summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/nouveau/nouveau_connector.c
AgeCommit message (Collapse)Author
2023-06-13drm/nouveau: add nv_encoder pointer check for NULLNatalia Petrova
Pointer nv_encoder could be dereferenced at nouveau_connector.c in case it's equal to NULL by jumping to goto label. This patch adds a NULL-check to avoid it. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 3195c5f9784a ("drm/nouveau: set encoder for lvds") Signed-off-by: Natalia Petrova <n.petrova@fintech.ru> Reviewed-by: Lyude Paul <lyude@redhat.com> [Fixed patch title] Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230512103320.82234-1-n.petrova@fintech.ru
2023-06-13drm/nouveau/dp: check for NULL nv_connector->native_modeNatalia Petrova
Add checking for NULL before calling nouveau_connector_detect_depth() in nouveau_connector_get_modes() function because nv_connector->native_mode could be dereferenced there since connector pointer passed to nouveau_connector_detect_depth() and the same value of nv_connector->native_mode is used there. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: d4c2c99bdc83 ("drm/nouveau/dp: remove broken display depth function, use the improved one") Signed-off-by: Natalia Petrova <n.petrova@fintech.ru> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230512111526.82408-1-n.petrova@fintech.ru
2022-11-09drm/nouveau/disp: expose conn event classBen Skeggs
This removes some now-unnecessary nesting of workqueues. v2: - use ?: (lyude) Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2022-11-09drm/nouveau/kms: pass event mask to hpd handlerBen Skeggs
Will be moving the DP link status check / re-train here so it's safe from racing with modeset routing changes. MST message handling etc. will remain where it is. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2022-11-09drm/nouveau/kms: switch hpd_lock from mutex to spinlockBen Skeggs
There's no good reason for this to be a mutex, and once the layers of workqueues have been untangled, nouveau_connector_hpd() can be called from IRQ context and won't be able to take a mutex. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2022-08-23drm/display/dp_mst: Add helpers for serializing SST <-> MST transitionsLyude Paul
There's another kind of situation where we could potentially race with nonblocking modesets and MST, especially if we were to only use the locking provided by atomic modesetting: * Display 1 begins as enabled on DP-1 in SST mode * Display 1 switches to MST mode, exposes one sink in MST mode * Userspace does non-blocking modeset to disable the SST display * Userspace does non-blocking modeset to enable the MST display with a different CRTC, but the SST display hasn't been fully taken down yet * Execution order between the last two commits isn't guaranteed since they share no drm resources We can fix this however, by ensuring that we always pull in the atomic topology state whenever a connector capable of driving an MST display performs its atomic check - and then tracking CRTC commits happening on the SST connector in the MST topology state. So, let's add some simple helpers for doing that and hook them up in various drivers. v2: * Use intel_dp_mst_source_support() to check for MST support in i915, fixes CI failures Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Wayne Lin <Wayne.Lin@amd.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Fangzhi Zuo <Jerry.Zuo@amd.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Sean Paul <sean@poorly.run> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220817193847.557945-14-lyude@redhat.com
2022-08-23drm/nouveau/kms: Cache DP encoders in nouveau_connectorLyude Paul
Post-NV50, the only kind of encoder you'll find for DP connectors on Nvidia GPUs are SORs (serial output resources). Because SORs have fixed associations with their connectors, we can correctly assume that any DP connector on a nvidia GPU will have exactly one SOR encoder routed to it for DisplayPort. Since we're going to need to be able to retrieve this fixed SOR DP encoder much more often as a result of hooking up MST helpers for tracking SST<->MST transitions in atomic states, let's simply cache this encoder in nouveau_connector for any DP connectors on the system to avoid looking it up each time. This isn't safe for NV50 since PIORs then come into play, however there's no code pre-NV50 that would need to look this up anyhow - so it's not really an issue. Signed-off-by: Lyude Paul <lyude@redhat.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220817193847.557945-12-lyude@redhat.com
2022-08-16drm/nouveau/kms/nv140-: Disable interlacingLyude Paul
As it turns out: while Nvidia does actually have interlacing knobs on their GPU still pretty much no current GPUs since Volta actually support it. Trying interlacing on these GPUs will result in NVDisplay being quite unhappy like so: nouveau 0000:1f:00.0: disp: chid 0 stat 00004802 reason 4 [INVALID_ARG] mthd 2008 data 00000001 code 00080000 nouveau 0000:1f:00.0: disp: chid 0 stat 10005080 reason 5 [INVALID_STATE] mthd 0200 data 00000001 code 00000001 So let's fix this by following the same behavior Nvidia's driver does and disable interlacing entirely. Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: stable@vger.kernel.org Reviewed-by: Karol Herbst <kherbst@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220816180436.156310-1-lyude@redhat.com
2022-07-27Merge tag 'topic/nouveau-misc-2022-07-27' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm into drm-next drm/nouveau-misc: display patches. These are just some precursor and cleanup display patches from Ben, tested by Lyude. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Dave Airlie <airlied@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/CAPM=9ty0R37q0mohBr_CegpYLXK2=fAH54QfAsMhHfPygTsdQA@mail.gmail.com
2022-07-27drm/nouveau/disp: add connector classBen Skeggs
Will be used to provide more solid driver interfaces in general, but the immediate motivation is work towards fixing issues with handling hotplug/DP IRQ events. Its use is currently limited to where we support non-polled hotplug already (ie. any GPU since NV40ish era, where our DCB handling works well enough), until that gets cleaned up someday. v2: - use ?: (lyude) Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2022-07-14drm/nouveau/kms: Fix failure path for creating DP connectorsLyude Paul
It looks like that when we moved nouveau over to using drm_dp_aux_init() and registering it's aux bus during late connector registration, we totally forgot to fix the failure codepath in nouveau_connector_create() - as it still seems to assume that drm_dp_aux_init() can fail (it can't). So, let's fix that and also add a missing check to ensure that we've properly allocated nv_connector->aux.name while we're at it. Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: David Airlie <airlied@linux.ie> Fixes: fd43ad9d47e7 ("drm/nouveau/kms/nv50-: Move AUX adapter reg to connector late register/early unregister") Cc: <stable@vger.kernel.org> # v5.14+ Link: https://patchwork.freedesktop.org/patch/msgid/20220526204313.656473-1-lyude@redhat.com
2021-07-01Merge tag 'drm-next-2021-07-01' of git://anongit.freedesktop.org/drm/drmLinus Torvalds
Pull drm updates from Dave Airlie: "Highlights: - AMD enables two more GPUs, with resulting header files - i915 has started to move to TTM for discrete GPU and enable DG1 discrete GPU support (not by default yet) - new HyperV drm driver - vmwgfx adds arm64 support - TTM refactoring ongoing - 16bpc display support for AMD hw Otherwise it's just the usual insane amounts of work all over the place in lots of drivers and the core, as mostly summarised below: Core: - mark AGP ioctls as legacy - disable force probing for non-master clients - HDR metadata property helpers - HDMI infoframe signal colorimetry support - remove drm_device.pdev pointer - remove DRM_KMS_FB_HELPER config option - remove drm_pci_alloc/free - drm_err_*/drm_dbg_* helpers - use drm driver names for fbdev - leaked DMA handle fix - 16bpc fixed point format fourcc - add prefetching memcpy for WC - Documentation fixes aperture: - add aperture ownership helpers dp: - aux fixes - downstream 0 port handling - use extended base receiver capability DPCD - Rename DP_PSR_SELECTIVE_UPDATE to better mach eDP spec - mst: use khz as link rate during init - VCPI fixes for StarTech hub ttm: - provide tt_shrink file via debugfs - warn about freeing pinned BOs - fix swapping error handling - move page alignment into BO - cleanup ttm_agp_backend - add ttm_sys_manager - don't override vm_ops - ttm_bo_mmap removed - make ttm_resource base of all managers - remove VM_MIXEDMAP usage panel: - sysfs_emit support - simple: runtime PM support - simple: power up panel when reading EDID + caching bridge: - MHDP8546: HDCP support + DT bindings - MHDP8546: Register DP AUX channel with userspace - TI SN65DSI83 + SN65DSI84: add driver - Sil8620: Fix module dependencies - dw-hdmi: make CEC driver loading optional - Ti-sn65dsi86: refclk fixes, subdrivers, runtime pm - It66121: Add driver + DT bindings - Adv7511: Support I2S IEC958 encoding - Anx7625: fix power-on delay - Nwi-dsi: Modesetting fixes; Cleanups - lt6911: add missing MODULE_DEVICE_TABLE - cdns: fix PM reference leak hyperv: - add new DRM driver for HyperV graphics efifb: - non-PCI device handling fixes i915: - refactor IP/device versioning - XeLPD Display IP preperation work - ADL-P enablement patches - DG1 uAPI behind BROKEN - disable mmap ioctl for discerte GPUs - start enabling HuC loading for Gen12+ - major GuC backend rework for new platforms - initial TTM support for Discrete GPUs - locking rework for TTM prep - use correct max source link rate for eDP - %p4cc format printing - GLK display fixes - VLV DSI panel power fixes - PSR2 disabled for RKL and ADL-S - ACPI _DSM invalid access fixed - DMC FW path abstraction - ADL-S PCI ID update - uAPI headers converted to kerneldoc - initial LMEM support for DG1 - x86/gpu: add Jasperlake to gen11 early quirks amdgpu: - Aldebaran updates + initial SR-IOV - new GPU: Beige Goby and Yellow Carp support - more LTTPR display work - Vangogh updates - SDMA 5.x GCR fixes - PCIe ASPM support - Renoir TMZ enablement - initial multiple eDP panel support - use fdinfo to track devices/process info - pin/unpin TTM fixes - free resource on fence usage query - fix fence calculation - fix hotunplug/suspend issues - GC/MM register access macro cleanup for SR-IOV - W=1 fixes - ACPI ATCS/ATIF handling rework - 16bpc fixed point format support - Initial smartshift support - RV/PCO power tuning fixes - new INFO query for additional vbios info amdkfd: - SR-IOV aldebaran support - HMM SVM support radeon: - SMU regression fixes - Oland flickering fix vmwgfx: - enable console with fbdev emulation - fix cpu updates of coherent multisample surfaces - remove reservation semaphore - add initial SVGA3 support - support arm64 msm: - devcoredump support for display errors - dpu/dsi: yaml bindings conversion - mdp5: alpha/blend_mode/zpos support - a6xx: cached coherent buffer support - gpu iova fault improvement - a660 support rockchip: - RK3036 win1 scaling support - RK3066/3188 missing register support - RK3036/3066/3126/3188 alpha support mediatek: - MT8167 HDMI support - MT8183 DPI dual edge support tegra: - fixed YUV support/scaling on Tegra186+ ast: - use pcim_iomap - fix DP501 EDID bochs: - screen blanking support etnaviv: - export more GPU ID values to userspace - add HWDB entry for GPU on i.MX8MP - rework linear window calcs exynos: - pm runtime changes imx: - Annotate dma_fence critical section - fix PRG modifiers after drmm conversion - Add 8 pixel alignment fix for 1366x768 - fix YUV advertising - add color properties ingenic: - IPU planes fix panfrost: - Mediatek MT8183 support + DT bindings - export AFBC_FEATURES register to userspace simpledrm: - %pr for printing resources nouveau: - pin/unpin TTM fixes qxl: - unpin shadow BO virtio: - create dumb BOs as guest blob vkms: - drmm_universal_plane_alloc - add XRGB plane composition - overlay support" * tag 'drm-next-2021-07-01' of git://anongit.freedesktop.org/drm/drm: (1570 commits) drm/i915: Reinstate the mmap ioctl for some platforms drm/i915/dsc: abstract helpers to get bigjoiner primary/secondary crtc Revert "drm/msm/mdp5: provide dynamic bandwidth management" drm/msm/mdp5: provide dynamic bandwidth management drm/msm/mdp5: add perf blocks for holding fudge factors drm/msm/mdp5: switch to standard zpos property drm/msm/mdp5: add support for alpha/blend_mode properties drm/msm/mdp5: use drm_plane_state for pixel blend mode drm/msm/mdp5: use drm_plane_state for storing alpha value drm/msm/mdp5: use drm atomic helpers to handle base drm plane state drm/msm/dsi: do not enable PHYs when called for the slave DSI interface drm/msm: Add debugfs to trigger shrinker drm/msm/dpu: Avoid ABBA deadlock between IRQ modules drm/msm: devcoredump iommu fault support iommu/arm-smmu-qcom: Add stall support drm/msm: Improve the a6xx page fault handler iommu/arm-smmu-qcom: Add an adreno-smmu-priv callback to get pagefault info iommu/arm-smmu: Add support for driver IOMMU fault handlers drm/msm: export hangcheck_period in debugfs drm/msm/a6xx: add support for Adreno 660 GPU ...
2021-06-03drm/nouveau: Fix fall-through warnings for ClangGustavo A. R. Silva
In preparation to enable -Wimplicit-fallthrough for Clang, fix a couple of warnings by explicitly adding a couple of break statements instead of letting the code fall through to the next case. Link: https://github.com/KSPP/linux/issues/115 Reviewed-by: Karol Herbst <kherbst@redhat.com> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
2021-05-13drm/nouveau: Remove invalid reference to struct drm_device.pdevThomas Zimmermann
The pdev field got removed from struct drm_device recently. Replace the invalid reference with an upcast from the struct's dev field. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Dave Airlie <airlied@redhat.com> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Fixes: b347e04452ff ("drm: Remove pdev field from struct drm_device") Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Maxime Ripard <maxime@cerno.tech> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Link: https://patchwork.freedesktop.org/patch/msgid/20210512185527.26050-1-tzimmermann@suse.de
2021-04-27drm/dp: Add backpointer to drm_device in drm_dp_auxLyude Paul
This is something that we've wanted for a while now: the ability to actually look up the respective drm_device for a given drm_dp_aux struct. This will also allow us to transition over to using the drm_dbg_*() helpers for debug message printing, as we'll finally have a drm_device to reference for doing so. Note that there is one limitation with this - because some DP AUX adapters exist as platform devices which are initialized independently of their respective DRM devices, one cannot rely on drm_dp_aux->drm_dev to always be non-NULL until drm_dp_aux_register() has been called. We make sure to point this out in the documentation for struct drm_dp_aux. v3: * Add WARN_ON_ONCE() to drm_dp_aux_register() if drm_dev isn't filled out Signed-off-by: Lyude Paul <lyude@redhat.com> Acked-by: Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210423184309.207645-4-lyude@redhat.com Reviewed-by: Dave Airlie <airlied@redhat.com>
2021-04-27drm/nouveau/kms/nv50-: Move AUX adapter reg to connector late register/early ↵Lyude Paul
unregister Since AUX adapters on nouveau have their respective DRM connectors as parents, we need to make sure that we register then after their connectors. Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210423184309.207645-3-lyude@redhat.com Reviewed-by: Dave Airlie <airlied@redhat.com>
2021-01-29drm/nouveau/kms: handle mDP connectorsKarol Herbst
In some cases we have the handle those explicitly as the fallback connector type detection fails and marks those as eDP connectors. Attempting to use such a connector with mutter leads to a crash of mutter as it ends up with two eDP displays. Information is taken from the official DCB documentation. Cc: stable@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: Ben Skeggs <bskeggs@redhat.com> Reported-by: Mark Pearson <markpearson@lenovo.com> Tested-by: Mark Pearson <markpearson@lenovo.com> Signed-off-by: Karol Herbst <kherbst@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2021-01-13drm/nouveau: Remove references to struct drm_device.pdevThomas Zimmermann
Using struct drm_device.pdev is deprecated. Convert nouveau to struct drm_device.dev. No functional changes. v3: * fix nv04_dfp_update_backlight() as well (Jeremy) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jeremy Cline <jcline@redhat.com> Cc: Ben Skeggs <bskeggs@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210107080748.4768-8-tzimmermann@suse.de
2020-11-14drm/nouveau/kms: Fix NULL pointer dereference in nouveau_connector_detect_depthAlexander Kapshuk
This oops manifests itself on the following hardware: 01:00.0 VGA compatible controller: NVIDIA Corporation G98M [GeForce G 103M] (rev a1) Oct 09 14:17:46 lp-sasha kernel: BUG: kernel NULL pointer dereference, address: 0000000000000000 Oct 09 14:17:46 lp-sasha kernel: #PF: supervisor read access in kernel mode Oct 09 14:17:46 lp-sasha kernel: #PF: error_code(0x0000) - not-present page Oct 09 14:17:46 lp-sasha kernel: PGD 0 P4D 0 Oct 09 14:17:46 lp-sasha kernel: Oops: 0000 [#1] SMP PTI Oct 09 14:17:46 lp-sasha kernel: CPU: 1 PID: 191 Comm: systemd-udevd Not tainted 5.9.0-rc8-next-20201009 #38 Oct 09 14:17:46 lp-sasha kernel: Hardware name: Hewlett-Packard Compaq Presario CQ61 Notebook PC/306A, BIOS F.03 03/23/2009 Oct 09 14:17:46 lp-sasha kernel: RIP: 0010:nouveau_connector_detect_depth+0x71/0xc0 [nouveau] Oct 09 14:17:46 lp-sasha kernel: Code: 0a 00 00 48 8b 49 48 c7 87 b8 00 00 00 06 00 00 00 80 b9 4d 0a 00 00 00 75 1e 83 fa 41 75 05 48 85 c0 75 29 8b 81 10 0d 00 00 <39> 06 7c 25 f6 81 14 0d 00 00 02 75 b7 c3 80 b9 0c 0d 00 00 00 75 Oct 09 14:17:46 lp-sasha kernel: RSP: 0018:ffffc9000028f8c0 EFLAGS: 00010297 Oct 09 14:17:46 lp-sasha kernel: RAX: 0000000000014c08 RBX: ffff8880369d4000 RCX: ffff8880369d3000 Oct 09 14:17:46 lp-sasha kernel: RDX: 0000000000000040 RSI: 0000000000000000 RDI: ffff8880369d4000 Oct 09 14:17:46 lp-sasha kernel: RBP: ffff88800601cc00 R08: ffff8880051da298 R09: ffffffff8226201a Oct 09 14:17:46 lp-sasha kernel: R10: ffff88800469aa80 R11: ffff888004c84ff8 R12: 0000000000000000 Oct 09 14:17:46 lp-sasha kernel: R13: ffff8880051da000 R14: 0000000000002000 R15: 0000000000000003 Oct 09 14:17:46 lp-sasha kernel: FS: 00007fd0192b3440(0000) GS:ffff8880bc900000(0000) knlGS:0000000000000000 Oct 09 14:17:46 lp-sasha kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Oct 09 14:17:46 lp-sasha kernel: CR2: 0000000000000000 CR3: 0000000004976000 CR4: 00000000000006e0 Oct 09 14:17:46 lp-sasha kernel: Call Trace: Oct 09 14:17:46 lp-sasha kernel: nouveau_connector_get_modes+0x1e6/0x240 [nouveau] Oct 09 14:17:46 lp-sasha kernel: ? kfree+0xb9/0x240 Oct 09 14:17:46 lp-sasha kernel: ? drm_connector_list_iter_next+0x7c/0xa0 Oct 09 14:17:46 lp-sasha kernel: drm_helper_probe_single_connector_modes+0x1ba/0x7c0 Oct 09 14:17:46 lp-sasha kernel: drm_client_modeset_probe+0x27e/0x1360 Oct 09 14:17:46 lp-sasha kernel: ? nvif_object_sclass_put+0xc/0x20 [nouveau] Oct 09 14:17:46 lp-sasha kernel: ? nouveau_cli_init+0x3cc/0x440 [nouveau] Oct 09 14:17:46 lp-sasha kernel: ? ktime_get_mono_fast_ns+0x49/0xa0 Oct 09 14:17:46 lp-sasha kernel: ? nouveau_drm_open+0x4e/0x180 [nouveau] Oct 09 14:17:46 lp-sasha kernel: __drm_fb_helper_initial_config_and_unlock+0x3f/0x4a0 Oct 09 14:17:46 lp-sasha kernel: ? drm_file_alloc+0x18f/0x260 Oct 09 14:17:46 lp-sasha kernel: ? mutex_lock+0x9/0x40 Oct 09 14:17:46 lp-sasha kernel: ? drm_client_init+0x110/0x160 Oct 09 14:17:46 lp-sasha kernel: nouveau_fbcon_init+0x14d/0x1c0 [nouveau] Oct 09 14:17:46 lp-sasha kernel: nouveau_drm_device_init+0x1c0/0x880 [nouveau] Oct 09 14:17:46 lp-sasha kernel: nouveau_drm_probe+0x11a/0x1e0 [nouveau] Oct 09 14:17:46 lp-sasha kernel: pci_device_probe+0xcd/0x140 Oct 09 14:17:46 lp-sasha kernel: really_probe+0xd8/0x400 Oct 09 14:17:46 lp-sasha kernel: driver_probe_device+0x4a/0xa0 Oct 09 14:17:46 lp-sasha kernel: device_driver_attach+0x9c/0xc0 Oct 09 14:17:46 lp-sasha kernel: __driver_attach+0x6f/0x100 Oct 09 14:17:46 lp-sasha kernel: ? device_driver_attach+0xc0/0xc0 Oct 09 14:17:46 lp-sasha kernel: bus_for_each_dev+0x75/0xc0 Oct 09 14:17:46 lp-sasha kernel: bus_add_driver+0x106/0x1c0 Oct 09 14:17:46 lp-sasha kernel: driver_register+0x86/0xe0 Oct 09 14:17:46 lp-sasha kernel: ? 0xffffffffa044e000 Oct 09 14:17:46 lp-sasha kernel: do_one_initcall+0x48/0x1e0 Oct 09 14:17:46 lp-sasha kernel: ? _cond_resched+0x11/0x60 Oct 09 14:17:46 lp-sasha kernel: ? kmem_cache_alloc_trace+0x19c/0x1e0 Oct 09 14:17:46 lp-sasha kernel: do_init_module+0x57/0x220 Oct 09 14:17:46 lp-sasha kernel: __do_sys_finit_module+0xa0/0xe0 Oct 09 14:17:46 lp-sasha kernel: do_syscall_64+0x33/0x40 Oct 09 14:17:46 lp-sasha kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9 Oct 09 14:17:46 lp-sasha kernel: RIP: 0033:0x7fd01a060d5d Oct 09 14:17:46 lp-sasha kernel: 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 e3 70 0c 00 f7 d8 64 89 01 48 Oct 09 14:17:46 lp-sasha kernel: RSP: 002b:00007ffc8ad38a98 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 Oct 09 14:17:46 lp-sasha kernel: RAX: ffffffffffffffda RBX: 0000563f6e7fd530 RCX: 00007fd01a060d5d Oct 09 14:17:46 lp-sasha kernel: RDX: 0000000000000000 RSI: 00007fd01a19f95d RDI: 000000000000000f Oct 09 14:17:46 lp-sasha kernel: RBP: 0000000000020000 R08: 0000000000000000 R09: 0000000000000007 Oct 09 14:17:46 lp-sasha kernel: R10: 000000000000000f R11: 0000000000000246 R12: 00007fd01a19f95d Oct 09 14:17:46 lp-sasha kernel: R13: 0000000000000000 R14: 0000563f6e7fbc10 R15: 0000563f6e7fd530 Oct 09 14:17:46 lp-sasha kernel: Modules linked in: nouveau(+) ttm xt_string xt_mark xt_LOG vgem v4l2_dv_timings uvcvideo ulpi udf ts_kmp ts_fsm ts_bm snd_aloop sil164 qat_dh895xccvf nf_nat_sip nf_nat_irc nf_nat_ftp nf_nat nf_log_ipv6 nf_log_ipv4 nf_log_common ltc2990 lcd intel_qat input_leds i2c_mux gspca_main videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common videodev mc drivetemp cuse fuse crc_itu_t coretemp ch7006 ath5k ath algif_hash Oct 09 14:17:46 lp-sasha kernel: CR2: 0000000000000000 Oct 09 14:17:46 lp-sasha kernel: ---[ end trace 0ddafe218ad30017 ]--- Oct 09 14:17:46 lp-sasha kernel: RIP: 0010:nouveau_connector_detect_depth+0x71/0xc0 [nouveau] Oct 09 14:17:46 lp-sasha kernel: Code: 0a 00 00 48 8b 49 48 c7 87 b8 00 00 00 06 00 00 00 80 b9 4d 0a 00 00 00 75 1e 83 fa 41 75 05 48 85 c0 75 29 8b 81 10 0d 00 00 <39> 06 7c 25 f6 81 14 0d 00 00 02 75 b7 c3 80 b9 0c 0d 00 00 00 75 Oct 09 14:17:46 lp-sasha kernel: RSP: 0018:ffffc9000028f8c0 EFLAGS: 00010297 Oct 09 14:17:46 lp-sasha kernel: RAX: 0000000000014c08 RBX: ffff8880369d4000 RCX: ffff8880369d3000 Oct 09 14:17:46 lp-sasha kernel: RDX: 0000000000000040 RSI: 0000000000000000 RDI: ffff8880369d4000 Oct 09 14:17:46 lp-sasha kernel: RBP: ffff88800601cc00 R08: ffff8880051da298 R09: ffffffff8226201a Oct 09 14:17:46 lp-sasha kernel: R10: ffff88800469aa80 R11: ffff888004c84ff8 R12: 0000000000000000 Oct 09 14:17:46 lp-sasha kernel: R13: ffff8880051da000 R14: 0000000000002000 R15: 0000000000000003 Oct 09 14:17:46 lp-sasha kernel: FS: 00007fd0192b3440(0000) GS:ffff8880bc900000(0000) knlGS:0000000000000000 Oct 09 14:17:46 lp-sasha kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Oct 09 14:17:46 lp-sasha kernel: CR2: 0000000000000000 CR3: 0000000004976000 CR4: 00000000000006e0 The disassembly: Code: 0a 00 00 48 8b 49 48 c7 87 b8 00 00 00 06 00 00 00 80 b9 4d 0a 00 00 00 75 1e 83 fa 41 75 05 48 85 c0 75 29 8b 81 10 0d 00 00 <39> 06 7c 25 f6 81 14 0d 00 00 02 75 b7 c3 80 b9 0c 0d 00 00 00 75 All code ======== 0: 0a 00 or (%rax),%al 2: 00 48 8b add %cl,-0x75(%rax) 5: 49 rex.WB 6: 48 c7 87 b8 00 00 00 movq $0x6,0xb8(%rdi) d: 06 00 00 00 11: 80 b9 4d 0a 00 00 00 cmpb $0x0,0xa4d(%rcx) 18: 75 1e jne 0x38 1a: 83 fa 41 cmp $0x41,%edx 1d: 75 05 jne 0x24 1f: 48 85 c0 test %rax,%rax 22: 75 29 jne 0x4d 24: 8b 81 10 0d 00 00 mov 0xd10(%rcx),%eax 2a:* 39 06 cmp %eax,(%rsi) <-- trapping instruction 2c: 7c 25 jl 0x53 2e: f6 81 14 0d 00 00 02 testb $0x2,0xd14(%rcx) 35: 75 b7 jne 0xffffffffffffffee 37: c3 retq 38: 80 b9 0c 0d 00 00 00 cmpb $0x0,0xd0c(%rcx) 3f: 75 .byte 0x75 Code starting with the faulting instruction =========================================== 0: 39 06 cmp %eax,(%rsi) 2: 7c 25 jl 0x29 4: f6 81 14 0d 00 00 02 testb $0x2,0xd14(%rcx) b: 75 b7 jne 0xffffffffffffffc4 d: c3 retq e: 80 b9 0c 0d 00 00 00 cmpb $0x0,0xd0c(%rcx) 15: 75 .byte 0x75 objdump -SF --disassemble=nouveau_connector_detect_depth [...] if (nv_connector->edid && c85e1: 83 fa 41 cmp $0x41,%edx c85e4: 75 05 jne c85eb <nouveau_connector_detect_depth+0x6b> (File Offset: 0xc866b) c85e6: 48 85 c0 test %rax,%rax c85e9: 75 29 jne c8614 <nouveau_connector_detect_depth+0x94> (File Offset: 0xc8694) nv_connector->type == DCB_CONNECTOR_LVDS_SPWG) duallink = ((u8 *)nv_connector->edid)[121] == 2; else duallink = mode->clock >= bios->fp.duallink_transition_clk; if ((!duallink && (bios->fp.strapless_is_24bit & 1)) || c85eb: 8b 81 10 0d 00 00 mov 0xd10(%rcx),%eax c85f1: 39 06 cmp %eax,(%rsi) c85f3: 7c 25 jl c861a <nouveau_connector_detect_depth+0x9a> (File Offset: 0xc869a) ( duallink && (bios->fp.strapless_is_24bit & 2))) c85f5: f6 81 14 0d 00 00 02 testb $0x2,0xd14(%rcx) c85fc: 75 b7 jne c85b5 <nouveau_connector_detect_depth+0x35> (File Offset: 0xc8635) connector->display_info.bpc = 8; [...] % scripts/faddr2line /lib/modules/5.9.0-rc8-next-20201009/kernel/drivers/gpu/drm/nouveau/nouveau.ko nouveau_connector_detect_depth+0x71/0xc0 nouveau_connector_detect_depth+0x71/0xc0: nouveau_connector_detect_depth at /home/sasha/linux-next/drivers/gpu/drm/nouveau/nouveau_connector.c:891 It is actually line 889. See the disassembly below. 889 duallink = mode->clock >= bios->fp.duallink_transition_clk; The NULL pointer being dereferenced is mode. Git bisect has identified the following commit as bad: f28e32d3906e drm/nouveau/kms: Don't change EDID when it hasn't actually changed Here is the chain of events that causes the oops. On entry to nouveau_connector_detect_lvds, edid is set to NULL. The call to nouveau_connector_detect sets nv_connector->edid to valid memory, with status set to connector_status_connected and the flow of execution branching to the out label. The subsequent call to nouveau_connector_set_edid erronously clears nv_connector->edid, via the local edid pointer which remains set to NULL. Fix this by setting edid to the value of the just acquired nv_connector->edid and executing the body of nouveau_connector_set_edid only if nv_connector->edid and edid point to different memory addresses thus preventing nv_connector->edid from being turned into a dangling pointer. Fixes: f28e32d3906e ("drm/nouveau/kms: Don't change EDID when it hasn't actually changed") Signed-off-by: Alexander Kapshuk <alexander.kapshuk@gmail.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2020-10-30drm/nouveau/kms/nv50-: Get rid of bogus nouveau_conn_mode_valid()Lyude Paul
Ville also pointed out that I got a lot of the logic here wrong as well, whoops. While I don't think anyone's likely using 3D output with nouveau, the next patch will make nouveau_conn_mode_valid() make a lot less sense. So, let's just get rid of it and open-code it like before, while taking care to move the 3D frame packing calculations on the dot clock into the right place. Signed-off-by: Lyude Paul <lyude@redhat.com> Fixes: d6a9efece724 ("drm/nouveau/kms/nv50-: Share DP SST mode_valid() handling with MST") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: <stable@vger.kernel.org> # v5.8+ Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2020-08-31drm/nouveau/kms: Don't change EDID when it hasn't actually changedLyude Paul
Currently in nouveau_connector_ddc_detect() and nouveau_connector_detect_lvds(), we start the connector probing process by releasing the previous EDID and informing DRM of the change. However, since commit 5186421cbfe2 ("drm: Introduce epoch counter to drm_connector") drm_connector_update_edid_property() actually checks whether the new EDID we've specified is different from the previous one, and updates the connector's epoch accordingly if it is. But, because we always set the EDID to NULL first in nouveau_connector_ddc_detect() and nouveau_connector_detect_lvds() we end up making DRM think that the EDID changes every single time we do a connector probe - which isn't needed. So, let's fix this by not clearing the EDID at the start of the connector probing process, and instead simply changing or removing it once near the end of the probing process. This will help prevent us from sending unneeded hotplug events to userspace when nothing has actually changed. Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Ben Skeggs <bskeggs@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200826182456.322681-19-lyude@redhat.com
2020-08-31drm/nouveau/kms: Only use hpd_work for reprobing in HPD pathsLyude Paul
Currently we perform both short IRQ handling for DP, and connector reprobing in the HPD IRQ handler. However since we need to grab connection_mutex in order to reprobe a connector, in theory we could accidentally block ourselves from handling any short IRQs until after a modeset completes if a connector hotplug happens to occur in parallel with a modeset. I haven't seen this actually happen yet, but since we're cleaning up nouveau's hotplug handling code anyway and we already have a hpd worker, we can simply fix this by only relying on the HPD worker to actually reprobe connectors when we receive a HPD IRQ. We also add a mask to nouveau_drm to keep track of which connectors are waiting to be reprobed in response to an HPD IRQ. Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Ben Skeggs <bskeggs@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200826182456.322681-13-lyude@redhat.com
2020-08-31drm/nouveau/kms: Move drm_dp_cec_unset_edid() into nouveau_connector_detect()Lyude Paul
For whatever reason we currently unset the EDID for DP CEC support when responding to the connector being unplugged, instead of just doing it in nouveau_connector_detect() where we set the CEC EDID. This isn't really needed and could even potentially cause us to forget to unset the EDID if the connector is removed without a corresponding hpd event, so let's fix that. Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Ben Skeggs <bskeggs@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200826182456.322681-12-lyude@redhat.com
2020-08-31drm/nouveau/kms/nv50-: Refactor and cleanup DP HPD handlingLyude Paul
First some backstory here: Currently, we keep track of whether or not we've enabled MST or not by trying to piggy-back off the MST helpers. This means that in order to check whether MST is enabled or not, we actually need to grab drm_dp_mst_topology_mgr.lock. Back when I originally wrote this, I did this piggy-backing with the intention that I'd eventually be teaching our MST helpers how to recover when an MST device has stopped responding, which in turn would require the MST helpers having a way of disabling MST independently of the driver. Note that this was before I reworked locking in the MST helpers, so at the time we were sticking random things under &mgr->lock - which grabbing this lock was meant to protect against. This never came to fruition because doing such a reset safely turned out to be a lot more painful and impossible then it sounds, and also just risks us working around issues with our MST handlers that should be properly fixed instead. Even if it did though, simply calling drm_dp_mst_topology_mgr_set_mst() from the MST helpers (with the exception of when we're tearing down our MST managers, that's always OK) wouldn't have been a bad idea, since drivers like nouveau and i915 need to do their own book keeping immediately after disabling MST. So-implementing that would likely require adding a hook for helper-triggered MST disables anyway. So, fast forward to now - we want to start adding support for all of the miscellaneous bits of the DP protocol (for both SST and MST) we're missing before moving on to supporting more complicated features like supporting different BPP values on MST, DSC, etc. Since many of these features only exist on SST and make use of DP HPD IRQs, we want to be able to atomically check whether we're servicing an MST IRQ or SST IRQ in nouveau_connector_hotplug(). Currently we literally don't do this at all, and just handle any kind of possible DP IRQ we could get including ESIs - even if MST isn't actually enabled. This would be very complicated and difficult to fix if we need to hold &mgr->lock while handling SST IRQs to ensure that the MST topology state doesn't change under us. What we really want here is to do our own tracking of whether MST is enabled or not, similar to drivers like i915, and define our own locking order to decomplicate things and avoid hitting locking issues in the future. So, let's do this by refactoring our MST probing/enabling code to use our own MST bookkeeping, along with adding a lock for protecting DP state that needs to be checked outside of our connector probing functions. While we're at it, we also remove a bunch of unneeded steps we perform when probing/enabling MST: * Enabling bits in MSTM_CTRL before calling drm_dp_mst_topology_mgr_set_mst(). I don't think these ever actually did anything, since the nvif methods for enabling MST don't actually do anything DPCD related and merely indicate to nvkm that we've turned on MST. * Checking the MSTM_CTRL bit is intact when checking the state of an enabled MST topology in nv50_mstm_detect(). I just added this to be safe originally, but now that we try reading the DPCD when probing DP connectors it shouldn't be needed as that will abort our hotplug probing if the device was removed well before we start checking for MST.. * All of the duplicate DPCD version checks. This leaves us with much nicer looking code, a much more sensible locking scheme, and an easy way of checking whether MST is enabled or not for handling DP HPD IRQs. v2: * Get rid of accidental newlines v4: * Fix uninitialized usage of mstm in nv50_mstm_detect() - thanks kernel bot! Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Ben Skeggs <bskeggs@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200826182456.322681-9-lyude@redhat.com
2020-08-31drm/nouveau/kms: Search for encoders' connectors properlyLyude Paul
While the way we find the associated connector for an encoder is just fine for legacy modesetting, it's not correct for nv50+ since that uses atomic modesetting. For reference, see the drm_encoder kdocs. Fix this by removing nouveau_encoder_connector_get(), and replacing it with nv04_encoder_get_connector(), nv50_outp_get_old_connector(), and nv50_outp_get_new_connector(). v2: * Don't line-wrap for_each_(old|new)_connector_in_state in nv50_outp_get_(old|new)_connector() - sravn v3: * Fix potential uninitialized usage of nv_connector (needs to be initialized to NULL at the start). Thanks kernel test robot! v4: * Actually fix uninitialized nv_connector usage in nv50_audio_component_get_eld(). The previous fix wouldn't have worked since we would have started out with nv_connector == NULL, but wouldn't clear it after a single drm_for_each_encoder() iteration. Thanks again Kernel bot! Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Ben Skeggs <bskeggs@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200826182456.322681-7-lyude@redhat.com
2020-08-31drm/nouveau/kms/nv50-: Remove open-coded drm_dp_read_desc()Lyude Paul
Noticed this while going through our DP code - we use an open-coded version of drm_dp_read_desc() instead of just using the helper, so change that. This will also let us use quirks in the future if we end up needing them. Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Ben Skeggs <bskeggs@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200826182456.322681-3-lyude@redhat.com
2020-07-24drm/nouveau/nvif: give every notify object a human-readable nameBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2020-07-24drm/nouveau: Use fallthrough pseudo-keywordGustavo A. R. Silva
Replace the existing /* fall through */ comments and its variants with the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary fall-through markings when it is the case. [1] https://www.kernel.org/doc/html/latest/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2020-07-24drm/nouveau: Fix reference count leak in nouveau_connector_detectAditya Pakki
nouveau_connector_detect() calls pm_runtime_get_sync and in turn increments the reference count. In case of failure, decrement the ref count before returning the error. Signed-off-by: Aditya Pakki <pakki001@umn.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2020-06-24Merge tag 'drm-misc-next-2020-06-19' of ↵Dave Airlie
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 <airlied@redhat.com> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/001cd9a6-405d-4e29-43d8-354f53ae4e8b@linux.intel.com
2020-05-27drm: Nuke mode->vrefreshVille Syrjälä
Get rid of mode->vrefresh and just calculate it on demand. Saves a bit of space and avoids the cached value getting out of sync with reality. Mostly done with cocci, with the following manual fixups: - Remove the now empty loop in drm_helper_probe_single_connector_modes() - Fix __MODE() macro in ch7006_mode.c - Fix DRM_MODE_ARG() macro in drm_modes.h - Remove leftover comment from samsung_s6d16d0_mode - Drop the TODO @@ @@ struct drm_display_mode { ... - int vrefresh; ... }; @@ identifier N; expression E; @@ struct drm_display_mode N = { - .vrefresh = E }; @@ identifier N; expression E; @@ struct drm_display_mode N[...] = { ..., { - .vrefresh = E } ,... }; @@ expression E; @@ { DRM_MODE(...), - .vrefresh = E, } @@ identifier M, R; @@ int drm_mode_vrefresh(const struct drm_display_mode *M) { ... - if (M->vrefresh > 0) - R = M->vrefresh; - else if (...) { ... } ... } @@ struct drm_display_mode *p; expression E; @@ ( - p->vrefresh = E; | - p->vrefresh + drm_mode_vrefresh(p) ) @@ struct drm_display_mode s; expression E; @@ ( - s.vrefresh = E; | - s.vrefresh + drm_mode_vrefresh(&s) ) @@ expression E; @@ - drm_mode_vrefresh(E) ? drm_mode_vrefresh(E) : drm_mode_vrefresh(E) + drm_mode_vrefresh(E) @find_substruct@ identifier X; identifier S; @@ struct X { ... struct drm_display_mode S; ... }; @@ identifier find_substruct.S; expression E; identifier I; @@ { .S = { - .vrefresh = E } } @@ identifier find_substruct.S; identifier find_substruct.X; expression E; identifier I; @@ struct X I[...] = { ..., .S = { - .vrefresh = E } ,... }; v2: Drop TODO v3: Rebase v4: Rebase Cc: Andrzej Hajda <a.hajda@samsung.com> Cc: Neil Armstrong <narmstrong@baylibre.com> Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com> Cc: Jonas Karlman <jonas@kwiboo.se> Cc: Jernej Skrabec <jernej.skrabec@siol.net> Cc: Inki Dae <inki.dae@samsung.com> Cc: Joonyoung Shim <jy0922.shim@samsung.com> Cc: Seung-Woo Kim <sw0312.kim@samsung.com> Cc: Kyungmin Park <kyungmin.park@samsung.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: CK Hu <ck.hu@mediatek.com> Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Jerry Han <hanxu5@huaqin.corp-partner.google.com> Cc: Icenowy Zheng <icenowy@aosc.io> Cc: Jagan Teki <jagan@amarulasolutions.com> Cc: Stefan Mavrodiev <stefan@olimex.com> Cc: Robert Chiras <robert.chiras@nxp.com> Cc: "Guido Günther" <agx@sigxcpu.org> Cc: Purism Kernel Team <kernel@puri.sm> Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org> Cc: Vincent Abriou <vincent.abriou@st.com> Cc: VMware Graphics <linux-graphics-maintainer@vmware.com> Cc: Thomas Hellstrom <thellstrom@vmware.com> Cc: linux-amlogic@lists.infradead.org Cc: nouveau@lists.freedesktop.org Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200428171940.19552-4-ville.syrjala@linux.intel.com
2020-05-22drm/nouveau/kms/nv50-: Share DP SST mode_valid() handling with MSTLyude Paul
Currently, the nv50_mstc_mode_valid() function is happy to take any and all modes, even the ones we can't actually support sometimes like interlaced modes. Luckily, the only difference between the mode validation that needs to be performed for MST vs. SST is that eventually we'll need to check the minimum PBN against the MSTB's full PBN capabilities (remember-we don't care about the current bw state here). Otherwise, all of the other code can be shared. So, we move all of the common mode validation in nouveau_connector_mode_valid() into a separate helper, nv50_dp_mode_valid(), and use that from both nv50_mstc_mode_valid() and nouveau_connector_mode_valid(). Note that we allow for returning the calculated clock that nv50_dp_mode_valid() came up with, since we'll eventually want to use that for PBN calculation in nv50_mstc_mode_valid(). Signed-off-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2020-05-22drm/nouveau/kms/nv50-: Probe SOR and PIOR caps for DP interlacing supportLyude Paul
Right now, we make the mistake of allowing interlacing on all connectors. Nvidia hardware does not always support interlacing with DP though, so we need to make sure that we don't allow interlaced modes to be set in such situations as otherwise we'll end up accidentally hanging the display HW. This fixes some hangs with Turing, which would be caused by attempting to set an interlaced mode on hardware that doesn't support it. This patch likely fixes other hardware hanging in the same way as well. Note that we say we probe PIOR caps, but they don't actually have any interlacing caps. So, the get_caps() function for PIORs just sets interlacing support to true. Changes since v1: * Actually probe caps correctly this time, both on EVO and NVDisplay. Changes since v2: * Fix probing for < GF119 * Use vfunc table, in prep for adding more caps in the future. Signed-off-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2019-12-10drm/nouveau: Fix drm-core using atomic code-paths on pre-nv50 hardwareHans de Goede
We do not support atomic modesetting on pre-nv50 hardware, but until now our connector code was setting drm_connector->state on pre-nv50 hardware. This causes the core to enter atomic modesetting paths in at least: 1. drm_connector_get_encoder(), returning connector->state->best_encoder which is always 0, causing us to always report 0 as encoder_id in the drmModeConnector struct returned by drmModeGetConnector(). 2. drm_encoder_get_crtc(), returning NULL because uses_atomic get set, causing us to always report 0 as crtc_id in the drmModeEncoder struct returned by drmModeGetEncoder() Which in turn confuses userspace, at least plymouth thinks that the pipe has changed because of this and tries to reconfigure it unnecessarily. More in general we should not set drm_connector->state in the non-atomic code as this violates the drm-core's expectations. This commit fixes this by using a nouveau_conn_atom struct embedded in the nouveau_connector struct for property handling in the non-atomic case. Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1706557 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2019-10-24drm/nouveau: Don't grab runtime PM refs for HPD IRQsLyude Paul
In order for suspend/resume reprobing to work, we need to be able to perform sideband communications during suspend/resume, along with runtime PM suspend/resume. In order to do so, we also need to make sure that nouveau doesn't bother grabbing a runtime PM reference to do so, since otherwise we'll start deadlocking runtime PM again. Note that we weren't able to do this before, because of the DP MST helpers processing UP requests from topologies in the same context as drm_dp_mst_hpd_irq() which would have caused us to open ourselves up to receiving hotplug events and deadlocking with runtime suspend/resume. Now that those requests are handled asynchronously, this change should be completely safe. Cc: Juston Li <juston.li@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Harry Wentland <hwentlan@amd.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Sean Paul <sean@poorly.run> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191022023641.8026-10-lyude@redhat.com
2019-10-03Merge drm/drm-next into drm-misc-nextMaxime Ripard
We haven't done any backmerge for a while due to the merge window, and it starts to become an issue for komeda. Let's bring 5.4-rc1 in. Signed-off-by: Maxime Ripard <mripard@kernel.org>
2019-09-16drm/connector: Allow max possible encoders to attach to a connectorJosé Roberto de Souza
Currently we restrict the number of encoders that can be linked to a connector to 3, increase it to match the maximum number of encoders that can be initialized(32). To more effiently do that lets switch from an array of encoder ids to bitmask. v2: Fixing missed return on amdgpu_dm_connector_to_encoder() Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: dri-devel@lists.freedesktop.org Cc: intel-gfx@lists.freedesktop.org Cc: nouveau@lists.freedesktop.org Cc: amd-gfx@lists.freedesktop.org Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190913232857.389834-2-jose.souza@intel.com
2019-08-27drm_dp_cec: add connector info support.Dariusz Marcinkiewicz
Pass the connector info to the CEC adapter. This makes it possible to associate the CEC adapter with the corresponding drm connector. Signed-off-by: Dariusz Marcinkiewicz <darekm@google.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Tested-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Reviewed-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Link: https://patchwork.freedesktop.org/patch/msgid/20190814104520.6001-2-darekm@google.com
2019-08-23drm/nouveau: drop use of drmp.hSam Ravnborg
Drop use of the deprecated drmP.h file from drm/nouveau. Build tested using allyesconfig and allmodconfig. Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: nouveau@lists.freedesktop.org Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2019-07-25drm/nouveau: Use connector kdev as aux device parentLeo Li
Set the connector's kernel device as the parent for the aux kernel device. This allows udev rules to access connector attributes when creating symlinks to aux devices. Cc: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Leo Li <sunpeng.li@amd.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190723232808.28128-4-sunpeng.li@amd.com
2019-07-19drm/nouveau: fix memory leak in nouveau_conn_reset()Yongxin Liu
In nouveau_conn_reset(), if connector->state is true, __drm_atomic_helper_connector_destroy_state() will be called, but the memory pointed by asyc isn't freed. Memory leak happens in the following function __drm_atomic_helper_connector_reset(), where newly allocated asyc->state will be assigned to connector->state. So using nouveau_conn_atomic_destroy_state() instead of __drm_atomic_helper_connector_destroy_state to free the "old" asyc. Here the is the log showing memory leak. unreferenced object 0xffff8c5480483c80 (size 192): comm "kworker/0:2", pid 188, jiffies 4294695279 (age 53.179s) hex dump (first 32 bytes): 00 f0 ba 7b 54 8c ff ff 00 00 00 00 00 00 00 00 ...{T........... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<000000005005c0d0>] kmem_cache_alloc_trace+0x195/0x2c0 [<00000000a122baed>] nouveau_conn_reset+0x25/0xc0 [nouveau] [<000000004fd189a2>] nouveau_connector_create+0x3a7/0x610 [nouveau] [<00000000c73343a8>] nv50_display_create+0x343/0x980 [nouveau] [<000000002e2b03c3>] nouveau_display_create+0x51f/0x660 [nouveau] [<00000000c924699b>] nouveau_drm_device_init+0x182/0x7f0 [nouveau] [<00000000cc029436>] nouveau_drm_probe+0x20c/0x2c0 [nouveau] [<000000007e961c3e>] local_pci_probe+0x47/0xa0 [<00000000da14d569>] work_for_cpu_fn+0x1a/0x30 [<0000000028da4805>] process_one_work+0x27c/0x660 [<000000001d415b04>] worker_thread+0x22b/0x3f0 [<0000000003b69f1f>] kthread+0x12f/0x150 [<00000000c94c29b7>] ret_from_fork+0x3a/0x50 Signed-off-by: Yongxin Liu <yongxin.liu@windriver.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2019-07-19drm/nouveau/kms: disallow dual-link harder if hdmi connection detectedBen Skeggs
The fallthrough cases (pre-Fermi) would accidentally allow dual-link pixel clocks even where they shouldn't be. This leads to a high resolution HDMI displays, connected via a DVI->HDMI adapter, to fail on the original NV50. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2019-01-24drm: Split out drm_probe_helper.hDaniel Vetter
Having the probe helper stuff (which pretty much everyone needs) in the drm_crtc_helper.h file (which atomic drivers should never need) is confusing. Split them out. To make sure I actually achieved the goal here I went through all drivers. And indeed, all atomic drivers are now free of drm_crtc_helper.h includes. v2: Make it compile. There was so much compile fail on arm drivers that I figured I'll better not include any of the acks on v1. v3: Massive rebase because i915 has lost a lot of drmP.h includes, but not all: Through drm_crtc_helper.h > drm_modeset_helper.h -> drmP.h there was still one, which this patch largely removes. Which means rolling out lots more includes all over. This will also conflict with ongoing drmP.h cleanup by others I expect. v3: Rebase on top of atomic bochs. v4: Review from Laurent for bridge/rcar/omap/shmob/core bits: - (re)move some of the added includes, use the better include files in other places (all suggested from Laurent adopted unchanged). - sort alphabetically v5: Actually try to sort them, and while at it, sort all the ones I touch. v6: Rebase onto i915 changes. v7: Rebase once more. Acked-by: Harry Wentland <harry.wentland@amd.com> Acked-by: Sam Ravnborg <sam@ravnborg.org> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Benjamin Gaignard <benjamin.gaignard@linaro.org> Acked-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Neil Armstrong <narmstrong@baylibre.com> Acked-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Acked-by: CK Hu <ck.hu@mediatek.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Acked-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: linux-arm-kernel@lists.infradead.org Cc: virtualization@lists.linux-foundation.org Cc: etnaviv@lists.freedesktop.org Cc: linux-samsung-soc@vger.kernel.org Cc: intel-gfx@lists.freedesktop.org Cc: linux-mediatek@lists.infradead.org Cc: linux-amlogic@lists.infradead.org Cc: linux-arm-msm@vger.kernel.org Cc: freedreno@lists.freedesktop.org Cc: nouveau@lists.freedesktop.org Cc: spice-devel@lists.freedesktop.org Cc: amd-gfx@lists.freedesktop.org Cc: linux-renesas-soc@vger.kernel.org Cc: linux-rockchip@lists.infradead.org Cc: linux-stm32@st-md-mailman.stormreply.com Cc: linux-tegra@vger.kernel.org Cc: xen-devel@lists.xen.org Link: https://patchwork.freedesktop.org/patch/msgid/20190117210334.13234-1-daniel.vetter@ffwll.ch
2018-12-11drm/nouveau/bios: translate USB-C connector typeBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-12-11drm/nouveau/drm/nouveau: Don't forget to label dp_aux devicesLyude Paul
This makes debugging with DP tracing a lot harder to interpret, so name each i2c based off the name of the encoder that it's for Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Karol Herbst <karolherbst@gmail.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-10-11drm/nouveau/disp: take sink support into account for exposing 594mhzIlia Mirkin
Scrambling is required for supporting any mode over 340MHz. If it's not supported, reject any modes that would require it. Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-10-11drm/nouveau/drm/nouveau: s/nouveau_backlight_exit/nouveau_backlight_fini/Lyude Paul
More consistent with the rest of the codebase, no functional changes here. Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Karol Herbst <kherbst@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-10-11drm/nouveau: Move backlight device into nouveau_connectorLyude Paul
Currently module unloading is broken in nouveau due to a rather annoying race condition resulting from nouveau_backlight.c having gone a bit stale over time: [ 1960.791143] ================================================================== [ 1960.791394] BUG: KASAN: use-after-free in nouveau_backlight_exit+0x112/0x150 [nouveau] [ 1960.791460] Read of size 4 at addr ffff88075accf350 by task zsh/11185 [ 1960.791521] [ 1960.791545] CPU: 7 PID: 11185 Comm: zsh Kdump: loaded Tainted: G O 4.18.0Lyude-Test+ #4 [ 1960.791580] Hardware name: LENOVO 20EQS64N0B/20EQS64N0B, BIOS N1EET79W (1.52 ) 07/13/2018 [ 1960.791628] Call Trace: [ 1960.791680] dump_stack+0xa4/0xfd [ 1960.791721] print_address_description+0x71/0x239 [ 1960.791833] ? nouveau_backlight_exit+0x112/0x150 [nouveau] [ 1960.791877] kasan_report.cold.6+0x242/0x2fe [ 1960.791919] __asan_report_load4_noabort+0x19/0x20 [ 1960.792012] nouveau_backlight_exit+0x112/0x150 [nouveau] [ 1960.792081] nouveau_display_destroy+0x76/0x150 [nouveau] [ 1960.792150] nouveau_drm_device_fini+0xb7/0x190 [nouveau] [ 1960.792265] nouveau_drm_device_remove+0x14b/0x1d0 [nouveau] [ 1960.792347] ? nouveau_cli_work_queue+0x2e0/0x2e0 [nouveau] [ 1960.792378] ? trace_hardirqs_on_caller+0x38b/0x570 [ 1960.792406] ? trace_hardirqs_on+0xd/0x10 [ 1960.792472] nouveau_drm_remove+0x37/0x50 [nouveau] [ 1960.792502] pci_device_remove+0x112/0x2d0 [ 1960.792530] ? pcibios_free_irq+0x10/0x10 [ 1960.792558] ? kasan_check_write+0x14/0x20 [ 1960.792587] device_release_driver_internal+0x35c/0x650 [ 1960.792617] device_release_driver+0x12/0x20 [ 1960.792643] pci_stop_bus_device+0x172/0x1e0 [ 1960.792671] pci_stop_and_remove_bus_device_locked+0x1a/0x30 [ 1960.792715] remove_store+0xcb/0xe0 [ 1960.792753] ? sriov_numvfs_store+0x2e0/0x2e0 [ 1960.792779] ? __lock_is_held+0xb5/0x140 [ 1960.792808] ? component_add+0x530/0x530 [ 1960.792834] dev_attr_store+0x3f/0x70 [ 1960.792859] ? sysfs_file_ops+0x11d/0x170 [ 1960.792885] sysfs_kf_write+0x104/0x150 [ 1960.792915] ? sysfs_file_ops+0x170/0x170 [ 1960.792940] kernfs_fop_write+0x24f/0x400 [ 1960.792978] ? __lock_acquire+0x6ea/0x47f0 [ 1960.793021] __vfs_write+0xeb/0x760 [ 1960.793048] ? kernel_read+0x130/0x130 [ 1960.793076] ? __lock_is_held+0xb5/0x140 [ 1960.793107] ? rcu_read_lock_sched_held+0xdd/0x110 [ 1960.793135] ? rcu_sync_lockdep_assert+0x78/0xb0 [ 1960.793162] ? __sb_start_write+0x183/0x220 [ 1960.793189] vfs_write+0x14d/0x4a0 [ 1960.793229] ksys_write+0xd2/0x1b0 [ 1960.793255] ? __ia32_sys_read+0xb0/0xb0 [ 1960.793298] ? fput+0x1d/0x120 [ 1960.793324] ? filp_close+0xf3/0x130 [ 1960.793349] ? entry_SYSCALL_64_after_hwframe+0x59/0xbe [ 1960.793380] __x64_sys_write+0x73/0xb0 [ 1960.793407] do_syscall_64+0xaa/0x400 [ 1960.793433] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 1960.793460] RIP: 0033:0x7f59df433164 [ 1960.793486] Code: 89 02 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 8d 05 81 38 2d 00 8b 00 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 41 54 49 89 d4 55 48 89 f5 53 [ 1960.793541] RSP: 002b:00007ffd70ee2fb8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ 1960.793576] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f59df433164 [ 1960.793620] RDX: 0000000000000002 RSI: 00005578088640c0 RDI: 0000000000000001 [ 1960.793665] RBP: 00005578088640c0 R08: 00007f59df7038c0 R09: 00007f59e0995b80 [ 1960.793696] R10: 000000000000000a R11: 0000000000000246 R12: 00007f59df702760 [ 1960.793730] R13: 0000000000000002 R14: 00007f59df6fd760 R15: 0000000000000002 [ 1960.793768] [ 1960.793790] Allocated by task 11167: [ 1960.793816] save_stack+0x43/0xd0 [ 1960.793841] kasan_kmalloc+0xc4/0xe0 [ 1960.793880] kasan_slab_alloc+0x11/0x20 [ 1960.793905] kmem_cache_alloc+0xd7/0x270 [ 1960.793944] getname_flags+0xbd/0x520 [ 1960.793969] user_path_at_empty+0x23/0x50 [ 1960.793994] do_faccessat+0x1fc/0x5d0 [ 1960.794018] __x64_sys_access+0x59/0x80 [ 1960.794043] do_syscall_64+0xaa/0x400 [ 1960.794067] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 1960.794093] [ 1960.794127] Freed by task 11167: [ 1960.794152] save_stack+0x43/0xd0 [ 1960.794190] __kasan_slab_free+0x139/0x190 [ 1960.794215] kasan_slab_free+0xe/0x10 [ 1960.794239] kmem_cache_free+0xcb/0x2c0 [ 1960.794264] putname+0xad/0xe0 [ 1960.794287] filename_lookup.part.59+0x1f1/0x360 [ 1960.794313] user_path_at_empty+0x3e/0x50 [ 1960.794338] do_faccessat+0x1fc/0x5d0 [ 1960.794362] __x64_sys_access+0x59/0x80 [ 1960.794393] do_syscall_64+0xaa/0x400 [ 1960.794421] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 1960.794461] [ 1960.794483] The buggy address belongs to the object at ffff88075acceac0 [ 1960.794483] which belongs to the cache names_cache of size 4096 [ 1960.794540] The buggy address is located 2192 bytes inside of [ 1960.794540] 4096-byte region [ffff88075acceac0, ffff88075accfac0) [ 1960.794581] The buggy address belongs to the page: [ 1960.794609] page:ffffea001d6b3200 count:1 mapcount:0 mapping:ffff880778e4b1c0 index:0x0 compound_mapcount: 0 [ 1960.794651] flags: 0x8000000000008100(slab|head) [ 1960.794679] raw: 8000000000008100 ffffea001d39e808 ffffea001d39ea08 ffff880778e4b1c0 [ 1960.794739] raw: 0000000000000000 0000000000070007 00000001ffffffff 0000000000000000 [ 1960.794785] page dumped because: kasan: bad access detected [ 1960.794813] [ 1960.794834] Memory state around the buggy address: [ 1960.794861] ffff88075accf200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 1960.794894] ffff88075accf280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 1960.794925] >ffff88075accf300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 1960.794956] ^ [ 1960.794985] ffff88075accf380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 1960.795017] ffff88075accf400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 1960.795061] ================================================================== [ 1960.795106] Disabling lock debugging due to kernel taint [ 1960.795131] ------------[ cut here ]------------ [ 1960.795148] ida_remove called for id=1802201963 which is not allocated. [ 1960.795193] WARNING: CPU: 7 PID: 11185 at lib/idr.c:521 ida_remove+0x184/0x210 [ 1960.795213] Modules linked in: nouveau(O) mxm_wmi ttm i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm joydev vfat fat intel_rapl x86_pkg_temp_thermal coretemp crc32_pclmul iTCO_wdt psmouse wmi_bmof mei_me tpm_tis mei tpm_tis_core tpm i2c_i801 thinkpad_acpi pcc_cpufreq crc32c_intel serio_raw xhci_pci xhci_hcd wmi video i2c_dev i2c_core [ 1960.795305] CPU: 7 PID: 11185 Comm: zsh Kdump: loaded Tainted: G B O 4.18.0Lyude-Test+ #4 [ 1960.795330] Hardware name: LENOVO 20EQS64N0B/20EQS64N0B, BIOS N1EET79W (1.52 ) 07/13/2018 [ 1960.795352] RIP: 0010:ida_remove+0x184/0x210 [ 1960.795370] Code: 4c 89 f7 e8 ae c8 00 00 eb 22 41 83 c4 02 4c 89 e8 41 83 fc 3f 0f 86 64 ff ff ff 44 89 fe 48 c7 c7 20 94 1e 83 e8 54 ed 81 fe <0f> 0b 48 b8 00 00 00 00 00 fc ff df 48 01 c3 c7 03 00 00 00 00 c7 [ 1960.795402] RSP: 0018:ffff88074d4df7b8 EFLAGS: 00010082 [ 1960.795421] RAX: 0000000000000000 RBX: 1ffff100e9a9befa RCX: ffffffff81479975 [ 1960.795440] RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffff88077c1de690 [ 1960.795460] RBP: ffff88074d4df878 R08: ffffed00ef83bcd3 R09: ffffed00ef83bcd2 [ 1960.795479] R10: ffffed00ef83bcd2 R11: ffff88077c1de697 R12: 000000000000036b [ 1960.795498] R13: 0000000000000202 R14: ffffffffa0aa7fa0 R15: 000000006b6b6b6b [ 1960.795518] FS: 00007f59e0995b80(0000) GS:ffff88077c1c0000(0000) knlGS:0000000000000000 [ 1960.795553] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1960.795571] CR2: 00007f59e09a2010 CR3: 00000004a1a70005 CR4: 00000000003606e0 [ 1960.795596] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1960.795629] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 1960.795649] Call Trace: [ 1960.795667] ? ida_destroy+0x1d0/0x1d0 [ 1960.795686] ? kasan_check_write+0x14/0x20 [ 1960.795704] ? do_raw_spin_lock+0xc2/0x1c0 [ 1960.795724] ida_simple_remove+0x26/0x40 [ 1960.795794] nouveau_backlight_exit+0x9d/0x150 [nouveau] [ 1960.795867] nouveau_display_destroy+0x76/0x150 [nouveau] [ 1960.795930] nouveau_drm_device_fini+0xb7/0x190 [nouveau] [ 1960.795989] nouveau_drm_device_remove+0x14b/0x1d0 [nouveau] [ 1960.796047] ? nouveau_cli_work_queue+0x2e0/0x2e0 [nouveau] [ 1960.796067] ? trace_hardirqs_on_caller+0x38b/0x570 [ 1960.796089] ? trace_hardirqs_on+0xd/0x10 [ 1960.796146] nouveau_drm_remove+0x37/0x50 [nouveau] [ 1960.796167] pci_device_remove+0x112/0x2d0 [ 1960.796186] ? pcibios_free_irq+0x10/0x10 [ 1960.796218] ? kasan_check_write+0x14/0x20 [ 1960.796237] device_release_driver_internal+0x35c/0x650 [ 1960.796257] device_release_driver+0x12/0x20 [ 1960.796289] pci_stop_bus_device+0x172/0x1e0 [ 1960.796308] pci_stop_and_remove_bus_device_locked+0x1a/0x30 [ 1960.796328] remove_store+0xcb/0xe0 [ 1960.796345] ? sriov_numvfs_store+0x2e0/0x2e0 [ 1960.796364] ? __lock_is_held+0xb5/0x140 [ 1960.796383] ? component_add+0x530/0x530 [ 1960.796401] dev_attr_store+0x3f/0x70 [ 1960.796419] ? sysfs_file_ops+0x11d/0x170 [ 1960.796436] sysfs_kf_write+0x104/0x150 [ 1960.796454] ? sysfs_file_ops+0x170/0x170 [ 1960.796471] kernfs_fop_write+0x24f/0x400 [ 1960.796488] ? __lock_acquire+0x6ea/0x47f0 [ 1960.796520] __vfs_write+0xeb/0x760 [ 1960.796538] ? kernel_read+0x130/0x130 [ 1960.796556] ? __lock_is_held+0xb5/0x140 [ 1960.796590] ? rcu_read_lock_sched_held+0xdd/0x110 [ 1960.796608] ? rcu_sync_lockdep_assert+0x78/0xb0 [ 1960.796626] ? __sb_start_write+0x183/0x220 [ 1960.796648] vfs_write+0x14d/0x4a0 [ 1960.796666] ksys_write+0xd2/0x1b0 [ 1960.796684] ? __ia32_sys_read+0xb0/0xb0 [ 1960.796701] ? fput+0x1d/0x120 [ 1960.796732] ? filp_close+0xf3/0x130 [ 1960.796749] ? entry_SYSCALL_64_after_hwframe+0x59/0xbe [ 1960.796768] __x64_sys_write+0x73/0xb0 [ 1960.796800] do_syscall_64+0xaa/0x400 [ 1960.796818] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 1960.796836] RIP: 0033:0x7f59df433164 [ 1960.796854] Code: 89 02 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 8d 05 81 38 2d 00 8b 00 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 41 54 49 89 d4 55 48 89 f5 53 [ 1960.796884] RSP: 002b:00007ffd70ee2fb8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ 1960.796906] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f59df433164 [ 1960.796926] RDX: 0000000000000002 RSI: 00005578088640c0 RDI: 0000000000000001 [ 1960.796946] RBP: 00005578088640c0 R08: 00007f59df7038c0 R09: 00007f59e0995b80 [ 1960.796966] R10: 000000000000000a R11: 0000000000000246 R12: 00007f59df702760 [ 1960.796985] R13: 0000000000000002 R14: 00007f59df6fd760 R15: 0000000000000002 [ 1960.797008] irq event stamp: 509990 [ 1960.797026] hardirqs last enabled at (509989): [<ffffffff8119ff78>] flush_work+0x4b8/0x6d0 [ 1960.797063] hardirqs last disabled at (509990): [<ffffffff8297c395>] _raw_spin_lock_irqsave+0x25/0x60 [ 1960.797085] softirqs last enabled at (509744): [<ffffffff82c005ad>] __do_softirq+0x5ad/0x8c0 [ 1960.797121] softirqs last disabled at (509735): [<ffffffff8115aa15>] irq_exit+0x1a5/0x1e0 [ 1960.797142] ---[ end trace fb1342325f1846b8 ]--- While I haven't actually gone into the details of what's causing this to happen (maybe the kernel removes the backlight device in the device core before we get to it?), it doesn't really matter anyway because the way nouveau handles backlights has long since been deprecated. According to the documentation on the drm_connector->late_register() hook, the ->late_register() hook should be used for adding extra connector-related devices. Vice versa, the ->early_unregister() hook is meant to be used for removing those devices. So: gut nouveau_drm->bl_list and nouveau_drm->backlight, and replace them with per-connector backlight structures. Additionally, move backlight registration/teardown into the ->late_register() and ->early_unregister() hooks so that DRM can give us a chance to remove the backlight before the connector is even removed. This appears to fix the problem once and for all. Changes since v2: - Use NV_INFO_ONCE for printing GMUX information, since otherwise this will end up printing that message for as many times as we have connectors Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Karol Herbst <kherbst@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-09-27BackMerge v4.19-rc5 into drm-nextDave Airlie
Sean Paul requested an -rc5 backmerge from some sun4i fixes. Signed-off-by: Dave Airlie <airlied@redhat.com>
2018-09-07drm/nouveau/disp: move eDP panel power handlingBen Skeggs
We need to do this earlier to prevent aux channel timeouts in resume paths on certain systems. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
generated by cgit v1.2.3 (git 2.39.1) at 2025-07-30 23:21:09 +0000