dri-devel July 2021

dri-devel@lists.freedesktop.org

321 participants
829 discussions

[PATCH] gpu: host1x: select CONFIG_SYNC_FILE
by Arnd Bergmann 23 Jul '21

23 Jul '21

From: Arnd Bergmann <arnd(a)arndb.de> With the addition of the DMA fence, the host1x driver now fails to build without the sync_file helper: arm-linux-gnueabi-ld: drivers/gpu/host1x/fence.o: in function `host1x_fence_create_fd': fence.c:(.text+0x624): undefined reference to `sync_file_create' Fixes: ad0529424def ("gpu: host1x: Add DMA fence implementation") Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> --- drivers/gpu/host1x/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/host1x/Kconfig b/drivers/gpu/host1x/Kconfig index 6dab94adf25e..6f7ea1720a39 100644 --- a/drivers/gpu/host1x/Kconfig +++ b/drivers/gpu/host1x/Kconfig @@ -3,6 +3,7 @@ config TEGRA_HOST1X tristate "NVIDIA Tegra host1x driver" depends on ARCH_TEGRA || (ARM && COMPILE_TEST) select IOMMU_IOVA + select SYNC_FILE help Driver for the NVIDIA Tegra host1x hardware. -- 2.29.2

2 2

[PATCH v3 1/1] drm/ttm: Fix COW check
by Felix Kuehling 23 Jul '21

23 Jul '21

KFD Thunk maps invisible VRAM BOs with PROT_NONE, MAP_PRIVATE. is_cow_mapping returns true for these mappings. Add a check for vm_flags & VM_WRITE to avoid mmap failures on private read-only or PROT_NONE mappings. v2: protect against mprotect making a mapping writable after the fact v3: update driver-specific vm_operations_structs Fixes: f91142c62161 ("drm/ttm: nuke VM_MIXEDMAP on BO mappings v3") Signed-off-by: Felix Kuehling <Felix.Kuehling(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 3 ++- drivers/gpu/drm/nouveau/nouveau_gem.c | 3 ++- drivers/gpu/drm/radeon/radeon_gem.c | 3 ++- drivers/gpu/drm/ttm/ttm_bo_vm.c | 14 +++++++++++++- drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c | 1 + include/drm/ttm/ttm_bo_api.h | 4 ++++ 6 files changed, 24 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c index b3404c43a911..1aa750a6a5d2 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c @@ -79,7 +79,8 @@ static const struct vm_operations_struct amdgpu_gem_vm_ops = { .fault = amdgpu_gem_fault, .open = ttm_bo_vm_open, .close = ttm_bo_vm_close, - .access = ttm_bo_vm_access + .access = ttm_bo_vm_access, + .mprotect = ttm_bo_vm_mprotect }; static void amdgpu_gem_object_free(struct drm_gem_object *gobj) diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c b/drivers/gpu/drm/nouveau/nouveau_gem.c index 5b27845075a1..164ea564bb7a 100644 --- a/drivers/gpu/drm/nouveau/nouveau_gem.c +++ b/drivers/gpu/drm/nouveau/nouveau_gem.c @@ -70,7 +70,8 @@ static const struct vm_operations_struct nouveau_ttm_vm_ops = { .fault = nouveau_ttm_fault, .open = ttm_bo_vm_open, .close = ttm_bo_vm_close, - .access = ttm_bo_vm_access + .access = ttm_bo_vm_access, + .mprotect = ttm_bo_vm_mprotect }; void diff --git a/drivers/gpu/drm/radeon/radeon_gem.c b/drivers/gpu/drm/radeon/radeon_gem.c index 458f92a70887..c19ad07eb7b5 100644 --- a/drivers/gpu/drm/radeon/radeon_gem.c +++ b/drivers/gpu/drm/radeon/radeon_gem.c @@ -77,7 +77,8 @@ static const struct vm_operations_struct radeon_gem_vm_ops = { .fault = radeon_gem_fault, .open = ttm_bo_vm_open, .close = ttm_bo_vm_close, - .access = ttm_bo_vm_access + .access = ttm_bo_vm_access, + .mprotect = ttm_bo_vm_mprotect }; static void radeon_gem_object_free(struct drm_gem_object *gobj) diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c index f56be5bc0861..fb325bad5db6 100644 --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c @@ -542,17 +542,29 @@ int ttm_bo_vm_access(struct vm_area_struct *vma, unsigned long addr, } EXPORT_SYMBOL(ttm_bo_vm_access); +int ttm_bo_vm_mprotect(struct vm_area_struct *vma, unsigned long start, + unsigned long end, unsigned long newflags) +{ + /* Enforce no COW since would have really strange behavior with it. */ + if (is_cow_mapping(newflags) && (newflags & VM_WRITE)) + return -EINVAL; + + return 0; +} +EXPORT_SYMBOL(ttm_bo_vm_mprotect); + static const struct vm_operations_struct ttm_bo_vm_ops = { .fault = ttm_bo_vm_fault, .open = ttm_bo_vm_open, .close = ttm_bo_vm_close, .access = ttm_bo_vm_access, + .mprotect = ttm_bo_vm_mprotect, }; int ttm_bo_mmap_obj(struct vm_area_struct *vma, struct ttm_buffer_object *bo) { /* Enforce no COW since would have really strange behavior with it. */ - if (is_cow_mapping(vma->vm_flags)) + if (is_cow_mapping(vma->vm_flags) && (vma->vm_flags & VM_WRITE)) return -EINVAL; ttm_bo_get(bo); diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c index e6b1f98ec99f..e4bf7dc99320 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c @@ -61,6 +61,7 @@ int vmw_mmap(struct file *filp, struct vm_area_struct *vma) .fault = vmw_bo_vm_fault, .open = ttm_bo_vm_open, .close = ttm_bo_vm_close, + .mprotect = ttm_bo_vm_mprotect, #ifdef CONFIG_TRANSPARENT_HUGEPAGE .huge_fault = vmw_bo_vm_huge_fault, #endif diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h index f681bbdbc698..40eb95875355 100644 --- a/include/drm/ttm/ttm_bo_api.h +++ b/include/drm/ttm/ttm_bo_api.h @@ -605,6 +605,10 @@ void ttm_bo_vm_close(struct vm_area_struct *vma); int ttm_bo_vm_access(struct vm_area_struct *vma, unsigned long addr, void *buf, int len, int write); + +int ttm_bo_vm_mprotect(struct vm_area_struct *vma, unsigned long start, + unsigned long end, unsigned long newflags); + bool ttm_bo_delayed_delete(struct ttm_device *bdev, bool remove_all); vm_fault_t ttm_bo_vm_dummy_page(struct vm_fault *vmf, pgprot_t prot); -- 2.32.0

6 14

[PATCH v3 1/2] drm/i915: document caching related bits
by Matthew Auld 23 Jul '21

23 Jul '21

Try to document the object caching related bits, like cache_coherent and cache_dirty. v2(Ville): - As pointed out by Ville, fix the completely incorrect assumptions about the "partial" coherency on shared LLC platforms. v3(Daniel): - Fix nonsense about "dirtying" the cache with reads. Suggested-by: Daniel Vetter <daniel.vetter(a)ffwll.ch> Signed-off-by: Matthew Auld <matthew.auld(a)intel.com> Cc: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Cc: Mika Kuoppala <mika.kuoppala(a)linux.intel.com> --- .../gpu/drm/i915/gem/i915_gem_object_types.h | 176 +++++++++++++++++- drivers/gpu/drm/i915/i915_drv.h | 9 - 2 files changed, 172 insertions(+), 13 deletions(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h index afbadfc5516b..40cce816a7e3 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h +++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h @@ -92,6 +92,76 @@ struct drm_i915_gem_object_ops { const char *name; /* friendly name for debug, e.g. lockdep classes */ }; +/** + * enum i915_cache_level - The supported GTT caching values for system memory + * pages. + * + * These translate to some special GTT PTE bits when binding pages into some + * address space. It also determines whether an object, or rather its pages are + * coherent with the GPU, when also reading or writing through the CPU cache + * with those pages. + * + * Userspace can also control this through struct drm_i915_gem_caching. + */ +enum i915_cache_level { + /** + * @I915_CACHE_NONE: + * + * Not coherent with the CPU cache. If the cache is dirty and we need + * the underlying pages to be coherent with some later GPU access then + * we need to manually flush the pages. + * + * Note that on shared LLC platforms reads and writes through the CPU + * cache are still coherent even with this setting. See also + * &drm_i915_gem_object.cache_coherent for more details. + * + * Note that on platforms with a shared LLC this should ideally only be + * used for scanout surfaces, otherwise we end up over-flushing in some + * places. + */ + I915_CACHE_NONE = 0, + /** + * @I915_CACHE_LLC: + * + * Coherent with the CPU cache. If the cache is dirty, then the GPU will + * ensure that access remains coherent, when both reading and writing + * through the CPU cache. + * + * Not used for scanout surfaces. + * + * Applies to both platforms with shared LLC(HAS_LLC), and snooping + * based platforms(HAS_SNOOP). + * + * This should be the default for platforms which share the LLC with the + * CPU. The only exception is scanout objects, where the display engine + * is not coherent with the LLC. For such objects I915_CACHE_NONE or + * I915_CACHE_WT should be used. + */ + I915_CACHE_LLC, + /** + * @I915_CACHE_L3_LLC: + * + * Explicitly enable the Gfx L3 cache, with snooped LLC. + * + * The Gfx L3 sits between the domain specific caches, e.g + * sampler/render caches, and the larger LLC. LLC is coherent with the + * GPU, but L3 is only visible to the GPU, so likely needs to be flushed + * when the workload completes. + * + * Not used for scanout surfaces. + * + * Only exposed on some gen7 + GGTT. More recent hardware has dropped + * this. + */ + I915_CACHE_L3_LLC, + /** + * @I915_CACHE_WT: + * + * hsw:gt3e Write-through for scanout buffers. + */ + I915_CACHE_WT, +}; + enum i915_map_type { I915_MAP_WB = 0, I915_MAP_WC, @@ -229,14 +299,112 @@ struct drm_i915_gem_object { unsigned int mem_flags; #define I915_BO_FLAG_STRUCT_PAGE BIT(0) /* Object backed by struct pages */ #define I915_BO_FLAG_IOMEM BIT(1) /* Object backed by IO memory */ - /* - * Is the object to be mapped as read-only to the GPU - * Only honoured if hardware has relevant pte bit + /** + * @cache_level: The desired GTT caching level. + * + * See enum i915_cache_level for possible values, along with what + * each does. */ unsigned int cache_level:3; - unsigned int cache_coherent:2; + /** + * @cache_coherent: + * + * Track whether the pages are coherent with the GPU if reading or + * writing through the CPU caches. The largely depends on the + * @cache_level setting. + * + * On platforms which don't have the shared LLC(HAS_SNOOP), like on Atom + * platforms, coherency must be explicitly requested with some special + * GTT caching bits(see enum i915_cache_level). When enabling coherency + * it does come at a performance and power cost on such platforms. On + * the flip side the kernel does need to manually flush any buffers + * which need to be coherent with the GPU, if the object is not + * coherent i.e @cache_coherent is zero. + * + * On platforms that share the LLC with the CPU(HAS_LLC), all GT memory + * access will automatically snoop the CPU caches(even with CACHE_NONE). + * The one exception is when dealing with the display engine, like with + * scanout surfaces. To handle this the kernel will always flush the + * surface out of the CPU caches when preparing it for scanout. Also + * note that since scanout surfaces are only ever read by the display + * engine we only need to care about flushing any writes through the CPU + * cache, reads on the other hand will always be coherent. + * + * Something strange here is why @cache_coherent is not a simple + * boolean, i.e coherent vs non-coherent. The reasoning for this is back + * to the display engine not being fully coherent. As a result scanout + * surfaces will either be marked as I915_CACHE_NONE or I915_CACHE_WT. + * In the case of seeing I915_CACHE_NONE the kernel makes the assumption + * that this is likely a scanout surface, and will set @cache_coherent + * as only I915_BO_CACHE_COHERENT_FOR_READ, on platforms with the shared + * LLC. The kernel uses this to always flush writes through the CPU + * cache as early as possible, where it can, in effect keeping + * @cache_dirty clean, so we can potentially avoid stalling when + * flushing the surface just before doing the scanout. This does mean + * we might unnecessarily flush non-scanout objects in some places, but + * the default assumption is that all normal objects should be using + * I915_CACHE_LLC, at least on platforms with the shared LLC. + * + * Supported values: + * + * I915_BO_CACHE_COHERENT_FOR_READ: + * + * On shared LLC platforms, we use this for special scanout surfaces, + * where the display engine is not coherent with the CPU cache. As such + * we need to ensure we flush any writes before doing the scanout. As an + * optimisation we try to flush any writes as early as possible to avoid + * stalling later. + * + * Thus for scanout surfaces using I915_CACHE_NONE, on shared LLC + * platforms, we use: + * + * cache_coherent = I915_BO_CACHE_COHERENT_FOR_READ + * + * While for normal objects that are fully coherent we use: + * + * cache_coherent = I915_BO_CACHE_COHERENT_FOR_READ | + * I915_BO_CACHE_COHERENT_FOR_WRITE + * + * And then for objects that are not coherent at all we use: + * + * cache_coherent = 0 + * + * I915_BO_CACHE_COHERENT_FOR_WRITE: + * + * When writing through the CPU cache, the GPU is still coherent. Note + * that this also implies I915_BO_CACHE_COHERENT_FOR_READ. + */ #define I915_BO_CACHE_COHERENT_FOR_READ BIT(0) #define I915_BO_CACHE_COHERENT_FOR_WRITE BIT(1) + unsigned int cache_coherent:2; + + /** + * @cache_dirty: + * + * Track if we are we dirty with writes through the CPU cache for this + * object. As a result reading directly from main memory might yield + * stale data. + * + * This also ties into whether the kernel is tracking the object as + * coherent with the GPU, as per @cache_coherent, as it determines if + * flushing might be needed at various points. + * + * Another part of @cache_dirty is managing flushing when first + * acquiring the pages for system memory, at this point the pages are + * considered foreign, so the default assumption is that the cache is + * dirty, for example the page zeroing done by the kernel might leave + * writes though the CPU cache, or swapping-in, while the actual data in + * main memory is potentially stale. Note that this is a potential + * security issue when dealing with userspace objects and zeroing. Now, + * whether we actually need apply the big sledgehammer of flushing all + * the pages on acquire depends on if @cache_coherent is marked as + * I915_BO_CACHE_COHERENT_FOR_WRITE, i.e that the GPU will be coherent + * for both reads and writes though the CPU cache. + * + * Note that on shared LLC platforms we still apply the heavy flush for + * I915_CACHE_NONE objects, under the assumption that this is going to + * be used for scanout. + */ unsigned int cache_dirty:1; /** diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 0321a1f9738d..f97792ccc199 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -394,15 +394,6 @@ struct drm_i915_display_funcs { void (*read_luts)(struct intel_crtc_state *crtc_state); }; -enum i915_cache_level { - I915_CACHE_NONE = 0, - I915_CACHE_LLC, /* also used for snoopable memory on non-LLC */ - I915_CACHE_L3_LLC, /* gen7+, L3 sits between the domain specifc - caches, eg sampler/render caches, and the - large Last-Level-Cache. LLC is coherent with - the CPU, but L3 is only visible to the GPU. */ - I915_CACHE_WT, /* hsw:gt3e WriteThrough for scanouts */ -}; #define I915_COLOR_UNEVICTABLE (-1) /* a non-vma sharing the address space */ -- 2.26.3

3 3

Re: [PATCH v3 1/3] drm/loongson: Add DRM Driver for Loongson 7A1000 bridge chip
by Dan Carpenter 23 Jul '21

23 Jul '21

On Fri, Jul 23, 2021 at 11:12:49AM +0800, lichenyang wrote: > +static int loongson_drm_load(struct drm_device *dev) > +{ > + struct loongson_device *ldev; > + int ret; > + > + ldev = devm_kzalloc(dev->dev, sizeof(*ldev), GFP_KERNEL); > + if (!ldev) > + return -ENOMEM; > + > + dev->dev_private = ldev; > + ldev->dev = dev; > + > + ret = loongson_device_init(dev); > + if (ret) > + goto err; > + > + ret = drmm_vram_helper_init(dev, ldev->vram_start, ldev->vram_size); > + if (ret) { > + drm_err(dev, "Error initializing vram %d\n", ret); > + goto err; > + } > + > + drm_mode_config_init(dev); > + dev->mode_config.funcs = (void *)&loongson_mode_funcs; > + dev->mode_config.min_width = 1; > + dev->mode_config.min_height = 1; > + dev->mode_config.max_width = 4096; > + dev->mode_config.max_height = 4096; > + dev->mode_config.preferred_depth = 32; > + dev->mode_config.prefer_shadow = 1; > + dev->mode_config.fb_base = ldev->vram_start; > + > + ret = loongson_modeset_init(ldev); > + if (ret) { > + drm_err(dev, "Fatal error during modeset init: %d\n", ret); > + goto err; > + } > + > + drm_kms_helper_poll_init(dev); > + drm_mode_config_reset(dev); > + > + return 0; > + > +err: > + kfree(ldev); I'm sorry, in the earlier version I told you to add this kfree() but this is devm_ allocated so the kfree() is wrong and will lead to a double free. My bad. That's on me. > + drm_err(dev, "failed to initialize drm driver: %d\n", ret); > + return ret; > +} regards, dan carpenter

1 0

[PATCH 0/3] drm/msm: Improved devfreq tuning
by Rob Clark 23 Jul '21

23 Jul '21

From: Rob Clark <robdclark(a)chromium.org> This is the outcome of trying to fix some bad gpu freq behavior seen in some use-cases, in particular mobile games that throttle themselves to 30fps. With the existing tuning, we'd end up spending most of the time that we should be running fast at a low freq, and most of the idle time at a high freq. First two patches are prep, 3/3 is the interesting bit. See the patch description in 3/3 for more details. Rob Clark (3): drm/msm: Split out devfreq handling drm/msm: Split out get_freq() helper drm/msm: Devfreq tuning drivers/gpu/drm/msm/Makefile | 1 + drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 4 +- drivers/gpu/drm/msm/msm_gpu.c | 124 ++-------------- drivers/gpu/drm/msm/msm_gpu.h | 27 +++- drivers/gpu/drm/msm/msm_gpu_devfreq.c | 203 ++++++++++++++++++++++++++ 5 files changed, 238 insertions(+), 121 deletions(-) create mode 100644 drivers/gpu/drm/msm/msm_gpu_devfreq.c -- 2.31.1

2 4

[PATCH] drm/msm/dp: signal audio plugged change at dp_pm_resume
by Kuogee Hsieh 23 Jul '21

23 Jul '21

There is a scenario that dp cable is unplugged from DUT during system suspended will cause audio option state does not match real connection state. Fix this problem by Signaling audio plugged change with realtime connection status at dp_pm_resume() so that audio option will be in correct state after system resumed. Fixes: bd52cfedb5a8 ("drm/msm/dp: power off DP phy at suspend") Signed-off-by: Kuogee Hsieh <khsieh(a)codeaurora.org> --- drivers/gpu/drm/msm/dp/dp_display.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/msm/dp/dp_display.c b/drivers/gpu/drm/msm/dp/dp_display.c index 78c5301..2b660e9 100644 --- a/drivers/gpu/drm/msm/dp/dp_display.c +++ b/drivers/gpu/drm/msm/dp/dp_display.c @@ -1339,6 +1339,10 @@ static int dp_pm_resume(struct device *dev) else dp->dp_display.is_connected = false; + dp_display_handle_plugged_change(g_dp_display, + dp->dp_display.is_connected); + + mutex_unlock(&dp->event_mutex); return 0; -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project

2 1

[PATCH v3] drm/shmobile: Convert to Linux IRQ interfaces
by Thomas Zimmermann 23 Jul '21

23 Jul '21

Drop the DRM IRQ midlayer in favor of Linux IRQ interfaces. DRM's IRQ helpers are mostly useful for UMS drivers. Modern KMS drivers don't benefit from using it. v3: * return error if (ret < 0) (Geert) * remove duplicate error message (Geert) v2: * handle errors in platform_get_irq() (Geert, Sergei) * store IRQ number in struct shmob_drm_device (Laurent) Signed-off-by: Thomas Zimmermann <tzimmermann(a)suse.de> Acked-by: Sam Ravnborg <sam(a)ravnborg.org> --- drivers/gpu/drm/shmobile/shmob_drm_drv.c | 14 +++++++++----- drivers/gpu/drm/shmobile/shmob_drm_drv.h | 1 + 2 files changed, 10 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/shmobile/shmob_drm_drv.c b/drivers/gpu/drm/shmobile/shmob_drm_drv.c index 0a02b7092c04..7db01904d18d 100644 --- a/drivers/gpu/drm/shmobile/shmob_drm_drv.c +++ b/drivers/gpu/drm/shmobile/shmob_drm_drv.c @@ -18,7 +18,6 @@ #include <drm/drm_crtc_helper.h> #include <drm/drm_drv.h> #include <drm/drm_gem_cma_helper.h> -#include <drm/drm_irq.h> #include <drm/drm_probe_helper.h> #include <drm/drm_vblank.h> @@ -130,7 +129,6 @@ DEFINE_DRM_GEM_CMA_FOPS(shmob_drm_fops); static const struct drm_driver shmob_drm_driver = { .driver_features = DRIVER_GEM | DRIVER_MODESET, - .irq_handler = shmob_drm_irq, DRM_GEM_CMA_DRIVER_OPS, .fops = &shmob_drm_fops, .name = "shmob-drm", @@ -183,7 +181,7 @@ static int shmob_drm_remove(struct platform_device *pdev) drm_dev_unregister(ddev); drm_kms_helper_poll_fini(ddev); - drm_irq_uninstall(ddev); + free_irq(sdev->irq, ddev); drm_dev_put(ddev); return 0; @@ -258,7 +256,13 @@ static int shmob_drm_probe(struct platform_device *pdev) goto err_modeset_cleanup; } - ret = drm_irq_install(ddev, platform_get_irq(pdev, 0)); + ret = platform_get_irq(pdev, 0); + if (ret < 0) + goto err_modeset_cleanup; + sdev->irq = ret; + + ret = request_irq(sdev->irq, shmob_drm_irq, 0, ddev->driver->name, + ddev); if (ret < 0) { dev_err(&pdev->dev, "failed to install IRQ handler\n"); goto err_modeset_cleanup; @@ -275,7 +279,7 @@ static int shmob_drm_probe(struct platform_device *pdev) return 0; err_irq_uninstall: - drm_irq_uninstall(ddev); + free_irq(sdev->irq, ddev); err_modeset_cleanup: drm_kms_helper_poll_fini(ddev); err_free_drm_dev: diff --git a/drivers/gpu/drm/shmobile/shmob_drm_drv.h b/drivers/gpu/drm/shmobile/shmob_drm_drv.h index 80dc4b1020aa..4964ddd5ab74 100644 --- a/drivers/gpu/drm/shmobile/shmob_drm_drv.h +++ b/drivers/gpu/drm/shmobile/shmob_drm_drv.h @@ -29,6 +29,7 @@ struct shmob_drm_device { u32 lddckr; u32 ldmt1r; + unsigned int irq; spinlock_t irq_lock; /* Protects hardware LDINTR register */ struct drm_device *ddev; -- 2.32.0

2 2

[PATCH v3 0/3] Add ilitek ili9341 panel driver
by dillon.minfei＠gmail.com 23 Jul '21

23 Jul '21

From: Dillon Min <dillon.minfei(a)gmail.com> Since the st,sf-tc240t-9370-t dts binding already exist in stm32f429-disco.dts but, the panel driver didn't get accepted from mainline. it's time to submit patch fot it. This driver can support two different interface by different dts bindings: - spi+dpi, use spi to configure register, dpi for graphic data. st,sf-tc240t-9370-t - only spi, just like tiny/ili9341.c (actually, this part is copy from tiny) adafruit,yx240qv29 I submited the first patch last year, you can find it at [1]. this patch has one major difference from that one, which is replace the low level communication way, from spi_sync() to mipi_dbi_{command, command_stackbuf}() interface, referred from Linus's patch [2]. both the two dpi/dbi interface was tested on stm32f429-disco board, if anyone want to verify this patch, you need apply the clk patch for this board first, you can get it from [3] [1] "drm/panel: Add ilitek ili9341 panel driver" https://lore.kernel.org/lkml/1590378348-8115-7-git-send-email-dillon.minfei… [2] "drm/panel: s6e63m0: Switch to DBI abstraction for SPI" https://lore.kernel.org/dri-devel/20210611214243.669892-1-linus.walleij@lin… [3] https://lore.kernel.org/lkml/1590378348-8115-6-git-send-email-dillon.minfei… v3: - add Fixes tags. - collect reviewed-by tags from linus and jagan. - replace DRM_ERROR() with dev_err() or drm_err(). - remove kernel-doc markers from struct ili9341_config{}. - reorder include headers. - remove the struct device *dev from struct ili9341{}. - restructure the ili9341_probe() function, add two ili9341_{dbi,dpi)_probe() to make it more readable according to jagan's suggestion, thanks. for the full drm driver exist in drm/panel need Sam and Laurent's feedback. so, not cover this part at this time, will be update in v4. v2 link: https://lore.kernel.org/lkml/1626853288-31223-1-git-send-email-dillon.minfe… v2: - replace vcc regulator to bulk regulators in driver, from linus suggestion. - fix dtbs_check warnings on ili9341 dts binding check. - add bulk regulation node in ilitek,ili9341.yaml. v1 link: https://lore.kernel.org/lkml/1626430843-23823-1-git-send-email-dillon.minfe… Dillon Min (3): dt-bindings: display: panel: Add ilitek ili9341 panel bindings ARM: dts: stm32: fix dtbs_check warning on ili9341 dts binding drm/panel: Add ilitek ili9341 panel driver .../bindings/display/panel/ilitek,ili9341.yaml | 78 ++ arch/arm/boot/dts/stm32f429-disco.dts | 2 +- drivers/gpu/drm/panel/Kconfig | 12 + drivers/gpu/drm/panel/Makefile | 1 + drivers/gpu/drm/panel/panel-ilitek-ili9341.c | 786 +++++++++++++++++++++ 5 files changed, 878 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/display/panel/ilitek,ili9341.yaml create mode 100644 drivers/gpu/drm/panel/panel-ilitek-ili9341.c -- 2.7.4

1 3

[PATCH AUTOSEL 5.10 08/17] drm/ttm: add a check against null pointer dereference
by Sasha Levin 23 Jul '21

23 Jul '21

From: Zheyu Ma <zheyuma97(a)gmail.com> [ Upstream commit 9e5c772954406829e928dbe59891d08938ead04b ] When calling ttm_range_man_fini(), 'man' may be uninitialized, which may cause a null pointer dereference bug. Fix this by checking if it is a null pointer. This log reveals it: [ 7.902580 ] BUG: kernel NULL pointer dereference, address: 0000000000000058 [ 7.905721 ] RIP: 0010:ttm_range_man_fini+0x40/0x160 [ 7.911826 ] Call Trace: [ 7.911826 ] radeon_ttm_fini+0x167/0x210 [ 7.911826 ] radeon_bo_fini+0x15/0x40 [ 7.913767 ] rs400_fini+0x55/0x80 [ 7.914358 ] radeon_device_fini+0x3c/0x140 [ 7.914358 ] radeon_driver_unload_kms+0x5c/0xe0 [ 7.914358 ] radeon_driver_load_kms+0x13a/0x200 [ 7.914358 ] ? radeon_driver_unload_kms+0xe0/0xe0 [ 7.914358 ] drm_dev_register+0x1db/0x290 [ 7.914358 ] radeon_pci_probe+0x16a/0x230 [ 7.914358 ] local_pci_probe+0x4a/0xb0 Signed-off-by: Zheyu Ma <zheyuma97(a)gmail.com> Reviewed-by: Christian König <christian.koenig(a)amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/1626274459-8148-1-git-send-em… Signed-off-by: Christian König <christian.koenig(a)amd.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/gpu/drm/ttm/ttm_range_manager.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/ttm/ttm_range_manager.c b/drivers/gpu/drm/ttm/ttm_range_manager.c index 1da0e277c511..ce9d127edbb5 100644 --- a/drivers/gpu/drm/ttm/ttm_range_manager.c +++ b/drivers/gpu/drm/ttm/ttm_range_manager.c @@ -147,6 +147,9 @@ int ttm_range_man_fini(struct ttm_bo_device *bdev, struct drm_mm *mm = &rman->mm; int ret; + if (!man) + return 0; + ttm_resource_manager_set_used(man, false); ret = ttm_resource_manager_force_list_clean(bdev, man); -- 2.30.2

1 0

[PATCH AUTOSEL 5.13 10/19] drm/ttm: add a check against null pointer dereference
by Sasha Levin 23 Jul '21

23 Jul '21

From: Zheyu Ma <zheyuma97(a)gmail.com> [ Upstream commit 9e5c772954406829e928dbe59891d08938ead04b ] When calling ttm_range_man_fini(), 'man' may be uninitialized, which may cause a null pointer dereference bug. Fix this by checking if it is a null pointer. This log reveals it: [ 7.902580 ] BUG: kernel NULL pointer dereference, address: 0000000000000058 [ 7.905721 ] RIP: 0010:ttm_range_man_fini+0x40/0x160 [ 7.911826 ] Call Trace: [ 7.911826 ] radeon_ttm_fini+0x167/0x210 [ 7.911826 ] radeon_bo_fini+0x15/0x40 [ 7.913767 ] rs400_fini+0x55/0x80 [ 7.914358 ] radeon_device_fini+0x3c/0x140 [ 7.914358 ] radeon_driver_unload_kms+0x5c/0xe0 [ 7.914358 ] radeon_driver_load_kms+0x13a/0x200 [ 7.914358 ] ? radeon_driver_unload_kms+0xe0/0xe0 [ 7.914358 ] drm_dev_register+0x1db/0x290 [ 7.914358 ] radeon_pci_probe+0x16a/0x230 [ 7.914358 ] local_pci_probe+0x4a/0xb0 Signed-off-by: Zheyu Ma <zheyuma97(a)gmail.com> Reviewed-by: Christian König <christian.koenig(a)amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/1626274459-8148-1-git-send-em… Signed-off-by: Christian König <christian.koenig(a)amd.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/gpu/drm/ttm/ttm_range_manager.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/ttm/ttm_range_manager.c b/drivers/gpu/drm/ttm/ttm_range_manager.c index 707e5c152896..ed053fd15c90 100644 --- a/drivers/gpu/drm/ttm/ttm_range_manager.c +++ b/drivers/gpu/drm/ttm/ttm_range_manager.c @@ -146,6 +146,9 @@ int ttm_range_man_fini(struct ttm_device *bdev, struct drm_mm *mm = &rman->mm; int ret; + if (!man) + return 0; + ttm_resource_manager_set_used(man, false); ret = ttm_resource_manager_evict_all(bdev, man); -- 2.30.2

1 0

← Newer
1
...
37
38
39
40
41
42
43
...
83
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel July 2021