- 10 Dec, 2021 3 commits
-
-
Kevin Tang authored
DPU (Display Processor Unit) is the Display Controller for the Unisoc SoCs which transfers the image data from a video memory buffer to an internal LCD interface. Cc: Orson Zhai <orsonzhai@gmail.com> Cc: Chunyan Zhang <zhang.lyra@gmail.com> Signed-off-by:
Kevin Tang <kevin.tang@unisoc.com> Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211207142717.30296-4-kevin3.tang@gmail.com
-
Kevin Tang authored
Adds drm support for the Unisoc's display subsystem. This is drm kms driver, this driver provides support for the application framework in Android, Yocto and more. Application framework can access Unisoc's display internal peripherals through libdrm or libkms, it's test ok by modetest (DRM/KMS test tool) and Android HWComposer. v4: - Move the devm_drm_dev_alloc to master_ops->bind function. - The managed drmm_mode_config_init() it is no longer necessary for drivers to explicitly call drm_mode_config_cleanup, so delete it. v5: - Remove subdir-ccflgas-y for Makefile. - Keep the selects sorted by alphabet for Kconfig. Cc: Orson Zhai <orsonzhai@gmail.com> Cc: Chunyan Zhang <zhang.lyra@gmail.com> Signed-off-by:
-
Kevin Tang authored
The Unisoc DRM master device is a virtual device needed to list all DPU devices or other display interface nodes that comprise the graphics subsystem Unisoc's display pipeline have several components as below description, multi display controllers and corresponding physical interfaces. For different display scenarios, dpu0 and dpu1 maybe binding to different encoder. E.g: dpu0 and dpu1 both binding to DSI for dual mipi-dsi display; dpu0 binding to DSI for primary display, and dpu1 binding to DP for external display; Cc: Orson Zhai <orsonzhai@gmail.com> Cc: Chunyan Zhang <zhang.lyra@gmail.com> Signed-off-by:
-
- 09 Dec, 2021 14 commits
-
-
Zack Rusin authored
v2: Old userspace doesn't like 3.x.x and we'd like to keep it working, so lets just bump the minor version until we have no choice. With GEM, GL4.3, stats and removal of a lot of old code it's time to bump the minor version of the driver. Signed-off-by:
Zack Rusin <zackr@vmware.com> Reviewed-by:
Martin Krastev <krastevm@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211209024924.3298137-1-zack@kde.org
-
Zack Rusin authored
Using MOBFMT_RANGE in the early days of guest backed objects was a major performance win but that has changed a lot since. There's no more a performance reason to use MOBFMT_RANGE. The device can/will still profit from the pages being contiguous but marking them as MOBFMT_RANGE no longer matters. Benchmarks (e.g. heaven, valley) show that creating page tables for mob memory is actually faster than using mobfmt ranges. Signed-off-by:
-
Roland Scheidegger authored
This adds support for the SVGA_3D_CMD_DX_SET_VS/PS/GS/HS/DS/CS_CONSTANT_BUFFER_OFFSET commands (which only update the offset, but don't rebind the buffer), which saves some overhead. Signed-off-by:
Roland Scheidegger <sroland@vmware.com> Reviewed-by:
Charmaine Lee <charmainel@vmware.com> Reviewed-by:
-
Zack Rusin authored
To make sure we're running on top of hardware that can support GL4.3 we need to add a way of querying for those capabilities. DRM_VMW_PARAM_GL43 allows userspace to check for presence of GL4.3 capable contexts. Signed-off-by:
-
Zack Rusin authored
If the host supports SVGA3D_DEVCAP_GL43, we can handle 64 instead of just 8 UAVs. Based on a patch from Roland Scheidegger <sroland@vmware.com>. Signed-off-by:
-
Roland Scheidegger authored
This is going to be required for setting the sample count when rendering with no attachments. Also cleans up view handling (should fix depthstencil_v2). Reviewed-by:
-
Zack Rusin authored
Update the headers for GL43 userspace works that landed in Mesa3D. Also update the license headers to conform to the kernel guidelines. For GL43 the virtual device got D3D11.1 support with some GL extensions. Signed-off-by:
-
Zack Rusin authored
The fb handle code assumes it deals with GEM objects. Because vmwgfx buffer objects were not actually GEM objects we were not able to implement that interface. Now that vmwgfx supports GEM buffer objects we can trivially implement create_handle for buffer object backed framebuffers. Among others this gets IGT's kms_getfb test passing. Signed-off-by:
-
Zack Rusin authored
This is initial change adding support for DRIVER_GEM to vmwgfx. vmwgfx was written before GEM and has always used TTM. Over the years the TTM buffers started inherting from GEM objects but vmwgfx never implemented GEM making it quite awkward. We were directly setting variables in GEM objects to not make DRM crash. This change brings vmwgfx inline with other DRM drivers and allows us to use a lot of DRM helpers which have depended on drivers with GEM support. Due to historical reasons vmwgfx splits the idea of a buffer and surface which makes it a littly tricky since either one can be used in most of our ioctl's which take user space handles. For now our BO's are GEM objects and our surfaces are opaque objects which are backed by GEM objects. In the future I'd like to combine those into a single BO but we don't want to break any of our existing ioctl's so it will take time to do it in a non-destructive way. Signed-off-by:
-
Zack Rusin authored
Instead of hardcoding the VMware's PCI ID the code should be using the public define for it. There's no functional change, it just makes it obvious what we're dealing with. Signed-off-by:
-
Zack Rusin authored
Mob/GMR id resource manager was lacking the debug print callback which meant that during memory errors we weren't getting the details which are needed to fix those errors. Kernel logs need to contain the information about used/max pages by the Mob/GMR id resource manager as well as the maximum number of id's they're allowed to allocate. Signed-off-by:
-
Zack Rusin authored
vmwgfx shared very elaborate memory accounting with ttm. It was moved from ttm to vmwgfx in change f07069da ("drm/ttm: move memory accounting into vmwgfx v4") but because of complexity it was hard to maintain. Some parts of the code weren't freeing memory correctly and some were missing accounting all together. While those would be fairly easy to fix the fundamental reason for memory accounting in the driver was the ability to invoke shrinker which is part of TTM code as well (with support for unified memory hopefully coming soon). That meant that vmwgfx had a lot of code that was either unused or duplicating code from TTM. Removing this code also prevents excessive calls to global swapout which were common during memory pressure because both vmwgfx and TTM would invoke the shrinker when memory usage reached half of RAM. Fixes: f07069da ("drm/ttm: move memory accounting into vmwgfx v4") Signed-off-by:
-
Christian König authored
The runtime PM get was incorrectly added after the check. Signed-off-by:
Christian König <christian.koenig@amd.com> Acked-by:
Evan Quan <evan.quan@amd.com> Acked-by:
Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211206084551.92502-1-christian.koenig@amd.com
-
Andy Shevchenko authored
When kernel.h is used in the headers it adds a lot into dependency hell, especially when there are circular dependencies are involved. Replace kernel.h inclusion with the list of what is really being used. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20211110102423.54282-1-andriy.shevchenko@linux.intel.com
-
- 08 Dec, 2021 12 commits
-
-
Rob Clark authored
Otherwise we don't get another shot at it if the bridge probes before the dsi host is registered. It seems like this is what *most* (but not all) of the other bridges do. It looks like this was missed in the conversion to attach dsi host at probe time. Fixes: c3b75d47 ("drm/bridge: sn65dsi86: Register and attach our DSI device at probe") Signed-off-by:
Rob Clark <robdclark@chromium.org> Reviewed-by:
Doug Anderson <dianders@chromium.org> Tested-by:
Stephen Boyd <swboyd@chromium.org> [dianders: squashed in Stephen's simplification] Signed-off-by:
-
Arnd Bergmann authored
Using the SET_RUNTIME_PM_OPS() macro causes a warning about the referenced functions when they are marked static but not __maybe_unused: drivers/gpu/drm/omapdrm/dss/dss.c:1572:12: error: unused function 'dss_runtime_suspend' [-Werror,-Wunused-function] drivers/gpu/drm/omapdrm/dss/dss.c:1584:12: error: unused function 'dss_runtime_resume' [-Werror,-Wunused-function] drivers/gpu/drm/omapdrm/dss/dispc.c:4845:12: error: unused function 'dispc_runtime_suspend' [-Werror,-Wunused-function] drivers/gpu/drm/omapdrm/dss/dispc.c:4860:12: error: unused function 'dispc_runtime_resume' [-Werror,-Wunused-function] Fixes: b92f7ea5 ("drm/omap: dss: Make use of the helper macro SET_RUNTIME_PM_OPS()") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by:
Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by:
-
Benoit Parrot authored
If the drm_plane has a source width that's greater than the max width supported by a single hw overlay, then we assign a 'r_overlay' to it in omap_plane_atomic_check(). Both overlays should have the capabilities required to handle the source framebuffer. The only parameters that vary between the left and right hwoverlays are the src_w, crtc_w, src_x and crtc_x as we just even chop the fb into left and right halves. We also take care of not creating odd width size when dealing with YUV formats. Since both halves need to be 'appear' side by side the zpos is recalculated when dealing with dual overlay cases so that the other planes zpos is consistent. Depending on user space usage it is possible that on occasion the number of requested planes exceeds the numbers of overlays required to display them. In that case a failure would be returned for the plane that cannot be handled at that time. It is up to user space to make sure the H/W resource are not over-subscribed. Signed-off-by:
Benoit Parrot <bparrot@ti.com> Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Reviewed-by:
-
Benoit Parrot authored
Now that we added specific item to our subclassed drm_plane_state we can add omap_plane_atomic_print_state() helper to dump out our own driver specific plane state. Signed-off-by:
-
Benoit Parrot authored
(re)assign the hw overlays to planes based on required caps, and to handle situations where we could not modify an in-use plane. This means all planes advertise the superset of formats and properties. Userspace must (as always) use atomic TEST_ONLY step for atomic updates, as not all planes may be available for use on every frame. The mapping of hwoverlays to plane is stored in omap_global_state, so that state updates are atomically committed in the same way that plane/etc state updates are managed. This is needed because the omap_plane_state keeps a pointer to the hwoverlay, and we don't want global state to become out of sync with the plane state if an atomic update fails, we hit deadlock/ backoff scenario, etc. The use of global_state_lock keeps multiple parallel updates which both re-assign hwoverlays properly serialized. Signed-off-by:
-
Benoit Parrot authored
Global shared resources (like hw overlays) for omapdrm are implemented as a part of atomic state using the drm_private_obj infrastructure available in the atomic core. omap_global_state is introduced as a drm atomic private object. The two funcs omap_get_global_state() and omap_get_existing_global_state() are the two variants that will be used to access omap_global_state. drm_mode_config_init() needs to be called earlier because it creates/initializes the private_obj link list maintained by the atomic framework. The private_obj link list has to exist prior to calling drm_atomic_private_obj_init(). Similarly the cleanup handler are reordered appropriately. Signed-off-by:
-
Benoit Parrot authored
In preparation to add omap plane state specific extensions we need to subclass drm_plane_state and add the relevant helpers. The addition of specific extension will be done separately. Signed-off-by:
-
Benoit Parrot authored
Split out the hardware overlay specifics from omap_plane. To start, the hw overlays are statically assigned to planes. The goal is to eventually assign hw overlays dynamically to planes during plane->atomic_check() based on requested caps (scaling, YUV, etc). And then perform hw overlay re-assignment if required. Signed-off-by:
-
Benoit Parrot authored
In order to be able to dynamically assign overlays to planes we need to be able to asses the overlay capabilities. Add a helper function to be able to retrieve the supported capabilities of an overlay. And export the function to check if a fourcc is supported on a given overlay. Signed-off-by:
-
Benoit Parrot authored
We currently assume that an overlay has the same maximum width and maximum height as the overlay manager. This assumption is incorrect. On some variants the overlay manager maximum width is twice the maximum width that the overlay can handle. We need to add the appropriate data per variant as well as export a helper function to retrieve the data so check can be made dynamically in omap_plane_atomic_check(). Signed-off-by:
-
Neil Armstrong authored
Call drm_atomic_helper_check_plane_state() from the plane atomic_check() callback in order to add plane state sanity checking. It will permit filtering out totally bad scaling factors, even if the real check are done later in the atomic commit. Calling drm_atomic_helper_check_plane_state() also sets plane_state->visible which will be useful when dynamically assigning hw overlays to planes. Signed-off-by:
-
Ivaylo Dimitrov authored
Memory of BOs backed by TILER is not contiguous, but omap_gem_map_dma_buf() exports it like it is. This leads to (possibly) invalid memory accesses if another device imports such a BO. Fix that by providing sg that correctly describes TILER memory layout. Align TILER allocations to page, so importer to be able to correctly set its MMU if have one. Set export size accounting for the alignment. Also, make sure to destroy sg on unpin, as it is no longer valid. Tested on Motorola Droid4 by using GPU (sgx540) to render. Suggested-by:
Matthijs van Duin <matthijsvanduin@gmail.com> Signed-off-by:
Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com> Reviewed-by:
-
- 07 Dec, 2021 4 commits
-
-
Douglas Anderson authored
When we added the support for the AUX channel in commit 13afcdd7 ("drm/bridge: parade-ps8640: Add support for AUX channel") we forgot to set "drm_dev" to avoid the warning splat at the beginning of drm_dp_aux_register(). Since everything was working I guess I never noticed the splat when testing against mainline. In any case, it's easy to fix. This is basically just like commit 6cba3fe4 ("drm/dp: Add backpointer to drm_device in drm_dp_aux") but just for the parade-ps8640. Fixes: 13afcdd7 ("drm/bridge: parade-ps8640: Add support for AUX channel") Signed-off-by:
Philip Chen <philipchen@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20211206162907.1.I1f5d1eba741e4663050ec1b8e39a753f6e42e38b@changeid
-
yangcong authored
At present, we have enough panel to confirm the effect, update the initial code to achieve the best effect. Such as gamma, Gop timing. They are all minor modifications and doesn't affect the lighting of the panel. a)Boe-tv110c9m panel Optimized touch horizontal grain. b)Inx-hj110iz panel Optimized GOP timing and gamma. Signed-off-by:
yangcong <yangcong5@huaqin.corp-partner.google.com> Reviewed-by:
-
John Keeping authored
Allow drm_fbdev_generic_setup() to pick the default bpp value for the framebuffer. This has no functional impact because the default is 32, given that mode_config.preferred_depth is not set for Rockchip. Suggested-by:
John Keeping <john@metanate.com> Signed-off-by:
-
John Keeping authored
The Rockchip fbdev code does not add anything compared to drm_fbdev_generic_setup(); the one custom function for .fb_mmap does the same thing as gem_prime_mmap which is called by the helper. Signed-off-by:
-
- 06 Dec, 2021 2 commits
-
-
Arnd Bergmann authored
The aspeed driver uses the gem_cma_helper code, but does noto enforce enabling this through Kconfig: x86_64-linux-ld: drivers/gpu/drm/aspeed/aspeed_gfx_drv.o:(.rodata+0x2c8): undefined reference to `drm_gem_cma_prime_import_sg_table' x86_64-linux-ld: drivers/gpu/drm/aspeed/aspeed_gfx_drv.o:(.rodata+0x2d8): undefined reference to `drm_gem_cma_dumb_create' x86_64-linux-ld: drivers/gpu/drm/aspeed/aspeed_gfx_crtc.o: in function `aspeed_gfx_pipe_update': aspeed_gfx_crtc.c:(.text+0xe5): undefined reference to `drm_fb_cma_get_gem_obj' Add the same 'select' that is used in other such drivers. Fixes: 09717af7 ("drm: Remove CONFIG_DRM_KMS_CMA_HELPER option") Signed-off-by:
-
Arnd Bergmann authored
The fsl-dcu driver uses the gem_cma_helper code, but does noto enforce enabling this through Kconfig: arm-linux-gnueabi-ld: drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.o:(.rodata+0x32c): undefined reference to `drm_gem_cma_prime_import_sg_table' arm-linux-gnueabi-ld: drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.o:(.rodata+0x334): undefined reference to `drm_gem_cma_dumb_create' arm-linux-gnueabi-ld: drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.o: in function `fsl_dcu_drm_plane_atomic_update': fsl_dcu_drm_plane.c:(.text+0x144): undefined reference to `drm_fb_cma_get_gem_obj' Add the same 'select' that is used in other such drivers. Fixes: 09717af7 ("drm: Remove CONFIG_DRM_KMS_CMA_HELPER option") Signed-off-by:
-
- 02 Dec, 2021 1 commit
-
-
Thomas Zimmermann authored
GEM helper libraries use struct drm_driver.gem_create_object to let drivers override GEM object allocation. On failure, the call returns NULL. Change the semantics to make the calls return a pointer-encoded error. This aligns the callback with its callers. Fixes the ingenic driver, which already returns an error pointer. Also update the callers to handle the involved types more strictly. Signed-off-by:
Steven Price <steven.price@arm.com> Acked-by:
Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20211130095255.26710-1-tzimmermann@suse.de
-
- 01 Dec, 2021 4 commits
-
-
Zack Rusin authored
TTM takes full control over TTM_PL_SYSTEM placed buffers. This makes driver internal usage of TTM_PL_SYSTEM prone to errors because it requires the drivers to manually handle all interactions between TTM which can swap out those buffers whenever it thinks it's the right thing to do and driver. CPU buffers which need to be fenced and shared with accelerators should be placed in driver specific placements that can explicitly handle CPU/accelerator buffer fencing. Currently, apart, from things silently failing nothing is enforcing that requirement which means that it's easy for drivers and new developers to get this wrong. To avoid the confusion we can document this requirement and clarify the solution. This came up during a discussion on dri-devel: https://lore.kernel.org/dri-devel/232f45e9-8748-1243-09bf-56763e6668b3@amd.comSigned-off-by:
-
Zack Rusin authored
There's never a need to access our internal kernel bo's from user-space. Those objects are used exclusively for internal support to guest backed surfaces (in otable setup and mob page tables) and there's no need to have them be of device type, i.e. mmappable from user-space. Signed-off-by:
-
Zack Rusin authored
For larger (bigger than a page) and noncontiguous mobs we have to create page tables that allow the host to find the memory. Those page tables just used regular system memory. Unfortunately in TTM those BO's are not allowed to be busy thus can't be fenced and we have to fence those bo's because we don't want to destroy the page tables while the host is still executing the command buffers which might be accessing them. To solve it we introduce a new placement VMW_PL_SYSTEM which is very similar to TTM_PL_SYSTEM except that it allows fencing. This fixes kernel oops'es during unloading of the driver (and pci hot remove/add) which were caused by busy BO's in TTM_PL_SYSTEM being present in the delayed deletion list in TTM (TTM_PL_SYSTEM manager is destroyed before the delayed deletions are executed) Signed-off-by:
-
Zack Rusin authored
Some of our hosts have a bug where rescaning a pci bus results in stale fifo memory being mapped on the host. This makes any fifo communication impossible resulting in various kernel crashes. Instead of unexpectedly crashing, predictably fail to load the driver which will preserve the system. Fixes: fb1d9738 ("drm/vmwgfx: Add DRM driver for VMware Virtual GPU") Signed-off-by:
-
