Most drivers that use VRAM helpers have only a few MiB of framebuffer
memory available. To reduce fragmentation, new BOs are now put into
system memory by default. Only pin operations are allowed to move BOs
into VRAM.

v2:
	* rebased onto latest drm-tip
Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20200922145700.25413-4-tzimmermann@suse.de

Don't override the GEM object functions unconditionally. If the driver
sets the GEM functions, VRAM helpers will not set them. The idea has been
taken from SHMEM helpers.

v2:
	* updated the commit message (Sam)
	* document the new feature for drm_gem_vram_create()
Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20200922145700.25413-3-tzimmermann@suse.de

The drm_gem_vram_create() function is the only caller of the internal
helper drm_gem_vram_init(). Streamline the code by putting all code into
the create function.

v2:
	* rebased onto latest drm-tip
	* fixed typo in commit message (Sam)
Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: NSam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200922145700.25413-2-tzimmermann@suse.de

Stop using TTM_PL_FLAG_NO_EVICT.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Acked-by: NThomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: NDave Airlie <airlied@redhat.com>
Reviewed-by: NHuang Rui <ray.huang@amd.com>
Link: https://patchwork.freedesktop.org/patch/391603/?series=81973&rev=1

Commit 7053e0ea ("drm/vram-helper: stop using TTM placement flags")
cleared the BO placement flags if top-down placement had been selected.
Hence, BOs that were supposed to go into VRAM are now placed in a default
location in system memory.

Trying to scanout the incorrectly pinned BO results in displayed garbage
and an error message.

[  146.108127] ------------[ cut here ]------------
[  146.1V08180] WARNING: CPU: 0 PID: 152 at drivers/gpu/drm/drm_gem_vram_helper.c:284 drm_gem_vram_offset+0x59/0x60 [drm_vram_helper]
...
[  146.108591]  ast_cursor_page_flip+0x3e/0x150 [ast]
[  146.108622]  ast_cursor_plane_helper_atomic_update+0x8a/0xc0 [ast]
[  146.108654]  drm_atomic_helper_commit_planes+0x197/0x4c0
[  146.108699]  drm_atomic_helper_commit_tail_rpm+0x59/0xa0
[  146.108718]  commit_tail+0x103/0x1c0
...
[  146.109302] ---[ end trace d901a1ba1d949036 ]---

Fix the bug by keeping the placement flags. The top-down placement flag
is stored in a separate variable.
Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Fixes: 7053e0ea ("drm/vram-helper: stop using TTM placement flags")
Cc: Christian König <christian.koenig@amd.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: dri-devel@lists.freedesktop.org
Link: https://patchwork.freedesktop.org/patch/msgid/20200921142536.4392-1-tzimmermann@suse.de

Call the driver first and have it call the common code cleanup.

This is useful later to fix unbind.
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200917043040.146575-3-airlied@gmail.com

Instead of letting TTM make an educated guess based on
some mask all drivers should just specify what caching
they want for their CPU mappings.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NDave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/390207/

As far as I can tell this was never used either and we just
always fallback to the order cached > wc > uncached anyway.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NDave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/390142/

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: NHulk Robot <hulkci@huawei.com>
Reported-by: Nbutt3rflyh4ck <butterflyhuangxx@gmail.com>
Signed-off-by: NJia Yang <jiayang5@huawei.com>
Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: NThomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20200714083238.28479-2-tzimmermann@suse.de

VRAM helpers support ref counting for pin and vmap operations, no need
to avoid these operations by employing the internal kmap interface. Just
use drm_gem_vram_vmap() and let it handle the details.

Also unexport the kmap interfaces from VRAM helpers. Vboxvideo was the
last user of these internal functions.

v2:
	* fixed a comma in commit description
Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Tested-by: NHans de Goede <hdegoede@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200911075922.19317-1-tzimmermann@suse.de

It's not supported to specify more than one of those flags.
So it never made sense to make this a flag in the first place.

Nuke the flags and specify directly which memory type to use.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NDave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/389826/?series=81551&rev=1

Those are going to be removed, stop using them here.

Instead define separate flags for the helper.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NDave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/389823/?series=81551&rev=1

Acked-by: NThomas Zimmermann <tzimmermann@suse.de>
Acked-by: NChristian König <christian.koenig@amd.com>
Acked-by: NBen Skeggs <bskeggs@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200907204630.1406528-10-airlied@gmail.com

This is used by TTM to communicate the physical address
which should be used with ioremap(), ioremap_wc(). We don't
need to separate the base and offset in any way here.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NDave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/389457/

I want to split this structure up and use it differently,
step one remove bdev pointer from it and pass it explicitly.
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200826014428.828392-4-airlied@gmail.com

The drivers all do the same thing here.

Reviewed-by: Christian König <christian.koenig@amd.com> for both.
Signed-off-by: NDave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200811074658.58309-1-airlied@gmail.com

This name better reflects what the object does. I didn't rename
all the pointers it seemed too messy.
Signed-off-by: NDave Airlie <airlied@redhat.com>
Acked-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NBen Skeggs <bskeggs@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200804025632.3868079-60-airlied@gmail.com

This name makes a lot more sense, since these are about managing
driver resources rather than just memory ranges.
Acked-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NBen Skeggs <bskeggs@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200804025632.3868079-59-airlied@gmail.com

This makes it easier to move these to a driver allocated system
Reviewed-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NBen Skeggs <bskeggs@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200804025632.3868079-47-airlied@gmail.com

Reviewed-by: NThomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: NDave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200804025632.3868079-39-airlied@gmail.com

Reviewed-by: NThomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: NDave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200804025632.3868079-30-airlied@gmail.com

Reviewed-by: NThomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: NGerd Hoffmann <kraxel@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200804025632.3868079-19-airlied@gmail.com

This code was assuming there was a drm_mm here, don't do
that call the correct API.

v2: use the new exported interface.
Reviewed-by: NThomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: NGerd Hoffmann <kraxel@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200804025632.3868079-13-airlied@gmail.com

The default path for populate/unpopulate is already this.
Reviewed-by: NThomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: NDave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200804025632.3868079-8-airlied@gmail.com

It is a very strange concept to call a function which just
calls back the caller for the functions parameters.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NThomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Link: https://patchwork.freedesktop.org/patch/382085/

Instead just initialize the memory type parameters
before calling ttm_bo_init_mm.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NThomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Link: https://patchwork.freedesktop.org/patch/382086/

Instead use a boolean field in the memory manager structure.

Also invert the meaning of the field since the use of a TT
structure is the special case here.

v2: cleanup zero init.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NThomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Link: https://patchwork.freedesktop.org/patch/382079/

Instead of repeating that in each driver.

v2: keep the caching limitation for VMWGFX for now.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: NThomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/382078/

Implementing those is completely unnecessary.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NMadhav Chauhan <madhav.chauhan@amd.com>
Link: https://patchwork.freedesktop.org/patch/378236/

The helper doesn't expose any not-mapable memory resources.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NThomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/377649/

Calling drmm_vram_helper_init() sets up a managed instance of
VRAM MM. Releasing the DRM device also frees the memory manager.

The patch also updates the DRM documentation for VRAM helpers. The
tutorial now describes the new managed interface. The old interfaces
are deprecated and should not be used in new code.

v2:
	* rename init function to drmm_vram_helper_init()
	* return errno code from init function; caller does not
	  need vram_mm anyway
	* update documentation and remove docs for deprecated
	  un-managed functions
Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: NSam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200716125353.31512-2-tzimmermann@suse.de

Calculate GEM VRAM bo's offset within vram-helper without depending on
bo->offset.
Signed-off-by: NNirmoy Das <nirmoy.das@amd.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NChristian König <christian.koenig@amd.com>
Link: https://patchwork.freedesktop.org/patch/372938/

Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.

Just drop the suffix. It makes the API cleaner.

Done via the following script:

__from=drm_gem_object_put_unlocked
__to=drm_gem_object_put
for __file in $(git grep --name-only $__from); do
  sed -i  "s/$__from/$__to/g" $__file;
done

Pay special attention to the compat #define

v2: keep sed and #define removal separate

Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: NEmil Velikov <emil.velikov@collabora.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org> (v1)
Reviewed-by: NSteven Price <steven.price@arm.com>
Acked-by: NThomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20200515095118.2743122-14-emil.l.velikov@gmail.com

Most of the documentation was in an otherwise empty file, which was
probably just left from a previous clean-up effort. So move code and
documentation into a single file.
Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
Acked-by: NGerd Hoffmann <kraxel@redhat.com>
Acked-by: NSam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200331081238.24749-1-tzimmermann@suse.de

Calling the VRAM helper's prepare_fb() helper now sets the plane's
fence object. This will be useful for PRIME support. VRAM helpers
don't support buffer sharing ATM, so for now there are no drivers
requiring this change.

v2:
	* removed a TODO comment about buffer synchronization
Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20200331092740.29282-1-tzimmermann@suse.de

Remove unneeded #if/#endif guards for checking whether the
CONFIG_DEBUG_FS option is set or not. If the option is not set, the
compiler optimizes the functions making the guards
unnecessary.
Signed-off-by: NWambui Karuga <wambui.karugax@gmail.com>
Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20200323112802.228214-1-wambui.karugax@gmail.com

As a result of commit 987d65d0 (drm: debugfs: make
drm_debugfs_create_files() never fail) and changes to various debugfs
functions in drm/core and across various drivers, there is no need for
the drm_driver.debugfs_init() hook to have a return value. Therefore,
declare it as void.

This also includes refactoring all users of the .debugfs_init() hook to
return void across the subsystem.

v2: include changes to the hook and drivers that use it in one patch to
prevent driver breakage and enable individual successful compilation of
this change.

References: https://lists.freedesktop.org/archives/dri-devel/2020-February/257183.htmlSigned-off-by: NWambui Karuga <wambui.karugax@gmail.com>
Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20200310133121.27913-18-wambui.karugax@gmail.com

Since 987d65d0 (drm: debugfs: make
drm_debugfs_create_files() never fail), drm_debugfs_create_files() never
fails and should return void. Therefore, remove its use as the
return value of drm_vram_mm_debugfs_init(), and have the function
return 0 directly.

v2: have drm_vram_mm_debugfs_init() return 0 instead of void to avoid
introducing build issues and build breakage.

References: https://lists.freedesktop.org/archives/dri-devel/2020-February/257183.htmlSigned-off-by: NWambui Karuga <wambui.karugax@gmail.com>
Acked-by: NThomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20200310133121.27913-11-wambui.karugax@gmail.com

Devices with low amount of dedicated video memory may not be able
to use all possible display modes, as the framebuffers may not fit
into VRAM. The new helper function drm_vram_helper_mode_valid()
implements a simple test to sort out all display modes that can
not be used in any case. Drivers should call this function from
struct drm_mode_config_funcs.mode_valid.

The functionality was originally implemented by the ast driver, which
is being converted as well.

v2:
	* WARN_ON if VRAM memory manager has not been initialized
	* documentation fixes
	* unexported drm_vram_helper_mode_valid_internal()
Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20200203155258.9346-2-tzimmermann@suse.de

Drivers that what to allocate VRAM GEM objects with additional fields
can now do this by implementing struct drm_driver.gem_create_object.

v3:
	* separately check allocation failure in if/else branches
	  before upcast to gbo
v2:
	* only cast to gbo within if branch; set gbo directly
	  in else branch
Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: NSam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200106125745.13797-9-tzimmermann@suse.de