dri-devel September 2021

dri-devel@lists.freedesktop.org

348 participants
817 discussions

BoF at LPC: Documenting the Heterogeneous Memory Model Architecture
by Felix Kuehling 23 Sep '21

23 Sep '21

As the programming models for GPU-based high-performance computing applications are evolving, HMM is helping us integrate the GPU memory management more closely with the kernel's virtual memory management. As a result we can provide a shared virtual address space with demand-paging and page-based migrations of anonymous pages to/from device memory. A patch series by AMD [1, 2] to add support for cache-coherent, CPU-accessible device memory has brought up some fairly fundamental questions about HMM and its interaction with virtual memory management, page cache and file systems. We'd like to use the chance of getting together for a BoF [3] at LPC to raise awareness for HMM outside the GPU driver code, identify gaps in the architectural documentation and clarify our priorities for future development. Thank you, Daniel, for suggesting the BoF and getting it scheduled. It's set for Friday, 10am Pacific, 1pm Eastern, 5pm UTC. I am registered at LPC. Daniel got a speaker's pass. We're still trying to work something out for Alex. I hope to see many of you on Friday. Best regards, Felix [1] https://patchwork.freedesktop.org/series/94611/ [2] https://patchwork.freedesktop.org/series/90706/ [3] https://linuxplumbersconf.org/event/11/contributions/1123/ -- F e l i x K u e h l i n g PMTS Software Development Engineer | Linux Compute Kernel 1 Commerce Valley Dr. East, Markham, ON L3T 7X6 Canada (O) +1(289)695-1597 _ _ _ _____ _____ / \ | \ / | | _ \ \ _ | / A \ | \M/ | | |D) ) /|_| | /_/ \_\ |_| |_| |_____/ |__/ \| facebook.com/AMD | amd.com

4 4

[PATCH] DRM/Panel : abt-y030xx067a yellow tint fix
by Christophe Branchereau 23 Sep '21

23 Sep '21

The previous parameters caused an unbalanced yellow tint. Signed-off-by: Christophe Branchereau <cbranchereau(a)gmail.com> --- drivers/gpu/drm/panel/panel-abt-y030xx067a.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/panel/panel-abt-y030xx067a.c b/drivers/gpu/drm/panel/panel-abt-y030xx067a.c index 2d8794d495d0..3d8a9ab47cae 100644 --- a/drivers/gpu/drm/panel/panel-abt-y030xx067a.c +++ b/drivers/gpu/drm/panel/panel-abt-y030xx067a.c @@ -146,8 +146,8 @@ static const struct reg_sequence y030xx067a_init_sequence[] = { { 0x09, REG09_SUB_BRIGHT_R(0x20) }, { 0x0a, REG0A_SUB_BRIGHT_B(0x20) }, { 0x0b, REG0B_HD_FREERUN | REG0B_VD_FREERUN }, - { 0x0c, REG0C_CONTRAST_R(0x10) }, - { 0x0d, REG0D_CONTRAST_G(0x10) }, + { 0x0c, REG0C_CONTRAST_R(0x00) }, + { 0x0d, REG0D_CONTRAST_G(0x00) }, { 0x0e, REG0E_CONTRAST_B(0x10) }, { 0x0f, 0 }, { 0x10, REG10_BRIGHT(0x7f) }, -- 2.33.0

3 3

[pull] amdgpu, amdkfd drm-fixes-5.15
by Alex Deucher 23 Sep '21

23 Sep '21

Hi Dave, Daniel, Fixes for 5.15. The following changes since commit e4e737bb5c170df6135a127739a9e6148ee3da82: Linux 5.15-rc2 (2021-09-19 17:28:22 -0700) are available in the Git repository at: https://gitlab.freedesktop.org/agd5f/linux.git tags/amd-drm-fixes-5.15-2021-09-23 for you to fetch changes up to 197ae17722e989942b36e33e044787877f158574: drm/amdkfd: fix svm_migrate_fini warning (2021-09-23 17:06:11 -0400) ---------------------------------------------------------------- amd-drm-fixes-5.15-2021-09-23: amdgpu: - Update MAINTAINERS entry for powerplay - Fix empty macros - SI DPM fix amdkfd: - SVM fixes - DMA mapping fix ---------------------------------------------------------------- Alex Deucher (1): MAINTAINERS: fix up entry for AMD Powerplay Arnd Bergmann (1): drm/amd/display: fix empty debug macros Lijo Lazar (1): drm/amd/pm: Update intermediate power state for SI Philip Yang (4): drm/amdkfd: SVM map to gpus check vma boundary drm/amdkfd: fix dma mapping leaking warning drm/amdkfd: handle svm migrate init error drm/amdkfd: fix svm_migrate_fini warning MAINTAINERS | 4 ++-- drivers/gpu/drm/amd/amdkfd/kfd_device.c | 1 - drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 16 +++++++--------- drivers/gpu/drm/amd/amdkfd/kfd_migrate.h | 5 ----- drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 24 +++++++++++++++++++----- drivers/gpu/drm/amd/display/dc/dce/dce_aux.c | 4 ++-- drivers/gpu/drm/amd/pm/powerplay/si_dpm.c | 2 ++ 7 files changed, 32 insertions(+), 24 deletions(-)

1 0

[PATCH v6 1/2] drm/bridge: parade-ps8640: Use regmap APIs
by Philip Chen 23 Sep '21

23 Sep '21

Replace the direct i2c access (i2c_smbus_* functions) with regmap APIs, which will simplify the future update on ps8640 driver. Reviewed-by: Douglas Anderson <dianders(a)chromium.org> Acked-by: Sam Ravnborg <sam(a)ravnborg.org> Signed-off-by: Philip Chen <philipchen(a)chromium.org> --- (no changes since v4) Changes in v4: - Remove excessive error logging from the probe function Changes in v3: - Fix the nits from v2 review Changes in v2: - Add separate reg map config per page drivers/gpu/drm/bridge/parade-ps8640.c | 94 ++++++++++++++++++-------- 1 file changed, 64 insertions(+), 30 deletions(-) diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c b/drivers/gpu/drm/bridge/parade-ps8640.c index 685e9c38b2db..18328e75bf90 100644 --- a/drivers/gpu/drm/bridge/parade-ps8640.c +++ b/drivers/gpu/drm/bridge/parade-ps8640.c @@ -9,6 +9,7 @@ #include <linux/i2c.h> #include <linux/module.h> #include <linux/of_graph.h> +#include <linux/regmap.h> #include <linux/regulator/consumer.h> #include <drm/drm_bridge.h> @@ -31,6 +32,11 @@ #define NUM_MIPI_LANES 4 +#define COMMON_PS8640_REGMAP_CONFIG \ + .reg_bits = 8, \ + .val_bits = 8, \ + .cache_type = REGCACHE_NONE + /* * PS8640 uses multiple addresses: * page[0]: for DP control @@ -64,12 +70,48 @@ struct ps8640 { struct drm_bridge *panel_bridge; struct mipi_dsi_device *dsi; struct i2c_client *page[MAX_DEVS]; + struct regmap *regmap[MAX_DEVS]; struct regulator_bulk_data supplies[2]; struct gpio_desc *gpio_reset; struct gpio_desc *gpio_powerdown; bool powered; }; +static const struct regmap_config ps8640_regmap_config[] = { + [PAGE0_DP_CNTL] = { + COMMON_PS8640_REGMAP_CONFIG, + .max_register = 0xbf, + }, + [PAGE1_VDO_BDG] = { + COMMON_PS8640_REGMAP_CONFIG, + .max_register = 0xff, + }, + [PAGE2_TOP_CNTL] = { + COMMON_PS8640_REGMAP_CONFIG, + .max_register = 0xff, + }, + [PAGE3_DSI_CNTL1] = { + COMMON_PS8640_REGMAP_CONFIG, + .max_register = 0xff, + }, + [PAGE4_MIPI_PHY] = { + COMMON_PS8640_REGMAP_CONFIG, + .max_register = 0xff, + }, + [PAGE5_VPLL] = { + COMMON_PS8640_REGMAP_CONFIG, + .max_register = 0x7f, + }, + [PAGE6_DSI_CNTL2] = { + COMMON_PS8640_REGMAP_CONFIG, + .max_register = 0xff, + }, + [PAGE7_SPI_CNTL] = { + COMMON_PS8640_REGMAP_CONFIG, + .max_register = 0xff, + }, +}; + static inline struct ps8640 *bridge_to_ps8640(struct drm_bridge *e) { return container_of(e, struct ps8640, bridge); @@ -78,13 +120,13 @@ static inline struct ps8640 *bridge_to_ps8640(struct drm_bridge *e) static int ps8640_bridge_vdo_control(struct ps8640 *ps_bridge, const enum ps8640_vdo_control ctrl) { - struct i2c_client *client = ps_bridge->page[PAGE3_DSI_CNTL1]; + struct regmap *map = ps_bridge->regmap[PAGE3_DSI_CNTL1]; u8 vdo_ctrl_buf[] = { VDO_CTL_ADD, ctrl }; int ret; - ret = i2c_smbus_write_i2c_block_data(client, PAGE3_SET_ADD, - sizeof(vdo_ctrl_buf), - vdo_ctrl_buf); + ret = regmap_bulk_write(map, PAGE3_SET_ADD, + vdo_ctrl_buf, sizeof(vdo_ctrl_buf)); + if (ret < 0) { DRM_ERROR("failed to %sable VDO: %d\n", ctrl == ENABLE ? "en" : "dis", ret); @@ -96,8 +138,7 @@ static int ps8640_bridge_vdo_control(struct ps8640 *ps_bridge, static void ps8640_bridge_poweron(struct ps8640 *ps_bridge) { - struct i2c_client *client = ps_bridge->page[PAGE2_TOP_CNTL]; - unsigned long timeout; + struct regmap *map = ps_bridge->regmap[PAGE2_TOP_CNTL]; int ret, status; if (ps_bridge->powered) @@ -121,18 +162,12 @@ static void ps8640_bridge_poweron(struct ps8640 *ps_bridge) */ msleep(200); - timeout = jiffies + msecs_to_jiffies(200) + 1; - - while (time_is_after_jiffies(timeout)) { - status = i2c_smbus_read_byte_data(client, PAGE2_GPIO_H); - if (status < 0) { - DRM_ERROR("failed read PAGE2_GPIO_H: %d\n", status); - goto err_regulators_disable; - } - if ((status & PS_GPIO9) == PS_GPIO9) - break; + ret = regmap_read_poll_timeout(map, PAGE2_GPIO_H, status, + status & PS_GPIO9, 20 * 1000, 200 * 1000); - msleep(20); + if (ret < 0) { + DRM_ERROR("failed read PAGE2_GPIO_H: %d\n", ret); + goto err_regulators_disable; } msleep(50); @@ -144,22 +179,15 @@ static void ps8640_bridge_poweron(struct ps8640 *ps_bridge) * disabled by the manufacturer. Once disabled, all MCS commands are * ignored by the display interface. */ - status = i2c_smbus_read_byte_data(client, PAGE2_MCS_EN); - if (status < 0) { - DRM_ERROR("failed read PAGE2_MCS_EN: %d\n", status); - goto err_regulators_disable; - } - ret = i2c_smbus_write_byte_data(client, PAGE2_MCS_EN, - status & ~MCS_EN); + ret = regmap_update_bits(map, PAGE2_MCS_EN, MCS_EN, 0); if (ret < 0) { DRM_ERROR("failed write PAGE2_MCS_EN: %d\n", ret); goto err_regulators_disable; } /* Switch access edp panel's edid through i2c */ - ret = i2c_smbus_write_byte_data(client, PAGE2_I2C_BYPASS, - I2C_BYPASS_EN); + ret = regmap_write(map, PAGE2_I2C_BYPASS, I2C_BYPASS_EN); if (ret < 0) { DRM_ERROR("failed write PAGE2_I2C_BYPASS: %d\n", ret); goto err_regulators_disable; @@ -362,15 +390,21 @@ static int ps8640_probe(struct i2c_client *client) ps_bridge->page[PAGE0_DP_CNTL] = client; + ps_bridge->regmap[PAGE0_DP_CNTL] = devm_regmap_init_i2c(client, ps8640_regmap_config); + if (IS_ERR(ps_bridge->regmap[PAGE0_DP_CNTL])) + return PTR_ERR(ps_bridge->regmap[PAGE0_DP_CNTL]); + for (i = 1; i < ARRAY_SIZE(ps_bridge->page); i++) { ps_bridge->page[i] = devm_i2c_new_dummy_device(&client->dev, client->adapter, client->addr + i); - if (IS_ERR(ps_bridge->page[i])) { - dev_err(dev, "failed i2c dummy device, address %02x\n", - client->addr + i); + if (IS_ERR(ps_bridge->page[i])) return PTR_ERR(ps_bridge->page[i]); - } + + ps_bridge->regmap[i] = devm_regmap_init_i2c(ps_bridge->page[i], + ps8640_regmap_config + i); + if (IS_ERR(ps_bridge->regmap[i])) + return PTR_ERR(ps_bridge->regmap[i]); } i2c_set_clientdata(client, ps_bridge); -- 2.33.0.464.g1972c5931b-goog

3 5

[PATCH v3 0/6] drm/vc4: hdmi: Fix CEC access while disabled
by Maxime Ripard 23 Sep '21

23 Sep '21

Hi, This series aims at fixing a complete and silent hang when one tries to use CEC while the display output is off. This can be tested with: echo off > /sys/class/drm/card0-HDMI-A-1/status cec-ctl --tuner -p 1.0.0.0 cec-compliance This series addresses it by making sure the HDMI controller is powered up as soon as the CEC device is opened by the userspace. Let me know what you think, Maxime Changes from v2: - Rebased on top of drm-misc-fixes - Fixed a build error Changes from v1: - More fixes - Added a big warning if we try to access a register while the device is disabled. - Fixed the pre_crtc_configure error path Maxime Ripard (6): drm/vc4: select PM drm/vc4: hdmi: Make sure the controller is powered up during bind drm/vc4: hdmi: Rework the pre_crtc_configure error handling drm/vc4: hdmi: Split the CEC disable / enable functions in two drm/vc4: hdmi: Make sure the device is powered with CEC drm/vc4: hdmi: Warn if we access the controller while disabled drivers/gpu/drm/vc4/Kconfig | 1 + drivers/gpu/drm/vc4/vc4_hdmi.c | 125 ++++++++++++++++++---------- drivers/gpu/drm/vc4/vc4_hdmi_regs.h | 6 ++ 3 files changed, 90 insertions(+), 42 deletions(-) -- 2.31.1

4 14

[PATCH v6 0/9] drm/i915: Suspend / resume backup- and restore of LMEM.
by Thomas Hellström 23 Sep '21

23 Sep '21

Implement backup and restore of LMEM during suspend / resume. What complicates things a bit is handling of pinned LMEM memory during suspend and the fact that we might be dealing with unmappable LMEM in the future, which makes us want to restrict the number of pinned objects that need memcpy resume. The first two patches are prereq patches implementing object content copy and a generic means of iterating through all objects in a region. The third patch adds the backup / recover / restore functions and the two last patches deal with restricting the number of objects we need to use memcpy for. v2: - Some polishing of patch 4/6, see patch commit message for details (Chris Wilson) - Rework of patch 3/6. v3: - Comment changes in patch 2/6 (Matthew Auld) - A number of changes to patch 3/6, see commit message. - Slightly reword comment in patch 5/6. (Matthew Auld). v4: - Various cleanups, among other things reworking the ttm / lmem backup- and resume interfaces somewhat. v5: - GuC adaptations. Mark GuC LMEM objects for early resume and increase the suspend idle timeout. v6: - Add two HAX patches to make broken CI happy. Kai Vehmanen (1): HAX: component: do not leave master devres group open after bind Thomas Hellström (8): drm/i915/ttm: Implement a function to copy the contents of two TTM-based objects drm/i915/gem: Implement a function to process all gem objects of a region drm/i915/gt: Increase suspend timeout drm/i915 Implement LMEM backup and restore for suspend / resume drm/i915/gt: Register the migrate contexts with their engines drm/i915: Don't back up pinned LMEM context images and rings during suspend drm/i915: Reduce the number of objects subject to memcpy recover HAX: drm/i915/gem: Fix the __i915_gem_is_lmem() function drivers/base/component.c | 5 +- drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/gem/i915_gem_context.c | 4 +- drivers/gpu/drm/i915/gem/i915_gem_lmem.c | 2 +- .../gpu/drm/i915/gem/i915_gem_object_types.h | 21 +- drivers/gpu/drm/i915/gem/i915_gem_pm.c | 91 ++++++++ drivers/gpu/drm/i915/gem/i915_gem_pm.h | 1 + drivers/gpu/drm/i915/gem/i915_gem_region.c | 70 ++++++ drivers/gpu/drm/i915/gem/i915_gem_region.h | 37 ++++ drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 99 +++++++-- drivers/gpu/drm/i915/gem/i915_gem_ttm.h | 14 ++ drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c | 206 ++++++++++++++++++ drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.h | 26 +++ .../gpu/drm/i915/gem/selftests/huge_pages.c | 2 +- drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 2 +- drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 5 +- drivers/gpu/drm/i915/gt/gen8_ppgtt.h | 4 +- drivers/gpu/drm/i915/gt/intel_context_types.h | 8 + drivers/gpu/drm/i915/gt/intel_engine_cs.c | 4 + drivers/gpu/drm/i915/gt/intel_engine_pm.c | 23 ++ drivers/gpu/drm/i915/gt/intel_engine_pm.h | 2 + drivers/gpu/drm/i915/gt/intel_engine_types.h | 7 + .../drm/i915/gt/intel_execlists_submission.c | 2 + drivers/gpu/drm/i915/gt/intel_ggtt.c | 3 +- drivers/gpu/drm/i915/gt/intel_gt.c | 2 +- drivers/gpu/drm/i915/gt/intel_gt_pm.c | 8 +- drivers/gpu/drm/i915/gt/intel_gtt.c | 3 +- drivers/gpu/drm/i915/gt/intel_gtt.h | 9 +- drivers/gpu/drm/i915/gt/intel_lrc.c | 3 +- drivers/gpu/drm/i915/gt/intel_migrate.c | 2 +- drivers/gpu/drm/i915/gt/intel_ppgtt.c | 13 +- drivers/gpu/drm/i915/gt/intel_ring.c | 3 +- .../gpu/drm/i915/gt/intel_ring_submission.c | 3 + drivers/gpu/drm/i915/gt/mock_engine.c | 2 + drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 2 +- drivers/gpu/drm/i915/gt/uc/intel_guc.c | 3 +- .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 12 +- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 7 +- drivers/gpu/drm/i915/gvt/scheduler.c | 2 +- drivers/gpu/drm/i915/i915_drv.c | 4 +- drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 4 +- 41 files changed, 658 insertions(+), 63 deletions(-) create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.h -- 2.31.1

3 18

[PATCH] drm/i915/guc, docs: Fix pdfdocs build error by removing nested grid
by Akira Yokosawa 23 Sep '21

23 Sep '21

Nested grids in grid-table cells are not specified as proper ReST constructs. Commit 572f2a5cd974 ("drm/i915/guc: Update firmware to v62.0.0") added a couple of kerneldoc tables of the form: +---+-------+------------------------------------------------------+ | 1 | 31:0 | +------------------------------------------------+ | +---+-------+ | | | |...| | | Embedded `HXG Message`_ | | +---+-------+ | | | | n | 31:0 | +------------------------------------------------+ | +---+-------+------------------------------------------------------+ For "make htmldocs", they happen to work as one might expect, but they are incompatible with "make latexdocs" and "make pdfdocs", and cause the generated gpu.tex file to become incomplete and unbuildable by xelatex. Restore the compatibility by removing those nested grids in the tables. Size comparison of generated gpu.tex: Sphinx 2.4.4 Sphinx 4.2.0 v5.14: 3238686 3841631 v5.15-rc1: 376270 432729 with this fix: 3377846 3998095 Fixes: 572f2a5cd974 ("drm/i915/guc: Update firmware to v62.0.0") Cc: John Harrison <John.C.Harrison(a)Intel.com> Cc: Michal Wajdeczko <michal.wajdeczko(a)intel.com> Cc: Matthew Brost <matthew.brost(a)intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio(a)intel.com> Cc: Matt Roper <matthew.d.roper(a)intel.com> Cc: Jonathan Corbet <corbet(a)lwn.net> Signed-off-by: Akira Yokosawa <akiyks(a)gmail.com> --- Hi all, I know there is little interest in building pdfdocs (or LaTeX) version of kernel-doc, and this issue does not matter most of you. But "make pdfdocs" is supposed to work, give or take those tables with squeezed columns, and at least it is expected to complete without fatal errors. I have no idea who is responsible to those grid-tables, so added a lot of people in the To: and Cc: lists. Does removing those nested grids look reasonable to you? Any feedback is welcome! Note: This patch is against the docs-next branch of Jon's -doc tree (git://git.lwn.net/linux.git). It can be applied against v5.15-rc1 and v5.15-rc2 as well. Thanks, Akira -- .../gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h | 10 +++++----- .../drm/i915/gt/uc/abi/guc_communication_mmio_abi.h | 10 +++++----- 2 files changed, 10 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h index 99e1fad5ca20..c9086a600bce 100644 --- a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h +++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h @@ -102,11 +102,11 @@ static_assert(sizeof(struct guc_ct_buffer_desc) == 64); * | +-------+--------------------------------------------------------------+ * | | 7:0 | NUM_DWORDS = length (in dwords) of the embedded HXG message | * +---+-------+--------------------------------------------------------------+ - * | 1 | 31:0 | +--------------------------------------------------------+ | - * +---+-------+ | | | - * |...| | | Embedded `HXG Message`_ | | - * +---+-------+ | | | - * | n | 31:0 | +--------------------------------------------------------+ | + * | 1 | 31:0 | | + * +---+-------+ | + * |...| | [Embedded `HXG Message`_] | + * +---+-------+ | + * | n | 31:0 | | * +---+-------+--------------------------------------------------------------+ */ diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h index bbf1ddb77434..9baa3cb07d13 100644 --- a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h +++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h @@ -38,11 +38,11 @@ * +---+-------+--------------------------------------------------------------+ * | | Bits | Description | * +===+=======+==============================================================+ - * | 0 | 31:0 | +--------------------------------------------------------+ | - * +---+-------+ | | | - * |...| | | Embedded `HXG Message`_ | | - * +---+-------+ | | | - * | n | 31:0 | +--------------------------------------------------------+ | + * | 0 | 31:0 | | + * +---+-------+ | + * |...| | [Embedded `HXG Message`_] | + * +---+-------+ | + * | n | 31:0 | | * +---+-------+--------------------------------------------------------------+ */ base-commit: 242f4c77b1c8cebfdfa0ad5b40e2e4ae0316e57d -- 2.17.1

2 2

Multiple DRI card detection in compositor systemd units
by Hoosier, Matt 23 Sep '21

23 Sep '21

I'm trying to find a robust way to handle the phrasing of UDev rules and systemd dependencies about /dev/dri/cardXXX nodes to ensure that several compositor services running on different graphics cards of a device all can reliably start up. First, some basic observations: * The DRM subsystem in the kernel will automatically acquire DRM master status on an fd opened against a card, if no other fd open against that card is already a DRM master. * DRI cards do have a human-readable identifier -- the "name" field reported by drmGetVersion() -- which can be used to reliably identify them. But this name is not exposed as a sysfs attribute on the device. So it's invisible to UDev rules. * DRI cards initialize in parallel to each other, so the basic kernel names such as 'card0', 'card1', and similar are not stable. On a system with multiple cards with each one used by a separate compositor application, this makes it a bit difficult to start each compositor only when its specific card is enumerated in UDev a bit tricky. * The lack of a sysfs property exposing the drmGetVersion()->name field, makes phrasing a UDev rule directly such as this impossible: SUBSYSTEM=="drm", ATTRS{name}=="amd", SYMLINK+="card-amd", TAG+="systemd" * You could imagine writing a helper program invoked by the UDev rule: SUBSYSTEM=="drm", PROGRAM="print-dri-symlink-name $env{DEVNAME}" SYMLINK+="%c", TAG+="systemd" The "print-dri-symlink-name" program would be responsible for using the libdrm API to fetch out the card's "name" property. * But it is not guaranteed that UDev rules fire only once for a given sysfs device. Which means that the next bullet point applies. * The UDev helper program temporarily acquires DRM master status because of that built-in behavior from the DRI subsystem. If you're unlucky, this will conflict with the compositor's legitimate attempt to become DRM master. If the systemd .device unit (e.g. dev-dri-card-amd.device) activated by the initial UDev rule firing is already up and running, and a second UDev rule instance executes at the same time that a compositor application is just starting up, there is a small but feasible chance that the UDev helper program will acquire DRM master rights during exactly the duration that the compositor is attempting its own initializer. The compositor will therefore be denied DRM master status, and fail. I'm not really sure how the race in the final bullet point can be prevented. It seems to me that the only ironclad way to avoid it would be to perform the UDev rule matches strictly based on sysfs attributes. Has there ever been any talk about exporting the DRI card name through sysfs? On the other hand, maybe I'm approach this problem completely wrongly. Is it a losing game to try to phrase systemd ordering constraints on /dev/dri cards? -Matt

3 4

[PATCH] drm/ttm: Don't delete the system manager before the delayed delete
by Zack Rusin 23 Sep '21

23 Sep '21

On some hardware, in particular in virtualized environments, the system memory can be shared with the "hardware". In those cases the BO's allocated through the ttm system manager might be busy during ttm_bo_put which results in them being scheduled for a delayed deletion. The problem is that that the ttm system manager is disabled before the final delayed deletion is ran in ttm_device_fini. This results in crashes during freeing of the BO resources because they're trying to remove themselves from a no longer existent ttm_resource_manager (e.g. in IGT's core_hotunplug on vmwgfx) In general reloading any driver that could share system mem resources with "hardware" could hit it because nothing prevents the system mem resources from being scheduled for delayed deletion (apart from them not being busy probably anywhere apart from virtualized environments). Signed-off-by: Zack Rusin <zackr(a)vmware.com> Cc: Christian Koenig <christian.koenig(a)amd.com> Cc: Huang Rui <ray.huang(a)amd.com> Cc: David Airlie <airlied(a)linux.ie> Cc: Daniel Vetter <daniel(a)ffwll.ch> Cc: dri-devel(a)lists.freedesktop.org --- drivers/gpu/drm/ttm/ttm_device.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/ttm/ttm_device.c b/drivers/gpu/drm/ttm/ttm_device.c index 9eb8f54b66fc..4ef19cafc755 100644 --- a/drivers/gpu/drm/ttm/ttm_device.c +++ b/drivers/gpu/drm/ttm/ttm_device.c @@ -225,10 +225,6 @@ void ttm_device_fini(struct ttm_device *bdev) struct ttm_resource_manager *man; unsigned i; - man = ttm_manager_type(bdev, TTM_PL_SYSTEM); - ttm_resource_manager_set_used(man, false); - ttm_set_driver_manager(bdev, TTM_PL_SYSTEM, NULL); - mutex_lock(&ttm_global_mutex); list_del(&bdev->device_list); mutex_unlock(&ttm_global_mutex); @@ -238,6 +234,10 @@ void ttm_device_fini(struct ttm_device *bdev) if (ttm_bo_delayed_delete(bdev, true)) pr_debug("Delayed destroy list was clean\n"); + man = ttm_manager_type(bdev, TTM_PL_SYSTEM); + ttm_resource_manager_set_used(man, false); + ttm_set_driver_manager(bdev, TTM_PL_SYSTEM, NULL); + spin_lock(&bdev->lru_lock); for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) if (list_empty(&man->lru[0])) -- 2.30.2

3 5

[PATCH RESEND] drm/i915: Flush buffer pools on driver remove
by Janusz Krzysztofik 23 Sep '21

23 Sep '21

In preparation for clean driver release, attempts to drain work queues and release freed objects are taken at driver remove time. However, GT buffer pools are now not flushed before the driver release phase. Since unused objects may stay there for up to one second, some may survive until driver release is attempted. That can potentially explain sporadic then hardly reproducible issues observed at driver release time, like non-zero shrink counter or outstanding address space areas. Flush buffer pools on GT remove as a fix. On driver release, don't flush the pools again, just assert that the flush was called and nothing added more in between. Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik(a)linux.intel.com> Cc: Chris Wilson <chris(a)chris-wilson.co.uk> --- Resending with Cc: dri-devel(a)lists.freedesktop.org as requested, and a typo in commit description fixed. Thanks, Janusz drivers/gpu/drm/i915/gt/intel_gt.c | 2 ++ drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c | 2 -- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c b/drivers/gpu/drm/i915/gt/intel_gt.c index 62d40c986642..8f322a4ecd87 100644 --- a/drivers/gpu/drm/i915/gt/intel_gt.c +++ b/drivers/gpu/drm/i915/gt/intel_gt.c @@ -737,6 +737,8 @@ void intel_gt_driver_remove(struct intel_gt *gt) intel_uc_driver_remove(&gt->uc); intel_engines_release(gt); + + intel_gt_flush_buffer_pool(gt); } void intel_gt_driver_unregister(struct intel_gt *gt) diff --git a/drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c b/drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c index aa0a59c5b614..acc49c56a9f3 100644 --- a/drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c +++ b/drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c @@ -245,8 +245,6 @@ void intel_gt_fini_buffer_pool(struct intel_gt *gt) struct intel_gt_buffer_pool *pool = &gt->buffer_pool; int n; - intel_gt_flush_buffer_pool(gt); - for (n = 0; n < ARRAY_SIZE(pool->cache_list); n++) GEM_BUG_ON(!list_empty(&pool->cache_list[n])); } -- 2.25.1

2 3

← Newer
1
...
34
35
36
37
38
39
40
...
82
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel September 2021