aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/drm_dp_mst_topology.c
AgeCommit message (Collapse)AuthorFilesLines
2020-11-10Revert "drm/dp_mst: Retrieve extended DPCD caps for topology manager"Koba Ko1-4/+3
This reverts commit ad44c03208e46b83e4ae3269e32c9e524aa71cf8. Currently DRM driver assume the source device caps is higher than the MST device caps. With this commit, this statement would be broken. e.g. the source device only support DP1.2 and the mst device support DP1.4. Signed-off-by: Koba Ko <[email protected]> Reviewed-by: Lyude Paul <[email protected]> Signed-off-by: Lyude Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-11-02Merge drm/drm-next into drm-misc-nextMaxime Ripard1-0/+150
Daniel needs -rc2 in drm-misc-next to merge some patches Signed-off-by: Maxime Ripard <[email protected]>
2020-09-23Merge tag 'drm-misc-next-2020-09-21' of ↵Dave Airlie1-16/+90
git://anongit.freedesktop.org/drm/drm-misc into drm-next drm-misc-next for 5.10: UAPI Changes: Cross-subsystem Changes: - virtio: Merged a PR for patches that will affect drm/virtio Core Changes: - dev: More devm_drm convertions and removal of drm_dev_init - atomic: Split out drm_atomic_helper_calc_timestamping_constants of drm_atomic_helper_update_legacy_modeset_state - ttm: More rework Driver Changes: - i915: selftests improvements - panfrost: support for Amlogic SoC - vc4: one fix - tree-wide: conversions to devm_drm_dev_alloc, - ast: simplifications of the atomic modesetting code - panfrost: multiple fixes - vc4: multiple fixes Signed-off-by: Dave Airlie <[email protected]> From: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-09-22drm/dp_mst: Retrieve extended DPCD caps for topology managerKoba Ko1-3/+4
As per DP-1.3, First check DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT. If DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT is 1,read the DP_DP13_DPCD_REV to get the faster capability. If DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT is 0,read DP_DPCD_REV. Signed-off-by: Koba Ko <[email protected]> Reviewed-by: Lyude Paul <[email protected]> [added aux name to drm_dbg_kms() call] Signed-off-by: Lyude Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-09-14Merge drm/drm-next into drm-misc-nextMaxime Ripard1-2/+24
Paul Cercueil needs some patches in -rc5 to apply new patches for ingenic properly. Signed-off-by: Maxime Ripard <[email protected]>
2020-09-11Merge drm/drm-next into drm-intel-next-queuedRodrigo Vivi1-2/+24
Sync drm-intel-gt-next here so we can have an unified fixes flow. Signed-off-by: Rodrigo Vivi <[email protected]>
2020-09-09Merge tag 'topic/nouveau-i915-dp-helpers-and-cleanup-2020-08-31-1' of ↵Dave Airlie1-0/+22
git://anongit.freedesktop.org/drm/drm-misc into drm-next UAPI Changes: None Cross-subsystem Changes: * Moves a bunch of miscellaneous DP code from the i915 driver into a set of shared DRM DP helpers Core Changes: * New DRM DP helpers (see above) Driver Changes: * Implements usage of the aforementioned DP helpers in the nouveau driver, along with some other various HPD related cleanup for nouveau Signed-off-by: Dave Airlie <[email protected]> From: Lyude Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-09-01drm/dp_mst: Support remote i2c writesSam McNally1-16/+90
For DP MST outputs, the i2c device currently only supports transfers that can be implemented using remote i2c reads. Such transfers must consist of zero or more write transactions followed by one read transaction. DDC/CI commands require standalone write transactions and hence aren't supported. Since each remote i2c write is handled as a separate transfer, remote i2c writes can support transfers consisting of write transactions, where all but the last have I2C_M_STOP set. According to the DDC/CI 1.1 standard, DDC/CI commands only require a single write or read transaction in a transfer, so this is sufficient. For i2c transfers meeting the above criteria, generate and send a remote i2c write message for each transaction. Add the trivial remote i2c write reply parsing support so remote i2c write acks bubble up correctly. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/37 Signed-off-by: Sam McNally <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20200727160225.1.I4e95a534de051551cd143e6cb83d4c5a9b0ad1cd@changeid
2020-09-01drm/mst: Add support for QUERY_STREAM_ENCRYPTION_STATUS MST sideband messageSean Paul1-0/+150
Used to query whether an MST stream is encrypted or not. Cc: Lyude Paul <[email protected]> Reviewed-by: Anshuman Gupta <[email protected]> Reviewed-by: Lyude Paul <[email protected]> Signed-off-by: Sean Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v4 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v5 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v6 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v7 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] #v8 Changes in v4: -Added to the set Changes in v5: -None Changes in v6: -Use FIELD_PREP to generate request buffer bitfields (Lyude) -Add mst selftest and dump/decode_sideband_req for QSES (Lyude) Changes in v7: -None Changes in v8: -Reverse the parsing on the hdcp_*x_device_present bits and leave breadcrumb in case this is incorrect (Anshuman) Changes in v8.5: -s/DRM_DEBUG_KMS/drm_dbg_kms/ (Lyude) Signed-off-by: Ramalingam C <[email protected]> Acked-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-08-31drm/i915/dp: Extract drm_dp_read_mst_cap()Lyude Paul1-0/+22
Just a tiny drive-by cleanup, we can consolidate i915's code for checking for MST support into a helper to be shared across drivers. v5: * Drop !!() * Move drm_dp_has_mst() out of header * Change name from drm_dp_has_mst() to drm_dp_read_mst_cap() Signed-off-by: Lyude Paul <[email protected]> Reviewed-by: Sean Paul <[email protected]> Reviewed-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-08-25Merge tag 'v5.9-rc2' into drm-misc-fixesMaarten Lankhorst1-27/+94
Backmerge requested by Tomi for a fix to omap inconsistent locking state issue, and because we need at least v5.9-rc2 now. Signed-off-by: Maarten Lankhorst <[email protected]>
2020-08-17drm/dp_mst: Don't return error code when crtc is nullBhawanpreet Lakha1-2/+2
[Why] In certain cases the crtc can be NULL and returning -EINVAL causes atomic check to fail when it shouln't. This leads to valid configurations failing because atomic check fails. [How] Don't early return if crtc is null Signed-off-by: Bhawanpreet Lakha <[email protected]> Reviewed-by: Lyude Paul <[email protected]> [added stable cc] Signed-off-by: Lyude Paul <[email protected]> Fixes: 8ec046716ca8 ("drm/dp_mst: Add helper to trigger modeset on affected DSC MST CRTCs") Cc: <[email protected]> # v5.6+ Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-08-04drm: fix drm_dp_mst_port refcount leaks in drm_dp_mst_allocate_vcpiXin Xiong1-3/+4
drm_dp_mst_allocate_vcpi() invokes drm_dp_mst_topology_get_port_validated(), which increases the refcount of the "port". These reference counting issues take place in two exception handling paths separately. Either when “slots” is less than 0 or when drm_dp_init_vcpi() returns a negative value, the function forgets to reduce the refcnt increased drm_dp_mst_topology_get_port_validated(), which results in a refcount leak. Fix these issues by pulling up the error handling when "slots" is less than 0, and calling drm_dp_mst_topology_put_port() before termination when drm_dp_init_vcpi() returns a negative value. Fixes: 1e797f556c61 ("drm/dp: Split drm_dp_mst_allocate_vcpi") Cc: <[email protected]> # v4.12+ Signed-off-by: Xiyu Yang <[email protected]> Signed-off-by: Xin Tan <[email protected]> Signed-off-by: Xin Xiong <[email protected]> Reviewed-by: Lyude Paul <[email protected]> Signed-off-by: Lyude Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20200719154545.GA41231@xin-virtual-machine
2020-07-02drm : Insert blank lines after declarations.Suraj Upadhyay1-0/+20
Resolve checkpatch issues for missing blank lines after declarations. Issues found in multiple files with checkpatch.pl. Signed-off-by: Suraj Upadhyay <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20200702131749.GA25710@blackclown
2020-06-24Merge tag 'drm-misc-next-2020-06-19' of ↵Dave Airlie1-24/+70
git://anongit.freedesktop.org/drm/drm-misc into drm-next drm-misc-next for v5.9: UAPI Changes: - Add DRM_MODE_TYPE_USERDEF for video modes specified in cmdline. Cross-subsystem Changes: - Assorted devicetree binding updates. - Add might_sleep() to dma_fence_wait(). - Fix fbdev's get_user_pages_fast() handling, and use pin_user_pages. - Small cleanup with IS_BUILTIN in video/fbdev drivers. - Fix video/hdmi coding style for infoframe size. Core Changes: - Silence vblank output during init. - Fix DP-MST corruption during send msg timeout. - Clear leak in drm_gem_objecs_lookup(). - Make newlines work with force connector attribute. - Fix module refcounting error in drm_encoder_slave, and use new i2c api. - Header fix for drm_managed.c - More struct_mutex removal for !legacy drivers: - Remove gem_free_object() - Removal of drm_gem_object_put_unlocked(). - Show current->comm alongside pid in debug printfs. - Add drm_client_modeset_check() + drm_client_framebuffer_flush(). - Replace drm_fb_swab16 with drm_fb_swap that also supports 32-bits. - Remove mode->vrefresh, and compactify drm_display_mode. - Use drm_* macros for logging and warnings. - Add WARN when drm_gem_get_pages is used on a private obj. - Handle importing and imported dmabuf better in shmem helpers. - Small fix for drm/mm hole size comparison, and remove invalid entry optimization. - Add a drm/mm selftest. - Set DSI connector type for DSI panels. - Assorted small fixes and documentation updates. - Fix DDI I2C device registration for MST ports, and flushing on destroy. - Fix master_set return type, used by vmwgfx. - Make the drm_set/drop_master ioctl symmetrical. Driver Changes: Allow iommu in the sun4i driver and use it for sun8i. - Simplify backlight lookup for omap, amba-clcd and tilcdc. - Hold reg_lock for rockchip. - Add support for bridge gpio and lane reordering + polarity to ti-sn65dsi86, and fix clock choice. - Small assorted fixes to tilcdc, vc4, i915, omap, fbdev/sm712fb, fbdev/pxafb, console/newport_con, msm, virtio, udl, malidp, hdlcd, bridge/ti-sn65dsi86, panfrost. - Remove hw cursor support for mgag200, and use simple kms helper + shmem helpers. - Add support for KOE Allow iommu in the sun4i driver and use it for sun8i. - Simplify backlight lookup for omap, amba-clcd and tilcdc. - Hold reg_lock for rockchip. - Add support for bridge gpio and lane reordering + polarity to ti-sn65dsi86, and fix clock choice. - Small assorted fixes to tilcdc, vc4 (multiple), i915. - Remove hw cursor support for mgag200, and use simple kms helper + shmem helpers. - Add support for KOE TX26D202VM0BWA panel. - Use GEM CMA functions in arc, arm, atmel-hlcdc, fsi-dcu, hisilicon, imx, ingenic, komeda, malidp, mcde, meson, msxfb, rcar-du, shmobile, stm, sti, tilcdc, tve200, zte. - Remove gem_print_info. - Improve gem_create_object_helper so udl can use shmem helpers. - Convert vc4 dt bindings to schemas, and add clock properties. - Device initialization cleanups for mgag200. - Add a workaround to fix DP-MST short pulses handling on broken hardware in i915. - Allow build test compiling arm drivers. - Use managed pci functions in mgag200 and ast. - Use dev_groups in malidp. - Add per pixel alpha support for PX30 VOP in rockchip. - Silence deferred probe logs in panfrost. Signed-off-by: Dave Airlie <[email protected]> From: Maarten Lankhorst <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-06-11drm/dp_mst: Fix flushing the delayed port/mstb destroy workImre Deak1-3/+16
Atm, a pending delayed destroy work during module removal will be canceled, leaving behind MST ports, mstbs. Fix this by using a dedicated workqueue which will be drained of requeued items as well when destroying it. v2: - Check if wq is NULL before calling destroy_workqueue(). Cc: Lyude Paul <[email protected]> Cc: Stanislav Lisovskiy <[email protected]> Reviewed-by: Stanislav Lisovskiy <[email protected]> Reviewed-by: Lyude Paul <[email protected]> Signed-off-by: Imre Deak <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-06-11drm/dp_mst: Fix the DDC I2C device registration of an MST portImre Deak1-12/+16
During the initial MST probing an MST port's I2C device will be registered using the kdev of the DRM device as a parent. Later after MST Connection Status Notifications this I2C device will be re-registered with the kdev of the port's connector. This will also move inconsistently the I2C device's sysfs entry from the DRM device's sysfs dir to the connector's dir. Fix the above by keeping the DRM kdev as the parent of the I2C device. Ideally the connector's kdev would be used as a parent, similarly to non-MST connectors, however that needs some more refactoring to ensure the connector's kdev is already available early enough. So keep the existing (initial) behavior for now. Cc: <[email protected]> Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Stanislav Lisovskiy <[email protected]> Reviewed-by: Lyude Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-06-11drm/dp_mst: Fix the DDC I2C device unregistration of an MST portImre Deak1-1/+2
The WARN below triggers during the removal of an MST port. The problem is that the parent device's (the connector's kdev) sysfs directory is removed recursively when the connector is unregistered (even though the I2C device holds a reference on the parent device). To fix this set first the Peer Device Type to none which will remove the I2C device. Note that atm, inconsistently, the parent of the I2C device is initially set to the DRM kdev and after a Connection Status Notification the parent may be reset to be the connector's kdev. This problem is addressed by the next patch. [ 4462.989299] ------------[ cut here ]------------ [ 4463.014940] sysfs group 'power' not found for kobject 'i2c-24' [ 4463.034664] WARNING: CPU: 0 PID: 970 at fs/sysfs/group.c:281 sysfs_remove_group+0x71/0x80 [ 4463.044357] Modules linked in: snd_hda_intel i915 drm_kms_helper(O) drm netconsole snd_hda_codec_hdmi mei_hdcp x86_pkg_temp_thermal coretemp crct10dif_pclmul snd_intel_dspcf g crc32_pclmul snd_hda_codec snd_hwdep ghash_clmulni_intel snd_hda_core asix usbnet kvm_intel mii i2c_algo_bit snd_pcm syscopyarea sysfillrect e1000e sysimgblt fb_sys_fops prim e_numbers ptp pps_core i2c_i801 r8169 mei_me realtek mei [last unloaded: drm] [ 4463.044399] CPU: 0 PID: 970 Comm: kworker/0:2 Tainted: G O 5.7.0+ #172 [ 4463.044402] Hardware name: Intel Corporation Tiger Lake Client Platform/TigerLake U DDR4 SODIMM RVP [ 4463.044423] Workqueue: events drm_dp_delayed_destroy_work [drm_kms_helper] [ 4463.044428] RIP: 0010:sysfs_remove_group+0x71/0x80 [ 4463.044431] Code: 48 89 df 5b 5d 41 5c e9 cd b6 ff ff 48 89 df e8 95 b4 ff ff eb cb 49 8b 14 24 48 8b 75 00 48 c7 c7 20 0f 3f 82 e8 9f c5 d7 ff <0f> 0b 5b 5d 41 5c c3 0f 1f 84 00 00 00 00 00 48 85 f6 74 31 41 54 [ 4463.044433] RSP: 0018:ffffc900018bfbf0 EFLAGS: 00010282 [ 4463.044436] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000001 [ 4463.044439] RDX: 0000000080000001 RSI: ffff88849e828f38 RDI: 00000000ffffffff [ 4463.052970] [drm:drm_atomic_get_plane_state [drm]] Added [PLANE:100:plane 2B] 00000000c2160caa state to 00000000d172564a [ 4463.070533] RBP: ffffffff820cea20 R08: ffff88847f4b8958 R09: 0000000000000000 [ 4463.070535] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88848a725018 [ 4463.070537] R13: 0000000000000000 R14: ffffffff827090e0 R15: 0000000000000002 [ 4463.070539] FS: 0000000000000000(0000) GS:ffff88849e800000(0000) knlGS:0000000000000000 [ 4463.070541] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 4463.070543] CR2: 00007fdf8a756538 CR3: 0000000489684001 CR4: 0000000000760ef0 [ 4463.070545] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 4463.070547] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 4463.070549] PKRU: 55555554 [ 4463.070551] Call Trace: [ 4463.070560] device_del+0x84/0x400 [ 4463.070571] cdev_device_del+0x10/0x30 [ 4463.070578] put_i2c_dev+0x69/0x80 [ 4463.070584] i2cdev_detach_adapter+0x2e/0x60 [ 4463.070591] notifier_call_chain+0x34/0x90 [ 4463.070599] blocking_notifier_call_chain+0x3f/0x60 [ 4463.070606] device_del+0x7c/0x400 [ 4463.087817] ? lockdep_init_map_waits+0x57/0x210 [ 4463.087825] device_unregister+0x11/0x60 [ 4463.087829] i2c_del_adapter+0x249/0x310 [ 4463.087846] drm_dp_port_set_pdt+0x6b/0x2c0 [drm_kms_helper] [ 4463.087862] drm_dp_delayed_destroy_work+0x2af/0x350 [drm_kms_helper] [ 4463.087876] process_one_work+0x268/0x600 [ 4463.105438] ? __schedule+0x30c/0x920 [ 4463.105451] worker_thread+0x37/0x380 [ 4463.105457] ? process_one_work+0x600/0x600 [ 4463.105462] kthread+0x140/0x160 [ 4463.105466] ? kthread_park+0x80/0x80 [ 4463.105474] ret_from_fork+0x24/0x50 Cc: <[email protected]> Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Stanislav Lisovskiy <[email protected]> Reviewed-by: Lyude Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-06-11drm/i915/dp_mst: Work around out-of-spec adapters filtering short pulsesImre Deak1-3/+29
Some TypeC -> native DP adapters, at least the Club 3D CAC-1557 adapter, incorrectly filter out HPD short pulses with a duration less than ~540 usec, leading to MST probe failures. According to the DP Standard 2.0 section 5.1.4: - DP sinks should generate short pulses in the 500 usec -> 1 msec range - DP sources should detect short pulses in the 250 usec -> 2 msec range According to the DP Alt Mode on TypeC Standard section 3.9.2, adapters should detect and forward short pulses according to how sources should detect them as specified in the DP Standard (250 usec -> 2 msec). Based on the above filtering out short pulses with a duration less than 540 usec is incorrect. To make such adapters work add support for a driver polling on MST inerrupt flags, and wire this up in the i915 driver. The sink can clear an interrupt it raised after 110 msec if the source doesn't respond, so use a 50 msec poll period to avoid missing an interrupt. Polling of the MST interrupt flags is explicitly allowed by the DP Standard. This fixes MST probe failures I saw using this adapter and a DELL U2515H monitor. v2: - Fix the wait event timeout for the no-poll case. v3 (Ville): - Fix the short pulse duration limits in the commit log prescribed by the DP Standard. - Add code comment explaining why/how polling is used. - Factor out a helper to schedule the port's hpd irq handler and move it to the rest of hotplug handlers. - Document the new MST callback. - s/update_hpd_irq_state/poll_hpd_irq/ Cc: Ville Syrjälä <[email protected]> Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Reviewed-by: Lyude Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-06-11drm/dp_mst: Sanitize mgr->qlock locking in drm_dp_mst_wait_tx_reply()Imre Deak1-1/+1
Make the locking look symmetric with the unlocking. Signed-off-by: Imre Deak <[email protected]> Reviewed-by: José Roberto de Souza <[email protected]> Reviewed-by: Lyude Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-06-02Merge tag 'drm-next-2020-06-02' of git://anongit.freedesktop.org/drm/drmLinus Torvalds1-227/+175
Pull drm updates from Dave Airlie: "Highlights: - Core DRM had a lot of refactoring around managed drm resources to make drivers simpler. - Intel Tigerlake support is on by default - amdgpu now support p2p PCI buffer sharing and encrypted GPU memory Details: core: - uapi: error out EBUSY when existing master - uapi: rework SET/DROP MASTER permission handling - remove drm_pci.h - drm_pci* are now legacy - introduced managed DRM resources - subclassing support for drm_framebuffer - simple encoder helper - edid improvements - vblank + writeback documentation improved - drm/mm - optimise tree searches - port drivers to use devm_drm_dev_alloc dma-buf: - add flag for p2p buffer support mst: - ACT timeout improvements - remove drm_dp_mst_has_audio - don't use 2nd TX slot - spec recommends against it bridge: - dw-hdmi various improvements - chrontel ch7033 support - fix stack issues with old gcc hdmi: - add unpack function for drm infoframe fbdev: - misc fbdev driver fixes i915: - uapi: global sseu pinning - uapi: OA buffer polling - uapi: remove generated perf code - uapi: per-engine default property values in sysfs - Tigerlake GEN12 enabled. - Lots of gem refactoring - Tigerlake enablement patches - move to drm_device logging - Icelake gamma HW readout - push MST link retrain to hotplug work - bandwidth atomic helpers - ICL fixes - RPS/GT refactoring - Cherryview full-ppgtt support - i915 locking guidelines documented - require linear fb stride to be 512 multiple on gen9 - Tigerlake SAGV support amdgpu: - uapi: encrypted GPU memory handling - uapi: add MEM_SYNC IB flag - p2p dma-buf support - export VRAM dma-bufs - FRU chip access support - RAS/SR-IOV updates - Powerplay locking fixes - VCN DPG (powergating) enablement - GFX10 clockgating fixes - DC fixes - GPU reset fixes - navi SDMA fix - expose FP16 for modesetting - DP 1.4 compliance fixes - gfx10 soft recovery - Improved Critical Thermal Faults handling - resizable BAR on gmc10 amdkfd: - uapi: GWS resource management - track GPU memory per process - report PCI domain in topology radeon: - safe reg list generator fixes nouveau: - HD audio fixes on recent systems - vGPU detection (fail probe if we're on one, for now) - Interlaced mode fixes (mostly avoidance on Turing, which doesn't support it) - SVM improvements/fixes - NVIDIA format modifier support - Misc other fixes. adv7511: - HDMI SPDIF support ast: - allocate crtc state size - fix double assignment - fix suspend bochs: - drop connector register cirrus: - move to tiny drivers. exynos: - fix imported dma-buf mapping - enable runtime PM - fixes and cleanups mediatek: - DPI pin mode swap - config mipi_tx current/impedance lima: - devfreq + cooling device support - task handling improvements - runtime PM support pl111: - vexpress init improvements - fix module auto-load rcar-du: - DT bindings conversion to YAML - Planes zpos sanity check and fix - MAINTAINERS entry for LVDS panel driver mcde: - fix return value mgag200: - use managed config init stm: - read endpoints from DT vboxvideo: - use PCI managed functions - drop WC mtrr vkms: - enable cursor by default rockchip: - afbc support virtio: - various cleanups qxl: - fix cursor notify port hisilicon: - 128-byte stride alignment fix sun4i: - improved format handling" * tag 'drm-next-2020-06-02' of git://anongit.freedesktop.org/drm/drm: (1401 commits) drm/amd/display: Fix potential integer wraparound resulting in a hang drm/amd/display: drop cursor position check in atomic test drm/amdgpu: fix device attribute node create failed with multi gpu drm/nouveau: use correct conflicting framebuffer API drm/vblank: Fix -Wformat compile warnings on some arches drm/amdgpu: Sync with VM root BO when switching VM to CPU update mode drm/amd/display: Handle GPU reset for DC block drm/amdgpu: add apu flags (v2) drm/amd/powerpay: Disable gfxoff when setting manual mode on picasso and raven drm/amdgpu: fix pm sysfs node handling (v2) drm/amdgpu: move gpu_info parsing after common early init drm/amdgpu: move discovery gfx config fetching drm/nouveau/dispnv50: fix runtime pm imbalance on error drm/nouveau: fix runtime pm imbalance on error drm/nouveau: fix runtime pm imbalance on error drm/nouveau/debugfs: fix runtime pm imbalance on error drm/nouveau/nouveau/hmm: fix migrate zero page to GPU drm/nouveau/nouveau/hmm: fix nouveau_dmem_chunk allocations drm/nouveau/kms/nv50-: Share DP SST mode_valid() handling with MST drm/nouveau/kms/nv50-: Move 8BPC limit for MST into nv50_mstc_get_modes() ...
2020-05-19Merge tag 'noinstr-lds-2020-05-19' into core/rcuThomas Gleixner1-2/+7
Get the noinstr section and annotation markers to base the RCU parts on.
2020-05-18drm: Match drm_dp_send_clear_payload_id_table definition to declarationChris Wilson1-3/+4
drivers/gpu/drm/drm_dp_mst_topology.c:2898:6: warning: symbol 'drm_dp_send_clear_payload_id_table' was not declared. Should it be static? drivers/gpu/drm/drm_dp_mst_topology.c:5451:37: warning: missing braces around initializer drivers/gpu/drm/drm_dp_mst_topology.c:5451:37: warning: missing braces around initializer Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-05-15drm/dp_mst: Fix timeout handling of MST down messagesImre Deak1-1/+2
This fixes the following use-after-free problem in case an MST down message times out, while waiting for the response for it: [ 449.022841] [drm:drm_dp_mst_wait_tx_reply.isra.26] timedout msg send 0000000080ba7fa2 2 0 [ 449.022898] ------------[ cut here ]------------ [ 449.022903] list_add corruption. prev->next should be next (ffff88847dae32c0), but was 6b6b6b6b6b6b6b6b. (prev=ffff88847db1c140). [ 449.022931] WARNING: CPU: 2 PID: 22 at lib/list_debug.c:28 __list_add_valid+0x4d/0x70 [ 449.022935] Modules linked in: asix usbnet mii snd_hda_codec_hdmi mei_hdcp i915 x86_pkg_temp_thermal coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hwdep e1000e snd_hda_core ptp snd_pcm pps_core mei_me mei intel_lpss_pci prime_numbers [ 449.022966] CPU: 2 PID: 22 Comm: kworker/2:0 Not tainted 5.7.0-rc3-CI-Patchwork_17536+ #1 [ 449.022970] Hardware name: Intel Corporation Tiger Lake Client Platform/TigerLake U DDR4 SODIMM RVP, BIOS TGLSFWI1.R00.2457.A16.1912270059 12/27/2019 [ 449.022976] Workqueue: events_long drm_dp_mst_link_probe_work [ 449.022982] RIP: 0010:__list_add_valid+0x4d/0x70 [ 449.022987] Code: c3 48 89 d1 48 c7 c7 f0 e7 32 82 48 89 c2 e8 3a 49 b7 ff 0f 0b 31 c0 c3 48 89 c1 4c 89 c6 48 c7 c7 40 e8 32 82 e8 23 49 b7 ff <0f> 0b 31 c0 c3 48 89 f2 4c 89 c1 48 89 fe 48 c7 c7 90 e8 32 82 e8 [ 449.022991] RSP: 0018:ffffc900001abcb0 EFLAGS: 00010286 [ 449.022995] RAX: 0000000000000000 RBX: ffff88847dae2d58 RCX: 0000000000000001 [ 449.022999] RDX: 0000000080000001 RSI: ffff88849d914978 RDI: 00000000ffffffff [ 449.023002] RBP: ffff88847dae32c0 R08: ffff88849d914978 R09: 0000000000000000 [ 449.023006] R10: ffffc900001abcb8 R11: 0000000000000000 R12: ffff888490d98400 [ 449.023009] R13: ffff88847dae3230 R14: ffff88847db1c140 R15: ffff888490d98540 [ 449.023013] FS: 0000000000000000(0000) GS:ffff88849ff00000(0000) knlGS:0000000000000000 [ 449.023017] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 449.023021] CR2: 00007fb96fafdc63 CR3: 0000000005610004 CR4: 0000000000760ee0 [ 449.023025] PKRU: 55555554 [ 449.023028] Call Trace: [ 449.023034] drm_dp_queue_down_tx+0x59/0x110 [ 449.023041] ? rcu_read_lock_sched_held+0x4d/0x80 [ 449.023050] ? kmem_cache_alloc_trace+0x2a6/0x2d0 [ 449.023060] drm_dp_send_link_address+0x74/0x870 [ 449.023065] ? __slab_free+0x3e1/0x5c0 [ 449.023071] ? lockdep_hardirqs_on+0xe0/0x1c0 [ 449.023078] ? lockdep_hardirqs_on+0xe0/0x1c0 [ 449.023097] drm_dp_check_and_send_link_address+0x9a/0xc0 [ 449.023106] drm_dp_mst_link_probe_work+0x9e/0x160 [ 449.023117] process_one_work+0x268/0x600 [ 449.023124] ? __schedule+0x307/0x8d0 [ 449.023139] worker_thread+0x37/0x380 [ 449.023149] ? process_one_work+0x600/0x600 [ 449.023153] kthread+0x140/0x160 [ 449.023159] ? kthread_park+0x80/0x80 [ 449.023169] ret_from_fork+0x24/0x50 Fixes: d308a881a591 ("drm/dp_mst: Kill the second sideband tx slot, save the world") Cc: Lyude Paul <[email protected]> Cc: Sean Paul <[email protected]> Cc: Wayne Lin <[email protected]> Cc: <[email protected]> # v3.17+ Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-04-27drm/dp_mst: Kill the second sideband tx slot, save the worldLyude Paul1-107/+42
While we support using both tx slots for sideband transmissions, it appears that DisplayPort devices in the field didn't end up doing a very good job of supporting it. From section 5.2.1 of the DP 2.0 specification: There are MST Sink/Branch devices in the field that do not handle interleaved message transactions. To facilitate message transaction handling by downstream devices, an MST Source device shall generate message transactions in an atomic manner (i.e., the MST Source device shall not concurrently interleave multiple message transactions). Therefore, an MST Source device shall clear the Message_Sequence_No value in the Sideband_MSG_Header to 0. This might come as a bit of a surprise since the vast majority of hubs will support using both tx slots even if they don't support interleaved message transactions, and we've also been using both tx slots since MST was introduced into the kernel. However, there is one device we've had trouble getting working consistently with MST for so long that we actually assumed it was just broken: the infamous Dell P2415Qb. Previously this monitor would appear to work sometimes, but in most situations would end up timing out LINK_ADDRESS messages almost at random until you power cycled the whole display. After reading section 5.2.1 in the DP 2.0 spec, some closer investigation into this infamous display revealed it was only ever timing out on sideband messages in the second TX slot. Sure enough, avoiding the second TX slot has suddenly made this monitor function perfectly for the first time in five years. And since they explicitly mention this in the specification, I doubt this is the only monitor out there with this issue. This might even explain explain the seemingly harmless garbage sideband responses we would occasionally see with MST hubs! So - rewrite our sideband TX handlers to only support one TX slot. In order to simplify our sideband handling now that we don't support transmitting to multiple MSTBs at once, we also move all state tracking for down replies from mstbs to the topology manager. Signed-off-by: Lyude Paul <[email protected]> Fixes: ad7f8a1f9ced ("drm/helper: add Displayport multi-stream helper (v0.6)") Cc: Sean Paul <[email protected]> Cc: "Lin, Wayne" <[email protected]> Cc: <[email protected]> # v3.17+ Reviewed-by: Sean Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-04-27drm: Make drm_dp_mst_dsc_aux_for_port() safe for old compilersPaul E. McKenney1-1/+1
Older compilers either want two extra pairs of curly braces around the initializer for local variable desc, or they want a single pair of curly braces with nothing inside. Because current Linux-kernel practice favors the latter, this commit makes it so. Suggested-by: Chris Wilson <[email protected]> Suggested-by: Joe Perches <[email protected]> Suggested-by: Christoph Hellwig <[email protected]> Signed-off-by: Paul E. McKenney <[email protected]>
2020-04-27drm/dp_mst: Fix drm_dp_send_dpcd_write() return codeLyude Paul1-2/+6
drm_dp_mst_wait_tx_reply() returns > 1 if time elapsed in wait_event_timeout() before check_txmsg_state(mgr, txmsg) evaluated to true. However, we make the mistake of returning this time from drm_dp_send_dpcd_write() on success instead of returning the number of bytes written - causing spontaneous failures during link probing: [drm:drm_dp_send_link_address [drm_kms_helper]] *ERROR* GUID check on 10:01 failed: 3975 Yikes! So, fix this by returning the number of bytes written on success instead. Signed-off-by: Lyude Paul <[email protected]> Fixes: cb897542c6d2 ("drm/dp_mst: Fix W=1 warnings") Cc: Benjamin Gaignard <[email protected]> Cc: Sean Paul <[email protected]> Acked-by: Alex Deucher <[email protected]> Reviewed-by: Sean Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-04-23Revert "drm/dp_mst: Remove single tx msg restriction."Lyude Paul1-2/+12
This reverts commit 6bb0942e8f46863a745489cce27efe5be2a3885e. Unfortunately it would appear that the rumors we've heard of sideband message interleaving not being very well supported are true. On the Lenovo ThinkPad Thunderbolt 3 dock that I have, interleaved messages appear to just get dropped: [drm:drm_dp_mst_wait_tx_reply [drm_kms_helper]] timedout msg send 00000000571ddfd0 2 1 [dp_mst] txmsg cur_offset=2 cur_len=2 seqno=1 state=SENT path_msg=1 dst=00 [dp_mst] type=ENUM_PATH_RESOURCES contents: [dp_mst] port=2 DP descriptor for this hub: OUI 90-cc-24 dev-ID SYNA3 HW-rev 1.0 SW-rev 3.12 quirks 0x0008 It would seem like as well that this is a somewhat well known issue in the field. From section 5.4.2 of the DisplayPort 2.0 specification: There are MST Sink/Branch devices in the field that do not handle interleaved message transactions. To facilitate message transaction handling by downstream devices, an MST Source device shall generate message transactions in an atomic manner (i.e., the MST Source device shall not concurrently interleave multiple message transactions). Therefore, an MST Source device shall clear the Message_Sequence_No value in the Sideband_MSG_Header to 0. MST Source devices that support field policy updates by way of software should update the policy to forego the generation of interleaved message transactions. This is a bit disappointing, as features like HDCP require that we send a sideband request every ~2 seconds for each active stream. However, there isn't really anything in the specification that allows us to accurately probe for interleaved messages. If it ends up being that we -really- need this in the future, we might be able to whitelist hubs where interleaving is known to work-or maybe try some sort of heuristics. But for now, let's just play it safe and not use it. Signed-off-by: Lyude Paul <[email protected]> Fixes: 6bb0942e8f46 ("drm/dp_mst: Remove single tx msg restriction.") Cc: Wayne Lin <[email protected]> Cc: Sean Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Sean Paul <[email protected]>
2020-04-17drm/dp_mst: Zero assigned PBN when releasing VCPI slotsMikita Lipski1-0/+1
Zero Port's PBN together with VCPI slots when releasing allocated VCPI slots. That way when disabling the connector it will not cause issues in drm_dp_mst_atomic_check verifying branch bw limit. Signed-off-by: Mikita Lipski <[email protected]> Signed-off-by: Lyude Paul <[email protected]> Fixes: cd82d82cbc04 ("drm/dp_mst: Add branch bandwidth validation to MST atomic check") Cc: <[email protected]> # v5.6+ Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-04-17Merge drm/drm-next into drm-misc-nextThomas Zimmermann1-58/+126
Backmerging required to pull topic/phy-compliance. Signed-off-by: Thomas Zimmermann <[email protected]>
2020-04-09drm/dp_mst: Print errors on ACT timeoutsLyude Paul1-2/+6
Although it's not unexpected for drm_dp_check_act_status() to fail due to DPCD read failures (as the hub may have just been unplugged suddenly), timeouts are a bit more worrying as they either mean we need a longer timeout value, or we aren't setting up payload allocations properly. So, let's start printing errors on timeouts. Signed-off-by: Lyude Paul <[email protected]> Cc: Sean Paul <[email protected]> Reviewed-by: Sean Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-04-09drm/dp_mst: Increase ACT retry timeout to 3sLyude Paul1-23/+34
Currently we only poll for an ACT up to 30 times, with a busy-wait delay of 100µs between each attempt - giving us a timeout of 2900µs. While this might seem sensible, it would appear that in certain scenarios it can take dramatically longer then that for us to receive an ACT. On one of the EVGA MST hubs that I have available, I observed said hub sometimes taking longer then a second before signalling the ACT. These delays mostly seem to occur when previous sideband messages we've sent are NAKd by the hub, however it wouldn't be particularly surprising if it's possible to reproduce times like this simply by introducing branch devices with large LCTs since payload allocations have to take effect on every downstream device up to the payload's target. So, instead of just retrying 30 times we poll for the ACT for up to 3ms, and additionally use usleep_range() to avoid a very long and rude busy-wait. Note that the previous retry count of 30 appears to have been arbitrarily chosen, as I can't find any mention of a recommended timeout or retry count for ACTs in the DisplayPort 2.0 specification. This also goes for the range we were previously using for udelay(), although I suspect that was just copied from the recommended delay for link training on SST devices. Changes since v1: * Use readx_poll_timeout() instead of open-coding timeout loop - Sean Paul Changes since v2: * Increase poll interval to 200us - Sean Paul * Print status in hex when we timeout waiting for ACT - Sean Paul Signed-off-by: Lyude Paul <[email protected]> Fixes: ad7f8a1f9ced ("drm/helper: add Displayport multi-stream helper (v0.6)") Cc: Sean Paul <[email protected]> Cc: <[email protected]> # v3.17+ Reviewed-by: Sean Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-04-09drm/dp_mst: Reformat drm_dp_check_act_status() a bitLyude Paul1-12/+10
Just add a bit more line wrapping, get rid of some extraneous whitespace, remove an unneeded goto label, and move around some variable declarations. No functional changes here. Signed-off-by: Lyude Paul <[email protected]> [this isn't a fix, but it's needed for the fix that comes after this] Fixes: ad7f8a1f9ced ("drm/helper: add Displayport multi-stream helper (v0.6)") Cc: Sean Paul <[email protected]> Cc: <[email protected]> # v3.17+ Reviewed-by: Sean Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-04-09drm/dp_mst: Improve kdocs for drm_dp_check_act_status()Lyude Paul1-2/+6
No functional changes. Signed-off-by: Lyude Paul <[email protected]> Cc: Sean Paul <[email protected]> Reviewed-by: Sean Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-04-07drm/dp_mst: Remove drm_dp_mst_has_audio()Lyude Paul1-21/+0
Drive-by fix I noticed the other day - drm_dp_mst_has_audio() only ever made sense back when we still had to validate ports before accessing them in order to (attempt to) avoid NULL dereferences. Since we have proper reference counting that guarantees we always can safely access the MST port, there's no use in keeping this function around as all it does is validate the port pointer before checking the audio status. Note - drm_dp_mst_port->has_audio is technically protected by drm_device->mode_config.connection_mutex, since it's only ever updated from drm_dp_mst_get_edid(). Additionally, we change the declaration for port in struct intel_connector to be properly typed, so we can directly access it. Changes since v1: * Change type of intel_connector->port in a separate patch - Sean Paul Cc: "Lee, Shawn C" <[email protected]> Reviewed-by: Sean Paul <[email protected]> Signed-off-by: Lyude Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-04-06drm/dp_mst: Don't drop NAKs for down responsesLyude Paul1-1/+0
It looks like that when we introduced the ability to handle multiple down requests at once, we accidentally started dropping NAK replies - causing sideband messages which got NAK'd to seemingly timeout and cause all sorts of weirdness. So, fix this by making sure we don't return from drm_dp_mst_handle_down_rep() early, but instead treat NAKs like any other message. Signed-off-by: Lyude Paul <[email protected]> Fixes: fbc821c4a506 ("drm/mst: Support simultaneous down replies") Cc: Wayne Lin <[email protected]> Cc: Wayne Lin <[email protected]> Cc: Sean Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Sean Paul <[email protected]>
2020-04-06drm/dp_mst: Fix NULL deref in drm_dp_get_one_sb_msg()Lyude Paul1-1/+2
While we don't need this function to store an mstb anywhere for UP requests since we process them asynchronously, we do need to make sure that we don't try to write to **mstb for UP requests otherwise we'll cause a NULL pointer deref: RIP: 0010:drm_dp_get_one_sb_msg+0x4b/0x460 [drm_kms_helper] Call Trace: ? vprintk_emit+0x16a/0x230 ? drm_dp_mst_hpd_irq+0x133/0x1010 [drm_kms_helper] drm_dp_mst_hpd_irq+0x133/0x1010 [drm_kms_helper] ? __drm_dbg+0x87/0x90 [drm] ? intel_dp_hpd_pulse+0x24b/0x400 [i915] intel_dp_hpd_pulse+0x24b/0x400 [i915] i915_digport_work_func+0xd6/0x160 [i915] process_one_work+0x1a9/0x370 worker_thread+0x4d/0x3a0 kthread+0xf9/0x130 ? process_one_work+0x370/0x370 ? kthread_park+0x90/0x90 ret_from_fork+0x35/0x40 So, fix this. Signed-off-by: Lyude Paul <[email protected]> Fixes: fbc821c4a506 ("drm/mst: Support simultaneous down replies") Cc: Wayne Lin <[email protected]> Cc: Lyude Paul <[email protected]> Cc: Wayne Lin <[email protected]> Cc: Sean Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Sean Paul <[email protected]>
2020-04-03drm/dp_mst: Remove drm_dp_mst_topology_cbs.destroy_connectorLyude Paul1-13/+3
Now that we've removed the last user of this callback, get rid of it and drm_dp_destroy_connector(). Signed-off-by: Lyude Paul <[email protected]> Cc: Pankaj Bharadiya <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Alex Deucher <[email protected]>
2020-03-31drm/dp_mst: make build_clear_payload_id_table return voidMaya Rashish1-2/+1
Nothing uses the always-0 return value. Signed-off-by: Maya Rashish <[email protected]> Signed-off-by: Lyude Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-03-31Merge v5.6 into drm-nextDave Airlie1-58/+126
msm needed rc6, so I just went and merged release (msm has been in drm-next outside of this tree) Signed-off-by: Dave Airlie <[email protected]>
2020-03-27drm/dp_mst: Remove single tx msg restriction.Sean Paul1-12/+2
Now that we can support multiple simultaneous replies, remove the restrictions placed on sending new tx msgs. This patch essentially just reverts commit 5a64967a2f3b ("drm/dp_mst: Have DP_Tx send one msg at a time") now that the problem is solved in a different way. Cc: Wayne Lin <[email protected]> Reviewed-by: Lyude Paul <[email protected]> Reviewed-by: Wayne Lin <[email protected]> Signed-off-by: Sean Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-03-27drm/mst: Support simultaneous down repliesSean Paul1-32/+48
Currently we have one down reply message servicing the mst manager, so we need to serialize all tx msgs to ensure we only have one message in flight at a time. For obvious reasons this is suboptimal (but less suboptimal than the free-for-all we had before serialization). This patch removes the single down_rep_recv message from manager and adds 2 replies in the branch structure. The 2 replies mirrors the tx_slots which we use to rate-limit outgoing messages and correspond to seqno in the packet headers. Cc: Wayne Lin <[email protected]> Reviewed-by: Lyude Paul <[email protected]> Reviewed-by: Wayne Lin <[email protected]> Signed-off-by: Sean Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-03-27drm/mst: Separate sideband packet header parsing from message buildingSean Paul1-45/+57
In preparation of per-branch device down message handling, separate header parsing from message building. This will allow us to peek at figure out which branch device the message is from before starting to parse the message contents. Reviewed-by: Lyude Paul <[email protected]> Reviewed-by: Wayne Lin <[email protected]> [seanpaul s/drm_dp_sideband_msg_build/drm_dp_sideband_msg_set_header/] Signed-off-by: Sean Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-03-19Merge tag 'drm-misc-next-2020-03-17' of ↵Dave Airlie1-12/+30
git://anongit.freedesktop.org/drm/drm-misc into drm-next drm-misc-next for 5.7: UAPI Changes: Cross-subsystem Changes: Core Changes: - dp-mst: Remove register_connector callback, add drm_dp_destroy_connector - Changes to scnprintf on multiple instances Driver Changes: - meson: Support for YUV420 - panel: Support Ortustech COM37H3M, idk-1110wr and idk-2121wr, multiple dotclock fixes Signed-off-by: Dave Airlie <[email protected]> From: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-03-19Merge tag 'drm-intel-next-2020-03-13' of ↵Dave Airlie1-1/+2
git://anongit.freedesktop.org/drm/drm-intel into drm-next UAPI Changes: On i915 we have a new UAPI to allow userspace to specify CS ring buffer size on construction (I915_CONTEXT_PARAM_RINGSIZE) and also new sysfs entries exposing various engine properties GVT Changes: VFIO edid getting expanded to all platforms and a big cleanup around attr group, unused vblank complete, kvmgt, Intel engine and dev_priv usages. i915 Changes: - new UAPI to allow userspace to specify CS ring buffer size on construction (I915_CONTEXT_PARAM_RINGSIZE) - (Chris) - New sysfs entries exposing various engine properties (Chris) - Tiger Lake is out of require_force_probe protection (Jose) - Changes in many places around active requests, reset and heartbeat (Chris) - Stop assigning drm-dev_private pointer (Jani) - Many code refactor in many places, including intel_modeset_init, increasing use of intel_uncore_*, vgpu, and gvt stuff (Jani) - Fixes around display pipe iterators (Anshuman) - Tigerlake enabling work (Matt Ropper, Matt Atwood, Ville, Lucas, Daniele, Jose, Anusha, Vivek, Swathi, Caz. Kai) - Code clean-up like reducing use of drm/i915_drv.h, removing unused registers, removing garbage warns, and some other code polishing (Jani, Lucas, Ville) - Selftests fixes, improvements and additions (Chris, Dan, Aditya, Matt Auld) - Fix plane possible_crtcs bit mask (Anshuman) - Fixes and cleanup on GLK pre production identification and w/a (Ville) - Fix display orientation on few cases (Hans, Ville) - dbuf clean-up and improvements for slice arrays handling (Ville) - Improvement around min cdclk calculation (Stanislav) - Fixes and refactor around display PLLs (Imre) - Other execlists and perf fixes (Chris) - Documentation fixes (Jani, Chris) - Fix build issue (Anshuman) - Many more fixes around the locking mechanisms (Chris) - Other fixes and debugability info around preemption (Chris, Tvrtko) - Add mechanism to submit a context WA on ring submission (Mika) - Clear all Eu/L3 resitual context (Prathap) - More changes around local memory (Abdiel, Matt, Chris) - Fix RPS (Chris) - DP MST fix (Lyude) - Display FBC fixes (Jose, RK) - debugfs cleanup (Tvrtko) - More convertion towards drm_debive based loggin (Wambui, Ram) - Avoid potential buffer overflow (Takashi) - Ice Lake and Elkhart Lake workarounds (Matt Roper) Signed-off-by: Dave Airlie <[email protected]> From: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-03-12drm/dp_mst: Rewrite and fix bandwidth limit checksLyude Paul1-26/+93
Sigh, this is mostly my fault for not giving commit cd82d82cbc04 ("drm/dp_mst: Add branch bandwidth validation to MST atomic check") enough scrutiny during review. The way we're checking bandwidth limitations here is mostly wrong: For starters, drm_dp_mst_atomic_check_bw_limit() determines the pbn_limit of a branch by simply scanning each port on the current branch device, then uses the last non-zero full_pbn value that it finds. It then counts the sum of the PBN used on each branch device for that level, and compares against the full_pbn value it found before. This is wrong because ports can and will have different PBN limitations on many hubs, especially since a number of DisplayPort hubs out there will be clever and only use the smallest link rate required for each downstream sink - potentially giving every port a different full_pbn value depending on what link rate it's trained at. This means with our current code, which max PBN value we end up with is not well defined. Additionally, we also need to remember when checking bandwidth limitations that the top-most device in any MST topology is a branch device, not a port. This means that the first level of a topology doesn't technically have a full_pbn value that needs to be checked. Instead, we should assume that so long as our VCPI allocations fit we're within the bandwidth limitations of the primary MSTB. We do however, want to check full_pbn on every port including those of the primary MSTB. However, it's important to keep in mind that this value represents the minimum link rate /between a port's sink or mstb, and the mstb itself/. A quick diagram to explain: MSTB #1 / \ / \ Port #1 Port #2 full_pbn for Port #1 → | | ← full_pbn for Port #2 Sink #1 MSTB #2 | etc... Note that in the above diagram, the combined PBN from all VCPI allocations on said hub should not exceed the full_pbn value of port #2, and the display configuration on sink #1 should not exceed the full_pbn value of port #1. However, port #1 and port #2 can otherwise consume as much bandwidth as they want so long as their VCPI allocations still fit. And finally - our current bandwidth checking code also makes the mistake of not checking whether something is an end device or not before trying to traverse down it. So, let's fix it by rewriting our bandwidth checking helpers. We split the function into one part for handling branches which simply adds up the total PBN on each branch and returns it, and one for checking each port to ensure we're not going over its PBN limit. Phew. This should fix regressions seen, where we erroneously reject display configurations due to thinking they're going over our bandwidth limits when they're not. Changes since v1: * Took an even closer look at how PBN limitations are supposed to be handled, and did some experimenting with Sean Paul. Ended up rewriting these helpers again, but this time they should actually be correct! Changes since v2: * Small indenting fix * Fix pbn_used check in drm_dp_mst_atomic_check_port_bw_limit() Signed-off-by: Lyude Paul <[email protected]> Fixes: cd82d82cbc04 ("drm/dp_mst: Add branch bandwidth validation to MST atomic check") Cc: Sean Paul <[email protected]> Acked-by: Alex Deucher <[email protected]> Reviewed-by: Mikita Lipski <[email protected]> Tested-by: Hans de Goede <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-03-12drm/dp_mst: Reprobe path resources in CSN handlerLyude Paul1-23/+25
We used to punt off reprobing path resources to the link address probe work, but now that we handle CSNs asynchronously from the driver's HPD handling we can do whatever the heck we want from the CSN! So, reprobe the path resources from drm_dp_mst_handle_conn_stat(). Also, get rid of the path resource reprobing code in drm_dp_check_and_send_link_address() since it's needlessly complicated when we already reprobe path resources from drm_dp_handle_link_address_port(). And finally, teach drm_dp_send_enum_path_resources() to return 1 on PBN changes so we know if we need to send another hotplug or not. This fixes issues where we've indicated to userspace that a port has just been connected, before we actually probed it's available PBN - something that results in unexpected atomic check failures. Signed-off-by: Lyude Paul <[email protected]> Fixes: cd82d82cbc04 ("drm/dp_mst: Add branch bandwidth validation to MST atomic check") Cc: Mikita Lipski <[email protected]> Cc: Hans de Goede <[email protected]> Cc: Sean Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Alex Deucher <[email protected]> Tested-by: Hans de Goede <[email protected]>
2020-03-12drm/dp_mst: Use full_pbn instead of available_pbn for bandwidth checksLyude Paul1-8/+7
DisplayPort specifications are fun. For a while, it's been really unclear to us what available_pbn actually does. There's a somewhat vague explanation in the DisplayPort spec (starting from 1.2) that partially explains it: The minimum payload bandwidth number supported by the path. Each node updates this number with its available payload bandwidth number if its payload bandwidth number is less than that in the Message Transaction reply. So, it sounds like available_pbn represents the smallest link rate in use between the source and the branch device. Cool, so full_pbn is just the highest possible PBN that the branch device supports right? Well, we assumed that for quite a while until Sean Paul noticed that on some MST hubs, available_pbn will actually get set to 0 whenever there's any active payloads on the respective branch device. This caused quite a bit of confusion since clearing the payload ID table would end up fixing the available_pbn value. So, we just went with that until commit cd82d82cbc04 ("drm/dp_mst: Add branch bandwidth validation to MST atomic check") started breaking people's setups due to us getting erroneous available_pbn values. So, we did some more digging and got confused until we finally looked at the definition for full_pbn: The bandwidth of the link at the trained link rate and lane count between the DP Source device and the DP Sink device with no time slots allocated to VC Payloads, represented as a Payload Bandwidth Number. As with the Available_Payload_Bandwidth_Number, this number is determined by the link with the lowest lane count and link rate. That's what we get for not reading specs closely enough, hehe. So, since full_pbn is definitely what we want for doing bandwidth restriction checks - let's start using that instead and ignore available_pbn entirely. Signed-off-by: Lyude Paul <[email protected]> Fixes: cd82d82cbc04 ("drm/dp_mst: Add branch bandwidth validation to MST atomic check") Cc: Mikita Lipski <[email protected]> Cc: Hans de Goede <[email protected]> Cc: Sean Paul <[email protected]> Reviewed-by: Mikita Lipski <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Alex Deucher <[email protected]> Tested-by: Hans de Goede <[email protected]>
2020-03-12drm/dp_mst: Rename drm_dp_mst_is_dp_mst_end_device() to be less redundantLyude Paul1-5/+5
It's already prefixed by dp_mst, so we don't really need to repeat ourselves here. One of the changes I should have picked up originally when reviewing MST DSC support. There should be no functional changes here Cc: Mikita Lipski <[email protected]> Cc: Sean Paul <[email protected]> Cc: Hans de Goede <[email protected]> Signed-off-by: Lyude Paul <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Tested-by: Hans de Goede <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-03-11drm: Add drm_dp_destroy_connector helper and use itPankaj Bharadiya1-2/+14
drm_dp_mst_topology_mgr_cbs.destroy_connector callbacks are identical amongst every driver and don't do anything other than cleaning up the connector (drm_connector_unregister()/drm_connector_put()) except for amdgpu_dm driver where some amdgpu_dm specific code in there which I an not sure if it should stay or not. Create and use a helper which calls driver's destroy_connector hook if available otherwise does cleanup internally. This is the step towards removing identical hooks from every driver. Signed-off-by: Pankaj Bharadiya <[email protected]> Suggested-by: Emil Velikov <[email protected]> Suggested-by: Lyude Paul <[email protected]> Signed-off-by: Lyude Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Lyude Paul <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.