dri-devel May 2022

dri-devel@lists.freedesktop.org

344 participants
736 discussions

[PATCH 5.10 1/1] drm/amdgpu: Ensure the AMDGPU file descriptor is legitimate
by Lee Jones 09 May '22

09 May '22

[ Upstream commit b40a6ab2cf9213923bf8e821ce7fa7f6a0a26990 ] This is a partial cherry-pick of the above upstream commit. It ensures the file descriptor passed in by userspace is a valid one. Cc: Felix Kuehling <Felix.Kuehling(a)amd.com> Cc: Alex Deucher <alexander.deucher(a)amd.com> Cc: "Christian König" <christian.koenig(a)amd.com> Cc: David Airlie <airlied(a)linux.ie> Cc: Daniel Vetter <daniel(a)ffwll.ch> Cc: amd-gfx(a)lists.freedesktop.org Cc: dri-devel(a)… [View More]

3 3

[PATCH 1/2] [RFC] regmap: Add bulk read/write callbacks into regmap_config
by Marek Vasut 09 May '22

09 May '22

Currently the regmap_config structure only allows the user to implement single element register read/write using .reg_read/.reg_write callbacks. The regmap_bus already implements bulk counterparts of both, and is being misused as a workaround for the missing bulk read/write callbacks in regmap_config by a couple of drivers. To stop this misuse, add the bulk read/write callbacks to regmap_config and call them from the regmap core code. Signed-off-by: Marek Vasut <marex(a)denx.de> Cc: … [View More]Jagan Teki <jagan(a)amarulasolutions.com> Cc: Mark Brown <broonie(a)kernel.org> Cc: Maxime Ripard <maxime(a)cerno.tech> Cc: Robert Foss <robert.foss(a)linaro.org> Cc: Sam Ravnborg <sam(a)ravnborg.org> Cc: Thomas Zimmermann <tzimmermann(a)suse.de> To: dri-devel(a)lists.freedesktop.org --- drivers/base/regmap/internal.h | 4 ++ drivers/base/regmap/regmap.c | 76 ++++++++++++++++++---------------- include/linux/regmap.h | 12 ++++++ 3 files changed, 56 insertions(+), 36 deletions(-) diff --git a/drivers/base/regmap/internal.h b/drivers/base/regmap/internal.h index b4df36c7b17d..da8996e7a1f1 100644 --- a/drivers/base/regmap/internal.h +++ b/drivers/base/regmap/internal.h @@ -110,6 +110,10 @@ struct regmap { int (*reg_write)(void *context, unsigned int reg, unsigned int val); int (*reg_update_bits)(void *context, unsigned int reg, unsigned int mask, unsigned int val); + /* Bulk read/write */ + int (*read)(void *context, const void *reg_buf, size_t reg_size, + void *val_buf, size_t val_size); + int (*write)(void *context, const void *data, size_t count); bool defer_caching; diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c index 5e12f7cb5147..879a87a6461b 100644 --- a/drivers/base/regmap/regmap.c +++ b/drivers/base/regmap/regmap.c @@ -838,12 +838,15 @@ struct regmap *__regmap_init(struct device *dev, map->reg_stride_order = ilog2(map->reg_stride); else map->reg_stride_order = -1; - map->use_single_read = config->use_single_read || !bus || !bus->read; - map->use_single_write = config->use_single_write || !bus || !bus->write; - map->can_multi_write = config->can_multi_write && bus && bus->write; + map->use_single_read = config->use_single_read || !(config->read || (bus && bus->read)); + map->use_single_write = config->use_single_write || !(config->write || (bus && bus->write)); + map->can_multi_write = config->can_multi_write && (config->write || (bus && bus->write)); if (bus) { map->max_raw_read = bus->max_raw_read; map->max_raw_write = bus->max_raw_write; + } else if (config->max_raw_read && config->max_raw_write) { + map->max_raw_read = config->max_raw_read; + map->max_raw_write = config->max_raw_write; } map->dev = dev; map->bus = bus; @@ -877,7 +880,16 @@ struct regmap *__regmap_init(struct device *dev, map->read_flag_mask = bus->read_flag_mask; } - if (!bus) { + if (config && config->read && config->write) { + map->reg_read = _regmap_bus_read; + + /* Bulk read/write */ + map->read = config->read; + map->write = config->write; + + reg_endian = REGMAP_ENDIAN_NATIVE; + val_endian = REGMAP_ENDIAN_NATIVE; + } else if (!bus) { map->reg_read = config->reg_read; map->reg_write = config->reg_write; map->reg_update_bits = config->reg_update_bits; @@ -894,10 +906,13 @@ struct regmap *__regmap_init(struct device *dev, } else { map->reg_read = _regmap_bus_read; map->reg_update_bits = bus->reg_update_bits; - } + /* Bulk read/write */ + map->read = bus->read; + map->write = bus->write; - reg_endian = regmap_get_reg_endian(bus, config); - val_endian = regmap_get_val_endian(dev, bus, config); + reg_endian = regmap_get_reg_endian(bus, config); + val_endian = regmap_get_val_endian(dev, bus, config); + } switch (config->reg_bits + map->reg_shift) { case 2: @@ -1671,8 +1686,6 @@ static int _regmap_raw_write_impl(struct regmap *map, unsigned int reg, size_t len; int i; - WARN_ON(!map->bus); - /* Check for unwritable or noinc registers in range * before we start */ @@ -1754,7 +1767,7 @@ static int _regmap_raw_write_impl(struct regmap *map, unsigned int reg, val = work_val; } - if (map->async && map->bus->async_write) { + if (map->async && map->bus && map->bus->async_write) { struct regmap_async *async; trace_regmap_async_write_start(map, reg, val_len); @@ -1822,10 +1835,10 @@ static int _regmap_raw_write_impl(struct regmap *map, unsigned int reg, * write. */ if (val == work_val) - ret = map->bus->write(map->bus_context, map->work_buf, - map->format.reg_bytes + - map->format.pad_bytes + - val_len); + ret = map->write(map->bus_context, map->work_buf, + map->format.reg_bytes + + map->format.pad_bytes + + val_len); else if (map->bus->gather_write) ret = map->bus->gather_write(map->bus_context, map->work_buf, map->format.reg_bytes + @@ -1844,7 +1857,7 @@ static int _regmap_raw_write_impl(struct regmap *map, unsigned int reg, memcpy(buf, map->work_buf, map->format.reg_bytes); memcpy(buf + map->format.reg_bytes + map->format.pad_bytes, val, val_len); - ret = map->bus->write(map->bus_context, buf, len); + ret = map->write(map->bus_context, buf, len); kfree(buf); } else if (ret != 0 && !map->cache_bypass && map->format.parse_val) { @@ -1901,7 +1914,7 @@ static int _regmap_bus_formatted_write(void *context, unsigned int reg, struct regmap_range_node *range; struct regmap *map = context; - WARN_ON(!map->bus || !map->format.format_write); + WARN_ON(!map->format.format_write); range = _regmap_range_lookup(map, reg); if (range) { @@ -1916,8 +1929,7 @@ static int _regmap_bus_formatted_write(void *context, unsigned int reg, trace_regmap_hw_write_start(map, reg, 1); - ret = map->bus->write(map->bus_context, map->work_buf, - map->format.buf_size); + ret = map->write(map->bus_context, map->work_buf, map->format.buf_size); trace_regmap_hw_write_done(map, reg, 1); @@ -1937,7 +1949,7 @@ static int _regmap_bus_raw_write(void *context, unsigned int reg, { struct regmap *map = context; - WARN_ON(!map->bus || !map->format.format_val); + WARN_ON(!map->format.format_val); map->format.format_val(map->work_buf + map->format.reg_bytes + map->format.pad_bytes, val, 0); @@ -1951,7 +1963,7 @@ static int _regmap_bus_raw_write(void *context, unsigned int reg, static inline void *_regmap_map_get_context(struct regmap *map) { - return (map->bus) ? map : map->bus_context; + return (map->bus || (!map->bus && map->read)) ? map : map->bus_context; } int _regmap_write(struct regmap *map, unsigned int reg, @@ -2363,7 +2375,7 @@ static int _regmap_raw_multi_reg_write(struct regmap *map, u8 = buf; *u8 |= map->write_flag_mask; - ret = map->bus->write(map->bus_context, buf, len); + ret = map->write(map->bus_context, buf, len); kfree(buf); @@ -2669,9 +2681,7 @@ static int _regmap_raw_read(struct regmap *map, unsigned int reg, void *val, struct regmap_range_node *range; int ret; - WARN_ON(!map->bus); - - if (!map->bus || !map->bus->read) + if (!map->read) return -EINVAL; range = _regmap_range_lookup(map, reg); @@ -2689,9 +2699,9 @@ static int _regmap_raw_read(struct regmap *map, unsigned int reg, void *val, map->read_flag_mask); trace_regmap_hw_read_start(map, reg, val_len / map->format.val_bytes); - ret = map->bus->read(map->bus_context, map->work_buf, - map->format.reg_bytes + map->format.pad_bytes, - val, val_len); + ret = map->read(map->bus_context, map->work_buf, + map->format.reg_bytes + map->format.pad_bytes, + val, val_len); trace_regmap_hw_read_done(map, reg, val_len / map->format.val_bytes); @@ -2802,8 +2812,6 @@ int regmap_raw_read(struct regmap *map, unsigned int reg, void *val, unsigned int v; int ret, i; - if (!map->bus) - return -EINVAL; if (val_len % map->format.val_bytes) return -EINVAL; if (!IS_ALIGNED(reg, map->reg_stride)) @@ -2818,7 +2826,7 @@ int regmap_raw_read(struct regmap *map, unsigned int reg, void *val, size_t chunk_count, chunk_bytes; size_t chunk_regs = val_count; - if (!map->bus->read) { + if (!map->read) { ret = -ENOTSUPP; goto out; } @@ -2878,7 +2886,7 @@ EXPORT_SYMBOL_GPL(regmap_raw_read); * @val: Pointer to data buffer * @val_len: Length of output buffer in bytes. * - * The regmap API usually assumes that bulk bus read operations will read a + * The regmap API usually assumes that bulk read operations will read a * range of registers. Some devices have certain registers for which a read * operation read will read from an internal FIFO. * @@ -2896,10 +2904,6 @@ int regmap_noinc_read(struct regmap *map, unsigned int reg, size_t read_len; int ret; - if (!map->bus) - return -EINVAL; - if (!map->bus->read) - return -ENOTSUPP; if (val_len % map->format.val_bytes) return -EINVAL; if (!IS_ALIGNED(reg, map->reg_stride)) @@ -3013,7 +3017,7 @@ int regmap_bulk_read(struct regmap *map, unsigned int reg, void *val, if (val_count == 0) return -EINVAL; - if (map->bus && map->format.parse_inplace && (vol || map->cache_type == REGCACHE_NONE)) { + if (map->format.parse_inplace && (vol || map->cache_type == REGCACHE_NONE)) { ret = regmap_raw_read(map, reg, val, val_bytes * val_count); if (ret != 0) return ret; diff --git a/include/linux/regmap.h b/include/linux/regmap.h index de81a94d7b30..8952fa3d0d59 100644 --- a/include/linux/regmap.h +++ b/include/linux/regmap.h @@ -299,6 +299,12 @@ typedef void (*regmap_unlock)(void *); * if the function require special handling with lock and reg * handling and the operation cannot be represented as a simple * update_bits operation on a bus such as SPI, I2C, etc. + * @read: Optional callback that if filled will be used to perform all the + * bulk reads from the registers. Data is returned in the buffer used + * to transmit data. + * @write: Same as above for writing. + * @max_raw_read: Max raw read size that can be used on the device. + * @max_raw_write: Max raw write size that can be used on the device. * @fast_io: Register IO is fast. Use a spinlock instead of a mutex * to perform locking. This field is ignored if custom lock/unlock * functions are used (see fields lock/unlock of struct regmap_config). @@ -385,6 +391,12 @@ struct regmap_config { int (*reg_write)(void *context, unsigned int reg, unsigned int val); int (*reg_update_bits)(void *context, unsigned int reg, unsigned int mask, unsigned int val); + /* Bulk read/write */ + int (*read)(void *context, const void *reg_buf, size_t reg_size, + void *val_buf, size_t val_size); + int (*write)(void *context, const void *data, size_t count); + size_t max_raw_read; + size_t max_raw_write; bool fast_io; -- 2.35.1 [View Less]

4 10

[PATCH v2] Revert "fbdev: Make fb_release() return -ENODEV if fbdev was unregistered"
by Javier Martinez Canillas 09 May '22

09 May '22

This reverts commit aafa025c76dcc7d1a8c8f0bdefcbe4eb480b2f6a. That commit attempted to fix a NULL pointer dereference, caused by the struct fb_info associated with a framebuffer device to not longer be valid when the file descriptor was closed. The issue was exposed by commit 27599aacbaef ("fbdev: Hot-unplug firmware fb devices on forced removal"), which added a new path that goes through the struct device removal instead of directly unregistering the fb. Most fbdev drivers have issues with … [View More]

2 3

[PATCH 0/5] i915: SSEU handling updates
by Matt Roper 09 May '22

09 May '22

This series makes a handful of updates to i915's internal handling of slice/subslice/EU (SSEU) data to handle recent platforms like Xe_HP in a more natural manner and to prepare for some additional upcoming platforms we have in the pipeline (the first of which I'll probably start sending patches for in the next week or two). One key idea of this series is that although we have a fixed ABI to convey SSEU data to userspace (i.e., multiple u8[] arrays with data stored at different strides), we … [View More]don't need to use this cumbersome format for the driver's own internal storage. As long as we can convert into the uapi form properly when responding to the I915_QUERY ioctl, it's preferable to use an internal storage format that's easier for the driver to work with. Doing so can also save us some storage space on modern platforms since we don't always need to replicate a bunch of data that's architecturally guaranteed to be identical. Another key point here is that Xe_HP platforms today have subslice (DSS) masks that are 32 bits, which maxes out the storage of a u32. On future platforms the architecture design is going to start spreading their DSS masks over multiple 32-bit fuse registers. So even for platforms where the total number of DSS doesn't actually go up, we're going to need larger storage than just a u32 to express the mask properly. To accomodate this, we start storing our subslice mask in a new typedef that can be processed by the linux/bitmap.h operations. Finally, since no userspace for Xe_HP or beyond is using the legacy I915_GETPARAM ioctl lookups for I915_PARAM_SLICE_MASK and I915_PARAM_SUBSLICE_MASK (since they've migrated to the more flexible I915_QUERY ioctl that can return more than a simple u32 value), we take the opportunity to officially drop support for those GETPARAM lookups on modern platforms. Maintaining support for these GETPARAM lookups don't make sense for a number of reasons: * Traditional slices no longer exist, and newer ideas like gslices, cslices, mslices, etc. aren't something userspace needs to query since it can be inferred from other information. * The GETPARAM ioctl doesn't have a way to distinguish between geometry subslice masks and compute subslice masks, which are distinct on Xe_HP and beyond. * The I915_GETPARAM ioctl is limited to returning a 32-bit value, so when subslice masks begin to exceed 32-bits, it simply can't return the entire mask. * The GETPARAM ioctl doesn't have a way to give sensible information for multi-tile devices. Cc: Tvrtko Ursulin <tvrtko.ursulin(a)linux.intel.com> Matt Roper (5): drm/i915/sseu: Don't try to store EU mask internally in UAPI format drm/i915/xehp: Drop GETPARAM lookups of I915_PARAM_[SUB]SLICE_MASK drm/i915/xehp: Use separate sseu init function drm/i915/sseu: Simplify gen11+ SSEU handling drm/i915/sseu: Disassociate internal subslice mask representation from uapi drivers/gpu/drm/i915/gem/i915_gem_context.c | 4 +- drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +- drivers/gpu/drm/i915/gt/intel_gt.c | 14 +- drivers/gpu/drm/i915/gt/intel_sseu.c | 371 +++++++++++-------- drivers/gpu/drm/i915/gt/intel_sseu.h | 69 ++-- drivers/gpu/drm/i915/gt/intel_sseu_debugfs.c | 28 +- drivers/gpu/drm/i915/gt/intel_workarounds.c | 28 +- drivers/gpu/drm/i915/i915_getparam.c | 10 +- drivers/gpu/drm/i915/i915_query.c | 16 +- 9 files changed, 323 insertions(+), 219 deletions(-) -- 2.35.1 [View Less]

2 8

[PATCH v3 00/21] xen: simplify frontend side ring setup
by Juergen Gross 09 May '22

09 May '22

Many Xen PV frontends share similar code for setting up a ring page (allocating and granting access for the backend) and for tearing it down. Create new service functions doing all needed steps in one go. This requires all frontends to use a common value for an invalid grant reference in order to make the functions idempotent. Changes in V3: - new patches 1 and 2, comments addressed Changes in V2: - new patch 9 and related changes in patches 10-18 Juergen Gross (21): xen: update … [View More]grant_table.h xen/grant-table: never put a reserved grant on the free list xen/blkfront: switch blkfront to use INVALID_GRANT_REF xen/netfront: switch netfront to use INVALID_GRANT_REF xen/scsifront: remove unused GRANT_INVALID_REF definition xen/usb: switch xen-hcd to use INVALID_GRANT_REF xen/drm: switch xen_drm_front to use INVALID_GRANT_REF xen/sound: switch xen_snd_front to use INVALID_GRANT_REF xen/dmabuf: switch gntdev-dmabuf to use INVALID_GRANT_REF xen/shbuf: switch xen-front-pgdir-shbuf to use INVALID_GRANT_REF xen: update ring.h xen/xenbus: add xenbus_setup_ring() service function xen/blkfront: use xenbus_setup_ring() and xenbus_teardown_ring() xen/netfront: use xenbus_setup_ring() and xenbus_teardown_ring() xen/tpmfront: use xenbus_setup_ring() and xenbus_teardown_ring() xen/drmfront: use xenbus_setup_ring() and xenbus_teardown_ring() xen/pcifront: use xenbus_setup_ring() and xenbus_teardown_ring() xen/scsifront: use xenbus_setup_ring() and xenbus_teardown_ring() xen/usbfront: use xenbus_setup_ring() and xenbus_teardown_ring() xen/sndfront: use xenbus_setup_ring() and xenbus_teardown_ring() xen/xenbus: eliminate xenbus_grant_ring() drivers/block/xen-blkfront.c | 57 +++---- drivers/char/tpm/xen-tpmfront.c | 18 +-- drivers/gpu/drm/xen/xen_drm_front.h | 9 -- drivers/gpu/drm/xen/xen_drm_front_evtchnl.c | 43 ++---- drivers/net/xen-netfront.c | 85 ++++------- drivers/pci/xen-pcifront.c | 19 +-- drivers/scsi/xen-scsifront.c | 31 +--- drivers/usb/host/xen-hcd.c | 65 ++------ drivers/xen/gntdev-dmabuf.c | 13 +- drivers/xen/grant-table.c | 12 +- drivers/xen/xen-front-pgdir-shbuf.c | 18 +-- drivers/xen/xenbus/xenbus_client.c | 82 +++++++--- include/xen/grant_table.h | 2 - include/xen/interface/grant_table.h | 161 ++++++++++++-------- include/xen/interface/io/ring.h | 19 ++- include/xen/xenbus.h | 4 +- sound/xen/xen_snd_front_evtchnl.c | 44 ++---- sound/xen/xen_snd_front_evtchnl.h | 9 -- 18 files changed, 287 insertions(+), 404 deletions(-) -- 2.35.3 [View Less]

3 4

[PATCH 1/2] drm/i915: Enable THP on Icelake and beyond
by Tvrtko Ursulin 09 May '22

09 May '22

From: Tvrtko Ursulin <tvrtko.ursulin(a)intel.com> We have a statement from HW designers that the GPU read regression when using 2M pages was fixed from Icelake onwards, which was also confirmed by bencharking Eero did last year: """ When IOMMU is disabled, enabling THP causes following perf changes on TGL-H (GT1): 10-15% SynMark Batch[0-3] 5-10% MemBW GPU texture, SynMark ShMapVsm 3-5% SynMark TerrainFly* + Geom* + Fill* + CSCloth + Batch4 1-3% GpuTest Triangle, SynMark … [View More]TexMem* + DeferredAA + Batch[5-7] + few others -7% MemBW GPU blend In the above 3D benchmark names, * means all the variants of tests with the same prefix. For example "SynMark TexMem*", means both TexMem128 & TexMem512 tests in the synthetic (Intel internal) SynMark test suite. In the (public, but proprietary) GfxBench & GLB(enchmark) test suites, there are both onscreen and offscreen variants of each test. Unless explicitly stated otherwise, numbers are for both variants. All tests are run with FullHD monitor. All tests are fullscreen except for GLB and GpuTest ones, which are run in 1/2 screen window (GpuTest triangle is run both in fullscreen and 1/2 screen window). """ Since the only regression is MemBW GPU blend, against many more gains, it sounds it is time to enable THP on Gen11+. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin(a)intel.com> References: https://gitlab.freedesktop.org/drm/intel/-/issues/430 Cc: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com> Cc: Matthew Auld <matthew.auld(a)intel.com> Cc: Eero Tamminen <eero.t.tamminen(a)intel.com> --- drivers/gpu/drm/i915/gem/i915_gemfs.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gemfs.c b/drivers/gpu/drm/i915/gem/i915_gemfs.c index ee87874e59dc..c5a6bbc842fc 100644 --- a/drivers/gpu/drm/i915/gem/i915_gemfs.c +++ b/drivers/gpu/drm/i915/gem/i915_gemfs.c @@ -28,12 +28,14 @@ int i915_gemfs_init(struct drm_i915_private *i915) * * One example, although it is probably better with a per-file * control, is selecting huge page allocations ("huge=within_size"). - * However, we only do so to offset the overhead of iommu lookups - * due to bandwidth issues (slow reads) on Broadwell+. + * However, we only do so on platforms which benefit from it, or to + * offset the overhead of iommu lookups, where with latter it is a net + * win even on platforms which would otherwise see some performance + * regressions such a slow reads issue on Broadwell and Skylake. */ opts = NULL; - if (i915_vtd_active(i915)) { + if (GRAPHICS_VER(i915) >= 11 || i915_vtd_active(i915)) { if (IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE)) { opts = huge_opt; drm_info(&i915->drm, @@ -41,7 +43,10 @@ int i915_gemfs_init(struct drm_i915_private *i915) opts); } else { drm_notice(&i915->drm, - "Transparent Hugepage support is recommended for optimal performance when IOMMU is enabled!\n"); + "Transparent Hugepage support is recommended for optimal performance%s\n", + GRAPHICS_VER(i915) >= 11 ? + " on this platform!" : + " when IOMMU is enabled!"); } } -- 2.32.0 [View Less]

2 3

Understanding i915 rps boost
by Matthias Treydte 09 May '22

09 May '22

Hello, I'm trying to understand why our application does not play well with the i915 driver. We're trying to drive a 4k/60Hz display using an OpenGL ES application, the GL context being derived directly from the DRM device. Depending on the GPU load we generate, we quite frequently manage to get stuck with an GPU clocked just a smidge too low to actually hit the 60Hz target. E.g. right now I'm looking at less than ideal animations because the time to complete a frame is 17.1ms, … [View More]

1 0

[Bug 214853] New: [amdgpu] UBSAN shows several null-ptr-deref in ../dc/bios/command_table2.c some array-index-out-of-bounds in ../dc/bios/bios_parser2.c and an invalid-load in ../amdgpu_dm/amdgpu_dm.c
by bugzilla-daemon＠bugzilla.kernel.org 09 May '22

09 May '22

https://bugzilla.kernel.org/show_bug.cgi?id=214853 Bug ID: 214853 Summary: [amdgpu] UBSAN shows several null-ptr-deref in ../dc/bios/command_table2.c some array-index-out-of-bounds in ../dc/bios/bios_parser2.c and an invalid-load in ../amdgpu_dm/amdgpu_dm.c Product: Drivers Version: 2.5 Kernel Version: 5.15-rc7 Hardware: All OS: Linux Tree: … [View More]Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: erhard_f(a)mailbox.org CC: christian.koenig(a)amd.com Regression: No Created attachment 299337 --> https://bugzilla.kernel.org/attachment.cgi?id=299337&action=edit kernel dmesg (kernel 5.15-rc7, AMD FX-8370) [...] UBSAN: null-ptr-deref in drivers/gpu/drm/amd/amdgpu/../display/dc/bios/command_table2.c:872:3 member access within null pointer of type 'struct atom_master_list_of_command_functions_v2_1' CPU: 3 PID: 234 Comm: systemd-udevd Not tainted 5.15.0-rc7-bdver2 #11 Hardware name: Gigabyte Technology Co., Ltd. To be filled by O.E.M./970-GAMING, BIOS F2 04/06/2016 Call Trace: dump_stack_lvl+0x8d/0xd9 ubsan_epilogue+0x5/0x44 __ubsan_handle_type_mismatch_v1+0x45/0x4a dal_firmware_parser_init_cmd_tbl+0x31c/0x37c [amdgpu] bios_parser2_construct+0x16f/0x9cb [amdgpu] firmware_parser_create+0x36/0x4c [amdgpu] dal_bios_parser_create+0xc/0x20 [amdgpu] dc_create+0x25d/0x764 [amdgpu] dm_hw_init+0x28a/0x697 [amdgpu] ? dev_printk_emit+0x4c/0x66 amdgpu_device_init+0x1847/0x1e13 [amdgpu] amdgpu_driver_load_kms+0x47/0x33d [amdgpu] amdgpu_pci_probe+0xeb/0x1a6 [amdgpu] pci_device_probe+0xa1/0x121 really_probe+0xe4/0x331 __driver_probe_device+0x84/0xe1 driver_probe_device+0x1a/0x6d __driver_attach+0xac/0xc3 ? driver_attach+0x15/0x15 bus_for_each_dev+0x8c/0xc0 bus_add_driver+0xf5/0x1f2 driver_register+0x66/0xe7 ? 0xffffffffc0ff2000 do_one_initcall+0x109/0x1f4 ? 0xffffffffc0ff2000 do_init_module+0x5c/0x1f1 load_module+0x193f/0x1ca9 ? kernel_read_file_from_fd+0x5b/0x7e __se_sys_finit_module+0xa7/0xce do_syscall_64+0x79/0xa3 ? lockdep_hardirqs_on_prepare+0xf6/0x1e3 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7fa99ef681e9 Code: 00 00 b8 ca 00 00 00 0f 05 eb ac 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 4f fc 0b 00 f7 d8 64 89 01 48 RSP: 002b:00007fff06041ba8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 RAX: ffffffffffffffda RBX: 000055f2d378be20 RCX: 00007fa99ef681e9 RDX: 0000000000000000 RSI: 00007fa99f0af97f RDI: 0000000000000018 RBP: 0000000000020000 R08: 0000000000000000 R09: fffffffffffffeb8 R10: 0000000000000018 R11: 0000000000000246 R12: 0000000000000000 R13: 000055f2d38eba60 R14: 00007fa99f0af97f R15: 0000000000000000 ================================================================================ ================================================================================ UBSAN: array-index-out-of-bounds in drivers/gpu/drm/amd/amdgpu/../display/dc/bios/bios_parser2.c:384:3 index 8 is out of range for type 'struct atom_gpio_pin_assignment [8]' CPU: 3 PID: 234 Comm: systemd-udevd Not tainted 5.15.0-rc7-bdver2 #11 Hardware name: Gigabyte Technology Co., Ltd. To be filled by O.E.M./970-GAMING, BIOS F2 04/06/2016 Call Trace: dump_stack_lvl+0x8d/0xd9 ubsan_epilogue+0x5/0x44 __ubsan_handle_out_of_bounds+0x9e/0xa0 get_gpio_i2c_info+0xe0/0x17e [amdgpu] bios_parser_get_i2c_info+0x5b/0xfa [amdgpu] dal_ddc_service_create+0xa7/0x1a8 [amdgpu] dcn20_resource_construct+0x106e/0x10ba [amdgpu] ? find_held_lock+0x41/0xc1 ? slab_post_alloc_hook+0x5f/0x8a dcn20_create_resource_pool+0x39/0x6f [amdgpu] dc_create_resource_pool+0x164/0x213 [amdgpu] ? dal_gpio_service_create+0x8f/0x193 [amdgpu] dc_create+0x2b3/0x764 [amdgpu] dm_hw_init+0x28a/0x697 [amdgpu] ? dev_printk_emit+0x4c/0x66 amdgpu_device_init+0x1847/0x1e13 [amdgpu] amdgpu_driver_load_kms+0x47/0x33d [amdgpu] amdgpu_pci_probe+0xeb/0x1a6 [amdgpu] pci_device_probe+0xa1/0x121 really_probe+0xe4/0x331 __driver_probe_device+0x84/0xe1 driver_probe_device+0x1a/0x6d __driver_attach+0xac/0xc3 ? driver_attach+0x15/0x15 bus_for_each_dev+0x8c/0xc0 bus_add_driver+0xf5/0x1f2 driver_register+0x66/0xe7 ? 0xffffffffc0ff2000 do_one_initcall+0x109/0x1f4 ? 0xffffffffc0ff2000 do_init_module+0x5c/0x1f1 load_module+0x193f/0x1ca9 ? kernel_read_file_from_fd+0x5b/0x7e __se_sys_finit_module+0xa7/0xce do_syscall_64+0x79/0xa3 ? lockdep_hardirqs_on_prepare+0xf6/0x1e3 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7fa99ef681e9 Code: 00 00 b8 ca 00 00 00 0f 05 eb ac 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 4f fc 0b 00 f7 d8 64 89 01 48 RSP: 002b:00007fff06041ba8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 RAX: ffffffffffffffda RBX: 000055f2d378be20 RCX: 00007fa99ef681e9 RDX: 0000000000000000 RSI: 00007fa99f0af97f RDI: 0000000000000018 RBP: 0000000000020000 R08: 0000000000000000 R09: fffffffffffffeb8 R10: 0000000000000018 R11: 0000000000000246 R12: 0000000000000000 R13: 000055f2d38eba60 R14: 00007fa99f0af97f R15: 0000000000000000 [...] = UBSAN: invalid-load in drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:5865:85 load of value 170 is not a valid value for type 'bool' (aka '_Bool') CPU: 5 PID: 234 Comm: systemd-udevd Not tainted 5.15.0-rc7-bdver2 #11 Hardware name: Gigabyte Technology Co., Ltd. To be filled by O.E.M./970-GAMING, BIOS F2 04/06/2016 Call Trace: dump_stack_lvl+0x8d/0xd9 ubsan_epilogue+0x5/0x44 __ubsan_handle_load_invalid_value+0x9e/0xa0 create_validate_stream_for_sink+0x6bb/0x777 [amdgpu] ? lockdep_hardirqs_on_prepare+0xf6/0x1e3 amdgpu_dm_connector_mode_valid+0x70/0x1b9 [amdgpu] ? drm_connector_list_update+0xba/0x121 [drm] drm_connector_mode_valid+0x34/0x42 [drm_kms_helper] drm_helper_probe_single_connector_modes+0x4d7/0x88e [drm_kms_helper] ? drm_client_modeset_probe+0x1fa/0x14c9 [drm] drm_client_modeset_probe+0x232/0x14c9 [drm] ? add_chain_block+0x165/0x22f ? __lock_acquire+0xc7c/0x1e4d ? rcu_read_lock_sched_held+0x45/0xa5 ? lock_acquire+0xcb/0x210 ? drm_fb_helper_initial_config+0x32/0x4f [drm_kms_helper] __drm_fb_helper_initial_config_and_unlock+0x3e/0x5f0 [drm_kms_helper] amdgpu_fbdev_init+0xee/0x110 [amdgpu] amdgpu_device_init+0x1996/0x1e13 [amdgpu] amdgpu_driver_load_kms+0x47/0x33d [amdgpu] amdgpu_pci_probe+0xeb/0x1a6 [amdgpu] pci_device_probe+0xa1/0x121 really_probe+0xe4/0x331 __driver_probe_device+0x84/0xe1 driver_probe_device+0x1a/0x6d __driver_attach+0xac/0xc3 ? driver_attach+0x15/0x15 bus_for_each_dev+0x8c/0xc0 bus_add_driver+0xf5/0x1f2 driver_register+0x66/0xe7 ? 0xffffffffc0ff2000 do_one_initcall+0x109/0x1f4 ? 0xffffffffc0ff2000 do_init_module+0x5c/0x1f1 load_module+0x193f/0x1ca9 ? kernel_read_file_from_fd+0x5b/0x7e __se_sys_finit_module+0xa7/0xce do_syscall_64+0x79/0xa3 ? lockdep_hardirqs_on_prepare+0xf6/0x1e3 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7fa99ef681e9 Code: 00 00 b8 ca 00 00 00 0f 05 eb ac 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 4f fc 0b 00 f7 d8 64 89 01 48 RSP: 002b:00007fff06041ba8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 RAX: ffffffffffffffda RBX: 000055f2d378be20 RCX: 00007fa99ef681e9 RDX: 0000000000000000 RSI: 00007fa99f0af97f RDI: 0000000000000018 RBP: 0000000000020000 R08: 0000000000000000 R09: fffffffffffffeb8 R10: 0000000000000018 R11: 0000000000000246 R12: 0000000000000000 R13: 000055f2d38eba60 R14: 00007fa99f0af97f R15: 0000000000000000 -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. [View Less]

2 3

[PATCH v12 0/3] drm/rockchip: RK356x VOP2 support last fixups
by Sascha Hauer 09 May '22

09 May '22

This is not the full series, if you want that, look for v11. This series merely has a last-minute change: The VOP2 driver used platform_get_resource_byname() to get its registers, but the reg-names property hasn't been documented in the binding. This series adds the missing documentation and along the way renames the generic "regs" name to "vop" and "gamma_lut" to "gamma-lut". Sascha Andy Yan (1): drm: rockchip: Add VOP2 driver Sascha Hauer (2): arm64: dts: rockchip: rk356x: Add VOP2 … [View More]

2 9

[bug report] drm/msm/dpu: introduce the dpu_encoder_phys_* for writeback
by Dan Carpenter 09 May '22

09 May '22

[ Oops. I never sent this after all. - dan ] Hello Abhinav Kumar, The patch d7d0e73f7de3: "drm/msm/dpu: introduce the dpu_encoder_phys_* for writeback" from Apr 26, 2022, leads to the following Smatch static checker warning: drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c:252 dpu_encoder_phys_wb_atomic_check() error: potentially dereferencing uninitialized 'mode'. drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c 244 static int dpu_encoder_phys_wb_atomic_check( 245 … [View More]

1 0

← Newer
1
...
54
55
56
57
58
59
60
...
74
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel May 2022