dri-devel April 2022

dri-devel@lists.freedesktop.org

351 participants
951 discussions

[PATCH 0/6] drm/vc4: Fixes for the writeback
by Maxime Ripard 08 Apr '22

08 Apr '22

Hi, This series address multiple issues with the transposer support, and thus the writeback support. Let me know what you think, Maxime Maxime Ripard (6): drm/vc4: hvs: Reset muxes at probe time drm/vc4: txp: Don't set TXP_VSTART_AT_EOF drm/vc4: txp: Force alpha to be 0xff if it's disabled drm/vc4: kms: Store channel in local variable drm/vc4: kms: Warn if we have an incompatible muxing setup drm/vc4: kms: Improve logging drivers/gpu/drm/vc4/vc4_hvs.c | 26 +++++++++++++++++++----- drivers/gpu/drm/vc4/vc4_kms.c | 38 +++++++++++++++++++++++++++-------- drivers/gpu/drm/vc4/vc4_txp.c | 4 +++- 3 files changed, 54 insertions(+), 14 deletions(-) -- 2.35.1

2 11

[PATCH v2] drm/i915: fix i915_gem_object_wait_moving_fence
by Matthew Auld 08 Apr '22

08 Apr '22

All of CI is just failing with the following, which prevents loading of the module: i915 0000:03:00.0: [drm] *ERROR* Scratch setup failed Best guess is that this comes from the pin_map() for the scratch page, which does an i915_gem_object_wait_moving_fence() somewhere. It looks like this now calls into dma_resv_wait_timeout() which can return the remaining timeout, leading to the caller thinking this is an error. v2(Lucas): handle ret == 0 Fixes: 1d7f5e6c5240 ("drm/i915: drop bo->moving dependency") Signed-off-by: Matthew Auld <matthew.auld(a)intel.com> Cc: Christian König <christian.koenig(a)amd.com> Cc: Lucas De Marchi <lucas.demarchi(a)intel.com> Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch> Reviewed-by: Christian König <christian.koenig(a)amd.com> #v1 --- drivers/gpu/drm/i915/gem/i915_gem_object.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c b/drivers/gpu/drm/i915/gem/i915_gem_object.c index 2998d895a6b3..747ac65e060f 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c @@ -772,9 +772,16 @@ int i915_gem_object_get_moving_fence(struct drm_i915_gem_object *obj, int i915_gem_object_wait_moving_fence(struct drm_i915_gem_object *obj, bool intr) { + long ret; + assert_object_held(obj); - return dma_resv_wait_timeout(obj->base. resv, DMA_RESV_USAGE_KERNEL, - intr, MAX_SCHEDULE_TIMEOUT); + + ret = dma_resv_wait_timeout(obj->base. resv, DMA_RESV_USAGE_KERNEL, + intr, MAX_SCHEDULE_TIMEOUT); + if (!ret) + ret = -ETIME; + + return ret < 0 ? ret : 0; } #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST) -- 2.34.1

3 4

Re: [Intel-gfx] [PATCH] drm/i915/display/debugfs: Add connector debugfs for "output_bpc"
by Jani Nikula 08 Apr '22

08 Apr '22

On Mon, 04 Apr 2022, "Modem, Bhanuprakash" <bhanuprakash.modem(a)intel.com> wrote: > On Fri-01-04-2022 06:10 pm, Jani Nikula wrote: >> On Tue, 29 Mar 2022, Bhanuprakash Modem <bhanuprakash.modem(a)intel.com> wrote: >>> This new debugfs will expose the connector's max supported bpc >>> and the bpc currently using. It is very useful for verifying >>> whether we enter the correct output color depth from IGT. >>> >>> Example: >>> cat /sys/kernel/debug/dri/0/DP-1/output_bpc >>> Current: 8 >>> Maximum: 10 >>> >>> V2: Add connector's max bpc to i915_display_info >>> >>> Cc: Ville Syrjälä <ville.syrjala(a)linux.intel.com> >>> Cc: Uma Shankar <uma.shankar(a)intel.com> >>> Cc: Swati Sharma <swati2.sharma(a)intel.com> >>> Signed-off-by: Bhanuprakash Modem <bhanuprakash.modem(a)intel.com> >>> --- >>> .../drm/i915/display/intel_display_debugfs.c | 46 +++++++++++++++++++ >>> 1 file changed, 46 insertions(+) >>> >>> diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c b/drivers/gpu/drm/i915/display/intel_display_debugfs.c >>> index c1e74a13a0828..694d27f3b109c 100644 >>> --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c >>> +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c >>> @@ -663,6 +663,8 @@ static void intel_connector_info(struct seq_file *m, >>> seq_puts(m, "\tHDCP version: "); >>> intel_hdcp_info(m, intel_connector); >>> >>> + seq_printf(m, "\tmax bpc: %u\n", connector->display_info.bpc); >>> + >>> intel_panel_info(m, intel_connector); >>> >>> seq_printf(m, "\tmodes:\n"); >>> @@ -2275,6 +2277,47 @@ static const struct file_operations i915_dsc_bpp_fops = { >>> .write = i915_dsc_bpp_write >>> }; >>> >>> +/* >>> + * Returns the maximum output bpc for the connector. >>> + * Example usage: cat /sys/kernel/debug/dri/0/DP-1/output_bpc >>> + */ >>> +static int output_bpc_show(struct seq_file *m, void *data) >>> +{ >>> + struct drm_connector *connector = m->private; >>> + struct drm_device *dev = connector->dev; >>> + struct drm_crtc *crtc; >>> + struct intel_crtc_state *crtc_state; >>> + struct intel_encoder *encoder = intel_attached_encoder(to_intel_connector(connector)); >>> + int res; >>> + >>> + if (!encoder) >>> + return -ENODEV; >>> + >>> + res = drm_modeset_lock_single_interruptible(&dev->mode_config.connection_mutex); >>> + if (res) >>> + return res; >>> + >>> + crtc = connector->state->crtc; >>> + if (connector->status != connector_status_connected || !crtc) { >>> + res = -ENODEV; >>> + goto unlock; >>> + } >>> + >>> + crtc_state = to_intel_crtc_state(crtc->state); >>> + if (!crtc_state->hw.active) >>> + goto unlock; >>> + >>> + seq_printf(m, "Current: %u\n", crtc_state->pipe_bpp / 3); >>> + seq_printf(m, "Maximum: %u\n", connector->display_info.bpc); >>> + res = 0; >>> + >>> +unlock: >>> + drm_modeset_unlock(&dev->mode_config.connection_mutex); >>> + >>> + return res; >>> +} >>> +DEFINE_SHOW_ATTRIBUTE(output_bpc); >> >> Looks like an excessive amount of code for a single value. > > Yeah, but these values are very helpful in many IGT tests like > kms_color, kms_hdr, kms_dither, kms_dsc etc.. > > Otherwise IGT needs to request the kernel to get the EDID, and parse > that EDID to get the "Maximum" value which is redundant (Kernel is > already doing the same) and not recommended in IGT. > > And there is no way to get the "Current" value except reading it from > i915_display_info which is again not recommended in IGT (As > i915_display_info is Intel specific). Note how we have intel_connector_debugfs_add() for connector debugfs and intel_crtc_debugfs_add() for crtc debugfs, and how this patch just mixes up the two by looking up crtc and state from the connector debugfs. > This debugfs is already introduced & using by AMD: > https://patchwork.freedesktop.org/patch/308586 Wait, what? Both amd and i915 adding the name "output_bpc" is *not* the way to roll. We only add i915_ prefixed debugfs files from i915.ko. If you need this to be a standard interface across drivers, IMO it should be added in common drm code, not sprinkled around in drivers. I see that amd is already using this in what is basically drm core debugfs namespace, and there's amd specific IGT built on top. Adding a bunch of Cc's to get some clarity on drm debugfs naming and usage. BR, Jani. > > - Bhanu > >> >> BR, >> Jani. >> >>> + >>> /** >>> * intel_connector_debugfs_add - add i915 specific connector debugfs files >>> * @connector: pointer to a registered drm_connector >>> @@ -2330,6 +2373,9 @@ void intel_connector_debugfs_add(struct intel_connector *intel_connector) >>> connector->connector_type == DRM_MODE_CONNECTOR_HDMIB) >>> debugfs_create_file("i915_lpsp_capability", 0444, root, >>> connector, &i915_lpsp_capability_fops); >>> + >>> + debugfs_create_file("output_bpc", 0444, root, >>> + connector, &output_bpc_fops); >>> } >>> >>> /** >> > -- Jani Nikula, Intel Open Source Graphics Center

3 3

[PATCH] drivers: Fix spelling mistake "writting" -> "writing"
by cgel.zte＠gmail.com 08 Apr '22

08 Apr '22

From: Lv Ruyi <lv.ruyi(a)zte.com.cn> There are some spelling mistakes in the comments. Fix it. Reported-by: Zeal Robot <zealci(a)zte.com.cn> Signed-off-by: Lv Ruyi <lv.ruyi(a)zte.com.cn> --- drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 2 +- drivers/gpu/drm/i915/i915_request.c | 2 +- drivers/net/ethernet/sfc/mcdi_pcol.h | 4 ++-- drivers/net/ethernet/toshiba/tc35815.c | 2 +- drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c | 4 ++-- drivers/platform/x86/hp_accel.c | 2 +- drivers/rtc/rtc-sa1100.c | 2 +- drivers/scsi/pmcraid.c | 4 ++-- 8 files changed, 11 insertions(+), 11 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c index 9426e252d8aa..ce361fce7155 100644 --- a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c @@ -7304,7 +7304,7 @@ static void gfx_v10_0_setup_grbm_cam_remapping(struct amdgpu_device *adev) return; /* initialize cam_index to 0 - * index will auto-inc after each data writting */ + * index will auto-inc after each data writing */ WREG32_SOC15(GC, 0, mmGRBM_CAM_INDEX, 0); switch (adev->ip_versions[GC_HWIP][0]) { diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c index 582770360ad1..cf79a25cd98a 100644 --- a/drivers/gpu/drm/i915/i915_request.c +++ b/drivers/gpu/drm/i915/i915_request.c @@ -451,7 +451,7 @@ static bool __request_in_flight(const struct i915_request *signal) * to avoid tearing.] * * Note that the read of *execlists->active may race with the promotion - * of execlists->pending[] to execlists->inflight[], overwritting + * of execlists->pending[] to execlists->inflight[], overwriting * the value at *execlists->active. This is fine. The promotion implies * that we received an ACK from the HW, and so the context is not * stuck -- if we do not see ourselves in *active, the inflight status diff --git a/drivers/net/ethernet/sfc/mcdi_pcol.h b/drivers/net/ethernet/sfc/mcdi_pcol.h index d3fcbf930dba..ff617b1b38d3 100644 --- a/drivers/net/ethernet/sfc/mcdi_pcol.h +++ b/drivers/net/ethernet/sfc/mcdi_pcol.h @@ -73,8 +73,8 @@ * \------------------------------ Resync (always set) * * The client writes it's request into MC shared memory, and rings the - * doorbell. Each request is completed by either by the MC writting - * back into shared memory, or by writting out an event. + * doorbell. Each request is completed by either by the MC writing + * back into shared memory, or by writing out an event. * * All MCDI commands support completion by shared memory response. Each * request may also contain additional data (accounted for by HEADER.LEN), diff --git a/drivers/net/ethernet/toshiba/tc35815.c b/drivers/net/ethernet/toshiba/tc35815.c index ce38f7515225..1b4c207afb66 100644 --- a/drivers/net/ethernet/toshiba/tc35815.c +++ b/drivers/net/ethernet/toshiba/tc35815.c @@ -157,7 +157,7 @@ struct tc35815_regs { #define PROM_Read 0x00004000 /*10:Read operation */ #define PROM_Write 0x00002000 /*01:Write operation */ #define PROM_Erase 0x00006000 /*11:Erase operation */ - /*00:Enable or Disable Writting, */ + /*00:Enable or Disable Writing, */ /* as specified in PROM_Addr. */ #define PROM_Addr_Ena 0x00000030 /*11xxxx:PROM Write enable */ /*00xxxx: disable */ diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c b/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c index eaba66113328..fbb4941d0da8 100644 --- a/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c +++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c @@ -520,7 +520,7 @@ static void _rtl92cu_init_queue_reserved_page(struct ieee80211_hw *hw, * 2 out-ep. Remainder pages have assigned to High queue */ if (outepnum > 1 && txqremaininpage) numhq += txqremaininpage; - /* NOTE: This step done before writting REG_RQPN. */ + /* NOTE: This step done before writing REG_RQPN. */ if (ischipn) { if (queue_sel & TX_SELE_NQ) numnq = txqpageunit; @@ -539,7 +539,7 @@ static void _rtl92cu_init_queue_reserved_page(struct ieee80211_hw *hw, numlq = ischipn ? WMM_CHIP_B_PAGE_NUM_LPQ : WMM_CHIP_A_PAGE_NUM_LPQ; } - /* NOTE: This step done before writting REG_RQPN. */ + /* NOTE: This step done before writing REG_RQPN. */ if (ischipn) { if (queue_sel & TX_SELE_NQ) numnq = WMM_CHIP_B_PAGE_NUM_NPQ; diff --git a/drivers/platform/x86/hp_accel.c b/drivers/platform/x86/hp_accel.c index e9f852f7c27f..b59b852a666f 100644 --- a/drivers/platform/x86/hp_accel.c +++ b/drivers/platform/x86/hp_accel.c @@ -122,7 +122,7 @@ static int lis3lv02d_acpi_read(struct lis3lv02d *lis3, int reg, u8 *ret) static int lis3lv02d_acpi_write(struct lis3lv02d *lis3, int reg, u8 val) { struct acpi_device *dev = lis3->bus_priv; - unsigned long long ret; /* Not used when writting */ + unsigned long long ret; /* Not used when writing */ union acpi_object in_obj[2]; struct acpi_object_list args = { 2, in_obj }; diff --git a/drivers/rtc/rtc-sa1100.c b/drivers/rtc/rtc-sa1100.c index 1250887e4382..a52a333de8e8 100644 --- a/drivers/rtc/rtc-sa1100.c +++ b/drivers/rtc/rtc-sa1100.c @@ -231,7 +231,7 @@ int sa1100_rtc_init(struct platform_device *pdev, struct sa1100_rtc *info) * initialization is unknown and could in principle happen during * normal processing. * - * Notice that clearing bit 1 and 0 is accomplished by writting ONES to + * Notice that clearing bit 1 and 0 is accomplished by writing ONES to * the corresponding bits in RTSR. */ writel_relaxed(RTSR_AL | RTSR_HZ, info->rtsr); diff --git a/drivers/scsi/pmcraid.c b/drivers/scsi/pmcraid.c index fd674ed1febe..d7f4680f6106 100644 --- a/drivers/scsi/pmcraid.c +++ b/drivers/scsi/pmcraid.c @@ -857,7 +857,7 @@ static void _pmcraid_fire_command(struct pmcraid_cmd *cmd) unsigned long lock_flags; /* Add this command block to pending cmd pool. We do this prior to - * writting IOARCB to ioarrin because IOA might complete the command + * writing IOARCB to ioarrin because IOA might complete the command * by the time we are about to add it to the list. Response handler * (isr/tasklet) looks for cmd block in the pending pending list. */ @@ -2450,7 +2450,7 @@ static void pmcraid_request_sense(struct pmcraid_cmd *cmd) /* request sense might be called as part of error response processing * which runs in tasklets context. It is possible that mid-layer might - * schedule queuecommand during this time, hence, writting to IOARRIN + * schedule queuecommand during this time, hence, writing to IOARRIN * must be protect by host_lock */ pmcraid_send_cmd(cmd, pmcraid_erp_done, -- 2.25.1

2 1

[PATCH] drm/bridge: anx7625: remove unnecessary flush_workqueue()
by cgel.zte＠gmail.com 08 Apr '22

08 Apr '22

From: Lv Ruyi <lv.ruyi(a)zte.com.cn> All work currently pending will be done by calling destroy_workqueue, so there is unnecessary to flush it explicitly. Reported-by: Zeal Robot <zealci(a)zte.com.cn> Signed-off-by: Lv Ruyi <lv.ruyi(a)zte.com.cn> --- drivers/gpu/drm/bridge/analogix/anx7625.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c b/drivers/gpu/drm/bridge/analogix/anx7625.c index 6516f9570b86..65632f584179 100644 --- a/drivers/gpu/drm/bridge/analogix/anx7625.c +++ b/drivers/gpu/drm/bridge/analogix/anx7625.c @@ -2744,7 +2744,6 @@ static int anx7625_i2c_remove(struct i2c_client *client) if (platform->hdcp_workqueue) { cancel_delayed_work(&platform->hdcp_work); - flush_workqueue(platform->hdcp_workqueue); destroy_workqueue(platform->hdcp_workqueue); } -- 2.25.1

1 0

[PATCH 0/1] Use platform specific defaults for GuC/HuC enabling
by Matthew Brost 08 Apr '22

08 Apr '22

Reviewed a long time ago, resending for CI + to dri-devel. John Harrison (1): drm/i915/uc: Use platform specific defaults for GuC/HuC enabling drivers/gpu/drm/i915/i915_params.c | 2 +- drivers/gpu/drm/i915/i915_params.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) -- 2.28.0

4 5

[PATCH 1/2] drm/i915: fix broken build
by Matthew Auld 08 Apr '22

08 Apr '22

I guess this was missed in the conversion or something. Fixes: 7bc80a5462c3 ("dma-buf: add enum dma_resv_usage v4") Signed-off-by: Matthew Auld <matthew.auld(a)intel.com> Cc: Christian König <christian.koenig(a)amd.com> Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch> --- drivers/gpu/drm/i915/i915_deps.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_deps.c b/drivers/gpu/drm/i915/i915_deps.c index 999210b37325..297b8e4e42ee 100644 --- a/drivers/gpu/drm/i915/i915_deps.c +++ b/drivers/gpu/drm/i915/i915_deps.c @@ -226,7 +226,7 @@ int i915_deps_add_resv(struct i915_deps *deps, struct dma_resv *resv, struct dma_fence *fence; dma_resv_assert_held(resv); - dma_resv_for_each_fence(&iter, resv, true, fence) { + dma_resv_for_each_fence(&iter, resv, dma_resv_usage_rw(true), fence) { int ret = i915_deps_add_dependency(deps, fence, ctx); if (ret) -- 2.34.1

4 12

[PATCH 1/2] drm/dp: Export drm_dp_dpcd_access()
by Imre Deak 08 Apr '22

08 Apr '22

The next patch needs a way to read a DPCD register without the preceding wake-up read in drm_dp_dpcd_read(). Export drm_dp_dpcd_access() to allow this. Cc: dri-devel(a)lists.freedesktop.org Signed-off-by: Imre Deak <imre.deak(a)intel.com> --- drivers/gpu/drm/dp/drm_dp.c | 19 +++++++++++++++++-- include/drm/dp/drm_dp_helper.h | 2 ++ 2 files changed, 19 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/dp/drm_dp.c b/drivers/gpu/drm/dp/drm_dp.c index 580016a1b9eb7..8b181314edcbe 100644 --- a/drivers/gpu/drm/dp/drm_dp.c +++ b/drivers/gpu/drm/dp/drm_dp.c @@ -470,8 +470,22 @@ drm_dp_dump_access(const struct drm_dp_aux *aux, * Both native and I2C-over-AUX transactions are supported. */ -static int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8 request, - unsigned int offset, void *buffer, size_t size) +/** + * drm_dp_dpcd_access() - read or write a series of bytes from/to the DPCD + * @aux: DisplayPort AUX channel (SST) + * @request: DP_AUX_NATIVE_READ or DP_AUX_NATIVE_WRITE + * @offset: address of the (first) register to read or write + * @buffer: buffer with the register values to write or the register values read + * @size: number of bytes in @buffer + * + * Returns the number of bytes transferred on success, or a negative error + * code on failure. This is a low-level function only for SST sinks and cases + * where calling drm_dp_dpcd_read()/write() is not possible (for instance due + * to the wake-up register read in drm_dp_dpcd_read()). For all other cases + * the latter functions should be used. + */ +int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8 request, + unsigned int offset, void *buffer, size_t size) { struct drm_dp_aux_msg msg; unsigned int retry, native_reply; @@ -526,6 +540,7 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8 request, mutex_unlock(&aux->hw_mutex); return ret; } +EXPORT_SYMBOL(drm_dp_dpcd_access); /** * drm_dp_dpcd_read() - read a series of bytes from the DPCD diff --git a/include/drm/dp/drm_dp_helper.h b/include/drm/dp/drm_dp_helper.h index 1eccd97419436..7cf6e83434a8c 100644 --- a/include/drm/dp/drm_dp_helper.h +++ b/include/drm/dp/drm_dp_helper.h @@ -2053,6 +2053,8 @@ struct drm_dp_aux { bool is_remote; }; +int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8 request, + unsigned int offset, void *buffer, size_t size); ssize_t drm_dp_dpcd_read(struct drm_dp_aux *aux, unsigned int offset, void *buffer, size_t size); ssize_t drm_dp_dpcd_write(struct drm_dp_aux *aux, unsigned int offset, -- 2.30.2

2 2

[PATCH v9 0/9] drm/i915/ttm: Evict and restore of compressed object
by Ramalingam C 08 Apr '22

08 Apr '22

On Xe-HP and later devices, we use dedicated compression control state (CCS) stored in local memory for each surface, to support the 3D and media compression formats. The memory required for the CCS of the entire local memory is 1/256 of the local memory size. So before the kernel boot, the required memory is reserved for the CCS data and a secure register will be programmed with the CCS base address So when we allocate a object in local memory we dont need to explicitly allocate the space for ccs data. But when we evict the obj into the smem to hold the compression related data along with the obj we need smem space of obj_size + (obj_size/256). Hence when we create smem for an obj with lmem placement possibility we create with the extra space. When we are swapping out the local memory obj on flat-ccs capable platform, we need to capture the ccs data too along with main meory and we need to restore it when we are swapping in the content. When lmem object is swapped into a smem obj, smem obj will have the extra pages required to hold the ccs data corresponding to the lmem main memory. So main memory of lmem will be copied into the initial pages of the smem and then ccs data corresponding to the main memory will be copied to the subsequent pages of smem. Swapin happens exactly in reverse order. First main memory of lmem is restored from the smem's initial pages and the ccs data will be restored from the subsequent pages of smem. Extracting and restoring the CCS data is done through a special cmd called XY_CTRL_SURF_COPY_BLT v8 and v9: New patch for return value fix Fix a return error code Test-with: 20220405141050.16037-1-ramalingam.c(a)intel.com Ramalingam C (9): drm/i915/gt: use engine instance directly for offset drm/i915/gt: Use XY_FAST_COLOR_BLT to clear obj on graphics ver 12+ drm/i915/gt: Optimize the migration and clear loop drm/i915/gt: Pass the -EINVAL when emit_pte doesn't update any PTE drm/i915/gt: Clear compress metadata for Flat-ccs objects drm/i915/selftest_migrate: Consider the possible roundup of size drm/i915/selftest_migrate: Check CCS meta data clear drm/i915/gem: Add extra pages in ttm_tt for ccs data drm/i915/migrate: Evict and restore the flatccs capable lmem obj drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 30 +- drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 21 + drivers/gpu/drm/i915/gt/intel_migrate.c | 387 +++++++++++++++++-- drivers/gpu/drm/i915/gt/selftest_migrate.c | 253 ++++++++++-- 4 files changed, 631 insertions(+), 60 deletions(-) -- 2.20.1

2 10

[PATCH 0/5] drm/ttm: Introduce TTM res manager debugfs helpers
by Zack Rusin 08 Apr '22

08 Apr '22

From: Zack Rusin <zackr(a)vmware.com> This series introduces generic TTM resource manager debugfs helpers and refactors TTM drivers which have been using hand rolled out versions of those to use the new code. Because those entries are managed by TTM the location of them moves to /sys/kernel/debug/ttm/. If there are any scripts which depend on the old locations we can certainly add a new root dentry to ttm_resource_manager_debugfs_init to preserve the old locations. Zack Rusin (5): drm/ttm: Add common debugfs code for resource managers drm/vmwgfx: Add debugfs entries for various ttm resource managers drm/amdgpu: Use TTM builtin resource manager debugfs code drm/qxl: Use TTM builtin resource manager debugfs code drm/radeon: Use TTM builtin resource manager debugfs code drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 81 ++++--------------------- drivers/gpu/drm/qxl/qxl_ttm.c | 40 +++--------- drivers/gpu/drm/radeon/radeon_ttm.c | 37 +++-------- drivers/gpu/drm/ttm/ttm_resource.c | 65 ++++++++++++++++++++ drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 10 +++ include/drm/ttm/ttm_resource.h | 4 ++ 6 files changed, 104 insertions(+), 133 deletions(-) -- 2.32.0

4 9

← Newer
1
...
72
73
74
75
76
77
78
...
96
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel April 2022