- 14 Jul, 2017 7 commits
-
-
Noralf Trønnes authored
This adds support for the Pervasive Displays RePaper branded displays. The controller code is taken from the userspace driver available through repaper.org. Only the V231 film is supported since the others are EOL. Acked-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Noralf Trønnes <noralf@tronnes.org> Link: http://patchwork.freedesktop.org/patch/msgid/1496934875-51984-5-git-send-email-noralf@tronnes.org
-
Noralf Trønnes authored
Drm has no monochrome or greyscale support so add a conversion from the common format XR24. Also reorder includes into the common order. Acked-by:
-
Noralf Trønnes authored
Add device-tree binding documentation for the 1.44", 1.9", 2.0" and 2.7" display panels. Acked-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Noralf Trønnes authored
Pervasive Displays Inc. designs, develops, and manufactures low-power electrophoretic (e-ink) display modules and supporting electronics for commercial and industrial display applications. Acked-by:
-
Peter Rosin authored
The legacy path implements setcmap in terms of crtc .gamma_set. The atomic path implements setcmap by directly updating the crtc gamma_lut property. This has a couple of benefits: - it makes the redundant fb helpers .load_lut, .gamma_set and .gamma_get completely obsolete. They are now unused and subject for removal. - atomic drivers that support clut modes get fbdev support for those from the drm core. This includes atmel-hlcdc, but perhaps others as well? Signed-off-by:
Peter Rosin <peda@axentia.se> Signed-off-by:
-
Peter Rosin authored
Do not waste cycles looking up the property id when we have the actual property already. Signed-off-by:
-
Peter Rosin authored
The function has little to do with atomic, it's just where it has so far been needed. So, rename it to drm_property_replace_blob, move it to drm_property.c and export it. Change the semantics to return whether the blob was replaced instead of using an extra argument for that. Signed-off-by:
-
- 13 Jul, 2017 15 commits
-
-
Ville Syrjälä authored
We have memch_inv(), so no need to memcmp() against a zeroed temp array. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170712155254.26455-1-ville.syrjala@linux.intel.comReviewed-by:
-
Ville Syrjälä authored
Make the atomic private object stuff less special by introducing proper base classes for the object and its state. Drivers can embed these in their own appropriate objects, after which these things will work exactly like the plane/crtc/connector states during atomic operations. v2: Reorder to not depend on drm_dynarray (Daniel) Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> #v1 Signed-off-by:
-
Ville Syrjälä authored
We will never add private objects with a NULL state into the atomic state, hence checking for that is pointless. Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by:
-
Ville Syrjälä authored
On failure drm_atomic_get_private_obj_state() returns and error pointer instead of NULL. Adjust the checks in the callers to match. Cc: stable@vger.kernel.org Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Harry Wentland <harry.wentland@amd.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Fixes: edb1ed1a ("drm/dp: Add DP MST helpers to atomically find and release vcpi slots") Signed-off-by:
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
-
Maarten Lankhorst authored
for_each_obj_in_state is about to be removed, so use the new atomic iterator macros. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: CK Hu <ck.hu@mediatek.com> Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: Matthias Brugger <matthias.bgg@gmail.com> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-mediatek@lists.infradead.org Link: http://patchwork.freedesktop.org/patch/msgid/20170712081344.25495-14-maarten.lankhorst@linux.intel.comReviewed-by:
Philipp Zabel <p.zabel@pengutronix.de>
-
Maarten Lankhorst authored
for_each_obj_in_state is about to be removed, so use the new atomic iterator macros. Signed-off-by:
-
Maarten Lankhorst authored
for_each_obj_in_state is about to be removed, so use the new iterator macros. Signed-off-by:
Liviu Dudau <liviu.dudau@arm.com>
-
Maarten Lankhorst authored
for_each_obj_in_state is about to be removed, so use the new atomic iterator macros. Signed-off-by:
Mark Yao <mark.yao@rock-chips.com>
-
Maarten Lankhorst authored
for_each_obj_in_state is about to be removed, so use the new iterator macros. Signed-off-by:
Boris Brezillon <boris.brezillon@free-electrons.com>
-
Maarten Lankhorst authored
for_each_connector_in_state will be removed, so use the right state here. Signed-off-by:
-
Maarten Lankhorst authored
I don't think the checking of resources in this function is very atomic-like, but it should definitely not use a macro that's about to be removed. Signed-off-by:
Sinclair Yeh <syeh@vmware.com> Reviewed-by:
-
Maarten Lankhorst authored
for_each_obj_in_state is about to be removed, so use the correct new iterator macro. Signed-off-by:
-
Maarten Lankhorst authored
for_each_obj_in_state will be removed, so don't use it here. Signed-off-by:
-
Maarten Lankhorst authored
for_each_obj_in_state will be removed, so use the new state here. Signed-off-by:
-
Maarten Lankhorst authored
You can enable the CRTC and without adding the plane to the state and it will succeed. This should be prevented in the crtc check instead of the plane check, because the plane check may never run for atomic enable, but the crtc check always will. This is based on a similar check in vmwgfx. Signed-off-by:
-
- 11 Jul, 2017 1 commit
-
-
Alexandru Moise authored
If the DRM core fails to init for whatever reason, ensure that no driver ever calls drm_dev_register(). This is best done at drm_dev_init() as it covers drivers that call drm_dev_alloc() as well as drivers that prefer to embed struct drm_device into their own device struct and call drm_dev_init() themselves. In my case I had so many dynamic device majors used that the major number for DRM (226) was stolen, causing DRM core init to fail after failing to register a chrdev, and ultimately calling debugfs_remove() on drm_debugfs_root in drm_core_exit(). After drm core failed to init, VGEM was still calling drm_dev_register(), ultimately leading to drm_debugfs_init(), with drm_debugfs_root passed as the root for the new debugfs dir at debugfs_create_dir(). This led to a kernel panic once we were either derefencing root->d_inode while it was NULL or calling root->d_inode->i_op->lookup() while it was NULL in debugfs at inode_lock() or lookup_*(). Signed-off-by:
Alexandru Moise <00moses.alexander00@gmail.com> Signed-off-by:
-
- 06 Jul, 2017 17 commits
-
-
Inki Dae authored
This patch removes unnecessary checking of return value. Signed-off-by:
Inki Dae <inki.dae@samsung.com> Signed-off-by:
Archit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/1499071350-25168-12-git-send-email-inki.dae@samsung.com
-
Inki Dae authored
This patch removes unnecessary checking of return value. Signed-off-by:
-
Inki Dae authored
This patch removes unnecessary checking of return value. Signed-off-by:
-
Inki Dae authored
This patch removes unnecessary checking of return value. Signed-off-by:
-
Inki Dae authored
This patch removes unnecessary checking of return value. Signed-off-by:
-
Inki Dae authored
This patch removes unnecessary checking of return value. Signed-off-by:
-
Inki Dae authored
This patch removes unnecessary checking of return value. Signed-off-by:
-
Inki Dae authored
This patch removes unnecessary checking of return value. Signed-off-by:
-
Inki Dae authored
This patch removes unnecessary checking of return value. Signed-off-by:
-
Inki Dae authored
This patch removes unnecessary checking of return value. Signed-off-by:
-
Peter Rosin authored
drm_fb_helper_save_lut_atomic is redundant since the .gamma_store is now always kept up to date by drm_fb_helper_setcmap. Signed-off-by:
-
Peter Rosin authored
I think the gamma_store can end up invalid on error. But the way I read it, that can happen in drm_mode_gamma_set_ioctl as well, so why should this pesky legacy fbdev stuff be any better? Signed-off-by:
-
Peter Rosin authored
The pseudo-palette has nothing to do with the crtc, so move it out of the crtc loop and update the palette once, then break out early. Signed-off-by:
Peter Rosin <peda@axenita.se> Signed-off-by:
-
Daniel Vetter authored
Like with panning and modesetting, and like with those, stick with simple drm_modeset_locking_all for the legacy path, and the full atomic dance for atomic drivers. This means a bit more boilerplate since setting up the atomic state machinery is rather verbose, but then this is shared code for 30+ drivers or so, so meh. After this patch there's only the LUT/cmap path which is still using drm_modeset_lock_all for an atomic driver. But Peter is already locking into reworking that, so I'll leave that code as-is for now. v2: Squash in patches from Maarten to unify all the various atomic paths into just one atomic update function for fbdev overall. On top do one s/restore_fbdev_mode/restore_fbdev_mode_atomic/ so that we have all-atomic callchains after the first check. Cc: Peter Rosin <peda@axentia.se> Cc: John Stultz <john.stultz@linaro.org> Cc: Thierry Reding <treding@nvidia.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by:
Maarten Lankhorst <maarten.lankhorst@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170704151833.17304-10-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
Those are now all protected using fb_helper->lock. v2: We still need to hold mode_config.mutex right around calling connector->fill_modes. v3: I forgot to hold mode_config.mutex while looking at connector->status and the mode list. Also, we need to patch up the i915 ->initial_config callback to grab the locks it needs to inspect the modeset state recovered from the fw. v4: Don't reorder the probe too much (Ville). Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: John Stultz <john.stultz@linaro.org> Cc: Thierry Reding <treding@nvidia.com> Reviewed-by:
-
Daniel Vetter authored
Same game as with the panning function, use drm_modeset_lock_all for legacy paths, and a proper acquire ctx w/w mutex dance for atomic. Cc: John Stultz <john.stultz@linaro.org> Cc: Thierry Reding <treding@nvidia.com> Reviewed-by:
-
Daniel Vetter authored
For the legacy path we'll keep drm_modeset_lock_all, for the atomic one we drop the use of the magic implicit context and wire it up properly. Cc: John Stultz <john.stultz@linaro.org> Cc: Thierry Reding <treding@nvidia.com> Reviewed-by:
-
