aboutsummaryrefslogtreecommitdiffstats
path: root/tools/perf/scripts/python/call-graph-from-postgresql.py (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2016-06-02drm/exynos: Use for_each_crtc_in_stateDaniel Vetter1-4/+4
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: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1464818821-5736-8-git-send-email-daniel.vetter@ffwll.ch
2016-06-02drm/omap: Use for_each_plane_in_stateDaniel Vetter1-6/+5
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: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1464818821-5736-7-git-send-email-daniel.vetter@ffwll.ch
2016-06-02drm/vc4: Use for_each_plane_in_stateDaniel Vetter1-7/+3
We want to hide drm_atomic_stat internals a bit better. Cc: Eric Anholt <eric@anholt.net> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1464818821-5736-6-git-send-email-daniel.vetter@ffwll.ch
2016-06-02drm/rcar-du: Use for_each_*_in_stateDaniel Vetter2-16/+12
We want to hide drm_atomic_state internals better. v2: Use drm_crtc_mask (Maarten). Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1464818821-5736-5-git-send-email-daniel.vetter@ffwll.ch
2016-06-02drm/msm: Use for_each_*_in_stateDaniel Vetter3-46/+23
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: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1464818821-5736-4-git-send-email-daniel.vetter@ffwll.ch
2016-06-02drm/i915: Use drm_atomic_get_existing_plane_stateDaniel Vetter1-1/+2
We want to encapsulate the drm_atomic_state internals. v2: Use intel_atomic_get_existing_plane_state (Maarten). Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1464818821-5736-3-git-send-email-daniel.vetter@ffwll.ch
2016-06-02drm/hdlcd: Clean up crtc hooksDaniel Vetter1-19/+0
Those are all no longer needed for a pure atomic driver. Cc: Liviu Dudau <Liviu.Dudau@arm.com> Tested-by: Liviu Dudau <Liviu.Dudau@arm.com> Acked-by: Liviu Dudau <Liviu.Dudau@arm.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1464818821-5736-17-git-send-email-daniel.vetter@ffwll.ch
2016-06-02drm/atomic-helper: use for_each_*_in_state moreDaniel Vetter1-31/+16
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: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1464818821-5736-2-git-send-email-daniel.vetter@ffwll.ch
2016-06-02drm: Only create a cmdline mode if no probed modes matchChris Wilson1-2/+19
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 eaf99c749d43ae74ac7ffece5512f3c73f01dfd2 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: Chris Wilson <chris@chris-wilson.co.uk> Cc: Radek Dostál <rd@radekdostal.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Cc: Julia Lemire <jlemire@matrox.com> Cc: Dave Airlie <airlied@redhat.com> Reviewed-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: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1464774651-20376-1-git-send-email-chris@chris-wilson.co.uk
2016-06-02dma-buf/fence: add signal_on_any to the fence array v2Christian König2-9/+27
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 <gustavo.padovan@collabora.co.uk> Acked-by: Sumit Semwal <sumit.semwal@linaro.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1464786612-5010-4-git-send-email-deathsimple@vodafone.de
2016-06-02dma-buf/fence: add fence_array fences v6Gustavo Padovan3-1/+200
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: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Acked-by: Sumit Semwal <sumit.semwal@linaro.org> [danvet: Improve commit message as suggested by Gustavo.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1464786612-5010-3-git-send-email-deathsimple@vodafone.de
2016-06-02dma-buf/fence: make fence context 64 bit v2Christian König10-18/+21
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: Christian König <christian.koenig@amd.com> Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Acked-by: Sumit Semwal <sumit.semwal@linaro.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1464786612-5010-2-git-send-email-deathsimple@vodafone.de
2016-06-02drm: Update obsolete information from {enable/disable}_vblank hooks.Liviu Dudau1-5/+5
Since commit 4dfd64862ff8 ("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: Liviu Dudau <Liviu.Dudau@arm.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1464795342-32297-1-git-send-email-Liviu.Dudau@arm.com
2016-06-02drm/atomic: Handle funcs->best_encoder == NULL caseBoris Brezillon1-1/+3
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: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20160601180337.28e0917b@bbrezillon
2016-06-01drm/i915: Revert async unpin and nonblocking atomic commitDaniel Vetter11-625/+1283
This reverts the following patches: d55dbd06bb5e1399aba9ab5227465339d1bbefff drm/i915: Allow nonblocking update of pageflips. 15c86bdb760185e871c7a0f559978328aa500971 drm/i915: Check for unpin correctness. 95c2ccdc82d520f59ae3b6fdc097b63c9b7082bb Reapply "drm/i915: Avoid stalling on pending flips for legacy cursor updates" a6747b7304a9d66758a196d885dab8bbfa5e7d1f drm/i915: Make unpin async. 03f476e1fcb42fca88fc50b94b0d3adbdbe887f0 drm/i915: Prepare connectors for nonblocking checks. 2099deffef4404f949ba1b68d2b17e0608190bc2 drm/i915: Pass atomic states to fbc update functions. ee7171af72c39c18b7d7571419a4ac6ca30aea66 drm/i915: Remove reset_counter from intel_crtc. 2ee004f7c59b2e642f0bb2834f847d756f2dd7b7 drm/i915: Remove queue_flip pointer. b8d2afae557dbb9b9c7bc6f6ec4f5278f3c4c34e drm/i915: Remove use_mmio_flip kernel parameter. 8dd634d922615ec3a9af7976029110ec037f8b50 drm/i915: Remove cs based page flip support. 143f73b3bf48c089b40f58462dd7f7c199fd4f0f drm/i915: Rework intel_crtc_page_flip to be almost atomic, v3. 84fc494b64e8c591be446a966b7447a9db519c88 drm/i915: Add the exclusive fence to plane_state. 6885843ae164e11f6c802209d06921e678a3f3f3 drm/i915: Convert flip_work to a list. aa420ddd8eeaa5df579894a412289e4d07c2fee9 drm/i915: Allow mmio updates on all platforms, v2. afee4d8707ab1f21b7668de995be3a5961e83582 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 5a21b6650a239ebc020912968a44047701104159 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: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Dave Airlie <airlied@redhat.com> Acked-by: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2016-05-31drm/vc4: Use lockless gem BO free callbackDaniel Vetter1-1/+1
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 <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1464630800-30786-16-git-send-email-daniel.vetter@ffwll.ch
2016-05-31drm/vc4: Use drm_gem_object_unreference_unlockedDaniel Vetter2-10/+3
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: Eric Anholt <eric@anholt.net> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1464630800-30786-15-git-send-email-daniel.vetter@ffwll.ch
2016-05-31drm: Initialize a linear gamma table by defaultDaniel Vetter2-7/+13
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: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459331485-28376-2-git-send-email-daniel.vetter@ffwll.ch
2016-05-31drm/vgem: Use lockless gem BO free callbackDaniel Vetter1-1/+1
No dev->struct_mutex anywhere to be seen. Cc: seanpaul@chromium.org Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1464630800-30786-17-git-send-email-daniel.vetter@ffwll.ch
2016-05-31drm/qxl: Don't set a gamma table sizeDaniel Vetter1-1/+0
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 <daniel.vetter@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1459331485-28376-10-git-send-email-daniel.vetter@ffwll.ch
2016-05-31drm/msm: Nuke dummy gamma_set/get functionsDaniel Vetter1-14/+0
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 <daniel.vetter@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1459331485-28376-7-git-send-email-daniel.vetter@ffwll.ch
2016-05-31drm/cirrus: Drop redundnant gamma size checkDaniel Vetter1-3/+0
The core does this for us already. Cc: Dave Airlie <airlied@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1459331485-28376-6-git-send-email-daniel.vetter@ffwll.ch
2016-05-31drm/fb-helper: Remove dead code in setcolregDaniel Vetter1-31/+2
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 <daniel.vetter@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1459331485-28376-3-git-send-email-daniel.vetter@ffwll.ch
2016-05-31drm/mediatek: Use lockless gem BO free callbackDaniel Vetter1-1/+1
No dev->struct_mutex anywhere to be seen. Cc: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Acked-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1464630800-30786-28-git-send-email-daniel.vetter@ffwll.ch
2016-05-31drm/hisilicon: Use lockless gem BO free callbackDaniel Vetter1-1/+1
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: Daniel Vetter <daniel.vetter@intel.com> Acked-by: Xinwei Kong <kong.kongxinwei@hisilicon.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1464630800-30786-27-git-send-email-daniel.vetter@ffwll.ch
2016-05-31drm/hlcd: Use lockless gem BO free callbackDaniel Vetter1-1/+1
No dev->struct_mutex anywhere to be seen. Cc: Liviu Dudau <Liviu.Dudau@arm.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Acked-by: Liviu Dudau <Liviu.Dudau@arm.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1464630800-30786-26-git-send-email-daniel.vetter@ffwll.ch
2016-05-31vga_switcheroo: Support deferred probing of audio clientsLukas Wunner1-8/+11
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: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/358d58490eb9dda5f270d844b0dce511a2a20828.1464685538.git.lukas@wunner.de
2016-05-31vga_switcheroo: Add helper for deferred probingLukas Wunner5-28/+33
So far we've got one condition when DRM drivers need to defer probing on a dual GPU system and it's coded separately into each of the relevant drivers. As suggested by Daniel Vetter, deduplicate that code in the drivers and move it to a new vga_switcheroo helper. This yields better encapsulation of concepts and lets us add further checks in a central place. (The existing check pertains to pre-retina MacBook Pros and an additional check is expected to be needed for retinas.) One might be tempted to check deferred probing conditions in vga_switcheroo_register_client(), but this is usually called fairly late during driver load. The GPU is fully brought up and ready for switching at that point. On boot the ->probe hook is potentially called dozens of times until it finally succeeds, and each time we'd repeat bringup and teardown of the GPU, lengthening boot time considerably and cluttering logfiles. A separate helper is therefore needed which can be called right at the beginning of the ->probe hook. Note that amdgpu currently does not call this helper as the AMD GPUs built into MacBook Pros are only supported by radeon so far. v2: This helper could eventually be used by audio clients as well, so rephrase kerneldoc to refer to "client" instead of "GPU" and move the single existing check in an if block specific to PCI_CLASS_DISPLAY_VGA devices. Move documentation on that check from kerneldoc to a comment. (Daniel Vetter) v3: Mandate in kerneldoc that registration of client shall only happen after calling this helper. (Daniel Vetter) v4: Rebase on 412c8f7de011 ("drm/radeon: Return -EPROBE_DEFER when amdkfd not loaded") v5: Some Optimus GPUs use PCI_CLASS_DISPLAY_3D, make sure those are matched as well. (Emil Velikov) v6: The if-condition referring to PCI_BASE_CLASS_DISPLAY may be considered a functional change. Move to a separate commit to keep this a pure refactoring change. (Emil Velikov, Jani Nikula) Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/575885fd440c2b13c3f19ddf44360cfbbff35f50.1464685538.git.lukas@wunner.de
2016-05-31virtio-gpu: fix output lookupGerd Hoffmann1-1/+7
Needed for multihead setups where we can have disabled outputs and therefore plane->crtc can be NULL. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1464609806-22013-1-git-send-email-kraxel@redhat.com
2016-05-30drm/doc: Unify KMS Locking docsDaniel Vetter2-18/+9
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Acked-by: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1464599449-12509-1-git-send-email-daniel.vetter@ffwll.ch
2016-05-30drm/atomic-helper: Do not call ->mode_fixup for CRTC which will be disabledLiu Ying1-0/+3
When a CRTC is going to be disabled, it's state may contain a display mode with zeroed content. This could be reproduced by HDMI cable hotplug out operation with legacy fbdev support in dual display cases. It would confuse driver's CRTC callback ->mode_fixup and make the total state be rejected. So, let's don't call the callback for the CRTC. Signed-off-by: Liu Ying <gnuiyl@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1464341754-7087-1-git-send-email-gnuiyl@gmail.com
2016-05-30Fix annoyingly awkward typo in drm_edid_load.cValdis Kletnieks1-1/+1
Fix egregious typo in comment. Signed-off-by: Valdis Kletnieks <valdis.kletnieks@vt.edu> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/10576.1464589598@turing-police.cc.vt.edu
2016-05-29Linux 4.7-rc1Linus Torvalds1-3/+3
2016-05-29hash_string: Fix zero-length case for !DCACHE_WORD_ACCESSGeorge Spelvin1-2/+2
The self-test was updated to cover zero-length strings; the function needs to be updated, too. Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: George Spelvin <linux@sciencehorizons.net> Fixes: fcfd2fbf22d2 ("fs/namei.c: Add hashlen_string() function") Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-05-28Rename other copy of hash_string to hashlen_stringGeorge Spelvin1-2/+2
The original name was simply hash_string(), but that conflicted with a function with that name in drivers/base/power/trace.c, and I decided that calling it "hashlen_" was better anyway. But you have to do it in two places. [ This caused build errors for architectures that don't define CONFIG_DCACHE_WORD_ACCESS - Linus ] Signed-off-by: George Spelvin <linux@sciencehorizons.net> Reported-by: Guenter Roeck <linux@roeck-us.net> Fixes: fcfd2fbf22d2 ("fs/namei.c: Add hashlen_string() function") Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-05-28hpfs: implement the show_options methodMikulas Patocka1-11/+32
The HPFS filesystem used generic_show_options to produce string that is displayed in /proc/mounts. However, there is a problem that the options may disappear after remount. If we mount the filesystem with option1 and then remount it with option2, /proc/mounts should show both option1 and option2, however it only shows option2 because the whole option string is replaced with replace_mount_options in hpfs_remount_fs. To fix this bug, implement the hpfs_show_options function that prints options that are currently selected. Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-05-28affs: fix remount failure when there are no options changedMikulas Patocka1-2/+3
Commit c8f33d0bec99 ("affs: kstrdup() memory handling") checks if the kstrdup function returns NULL due to out-of-memory condition. However, if we are remounting a filesystem with no change to filesystem-specific options, the parameter data is NULL. In this case, kstrdup returns NULL (because it was passed NULL parameter), although no out of memory condition exists. The mount syscall then fails with ENOMEM. This patch fixes the bug. We fail with ENOMEM only if data is non-NULL. The patch also changes the call to replace_mount_options - if we didn't pass any filesystem-specific options, we don't call replace_mount_options (thus we don't erase existing reported options). Fixes: c8f33d0bec99 ("affs: kstrdup() memory handling") Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Cc: stable@vger.kernel.org # v4.1+ Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-05-28hpfs: fix remount failure when there are no options changedMikulas Patocka1-2/+3
Commit ce657611baf9 ("hpfs: kstrdup() out of memory handling") checks if the kstrdup function returns NULL due to out-of-memory condition. However, if we are remounting a filesystem with no change to filesystem-specific options, the parameter data is NULL. In this case, kstrdup returns NULL (because it was passed NULL parameter), although no out of memory condition exists. The mount syscall then fails with ENOMEM. This patch fixes the bug. We fail with ENOMEM only if data is non-NULL. The patch also changes the call to replace_mount_options - if we didn't pass any filesystem-specific options, we don't call replace_mount_options (thus we don't erase existing reported options). Fixes: ce657611baf9 ("hpfs: kstrdup() out of memory handling") Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-05-28fs: fix binfmt_aout.c build errorGuenter Roeck1-1/+0
Various builds (such as i386:allmodconfig) fail with fs/binfmt_aout.c:133:2: error: expected identifier or '(' before 'return' fs/binfmt_aout.c:134:1: error: expected identifier or '(' before '}' token [ Oops. My bad, I had stupidly thought that "allmodconfig" covered this on x86-64 too, but it obviously doesn't. Egg on my face. - Linus ] Fixes: 5d22fc25d4fc ("mm: remove more IS_ERR_VALUE abuses") Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-05-28h8300: Add <asm/hash.h>George Spelvin2-0/+54
This will improve the performance of hash_32() and hash_64(), but due to complete lack of multi-bit shift instructions on H8, performance will still be bad in surrounding code. Designing H8-specific hash algorithms to work around that is a separate project. (But if the maintainers would like to get in touch...) Signed-off-by: George Spelvin <linux@sciencehorizons.net> Cc: Yoshinori Sato <ysato@users.sourceforge.jp> Cc: uclinux-h8-devel@lists.sourceforge.jp
2016-05-28microblaze: Add <asm/hash.h>George Spelvin2-0/+82
Microblaze is an FPGA soft core that can be configured various ways. If it is configured without a multiplier, the standard __hash_32() will require a call to __mulsi3, which is a slow software loop. Instead, use a shift-and-add sequence for the constant multiply. GCC knows how to do this, but it's not as clever as some. Signed-off-by: George Spelvin <linux@sciencehorizons.net> Cc: Alistair Francis <alistair.francis@xilinx.com> Cc: Michal Simek <michal.simek@xilinx.com>
2016-05-28m68k: Add <asm/hash.h>George Spelvin2-0/+60
This provides a multiply by constant GOLDEN_RATIO_32 = 0x61C88647 for the original mc68000, which lacks a 32x32-bit multiply instruction. Yes, the amount of optimization effort put in is excessive. :-) Shift-add chain found by Yevgen Voronenko's Hcub algorithm at http://spiral.ece.cmu.edu/mcm/gen.html Signed-off-by: George Spelvin <linux@sciencehorizons.net> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Greg Ungerer <gerg@linux-m68k.org> Cc: Andreas Schwab <schwab@linux-m68k.org> Cc: Philippe De Muyter <phdm@macq.eu> Cc: linux-m68k@lists.linux-m68k.org
2016-05-28<linux/hash.h>: Add support for architecture-specific functionsGeorge Spelvin6-4/+299
This is just the infrastructure; there are no users yet. This is modelled on CONFIG_ARCH_RANDOM; a CONFIG_ symbol declares the existence of <asm/hash.h>. That file may define its own versions of various functions, and define HAVE_* symbols (no CONFIG_ prefix!) to suppress the generic ones. Included is a self-test (in lib/test_hash.c) that verifies the basics. It is NOT in general required that the arch-specific functions compute the same thing as the generic, but if a HAVE_* symbol is defined with the value 1, then equality is tested. Signed-off-by: George Spelvin <linux@sciencehorizons.net> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Greg Ungerer <gerg@linux-m68k.org> Cc: Andreas Schwab <schwab@linux-m68k.org> Cc: Philippe De Muyter <phdm@macq.eu> Cc: linux-m68k@lists.linux-m68k.org Cc: Alistair Francis <alistai@xilinx.com> Cc: Michal Simek <michal.simek@xilinx.com> Cc: Yoshinori Sato <ysato@users.sourceforge.jp> Cc: uclinux-h8-devel@lists.sourceforge.jp
2016-05-28fs/namei.c: Improve dcache hash functionGeorge Spelvin1-40/+81
Patch 0fed3ac866 improved the hash mixing, but the function is slower than necessary; there's a 7-instruction dependency chain (10 on x86) each loop iteration. Word-at-a-time access is a very tight loop (which is good, because link_path_walk() is one of the hottest code paths in the entire kernel), and the hash mixing function must not have a longer latency to avoid slowing it down. There do not appear to be any published fast hash functions that: 1) Operate on the input a word at a time, and 2) Don't need to know the length of the input beforehand, and 3) Have a single iterated mixing function, not needing conditional branches or unrolling to distinguish different loop iterations. One of the algorithms which comes closest is Yann Collet's xxHash, but that's two dependent multiplies per word, which is too much. The key insights in this design are: 1) Barring expensive ops like multiplies, to diffuse one input bit across 64 bits of hash state takes at least log2(64) = 6 sequentially dependent instructions. That is more cycles than we'd like. 2) An operation like "hash ^= hash << 13" requires a second temporary register anyway, and on a 2-operand machine like x86, it's three instructions. 3) A better use of a second register is to hold a two-word hash state. With careful design, no temporaries are needed at all, so it doesn't increase register pressure. And this gets rid of register copying on 2-operand machines, so the code is smaller and faster. 4) Using two words of state weakens the requirement for one-round mixing; we now have two rounds of mixing before cancellation is possible. 5) A two-word hash state also allows operations on both halves to be done in parallel, so on a superscalar processor we get more mixing in fewer cycles. I ended up using a mixing function inspired by the ChaCha and Speck round functions. It is 6 simple instructions and 3 cycles per iteration (assuming multiply by 9 can be done by an "lea" instruction): x ^= *input++; y ^= x; x = ROL(x, K1); x += y; y = ROL(y, K2); y *= 9; Not only is this reversible, two consecutive rounds are reversible: if you are given the initial and final states, but not the intermediate state, it is possible to compute both input words. This means that at least 3 words of input are required to create a collision. (It also has the property, used by hash_name() to avoid a branch, that it hashes all-zero to all-zero.) The rotate constants K1 and K2 were found by experiment. The search took a sample of random initial states (I used 1023) and considered the effect of flipping each of the 64 input bits on each of the 128 output bits two rounds later. Each of the 8192 pairs can be considered a biased coin, and adding up the Shannon entropy of all of them produces a score. The best-scoring shifts also did well in other tests (flipping bits in y, trying 3 or 4 rounds of mixing, flipping all 64*63/2 pairs of input bits), so the choice was made with the additional constraint that the sum of the shifts is odd and not too close to the word size. The final state is then folded into a 32-bit hash value by a less carefully optimized multiply-based scheme. This also has to be fast, as pathname components tend to be short (the most common case is one iteration!), but there's some room for latency, as there is a fair bit of intervening logic before the hash value is used for anything. (Performance verified with "bonnie++ -s 0 -n 1536:-2" on tmpfs. I need a better benchmark; the numbers seem to show a slight dip in performance between 4.6.0 and this patch, but they're too noisy to quote.) Special thanks to Bruce fields for diligent testing which uncovered a nasty fencepost error in an earlier version of this patch. [checkpatch.pl formatting complaints noted and respectfully disagreed with.] Signed-off-by: George Spelvin <linux@sciencehorizons.net> Tested-by: J. Bruce Fields <bfields@redhat.com>
2016-05-28Eliminate bad hash multipliers from hash_32() and hash_64()George Spelvin2-53/+36
The "simplified" prime multipliers made very bad hash functions, so get rid of them. This completes the work of 689de1d6ca. To avoid the inefficiency which was the motivation for the "simplified" multipliers, hash_64() on 32-bit systems is changed to use a different algorithm. It makes two calls to hash_32() instead. drivers/media/usb/dvb-usb-v2/af9015.c uses the old GOLDEN_RATIO_PRIME_32 for some horrible reason, so it inherits a copy of the old definition. Signed-off-by: George Spelvin <linux@sciencehorizons.net> Cc: Antti Palosaari <crope@iki.fi> Cc: Mauro Carvalho Chehab <m.chehab@samsung.com>
2016-05-28Change hash_64() return value to 32 bitsGeorge Spelvin1-3/+3
That's all that's ever asked for, and it makes the return type of hash_long() consistent. It also allows (upcoming patch) an optimized implementation of hash_64 on 32-bit machines. I tried adding a BUILD_BUG_ON to ensure the number of bits requested was never more than 32 (most callers use a compile-time constant), but adding <linux/bug.h> to <linux/hash.h> breaks the tools/perf compiler unless tools/perf/MANIFEST is updated, and understanding that code base well enough to update it is too much trouble. I did the rest of an allyesconfig build with such a check, and nothing tripped. Signed-off-by: George Spelvin <linux@sciencehorizons.net>
2016-05-28<linux/sunrpc/svcauth.h>: Define hash_str() in terms of hashlen_string()George Spelvin1-31/+9
Finally, the first use of previous two patches: eliminate the separate ad-hoc string hash functions in the sunrpc code. Now hash_str() is a wrapper around hash_string(), and hash_mem() is likewise a wrapper around full_name_hash(). Note that sunrpc code *does* call hash_mem() with a zero length, which is why the previous patch needed to handle that in full_name_hash(). (Thanks, Bruce, for finding that!) This also eliminates the only caller of hash_long which asks for more than 32 bits of output. The comment about the quality of hashlen_string() and full_name_hash() is jumping the gun by a few patches; they aren't very impressive now, but will be improved greatly later in the series. Signed-off-by: George Spelvin <linux@sciencehorizons.net> Tested-by: J. Bruce Fields <bfields@redhat.com> Acked-by: J. Bruce Fields <bfields@redhat.com> Cc: Jeff Layton <jlayton@poochiereds.net> Cc: linux-nfs@vger.kernel.org
2016-05-28fs/namei.c: Add hashlen_string() functionGeorge Spelvin3-9/+53
We'd like to make more use of the highly-optimized dcache hash functions throughout the kernel, rather than have every subsystem create its own, and a function that hashes basic null-terminated strings is required for that. (The name is to emphasize that it returns both hash and length.) It's actually useful in the dcache itself, specifically d_alloc_name(). Other uses in the next patch. full_name_hash() is also tweaked to make it more generally useful: 1) Take a "char *" rather than "unsigned char *" argument, to be consistent with hash_name(). 2) Handle zero-length inputs. If we want more callers, we don't want to make them worry about corner cases. Signed-off-by: George Spelvin <linux@sciencehorizons.net>
2016-05-28Pull out string hash to <linux/stringhash.h>George Spelvin2-26/+73
... so they can be used without the rest of <linux/dcache.h> The hashlen_* macros will make sense next patch. Signed-off-by: George Spelvin <linux@sciencehorizons.net>
2016-05-28Revert "platform/chrome: chromeos_laptop: Add Leon Touch"Benson Leung1-15/+0
This reverts commit bff3c624dc7261a084a4d25a0b09c3fb0fec872a. Board "Leon" is otherwise known as "Toshiba CB35" and we already have the entry that supports that board as of this commit : 963cb6f platform/chrome: chromeos_laptop - Add Toshiba CB35 Touch Remove this duplicate. Signed-off-by: Benson Leung <bleung@chromium.org> Signed-off-by: Olof Johansson <olof@lixom.net>
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.