- 30 Mar, 2018 2 commits
-
-
Daniel Stone authored
Make it a little more clear what's going on inside of getfb, and also make it easier to add alternate paths to get a handle in future. Signed-off-by:
Daniel Stone <daniels@collabora.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180323134553.15993-3-daniels@collabora.com
-
Sean Paul authored
Backmerging to pick up a fix from drm-misc-next-fixes. Signed-off-by:Sean Paul <seanpaul@chromium.org>
-
- 29 Mar, 2018 14 commits
-
-
Ville Syrjälä authored
When doing forced load detection testing we should totally ignore any hotplug status for the connector. This is mostly relevant for machines where we already ignore the hotplug status based on the DMI quirks. On other machines we would currently skip the force load detection tests on account of the connector already being connected. v2: Drop the other force_load_detect check since it's useless now (Maarten) Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
-
Ville Syrjälä authored
Actually turn the planes back on after were done with the load detection. Fixes: 20bdc112 ("drm/i915: Disable all planes for load detection, v2.") Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
-
Ville Syrjälä authored
We want to get rid of plane->crtc on atomic drivers. Stop looking at it. v2: Use old_state->crtc (Maarten) v3: s/fb/crtc/ in commit message to actually match the patch (Shawn) Cc: Shawn Guo <shawnguo@kernel.org> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
Shawn Guo <shawnguo@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20180326121442.32009-1-ville.syrjala@linux.intel.comReviewed-by:
-
Ville Syrjälä authored
We want to get rid of plane->fb on atomic drivers. Stop looking at it. Cc: VMware Graphics <linux-graphics-maintainer@vmware.com> Cc: Sinclair Yeh <syeh@vmware.com> Cc: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by:
Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by:
-
Ville Syrjälä authored
We want to get rid of plane->fb on atomic drivers. Stop looking at it. Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org> Cc: Vincent Abriou <vincent.abriou@st.com> Signed-off-by:
Benjamin Gaignard <benjamin.gaignard@linaro.org> Reviewed-by:
-
Ville Syrjälä authored
We want to get rid of plane->fb on atomic drivers. Stop looking at it. Signed-off-by:
-
Ville Syrjälä authored
Stop looking at plane->fb on atomic drivers. Use plane->state->fb instead. Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
-
Ville Syrjälä authored
Instead of assigning the plane->fb pointer and clearing the fb pointer to hand over the reference, let's just do it by grabbing another referece for plane->fb and let fb keep its original one. Signed-off-by:
-
Ville Syrjälä authored
Add a bit of whitespace here and there to make the code look a bit more structured. Signed-off-by:
-
Ville Syrjälä authored
Make the code a bit more readable by storing the plane pointer in a local variable rather than having to do crtc->{primary,cursor} all the time. Signed-off-by: -
Ville Syrjälä authored
drm_atomic_helper_commit_duplicated_state() should only be called resume/reset/load_detect paths where plane->old_fb should always be NULL and plane->fb should be equal to the new_plane_state->fb. Assert that is indeed the case. Cc: martin.peres@free.fr Cc: chris@chris-wilson.co.uk Cc: Dave Airlie <airlied@gmail.com> (v1) Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Keep the primary->crtc in sync with the state->crtc (also with primary->fb and state->fb) when disabling the crtc (and thus also the primary) via setcrtc(). Signed-off-by:
-
Ville Syrjälä authored
drm_atomic_helper_shutdown() needs to release the reference held by plane->fb. Since commit 49d70aea ("drm/atomic-helper: Fix leak in disable_all") we're doing that by calling drm_atomic_clean_old_fb() in drm_atomic_helper_disable_all(). This also leaves plane->fb == NULL afterwards. However, since drm_atomic_helper_disable_all() is also used by the i915 gpu reset code drm_atomic_helper_commit_duplicated_state() then has to undo the damage and put the correct plane->fb pointers back in (and also adjust the ref counts to match again as well). That approach doesn't work so well for load detection as nothing sets up the plane->old_fb pointers for us. This causes us to leak an extra reference for each plane->fb when drm_atomic_helper_commit_duplicated_state() calls drm_atomic_clean_old_fb() after load detection. To fix this let's call drm_atomic_clean_old_fb() only for drm_atomic_helper_shutdown() as that's the only time we need to actually drop the plane->fb references. In all the other cases (load detection, gpu reset) we want to leave plane->fb alone. v2: Don't inflict the clean_old_fbs bool to drivers (Daniel) v3: Squash in the revert and rewrite the commit msg (Daniel) Cc: martin.peres@free.fr Cc: chris@chris-wilson.co.uk Cc: Dave Airlie <airlied@gmail.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Noralf Trønnes authored
Use srcu to protect drm_device.unplugged in a race free manner. Drivers can use drm_dev_enter()/drm_dev_exit() to protect and mark sections preventing access to device resources that are not available after the device is gone. Suggested-by:
Noralf Trønnes <noralf@tronnes.org> Signed-off-by:
Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Reviewed-by:
-
- 28 Mar, 2018 20 commits
-
-
git://anongit.freedesktop.org/drm/drm-miscDave Airlie authored
- Mask mode type garbage from userspace (Ville) Something went wrong on the misc tree side, but I'll pull the patch directly. * 'drm-misc-next-fixes' of git://anongit.freedesktop.org/drm/drm-misc: drm: Fix uabi regression by allowing garbage mode->type from userspace
-
Samuel Li authored
To reduce some warnings. Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
Samuel Li <Samuel.Li@amd.com> Signed-off-by:
-
Ville Syrjälä authored
mipi_dbi_enable_flush() wants to call the fb->dirty() hook from the bowels of the .atomic_enable() hook. That prevents us from taking the plane mutex in fb->dirty() unless we also plumb down the acquire context. Instead it seems simpler to split the fb->dirty() into a tinydrm specific lower level hook that can be called from mipi_dbi_enable_flush() and from a generic higher level tinydrm_fb_dirty() helper. As we don't have a tinydrm specific vfuncs table we'll just stick it into tinydrm_device directly for now. v2: Deal with the fb->dirty() in tinydrm_display_pipe_update() as well (Noralf) Cc: "Noralf Trønnes" <noralf@tronnes.org> Cc: David Lechner <david@lechnology.com> Signed-off-by:
-
Ville Syrjälä authored
tinydrm enable hook wants to play around with the new fb in .atomic_enable(), thus we'll need access to the plane state. Performed with coccinelle: @r1@ identifier F =~ ".*enable$"; identifier P, CS; @@ F( struct drm_simple_display_pipe *P ,struct drm_crtc_state *CS + ,struct drm_plane_state *plane_state ) { ... } @@ struct drm_simple_display_pipe *P; expression E; @@ { + struct drm_plane *plane; ... + plane = &P->plane; P->funcs->enable(P ,E + ,plane->state ); ... } @@ identifier P, CS; @@ struct drm_simple_display_pipe_funcs { ... void (*enable)(struct drm_simple_display_pipe *P ,struct drm_crtc_state *CS + ,struct drm_plane_state *plane_state ); ... }; v2: Pimp the commit message (David) Cc: Marek Vasut <marex@denx.de> Cc: Eric Anholt <eric@anholt.net> Cc: David Lechner <david@lechnology.com> Cc: "Noralf Trønnes" <noralf@tronnes.org> Cc: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: -
Daniel Vetter authored
It's only used to protect our page list, and only when we know we have a full reference. This means none of these code paths can ever race with the final unref, and hence we do not need dev->struct_mutex serialization and can simply switch to our own locking. For more context the only magic the locked gem_free_object provides is that it prevents concurrent final unref (and destruction) of gem objects while anyone is holding dev->struct_mutex. This was used by i915 (and other drivers) to implement eviction handling with less headaches. Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Cc: Dave Airlie <airlied@redhat.com> Reviewed-by:
-
Daniel Vetter authored
Just want to clean out all grep hits. gem_free_object is deprecated. Signed-off-by:
-
Daniel Vetter authored
vboxvideo doesn't use dev->struct_mutex and therefore has no need to use gem_free_object. Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://patchwork.freedesktop.org/patch/msgid/20180327082356.24516-1-daniel.vetter@ffwll.ch
-
Peter Ujfalusi authored
Planes with identical zpos value will result undefined behavior: disappearing planes, screen flickering and it is not supported by the hardware. Use normalized zpos to make sure that we don't encounter invalid configuration. Signed-off-by:
Peter Ujfalusi <peter.ujfalusi@ti.com> CC: Tomi Valkeinen <tomi.valkeinen@ti.com> Acked-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by:
-
Peter Ujfalusi authored
Set the drm_mode_config->normalize_zpos and call drm_atomic_helper_check() from rcar_du_atomic_check() instead of re implementing the function locally. Signed-off-by:
-
Peter Ujfalusi authored
Instead of re-implementing the drm_atomic_helper_check() locally with just adding drm_atomic_normalize_zpos() into it, set the drm_mode_config->normalize_zpos. Note: the drm_atomic_helper_check() now includes if (state->legacy_cursor_update) state->async_update = !drm_atomic_helper_async_check(drm, state); which was added after the driver moved away from using it (38d868e4 drm: Don't force all planes to be added to the state due to zpos) Signed-off-by:
-
Peter Ujfalusi authored
Set the drm_mode_config->normalize_zpos and call the generic drm_atomic_helper_check() instead of duplicating it within tegra_atomic_check(). Call tegra_display_hub_atomic_check() after the drm_atomic_helpre_check() returned without error. Signed-off-by:
-
Peter Ujfalusi authored
Instead of re-implementing the drm_atomic_helper_check() locally with just adding drm_atomic_normalize_zpos() into it, set the drm_mode_config->normalize_zpos. Signed-off-by:
Inki Dae <inki.dae@samsung.com> Signed-off-by:
-
Peter Ujfalusi authored
Instead of drivers duplicating the drm_atomic_helper_check() code to be able to normalize the zpos they can use the normalize_zpos flag to let the drm core to do it. Signed-off-by:
-
Jani Nikula authored
Bool is the more appropriate return type here, use it. Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180327204722.31246-3-jani.nikula@intel.com
-
Jani Nikula authored
Throw out the leftovers. Reviewed-by:
-
Jani Nikula authored
Remove last users of __inline__. Reviewed-by:
-
Andy Shevchenko authored
It seems there is a classical off-by-one typo from the beginning when commit ad7f8a1f ("drm/helper: add Displayport multi-stream helper (v0.6)") introduced a new helper. Fix a typo by introducing a macro constant. Cc: Dave Airlie <airlied@redhat.com> Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
git://people.freedesktop.org/~gabbayo/linuxDave Airlie authored
- GPUVM support for dGPUs - KFD events support for dGPUs - Fix live-lock situation when restoring multiple evicted processes - Fix VM page table allocation on large-bar systems - Fix for build failure on frv architecture * tag 'drm-amdkfd-next-2018-03-27' of git://people.freedesktop.org/~gabbayo/linux: drm/amdkfd: Use ordered workqueue to restore processes drm/amdgpu: Fix acquiring VM on large-BAR systems drm/amdkfd: Add module option for testing large-BAR functionality drm/amdkfd: Kmap event page for dGPUs drm/amdkfd: Add ioctls for GPUVM memory management drm/amdkfd: Add TC flush on VMID deallocation for Hawaii drm/amdkfd: Allocate CWSR trap handler memory for dGPUs drm/amdkfd: Add per-process IDR for buffer handles drm/amdkfd: Aperture setup for dGPUs drm/amdkfd: Remove limit on number of GPUs drm/amdkfd: Populate DRM render device minor drm/amdkfd: Create KFD VMs on demand drm/amdgpu: Add kfd2kgd interface to acquire an existing VM drm/amdgpu: Add helper to turn an existing VM into a compute VM drm/amdgpu: Fix initial validation of PD BO for KFD VMs drm/amdgpu: Move KFD-specific fields into struct amdgpu_vm drm/amdkfd: fix uninitialized variable use drm/amdkfd: add missing include of mm.h
-
Dave Airlie authored
Merge tag 'drm-intel-next-fixes-2018-03-27' of git://anongit.freedesktop.org/drm/drm-intel into drm-next - Display fixes for booting with MST hub lid closed and display freezing after hibernation (fd.o bugs 105470 & 105196) - Fix for a very rare interrupt handling race resulting in GPU hang * tag 'drm-intel-next-fixes-2018-03-27' of git://anongit.freedesktop.org/drm/drm-intel: drm/i915: Fix hibernation with ACPI S0 target state drm/i915/execlists: Use a locked clear_bit() for synchronisation with interrupt drm/i915: Specify which engines to reset following semaphore/event lockups drm/i915/dp: Write to SET_POWER dpcd to enable MST hub.
-
Dave Airlie authored
Linux 4.16-rc7 This was requested by Daniel, and things were getting a bit hard to reconcile, most of the conflicts were trivial though.
-
- 27 Mar, 2018 4 commits
-
-
Imre Deak authored
After commit dd9f31c7 Author: Imre Deak <imre.deak@intel.com> Date: Wed Aug 16 17:46:07 2017 +0300 drm/i915/gen9+: Set same power state before hibernation image save/restore during hibernation/suspend the power domain functionality got disabled, after which resume could leave it incorrectly disabled if the ACPI target state was S0 during suspend and i915 was not loaded by the loader kernel. This was caused by not considering if we resumed from hibernation as the condition for power domains reiniting. Fix this by simply tracking if we suspended power domains during system suspend and reinit power domains accordingly during resume. This will result in reiniting power domains always when resuming from hibernation, regardless of the platform and whether or not i915 is loaded by the loader kernel. The reason we didn't catch this earlier is that the enabled/disabled state of power domains during PMSG_FREEZE/PMSG_QUIESCE is platform and kernel config dependent: on my SKL the target state is S4 during PMSG_FREEZE and (with the driver loaded in the loader kernel) S0 during PMSG_QUIESCE. On the reporter's machine it's S0 during PMSG_FREEZE but (contrary to this) power domains are not initialized during PMSG_QUIESCE since i915 is not loaded in the loader kernel, or it's loaded but without the DMC firmware being available. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105196 Reported-and-tested-by: amn-bas@hotmail.com Fixes: dd9f31c7 ("drm/i915/gen9+: Set same power state before hibernation image save/restore") Cc: amn-bas@hotmail.com Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: <stable@vger.kernel.org> Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
-
Chris Wilson authored
We were relying on the uncached reads when processing the CSB to provide ourselves with the serialisation with the interrupt handler (so we could detect new interrupts in the middle of processing the old one). However, in commit 767a983a ("drm/i915/execlists: Read the context-status HEAD from the HWSP") those uncached reads were eliminated (on one path at least) and along with them our serialisation. The result is that we would very rarely miss notification of a new interrupt and leave a context-switch unprocessed, hanging the GPU. Fixes: 767a983a ("drm/i915/execlists: Read the context-status HEAD from the HWSP") Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by:
Michel Thierry <michel.thierry@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180321091027.21034-1-chris@chris-wilson.co.uk (cherry picked from commit 9153e6b7) Signed-off-by:
-
Chris Wilson authored
If the GPU is stuck waiting for an event or for a semaphore, we need to reset the GPU in order to recover. We have to tell the reset routine which engines we want reset, but we were still using the old interface and declaring it as "not-fatal". Fixes: 14b730fc ("drm/i915/tdr: Prepare error handler to accept mask of hung engines") Signed-off-by:
-
Dhinakaran Pandiyan authored
If bios sets up an MST output and hardware state readout code sees this is an SST configuration, when disabling the encoder we end up calling ->post_disable_dp() hook instead of the MST version. Consequently, we write to the DP_SET_POWER dpcd to set it D3 state. Further along when we try enable the encoder in MST mode, POWER_UP_PHY transaction fails to power up the MST hub. This results in continuous link training failures which keep the system busy delaying boot. We could identify bios MST boot discrepancy and handle it accordingly but a simple way to solve this is to write to the DP_SET_POWER dpcd for MST too. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105470 Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by:
Laura Abbott <labbott@redhat.com> Cc: stable@vger.kernel.org Fixes: 5ea2355a ("drm/i915/mst: Use MST sideband message transactions for dpms control") Tested-by:
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by:
-
