- 01 Dec, 2020 18 commits
-
-
Uma Shankar authored
Enable HDMI Colorspace for LSPCON based devices. 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. v3: Aligned colorimetry handling for lspcon as per compute_avi_infoframes, as suggested by Ville. v4: Finally fixed this with Ville's help, re-phrased the commit header and description. v5: Register HDMI colorspace for lspcon and move this to intel_dp_add_properties as we can't create property at late_register. Credits-to: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Uma Shankar <uma.shankar@intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201130204738.2443-9-uma.shankar@intel.com
-
Ville Syrjälä authored
With LSPCON we use the AVI infoframe to convey the colorimetry information (as opposed to DP MSA/SDP), so the property we expose should match the values we can stuff into the infoframe. Ie. we must use the HDMI variant of the property, even though we drive LSPCON in PCON mode. To that end just split intel_attach_colorspace_property() into HDMI and DP variants and let the caller worry about which one it wants to use. Cc: Uma Shankar <uma.shankar@intel.com> Signed-off-by:
-
Uma Shankar authored
Content type is supported on HDMI sink devices. Attached the property for the same for LSPCON based devices. v2: Added the content type programming when we are attaching the property to connector, as suggested by Ville. v3: Need to attach content type on intel_dp_add_properties as creating of new properties is not possible at late_register. Signed-off-by:
-
Uma Shankar authored
Add a WARN to rule out an invalid output range and format combination. This is to align the lspcon code with compute_avi_infoframes. Signed-off-by:
-
Uma Shankar authored
This patch fixes the quantization range for YCbCr output on Lspcon based devices. v2: Re-phrased the description and added Ville's Rb. Signed-off-by:
-
Uma Shankar authored
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. v3: Fixed the HDR property attachment logic as per the new changes by Kai-Feng to align with lspcon detection failure on some devices. v4: Add HDR proprty in late_register to handle lspcon detection, as suggested by Ville. v5: Init Lspcon only if advertized from BIOS. v6: Added a Todo to plan a cleanup later, added Ville's RB. Signed-off-by:
-
Uma Shankar authored
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. v4: Addressed Ville's review comments, removed redundant wrapper and checks, passed arguments instead of hardcodings. Signed-off-by:
-
Uma Shankar authored
LSPCON firmware exposes HDR capability through LPCON_CAPABILITIES DPCD register. LSPCON implementations capable of supporting HDR set HDR_CAPABILITY bit in LSPCON_CAPABILITIES to 1. This patch reads the same, detects the HDR capability and adds this to intel_lspcon struct. v2: Addressed Jani Nikula's review comment and fixed the HDR capability detection logic v3: Deferred HDR detection from lspcon_init (Ville) v4: Addressed Ville's minor review comments, added his RB. Signed-off-by: -
José Roberto de Souza authored
Add the calculations to set plane selective fetch registers depending in the value of the area damaged. It is still using the whole plane area as damaged but that will change in next patches. v2: - fixed new_plane_state->uapi.dst.y2 typo in intel_psr2_sel_fetch_update() - do not shifthing new_plane_state->uapi.dst only src is in 16.16 format BSpec: 55229 Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Reviewed-by:
Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Tested-by:
-
Jani Nikula authored
Arguably some of these should use intel_de_read() or intel_de_write(), however not all. Prioritize I915_READ() and I915_WRITE() removal in general over migrating to the pedantically correct replacements right away. Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201130111601.2817-8-jani.nikula@intel.com
-
Jani Nikula authored
Arguably some of these should use intel_de_read() or intel_de_write(), however not all. Prioritize I915_READ() and I915_WRITE() removal in general over migrating to the pedantically correct replacements right away. Reviewed-by:
-
Jani Nikula authored
Another straggler with I915_READ() and I915_WRITE() uses gone. Reviewed-by:
-
Jani Nikula authored
Another straggler with I915_READ() uses gone. Arguably some of these should use intel_de_read(), however not all. Prioritize I915_READ() removal in general over migrating to the pedantically correct replacement right away. Reviewed-by:
-
Jani Nikula authored
The i915_cache_sharing file is a debugfs interface for gen 6-7 with no validation or user. Remove it. This also removes the last I915_WRITE() use in i915_debugfs.c. Suggested-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
-
Jani Nikula authored
Let's try to not add new ones while we're phasing out I915_READ() and I915_WRITE(). Fixes: 27a6bc80 ("drm/i915/dg1: Initialize RAWCLK properly") Reviewed-by:
-
Jani Nikula authored
Good riddance! Remove the macros and their remaining references in comments. intel_uncore_read_fw() and intel_uncore_write_fw() should be used instead. Reviewed-by:
-
Jani Nikula authored
The information is no longer relevant, so remove it. This also removes the last users of I915_READ_FW() Cc: Chris Wilson <chris@chris-wilson.co.uk> Suggested-by:
-
Lionel Landwerlin authored
CI shows this workaround is also needed on Gen11. Signed-off-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Fixes: 059a0beb ("drm/i915/perf: workaround register corruption in OATAILPTR") Reviewed-by:
Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201126105155.540350-1-lionel.g.landwerlin@intel.com
-
- 27 Nov, 2020 3 commits
-
-
Chris Wilson authored
We know a problem exists in the ifwi shipped with the early pre-production Tigerlake and DG1 prototypes, later revisions are fine. However, CI still relies on the earlier ifwi and we grow tired of the volume of warnings as we wait for replacements. Since the warning is a bug, we do not want to lose the warning in its entirety, so only suppress the warning for the platforms currently exhibiting the issue. Suggested-by:
José Roberto de Souza <gitlab@gitlab.freedesktop.org> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2411Signed-off-by:
-
Tom Rix authored
The macro use will already have a semicolon. Signed-off-by:
Tom Rix <trix@redhat.com> Reviewed-by:
-
Chris Wilson authored
We now use ilk_hpd_irq_setup for all GMCH platforms that do not have hotplug. These are early gen3 and gen2 devices that now explode on boot as they try to access non-existent registers. Fixes: 794d61a1 ("drm/i915: re-order if/else ladder for hpd_irq_setup") Signed-off-by:
-
- 26 Nov, 2020 1 commit
-
-
Chris Wilson authored
Prior to sanitizing the GGTT, the only operations allowed in intel_display_init_nogem() are those to reserve the preallocated (and active) regions in the GGTT leftover from the BIOS. Trying to allocate a GGTT vma (such as intel_pin_and_fence_fb_obj during the initial modeset) may then conflict with other preallocated regions that have not yet been protected. Move the initial modesetting from the end of init_nogem to the beginning of init so that any vma pinning (either framebuffers or DSB, for example), is after the GGTT is ready to handle it. This will prevent the DSB object from being destroyed too early: [ 53.449241] BUG: KASAN: use-after-free in i915_init_ggtt+0x324/0x9e0 [i915] [ 53.449309] Read of size 8 at addr ffff88811b1e8070 by task systemd-udevd/345 [ 53.449399] CPU: 1 PID: 345 Comm: systemd-udevd Tainted: G W 5.10.0-rc5+ #12 [ 53.449409] Call Trace: [ 53.449418] dump_stack+0x9a/0xcc [ 53.449558] ? i915_init_ggtt+0x324/0x9e0 [i915] [ 53.449565] print_address_description.constprop.0+0x3e/0x60 [ 53.449577] ? _raw_spin_lock_irqsave+0x4e/0x50 [ 53.449718] ? i915_init_ggtt+0x324/0x9e0 [i915] [ 53.449849] ? i915_init_ggtt+0x324/0x9e0 [i915] [ 53.449857] kasan_report.cold+0x1f/0x37 [ 53.449993] ? i915_init_ggtt+0x324/0x9e0 [i915] [ 53.450130] i915_init_ggtt+0x324/0x9e0 [i915] [ 53.450273] ? i915_ggtt_suspend+0x1f0/0x1f0 [i915] [ 53.450281] ? static_obj+0x69/0x80 [ 53.450289] ? lockdep_init_map_waits+0xa9/0x310 [ 53.450431] ? intel_wopcm_init+0x96/0x3d0 [i915] [ 53.450581] ? i915_gem_init+0x75/0x2d0 [i915] [ 53.450720] i915_gem_init+0x75/0x2d0 [i915] [ 53.450852] i915_driver_probe+0x8c2/0x1210 [i915] [ 53.450993] ? i915_pm_prepare+0x630/0x630 [i915] [ 53.451006] ? check_chain_key+0x1e7/0x2e0 [ 53.451025] ? __pm_runtime_resume+0x58/0xb0 [ 53.451157] i915_pci_probe+0xa6/0x2b0 [i915] [ 53.451285] ? i915_pci_remove+0x40/0x40 [i915] [ 53.451295] ? lockdep_hardirqs_on_prepare+0x124/0x230 [ 53.451302] ? _raw_spin_unlock_irqrestore+0x42/0x50 [ 53.451309] ? lockdep_hardirqs_on+0xbf/0x130 [ 53.451315] ? preempt_count_sub+0xf/0xb0 [ 53.451321] ? _raw_spin_unlock_irqrestore+0x2f/0x50 [ 53.451335] pci_device_probe+0xf9/0x190 [ 53.451350] really_probe+0x17f/0x5b0 [ 53.451365] driver_probe_device+0x13a/0x1c0 [ 53.451376] device_driver_attach+0x82/0x90 [ 53.451386] ? device_driver_attach+0x90/0x90 [ 53.451391] __driver_attach+0xab/0x190 [ 53.451401] ? device_driver_attach+0x90/0x90 [ 53.451407] bus_for_each_dev+0xe4/0x140 [ 53.451414] ? subsys_dev_iter_exit+0x10/0x10 [ 53.451423] ? __list_add_valid+0x2b/0xa0 [ 53.451440] bus_add_driver+0x227/0x2e0 [ 53.451454] driver_register+0xd3/0x150 [ 53.451585] i915_init+0x92/0xac [i915] [ 53.451592] ? 0xffffffffa0a20000 [ 53.451598] do_one_initcall+0xb6/0x3b0 [ 53.451606] ? trace_event_raw_event_initcall_finish+0x150/0x150 [ 53.451614] ? __kasan_kmalloc.constprop.0+0xc2/0xd0 [ 53.451627] ? kmem_cache_alloc_trace+0x4a4/0x8e0 [ 53.451634] ? kasan_unpoison_shadow+0x33/0x40 [ 53.451649] do_init_module+0xf8/0x350 [ 53.451662] load_module+0x43de/0x47f0 [ 53.451716] ? module_frob_arch_sections+0x20/0x20 [ 53.451731] ? rw_verify_area+0x5f/0x130 [ 53.451780] ? __do_sys_finit_module+0x10d/0x1a0 [ 53.451785] __do_sys_finit_module+0x10d/0x1a0 [ 53.451792] ? __ia32_sys_init_module+0x40/0x40 [ 53.451800] ? seccomp_do_user_notification.isra.0+0x5c0/0x5c0 [ 53.451829] ? rcu_read_lock_bh_held+0xb0/0xb0 [ 53.451835] ? mark_held_locks+0x24/0x90 [ 53.451856] do_syscall_64+0x33/0x80 [ 53.451863] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 53.451868] RIP: 0033:0x7fde09b4470d [ 53.451875] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 53 f7 0c 00 f7 d8 64 89 01 48 [ 53.451880] RSP: 002b:00007ffd6abc1718 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 [ 53.451890] RAX: ffffffffffffffda RBX: 000056444e528150 RCX: 00007fde09b4470d [ 53.451895] RDX: 0000000000000000 RSI: 00007fde09a21ded RDI: 000000000000000f [ 53.451899] RBP: 0000000000020000 R08: 0000000000000000 R09: 0000000000000000 [ 53.451904] R10: 000000000000000f R11: 0000000000000246 R12: 00007fde09a21ded [ 53.451909] R13: 0000000000000000 R14: 000056444e329200 R15: 000056444e528150 [ 53.451957] Allocated by task 345: [ 53.451995] kasan_save_stack+0x1b/0x40 [ 53.452001] __kasan_kmalloc.constprop.0+0xc2/0xd0 [ 53.452006] kmem_cache_alloc+0x1cd/0x8d0 [ 53.452146] i915_vma_instance+0x126/0xb70 [i915] [ 53.452304] i915_gem_object_ggtt_pin_ww+0x222/0x3f0 [i915] [ 53.452446] intel_dsb_prepare+0x14f/0x230 [i915] [ 53.452588] intel_atomic_commit+0x183/0x690 [i915] [ 53.452730] intel_initial_commit+0x2bc/0x2f0 [i915] [ 53.452871] intel_modeset_init_nogem+0xa02/0x2af0 [i915] [ 53.452995] i915_driver_probe+0x8af/0x1210 [i915] [ 53.453120] i915_pci_probe+0xa6/0x2b0 [i915] [ 53.453125] pci_device_probe+0xf9/0x190 [ 53.453131] really_probe+0x17f/0x5b0 [ 53.453136] driver_probe_device+0x13a/0x1c0 [ 53.453142] device_driver_attach+0x82/0x90 [ 53.453148] __driver_attach+0xab/0x190 [ 53.453153] bus_for_each_dev+0xe4/0x140 [ 53.453158] bus_add_driver+0x227/0x2e0 [ 53.453164] driver_register+0xd3/0x150 [ 53.453286] i915_init+0x92/0xac [i915] [ 53.453292] do_one_initcall+0xb6/0x3b0 [ 53.453297] do_init_module+0xf8/0x350 [ 53.453302] load_module+0x43de/0x47f0 [ 53.453307] __do_sys_finit_module+0x10d/0x1a0 [ 53.453312] do_syscall_64+0x33/0x80 [ 53.453318] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 53.453345] Freed by task 82: [ 53.453379] kasan_save_stack+0x1b/0x40 [ 53.453384] kasan_set_track+0x1c/0x30 [ 53.453389] kasan_set_free_info+0x1b/0x30 [ 53.453394] __kasan_slab_free+0x112/0x160 [ 53.453399] kmem_cache_free+0xb2/0x3f0 [ 53.453536] i915_gem_flush_free_objects+0x31a/0x3b0 [i915] [ 53.453542] process_one_work+0x519/0x9f0 [ 53.453547] worker_thread+0x75/0x5c0 [ 53.453552] kthread+0x1da/0x230 [ 53.453557] ret_from_fork+0x22/0x30 [ 53.453584] The buggy address belongs to the object at ffff88811b1e8040 which belongs to the cache i915_vma of size 968 [ 53.453692] The buggy address is located 48 bytes inside of 968-byte region [ffff88811b1e8040, ffff88811b1e8408) [ 53.453792] The buggy address belongs to the page: [ 53.453842] page:00000000b35f7048 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88811b1ef940 pfn:0x11b1e8 [ 53.453847] head:00000000b35f7048 order:3 compound_mapcount:0 compound_pincount:0 [ 53.453853] flags: 0x8000000000010200(slab|head) [ 53.453860] raw: 8000000000010200 ffff888115596248 ffff888115596248 ffff8881155b6340 [ 53.453866] raw: ffff88811b1ef940 0000000000170001 00000001ffffffff 0000000000000000 [ 53.453870] page dumped because: kasan: bad access detected [ 53.453895] Memory state around the buggy address: [ 53.453944] ffff88811b1e7f00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 53.454011] ffff88811b1e7f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 53.454079] >ffff88811b1e8000: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb [ 53.454146] ^ [ 53.454211] ffff88811b1e8080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 53.454279] ffff88811b1e8100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 53.454347] ================================================================== [ 53.454414] Disabling lock debugging due to kernel taint [ 53.454434] general protection fault, probably for non-canonical address 0xdead0000000000d0: 0000 [#1] PREEMPT SMP KASAN PTI [ 53.454446] CPU: 1 PID: 345 Comm: systemd-udevd Tainted: G B W 5.10.0-rc5+ #12 [ 53.454592] RIP: 0010:i915_init_ggtt+0x26f/0x9e0 [i915] [ 53.454602] Code: 89 8d 48 ff ff ff 4c 8d 60 d0 49 39 c7 0f 84 37 02 00 00 4c 89 b5 40 ff ff ff 4d 8d bc 24 90 00 00 00 4c 89 ff e8 c1 97 f8 e0 <49> 83 bc 24 90 00 00 00 00 0f 84 0f 02 00 00 49 8d 7c 24 08 e8 a8 [ 53.454618] RSP: 0018:ffff88812247f430 EFLAGS: 00010286 [ 53.454625] RAX: 0000000000000000 RBX: ffff888136440000 RCX: ffffffffa03fb78f [ 53.454633] RDX: 0000000000000000 RSI: 0000000000000008 RDI: dead000000000160 [ 53.454641] RBP: ffff88812247f500 R08: ffffffff8113589f R09: 0000000000000000 [ 53.454648] R10: ffffffff83063843 R11: fffffbfff060c708 R12: dead0000000000d0 [ 53.454656] R13: ffff888136449ba0 R14: 0000000000002000 R15: dead000000000160 [ 53.454664] FS: 00007fde095c4880(0000) GS:ffff88840c880000(0000) knlGS:0000000000000000 [ 53.454672] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 53.454679] CR2: 00007fef132b4f28 CR3: 000000012245c002 CR4: 00000000003706e0 [ 53.454686] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 53.454693] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 53.454700] Call Trace: [ 53.454833] ? i915_ggtt_suspend+0x1f0/0x1f0 [i915] Reported-by:Matthew Auld <matthew.auld@intel.com> Fixes: afeda4f3 ("drm/i915/dsb: Pre allocate and late cleanup of cmd buffer") Signed-off-by:
-
- 24 Nov, 2020 1 commit
-
-
https://github.com/intel/gvt-linuxJani Nikula authored
gvt-next-2020-11-23 - Fix host suspend/resume with vGPU (Colin) - optimize idr init (Varma) - Change intel_gvt_mpt as const (Julian) - One comment error fix (Yan) Signed-off-by:
-
- 23 Nov, 2020 1 commit
-
-
Julian Stecklina authored
The current interface of intel_gvt_register_hypervisor() expects a non-const pointer to struct intel_gvt_mpt, even though the mediator never modifies (or should modifiy) the content of this struct. Change the function signature and relevant struct members to const to properly express the API's intent and allow instances of intel_gvt_mpt to be allocated as const. While I was here, I also made KVM's instance of this struct const to reduce the number of writable function pointers in the kernel. Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Cc: intel-gvt-dev@lists.freedesktop.org Reviewed-by:
Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by:
Julian Stecklina <julian.stecklina@cyberus-technology.de> Signed-off-by:
-
- 20 Nov, 2020 2 commits
-
-
Aditya Swarup authored
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. This additional mapping for VBT and phy are already covered in previous patches, so now we can initialize all the DDIs as A, B, D and E. v2: Squash previous patch enabling just ports A and B since most of the pumbling code is already merged now Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Clinton Taylor <Clinton.A.Taylor@intel.com> Signed-off-by:
Aditya Swarup <aditya.swarup@intel.com> Reviewed-by:
Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
Manasi Navare authored
This should fix the boot oops for dsi v2: * Fix indent (Manasi) v3: * Remove redundant condition (Matt Roper) Fixes: 4e3cdb45 ("drm/i915/dp: Master/Slave enable/disable sequence for bigjoiner") Signed-off-by:
Manasi Navare <manasi.d.navare@intel.com> Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201119232615.23231-1-manasi.d.navare@intel.com
-
- 19 Nov, 2020 2 commits
-
-
Chris Wilson authored
drivers/gpu/drm/i915/display/intel_display.c:3634 intel_find_initial_plane_obj() warn: inconsistent indenting drivers/gpu/drm/i915/display/intel_display.c:15367 kill_bigjoiner_slave() warn: inconsistent indenting Signed-off-by:
-
Lionel Landwerlin authored
After having written the entire OA buffer with reports, the HW will write again at the beginning of the OA buffer. It'll indicate it by setting the WRAP bits in the OASTATUS register. When a wrap happens and that at the end of the read vfunc we write the OASTATUS register back to clear the REPORT_LOST bit, we sometimes see that the OATAILPTR register is reset to a previous position on Gen8/9 (apparently not the case on Gen11+). This leads the next call to the read vfunc to process reports we've already read. Because we've marked those as read by clearing the reason & timestamp dwords, they're discarded and a "Skipping spurious, invalid OA report" message is emitted. The workaround to avoid this OATAILPTR value reset seems to be to set the wrap bits when writing back OASTATUS. This change has no impact on userspace, it only avoids a bunch of DRM_NOTE("Skipping spurious, invalid OA report\n") messages. Signed-off-by:
-
- 18 Nov, 2020 12 commits
-
-
Ville Syrjälä authored
Enough plumbing should be in place to throw the bigjoiner switch. Signed-off-by:
-
Ville Syrjälä authored
Add a big of bigjoiner information to the state dump. Signed-off-by:
-
Ville Syrjälä authored
We can't call drm_plane_state_src() this late for the slave plane since it would consult the wrong uapi state. We've alreayd done the correct uapi->hw copy earlier, so let's just preserve the unclipped src/dst rects using a temp copy across the intel_atomic_plane_check_clipping() call. Signed-off-by:
-
Ville Syrjälä authored
The legacy cursor fastpath code doesn't deal with bigjoiner. Disable the fastpath for now. Signed-off-by:
-
Maarten Lankhorst authored
Dump debugfs and planar links as well, this will make it easier to debug when things go wrong. v4: * Rebase Changes since v1: - Report planar slaves as such, now that we have the plane_state switch. Changes since v2: - Rebase on top of the new plane format dumping Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
Animesh Manna <animesh.manna@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201117194718.11462-12-manasi.d.navare@intel.com
-
Maarten Lankhorst authored
We need to look at hw.fb for the framebuffer, and add the translation for the slave_plane_state. With these changes we set the correct rectangle on the bigjoiner slave, and don't set incorrect src/dst/visibility on the slave plane. v2: * Manual rebase (Manasi) v3: * hw.rotation instead of uapi.rotation (Ville) Signed-off-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201117194718.11462-11-manasi.d.navare@intel.com
-
Ville Syrjälä authored
When using bigjoiner userspace is only controlling the "master" plane, so use its uapi state for the "slave" plane as well. hw.crtc needs a bit of magic since we don't want to copy that from the uapi state (as it points to the wrong pipe for the "slave " plane). Instead we pass the right crtc in explicitly but only assign it when the uapi state indicates the plane to be logically enabled (ie. uapi.crtc != NULL). Signed-off-by:
-
Ville Syrjälä authored
Make sure both the bigjoiner "master" and "slave" plane are in the state whenever either of them is in the state. Signed-off-by:
-
Ville Syrjälä authored
Make sure both crtcs participating in the bigjoiner stuff are in the state. Signed-off-by:
-
Manasi Navare authored
Skip iterating over bigjoiner slaves, only the master has the state we care about. Add the width of the bigjoiner slave to the reconstructed fb. Hide the bigjoiner slave to userspace, and double the mode on bigjoiner master. And last, disable bigjoiner slave from primary if reconstruction fails. v3: * Fix the ddi_get_config slave error (Ankit Nautiyal) v2: * Unsupported bigjoiner config for initial fb (Ville) Signed-off-by:
-
Manasi Navare authored
Enabling is done in a special sequence and so should plane updates be. Ideally the end user never notices the second pipe is used. This way ideally everything will be tear free, and updates are really atomic as userspace expects it. This uses generic modeset_enables() calls like trans port sync but still has special handling for disable since for slave we should not disable things like encoder, plls that are not enabled for slave. Signed-off-by:
-
Manasi Navare authored
Make vdsc work when no output is enabled. The big joiner needs VDSC on the slave, so enable it and set the appropriate bits. So remove encoder usage from dsc functions. Signed-off-by:
-
