1. 20 Oct, 2017 2 commits
    • Thierry Reding's avatar
      gpu: host1x: syncpt: Request syncpoints per client · 617dd7cc
      Thierry Reding authored
      Rather than request syncpoints for a struct device *, request them for a
      struct host1x_client *. This is important because subsequent patches are
      going to break the assumption that host1x will always be the parent for
      devices requesting a syncpoint. It's also a more natural choice because
      host1x clients are really the only ones that will know how to deal with
      syncpoints.
      
      Note that host1x clients are always guaranteed to be children of host1x,
      regardless of their location in the device tree.
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      617dd7cc
    • Thierry Reding's avatar
      gpu: host1x: Use of_device_get_match_data() · 6a341fdf
      Thierry Reding authored
      Avoid some boilerplate by calling of_device_get_match_data() instead of
      open-coding the equivalent in the driver.
      
      While at it, shuffle around some code to avoid unnecessary local
      variables.
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      6a341fdf
  2. 26 Sep, 2017 1 commit
  3. 25 Sep, 2017 1 commit
  4. 22 Sep, 2017 1 commit
  5. 20 Sep, 2017 4 commits
  6. 19 Sep, 2017 3 commits
  7. 18 Sep, 2017 6 commits
  8. 15 Sep, 2017 1 commit
  9. 14 Sep, 2017 3 commits
    • Jean DELVARE's avatar
      drm/amdgpu: revert tile table update for oland · 4cf97582
      Jean DELVARE authored
      Several users have complained that the tile table update broke Oland
      support. Despite several attempts to fix it, the root cause is still
      unknown at this point and no solution is available. As it is not
      acceptable to leave a known regression breaking a major functionality
      in the kernel for several releases, let's just reverse this
      optimization for now. It can be implemented again later if and only
      if the breakage is understood and fixed.
      
      As there were no complaints for Hainan so far, only the Oland part of
      the offending commit is reverted. Optimization is preserved on
      Hainan, so this commit isn't an actual revert of the original.
      
      This fixes bug #194761:
      https://bugzilla.kernel.org/show_bug.cgi?id=194761Reviewed-by: default avatarMarek Olšák <marek.olsak@amd.com>
      Signed-off-by: Jean DELVARE's avatarJean Delvare <jdelvare@suse.de>
      Fixes: f8d9422e ("drm/amdgpu: update tile table for oland/hainan")
      Cc: Flora Cui <Flora.Cui@amd.com>
      Cc: Junwei Zhang <Jerry.Zhang@amd.com>
      Cc: Alex Deucher <alexander.deucher@amd.com>
      Cc: Marek Olšák <maraeo@gmail.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Cc: stable@vger.kernel.org
      4cf97582
    • Christoph Hellwig's avatar
      dmi: Mark all struct dmi_system_id instances const · 6faadbbb
      Christoph Hellwig authored
      ... and __initconst if applicable.
      
      Based on similar work for an older kernel in the Grsecurity patch.
      
      [JD: fix toshiba-wmi build]
      [JD: add htcpen]
      [JD: move __initconst where checkscript wants it]
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: Jean DELVARE's avatarJean Delvare <jdelvare@suse.de>
      6faadbbb
    • Michal Hocko's avatar
      mm: treewide: remove GFP_TEMPORARY allocation flag · 0ee931c4
      Michal Hocko authored
      GFP_TEMPORARY was introduced by commit e12ba74d ("Group short-lived
      and reclaimable kernel allocations") along with __GFP_RECLAIMABLE.  It's
      primary motivation was to allow users to tell that an allocation is
      short lived and so the allocator can try to place such allocations close
      together and prevent long term fragmentation.  As much as this sounds
      like a reasonable semantic it becomes much less clear when to use the
      highlevel GFP_TEMPORARY allocation flag.  How long is temporary? Can the
      context holding that memory sleep? Can it take locks? It seems there is
      no good answer for those questions.
      
      The current implementation of GFP_TEMPORARY is basically GFP_KERNEL |
      __GFP_RECLAIMABLE which in itself is tricky because basically none of
      the existing caller provide a way to reclaim the allocated memory.  So
      this is rather misleading and hard to evaluate for any benefits.
      
      I have checked some random users and none of them has added the flag
      with a specific justification.  I suspect most of them just copied from
      other existing users and others just thought it might be a good idea to
      use without any measuring.  This suggests that GFP_TEMPORARY just
      motivates for cargo cult usage without any reasoning.
      
      I believe that our gfp flags are quite complex already and especially
      those with highlevel semantic should be clearly defined to prevent from
      confusion and abuse.  Therefore I propose dropping GFP_TEMPORARY and
      replace all existing users to simply use GFP_KERNEL.  Please note that
      SLAB users with shrinkers will still get __GFP_RECLAIMABLE heuristic and
      so they will be placed properly for memory fragmentation prevention.
      
      I can see reasons we might want some gfp flag to reflect shorterm
      allocations but I propose starting from a clear semantic definition and
      only then add users with proper justification.
      
      This was been brought up before LSF this year by Matthew [1] and it
      turned out that GFP_TEMPORARY really doesn't have a clear semantic.  It
      seems to be a heuristic without any measured advantage for most (if not
      all) its current users.  The follow up discussion has revealed that
      opinions on what might be temporary allocation differ a lot between
      developers.  So rather than trying to tweak existing users into a
      semantic which they haven't expected I propose to simply remove the flag
      and start from scratch if we really need a semantic for short term
      allocations.
      
      [1] http://lkml.kernel.org/r/20170118054945.GD18349@bombadil.infradead.org
      
      [akpm@linux-foundation.org: fix typo]
      [akpm@linux-foundation.org: coding-style fixes]
      [sfr@canb.auug.org.au: drm/i915: fix up]
        Link: http://lkml.kernel.org/r/20170816144703.378d4f4d@canb.auug.org.au
      Link: http://lkml.kernel.org/r/20170728091904.14627-1-mhocko@kernel.orgSigned-off-by: default avatarMichal Hocko <mhocko@suse.com>
      Signed-off-by: default avatarStephen Rothwell <sfr@canb.auug.org.au>
      Acked-by: default avatarMel Gorman <mgorman@suse.de>
      Acked-by: default avatarVlastimil Babka <vbabka@suse.cz>
      Cc: Matthew Wilcox <willy@infradead.org>
      Cc: Neil Brown <neilb@suse.de>
      Cc: "Theodore Ts'o" <tytso@mit.edu>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      0ee931c4
  10. 13 Sep, 2017 3 commits
  11. 12 Sep, 2017 1 commit
  12. 09 Sep, 2017 1 commit
  13. 08 Sep, 2017 1 commit
  14. 07 Sep, 2017 1 commit
    • Chris Wilson's avatar
      drm/i915: wire up shrinkctl->nr_scanned · 912d572d
      Chris Wilson authored
      shrink_slab() allows us to report back the number of objects we
      successfully scanned (out of the target shrinkctl->nr_to_scan).  As
      report the number of pages owned by each GEM object as a separate item
      to the shrinker, we cannot precisely control the number of shrinker
      objects we scan on each pass; and indeed may free more than requested.
      If we fail to tell the shrinker about the number of objects we process,
      it will continue to hold a grudge against us as any objects left
      unscanned are added to the next reclaim -- and so we will keep on
      "unfairly" shrinking our own slab in comparison to other slabs.
      
      Link: http://lkml.kernel.org/r/20170822135325.9191-2-chris@chris-wilson.co.ukSigned-off-by: Chris Wilson's avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Michal Hocko <mhocko@suse.com>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: Hillf Danton <hillf.zj@alibaba-inc.com>
      Cc: Minchan Kim <minchan@kernel.org>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Cc: Mel Gorman <mgorman@techsingularity.net>
      Cc: Shaohua Li <shli@fb.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Cc: Pekka Enberg <penberg@kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      912d572d
  15. 06 Sep, 2017 2 commits
  16. 05 Sep, 2017 4 commits
  17. 02 Sep, 2017 1 commit
  18. 01 Sep, 2017 4 commits