[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915/display: fix level 0 adjustement on display ver >= 12 (rev2)
== Series Details ==
Series: series starting with [1/2] drm/i915/display: fix level 0 adjustement on
display ver >= 12 (rev2)
URL : https://patchwork.freedesktop.org/series/91791/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10277_full -> Patchwork_20460_full
Summary
---
**WARNING**
Minor unknown changes coming with Patchwork_20460_full need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_20460_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_20460_full:
### IGT changes ###
Warnings
* igt@kms_psr2_sf@overlay-primary-update-sf-dmg-area-3:
- shard-iclb: [SKIP][1] ([i915#658]) -> [SKIP][2] +4 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10277/shard-iclb7/igt@kms_psr2...@overlay-primary-update-sf-dmg-area-3.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20460/shard-iclb2/igt@kms_psr2...@overlay-primary-update-sf-dmg-area-3.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@kms_ccs@pipe-d-bad-aux-stride-y_tiled_gen12_mc_ccs}:
- shard-tglb: NOTRUN -> [SKIP][3] +2 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20460/shard-tglb3/igt@kms_ccs@pipe-d-bad-aux-stride-y_tiled_gen12_mc_ccs.html
Known issues
Here are the changes found in Patchwork_20460_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_persistence@legacy-engines-mixed-process:
- shard-snb: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#1099]) +4
similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20460/shard-snb7/igt@gem_ctx_persiste...@legacy-engines-mixed-process.html
* igt@gem_ctx_shared@q-in-order:
- shard-snb: NOTRUN -> [SKIP][5] ([fdo#109271]) +249 similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20460/shard-snb7/igt@gem_ctx_sha...@q-in-order.html
* igt@gem_eio@unwedge-stress:
- shard-iclb: [PASS][6] -> [TIMEOUT][7] ([i915#2369] / [i915#2481]
/ [i915#3070])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10277/shard-iclb2/igt@gem_...@unwedge-stress.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20460/shard-iclb3/igt@gem_...@unwedge-stress.html
* igt@gem_exec_fair@basic-flow@rcs0:
- shard-tglb: [PASS][8] -> [FAIL][9] ([i915#2842]) +1 similar issue
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10277/shard-tglb5/igt@gem_exec_fair@basic-f...@rcs0.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20460/shard-tglb5/igt@gem_exec_fair@basic-f...@rcs0.html
* igt@gem_exec_fair@basic-none-solo@rcs0:
- shard-kbl: NOTRUN -> [FAIL][10] ([i915#2842])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20460/shard-kbl1/igt@gem_exec_fair@basic-none-s...@rcs0.html
* igt@gem_exec_fair@basic-none@vcs0:
- shard-kbl: [PASS][11] -> [FAIL][12] ([i915#2842]) +1 similar
issue
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10277/shard-kbl2/igt@gem_exec_fair@basic-n...@vcs0.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20460/shard-kbl2/igt@gem_exec_fair@basic-n...@vcs0.html
* igt@gem_exec_fair@basic-none@vcs1:
- shard-iclb: NOTRUN -> [FAIL][13] ([i915#2842])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20460/shard-iclb1/igt@gem_exec_fair@basic-n...@vcs1.html
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-glk: [PASS][14] -> [FAIL][15] ([i915#2842]) +2 similar
issues
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10277/shard-glk8/igt@gem_exec_fair@basic-pace-s...@rcs0.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20460/shard-glk1/igt@gem_exec_fair@basic-pace-s...@rcs0.html
* igt@gem_exec_reloc@basic-wide-active@vcs1:
- shard-iclb: NOTRUN -> [FAIL][16] ([i915#3633])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20460/shard-iclb1/igt@gem_exec_reloc@basic-wide-act...@vcs1.html
* igt@gem_exec_whisper@basic-contexts:
- shard-glk: [PASS][17] -> [DMESG-WARN][18] ([i915#118] /
[i915#95])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10277/shard-glk1/igt@gem_exec_whis...@basic-contexts.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20460/shard-glk2/igt@gem_exec_whis...@basic-contexts.html
* igt@gem_mmap_gtt@big-copy:
- shard-glk: [PASS][19] -> [FAIL][20] ([i915#307])
[19]:
Re: [Intel-gfx] [PATCH 44/47] drm/i915/guc: Connect reset modparam updates to GuC policy flags
On Thu, Jun 24, 2021 at 12:05:13AM -0700, Matthew Brost wrote:
> From: John Harrison
>
> Changing the reset module parameter has no effect on a running GuC.
> The corresponding entry in the ADS must be updated and then the GuC
> informed via a Host2GuC message.
>
> The new debugfs interface to module parameters allows this to happen.
> However, connecting the parameter data address back to anything useful
> is messy. One option would be to pass a new private data structure
> address through instead of just the parameter pointer. However, that
> means having a new (and different) data structure for each parameter
> and a new (and different) write function for each parameter. This
> method keeps everything generic by instead using a string lookup on
> the directory entry name.
>
> Signed-off-by: John Harrison
> Signed-off-by: Matthew Brost
> ---
> drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 2 +-
> drivers/gpu/drm/i915/i915_debugfs_params.c | 31 ++
> 2 files changed, 32 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> index 2ad5fcd4e1b7..c6d0b762d82c 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> @@ -99,7 +99,7 @@ static int guc_action_policies_update(struct intel_guc
> *guc, u32 policy_offset)
> policy_offset
> };
>
> - return intel_guc_send(guc, action, ARRAY_SIZE(action));
> + return intel_guc_send_busy_loop(guc, action, ARRAY_SIZE(action), 0,
> true);
> }
>
> int intel_guc_global_policies_update(struct intel_guc *guc)
> diff --git a/drivers/gpu/drm/i915/i915_debugfs_params.c
> b/drivers/gpu/drm/i915/i915_debugfs_params.c
> index 4e2b077692cb..8ecd8b42f048 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs_params.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs_params.c
> @@ -6,9 +6,20 @@
> #include
>
> #include "i915_debugfs_params.h"
> +#include "gt/intel_gt.h"
> +#include "gt/uc/intel_guc.h"
> #include "i915_drv.h"
> #include "i915_params.h"
>
> +#define MATCH_DEBUGFS_NODE_NAME(_file, _name)
> (strcmp((_file)->f_path.dentry->d_name.name, (_name)) == 0)
> +
> +#define GET_I915(i915, name, ptr)\
> + do {\
> + struct i915_params *params; \
> + params = container_of(((void *) (ptr)), typeof(*params), name);
> \
> + (i915) = container_of(params, typeof(*(i915)), params); \
> + } while(0)
> +
> /* int param */
> static int i915_param_int_show(struct seq_file *m, void *data)
> {
> @@ -24,6 +35,16 @@ static int i915_param_int_open(struct inode *inode, struct
> file *file)
> return single_open(file, i915_param_int_show, inode->i_private);
> }
>
> +static int notify_guc(struct drm_i915_private *i915)
> +{
> + int ret = 0;
> +
> + if (intel_uc_uses_guc_submission(>gt.uc))
> + ret = intel_guc_global_policies_update(>gt.uc.guc);
> +
> + return ret;
> +}
> +
> static ssize_t i915_param_int_write(struct file *file,
> const char __user *ubuf, size_t len,
> loff_t *offp)
> @@ -81,8 +102,10 @@ static ssize_t i915_param_uint_write(struct file *file,
>const char __user *ubuf, size_t len,
>loff_t *offp)
> {
> + struct drm_i915_private *i915;
> struct seq_file *m = file->private_data;
> unsigned int *value = m->private;
> + unsigned int old = *value;
> int ret;
>
> ret = kstrtouint_from_user(ubuf, len, 0, value);
> @@ -95,6 +118,14 @@ static ssize_t i915_param_uint_write(struct file *file,
> *value = b;
> }
>
> + if (!ret && MATCH_DEBUGFS_NODE_NAME(file, "reset")) {
> + GET_I915(i915, reset, value);
We might want to make this into a macro in case we need to update more
than just "reset" with the GuC going forward but that is not a blocker.
With that:
Reviewed-by: Matthew Brost
> +
> + ret = notify_guc(i915);
> + if (ret)
> + *value = old;
> + }
> +
> return ret ?: len;
> }
>
> --
> 2.28.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 43/47] drm/i915/guc: Hook GuC scheduling policies up
On Thu, Jun 24, 2021 at 12:05:12AM -0700, Matthew Brost wrote:
> From: John Harrison
>
> Use the official driver default scheduling policies for configuring
> the GuC scheduler rather than a bunch of hardcoded values.
>
> Signed-off-by: John Harrison
> Signed-off-by: Matthew Brost
> Cc: Jose Souza
> ---
> drivers/gpu/drm/i915/gt/intel_engine_types.h | 1 +
> drivers/gpu/drm/i915/gt/uc/intel_guc.h| 2 +
> drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c| 44 ++-
> .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 11 +++--
> 4 files changed, 53 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
> b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> index 0ceffa2be7a7..37db857bb56c 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> @@ -455,6 +455,7 @@ struct intel_engine_cs {
> #define I915_ENGINE_IS_VIRTUAL BIT(5)
> #define I915_ENGINE_HAS_RELATIVE_MMIO BIT(6)
> #define I915_ENGINE_REQUIRES_CMD_PARSER BIT(7)
> +#define I915_ENGINE_WANT_FORCED_PREEMPTION BIT(8)
> unsigned int flags;
>
> /*
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> index c38365cd5fab..905ecbc7dbe3 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> @@ -270,6 +270,8 @@ int intel_guc_engine_failure_process_msg(struct intel_guc
> *guc,
>
> void intel_guc_find_hung_context(struct intel_engine_cs *engine);
>
> +int intel_guc_global_policies_update(struct intel_guc *guc);
> +
> void intel_guc_submission_reset_prepare(struct intel_guc *guc);
> void intel_guc_submission_reset(struct intel_guc *guc, bool stalled);
> void intel_guc_submission_reset_finish(struct intel_guc *guc);
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> index d3e86ab7508f..2ad5fcd4e1b7 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> @@ -77,14 +77,54 @@ static u32 guc_ads_blob_size(struct intel_guc *guc)
> guc_ads_private_data_size(guc);
> }
>
> -static void guc_policies_init(struct guc_policies *policies)
> +static void guc_policies_init(struct intel_guc *guc, struct guc_policies
> *policies)
> {
> + struct intel_gt *gt = guc_to_gt(guc);
> + struct drm_i915_private *i915 = gt->i915;
> +
> policies->dpc_promote_time = GLOBAL_POLICY_DEFAULT_DPC_PROMOTE_TIME_US;
> policies->max_num_work_items = GLOBAL_POLICY_MAX_NUM_WI;
> +
> policies->global_flags = 0;
> + if (i915->params.reset < 2)
> + policies->global_flags |= GLOBAL_POLICY_DISABLE_ENGINE_RESET;
> +
> policies->is_valid = 1;
> }
>
> +static int guc_action_policies_update(struct intel_guc *guc, u32
> policy_offset)
> +{
> + u32 action[] = {
> + INTEL_GUC_ACTION_GLOBAL_SCHED_POLICY_CHANGE,
> + policy_offset
> + };
> +
> + return intel_guc_send(guc, action, ARRAY_SIZE(action));
> +}
> +
> +int intel_guc_global_policies_update(struct intel_guc *guc)
> +{
> + struct __guc_ads_blob *blob = guc->ads_blob;
> + struct intel_gt *gt = guc_to_gt(guc);
> + intel_wakeref_t wakeref;
> + int ret;
> +
> + if (!blob)
> + return -ENOTSUPP;
> +
> + GEM_BUG_ON(!blob->ads.scheduler_policies);
> +
> + guc_policies_init(guc, >policies);
> +
> + if (!intel_guc_is_ready(guc))
> + return 0;
> +
> + with_intel_runtime_pm(>i915->runtime_pm, wakeref)
> + ret = guc_action_policies_update(guc,
> blob->ads.scheduler_policies);
> +
> + return ret;
> +}
> +
> static void guc_mapping_table_init(struct intel_gt *gt,
> struct guc_gt_system_info *system_info)
> {
> @@ -281,7 +321,7 @@ static void __guc_ads_init(struct intel_guc *guc)
> u8 engine_class, guc_class;
>
> /* GuC scheduling policies */
> - guc_policies_init(>policies);
> + guc_policies_init(guc, >policies);
>
> /*
>* GuC expects a per-engine-class context image and size
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> index 6188189314d5..a427336ce916 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> @@ -873,6 +873,7 @@ void intel_guc_submission_reset_finish(struct intel_guc
> *guc)
> GEM_WARN_ON(atomic_read(>outstanding_submission_g2h));
> atomic_set(>outstanding_submission_g2h, 0);
>
> + intel_guc_global_policies_update(guc);
> enable_submission(guc);
> intel_gt_unpark_heartbeats(guc_to_gt(guc));
> }
> @@ -1161,8 +1162,12 @@ static void guc_context_policy_init(struct
> intel_engine_cs *engine,
> {
> desc->policy_flags = 0;
>
> - desc->execution_quantum =
Re: [Intel-gfx] [PATCH v15 00/12] Restricted DMA
On Fri, Jun 25, 2021 at 3:20 AM Konrad Rzeszutek Wilk wrote: > > On Thu, Jun 24, 2021 at 11:55:14PM +0800, Claire Chang wrote: > > This series implements mitigations for lack of DMA access control on > > systems without an IOMMU, which could result in the DMA accessing the > > system memory at unexpected times and/or unexpected addresses, possibly > > leading to data leakage or corruption. > > > > For example, we plan to use the PCI-e bus for Wi-Fi and that PCI-e bus is > > not behind an IOMMU. As PCI-e, by design, gives the device full access to > > system memory, a vulnerability in the Wi-Fi firmware could easily escalate > > to a full system exploit (remote wifi exploits: [1a], [1b] that shows a > > full chain of exploits; [2], [3]). > > > > To mitigate the security concerns, we introduce restricted DMA. Restricted > > DMA utilizes the existing swiotlb to bounce streaming DMA in and out of a > > specially allocated region and does memory allocation from the same region. > > The feature on its own provides a basic level of protection against the DMA > > overwriting buffer contents at unexpected times. However, to protect > > against general data leakage and system memory corruption, the system needs > > to provide a way to restrict the DMA to a predefined memory region (this is > > usually done at firmware level, e.g. MPU in ATF on some ARM platforms [4]). > > > > [1a] > > https://googleprojectzero.blogspot.com/2017/04/over-air-exploiting-broadcoms-wi-fi_4.html > > [1b] > > https://googleprojectzero.blogspot.com/2017/04/over-air-exploiting-broadcoms-wi-fi_11.html > > [2] https://blade.tencent.com/en/advisories/qualpwn/ > > [3] > > https://www.bleepingcomputer.com/news/security/vulnerabilities-found-in-highly-popular-firmware-for-wifi-chips/ > > [4] > > https://github.com/ARM-software/arm-trusted-firmware/blob/master/plat/mediatek/mt8183/drivers/emi_mpu/emi_mpu.c#L132 > > > > v15: > > - Apply Will's diff > > (https://lore.kernel.org/patchwork/patch/1448957/#1647521) > > to fix the crash reported by Qian. > > - Add Stefano's Acked-by tag for patch 01/12 from v14 > > That all should be now be on > > https://git.kernel.org/pub/scm/linux/kernel/git/konrad/swiotlb.git/ > devel/for-linus-5.14 (and linux-next) > devel/for-linus-5.14 looks good. Thanks! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/6] KVM: Remove uses of struct page from x86 and arm64 MMU
Excerpts from Paolo Bonzini's message of June 25, 2021 1:35 am: > On 24/06/21 14:57, Nicholas Piggin wrote: >> KVM: Fix page ref underflow for regions with valid but non-refcounted pages > > It doesn't really fix the underflow, it disallows mapping them in the > first place. Since in principle things can break, I'd rather be > explicit, so let's go with "KVM: do not allow mapping valid but > non-reference-counted pages". > >> It's possible to create a region which maps valid but non-refcounted >> pages (e.g., tail pages of non-compound higher order allocations). These >> host pages can then be returned by gfn_to_page, gfn_to_pfn, etc., family >> of APIs, which take a reference to the page, which takes it from 0 to 1. >> When the reference is dropped, this will free the page incorrectly. >> >> Fix this by only taking a reference on the page if it was non-zero, > > s/on the page/on valid pages/ (makes clear that invalid pages are fine > without refcounting). That seems okay, you can adjust the title or changelog as you like. > Thank you *so* much, I'm awful at Linux mm. Glad to help. Easy to see why you were taking this approach because the API really does need to be improved and even a pretty intwined with mm subsystem like KVM shouldn't _really_ be doing this kind of trick (and it should go away when old API is removed). Thanks, Nick ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/6] drm/i915/display/adl_p: Implement PSR changes
On Thu, 2021-06-24 at 16:19 +, Souza, Jose wrote:
> On Thu, 2021-06-24 at 09:22 -0700, José Roberto de Souza wrote:
> > On Wed, 2021-06-23 at 22:06 +0300, Gwan-gyeong Mun wrote:
> > > On 6/16/21 11:31 PM, José Roberto de Souza wrote:
> > > > Implements changes around PSR for alderlake-P:
> > > >
> > > > - EDP_SU_TRACK_ENABLE was removed and bit 30 now has other function
> > > > - Some bits of PSR2_MAN_TRK_CTL moved and SF_PARTIAL_FRAME_UPDATE was
> > > >removed setting SU_REGION_START/END_ADDR will do this job
> > > > - SU_REGION_START/END_ADDR have now line granularity but will need to
> > > >be aligned with DSC when the PSRS + DSC support lands
> > > >
> > > > BSpec: 50422
> > > > BSpec: 50424
> > > > Cc: Gwan-gyeong Mun
> > > > Cc: Anusha Srivatsa
> > > > Signed-off-by: José Roberto de Souza
> > > > Signed-off-by: Gwan-gyeong Mun
> > > > ---
> > > > drivers/gpu/drm/i915/display/intel_psr.c | 43 ++--
> > > > drivers/gpu/drm/i915/i915_reg.h | 26 --
> > > > 2 files changed, 48 insertions(+), 21 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> > > > b/drivers/gpu/drm/i915/display/intel_psr.c
> > > > index 9643624fe160d..46bb19c4b63a4 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > > > @@ -534,11 +534,13 @@ static u32 intel_psr2_get_tp_time(struct intel_dp
> > > > *intel_dp)
> > > > static void hsw_activate_psr2(struct intel_dp *intel_dp)
> > > > {
> > > > struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> > > > - u32 val;
> > > > + u32 val = EDP_PSR2_ENABLE;
> > > > +
> > > > + val |= psr_compute_idle_frames(intel_dp) <<
> > > > EDP_PSR2_IDLE_FRAME_SHIFT;
> > > >
> > > > - val = psr_compute_idle_frames(intel_dp) <<
> > > > EDP_PSR2_IDLE_FRAME_SHIFT;
> > > > + if (!IS_ALDERLAKE_P(dev_priv))
> > > > + val |= EDP_SU_TRACK_ENABLE;
> > > >
> > > > - val |= EDP_PSR2_ENABLE | EDP_SU_TRACK_ENABLE;
> > > > if (DISPLAY_VER(dev_priv) >= 10 && DISPLAY_VER(dev_priv) <= 12)
> > > > val |= EDP_Y_COORDINATE_ENABLE;
> > > >
> > > > @@ -793,6 +795,7 @@ static bool
> > > > intel_psr2_sel_fetch_config_valid(struct intel_dp *intel_dp,
> > > > static bool psr2_granularity_check(struct intel_dp *intel_dp,
> > > >struct intel_crtc_state *crtc_state)
> > > > {
> > > > + struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> > > > const int crtc_hdisplay =
> > > > crtc_state->hw.adjusted_mode.crtc_hdisplay;
> > > > const int crtc_vdisplay =
> > > > crtc_state->hw.adjusted_mode.crtc_vdisplay;
> > > > u16 y_granularity = 0;
> > > > @@ -809,10 +812,13 @@ static bool psr2_granularity_check(struct
> > > > intel_dp *intel_dp,
> > > > return intel_dp->psr.su_y_granularity == 4;
> > > >
> > > > /*
> > > > -* For SW tracking we can adjust the y to match sink
> > > > requirement if
> > > > -* multiple of 4
> > > > +* adl_p has 1 line granularity for other platforms with SW
> > > > tracking we
> > > > +* can adjust the y coordinate to match sink requirement if
> > > > multiple of
> > > > +* 4
> > > > */
> > > > - if (intel_dp->psr.su_y_granularity <= 2)
> > > > + if (IS_ALDERLAKE_P(dev_priv))
> > > > + y_granularity = intel_dp->psr.su_y_granularity;
> > > > + else if (intel_dp->psr.su_y_granularity <= 2)
> > > > y_granularity = 4;
> > > > else if ((intel_dp->psr.su_y_granularity % 4) == 0)
> > > > y_granularity = intel_dp->psr.su_y_granularity;
> > > > @@ -1525,21 +1531,32 @@ void intel_psr2_program_trans_man_trk_ctl(const
> > > > struct intel_crtc_state *crtc_st
> > > > static void psr2_man_trk_ctl_calc(struct intel_crtc_state *crtc_state,
> > > > struct drm_rect *clip, bool
> > > > full_update)
> > > > {
> > > > + struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> > > > + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > > > u32 val = PSR2_MAN_TRK_CTL_ENABLE;
> > > The logic is not wrong, but the meaning of the register bit has changed.
> > > The 31st bit in ADL-P means "SF partial frame enable".
> > > It is recommended to add a macro such as
> > > ADLP_PSR2_MAN_TRK_CTL_SF_PARTIAL_FRAME_ENABLE to the code to clarify the
> > > role of the changed register.
> >
> > In my opinion the meaning is the same, enable manual/software tracking.
> > It was just a register rename done as part of changes of the other bits.
> >
> > But if you really think is necessary I can do that, please let me know.
>
> And with or without that can I add your RVB?
I have pushed all the reviewed patches.
Another note about the requested change, we use
Re: [Intel-gfx] [PATCH 05/47] drm/i915/guc: Add stall timer to non blocking CTB send function
On Thu, Jun 24, 2021 at 07:37:01PM +0200, Michal Wajdeczko wrote:
>
>
> On 24.06.2021 09:04, Matthew Brost wrote:
> > Implement a stall timer which fails H2G CTBs once a period of time
> > with no forward progress is reached to prevent deadlock.
> >
> > Also update to ct_write to return -EIO rather than -EPIPE on a
> > corrupted descriptor.
>
> by doing so you will have the same error code for two different problems:
>
> a) corrupted CTB descriptor (definitely unrecoverable)
> b) long stall in CTB processing (still recoverable)
>
Already discussed both are treated exactly the same by the rest of the
stack so we return a single error code.
> while caller is explicitly instructed to retry only on:
>
> c) temporary stall in CTB processing (likely recoverable)
>
> so why do we want to limit our diagnostics?
>
> >
> > Signed-off-by: John Harrison
> > Signed-off-by: Daniele Ceraolo Spurio
> > Signed-off-by: Matthew Brost
> > ---
> > drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 47 +--
> > drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h | 4 ++
> > 2 files changed, 48 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> > b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> > index c9a65d05911f..27ec30b5ef47 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> > @@ -319,6 +319,7 @@ int intel_guc_ct_enable(struct intel_guc_ct *ct)
> > goto err_deregister;
> >
> > ct->enabled = true;
> > + ct->stall_time = KTIME_MAX;
> >
> > return 0;
> >
> > @@ -392,7 +393,7 @@ static int ct_write(struct intel_guc_ct *ct,
> > unsigned int i;
> >
> > if (unlikely(ctb->broken))
> > - return -EPIPE;
> > + return -EIO;
> >
> > if (unlikely(desc->status))
> > goto corrupted;
> > @@ -464,7 +465,7 @@ static int ct_write(struct intel_guc_ct *ct,
> > CT_ERROR(ct, "Corrupted descriptor head=%u tail=%u status=%#x\n",
> > desc->head, desc->tail, desc->status);
> > ctb->broken = true;
> > - return -EPIPE;
> > + return -EIO;
> > }
> >
> > /**
> > @@ -507,6 +508,18 @@ static int wait_for_ct_request_update(struct
> > ct_request *req, u32 *status)
> > return err;
> > }
> >
> > +#define GUC_CTB_TIMEOUT_MS 1500
>
> it's 150% of core CTB timeout, maybe we should correlate them ?
>
Seems overkill.
> > +static inline bool ct_deadlocked(struct intel_guc_ct *ct)
> > +{
> > + long timeout = GUC_CTB_TIMEOUT_MS;
> > + bool ret = ktime_ms_delta(ktime_get(), ct->stall_time) > timeout;
> > +
> > + if (unlikely(ret))
> > + CT_ERROR(ct, "CT deadlocked\n");
>
> nit: in commit message you said all these changes are to "prevent
> deadlock" so maybe this message should rather be:
>
> int delta = ktime_ms_delta(ktime_get(), ct->stall_time);
>
> CT_ERROR(ct, "Communication stalled for %dms\n", delta);
>
Sure.
> (note that CT_ERROR already adds "CT" prefix)
>
> > +
> > + return ret;
> > +}
> > +
> > static inline bool h2g_has_room(struct intel_guc_ct_buffer *ctb, u32
> > len_dw)
> > {
> > struct guc_ct_buffer_desc *desc = ctb->desc;
> > @@ -518,6 +531,26 @@ static inline bool h2g_has_room(struct
> > intel_guc_ct_buffer *ctb, u32 len_dw)
> > return space >= len_dw;
> > }
> >
> > +static int has_room_nb(struct intel_guc_ct *ct, u32 len_dw)
> > +{
> > + struct intel_guc_ct_buffer *ctb = >ctbs.send;
> > +
> > + lockdep_assert_held(>ctbs.send.lock);
> > +
> > + if (unlikely(!h2g_has_room(ctb, len_dw))) {
> > + if (ct->stall_time == KTIME_MAX)
> > + ct->stall_time = ktime_get();
> > +
> > + if (unlikely(ct_deadlocked(ct)))
>
> and maybe above message should be printed somewhere around here when we
> detect "deadlock" for the first time?
>
Not sure I follow. The error message is in the correct place if ask me.
Probably should set the broken flag though when the message is printed
though.
> > + return -EIO;
> > + else
> > + return -EBUSY;
> > + }
> > +
> > + ct->stall_time = KTIME_MAX;
> > + return 0;
> > +}
> > +
> > static int ct_send_nb(struct intel_guc_ct *ct,
> > const u32 *action,
> > u32 len,
> > @@ -530,7 +563,7 @@ static int ct_send_nb(struct intel_guc_ct *ct,
> >
> > spin_lock_irqsave(>lock, spin_flags);
> >
> > - ret = h2g_has_room(ctb, len + 1);
> > + ret = has_room_nb(ct, len + 1);
> > if (unlikely(ret))
> > goto out;
> >
> > @@ -574,11 +607,19 @@ static int ct_send(struct intel_guc_ct *ct,
> > retry:
> > spin_lock_irqsave(>ctbs.send.lock, flags);
> > if (unlikely(!h2g_has_room(ctb, len + 1))) {
> > + if (ct->stall_time == KTIME_MAX)
> > + ct->stall_time = ktime_get();
>
> as this is a repeated pattern, maybe it should be moved to h2g_has_room
> or other wrapper ?
>
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915, drm/ttm: Update the ttm_move_memcpy() interface
== Series Details ==
Series: drm/i915, drm/ttm: Update the ttm_move_memcpy() interface
URL : https://patchwork.freedesktop.org/series/91893/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10278 -> Patchwork_20463
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20463/index.html
Known issues
Here are the changes found in Patchwork_20463 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@requests:
- fi-kbl-soraka: [PASS][1] -> [INCOMPLETE][2] ([i915#2782])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10278/fi-kbl-soraka/igt@i915_selftest@l...@requests.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20463/fi-kbl-soraka/igt@i915_selftest@l...@requests.html
* igt@runner@aborted:
- fi-kbl-soraka: NOTRUN -> [FAIL][3] ([i915#1436] / [i915#3363])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20463/fi-kbl-soraka/igt@run...@aborted.html
Possible fixes
* igt@i915_module_load@reload:
- {fi-tgl-dsi}: [DMESG-WARN][4] ([i915#1982] / [k.org#205379]) ->
[PASS][5]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10278/fi-tgl-dsi/igt@i915_module_l...@reload.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20463/fi-tgl-dsi/igt@i915_module_l...@reload.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2782]: https://gitlab.freedesktop.org/drm/intel/issues/2782
[i915#3363]: https://gitlab.freedesktop.org/drm/intel/issues/3363
[k.org#205379]: https://bugzilla.kernel.org/show_bug.cgi?id=205379
Participating hosts (43 -> 38)
--
Missing(5): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-kbl-7500u
fi-bdw-samus
Build changes
-
* Linux: CI_DRM_10278 -> Patchwork_20463
CI-20190529: 20190529
CI_DRM_10278: 33497e95c159f1fe3393f1016b1ec1187eab1589 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6119: a306810ebbc8984bde38a57ef0c33eea394f4e18 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_20463: 85a97e35327d5c07f52418186979b31c81f13eee @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
85a97e35327d drm/ttm, drm/i915: Update ttm_move_memcpy for async use
a621c25bc265 drm/i915/ttm: Reorganize the ttm move code somewhat
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20463/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/47] drm/i915/guc: Add non blocking CTB send function
On Thu, Jun 24, 2021 at 07:02:18PM +0200, Michal Wajdeczko wrote:
>
>
> On 24.06.2021 17:49, Matthew Brost wrote:
> > On Thu, Jun 24, 2021 at 04:48:32PM +0200, Michal Wajdeczko wrote:
> >>
> >>
> >> On 24.06.2021 09:04, Matthew Brost wrote:
> >>> Add non blocking CTB send function, intel_guc_send_nb. GuC submission
> >>> will send CTBs in the critical path and does not need to wait for these
> >>> CTBs to complete before moving on, hence the need for this new function.
> >>>
> >>> The non-blocking CTB now must have a flow control mechanism to ensure
> >>> the buffer isn't overrun. A lazy spin wait is used as we believe the
> >>> flow control condition should be rare with a properly sized buffer.
> >>>
> >>> The function, intel_guc_send_nb, is exported in this patch but unused.
> >>> Several patches later in the series make use of this function.
> >>>
> >>> Signed-off-by: John Harrison
> >>> Signed-off-by: Matthew Brost
> >>> ---
> >>> drivers/gpu/drm/i915/gt/uc/intel_guc.h| 12 +++-
> >>> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 77 +--
> >>> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h | 3 +-
> >>> 3 files changed, 82 insertions(+), 10 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> >>> b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> >>> index 4abc59f6f3cd..24b1df6ad4ae 100644
> >>> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> >>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> >>> @@ -74,7 +74,15 @@ static inline struct intel_guc *log_to_guc(struct
> >>> intel_guc_log *log)
> >>> static
> >>> inline int intel_guc_send(struct intel_guc *guc, const u32 *action, u32
> >>> len)
> >>> {
> >>> - return intel_guc_ct_send(>ct, action, len, NULL, 0);
> >>> + return intel_guc_ct_send(>ct, action, len, NULL, 0, 0);
> >>> +}
> >>> +
> >>> +#define INTEL_GUC_SEND_NBBIT(31)
> >>
> >> hmm, this flag really belongs to intel_guc_ct_send() so it should be
> >> defined as CTB flag near that function declaration
> >>
> >
> > I can move this up a few lines.
> >
> >>> +static
> >>> +inline int intel_guc_send_nb(struct intel_guc *guc, const u32 *action,
> >>> u32 len)
> >>> +{
> >>> + return intel_guc_ct_send(>ct, action, len, NULL, 0,
> >>> + INTEL_GUC_SEND_NB);
> >>> }
> >>>
> >>> static inline int
> >>> @@ -82,7 +90,7 @@ intel_guc_send_and_receive(struct intel_guc *guc, const
> >>> u32 *action, u32 len,
> >>> u32 *response_buf, u32 response_buf_size)
> >>> {
> >>> return intel_guc_ct_send(>ct, action, len,
> >>> - response_buf, response_buf_size);
> >>> + response_buf, response_buf_size, 0);
> >>> }
> >>>
> >>> static inline void intel_guc_to_host_event_handler(struct intel_guc *guc)
> >>> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> >>> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> >>> index a17215920e58..c9a65d05911f 100644
> >>> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> >>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> >>> @@ -3,6 +3,11 @@
> >>> * Copyright © 2016-2019 Intel Corporation
> >>> */
> >>>
> >>> +#include
> >>> +#include
> >>> +#include
> >>> +#include
> >>> +
> >>> #include "i915_drv.h"
> >>> #include "intel_guc_ct.h"
> >>> #include "gt/intel_gt.h"
> >>> @@ -373,7 +378,7 @@ static void write_barrier(struct intel_guc_ct *ct)
> >>> static int ct_write(struct intel_guc_ct *ct,
> >>> const u32 *action,
> >>> u32 len /* in dwords */,
> >>> - u32 fence)
> >>> + u32 fence, u32 flags)
> >>> {
> >>> struct intel_guc_ct_buffer *ctb = >ctbs.send;
> >>> struct guc_ct_buffer_desc *desc = ctb->desc;
> >>> @@ -421,9 +426,13 @@ static int ct_write(struct intel_guc_ct *ct,
> >>>FIELD_PREP(GUC_CTB_MSG_0_NUM_DWORDS, len) |
> >>>FIELD_PREP(GUC_CTB_MSG_0_FENCE, fence);
> >>>
> >>> - hxg = FIELD_PREP(GUC_HXG_MSG_0_TYPE, GUC_HXG_TYPE_REQUEST) |
> >>> - FIELD_PREP(GUC_HXG_REQUEST_MSG_0_ACTION |
> >>> - GUC_HXG_REQUEST_MSG_0_DATA0, action[0]);
> >>> + hxg = (flags & INTEL_GUC_SEND_NB) ?
> >>> + (FIELD_PREP(GUC_HXG_MSG_0_TYPE, GUC_HXG_TYPE_EVENT) |
> >>> + FIELD_PREP(GUC_HXG_EVENT_MSG_0_ACTION |
> >>> + GUC_HXG_EVENT_MSG_0_DATA0, action[0])) :
> >>> + (FIELD_PREP(GUC_HXG_MSG_0_TYPE, GUC_HXG_TYPE_REQUEST) |
> >>> + FIELD_PREP(GUC_HXG_REQUEST_MSG_0_ACTION |
> >>> + GUC_HXG_REQUEST_MSG_0_DATA0, action[0]));
> >>
> >> or as we already switched to accept and return whole HXG messages in
> >> guc_send_mmio() maybe we should do the same for CTB variant too and
> >> instead of using extra flag just let caller to prepare proper HXG header
> >> with HXG_EVENT type and then in CTB code just look at this type to make
> >> decision which code path to use
> >>
> >
> > Not sure I follow. Anyways could this be done in a follow up by you if
> >
Re: [Intel-gfx] [PATCH 04/47] drm/i915/guc: Add non blocking CTB send function
On Thu, Jun 24, 2021 at 07:02:18PM +0200, Michal Wajdeczko wrote:
>
>
> On 24.06.2021 17:49, Matthew Brost wrote:
> > On Thu, Jun 24, 2021 at 04:48:32PM +0200, Michal Wajdeczko wrote:
> >>
> >>
> >> On 24.06.2021 09:04, Matthew Brost wrote:
> >>> Add non blocking CTB send function, intel_guc_send_nb. GuC submission
> >>> will send CTBs in the critical path and does not need to wait for these
> >>> CTBs to complete before moving on, hence the need for this new function.
> >>>
> >>> The non-blocking CTB now must have a flow control mechanism to ensure
> >>> the buffer isn't overrun. A lazy spin wait is used as we believe the
> >>> flow control condition should be rare with a properly sized buffer.
> >>>
> >>> The function, intel_guc_send_nb, is exported in this patch but unused.
> >>> Several patches later in the series make use of this function.
> >>>
> >>> Signed-off-by: John Harrison
> >>> Signed-off-by: Matthew Brost
> >>> ---
> >>> drivers/gpu/drm/i915/gt/uc/intel_guc.h| 12 +++-
> >>> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 77 +--
> >>> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h | 3 +-
> >>> 3 files changed, 82 insertions(+), 10 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> >>> b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> >>> index 4abc59f6f3cd..24b1df6ad4ae 100644
> >>> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> >>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> >>> @@ -74,7 +74,15 @@ static inline struct intel_guc *log_to_guc(struct
> >>> intel_guc_log *log)
> >>> static
> >>> inline int intel_guc_send(struct intel_guc *guc, const u32 *action, u32
> >>> len)
> >>> {
> >>> - return intel_guc_ct_send(>ct, action, len, NULL, 0);
> >>> + return intel_guc_ct_send(>ct, action, len, NULL, 0, 0);
> >>> +}
> >>> +
> >>> +#define INTEL_GUC_SEND_NBBIT(31)
> >>
> >> hmm, this flag really belongs to intel_guc_ct_send() so it should be
> >> defined as CTB flag near that function declaration
> >>
> >
> > I can move this up a few lines.
> >
> >>> +static
> >>> +inline int intel_guc_send_nb(struct intel_guc *guc, const u32 *action,
> >>> u32 len)
> >>> +{
> >>> + return intel_guc_ct_send(>ct, action, len, NULL, 0,
> >>> + INTEL_GUC_SEND_NB);
> >>> }
> >>>
> >>> static inline int
> >>> @@ -82,7 +90,7 @@ intel_guc_send_and_receive(struct intel_guc *guc, const
> >>> u32 *action, u32 len,
> >>> u32 *response_buf, u32 response_buf_size)
> >>> {
> >>> return intel_guc_ct_send(>ct, action, len,
> >>> - response_buf, response_buf_size);
> >>> + response_buf, response_buf_size, 0);
> >>> }
> >>>
> >>> static inline void intel_guc_to_host_event_handler(struct intel_guc *guc)
> >>> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> >>> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> >>> index a17215920e58..c9a65d05911f 100644
> >>> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> >>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> >>> @@ -3,6 +3,11 @@
> >>> * Copyright © 2016-2019 Intel Corporation
> >>> */
> >>>
> >>> +#include
> >>> +#include
> >>> +#include
> >>> +#include
> >>> +
> >>> #include "i915_drv.h"
> >>> #include "intel_guc_ct.h"
> >>> #include "gt/intel_gt.h"
> >>> @@ -373,7 +378,7 @@ static void write_barrier(struct intel_guc_ct *ct)
> >>> static int ct_write(struct intel_guc_ct *ct,
> >>> const u32 *action,
> >>> u32 len /* in dwords */,
> >>> - u32 fence)
> >>> + u32 fence, u32 flags)
> >>> {
> >>> struct intel_guc_ct_buffer *ctb = >ctbs.send;
> >>> struct guc_ct_buffer_desc *desc = ctb->desc;
> >>> @@ -421,9 +426,13 @@ static int ct_write(struct intel_guc_ct *ct,
> >>>FIELD_PREP(GUC_CTB_MSG_0_NUM_DWORDS, len) |
> >>>FIELD_PREP(GUC_CTB_MSG_0_FENCE, fence);
> >>>
> >>> - hxg = FIELD_PREP(GUC_HXG_MSG_0_TYPE, GUC_HXG_TYPE_REQUEST) |
> >>> - FIELD_PREP(GUC_HXG_REQUEST_MSG_0_ACTION |
> >>> - GUC_HXG_REQUEST_MSG_0_DATA0, action[0]);
> >>> + hxg = (flags & INTEL_GUC_SEND_NB) ?
> >>> + (FIELD_PREP(GUC_HXG_MSG_0_TYPE, GUC_HXG_TYPE_EVENT) |
> >>> + FIELD_PREP(GUC_HXG_EVENT_MSG_0_ACTION |
> >>> + GUC_HXG_EVENT_MSG_0_DATA0, action[0])) :
> >>> + (FIELD_PREP(GUC_HXG_MSG_0_TYPE, GUC_HXG_TYPE_REQUEST) |
> >>> + FIELD_PREP(GUC_HXG_REQUEST_MSG_0_ACTION |
> >>> + GUC_HXG_REQUEST_MSG_0_DATA0, action[0]));
> >>
> >> or as we already switched to accept and return whole HXG messages in
> >> guc_send_mmio() maybe we should do the same for CTB variant too and
> >> instead of using extra flag just let caller to prepare proper HXG header
> >> with HXG_EVENT type and then in CTB code just look at this type to make
> >> decision which code path to use
> >>
> >
> > Not sure I follow. Anyways could this be done in a follow up by you if
> >
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/dp: Fix invalid test parameter when run DP link layer compliance
== Series Details == Series: drm/i915/dp: Fix invalid test parameter when run DP link layer compliance URL : https://patchwork.freedesktop.org/series/91879/ State : success == Summary == CI Bug Log - changes from CI_DRM_10276_full -> Patchwork_20458_full Summary --- **WARNING** Minor unknown changes coming with Patchwork_20458_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_20458_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_20458_full: ### IGT changes ### Warnings * igt@kms_psr2_sf@cursor-plane-update-sf: - shard-iclb: [SKIP][1] ([i915#658]) -> [SKIP][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10276/shard-iclb4/igt@kms_psr2...@cursor-plane-update-sf.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20458/shard-iclb2/igt@kms_psr2...@cursor-plane-update-sf.html Known issues Here are the changes found in Patchwork_20458_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_create@create-massive: - shard-apl: NOTRUN -> [DMESG-WARN][3] ([i915#3002]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20458/shard-apl2/igt@gem_cre...@create-massive.html * igt@gem_ctx_persistence@smoketest: - shard-snb: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#1099]) +3 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20458/shard-snb5/igt@gem_ctx_persiste...@smoketest.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-tglb: [PASS][5] -> [FAIL][6] ([i915#2842]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10276/shard-tglb2/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20458/shard-tglb8/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_exec_fair@basic-pace@vecs0: - shard-glk: [PASS][7] -> [FAIL][8] ([i915#2842]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10276/shard-glk5/igt@gem_exec_fair@basic-p...@vecs0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20458/shard-glk7/igt@gem_exec_fair@basic-p...@vecs0.html * igt@gem_exec_parallel@engines@basic: - shard-glk: [PASS][9] -> [DMESG-WARN][10] ([i915#118] / [i915#95]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10276/shard-glk7/igt@gem_exec_parallel@engi...@basic.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20458/shard-glk2/igt@gem_exec_parallel@engi...@basic.html * igt@gem_fenced_exec_thrash@no-spare-fences: - shard-snb: [PASS][11] -> [INCOMPLETE][12] ([i915#2055]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10276/shard-snb7/igt@gem_fenced_exec_thr...@no-spare-fences.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20458/shard-snb2/igt@gem_fenced_exec_thr...@no-spare-fences.html * igt@gem_mmap_gtt@big-copy: - shard-glk: [PASS][13] -> [FAIL][14] ([i915#307]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10276/shard-glk2/igt@gem_mmap_...@big-copy.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20458/shard-glk6/igt@gem_mmap_...@big-copy.html * igt@gen9_exec_parse@bb-large: - shard-glk: NOTRUN -> [FAIL][15] ([i915#3296]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20458/shard-glk5/igt@gen9_exec_pa...@bb-large.html * igt@i915_pm_dc@dc6-psr: - shard-iclb: [PASS][16] -> [FAIL][17] ([i915#454]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10276/shard-iclb5/igt@i915_pm...@dc6-psr.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20458/shard-iclb6/igt@i915_pm...@dc6-psr.html * igt@i915_pm_rc6_residency@rc6-fence: - shard-iclb: NOTRUN -> [WARN][18] ([i915#2684]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20458/shard-iclb1/igt@i915_pm_rc6_reside...@rc6-fence.html * igt@i915_pm_rpm@modeset-lpsp-stress: - shard-apl: NOTRUN -> [SKIP][19] ([fdo#109271]) +188 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20458/shard-apl2/igt@i915_pm_...@modeset-lpsp-stress.html * igt@kms_chamelium@dp-crc-fast: - shard-iclb: NOTRUN -> [SKIP][20] ([fdo#109284] / [fdo#111827]) +1 similar issue [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20458/shard-iclb1/igt@kms_chamel...@dp-crc-fast.html * igt@kms_chamelium@dp-hpd-storm-disable: - shard-glk: NOTRUN -> [SKIP][21] ([fdo#109271] / [fdo#111827]) +4 similar issues [21]:
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gem: Introduce a migrate interface
== Series Details ==
Series: drm/i915/gem: Introduce a migrate interface
URL : https://patchwork.freedesktop.org/series/91890/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10278 -> Patchwork_20462
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20462/index.html
New tests
-
New tests have been introduced between CI_DRM_10278 and Patchwork_20462:
### New IGT tests (1) ###
* igt@i915_selftest@live@gem_migrate:
- Statuses : 34 pass(s)
- Exec time: [0.43, 5.13] s
Known issues
Here are the changes found in Patchwork_20462 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_pm_rpm@module-reload:
- fi-kbl-7500u: [PASS][1] -> [INCOMPLETE][2] ([i915#151] /
[i915#2405])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10278/fi-kbl-7500u/igt@i915_pm_...@module-reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20462/fi-kbl-7500u/igt@i915_pm_...@module-reload.html
* igt@runner@aborted:
- fi-kbl-7500u: NOTRUN -> [FAIL][3] ([fdo#109271] / [i915#1814] /
[i915#2722] / [i915#3363])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20462/fi-kbl-7500u/igt@run...@aborted.html
Possible fixes
* igt@i915_module_load@reload:
- {fi-tgl-dsi}: [DMESG-WARN][4] ([i915#1982] / [k.org#205379]) ->
[PASS][5]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10278/fi-tgl-dsi/igt@i915_module_l...@reload.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20462/fi-tgl-dsi/igt@i915_module_l...@reload.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#151]: https://gitlab.freedesktop.org/drm/intel/issues/151
[i915#1814]: https://gitlab.freedesktop.org/drm/intel/issues/1814
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2405]: https://gitlab.freedesktop.org/drm/intel/issues/2405
[i915#2722]: https://gitlab.freedesktop.org/drm/intel/issues/2722
[i915#3363]: https://gitlab.freedesktop.org/drm/intel/issues/3363
[k.org#205379]: https://bugzilla.kernel.org/show_bug.cgi?id=205379
Participating hosts (43 -> 39)
--
Missing(4): fi-ilk-m540 fi-bsw-cyan fi-bdw-samus fi-hsw-4200u
Build changes
-
* Linux: CI_DRM_10278 -> Patchwork_20462
CI-20190529: 20190529
CI_DRM_10278: 33497e95c159f1fe3393f1016b1ec1187eab1589 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6119: a306810ebbc8984bde38a57ef0c33eea394f4e18 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_20462: de1e6e1fa3f7380663488844a29ddb461157ef3c @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
de1e6e1fa3f7 drm/i915/gem: Migrate to system at dma-buf map time
974c401400ff drm/i915/display: Migrate objects to LMEM if possible for display
c7fc34104143 drm/i915/gem: Introduce a selftest for the gem object migrate
functionality
ee56ef21edf6 drm/i915/gem: Implement object migration
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20462/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/gem: Introduce a migrate interface
== Series Details == Series: drm/i915/gem: Introduce a migrate interface URL : https://patchwork.freedesktop.org/series/91890/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - +drivers/gpu/drm/i915/display/intel_display.c:1896:21:expected struct i915_vma *[assigned] vma +drivers/gpu/drm/i915/display/intel_display.c:1896:21:got void [noderef] __iomem *[assigned] iomem +drivers/gpu/drm/i915/display/intel_display.c:1896:21: warning: incorrect type in assignment (different address spaces) +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_reset.c:1396:5: warning: context imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic block +drivers/gpu/drm/i915/gt/intel_ring_submission.c:1207:24: warning: Using plain integer as NULL pointer +drivers/gpu/drm/i915/i915_perf.c:1434:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/i915_perf.c:1488:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/selftests/i915_syncmap.c:80:54: warning: dubious: x | !y +./include/asm-generic/bitops/find.h:112:45: warning: shift count is negative (-262080) +./include/asm-generic/bitops/find.h:32:31: warning: shift count is negative (-262080) +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9:
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/gem: Introduce a migrate interface
== Series Details == Series: drm/i915/gem: Introduce a migrate interface URL : https://patchwork.freedesktop.org/series/91890/ State : warning == Summary == $ dim checkpatch origin/drm-tip ee56ef21edf6 drm/i915/gem: Implement object migration c7fc34104143 drm/i915/gem: Introduce a selftest for the gem object migrate functionality -:31: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #31: new file mode 100644 total: 0 errors, 1 warnings, 0 checks, 251 lines checked 974c401400ff drm/i915/display: Migrate objects to LMEM if possible for display de1e6e1fa3f7 drm/i915/gem: Migrate to system at dma-buf map time ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] dma-buf/sync_file: Don't leak fences on merge failure
Am 24.06.21 um 19:47 schrieb Jason Ekstrand:
Each add_fence() call does a dma_fence_get() on the relevant fence. In
the error path, we weren't calling dma_fence_put() so all those fences
got leaked. Also, in the krealloc_array failure case, we weren't
freeing the fences array. Instead, ensure that i and fences are always
zero-initialized and dma_fence_put() all the fences and kfree(fences) on
every error path.
Signed-off-by: Jason Ekstrand
Fixes: a02b9dc90d84 ("dma-buf/sync_file: refactor fence storage in struct
sync_file")
Cc: Gustavo Padovan
Cc: Christian König
Reviewed-by: Christian König
---
drivers/dma-buf/sync_file.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c
index 20d9bddbb985b..394e6e1e96860 100644
--- a/drivers/dma-buf/sync_file.c
+++ b/drivers/dma-buf/sync_file.c
@@ -211,8 +211,8 @@ static struct sync_file *sync_file_merge(const char *name,
struct sync_file *a,
struct sync_file *b)
{
struct sync_file *sync_file;
- struct dma_fence **fences, **nfences, **a_fences, **b_fences;
- int i, i_a, i_b, num_fences, a_num_fences, b_num_fences;
+ struct dma_fence **fences = NULL, **nfences, **a_fences, **b_fences;
+ int i = 0, i_a, i_b, num_fences, a_num_fences, b_num_fences;
sync_file = sync_file_alloc();
if (!sync_file)
@@ -236,7 +236,7 @@ static struct sync_file *sync_file_merge(const char *name,
struct sync_file *a,
* If a sync_file can only be created with sync_file_merge
* and sync_file_create, this is a reasonable assumption.
*/
- for (i = i_a = i_b = 0; i_a < a_num_fences && i_b < b_num_fences; ) {
+ for (i_a = i_b = 0; i_a < a_num_fences && i_b < b_num_fences; ) {
struct dma_fence *pt_a = a_fences[i_a];
struct dma_fence *pt_b = b_fences[i_b];
@@ -277,15 +277,16 @@ static struct sync_file *sync_file_merge(const char *name, struct sync_file *a,
fences = nfences;
}
- if (sync_file_set_fence(sync_file, fences, i) < 0) {
- kfree(fences);
+ if (sync_file_set_fence(sync_file, fences, i) < 0)
goto err;
- }
strlcpy(sync_file->user_name, name, sizeof(sync_file->user_name));
return sync_file;
err:
+ while (i)
+ dma_fence_put(fences[--i]);
+ kfree(fences);
fput(sync_file->file);
return NULL;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for dma-buf/sync_file: Don't leak fences on merge failure
== Series Details ==
Series: dma-buf/sync_file: Don't leak fences on merge failure
URL : https://patchwork.freedesktop.org/series/91888/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10278 -> Patchwork_20461
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20461/index.html
Known issues
Here are the changes found in Patchwork_20461 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@gt_heartbeat:
- fi-bdw-5557u: [PASS][1] -> [DMESG-FAIL][2] ([i915#541])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10278/fi-bdw-5557u/igt@i915_selftest@live@gt_heartbeat.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20461/fi-bdw-5557u/igt@i915_selftest@live@gt_heartbeat.html
Possible fixes
* igt@i915_module_load@reload:
- {fi-tgl-dsi}: [DMESG-WARN][3] ([i915#1982] / [k.org#205379]) ->
[PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10278/fi-tgl-dsi/igt@i915_module_l...@reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20461/fi-tgl-dsi/igt@i915_module_l...@reload.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#541]: https://gitlab.freedesktop.org/drm/intel/issues/541
[k.org#205379]: https://bugzilla.kernel.org/show_bug.cgi?id=205379
Participating hosts (43 -> 39)
--
Missing(4): fi-ilk-m540 fi-bsw-cyan fi-bdw-samus fi-hsw-4200u
Build changes
-
* Linux: CI_DRM_10278 -> Patchwork_20461
CI-20190529: 20190529
CI_DRM_10278: 33497e95c159f1fe3393f1016b1ec1187eab1589 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6119: a306810ebbc8984bde38a57ef0c33eea394f4e18 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_20461: eca3b2db550829b76113089f8c877a4bee198ab9 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
eca3b2db5508 dma-buf/sync_file: Don't leak fences on merge failure
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20461/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/selftest: Extend ctx_timestamp ICL workaround to GEN11 (rev3)
== Series Details == Series: drm/i915/selftest: Extend ctx_timestamp ICL workaround to GEN11 (rev3) URL : https://patchwork.freedesktop.org/series/91805/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10276_full -> Patchwork_20456_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_20456_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_20456_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_20456_full: ### IGT changes ### Possible regressions * igt@gem_exec_reloc@basic-parallel: - shard-tglb: [PASS][1] -> [TIMEOUT][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10276/shard-tglb7/igt@gem_exec_re...@basic-parallel.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20456/shard-tglb1/igt@gem_exec_re...@basic-parallel.html * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: - shard-glk: [PASS][3] -> [INCOMPLETE][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10276/shard-glk4/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20456/shard-glk7/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html * igt@sysfs_timeslice_duration@timeout@vecs0: - shard-skl: [PASS][5] -> [FAIL][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10276/shard-skl4/igt@sysfs_timeslice_duration@time...@vecs0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20456/shard-skl7/igt@sysfs_timeslice_duration@time...@vecs0.html Warnings * igt@kms_psr2_sf@plane-move-sf-dmg-area-3: - shard-iclb: [SKIP][7] ([i915#658]) -> [SKIP][8] +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10276/shard-iclb8/igt@kms_psr2...@plane-move-sf-dmg-area-3.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20456/shard-iclb2/igt@kms_psr2...@plane-move-sf-dmg-area-3.html ### Piglit changes ### Possible regressions * spec@arb_gpu_shader_fp64@execution@built-in-functions@gs-normalize-dvec2 (NEW): - pig-kbl-iris: NOTRUN -> [INCOMPLETE][9] +7 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20456/pig-kbl-iris/spec@arb_gpu_shader_fp64@execution@built-in-functi...@gs-normalize-dvec2.html New tests - New tests have been introduced between CI_DRM_10276_full and Patchwork_20456_full: ### New Piglit tests (8) ### * spec@arb_gpu_shader_fp64@execution@built-in-functions@fs-op-div-dmat3-dmat3: - Statuses : 1 incomplete(s) - Exec time: [0.0] s * spec@arb_gpu_shader_fp64@execution@built-in-functions@gs-normalize-dvec2: - Statuses : 1 incomplete(s) - Exec time: [0.0] s * spec@arb_gpu_shader_fp64@execution@built-in-functions@gs-op-mult-dvec2-dmat2: - Statuses : 1 incomplete(s) - Exec time: [0.0] s * spec@arb_gpu_shader_fp64@execution@built-in-functions@gs-op-mult-dvec4-dmat2x4: - Statuses : 1 incomplete(s) - Exec time: [0.0] s * spec@arb_gpu_shader_fp64@execution@built-in-functions@gs-sign-dvec2: - Statuses : 1 incomplete(s) - Exec time: [0.0] s * spec@arb_gpu_shader_fp64@execution@built-in-functions@vs-ceil-double: - Statuses : 1 incomplete(s) - Exec time: [0.0] s * spec@arb_gpu_shader_fp64@execution@built-in-functions@vs-fract-dvec3: - Statuses : 1 incomplete(s) - Exec time: [0.0] s * spec@arb_gpu_shader_fp64@execution@built-in-functions@vs-op-add-double-dmat3: - Statuses : 1 incomplete(s) - Exec time: [0.0] s Known issues Here are the changes found in Patchwork_20456_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@smoketest: - shard-snb: NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#1099]) +3 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20456/shard-snb5/igt@gem_ctx_persiste...@smoketest.html * igt@gem_exec_fair@basic-deadline: - shard-apl: NOTRUN -> [FAIL][11] ([i915#2846]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20456/shard-apl1/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-none-solo@rcs0: - shard-kbl: NOTRUN -> [FAIL][12] ([i915#2842]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20456/shard-kbl6/igt@gem_exec_fair@basic-none-s...@rcs0.html * igt@gem_exec_fair@basic-pace@rcs0: - shard-kbl: [PASS][13] -> [FAIL][14] ([i915#2842]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10276/shard-kbl1/igt@gem_exec_fair@basic-p...@rcs0.html [14]:
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Reinstate the mmap ioctl for some platforms (rev2)
== Series Details == Series: drm/i915: Reinstate the mmap ioctl for some platforms (rev2) URL : https://patchwork.freedesktop.org/series/91865/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10276_full -> Patchwork_20455_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_20455_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_20455_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_20455_full: ### IGT changes ### Possible regressions * igt@i915_suspend@forcewake: - shard-iclb: [PASS][1] -> [DMESG-WARN][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10276/shard-iclb1/igt@i915_susp...@forcewake.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20455/shard-iclb1/igt@i915_susp...@forcewake.html * igt@perf_pmu@most-busy-idle-check-all@rcs0: - shard-skl: [PASS][3] -> [FAIL][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10276/shard-skl8/igt@perf_pmu@most-busy-idle-check-...@rcs0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20455/shard-skl1/igt@perf_pmu@most-busy-idle-check-...@rcs0.html Warnings * igt@kms_psr2_sf@primary-plane-update-sf-dmg-area-2: - shard-iclb: [SKIP][5] ([i915#658]) -> [SKIP][6] +2 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10276/shard-iclb5/igt@kms_psr2...@primary-plane-update-sf-dmg-area-2.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20455/shard-iclb2/igt@kms_psr2...@primary-plane-update-sf-dmg-area-2.html Known issues Here are the changes found in Patchwork_20455_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_create@create-massive: - shard-apl: NOTRUN -> [DMESG-WARN][7] ([i915#3002]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20455/shard-apl2/igt@gem_cre...@create-massive.html * igt@gem_ctx_persistence@smoketest: - shard-snb: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#1099]) +4 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20455/shard-snb2/igt@gem_ctx_persiste...@smoketest.html * igt@gem_eio@unwedge-stress: - shard-iclb: [PASS][9] -> [TIMEOUT][10] ([i915#2369] / [i915#2481] / [i915#3070]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10276/shard-iclb5/igt@gem_...@unwedge-stress.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20455/shard-iclb1/igt@gem_...@unwedge-stress.html * igt@gem_exec_fair@basic-deadline: - shard-apl: NOTRUN -> [FAIL][11] ([i915#2846]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20455/shard-apl2/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-none@vcs0: - shard-kbl: [PASS][12] -> [FAIL][13] ([i915#2842]) +1 similar issue [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10276/shard-kbl4/igt@gem_exec_fair@basic-n...@vcs0.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20455/shard-kbl2/igt@gem_exec_fair@basic-n...@vcs0.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-tglb: [PASS][14] -> [FAIL][15] ([i915#2842]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10276/shard-tglb2/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20455/shard-tglb7/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_exec_fair@basic-pace@vcs1: - shard-iclb: NOTRUN -> [FAIL][16] ([i915#2842]) +1 similar issue [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20455/shard-iclb1/igt@gem_exec_fair@basic-p...@vcs1.html * igt@gem_exec_fair@basic-throttle@rcs0: - shard-glk: [PASS][17] -> [FAIL][18] ([i915#2842]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10276/shard-glk5/igt@gem_exec_fair@basic-throt...@rcs0.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20455/shard-glk3/igt@gem_exec_fair@basic-throt...@rcs0.html * igt@gem_exec_whisper@basic-queues-forked-all: - shard-glk: [PASS][19] -> [DMESG-WARN][20] ([i915#118] / [i915#95]) +2 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10276/shard-glk6/igt@gem_exec_whis...@basic-queues-forked-all.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20455/shard-glk5/igt@gem_exec_whis...@basic-queues-forked-all.html * igt@gem_huc_copy@huc-copy: - shard-apl: NOTRUN -> [SKIP][21] ([fdo#109271] / [i915#2190]) [21]:
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/display: fix level 0 adjustement on display ver >= 12 (rev2)
== Series Details == Series: series starting with [1/2] drm/i915/display: fix level 0 adjustement on display ver >= 12 (rev2) URL : https://patchwork.freedesktop.org/series/91791/ State : success == Summary == CI Bug Log - changes from CI_DRM_10277 -> Patchwork_20460 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20460/index.html Known issues Here are the changes found in Patchwork_20460 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_cs_nop@sync-fork-compute0: - fi-kbl-soraka: NOTRUN -> [SKIP][1] ([fdo#109271]) +11 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20460/fi-kbl-soraka/igt@amdgpu/amd_cs_...@sync-fork-compute0.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 Participating hosts (44 -> 39) -- Missing(5): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 fi-bdw-samus Build changes - * Linux: CI_DRM_10277 -> Patchwork_20460 CI-20190529: 20190529 CI_DRM_10277: c79becd42bf230117a3069a918a9448fb67f3cb1 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_6119: a306810ebbc8984bde38a57ef0c33eea394f4e18 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_20460: c6987aa2f6c603863d14d3e851e0db43bced8f02 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == c6987aa2f6c6 drm/i915/display: use max_level to control loop 680e74bd86a0 drm/i915/display: fix level 0 adjustement on display ver >= 12 == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20460/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v6,RESEND,1/3] gpu: drm: separate panel orientation property creating and value setting
== Series Details == Series: series starting with [v6,RESEND,1/3] gpu: drm: separate panel orientation property creating and value setting URL : https://patchwork.freedesktop.org/series/91867/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10276_full -> Patchwork_20454_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_20454_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_20454_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_20454_full: ### IGT changes ### Possible regressions * igt@sysfs_timeslice_duration@timeout@vecs0: - shard-glk: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10276/shard-glk5/igt@sysfs_timeslice_duration@time...@vecs0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20454/shard-glk8/igt@sysfs_timeslice_duration@time...@vecs0.html Warnings * igt@kms_psr2_sf@primary-plane-update-sf-dmg-area-1: - shard-iclb: [SKIP][3] ([i915#658]) -> [SKIP][4] +3 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10276/shard-iclb5/igt@kms_psr2...@primary-plane-update-sf-dmg-area-1.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20454/shard-iclb2/igt@kms_psr2...@primary-plane-update-sf-dmg-area-1.html Known issues Here are the changes found in Patchwork_20454_full that come from known issues: ### CI changes ### Issues hit * boot: - shard-skl: ([PASS][5], [PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25], [PASS][26], [PASS][27], [PASS][28]) -> ([PASS][29], [PASS][30], [PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37], [FAIL][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48], [PASS][49], [PASS][50], [PASS][51], [PASS][52], [PASS][53]) ([i915#3174]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10276/shard-skl9/boot.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10276/shard-skl9/boot.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10276/shard-skl8/boot.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10276/shard-skl7/boot.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10276/shard-skl7/boot.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10276/shard-skl6/boot.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10276/shard-skl6/boot.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10276/shard-skl6/boot.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10276/shard-skl5/boot.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10276/shard-skl5/boot.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10276/shard-skl4/boot.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10276/shard-skl4/boot.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10276/shard-skl4/boot.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10276/shard-skl3/boot.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10276/shard-skl3/boot.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10276/shard-skl3/boot.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10276/shard-skl2/boot.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10276/shard-skl2/boot.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10276/shard-skl10/boot.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10276/shard-skl10/boot.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10276/shard-skl10/boot.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10276/shard-skl1/boot.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10276/shard-skl1/boot.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10276/shard-skl1/boot.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20454/shard-skl1/boot.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20454/shard-skl1/boot.html [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20454/shard-skl10/boot.html [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20454/shard-skl10/boot.html [33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20454/shard-skl10/boot.html [34]:
Re: [Intel-gfx] [PATCH] dma-buf/sync_file: Don't leak fences on merge failure
I don't have drm-misc access. Mind pushing?
On Thu, Jun 24, 2021 at 12:59 PM Christian König
wrote:
>
> Am 24.06.21 um 19:47 schrieb Jason Ekstrand:
> > Each add_fence() call does a dma_fence_get() on the relevant fence. In
> > the error path, we weren't calling dma_fence_put() so all those fences
> > got leaked. Also, in the krealloc_array failure case, we weren't
> > freeing the fences array. Instead, ensure that i and fences are always
> > zero-initialized and dma_fence_put() all the fences and kfree(fences) on
> > every error path.
> >
> > Signed-off-by: Jason Ekstrand
> > Fixes: a02b9dc90d84 ("dma-buf/sync_file: refactor fence storage in struct
> > sync_file")
> > Cc: Gustavo Padovan
> > Cc: Christian König
>
> Reviewed-by: Christian König
>
> > ---
> > drivers/dma-buf/sync_file.c | 13 +++--
> > 1 file changed, 7 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c
> > index 20d9bddbb985b..394e6e1e96860 100644
> > --- a/drivers/dma-buf/sync_file.c
> > +++ b/drivers/dma-buf/sync_file.c
> > @@ -211,8 +211,8 @@ static struct sync_file *sync_file_merge(const char
> > *name, struct sync_file *a,
> >struct sync_file *b)
> > {
> > struct sync_file *sync_file;
> > - struct dma_fence **fences, **nfences, **a_fences, **b_fences;
> > - int i, i_a, i_b, num_fences, a_num_fences, b_num_fences;
> > + struct dma_fence **fences = NULL, **nfences, **a_fences, **b_fences;
> > + int i = 0, i_a, i_b, num_fences, a_num_fences, b_num_fences;
> >
> > sync_file = sync_file_alloc();
> > if (!sync_file)
> > @@ -236,7 +236,7 @@ static struct sync_file *sync_file_merge(const char
> > *name, struct sync_file *a,
> >* If a sync_file can only be created with sync_file_merge
> >* and sync_file_create, this is a reasonable assumption.
> >*/
> > - for (i = i_a = i_b = 0; i_a < a_num_fences && i_b < b_num_fences; ) {
> > + for (i_a = i_b = 0; i_a < a_num_fences && i_b < b_num_fences; ) {
> > struct dma_fence *pt_a = a_fences[i_a];
> > struct dma_fence *pt_b = b_fences[i_b];
> >
> > @@ -277,15 +277,16 @@ static struct sync_file *sync_file_merge(const char
> > *name, struct sync_file *a,
> > fences = nfences;
> > }
> >
> > - if (sync_file_set_fence(sync_file, fences, i) < 0) {
> > - kfree(fences);
> > + if (sync_file_set_fence(sync_file, fences, i) < 0)
> > goto err;
> > - }
> >
> > strlcpy(sync_file->user_name, name, sizeof(sync_file->user_name));
> > return sync_file;
> >
> > err:
> > + while (i)
> > + dma_fence_put(fences[--i]);
> > + kfree(fences);
> > fput(sync_file->file);
> > return NULL;
> >
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/ttm, drm/i915: Update ttm_move_memcpy for async use
The buffer object argument to ttm_move_memcpy was only used to
determine whether the destination memory should be cleared only
or whether we should copy data. Replace it with a "clear" bool, and
update the callers.
The intention here is to be able to use ttm_move_memcpy() async under
a dma-fence as a fallback if an accelerated blit fails in a security-
critical path where data might leak if the blit is not properly
performed. For that purpose the bo is an unsuitable argument since
its relevant members might already have changed at call time.
Finally, update the ttm_move_memcpy kerneldoc that seems to have
ended up with a stale version.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 2 +-
drivers/gpu/drm/ttm/ttm_bo_util.c | 20 ++--
include/drm/ttm/ttm_bo_driver.h | 2 +-
3 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 4e529adcdfc7..f19847abe856 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -517,7 +517,7 @@ static void __i915_ttm_move(struct ttm_buffer_object *bo,
bool clear,
obj->ttm.cached_io_st,
src_reg->region.start);
- ttm_move_memcpy(bo, dst_mem->num_pages, dst_iter, src_iter);
+ ttm_move_memcpy(clear, dst_mem->num_pages, dst_iter, src_iter);
}
}
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 2f57f824e6db..e3747f069674 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -75,22 +75,21 @@ void ttm_mem_io_free(struct ttm_device *bdev,
/**
* ttm_move_memcpy - Helper to perform a memcpy ttm move operation.
- * @bo: The struct ttm_buffer_object.
- * @new_mem: The struct ttm_resource we're moving to (copy destination).
- * @new_iter: A struct ttm_kmap_iter representing the destination resource.
+ * @clear: Whether to clear rather than copy.
+ * @num_pages: Number of pages of the operation.
+ * @dst_iter: A struct ttm_kmap_iter representing the destination resource.
* @src_iter: A struct ttm_kmap_iter representing the source resource.
*
* This function is intended to be able to move out async under a
* dma-fence if desired.
*/
-void ttm_move_memcpy(struct ttm_buffer_object *bo,
+void ttm_move_memcpy(bool clear,
u32 num_pages,
struct ttm_kmap_iter *dst_iter,
struct ttm_kmap_iter *src_iter)
{
const struct ttm_kmap_iter_ops *dst_ops = dst_iter->ops;
const struct ttm_kmap_iter_ops *src_ops = src_iter->ops;
- struct ttm_tt *ttm = bo->ttm;
struct dma_buf_map src_map, dst_map;
pgoff_t i;
@@ -99,10 +98,7 @@ void ttm_move_memcpy(struct ttm_buffer_object *bo,
return;
/* Don't move nonexistent data. Clear destination instead. */
- if (src_ops->maps_tt && (!ttm || !ttm_tt_is_populated(ttm))) {
- if (ttm && !(ttm->page_flags & TTM_PAGE_FLAG_ZERO_ALLOC))
- return;
-
+ if (clear) {
for (i = 0; i < num_pages; ++i) {
dst_ops->map_local(dst_iter, _map, i);
if (dst_map.is_iomem)
@@ -146,6 +142,7 @@ int ttm_bo_move_memcpy(struct ttm_buffer_object *bo,
struct ttm_kmap_iter_linear_io io;
} _dst_iter, _src_iter;
struct ttm_kmap_iter *dst_iter, *src_iter;
+ bool clear;
int ret = 0;
if (ttm && ((ttm->page_flags & TTM_PAGE_FLAG_SWAPPED) ||
@@ -169,7 +166,10 @@ int ttm_bo_move_memcpy(struct ttm_buffer_object *bo,
goto out_src_iter;
}
- ttm_move_memcpy(bo, dst_mem->num_pages, dst_iter, src_iter);
+ clear = src_iter->ops->maps_tt && (!ttm || !ttm_tt_is_populated(ttm));
+ if (!(clear && ttm && !(ttm->page_flags & TTM_PAGE_FLAG_ZERO_ALLOC)))
+ ttm_move_memcpy(clear, dst_mem->num_pages, dst_iter, src_iter);
+
src_copy = *src_mem;
ttm_bo_move_sync_cleanup(bo, dst_mem);
diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index 68d6069572aa..5f087575194b 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -322,7 +322,7 @@ int ttm_bo_tt_bind(struct ttm_buffer_object *bo, struct
ttm_resource *mem);
*/
void ttm_bo_tt_destroy(struct ttm_buffer_object *bo);
-void ttm_move_memcpy(struct ttm_buffer_object *bo,
+void ttm_move_memcpy(bool clear,
u32 num_pages,
struct ttm_kmap_iter *dst_iter,
struct ttm_kmap_iter *src_iter);
--
2.31.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915/ttm: Reorganize the ttm move code somewhat
In order to make the code a bit more readable and to facilitate
async memcpy moves, reorganize the move code a little. Determine
at an early stage whether to copy or to clear.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 70 ++---
1 file changed, 40 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index c39d982c4fa6..4e529adcdfc7 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -431,6 +431,7 @@ i915_ttm_resource_get_st(struct drm_i915_gem_object *obj,
}
static int i915_ttm_accel_move(struct ttm_buffer_object *bo,
+ bool clear,
struct ttm_resource *dst_mem,
struct sg_table *dst_st)
{
@@ -449,13 +450,10 @@ static int i915_ttm_accel_move(struct ttm_buffer_object
*bo,
return -EINVAL;
dst_level = i915_ttm_cache_level(i915, dst_mem, ttm);
- if (!ttm || !ttm_tt_is_populated(ttm)) {
+ if (clear) {
if (bo->type == ttm_bo_type_kernel)
return -EINVAL;
- if (ttm && !(ttm->page_flags & TTM_PAGE_FLAG_ZERO_ALLOC))
- return 0;
-
intel_engine_pm_get(i915->gt.migrate.context->engine);
ret = intel_context_migrate_clear(i915->gt.migrate.context,
NULL,
dst_st->sgl, dst_level,
@@ -489,27 +487,53 @@ static int i915_ttm_accel_move(struct ttm_buffer_object
*bo,
return ret;
}
-static int i915_ttm_move(struct ttm_buffer_object *bo, bool evict,
-struct ttm_operation_ctx *ctx,
-struct ttm_resource *dst_mem,
-struct ttm_place *hop)
+static void __i915_ttm_move(struct ttm_buffer_object *bo, bool clear,
+ struct ttm_resource *dst_mem,
+ struct sg_table *dst_st)
{
struct drm_i915_gem_object *obj = i915_ttm_to_gem(bo);
- struct ttm_resource_manager *dst_man =
- ttm_manager_type(bo->bdev, dst_mem->mem_type);
struct intel_memory_region *dst_reg, *src_reg;
union {
struct ttm_kmap_iter_tt tt;
struct ttm_kmap_iter_iomap io;
} _dst_iter, _src_iter;
struct ttm_kmap_iter *dst_iter, *src_iter;
- struct sg_table *dst_st;
int ret;
dst_reg = i915_ttm_region(bo->bdev, dst_mem->mem_type);
src_reg = i915_ttm_region(bo->bdev, bo->resource->mem_type);
GEM_BUG_ON(!dst_reg || !src_reg);
+ ret = i915_ttm_accel_move(bo, clear, dst_mem, dst_st);
+ if (ret) {
+ dst_iter = !cpu_maps_iomem(dst_mem) ?
+ ttm_kmap_iter_tt_init(&_dst_iter.tt, bo->ttm) :
+ ttm_kmap_iter_iomap_init(&_dst_iter.io, _reg->iomap,
+dst_st, dst_reg->region.start);
+
+ src_iter = !cpu_maps_iomem(bo->resource) ?
+ ttm_kmap_iter_tt_init(&_src_iter.tt, bo->ttm) :
+ ttm_kmap_iter_iomap_init(&_src_iter.io, _reg->iomap,
+obj->ttm.cached_io_st,
+src_reg->region.start);
+
+ ttm_move_memcpy(bo, dst_mem->num_pages, dst_iter, src_iter);
+ }
+}
+
+static int i915_ttm_move(struct ttm_buffer_object *bo, bool evict,
+struct ttm_operation_ctx *ctx,
+struct ttm_resource *dst_mem,
+struct ttm_place *hop)
+{
+ struct drm_i915_gem_object *obj = i915_ttm_to_gem(bo);
+ struct ttm_resource_manager *dst_man =
+ ttm_manager_type(bo->bdev, dst_mem->mem_type);
+ struct ttm_tt *ttm = bo->ttm;
+ struct sg_table *dst_st;
+ bool clear;
+ int ret;
+
/* Sync for now. We could do the actual copy async. */
ret = ttm_bo_wait_ctx(bo, ctx);
if (ret)
@@ -526,9 +550,8 @@ static int i915_ttm_move(struct ttm_buffer_object *bo, bool
evict,
}
/* Populate ttm with pages if needed. Typically system memory. */
- if (bo->ttm && (dst_man->use_tt ||
- (bo->ttm->page_flags & TTM_PAGE_FLAG_SWAPPED))) {
- ret = ttm_tt_populate(bo->bdev, bo->ttm, ctx);
+ if (ttm && (dst_man->use_tt || (ttm->page_flags &
TTM_PAGE_FLAG_SWAPPED))) {
+ ret = ttm_tt_populate(bo->bdev, ttm, ctx);
if (ret)
return ret;
}
@@ -537,23 +560,10 @@ static int i915_ttm_move(struct ttm_buffer_object *bo,
bool evict,
if (IS_ERR(dst_st))
return PTR_ERR(dst_st);
- ret = i915_ttm_accel_move(bo, dst_mem, dst_st);
- if (ret) {
- /* If
[Intel-gfx] [PATCH 0/2] drm/i915, drm/ttm: Update the ttm_move_memcpy() interface
The ttm_move_memcpy() function was intended to be able to be used async under a fence. We are going to utilize that as a fallback if the gpu clearing blit fails before we set up CPU- or GPU ptes to the memory region. But to accomplish that the bo argument to ttm_move_memcpy() needs to be replaced. Patch 1 reorganizes the i915 ttm move code a bit to make the change in patch 2 smaller. Patch 2 updates the ttm_move_memcpy() interface. Thomas Hellström (2): drm/i915/ttm: Reorganize the ttm move code somewhat drm/ttm, drm/i915: Update ttm_move_memcpy for async use drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 70 ++--- drivers/gpu/drm/ttm/ttm_bo_util.c | 20 +++ include/drm/ttm/ttm_bo_driver.h | 2 +- 3 files changed, 51 insertions(+), 41 deletions(-) -- 2.31.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v14 06/12] swiotlb: Use is_swiotlb_force_bounce for swiotlb data bouncing
On Thu, Jun 24, 2021 at 11:58:57PM +0800, Claire Chang wrote: > On Thu, Jun 24, 2021 at 11:56 PM Konrad Rzeszutek Wilk > wrote: > > > > On Thu, Jun 24, 2021 at 10:10:51AM -0400, Qian Cai wrote: > > > > > > > > > On 6/24/2021 7:48 AM, Will Deacon wrote: > > > > Ok, diff below which attempts to tackle the offset issue I mentioned as > > > > well. Qian Cai -- please can you try with these changes? > > > > > > This works fine. > > > > Cool. Let me squash this patch in #6 and rebase the rest of them. > > > > Claire, could you check the devel/for-linus-5.14 say by end of today to > > double check that I didn't mess anything up please? > > I just submitted v15 here > (https://lore.kernel.org/patchwork/cover/1451322/) in case it's > helpful. Oh! Nice! > I'll double check of course. Thanks for the efforts! I ended up using your patch #6 and #7. Please double-check. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v15 00/12] Restricted DMA
On Thu, Jun 24, 2021 at 11:55:14PM +0800, Claire Chang wrote: > This series implements mitigations for lack of DMA access control on > systems without an IOMMU, which could result in the DMA accessing the > system memory at unexpected times and/or unexpected addresses, possibly > leading to data leakage or corruption. > > For example, we plan to use the PCI-e bus for Wi-Fi and that PCI-e bus is > not behind an IOMMU. As PCI-e, by design, gives the device full access to > system memory, a vulnerability in the Wi-Fi firmware could easily escalate > to a full system exploit (remote wifi exploits: [1a], [1b] that shows a > full chain of exploits; [2], [3]). > > To mitigate the security concerns, we introduce restricted DMA. Restricted > DMA utilizes the existing swiotlb to bounce streaming DMA in and out of a > specially allocated region and does memory allocation from the same region. > The feature on its own provides a basic level of protection against the DMA > overwriting buffer contents at unexpected times. However, to protect > against general data leakage and system memory corruption, the system needs > to provide a way to restrict the DMA to a predefined memory region (this is > usually done at firmware level, e.g. MPU in ATF on some ARM platforms [4]). > > [1a] > https://googleprojectzero.blogspot.com/2017/04/over-air-exploiting-broadcoms-wi-fi_4.html > [1b] > https://googleprojectzero.blogspot.com/2017/04/over-air-exploiting-broadcoms-wi-fi_11.html > [2] https://blade.tencent.com/en/advisories/qualpwn/ > [3] > https://www.bleepingcomputer.com/news/security/vulnerabilities-found-in-highly-popular-firmware-for-wifi-chips/ > [4] > https://github.com/ARM-software/arm-trusted-firmware/blob/master/plat/mediatek/mt8183/drivers/emi_mpu/emi_mpu.c#L132 > > v15: > - Apply Will's diff (https://lore.kernel.org/patchwork/patch/1448957/#1647521) > to fix the crash reported by Qian. > - Add Stefano's Acked-by tag for patch 01/12 from v14 That all should be now be on https://git.kernel.org/pub/scm/linux/kernel/git/konrad/swiotlb.git/ devel/for-linus-5.14 (and linux-next) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-misc-fixes
Hi Dave, Daniel, Here's this week drm-misc-fixes PR Thanks! Maxime drm-misc-fixes-2021-06-24: A DMA address check for nouveau, an error code return fix for kmb, fixes to wait for a moving fence after pinning the BO for amdgpu, nouveau and radeon, a crtc and async page flip fix for atmel-hlcdc and a cpu hang fix for vc4. The following changes since commit c336a5ee984708db4826ef9e47d184e638e29717: drm: Lock pointer access in drm_master_release() (2021-06-10 12:22:02 +0200) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2021-06-24 for you to fetch changes up to d330099115597bbc238d6758a4930e72b49ea9ba: drm/nouveau: fix dma_address check for CPU/GPU sync (2021-06-24 15:40:44 +0200) A DMA address check for nouveau, an error code return fix for kmb, fixes to wait for a moving fence after pinning the BO for amdgpu, nouveau and radeon, a crtc and async page flip fix for atmel-hlcdc and a cpu hang fix for vc4. Christian König (4): drm/nouveau: wait for moving fence after pinning v2 drm/radeon: wait for moving fence after pinning drm/amdgpu: wait for moving fence after pinning drm/nouveau: fix dma_address check for CPU/GPU sync Dan Sneddon (2): drm: atmel_hlcdc: Enable the crtc vblank prior to crtc usage. drm/atmel-hlcdc: Allow async page flips Daniel Vetter (1): Revert "drm: add a locked version of drm_is_current_master" Desmond Cheong Zhi Xi (1): drm: add a locked version of drm_is_current_master Krzysztof Kozlowski (1): drm/panel: ld9040: reference spi_device_id table Maxime Ripard (2): drm/vc4: hdmi: Move the HSM clock enable to runtime_pm drm/vc4: hdmi: Make sure the controller is powered in detect Zhen Lei (1): drm/kmb: Fix error return code in kmb_hw_init() drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c| 14 +++- drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 17 ++ drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 1 + drivers/gpu/drm/kmb/kmb_drv.c | 1 + drivers/gpu/drm/nouveau/nouveau_bo.c | 4 +-- drivers/gpu/drm/nouveau/nouveau_prime.c| 17 +- drivers/gpu/drm/panel/panel-samsung-ld9040.c | 1 + drivers/gpu/drm/radeon/radeon_prime.c | 14 ++-- drivers/gpu/drm/vc4/vc4_hdmi.c | 44 -- 9 files changed, 90 insertions(+), 23 deletions(-) signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/4] drm/i915/gem: Migrate to system at dma-buf map time
Until we support p2p dma or as a complement to that, migrate data to system memory at dma-buf map time if possible. Signed-off-by: Thomas Hellström --- drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c index 616c3a2f1baf..a52f885bc09a 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c @@ -25,7 +25,14 @@ static struct sg_table *i915_gem_map_dma_buf(struct dma_buf_attachment *attachme struct scatterlist *src, *dst; int ret, i; - ret = i915_gem_object_pin_pages_unlocked(obj); + ret = i915_gem_object_lock_interruptible(obj, NULL); + if (ret) + return ERR_PTR(ret); + + ret = i915_gem_object_migrate(obj, NULL, INTEL_REGION_SMEM); + if (!ret) + ret = i915_gem_object_pin_pages(obj); + i915_gem_object_unlock(obj); if (ret) goto err; -- 2.31.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/4] drm/i915/gem: Introduce a selftest for the gem object migrate functionality
From: Matthew Auld
A selftest for the gem object migrate functionality. Slightly adapted
from the original by Matthew to the new interface and new fill blit
code.
Co-developed-by: Thomas Hellström
Signed-off-by: Thomas Hellström
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_object.c| 1 +
.../drm/i915/gem/selftests/i915_gem_migrate.c | 237 ++
.../drm/i915/selftests/i915_live_selftests.h | 1 +
3 files changed, 239 insertions(+)
create mode 100644 drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 6421c3a8b2f3..24f4395bf387 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -644,6 +644,7 @@ static const struct drm_gem_object_funcs
i915_gem_object_funcs = {
#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
#include "selftests/huge_gem_object.c"
#include "selftests/huge_pages.c"
+#include "selftests/i915_gem_migrate.c"
#include "selftests/i915_gem_object.c"
#include "selftests/i915_gem_coherency.c"
#endif
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c
new file mode 100644
index ..a437b66f64d9
--- /dev/null
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c
@@ -0,0 +1,237 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2020-2021 Intel Corporation
+ */
+
+#include "gt/intel_migrate.h"
+
+static int igt_smem_create_migrate(void *arg)
+{
+ struct intel_gt *gt = arg;
+ struct drm_i915_private *i915 = gt->i915;
+ struct drm_i915_gem_object *obj;
+ struct i915_gem_ww_ctx ww;
+ int err = 0;
+
+ /* Switch object backing-store on create */
+ obj = i915_gem_object_create_lmem(i915, PAGE_SIZE, 0);
+ if (IS_ERR(obj))
+ return PTR_ERR(obj);
+
+ for_i915_gem_ww(, err, true) {
+ err = i915_gem_object_lock(obj, );
+ if (err)
+ continue;
+
+ if (!i915_gem_object_can_migrate(obj, INTEL_REGION_SMEM)) {
+ err = -EINVAL;
+ continue;
+ }
+
+ err = i915_gem_object_migrate(obj, , INTEL_REGION_SMEM);
+ if (err)
+ continue;
+
+ err = i915_gem_object_pin_pages(obj);
+ if (err)
+ continue;
+
+ if (i915_gem_object_can_migrate(obj, INTEL_REGION_LMEM))
+ err = -EINVAL;
+
+ i915_gem_object_unpin_pages(obj);
+ }
+ i915_gem_object_put(obj);
+
+ return err;
+}
+
+static int igt_lmem_create_migrate(void *arg)
+{
+ struct intel_gt *gt = arg;
+ struct drm_i915_private *i915 = gt->i915;
+ struct drm_i915_gem_object *obj;
+ struct i915_gem_ww_ctx ww;
+ int err = 0;
+
+ /* Switch object backing-store on create */
+ obj = i915_gem_object_create_shmem(i915, PAGE_SIZE);
+ if (IS_ERR(obj))
+ return PTR_ERR(obj);
+
+ for_i915_gem_ww(, err, true) {
+ err = i915_gem_object_lock(obj, );
+ if (err)
+ continue;
+
+ if (!i915_gem_object_can_migrate(obj, INTEL_REGION_LMEM)) {
+ err = -EINVAL;
+ continue;
+ }
+
+ err = i915_gem_object_migrate(obj, , INTEL_REGION_LMEM);
+ if (err)
+ continue;
+
+ err = i915_gem_object_pin_pages(obj);
+ if (err)
+ continue;
+
+ if (i915_gem_object_can_migrate(obj, INTEL_REGION_SMEM))
+ err = -EINVAL;
+
+ i915_gem_object_unpin_pages(obj);
+ }
+ i915_gem_object_put(obj);
+
+ return err;
+}
+
+static int lmem_pages_migrate_one(struct i915_gem_ww_ctx *ww,
+ struct drm_i915_gem_object *obj)
+{
+ int err;
+
+ err = i915_gem_object_lock(obj, ww);
+ if (err)
+ return err;
+
+ err = i915_gem_object_wait(obj,
+ I915_WAIT_INTERRUPTIBLE |
+ I915_WAIT_PRIORITY |
+ I915_WAIT_ALL,
+ MAX_SCHEDULE_TIMEOUT);
+ if (err)
+ return err;
+
+ if (i915_gem_object_is_lmem(obj)) {
+ if (!i915_gem_object_can_migrate(obj, INTEL_REGION_SMEM)) {
+ pr_err("object can't migrate to smem.\n");
+ return -EINVAL;
+ }
+
+ err = i915_gem_object_migrate(obj, ww, INTEL_REGION_SMEM);
+ if (err) {
+ pr_err("Object failed migration to smem\n");
+ if (err)
+
[Intel-gfx] [PATCH 3/4] drm/i915/display: Migrate objects to LMEM if possible for display
Objects intended to be used as display framebuffers must reside in
LMEM for discrete. If they happen to not do that, migrate them to
LMEM before pinning.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/display/intel_display.c | 5 -
drivers/gpu/drm/i915/gem/i915_gem_domain.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_lmem.c | 21
drivers/gpu/drm/i915/gem/i915_gem_object.h | 2 --
4 files changed, 5 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 4524dbfa5e42..83a4aba54d67 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -1331,6 +1331,9 @@ intel_pin_and_fence_fb_obj(struct drm_framebuffer *fb,
ret = i915_gem_object_lock(obj, );
if (!ret && phys_cursor)
ret = i915_gem_object_attach_phys(obj, alignment);
+ else if (!ret && HAS_LMEM(dev_priv))
+ ret = i915_gem_object_migrate(obj, , INTEL_REGION_LMEM);
+ /* TODO: Do we need to sync when migration becomes async? */
if (!ret)
ret = i915_gem_object_pin_pages(obj);
if (ret)
@@ -11770,7 +11773,7 @@ intel_user_framebuffer_create(struct drm_device *dev,
/* object is backed with LMEM for discrete */
i915 = to_i915(obj->base.dev);
- if (HAS_LMEM(i915) && !i915_gem_object_validates_to_lmem(obj)) {
+ if (HAS_LMEM(i915) && !i915_gem_object_can_migrate(obj,
INTEL_REGION_LMEM)) {
/* object is "remote", not in local memory */
i915_gem_object_put(obj);
return ERR_PTR(-EREMOTE);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
index 073822100da7..7d1400b13429 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
@@ -375,7 +375,7 @@ i915_gem_object_pin_to_display_plane(struct
drm_i915_gem_object *obj,
struct i915_vma *vma;
int ret;
- /* Frame buffer must be in LMEM (no migration yet) */
+ /* Frame buffer must be in LMEM */
if (HAS_LMEM(i915) && !i915_gem_object_is_lmem(obj))
return ERR_PTR(-EINVAL);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
index 41d5182cd367..be1d122574af 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
@@ -23,27 +23,6 @@ i915_gem_object_lmem_io_map(struct drm_i915_gem_object *obj,
return io_mapping_map_wc(>mm.region->iomap, offset, size);
}
-/**
- * i915_gem_object_validates_to_lmem - Whether the object is resident in
- * lmem when pages are present.
- * @obj: The object to check.
- *
- * Migratable objects residency may change from under us if the object is
- * not pinned or locked. This function is intended to be used to check whether
- * the object can only reside in lmem when pages are present.
- *
- * Return: Whether the object is always resident in lmem when pages are
- * present.
- */
-bool i915_gem_object_validates_to_lmem(struct drm_i915_gem_object *obj)
-{
- struct intel_memory_region *mr = READ_ONCE(obj->mm.region);
-
- return !i915_gem_object_migratable(obj) &&
- mr && (mr->type == INTEL_MEMORY_LOCAL ||
- mr->type == INTEL_MEMORY_STOLEN_LOCAL);
-}
-
/**
* i915_gem_object_is_lmem - Whether the object is resident in
* lmem
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index 8cbd7a5334e2..d423d8cac4f2 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -597,8 +597,6 @@ bool i915_gem_object_evictable(struct drm_i915_gem_object
*obj);
bool i915_gem_object_migratable(struct drm_i915_gem_object *obj);
-bool i915_gem_object_validates_to_lmem(struct drm_i915_gem_object *obj);
-
int i915_gem_object_migrate(struct drm_i915_gem_object *obj,
struct i915_gem_ww_ctx *ww,
enum intel_region_id id);
--
2.31.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/4] drm/i915/gem: Implement object migration
Introduce an interface to migrate objects between regions.
This is primarily intended to migrate objects to LMEM for display and
to SYSTEM for dma-buf, but might be reused in one form or another for
performande-based migration.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_object.c| 91 +++
drivers/gpu/drm/i915/gem/i915_gem_object.h| 12 +++
.../gpu/drm/i915/gem/i915_gem_object_types.h | 9 ++
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 69 ++
drivers/gpu/drm/i915/gem/i915_gem_wait.c | 19
5 files changed, 183 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 07e8ff9a8aae..6421c3a8b2f3 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -513,6 +513,97 @@ bool i915_gem_object_has_iomem(const struct
drm_i915_gem_object *obj)
return obj->mem_flags & I915_BO_FLAG_IOMEM;
}
+/**
+ * i915_gem_object_can_migrate - Whether an object likely can be migrated
+ *
+ * @obj: The object to migrate
+ * @id: The region intended to migrate to
+ *
+ * Check whether the object backend supports migration to the
+ * given region. Note that pinning may affect the ability to migrate.
+ *
+ * Return: true if migration is possible, false otherwise.
+ */
+bool i915_gem_object_can_migrate(struct drm_i915_gem_object *obj,
+enum intel_region_id id)
+{
+ struct drm_i915_private *i915 = to_i915(obj->base.dev);
+ unsigned int num_allowed = obj->mm.n_placements;
+ struct intel_memory_region *mr;
+ unsigned int i;
+
+ GEM_BUG_ON(id >= INTEL_REGION_UNKNOWN);
+ GEM_BUG_ON(obj->mm.madv != I915_MADV_WILLNEED);
+
+ if (!obj->ops->migrate)
+ return -EOPNOTSUPP;
+
+ mr = i915->mm.regions[id];
+ if (obj->mm.region == mr)
+ return true;
+
+ if (!i915_gem_object_evictable(obj))
+ return false;
+
+ if (!(obj->flags & I915_BO_ALLOC_USER))
+ return true;
+
+ if (num_allowed == 0)
+ return false;
+
+ for (i = 0; i < num_allowed; ++i) {
+ if (mr == obj->mm.placements[i])
+ return true;
+ }
+
+ return false;
+}
+
+/**
+ * i915_gem_object_migrate - Migrate an object to the desired region id
+ * @obj: The object to migrate.
+ * @ww: An optional struct i915_gem_ww_ctx. If NULL, the backend may
+ * not be successful in evicting other objects to make room for this object.
+ * @id: The region id to migrate to.
+ *
+ * Attempt to migrate the object to the desired memory region. The
+ * object backend must support migration and the object may not be
+ * pinned, (explicitly pinned pages or pinned vmas). The object must
+ * be locked.
+ * On successful completion, the object will have pages pointing to
+ * memory in the new region, but an async migration task may not have
+ * completed yet, and to accomplish that, i915_gem_object_wait_migration()
+ * must be called.
+ *
+ * Return: 0 on success. Negative error code on failure. In particular may
+ * return -ENXIO on lack of region space, -EDEADLK for deadlock avoidance
+ * if @ww is set, -EINTR or -ERESTARTSYS if signal pending, and
+ * -EBUSY if the object is pinned.
+ */
+int i915_gem_object_migrate(struct drm_i915_gem_object *obj,
+ struct i915_gem_ww_ctx *ww,
+ enum intel_region_id id)
+{
+ struct drm_i915_private *i915 = to_i915(obj->base.dev);
+ struct intel_memory_region *mr;
+
+ GEM_BUG_ON(id >= INTEL_REGION_UNKNOWN);
+ GEM_BUG_ON(obj->mm.madv != I915_MADV_WILLNEED);
+ assert_object_held(obj);
+
+ mr = i915->mm.regions[id];
+ if (obj->mm.region == mr)
+ return 0;
+
+ if (!i915_gem_object_evictable(obj))
+ return -EBUSY;
+
+ if (!obj->ops->migrate)
+ return -EOPNOTSUPP;
+
+ return obj->ops->migrate(obj, mr);
+}
+
void i915_gem_init__objects(struct drm_i915_private *i915)
{
INIT_WORK(>mm.free_work, __i915_gem_free_work);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index ea3224a480c4..8cbd7a5334e2 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -17,6 +17,8 @@
#include "i915_gem_ww.h"
#include "i915_vma_types.h"
+enum intel_region_id;
+
/*
* XXX: There is a prevalence of the assumption that we fit the
* object's page count inside a 32bit _signed_ variable. Let's document
@@ -597,6 +599,16 @@ bool i915_gem_object_migratable(struct drm_i915_gem_object
*obj);
bool i915_gem_object_validates_to_lmem(struct drm_i915_gem_object *obj);
+int i915_gem_object_migrate(struct drm_i915_gem_object *obj,
+ struct i915_gem_ww_ctx *ww,
+
[Intel-gfx] [PATCH 0/4] drm/i915/gem: Introduce a migrate interface
We want to be able to explicitly migrate objects between gem memory regions, initially for display and dma-buf, but there might be more use-cases coming up. Introduce a gem migrate interface, add a selftest and use it for display fb pinning and dma-buf mapping. This series should make the desktop light up on DG1 with DG1-enabled mesa. Matthew Auld (1): drm/i915/gem: Introduce a selftest for the gem object migrate functionality Thomas Hellström (3): drm/i915/gem: Implement object migration drm/i915/display: Migrate objects to LMEM if possible for display drm/i915/gem: Migrate to system at dma-buf map time drivers/gpu/drm/i915/display/intel_display.c | 5 +- drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 9 +- drivers/gpu/drm/i915/gem/i915_gem_domain.c| 2 +- drivers/gpu/drm/i915/gem/i915_gem_lmem.c | 21 -- drivers/gpu/drm/i915/gem/i915_gem_object.c| 92 +++ drivers/gpu/drm/i915/gem/i915_gem_object.h| 12 +- .../gpu/drm/i915/gem/i915_gem_object_types.h | 9 + drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 69 +++-- drivers/gpu/drm/i915/gem/i915_gem_wait.c | 19 ++ .../drm/i915/gem/selftests/i915_gem_migrate.c | 237 ++ .../drm/i915/selftests/i915_live_selftests.h | 1 + 11 files changed, 434 insertions(+), 42 deletions(-) create mode 100644 drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c -- 2.31.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] dma-buf/sync_file: Don't leak fences on merge failure
Each add_fence() call does a dma_fence_get() on the relevant fence. In
the error path, we weren't calling dma_fence_put() so all those fences
got leaked. Also, in the krealloc_array failure case, we weren't
freeing the fences array. Instead, ensure that i and fences are always
zero-initialized and dma_fence_put() all the fences and kfree(fences) on
every error path.
Signed-off-by: Jason Ekstrand
Fixes: a02b9dc90d84 ("dma-buf/sync_file: refactor fence storage in struct
sync_file")
Cc: Gustavo Padovan
Cc: Christian König
---
drivers/dma-buf/sync_file.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c
index 20d9bddbb985b..394e6e1e96860 100644
--- a/drivers/dma-buf/sync_file.c
+++ b/drivers/dma-buf/sync_file.c
@@ -211,8 +211,8 @@ static struct sync_file *sync_file_merge(const char *name,
struct sync_file *a,
struct sync_file *b)
{
struct sync_file *sync_file;
- struct dma_fence **fences, **nfences, **a_fences, **b_fences;
- int i, i_a, i_b, num_fences, a_num_fences, b_num_fences;
+ struct dma_fence **fences = NULL, **nfences, **a_fences, **b_fences;
+ int i = 0, i_a, i_b, num_fences, a_num_fences, b_num_fences;
sync_file = sync_file_alloc();
if (!sync_file)
@@ -236,7 +236,7 @@ static struct sync_file *sync_file_merge(const char *name,
struct sync_file *a,
* If a sync_file can only be created with sync_file_merge
* and sync_file_create, this is a reasonable assumption.
*/
- for (i = i_a = i_b = 0; i_a < a_num_fences && i_b < b_num_fences; ) {
+ for (i_a = i_b = 0; i_a < a_num_fences && i_b < b_num_fences; ) {
struct dma_fence *pt_a = a_fences[i_a];
struct dma_fence *pt_b = b_fences[i_b];
@@ -277,15 +277,16 @@ static struct sync_file *sync_file_merge(const char
*name, struct sync_file *a,
fences = nfences;
}
- if (sync_file_set_fence(sync_file, fences, i) < 0) {
- kfree(fences);
+ if (sync_file_set_fence(sync_file, fences, i) < 0)
goto err;
- }
strlcpy(sync_file->user_name, name, sizeof(sync_file->user_name));
return sync_file;
err:
+ while (i)
+ dma_fence_put(fences[--i]);
+ kfree(fences);
fput(sync_file->file);
return NULL;
--
2.31.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 14/15] drm/gem: Tiny kernel clarification for drm_gem_fence_array_add
Am 24.06.21 um 15:41 schrieb Daniel Vetter: On Thu, Jun 24, 2021 at 03:35:19PM +0200, Christian König wrote: Am 24.06.21 um 15:32 schrieb Daniel Vetter: On Thu, Jun 24, 2021 at 02:48:54PM +0200, Christian König wrote: Am 24.06.21 um 14:41 schrieb Daniel Vetter: On Wed, Jun 23, 2021 at 10:42:50AM +0200, Christian König wrote: Am 22.06.21 um 18:55 schrieb Daniel Vetter: Spotted while trying to convert panfrost to these. Signed-off-by: Daniel Vetter Cc: "Christian König" Cc: Lucas Stach Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Thomas Zimmermann Cc: David Airlie Cc: Daniel Vetter --- drivers/gpu/drm/drm_gem.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c index ba2e64ed8b47..68deb1de8235 100644 --- a/drivers/gpu/drm/drm_gem.c +++ b/drivers/gpu/drm/drm_gem.c @@ -1302,6 +1302,9 @@ EXPORT_SYMBOL(drm_gem_unlock_reservations); * @fence_array: array of dma_fence * for the job to block on. * @fence: the dma_fence to add to the list of dependencies. * + * This functions consumes the reference for @fence both on success and error + * cases. + * Oh, the later is a bit ugly I think. But good to know. Reviewed-by: Christian König Merged to drm-misc-next, thanks for taking a look. Can you perhaps take a look at the drm/armada patch too, then I think I have reviews/acks for all of them? What are you talking about? I only see drm/armada patches for the irq stuff Thomas is working on. There was one in this series, but Maxime was quicker. I'm going to apply all the remaining ones now. After that I'll send out a patch set to add some dependency tracking to drm_sched_job so that there's not so much copypasta going on there. I stumbled over that when reviewing how we handle dependencies. Do you mean a common container for dma_fence objects a drm_sched_job depends on? Yup. Well the real usefulness is the interfaces, so that you can just grep for those when trying to figure out htf a driver handles its implicit dependencies. And amdgpu is unfortunately going to be a bit in the cold because it's special (but should be able to benefit too, just more than 1-2 patches to convert it over). I had that on the TODO list for quite a while as well. Essentially extracting what the dma_resv_list object is doing into a new object (but maybe without RCU). Christian. Anyway I'm going to type the cover letter rsn. -Daniel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 05/47] drm/i915/guc: Add stall timer to non blocking CTB send function
On 24.06.2021 09:04, Matthew Brost wrote:
> Implement a stall timer which fails H2G CTBs once a period of time
> with no forward progress is reached to prevent deadlock.
>
> Also update to ct_write to return -EIO rather than -EPIPE on a
> corrupted descriptor.
by doing so you will have the same error code for two different problems:
a) corrupted CTB descriptor (definitely unrecoverable)
b) long stall in CTB processing (still recoverable)
while caller is explicitly instructed to retry only on:
c) temporary stall in CTB processing (likely recoverable)
so why do we want to limit our diagnostics?
>
> Signed-off-by: John Harrison
> Signed-off-by: Daniele Ceraolo Spurio
> Signed-off-by: Matthew Brost
> ---
> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 47 +--
> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h | 4 ++
> 2 files changed, 48 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> index c9a65d05911f..27ec30b5ef47 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> @@ -319,6 +319,7 @@ int intel_guc_ct_enable(struct intel_guc_ct *ct)
> goto err_deregister;
>
> ct->enabled = true;
> + ct->stall_time = KTIME_MAX;
>
> return 0;
>
> @@ -392,7 +393,7 @@ static int ct_write(struct intel_guc_ct *ct,
> unsigned int i;
>
> if (unlikely(ctb->broken))
> - return -EPIPE;
> + return -EIO;
>
> if (unlikely(desc->status))
> goto corrupted;
> @@ -464,7 +465,7 @@ static int ct_write(struct intel_guc_ct *ct,
> CT_ERROR(ct, "Corrupted descriptor head=%u tail=%u status=%#x\n",
>desc->head, desc->tail, desc->status);
> ctb->broken = true;
> - return -EPIPE;
> + return -EIO;
> }
>
> /**
> @@ -507,6 +508,18 @@ static int wait_for_ct_request_update(struct ct_request
> *req, u32 *status)
> return err;
> }
>
> +#define GUC_CTB_TIMEOUT_MS 1500
it's 150% of core CTB timeout, maybe we should correlate them ?
> +static inline bool ct_deadlocked(struct intel_guc_ct *ct)
> +{
> + long timeout = GUC_CTB_TIMEOUT_MS;
> + bool ret = ktime_ms_delta(ktime_get(), ct->stall_time) > timeout;
> +
> + if (unlikely(ret))
> + CT_ERROR(ct, "CT deadlocked\n");
nit: in commit message you said all these changes are to "prevent
deadlock" so maybe this message should rather be:
int delta = ktime_ms_delta(ktime_get(), ct->stall_time);
CT_ERROR(ct, "Communication stalled for %dms\n", delta);
(note that CT_ERROR already adds "CT" prefix)
> +
> + return ret;
> +}
> +
> static inline bool h2g_has_room(struct intel_guc_ct_buffer *ctb, u32 len_dw)
> {
> struct guc_ct_buffer_desc *desc = ctb->desc;
> @@ -518,6 +531,26 @@ static inline bool h2g_has_room(struct
> intel_guc_ct_buffer *ctb, u32 len_dw)
> return space >= len_dw;
> }
>
> +static int has_room_nb(struct intel_guc_ct *ct, u32 len_dw)
> +{
> + struct intel_guc_ct_buffer *ctb = >ctbs.send;
> +
> + lockdep_assert_held(>ctbs.send.lock);
> +
> + if (unlikely(!h2g_has_room(ctb, len_dw))) {
> + if (ct->stall_time == KTIME_MAX)
> + ct->stall_time = ktime_get();
> +
> + if (unlikely(ct_deadlocked(ct)))
and maybe above message should be printed somewhere around here when we
detect "deadlock" for the first time?
> + return -EIO;
> + else
> + return -EBUSY;
> + }
> +
> + ct->stall_time = KTIME_MAX;
> + return 0;
> +}
> +
> static int ct_send_nb(struct intel_guc_ct *ct,
> const u32 *action,
> u32 len,
> @@ -530,7 +563,7 @@ static int ct_send_nb(struct intel_guc_ct *ct,
>
> spin_lock_irqsave(>lock, spin_flags);
>
> - ret = h2g_has_room(ctb, len + 1);
> + ret = has_room_nb(ct, len + 1);
> if (unlikely(ret))
> goto out;
>
> @@ -574,11 +607,19 @@ static int ct_send(struct intel_guc_ct *ct,
> retry:
> spin_lock_irqsave(>ctbs.send.lock, flags);
> if (unlikely(!h2g_has_room(ctb, len + 1))) {
> + if (ct->stall_time == KTIME_MAX)
> + ct->stall_time = ktime_get();
as this is a repeated pattern, maybe it should be moved to h2g_has_room
or other wrapper ?
> spin_unlock_irqrestore(>ctbs.send.lock, flags);
> +
> + if (unlikely(ct_deadlocked(ct)))
> + return -EIO;
> +
> cond_resched();
> goto retry;
> }
>
> + ct->stall_time = KTIME_MAX;
this one too
> +
> fence = ct_get_next_fence(ct);
> request.fence = fence;
> request.status = 0;
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
> index eb69263324ba..55ef7c52472f 100644
> ---
Re: [Intel-gfx] [PATCH 14/15] drm/gem: Tiny kernel clarification for drm_gem_fence_array_add
Am 24.06.21 um 15:32 schrieb Daniel Vetter: On Thu, Jun 24, 2021 at 02:48:54PM +0200, Christian König wrote: Am 24.06.21 um 14:41 schrieb Daniel Vetter: On Wed, Jun 23, 2021 at 10:42:50AM +0200, Christian König wrote: Am 22.06.21 um 18:55 schrieb Daniel Vetter: Spotted while trying to convert panfrost to these. Signed-off-by: Daniel Vetter Cc: "Christian König" Cc: Lucas Stach Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Thomas Zimmermann Cc: David Airlie Cc: Daniel Vetter --- drivers/gpu/drm/drm_gem.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c index ba2e64ed8b47..68deb1de8235 100644 --- a/drivers/gpu/drm/drm_gem.c +++ b/drivers/gpu/drm/drm_gem.c @@ -1302,6 +1302,9 @@ EXPORT_SYMBOL(drm_gem_unlock_reservations); * @fence_array: array of dma_fence * for the job to block on. * @fence: the dma_fence to add to the list of dependencies. * + * This functions consumes the reference for @fence both on success and error + * cases. + * Oh, the later is a bit ugly I think. But good to know. Reviewed-by: Christian König Merged to drm-misc-next, thanks for taking a look. Can you perhaps take a look at the drm/armada patch too, then I think I have reviews/acks for all of them? What are you talking about? I only see drm/armada patches for the irq stuff Thomas is working on. There was one in this series, but Maxime was quicker. I'm going to apply all the remaining ones now. After that I'll send out a patch set to add some dependency tracking to drm_sched_job so that there's not so much copypasta going on there. I stumbled over that when reviewing how we handle dependencies. Do you mean a common container for dma_fence objects a drm_sched_job depends on? Thanks, Christian. -Daniel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 36/97] drm/i915/guc: Add non blocking CTB send function
On Thu, Jun 24, 2021 at 09:38:33AM -0700, Matthew Brost wrote:
> On Thu, Jun 10, 2021 at 05:27:48PM +0200, Daniel Vetter wrote:
> > On Wed, Jun 09, 2021 at 04:10:23PM -0700, Matthew Brost wrote:
> > > On Tue, Jun 08, 2021 at 10:46:15AM +0200, Daniel Vetter wrote:
> > > > On Tue, Jun 8, 2021 at 10:39 AM Tvrtko Ursulin
> > > > wrote:
> > > > >
> > > > >
> > > > > On 07/06/2021 18:31, Matthew Brost wrote:
> > > > > > On Thu, May 27, 2021 at 04:11:50PM +0100, Tvrtko Ursulin wrote:
> > > > > >>
> > > > > >> On 27/05/2021 15:35, Matthew Brost wrote:
> > > > > >>> On Thu, May 27, 2021 at 11:02:24AM +0100, Tvrtko Ursulin wrote:
> > > > >
> > > > > On 26/05/2021 19:10, Matthew Brost wrote:
> > > > >
> > > > > [snip]
> > > > >
> > > > > > +static int ct_send_nb(struct intel_guc_ct *ct,
> > > > > > + const u32 *action,
> > > > > > + u32 len,
> > > > > > + u32 flags)
> > > > > > +{
> > > > > > + struct intel_guc_ct_buffer *ctb = >ctbs.send;
> > > > > > + unsigned long spin_flags;
> > > > > > + u32 fence;
> > > > > > + int ret;
> > > > > > +
> > > > > > + spin_lock_irqsave(>lock, spin_flags);
> > > > > > +
> > > > > > + ret = ctb_has_room(ctb, len + 1);
> > > > > > + if (unlikely(ret))
> > > > > > + goto out;
> > > > > > +
> > > > > > + fence = ct_get_next_fence(ct);
> > > > > > + ret = ct_write(ct, action, len, fence, flags);
> > > > > > + if (unlikely(ret))
> > > > > > + goto out;
> > > > > > +
> > > > > > + intel_guc_notify(ct_to_guc(ct));
> > > > > > +
> > > > > > +out:
> > > > > > + spin_unlock_irqrestore(>lock, spin_flags);
> > > > > > +
> > > > > > + return ret;
> > > > > > +}
> > > > > > +
> > > > > > static int ct_send(struct intel_guc_ct *ct,
> > > > > > const u32 *action,
> > > > > > u32 len,
> > > > > > @@ -473,6 +541,7 @@ static int ct_send(struct intel_guc_ct
> > > > > > *ct,
> > > > > > u32 response_buf_size,
> > > > > > u32 *status)
> > > > > > {
> > > > > > + struct intel_guc_ct_buffer *ctb = >ctbs.send;
> > > > > > struct ct_request request;
> > > > > > unsigned long flags;
> > > > > > u32 fence;
> > > > > > @@ -482,8 +551,20 @@ static int ct_send(struct intel_guc_ct
> > > > > > *ct,
> > > > > > GEM_BUG_ON(!len);
> > > > > > GEM_BUG_ON(len & ~GUC_CT_MSG_LEN_MASK);
> > > > > > GEM_BUG_ON(!response_buf &&
> > > > > > response_buf_size);
> > > > > > + might_sleep();
> > > > >
> > > > > Sleep is just cond_resched below or there is more?
> > > > >
> > > > > >>>
> > > > > >>> Yes, the cond_resched.
> > > > > >>>
> > > > > > + /*
> > > > > > + * We use a lazy spin wait loop here as we believe
> > > > > > that if the CT
> > > > > > + * buffers are sized correctly the flow control
> > > > > > condition should be
> > > > > > + * rare.
> > > > > > + */
> > > > > > +retry:
> > > > > > spin_lock_irqsave(>ctbs.send.lock, flags);
> > > > > > + if (unlikely(!ctb_has_room(ctb, len + 1))) {
> > > > > > + spin_unlock_irqrestore(>ctbs.send.lock,
> > > > > > flags);
> > > > > > + cond_resched();
> > > > > > + goto retry;
> > > > > > + }
> > > > >
> > > > > If this patch is about adding a non-blocking send function,
> > > > > and below we can
> > > > > see that it creates a fork:
> > > > >
> > > > > intel_guc_ct_send:
> > > > > ...
> > > > > if (flags & INTEL_GUC_SEND_NB)
> > > > > return ct_send_nb(ct, action, len, flags);
> > > > >
> > > > > ret = ct_send(ct, action, len, response_buf,
> > > > > response_buf_size, );
> > > > >
> > > > > Then why is there a change in ct_send here, which is not the
> > > > > new
> > > > > non-blocking path?
> > > > >
> > > > > >>>
> > > > > >>> There is not a change to ct_send(), just to intel_guc_ct_send.
> > > > > >>
> > > > > >> I was doing by the diff which says:
> > > > > >>
> > > > > >> static int ct_send(struct intel_guc_ct *ct,
> > > > > >> const u32 *action,
> > > > > >>
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/display: Fix state mismatch in drm infoframe (rev5)
== Series Details == Series: drm/i915/display: Fix state mismatch in drm infoframe (rev5) URL : https://patchwork.freedesktop.org/series/89225/ State : success == Summary == CI Bug Log - changes from CI_DRM_10274_full -> Patchwork_20453_full Summary --- **WARNING** Minor unknown changes coming with Patchwork_20453_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_20453_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_20453_full: ### IGT changes ### Warnings * igt@kms_psr2_sf@plane-move-sf-dmg-area-3: - shard-iclb: [SKIP][1] ([i915#658]) -> [SKIP][2] +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10274/shard-iclb8/igt@kms_psr2...@plane-move-sf-dmg-area-3.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20453/shard-iclb2/igt@kms_psr2...@plane-move-sf-dmg-area-3.html Known issues Here are the changes found in Patchwork_20453_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_create@create-clear: - shard-glk: [PASS][3] -> [FAIL][4] ([i915#1888] / [i915#3160]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10274/shard-glk4/igt@gem_cre...@create-clear.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20453/shard-glk1/igt@gem_cre...@create-clear.html - shard-skl: [PASS][5] -> [FAIL][6] ([i915#3160]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10274/shard-skl9/igt@gem_cre...@create-clear.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20453/shard-skl8/igt@gem_cre...@create-clear.html * igt@gem_create@create-massive: - shard-kbl: NOTRUN -> [DMESG-WARN][7] ([i915#3002]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20453/shard-kbl2/igt@gem_cre...@create-massive.html - shard-apl: NOTRUN -> [DMESG-WARN][8] ([i915#3002]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20453/shard-apl1/igt@gem_cre...@create-massive.html * igt@gem_ctx_isolation@preservation-s3@rcs0: - shard-kbl: [PASS][9] -> [INCOMPLETE][10] ([i915#794]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10274/shard-kbl6/igt@gem_ctx_isolation@preservation...@rcs0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20453/shard-kbl3/igt@gem_ctx_isolation@preservation...@rcs0.html * igt@gem_ctx_persistence@engines-hostile-preempt: - shard-snb: NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#1099]) +2 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20453/shard-snb6/igt@gem_ctx_persiste...@engines-hostile-preempt.html * igt@gem_exec_fair@basic-deadline: - shard-apl: NOTRUN -> [FAIL][12] ([i915#2846]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20453/shard-apl1/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-none-rrul@rcs0: - shard-kbl: [PASS][13] -> [FAIL][14] ([i915#2842]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10274/shard-kbl4/igt@gem_exec_fair@basic-none-r...@rcs0.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20453/shard-kbl3/igt@gem_exec_fair@basic-none-r...@rcs0.html * igt@gem_exec_fair@basic-none-share@rcs0: - shard-tglb: [PASS][15] -> [FAIL][16] ([i915#2842]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10274/shard-tglb2/igt@gem_exec_fair@basic-none-sh...@rcs0.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20453/shard-tglb7/igt@gem_exec_fair@basic-none-sh...@rcs0.html * igt@gem_exec_fair@basic-none-solo@rcs0: - shard-kbl: NOTRUN -> [FAIL][17] ([i915#2842]) +3 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20453/shard-kbl2/igt@gem_exec_fair@basic-none-s...@rcs0.html * igt@gem_exec_fair@basic-none-vip@rcs0: - shard-glk: [PASS][18] -> [FAIL][19] ([i915#2842]) +1 similar issue [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10274/shard-glk5/igt@gem_exec_fair@basic-none-...@rcs0.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20453/shard-glk4/igt@gem_exec_fair@basic-none-...@rcs0.html * igt@gem_exec_reloc@basic-wide-active@rcs0: - shard-snb: NOTRUN -> [FAIL][20] ([i915#3633]) +2 similar issues [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20453/shard-snb7/igt@gem_exec_reloc@basic-wide-act...@rcs0.html * igt@gem_exec_whisper@basic-queues-forked-all: - shard-glk: [PASS][21] -> [DMESG-WARN][22] ([i915#118] / [i915#95]) +2 similar issues [21]:
Re: [Intel-gfx] [PATCH 01/47] drm/i915/guc: Relax CTB response timeout
On 24.06.2021 09:04, Matthew Brost wrote: > In upcoming patch we will allow more CTB requests to be sent in > parallel to the GuC for processing, so we shouldn't assume any more > that GuC will always reply without 10ms. > > Use bigger value hardcoded value of 1s instead. > > v2: Add CONFIG_DRM_I915_GUC_CTB_TIMEOUT config option > v3: > (Daniel Vetter) > - Use hardcoded value of 1s rather than config option > > Signed-off-by: Matthew Brost > Cc: Michal Wajdeczko > --- > drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c > b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c > index 43409044528e..a59e239497ee 100644 > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c > @@ -474,14 +474,16 @@ static int wait_for_ct_request_update(struct ct_request > *req, u32 *status) > /* >* Fast commands should complete in less than 10us, so sample quickly >* up to that length of time, then switch to a slower sleep-wait loop. > - * No GuC command should ever take longer than 10ms. > + * No GuC command should ever take longer than 10ms but many GuC > + * commands can be inflight at time, so use a 1s timeout on the slower > + * sleep-wait loop. >*/ > #define done \ > (FIELD_GET(GUC_HXG_MSG_0_ORIGIN, READ_ONCE(req->status)) == \ >GUC_HXG_ORIGIN_GUC) > err = wait_for_us(done, 10); > if (err) > - err = wait_for(done, 10); > + err = wait_for(done, 1000); can we add #defines for these 10/1000 values? with that Reviewed-by: Michal Wajdeczko > #undef done > > if (unlikely(err)) > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 15/17] drm/i915: Clean up jsl/ehl buf trans functions
On Wed, Jun 23, 2021 at 05:13:53PM +0300, Jani Nikula wrote:
> On Tue, 08 Jun 2021, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > The jsl/ehl buf trans functions are needlessly conplicated.
>^
>
> My only disappointment here is that now some of the
> *_get_combo_buf_trans_edp() functions handle low vswing inside, and some
> expect to only be called for low vswing.
Yeah, that is a bit annoying. Not really sure what the best approach is
for everything :/
>
> At least cnl could switch to same style as here, the rest get more
> complicated.
>
> Not a big issue, and the code is easy enough to follow for each
> individual platform. And I like the reduction in call depth.
>
> Reviewed-by: Jani Nikula
Ta.
>
>
> > Simplify them.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > .../drm/i915/display/intel_ddi_buf_trans.c| 87 +--
> > 1 file changed, 20 insertions(+), 67 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
> > b/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
> > index 9398aa62585b..2bd51ce4aa2c 100644
> > --- a/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
> > +++ b/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
> > @@ -1377,42 +1377,16 @@ icl_get_mg_buf_trans(struct intel_encoder *encoder,
> > return icl_get_mg_buf_trans_dp(encoder, crtc_state, n_entries);
> > }
> >
> > -static const struct intel_ddi_buf_trans *
> > -ehl_get_combo_buf_trans_hdmi(struct intel_encoder *encoder,
> > -const struct intel_crtc_state *crtc_state,
> > -int *n_entries)
> > -{
> > - return intel_get_buf_trans(_combo_phy_ddi_translations_hdmi,
> > - n_entries);
> > -}
> > -
> > -static const struct intel_ddi_buf_trans *
> > -ehl_get_combo_buf_trans_dp(struct intel_encoder *encoder,
> > - const struct intel_crtc_state *crtc_state,
> > - int *n_entries)
> > -{
> > - return intel_get_buf_trans(_combo_phy_ddi_translations_dp,
> > - n_entries);
> > -}
> >
> > static const struct intel_ddi_buf_trans *
> > ehl_get_combo_buf_trans_edp(struct intel_encoder *encoder,
> > const struct intel_crtc_state *crtc_state,
> > int *n_entries)
> > {
> > - struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > -
> > - if (dev_priv->vbt.edp.low_vswing) {
> > - if (crtc_state->port_clock > 27) {
> > - return
> > intel_get_buf_trans(_combo_phy_ddi_translations_edp_hbr2,
> > - n_entries);
> > - } else {
> > - return
> > intel_get_buf_trans(_combo_phy_ddi_translations_edp_hbr2,
> > - n_entries);
> > - }
> > - }
> > -
> > - return ehl_get_combo_buf_trans_dp(encoder, crtc_state, n_entries);
> > + if (crtc_state->port_clock > 27)
> > + return
> > intel_get_buf_trans(_combo_phy_ddi_translations_edp_hbr2, n_entries);
> > + else
> > + return
> > intel_get_buf_trans(_combo_phy_ddi_translations_edp_hbr2, n_entries);
> > }
> >
> > static const struct intel_ddi_buf_trans *
> > @@ -1420,30 +1394,15 @@ ehl_get_combo_buf_trans(struct intel_encoder
> > *encoder,
> > const struct intel_crtc_state *crtc_state,
> > int *n_entries)
> > {
> > + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > +
> > if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI))
> > - return ehl_get_combo_buf_trans_hdmi(encoder, crtc_state,
> > n_entries);
> > - else if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_EDP))
> > + return
> > intel_get_buf_trans(_combo_phy_ddi_translations_hdmi, n_entries);
> > + else if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_EDP) &&
> > +dev_priv->vbt.edp.low_vswing)
> > return ehl_get_combo_buf_trans_edp(encoder, crtc_state,
> > n_entries);
> > else
> > - return ehl_get_combo_buf_trans_dp(encoder, crtc_state,
> > n_entries);
> > -}
> > -
> > -static const struct intel_ddi_buf_trans *
> > -jsl_get_combo_buf_trans_hdmi(struct intel_encoder *encoder,
> > -const struct intel_crtc_state *crtc_state,
> > -int *n_entries)
> > -{
> > - return intel_get_buf_trans(_combo_phy_ddi_translations_hdmi,
> > - n_entries);
> > -}
> > -
> > -static const struct intel_ddi_buf_trans *
> > -jsl_get_combo_buf_trans_dp(struct intel_encoder *encoder,
> > - const struct intel_crtc_state *crtc_state,
> > - int *n_entries)
> > -{
> > - return
> > intel_get_buf_trans(_combo_phy_ddi_translations_dp_hbr2_edp_hbr3,
> > - n_entries);
> > +
Re: [Intel-gfx] [PATCH 04/47] drm/i915/guc: Add non blocking CTB send function
On 24.06.2021 17:49, Matthew Brost wrote:
> On Thu, Jun 24, 2021 at 04:48:32PM +0200, Michal Wajdeczko wrote:
>>
>>
>> On 24.06.2021 09:04, Matthew Brost wrote:
>>> Add non blocking CTB send function, intel_guc_send_nb. GuC submission
>>> will send CTBs in the critical path and does not need to wait for these
>>> CTBs to complete before moving on, hence the need for this new function.
>>>
>>> The non-blocking CTB now must have a flow control mechanism to ensure
>>> the buffer isn't overrun. A lazy spin wait is used as we believe the
>>> flow control condition should be rare with a properly sized buffer.
>>>
>>> The function, intel_guc_send_nb, is exported in this patch but unused.
>>> Several patches later in the series make use of this function.
>>>
>>> Signed-off-by: John Harrison
>>> Signed-off-by: Matthew Brost
>>> ---
>>> drivers/gpu/drm/i915/gt/uc/intel_guc.h| 12 +++-
>>> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 77 +--
>>> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h | 3 +-
>>> 3 files changed, 82 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
>>> b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
>>> index 4abc59f6f3cd..24b1df6ad4ae 100644
>>> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
>>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
>>> @@ -74,7 +74,15 @@ static inline struct intel_guc *log_to_guc(struct
>>> intel_guc_log *log)
>>> static
>>> inline int intel_guc_send(struct intel_guc *guc, const u32 *action, u32
>>> len)
>>> {
>>> - return intel_guc_ct_send(>ct, action, len, NULL, 0);
>>> + return intel_guc_ct_send(>ct, action, len, NULL, 0, 0);
>>> +}
>>> +
>>> +#define INTEL_GUC_SEND_NB BIT(31)
>>
>> hmm, this flag really belongs to intel_guc_ct_send() so it should be
>> defined as CTB flag near that function declaration
>>
>
> I can move this up a few lines.
>
>>> +static
>>> +inline int intel_guc_send_nb(struct intel_guc *guc, const u32 *action, u32
>>> len)
>>> +{
>>> + return intel_guc_ct_send(>ct, action, len, NULL, 0,
>>> +INTEL_GUC_SEND_NB);
>>> }
>>>
>>> static inline int
>>> @@ -82,7 +90,7 @@ intel_guc_send_and_receive(struct intel_guc *guc, const
>>> u32 *action, u32 len,
>>>u32 *response_buf, u32 response_buf_size)
>>> {
>>> return intel_guc_ct_send(>ct, action, len,
>>> -response_buf, response_buf_size);
>>> +response_buf, response_buf_size, 0);
>>> }
>>>
>>> static inline void intel_guc_to_host_event_handler(struct intel_guc *guc)
>>> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>>> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>>> index a17215920e58..c9a65d05911f 100644
>>> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>>> @@ -3,6 +3,11 @@
>>> * Copyright © 2016-2019 Intel Corporation
>>> */
>>>
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +
>>> #include "i915_drv.h"
>>> #include "intel_guc_ct.h"
>>> #include "gt/intel_gt.h"
>>> @@ -373,7 +378,7 @@ static void write_barrier(struct intel_guc_ct *ct)
>>> static int ct_write(struct intel_guc_ct *ct,
>>> const u32 *action,
>>> u32 len /* in dwords */,
>>> - u32 fence)
>>> + u32 fence, u32 flags)
>>> {
>>> struct intel_guc_ct_buffer *ctb = >ctbs.send;
>>> struct guc_ct_buffer_desc *desc = ctb->desc;
>>> @@ -421,9 +426,13 @@ static int ct_write(struct intel_guc_ct *ct,
>>> FIELD_PREP(GUC_CTB_MSG_0_NUM_DWORDS, len) |
>>> FIELD_PREP(GUC_CTB_MSG_0_FENCE, fence);
>>>
>>> - hxg = FIELD_PREP(GUC_HXG_MSG_0_TYPE, GUC_HXG_TYPE_REQUEST) |
>>> - FIELD_PREP(GUC_HXG_REQUEST_MSG_0_ACTION |
>>> -GUC_HXG_REQUEST_MSG_0_DATA0, action[0]);
>>> + hxg = (flags & INTEL_GUC_SEND_NB) ?
>>> + (FIELD_PREP(GUC_HXG_MSG_0_TYPE, GUC_HXG_TYPE_EVENT) |
>>> +FIELD_PREP(GUC_HXG_EVENT_MSG_0_ACTION |
>>> + GUC_HXG_EVENT_MSG_0_DATA0, action[0])) :
>>> + (FIELD_PREP(GUC_HXG_MSG_0_TYPE, GUC_HXG_TYPE_REQUEST) |
>>> +FIELD_PREP(GUC_HXG_REQUEST_MSG_0_ACTION |
>>> + GUC_HXG_REQUEST_MSG_0_DATA0, action[0]));
>>
>> or as we already switched to accept and return whole HXG messages in
>> guc_send_mmio() maybe we should do the same for CTB variant too and
>> instead of using extra flag just let caller to prepare proper HXG header
>> with HXG_EVENT type and then in CTB code just look at this type to make
>> decision which code path to use
>>
>
> Not sure I follow. Anyways could this be done in a follow up by you if
> want this change.
>
>> note that existing callers should not be impacted, as full HXG header
>> for the REQUEST message looks exactly the same as "action" code alone.
>>
>>>
>>> CT_DEBUG(ct, "writing (tail %u) %*ph %*ph %*ph\n",
>>>
Re: [Intel-gfx] [PATCH 14/15] drm/gem: Tiny kernel clarification for drm_gem_fence_array_add
Am 24.06.21 um 14:41 schrieb Daniel Vetter: On Wed, Jun 23, 2021 at 10:42:50AM +0200, Christian König wrote: Am 22.06.21 um 18:55 schrieb Daniel Vetter: Spotted while trying to convert panfrost to these. Signed-off-by: Daniel Vetter Cc: "Christian König" Cc: Lucas Stach Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Thomas Zimmermann Cc: David Airlie Cc: Daniel Vetter --- drivers/gpu/drm/drm_gem.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c index ba2e64ed8b47..68deb1de8235 100644 --- a/drivers/gpu/drm/drm_gem.c +++ b/drivers/gpu/drm/drm_gem.c @@ -1302,6 +1302,9 @@ EXPORT_SYMBOL(drm_gem_unlock_reservations); * @fence_array: array of dma_fence * for the job to block on. * @fence: the dma_fence to add to the list of dependencies. * + * This functions consumes the reference for @fence both on success and error + * cases. + * Oh, the later is a bit ugly I think. But good to know. Reviewed-by: Christian König Merged to drm-misc-next, thanks for taking a look. Can you perhaps take a look at the drm/armada patch too, then I think I have reviews/acks for all of them? What are you talking about? I only see drm/armada patches for the irq stuff Thomas is working on. Christian. Thanks, Daniel * Returns: * 0 on success, or an error on failing to expand the array. */ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dp: Fix invalid test parameter when run DP link layer compliance
== Series Details == Series: drm/i915/dp: Fix invalid test parameter when run DP link layer compliance URL : https://patchwork.freedesktop.org/series/91879/ State : success == Summary == CI Bug Log - changes from CI_DRM_10276 -> Patchwork_20458 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20458/index.html Known issues Here are the changes found in Patchwork_20458 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_cs_nop@sync-compute0: - fi-kbl-soraka: NOTRUN -> [SKIP][1] ([fdo#109271]) +2 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20458/fi-kbl-soraka/igt@amdgpu/amd_cs_...@sync-compute0.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 Participating hosts (45 -> 39) -- Missing(6): fi-ilk-m540 fi-hsw-4200u fi-skl-guc fi-bsw-cyan fi-ctg-p8600 fi-bdw-samus Build changes - * Linux: CI_DRM_10276 -> Patchwork_20458 CI-20190529: 20190529 CI_DRM_10276: dc72fe3798577491293de99bfcf132e5d321ab7e @ git://anongit.freedesktop.org/gfx-ci/linux IGT_6117: 3ba0a02404f243d6d8f232c6215163cc4b0fd699 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_20458: 82986769202125be11e18daf7ce688722fab2be0 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 829867692021 drm/i915/dp: Fix invalid test parameter when run DP link layer compliance == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20458/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 36/97] drm/i915/guc: Add non blocking CTB send function
On Thu, Jun 10, 2021 at 05:27:48PM +0200, Daniel Vetter wrote:
> On Wed, Jun 09, 2021 at 04:10:23PM -0700, Matthew Brost wrote:
> > On Tue, Jun 08, 2021 at 10:46:15AM +0200, Daniel Vetter wrote:
> > > On Tue, Jun 8, 2021 at 10:39 AM Tvrtko Ursulin
> > > wrote:
> > > >
> > > >
> > > > On 07/06/2021 18:31, Matthew Brost wrote:
> > > > > On Thu, May 27, 2021 at 04:11:50PM +0100, Tvrtko Ursulin wrote:
> > > > >>
> > > > >> On 27/05/2021 15:35, Matthew Brost wrote:
> > > > >>> On Thu, May 27, 2021 at 11:02:24AM +0100, Tvrtko Ursulin wrote:
> > > >
> > > > On 26/05/2021 19:10, Matthew Brost wrote:
> > > >
> > > > [snip]
> > > >
> > > > > +static int ct_send_nb(struct intel_guc_ct *ct,
> > > > > + const u32 *action,
> > > > > + u32 len,
> > > > > + u32 flags)
> > > > > +{
> > > > > + struct intel_guc_ct_buffer *ctb = >ctbs.send;
> > > > > + unsigned long spin_flags;
> > > > > + u32 fence;
> > > > > + int ret;
> > > > > +
> > > > > + spin_lock_irqsave(>lock, spin_flags);
> > > > > +
> > > > > + ret = ctb_has_room(ctb, len + 1);
> > > > > + if (unlikely(ret))
> > > > > + goto out;
> > > > > +
> > > > > + fence = ct_get_next_fence(ct);
> > > > > + ret = ct_write(ct, action, len, fence, flags);
> > > > > + if (unlikely(ret))
> > > > > + goto out;
> > > > > +
> > > > > + intel_guc_notify(ct_to_guc(ct));
> > > > > +
> > > > > +out:
> > > > > + spin_unlock_irqrestore(>lock, spin_flags);
> > > > > +
> > > > > + return ret;
> > > > > +}
> > > > > +
> > > > > static int ct_send(struct intel_guc_ct *ct,
> > > > > const u32 *action,
> > > > > u32 len,
> > > > > @@ -473,6 +541,7 @@ static int ct_send(struct intel_guc_ct
> > > > > *ct,
> > > > > u32 response_buf_size,
> > > > > u32 *status)
> > > > > {
> > > > > + struct intel_guc_ct_buffer *ctb = >ctbs.send;
> > > > > struct ct_request request;
> > > > > unsigned long flags;
> > > > > u32 fence;
> > > > > @@ -482,8 +551,20 @@ static int ct_send(struct intel_guc_ct
> > > > > *ct,
> > > > > GEM_BUG_ON(!len);
> > > > > GEM_BUG_ON(len & ~GUC_CT_MSG_LEN_MASK);
> > > > > GEM_BUG_ON(!response_buf && response_buf_size);
> > > > > + might_sleep();
> > > >
> > > > Sleep is just cond_resched below or there is more?
> > > >
> > > > >>>
> > > > >>> Yes, the cond_resched.
> > > > >>>
> > > > > + /*
> > > > > + * We use a lazy spin wait loop here as we believe that
> > > > > if the CT
> > > > > + * buffers are sized correctly the flow control
> > > > > condition should be
> > > > > + * rare.
> > > > > + */
> > > > > +retry:
> > > > > spin_lock_irqsave(>ctbs.send.lock, flags);
> > > > > + if (unlikely(!ctb_has_room(ctb, len + 1))) {
> > > > > + spin_unlock_irqrestore(>ctbs.send.lock,
> > > > > flags);
> > > > > + cond_resched();
> > > > > + goto retry;
> > > > > + }
> > > >
> > > > If this patch is about adding a non-blocking send function,
> > > > and below we can
> > > > see that it creates a fork:
> > > >
> > > > intel_guc_ct_send:
> > > > ...
> > > > if (flags & INTEL_GUC_SEND_NB)
> > > > return ct_send_nb(ct, action, len, flags);
> > > >
> > > > ret = ct_send(ct, action, len, response_buf,
> > > > response_buf_size, );
> > > >
> > > > Then why is there a change in ct_send here, which is not the
> > > > new
> > > > non-blocking path?
> > > >
> > > > >>>
> > > > >>> There is not a change to ct_send(), just to intel_guc_ct_send.
> > > > >>
> > > > >> I was doing by the diff which says:
> > > > >>
> > > > >> static int ct_send(struct intel_guc_ct *ct,
> > > > >> const u32 *action,
> > > > >> u32 len,
> > > > >> @@ -473,6 +541,7 @@ static int ct_send(struct intel_guc_ct *ct,
> > > > >> u32 response_buf_size,
> > > > >> u32 *status)
> > > > >> {
> > > > >> +struct intel_guc_ct_buffer *ctb = >ctbs.send;
[Intel-gfx] ✗ Fi.CI.BUILD: failure for Restricted DMA
== Series Details == Series: Restricted DMA URL : https://patchwork.freedesktop.org/series/91883/ State : failure == Summary == Applying: swiotlb: Refactor swiotlb init functions Applying: swiotlb: Refactor swiotlb_create_debugfs Applying: swiotlb: Set dev->dma_io_tlb_mem to the swiotlb pool used error: sha1 information is lacking or useless (kernel/dma/swiotlb.c). error: could not build fake ancestor hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0003 swiotlb: Set dev->dma_io_tlb_mem to the swiotlb pool used When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 45/47] drm/i915/guc: Include scheduling policies in the debugfs state dump
On Thu, Jun 24, 2021 at 12:05:14AM -0700, Matthew Brost wrote:
> From: John Harrison
>
> Added the scheduling policy parameters to the 'guc_info' debugfs state
> dump.
>
> Signed-off-by: John Harrison
> Signed-off-by: Matthew Brost
Reviewed-by: Matthew Brost
> ---
> drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 13 +
> drivers/gpu/drm/i915/gt/uc/intel_guc_ads.h | 2 ++
> drivers/gpu/drm/i915/gt/uc/intel_guc_debugfs.c | 2 ++
> 3 files changed, 17 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> index c6d0b762d82c..b8182844aa00 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> @@ -92,6 +92,19 @@ static void guc_policies_init(struct intel_guc *guc,
> struct guc_policies *polici
> policies->is_valid = 1;
> }
>
> +void intel_guc_log_policy_info(struct intel_guc *guc, struct drm_printer *dp)
> +{
> + struct __guc_ads_blob *blob = guc->ads_blob;
> +
> + if (unlikely(!blob))
> + return;
> +
> + drm_printf(dp, "Global scheduling policies:\n");
> + drm_printf(dp, " DPC promote time = %u\n",
> blob->policies.dpc_promote_time);
> + drm_printf(dp, " Max num work items = %u\n",
> blob->policies.max_num_work_items);
> + drm_printf(dp, " Flags = %u\n",
> blob->policies.global_flags);
> +}
> +
> static int guc_action_policies_update(struct intel_guc *guc, u32
> policy_offset)
> {
> u32 action[] = {
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.h
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.h
> index b00d3ae1113a..0fdcb3583601 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.h
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.h
> @@ -7,9 +7,11 @@
> #define _INTEL_GUC_ADS_H_
>
> struct intel_guc;
> +struct drm_printer;
>
> int intel_guc_ads_create(struct intel_guc *guc);
> void intel_guc_ads_destroy(struct intel_guc *guc);
> void intel_guc_ads_reset(struct intel_guc *guc);
> +void intel_guc_log_policy_info(struct intel_guc *guc, struct drm_printer *p);
>
> #endif
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_debugfs.c
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_debugfs.c
> index 62b9ce0fafaa..9a03ff56e654 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_debugfs.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_debugfs.c
> @@ -10,6 +10,7 @@
> #include "intel_guc_debugfs.h"
> #include "intel_guc_log_debugfs.h"
> #include "gt/uc/intel_guc_ct.h"
> +#include "gt/uc/intel_guc_ads.h"
> #include "gt/uc/intel_guc_submission.h"
>
> static int guc_info_show(struct seq_file *m, void *data)
> @@ -29,6 +30,7 @@ static int guc_info_show(struct seq_file *m, void *data)
>
> intel_guc_log_ct_info(>ct, );
> intel_guc_log_submission_info(guc, );
> + intel_guc_log_policy_info(guc, );
>
> return 0;
> }
> --
> 2.28.0
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 40/47] drm/i915/guc: Enable GuC engine reset
On Thu, Jun 24, 2021 at 12:05:09AM -0700, Matthew Brost wrote:
> From: John Harrison
>
> Clear the 'disable resets' flag to allow GuC to reset hung contexts
> (detected via pre-emption timeout).
>
> Signed-off-by: John Harrison
> Signed-off-by: Matthew Brost
Reviewed-by: Matthew Brost
> ---
> drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> index 9fd3c911f5fb..d3e86ab7508f 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> @@ -81,8 +81,7 @@ static void guc_policies_init(struct guc_policies *policies)
> {
> policies->dpc_promote_time = GLOBAL_POLICY_DEFAULT_DPC_PROMOTE_TIME_US;
> policies->max_num_work_items = GLOBAL_POLICY_MAX_NUM_WI;
> - /* Disable automatic resets as not yet supported. */
> - policies->global_flags = GLOBAL_POLICY_DISABLE_ENGINE_RESET;
> + policies->global_flags = 0;
> policies->is_valid = 1;
> }
>
> --
> 2.28.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/6] drm/i915/display/adl_p: Implement PSR changes
On Thu, 2021-06-24 at 09:22 -0700, José Roberto de Souza wrote:
> On Wed, 2021-06-23 at 22:06 +0300, Gwan-gyeong Mun wrote:
> > On 6/16/21 11:31 PM, José Roberto de Souza wrote:
> > > Implements changes around PSR for alderlake-P:
> > >
> > > - EDP_SU_TRACK_ENABLE was removed and bit 30 now has other function
> > > - Some bits of PSR2_MAN_TRK_CTL moved and SF_PARTIAL_FRAME_UPDATE was
> > >removed setting SU_REGION_START/END_ADDR will do this job
> > > - SU_REGION_START/END_ADDR have now line granularity but will need to
> > >be aligned with DSC when the PSRS + DSC support lands
> > >
> > > BSpec: 50422
> > > BSpec: 50424
> > > Cc: Gwan-gyeong Mun
> > > Cc: Anusha Srivatsa
> > > Signed-off-by: José Roberto de Souza
> > > Signed-off-by: Gwan-gyeong Mun
> > > ---
> > > drivers/gpu/drm/i915/display/intel_psr.c | 43 ++--
> > > drivers/gpu/drm/i915/i915_reg.h | 26 --
> > > 2 files changed, 48 insertions(+), 21 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> > > b/drivers/gpu/drm/i915/display/intel_psr.c
> > > index 9643624fe160d..46bb19c4b63a4 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > > @@ -534,11 +534,13 @@ static u32 intel_psr2_get_tp_time(struct intel_dp
> > > *intel_dp)
> > > static void hsw_activate_psr2(struct intel_dp *intel_dp)
> > > {
> > > struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> > > - u32 val;
> > > + u32 val = EDP_PSR2_ENABLE;
> > > +
> > > + val |= psr_compute_idle_frames(intel_dp) << EDP_PSR2_IDLE_FRAME_SHIFT;
> > >
> > > - val = psr_compute_idle_frames(intel_dp) << EDP_PSR2_IDLE_FRAME_SHIFT;
> > > + if (!IS_ALDERLAKE_P(dev_priv))
> > > + val |= EDP_SU_TRACK_ENABLE;
> > >
> > > - val |= EDP_PSR2_ENABLE | EDP_SU_TRACK_ENABLE;
> > > if (DISPLAY_VER(dev_priv) >= 10 && DISPLAY_VER(dev_priv) <= 12)
> > > val |= EDP_Y_COORDINATE_ENABLE;
> > >
> > > @@ -793,6 +795,7 @@ static bool intel_psr2_sel_fetch_config_valid(struct
> > > intel_dp *intel_dp,
> > > static bool psr2_granularity_check(struct intel_dp *intel_dp,
> > > struct intel_crtc_state *crtc_state)
> > > {
> > > + struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> > > const int crtc_hdisplay =
> > > crtc_state->hw.adjusted_mode.crtc_hdisplay;
> > > const int crtc_vdisplay =
> > > crtc_state->hw.adjusted_mode.crtc_vdisplay;
> > > u16 y_granularity = 0;
> > > @@ -809,10 +812,13 @@ static bool psr2_granularity_check(struct intel_dp
> > > *intel_dp,
> > > return intel_dp->psr.su_y_granularity == 4;
> > >
> > > /*
> > > - * For SW tracking we can adjust the y to match sink requirement if
> > > - * multiple of 4
> > > + * adl_p has 1 line granularity for other platforms with SW tracking we
> > > + * can adjust the y coordinate to match sink requirement if multiple of
> > > + * 4
> > >*/
> > > - if (intel_dp->psr.su_y_granularity <= 2)
> > > + if (IS_ALDERLAKE_P(dev_priv))
> > > + y_granularity = intel_dp->psr.su_y_granularity;
> > > + else if (intel_dp->psr.su_y_granularity <= 2)
> > > y_granularity = 4;
> > > else if ((intel_dp->psr.su_y_granularity % 4) == 0)
> > > y_granularity = intel_dp->psr.su_y_granularity;
> > > @@ -1525,21 +1531,32 @@ void intel_psr2_program_trans_man_trk_ctl(const
> > > struct intel_crtc_state *crtc_st
> > > static void psr2_man_trk_ctl_calc(struct intel_crtc_state *crtc_state,
> > > struct drm_rect *clip, bool
> > > full_update)
> > > {
> > > + struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> > > + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > > u32 val = PSR2_MAN_TRK_CTL_ENABLE;
> > The logic is not wrong, but the meaning of the register bit has changed.
> > The 31st bit in ADL-P means "SF partial frame enable".
> > It is recommended to add a macro such as
> > ADLP_PSR2_MAN_TRK_CTL_SF_PARTIAL_FRAME_ENABLE to the code to clarify the
> > role of the changed register.
>
> In my opinion the meaning is the same, enable manual/software tracking.
> It was just a register rename done as part of changes of the other bits.
>
> But if you really think is necessary I can do that, please let me know.
And with or without that can I add your RVB?
>
> > >
> > > if (full_update) {
> > > - val |= PSR2_MAN_TRK_CTL_SF_SINGLE_FULL_FRAME;
> > > + if (IS_ALDERLAKE_P(dev_priv))
> > > + val |= ADLP_PSR2_MAN_TRK_CTL_SF_SINGLE_FULL_FRAME;
> > > + else
> > > + val |= PSR2_MAN_TRK_CTL_SF_SINGLE_FULL_FRAME;
> > > +
> > > goto exit;
> > > }
> > >
> > > if (clip->y1 == -1)
> > > goto exit;
> > >
> > > -
Re: [Intel-gfx] [PATCH 6/6] drm/i915/display/adl_p: Implement PSR changes
On Wed, 2021-06-23 at 22:06 +0300, Gwan-gyeong Mun wrote:
> On 6/16/21 11:31 PM, José Roberto de Souza wrote:
> > Implements changes around PSR for alderlake-P:
> >
> > - EDP_SU_TRACK_ENABLE was removed and bit 30 now has other function
> > - Some bits of PSR2_MAN_TRK_CTL moved and SF_PARTIAL_FRAME_UPDATE was
> >removed setting SU_REGION_START/END_ADDR will do this job
> > - SU_REGION_START/END_ADDR have now line granularity but will need to
> >be aligned with DSC when the PSRS + DSC support lands
> >
> > BSpec: 50422
> > BSpec: 50424
> > Cc: Gwan-gyeong Mun
> > Cc: Anusha Srivatsa
> > Signed-off-by: José Roberto de Souza
> > Signed-off-by: Gwan-gyeong Mun
> > ---
> > drivers/gpu/drm/i915/display/intel_psr.c | 43 ++--
> > drivers/gpu/drm/i915/i915_reg.h | 26 --
> > 2 files changed, 48 insertions(+), 21 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> > b/drivers/gpu/drm/i915/display/intel_psr.c
> > index 9643624fe160d..46bb19c4b63a4 100644
> > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > @@ -534,11 +534,13 @@ static u32 intel_psr2_get_tp_time(struct intel_dp
> > *intel_dp)
> > static void hsw_activate_psr2(struct intel_dp *intel_dp)
> > {
> > struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> > - u32 val;
> > + u32 val = EDP_PSR2_ENABLE;
> > +
> > + val |= psr_compute_idle_frames(intel_dp) << EDP_PSR2_IDLE_FRAME_SHIFT;
> >
> > - val = psr_compute_idle_frames(intel_dp) << EDP_PSR2_IDLE_FRAME_SHIFT;
> > + if (!IS_ALDERLAKE_P(dev_priv))
> > + val |= EDP_SU_TRACK_ENABLE;
> >
> > - val |= EDP_PSR2_ENABLE | EDP_SU_TRACK_ENABLE;
> > if (DISPLAY_VER(dev_priv) >= 10 && DISPLAY_VER(dev_priv) <= 12)
> > val |= EDP_Y_COORDINATE_ENABLE;
> >
> > @@ -793,6 +795,7 @@ static bool intel_psr2_sel_fetch_config_valid(struct
> > intel_dp *intel_dp,
> > static bool psr2_granularity_check(struct intel_dp *intel_dp,
> >struct intel_crtc_state *crtc_state)
> > {
> > + struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> > const int crtc_hdisplay = crtc_state->hw.adjusted_mode.crtc_hdisplay;
> > const int crtc_vdisplay = crtc_state->hw.adjusted_mode.crtc_vdisplay;
> > u16 y_granularity = 0;
> > @@ -809,10 +812,13 @@ static bool psr2_granularity_check(struct intel_dp
> > *intel_dp,
> > return intel_dp->psr.su_y_granularity == 4;
> >
> > /*
> > -* For SW tracking we can adjust the y to match sink requirement if
> > -* multiple of 4
> > +* adl_p has 1 line granularity for other platforms with SW tracking we
> > +* can adjust the y coordinate to match sink requirement if multiple of
> > +* 4
> > */
> > - if (intel_dp->psr.su_y_granularity <= 2)
> > + if (IS_ALDERLAKE_P(dev_priv))
> > + y_granularity = intel_dp->psr.su_y_granularity;
> > + else if (intel_dp->psr.su_y_granularity <= 2)
> > y_granularity = 4;
> > else if ((intel_dp->psr.su_y_granularity % 4) == 0)
> > y_granularity = intel_dp->psr.su_y_granularity;
> > @@ -1525,21 +1531,32 @@ void intel_psr2_program_trans_man_trk_ctl(const
> > struct intel_crtc_state *crtc_st
> > static void psr2_man_trk_ctl_calc(struct intel_crtc_state *crtc_state,
> > struct drm_rect *clip, bool full_update)
> > {
> > + struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> > + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > u32 val = PSR2_MAN_TRK_CTL_ENABLE;
> The logic is not wrong, but the meaning of the register bit has changed.
> The 31st bit in ADL-P means "SF partial frame enable".
> It is recommended to add a macro such as
> ADLP_PSR2_MAN_TRK_CTL_SF_PARTIAL_FRAME_ENABLE to the code to clarify the
> role of the changed register.
In my opinion the meaning is the same, enable manual/software tracking.
It was just a register rename done as part of changes of the other bits.
But if you really think is necessary I can do that, please let me know.
> >
> > if (full_update) {
> > - val |= PSR2_MAN_TRK_CTL_SF_SINGLE_FULL_FRAME;
> > + if (IS_ALDERLAKE_P(dev_priv))
> > + val |= ADLP_PSR2_MAN_TRK_CTL_SF_SINGLE_FULL_FRAME;
> > + else
> > + val |= PSR2_MAN_TRK_CTL_SF_SINGLE_FULL_FRAME;
> > +
> > goto exit;
> > }
> >
> > if (clip->y1 == -1)
> > goto exit;
> >
> > - drm_WARN_ON(crtc_state->uapi.crtc->dev, clip->y1 % 4 || clip->y2 % 4);
> > + if (IS_ALDERLAKE_P(dev_priv)) {
> > + val |= ADLP_PSR2_MAN_TRK_CTL_SU_REGION_START_ADDR(clip->y1);
> > + val |= ADLP_PSR2_MAN_TRK_CTL_SU_REGION_END_ADDR(clip->y2);
> > + } else {
> > + drm_WARN_ON(crtc_state->uapi.crtc->dev, clip->y1 % 4 ||
> > clip->y2 % 4);
> >
> > - val |=
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftest: Extend ctx_timestamp ICL workaround to GEN11 (rev3)
== Series Details ==
Series: drm/i915/selftest: Extend ctx_timestamp ICL workaround to GEN11 (rev3)
URL : https://patchwork.freedesktop.org/series/91805/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10276 -> Patchwork_20456
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20456/index.html
Known issues
Here are the changes found in Patchwork_20456 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_cs_nop@sync-fork-compute0:
- fi-kbl-soraka: NOTRUN -> [SKIP][1] ([fdo#109271]) +6 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20456/fi-kbl-soraka/igt@amdgpu/amd_cs_...@sync-fork-compute0.html
* igt@i915_pm_rpm@module-reload:
- fi-kbl-guc: [PASS][2] -> [FAIL][3] ([i915#2203] / [i915#579])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10276/fi-kbl-guc/igt@i915_pm_...@module-reload.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20456/fi-kbl-guc/igt@i915_pm_...@module-reload.html
* igt@kms_chamelium@dp-crc-fast:
- fi-kbl-7500u: [PASS][4] -> [FAIL][5] ([i915#1372])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10276/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20456/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
* igt@runner@aborted:
- fi-kbl-r: NOTRUN -> [FAIL][6] ([i915#2292] / [i915#2426] /
[i915#3363] / [k.org#204565])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20456/fi-kbl-r/igt@run...@aborted.html
Possible fixes
* igt@i915_selftest@live@gt_engines:
- {fi-ehl-2}: [FAIL][7] ([i915#3628]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10276/fi-ehl-2/igt@i915_selftest@live@gt_engines.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20456/fi-ehl-2/igt@i915_selftest@live@gt_engines.html
- {fi-jsl-1}: [FAIL][9] ([i915#3628]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10276/fi-jsl-1/igt@i915_selftest@live@gt_engines.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20456/fi-jsl-1/igt@i915_selftest@live@gt_engines.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#1372]: https://gitlab.freedesktop.org/drm/intel/issues/1372
[i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
[i915#1759]: https://gitlab.freedesktop.org/drm/intel/issues/1759
[i915#2203]: https://gitlab.freedesktop.org/drm/intel/issues/2203
[i915#2292]: https://gitlab.freedesktop.org/drm/intel/issues/2292
[i915#2426]: https://gitlab.freedesktop.org/drm/intel/issues/2426
[i915#2966]: https://gitlab.freedesktop.org/drm/intel/issues/2966
[i915#3363]: https://gitlab.freedesktop.org/drm/intel/issues/3363
[i915#3628]: https://gitlab.freedesktop.org/drm/intel/issues/3628
[i915#579]: https://gitlab.freedesktop.org/drm/intel/issues/579
[k.org#204565]: https://bugzilla.kernel.org/show_bug.cgi?id=204565
Participating hosts (45 -> 39)
--
Missing(6): fi-ilk-m540 fi-hsw-4200u fi-bsw-n3050 fi-bsw-cyan
fi-ctg-p8600 fi-bdw-samus
Build changes
-
* Linux: CI_DRM_10276 -> Patchwork_20456
CI-20190529: 20190529
CI_DRM_10276: dc72fe3798577491293de99bfcf132e5d321ab7e @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6117: 3ba0a02404f243d6d8f232c6215163cc4b0fd699 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_20456: f5b17eede4f9538ae10458ae988e83c37dd6f616 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
f5b17eede4f9 drm/i915/selftest: Extend ctx_timestamp ICL workaround to GEN11
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20456/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BUILD: failure for KVM: Remove uses of struct page from x86 and arm64 MMU (rev3)
== Series Details == Series: KVM: Remove uses of struct page from x86 and arm64 MMU (rev3) URL : https://patchwork.freedesktop.org/series/91836/ State : failure == Summary == Applying: KVM: Remove uses of struct page from x86 and arm64 MMU Applying: KVM: mmu: also return page from gfn_to_pfn Using index info to reconstruct a base tree... M arch/powerpc/kvm/book3s_64_mmu_hv.c M arch/x86/kvm/mmu/mmu_audit.c M arch/x86/kvm/x86.c M drivers/gpu/drm/i915/gvt/kvmgt.c M virt/kvm/kvm_main.c Falling back to patching base and 3-way merge... Auto-merging virt/kvm/kvm_main.c CONFLICT (content): Merge conflict in virt/kvm/kvm_main.c Auto-merging drivers/gpu/drm/i915/gvt/kvmgt.c Auto-merging arch/x86/kvm/x86.c Auto-merging arch/x86/kvm/mmu/mmu_audit.c Auto-merging arch/powerpc/kvm/book3s_64_mmu_hv.c error: Failed to merge in the changes. hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0002 KVM: mmu: also return page from gfn_to_pfn When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v14 06/12] swiotlb: Use is_swiotlb_force_bounce for swiotlb data bouncing
On Thu, Jun 24, 2021 at 11:56 PM Konrad Rzeszutek Wilk
wrote:
>
> On Thu, Jun 24, 2021 at 10:10:51AM -0400, Qian Cai wrote:
> >
> >
> > On 6/24/2021 7:48 AM, Will Deacon wrote:
> > > Ok, diff below which attempts to tackle the offset issue I mentioned as
> > > well. Qian Cai -- please can you try with these changes?
> >
> > This works fine.
>
> Cool. Let me squash this patch in #6 and rebase the rest of them.
>
> Claire, could you check the devel/for-linus-5.14 say by end of today to
> double check that I didn't mess anything up please?
I just submitted v15 here
(https://lore.kernel.org/patchwork/cover/1451322/) in case it's
helpful.
I'll double check of course. Thanks for the efforts!
>
> Will,
>
> Thank you for generating the fix! I am going to run it on x86 and Xen
> to make sure all is good (granted last time I ran devel/for-linus-5.14
> on that setup I didn't see any errors so I need to double check
> I didn't do something silly like run a wrong kernel).
>
>
> >
> > >
> > > Will
> > >
> > > --->8
> > >
> > > diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
> > > index 175b6c113ed8..39284ff2a6cd 100644
> > > --- a/include/linux/swiotlb.h
> > > +++ b/include/linux/swiotlb.h
> > > @@ -116,7 +116,9 @@ static inline bool is_swiotlb_buffer(struct device
> > > *dev, phys_addr_t paddr)
> > >
> > > static inline bool is_swiotlb_force_bounce(struct device *dev)
> > > {
> > > - return dev->dma_io_tlb_mem->force_bounce;
> > > + struct io_tlb_mem *mem = dev->dma_io_tlb_mem;
> > > +
> > > + return mem && mem->force_bounce;
> > > }
> > >
> > > void __init swiotlb_exit(void);
> > > diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
> > > index 44be8258e27b..0ffbaae9fba2 100644
> > > --- a/kernel/dma/swiotlb.c
> > > +++ b/kernel/dma/swiotlb.c
> > > @@ -449,6 +449,7 @@ static int swiotlb_find_slots(struct device *dev,
> > > phys_addr_t orig_addr,
> > > dma_get_min_align_mask(dev) & ~(IO_TLB_SIZE - 1);
> > > unsigned int nslots = nr_slots(alloc_size), stride;
> > > unsigned int index, wrap, count = 0, i;
> > > + unsigned int offset = swiotlb_align_offset(dev, orig_addr);
> > > unsigned long flags;
> > >
> > > BUG_ON(!nslots);
> > > @@ -497,7 +498,7 @@ static int swiotlb_find_slots(struct device *dev,
> > > phys_addr_t orig_addr,
> > > for (i = index; i < index + nslots; i++) {
> > > mem->slots[i].list = 0;
> > > mem->slots[i].alloc_size =
> > > - alloc_size - ((i - index) << IO_TLB_SHIFT);
> > > + alloc_size - (offset + ((i - index) <<
> > > IO_TLB_SHIFT));
> > > }
> > > for (i = index - 1;
> > > io_tlb_offset(i) != IO_TLB_SEGSIZE - 1 &&
> > >
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 39/47] drm/i915/guc: Don't complain about reset races
On Thu, Jun 24, 2021 at 12:05:08AM -0700, Matthew Brost wrote:
> From: John Harrison
>
> It is impossible to seal all race conditions of resets occurring
> concurrent to other operations. At least, not without introducing
> excesive mutex locking. Instead, don't complain if it occurs. In
> particular, don't complain if trying to send a H2G during a reset.
> Whatever the H2G was about should get redone once the reset is over.
>
> Signed-off-by: John Harrison
> Signed-off-by: Matthew Brost
Reviewed-by: Matthew Brost
> ---
> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 5 -
> drivers/gpu/drm/i915/gt/uc/intel_uc.c | 3 +++
> drivers/gpu/drm/i915/gt/uc/intel_uc.h | 2 ++
> 3 files changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> index dd6177c8d75c..3b32755f892e 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> @@ -727,7 +727,10 @@ int intel_guc_ct_send(struct intel_guc_ct *ct, const u32
> *action, u32 len,
> int ret;
>
> if (unlikely(!ct->enabled)) {
> - WARN(1, "Unexpected send: action=%#x\n", *action);
> + struct intel_guc *guc = ct_to_guc(ct);
> + struct intel_uc *uc = container_of(guc, struct intel_uc, guc);
> +
> + WARN(!uc->reset_in_progress, "Unexpected send: action=%#x\n",
> *action);
> return -ENODEV;
> }
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> index b523a8521351..77c1fe2ed883 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> @@ -550,6 +550,7 @@ void intel_uc_reset_prepare(struct intel_uc *uc)
> {
> struct intel_guc *guc = >guc;
>
> + uc->reset_in_progress = true;
>
> /* Nothing to do if GuC isn't supported */
> if (!intel_uc_supports_guc(uc))
> @@ -579,6 +580,8 @@ void intel_uc_reset_finish(struct intel_uc *uc)
> {
> struct intel_guc *guc = >guc;
>
> + uc->reset_in_progress = false;
> +
> /* Firmware expected to be running when this function is called */
> if (intel_guc_is_fw_running(guc) && intel_uc_uses_guc_submission(uc))
> intel_guc_submission_reset_finish(guc);
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.h
> b/drivers/gpu/drm/i915/gt/uc/intel_uc.h
> index eaa3202192ac..91315e3f1c58 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_uc.h
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.h
> @@ -30,6 +30,8 @@ struct intel_uc {
>
> /* Snapshot of GuC log from last failed load */
> struct drm_i915_gem_object *load_err_log;
> +
> + bool reset_in_progress;
> };
>
> void intel_uc_init_early(struct intel_uc *uc);
> --
> 2.28.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/47] drm/i915/guc: Add non blocking CTB send function
On Thu, Jun 24, 2021 at 04:48:32PM +0200, Michal Wajdeczko wrote:
>
>
> On 24.06.2021 09:04, Matthew Brost wrote:
> > Add non blocking CTB send function, intel_guc_send_nb. GuC submission
> > will send CTBs in the critical path and does not need to wait for these
> > CTBs to complete before moving on, hence the need for this new function.
> >
> > The non-blocking CTB now must have a flow control mechanism to ensure
> > the buffer isn't overrun. A lazy spin wait is used as we believe the
> > flow control condition should be rare with a properly sized buffer.
> >
> > The function, intel_guc_send_nb, is exported in this patch but unused.
> > Several patches later in the series make use of this function.
> >
> > Signed-off-by: John Harrison
> > Signed-off-by: Matthew Brost
> > ---
> > drivers/gpu/drm/i915/gt/uc/intel_guc.h| 12 +++-
> > drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 77 +--
> > drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h | 3 +-
> > 3 files changed, 82 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > index 4abc59f6f3cd..24b1df6ad4ae 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > @@ -74,7 +74,15 @@ static inline struct intel_guc *log_to_guc(struct
> > intel_guc_log *log)
> > static
> > inline int intel_guc_send(struct intel_guc *guc, const u32 *action, u32
> > len)
> > {
> > - return intel_guc_ct_send(>ct, action, len, NULL, 0);
> > + return intel_guc_ct_send(>ct, action, len, NULL, 0, 0);
> > +}
> > +
> > +#define INTEL_GUC_SEND_NB BIT(31)
>
> hmm, this flag really belongs to intel_guc_ct_send() so it should be
> defined as CTB flag near that function declaration
>
I can move this up a few lines.
> > +static
> > +inline int intel_guc_send_nb(struct intel_guc *guc, const u32 *action, u32
> > len)
> > +{
> > + return intel_guc_ct_send(>ct, action, len, NULL, 0,
> > +INTEL_GUC_SEND_NB);
> > }
> >
> > static inline int
> > @@ -82,7 +90,7 @@ intel_guc_send_and_receive(struct intel_guc *guc, const
> > u32 *action, u32 len,
> >u32 *response_buf, u32 response_buf_size)
> > {
> > return intel_guc_ct_send(>ct, action, len,
> > -response_buf, response_buf_size);
> > +response_buf, response_buf_size, 0);
> > }
> >
> > static inline void intel_guc_to_host_event_handler(struct intel_guc *guc)
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> > b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> > index a17215920e58..c9a65d05911f 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> > @@ -3,6 +3,11 @@
> > * Copyright © 2016-2019 Intel Corporation
> > */
> >
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > #include "i915_drv.h"
> > #include "intel_guc_ct.h"
> > #include "gt/intel_gt.h"
> > @@ -373,7 +378,7 @@ static void write_barrier(struct intel_guc_ct *ct)
> > static int ct_write(struct intel_guc_ct *ct,
> > const u32 *action,
> > u32 len /* in dwords */,
> > - u32 fence)
> > + u32 fence, u32 flags)
> > {
> > struct intel_guc_ct_buffer *ctb = >ctbs.send;
> > struct guc_ct_buffer_desc *desc = ctb->desc;
> > @@ -421,9 +426,13 @@ static int ct_write(struct intel_guc_ct *ct,
> > FIELD_PREP(GUC_CTB_MSG_0_NUM_DWORDS, len) |
> > FIELD_PREP(GUC_CTB_MSG_0_FENCE, fence);
> >
> > - hxg = FIELD_PREP(GUC_HXG_MSG_0_TYPE, GUC_HXG_TYPE_REQUEST) |
> > - FIELD_PREP(GUC_HXG_REQUEST_MSG_0_ACTION |
> > -GUC_HXG_REQUEST_MSG_0_DATA0, action[0]);
> > + hxg = (flags & INTEL_GUC_SEND_NB) ?
> > + (FIELD_PREP(GUC_HXG_MSG_0_TYPE, GUC_HXG_TYPE_EVENT) |
> > +FIELD_PREP(GUC_HXG_EVENT_MSG_0_ACTION |
> > + GUC_HXG_EVENT_MSG_0_DATA0, action[0])) :
> > + (FIELD_PREP(GUC_HXG_MSG_0_TYPE, GUC_HXG_TYPE_REQUEST) |
> > +FIELD_PREP(GUC_HXG_REQUEST_MSG_0_ACTION |
> > + GUC_HXG_REQUEST_MSG_0_DATA0, action[0]));
>
> or as we already switched to accept and return whole HXG messages in
> guc_send_mmio() maybe we should do the same for CTB variant too and
> instead of using extra flag just let caller to prepare proper HXG header
> with HXG_EVENT type and then in CTB code just look at this type to make
> decision which code path to use
>
Not sure I follow. Anyways could this be done in a follow up by you if
want this change.
> note that existing callers should not be impacted, as full HXG header
> for the REQUEST message looks exactly the same as "action" code alone.
>
> >
> > CT_DEBUG(ct, "writing (tail %u) %*ph %*ph %*ph\n",
> > tail, 4, , 4, , 4 * (len - 1), [1]);
> > @@ -498,6 +507,46 @@ static
[Intel-gfx] [PATCH v15 12/12] of: Add plumbing for restricted DMA pool
If a device is not behind an IOMMU, we look up the device node and set
up the restricted DMA when the restricted-dma-pool is presented.
Signed-off-by: Claire Chang
Tested-by: Stefano Stabellini
Tested-by: Will Deacon
---
drivers/of/address.c| 33 +
drivers/of/device.c | 3 +++
drivers/of/of_private.h | 6 ++
3 files changed, 42 insertions(+)
diff --git a/drivers/of/address.c b/drivers/of/address.c
index 73ddf2540f3f..cdf700fba5c4 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1022,6 +1023,38 @@ int of_dma_get_range(struct device_node *np, const
struct bus_dma_region **map)
of_node_put(node);
return ret;
}
+
+int of_dma_set_restricted_buffer(struct device *dev, struct device_node *np)
+{
+ struct device_node *node, *of_node = dev->of_node;
+ int count, i;
+
+ count = of_property_count_elems_of_size(of_node, "memory-region",
+ sizeof(u32));
+ /*
+* If dev->of_node doesn't exist or doesn't contain memory-region, try
+* the OF node having DMA configuration.
+*/
+ if (count <= 0) {
+ of_node = np;
+ count = of_property_count_elems_of_size(
+ of_node, "memory-region", sizeof(u32));
+ }
+
+ for (i = 0; i < count; i++) {
+ node = of_parse_phandle(of_node, "memory-region", i);
+ /*
+* There might be multiple memory regions, but only one
+* restricted-dma-pool region is allowed.
+*/
+ if (of_device_is_compatible(node, "restricted-dma-pool") &&
+ of_device_is_available(node))
+ return of_reserved_mem_device_init_by_idx(dev, of_node,
+ i);
+ }
+
+ return 0;
+}
#endif /* CONFIG_HAS_DMA */
/**
diff --git a/drivers/of/device.c b/drivers/of/device.c
index 6cb86de404f1..e68316836a7a 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -165,6 +165,9 @@ int of_dma_configure_id(struct device *dev, struct
device_node *np,
arch_setup_dma_ops(dev, dma_start, size, iommu, coherent);
+ if (!iommu)
+ return of_dma_set_restricted_buffer(dev, np);
+
return 0;
}
EXPORT_SYMBOL_GPL(of_dma_configure_id);
diff --git a/drivers/of/of_private.h b/drivers/of/of_private.h
index d9e6a324de0a..25cebbed5f02 100644
--- a/drivers/of/of_private.h
+++ b/drivers/of/of_private.h
@@ -161,12 +161,18 @@ struct bus_dma_region;
#if defined(CONFIG_OF_ADDRESS) && defined(CONFIG_HAS_DMA)
int of_dma_get_range(struct device_node *np,
const struct bus_dma_region **map);
+int of_dma_set_restricted_buffer(struct device *dev, struct device_node *np);
#else
static inline int of_dma_get_range(struct device_node *np,
const struct bus_dma_region **map)
{
return -ENODEV;
}
+static inline int of_dma_set_restricted_buffer(struct device *dev,
+ struct device_node *np)
+{
+ return -ENODEV;
+}
#endif
#endif /* _LINUX_OF_PRIVATE_H */
--
2.32.0.288.g62a8d224e6-goog
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v15 11/12] dt-bindings: of: Add restricted DMA pool
Introduce the new compatible string, restricted-dma-pool, for restricted
DMA. One can specify the address and length of the restricted DMA memory
region by restricted-dma-pool in the reserved-memory node.
Signed-off-by: Claire Chang
Tested-by: Stefano Stabellini
Tested-by: Will Deacon
---
.../reserved-memory/reserved-memory.txt | 36 +--
1 file changed, 33 insertions(+), 3 deletions(-)
diff --git
a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
index e8d3096d922c..39b5f4c5a511 100644
--- a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
+++ b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
@@ -51,6 +51,23 @@ compatible (optional) - standard definition
used as a shared pool of DMA buffers for a set of devices. It can
be used by an operating system to instantiate the necessary pool
management subsystem if necessary.
+- restricted-dma-pool: This indicates a region of memory meant to be
+ used as a pool of restricted DMA buffers for a set of devices. The
+ memory region would be the only region accessible to those devices.
+ When using this, the no-map and reusable properties must not be set,
+ so the operating system can create a virtual mapping that will be
used
+ for synchronization. The main purpose for restricted DMA is to
+ mitigate the lack of DMA access control on systems without an IOMMU,
+ which could result in the DMA accessing the system memory at
+ unexpected times and/or unexpected addresses, possibly leading to
data
+ leakage or corruption. The feature on its own provides a basic level
+ of protection against the DMA overwriting buffer contents at
+ unexpected times. However, to protect against general data leakage
and
+ system memory corruption, the system needs to provide way to lock
down
+ the memory access, e.g., MPU. Note that since coherent allocation
+ needs remapping, one must set up another device coherent pool by
+ shared-dma-pool and use dma_alloc_from_dev_coherent instead for
atomic
+ coherent allocation.
- vendor specific string in the form ,[-]
no-map (optional) - empty property
- Indicates the operating system must not create a virtual mapping
@@ -85,10 +102,11 @@ memory-region-names (optional) - a list of names, one for
each corresponding
Example
---
-This example defines 3 contiguous regions are defined for Linux kernel:
+This example defines 4 contiguous regions for Linux kernel:
one default of all device drivers (named linux,cma@7200 and 64MiB in size),
-one dedicated to the framebuffer device (named framebuffer@7800, 8MiB), and
-one for multimedia processing (named multimedia-memory@7700, 64MiB).
+one dedicated to the framebuffer device (named framebuffer@7800, 8MiB),
+one for multimedia processing (named multimedia-memory@7700, 64MiB), and
+one for restricted dma pool (named restricted_dma_reserved@0x5000, 64MiB).
/ {
#address-cells = <1>;
@@ -120,6 +138,11 @@ one for multimedia processing (named
multimedia-memory@7700, 64MiB).
compatible = "acme,multimedia-memory";
reg = <0x7700 0x400>;
};
+
+ restricted_dma_reserved: restricted_dma_reserved {
+ compatible = "restricted-dma-pool";
+ reg = <0x5000 0x400>;
+ };
};
/* ... */
@@ -138,4 +161,11 @@ one for multimedia processing (named
multimedia-memory@7700, 64MiB).
memory-region = <_reserved>;
/* ... */
};
+
+ pcie_device: pcie_device@0,0 {
+ reg = <0x8301 0x0 0x 0x0 0x0010
+ 0x8301 0x0 0x0010 0x0 0x0010>;
+ memory-region = <_dma_reserved>;
+ /* ... */
+ };
};
--
2.32.0.288.g62a8d224e6-goog
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v15 10/12] swiotlb: Add restricted DMA pool initialization
Add the initialization function to create restricted DMA pools from
matching reserved-memory nodes.
Regardless of swiotlb setting, the restricted DMA pool is preferred if
available.
The restricted DMA pools provide a basic level of protection against the
DMA overwriting buffer contents at unexpected times. However, to protect
against general data leakage and system memory corruption, the system
needs to provide a way to lock down the memory access, e.g., MPU.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
Tested-by: Stefano Stabellini
Tested-by: Will Deacon
---
include/linux/swiotlb.h | 3 +-
kernel/dma/Kconfig | 14
kernel/dma/swiotlb.c| 76 +
3 files changed, 92 insertions(+), 1 deletion(-)
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index 3b9454d1e498..39284ff2a6cd 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -73,7 +73,8 @@ extern enum swiotlb_force swiotlb_force;
* range check to see if the memory was in fact allocated by this
* API.
* @nslabs:The number of IO TLB blocks (in groups of 64) between @start and
- * @end. This is command line adjustable via setup_io_tlb_npages.
+ * @end. For default swiotlb, this is command line adjustable via
+ * setup_io_tlb_npages.
* @used: The number of used IO TLB block.
* @list: The free list describing the number of free entries available
* from each index.
diff --git a/kernel/dma/Kconfig b/kernel/dma/Kconfig
index 77b405508743..3e961dc39634 100644
--- a/kernel/dma/Kconfig
+++ b/kernel/dma/Kconfig
@@ -80,6 +80,20 @@ config SWIOTLB
bool
select NEED_DMA_MAP_STATE
+config DMA_RESTRICTED_POOL
+ bool "DMA Restricted Pool"
+ depends on OF && OF_RESERVED_MEM
+ select SWIOTLB
+ help
+ This enables support for restricted DMA pools which provide a level of
+ DMA memory protection on systems with limited hardware protection
+ capabilities, such as those lacking an IOMMU.
+
+ For more information see
+
+ and .
+ If unsure, say "n".
+
#
# Should be selected if we can mmap non-coherent mappings to userspace.
# The only thing that is really required is a way to set an uncached bit
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 6a7c6e30eb4b..3baf49c9b766 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -39,6 +39,13 @@
#ifdef CONFIG_DEBUG_FS
#include
#endif
+#ifdef CONFIG_DMA_RESTRICTED_POOL
+#include
+#include
+#include
+#include
+#include
+#endif
#include
#include
@@ -737,4 +744,73 @@ bool swiotlb_free(struct device *dev, struct page *page,
size_t size)
return true;
}
+static int rmem_swiotlb_device_init(struct reserved_mem *rmem,
+ struct device *dev)
+{
+ struct io_tlb_mem *mem = rmem->priv;
+ unsigned long nslabs = rmem->size >> IO_TLB_SHIFT;
+
+ /*
+* Since multiple devices can share the same pool, the private data,
+* io_tlb_mem struct, will be initialized by the first device attached
+* to it.
+*/
+ if (!mem) {
+ mem = kzalloc(struct_size(mem, slots, nslabs), GFP_KERNEL);
+ if (!mem)
+ return -ENOMEM;
+
+ set_memory_decrypted((unsigned long)phys_to_virt(rmem->base),
+rmem->size >> PAGE_SHIFT);
+ swiotlb_init_io_tlb_mem(mem, rmem->base, nslabs, false);
+ mem->force_bounce = true;
+ mem->for_alloc = true;
+
+ rmem->priv = mem;
+
+ if (IS_ENABLED(CONFIG_DEBUG_FS)) {
+ mem->debugfs =
+ debugfs_create_dir(rmem->name, debugfs_dir);
+ swiotlb_create_debugfs_files(mem);
+ }
+ }
+
+ dev->dma_io_tlb_mem = mem;
+
+ return 0;
+}
+
+static void rmem_swiotlb_device_release(struct reserved_mem *rmem,
+ struct device *dev)
+{
+ dev->dma_io_tlb_mem = io_tlb_default_mem;
+}
+
+static const struct reserved_mem_ops rmem_swiotlb_ops = {
+ .device_init = rmem_swiotlb_device_init,
+ .device_release = rmem_swiotlb_device_release,
+};
+
+static int __init rmem_swiotlb_setup(struct reserved_mem *rmem)
+{
+ unsigned long node = rmem->fdt_node;
+
+ if (of_get_flat_dt_prop(node, "reusable", NULL) ||
+ of_get_flat_dt_prop(node, "linux,cma-default", NULL) ||
+ of_get_flat_dt_prop(node, "linux,dma-default", NULL) ||
+ of_get_flat_dt_prop(node, "no-map", NULL))
+ return -EINVAL;
+
+ if (PageHighMem(pfn_to_page(PHYS_PFN(rmem->base {
+ pr_err("Restricted DMA pool must be accessible within the
linear mapping.");
+ return
[Intel-gfx] [PATCH v15 09/12] swiotlb: Add restricted DMA alloc/free support
Add the functions, swiotlb_{alloc,free} and is_swiotlb_for_alloc to
support the memory allocation from restricted DMA pool.
The restricted DMA pool is preferred if available.
Note that since coherent allocation needs remapping, one must set up
another device coherent pool by shared-dma-pool and use
dma_alloc_from_dev_coherent instead for atomic coherent allocation.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
Tested-by: Stefano Stabellini
Tested-by: Will Deacon
Acked-by: Stefano Stabellini
---
include/linux/swiotlb.h | 26 ++
kernel/dma/direct.c | 49 +++--
kernel/dma/swiotlb.c| 38 ++--
3 files changed, 99 insertions(+), 14 deletions(-)
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index da348671b0d5..3b9454d1e498 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -85,6 +85,7 @@ extern enum swiotlb_force swiotlb_force;
* @debugfs: The dentry to debugfs.
* @late_alloc:%true if allocated using the page allocator
* @force_bounce: %true if swiotlb bouncing is forced
+ * @for_alloc: %true if the pool is used for memory allocation
*/
struct io_tlb_mem {
phys_addr_t start;
@@ -96,6 +97,7 @@ struct io_tlb_mem {
struct dentry *debugfs;
bool late_alloc;
bool force_bounce;
+ bool for_alloc;
struct io_tlb_slot {
phys_addr_t orig_addr;
size_t alloc_size;
@@ -158,4 +160,28 @@ static inline void swiotlb_adjust_size(unsigned long size)
extern void swiotlb_print_info(void);
extern void swiotlb_set_max_segment(unsigned int);
+#ifdef CONFIG_DMA_RESTRICTED_POOL
+struct page *swiotlb_alloc(struct device *dev, size_t size);
+bool swiotlb_free(struct device *dev, struct page *page, size_t size);
+
+static inline bool is_swiotlb_for_alloc(struct device *dev)
+{
+ return dev->dma_io_tlb_mem->for_alloc;
+}
+#else
+static inline struct page *swiotlb_alloc(struct device *dev, size_t size)
+{
+ return NULL;
+}
+static inline bool swiotlb_free(struct device *dev, struct page *page,
+ size_t size)
+{
+ return false;
+}
+static inline bool is_swiotlb_for_alloc(struct device *dev)
+{
+ return false;
+}
+#endif /* CONFIG_DMA_RESTRICTED_POOL */
+
#endif /* __LINUX_SWIOTLB_H */
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index a92465b4eb12..2de33e5d302b 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -75,6 +75,15 @@ static bool dma_coherent_ok(struct device *dev, phys_addr_t
phys, size_t size)
min_not_zero(dev->coherent_dma_mask, dev->bus_dma_limit);
}
+static void __dma_direct_free_pages(struct device *dev, struct page *page,
+ size_t size)
+{
+ if (IS_ENABLED(CONFIG_DMA_RESTRICTED_POOL) &&
+ swiotlb_free(dev, page, size))
+ return;
+ dma_free_contiguous(dev, page, size);
+}
+
static struct page *__dma_direct_alloc_pages(struct device *dev, size_t size,
gfp_t gfp)
{
@@ -86,6 +95,16 @@ static struct page *__dma_direct_alloc_pages(struct device
*dev, size_t size,
gfp |= dma_direct_optimal_gfp_mask(dev, dev->coherent_dma_mask,
_limit);
+ if (IS_ENABLED(CONFIG_DMA_RESTRICTED_POOL) &&
+ is_swiotlb_for_alloc(dev)) {
+ page = swiotlb_alloc(dev, size);
+ if (page && !dma_coherent_ok(dev, page_to_phys(page), size)) {
+ __dma_direct_free_pages(dev, page, size);
+ return NULL;
+ }
+ return page;
+ }
+
page = dma_alloc_contiguous(dev, size, gfp);
if (page && !dma_coherent_ok(dev, page_to_phys(page), size)) {
dma_free_contiguous(dev, page, size);
@@ -142,7 +161,7 @@ void *dma_direct_alloc(struct device *dev, size_t size,
gfp |= __GFP_NOWARN;
if ((attrs & DMA_ATTR_NO_KERNEL_MAPPING) &&
- !force_dma_unencrypted(dev)) {
+ !force_dma_unencrypted(dev) && !is_swiotlb_for_alloc(dev)) {
page = __dma_direct_alloc_pages(dev, size, gfp & ~__GFP_ZERO);
if (!page)
return NULL;
@@ -155,18 +174,23 @@ void *dma_direct_alloc(struct device *dev, size_t size,
}
if (!IS_ENABLED(CONFIG_ARCH_HAS_DMA_SET_UNCACHED) &&
- !IS_ENABLED(CONFIG_DMA_DIRECT_REMAP) &&
- !dev_is_dma_coherent(dev))
+ !IS_ENABLED(CONFIG_DMA_DIRECT_REMAP) && !dev_is_dma_coherent(dev) &&
+ !is_swiotlb_for_alloc(dev))
return arch_dma_alloc(dev, size, dma_handle, gfp, attrs);
/*
* Remapping or decrypting memory may block. If either is required and
* we can't block, allocate the memory from the atomic pools.
+* If restricted DMA (i.e., is_swiotlb_for_alloc) is
[Intel-gfx] [PATCH v15 08/12] swiotlb: Refactor swiotlb_tbl_unmap_single
Add a new function, swiotlb_release_slots, to make the code reusable for
supporting different bounce buffer pools.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
Tested-by: Stefano Stabellini
Tested-by: Will Deacon
---
kernel/dma/swiotlb.c | 35 ---
1 file changed, 20 insertions(+), 15 deletions(-)
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index b41d16e92cf6..93752e752e76 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -557,27 +557,15 @@ phys_addr_t swiotlb_tbl_map_single(struct device *dev,
phys_addr_t orig_addr,
return tlb_addr;
}
-/*
- * tlb_addr is the physical address of the bounce buffer to unmap.
- */
-void swiotlb_tbl_unmap_single(struct device *hwdev, phys_addr_t tlb_addr,
- size_t mapping_size, enum dma_data_direction dir,
- unsigned long attrs)
+static void swiotlb_release_slots(struct device *dev, phys_addr_t tlb_addr)
{
- struct io_tlb_mem *mem = hwdev->dma_io_tlb_mem;
+ struct io_tlb_mem *mem = dev->dma_io_tlb_mem;
unsigned long flags;
- unsigned int offset = swiotlb_align_offset(hwdev, tlb_addr);
+ unsigned int offset = swiotlb_align_offset(dev, tlb_addr);
int index = (tlb_addr - offset - mem->start) >> IO_TLB_SHIFT;
int nslots = nr_slots(mem->slots[index].alloc_size + offset);
int count, i;
- /*
-* First, sync the memory before unmapping the entry
-*/
- if (!(attrs & DMA_ATTR_SKIP_CPU_SYNC) &&
- (dir == DMA_FROM_DEVICE || dir == DMA_BIDIRECTIONAL))
- swiotlb_bounce(hwdev, tlb_addr, mapping_size, DMA_FROM_DEVICE);
-
/*
* Return the buffer to the free list by setting the corresponding
* entries to indicate the number of contiguous entries available.
@@ -612,6 +600,23 @@ void swiotlb_tbl_unmap_single(struct device *hwdev,
phys_addr_t tlb_addr,
spin_unlock_irqrestore(>lock, flags);
}
+/*
+ * tlb_addr is the physical address of the bounce buffer to unmap.
+ */
+void swiotlb_tbl_unmap_single(struct device *dev, phys_addr_t tlb_addr,
+ size_t mapping_size, enum dma_data_direction dir,
+ unsigned long attrs)
+{
+ /*
+* First, sync the memory before unmapping the entry
+*/
+ if (!(attrs & DMA_ATTR_SKIP_CPU_SYNC) &&
+ (dir == DMA_FROM_DEVICE || dir == DMA_BIDIRECTIONAL))
+ swiotlb_bounce(dev, tlb_addr, mapping_size, DMA_FROM_DEVICE);
+
+ swiotlb_release_slots(dev, tlb_addr);
+}
+
void swiotlb_sync_single_for_device(struct device *dev, phys_addr_t tlb_addr,
size_t size, enum dma_data_direction dir)
{
--
2.32.0.288.g62a8d224e6-goog
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v15 07/12] swiotlb: Move alloc_size to swiotlb_find_slots
Rename find_slots to swiotlb_find_slots and move the maintenance of
alloc_size to it for better code reusability later.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
Tested-by: Stefano Stabellini
Tested-by: Will Deacon
---
kernel/dma/swiotlb.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 0d294bbf274c..b41d16e92cf6 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -432,8 +432,8 @@ static unsigned int wrap_index(struct io_tlb_mem *mem,
unsigned int index)
* Find a suitable number of IO TLB entries size that will fit this request and
* allocate a buffer from that IO TLB pool.
*/
-static int find_slots(struct device *dev, phys_addr_t orig_addr,
- size_t alloc_size)
+static int swiotlb_find_slots(struct device *dev, phys_addr_t orig_addr,
+ size_t alloc_size)
{
struct io_tlb_mem *mem = dev->dma_io_tlb_mem;
unsigned long boundary_mask = dma_get_seg_boundary(dev);
@@ -444,6 +444,7 @@ static int find_slots(struct device *dev, phys_addr_t
orig_addr,
dma_get_min_align_mask(dev) & ~(IO_TLB_SIZE - 1);
unsigned int nslots = nr_slots(alloc_size), stride;
unsigned int index, wrap, count = 0, i;
+ unsigned int offset = swiotlb_align_offset(dev, orig_addr);
unsigned long flags;
BUG_ON(!nslots);
@@ -488,8 +489,11 @@ static int find_slots(struct device *dev, phys_addr_t
orig_addr,
return -1;
found:
- for (i = index; i < index + nslots; i++)
+ for (i = index; i < index + nslots; i++) {
mem->slots[i].list = 0;
+ mem->slots[i].alloc_size =
+ alloc_size - (offset + ((i - index) << IO_TLB_SHIFT));
+ }
for (i = index - 1;
io_tlb_offset(i) != IO_TLB_SEGSIZE - 1 &&
mem->slots[i].list; i--)
@@ -530,7 +534,7 @@ phys_addr_t swiotlb_tbl_map_single(struct device *dev,
phys_addr_t orig_addr,
return (phys_addr_t)DMA_MAPPING_ERROR;
}
- index = find_slots(dev, orig_addr, alloc_size + offset);
+ index = swiotlb_find_slots(dev, orig_addr, alloc_size + offset);
if (index == -1) {
if (!(attrs & DMA_ATTR_NO_WARN))
dev_warn_ratelimited(dev,
@@ -544,11 +548,8 @@ phys_addr_t swiotlb_tbl_map_single(struct device *dev,
phys_addr_t orig_addr,
* This is needed when we sync the memory. Then we sync the buffer if
* needed.
*/
- for (i = 0; i < nr_slots(alloc_size + offset); i++) {
+ for (i = 0; i < nr_slots(alloc_size + offset); i++)
mem->slots[index + i].orig_addr = slot_addr(orig_addr, i);
- mem->slots[index + i].alloc_size =
- alloc_size - (i << IO_TLB_SHIFT);
- }
tlb_addr = slot_addr(mem->start, index) + offset;
if (!(attrs & DMA_ATTR_SKIP_CPU_SYNC) &&
(dir == DMA_TO_DEVICE || dir == DMA_BIDIRECTIONAL))
--
2.32.0.288.g62a8d224e6-goog
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v14 06/12] swiotlb: Use is_swiotlb_force_bounce for swiotlb data bouncing
On Thu, Jun 24, 2021 at 10:10:51AM -0400, Qian Cai wrote:
>
>
> On 6/24/2021 7:48 AM, Will Deacon wrote:
> > Ok, diff below which attempts to tackle the offset issue I mentioned as
> > well. Qian Cai -- please can you try with these changes?
>
> This works fine.
Cool. Let me squash this patch in #6 and rebase the rest of them.
Claire, could you check the devel/for-linus-5.14 say by end of today to
double check that I didn't mess anything up please?
Will,
Thank you for generating the fix! I am going to run it on x86 and Xen
to make sure all is good (granted last time I ran devel/for-linus-5.14
on that setup I didn't see any errors so I need to double check
I didn't do something silly like run a wrong kernel).
>
> >
> > Will
> >
> > --->8
> >
> > diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
> > index 175b6c113ed8..39284ff2a6cd 100644
> > --- a/include/linux/swiotlb.h
> > +++ b/include/linux/swiotlb.h
> > @@ -116,7 +116,9 @@ static inline bool is_swiotlb_buffer(struct device
> > *dev, phys_addr_t paddr)
> >
> > static inline bool is_swiotlb_force_bounce(struct device *dev)
> > {
> > - return dev->dma_io_tlb_mem->force_bounce;
> > + struct io_tlb_mem *mem = dev->dma_io_tlb_mem;
> > +
> > + return mem && mem->force_bounce;
> > }
> >
> > void __init swiotlb_exit(void);
> > diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
> > index 44be8258e27b..0ffbaae9fba2 100644
> > --- a/kernel/dma/swiotlb.c
> > +++ b/kernel/dma/swiotlb.c
> > @@ -449,6 +449,7 @@ static int swiotlb_find_slots(struct device *dev,
> > phys_addr_t orig_addr,
> > dma_get_min_align_mask(dev) & ~(IO_TLB_SIZE - 1);
> > unsigned int nslots = nr_slots(alloc_size), stride;
> > unsigned int index, wrap, count = 0, i;
> > + unsigned int offset = swiotlb_align_offset(dev, orig_addr);
> > unsigned long flags;
> >
> > BUG_ON(!nslots);
> > @@ -497,7 +498,7 @@ static int swiotlb_find_slots(struct device *dev,
> > phys_addr_t orig_addr,
> > for (i = index; i < index + nslots; i++) {
> > mem->slots[i].list = 0;
> > mem->slots[i].alloc_size =
> > - alloc_size - ((i - index) << IO_TLB_SHIFT);
> > + alloc_size - (offset + ((i - index) <<
> > IO_TLB_SHIFT));
> > }
> > for (i = index - 1;
> > io_tlb_offset(i) != IO_TLB_SEGSIZE - 1 &&
> >
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v15 06/12] swiotlb: Use is_swiotlb_force_bounce for swiotlb data bouncing
Propagate the swiotlb_force into io_tlb_default_mem->force_bounce and
use it to determine whether to bounce the data or not. This will be
useful later to allow for different pools.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
Tested-by: Stefano Stabellini
Tested-by: Will Deacon
Acked-by: Stefano Stabellini
---
drivers/xen/swiotlb-xen.c | 2 +-
include/linux/swiotlb.h | 13 +
kernel/dma/direct.c | 2 +-
kernel/dma/direct.h | 2 +-
kernel/dma/swiotlb.c | 4
5 files changed, 20 insertions(+), 3 deletions(-)
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 0c6ed09f8513..4730a146fa35 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -369,7 +369,7 @@ static dma_addr_t xen_swiotlb_map_page(struct device *dev,
struct page *page,
if (dma_capable(dev, dev_addr, size, true) &&
!range_straddles_page_boundary(phys, size) &&
!xen_arch_need_swiotlb(dev, phys, dev_addr) &&
- swiotlb_force != SWIOTLB_FORCE)
+ !is_swiotlb_force_bounce(dev))
goto done;
/*
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index dd1c30a83058..da348671b0d5 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -84,6 +84,7 @@ extern enum swiotlb_force swiotlb_force;
* unmap calls.
* @debugfs: The dentry to debugfs.
* @late_alloc:%true if allocated using the page allocator
+ * @force_bounce: %true if swiotlb bouncing is forced
*/
struct io_tlb_mem {
phys_addr_t start;
@@ -94,6 +95,7 @@ struct io_tlb_mem {
spinlock_t lock;
struct dentry *debugfs;
bool late_alloc;
+ bool force_bounce;
struct io_tlb_slot {
phys_addr_t orig_addr;
size_t alloc_size;
@@ -109,6 +111,13 @@ static inline bool is_swiotlb_buffer(struct device *dev,
phys_addr_t paddr)
return mem && paddr >= mem->start && paddr < mem->end;
}
+static inline bool is_swiotlb_force_bounce(struct device *dev)
+{
+ struct io_tlb_mem *mem = dev->dma_io_tlb_mem;
+
+ return mem && mem->force_bounce;
+}
+
void __init swiotlb_exit(void);
unsigned int swiotlb_max_segment(void);
size_t swiotlb_max_mapping_size(struct device *dev);
@@ -120,6 +129,10 @@ static inline bool is_swiotlb_buffer(struct device *dev,
phys_addr_t paddr)
{
return false;
}
+static inline bool is_swiotlb_force_bounce(struct device *dev)
+{
+ return false;
+}
static inline void swiotlb_exit(void)
{
}
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 7a88c34d0867..a92465b4eb12 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -496,7 +496,7 @@ size_t dma_direct_max_mapping_size(struct device *dev)
{
/* If SWIOTLB is active, use its maximum mapping size */
if (is_swiotlb_active(dev) &&
- (dma_addressing_limited(dev) || swiotlb_force == SWIOTLB_FORCE))
+ (dma_addressing_limited(dev) || is_swiotlb_force_bounce(dev)))
return swiotlb_max_mapping_size(dev);
return SIZE_MAX;
}
diff --git a/kernel/dma/direct.h b/kernel/dma/direct.h
index 13e9e7158d94..4632b0f4f72e 100644
--- a/kernel/dma/direct.h
+++ b/kernel/dma/direct.h
@@ -87,7 +87,7 @@ static inline dma_addr_t dma_direct_map_page(struct device
*dev,
phys_addr_t phys = page_to_phys(page) + offset;
dma_addr_t dma_addr = phys_to_dma(dev, phys);
- if (unlikely(swiotlb_force == SWIOTLB_FORCE))
+ if (is_swiotlb_force_bounce(dev))
return swiotlb_map(dev, phys, size, dir, attrs);
if (unlikely(!dma_capable(dev, dma_addr, size, true))) {
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 8a120f42340b..0d294bbf274c 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -179,6 +179,10 @@ static void swiotlb_init_io_tlb_mem(struct io_tlb_mem
*mem, phys_addr_t start,
mem->end = mem->start + bytes;
mem->index = 0;
mem->late_alloc = late_alloc;
+
+ if (swiotlb_force == SWIOTLB_FORCE)
+ mem->force_bounce = true;
+
spin_lock_init(>lock);
for (i = 0; i < mem->nslabs; i++) {
mem->slots[i].list = IO_TLB_SEGSIZE - io_tlb_offset(i);
--
2.32.0.288.g62a8d224e6-goog
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v15 05/12] swiotlb: Update is_swiotlb_active to add a struct device argument
Update is_swiotlb_active to add a struct device argument. This will be
useful later to allow for different pools.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
Tested-by: Stefano Stabellini
Tested-by: Will Deacon
Acked-by: Stefano Stabellini
---
drivers/gpu/drm/i915/gem/i915_gem_internal.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_ttm.c| 2 +-
drivers/pci/xen-pcifront.c | 2 +-
include/linux/swiotlb.h | 4 ++--
kernel/dma/direct.c | 2 +-
kernel/dma/swiotlb.c | 4 ++--
6 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_internal.c
b/drivers/gpu/drm/i915/gem/i915_gem_internal.c
index a9d65fc8aa0e..4b7afa0fc85d 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_internal.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_internal.c
@@ -42,7 +42,7 @@ static int i915_gem_object_get_pages_internal(struct
drm_i915_gem_object *obj)
max_order = MAX_ORDER;
#ifdef CONFIG_SWIOTLB
- if (is_swiotlb_active()) {
+ if (is_swiotlb_active(obj->base.dev->dev)) {
unsigned int max_segment;
max_segment = swiotlb_max_segment();
diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c
b/drivers/gpu/drm/nouveau/nouveau_ttm.c
index 9662522aa066..be15bfd9e0ee 100644
--- a/drivers/gpu/drm/nouveau/nouveau_ttm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_ttm.c
@@ -321,7 +321,7 @@ nouveau_ttm_init(struct nouveau_drm *drm)
}
#if IS_ENABLED(CONFIG_SWIOTLB) && IS_ENABLED(CONFIG_X86)
- need_swiotlb = is_swiotlb_active();
+ need_swiotlb = is_swiotlb_active(dev->dev);
#endif
ret = ttm_bo_device_init(>ttm.bdev, _bo_driver,
diff --git a/drivers/pci/xen-pcifront.c b/drivers/pci/xen-pcifront.c
index b7a8f3a1921f..0d56985bfe81 100644
--- a/drivers/pci/xen-pcifront.c
+++ b/drivers/pci/xen-pcifront.c
@@ -693,7 +693,7 @@ static int pcifront_connect_and_init_dma(struct
pcifront_device *pdev)
spin_unlock(_dev_lock);
- if (!err && !is_swiotlb_active()) {
+ if (!err && !is_swiotlb_active(>xdev->dev)) {
err = pci_xen_swiotlb_init_late();
if (err)
dev_err(>xdev->dev, "Could not setup SWIOTLB!\n");
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index d1f3d95881cd..dd1c30a83058 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -112,7 +112,7 @@ static inline bool is_swiotlb_buffer(struct device *dev,
phys_addr_t paddr)
void __init swiotlb_exit(void);
unsigned int swiotlb_max_segment(void);
size_t swiotlb_max_mapping_size(struct device *dev);
-bool is_swiotlb_active(void);
+bool is_swiotlb_active(struct device *dev);
void __init swiotlb_adjust_size(unsigned long size);
#else
#define swiotlb_force SWIOTLB_NO_FORCE
@@ -132,7 +132,7 @@ static inline size_t swiotlb_max_mapping_size(struct device
*dev)
return SIZE_MAX;
}
-static inline bool is_swiotlb_active(void)
+static inline bool is_swiotlb_active(struct device *dev)
{
return false;
}
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 84c9feb5474a..7a88c34d0867 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -495,7 +495,7 @@ int dma_direct_supported(struct device *dev, u64 mask)
size_t dma_direct_max_mapping_size(struct device *dev)
{
/* If SWIOTLB is active, use its maximum mapping size */
- if (is_swiotlb_active() &&
+ if (is_swiotlb_active(dev) &&
(dma_addressing_limited(dev) || swiotlb_force == SWIOTLB_FORCE))
return swiotlb_max_mapping_size(dev);
return SIZE_MAX;
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 72a4289faed1..8a120f42340b 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -664,9 +664,9 @@ size_t swiotlb_max_mapping_size(struct device *dev)
return ((size_t)IO_TLB_SIZE) * IO_TLB_SEGSIZE;
}
-bool is_swiotlb_active(void)
+bool is_swiotlb_active(struct device *dev)
{
- return io_tlb_default_mem != NULL;
+ return dev->dma_io_tlb_mem != NULL;
}
EXPORT_SYMBOL_GPL(is_swiotlb_active);
--
2.32.0.288.g62a8d224e6-goog
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v15 04/12] swiotlb: Update is_swiotlb_buffer to add a struct device argument
Update is_swiotlb_buffer to add a struct device argument. This will be
useful later to allow for different pools.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
Tested-by: Stefano Stabellini
Tested-by: Will Deacon
Acked-by: Stefano Stabellini
---
drivers/iommu/dma-iommu.c | 12 ++--
drivers/xen/swiotlb-xen.c | 2 +-
include/linux/swiotlb.h | 7 ---
kernel/dma/direct.c | 6 +++---
kernel/dma/direct.h | 6 +++---
5 files changed, 17 insertions(+), 16 deletions(-)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 3087d9fa6065..10997ef541f8 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -507,7 +507,7 @@ static void __iommu_dma_unmap_swiotlb(struct device *dev,
dma_addr_t dma_addr,
__iommu_dma_unmap(dev, dma_addr, size);
- if (unlikely(is_swiotlb_buffer(phys)))
+ if (unlikely(is_swiotlb_buffer(dev, phys)))
swiotlb_tbl_unmap_single(dev, phys, size, dir, attrs);
}
@@ -578,7 +578,7 @@ static dma_addr_t __iommu_dma_map_swiotlb(struct device
*dev, phys_addr_t phys,
}
iova = __iommu_dma_map(dev, phys, aligned_size, prot, dma_mask);
- if (iova == DMA_MAPPING_ERROR && is_swiotlb_buffer(phys))
+ if (iova == DMA_MAPPING_ERROR && is_swiotlb_buffer(dev, phys))
swiotlb_tbl_unmap_single(dev, phys, org_size, dir, attrs);
return iova;
}
@@ -749,7 +749,7 @@ static void iommu_dma_sync_single_for_cpu(struct device
*dev,
if (!dev_is_dma_coherent(dev))
arch_sync_dma_for_cpu(phys, size, dir);
- if (is_swiotlb_buffer(phys))
+ if (is_swiotlb_buffer(dev, phys))
swiotlb_sync_single_for_cpu(dev, phys, size, dir);
}
@@ -762,7 +762,7 @@ static void iommu_dma_sync_single_for_device(struct device
*dev,
return;
phys = iommu_iova_to_phys(iommu_get_dma_domain(dev), dma_handle);
- if (is_swiotlb_buffer(phys))
+ if (is_swiotlb_buffer(dev, phys))
swiotlb_sync_single_for_device(dev, phys, size, dir);
if (!dev_is_dma_coherent(dev))
@@ -783,7 +783,7 @@ static void iommu_dma_sync_sg_for_cpu(struct device *dev,
if (!dev_is_dma_coherent(dev))
arch_sync_dma_for_cpu(sg_phys(sg), sg->length, dir);
- if (is_swiotlb_buffer(sg_phys(sg)))
+ if (is_swiotlb_buffer(dev, sg_phys(sg)))
swiotlb_sync_single_for_cpu(dev, sg_phys(sg),
sg->length, dir);
}
@@ -800,7 +800,7 @@ static void iommu_dma_sync_sg_for_device(struct device *dev,
return;
for_each_sg(sgl, sg, nelems, i) {
- if (is_swiotlb_buffer(sg_phys(sg)))
+ if (is_swiotlb_buffer(dev, sg_phys(sg)))
swiotlb_sync_single_for_device(dev, sg_phys(sg),
sg->length, dir);
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 4c89afc0df62..0c6ed09f8513 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -100,7 +100,7 @@ static int is_xen_swiotlb_buffer(struct device *dev,
dma_addr_t dma_addr)
* in our domain. Therefore _only_ check address within our domain.
*/
if (pfn_valid(PFN_DOWN(paddr)))
- return is_swiotlb_buffer(paddr);
+ return is_swiotlb_buffer(dev, paddr);
return 0;
}
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index 216854a5e513..d1f3d95881cd 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -2,6 +2,7 @@
#ifndef __LINUX_SWIOTLB_H
#define __LINUX_SWIOTLB_H
+#include
#include
#include
#include
@@ -101,9 +102,9 @@ struct io_tlb_mem {
};
extern struct io_tlb_mem *io_tlb_default_mem;
-static inline bool is_swiotlb_buffer(phys_addr_t paddr)
+static inline bool is_swiotlb_buffer(struct device *dev, phys_addr_t paddr)
{
- struct io_tlb_mem *mem = io_tlb_default_mem;
+ struct io_tlb_mem *mem = dev->dma_io_tlb_mem;
return mem && paddr >= mem->start && paddr < mem->end;
}
@@ -115,7 +116,7 @@ bool is_swiotlb_active(void);
void __init swiotlb_adjust_size(unsigned long size);
#else
#define swiotlb_force SWIOTLB_NO_FORCE
-static inline bool is_swiotlb_buffer(phys_addr_t paddr)
+static inline bool is_swiotlb_buffer(struct device *dev, phys_addr_t paddr)
{
return false;
}
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index f737e3347059..84c9feb5474a 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -343,7 +343,7 @@ void dma_direct_sync_sg_for_device(struct device *dev,
for_each_sg(sgl, sg, nents, i) {
phys_addr_t paddr = dma_to_phys(dev, sg_dma_address(sg));
- if (unlikely(is_swiotlb_buffer(paddr)))
+ if (unlikely(is_swiotlb_buffer(dev, paddr)))
[Intel-gfx] [PATCH v15 03/12] swiotlb: Set dev->dma_io_tlb_mem to the swiotlb pool used
Always have the pointer to the swiotlb pool used in struct device. This
could help simplify the code for other pools.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
Tested-by: Stefano Stabellini
Tested-by: Will Deacon
Acked-by: Stefano Stabellini
---
drivers/base/core.c| 4
include/linux/device.h | 4
kernel/dma/swiotlb.c | 8
3 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index f29839382f81..cb3123e3954d 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
#include
#include /* for dma_default_coherent */
@@ -2736,6 +2737,9 @@ void device_initialize(struct device *dev)
defined(CONFIG_ARCH_HAS_SYNC_DMA_FOR_CPU_ALL)
dev->dma_coherent = dma_default_coherent;
#endif
+#ifdef CONFIG_SWIOTLB
+ dev->dma_io_tlb_mem = io_tlb_default_mem;
+#endif
}
EXPORT_SYMBOL_GPL(device_initialize);
diff --git a/include/linux/device.h b/include/linux/device.h
index ba660731bd25..240d652a0696 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -416,6 +416,7 @@ struct dev_links_info {
* @dma_pools: Dma pools (if dma'ble device).
* @dma_mem: Internal for coherent mem override.
* @cma_area: Contiguous memory area for dma allocations
+ * @dma_io_tlb_mem: Pointer to the swiotlb pool used. Not for driver use.
* @archdata: For arch-specific additions.
* @of_node: Associated device tree node.
* @fwnode:Associated device node supplied by platform firmware.
@@ -518,6 +519,9 @@ struct device {
#ifdef CONFIG_DMA_CMA
struct cma *cma_area; /* contiguous memory area for dma
allocations */
+#endif
+#ifdef CONFIG_SWIOTLB
+ struct io_tlb_mem *dma_io_tlb_mem;
#endif
/* arch specific additions */
struct dev_archdata archdata;
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index ede66df6835b..72a4289faed1 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -340,7 +340,7 @@ void __init swiotlb_exit(void)
static void swiotlb_bounce(struct device *dev, phys_addr_t tlb_addr, size_t
size,
enum dma_data_direction dir)
{
- struct io_tlb_mem *mem = io_tlb_default_mem;
+ struct io_tlb_mem *mem = dev->dma_io_tlb_mem;
int index = (tlb_addr - mem->start) >> IO_TLB_SHIFT;
unsigned int offset = (tlb_addr - mem->start) & (IO_TLB_SIZE - 1);
phys_addr_t orig_addr = mem->slots[index].orig_addr;
@@ -431,7 +431,7 @@ static unsigned int wrap_index(struct io_tlb_mem *mem,
unsigned int index)
static int find_slots(struct device *dev, phys_addr_t orig_addr,
size_t alloc_size)
{
- struct io_tlb_mem *mem = io_tlb_default_mem;
+ struct io_tlb_mem *mem = dev->dma_io_tlb_mem;
unsigned long boundary_mask = dma_get_seg_boundary(dev);
dma_addr_t tbl_dma_addr =
phys_to_dma_unencrypted(dev, mem->start) & boundary_mask;
@@ -508,7 +508,7 @@ phys_addr_t swiotlb_tbl_map_single(struct device *dev,
phys_addr_t orig_addr,
size_t mapping_size, size_t alloc_size,
enum dma_data_direction dir, unsigned long attrs)
{
- struct io_tlb_mem *mem = io_tlb_default_mem;
+ struct io_tlb_mem *mem = dev->dma_io_tlb_mem;
unsigned int offset = swiotlb_align_offset(dev, orig_addr);
unsigned int i;
int index;
@@ -559,7 +559,7 @@ void swiotlb_tbl_unmap_single(struct device *hwdev,
phys_addr_t tlb_addr,
size_t mapping_size, enum dma_data_direction dir,
unsigned long attrs)
{
- struct io_tlb_mem *mem = io_tlb_default_mem;
+ struct io_tlb_mem *mem = hwdev->dma_io_tlb_mem;
unsigned long flags;
unsigned int offset = swiotlb_align_offset(hwdev, tlb_addr);
int index = (tlb_addr - offset - mem->start) >> IO_TLB_SHIFT;
--
2.32.0.288.g62a8d224e6-goog
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v15 02/12] swiotlb: Refactor swiotlb_create_debugfs
Split the debugfs creation to make the code reusable for supporting
different bounce buffer pools.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
Tested-by: Stefano Stabellini
Tested-by: Will Deacon
---
kernel/dma/swiotlb.c | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 1f9b2b9e7490..ede66df6835b 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -671,19 +671,26 @@ bool is_swiotlb_active(void)
EXPORT_SYMBOL_GPL(is_swiotlb_active);
#ifdef CONFIG_DEBUG_FS
+static struct dentry *debugfs_dir;
-static int __init swiotlb_create_debugfs(void)
+static void swiotlb_create_debugfs_files(struct io_tlb_mem *mem)
{
- struct io_tlb_mem *mem = io_tlb_default_mem;
-
- if (!mem)
- return 0;
- mem->debugfs = debugfs_create_dir("swiotlb", NULL);
debugfs_create_ulong("io_tlb_nslabs", 0400, mem->debugfs, >nslabs);
debugfs_create_ulong("io_tlb_used", 0400, mem->debugfs, >used);
+}
+
+static int __init swiotlb_create_default_debugfs(void)
+{
+ struct io_tlb_mem *mem = io_tlb_default_mem;
+
+ debugfs_dir = debugfs_create_dir("swiotlb", NULL);
+ if (mem) {
+ mem->debugfs = debugfs_dir;
+ swiotlb_create_debugfs_files(mem);
+ }
return 0;
}
-late_initcall(swiotlb_create_debugfs);
+late_initcall(swiotlb_create_default_debugfs);
#endif
--
2.32.0.288.g62a8d224e6-goog
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v15 01/12] swiotlb: Refactor swiotlb init functions
Add a new function, swiotlb_init_io_tlb_mem, for the io_tlb_mem struct
initialization to make the code reusable.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
Tested-by: Stefano Stabellini
Tested-by: Will Deacon
Acked-by: Stefano Stabellini
---
kernel/dma/swiotlb.c | 50 ++--
1 file changed, 25 insertions(+), 25 deletions(-)
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 52e2ac526757..1f9b2b9e7490 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -168,9 +168,28 @@ void __init swiotlb_update_mem_attributes(void)
memset(vaddr, 0, bytes);
}
-int __init swiotlb_init_with_tbl(char *tlb, unsigned long nslabs, int verbose)
+static void swiotlb_init_io_tlb_mem(struct io_tlb_mem *mem, phys_addr_t start,
+ unsigned long nslabs, bool late_alloc)
{
+ void *vaddr = phys_to_virt(start);
unsigned long bytes = nslabs << IO_TLB_SHIFT, i;
+
+ mem->nslabs = nslabs;
+ mem->start = start;
+ mem->end = mem->start + bytes;
+ mem->index = 0;
+ mem->late_alloc = late_alloc;
+ spin_lock_init(>lock);
+ for (i = 0; i < mem->nslabs; i++) {
+ mem->slots[i].list = IO_TLB_SEGSIZE - io_tlb_offset(i);
+ mem->slots[i].orig_addr = INVALID_PHYS_ADDR;
+ mem->slots[i].alloc_size = 0;
+ }
+ memset(vaddr, 0, bytes);
+}
+
+int __init swiotlb_init_with_tbl(char *tlb, unsigned long nslabs, int verbose)
+{
struct io_tlb_mem *mem;
size_t alloc_size;
@@ -186,16 +205,8 @@ int __init swiotlb_init_with_tbl(char *tlb, unsigned long
nslabs, int verbose)
if (!mem)
panic("%s: Failed to allocate %zu bytes align=0x%lx\n",
__func__, alloc_size, PAGE_SIZE);
- mem->nslabs = nslabs;
- mem->start = __pa(tlb);
- mem->end = mem->start + bytes;
- mem->index = 0;
- spin_lock_init(>lock);
- for (i = 0; i < mem->nslabs; i++) {
- mem->slots[i].list = IO_TLB_SEGSIZE - io_tlb_offset(i);
- mem->slots[i].orig_addr = INVALID_PHYS_ADDR;
- mem->slots[i].alloc_size = 0;
- }
+
+ swiotlb_init_io_tlb_mem(mem, __pa(tlb), nslabs, false);
io_tlb_default_mem = mem;
if (verbose)
@@ -282,8 +293,8 @@ swiotlb_late_init_with_default_size(size_t default_size)
int
swiotlb_late_init_with_tbl(char *tlb, unsigned long nslabs)
{
- unsigned long bytes = nslabs << IO_TLB_SHIFT, i;
struct io_tlb_mem *mem;
+ unsigned long bytes = nslabs << IO_TLB_SHIFT;
if (swiotlb_force == SWIOTLB_NO_FORCE)
return 0;
@@ -297,20 +308,9 @@ swiotlb_late_init_with_tbl(char *tlb, unsigned long nslabs)
if (!mem)
return -ENOMEM;
- mem->nslabs = nslabs;
- mem->start = virt_to_phys(tlb);
- mem->end = mem->start + bytes;
- mem->index = 0;
- mem->late_alloc = 1;
- spin_lock_init(>lock);
- for (i = 0; i < mem->nslabs; i++) {
- mem->slots[i].list = IO_TLB_SEGSIZE - io_tlb_offset(i);
- mem->slots[i].orig_addr = INVALID_PHYS_ADDR;
- mem->slots[i].alloc_size = 0;
- }
-
+ memset(mem, 0, sizeof(*mem));
set_memory_decrypted((unsigned long)tlb, bytes >> PAGE_SHIFT);
- memset(tlb, 0, bytes);
+ swiotlb_init_io_tlb_mem(mem, virt_to_phys(tlb), nslabs, true);
io_tlb_default_mem = mem;
swiotlb_print_info();
--
2.32.0.288.g62a8d224e6-goog
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v15 00/12] Restricted DMA
This series implements mitigations for lack of DMA access control on systems without an IOMMU, which could result in the DMA accessing the system memory at unexpected times and/or unexpected addresses, possibly leading to data leakage or corruption. For example, we plan to use the PCI-e bus for Wi-Fi and that PCI-e bus is not behind an IOMMU. As PCI-e, by design, gives the device full access to system memory, a vulnerability in the Wi-Fi firmware could easily escalate to a full system exploit (remote wifi exploits: [1a], [1b] that shows a full chain of exploits; [2], [3]). To mitigate the security concerns, we introduce restricted DMA. Restricted DMA utilizes the existing swiotlb to bounce streaming DMA in and out of a specially allocated region and does memory allocation from the same region. The feature on its own provides a basic level of protection against the DMA overwriting buffer contents at unexpected times. However, to protect against general data leakage and system memory corruption, the system needs to provide a way to restrict the DMA to a predefined memory region (this is usually done at firmware level, e.g. MPU in ATF on some ARM platforms [4]). [1a] https://googleprojectzero.blogspot.com/2017/04/over-air-exploiting-broadcoms-wi-fi_4.html [1b] https://googleprojectzero.blogspot.com/2017/04/over-air-exploiting-broadcoms-wi-fi_11.html [2] https://blade.tencent.com/en/advisories/qualpwn/ [3] https://www.bleepingcomputer.com/news/security/vulnerabilities-found-in-highly-popular-firmware-for-wifi-chips/ [4] https://github.com/ARM-software/arm-trusted-firmware/blob/master/plat/mediatek/mt8183/drivers/emi_mpu/emi_mpu.c#L132 v15: - Apply Will's diff (https://lore.kernel.org/patchwork/patch/1448957/#1647521) to fix the crash reported by Qian. - Add Stefano's Acked-by tag for patch 01/12 from v14 v14: - Move set_memory_decrypted before swiotlb_init_io_tlb_mem (patch 01/12, 10,12) - Add Stefano's Acked-by tag from v13 https://lore.kernel.org/patchwork/cover/1448954/ v13: - Fix xen-swiotlb issues - memset in patch 01/12 - is_swiotlb_force_bounce in patch 06/12 - Fix the dts example typo in reserved-memory.txt - Add Stefano and Will's Tested-by tag from v12 https://lore.kernel.org/patchwork/cover/1448001/ v12: Split is_dev_swiotlb_force into is_swiotlb_force_bounce (patch 06/12) and is_swiotlb_for_alloc (patch 09/12) https://lore.kernel.org/patchwork/cover/1447254/ v11: - Rebase against swiotlb devel/for-linus-5.14 - s/mempry/memory/g - exchange the order of patch 09/12 and 10/12 https://lore.kernel.org/patchwork/cover/1447216/ v10: Address the comments in v9 to - fix the dev->dma_io_tlb_mem assignment - propagate swiotlb_force setting into io_tlb_default_mem->force - move set_memory_decrypted out of swiotlb_init_io_tlb_mem - move debugfs_dir declaration into the main CONFIG_DEBUG_FS block - add swiotlb_ prefix to find_slots and release_slots - merge the 3 alloc/free related patches - move the CONFIG_DMA_RESTRICTED_POOL later https://lore.kernel.org/patchwork/cover/1446882/ v9: Address the comments in v7 to - set swiotlb active pool to dev->dma_io_tlb_mem - get rid of get_io_tlb_mem - dig out the device struct for is_swiotlb_active - move debugfs_create_dir out of swiotlb_create_debugfs - do set_memory_decrypted conditionally in swiotlb_init_io_tlb_mem - use IS_ENABLED in kernel/dma/direct.c - fix redefinition of 'of_dma_set_restricted_buffer' https://lore.kernel.org/patchwork/cover/1445081/ v8: - Fix reserved-memory.txt and add the reg property in example. - Fix sizeof for of_property_count_elems_of_size in drivers/of/address.c#of_dma_set_restricted_buffer. - Apply Will's suggestion to try the OF node having DMA configuration in drivers/of/address.c#of_dma_set_restricted_buffer. - Fix typo in the comment of drivers/of/address.c#of_dma_set_restricted_buffer. - Add error message for PageHighMem in kernel/dma/swiotlb.c#rmem_swiotlb_device_init and move it to rmem_swiotlb_setup. - Fix the message string in rmem_swiotlb_setup. https://lore.kernel.org/patchwork/cover/1437112/ v7: Fix debugfs, PageHighMem and comment style in rmem_swiotlb_device_init https://lore.kernel.org/patchwork/cover/1431031/ v6: Address the comments in v5 https://lore.kernel.org/patchwork/cover/1423201/ v5: Rebase on latest linux-next https://lore.kernel.org/patchwork/cover/1416899/ v4: - Fix spinlock bad magic - Use rmem->name for debugfs entry - Address the comments in v3 https://lore.kernel.org/patchwork/cover/1378113/ v3: Using only one reserved memory region for both streaming DMA and memory allocation. https://lore.kernel.org/patchwork/cover/1360992/ v2: Building on top of swiotlb. https://lore.kernel.org/patchwork/cover/1280705/ v1: Using dma_map_ops. https://lore.kernel.org/patchwork/cover/1271660/ Claire Chang (12): swiotlb: Refactor swiotlb init functions swiotlb: Refactor swiotlb_create_debugfs swiotlb: Set dev->dma_io_tlb_mem to the swiotlb pool used
Re: [Intel-gfx] [PATCH 03/47] drm/i915/guc: Increase size of CTB buffers
On Thu, Jun 24, 2021 at 03:49:55PM +0200, Michal Wajdeczko wrote:
>
>
> On 24.06.2021 09:04, Matthew Brost wrote:
> > With the introduction of non-blocking CTBs more than one CTB can be in
> > flight at a time. Increasing the size of the CTBs should reduce how
> > often software hits the case where no space is available in the CTB
> > buffer.
> >
> > Cc: John Harrison
> > Signed-off-by: Matthew Brost
> > ---
> > drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 11 ---
> > 1 file changed, 8 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> > b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> > index 07f080ddb9ae..a17215920e58 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> > @@ -58,11 +58,16 @@ static inline struct drm_device *ct_to_drm(struct
> > intel_guc_ct *ct)
> > * ++---+--+
> > *
> > * Size of each `CT Buffer`_ must be multiple of 4K.
> > - * As we don't expect too many messages, for now use minimum sizes.
> > + * We don't expect too many messages in flight at any time, unless we are
> > + * using the GuC submission. In that case each request requires a minimum
> > + * 2 dwords which gives us a maximum 256 queue'd requests. Hopefully this
> > + * enough space to avoid backpressure on the driver. We increase the size
> > + * of the receive buffer (relative to the send) to ensure a G2H response
> > + * CTB has a landing spot.
> > */
> > #define CTB_DESC_SIZE ALIGN(sizeof(struct
> > guc_ct_buffer_desc), SZ_2K)
> > #define CTB_H2G_BUFFER_SIZE(SZ_4K)
> > -#define CTB_G2H_BUFFER_SIZE(SZ_4K)
> > +#define CTB_G2H_BUFFER_SIZE(4 * CTB_H2G_BUFFER_SIZE)
> >
> > struct ct_request {
> > struct list_head link;
> > @@ -641,7 +646,7 @@ static int ct_read(struct intel_guc_ct *ct, struct
> > ct_incoming_msg **msg)
> > /* beware of buffer wrap case */
> > if (unlikely(available < 0))
> > available += size;
> > - CT_DEBUG(ct, "available %d (%u:%u)\n", available, head, tail);
> > + CT_DEBUG(ct, "available %d (%u:%u:%u)\n", available, head, tail, size);
>
> CTB size is already printed in intel_guc_ct_init() and is fixed so not
> sure if repeating it on every ct_read has any benefit
>
I'd say more debug the better and if CT_DEBUG is enabled the logs are
very verbose so an extra value doesn't really hurt.
Matt
> > GEM_BUG_ON(available < 0);
> >
> > header = cmds[head];
> >
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Reinstate the mmap ioctl for some platforms (rev2)
== Series Details == Series: drm/i915: Reinstate the mmap ioctl for some platforms (rev2) URL : https://patchwork.freedesktop.org/series/91865/ State : success == Summary == CI Bug Log - changes from CI_DRM_10276 -> Patchwork_20455 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20455/index.html Known issues Here are the changes found in Patchwork_20455 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live@execlists: - fi-bsw-nick:[PASS][1] -> [INCOMPLETE][2] ([i915#2782] / [i915#2940]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10276/fi-bsw-nick/igt@i915_selftest@l...@execlists.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20455/fi-bsw-nick/igt@i915_selftest@l...@execlists.html * igt@runner@aborted: - fi-bsw-nick:NOTRUN -> [FAIL][3] ([fdo#109271] / [i915#1436]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20455/fi-bsw-nick/igt@run...@aborted.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436 [i915#2782]: https://gitlab.freedesktop.org/drm/intel/issues/2782 [i915#2940]: https://gitlab.freedesktop.org/drm/intel/issues/2940 Participating hosts (45 -> 40) -- Missing(5): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 fi-bdw-samus Build changes - * Linux: CI_DRM_10276 -> Patchwork_20455 CI-20190529: 20190529 CI_DRM_10276: dc72fe3798577491293de99bfcf132e5d321ab7e @ git://anongit.freedesktop.org/gfx-ci/linux IGT_6117: 3ba0a02404f243d6d8f232c6215163cc4b0fd699 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_20455: fa79f45b7695f89ccddfe7e3377b095bff8218f5 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == fa79f45b7695 drm/i915: Reinstate the mmap ioctl for some platforms == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20455/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Move system memory to TTM for discrete (rev10)
== Series Details ==
Series: drm/i915: Move system memory to TTM for discrete (rev10)
URL : https://patchwork.freedesktop.org/series/90898/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10273_full -> Patchwork_20452_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_20452_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_20452_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_20452_full:
### IGT changes ###
Possible regressions
* igt@sysfs_timeslice_duration@timeout@vecs0:
- shard-skl: [PASS][1] -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10273/shard-skl2/igt@sysfs_timeslice_duration@time...@vecs0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20452/shard-skl1/igt@sysfs_timeslice_duration@time...@vecs0.html
Warnings
* igt@kms_psr2_sf@primary-plane-update-sf-dmg-area-1:
- shard-iclb: [SKIP][3] ([i915#658]) -> [SKIP][4] +3 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10273/shard-iclb5/igt@kms_psr2...@primary-plane-update-sf-dmg-area-1.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20452/shard-iclb2/igt@kms_psr2...@primary-plane-update-sf-dmg-area-1.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@kms_ccs@pipe-c-bad-pixel-format-y_tiled_ccs}:
- shard-tglb: NOTRUN -> [SKIP][5]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20452/shard-tglb3/igt@kms_ccs@pipe-c-bad-pixel-format-y_tiled_ccs.html
Known issues
Here are the changes found in Patchwork_20452_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_create@create-clear:
- shard-glk: [PASS][6] -> [FAIL][7] ([i915#3160])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10273/shard-glk5/igt@gem_cre...@create-clear.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20452/shard-glk5/igt@gem_cre...@create-clear.html
* igt@gem_ctx_persistence@clone:
- shard-snb: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#1099]) +3
similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20452/shard-snb2/igt@gem_ctx_persiste...@clone.html
* igt@gem_eio@unwedge-stress:
- shard-tglb: [PASS][9] -> [TIMEOUT][10] ([i915#2369] / [i915#3063])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10273/shard-tglb3/igt@gem_...@unwedge-stress.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20452/shard-tglb8/igt@gem_...@unwedge-stress.html
- shard-iclb: [PASS][11] -> [TIMEOUT][12] ([i915#2369] /
[i915#2481] / [i915#3070])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10273/shard-iclb5/igt@gem_...@unwedge-stress.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20452/shard-iclb2/igt@gem_...@unwedge-stress.html
* igt@gem_exec_fair@basic-flow@rcs0:
- shard-tglb: [PASS][13] -> [FAIL][14] ([i915#2842])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10273/shard-tglb5/igt@gem_exec_fair@basic-f...@rcs0.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20452/shard-tglb8/igt@gem_exec_fair@basic-f...@rcs0.html
* igt@gem_exec_fair@basic-none-share@rcs0:
- shard-iclb: [PASS][15] -> [FAIL][16] ([i915#2842])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10273/shard-iclb1/igt@gem_exec_fair@basic-none-sh...@rcs0.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20452/shard-iclb6/igt@gem_exec_fair@basic-none-sh...@rcs0.html
* igt@gem_exec_fair@basic-none-solo@rcs0:
- shard-kbl: NOTRUN -> [FAIL][17] ([i915#2842])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20452/shard-kbl2/igt@gem_exec_fair@basic-none-s...@rcs0.html
* igt@gem_exec_fair@basic-pace@vcs1:
- shard-iclb: NOTRUN -> [FAIL][18] ([i915#2842]) +1 similar issue
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20452/shard-iclb2/igt@gem_exec_fair@basic-p...@vcs1.html
* igt@gem_exec_fair@basic-throttle@rcs0:
- shard-glk: [PASS][19] -> [FAIL][20] ([i915#2842])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10273/shard-glk6/igt@gem_exec_fair@basic-throt...@rcs0.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20452/shard-glk1/igt@gem_exec_fair@basic-throt...@rcs0.html
* igt@gem_exec_suspend@basic-s3:
- shard-kbl: NOTRUN -> [DMESG-WARN][21] ([i915#180]) +1 similar
issue
[21]:
Re: [Intel-gfx] [PATCH 0/6] KVM: Remove uses of struct page from x86 and arm64 MMU
On 24/06/21 14:57, Nicholas Piggin wrote: KVM: Fix page ref underflow for regions with valid but non-refcounted pages It doesn't really fix the underflow, it disallows mapping them in the first place. Since in principle things can break, I'd rather be explicit, so let's go with "KVM: do not allow mapping valid but non-reference-counted pages". It's possible to create a region which maps valid but non-refcounted pages (e.g., tail pages of non-compound higher order allocations). These host pages can then be returned by gfn_to_page, gfn_to_pfn, etc., family of APIs, which take a reference to the page, which takes it from 0 to 1. When the reference is dropped, this will free the page incorrectly. Fix this by only taking a reference on the page if it was non-zero, s/on the page/on valid pages/ (makes clear that invalid pages are fine without refcounting). Thank you *so* much, I'm awful at Linux mm. Paolo which indicates it is participating in normal refcounting (and can be released with put_page). Signed-off-by: Nicholas Piggin ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v6,RESEND,1/3] gpu: drm: separate panel orientation property creating and value setting
== Series Details ==
Series: series starting with [v6,RESEND,1/3] gpu: drm: separate panel
orientation property creating and value setting
URL : https://patchwork.freedesktop.org/series/91867/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10276 -> Patchwork_20454
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20454/index.html
Known issues
Here are the changes found in Patchwork_20454 that come from known issues:
### IGT changes ###
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[k.org#205379]: https://bugzilla.kernel.org/show_bug.cgi?id=205379
Participating hosts (45 -> 40)
--
Missing(5): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600
fi-bdw-samus
Build changes
-
* Linux: CI_DRM_10276 -> Patchwork_20454
CI-20190529: 20190529
CI_DRM_10276: dc72fe3798577491293de99bfcf132e5d321ab7e @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6117: 3ba0a02404f243d6d8f232c6215163cc4b0fd699 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_20454: d46a8e1bd812aa3619c3cd1d278bbb639bbaa7d0 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
d46a8e1bd812 arm64: dts: mt8183: Add panel rotation
39f7ae8abfee drm/mediatek: init panel orientation property
8e0b6d8e41b6 gpu: drm: separate panel orientation property creating and value
setting
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20454/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/2] drm/i915/dg1: Compute MEM Bandwidth using MCHBAR
== Series Details ==
Series: series starting with [1/2] drm/i915/dg1: Compute MEM Bandwidth using
MCHBAR
URL : https://patchwork.freedesktop.org/series/91848/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10273_full -> Patchwork_20451_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_20451_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_20451_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_20451_full:
### IGT changes ###
Possible regressions
* igt@gem_exec_endless@dispatch@rcs0:
- shard-iclb: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10273/shard-iclb4/igt@gem_exec_endless@dispa...@rcs0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20451/shard-iclb1/igt@gem_exec_endless@dispa...@rcs0.html
Warnings
* igt@kms_psr2_sf@primary-plane-update-sf-dmg-area-5:
- shard-iclb: [SKIP][3] ([i915#658]) -> [SKIP][4] +1 similar issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10273/shard-iclb4/igt@kms_psr2...@primary-plane-update-sf-dmg-area-5.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20451/shard-iclb2/igt@kms_psr2...@primary-plane-update-sf-dmg-area-5.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@kms_ccs@pipe-c-bad-pixel-format-y_tiled_ccs}:
- shard-tglb: NOTRUN -> [SKIP][5]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20451/shard-tglb2/igt@kms_ccs@pipe-c-bad-pixel-format-y_tiled_ccs.html
Known issues
Here are the changes found in Patchwork_20451_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_persistence@clone:
- shard-snb: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#1099]) +2
similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20451/shard-snb7/igt@gem_ctx_persiste...@clone.html
* igt@gem_exec_capture@pi@rcs0:
- shard-skl: [PASS][7] -> [INCOMPLETE][8] ([i915#2369])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10273/shard-skl3/igt@gem_exec_capture@p...@rcs0.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20451/shard-skl7/igt@gem_exec_capture@p...@rcs0.html
* igt@gem_exec_fair@basic-none-share@rcs0:
- shard-iclb: [PASS][9] -> [FAIL][10] ([i915#2842])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10273/shard-iclb1/igt@gem_exec_fair@basic-none-sh...@rcs0.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20451/shard-iclb7/igt@gem_exec_fair@basic-none-sh...@rcs0.html
* igt@gem_exec_fair@basic-none@vcs0:
- shard-kbl: [PASS][11] -> [FAIL][12] ([i915#2842])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10273/shard-kbl3/igt@gem_exec_fair@basic-n...@vcs0.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20451/shard-kbl6/igt@gem_exec_fair@basic-n...@vcs0.html
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk: [PASS][13] -> [FAIL][14] ([i915#2842])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10273/shard-glk5/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20451/shard-glk7/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
* igt@gem_exec_params@no-blt:
- shard-iclb: NOTRUN -> [SKIP][15] ([fdo#109283])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20451/shard-iclb8/igt@gem_exec_par...@no-blt.html
* igt@gem_exec_reloc@basic-wide-active@rcs0:
- shard-snb: NOTRUN -> [FAIL][16] ([i915#3633]) +2 similar issues
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20451/shard-snb7/igt@gem_exec_reloc@basic-wide-act...@rcs0.html
* igt@gem_mmap_gtt@cpuset-basic-small-copy-odd:
- shard-glk: [PASS][17] -> [FAIL][18] ([i915#307] / [i915#3468])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10273/shard-glk1/igt@gem_mmap_...@cpuset-basic-small-copy-odd.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20451/shard-glk8/igt@gem_mmap_...@cpuset-basic-small-copy-odd.html
* igt@gem_mmap_gtt@cpuset-big-copy:
- shard-iclb: [PASS][19] -> [FAIL][20] ([i915#2428])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10273/shard-iclb5/igt@gem_mmap_...@cpuset-big-copy.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20451/shard-iclb4/igt@gem_mmap_...@cpuset-big-copy.html
* igt@gem_mmap_gtt@cpuset-big-copy-odd:
-
Re: [Intel-gfx] [PATCH 04/47] drm/i915/guc: Add non blocking CTB send function
On 24.06.2021 09:04, Matthew Brost wrote:
> Add non blocking CTB send function, intel_guc_send_nb. GuC submission
> will send CTBs in the critical path and does not need to wait for these
> CTBs to complete before moving on, hence the need for this new function.
>
> The non-blocking CTB now must have a flow control mechanism to ensure
> the buffer isn't overrun. A lazy spin wait is used as we believe the
> flow control condition should be rare with a properly sized buffer.
>
> The function, intel_guc_send_nb, is exported in this patch but unused.
> Several patches later in the series make use of this function.
>
> Signed-off-by: John Harrison
> Signed-off-by: Matthew Brost
> ---
> drivers/gpu/drm/i915/gt/uc/intel_guc.h| 12 +++-
> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 77 +--
> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h | 3 +-
> 3 files changed, 82 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> index 4abc59f6f3cd..24b1df6ad4ae 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> @@ -74,7 +74,15 @@ static inline struct intel_guc *log_to_guc(struct
> intel_guc_log *log)
> static
> inline int intel_guc_send(struct intel_guc *guc, const u32 *action, u32 len)
> {
> - return intel_guc_ct_send(>ct, action, len, NULL, 0);
> + return intel_guc_ct_send(>ct, action, len, NULL, 0, 0);
> +}
> +
> +#define INTEL_GUC_SEND_NBBIT(31)
hmm, this flag really belongs to intel_guc_ct_send() so it should be
defined as CTB flag near that function declaration
> +static
> +inline int intel_guc_send_nb(struct intel_guc *guc, const u32 *action, u32
> len)
> +{
> + return intel_guc_ct_send(>ct, action, len, NULL, 0,
> + INTEL_GUC_SEND_NB);
> }
>
> static inline int
> @@ -82,7 +90,7 @@ intel_guc_send_and_receive(struct intel_guc *guc, const u32
> *action, u32 len,
> u32 *response_buf, u32 response_buf_size)
> {
> return intel_guc_ct_send(>ct, action, len,
> - response_buf, response_buf_size);
> + response_buf, response_buf_size, 0);
> }
>
> static inline void intel_guc_to_host_event_handler(struct intel_guc *guc)
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> index a17215920e58..c9a65d05911f 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> @@ -3,6 +3,11 @@
> * Copyright © 2016-2019 Intel Corporation
> */
>
> +#include
> +#include
> +#include
> +#include
> +
> #include "i915_drv.h"
> #include "intel_guc_ct.h"
> #include "gt/intel_gt.h"
> @@ -373,7 +378,7 @@ static void write_barrier(struct intel_guc_ct *ct)
> static int ct_write(struct intel_guc_ct *ct,
> const u32 *action,
> u32 len /* in dwords */,
> - u32 fence)
> + u32 fence, u32 flags)
> {
> struct intel_guc_ct_buffer *ctb = >ctbs.send;
> struct guc_ct_buffer_desc *desc = ctb->desc;
> @@ -421,9 +426,13 @@ static int ct_write(struct intel_guc_ct *ct,
>FIELD_PREP(GUC_CTB_MSG_0_NUM_DWORDS, len) |
>FIELD_PREP(GUC_CTB_MSG_0_FENCE, fence);
>
> - hxg = FIELD_PREP(GUC_HXG_MSG_0_TYPE, GUC_HXG_TYPE_REQUEST) |
> - FIELD_PREP(GUC_HXG_REQUEST_MSG_0_ACTION |
> - GUC_HXG_REQUEST_MSG_0_DATA0, action[0]);
> + hxg = (flags & INTEL_GUC_SEND_NB) ?
> + (FIELD_PREP(GUC_HXG_MSG_0_TYPE, GUC_HXG_TYPE_EVENT) |
> + FIELD_PREP(GUC_HXG_EVENT_MSG_0_ACTION |
> + GUC_HXG_EVENT_MSG_0_DATA0, action[0])) :
> + (FIELD_PREP(GUC_HXG_MSG_0_TYPE, GUC_HXG_TYPE_REQUEST) |
> + FIELD_PREP(GUC_HXG_REQUEST_MSG_0_ACTION |
> + GUC_HXG_REQUEST_MSG_0_DATA0, action[0]));
or as we already switched to accept and return whole HXG messages in
guc_send_mmio() maybe we should do the same for CTB variant too and
instead of using extra flag just let caller to prepare proper HXG header
with HXG_EVENT type and then in CTB code just look at this type to make
decision which code path to use
note that existing callers should not be impacted, as full HXG header
for the REQUEST message looks exactly the same as "action" code alone.
>
> CT_DEBUG(ct, "writing (tail %u) %*ph %*ph %*ph\n",
>tail, 4, , 4, , 4 * (len - 1), [1]);
> @@ -498,6 +507,46 @@ static int wait_for_ct_request_update(struct ct_request
> *req, u32 *status)
> return err;
> }
>
> +static inline bool h2g_has_room(struct intel_guc_ct_buffer *ctb, u32 len_dw)
> +{
> + struct guc_ct_buffer_desc *desc = ctb->desc;
> + u32 head = READ_ONCE(desc->head);
> + u32 space;
> +
> + space = CIRC_SPACE(desc->tail, head, ctb->size);
> +
> +
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v6,RESEND,1/3] gpu: drm: separate panel orientation property creating and value setting
== Series Details == Series: series starting with [v6,RESEND,1/3] gpu: drm: separate panel orientation property creating and value setting URL : https://patchwork.freedesktop.org/series/91867/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed:
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v6,RESEND,1/3] gpu: drm: separate panel orientation property creating and value setting
== Series Details ==
Series: series starting with [v6,RESEND,1/3] gpu: drm: separate panel
orientation property creating and value setting
URL : https://patchwork.freedesktop.org/series/91867/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
8e0b6d8e41b6 gpu: drm: separate panel orientation property creating and value
setting
-:131: WARNING:SPACE_BEFORE_TAB: please, no space before tabs
#131: FILE: drivers/gpu/drm/drm_connector.c:2320:
+ * ^Icreate the connector's panel orientation property$
-:142: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#142: FILE: drivers/gpu/drm/drm_connector.c:2331:
+int drm_connector_init_panel_orientation_property(
-:149: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#149: FILE: drivers/gpu/drm/drm_connector.c:2338:
+ prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE,
+ "panel orientation",
-:210: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#210: FILE: include/drm/drm_connector.h:1708:
+int drm_connector_init_panel_orientation_property(
total: 0 errors, 1 warnings, 3 checks, 118 lines checked
39f7ae8abfee drm/mediatek: init panel orientation property
d46a8e1bd812 arm64: dts: mt8183: Add panel rotation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/dp: Fix invalid test parameter when run DP link layer compliance
Run intel_dp_compliance would failed at video pattern related
test case sometimes. DP test applet read incorrect test type
from kernel to cause this symptom. Add "\n" (newline) in
seq_printf() then test daemon can get parameter properly.
Fixes: eb3394faeb97 ("drm/i915: Add debugfs test control
files for Displayport compliance testing")
Cc: Manasi Navare
Cc: Jani Nikula
Cc: Ville Syrjala
Cc: Cooper Chiou
Signed-off-by: Lee Shawn C
---
drivers/gpu/drm/i915/display/intel_display_debugfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index db38891a9ef0..08b0a5c89f7e 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -1540,7 +1540,7 @@ static int i915_displayport_test_data_show(struct
seq_file *m, void *data)
intel_dp = enc_to_intel_dp(encoder);
if (intel_dp->compliance.test_type ==
DP_TEST_LINK_EDID_READ)
- seq_printf(m, "%lx",
+ seq_printf(m, "%lx\n",
intel_dp->compliance.test_data.edid);
else if (intel_dp->compliance.test_type ==
DP_TEST_LINK_VIDEO_PATTERN) {
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/47] drm/i915/guc: Increase size of CTB buffers
On 24.06.2021 09:04, Matthew Brost wrote:
> With the introduction of non-blocking CTBs more than one CTB can be in
> flight at a time. Increasing the size of the CTBs should reduce how
> often software hits the case where no space is available in the CTB
> buffer.
>
> Cc: John Harrison
> Signed-off-by: Matthew Brost
> ---
> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 11 ---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> index 07f080ddb9ae..a17215920e58 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> @@ -58,11 +58,16 @@ static inline struct drm_device *ct_to_drm(struct
> intel_guc_ct *ct)
> * ++---+--+
> *
> * Size of each `CT Buffer`_ must be multiple of 4K.
> - * As we don't expect too many messages, for now use minimum sizes.
> + * We don't expect too many messages in flight at any time, unless we are
> + * using the GuC submission. In that case each request requires a minimum
> + * 2 dwords which gives us a maximum 256 queue'd requests. Hopefully this
> + * enough space to avoid backpressure on the driver. We increase the size
> + * of the receive buffer (relative to the send) to ensure a G2H response
> + * CTB has a landing spot.
> */
> #define CTB_DESC_SIZEALIGN(sizeof(struct
> guc_ct_buffer_desc), SZ_2K)
> #define CTB_H2G_BUFFER_SIZE (SZ_4K)
> -#define CTB_G2H_BUFFER_SIZE (SZ_4K)
> +#define CTB_G2H_BUFFER_SIZE (4 * CTB_H2G_BUFFER_SIZE)
>
> struct ct_request {
> struct list_head link;
> @@ -641,7 +646,7 @@ static int ct_read(struct intel_guc_ct *ct, struct
> ct_incoming_msg **msg)
> /* beware of buffer wrap case */
> if (unlikely(available < 0))
> available += size;
> - CT_DEBUG(ct, "available %d (%u:%u)\n", available, head, tail);
> + CT_DEBUG(ct, "available %d (%u:%u:%u)\n", available, head, tail, size);
CTB size is already printed in intel_guc_ct_init() and is fixed so not
sure if repeating it on every ct_read has any benefit
> GEM_BUG_ON(available < 0);
>
> header = cmds[head];
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 14/15] drm/gem: Tiny kernel clarification for drm_gem_fence_array_add
On Thu, Jun 24, 2021 at 03:35:19PM +0200, Christian König wrote: > Am 24.06.21 um 15:32 schrieb Daniel Vetter: > > On Thu, Jun 24, 2021 at 02:48:54PM +0200, Christian König wrote: > > > > > > Am 24.06.21 um 14:41 schrieb Daniel Vetter: > > > > On Wed, Jun 23, 2021 at 10:42:50AM +0200, Christian König wrote: > > > > > Am 22.06.21 um 18:55 schrieb Daniel Vetter: > > > > > > Spotted while trying to convert panfrost to these. > > > > > > > > > > > > Signed-off-by: Daniel Vetter > > > > > > Cc: "Christian König" > > > > > > Cc: Lucas Stach > > > > > > Cc: Maarten Lankhorst > > > > > > Cc: Maxime Ripard > > > > > > Cc: Thomas Zimmermann > > > > > > Cc: David Airlie > > > > > > Cc: Daniel Vetter > > > > > > --- > > > > > > drivers/gpu/drm/drm_gem.c | 3 +++ > > > > > > 1 file changed, 3 insertions(+) > > > > > > > > > > > > diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c > > > > > > index ba2e64ed8b47..68deb1de8235 100644 > > > > > > --- a/drivers/gpu/drm/drm_gem.c > > > > > > +++ b/drivers/gpu/drm/drm_gem.c > > > > > > @@ -1302,6 +1302,9 @@ EXPORT_SYMBOL(drm_gem_unlock_reservations); > > > > > > * @fence_array: array of dma_fence * for the job to block on. > > > > > > * @fence: the dma_fence to add to the list of dependencies. > > > > > > * > > > > > > + * This functions consumes the reference for @fence both on > > > > > > success and error > > > > > > + * cases. > > > > > > + * > > > > > Oh, the later is a bit ugly I think. But good to know. > > > > > > > > > > Reviewed-by: Christian König > > > > Merged to drm-misc-next, thanks for taking a look. Can you perhaps take > > > > a > > > > look at the drm/armada patch too, then I think I have reviews/acks for > > > > all > > > > of them? > > > What are you talking about? I only see drm/armada patches for the irq > > > stuff > > > Thomas is working on. > > There was one in this series, but Maxime was quicker. I'm going to apply > > all the remaining ones now. After that I'll send out a patch set to add > > some dependency tracking to drm_sched_job so that there's not so much > > copypasta going on there. I stumbled over that when reviewing how we > > handle dependencies. > > Do you mean a common container for dma_fence objects a drm_sched_job depends > on? Yup. Well the real usefulness is the interfaces, so that you can just grep for those when trying to figure out htf a driver handles its implicit dependencies. And amdgpu is unfortunately going to be a bit in the cold because it's special (but should be able to benefit too, just more than 1-2 patches to convert it over). Anyway I'm going to type the cover letter rsn. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/15] drm/vram-helpers: Create DRM_GEM_VRAM_PLANE_HELPER_FUNCS
On Thu, Jun 24, 2021 at 09:46:20AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 22.06.21 um 18:55 schrieb Daniel Vetter:
> > Like we have for the shadow helpers too, and roll it out to drivers.
>
> In addition to the plane-helper macro, you may also want to add
> DRM_GEM_VRAM_SIMPLE_DISPLAY_PIPE_FUNCS and use it in bochs.
Hm I guess we can do that when we have a 2nd such case. I was more aiming
to make it as friction-less as possible that drivers end up with a
prepare_fb implementation which fishes out the implicit fences as needed
in this series.
Thanks for looking at this patch, I'm merging them all to drm-misc-next
now.
-Daniel
>
> Best regards
> Thomas
>
> >
> > Acked-by: Tian Tao
> > Signed-off-by: Daniel Vetter
> > Cc: Dave Airlie
> > Cc: Thomas Zimmermann
> > Cc: Hans de Goede
> > Cc: Maarten Lankhorst
> > Cc: Maxime Ripard
> > Cc: David Airlie
> > Cc: Daniel Vetter
> > Cc: Tian Tao
> > Cc: Laurent Pinchart
> > ---
> > drivers/gpu/drm/ast/ast_mode.c | 3 +--
> > drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c | 3 +--
> > drivers/gpu/drm/vboxvideo/vbox_mode.c | 3 +--
> > include/drm/drm_gem_vram_helper.h | 12
> > 4 files changed, 15 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
> > index e5996ae03c49..f5d58c3088fe 100644
> > --- a/drivers/gpu/drm/ast/ast_mode.c
> > +++ b/drivers/gpu/drm/ast/ast_mode.c
> > @@ -612,8 +612,7 @@ ast_primary_plane_helper_atomic_disable(struct
> > drm_plane *plane,
> > }
> > static const struct drm_plane_helper_funcs ast_primary_plane_helper_funcs
> > = {
> > - .prepare_fb = drm_gem_vram_plane_helper_prepare_fb,
> > - .cleanup_fb = drm_gem_vram_plane_helper_cleanup_fb,
> > + DRM_GEM_VRAM_PLANE_HELPER_FUNCS,
> > .atomic_check = ast_primary_plane_helper_atomic_check,
> > .atomic_update = ast_primary_plane_helper_atomic_update,
> > .atomic_disable = ast_primary_plane_helper_atomic_disable,
> > diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
> > b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
> > index 29b8332b2bca..ccf80e369b4b 100644
> > --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
> > +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
> > @@ -158,8 +158,7 @@ static const struct drm_plane_funcs hibmc_plane_funcs =
> > {
> > };
> > static const struct drm_plane_helper_funcs hibmc_plane_helper_funcs = {
> > - .prepare_fb = drm_gem_vram_plane_helper_prepare_fb,
> > - .cleanup_fb = drm_gem_vram_plane_helper_cleanup_fb,
> > + DRM_GEM_VRAM_PLANE_HELPER_FUNCS,
> > .atomic_check = hibmc_plane_atomic_check,
> > .atomic_update = hibmc_plane_atomic_update,
> > };
> > diff --git a/drivers/gpu/drm/vboxvideo/vbox_mode.c
> > b/drivers/gpu/drm/vboxvideo/vbox_mode.c
> > index 964381d55fc1..972c83b720aa 100644
> > --- a/drivers/gpu/drm/vboxvideo/vbox_mode.c
> > +++ b/drivers/gpu/drm/vboxvideo/vbox_mode.c
> > @@ -488,8 +488,7 @@ static const struct drm_plane_helper_funcs
> > vbox_primary_helper_funcs = {
> > .atomic_check = vbox_primary_atomic_check,
> > .atomic_update = vbox_primary_atomic_update,
> > .atomic_disable = vbox_primary_atomic_disable,
> > - .prepare_fb = drm_gem_vram_plane_helper_prepare_fb,
> > - .cleanup_fb = drm_gem_vram_plane_helper_cleanup_fb,
> > + DRM_GEM_VRAM_PLANE_HELPER_FUNCS,
> > };
> > static const struct drm_plane_funcs vbox_primary_plane_funcs = {
> > diff --git a/include/drm/drm_gem_vram_helper.h
> > b/include/drm/drm_gem_vram_helper.h
> > index 27ed7e9243b9..f48d181c824b 100644
> > --- a/include/drm/drm_gem_vram_helper.h
> > +++ b/include/drm/drm_gem_vram_helper.h
> > @@ -124,6 +124,18 @@ void
> > drm_gem_vram_plane_helper_cleanup_fb(struct drm_plane *plane,
> > struct drm_plane_state *old_state);
> > +/**
> > + * DRM_GEM_VRAM_PLANE_HELPER_FUNCS -
> > + * Initializes struct drm_plane_helper_funcs for VRAM handling
> > + *
> > + * Drivers may use GEM BOs as VRAM helpers for the framebuffer memory. This
> > + * macro initializes struct drm_plane_helper_funcs to use the respective
> > helper
> > + * functions.
> > + */
> > +#define DRM_GEM_VRAM_PLANE_HELPER_FUNCS \
> > + .prepare_fb = drm_gem_vram_plane_helper_prepare_fb, \
> > + .cleanup_fb = drm_gem_vram_plane_helper_cleanup_fb
> > +
> > /*
> >* Helpers for struct drm_simple_display_pipe_funcs
> >*/
> >
>
> --
> 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
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 14/15] drm/gem: Tiny kernel clarification for drm_gem_fence_array_add
On Thu, Jun 24, 2021 at 02:48:54PM +0200, Christian König wrote: > > > Am 24.06.21 um 14:41 schrieb Daniel Vetter: > > On Wed, Jun 23, 2021 at 10:42:50AM +0200, Christian König wrote: > > > Am 22.06.21 um 18:55 schrieb Daniel Vetter: > > > > Spotted while trying to convert panfrost to these. > > > > > > > > Signed-off-by: Daniel Vetter > > > > Cc: "Christian König" > > > > Cc: Lucas Stach > > > > Cc: Maarten Lankhorst > > > > Cc: Maxime Ripard > > > > Cc: Thomas Zimmermann > > > > Cc: David Airlie > > > > Cc: Daniel Vetter > > > > --- > > > >drivers/gpu/drm/drm_gem.c | 3 +++ > > > >1 file changed, 3 insertions(+) > > > > > > > > diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c > > > > index ba2e64ed8b47..68deb1de8235 100644 > > > > --- a/drivers/gpu/drm/drm_gem.c > > > > +++ b/drivers/gpu/drm/drm_gem.c > > > > @@ -1302,6 +1302,9 @@ EXPORT_SYMBOL(drm_gem_unlock_reservations); > > > > * @fence_array: array of dma_fence * for the job to block on. > > > > * @fence: the dma_fence to add to the list of dependencies. > > > > * > > > > + * This functions consumes the reference for @fence both on success > > > > and error > > > > + * cases. > > > > + * > > > Oh, the later is a bit ugly I think. But good to know. > > > > > > Reviewed-by: Christian König > > Merged to drm-misc-next, thanks for taking a look. Can you perhaps take a > > look at the drm/armada patch too, then I think I have reviews/acks for all > > of them? > > What are you talking about? I only see drm/armada patches for the irq stuff > Thomas is working on. There was one in this series, but Maxime was quicker. I'm going to apply all the remaining ones now. After that I'll send out a patch set to add some dependency tracking to drm_sched_job so that there's not so much copypasta going on there. I stumbled over that when reviewing how we handle dependencies. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display: Fix state mismatch in drm infoframe (rev5)
== Series Details ==
Series: drm/i915/display: Fix state mismatch in drm infoframe (rev5)
URL : https://patchwork.freedesktop.org/series/89225/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10274 -> Patchwork_20453
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20453/index.html
Known issues
Here are the changes found in Patchwork_20453 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_gttfill@basic:
- fi-bsw-n3050: NOTRUN -> [SKIP][1] ([fdo#109271])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20453/fi-bsw-n3050/igt@gem_exec_gttf...@basic.html
* igt@gem_exec_suspend@basic-s3:
- fi-bsw-n3050: NOTRUN -> [INCOMPLETE][2] ([i915#3159])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20453/fi-bsw-n3050/igt@gem_exec_susp...@basic-s3.html
* igt@i915_selftest@live@execlists:
- fi-bsw-kefka: [PASS][3] -> [INCOMPLETE][4] ([i915#2782] /
[i915#2940])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10274/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20453/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
[i915#2782]: https://gitlab.freedesktop.org/drm/intel/issues/2782
[i915#2940]: https://gitlab.freedesktop.org/drm/intel/issues/2940
[i915#3159]: https://gitlab.freedesktop.org/drm/intel/issues/3159
Participating hosts (43 -> 40)
--
Additional (1): fi-bsw-n3050
Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-bdw-samus fi-hsw-4200u
Build changes
-
* Linux: CI_DRM_10274 -> Patchwork_20453
CI-20190529: 20190529
CI_DRM_10274: 0f49e4d085430915c86c990722817b8ddec84480 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6117: 3ba0a02404f243d6d8f232c6215163cc4b0fd699 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_20453: 588c71ac65adcf7ab6a0a5c382b7196b425d0611 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
588c71ac65ad drm/i915/display: Fix state mismatch in drm infoframe
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20453/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/6] KVM: Remove uses of struct page from x86 and arm64 MMU
Excerpts from Paolo Bonzini's message of June 24, 2021 10:41 pm:
> On 24/06/21 13:42, Nicholas Piggin wrote:
>> Excerpts from Nicholas Piggin's message of June 24, 2021 8:34 pm:
>>> Excerpts from David Stevens's message of June 24, 2021 1:57 pm:
KVM supports mapping VM_IO and VM_PFNMAP memory into the guest by using
follow_pte in gfn_to_pfn. However, the resolved pfns may not have
assoicated struct pages, so they should not be passed to pfn_to_page.
This series removes such calls from the x86 and arm64 secondary MMU. To
do this, this series modifies gfn_to_pfn to return a struct page in
addition to a pfn, if the hva was resolved by gup. This allows the
caller to call put_page only when necessated by gup.
This series provides a helper function that unwraps the new return type
of gfn_to_pfn to provide behavior identical to the old behavior. As I
have no hardware to test powerpc/mips changes, the function is used
there for minimally invasive changes. Additionally, as gfn_to_page and
gfn_to_pfn_cache are not integrated with mmu notifier, they cannot be
easily changed over to only use pfns.
This addresses CVE-2021-22543 on x86 and arm64.
>>>
>>> Does this fix the problem? (untested I don't have a POC setup at hand,
>>> but at least in concept)
>>
>> This one actually compiles at least. Unfortunately I don't have much
>> time in the near future to test, and I only just found out about this
>> CVE a few hours ago.
>
> And it also works (the reproducer gets an infinite stream of userspace
> exits and especially does not crash). We can still go for David's
> solution later since MMU notifiers are able to deal with this pages, but
> it's a very nice patch for stable kernels.
Oh nice, thanks for testing. How's this?
Thanks,
Nick
---
KVM: Fix page ref underflow for regions with valid but non-refcounted pages
It's possible to create a region which maps valid but non-refcounted
pages (e.g., tail pages of non-compound higher order allocations). These
host pages can then be returned by gfn_to_page, gfn_to_pfn, etc., family
of APIs, which take a reference to the page, which takes it from 0 to 1.
When the reference is dropped, this will free the page incorrectly.
Fix this by only taking a reference on the page if it was non-zero,
which indicates it is participating in normal refcounting (and can be
released with put_page).
Signed-off-by: Nicholas Piggin
---
virt/kvm/kvm_main.c | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 6a6bc7af0e28..46fb042837d2 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -2055,6 +2055,13 @@ static bool vma_is_valid(struct vm_area_struct *vma,
bool write_fault)
return true;
}
+static int kvm_try_get_pfn(kvm_pfn_t pfn)
+{
+ if (kvm_is_reserved_pfn(pfn))
+ return 1;
+ return get_page_unless_zero(pfn_to_page(pfn));
+}
+
static int hva_to_pfn_remapped(struct vm_area_struct *vma,
unsigned long addr, bool *async,
bool write_fault, bool *writable,
@@ -2104,13 +2111,21 @@ static int hva_to_pfn_remapped(struct vm_area_struct
*vma,
* Whoever called remap_pfn_range is also going to call e.g.
* unmap_mapping_range before the underlying pages are freed,
* causing a call to our MMU notifier.
+*
+* Certain IO or PFNMAP mappings can be backed with valid
+* struct pages, but be allocated without refcounting e.g.,
+* tail pages of non-compound higher order allocations, which
+* would then underflow the refcount when the caller does the
+* required put_page. Don't allow those pages here.
*/
- kvm_get_pfn(pfn);
+ if (!kvm_try_get_pfn(pfn))
+ r = -EFAULT;
out:
pte_unmap_unlock(ptep, ptl);
*p_pfn = pfn;
- return 0;
+
+ return r;
}
/*
--
2.23.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 04/27] drm: Don't test for IRQ support in VBLANK ioctls
Hi
Am 24.06.21 um 14:36 schrieb Jani Nikula:
On Thu, 24 Jun 2021, Thierry Reding wrote:
On Thu, Jun 24, 2021 at 11:07:57AM +0200, Thomas Zimmermann wrote:
Hi
Am 24.06.21 um 10:51 schrieb Jani Nikula:
On Thu, 24 Jun 2021, Thomas Zimmermann wrote:
Hi
Am 24.06.21 um 10:06 schrieb Jani Nikula:
On Thu, 24 Jun 2021, Thomas Zimmermann wrote:
diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 3417e1ac7918..10fe16bafcb6 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -1748,8 +1748,16 @@ int drm_wait_vblank_ioctl(struct drm_device *dev, void
*data,
unsigned int pipe_index;
unsigned int flags, pipe, high_pipe;
- if (!dev->irq_enabled)
- return -EOPNOTSUPP;
+#if defined(CONFIG_DRM_LEGACY)
+ if (unlikely(drm_core_check_feature(dev, DRIVER_LEGACY))) {
+ if (!dev->irq_enabled)
+ return -EOPNOTSUPP;
+ } else /* if DRIVER_MODESET */
+#endif
+ {
+ if (!drm_dev_has_vblank(dev))
+ return -EOPNOTSUPP;
+ }
Sheesh I hate this kind of inline #ifdefs.
Two alternate suggestions that I believe should be as just efficient:
Or how about:
static bool drm_wait_vblank_supported(struct drm_device *dev)
{
if defined(CONFIG_DRM_LEGACY)
if (unlikely(drm_core_check_feature(dev, DRIVER_LEGACY)))
return dev->irq_enabled;
#endif
return drm_dev_has_vblank(dev);
}
?
It's inline, but still readable.
It's definitely better than the original, but it's unclear to me why
you'd prefer this over option 2) below. I guess the only reason I can
think of is emphasizing the conditional compilation. However,
IS_ENABLED() is widely used in this manner specifically to avoid inline
#if, and the compiler optimizes it away.
It's simply more readable to me as the condition is simpler. But option 2 is
also ok.
Perhaps do something like this, then:
if (IS_ENABLED(CONFIG_DRM_LEGACY)) {
if (unlikely(drm_core_check_feature(dev, DRIVER_LEGACY)))
return dev->irq_enabled;
}
return drm_dev_has_vblank(dev);
That's about just as readable as the variant involving the preprocessor
but has all the benefits of not using the preprocessor.
Looks like a winner to me. :)
That's the most readable.
But I just remembered that irq_enabled will likely become legacy-only in
the device structure. We'll need an ifdef variant then. :/
Best regards
Thomas
BR,
Jani.
--
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
OpenPGP_signature
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/15] drm/armada: Remove prepare/cleanup_fb hooks
On Tue, Jun 22, 2021 at 06:55:05PM +0200, Daniel Vetter wrote: > All they do is refcount the fb, which the atomic helpers already do. > > This is was necessary with the legacy helpers and I guess just carry > over in the conversion. drm_plane_state always has a full reference > for its ->fb pointer during its entire lifetime, > see __drm_atomic_helper_plane_destroy_state() > > Signed-off-by: Daniel Vetter > Cc: Russell King Acked-by: Maxime Ripard Maxime ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 14/15] drm/gem: Tiny kernel clarification for drm_gem_fence_array_add
On Wed, Jun 23, 2021 at 10:42:50AM +0200, Christian König wrote: > Am 22.06.21 um 18:55 schrieb Daniel Vetter: > > Spotted while trying to convert panfrost to these. > > > > Signed-off-by: Daniel Vetter > > Cc: "Christian König" > > Cc: Lucas Stach > > Cc: Maarten Lankhorst > > Cc: Maxime Ripard > > Cc: Thomas Zimmermann > > Cc: David Airlie > > Cc: Daniel Vetter > > --- > > drivers/gpu/drm/drm_gem.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c > > index ba2e64ed8b47..68deb1de8235 100644 > > --- a/drivers/gpu/drm/drm_gem.c > > +++ b/drivers/gpu/drm/drm_gem.c > > @@ -1302,6 +1302,9 @@ EXPORT_SYMBOL(drm_gem_unlock_reservations); > >* @fence_array: array of dma_fence * for the job to block on. > >* @fence: the dma_fence to add to the list of dependencies. > >* > > + * This functions consumes the reference for @fence both on success and > > error > > + * cases. > > + * > > Oh, the later is a bit ugly I think. But good to know. > > Reviewed-by: Christian König Merged to drm-misc-next, thanks for taking a look. Can you perhaps take a look at the drm/armada patch too, then I think I have reviews/acks for all of them? Thanks, Daniel > > >* Returns: > >* 0 on success, or an error on failing to expand the array. > >*/ > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/6] KVM: Remove uses of struct page from x86 and arm64 MMU
On 24/06/21 13:42, Nicholas Piggin wrote:
Excerpts from Nicholas Piggin's message of June 24, 2021 8:34 pm:
Excerpts from David Stevens's message of June 24, 2021 1:57 pm:
KVM supports mapping VM_IO and VM_PFNMAP memory into the guest by using
follow_pte in gfn_to_pfn. However, the resolved pfns may not have
assoicated struct pages, so they should not be passed to pfn_to_page.
This series removes such calls from the x86 and arm64 secondary MMU. To
do this, this series modifies gfn_to_pfn to return a struct page in
addition to a pfn, if the hva was resolved by gup. This allows the
caller to call put_page only when necessated by gup.
This series provides a helper function that unwraps the new return type
of gfn_to_pfn to provide behavior identical to the old behavior. As I
have no hardware to test powerpc/mips changes, the function is used
there for minimally invasive changes. Additionally, as gfn_to_page and
gfn_to_pfn_cache are not integrated with mmu notifier, they cannot be
easily changed over to only use pfns.
This addresses CVE-2021-22543 on x86 and arm64.
Does this fix the problem? (untested I don't have a POC setup at hand,
but at least in concept)
This one actually compiles at least. Unfortunately I don't have much
time in the near future to test, and I only just found out about this
CVE a few hours ago.
And it also works (the reproducer gets an infinite stream of userspace
exits and especially does not crash). We can still go for David's
solution later since MMU notifiers are able to deal with this pages, but
it's a very nice patch for stable kernels.
If you provide a Signed-off-by, I can integrate it.
Paolo
---
It's possible to create a region which maps valid but non-refcounted
pages (e.g., tail pages of non-compound higher order allocations). These
host pages can then be returned by gfn_to_page, gfn_to_pfn, etc., family
of APIs, which take a reference to the page, which takes it from 0 to 1.
When the reference is dropped, this will free the page incorrectly.
Fix this by only taking a reference on the page if it was non-zero,
which indicates it is participating in normal refcounting (and can be
released with put_page).
---
virt/kvm/kvm_main.c | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 6a6bc7af0e28..46fb042837d2 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -2055,6 +2055,13 @@ static bool vma_is_valid(struct vm_area_struct *vma,
bool write_fault)
return true;
}
+static int kvm_try_get_pfn(kvm_pfn_t pfn)
+{
+ if (kvm_is_reserved_pfn(pfn))
+ return 1;
+ return get_page_unless_zero(pfn_to_page(pfn));
+}
+
static int hva_to_pfn_remapped(struct vm_area_struct *vma,
unsigned long addr, bool *async,
bool write_fault, bool *writable,
@@ -2104,13 +2111,21 @@ static int hva_to_pfn_remapped(struct vm_area_struct
*vma,
* Whoever called remap_pfn_range is also going to call e.g.
* unmap_mapping_range before the underlying pages are freed,
* causing a call to our MMU notifier.
+*
+* Certain IO or PFNMAP mappings can be backed with valid
+* struct pages, but be allocated without refcounting e.g.,
+* tail pages of non-compound higher order allocations, which
+* would then underflow the refcount when the caller does the
+* required put_page. Don't allow those pages here.
*/
- kvm_get_pfn(pfn);
+ if (!kvm_try_get_pfn(pfn))
+ r = -EFAULT;
out:
pte_unmap_unlock(ptep, ptl);
*p_pfn = pfn;
- return 0;
+
+ return r;
}
/*
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 04/27] drm: Don't test for IRQ support in VBLANK ioctls
On Thu, 24 Jun 2021, Thierry Reding wrote:
> On Thu, Jun 24, 2021 at 11:07:57AM +0200, Thomas Zimmermann wrote:
>> Hi
>>
>> Am 24.06.21 um 10:51 schrieb Jani Nikula:
>> > On Thu, 24 Jun 2021, Thomas Zimmermann wrote:
>> > > Hi
>> > >
>> > > Am 24.06.21 um 10:06 schrieb Jani Nikula:
>> > > > On Thu, 24 Jun 2021, Thomas Zimmermann wrote:
>> > > > > diff --git a/drivers/gpu/drm/drm_vblank.c
>> > > > > b/drivers/gpu/drm/drm_vblank.c
>> > > > > index 3417e1ac7918..10fe16bafcb6 100644
>> > > > > --- a/drivers/gpu/drm/drm_vblank.c
>> > > > > +++ b/drivers/gpu/drm/drm_vblank.c
>> > > > > @@ -1748,8 +1748,16 @@ int drm_wait_vblank_ioctl(struct drm_device
>> > > > > *dev, void *data,
>> > > > > unsigned int pipe_index;
>> > > > > unsigned int flags, pipe, high_pipe;
>> > > > > -if (!dev->irq_enabled)
>> > > > > -return -EOPNOTSUPP;
>> > > > > +#if defined(CONFIG_DRM_LEGACY)
>> > > > > +if (unlikely(drm_core_check_feature(dev, DRIVER_LEGACY))) {
>> > > > > +if (!dev->irq_enabled)
>> > > > > +return -EOPNOTSUPP;
>> > > > > +} else /* if DRIVER_MODESET */
>> > > > > +#endif
>> > > > > +{
>> > > > > +if (!drm_dev_has_vblank(dev))
>> > > > > +return -EOPNOTSUPP;
>> > > > > +}
>> > > >
>> > > > Sheesh I hate this kind of inline #ifdefs.
>> > > >
>> > > > Two alternate suggestions that I believe should be as just efficient:
>> > >
>> > > Or how about:
>> > >
>> > > static bool drm_wait_vblank_supported(struct drm_device *dev)
>> > >
>> > > {
>> > >
>> > > if defined(CONFIG_DRM_LEGACY)
>> > > if (unlikely(drm_core_check_feature(dev, DRIVER_LEGACY)))
>> > >
>> > > return dev->irq_enabled;
>> > >
>> > > #endif
>> > > return drm_dev_has_vblank(dev);
>> > >
>> > > }
>> > >
>> > >
>> > > ?
>> > >
>> > > It's inline, but still readable.
>> >
>> > It's definitely better than the original, but it's unclear to me why
>> > you'd prefer this over option 2) below. I guess the only reason I can
>> > think of is emphasizing the conditional compilation. However,
>> > IS_ENABLED() is widely used in this manner specifically to avoid inline
>> > #if, and the compiler optimizes it away.
>>
>> It's simply more readable to me as the condition is simpler. But option 2 is
>> also ok.
>
> Perhaps do something like this, then:
>
> if (IS_ENABLED(CONFIG_DRM_LEGACY)) {
> if (unlikely(drm_core_check_feature(dev, DRIVER_LEGACY)))
> return dev->irq_enabled;
> }
>
> return drm_dev_has_vblank(dev);
>
> That's about just as readable as the variant involving the preprocessor
> but has all the benefits of not using the preprocessor.
Looks like a winner to me. :)
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Move system memory to TTM for discrete (rev10)
== Series Details ==
Series: drm/i915: Move system memory to TTM for discrete (rev10)
URL : https://patchwork.freedesktop.org/series/90898/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10273 -> Patchwork_20452
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20452/index.html
Known issues
Here are the changes found in Patchwork_20452 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@cs-sdma:
- fi-kbl-7500u: NOTRUN -> [SKIP][1] ([fdo#109271]) +28 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20452/fi-kbl-7500u/igt@amdgpu/amd_ba...@cs-sdma.html
* igt@amdgpu/amd_basic@query-info:
- fi-tgl-y: NOTRUN -> [SKIP][2] ([fdo#109315])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20452/fi-tgl-y/igt@amdgpu/amd_ba...@query-info.html
* igt@amdgpu/amd_cs_nop@fork-gfx0:
- fi-tgl-y: NOTRUN -> [SKIP][3] ([fdo#109315] / [i915#2575]) +16
similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20452/fi-tgl-y/igt@amdgpu/amd_cs_...@fork-gfx0.html
* igt@amdgpu/amd_cs_nop@sync-fork-compute0:
- fi-kbl-soraka: NOTRUN -> [SKIP][4] ([fdo#109271]) +10 similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20452/fi-kbl-soraka/igt@amdgpu/amd_cs_...@sync-fork-compute0.html
* igt@gem_huc_copy@huc-copy:
- fi-tgl-y: NOTRUN -> [SKIP][5] ([i915#2190])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20452/fi-tgl-y/igt@gem_huc_c...@huc-copy.html
- fi-kbl-7500u: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#2190])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20452/fi-kbl-7500u/igt@gem_huc_c...@huc-copy.html
* igt@i915_selftest@live@gt_lrc:
- fi-tgl-y: NOTRUN -> [DMESG-FAIL][7] ([i915#2373])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20452/fi-tgl-y/igt@i915_selftest@live@gt_lrc.html
* igt@i915_selftest@live@gt_pm:
- fi-tgl-y: NOTRUN -> [DMESG-FAIL][8] ([i915#1759])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20452/fi-tgl-y/igt@i915_selftest@live@gt_pm.html
* igt@kms_chamelium@vga-edid-read:
- fi-tgl-y: NOTRUN -> [SKIP][9] ([fdo#111827]) +8 similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20452/fi-tgl-y/igt@kms_chamel...@vga-edid-read.html
* igt@kms_force_connector_basic@force-load-detect:
- fi-tgl-y: NOTRUN -> [SKIP][10] ([fdo#109285])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20452/fi-tgl-y/igt@kms_force_connector_ba...@force-load-detect.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-kbl-7500u: NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#533])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20452/fi-kbl-7500u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html
* igt@prime_vgem@basic-userptr:
- fi-tgl-y: NOTRUN -> [SKIP][12] ([i915#3301])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20452/fi-tgl-y/igt@prime_v...@basic-userptr.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1759]: https://gitlab.freedesktop.org/drm/intel/issues/1759
[i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#2373]: https://gitlab.freedesktop.org/drm/intel/issues/2373
[i915#2575]: https://gitlab.freedesktop.org/drm/intel/issues/2575
[i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
[i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533
Participating hosts (40 -> 40)
--
Additional (2): fi-tgl-y fi-kbl-7500u
Missing(2): fi-bsw-cyan fi-bdw-samus
Build changes
-
* Linux: CI_DRM_10273 -> Patchwork_20452
CI-20190529: 20190529
CI_DRM_10273: 7e8fb717a07aaf86771e709855436312f546965b @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6117: 3ba0a02404f243d6d8f232c6215163cc4b0fd699 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_20452: ffbc9788f52bcb897a35f0f9427e832e0334 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
ffbc9788 drm/i915/ttm: Use TTM for system memory
3469f15e5021 drm/i915/ttm: Adjust gem flags and caching settings after a move
99ab2382bf2e drm/i915: Update object placement flags to be mutable
== Logs ==
For more details see:
Re: [Intel-gfx] [PATCH v2] drm/i915: Reinstate the mmap ioctl for some platforms
On Thu, Jun 24, 2021 at 1:29 PM Thomas Hellström
wrote:
>
> Reinstate the mmap ioctl for all current integrated platforms.
> The intention was really to have it disabled for discrete graphics
> where we enforce a single mmap mode.
>
> Fixes: 35cbd91eb541 ("drm/i915: Disable mmap ioctl for gen12+")
> Signed-off-by: Thomas Hellström
> Reviewed-by: Matthew Auld
Acked-by: Daniel Vetter
> ---
> v2:
> - Added a R-B.
> - Fixed up the code comment a bit.
> ---
> drivers/gpu/drm/i915/gem/i915_gem_mman.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> index 2fd155742bd2..4f50a508c7a0 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> @@ -62,10 +62,11 @@ i915_gem_mmap_ioctl(struct drm_device *dev, void *data,
> struct drm_i915_gem_object *obj;
> unsigned long addr;
>
> - /* mmap ioctl is disallowed for all platforms after TGL-LP. This also
> -* covers all platforms with local memory.
> + /*
> +* mmap ioctl is disallowed for all discrete platforms,
> +* and for all platforms with GRAPHICS_VER > 12.
> */
> - if (GRAPHICS_VER(i915) >= 12 && !IS_TIGERLAKE(i915))
> + if (IS_DGFX(i915) || GRAPHICS_VER(i915) > 12)
> return -EOPNOTSUPP;
>
> if (args->flags & ~(I915_MMAP_WC))
> --
> 2.31.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 21/27] drm/tegra: Don't set struct drm_device.irq_enabled
On Thu, Jun 24, 2021 at 09:29:10AM +0200, Thomas Zimmermann wrote: > The field drm_device.irq_enabled is only used by legacy drivers > with userspace modesetting. Don't set it in tegra. > > Signed-off-by: Thomas Zimmermann > Reviewed-by: Laurent Pinchart > Acked-by: Daniel Vetter > --- > drivers/gpu/drm/tegra/drm.c | 7 --- > 1 file changed, 7 deletions(-) Acked-by: Thierry Reding signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 04/27] drm: Don't test for IRQ support in VBLANK ioctls
On Thu, Jun 24, 2021 at 11:07:57AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 24.06.21 um 10:51 schrieb Jani Nikula:
> > On Thu, 24 Jun 2021, Thomas Zimmermann wrote:
> > > Hi
> > >
> > > Am 24.06.21 um 10:06 schrieb Jani Nikula:
> > > > On Thu, 24 Jun 2021, Thomas Zimmermann wrote:
> > > > > diff --git a/drivers/gpu/drm/drm_vblank.c
> > > > > b/drivers/gpu/drm/drm_vblank.c
> > > > > index 3417e1ac7918..10fe16bafcb6 100644
> > > > > --- a/drivers/gpu/drm/drm_vblank.c
> > > > > +++ b/drivers/gpu/drm/drm_vblank.c
> > > > > @@ -1748,8 +1748,16 @@ int drm_wait_vblank_ioctl(struct drm_device
> > > > > *dev, void *data,
> > > > > unsigned int pipe_index;
> > > > > unsigned int flags, pipe, high_pipe;
> > > > > - if (!dev->irq_enabled)
> > > > > - return -EOPNOTSUPP;
> > > > > +#if defined(CONFIG_DRM_LEGACY)
> > > > > + if (unlikely(drm_core_check_feature(dev, DRIVER_LEGACY))) {
> > > > > + if (!dev->irq_enabled)
> > > > > + return -EOPNOTSUPP;
> > > > > + } else /* if DRIVER_MODESET */
> > > > > +#endif
> > > > > + {
> > > > > + if (!drm_dev_has_vblank(dev))
> > > > > + return -EOPNOTSUPP;
> > > > > + }
> > > >
> > > > Sheesh I hate this kind of inline #ifdefs.
> > > >
> > > > Two alternate suggestions that I believe should be as just efficient:
> > >
> > > Or how about:
> > >
> > > static bool drm_wait_vblank_supported(struct drm_device *dev)
> > >
> > > {
> > >
> > > if defined(CONFIG_DRM_LEGACY)
> > > if (unlikely(drm_core_check_feature(dev, DRIVER_LEGACY)))
> > >
> > > return dev->irq_enabled;
> > >
> > > #endif
> > > return drm_dev_has_vblank(dev);
> > >
> > > }
> > >
> > >
> > > ?
> > >
> > > It's inline, but still readable.
> >
> > It's definitely better than the original, but it's unclear to me why
> > you'd prefer this over option 2) below. I guess the only reason I can
> > think of is emphasizing the conditional compilation. However,
> > IS_ENABLED() is widely used in this manner specifically to avoid inline
> > #if, and the compiler optimizes it away.
>
> It's simply more readable to me as the condition is simpler. But option 2 is
> also ok.
Perhaps do something like this, then:
if (IS_ENABLED(CONFIG_DRM_LEGACY)) {
if (unlikely(drm_core_check_feature(dev, DRIVER_LEGACY)))
return dev->irq_enabled;
}
return drm_dev_has_vblank(dev);
That's about just as readable as the variant involving the preprocessor
but has all the benefits of not using the preprocessor.
Thierry
signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/6] KVM: Remove uses of struct page from x86 and arm64 MMU
On 24/06/21 13:42, Nicholas Piggin wrote:
+static int kvm_try_get_pfn(kvm_pfn_t pfn)
+{
+ if (kvm_is_reserved_pfn(pfn))
+ return 1;
So !pfn_valid would always return true. Yeah, this should work and is
certainly appealing!
Paolo
+ return get_page_unless_zero(pfn_to_page(pfn));
+}
+
static int hva_to_pfn_remapped(struct vm_area_struct *vma,
unsigned long addr, bool *async,
bool write_fault, bool *writable,
@@ -2104,13 +2111,21 @@ static int hva_to_pfn_remapped(struct vm_area_struct
*vma,
* Whoever called remap_pfn_range is also going to call e.g.
* unmap_mapping_range before the underlying pages are freed,
* causing a call to our MMU notifier.
+*
+* Certain IO or PFNMAP mappings can be backed with valid
+* struct pages, but be allocated without refcounting e.g.,
+* tail pages of non-compound higher order allocations, which
+* would then underflow the refcount when the caller does the
+* required put_page. Don't allow those pages here.
*/
- kvm_get_pfn(pfn);
+ if (!kvm_try_get_pfn(pfn))
+ r = -EFAULT;
out:
pte_unmap_unlock(ptep, ptl);
*p_pfn = pfn;
- return 0;
+
+ return r;
}
/*
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/6] KVM: Remove uses of struct page from x86 and arm64 MMU
Excerpts from Nicholas Piggin's message of June 24, 2021 8:34 pm:
> Excerpts from David Stevens's message of June 24, 2021 1:57 pm:
>> KVM supports mapping VM_IO and VM_PFNMAP memory into the guest by using
>> follow_pte in gfn_to_pfn. However, the resolved pfns may not have
>> assoicated struct pages, so they should not be passed to pfn_to_page.
>> This series removes such calls from the x86 and arm64 secondary MMU. To
>> do this, this series modifies gfn_to_pfn to return a struct page in
>> addition to a pfn, if the hva was resolved by gup. This allows the
>> caller to call put_page only when necessated by gup.
>>
>> This series provides a helper function that unwraps the new return type
>> of gfn_to_pfn to provide behavior identical to the old behavior. As I
>> have no hardware to test powerpc/mips changes, the function is used
>> there for minimally invasive changes. Additionally, as gfn_to_page and
>> gfn_to_pfn_cache are not integrated with mmu notifier, they cannot be
>> easily changed over to only use pfns.
>>
>> This addresses CVE-2021-22543 on x86 and arm64.
>
> Does this fix the problem? (untested I don't have a POC setup at hand,
> but at least in concept)
This one actually compiles at least. Unfortunately I don't have much
time in the near future to test, and I only just found out about this
CVE a few hours ago.
---
It's possible to create a region which maps valid but non-refcounted
pages (e.g., tail pages of non-compound higher order allocations). These
host pages can then be returned by gfn_to_page, gfn_to_pfn, etc., family
of APIs, which take a reference to the page, which takes it from 0 to 1.
When the reference is dropped, this will free the page incorrectly.
Fix this by only taking a reference on the page if it was non-zero,
which indicates it is participating in normal refcounting (and can be
released with put_page).
---
virt/kvm/kvm_main.c | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 6a6bc7af0e28..46fb042837d2 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -2055,6 +2055,13 @@ static bool vma_is_valid(struct vm_area_struct *vma,
bool write_fault)
return true;
}
+static int kvm_try_get_pfn(kvm_pfn_t pfn)
+{
+ if (kvm_is_reserved_pfn(pfn))
+ return 1;
+ return get_page_unless_zero(pfn_to_page(pfn));
+}
+
static int hva_to_pfn_remapped(struct vm_area_struct *vma,
unsigned long addr, bool *async,
bool write_fault, bool *writable,
@@ -2104,13 +2111,21 @@ static int hva_to_pfn_remapped(struct vm_area_struct
*vma,
* Whoever called remap_pfn_range is also going to call e.g.
* unmap_mapping_range before the underlying pages are freed,
* causing a call to our MMU notifier.
+*
+* Certain IO or PFNMAP mappings can be backed with valid
+* struct pages, but be allocated without refcounting e.g.,
+* tail pages of non-compound higher order allocations, which
+* would then underflow the refcount when the caller does the
+* required put_page. Don't allow those pages here.
*/
- kvm_get_pfn(pfn);
+ if (!kvm_try_get_pfn(pfn))
+ r = -EFAULT;
out:
pte_unmap_unlock(ptep, ptl);
*p_pfn = pfn;
- return 0;
+
+ return r;
}
/*
--
2.23.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH V2] drm/i915/selftest: Extend ctx_timestamp ICL workaround to GEN11
EHL and JSL are also observing requirement for 80ns interval for CTX_TIMESTAMP thus extending it to GEN11. Changes since V1: - IS_GEN replaced by GRAPHICS_VER - Tvrtko Acked-by: Tvrtko Ursulin Signed-off-by: Tejas Upadhyay --- drivers/gpu/drm/i915/gt/selftest_engine_pm.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/selftest_engine_pm.c b/drivers/gpu/drm/i915/gt/selftest_engine_pm.c index 72cca3f0da21..75569666105d 100644 --- a/drivers/gpu/drm/i915/gt/selftest_engine_pm.c +++ b/drivers/gpu/drm/i915/gt/selftest_engine_pm.c @@ -173,8 +173,8 @@ static int __live_engine_timestamps(struct intel_engine_cs *engine) d_ctx = trifilter(s_ctx); d_ctx *= engine->gt->clock_frequency; - if (IS_ICELAKE(engine->i915)) - d_ring *= 1250; /* Fixed 80ns for icl ctx timestamp? */ + if (GRAPHICS_VER(engine->i915) == 11) + d_ring *= 1250; /* Fixed 80ns for GEN11 ctx timestamp? */ else d_ring *= engine->gt->clock_frequency; -- 2.31.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915: Reinstate the mmap ioctl for some platforms
Reinstate the mmap ioctl for all current integrated platforms.
The intention was really to have it disabled for discrete graphics
where we enforce a single mmap mode.
Fixes: 35cbd91eb541 ("drm/i915: Disable mmap ioctl for gen12+")
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
---
v2:
- Added a R-B.
- Fixed up the code comment a bit.
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index 2fd155742bd2..4f50a508c7a0 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -62,10 +62,11 @@ i915_gem_mmap_ioctl(struct drm_device *dev, void *data,
struct drm_i915_gem_object *obj;
unsigned long addr;
- /* mmap ioctl is disallowed for all platforms after TGL-LP. This also
-* covers all platforms with local memory.
+ /*
+* mmap ioctl is disallowed for all discrete platforms,
+* and for all platforms with GRAPHICS_VER > 12.
*/
- if (GRAPHICS_VER(i915) >= 12 && !IS_TIGERLAKE(i915))
+ if (IS_DGFX(i915) || GRAPHICS_VER(i915) > 12)
return -EOPNOTSUPP;
if (args->flags & ~(I915_MMAP_WC))
--
2.31.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Mesa-dev] [PATCH] dma-buf: Document dma-buf implicit fencing/resv fencing rules
On Thu, Jun 24, 2021 at 1:08 PM Daniel Stone wrote: > > Hi, > > On Wed, 23 Jun 2021 at 17:20, Daniel Vetter wrote: > > +* > > +* IMPLICIT SYNCHRONIZATION RULES: > > +* > > +* Drivers which support implicit synchronization of buffer access > > as > > +* e.g. exposed in `Implicit Fence Poll Support`_ should follow the > > +* below rules. > > 'Should' ... ? Must. Yeah I guess I can upgrade a bunch of them. > > +* - Drivers should add a shared fence through > > +* dma_resv_add_shared_fence() for anything the userspace API > > +* considers a read access. This highly depends upon the API and > > +* window system: E.g. OpenGL is generally implicitly > > synchronized on > > +* Linux, but explicitly synchronized on Android. Whereas Vulkan > > is > > +* generally explicitly synchronized for everything, and window > > system > > +* buffers have explicit API calls (which then need to make sure > > the > > +* implicit fences store here in @resv are updated correctly). > > +* > > +* - [...] > > Mmm, I think this is all right, but it could be worded much more > clearly. Right now it's a bunch of points all smashed into one, and > there's a lot of room for misinterpretation. > > Here's a strawman, starting with most basic and restrictive, working > through to when you're allowed to wriggle your way out: > > Rule 1: Drivers must add a shared fence through > dma_resv_add_shared_fence() for any read accesses against that buffer. > This appends a fence to the shared array, ensuring that any future > non-read access will be synchronised against this operation to only > begin after it has completed. > > Rule 2: Drivers must add an exclusive fence through > dma_resv_add_excl_fence() for any write accesses against that buffer. > This replaces the exclusive fence with the new operation, ensuring > that all future access will be synchronised against this operation to > only begin after it has completed. > > Rule 3: Drivers must synchronise all accesses to buffers against > existing implicit fences. Read accesses must synchronise against the > exclusive fence (read-after-write), and write accesses must > synchronise against both the exclusive (write-after-write) and shared > (write-after-read) fences. > > Note 1: Users like OpenGL and window systems on non-Android userspace > are generally implicitly synchronised. An implicitly-synchronised > userspace is unaware of fences from prior operations, so the kernel > mediates scheduling to create the illusion that GPU work is FIFO. For > example, an application will flush and schedule GPU write work to > render its image, then immediately tell the window system to display > that image; the window system may immediately flush and schedule GPU > read work to display that image, with neither waiting for the write to > have completed. The kernel provides coherence by synchronising the > read access against the write fence in the exclusive slot, so that the > image displayed is correct. > > Note 2: Users like Vulkan and Android window system are generally > explicitly synchronised. An explicitly-synchronised userspace is > responsible for tracking its own read and write access and providing > the kernel with synchronisation barriers. For instance, a Vulkan > application rendering to a buffer and subsequently using it as a read > texture, must annotate the read operation with a read-after-write > synchronisation barrier. > > Note 3: Implicit and explicit userspace can coexist. For instance, an > explicitly-synchronised Vulkan application may be running as a client > of an implicitly-synchronised window system which uses OpenGL for > composition; an implicitly-synchronised OpenGL application may be > running as a client of a window system which uses Vulkan for > composition. > > Note 4: Some subsystems, for example V4L2, do not pipeline operations, > and instead only return to userspace when the scheduled work against a > buffer has fully retired. > > Exemption 1: Fully self-coherent userspace may skip implicit > synchronisation barriers. For instance, accesses between two > Vulkan-internal buffers allocated by a single application do not need > to synchronise against each other's implicit fences, as the client is > responsible for explicitly providing barriers for access. A > self-contained OpenGL userspace also has no need to implicitly > synchronise its access if the driver instead tracks all access and > inserts the appropriate synchronisation barriers. > > Exemption 2: When implicit and explicit userspace coexist, the > explicit side may skip intermediate synchronisation, and only place > synchronisation barriers at transition points. For example, a Vulkan > compositor displaying a buffer from an OpenGL application would need > to synchronise its first access against the fence placed in the > exclusive implicit-synchronisation slot. Once
Re: [Intel-gfx] [PATCH] drm/i915: Reinstate the mmap ioctl for some platforms
On Thu, 24 Jun 2021 at 11:53, Thomas Hellström
wrote:
>
> Reinstate the mmap ioctl for all current integrated platforms.
> The intention was really to have it disabled for discrete graphics
> where we enforce a single mmap mode.
>
> Fixes: 35cbd91eb541 ("drm/i915: Disable mmap ioctl for gen12+")
> Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/2] drm/i915: support forcing the page size with lmem
On 6/23/21 4:16 PM, Matthew Auld wrote:
For some specialised objects we might need something larger than the
regions min_page_size due to some hw restriction, and slightly more
hairy is needing something smaller with the guarantee that such objects
will never be inserted into any GTT, which is the case for the paging
structures.
This also fixes how we setup the BO page_alignment, if we later migrate
the object somewhere else. For example if the placements are {SMEM,
LMEM}, then we might get this wrong. Pushing the min_page_size behaviour
into the manager should fix this.
v2(Thomas): push the default page size behaviour into buddy_man, and let
the user override it with the page-alignment, which looks cleaner
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Thomas Hellström
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
