- 12 Aug, 2016 7 commits
-
-
Sumit Semwal authored
Commit 0431b906 ("staging/android: bring struct sync_pt back") removed child_list and active_list from struct fence, but left it in kernel doc. Delete them. Fixes: 0431b906 ("staging/android: bring struct sync_pt back") Signed-off-by:
Sumit Semwal <sumit.semwal@linaro.org> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1470912480-32304-2-git-send-email-sumit.semwal@linaro.org
-
Peter Chen authored
This reverts commit 2ab9f587 Author: Peter Chen <peter.chen@nxp.com> Date: Fri Jul 15 11:17:03 2016 +0800 gpu: drm: omapdrm: dss-of: add missing of_node_put after calling of_parse_phandle The of_get_next_parent will drop refcount on the passed node, so the reverted patch is wrong, thanks for Tomi Valkeinen points it. Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by:
Peter Chen <peter.chen@nxp.com> Acked-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by:
Sean Paul <seanpaul@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/1470908694-16362-1-git-send-email-peter.chen@nxp.com
-
Daniel Vetter authored
For reasons that entirely elude me fb.h exposes all the structures, even when it is not enabled. Except for special stuff like fb_defio. Which means all the drivers which haven't yet switched over to the defio support in the helpers and still roll their own, will fail to compile when fbdev emulation is disabled. Protect just those bits, as a gnarly reminder that conversion to the core defio helpers would be good. Cc: Dave Airlie <airlied@redhat.com> Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Daniel Vetter authored
Seems to at least compile fine, only change needed was to use the fb_set_suspend helper. Cc: alexander.deucher@amd.com Reviewed-by:
-
Daniel Vetter authored
vmwgfx doesn't actually build without that. It would be great if vmwgfx could switch over to the fbdev emulation helpers, since those will take care of all this already. I guess one reason to not do that was lack of defio support in the helpers, but that's fixed now. If there's any other hold-up, we should figure out what it is and whether it makes sense to address it. Cc: Sinclair Yeh <syeh@vmware.com> Cc: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by:
Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1470847958-28465-4-git-send-email-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
Everyone who uses the fbdev emulation helpers doesn't need to include fb.h directly. Remove it. Reviewed-by:
-
Daniel Vetter authored
Lots of drivers don't properly compile without this when CONFIG_FB=n. It's kinda a hack, but since CONFIG_FB doesn't stub any fucntions when it's disabled I think it makes sense to add it to drm_fb_helper.h. Long term we probably need to rethink all the logic to unload firmware framebuffer drivers, at least if we want to be able to move away from CONFIG_FB and fbcon. v2: Unfortunately just stubbing out remove_conflicting_framebuffers in drm_fb_helper.h upset gcc about static vs. non-static declarations, so a new wrapper it needs to be. Means more churn :( Cc: Tobias Jakobi <tjakobi@math.uni-bielefeld.de> Cc: Noralf Trønnes <noralf@tronnes.org> Cc: tomi.valkeinen@ti.com Cc: dh.herrmann@gmail.com Reviewed-by:
-
- 11 Aug, 2016 5 commits
-
-
Gustavo Padovan authored
Signalling doesn't need to be enabled at sync_file creation, it is only required if userspace waiting the fence to signal through poll(). Thus we delay fence_add_callback() until poll is called. It only adds the callback the first time poll() is called. This avoid re-adding the same callback multiple times. v2: rebase and update to work with new fence support for sync_file v3: use atomic operation to set enabled and protect fence_add_callback() v4: use user bit from fence flags (comment from Chris Wilson) v5: use ternary if on poll return (comment from Chris Wilson) Signed-off-by:
Gustavo Padovan <gustavo.padovan@collabora.co.uk> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Gustavo Padovan authored
Document the new function added to sync_file.c v2: Adapt to fence_array v3: Take in Chris Wilson suggestions Signed-off-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
-
Gustavo Padovan authored
Creates a function that given an sync file descriptor returns a fence containing all fences in the sync_file. v2: Comments by Daniel Vetter - Adapt to new version of fence_collection_init() - Hold a reference for the fence we return v3: - Adapt to use fput() directly - rename to sync_file_get_fence() as we always return one fence v4: Adapt to use fence_array v5: set fence through fence_get() Signed-off-by:
-
Gustavo Padovan authored
Create sync_file->fence to abstract the type of fence we are using for each sync_file. If only one fence is present we use a normal struct fence but if there is more fences to be added to the sync_file a fence_array is created. This change cleans up sync_file a bit. We don't need to have sync_file_cb array anymore. Instead, as we always have one fence, only one fence callback is registered per sync_file. v2: Comments from Chris Wilson and Christian König - Not using fence_ops anymore - fence_is_array() was created to differentiate fence from fence_array - fence_array_teardown() is now exported and used under fence_is_array() - struct sync_file lost num_fences member v3: Comments from Chris Wilson and Christian König - struct sync_file lost status member in favor of fence_is_signaled() - drop use of fence_array_teardown() - use sizeof(*fence) to allocate only an array on fence pointers v4: Comments from Chris Wilson - use sizeof(*fence) to reallocate array - fix typo in comments - protect num_fences sum against overflows - use array->base instead of casting the to struct fence v5: fixes checkpatch warnings v6: fix case where all fences are signaled. Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Gustavo Padovan authored
Add helper to check if fence is array. v2: Comments from Chris Wilson - remove ternary if from ops comparison - add EXPORT_SYMBOL(fence_array_ops) Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Christian König <christian.koenig@amd.com> Signed-off-by:
-
- 09 Aug, 2016 3 commits
-
-
Lyude authored
Timeouts can be errors, but timeouts are also usually normal behavior and happen a lot. Since the kernel already lets us know when we're suppressing messages due to rate limiting, rate limit timeout errors so we don't make too much noise in the kernel log. Signed-off-by:
Lyude <cpaul@redhat.com> Reviewed-by:
-
Lyude authored
Since we always retry in drm_dp_dpcd_access() regardless of the error, we're going to make a lot of noise if the aux->transfer function prints it's own errors (as is the case with radeon). If we can print the error code here, this reduces the need for drivers to do this. So instead of having to print "dp_aux_ch timed out" over 32 times we can just print once. Signed-off-by:
-
Lyude authored
There's a couple of places where this would be useful for drivers (such as reporting DP aux transaction timeouts). Signed-off-by:
-
- 08 Aug, 2016 25 commits
-
-
Daniel Vetter authored
Shouldn't be possible since everyone kzallocs this, but better safe than sorry. Random drive-by-idea really. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
Rodrigo Vivi <rdorigo.vivi@intel.com> Signed-off-by:
-
Bibby Hsieh authored
To properly implement atomic w/ runtime pm, we move drm_atomic_helper_commit_modeset_enables() above drm_atomic_helper_commit_planes() to ensure CRTCs are enabled before modifying plane registers, and set active_only to true to filter out plane update notifications when the CRTC is disabled. According to the document from linux kernel: Set the active_only parameters to true in order not to receive plane update notifications related to a disabled CRTC. This avoids the need to manually ignore plane updates in driver code when the driver and/or hardware can't or just don't need to deal with updates on disabled CRTCs, for example when supporting runtime PM. Signed-off-by:
Bibby Hsieh <bibby.hsieh@mediatek.com> Signed-off-by:
Daniel Kurtz <djkurtz@chromium.org> Signed-off-by:
-
Daniel Kurtz authored
Use the framebuffer's format to compute its cpp, and use it when calculating the address shift value. Signed-off-by:
-
Daniel Kurtz authored
The mtk_plane_enable is just called once by mtk_plane_atomic_update. So, merge mtk_plane_enable into mtk_plane_atomic_update. While we are here, also clean up the function a bit by using an fb local variables. Signed-off-by:
-
Bibby Hsieh authored
Use the core destroy_state helpers to destroy core state to ensure we don't leak if/when more fields get added later. Signed-off-by:
-
Daniel Kurtz authored
Now that mtk_drm_plane just contains its base struct drm_plane, we can just remove it and use struct drm_plane everywhere. Signed-off-by:
-
Daniel Kurtz authored
It is not actually useful to a mtk plane to know its zpos/index, so just remove this field. This let's completely remove struct mtk_drm_plane in a follow up patch. Signed-off-by:
-
Daniel Kurtz authored
This function no longer exists. Signed-off-by:
-
Ville Syrjälä authored
Replace the use of drm_plane_helper_check_update() with drm_plane_helper_check_state() since we have a plane state. I don't see any actual users of drm_simple_kms_helper yet, so no actual plane clipping bugs to fix. Cc: Noralf Trønnes <noralf@tronnes.org> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Ville Syrjälä authored
Replace the use of drm_plane_helper_check_update() with drm_plane_helper_check_state() since we have a plane state. This also eliminates the double clipping the driver was doing in both check and commit phases). And it should fix src coordinate addr adjustement. Previously the driver was expecting negative dst coordinates after clipping, which is not going happen, so any clipping induced addr adjustment simply didn't happen. Neither did the driver respect any user configured src coordinates, so panning and such would have been totally broken. It should be all good now. Cc: CK Hu <ck.hu@mediatek.com> Cc: linux-mediatek@lists.infradead.org Signed-off-by:
CK Hu <ck.hu@mediatek.com> Signed-off-by:
-
Ville Syrjälä authored
Replace the use of drm_plane_helper_check_update() with drm_plane_helper_check_state() since we have a plane state. Rockchip looks to handling plane clipping rather well already (unlikje most arm drm drivers) so there are no function changes here. Cc: Yao <mark.yao@rock-chips.com> Cc: linux-rockchip@lists.infradead.org Signed-off-by:
Mark Yao <mark.yao@rock-chips.com> Signed-off-by:
-
Ville Syrjälä authored
Replace the private drm_rects in vop_plane_state with the ones now living in drm_plane_state. Cc: Yao <mark.yao@rock-chips.com> Cc: linux-rockchip@lists.infradead.org Signed-off-by:
-
Ville Syrjälä authored
Replace the use of drm_plane_helper_check_update() with drm_plane_helper_check_state() since we have a plane state. Signed-off-by:
-
Ville Syrjälä authored
Replace the private drm_rects/flags in intel_plane_state with the ones now living in drm_plane_state. Signed-off-by:
-
Ville Syrjälä authored
Add a version of drm_plane_helper_check_update() which takes a plane state instead of having the caller pass in everything. And to reduce code duplication, let's reimplement drm_plane_helper_check_update() in terms of the new function, by having a tempororary plane state on the stack. v2: Add a note that the functions modifies the state (Chris) v3: Fix drm_plane_helper_check_update() y coordinates (Daniel Kurtz) Cc: Daniel Kurtz <djkurtz@chromium.org> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Ville Syrjälä authored
Pretty much all driver will have need for the clipped plane coordinates, so let's stuff then into drm_plane_state. Signed-off-by:
-
Ville Syrjälä authored
Passing negative width/hight to scale factor calculations is not legal. Let's WARN if that happens. Signed-off-by:
-
Joonas Lahtinen authored
Only property creation uses the rotation as an index, so convert the to figure the index when needed. v2: Use the new defines to build the _MASK defines (Sean) Cc: intel-gfx@lists.freedesktop.org Cc: linux-arm-msm@vger.kernel.org Cc: freedreno@lists.freedesktop.org Cc: malidp@foss.arm.com Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Liviu Dudau <Liviu.Dudau@arm.com> Cc: Sean Paul <seanpaul@chromium.org> Acked-by:
Liviu Dudau <Liviu.Dudau@arm.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v1) Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by:
-
Keith Packard authored
When reconfiguring a plane position (as in moving the cursor), the frame buffer for the cursor isn't changing, so don't call the prepare or cleanup driver functions. This avoids making cursor position updates block on all pending rendering. v3: use drm_atomic_helper_framebuffer_changed in both prepare and cleanup phases instead of keeping state in the plane. cc: dri-devel@lists.freedesktop.org cc: David Airlie <airlied@linux.ie> cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by:Keith Packard <keithp@keithp.com> [danvet: Rebase onto 4.8] Signed-off-by:
-
Daniel Vetter authored
Except for nouveau, only legacy drivers need this really. And nouveau is already marked up with DRIVER_KMS_LEGACY_CONTEXT as the special case. I've tried to be careful to leave everything related to modeset still using the DRIVER_MODESET flag. Otherwise it's a direct replacement of !DRIVER_MODESET with DRIVER_LEGACY checks. Also helps readability since fewer negative checks overall. Reviewed-by:
David Herrmann <dh.herrmann@gmail.com> Reviewed-by:
Frank Binns <frank.binns@imgtec.com> Signed-off-by:
-
Daniel Vetter authored
It's super confusing that new drivers need to be marked with DRIVER_MODESET when really it means DRIVER_MODERN. Much better to invert the meaning and rename it to something that's suitably off-putting. Since there's over 100 places using DRIVER_MODESET we need to roll out this change without a flag day. v2: Update docs. Reviewed-by:
-
Chris Wilson authored
At a higher level, all objects are created with definite size i.e. 0 is illegal. In forthcoming patches, this assumption is dependent upon in the drm_mm range manager, i.e. trying to create a drm_mm node with size 0 will have undefined behaviour. Add a couple of WARNs upon creating the drm_mm node to prevent later bugs. Signed-off-by:
-
David Herrmann authored
The minor referred to by "DRM_MINOR_LEGACY" is called 'dev->primary' and gets 'cardX' as name assigned. Lets reduce this magnificent number of names for the same concept by one and rename DRM_MINOR_LEGACY to DRM_MINOR_PRIMARY (to match the actual struct-member name). Furthermore, this is in no way a legacy node, so lets not call it that. Signed-off-by:
-
Chris Wilson authored
As we always add this to the drm_mm->hole_stack as our first operation, we do not need to initialise the list node. Signed-off-by:
-
Chris Wilson authored
Having added an interval-tree to struct drm_mm, we can replace the auxiliary rb-tree inside the drm_vma_manager with it. Signed-off-by:
-
