dri-devel June 2021

dri-devel@lists.freedesktop.org

341 participants
878 discussions

[PATCH 0/2] GuC submission / DRM scheduler integration plan + new uAPI
by Matthew Brost 18 Jun '21

18 Jun '21

Subject and patches say it all. v2: Address comments, patches have details of changes v3: Address comments, patches have details of changes v4: Address comments, patches have details of changes Signed-off-by: Matthew Brost <matthew.brost(a)intel.com> Matthew Brost (2): drm/doc/rfc: i915 GuC submission / DRM scheduler drm/doc/rfc: i915 new parallel submission uAPI plan Documentation/gpu/rfc/i915_parallel_execbuf.h | 117 ++++++++++++++ Documentation/gpu/rfc/i915_scheduler.rst | 148 ++++++++++++++++++ Documentation/gpu/rfc/index.rst | 4 + 3 files changed, 269 insertions(+) create mode 100644 Documentation/gpu/rfc/i915_parallel_execbuf.h create mode 100644 Documentation/gpu/rfc/i915_scheduler.rst -- 2.28.0

3 4

[PATCH] drm/dp_mst: Add missing drm parameters to recently added call to drm_dbg_kms()
by José Roberto de Souza 18 Jun '21

18 Jun '21

Commit 3769e4c0af5b ("drm/dp_mst: Avoid to mess up payload table by ports in stale topology") added to calls to drm_dbg_kms() but it missed the first parameter, the drm device breaking the build. Fixes: 3769e4c0af5b ("drm/dp_mst: Avoid to mess up payload table by ports in stale topology") Cc: Wayne Lin <Wayne.Lin(a)amd.com> Cc: Lyude Paul <lyude(a)redhat.com> Cc: dri-devel(a)lists.freedesktop.org Signed-off-by: José Roberto de Souza <jose.souza(a)intel.com> --- drivers/gpu/drm/drm_dp_mst_topology.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c b/drivers/gpu/drm/drm_dp_mst_topology.c index 9ac148efd9e43..ad0795afc21cf 100644 --- a/drivers/gpu/drm/drm_dp_mst_topology.c +++ b/drivers/gpu/drm/drm_dp_mst_topology.c @@ -3389,7 +3389,9 @@ int drm_dp_update_payload_part1(struct drm_dp_mst_topology_mgr *mgr) mutex_unlock(&mgr->lock); if (skip) { - drm_dbg_kms("Virtual channel %d is not in current topology\n", i); + drm_dbg_kms(mgr->dev, + "Virtual channel %d is not in current topology\n", + i); continue; } /* Validated ports don't matter if we're releasing @@ -3404,7 +3406,8 @@ int drm_dp_update_payload_part1(struct drm_dp_mst_topology_mgr *mgr) payload->start_slot = req_payload.start_slot; continue; } else { - drm_dbg_kms("Fail:set payload to invalid sink"); + drm_dbg_kms(mgr->dev, + "Fail:set payload to invalid sink"); mutex_unlock(&mgr->payload_lock); return -EINVAL; } -- 2.32.0

3 3

[PATCH v3] drm/i915: Document the Virtual Engine uAPI
by Tvrtko Ursulin 18 Jun '21

18 Jun '21

From: Tvrtko Ursulin <tvrtko.ursulin(a)intel.com> A little bit of documentation covering the topics of engine discovery, context engine maps and virtual engines. It is not very detailed but supposed to be a starting point of giving a brief high level overview of general principles and intended use cases. v3: * Move text to driver-uapi.rst. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin(a)intel.com> Cc: Daniel Vetter <daniel(a)ffwll.ch> --- Pick between v2 with text in i915_drm.h, or this v3 in driver-uapi.rst. --- Documentation/gpu/driver-uapi.rst | 184 ++++++++++++++++++++++++++++++ 1 file changed, 184 insertions(+) diff --git a/Documentation/gpu/driver-uapi.rst b/Documentation/gpu/driver-uapi.rst index 4411e6919a3d..17013fb68618 100644 --- a/Documentation/gpu/driver-uapi.rst +++ b/Documentation/gpu/driver-uapi.rst @@ -5,4 +5,188 @@ DRM Driver uAPI drm/i915 uAPI ============= +Engine Discovery uAPI +--------------------- + +Engine discovery uAPI is a way of enumerating physical engines present in a GPU +associated with an open i915 DRM file descriptor. This supersedes the old way of +using `DRM_IOCTL_I915_GETPARAM` and engine identifiers like +`I915_PARAM_HAS_BLT`. + +The need for this interface came starting with Icelake and newer GPUs, which +started establishing a pattern of having multiple engines of a same class, where +not all instances were always completely functionally equivalent. + +Entry point for this uapi is `DRM_IOCTL_I915_QUERY` with the +`DRM_I915_QUERY_ENGINE_INFO` as the queried item id. + +Example for getting the list of engines: + +.. code-block:: C + + struct drm_i915_query_engine_info *info; + struct drm_i915_query_item item = { + .query_id = DRM_I915_QUERY_ENGINE_INFO; + }; + struct drm_i915_query query = { + .num_items = 1, + .items_ptr = (uintptr_t)&item, + }; + int err, i; + + // First query the size of the blob we need, this needs to be large + // enough to hold our array of engines. The kernel will fill out the + // item.length for us, which is the number of bytes we need. + // + // Alternatively a large buffer can be allocated straight away enabling + // querying in one pass, in which case item.length should contain the + // length of the provided buffer. + err = ioctl(fd, DRM_IOCTL_I915_QUERY, &query); + if (err) ... + + info = calloc(1, item.length); + // Now that we allocated the required number of bytes, we call the ioctl + // again, this time with the data_ptr pointing to our newly allocated + // blob, which the kernel can then populate with info on all engines. + item.data_ptr = (uintptr_t)&info, + + err = ioctl(fd, DRM_IOCTL_I915_QUERY, &query); + if (err) ... + + // We can now access each engine in the array + for (i = 0; i < info->num_engines; i++) { + struct drm_i915_engine_info einfo = info->engines[i]; + u16 class = einfo.engine.class; + u16 instance = einfo.engine.instance; + .... + } + + free(info); + +Each of the enumerated engines, apart from being defined by its class and +instance (see `struct i915_engine_class_instance`), also can have flags and +capabilities defined as documented in i915_drm.h. + +For instance video engines which support HEVC encoding will have the +`I915_VIDEO_CLASS_CAPABILITY_HEVC` capability bit set. + +Engine discovery only fully comes to its own when combined with the new way of +addressing engines when submitting batch buffers using contexts with engine +maps configured. + +Context Engine Map uAPI +----------------------- + +Context engine map is a new way of addressing engines when submitting batch- +buffers, replacing the existing way of using identifiers like `I915_EXEC_BLT` +inside the flags field of `struct drm_i915_gem_execbuffer2`. + +To use it created GEM contexts need to be configured with a list of engines +the user is intending to submit to. This is accomplished using the +`I915_CONTEXT_PARAM_ENGINES` parameter and `struct i915_context_param_engines`. + +For such contexts the `I915_EXEC_RING_MASK` field becomes an index into the +configured map. + +Example of creating such context and submitting against it: + +.. code-block:: C + + I915_DEFINE_CONTEXT_PARAM_ENGINES(engines, 2) = { + .engines = { { I915_ENGINE_CLASS_RENDER, 0 }, + { I915_ENGINE_CLASS_COPY, 0 } } + }; + struct drm_i915_gem_context_create_ext_setparam p_engines = { + .base = { + .name = I915_CONTEXT_CREATE_EXT_SETPARAM, + }, + .param = { + .param = I915_CONTEXT_PARAM_ENGINES, + .value = to_user_pointer(&engines), + .size = sizeof(engines), + }, + }; + struct drm_i915_gem_context_create_ext create = { + .flags = I915_CONTEXT_CREATE_FLAGS_USE_EXTENSIONS, + .extensions = to_user_pointer(&p_engines); + }; + + ctx_id = gem_context_create_ext(drm_fd, &create); + + // We have now created a GEM context with two engines in the map: + // Index 0 points to rcs0 while index 1 points to bcs0. Other engines + // will not be accessible from this context. + + ... + execbuf.rsvd1 = ctx_id; + execbuf.flags = 0; // Submits to index 0, which is rcs0 for this context + gem_execbuf(drm_fd, &execbuf); + + ... + execbuf.rsvd1 = ctx_id; + execbuf.flags = 1; // Submits to index 0, which is bcs0 for this context + gem_execbuf(drm_fd, &execbuf); + +Virtual Engine uAPI +------------------- + +Virtual engine is a concept where userspace is able to configure a set of +physical engines, submit a batch buffer, and let the driver execute it on any +engine from the set as it sees fit. + +This is primarily useful on parts which have multiple instances of a same class +engine, like for example GT3+ Skylake parts with their two VCS engines. + +For instance userspace can enumerate all engines of a certain class using the +previously described `Engine Discovery uAPI`_. After +that userspace can create a GEM context with a placeholder slot for the virtual +engine (using `I915_ENGINE_CLASS_INVALID` and `I915_ENGINE_CLASS_INVALID_NONE` +for class and instance respectively) and finally using the +`I915_CONTEXT_ENGINES_EXT_LOAD_BALANCE` extension place a virtual engine in the +same reserved slot. + +Example of creating a virtual engine and submitting a batch buffer to it: + +.. code-block:: C + + I915_DEFINE_CONTEXT_ENGINES_LOAD_BALANCE(virtual, 2) = { + .base.name = I915_CONTEXT_ENGINES_EXT_LOAD_BALANCE, + .engine_index = 0, // Place this virtual engine into engine map slot 0 + .num_siblings = 2, + .engines = { { I915_ENGINE_CLASS_VIDEO, 0 }, + { I915_ENGINE_CLASS_VIDEO, 1 }, }, + }; + I915_DEFINE_CONTEXT_PARAM_ENGINES(engines, 1) = { + .engines = { { I915_ENGINE_CLASS_INVALID, + I915_ENGINE_CLASS_INVALID_NONE } }, + .extensions = to_user_pointer(&virtual), // Chains after load_balance extension + }; + struct drm_i915_gem_context_create_ext_setparam p_engines = { + .base = { + .name = I915_CONTEXT_CREATE_EXT_SETPARAM, + }, + .param = { + .param = I915_CONTEXT_PARAM_ENGINES, + .value = to_user_pointer(&engines), + .size = sizeof(engines), + }, + }; + struct drm_i915_gem_context_create_ext create = { + .flags = I915_CONTEXT_CREATE_FLAGS_USE_EXTENSIONS, + .extensions = to_user_pointer(&p_engines); + }; + + ctx_id = gem_context_create_ext(drm_fd, &create); + + // Now we have created a GEM context with its engine map containing a + // single virtual engine. Submissions to this slot can go either to + // vcs0 or vcs1, depending on the load balancing algorithm used inside + // the driver. The load balancing is dynamic from one batch buffer to + // another and transparent to userspace. + + ... + execbuf.rsvd1 = ctx_id; + execbuf.flags = 0; // Submits to index 0 which is the virtual engine + gem_execbuf(drm_fd, &execbuf); + .. kernel-doc:: include/uapi/drm/i915_drm.h -- 2.30.2

1 0

[PATCH 1/2] drm/i915/selftests: add back the selftest() hook for the buddy
by Matthew Auld 18 Jun '21

18 Jun '21

When we resurrected the selftest we forgot to add back the selftest() hook, meaning the test is not currently run. Reported-by: kernel test robot <lkp(a)intel.com> Signed-off-by: Matthew Auld <matthew.auld(a)intel.com> Cc: Thomas Hellström <thomas.hellstrom(a)linux.intel.com> --- drivers/gpu/drm/i915/selftests/i915_mock_selftests.h | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/selftests/i915_mock_selftests.h b/drivers/gpu/drm/i915/selftests/i915_mock_selftests.h index 34e5caf38093..6759b56086fb 100644 --- a/drivers/gpu/drm/i915/selftests/i915_mock_selftests.h +++ b/drivers/gpu/drm/i915/selftests/i915_mock_selftests.h @@ -34,3 +34,4 @@ selftest(gtt, i915_gem_gtt_mock_selftests) selftest(hugepages, i915_gem_huge_page_mock_selftests) selftest(contexts, i915_gem_context_mock_selftests) selftest(memory_region, intel_memory_region_mock_selftests) +selftest(buddy, i915_buddy_mock_selftests) -- 2.26.3

2 5

[PATCH] drm/i915/ttm: Fix incorrect assumptions about ttm_bo_validate() semantics
by Thomas Hellström 18 Jun '21

18 Jun '21

We have assumed that if the current placement was not the requested placement, but instead one of the busy placements, a TTM move would have been triggered. That is not the case. So when we initially place LMEM objects in "Limbo", (that is system placement without any pages allocated), to be able to defer clearing objects until first get_pages(), the first get_pages() would happily keep objects in system memory if that is one of the allowed placements. And since we don't yet support i915 GEM system memory from TTM, everything breaks apart. So make sure we try the requested placement first, if no eviction is needed. If that fails, retry with all allowed placements also allowing evictions. Also make sure we handle TTM failure codes correctly. Also temporarily (until we support i915 GEM system on TTM), restrict allowed placements to the requested placement to avoid things falling apart should LMEM be full. Fixes: 38f28c0695c0 ("drm/i915/ttm: Calculate the object placement at get_pages time) Signed-off-by: Thomas Hellström <thomas.hellstrom(a)linux.intel.com> --- drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 61 +++++++++++++++++++++++-- 1 file changed, 58 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c index df46535cca47..4bb0440f693c 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c @@ -64,6 +64,30 @@ static struct ttm_placement i915_sys_placement = { .busy_placement = &sys_placement_flags, }; +static int i915_ttm_err_to_gem(int err) +{ + /* Fastpath */ + if (likely(!err)) + return 0; + + switch (err) { + case -EBUSY: + /* + * TTM likes to convert -EDEADLK to -EBUSY, and wants us to + * restart the operation, since we don't record the contending + * lock. We use -EAGAIN to restart. + */ + return -EAGAIN; + case -ENOSPC: + /* Memory type / region is full, and we can't evict. */ + return -ENXIO; + default: + break; + } + + return err; +} + static void i915_ttm_adjust_lru(struct drm_i915_gem_object *obj); static enum ttm_caching @@ -522,15 +546,46 @@ static int i915_ttm_get_pages(struct drm_i915_gem_object *obj) struct sg_table *st; struct ttm_place requested, busy[I915_TTM_MAX_PLACEMENTS]; struct ttm_placement placement; + int real_num_busy; int ret; GEM_BUG_ON(obj->mm.n_placements > I915_TTM_MAX_PLACEMENTS); /* Move to the requested placement. */ i915_ttm_placement_from_obj(obj, &requested, busy, &placement); + + /* + * For now we support LMEM only with TTM. + * TODO: Remove with system support + */ + GEM_BUG_ON(requested.mem_type < I915_PL_LMEM0 || + busy[0].mem_type < I915_PL_LMEM0); + + /* First try only the requested placement. No eviction. */ + real_num_busy = fetch_and_zero(&placement.num_busy_placement); ret = ttm_bo_validate(bo, &placement, &ctx); - if (ret) - return ret == -ENOSPC ? -ENXIO : ret; + if (ret) { + ret = i915_ttm_err_to_gem(ret); + /* + * Anything that wants to restart the operation gets to + * do that. + */ + if (ret == -EDEADLK || ret == -EINTR || ret == -ERESTARTSYS || + ret == -EAGAIN) + return ret; + + /* TODO: Remove this when we support system as TTM. */ + real_num_busy = 1; + + /* + * If the initial attempt fails, allow all accepted placements, + * evicting if necessary. + */ + placement.num_busy_placement = real_num_busy; + ret = ttm_bo_validate(bo, &placement, &ctx); + if (ret) + return i915_ttm_err_to_gem(ret); + } /* Object either has a page vector or is an iomem object */ st = bo->ttm ? i915_ttm_tt_get_st(bo->ttm) : obj->ttm.cached_io_st; @@ -741,5 +796,5 @@ int __i915_gem_ttm_object_init(struct intel_memory_region *mem, obj->ttm.created = true; /* i915 wants -ENXIO when out of memory region space. */ - return (ret == -ENOSPC) ? -ENXIO : ret; + return i915_ttm_err_to_gem(ret); } -- 2.31.1

2 2

[PATCH] drm/bridge: anx7625: Make hpd workqueue freezable
by Pi-Hsun Shih 18 Jun '21

18 Jun '21

There were still a race condition between hpd work and suspend, since the workqueue work can still be run after anx7625 had powered off in suspend. Since we never want hpd work to run while suspending, and there's no harm to delay them to be run after resume, mark the workqueue as WQ_FREEZABLE so all works won't run while suspending. Fixes: 409776fa3c42 ("drm/bridge: anx7625: add suspend / resume hooks") Signed-off-by: Pi-Hsun Shih <pihsun(a)chromium.org> --- drivers/gpu/drm/bridge/analogix/anx7625.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c b/drivers/gpu/drm/bridge/analogix/anx7625.c index 7519b7a0f29d..e165be5a2067 100644 --- a/drivers/gpu/drm/bridge/analogix/anx7625.c +++ b/drivers/gpu/drm/bridge/analogix/anx7625.c @@ -1730,7 +1730,6 @@ static int __maybe_unused anx7625_suspend(struct device *dev) if (!pm_runtime_enabled(dev) || !pm_runtime_suspended(dev)) { anx7625_runtime_pm_suspend(dev); disable_irq(ctx->pdata.intp_irq); - flush_workqueue(ctx->workqueue); } return 0; @@ -1790,7 +1789,8 @@ static int anx7625_i2c_probe(struct i2c_client *client, platform->pdata.intp_irq = client->irq; if (platform->pdata.intp_irq) { INIT_WORK(&platform->work, anx7625_work_func); - platform->workqueue = create_workqueue("anx7625_work"); + platform->workqueue = alloc_workqueue( + "anx7625_work", WQ_FREEZABLE | WQ_MEM_RECLAIM, 1); if (!platform->workqueue) { DRM_DEV_ERROR(dev, "fail to create work queue\n"); ret = -ENOMEM; base-commit: 25fe90f43fa312213b653dc1f12fd2d80f855883 -- 2.32.0.272.g935e593368-goog

3 2

[drm-intel:drm-intel-gt-next 2/8] drivers/gpu/drm/i915/selftests/i915_buddy.c:777:5: warning: no previous prototype for 'i915_buddy_mock_selftests'
by kernel test robot 18 Jun '21

18 Jun '21

tree: git://anongit.freedesktop.org/drm-intel drm-intel-gt-next head: 13c2ceb6addb6b14468e09b75832c98909eed8e7 commit: 88be9a0a06b73ecd85a688a7c174c941e9692e92 [2/8] drm/i915/ttm: add ttm_buddy_man config: x86_64-randconfig-a012-20210618 (attached as .config) compiler: gcc-9 (Debian 9.3.0-22) 9.3.0 reproduce (this is a W=1 build): git remote add drm-intel git://anongit.freedesktop.org/drm-intel git fetch --no-tags drm-intel drm-intel-gt-next git checkout 88be9a0a06b73ecd85a688a7c174c941e9692e92 # save the attached .config to linux build tree make W=1 ARCH=x86_64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot <lkp(a)intel.com> All warnings (new ones prefixed by >>): In file included from drivers/gpu/drm/i915/i915_buddy.c:411: >> drivers/gpu/drm/i915/selftests/i915_buddy.c:777:5: warning: no previous prototype for 'i915_buddy_mock_selftests' [-Wmissing-prototypes] 777 | int i915_buddy_mock_selftests(void) | ^~~~~~~~~~~~~~~~~~~~~~~~~ vim +/i915_buddy_mock_selftests +777 drivers/gpu/drm/i915/selftests/i915_buddy.c 776 > 777 int i915_buddy_mock_selftests(void) --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org

1 0

[v1 0/3] drm/msm/dsi: Add display DSI support for SC7280 target
by Rajeev Nandan 18 Jun '21

18 Jun '21

Changes in this series add support for MSM display DSI CTRL & PHY drivers for the SC7280 SoC, which has DSI controller v2.5.0 and DSI PHY v4.1. This series also updates the missing bindings (yaml) for the 7nm DSI PHY driver on "msm-next" branch. Rajeev Nandan (3): dt-bindings: msm/dsi: Add yaml schema for 7nm DSI PHY drm/msm/dsi: Add PHY configuration for SC7280 drm/msm/dsi: Add DSI support for SC7280 .../bindings/display/msm/dsi-phy-7nm.yaml | 68 ++++++++++++++++++++++ drivers/gpu/drm/msm/Kconfig | 6 +- drivers/gpu/drm/msm/dsi/dsi_cfg.c | 20 +++++++ drivers/gpu/drm/msm/dsi/dsi_cfg.h | 1 + drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 2 + drivers/gpu/drm/msm/dsi/phy/dsi_phy.h | 1 + drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c | 22 +++++++ 7 files changed, 117 insertions(+), 3 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/msm/dsi-phy-7nm.yaml -- 2.7.4

5 12

[PULL] drm-misc-next-fixes
by Thomas Zimmermann 18 Jun '21

18 Jun '21

Hi Dave and Daniel, here's the extra PR for drm-misc-next-fixes for this week. In addition to the previous fixes, it only contains the dp_mst build fix. Best regards Thomas drm-misc-next-fixes-2021-06-18: Short summary of fixes pull: * hyperv: advertise the correct formatmodifiers for its primary plane * dp_mst: VCPI fixes to make it work with StarTech hub; Fix build error The following changes since commit 1bd8a7dc28c1c410f1ceefae1f2a97c06d1a67c2: Merge tag 'exynos-drm-next-for-v5.14' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next (2021-06-11 14:19:12 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-fixes-2021-06-18 for you to fetch changes up to 24ff3dc18b99c4b912ab1746e803ddb3be5ced4c: drm/dp_mst: Add missing drm parameters to recently added call to drm_dbg_kms() (2021-06-16 15:53:15 -0400) ---------------------------------------------------------------- Short summary of fixes pull: * hyperv: advertise the correct formatmodifiers for its primary plane * dp_mst: VCPI fixes to make it work with StarTech hub; Fix build error ---------------------------------------------------------------- José Roberto de Souza (1): drm/dp_mst: Add missing drm parameters to recently added call to drm_dbg_kms() Pu Lehui (1): drm/hyperv: Fix unused const variable 'hyperv_modifiers' Wayne Lin (2): drm/dp_mst: Do not set proposed vcpi directly drm/dp_mst: Avoid to mess up payload table by ports in stale topology drivers/gpu/drm/drm_dp_mst_topology.c | 68 ++++++++++++++++++----------- drivers/gpu/drm/hyperv/hyperv_drm_modeset.c | 2 +- 2 files changed, 43 insertions(+), 27 deletions(-) -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer

1 0

[PULL] drm-misc-next-fixes
by Thomas Zimmermann 18 Jun '21

18 Jun '21

Hi Dave and Daniel, here's this week's PR for drm-misc-next-fixes. Best regards Thomas drm-misc-next-fixes-2021-06-16: Short summary of fixes pull: * hyperv: advertise the correct formatmodifiers for its primary plane * dp_mst: VCPI fixes to make it work with StarTech hub The following changes since commit 1bd8a7dc28c1c410f1ceefae1f2a97c06d1a67c2: Merge tag 'exynos-drm-next-for-v5.14' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next (2021-06-11 14:19:12 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-fixes-2021-06-16 for you to fetch changes up to 3769e4c0af5b82c8ea21d037013cb9564dfaa51f: drm/dp_mst: Avoid to mess up payload table by ports in stale topology (2021-06-16 12:57:46 -0400) ---------------------------------------------------------------- Short summary of fixes pull: * hyperv: advertise the correct formatmodifiers for its primary plane * dp_mst: VCPI fixes to make it work with StarTech hub ---------------------------------------------------------------- Pu Lehui (1): drm/hyperv: Fix unused const variable 'hyperv_modifiers' Wayne Lin (2): drm/dp_mst: Do not set proposed vcpi directly drm/dp_mst: Avoid to mess up payload table by ports in stale topology drivers/gpu/drm/drm_dp_mst_topology.c | 65 +++++++++++++++++------------ drivers/gpu/drm/hyperv/hyperv_drm_modeset.c | 2 +- 2 files changed, 40 insertions(+), 27 deletions(-) -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer

4 4

← Newer
1
...
38
39
40
41
42
43
44
...
88
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel June 2021