[Intel-gfx] ✗ Fi.CI.IGT: failure for Geminilake GuC(11.98), HuC(3.0.2225); Icelake DMC v1.05 (rev2)
== Series Details == Series: Geminilake GuC(11.98), HuC(3.0.2225); Icelake DMC v1.05 (rev2) URL : https://patchwork.freedesktop.org/series/45036/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4344_full -> Patchwork_9363_full = == Summary - FAILURE == Serious unknown changes coming with Patchwork_9363_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9363_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_9363_full: === IGT changes === Possible regressions igt@debugfs_test@read_all_entries: shard-glk: PASS -> DMESG-WARN +3 igt@drv_selftest@mock_contexts: shard-apl: PASS -> DMESG-FAIL shard-kbl: PASS -> DMESG-FAIL shard-snb: PASS -> DMESG-FAIL shard-hsw: PASS -> DMESG-FAIL shard-glk: PASS -> DMESG-FAIL igt@pm_rpm@debugfs-read: shard-apl: PASS -> DMESG-WARN igt@prime_busy@wait-hang-vebox: shard-kbl: PASS -> DMESG-WARN +4 Warnings igt@drv_selftest@live_evict: shard-snb: PASS -> SKIP +13 igt@drv_selftest@live_execlists: shard-hsw: PASS -> SKIP +13 igt@drv_selftest@live_objects: shard-glk: PASS -> SKIP +14 igt@drv_selftest@live_workarounds: shard-apl: PASS -> SKIP +24 igt@gem_exec_blt@cold-max: shard-kbl: PASS -> SKIP +26 igt@gem_mocs_settings@mocs-rc6-ctx-dirty-render: shard-kbl: SKIP -> PASS == Known issues == Here are the changes found in Patchwork_9363_full that come from known issues: === IGT changes === Issues hit igt@gem_eio@execbuf: shard-glk: PASS -> INCOMPLETE (k.org#198133, fdo#103359) +1 shard-apl: PASS -> INCOMPLETE (fdo#103927) +1 igt@gem_eio@unwedge-stress: shard-glk: PASS -> FAIL (fdo#105957) igt@gem_render_copy_redux@interruptible: shard-kbl: PASS -> INCOMPLETE (fdo#106650, fdo#103665) igt@kms_available_modes_crc@available_mode_test_crc: shard-snb: PASS -> FAIL (fdo#106641) igt@kms_flip@dpms-vs-vblank-race: shard-hsw: PASS -> FAIL (fdo#103060) igt@kms_flip_tiling@flip-x-tiled: shard-glk: PASS -> FAIL (fdo#104724) igt@kms_setmode@basic: shard-apl: PASS -> FAIL (fdo#99912) igt@prime_busy@wait-hang-render: shard-kbl: PASS -> INCOMPLETE (fdo#103665) +3 Possible fixes igt@drv_suspend@shrink: shard-snb: FAIL (fdo#106886) -> PASS igt@gem_ctx_switch@basic-all-light: shard-hsw: INCOMPLETE (fdo#103540) -> PASS igt@kms_cursor_legacy@cursora-vs-flipa-toggle: shard-glk: DMESG-WARN (fdo#105763) -> PASS igt@kms_flip@2x-plain-flip-ts-check: shard-glk: FAIL (fdo#100368) -> PASS igt@kms_flip@dpms-vs-vblank-race-interruptible: shard-glk: FAIL (fdo#103060) -> PASS igt@kms_flip_tiling@flip-to-x-tiled: shard-glk: FAIL (fdo#104724) -> PASS igt@kms_frontbuffer_tracking@fbc-2p-primscrn-shrfb-plflip-blt: shard-glk: FAIL (fdo#104724, fdo#103167) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359 fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#105763 https://bugs.freedesktop.org/show_bug.cgi?id=105763 fdo#105957 https://bugs.freedesktop.org/show_bug.cgi?id=105957 fdo#106641 https://bugs.freedesktop.org/show_bug.cgi?id=106641 fdo#106650 https://bugs.freedesktop.org/show_bug.cgi?id=106650 fdo#106886 https://bugs.freedesktop.org/show_bug.cgi?id=106886 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4344 -> Patchwork_9363 CI_DRM_4344: 922a029a1d0ecf5c7e5c86a372a5d3df3fd35483 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4524: 9ab9268fa7eeda0a7ea6eb2ab02bb6c5b9c91ba0 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9363: c1e46071c64d06a3c9b3e3a6c354d858b1c132da @ git://anongit.freedesktop.org/gfx-ci/linux
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Force 2*96 MHz cdclk on glk/cnl when audio power is enabled (rev6)
== Series Details == Series: drm/i915: Force 2*96 MHz cdclk on glk/cnl when audio power is enabled (rev6) URL : https://patchwork.freedesktop.org/series/42459/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4344_full -> Patchwork_9362_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_9362_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9362_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_9362_full: === IGT changes === Warnings igt@gem_mocs_settings@mocs-rc6-ctx-dirty-render: shard-kbl: SKIP -> PASS == Known issues == Here are the changes found in Patchwork_9362_full that come from known issues: === IGT changes === Issues hit igt@drv_selftest@live_gtt: shard-glk: PASS -> FAIL (fdo#105347) igt@drv_selftest@live_hangcheck: shard-kbl: PASS -> DMESG-FAIL (fdo#106560, fdo#106947) igt@kms_flip@2x-plain-flip-fb-recreate-interruptible: shard-glk: PASS -> FAIL (fdo#100368) igt@kms_flip@dpms-vs-vblank-race: shard-hsw: PASS -> FAIL (fdo#103060) igt@kms_flip@flip-vs-expired-vblank: shard-glk: PASS -> FAIL (fdo#102887) igt@kms_flip_tiling@flip-x-tiled: shard-glk: PASS -> FAIL (fdo#104724, fdo#103822) igt@kms_setmode@basic: shard-apl: PASS -> FAIL (fdo#99912) Possible fixes igt@drv_suspend@shrink: shard-snb: FAIL (fdo#106886) -> PASS shard-apl: INCOMPLETE (fdo#103927) -> PASS shard-glk: FAIL (fdo#106886) -> PASS igt@gem_ctx_switch@basic-all-light: shard-hsw: INCOMPLETE (fdo#103540) -> PASS igt@kms_cursor_legacy@cursora-vs-flipa-toggle: shard-glk: DMESG-WARN (fdo#105763) -> PASS igt@kms_flip@2x-plain-flip-ts-check: shard-glk: FAIL (fdo#100368) -> PASS igt@kms_flip@dpms-vs-vblank-race-interruptible: shard-glk: FAIL (fdo#103060) -> PASS igt@kms_flip_tiling@flip-to-y-tiled: shard-glk: FAIL (fdo#104724, fdo#103822) -> PASS +1 igt@kms_frontbuffer_tracking@fbc-2p-primscrn-shrfb-plflip-blt: shard-glk: FAIL (fdo#103167, fdo#104724) -> PASS igt@kms_setmode@basic: shard-hsw: FAIL (fdo#99912) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540 fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#105347 https://bugs.freedesktop.org/show_bug.cgi?id=105347 fdo#105763 https://bugs.freedesktop.org/show_bug.cgi?id=105763 fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560 fdo#106886 https://bugs.freedesktop.org/show_bug.cgi?id=106886 fdo#106947 https://bugs.freedesktop.org/show_bug.cgi?id=106947 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4344 -> Patchwork_9362 CI_DRM_4344: 922a029a1d0ecf5c7e5c86a372a5d3df3fd35483 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4524: 9ab9268fa7eeda0a7ea6eb2ab02bb6c5b9c91ba0 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9362: 61069992fd7457cb12695c90199c205ce47d8f92 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9362/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] [RFC] Add support to force specific module load
Hi, Thanks a lot for your feedback. I believe that I understood all of your comments. I will start the first version of the patch. Best Regards Rodrigo Siqueira On 06/18, Petri Latvala wrote: > On Sat, Jun 16, 2018 at 09:26:31PM -0300, Rodrigo Siqueira wrote: > > Hi, > > > > First of all, thanks for your feedback :) > > > > On 06/13, Petri Latvala wrote: > > > On Tue, May 29, 2018 at 09:45:20PM -0300, Rodrigo Siqueira wrote: > > > > This patch adds a new option to force the use of a module specified from > > > > the command line. The force command expects a module name which will be > > > > used on the target test (changing the standard behavior). This feature > > > > can be useful for developers that have to create a new module since it > > > > is possible to use some of the tests already provided by IGT (e.g., > > > > kms_color, core, etc.) as a start point. Additionally, it can > > > > also be useful for someone that wants to implement a new set of tests > > > > for a specific driver because the developer can first check the behavior > > > > of any test in the target module. It is important to highlight, that a > > > > force option can produce unexpected results and developers should be > > > > aware of that. > > > > > > > > > Is this meant for testing replacement drivers for hardware with > > > already existing drivers? If not, I'm not sure what the goal is here. > > > > Just for provide some additional information, follows my context and > > motivation for this patch: > > > > We are working on a new module named VKMS [1,2]. In some way, our > > development approach is similar to Test-Driven Development (TDD), since > > we use IGT tests to support our development process. For example, at the > > beginning of the VKMS development we focused on making core_* tests > > pass, and now we are using kms_flip and others to help us to implement > > new features. For doing it, we changed IGT code to load our > > module. After thinking about the changes we made in the IGT, I realize > > that force a particular module via command line could be useful for > > other users because they can utilize the available tests to help them to > > create their modules (as we are doing). Additionally, I think this > > feature could be used for test some basic features on modules that > > currently aren't part of the IGT. > > > > So, what do you think about that? Do you think that makes sense to have > > this feature in the IGT? > > Yes! The devil is in the details though. > > Forcing the use of a specific driver, that's what we're going to need > in IGT in some form. > > After discussing this with you on IRC, I learned that you're running a > VM without any other DRM drivers (loaded). That's why you have this > system working at this time. > > When the tests want an fd to a DRM device, drmtest.c tries to open the > first /dev/dri/card that matches what is requested. If everything > fails, it loads all modules it knows about and tries another time, > again opening the first /dev/dri/card that matches the request. > > If you had, say, i915 loaded or builtin, you'd have /dev/dri/card0 > already, and it would be used for DRIVER_ANY opens regardless of > whether you modprobe vkms. If vkms was builtin, modprobe would change > nothing. > > One force option that we absolutely need is selecting what DRIVER_ANY > means, in a device that has multiple DRM drivers available. Another is > forcing which /dev/dri/card to use, with or without overriding > what DRIVER_ANY means. Forcing a modprobe on a particular driver isn't > strictly speaking a third option, but tied to the two. > > (One could argue that modprobing a driver can also be done from one's > testing scripts, but drivers can be left unloaded by e.g. a test that > checks module unloading.) > > An approach I came up with is setting a string and in drmtest.c, > __open_device(), > > if (force_string && chipset == DRIVER_ANY && __is_device(fd, > force_string)) > return fd; > > That would force vkms to be used by setting force_string to "vkms", > assuming DRM_IOCTL_VERSION gives that as its name. That allows vkms to > be builtin, and other drivers to be loaded. > > In addition to that, setting another force string could be used to > modprobe a specific module. In addition to what is already loaded by > the modprobe loop, forcing the device name in the above code would > mean other drivers won't be used. > > > > > > > Setting a forced module target in this patch changes which module is > > > loaded by the kernel, but the driver that's opened by IGT is > > > unchanged. Force-loading my-fancy-driver.ko still makes > > > drm_open_driver(DRIVER_INTEL) open the one driven by i915.ko, and > > > drm_open_driver(DRIVER_ANY) still opens the first one that is > > > recognized. > > > > I think it is better to force open and load, right? > > > > > If this is for testing new drivers for not-already-supported devices, > > > you need to instead force what
[Intel-gfx] ✓ Fi.CI.BAT: success for Geminilake GuC(11.98), HuC(3.0.2225); Icelake DMC v1.05 (rev2)
== Series Details == Series: Geminilake GuC(11.98), HuC(3.0.2225); Icelake DMC v1.05 (rev2) URL : https://patchwork.freedesktop.org/series/45036/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4344 -> Patchwork_9363 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/45036/revisions/2/mbox/ == Known issues == Here are the changes found in Patchwork_9363 that come from known issues: === IGT changes === Issues hit igt@drv_module_reload@basic-reload-inject: fi-glk-j4005: PASS -> DMESG-WARN (fdo#106248, fdo#106725) igt@gem_exec_gttfill@basic: fi-byt-n2820: PASS -> FAIL (fdo#106744) igt@gem_exec_suspend@basic-s4-devices: fi-glk-j4005: PASS -> DMESG-WARN (fdo#106097) igt@kms_flip@basic-flip-vs-wf_vblank: fi-glk-j4005: PASS -> FAIL (fdo#100368) igt@kms_flip@basic-plain-flip: fi-glk-j4005: PASS -> DMESG-WARN (fdo#106000) +1 Possible fixes igt@kms_flip@basic-flip-vs-modeset: fi-glk-j4005: DMESG-WARN (fdo#106097) -> PASS igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: fi-bxt-dsi: INCOMPLETE (fdo#103927) -> PASS igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: fi-glk-j4005: DMESG-WARN (fdo#106238) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#106000 https://bugs.freedesktop.org/show_bug.cgi?id=106000 fdo#106097 https://bugs.freedesktop.org/show_bug.cgi?id=106097 fdo#106238 https://bugs.freedesktop.org/show_bug.cgi?id=106238 fdo#106248 https://bugs.freedesktop.org/show_bug.cgi?id=106248 fdo#106725 https://bugs.freedesktop.org/show_bug.cgi?id=106725 fdo#106744 https://bugs.freedesktop.org/show_bug.cgi?id=106744 == Participating hosts (43 -> 37) == Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-j1900 fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 == Build changes == * Linux: CI_DRM_4344 -> Patchwork_9363 CI_DRM_4344: 922a029a1d0ecf5c7e5c86a372a5d3df3fd35483 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4524: 9ab9268fa7eeda0a7ea6eb2ab02bb6c5b9c91ba0 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9363: c1e46071c64d06a3c9b3e3a6c354d858b1c132da @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == c1e46071c64d Enable guc loading for Geminilake. 29a332ad9298 firmware/huc/glk: Load HuC v03.00.2225 for Geminilake. 30d0c4d0ab66 firmware/guc/glk: Load GuC v11.98 for Geminilake. 67704b18cfb3 firmware/dmc/icl: load v1.05 on icelake. == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9363/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Wait for PSR exit before checking for vblank evasion
On Tue, 2018-06-19 at 14:59 -0700, Tarun Vyas wrote: > On Tue, Jun 19, 2018 at 02:54:07PM -0700, Dhinakaran Pandiyan wrote: > > > > On Tue, 2018-06-19 at 14:27 -0700, Dhinakaran Pandiyan wrote: > > > > > > On Mon, 2018-05-14 at 13:49 -0700, Tarun Vyas wrote: > > > > > > > > > > > > The PIPEDSL freezes on PSR entry and if PSR hasn't fully > > > > exited, > > > > then > > > > the pipe_update_start call schedules itself out to check back > > > > later. > > > > > > > > On ChromeOS-4.4 kernel, which is fairly up-to-date w.r.t > > > > drm/i915 > > > > but > > > > lags w.r.t core kernel code, hot plugging an external display > > > > triggers > > > > tons of "potential atomic update errors" in the dmesg, on *pipe > > > > A*. > > > > A > > > > closer analysis reveals that we try to read the scanline 3 > > > > times > > > > and > > > > eventually timeout, b/c PSR hasn't exited fully leading to a > > > > PIPEDSL > > > > stuck @ 1599. This issue is not seen on upstream kernels, b/c > > > > for > > > > *some* > > > > reason we loop inside intel_pipe_update start for ~2+ msec > > > > which in > > > > this > > > > case is more than enough to exit PSR fully, hence an *unstuck* > > > > PIPEDSL > > > > counter, hence no error. On the other hand, the ChromeOS kernel > > > > spends > > > > ~1.1 msec looping inside intel_pipe_update_start and hence > > > > errors > > > > out > > > > b/c the source is still in PSR. > > > > > > > > Regardless, we should wait for PSR exit (if PSR is supported > > > > and > > > > active > > > > on the current pipe) before reading the PIPEDSL, b/c if we > > > > haven't > > > > fully exited PSR, then checking for vblank evasion isn't > > > > actually > > > > applicable. > > > > > > > > This scenario applies to a configuration with an additional > > > > pipe, > > > > as of now > > > > > > > > Signed-off-by: Tarun Vyas > > > > --- > > > > drivers/gpu/drm/i915/intel_sprite.c | 7 +-- > > > > 1 file changed, 5 insertions(+), 2 deletions(-) > > > > > > > > diff --git a/drivers/gpu/drm/i915/intel_sprite.c > > > > b/drivers/gpu/drm/i915/intel_sprite.c > > > > index ee23613f9fd4..481d310e5c3b 100644 > > > > --- a/drivers/gpu/drm/i915/intel_sprite.c > > > > +++ b/drivers/gpu/drm/i915/intel_sprite.c > > > > @@ -107,14 +107,17 @@ void intel_pipe_update_start(const struct > > > > intel_crtc_state *new_crtc_state) > > > > VBLANK_E > > > > VASI > > > > ON > > > > _TIME_US); > > > > max = vblank_start - 1; > > > > > > > > - local_irq_disable(); > > > > - > > > > if (min <= 0 || max <= 0) > > > > return; > > > > > > > > if (WARN_ON(drm_crtc_vblank_get(>base))) > > > > return; > > > > > > > > + if(new_crtc_state->has_psr && dev_priv->psr.active) > > > > + psr_wait_for_idle(dev_priv); > > > How about just waiting for PSR_STATUS to idle without grabbing > > > any > > > locks or checking whether PSR is active? > > > > > > Status should be idle if PSR was disabled or on it's way to > > > becoming > > > idle if it was enabled. Even if PSR did get enabled while we are > > > in > > > pipe_update_start(), it will not be active as long as VBIs are > > > enabled. > > > > Right, if we are OK with some duplication (of psr_wait_for_idle) > inside intel_psr.c, then we can duplicate the PSR2 vs. PSR check > that's being done in psr_wait_for_idle and then just wait without > grabbing any locks, so essentially a lockless version of > psr_wait_for_idle() Yeah, you can extract the wait into psr_wait_for_idle_locked() > > > > Correct me if this was already considered, why not wait until the > > scanline counter starts moving? I see we have a > > intel_wait_for_pipe_scanline_moving(crtc) that's used when the > > pipe is enabled. > > > > -DK > Didn't consider this before, but, pipe_scanline_is_moving waits for a > minimum of 5 msec. Are we OK with a min wait of 5 msec inside > pipe_update_start ? Heuristically, waiting for PSR idle has almost > always returned within < 2 msec. Occasionally it takes upto 1 full > frame. We should be able to change that function. ___ 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: Force 2*96 MHz cdclk on glk/cnl when audio power is enabled (rev6)
== Series Details == Series: drm/i915: Force 2*96 MHz cdclk on glk/cnl when audio power is enabled (rev6) URL : https://patchwork.freedesktop.org/series/42459/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4344 -> Patchwork_9362 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/42459/revisions/6/mbox/ == Known issues == Here are the changes found in Patchwork_9362 that come from known issues: === IGT changes === Issues hit igt@debugfs_test@read_all_entries: fi-snb-2520m: PASS -> INCOMPLETE (fdo#103713) igt@gem_ctx_create@basic-files: fi-skl-gvtdvm: PASS -> INCOMPLETE (fdo#105600) igt@gem_exec_gttfill@basic: fi-byt-n2820: PASS -> FAIL (fdo#106744) igt@kms_pipe_crc_basic@read-crc-pipe-c: fi-glk-j4005: PASS -> DMESG-WARN (fdo#106238) igt@pm_rpm@basic-rte: fi-glk-j4005: PASS -> DMESG-WARN (fdo#106097) Possible fixes igt@kms_flip@basic-flip-vs-modeset: fi-glk-j4005: DMESG-WARN (fdo#106097) -> PASS igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: fi-bxt-dsi: INCOMPLETE (fdo#103927) -> PASS igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: fi-glk-j4005: DMESG-WARN (fdo#106238) -> PASS fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#105600 https://bugs.freedesktop.org/show_bug.cgi?id=105600 fdo#106097 https://bugs.freedesktop.org/show_bug.cgi?id=106097 fdo#106238 https://bugs.freedesktop.org/show_bug.cgi?id=106238 fdo#106744 https://bugs.freedesktop.org/show_bug.cgi?id=106744 == Participating hosts (43 -> 37) == Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-j1900 fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 == Build changes == * Linux: CI_DRM_4344 -> Patchwork_9362 CI_DRM_4344: 922a029a1d0ecf5c7e5c86a372a5d3df3fd35483 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4524: 9ab9268fa7eeda0a7ea6eb2ab02bb6c5b9c91ba0 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9362: 61069992fd7457cb12695c90199c205ce47d8f92 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 61069992fd74 drm/i915: Force 2*96 MHz cdclk on glk/cnl when audio power is enabled == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9362/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 18/24] drm/i915/icl: implement icl_digital_port_connected()
On Mon, May 21, 2018 at 05:25:52PM -0700, Paulo Zanoni wrote:
> Do like the other functions and check for the ISR bits. We have plans
> to add a few more checks in this code in the next patches, that's why
> it's a little more verbose than it could be.
>
> Cc: Animesh Manna
> Signed-off-by: Paulo Zanoni
> Signed-off-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/i915_reg.h | 5
> drivers/gpu/drm/i915/intel_dp.c | 57
> +
> 2 files changed, 62 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 49a72320e794..24308d4435f5 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7055,6 +7055,7 @@ enum {
> #define GEN11_TC3_HOTPLUG (1 << 18)
> #define GEN11_TC2_HOTPLUG (1 << 17)
> #define GEN11_TC1_HOTPLUG (1 << 16)
> +#define GEN11_TC_HOTPLUG(tc_port) (1 << ((tc_port) + 16))
> #define GEN11_DE_TC_HOTPLUG_MASK(GEN11_TC4_HOTPLUG | \
>GEN11_TC3_HOTPLUG | \
>GEN11_TC2_HOTPLUG | \
> @@ -7063,6 +7064,7 @@ enum {
> #define GEN11_TBT3_HOTPLUG (1 << 2)
> #define GEN11_TBT2_HOTPLUG (1 << 1)
> #define GEN11_TBT1_HOTPLUG (1 << 0)
> +#define GEN11_TBT_HOTPLUG(tc_port) (1 << (tc_port))
> #define GEN11_DE_TBT_HOTPLUG_MASK (GEN11_TBT4_HOTPLUG | \
>GEN11_TBT3_HOTPLUG | \
>GEN11_TBT2_HOTPLUG | \
> @@ -7486,6 +7488,9 @@ enum {
> #define ICP_GMBUS (1 << 23)
> #define ICP_DDIB_HOTPLUG (1 << 17)
> #define ICP_DDIA_HOTPLUG (1 << 16)
> +#define ICP_TC_HOTPLUG(tc_port) (1 << ((tc_port) + 24))
> +#define ICP_DDI_HOTPLUG(port)(1 << ((port) + 16))
> +
>
> #define ICP_SDE_DDI_MASK (ICP_DDIB_HOTPLUG | \
>ICP_DDIA_HOTPLUG)
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 102070940095..b477124717e7 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4722,6 +4722,61 @@ static bool bxt_digital_port_connected(struct
> intel_encoder *encoder)
> return I915_READ(GEN8_DE_PORT_ISR) & bit;
> }
>
> +static bool icl_combo_port_connected(struct drm_i915_private *dev_priv,
> + struct intel_digital_port *intel_dig_port)
> +{
> + enum port port = intel_dig_port->base.port;
> +
> + return I915_READ(ICP_SDE_ISR) & ICP_DDI_HOTPLUG(port);
> +}
> +
> +static bool icl_tc_port_connected(struct drm_i915_private *dev_priv,
> + struct intel_digital_port *intel_dig_port)
> +{
> + enum port port = intel_dig_port->base.port;
> + enum tc_port tc_port = intel_port_to_tc(dev_priv, port);
> + u32 legacy_bit = ICP_TC_HOTPLUG(tc_port);
> + u32 typec_bit = GEN11_TC_HOTPLUG(tc_port);
> + u32 tbt_bit = GEN11_TBT_HOTPLUG(tc_port);
> + bool is_legacy = false, is_typec = false, is_tbt = false;
> + u32 cpu_isr;
why *cpu*_isr? hpd_isr, isr or val would be better IMO
> +
> + if (I915_READ(ICP_SDE_ISR) & legacy_bit)
> + is_legacy = true;
> +
> + cpu_isr = I915_READ(GEN11_DE_HPD_ISR);
> + if (cpu_isr & typec_bit)
> + is_typec = true;
> + if (cpu_isr & tbt_bit)
> + is_tbt = true;
> +
> + WARN_ON(is_legacy + is_typec + is_tbt > 1);
> + if (!is_legacy && !is_typec && !is_tbt)
> + return false;
> +
> + return true;
you know you could "return is_legacy + is_typec + is_tbt;", right? you
are already doing it above, it may make sense to remove the extra
branch. Or not.
Feel free to disagree and push.
Reviewed-by: Lucas De Marchi
Lucas De Marchi
> +}
> +
> +static bool icl_digital_port_connected(struct intel_encoder *encoder)
> +{
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> + struct intel_digital_port *dig_port = enc_to_dig_port(>base);
> +
> + switch (encoder->hpd_pin) {
> + case HPD_PORT_A:
> + case HPD_PORT_B:
> + return icl_combo_port_connected(dev_priv, dig_port);
> + case HPD_PORT_C:
> + case HPD_PORT_D:
> + case HPD_PORT_E:
> + case HPD_PORT_F:
> + return icl_tc_port_connected(dev_priv, dig_port);
> + default:
> + MISSING_CASE(encoder->hpd_pin);
> + return false;
> + }
> +}
> +
> /*
> * intel_digital_port_connected - is the specified port connected?
> * @encoder: intel_encoder
> @@ -4749,6 +4804,8 @@ bool intel_digital_port_connected(struct intel_encoder
> *encoder)
> return bdw_digital_port_connected(encoder);
> else if (IS_GEN9_LP(dev_priv))
>
[Intel-gfx] [PATCH 3/4] firmware/huc/glk: Load HuC v03.00.2225 for Geminilake.
load the v03.00.2225 huC on geminilake.
v2:
- rebased.
- Load the correct the version. (John Spotswood)
v3:
- rebased.
v4: Change subject subject prefix.(Anusha)
Cc: John Spotswood
Cc: Tomi Sarvela
Cc: Jani Saarinen
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/intel_huc_fw.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_huc_fw.c
b/drivers/gpu/drm/i915/intel_huc_fw.c
index f93d238..b8efbff 100644
--- a/drivers/gpu/drm/i915/intel_huc_fw.c
+++ b/drivers/gpu/drm/i915/intel_huc_fw.c
@@ -34,6 +34,10 @@
#define KBL_HUC_FW_MINOR 00
#define KBL_BLD_NUM 1810
+#define GLK_HUC_FW_MAJOR 03
+#define GLK_HUC_FW_MINOR 00
+#define GLK_BLD_NUM 2225
+
#define HUC_FW_PATH(platform, major, minor, bld_num) \
"i915/" __stringify(platform) "_huc_ver" __stringify(major) "_" \
__stringify(minor) "_" __stringify(bld_num) ".bin"
@@ -50,6 +54,10 @@ MODULE_FIRMWARE(I915_BXT_HUC_UCODE);
KBL_HUC_FW_MINOR, KBL_BLD_NUM)
MODULE_FIRMWARE(I915_KBL_HUC_UCODE);
+#define I915_GLK_HUC_UCODE HUC_FW_PATH(glk, GLK_HUC_FW_MAJOR, \
+ GLK_HUC_FW_MINOR, GLK_BLD_NUM)
+MODULE_FIRMWARE(I915_GLK_HUC_UCODE);
+
static void huc_fw_select(struct intel_uc_fw *huc_fw)
{
struct intel_huc *huc = container_of(huc_fw, struct intel_huc, fw);
@@ -76,6 +84,10 @@ static void huc_fw_select(struct intel_uc_fw *huc_fw)
huc_fw->path = I915_KBL_HUC_UCODE;
huc_fw->major_ver_wanted = KBL_HUC_FW_MAJOR;
huc_fw->minor_ver_wanted = KBL_HUC_FW_MINOR;
+ } else if (IS_GEMINILAKE(dev_priv)) {
+ huc_fw->path = I915_GLK_HUC_UCODE;
+ huc_fw->major_ver_wanted = GLK_HUC_FW_MAJOR;
+ huc_fw->minor_ver_wanted = GLK_HUC_FW_MINOR;
} else {
DRM_WARN("%s: No firmware known for this platform!\n",
intel_uc_fw_type_repr(huc_fw->type));
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/4] Enable guc loading for Geminilake.
Signed-off-by: Anusha Srivatsa --- drivers/gpu/drm/i915/i915_params.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_params.h b/drivers/gpu/drm/i915/i915_params.h index aebe046..3e4e128 100644 --- a/drivers/gpu/drm/i915/i915_params.h +++ b/drivers/gpu/drm/i915/i915_params.h @@ -47,7 +47,7 @@ struct drm_printer; param(int, disable_power_well, -1) \ param(int, enable_ips, 1) \ param(int, invert_brightness, 0) \ - param(int, enable_guc, 0) \ + param(int, enable_guc, -1) \ param(int, guc_log_level, -1) \ param(char *, guc_firmware_path, NULL) \ param(char *, huc_firmware_path, NULL) \ -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/4] firmware/dmc/icl: load v1.05 on icelake.
Add Support to load DMC on Icelake.
Cc: Rodrigo Vivi
Cc: Paulo Zanoni
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/intel_csr.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c
index cf9b600..dfc2b7f 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -34,6 +34,9 @@
* low-power state and comes back to normal.
*/
+#define I915_CSR_ICL "i915/icl_dmc_ver1_05.bin"
+#define ICL_CSR_VERSION_REQUIRED CSR_VERSION(1, 5)
+
#define I915_CSR_GLK "i915/glk_dmc_ver1_04.bin"
MODULE_FIRMWARE(I915_CSR_GLK);
#define GLK_CSR_VERSION_REQUIRED CSR_VERSION(1, 4)
@@ -301,6 +304,8 @@ static uint32_t *parse_csr_fw(struct drm_i915_private
*dev_priv,
if (csr->fw_path == i915_modparams.dmc_firmware_path) {
/* Bypass version check for firmware override. */
required_version = csr->version;
+ } else if (IS_ICELAKE(dev_priv)) {
+ required_version = ICL_CSR_VERSION_REQUIRED;
} else if (IS_CANNONLAKE(dev_priv)) {
required_version = CNL_CSR_VERSION_REQUIRED;
} else if (IS_GEMINILAKE(dev_priv)) {
@@ -458,6 +463,8 @@ void intel_csr_ucode_init(struct drm_i915_private *dev_priv)
if (i915_modparams.dmc_firmware_path)
csr->fw_path = i915_modparams.dmc_firmware_path;
+ else if (IS_ICELAKE(dev_priv))
+ csr->fw_path = I915_CSR_ICL;
else if (IS_CANNONLAKE(dev_priv))
csr->fw_path = I915_CSR_CNL;
else if (IS_GEMINILAKE(dev_priv))
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/4] Geminilake GuC(11.98), HuC(3.0.2225); Icelake DMC v1.05
Resending Geminilake GuC,HuC to trigger new CI runs. Adding Icelake DMC Support. The following changes since commit d1147327232ec4616a66ab898df84f9700c816c1: Merge branch 'for-upstreaming-v1.7.2-vsw' of https://github.com/felix-cavium/linux-firmware (2018-06-06 13:23:36 -0400) are available in the git repository at: git://anongit.freedesktop.org/drm/drm-firmware master for you to fetch changes up to 57ffda274ed80b057f6d1e2a84a9a866b2d52b7d: firmware/icl/dmc: Add DMC v1.05 for Icelake. (2018-06-19 14:53:21 -0700) Anusha Srivatsa (14): linux-firmware/i915: GuC firmware for Cannonlake v11.102 linux-firmware/i915: HuC firmware for Cannonlake v9.01.2678 Revert "linux-firmware/i915: HuC firmware for Cannonlake v9.01.2678" Revert "linux-firmware/i915: GuC firmware for Cannonlake v11.102" Merge remote-tracking branch 'official/master' into drm-firmware linux-firmware/i915: GuC firmware for Cannonlake v11.102 linux-firmware/i915: HuC firmware for Cannonlake v9.01.2719 Merge remote-tracking branch 'official/master' linux-firmware: Add GuC v11.98 for geminilake linux-firmware: Add HuC v3.00.2225 for geminilake Revert "linux-firmware/i915: GuC firmware for Cannonlake v11.102" Revert "linux-firmware/i915: HuC firmware for Cannonlake v9.01.2719" Merge remote-tracking branch 'official/master' Merge remote-tracking branch 'official/master' firmware/icl/dmc: Add DMC v1.05 for Icelake. WHENCE | 9 + i915/glk_guc_ver11_98.bin | Bin 0 -> 154240 bytes i915/glk_huc_ver03_00_2225.bin | Bin 0 -> 220032 bytes i915/icl_dmc_ver1_05.bin | Bin 0 -> 25836 bytes 4 files changed, 9 insertions(+) create mode 100644 i915/glk_guc_ver11_98.bin create mode 100644 i915/glk_huc_ver03_00_2225.bin create mode 100644 i915/icl_dmc_ver1_05.bin Anusha Srivatsa (3): firmware/dmc/icl: load v1.05 on icelake. firmware/huc/glk: Load HuC v03.00.2225 for Geminilake. Enable guc loading for Geminilake. John Spotswood (1): firmware/guc/glk: Load GuC v11.98 for Geminilake. drivers/gpu/drm/i915/i915_params.h | 2 +- drivers/gpu/drm/i915/intel_csr.c| 7 +++ drivers/gpu/drm/i915/intel_guc_fw.c | 10 ++ drivers/gpu/drm/i915/intel_huc_fw.c | 12 4 files changed, 30 insertions(+), 1 deletion(-) -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/4] firmware/guc/glk: Load GuC v11.98 for Geminilake.
From: John Spotswood
load the v11.98 guC on geminilake.
v2: rebased.
v3: Change subject prefix. (Anusha)
Cc: Tomi Sarvela
Cc: Jani Saarinen
Signed-off-by: Anusha Srivatsa
Signed-off-by: John Spotswood
---
drivers/gpu/drm/i915/intel_guc_fw.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_guc_fw.c
b/drivers/gpu/drm/i915/intel_guc_fw.c
index a9e6fcc..29b1d92 100644
--- a/drivers/gpu/drm/i915/intel_guc_fw.c
+++ b/drivers/gpu/drm/i915/intel_guc_fw.c
@@ -39,6 +39,9 @@
#define KBL_FW_MAJOR 9
#define KBL_FW_MINOR 39
+#define GLK_FW_MAJOR 11
+#define GLK_FW_MINOR 98
+
#define GUC_FW_PATH(platform, major, minor) \
"i915/" __stringify(platform) "_guc_ver" __stringify(major) "_"
__stringify(minor) ".bin"
@@ -51,6 +54,9 @@ MODULE_FIRMWARE(I915_BXT_GUC_UCODE);
#define I915_KBL_GUC_UCODE GUC_FW_PATH(kbl, KBL_FW_MAJOR, KBL_FW_MINOR)
MODULE_FIRMWARE(I915_KBL_GUC_UCODE);
+#define I915_GLK_GUC_UCODE GUC_FW_PATH(glk, GLK_FW_MAJOR, GLK_FW_MINOR)
+MODULE_FIRMWARE(I915_GLK_GUC_UCODE);
+
static void guc_fw_select(struct intel_uc_fw *guc_fw)
{
struct intel_guc *guc = container_of(guc_fw, struct intel_guc, fw);
@@ -77,6 +83,10 @@ static void guc_fw_select(struct intel_uc_fw *guc_fw)
guc_fw->path = I915_KBL_GUC_UCODE;
guc_fw->major_ver_wanted = KBL_FW_MAJOR;
guc_fw->minor_ver_wanted = KBL_FW_MINOR;
+ } else if (IS_GEMINILAKE(dev_priv)) {
+ guc_fw->path = I915_GLK_GUC_UCODE;
+ guc_fw->major_ver_wanted = GLK_FW_MAJOR;
+ guc_fw->minor_ver_wanted = GLK_FW_MINOR;
} else {
DRM_WARN("%s: No firmware known for this platform!\n",
intel_uc_fw_type_repr(guc_fw->type));
--
2.7.4
___
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: Nuke the cursor size defines
On Fri, Jun 15, 2018 at 08:44:04PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> No point in having this extra indireciton for the cursor max size.
> So drop the defines and just write out the raw numbers. Makes it
> easier to see what's going on.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/intel_display.c | 8
> drivers/gpu/drm/i915/intel_drv.h | 6 --
> 2 files changed, 4 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 8251e189a8bb..f6655f482b67 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -15054,11 +15054,11 @@ int intel_modeset_init(struct drm_device *dev)
> dev->mode_config.cursor_width = IS_I845G(dev_priv) ? 64 : 512;
> dev->mode_config.cursor_height = 1023;
> } else if (IS_GEN2(dev_priv)) {
> - dev->mode_config.cursor_width = GEN2_CURSOR_WIDTH;
> - dev->mode_config.cursor_height = GEN2_CURSOR_HEIGHT;
> + dev->mode_config.cursor_width = 64;
> + dev->mode_config.cursor_height = 64;
> } else {
> - dev->mode_config.cursor_width = MAX_CURSOR_WIDTH;
> - dev->mode_config.cursor_height = MAX_CURSOR_HEIGHT;
> + dev->mode_config.cursor_width = 256;
> + dev->mode_config.cursor_height = 256;
> }
>
> dev->mode_config.fb_base = ggtt->gmadr.start;
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 8840108749a5..2d09f08e5e0c 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -158,12 +158,6 @@
> #define MAX_OUTPUTS 6
> /* maximum connectors per crtcs in the mode set */
>
> -/* Maximum cursor sizes */
> -#define GEN2_CURSOR_WIDTH 64
> -#define GEN2_CURSOR_HEIGHT 64
> -#define MAX_CURSOR_WIDTH 256
> -#define MAX_CURSOR_HEIGHT 256
> -
> #define INTEL_I2C_BUS_DVO 1
> #define INTEL_I2C_BUS_SDVO 2
>
> --
> 2.16.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Force 2*96 MHz cdclk on glk/cnl when audio power is enabled (rev6)
== Series Details == Series: drm/i915: Force 2*96 MHz cdclk on glk/cnl when audio power is enabled (rev6) URL : https://patchwork.freedesktop.org/series/42459/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915: Force 2*96 MHz cdclk on glk/cnl when audio power is enabled -O:drivers/gpu/drm/i915/intel_cdclk.c:2204:29: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_cdclk.c:2193:29: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/intel_cdclk.c:2245:29: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/intel_cdclk.c:2245:29: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_cdclk.c:2234:29: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_cdclk.c:2234:29: warning: expression using sizeof(void) -drivers/gpu/drm/i915/selftests/../i915_drv.h:3690:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3693:16: warning: expression using sizeof(void) ___ 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: Force 2*96 MHz cdclk on glk/cnl when audio power is enabled (rev6)
== Series Details ==
Series: drm/i915: Force 2*96 MHz cdclk on glk/cnl when audio power is enabled
(rev6)
URL : https://patchwork.freedesktop.org/series/42459/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
61069992fd74 drm/i915: Force 2*96 MHz cdclk on glk/cnl when audio power is
enabled
-:62: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#62: FILE: drivers/gpu/drm/i915/intel_audio.c:726:
+static void glk_force_audio_cdclk(struct drm_i915_private *dev_priv,
+ bool enable)
-:207: WARNING:SUSPECT_CODE_INDENT: suspect code indent for conditional
statements (16, 25)
#207: FILE: drivers/gpu/drm/i915/intel_cdclk.c:2436:
if (IS_GEMINILAKE(dev_priv)) {
+cdclk =
glk_calc_cdclk(intel_state->cdclk.force_min_cdclk);
total: 0 errors, 1 warnings, 1 checks, 219 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5] drm/i915: Force 2*96 MHz cdclk on glk/cnl when audio power is enabled
From: Ville Syrjälä
CDCLK has to be at least twice the BLCK regardless of audio. Audio
driver has to probe using this hook and increase the clock even in
absence of any display.
v2: Use atomic refcount for get_power, put_power so that we can
call each once(Abhay).
v3: Reset power well 2 to avoid any transaction on iDisp link
during cdclk change(Abhay).
v4: Remove Power well 2 reset workaround(Ville).
v5: Remove unwanted Power well 2 register defined in v4(Abhay).
Signed-off-by: Ville Syrjälä
Signed-off-by: Abhay Kumar
---
drivers/gpu/drm/i915/i915_drv.h | 3 ++
drivers/gpu/drm/i915/intel_audio.c | 67 +---
drivers/gpu/drm/i915/intel_cdclk.c | 29 +---
drivers/gpu/drm/i915/intel_display.c | 7 +++-
drivers/gpu/drm/i915/intel_drv.h | 2 ++
5 files changed, 83 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6104d7115054..a4a386a5db69 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1702,6 +1702,7 @@ struct drm_i915_private {
unsigned int hpll_freq;
unsigned int fdi_pll_freq;
unsigned int czclk_freq;
+ u32 get_put_refcount;
struct {
/*
@@ -1719,6 +1720,8 @@ struct drm_i915_private {
struct intel_cdclk_state actual;
/* The current hardware cdclk state */
struct intel_cdclk_state hw;
+
+ int force_min_cdclk;
} cdclk;
/**
diff --git a/drivers/gpu/drm/i915/intel_audio.c
b/drivers/gpu/drm/i915/intel_audio.c
index 3ea566f99450..ca8f04c7cbb3 100644
--- a/drivers/gpu/drm/i915/intel_audio.c
+++ b/drivers/gpu/drm/i915/intel_audio.c
@@ -618,7 +618,6 @@ void intel_audio_codec_enable(struct intel_encoder *encoder,
if (!connector->eld[0])
return;
-
DRM_DEBUG_DRIVER("ELD on [CONNECTOR:%d:%s], [ENCODER:%d:%s]\n",
connector->base.id,
connector->name,
@@ -713,14 +712,74 @@ void intel_init_audio_hooks(struct drm_i915_private
*dev_priv)
}
}
+static void glk_force_audio_cdclk(struct drm_i915_private *dev_priv,
+ bool enable)
+{
+ struct drm_modeset_acquire_ctx ctx;
+ struct drm_atomic_state *state;
+ int ret;
+
+ drm_modeset_acquire_init(, 0);
+ state = drm_atomic_state_alloc(_priv->drm);
+ if (WARN_ON(!state))
+ return;
+
+ state->acquire_ctx =
+
+retry:
+ to_intel_atomic_state(state)->modeset = true;
+ to_intel_atomic_state(state)->cdclk.force_min_cdclk =
+ enable ? 2 * 96000 : 0;
+
+ /*
+* Protects dev_priv->cdclk.force_min_cdclk
+* Need to lock this here in case we have no active pipes
+* and thus wouldn't lock it during the commit otherwise.
+*/
+ ret = drm_modeset_lock(_priv->drm.mode_config.connection_mutex,
);
+ if (!ret)
+ ret = drm_atomic_commit(state);
+
+ if (ret == -EDEADLK) {
+ drm_atomic_state_clear(state);
+ drm_modeset_backoff();
+ goto retry;
+ }
+
+ WARN_ON(ret);
+
+ drm_atomic_state_put(state);
+
+ drm_modeset_drop_locks();
+ drm_modeset_acquire_fini();
+}
+
static void i915_audio_component_get_power(struct device *kdev)
{
- intel_display_power_get(kdev_to_i915(kdev), POWER_DOMAIN_AUDIO);
+ struct drm_i915_private *dev_priv = kdev_to_i915(kdev);
+
+ dev_priv->get_put_refcount++;
+
+ /* Force cdclk to 2*BCLK during first time get power call */
+ if (dev_priv->get_put_refcount == 1)
+ if (IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv))
+ glk_force_audio_cdclk(dev_priv, true);
+
+ intel_display_power_get(dev_priv, POWER_DOMAIN_AUDIO);
}
static void i915_audio_component_put_power(struct device *kdev)
{
- intel_display_power_put(kdev_to_i915(kdev), POWER_DOMAIN_AUDIO);
+ struct drm_i915_private *dev_priv = kdev_to_i915(kdev);
+
+ dev_priv->get_put_refcount--;
+
+ /* Force required cdclk during last time put power call */
+ if (dev_priv->get_put_refcount == 0)
+ if (IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv))
+ glk_force_audio_cdclk(dev_priv, false);
+
+ intel_display_power_put(dev_priv, POWER_DOMAIN_AUDIO);
}
static void i915_audio_component_codec_wake_override(struct device *kdev,
@@ -959,7 +1018,7 @@ void i915_audio_component_init(struct drm_i915_private
*dev_priv)
/* continue with reduced functionality */
return;
}
-
+ dev_priv->get_put_refcount = 0;
dev_priv->audio_component_registered = true;
}
diff --git a/drivers/gpu/drm/i915/intel_cdclk.c
b/drivers/gpu/drm/i915/intel_cdclk.c
index 8ed7bd052e46..0f0aea900ceb 100644
---
Re: [Intel-gfx] [PATCH v2] drm/i915: Wait for PSR exit before checking for vblank evasion
On Tue, Jun 19, 2018 at 02:54:07PM -0700, Dhinakaran Pandiyan wrote: > On Tue, 2018-06-19 at 14:27 -0700, Dhinakaran Pandiyan wrote: > > On Mon, 2018-05-14 at 13:49 -0700, Tarun Vyas wrote: > > > > > > The PIPEDSL freezes on PSR entry and if PSR hasn't fully exited, > > > then > > > the pipe_update_start call schedules itself out to check back > > > later. > > > > > > On ChromeOS-4.4 kernel, which is fairly up-to-date w.r.t drm/i915 > > > but > > > lags w.r.t core kernel code, hot plugging an external display > > > triggers > > > tons of "potential atomic update errors" in the dmesg, on *pipe A*. > > > A > > > closer analysis reveals that we try to read the scanline 3 times > > > and > > > eventually timeout, b/c PSR hasn't exited fully leading to a > > > PIPEDSL > > > stuck @ 1599. This issue is not seen on upstream kernels, b/c for > > > *some* > > > reason we loop inside intel_pipe_update start for ~2+ msec which in > > > this > > > case is more than enough to exit PSR fully, hence an *unstuck* > > > PIPEDSL > > > counter, hence no error. On the other hand, the ChromeOS kernel > > > spends > > > ~1.1 msec looping inside intel_pipe_update_start and hence errors > > > out > > > b/c the source is still in PSR. > > > > > > Regardless, we should wait for PSR exit (if PSR is supported and > > > active > > > on the current pipe) before reading the PIPEDSL, b/c if we haven't > > > fully exited PSR, then checking for vblank evasion isn't actually > > > applicable. > > > > > > This scenario applies to a configuration with an additional pipe, > > > as of now > > > > > > Signed-off-by: Tarun Vyas > > > --- > > > drivers/gpu/drm/i915/intel_sprite.c | 7 +-- > > > 1 file changed, 5 insertions(+), 2 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/i915/intel_sprite.c > > > b/drivers/gpu/drm/i915/intel_sprite.c > > > index ee23613f9fd4..481d310e5c3b 100644 > > > --- a/drivers/gpu/drm/i915/intel_sprite.c > > > +++ b/drivers/gpu/drm/i915/intel_sprite.c > > > @@ -107,14 +107,17 @@ void intel_pipe_update_start(const struct > > > intel_crtc_state *new_crtc_state) > > > VBLANK_EVASI > > > ON > > > _TIME_US); > > > max = vblank_start - 1; > > > > > > - local_irq_disable(); > > > - > > > if (min <= 0 || max <= 0) > > > return; > > > > > > if (WARN_ON(drm_crtc_vblank_get(>base))) > > > return; > > > > > > + if(new_crtc_state->has_psr && dev_priv->psr.active) > > > + psr_wait_for_idle(dev_priv); > > How about just waiting for PSR_STATUS to idle without grabbing any > > locks or checking whether PSR is active? > > > > Status should be idle if PSR was disabled or on it's way to becoming > > idle if it was enabled. Even if PSR did get enabled while we are in > > pipe_update_start(), it will not be active as long as VBIs are > > enabled. > > Right, if we are OK with some duplication (of psr_wait_for_idle) inside intel_psr.c, then we can duplicate the PSR2 vs. PSR check that's being done in psr_wait_for_idle and then just wait without grabbing any locks, so essentially a lockless version of psr_wait_for_idle() > Correct me if this was already considered, why not wait until the > scanline counter starts moving? I see we have a > intel_wait_for_pipe_scanline_moving(crtc) that's used when the > pipe is enabled. > > -DK Didn't consider this before, but, pipe_scanline_is_moving waits for a minimum of 5 msec. Are we OK with a min wait of 5 msec inside pipe_update_start ? Heuristically, waiting for PSR idle has almost always returned within < 2 msec. Occasionally it takes upto 1 full frame. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PULL] gvt-next
On Tue, Jun 19, 2018 at 05:00:43PM +0800, Zhenyu Wang wrote: > > Hi, > > Here is first gvt-next pull for next 4.19 kernel. Mostly on gvt > optimizations and has added BXT support for GVT-g. pushed to dinq. Thanks. > > Thanks. > --- > The following changes since commit 14c3f8425080a1ff97df7b81f7c339bf42c427a3: > > drm/i915: Update DRIVER_DATE to 20180606 (2018-06-06 15:10:47 -0700) > > are available in the Git repository at: > > https://github.com/intel/gvt-linux.git tags/gvt-next-2018-06-19 > > for you to fetch changes up to 57c8a484a9cbf1315b5299702d12aef04867: > > drm/i915: Enable KVMGT for BXT. (2018-06-13 10:57:30 +0800) > > > gvt-next-2018-06-19 > > - fine-grained per vgpu locking (Colin) > - fine-grained vgpu scheduler locking (Colin) > - deliver windows guest cursor hotspot info (Tina) > - GVT-g BXT support (Colin) > - other misc and checker fixes (Chris, Xinyun) > > > Chris Wilson (1): > drm/i915/gvt: Use offsetofend() rather than offsetof + sizeof > > Colin Xu (14): > drm/i915/gvt: Use vgpu_lock to protect per vgpu access > drm/i915/gvt: Use sched_lock to protect gvt scheduler logic. > drm/i915/gvt: Add D_BXT device type define for BXT. > drm/i915/gvt: Add MEDIA_POOL_STATE for BXT. > drm/i915/gvt: Enable device info initialization for BXT. > drm/i915/gvt: Enable gtt initialization for BXT. > drm/i915/gvt: Enable irq initialization for BXT. > drm/i915/gvt: Enable mmio context init and switch for BXT. > drm/i915/gvt: Enable cmd_parser support for BXT. > drm/i915/gvt: Enable force wake support for BXT. > drm/i915/gvt: Enable virtual display support for BXT. > drm/i915/gvt: Enable dma_buf support for BXT. > drm/i915/gvt: Add mmio handler for for BXT. > drm/i915: Enable KVMGT for BXT. > > Tina Zhang (1): > drm/i915/gvt: Deliver guest cursor hotspot info > > Xinyun Liu (3): > drm/i915/gvt: Avoid dereference a potential null pointer > drm/i915/gvt: removed unnecessary boundary check > drm/i915/gvt: use array to avoid potential buffer overflow > > Zhenyu Wang (1): > Merge tag 'drm-intel-next-2018-06-06' into gvt-next > > drivers/gpu/drm/i915/gvt/cmd_parser.c | 43 ++-- > drivers/gpu/drm/i915/gvt/display.c | 58 +++-- > drivers/gpu/drm/i915/gvt/dmabuf.c | 26 ++- > drivers/gpu/drm/i915/gvt/edid.c | 20 +- > drivers/gpu/drm/i915/gvt/execlist.h | 13 +- > drivers/gpu/drm/i915/gvt/fb_decoder.c | 15 +- > drivers/gpu/drm/i915/gvt/firmware.c | 2 +- > drivers/gpu/drm/i915/gvt/gtt.c | 11 +- > drivers/gpu/drm/i915/gvt/gvt.c | 27 +-- > drivers/gpu/drm/i915/gvt/gvt.h | 16 ++ > drivers/gpu/drm/i915/gvt/handlers.c | 399 > > drivers/gpu/drm/i915/gvt/interrupt.c| 17 +- > drivers/gpu/drm/i915/gvt/mmio.c | 12 +- > drivers/gpu/drm/i915/gvt/mmio.h | 11 +- > drivers/gpu/drm/i915/gvt/mmio_context.c | 16 +- > drivers/gpu/drm/i915/gvt/page_track.c | 5 +- > drivers/gpu/drm/i915/gvt/sched_policy.c | 36 ++- > drivers/gpu/drm/i915/gvt/scheduler.c| 25 +- > drivers/gpu/drm/i915/gvt/vgpu.c | 56 ++--- > drivers/gpu/drm/i915/i915_pvinfo.h | 5 +- > drivers/gpu/drm/i915/intel_gvt.c| 2 + > 21 files changed, 612 insertions(+), 203 deletions(-) > > -- > Open Source Technology Center, Intel ltd. > > $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827 ___ 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/intel_dsi: Read back and use pclk set by the GOP
== Series Details == Series: drm/i915/intel_dsi: Read back and use pclk set by the GOP URL : https://patchwork.freedesktop.org/series/45030/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4343_full -> Patchwork_9361_full = == Summary - SUCCESS == No regressions found. == Known issues == Here are the changes found in Patchwork_9361_full that come from known issues: === IGT changes === Issues hit igt@drv_suspend@shrink: shard-snb: PASS -> FAIL (fdo#106886) igt@kms_cursor_legacy@cursor-vs-flip-toggle: shard-hsw: PASS -> FAIL (fdo#103355) igt@kms_flip_tiling@flip-to-x-tiled: shard-glk: PASS -> FAIL (fdo#104724, fdo#103822) igt@kms_frontbuffer_tracking@fbc-2p-primscrn-shrfb-msflip-blt: shard-glk: PASS -> FAIL (fdo#104724, fdo#103167) igt@kms_rotation_crc@sprite-rotation-270: shard-kbl: PASS -> FAIL (fdo#104724, fdo#103925) Possible fixes igt@drv_selftest@live_gtt: shard-glk: FAIL (fdo#105347) -> PASS igt@drv_selftest@live_hangcheck: shard-kbl: DMESG-FAIL (fdo#106947, fdo#106560) -> PASS igt@gem_ctx_switch@basic-all-light: shard-hsw: INCOMPLETE (fdo#103540) -> PASS igt@gem_eio@unwedge-stress: shard-glk: FAIL (fdo#105957) -> PASS igt@kms_flip@2x-flip-vs-blocking-wf-vblank: shard-glk: FAIL (fdo#100368) -> PASS +1 igt@kms_setmode@basic: shard-apl: FAIL (fdo#99912) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#103355 https://bugs.freedesktop.org/show_bug.cgi?id=103355 fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540 fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822 fdo#103925 https://bugs.freedesktop.org/show_bug.cgi?id=103925 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#105347 https://bugs.freedesktop.org/show_bug.cgi?id=105347 fdo#105957 https://bugs.freedesktop.org/show_bug.cgi?id=105957 fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560 fdo#106886 https://bugs.freedesktop.org/show_bug.cgi?id=106886 fdo#106947 https://bugs.freedesktop.org/show_bug.cgi?id=106947 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4343 -> Patchwork_9361 CI_DRM_4343: 93475d62c73031c5b4625eaa64b5c0f4079b2f3f @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4524: 9ab9268fa7eeda0a7ea6eb2ab02bb6c5b9c91ba0 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9361: 915eb9ec85f900ad1d71307f8a1a1c71d9570c9c @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9361/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Wait for PSR exit before checking for vblank evasion
On Tue, 2018-06-19 at 14:27 -0700, Dhinakaran Pandiyan wrote: > On Mon, 2018-05-14 at 13:49 -0700, Tarun Vyas wrote: > > > > The PIPEDSL freezes on PSR entry and if PSR hasn't fully exited, > > then > > the pipe_update_start call schedules itself out to check back > > later. > > > > On ChromeOS-4.4 kernel, which is fairly up-to-date w.r.t drm/i915 > > but > > lags w.r.t core kernel code, hot plugging an external display > > triggers > > tons of "potential atomic update errors" in the dmesg, on *pipe A*. > > A > > closer analysis reveals that we try to read the scanline 3 times > > and > > eventually timeout, b/c PSR hasn't exited fully leading to a > > PIPEDSL > > stuck @ 1599. This issue is not seen on upstream kernels, b/c for > > *some* > > reason we loop inside intel_pipe_update start for ~2+ msec which in > > this > > case is more than enough to exit PSR fully, hence an *unstuck* > > PIPEDSL > > counter, hence no error. On the other hand, the ChromeOS kernel > > spends > > ~1.1 msec looping inside intel_pipe_update_start and hence errors > > out > > b/c the source is still in PSR. > > > > Regardless, we should wait for PSR exit (if PSR is supported and > > active > > on the current pipe) before reading the PIPEDSL, b/c if we haven't > > fully exited PSR, then checking for vblank evasion isn't actually > > applicable. > > > > This scenario applies to a configuration with an additional pipe, > > as of now > > > > Signed-off-by: Tarun Vyas > > --- > > drivers/gpu/drm/i915/intel_sprite.c | 7 +-- > > 1 file changed, 5 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/intel_sprite.c > > b/drivers/gpu/drm/i915/intel_sprite.c > > index ee23613f9fd4..481d310e5c3b 100644 > > --- a/drivers/gpu/drm/i915/intel_sprite.c > > +++ b/drivers/gpu/drm/i915/intel_sprite.c > > @@ -107,14 +107,17 @@ void intel_pipe_update_start(const struct > > intel_crtc_state *new_crtc_state) > > VBLANK_EVASI > > ON > > _TIME_US); > > max = vblank_start - 1; > > > > - local_irq_disable(); > > - > > if (min <= 0 || max <= 0) > > return; > > > > if (WARN_ON(drm_crtc_vblank_get(>base))) > > return; > > > > + if(new_crtc_state->has_psr && dev_priv->psr.active) > > + psr_wait_for_idle(dev_priv); > How about just waiting for PSR_STATUS to idle without grabbing any > locks or checking whether PSR is active? > > Status should be idle if PSR was disabled or on it's way to becoming > idle if it was enabled. Even if PSR did get enabled while we are in > pipe_update_start(), it will not be active as long as VBIs are > enabled. > Correct me if this was already considered, why not wait until the scanline counter starts moving? I see we have a intel_wait_for_pipe_scanline_moving(crtc) that's used when the pipe is enabled. -DK ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Wait for PSR exit before checking for vblank evasion
On Mon, 2018-05-14 at 13:49 -0700, Tarun Vyas wrote: > The PIPEDSL freezes on PSR entry and if PSR hasn't fully exited, then > the pipe_update_start call schedules itself out to check back later. > > On ChromeOS-4.4 kernel, which is fairly up-to-date w.r.t drm/i915 but > lags w.r.t core kernel code, hot plugging an external display > triggers > tons of "potential atomic update errors" in the dmesg, on *pipe A*. A > closer analysis reveals that we try to read the scanline 3 times and > eventually timeout, b/c PSR hasn't exited fully leading to a PIPEDSL > stuck @ 1599. This issue is not seen on upstream kernels, b/c for > *some* > reason we loop inside intel_pipe_update start for ~2+ msec which in > this > case is more than enough to exit PSR fully, hence an *unstuck* > PIPEDSL > counter, hence no error. On the other hand, the ChromeOS kernel > spends > ~1.1 msec looping inside intel_pipe_update_start and hence errors out > b/c the source is still in PSR. > > Regardless, we should wait for PSR exit (if PSR is supported and > active > on the current pipe) before reading the PIPEDSL, b/c if we haven't > fully exited PSR, then checking for vblank evasion isn't actually > applicable. > > This scenario applies to a configuration with an additional pipe, > as of now > > Signed-off-by: Tarun Vyas > --- > drivers/gpu/drm/i915/intel_sprite.c | 7 +-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_sprite.c > b/drivers/gpu/drm/i915/intel_sprite.c > index ee23613f9fd4..481d310e5c3b 100644 > --- a/drivers/gpu/drm/i915/intel_sprite.c > +++ b/drivers/gpu/drm/i915/intel_sprite.c > @@ -107,14 +107,17 @@ void intel_pipe_update_start(const struct > intel_crtc_state *new_crtc_state) > VBLANK_EVASION > _TIME_US); > max = vblank_start - 1; > > - local_irq_disable(); > - > if (min <= 0 || max <= 0) > return; > > if (WARN_ON(drm_crtc_vblank_get(>base))) > return; > > + if(new_crtc_state->has_psr && dev_priv->psr.active) > + psr_wait_for_idle(dev_priv); How about just waiting for PSR_STATUS to idle without grabbing any locks or checking whether PSR is active? Status should be idle if PSR was disabled or on it's way to becoming idle if it was enabled. Even if PSR did get enabled while we are in pipe_update_start(), it will not be active as long as VBIs are enabled. > + > + local_irq_disable(); > + > crtc->debug.min_vbl = min; > crtc->debug.max_vbl = max; > trace_i915_pipe_update_start(crtc); ___ 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/intel_dsi: Read back and use pclk set by the GOP
== Series Details == Series: drm/i915/intel_dsi: Read back and use pclk set by the GOP URL : https://patchwork.freedesktop.org/series/45030/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4343 -> Patchwork_9361 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/45030/revisions/1/mbox/ == Known issues == Here are the changes found in Patchwork_9361 that come from known issues: === IGT changes === Issues hit igt@kms_flip@basic-flip-vs-dpms: fi-glk-j4005: PASS -> DMESG-WARN (fdo#106097) igt@kms_flip@basic-flip-vs-modeset: fi-glk-j4005: PASS -> DMESG-WARN (fdo#106000) igt@pm_rpm@basic-rte: fi-glk-j4005: PASS -> DMESG-WARN (fdo#106000, fdo#106745) Possible fixes igt@kms_flip@basic-flip-vs-wf_vblank: fi-glk-j4005: FAIL (fdo#100368) -> PASS igt@kms_flip@basic-plain-flip: fi-glk-j4005: DMESG-WARN (fdo#106000) -> PASS igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: fi-glk-j4005: DMESG-WARN (fdo#106097) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#106000 https://bugs.freedesktop.org/show_bug.cgi?id=106000 fdo#106097 https://bugs.freedesktop.org/show_bug.cgi?id=106097 fdo#106745 https://bugs.freedesktop.org/show_bug.cgi?id=106745 == Participating hosts (42 -> 38) == Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-bsw-cyan fi-hsw-4200u == Build changes == * Linux: CI_DRM_4343 -> Patchwork_9361 CI_DRM_4343: 93475d62c73031c5b4625eaa64b5c0f4079b2f3f @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4524: 9ab9268fa7eeda0a7ea6eb2ab02bb6c5b9c91ba0 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9361: 915eb9ec85f900ad1d71307f8a1a1c71d9570c9c @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 915eb9ec85f9 drm/i915/intel_dsi: Read back pclk set by GOP and use that as pclk 090b93fcce9f drm/i915/intel_dsi: Make intel_connector_get_hw_state() non static 5142b2daabed drm/i915/intel_dsi: Move initialization of encoder variables up a bit 8327a1b70388 drm/i915/intel_dsi: Allow calling intel_dsi_get_pclk with a NULL config == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9361/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 26/24] drm/i915/icl: Add allowed DP rates for Icelake
On Thu, Jun 14, 2018 at 12:23:36PM -0700, Rodrigo Vivi wrote:
> On Thu, May 24, 2018 at 04:42:37PM -0700, Paulo Zanoni wrote:
> > From: Manasi Navare
> >
> > For ICL, on Combo PHY the allowed max rates are:
> > - HBR3 8.1 eDP (DDIA)
> > - HBR2 5.4 DisplayPort (DDIB)
> > and for MG PHY/TC DDI Ports allowed DP rates are:
> > - HBR3 8.1 DisplayPort (DP alternate mode, DP over TBT,
> > - DP on legacy connector - DDIC/D/E/F)
> >
> > Cc: Rodrigo Vivi
> > Cc: Jani Nikula
> > Cc: James Ausmus
> > Signed-off-by: Manasi Navare
> > Signed-off-by: James Ausmus
> > ---
> > drivers/gpu/drm/i915/intel_dp.c | 21 +++--
> > 1 file changed, 19 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 5109023abe28..3ee8e74cf2b8 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -419,6 +419,20 @@ static int cnl_max_source_rate(struct intel_dp
> > *intel_dp)
> > return 81;
> > }
> >
> > +static int icl_max_source_rate(struct intel_dp *intel_dp)
> > +{
> > + struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> > + enum port port = dig_port->base.port;
> > +
> > + /* On Combo PHY port A max speed is HBR3 for all Vccio voltages
> > +* and on Combo PHY Port B the maximum supported is HBR2.
> > +*/
> > + if (port == PORT_B)
>
> A more generic way here would be COMBO and !eDP
Yes I can use the function intel_is_port_combophy() but I dont see that merged
yet
Will have to wait to spin this patch in that case.
>
> > + return 54;
> > +
> > + return 81;
> > +}
> > +
> > static void
> > intel_dp_set_source_rates(struct intel_dp *intel_dp)
> > {
> > @@ -448,10 +462,13 @@ intel_dp_set_source_rates(struct intel_dp *intel_dp)
> > /* This should only be done once */
> > WARN_ON(intel_dp->source_rates || intel_dp->num_source_rates);
> >
> > - if (IS_CANNONLAKE(dev_priv)) {
> > + if (INTEL_GEN(dev_priv) >= 10) {
> > source_rates = cnl_rates;
> > size = ARRAY_SIZE(cnl_rates);
> > - max_rate = cnl_max_source_rate(intel_dp);
> > + if (IS_ICELAKE(dev_priv))
>
> and gen >= 11
>
> but changes can be in follow-up work, so
Yes will change that to use >= 11
Manasi
>
> Reviewed-by: Rodrigo Vivi
>
> > + max_rate = icl_max_source_rate(intel_dp);
> > + else
> > + max_rate = cnl_max_source_rate(intel_dp);
> > } else if (IS_GEN9_LP(dev_priv)) {
> > source_rates = bxt_rates;
> > size = ARRAY_SIZE(bxt_rates);
> > --
> > 2.14.3
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/4] drm/i915/intel_dsi: Read back pclk set by GOP and use that as pclk
On BYT and CHT the GOP sometimes initializes the pclk at a (slightly)
different frequency then the pclk which we've calculated.
This commit makes the DSI code read-back the pclk set by the GOP and
if that is within a reasonable margin of the calculated pclk, uses
that instead.
This fixes the first modeset being a full modeset instead of a
fast modeset on systems where the GOP pclk is different.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/intel_dsi_vbt.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dsi_vbt.c
b/drivers/gpu/drm/i915/intel_dsi_vbt.c
index 4d6ffa7b3e7b..d4cc6099012c 100644
--- a/drivers/gpu/drm/i915/intel_dsi_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_vbt.c
@@ -517,6 +517,7 @@ bool intel_dsi_vbt_init(struct intel_dsi *intel_dsi, u16
panel_id)
u32 mul;
u16 burst_mode_ratio;
enum port port;
+ enum pipe pipe;
DRM_DEBUG_KMS("\n");
@@ -583,6 +584,19 @@ bool intel_dsi_vbt_init(struct intel_dsi *intel_dsi, u16
panel_id)
} else
burst_mode_ratio = 100;
+ /*
+* On BYT / CRC the GOP sometimes picks a slightly different pclk,
+* read back the GOP configured pclk and prefer it over ours.
+*/
+ if ((IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) &&
+ intel_dsi_get_hw_state(_dsi->base, )) {
+ u32 gop = intel_dsi_get_pclk(_dsi->base, bpp, NULL);
+
+ DRM_DEBUG_KMS("Calculated pclk %d GOP %d\n", pclk, gop);
+ if (gop >= (pclk * 9 / 10) && gop <= (pclk * 11 / 10))
+ pclk = gop;
+ }
+
intel_dsi->burst_mode_ratio = burst_mode_ratio;
intel_dsi->pclk = pclk;
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/4] drm/i915/intel_dsi: Move initialization of encoder variables up a bit
Move the initialization of encoder variables a bit higher inside the intel_dsi_init() function. So that the encoder can safely be passed to intel_connector_get_hw_state() inside intel_dsi_vbt_init(). This is a preparation patch for reading back the GOP configured pclk from intel_dsi_vbt_init(). Signed-off-by: Hans de Goede --- drivers/gpu/drm/i915/intel_dsi.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c index 3b7acb5a70b3..103fe460f78c 100644 --- a/drivers/gpu/drm/i915/intel_dsi.c +++ b/drivers/gpu/drm/i915/intel_dsi.c @@ -1769,6 +1769,9 @@ void intel_dsi_init(struct drm_i915_private *dev_priv) intel_connector->get_hw_state = intel_connector_get_hw_state; intel_encoder->port = port; + intel_encoder->type = INTEL_OUTPUT_DSI; + intel_encoder->power_domain = POWER_DOMAIN_PORT_DSI; + intel_encoder->cloneable = 0; /* * On BYT/CHV, pipe A maps to MIPI DSI port A, pipe B maps to MIPI DSI @@ -1820,9 +1823,6 @@ void intel_dsi_init(struct drm_i915_private *dev_priv) } } - intel_encoder->type = INTEL_OUTPUT_DSI; - intel_encoder->power_domain = POWER_DOMAIN_PORT_DSI; - intel_encoder->cloneable = 0; drm_connector_init(dev, connector, _dsi_connector_funcs, DRM_MODE_CONNECTOR_DSI); -- 2.17.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/4] drm/i915/intel_dsi: Read back and use pclk set by the GOP
Hi All, This patch-set is the result of the work I've been doing recently to give people a smooth "flickerfree" boot experience where the display keeps displaying the logo put there by the firmware until it smoothly fades into the Linux GUI (e.g. gdm). While testing this on some BYT/CHT devices I noticed the screen going black for 1 second or so, because the first modeset was not a fast modeset despite passing i915.fastboot=1 on the kernel commandline. This is caused by the GOP and the i915 code differing in what they think the DSI pclk should be. This patch-set fixes this by reading back the pclk set by the GOP and if it is reasonably close to the clk calculated by the i915 code, using the GOP set pclk. Regards, Hans ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/4] drm/i915/intel_dsi: Make intel_connector_get_hw_state() non static
Make intel_connector_get_hw_state() non static so that it can be called
from the intel_dsi_vbt.c code.
This is a preparation patch for reading back the GOP configured pclk
from intel_dsi_vbt_init().
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/intel_dsi.c | 3 +--
drivers/gpu/drm/i915/intel_dsi.h | 1 +
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 103fe460f78c..5e2bb13f7b6d 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -1005,8 +1005,7 @@ static void intel_dsi_post_disable(struct intel_encoder
*encoder,
intel_dsi_msleep(intel_dsi, intel_dsi->panel_pwr_cycle_delay);
}
-static bool intel_dsi_get_hw_state(struct intel_encoder *encoder,
- enum pipe *pipe)
+bool intel_dsi_get_hw_state(struct intel_encoder *encoder, enum pipe *pipe)
{
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
struct intel_dsi *intel_dsi = enc_to_intel_dsi(>base);
diff --git a/drivers/gpu/drm/i915/intel_dsi.h b/drivers/gpu/drm/i915/intel_dsi.h
index 7afeb9580f41..34ce3ef395ef 100644
--- a/drivers/gpu/drm/i915/intel_dsi.h
+++ b/drivers/gpu/drm/i915/intel_dsi.h
@@ -132,6 +132,7 @@ static inline struct intel_dsi *enc_to_intel_dsi(struct
drm_encoder *encoder)
/* intel_dsi.c */
void wait_for_dsi_fifo_empty(struct intel_dsi *intel_dsi, enum port port);
enum mipi_dsi_pixel_format pixel_format_from_register_bits(u32 fmt);
+bool intel_dsi_get_hw_state(struct intel_encoder *encoder, enum pipe *pipe);
/* intel_dsi_pll.c */
bool intel_dsi_pll_is_enabled(struct drm_i915_private *dev_priv);
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/4] drm/i915/intel_dsi: Allow calling intel_dsi_get_pclk with a NULL config
Allow calling intel_dsi_get_pclk without passing in an intel_crtc_state.
This is a preparation patch for reading back the GOP configured DSI
clk during probe.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/intel_dsi_pll.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi_pll.c
b/drivers/gpu/drm/i915/intel_dsi_pll.c
index 2ff2ee7f3b78..71ce6e3157d4 100644
--- a/drivers/gpu/drm/i915/intel_dsi_pll.c
+++ b/drivers/gpu/drm/i915/intel_dsi_pll.c
@@ -279,8 +279,10 @@ static u32 vlv_dsi_get_pclk(struct intel_encoder *encoder,
int pipe_bpp,
pll_div = vlv_cck_read(dev_priv, CCK_REG_DSI_PLL_DIVIDER);
mutex_unlock(_priv->sb_lock);
- config->dsi_pll.ctrl = pll_ctl & ~DSI_PLL_LOCK;
- config->dsi_pll.div = pll_div;
+ if (config) {
+ config->dsi_pll.ctrl = pll_ctl & ~DSI_PLL_LOCK;
+ config->dsi_pll.div = pll_div;
+ }
/* mask out other bits and extract the P1 divisor */
pll_ctl &= DSI_PLL_P1_POST_DIV_MASK;
@@ -330,6 +332,7 @@ static u32 vlv_dsi_get_pclk(struct intel_encoder *encoder,
int pipe_bpp,
static u32 bxt_dsi_get_pclk(struct intel_encoder *encoder, int pipe_bpp,
struct intel_crtc_state *config)
{
+ u32 ctrl;
u32 pclk;
u32 dsi_clk;
u32 dsi_ratio;
@@ -342,9 +345,12 @@ static u32 bxt_dsi_get_pclk(struct intel_encoder *encoder,
int pipe_bpp,
return 0;
}
- config->dsi_pll.ctrl = I915_READ(BXT_DSI_PLL_CTL);
+ ctrl = I915_READ(BXT_DSI_PLL_CTL);
+
+ if (config)
+ config->dsi_pll.ctrl = ctrl;
- dsi_ratio = config->dsi_pll.ctrl & BXT_DSI_PLL_RATIO_MASK;
+ dsi_ratio = ctrl & BXT_DSI_PLL_RATIO_MASK;
dsi_clk = (dsi_ratio * BXT_REF_CLOCK_KHZ) / 2;
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/icl: Add remaining registers and bitfields for MG PHY DDI
Paulo could you review this patch, I need these defs for the next revision
of MG PHY DDI programming new revision.
Manasi
On Tue, May 15, 2018 at 05:53:01PM -0700, Manasi Navare wrote:
> This patch adds the remaining register definitions and bit fields
> required for MG PHy DDI buffer initializations and voltage
> swing programming for MG PHy DDI ports.
>
> While at it this patch also fixes the naming for previously defined
> MG PHY registers in original commit id (c92f47b5ec977a "drm/i915/icl:
> Add register defs for voltage swing sequences for MG PHY DDI").
> Since the MG PHY registers are first defined in ICL platform, there
> is no need for _ICL prefix.
>
> Signed-off-by: Manasi Navare
> Cc: Paulo Zanoni
> Cc: James Ausmus
> ---
> drivers/gpu/drm/i915/i915_reg.h | 243
> +++-
> 1 file changed, 142 insertions(+), 101 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index f11bb21..a93b796 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1827,121 +1827,162 @@ enum i915_power_well_id {
> #define N_SCALAR(x)((x) << 24)
> #define N_SCALAR_MASK (0x7F << 24)
>
> -#define _ICL_MG_PHY_PORT_LN(port, ln, ln0p1, ln0p2, ln1p1) \
> +#define MG_PHY_PORT_LN(port, ln, ln0p1, ln0p2, ln1p1) \
> _MMIO(_PORT((port) - PORT_C, ln0p1, ln0p2) + (ln) * ((ln1p1) - (ln0p1)))
>
> -#define _ICL_MG_TX_LINK_PARAMS_TX1LN0_PORT1 0x16812C
> -#define _ICL_MG_TX_LINK_PARAMS_TX1LN1_PORT1 0x16852C
> -#define _ICL_MG_TX_LINK_PARAMS_TX1LN0_PORT2 0x16912C
> -#define _ICL_MG_TX_LINK_PARAMS_TX1LN1_PORT2 0x16952C
> -#define _ICL_MG_TX_LINK_PARAMS_TX1LN0_PORT3 0x16A12C
> -#define _ICL_MG_TX_LINK_PARAMS_TX1LN1_PORT3 0x16A52C
> -#define _ICL_MG_TX_LINK_PARAMS_TX1LN0_PORT4 0x16B12C
> -#define _ICL_MG_TX_LINK_PARAMS_TX1LN1_PORT4 0x16B52C
> -#define ICL_PORT_MG_TX1_LINK_PARAMS(port, ln) \
> - _ICL_MG_PHY_PORT_LN(port, ln, _ICL_MG_TX_LINK_PARAMS_TX1LN0_PORT1, \
> - _ICL_MG_TX_LINK_PARAMS_TX1LN0_PORT2, \
> - _ICL_MG_TX_LINK_PARAMS_TX1LN1_PORT1)
> -
> -#define _ICL_MG_TX_LINK_PARAMS_TX2LN0_PORT1 0x1680AC
> -#define _ICL_MG_TX_LINK_PARAMS_TX2LN1_PORT1 0x1684AC
> -#define _ICL_MG_TX_LINK_PARAMS_TX2LN0_PORT2 0x1690AC
> -#define _ICL_MG_TX_LINK_PARAMS_TX2LN1_PORT2 0x1694AC
> -#define _ICL_MG_TX_LINK_PARAMS_TX2LN0_PORT3 0x16A0AC
> -#define _ICL_MG_TX_LINK_PARAMS_TX2LN1_PORT3 0x16A4AC
> -#define _ICL_MG_TX_LINK_PARAMS_TX2LN0_PORT4 0x16B0AC
> -#define _ICL_MG_TX_LINK_PARAMS_TX2LN1_PORT4 0x16B4AC
> -#define ICL_PORT_MG_TX2_LINK_PARAMS(port, ln) \
> - _ICL_MG_PHY_PORT_LN(port, ln, _ICL_MG_TX_LINK_PARAMS_TX2LN0_PORT1, \
> - _ICL_MG_TX_LINK_PARAMS_TX2LN0_PORT2, \
> - _ICL_MG_TX_LINK_PARAMS_TX2LN1_PORT1)
> +#define MG_TX_LINK_PARAMS_TX1LN0_PORT1 0x16812C
> +#define MG_TX_LINK_PARAMS_TX1LN1_PORT1 0x16852C
> +#define MG_TX_LINK_PARAMS_TX1LN0_PORT2 0x16912C
> +#define MG_TX_LINK_PARAMS_TX1LN1_PORT2 0x16952C
> +#define MG_TX_LINK_PARAMS_TX1LN0_PORT3 0x16A12C
> +#define MG_TX_LINK_PARAMS_TX1LN1_PORT3 0x16A52C
> +#define MG_TX_LINK_PARAMS_TX1LN0_PORT4 0x16B12C
> +#define _MG_TX_LINK_PARAMS_TX1LN1_PORT4 0x16B52C
> +#define MG_TX1_LINK_PARAMS(port, ln) \
> + MG_PHY_PORT_LN(port, ln, MG_TX_LINK_PARAMS_TX1LN0_PORT1, \
> + MG_TX_LINK_PARAMS_TX1LN0_PORT2, \
> + MG_TX_LINK_PARAMS_TX1LN1_PORT1)
> +
> +#define MG_TX_LINK_PARAMS_TX2LN0_PORT1 0x1680AC
> +#define MG_TX_LINK_PARAMS_TX2LN1_PORT1 0x1684AC
> +#define MG_TX_LINK_PARAMS_TX2LN0_PORT2 0x1690AC
> +#define MG_TX_LINK_PARAMS_TX2LN1_PORT2 0x1694AC
> +#define MG_TX_LINK_PARAMS_TX2LN0_PORT3 0x16A0AC
> +#define MG_TX_LINK_PARAMS_TX2LN1_PORT3 0x16A4AC
> +#define MG_TX_LINK_PARAMS_TX2LN0_PORT4 0x16B0AC
> +#define MG_TX_LINK_PARAMS_TX2LN1_PORT4 0x16B4AC
> +#define MG_TX2_LINK_PARAMS(port, ln) \
> + MG_PHY_PORT_LN(port, ln, MG_TX_LINK_PARAMS_TX2LN0_PORT1, \
> + MG_TX_LINK_PARAMS_TX2LN0_PORT2, \
> + MG_TX_LINK_PARAMS_TX2LN1_PORT1)
> #define CRI_USE_FS32 (1 << 5)
>
> -#define _ICL_MG_TX_PISO_READLOAD_TX1LN0_PORT10x16814C
> -#define _ICL_MG_TX_PISO_READLOAD_TX1LN1_PORT10x16854C
> -#define _ICL_MG_TX_PISO_READLOAD_TX1LN0_PORT20x16914C
> -#define _ICL_MG_TX_PISO_READLOAD_TX1LN1_PORT20x16954C
> -#define _ICL_MG_TX_PISO_READLOAD_TX1LN0_PORT3
Re: [Intel-gfx] [PATCH v2] drm/i915: remove check for aux irq
On Tue, 2018-06-19 at 08:24 -0700, Lucas De Marchi wrote:
> On Tue, Jun 19, 2018 at 7:06 AM Ville Syrjälä
> wrote:
> >
> >
> > On Fri, Jun 15, 2018 at 02:51:06PM -0700, Lucas De Marchi wrote:
> > >
> > > On Fri, Jun 15, 2018 at 08:58:28PM +0300, Ville Syrjälä wrote:
> > > >
> > > > On Wed, May 23, 2018 at 11:04:35AM -0700, Lucas De Marchi
> > > > wrote:
> > > > >
> > > > > This became dead code with commit 309bd8ed464f ("drm/i915:
> > > > > Reinstate
> > > > > GMBUS and AUX interrupts on gen4/g4x").
> > > > >
> > > > > v2: Move comment about HW behavior to where decision is made
> > > > > to enable
> > > > > MSI (Ville).
> > > > >
> > > > > Cc: Ville Syrjälä
> > > > > Signed-off-by: Lucas De Marchi
> > > > > ---
> > > > > drivers/gpu/drm/i915/i915_drv.c | 6 ++
> > > > > drivers/gpu/drm/i915/i915_drv.h | 10 --
> > > > > drivers/gpu/drm/i915/intel_dp.c | 22 +++---
> > > > > drivers/gpu/drm/i915/intel_drv.h | 1 -
> > > > > drivers/gpu/drm/i915/intel_psr.c | 2 +-
> > > > > 5 files changed, 14 insertions(+), 27 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.c
> > > > > b/drivers/gpu/drm/i915/i915_drv.c
> > > > > index 9c449b8d8eab..a1461de20472 100644
> > > > > --- a/drivers/gpu/drm/i915/i915_drv.c
> > > > > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > > > > @@ -1189,6 +1189,12 @@ static int i915_driver_init_hw(struct
> > > > > drm_i915_private *dev_priv)
> > > > > * get lost on g4x as well, and interrupt delivery seems to
> > > > > stay
> > > > > * properly dead afterwards. So we'll just disable them for
> > > > > all
> > > > > * pre-gen5 chipsets.
> > > > > + *
> > > > > + * dp aux and gmbus irq on gen4 seems to be able to
> > > > > generate legacy
> > > > > + * interrupts even when in MSI mode. This results in
> > > > > spurious
> > > > > + * interrupt warnings if the legacy irq no. is shared with
> > > > > another
> > > > > + * device. The kernel then disables that interrupt source
> > > > > and so
> > > > > + * prevents the other device from working properly.
> > > > > */
> > > > > if (INTEL_GEN(dev_priv) >= 5) {
> > > > > if (pci_enable_msi(pdev) < 0)
> > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > > > b/drivers/gpu/drm/i915/i915_drv.h
> > > > > index b86ed6401120..c5e1f648c47c 100644
> > > > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > > @@ -2558,16 +2558,6 @@ intel_info(const struct
> > > > > drm_i915_private *dev_priv)
> > > > > (IS_CANNONLAKE(dev_priv) || \
> > > > > IS_SKL_GT3(dev_priv) || IS_SKL_GT4(dev_priv))
> > > > >
> > > > > -/*
> > > > > - * dp aux and gmbus irq on gen4 seems to be able to generate
> > > > > legacy interrupts
> > > > > - * even when in MSI mode. This results in spurious interrupt
> > > > > warnings if the
> > > > > - * legacy irq no. is shared with another device. The kernel
> > > > > then disables that
> > > > > - * interrupt source and so prevents the other device from
> > > > > working properly.
> > > > > - *
> > > > > - * Since we don't enable MSI anymore on gen4, we can always
> > > > > use GMBUS/AUX
> > > > > - * interrupts.
> > > > > - */
> > > > > -#define HAS_AUX_IRQ(dev_priv) true
> > > > > #define HAS_GMBUS_IRQ(dev_priv) (INTEL_GEN(dev_priv) >= 4)
> > > > >
> > > > > /* With the 945 and later, Y tiling got adjusted so that it
> > > > > was 32 128-byte
> > > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > > > b/drivers/gpu/drm/i915/intel_dp.c
> > > > > index ce07bd794aed..1dab40056df7 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > > > @@ -936,7 +936,7 @@ intel_dp_check_edp(struct intel_dp
> > > > > *intel_dp)
> > > > > }
> > > > >
> > > > > static uint32_t
> > > > > -intel_dp_aux_wait_done(struct intel_dp *intel_dp, bool
> > > > > has_aux_irq)
> > > > > +intel_dp_aux_wait_done(struct intel_dp *intel_dp)
> > > > > {
> > > > > struct drm_i915_private *dev_priv =
> > > > > to_i915(intel_dp_to_dev(intel_dp));
> > > > > i915_reg_t ch_ctl = intel_dp->aux_ch_ctl_reg(intel_dp);
> > > > > @@ -944,14 +944,10 @@ intel_dp_aux_wait_done(struct intel_dp
> > > > > *intel_dp, bool has_aux_irq)
> > > > > bool done;
> > > > >
> > > > > #define C (((status = I915_READ_NOTRACE(ch_ctl)) &
> > > > > DP_AUX_CH_CTL_SEND_BUSY) == 0)
> > > > > - if (has_aux_irq)
> > > > > - done = wait_event_timeout(dev_priv-
> > > > > >gmbus_wait_queue, C,
> > > > > - msecs_to_jiffies_timeout(
> > > > > 10));
> > > > > - else
> > > > > - done = wait_for(C, 10) == 0;
> > > > > + done = wait_event_timeout(dev_priv->gmbus_wait_queue, C,
> > > > > + msecs_to_jiffies_timeout(10));
> > > > > if (!done)
> > > > > - DRM_ERROR("dp aux hw did not signal timeout (has
> > > > > irq: %i)!\n",
> > > > > - has_aux_irq);
> > > > > + DRM_ERROR("dp aux hw
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 1/2] lib: Spin fast, sweet chariot, coming to carry me home
On 19/06/18 06:55, Chris Wilson wrote:
When using the pollable spinner, we often want to use it as a means of
ensuring the task is running on the GPU before switching to something
else. In which case we don't want to add extra delay inside the spinner,
but the current 1000 NOPs add on order of 5us, which is often larger
than the target latency.
Signed-off-by: Chris Wilson
Reviewed-by: Antonio Argenziano
---
lib/igt_dummyload.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/lib/igt_dummyload.c b/lib/igt_dummyload.c
index d32b421c6..b090b8004 100644
--- a/lib/igt_dummyload.c
+++ b/lib/igt_dummyload.c
@@ -78,6 +78,7 @@ fill_reloc(struct drm_i915_gem_relocation_entry *reloc,
#define OUT_FENCE (1 << 0)
#define POLL_RUN (1 << 1)
#define NO_PREEMPTION (1 << 2)
+#define SPIN_FAST (1 << 3)
static int
emit_recursive_batch(igt_spin_t *spin, int fd, uint32_t ctx, unsigned engine,
@@ -212,7 +213,8 @@ emit_recursive_batch(igt_spin_t *spin, int fd, uint32_t
ctx, unsigned engine,
* between function calls, that appears enough to keep SNB out of
* trouble. See https://bugs.freedesktop.org/show_bug.cgi?id=102262
*/
- batch += 1000;
+ if (!(flags & SPIN_FAST))
+ batch += 1000;
/* recurse */
r = [obj[BATCH].relocation_count++];
@@ -369,7 +371,7 @@ igt_spin_batch_new_fence(int fd, uint32_t ctx, unsigned
engine)
igt_spin_t *
__igt_spin_batch_new_poll(int fd, uint32_t ctx, unsigned engine)
{
- return ___igt_spin_batch_new(fd, ctx, engine, 0, POLL_RUN);
+ return ___igt_spin_batch_new(fd, ctx, engine, 0, POLL_RUN | SPIN_FAST);
}
igt_spin_t *
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915/icl: Fix MG PLL setup when refclk is 38.4MHz (rev3)
== Series Details == Series: series starting with [1/2] drm/i915/icl: Fix MG PLL setup when refclk is 38.4MHz (rev3) URL : https://patchwork.freedesktop.org/series/44836/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4343 -> Patchwork_9360 = == Summary - FAILURE == Serious unknown changes coming with Patchwork_9360 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9360, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/44836/revisions/3/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9360: === IGT changes === Possible regressions igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b: fi-glk-j4005: PASS -> FAIL == Known issues == Here are the changes found in Patchwork_9360 that come from known issues: === IGT changes === Issues hit igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: fi-snb-2520m: PASS -> INCOMPLETE (fdo#103713) Possible fixes igt@kms_flip@basic-plain-flip: fi-glk-j4005: DMESG-WARN (fdo#106000) -> PASS igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: fi-glk-j4005: DMESG-WARN (fdo#106097) -> PASS fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fdo#106000 https://bugs.freedesktop.org/show_bug.cgi?id=106000 fdo#106097 https://bugs.freedesktop.org/show_bug.cgi?id=106097 == Participating hosts (42 -> 38) == Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-bsw-cyan fi-hsw-4200u == Build changes == * Linux: CI_DRM_4343 -> Patchwork_9360 CI_DRM_4343: 93475d62c73031c5b4625eaa64b5c0f4079b2f3f @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4524: 9ab9268fa7eeda0a7ea6eb2ab02bb6c5b9c91ba0 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9360: 01529685e7fbbd57d3f7de473799a45bcd0783e0 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 01529685e7fb drm/i915/icl: Do read-modify-write as needed during MG PLL programming e89ce575e104 drm/i915/icl: Fix MG PLL setup when refclk is 38.4MHz == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9360/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 2/2] drm/i915/icl: Do read-modify-write as needed during MG PLL programming
Some MG PLL registers have fields that need to be preserved at their HW
default or BIOS programmed values. So make sure we preserve them.
v2:
- Add comment to icl_mg_pll_write() explaining the need for register
masks. (Vandita)
- Fix patchwork checkpatch warning.
v3:
- Rebase on drm-tip.
Cc: Vandita Kulkarni
Cc: Paulo Zanoni
Cc: James Ausmus
Signed-off-by: Imre Deak
Reviewed-by: James Ausmus (v1)
---
drivers/gpu/drm/i915/i915_reg.h | 13
drivers/gpu/drm/i915/intel_dpll_mgr.c | 39 +++
2 files changed, 48 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 4bfd7a9bd75f..65b87ee4 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -9047,6 +9047,7 @@ enum skl_power_gate {
#define _MG_REFCLKIN_CTL_PORT3 0x16A92C
#define _MG_REFCLKIN_CTL_PORT4 0x16B92C
#define MG_REFCLKIN_CTL_OD_2_MUX(x) ((x) << 8)
+#define MG_REFCLKIN_CTL_OD_2_MUX_MASK(0x7 << 8)
#define MG_REFCLKIN_CTL(port) _MMIO_PORT((port) - PORT_C, \
_MG_REFCLKIN_CTL_PORT1, \
_MG_REFCLKIN_CTL_PORT2)
@@ -9056,7 +9057,9 @@ enum skl_power_gate {
#define _MG_CLKTOP2_CORECLKCTL1_PORT3 0x16A8D8
#define _MG_CLKTOP2_CORECLKCTL1_PORT4 0x16B8D8
#define MG_CLKTOP2_CORECLKCTL1_B_DIVRATIO(x) ((x) << 16)
+#define MG_CLKTOP2_CORECLKCTL1_B_DIVRATIO_MASK (0xff << 16)
#define MG_CLKTOP2_CORECLKCTL1_A_DIVRATIO(x) ((x) << 8)
+#define MG_CLKTOP2_CORECLKCTL1_A_DIVRATIO_MASK (0xff << 8)
#define MG_CLKTOP2_CORECLKCTL1(port) _MMIO_PORT((port) - PORT_C, \
_MG_CLKTOP2_CORECLKCTL1_PORT1, \
_MG_CLKTOP2_CORECLKCTL1_PORT2)
@@ -9066,9 +9069,13 @@ enum skl_power_gate {
#define _MG_CLKTOP2_HSCLKCTL_PORT3 0x16A8D4
#define _MG_CLKTOP2_HSCLKCTL_PORT4 0x16B8D4
#define MG_CLKTOP2_HSCLKCTL_CORE_INPUTSEL(x) ((x) << 16)
+#define MG_CLKTOP2_HSCLKCTL_CORE_INPUTSEL_MASK (0x1 << 16)
#define MG_CLKTOP2_HSCLKCTL_TLINEDRV_CLKSEL(x) ((x) << 14)
+#define MG_CLKTOP2_HSCLKCTL_TLINEDRV_CLKSEL_MASK (0x3 << 14)
#define MG_CLKTOP2_HSCLKCTL_HSDIV_RATIO(x) ((x) << 12)
+#define MG_CLKTOP2_HSCLKCTL_HSDIV_RATIO_MASK (0x3 << 12)
#define MG_CLKTOP2_HSCLKCTL_DSDIV_RATIO(x) ((x) << 8)
+#define MG_CLKTOP2_HSCLKCTL_DSDIV_RATIO_MASK (0xf << 8)
#define MG_CLKTOP2_HSCLKCTL(port) _MMIO_PORT((port) - PORT_C, \
_MG_CLKTOP2_HSCLKCTL_PORT1, \
_MG_CLKTOP2_HSCLKCTL_PORT2)
@@ -9142,12 +9149,18 @@ enum skl_power_gate {
#define _MG_PLL_BIAS_PORT3 0x16AA14
#define _MG_PLL_BIAS_PORT4 0x16BA14
#define MG_PLL_BIAS_BIAS_GB_SEL(x) ((x) << 30)
+#define MG_PLL_BIAS_BIAS_GB_SEL_MASK (0x3 << 30)
#define MG_PLL_BIAS_INIT_DCOAMP(x) ((x) << 24)
+#define MG_PLL_BIAS_INIT_DCOAMP_MASK (0x3f << 24)
#define MG_PLL_BIAS_BIAS_BONUS(x)((x) << 16)
+#define MG_PLL_BIAS_BIAS_BONUS_MASK (0xff << 16)
#define MG_PLL_BIAS_BIASCAL_EN (1 << 15)
#define MG_PLL_BIAS_CTRIM(x) ((x) << 8)
+#define MG_PLL_BIAS_CTRIM_MASK (0x1f << 8)
#define MG_PLL_BIAS_VREF_RDAC(x) ((x) << 5)
+#define MG_PLL_BIAS_VREF_RDAC_MASK (0x7 << 5)
#define MG_PLL_BIAS_IREFTRIM(x) ((x) << 0)
+#define MG_PLL_BIAS_IREFTRIM_MASK(0x1f << 0)
#define MG_PLL_BIAS(port) _MMIO_PORT((port) - PORT_C, _MG_PLL_BIAS_PORT1, \
_MG_PLL_BIAS_PORT2)
diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c
b/drivers/gpu/drm/i915/intel_dpll_mgr.c
index d4c7bacbe83e..57342364fd30 100644
--- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
@@ -2945,10 +2945,21 @@ static bool icl_pll_get_hw_state(struct
drm_i915_private *dev_priv,
case DPLL_ID_ICL_MGPLL4:
port = icl_mg_pll_id_to_port(id);
hw_state->mg_refclkin_ctl = I915_READ(MG_REFCLKIN_CTL(port));
+ hw_state->mg_refclkin_ctl &= MG_REFCLKIN_CTL_OD_2_MUX_MASK;
+
hw_state->mg_clktop2_coreclkctl1 =
I915_READ(MG_CLKTOP2_CORECLKCTL1(port));
+ hw_state->mg_clktop2_coreclkctl1 &=
+ MG_CLKTOP2_CORECLKCTL1_A_DIVRATIO_MASK;
+
hw_state->mg_clktop2_hsclkctl =
I915_READ(MG_CLKTOP2_HSCLKCTL(port));
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915/icl: Fix MG PLL setup when refclk is 38.4MHz (rev2)
== Series Details == Series: series starting with [1/2] drm/i915/icl: Fix MG PLL setup when refclk is 38.4MHz (rev2) URL : https://patchwork.freedesktop.org/series/44836/ State : failure == Summary == Applying: drm/i915/icl: Fix MG PLL setup when refclk is 38.4MHz Applying: drm/i915/icl: Do read-modify-write as needed during MG PLL programming error: sha1 information is lacking or useless (drivers/gpu/drm/i915/i915_reg.h). error: could not build fake ancestor Patch failed at 0002 drm/i915/icl: Do read-modify-write as needed during MG PLL programming Use 'git am --show-current-patch' to see the failed patch 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 2/2] drm/i915/icl: Do read-modify-write as needed during MG PLL programming
Some MG PLL registers have fields that need to be preserved at their HW
default or BIOS programmed values. So make sure we preserve them.
v2:
- Add comment to icl_mg_pll_write() explaining the need for register
masks. (Vandita)
- Fix patchwork checkpatch warning.
Cc: Vandita Kulkarni
Cc: Paulo Zanoni
Cc: James Ausmus
Signed-off-by: Imre Deak
Reviewed-by: James Ausmus (v1)
---
drivers/gpu/drm/i915/i915_reg.h | 13
drivers/gpu/drm/i915/intel_dpll_mgr.c | 39 +++
2 files changed, 48 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index c6c9e4f9a718..6e587d49b936 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -9405,6 +9405,7 @@ enum skl_power_gate {
#define _MG_REFCLKIN_CTL_PORT3 0x16A92C
#define _MG_REFCLKIN_CTL_PORT4 0x16B92C
#define MG_REFCLKIN_CTL_OD_2_MUX(x) ((x) << 8)
+#define MG_REFCLKIN_CTL_OD_2_MUX_MASK(0x7 << 8)
#define MG_REFCLKIN_CTL(port) _MMIO_PORT((port) - PORT_C, \
_MG_REFCLKIN_CTL_PORT1, \
_MG_REFCLKIN_CTL_PORT2)
@@ -9414,7 +9415,9 @@ enum skl_power_gate {
#define _MG_CLKTOP2_CORECLKCTL1_PORT3 0x16A8D8
#define _MG_CLKTOP2_CORECLKCTL1_PORT4 0x16B8D8
#define MG_CLKTOP2_CORECLKCTL1_B_DIVRATIO(x) ((x) << 16)
+#define MG_CLKTOP2_CORECLKCTL1_B_DIVRATIO_MASK (0xff << 16)
#define MG_CLKTOP2_CORECLKCTL1_A_DIVRATIO(x) ((x) << 8)
+#define MG_CLKTOP2_CORECLKCTL1_A_DIVRATIO_MASK (0xff << 8)
#define MG_CLKTOP2_CORECLKCTL1(port) _MMIO_PORT((port) - PORT_C, \
_MG_CLKTOP2_CORECLKCTL1_PORT1, \
_MG_CLKTOP2_CORECLKCTL1_PORT2)
@@ -9424,9 +9427,13 @@ enum skl_power_gate {
#define _MG_CLKTOP2_HSCLKCTL_PORT3 0x16A8D4
#define _MG_CLKTOP2_HSCLKCTL_PORT4 0x16B8D4
#define MG_CLKTOP2_HSCLKCTL_CORE_INPUTSEL(x) ((x) << 16)
+#define MG_CLKTOP2_HSCLKCTL_CORE_INPUTSEL_MASK (0x1 << 16)
#define MG_CLKTOP2_HSCLKCTL_TLINEDRV_CLKSEL(x) ((x) << 14)
+#define MG_CLKTOP2_HSCLKCTL_TLINEDRV_CLKSEL_MASK (0x3 << 14)
#define MG_CLKTOP2_HSCLKCTL_HSDIV_RATIO(x) ((x) << 12)
+#define MG_CLKTOP2_HSCLKCTL_HSDIV_RATIO_MASK (0x3 << 12)
#define MG_CLKTOP2_HSCLKCTL_DSDIV_RATIO(x) ((x) << 8)
+#define MG_CLKTOP2_HSCLKCTL_DSDIV_RATIO_MASK (0xf << 8)
#define MG_CLKTOP2_HSCLKCTL(port) _MMIO_PORT((port) - PORT_C, \
_MG_CLKTOP2_HSCLKCTL_PORT1, \
_MG_CLKTOP2_HSCLKCTL_PORT2)
@@ -9500,12 +9507,18 @@ enum skl_power_gate {
#define _MG_PLL_BIAS_PORT3 0x16AA14
#define _MG_PLL_BIAS_PORT4 0x16BA14
#define MG_PLL_BIAS_BIAS_GB_SEL(x) ((x) << 30)
+#define MG_PLL_BIAS_BIAS_GB_SEL_MASK (0x3 << 30)
#define MG_PLL_BIAS_INIT_DCOAMP(x) ((x) << 24)
+#define MG_PLL_BIAS_INIT_DCOAMP_MASK (0x3f << 24)
#define MG_PLL_BIAS_BIAS_BONUS(x)((x) << 16)
+#define MG_PLL_BIAS_BIAS_BONUS_MASK (0xff << 16)
#define MG_PLL_BIAS_BIASCAL_EN (1 << 15)
#define MG_PLL_BIAS_CTRIM(x) ((x) << 8)
+#define MG_PLL_BIAS_CTRIM_MASK (0x1f << 8)
#define MG_PLL_BIAS_VREF_RDAC(x) ((x) << 5)
+#define MG_PLL_BIAS_VREF_RDAC_MASK (0x7 << 5)
#define MG_PLL_BIAS_IREFTRIM(x) ((x) << 0)
+#define MG_PLL_BIAS_IREFTRIM_MASK(0x1f << 0)
#define MG_PLL_BIAS(port) _MMIO_PORT((port) - PORT_C, _MG_PLL_BIAS_PORT1, \
_MG_PLL_BIAS_PORT2)
diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c
b/drivers/gpu/drm/i915/intel_dpll_mgr.c
index 8543a1015e21..ae47cdb80d54 100644
--- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
@@ -2992,10 +2992,21 @@ static bool icl_pll_get_hw_state(struct
drm_i915_private *dev_priv,
} else {
port = icl_mg_pll_id_to_port(dev_priv, id);
hw_state->mg_refclkin_ctl = I915_READ(MG_REFCLKIN_CTL(port));
+ hw_state->mg_refclkin_ctl &= MG_REFCLKIN_CTL_OD_2_MUX_MASK;
+
hw_state->mg_clktop2_coreclkctl1 =
I915_READ(MG_CLKTOP2_CORECLKCTL1(port));
+ hw_state->mg_clktop2_coreclkctl1 &=
+ MG_CLKTOP2_CORECLKCTL1_A_DIVRATIO_MASK;
+
hw_state->mg_clktop2_hsclkctl =
I915_READ(MG_CLKTOP2_HSCLKCTL(port));
+
Re: [Intel-gfx] [PATCH v2] drm/i915: remove check for aux irq
On Tue, Jun 19, 2018 at 7:06 AM Ville Syrjälä
wrote:
>
> On Fri, Jun 15, 2018 at 02:51:06PM -0700, Lucas De Marchi wrote:
> > On Fri, Jun 15, 2018 at 08:58:28PM +0300, Ville Syrjälä wrote:
> > > On Wed, May 23, 2018 at 11:04:35AM -0700, Lucas De Marchi wrote:
> > > > This became dead code with commit 309bd8ed464f ("drm/i915: Reinstate
> > > > GMBUS and AUX interrupts on gen4/g4x").
> > > >
> > > > v2: Move comment about HW behavior to where decision is made to enable
> > > > MSI (Ville).
> > > >
> > > > Cc: Ville Syrjälä
> > > > Signed-off-by: Lucas De Marchi
> > > > ---
> > > > drivers/gpu/drm/i915/i915_drv.c | 6 ++
> > > > drivers/gpu/drm/i915/i915_drv.h | 10 --
> > > > drivers/gpu/drm/i915/intel_dp.c | 22 +++---
> > > > drivers/gpu/drm/i915/intel_drv.h | 1 -
> > > > drivers/gpu/drm/i915/intel_psr.c | 2 +-
> > > > 5 files changed, 14 insertions(+), 27 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/i915_drv.c
> > > > b/drivers/gpu/drm/i915/i915_drv.c
> > > > index 9c449b8d8eab..a1461de20472 100644
> > > > --- a/drivers/gpu/drm/i915/i915_drv.c
> > > > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > > > @@ -1189,6 +1189,12 @@ static int i915_driver_init_hw(struct
> > > > drm_i915_private *dev_priv)
> > > >* get lost on g4x as well, and interrupt delivery seems to stay
> > > >* properly dead afterwards. So we'll just disable them for all
> > > >* pre-gen5 chipsets.
> > > > + *
> > > > + * dp aux and gmbus irq on gen4 seems to be able to generate legacy
> > > > + * interrupts even when in MSI mode. This results in spurious
> > > > + * interrupt warnings if the legacy irq no. is shared with another
> > > > + * device. The kernel then disables that interrupt source and so
> > > > + * prevents the other device from working properly.
> > > >*/
> > > > if (INTEL_GEN(dev_priv) >= 5) {
> > > > if (pci_enable_msi(pdev) < 0)
> > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > > b/drivers/gpu/drm/i915/i915_drv.h
> > > > index b86ed6401120..c5e1f648c47c 100644
> > > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > @@ -2558,16 +2558,6 @@ intel_info(const struct drm_i915_private
> > > > *dev_priv)
> > > > (IS_CANNONLAKE(dev_priv) || \
> > > >IS_SKL_GT3(dev_priv) || IS_SKL_GT4(dev_priv))
> > > >
> > > > -/*
> > > > - * dp aux and gmbus irq on gen4 seems to be able to generate legacy
> > > > interrupts
> > > > - * even when in MSI mode. This results in spurious interrupt warnings
> > > > if the
> > > > - * legacy irq no. is shared with another device. The kernel then
> > > > disables that
> > > > - * interrupt source and so prevents the other device from working
> > > > properly.
> > > > - *
> > > > - * Since we don't enable MSI anymore on gen4, we can always use
> > > > GMBUS/AUX
> > > > - * interrupts.
> > > > - */
> > > > -#define HAS_AUX_IRQ(dev_priv) true
> > > > #define HAS_GMBUS_IRQ(dev_priv) (INTEL_GEN(dev_priv) >= 4)
> > > >
> > > > /* With the 945 and later, Y tiling got adjusted so that it was 32
> > > > 128-byte
> > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > > b/drivers/gpu/drm/i915/intel_dp.c
> > > > index ce07bd794aed..1dab40056df7 100644
> > > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > > @@ -936,7 +936,7 @@ intel_dp_check_edp(struct intel_dp *intel_dp)
> > > > }
> > > >
> > > > static uint32_t
> > > > -intel_dp_aux_wait_done(struct intel_dp *intel_dp, bool has_aux_irq)
> > > > +intel_dp_aux_wait_done(struct intel_dp *intel_dp)
> > > > {
> > > > struct drm_i915_private *dev_priv =
> > > > to_i915(intel_dp_to_dev(intel_dp));
> > > > i915_reg_t ch_ctl = intel_dp->aux_ch_ctl_reg(intel_dp);
> > > > @@ -944,14 +944,10 @@ intel_dp_aux_wait_done(struct intel_dp *intel_dp,
> > > > bool has_aux_irq)
> > > > bool done;
> > > >
> > > > #define C (((status = I915_READ_NOTRACE(ch_ctl)) &
> > > > DP_AUX_CH_CTL_SEND_BUSY) == 0)
> > > > - if (has_aux_irq)
> > > > - done = wait_event_timeout(dev_priv->gmbus_wait_queue, C,
> > > > - msecs_to_jiffies_timeout(10));
> > > > - else
> > > > - done = wait_for(C, 10) == 0;
> > > > + done = wait_event_timeout(dev_priv->gmbus_wait_queue, C,
> > > > + msecs_to_jiffies_timeout(10));
> > > > if (!done)
> > > > - DRM_ERROR("dp aux hw did not signal timeout (has irq: %i)!\n",
> > > > - has_aux_irq);
> > > > + DRM_ERROR("dp aux hw did not signal timeout!\n");
> > > > #undef C
> > > >
> > > > return status;
> > > > @@ -1016,7 +1012,6 @@ static uint32_t skl_get_aux_clock_divider(struct
> > > > intel_dp *intel_dp, int index)
> > > > }
> > > >
> > > > static uint32_t g4x_get_aux_send_ctl(struct intel_dp *intel_dp,
> > > > - bool has_aux_irq,
> > > >int send_bytes,
> > > >
Re: [Intel-gfx] [PATCH] drm/i915: Apply context workarounds directly
Quoting Joonas Lahtinen (2018-06-18 13:25:16) > Quoting Chris Wilson (2018-06-15 19:37:33) > > From: Oscar Mateo > > > > Once upon a time, we tried to apply workarounds for registers that lived > > inside the context image for every new context. That meant emitting LRI > > commands soon after each context was created. > > > > Nowadays, we have a single golden context that gets used as a master > > template for future contexts. That golden context will acquire initial > > values for its image from the existing values in HW (thanks to inhibit > > restore bit). If all WAs are applied normally (i.e. using MMIO writes) > > before that happens, they will get soaked up by the golden context and > > transmitted correctly to new contexts. > > > > All of this means we don't have to distinguish between context and > > non-context WAs anymore, because both can be applied in the same way > > (we still want to distinguish them though, because we would like to > > check their validity using i-g-t, and that means making sure we have > > a context loaded for ctx-residing WAs). > > > > Signed-off-by: Oscar Mateo > > Cc: Chris Wilson > > Cc: Joonas Lahtinen > > Cc: Ville Syrjälä > > Reviewed-by: Joonas Lahtinen I can't decide if we want to follow through on this or not. On the one hand, direct mmio writes is simpler, but on the other hand LRI run inside the target context and so much easier to reason will be saved as part of that context. Ville mentioned that Mika might have some evidence to show that we cannot always predict when the power context is loaded that would invalidate our assumptions that the direct writes will be saved (and not overridden by a later load of the power context). Oscar, if you can think of a way to confirm that the mmio writes will be saved that would be useful. Otherwise, I'll wait until Mika returns and we can probe his memory as to what he was doing to throw doubt on forcewake-vs-powercontext. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/psr : Add psr1 live status
On Tue, 12 Jun 2018, Dhinakaran Pandiyan wrote:
> On Fri, 2018-05-25 at 11:50 +0530, vathsala nagaraju wrote:
>> From: Vathsala Nagaraju
>>
>> Prints live state of psr1.Extending the existing
>> PSR2 live state function to cover psr1.
>>
>> Tested on KBL with psr2 and psr1 panel.
>>
>> v2: rebase
>> v3: DK
>> Rename psr2_live_status to psr_source_status.
>> v4: DK
>> Move EDP_PSR_STATUS_STATE_SHIFT below EDP_PSR_STATUS_STATE_MASK.
>> Pass seq to psr_source_status, handle source status prints in
>> psr_source_status.
>> v5: Fixed CI warning messages
>>
>> Cc: Rodrigo Vivi
>> Cc: Dhinakaran Pandiyan
>>
>
> nit: Noticed an extra space in the title before the colon.
> Reviewed-by: Dhinakaran Pandiyan
I'm afraid this no longer applies cleanly. Please resend if it's still
needed.
BR,
Jani.
>
>> Signed-off-by: Vathsala Nagaraju
>> ---
>> drivers/gpu/drm/i915/i915_debugfs.c | 72 ---
>> --
>> drivers/gpu/drm/i915/i915_reg.h | 1 +
>> 2 files changed, 49 insertions(+), 24 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
>> b/drivers/gpu/drm/i915/i915_debugfs.c
>> index 5251544..1d45cb9 100644
>> --- a/drivers/gpu/drm/i915/i915_debugfs.c
>> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
>> @@ -2596,27 +2596,55 @@ static int i915_guc_log_relay_release(struct
>> inode *inode, struct file *file)
>> .release = i915_guc_log_relay_release,
>> };
>>
>> -static const char *psr2_live_status(u32 val)
>> -{
>> -static const char * const live_status[] = {
>> -"IDLE",
>> -"CAPTURE",
>> -"CAPTURE_FS",
>> -"SLEEP",
>> -"BUFON_FW",
>> -"ML_UP",
>> -"SU_STANDBY",
>> -"FAST_SLEEP",
>> -"DEEP_SLEEP",
>> -"BUF_ON",
>> -"TG_ON"
>> -};
>> +static void
>> +psr_source_status(struct drm_i915_private *dev_priv, struct seq_file
>> *m)
>> +{
>> +u32 val, psr_status = 0;
>>
>> -val = (val & EDP_PSR2_STATUS_STATE_MASK) >>
>> EDP_PSR2_STATUS_STATE_SHIFT;
>> -if (val < ARRAY_SIZE(live_status))
>> -return live_status[val];
>> +if (dev_priv->psr.psr2_enabled) {
>> +static const char * const live_status[] = {
>> +"IDLE",
>> +"CAPTURE",
>> +"CAPTURE_FS",
>> +"SLEEP",
>> +"BUFON_FW",
>> +"ML_UP",
>> +"SU_STANDBY",
>> +"FAST_SLEEP",
>> +"DEEP_SLEEP",
>> +"BUF_ON",
>> +"TG_ON"
>> +};
>> +psr_status = I915_READ(EDP_PSR2_STATUS);
>> +val = (psr_status & EDP_PSR2_STATUS_STATE_MASK) >>
>> +EDP_PSR2_STATUS_STATE_SHIFT;
>> +if (val < ARRAY_SIZE(live_status)) {
>> +seq_printf(m, "Source PSR status: %x[%s]\n",
>> psr_status,
>> + live_status[val]);
>> +return;
>> +}
>> +} else {
>> +static const char * const live_status[] = {
>> +"IDLE",
>> +"SRDONACK",
>> +"SRDENT",
>> +"BUFOFF",
>> +"BUFON",
>> +"AUXACK",
>> +"SRDOFFACK",
>> +"SRDENT_ON",
>> +};
>> +psr_status = I915_READ(EDP_PSR_STATUS);
>> +val = (psr_status & EDP_PSR_STATUS_STATE_MASK) >>
>> +EDP_PSR_STATUS_STATE_SHIFT;
> ^alignment is different from the PSR2 block.
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
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/audio: constify ELD pointers
== Series Details == Series: drm/i915/audio: constify ELD pointers URL : https://patchwork.freedesktop.org/series/45014/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4341_full -> Patchwork_9358_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_9358_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9358_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_9358_full: === IGT changes === Warnings igt@drv_selftest@live_guc: shard-kbl: SKIP -> PASS +1 == Known issues == Here are the changes found in Patchwork_9358_full that come from known issues: === IGT changes === Issues hit igt@drv_selftest@live_hangcheck: shard-apl: NOTRUN -> DMESG-FAIL (fdo#106560, fdo#106947) shard-glk: PASS -> DMESG-FAIL (fdo#106560, fdo#106947) igt@kms_cursor_legacy@2x-nonblocking-modeset-vs-cursor-atomic: shard-glk: PASS -> FAIL (fdo#106509, fdo#105454) igt@kms_flip@2x-plain-flip-ts-check: shard-glk: PASS -> FAIL (fdo#100368) igt@kms_flip_tiling@flip-to-y-tiled: shard-glk: PASS -> FAIL (fdo#104724, fdo#103822) igt@kms_setmode@basic: shard-apl: PASS -> FAIL (fdo#99912) Possible fixes igt@drv_selftest@live_gtt: shard-apl: INCOMPLETE (fdo#103927) -> PASS igt@drv_suspend@shrink: shard-snb: INCOMPLETE (fdo#105411) -> PASS +1 igt@kms_cursor_legacy@cursorb-vs-flipb-toggle: shard-glk: DMESG-WARN (fdo#105763, fdo#106538) -> PASS igt@kms_flip@2x-plain-flip-ts-check-interruptible: shard-glk: FAIL (fdo#100368) -> PASS igt@kms_flip@flip-vs-expired-vblank-interruptible: shard-glk: FAIL (fdo#105189) -> PASS igt@kms_flip@modeset-vs-vblank-race-interruptible: shard-hsw: FAIL (fdo#103060) -> PASS igt@kms_setmode@basic: shard-kbl: FAIL (fdo#99912) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#105189 https://bugs.freedesktop.org/show_bug.cgi?id=105189 fdo#105411 https://bugs.freedesktop.org/show_bug.cgi?id=105411 fdo#105454 https://bugs.freedesktop.org/show_bug.cgi?id=105454 fdo#105763 https://bugs.freedesktop.org/show_bug.cgi?id=105763 fdo#106509 https://bugs.freedesktop.org/show_bug.cgi?id=106509 fdo#106538 https://bugs.freedesktop.org/show_bug.cgi?id=106538 fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560 fdo#106947 https://bugs.freedesktop.org/show_bug.cgi?id=106947 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4341 -> Patchwork_9358 CI_DRM_4341: 1a2269d72a9a9f67fa83d799df63c98004faa2f1 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4523: 778497e7965dc8662c770a89ebbd741778feb71e @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9358: d99a99702ca9a9176e45466ebc08dae4352a09c1 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9358/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: remove check for aux irq
On Fri, Jun 15, 2018 at 02:51:06PM -0700, Lucas De Marchi wrote:
> On Fri, Jun 15, 2018 at 08:58:28PM +0300, Ville Syrjälä wrote:
> > On Wed, May 23, 2018 at 11:04:35AM -0700, Lucas De Marchi wrote:
> > > This became dead code with commit 309bd8ed464f ("drm/i915: Reinstate
> > > GMBUS and AUX interrupts on gen4/g4x").
> > >
> > > v2: Move comment about HW behavior to where decision is made to enable
> > > MSI (Ville).
> > >
> > > Cc: Ville Syrjälä
> > > Signed-off-by: Lucas De Marchi
> > > ---
> > > drivers/gpu/drm/i915/i915_drv.c | 6 ++
> > > drivers/gpu/drm/i915/i915_drv.h | 10 --
> > > drivers/gpu/drm/i915/intel_dp.c | 22 +++---
> > > drivers/gpu/drm/i915/intel_drv.h | 1 -
> > > drivers/gpu/drm/i915/intel_psr.c | 2 +-
> > > 5 files changed, 14 insertions(+), 27 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.c
> > > b/drivers/gpu/drm/i915/i915_drv.c
> > > index 9c449b8d8eab..a1461de20472 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.c
> > > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > > @@ -1189,6 +1189,12 @@ static int i915_driver_init_hw(struct
> > > drm_i915_private *dev_priv)
> > >* get lost on g4x as well, and interrupt delivery seems to stay
> > >* properly dead afterwards. So we'll just disable them for all
> > >* pre-gen5 chipsets.
> > > + *
> > > + * dp aux and gmbus irq on gen4 seems to be able to generate legacy
> > > + * interrupts even when in MSI mode. This results in spurious
> > > + * interrupt warnings if the legacy irq no. is shared with another
> > > + * device. The kernel then disables that interrupt source and so
> > > + * prevents the other device from working properly.
> > >*/
> > > if (INTEL_GEN(dev_priv) >= 5) {
> > > if (pci_enable_msi(pdev) < 0)
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > b/drivers/gpu/drm/i915/i915_drv.h
> > > index b86ed6401120..c5e1f648c47c 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > @@ -2558,16 +2558,6 @@ intel_info(const struct drm_i915_private *dev_priv)
> > > (IS_CANNONLAKE(dev_priv) || \
> > >IS_SKL_GT3(dev_priv) || IS_SKL_GT4(dev_priv))
> > >
> > > -/*
> > > - * dp aux and gmbus irq on gen4 seems to be able to generate legacy
> > > interrupts
> > > - * even when in MSI mode. This results in spurious interrupt warnings if
> > > the
> > > - * legacy irq no. is shared with another device. The kernel then
> > > disables that
> > > - * interrupt source and so prevents the other device from working
> > > properly.
> > > - *
> > > - * Since we don't enable MSI anymore on gen4, we can always use GMBUS/AUX
> > > - * interrupts.
> > > - */
> > > -#define HAS_AUX_IRQ(dev_priv) true
> > > #define HAS_GMBUS_IRQ(dev_priv) (INTEL_GEN(dev_priv) >= 4)
> > >
> > > /* With the 945 and later, Y tiling got adjusted so that it was 32
> > > 128-byte
> > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > b/drivers/gpu/drm/i915/intel_dp.c
> > > index ce07bd794aed..1dab40056df7 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > @@ -936,7 +936,7 @@ intel_dp_check_edp(struct intel_dp *intel_dp)
> > > }
> > >
> > > static uint32_t
> > > -intel_dp_aux_wait_done(struct intel_dp *intel_dp, bool has_aux_irq)
> > > +intel_dp_aux_wait_done(struct intel_dp *intel_dp)
> > > {
> > > struct drm_i915_private *dev_priv = to_i915(intel_dp_to_dev(intel_dp));
> > > i915_reg_t ch_ctl = intel_dp->aux_ch_ctl_reg(intel_dp);
> > > @@ -944,14 +944,10 @@ intel_dp_aux_wait_done(struct intel_dp *intel_dp,
> > > bool has_aux_irq)
> > > bool done;
> > >
> > > #define C (((status = I915_READ_NOTRACE(ch_ctl)) &
> > > DP_AUX_CH_CTL_SEND_BUSY) == 0)
> > > - if (has_aux_irq)
> > > - done = wait_event_timeout(dev_priv->gmbus_wait_queue, C,
> > > - msecs_to_jiffies_timeout(10));
> > > - else
> > > - done = wait_for(C, 10) == 0;
> > > + done = wait_event_timeout(dev_priv->gmbus_wait_queue, C,
> > > + msecs_to_jiffies_timeout(10));
> > > if (!done)
> > > - DRM_ERROR("dp aux hw did not signal timeout (has irq: %i)!\n",
> > > - has_aux_irq);
> > > + DRM_ERROR("dp aux hw did not signal timeout!\n");
> > > #undef C
> > >
> > > return status;
> > > @@ -1016,7 +1012,6 @@ static uint32_t skl_get_aux_clock_divider(struct
> > > intel_dp *intel_dp, int index)
> > > }
> > >
> > > static uint32_t g4x_get_aux_send_ctl(struct intel_dp *intel_dp,
> > > - bool has_aux_irq,
> > >int send_bytes,
> > >uint32_t aux_clock_divider)
> > > {
> > > @@ -1037,7 +1032,7 @@ static uint32_t g4x_get_aux_send_ctl(struct
> > > intel_dp *intel_dp,
> > >
> > > return DP_AUX_CH_CTL_SEND_BUSY |
> > > DP_AUX_CH_CTL_DONE |
> > > -(has_aux_irq ?
[Intel-gfx] [PATCH i-g-t 2/2] igt/gem_sync: Show the baseline poll latency for wakeups
Distinguish between the latency required to switch away from the
pollable spinner into the target nops from the client wakeup of
synchronisation on the last nop.
Signed-off-by: Chris Wilson
---
tests/gem_sync.c | 33 ++---
1 file changed, 30 insertions(+), 3 deletions(-)
diff --git a/tests/gem_sync.c b/tests/gem_sync.c
index 5901e1476..a3e3d7ee8 100644
--- a/tests/gem_sync.c
+++ b/tests/gem_sync.c
@@ -207,7 +207,7 @@ wakeup_ring(int fd, unsigned ring, int timeout, int wlen)
const uint32_t bbe = MI_BATCH_BUFFER_END;
struct drm_i915_gem_exec_object2 object;
struct drm_i915_gem_execbuffer2 execbuf;
- double end, this, elapsed, now;
+ double end, this, elapsed, now, baseline;
unsigned long cycles;
uint32_t cmd;
igt_spin_t *spin;
@@ -230,6 +230,32 @@ wakeup_ring(int fd, unsigned ring, int timeout, int wlen)
igt_spin_batch_end(spin);
gem_sync(fd, object.handle);
+ for (int warmup = 0; warmup <= 1; warmup++) {
+ end = gettime() + timeout/10.;
+ elapsed = 0;
+ cycles = 0;
+ do {
+ *spin->batch = cmd;
+ *spin->running = 0;
+ gem_execbuf(fd, >execbuf);
+ while (!READ_ONCE(*spin->running))
+ ;
+
+ this = gettime();
+ igt_spin_batch_end(spin);
+ gem_sync(fd, spin->handle);
+ now = gettime();
+
+ elapsed += now - this;
+ cycles++;
+ } while (now < end);
+ baseline = elapsed / cycles;
+ }
+ igt_info("%s%sasline %ld cycles: %.3f us\n",
+names[child % num_engines] ?: "",
+names[child % num_engines] ? " b" : "B",
+cycles, elapsed*1e6/cycles);
+
end = gettime() + timeout;
elapsed = 0;
cycles = 0;
@@ -251,11 +277,12 @@ wakeup_ring(int fd, unsigned ring, int timeout, int wlen)
elapsed += now - this;
cycles++;
} while (now < end);
+ elapsed -= cycles * baseline;
- igt_info("%s%sompleted %ld cycles: %.3f us\n",
+ igt_info("%s%sompleted %ld cycles: %.3f + %.3f us\n",
names[child % num_engines] ?: "",
names[child % num_engines] ? " c" : "C",
-cycles, elapsed*1e6/cycles);
+cycles, 1e6*baseline, elapsed*1e6/cycles);
igt_spin_batch_free(fd, spin);
gem_close(fd, object.handle);
--
2.18.0.rc2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 1/2] lib: Spin fast, sweet chariot, coming to carry me home
When using the pollable spinner, we often want to use it as a means of
ensuring the task is running on the GPU before switching to something
else. In which case we don't want to add extra delay inside the spinner,
but the current 1000 NOPs add on order of 5us, which is often larger
than the target latency.
Signed-off-by: Chris Wilson
---
lib/igt_dummyload.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/lib/igt_dummyload.c b/lib/igt_dummyload.c
index d32b421c6..b090b8004 100644
--- a/lib/igt_dummyload.c
+++ b/lib/igt_dummyload.c
@@ -78,6 +78,7 @@ fill_reloc(struct drm_i915_gem_relocation_entry *reloc,
#define OUT_FENCE (1 << 0)
#define POLL_RUN (1 << 1)
#define NO_PREEMPTION (1 << 2)
+#define SPIN_FAST (1 << 3)
static int
emit_recursive_batch(igt_spin_t *spin, int fd, uint32_t ctx, unsigned engine,
@@ -212,7 +213,8 @@ emit_recursive_batch(igt_spin_t *spin, int fd, uint32_t
ctx, unsigned engine,
* between function calls, that appears enough to keep SNB out of
* trouble. See https://bugs.freedesktop.org/show_bug.cgi?id=102262
*/
- batch += 1000;
+ if (!(flags & SPIN_FAST))
+ batch += 1000;
/* recurse */
r = [obj[BATCH].relocation_count++];
@@ -369,7 +371,7 @@ igt_spin_batch_new_fence(int fd, uint32_t ctx, unsigned
engine)
igt_spin_t *
__igt_spin_batch_new_poll(int fd, uint32_t ctx, unsigned engine)
{
- return ___igt_spin_batch_new(fd, ctx, engine, 0, POLL_RUN);
+ return ___igt_spin_batch_new(fd, ctx, engine, 0, POLL_RUN | SPIN_FAST);
}
igt_spin_t *
--
2.18.0.rc2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 2/6] igt/gem_sync: Alternate stress for nop+sync
Quoting Joonas Lahtinen (2018-06-19 14:36:42)
> Quoting Chris Wilson (2018-06-19 13:49:16)
> > Apply a different sort of stress by timing how long it takes to sync a
> > second nop batch in the pipeline. We first start a spinner on the
> > engine, then when we know the GPU is active, we submit the second nop;
> > start timing as we then release the spinner and wait for the nop to
> > complete.
> >
> > As with every other gem_sync test, it serves two roles. The first is
> > that it checks that we do not miss a wakeup under common stressful
> > conditions (the more conditions we check, the happier we will be that
> > they do not occur in practice). And the second role it fulfils, is that
> > it provides a very crude estimate for how long it takes for a nop to
> > execute from a running start (we already have a complimentary estimate
> > for an idle start).
> >
> > Signed-off-by: Chris Wilson
> > Cc: Joonas Lahtinen
>
>
>
> > +static void
> > +wakeup_ring(int fd, unsigned ring, int timeout)
> > +{
>
>
>
> > + intel_detect_and_clear_missed_interrupts(fd);
> > + igt_fork(child, num_engines) {
> > + const uint32_t bbe = MI_BATCH_BUFFER_END;
> > + struct drm_i915_gem_exec_object2 object;
> > + struct drm_i915_gem_execbuffer2 execbuf;
> > + double end, this, elapsed, now;
> > + unsigned long cycles;
> > + uint32_t cmd;
> > + igt_spin_t *spin;
> > +
> > + memset(, 0, sizeof(object));
> > + object.handle = gem_create(fd, 4096);
> > + gem_write(fd, object.handle, 0, , sizeof(bbe));
> > +
> > + memset(, 0, sizeof(execbuf));
> > + execbuf.buffers_ptr = to_user_pointer();
> > + execbuf.buffer_count = 1;
> > + execbuf.flags = engines[child % num_engines];
> > +
> > + spin = __igt_spin_batch_new_poll(fd, 0, execbuf.flags);
> > + igt_assert(spin->running);
> > + cmd = *spin->batch;
> > +
> > + gem_execbuf(fd, );
> > +
> > + igt_spin_batch_end(spin);
> > + gem_sync(fd, object.handle);
> > +
> > + end = gettime() + timeout;
> > + elapsed = 0;
> > + cycles = 0;
> > + do {
> > + *spin->batch = cmd;
> > + *spin->running = 0;
>
> igt_spin_batch_reset/resume/whatever...
And here you see why Tvrtko and myself never formalised that part of the
API.
Anyway, I just found why this was underperforming. Those 250 MI_NOOPs we
insert to stop the GPU eating itself cost around 5us, which considering
the target here is say 1us, is quite huge.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 3/6] igt/gem_sync: Double the wakeups, twice the pain
Quoting Chris Wilson (2018-06-19 13:49:17) > To further defeat any contemplated spin-optimisations to avoid the irq > latency for synchronous wakeups, increase the queue length. > > Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen Regards, Joonas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 2/6] igt/gem_sync: Alternate stress for nop+sync
Quoting Chris Wilson (2018-06-19 13:49:16)
> Apply a different sort of stress by timing how long it takes to sync a
> second nop batch in the pipeline. We first start a spinner on the
> engine, then when we know the GPU is active, we submit the second nop;
> start timing as we then release the spinner and wait for the nop to
> complete.
>
> As with every other gem_sync test, it serves two roles. The first is
> that it checks that we do not miss a wakeup under common stressful
> conditions (the more conditions we check, the happier we will be that
> they do not occur in practice). And the second role it fulfils, is that
> it provides a very crude estimate for how long it takes for a nop to
> execute from a running start (we already have a complimentary estimate
> for an idle start).
>
> Signed-off-by: Chris Wilson
> Cc: Joonas Lahtinen
> +static void
> +wakeup_ring(int fd, unsigned ring, int timeout)
> +{
> + intel_detect_and_clear_missed_interrupts(fd);
> + igt_fork(child, num_engines) {
> + const uint32_t bbe = MI_BATCH_BUFFER_END;
> + struct drm_i915_gem_exec_object2 object;
> + struct drm_i915_gem_execbuffer2 execbuf;
> + double end, this, elapsed, now;
> + unsigned long cycles;
> + uint32_t cmd;
> + igt_spin_t *spin;
> +
> + memset(, 0, sizeof(object));
> + object.handle = gem_create(fd, 4096);
> + gem_write(fd, object.handle, 0, , sizeof(bbe));
> +
> + memset(, 0, sizeof(execbuf));
> + execbuf.buffers_ptr = to_user_pointer();
> + execbuf.buffer_count = 1;
> + execbuf.flags = engines[child % num_engines];
> +
> + spin = __igt_spin_batch_new_poll(fd, 0, execbuf.flags);
> + igt_assert(spin->running);
> + cmd = *spin->batch;
> +
> + gem_execbuf(fd, );
> +
> + igt_spin_batch_end(spin);
> + gem_sync(fd, object.handle);
> +
> + end = gettime() + timeout;
> + elapsed = 0;
> + cycles = 0;
> + do {
> + *spin->batch = cmd;
> + *spin->running = 0;
igt_spin_batch_reset/resume/whatever...
Reviewed-by: Joonas Lahtinen
Regards, Joonas
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] 4.18-rc1 i915 dma mapping warning
Quoting Joonas Lahtinen (2018-06-19 14:16:08) > + Chris, > > Somehow this message managed to dodge the mailing list? > > Regards, Joonas > > Quoting Dave Jones (2018-06-19 05:52:23) > > The new DMA mapping debug option in 4.18-rc1 (CONFIG_DMA_API_DEBUG_SG) > > seems to dislike something about i915.. See commit 002edb6f6f2a79bea50de11260ddc9572e6db731 Author: Robin Murphy Date: Fri Nov 6 16:32:51 2015 -0800 dma-mapping: tidy up dma_parms default handling Many DMA controllers and other devices set max_segment_size to indicate their scatter-gather capability, but have no interest in segment_boundary_mask. However, the existence of a dma_parms structure precludes the use of any default value, leaving them as zeros (assuming a properly kzalloc'ed structure). If a well-behaved IOMMU (or SWIOTLB) then tries to respect this by ensuring a mapped segment does not cross a zero-byte boundary, hilarity ensues. Since zero is a nonsensical value for either parameter, treat it as an indicator for "default", as might be expected. In the process, clean up a bit by replacing the bare constants with slightly more meaningful macros and removing the superfluous "else" statements. [a...@linux-foundation.org: dma-mapping.h needs sizes.h for SZ_64K] Signed-off-by: Robin Murphy Reviewed-by: Sumit Semwal Acked-by: Marek Szyprowski Cc: Arnd Bergmann Cc: Sakari Ailus Cc: Russell King Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds for no explanation whatever for the magical value. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] lib: Conservatively include residue buffers in the available ram estimate
Quoting Chris Wilson (2018-06-19 12:20:55) > Add any buffers reported by sysinfo to the estimate of available memory. > We do ask the kernel to purge it's caches before reporting sysinfo, but > a few remain that may be forced out by our test usage, so include them. > However, be conservative and only allow them to be swapped out. > > References: https://bugs.freedesktop.org/show_bug.cgi?id=105967 > Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen Regards, Joonas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 24/24] drm/i915/icl: toggle PHY clock gating around link training
Op 22-05-18 om 02:25 schreef Paulo Zanoni:
> The Gen11 TypeC PHY DDI Buffer chapter, PHY Clock Gating Programming
> section says that PHY clock gating should be disabled before starting
> voltage swing programming, then enabled after any link training is
> complete.
>
> Cc: Animesh Manna
> Cc: Manasi Navare
> Signed-off-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/i915_reg.h | 21 +
> drivers/gpu/drm/i915/intel_ddi.c | 3 ++
> drivers/gpu/drm/i915/intel_dp.c | 66
>
> drivers/gpu/drm/i915/intel_drv.h | 2 ++
> 4 files changed, 92 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 2ccae6c3e905..9d2c022bc3a1 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1957,6 +1957,27 @@ enum i915_power_well_id {
> _MG_DP_MODE_LN1_ACU_PORT1)
> #define MG_DP_MODE_CFG_DP_X2_MODE (1 << 7)
> #define MG_DP_MODE_CFG_DP_X1_MODE (1 << 6)
> +#define MG_DP_MODE_CFG_TR2PWR_GATING (1 << 5)
> +#define MG_DP_MODE_CFG_TRPWR_GATING(1 << 4)
> +#define MG_DP_MODE_CFG_CLNPWR_GATING (1 << 3)
> +#define MG_DP_MODE_CFG_DIGPWR_GATING (1 << 2)
> +#define MG_DP_MODE_CFG_GAONPWR_GATING (1 << 1)
> +
> +#define _MG_MISC_SUS0_PORT1 0x168814
> +#define _MG_MISC_SUS0_PORT2 0x169814
> +#define _MG_MISC_SUS0_PORT3 0x16A814
> +#define _MG_MISC_SUS0_PORT4 0x16B814
> +#define MG_MISC_SUS0(tc_port) \
> + _MMIO(_PORT(tc_port, _MG_MISC_SUS0_PORT1, _MG_MISC_SUS0_PORT2))
> +#define MG_MISC_SUS0_SUSCLK_DYNCLKGATE_MODE_MASK (3 << 14)
> +#define MG_MISC_SUS0_SUSCLK_DYNCLKGATE_MODE(x) ((x) << 14)
> +#define MG_MISC_SUS0_CFG_TR2PWR_GATING (1 << 12)
> +#define MG_MISC_SUS0_CFG_CL2PWR_GATING (1 << 11)
> +#define MG_MISC_SUS0_CFG_GAONPWR_GATING(1 << 10)
> +#define MG_MISC_SUS0_CFG_TRPWR_GATING (1 << 7)
> +#define MG_MISC_SUS0_CFG_CL1PWR_GATING (1 << 6)
> +#define MG_MISC_SUS0_CFG_DGPWR_GATING (1 << 5)
> +
>
> /* The spec defines this only for BXT PHY0, but lets assume that this
> * would exist for PHY1 too if it had a second channel.
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index c3c29565b863..6617950a28a9 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -2668,6 +2668,7 @@ static void intel_ddi_pre_enable_dp(struct
> intel_encoder *encoder,
> intel_display_power_get(dev_priv, dig_port->ddi_io_power_domain);
>
> icl_program_mg_dp_mode(intel_dp);
> + icl_disable_phy_clock_gating(dig_port);
>
> if (IS_ICELAKE(dev_priv))
> icl_ddi_vswing_sequence(encoder, level, encoder->type);
> @@ -2684,6 +2685,8 @@ static void intel_ddi_pre_enable_dp(struct
> intel_encoder *encoder,
> intel_dp_start_link_train(intel_dp);
> if (port != PORT_A || INTEL_GEN(dev_priv) >= 9)
> intel_dp_stop_link_train(intel_dp);
> +
> + icl_enable_phy_clock_gating(dig_port);
> }
>
> static void intel_ddi_pre_enable_hdmi(struct intel_encoder *encoder,
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 1228d6185f76..e898d61b5924 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -295,6 +295,72 @@ void icl_program_mg_dp_mode(struct intel_dp *intel_dp)
> I915_WRITE(MG_DP_MODE(port, 1), ln1);
> }
>
> +void icl_enable_phy_clock_gating(struct intel_digital_port *dig_port)
> +{
> + struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
> + enum port port = dig_port->base.port;
> + enum tc_port tc_port = intel_port_to_tc(dev_priv, port);
> + i915_reg_t mg_regs[2] = { MG_DP_MODE(port, 0), MG_DP_MODE(port, 1) };
> + u32 val;
> + int i;
> +
> + if (tc_port == PORT_TC_NONE)
> + return;
> +
> + for (i = 0; i < ARRAY_SIZE(mg_regs); i++) {
> + val = I915_READ(mg_regs[i]);
> + val |= 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;
> + I915_WRITE(mg_regs[i], val);
> + }
> +
> + val = I915_READ(MG_MISC_SUS0(tc_port));
> + val |= MG_MISC_SUS0_SUSCLK_DYNCLKGATE_MODE(3) |
> +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 |
> +
Re: [Intel-gfx] 4.18-rc1 i915 dma mapping warning
+ Chris, Somehow this message managed to dodge the mailing list? Regards, Joonas Quoting Dave Jones (2018-06-19 05:52:23) > The new DMA mapping debug option in 4.18-rc1 (CONFIG_DMA_API_DEBUG_SG) seems > to dislike something about i915.. > > [1.203923] i915 :00:02.0: DMA-API: mapping sg segment longer than > device claims to support [len=69632] [max=65536] > [1.203968] WARNING: CPU: 1 PID: 1 at lib/dma-debug.c:1301 > debug_dma_map_sg+0x26f/0x3f0 > [1.203989] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.18.0-rc1 #1 > [1.204008] Hardware name: Shuttle Inc. SH87R/FH87, BIOS 2.03 06/19/2014 > [1.204025] RIP: 0010:debug_dma_map_sg+0x26f/0x3f0 > [1.204038] Code: 08 48 8b 54 24 10 4c 8b 5c 24 18 4c 8b 4c 24 20 8b 4c 24 > 2c 48 c7 c7 a8 80 01 99 4c 89 4c 24 10 4c 89 5c 24 08 e8 51 58 ca ff <0f> 0b > 4c 8b 4c 24 10 4c 8b 5c 24 08 8b 35 e7 27 f6 00 85 f6 0f 85 > [1.204175] RSP: :a11a00023b10 EFLAGS: 00010246 > [1.204190] RAX: RBX: 9782d0922008 RCX: > > [1.204207] RDX: 0001 RSI: 980b94cf RDI: > 980b94cf > [1.204225] RBP: 9782d2b7c5e8 R08: 0001 R09: > 0001 > [1.204242] R10: R11: R12: > > [1.204259] R13: 0001 R14: 87654321 R15: > 9782d57f58c8 > [1.204277] FS: () GS:9782d640() > knlGS: > [1.204296] CS: 0010 DS: ES: CR0: 80050033 > [1.204311] CR2: CR3: 00013f224001 CR4: > 000606e0 > [1.204328] Call Trace: > [1.204340] i915_gem_gtt_prepare_pages+0x78/0xd0 > [1.204354] i915_gem_object_get_pages_gtt+0x3e9/0x790 > [1.204368] __i915_gem_object_get_pages+0x58/0x70 > [1.204382] i915_gem_object_set_to_gtt_domain+0x51/0x100 > [1.204398] intel_ring_context_pin+0xe4/0x230 > [1.204411] i915_request_alloc+0x51/0x400 > [1.204423] i915_gem_init+0x2c9/0x480 > [1.204436] i915_driver_load+0x9ad/0xec0 > [1.204449] ? _raw_spin_unlock_irqrestore+0x3f/0x70 > [1.204463] pci_device_probe+0xa8/0x130 > [1.204477] driver_probe_device+0x29d/0x330 > [1.204489] __driver_attach+0xc0/0xd0 > [1.204501] ? driver_probe_device+0x330/0x330 > [1.204514] bus_for_each_dev+0x6b/0xc0 > [1.204525] bus_add_driver+0x11d/0x210 > [1.204538] ? mipi_dsi_bus_init+0x11/0x11 > [1.204551] driver_register+0x5b/0xe0 > [1.204563] do_one_initcall+0x10b/0x345 > [1.204575] ? do_early_param+0x8e/0x8e > [1.204588] ? rcu_read_lock_sched_held+0x66/0x70 > [1.204602] ? do_early_param+0x8e/0x8e > [1.204613] kernel_init_freeable+0x1c6/0x24c > [1.204627] ? rest_init+0xc0/0xc0 > [1.204637] kernel_init+0xa/0x100 > [1.204648] ret_from_fork+0x3a/0x50 > [1.204659] irq event stamp: 1452970 > [1.204672] hardirqs last enabled at (1452969): [] > console_unlock+0x4f7/0x680 > [1.204693] hardirqs last disabled at (1452970): [] > error_entry+0x86/0x100 > [1.204715] softirqs last enabled at (1448282): [] > __do_softirq+0x409/0x551 > [1.204737] softirqs last disabled at (1448143): [] > irq_exit+0xc5/0xd0 > [1.204804] ---[ end trace e7fa4b5bd5f1190a ]--- > ___ 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/audio: constify ELD pointers
== Series Details == Series: drm/i915/audio: constify ELD pointers URL : https://patchwork.freedesktop.org/series/45014/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4341 -> Patchwork_9358 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/45014/revisions/1/mbox/ == Known issues == Here are the changes found in Patchwork_9358 that come from known issues: === IGT changes === Issues hit igt@drv_module_reload@basic-no-display: fi-cnl-psr: NOTRUN -> DMESG-WARN (fdo#105395) +2 igt@gem_ctx_create@basic-files: fi-skl-guc: PASS -> DMESG-WARN (fdo#106954) igt@gem_exec_gttfill@basic: fi-byt-n2820: PASS -> FAIL (fdo#106744) igt@kms_frontbuffer_tracking@basic: fi-hsw-peppy: PASS -> DMESG-FAIL (fdo#106103, fdo#102614) igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: fi-skl-6700k2: PASS -> INCOMPLETE (fdo#104108, k.org#199541, fdo#105524) Possible fixes igt@kms_flip@basic-flip-vs-dpms: fi-glk-j4005: DMESG-WARN (fdo#106000, fdo#106097) -> PASS igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: fi-cnl-psr: INCOMPLETE (fdo#105086) -> PASS fi-glk-j4005: DMESG-WARN (fdo#106097) -> PASS +1 fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614 fdo#104108 https://bugs.freedesktop.org/show_bug.cgi?id=104108 fdo#105086 https://bugs.freedesktop.org/show_bug.cgi?id=105086 fdo#105395 https://bugs.freedesktop.org/show_bug.cgi?id=105395 fdo#105524 https://bugs.freedesktop.org/show_bug.cgi?id=105524 fdo#106000 https://bugs.freedesktop.org/show_bug.cgi?id=106000 fdo#106097 https://bugs.freedesktop.org/show_bug.cgi?id=106097 fdo#106103 https://bugs.freedesktop.org/show_bug.cgi?id=106103 fdo#106744 https://bugs.freedesktop.org/show_bug.cgi?id=106744 fdo#106954 https://bugs.freedesktop.org/show_bug.cgi?id=106954 k.org#199541 https://bugzilla.kernel.org/show_bug.cgi?id=199541 == Participating hosts (43 -> 38) == Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-hsw-4200u == Build changes == * Linux: CI_DRM_4341 -> Patchwork_9358 CI_DRM_4341: 1a2269d72a9a9f67fa83d799df63c98004faa2f1 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4523: 778497e7965dc8662c770a89ebbd741778feb71e @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9358: d99a99702ca9a9176e45466ebc08dae4352a09c1 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == d99a99702ca9 drm/i915/audio: constify ELD pointers == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9358/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/audio: constify ELD pointers
On Tue, Jun 19, 2018 at 03:44:37PM +0300, Jani Nikula wrote:
> The hooks aren't supposed to modify the ELD, so use const pointer. As a
> drive-by fix, use drm_eld_size() to log ELD size.
>
> Suggested-by: Ville Syrjala
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_audio.c | 16
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_audio.c
> b/drivers/gpu/drm/i915/intel_audio.c
> index a34aa66f28f8..bb94172ffc07 100644
> --- a/drivers/gpu/drm/i915/intel_audio.c
> +++ b/drivers/gpu/drm/i915/intel_audio.c
> @@ -213,7 +213,7 @@ static bool intel_eld_uptodate(struct drm_connector
> *connector,
> i915_reg_t reg_edid)
> {
> struct drm_i915_private *dev_priv = to_i915(connector->dev);
> - u8 *eld = connector->eld;
> + const u8 *eld = connector->eld;
> u32 tmp;
> int i;
>
> @@ -228,7 +228,7 @@ static bool intel_eld_uptodate(struct drm_connector
> *connector,
> I915_WRITE(reg_elda, tmp);
>
> for (i = 0; i < drm_eld_size(eld) / 4; i++)
> - if (I915_READ(reg_edid) != *((u32 *)eld + i))
> + if (I915_READ(reg_edid) != *((const u32 *)eld + i))
I was hoping we could make it const u32* and kill these ugly casts.
But I suppose that would require more casts for the drm_eld_size() & co.,
or changing those to take a const void* instead.
Anyways, the const alone is an improvement so
Reviewed-by: Ville Syrjälä
> return false;
>
> return true;
> @@ -261,12 +261,12 @@ static void g4x_audio_codec_enable(struct intel_encoder
> *encoder,
> {
> struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> struct drm_connector *connector = conn_state->connector;
> - u8 *eld = connector->eld;
> + const u8 *eld = connector->eld;
> u32 eldv;
> u32 tmp;
> int len, i;
>
> - DRM_DEBUG_KMS("Enable audio codec, %u bytes ELD\n", eld[2]);
> + DRM_DEBUG_KMS("Enable audio codec, %u bytes ELD\n", drm_eld_size(eld));
>
> tmp = I915_READ(G4X_AUD_VID_DID);
> if (tmp == INTEL_AUDIO_DEVBLC || tmp == INTEL_AUDIO_DEVCL)
> @@ -288,7 +288,7 @@ static void g4x_audio_codec_enable(struct intel_encoder
> *encoder,
> len = min(drm_eld_size(eld) / 4, len);
> DRM_DEBUG_DRIVER("ELD size %d\n", len);
> for (i = 0; i < len; i++)
> - I915_WRITE(G4X_HDMIW_HDMIEDID, *((u32 *)eld + i));
> + I915_WRITE(G4X_HDMIW_HDMIEDID, *((const u32 *)eld + i));
>
> tmp = I915_READ(G4X_AUD_CNTL_ST);
> tmp |= eldv;
> @@ -466,7 +466,7 @@ static void hsw_audio_codec_enable(struct intel_encoder
> *encoder,
> /* Up to 84 bytes of hw ELD buffer */
> len = min(drm_eld_size(eld), 84);
> for (i = 0; i < len / 4; i++)
> - I915_WRITE(HSW_AUD_EDID_DATA(pipe), *((u32 *)eld + i));
> + I915_WRITE(HSW_AUD_EDID_DATA(pipe), *((const u32 *)eld + i));
>
> /* ELD valid */
> tmp = I915_READ(HSW_AUD_PIN_ELD_CP_VLD);
> @@ -534,7 +534,7 @@ static void ilk_audio_codec_enable(struct intel_encoder
> *encoder,
> struct drm_connector *connector = conn_state->connector;
> enum pipe pipe = crtc->pipe;
> enum port port = encoder->port;
> - u8 *eld = connector->eld;
> + const u8 *eld = connector->eld;
> u32 tmp, eldv;
> int len, i;
> i915_reg_t hdmiw_hdmiedid, aud_config, aud_cntl_st, aud_cntrl_st2;
> @@ -585,7 +585,7 @@ static void ilk_audio_codec_enable(struct intel_encoder
> *encoder,
> /* Up to 84 bytes of hw ELD buffer */
> len = min(drm_eld_size(eld), 84);
> for (i = 0; i < len / 4; i++)
> - I915_WRITE(hdmiw_hdmiedid, *((u32 *)eld + i));
> + I915_WRITE(hdmiw_hdmiedid, *((const u32 *)eld + i));
>
> /* ELD valid */
> tmp = I915_READ(aud_cntrl_st2);
> --
> 2.11.0
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 23/24] drm/i915/icl: program MG_DP_MODE
Op 19-06-18 om 14:59 schreef Maarten Lankhorst:
> Op 22-05-18 om 02:25 schreef Paulo Zanoni:
>> Programming this register is part of the Enable Sequence for
>> DisplayPort on ICL. Do as the spec says.
>>
>> Cc: Animesh Manna
>> Cc: Manasi Navare
>> Cc: Dhinakaran Pandiyan
>> Signed-off-by: Paulo Zanoni
>> ---
>> drivers/gpu/drm/i915/i915_reg.h | 15 +
>> drivers/gpu/drm/i915/intel_ddi.c | 2 ++
>> drivers/gpu/drm/i915/intel_dp.c | 66
>>
>> drivers/gpu/drm/i915/intel_drv.h | 1 +
>> 4 files changed, 84 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_reg.h
>> b/drivers/gpu/drm/i915/i915_reg.h
>> index 2a501e7590bf..2ccae6c3e905 100644
>> --- a/drivers/gpu/drm/i915/i915_reg.h
>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>> @@ -1943,6 +1943,21 @@ enum i915_power_well_id {
>> #define CRI_TXDEEMPH_OVERRIDE_5_0(x)((x) << 16)
>> #define CRI_TXDEEMPH_OVERRIDE_5_0_MASK (0x3F << 16)
>>
>> +#define _MG_DP_MODE_LN0_ACU_PORT1 0x1683A0
>> +#define _MG_DP_MODE_LN1_ACU_PORT1 0x1687A0
>> +#define _MG_DP_MODE_LN0_ACU_PORT2 0x1693A0
>> +#define _MG_DP_MODE_LN1_ACU_PORT2 0x1697A0
>> +#define _MG_DP_MODE_LN0_ACU_PORT3 0x16A3A0
>> +#define _MG_DP_MODE_LN1_ACU_PORT3 0x16A7A0
>> +#define _MG_DP_MODE_LN0_ACU_PORT4 0x16B3A0
>> +#define _MG_DP_MODE_LN1_ACU_PORT4 0x16B7A0
>> +#define MG_DP_MODE(port, ln)\
>> +_ICL_MG_PHY_PORT_LN(port, ln, _MG_DP_MODE_LN0_ACU_PORT1, \
>> + _MG_DP_MODE_LN0_ACU_PORT2, \
>> + _MG_DP_MODE_LN1_ACU_PORT1)
>> +#define MG_DP_MODE_CFG_DP_X2_MODE (1 << 7)
>> +#define MG_DP_MODE_CFG_DP_X1_MODE (1 << 6)
>> +
>> /* The spec defines this only for BXT PHY0, but lets assume that this
>> * would exist for PHY1 too if it had a second channel.
>> */
>> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
>> b/drivers/gpu/drm/i915/intel_ddi.c
>> index 1d5bfec57c33..c3c29565b863 100644
>> --- a/drivers/gpu/drm/i915/intel_ddi.c
>> +++ b/drivers/gpu/drm/i915/intel_ddi.c
>> @@ -2667,6 +2667,8 @@ static void intel_ddi_pre_enable_dp(struct
>> intel_encoder *encoder,
>>
>> intel_display_power_get(dev_priv, dig_port->ddi_io_power_domain);
>>
>> +icl_program_mg_dp_mode(intel_dp);
>> +
>> if (IS_ICELAKE(dev_priv))
>> icl_ddi_vswing_sequence(encoder, level, encoder->type);
>> else if (IS_CANNONLAKE(dev_priv))
>> diff --git a/drivers/gpu/drm/i915/intel_dp.c
>> b/drivers/gpu/drm/i915/intel_dp.c
>> index a883a3264e56..1228d6185f76 100644
>> --- a/drivers/gpu/drm/i915/intel_dp.c
>> +++ b/drivers/gpu/drm/i915/intel_dp.c
>> @@ -229,6 +229,72 @@ intel_dp_link_required(int pixel_clock, int bpp)
>> return DIV_ROUND_UP(pixel_clock * bpp, 8);
>> }
>>
>> +void icl_program_mg_dp_mode(struct intel_dp *intel_dp)
>> +{
>> +struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
>> +struct drm_i915_private *dev_priv = to_i915(intel_dp_to_dev(intel_dp));
>> +enum port port = intel_dig_port->base.port;
>> +enum tc_port tc_port = intel_port_to_tc(dev_priv, port);
>> +u32 ln0, ln1, lane_info;
>> +
>> +if (tc_port == PORT_TC_NONE || intel_dig_port->tc_type == TC_PORT_TBT)
>> +return;
>> +
>> +ln0 = I915_READ(MG_DP_MODE(port, 0));
>> +ln1 = I915_READ(MG_DP_MODE(port, 1));
>> +
>> +switch (intel_dig_port->tc_type) {
>> +case TC_PORT_TYPEC:
>> +ln0 &= ~(MG_DP_MODE_CFG_DP_X1_MODE | MG_DP_MODE_CFG_DP_X2_MODE);
>> +ln1 &= ~(MG_DP_MODE_CFG_DP_X1_MODE | MG_DP_MODE_CFG_DP_X2_MODE);
>> +
>> +lane_info = (I915_READ(PORT_TX_DFLEXDPSP) &
>> + DP_LANE_ASSIGNMENT_MASK(tc_port)) >>
>> +DP_LANE_ASSIGNMENT_SHIFT(tc_port);
>> +
>> +switch (lane_info) {
>> +case 0x1:
>> +case 0x4:
>> +break;
> Shouldn't this still be x1 mode?
Ah nm, found the mapping.
Reviewed-by: Maarten Lankhorst
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 23/24] drm/i915/icl: program MG_DP_MODE
Op 22-05-18 om 02:25 schreef Paulo Zanoni:
> Programming this register is part of the Enable Sequence for
> DisplayPort on ICL. Do as the spec says.
>
> Cc: Animesh Manna
> Cc: Manasi Navare
> Cc: Dhinakaran Pandiyan
> Signed-off-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/i915_reg.h | 15 +
> drivers/gpu/drm/i915/intel_ddi.c | 2 ++
> drivers/gpu/drm/i915/intel_dp.c | 66
>
> drivers/gpu/drm/i915/intel_drv.h | 1 +
> 4 files changed, 84 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 2a501e7590bf..2ccae6c3e905 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1943,6 +1943,21 @@ enum i915_power_well_id {
> #define CRI_TXDEEMPH_OVERRIDE_5_0(x) ((x) << 16)
> #define CRI_TXDEEMPH_OVERRIDE_5_0_MASK (0x3F << 16)
>
> +#define _MG_DP_MODE_LN0_ACU_PORT10x1683A0
> +#define _MG_DP_MODE_LN1_ACU_PORT10x1687A0
> +#define _MG_DP_MODE_LN0_ACU_PORT20x1693A0
> +#define _MG_DP_MODE_LN1_ACU_PORT20x1697A0
> +#define _MG_DP_MODE_LN0_ACU_PORT30x16A3A0
> +#define _MG_DP_MODE_LN1_ACU_PORT30x16A7A0
> +#define _MG_DP_MODE_LN0_ACU_PORT40x16B3A0
> +#define _MG_DP_MODE_LN1_ACU_PORT40x16B7A0
> +#define MG_DP_MODE(port, ln) \
> + _ICL_MG_PHY_PORT_LN(port, ln, _MG_DP_MODE_LN0_ACU_PORT1, \
> + _MG_DP_MODE_LN0_ACU_PORT2, \
> + _MG_DP_MODE_LN1_ACU_PORT1)
> +#define MG_DP_MODE_CFG_DP_X2_MODE (1 << 7)
> +#define MG_DP_MODE_CFG_DP_X1_MODE (1 << 6)
> +
> /* The spec defines this only for BXT PHY0, but lets assume that this
> * would exist for PHY1 too if it had a second channel.
> */
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 1d5bfec57c33..c3c29565b863 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -2667,6 +2667,8 @@ static void intel_ddi_pre_enable_dp(struct
> intel_encoder *encoder,
>
> intel_display_power_get(dev_priv, dig_port->ddi_io_power_domain);
>
> + icl_program_mg_dp_mode(intel_dp);
> +
> if (IS_ICELAKE(dev_priv))
> icl_ddi_vswing_sequence(encoder, level, encoder->type);
> else if (IS_CANNONLAKE(dev_priv))
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index a883a3264e56..1228d6185f76 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -229,6 +229,72 @@ intel_dp_link_required(int pixel_clock, int bpp)
> return DIV_ROUND_UP(pixel_clock * bpp, 8);
> }
>
> +void icl_program_mg_dp_mode(struct intel_dp *intel_dp)
> +{
> + struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> + struct drm_i915_private *dev_priv = to_i915(intel_dp_to_dev(intel_dp));
> + enum port port = intel_dig_port->base.port;
> + enum tc_port tc_port = intel_port_to_tc(dev_priv, port);
> + u32 ln0, ln1, lane_info;
> +
> + if (tc_port == PORT_TC_NONE || intel_dig_port->tc_type == TC_PORT_TBT)
> + return;
> +
> + ln0 = I915_READ(MG_DP_MODE(port, 0));
> + ln1 = I915_READ(MG_DP_MODE(port, 1));
> +
> + switch (intel_dig_port->tc_type) {
> + case TC_PORT_TYPEC:
> + ln0 &= ~(MG_DP_MODE_CFG_DP_X1_MODE | MG_DP_MODE_CFG_DP_X2_MODE);
> + ln1 &= ~(MG_DP_MODE_CFG_DP_X1_MODE | MG_DP_MODE_CFG_DP_X2_MODE);
> +
> + lane_info = (I915_READ(PORT_TX_DFLEXDPSP) &
> + DP_LANE_ASSIGNMENT_MASK(tc_port)) >>
> + DP_LANE_ASSIGNMENT_SHIFT(tc_port);
> +
> + switch (lane_info) {
> + case 0x1:
> + case 0x4:
> + break;
Shouldn't this still be x1 mode?
~Maarten
> + case 0x2:
> + ln0 |= MG_DP_MODE_CFG_DP_X1_MODE;
> + break;
> + case 0x3:
> + ln0 |= MG_DP_MODE_CFG_DP_X1_MODE |
> +MG_DP_MODE_CFG_DP_X2_MODE;
> + break;
> + case 0x8:
> + ln1 |= MG_DP_MODE_CFG_DP_X1_MODE;
> + break;
> + case 0xC:
> + ln1 |= MG_DP_MODE_CFG_DP_X1_MODE |
> +MG_DP_MODE_CFG_DP_X2_MODE;
> + break;
> + case 0xF:
> + ln0 |= MG_DP_MODE_CFG_DP_X1_MODE |
> +MG_DP_MODE_CFG_DP_X2_MODE;
> + ln1 |= MG_DP_MODE_CFG_DP_X1_MODE |
> +MG_DP_MODE_CFG_DP_X2_MODE;
> + break;
> + default:
> + MISSING_CASE(lane_info);
> + }
> +
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/audio: constify ELD pointers
== Series Details == Series: drm/i915/audio: constify ELD pointers URL : https://patchwork.freedesktop.org/series/45014/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915/audio: constify ELD pointers -O:drivers/gpu/drm/i915/intel_audio.c:288:15: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/intel_audio.c:288:15: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/intel_audio.c:467:15: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/intel_audio.c:586:15: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_audio.c:288:15: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_audio.c:288:15: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_audio.c:467:15: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_audio.c:586:15: warning: expression using sizeof(void) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/audio: constify ELD pointers
The hooks aren't supposed to modify the ELD, so use const pointer. As a
drive-by fix, use drm_eld_size() to log ELD size.
Suggested-by: Ville Syrjala
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_audio.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_audio.c
b/drivers/gpu/drm/i915/intel_audio.c
index a34aa66f28f8..bb94172ffc07 100644
--- a/drivers/gpu/drm/i915/intel_audio.c
+++ b/drivers/gpu/drm/i915/intel_audio.c
@@ -213,7 +213,7 @@ static bool intel_eld_uptodate(struct drm_connector
*connector,
i915_reg_t reg_edid)
{
struct drm_i915_private *dev_priv = to_i915(connector->dev);
- u8 *eld = connector->eld;
+ const u8 *eld = connector->eld;
u32 tmp;
int i;
@@ -228,7 +228,7 @@ static bool intel_eld_uptodate(struct drm_connector
*connector,
I915_WRITE(reg_elda, tmp);
for (i = 0; i < drm_eld_size(eld) / 4; i++)
- if (I915_READ(reg_edid) != *((u32 *)eld + i))
+ if (I915_READ(reg_edid) != *((const u32 *)eld + i))
return false;
return true;
@@ -261,12 +261,12 @@ static void g4x_audio_codec_enable(struct intel_encoder
*encoder,
{
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
struct drm_connector *connector = conn_state->connector;
- u8 *eld = connector->eld;
+ const u8 *eld = connector->eld;
u32 eldv;
u32 tmp;
int len, i;
- DRM_DEBUG_KMS("Enable audio codec, %u bytes ELD\n", eld[2]);
+ DRM_DEBUG_KMS("Enable audio codec, %u bytes ELD\n", drm_eld_size(eld));
tmp = I915_READ(G4X_AUD_VID_DID);
if (tmp == INTEL_AUDIO_DEVBLC || tmp == INTEL_AUDIO_DEVCL)
@@ -288,7 +288,7 @@ static void g4x_audio_codec_enable(struct intel_encoder
*encoder,
len = min(drm_eld_size(eld) / 4, len);
DRM_DEBUG_DRIVER("ELD size %d\n", len);
for (i = 0; i < len; i++)
- I915_WRITE(G4X_HDMIW_HDMIEDID, *((u32 *)eld + i));
+ I915_WRITE(G4X_HDMIW_HDMIEDID, *((const u32 *)eld + i));
tmp = I915_READ(G4X_AUD_CNTL_ST);
tmp |= eldv;
@@ -466,7 +466,7 @@ static void hsw_audio_codec_enable(struct intel_encoder
*encoder,
/* Up to 84 bytes of hw ELD buffer */
len = min(drm_eld_size(eld), 84);
for (i = 0; i < len / 4; i++)
- I915_WRITE(HSW_AUD_EDID_DATA(pipe), *((u32 *)eld + i));
+ I915_WRITE(HSW_AUD_EDID_DATA(pipe), *((const u32 *)eld + i));
/* ELD valid */
tmp = I915_READ(HSW_AUD_PIN_ELD_CP_VLD);
@@ -534,7 +534,7 @@ static void ilk_audio_codec_enable(struct intel_encoder
*encoder,
struct drm_connector *connector = conn_state->connector;
enum pipe pipe = crtc->pipe;
enum port port = encoder->port;
- u8 *eld = connector->eld;
+ const u8 *eld = connector->eld;
u32 tmp, eldv;
int len, i;
i915_reg_t hdmiw_hdmiedid, aud_config, aud_cntl_st, aud_cntrl_st2;
@@ -585,7 +585,7 @@ static void ilk_audio_codec_enable(struct intel_encoder
*encoder,
/* Up to 84 bytes of hw ELD buffer */
len = min(drm_eld_size(eld), 84);
for (i = 0; i < len / 4; i++)
- I915_WRITE(hdmiw_hdmiedid, *((u32 *)eld + i));
+ I915_WRITE(hdmiw_hdmiedid, *((const u32 *)eld + i));
/* ELD valid */
tmp = I915_READ(aud_cntrl_st2);
--
2.11.0
___
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/icl: Fix MG PLL setup when refclk is 38.4MHz
> -Original Message-
> From: Deak, Imre
> Sent: Tuesday, June 19, 2018 3:43 PM
> To: Kulkarni, Vandita
> Cc: intel-gfx@lists.freedesktop.org; Zanoni, Paulo R
> ; Ausmus, James
> Subject: Re: [PATCH 1/2] drm/i915/icl: Fix MG PLL setup when refclk is
> 38.4MHz
>
> On Tue, Jun 19, 2018 at 09:07:25AM +0300, Kulkarni, Vandita wrote:
> > > -Original Message-
> > > From: Deak, Imre
> > > Sent: Monday, June 18, 2018 2:45 PM
> > > To: Kulkarni, Vandita
> > > Cc: intel-gfx@lists.freedesktop.org; Zanoni, Paulo R
> > > ; Ausmus, James
>
> > > Subject: Re: [PATCH 1/2] drm/i915/icl: Fix MG PLL setup when refclk
> > > is 38.4MHz
> > >
> > > On Mon, Jun 18, 2018 at 11:11:30AM +0300, Kulkarni, Vandita wrote:
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: Deak, Imre
> > > > > Sent: Friday, June 15, 2018 8:09 PM
> > > > > To: intel-gfx@lists.freedesktop.org
> > > > > Cc: Kulkarni, Vandita ; Zanoni,
> > > > > Paulo R ; Ausmus, James
> > >
> > > > > Subject: [PATCH 1/2] drm/i915/icl: Fix MG PLL setup when refclk
> > > > > is 38.4MHz
> > > > >
> > > > > Atm we're zeroing out fields in MG_PLL_BIAS and
> > > > > MG_PLL_TDC_COLDST_BIAS if refclk is 38.4MHz, whereas the spec
> > > > > tells us to preserve them.
> > > > > Although the calculated values mostly match the register
> > > > > defaults even for the 38.4MHz case, there are some differences
> > > > > wrt. what BIOS programs (I noticed at least differences in the
> > > > > MG_PLL_BIAS/IREFTRIM and MG_PLL_BIAS/BIASCAL_EN fields). In
> the
> > > > > lack of further info on how to program these fields, just do
> > > > > what the spec says and preserve the BIOS state.
> > > > >
> > > > > v2:
> > > > > - Preserve the BIOS programmed reg fields instead of programming
> > > them.
> > > > >
> > > > > Cc: Vandita Kulkarni
> > > > > Cc: Paulo Zanoni
> > > > > Cc: James Ausmus
> > > > > Signed-off-by: Imre Deak
> > > > > Reviewed-by: James Ausmus (v1)
> > > > > ---
> > > > > drivers/gpu/drm/i915/intel_dpll_mgr.c | 63
> > > > > +--
> > > > > drivers/gpu/drm/i915/intel_dpll_mgr.h | 2 ++
> > > > > 2 files changed, 47 insertions(+), 18 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > > > > b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > > > > index 132fe63e042a..d4c7bacbe83e 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > > > > +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > > > > @@ -2812,25 +2812,31 @@ static bool
> icl_calc_mg_pll_state(struct
> > > > > intel_crtc_state *crtc_state,
> > > > > MG_PLL_SSC_FLLEN |
> > > > >
> MG_PLL_SSC_STEPSIZE(ssc_stepsize);
> > > > >
> > > > > - pll_state->mg_pll_tdc_coldst_bias =
> > > > > MG_PLL_TDC_COLDST_COLDSTART;
> > > > > + pll_state->mg_pll_tdc_coldst_bias =
> > > > > MG_PLL_TDC_COLDST_COLDSTART |
> > > > > +
> > > > > MG_PLL_TDC_COLDST_IREFINT_EN |
> > > > > +
> > > > > MG_PLL_TDC_COLDST_REFBIAS_START_PULSE_W(iref_pulse_w) |
> > > > > +
> MG_PLL_TDC_TDCOVCCORR_EN |
> > > > > + MG_PLL_TDC_TDCSEL(3);
> > > > >
> > > > > - if (refclk_khz != 38400) {
> > > > > - pll_state->mg_pll_tdc_coldst_bias |=
> > > > > - MG_PLL_TDC_COLDST_IREFINT_EN |
> > > > > -
> > > > > MG_PLL_TDC_COLDST_REFBIAS_START_PULSE_W(iref_pulse_w) |
> > > > > - MG_PLL_TDC_COLDST_COLDSTART |
> > > > > - MG_PLL_TDC_TDCOVCCORR_EN |
> > > > > - MG_PLL_TDC_TDCSEL(3);
> > > > > + pll_state->mg_pll_bias = MG_PLL_BIAS_BIAS_GB_SEL(3) |
> > > > > + MG_PLL_BIAS_INIT_DCOAMP(0x3F)
> |
> > > > > + MG_PLL_BIAS_BIAS_BONUS(10) |
> > > > > + MG_PLL_BIAS_BIASCAL_EN |
> > > > > + MG_PLL_BIAS_CTRIM(12) |
> > > > > + MG_PLL_BIAS_VREF_RDAC(4) |
> > > > > + MG_PLL_BIAS_IREFTRIM(iref_trim);
> > > > >
> > > > > - pll_state->mg_pll_bias =
> MG_PLL_BIAS_BIAS_GB_SEL(3) |
> > > > > -
> MG_PLL_BIAS_INIT_DCOAMP(0x3F)
> > > > > |
> > > > > -
> MG_PLL_BIAS_BIAS_BONUS(10) |
> > > > > - MG_PLL_BIAS_BIASCAL_EN
> |
> > > > > - MG_PLL_BIAS_CTRIM(12) |
> > > > > -
> MG_PLL_BIAS_VREF_RDAC(4) |
> > > > > -
> MG_PLL_BIAS_IREFTRIM(iref_trim);
> > > > > + if (refclk_khz == 38400) {
> > > > > + pll_state->mg_pll_tdc_coldst_bias_mask =
> > > > > MG_PLL_TDC_COLDST_COLDSTART;
> > > > > + pll_state->mg_pll_bias_mask = 0;
> > > > > + } else {
> > > > > + pll_state->mg_pll_tdc_coldst_bias_mask = -1U;
> > > > > + pll_state->mg_pll_bias_mask = -1U;
> > > > > }
> > > > >
> > > > > + pll_state->mg_pll_tdc_coldst_bias &= pll_state-
> > > > > >mg_pll_tdc_coldst_bias_mask;
> > > > > +
Re: [Intel-gfx] [RFC] drm/i915: Fix assert_plane() warning on bootup with external display
On Mon, Jun 18, 2018 at 09:40:38PM +, Shaikh, Azhar wrote: > > > >-Original Message- > >From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] > >Sent: Monday, June 18, 2018 4:57 AM > >To: Jani Nikula > >Cc: Shaikh, Azhar ; intel-gfx@lists.freedesktop.org > >Subject: Re: [Intel-gfx] [RFC] drm/i915: Fix assert_plane() warning on bootup > >with external display > > > >On Mon, Jun 18, 2018 at 11:18:52AM +0300, Jani Nikula wrote: > >> On Sun, 17 Jun 2018, Azhar Shaikh wrote: > >> > On KBL, WHL RVPs, booting up with an external display connected, > >> > triggers below warning. This warning is not seen during hotplug. > >> > > >> > [3.615226] [ cut here ] > >> > [3.619829] plane 1A assertion failure (expected on, current off) > >> > [3.632039] WARNING: CPU: 2 PID: 354 at > >drivers/gpu/drm/i915/intel_display.c:1294 assert_plane+0x71/0xbb > >> > [3.633920] iwlwifi :00:14.3: loaded firmware version > >> > 38.c0e03d94.0 > >op_mode iwlmvm > >> > [3.647157] Modules linked in: iwlwifi cfg80211 btusb btrtl btbcm > >> > btintel > >bluetooth ecdh_generic > >> > [3.647163] CPU: 2 PID: 354 Comm: frecon Not tainted 4.17.0-rc7-50176- > >g655af12d39c2 #3 > >> > [3.647165] Hardware name: Intel Corporation CoffeeLake Client > >Platform/WhiskeyLake U DDR4 ERB, BIOS > >CNLSFWR1.R00.X140.B00.1804040304 04/04/2018 > >> > [3.684509] RIP: 0010:assert_plane+0x71/0xbb > >> > [3.764451] Call Trace: > >> > [3.766888] intel_atomic_commit_tail+0xa97/0xb77 > >> > [3.771569] intel_atomic_commit+0x26a/0x279 > >> > [3.771572] drm_atomic_helper_set_config+0x5c/0x76 > >> > [3.780670] __drm_mode_set_config_internal+0x66/0x109 > >> > [3.780672] drm_mode_setcrtc+0x4c9/0x5cc > >> > [3.780674] ? drm_mode_getcrtc+0x162/0x162 > >> > [3.789774] ? drm_mode_getcrtc+0x162/0x162 > >> > [3.798108] drm_ioctl_kernel+0x8d/0xe4 > >> > [3.801926] drm_ioctl+0x27d/0x368 > >> > [3.805311] ? drm_mode_getcrtc+0x162/0x162 > >> > [3.805314] ? selinux_file_ioctl+0x14e/0x199 > >> > [3.805317] vfs_ioctl+0x21/0x2f > >> > [3.813812] do_vfs_ioctl+0x491/0x4b4 > >> > [3.813813] ? security_file_ioctl+0x37/0x4b > >> > [3.813816] ksys_ioctl+0x55/0x75 > >> > [3.820672] __x64_sys_ioctl+0x1a/0x1e > >> > [3.820674] do_syscall_64+0x51/0x5f > >> > [3.820678] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > >> > [3.828221] RIP: 0033:0x7b5e04953967 > >> > [3.835504] RSP: 002b:7fff2eafb6f8 EFLAGS: 0246 ORIG_RAX: > >0010 > >> > [3.835505] RAX: ffda RBX: 0002 RCX: > >7b5e04953967 > >> > [3.835505] RDX: 7fff2eafb730 RSI: c06864a2 RDI: > >000f > >> > [3.835506] RBP: 7fff2eafb720 R08: R09: > > > >> > [3.835507] R10: 0070 R11: 0246 R12: > >000f > >> > [3.879988] R13: 56bc9dd7d210 R14: 7fff2eafb730 R15: > >c06864a2 > >> > [3.887081] Code: 48 c7 c7 06 71 a5 be 84 c0 48 c7 c2 06 fd a3 be 48 > >> > 89 f9 48 > >0f 44 ca 84 db 48 0f 45 d7 48 c7 c7 df d3 a4 be 31 c0 e8 af a0 c0 ff <0f> 0b > >eb 2b > >48 c7 c7 06 fd a3 be 84 c0 48 c7 c2 06 71 a5 be 48 > >> > [3.905845] WARNING: CPU: 2 PID: 354 at > >drivers/gpu/drm/i915/intel_display.c:1294 assert_plane+0x71/0xbb > >> > [3.920964] ---[ end trace dac692f4ac46391a ]--- > >> > > >> > The warning is seen when mode_setcrtc() is called for pipeB during > >> > bootup and before we get a mode_setcrtc() for pipeA, while doing > >> > update_crtcs() in intel_atomic_commit_tail(). > >> > Now since, plane1A is still active after commit, update_crtcs() is > >> > done for pipeA and eventually update_plane() for plane1A. > >> > > >> > intel_plane_state->ctl for plane1A is not updated since > >> > set_modecrtc() is called for pipeB. So intel_plane_state->ctl for plane > >> > 1A > >will be 0x0. > >> > So doing an update_plane() for plane1A, will result in clearing > >> > PLANE_CTL_ENABLE bit, and hence the warning. > >> > > >> > To fix this warning, prior to updating the PLANE_CTL register with > >> > intel_plane_state->ctl value, read PLANE_CTL register, OR it with > >> > intel_plane_state->ctl and then write it to PLANE_CTL register > >> > instead of just relying on intel_plane_state->ctl value. > >> > > >> > Signed-off-by: Azhar Shaikh > >> > --- > >> > drivers/gpu/drm/i915/intel_sprite.c | 3 +++ > >> > 1 file changed, 3 insertions(+) > >> > > >> > diff --git a/drivers/gpu/drm/i915/intel_sprite.c > >> > b/drivers/gpu/drm/i915/intel_sprite.c > >> > index 344c0e709b19..b491b1fbdea1 100644 > >> > --- a/drivers/gpu/drm/i915/intel_sprite.c > >> > +++ b/drivers/gpu/drm/i915/intel_sprite.c > >> > @@ -254,6 +254,7 @@ void intel_pipe_update_end(struct > >intel_crtc_state *new_crtc_state) > >> > uint32_t src_w = drm_rect_width(_state->base.src) >> 16; > >> > uint32_t src_h =
[Intel-gfx] [PATCH i-g-t 6/6] igt/gem_exec_latency: Measure polling latency between batches
Signed-off-by: Chris Wilson
---
tests/gem_exec_latency.c | 50
1 file changed, 50 insertions(+)
diff --git a/tests/gem_exec_latency.c b/tests/gem_exec_latency.c
index d64dd73ab..ea2e4c681 100644
--- a/tests/gem_exec_latency.c
+++ b/tests/gem_exec_latency.c
@@ -60,6 +60,51 @@
static unsigned int ring_size;
+static void
+poll_ring(int fd, unsigned ring, const char *name)
+{
+ struct timespec tv = {};
+ unsigned long cycles;
+ igt_spin_t *spin[2];
+ uint64_t elapsed;
+ uint32_t cmd;
+
+ gem_require_ring(fd, ring);
+ igt_require(gem_can_store_dword(fd, ring));
+
+ spin[0] = __igt_spin_batch_new_poll(fd, 0, ring);
+ igt_assert(spin[0]->running);
+ cmd = *spin[0]->batch;
+
+ spin[1] = __igt_spin_batch_new_poll(fd, 0, ring);
+ igt_assert(spin[1]->running);
+ igt_assert(cmd == *spin[1]->batch);
+
+ igt_spin_batch_end(spin[0]);
+ while (!READ_ONCE(*spin[1]->running))
+ ;
+ igt_assert(!gem_bo_busy(fd, spin[0]->handle));
+
+ cycles = 0;
+ while ((elapsed = igt_nsec_elapsed()) < 2ull << 30) {
+ unsigned int idx = cycles++ & 1;
+
+ *spin[idx]->batch = cmd;
+ *spin[idx]->running = 0;
+ gem_execbuf(fd, [idx]->execbuf);
+
+ igt_spin_batch_end(spin[!idx]);
+ while (!READ_ONCE(*spin[idx]->running))
+ ;
+ }
+
+ igt_info("%s completed %ld cycles: %.3f us\n",
+name, cycles, elapsed*1e-3/cycles);
+
+ igt_spin_batch_free(fd, spin[1]);
+ igt_spin_batch_free(fd, spin[0]);
+}
+
#define RCS_TIMESTAMP (0x2000 + 0x358)
static void latency_on_ring(int fd,
unsigned ring, const char *name,
@@ -611,6 +656,11 @@ igt_main
e->exec_id | e->flags,
e->name, 0);
+ igt_subtest_f("%s-poll", e->name)
+ poll_ring(device,
+ e->exec_id | e->flags,
+ e->name);
+
igt_subtest_f("%s-rtidle-submit", e->name)
rthog_latency_on_ring(device,
e->exec_id |
--
2.18.0.rc2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 4/6] igt/gem_exec_nop: Drip feed nops
Wait until the previous nop batch is running before submitting the next.
This prevents the kernel from batching up sequential requests into a
a ringfull, more strenuous exercising the "lite-restore" execution path.
Signed-off-by: Chris Wilson
---
tests/gem_exec_nop.c | 146 +--
1 file changed, 142 insertions(+), 4 deletions(-)
diff --git a/tests/gem_exec_nop.c b/tests/gem_exec_nop.c
index 50f0a3aad..0523b1c02 100644
--- a/tests/gem_exec_nop.c
+++ b/tests/gem_exec_nop.c
@@ -104,6 +104,129 @@ static double nop_on_ring(int fd, uint32_t handle,
unsigned ring_id,
return elapsed(, );
}
+static void poll_ring(int fd, unsigned ring, const char *name, int timeout)
+{
+ const int gen = intel_gen(intel_get_drm_devid(fd));
+ const uint32_t MI_ARB_CHK = 0x5 << 23;
+ struct drm_i915_gem_execbuffer2 execbuf;
+ struct drm_i915_gem_exec_object2 obj;
+ struct drm_i915_gem_relocation_entry reloc[4], *r;
+ uint32_t *bbe[2], *state, *batch;
+ unsigned engines[16], nengine, flags;
+ struct timespec tv = {};
+ unsigned long cycles;
+ uint64_t elapsed;
+
+ flags = I915_EXEC_NO_RELOC;
+ if (gen == 4 || gen == 5)
+ flags |= I915_EXEC_SECURE;
+
+ nengine = 0;
+ if (ring == ALL_ENGINES) {
+ for_each_physical_engine(fd, ring) {
+ if (!gem_can_store_dword(fd, ring))
+ continue;
+
+ engines[nengine++] = ring;
+ }
+ } else {
+ gem_require_ring(fd, ring);
+ igt_require(gem_can_store_dword(fd, ring));
+ engines[nengine++] = ring;
+ }
+ igt_require(nengine);
+
+ memset(, 0, sizeof(obj));
+ obj.handle = gem_create(fd, 4096);
+ obj.relocs_ptr = to_user_pointer(reloc);
+ obj.relocation_count = ARRAY_SIZE(reloc);
+
+ r = memset(reloc, 0, sizeof(reloc));
+ batch = gem_mmap__wc(fd, obj.handle, 0, 4096, PROT_WRITE);
+
+ for (unsigned int start_offset = 0;
+start_offset <= 128;
+start_offset += 128) {
+ uint32_t *b = batch + start_offset / sizeof(*batch);
+
+ r->target_handle = obj.handle;
+ r->offset = (b - batch + 1) * sizeof(uint32_t);
+ r->delta = 4092;
+ r->read_domains = I915_GEM_DOMAIN_RENDER;
+
+ *b = MI_STORE_DWORD_IMM | (gen < 6 ? 1 << 22 : 0);
+ if (gen >= 8) {
+ *++b = r->delta;
+ *++b = 0;
+ } else if (gen >= 4) {
+ r->offset += sizeof(uint32_t);
+ *++b = 0;
+ *++b = r->delta;
+ } else {
+ *b -= 1;
+ *++b = r->delta;
+ }
+ *++b = start_offset != 0;
+ r++;
+
+ b = batch + (start_offset + 64) / sizeof(*batch);
+ bbe[start_offset != 0] = b;
+ *b++ = MI_ARB_CHK;
+
+ r->target_handle = obj.handle;
+ r->offset = (b - batch + 1) * sizeof(uint32_t);
+ r->read_domains = I915_GEM_DOMAIN_COMMAND;
+ r->delta = start_offset + 64;
+ if (gen >= 8) {
+ *b++ = MI_BATCH_BUFFER_START | 1 << 8 | 1;
+ *b++ = r->delta;
+ *b++ = 0;
+ } else if (gen >= 6) {
+ *b++ = MI_BATCH_BUFFER_START | 1 << 8;
+ *b++ = r->delta;
+ } else {
+ *b++ = MI_BATCH_BUFFER_START | 2 << 6;
+ if (gen < 4)
+ r->delta |= 1;
+ *b++ = r->delta;
+ }
+ r++;
+ }
+ igt_assert(r == reloc + ARRAY_SIZE(reloc));
+ state = batch + 1023;
+
+ memset(, 0, sizeof(execbuf));
+ execbuf.buffers_ptr = to_user_pointer();
+ execbuf.buffer_count = 1;
+ execbuf.flags = engines[0];
+
+ cycles = 0;
+ do {
+ unsigned int idx = ++cycles & 1;
+
+ *bbe[idx] = MI_ARB_CHK;
+ execbuf.batch_start_offset =
+ (bbe[idx] - batch) * sizeof(*batch) - 64;
+
+ execbuf.flags = engines[cycles % nengine] | flags;
+ gem_execbuf(fd, );
+
+ *bbe[!idx] = MI_BATCH_BUFFER_END;
+ __sync_synchronize();
+
+ while (READ_ONCE(*state) != idx)
+ ;
+ } while ((elapsed = igt_nsec_elapsed()) >> 30 < timeout);
+ *bbe[cycles & 1] = MI_BATCH_BUFFER_END;
+ gem_sync(fd, obj.handle);
+
+ igt_info("%s completed %ld cycles: %.3f us\n",
+name, cycles, elapsed*1e-3/cycles);
+
+ munmap(batch, 4096);
+ gem_close(fd, obj.handle);
+}
+
[Intel-gfx] [PATCH i-g-t 5/6] tests/gem_exec_latency: New subtests for checking submission from RT tasks
From: Tvrtko Ursulin
We want to make sure RT tasks which use a lot of CPU times can submit
batch buffers with roughly the same latency (and certainly not worse)
compared to normal tasks.
v2: Add tests to run across all engines simultaneously to encourage
ksoftirqd to kick in even more often.
v3: More passes to improve measurement stability.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson #v1
Signed-off-by: Chris Wilson
---
tests/gem_exec_latency.c | 234 +++
1 file changed, 234 insertions(+)
diff --git a/tests/gem_exec_latency.c b/tests/gem_exec_latency.c
index 9498c0921..d64dd73ab 100644
--- a/tests/gem_exec_latency.c
+++ b/tests/gem_exec_latency.c
@@ -36,11 +36,15 @@
#include
#include
#include
+#include
#include "drm.h"
#include "igt_sysfs.h"
#include "igt_vgem.h"
+#include "igt_dummyload.h"
+#include "igt_stats.h"
+
#include "i915/gem_ring.h"
#define LOCAL_I915_EXEC_NO_RELOC (1<<11)
@@ -351,6 +355,216 @@ static void latency_from_ring(int fd,
}
}
+static void __rearm_spin_batch(igt_spin_t *spin)
+{
+ const uint32_t mi_arb_chk = 0x5 << 23;
+
+ *spin->batch = mi_arb_chk;
+ *spin->running = 0;
+ __sync_synchronize();
+}
+
+static void
+__submit_spin_batch(int fd, igt_spin_t *spin, unsigned int flags)
+{
+ struct drm_i915_gem_execbuffer2 eb = spin->execbuf;
+
+ eb.flags &= ~(0x3f | I915_EXEC_BSD_MASK);
+ eb.flags |= flags | I915_EXEC_NO_RELOC;
+
+ gem_execbuf(fd, );
+}
+
+struct rt_pkt {
+ struct igt_mean mean;
+ double min, max;
+};
+
+static bool __spin_wait(int fd, igt_spin_t *spin)
+{
+ while (!READ_ONCE(*spin->running)) {
+ if (!gem_bo_busy(fd, spin->handle))
+ return false;
+ }
+
+ return true;
+}
+
+/*
+ * Test whether RT thread which hogs the CPU a lot can submit work with
+ * reasonable latency.
+ */
+static void
+rthog_latency_on_ring(int fd, unsigned int engine, const char *name, unsigned
int flags)
+#define RTIDLE 0x1
+{
+ const char *passname[] = {
+ "warmup",
+ "normal",
+ "rt[0]",
+ "rt[1]",
+ "rt[2]",
+ "rt[3]",
+ "rt[4]",
+ "rt[5]",
+ "rt[6]",
+ };
+#define NPASS ARRAY_SIZE(passname)
+#define MMAP_SZ (64 << 10)
+ struct rt_pkt *results;
+ unsigned int engines[16];
+ const char *names[16];
+ unsigned int nengine;
+ int ret;
+
+ igt_assert(ARRAY_SIZE(engines) * NPASS * sizeof(*results) <= MMAP_SZ);
+ results = mmap(NULL, MMAP_SZ, PROT_WRITE, MAP_SHARED | MAP_ANON, -1, 0);
+ igt_assert(results != MAP_FAILED);
+
+ nengine = 0;
+ if (engine == ALL_ENGINES) {
+ for_each_physical_engine(fd, engine) {
+ if (!gem_can_store_dword(fd, engine))
+ continue;
+
+ engines[nengine] = engine;
+ names[nengine] = e__->name;
+ nengine++;
+ }
+ igt_require(nengine > 1);
+ } else {
+ igt_require(gem_can_store_dword(fd, engine));
+ engines[nengine] = engine;
+ names[nengine] = name;
+ nengine++;
+ }
+
+ gem_quiescent_gpu(fd);
+
+ igt_fork(child, nengine) {
+ unsigned int pass = 0; /* Three phases: warmup, normal, rt. */
+
+ engine = engines[child];
+ do {
+ struct igt_mean mean;
+ double min = HUGE_VAL;
+ double max = -HUGE_VAL;
+ igt_spin_t *spin;
+
+ igt_mean_init();
+
+ if (pass == 2) {
+ struct sched_param rt =
+ { .sched_priority = 99 };
+
+ ret = sched_setscheduler(0,
+SCHED_FIFO |
SCHED_RESET_ON_FORK,
+);
+ if (ret) {
+ igt_warn("Failed to set scheduling
policy!\n");
+ break;
+ }
+ }
+
+ usleep(250);
+
+ spin = __igt_spin_batch_new_poll(fd, 0, engine);
+ if (!spin) {
+ igt_warn("Failed to create spinner! (%s)\n",
+passname[pass]);
+ break;
+ }
+ igt_spin_busywait_until_running(spin);
+
+ igt_until_timeout(pass > 0 ? 5 : 2) {
+ struct timespec ts = { };
+ double t;
+
+
[Intel-gfx] [PATCH i-g-t 2/6] igt/gem_sync: Alternate stress for nop+sync
Apply a different sort of stress by timing how long it takes to sync a
second nop batch in the pipeline. We first start a spinner on the
engine, then when we know the GPU is active, we submit the second nop;
start timing as we then release the spinner and wait for the nop to
complete.
As with every other gem_sync test, it serves two roles. The first is
that it checks that we do not miss a wakeup under common stressful
conditions (the more conditions we check, the happier we will be that
they do not occur in practice). And the second role it fulfils, is that
it provides a very crude estimate for how long it takes for a nop to
execute from a running start (we already have a complimentary estimate
for an idle start).
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
---
tests/gem_sync.c | 90
1 file changed, 90 insertions(+)
diff --git a/tests/gem_sync.c b/tests/gem_sync.c
index 1e2e089a1..4cd97c58b 100644
--- a/tests/gem_sync.c
+++ b/tests/gem_sync.c
@@ -177,6 +177,92 @@ idle_ring(int fd, unsigned ring, int timeout)
gem_close(fd, object.handle);
}
+static void
+wakeup_ring(int fd, unsigned ring, int timeout)
+{
+ unsigned engines[16];
+ const char *names[16];
+ int num_engines = 0;
+
+ if (ring == ALL_ENGINES) {
+ for_each_physical_engine(fd, ring) {
+ if (!gem_can_store_dword(fd, ring))
+ continue;
+
+ names[num_engines] = e__->name;
+ engines[num_engines++] = ring;
+ if (num_engines == ARRAY_SIZE(engines))
+ break;
+ }
+ igt_require(num_engines);
+ } else {
+ gem_require_ring(fd, ring);
+ igt_require(gem_can_store_dword(fd, ring));
+ names[num_engines] = NULL;
+ engines[num_engines++] = ring;
+ }
+
+ intel_detect_and_clear_missed_interrupts(fd);
+ igt_fork(child, num_engines) {
+ const uint32_t bbe = MI_BATCH_BUFFER_END;
+ struct drm_i915_gem_exec_object2 object;
+ struct drm_i915_gem_execbuffer2 execbuf;
+ double end, this, elapsed, now;
+ unsigned long cycles;
+ uint32_t cmd;
+ igt_spin_t *spin;
+
+ memset(, 0, sizeof(object));
+ object.handle = gem_create(fd, 4096);
+ gem_write(fd, object.handle, 0, , sizeof(bbe));
+
+ memset(, 0, sizeof(execbuf));
+ execbuf.buffers_ptr = to_user_pointer();
+ execbuf.buffer_count = 1;
+ execbuf.flags = engines[child % num_engines];
+
+ spin = __igt_spin_batch_new_poll(fd, 0, execbuf.flags);
+ igt_assert(spin->running);
+ cmd = *spin->batch;
+
+ gem_execbuf(fd, );
+
+ igt_spin_batch_end(spin);
+ gem_sync(fd, object.handle);
+
+ end = gettime() + timeout;
+ elapsed = 0;
+ cycles = 0;
+ do {
+ *spin->batch = cmd;
+ *spin->running = 0;
+ gem_execbuf(fd, >execbuf);
+ while (!READ_ONCE(*spin->running))
+ ;
+
+ gem_execbuf(fd, );
+
+ this = gettime();
+ igt_spin_batch_end(spin);
+ gem_sync(fd, object.handle);
+ now = gettime();
+
+ elapsed += now - this;
+ cycles++;
+ } while (now < end);
+
+ igt_info("%s%sompleted %ld cycles: %.3f us\n",
+names[child % num_engines] ?: "",
+names[child % num_engines] ? " c" : "C",
+cycles, elapsed*1e6/cycles);
+
+ igt_spin_batch_free(fd, spin);
+ gem_close(fd, object.handle);
+ }
+ igt_waitchildren_timeout(timeout+10, NULL);
+ igt_assert_eq(intel_detect_and_clear_missed_interrupts(fd), 0);
+}
+
static void
store_ring(int fd, unsigned ring, int num_children, int timeout)
{
@@ -762,6 +848,8 @@ igt_main
sync_ring(fd, e->exec_id | e->flags, 1, 150);
igt_subtest_f("idle-%s", e->name)
idle_ring(fd, e->exec_id | e->flags, 150);
+ igt_subtest_f("wakeup-%s", e->name)
+ wakeup_ring(fd, e->exec_id | e->flags, 150);
igt_subtest_f("store-%s", e->name)
store_ring(fd, e->exec_id | e->flags, 1, 150);
igt_subtest_f("many-%s", e->name)
@@ -782,6 +870,8 @@ igt_main
sync_ring(fd, ALL_ENGINES, ncpus, 150);
igt_subtest("forked-store-each")
store_ring(fd, ALL_ENGINES, ncpus,
[Intel-gfx] [PATCH i-g-t 1/6] lib: Conservatively include residue buffers in the available ram estimate
Add any buffers reported by sysinfo to the estimate of available memory. We do ask the kernel to purge it's caches before reporting sysinfo, but a few remain that may be forced out by our test usage, so include them. However, be conservative and only allow them to be swapped out. References: https://bugs.freedesktop.org/show_bug.cgi?id=105967 Signed-off-by: Chris Wilson --- lib/intel_os.c | 1 + 1 file changed, 1 insertion(+) diff --git a/lib/intel_os.c b/lib/intel_os.c index 88a61f378..885ffdcec 100644 --- a/lib/intel_os.c +++ b/lib/intel_os.c @@ -105,6 +105,7 @@ intel_get_avail_ram_mb(void) igt_assert(sysinfo() == 0); retval = sysinf.freeram; + retval += min(sysinf.freeswap, sysinf.bufferram); retval *= sysinf.mem_unit; #elif defined(_SC_PAGESIZE) && defined(_SC_AVPHYS_PAGES) /* Solaris */ long pagesize, npages; -- 2.18.0.rc2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 3/6] igt/gem_sync: Double the wakeups, twice the pain
To further defeat any contemplated spin-optimisations to avoid the irq
latency for synchronous wakeups, increase the queue length.
Signed-off-by: Chris Wilson
---
tests/gem_sync.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/tests/gem_sync.c b/tests/gem_sync.c
index 4cd97c58b..5901e1476 100644
--- a/tests/gem_sync.c
+++ b/tests/gem_sync.c
@@ -178,7 +178,7 @@ idle_ring(int fd, unsigned ring, int timeout)
}
static void
-wakeup_ring(int fd, unsigned ring, int timeout)
+wakeup_ring(int fd, unsigned ring, int timeout, int wlen)
{
unsigned engines[16];
const char *names[16];
@@ -240,7 +240,8 @@ wakeup_ring(int fd, unsigned ring, int timeout)
while (!READ_ONCE(*spin->running))
;
- gem_execbuf(fd, );
+ for (int n = 0; n < wlen; n++)
+ gem_execbuf(fd, );
this = gettime();
igt_spin_batch_end(spin);
@@ -849,7 +850,9 @@ igt_main
igt_subtest_f("idle-%s", e->name)
idle_ring(fd, e->exec_id | e->flags, 150);
igt_subtest_f("wakeup-%s", e->name)
- wakeup_ring(fd, e->exec_id | e->flags, 150);
+ wakeup_ring(fd, e->exec_id | e->flags, 150, 1);
+ igt_subtest_f("double-wakeup-%s", e->name)
+ wakeup_ring(fd, e->exec_id | e->flags, 150, 2);
igt_subtest_f("store-%s", e->name)
store_ring(fd, e->exec_id | e->flags, 1, 150);
igt_subtest_f("many-%s", e->name)
@@ -871,7 +874,9 @@ igt_main
igt_subtest("forked-store-each")
store_ring(fd, ALL_ENGINES, ncpus, 150);
igt_subtest("wakeup-each")
- wakeup_ring(fd, ALL_ENGINES, 150);
+ wakeup_ring(fd, ALL_ENGINES, 150, 1);
+ igt_subtest("double-wakeup-each")
+ wakeup_ring(fd, ALL_ENGINES, 150, 2);
igt_subtest("basic-all")
sync_all(fd, 1, 5);
--
2.18.0.rc2
___
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/icl: Fix MG PLL setup when refclk is 38.4MHz
On Tue, Jun 19, 2018 at 09:07:25AM +0300, Kulkarni, Vandita wrote:
> > -Original Message-
> > From: Deak, Imre
> > Sent: Monday, June 18, 2018 2:45 PM
> > To: Kulkarni, Vandita
> > Cc: intel-gfx@lists.freedesktop.org; Zanoni, Paulo R
> > ; Ausmus, James
> > Subject: Re: [PATCH 1/2] drm/i915/icl: Fix MG PLL setup when refclk is
> > 38.4MHz
> >
> > On Mon, Jun 18, 2018 at 11:11:30AM +0300, Kulkarni, Vandita wrote:
> > >
> > >
> > > > -Original Message-
> > > > From: Deak, Imre
> > > > Sent: Friday, June 15, 2018 8:09 PM
> > > > To: intel-gfx@lists.freedesktop.org
> > > > Cc: Kulkarni, Vandita ; Zanoni, Paulo R
> > > > ; Ausmus, James
> >
> > > > Subject: [PATCH 1/2] drm/i915/icl: Fix MG PLL setup when refclk is
> > > > 38.4MHz
> > > >
> > > > Atm we're zeroing out fields in MG_PLL_BIAS and
> > > > MG_PLL_TDC_COLDST_BIAS if refclk is 38.4MHz, whereas the spec tells
> > > > us to preserve them.
> > > > Although the calculated values mostly match the register defaults
> > > > even for the 38.4MHz case, there are some differences wrt. what BIOS
> > > > programs (I noticed at least differences in the MG_PLL_BIAS/IREFTRIM
> > > > and MG_PLL_BIAS/BIASCAL_EN fields). In the lack of further info on
> > > > how to program these fields, just do what the spec says and preserve
> > > > the BIOS state.
> > > >
> > > > v2:
> > > > - Preserve the BIOS programmed reg fields instead of programming
> > them.
> > > >
> > > > Cc: Vandita Kulkarni
> > > > Cc: Paulo Zanoni
> > > > Cc: James Ausmus
> > > > Signed-off-by: Imre Deak
> > > > Reviewed-by: James Ausmus (v1)
> > > > ---
> > > > drivers/gpu/drm/i915/intel_dpll_mgr.c | 63
> > > > +--
> > > > drivers/gpu/drm/i915/intel_dpll_mgr.h | 2 ++
> > > > 2 files changed, 47 insertions(+), 18 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > > > b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > > > index 132fe63e042a..d4c7bacbe83e 100644
> > > > --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > > > +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > > > @@ -2812,25 +2812,31 @@ static bool icl_calc_mg_pll_state(struct
> > > > intel_crtc_state *crtc_state,
> > > > MG_PLL_SSC_FLLEN |
> > > > MG_PLL_SSC_STEPSIZE(ssc_stepsize);
> > > >
> > > > - pll_state->mg_pll_tdc_coldst_bias =
> > > > MG_PLL_TDC_COLDST_COLDSTART;
> > > > + pll_state->mg_pll_tdc_coldst_bias =
> > > > MG_PLL_TDC_COLDST_COLDSTART |
> > > > +
> > > > MG_PLL_TDC_COLDST_IREFINT_EN |
> > > > +
> > > > MG_PLL_TDC_COLDST_REFBIAS_START_PULSE_W(iref_pulse_w) |
> > > > + MG_PLL_TDC_TDCOVCCORR_EN |
> > > > + MG_PLL_TDC_TDCSEL(3);
> > > >
> > > > - if (refclk_khz != 38400) {
> > > > - pll_state->mg_pll_tdc_coldst_bias |=
> > > > - MG_PLL_TDC_COLDST_IREFINT_EN |
> > > > -
> > > > MG_PLL_TDC_COLDST_REFBIAS_START_PULSE_W(iref_pulse_w) |
> > > > - MG_PLL_TDC_COLDST_COLDSTART |
> > > > - MG_PLL_TDC_TDCOVCCORR_EN |
> > > > - MG_PLL_TDC_TDCSEL(3);
> > > > + pll_state->mg_pll_bias = MG_PLL_BIAS_BIAS_GB_SEL(3) |
> > > > +MG_PLL_BIAS_INIT_DCOAMP(0x3F) |
> > > > +MG_PLL_BIAS_BIAS_BONUS(10) |
> > > > +MG_PLL_BIAS_BIASCAL_EN |
> > > > +MG_PLL_BIAS_CTRIM(12) |
> > > > +MG_PLL_BIAS_VREF_RDAC(4) |
> > > > +MG_PLL_BIAS_IREFTRIM(iref_trim);
> > > >
> > > > - pll_state->mg_pll_bias = MG_PLL_BIAS_BIAS_GB_SEL(3) |
> > > > -MG_PLL_BIAS_INIT_DCOAMP(0x3F)
> > > > |
> > > > -MG_PLL_BIAS_BIAS_BONUS(10) |
> > > > -MG_PLL_BIAS_BIASCAL_EN |
> > > > -MG_PLL_BIAS_CTRIM(12) |
> > > > -MG_PLL_BIAS_VREF_RDAC(4) |
> > > > -
> > > > MG_PLL_BIAS_IREFTRIM(iref_trim);
> > > > + if (refclk_khz == 38400) {
> > > > + pll_state->mg_pll_tdc_coldst_bias_mask =
> > > > MG_PLL_TDC_COLDST_COLDSTART;
> > > > + pll_state->mg_pll_bias_mask = 0;
> > > > + } else {
> > > > + pll_state->mg_pll_tdc_coldst_bias_mask = -1U;
> > > > + pll_state->mg_pll_bias_mask = -1U;
> > > > }
> > > >
> > > > + pll_state->mg_pll_tdc_coldst_bias &= pll_state-
> > > > >mg_pll_tdc_coldst_bias_mask;
> > > > + pll_state->mg_pll_bias &= pll_state->mg_pll_bias_mask;
> > > > +
> > > > return true;
> > > > }
> > > >
> > > > @@ -2948,9 +2954,21 @@ static bool icl_pll_get_hw_state(struct
> > > > drm_i915_private *dev_priv,
Re: [Intel-gfx] [PATCH xf86-video-intel] sna: Replace the blt SYNC_COPY assert with a check
Quoting Ville Syrjala (2018-06-18 18:39:43) > From: Ville Syrjälä > > My IVB hits the SYNC_COPY assert in prefer_blt_copy() when I force the > use of the software cursor and I move the cursor on top of a dri2 > window. Looks like any platform with sna_wait_for_scanline() implemented > should be capable of tripping this assert. > > Let's just replace the assert with a check, which is what gen6 already > does. IVB/HSW/BDW have sna_wait_for_scanline() so we'll have to change > the gen7 and gen8 code at least. gen9+ doesn't have sna_wait_for_scanline() > so in theory we could leave that one be, but I like consistency so let's > change that one too. Hmm, my memory says that the assertion was concerned with making sure the wait-for-event + copy operation was in the same batch. At any rate it seems like the swcursor is breaking a few of my assumptions, so before acting I'd like to tidy up the validation logic to check if it is not working as intended. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] lib: Conservatively include residue buffers in the available ram estimate
Add any buffers reported by sysinfo to the estimate of available memory. We do ask the kernel to purge it's caches before reporting sysinfo, but a few remain that may be forced out by our test usage, so include them. However, be conservative and only allow them to be swapped out. References: https://bugs.freedesktop.org/show_bug.cgi?id=105967 Signed-off-by: Chris Wilson --- lib/intel_os.c | 1 + 1 file changed, 1 insertion(+) diff --git a/lib/intel_os.c b/lib/intel_os.c index 88a61f378..885ffdcec 100644 --- a/lib/intel_os.c +++ b/lib/intel_os.c @@ -105,6 +105,7 @@ intel_get_avail_ram_mb(void) igt_assert(sysinfo() == 0); retval = sysinf.freeram; + retval += min(sysinf.freeswap, sysinf.bufferram); retval *= sysinf.mem_unit; #elif defined(_SC_PAGESIZE) && defined(_SC_AVPHYS_PAGES) /* Solaris */ long pagesize, npages; -- 2.18.0.rc2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] gvt-next
Hi, Here is first gvt-next pull for next 4.19 kernel. Mostly on gvt optimizations and has added BXT support for GVT-g. Thanks. --- The following changes since commit 14c3f8425080a1ff97df7b81f7c339bf42c427a3: drm/i915: Update DRIVER_DATE to 20180606 (2018-06-06 15:10:47 -0700) are available in the Git repository at: https://github.com/intel/gvt-linux.git tags/gvt-next-2018-06-19 for you to fetch changes up to 57c8a484a9cbf1315b5299702d12aef04867: drm/i915: Enable KVMGT for BXT. (2018-06-13 10:57:30 +0800) gvt-next-2018-06-19 - fine-grained per vgpu locking (Colin) - fine-grained vgpu scheduler locking (Colin) - deliver windows guest cursor hotspot info (Tina) - GVT-g BXT support (Colin) - other misc and checker fixes (Chris, Xinyun) Chris Wilson (1): drm/i915/gvt: Use offsetofend() rather than offsetof + sizeof Colin Xu (14): drm/i915/gvt: Use vgpu_lock to protect per vgpu access drm/i915/gvt: Use sched_lock to protect gvt scheduler logic. drm/i915/gvt: Add D_BXT device type define for BXT. drm/i915/gvt: Add MEDIA_POOL_STATE for BXT. drm/i915/gvt: Enable device info initialization for BXT. drm/i915/gvt: Enable gtt initialization for BXT. drm/i915/gvt: Enable irq initialization for BXT. drm/i915/gvt: Enable mmio context init and switch for BXT. drm/i915/gvt: Enable cmd_parser support for BXT. drm/i915/gvt: Enable force wake support for BXT. drm/i915/gvt: Enable virtual display support for BXT. drm/i915/gvt: Enable dma_buf support for BXT. drm/i915/gvt: Add mmio handler for for BXT. drm/i915: Enable KVMGT for BXT. Tina Zhang (1): drm/i915/gvt: Deliver guest cursor hotspot info Xinyun Liu (3): drm/i915/gvt: Avoid dereference a potential null pointer drm/i915/gvt: removed unnecessary boundary check drm/i915/gvt: use array to avoid potential buffer overflow Zhenyu Wang (1): Merge tag 'drm-intel-next-2018-06-06' into gvt-next drivers/gpu/drm/i915/gvt/cmd_parser.c | 43 ++-- drivers/gpu/drm/i915/gvt/display.c | 58 +++-- drivers/gpu/drm/i915/gvt/dmabuf.c | 26 ++- drivers/gpu/drm/i915/gvt/edid.c | 20 +- drivers/gpu/drm/i915/gvt/execlist.h | 13 +- drivers/gpu/drm/i915/gvt/fb_decoder.c | 15 +- drivers/gpu/drm/i915/gvt/firmware.c | 2 +- drivers/gpu/drm/i915/gvt/gtt.c | 11 +- drivers/gpu/drm/i915/gvt/gvt.c | 27 +-- drivers/gpu/drm/i915/gvt/gvt.h | 16 ++ drivers/gpu/drm/i915/gvt/handlers.c | 399 drivers/gpu/drm/i915/gvt/interrupt.c| 17 +- drivers/gpu/drm/i915/gvt/mmio.c | 12 +- drivers/gpu/drm/i915/gvt/mmio.h | 11 +- drivers/gpu/drm/i915/gvt/mmio_context.c | 16 +- drivers/gpu/drm/i915/gvt/page_track.c | 5 +- drivers/gpu/drm/i915/gvt/sched_policy.c | 36 ++- drivers/gpu/drm/i915/gvt/scheduler.c| 25 +- drivers/gpu/drm/i915/gvt/vgpu.c | 56 ++--- drivers/gpu/drm/i915/i915_pvinfo.h | 5 +- drivers/gpu/drm/i915/intel_gvt.c| 2 + 21 files changed, 612 insertions(+), 203 deletions(-) -- Open Source Technology Center, Intel ltd. $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827 signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/psr: Adds psrwake options for all platforms
On Mon, 18 Jun 2018, Dhinakaran Pandiyan wrote:
> On Mon, 2018-06-18 at 11:42 +0530, vathsala nagaraju wrote:
>> From: Vathsala Nagaraju
>>
>> Adds new psrwake options defined in the below table.
>> Platform PSR wake options vbt version
>> KBL/CFL/WHL All(205+)
>> BXT Uses old interpretation.
>> CNL/ICL+ All(205+)
>> GLK All(205+)
>> SKL All PV releases (Check for 205+ might help but
>> cannot be foolproof)
>>
>> We will continue with newer interpretation for SKL from 205.
> Let's hope this works for most machines out there.
>
> It'd be easier to distinguish newer updated patches if you use version
> numbers.
>
> Reviewed-by: Dhinakaran Pandiyan
Thanks for the patch and review, pushed to dinq with the checkpatch
warnings fixed while at it.
BR,
Jani.
>
>>
>> v2: Jani
>> Keep the bdb version check.
>> v3:
>> Apply newer version for skl from 205+(DK).
>> Add (version check && platform list) (Jani).
>> Add bdb version for each platform in commit message(DK).
>>
>> Cc: Jani Nikula
>> Cc: Rodrigo Vivi
>> Cc: Puthikorn Voravootivat
>> Cc: Dhinakaran Pandiyan
>> Cc: Ashutosh D Shukla
>> Cc: Maulik V Vaghela
>>
>> Signed-off-by: Vathsala Nagaraju
>> ---
>> drivers/gpu/drm/i915/intel_bios.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_bios.c
>> b/drivers/gpu/drm/i915/intel_bios.c
>> index 465dff4..9ef0464 100644
>> --- a/drivers/gpu/drm/i915/intel_bios.c
>> +++ b/drivers/gpu/drm/i915/intel_bios.c
>> @@ -710,7 +710,8 @@ static int intel_bios_ssc_frequency(struct
>> drm_i915_private *dev_priv,
>> * New psr options 0=500us, 1=100us, 2=2500us, 3=0us
>> * Old decimal value is wake up time in multiples of 100 us.
>> */
>> -if (bdb->version >= 209 && IS_GEN9_BC(dev_priv)) {
>> +if (bdb->version >= 205 && (IS_GEN9_BC(dev_priv) ||
>> +IS_GEMINILAKE(dev_priv) || (INTEL_GEN(dev_priv) >= 10)))
>> {
>> switch (psr_table->tp1_wakeup_time) {
>> case 0:
>> dev_priv->vbt.psr.tp1_wakeup_time_us = 500;
--
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/4] drm/i915: fix guest virtual PCH detection on non-PCH systems
On Wed, Jun 13, 2018 at 11:57 PM Arkadiusz Hiler wrote: > > On Wed, Jun 13, 2018 at 10:16:07AM -0700, Lucas De Marchi wrote: > > On Wed, Jun 13, 2018 at 10:09 AM Lucas De Marchi > > wrote: > > > > > > On Wed, Jun 13, 2018 at 1:11 AM Arkadiusz Hiler > > > wrote: > > > > > > > > On Wed, Jun 13, 2018 at 09:49:09AM +0300, Jani Nikula wrote: > > > > > On Tue, 12 Jun 2018, Lucas De Marchi > > > > > wrote: > > > > > > On Fri, Jun 8, 2018 at 5:34 AM Jani Nikula > > > > > > wrote: > > > > > >> > > > > > >> On Thu, 31 May 2018, Lucas De Marchi > > > > > >> wrote: > > > > > >> > On Thu, May 31, 2018 at 02:56:21PM +0300, Jani Nikula wrote: > > > > > >> >> Virtualized non-PCH systems such as Broxton or Geminilake > > > > > >> >> should use > > > > > >> >> PCH_NONE to indicate no PCH rather than PCH_NOP. The latter is a > > > > > >> >> specific case to indicate a PCH system without south display. > > > > > >> > > > > > > >> > Then let's go ahead and document it? > > > > > >> > > > > > >> Please avoid sending suggestion patches in-reply-to existing > > > > > >> series. This confused patchwork and screwed up CI for the series, > > > > > >> which > > > > > >> was already a resend just to get CI. :( > > > > > > > > > > > > ugh, sorry. Sometimes just adding a oneline diff is much better > > > > > > than > > > > > > a hundred words explaining :( ... > > > > > > > > > > I feel you, a patch is more precise. > > > > > > > > > > > IMO pw is trying to be smarter than it should here or not being > > > > > > smart > > > > > > enough. Nonetheless I won't do that anymore. > > > > > > > > > > I think there were earlier complaints about what it did recognize and > > > > > what it didn't. I'd be open to only accepting new versions of patches > > > > > from whoever sent the original patch. Or requiring patch subjects > > > > > don't > > > > > start with "Re:". Or both. > > > > > > > > No matter what you do here it will misbehave in some scenarios and > > > > break someone's workflow :< > > > > > > > > Originally we required the patches to have X-Mailer set to > > > > git-send-email, which seems reasonable, but that annoyed people because > > > > their servers were stripping out those headers. > > > > > > > > Other people send out the patches by feeding them to the drafts folder > > > > through IMAP and then sending them out. This, depending on the > > > > provider's configuration, also gobbles up a thing or two. > > > > > > > > Because of the above I am not sure about trusting "Re:" and matching > > > > "From:" headers as good enough indicators either. > > > > > > > > It just adds more opaque "smartness". I already can foresee questions > > > > asking "why my v2 was not picked up?" and someone would have to debug it > > > > down the line. > > > > > > > > Was the address different (+XYZ before @)? Has that someone used > > > > --subject-prefix=re:? Is it an actual bug? Etc. > > > > > > > > > > > > > I was annoyed, but I'm perhaps more annoyed that you can't do this > > > > > without confusing patchwork. In the end, I wouldn't want to hamper > > > > > review by blocking something that comes naturally to people. > > > > > > > > > > Arek? > > > > > > > > Just add the following header: > > > > "X-Patchwork-Hint: comment" > > > > to emails that you type out manually. > > > > > > > > For mutt it's as easy as adding: > > > > "my_hdr X-Patchwork-Hint: comment" > > > > to your .muttrc > > > > > > This may not work for the same reasons you pointed out that wouldn't > > > work if people are sending patches. Is there a format I can use that > > > will not trigger patchwork from parsing a _reply_? Does removing the > > > "" help? Under the hood does it use git am --scissors or > > > similar? > > Yeah, it's far for perfection and needs additional effort to set the > header up. For me it works, but I always send patches via git-send-email > and always send replies via mutt - I am the simple case. > > > Humn... it has its own parser. So if I read > > https://github.com/dlespiau/patchwork/blob/master/patchwork/parser.py#L36 > > correctly, it should be just a matter of omitting the "diff | ---" > > lines (or prepending with a "#"). > > > > It does make things more difficult if the other person would use "git > > am --scissors" though. > > > > Lucas De Marchi > > Yes, that is my understanding as well - if you would ommit the "diff > header" it should not recognize your mail as a patch. But that's yet > another behavior you have to know upfront. > > It's really hard to strike a balance here. > > One idea is to optimize for the default case (i.e. behavior of > git-send-email), sans the known quirks we have seen so far, > and write this down. > > Then, if some patches are getting ignored, this would make a handy > checklist that can be use for troubleshooting and we can also link to > it, kindly asking to adhere to a more standard way of sending patches. Agreed. Lucas De Marchi > > -- > Cheers, > Arek -- Lucas De Marchi
Re: [Intel-gfx] [PATCH 0/7] drm/i915: move towards kernel types
On Fri, Jun 15, 2018 at 2:08 AM Jani Nikula wrote: > > On Thu, 14 Jun 2018, Rodrigo Vivi wrote: > > On Wed, Jun 13, 2018 at 09:55:38AM +0300, Jani Nikula wrote: > >> On Tue, 12 Jun 2018, Lucas De Marchi wrote: > >> > On Tue, Jun 12, 2018 at 3:15 AM Jani Nikula > >> > wrote: > >> >> > >> >> On Tue, 12 Jun 2018, Tvrtko Ursulin > >> >> wrote: > >> >> > On 12/06/2018 10:19, Jani Nikula wrote: > >> >> >> Semi-RFC. Do we want to do this? Here's a batch of conversions that > >> >> >> shouldn't > >> >> >> conflict much with in-flight patches. > >> >> >> > >> >> >> The trouble with mixed use is that it's inconsistent, and any > >> >> >> remaining C99 > >> >> >> types will encourage their use. We could at least do the low hanging > >> >> >> fruit? > >> >> > > >> >> > Ack from me. Doesn't seem so big to cause much pain. > >> >> > > >> >> > When you say low-hanging fruit, that implies you only dealt with a > >> >> > particular class of occurrences? > >> >> > >> >> I meant the files which don't have massive amounts of C99 types and > >> >> aren't under active development right now. I just wanted to avoid > >> >> trouble for starters. ;) > >> > > >> > If using kernel types is where we want to go (which I agree with), > >> > maybe it would be better to have a single conversion rather than > >> > several small ones as we are doing with dev_priv -> i915? This allows > >> > in-flight-but-not-yet-sent patches to easily keep up with the changes > >> > rather than conflicting every other rebase. > >> > >> I'm thinking we can do a lot of changes without conflicting anything or > >> very little. At least for starters before the sudden ripping off the > >> band-aid. > > > > I'm with Lucas. I'd prefer one single massive move than many small ones. > > Easier for the internal maintenance. We fix it only once and not one per > > day for months and months like dev_priv/i915 case. > > For everything else, I believe smaller patches are easier. For example, > who is going to review the massive change? Halt everything until it's > reviewed and merged? For merge conflicts I think git can do a better job > of managing the rerere with piecemeal changes. Internal is not the only > consideration. A change like this would be a matter of having a sed/cocci/whatever script that can be reproduced later. The end result can be split in logical chunks for review/merge, I never said it ought to be in one patch. Lucas De Marchi > > BR, > Jani. > > > > >> > >> BR, > >> Jani. > >> > >> > > >> > Lucas De Marchi > >> > > >> >> > >> >> > Also going forward we have to make sure we will be able to stop them > >> >> > creeping back in. Is checkpatch perhaps covering this? Or we could put > >> >> > something in dim? > >> >> > >> >> We can stop ignoring PREFER_KERNEL_TYPES in checkpatch (the ignores are > >> >> in dim). We don't even have to change everything for that, we just need > >> >> to change enough to make the S/N better. People tend to use the types > >> >> near the places they change. > >> >> > >> >> BR, > >> >> Jani. > >> >> > >> >> > >> >> > > >> >> > Regards, > >> >> > > >> >> > Tvrtko > >> >> > > >> >> >> $ git grep "uint\(8\|16\|32\|64\)_t" -- drivers/gpu/drm/i915/ | sed > >> >> >> 's/:.*//' | sort | uniq -c | sort -n > >> >> >> > >> >> >> BR, > >> >> >> Jani. > >> >> >> > >> >> >> > >> >> >> Jani Nikula (7): > >> >> >>drm/i915/vbt: switch to kernel unsigned int types > >> >> >>drm/i915/hdmi: switch to kernel unsigned int types > >> >> >>drm/i915/uncore: switch to kernel unsigned int types > >> >> >>drm/i915/dvo: switch to kernel unsigned int types > >> >> >>drm/i915/backlight: switch to kernel unsigned int types > >> >> >>drm/i915/audio: switch to kernel unsigned int types > >> >> >>drm/i915/lspcon: switch to kernel unsigned int types > >> >> >> > >> >> >> drivers/gpu/drm/i915/dvo_ch7017.c | 20 ++-- > >> >> >> drivers/gpu/drm/i915/dvo_ch7xxx.c | 22 +++--- > >> >> >> drivers/gpu/drm/i915/dvo_ivch.c | 26 > >> >> >> drivers/gpu/drm/i915/dvo_ns2501.c | 44 > >> >> >> +-- > >> >> >> drivers/gpu/drm/i915/dvo_sil164.c | 10 +++--- > >> >> >> drivers/gpu/drm/i915/dvo_tfp410.c | 16 +- > >> >> >> drivers/gpu/drm/i915/intel_audio.c| 36 > >> >> >> +++--- > >> >> >> drivers/gpu/drm/i915/intel_bios.c | 4 +-- > >> >> >> drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 12 > >> >> >> drivers/gpu/drm/i915/intel_dvo.c | 2 +- > >> >> >> drivers/gpu/drm/i915/intel_hdmi.c | 14 - > >> >> >> drivers/gpu/drm/i915/intel_lspcon.c | 2 +- > >> >> >> drivers/gpu/drm/i915/intel_panel.c| 8 ++--- > >> >> >> drivers/gpu/drm/i915/intel_uncore.h | 22 +++--- > >> >> >> drivers/gpu/drm/i915/intel_vbt_defs.h | 2 +- > >> >> >> 15 files changed,
Re: [Intel-gfx] [PATCH 1/2] drm/i915/icl: Fix MG PLL setup when refclk is 38.4MHz
> -Original Message-
> From: Deak, Imre
> Sent: Monday, June 18, 2018 2:45 PM
> To: Kulkarni, Vandita
> Cc: intel-gfx@lists.freedesktop.org; Zanoni, Paulo R
> ; Ausmus, James
> Subject: Re: [PATCH 1/2] drm/i915/icl: Fix MG PLL setup when refclk is
> 38.4MHz
>
> On Mon, Jun 18, 2018 at 11:11:30AM +0300, Kulkarni, Vandita wrote:
> >
> >
> > > -Original Message-
> > > From: Deak, Imre
> > > Sent: Friday, June 15, 2018 8:09 PM
> > > To: intel-gfx@lists.freedesktop.org
> > > Cc: Kulkarni, Vandita ; Zanoni, Paulo R
> > > ; Ausmus, James
>
> > > Subject: [PATCH 1/2] drm/i915/icl: Fix MG PLL setup when refclk is
> > > 38.4MHz
> > >
> > > Atm we're zeroing out fields in MG_PLL_BIAS and
> > > MG_PLL_TDC_COLDST_BIAS if refclk is 38.4MHz, whereas the spec tells
> > > us to preserve them.
> > > Although the calculated values mostly match the register defaults
> > > even for the 38.4MHz case, there are some differences wrt. what BIOS
> > > programs (I noticed at least differences in the MG_PLL_BIAS/IREFTRIM
> > > and MG_PLL_BIAS/BIASCAL_EN fields). In the lack of further info on
> > > how to program these fields, just do what the spec says and preserve
> > > the BIOS state.
> > >
> > > v2:
> > > - Preserve the BIOS programmed reg fields instead of programming
> them.
> > >
> > > Cc: Vandita Kulkarni
> > > Cc: Paulo Zanoni
> > > Cc: James Ausmus
> > > Signed-off-by: Imre Deak
> > > Reviewed-by: James Ausmus (v1)
> > > ---
> > > drivers/gpu/drm/i915/intel_dpll_mgr.c | 63
> > > +--
> > > drivers/gpu/drm/i915/intel_dpll_mgr.h | 2 ++
> > > 2 files changed, 47 insertions(+), 18 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > > b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > > index 132fe63e042a..d4c7bacbe83e 100644
> > > --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > > +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > > @@ -2812,25 +2812,31 @@ static bool icl_calc_mg_pll_state(struct
> > > intel_crtc_state *crtc_state,
> > > MG_PLL_SSC_FLLEN |
> > > MG_PLL_SSC_STEPSIZE(ssc_stepsize);
> > >
> > > - pll_state->mg_pll_tdc_coldst_bias =
> > > MG_PLL_TDC_COLDST_COLDSTART;
> > > + pll_state->mg_pll_tdc_coldst_bias =
> > > MG_PLL_TDC_COLDST_COLDSTART |
> > > +
> > > MG_PLL_TDC_COLDST_IREFINT_EN |
> > > +
> > > MG_PLL_TDC_COLDST_REFBIAS_START_PULSE_W(iref_pulse_w) |
> > > + MG_PLL_TDC_TDCOVCCORR_EN |
> > > + MG_PLL_TDC_TDCSEL(3);
> > >
> > > - if (refclk_khz != 38400) {
> > > - pll_state->mg_pll_tdc_coldst_bias |=
> > > - MG_PLL_TDC_COLDST_IREFINT_EN |
> > > -
> > > MG_PLL_TDC_COLDST_REFBIAS_START_PULSE_W(iref_pulse_w) |
> > > - MG_PLL_TDC_COLDST_COLDSTART |
> > > - MG_PLL_TDC_TDCOVCCORR_EN |
> > > - MG_PLL_TDC_TDCSEL(3);
> > > + pll_state->mg_pll_bias = MG_PLL_BIAS_BIAS_GB_SEL(3) |
> > > + MG_PLL_BIAS_INIT_DCOAMP(0x3F) |
> > > + MG_PLL_BIAS_BIAS_BONUS(10) |
> > > + MG_PLL_BIAS_BIASCAL_EN |
> > > + MG_PLL_BIAS_CTRIM(12) |
> > > + MG_PLL_BIAS_VREF_RDAC(4) |
> > > + MG_PLL_BIAS_IREFTRIM(iref_trim);
> > >
> > > - pll_state->mg_pll_bias = MG_PLL_BIAS_BIAS_GB_SEL(3) |
> > > - MG_PLL_BIAS_INIT_DCOAMP(0x3F)
> > > |
> > > - MG_PLL_BIAS_BIAS_BONUS(10) |
> > > - MG_PLL_BIAS_BIASCAL_EN |
> > > - MG_PLL_BIAS_CTRIM(12) |
> > > - MG_PLL_BIAS_VREF_RDAC(4) |
> > > - MG_PLL_BIAS_IREFTRIM(iref_trim);
> > > + if (refclk_khz == 38400) {
> > > + pll_state->mg_pll_tdc_coldst_bias_mask =
> > > MG_PLL_TDC_COLDST_COLDSTART;
> > > + pll_state->mg_pll_bias_mask = 0;
> > > + } else {
> > > + pll_state->mg_pll_tdc_coldst_bias_mask = -1U;
> > > + pll_state->mg_pll_bias_mask = -1U;
> > > }
> > >
> > > + pll_state->mg_pll_tdc_coldst_bias &= pll_state-
> > > >mg_pll_tdc_coldst_bias_mask;
> > > + pll_state->mg_pll_bias &= pll_state->mg_pll_bias_mask;
> > > +
> > > return true;
> > > }
> > >
> > > @@ -2948,9 +2954,21 @@ static bool icl_pll_get_hw_state(struct
> > > drm_i915_private *dev_priv,
> > > hw_state->mg_pll_lf = I915_READ(MG_PLL_LF(port));
> > > hw_state->mg_pll_frac_lock =
> > > I915_READ(MG_PLL_FRAC_LOCK(port));
> > > hw_state->mg_pll_ssc = I915_READ(MG_PLL_SSC(port));
> > > +
> > > hw_state->mg_pll_bias = I915_READ(MG_PLL_BIAS(port));
> > > hw_state->mg_pll_tdc_coldst_bias =
> > > I915_READ(MG_PLL_TDC_COLDST_BIAS(port));
> > > +
> > > + if (dev_priv->cdclk.hw.ref == 38400) {
> > > +
