- 31 Mar, 2017 4 commits
-
-
Thierry Reding authored
Add a couple of temporary variables and use shorter names for existing variables in drm_fb_helper_add_one_connector() for better readability. Tested-by:
John Stultz <john.stultz@linaro.org> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
-
Thierry Reding authored
An unlocked version of the drm_fb_helper_add_one_connector() function will be added in a subsequent patch. Reshuffle the code separately to make the diff more readable later on. Tested-by:
-
Thierry Reding authored
Fix up a couple of checkpatch warnings, such as whitespace or coding style issues. Tested-by:
-
Russell King authored
Add debugfs output to report shared and exclusive fences on a dma_buf object. This produces output such as: Dma-buf Objects: size flags mode count exp_name 08294400 00000000 00000005 00000005 drm Exclusive fence: etnaviv 134000.gpu signalled Attached Devices: gpu-subsystem Total 1 devices attached Total 1 objects, 8294400 bytes Signed-off-by:Russell King <rmk+kernel@arm.linux.org.uk> Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
Gustavo Padovan <gustavo.padovan@collabora.com> Link: http://patchwork.freedesktop.org/patch/msgid/E1cttMI-00068z-3X@rmk-PC.armlinux.org.uk
-
- 30 Mar, 2017 6 commits
-
-
Lukas Wunner authored
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 <andy.shevchenko@gmail.com> Signed-off-by:
Lukas Wunner <lukas@wunner.de> Link: http://patchwork.freedesktop.org/patch/msgid/4d1fcc92d1960049e2cff997fbd2d74e45e84e49.1489145162.git.lukas@wunner.de
-
Lukas Wunner authored
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 <bskeggs@redhat.com> Acked-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Lukas Wunner authored
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:
-
Lukas Wunner authored
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:
-
Lukas Wunner authored
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 <andreas.noever@gmail.com> Cc: Michael Jamet <michael.jamet@intel.com> Cc: Tomas Winkler <tomas.winkler@intel.com> Cc: Amir Levy <amir.jer.levy@intel.com> Acked-by:Bjorn Helgaas <bhelgaas@google.com> Signed-off-by:
-
Lukas Wunner authored
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:
-
- 31 Mar, 2017 1 commit
-
-
Daniel Vetter authored
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 <eric@anholt.net> Fixes: 29dc0d1d ("drm: Roll out acquire context for the page_flip ioctl") Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Sean Paul <seanpaul@chromium.org> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170330204831.8225-1-daniel.vetter@ffwll.chTested-by:
Harry Wentland <harry.wentland@amd.com>
-
- 30 Mar, 2017 7 commits
-
-
Eric Anholt authored
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:
-
Daniel Vetter authored
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 <julia.lawall@lip6.fr> Reported-by:
Julia Lawall <julia.lawall@lip6.fr> Fixes: 29dc0d1d ("drm: Roll out acquire context for the page_flip ioctl") Cc: Harry Wentland <harry.wentland@amd.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Sean Paul <seanpaul@chromium.org> Reviewed-by:
-
Chris Wilson authored
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 <fengguang.wu@intel.com> Reported-by:
Leonard Crestez <leonard.crestez@nxp.com> Fixes: 43dc7fe2 ("drm: Mark up accesses of vblank->enabled outside of its spinlock") Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170330140832.32377-1-chris@chris-wilson.co.uk
-
Christopher Spinrath authored
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 <jsarha@ti.com> Signed-off-by:
Christopher Spinrath <christopher.spinrath@rwth-aachen.de> Signed-off-by:
Archit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/2e47786ab3d04078ae70d0c4064f7c4d@rwthex-s1-b.rwth-ad.de
-
Javi Merino authored
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 <C.Emde@osadl.org> Cc: David Airlie <airlied@linux.ie> Acked-by:
David Airlie <airlied@linux.ie> Signed-off-by:
Javi Merino <javi.merino@kernel.org> Signed-off-by:
-
Maarten Lankhorst authored
v2 of the commit 2c77bb29 ("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 <maarten.lankhorst@linux.intel.com> Fixes: 2c77bb29 ("drm: simplify the locking in the GETCRTC ioctl") Reported-by:
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by:
-
Daniel Vetter authored
I've screwed this up when removing the legacy backoff hack. Fixes: 38b6441e ("drm/atomic-helper: Remove the backoff hack from set_config") Cc: Harry Wentland <harry.wentland@amd.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Sean Paul <seanpaul@chromium.org> Cc: David Airlie <airlied@linux.ie> Cc: dri-devel@lists.freedesktop.org Reviewed-by:
-
- 29 Mar, 2017 21 commits
-
-
Chris Wilson authored
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 authored
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:
Michel Dänzer <michel.daenzer@amd.com> Reviewed-by:
-
Chris Wilson authored
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 authored
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 authored
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:
-
Daniel Vetter authored
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:
-
Daniel Vetter authored
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 <syeh@vmware.com> Cc: Thomas Hellstrom <thellstrom@vmware.com> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian König <christian.koenig@amd.com> Reviewed-by:
-
Daniel Vetter authored
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:
-
Daniel Vetter authored
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:
-
Daniel Vetter authored
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 <harry.wentland@amd.com> Reviewed-by:
-
Daniel Vetter authored
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:
-
Daniel Vetter authored
Again just going through the motions, no functional changes in here. Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Russell King <linux@armlinux.org.uk> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Eric Anholt <eric@anholt.net> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian König <christian.koenig@amd.com> Reviewed-by:
-
Daniel Vetter authored
Again just prep work. Reviewed-by:
-
Daniel Vetter authored
We can now properly retry at the top level, yay! v2: Also remove the temporary acquire_ctx hack again, no longer needed! Reviewed-by:
-
Daniel Vetter authored
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 <bskeggs@redhat.com> Cc: Russell King <linux@armlinux.org.uk> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by:
-
Daniel Vetter authored
This way I can explain why it'll be fine to pass a NULL acquire ctx here in the next patch. Reviewed-by:
-
Daniel Vetter authored
Just rolling it out, no code change here. Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Russell King <linux@armlinux.org.uk> Cc: Rob Clark <robdclark@gmail.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Eric Anholt <eric@anholt.net> Reviewed-by:
-
Daniel Vetter authored
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:
-
Daniel Vetter authored
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 <harry.wentland@amd.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by:
-
Daniel Vetter authored
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 <harry.wentland@amd.com> Reviewed-by:
-
Daniel Vetter authored
They're properly documented in drm_connector.c now, and this csv file is a horrible mess. Better to remove it. Reviewed-by:
-
- 28 Mar, 2017 1 commit
-
-
Shashank Sharma authored
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 <daniel@ffwll.ch> Signed-off-by:
Shashank Sharma <shashank.sharma@intel.com> Signed-off-by:
-
