- 28 May, 2021 2 commits
-
-
Javier Martinez Canillas authored
There are drivers that register framebuffer devices very early in the boot process and make use of the existing framebuffer as setup by the firmware. If one of those drivers has registered a fbdev, then the fallback fbdev of the DRM driver won't be bound to the framebuffer console. To avoid that, remove any existing generic driver and take over the graphics device. By doing that, the fb mapped to the console is switched correctly from the early fbdev to the one registered by the rockchip DRM driver: [ 40.752420] fb0: switching to rockchip-drm-fb from EFI VGA Signed-off-by:Javier Martinez Canillas <javierm@redhat.com> Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Tested-by:
Peter Robinson <pbrobinson@gmail.com> Acked-by:
Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20210516074833.451643-1-javierm@redhat.com
-
Paul Cercueil authored
The previous commit wrongly assumed that dma_mmap_wc() could be replaced by pgprot_writecombine() + dma_mmap_pages(). It did work on my setup, but did not work everywhere. Use dma_mmap_wc() when the buffer has the write-combine cache attribute, and dma_mmap_pages() when it has the non-coherent cache attribute. Signed-off-by:
Paul Cercueil <paul@crapouillou.net> Reported-by:
Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Reviewed-by:
-
- 27 May, 2021 11 commits
-
-
Nikola Cornij authored
[why] Link rate in kHz is what is eventually required to calculate the link bandwidth, which makes kHz a more generic unit. This should also make forward-compatibility with new DP standards easier. [how] - Replace 'link rate DPCD code' with 'link rate in kHz' when used with drm_dp_mst_topology_mgr_init() - Add/remove related DPCD code conversion from/to kHz where applicable Signed-off-by:
Nikola Cornij <nikola.cornij@amd.com> Acked-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
Lyude Paul <lyude@redhat.com> Signed-off-by:
-
Maxime Ripard authored
i915 is broken without -rc3, let's bring that tag in to fix it. Signed-off-by:Maxime Ripard <maxime@cerno.tech>
-
Geert Uytterhoeven authored
The ChromeOS EC ANX7688 bridge is connected to a ChromeOS Embedded Controller, and is accessed using I2C tunneling through the Embedded Controller. Hence add a dependency on I2C_CROS_EC_TUNNEL, to prevent asking the user about this driver when configuring a kernel without support for the ChromeOS EC tunnel I2C bus. Fixes: 44602b10 ("drm/bridge: Add ChromeOS EC ANX7688 bridge driver support") Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by:
Enric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by:
Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/d107d1840b83607baee8571cc5d88973fc32b519.1622015323.git.geert+renesas@glider.be
-
Zou Wei authored
./drivers/gpu/drm/bridge/lontium-lt8912b.c:758:3-8: No need to set .owner here. The core will do it. Remove .owner field if calls are used which set it automatically Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Zou Wei <zou_wei@huawei.com> Reviewed-by:
-
Jiapeng Chong authored
Eliminate the follow smatch warning: drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c:2143 cdns_mhdp_bridge_atomic_reset() warn: inconsistent indenting. Reported-by:
Abaci Robot <abaci@linux.alibaba.com> Signed-off-by:
Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Reviewed-by:
-
Zou Wei authored
pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to putting operation will result in reference leak here. Fix it by replacing it with pm_runtime_resume_and_get to keep usage counter balanced. Reported-by:
-
Daniel Vetter authored
drm/i915 is extremely on fire without the below revert from -rc3: commit 293837b9 Author: Linus Torvalds <torvalds@linux-foundation.org> Date: Wed May 19 05:55:57 2021 -1000 Revert "i915: fix remap_io_sg to verify the pgprot" Backmerge so we don't have a too wide bisect window for anything that's a more involved workload than booting the driver. Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Thomas Zimmermann authored
The structure is unused. Remove it. Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210516121315.30321-5-tzimmermann@suse.de
-
Sakari Ailus authored
The %p4cc printk format modifier was recently added to print fourcc codes, replacing drm_get_format_name(). The function is no longer needed, so remove it. Signed-off-by:
Petr Mladek <pmladek@suse.com> Reviewed-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210516121315.30321-4-tzimmermann@suse.de
-
Thomas Zimmermann authored
Replace use of struct drm_format_name_buf with %p4cc for printing 4CC formats. Signed-off-by:
-
Thomas Zimmermann authored
Replace use of struct drm_format_name_buf with %p4cc for printing 4CC formats. Signed-off-by:
Christian König <christian.koenig@amd.com> Acked-by:
Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210516121315.30321-2-tzimmermann@suse.de
-
- 26 May, 2021 13 commits
-
-
Arnd Bergmann authored
This is one of the last drivers with a global init_module() function instead of the modern module_init() annotation. Convert it over. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Javier Martinez Canillas authored
Framebuffer devices that are registered by DRM drivers for fbdev emulation have a "drmfb" suffix in their name. But makes them to be quite confusing for drivers that already have "drm" in their name: $ cat /proc/fb 0 rockchipdrmdrmfb $ cat /proc/fb 0 simpledrmdrmfb Also, there isn't a lot of value in adding these "drmfb" suffices to their names, since users shouldn't really care if the FB devices were registered by a real fbdev driver or a DRM driver using the fbdev emulation. What programs should be interested about is if there's a DRM device, and there are better ways to query that info than reading this procfs entry. So let's just remove the suffix, which leads to much better device names: $ cat /proc/fb 0 rockchipdrm $ cat /proc/fb 0 simpledrm Suggested-by:
-
Hao Fang authored
s/Hisilicon/HiSilicon/. It should use capital S, according to https://www.hisilicon.com/en. Signed-off-by:
Hao Fang <fanghao11@huawei.com> Acked-by:
Tian Tao <tiantao6@hisilicon.com> Signed-off-by:
-
Joseph Kogut authored
After removing drm_pci_alloc/free, some instances where drm_pci_free() would have kfreed the dma handle were skipped. Ensure these handles are freed properly. Signed-off-by:
Joseph Kogut <joseph.kogut@gmail.com> Signed-off-by:
-
Thomas Zimmermann authored
The option DRM_KMS_FB_HELPER has been removed. Also remove the last remaining select statement for it. Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> 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/20210526100825.29450-1-tzimmermann@suse.de
-
Thomas Zimmermann authored
The function ttm_bo_mmap is unused. Remove it and it's helpers; including the verify_access callback in struct ttm_device_funcs. Signed-off-by:
-
Thomas Zimmermann authored
Vmwgfx is the only user of the TTM's verify_access callback. Inline the call and avoid the indirection through the function pointer. Signed-off-by:
Zack Rusin <zackr@vmware.com> Acked-by:
-
Thomas Zimmermann authored
The vmwgfx driver is the only remaining user of ttm_bo_mmap(). Inline the code. The internal helper ttm_bo_vm_lookup() is now also part of vmwgfx as vmw_bo_vm_lookup(). v2: * replace pr_err() with drm_err() (Zack) Signed-off-by:
-
Thomas Zimmermann authored
Moving the driver-specific mmap code into a GEM object function allows for using DRM helpers for various mmap callbacks. The GEM object function is provided by GEM TTM helpers. Nouveau's implementation of verify_access is unused and has been removed. Access permissions are validated by the DRM helpers. As a side effect, nouveau_ttm_vm_ops and nouveau_ttm_fault() are now implemented in nouveau's GEM code. Signed-off-by:
-
Thomas Zimmermann authored
Moving the driver-specific mmap code into a GEM object function allows for using DRM helpers for various mmap callbacks. This change also allows to support prime-based mmap via DRM's helper drm_gem_prime_mmap(). Permission checks are implemented by drm_gem_mmap(), with an additional check for radeon_ttm_tt_has_userptr() in the GEM object function. The function radeon_verify_access() is now unused and has thus been removed. As a side effect, radeon_ttm_vm_ops and radeon_ttm_fault() are now implemented in amdgpu's GEM code. v3: * remove unnecessary checks from mmap (Christian) v2: * rename radeon_ttm_vm_ops and radeon_ttm_fault() to radeon_gem_vm_ops and radeon_gem_fault() (Christian) * fix commit description (Alex) Signed-off-by:
-
Thomas Zimmermann authored
Moving the driver-specific mmap code into a GEM object function allows for using DRM helpers for various mmap callbacks. This change resolves several inconsistencies between regular mmap and prime-based mmap. The vm_ops field in vma is now set for all mmap'ed areas. Previously it way only set for regular mmap calls, prime-based mmap used TTM's default vm_ops. The function amdgpu_verify_access() is no longer being called and therefore removed by this patch. As a side effect, amdgpu_ttm_vm_ops and amdgpu_ttm_fault() are now implemented in amdgpu's GEM code. v4: * rebased v3: * rename mmap function to amdgpu_gem_object_mmap() (Christian) * remove unnecessary checks from mmap (Christian) v2: * rename amdgpu_ttm_vm_ops and amdgpu_ttm_fault() to amdgpu_gem_vm_ops and amdgpu_gem_fault() (Christian) * the check for kfd_bo has meanwhile been removed Signed-off-by:
-
Thomas Zimmermann authored
Drivers may want to set their own callbacks for a VM area. Only set TTM's callbacks if the vm_ops field is clear. Signed-off-by:
-
Andrey Grodzovsky authored
Problem: drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:332:1: warning: unused label 'exit' [-Wunused-label] exit: ^~~~~ Fix: Put #ifdef CONFIG_64BIT around exit Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Andrey Grodzovsky <andrey.grodzovsky@amd.com> Reviewed-by:
-
- 25 May, 2021 6 commits
-
-
Andrey Grodzovsky authored
Problem: When device goes into runtime suspend due to prolonged inactivity (e.g. BACO sleep) and then hot unplugged, PCI core will try to wake up the device as part of unplug process. Since the device is gone all HW programming during rpm resume fails leading to a bad SW state later during pci remove handling. Fix: Use a flag we use for PCIe error recovery to avoid accessing registres. This allows to successfully complete rpm resume sequence and finish pci remove. v2: Renamed HW access block flag Signed-off-by:
-
Andrey Grodzovsky authored
Make it's name not feature but function descriptive. Signed-off-by:
-
Paul Cercueil authored
Alloc GEM buffers backed by noncoherent memory on SoCs where it is actually faster than write-combine. This dramatically speeds up software rendering on these SoCs, even for tasks where write-combine memory should in theory be faster (e.g. simple blits). v3: The option is now selected per-SoC instead of being a module parameter. v5: - Fix drm_atomic_get_new_plane_state() used to retrieve the old state - Use custom drm_gem_fb_create() - Only check damage clips and sync DMA buffers if non-coherent buffers are used Signed-off-by: -
Paul Cercueil authored
This function can be used by drivers that use damage clips and have CMA GEM objects backed by non-coherent memory. Calling this function in a plane's .atomic_update ensures that all the data in the backing memory have been written to RAM. v3: - Only sync data if using GEM objects backed by non-coherent memory. - Use a drm_device pointer instead of device pointer in prototype v5: - Rename to drm_fb_cma_sync_non_coherent - Invert loops for better cache locality - Only sync BOs that have the non-coherent flag - Move to drm_fb_cma_helper.c to avoid circular dependency Signed-off-by: -
Paul Cercueil authored
Having GEM buffers backed by non-coherent memory is interesting in the particular case where it is faster to render to a non-coherent buffer then sync the data cache, than to render to a write-combine buffer, and (by extension) much faster than using a shadow buffer. This is true for instance on some Ingenic SoCs, where even simple blits (e.g. memcpy) are about three times faster using this method. Add a 'map_noncoherent' flag to the drm_gem_cma_object structure, which can be set by the drivers when they create the dumb buffer. Since this really only applies to software rendering, disable this flag as soon as the CMA objects are exported via PRIME. v3: New patch. Now uses a simple 'map_noncoherent' flag to control how the objects are mapped, and use the new dma_mmap_pages function. v4: Make sure map_noncoherent is always disabled when creating GEM objects meant to be used with dma-buf. Signed-off-by: -
Zou Wei authored
pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to putting operation will result in reference leak here. Fix it by replacing it with pm_runtime_resume_and_get to keep usage counter balanced. Reported-by:
-
- 24 May, 2021 8 commits
-
-
Douglas Anderson authored
The PM Runtime docs specifically call out the need to call pm_runtime_dont_use_autosuspend() in the remove() callback if pm_runtime_use_autosuspend() was called in probe(): > Drivers in ->remove() callback should undo the runtime PM changes done > in ->probe(). Usually this means calling pm_runtime_disable(), > pm_runtime_dont_use_autosuspend() etc. We should do this. This fixes a warning splat that I saw when I was testing out the panel-simple's remove(). Fixes: 3235b0f2 ("drm/panel: panel-simple: Use runtime pm to avoid excessive unprepare / prepare") Signed-off-by:
Douglas Anderson <dianders@chromium.org> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210517130450.v7.1.I9e947183e95c9bd067c9c1d51208ac6a96385139@changeid
-
Maxime Ripard authored
It looks like some displays (like the LG 27UL850-W) don't enable the scrambling when the HDMI driver enables it. However, if we set later the scrambler enable bit, the display will work as expected. Let's create delayed work queue to periodically look at the display scrambling status, and if it's not set yet try to enable it again. Signed-off-by:
Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210507150515.257424-12-maxime@cerno.tech
-
Maxime Ripard authored
The HDMI controller on the BCM2711 includes a scrambler in order to reach the HDMI 2.0 modes that require it. Let's add the support for it. Acked-by:
-
Maxime Ripard authored
In order to reach the frequencies needed to output at 594MHz, the firmware needs to be configured with the appropriate parameters in the config.txt file (enable_hdmi_4kp60 and force_turbo). Let's detect it at bind time, warn the user if we can't, and filter out the relevant modes. Acked-by:
-
Maxime Ripard authored
The BVB clock rate computation doesn't take into account a mode clock of 594MHz that we're going to need to support 4k60. Acked-by:
-
Maxime Ripard authored
We'll need to have the HVS binding before the HDMI controllers so that we can check whether the firmware allows to run in 4kp60. Reorder a bit the component list, and document the current constraints we're aware of. Acked-by:
-
Maxime Ripard authored
Since we fixed the hooks to disable the encoder at boot, we now have an unbalanced clk_disable call at boot since we never enabled them in the first place. Let's mimic the state of the hardware and enable the clocks at boot if the controller is enabled to get the use-count right. Cc: <stable@vger.kernel.org> # v5.10+ Fixes: 09c43813 ("drm/vc4: hdmi: Implement finer-grained hooks") Signed-off-by:
-
Maxime Ripard authored
At boot, we can't rely on the vc4_get_crtc_encoder since we don't have a state yet and thus will not be able to figure out which connector is attached to our CRTC. However, we have a muxing bit in the CRTC register we can use to get the encoder currently connected to the pixelvalve. We can thus read that register, lookup the associated register through the vc4_pv_data structure, and then pass it to vc4_crtc_disable so that we can perform the proper operations. Fixes: 875a4d53 ("drm/vc4: drv: Disable the CRTC at boot time") Signed-off-by:
-
