aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2017-03-30apple-gmux: Don't switch external DP port on 2011+ MacBook ProsLukas Wunner1-1/+30
On MacBook Pros introduced 2011 and onward, external DP ports are combined DP/Thunderbolt ports that are no longer fully switchable between GPUs, they can only be driven by the discrete GPU. More specifically, the Main Link pins (which transport the actual video and audio streams) are soldered to the discrete GPU, whereas the AUX Channel pins are switchable. Because the integrated GPU is missing the Main Link, external displays appear to it as phantoms which fail to link-train. Force the AUX channel to the discrete GPU on these models to avoid any confusion. Document the switching policy implemented by this commit. Acked-by: Andy Shevchenko <[email protected]> Signed-off-by: Lukas Wunner <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/4d1fcc92d1960049e2cff997fbd2d74e45e84e49.1489145162.git.lukas@wunner.de
2017-03-30drm/nouveau: Don't register Thunderbolt eGPU with vga_switcherooLukas Wunner1-1/+9
An external Thunderbolt GPU can neither drive the laptop's panel nor be powered off by the platform, so there's no point in registering it with vga_switcheroo. In fact, when the external GPU is runtime suspended, vga_switcheroo will cut power to the internal discrete GPU, resulting in a lockup. Cc: Ben Skeggs <[email protected]> Acked-by: Alex Deucher <[email protected]> Signed-off-by: Lukas Wunner <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/8e733152b13e7c14501ad5af45c1c5c736584111.1489145162.git.lukas@wunner.de
2017-03-30drm/amdgpu: Don't register Thunderbolt eGPU with vga_switcherooLukas Wunner2-3/+7
An external Thunderbolt GPU can neither drive the laptop's panel nor be powered off by the platform, so there's no point in registering it with vga_switcheroo. In fact, when the external GPU is runtime suspended, vga_switcheroo will cut power to the internal discrete GPU, resulting in a lockup. Moreover AMD's Windows driver special-cases Thunderbolt as well. Acked-by: Alex Deucher <[email protected]> Signed-off-by: Lukas Wunner <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/701a8e89ce8ac39734736ab779558b6a4042a19e.1489145162.git.lukas@wunner.de
2017-03-30drm/radeon: Don't register Thunderbolt eGPU with vga_switcherooLukas Wunner2-3/+7
An external Thunderbolt GPU can neither drive the laptop's panel nor be powered off by the platform, so there's no point in registering it with vga_switcheroo. In fact, when the external GPU is runtime suspended, vga_switcheroo will cut power to the internal discrete GPU, resulting in a lockup. Moreover AMD's Windows driver special-cases Thunderbolt as well. Acked-by: Alex Deucher <[email protected]> Signed-off-by: Lukas Wunner <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/72d8a9645aece3eff44e116303f0fec8be061c88.1489145162.git.lukas@wunner.de
2017-03-30PCI: Recognize Thunderbolt devicesLukas Wunner3-0/+46
Detect on probe whether a PCI device is part of a Thunderbolt controller. Intel uses a Vendor-Specific Extended Capability (VSEC) with ID 0x1234 on such devices. Detect presence of this VSEC and cache it in a newly added is_thunderbolt bit in struct pci_dev. Also, add a helper to check whether a given PCI device is situated on a Thunderbolt daisy chain (i.e., below a PCI device with is_thunderbolt set). The necessity arises from the following: * If an external Thunderbolt GPU is connected to a dual GPU laptop, that GPU is currently registered with vga_switcheroo even though it can neither drive the laptop's panel nor be powered off by the platform. To vga_switcheroo it will appear as if two discrete GPUs are present. As a result, when the external GPU is runtime suspended, vga_switcheroo will cut power to the internal discrete GPU which may not be runtime suspended at all at this moment. The solution is to not register external GPUs with vga_switcheroo, which necessitates a way to recognize if they're on a Thunderbolt daisy chain. * Dual GPU MacBook Pros introduced 2011+ can no longer switch external DisplayPort ports between GPUs. (They're no longer just used for DP but have become combined DP/Thunderbolt ports.) The driver to switch the ports, drivers/platform/x86/apple-gmux.c, needs to detect presence of a Thunderbolt controller and, if found, keep external ports permanently switched to the discrete GPU. v2: Make kerneldoc for pci_is_thunderbolt_attached() more precise, drop portion of commit message pertaining to separate series. (Bjorn Helgaas) Cc: Andreas Noever <[email protected]> Cc: Michael Jamet <[email protected]> Cc: Tomas Winkler <[email protected]> Cc: Amir Levy <[email protected]> Acked-by: Bjorn Helgaas <[email protected]> Signed-off-by: Lukas Wunner <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/0ab165a4a35c0b60f29d4c306c653ead14fcd8f9.1489145162.git.lukas@wunner.de
2017-03-30MAINTAINERS: Add Lukas Wunner as reviewer for vga_switcherooLukas Wunner1-0/+10
I've been contributing to vga_switcheroo for the past two years and by now am fairly familiar with it, so danvet suggested that I add myself as reviewer. While at it, add missing file pattern for vga_switcheroo.h + vgaarb.h to the DRM and DRM-MISC sections such that get_maintainer.pl returns dri-devel@ and the drm-misc maintainers. Suggested-and-acked-by: Daniel Vetter <[email protected]> Signed-off-by: Lukas Wunner <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/ff2320a0790d039e714cf352cf32ec16fa370627.1490623913.git.lukas@wunner.de
2017-03-30drm: Fix locking gotcha in page_flip ioctlDaniel Vetter1-1/+1
We want to lock the primary plane, not the cursor (which might be optional). Real bad case of copy-paste fail, unfortunately our CI didn't catch that because i915 does have a cursor plane. Reported-by: Eric Anholt <[email protected]> Fixes: 29dc0d1de182 ("drm: Roll out acquire context for the page_flip ioctl") Cc: Jani Nikula <[email protected]> Cc: Sean Paul <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Tested-by: Eric Anholt <[email protected]> Reviewed-by: Harry Wentland <[email protected]>
2017-03-30drm: Clarify the role of plane_state argument to drm_simple update().Eric Anholt2-3/+3
Like the atomic update hook it's wrapping, the plane_state is the old one, and the new one is in plane->state. Both msxfb and tinydrm use it correctly, but I mistook it for the new state in pl111 due to its naming. Signed-off-by: Eric Anholt <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Daniel Vetter <[email protected]>
2017-03-30drm: Clear e after kfree in drm_mode_page_flip_ioctlDaniel Vetter1-0/+1
With the explicit retry loop static analyzers get confused by the control flow and believe that e could be accessed after kfree. That's not possible, but it's non-obvious, so let's clear it to NULL. We already cleared e = NULL at the top of the function, so this is all in line. Cc: Julia Lawall <[email protected]> Reported-by: Julia Lawall <[email protected]> Fixes: 29dc0d1de182 ("drm: Roll out acquire context for the page_flip ioctl") Cc: Harry Wentland <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Jani Nikula <[email protected]> Cc: Sean Paul <[email protected]> Reviewed-by: Harry Wentland <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-03-30drm: Convert cmpxchg(bool) back to a two step operationChris Wilson1-1/+3
ARM v6 (at least) only allows cmpxchg on 32bit variables which doesn't always include the bool type. drivers/built-in.o: In function `vblank_disable_and_save': imx-ocotp.c:(.text+0xb45e8): undefined reference to `__bad_cmpxchg' Makefile:986: recipe for target 'vmlinux' failed Reported-by: kbuild test robot <[email protected]> Reported-by: Leonard Crestez <[email protected]> Fixes: 43dc7fe2b211 ("drm: Mark up accesses of vblank->enabled outside of its spinlock") Signed-off-by: Chris Wilson <[email protected]> Cc: Ville Syrjälä <[email protected]> Cc: Daniel Vetter <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-03-30drm/bridge: ti-tfp410: support hpd via gpioChristopher Spinrath1-2/+70
On some boards the hpd pin of a hdmi connector is wired up to a gpio pin. Since in the DRM world the tfp410 driver is responsible for handling the connector, add support for hpd gpios in this very driver. Reviewed-by: Jyri Sarha <[email protected]> Signed-off-by: Christopher Spinrath <[email protected]> Signed-off-by: Archit Taneja <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-03-30drm: use .hword to represent 16-bit numbersJavi Merino1-3/+3
The size of .word is the size of a word in the given platform, which for intel systems is 16-bits but other architectures use different sizes. However, .hword emits 16-bit numbers regardless of the platform (and despite the name). The quantities specified in EDID are platform independent, so they should work in spite of the default target of the cc you are using, so use .hword where EDID specifies 16-bit numbers. Cc: Carsten Emde <[email protected]> Cc: David Airlie <[email protected]> Acked-by: David Airlie <[email protected]> Signed-off-by: Javi Merino <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-03-30Revert unrelated part of "drm: simplify the locking in the GETCRTC ioctl"Maarten Lankhorst1-5/+0
v2 of the commit 2c77bb29d398 ("drm: simplify the locking in the GETCRTC ioctl") accidentally introduced a unrelated change in intel_display.c, revert the unrelated change. Signed-off-by: Maarten Lankhorst <[email protected]> Fixes: 2c77bb29d398 ("drm: simplify the locking in the GETCRTC ioctl") Reported-by: Dhinakaran Pandiyan <[email protected]> Reviewed-by: Dhinakaran Pandiyan <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-03-30drm: Fixup failure paths in drm_atomic_helper_set_configDaniel Vetter1-1/+2
I've screwed this up when removing the legacy backoff hack. Fixes: 38b6441e4e75 ("drm/atomic-helper: Remove the backoff hack from set_config") Cc: Harry Wentland <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Jani Nikula <[email protected]> Cc: Sean Paul <[email protected]> Cc: David Airlie <[email protected]> Cc: [email protected] Reviewed-by: Harry Wentland <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-03-29drm: Peek at the current counter/timestamp for vblank queriesChris Wilson1-0/+26
Bypass all the spinlocks and return the last timestamp and counter from the last vblank if the driver delcares that it is accurate (and stable across on/off), and the vblank is currently enabled. This is dependent upon the both the hardware and driver to provide the proper barriers to facilitate reading our bookkeeping outside of the vblank interrupt and outside of the explicit vblank locks. Signed-off-by: Chris Wilson <[email protected]> Cc: Ville Syrjälä <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Michel Dänzer <[email protected]> Cc: Laurent Pinchart <[email protected]> Cc: Dave Airlie <[email protected]>, Cc: Mario Kleiner <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Ville Syrjälä <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]>
2017-03-29drm: Refactor vblank sequence number comparisonChris Wilson1-6/+10
Move the repeated (a - b) <= (1 << 23) to its own function. v2: Catch the '1<<23' inside drm_handle_vblank() as well Signed-off-by: Chris Wilson <[email protected]> Cc: Ville Syrjälä <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Michel Dänzer <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Michel Dänzer <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]>
2017-03-29drm: vblank cannot be enabled if dev->irq_enabled is falseChris Wilson1-4/+3
Since we cannot enable the vblank if !dev->irq_enabled, we assert that checking for both !vblank->enabled and !dev->irq_enabled is tautological and only need the former. The only time it may differ is when racing with drm_irq_uninstall(), but that will then disable the vblank and wakeup the waiters. Signed-off-by: Chris Wilson <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Ville Syrjälä <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]>
2017-03-29drm: Mark up accesses of vblank->enabled outside of its spinlockChris Wilson1-9/+14
Order the update to vblank->enabled after the timestamp is primed so that a concurrent unlocked reader will only see the vblank->enabled with the current timestamp. v2: vblank->enable is guarded by dev->vbl_lock not dev->vblank_time_lock, update the READ_ONCE accordingly. Do not add a READ_ONCE(vblank->enabled) inside the interrupt handler to avoid missing an interrupt whilst racing with enable_vblank() Signed-off-by: Chris Wilson <[email protected]> Cc: Ville Syrjälä <[email protected]> Cc: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Ville Syrjälä <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]>
2017-03-29drm: Make the decision to keep vblank irq enabled earlierChris Wilson1-8/+12
We want to provide the vblank irq shadow for pageflip events as well as vblank queries. Such events are completed within the vblank interrupt handler, and so the current check for disabling the irq will disable it from with the same interrupt as the last pageflip event. If we move the decision on whether to disable the irq (based on there no being no remaining vblank events, i.e. vblank->refcount == 0) to before we signal the events, we will only disable the irq on the interrupt after the last event was signaled. In the normal course of events, this will keep the vblank irq enabled for the entire flip sequence whereas before it would flip-flop around every interrupt. v2: Move the disable_fn() call outside of the vblank_event_lock. Signed-off-by: Chris Wilson <[email protected]> Cc: Ville Syrjälä <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Michel Dänzer <[email protected]> Cc: Laurent Pinchart <[email protected]> Cc: Dave Airlie <[email protected]>, Cc: Mario Kleiner <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> #v1 Reviewed-by: Mario Kleiner <[email protected]> #v1 Signed-off-by: Ville Syrjälä <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-03-29drm/atomic-helper: Remove the backoff hack from set_configDaniel Vetter2-20/+2
Another one bites the dust. Again let's not forget to remove the temporary hidden acquire_ctx assignment, now that we pass this all around explicitly it can go away again. Reviewed-by: Harry Wentland <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-03-29drm: Add acquire ctx parameter to ->set_configDaniel Vetter17-23/+38
Surprisingly a lot of legacy drivers roll their own, for runtime pm and because vmwgfx. Also make nouveau's set_config static while at it. Cc: Sinclair Yeh <[email protected]> Cc: Thomas Hellstrom <[email protected]> Cc: Ben Skeggs <[email protected]> Cc: Patrik Jakobsson <[email protected]> Cc: Alex Deucher <[email protected]> Cc: Christian König <[email protected]> Reviewed-by: Harry Wentland <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-03-29drm: Add explicit acquire ctx handling around ->set_configDaniel Vetter1-7/+19
Just the groundwork to have something to feed into ->set_config. Again we need a temporary hack to still fill out the legacy ctx in mode_config.acquire_ctx. Reviewed-by: Harry Wentland <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-03-29drm: Restrict drm_mode_set_config_internal to non-atomic driversDaniel Vetter1-13/+21
This is another case where we really can't reconstruct a acquire ctx in any useful fashion because all the callers are legacy drivers. So like drm_plane_force_disable simply restrict it to non-atomic drivers so that it's clear we're ok with passing a NULL ctx. Reviewed-by: Harry Wentland <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-03-29drm: simplify the locking in the GETCRTC ioctlDaniel Vetter2-3/+13
No need to grab both plane and crtc locks at the same time, we can do them one after the other. If userspace races it'll get what it deserves either way. This removes another user of drm_modeset_lock_crtc. There's only one left. v2: Make sure all access to primary->state is properly protected (Harry). Cc: Harry Wentland <[email protected]> Reviewed-by: Harry Wentland <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-03-29drm/atomic-helper: remove backoff hack from page_flipDaniel Vetter2-39/+2
Yay, we can now properly retry in case of deadlocks or whatever! Also don't forget to remove the transitional crtc->acquire_ctx assignment again. Reviewed-by: Harry Wentland <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-03-29drm: Add acquire ctx parameter to ->page_flip(_target)Daniel Vetter16-21/+43
Again just going through the motions, no functional changes in here. Cc: Gerd Hoffmann <[email protected]> Cc: Ben Skeggs <[email protected]> Cc: Russell King <[email protected]> Cc: Laurent Pinchart <[email protected]> Cc: Eric Anholt <[email protected]> Cc: Alex Deucher <[email protected]> Cc: Christian König <[email protected]> Reviewed-by: Harry Wentland <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>t Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-03-29drm: Roll out acquire context for the page_flip ioctlDaniel Vetter1-2/+19
Again just prep work. Reviewed-by: Harry Wentland <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-03-29drm/atomic-helper: remove backoff hack from disable/update_planeDaniel Vetter2-49/+2
We can now properly retry at the top level, yay! v2: Also remove the temporary acquire_ctx hack again, no longer needed! Reviewed-by: Harry Wentland <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-03-29drm: Add acquire ctx parameter to ->plane_disableDaniel Vetter9-16/+26
Nouveau had a few direct calls to ->disable_plane, I replaced those with drm_plane_force_disable. Same story for shmob. Otherwise no code changes. Cc: Ben Skeggs <[email protected]> Cc: Russell King <[email protected]> Cc: Laurent Pinchart <[email protected]> Reviewed-by: Harry Wentland <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-03-29drm: drm_plane_force_disable is not for atomic driversDaniel Vetter1-0/+8
This way I can explain why it'll be fine to pass a NULL acquire ctx here in the next patch. Reviewed-by: Harry Wentland <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-03-29drm: Add acquire ctx parameter to ->update_planeDaniel Vetter12-17/+34
Just rolling it out, no code change here. Cc: Ben Skeggs <[email protected]> Cc: Russell King <[email protected]> Cc: Rob Clark <[email protected]> Cc: Laurent Pinchart <[email protected]> Cc: Eric Anholt <[email protected]> Reviewed-by: Harry Wentland <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-03-29drm: Wire up proper acquire ctx for plane functionsDaniel Vetter1-10/+42
This is just prep work to get an acquire ctx into every place where we call ->update_plane or ->disable_plane. v2: Keep the hidden acquire_ctx pointers valid while transitioning. Reviewed-by: Harry Wentland <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-03-29drm: document the all the atomic iteratorsDaniel Vetter1-1/+158
Mostly because I want the links from the newly-added @state functions to work. But I think explaining when they're useful and that the implicit one is deprecated is good either way. Slightly repetitive unfortunately. Cc: Harry Wentland <[email protected]> Cc: Maarten Lankhorst <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Reviewed-by: Harry Wentland <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-03-29drm: Document kms locking a bit betterDaniel Vetter4-34/+152
The rules are getting real hard, better to dump my brain into text a bit. This is by far not complete, but I think I reasonable start at least. Some of the older kms structures would need a full doc review anyway ... Cc: Harry Wentland <[email protected]> Reviewed-by: Harry Wentland <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Cc: Maarten Lankhorst <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-03-29drm/doc: remove standard connector props from the csv fileDaniel Vetter1-5/+0
They're properly documented in drm_connector.c now, and this csv file is a horrible mess. Better to remove it. Reviewed-by: Alex Deucher <[email protected]> Reviewed-by: Harry Wentland <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-03-28drm: Add description for scdc variableShashank Sharma1-0/+1
This patch adds description about 'scdc' variable in drm_hdmi_info structure, to fix this warning during doc-build. "drm_connector.h:140: warning: No description found for parameter 'scdc'" V2: Rebase V3: Added extra * V4: Removed merged conflict V5: Removed extra line at start of structure (Daniel) V6: Make description single line (Daniel) Cc: Daniel Vetter <[email protected]> Signed-off-by: Shashank Sharma <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-03-27drm/tegra: Don't use modeset_lock_crtcDaniel Vetter1-4/+4
Yes the help text is unhelpful, but atomic drivers should never use this. Just grab the lock without context or anything. Also an aside: Checking ->active like this doesn't protect against nonblocking commits, this is rather bogus. Cc: Thierry Reding <[email protected]> Acked-by: Thierry Reding <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-03-27drm: bochs: Prevent double-free of fb helperGabriel Krisman Bertazi1-1/+3
If fbdev registration fails for whatever reason, the error path of bochs_fbdev_init() will call bochs_fbdev_fini(), but since an fbdev initialization error is not fatal to the probe function, a subsequent device removal will try to call bochs_fbdev_fini() again, hitting the Oops below. This was detected by 0-day with a failing framebuffer registration and CONFIG_DEBUG_TEST_DRIVER_REMOVE=y. This reproduces the scenario I mentioned above at insmod time, because the test attempts to remove the device right after probing. root@debian:~# insmod bochs-drm.ko [ 17.609635] [drm] Found bochs VGA, ID 0xb0c0. [ 17.612974] [drm] Framebuffer size 16384 kB @ 0xfa000000, mmio @ 0xfebf2000. [ 17.613938] [TTM] Zone kernel: Available graphics memory: 1022244 kiB [ 17.614701] [TTM] Initializing pool allocator [ 17.615427] [TTM] Initializing DMA pool allocator [ 17.619143] fbcon: bochsdrmfb (fb0) is primary device [ 17.619428] Console: switching to colour frame buffer device 128x48 [ 17.621047] bochs-drm 0000:00:02.0: fb0: bochsdrmfb frame buffer device [ 17.641111] [drm] Initialized bochs-drm 1.0.0 20130925 for 0000:00:02.0 on minor 0 [ 17.642380] general protection fault: 0000 [#1] SMP [ 17.642985] Modules linked in: bochs_drm(+) [ 17.643259] CPU: 4 PID: 3279 Comm: insmod Tainted: G W 4.11.0-rc1+ #119 [ 17.643259] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.3-20161025_171302-gandalf 04/01/2014 [ 17.643259] task: ffff88007af35e00 task.stack: ffffc90000d84000 [ 17.643259] RIP: 0010:drm_fb_helper_fini+0x8e/0x110 [ 17.643259] RSP: 0018:ffffc90000d87ad0 EFLAGS: 00010202 [ 17.643259] RAX: dead000000000200 RBX: ffff8800790d5770 RCX: 0000000000000000 [ 17.652101] RDX: dead000000000100 RSI: 000000007fffffff RDI: ffffffff81eaf820 [ 17.652101] RBP: ffffc90000d87ae0 R08: 0000000000000000 R09: ffff88007271d918 [ 17.652101] R10: ffffc90000d87a88 R11: 0000000000000000 R12: 0000000000000000 [ 17.652101] R13: ffff8800790d56d0 R14: 0000000000000000 R15: 0000000000000000 [ 17.652101] FS: 00007f9285995700(0000) GS:ffff88007cf00000(0000) knlGS:0000000000000000 [ 17.652101] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 17.652101] CR2: 0000564f1cf9f1e8 CR3: 0000000079686000 CR4: 00000000000006e0 [ 17.652101] Call Trace: [ 17.652101] bochs_fbdev_fini+0x24/0x90 [bochs_drm] [ 17.652101] bochs_unload+0x16/0x50 [bochs_drm] [ 17.652101] drm_dev_unregister+0x37/0xd0 [ 17.652101] drm_put_dev+0x31/0x60 [ 17.652101] bochs_pci_remove+0x10/0x20 [bochs_drm] [ 17.652101] pci_device_remove+0x34/0xb0 [ 17.652101] driver_probe_device+0xd0/0x370 [ 17.652101] __driver_attach+0x96/0xa0 [ 17.652101] ? driver_probe_device+0x370/0x370 [ 17.652101] bus_for_each_dev+0x5b/0x90 [ 17.652101] driver_attach+0x19/0x20 [ 17.652101] bus_add_driver+0x11c/0x220 [ 17.652101] driver_register+0x5b/0xd0 [ 17.652101] ? 0xffffffffa0006000 [ 17.652101] __pci_register_driver+0x47/0x50 [ 17.652101] drm_pci_init+0xe1/0xf0 [ 17.652101] ? 0xffffffffa0006000 [ 17.652101] bochs_init+0x3c/0x1000 [bochs_drm] [ 17.652101] do_one_initcall+0x3e/0x180 [ 17.652101] ? kmem_cache_alloc_trace+0x33/0x150 [ 17.652101] do_init_module+0x5a/0x1eb [ 17.652101] load_module+0x1ea0/0x2650 [ 17.652101] ? __symbol_put+0x40/0x40 [ 17.652101] ? kernel_read_file+0x19e/0x1c0 [ 17.652101] ? kernel_read_file_from_fd+0x44/0x70 [ 17.652101] SYSC_finit_module+0xba/0xc0 [ 17.652101] SyS_finit_module+0x9/0x10 [ 17.652101] entry_SYSCALL_64_fastpath+0x1a/0xa9 [ 17.652101] RIP: 0033:0x7f92854da119 [ 17.652101] RSP: 002b:00007ffcd0390498 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 [ 17.652101] RAX: ffffffffffffffda RBX: 00007f928578eb58 RCX: 00007f92854da119 [ 17.652101] RDX: 0000000000000000 RSI: 0000564f1c8bd638 RDI: 0000000000000003 [ 17.652101] RBP: 000000000000270e R08: 0000000000000000 R09: 00007f9285790ea0 [ 17.652101] R10: 0000000000000003 R11: 0000000000000246 R12: 00007f928578eb58 [ 17.652101] R13: 0000000000001020 R14: 0000564f1cf9e1c0 R15: 00007f928578eb00 [ 17.652101] Code: c7 20 f8 ea 81 e8 b3 3e 50 00 48 8b 83 d0 00 00 00 48 8d 93 d0 00 00 00 48 39 c2 74 46 48 8b 83 d8 00 00 00 48 8b 93 d0 00 00 00 <48> 89 42 08 48 89 10 48 b8 00 01 00 00 0000 ad de 48 89 83 d0 [ 17.652101] RIP: drm_fb_helper_fini+0x8e/0x110 RSP: ffffc90000d87ad0 [ 17.653331] ---[ end trace 542fd75a2e60a6a4 ]--- Signed-off-by: Gabriel Krisman Bertazi <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Gerd Hoffmann <[email protected]>
2017-03-27drm/atomic: Introduce drm_atomic_helper_shutdownDaniel Vetter6-25/+57
The trouble here is that it does multiple atomic commits under one drm_modeset_lock_all, which breaks the behind-the-scenes acquire context magic that function pulls off. It's much better to have one overall atomic commit. That we still have multiple atomic commits prevents us from adding some pretty useful debug checks to the atomic machinery. Hence it is really a bad idea to call the legacy drm_crtc_force_disable_all() function. There's 2 atomic drivers using this still, nouveau and tinydrm. To fix this, introduce a new drm_atomic_helper_shutdown() by extracting the code from i915. While at it improve kernel-doc and catch future offenders by sprinkling a WARN_ON into the legacy function. We should probably move those into the legacy modeset helpers, too ... v2: Make it compile on arm drivers too (Noralf). v3: Correct kerneldoc to point at _disable_all(). Reviewed-by: Maarten Lankhorst <[email protected]> Acked-by: Noralf Trønnes <[email protected]> Cc: Maarten Lankhorst <[email protected]> Cc: Noralf Trønnes <[email protected]> Cc: Ben Skeggs <[email protected]> Tested-by: Tomi Valkeinen <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-03-27drm/tinydrm: Fix drm_driver.fops.ownerNoralf Trønnes3-18/+4
drm_driver.fops can't be shared since the owner then becomes tinydrm.ko. Move the fops declaration to the driver. v2: Use DEFINE_DRM_GEM_CMA_FOPS Reported-by: Daniel Vetter <[email protected]> Signed-off-by: Noralf Trønnes <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-03-27drm: dw_hdmi: Don't rely on the status of the bridge for updating HPDRomain Perier1-1/+1
Currently, the irq handler that monitors changes for HPD and RX_SENSE relies on the status of the bridge for updating the status of the HPD. The update is done only when the bridge is enabled. However, on Rockchip platforms we have found use cases where it could be a problem. When HDMI is being used, turning off/on the screen or unplugging/re-plugging the cable, the following simplified code path will happen: - dw_hdmi_irq() will be triggered by an HPD event, as the bridge is on hdmi->disabled is false, then the handler will update the rxsense flag accordingly. - dw_hdmi_update_power() will be invoked with the mode DRM_FORCE_UNSPECIFIED and rxsense == 1, so dw_hdmi_poweroff() will be called and the PHY will be desactivated (its pixel clocks and TMDS) [...] - dw_hdmi_bridge_disable() will be invoked, the bridge will be marked as disabled. - dw_hdmi_irq() will be triggered by an HPD event, as the bridge is currently disabled the HPD status won't be updated, so hdmi->rxsense won't be changed. Even if the data part of the PHY is disabled, this information coming from the HDMI Transmitter is correct and should be saved. [...] - dw_hdmi_bridge_enable() will be invoked, the bridge will be marked as enabled. - dw_hdmi_update_power() will be called. When hdmi->force is equal to DRM_FORCE_UNSPECIFIED the function will rely on hdmi->rxsense. If this field has not been updated by the irq handler, it will be false and DRM_FORCE_ON won't be put to hdmi->force. Consequently, most of the time dw_hdmi_poweron() won't be called in this use case, TMDS won't be re-enabled the PHY won't be re-initialized, resulting in a "Signal not found". This commit fixes the issue by removing the check for "!hdmi->disabled". As already explained, even if the PHY is partially disabled, information coming from HDMI Transmitter about HPD should be saved for a later use. Signed-off-by: Romain Perier <[email protected]> Signed-off-by: Archit Taneja <[email protected]> Link: https://patchwork.freedesktop.org/patch/143602/
2017-03-25drm/vblank: Remove DRM_VBLANKTIME_IN_VBLANKDaniel Vetter2-9/+0
The core code doesn't care at all about this, it's entirely dead. Cc: Mario Kleiner <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-03-25drm/todo: Add tinydrm refactoring ideasDaniel Vetter1-0/+70
Discussed with Noralf on the list a bit. An open question is tinydrm vs. drm_panel, but until we have a clear idea what's really needed in that space, I think it's best to just move forward with what we have. Cc: Noralf Trønnes <[email protected]> Acked-by: Noralf Trønnes <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-03-25drm: Extract drm_ioctl.hDaniel Vetter3-60/+104
To match the drm_ioctl.c we already have. v2: Remove spurious space (Ville). Cc: Ville Syrjälä <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2017-03-25drm/tilcdc: Drop calls to modeset_lock_crtcDaniel Vetter1-6/+6
Again this is an internal helper, not the official way to lock a crtc. Cc: Jyri Sarha <[email protected]> Cc: Tomi Valkeinen <[email protected]> Reviewed-by: Tomi Valkeinen <[email protected]> Acked-by: Jyri Sarha <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-03-24drm/rockchip/dsi: correct the grf_switch_reg nameChris Zhong1-2/+2
For the RK3399, the grf_switch_reg name should be RK3399_GRF_SOC_CON20, not RK3399_GRF_SOC_CON19. Signed-off-by: Chris Zhong <[email protected]> Reviewed-by: Brian Norris <[email protected]> Reviewed-by: Sean Paul <[email protected]> Signed-off-by: Sean Paul <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-03-24drm/rockchip/dsi: enable the grf clk before writing grf registersChris Zhong1-1/+25
For RK3399, the grf clk should be enabled before writing grf registers, otherwise the register value can not be changed. Signed-off-by: Chris Zhong <[email protected]> Reviewed-by: Sean Paul <[email protected]> Signed-off-by: Sean Paul <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-03-24dt-bindings: add the grf clock for dw-mipi-dsiChris Zhong1-1/+1
For RK3399, the grf clock should be controlled by dw-mipi-dsi driver, add the description for this clock. Acked-by: Rob Herring <[email protected] Signed-off-by: Chris Zhong <[email protected]> Reviewed-by: Sean Paul <[email protected]> Signed-off-by: Sean Paul <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-03-24drm/rockchip/dsi: check phy_cfg_clk only for RK3399Chris Zhong1-6/+8
For RK3399, the phy_cfg_clk is a required clock, if phy_cfg_clk is disabled, MIPI phy can not work. Let's return a error if there is no phy_cfg_clk in dts property, when the pdata match RK3399. Signed-off-by: Chris Zhong <[email protected]> Reviewed-by: Sean Paul <[email protected]> Signed-off-by: Sean Paul <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2017-03-24drm/rockchip: Refactor the component match logic.Jeffy Chen10-108/+118
Currently we are adding all components from the dts, if one of their drivers been disabled, we would not be able to bring up others. Refactor component match logic, follow exynos drm. Signed-off-by: Jeffy Chen <[email protected]> Reviewed-by: Andrzej Hajda <[email protected]> Acked-by: Mark Yao <[email protected]> Tested-by: Heiko Stuebner <[email protected]> Signed-off-by: Sean Paul <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Powered by cgit, Gruvboxed by Blaster4385.