- 03 Jun, 2016 3 commits
-
-
Daniel Vetter authored
kernel-doc is unhappy, appease it. Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Acked-by:
Liviu Dudau <Liviu.Dudau@arm.com> Acked-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1464729075-22243-2-git-send-email-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
Apparently not everyone has been super dutiful with updating this stuff. I still decided to leave out the documentation for all the *_property pointers we have in drm_mode_config. v2: Feedback from Liviu. Acked-by:
-
Gustavo Padovan authored
Christian König changed fence context to a u64 type, so we need to update all users accordingly. Signed-off-by:
Gustavo Padovan <gustavo.padovan@collabora.co.uk> Acked-by:
Sumit Semwal <sumit.semwal@linaro.org> Signed-off-by:
-
- 02 Jun, 2016 22 commits
-
-
Chris Wilson authored
Currently the plane's index is determined by walking the list of all planes in the mode and finding the position of that plane in the list. A linear walk, especially a linear walk within a linear walk as frequently conceived by i915.ko [O(N^2)] quickly comes to dominate profiles. The plane's index is constant for as long as no earlier planes are removed from the list. For all drivers, planes are static, determined at boot and then untouched until shutdown. In fact, there is no locking provided to allow for dynamic removal of planes/encoders/crtcs. v2: Convert drm_crtc_index() and drm_encoder_index() as well. v3: Stop adjusting the indices upon removal; consider the list construct-only. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> [danvet: Fixup typo in kerneldoc that Matt spotted.] Signed-off-by:
-
Gustavo Padovan authored
Now a drm_pending_event can either send a real drm_event or signal a fence, or both. It allow us to signal via fences when the buffer is displayed on the screen. Which in turn means that the previous buffer is not in use anymore and can be freed or sent back to another driver for processing. v2: Comments from Daniel Vetter - call fence_signal in drm_send_event_locked() - remove unneeded !e->event check v3: Remove drm_pending_event->destroy to fix a leak when e->file_priv is not set. Reviewed-by:
Sean Paul <seanpaul@chromium.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> (v2) [danvet: fix one e->destroy in arcpgu due to rebasing.] Signed-off-by:
-
Daniel Vetter authored
Eric nicely pointed these out, but I failed at git add and lost them. This fixes up commit 2f196b7c Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Jun 2 16:21:44 2016 +0200 drm/atomic: Add drm_atomic_crtc_state_for_each_plane_state to actually do what it says on the tin^Wcommit message. Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com>
-
Daniel Vetter authored
It's silly to have 2 mallocs when we could tie these two together. Also, Gustavo adds another one in his per-crtc out-fence patches. And I want to add more stuff here for nonblocking commit helpers. In the future we can use this to store a pointer to the preceeding state, making an atomic update entirely free-standing. This will be needed to be able to queue them up with a depth > 1. Cc: Gustavo Padovan <gustavo@padovan.org> Reviewed-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
-
Daniel Vetter authored
It's kinda pointless to have 2 separate mallocs for these. And when we add more per-plane state in the future it's even more pointless. Right now there's no such thing planned, but both Gustavo's per-crtc fence patches, and some nonblocking commit helpers I'm playing around with will add more per-crtc stuff. It makes sense to also consolidate planes, just for consistency. In the future we can use this to store a pointer to the preceeding state, making an atomic update entirely free-standing. This will be needed to be able to queue them up with a depth > 1. Cc: Gustavo Padovan <gustavo@padovan.org> Reviewed-by:
-
Daniel Vetter authored
It's kinda pointless to have 2 separate mallocs for these. And when we add more per-connector state in the future it's even more pointless. Right now there's no such thing planned, but both Gustavo's per-crtc fence patches, and some nonblocking commit helpers I'm playing around with will add more per-crtc stuff. It makes sense to also consolidate connectors, just for consistency. In the future we can use this to store a pointer to the preceeding state, making an atomic update entirely free-standing. This will be needed to be able to queue them up with a depth > 1. Cc: Gustavo Padovan <gustavo@padovan.org> Reviewed-by:
-
Daniel Vetter authored
... and use it in msm&vc4. Again just want to encapsulate drm_atomic_state internals a bit. The const threading is a bit awkward in vc4 since C sucks, but I still think it's worth to enforce this. Eventually I want to make all the obj->state pointers const too, but that's a lot more work ... v2: Provide safe macro to wrap up the unsafe helper better, suggested by Maarten. v3: Fixup subject (Maarten) and spelling fixes (Eric Engestrom). Cc: Eric Anholt <eric@anholt.net> Cc: Rob Clark <robdclark@gmail.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Eric Engestrom <eric.engestrom@imgtec.com> Reviewed-by:
-
Daniel Vetter authored
Mostly this is unexpected indents. But really it's just a demonstration for my patch, all these issues have been found&fixed using the correct source file and line number support I just added. All line numbers have been perfectly accurate. One issue looked a bit fishy in intel_lrc.c, where I don't quite grok what sphinx is unhappy about. But since that file looks like it has never seen a proper kernel-doc parser I figured better to fix in a separate path. v2: Use fancy new &drm_device->struct_mutex linking (Jani). Cc: Jani Nikula <jani.nikula@intel.com> Cc: linux-doc@vger.kernel.org Cc: Jonathan Corbet <corbet@lwn.net> Acked-by:
-
Daniel Vetter authored
We want to hide drm_atomic_state internals better. v2: Use drm_crtc_mask (Maarten). Cc: Inki Dae <inki.dae@samsung.com> Acked-by:
Inki Dae <inki.dae@samsung.com> Reviewed-by:
-
Daniel Vetter authored
We want to hide drm_atomic_stat internals a bit better. v2: Use drm_crtc_mask (Maarten). Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by:
-
Daniel Vetter authored
We want to hide drm_atomic_stat internals a bit better. Cc: Eric Anholt <eric@anholt.net> Reviewed-by:
-
Daniel Vetter authored
We want to hide drm_atomic_state internals better. v2: Use drm_crtc_mask (Maarten). Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by:
-
Daniel Vetter authored
We want to hide drm_atomic_state internals v2: Review from Maarten: - remove whitespace change in rockchip driver that slipped in. - use drm_crtc_mask insted of open-coding it. Cc: Rob Clark <robdclark@gmail.com> Reviewed-by:
-
Daniel Vetter authored
We want to encapsulate the drm_atomic_state internals. v2: Use intel_atomic_get_existing_plane_state (Maarten). Reviewed-by:
-
Daniel Vetter authored
Those are all no longer needed for a pure atomic driver. Cc: Liviu Dudau <Liviu.Dudau@arm.com> Tested-by:
-
Daniel Vetter authored
This avois leaking drm_atomic_state internals into the helpers. The only place where this still happens after this patch is drm_atomic_helper_swap_state(). It's unavoidable there, and maybe a good indicator we should actually move that function into drm_atomic.c. Signed-off-by:
-
Chris Wilson authored
The intention of using video=<connector>:<mode> is primarily to select the user's preferred resolution at startup. Currently we always create a new mode irrespective of whether the monitor has a native mode at the desired resolution. This has the issue that we may then select the fake mode rather the native mode during fb_helper->inital_config() and so if the fake mode is invalid we then end up with a loss of signal. Oops. This invalid fake mode would also be exported to userspace, who potentially may make the same mistake. To avoid this issue, we filter out the added command line mode if we detect the desired resolution (and clock if specified) amongst the probed modes. This fixes the immediate problem of adding a duplicate mode, but perhaps more generically we should avoid adding a GTF mode if the monitor has an EDID that is not GTF-compatible, or similarly for CVT. Was meant to fix a regression from commit eaf99c74 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Wed Aug 6 10:08:32 2014 +0200 drm: Perform cmdline mode parsing during connector initialisation but Radek explained that the original bug is no longer reproducible on latest kernels. v2: Explicitly delete our earlier cmdline mode v3: Mode pruning should now be sufficient to delete stale cmdline modes v4: Compute the vrefresh for the probed mode Reported-by:
Radek Dostál <rd@radekdostal.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> [danvet: Drop cc: stable since no longer a pressing bugfix, just nice-to-have.] Signed-off-by:
-
Christian König authored
If @signal_on_any is true the fence array signals if any fence in the array signals, otherwise it signals when all fences in the array signal. v2: fix signaled test and add comment suggested by Chris Wilson. Signed-off-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
-
Gustavo Padovan authored
struct fence_array inherits from struct fence and carries a collection of fences that needs to be waited together. It is useful to translate a sync_file to a fence to remove the complexity of dealing with sync_files on DRM drivers. So even if there are many fences in the sync_file that needs to waited for a commit to happen, they all get added to the fence_collection and passed for DRM use as a standard struct fence. That means that no changes needed to any driver besides supporting fences. To avoid fence_array's fence allocates a new timeline if needed (when combining fences from different timelines). v2: Comments by Daniel Vetter: - merge fence_collection_init() and fence_collection_add() - only add callbacks at ->enable_signalling() - remove fence_collection_put() - check for type on to_fence_collection() - adjust fence_is_later() and fence_later() to WARN_ON() if they are used with collection fences. v3: - Initialize fence_cb.node at fence init. Comments by Chris Wilson: - return "unbound" on fence_collection_get_timeline_name() - don't stop adding callbacks if one fails - remove redundant !! on fence_collection_enable_signaling() - remove redundant () on fence_collection_signaled - use fence_default_wait() instead v4 (chk): Rework, simplification and cleanup: - Drop FENCE_NO_CONTEXT handling, always allocate a context. - Rename to fence_array. - Return fixed driver name. - Register only one callback at a time. - Document that create function takes ownership of array. v5 (chk): More work and fixes: - Avoid deadlocks by adding all callbacks at once again. - Stop trying to remove the callbacks. - Provide context and sequence number for the array fence. v6 (chk): Fixes found during testing - Fix stupid typo in _enable_signaling(). Signed-off-by: -
Christian König authored
Fence contexts are created on the fly (for example) by the GPU scheduler used in the amdgpu driver as a result of an userspace request. Because of this userspace could in theory force a wrap around of the 32bit context number if it doesn't behave well. Avoid this by increasing the context number to 64bits. This way even when userspace manages to allocate a billion contexts per second it takes more than 500 years for the context number to wrap around. v2: fix printf formats as well. Signed-off-by:
-
Liviu Dudau authored
Since commit 4dfd6486 ("drm: Use vblank timestamps to guesstimate how many vblanks were missed"), the DRM framework can cope with devices that don't have a hardware counter for vsync events without having to keep the vsync interrupts enabled all the time. Drivers handling such hardware should use drm_vblank_no_hw_counter() function for their ->get_vblank_counter hook. Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Boris Brezillon authored
Fallback drm_atomic_helper_best_encoder() is funcs->best_encoder() is NULL so that DRM drivers can leave this hook unassigned if they know they want to use drm_atomic_helper_best_encoder(). Signed-off-by:
Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by:
-
- 01 Jun, 2016 3 commits
-
-
git://anongit.freedesktop.org/drm-intelDave Airlie authored
drm-intel-next-2016-05-22: - cmd-parser support for direct reg->reg loads (Ken Graunke) - better handle DP++ smart dongles (Ville) - bxt guc fw loading support (Nick Hoathe) - remove a bunch of struct typedefs from dpll code (Ander) - tons of small work all over to avoid casting between drm_device and the i915 dev struct (Tvrtko&Chris) - untangle request retiring from other operations, also fixes reset stat corner cases (Chris) - skl atomic watermark support from Matt Roper, yay! - various wm handling bugfixes from Ville - big pile of cdclck rework for bxt/skl (Ville) - CABC (Content Adaptive Brigthness Control) for dsi panels (Jani&Deepak M) - nonblocking atomic commits for plane-only updates (Maarten Lankhorst) - bunch of PSR fixes&improvements - untangle our map/pin/sg_iter code a bit (Dave Gordon) drm-intel-next-2016-05-08: - refactor stolen quirks to share code between early quirks and i915 (Joonas) - refactor gem BO/vma funcstion (Tvrtko&Dave) - backlight over DPCD support (Yetunde Abedisi) - more dsi panel sequence support (Jani) - lots of refactoring around handling iomaps, vma, ring access and related topics culmulating in removing the duplicated request tracking in the execlist code (Chris & Tvrtko) includes a small patch for core iomapping code - hw state readout for bxt dsi (Ramalingam C) - cdclk cleanups (Ville) - dedupe chv pll code a bit (Ander) - enable semaphores on gen8+ for legacy submission, to be able to have a direct comparison against execlist on the same platform (Chris) Not meant to be used for anything else but performance tuning - lvds border bit hw state checker fix (Jani) - rpm vs. shrinker/oom-notifier fixes (Praveen Paneri) - l3 tuning (Imre) - revert mst dp audio, it's totally non-functional and crash-y (Lyude) - first official dmc for kbl (Rodrigo) - and tons of small things all over as usual * 'drm-intel-next' of git://anongit.freedesktop.org/drm-intel: (194 commits) drm/i915: Revert async unpin and nonblocking atomic commit drm/i915: Update DRIVER_DATE to 20160522 drm/i915: Inline sg_next() for the optimised SGL iterator drm/i915: Introduce & use new lightweight SGL iterators drm/i915: optimise i915_gem_object_map() for small objects drm/i915: refactor i915_gem_object_pin_map() drm/i915/psr: Implement PSR2 w/a for gen9 drm/i915/psr: Use ->get_aux_send_ctl functions drm/i915/psr: Order DP aux transactions correctly drm/i915/psr: Make idle_frames sensible again drm/i915/psr: Try to program link training times correctly drm/i915/userptr: Convert to drm_i915_private drm/i915: Allow nonblocking update of pageflips. drm/i915: Check for unpin correctness. Reapply "drm/i915: Avoid stalling on pending flips for legacy cursor updates" drm/i915: Make unpin async. drm/i915: Prepare connectors for nonblocking checks. drm/i915: Pass atomic states to fbc update functions. drm/i915: Remove reset_counter from intel_crtc. drm/i915: Remove queue_flip pointer. ...
-
git://anongit.freedesktop.org/drm-intelDave Airlie authored
Frist -misc pull for 4.8, with pretty much just random all over plus a few more lockless gem BO patches acked/reviewed by driver maintainers. I'm starting a bit earlier this time around because there's a few invasive patch series to land (nonblocking atomic prep work, fence prep work, rst/sphinx kerneldoc finally happening) and I need a baseline with all the branches merged. * tag 'topic/drm-misc-2016-06-01' of git://anongit.freedesktop.org/drm-intel: (21 commits) drm/vc4: Use lockless gem BO free callback drm/vc4: Use drm_gem_object_unreference_unlocked drm: Initialize a linear gamma table by default drm/vgem: Use lockless gem BO free callback drm/qxl: Don't set a gamma table size drm/msm: Nuke dummy gamma_set/get functions drm/cirrus: Drop redundnant gamma size check drm/fb-helper: Remove dead code in setcolreg drm/mediatek: Use lockless gem BO free callback drm/hisilicon: Use lockless gem BO free callback drm/hlcd: Use lockless gem BO free callback vga_switcheroo: Support deferred probing of audio clients vga_switcheroo: Add helper for deferred probing virtio-gpu: fix output lookup drm/doc: Unify KMS Locking docs drm/atomic-helper: Do not call ->mode_fixup for CRTC which will be disabled Fix annoyingly awkward typo in drm_edid_load.c drm/doc: Drop vblank_disable_allow wording drm: use seqlock for vblank time/count drm/mm: avoid possible null pointer dereference ...
-
Daniel Vetter authored
This reverts the following patches: d55dbd06 drm/i915: Allow nonblocking update of pageflips. 15c86bdb drm/i915: Check for unpin correctness. 95c2ccdc Reapply "drm/i915: Avoid stalling on pending flips for legacy cursor updates" a6747b73 drm/i915: Make unpin async. 03f476e1 drm/i915: Prepare connectors for nonblocking checks. 2099deff drm/i915: Pass atomic states to fbc update functions. ee7171af drm/i915: Remove reset_counter from intel_crtc. 2ee004f7 drm/i915: Remove queue_flip pointer. b8d2afae drm/i915: Remove use_mmio_flip kernel parameter. 8dd634d9 drm/i915: Remove cs based page flip support. 143f73b3 drm/i915: Rework intel_crtc_page_flip to be almost atomic, v3. 84fc494b drm/i915: Add the exclusive fence to plane_state. 6885843a drm/i915: Convert flip_work to a list. aa420ddd drm/i915: Allow mmio updates on all platforms, v2. afee4d87 Revert "drm/i915: Avoid stalling on pending flips for legacy cursor updates" "drm/i915: Allow nonblocking update of pageflips" should have been split up, misses a proper commit message and seems to cause issues in the legacy page_flip path as demonstrated by kms_flip. "drm/i915: Make unpin async" doesn't handle the unthrottled cursor updates correctly, leading to an apparent pin count leak. This is caught by the WARN_ON in i915_gem_object_do_pin which screams if we have more than DRM_I915_GEM_OBJECT_MAX_PIN_COUNT pins. Unfortuantely we can't just revert these two because this patch series came with a built-in bisect breakage in the form of temporarily removing the unthrottled cursor update hack for legacy cursor ioctl. Therefore there's no other option than to revert the entire pile :( There's one tiny conflict in intel_drv.h due to other patches, nothing serious. Normally I'd wait a bit longer with doing a maintainer revert, but since the minimal set of patches we need to revert (due to the bisect breakage) is so big, time is running out fast. And very soon (especially after a few attempts at fixing issues) it'll be really hard to revert things cleanly. Lessons learned: - Not a good idea to rush the review (done by someone fairly new to the area) and not make sure domain experts had a chance to read it. - Patches should be properly split up. I only looked at the two patches that should be reverted in detail, but both look like the mix up different things in one patch. - Patches really should have proper commit messages. Especially when doing more than one thing, and especially when touching critical and tricky core code. - Building a patch series and r-b stamping it when it has a built-in bisect breakage is not a good idea. - I also think we need to stop building up technical debt by postponing atomic igt testcases even longer. I think it's clear that there's enough corner cases in this beast that we really need to have the testcases _before_ the next step lands. (cherry picked from commit 5a21b665 from drm-intel-next-queeud) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Acked-by:
Dave Airlie <airlied@redhat.com> Acked-by:
Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by:
-
- 31 May, 2016 12 commits
-
-
Daniel Vetter authored
No dev->struct_mutex anywhere to be seen. Cc: Eric Anholt <eric@anholt.net> Reviewed-by:
Eric Anholt <eric@anholt.net> Signed-off-by:
-
Daniel Vetter authored
Since my last struct_mutex crusade someone escaped! This already has the advantage that for the common case when someone else holds a ref the unref won't even acquire dev->struct_mutex. And I'm working on code to allow drivers to completely opt-out of any and all dev->struct_mutex usage, but that only works if they use the _unlocked variants everywhere. v2: Drop comment too. v3: Drop the other comment too. Cc: Eric Anholt <eric@anholt.net> Reviewed-by:
-
Daniel Vetter authored
Code stolen from gma500. This is just a minor bit of safety code that I spotted and figured it might be useful if we put it into the core. This is to make the get_gamma ioctl reflect likely reality even before the first set_gamma ioctl call. v2 on irc: Extend commit message per Maarten's suggestions. Reviewed-by:
-
Daniel Vetter authored
No dev->struct_mutex anywhere to be seen. Cc: seanpaul@chromium.org Signed-off-by:
-
Daniel Vetter authored
qxl doesn't have any functions for setting the gamma table, so this is completely defunct. Not nice to lie to userspace, so let's stop! Cc: Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Daniel Vetter authored
Again the fbdev emulation gamma_set/get functions are only needed for drivers that try to also use 8bpp paletted mode. Which msm doesn't, so this is dead code. Let's rip it out. Cc: Rob Clark <robdclark@gmail.com> Signed-off-by:
-
Daniel Vetter authored
The core does this for us already. Cc: Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Daniel Vetter authored
DRM fbdev emulation only supports pallete_color with depth == 8, and truecolor with depth > 8. Handling depth == 16 for palettes is hence dead code, let's remove it. Signed-off-by:
-
Daniel Vetter authored
No dev->struct_mutex anywhere to be seen. Cc: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by:
Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by:
-
Daniel Vetter authored
No dev->struct_mutex anywhere to be seen. Cc: Xinliang Liu <xinliang.liu@linaro.org> Cc: Xinwei Kong <kong.kongxinwei@hisilicon.com> Signed-off-by:
Xinwei Kong <kong.kongxinwei@hisilicon.com> Signed-off-by:
-
Daniel Vetter authored
No dev->struct_mutex anywhere to be seen. Cc: Liviu Dudau <Liviu.Dudau@arm.com> Signed-off-by:
-
Lukas Wunner authored
Daniel Vetter pointed out that vga_switcheroo_client_probe_defer() could be needed by audio clients as well. To avoid mistakes when someone adds conditions for these in the future, constrain the single existing condition to VGA clients by checking for PCI_BASE_CLASS_DISPLAY. This encompasses both PCI_CLASS_DISPLAY_VGA as well as PCI_CLASS_DISPLAY_3D, which is used by some Nvidia Optimus GPUs. Any future checks for audio clients should then be constrained to PCI_BASE_CLASS_MULTIMEDIA. v6: Spun out from commit introducing vga_switcheroo_client_probe_defer() to keep it a pure refactoring change. (Emil Velikov, Jani Nikula) Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Emil Velikov <emil.l.velikov@gmail.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by:Lukas Wunner <lukas@wunner.de> Signed-off-by:
-
