Re: [Intel-gfx] [PATCH 2/2] drm/i915/edp/jsl: Update vswing table for HBR and HBR2
On Mon, 28 Sep 2020, Matt Roper wrote: > On Mon, Sep 28, 2020 at 04:07:39PM -0700, Lucas De Marchi wrote: >> On Mon, Sep 28, 2020 at 08:15:29PM +0300, Jani Nikula wrote: >> > On Mon, 28 Sep 2020, "Surendrakumar Upadhyay, TejaskumarX" >> > wrote: >> > > This is a good example of a potential trap that having >> > > IS_ELKHARTLAKE() cover both ELK and JSP creates. An unsuspecting coder >> > > might change the if ladder to have IS_ELKHARTLAKE() first, and the >> > > subsequent IS_JASPERLAKE() branch would never be taken. >> > > >> > > BR, >> > > Jani. >> > > >> > > Tejas : In that case I will put attention note in comment about >> > > platform checks such that ladder distrubance can be avoided. What you >> > > suggest? >> >> > The solution is to make IS_ELKHARTLAKE() mean ELK and only ELK. >> >> Since we are talking about the TLA for JSL in the other patch, for >> elkhartlake it is EHL, not ELK. ELK is something else, but I'm not sure >> what: >> >> $ git grep -w ELK -- drivers/gpu/drm/ >> drivers/gpu/drm/i915/gem/i915_gem_stolen.c: IS_GM45(i915) ? >> "CTG" : "ELK", reg_val); >> drivers/gpu/drm/i915/gem/i915_gem_stolen.c: * Whether ILK really reuses >> the ELK register for this is unclear. >> drivers/gpu/drm/i915/intel_pm.c: * Not 100% sure which way ELK >> should go here as the >> drivers/gpu/drm/i915/intel_pm.c: * assume ELK doesn't need this. > > Yeah, ELK = Eagle Lake, CTG = Cantiga. Both are old gen5 platforms IIRC. Yeah, I know, my bad. BR, Jani. > > > Matt > >> >> Lucas De Marchi >> >> > >> > BR, >> > Jani. >> > >> > >> > -- >> > Jani Nikula, Intel Open Source Graphics Center -- 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: Avoid mixing integer types during batch copies
== Series Details == Series: drm/i915: Avoid mixing integer types during batch copies URL : https://patchwork.freedesktop.org/series/82165/ State : success == Summary == CI Bug Log - changes from CI_DRM_9067_full -> Patchwork_18584_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_18584_full that come from known issues: ### IGT changes ### Issues hit * igt@device_reset@unbind-reset-rebind: - shard-iclb: [PASS][1] -> [DMESG-WARN][2] ([i915#1982]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9067/shard-iclb4/igt@device_re...@unbind-reset-rebind.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18584/shard-iclb4/igt@device_re...@unbind-reset-rebind.html * igt@feature_discovery@psr2: - shard-iclb: [PASS][3] -> [SKIP][4] ([i915#658]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9067/shard-iclb2/igt@feature_discov...@psr2.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18584/shard-iclb1/igt@feature_discov...@psr2.html * igt@gem_exec_whisper@basic-normal-all: - shard-glk: [PASS][5] -> [DMESG-WARN][6] ([i915#118] / [i915#95]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9067/shard-glk3/igt@gem_exec_whis...@basic-normal-all.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18584/shard-glk7/igt@gem_exec_whis...@basic-normal-all.html * igt@kms_big_fb@x-tiled-8bpp-rotate-0: - shard-apl: [PASS][7] -> [DMESG-WARN][8] ([i915#1635] / [i915#1982]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9067/shard-apl8/igt@kms_big...@x-tiled-8bpp-rotate-0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18584/shard-apl7/igt@kms_big...@x-tiled-8bpp-rotate-0.html * igt@kms_frontbuffer_tracking@fbc-suspend: - shard-kbl: [PASS][9] -> [DMESG-WARN][10] ([i915#180]) +11 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9067/shard-kbl2/igt@kms_frontbuffer_track...@fbc-suspend.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18584/shard-kbl7/igt@kms_frontbuffer_track...@fbc-suspend.html * igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-draw-mmap-cpu: - shard-tglb: [PASS][11] -> [DMESG-WARN][12] ([i915#1982]) +6 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9067/shard-tglb8/igt@kms_frontbuffer_track...@psr-1p-primscrn-spr-indfb-draw-mmap-cpu.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18584/shard-tglb5/igt@kms_frontbuffer_track...@psr-1p-primscrn-spr-indfb-draw-mmap-cpu.html * igt@kms_hdr@bpc-switch-dpms: - shard-skl: [PASS][13] -> [FAIL][14] ([i915#1188]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9067/shard-skl8/igt@kms_...@bpc-switch-dpms.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18584/shard-skl1/igt@kms_...@bpc-switch-dpms.html * igt@kms_plane@plane-position-covered-pipe-b-planes: - shard-skl: [PASS][15] -> [DMESG-WARN][16] ([i915#1982]) +8 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9067/shard-skl1/igt@kms_pl...@plane-position-covered-pipe-b-planes.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18584/shard-skl8/igt@kms_pl...@plane-position-covered-pipe-b-planes.html * igt@kms_plane_alpha_blend@pipe-b-constant-alpha-min: - shard-skl: [PASS][17] -> [FAIL][18] ([fdo#108145] / [i915#265]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9067/shard-skl8/igt@kms_plane_alpha_bl...@pipe-b-constant-alpha-min.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18584/shard-skl1/igt@kms_plane_alpha_bl...@pipe-b-constant-alpha-min.html * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc: - shard-skl: [PASS][19] -> [DMESG-FAIL][20] ([fdo#108145] / [i915#1982]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9067/shard-skl1/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18584/shard-skl5/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html * igt@kms_psr2_su@page_flip: - shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109642] / [fdo#111068]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9067/shard-iclb2/igt@kms_psr2_su@page_flip.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18584/shard-iclb1/igt@kms_psr2_su@page_flip.html * igt@kms_psr@psr2_suspend: - shard-iclb: [PASS][23] -> [SKIP][24] ([fdo#109441]) +2 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9067/shard-iclb2/igt@kms_psr@psr2_suspend.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18584/shard-iclb1/igt@kms_psr@psr2_suspend.html * igt@perf@polling-small-buf: - shard-skl:
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [CI,1/3] drm/i915: Cancel outstanding work after disabling heartbeats on an engine
== Series Details == Series: series starting with [CI,1/3] drm/i915: Cancel outstanding work after disabling heartbeats on an engine URL : https://patchwork.freedesktop.org/series/82167/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9067_full -> Patchwork_18585_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_18585_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_18585_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_18585_full: ### IGT changes ### Possible regressions * igt@gem_ctx_ringsize@active@bcs0: - shard-glk: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9067/shard-glk6/igt@gem_ctx_ringsize@act...@bcs0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18585/shard-glk9/igt@gem_ctx_ringsize@act...@bcs0.html Known issues Here are the changes found in Patchwork_18585_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@preservation-s3@rcs0: - shard-skl: [PASS][3] -> [INCOMPLETE][4] ([i915#198]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9067/shard-skl3/igt@gem_ctx_isolation@preservation...@rcs0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18585/shard-skl5/igt@gem_ctx_isolation@preservation...@rcs0.html * igt@gen9_exec_parse@allowed-all: - shard-skl: [PASS][5] -> [DMESG-WARN][6] ([i915#1436] / [i915#716]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9067/shard-skl9/igt@gen9_exec_pa...@allowed-all.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18585/shard-skl5/igt@gen9_exec_pa...@allowed-all.html * igt@i915_selftest@mock@contexts: - shard-skl: [PASS][7] -> [INCOMPLETE][8] ([i915#198] / [i915#2278]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9067/shard-skl2/igt@i915_selftest@m...@contexts.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18585/shard-skl9/igt@i915_selftest@m...@contexts.html * igt@kms_big_fb@x-tiled-8bpp-rotate-0: - shard-apl: [PASS][9] -> [DMESG-WARN][10] ([i915#1635] / [i915#1982]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9067/shard-apl8/igt@kms_big...@x-tiled-8bpp-rotate-0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18585/shard-apl6/igt@kms_big...@x-tiled-8bpp-rotate-0.html - shard-kbl: [PASS][11] -> [DMESG-WARN][12] ([i915#1982]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9067/shard-kbl7/igt@kms_big...@x-tiled-8bpp-rotate-0.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18585/shard-kbl4/igt@kms_big...@x-tiled-8bpp-rotate-0.html * igt@kms_big_fb@y-tiled-64bpp-rotate-180: - shard-iclb: [PASS][13] -> [DMESG-WARN][14] ([i915#1982]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9067/shard-iclb1/igt@kms_big...@y-tiled-64bpp-rotate-180.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18585/shard-iclb3/igt@kms_big...@y-tiled-64bpp-rotate-180.html * igt@kms_flip@2x-plain-flip-fb-recreate-interruptible@bc-hdmi-a1-hdmi-a2: - shard-glk: [PASS][15] -> [FAIL][16] ([i915#2122]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9067/shard-glk5/igt@kms_flip@2x-plain-flip-fb-recreate-interrupti...@bc-hdmi-a1-hdmi-a2.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18585/shard-glk9/igt@kms_flip@2x-plain-flip-fb-recreate-interrupti...@bc-hdmi-a1-hdmi-a2.html * igt@kms_flip@flip-vs-suspend@b-dp1: - shard-kbl: [PASS][17] -> [DMESG-WARN][18] ([i915#180]) +5 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9067/shard-kbl4/igt@kms_flip@flip-vs-susp...@b-dp1.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18585/shard-kbl1/igt@kms_flip@flip-vs-susp...@b-dp1.html * igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-fullscreen: - shard-tglb: [PASS][19] -> [DMESG-WARN][20] ([i915#1982]) +4 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9067/shard-tglb1/igt@kms_frontbuffer_track...@psr-1p-primscrn-spr-indfb-fullscreen.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18585/shard-tglb5/igt@kms_frontbuffer_track...@psr-1p-primscrn-spr-indfb-fullscreen.html * igt@kms_hdr@bpc-switch-suspend: - shard-skl: [PASS][21] -> [FAIL][22] ([i915#1188]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9067/shard-skl7/igt@kms_...@bpc-switch-suspend.html [22]: https://intel-g
Re: [Intel-gfx] [PATCH] drm/i915/selftests: Measure the energy consumed while in RC6
Quoting Lucas De Marchi (2020-09-29 00:56:54) > On Tue, Mar 24, 2020 at 1:45 PM Chris Wilson wrote: > > > > Measure and compare the energy consumed, as reported by the rapl MSR, > > by the GPU while in RC0 and RC6 states. Throw an error if RC6 does not > > at least halve the energy consumption of RC0, as this more than likely > > means we failed to enter RC0 correctly. > > > > If we can't measure the energy draw with the MSR, then it will report 0 > > for both measurements. Since the measurement works on all gen6+, this seems > > worth flagging as an error. > > I'm confused by this statement here. MSR is a *CPU* register and you are using > it here, mixed with RC6. How is that supposed to work with, e.g., dgfx? You abstract it with the right interface for hwmon. The card reports energy draw, so the test remains the same, verify that a low power state does consume substantially less energy (and if we can get fine enough granularity that the GT powerwells draw 0). -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] vfio/pci: Refine Intel IGD OpRegion support
Bypass the IGD initialization for Intel's dgfx devices with own expansion
ROM and the host/LPC bridge config space are no longer accessed.
v2: simply test if discrete or integrated gfx device
with root bus. (Alex Williamson)
Cc: Zhenyu Wang
Cc: Xiong Zhang
Cc: Hang Yuan
Cc: Stuart Summers
Signed-off-by: Lucas De Marchi
Signed-off-by: Fred Gao
---
drivers/vfio/pci/vfio_pci.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index f634c81998bb..9258ccfadb79 100644
--- a/drivers/vfio/pci/vfio_pci.c
+++ b/drivers/vfio/pci/vfio_pci.c
@@ -336,10 +336,11 @@ static int vfio_pci_enable(struct vfio_pci_device *vdev)
if (!vfio_vga_disabled() && vfio_pci_is_vga(pdev))
vdev->has_vga = true;
-
+ /* Intel's dgfx should not appear on root bus */
if (vfio_pci_is_vga(pdev) &&
pdev->vendor == PCI_VENDOR_ID_INTEL &&
- IS_ENABLED(CONFIG_VFIO_PCI_IGD)) {
+ IS_ENABLED(CONFIG_VFIO_PCI_IGD) &&
+ pci_is_root_bus(pdev->bus)) {
ret = vfio_pci_igd_init(vdev);
if (ret) {
pci_warn(pdev, "Failed to setup Intel IGD regions\n");
--
2.24.1.1.gb6d4d82bd5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] REGRESSION: in intel video driver following introduction of mm_struct.has_pinned
(+ intel-gfx for being i915 related) (+ Chris who has looked into the issue) Hi, Thanks for reporting! Could you open a bug report according to following instructions: https://gitlab.freedesktop.org/drm/intel/-/wikis/How-to-file-i915-bugs A full dmesg of a bad boot and git bisect logs will be helpful. Also, please describe when the problem happens, is it at boot? Are you getting the OOPS on every boot? For future reference, replying to a single thread helps keeping the attention focused. Regards, Joonas Quoting Tony Fischetti (2020-09-28 21:14:16) > After a length git bisection, I determined the commit that introduced > a change that ultimately caused a bug/oops null dereference (see below > for relevant syslog entries) was 008cfe4418b3dbda2ff.. (mm: Introduce > mm_struct.has_pinned) > > The RIP (according to syslog) occurs in function > `__get_user_pages_remote` and the last function to call it from the > i915 code is `gem_userptr_get_pages_worker` > More specifically, it appears to be the call to > `pin_user_pages_remote` in `gem_userptr_get_pages_worker` in > drivers/gpu/drm/i915/gem/i915_gem_userptr.c that directly leads to the > oops. > > Unfortunately, I don't know enough to try to fix and share the fix > myself, but I hope the information I provided is helpful. Please let > me know if there is any further information I can provide that might > be of use. > > BUG: kernel NULL pointer dereference, address: 0054 > #PF: supervisor write access in kernel mode > #PF: error_code(0x0002) - not-present page > Oops: 0002 [#1] PREEMPT SMP NOPTI > CPU: 8 PID: 497 Comm: kworker/u25:0 Not tainted > 5.9.0-rc7-alice-investigate-3+ #2 > Hardware name: LENOVO 10ST001QUS/312A, BIOS M1UKT4BA 11/11/2019 > Workqueue: i915-userptr-acquire __i915_gem_userptr_get_pages_worker [i915] > RIP: 0010:__get_user_pages_remote+0xa0/0x2d0 > Code: 85 e7 01 00 00 83 3b 01 0f 85 e0 01 00 00 f7 c1 00 00 04 00 0f > 84 12 01 00 00 65 48 8b 04 25 00 6d 01 00 48 8b 80 58 03 00 00 40 > 54 01 00 00 00 c6 04 24 00 4d 8d 6f 68 48 c7 44 24 10 00 00 > RSP: 0018:a1a58086bde0 EFLAGS: 00010206 > RAX: RBX: a1a58086be64 RCX: 00040001 > RDX: 07e9 RSI: 7f532f80 RDI: 92f22d89c480 > RBP: 7f532f80 R08: 92f23a188000 R09: > R10: R11: a1a58086bcfd R12: 92f23a188000 > R13: 92f22d89c480 R14: 00042003 R15: 92f22d89c480 > FS: () GS:92f23e40() knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: 0054 CR3: 16c0a002 CR4: 001706e0 > DR0: DR1: DR2: > DR3: DR6: fffe0ff0 DR7: 0400 > Call Trace: > __i915_gem_userptr_get_pages_worker+0x1ec/0x392 [i915] > process_one_work+0x1c7/0x310 > worker_thread+0x28/0x3c0 > ? set_worker_desc+0xb0/0xb0 > kthread+0x123/0x140 > ? kthread_use_mm+0xe0/0xe0 > ret_from_fork+0x1f/0x30 > Modules linked in: snd_hda_codec_hdmi snd_hda_codec_realtek > snd_hda_codec_generic ledtrig_audio iwlmvm mac80211 libarc4 > x86_pkg_temp_thermal intel_powerclamp iwlwifi coretemp i915 > crct10dif_pclmul crc32_pclmul crc32c_intel i2c_algo_bit > ghash_clmulni_intel drm_kms_helper syscopyarea sysfillrect sysimgblt > fb_sys_fops cec mei_hdcp wmi_bmof snd_hda_intel drm tpm_crb > snd_intel_dspcfg intel_wmi_thunderbolt snd_hda_codec snd_hwdep > aesni_intel crypto_simd glue_helper snd_hda_core cfg80211 i2c_i801 > snd_pcm intel_cstate pcspkr snd_timer mei_me i2c_smbus mei i2c_core > thermal wmi tpm_tis tpm_tis_core tpm rng_core acpi_pad ppdev lp > ip_tables x_tables > CR2: 0054 > ---[ end trace 8d080e8b96289c9e ]--- ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [patch 00/13] preempt: Make preempt count unconditional
On Wed 16-09-20 23:43:02, Daniel Vetter wrote: > I can > then figure out whether it's better to risk not spotting issues with > call_rcu vs slapping a memalloc_noio_save/restore around all these > critical section which force-degrades any allocation to GFP_ATOMIC at did you mean memalloc_noreclaim_* here? > most, but has the risk that we run into code that assumes "GFP_KERNEL > never fails for small stuff" and has a decidedly less tested fallback > path than rcu code. Even if the above then please note that memalloc_noreclaim_* or PF_MEMALLOC should be used with an extreme care. Essentially only for internal memory reclaimers. It grants access to _all_ the available memory so any abuse can be detrimental to the overall system operation. Allocation failure in this mode means that we are out of memory and any code relying on such an allocation has to carefuly consider failure. This is not a random allocation mode. -- Michal Hocko SUSE Labs ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] REGRESSION: in intel video driver following introduction of mm_struct.has_pinned
Quoting Joonas Lahtinen (2020-09-29 09:18:34) > (+ intel-gfx for being i915 related) > (+ Chris who has looked into the issue) > > Hi, > > Thanks for reporting! Fixed in commit a4d63c3732f1a0c91abcf5b7f32b4ef7dcd82025 Author: Jason A. Donenfeld Date: Mon Sep 28 12:35:07 2020 +0200 mm: do not rely on mm == current->mm in __get_user_pages_locked -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/i915/gt: Retire cancelled requests on unload
If we manage to hit the intel_gt_set_wedged_on_fini() while active, i.e.
module unload during a stress test, we may cancel the requests but not
clean up. This leads to a very slow module unload as we wait for
something or other to trigger the retirement flushing, or timeout and
unload with a bunch of warnings. Instead if we explicitly cancel then
cleanup on an active unload, it should be instant and quiet.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_reset.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c
b/drivers/gpu/drm/i915/gt/intel_reset.c
index ac36b67fb46b..4e5e13dc95da 100644
--- a/drivers/gpu/drm/i915/gt/intel_reset.c
+++ b/drivers/gpu/drm/i915/gt/intel_reset.c
@@ -19,6 +19,7 @@
#include "intel_engine_pm.h"
#include "intel_gt.h"
#include "intel_gt_pm.h"
+#include "intel_gt_requests.h"
#include "intel_reset.h"
#include "uc/intel_guc.h"
@@ -1370,6 +1371,7 @@ void intel_gt_set_wedged_on_fini(struct intel_gt *gt)
{
intel_gt_set_wedged(gt);
set_bit(I915_WEDGED_ON_FINI, >->reset.flags);
+ intel_gt_retire_requests(gt); /* cleanup any wedged requests */
}
void intel_gt_init_reset(struct intel_gt *gt)
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] drm/i915/gt: Signal cancelled requests
After marking the requests on an engine as cancelled upon wedging, send
any signals for their completions.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 1 +
drivers/gpu/drm/i915/gt/intel_ring_submission.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 1a1c3b077b7b..287537089c77 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -4407,6 +4407,7 @@ static void execlists_reset_cancel(struct intel_engine_cs
*engine)
/* Mark all executing requests as skipped. */
list_for_each_entry(rq, &engine->active.requests, sched.link)
mark_eio(rq);
+ intel_engine_signal_breadcrumbs(engine);
/* Flush the queued requests to the timeline list (for retiring). */
while ((rb = rb_first_cached(&execlists->queue))) {
diff --git a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
index 16b48e72c369..a41b43f445b8 100644
--- a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
@@ -444,6 +444,7 @@ static void reset_cancel(struct intel_engine_cs *engine)
i915_request_set_error_once(request, -EIO);
i915_request_mark_complete(request);
}
+ intel_engine_signal_breadcrumbs(engine);
/* Remaining _unready_ requests will be nop'ed when submitted */
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/i915/selftests: Finish pending mock requests on cancellation.
Flush all the pending requests from the mock engine when they are
cancelled.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/mock_engine.c | 29 +++
1 file changed, 25 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/mock_engine.c
b/drivers/gpu/drm/i915/gt/mock_engine.c
index dfd1cfb8a7ec..df52fed3c0d0 100644
--- a/drivers/gpu/drm/i915/gt/mock_engine.c
+++ b/drivers/gpu/drm/i915/gt/mock_engine.c
@@ -245,19 +245,40 @@ static void mock_reset_rewind(struct intel_engine_cs
*engine, bool stalled)
GEM_BUG_ON(stalled);
}
+static void mark_eio(struct i915_request *rq)
+{
+ if (i915_request_completed(rq))
+ return;
+
+ GEM_BUG_ON(i915_request_signaled(rq));
+
+ i915_request_set_error_once(rq, -EIO);
+ i915_request_mark_complete(rq);
+}
+
static void mock_reset_cancel(struct intel_engine_cs *engine)
{
- struct i915_request *request;
+ struct mock_engine *mock =
+ container_of(engine, typeof(*mock), base);
+ struct i915_request *rq;
unsigned long flags;
+ del_timer_sync(&mock->hw_delay);
+
spin_lock_irqsave(&engine->active.lock, flags);
/* Mark all submitted requests as skipped. */
- list_for_each_entry(request, &engine->active.requests, sched.link) {
- i915_request_set_error_once(request, -EIO);
- i915_request_mark_complete(request);
+ list_for_each_entry(rq, &engine->active.requests, sched.link)
+ mark_eio(rq);
+
+ /* Cancel and submit all pending requests. */
+ list_for_each_entry(rq, &mock->hw_queue, mock.link) {
+ mark_eio(rq);
+ __i915_request_submit(rq);
}
+ INIT_LIST_HEAD(&mock->hw_queue);
+ intel_engine_signal_breadcrumbs(engine);
spin_unlock_irqrestore(&engine->active.lock, flags);
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Avoid mixing integer types during batch copies
Chris Wilson writes:
> Be consistent and use unsigned long throughout the chunk copies to
> avoid the inherent clumsiness of mixing integer types of different
> widths and signs. Failing to take acount of a wider unsigned type when
> using min_t can lead to treating it as a negative, only for it flip back
> to a large unsigned value after passing a boundary check.
>
> Fixes: ed13033f0287 ("drm/i915/cmdparser: Only cache the dst vmap")
> Testcase: igt/gen9_exec_parse/bb-large
> Reported-by: "Candelaria, Jared"
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> Cc: Joonas Lahtinen
> Cc: "Candelaria, Jared"
> Cc: "Bloomfield, Jon"
> Cc: # v4.9+
Reviewed-by: Mika Kuoppala
> ---
> The alternative would be to use u32 throughout, but that would also mean
> keeping the min_t(u32, ...). unsigned long decouples the mechanism from
> the API limits, so long as we remember to enforce that the mechanism
> copes with the entire range of the API.
> ---
> drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 7 +--
> drivers/gpu/drm/i915/i915_cmd_parser.c | 10 +-
> drivers/gpu/drm/i915/i915_drv.h| 4 ++--
> 3 files changed, 12 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index 5509946f1a1d..4b09bcd70cf4 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -2267,8 +2267,8 @@ struct eb_parse_work {
> struct i915_vma *batch;
> struct i915_vma *shadow;
> struct i915_vma *trampoline;
> - unsigned int batch_offset;
> - unsigned int batch_length;
> + unsigned long batch_offset;
> + unsigned long batch_length;
> };
>
> static int __eb_parse(struct dma_fence_work *work)
> @@ -2338,6 +2338,9 @@ static int eb_parse_pipeline(struct i915_execbuffer *eb,
> struct eb_parse_work *pw;
> int err;
>
> + GEM_BUG_ON(overflows_type(eb->batch_start_offset, pw->batch_offset));
> + GEM_BUG_ON(overflows_type(eb->batch_len, pw->batch_length));
> +
> pw = kzalloc(sizeof(*pw), GFP_KERNEL);
> if (!pw)
> return -ENOMEM;
> diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c
> b/drivers/gpu/drm/i915/i915_cmd_parser.c
> index 5ac4a999f05a..e88970256e8e 100644
> --- a/drivers/gpu/drm/i915/i915_cmd_parser.c
> +++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
> @@ -1136,7 +1136,7 @@ find_reg(const struct intel_engine_cs *engine, u32 addr)
> /* Returns a vmap'd pointer to dst_obj, which the caller must unmap */
> static u32 *copy_batch(struct drm_i915_gem_object *dst_obj,
> struct drm_i915_gem_object *src_obj,
> -u32 offset, u32 length)
> +unsigned long offset, unsigned long length)
> {
> bool needs_clflush;
> void *dst, *src;
> @@ -1166,8 +1166,8 @@ static u32 *copy_batch(struct drm_i915_gem_object
> *dst_obj,
> }
> }
> if (IS_ERR(src)) {
> + unsigned long x, n;
> void *ptr;
> - int x, n;
>
> /*
>* We can avoid clflushing partial cachelines before the write
> @@ -1184,7 +1184,7 @@ static u32 *copy_batch(struct drm_i915_gem_object
> *dst_obj,
> ptr = dst;
> x = offset_in_page(offset);
> for (n = offset >> PAGE_SHIFT; length; n++) {
> - int len = min_t(int, length, PAGE_SIZE - x);
> + int len = min(length, PAGE_SIZE - x);
>
> src = kmap_atomic(i915_gem_object_get_page(src_obj, n));
> if (needs_clflush)
> @@ -1414,8 +1414,8 @@ static bool shadow_needs_clflush(struct
> drm_i915_gem_object *obj)
> */
> int intel_engine_cmd_parser(struct intel_engine_cs *engine,
> struct i915_vma *batch,
> - u32 batch_offset,
> - u32 batch_length,
> + unsigned long batch_offset,
> + unsigned long batch_length,
> struct i915_vma *shadow,
> bool trampoline)
> {
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 72a9449b674e..eef9a821c49c 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1949,8 +1949,8 @@ void intel_engine_init_cmd_parser(struct
> intel_engine_cs *engine);
> void intel_engine_cleanup_cmd_parser(struct intel_engine_cs *engine);
> int intel_engine_cmd_parser(struct intel_engine_cs *engine,
> struct i915_vma *batch,
> - u32 batch_offset,
> - u32 batch_length,
> + unsigned long batch_offset,
> + unsigned long batch_length,
> struct i915_vma *shadow,
>
Re: [Intel-gfx] [patch 00/13] preempt: Make preempt count unconditional
On Tue, Sep 29, 2020 at 10:19:38AM +0200, Michal Hocko wrote: > On Wed 16-09-20 23:43:02, Daniel Vetter wrote: > > I can > > then figure out whether it's better to risk not spotting issues with > > call_rcu vs slapping a memalloc_noio_save/restore around all these > > critical section which force-degrades any allocation to GFP_ATOMIC at > > did you mean memalloc_noreclaim_* here? Yeah I picked the wrong one of that family of functions. > > most, but has the risk that we run into code that assumes "GFP_KERNEL > > never fails for small stuff" and has a decidedly less tested fallback > > path than rcu code. > > Even if the above then please note that memalloc_noreclaim_* or > PF_MEMALLOC should be used with an extreme care. Essentially only for > internal memory reclaimers. It grants access to _all_ the available > memory so any abuse can be detrimental to the overall system operation. > Allocation failure in this mode means that we are out of memory and any > code relying on such an allocation has to carefuly consider failure. > This is not a random allocation mode. Agreed, that's why I don't like having these kind of automagic critical sections. It's a bit a shotgun approach. Paul said that the code would handle failures, but the problem is that it applies everywhere. Anyway my understanding is that call_rcu will be reworked and gain a pile of tricks so that these problems for the callchains leading to call_rcu all disappear. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] vfio/pci: Refine Intel IGD OpRegion support
On 2020.09.30 00:10:38 +0800, Fred Gao wrote:
> Bypass the IGD initialization for Intel's dgfx devices with own expansion
> ROM and the host/LPC bridge config space are no longer accessed.
>
> v2: simply test if discrete or integrated gfx device
> with root bus. (Alex Williamson)
>
Patch title is somehow misleading that better change to what this one does
that skip VFIO IGD setup for Intel discrete graphics card.
With that,
Reviewed-by: Zhenyu Wang
> Cc: Zhenyu Wang
> Cc: Xiong Zhang
> Cc: Hang Yuan
> Cc: Stuart Summers
> Signed-off-by: Lucas De Marchi
> Signed-off-by: Fred Gao
> ---
> drivers/vfio/pci/vfio_pci.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
> index f634c81998bb..9258ccfadb79 100644
> --- a/drivers/vfio/pci/vfio_pci.c
> +++ b/drivers/vfio/pci/vfio_pci.c
> @@ -336,10 +336,11 @@ static int vfio_pci_enable(struct vfio_pci_device *vdev)
> if (!vfio_vga_disabled() && vfio_pci_is_vga(pdev))
> vdev->has_vga = true;
>
> -
> + /* Intel's dgfx should not appear on root bus */
> if (vfio_pci_is_vga(pdev) &&
> pdev->vendor == PCI_VENDOR_ID_INTEL &&
> - IS_ENABLED(CONFIG_VFIO_PCI_IGD)) {
> + IS_ENABLED(CONFIG_VFIO_PCI_IGD) &&
> + pci_is_root_bus(pdev->bus)) {
> ret = vfio_pci_igd_init(vdev);
> if (ret) {
> pci_warn(pdev, "Failed to setup Intel IGD regions\n");
> --
> 2.24.1.1.gb6d4d82bd5
>
--
$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
[Intel-gfx] [PATCH i-g-t v2] i915/gen9_exec_parse: Check parsing of large objects
Simply check that we support parsing of batches as large as the uAPI
allows.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
Try a few intermediate object sizes since CI machines do not have enough
memory to reach the upper bounds of the uAPI.
---
tests/i915/gen9_exec_parse.c | 47
1 file changed, 47 insertions(+)
diff --git a/tests/i915/gen9_exec_parse.c b/tests/i915/gen9_exec_parse.c
index 8cd82f568..f735e7e1c 100644
--- a/tests/i915/gen9_exec_parse.c
+++ b/tests/i915/gen9_exec_parse.c
@@ -566,6 +566,50 @@ static void test_bb_start(const int i915, const uint32_t
handle, int test)
gem_close(i915, target_bo);
}
+static void test_bb_large(int i915)
+{
+ const uint32_t bbe = MI_BATCH_BUFFER_END;
+ static const uint32_t sizes[] = {
+ (1ull << 30) - 4096,
+ (1ull << 30) + 4096,
+ (2ull << 30) - 4096,
+ (2ull << 30) + 4096,
+ (3ull << 30) - 4096,
+ (3ull << 30) + 4096,
+ (4ull << 30) - 4096,
+ };
+ struct drm_i915_gem_exec_object2 obj = {};
+ struct drm_i915_gem_execbuffer2 execbuf = {
+ .buffers_ptr = to_user_pointer(&obj),
+ .buffer_count = 1,
+ .flags = I915_EXEC_BLT,
+ };
+ uint64_t required, total;
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(sizes); i++) {
+ if (!__intel_check_memory(2, sizes[i], CHECK_RAM,
+ &required, &total))
+ break;
+
+ igt_debug("Using object size %#x\n", sizes[i]);
+ obj.handle = gem_create(i915, sizes[i]),
+ gem_write(i915, obj.handle, sizes[i] - 64, &bbe, sizeof(bbe));
+
+ execbuf.batch_start_offset = 0;
+ igt_assert_eq(__checked_execbuf(i915, &execbuf), 0);
+
+ execbuf.batch_start_offset = sizes[i] - 64;
+ igt_assert_eq(__checked_execbuf(i915, &execbuf), 0);
+
+ gem_close(i915, obj.handle);
+ }
+
+ igt_require_f(i > 0 && sizes[i - 1] > 1ull << 31,
+ "Insufficient free memory, require at least %'"PRIu64"MiB
but only have %'"PRIu64"MiB available",
+ required >> 20, total >> 20);
+}
+
static void test_bb_chained(const int i915, const uint32_t handle)
{
const uint32_t batch[] = {
@@ -1053,6 +1097,9 @@ igt_main
igt_subtest("bb-start-far")
test_bb_start(i915, handle, BB_START_FAR);
+ igt_subtest("bb-large")
+ test_bb_large(i915);
+
igt_fixture {
igt_stop_hang_detector();
gem_close(i915, handle);
--
2.28.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 0/4] dma-buf: Flag vmap'ed memory as system or I/O memory
On Mon, Sep 28, 2020 at 01:22:13PM +0200, Christian König wrote:
> Am 28.09.20 um 09:37 schrieb Thomas Zimmermann:
> > Hi
> >
> > Am 28.09.20 um 08:50 schrieb Christian König:
> > > Am 27.09.20 um 21:16 schrieb Sam Ravnborg:
> > > > Hi Thomas.
> > > >
> > > > > > struct simap {
> > > > > > union {
> > > > > > void __iomem *vaddr_iomem;
> > > > > > void *vaddr;
> > > > > > };
> > > > > > bool is_iomem;
> > > > > > };
> > > > > >
> > > > > > Where simap is a shorthand for system_iomem_map
> > > > > > And it could al be stuffed into a include/linux/simap.h file.
> > > > > >
> > > > > > Not totally sold on the simap name - but wanted to come up with
> > > > > > something.
> > > > > Yes. Others, myself included, have suggested to use a name that does
> > > > > not
> > > > > imply a connection to the dma-buf framework, but no one has come up
> > > > > with
> > > > > a good name.
> > > > >
> > > > > I strongly dislike simap, as it's entirely non-obvious what it does.
> > > > > dma-buf-map is not actually wrong. The structures represents the
> > > > > mapping
> > > > > of a dma-able buffer in most cases.
> > > > >
> > > > > > With this approach users do not have to pull in dma-buf to use it
> > > > > > and
> > > > > > users will not confuse that this is only for dma-buf usage.
> > > > > There's no need to enable dma-buf. It's all in the header file without
> > > > > dependencies on dma-buf. It's really just the name.
> > > > >
> > > > > But there's something else to take into account. The whole issue here
> > > > > is
> > > > > that the buffer is disconnected from its originating driver, so we
> > > > > don't
> > > > > know which kind of memory ops we have to use. Thinking about it, I
> > > > > realized that no one else seemed to have this problem until now.
> > > > > Otherwise there would be a solution already. So maybe the dma-buf
> > > > > framework *is* the native use case for this data structure.
> > > > We have at least:
> > > > linux/fb.h:
> > > > union {
> > > > char __iomem *screen_base; /* Virtual address */
> > > > char *screen_buffer;
> > > > };
> > > >
> > > > Which solve more or less the same problem.
> > I thought this was for convenience. The important is_iomem bit is missing.
> >
> > > I also already noted that in TTM we have exactly the same problem and a
> > > whole bunch of helpers to allow operations on those pointers.
> > How do you call this within TTM?
>
> ttm_bus_placement, but I really don't like that name.
>
> >
> > The data structure represents a pointer to either system or I/O memory,
> > but not necessatrily device memory. It contains raw data. That would
> > give something like
> >
> >struct databuf_map
> >struct databuf_ptr
> >struct dbuf_map
> >struct dbuf_ptr
> >
> > My favorite would be dbuf_ptr. It's short and the API names would make
> > sense: dbuf_ptr_clear() for clearing, dbuf_ptr_set_vaddr() to set an
> > address, dbuf_ptr_incr() to increment, etc. Also, the _ptr indicates
> > that it's a single address; not an offset with length.
>
> Puh, no idea. All of that doesn't sound like it 100% hits the underlying
> meaning of the structure.
Imo first let's merge this and then second with more users we might come
up with a better name. And cocci is fairly good at large-scale rename, to
the point where we manged to rename struct fence to struct dma_fence.
Also this entire thread here imo shows that we haven't yet figured out the
perfect name anyway, and I don't think it's worth it to hold this up
because of this bikeshed :-)
Cheers, Daniel
>
> Christian.
>
> >
> > Best regards
> > Thomas
> >
> > > Christian.
> > >
> > > > > Anyway, if a better name than dma-buf-map comes in, I'm willing to
> > > > > rename the thing. Otherwise I intend to merge the patchset by the end
> > > > > of
> > > > > the week.
> > > > Well, the main thing is that I think this shoud be moved away from
> > > > dma-buf. But if indeed dma-buf is the only relevant user in drm then
> > > > I am totally fine with the current naming.
> > > >
> > > > One alternative named that popped up in my head: struct sys_io_map {}
> > > > But again, if this is kept in dma-buf then I am fine with the current
> > > > naming.
> > > >
> > > > In other words, if you continue to think this is mostly a dma-buf
> > > > thing all three patches are:
> > > > Acked-by: Sam Ravnborg
> > > >
> > > > Sam
> > > ___
> > > dri-devel mailing list
> > > dri-de...@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v10 0/8] Asynchronous flip implementation for i915
On 9/28/2020 5:48 PM, Ville Syrjälä wrote: On Mon, Sep 21, 2020 at 04:32:02PM +0530, Karthik B S wrote: Without async flip support in the kernel, fullscreen apps where game resolution is equal to the screen resolution, must perform an extra blit per frame prior to flipping. Asynchronous page flips will also boost the FPS of Mesa benchmarks. v2: -Few patches have been squashed and patches have been shuffled as per the reviews on the previous version. v3: -Few patches have been squashed and patches have been shuffled as per the reviews on the previous version. v4: -Made changes to fix the sequence and time stamp issue as per the comments received on the previous version. -Timestamps are calculated using the flip done time stamp and current timestamp. Here I915_MODE_FLAG_GET_SCANLINE_FROM_TIMESTAMP flag is used for timestamp calculations. -Event is sent from the interrupt handler immediately using this updated timestamps and sequence. -Added more state checks as async flip should only allow change in plane surface address and nothing else should be allowed to change. -Added a separate plane hook for async flip. -Need to find a way to reject fbc enabling if it comes as part of this flip as bspec states that changes to FBC are not allowed. v5: -Fixed the Checkpatch and sparse warnings. v6: -Reverted back to the old timestamping code as per the feedback received. -Added documentation. v7: -Changes in intel_atomic_check_async() -Add vfunc for skl_program_async_surface_address() v8: -Add WA for older platforms with double buffered async address update enable bit. v9: -Changes as per feedback received on previous version. v10: -Changes as per feedback received on previous version. Everything seems good, so pushed the series to dinq. Thanks. Gave this a little test run on my cfl as well. At first it didn't kick in, but then I remebered that I'm running X with modifiers enabled so I was getting compression instead. After disabling modifiers I got plain old X-tile again and did see async flips happening. Thanks for the merge. Thanks, Karthik.B.S Karthik B S (8): drm/i915: Add enable/disable flip done and flip done handler drm/i915: Add support for async flips in I915 drm/i915: Add checks specific to async flips drm/i915: Do not call drm_crtc_arm_vblank_event in async flips drm/i915: Add dedicated plane hook for async flip case drm/i915: WA for platforms with double buffered address update enable bit Documentation/gpu: Add asynchronous flip documentation for i915 drm/i915: Enable async flips in i915 Documentation/gpu/i915.rst| 6 + .../gpu/drm/i915/display/intel_atomic_plane.c | 6 +- drivers/gpu/drm/i915/display/intel_display.c | 199 ++ .../drm/i915/display/intel_display_types.h| 3 + drivers/gpu/drm/i915/display/intel_sprite.c | 30 +++ drivers/gpu/drm/i915/i915_irq.c | 52 + drivers/gpu/drm/i915/i915_irq.h | 3 + drivers/gpu/drm/i915/i915_reg.h | 1 + 8 files changed, 299 insertions(+), 1 deletion(-) -- 2.22.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 0/4] dma-buf: Flag vmap'ed memory as system or I/O memory
Am 29.09.20 um 11:14 schrieb Daniel Vetter:
On Mon, Sep 28, 2020 at 01:22:13PM +0200, Christian König wrote:
Am 28.09.20 um 09:37 schrieb Thomas Zimmermann:
Hi
Am 28.09.20 um 08:50 schrieb Christian König:
Am 27.09.20 um 21:16 schrieb Sam Ravnborg:
Hi Thomas.
struct simap {
union {
void __iomem *vaddr_iomem;
void *vaddr;
};
bool is_iomem;
};
Where simap is a shorthand for system_iomem_map
And it could al be stuffed into a include/linux/simap.h file.
Not totally sold on the simap name - but wanted to come up with
something.
Yes. Others, myself included, have suggested to use a name that does not
imply a connection to the dma-buf framework, but no one has come up with
a good name.
I strongly dislike simap, as it's entirely non-obvious what it does.
dma-buf-map is not actually wrong. The structures represents the mapping
of a dma-able buffer in most cases.
With this approach users do not have to pull in dma-buf to use it and
users will not confuse that this is only for dma-buf usage.
There's no need to enable dma-buf. It's all in the header file without
dependencies on dma-buf. It's really just the name.
But there's something else to take into account. The whole issue here is
that the buffer is disconnected from its originating driver, so we don't
know which kind of memory ops we have to use. Thinking about it, I
realized that no one else seemed to have this problem until now.
Otherwise there would be a solution already. So maybe the dma-buf
framework *is* the native use case for this data structure.
We have at least:
linux/fb.h:
union {
char __iomem *screen_base; /* Virtual address */
char *screen_buffer;
};
Which solve more or less the same problem.
I thought this was for convenience. The important is_iomem bit is missing.
I also already noted that in TTM we have exactly the same problem and a
whole bunch of helpers to allow operations on those pointers.
How do you call this within TTM?
ttm_bus_placement, but I really don't like that name.
The data structure represents a pointer to either system or I/O memory,
but not necessatrily device memory. It contains raw data. That would
give something like
struct databuf_map
struct databuf_ptr
struct dbuf_map
struct dbuf_ptr
My favorite would be dbuf_ptr. It's short and the API names would make
sense: dbuf_ptr_clear() for clearing, dbuf_ptr_set_vaddr() to set an
address, dbuf_ptr_incr() to increment, etc. Also, the _ptr indicates
that it's a single address; not an offset with length.
Puh, no idea. All of that doesn't sound like it 100% hits the underlying
meaning of the structure.
Imo first let's merge this and then second with more users we might come
up with a better name. And cocci is fairly good at large-scale rename, to
the point where we manged to rename struct fence to struct dma_fence.
Agreed, renaming things later on is easy if somebody comes up with
something better.
But blocking a necessary technical change just because of the naming is
usually not a good idea.
Christian.
Also this entire thread here imo shows that we haven't yet figured out the
perfect name anyway, and I don't think it's worth it to hold this up
because of this bikeshed :-)
Cheers, Daniel
Christian.
Best regards
Thomas
Christian.
Anyway, if a better name than dma-buf-map comes in, I'm willing to
rename the thing. Otherwise I intend to merge the patchset by the end of
the week.
Well, the main thing is that I think this shoud be moved away from
dma-buf. But if indeed dma-buf is the only relevant user in drm then
I am totally fine with the current naming.
One alternative named that popped up in my head: struct sys_io_map {}
But again, if this is kept in dma-buf then I am fine with the current
naming.
In other words, if you continue to think this is mostly a dma-buf
thing all three patches are:
Acked-by: Sam Ravnborg
Sam
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-devel&data=02%7C01%7Cchristian.koenig%40amd.com%7C71c630a7ca1d48476eed08d864581e4f%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637369676925032848&sdata=CsekzASvj2lY%2B74FIiLc9B5QG7AHma8B2M5y8Cassj4%3D&reserved=0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 0/4] dma-buf: Flag vmap'ed memory as system or I/O memory
Am 29.09.20 um 13:09 schrieb Christian König:
> Am 29.09.20 um 11:14 schrieb Daniel Vetter:
>> On Mon, Sep 28, 2020 at 01:22:13PM +0200, Christian König wrote:
>>> Am 28.09.20 um 09:37 schrieb Thomas Zimmermann:
Hi
Am 28.09.20 um 08:50 schrieb Christian König:
> Am 27.09.20 um 21:16 schrieb Sam Ravnborg:
>> Hi Thomas.
>>
struct simap {
union {
void __iomem *vaddr_iomem;
void *vaddr;
};
bool is_iomem;
};
Where simap is a shorthand for system_iomem_map
And it could al be stuffed into a include/linux/simap.h file.
Not totally sold on the simap name - but wanted to come up with
something.
>>> Yes. Others, myself included, have suggested to use a name that
>>> does not
>>> imply a connection to the dma-buf framework, but no one has come
>>> up with
>>> a good name.
>>>
>>> I strongly dislike simap, as it's entirely non-obvious what it does.
>>> dma-buf-map is not actually wrong. The structures represents the
>>> mapping
>>> of a dma-able buffer in most cases.
>>>
With this approach users do not have to pull in dma-buf to use
it and
users will not confuse that this is only for dma-buf usage.
>>> There's no need to enable dma-buf. It's all in the header file
>>> without
>>> dependencies on dma-buf. It's really just the name.
>>>
>>> But there's something else to take into account. The whole issue
>>> here is
>>> that the buffer is disconnected from its originating driver, so
>>> we don't
>>> know which kind of memory ops we have to use. Thinking about it, I
>>> realized that no one else seemed to have this problem until now.
>>> Otherwise there would be a solution already. So maybe the dma-buf
>>> framework *is* the native use case for this data structure.
>> We have at least:
>> linux/fb.h:
>> union {
>> char __iomem *screen_base; /* Virtual address */
>> char *screen_buffer;
>> };
>>
>> Which solve more or less the same problem.
I thought this was for convenience. The important is_iomem bit is
missing.
> I also already noted that in TTM we have exactly the same problem
> and a
> whole bunch of helpers to allow operations on those pointers.
How do you call this within TTM?
>>> ttm_bus_placement, but I really don't like that name.
>>>
The data structure represents a pointer to either system or I/O memory,
but not necessatrily device memory. It contains raw data. That would
give something like
struct databuf_map
struct databuf_ptr
struct dbuf_map
struct dbuf_ptr
My favorite would be dbuf_ptr. It's short and the API names would make
sense: dbuf_ptr_clear() for clearing, dbuf_ptr_set_vaddr() to set an
address, dbuf_ptr_incr() to increment, etc. Also, the _ptr indicates
that it's a single address; not an offset with length.
>>> Puh, no idea. All of that doesn't sound like it 100% hits the underlying
>>> meaning of the structure.
>> Imo first let's merge this and then second with more users we might come
>> up with a better name. And cocci is fairly good at large-scale rename, to
>> the point where we manged to rename struct fence to struct dma_fence.
>
> Agreed, renaming things later on is easy if somebody comes up with
> something better.
>
> But blocking a necessary technical change just because of the naming is
> usually not a good idea.
OK, merged now.
Best regards
Thomas
>
> Christian.
>
>>
>> Also this entire thread here imo shows that we haven't yet figured out
>> the
>> perfect name anyway, and I don't think it's worth it to hold this up
>> because of this bikeshed :-)
>>
>> Cheers, Daniel
>>
>>> Christian.
>>>
Best regards
Thomas
> Christian.
>
>>> Anyway, if a better name than dma-buf-map comes in, I'm willing to
>>> rename the thing. Otherwise I intend to merge the patchset by the
>>> end of
>>> the week.
>> Well, the main thing is that I think this shoud be moved away from
>> dma-buf. But if indeed dma-buf is the only relevant user in drm then
>> I am totally fine with the current naming.
>>
>> One alternative named that popped up in my head: struct sys_io_map {}
>> But again, if this is kept in dma-buf then I am fine with the current
>> naming.
>>
>> In other words, if you continue to think this is mostly a dma-buf
>> thing all three patches are:
>> Acked-by: Sam Ravnborg
>>
>> Sam
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2
[Intel-gfx] [PATCH] drm/i915/gt: Scrub HW state on remove
Currently we do a final scrub of the HW state upon release. However,
when rebinding the device, this is too late as the device may either
have been partially rebound or the device is no longer accessible. If
the device has been removed before release, the reset goes astray
leaving the device in an inconsistent state, unlikely to work without a
full PCI reset. Furthermore, if the device is partially rebound before
the HW scrubbing, there may be leftover HW state that should have been
scrubbed. Either way, we need to push the scrubbing earlier before the
removal, so into unregister. The danger is that on older machines,
reseting the GPU also impact the display engine and so the reset should
be after modesetting is disabled (and before reuse we need to recover
modesetting).
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2508
Testcase: igt/core_hotunplug
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_gt.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index 39b428c5049c..44f1d51e5ae5 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -614,6 +614,8 @@ void intel_gt_driver_remove(struct intel_gt *gt)
void intel_gt_driver_unregister(struct intel_gt *gt)
{
+ intel_wakeref_t wakeref;
+
intel_rps_driver_unregister(>->rps);
/*
@@ -622,16 +624,15 @@ void intel_gt_driver_unregister(struct intel_gt *gt)
* resources.
*/
intel_gt_set_wedged(gt);
+
+ /* Scrub all HW state upon release */
+ with_intel_runtime_pm(gt->uncore->rpm, wakeref)
+ __intel_gt_reset(gt, ALL_ENGINES);
}
void intel_gt_driver_release(struct intel_gt *gt)
{
struct i915_address_space *vm;
- intel_wakeref_t wakeref;
-
- /* Scrub all HW state upon release */
- with_intel_runtime_pm(gt->uncore->rpm, wakeref)
- __intel_gt_reset(gt, ALL_ENGINES);
vm = fetch_and_zero(>->vm);
if (vm) /* FIXME being called twice on error paths :( */
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915/edp/jsl: Update vswing table for HBR and HBR2
JSL has update in vswing table for eDP
BSpec: 21257
Changes since V1 :
- IS_ELKHARTLAKE and IS_JASPERLAKE is replaced with
HAS_PCH_MCC(EHL) and HAS_PCH_JSP(JSL) respectively
- Reverted EHL/JSL PCI ids split change
Signed-off-by: Tejas Upadhyay
---
drivers/gpu/drm/i915/display/intel_ddi.c | 67 ++--
1 file changed, 64 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 4d06178cd76c..e6e93d01d0ce 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -582,6 +582,34 @@ static const struct cnl_ddi_buf_trans
ehl_combo_phy_ddi_translations_dp[] = {
{ 0x6, 0x7F, 0x3F, 0x00, 0x00 },/* 900 900 0.0 */
};
+static const struct cnl_ddi_buf_trans jsl_combo_phy_ddi_translations_edp_hbr[]
= {
+ /* NT mV Trans mV db*/
+ { 0x8, 0x7F, 0x3F, 0x00, 0x00 },/* 200 200 0.0 */
+ { 0x8, 0x7F, 0x38, 0x00, 0x07 },/* 200 250 1.9 */
+ { 0x1, 0x7F, 0x33, 0x00, 0x0C },/* 200 300 3.5 */
+ { 0xA, 0x35, 0x36, 0x00, 0x09 },/* 200 350 4.9 */
+ { 0x8, 0x7F, 0x3F, 0x00, 0x00 },/* 250 250 0.0 */
+ { 0x1, 0x7F, 0x38, 0x00, 0x07 },/* 250 300 1.6 */
+ { 0xA, 0x35, 0x35, 0x00, 0x0A },/* 250 350 2.9 */
+ { 0x1, 0x7F, 0x3F, 0x00, 0x00 },/* 300 300 0.0 */
+ { 0xA, 0x35, 0x38, 0x00, 0x07 },/* 300 350 1.3 */
+ { 0xA, 0x35, 0x3F, 0x00, 0x00 },/* 350 350 0.0 */
+};
+
+static const struct cnl_ddi_buf_trans
jsl_combo_phy_ddi_translations_edp_hbr2[] = {
+ /* NT mV Trans mV db*/
+ { 0x8, 0x7F, 0x3F, 0x00, 0x00 },/* 200 200 0.0 */
+ { 0x8, 0x7F, 0x3F, 0x00, 0x00 },/* 200 250 1.9 */
+ { 0x1, 0x7F, 0x3D, 0x00, 0x02 },/* 200 300 3.5 */
+ { 0xA, 0x35, 0x38, 0x00, 0x07 },/* 200 350 4.9 */
+ { 0x8, 0x7F, 0x3F, 0x00, 0x00 },/* 250 250 0.0 */
+ { 0x1, 0x7F, 0x3F, 0x00, 0x00 },/* 250 300 1.6 */
+ { 0xA, 0x35, 0x3A, 0x00, 0x05 },/* 250 350 2.9 */
+ { 0x1, 0x7F, 0x3F, 0x00, 0x00 },/* 300 300 0.0 */
+ { 0xA, 0x35, 0x38, 0x00, 0x07 },/* 300 350 1.3 */
+ { 0xA, 0x35, 0x3F, 0x00, 0x00 },/* 350 350 0.0 */
+};
+
struct icl_mg_phy_ddi_buf_trans {
u32 cri_txdeemph_override_11_6;
u32 cri_txdeemph_override_5_0;
@@ -1069,7 +1097,6 @@ icl_get_mg_buf_trans(struct intel_encoder *encoder, int
type, int rate,
*n_entries = ARRAY_SIZE(icl_mg_phy_ddi_translations_rbr_hbr);
return icl_mg_phy_ddi_translations_rbr_hbr;
}
-
static const struct cnl_ddi_buf_trans *
ehl_get_combo_buf_trans(struct intel_encoder *encoder, int type, int rate,
int *n_entries)
@@ -1098,6 +1125,34 @@ ehl_get_combo_buf_trans(struct intel_encoder *encoder,
int type, int rate,
}
}
+static const struct cnl_ddi_buf_trans *
+jsl_get_combo_buf_trans(struct intel_encoder *encoder, int type, int rate,
+ int *n_entries)
+{
+ struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+
+ switch (type) {
+ case INTEL_OUTPUT_HDMI:
+ *n_entries = ARRAY_SIZE(icl_combo_phy_ddi_translations_hdmi);
+ return icl_combo_phy_ddi_translations_hdmi;
+ case INTEL_OUTPUT_EDP:
+ if (dev_priv->vbt.edp.low_vswing) {
+ if (rate > 27) {
+ *n_entries =
ARRAY_SIZE(jsl_combo_phy_ddi_translations_edp_hbr2);
+ return jsl_combo_phy_ddi_translations_edp_hbr2;
+ } else {
+ *n_entries =
ARRAY_SIZE(jsl_combo_phy_ddi_translations_edp_hbr);
+ return jsl_combo_phy_ddi_translations_edp_hbr;
+ }
+ }
+ /* fall through */
+ default:
+ /* All combo DP and eDP ports that do not support low_vswing */
+ *n_entries = ARRAY_SIZE(icl_combo_phy_ddi_translations_dp_hbr2);
+ return icl_combo_phy_ddi_translations_dp_hbr2;
+ }
+}
+
static const struct cnl_ddi_buf_trans *
tgl_get_combo_buf_trans(struct intel_encoder *encoder, int type, int rate,
int *n_entries)
@@ -2265,7 +2320,10 @@ static u8 intel_ddi_dp_voltage_max(struct intel_dp
*intel_dp)
tgl_get_dkl_buf_trans(encoder, encoder->type,
intel_dp->link_rate, &n_entries);
} else if (INTEL_GEN(dev_priv) == 11) {
- if (IS_
Re: [Intel-gfx] remove alloc_vm_area v2
Quoting Christoph Hellwig (2020-09-28 15:37:41) > On Mon, Sep 28, 2020 at 01:13:38PM +0300, Joonas Lahtinen wrote: > > I think we have a gap that after splitting the drm-intel-next pull requests > > into > > two the drm-intel/for-linux-next branch is now missing material from > > drm-intel/drm-intel-gt-next. > > > > I think a simple course of action might be to start including > > drm-intel-gt-next > > in linux-next, which would mean that we should update DIM tooling to add > > extra branch "drm-intel/gt-for-linux-next" or so. > > > > Which specific patches are missing in this case? > > The two dependencies required by my series not in mainline are: > > drm/i915/gem: Avoid implicit vmap for highmem on x86-32 > drm/i915/gem: Prevent using pgprot_writecombine() if PAT is not supported > > so it has to be one or both of those. Hmm, those are both committed after our last -next pull request, so they would normally only target next merge window. drm-next closes the merge window around -rc5 already. But, in this specific case those are both Fixes: patches with Cc: stable, so they should be pulled into drm-intel-next-fixes PR. Rodrigo, can you cherry-pick those patches to -next-fixes that you send to Dave? Regards, Joonas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915/edp/jsl: Update vswing table for HBR and HBR2
On Mon, Sep 28, 2020 at 08:20:59PM +0300, Jani Nikula wrote: > On Mon, 28 Sep 2020, Ville Syrjälä wrote: > > On Mon, Sep 28, 2020 at 07:15:43AM -0700, James Ausmus wrote: > >> On Mon, Sep 28, 2020 at 04:43:11PM +0300, Jani Nikula wrote: > >> > On Mon, 28 Sep 2020, Tejas Upadhyay > >> > wrote: > >> > > JSL has update in vswing table for eDP > >> > > >> > I've thought the TLA for Jasper Lake is JSP, not JSL. At least we have > >> > PCH_JSP for Jasper Lake PCH. > >> > >> JSP == Point (the PCH), JSL == Lake > > > > .PT was " Point", ..P stands just for " PCH" IIRC. > > Yeah, nowadays it doesn't have "Point", however bspec agrees on the JSL > acronym for Jasper Lake. Bspec uses ..P for " PCH", when it acknowledges the existence of said PCH (see eg. CNP,ICP,TGP). JSP is not among that select crowd however, neither really is MCC (although it is mentioned by name in the JSL section). I kinda want to nuke the JSP and MCC types entirely. I believe we should be able to treat them as just ICP and TGP variants respectively. But theres's still a bit of work left to do before we can get there. -- 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 v2] drm/i915/edp/jsl: Update vswing table for HBR and HBR2
On Tue, Sep 29, 2020 at 05:41:27PM +0530, Tejas Upadhyay wrote:
> JSL has update in vswing table for eDP
>
> BSpec: 21257
>
> Changes since V1 :
> - IS_ELKHARTLAKE and IS_JASPERLAKE is replaced with
> HAS_PCH_MCC(EHL) and HAS_PCH_JSP(JSL) respectively
What do vswing values have to do with the PCH type?
> - Reverted EHL/JSL PCI ids split change
>
> Signed-off-by: Tejas Upadhyay
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 67 ++--
> 1 file changed, 64 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 4d06178cd76c..e6e93d01d0ce 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -582,6 +582,34 @@ static const struct cnl_ddi_buf_trans
> ehl_combo_phy_ddi_translations_dp[] = {
> { 0x6, 0x7F, 0x3F, 0x00, 0x00 },/* 900 900 0.0 */
> };
>
> +static const struct cnl_ddi_buf_trans
> jsl_combo_phy_ddi_translations_edp_hbr[] = {
> + /* NT mV Trans mV db*/
> + { 0x8, 0x7F, 0x3F, 0x00, 0x00 },/* 200 200 0.0 */
> + { 0x8, 0x7F, 0x38, 0x00, 0x07 },/* 200 250 1.9 */
> + { 0x1, 0x7F, 0x33, 0x00, 0x0C },/* 200 300 3.5 */
> + { 0xA, 0x35, 0x36, 0x00, 0x09 },/* 200 350 4.9 */
> + { 0x8, 0x7F, 0x3F, 0x00, 0x00 },/* 250 250 0.0 */
> + { 0x1, 0x7F, 0x38, 0x00, 0x07 },/* 250 300 1.6 */
> + { 0xA, 0x35, 0x35, 0x00, 0x0A },/* 250 350 2.9 */
> + { 0x1, 0x7F, 0x3F, 0x00, 0x00 },/* 300 300 0.0 */
> + { 0xA, 0x35, 0x38, 0x00, 0x07 },/* 300 350 1.3 */
> + { 0xA, 0x35, 0x3F, 0x00, 0x00 },/* 350 350 0.0 */
> +};
> +
> +static const struct cnl_ddi_buf_trans
> jsl_combo_phy_ddi_translations_edp_hbr2[] = {
> + /* NT mV Trans mV db*/
> + { 0x8, 0x7F, 0x3F, 0x00, 0x00 },/* 200 200 0.0 */
> + { 0x8, 0x7F, 0x3F, 0x00, 0x00 },/* 200 250 1.9 */
> + { 0x1, 0x7F, 0x3D, 0x00, 0x02 },/* 200 300 3.5 */
> + { 0xA, 0x35, 0x38, 0x00, 0x07 },/* 200 350 4.9 */
> + { 0x8, 0x7F, 0x3F, 0x00, 0x00 },/* 250 250 0.0 */
> + { 0x1, 0x7F, 0x3F, 0x00, 0x00 },/* 250 300 1.6 */
> + { 0xA, 0x35, 0x3A, 0x00, 0x05 },/* 250 350 2.9 */
> + { 0x1, 0x7F, 0x3F, 0x00, 0x00 },/* 300 300 0.0 */
> + { 0xA, 0x35, 0x38, 0x00, 0x07 },/* 300 350 1.3 */
> + { 0xA, 0x35, 0x3F, 0x00, 0x00 },/* 350 350 0.0 */
> +};
> +
> struct icl_mg_phy_ddi_buf_trans {
> u32 cri_txdeemph_override_11_6;
> u32 cri_txdeemph_override_5_0;
> @@ -1069,7 +1097,6 @@ icl_get_mg_buf_trans(struct intel_encoder *encoder, int
> type, int rate,
> *n_entries = ARRAY_SIZE(icl_mg_phy_ddi_translations_rbr_hbr);
> return icl_mg_phy_ddi_translations_rbr_hbr;
> }
> -
> static const struct cnl_ddi_buf_trans *
> ehl_get_combo_buf_trans(struct intel_encoder *encoder, int type, int rate,
> int *n_entries)
> @@ -1098,6 +1125,34 @@ ehl_get_combo_buf_trans(struct intel_encoder *encoder,
> int type, int rate,
> }
> }
>
> +static const struct cnl_ddi_buf_trans *
> +jsl_get_combo_buf_trans(struct intel_encoder *encoder, int type, int rate,
> + int *n_entries)
> +{
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> +
> + switch (type) {
> + case INTEL_OUTPUT_HDMI:
> + *n_entries = ARRAY_SIZE(icl_combo_phy_ddi_translations_hdmi);
> + return icl_combo_phy_ddi_translations_hdmi;
> + case INTEL_OUTPUT_EDP:
> + if (dev_priv->vbt.edp.low_vswing) {
> + if (rate > 27) {
> + *n_entries =
> ARRAY_SIZE(jsl_combo_phy_ddi_translations_edp_hbr2);
> + return jsl_combo_phy_ddi_translations_edp_hbr2;
> + } else {
> + *n_entries =
> ARRAY_SIZE(jsl_combo_phy_ddi_translations_edp_hbr);
> + return jsl_combo_phy_ddi_translations_edp_hbr;
> + }
> + }
> + /* fall through */
> + default:
> + /* All combo DP and eDP ports that do not support low_vswing */
> + *n_entries = ARRAY_SIZE(icl_combo_phy_ddi_translations_dp_hbr2);
> + return icl_combo_phy_ddi_translations_dp_hbr2;
> + }
> +}
> +
> static const struct cnl_ddi_buf_trans *
> tgl_get_combo_buf_trans(struct intel_encoder *encoder, int type, int rate,
> int *n_entries)
> @@ -2265,7 +2320,10 @@ static u8 intel_ddi_dp_voltage_max(struct intel_dp
> *intel_dp)
[Intel-gfx] [PATCH] drm/i915: Read DIMM size in Gb rather than GB
From: Ville Syrjälä
CNL+ can report DIMM sizes in .5 GB units. In order to not trauncate
away the .5 GB let's switch to storing the DIMM size in Gb units.
Cc: Swati Sharma
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dram.c | 23 ---
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dram.c
b/drivers/gpu/drm/i915/intel_dram.c
index 8aa12cad93ce..4754296a250e 100644
--- a/drivers/gpu/drm/i915/intel_dram.c
+++ b/drivers/gpu/drm/i915/intel_dram.c
@@ -7,7 +7,8 @@
#include "intel_dram.h"
struct dram_dimm_info {
- u8 size, width, ranks;
+ u16 size;
+ u8 width, ranks;
};
struct dram_channel_info {
@@ -41,10 +42,10 @@ static int intel_dimm_num_devices(const struct
dram_dimm_info *dimm)
return dimm->ranks * 64 / (dimm->width ?: 1);
}
-/* Returns total GB for the whole DIMM */
+/* Returns total Gb for the whole DIMM */
static int skl_get_dimm_size(u16 val)
{
- return val & SKL_DRAM_SIZE_MASK;
+ return (val & SKL_DRAM_SIZE_MASK) * 8;
}
static int skl_get_dimm_width(u16 val)
@@ -74,10 +75,10 @@ static int skl_get_dimm_ranks(u16 val)
return val + 1;
}
-/* Returns total GB for the whole DIMM */
+/* Returns total Gb for the whole DIMM */
static int cnl_get_dimm_size(u16 val)
{
- return (val & CNL_DRAM_SIZE_MASK) / 2;
+ return (val & CNL_DRAM_SIZE_MASK) * 8 / 2;
}
static int cnl_get_dimm_width(u16 val)
@@ -110,8 +111,8 @@ static int cnl_get_dimm_ranks(u16 val)
static bool
skl_is_16gb_dimm(const struct dram_dimm_info *dimm)
{
- /* Convert total GB to Gb per DRAM device */
- return 8 * dimm->size / (intel_dimm_num_devices(dimm) ?: 1) == 16;
+ /* Convert total Gb to Gb per DRAM device */
+ return dimm->size / (intel_dimm_num_devices(dimm) ?: 1) == 16;
}
static void
@@ -130,7 +131,7 @@ skl_dram_get_dimm_info(struct drm_i915_private *i915,
}
drm_dbg_kms(&i915->drm,
- "CH%u DIMM %c size: %u GB, width: X%u, ranks: %u, 16Gb
DIMMs: %s\n",
+ "CH%u DIMM %c size: %u Gb, width: X%u, ranks: %u, 16Gb
DIMMs: %s\n",
channel, dimm_name, dimm->size, dimm->width, dimm->ranks,
yesno(skl_is_16gb_dimm(dimm)));
}
@@ -354,9 +355,9 @@ static void bxt_get_dimm_info(struct dram_dimm_info *dimm,
u32 val)
/*
* Size in register is Gb per DRAM device. Convert to total
-* GB to match the way we report this for non-LP platforms.
+* Gb to match the way we report this for non-LP platforms.
*/
- dimm->size = bxt_get_dimm_size(val) * intel_dimm_num_devices(dimm) / 8;
+ dimm->size = bxt_get_dimm_size(val) * intel_dimm_num_devices(dimm);
}
static int bxt_get_dram_info(struct drm_i915_private *i915)
@@ -404,7 +405,7 @@ static int bxt_get_dram_info(struct drm_i915_private *i915)
dram_info->type != type);
drm_dbg_kms(&i915->drm,
- "CH%u DIMM size: %u GB, width: X%u, ranks: %u,
type: %s\n",
+ "CH%u DIMM size: %u Gb, width: X%u, ranks: %u,
type: %s\n",
i - BXT_D_CR_DRP0_DUNIT_START,
dimm.size, dimm.width, dimm.ranks,
intel_dram_type_str(type));
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/edp/jsl: Update vswing table for HBR and HBR2
-Original Message-
From: Ville Syrjälä
Sent: 29 September 2020 18:23
To: Surendrakumar Upadhyay, TejaskumarX
Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; Ausmus,
James ; Roper, Matthew D ;
Souza, Jose ; De Marchi, Lucas
; Pandey, Hariom
Subject: Re: [PATCH v2] drm/i915/edp/jsl: Update vswing table for HBR and HBR2
On Tue, Sep 29, 2020 at 05:41:27PM +0530, Tejas Upadhyay wrote:
> JSL has update in vswing table for eDP
>
> BSpec: 21257
>
> Changes since V1 :
> - IS_ELKHARTLAKE and IS_JASPERLAKE is replaced with
> HAS_PCH_MCC(EHL) and HAS_PCH_JSP(JSL) respectively
What do vswing values have to do with the PCH type?
Tejas : There is difference in voltage swing values for EHL and JSL. Till now
we were not differentiating between EHL and JSL as both were
based on ICL. Now as per compliance test we have found change in JSL eDP vswing
values which does not apply to EHL which leads to differentiate
between EHL and JSL. Thus differentiator between JSL and EHL is PCH i.e
HAS_PCH_MCC(EHL) and HAS_PCH_JSP(JSL). There is no direct relation of PCH with
vswing.
> - Reverted EHL/JSL PCI ids split change
>
> Signed-off-by: Tejas Upadhyay
>
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 67
> ++--
> 1 file changed, 64 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 4d06178cd76c..e6e93d01d0ce 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -582,6 +582,34 @@ static const struct cnl_ddi_buf_trans
> ehl_combo_phy_ddi_translations_dp[] = {
> { 0x6, 0x7F, 0x3F, 0x00, 0x00 },/* 900 900 0.0 */
> };
>
> +static const struct cnl_ddi_buf_trans
> jsl_combo_phy_ddi_translations_edp_hbr[] = {
> + /* NT mV Trans mV db*/
> + { 0x8, 0x7F, 0x3F, 0x00, 0x00 },/* 200 200 0.0 */
> + { 0x8, 0x7F, 0x38, 0x00, 0x07 },/* 200 250 1.9 */
> + { 0x1, 0x7F, 0x33, 0x00, 0x0C },/* 200 300 3.5 */
> + { 0xA, 0x35, 0x36, 0x00, 0x09 },/* 200 350 4.9 */
> + { 0x8, 0x7F, 0x3F, 0x00, 0x00 },/* 250 250 0.0 */
> + { 0x1, 0x7F, 0x38, 0x00, 0x07 },/* 250 300 1.6 */
> + { 0xA, 0x35, 0x35, 0x00, 0x0A },/* 250 350 2.9 */
> + { 0x1, 0x7F, 0x3F, 0x00, 0x00 },/* 300 300 0.0 */
> + { 0xA, 0x35, 0x38, 0x00, 0x07 },/* 300 350 1.3 */
> + { 0xA, 0x35, 0x3F, 0x00, 0x00 },/* 350 350 0.0 */
> +};
> +
> +static const struct cnl_ddi_buf_trans
> jsl_combo_phy_ddi_translations_edp_hbr2[] = {
> + /* NT mV Trans mV db*/
> + { 0x8, 0x7F, 0x3F, 0x00, 0x00 },/* 200 200 0.0 */
> + { 0x8, 0x7F, 0x3F, 0x00, 0x00 },/* 200 250 1.9 */
> + { 0x1, 0x7F, 0x3D, 0x00, 0x02 },/* 200 300 3.5 */
> + { 0xA, 0x35, 0x38, 0x00, 0x07 },/* 200 350 4.9 */
> + { 0x8, 0x7F, 0x3F, 0x00, 0x00 },/* 250 250 0.0 */
> + { 0x1, 0x7F, 0x3F, 0x00, 0x00 },/* 250 300 1.6 */
> + { 0xA, 0x35, 0x3A, 0x00, 0x05 },/* 250 350 2.9 */
> + { 0x1, 0x7F, 0x3F, 0x00, 0x00 },/* 300 300 0.0 */
> + { 0xA, 0x35, 0x38, 0x00, 0x07 },/* 300 350 1.3 */
> + { 0xA, 0x35, 0x3F, 0x00, 0x00 },/* 350 350 0.0 */
> +};
> +
> struct icl_mg_phy_ddi_buf_trans {
> u32 cri_txdeemph_override_11_6;
> u32 cri_txdeemph_override_5_0;
> @@ -1069,7 +1097,6 @@ icl_get_mg_buf_trans(struct intel_encoder *encoder, int
> type, int rate,
> *n_entries = ARRAY_SIZE(icl_mg_phy_ddi_translations_rbr_hbr);
> return icl_mg_phy_ddi_translations_rbr_hbr;
> }
> -
> static const struct cnl_ddi_buf_trans *
> ehl_get_combo_buf_trans(struct intel_encoder *encoder, int type, int rate,
> int *n_entries)
> @@ -1098,6 +1125,34 @@ ehl_get_combo_buf_trans(struct intel_encoder *encoder,
> int type, int rate,
> }
> }
>
> +static const struct cnl_ddi_buf_trans *
> +jsl_get_combo_buf_trans(struct intel_encoder *encoder, int type, int rate,
> + int *n_entries)
> +{
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> +
> + switch (type) {
> + case INTEL_OUTPUT_HDMI:
> + *n_entries = ARRAY_SIZE(icl_combo_phy_ddi_translations_hdmi);
> + return icl_combo_phy_ddi_translations_hdmi;
> + case INTEL_OUTPUT_EDP:
> + if (dev_priv->vbt.edp.low_vswing) {
> + if (rate > 27) {
> + *n_entries =
> ARRAY_SIZE(jsl_combo_phy_ddi_translations_edp_hbr2);
> + return jsl_combo_phy_ddi_translat
Re: [Intel-gfx] [PATCH i-g-t v2] i915/gen9_exec_parse: Check parsing of large objects
Chris Wilson writes:
> Simply check that we support parsing of batches as large as the uAPI
> allows.
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
Reviewed-by: Mika Kuoppala
> ---
> Try a few intermediate object sizes since CI machines do not have enough
> memory to reach the upper bounds of the uAPI.
> ---
> tests/i915/gen9_exec_parse.c | 47
> 1 file changed, 47 insertions(+)
>
> diff --git a/tests/i915/gen9_exec_parse.c b/tests/i915/gen9_exec_parse.c
> index 8cd82f568..f735e7e1c 100644
> --- a/tests/i915/gen9_exec_parse.c
> +++ b/tests/i915/gen9_exec_parse.c
> @@ -566,6 +566,50 @@ static void test_bb_start(const int i915, const uint32_t
> handle, int test)
> gem_close(i915, target_bo);
> }
>
> +static void test_bb_large(int i915)
> +{
> + const uint32_t bbe = MI_BATCH_BUFFER_END;
> + static const uint32_t sizes[] = {
> + (1ull << 30) - 4096,
> + (1ull << 30) + 4096,
> + (2ull << 30) - 4096,
> + (2ull << 30) + 4096,
> + (3ull << 30) - 4096,
> + (3ull << 30) + 4096,
> + (4ull << 30) - 4096,
> + };
> + struct drm_i915_gem_exec_object2 obj = {};
> + struct drm_i915_gem_execbuffer2 execbuf = {
> + .buffers_ptr = to_user_pointer(&obj),
> + .buffer_count = 1,
> + .flags = I915_EXEC_BLT,
> + };
> + uint64_t required, total;
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(sizes); i++) {
> + if (!__intel_check_memory(2, sizes[i], CHECK_RAM,
> + &required, &total))
> + break;
> +
> + igt_debug("Using object size %#x\n", sizes[i]);
> + obj.handle = gem_create(i915, sizes[i]),
> + gem_write(i915, obj.handle, sizes[i] - 64, &bbe, sizeof(bbe));
> +
> + execbuf.batch_start_offset = 0;
> + igt_assert_eq(__checked_execbuf(i915, &execbuf), 0);
> +
> + execbuf.batch_start_offset = sizes[i] - 64;
> + igt_assert_eq(__checked_execbuf(i915, &execbuf), 0);
> +
> + gem_close(i915, obj.handle);
> + }
> +
> + igt_require_f(i > 0 && sizes[i - 1] > 1ull << 31,
> + "Insufficient free memory, require at least %'"PRIu64"MiB
> but only have %'"PRIu64"MiB available",
> + required >> 20, total >> 20);
> +}
> +
> static void test_bb_chained(const int i915, const uint32_t handle)
> {
> const uint32_t batch[] = {
> @@ -1053,6 +1097,9 @@ igt_main
> igt_subtest("bb-start-far")
> test_bb_start(i915, handle, BB_START_FAR);
>
> + igt_subtest("bb-large")
> + test_bb_large(i915);
> +
> igt_fixture {
> igt_stop_hang_detector();
> gem_close(i915, handle);
> --
> 2.28.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 6/7] drm: Validate encoder->possible_crtcs
On 10.09.20 20:18, Deucher, Alexander wrote:
> [AMD Public Use]
>
>
>
>> -Original Message-
>> From: amd-gfx On Behalf Of
>> Daniel Vetter
>> Sent: Monday, September 7, 2020 3:15 AM
>> To: Jan Kiszka ; amd-gfx list > g...@lists.freedesktop.org>; Wentland, Harry ;
>> Kazlauskas, Nicholas
>> Cc: dri-devel ; intel-gfx > g...@lists.freedesktop.org>; Thomas Zimmermann
>> ; Ville Syrjala
>> Subject: Re: [PATCH v3 6/7] drm: Validate encoder->possible_crtcs
>>
>> On Sun, Sep 6, 2020 at 1:19 PM Jan Kiszka wrote:
>>>
>>> On 11.02.20 18:04, Daniel Vetter wrote:
On Tue, Feb 11, 2020 at 06:22:07PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> WARN if the encoder possible_crtcs is effectively empty or contains
> bits for non-existing crtcs.
>
> v2: Move to drm_mode_config_validate() (Daniel)
> Make the docs say we WARN when this is wrong (Daniel)
> Extract full_crtc_mask()
>
> Cc: Thomas Zimmermann
> Cc: Daniel Vetter
> Signed-off-by: Ville Syrjälä
When pushing the fixup needs to be applied before the validation
patch here, because we don't want to anger the bisect gods.
Reviewed-by: Daniel Vetter
I think with the fixup we should be good enough with the existing
nonsense in drivers. Fingers crossed.
-Daniel
> ---
> drivers/gpu/drm/drm_mode_config.c | 27
>> ++-
> include/drm/drm_encoder.h | 2 +-
> 2 files changed, 27 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_mode_config.c
> b/drivers/gpu/drm/drm_mode_config.c
> index afc91447293a..4c1b350ddb95 100644
> --- a/drivers/gpu/drm/drm_mode_config.c
> +++ b/drivers/gpu/drm/drm_mode_config.c
> @@ -581,6 +581,29 @@ static void
>> validate_encoder_possible_clones(struct drm_encoder *encoder)
> encoder->possible_clones, encoder_mask); }
>
> +static u32 full_crtc_mask(struct drm_device *dev) {
> +struct drm_crtc *crtc;
> +u32 crtc_mask = 0;
> +
> +drm_for_each_crtc(crtc, dev)
> +crtc_mask |= drm_crtc_mask(crtc);
> +
> +return crtc_mask;
> +}
> +
> +static void validate_encoder_possible_crtcs(struct drm_encoder
> +*encoder) {
> +u32 crtc_mask = full_crtc_mask(encoder->dev);
> +
> +WARN((encoder->possible_crtcs & crtc_mask) == 0 ||
> + (encoder->possible_crtcs & ~crtc_mask) != 0,
> + "Bogus possible_crtcs: "
> + "[ENCODER:%d:%s] possible_crtcs=0x%x (full crtc mask=0x%x)\n",
> + encoder->base.id, encoder->name,
> + encoder->possible_crtcs, crtc_mask); }
> +
> void drm_mode_config_validate(struct drm_device *dev) {
> struct drm_encoder *encoder;
> @@ -588,6 +611,8 @@ void drm_mode_config_validate(struct
>> drm_device *dev)
> drm_for_each_encoder(encoder, dev)
> fixup_encoder_possible_clones(encoder);
>
> -drm_for_each_encoder(encoder, dev)
> +drm_for_each_encoder(encoder, dev) {
> validate_encoder_possible_clones(encoder);
> +validate_encoder_possible_crtcs(encoder);
> +}
> }
> diff --git a/include/drm/drm_encoder.h b/include/drm/drm_encoder.h
> index 3741963b9587..b236269f41ac 100644
> --- a/include/drm/drm_encoder.h
> +++ b/include/drm/drm_encoder.h
> @@ -142,7 +142,7 @@ struct drm_encoder {
> * the bits for all &drm_crtc objects this encoder can be connected
> to
> * before calling drm_dev_register().
> *
> - * In reality almost every driver gets this wrong.
> + * You will get a WARN if you get this wrong in the driver.
> *
> * Note that since CRTC objects can't be hotplugged the assigned
>> indices
> * are stable and hence known before registering all objects.
> --
> 2.24.1
>
>>>
>>> Triggers on an Advantech AIMB-228 (R1505G, 3 DP outputs):
>>
>> Adding amdgpu display folks.
>
> I took a quick look at this and it looks like we limit the number of crtcs
> later in the mode init process if the number of physical displays can't
> actually use more crtcs. E.g., the physical board configuration would only
> allow for 3 active displays even if the hardware technically supports 4
> crtcs. I presume that way we can just leave the additional hardware power
> gated all the time.
>
So, will this be fixed any time soon? I don't feel qualified writing
such a patch but I would obviously be happy to test one.
Jan
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [patch 00/13] preempt: Make preempt count unconditional
On Tue 29-09-20 11:00:03, Daniel Vetter wrote:
> On Tue, Sep 29, 2020 at 10:19:38AM +0200, Michal Hocko wrote:
> > On Wed 16-09-20 23:43:02, Daniel Vetter wrote:
> > > I can
> > > then figure out whether it's better to risk not spotting issues with
> > > call_rcu vs slapping a memalloc_noio_save/restore around all these
> > > critical section which force-degrades any allocation to GFP_ATOMIC at
> >
> > did you mean memalloc_noreclaim_* here?
>
> Yeah I picked the wrong one of that family of functions.
>
> > > most, but has the risk that we run into code that assumes "GFP_KERNEL
> > > never fails for small stuff" and has a decidedly less tested fallback
> > > path than rcu code.
> >
> > Even if the above then please note that memalloc_noreclaim_* or
> > PF_MEMALLOC should be used with an extreme care. Essentially only for
> > internal memory reclaimers. It grants access to _all_ the available
> > memory so any abuse can be detrimental to the overall system operation.
> > Allocation failure in this mode means that we are out of memory and any
> > code relying on such an allocation has to carefuly consider failure.
> > This is not a random allocation mode.
>
> Agreed, that's why I don't like having these kind of automagic critical
> sections. It's a bit a shotgun approach. Paul said that the code would
> handle failures, but the problem is that it applies everywhere.
Ohh, in the ideal world we wouldn't need anything like that. But then
the reality fires:
* PF_MEMALLOC (resp memalloc_noreclaim_* for that matter) is primarily used
to make sure that allocations from inside the memory reclaim - yeah that
happens - will not recurse.
* PF_MEMALLOC_NO{FS,IO} (resp memalloc_no{fs,io}*) are used to mark no
fs/io reclaim recursion critical sections because controling that for
each allocation inside fs transaction (or other sensitive) or IO
contexts turned out to be unmaintainable and people simply fallen into
using NOFS/NOIO unconditionally which is causing reclaim imbalance
problems.
* PF_MEMALLOC_NOCMA (resp memalloc_nocma*) is used for long term pinning
when CMA pages cannot be pinned because that would break the CMA
guarantees. Communicating this to all potential allocations during
pinning is simply unfeasible.
So you are absolutely right that these critical sections with side
effects on all allocations are far from ideal from the API point of view
but they are mostly mirroring a demand for functionality which is
_practically_ impossible to achieve with our current code base. Not that
we couldn't get back to drawing board and come up with a saner thing and
rework the world...
--
Michal Hocko
SUSE Labs
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/3] drm/i915/gt: Signal cancelled requests
== Series Details == Series: series starting with [1/3] drm/i915/gt: Signal cancelled requests URL : https://patchwork.freedesktop.org/series/82189/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. +./include/linux/seqlock.h:752:24: warning: trying to copy expression type 31 +./include/linux/seqlock.h:778:16: warning: trying to copy expression type 31 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915/gt: Signal cancelled requests
== Series Details ==
Series: series starting with [1/3] drm/i915/gt: Signal cancelled requests
URL : https://patchwork.freedesktop.org/series/82189/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9073 -> Patchwork_18588
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18588/index.html
Known issues
Here are the changes found in Patchwork_18588 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_module_load@reload:
- fi-byt-j1900: [PASS][1] -> [DMESG-WARN][2] ([i915#1982])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9073/fi-byt-j1900/igt@i915_module_l...@reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18588/fi-byt-j1900/igt@i915_module_l...@reload.html
Possible fixes
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-byt-j1900: [DMESG-WARN][3] ([i915#1982]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9073/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18588/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-kefka: [DMESG-WARN][5] ([i915#1982]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9073/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18588/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_cursor_legacy@basic-flip-before-cursor-atomic:
- fi-icl-u2: [DMESG-WARN][7] ([i915#1982]) -> [PASS][8] +2 similar
issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9073/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18588/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html
* igt@kms_flip@basic-flip-vs-wf_vblank@c-hdmi-a2:
- fi-skl-guc: [DMESG-WARN][9] ([i915#2203]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9073/fi-skl-guc/igt@kms_flip@basic-flip-vs-wf_vbl...@c-hdmi-a2.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18588/fi-skl-guc/igt@kms_flip@basic-flip-vs-wf_vbl...@c-hdmi-a2.html
Warnings
* igt@gem_exec_suspend@basic-s0:
- fi-kbl-x1275: [DMESG-WARN][11] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][12] ([i915#1982] / [i915#62] / [i915#92] / [i915#95])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9073/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18588/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
* igt@kms_force_connector_basic@prune-stale-modes:
- fi-kbl-x1275: [DMESG-WARN][13] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][14] ([i915#62] / [i915#92])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9073/fi-kbl-x1275/igt@kms_force_connector_ba...@prune-stale-modes.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18588/fi-kbl-x1275/igt@kms_force_connector_ba...@prune-stale-modes.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-c:
- fi-kbl-x1275: [DMESG-WARN][15] ([i915#62] / [i915#92]) ->
[DMESG-WARN][16] ([i915#62] / [i915#92] / [i915#95]) +5 similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9073/fi-kbl-x1275/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18588/fi-kbl-x1275/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2203]: https://gitlab.freedesktop.org/drm/intel/issues/2203
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
[i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
Participating hosts (46 -> 39)
--
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600 fi-byt-clapper fi-bdw-samus
Build changes
-
* Linux: CI_DRM_9073 -> Patchwork_18588
CI-20190529: 20190529
CI_DRM_9073: 0b019e521325e4ea16328f4d4e0ea0ff1a85e4a2 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5791: d089599869755e80accd16d3018b5f9ace139588 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_18588: 858151df42404c9017b2cbee1278e723c492bee3 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
858151df4240 drm/i915/gt: Retire cancelled requests on unlo
Re: [Intel-gfx] [PATCH 2/2] drm/atomic: debug output for EBUSY
Hi, On Fri, 25 Sep 2020 at 09:46, Daniel Vetter wrote: > Hopefully we'll have the drm crash recorder RSN, but meanwhile > compositors would like to know a bit better why they get an EBUSY. Thanks a lot, this is super helpful! Both patches are: Reviewed-by: Daniel Stone Cheers, Daniel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v6 02/11] drm/i915/display: Enable HDR on gen9 devices with MCA Lspcon
On Tue, Sep 15, 2020 at 02:30:38AM +0530, Uma Shankar wrote:
> Gen9 hardware supports HDMI2.0 through LSPCON chips.
> Extending HDR support for MCA LSPCON based GEN9 devices.
>
> SOC will drive LSPCON as DP and send HDR metadata as standard
> DP SDP packets. LSPCON will be set to operate in PCON mode,
> will receive the metadata and create Dynamic Range and
> Mastering Infoframe (DRM packets) and send it to HDR capable
> HDMI sink devices.
>
> v2: Re-used hsw infoframe write implementation for HDR metadata
> for LSPCON as per Ville's suggestion.
>
> v3: Addressed Jani Nikula's review comments.
>
> Signed-off-by: Uma Shankar
> ---
> drivers/gpu/drm/i915/display/intel_hdmi.c | 10 ++
> drivers/gpu/drm/i915/display/intel_lspcon.c | 37 +++--
> drivers/gpu/drm/i915/display/intel_lspcon.h | 5 ++-
> 3 files changed, 40 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
> b/drivers/gpu/drm/i915/display/intel_hdmi.c
> index 0978b0d8f4c6..1e40ed473fb9 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
> @@ -590,6 +590,16 @@ static u32 hsw_infoframes_enabled(struct intel_encoder
> *encoder,
> return val & mask;
> }
>
> +void lspcon_drm_write_infoframe(struct intel_encoder *encoder,
> + const struct intel_crtc_state *crtc_state,
> + unsigned int type,
> + const void *frame, ssize_t len)
> +{
> + drm_dbg_kms(encoder->base.dev, "Update HDR metadata for lspcon\n");
> + /* It uses the legacy hsw implementation for the same */
> + hsw_write_infoframe(encoder, crtc_state, type, frame, len);
> +}
This wrapper seems quite pointless.
> +
> static const u8 infoframe_type_to_idx[] = {
> HDMI_PACKET_TYPE_GENERAL_CONTROL,
> HDMI_PACKET_TYPE_GAMUT_METADATA,
> diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c
> b/drivers/gpu/drm/i915/display/intel_lspcon.c
> index 8e8c7a02ab51..5e2d7ca1d20f 100644
> --- a/drivers/gpu/drm/i915/display/intel_lspcon.c
> +++ b/drivers/gpu/drm/i915/display/intel_lspcon.c
> @@ -461,27 +461,42 @@ void lspcon_write_infoframe(struct intel_encoder
> *encoder,
> unsigned int type,
> const void *frame, ssize_t len)
> {
> - bool ret;
> + bool ret = true;
> struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> struct intel_lspcon *lspcon = enc_to_intel_lspcon(encoder);
>
> - /* LSPCON only needs AVI IF */
> - if (type != HDMI_INFOFRAME_TYPE_AVI)
> + /*
> + * Supporting HDR on MCA LSPCON
> + * Todo: Add support for Parade later
> + */
> + if (type == HDMI_PACKET_TYPE_GAMUT_METADATA &&
> + lspcon->vendor != LSPCON_VENDOR_MCA)
> return;
We shouldn't have the infoframe flagged as enabled if we
don't support it. So this check seems pointless, or there's
a bug somewhere else.
>
> - if (lspcon->vendor == LSPCON_VENDOR_MCA)
> - ret = _lspcon_write_avi_infoframe_mca(&intel_dp->aux,
> - frame, len);
> - else
> - ret = _lspcon_write_avi_infoframe_parade(&intel_dp->aux,
> - frame, len);
> + switch (type) {
> + case HDMI_INFOFRAME_TYPE_AVI:
> + if (lspcon->vendor == LSPCON_VENDOR_MCA)
> + ret = _lspcon_write_avi_infoframe_mca(&intel_dp->aux,
> + frame, len);
> + else
> + ret = _lspcon_write_avi_infoframe_parade(&intel_dp->aux,
> + frame, len);
> + break;
> + case HDMI_PACKET_TYPE_GAMUT_METADATA:
> + lspcon_drm_write_infoframe(encoder, crtc_state,
> +HDMI_PACKET_TYPE_GAMUT_METADATA,
> +frame, VIDEO_DIP_DATA_SIZE);
Why are we hardocoding the parameters here? Just pass them through?
> + break;
> + default:
> + return;
> + }
>
> if (!ret) {
> - DRM_ERROR("Failed to write AVI infoframes\n");
> + DRM_ERROR("Failed to write infoframes\n");
> return;
> }
>
> - DRM_DEBUG_DRIVER("AVI infoframes updated successfully\n");
> + DRM_DEBUG_DRIVER("Infoframes updated successfully\n");
That pointless debug should probably be just nuked.
> }
>
> void lspcon_read_infoframe(struct intel_encoder *encoder,
> diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.h
> b/drivers/gpu/drm/i915/display/intel_lspcon.h
> index 1cffe8a42a08..3fac05535731 100644
> --- a/drivers/gpu/drm/i915/display/intel_lspcon.h
> +++ b/drivers/gpu/drm/i915/display/intel_lspcon.h
> @@ -34,5 +34,8 @@ u32 lspcon_infoframes_enabled(struct intel_encoder *encoder,
>
Re: [Intel-gfx] [v6 03/11] drm/i915/display: Attach HDR property for capable Gen9 devices
On Tue, Sep 15, 2020 at 02:30:39AM +0530, Uma Shankar wrote:
> Attach HDR property for Gen9 devices with MCA LSPCON
> chips.
>
> v2: Cleaned HDR property attachment logic based on capability
> as per Jani Nikula's suggestion.
>
> Signed-off-by: Uma Shankar
> ---
> drivers/gpu/drm/i915/display/intel_lspcon.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c
> b/drivers/gpu/drm/i915/display/intel_lspcon.c
> index 5e2d7ca1d20f..fd05210f4405 100644
> --- a/drivers/gpu/drm/i915/display/intel_lspcon.c
> +++ b/drivers/gpu/drm/i915/display/intel_lspcon.c
> @@ -626,6 +626,11 @@ bool lspcon_init(struct intel_digital_port *dig_port)
>
> lspcon_detect_hdr_capability(lspcon);
>
> + if (lspcon->hdr_supported)
> + drm_object_attach_property(&connector->base,
> +
> connector->dev->mode_config.hdr_output_metadata_property,
> +0);
Hmm. This hdr capability detection is going to cause us extra grief
when looking at Kai-Heng's patch to defer lspcon detection until
hotplug time. Not quite sure what to do about that though.
> +
> connector->ycbcr_420_allowed = true;
> lspcon->active = true;
> DRM_DEBUG_KMS("Success: LSPCON init\n");
> --
> 2.26.2
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v6 04/11] drm/i915/display: Enable BT2020 for HDR on LSPCON devices
On Tue, Sep 15, 2020 at 02:30:40AM +0530, Uma Shankar wrote:
> Enable Colorspace as BT2020 if driving HDR content.Sending Colorimetry
> data for HDR using AVI infoframe. LSPCON firmware expects this and though
> SOC drives DP, for HDMI panel AVI infoframe is sent to the LSPCON device
> which transfers the same to HDMI sink.
>
> v2: Dropped state managed in drm core as per Jani Nikula's suggestion.
>
> Signed-off-by: Uma Shankar
> ---
> drivers/gpu/drm/i915/display/intel_lspcon.c | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c
> b/drivers/gpu/drm/i915/display/intel_lspcon.c
> index fd05210f4405..b0ca494f1110 100644
> --- a/drivers/gpu/drm/i915/display/intel_lspcon.c
> +++ b/drivers/gpu/drm/i915/display/intel_lspcon.c
> @@ -507,6 +507,11 @@ void lspcon_read_infoframe(struct intel_encoder *encoder,
> /* FIXME implement this */
> }
>
> +/* HDMI HDR Colorspace Spec Definitions */
> +#define NORMAL_COLORIMETRY_MASK 0x3
> +#define EXTENDED_COLORIMETRY_MASK0x7
> +#define HDMI_COLORIMETRY_BT2020_YCC ((3 << 0) | (6 << 2) | (0 << 5))
> +
> void lspcon_set_infoframes(struct intel_encoder *encoder,
> bool enable,
> const struct intel_crtc_state *crtc_state,
> @@ -551,6 +556,19 @@ void lspcon_set_infoframes(struct intel_encoder *encoder,
> HDMI_QUANTIZATION_RANGE_LIMITED :
> HDMI_QUANTIZATION_RANGE_FULL);
>
> + /*
> + * Set BT2020 colorspace if driving HDR data
> + * ToDo: Make this generic and expose all colorspaces for lspcon
> + */
> + if (lspcon->active && lspcon->hdr_supported) {
> + frame.avi.colorimetry =
> + HDMI_COLORIMETRY_BT2020_YCC &
> + NORMAL_COLORIMETRY_MASK;
> + frame.avi.extended_colorimetry =
> + (HDMI_COLORIMETRY_BT2020_YCC >> 2) &
> + EXTENDED_COLORIMETRY_MASK;
> + }
drm_hdmi_avi_infoframe_colorspace().
Also pls try to match intel_hdmi_compute_avi_infoframe() as
closesly as possible if we can't just outright reuse it. That
will make it easier to spot differences between the two.
> +
> ret = hdmi_infoframe_pack(&frame, buf, sizeof(buf));
> if (ret < 0) {
> DRM_ERROR("Failed to pack AVI IF\n");
> --
> 2.26.2
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v6 05/11] drm/i915/display: Enable HDR for Parade based lspcon
On Tue, Sep 15, 2020 at 02:30:41AM +0530, Uma Shankar wrote:
> Enable HDR for LSPCON based on Parade along with MCA.
>
> Signed-off-by: Uma Shankar
> Signed-off-by: Vipin Anand
> ---
> drivers/gpu/drm/i915/display/intel_lspcon.c | 19 ---
> 1 file changed, 8 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c
> b/drivers/gpu/drm/i915/display/intel_lspcon.c
> index b0ca494f1110..60863b825cc5 100644
> --- a/drivers/gpu/drm/i915/display/intel_lspcon.c
> +++ b/drivers/gpu/drm/i915/display/intel_lspcon.c
> @@ -36,6 +36,7 @@
> #define LSPCON_VENDOR_MCA_OUI 0x0060AD
>
> #define DPCD_MCA_LSPCON_HDR_STATUS 0x70003
> +#define DPCD_PARADE_LSPCON_HDR_STATUS0x00511
>
> /* AUX addresses to write MCA AVI IF */
> #define LSPCON_MCA_AVI_IF_WRITE_OFFSET 0x5C0
> @@ -112,16 +113,20 @@ static void lspcon_detect_hdr_capability(struct
> intel_lspcon *lspcon)
> container_of(lspcon, struct intel_digital_port, lspcon);
> struct drm_device *dev = intel_dig_port->base.base.dev;
> struct intel_dp *dp = lspcon_to_intel_dp(lspcon);
> + u32 lspcon_hdr_status_reg;
> u8 hdr_caps;
> int ret;
>
> - /* Enable HDR for MCA based LSPCON devices */
> if (lspcon->vendor == LSPCON_VENDOR_MCA)
> - ret = drm_dp_dpcd_read(&dp->aux, DPCD_MCA_LSPCON_HDR_STATUS,
> -&hdr_caps, 1);
> + lspcon_hdr_status_reg = DPCD_MCA_LSPCON_HDR_STATUS;
> + else if (lspcon->vendor == LSPCON_VENDOR_PARADE)
> + lspcon_hdr_status_reg = DPCD_PARADE_LSPCON_HDR_STATUS;
> else
> return;
That could be small helper function.
>
> + ret = drm_dp_dpcd_read(&dp->aux, lspcon_hdr_status_reg,
> +&hdr_caps, 1);
> +
> if (ret < 0) {
> drm_dbg_kms(dev, "hdr capability detection failed\n");
> lspcon->hdr_supported = false;
> @@ -465,14 +470,6 @@ void lspcon_write_infoframe(struct intel_encoder
> *encoder,
> struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> struct intel_lspcon *lspcon = enc_to_intel_lspcon(encoder);
>
> - /*
> - * Supporting HDR on MCA LSPCON
> - * Todo: Add support for Parade later
> - */
> - if (type == HDMI_PACKET_TYPE_GAMUT_METADATA &&
> - lspcon->vendor != LSPCON_VENDOR_MCA)
> - return;
> -
> switch (type) {
> case HDMI_INFOFRAME_TYPE_AVI:
> if (lspcon->vendor == LSPCON_VENDOR_MCA)
> --
> 2.26.2
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v6 06/11] drm/i915/display: Implement infoframes readback for LSPCON
On Tue, Sep 15, 2020 at 02:30:42AM +0530, Uma Shankar wrote:
> Implemented Infoframes enabled readback for LSPCON devices.
> This will help align the implementation with state readback
> infrastructure.
>
> v2: Added proper bitmask of enabled infoframes as per Ville's
> recommendation.
>
> Signed-off-by: Uma Shankar
> ---
> drivers/gpu/drm/i915/display/intel_lspcon.c | 57 -
> 1 file changed, 55 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c
> b/drivers/gpu/drm/i915/display/intel_lspcon.c
> index 60863b825cc5..565913b8e656 100644
> --- a/drivers/gpu/drm/i915/display/intel_lspcon.c
> +++ b/drivers/gpu/drm/i915/display/intel_lspcon.c
> @@ -576,11 +576,64 @@ void lspcon_set_infoframes(struct intel_encoder
> *encoder,
> buf, ret);
> }
>
> +static bool _lspcon_read_avi_infoframe_enabled_mca(struct drm_dp_aux *aux)
> +{
> + int ret;
> + u32 val = 0;
> + u16 reg = LSPCON_MCA_AVI_IF_CTRL;
> +
> + ret = drm_dp_dpcd_read(aux, reg, &val, 1);
> + if (ret < 0) {
> + DRM_ERROR("DPCD read failed, address 0x%x\n", reg);
> + return false;
> + }
> +
> + return val & LSPCON_MCA_AVI_IF_KICKOFF;
> +}
> +
> +static bool _lspcon_read_avi_infoframe_enabled_parade(struct drm_dp_aux *aux)
> +{
> + int ret;
> + u32 val = 0;
> + u16 reg = LSPCON_PARADE_AVI_IF_CTRL;
> +
> + ret = drm_dp_dpcd_read(aux, reg, &val, 1);
> + if (ret < 0) {
> + DRM_ERROR("DPCD read failed, address 0x%x\n", reg);
> + return false;
> + }
> +
> + return val & LSPCON_PARADE_AVI_IF_KICKOFF;
> +}
> +
> u32 lspcon_infoframes_enabled(struct intel_encoder *encoder,
> const struct intel_crtc_state *pipe_config)
> {
> - /* FIXME actually read this from the hw */
> - return 0;
> + struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> + struct intel_lspcon *lspcon = enc_to_intel_lspcon(encoder);
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> + bool infoframes_enabled;
> + u32 val = 0;
> + u32 mask, tmp;
> +
> + if (lspcon->vendor == LSPCON_VENDOR_MCA)
> + infoframes_enabled =
> _lspcon_read_avi_infoframe_enabled_mca(&intel_dp->aux);
> + else
> + infoframes_enabled =
> _lspcon_read_avi_infoframe_enabled_parade(&intel_dp->aux);
> +
> + if (infoframes_enabled)
> + val |= VIDEO_DIP_ENABLE_AVI_HSW;
Still not a fan of abusing the HSW specific reg values here.
> +
> + if (lspcon->hdr_supported) {
> + tmp = intel_de_read(dev_priv,
> +
> HSW_TVIDEO_DIP_CTL(pipe_config->cpu_transcoder));
> + mask = VIDEO_DIP_ENABLE_GMP_HSW;
> +
> + if (tmp & mask)
> + val |= mask;
> + }
> +
> + return val;
> }
>
> void lspcon_resume(struct intel_lspcon *lspcon)
> --
> 2.26.2
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v6 07/11] drm/i915/display: Implement DRM infoframe read for LSPCON
On Tue, Sep 15, 2020 at 02:30:43AM +0530, Uma Shankar wrote:
> Implement Read back of HDR metadata infoframes i.e Dynamic Range
> and Mastering Infoframe for LSPCON devices.
>
> v2: Added proper bitmask of enabled infoframes as per Ville's
> recommendation.
>
> Signed-off-by: Uma Shankar
> ---
> drivers/gpu/drm/i915/display/intel_hdmi.c | 10 ++
> drivers/gpu/drm/i915/display/intel_lspcon.c | 6 +-
> drivers/gpu/drm/i915/display/intel_lspcon.h | 4
> 3 files changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
> b/drivers/gpu/drm/i915/display/intel_hdmi.c
> index 1e40ed473fb9..02b0b5921bed 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
> @@ -600,6 +600,16 @@ void lspcon_drm_write_infoframe(struct intel_encoder
> *encoder,
> hsw_write_infoframe(encoder, crtc_state, type, frame, len);
> }
>
> +void lspcon_drm_read_infoframe(struct intel_encoder *encoder,
> +const struct intel_crtc_state *crtc_state,
> +unsigned int type,
> +void *frame, ssize_t len)
> +{
> + drm_dbg_kms(encoder->base.dev, "Read HDR metadata for lspcon\n");
> + /* It uses the legacy hsw implementation for the same */
> + hsw_read_infoframe(encoder, crtc_state, type, frame, len);
> +}
Another pointless wrapper.
> +
> static const u8 infoframe_type_to_idx[] = {
> HDMI_PACKET_TYPE_GENERAL_CONTROL,
> HDMI_PACKET_TYPE_GAMUT_METADATA,
> diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c
> b/drivers/gpu/drm/i915/display/intel_lspcon.c
> index 565913b8e656..ee77a5381cb5 100644
> --- a/drivers/gpu/drm/i915/display/intel_lspcon.c
> +++ b/drivers/gpu/drm/i915/display/intel_lspcon.c
> @@ -501,7 +501,11 @@ void lspcon_read_infoframe(struct intel_encoder *encoder,
> unsigned int type,
> void *frame, ssize_t len)
> {
> - /* FIXME implement this */
> + /* FIXME implement for AVI Infoframe as well */
> + if (type == HDMI_PACKET_TYPE_GAMUT_METADATA)
> + lspcon_drm_read_infoframe(encoder, crtc_state,
> + HDMI_PACKET_TYPE_GAMUT_METADATA,
> + frame, VIDEO_DIP_DATA_SIZE);
Again I'd just pass the params through.
> }
>
> /* HDMI HDR Colorspace Spec Definitions */
> diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.h
> b/drivers/gpu/drm/i915/display/intel_lspcon.h
> index 3fac05535731..1b9fb531128e 100644
> --- a/drivers/gpu/drm/i915/display/intel_lspcon.h
> +++ b/drivers/gpu/drm/i915/display/intel_lspcon.h
> @@ -38,4 +38,8 @@ void lspcon_drm_write_infoframe(struct intel_encoder
> *encoder,
> const struct intel_crtc_state *crtc_state,
> unsigned int type,
> const void *frame, ssize_t len);
> +void lspcon_drm_read_infoframe(struct intel_encoder *encoder,
> +const struct intel_crtc_state *crtc_state,
> +unsigned int type,
> +void *frame, ssize_t len);
> #endif /* __INTEL_LSPCON_H__ */
> --
> 2.26.2
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/gt: Scrub HW state on remove
== Series Details == Series: drm/i915/gt: Scrub HW state on remove URL : https://patchwork.freedesktop.org/series/82201/ State : warning == Summary == $ dim checkpatch origin/drm-tip dcd9a08264c1 drm/i915/gt: Scrub HW state on remove -:15: WARNING:TYPO_SPELLING: 'reseting' may be misspelled - perhaps 'resetting'? #15: reseting the GPU also impact the display engine and so the reset should total: 0 errors, 1 warnings, 0 checks, 28 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Scrub HW state on remove
== Series Details ==
Series: drm/i915/gt: Scrub HW state on remove
URL : https://patchwork.freedesktop.org/series/82201/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9074 -> Patchwork_18589
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18589/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_18589:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@core_hotunplug@unbind-rebind}:
- fi-blb-e6850: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9074/fi-blb-e6850/igt@core_hotunp...@unbind-rebind.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18589/fi-blb-e6850/igt@core_hotunp...@unbind-rebind.html
Known issues
Here are the changes found in Patchwork_18589 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-byt-j1900: [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9074/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18589/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1:
- fi-icl-u2: [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9074/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18589/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
* igt@kms_flip@basic-flip-vs-wf_vblank@c-hdmi-a2:
- fi-skl-guc: [PASS][7] -> [DMESG-WARN][8] ([i915#2203])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9074/fi-skl-guc/igt@kms_flip@basic-flip-vs-wf_vbl...@c-hdmi-a2.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18589/fi-skl-guc/igt@kms_flip@basic-flip-vs-wf_vbl...@c-hdmi-a2.html
Possible fixes
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka: [DMESG-WARN][9] ([i915#1982]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9074/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18589/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_pm_rpm@module-reload:
- fi-bsw-n3050: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9074/fi-bsw-n3050/igt@i915_pm_...@module-reload.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18589/fi-bsw-n3050/igt@i915_pm_...@module-reload.html
* igt@kms_busy@basic@flip:
- fi-apl-guc: [INCOMPLETE][13] ([i915#1635]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9074/fi-apl-guc/igt@kms_busy@ba...@flip.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18589/fi-apl-guc/igt@kms_busy@ba...@flip.html
- fi-kbl-x1275: [DMESG-WARN][15] ([i915#62] / [i915#92] / [i915#95])
-> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9074/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18589/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-icl-u2: [DMESG-WARN][17] ([i915#1982]) -> [PASS][18] +1
similar issue
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9074/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18589/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
Warnings
* igt@gem_exec_suspend@basic-s3:
- fi-kbl-x1275: [DMESG-WARN][19] ([i915#62] / [i915#92]) ->
[DMESG-WARN][20] ([i915#1982] / [i915#62] / [i915#92] / [i915#95])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9074/fi-kbl-x1275/igt@gem_exec_susp...@basic-s3.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18589/fi-kbl-x1275/igt@gem_exec_susp...@basic-s3.html
* igt@kms_force_connector_basic@prune-stale-modes:
- fi-kbl-x1275: [DMESG-WARN][21] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][22] ([i915#62] / [i915#92]) +1 similar issue
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9074/fi-kbl-x1275/igt@kms_force_connector_ba...@prune-stale-modes.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18589/fi-kbl-x1275/igt@kms_force_connector_ba...@prune-stale-modes.html
* igt@prime_vgem@basic-fence-fli
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/edp/jsl: Update vswing table for HBR and HBR2
== Series Details ==
Series: drm/i915/edp/jsl: Update vswing table for HBR and HBR2
URL : https://patchwork.freedesktop.org/series/82206/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
548dfee5bc0f drm/i915/edp/jsl: Update vswing table for HBR and HBR2
-:83: WARNING:UNNECESSARY_ELSE: else is not generally useful after a break or
return
#83: FILE: drivers/gpu/drm/i915/display/intel_ddi.c:1143:
+ return jsl_combo_phy_ddi_translations_edp_hbr2;
+ } else {
-:88: WARNING:PREFER_FALLTHROUGH: Prefer 'fallthrough;' over fallthrough comment
#88: FILE: drivers/gpu/drm/i915/display/intel_ddi.c:1148:
+ /* fall through */
total: 0 errors, 2 warnings, 0 checks, 97 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/edp/jsl: Update vswing table for HBR and HBR2
== Series Details ==
Series: drm/i915/edp/jsl: Update vswing table for HBR and HBR2
URL : https://patchwork.freedesktop.org/series/82206/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9075 -> Patchwork_18590
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18590/index.html
Known issues
Here are the changes found in Patchwork_18590 that come from known issues:
### IGT changes ###
Possible fixes
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka: [DMESG-WARN][1] ([i915#1982]) -> [PASS][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9075/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18590/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
* igt@vgem_basic@unload:
- fi-skl-guc: [DMESG-WARN][3] ([i915#2203]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9075/fi-skl-guc/igt@vgem_ba...@unload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18590/fi-skl-guc/igt@vgem_ba...@unload.html
Warnings
* igt@i915_pm_rpm@module-reload:
- fi-kbl-x1275: [DMESG-FAIL][5] ([i915#62]) -> [DMESG-FAIL][6]
([i915#62] / [i915#95])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9075/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18590/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
* igt@kms_flip@basic-flip-vs-wf_vblank@a-dp1:
- fi-kbl-x1275: [DMESG-WARN][7] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][8] ([i915#62] / [i915#92]) +1 similar issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9075/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-wf_vbl...@a-dp1.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18590/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-wf_vbl...@a-dp1.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-c:
- fi-kbl-x1275: [DMESG-WARN][9] ([i915#62] / [i915#92]) ->
[DMESG-WARN][10] ([i915#62] / [i915#92] / [i915#95]) +7 similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9075/fi-kbl-x1275/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18590/fi-kbl-x1275/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-kbl-x1275: [DMESG-WARN][11] ([i915#1982] / [i915#62] / [i915#92]
/ [i915#95]) -> [DMESG-WARN][12] ([i915#62] / [i915#92] / [i915#95])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9075/fi-kbl-x1275/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18590/fi-kbl-x1275/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
* igt@vgem_basic@unload:
- fi-kbl-x1275: [DMESG-WARN][13] ([i915#62] / [i915#92]) ->
[DMESG-WARN][14] ([i915#95])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9075/fi-kbl-x1275/igt@vgem_ba...@unload.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18590/fi-kbl-x1275/igt@vgem_ba...@unload.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2203]: https://gitlab.freedesktop.org/drm/intel/issues/2203
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
[i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
Participating hosts (46 -> 39)
--
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600 fi-byt-clapper fi-bdw-samus
Build changes
-
* Linux: CI_DRM_9075 -> Patchwork_18590
CI-20190529: 20190529
CI_DRM_9075: fd24361b2b76956b5c056bc430a4c77edecb7744 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5792: cbaf441899f3b4f36cca5996aa6a69e7399b2dbd @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_18590: 548dfee5bc0ff01e16e2313ef9193950370b1a9c @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
548dfee5bc0f drm/i915/edp/jsl: Update vswing table for HBR and HBR2
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18590/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Read DIMM size in Gb rather than GB
== Series Details ==
Series: drm/i915: Read DIMM size in Gb rather than GB
URL : https://patchwork.freedesktop.org/series/82210/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9075 -> Patchwork_18591
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18591/index.html
Known issues
Here are the changes found in Patchwork_18591 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@coherency:
- fi-gdg-551: [PASS][1] -> [DMESG-FAIL][2] ([i915#1748])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9075/fi-gdg-551/igt@i915_selftest@l...@coherency.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18591/fi-gdg-551/igt@i915_selftest@l...@coherency.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-7500u: [PASS][3] -> [DMESG-WARN][4] ([i915#2203])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9075/fi-kbl-7500u/igt@kms_chamel...@common-hpd-after-suspend.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18591/fi-kbl-7500u/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-icl-u2: [PASS][5] -> [DMESG-WARN][6] ([i915#1982]) +2 similar
issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9075/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18591/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
Possible fixes
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka: [DMESG-WARN][7] ([i915#1982]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9075/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18591/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
* igt@vgem_basic@unload:
- fi-skl-guc: [DMESG-WARN][9] ([i915#2203]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9075/fi-skl-guc/igt@vgem_ba...@unload.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18591/fi-skl-guc/igt@vgem_ba...@unload.html
- fi-kbl-x1275: [DMESG-WARN][11] ([i915#62] / [i915#92]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9075/fi-kbl-x1275/igt@vgem_ba...@unload.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18591/fi-kbl-x1275/igt@vgem_ba...@unload.html
Warnings
* igt@i915_module_load@reload:
- fi-kbl-x1275: [DMESG-WARN][13] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][14] ([i915#62] / [i915#92])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9075/fi-kbl-x1275/igt@i915_module_l...@reload.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18591/fi-kbl-x1275/igt@i915_module_l...@reload.html
* igt@i915_pm_rpm@module-reload:
- fi-kbl-x1275: [DMESG-FAIL][15] ([i915#62]) -> [DMESG-FAIL][16]
([i915#62] / [i915#95])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9075/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18591/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
* igt@kms_force_connector_basic@prune-stale-modes:
- fi-kbl-x1275: [DMESG-WARN][17] ([i915#62] / [i915#92]) ->
[DMESG-WARN][18] ([i915#62] / [i915#92] / [i915#95]) +4 similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9075/fi-kbl-x1275/igt@kms_force_connector_ba...@prune-stale-modes.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18591/fi-kbl-x1275/igt@kms_force_connector_ba...@prune-stale-modes.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-kbl-x1275: [DMESG-WARN][19] ([i915#1982] / [i915#62] / [i915#92]
/ [i915#95]) -> [DMESG-WARN][20] ([i915#62] / [i915#92] / [i915#95])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9075/fi-kbl-x1275/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18591/fi-kbl-x1275/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1748]: https://gitlab.freedesktop.org/drm/intel/issues/1748
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2203]: https://gitlab.freedesktop.org/drm/intel/issues/2203
[i915#2411]: https://gitlab.freedesktop.org/drm/intel/issues/2411
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
[i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
[k.org#205379]: https://bugzil
[Intel-gfx] ✓ Fi.CI.IGT: success for vfio/pci: Refine Intel IGD OpRegion support (rev2)
== Series Details == Series: vfio/pci: Refine Intel IGD OpRegion support (rev2) URL : https://patchwork.freedesktop.org/series/79293/ State : success == Summary == CI Bug Log - changes from CI_DRM_9071_full -> Patchwork_18587_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_18587_full that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@mock@contexts: - shard-apl: [PASS][1] -> [INCOMPLETE][2] ([i915#1635] / [i915#2278]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9071/shard-apl3/igt@i915_selftest@m...@contexts.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18587/shard-apl7/igt@i915_selftest@m...@contexts.html * igt@kms_big_fb@y-tiled-8bpp-rotate-0: - shard-kbl: [PASS][3] -> [DMESG-WARN][4] ([i915#1982]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9071/shard-kbl2/igt@kms_big...@y-tiled-8bpp-rotate-0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18587/shard-kbl4/igt@kms_big...@y-tiled-8bpp-rotate-0.html * igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size: - shard-skl: [PASS][5] -> [FAIL][6] ([i915#2346]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9071/shard-skl3/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions-varying-size.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18587/shard-skl10/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions-varying-size.html * igt@kms_cursor_legacy@short-flip-before-cursor-atomic-transitions: - shard-skl: [PASS][7] -> [DMESG-WARN][8] ([i915#1982]) +5 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9071/shard-skl9/igt@kms_cursor_leg...@short-flip-before-cursor-atomic-transitions.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18587/shard-skl4/igt@kms_cursor_leg...@short-flip-before-cursor-atomic-transitions.html * igt@kms_flip@flip-vs-expired-vblank-interruptible@c-edp1: - shard-skl: [PASS][9] -> [FAIL][10] ([i915#79]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9071/shard-skl3/igt@kms_flip@flip-vs-expired-vblank-interrupti...@c-edp1.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18587/shard-skl10/igt@kms_flip@flip-vs-expired-vblank-interrupti...@c-edp1.html * igt@kms_flip@flip-vs-suspend-interruptible@b-edp1: - shard-skl: [PASS][11] -> [INCOMPLETE][12] ([i915#198]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9071/shard-skl5/igt@kms_flip@flip-vs-suspend-interrupti...@b-edp1.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18587/shard-skl5/igt@kms_flip@flip-vs-suspend-interrupti...@b-edp1.html * igt@kms_flip@plain-flip-fb-recreate-interruptible@c-hdmi-a1: - shard-glk: [PASS][13] -> [FAIL][14] ([i915#2122]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9071/shard-glk7/igt@kms_flip@plain-flip-fb-recreate-interrupti...@c-hdmi-a1.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18587/shard-glk7/igt@kms_flip@plain-flip-fb-recreate-interrupti...@c-hdmi-a1.html * igt@kms_frontbuffer_tracking@fbc-suspend: - shard-kbl: [PASS][15] -> [DMESG-WARN][16] ([i915#180]) +8 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9071/shard-kbl7/igt@kms_frontbuffer_track...@fbc-suspend.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18587/shard-kbl3/igt@kms_frontbuffer_track...@fbc-suspend.html * igt@kms_hdr@bpc-switch-dpms: - shard-skl: [PASS][17] -> [FAIL][18] ([i915#1188]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9071/shard-skl3/igt@kms_...@bpc-switch-dpms.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18587/shard-skl7/igt@kms_...@bpc-switch-dpms.html * igt@kms_lease@atomic_implicit_crtc: - shard-snb: [PASS][19] -> [SKIP][20] ([fdo#109271]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9071/shard-snb1/igt@kms_lease@atomic_implicit_crtc.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18587/shard-snb5/igt@kms_lease@atomic_implicit_crtc.html * igt@kms_plane@plane-panning-bottom-right-pipe-a-planes: - shard-iclb: [PASS][21] -> [DMESG-WARN][22] ([i915#1982]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9071/shard-iclb4/igt@kms_pl...@plane-panning-bottom-right-pipe-a-planes.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18587/shard-iclb2/igt@kms_pl...@plane-panning-bottom-right-pipe-a-planes.html * igt@kms_plane_alpha_blend@pipe-a-coverage-7efc: - shard-skl: [PASS][23] -> [DMESG-FAIL][24] ([fdo#108145] / [i915#1982]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9071/shard-skl4/igt@kms_plane_alpha_bl...@pipe-a-coverage-7efc.html [
Re: [Intel-gfx] [PATCH] i915: Introduce quirk for shifting eDP brightness.
Thank you for the reply. And in regards to digging into it further, thanks for requesting that I do some more due diligence here :) Also if you did get around to it, thanks for double-checking with Bill! Let me know if you'd like me to reach out instead, or if anything else needs to be done in this regard. So to clarify the plan: if we do actually move forwards with leaving the current functionality as the default, do we need to have the complete list of devices which need the quirk applied when the patch first goes in? From my perspective, we definitely have one device which needs the quirk (and preferably, it'd be good to do it sooner than later so that we can get this bugfix out to our users) and an unknowable number of others. Would it be OK to introduce the quirk for just Pixelbook and to follow up to add others once we have that list? It may take a good amount of time for me to herd the cats inside Google, especially given there's a chance that there are affected laptops and that no one has noticed (e.g., I almost didn't notice with the Pixelbook). Given Lyude's analysis it seems like Chrome OS devices may be the largest affected group here, so I am incentivized to not drop the ball after fixing my immediate Pixelbook problem :) On Fri, Sep 25, 2020 at 10:53 AM Lyude Paul wrote: > > On Thu, 2020-09-24 at 17:46 -0600, Kevin Chowski wrote: > > cc back a few others who were unintentionally dropped from the thread > > earlier. > > > > Someone (at Google) helped me dig into this a little more and they > > found a document titled "eDP Backlight Brightness bit alignment" sent > > out for review in January 2017. I registered for a new account (google > > is a member) and have access to the document; here is the URL for > > those who also have access: > > https://groups.vesa.org/wg/AllMem/document/7786. For what it's worth, > > it seems like Lyude's contact Bill Lempesis uploaded this > > change-request document, so I think we can reach out to him if we have > > further questions. It's actually unclear to me what the status of this > > change request is, and whether it's been officially accepted. But I > > think it can be seen as some official advice on how we can move > > forward here. > > > > Basically, this is a change request to the spec which acknowledges > > that, despite the original spec implying that the > > most-significant-bits were relevant here, many implementations used > > the least-significant-bits. In defense of most-significant it laid out > > some similar arguments to what Ville was saying. But it ends up > > saying: > > > > > Unfortunately, the most common interpretation that we have > > > encountered is case 1 in the example above. TCON vendors > > > tend to align the valid bits to the LSBs, not the MSBs. > > > > Instead of changing the default defined functionality (as some earlier > > version of this doc apparently suggested), this doc prefers to > > allocate two extra bits in EDP_GENERAL_CAPABILITY_2 so that future > > backlight devices can specify to the Source how to program them: > > > > 00: the current functionality, i,e. no defined interpretation > > 01: aligned to most-significant bits > > 10: aligned to least-significant bits > > 11: reserved > > > > It also says "[Sources] should only need panel-specific workarounds > > for the currently available panels." > > > > So I believe this document is an acknowledgement of many > > implementations having their alignment to the least-significant bits, > > and (to my eyes) clearly validates that the spec "should" be the > > opposite. If we believe the doc's claim that "the most common > > interpretation" is least-significant, it seems to me that it would > > require more quirks if we made most-significant the default > > implementation. > > > > Ville mentioned at some point earlier that we should try to match the > > spec, whereas Lyude mentioned we should prefer to do what the majority > > of machines do. What do you both think of this new development? > > That's how displayport happens to be sometimes :). Definitely isn't the first > time something in the spec like this got implemented incorrectly so many times > by different vendors that they had to update the spec in response (same thing > happened with MST and interleaved sideband messages as of DP 2.0), so I'm > really glad we went and actually investigated this. > > So yes - I think a quirk for this would definitely be a good idea, and IMO we > should always lean on the side that more panels implement even if it's not > according to spec - so defaulting to the behavior we currently have in the > kernel, and adding quirks for panels that were smart enough not to fall for > this would probably be the best way to go. That just leaves the challenge of > "how do we figure out which panels actually need this and which ones don't?" > > This might end up being a bit of a challenge, but I've got some ideas on how > we might be able to tackle it to the best of our ability based off my >
Re: [Intel-gfx] [PATCH v2] drm/i915/edp/jsl: Update vswing table for HBR and HBR2
On Tue, 2020-09-29 at 17:41 +0530, Tejas Upadhyay wrote:
> JSL has update in vswing table for eDP
Would be nice to mention in the commit description why PCH is being used, that
would avoid Ville's question.
>
> BSpec: 21257
>
> Changes since V1 :
> - IS_ELKHARTLAKE and IS_JASPERLAKE is replaced with
> HAS_PCH_MCC(EHL) and HAS_PCH_JSP(JSL) respectively
> - Reverted EHL/JSL PCI ids split change
>
> Signed-off-by: Tejas Upadhyay <
> tejaskumarx.surendrakumar.upadh...@intel.com
> >
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 67 ++--
> 1 file changed, 64 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 4d06178cd76c..e6e93d01d0ce 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -582,6 +582,34 @@ static const struct cnl_ddi_buf_trans
> ehl_combo_phy_ddi_translations_dp[] = {
> { 0x6, 0x7F, 0x3F, 0x00, 0x00 },/* 900 900 0.0 */
> };
>
> +static const struct cnl_ddi_buf_trans
> jsl_combo_phy_ddi_translations_edp_hbr[] = {
> + /* NT mV Trans mV db*/
> + { 0x8, 0x7F, 0x3F, 0x00, 0x00 },/* 200 200 0.0 */
> + { 0x8, 0x7F, 0x38, 0x00, 0x07 },/* 200 250 1.9 */
> + { 0x1, 0x7F, 0x33, 0x00, 0x0C },/* 200 300 3.5 */
> + { 0xA, 0x35, 0x36, 0x00, 0x09 },/* 200 350 4.9 */
> + { 0x8, 0x7F, 0x3F, 0x00, 0x00 },/* 250 250 0.0 */
> + { 0x1, 0x7F, 0x38, 0x00, 0x07 },/* 250 300 1.6 */
> + { 0xA, 0x35, 0x35, 0x00, 0x0A },/* 250 350 2.9 */
> + { 0x1, 0x7F, 0x3F, 0x00, 0x00 },/* 300 300 0.0 */
> + { 0xA, 0x35, 0x38, 0x00, 0x07 },/* 300 350 1.3 */
> + { 0xA, 0x35, 0x3F, 0x00, 0x00 },/* 350 350 0.0 */
> +};
> +
> +static const struct cnl_ddi_buf_trans
> jsl_combo_phy_ddi_translations_edp_hbr2[] = {
> + /* NT mV Trans mV db*/
> + { 0x8, 0x7F, 0x3F, 0x00, 0x00 },/* 200 200 0.0 */
> + { 0x8, 0x7F, 0x3F, 0x00, 0x00 },/* 200 250 1.9 */
> + { 0x1, 0x7F, 0x3D, 0x00, 0x02 },/* 200 300 3.5 */
> + { 0xA, 0x35, 0x38, 0x00, 0x07 },/* 200 350 4.9 */
> + { 0x8, 0x7F, 0x3F, 0x00, 0x00 },/* 250 250 0.0 */
> + { 0x1, 0x7F, 0x3F, 0x00, 0x00 },/* 250 300 1.6 */
> + { 0xA, 0x35, 0x3A, 0x00, 0x05 },/* 250 350 2.9 */
> + { 0x1, 0x7F, 0x3F, 0x00, 0x00 },/* 300 300 0.0 */
> + { 0xA, 0x35, 0x38, 0x00, 0x07 },/* 300 350 1.3 */
> + { 0xA, 0x35, 0x3F, 0x00, 0x00 },/* 350 350 0.0 */
> +};
Tables matches specification.
> +
> struct icl_mg_phy_ddi_buf_trans {
> u32 cri_txdeemph_override_11_6;
> u32 cri_txdeemph_override_5_0;
> @@ -1069,7 +1097,6 @@ icl_get_mg_buf_trans(struct intel_encoder *encoder, int
> type, int rate,
> *n_entries = ARRAY_SIZE(icl_mg_phy_ddi_translations_rbr_hbr);
> return icl_mg_phy_ddi_translations_rbr_hbr;
> }
> -
Probably not intentional.
Reviewed-by: José Roberto de Souza
Will push with this line fixed as soon as CI finish testing.
> static const struct cnl_ddi_buf_trans *
> ehl_get_combo_buf_trans(struct intel_encoder *encoder, int type, int rate,
> int *n_entries)
> @@ -1098,6 +1125,34 @@ ehl_get_combo_buf_trans(struct intel_encoder *encoder,
> int type, int rate,
> }
> }
>
> +static const struct cnl_ddi_buf_trans *
> +jsl_get_combo_buf_trans(struct intel_encoder *encoder, int type, int rate,
> + int *n_entries)
> +{
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> +
> + switch (type) {
> + case INTEL_OUTPUT_HDMI:
> + *n_entries = ARRAY_SIZE(icl_combo_phy_ddi_translations_hdmi);
> + return icl_combo_phy_ddi_translations_hdmi;
> + case INTEL_OUTPUT_EDP:
> + if (dev_priv->vbt.edp.low_vswing) {
> + if (rate > 27) {
> + *n_entries =
> ARRAY_SIZE(jsl_combo_phy_ddi_translations_edp_hbr2);
> + return jsl_combo_phy_ddi_translations_edp_hbr2;
> + } else {
> + *n_entries =
> ARRAY_SIZE(jsl_combo_phy_ddi_translations_edp_hbr);
> + return jsl_combo_phy_ddi_translations_edp_hbr;
> + }
> + }
> + /* fall through */
> + default:
> + /* All combo DP and eDP ports that do not support low_vswing */
> + *n_entries = ARRAY_SIZE(icl_combo_phy_ddi_translations_dp_hbr2);
> + return icl_combo_phy_ddi_translations_dp_hbr2;
> +
Re: [Intel-gfx] [PATCH v2] drm/i915/edp/jsl: Update vswing table for HBR and HBR2
On Tue, Sep 29, 2020 at 07:33:45PM +, Souza, Jose wrote:
> On Tue, 2020-09-29 at 17:41 +0530, Tejas Upadhyay wrote:
> > JSL has update in vswing table for eDP
>
> Would be nice to mention in the commit description why PCH is being used,
> that would avoid Ville's question.
If the thing has nothing to do PCH then it should not use the PCH type
for the the check. Instead we should just do the EHL/JSL split.
>
> >
> > BSpec: 21257
> >
> > Changes since V1 :
> > - IS_ELKHARTLAKE and IS_JASPERLAKE is replaced with
> > HAS_PCH_MCC(EHL) and HAS_PCH_JSP(JSL) respectively
> > - Reverted EHL/JSL PCI ids split change
> >
> > Signed-off-by: Tejas Upadhyay <
> > tejaskumarx.surendrakumar.upadh...@intel.com
> > >
> > ---
> > drivers/gpu/drm/i915/display/intel_ddi.c | 67 ++--
> > 1 file changed, 64 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > index 4d06178cd76c..e6e93d01d0ce 100644
> > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > @@ -582,6 +582,34 @@ static const struct cnl_ddi_buf_trans
> > ehl_combo_phy_ddi_translations_dp[] = {
> > { 0x6, 0x7F, 0x3F, 0x00, 0x00 },/* 900 900 0.0 */
> > };
> >
> > +static const struct cnl_ddi_buf_trans
> > jsl_combo_phy_ddi_translations_edp_hbr[] = {
> > + /* NT mV Trans mV db*/
> > + { 0x8, 0x7F, 0x3F, 0x00, 0x00 },/* 200 200 0.0 */
> > + { 0x8, 0x7F, 0x38, 0x00, 0x07 },/* 200 250 1.9 */
> > + { 0x1, 0x7F, 0x33, 0x00, 0x0C },/* 200 300 3.5 */
> > + { 0xA, 0x35, 0x36, 0x00, 0x09 },/* 200 350 4.9 */
> > + { 0x8, 0x7F, 0x3F, 0x00, 0x00 },/* 250 250 0.0 */
> > + { 0x1, 0x7F, 0x38, 0x00, 0x07 },/* 250 300 1.6 */
> > + { 0xA, 0x35, 0x35, 0x00, 0x0A },/* 250 350 2.9 */
> > + { 0x1, 0x7F, 0x3F, 0x00, 0x00 },/* 300 300 0.0 */
> > + { 0xA, 0x35, 0x38, 0x00, 0x07 },/* 300 350 1.3 */
> > + { 0xA, 0x35, 0x3F, 0x00, 0x00 },/* 350 350 0.0 */
> > +};
> > +
> > +static const struct cnl_ddi_buf_trans
> > jsl_combo_phy_ddi_translations_edp_hbr2[] = {
> > + /* NT mV Trans mV db*/
> > + { 0x8, 0x7F, 0x3F, 0x00, 0x00 },/* 200 200 0.0 */
> > + { 0x8, 0x7F, 0x3F, 0x00, 0x00 },/* 200 250 1.9 */
> > + { 0x1, 0x7F, 0x3D, 0x00, 0x02 },/* 200 300 3.5 */
> > + { 0xA, 0x35, 0x38, 0x00, 0x07 },/* 200 350 4.9 */
> > + { 0x8, 0x7F, 0x3F, 0x00, 0x00 },/* 250 250 0.0 */
> > + { 0x1, 0x7F, 0x3F, 0x00, 0x00 },/* 250 300 1.6 */
> > + { 0xA, 0x35, 0x3A, 0x00, 0x05 },/* 250 350 2.9 */
> > + { 0x1, 0x7F, 0x3F, 0x00, 0x00 },/* 300 300 0.0 */
> > + { 0xA, 0x35, 0x38, 0x00, 0x07 },/* 300 350 1.3 */
> > + { 0xA, 0x35, 0x3F, 0x00, 0x00 },/* 350 350 0.0 */
> > +};
>
> Tables matches specification.
>
> > +
> > struct icl_mg_phy_ddi_buf_trans {
> > u32 cri_txdeemph_override_11_6;
> > u32 cri_txdeemph_override_5_0;
> > @@ -1069,7 +1097,6 @@ icl_get_mg_buf_trans(struct intel_encoder *encoder,
> > int type, int rate,
> > *n_entries = ARRAY_SIZE(icl_mg_phy_ddi_translations_rbr_hbr);
> > return icl_mg_phy_ddi_translations_rbr_hbr;
> > }
> > -
>
> Probably not intentional.
>
> Reviewed-by: José Roberto de Souza
>
> Will push with this line fixed as soon as CI finish testing.
>
>
> > static const struct cnl_ddi_buf_trans *
> > ehl_get_combo_buf_trans(struct intel_encoder *encoder, int type, int rate,
> > int *n_entries)
> > @@ -1098,6 +1125,34 @@ ehl_get_combo_buf_trans(struct intel_encoder
> > *encoder, int type, int rate,
> > }
> > }
> >
> > +static const struct cnl_ddi_buf_trans *
> > +jsl_get_combo_buf_trans(struct intel_encoder *encoder, int type, int rate,
> > + int *n_entries)
> > +{
> > + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > +
> > + switch (type) {
> > + case INTEL_OUTPUT_HDMI:
> > + *n_entries = ARRAY_SIZE(icl_combo_phy_ddi_translations_hdmi);
> > + return icl_combo_phy_ddi_translations_hdmi;
> > + case INTEL_OUTPUT_EDP:
> > + if (dev_priv->vbt.edp.low_vswing) {
> > + if (rate > 27) {
> > + *n_entries =
> > ARRAY_SIZE(jsl_combo_phy_ddi_translations_edp_hbr2);
> > + return jsl_combo_phy_ddi_translations_edp_hbr2;
> > + } else {
> > + *n_entries =
> > ARRAY_SIZE(jsl_combo_phy_ddi_translations_edp_hbr);
> > + return jsl_combo_phy_ddi_translations_edp_hbr;
Re: [Intel-gfx] [PATCH rdma-next v4 4/4] RDMA/umem: Move to allocate SG table from pages
On Sun, Sep 27, 2020 at 09:46:47AM +0300, Leon Romanovsky wrote:
> @@ -296,11 +223,17 @@ static struct ib_umem *__ib_umem_get(struct ib_device
> *device,
> goto umem_release;
>
> cur_base += ret * PAGE_SIZE;
> - npages -= ret;
> -
> - sg = ib_umem_add_sg_table(sg, page_list, ret,
> - dma_get_max_seg_size(device->dma_device),
> - &umem->sg_nents);
> + npages -= ret;
> + sg = __sg_alloc_table_from_pages(
> + &umem->sg_head, page_list, ret, 0, ret << PAGE_SHIFT,
> + dma_get_max_seg_size(device->dma_device), sg, npages,
> + GFP_KERNEL);
> + umem->sg_nents = umem->sg_head.nents;
> + if (IS_ERR(sg)) {
> + unpin_user_pages_dirty_lock(page_list, ret, 0);
> + ret = PTR_ERR(sg);
> + goto umem_release;
> + }
> }
>
> sg_mark_end(sg);
Does it still need the sg_mark_end?
Jason
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 6/7] drm: Validate encoder->possible_crtcs
On Tue, Sep 29, 2020 at 8:31 AM Jan Kiszka wrote:
>
> On 10.09.20 20:18, Deucher, Alexander wrote:
> > [AMD Public Use]
> >
> >
> >
> >> -Original Message-
> >> From: amd-gfx On Behalf Of
> >> Daniel Vetter
> >> Sent: Monday, September 7, 2020 3:15 AM
> >> To: Jan Kiszka ; amd-gfx list >> g...@lists.freedesktop.org>; Wentland, Harry ;
> >> Kazlauskas, Nicholas
> >> Cc: dri-devel ; intel-gfx >> g...@lists.freedesktop.org>; Thomas Zimmermann
> >> ; Ville Syrjala
> >> Subject: Re: [PATCH v3 6/7] drm: Validate encoder->possible_crtcs
> >>
> >> On Sun, Sep 6, 2020 at 1:19 PM Jan Kiszka wrote:
> >>>
> >>> On 11.02.20 18:04, Daniel Vetter wrote:
> On Tue, Feb 11, 2020 at 06:22:07PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > WARN if the encoder possible_crtcs is effectively empty or contains
> > bits for non-existing crtcs.
> >
> > v2: Move to drm_mode_config_validate() (Daniel)
> > Make the docs say we WARN when this is wrong (Daniel)
> > Extract full_crtc_mask()
> >
> > Cc: Thomas Zimmermann
> > Cc: Daniel Vetter
> > Signed-off-by: Ville Syrjälä
>
> When pushing the fixup needs to be applied before the validation
> patch here, because we don't want to anger the bisect gods.
>
> Reviewed-by: Daniel Vetter
>
> I think with the fixup we should be good enough with the existing
> nonsense in drivers. Fingers crossed.
> -Daniel
>
>
> > ---
> > drivers/gpu/drm/drm_mode_config.c | 27
> >> ++-
> > include/drm/drm_encoder.h | 2 +-
> > 2 files changed, 27 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_mode_config.c
> > b/drivers/gpu/drm/drm_mode_config.c
> > index afc91447293a..4c1b350ddb95 100644
> > --- a/drivers/gpu/drm/drm_mode_config.c
> > +++ b/drivers/gpu/drm/drm_mode_config.c
> > @@ -581,6 +581,29 @@ static void
> >> validate_encoder_possible_clones(struct drm_encoder *encoder)
> > encoder->possible_clones, encoder_mask); }
> >
> > +static u32 full_crtc_mask(struct drm_device *dev) {
> > +struct drm_crtc *crtc;
> > +u32 crtc_mask = 0;
> > +
> > +drm_for_each_crtc(crtc, dev)
> > +crtc_mask |= drm_crtc_mask(crtc);
> > +
> > +return crtc_mask;
> > +}
> > +
> > +static void validate_encoder_possible_crtcs(struct drm_encoder
> > +*encoder) {
> > +u32 crtc_mask = full_crtc_mask(encoder->dev);
> > +
> > +WARN((encoder->possible_crtcs & crtc_mask) == 0 ||
> > + (encoder->possible_crtcs & ~crtc_mask) != 0,
> > + "Bogus possible_crtcs: "
> > + "[ENCODER:%d:%s] possible_crtcs=0x%x (full crtc mask=0x%x)\n",
> > + encoder->base.id, encoder->name,
> > + encoder->possible_crtcs, crtc_mask); }
> > +
> > void drm_mode_config_validate(struct drm_device *dev) {
> > struct drm_encoder *encoder;
> > @@ -588,6 +611,8 @@ void drm_mode_config_validate(struct
> >> drm_device *dev)
> > drm_for_each_encoder(encoder, dev)
> > fixup_encoder_possible_clones(encoder);
> >
> > -drm_for_each_encoder(encoder, dev)
> > +drm_for_each_encoder(encoder, dev) {
> > validate_encoder_possible_clones(encoder);
> > +validate_encoder_possible_crtcs(encoder);
> > +}
> > }
> > diff --git a/include/drm/drm_encoder.h b/include/drm/drm_encoder.h
> > index 3741963b9587..b236269f41ac 100644
> > --- a/include/drm/drm_encoder.h
> > +++ b/include/drm/drm_encoder.h
> > @@ -142,7 +142,7 @@ struct drm_encoder {
> > * the bits for all &drm_crtc objects this encoder can be
> > connected to
> > * before calling drm_dev_register().
> > *
> > - * In reality almost every driver gets this wrong.
> > + * You will get a WARN if you get this wrong in the driver.
> > *
> > * Note that since CRTC objects can't be hotplugged the assigned
> >> indices
> > * are stable and hence known before registering all objects.
> > --
> > 2.24.1
> >
>
> >>>
> >>> Triggers on an Advantech AIMB-228 (R1505G, 3 DP outputs):
> >>
> >> Adding amdgpu display folks.
> >
> > I took a quick look at this and it looks like we limit the number of crtcs
> > later in the mode init process if the number of physical displays can't
> > actually use more crtcs. E.g., the physical board configuration would only
> > allow for 3 active displays even if the hardware technically supports 4
> > crtcs. I presume that way we can just leave the additional hardware power
> > gated all the time.
> >
>
> So, will this be fixed any time soon? I don't feel qualified writing
> such a patch but I would obviously be happy to test one.
It's harmless, but I'll send out a patc
Re: [Intel-gfx] [PATCH v2] drm/i915/edp/jsl: Update vswing table for HBR and HBR2
On Tue, 2020-09-29 at 23:02 +0300, Ville Syrjälä wrote:
> On Tue, Sep 29, 2020 at 07:33:45PM +, Souza, Jose wrote:
> > On Tue, 2020-09-29 at 17:41 +0530, Tejas Upadhyay wrote:
> > > JSL has update in vswing table for eDP
> >
> > Would be nice to mention in the commit description why PCH is being used,
> > that would avoid Ville's question.
>
> If the thing has nothing to do PCH then it should not use the PCH type
> for the the check. Instead we should just do the EHL/JSL split.
In the first version Matt Roper suggested to use PCH to differentiate between
EHL and JSL, Jani also agreed with this solution.This 2 PCHs can only be
associate with EHL and JSL respectively, so no downsides here.
>
> > > BSpec: 21257
> > >
> > > Changes since V1 :
> > > - IS_ELKHARTLAKE and IS_JASPERLAKE is replaced with
> > > HAS_PCH_MCC(EHL) and HAS_PCH_JSP(JSL) respectively
> > > - Reverted EHL/JSL PCI ids split change
> > >
> > > Signed-off-by: Tejas Upadhyay <
> > > tejaskumarx.surendrakumar.upadh...@intel.com
> > >
> > >
> > > ---
> > > drivers/gpu/drm/i915/display/intel_ddi.c | 67 ++--
> > > 1 file changed, 64 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> > > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > > index 4d06178cd76c..e6e93d01d0ce 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > > @@ -582,6 +582,34 @@ static const struct cnl_ddi_buf_trans
> > > ehl_combo_phy_ddi_translations_dp[] = {
> > > { 0x6, 0x7F, 0x3F, 0x00, 0x00 },/* 900 900 0.0 */
> > > };
> > >
> > > +static const struct cnl_ddi_buf_trans
> > > jsl_combo_phy_ddi_translations_edp_hbr[] = {
> > > + /* NT mV Trans mV db*/
> > > + { 0x8, 0x7F, 0x3F, 0x00, 0x00 },/* 200 200 0.0 */
> > > + { 0x8, 0x7F, 0x38, 0x00, 0x07 },/* 200 250 1.9 */
> > > + { 0x1, 0x7F, 0x33, 0x00, 0x0C },/* 200 300 3.5 */
> > > + { 0xA, 0x35, 0x36, 0x00, 0x09 },/* 200 350 4.9 */
> > > + { 0x8, 0x7F, 0x3F, 0x00, 0x00 },/* 250 250 0.0 */
> > > + { 0x1, 0x7F, 0x38, 0x00, 0x07 },/* 250 300 1.6 */
> > > + { 0xA, 0x35, 0x35, 0x00, 0x0A },/* 250 350 2.9 */
> > > + { 0x1, 0x7F, 0x3F, 0x00, 0x00 },/* 300 300 0.0 */
> > > + { 0xA, 0x35, 0x38, 0x00, 0x07 },/* 300 350 1.3 */
> > > + { 0xA, 0x35, 0x3F, 0x00, 0x00 },/* 350 350 0.0 */
> > > +};
> > > +
> > > +static const struct cnl_ddi_buf_trans
> > > jsl_combo_phy_ddi_translations_edp_hbr2[] = {
> > > + /* NT mV Trans mV db*/
> > > + { 0x8, 0x7F, 0x3F, 0x00, 0x00 },/* 200 200 0.0 */
> > > + { 0x8, 0x7F, 0x3F, 0x00, 0x00 },/* 200 250 1.9 */
> > > + { 0x1, 0x7F, 0x3D, 0x00, 0x02 },/* 200 300 3.5 */
> > > + { 0xA, 0x35, 0x38, 0x00, 0x07 },/* 200 350 4.9 */
> > > + { 0x8, 0x7F, 0x3F, 0x00, 0x00 },/* 250 250 0.0 */
> > > + { 0x1, 0x7F, 0x3F, 0x00, 0x00 },/* 250 300 1.6 */
> > > + { 0xA, 0x35, 0x3A, 0x00, 0x05 },/* 250 350 2.9 */
> > > + { 0x1, 0x7F, 0x3F, 0x00, 0x00 },/* 300 300 0.0 */
> > > + { 0xA, 0x35, 0x38, 0x00, 0x07 },/* 300 350 1.3 */
> > > + { 0xA, 0x35, 0x3F, 0x00, 0x00 },/* 350 350 0.0 */
> > > +};
> >
> > Tables matches specification.
> >
> > > +
> > > struct icl_mg_phy_ddi_buf_trans {
> > > u32 cri_txdeemph_override_11_6;
> > > u32 cri_txdeemph_override_5_0;
> > > @@ -1069,7 +1097,6 @@ icl_get_mg_buf_trans(struct intel_encoder *encoder,
> > > int type, int rate,
> > > *n_entries = ARRAY_SIZE(icl_mg_phy_ddi_translations_rbr_hbr);
> > > return icl_mg_phy_ddi_translations_rbr_hbr;
> > > }
> > > -
> >
> > Probably not intentional.
> >
> > Reviewed-by: José Roberto de Souza <
> > jose.so...@intel.com
> > >
> >
> > Will push with this line fixed as soon as CI finish testing.
> >
> >
> > > static const struct cnl_ddi_buf_trans *
> > > ehl_get_combo_buf_trans(struct intel_encoder *encoder, int type, int
> > > rate,
> > > int *n_entries)
> > > @@ -1098,6 +1125,34 @@ ehl_get_combo_buf_trans(struct intel_encoder
> > > *encoder, int type, int rate,
> > > }
> > > }
> > >
> > > +static const struct cnl_ddi_buf_trans *
> > > +jsl_get_combo_buf_trans(struct intel_encoder *encoder, int type, int
> > > rate,
> > > + int *n_entries)
> > > +{
> > > + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > > +
> > > + switch (type) {
> > > + case INTEL_OUTPUT_HDMI:
> > > + *n_entries = ARRAY_SIZE(icl_combo_phy_ddi_translations_hdmi);
> > > + return icl_combo_phy_ddi_translations_hdmi;
> > > + case INTEL_OUTPUT_EDP:
> > > + if (dev_priv->vbt.edp.low_vswin
Re: [Intel-gfx] [PATCH v2] drm/i915/edp/jsl: Update vswing table for HBR and HBR2
On Tue, Sep 29, 2020 at 08:20:22PM +, Souza, Jose wrote: > On Tue, 2020-09-29 at 23:02 +0300, Ville Syrjälä wrote: > > On Tue, Sep 29, 2020 at 07:33:45PM +, Souza, Jose wrote: > > > On Tue, 2020-09-29 at 17:41 +0530, Tejas Upadhyay wrote: > > > > JSL has update in vswing table for eDP > > > > > > Would be nice to mention in the commit description why PCH is being used, > > > that would avoid Ville's question. > > > > If the thing has nothing to do PCH then it should not use the PCH type > > for the the check. Instead we should just do the EHL/JSL split. > > In the first version Matt Roper suggested to use PCH to differentiate between > EHL and JSL, Jani also agreed with this solution.This 2 PCHs can only be > associate with EHL and JSL respectively, so no downsides here. The downside is that the code makes no sense on the first glance. It's going to generate a "wtf?" exception in the brain and require me to take a second look to figure what is going on. Exception handling is expensive and shouldn't be needed in cases where it's trivial to make the code 100% obvious. -- 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 v2] drm/i915/edp/jsl: Update vswing table for HBR and HBR2
On Tue, 2020-09-29 at 23:30 +0300, Ville Syrjälä wrote: > On Tue, Sep 29, 2020 at 08:20:22PM +, Souza, Jose wrote: > > On Tue, 2020-09-29 at 23:02 +0300, Ville Syrjälä wrote: > > > On Tue, Sep 29, 2020 at 07:33:45PM +, Souza, Jose wrote: > > > > On Tue, 2020-09-29 at 17:41 +0530, Tejas Upadhyay wrote: > > > > > JSL has update in vswing table for eDP > > > > > > > > Would be nice to mention in the commit description why PCH is being > > > > used, that would avoid Ville's question. > > > > > > If the thing has nothing to do PCH then it should not use the PCH type > > > for the the check. Instead we should just do the EHL/JSL split. > > > > In the first version Matt Roper suggested to use PCH to differentiate > > between EHL and JSL, Jani also agreed with this solution.This 2 PCHs can > > only be > > associate with EHL and JSL respectively, so no downsides here. > > The downside is that the code makes no sense on the first glance. > It's going to generate a "wtf?" exception in the brain and require > me to take a second look to figure what is going on. Exception > handling is expensive and shouldn't be needed in cases where it's > trivial to make the code 100% obvious. > Adding a comment on the top of jsl_get_combo_buf_trans() would help? Otherwise Tejas you will need to rework this then. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/edp/jsl: Update vswing table for HBR and HBR2
On Tue, Sep 29, 2020 at 11:30:22PM +0300, Ville Syrjälä wrote: > On Tue, Sep 29, 2020 at 08:20:22PM +, Souza, Jose wrote: > > On Tue, 2020-09-29 at 23:02 +0300, Ville Syrjälä wrote: > > > On Tue, Sep 29, 2020 at 07:33:45PM +, Souza, Jose wrote: > > > > On Tue, 2020-09-29 at 17:41 +0530, Tejas Upadhyay wrote: > > > > > JSL has update in vswing table for eDP > > > > > > > > Would be nice to mention in the commit description why PCH is being > > > > used, that would avoid Ville's question. > > > > > > If the thing has nothing to do PCH then it should not use the PCH type > > > for the the check. Instead we should just do the EHL/JSL split. > > > > In the first version Matt Roper suggested to use PCH to differentiate > > between EHL and JSL, Jani also agreed with this solution.This 2 PCHs can > > only be > > associate with EHL and JSL respectively, so no downsides here. > > The downside is that the code makes no sense on the first glance. > It's going to generate a "wtf?" exception in the brain and require > me to take a second look to figure what is going on. Exception > handling is expensive and shouldn't be needed in cases where it's > trivial to make the code 100% obvious. The bspec documents EHL and JSL as being the same platform and identical in all programming since they are literally the same display IP; this vswing table is the one and only place where the two are treated in a distinct manner for reasons that lie outside the display controller. If you had to stop and take a closer look at the code here, that's a probably a good thing since in general there should generally never be a difference in the behavior between the two. Adding an additional clarifying comment is probably in order too since this is a very exceptional special case. If we deviate from the bspec's guidance and try to split IS_ELKHARTLAKE and IS_JASPERLAKE across the whole driver, that's going to be a lot more pain to maintain down the road since we'll almost certainly have cases where someone silently leaves one or the other off a condition and gets unexepcted behavior. I could see arguments for using a SUBPLATFORM here like we do for TGL_U vs TGL_Y, but even that seems like overkill if we already have a clear way to distinguish the two cases (PCH pairing) and can just leave a clarifying comment. Matt > > -- > Ville Syrjälä > Intel -- Matt Roper Graphics Software Engineer VTT-OSGC Platform Enablement Intel Corporation (916) 356-2795 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/edp/jsl: Update vswing table for HBR and HBR2
On Tue, Sep 29, 2020 at 02:01:44PM -0700, Matt Roper wrote: > On Tue, Sep 29, 2020 at 11:30:22PM +0300, Ville Syrjälä wrote: > > On Tue, Sep 29, 2020 at 08:20:22PM +, Souza, Jose wrote: > > > On Tue, 2020-09-29 at 23:02 +0300, Ville Syrjälä wrote: > > > > On Tue, Sep 29, 2020 at 07:33:45PM +, Souza, Jose wrote: > > > > > On Tue, 2020-09-29 at 17:41 +0530, Tejas Upadhyay wrote: > > > > > > JSL has update in vswing table for eDP > > > > > > > > > > Would be nice to mention in the commit description why PCH is being > > > > > used, that would avoid Ville's question. > > > > > > > > If the thing has nothing to do PCH then it should not use the PCH type > > > > for the the check. Instead we should just do the EHL/JSL split. > > > > > > In the first version Matt Roper suggested to use PCH to differentiate > > > between EHL and JSL, Jani also agreed with this solution.This 2 PCHs can > > > only be > > > associate with EHL and JSL respectively, so no downsides here. > > > > The downside is that the code makes no sense on the first glance. > > It's going to generate a "wtf?" exception in the brain and require > > me to take a second look to figure what is going on. Exception > > handling is expensive and shouldn't be needed in cases where it's > > trivial to make the code 100% obvious. > > The bspec documents EHL and JSL as being the same platform and identical > in all programming since they are literally the same display IP; this > vswing table is the one and only place where the two are treated in a > distinct manner for reasons that lie outside the display controller. If > you had to stop and take a closer look at the code here, that's a > probably a good thing since in general there should generally never be a > difference in the behavior between the two. Adding an additional > clarifying comment is probably in order too since this is a very > exceptional special case. > > If we deviate from the bspec's guidance and try to split IS_ELKHARTLAKE > and IS_JASPERLAKE across the whole driver, that's going to be a lot more > pain to maintain down the road since we'll almost certainly have cases > where someone silently leaves one or the other off a condition and gets > unexepcted behavior. I could see arguments for using a SUBPLATFORM here > like we do for TGL_U vs TGL_Y, but even that seems like overkill if we > already have a clear way to distinguish the two cases (PCH pairing) and > can just leave a clarifying comment. That fixed PCH pairing is totally undocumented AFAICS. And vswing has nothing to do with the south display, so the wtf will still happen. Comment or no comment. -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] drm/i915/vbt: Fix backlight parsing for VBT 234+
Child min_brightness is obsolete from VBT 234+, instead the new
min_brightness field in the main structure should be used.
This new field is 16 bits wide, so backlight_precision_bits is needed
to check if value needs to be scaled down but it is only available in
VBT 236+ so working around it by using the also new backlight_level
in the main struct.
BSpec: 20149
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_bios.c | 23 ++-
drivers/gpu/drm/i915/display/intel_vbt_defs.h | 10 +++-
2 files changed, 31 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
b/drivers/gpu/drm/i915/display/intel_bios.c
index 4716484af62d..fa7a93f118f4 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -459,7 +459,28 @@ parse_lfp_backlight(struct drm_i915_private *dev_priv,
dev_priv->vbt.backlight.pwm_freq_hz = entry->pwm_freq_hz;
dev_priv->vbt.backlight.active_low_pwm = entry->active_low_pwm;
- dev_priv->vbt.backlight.min_brightness = entry->min_brightness;
+
+ if (bdb->version >= 234) {
+ u16 level =
backlight_data->backlight_min_level[panel_type].level;
+ bool scale = false;
+
+ if (bdb->version >= 236)
+ scale =
backlight_data->backlight_precision_bits[panel_type] == 16;
+ else
+ scale =
backlight_data->backlight_level[panel_type].level > 255;
+
+ if (scale)
+ level = level / 255;
+
+ if (level > 255) {
+ drm_warn(&dev_priv->drm, "Backlight min level > 255\n");
+ level = 255;
+ }
+ dev_priv->vbt.backlight.min_brightness = level;
+ } else {
+ dev_priv->vbt.backlight.min_brightness = entry->min_brightness;
+ }
+
drm_dbg_kms(&dev_priv->drm,
"VBT backlight PWM modulation frequency %u Hz, "
"active %s, min brightness %u, level %u, controller %u\n",
diff --git a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
index 54bcc6a6947c..12ec4c0781ce 100644
--- a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
+++ b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
@@ -782,7 +782,7 @@ struct lfp_backlight_data_entry {
u8 active_low_pwm:1;
u8 obsolete1:5;
u16 pwm_freq_hz;
- u8 min_brightness;
+ u8 min_brightness; /* Obsolete from 234+ */
u8 obsolete2;
u8 obsolete3;
} __packed;
@@ -792,11 +792,19 @@ struct lfp_backlight_control_method {
u8 controller:4;
} __packed;
+struct lfp_backlight_level {
+ u32 level : 16;
+ u32 reserved : 16;
+} __packed;
+
struct bdb_lfp_backlight_data {
u8 entry_size;
struct lfp_backlight_data_entry data[16];
u8 level[16];
struct lfp_backlight_control_method backlight_control[16];
+ struct lfp_backlight_level backlight_level[16]; /* 234+ */
+ struct lfp_backlight_level backlight_min_level[16]; /* 234+ */
+ u8 backlight_precision_bits[16];
/* 236+ */
} __packed;
/*
--
2.28.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/i915/vbt: Add VRR VBT toggle
This will be used in future but already adding to VBT so we are
updated with VBT changes.
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_vbt_defs.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
index 12ec4c0781ce..87f403424719 100644
--- a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
+++ b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
@@ -835,6 +835,7 @@ struct bdb_lfp_power {
u16 lace_enabled_status;
struct agressiveness_profile_entry aggressivenes[16];
u16 hobl; /* 232+ */
+ u16 vrr_feature_enabled; /* 233+ */
} __packed;
/*
--
2.28.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/i915/vbt: Update the version and expected size of BDB_GENERAL_DEFINITIONS map
This will remove the "Expected child device config size for VBT
version 235 not known" debug message seen in TGL, although this is not
fixing anything it good to keep our VBT parser updated.
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_bios.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
b/drivers/gpu/drm/i915/display/intel_bios.c
index fa7a93f118f4..053c90abb870 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -1910,7 +1910,7 @@ parse_general_definitions(struct drm_i915_private
*dev_priv,
expected_size = 37;
} else if (bdb->version <= 215) {
expected_size = 38;
- } else if (bdb->version <= 229) {
+ } else if (bdb->version <= 237) {
expected_size = 39;
} else {
expected_size = sizeof(*child);
--
2.28.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/edp/jsl: Update vswing table for HBR and HBR2
On Wed, Sep 30, 2020 at 12:11:48AM +0300, Ville Syrjälä wrote: > On Tue, Sep 29, 2020 at 02:01:44PM -0700, Matt Roper wrote: > > On Tue, Sep 29, 2020 at 11:30:22PM +0300, Ville Syrjälä wrote: > > > On Tue, Sep 29, 2020 at 08:20:22PM +, Souza, Jose wrote: > > > > On Tue, 2020-09-29 at 23:02 +0300, Ville Syrjälä wrote: > > > > > On Tue, Sep 29, 2020 at 07:33:45PM +, Souza, Jose wrote: > > > > > > On Tue, 2020-09-29 at 17:41 +0530, Tejas Upadhyay wrote: > > > > > > > JSL has update in vswing table for eDP > > > > > > > > > > > > Would be nice to mention in the commit description why PCH is being > > > > > > used, that would avoid Ville's question. > > > > > > > > > > If the thing has nothing to do PCH then it should not use the PCH type > > > > > for the the check. Instead we should just do the EHL/JSL split. > > > > > > > > In the first version Matt Roper suggested to use PCH to differentiate > > > > between EHL and JSL, Jani also agreed with this solution.This 2 PCHs > > > > can only be > > > > associate with EHL and JSL respectively, so no downsides here. > > > > > > The downside is that the code makes no sense on the first glance. > > > It's going to generate a "wtf?" exception in the brain and require > > > me to take a second look to figure what is going on. Exception > > > handling is expensive and shouldn't be needed in cases where it's > > > trivial to make the code 100% obvious. > > > > The bspec documents EHL and JSL as being the same platform and identical > > in all programming since they are literally the same display IP; this > > vswing table is the one and only place where the two are treated in a > > distinct manner for reasons that lie outside the display controller. If > > you had to stop and take a closer look at the code here, that's a > > probably a good thing since in general there should generally never be a > > difference in the behavior between the two. Adding an additional > > clarifying comment is probably in order too since this is a very > > exceptional special case. > > > > If we deviate from the bspec's guidance and try to split IS_ELKHARTLAKE > > and IS_JASPERLAKE across the whole driver, that's going to be a lot more > > pain to maintain down the road since we'll almost certainly have cases > > where someone silently leaves one or the other off a condition and gets > > unexepcted behavior. I could see arguments for using a SUBPLATFORM here > > like we do for TGL_U vs TGL_Y, but even that seems like overkill if we > > already have a clear way to distinguish the two cases (PCH pairing) and > > can just leave a clarifying comment. > > That fixed PCH pairing is totally undocumented AFAICS. And vswing has > nothing to do with the south display, so the wtf will still happen. > Comment or no comment. Oh and JSP does not show up in bspec even once. MCC appears exactly once where it talks about the differences between MCC and ICL-N PCH (which I guess is the same as JSP?). Furthermore the spec never really talks about EHL except in very select places. So the IS_ELKHARTLAKE is already totally confusing and IMO more likely to cause maintenance problems than the split. Making it IS_JSL||IS_EHL at least gives the reader some hint as to where they should look in the spec. Another argument why the split is fine is CFL/CML. Those are more or less exactly in the same boat as EHL. Ie. only really mentioned in the "configurations" section. Beyond that only KBL is ever really mentioned. And yet we have separate IS_FOOs for all of them, and apparently no one had any objections to that situation. tldr;we have an established way to handle these things, so IMO lets just follow it and stop adding special cases. -- 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 v2] vfio/pci: Refine Intel IGD OpRegion support
On Wed, 30 Sep 2020 00:10:38 +0800
Fred Gao wrote:
> Bypass the IGD initialization for Intel's dgfx devices with own expansion
> ROM and the host/LPC bridge config space are no longer accessed.
>
> v2: simply test if discrete or integrated gfx device
> with root bus. (Alex Williamson)
>
> Cc: Zhenyu Wang
> Cc: Xiong Zhang
> Cc: Hang Yuan
> Cc: Stuart Summers
> Signed-off-by: Lucas De Marchi
> Signed-off-by: Fred Gao
> ---
> drivers/vfio/pci/vfio_pci.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
> index f634c81998bb..9258ccfadb79 100644
> --- a/drivers/vfio/pci/vfio_pci.c
> +++ b/drivers/vfio/pci/vfio_pci.c
> @@ -336,10 +336,11 @@ static int vfio_pci_enable(struct vfio_pci_device *vdev)
> if (!vfio_vga_disabled() && vfio_pci_is_vga(pdev))
> vdev->has_vga = true;
>
> -
> + /* Intel's dgfx should not appear on root bus */
> if (vfio_pci_is_vga(pdev) &&
> pdev->vendor == PCI_VENDOR_ID_INTEL &&
> - IS_ENABLED(CONFIG_VFIO_PCI_IGD)) {
> + IS_ENABLED(CONFIG_VFIO_PCI_IGD) &&
> + pci_is_root_bus(pdev->bus)) {
> ret = vfio_pci_igd_init(vdev);
> if (ret) {
> pci_warn(pdev, "Failed to setup Intel IGD regions\n");
The comment seems rather misplaced here, it only refers to one switch,
several lines down within the set of conditions, but looks like a
header for the entire branch. I think it would be better to either
expand the comment to describe the entire branch, including the
exclusion, or try to fit the exclusion comment alongside the test, ie.
/*
* Intel IGD requires quirks to support guest drivers. IGD is
* identified as an Intel VGA device on the root bus.
*/
Or
pci_is_root_bus(pdev->bus)) { /* Skip discrete gfx */
The commit title should really include something about excluding
discrete graphics from IGD quirks as well. It might help downstreams
backport it for support.
It also occurs to me that relying on the physical topology only works
at the bare metal level. We could for example assign a dgfx device at
address 00:02.0 in the guest. Nested assignment of that device would
trigger calling vfio_pci_igd_init() and fail. I see igd has a PCIe
capability type of PCI_EXP_TYPE_RC_END and I'd expect dgfx to have a
type of PCI_EXP_TYPE_LEG_END, but unfortunately QEMU does too good of a
job emulating the PCIe capability and will mangle these to suit the
guest topology. I wonder then if our best course is to make the above
branch more lenient, for example pruning the failure paths such that we
could use -ENODEV as a non-terminal error like is done for the NVLink
quirks below this code block. Failure to find an OpRegion might be our
differentiation, where on bare metal we might have both igd and dgfx,
so we'd need the root bus test, but assigning dgfx to a VM and placing
it on the VM root bus wouldn't generate an OpRegion, so both levels
would take the dgfx path. IGD placed on a non-root bus in the guest
could probably just be considered a misconfiguration by the user...
Thanks,
Alex
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915/vbt: Fix backlight parsing for VBT 234+
== Series Details ==
Series: series starting with [1/3] drm/i915/vbt: Fix backlight parsing for VBT
234+
URL : https://patchwork.freedesktop.org/series/82227/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9075 -> Patchwork_18592
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18592/index.html
Known issues
Here are the changes found in Patchwork_18592 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@active:
- fi-kbl-7500u: [PASS][1] -> [DMESG-FAIL][2] ([i915#666])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9075/fi-kbl-7500u/igt@i915_selftest@l...@active.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18592/fi-kbl-7500u/igt@i915_selftest@l...@active.html
Possible fixes
* igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1:
- fi-icl-u2: [DMESG-WARN][3] ([i915#1982]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9075/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18592/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
* igt@vgem_basic@unload:
- fi-skl-guc: [DMESG-WARN][5] ([i915#2203]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9075/fi-skl-guc/igt@vgem_ba...@unload.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18592/fi-skl-guc/igt@vgem_ba...@unload.html
Warnings
* igt@i915_pm_rpm@basic-rte:
- fi-kbl-guc: [SKIP][7] ([fdo#109271]) -> [DMESG-FAIL][8]
([i915#2203])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9075/fi-kbl-guc/igt@i915_pm_...@basic-rte.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18592/fi-kbl-guc/igt@i915_pm_...@basic-rte.html
* igt@kms_flip@basic-flip-vs-wf_vblank@a-dp1:
- fi-kbl-x1275: [DMESG-WARN][9] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][10] ([i915#62] / [i915#92]) +1 similar issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9075/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-wf_vbl...@a-dp1.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18592/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-wf_vbl...@a-dp1.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-kbl-x1275: [DMESG-WARN][11] ([i915#1982] / [i915#62] / [i915#92]
/ [i915#95]) -> [DMESG-WARN][12] ([i915#62] / [i915#92])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9075/fi-kbl-x1275/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18592/fi-kbl-x1275/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
* igt@prime_vgem@basic-fence-flip:
- fi-kbl-x1275: [DMESG-WARN][13] ([i915#62] / [i915#92]) ->
[DMESG-WARN][14] ([i915#62] / [i915#92] / [i915#95]) +1 similar issue
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9075/fi-kbl-x1275/igt@prime_v...@basic-fence-flip.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18592/fi-kbl-x1275/igt@prime_v...@basic-fence-flip.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2203]: https://gitlab.freedesktop.org/drm/intel/issues/2203
[i915#2411]: https://gitlab.freedesktop.org/drm/intel/issues/2411
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#666]: https://gitlab.freedesktop.org/drm/intel/issues/666
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
[i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
[k.org#205379]: https://bugzilla.kernel.org/show_bug.cgi?id=205379
Participating hosts (46 -> 39)
--
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600 fi-byt-clapper fi-bdw-samus
Build changes
-
* Linux: CI_DRM_9075 -> Patchwork_18592
CI-20190529: 20190529
CI_DRM_9075: fd24361b2b76956b5c056bc430a4c77edecb7744 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5792: cbaf441899f3b4f36cca5996aa6a69e7399b2dbd @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_18592: 0e24be1e2fde7c67bf90a936562f768c3b3be39b @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
0e24be1e2fde drm/i915/vbt: Add VRR VBT toggle
c90d3e04c3af drm/i915/vbt: Update the version and expected size of
BDB_GENERAL_DEFINITIONS map
37a5c44eabf9 drm/i915/vbt: Fix backlight parsing for VBT 234+
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18592/index.html
___
I
[Intel-gfx] [PATCH v2 1/3] drm/i915/vbt: Fix backlight parsing for VBT 234+
Child min_brightness is obsolete from VBT 234+, instead the new
min_brightness field in the main structure should be used.
This new field is 16 bits wide, so backlight_precision_bits is needed
to check if value needs to be scaled down but it is only available in
VBT 236+ so working around it by using the also new backlight_level
in the main struct.
v2:
- missed that backlight_data->level is also obsolete
BSpec: 20149
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_bios.c | 30 +--
drivers/gpu/drm/i915/display/intel_vbt_defs.h | 12 ++--
2 files changed, 38 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
b/drivers/gpu/drm/i915/display/intel_bios.c
index 4716484af62d..58e5657a77bb 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -425,6 +425,7 @@ parse_lfp_backlight(struct drm_i915_private *dev_priv,
const struct bdb_lfp_backlight_data *backlight_data;
const struct lfp_backlight_data_entry *entry;
int panel_type = dev_priv->vbt.panel_type;
+ u16 level;
backlight_data = find_section(bdb, BDB_LVDS_BACKLIGHT);
if (!backlight_data)
@@ -459,14 +460,39 @@ parse_lfp_backlight(struct drm_i915_private *dev_priv,
dev_priv->vbt.backlight.pwm_freq_hz = entry->pwm_freq_hz;
dev_priv->vbt.backlight.active_low_pwm = entry->active_low_pwm;
- dev_priv->vbt.backlight.min_brightness = entry->min_brightness;
+
+ if (bdb->version >= 234) {
+ bool scale = false;
+ u16 min_level;
+
+ level = backlight_data->backlight_level[panel_type].level;
+ min_level =
backlight_data->backlight_min_level[panel_type].level;
+
+ if (bdb->version >= 236)
+ scale =
backlight_data->backlight_precision_bits[panel_type] == 16;
+ else
+ scale = level > 255;
+
+ if (scale)
+ min_level = min_level / 255;
+
+ if (min_level > 255) {
+ drm_warn(&dev_priv->drm, "Backlight min level > 255\n");
+ level = 255;
+ }
+ dev_priv->vbt.backlight.min_brightness = min_level;
+ } else {
+ level = backlight_data->level[panel_type];
+ dev_priv->vbt.backlight.min_brightness = entry->min_brightness;
+ }
+
drm_dbg_kms(&dev_priv->drm,
"VBT backlight PWM modulation frequency %u Hz, "
"active %s, min brightness %u, level %u, controller %u\n",
dev_priv->vbt.backlight.pwm_freq_hz,
dev_priv->vbt.backlight.active_low_pwm ? "low" : "high",
dev_priv->vbt.backlight.min_brightness,
- backlight_data->level[panel_type],
+ level,
dev_priv->vbt.backlight.controller);
}
diff --git a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
index 54bcc6a6947c..b4742c4fde97 100644
--- a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
+++ b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
@@ -782,7 +782,7 @@ struct lfp_backlight_data_entry {
u8 active_low_pwm:1;
u8 obsolete1:5;
u16 pwm_freq_hz;
- u8 min_brightness;
+ u8 min_brightness; /* Obsolete from 234+ */
u8 obsolete2;
u8 obsolete3;
} __packed;
@@ -792,11 +792,19 @@ struct lfp_backlight_control_method {
u8 controller:4;
} __packed;
+struct lfp_backlight_level {
+ u32 level : 16;
+ u32 reserved : 16;
+} __packed;
+
struct bdb_lfp_backlight_data {
u8 entry_size;
struct lfp_backlight_data_entry data[16];
- u8 level[16];
+ u8 level[16]; /* Obsolete from 234+ */
struct lfp_backlight_control_method backlight_control[16];
+ struct lfp_backlight_level backlight_level[16]; /* 234+ */
+ struct lfp_backlight_level backlight_min_level[16]; /* 234+ */
+ u8 backlight_precision_bits[16];
/* 236+ */
} __packed;
/*
--
2.28.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/3] drm/i915/vbt: Update the version and expected size of BDB_GENERAL_DEFINITIONS map
This will remove the "Expected child device config size for VBT
version 235 not known" debug message seen in TGL, although this is not
fixing anything it good to keep our VBT parser updated.
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_bios.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
b/drivers/gpu/drm/i915/display/intel_bios.c
index 58e5657a77bb..6ce0b848e342 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -1915,7 +1915,7 @@ parse_general_definitions(struct drm_i915_private
*dev_priv,
expected_size = 37;
} else if (bdb->version <= 215) {
expected_size = 38;
- } else if (bdb->version <= 229) {
+ } else if (bdb->version <= 237) {
expected_size = 39;
} else {
expected_size = sizeof(*child);
--
2.28.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 3/3] drm/i915/vbt: Add VRR VBT toggle
This will be used in future but already adding to VBT so we are
updated with VBT changes.
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_vbt_defs.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
index b4742c4fde97..46f3f4804c9e 100644
--- a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
+++ b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
@@ -835,6 +835,7 @@ struct bdb_lfp_power {
u16 lace_enabled_status;
struct agressiveness_profile_entry aggressivenes[16];
u16 hobl; /* 232+ */
+ u16 vrr_feature_enabled; /* 233+ */
} __packed;
/*
--
2.28.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/3] drm/i915/vbt: Fix backlight parsing for VBT 234+
== Series Details == Series: series starting with [v2,1/3] drm/i915/vbt: Fix backlight parsing for VBT 234+ URL : https://patchwork.freedesktop.org/series/82229/ State : success == Summary == CI Bug Log - changes from CI_DRM_9075 -> Patchwork_18593 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18593/index.html Known issues Here are the changes found in Patchwork_18593 that come from known issues: ### IGT changes ### Issues hit * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - fi-icl-u2: [PASS][1] -> [DMESG-WARN][2] ([i915#1982]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9075/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18593/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html Possible fixes * igt@kms_busy@basic@flip: - fi-kbl-x1275: [DMESG-WARN][3] ([i915#62] / [i915#92] / [i915#95]) -> [PASS][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9075/fi-kbl-x1275/igt@kms_busy@ba...@flip.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18593/fi-kbl-x1275/igt@kms_busy@ba...@flip.html * igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1: - fi-icl-u2: [DMESG-WARN][5] ([i915#1982]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9075/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18593/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html Warnings * igt@kms_flip@basic-flip-vs-wf_vblank@a-dp1: - fi-kbl-x1275: [DMESG-WARN][7] ([i915#62] / [i915#92] / [i915#95]) -> [DMESG-WARN][8] ([i915#62] / [i915#92]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9075/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-wf_vbl...@a-dp1.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18593/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-wf_vbl...@a-dp1.html * igt@kms_force_connector_basic@prune-stale-modes: - fi-kbl-x1275: [DMESG-WARN][9] ([i915#62] / [i915#92]) -> [DMESG-WARN][10] ([i915#62] / [i915#92] / [i915#95]) +4 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9075/fi-kbl-x1275/igt@kms_force_connector_ba...@prune-stale-modes.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18593/fi-kbl-x1275/igt@kms_force_connector_ba...@prune-stale-modes.html * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: - fi-kbl-x1275: [DMESG-WARN][11] ([i915#1982] / [i915#62] / [i915#92] / [i915#95]) -> [DMESG-WARN][12] ([i915#62] / [i915#92] / [i915#95]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9075/fi-kbl-x1275/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18593/fi-kbl-x1275/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982 [i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62 [i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92 [i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95 Participating hosts (46 -> 37) -- Missing(9): fi-cml-u2 fi-ilk-m540 fi-tgl-dsi fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper fi-bdw-samus Build changes - * Linux: CI_DRM_9075 -> Patchwork_18593 CI-20190529: 20190529 CI_DRM_9075: fd24361b2b76956b5c056bc430a4c77edecb7744 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5792: cbaf441899f3b4f36cca5996aa6a69e7399b2dbd @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_18593: b88dce76e2adb69efa0ef313cf18515a15821d21 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == b88dce76e2ad drm/i915/vbt: Add VRR VBT toggle 67fc6dee0c3a drm/i915/vbt: Update the version and expected size of BDB_GENERAL_DEFINITIONS map c041999f76f1 drm/i915/vbt: Fix backlight parsing for VBT 234+ == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18593/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 00/11] drm/i915: Plumb crtc state to link training code
From: Ville Syrjälä
Another attempt at plumbing the crtc state to the depths of
the link training code. This time I tried to preserve the
PHY test stuff in a somewhat working condition.
The DDI buf trans stuff also started to bug me again so had
to toss in a few cleanups in that area. Still pretty messy,
but with a bit more regular structure we could perhaps toss
in a few vfuncs to get rid of some if ladders at least.
Not entirely sure yet...
Ville Syrjälä (11):
drm/i915: s/pre_empemph/preemph/
drm/i915: s/old_crtc_state/crtc_state/
drm/i915: Make intel_dp_process_phy_request() static
drm/i915: Shove the PHY test into the hotplug work
drm/i915: Split ICL combo PHY buf trans per output type
drm/i915: Split ICL MG PHY buf trans per output type
drm/i915: Split EHL combo PHY buf trans per output type
drm/i915: Split TGL combo PHY buf trans per output type
drm/i915: Split TGL DKL PHY buf trans per output type
drm/i915: Plumb crtc_state to link training
drm/i915: Eliminate intel_dp.regs.dp_tp_{ctl,status}
drivers/gpu/drm/i915/display/intel_ddi.c | 677 ++
drivers/gpu/drm/i915/display/intel_ddi.h | 11 +-
.../drm/i915/display/intel_display_types.h| 25 +-
drivers/gpu/drm/i915/display/intel_dp.c | 289 ++--
drivers/gpu/drm/i915/display/intel_dp.h | 11 +-
.../drm/i915/display/intel_dp_link_training.c | 102 +--
.../drm/i915/display/intel_dp_link_training.h | 8 +-
drivers/gpu/drm/i915/display/intel_dp_mst.c | 24 +-
drivers/gpu/drm/i915/display/intel_dpio_phy.c | 23 +-
drivers/gpu/drm/i915/display/intel_dpio_phy.h | 2 +
drivers/gpu/drm/i915/display/intel_hdmi.c | 7 +-
11 files changed, 718 insertions(+), 461 deletions(-)
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 03/11] drm/i915: Make intel_dp_process_phy_request() static
From: Ville Syrjälä
intel_dp_process_phy_request() has no business being externally
visible. Make it static.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp.c | 2 +-
drivers/gpu/drm/i915/display/intel_dp.h | 1 -
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 3586d79f5599..5c673080ecb1 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5562,7 +5562,7 @@ intel_dp_autotest_phy_ddi_enable(struct intel_dp
*intel_dp, uint8_t lane_cnt)
trans_ddi_func_ctl_value);
}
-void intel_dp_process_phy_request(struct intel_dp *intel_dp)
+static void intel_dp_process_phy_request(struct intel_dp *intel_dp)
{
struct drm_dp_phy_test_params *data =
&intel_dp->compliance.test_data.phytest;
diff --git a/drivers/gpu/drm/i915/display/intel_dp.h
b/drivers/gpu/drm/i915/display/intel_dp.h
index a9580d1df35b..60f44f41fd08 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.h
+++ b/drivers/gpu/drm/i915/display/intel_dp.h
@@ -123,7 +123,6 @@ void intel_read_dp_sdp(struct intel_encoder *encoder,
struct intel_crtc_state *crtc_state,
unsigned int type);
bool intel_digital_port_connected(struct intel_encoder *encoder);
-void intel_dp_process_phy_request(struct intel_dp *intel_dp);
static inline unsigned int intel_dp_unused_lane_mask(int lane_count)
{
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 08/11] drm/i915: Split TGL combo PHY buf trans per output type
From: Ville Syrjälä
Make the mess inside the buf trans funcs a bit more manageable by
splitting along the lines of output type.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 83 ++--
1 file changed, 49 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index da7090803ea1..fea06c1b09d9 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -1157,51 +1157,66 @@ ehl_get_combo_buf_trans(struct intel_encoder *encoder,
int type, int rate,
}
static const struct cnl_ddi_buf_trans *
-tgl_get_combo_buf_trans(struct intel_encoder *encoder, int type, int rate,
- int *n_entries)
+tgl_get_combo_buf_trans_hdmi(struct intel_encoder *encoder, int type, int rate,
+int *n_entries)
+{
+ *n_entries = ARRAY_SIZE(icl_combo_phy_ddi_translations_hdmi);
+ return icl_combo_phy_ddi_translations_hdmi;
+}
+
+static const struct cnl_ddi_buf_trans *
+tgl_get_combo_buf_trans_dp(struct intel_encoder *encoder, int type, int rate,
+ int *n_entries)
{
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
- switch (type) {
- case INTEL_OUTPUT_HDMI:
- *n_entries = ARRAY_SIZE(icl_combo_phy_ddi_translations_hdmi);
- return icl_combo_phy_ddi_translations_hdmi;
- case INTEL_OUTPUT_EDP:
- if (dev_priv->vbt.edp.hobl) {
- struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
-
- if (!intel_dp->hobl_failed && rate <= 54) {
- /* Same table applies to TGL, RKL and DG1 */
- *n_entries =
ARRAY_SIZE(tgl_combo_phy_ddi_translations_edp_hbr2_hobl);
- return
tgl_combo_phy_ddi_translations_edp_hbr2_hobl;
- }
- }
-
- if (rate > 54) {
- *n_entries =
ARRAY_SIZE(icl_combo_phy_ddi_translations_edp_hbr3);
- return icl_combo_phy_ddi_translations_edp_hbr3;
- } else if (dev_priv->vbt.edp.low_vswing) {
- *n_entries =
ARRAY_SIZE(icl_combo_phy_ddi_translations_edp_hbr2);
- return icl_combo_phy_ddi_translations_edp_hbr2;
- }
- /* fall through */
- default:
- /* All combo DP and eDP ports that do not support low_vswing */
- if (rate > 27) {
- if (IS_TGL_U(dev_priv) || IS_TGL_Y(dev_priv)) {
- *n_entries =
ARRAY_SIZE(tgl_uy_combo_phy_ddi_translations_dp_hbr2);
- return
tgl_uy_combo_phy_ddi_translations_dp_hbr2;
- }
-
+ if (rate > 27) {
+ if (IS_TGL_U(dev_priv) || IS_TGL_Y(dev_priv)) {
+ *n_entries =
ARRAY_SIZE(tgl_uy_combo_phy_ddi_translations_dp_hbr2);
+ return tgl_uy_combo_phy_ddi_translations_dp_hbr2;
+ } else {
*n_entries =
ARRAY_SIZE(tgl_combo_phy_ddi_translations_dp_hbr2);
return tgl_combo_phy_ddi_translations_dp_hbr2;
}
-
+ } else {
*n_entries = ARRAY_SIZE(tgl_combo_phy_ddi_translations_dp_hbr);
return tgl_combo_phy_ddi_translations_dp_hbr;
}
}
+static const struct cnl_ddi_buf_trans *
+tgl_get_combo_buf_trans_edp(struct intel_encoder *encoder, int type, int rate,
+ int *n_entries)
+{
+ struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+ struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+
+ if (rate > 54) {
+ *n_entries =
ARRAY_SIZE(icl_combo_phy_ddi_translations_edp_hbr3);
+ return icl_combo_phy_ddi_translations_edp_hbr3;
+ } else if (dev_priv->vbt.edp.hobl && !intel_dp->hobl_failed) {
+ *n_entries =
ARRAY_SIZE(tgl_combo_phy_ddi_translations_edp_hbr2_hobl);
+ return tgl_combo_phy_ddi_translations_edp_hbr2_hobl;
+ } else if (dev_priv->vbt.edp.low_vswing) {
+ *n_entries =
ARRAY_SIZE(icl_combo_phy_ddi_translations_edp_hbr2);
+ return icl_combo_phy_ddi_translations_edp_hbr2;
+ }
+
+ return tgl_get_combo_buf_trans_dp(encoder, type, rate, n_entries);
+}
+
+static const struct cnl_ddi_buf_trans *
+tgl_get_combo_buf_trans(struct intel_encoder *encoder, int type, int rate,
+ int *n_entries)
+{
+ if (type == INTEL_OUTPUT_HDMI)
+ return tgl_get_combo_buf_trans_hdmi(encoder, type, rate,
n_entries);
+ else if (type == INTEL_OUTPUT_EDP)
+ return tgl_get_combo_buf_trans_edp(encoder, type, rate,
n_entries);
+ else
+ return tgl_
[Intel-gfx] [PATCH v2 01/11] drm/i915: s/pre_empemph/preemph/
From: Ville Syrjälä
I managed to fumble some functions names. Fix them.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 54a4b81ea3ff..ff96540c8612 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4167,12 +4167,12 @@ static u8 intel_dp_voltage_max_3(struct intel_dp
*intel_dp)
return DP_TRAIN_VOLTAGE_SWING_LEVEL_3;
}
-static u8 intel_dp_pre_empemph_max_2(struct intel_dp *intel_dp)
+static u8 intel_dp_preemph_max_2(struct intel_dp *intel_dp)
{
return DP_TRAIN_PRE_EMPH_LEVEL_2;
}
-static u8 intel_dp_pre_empemph_max_3(struct intel_dp *intel_dp)
+static u8 intel_dp_preemph_max_3(struct intel_dp *intel_dp)
{
return DP_TRAIN_PRE_EMPH_LEVEL_3;
}
@@ -7953,10 +7953,10 @@ bool intel_dp_init(struct drm_i915_private *dev_priv,
if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv) ||
(HAS_PCH_SPLIT(dev_priv) && port != PORT_A)) {
- dig_port->dp.preemph_max = intel_dp_pre_empemph_max_3;
+ dig_port->dp.preemph_max = intel_dp_preemph_max_3;
dig_port->dp.voltage_max = intel_dp_voltage_max_3;
} else {
- dig_port->dp.preemph_max = intel_dp_pre_empemph_max_2;
+ dig_port->dp.preemph_max = intel_dp_preemph_max_2;
dig_port->dp.voltage_max = intel_dp_voltage_max_2;
}
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 07/11] drm/i915: Split EHL combo PHY buf trans per output type
From: Ville Syrjälä
Make the mess inside the buf trans funcs a bit more manageable by
splitting along the lines of output type.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 63 +++-
1 file changed, 41 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index e3c6d4942b68..da7090803ea1 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -1109,32 +1109,51 @@ icl_get_mg_buf_trans(struct intel_encoder *encoder, int
type, int rate,
return icl_get_mg_buf_trans_dp(encoder, type, rate, n_entries);
}
+static const struct cnl_ddi_buf_trans *
+ehl_get_combo_buf_trans_hdmi(struct intel_encoder *encoder, int type, int rate,
+int *n_entries)
+{
+ *n_entries = ARRAY_SIZE(icl_combo_phy_ddi_translations_hdmi);
+ return icl_combo_phy_ddi_translations_hdmi;
+}
+
+static const struct cnl_ddi_buf_trans *
+ehl_get_combo_buf_trans_dp(struct intel_encoder *encoder, int type, int rate,
+ int *n_entries)
+{
+ *n_entries = ARRAY_SIZE(ehl_combo_phy_ddi_translations_dp);
+ return ehl_combo_phy_ddi_translations_dp;
+}
+
+static const struct cnl_ddi_buf_trans *
+ehl_get_combo_buf_trans_edp(struct intel_encoder *encoder, int type, int rate,
+ int *n_entries)
+{
+ struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+
+ if (dev_priv->vbt.edp.low_vswing) {
+ if (rate > 54) {
+ *n_entries =
ARRAY_SIZE(icl_combo_phy_ddi_translations_edp_hbr3);
+ return icl_combo_phy_ddi_translations_edp_hbr3;
+ } else {
+ *n_entries =
ARRAY_SIZE(icl_combo_phy_ddi_translations_edp_hbr2);
+ return icl_combo_phy_ddi_translations_edp_hbr2;
+ }
+ }
+
+ return ehl_get_combo_buf_trans_dp(encoder, type, rate, n_entries);
+}
+
static const struct cnl_ddi_buf_trans *
ehl_get_combo_buf_trans(struct intel_encoder *encoder, int type, int rate,
int *n_entries)
{
- struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
-
- switch (type) {
- case INTEL_OUTPUT_HDMI:
- *n_entries = ARRAY_SIZE(icl_combo_phy_ddi_translations_hdmi);
- return icl_combo_phy_ddi_translations_hdmi;
- case INTEL_OUTPUT_EDP:
- if (dev_priv->vbt.edp.low_vswing) {
- if (rate > 54) {
- *n_entries =
ARRAY_SIZE(icl_combo_phy_ddi_translations_edp_hbr3);
- return icl_combo_phy_ddi_translations_edp_hbr3;
- } else {
- *n_entries =
ARRAY_SIZE(icl_combo_phy_ddi_translations_edp_hbr2);
- return icl_combo_phy_ddi_translations_edp_hbr2;
- }
- }
- /* fall through */
- default:
- /* All combo DP and eDP ports that do not support low_vswing */
- *n_entries = ARRAY_SIZE(ehl_combo_phy_ddi_translations_dp);
- return ehl_combo_phy_ddi_translations_dp;
- }
+ if (type == INTEL_OUTPUT_HDMI)
+ return ehl_get_combo_buf_trans_hdmi(encoder, type, rate,
n_entries);
+ else if (type == INTEL_OUTPUT_EDP)
+ return ehl_get_combo_buf_trans_edp(encoder, type, rate,
n_entries);
+ else
+ return ehl_get_combo_buf_trans_dp(encoder, type, rate,
n_entries);
}
static const struct cnl_ddi_buf_trans *
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 04/11] drm/i915: Shove the PHY test into the hotplug work
From: Ville Syrjälä
Doing nay kind modeset stuff from the short hpd handler is
verboten. The ad-hoc PHY test modeset code violates this. And
by calling various link training related functions it's now
blocking further work to plumb the crtc state down into the
link training code.
Let's hack around that by pushing the PHY test stuff into the
hotplug work where it's less of a problem. Still not great but
at least acceptable. We take a few pages from the link retraining
handbook to handle the locking and whatnot.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp.c | 154
1 file changed, 128 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 5c673080ecb1..6718e01909cd 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5424,25 +5424,6 @@ static u8 intel_dp_autotest_edid(struct intel_dp
*intel_dp)
return test_result;
}
-static u8 intel_dp_prepare_phytest(struct intel_dp *intel_dp)
-{
- struct drm_dp_phy_test_params *data =
- &intel_dp->compliance.test_data.phytest;
-
- if (drm_dp_get_phy_test_pattern(&intel_dp->aux, data)) {
- DRM_DEBUG_KMS("DP Phy Test pattern AUX read failure\n");
- return DP_TEST_NAK;
- }
-
- /*
-* link_mst is set to false to avoid executing mst related code
-* during compliance testing.
-*/
- intel_dp->link_mst = false;
-
- return DP_TEST_ACK;
-}
-
static void intel_dp_phy_pattern_update(struct intel_dp *intel_dp)
{
struct drm_i915_private *dev_priv =
@@ -5590,15 +5571,18 @@ static void intel_dp_process_phy_request(struct
intel_dp *intel_dp)
static u8 intel_dp_autotest_phy_pattern(struct intel_dp *intel_dp)
{
- u8 test_result;
+ struct drm_dp_phy_test_params *data =
+ &intel_dp->compliance.test_data.phytest;
- test_result = intel_dp_prepare_phytest(intel_dp);
- if (test_result != DP_TEST_ACK)
- DRM_ERROR("Phy test preparation failed\n");
+ if (drm_dp_get_phy_test_pattern(&intel_dp->aux, data)) {
+ DRM_DEBUG_KMS("DP Phy Test pattern AUX read failure\n");
+ return DP_TEST_NAK;
+ }
- intel_dp_process_phy_request(intel_dp);
+ /* Set test active flag here so userspace doesn't interrupt things */
+ intel_dp->compliance.test_active = true;
- return test_result;
+ return DP_TEST_ACK;
}
static void intel_dp_handle_test_request(struct intel_dp *intel_dp)
@@ -5887,6 +5871,104 @@ int intel_dp_retrain_link(struct intel_encoder *encoder,
return 0;
}
+static int intel_dp_prep_phy_test(struct intel_dp *intel_dp,
+ struct drm_modeset_acquire_ctx *ctx,
+ u32 *crtc_mask)
+{
+ struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+ struct drm_connector_list_iter conn_iter;
+ struct intel_connector *connector;
+ int ret = 0;
+
+ *crtc_mask = 0;
+
+ drm_connector_list_iter_begin(&i915->drm, &conn_iter);
+ for_each_intel_connector_iter(connector, &conn_iter) {
+ struct drm_connector_state *conn_state =
+ connector->base.state;
+ struct intel_crtc_state *crtc_state;
+ struct intel_crtc *crtc;
+
+ if (!intel_dp_has_connector(intel_dp, conn_state))
+ continue;
+
+ crtc = to_intel_crtc(conn_state->crtc);
+ if (!crtc)
+ continue;
+
+ ret = drm_modeset_lock(&crtc->base.mutex, ctx);
+ if (ret)
+ break;
+
+ crtc_state = to_intel_crtc_state(crtc->base.state);
+
+ drm_WARN_ON(&i915->drm, !intel_crtc_has_dp_encoder(crtc_state));
+
+ if (!crtc_state->hw.active)
+ continue;
+
+ if (conn_state->commit &&
+ !try_wait_for_completion(&conn_state->commit->hw_done))
+ continue;
+
+ *crtc_mask |= drm_crtc_mask(&crtc->base);
+ }
+ drm_connector_list_iter_end(&conn_iter);
+
+ return ret;
+}
+
+static int intel_dp_do_phy_test(struct intel_encoder *encoder,
+ struct drm_modeset_acquire_ctx *ctx)
+{
+ struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+ struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+ u32 crtc_mask;
+ int ret;
+
+ ret = drm_modeset_lock(&dev_priv->drm.mode_config.connection_mutex,
+ ctx);
+ if (ret)
+ return ret;
+
+ ret = intel_dp_prep_phy_test(intel_dp, ctx, &crtc_mask);
+ if (ret)
+ return ret;
+
+ if (crtc_mask == 0)
+ return 0;
+
+ drm_dbg_km
[Intel-gfx] [PATCH v2 02/11] drm/i915: s/old_crtc_state/crtc_state/
From: Ville Syrjälä
intel_dp_enable_port() is called during the enable sequence,
so there is nothing old about the passed in crtc state.
Rename it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index ff96540c8612..3586d79f5599 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -3850,7 +3850,7 @@ g4x_set_link_train(struct intel_dp *intel_dp,
}
static void intel_dp_enable_port(struct intel_dp *intel_dp,
-const struct intel_crtc_state *old_crtc_state)
+const struct intel_crtc_state *crtc_state)
{
struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
@@ -3865,7 +3865,7 @@ static void intel_dp_enable_port(struct intel_dp
*intel_dp,
* fail when the power sequencer is freshly used for this port.
*/
intel_dp->DP |= DP_PORT_EN;
- if (old_crtc_state->has_audio)
+ if (crtc_state->has_audio)
intel_dp->DP |= DP_AUDIO_OUTPUT_ENABLE;
intel_de_write(dev_priv, intel_dp->output_reg, intel_dp->DP);
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 06/11] drm/i915: Split ICL MG PHY buf trans per output type
From: Ville Syrjälä
Make the mess inside the buf trans funcs a bit more manageable by
splitting along the lines of output type.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 31 ++--
1 file changed, 23 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 4c3416d89f30..e3c6d4942b68 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -1079,19 +1079,34 @@ icl_get_combo_buf_trans(struct intel_encoder *encoder,
int type, int rate,
}
static const struct icl_mg_phy_ddi_buf_trans *
-icl_get_mg_buf_trans(struct intel_encoder *encoder, int type, int rate,
-int *n_entries)
+icl_get_mg_buf_trans_hdmi(struct intel_encoder *encoder, int type, int rate,
+ int *n_entries)
{
- if (type == INTEL_OUTPUT_HDMI) {
- *n_entries = ARRAY_SIZE(icl_mg_phy_ddi_translations_hdmi);
- return icl_mg_phy_ddi_translations_hdmi;
- } else if (rate > 27) {
+ *n_entries = ARRAY_SIZE(icl_mg_phy_ddi_translations_hdmi);
+ return icl_mg_phy_ddi_translations_hdmi;
+}
+
+static const struct icl_mg_phy_ddi_buf_trans *
+icl_get_mg_buf_trans_dp(struct intel_encoder *encoder, int type, int rate,
+ int *n_entries)
+{
+ if (rate > 27) {
*n_entries = ARRAY_SIZE(icl_mg_phy_ddi_translations_hbr2_hbr3);
return icl_mg_phy_ddi_translations_hbr2_hbr3;
+ } else {
+ *n_entries = ARRAY_SIZE(icl_mg_phy_ddi_translations_rbr_hbr);
+ return icl_mg_phy_ddi_translations_rbr_hbr;
}
+}
- *n_entries = ARRAY_SIZE(icl_mg_phy_ddi_translations_rbr_hbr);
- return icl_mg_phy_ddi_translations_rbr_hbr;
+static const struct icl_mg_phy_ddi_buf_trans *
+icl_get_mg_buf_trans(struct intel_encoder *encoder, int type, int rate,
+int *n_entries)
+{
+ if (type == INTEL_OUTPUT_HDMI)
+ return icl_get_mg_buf_trans_hdmi(encoder, type, rate,
n_entries);
+ else
+ return icl_get_mg_buf_trans_dp(encoder, type, rate, n_entries);
}
static const struct cnl_ddi_buf_trans *
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 09/11] drm/i915: Split TGL DKL PHY buf trans per output type
From: Ville Syrjälä
Make the mess inside the buf trans funcs a bit more manageable by
splitting along the lines of output type.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 31 ++--
1 file changed, 23 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index fea06c1b09d9..7032c367075a 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -1218,19 +1218,34 @@ tgl_get_combo_buf_trans(struct intel_encoder *encoder,
int type, int rate,
}
static const struct tgl_dkl_phy_ddi_buf_trans *
-tgl_get_dkl_buf_trans(struct intel_encoder *encoder, int type, int rate,
- int *n_entries)
+tgl_get_dkl_buf_trans_hdmi(struct intel_encoder *encoder, int type, int rate,
+ int *n_entries)
{
- if (type == INTEL_OUTPUT_HDMI) {
- *n_entries = ARRAY_SIZE(tgl_dkl_phy_hdmi_ddi_trans);
- return tgl_dkl_phy_hdmi_ddi_trans;
- } else if (rate > 27) {
+ *n_entries = ARRAY_SIZE(tgl_dkl_phy_hdmi_ddi_trans);
+ return tgl_dkl_phy_hdmi_ddi_trans;
+}
+
+static const struct tgl_dkl_phy_ddi_buf_trans *
+tgl_get_dkl_buf_trans_dp(struct intel_encoder *encoder, int type, int rate,
+int *n_entries)
+{
+ if (rate > 27) {
*n_entries = ARRAY_SIZE(tgl_dkl_phy_dp_ddi_trans_hbr2);
return tgl_dkl_phy_dp_ddi_trans_hbr2;
+ } else {
+ *n_entries = ARRAY_SIZE(tgl_dkl_phy_dp_ddi_trans);
+ return tgl_dkl_phy_dp_ddi_trans;
}
+}
- *n_entries = ARRAY_SIZE(tgl_dkl_phy_dp_ddi_trans);
- return tgl_dkl_phy_dp_ddi_trans;
+static const struct tgl_dkl_phy_ddi_buf_trans *
+tgl_get_dkl_buf_trans(struct intel_encoder *encoder, int type, int rate,
+ int *n_entries)
+{
+ if (type == INTEL_OUTPUT_HDMI)
+ return tgl_get_dkl_buf_trans_hdmi(encoder, type, rate,
n_entries);
+ else
+ return tgl_get_dkl_buf_trans_dp(encoder, type, rate, n_entries);
}
static int intel_ddi_hdmi_level(struct intel_encoder *encoder)
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 10/11] drm/i915: Plumb crtc_state to link training
From: Ville Syrjälä
Get rid of mode crtc->config usage, and some ad-hoc intel_dp state
usage by plumbing the crtc state all the way down to the link training
code.
Unfortunately we do have to keep some cached state in intel_dp so
that we can do the "does the link need retraining?" checks from
the short hpd handler.
v2: Add intel_crtc_state forward declaration
v3: Don't kill the PHY test code totally since it's
now in the hotplug work where we can get at the states
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 416 +-
drivers/gpu/drm/i915/display/intel_ddi.h | 6 +-
.../drm/i915/display/intel_display_types.h| 17 +-
drivers/gpu/drm/i915/display/intel_dp.c | 123 --
drivers/gpu/drm/i915/display/intel_dp.h | 10 +-
.../drm/i915/display/intel_dp_link_training.c | 102 +++--
.../drm/i915/display/intel_dp_link_training.h | 8 +-
drivers/gpu/drm/i915/display/intel_dpio_phy.c | 23 +-
drivers/gpu/drm/i915/display/intel_dpio_phy.h | 2 +
drivers/gpu/drm/i915/display/intel_hdmi.c | 7 +-
10 files changed, 388 insertions(+), 326 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 7032c367075a..cdf3e5540482 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -1034,7 +1034,8 @@ cnl_get_buf_trans_edp(struct intel_encoder *encoder, int
*n_entries)
}
static const struct cnl_ddi_buf_trans *
-icl_get_combo_buf_trans_hdmi(struct intel_encoder *encoder, int type, int rate,
+icl_get_combo_buf_trans_hdmi(struct intel_encoder *encoder,
+const struct intel_crtc_state *crtc_state,
int *n_entries)
{
*n_entries = ARRAY_SIZE(icl_combo_phy_ddi_translations_hdmi);
@@ -1042,7 +1043,8 @@ icl_get_combo_buf_trans_hdmi(struct intel_encoder
*encoder, int type, int rate,
}
static const struct cnl_ddi_buf_trans *
-icl_get_combo_buf_trans_dp(struct intel_encoder *encoder, int type, int rate,
+icl_get_combo_buf_trans_dp(struct intel_encoder *encoder,
+ const struct intel_crtc_state *crtc_state,
int *n_entries)
{
*n_entries = ARRAY_SIZE(icl_combo_phy_ddi_translations_dp_hbr2);
@@ -1050,12 +1052,13 @@ icl_get_combo_buf_trans_dp(struct intel_encoder
*encoder, int type, int rate,
}
static const struct cnl_ddi_buf_trans *
-icl_get_combo_buf_trans_edp(struct intel_encoder *encoder, int type, int rate,
+icl_get_combo_buf_trans_edp(struct intel_encoder *encoder,
+ const struct intel_crtc_state *crtc_state,
int *n_entries)
{
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
- if (rate > 54) {
+ if (crtc_state->port_clock > 54) {
*n_entries =
ARRAY_SIZE(icl_combo_phy_ddi_translations_edp_hbr3);
return icl_combo_phy_ddi_translations_edp_hbr3;
} else if (dev_priv->vbt.edp.low_vswing) {
@@ -1063,23 +1066,25 @@ icl_get_combo_buf_trans_edp(struct intel_encoder
*encoder, int type, int rate,
return icl_combo_phy_ddi_translations_edp_hbr2;
}
- return icl_get_combo_buf_trans_dp(encoder, type, rate, n_entries);
+ return icl_get_combo_buf_trans_dp(encoder, crtc_state, n_entries);
}
static const struct cnl_ddi_buf_trans *
-icl_get_combo_buf_trans(struct intel_encoder *encoder, int type, int rate,
+icl_get_combo_buf_trans(struct intel_encoder *encoder,
+ const struct intel_crtc_state *crtc_state,
int *n_entries)
{
- if (type == INTEL_OUTPUT_HDMI)
- return icl_get_combo_buf_trans_hdmi(encoder, type, rate,
n_entries);
- else if (type == INTEL_OUTPUT_EDP)
- return icl_get_combo_buf_trans_edp(encoder, type, rate,
n_entries);
+ if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI))
+ return icl_get_combo_buf_trans_hdmi(encoder, crtc_state,
n_entries);
+ else if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_EDP))
+ return icl_get_combo_buf_trans_edp(encoder, crtc_state,
n_entries);
else
- return icl_get_combo_buf_trans_dp(encoder, type, rate,
n_entries);
+ return icl_get_combo_buf_trans_dp(encoder, crtc_state,
n_entries);
}
static const struct icl_mg_phy_ddi_buf_trans *
-icl_get_mg_buf_trans_hdmi(struct intel_encoder *encoder, int type, int rate,
+icl_get_mg_buf_trans_hdmi(struct intel_encoder *encoder,
+ const struct intel_crtc_state *crtc_state,
int *n_entries)
{
*n_entries = ARRAY_SIZE(icl_mg_phy_ddi_translations_hdmi);
@@ -1087,10 +1092,11 @@ icl_get_mg_buf_trans_hdmi(struct intel_encoder
*encoder, int type, int rate,
}
static const struct icl_mg_phy_ddi_buf_trans *
-icl_get_mg_buf_trans_dp(struct inte
[Intel-gfx] [PATCH v2 11/11] drm/i915: Eliminate intel_dp.regs.dp_tp_{ctl, status}
From: Ville Syrjälä
Now that we've plumbed the crtc state all the way down we can
eliminate the DP_TP_{CTL,STATUS} register offsets from intel_dp,
and instead we derive them directly from the crtc state.
And thus we can get rid of the nasty hack in intel_ddi_get_config()
which mutates intel_dp during the readout.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 107 ++
drivers/gpu/drm/i915/display/intel_ddi.h | 5 +
.../drm/i915/display/intel_display_types.h| 8 --
drivers/gpu/drm/i915/display/intel_dp.c | 2 -
drivers/gpu/drm/i915/display/intel_dp_mst.c | 24 ++--
5 files changed, 76 insertions(+), 70 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index cdf3e5540482..11297a8af3b7 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3295,6 +3295,37 @@ icl_program_mg_dp_mode(struct intel_digital_port
*dig_port,
}
}
+static enum transcoder
+tgl_dp_tp_transcoder(const struct intel_crtc_state *crtc_state)
+{
+ if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP_MST))
+ return crtc_state->mst_master_transcoder;
+ else
+ return crtc_state->cpu_transcoder;
+}
+
+i915_reg_t dp_tp_ctl_reg(struct intel_encoder *encoder,
+const struct intel_crtc_state *crtc_state)
+{
+ struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+
+ if (INTEL_GEN(dev_priv) >= 12)
+ return TGL_DP_TP_CTL(tgl_dp_tp_transcoder(crtc_state));
+ else
+ return DP_TP_CTL(encoder->port);
+}
+
+i915_reg_t dp_tp_status_reg(struct intel_encoder *encoder,
+ const struct intel_crtc_state *crtc_state)
+{
+ struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+
+ if (INTEL_GEN(dev_priv) >= 12)
+ return TGL_DP_TP_STATUS(tgl_dp_tp_transcoder(crtc_state));
+ else
+ return DP_TP_STATUS(encoder->port);
+}
+
static void intel_dp_sink_set_fec_ready(struct intel_dp *intel_dp,
const struct intel_crtc_state
*crtc_state)
{
@@ -3319,11 +3350,12 @@ static void intel_ddi_enable_fec(struct intel_encoder
*encoder,
return;
intel_dp = enc_to_intel_dp(encoder);
- val = intel_de_read(dev_priv, intel_dp->regs.dp_tp_ctl);
+ val = intel_de_read(dev_priv, dp_tp_ctl_reg(encoder, crtc_state));
val |= DP_TP_CTL_FEC_ENABLE;
- intel_de_write(dev_priv, intel_dp->regs.dp_tp_ctl, val);
+ intel_de_write(dev_priv, dp_tp_ctl_reg(encoder, crtc_state), val);
- if (intel_de_wait_for_set(dev_priv, intel_dp->regs.dp_tp_status,
+ if (intel_de_wait_for_set(dev_priv,
+ dp_tp_status_reg(encoder, crtc_state),
DP_TP_STATUS_FEC_ENABLE_LIVE, 1))
drm_err(&dev_priv->drm,
"Timed out waiting for FEC Enable Status\n");
@@ -3340,10 +3372,10 @@ static void intel_ddi_disable_fec_state(struct
intel_encoder *encoder,
return;
intel_dp = enc_to_intel_dp(encoder);
- val = intel_de_read(dev_priv, intel_dp->regs.dp_tp_ctl);
+ val = intel_de_read(dev_priv, dp_tp_ctl_reg(encoder, crtc_state));
val &= ~DP_TP_CTL_FEC_ENABLE;
- intel_de_write(dev_priv, intel_dp->regs.dp_tp_ctl, val);
- intel_de_posting_read(dev_priv, intel_dp->regs.dp_tp_ctl);
+ intel_de_write(dev_priv, dp_tp_ctl_reg(encoder, crtc_state), val);
+ intel_de_posting_read(dev_priv, dp_tp_ctl_reg(encoder, crtc_state));
}
static void tgl_ddi_pre_enable_dp(struct intel_atomic_state *state,
@@ -3357,15 +3389,11 @@ static void tgl_ddi_pre_enable_dp(struct
intel_atomic_state *state,
struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
bool is_mst = intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP_MST);
int level = intel_ddi_dp_level(intel_dp);
- enum transcoder transcoder = crtc_state->cpu_transcoder;
intel_dp_set_link_params(intel_dp,
crtc_state->port_clock,
crtc_state->lane_count);
- intel_dp->regs.dp_tp_ctl = TGL_DP_TP_CTL(transcoder);
- intel_dp->regs.dp_tp_status = TGL_DP_TP_STATUS(transcoder);
-
/*
* 1. Enable Power Wells
*
@@ -3682,12 +3710,10 @@ static void intel_disable_ddi_buf(struct intel_encoder
*encoder,
}
if (intel_crtc_has_dp_encoder(crtc_state)) {
- struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
-
- val = intel_de_read(dev_priv, intel_dp->regs.dp_tp_ctl);
+ val = intel_de_read(dev_priv, dp_tp_ctl_reg(encoder,
crtc_state));
val &= ~(DP_TP_CTL_ENABLE | DP_TP_CTL_LINK_TRAIN_MASK);
val |= DP_TP_CTL_LINK_TRAIN
[Intel-gfx] [PATCH v2 05/11] drm/i915: Split ICL combo PHY buf trans per output type
From: Ville Syrjälä
Make the mess inside the buf trans funcs a bit more manageable by
splitting along the lines of output type.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 42 +++-
1 file changed, 33 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 4d06178cd76c..4c3416d89f30 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -1034,24 +1034,48 @@ cnl_get_buf_trans_edp(struct intel_encoder *encoder,
int *n_entries)
}
static const struct cnl_ddi_buf_trans *
-icl_get_combo_buf_trans(struct intel_encoder *encoder, int type, int rate,
- int *n_entries)
+icl_get_combo_buf_trans_hdmi(struct intel_encoder *encoder, int type, int rate,
+int *n_entries)
+{
+ *n_entries = ARRAY_SIZE(icl_combo_phy_ddi_translations_hdmi);
+ return icl_combo_phy_ddi_translations_hdmi;
+}
+
+static const struct cnl_ddi_buf_trans *
+icl_get_combo_buf_trans_dp(struct intel_encoder *encoder, int type, int rate,
+ int *n_entries)
+{
+ *n_entries = ARRAY_SIZE(icl_combo_phy_ddi_translations_dp_hbr2);
+ return icl_combo_phy_ddi_translations_dp_hbr2;
+}
+
+static const struct cnl_ddi_buf_trans *
+icl_get_combo_buf_trans_edp(struct intel_encoder *encoder, int type, int rate,
+ int *n_entries)
{
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
- if (type == INTEL_OUTPUT_HDMI) {
- *n_entries = ARRAY_SIZE(icl_combo_phy_ddi_translations_hdmi);
- return icl_combo_phy_ddi_translations_hdmi;
- } else if (rate > 54 && type == INTEL_OUTPUT_EDP) {
+ if (rate > 54) {
*n_entries =
ARRAY_SIZE(icl_combo_phy_ddi_translations_edp_hbr3);
return icl_combo_phy_ddi_translations_edp_hbr3;
- } else if (type == INTEL_OUTPUT_EDP && dev_priv->vbt.edp.low_vswing) {
+ } else if (dev_priv->vbt.edp.low_vswing) {
*n_entries =
ARRAY_SIZE(icl_combo_phy_ddi_translations_edp_hbr2);
return icl_combo_phy_ddi_translations_edp_hbr2;
}
- *n_entries = ARRAY_SIZE(icl_combo_phy_ddi_translations_dp_hbr2);
- return icl_combo_phy_ddi_translations_dp_hbr2;
+ return icl_get_combo_buf_trans_dp(encoder, type, rate, n_entries);
+}
+
+static const struct cnl_ddi_buf_trans *
+icl_get_combo_buf_trans(struct intel_encoder *encoder, int type, int rate,
+ int *n_entries)
+{
+ if (type == INTEL_OUTPUT_HDMI)
+ return icl_get_combo_buf_trans_hdmi(encoder, type, rate,
n_entries);
+ else if (type == INTEL_OUTPUT_EDP)
+ return icl_get_combo_buf_trans_edp(encoder, type, rate,
n_entries);
+ else
+ return icl_get_combo_buf_trans_dp(encoder, type, rate,
n_entries);
}
static const struct icl_mg_phy_ddi_buf_trans *
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/edp/jsl: Update vswing table for HBR and HBR2
On Wed, Sep 30, 2020 at 12:59:58AM +0300, Ville Syrjälä wrote: > On Wed, Sep 30, 2020 at 12:11:48AM +0300, Ville Syrjälä wrote: > > On Tue, Sep 29, 2020 at 02:01:44PM -0700, Matt Roper wrote: > > > On Tue, Sep 29, 2020 at 11:30:22PM +0300, Ville Syrjälä wrote: > > > > On Tue, Sep 29, 2020 at 08:20:22PM +, Souza, Jose wrote: > > > > > On Tue, 2020-09-29 at 23:02 +0300, Ville Syrjälä wrote: > > > > > > On Tue, Sep 29, 2020 at 07:33:45PM +, Souza, Jose wrote: > > > > > > > On Tue, 2020-09-29 at 17:41 +0530, Tejas Upadhyay wrote: > > > > > > > > JSL has update in vswing table for eDP > > > > > > > > > > > > > > Would be nice to mention in the commit description why PCH is > > > > > > > being used, that would avoid Ville's question. > > > > > > > > > > > > If the thing has nothing to do PCH then it should not use the PCH > > > > > > type > > > > > > for the the check. Instead we should just do the EHL/JSL split. > > > > > > > > > > In the first version Matt Roper suggested to use PCH to differentiate > > > > > between EHL and JSL, Jani also agreed with this solution.This 2 PCHs > > > > > can only be > > > > > associate with EHL and JSL respectively, so no downsides here. > > > > > > > > The downside is that the code makes no sense on the first glance. > > > > It's going to generate a "wtf?" exception in the brain and require > > > > me to take a second look to figure what is going on. Exception > > > > handling is expensive and shouldn't be needed in cases where it's > > > > trivial to make the code 100% obvious. > > > > > > The bspec documents EHL and JSL as being the same platform and identical > > > in all programming since they are literally the same display IP; this > > > vswing table is the one and only place where the two are treated in a > > > distinct manner for reasons that lie outside the display controller. If > > > you had to stop and take a closer look at the code here, that's a > > > probably a good thing since in general there should generally never be a > > > difference in the behavior between the two. Adding an additional > > > clarifying comment is probably in order too since this is a very > > > exceptional special case. > > > > > > If we deviate from the bspec's guidance and try to split IS_ELKHARTLAKE > > > and IS_JASPERLAKE across the whole driver, that's going to be a lot more > > > pain to maintain down the road since we'll almost certainly have cases > > > where someone silently leaves one or the other off a condition and gets > > > unexepcted behavior. I could see arguments for using a SUBPLATFORM here > > > like we do for TGL_U vs TGL_Y, but even that seems like overkill if we > > > already have a clear way to distinguish the two cases (PCH pairing) and > > > can just leave a clarifying comment. > > > > That fixed PCH pairing is totally undocumented AFAICS. And vswing has > > nothing to do with the south display, so the wtf will still happen. > > Comment or no comment. > > Oh and JSP does not show up in bspec even once. MCC appears exactly once > where it talks about the differences between MCC and ICL-N PCH (which I > guess is the same as JSP?). No, ICL-N PCH is something different. :-( There were some early test chips created that paired the EHL/JSL graphics/media/display IP with an ICL PCH just for early debug/test purposes, but that pairing isn't something that actually exists as a real platform. I think the confusion here arises because most driver developers only look at (or have access to) the bspec, which does not aim to document end-user platforms, but rather IP families that the graphics/media/display hardware IP teams design. The bspec is not an authoritative document for anything that lies outside the GMD IP itself. The GMD architects do sometimes try to pull in additional information from external teams/sources (such as PCH pairing or the electrical details like the vswing programming here) to make life easier for the software teams like us that only really deal with the bspec, but that information comes from external sources, so it's a bit inconsistent in terms of how much detail there is (or even whether it's described at all). We could probably file bspec defects to get them to include the PCH pairing details for EHL/JSL in the bspec, but ultimately EHL="EHL G/M/D + MCC PCH" and JSL="EHL G/M/D + JSP PCH;" this has already been confirmed in an offline email thread with the hardware teams. Elkhart Lake and Jasper Lake are two separate end-user platforms, that both incorporated the same G/M/D IP design. The name "Jasper Lake" existed as a codename first, so that's the name that shows up in the bspec; this wound up being a bit confusing when Elkhart Lake was actually the first of the two to be released and thus wound up being the name we have in our code. But the situation seems similar to CHT vs BSW which are both referred to as "CHV" in the bspec and in our code (although obviously there was no PCH pairing for those SoCs). Steppings, work
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Plumb crtc state to link training code (rev3)
== Series Details ==
Series: drm/i915: Plumb crtc state to link training code (rev3)
URL : https://patchwork.freedesktop.org/series/76993/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
e1b9ea43cc51 drm/i915: s/pre_empemph/preemph/
099b31ec3c93 drm/i915: s/old_crtc_state/crtc_state/
a5235039ab34 drm/i915: Make intel_dp_process_phy_request() static
3f3c4a5bf30d drm/i915: Shove the PHY test into the hotplug work
a5f3aceec002 drm/i915: Split ICL combo PHY buf trans per output type
fccaa6c84e89 drm/i915: Split ICL MG PHY buf trans per output type
cdd8092d9acb drm/i915: Split EHL combo PHY buf trans per output type
-:62: WARNING:UNNECESSARY_ELSE: else is not generally useful after a break or
return
#62: FILE: drivers/gpu/drm/i915/display/intel_ddi.c:1138:
+ return icl_combo_phy_ddi_translations_edp_hbr3;
+ } else {
total: 0 errors, 1 warnings, 0 checks, 70 lines checked
7676ef2864b7 drm/i915: Split TGL combo PHY buf trans per output type
-:72: WARNING:UNNECESSARY_ELSE: else is not generally useful after a break or
return
#72: FILE: drivers/gpu/drm/i915/display/intel_ddi.c:1177:
+ return tgl_uy_combo_phy_ddi_translations_dp_hbr2;
+ } else {
total: 0 errors, 1 warnings, 0 checks, 100 lines checked
b0e21d0d4119 drm/i915: Split TGL DKL PHY buf trans per output type
c0ea3b11329e drm/i915: Plumb crtc_state to link training
4c9eb175070d drm/i915: Eliminate intel_dp.regs.dp_tp_{ctl, status}
___
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: Plumb crtc state to link training code (rev3)
== Series Details == Series: drm/i915: Plumb crtc state to link training code (rev3) URL : https://patchwork.freedesktop.org/series/76993/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. +drivers/gpu/drm/i915/display/intel_dp.c:6042:39:unsigned int enum drm_connector_status +drivers/gpu/drm/i915/display/intel_dp.c:6042:39:unsigned int enum intel_hotplug_state +drivers/gpu/drm/i915/display/intel_dp.c:6042:39: warning: mixing different enum types: ___ 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: Plumb crtc state to link training code (rev3)
== Series Details == Series: drm/i915: Plumb crtc state to link training code (rev3) URL : https://patchwork.freedesktop.org/series/76993/ State : success == Summary == CI Bug Log - changes from CI_DRM_9075 -> Patchwork_18594 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18594/index.html Known issues Here are the changes found in Patchwork_18594 that come from known issues: ### IGT changes ### Issues hit * igt@i915_pm_rpm@basic-pci-d3-state: - fi-byt-j1900: [PASS][1] -> [DMESG-WARN][2] ([i915#1982]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9075/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18594/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html * igt@i915_pm_rpm@module-reload: - fi-bsw-kefka: [PASS][3] -> [INCOMPLETE][4] ([i915#151] / [i915#1844] / [i915#1909]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9075/fi-bsw-kefka/igt@i915_pm_...@module-reload.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18594/fi-bsw-kefka/igt@i915_pm_...@module-reload.html * igt@kms_chamelium@dp-crc-fast: - fi-kbl-7500u: [PASS][5] -> [FAIL][6] ([i915#1161] / [i915#262]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9075/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18594/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html - fi-icl-u2: [PASS][7] -> [FAIL][8] ([i915#1161] / [i915#262]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9075/fi-icl-u2/igt@kms_chamel...@dp-crc-fast.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18594/fi-icl-u2/igt@kms_chamel...@dp-crc-fast.html - fi-cml-u2: [PASS][9] -> [FAIL][10] ([i915#1161] / [i915#262]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9075/fi-cml-u2/igt@kms_chamel...@dp-crc-fast.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18594/fi-cml-u2/igt@kms_chamel...@dp-crc-fast.html * igt@kms_chamelium@hdmi-crc-fast: - fi-kbl-7500u: [PASS][11] -> [FAIL][12] ([i915#1161] / [i915#2260]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9075/fi-kbl-7500u/igt@kms_chamel...@hdmi-crc-fast.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18594/fi-kbl-7500u/igt@kms_chamel...@hdmi-crc-fast.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - fi-icl-u2: [PASS][13] -> [DMESG-WARN][14] ([i915#1982]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9075/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18594/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html * igt@kms_flip@basic-flip-vs-modeset@c-dp2: - fi-skl-6700k2: [PASS][15] -> [DMESG-WARN][16] ([i915#2203]) +3 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9075/fi-skl-6700k2/igt@kms_flip@basic-flip-vs-mode...@c-dp2.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18594/fi-skl-6700k2/igt@kms_flip@basic-flip-vs-mode...@c-dp2.html * igt@kms_flip@basic-flip-vs-wf_vblank@c-dp2: - fi-skl-guc: [PASS][17] -> [DMESG-WARN][18] ([i915#2203]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9075/fi-skl-guc/igt@kms_flip@basic-flip-vs-wf_vbl...@c-dp2.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18594/fi-skl-guc/igt@kms_flip@basic-flip-vs-wf_vbl...@c-dp2.html * igt@kms_psr@cursor_plane_move: - fi-kbl-r: [PASS][19] -> [SKIP][20] ([fdo#109271] / [i915#668]) +3 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9075/fi-kbl-r/igt@kms_psr@cursor_plane_move.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18594/fi-kbl-r/igt@kms_psr@cursor_plane_move.html Possible fixes * igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1: - fi-icl-u2: [DMESG-WARN][21] ([i915#1982]) -> [PASS][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9075/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18594/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html Warnings * igt@kms_flip@basic-flip-vs-wf_vblank@a-dp1: - fi-kbl-x1275: [DMESG-WARN][23] ([i915#62] / [i915#92] / [i915#95]) -> [DMESG-WARN][24] ([i915#62] / [i915#92]) +1 similar issue [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9075/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-wf_vbl...@a-dp1.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18594/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-wf_vbl...@a-dp1.html * igt@kms_pipe_crc_basic@suspend-read-crc-pip
Re: [Intel-gfx] [PATCH] drm/i915: Read DIMM size in Gb rather than GB
On Tue, 2020-09-29 at 16:13 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä <
> ville.syrj...@linux.intel.com
> >
>
> CNL+ can report DIMM sizes in .5 GB units. In order to not trauncate
> away the .5 GB let's switch to storing the DIMM size in Gb units.
>
Reviewed-by: José Roberto de Souza
> Cc: Swati Sharma <
> swati2.sha...@intel.com
> >
> Signed-off-by: Ville Syrjälä <
> ville.syrj...@linux.intel.com
> >
> ---
> drivers/gpu/drm/i915/intel_dram.c | 23 ---
> 1 file changed, 12 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dram.c
> b/drivers/gpu/drm/i915/intel_dram.c
> index 8aa12cad93ce..4754296a250e 100644
> --- a/drivers/gpu/drm/i915/intel_dram.c
> +++ b/drivers/gpu/drm/i915/intel_dram.c
> @@ -7,7 +7,8 @@
> #include "intel_dram.h"
>
> struct dram_dimm_info {
> - u8 size, width, ranks;
> + u16 size;
> + u8 width, ranks;
> };
>
> struct dram_channel_info {
> @@ -41,10 +42,10 @@ static int intel_dimm_num_devices(const struct
> dram_dimm_info *dimm)
> return dimm->ranks * 64 / (dimm->width ?: 1);
> }
>
> -/* Returns total GB for the whole DIMM */
> +/* Returns total Gb for the whole DIMM */
> static int skl_get_dimm_size(u16 val)
> {
> - return val & SKL_DRAM_SIZE_MASK;
> + return (val & SKL_DRAM_SIZE_MASK) * 8;
> }
>
> static int skl_get_dimm_width(u16 val)
> @@ -74,10 +75,10 @@ static int skl_get_dimm_ranks(u16 val)
> return val + 1;
> }
>
> -/* Returns total GB for the whole DIMM */
> +/* Returns total Gb for the whole DIMM */
> static int cnl_get_dimm_size(u16 val)
> {
> - return (val & CNL_DRAM_SIZE_MASK) / 2;
> + return (val & CNL_DRAM_SIZE_MASK) * 8 / 2;
> }
>
> static int cnl_get_dimm_width(u16 val)
> @@ -110,8 +111,8 @@ static int cnl_get_dimm_ranks(u16 val)
> static bool
> skl_is_16gb_dimm(const struct dram_dimm_info *dimm)
> {
> - /* Convert total GB to Gb per DRAM device */
> - return 8 * dimm->size / (intel_dimm_num_devices(dimm) ?: 1) == 16;
> + /* Convert total Gb to Gb per DRAM device */
> + return dimm->size / (intel_dimm_num_devices(dimm) ?: 1) == 16;
> }
>
> static void
> @@ -130,7 +131,7 @@ skl_dram_get_dimm_info(struct drm_i915_private *i915,
> }
>
> drm_dbg_kms(&i915->drm,
> - "CH%u DIMM %c size: %u GB, width: X%u, ranks: %u, 16Gb
> DIMMs: %s\n",
> + "CH%u DIMM %c size: %u Gb, width: X%u, ranks: %u, 16Gb
> DIMMs: %s\n",
> channel, dimm_name, dimm->size, dimm->width, dimm->ranks,
> yesno(skl_is_16gb_dimm(dimm)));
> }
> @@ -354,9 +355,9 @@ static void bxt_get_dimm_info(struct dram_dimm_info
> *dimm, u32 val)
>
> /*
>* Size in register is Gb per DRAM device. Convert to total
> - * GB to match the way we report this for non-LP platforms.
> + * Gb to match the way we report this for non-LP platforms.
>*/
> - dimm->size = bxt_get_dimm_size(val) * intel_dimm_num_devices(dimm) / 8;
> + dimm->size = bxt_get_dimm_size(val) * intel_dimm_num_devices(dimm);
> }
>
> static int bxt_get_dram_info(struct drm_i915_private *i915)
> @@ -404,7 +405,7 @@ static int bxt_get_dram_info(struct drm_i915_private
> *i915)
> dram_info->type != type);
>
> drm_dbg_kms(&i915->drm,
> - "CH%u DIMM size: %u GB, width: X%u, ranks: %u,
> type: %s\n",
> + "CH%u DIMM size: %u Gb, width: X%u, ranks: %u,
> type: %s\n",
> i - BXT_D_CR_DRP0_DUNIT_START,
> dimm.size, dimm.width, dimm.ranks,
> intel_dram_type_str(type));
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 09/24] drm/i915/dg1: Enable DPLL for DG1
Add DG1 DPLL Enable register macro and use the macro to enable the
correct DPLL based on PLL id. Although we use
_MG_PLL1_ENABLE/_MG_PLL2_ENABLE these are rather combo phys.
While at it, fix coding style: wrong newlines and use if/else chain
v2: Rewrite original patch from Aditya Swarup based on refactors
upstream
Bspec: 49443, 49206
Cc: Clinton Taylor
Cc: Matt Roper
Cc: Aditya Swarup
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 12 ++--
drivers/gpu/drm/i915/i915_reg.h | 4
2 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
index d41914b73d88..c6d0c19ed40c 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
@@ -151,14 +151,14 @@ static i915_reg_t
intel_combo_pll_enable_reg(struct drm_i915_private *i915,
struct intel_shared_dpll *pll)
{
-
- if (IS_ELKHARTLAKE(i915) && (pll->info->id == DPLL_ID_EHL_DPLL4))
+ if (IS_DG1(i915))
+ return DG1_DPLL_ENABLE(pll->info->id);
+ else if (IS_ELKHARTLAKE(i915) && (pll->info->id == DPLL_ID_EHL_DPLL4))
return MG_PLL_ENABLE(0);
-
- return CNL_DPLL_ENABLE(pll->info->id);
-
-
+ else
+ return CNL_DPLL_ENABLE(pll->info->id);
}
+
/**
* intel_prepare_shared_dpll - call a dpll's prepare hook
* @crtc_state: CRTC, and its state, which has a shared dpll
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 6d32d534543f..a093fe742448 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -10312,6 +10312,10 @@ enum skl_power_gate {
#define MG_PLL_ENABLE(tc_port) _MMIO_PORT((tc_port), _MG_PLL1_ENABLE, \
_MG_PLL2_ENABLE)
+/* DG1 PLL */
+#define DG1_DPLL_ENABLE(pll)_MMIO_PLL3(pll, DPLL0_ENABLE, DPLL1_ENABLE, \
+ _MG_PLL1_ENABLE, _MG_PLL2_ENABLE)
+
#define _MG_REFCLKIN_CTL_PORT1 0x16892C
#define _MG_REFCLKIN_CTL_PORT2 0x16992C
#define _MG_REFCLKIN_CTL_PORT3 0x16A92C
--
2.28.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 02/24] drm/i915/dg1: Initialize RAWCLK properly
From: Matt Roper
DG1 always uses a 38.4 MHz rawclk rather than the 19.2/24 MHz
frequencies on CNP+. Note that register bits associated with this
frequency confusingly use 37 for the divider field rather than 38 as you
might expect.
For simplicity, let's just assume that this 38.4 MHz frequency will hold
true for other future platforms with "fake" PCH south displays and that
the CNP-style behavior will remain for other platforms with a real PCH.
Bspec: 49950
Bspec: 49309
Cc: Aditya Swarup
Cc: Clinton Taylor
Cc: Lucas De Marchi
Signed-off-by: Matt Roper
Signed-off-by: Lucas De Marchi
Reviewed-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index cb93f6cf6d37..7dbf153279fb 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -2680,6 +2680,18 @@ void intel_update_cdclk(struct drm_i915_private
*dev_priv)
DIV_ROUND_UP(dev_priv->cdclk.hw.cdclk, 1000));
}
+static int dg1_rawclk(struct drm_i915_private *dev_priv)
+{
+ /*
+* DG1 always uses a 38.4 MHz rawclk. The bspec tells us
+* "Program Numerator=2, Denominator=4, Divider=37 decimal."
+*/
+ I915_WRITE(PCH_RAWCLK_FREQ,
+ CNP_RAWCLK_DEN(4) | CNP_RAWCLK_DIV(37) | ICP_RAWCLK_NUM(2));
+
+ return 38400;
+}
+
static int cnp_rawclk(struct drm_i915_private *dev_priv)
{
u32 rawclk;
@@ -2788,7 +2800,9 @@ u32 intel_read_rawclk(struct drm_i915_private *dev_priv)
{
u32 freq;
- if (INTEL_PCH_TYPE(dev_priv) >= PCH_CNP)
+ if (INTEL_PCH_TYPE(dev_priv) >= PCH_DG1)
+ freq = dg1_rawclk(dev_priv);
+ else if (INTEL_PCH_TYPE(dev_priv) >= PCH_CNP)
freq = cnp_rawclk(dev_priv);
else if (HAS_PCH_SPLIT(dev_priv))
freq = pch_rawclk(dev_priv);
--
2.28.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 04/24] drm/i915/dg1: Add DG1 power wells
From: Uma Shankar
Most of TGL power wells are re-used for DG1. However, AUDIO Power
Domain is moved from PG3 to PG0. Handle the change and initialize
power wells with the new power well structure.
Some of the Audio Streaming logic still remains in PW3 so still
it needs to be enabled.
DDIA, DDIB, TC1 and TC2 are the active ports on DG1.
Bspec: 49182
Cc: Matt Roper
Cc: Anshuman Gupta
Signed-off-by: Uma Shankar
Signed-off-by: Lucas De Marchi
---
.../drm/i915/display/intel_display_power.c| 201 +-
1 file changed, 200 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 7277e58b01f1..94be64fce5d3 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -2970,6 +2970,44 @@ void intel_display_power_put(struct drm_i915_private
*dev_priv,
BIT_ULL(POWER_DOMAIN_AUX_B) | \
BIT_ULL(POWER_DOMAIN_INIT))
+#define DG1_PW_5_POWER_DOMAINS ( \
+ BIT_ULL(POWER_DOMAIN_PIPE_D) | \
+ BIT_ULL(POWER_DOMAIN_TRANSCODER_D) |\
+ BIT_ULL(POWER_DOMAIN_PIPE_D_PANEL_FITTER) | \
+ BIT_ULL(POWER_DOMAIN_INIT))
+
+#define DG1_PW_4_POWER_DOMAINS ( \
+ DG1_PW_5_POWER_DOMAINS |\
+ BIT_ULL(POWER_DOMAIN_PIPE_C) | \
+ BIT_ULL(POWER_DOMAIN_TRANSCODER_C) |\
+ BIT_ULL(POWER_DOMAIN_PIPE_C_PANEL_FITTER) | \
+ BIT_ULL(POWER_DOMAIN_INIT))
+
+#define DG1_PW_3_POWER_DOMAINS ( \
+ DG1_PW_4_POWER_DOMAINS |\
+ BIT_ULL(POWER_DOMAIN_PIPE_B) | \
+ BIT_ULL(POWER_DOMAIN_TRANSCODER_B) |\
+ BIT_ULL(POWER_DOMAIN_PIPE_B_PANEL_FITTER) | \
+ BIT_ULL(POWER_DOMAIN_PORT_DDI_D_LANES) |\
+ BIT_ULL(POWER_DOMAIN_PORT_DDI_E_LANES) |\
+ BIT_ULL(POWER_DOMAIN_AUX_D) | \
+ BIT_ULL(POWER_DOMAIN_AUX_E) | \
+ BIT_ULL(POWER_DOMAIN_VGA) | \
+ BIT_ULL(POWER_DOMAIN_AUDIO) | \
+ BIT_ULL(POWER_DOMAIN_INIT))
+
+#define DG1_PW_2_POWER_DOMAINS ( \
+ DG1_PW_3_POWER_DOMAINS |\
+ BIT_ULL(POWER_DOMAIN_TRANSCODER_VDSC_PW2) | \
+ BIT_ULL(POWER_DOMAIN_INIT))
+
+#define DG1_DISPLAY_DC_OFF_POWER_DOMAINS ( \
+ DG1_PW_3_POWER_DOMAINS |\
+ BIT_ULL(POWER_DOMAIN_MODESET) | \
+ BIT_ULL(POWER_DOMAIN_AUX_A) | \
+ BIT_ULL(POWER_DOMAIN_AUX_B) | \
+ BIT_ULL(POWER_DOMAIN_INIT))
+
static const struct i915_power_well_ops i9xx_always_on_power_well_ops = {
.sync_hw = i9xx_power_well_sync_hw_noop,
.enable = i9xx_always_on_power_well_noop,
@@ -4474,6 +4512,165 @@ static const struct i915_power_well_desc
rkl_power_wells[] = {
},
};
+static const struct i915_power_well_desc dg1_power_wells[] = {
+ {
+ .name = "always-on",
+ .always_on = true,
+ .domains = POWER_DOMAIN_MASK,
+ .ops = &i9xx_always_on_power_well_ops,
+ .id = DISP_PW_ID_NONE,
+ },
+ {
+ .name = "power well 1",
+ /* Handled by the DMC firmware */
+ .always_on = true,
+ .domains = 0,
+ .ops = &hsw_power_well_ops,
+ .id = SKL_DISP_PW_1,
+ {
+ .hsw.regs = &hsw_power_well_regs,
+ .hsw.idx = ICL_PW_CTL_IDX_PW_1,
+ .hsw.has_fuses = true,
+ },
+ },
+ {
+ .name = "DC off",
+ .domains = DG1_DISPLAY_DC_OFF_POWER_DOMAINS,
+ .ops = &gen9_dc_off_power_well_ops,
+ .id = SKL_DISP_DC_OFF,
+ },
+ {
+ .name = "power well 2",
+ .domains = DG1_PW_2_POWER_DOMAINS,
+ .ops = &hsw_power_well_ops,
+ .id = SKL_DISP_PW_2,
+ {
+ .hsw.regs = &hsw_power_well_regs,
+ .hsw.idx = ICL_PW_CTL_IDX_PW_2,
+ .hsw.has_fuses = true,
+ },
+ },
+ {
+ .name = "power well 3",
+ .domains = DG1_PW_3_POWER_DOMAINS,
+ .ops = &hsw_power_well_ops,
+ .id = ICL_DISP_PW_3,
+ {
+ .hsw.regs = &hsw_power_well_regs,
+ .hsw.idx = ICL_PW_CTL_IDX_PW_3,
+ .hsw.irq_pipe_mask = BIT(PIPE_B),
+ .hsw.has_vga = true,
+ .hsw.has_fuses = true,
+ },
+ },
+ {
+ .name = "DDI A I
[Intel-gfx] [PATCH v6 00/24] Introduce DG1
v6:
- Remove already applied patches and rebase the rest, particularly on
top of DPLL and hotplug changes
- Add new workarounds
- Reword commit messages regarding DDIA, DDIB, TC1 and TC2 ports
- Colletc R-b
The DPLL and hotplug changes are not tested as testing depends on
the lmem patches. They are still wip and do not apply cleanly in
drm-tip.
Aditya Swarup (3):
drm/i915/dg1: Add DPLL macros for DG1
drm/i915/dg1: Add and setup DPLLs for DG1
drm/i915/dg1: Enable first 2 ports for DG1
Anshuman Gupta (2):
drm/i915/dg1: DG1 does not support DC6
drm/i915/dg1: Change DMC_DEBUG{1, 2} registers
Clinton A Taylor (1):
drm/i915/dg1: invert HPD pins
Lucas De Marchi (7):
drm/i915/dg1: add more PCI ids
drm/i915/dg1: Define MOCS table for DG1
drm/i915/dg1: Enable DPLL for DG1
drm/i915/dg1: add hpd interrupt handling
drm/i915/dg1: gmbus pin mapping
drm/i915/dg1: map/unmap pll clocks
drm/i915/dg1: enable PORT C/D aka D/E
Matt Atwood (1):
drm/i915/dg1: Load DMC
Matt Roper (6):
drm/i915/dg1: Initialize RAWCLK properly
drm/i915/dg1: Wait for pcode/uncore handshake at startup
drm/i915/dg1: Don't program PHY_MISC for PHY-C and PHY-D
drm/i915/dg1: Update comp master/slave relationships for PHYs
drm/i915/dg1: Update voltage swing tables for DP
drm/i915/dg1: provide port/phy mapping for vbt
Michel Thierry (1):
drm/i915/dgfx: define llc and snooping behaviour
Stuart Summers (1):
drm/i915/dg1: Add initial DG1 workarounds
Uma Shankar (1):
drm/i915/dg1: Add DG1 power wells
Venkata Sandeep Dhanalakota (1):
drm/i915/dg1: Increase mmio size to 4MB
drivers/gpu/drm/i915/display/intel_bios.c | 12 +-
drivers/gpu/drm/i915/display/intel_cdclk.c| 16 +-
.../gpu/drm/i915/display/intel_combo_phy.c| 7 +-
drivers/gpu/drm/i915/display/intel_csr.c | 12 +-
drivers/gpu/drm/i915/display/intel_ddi.c | 126 ++-
drivers/gpu/drm/i915/display/intel_display.c | 46 +++-
.../drm/i915/display/intel_display_debugfs.c | 9 +-
.../drm/i915/display/intel_display_power.c| 211 +-
drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 54 -
drivers/gpu/drm/i915/display/intel_dpll_mgr.h | 17 ++
drivers/gpu/drm/i915/display/intel_gmbus.c| 15 +-
drivers/gpu/drm/i915/display/intel_hdmi.c | 9 +-
drivers/gpu/drm/i915/display/intel_sprite.c | 4 +-
drivers/gpu/drm/i915/gt/intel_mocs.c | 41 +++-
drivers/gpu/drm/i915/gt/intel_workarounds.c | 111 +++--
drivers/gpu/drm/i915/i915_drv.c | 3 +
drivers/gpu/drm/i915/i915_irq.c | 67 +-
drivers/gpu/drm/i915/i915_pci.c | 4 +
drivers/gpu/drm/i915/i915_reg.h | 62 -
drivers/gpu/drm/i915/intel_pm.c | 39 ++--
drivers/gpu/drm/i915/intel_sideband.c | 15 ++
drivers/gpu/drm/i915/intel_sideband.h | 2 +
drivers/gpu/drm/i915/intel_uncore.c | 4 +
include/drm/i915_pciids.h | 5 +-
24 files changed, 802 insertions(+), 89 deletions(-)
--
2.28.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 07/24] drm/i915/dg1: Add DPLL macros for DG1
From: Aditya Swarup
DG1 has 4 DPLLs where DPLL0 and DPLL1 drive DDIA/B and
DPLL2 and DPLL3 drive DDI-TC1/DDI-TC2.
Introduce DG1_DPLL_CFCRx() helper macros to configure
DPLL registers.
Bspec: 50288, 50299
Cc: Matt Roper
Signed-off-by: Aditya Swarup
Signed-off-by: Lucas De Marchi
Reviewed-by: Matt Roper
---
drivers/gpu/drm/i915/display/intel_dpll_mgr.h | 17 +
drivers/gpu/drm/i915/i915_reg.h | 17 -
2 files changed, 33 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.h
b/drivers/gpu/drm/i915/display/intel_dpll_mgr.h
index 5d9a2bc371e7..205542fb8dc7 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.h
+++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.h
@@ -154,6 +154,23 @@ enum intel_dpll_id {
* @DPLL_ID_TGL_MGPLL6: TGL TC PLL port 6 (TC6)
*/
DPLL_ID_TGL_MGPLL6 = 8,
+
+ /**
+* @DPLL_ID_DG1_DPLL0: DG1 combo PHY DPLL0
+*/
+ DPLL_ID_DG1_DPLL0 = 0,
+ /**
+* @DPLL_ID_DG1_DPLL1: DG1 combo PHY DPLL1
+*/
+ DPLL_ID_DG1_DPLL1 = 1,
+ /**
+* @DPLL_ID_DG1_DPLL2: DG1 combo PHY DPLL2
+*/
+ DPLL_ID_DG1_DPLL2 = 2,
+ /**
+* @DPLL_ID_DG1_DPLL3: DG1 combo PHY DPLL3
+*/
+ DPLL_ID_DG1_DPLL3 = 3,
};
#define I915_NUM_PLLS 9
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 8582dbe6ef69..6d32d534543f 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -242,7 +242,8 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
#define _MMIO_PIPE3(pipe, a, b, c) _MMIO(_PICK(pipe, a, b, c))
#define _MMIO_PORT3(pipe, a, b, c) _MMIO(_PICK(pipe, a, b, c))
#define _MMIO_PHY3(phy, a, b, c) _MMIO(_PHY3(phy, a, b, c))
-#define _MMIO_PLL3(pll, a, b, c) _MMIO(_PICK(pll, a, b, c))
+#define _MMIO_PLL3(pll, ...) _MMIO(_PICK(pll, __VA_ARGS__))
+
/*
* Device info offset array based helpers for groups of registers with unevenly
@@ -10527,6 +10528,20 @@ enum skl_power_gate {
#define RKL_DPLL_CFGCR1(pll) _MMIO_PLL(pll, _TGL_DPLL0_CFGCR1, \
_TGL_DPLL1_CFGCR1)
+#define _DG1_DPLL2_CFGCR0 0x16C284
+#define _DG1_DPLL3_CFGCR0 0x16C28C
+#define DG1_DPLL_CFGCR0(pll) _MMIO_PLL3(pll, _TGL_DPLL0_CFGCR0, \
+ _TGL_DPLL1_CFGCR0, \
+ _DG1_DPLL2_CFGCR0, \
+ _DG1_DPLL3_CFGCR0)
+
+#define _DG1_DPLL2_CFGCR1 0x16C288
+#define _DG1_DPLL3_CFGCR1 0x16C290
+#define DG1_DPLL_CFGCR1(pll)_MMIO_PLL3(pll, _TGL_DPLL0_CFGCR1, \
+ _TGL_DPLL1_CFGCR1, \
+ _DG1_DPLL2_CFGCR1, \
+ _DG1_DPLL3_CFGCR1)
+
#define _DKL_PHY1_BASE 0x168000
#define _DKL_PHY2_BASE 0x169000
#define _DKL_PHY3_BASE 0x16A000
--
2.28.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 08/24] drm/i915/dg1: Add and setup DPLLs for DG1
From: Aditya Swarup
Add entries for dg1 plls and setup dg1_pll_mgr to reuse ICL callbacks.
Initial setup for shared dplls DPLL0/1 for DDIA/DDIB and DPLL2/3 for
DDI-TC1/DDI-TC2. Configure dpll cfgcrx registers to drive the plls on
DG1.
v2 (Lucas): Reword commit message and add missing update_ref_clks hook
(requested by Matt Roper)
Signed-off-by: Aditya Swarup
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 42 +--
1 file changed, 38 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
index e08684e34078..d41914b73d88 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
@@ -3524,7 +3524,17 @@ static bool icl_get_combo_phy_dpll(struct
intel_atomic_state *state,
icl_calc_dpll_state(dev_priv, &pll_params, &port_dpll->hw_state);
- if (IS_ROCKETLAKE(dev_priv)) {
+ if (IS_DG1(dev_priv)) {
+ if (port == PORT_D || port == PORT_E) {
+ dpll_mask =
+ BIT(DPLL_ID_DG1_DPLL2) |
+ BIT(DPLL_ID_DG1_DPLL3);
+ } else {
+ dpll_mask =
+ BIT(DPLL_ID_DG1_DPLL0) |
+ BIT(DPLL_ID_DG1_DPLL1);
+ }
+ } else if (IS_ROCKETLAKE(dev_priv)) {
dpll_mask =
BIT(DPLL_ID_EHL_DPLL4) |
BIT(DPLL_ID_ICL_DPLL1) |
@@ -3820,7 +3830,10 @@ static bool icl_pll_get_hw_state(struct drm_i915_private
*dev_priv,
if (!(val & PLL_ENABLE))
goto out;
- if (IS_ROCKETLAKE(dev_priv)) {
+ if (IS_DG1(dev_priv)) {
+ hw_state->cfgcr0 = intel_de_read(dev_priv, DG1_DPLL_CFGCR0(id));
+ hw_state->cfgcr1 = intel_de_read(dev_priv, DG1_DPLL_CFGCR1(id));
+ } else if (IS_ROCKETLAKE(dev_priv)) {
hw_state->cfgcr0 = intel_de_read(dev_priv,
RKL_DPLL_CFGCR0(id));
hw_state->cfgcr1 = intel_de_read(dev_priv,
@@ -3873,7 +3886,10 @@ static void icl_dpll_write(struct drm_i915_private
*dev_priv,
const enum intel_dpll_id id = pll->info->id;
i915_reg_t cfgcr0_reg, cfgcr1_reg;
- if (IS_ROCKETLAKE(dev_priv)) {
+ if (IS_DG1(dev_priv)) {
+ cfgcr0_reg = DG1_DPLL_CFGCR0(id);
+ cfgcr1_reg = DG1_DPLL_CFGCR1(id);
+ } else if (IS_ROCKETLAKE(dev_priv)) {
cfgcr0_reg = RKL_DPLL_CFGCR0(id);
cfgcr1_reg = RKL_DPLL_CFGCR1(id);
} else if (INTEL_GEN(dev_priv) >= 12) {
@@ -4317,6 +4333,22 @@ static const struct intel_dpll_mgr rkl_pll_mgr = {
.dump_hw_state = icl_dump_hw_state,
};
+static const struct dpll_info dg1_plls[] = {
+ { "DPLL 0", &combo_pll_funcs, DPLL_ID_DG1_DPLL0, 0 },
+ { "DPLL 1", &combo_pll_funcs, DPLL_ID_DG1_DPLL1, 0 },
+ { "DPLL 2", &combo_pll_funcs, DPLL_ID_DG1_DPLL2, 0 },
+ { "DPLL 3", &combo_pll_funcs, DPLL_ID_DG1_DPLL3, 0 },
+ { },
+};
+
+static const struct intel_dpll_mgr dg1_pll_mgr = {
+ .dpll_info = dg1_plls,
+ .get_dplls = icl_get_dplls,
+ .put_dplls = icl_put_dplls,
+ .update_ref_clks = icl_update_dpll_ref_clks,
+ .dump_hw_state = icl_dump_hw_state,
+};
+
/**
* intel_shared_dpll_init - Initialize shared DPLLs
* @dev: drm device
@@ -4330,7 +4362,9 @@ void intel_shared_dpll_init(struct drm_device *dev)
const struct dpll_info *dpll_info;
int i;
- if (IS_ROCKETLAKE(dev_priv))
+ if (IS_DG1(dev_priv))
+ dpll_mgr = &dg1_pll_mgr;
+ else if (IS_ROCKETLAKE(dev_priv))
dpll_mgr = &rkl_pll_mgr;
else if (INTEL_GEN(dev_priv) >= 12)
dpll_mgr = &tgl_pll_mgr;
--
2.28.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 11/24] drm/i915/dg1: invert HPD pins
From: Clinton A Taylor
HPD pins are inverted for DG1 platform.
Bspec: 49956
Cc: José Roberto de Souza
Cc: Matt Roper
Signed-off-by: Clinton A Taylor
Reviewed-by: Lucas De Marchi
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/i915_irq.c | 9 +
drivers/gpu/drm/i915/i915_reg.h | 4
2 files changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 0d6e4894b505..d76974d957b3 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -3288,6 +3288,15 @@ static void jsp_hpd_irq_setup(struct drm_i915_private
*dev_priv)
static void dg1_hpd_irq_setup(struct drm_i915_private *dev_priv)
{
+ u32 val;
+
+ val = I915_READ(SOUTH_CHICKEN1);
+ val |= (INVERT_DDIA_HPD |
+ INVERT_DDIB_HPD |
+ INVERT_DDIC_HPD |
+ INVERT_DDID_HPD);
+ I915_WRITE(SOUTH_CHICKEN1, val);
+
icp_hpd_irq_setup(dev_priv,
DG1_DDI_HPD_ENABLE_MASK, 0);
}
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 310bc568a966..d3600a9e6370 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8694,6 +8694,10 @@ enum {
#define SOUTH_CHICKEN1 _MMIO(0xc2000)
#define FDIA_PHASE_SYNC_SHIFT_OVR 19
#define FDIA_PHASE_SYNC_SHIFT_EN 18
+#define INVERT_DDID_HPD (1 << 18)
+#define INVERT_DDIC_HPD (1 << 17)
+#define INVERT_DDIB_HPD (1 << 16)
+#define INVERT_DDIA_HPD (1 << 15)
#define FDI_PHASE_SYNC_OVR(pipe) (1 << (FDIA_PHASE_SYNC_SHIFT_OVR - ((pipe) *
2)))
#define FDI_PHASE_SYNC_EN(pipe) (1 << (FDIA_PHASE_SYNC_SHIFT_EN - ((pipe) *
2)))
#define FDI_BC_BIFURCATION_SELECT (1 << 12)
--
2.28.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 20/24] drm/i915/dg1: Load DMC
From: Matt Atwood
Add support to load DMC v2.0.2 on DG1
While we're at it, make TGL use the same GEN12 firmware size definition
and remove obsolete comment.
Bpec: 49230
v2: do not replace GEN12_CSR_MAX_FW_SIZE (from José)
and replace stale comment
Cc: Matt Roper
Signed-off-by: Matt Atwood
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/display/intel_csr.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_csr.c
b/drivers/gpu/drm/i915/display/intel_csr.c
index d5db16764619..67dc64df78a5 100644
--- a/drivers/gpu/drm/i915/display/intel_csr.c
+++ b/drivers/gpu/drm/i915/display/intel_csr.c
@@ -40,13 +40,16 @@
#define GEN12_CSR_MAX_FW_SIZE ICL_CSR_MAX_FW_SIZE
+#define DG1_CSR_PATH "i915/dg1_dmc_ver2_02.bin"
+#define DG1_CSR_VERSION_REQUIRED CSR_VERSION(2, 2)
+MODULE_FIRMWARE(DG1_CSR_PATH);
+
#define RKL_CSR_PATH "i915/rkl_dmc_ver2_02.bin"
#define RKL_CSR_VERSION_REQUIRED CSR_VERSION(2, 2)
MODULE_FIRMWARE(RKL_CSR_PATH);
#define TGL_CSR_PATH "i915/tgl_dmc_ver2_08.bin"
#define TGL_CSR_VERSION_REQUIRED CSR_VERSION(2, 8)
-#define TGL_CSR_MAX_FW_SIZE0x6000
MODULE_FIRMWARE(TGL_CSR_PATH);
#define ICL_CSR_PATH "i915/icl_dmc_ver1_09.bin"
@@ -686,14 +689,17 @@ void intel_csr_ucode_init(struct drm_i915_private
*dev_priv)
*/
intel_csr_runtime_pm_get(dev_priv);
- if (IS_ROCKETLAKE(dev_priv)) {
+ if (IS_DG1(dev_priv)) {
+ csr->fw_path = DG1_CSR_PATH;
+ csr->required_version = DG1_CSR_VERSION_REQUIRED;
+ csr->max_fw_size = GEN12_CSR_MAX_FW_SIZE;
+ } else if (IS_ROCKETLAKE(dev_priv)) {
csr->fw_path = RKL_CSR_PATH;
csr->required_version = RKL_CSR_VERSION_REQUIRED;
csr->max_fw_size = GEN12_CSR_MAX_FW_SIZE;
} else if (INTEL_GEN(dev_priv) >= 12) {
csr->fw_path = TGL_CSR_PATH;
csr->required_version = TGL_CSR_VERSION_REQUIRED;
- /* Allow to load fw via parameter using the last known size */
csr->max_fw_size = GEN12_CSR_MAX_FW_SIZE;
} else if (IS_GEN(dev_priv, 11)) {
csr->fw_path = ICL_CSR_PATH;
--
2.28.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 14/24] drm/i915/dg1: Don't program PHY_MISC for PHY-C and PHY-D
From: Matt Roper The only bit we use in PHY_MISC is DE_IO_COMP_PWR_DOWN, and the bspec details for that bit tell us that it need only be set for PHY-A and PHY-B. It also turns out that there isn't even an instance of the PHY_MISC register for PHY-D on this platform. Let's extend the EHL/RKL logic that conditionally skips PHY_MISC usage to DG1 as well. Bspec: 50107 Cc: Aditya Swarup Cc: Clinton Taylor Signed-off-by: Matt Roper Signed-off-by: Lucas De Marchi Reviewed-by: Anusha Srivatsa --- drivers/gpu/drm/i915/display/intel_combo_phy.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_combo_phy.c b/drivers/gpu/drm/i915/display/intel_combo_phy.c index 157d8c8c605a..07c9fa2fb835 100644 --- a/drivers/gpu/drm/i915/display/intel_combo_phy.c +++ b/drivers/gpu/drm/i915/display/intel_combo_phy.c @@ -189,7 +189,8 @@ static bool has_phy_misc(struct drm_i915_private *i915, enum phy phy) * other combo PHY's. */ if (IS_ELKHARTLAKE(i915) || - IS_ROCKETLAKE(i915)) + IS_ROCKETLAKE(i915) || + IS_DG1(i915)) return phy < PHY_C; return true; -- 2.28.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 15/24] drm/i915/dg1: Update comp master/slave relationships for PHYs
From: Matt Roper As with RKL, DG1's PHY C acts as a comp master for PHY D. Bspec: 49291 Signed-off-by: Matt Roper Signed-off-by: Lucas De Marchi Reviewed-by: Anusha Srivatsa --- drivers/gpu/drm/i915/display/intel_combo_phy.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_combo_phy.c b/drivers/gpu/drm/i915/display/intel_combo_phy.c index 07c9fa2fb835..932265f1ac90 100644 --- a/drivers/gpu/drm/i915/display/intel_combo_phy.c +++ b/drivers/gpu/drm/i915/display/intel_combo_phy.c @@ -243,14 +243,14 @@ static bool phy_is_master(struct drm_i915_private *dev_priv, enum phy phy) * * ICL,TGL: * A(master) -> B(slave), C(slave) -* RKL: +* RKL,DG1: * A(master) -> B(slave) * C(master) -> D(slave) * * We must set the IREFGEN bit for any PHY acting as a master * to another PHY. */ - if (IS_ROCKETLAKE(dev_priv) && phy == PHY_C) + if ((IS_DG1(dev_priv) || IS_ROCKETLAKE(dev_priv)) && phy == PHY_C) return true; return phy == PHY_A; -- 2.28.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 22/24] drm/i915/dg1: DG1 does not support DC6
From: Anshuman Gupta
DC6 is not supported on DG1, so change the allowed DC mask for DG1.
Cc: Uma Shankar
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_display_power.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 0827e68a9d89..7dfc697ccf78 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -4689,7 +4689,10 @@ static u32 get_allowed_dc_mask(const struct
drm_i915_private *dev_priv,
int max_dc;
if (INTEL_GEN(dev_priv) >= 12) {
- max_dc = 4;
+ if (IS_DG1(dev_priv))
+ max_dc = 3;
+ else
+ max_dc = 4;
/*
* DC9 has a separate HW flow from the rest of the DC states,
* not depending on the DMC firmware. It's needed by system
--
2.28.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 03/24] drm/i915/dg1: Define MOCS table for DG1
DG1 has a new MOCS table. We still use the old definition of the table,
but as for any dgfx card it doesn't contain the control_value values
(these values don't matter as we won't program them).
Bspec: 45101
v2: Reword the comment to state that the last few entries are reserved
instead of "the last two". DG1 reserves four instead of two from
previous platforms (from Matt Roper)
Cc: Daniele Ceraolo Spurio
Cc: Rodrigo Vivi
Signed-off-by: Lucas De Marchi
Reviewed-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_mocs.c | 41 ++--
1 file changed, 39 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.c
b/drivers/gpu/drm/i915/gt/intel_mocs.c
index 632e08a4592b..8d0614d547bf 100644
--- a/drivers/gpu/drm/i915/gt/intel_mocs.c
+++ b/drivers/gpu/drm/i915/gt/intel_mocs.c
@@ -109,7 +109,7 @@ struct drm_i915_mocs_table {
* they will be initialized to PTE. Gen >= 12 onwards don't have a setting for
* PTE and will be initialized to an invalid value.
*
- * The last two entries are reserved by the hardware. For ICL+ they
+ * The last few entries are reserved by the hardware. For ICL+ they
* should be initialized according to bspec and never used, for older
* platforms they should never be written to.
*
@@ -280,6 +280,39 @@ static const struct drm_i915_mocs_entry icl_mocs_table[] =
{
GEN11_MOCS_ENTRIES
};
+static const struct drm_i915_mocs_entry dg1_mocs_table[] = {
+ /* Error */
+ MOCS_ENTRY(0, 0, L3_0_DIRECT),
+
+ /* UC */
+ MOCS_ENTRY(1, 0, L3_1_UC),
+
+ /* Reserved */
+ MOCS_ENTRY(2, 0, L3_0_DIRECT),
+ MOCS_ENTRY(3, 0, L3_0_DIRECT),
+ MOCS_ENTRY(4, 0, L3_0_DIRECT),
+
+ /* WB - L3 */
+ MOCS_ENTRY(5, 0, L3_3_WB),
+ /* WB - L3 50% */
+ MOCS_ENTRY(6, 0, L3_ESC(1) | L3_SCC(1) | L3_3_WB),
+ /* WB - L3 25% */
+ MOCS_ENTRY(7, 0, L3_ESC(1) | L3_SCC(3) | L3_3_WB),
+ /* WB - L3 12.5% */
+ MOCS_ENTRY(8, 0, L3_ESC(1) | L3_SCC(7) | L3_3_WB),
+
+ /* HDC:L1 + L3 */
+ MOCS_ENTRY(48, 0, L3_3_WB),
+ /* HDC:L1 */
+ MOCS_ENTRY(49, 0, L3_1_UC),
+
+ /* HW Reserved */
+ MOCS_ENTRY(60, 0, L3_1_UC),
+ MOCS_ENTRY(61, 0, L3_1_UC),
+ MOCS_ENTRY(62, 0, L3_1_UC),
+ MOCS_ENTRY(63, 0, L3_1_UC),
+};
+
enum {
HAS_GLOBAL_MOCS = BIT(0),
HAS_ENGINE_MOCS = BIT(1),
@@ -306,7 +339,11 @@ static unsigned int get_mocs_settings(const struct
drm_i915_private *i915,
{
unsigned int flags;
- if (INTEL_GEN(i915) >= 12) {
+ if (IS_DG1(i915)) {
+ table->size = ARRAY_SIZE(dg1_mocs_table);
+ table->table = dg1_mocs_table;
+ table->n_entries = GEN11_NUM_MOCS_ENTRIES;
+ } else if (INTEL_GEN(i915) >= 12) {
table->size = ARRAY_SIZE(tgl_mocs_table);
table->table = tgl_mocs_table;
table->n_entries = GEN11_NUM_MOCS_ENTRIES;
--
2.28.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 16/24] drm/i915/dg1: Update voltage swing tables for DP
From: Matt Roper
DG1's vswing tables are the same for eDP and HDMI but have slight
differences from ICL/TGL for DP.
Bspec: 49291
Cc: Clinton Taylor
Cc: José Roberto de Souza
Cc: Radhakrishna Sripada
Signed-off-by: Matt Roper
Signed-off-by: Lucas De Marchi
Reviewed-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_ddi.c | 34
1 file changed, 34 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 4d06178cd76c..866714b34c6b 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -582,6 +582,34 @@ static const struct cnl_ddi_buf_trans
ehl_combo_phy_ddi_translations_dp[] = {
{ 0x6, 0x7F, 0x3F, 0x00, 0x00 },/* 900 900 0.0 */
};
+static const struct cnl_ddi_buf_trans dg1_combo_phy_ddi_translations_dp_hbr[]
= {
+ /* NT mV Trans mV db*/
+ { 0xA, 0x32, 0x3F, 0x00, 0x00 },/* 350 350 0.0 */
+ { 0xA, 0x48, 0x35, 0x00, 0x0A },/* 350 500 3.1 */
+ { 0xC, 0x63, 0x2F, 0x00, 0x10 },/* 350 700 6.0 */
+ { 0x6, 0x7F, 0x2C, 0x00, 0x13 },/* 350 900 8.2 */
+ { 0xA, 0x43, 0x3F, 0x00, 0x00 },/* 500 500 0.0 */
+ { 0xC, 0x60, 0x36, 0x00, 0x09 },/* 500 700 2.9 */
+ { 0x6, 0x7F, 0x30, 0x00, 0x0F },/* 500 900 5.1 */
+ { 0xC, 0x60, 0x3F, 0x00, 0x00 },/* 650 700 0.6 */
+ { 0x6, 0x7F, 0x37, 0x00, 0x08 },/* 600 900 3.5 */
+ { 0x6, 0x7F, 0x3F, 0x00, 0x00 },/* 900 900 0.0 */
+};
+
+static const struct cnl_ddi_buf_trans dg1_combo_phy_ddi_translations_dp_hbr2[]
= {
+ /* NT mV Trans mV db*/
+ { 0xA, 0x32, 0x3F, 0x00, 0x00 },/* 350 350 0.0 */
+ { 0xA, 0x48, 0x35, 0x00, 0x0A },/* 350 500 3.1 */
+ { 0xC, 0x63, 0x2F, 0x00, 0x10 },/* 350 700 6.0 */
+ { 0x6, 0x7F, 0x2C, 0x00, 0x13 },/* 350 900 8.2 */
+ { 0xA, 0x43, 0x3F, 0x00, 0x00 },/* 500 500 0.0 */
+ { 0xC, 0x60, 0x36, 0x00, 0x09 },/* 500 700 2.9 */
+ { 0x6, 0x7F, 0x30, 0x00, 0x0F },/* 500 900 5.1 */
+ { 0xC, 0x58, 0x3F, 0x00, 0x00 },/* 650 700 0.6 */
+ { 0x6, 0x7F, 0x35, 0x00, 0x0A },/* 600 900 3.5 */
+ { 0x6, 0x7F, 0x3F, 0x00, 0x00 },/* 900 900 0.0 */
+};
+
struct icl_mg_phy_ddi_buf_trans {
u32 cri_txdeemph_override_11_6;
u32 cri_txdeemph_override_5_0;
@@ -1048,6 +1076,12 @@ icl_get_combo_buf_trans(struct intel_encoder *encoder,
int type, int rate,
} else if (type == INTEL_OUTPUT_EDP && dev_priv->vbt.edp.low_vswing) {
*n_entries =
ARRAY_SIZE(icl_combo_phy_ddi_translations_edp_hbr2);
return icl_combo_phy_ddi_translations_edp_hbr2;
+ } else if (IS_DG1(dev_priv) && rate > 27) {
+ *n_entries = ARRAY_SIZE(dg1_combo_phy_ddi_translations_dp_hbr2);
+ return dg1_combo_phy_ddi_translations_dp_hbr2;
+ } else if (IS_DG1(dev_priv)) {
+ *n_entries = ARRAY_SIZE(dg1_combo_phy_ddi_translations_dp_hbr);
+ return dg1_combo_phy_ddi_translations_dp_hbr;
}
*n_entries = ARRAY_SIZE(icl_combo_phy_ddi_translations_dp_hbr2);
--
2.28.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 23/24] drm/i915/dg1: Change DMC_DEBUG{1, 2} registers
From: Anshuman Gupta
DGFX devices have different DMC_DEBUG* counter MMIO address
offset. Incorporate these changes in i915_reg.h for DG1
and handle i915_dmc_info accordingly.
Cc: Uma Shankar
Signed-off-by: Anshuman Gupta
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/display/intel_display_debugfs.c | 9 +++--
drivers/gpu/drm/i915/i915_reg.h | 1 +
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index 0bf31f9a8af5..472f119fe246 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -518,8 +518,13 @@ static int i915_dmc_info(struct seq_file *m, void *unused)
CSR_VERSION_MINOR(csr->version));
if (INTEL_GEN(dev_priv) >= 12) {
- dc5_reg = TGL_DMC_DEBUG_DC5_COUNT;
- dc6_reg = TGL_DMC_DEBUG_DC6_COUNT;
+ if (IS_DG1(dev_priv)) {
+ dc5_reg = DG1_DMC_DEBUG_DC5_COUNT;
+ } else {
+ dc5_reg = TGL_DMC_DEBUG_DC5_COUNT;
+ dc6_reg = TGL_DMC_DEBUG_DC6_COUNT;
+ }
+
/*
* NOTE: DMC_DEBUG3 is a general purpose reg.
* According to B.Specs:49196 DMC f/w reuses DC5/6 counter
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index bb5094b80f15..b856a1fb0a32 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7538,6 +7538,7 @@ enum {
#define BXT_CSR_DC3_DC5_COUNT _MMIO(0x80038)
#define TGL_DMC_DEBUG_DC5_COUNT_MMIO(0x101084)
#define TGL_DMC_DEBUG_DC6_COUNT_MMIO(0x101088)
+#define DG1_DMC_DEBUG_DC5_COUNT_MMIO(0x134154)
#define DMC_DEBUG3 _MMIO(0x101090)
--
2.28.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 10/24] drm/i915/dg1: add hpd interrupt handling
DG1 has one more combo phy port, no TC and all irq handling goes through
SDE, like for MCC.
v2: Also change intel_hpd_pin_default() to include DG1 mapping
v3: Rebase on hpd refactor
Cc: Ville Syrjälä
Cc: Anshuman Gupta
Cc: José Roberto de Souza
Cc: Imre Deak
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/i915_irq.c | 58 +
drivers/gpu/drm/i915/i915_reg.h | 8 +
2 files changed, 59 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index b753c77c9a77..0d6e4894b505 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -152,6 +152,13 @@ static const u32 hpd_icp[HPD_NUM_PINS] = {
[HPD_PORT_TC6] = SDE_TC_HOTPLUG_ICP(PORT_TC6),
};
+static const u32 hpd_dg1_sde[HPD_NUM_PINS] = {
+ [HPD_PORT_A] = SDE_DDI_HOTPLUG_ICP(PHY_A),
+ [HPD_PORT_B] = SDE_DDI_HOTPLUG_ICP(PHY_B),
+ [HPD_PORT_D] = SDE_DDI_HOTPLUG_ICP(PHY_C),
+ [HPD_PORT_E] = SDE_DDI_HOTPLUG_ICP(PHY_D),
+};
+
static void intel_hpd_init_pins(struct drm_i915_private *dev_priv)
{
struct i915_hotplug *hpd = &dev_priv->hotplug;
@@ -176,11 +183,14 @@ static void intel_hpd_init_pins(struct drm_i915_private
*dev_priv)
else
hpd->hpd = hpd_ilk;
- if (!HAS_PCH_SPLIT(dev_priv) || HAS_PCH_NOP(dev_priv))
+ if ((INTEL_PCH_TYPE(dev_priv) < PCH_DG1) &&
+ (!HAS_PCH_SPLIT(dev_priv) || HAS_PCH_NOP(dev_priv)))
return;
- if (HAS_PCH_TGP(dev_priv) || HAS_PCH_JSP(dev_priv) ||
- HAS_PCH_ICP(dev_priv) || HAS_PCH_MCC(dev_priv))
+ if (HAS_PCH_DG1(dev_priv))
+ hpd->pch_hpd = hpd_dg1_sde;
+ else if (HAS_PCH_TGP(dev_priv) || HAS_PCH_JSP(dev_priv) ||
+HAS_PCH_ICP(dev_priv) || HAS_PCH_MCC(dev_priv))
hpd->pch_hpd = hpd_icp;
else if (HAS_PCH_CNP(dev_priv) || HAS_PCH_SPT(dev_priv))
hpd->pch_hpd = hpd_spt;
@@ -1079,6 +1089,22 @@ static bool icp_ddi_port_hotplug_long_detect(enum
hpd_pin pin, u32 val)
}
}
+static bool dg1_ddi_port_hotplug_long_detect(enum hpd_pin pin, u32 val)
+{
+ switch (pin) {
+ case HPD_PORT_A:
+ return val & SHOTPLUG_CTL_DDI_HPD_LONG_DETECT(PORT_A);
+ case HPD_PORT_B:
+ return val & SHOTPLUG_CTL_DDI_HPD_LONG_DETECT(PORT_B);
+ case HPD_PORT_D:
+ return val & SHOTPLUG_CTL_DDI_HPD_LONG_DETECT(PORT_C);
+ case HPD_PORT_E:
+ return val & SHOTPLUG_CTL_DDI_HPD_LONG_DETECT(PORT_D);
+ default:
+ return false;
+ }
+}
+
static bool icp_tc_port_hotplug_long_detect(enum hpd_pin pin, u32 val)
{
switch (pin) {
@@ -1863,12 +1889,19 @@ static void icp_irq_handler(struct drm_i915_private
*dev_priv, u32 pch_iir)
{
u32 ddi_hotplug_trigger, tc_hotplug_trigger;
u32 pin_mask = 0, long_mask = 0;
+ bool (*ddi_port_hotplug_long_detect)(enum hpd_pin pin, u32 val);
- if (HAS_PCH_TGP(dev_priv)) {
+ if (HAS_PCH_DG1(dev_priv)) {
+ ddi_hotplug_trigger = pch_iir & SDE_DDI_MASK_DG1;
+ ddi_port_hotplug_long_detect = dg1_ddi_port_hotplug_long_detect;
+ tc_hotplug_trigger = 0;
+ } else if (HAS_PCH_TGP(dev_priv)) {
ddi_hotplug_trigger = pch_iir & SDE_DDI_MASK_TGP;
+ ddi_port_hotplug_long_detect = icp_ddi_port_hotplug_long_detect;
tc_hotplug_trigger = pch_iir & SDE_TC_MASK_TGP;
} else if (HAS_PCH_JSP(dev_priv)) {
ddi_hotplug_trigger = pch_iir & SDE_DDI_MASK_TGP;
+ ddi_port_hotplug_long_detect = icp_ddi_port_hotplug_long_detect;
tc_hotplug_trigger = 0;
} else if (HAS_PCH_MCC(dev_priv)) {
ddi_hotplug_trigger = pch_iir & SDE_DDI_MASK_ICP;
@@ -1879,6 +1912,7 @@ static void icp_irq_handler(struct drm_i915_private
*dev_priv, u32 pch_iir)
INTEL_PCH_TYPE(dev_priv));
ddi_hotplug_trigger = pch_iir & SDE_DDI_MASK_ICP;
+ ddi_port_hotplug_long_detect = icp_ddi_port_hotplug_long_detect;
tc_hotplug_trigger = pch_iir & SDE_TC_MASK_ICP;
}
@@ -1891,7 +1925,7 @@ static void icp_irq_handler(struct drm_i915_private
*dev_priv, u32 pch_iir)
intel_get_hpd_pins(dev_priv, &pin_mask, &long_mask,
ddi_hotplug_trigger, dig_hotplug_reg,
dev_priv->hotplug.pch_hpd,
- icp_ddi_port_hotplug_long_detect);
+ ddi_port_hotplug_long_detect);
}
if (tc_hotplug_trigger) {
@@ -3252,6 +3286,12 @@ static void jsp_hpd_irq_setup(struct drm_i915_private
*dev_priv)
TGP_DDI_HPD_ENABLE_MASK, 0);
}
+static void dg1_hpd_irq_setup(struct drm_i915_private *dev_priv)
+{
+ icp_hpd_irq_setup(dev_priv,
+
[Intel-gfx] [PATCH v6 24/24] drm/i915/dgfx: define llc and snooping behaviour
From: Michel Thierry
While we do lack the faster shared LLC, we should still have support
for snooping over PCIe.
Signed-off-by: Michel Thierry
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_pci.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index c2dfdf52419b..95f281b48c64 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -900,6 +900,8 @@ static const struct intel_device_info rkl_info = {
GEN12_FEATURES, \
.memory_regions = REGION_SMEM | REGION_LMEM, \
.has_master_unit_irq = 1, \
+ .has_llc = 0, \
+ .has_snoop = 1, \
.is_dgfx = 1
static const struct intel_device_info dg1_info __maybe_unused = {
--
2.28.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 01/24] drm/i915/dg1: add more PCI ids
Synchronize with the current list of DG1 PCI IDs. Signed-off-by: Lucas De Marchi --- include/drm/i915_pciids.h | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h index 7eeecb07c9a1..095463ff7cb9 100644 --- a/include/drm/i915_pciids.h +++ b/include/drm/i915_pciids.h @@ -624,6 +624,9 @@ /* DG1 */ #define INTEL_DG1_IDS(info) \ - INTEL_VGA_DEVICE(0x4905, info) + INTEL_VGA_DEVICE(0x4905, info), \ + INTEL_VGA_DEVICE(0x4906, info), \ + INTEL_VGA_DEVICE(0x4907, info), \ + INTEL_VGA_DEVICE(0x4908, info) #endif /* _I915_PCIIDS_H */ -- 2.28.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 06/24] drm/i915/dg1: Wait for pcode/uncore handshake at startup
From: Matt Roper
DG1 does some additional pcode/uncore handshaking at
boot time; this handshaking must complete before various other pcode
commands are effective and before general work is submitted to the GPU.
We need to poll a new pcode mailbox during startup until it reports that
this handshaking is complete.
The bspec doesn't give guidance on how long we may need to wait for this
handshaking to complete. For now, let's just set a really long timeout;
if we still don't get a completion status by the end of that timeout,
we'll just continue on and hope for the best.
v2 (Lucas): Rename macros to make clear the relation between command and
result (requested by José)
Bspec: 52065
Cc: Clinton Taylor
Cc: Ville Syrjälä
Cc: Radhakrishna Sripada
Signed-off-by: Matt Roper
Signed-off-by: Lucas De Marchi
Reviewed-by: José Roberto de Souza
---
drivers/gpu/drm/i915/i915_drv.c | 3 +++
drivers/gpu/drm/i915/i915_reg.h | 3 +++
drivers/gpu/drm/i915/intel_sideband.c | 15 +++
drivers/gpu/drm/i915/intel_sideband.h | 2 ++
4 files changed, 23 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 45e719c79183..a9f4e331a4fb 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -84,6 +84,7 @@
#include "intel_gvt.h"
#include "intel_memory_region.h"
#include "intel_pm.h"
+#include "intel_sideband.h"
#include "vlv_suspend.h"
static struct drm_driver driver;
@@ -616,6 +617,8 @@ static int i915_driver_hw_probe(struct drm_i915_private
*dev_priv)
*/
intel_dram_detect(dev_priv);
+ intel_pcode_init(dev_priv);
+
intel_bw_init_hw(dev_priv);
return 0;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 47730a176698..8582dbe6ef69 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -9224,6 +9224,9 @@ enum {
#define GEN9_SAGV_DISABLE 0x0
#define GEN9_SAGV_IS_DISABLED 0x1
#define GEN9_SAGV_ENABLE 0x3
+#define DG1_PCODE_STATUS 0x7E
+#define DG1_UNCORE_GET_INIT_STATUS 0x0
+#define DG1_UNCORE_INIT_STATUS_COMPLETE0x1
#define GEN12_PCODE_READ_SAGV_BLOCK_TIME_US0x23
#define GEN6_PCODE_DATA_MMIO(0x138128)
#define GEN6_PCODE_FREQ_IA_RATIO_SHIFT 8
diff --git a/drivers/gpu/drm/i915/intel_sideband.c
b/drivers/gpu/drm/i915/intel_sideband.c
index 5b3279262123..02ebf5a04a9b 100644
--- a/drivers/gpu/drm/i915/intel_sideband.c
+++ b/drivers/gpu/drm/i915/intel_sideband.c
@@ -555,3 +555,18 @@ int skl_pcode_request(struct drm_i915_private *i915, u32
mbox, u32 request,
return ret ? ret : status;
#undef COND
}
+
+void intel_pcode_init(struct drm_i915_private *i915)
+{
+ int ret;
+
+ if (!IS_DGFX(i915))
+ return;
+
+ ret = skl_pcode_request(i915, DG1_PCODE_STATUS,
+ DG1_UNCORE_GET_INIT_STATUS,
+ DG1_UNCORE_INIT_STATUS_COMPLETE,
+ DG1_UNCORE_INIT_STATUS_COMPLETE, 50);
+ if (ret)
+ drm_err(&i915->drm, "Pcode did not report uncore initialization
completion!\n");
+}
diff --git a/drivers/gpu/drm/i915/intel_sideband.h
b/drivers/gpu/drm/i915/intel_sideband.h
index 7fb95745a444..094c7b19c5d4 100644
--- a/drivers/gpu/drm/i915/intel_sideband.h
+++ b/drivers/gpu/drm/i915/intel_sideband.h
@@ -138,4 +138,6 @@ int sandybridge_pcode_write_timeout(struct drm_i915_private
*i915, u32 mbox,
int skl_pcode_request(struct drm_i915_private *i915, u32 mbox, u32 request,
u32 reply_mask, u32 reply, int timeout_base_ms);
+void intel_pcode_init(struct drm_i915_private *i915);
+
#endif /* _INTEL_SIDEBAND_H */
--
2.28.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 19/24] drm/i915/dg1: enable PORT C/D aka D/E
For DG1 we have a little of mix up wrt to DDI/port names and indexes.
Bspec refers to the ports as DDIA, DDIB, DDI USBC1 and DDI USBC2
(besides the DDIA, DDIB, DDIC, DDID), but the previous naming is the
most unambiguous one. This means that for any register on Display Engine
we should use the index of A, B, D and E. However in some places this is
not true:
- VBT: uses C and D and have to be mapped to D/E
- IO/Combo: uses C and D, but we already differentiate those when
we created the phy vs port distinction.
Ths additional mapping for VBT and phy are already covered in previous
patches, so now we can initialize the DDI as D/E.
Cc: Clinton Taylor
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/display/intel_display.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 43fe5867a8ae..6a63fb0136d4 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -7332,10 +7332,7 @@ bool intel_phy_is_combo(struct drm_i915_private
*dev_priv, enum phy phy)
{
if (phy == PHY_NONE)
return false;
- else if (IS_DG1(dev_priv))
- /* FIXME: Enable only two ports for now */
- return phy <= PHY_B;
- else if (IS_ROCKETLAKE(dev_priv))
+ else if (IS_DG1(dev_priv) || IS_ROCKETLAKE(dev_priv))
return phy <= PHY_D;
else if (IS_ELKHARTLAKE(dev_priv))
return phy <= PHY_C;
@@ -7359,7 +7356,7 @@ bool intel_phy_is_tc(struct drm_i915_private *dev_priv,
enum phy phy)
enum phy intel_port_to_phy(struct drm_i915_private *i915, enum port port)
{
- if (IS_ROCKETLAKE(i915) && port >= PORT_D)
+ if ((IS_DG1(i915) || IS_ROCKETLAKE(i915)) && port >= PORT_D)
return (enum phy)port - 1;
else if (IS_ELKHARTLAKE(i915) && port == PORT_D)
return PHY_A;
@@ -17128,9 +17125,18 @@ static void intel_setup_outputs(struct
drm_i915_private *dev_priv)
return;
if (IS_DG1(dev_priv)) {
- /* FIXME: Enable only two ports for now */
intel_ddi_init(dev_priv, PORT_A);
intel_ddi_init(dev_priv, PORT_B);
+
+ /*
+* Bspec lists the ports as A, B, C (USBC1) and D (USBC2).
+* However from the Display Engine perspective all registers are
+* actually wired to handle C and D as offsets of D/E. Instead
+* of fighting all our macros for handling them specially for
+* DG1, just call them D/E
+*/
+ intel_ddi_init(dev_priv, PORT_D);
+ intel_ddi_init(dev_priv, PORT_E);
} else if (IS_ROCKETLAKE(dev_priv)) {
intel_ddi_init(dev_priv, PORT_A);
intel_ddi_init(dev_priv, PORT_B);
--
2.28.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
