1. 17 May, 2020 3 commits
  2. 15 May, 2020 3 commits
    • Maxime Ripard's avatar
      drm/sun4i: mixer: Call of_dma_configure if there's an IOMMU · b718102d
      Maxime Ripard authored
      The main DRM device is actually a virtual device so it doesn't have the
      iommus property, which is instead on the DMA masters, in this case the
      mixers.
      
      Add a call to of_dma_configure with the mixers DT node but on the DRM
      virtual device to configure it in the same way than the mixers.
      Reviewed-by: default avatarPaul Kocialkowski <paul.kocialkowski@bootlin.com>
      Signed-off-by: default avatarMaxime Ripard <maxime@cerno.tech>
      Link: https://patchwork.freedesktop.org/patch/msgid/9a4daf438dd3f2fe07afb23688bfb793a0613d7d.1589378833.git-series.maxime@cerno.tech
      b718102d
    • Maxime Ripard's avatar
      dt-bindings: display: sun8i-mixer: Allow for an iommu property · e8ade615
      Maxime Ripard authored
      The H6 mixer is attached to an IOMMU, so let's allow that property to be
      set in the bindings.
      Reviewed-by: default avatarRob Herring <robh@kernel.org>
      Signed-off-by: default avatarMaxime Ripard <maxime@cerno.tech>
      Link: https://patchwork.freedesktop.org/patch/msgid/7941e0c02794e6336da75fcac950ecd43be7fd97.1589378833.git-series.maxime@cerno.tech
      e8ade615
    • Imre Deak's avatar
      drm/dp_mst: Fix timeout handling of MST down messages · 58c17217
      Imre Deak authored
      This fixes the following use-after-free problem in case an MST down
      message times out, while waiting for the response for it:
      
      [  449.022841] [drm:drm_dp_mst_wait_tx_reply.isra.26] timedout msg send 0000000080ba7fa2 2 0
      [  449.022898] ------------[ cut here ]------------
      [  449.022903] list_add corruption. prev->next should be next (ffff88847dae32c0), but was 6b6b6b6b6b6b6b6b. (prev=ffff88847db1c140).
      [  449.022931] WARNING: CPU: 2 PID: 22 at lib/list_debug.c:28 __list_add_valid+0x4d/0x70
      [  449.022935] Modules linked in: asix usbnet mii snd_hda_codec_hdmi mei_hdcp i915 x86_pkg_temp_thermal coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hwdep e1000e snd_hda_core ptp snd_pcm pps_core mei_me mei intel_lpss_pci prime_numbers
      [  449.022966] CPU: 2 PID: 22 Comm: kworker/2:0 Not tainted 5.7.0-rc3-CI-Patchwork_17536+ #1
      [  449.022970] Hardware name: Intel Corporation Tiger Lake Client Platform/TigerLake U DDR4 SODIMM RVP, BIOS TGLSFWI1.R00.2457.A16.1912270059 12/27/2019
      [  449.022976] Workqueue: events_long drm_dp_mst_link_probe_work
      [  449.022982] RIP: 0010:__list_add_valid+0x4d/0x70
      [  449.022987] Code: c3 48 89 d1 48 c7 c7 f0 e7 32 82 48 89 c2 e8 3a 49 b7 ff 0f 0b 31 c0 c3 48 89 c1 4c 89 c6 48 c7 c7 40 e8 32 82 e8 23 49 b7 ff <0f> 0b 31 c0 c3 48 89 f2 4c 89 c1 48 89 fe 48 c7 c7 90 e8 32 82 e8
      [  449.022991] RSP: 0018:ffffc900001abcb0 EFLAGS: 00010286
      [  449.022995] RAX: 0000000000000000 RBX: ffff88847dae2d58 RCX: 0000000000000001
      [  449.022999] RDX: 0000000080000001 RSI: ffff88849d914978 RDI: 00000000ffffffff
      [  449.023002] RBP: ffff88847dae32c0 R08: ffff88849d914978 R09: 0000000000000000
      [  449.023006] R10: ffffc900001abcb8 R11: 0000000000000000 R12: ffff888490d98400
      [  449.023009] R13: ffff88847dae3230 R14: ffff88847db1c140 R15: ffff888490d98540
      [  449.023013] FS:  0000000000000000(0000) GS:ffff88849ff00000(0000) knlGS:0000000000000000
      [  449.023017] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  449.023021] CR2: 00007fb96fafdc63 CR3: 0000000005610004 CR4: 0000000000760ee0
      [  449.023025] PKRU: 55555554
      [  449.023028] Call Trace:
      [  449.023034]  drm_dp_queue_down_tx+0x59/0x110
      [  449.023041]  ? rcu_read_lock_sched_held+0x4d/0x80
      [  449.023050]  ? kmem_cache_alloc_trace+0x2a6/0x2d0
      [  449.023060]  drm_dp_send_link_address+0x74/0x870
      [  449.023065]  ? __slab_free+0x3e1/0x5c0
      [  449.023071]  ? lockdep_hardirqs_on+0xe0/0x1c0
      [  449.023078]  ? lockdep_hardirqs_on+0xe0/0x1c0
      [  449.023097]  drm_dp_check_and_send_link_address+0x9a/0xc0
      [  449.023106]  drm_dp_mst_link_probe_work+0x9e/0x160
      [  449.023117]  process_one_work+0x268/0x600
      [  449.023124]  ? __schedule+0x307/0x8d0
      [  449.023139]  worker_thread+0x37/0x380
      [  449.023149]  ? process_one_work+0x600/0x600
      [  449.023153]  kthread+0x140/0x160
      [  449.023159]  ? kthread_park+0x80/0x80
      [  449.023169]  ret_from_fork+0x24/0x50
      
      Fixes: d308a881 ("drm/dp_mst: Kill the second sideband tx slot, save the world")
      Cc: Lyude Paul <lyude@redhat.com>
      Cc: Sean Paul <sean@poorly.run>
      Cc: Wayne Lin <Wayne.Lin@amd.com>
      Cc: <stable@vger.kernel.org> # v3.17+
      Signed-off-by: default avatarImre Deak <imre.deak@intel.com>
      Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20200513103155.12336-1-imre.deak@intel.com
      58c17217
  3. 14 May, 2020 1 commit
  4. 13 May, 2020 1 commit
  5. 12 May, 2020 1 commit
  6. 11 May, 2020 6 commits
  7. 09 May, 2020 7 commits
  8. 08 May, 2020 3 commits
  9. 07 May, 2020 5 commits
  10. 06 May, 2020 9 commits
  11. 05 May, 2020 1 commit
    • Nirmoy Das's avatar
      drm/mm: optimize rb_hole_addr rbtree search · 0cdea445
      Nirmoy Das authored
      Userspace can severely fragment rb_hole_addr rbtree by manipulating
      alignment while allocating buffers. Fragmented rb_hole_addr rbtree
      would result in large delays while allocating buffer object for a
      userspace application. It takes long time to find suitable hole
      because if we fail to find a suitable hole in the first attempt
      then we look for neighbouring nodes using rb_prev()/rb_next().
      Traversing rbtree using rb_prev()/rb_next() can take really long
      time if the tree is fragmented.
      
      This patch improves searches in fragmented rb_hole_addr rbtree by
      modifying it to an augmented rbtree which will store an extra field
      in drm_mm_node, subtree_max_hole. Each drm_mm_node now stores maximum
      hole size for its subtree in drm_mm_node->subtree_max_hole. Using
      drm_mm_node->subtree_max_hole, it is possible to eliminate a complete
      subtree if that subtree is unable to serve a request hence reducing
      number of rb_prev()/rb_next() used.
      
      With this patch applied, 1 million bo allocs on amdgpu took ~8 sec,
      compared to 50k bo allocs which took 28 sec without it.
      
      partial test code:
      int test_fragmentation(void)
      {
      
      	int i = 0;
              uint32_t  minor_version;
              uint32_t  major_version;
      
              struct amdgpu_bo_alloc_request request = {};
              amdgpu_bo_handle vram_handle[MAX_ALLOC] = {};
              amdgpu_device_handle device_handle;
      
              request.alloc_size = 4096;
              request.phys_alignment = 8192;
              request.preferred_heap = AMDGPU_GEM_DOMAIN_VRAM;
      
              int fd = open("/dev/dri/card0", O_RDWR | O_CLOEXEC);
              amdgpu_device_initialize(fd, &major_version,  &minor_version,
      				 &device_handle);
      
              for (i = 0; i < MAX_ALLOC; i++) {
                      amdgpu_bo_alloc(device_handle, &request, &vram_handle[i]);
              }
      
              for (i = 0; i < MAX_ALLOC; i++)
                      amdgpu_bo_free(vram_handle[i]);
      
              return 0;
      }
      
      v2:
      Use RB_DECLARE_CALLBACKS_MAX to maintain subtree_max_hole
      v3:
      insert_hole_addr() should be static a function
      fix return value of next_hole_high_addr()/next_hole_low_addr()
      Reported-by: default avatarkbuild test robot <lkp@intel.com>
      v4:
      Fix commit message.
      Signed-off-by: default avatarNirmoy Das <nirmoy.das@amd.com>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Acked-by: default avatarChristian König <christian.koenig@amd.com>
      Link: https://patchwork.freedesktop.org/patch/364341/Signed-off-by: default avatarChristian König <christian.koenig@amd.com>
      0cdea445