1. 17 Sep, 2020 11 commits
  2. 16 Sep, 2020 8 commits
  3. 15 Sep, 2020 14 commits
  4. 14 Sep, 2020 7 commits
    • Paul Cercueil's avatar
      gpu/drm: ingenic: Add option to mmap GEM buffers cached · 37054fc8
      Paul Cercueil authored
      Ingenic SoCs are most notably used in cheap chinese handheld gaming
      consoles. There, the games and applications generally render in software
      directly into GEM buffers.
      
      Traditionally, GEM buffers are mapped write-combine. Writes to the
      buffer are accelerated, and reads are slow. Application doing lots of
      alpha-blending paint inside shadow buffers, which is then memcpy'd into
      the final GEM buffer.
      
      On recent Ingenic SoCs however, it is much faster to have a fully cached
      GEM buffer, in which applications paint directly, and whose data is
      invalidated before scanout, than having a write-combine GEM buffer, even
      when alpha blending is not used.
      
      Add an optional 'cached_gem_buffers' parameter to the ingenic-drm driver
      to allow GEM buffers to be mapped fully-cached, in order to speed up
      software rendering.
      
      v2: Use standard noncoherent DMA APIs
      
      v3: Use damage clips instead of invalidating full frames
      
      v4: Avoid dma_pgprot() which is not exported. Using vm_get_page_prot()
          is enough in this case.
      
      v5:
      - Avoid calling drm_gem_cma_prime_mmap(). It has the side effect that an
        extra object reference is obtained, which causes our dumb buffers to
        never be freed. It should have been drm_gem_cma_mmap_obj(). However,
        our custom mmap function only differs with one flag, so we can cleanly
        handle both modes in ingenic_drm_gem_mmap().
      - Call drm_gem_vm_close() if drm_mmap_attrs() failed, just like in
        drm_gem_cma_mmap_obj().
      Signed-off-by: default avatarPaul Cercueil <paul@crapouillou.net>
      Acked-by: default avatarSam Ravnborg <sam@ravnborg.org>
      Link: https://patchwork.freedesktop.org/patch/msgid/20200912195639.176001-1-paul@crapouillou.net
      37054fc8
    • Ville Syrjälä's avatar
      drm/i915: Drop the drm_atomic_helper_calc_timestamping_constants() call · 79628c54
      Ville Syrjälä authored
      We update the timestamping constants per-crtc explicitly in
      intel_crtc_update_active_timings(). Furtermore the helper will
      use uapi.adjusted_mode whereas we want hw.adjusted_mode. Thus
      let's drop the helper call an rely on what we already have in
      intel_crtc_update_active_timings(). We can now also drop the
      hw.adjusted_mode -> uapi.adjusted_mode copy hack that was added
      to keep the helper from deriving the timestamping constants from
      the wrong thing.
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20200907120026.6360-3-ville.syrjala@linux.intel.comReviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      79628c54
    • Ville Syrjälä's avatar
      drm/atomic-helper: Remove the timestamping constant update from... · 441959eb
      Ville Syrjälä authored
      drm/atomic-helper: Remove the timestamping constant update from drm_atomic_helper_update_legacy_modeset_state()
      
      The timestamping constants have nothing to do with any legacy state
      so should not be updated from
      drm_atomic_helper_update_legacy_modeset_state().
      
      Let's make everyone call drm_atomic_helper_calc_timestamping_constants()
      directly instead of relying on
      drm_atomic_helper_update_legacy_modeset_state() to call it.
      
      @@
      expression S;
      @@
      - drm_atomic_helper_calc_timestamping_constants(S);
      
      @@
      expression D, S;
      @@
        drm_atomic_helper_update_legacy_modeset_state(D, S);
      + drm_atomic_helper_calc_timestamping_constants(S);
      
      v2: Update drm_crtc_vblank_helper_get_vblank_timestamp{,_internal}() docs (Daniel)
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20200907120026.6360-2-ville.syrjala@linux.intel.comReviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      441959eb
    • Ville Syrjälä's avatar
      drm/atomic-helper: Extract drm_atomic_helper_calc_timestamping_constants() · 4b31a9c7
      Ville Syrjälä authored
      Put the vblank timestamping constants update loop into its own
      function. It has no business living inside
      drm_atomic_helper_update_legacy_modeset_state() so we'll be wanting
      to move it out entirely. As a first step we'll still call it
      from drm_atomic_helper_update_legacy_modeset_state().
      
      v2: Drop comment about 'legacy state' in the new function
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20200907120026.6360-1-ville.syrjala@linux.intel.comReviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      4b31a9c7
    • Maxime Ripard's avatar
      Merge drm/drm-next into drm-misc-next · 00af6729
      Maxime Ripard authored
      Paul Cercueil needs some patches in -rc5 to apply new patches for ingenic
      properly.
      Signed-off-by: default avatarMaxime Ripard <maxime@cerno.tech>
      00af6729
    • Daniel Vetter's avatar
      Merge v5.9-rc5 into drm-next · 818280d5
      Daniel Vetter authored
      Paul needs 1a21e5b9 ("drm/ingenic: Fix leak of device_node
      pointer") and 3b5b005e ("drm/ingenic: Fix driver not probing when
      IPU port is missing") from -fixes to be able to merge further ingenic
      patches into -next.
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      818280d5
    • Jia Yang's avatar
      drm: fix double free for gbo in drm_gem_vram_init and drm_gem_vram_create · da62cb72
      Jia Yang authored
      I got a use-after-free report when doing some fuzz test:
      
      If ttm_bo_init() fails, the "gbo" and "gbo->bo.base" will be
      freed by ttm_buffer_object_destroy() in ttm_bo_init(). But
      then drm_gem_vram_create() and drm_gem_vram_init() will free
      "gbo" and "gbo->bo.base" again.
      
      BUG: KMSAN: use-after-free in drm_vma_offset_remove+0xb3/0x150
      CPU: 0 PID: 24282 Comm: syz-executor.1 Tainted: G    B   W         5.7.0-rc4-msan #2
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
      Call Trace:
       __dump_stack
       dump_stack+0x1c9/0x220
       kmsan_report+0xf7/0x1e0
       __msan_warning+0x58/0xa0
       drm_vma_offset_remove+0xb3/0x150
       drm_gem_free_mmap_offset
       drm_gem_object_release+0x159/0x180
       drm_gem_vram_init
       drm_gem_vram_create+0x7c5/0x990
       drm_gem_vram_fill_create_dumb
       drm_gem_vram_driver_dumb_create+0x238/0x590
       drm_mode_create_dumb
       drm_mode_create_dumb_ioctl+0x41d/0x450
       drm_ioctl_kernel+0x5a4/0x710
       drm_ioctl+0xc6f/0x1240
       vfs_ioctl
       ksys_ioctl
       __do_sys_ioctl
       __se_sys_ioctl+0x2e9/0x410
       __x64_sys_ioctl+0x4a/0x70
       do_syscall_64+0xb8/0x160
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      RIP: 0033:0x4689b9
      Code: fd e0 fa ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 cb e0 fa ff c3 66 2e 0f 1f 84 00 00 00 00
      RSP: 002b:00007f368fa4dc98 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
      RAX: ffffffffffffffda RBX: 000000000076bf00 RCX: 00000000004689b9
      RDX: 0000000020000240 RSI: 00000000c02064b2 RDI: 0000000000000003
      RBP: 0000000000000004 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
      R13: 00000000004d17e0 R14: 00007f368fa4e6d4 R15: 000000000076bf0c
      
      Uninit was created at:
       kmsan_save_stack_with_flags
       kmsan_internal_poison_shadow+0x66/0xd0
       kmsan_slab_free+0x6e/0xb0
       slab_free_freelist_hook
       slab_free
       kfree+0x571/0x30a0
       drm_gem_vram_destroy
       ttm_buffer_object_destroy+0xc8/0x130
       ttm_bo_release
       kref_put
       ttm_bo_put+0x117d/0x23e0
       ttm_bo_init_reserved+0x11c0/0x11d0
       ttm_bo_init+0x289/0x3f0
       drm_gem_vram_init
       drm_gem_vram_create+0x775/0x990
       drm_gem_vram_fill_create_dumb
       drm_gem_vram_driver_dumb_create+0x238/0x590
       drm_mode_create_dumb
       drm_mode_create_dumb_ioctl+0x41d/0x450
       drm_ioctl_kernel+0x5a4/0x710
       drm_ioctl+0xc6f/0x1240
       vfs_ioctl
       ksys_ioctl
       __do_sys_ioctl
       __se_sys_ioctl+0x2e9/0x410
       __x64_sys_ioctl+0x4a/0x70
       do_syscall_64+0xb8/0x160
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      If ttm_bo_init() fails, the "gbo" will be freed by
      ttm_buffer_object_destroy() in ttm_bo_init(). But then
      drm_gem_vram_create() and drm_gem_vram_init() will free
      "gbo" again.
      Reported-by: default avatarHulk Robot <hulkci@huawei.com>
      Reported-by: default avatarbutt3rflyh4ck <butterflyhuangxx@gmail.com>
      Signed-off-by: default avatarJia Yang <jiayang5@huawei.com>
      Signed-off-by: default avatarThomas Zimmermann <tzimmermann@suse.de>
      Reviewed-by: default avatarThomas Zimmermann <tzimmermann@suse.de>
      Link: https://patchwork.freedesktop.org/patch/msgid/20200714083238.28479-2-tzimmermann@suse.de
      da62cb72