- 26 Jul, 2017 35 commits
-
-
Philippe CORNU authored
Rename the returned value from "res" to "ret" as it is more "readable". Signed-off-by:
Philippe CORNU <philippe.cornu@st.com> Reviewed-by:
Benjamin Gaignard <benjamin.gaignard@linaro.org> Signed-off-by:
-
Philippe CORNU authored
Use devm_reset_control_get_exclusive to avoid resource leakage (based on patch "Convert drivers to explicit reset API" from Philipp Zabel). Also use platform_get_resource, which is more usual and consistent with platform_get_irq called later. Signed-off-by:
Fabien Dessenne <fabien.dessenne@st.com> Signed-off-by:
-
Philippe CORNU authored
Constify drm funcs structures. Signed-off-by:
-
Philippe CORNU authored
Lindent then checkpatch --strict cleanups Signed-off-by:
-
Philippe CORNU authored
The GCR_PCPOL/DEPOL/VSPOL/HSPOL defines are sufficient to describe the HS, VS, DE & PC signal polarities. Signed-off-by:
-
Philippe CORNU authored
Rename the platform driver name from "stm" to "stm32-display" for a better readability in /sys/bus/platform/drivers entries. Note: We keep "stm" as drm_driver.name because it is better when using "modetest -M stm ..." (even if recent modetest patch avoids using -M). Signed-off-by:
-
benjamin.gaignard@linaro.org authored
To do not force stm driver to be build by default Signed-off-by:
Emil Velikov <emil.l.velikov@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/1499699248-25776-1-git-send-email-benjamin.gaignard@linaro.org
-
Philippe CORNU authored
Add the STM32 DSI controller driver that uses the Synopsys DesignWare MIPI DSI host controller bridge. Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Reviewed-by:
Archit Taneja <architt@codeaurora.org> Signed-off-by:
-
Philippe CORNU authored
This patch adds documentation of device tree bindings for the STM32 DSI controller based on the Synopsys DesignWare MIPI DSI host controller. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Philippe CORNU authored
There is no need anymore to have a "st-display-subsystem" parent node in the device tree for the ltdc. Signed-off-by:
-
Arnd Bergmann authored
We cannot reference priv->fbdev outside of the #ifdef: drivers/net/virtio_net.c:1881:12: error: 'virtnet_restore_up' defined but not used [-Werror=unused-function] static int virtnet_restore_up(struct virtio_device *vdev) drivers/net/virtio_net.c:1859:13: error: 'virtnet_freeze_down' defined but not used [-Werror=unused-function] static void virtnet_freeze_down(struct virtio_device *vdev) As the #ifdef is a bit annoying here, this removes it entirely and uses an IS_ENABLED() check in it place where needed. Fixes: b4dd9f1ffaba ("drm/hisilicon: Remove custom FB helper deferred setup") Signed-off-by:Arnd Bergmann <arnd@arndb.de> [danvet: One step further, also remove the IS_ENABLED checks, core no-ops out the fb helper functions that the cma helpers use. Discussed with Arnd on dri-devel.] Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20170725180555.3699056-1-arnd@arndb.deSigned-off-by:
-
Maxime Ripard authored
The current drm_atomic_helper_commit_tail helper works only if the CRTC is accessible, and documents an alternative implementation that is supposed to be used if that happens. That implementation is then duplicated by some drivers. Instead of documenting it, let's implement an helper that all the relevant users can use directly. Signed-off-by:
Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by:
-
Liviu Dudau authored
Explain better when the drm_modeset_acquire_ctx parameter can be skipped for drm_modeset_lock() call. Signed-off-by:
Liviu Dudau <Liviu.Dudau@arm.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Thierry Reding authored
The FB helper core now supports deferred setup, so the driver's custom implementation can be removed. v2: Dont' resurrect drm_vblank_cleanup. Cc: Xinliang Liu <z.liuxinliang@hisilicon.com> Cc: Rongrong Zou <zourongrong@gmail.com> Cc: Xinwei Kong <kong.kongxinwei@hisilicon.com> Cc: Chen Feng <puck.chen@hisilicon.com> Signed-off-by: Thierry Reding <treding@nvidia.com> (v1) Reviewed-by:
Sean Paul <seanpaul@chromium.org> Signed-off-by:
-
Thierry Reding authored
The FB helper core now supports deferred setup, so the driver's custom implementation can be removed. v2: Drop NULL check, drm_fb_helper_hotplug_event handles that already. 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> Signed-off-by: Thierry Reding <treding@nvidia.com> (v1) Reviewed-by:
Inki Dae <inki.dae@samsung.com> Tested-by:
-
Daniel Vetter authored
FB helper code falls back to a 1024x768 mode if no outputs are connected or don't report back any modes upon initialization. This can be annoying because outputs that are added to FB helper later on can't be used with FB helper if they don't support a matching mode. The fallback is in place because VGA connectors can happen to report an unknown connection status even when they are in fact connected. Some drivers have custom solutions in place to defer FB helper setup until at least one output is connected. But the logic behind these solutions is always the same and there is nothing driver-specific about it, so a better alterative is to fix the FB helper core and add support for all drivers automatically. This patch adds support for deferred FB helper setup. It checks all the connectors for their connection status, and if all of them report to be disconnected marks the FB helper as needing deferred setup. Whet setup is deferred, the FB helper core will automatically retry setup after a hotplug event, and it will keep trying until it succeeds. v2: Rebase onto my entirely reworked fbdev helper locking. One big difference is that this version again drops&reacquires the fbdev lock (which is now fb_helper->lock, but before this patch series it was mode_config->mutex), because register_framebuffer must be able to recurse back into fbdev helper code for the initial screen setup. v3: __drm_fb_helper_initial_config must hold fb_helper->lock upon return, I've fumbled that in the deferred setup case (Liviu). v4: I was blind, redo this all. __drm_fb_helper_initial_config shouldn't need to reacquire fb_helper->lock, that just confuses callers. I myself got confused by kernel_fb_helper_lock and somehow thought it's the same as fb_helper->lock. Tsk. Also simplify the logic a bit (we don't need two functions to probe connectors), we can stick much closer to the existing code. And update some comments I've spotted that are outdated. v5: Don't pass -EAGAIN to drivers, it's just an internal error code (Liviu). v6: Add _and_unlock suffix to clarify locking (Maarten) Cc: Liviu Dudau <liviu@dudau.co.uk> Cc: John Stultz <john.stultz@linaro.org> Cc: Thierry Reding <treding@nvidia.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Tested-by:
John Stultz <john.stultz@linaro.org> Signed-off-by: Thierry Reding <treding@nvidia.com> (v1) Reviewed-by:
Maarten Lankhorst <maarten.lankhorst@intel.com> Reviewed-by:
Liviu Dudau <liviu@dudau.co.uk> Signed-off-by:
-
Daniel Vetter authored
It makes debugging a massive pain. Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: Gustavo Padovan <gustavo@padovan.org> Cc: linux-media@vger.kernel.org Cc: linaro-mm-sig@lists.linaro.org Reviewed-by:
Lucas Stach <l.stach@pengutronix.de> Acked-by:
Sumit Semwal <sumit.semwal@linaro.org> Acked-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170720125107.26693-1-daniel.vetter@ffwll.chSigned-off-by:
-
Rob Herring authored
Now that we have a custom printf format specifier, convert users of full_name to use %pOF instead. This is preparation to remove storing of the full path string for each node. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by:
Philipp Zabel <p.zabel@pengutronix.de> Acked-by:
-
Daniel Vetter authored
I need this to be able to apply the deferred fbdev setup patches, I need the relevant prep work that landed through the drm-intel tree. Also squash in conflict fixup from Laurent Pinchart. Signed-off-by: -
Daniel Vetter authored
make htmldocs helps with catching these. Cc: Dave Airlie <airlied@gmail.com> Acked-by:
Dave Airlie <airlied@gmail.com> Signed-off-by:
-
Maarten Lankhorst authored
Signed-off-by:
-
Maarten Lankhorst authored
Now that all drivers check the return value, convert swap_state to __must_check. This is done separately to force build warnings if we missed a driver. Signed-off-by:
-
Maarten Lankhorst authored
drm_atomic_helper_swap_state() will be changed to interruptible waiting in the next few commits, so all drivers have to be changed to handling failure. VC4 has its own nonblocking modeset tracking through the vc4->async_modeset semaphore, so it doesn't need to stall in swap_state. Pass stall = false and BUG_ON when it returns an error. This should never happen for !stall. Signed-off-by:
-
Maarten Lankhorst authored
drm_atomic_helper_swap_state() will be changed to interruptible waiting in the next few commits, so all drivers have to be changed to handling failure. Signed-off-by:
-
Maarten Lankhorst authored
drm_atomic_helper_swap_state() will be changed to interruptible waiting in the next few commits, so all drivers have to be changed to handling failure. Signed-off-by:
-
Maarten Lankhorst authored
drm_atomic_helper_swap_state() will be changed to interruptible waiting in the next few commits, so all drivers have to be changed to handling failure. MSM has its own busy tracking, which means the swap_state call can be done with stall = false, in which case it should never return an error. Handle failure with BUG_ON for this reason. Signed-off-by:
-
Maarten Lankhorst authored
drm_atomic_helper_swap_state() will be changed to interruptible waiting in the next few commits, so all drivers have to be changed to handling failure. Signed-off-by:
-
Maarten Lankhorst authored
drm_atomic_helper_swap_state() will be changed to interruptible waiting in the next few commits, so all drivers have to be changed to handling failure. Signed-off-by:
-
Maarten Lankhorst authored
drm_atomic_helper_swap_state() will be changed to interruptible waiting in the next few commits, so all drivers have to be changed to handling failure. Atmel tracks pending commits through dc->commit.pending, so it can ignore the changes by setting stall = false. We never return failure in this case, so make failure a BUG_ON. Signed-off-by:
-
Maarten Lankhorst authored
drm_atomic_helper_swap_state() will be changed to interruptible waiting in the next few commits, so all drivers have to be changed to handling failure. Signed-off-by:
-
Maarten Lankhorst authored
We want to change swap_state to wait indefinitely, but to do this swap_state should wait interruptibly. This requires propagating the error to each driver. Cc: dri-devel@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org Cc: intel-gfx@lists.freedesktop.org Signed-off-by:
-
Maarten Lankhorst authored
Make it more clear that post commit return ret is really return 0, and add a missing drm_atomic_helper_cleanup_planes when drm_atomic_helper_wait_for_fences fails. Fixes: 839ca903 ("drm/nouveau/kms/nv50: transition to atomic interfaces internally") Cc: Ben Skeggs <bskeggs@redhat.com> Cc: dri-devel@lists.freedesktop.org Cc: nouveau@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v4.10+ Signed-off-by:
-
Daniel Vetter authored
- FBINFO_CAN_FORCE_OUTPUT has been a lie ever since we nerfed&removed the entire panic handling code in our fbdev emulation. We might restore kms panic output, but not through the bazillion of legacy code layers called fbdev/fbcon, there's just no way to make that work safely. - With the module check change FBINFO_DEFAULT is always 0, so can be removed too. That removes another change to cargo-cult stuff in kms drivers, yay! Reviewed-by:
-
Daniel Vetter authored
It's not accelarated, just system memory. Note we don't even need to set the default flag since that's now always 0. Note that originally qxl had acceleration support, but that was all ripped out in commit c0fe07aa Author: Gerd Hoffmann <kraxel@redhat.com> Date: Tue May 5 13:52:49 2015 +0200 drm/qxl: rewrite framebuffer support v2: Amend commit message a bit after irc chat with Dave. Cc: Dave Airlie <airlied@redhat.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: virtualization@lists.linux-foundation.org Acked-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Daniel Vetter authored
Not all places correctly stated that gem_free_object_unlocked is the one to use. Reported-by: Eric Anholt <eric@anholt.net Cc: Eric Anholt <eric@anholt.net Reviewed-by:
Eric Anholt <eric@anholt.net> Signed-off-by:
-
- 20 Jul, 2017 1 commit
-
-
git://anongit.freedesktop.org/git/drm-intelDave Airlie authored
2nd round of 4.14 features: - prep for deferred fbdev setup - refactor fixed 16.16 computations and skl+ wm code (Mahesh Kumar) - more cnl paches (Rodrigo, Imre et al) - tighten context cleanup and handling (Chris Wilson) - fix interlaced handling on skl+ (Mahesh Kumar) - small bits as usual * tag 'drm-intel-next-2017-07-17' of git://anongit.freedesktop.org/git/drm-intel: (84 commits) drm/i915: Update DRIVER_DATE to 20170717 drm/i915: Protect against deferred fbdev setup drm/i915/fbdev: Always forward hotplug events drm/i915/skl+: unify cpp value in WM calculation drm/i915/skl+: WM calculation don't require height drm/i915: Addition wrapper for fixed16.16 operation drm/i915: cleanup fixed-point wrappers naming drm/i915: Always perform internal fixed16 division in 64 bits drm/i915: take-out common clamping code of fixed16 wrappers drm/i915/cnl: Add missing type case. drm/i915/cnl: Add max allowed Cannonlake DC. drm/i915: Make DP-MST connector info work drm/i915/cnl: Get DDI clock based on PLLs. drm/i915/cnl: Inherit RPS stuff from previous platforms. drm/i915/cnl: Gen10 render context size. drm/i915/cnl: Don't trust VBT's alternate pin for port D for now. drm/i915: Fix the kernel panic when using aliasing ppgtt drm/i915/cnl: Cannonlake color init. drm/i915/cnl: Add force wake for gen10+. x86/gpu: CNL uses the same GMS values as SKL ...
-
- 18 Jul, 2017 4 commits
-
-
Daniel Vetter authored
For modern drivers the DRM core doesn't use struct_mutex at all, which means it's defacto a driver-private lock. But since we still need it for legacy drivers we can't initialize it in drivers, which means all the different instances share one lockdep key. Despite that they might be placed in totally different places in the locking hierarchy. This results in a lot of bogus lockdep splats when running stuff on systems with multiple gpus. Partially remedy the situation by only doing might_lock checks on drivers that do use struct_mutex still for gem locking. A more complete solution would be to do the mutex_init in the drm core only for legacy drivers, plus add it to each modern driver that still needs it, which would also give each its own lockdep key. Trying to do that dynamically doesn't work, because lockdep requires it's keys to be statically allocated. v2: {} everywhere (Chris) Cc: Hans de Goede <hdegoede@redhat.com> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Jiri Slaby <jirislaby@gmail.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Ingo Molnar <mingo@redhat.com> Reviewed-by:Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Daniel Vetter authored
CMA helpers are struct_mutex free, and so is the zte itself. And that's the only valid reason for using gem_free_object. Signed-off-by:
-
Daniel Vetter authored
CMA helpers are struct_mutex free, and so is the pl111 itself. And that's the only valid reason for using gem_free_object. Signed-off-by:
-
Daniel Vetter authored
CMA helpers are struct_mutex free, and so is the mxsfb itself. And that's the only valid reason for using gem_free_object. Reviewed-by:
-
