dri-devel July 2021

dri-devel@lists.freedesktop.org

321 participants
829 discussions

[PATCH v4 1/2] drm/panel: simple: Add support for EDT ETMV570G2DHU panel
by Yunus Bas 09 Jul '21

09 Jul '21

From: Stefan Riedmueller <s.riedmueller(a)phytec.de> This patch adds support for the EDT ETMV570G2DHU 5.7" (640x480) lcd panel to DRM simple panel driver. Signed-off-by: Stefan Riedmueller <s.riedmueller(a)phytec.de> Signed-off-by: Yunus Bas <y.bas(a)phytec.de> --- Changes in v4: - Moved code to proper place to keep alphabetic order --- drivers/gpu/drm/panel/panel-simple.c | 29 ++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+) diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c index 21939d4352cf..7f3918fee250 100644 --- a/drivers/gpu/drm/panel/panel-simple.c +++ b/drivers/gpu/drm/panel/panel-simple.c @@ -2046,6 +2046,32 @@ static const struct panel_desc edt_etm0700g0bdh6 = { .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE, }; +static const struct drm_display_mode edt_etmv570g2dhu_mode = { + .clock = 25175, + .hdisplay = 640, + .hsync_start = 640, + .hsync_end = 640 + 16, + .htotal = 640 + 16 + 30 + 114, + .vdisplay = 480, + .vsync_start = 480 + 10, + .vsync_end = 480 + 10 + 3, + .vtotal = 480 + 10 + 3 + 35, + .flags = DRM_MODE_FLAG_PVSYNC | DRM_MODE_FLAG_PHSYNC, +}; + +static const struct panel_desc edt_etmv570g2dhu = { + .modes = &edt_etmv570g2dhu_mode, + .num_modes = 1, + .bpc = 6, + .size = { + .width = 115, + .height = 86, + }, + .bus_format = MEDIA_BUS_FMT_RGB888_1X24, + .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE, + .connector_type = DRM_MODE_CONNECTOR_DPI, +}; + static const struct display_timing evervision_vgg804821_timing = { .pixelclock = { 27600000, 33300000, 50000000 }, .hactive = { 800, 800, 800 }, @@ -4350,6 +4376,9 @@ static const struct of_device_id platform_of_match[] = { }, { .compatible = "edt,etm0700g0edh6", .data = &edt_etm0700g0bdh6, + }, { + .compatible = "edt,etmv570g2dhu", + .data = &edt_etmv570g2dhu, }, { .compatible = "evervision,vgg804821", .data = &evervision_vgg804821, -- 2.30.0

2 2

[PATCH v1] fix vmwgfx compilation error due to a missing include
by Tong Zhang 09 Jul '21

09 Jul '21

This patch fixes vmwgfx driver compilation error due to a missing include drivers/gpu/drm/vmwgfx/vmwgfx_drv.c: In function ‘vmw_vram_manager_init’: drivers/gpu/drm/vmwgfx/vmwgfx_drv.c:678:8: error: implicit declaration of function ‘ttm_range_man_init’ [-Werror=implicit-function-declaration] 678 | ret = ttm_range_man_init(&dev_priv->bdev, TTM_PL_VRAM, false, | ^~~~~~~~~~~~~~~~~~ drivers/gpu/drm/vmwgfx/vmwgfx_drv.c: In function ‘vmw_vram_manager_fini’: drivers/gpu/drm/vmwgfx/vmwgfx_drv.c:690:2: error: implicit declaration of function ‘ttm_range_man_fini’ [-Werror=implicit-function-declaration] 690 | ttm_range_man_fini(&dev_priv->bdev, TTM_PL_VRAM); | ^~~~~~~~~~~~~~~~~~ cc1: some warnings being treated as errors Signed-off-by: Tong Zhang <ztong0001(a)gmail.com> --- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c index 6f5ea00973e0..6eb93aa2f311 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c @@ -37,6 +37,7 @@ #include <drm/drm_sysfs.h> #include <drm/ttm/ttm_bo_driver.h> #include <drm/ttm/ttm_placement.h> +#include <drm/ttm/ttm_range_manager.h> #include <generated/utsrelease.h> #include "ttm_object.h" -- 2.25.1

4 3

[PATCH] drm/gma500: Add the missed drm_gem_object_put() in psb_user_framebuffer_create()
by Jing Xiangfeng 09 Jul '21

09 Jul '21

psb_user_framebuffer_create() misses to call drm_gem_object_put() in an error path. Add the missed function call to fix it. Signed-off-by: Jing Xiangfeng <jingxiangfeng(a)huawei.com> --- drivers/gpu/drm/gma500/framebuffer.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/gma500/framebuffer.c b/drivers/gpu/drm/gma500/framebuffer.c index ebe9dccf2d83..0b8648396fb2 100644 --- a/drivers/gpu/drm/gma500/framebuffer.c +++ b/drivers/gpu/drm/gma500/framebuffer.c @@ -352,6 +352,7 @@ static struct drm_framebuffer *psb_user_framebuffer_create const struct drm_mode_fb_cmd2 *cmd) { struct drm_gem_object *obj; + struct drm_framebuffer *fb; /* * Find the GEM object and thus the gtt range object that is @@ -362,7 +363,11 @@ static struct drm_framebuffer *psb_user_framebuffer_create return ERR_PTR(-ENOENT); /* Let the core code do all the work */ - return psb_framebuffer_create(dev, cmd, obj); + fb = psb_framebuffer_create(dev, cmd, obj); + if (IS_ERR(fb)) + drm_gem_object_put(obj); + + return fb; } static int psbfb_probe(struct drm_fb_helper *fb_helper, -- 2.26.0.106.g9fadedd

2 1

[PATCH v3 1/2] drm/panel: simple: Add support for EDT ETMV570G2DHU panel
by Yunus Bas 09 Jul '21

09 Jul '21

From: Stefan Riedmueller <s.riedmueller(a)phytec.de> This patch adds support for the EDT ETMV570G2DHU 5.7" (640x480) lcd panel to DRM simple panel driver. Signed-off-by: Stefan Riedmueller <s.riedmueller(a)phytec.de> Signed-off-by: Yunus Bas <y.bas(a)phytec.de> --- Changes in v3: - No changes in general, added additional maintainers and also sending to general kernel mailing list --- drivers/gpu/drm/panel/panel-simple.c | 29 ++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+) diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c index 21939d4352cf..07433bff6c2b 100644 --- a/drivers/gpu/drm/panel/panel-simple.c +++ b/drivers/gpu/drm/panel/panel-simple.c @@ -2008,6 +2008,32 @@ static const struct panel_desc edt_et057090dhu = { .connector_type = DRM_MODE_CONNECTOR_DPI, }; +static const struct drm_display_mode edt_etmv570g2dhu_mode = { + .clock = 25175, + .hdisplay = 640, + .hsync_start = 640, + .hsync_end = 640 + 16, + .htotal = 640 + 16 + 30 + 114, + .vdisplay = 480, + .vsync_start = 480 + 10, + .vsync_end = 480 + 10 + 3, + .vtotal = 480 + 10 + 3 + 35, + .flags = DRM_MODE_FLAG_PVSYNC | DRM_MODE_FLAG_PHSYNC, +}; + +static const struct panel_desc edt_etmv570g2dhu = { + .modes = &edt_etmv570g2dhu_mode, + .num_modes = 1, + .bpc = 6, + .size = { + .width = 115, + .height = 86, + }, + .bus_format = MEDIA_BUS_FMT_RGB888_1X24, + .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE, + .connector_type = DRM_MODE_CONNECTOR_DPI, +}; + static const struct drm_display_mode edt_etm0700g0dh6_mode = { .clock = 33260, .hdisplay = 800, @@ -4338,6 +4364,9 @@ static const struct of_device_id platform_of_match[] = { }, { .compatible = "edt,et057090dhu", .data = &edt_et057090dhu, + }, { + .compatible = "edt,etmv570g2dhu", + .data = &edt_etmv570g2dhu, }, { .compatible = "edt,et070080dh6", .data = &edt_etm0700g0dh6, -- 2.30.0

3 7

[PATCH] drm/panel: panel-simple: Fix proper bpc for ytc700tlag_05_201c
by Jagan Teki 09 Jul '21

09 Jul '21

ytc700tlag_05_201c panel support 8 bpc not 6 bpc as per recent testing in i.MX8MM platform. Fix it. Signed-off-by: Jagan Teki <jagan(a)amarulasolutions.com> --- drivers/gpu/drm/panel/panel-simple.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c index 9be050ab372f..6f4151729fb7 100644 --- a/drivers/gpu/drm/panel/panel-simple.c +++ b/drivers/gpu/drm/panel/panel-simple.c @@ -4164,7 +4164,7 @@ static const struct drm_display_mode yes_optoelectronics_ytc700tlag_05_201c_mode static const struct panel_desc yes_optoelectronics_ytc700tlag_05_201c = { .modes = &yes_optoelectronics_ytc700tlag_05_201c_mode, .num_modes = 1, - .bpc = 6, + .bpc = 8, .size = { .width = 154, .height = 90, -- 2.25.1

2 3

[PATCH v3] drm/panel: Add support for E Ink VB3300-KCA
by Alistair Francis 09 Jul '21

09 Jul '21

Add support for the 10.3" E Ink panel described at: https://www.eink.com/product.html?type=productdetail&id=7 Signed-off-by: Alistair Francis <alistair(a)alistair23.me> Acked-by: Rob Herring <robh(a)kernel.org> --- .../bindings/display/panel/panel-simple.yaml | 2 ++ .../devicetree/bindings/vendor-prefixes.yaml | 2 ++ drivers/gpu/drm/panel/panel-simple.c | 29 +++++++++++++++++++ 3 files changed, 33 insertions(+) diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml index b3797ba2698b..799e20222551 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -128,6 +128,8 @@ properties: # Emerging Display Technology Corp. WVGA TFT Display with capacitive touch - edt,etm0700g0dh6 - edt,etm0700g0edh6 + # E Ink VB3300-KCA + - eink,vb3300-kca # Evervision Electronics Co. Ltd. VGG804821 5.0" WVGA TFT LCD Panel - evervision,vgg804821 # Foxlink Group 5" WVGA TFT LCD panel diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 0199728d2eaf..3612c6020fe4 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -335,6 +335,8 @@ patternProperties: description: eGalax_eMPIA Technology Inc "^einfochips,.*": description: Einfochips + "^eink,.*": + description: E Ink Corporation "^elan,.*": description: Elan Microelectronic Corp. "^element14,.*": diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c index 21939d4352cf..210377b03f6f 100644 --- a/drivers/gpu/drm/panel/panel-simple.c +++ b/drivers/gpu/drm/panel/panel-simple.c @@ -2046,6 +2046,32 @@ static const struct panel_desc edt_etm0700g0bdh6 = { .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE, }; +static const struct display_timing eink_vb3300_kca_timing = { + .pixelclock = { 40000000, 40000000, 40000000 }, + .hactive = { 334, 334, 334 }, + .hfront_porch = { 1, 1, 1 }, + .hback_porch = { 1, 1, 1 }, + .hsync_len = { 1, 1, 1 }, + .vactive = { 1405, 1405, 1405 }, + .vfront_porch = { 1, 1, 1 }, + .vback_porch = { 1, 1, 1 }, + .vsync_len = { 1, 1, 1 }, + .flags = DISPLAY_FLAGS_HSYNC_LOW | DISPLAY_FLAGS_VSYNC_LOW | + DISPLAY_FLAGS_DE_HIGH | DISPLAY_FLAGS_PIXDATA_POSEDGE, +}; + +static const struct panel_desc eink_vb3300_kca = { + .timings = &eink_vb3300_kca_timing, + .num_timings = 1, + .bpc = 6, + .size = { + .width = 157, + .height = 209, + }, + .bus_format = MEDIA_BUS_FMT_RGB888_1X24, + .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE, +}; + static const struct display_timing evervision_vgg804821_timing = { .pixelclock = { 27600000, 33300000, 50000000 }, .hactive = { 800, 800, 800 }, @@ -4344,6 +4370,9 @@ static const struct of_device_id platform_of_match[] = { }, { .compatible = "edt,etm0700g0dh6", .data = &edt_etm0700g0dh6, + }, { + .compatible = "eink,vb3300-kca", + .data = &eink_vb3300_kca, }, { .compatible = "edt,etm0700g0bdh6", .data = &edt_etm0700g0bdh6, -- 2.31.1

2 1

[PATCH] drm/i915/ehl: unconditionally flush the pages on acquire
by Matthew Auld 09 Jul '21

09 Jul '21

EHL and JSL add the 'Bypass LLC' MOCS entry, which should make it possible for userspace to bypass the GTT caching bits set by the kernel, as per the given object cache_level. This is troublesome since the heavy flush we apply when first acquiring the pages is skipped if the kernel thinks the object is coherent with the GPU. As a result it might be possible to bypass the cache and read the contents of the page directly, which could be stale data. If it's just a case of userspace shooting themselves in the foot then so be it, but since i915 takes the stance of always zeroing memory before handing it to userspace, we need to prevent this. BSpec: 34007 References: 046091758b50 ("Revert "drm/i915/ehl: Update MOCS table for EHL"") Signed-off-by: Matthew Auld <matthew.auld(a)intel.com> Cc: Tejas Upadhyay <tejaskumarx.surendrakumar.upadhyay(a)intel.com> Cc: Francisco Jerez <francisco.jerez.plata(a)intel.com> Cc: Lucas De Marchi <lucas.demarchi(a)intel.com> Cc: Jon Bloomfield <jon.bloomfield(a)intel.com> Cc: Chris Wilson <chris.p.wilson(a)intel.com> Cc: Matt Roper <matthew.d.roper(a)intel.com> --- drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 29 +++++++++++++++++++++-- 1 file changed, 27 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c index 6a04cce188fc..7e9ec68cce9e 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c @@ -298,11 +298,12 @@ __i915_gem_object_release_shmem(struct drm_i915_gem_object *obj, void i915_gem_object_put_pages_shmem(struct drm_i915_gem_object *obj, struct sg_table *pages) { + struct drm_i915_private *i915 = to_i915(obj->base.dev); struct sgt_iter sgt_iter; struct pagevec pvec; struct page *page; - GEM_WARN_ON(IS_DGFX(to_i915(obj->base.dev))); + GEM_WARN_ON(IS_DGFX(i915)); __i915_gem_object_release_shmem(obj, pages, true); i915_gem_gtt_finish_pages(obj, pages); @@ -325,7 +326,12 @@ void i915_gem_object_put_pages_shmem(struct drm_i915_gem_object *obj, struct sg_ } if (pagevec_count(&pvec)) check_release_pagevec(&pvec); - obj->mm.dirty = false; + + /* See the comment in shmem_object_init() for why we need this */ + if (IS_JSL_EHL(i915) && obj->flags & I915_BO_ALLOC_USER) + obj->mm.dirty = true; + else + obj->mm.dirty = false; sg_free_table(pages); kfree(pages); @@ -539,6 +545,25 @@ static int shmem_object_init(struct intel_memory_region *mem, i915_gem_object_set_cache_coherency(obj, cache_level); + /* + * EHL and JSL add the 'Bypass LLC' MOCS entry, which should make it + * possible for userspace to bypass the GTT caching bits set by the + * kernel, as per the given object cache_level. This is troublesome + * since the heavy flush we apply when first gathering the pages is + * skipped if the kernel thinks the object is coherent with the GPU. As + * a result it might be possible to bypass the cache and read the + * contents of the page directly, which could be stale data. If it's + * just a case of userspace shooting themselves in the foot then so be + * it, but since i915 takes the stance of always zeroing memory before + * handing it to userspace, we need to prevent this. + * + * By setting cache_dirty here we make the clflush when first acquiring + * the pages unconditional on such platforms. We also set this again in + * put_pages(). + */ + if (IS_JSL_EHL(i915) && flags & I915_BO_ALLOC_USER) + obj->cache_dirty = true; + i915_gem_object_init_memory_region(obj, mem); return 0; -- 2.26.3

3 3

[PATCH] drm/vgem: Restore mmap functionality
by Thomas Zimmermann 09 Jul '21

09 Jul '21

Commit 375cca1cfeb5 ("drm/vgem: Implement mmap as GEM object function") accidentally removed the actual mmap functionality from vgem. Restore the original implementation and VMA flags. Fixes access to unmapped memory: [ 106.591744] BUG: KASAN: vmalloc-out-of-bounds in do_fault+0x38/0x480 [ 106.598154] Read of size 8 at addr ffffffffc10c44a8 by task vgem_basic/1514 [ 106.605173] [ 106.606678] CPU: 1 PID: 1514 Comm: vgem_basic Tainted: G E 5.13.0-1-default+ #990 [ 106.615535] Hardware name: Dell Inc. OptiPlex 9020/0N4YC8, BIOS A24 10/24/2018 [ 106.622818] Call Trace: [ 106.625289] dump_stack+0xa5/0xdc [ 106.628642] print_address_description.constprop.0+0x18/0x100 [ 106.634439] ? do_fault+0x38/0x480 [ 106.637872] kasan_report.cold+0x7c/0xd8 [ 106.641834] ? do_fault+0x38/0x480 [ 106.645274] do_fault+0x38/0x480 [ 106.648535] __handle_mm_fault+0x935/0xb00 [ 106.652676] ? vm_iomap_memory+0xe0/0xe0 [ 106.656634] ? __lock_release+0x12f/0x4e0 [ 106.660696] ? count_memcg_event_mm.part.0+0xb9/0x190 [ 106.665799] handle_mm_fault+0xd0/0x370 [ 106.669675] do_user_addr_fault+0x2a0/0x8c0 [ 106.673908] exc_page_fault+0x64/0xf0 [ 106.677604] ? asm_exc_page_fault+0x8/0x30 [ 106.681739] asm_exc_page_fault+0x1e/0x30 [ 106.685782] RIP: 0033:0x402e12 ... Signed-off-by: Thomas Zimmermann <tzimmermann(a)suse.de> Fixes: 375cca1cfeb5 ("drm/vgem: Implement mmap as GEM object function") Reviewed-by: Daniel Vetter <daniel.vetter(a)ffwll.ch> Cc: Thomas Zimmermann <tzimmermann(a)suse.de> Cc: Christian König <christian.koenig(a)amd.com> Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch> Cc: "Christian König" <christian.koenig(a)amd.com> Cc: Melissa Wen <melissa.srw(a)gmail.com> Cc: Jason Gunthorpe <jgg(a)ziepe.ca> Cc: Gerd Hoffmann <kraxel(a)redhat.com> Cc: Lee Jones <lee.jones(a)linaro.org> --- drivers/gpu/drm/vgem/vgem_drv.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c index df634aa52638..f50fd10c4fad 100644 --- a/drivers/gpu/drm/vgem/vgem_drv.c +++ b/drivers/gpu/drm/vgem/vgem_drv.c @@ -364,8 +364,17 @@ static void vgem_prime_vunmap(struct drm_gem_object *obj, struct dma_buf_map *ma static int vgem_prime_mmap(struct drm_gem_object *obj, struct vm_area_struct *vma) { + int ret; + + if (!obj->filp) + return -ENODEV; + + ret = call_mmap(obj->filp, vma); + if (ret) + return ret; + vma_set_file(vma, obj->filp); - vma->vm_flags |= VM_DONTEXPAND | VM_DONTDUMP; + vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP; vma->vm_page_prot = pgprot_writecombine(vm_get_page_prot(vma->vm_flags)); vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot); -- 2.32.0

1 0

[PATCH v2] drm/i915/ehl: unconditionally flush the pages on acquire
by Matthew Auld 09 Jul '21

09 Jul '21

EHL and JSL add the 'Bypass LLC' MOCS entry, which should make it possible for userspace to bypass the GTT caching bits set by the kernel, as per the given object cache_level. This is troublesome since the heavy flush we apply when first acquiring the pages is skipped if the kernel thinks the object is coherent with the GPU. As a result it might be possible to bypass the cache and read the contents of the page directly, which could be stale data. If it's just a case of userspace shooting themselves in the foot then so be it, but since i915 takes the stance of always zeroing memory before handing it to userspace, we need to prevent this. v2: this time actually set cache_dirty in put_pages() BSpec: 34007 References: 046091758b50 ("Revert "drm/i915/ehl: Update MOCS table for EHL"") Signed-off-by: Matthew Auld <matthew.auld(a)intel.com> Cc: Tejas Upadhyay <tejaskumarx.surendrakumar.upadhyay(a)intel.com> Cc: Francisco Jerez <francisco.jerez.plata(a)intel.com> Cc: Lucas De Marchi <lucas.demarchi(a)intel.com> Cc: Jon Bloomfield <jon.bloomfield(a)intel.com> Cc: Chris Wilson <chris.p.wilson(a)intel.com> Cc: Matt Roper <matthew.d.roper(a)intel.com> --- drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 26 ++++++++++++++++++++++- 1 file changed, 25 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c index 6a04cce188fc..d5a487d4c5a6 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c @@ -298,11 +298,12 @@ __i915_gem_object_release_shmem(struct drm_i915_gem_object *obj, void i915_gem_object_put_pages_shmem(struct drm_i915_gem_object *obj, struct sg_table *pages) { + struct drm_i915_private *i915 = to_i915(obj->base.dev); struct sgt_iter sgt_iter; struct pagevec pvec; struct page *page; - GEM_WARN_ON(IS_DGFX(to_i915(obj->base.dev))); + GEM_WARN_ON(IS_DGFX(i915)); __i915_gem_object_release_shmem(obj, pages, true); i915_gem_gtt_finish_pages(obj, pages); @@ -327,6 +328,10 @@ void i915_gem_object_put_pages_shmem(struct drm_i915_gem_object *obj, struct sg_ check_release_pagevec(&pvec); obj->mm.dirty = false; + /* See the comment in shmem_object_init() for why we need this */ + if (IS_JSL_EHL(i915) && obj->flags & I915_BO_ALLOC_USER) + obj->cache_dirty = true; + sg_free_table(pages); kfree(pages); } @@ -539,6 +544,25 @@ static int shmem_object_init(struct intel_memory_region *mem, i915_gem_object_set_cache_coherency(obj, cache_level); + /* + * EHL and JSL add the 'Bypass LLC' MOCS entry, which should make it + * possible for userspace to bypass the GTT caching bits set by the + * kernel, as per the given object cache_level. This is troublesome + * since the heavy flush we apply when first gathering the pages is + * skipped if the kernel thinks the object is coherent with the GPU. As + * a result it might be possible to bypass the cache and read the + * contents of the page directly, which could be stale data. If it's + * just a case of userspace shooting themselves in the foot then so be + * it, but since i915 takes the stance of always zeroing memory before + * handing it to userspace, we need to prevent this. + * + * By setting cache_dirty here we make the clflush when first acquiring + * the pages unconditional on such platforms. We also set this again in + * put_pages(). + */ + if (IS_JSL_EHL(i915) && flags & I915_BO_ALLOC_USER) + obj->cache_dirty = true; + i915_gem_object_init_memory_region(obj, mem); return 0; -- 2.26.3

1 0

Re: [PATCH v4 0/2] Add p2p via dmabuf to habanalabs
by Jason Gunthorpe 09 Jul '21

09 Jul '21

On Tue, Jul 06, 2021 at 07:31:37PM +0200, Christoph Hellwig wrote: > On Tue, Jul 06, 2021 at 02:28:28PM -0300, Jason Gunthorpe wrote: > > > Also on your claim that drivers/gpu is a non-upstream disaster: I've > > > also learned that that for drivers/rdma there's the upstream driver, > > > and then there's the out-of-tree hackjob the vendor actually > > > supports. > > > > In the enterprise world everyone has their out of tree backport > > drivers. It varies on the vendor how much deviation there is from the > > upstream driver and what commercial support relationship the vendor > > has with the enterprise distros. > > I think he means the Mellanox OFED stack, which is a complete and utter > mess and which gets force fed by Mellanox/Nvidia on unsuspecting > customers. I know many big HPC sites that ignore it, but a lot of > enterprise customers are dumb enought to deploy it. No, I don't think so. While MOFED is indeed a giant mess, the mlx5 upstream driver is not some token effort to generate good will and Mellanox certainly does provide full commercial support for the mlx5 drivers shipped inside various enterprise distros. MOFED also doesn't have a big functional divergance from RDMA upstream, and it is not mandatory just to use the hardware. I can not say the same about other company's RDMA driver distributions, Daniel's description of "minimal effort to get goodwill" would match others much better. You are right that there are a lot of enterprise customers who deploy the MOFED. I can't agree with their choices, but they are not forced into using it anymore. Jason

2 1

← Newer
1
...
67
68
69
70
71
72
73
...
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