- 20 Feb, 2023 13 commits
-
-
Thomas Zimmermann authored
Do not claim that there's a default mode in the video= option parser. if no option string has been given, the parser does nothing. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230209135509.7786-12-tzimmermann@suse.de
-
Thomas Zimmermann authored
Include <video/cmdline.h> in drm_connector.c to get video_get_options() and avoid the dependency on <linux/fb.h>. The replaced function fb_get_options() is just a tiny wrapper around video_get_opions(). No functional changes. Include <linux/property.h> to get fwnode_handle_put(), which had been provided via <linux/fb.h>. Signed-off-by:
-
Thomas Zimmermann authored
Include <video/cmdline.h> in ps3av.c to get video_get_options() and avoid the dependency on <linux/fb.h>. The replaced function fb_get_options() is just a tiny wrapper around video_get_opions(). No functional changes. Signed-off-by:
-
Thomas Zimmermann authored
Handle the command-line parameter video= in video/cmdline.c. Implement the fbdev helper fb_get_options() on top. Will allows to handle the kernel parameter in DRM without fbdev dependencies. Note that __video_get_options() has the meaning of its return value inverted compared to fb_get_options(). The new helper returns true if the adapter has been enabled, and false otherwise. There is the ofonly parameter, which disables output for non-OF-based framebuffers. It is only for offb and looks like a workaround. The actual purpose it not clear to me. Use 'video=off' or 'nomodeset' instead. Signed-off-by:
-
Thomas Zimmermann authored
Move the lookup of the option string into an internal helper. No functional changes. Signed-off-by:
-
Thomas Zimmermann authored
There are no external users of fb_mode_option. Unexport the variable and declare it static. Signed-off-by:
-
Thomas Zimmermann authored
Get the kernel's global video= parameter with fb_get_option(). Done to unexport the internal fbdev state fb_mode_config. No functional changes. Signed-off-by:
-
Thomas Zimmermann authored
Get the kernel's global video= parameter with fb_get_option(). Done to unexport the internal fbdev state fb_mode_config. No functional changes. Signed-off-by:
Geoff Levand <geoff@infradead.org> Reviewed-by:
-
Thomas Zimmermann authored
Ignore the per-driver video options if no driver name has been specified to fb_get_option(). Return the global options in this case. Signed-off-by:
-
Thomas Zimmermann authored
In fb_get_options(), always duplicate the returned option string and transfer ownership of the memory to the function's caller. Until now, only the global option string got duplicated and transferred to the caller; the per-driver options were owned by fb_get_options(). In the end, it was impossible for the function's caller to detect if it had to release the string's memory buffer. Hence, all calling drivers leak the memory buffer. The leaks have existed ever since, but drivers only call fb_get_option() once as part of module initialization. So the amount of leaked memory is not significant. Fix the semantics of fb_get_option() by unconditionally transferring ownership of the memory buffer to the caller. Later patches can resolve the memory leaks in the fbdev drivers. Signed-off-by:
-
Thomas Zimmermann authored
Fix Daniel's email address. No functional changes. Signed-off-by:
-
Simon Ser authored
v2: mention caps, note that the IOCTLs might fail, document that user-space needs a data structure to keep track of the handles (Daniel V.) Signed-off-by:
Simon Ser <contact@emersion.fr> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Pekka Paalanen <ppaalanen@gmail.com> Cc: Daniel Stone <daniel@fooishbar.org> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by:
Pekka Paalanen <pekka.paalanen@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230217162151.59996-2-contact@emersion.fr
-
Simon Ser authored
There are two important details missing from the docs: - If the memory object backing the FB already has a GEM handle, it's not re-used, a new one is generated. - Aliased planes will return the same GEM handle. v2: document how user-space can obtain DMA-BUF FDs without leaking handles (Pekka) Signed-off-by:
-
- 17 Feb, 2023 2 commits
-
-
Thomas Weißschuh authored
Since commit ee6d3dd4 ("driver core: make kobj_type constant.") the driver core allows the usage of const struct kobj_type. Take advantage of this to constify the structure definition to prevent modification at runtime. Signed-off-by:
Thomas Weißschuh <linux@weissschuh.net> Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
Simon Ser authored
This is a bit tricky, because of the ref'counting considerations. See also [1] for more discussion about this topic. Since this is kernel docs, I've decided to elaborate a bit less on the user-space details. [1]: https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/110Signed-off-by:
-
- 16 Feb, 2023 4 commits
-
-
Maxime Ripard authored
This reverts commit ae71ab58. Commit ae71ab58 ("drm/vc4: hdmi: Enforce the minimum rate at runtime_resume") was introduced to work around an issue partly due to the clk-bcm2835 driver on the RaspberryPi0-3. Since we're not using that driver for our HDMI clocks, we can now revert it. Reviewed-by:
Maxime Ripard <maxime@cerno.tech>
-
Maxime Ripard authored
This reverts commit 3bc6a37f. Commit 3bc6a37f ("drm/vc4: hdmi: Fix HSM clock too low on Pi4") was introduced to work around an issue partly due to the clk-bcm2835 driver on the RaspberryPi0-3. Since we're not using that driver for our HDMI clocks, we can now revert that inelegant solution. Reviewed-by:
-
Maxime Ripard authored
On the RaspberryPi0-3, the HSM clock was provided by the clk-bcm2835 driver, but on the Pi4 it was provided by the firmware through the clk-raspberrypi driver. The clk-bcm2835 driver registers the HSM clock using the CLK_SET_RATE_GATE flag that prevents any modification to the rate while the clock is active. This meant that we needed to call clk_set_min_rate() before our call to pm_runtime_resume_and_get() since our runtime_resume implementation needs to enable the HSM clock for the HDMI controller registers to be functional. However, the HSM clock is part of the HDMI power domain which might not be powered prior to the pm_runtime_resume_and_get() call, so we could end up changing the rate of the HSM clock while its power domain was disabled. We recently changed the backing driver for the RaspberryPi0-3 to clk-raspberrypi though, which doesn't have such restrictions. We can thus move the clk_set_min_rate() after our call to runtime_resume and avoid the access while the power domain is disabled. Reviewed-by:
-
Maxime Ripard authored
The 120MHz value hardcoded in the call to max_t to compute the HSM rate is defined in the driver as HSM_MIN_CLOCK_FREQ, let's switch to it so that it's more readable. Reviewed-by:
-
- 15 Feb, 2023 3 commits
-
-
Thomas Weißschuh authored
Instead of relying on an accidental, transitive inclusion of linux/leds.h use it directly. Also drop the forware definition of struct led_classdev that is now provided by linux/leds.h. Signed-off-by:
Lyude Paul <lyude@redhat.com> Signed-off-by:
-
Zack Rusin authored
v3: Fix vmw_user_bo_lookup which was also dropping the gem reference before the kernel was done with buffer depending on userspace doing the right thing. Same bug, different spot. It is possible for userspace to predict the next buffer handle and to destroy the buffer while it's still used by the kernel. Delay dropping the internal reference on the buffers until kernel is done with them. Instead of immediately dropping the gem reference in vmw_user_bo_lookup and vmw_gem_object_create_with_handle let the callers decide when they're ready give the control back to userspace. Also fixes the second usage of vmw_gem_object_create_with_handle in vmwgfx_surface.c which wasn't grabbing an explicit reference to the gem object which could have been destroyed by the userspace on the owning surface at any point. Signed-off-by:
Zack Rusin <zackr@vmware.com> Fixes: 8afa13a0 ("drm/vmwgfx: Implement DRIVER_GEM") Reviewed-by:
Martin Krastev <krastevm@vmware.com> Reviewed-by:
Maaz Mombasawala <mombasawalam@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230211050514.2431155-1-zack@kde.org
-
Zack Rusin authored
ttm_bo_init_reserved on failure puts the buffer object back which causes it to be deleted, but kfree was still being called on the same buffer in vmw_bo_create leading to a double free. After the double free the vmw_gem_object_create_with_handle was setting the gem function objects before checking the return status of vmw_bo_create leading to null pointer access. Fix the entire path by relaying on ttm_bo_init_reserved to delete the buffer objects on failure and making sure the return status is checked before setting the gem function objects on the buffer object. Signed-off-by:
-
- 14 Feb, 2023 9 commits
-
-
Zack Rusin authored
In commit 18025378 ("drm/ttm: stop allocating dummy resources during BO creation") ttm stopped allocating dummy resources but vmwgfx was never ported to handle it. Make the driver treat null resources as initial creation and port code to handle null resources in general. Fixes kernel oops'es on boot with vmwgfx. Signed-off-by:
-
Zack Rusin authored
Various bits of the driver used raw ttm_buffer_object instead of the driver specific vmw_bo object. All those places used to duplicate the mapped bo caching policy of vmw_bo. Instead of duplicating all of that code and special casing various functions to work both with vmw_bo and raw ttm_buffer_object's unify the buffer object handling code. As part of that work fix the naming of bo's, e.g. insted of generic backup use 'guest_memory' because that's what it really is. All of it makes the driver easier to maintain and the code easier to read. Saves 100+ loc as well. Signed-off-by:
-
Zack Rusin authored
Problem with explicit placement selection in vmwgfx is that by the time the buffer object needs to be validated the information about which placement was supposed to be used is lost. To workaround this the driver had a bunch of state in various places e.g. as_mob or cpu_blit to somehow convey the information on which placement was intended. Fix it properly by allowing the buffer objects to hold their preferred placement so it can be reused whenever needed. This makes the entire validation pipeline a lot easier both to understand and maintain. Signed-off-by:
-
Zack Rusin authored
Rename dummy to is_iomem because that's what it is even if we're not activelly using it. Makes the code easier to read. Signed-off-by:
-
Zack Rusin authored
Base mapped count is useless because the ttm unmap functions handle null maps just fine so completely remove all the code related to it. Signed-off-by:
-
Zack Rusin authored
Only the legacy display unit requires pinning of the fb memory in vram. Both the screen objects and screen targets can present from any buffer. That makes the pinning abstraction pointless. Simplify all of the code and move it to the legacy display unit, the only place that needs it. Signed-off-by:
-
Zack Rusin authored
The rest of the drivers which are using ttm have mostly standardized on driver_prefix_bo as the name for subclasses of the TTM buffer object. Make vmwgfx match the rest of the drivers and follow the same naming semantics. This is especially clear given that the name of the file in which the object was defined is vmw_bo.c. Signed-off-by:
-
Zack Rusin authored
Remove the explicit bo_free parameter which was switching between vmw_bo_bo_free and vmw_gem_destroy which had exactly the same implementation. It makes no sense to keep parameter which is always the same, remove it and all code referencing it. Instead use the vmw_bo_bo_free directly. Signed-off-by:
-
Zack Rusin authored
Before vmwgfx supported gem it needed to implement the entire mmap logic explicitly. With GEM support that's not needed and the generic code can be used by simply setting the vm_ops to vmwgfx specific ones on the gem object itself. Removes a lot of code from vmwgfx without any functional difference. Signed-off-by:
-
- 10 Feb, 2023 3 commits
-
-
Asahi Lina authored
Other functions touching shmem->sgt take the pages lock, so do that here too. drm_gem_shmem_get_pages() & co take the same lock, so move to the _locked() variants to avoid recursive locking. Discovered while auditing locking to write the Rust abstractions. Fixes: 2194a63a ("drm: Add library for shmem backed GEM objects") Fixes: 4fa3d66f ("drm/shmem: Do dma_unmap_sg before purging pages") Signed-off-by:
Asahi Lina <lina@asahilina.net> Reviewed-by:
-
Maíra Canal authored
vgem_fence_open() instantiates a mutex for a particular fence instance, but never destroys it by calling mutex_destroy() in vgem_fence_close(). So, add the missing mutex_destroy() to guarantee proper resource destruction. Fixes: 40777984 ("drm/vgem: Attach sw fences to exported vGEM dma-buf (ioctl)") Signed-off-by:
Maíra Canal <mcanal@igalia.com> Reviewed-by:
Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com> Signed-off-by:
Maíra Canal <mairacanal@riseup.net> Link: https://patchwork.freedesktop.org/patch/msgid/20230202125517.427976-1-mcanal@igalia.com
-
Christian König authored
Not used by any driver any more. Signed-off-by:
-
- 09 Feb, 2023 1 commit
-
-
Somalapuram Amaranath authored
Use amdgpu_bo_in_cpu_visible_vram() instead. v2 (chk): fix test inversion Signed-off-by:
Somalapuram Amaranath <Amaranath.Somalapuram@amd.com> Reviewed-by:
-
- 07 Feb, 2023 1 commit
-
-
John Keeping authored
Commit 15b9ca16 ("drm: Config orientation property if panel provides it") added a helper to set the panel orientation early but only connected this for drm_bridge_connector, which constructs a panel bridge with DRM_BRIDGE_ATTACH_NO_CONNECTOR and creates the connector itself. When the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag is not specified and the panel_bridge creates its own connector the orientation is not set unless the panel does it in .get_modes which is too late and leads to a warning splat from __drm_mode_object_add() because the device is already registered. Call the necessary function to set add the orientation property when the connector is created so that it is available before the device is registered. Signed-off-by:
John Keeping <john@metanate.com> Reviewed-by:
Douglas Anderson <dianders@chromium.org> Signed-off-by:
-
- 06 Feb, 2023 4 commits
-
-
Christian König authored
We have checks for this in the individual drivers move callback, but it's probably better to generally forbid that on a higher level. Also stops exporting ttm_resource_compat() since that's not necessary any more after removing the extra checks in vmwgfx. Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Signed-off-by:
-
Christian König authored
That should not be necessary any more when drivers should at least be able to handle a move without a resource. Signed-off-by:
Nirmoy Das <nirmoy.das@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230130120636.63765-5-matthew.auld@intel.com
-
Christian König authored
That should not be necessary any more when drivers should at least be able to handle the move without a resource. Signed-off-by:
-
Matthew Auld authored
In the next few patches, when initially creating a ttm BO, the bo->resource is NULL, and the driver is then expected to handle the initial dummy move. However, if this is created as a system resource the first ttm_tt we create will always have the clear value set to false. Previously the initial ttm_tt would be created in ttm_bo_validate() with the clear parameter always set to true. Signed-off-by:
Christian König <ckoenig.leichtzumerken@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230130101230.25347-3-matthew.auld@intel.comAcked-by:
-
