summaryrefslogtreecommitdiffstats
path: root/drivers
Commit message (Collapse)AuthorAgeFilesLines
* driver/ps3: Include <video/cmdline.h> for mode parsingThomas Zimmermann2023-02-201-12/+6
| | | | | | | | | | | 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 <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230209135509.7786-10-tzimmermann@suse.de
* fbdev: Handle video= parameter in video/cmdline.cThomas Zimmermann2023-02-207-88/+152
| | | | | | | | | | | | | | | | | | 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 <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230209135509.7786-9-tzimmermann@suse.de
* fbdev: Move option-string lookup into helperThomas Zimmermann2023-02-201-24/+36
| | | | | | | | | Move the lookup of the option string into an internal helper. No functional changes. 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-8-tzimmermann@suse.de
* fbdev: Unexport fb_mode_optionThomas Zimmermann2023-02-201-3/+1
| | | | | | | | | There are no external users of fb_mode_option. Unexport the variable and declare it static. 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-7-tzimmermann@suse.de
* fbdev: Read video= option with fb_get_option() in modedbThomas Zimmermann2023-02-201-2/+6
| | | | | | | | | | 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 <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230209135509.7786-6-tzimmermann@suse.de
* drivers/ps3: Read video= option with fb_get_option()Thomas Zimmermann2023-02-201-2/+9
| | | | | | | | | | | 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 <tzimmermann@suse.de> Tested-by: Geoff Levand <geoff@infradead.org> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230209135509.7786-5-tzimmermann@suse.de
* fbdev: Support NULL for name in option-string lookupThomas Zimmermann2023-02-201-1/+6
| | | | | | | | | | 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 <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230209135509.7786-4-tzimmermann@suse.de
* fbdev: Transfer video= option strings to caller; clarify ownershipThomas Zimmermann2023-02-201-4/+12
| | | | | | | | | | | | | | | | | | | | | 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 <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230209135509.7786-3-tzimmermann@suse.de
* fbdev: Fix contact info in fb_cmdline.cThomas Zimmermann2023-02-201-1/+1
| | | | | | | | | Fix Daniel's email address. No functional changes. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230209135509.7786-2-tzimmermann@suse.de
* dma-buf: make kobj_type structure constantThomas Weißschuh2023-02-171-1/+1
| | | | | | | | | | | | | Since commit ee6d3dd4ed48 ("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: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230217-kobj_type-dma-buf-v1-1-b84a3616522c@weissschuh.net
* Revert "drm/vc4: hdmi: Enforce the minimum rate at runtime_resume"Maxime Ripard2023-02-161-9/+0
| | | | | | | | | | | | | | | This reverts commit ae71ab585c819f83aec84f91eb01157a90552ef2. Commit ae71ab585c81 ("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: Javier Martinez Canillas <javierm@redhat.com> Link: https://lore.kernel.org/r/20230126-rpi-display-fw-clk-cleanup-v1-4-d646ff6fb842@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
* Revert "drm/vc4: hdmi: Fix HSM clock too low on Pi4"Maxime Ripard2023-02-162-18/+4
| | | | | | | | | | | | | | | This reverts commit 3bc6a37f59f21a8bfaf74d0975b2eb0b2d52a065. Commit 3bc6a37f59f2 ("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: Javier Martinez Canillas <javierm@redhat.com> Link: https://lore.kernel.org/r/20230126-rpi-display-fw-clk-cleanup-v1-3-d646ff6fb842@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
* drm/vc4: hdmi: Enable power domain before setting minimumMaxime Ripard2023-02-161-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Javier Martinez Canillas <javierm@redhat.com> Link: https://lore.kernel.org/r/20230126-rpi-display-fw-clk-cleanup-v1-2-d646ff6fb842@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
* drm/vc4: hdmi: Replace hardcoded value by defineMaxime Ripard2023-02-161-1/+3
| | | | | | | | | | 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: Javier Martinez Canillas <javierm@redhat.com> Link: https://lore.kernel.org/r/20230126-rpi-display-fw-clk-cleanup-v1-1-d646ff6fb842@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
* drm/nouveau/led: explicitly include linux/leds.hThomas Weißschuh2023-02-151-1/+1
| | | | | | | | | | | | | 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: Thomas Weißschuh <linux@weissschuh.net> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230215-power_supply-leds-nouveau-v1-1-ea93bfa0ba7e@weissschuh.net
* drm/vmwgfx: Do not drop the reference to the handle too soonZack Rusin2023-02-147-10/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | 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: 8afa13a0583f ("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
* drm/vmwgfx: Stop accessing buffer objects which failed initZack Rusin2023-02-142-3/+5
| | | | | | | | | | | | | | | | | | | | 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: Zack Rusin <zackr@vmware.com> Fixes: 8afa13a0583f ("drm/vmwgfx: Implement DRIVER_GEM") Reviewed-by: Maaz Mombasawala <mombasawalam@vmware.com> Reviewed-by: Martin Krastev <krastevm@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230208180050.2093426-1-zack@kde.org
* drm/vmwgfx: Make the driver work without the dummy resourcesZack Rusin2023-02-132-5/+16
| | | | | | | | | | | | | | | | | | | | In commit 180253782038 ("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 <zackr@vmware.com> Fixes: 180253782038 ("drm/ttm: stop allocating dummy resources during BO creation") Cc: Christian König <christian.koenig@amd.com> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Nirmoy Das <nirmoy.das@intel.com> Cc: Christian Koenig <christian.koenig@amd.com> Cc: Huang Rui <ray.huang@amd.com> Cc: dri-devel@lists.freedesktop.org Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230210023437.2214816-1-zack@kde.org
* drm/vmwgfx: Stop using raw ttm_buffer_object'sZack Rusin2023-02-1327-688/+563
| | | | | | | | | | | | | | | | | | | | | | 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 <zackr@vmware.com> Reviewed-by: Martin Krastev <krastevm@vmware.com> Reviewed-by: Maaz Mombasawala <mombasawalam@vmware.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230131033542.953249-9-zack@kde.org
* drm/vmwgfx: Abstract placement selectionZack Rusin2023-02-1322-455/+311
| | | | | | | | | | | | | | | | | | 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 <zackr@vmware.com> Reviewed-by: Martin Krastev <krastevm@vmware.com> Reviewed-by: Maaz Mombasawala <mombasawalam@vmware.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230131033542.953249-8-zack@kde.org
* drm/vmwgfx: Rename dummy to is_iomemZack Rusin2023-02-131-8/+8
| | | | | | | | | | | 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 <zackr@vmware.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Martin Krastev <krastevm@vmware.com> Reviewed-by: Maaz Mombasawala <mombasawalam@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230131033542.953249-7-zack@kde.org
* drm/vmwgfx: Cleanup the vmw bo usage in the cursor pathsZack Rusin2023-02-132-14/+1
| | | | | | | | | | | 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 <zackr@vmware.com> Reviewed-by: Martin Krastev <krastevm@vmware.com> Reviewed-by: Maaz Mombasawala <mombasawalam@vmware.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230131033542.953249-6-zack@kde.org
* drm/vmwgfx: Simplify fb pinningZack Rusin2023-02-135-85/+54
| | | | | | | | | | | | | 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 <zackr@vmware.com> Reviewed-by: Martin Krastev <krastevm@vmware.com> Reviewed-by: Maaz Mombasawala <mombasawalam@vmware.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230131033542.953249-5-zack@kde.org
* drm/vmwgfx: Rename vmw_buffer_object to vmw_boZack Rusin2023-02-1325-385/+419
| | | | | | | | | | | | | | | | 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 <zackr@vmware.com> Reviewed-by: Martin Krastev <krastevm@vmware.com> Reviewed-by: Maaz Mombasawala <mombasawalam@vmware.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230131033542.953249-4-zack@kde.org
* drm/vmwgfx: Remove the duplicate bo_free functionZack Rusin2023-02-138-58/+27
| | | | | | | | | | | | | | | 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 <zackr@vmware.com> Reviewed-by: Martin Krastev <krastevm@vmware.com> Reviewed-by: Maaz Mombasawala <mombasawalam@vmware.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230131033542.953249-3-zack@kde.org
* drm/vmwgfx: Use the common gem mmap instead of the custom codeZack Rusin2023-02-135-118/+10
| | | | | | | | | | | | | | | 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: Zack Rusin <zackr@vmware.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Martin Krastev <krastevm@vmware.com> Reviewed-by: Maaz Mombasawala <mombasawalam@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230131033542.953249-2-zack@kde.org
* drm/shmem-helper: Fix locking for drm_gem_shmem_get_pages_sgt()Asahi Lina2023-02-101-20/+34
| | | | | | | | | | | | | | | 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: 2194a63a818d ("drm: Add library for shmem backed GEM objects") Fixes: 4fa3d66f132b ("drm/shmem: Do dma_unmap_sg before purging pages") Signed-off-by: Asahi Lina <lina@asahilina.net> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230205125124.2260-1-lina@asahilina.net
* drm/vgem: add missing mutex_destroyMaíra Canal2023-02-101-0/+1
| | | | | | | | | | | | | | | 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: 407779848445 ("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
* drm: remove dumb_destroy callbackChristian König2023-02-103-14/+1
| | | | | | | | | Not used by any driver any more. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Tested-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230126102814.8722-2-christian.koenig@amd.com
* drm/amdgpu: Remove TTM resource->start visible VRAM condition v2Somalapuram Amaranath2023-02-091-6/+3
| | | | | | | | | | | Use amdgpu_bo_in_cpu_visible_vram() instead. v2 (chk): fix test inversion Signed-off-by: Somalapuram Amaranath <Amaranath.Somalapuram@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230208090106.9659-2-Amaranath.Somalapuram@amd.com
* drm/bridge: panel: Set orientation on panel_bridge connectorJohn Keeping2023-02-061-0/+2
| | | | | | | | | | | | | | | | | | | | | | Commit 15b9ca1641f0 ("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: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230120114313.2087015-1-john@metanate.com
* drm/ttm: prevent moving of pinned BOsChristian König2023-02-066-37/+14
| | | | | | | | | | | | | 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: Christian König <christian.koenig@amd.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230130120636.63765-6-matthew.auld@intel.com
* drm/ttm: stop allocating a dummy resource for pipelined guttingChristian König2023-02-061-13/+2
| | | | | | | | | | | That should not be necessary any more when drivers should at least be able to handle a move without a resource. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Acked-by: Nirmoy Das <nirmoy.das@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230130120636.63765-5-matthew.auld@intel.com
* drm/ttm: stop allocating dummy resources during BO creationChristian König2023-02-061-7/+0
| | | | | | | | | | | That should not be necessary any more when drivers should at least be able to handle the move without a resource. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Acked-by: Nirmoy Das <nirmoy.das@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230130120636.63765-4-matthew.auld@intel.com
* drm/ttm: clear the ttm_tt when bo->resource is NULLMatthew Auld2023-02-061-2/+1
| | | | | | | | | | | | | | | 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: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Christian König <ckoenig.leichtzumerken@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230130101230.25347-3-matthew.auld@intel.com Acked-by: Nirmoy Das <nirmoy.das@intel.com> Signed-off-by: Christian König <christian.koenig@amd.com>
* drm/i915/ttm: audit remaining bo->resourceMatthew Auld2023-02-064-5/+18
| | | | | | | | | | | | | | | | | | | | In the near future TTM will have NULL bo->resource when the object is initially created, plus after calling into pipeline-gutting. Try to handle the remaining cases. In practice NULL bo->resource should be taken to mean swapped-out or purged object. v2 (Andrzej): - Rather make i915_ttm_cpu_maps_iomem() return false with NULL resource. References: 516198d317d8 ("drm/i915: audit bo->resource usage v3") Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Nirmoy Das <nirmoy.das@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230130101230.25347-2-matthew.auld@intel.com Reviewed-by: Nirmoy Das <nirmoy.das@intel.com> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Acked-by: Christian König <ckoenig.leichtzumerken@gmail.com> Signed-off-by: Christian König <christian.koenig@amd.com>
* drm/i915/ttm: fix sparse warningMatthew Auld2023-02-061-2/+3
| | | | | | | | | | | | | | | | Sparse complains with: drivers/gpu/drm/i915/gem/i915_gem_ttm.c:1066:21: sparse: expected restricted vm_fault_t [assigned] [usertype] ret drivers/gpu/drm/i915/gem/i915_gem_ttm.c:1066:21: sparse: got int Fixes: 516198d317d8 ("drm/i915: audit bo->resource usage v3") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230130101230.25347-1-matthew.auld@intel.com Reviewed-by: Nirmoy Das <nirmoy.das@intel.com> Acked-by: Christian König <ckoenig.leichtzumerken@gmail.com> Signed-off-by: Christian König <christian.koenig@amd.com>
* accel/ivpu: Fix old dma_buf api usageStanislaw Gruszka2023-02-061-6/+2
| | | | | | | | | | | | Update according to new dma-buf locking scheme. Remove redundant WARN_ON()'s, dma_buf functions internally have the same warnings already. Signed-off-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com> Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com> Signed-off-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230202092114.2637452-5-stanislaw.gruszka@linux.intel.com
* accel/ivpu: Set dma max_segment_sizeStanislaw Gruszka2023-02-061-0/+1
| | | | | | | | | | | | Avoid below spurious warning: [ 264.844029] DMA-API: intel_vpu 0000:00:0b.0: mapping sg segment longer than device claims to support [len=143360] [max=65536] [ 264.844038] WARNING: CPU: 0 PID: 1254 at kernel/dma/debug.c:1160 debug_dma_map_sg+0x6ca/0xb70 Signed-off-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com> Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com> Signed-off-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230202092114.2637452-4-stanislaw.gruszka@linux.intel.com
* accel/ivpu: Send VPU_JSM_MSG_CONTEXT_DELETE when deleting contextAndrzej Kacprowski2023-02-063-1/+13
| | | | | | | | | | | | | | | | The VPU_JSM_MSG_CONTEXT_DELETE will remove any resources associated with the SSID, that included any blobs create by the user space application. The command can also remove doorbell registrations, but since this does not work in HW scheduling case, we do not depend on this capability and unregister the doorbells explicitly. Signed-off-by: Andrzej Kacprowski <andrzej.kacprowski@linux.intel.com> Signed-off-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com> Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com> Signed-off-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230202092114.2637452-3-stanislaw.gruszka@linux.intel.com
* accel/ivpu: Fix FW API data alignment issuesAndrzej Kacprowski2023-02-063-44/+65
| | | | | | | | | | | | | | | | FW API structures have been updated to fix misaligned structure members. Also changed JSM message header format to account for future improvements. Added explicit check for minimum supported JSM API version. Signed-off-by: Andrzej Kacprowski <andrzej.kacprowski@linux.intel.com> Signed-off-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com> Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com> Signed-off-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230202092114.2637452-2-stanislaw.gruszka@linux.intel.com
* drm/rockchip: Drop unbalanced obj unrefRob Clark2023-02-051-3/+0
| | | | | | | | | | In the error path, rockchip_drm_gem_object_mmap() is dropping an obj reference that it doesn't own. Fixes: 41315b793e13 ("drm/rockchip: use drm_gem_mmap helpers") Signed-off-by: Rob Clark <robdclark@chromium.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230119231734.2884543-1-robdclark@gmail.com
* drm/rockchip: avoid duplicate mappings for IOMMU devicesJohn Keeping2023-02-051-3/+10
| | | | | | | | | | If a buffer is allocated with alloc_kmap, then it is vmap'd on creation and there is no reason to map it again in rockchip_gem_prime_vmap() when the existing mapping can be used. Signed-off-by: John Keeping <john@metanate.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20221110172415.2853420-1-john@metanate.com
* drm/rockchip: vop: Quiet always-warning AFBC logBrian Norris2023-02-051-4/+1
| | | | | | | | | | | | | | | | | | | | | | | | The downstream code from which this was derived didn't ever run through this 'switch' block with non-AFBC formats, but the upstream code does -- we use this function to probe whether a given format is supported. Demote the warning to eliminate this sort of warning seen on every boot: [drm] unsupported AFBC format[3231564e] And make it warn more than once, because if we *actually* care to see what formats we're probing/rejecting and for what reasons, we probably care about more than just the first message. Drop the comment, because one of the two *is* commonly reachable. And lastly, drop the unreachable return; we'd do better to let the compiler complain if we start hitting this unexpectedly. Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20221031101557.1.Ic1569d394173c1c3016142fee4bb87a09753db94@changeid
* drm/rockchip: vop2: add support for the rgb output blockMichael Riesch2023-02-051-0/+44
| | | | | | | | | | The Rockchip VOP2 features an internal RGB output block, which can be attached any video port of the VOP2. Add support for this output block. Signed-off-by: Michael Riesch <michael.riesch@wolfvision.net> Reviewed-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230124054706.3921383-6-michael.riesch@wolfvision.net
* drm/rockchip: vop2: use symmetric function pair vop2_{create,destroy}_crtcsMichael Riesch2023-02-051-15/+16
| | | | | | | | | | | Let the function name vop2_create_crtcs reflect that the function creates multiple CRTCS. Also, use a symmetric function pair to create and destroy the CRTCs and the corresponding planes. Signed-off-by: Michael Riesch <michael.riesch@wolfvision.net> Reviewed-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230124054706.3921383-5-michael.riesch@wolfvision.net
* drm/rockchip: rgb: add video_port parameter to init functionMichael Riesch2023-02-053-7/+10
| | | | | | | | | | | The VOP2 driver has more than one video port, hence the hard-coded port id will not work anymore. Add an extra parameter for the video port id to the rockchip_rgb_init function. Signed-off-by: Michael Riesch <michael.riesch@wolfvision.net> Reviewed-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230124054706.3921383-4-michael.riesch@wolfvision.net
* drm/rockchip: rgb: embed drm_encoder into rockchip_encoderMichael Riesch2023-02-051-5/+5
| | | | | | | | | | | | | | Commit 540b8f271e53 ("drm/rockchip: Embed drm_encoder into rockchip_decoder") provides the means to pass the endpoint ID to the VOP2 driver, which sets the interface MUX accordingly. However, this step has not yet been carried out for the RGB output block. Embed the drm_encoder structure into the rockchip_encoder structure and set the endpoint ID correctly. Signed-off-by: Michael Riesch <michael.riesch@wolfvision.net> Reviewed-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230124054706.3921383-3-michael.riesch@wolfvision.net
* drm/rockchip: vop2: initialize possible_crtcs properlyMichael Riesch2023-02-051-3/+4
| | | | | | | | | | | | | | | The variable possible_crtcs is only initialized for primary and overlay planes. Since the VOP2 driver only supports these plane types at the moment, the current code is safe. However, in order to provide a future-proof solution, fix the initialization of the variable. Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <error27@gmail.com> Signed-off-by: Michael Riesch <michael.riesch@wolfvision.net> Reviewed-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230124054706.3921383-2-michael.riesch@wolfvision.net
* drm/arm/malidp: use sysfs_emit in show function callbackDeepak R Varma2023-02-031-1/+1
| | | | | | | | | | | According to Documentation/filesystems/sysfs.rst, the show() callback function of kobject attributes should strictly use sysfs_emit() instead of sprintf() family functions. Issue identified using the device_attr_show.cocci Coccinelle script. Signed-off-by: Deepak R Varma <drv@mailo.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/Y9Q5Tt8c9WBDxeyV@ubun2204.myguest.virtualbox.org
generated by cgit v1.2.3 (git 2.25.1) at 2024-10-02 06:38:50 +0000