- Mar 28, 2018
-
-
Jani Nikula authored
Remove last users of __inline__. 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-1-jani.nikula@intel.com
-
- Oct 25, 2017
-
-
Keith Packard authored
Separate out lease debugging from the core. Signed-off-by:
Keith Packard <keithp@keithp.com> Signed-off-by:
Dave Airlie <airlied@redhat.com>
-
- Oct 20, 2017
-
-
Haneen Mohammed authored
This patch extract DRM_* debug macros from drmP.h to drm_print.h and move printing related functions used by these macros from drm_drv.[hc] to drm_print.[hc]. Signed-off-by:
Haneen Mohammed <hamohammed.sa@gmail.com> Signed-off-by:
Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/4020bc7c5ffad2af516919f78bb837c7f366b82b.1508297716.git.hamohammed.sa@gmail.com
-
- Aug 11, 2017
-
-
Daniel Vetter authored
While at it, also ocd and give them a consistent drm_dev_ prefix, like the other device instance functionality. Plus move the functions into the right places. Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170802115604.12734-3-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
I need this to untangle an include loop in the next patch. Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20170802115604.12734-2-daniel.vetter@ffwll.ch
-
- Jun 20, 2017
-
-
Daniel Vetter authored
Unify and review everything, plus make sure it's all correct markup. Drop the kernel-doc for internal functions. Also rework the overview section, it's become rather outdated. Unfortuantely the kernel-doc in drm_driver isn't rendered yet, but that will change as soon as drm_driver is kernel-docified properly. Also document properly that drm_vblank_cleanup is optional, the core calls this already. v2: Make it clear that cleanup happens in drm_dev_fini for drivers with their own ->release callback (Thierry). Acked-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
-
- Jun 01, 2017
-
-
Daniel Vetter authored
Pull a (much shorter) overview into drm_irq.c, and instead put the callback documentation into in-line comments in drm_drv.h. v2: Move the include stanzas back to the split-up patch (Stefan). Cc: Stefan Agner <stefan@agner.ch> Reviewed-by:
Stefan Agner <stefan@agner.ch> Signed-off-by:
-
Daniel Vetter authored
drm_irq.c contains both the irq helper library (optional) and the vblank support (optional, but part of the modeset uapi, and doesn't require the use of the irq helpers at all. Split this up for more clarity of the scope of the individual bits. v2: Move misplaced hunks to this patch (Stefan). Cc: Stefan Agner <stefan@agner.ch> Reviewed-by:
-
- May 31, 2017
-
-
Daniel Vetter authored
And document them lightly. Unfortunately kernel-doc isn't the most awesome for documenting #defines that don't look like functions, it makes functions out of them :-/ Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170524145212.27837-2-daniel.vetter@ffwll.ch Link: http://patchwork.freedesktop.org/patch/msgid/20170524145212.27837-3-daniel.vetter@ffwll.ch
-
- May 29, 2017
-
-
Daniel Vetter authored
This is a leftover from the drm_bus days, where we've had a bus-specific device type for every bus type in drm_device. Except for pci (which we can't remove because dri1 drivers) this is all gone. And the virt driver also doesn't really need it, dev_to_virtio works perfectly fine. Cc: David Airlie <airlied@linux.ie> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: virtualization@lists.linux-foundation.org Reviewed-by:
Gerd Hoffmann <kraxel@redhat.com> Signed-off-by:
-
- May 18, 2017
-
-
Michal Hocko authored
Now that drm_[cm]alloc* helpers are simple one line wrappers around kvmalloc_array and drm_free_large is just kvfree alias we can drop them and replace by their native forms. This shouldn't introduce any functional change. Changes since v1 - fix typo in drivers/gpu//drm/etnaviv/etnaviv_gem.c - noticed by 0day build robot Suggested-by:
Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Michal Hocko <mhocko@suse.com>drm: drop drm_[cm]alloc* helpers [danvet: Fixup vgem which grew another user very recently.] Signed-off-by:
Christian König <christian.koenig@amd.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170517122312.GK18247@dhcp22.suse.cz
-
- May 10, 2017
-
-
Daniel Vetter authored
If we restrict this helper to only kms drivers (which is the case) we can look up the correct mode easily ourselves. But it's a bit tricky: - All legacy drivers look at crtc->hwmode. But that is updated already at the beginning of the modeset helper, which means when we disable a pipe. Hence the final timestamps might be a bit off. But since this is an existing bug I'm not going to change it, but just try to be bug-for-bug compatible with the current code. This only applies to radeon&amdgpu. - i915 tries to get it perfect by updating crtc->hwmode when the pipe is off (i.e. vblank->enabled = false). - All other atomic drivers look at crtc->state->adjusted_mode. Those that look at state->requested_mode simply don't adjust their mode, so it's the same. That has two problems: Accessing crtc->state from interrupt handling code is unsafe, and it's updated before we shut down the pipe. For nonblocking modesets it's even worse. For atomic drivers try to implement what i915 does. To do that we add a new hwmode field to the vblank structure, and update it from drm_calc_timestamping_constants(). For atomic drivers that's called from the right spot by the helper library already, so all fine. But for safety let's enforce that. For legacy driver this function is only called at the end (oh the fun), which is broken, so again let's not bother and just stay bug-for-bug compatible. The benefit is that we can use drm_calc_vbltimestamp_from_scanoutpos directly to implement ->get_vblank_timestamp in every driver, deleting a lot of code. v2: Completely new approach, trying to mimick the i915 solution. v3: Fixup kerneldoc. v4: Drop the WARN_ON to check that the vblank is off, atomic helpers currently unconditionally call this. Recomputing the same stuff should be harmless. v5: Fix typos and move misplaced hunks to the right patches (Neil). v6: Undo hunk movement (kbuild). Cc: Mario Kleiner <mario.kleiner@tuebingen.mpg.de> Cc: Eric Anholt <eric@anholt.net> Cc: Rob Clark <robdclark@gmail.com> Cc: linux-arm-msm@vger.kernel.org Cc: freedreno@lists.freedesktop.org Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Ben Skeggs <bskeggs@redhat.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Daniel Vetter authored
There's really no reason for anything more: - Calling this while the crtc vblank stuff isn't set up is a driver bug. Those places alrready DRM_ERROR. - Calling this when the crtc is off is either a driver bug (calling drm_crtc_handle_vblank at the wrong time) or a core bug (for anything else). Again, we DRM_ERROR. - EINVAL is checked at higher levels already, and if we'd use struct drm_crtc * instead of (dev, pipe) it would be real obvious that those are again core bugs. The only valid failure mode is crap hardware that couldn't sample a useful timestamp, to ask the core to just grab a not-so-accurate timestamp. Bool is perfectly fine for that. v2: Also fix up the one caller, I lost that in the shuffling (Jani). v3: Fixup commit message (Neil). Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Mario Kleiner <mario.kleiner@tuebingen.mpg.de> Cc: Eric Anholt <eric@anholt.net> Cc: Rob Clark <robdclark@gmail.com> Cc: linux-arm-msm@vger.kernel.org Cc: freedreno@lists.freedesktop.org Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Ben Skeggs <bskeggs@redhat.com> Reviewed-by:
-
- Apr 04, 2017
-
-
Daniel Vetter authored
- remove docs for internal func, doesn't add value - add short overview snippet instead explaining that drivers don't have to bother themselves with reg/unreg concerns - drop the ttm comment about drmP.h, drmP.h is disappearing ... Reviewed-by:
-
- Mar 25, 2017
-
-
Daniel Vetter authored
The core code doesn't care at all about this, it's entirely dead. Cc: Mario Kleiner <mario.kleiner@tuebingen.mpg.de> Reviewed-by:
-
Daniel Vetter authored
To match the drm_ioctl.c we already have. v2: Remove spurious space (Ville). Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
- Mar 24, 2017
-
-
Daniel Vetter authored
Doc polish will follow in the next patch. v2: Put the include guard #endif at the end (Ville). Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
- Mar 09, 2017
-
-
Daniel Vetter authored
I'm torn on whether drm_minor really should be here or somewhere else. Maybe with more clarity after untangling drmP.h more this is easier to decide, for now I've put a FIXME comment right next to it. Right now we need struct drm_minor for the inline drm_file type helpers, and so it does kinda make sense to have them here. Next patch will kerneldoc-ify the entire pile. Reviewed-by:
Gustavo Padovan <gustavo.padovan@collabora.com> Signed-off-by:
-
Daniel Vetter authored
This was originally added by David Herrmann for range checks, but entirely unused. It confused me, so let's remove it. Cc: David Herrmann <dh.herrmann@gmail.com> Reviewed-by:
David Herrmann <dh.herrmann@gmail.com> Signed-off-by:
-
Daniel Vetter authored
It's not just file ops, but drm_file stuff in general. This is prep work to extracting a drm_file.h header in the next patch. Reviewed-by:
-
Daniel Vetter authored
Just another step in finally making drmP.h obsolete. Reviewed-by:
-
Daniel Vetter authored
And remove the semi-kernel-doc stuff, to make sure no one uses this. Reviewed-by:
-
Daniel Vetter authored
Plus a little bit more documentation. v2: Untangle the missing forward decls to make drm_prime|gem.h free-standing. Reviewed-by:
-
- Feb 17, 2017
-
-
Laurent Pinchart authored
The field contains a pointer to the parent platform device of the DRM device. As struct drm_device also contains a dev pointer to the struct device embedded in the platform_device structure, the platformdev field is redundant. Remove it and use the dev pointer directly. Signed-off-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by:
Jyri Sarha <jsarha@ti.com> Acked-by: Vincent Abriou <vincent.abriou@st.com> # For sti Acked-by: Russell King <rmk+kernel@armlinux.org.uk> # For armada Acked-by: Rob Clark <robdclark@gmail.com> # For msm Acked-by:
Xinwei <Kong<kong.kongxinwei@hisilicon.com>
-
Laurent Pinchart authored
Now that the last driver has been converted, the drm_platform midlayer is unused. Remove it. Signed-off-by:
-
- Jan 30, 2017
-
-
Daniel Vetter authored
I was under the misconception that the sysfs dev stuff can be fully set up, and then registered all in one step with device_add. That's true for properties and property groups, but not for parents and child devices. Those must be fully registered before you can register a child. Add a bit of tracking to make sure that asynchronous mst connector hotplugging gets this right. For consistency we rely upon the implicit barriers of the connector->mutex, which is taken anyway, to ensure that at least either the connector or device registration call will work out. Mildly tested since I can't reliably reproduce this on my mst box here. Reported-by:
Dave Hansen <dave.hansen@intel.com> Cc: Dave Hansen <dave.hansen@intel.com> Acked-by:
-
- Jan 26, 2017
-
-
Daniel Vetter authored
With that the drm_pci_device_is_agp function becomes trivial, so inline that too. And while at it, move the drm_pci_agp_destroy declaration into drm-internal.h, since it's not used by drivers. Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Ben Skeggs <bskeggs@redhat.com> Reviewed-by:
-
- Jan 10, 2017
-
-
Gabriel Krisman Bertazi authored
Continue to clean up drmP.h by moving the cache flushing functions into it's own header file. Compile-tested only Signed-off-by:
Gabriel Krisman Bertazi <krisman@collabora.co.uk> Reviewed-by:
-
- Jan 04, 2017
-
-
Daniel Vetter authored
When writing the generic nonblocking commit code I assumed that through clever lifetime management I can assure that the completion (stored in drm_crtc_commit) only gets freed after it is completed. And that worked. I also wanted to make nonblocking helpers resilient against driver bugs, by having timeouts everywhere. And that worked too. Unfortunately taking boths things together results in oopses :( Well, at least sometimes: What seems to happen is that the drm event hangs around forever stuck in limbo land. The nonblocking helpers eventually time out, move on and release it. Now the bug I tested all this against is drivers that just entirely fail to deliver the vblank events like they should, and in those cases the event is simply leaked. But what seems to happen, at least sometimes, on i915 is that the event is set up correctly, but somohow the vblank fails to fire in time. Which means the event isn't leaked, it's still there waiting for eventually a vblank to fire. That tends to happen when re-enabling the pipe, and then the trap springs and the kernel oopses. The correct fix here is simply to refcount the crtc commit to make sure that the event sticks around even for drivers which only sometimes fail to deliver vblanks for some arbitrary reasons. Since crtc commits are already refcounted that's easy to do. References: https://bugs.freedesktop.org/show_bug.cgi?id=96781 Cc: Jim Rees <rees@umich.edu> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
-
- Dec 27, 2016
-
-
Dhinakaran Pandiyan authored
This check is useful for drivers that do not have DRIVER_ATOMIC set but have atomic modesetting internally implemented. Wrap the check into a function since this is used in many places and as a bonus, the function name helps to document what the check is for. v2: Change return type to bool (Ville) Move the function drm_atomic.h (Daniel) Fixed comment marker for documentation Suggested-by:
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> [danvet: Move back to drmP.h because include hell.] Signed-off-by:
-
- Dec 24, 2016
-
-
Linus Torvalds authored
This was entirely automated, using the script by Al: PATT='^[[:blank:]]*#[[:blank:]]*include[[:blank:]]*<asm/uaccess.h>' sed -i -e "s!$PATT!#include <linux/uaccess.h>!" \ $(git grep -l "$PATT"|grep -v ^include/linux/uaccess.h) to do the replacement at the end of the merge window. Requested-by:Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
- Nov 15, 2016
-
-
Daniel Vetter authored
Now that all drivers are switched over to drm_crtc_vblank_on/off we can relegate pre/post_modeset to the purely drm_irq.c internal role of supporting old ums userspace. As usual switch to the drm_legacy_ prefix to make it clear this is for old drivers only. v2: Rebase on top of Thierry's s/int crtc/unsigned int pipe/ changes. Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Alex Deucher <alexander.deucher@amd.com> Reviewed-by:
-
Daniel Vetter authored
I want to move dumb buffer documentation into the right vfuncs, and for that I first need to be able to pull that into kerneldoc without having to clean up all of drmP.h. Also, header-splitting is nice. While at it shuffle all the function declarations for drm_drv.c into the right spots, and drop the kerneldoc for drm_minor_acquire/release since it's only used internally. v2: Keep all existing copyright notices (Chris). Reviewed-by:
-
Gerd Hoffmann authored
We still need it, for virtio-gpu for example. Partial revert of commit a742946a. Signed-off-by:
-
- Nov 08, 2016
-
-
Rob Clark authored
The contents of drm_{plane,crtc,connector}_state is dumped before commit. If a driver extends any of the state structs, it can implement the corresponding funcs->atomic_print_state() to add it's own driver specific state. Signed-off-by:Rob Clark <robdclark@gmail.com> [seanpaul resolved conflict in drm_plane.h] Signed-off-by:
-
Rob Clark authored
I'll want to print things in a similar way in a later patch. This will make it easier. Signed-off-by:
-
- Nov 02, 2016
-
-
Jani Nikula authored
If we define drm_compat_ioctl NULL on CONFIG_COMPAT=n, we don't have to check for the config everywhere. Reviewed-by:
Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Signed-off-by:
-
- Oct 25, 2016
-
-
Chris Wilson authored
I plan to usurp the short name of struct fence for a core kernel struct, and so I need to rename the specialised fence/timeline for DMA operations to make room. A consensus was reached in https://lists.freedesktop.org/archives/dri-devel/2016-July/113083.html that making clear this fence applies to DMA operations was a good thing. Since then the patch has grown a bit as usage increases, so hopefully it remains a good thing! (v2...: rebase, rerun spatch) v3: Compile on msm, spotted a manual fixup that I broke. v4: Try again for msm, sorry Daniel coccinelle script: @@ @@ - struct fence + struct dma_fence @@ @@ - struct fence_ops + struct dma_fence_ops @@ @@ - struct fence_cb + struct dma_fence_cb @@ @@ - struct fence_array + struct dma_fence_array @@ @@ - enum fence_flag_bits + enum dma_fence_flag_bits @@ @@ ( - fence_init + dma_fence_init | - fence_release + dma_fence_release | - fence_free + dma_fence_free | - fence_get + dma_fence_get | - fence_get_rcu + dma_fence_get_rcu | - fence_put + dma_fence_put | - fence_signal + dma_fence_signal | - fence_signal_locked + dma_fence_signal_locked | - fence_default_wait + dma_fence_default_wait | - fence_add_callback + dma_fence_add_callback | - fence_remove_callback + dma_fence_remove_callback | - fence_enable_sw_signaling + dma_fence_enable_sw_signaling | - fence_is_signaled_locked + dma_fence_is_signaled_locked | - fence_is_signaled + dma_fence_is_signaled | - fence_is_later + dma_fence_is_later | - fence_later + dma_fence_later | - fence_wait_timeout + dma_fence_wait_timeout | - fence_wait_any_timeout + dma_fence_wait_any_timeout | - fence_wait + dma_fence_wait | - fence_context_alloc + dma_fence_context_alloc | - fence_array_create + dma_fence_array_create | - to_fence_array + to_dma_fence_array | - fence_is_array + dma_fence_is_array | - trace_fence_emit + trace_dma_fence_emit | - FENCE_TRACE + DMA_FENCE_TRACE | - FENCE_WARN + DMA_FENCE_WARN | - FENCE_ERR + DMA_FENCE_ERR ) ( ... ) Signed-off-by:
Gustavo Padovan <gustavo.padovan@collabora.co.uk> Acked-by:
Sumit Semwal <sumit.semwal@linaro.org> Acked-by:
-
- Oct 05, 2016
-
-
Chris Wilson authored
dma_buf may live a long time, longer than the last direct user of the driver. We already hold a reference to the owner module (that prevents the object code from disappearing), but there is no reference to the drm_dev - so the pointers to the driver backend themselves may vanish. v2: Resist temptation to fix the bug in armada_gem.c not setting the correct flags on the exported dma-buf (it should pass the flags through and not be arbitrarily setting O_RDWR). Use a common wrapper for exporting the dmabuf and acquiring the reference to the drm_device. Testcase: igt/vgem_basic/unload Suggested-by:
Petri Latvala <petri.latvala@intel.com> Reviewed-by:
-
Chris Wilson authored
dma_buf_export() adds a reference to the owning module to the dmabuf (to prevent the driver from being unloaded whilst a third party still refers to the dmabuf). However, drm_gem_prime_export() was passing its own THIS_MODULE (i.e. drm.ko) rather than the driver. Extract the right owner from the device->fops instead. v2: Use C99 initializers to zero out unset elements of dma_buf_export_info v3: Extract the right module from dev->fops. Testcase: igt/vgem_basic/unload Reported-by:
-
