Re: [Intel-gfx] [PATCH v2 0/4] More MTL WA and powerwell patches
Hi, On 19.04.2023 00:04, Radhakrishna Sripada wrote: This series adds 2 MTL WA's and 2 patches to fix re-use "DC off" power wells. v2: Haridhar Kalvala (1): drm/i915/mtl: WA to clear RDOP clock gating Madhumitha Tolakanahalli Pradeep (1): drm/i915/mtl: Extend Wa_22011802037 to MTL A-step Matt Roper (2): drm/i915: Use separate "DC off" power well for ADL-P and DG2 drm/i915/mtl: Re-use ADL-P's "DC off" power well Apparently this patchset broke bat-dg2-11 machine on CI. Both pre and post merge results suggests it [1][2]. Regarding bat-dg2-11, this machine contains DG2 AND ADL cards. So the bug hits ADL card on bat-dg2-11 machine. No idea why only this one, there are multiple bat machines with ADL. [1]: http://gfx-ci.igk.intel.com/tree/drm-tip/bat-dg2-11.html [2]: http://gfx-ci.igk.intel.com/tree/drm-tip/Patchwork_115292v3/index.html? Regards Andrzej .../i915/display/intel_display_power_map.c| 57 +-- drivers/gpu/drm/i915/gt/intel_workarounds.c | 3 + .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 12 ++-- 3 files changed, 48 insertions(+), 24 deletions(-)
Re: [Intel-gfx] [PATCH 01/13] drm/i915/mtl: C20 PLL programming
> -Original Message-
> From: Sripada, Radhakrishna
> Sent: Saturday, April 22, 2023 2:24 AM
> To: Kahola, Mika
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 01/13] drm/i915/mtl: C20 PLL programming
>
> Hi Mika,
>
> On Thu, Apr 20, 2023 at 03:40:38PM +0300, Mika Kahola wrote:
> > C20 phy PLL programming sequence for DP, DP2.0, HDMI2.x non-FRL and
> > HDMI2.x FRL. This enables C20 MPLLA and MPLLB programming sequence.
> > add
> > 4 lane support for c20.
> >
> > Signed-off-by: José Roberto de Souza
> > Signed-off-by: Mika Kahola
> > Signed-off-by: Bhanuprakash Modem
> > Signed-off-by: Imre Deak
> > Signed-off-by: Arun R Murthy
> > ---
> > drivers/gpu/drm/i915/display/intel_cx0_phy.c | 280
> > +++--- .../gpu/drm/i915/display/intel_cx0_phy_regs.h | 32 ++
> > drivers/gpu/drm/i915/display/intel_ddi.c | 3 +-
> > .../drm/i915/display/intel_display_types.h| 15 +-
> > drivers/gpu/drm/i915/display/intel_dp.c | 12 +-
> > 5 files changed, 300 insertions(+), 42 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> > b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> > index 83180074b512..dd96bf5e179e 100644
> > --- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> > +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> > @@ -273,6 +273,18 @@ static void intel_cx0_write(struct drm_i915_private
> *i915, enum port port,
> > __intel_cx0_write(i915, port, lane, addr, data, committed); }
> >
> > +static void intel_c20_sram_write(struct drm_i915_private *i915, enum port
> port,
> > +int lane, u16 addr, u16 data)
> > +{
> > + assert_dc_off(i915);
> > +
> > + intel_cx0_write(i915, port, lane, PHY_C20_WR_ADDRESS_H, addr >> 8,
> 0);
> > + intel_cx0_write(i915, port, lane, PHY_C20_WR_ADDRESS_L, addr & 0xff,
> > +0);
> > +
> > + intel_cx0_write(i915, port, lane, PHY_C20_WR_DATA_H, data >> 8, 0);
> > + intel_cx0_write(i915, port, lane, PHY_C20_WR_DATA_L, data & 0xff,
> > +1); }
> > +
> > static void __intel_cx0_rmw(struct drm_i915_private *i915, enum port port,
> > int lane, u16 addr, u8 clear, u8 set, bool
> > committed) {
> @@
> > -1415,6 +1427,207 @@ void intel_c10pll_dump_hw_state(struct
> drm_i915_private *i915,
> > i + 2, hw_state->pll[i + 2], i + 3, hw_state->pll[i
> > + 3]);
> }
> >
> > +static bool intel_c20_use_mplla(u32 clock) {
> > + /* 10G and 20G rates use MPLLA */
> > + if (clock == 312500 || clock == 625000)
> > + return true;
> > +
> > + return false;
> > +}
> > +
> > +static u8 intel_c20_get_dp_rate(u32 clock) {
> > + switch (clock) {
> > + case 162000: /* 1.62 Gbps DP1.4 */
> > + return 0;
> > + case 27: /* 2.7 Gbps DP1.4 */
> > + return 1;
> > + case 54: /* 5.4 Gbps DP 1.4 */
> > + return 2;
> > + case 81: /* 8.1 Gbps DP1.4 */
> > + return 3;
> > + case 216000: /* 2.16 Gbps eDP */
> > + return 4;
> > + case 243000: /* 2.43 Gbps eDP */
> > + return 5;
> > + case 324000: /* 3.24 Gbps eDP */
> > + return 6;
> > + case 432000: /* 4.32 Gbps eDP */
> > + return 7;
> > + case 312500: /* 10 Gbps DP2.0 */
> > + return 8;
> > + case 421875: /* 13.5 Gbps DP2.0 */
> > + return 9;
> > + case 625000: /* 20 Gbps DP2.0*/
> > + return 10;
> Worth adding the rate for 6.75 Gbps eDP.
Definitely. As per BSPec it seems that we are missing also 6.48Gbps rate as
well i.e. return value "11".
>
> > + default:
> > + MISSING_CASE(clock);
> > + return 0;
> > + }
> > +}
> > +
> > +static u8 intel_c20_get_hdmi_rate(u32 clock) {
> > + switch (clock) {
> > + case 25175:
> > + case 27000:
> > + case 74250:
> > + case 148500:
> > + case 594000:
> > + return 0;
> > + case 166670: /* 3 Gbps */
> > + case 30: /* 6 Gbps */
> > + case 70: /* 12 Gbps */
> > + return 1;
> > + case 40: /* 8 Gbps */
> > + return 2;
> > + case 60: /* 10 Gbps */
> > + return 3;
> > + default:
> > + MISSING_CASE(clock);
> > + return 0;
> > + }
> > +}
> > +
> > +static bool is_dp2(u32 clock)
> > +{
> > + /* DP2.0 clock rates */
> > + if (clock == 312500 || clock == 421875 || clock == 625000)
> > + return true;
> > +
> > + return false;
> > +}
> > +
> > +static bool is_hdmi_frl(u32 clock)
> > +{
> > + switch (clock) {
> > + case 166670: /* 3 Gbps */
> > + case 30: /* 6 Gbps */
> > + case 40: /* 8 Gbps */
> > + case 60: /* 10 Gbps */
> > + case 70: /* 12 Gbps */
> > + return true;
> > + default:
> > + return false;
> > + }
> > +}
> > +
> > +static bool intel_c20_protocol_switch_valid(struct intel_encoder
> > +*encoder) {
> > + struct intel_digital_port *intel_dig_port =
> > +enc_to_dig_port(encoder);
> > +
> > + /* bank
Re: [Intel-gfx] [PATCH 7/8] drm/i915: use pat_index instead of cache_level
On 23/04/2023 07:12, Yang, Fei wrote:
On 20/04/2023 00:00, fei.y...@intel.com wrote:
From: Fei Yang
Currently the KMD is using enum i915_cache_level to set caching policy
for buffer objects. This is flaky because the PAT index which really
controls the caching behavior in PTE has far more levels than what's
defined in the enum. In addition, the PAT index is platform dependent,
having to translate between i915_cache_level and PAT index is not
reliable, and makes the code more complicated.
From UMD's perspective there is also a necessity to set caching policy for
performance fine tuning. It's much easier for the UMD to directly use
PAT index because the behavior of each PAT index is clearly defined in Bspec.
Having the abstracted i915_cache_level sitting in between would only
cause more ambiguity.
For these reasons this patch replaces i915_cache_level with PAT index.
Also note, the cache_level is not completely removed yet, because the
KMD still has the need of creating buffer objects with simple cache
settings such as cached, uncached, or writethrough. For such simple
cases, using cache_level would help simplify the code.
Cc: Chris Wilson
Cc: Matt Roper
Signed-off-by: Fei Yang
Reviewed-by: Andi Shyti
[snip]
bool i915_gem_cpu_write_needs_clflush(struct drm_i915_gem_object
*obj) @@ -267,7 +267,7 @@ int i915_gem_object_set_cache_level(struct
drm_i915_gem_object *obj,
{
int ret;
-if (obj->cache_level == cache_level)
+if (i915_gem_object_has_cache_level(obj, cache_level))
return 0;
When userspace calls i915_gem_set_caching_ioctl
We are ending the support for set_caching_ioctl.
Not on all platforms.
after having set the PAT index explicitly this will make it silently succeed
regardless of the cache level passed in, no? Because of:
Yes, that's the point. For objects created by userspace with PAT index set,
KMD is not supposed to touch the setting.
Why would that be a reason to lie to it? What would would be the problem
with telling it of the mistake?
+bool i915_gem_object_has_cache_level(const struct drm_i915_gem_object *obj,
+ enum i915_cache_level lvl)
+{
+ /*
+ * cache_level == I915_CACHE_INVAL indicates the UMD's have set the
+ * caching policy through pat_index, in which case the KMD should
+ * leave the coherency to be managed by user space, simply return
+ * true here.
+ */
+ if (obj->cache_level == I915_CACHE_INVAL)
+ return true;
I think we need to let it know it is doing it wrong with an error.
This is not an error, by design userspace should know exactly what it's doing.
IMO when return values can be misleading that means the API is not great.
I don't see a good reason to lie to both in kernel callers and to
userspace (set_caching).
Regards,
Tvrtko
Re: [Intel-gfx] [PATCH 8/8] drm/i915: Allow user to set cache at BO creation
[fixed mailing lists addresses] On 24/04/2023 09:36, Jordan Justen wrote: On 2023-04-23 00:05:06, Yang, Fei wrote: On 2023-04-20 09:11:18, Yang, Fei wrote: On 20/04/2023 12:39, Andi Shyti wrote: Hi Fei, because this is an API change, we need some more information here. First of all you need to CC the userspace guys that have been working on top of your series and get their ack's. Yes, and a link to a Mesa merge request which uses the uapi should be included. Working with Mesa team on this, stay tuned. I would like to see the extension detection issue is handled before ack'ing this. How about a new DRM_I915_QUERY_GEM_CREATE_EXTENSIONS item, that returns a u64 array of usable extension names for DRM_IOCTL_I915_GEM_CREATE_EXT? I agree a query mechanism is necessary, but that should be generic for all uAPI's, not just for GEM_CREATE. A similar DRM_I915_QUERY_GEM_CONTEXT_CREATE_EXTENSIONS could also provide an alternative to Alan's "drm/i915/uapi/pxp: Add a GET_PARAM for PXP", and more easily allow advertising future new extensions for context/buffer creation. I think we should have a discussion and come up with a sustainable design for the query uAPI, rather than just put in a quick hack for this. I think you are being a bit too quick to dismiss my idea as a quick hack... Nevetheless, I would love to hear an alternate suggestion. Just as long as it's not, "let's figure this out later, because I need to add this feature now". I don't think "just try to use it and if it fails, I guess it isn't supported" is reasonable. So, if we can't do better, at least add a GET_PARAM. Yeah, it's a quick hack, but it's better than nothing. Being able to "list" supported extensions sounds like a reasonable principle, albeit a departure from the design direction to date. Which means there are probably no quick solutions. Also, AFAIU, only PXP context create is the problematic one, right? Everything else is pretty much instant or delayed allocation so super cheap to probe by attempting to use. If I got that right and given this series is about drm_i915_gem_create_ext I don't think this side discussion should be blocking it. Furthermore the PXP context create story is even more complicated, in a way that it is not just about querying whether the extension is supported, but the expensive check is something more complicated. Going back to implementation details for this proposed new feature, one alternative to query could be something like: drm_i915_gem_create_ext.flags |= I915_GEM_CREATE_EXT_FLAG_PROBE_EXTENSIONS; That would be somewhat more light weight to implement that the i915_query route. And it appears it would work for all ioctls which support extensions apart for i915_context_param_engines. Regards, Tvrtko
Re: [Intel-gfx] [PATCH 7/8] drm/i915: use pat_index instead of cache_level
On 23/04/2023 07:52, Yang, Fei wrote:
On 20/04/2023 00:00, fei.y...@intel.com wrote:
From: Fei Yang
Currently the KMD is using enum i915_cache_level to set caching policy for
buffer objects. This is flaky because the PAT index which really controls
the caching behavior in PTE has far more levels than what's defined in the
enum. In addition, the PAT index is platform dependent, having to translate
between i915_cache_level and PAT index is not reliable, and makes the code
more complicated.
>From UMD's perspective there is also a necessity to set caching policy for
performance fine tuning. It's much easier for the UMD to directly use PAT
index because the behavior of each PAT index is clearly defined in Bspec.
Having the abstracted i915_cache_level sitting in between would only cause
more ambiguity.
For these reasons this patch replaces i915_cache_level with PAT index. Also
note, the cache_level is not completely removed yet, because the KMD still
has the need of creating buffer objects with simple cache settings such as
cached, uncached, or writethrough. For such simple cases, using cache_level
would help simplify the code.
Cc: Chris Wilson
Cc: Matt Roper
Signed-off-by: Fei Yang
Reviewed-by: Andi Shyti
I think have some ideas no how to perhaps make this simpler, please bear
with me.
In my mind get/set caching ioctls need to be failing once explicit pat
index has been set by userspace. Or at least not return false information.
By design we are ending the support for set caching ioctl. The patch is included
in this series, "drm/i915/mtl: end support for set caching ioctl"
+ if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 70))
+ return -EOPNOTSUPP;
+
And I don't like i915_gem_object_has_cache_level and
i915_gem_get_pat_index as a refactoring step.
It also seems that the driver has a need to query the caching mode set
regardless of the route (of setting).
Only for the objects created by the KMD. For UMD created objects with PAT
index set KMD should never touch the setting.
So how about this.
Three callers which query the caching mode: use_cpu_reloc, vm_fault_gtt,
gpu_write_needs_clflush.
We convert them to be like:
i915_gem_object_has_caching_mode(obj, PAT_UC / PAT_WT / ...);
PAT_UC/WT/WB are platform dependent
(https://gfxspecs.intel.com/Predator/Home/Index/45101),
performing this check you would have to do something like,
if (MTL)
...
else if (PVC)
...
else if (GEN12)
...
else
...
No, it would be doable with a table as I suggested below. And that table
could be re-used for debugfs pretty-printing simplifying that code too.
Then apart from the per platform tables for mapping between cache level
to pat index, you add tables which map pat index to caching modes
(PAT_UC, etc, naming TBD, just enums or bitmasks also TBD, I haven't
looked at the bspec to see how exactly it works).
You would use that table in the i915_gem_object_has_caching_mode helper,
called from the above three functions instead of obj->cache_level direct
comparison.
I am assuming at least for instance cache_level != I915_CACHE_NONE would
be equivalent to i915_gem_object_has_caching_mode(obj, PAT_UC), etc.
So far kernel only needs 4 cache levels defined in enum i915_cache_level,
kernel doesn't need to understand all PAT indices. By desgin if the userspace
is setting PAT index directly, kernel only needs to pass the setting to PTE.
For objects created by kernel (including objects created by userspace without
specifying pat index), there are only 4 options (defined in the
cachelevel_to_pat).
For objects created by userspace with PAT index set (GEM_CREATE + set_pat
extension),
kernel should not touch the setting, just pass it to the PAT index bits in PTE.
That's why I was only checking cache_level. Handling PAT index is much more
complicated because of its platform dependent nature and even the number of
PAT indices varies from platform to platform. Fortunately kernel doesn't need
to understand that.
Yeah but I think you maybe missed the spirit of my proposal - which is
to simplify the internal code paths by not having the duality of
cache_level-vs-pat almost all the way down. But instead cut it at the
top API level.
You have this:
+ .cachelevel_to_pat = { \
+ [I915_CACHE_NONE] = 0, \
+ [I915_CACHE_LLC]= 1, \
+ [I915_CACHE_L3_LLC] = 2, \
+ [I915_CACHE_WT] = 3, \
+ }
I propose to add something like:
.legacy_platform_pat = { /* pat index to driver logical flags */
[0] = PAT_UC,
[1] = PAT_WB | PAT_LLC, /* Just illustrating the principle */
};
i915->platform_pat = &legacy_platform_pat
i915_gem_object_has_caching_mode(obj, PAT_UC)
...
return i915->platform_pat & PAT_UC == PAT_UC /* give or take */
get/set_caching_ioctl
{
...
if (obj->has_pat_index) /* set in the extension only */
return -EINVAL;
debugfs:
i915_show_pat_flags(i9
[Intel-gfx] [PATCH V2] drm/i915/mtl: Add workaround 14018778641
WA 18018781329 is applicable now across all MTL
steppings.
V2:
- Remove IS_MTL check, code already running for MTL - Matt
Cc: Matt Roper
Signed-off-by: Tejas Upadhyay
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 30 ++---
1 file changed, 14 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 312eb8b5f949..de4f8e2e8e8c 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -1695,19 +1695,18 @@ pvc_gt_workarounds_init(struct intel_gt *gt, struct
i915_wa_list *wal)
static void
xelpg_gt_workarounds_init(struct intel_gt *gt, struct i915_wa_list *wal)
{
+ /* Wa_14018778641 / Wa_18018781329 */
+ wa_mcr_write_or(wal, RENDER_MOD_CTRL, FORCE_MISS_FTLB);
+ wa_mcr_write_or(wal, COMP_MOD_CTRL, FORCE_MISS_FTLB);
+
if (IS_MTL_GRAPHICS_STEP(gt->i915, M, STEP_A0, STEP_B0) ||
IS_MTL_GRAPHICS_STEP(gt->i915, P, STEP_A0, STEP_B0)) {
/* Wa_14014830051 */
wa_mcr_write_clr(wal, SARB_CHICKEN1, COMP_CKN_IN);
- /* Wa_18018781329 */
- wa_mcr_write_or(wal, RENDER_MOD_CTRL, FORCE_MISS_FTLB);
- wa_mcr_write_or(wal, COMP_MOD_CTRL, FORCE_MISS_FTLB);
-
/* Wa_14015795083 */
wa_write_clr(wal, GEN7_MISCCPCTL,
GEN12_DOP_CLOCK_GATE_RENDER_ENABLE);
}
-
/*
* Unlike older platforms, we no longer setup implicit steering here;
* all MCR accesses are explicitly steered.
@@ -1718,17 +1717,16 @@ xelpg_gt_workarounds_init(struct intel_gt *gt, struct
i915_wa_list *wal)
static void
xelpmp_gt_workarounds_init(struct intel_gt *gt, struct i915_wa_list *wal)
{
- if (IS_MTL_MEDIA_STEP(gt->i915, STEP_A0, STEP_B0)) {
- /*
-* Wa_18018781329
-*
-* Note that although these registers are MCR on the primary
-* GT, the media GT's versions are regular singleton registers.
-*/
- wa_write_or(wal, XELPMP_GSC_MOD_CTRL, FORCE_MISS_FTLB);
- wa_write_or(wal, XELPMP_VDBX_MOD_CTRL, FORCE_MISS_FTLB);
- wa_write_or(wal, XELPMP_VEBX_MOD_CTRL, FORCE_MISS_FTLB);
- }
+ /*
+* Wa_14018778641
+* Wa_18018781329
+*
+* Note that although these registers are MCR on the primary
+* GT, the media GT's versions are regular singleton registers.
+*/
+ wa_write_or(wal, XELPMP_GSC_MOD_CTRL, FORCE_MISS_FTLB);
+ wa_write_or(wal, XELPMP_VDBX_MOD_CTRL, FORCE_MISS_FTLB);
+ wa_write_or(wal, XELPMP_VEBX_MOD_CTRL, FORCE_MISS_FTLB);
debug_dump_steering(gt);
}
--
2.25.1
Re: [Intel-gfx] [PATCH 0/2] Use i915 instead of dev_priv
On Sun, 23 Apr 2023, Andi Shyti wrote: > Hi, > > On Fri, Apr 21, 2023 at 03:46:52PM +0200, Andi Shyti wrote: >> Hi, >> >> just another "Friday patch". While reviewing some patches from >> Tejas I found a bit confusing the use of dev_priv__ inside the >> for_each_engine(), perhaps it should be moved inside the gt/? >> >> As I was at it I made the /dev_priv/i915/ change which is still >> harmless. Next in queue is to change the i915_irq.h, which is a >> bit tricky (but not much) as the "dev_priv" is hardcoded inside >> some defines. >> >> Andi >> >> Andi Shyti (2): >> drm/i915/i915_drv: Use proper parameter naming in for_each_gt() >> drm/i915/i915_drv: Use i915 instead of dev_priv insied the file_priv >> structure >> >> drivers/gpu/drm/i915/i915_drv.h | 462 >> 1 file changed, 231 insertions(+), 231 deletions(-) > > Pushed to dmr-intel-gt-next. That's going to create problems for us for weeks to come. I'm actually tempted to ask Joonas or Tvrtko to just force push that out of there. Only use drm-intel-gt-next for stuff that's specifically about gt or gem, and touches files used by gt or gem only. For everything else, use drm-intel-next. When in doubt, err on the side of drm-intel-next. It's not enough that one of the patches changes parameters of for_each_gt() macro. We can cross-merge drm-intel-next to drm-intel-gt-next, but we can't cross-merge drm-intel-gt-next to drm-intel-next. This means the only way to sync those i915_drv.h changes to drm-intel-next is to have a drm-intel-gt-next pull request merged to drm-next, and then backmerged to drm-intel-next. That's not going to happen for several weeks. Any change aimed at drm-intel-next that conflicts with the i915_drv.h changes will now be pending on those merges. BR, Jani. > > Thanks Rodrigo and Andrzej for your review. > > Andi -- Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH 7/9] drm/sti/sti_hdmi: convert to using is_hdmi from display info
Hi Jani,
On Thu, Sep 01, 2022 at 03:47:09PM +0300, Jani Nikula wrote:
> Prefer the parsed results for is_hdmi in display info over calling
> drm_detect_hdmi_monitor(). Remove the now redundant hdmi_monitor member
> from struct sti_hdmi.
>
> Cc: Alain Volmat
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/sti/sti_hdmi.c | 11 ++-
> drivers/gpu/drm/sti/sti_hdmi.h | 2 --
> 2 files changed, 6 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c
> index cb82622877d2..7e6d47c1c43b 100644
> --- a/drivers/gpu/drm/sti/sti_hdmi.c
> +++ b/drivers/gpu/drm/sti/sti_hdmi.c
> @@ -266,6 +266,7 @@ static void hdmi_active_area(struct sti_hdmi *hdmi)
> */
> static void hdmi_config(struct sti_hdmi *hdmi)
> {
> + struct drm_connector *connector = hdmi->drm_connector;
> u32 conf;
>
> DRM_DEBUG_DRIVER("\n");
> @@ -275,7 +276,7 @@ static void hdmi_config(struct sti_hdmi *hdmi)
>
> /* Select encryption type and the framing mode */
> conf |= HDMI_CFG_ESS_NOT_OESS;
> - if (hdmi->hdmi_monitor)
> + if (connector->display_info.is_hdmi)
> conf |= HDMI_CFG_HDMI_NOT_DVI;
>
> /* Set Hsync polarity */
> @@ -985,15 +986,15 @@ static int sti_hdmi_connector_get_modes(struct
> drm_connector *connector)
> if (!edid)
> goto fail;
>
> - hdmi->hdmi_monitor = drm_detect_hdmi_monitor(edid);
> - DRM_DEBUG_KMS("%s : %dx%d cm\n",
> - (hdmi->hdmi_monitor ? "hdmi monitor" : "dvi monitor"),
> - edid->width_cm, edid->height_cm);
> cec_notifier_set_phys_addr_from_edid(hdmi->notifier, edid);
>
> count = drm_add_edid_modes(connector, edid);
> drm_connector_update_edid_property(connector, edid);
>
> + DRM_DEBUG_KMS("%s : %dx%d cm\n",
> + (connector->display_info.is_hdmi ? "hdmi monitor" : "dvi
> monitor"),
> + edid->width_cm, edid->height_cm);
> +
> kfree(edid);
> return count;
>
> diff --git a/drivers/gpu/drm/sti/sti_hdmi.h b/drivers/gpu/drm/sti/sti_hdmi.h
> index 05b2f3d0d48d..6d4c3f57bc46 100644
> --- a/drivers/gpu/drm/sti/sti_hdmi.h
> +++ b/drivers/gpu/drm/sti/sti_hdmi.h
> @@ -57,7 +57,6 @@ struct hdmi_audio_params {
> * @reset: reset control of the hdmi phy
> * @ddc_adapt: i2c ddc adapter
> * @colorspace: current colorspace selected
> - * @hdmi_monitor: true if HDMI monitor detected else DVI monitor assumed
> * @audio_pdev: ASoC hdmi-codec platform device
> * @audio: hdmi audio parameters.
> * @drm_connector: hdmi connector
> @@ -83,7 +82,6 @@ struct sti_hdmi {
> struct reset_control *reset;
> struct i2c_adapter *ddc_adapt;
> enum hdmi_colorspace colorspace;
> - bool hdmi_monitor;
> struct platform_device *audio_pdev;
> struct hdmi_audio_params audio;
> struct drm_connector *drm_connector;
> --
Acked-by: Alain Volmat
Thanks.
> 2.34.1
>
Re: [Intel-gfx] [PATCH 03/13] drm/i915/dp: Replace intel_dp.dfp members with the new crtc_state sink_format
On Fri, Mar 31, 2023 at 03:46:03PM +0530, Ankit Nautiyal wrote:
> The decision to use DFP output format conversion capabilities should be
> during compute_config phase.
>
> This patch uses the members of intel_dp->dfp to only store the
> format conversion capabilities of the DP device and uses the crtc_state
> sink_format member, to program the protocol-converter for
> colorspace/format conversion.
>
> v2: Use sink_format to determine the color conversion config for the
> pcon (Ville).
>
> v3: Fix typo: missing 'break' in switch case (lkp kernel test robot).
>
> v4: Add helper to check if DP supports YCBCR420.
>
> v5: Simplify logic for computing output_format, based on the given
> sink_format. (Ville).
> Added scaler constraint for YCbCr420 output.
>
> v6: Split the patch for Scaler constraint for Ycbcr420.
>
> v7: Simplify the policy for selecting output_format:
> Always try for RGB first, followed by YCBCR444, and finally by YCBCR420.
>
> v8: Removed redundant comments, minor refactoring. (Ville)
>
> Signed-off-by: Ankit Nautiyal
> Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 178 +---
> 1 file changed, 125 insertions(+), 53 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 450cb8ba3805..837532952936 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -827,24 +827,92 @@ u8 intel_dp_dsc_get_slice_count(struct intel_dp
> *intel_dp,
> return 0;
> }
>
> +static bool source_can_output(struct intel_dp *intel_dp,
> + enum intel_output_format format)
> +{
> + struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> + bool ycbcr_supported = true;
> +
> + /*
> + * No YCbCr output support on gmch platforms.
> + * Also, ILK doesn't seem capable of DP YCbCr output.
> + * The displayed image is severly corrupted. SNB+ is fine.
> + */
> + if (HAS_GMCH(i915) || IS_IRONLAKE(i915))
> + ycbcr_supported = false;
That extra variable seems rather pointless...
> +
> + switch (format) {
> + case INTEL_OUTPUT_FORMAT_RGB :
> + return true;
> +
> + case INTEL_OUTPUT_FORMAT_YCBCR444:
> + return ycbcr_supported;
could just 'return !GMCH && !ILK' here
> +
> + case INTEL_OUTPUT_FORMAT_YCBCR420:
> + /* Platform < Gen 11 cannot output YCbCr420 format */
> + if (!ycbcr_supported || DISPLAY_VER(i915) < 11)
> + return false;
> +
> + return true;
and 'return DISPLAY_VER >= 11' here.
> +
> + default:
> + MISSING_CASE(format);
> + return false;
> + }
> +}
> +
> +static bool
> +dfp_can_convert_from_rgb(struct intel_dp *intel_dp,
> + enum intel_output_format sink_format)
> +{
> + if (!drm_dp_is_branch(intel_dp->dpcd))
> + return false;
> +
> + if (sink_format == INTEL_OUTPUT_FORMAT_YCBCR444)
> + return intel_dp->dfp.rgb_to_ycbcr;
> +
> + if (sink_format == INTEL_OUTPUT_FORMAT_YCBCR420)
> + return intel_dp->dfp.rgb_to_ycbcr &&
> + intel_dp->dfp.ycbcr_444_to_420;
> +
> + return false;
> +}
> +
> +static bool
> +dfp_can_convert_from_ycbcr444(struct intel_dp *intel_dp,
> + enum intel_output_format sink_format)
> +{
> + if (!drm_dp_is_branch(intel_dp->dpcd))
> + return false;
> +
> + if (sink_format == INTEL_OUTPUT_FORMAT_YCBCR420)
> + return intel_dp->dfp.ycbcr_444_to_420;
> +
> + return false;
> +}
> +
> static enum intel_output_format
> intel_dp_output_format(struct intel_connector *connector,
> enum intel_output_format sink_format)
> {
> struct intel_dp *intel_dp = intel_attached_dp(connector);
> + struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> + enum intel_output_format output_format;
>
> - if (!connector->base.ycbcr_420_allowed ||
> - sink_format != INTEL_OUTPUT_FORMAT_YCBCR420)
> - return INTEL_OUTPUT_FORMAT_RGB;
> + if (sink_format == INTEL_OUTPUT_FORMAT_RGB ||
> + dfp_can_convert_from_rgb(intel_dp, sink_format))
> + output_format = INTEL_OUTPUT_FORMAT_RGB;
>
> - if (intel_dp->dfp.rgb_to_ycbcr &&
> - intel_dp->dfp.ycbcr_444_to_420)
> - return INTEL_OUTPUT_FORMAT_RGB;
> + else if (sink_format == INTEL_OUTPUT_FORMAT_YCBCR444 ||
> + dfp_can_convert_from_ycbcr444(intel_dp, sink_format))
> + output_format = INTEL_OUTPUT_FORMAT_YCBCR444;
>
> - if (intel_dp->dfp.ycbcr_444_to_420)
> - return INTEL_OUTPUT_FORMAT_YCBCR444;
> else
> - return INTEL_OUTPUT_FORMAT_YCBCR420;
> + output_format = INTEL_OUTPUT_FORMAT_YCBCR420;
> +
> + drm_WARN_ON(&i915->drm, !source_can_output(intel_dp, output_format));
> +
Re: [Intel-gfx] [PATCH 04/13] drm/i915/dp: Configure PCON for conversion of output_format to YCbCr444
On Fri, Mar 31, 2023 at 03:46:04PM +0530, Ankit Nautiyal wrote:
> Handle the case with DP to HDMI PCON, where sink_format is set to YCbCr444.
> In that case PCON is required to be configured to convert from given
> output_format to YCbCR444.
>
> Signed-off-by: Ankit Nautiyal
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 837532952936..c3f3003c52ca 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -2862,6 +2862,22 @@ void intel_dp_configure_protocol_converter(struct
> intel_dp *intel_dp,
> MISSING_CASE(crtc_state->output_format);
> break;
> }
> + } else if (crtc_state->sink_format == INTEL_OUTPUT_FORMAT_YCBCR444) {
> + switch (crtc_state->output_format) {
> + case INTEL_OUTPUT_FORMAT_YCBCR420:
> + drm_WARN(&i915->drm,
> + crtc_state->output_format ==
> INTEL_OUTPUT_FORMAT_YCBCR420,
> + "Cannot convert YCbCr420->YCbCr444\n");
Since this should never happen I think we can drop this
and just let the MISSING_CASE() catch it.
with that
Reviewed-by: Ville Syrjälä
> + break;
> + case INTEL_OUTPUT_FORMAT_YCBCR444:
> + break;
> + case INTEL_OUTPUT_FORMAT_RGB:
> + rgb_to_ycbcr = true;
> + break;
> + default:
> + MISSING_CASE(crtc_state->output_format);
> + break;
> + }
> }
>
> tmp = ycbcr444_to_420 ? DP_CONVERSION_TO_YCBCR420_ENABLE : 0;
> --
> 2.25.1
--
Ville Syrjälä
Intel
[Intel-gfx] [RFC PATCH] x86/mm: Fix PAT bit missing from page protection modify mask
Visible glitches have been observed when running graphics applications on
Linux under Xen hypervisor. Those observations have been confirmed with
failures from kms_pwrite_crc Intel GPU test that verifies data coherency
of DRM frame buffer objects using hardware CRC checksums calculated by
display controllers, exposed to userspace via debugfs. Affected
processing paths have then been identified with new test variants that
mmap the objects using different methods and caching modes.
When running as a Xen PV guest, Linux uses Xen provided PAT configuration
which is different from its native one. In particular, Xen specific PTE
encoding of write-combining caching, likely used by graphics applications,
differs from the Linux default one found among statically defined minimal
set of supported modes. Since Xen defines PTE encoding of the WC mode as
_PAGE_PAT, it no longer belongs to the minimal set, depends on correct
handling of _PAGE_PAT bit, and can be mismatched with write-back caching.
When a user calls mmap() for a DRM buffer object, DRM device specific
.mmap file operation, called from mmap_region(), takes care of setting PTE
encoding bits in a vm_page_prot field of an associated virtual memory area
structure. Unfortunately, _PAGE_PAT bit is not preserved when the vma's
.vm_flags are then applied to .vm_page_prot via vm_set_page_prot(). Bits
to be preserved are determined with _PAGE_CHG_MASK symbol that doesn't
cover _PAGE_PAT. As a consequence, WB caching is requested instead of WC
when running under Xen (also, WP is silently changed to WT, and UC
downgraded to UC_MINUS). When running on bare metal, WC is not affected,
but WP and WT extra modes are unintentionally replaced with WC and UC,
respectively.
WP and WT modes, encoded with _PAGE_PAT bit set, were introduced by commit
281d4078bec3 ("x86: Make page cache mode a real type"). Care was taken
to extend _PAGE_CACHE_MASK symbol with that additional bit, but that
symbol has never been used for identification of bits preserved when
applying page protection flags. Support for all cache modes under Xen,
including the problematic WC mode, was then introduced by commit
47591df50512 ("xen: Support Xen pv-domains using PAT").
Extend bitmask used by pgprot_modify() for selecting bits to be preserved
with _PAGE_PAT bit. However, since that bit can be reused as _PAGE_PSE,
and the _PAGE_CHG_MASK symbol, primarly used by pte_modify(), is likely
intentionally defined with that bit not set, keep that symbol unchanged.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/7648
Fixes: 281d4078bec3 ("x86: Make page cache mode a real type")
Signed-off-by: Janusz Krzysztofik
Cc: sta...@vger.kernel.org # v3.19+
---
arch/x86/include/asm/pgtable.h | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h
index 7425f32e52932..f797f8da2e5b6 100644
--- a/arch/x86/include/asm/pgtable.h
+++ b/arch/x86/include/asm/pgtable.h
@@ -654,8 +654,10 @@ static inline pmd_t pmd_modify(pmd_t pmd, pgprot_t newprot)
#define pgprot_modify pgprot_modify
static inline pgprot_t pgprot_modify(pgprot_t oldprot, pgprot_t newprot)
{
- pgprotval_t preservebits = pgprot_val(oldprot) & _PAGE_CHG_MASK;
- pgprotval_t addbits = pgprot_val(newprot) & ~_PAGE_CHG_MASK;
+ unsigned long mask = _PAGE_CHG_MASK | _PAGE_CACHE_MASK;
+
+ pgprotval_t preservebits = pgprot_val(oldprot) & mask;
+ pgprotval_t addbits = pgprot_val(newprot) & ~mask;
return __pgprot(preservebits | addbits);
}
--
2.40.0
Re: [Intel-gfx] [PATCH 05/13] drm/i915/display: Use sink_format instead of ycbcr420_output flag
On Fri, Mar 31, 2023 at 03:46:05PM +0530, Ankit Nautiyal wrote:
> Start passing the sink_format, to all functions that take a bool
> ycbcr420_output as parameter. This will make the functions generic,
> and will serve as a slight step towards 4:2:2 support later.
>
> v2: Rebased.
>
> v3: Correct the checks in places concerned with pipe output. (Ville)
> Other minor styling and refactoring fixes, as suggested by Ville.
>
> Suggested-by: Ville Syrj_l_
Name borked here.
Reviewed-by: Ville Syrjälä
> Signed-off-by: Ankit Nautiyal
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 32 -
> drivers/gpu/drm/i915/display/intel_hdmi.c | 44 ++-
> drivers/gpu/drm/i915/display/intel_hdmi.h | 5 +--
> 3 files changed, 45 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index c3f3003c52ca..ce9384a0d153 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -987,7 +987,8 @@ static int intel_dp_max_tmds_clock(struct intel_dp
> *intel_dp)
>
> static enum drm_mode_status
> intel_dp_tmds_clock_valid(struct intel_dp *intel_dp,
> - int clock, int bpc, bool ycbcr420_output,
> + int clock, int bpc,
> + enum intel_output_format sink_format,
> bool respect_downstream_limits)
> {
> int tmds_clock, min_tmds_clock, max_tmds_clock;
> @@ -995,7 +996,7 @@ intel_dp_tmds_clock_valid(struct intel_dp *intel_dp,
> if (!respect_downstream_limits)
> return MODE_OK;
>
> - tmds_clock = intel_hdmi_tmds_clock(clock, bpc, ycbcr420_output);
> + tmds_clock = intel_hdmi_tmds_clock(clock, bpc, sink_format);
>
> min_tmds_clock = intel_dp->dfp.min_tmds_clock;
> max_tmds_clock = intel_dp_max_tmds_clock(intel_dp);
> @@ -1018,6 +1019,7 @@ intel_dp_mode_valid_downstream(struct intel_connector
> *connector,
> const struct drm_display_info *info = &connector->base.display_info;
> enum drm_mode_status status;
> bool ycbcr_420_only;
> + enum intel_output_format sink_format;
>
> /* If PCON supports FRL MODE, check FRL bandwidth constraints */
> if (intel_dp->dfp.pcon_max_frl_bw) {
> @@ -1044,18 +1046,23 @@ intel_dp_mode_valid_downstream(struct intel_connector
> *connector,
>
> ycbcr_420_only = drm_mode_is_420_only(info, mode);
>
> + if (ycbcr_420_only)
> + sink_format = INTEL_OUTPUT_FORMAT_YCBCR420;
> + else
> + sink_format = INTEL_OUTPUT_FORMAT_RGB;
> +
> /* Assume 8bpc for the DP++/HDMI/DVI TMDS clock check */
> status = intel_dp_tmds_clock_valid(intel_dp, target_clock,
> -8, ycbcr_420_only, true);
> +8, sink_format, true);
>
> if (status != MODE_OK) {
> - if (ycbcr_420_only ||
> + if (sink_format == INTEL_OUTPUT_FORMAT_YCBCR420 ||
> !connector->base.ycbcr_420_allowed ||
> !drm_mode_is_420_also(info, mode))
> return status;
> -
> + sink_format = INTEL_OUTPUT_FORMAT_YCBCR420;
> status = intel_dp_tmds_clock_valid(intel_dp, target_clock,
> -8, true, true);
> +8, sink_format, true);
> if (status != MODE_OK)
> return status;
> }
> @@ -1291,19 +1298,10 @@ static bool intel_dp_supports_dsc(struct intel_dp
> *intel_dp,
> drm_dp_sink_supports_dsc(intel_dp->dsc_dpcd);
> }
>
> -static bool intel_dp_is_ycbcr420(struct intel_dp *intel_dp,
> - const struct intel_crtc_state *crtc_state)
> -{
> - return crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420 ||
> - (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR444 &&
> - intel_dp->dfp.ycbcr_444_to_420);
> -}
> -
> static int intel_dp_hdmi_compute_bpc(struct intel_dp *intel_dp,
>const struct intel_crtc_state *crtc_state,
>int bpc, bool respect_downstream_limits)
> {
> - bool ycbcr420_output = intel_dp_is_ycbcr420(intel_dp, crtc_state);
> int clock = crtc_state->hw.adjusted_mode.crtc_clock;
>
> /*
> @@ -1323,8 +1321,8 @@ static int intel_dp_hdmi_compute_bpc(struct intel_dp
> *intel_dp,
>
> for (; bpc >= 8; bpc -= 2) {
> if (intel_hdmi_bpc_possible(crtc_state, bpc,
> - intel_dp->has_hdmi_sink,
> ycbcr420_output) &&
> - intel_dp_tmds_clock_valid(intel_dp, clock, bpc,
> ycbcr420_output,
> + intel_dp->has_hdmi_sink) &&
> + intel_dp_tmds_clock_valid(intel_dp, clock, bpc,
> crtc_
Re: [Intel-gfx] [PATCH 06/13] drm/i915/dp: Add helper to get sink_format
On Fri, Mar 31, 2023 at 03:46:06PM +0530, Ankit Nautiyal wrote:
> Common function to get the sink format for a given mode for DP.
>
> Signed-off-by: Ankit Nautiyal
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 30 -
> 1 file changed, 15 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index ce9384a0d153..352b5fbd805a 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -936,17 +936,25 @@ static int intel_dp_output_bpp(enum intel_output_format
> output_format, int bpp)
> return bpp;
> }
>
> +static enum intel_output_format
> +intel_dp_sink_format(struct intel_connector *connector,
> + const struct drm_display_mode *mode)
> +{
> + const struct drm_display_info *info = &connector->base.display_info;
> +
> + if (drm_mode_is_420_only(info, mode))
> + return INTEL_OUTPUT_FORMAT_YCBCR420;
> +
> + return INTEL_OUTPUT_FORMAT_RGB;
> +}
> +
> static int
> intel_dp_mode_min_output_bpp(struct intel_connector *connector,
>const struct drm_display_mode *mode)
> {
> - const struct drm_display_info *info = &connector->base.display_info;
> enum intel_output_format output_format, sink_format;
>
> - if (drm_mode_is_420_only(info, mode))
> - sink_format = INTEL_OUTPUT_FORMAT_YCBCR420;
> - else
> - sink_format = INTEL_OUTPUT_FORMAT_RGB;
> + sink_format = intel_dp_sink_format(connector, mode);
>
> output_format = intel_dp_output_format(connector, sink_format);
>
> @@ -1018,7 +1026,6 @@ intel_dp_mode_valid_downstream(struct intel_connector
> *connector,
> struct intel_dp *intel_dp = intel_attached_dp(connector);
> const struct drm_display_info *info = &connector->base.display_info;
> enum drm_mode_status status;
> - bool ycbcr_420_only;
> enum intel_output_format sink_format;
>
> /* If PCON supports FRL MODE, check FRL bandwidth constraints */
> @@ -1044,12 +1051,7 @@ intel_dp_mode_valid_downstream(struct intel_connector
> *connector,
> target_clock > intel_dp->dfp.max_dotclock)
> return MODE_CLOCK_HIGH;
>
> - ycbcr_420_only = drm_mode_is_420_only(info, mode);
> -
> - if (ycbcr_420_only)
> - sink_format = INTEL_OUTPUT_FORMAT_YCBCR420;
> - else
> - sink_format = INTEL_OUTPUT_FORMAT_RGB;
> + sink_format = intel_dp_sink_format(connector, mode);
>
> /* Assume 8bpc for the DP++/HDMI/DVI TMDS clock check */
> status = intel_dp_tmds_clock_valid(intel_dp, target_clock,
> @@ -2127,10 +2129,8 @@ intel_dp_compute_output_format(struct intel_encoder
> *encoder,
> drm_dbg_kms(&i915->drm,
> "YCbCr 4:2:0 mode but YCbCr 4:2:0 output not
> possible. Falling back to RGB.\n");
> crtc_state->sink_format = INTEL_OUTPUT_FORMAT_RGB;
> - } else if (ycbcr_420_only) {
> - crtc_state->sink_format = INTEL_OUTPUT_FORMAT_YCBCR420;
> } else {
> - crtc_state->sink_format = INTEL_OUTPUT_FORMAT_RGB;
> + crtc_state->sink_format = intel_dp_sink_format(connector,
> adjusted_mode);
> }
>
> crtc_state->output_format = intel_dp_output_format(connector,
> crtc_state->sink_format);
> --
> 2.25.1
--
Ville Syrjälä
Intel
Re: [Intel-gfx] [PATCH 02/13] drm/i915/display: Add new member in intel_dp to store ycbcr420 passthrough cap
On Fri, Mar 31, 2023 at 03:46:02PM +0530, Ankit Nautiyal wrote:
> New member to store the YCBCR20 Pass through capability of the DP sink.
>
> Signed-off-by: Ankit Nautiyal
> ---
> drivers/gpu/drm/i915/display/intel_display_types.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index b1ade7e40f37..fd1eca5addaa 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -1742,6 +1742,7 @@ struct intel_dp {
> int pcon_max_frl_bw;
> u8 max_bpc;
> bool ycbcr_444_to_420;
> + bool ycbcr420_passthrough;
> bool rgb_to_ycbcr;
> } dfp;
I would just squash this into the next patch where it actually gets
used.
>
> --
> 2.25.1
--
Ville Syrjälä
Intel
Re: [Intel-gfx] [PATCH 08/13] drm/i915/dp: Consider output_format while computing dsc bpp
On Fri, Mar 31, 2023 at 03:46:08PM +0530, Ankit Nautiyal wrote:
> While using DSC the compressed bpp is computed assuming RGB output
> format. Consider the output_format and compute the compressed bpp
> during mode valid and compute config steps.
>
> For DP-MST we currently use RGB output format only, so continue
> using RGB while computing compressed bpp for MST case.
>
> Signed-off-by: Ankit Nautiyal
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 14 +-
> drivers/gpu/drm/i915/display/intel_dp.h | 1 +
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 1 +
> 3 files changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 4d5c74a1bd29..e5903b5e511b 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -712,6 +712,7 @@ u16 intel_dp_dsc_get_output_bpp(struct drm_i915_private
> *i915,
> u32 link_clock, u32 lane_count,
> u32 mode_clock, u32 mode_hdisplay,
> bool bigjoiner,
> + enum intel_output_format output_format,
> u32 pipe_bpp,
> u32 timeslots)
> {
> @@ -736,6 +737,10 @@ u16 intel_dp_dsc_get_output_bpp(struct drm_i915_private
> *i915,
> bits_per_pixel = ((link_clock * lane_count) * timeslots) /
>(intel_dp_mode_to_fec_clock(mode_clock) * 8);
>
> + /* Bandwidth required for 420 is half, that of 444 format */
> + if (output_format == INTEL_OUTPUT_FORMAT_YCBCR420)
> + bits_per_pixel *= 2;
/2 ?
> +
> drm_dbg_kms(&i915->drm, "Max link bpp is %u for %u timeslots "
> "total bw %u pixel clock %u\n",
> bits_per_pixel, timeslots,
> @@ -1133,11 +1138,16 @@ intel_dp_mode_valid(struct drm_connector *_connector,
>
> if (HAS_DSC(dev_priv) &&
> drm_dp_sink_supports_dsc(intel_dp->dsc_dpcd)) {
> + enum intel_output_format sink_format, output_format;
> + int pipe_bpp;
> +
> + sink_format = intel_dp_sink_format(connector, mode);
> + output_format = intel_dp_output_format(connector, sink_format);
> /*
>* TBD pass the connector BPC,
>* for now U8_MAX so that max BPC on that platform would be
> picked
>*/
> - int pipe_bpp = intel_dp_dsc_compute_bpp(intel_dp, U8_MAX);
> + pipe_bpp = intel_dp_dsc_compute_bpp(intel_dp, U8_MAX);
>
> /*
>* Output bpp is stored in 6.4 format so right shift by 4 to
> get the
> @@ -1157,6 +1167,7 @@ intel_dp_mode_valid(struct drm_connector *_connector,
> target_clock,
> mode->hdisplay,
> bigjoiner,
> + output_format,
> pipe_bpp, 64) >> 4;
> dsc_slice_count =
> intel_dp_dsc_get_slice_count(intel_dp,
> @@ -1655,6 +1666,7 @@ int intel_dp_dsc_compute_config(struct intel_dp
> *intel_dp,
>
> adjusted_mode->crtc_clock,
>
> adjusted_mode->crtc_hdisplay,
>
> pipe_config->bigjoiner_pipes,
> +
> pipe_config->output_format,
> pipe_bpp,
> timeslots);
> if (!dsc_max_output_bpp) {
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.h
> b/drivers/gpu/drm/i915/display/intel_dp.h
> index ef39e4f7a329..db86c2b71c1f 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.h
> +++ b/drivers/gpu/drm/i915/display/intel_dp.h
> @@ -107,6 +107,7 @@ u16 intel_dp_dsc_get_output_bpp(struct drm_i915_private
> *i915,
> u32 link_clock, u32 lane_count,
> u32 mode_clock, u32 mode_hdisplay,
> bool bigjoiner,
> + enum intel_output_format output_format,
> u32 pipe_bpp,
> u32 timeslots);
> u8 intel_dp_dsc_get_slice_count(struct intel_dp *intel_dp,
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index 2cc4239cfa5b..daa1591a9ae8 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -927,6 +927,7 @
Re: [Intel-gfx] [PATCH 09/13] drm/i915/dp_mst: Use output_format to get the final link bpp
On Fri, Mar 31, 2023 at 03:46:09PM +0530, Ankit Nautiyal wrote:
> The final link bpp used to calculate the m_n values depend on the
> output_format. Though the output_format is set to RGB for MST case and
> the link bpp will be same as the pipe bpp, for the sake of semantics,
> lets calculate the m_n values with the link bpp, instead of pipe_bpp.
>
> Signed-off-by: Ankit Nautiyal
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 2 +-
> drivers/gpu/drm/i915/display/intel_dp.h | 1 +
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 5 -
> 3 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index e5903b5e511b..8d819b2963de 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -928,7 +928,7 @@ int intel_dp_min_bpp(enum intel_output_format
> output_format)
> return 8 * 3;
> }
>
> -static int intel_dp_output_bpp(enum intel_output_format output_format, int
> bpp)
> +int intel_dp_output_bpp(enum intel_output_format output_format, int bpp)
> {
> /*
>* bpp value was assumed to RGB format. And YCbCr 4:2:0 output
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.h
> b/drivers/gpu/drm/i915/display/intel_dp.h
> index db86c2b71c1f..856172bfa13e 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.h
> +++ b/drivers/gpu/drm/i915/display/intel_dp.h
> @@ -140,5 +140,6 @@ void intel_dp_pcon_dsc_configure(struct intel_dp
> *intel_dp,
> void intel_dp_phy_test(struct intel_encoder *encoder);
>
> void intel_dp_wait_source_oui(struct intel_dp *intel_dp);
> +int intel_dp_output_bpp(enum intel_output_format output_format, int bpp);
>
> #endif /* __INTEL_DP_H__ */
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index daa1591a9ae8..fec3f310fc9b 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -130,6 +130,7 @@ static int intel_dp_mst_compute_link_config(struct
> intel_encoder *encoder,
> const struct drm_display_mode *adjusted_mode =
> &crtc_state->hw.adjusted_mode;
> int slots = -EINVAL;
> + int link_bpp;
>
> slots = intel_dp_mst_find_vcpi_slots_for_bpp(encoder, crtc_state,
> limits->max_bpp,
>limits->min_bpp, limits,
> @@ -138,7 +139,9 @@ static int intel_dp_mst_compute_link_config(struct
> intel_encoder *encoder,
> if (slots < 0)
> return slots;
>
> - intel_link_compute_m_n(crtc_state->pipe_bpp,
> + link_bpp = intel_dp_output_bpp(crtc_state->output_format,
> crtc_state->pipe_bpp);
> +
> + intel_link_compute_m_n(link_bpp,
> crtc_state->lane_count,
> adjusted_mode->crtc_clock,
> crtc_state->port_clock,
> --
> 2.25.1
--
Ville Syrjälä
Intel
Re: [Intel-gfx] [PATCH 13/13] drm/i915/dp: Use consistent name for link bpp and compressed bpp
On Fri, Mar 31, 2023 at 03:46:13PM +0530, Ankit Nautiyal wrote:
> Currently there are many places where we use output_bpp for link bpp and
> compressed bpp.
> Lets use consistent naming:
> output_bpp : The intermediate value taking into account the
> output_format chroma subsampling.
> compressed_bpp : target bpp for the DSC encoder.
> link_bpp : final bpp used in the link.
>
> For 444 sampling without DSC:
> link_bpp = output_bpp = pipe_bpp
>
> For 420 sampling without DSC:
> output_bpp = pipe_bpp / 2
> link_bpp = output_bpp
>
> For 444 sampling with DSC:
> output_bpp = pipe_bpp
> link_bpp = compressed_bpp, computed with output_bpp (i.e. pipe_bpp in
> this case)
>
> For 420 sampling with DSC:
> output_bpp = pipe_bpp/2
> link_bpp = compressed_bpp, computed with output_bpp
>
> Signed-off-by: Ankit Nautiyal
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 84 ++---
> drivers/gpu/drm/i915/display/intel_dp.h | 14 ++--
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 22 +++---
> 3 files changed, 60 insertions(+), 60 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 63f3f6ff2cad..22b98653d539 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -710,13 +710,13 @@ u32 intel_dp_dsc_nearest_valid_bpp(struct
> drm_i915_private *i915, u32 bpp, u32 p
> return bits_per_pixel;
> }
>
> -u16 intel_dp_dsc_get_output_bpp(struct drm_i915_private *i915,
> - u32 link_clock, u32 lane_count,
> - u32 mode_clock, u32 mode_hdisplay,
> - bool bigjoiner,
> - enum intel_output_format output_format,
> - u32 pipe_bpp,
> - u32 timeslots)
> +u16 intel_dp_dsc_get_max_compressed_bpp(struct drm_i915_private *i915,
> + u32 link_clock, u32 lane_count,
> + u32 mode_clock, u32 mode_hdisplay,
> + bool bigjoiner,
> + enum intel_output_format output_format,
> + u32 pipe_bpp,
> + u32 timeslots)
> {
> u32 bits_per_pixel, max_bpp_small_joiner_ram;
>
> @@ -1118,7 +1118,7 @@ intel_dp_mode_valid(struct drm_connector *_connector,
> int target_clock = mode->clock;
> int max_rate, mode_rate, max_lanes, max_link_clock;
> int max_dotclk = dev_priv->max_dotclk_freq;
> - u16 dsc_max_output_bpp = 0;
> + u16 dsc_max_compressed_bpp = 0;
> u8 dsc_slice_count = 0;
> enum drm_mode_status status;
> bool dsc = false, bigjoiner = false;
> @@ -1173,21 +1173,21 @@ intel_dp_mode_valid(struct drm_connector *_connector,
>* integer value since we support only integer values of bpp.
>*/
> if (intel_dp_is_edp(intel_dp)) {
> - dsc_max_output_bpp =
> + dsc_max_compressed_bpp =
> drm_edp_dsc_sink_output_bpp(intel_dp->dsc_dpcd)
> >> 4;
Renaming that as well would be nice, as a separate patch.
> dsc_slice_count =
>
> drm_dp_dsc_sink_max_slice_count(intel_dp->dsc_dpcd,
> true);
> } else if (drm_dp_sink_supports_fec(intel_dp->fec_capable)) {
> - dsc_max_output_bpp =
> - intel_dp_dsc_get_output_bpp(dev_priv,
> - max_link_clock,
> - max_lanes,
> - target_clock,
> - mode->hdisplay,
> - bigjoiner,
> - output_format,
> - pipe_bpp, 64) >> 4;
> + dsc_max_compressed_bpp =
> + intel_dp_dsc_get_max_compressed_bpp(dev_priv,
> +
> max_link_clock,
> + max_lanes,
> +
> target_clock,
> +
> mode->hdisplay,
> + bigjoiner,
> +
> output_format,
> + pipe_bpp,
> 64) >> 4;
> dsc_slice_count =
>
Re: [Intel-gfx] [PATCH 00/13] Handle BPC for HDMI2.1 PCON without DSC1.2 sink and other fixes
On Fri, Mar 31, 2023 at 03:46:00PM +0530, Ankit Nautiyal wrote: > This series fixes issues faced when an HDMI2.1 sink that does not > support DSC is connected via HDMI2.1PCON. It also includes other minor > HDMI2.1 PCON fixes/refactoring. > > Patch 1-2 Have minor fixes/cleanups. > Patch 3-6 Pull the decision making to use DFP conversion capabilities > for every mode during compute config, instead of having that decision > during DP initializing phase. > Patch 7-8 Calculate the max BPC that can be sufficient with either > RGB or YCbcr420 format for the maximum FRL rate supported. > > Rev2: Split the refactoring of DFP RG->YCBCR conversion into smaller > patches, as suggested by Jani N. > Also dropped the unnecessary helper for DSC1.2 support for HDMI2.1 DFP. > > Rev3: As suggested by Ville, added new member sink_format to store the > final format that the sink will be using, which might be different > than the output format, and thus might need color/format conversion > performed by the PCON. > > Rev4: Fix typo in switch case as, reported by kernel test bot. > > Rev5: Corrected order of setting sink_format and output_format. (Ville) > Avoided the flag ycbcr420_output and used the sink_format to facilitate > 4:2:2 support at a later stage. (Ville) > > Rev6: Added missing changes for sdvo. (Ville) > Added check for scaler and DSC constraints with YCbCr420. > > Rev7: Split change to add scaler constraint in separate patch, and rebased. > > Rev8: Rebased. Fixed check for mode rate with dsc in modevalid. > Fixed scaler constraint as per display version. > > Rev9: Rebased. > > Rev10: Addressed review comments from Ville. > Dropped patch to check for mode rate with dsc during modevalid, as the > compressed bpp is already selected with bandwidth considerations. > > Rev11: Fixed the policy to use output format as RGB first if possible, > followed by YCbCr444, atlast YCbCr420. Also removed the scaler-constraints > with YCbCr420, as these are handled in scaler code. (Ville) > > Rev12: Added a patch for configuring PCON to convert output_format to > YCBCR444. Added patch to have consistent naming for link bpp and > compressed bpp. > > Ankit Nautiyal (13): > drm/i915/display: Add new member to configure PCON color conversion > drm/i915/display: Add new member in intel_dp to store ycbcr420 > passthrough cap > drm/i915/dp: Replace intel_dp.dfp members with the new crtc_state > sink_format > drm/i915/dp: Configure PCON for conversion of output_format to > YCbCr444 > drm/i915/display: Use sink_format instead of ycbcr420_output flag > drm/i915/dp: Add helper to get sink_format > drm/i915/dp: Rearrange check for illegal mode and comments in > mode_valid Apart from a few minor nits that set looks pretty much ready to go in. Maybe rebase and submit just those so we can push them? The rest might still need some tweaking, and I probably need to refresh mymemory on the FRL stuff before I look at those. > drm/i915/dp: Consider output_format while computing dsc bpp > drm/i915/dp_mst: Use output_format to get the final link bpp > drm/i915/dp: Handle BPP where HDMI2.1 DFP doesn't support DSC > drm/i915/dp: Fix FRL BW check for HDMI2.1 DFP > drm/i915/dp: Add a wrapper to check frl/tmds downstream constraints > drm/i915/dp: Use consistent name for link bpp and compressed bpp > > drivers/gpu/drm/i915/display/icl_dsi.c| 1 + > drivers/gpu/drm/i915/display/intel_crt.c | 1 + > .../drm/i915/display/intel_crtc_state_dump.c | 5 +- > drivers/gpu/drm/i915/display/intel_display.c | 5 + > .../drm/i915/display/intel_display_types.h| 12 +- > drivers/gpu/drm/i915/display/intel_dp.c | 494 -- > drivers/gpu/drm/i915/display/intel_dp.h | 14 +- > drivers/gpu/drm/i915/display/intel_dp_mst.c | 27 +- > drivers/gpu/drm/i915/display/intel_dvo.c | 1 + > drivers/gpu/drm/i915/display/intel_hdmi.c | 71 ++- > drivers/gpu/drm/i915/display/intel_hdmi.h | 5 +- > drivers/gpu/drm/i915/display/intel_lvds.c | 1 + > drivers/gpu/drm/i915/display/intel_sdvo.c | 1 + > drivers/gpu/drm/i915/display/intel_tv.c | 1 + > drivers/gpu/drm/i915/display/vlv_dsi.c| 1 + > 15 files changed, 437 insertions(+), 203 deletions(-) > > -- > 2.25.1 -- Ville Syrjälä Intel
Re: [Intel-gfx] [RFC PATCH] x86/mm: Fix PAT bit missing from page protection modify mask
On 24.04.23 14:35, Janusz Krzysztofik wrote:
Visible glitches have been observed when running graphics applications on
Linux under Xen hypervisor. Those observations have been confirmed with
failures from kms_pwrite_crc Intel GPU test that verifies data coherency
of DRM frame buffer objects using hardware CRC checksums calculated by
display controllers, exposed to userspace via debugfs. Affected
processing paths have then been identified with new test variants that
mmap the objects using different methods and caching modes.
When running as a Xen PV guest, Linux uses Xen provided PAT configuration
which is different from its native one. In particular, Xen specific PTE
encoding of write-combining caching, likely used by graphics applications,
differs from the Linux default one found among statically defined minimal
set of supported modes. Since Xen defines PTE encoding of the WC mode as
_PAGE_PAT, it no longer belongs to the minimal set, depends on correct
handling of _PAGE_PAT bit, and can be mismatched with write-back caching.
When a user calls mmap() for a DRM buffer object, DRM device specific
.mmap file operation, called from mmap_region(), takes care of setting PTE
encoding bits in a vm_page_prot field of an associated virtual memory area
structure. Unfortunately, _PAGE_PAT bit is not preserved when the vma's
.vm_flags are then applied to .vm_page_prot via vm_set_page_prot(). Bits
to be preserved are determined with _PAGE_CHG_MASK symbol that doesn't
cover _PAGE_PAT. As a consequence, WB caching is requested instead of WC
when running under Xen (also, WP is silently changed to WT, and UC
downgraded to UC_MINUS). When running on bare metal, WC is not affected,
but WP and WT extra modes are unintentionally replaced with WC and UC,
respectively.
WP and WT modes, encoded with _PAGE_PAT bit set, were introduced by commit
281d4078bec3 ("x86: Make page cache mode a real type"). Care was taken
to extend _PAGE_CACHE_MASK symbol with that additional bit, but that
symbol has never been used for identification of bits preserved when
applying page protection flags. Support for all cache modes under Xen,
including the problematic WC mode, was then introduced by commit
47591df50512 ("xen: Support Xen pv-domains using PAT").
Extend bitmask used by pgprot_modify() for selecting bits to be preserved
with _PAGE_PAT bit. However, since that bit can be reused as _PAGE_PSE,
and the _PAGE_CHG_MASK symbol, primarly used by pte_modify(), is likely
intentionally defined with that bit not set, keep that symbol unchanged.
Hmm, I wonder whether pte_mkhuge() shouldn't just set _PAGE_PSE, but use
pgprot_4k_2_large() before doing so.
OTOH a use case like in remove_migration_pte(), where pte_mkhuge() is
directly followed by a call of arch_make_huge_pte(), which in turn is
calling pte_mkhuge() again, would set _always_ the PAT bit.
When running as a Xen PV guest this doesn't matter at all, as large or
huge pages aren't supported there. So clearly something for the MM
maintainers. :-)
Juergen
P.S.: Janusz, nice catch! The QubesOS folks who reported the problem
originally will test your patch under Xen soon.
OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
[Intel-gfx] [PATCH] drm/i915/selftest: Record GT error for gt failure
igt_live_test has pr_err dumped in case of some
GT failures. It will be more informative regarding
GT if we use gt_err instead.
Cc: Andi Shyti
Signed-off-by: Tejas Upadhyay
---
drivers/gpu/drm/i915/selftests/igt_live_test.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/selftests/igt_live_test.c
b/drivers/gpu/drm/i915/selftests/igt_live_test.c
index 714b7afc490b..4ddc6d902752 100644
--- a/drivers/gpu/drm/i915/selftests/igt_live_test.c
+++ b/drivers/gpu/drm/i915/selftests/igt_live_test.c
@@ -6,6 +6,7 @@
#include "i915_drv.h"
#include "gt/intel_gt.h"
+#include "gt/intel_gt_print.h"
#include "../i915_selftest.h"
#include "igt_flush_test.h"
@@ -30,7 +31,7 @@ int igt_live_test_begin(struct igt_live_test *t,
err = intel_gt_wait_for_idle(gt, MAX_SCHEDULE_TIMEOUT);
if (err) {
- pr_err("%s(%s): failed to idle before, with err=%d!",
+ gt_err(gt, "%s(%s): GT failed to idle before, with
err=%d!",
func, name, err);
return err;
}
@@ -69,7 +70,7 @@ int igt_live_test_end(struct igt_live_test *t)
i915_reset_engine_count(&i915->gpu_error, engine))
continue;
- pr_err("%s(%s): engine '%s' was reset %d times!\n",
+ gt_err(gt, "%s(%s): engine '%s' was reset %d times!\n",
t->func, t->name, engine->name,
i915_reset_engine_count(&i915->gpu_error,
engine) -
t->reset_engine[id]);
--
2.25.1
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/mtl: workaround coherency issue for Media (rev4)
== Series Details ==
Series: drm/i915/mtl: workaround coherency issue for Media (rev4)
URL : https://patchwork.freedesktop.org/series/116751/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13053 -> Patchwork_116751v4
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116751v4/index.html
Participating hosts (38 -> 37)
--
Additional (1): bat-mtlp-8
Missing(2): fi-kbl-soraka fi-snb-2520m
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_116751v4:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_module_load@load:
- {bat-mtlp-8}: NOTRUN -> [ABORT][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116751v4/bat-mtlp-8/igt@i915_module_l...@load.html
Known issues
Here are the changes found in Patchwork_116751v4 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@gt_lrc:
- bat-adln-1: [PASS][2] -> [INCOMPLETE][3] ([i915#4983] /
[i915#7609])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13053/bat-adln-1/igt@i915_selftest@live@gt_lrc.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116751v4/bat-adln-1/igt@i915_selftest@live@gt_lrc.html
* igt@i915_selftest@live@reset:
- bat-rpls-1: [PASS][4] -> [ABORT][5] ([i915#4983] / [i915#8384])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13053/bat-rpls-1/igt@i915_selftest@l...@reset.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116751v4/bat-rpls-1/igt@i915_selftest@l...@reset.html
Possible fixes
* igt@i915_selftest@live@migrate:
- bat-adlp-9: [DMESG-FAIL][6] ([i915#7699]) -> [PASS][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13053/bat-adlp-9/igt@i915_selftest@l...@migrate.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116751v4/bat-adlp-9/igt@i915_selftest@l...@migrate.html
* igt@kms_pipe_crc_basic@suspend-read-crc@pipe-b-hdmi-a-1:
- fi-rkl-11600: [FAIL][8] ([fdo#103375]) -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13053/fi-rkl-11600/igt@kms_pipe_crc_basic@suspend-read-...@pipe-b-hdmi-a-1.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116751v4/fi-rkl-11600/igt@kms_pipe_crc_basic@suspend-read-...@pipe-b-hdmi-a-1.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#7609]: https://gitlab.freedesktop.org/drm/intel/issues/7609
[i915#7699]: https://gitlab.freedesktop.org/drm/intel/issues/7699
[i915#8384]: https://gitlab.freedesktop.org/drm/intel/issues/8384
Build changes
-
* Linux: CI_DRM_13053 -> Patchwork_116751v4
CI-20190529: 20190529
CI_DRM_13053: 63a6d68541b38408d5be8345f3e4a561661f68cb @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7266: 94411dd85f9ad6d76fb7b2097197122703a3914c @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_116751v4: 63a6d68541b38408d5be8345f3e4a561661f68cb @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
86368a176c5f drm/i915/mtl: workaround coherency issue for Media
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116751v4/index.html
Re: [Intel-gfx] [PATCH 0/2] Use i915 instead of dev_priv
Hi Jani, > >> just another "Friday patch". While reviewing some patches from > >> Tejas I found a bit confusing the use of dev_priv__ inside the > >> for_each_engine(), perhaps it should be moved inside the gt/? > >> > >> As I was at it I made the /dev_priv/i915/ change which is still > >> harmless. Next in queue is to change the i915_irq.h, which is a > >> bit tricky (but not much) as the "dev_priv" is hardcoded inside > >> some defines. > >> > >> Andi > >> > >> Andi Shyti (2): > >> drm/i915/i915_drv: Use proper parameter naming in for_each_gt() > >> drm/i915/i915_drv: Use i915 instead of dev_priv insied the file_priv > >> structure > >> > >> drivers/gpu/drm/i915/i915_drv.h | 462 > >> 1 file changed, 231 insertions(+), 231 deletions(-) > > > > Pushed to dmr-intel-gt-next. > > That's going to create problems for us for weeks to come. I'm actually > tempted to ask Joonas or Tvrtko to just force push that out of there. > > Only use drm-intel-gt-next for stuff that's specifically about gt or > gem, and touches files used by gt or gem only. For everything else, use > drm-intel-next. When in doubt, err on the side of drm-intel-next. sorry, I did think of it. But... > It's not enough that one of the patches changes parameters of > for_each_gt() macro. ... I was fooled by the gt/i915 parameter. Thanks and sorry, Andi > We can cross-merge drm-intel-next to drm-intel-gt-next, but we can't > cross-merge drm-intel-gt-next to drm-intel-next. This means the only way > to sync those i915_drv.h changes to drm-intel-next is to have a > drm-intel-gt-next pull request merged to drm-next, and then backmerged > to drm-intel-next. That's not going to happen for several weeks. > > Any change aimed at drm-intel-next that conflicts with the i915_drv.h > changes will now be pending on those merges.
Re: [Intel-gfx] [RFC PATCH] x86/mm: Fix PAT bit missing from page protection modify mask
On Mon, Apr 24, 2023 at 02:35:24PM +0200, Janusz Krzysztofik wrote:
> Visible glitches have been observed when running graphics applications on
> Linux under Xen hypervisor. Those observations have been confirmed with
> failures from kms_pwrite_crc Intel GPU test that verifies data coherency
> of DRM frame buffer objects using hardware CRC checksums calculated by
> display controllers, exposed to userspace via debugfs. Affected
> processing paths have then been identified with new test variants that
> mmap the objects using different methods and caching modes.
>
> When running as a Xen PV guest, Linux uses Xen provided PAT configuration
> which is different from its native one. In particular, Xen specific PTE
> encoding of write-combining caching, likely used by graphics applications,
> differs from the Linux default one found among statically defined minimal
> set of supported modes. Since Xen defines PTE encoding of the WC mode as
> _PAGE_PAT, it no longer belongs to the minimal set, depends on correct
> handling of _PAGE_PAT bit, and can be mismatched with write-back caching.
>
> When a user calls mmap() for a DRM buffer object, DRM device specific
> .mmap file operation, called from mmap_region(), takes care of setting PTE
> encoding bits in a vm_page_prot field of an associated virtual memory area
> structure. Unfortunately, _PAGE_PAT bit is not preserved when the vma's
> .vm_flags are then applied to .vm_page_prot via vm_set_page_prot(). Bits
> to be preserved are determined with _PAGE_CHG_MASK symbol that doesn't
> cover _PAGE_PAT. As a consequence, WB caching is requested instead of WC
> when running under Xen (also, WP is silently changed to WT, and UC
> downgraded to UC_MINUS). When running on bare metal, WC is not affected,
> but WP and WT extra modes are unintentionally replaced with WC and UC,
> respectively.
>
> WP and WT modes, encoded with _PAGE_PAT bit set, were introduced by commit
> 281d4078bec3 ("x86: Make page cache mode a real type"). Care was taken
> to extend _PAGE_CACHE_MASK symbol with that additional bit, but that
> symbol has never been used for identification of bits preserved when
> applying page protection flags. Support for all cache modes under Xen,
> including the problematic WC mode, was then introduced by commit
> 47591df50512 ("xen: Support Xen pv-domains using PAT").
>
> Extend bitmask used by pgprot_modify() for selecting bits to be preserved
> with _PAGE_PAT bit. However, since that bit can be reused as _PAGE_PSE,
> and the _PAGE_CHG_MASK symbol, primarly used by pte_modify(), is likely
> intentionally defined with that bit not set, keep that symbol unchanged.
>
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/7648
> Fixes: 281d4078bec3 ("x86: Make page cache mode a real type")
> Signed-off-by: Janusz Krzysztofik
> Cc: sta...@vger.kernel.org # v3.19+
I can confirm it fixes the issue, thanks!
Tested-by: Marek Marczykowski-Górecki
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
signature.asc
Description: PGP signature
Re: [Intel-gfx] [RESEND PATCHv2] drm/i915/display/dp: 128/132b LT requirement
On Wed, Apr 19, 2023 at 10:07:46AM +, Murthy, Arun R wrote:
> > -Original Message-
> > From: Nikula, Jani
> > Sent: Wednesday, April 19, 2023 3:26 PM
> > To: Murthy, Arun R ; intel-
> > g...@lists.freedesktop.org
> > Cc: ville.syrj...@linux.intel.com
> > Subject: RE: [RESEND PATCHv2] drm/i915/display/dp: 128/132b LT
> > requirement
> >
> > On Wed, 19 Apr 2023, "Murthy, Arun R" wrote:
> > >> -Original Message-
> > >> From: Nikula, Jani
> > >> Sent: Wednesday, April 19, 2023 12:48 PM
> > >> To: Murthy, Arun R ; intel-
> > >> g...@lists.freedesktop.org
> > >> Cc: Murthy, Arun R
> > >> Subject: Re: [RESEND PATCHv2] drm/i915/display/dp: 128/132b LT
> > >> requirement
> > >>
> > >> On Wed, 19 Apr 2023, Arun R Murthy wrote:
> > >> > For 128b/132b LT prior to LT DPTX should set power state, DP
> > >> > channel coding and then link rate.
> > >> >
> > >> > v2: added separate function to avoid code duplication(Jani N)
> > >> >
> > >> > Signed-off-by: Arun R Murthy
> > >>
> > >> RESEND for what reason?
> > > Typo is sending V2 patch hence corrected and sent it again.
> > >
> > >>
> > >> Two v2 and neither fixes
> > >> https://lore.kernel.org/r/87o7nmergw@intel.com
> > > This is pointing to the v1 patch.
> > > V2 patch addressing review comments can be located @
> > > https://lore.kernel.org/all/20230419022522.3457924-1-arun.r.murthy@int
> > > el.com/
> >
> > Argh.
> >
> > RESEND means you're sending the exact same patch again. Hence *re-send*.
> > That's what I thought. That's what everyone would think.
> >
> > It's even documented in submitting-patches.rst [1].
> >
> > ---
> >
> > There's still the question of whether we could just change the order for
> > 8b/10b too [2]. On IRC, Ville thinks we could, "i don't think there is any
> > order
> > specified. just use the same alwas imo".
> >
> Spec DP2.1 section 3.5.1.2 (for 8b/10b LT)
> write the following Link Configuration parameters:
> * LINK_BW_SET register (DPCD 00100h)
> * LANE_COUNT_SET field in the LANE_COUNT_SET register (DPCD 00101h[4:0])
> * DOWNSPREAD_CTRL register (DPCD 00107h)
> * MAIN_LINK_CHANNEL_CODING_SET register (DPCD 00108h)
Looks like an unordered list to me
>
> Whereas for 128b/132b section 3.5.2.16 says
> Prior to link training, a DPTX should perform the following:
> 1 Verify that the SET_POWER_STATE field in the
> SET_POWER_AND_SET_DP_PWR_VOLTAGE register is programmed to D0 normal
> operation (DPCD 00600h[2:0] = 001b).
> 2 Write DPCD 00108h = 02h to select 128b/132b DP channel coding.
> 3 Program the target link rate and lane count by way of an AUX write
> transaction to
> DPCD 00100h and 00101h, respectively
whereas this is an ordered list.
>
>
> Thanks and Regards,
> Arun R Murthy
> ---
> >
> > BR,
> > Jani.
> >
> >
> > [1] https://docs.kernel.org/process/submitting-patches.html#don-t-get-
> > discouraged-or-impatient
> > [2] https://lore.kernel.org/r/87r0siernf@intel.com
> >
> >
> >
> >
> >
> >
> > >
> > > Thanks and Regards,
> > > Arun R Murthy
> > >
> > >>
> > >> BR,
> > >> Jani.
> > >>
> > >>
> > >> > ---
> > >> > .../drm/i915/display/intel_dp_link_training.c | 62
> > >> > +--
> > >> > 1 file changed, 44 insertions(+), 18 deletions(-)
> > >> >
> > >> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > >> > b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > >> > index 6aa4ae5e7ebe..e5809cf7d0c4 100644
> > >> > --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > >> > +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > >> > @@ -637,6 +637,37 @@ static bool
> > >> intel_dp_link_max_vswing_reached(struct intel_dp *intel_dp,
> > >> > return true;
> > >> > }
> > >> >
> > >> > +static void
> > >> > +intel_dp_update_downspread_ctrl(struct intel_dp *intel_dp,
> > >> > + const struct intel_crtc_state *crtc_state)
> > >> > {
> > >> > + u8 link_config[2];
> > >> > +
> > >> > + link_config[0] = crtc_state->vrr.flipline ?
> > >> DP_MSA_TIMING_PAR_IGNORE_EN : 0;
> > >> > + link_config[1] = intel_dp_is_uhbr(crtc_state) ?
> > >> > +DP_SET_ANSI_128B132B : DP_SET_ANSI_8B10B;
> > >> > + drm_dp_dpcd_write(&intel_dp->aux, DP_DOWNSPREAD_CTRL,
> > >> link_config,
> > >> > +2); }
> > >> > +
> > >> > +static void
> > >> > +intel_dp_update_link_bw_set(struct intel_dp *intel_dp,
> > >> > + const struct intel_crtc_state *crtc_state,
> > >> > + u8 link_bw, u8 rate_select) {
> > >> > + u8 link_config[2];
> > >> > +
> > >> > + /* Write the link configuration data */
> > >> > + link_config[0] = link_bw;
> > >> > + link_config[1] = crtc_state->lane_count;
> > >> > + if (drm_dp_enhanced_frame_cap(intel_dp->dpcd))
> > >> > + link_config[1] |= DP_LANE_COUNT_ENHANCED_FRAME_EN;
> > >> > + drm_dp_dpcd_write(&intel_dp->aux, DP_LINK_BW_SET, link_config,
> > >> 2);
> > >> > + /* eDP 1.4 rate
[Intel-gfx] [PATCH 1/2] Revert "drm/i915/mtl: fix mocs selftest"
This reverts commit faca6aaa4838c3c234caa619d3c7d1f09da0d303.
This patch, in series with the next "Define MOCS and PAT tables
for MTL" are causing boot failures for MTL.
Revert them both.
Signed-off-by: Andi Shyti
Cc: Fei Yang
Cc: Matt Roper
---
drivers/gpu/drm/i915/gt/selftest_mocs.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_mocs.c
b/drivers/gpu/drm/i915/gt/selftest_mocs.c
index a8446ab825012..ca009a6a13bdb 100644
--- a/drivers/gpu/drm/i915/gt/selftest_mocs.c
+++ b/drivers/gpu/drm/i915/gt/selftest_mocs.c
@@ -131,14 +131,13 @@ static int read_mocs_table(struct i915_request *rq,
const struct drm_i915_mocs_table *table,
u32 *offset)
{
- struct intel_gt *gt = rq->engine->gt;
u32 addr;
if (!table)
return 0;
if (HAS_GLOBAL_MOCS_REGISTERS(rq->engine->i915))
- addr = global_mocs_offset() + gt->uncore->gsi_offset;
+ addr = global_mocs_offset();
else
addr = mocs_offset(rq->engine);
--
2.40.0
[Intel-gfx] [PATCH 0/2] Restore MTL boot
Hi, The two patches reverted in this series are, together, preventing MTL from booting. Revert them until the fix is deployed. Andi Andi Shyti (2): Revert "drm/i915/mtl: fix mocs selftest" Revert "drm/i915/mtl: Define MOCS and PAT tables for MTL" drivers/gpu/drm/i915/gt/intel_gt_regs.h | 6 +-- drivers/gpu/drm/i915/gt/intel_gtt.c | 47 + drivers/gpu/drm/i915/gt/intel_gtt.h | 8 --- drivers/gpu/drm/i915/gt/intel_mocs.c| 70 + drivers/gpu/drm/i915/gt/selftest_mocs.c | 3 +- 5 files changed, 4 insertions(+), 130 deletions(-) -- 2.40.0
[Intel-gfx] [PATCH 2/2] Revert "drm/i915/mtl: Define MOCS and PAT tables for MTL"
This reverts commit b76c0deef6273609c02ed5053209f6397cd1b0fb.
This patch is causing boot failures for MTL.
Revert it.
Signed-off-by: Andi Shyti
Cc: Matt Roper
Cc: Lucas De Marchi
Cc: Aravind Iddamsetty
Cc: Nirmoy Das
Cc: Fei Yang
Cc: Andrzej Hajda
---
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 6 +--
drivers/gpu/drm/i915/gt/intel_gtt.c | 47 +
drivers/gpu/drm/i915/gt/intel_gtt.h | 8 ---
drivers/gpu/drm/i915/gt/intel_mocs.c| 70 +
4 files changed, 3 insertions(+), 128 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index e8c3b762a92a3..fd1f9cd35e9d7 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -356,11 +356,7 @@
#define GEN7_TLB_RD_ADDR _MMIO(0x4700)
#define GEN12_PAT_INDEX(index) _MMIO(0x4800 + (index) * 4)
-#define _PAT_INDEX(index) _PICK_EVEN_2RANGES(index, 8, \
- 0x4800,
0x4804, \
- 0x4848,
0x484c)
-#define XEHP_PAT_INDEX(index) MCR_REG(_PAT_INDEX(index))
-#define XELPMP_PAT_INDEX(index)_MMIO(_PAT_INDEX(index))
+#define XEHP_PAT_INDEX(index) MCR_REG(0x4800 + (index) * 4)
#define XEHP_TILE0_ADDR_RANGE MCR_REG(0x4900)
#define XEHP_TILE_LMEM_RANGE_SHIFT 8
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c
b/drivers/gpu/drm/i915/gt/intel_gtt.c
index 2f6a9be0ffe61..4f436ba7a3c83 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
@@ -468,44 +468,6 @@ void gtt_write_workarounds(struct intel_gt *gt)
}
}
-static void xelpmp_setup_private_ppat(struct intel_uncore *uncore)
-{
- intel_uncore_write(uncore, XELPMP_PAT_INDEX(0),
- MTL_PPAT_L4_0_WB);
- intel_uncore_write(uncore, XELPMP_PAT_INDEX(1),
- MTL_PPAT_L4_1_WT);
- intel_uncore_write(uncore, XELPMP_PAT_INDEX(2),
- MTL_PPAT_L4_3_UC);
- intel_uncore_write(uncore, XELPMP_PAT_INDEX(3),
- MTL_PPAT_L4_0_WB | MTL_2_COH_1W);
- intel_uncore_write(uncore, XELPMP_PAT_INDEX(4),
- MTL_PPAT_L4_0_WB | MTL_3_COH_2W);
-
- /*
-* Remaining PAT entries are left at the hardware-default
-* fully-cached setting
-*/
-}
-
-static void xelpg_setup_private_ppat(struct intel_gt *gt)
-{
- intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(0),
-MTL_PPAT_L4_0_WB);
- intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(1),
-MTL_PPAT_L4_1_WT);
- intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(2),
-MTL_PPAT_L4_3_UC);
- intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(3),
-MTL_PPAT_L4_0_WB | MTL_2_COH_1W);
- intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(4),
-MTL_PPAT_L4_0_WB | MTL_3_COH_2W);
-
- /*
-* Remaining PAT entries are left at the hardware-default
-* fully-cached setting
-*/
-}
-
static void tgl_setup_private_ppat(struct intel_uncore *uncore)
{
/* TGL doesn't support LLC or AGE settings */
@@ -641,14 +603,7 @@ void setup_private_pat(struct intel_gt *gt)
GEM_BUG_ON(GRAPHICS_VER(i915) < 8);
- if (gt->type == GT_MEDIA) {
- xelpmp_setup_private_ppat(gt->uncore);
- return;
- }
-
- if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 70))
- xelpg_setup_private_ppat(gt);
- else if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 50))
+ if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 50))
xehp_setup_private_ppat(gt);
else if (GRAPHICS_VER(i915) >= 12)
tgl_setup_private_ppat(uncore);
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h
b/drivers/gpu/drm/i915/gt/intel_gtt.h
index ea17849e7a5c8..69ce55f517f56 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
@@ -147,14 +147,6 @@ typedef u64 gen8_pte_t;
#define GEN8_PDE_IPS_64K BIT(11)
#define GEN8_PDE_PS_2M BIT(7)
-#define MTL_PPAT_L4_CACHE_POLICY_MASK REG_GENMASK(3, 2)
-#define MTL_PAT_INDEX_COH_MODE_MASKREG_GENMASK(1, 0)
-#define MTL_PPAT_L4_3_UC REG_FIELD_PREP(MTL_PPAT_L4_CACHE_POLICY_MASK, 3)
-#define MTL_PPAT_L4_1_WT REG_FIELD_PREP(MTL_PPAT_L4_CACHE_POLICY_MASK, 1)
-#define MTL_PPAT_L4_0_WB REG_FIELD_PREP(MTL_PPAT_L4_CACHE_POLICY_MASK, 0)
-#define MTL_3_COH_2W REG_FIELD_PREP(MTL_PAT_INDEX_COH_MODE_MASK, 3)
-#define MTL_2_COH_1W REG_FIELD_PREP(MTL_PAT_INDEX_COH_MODE_MASK, 2)
-
enum i915_cache_level;
struct drm_i915_gem_object;
diff --git a/drivers/
Re: [Intel-gfx] [PATCH 0/2] Restore MTL boot
On 4/24/2023 6:09 PM, Andi Shyti wrote: Hi, The two patches reverted in this series are, together, preventing MTL from booting. Revert them until the fix is deployed. Andi Andi Shyti (2): Revert "drm/i915/mtl: fix mocs selftest" Revert "drm/i915/mtl: Define MOCS and PAT tables for MTL" Series is Reviewed-by: Nirmoy Das drivers/gpu/drm/i915/gt/intel_gt_regs.h | 6 +-- drivers/gpu/drm/i915/gt/intel_gtt.c | 47 + drivers/gpu/drm/i915/gt/intel_gtt.h | 8 --- drivers/gpu/drm/i915/gt/intel_mocs.c| 70 + drivers/gpu/drm/i915/gt/selftest_mocs.c | 3 +- 5 files changed, 4 insertions(+), 130 deletions(-)
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/mtl: workaround coherency issue for Media (rev4)
== Series Details ==
Series: drm/i915/mtl: workaround coherency issue for Media (rev4)
URL : https://patchwork.freedesktop.org/series/116751/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_13053_full -> Patchwork_116751v4_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_116751v4_full absolutely need
to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_116751v4_full, please notify your bug team to allow
them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (7 -> 7)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_116751v4_full:
### IGT changes ###
Possible regressions
* igt@i915_pm_rc6_residency@rc6-idle@bcs0:
- shard-apl: [PASS][1] -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13053/shard-apl2/igt@i915_pm_rc6_residency@rc6-i...@bcs0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116751v4/shard-apl7/igt@i915_pm_rc6_residency@rc6-i...@bcs0.html
Known issues
Here are the changes found in Patchwork_116751v4_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_persistence@hang:
- shard-snb: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#1099])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116751v4/shard-snb5/igt@gem_ctx_persiste...@hang.html
* igt@gem_exec_capture@capture-invisible@smem0:
- shard-apl: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#6334])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116751v4/shard-apl7/igt@gem_exec_capture@capture-invisi...@smem0.html
* igt@gem_exec_fair@basic-deadline:
- shard-apl: [PASS][5] -> [FAIL][6] ([i915#2846])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13053/shard-apl1/igt@gem_exec_f...@basic-deadline.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116751v4/shard-apl4/igt@gem_exec_f...@basic-deadline.html
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-apl: [PASS][7] -> [FAIL][8] ([i915#2842])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13053/shard-apl2/igt@gem_exec_fair@basic-pace-s...@rcs0.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116751v4/shard-apl7/igt@gem_exec_fair@basic-pace-s...@rcs0.html
* igt@gem_lmem_swapping@heavy-verify-multi:
- shard-apl: NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#4613])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116751v4/shard-apl7/igt@gem_lmem_swapp...@heavy-verify-multi.html
* igt@kms_ccs@pipe-a-bad-pixel-format-4_tiled_dg2_rc_ccs_cc:
- shard-apl: NOTRUN -> [SKIP][10] ([fdo#109271]) +45 similar issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116751v4/shard-apl7/igt@kms_ccs@pipe-a-bad-pixel-format-4_tiled_dg2_rc_ccs_cc.html
* igt@kms_ccs@pipe-c-bad-rotation-90-y_tiled_gen12_mc_ccs:
- shard-glk: NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#3886]) +1
similar issue
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116751v4/shard-glk8/igt@kms_ccs@pipe-c-bad-rotation-90-y_tiled_gen12_mc_ccs.html
* igt@kms_ccs@pipe-c-crc-primary-basic-y_tiled_gen12_mc_ccs:
- shard-apl: NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#3886])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116751v4/shard-apl7/igt@kms_ccs@pipe-c-crc-primary-basic-y_tiled_gen12_mc_ccs.html
*
igt@kms_plane_scaling@plane-scaler-with-clipping-clamping-rotation@pipe-a-vga-1:
- shard-snb: NOTRUN -> [SKIP][13] ([fdo#109271]) +107 similar
issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116751v4/shard-snb5/igt@kms_plane_scaling@plane-scaler-with-clipping-clamping-rotat...@pipe-a-vga-1.html
* igt@v3d/v3d_submit_csd@multiple-job-submission:
- shard-glk: NOTRUN -> [SKIP][14] ([fdo#109271]) +12 similar issues
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116751v4/shard-glk8/igt@v3d/v3d_submit_...@multiple-job-submission.html
Possible fixes
* igt@drm_fdinfo@most-busy-idle-check-all@rcs0:
- {shard-rkl}:[FAIL][15] ([i915#7742]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13053/shard-rkl-3/igt@drm_fdinfo@most-busy-idle-check-...@rcs0.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116751v4/shard-rkl-7/igt@drm_fdinfo@most-busy-idle-check-...@rcs0.html
* igt@gem_eio@reset-stress:
- {shard-dg1}:[FAIL][17] ([i915#5784]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13053/shard-dg1-16/igt@gem_...@reset-stress.html
[18]:
https://intel-gfx-ci.01.org/tree/drm
[Intel-gfx] [PATCH 11/15] drm/i915: Initialize dkl_phy spin lock from display code path
drm/i915: Initialize dkl_phy spin lock from display code path
Start moving the initialization of display locks from
i915_driver_early_probe().
Display locks should be initialized from display-only code paths.
It was also agreed that if a variable is only used in one file, it
should be initialized only in that file, so intel_dkl_phy_init() was
added.
v2:
- added intel_display_locks_init()
v3:
- rebased
v4:
- dropped intel_display_locks_init()
v5:
- moved intel_dkl_phy_init() to the beginning of file
Cc: intel-gfx@lists.freedesktop.org
Cc: Rodrigo Vivi
Cc: Ville Syrjälä
Cc: Jani Nikula
Cc: Maarten Lankhorst
Reviewed-by: Lucas De Marchi
Signed-off-by: José Roberto de Souza
Link:
https://patchwork.freedesktop.org/patch/msgid/20230420170558.35398-1-jose.so...@intel.com
(cherry picked from commit bfa010f608491036327db20aad1d15e28da0189e)
---
drivers/gpu/drm/i915/display/intel_display_driver.c | 2 ++
drivers/gpu/drm/i915/display/intel_dkl_phy.c| 9 +
drivers/gpu/drm/i915/display/intel_dkl_phy.h| 1 +
drivers/gpu/drm/i915/i915_driver.c | 1 -
4 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_driver.c
b/drivers/gpu/drm/i915/display/intel_display_driver.c
index 92c624f6d2ae7..95669ad1a7975 100644
--- a/drivers/gpu/drm/i915/display/intel_display_driver.c
+++ b/drivers/gpu/drm/i915/display/intel_display_driver.c
@@ -30,6 +30,7 @@
#include "intel_display_driver.h"
#include "intel_display_power.h"
#include "intel_display_types.h"
+#include "intel_dkl_phy.h"
#include "intel_dmc.h"
#include "intel_dp.h"
#include "intel_dpll.h"
@@ -177,6 +178,7 @@ void intel_display_driver_early_probe(struct
drm_i915_private *i915)
if (!HAS_DISPLAY(i915))
return;
+ intel_dkl_phy_init(i915);
intel_color_init_hooks(i915);
intel_init_cdclk_hooks(i915);
intel_audio_hooks_init(i915);
diff --git a/drivers/gpu/drm/i915/display/intel_dkl_phy.c
b/drivers/gpu/drm/i915/display/intel_dkl_phy.c
index 57cc3edba0163..a001232ad445e 100644
--- a/drivers/gpu/drm/i915/display/intel_dkl_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_dkl_phy.c
@@ -11,6 +11,15 @@
#include "intel_dkl_phy.h"
#include "intel_dkl_phy_regs.h"
+/**
+ * intel_dkl_phy_init - initialize Dekel PHY
+ * @i915: i915 device instance
+ */
+void intel_dkl_phy_init(struct drm_i915_private *i915)
+{
+ spin_lock_init(&i915->display.dkl.phy_lock);
+}
+
static void
dkl_phy_set_hip_idx(struct drm_i915_private *i915, struct intel_dkl_phy_reg
reg)
{
diff --git a/drivers/gpu/drm/i915/display/intel_dkl_phy.h
b/drivers/gpu/drm/i915/display/intel_dkl_phy.h
index 570ee36f9386f..5956ec3e940b1 100644
--- a/drivers/gpu/drm/i915/display/intel_dkl_phy.h
+++ b/drivers/gpu/drm/i915/display/intel_dkl_phy.h
@@ -12,6 +12,7 @@
struct drm_i915_private;
+void intel_dkl_phy_init(struct drm_i915_private *i915);
u32
intel_dkl_phy_read(struct drm_i915_private *i915, struct intel_dkl_phy_reg
reg);
void
diff --git a/drivers/gpu/drm/i915/i915_driver.c
b/drivers/gpu/drm/i915/i915_driver.c
index decaff25c36cf..a4e11a3c1842f 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -225,7 +225,6 @@ static int i915_driver_early_probe(struct drm_i915_private
*dev_priv)
mutex_init(&dev_priv->display.wm.wm_mutex);
mutex_init(&dev_priv->display.pps.mutex);
mutex_init(&dev_priv->display.hdcp.comp_mutex);
- spin_lock_init(&dev_priv->display.dkl.phy_lock);
i915_memcpy_init_early(dev_priv);
intel_runtime_pm_init_early(&dev_priv->runtime_pm);
--
2.40.0
[Intel-gfx] [PATCH 0/2] drm/i915/mtl: Add PTE encode functions
From: Fei Yang Extract PTE patch from https://patchwork.freedesktop.org/series/116868/ to fix MTL boot issue caused by MOCS/PAT update. Fei Yang (2): drm/i915/mtl: Add PTE encode function drm/i915/mtl: workaround coherency issue for Media drivers/gpu/drm/i915/display/intel_dpt.c | 2 +- drivers/gpu/drm/i915/gem/i915_gem_pages.c | 5 ++- drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 45 +++ drivers/gpu/drm/i915/gt/intel_ggtt.c | 36 -- drivers/gpu/drm/i915/gt/intel_gtt.h | 13 ++- drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c | 13 +++ drivers/gpu/drm/i915/gt/uc/intel_guc.c| 7 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 6 +++ 8 files changed, 113 insertions(+), 14 deletions(-) -- 2.25.1
[Intel-gfx] [PATCH 1/2] drm/i915/mtl: Add PTE encode function
From: Fei Yang
PTE encode functions are platform dependent. This patch implements
PTE functions for MTL, and ensures the correct PTE encode function
is used by calling pte_encode function pointer instead of the
hardcoded gen8 version of PTE encode.
Fixes: b76c0deef627 ("drm/i915/mtl: Define MOCS and PAT tables for MTL")
Signed-off-by: Fei Yang
Reviewed-by: Andrzej Hajda
Reviewed-by: Andi Shyti
Acked-by: Nirmoy Das
---
drivers/gpu/drm/i915/display/intel_dpt.c | 2 +-
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 45
drivers/gpu/drm/i915/gt/intel_ggtt.c | 36 +--
drivers/gpu/drm/i915/gt/intel_gtt.h | 13 +--
4 files changed, 83 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dpt.c
b/drivers/gpu/drm/i915/display/intel_dpt.c
index b8027392144d..c5eacfdba1a5 100644
--- a/drivers/gpu/drm/i915/display/intel_dpt.c
+++ b/drivers/gpu/drm/i915/display/intel_dpt.c
@@ -300,7 +300,7 @@ intel_dpt_create(struct intel_framebuffer *fb)
vm->vma_ops.bind_vma= dpt_bind_vma;
vm->vma_ops.unbind_vma = dpt_unbind_vma;
- vm->pte_encode = gen8_ggtt_pte_encode;
+ vm->pte_encode = vm->gt->ggtt->vm.pte_encode;
dpt->obj = dpt_obj;
dpt->obj->is_dpt = true;
diff --git a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
index 4daaa6f55668..11b91e0453c8 100644
--- a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
@@ -55,6 +55,34 @@ static u64 gen8_pte_encode(dma_addr_t addr,
return pte;
}
+static u64 mtl_pte_encode(dma_addr_t addr,
+ enum i915_cache_level level,
+ u32 flags)
+{
+ gen8_pte_t pte = addr | GEN8_PAGE_PRESENT | GEN8_PAGE_RW;
+
+ if (unlikely(flags & PTE_READ_ONLY))
+ pte &= ~GEN8_PAGE_RW;
+
+ if (flags & PTE_LM)
+ pte |= GEN12_PPGTT_PTE_LM | GEN12_PPGTT_PTE_NC;
+
+ switch (level) {
+ case I915_CACHE_NONE:
+ pte |= GEN12_PPGTT_PTE_PAT1;
+ break;
+ case I915_CACHE_LLC:
+ case I915_CACHE_L3_LLC:
+ pte |= GEN12_PPGTT_PTE_PAT0 | GEN12_PPGTT_PTE_PAT1;
+ break;
+ case I915_CACHE_WT:
+ pte |= GEN12_PPGTT_PTE_PAT0;
+ break;
+ }
+
+ return pte;
+}
+
static void gen8_ppgtt_notify_vgt(struct i915_ppgtt *ppgtt, bool create)
{
struct drm_i915_private *i915 = ppgtt->vm.i915;
@@ -427,7 +455,7 @@ gen8_ppgtt_insert_pte(struct i915_ppgtt *ppgtt,
u32 flags)
{
struct i915_page_directory *pd;
- const gen8_pte_t pte_encode = gen8_pte_encode(0, cache_level, flags);
+ const gen8_pte_t pte_encode = ppgtt->vm.pte_encode(0, cache_level,
flags);
gen8_pte_t *vaddr;
pd = i915_pd_entry(pdp, gen8_pd_index(idx, 2));
@@ -580,7 +608,7 @@ static void gen8_ppgtt_insert_huge(struct
i915_address_space *vm,
enum i915_cache_level cache_level,
u32 flags)
{
- const gen8_pte_t pte_encode = gen8_pte_encode(0, cache_level, flags);
+ const gen8_pte_t pte_encode = vm->pte_encode(0, cache_level, flags);
unsigned int rem = sg_dma_len(iter->sg);
u64 start = vma_res->start;
@@ -743,7 +771,7 @@ static void gen8_ppgtt_insert_entry(struct
i915_address_space *vm,
GEM_BUG_ON(pt->is_compact);
vaddr = px_vaddr(pt);
- vaddr[gen8_pd_index(idx, 0)] = gen8_pte_encode(addr, level, flags);
+ vaddr[gen8_pd_index(idx, 0)] = vm->pte_encode(addr, level, flags);
drm_clflush_virt_range(&vaddr[gen8_pd_index(idx, 0)], sizeof(*vaddr));
}
@@ -773,7 +801,7 @@ static void __xehpsdv_ppgtt_insert_entry_lm(struct
i915_address_space *vm,
}
vaddr = px_vaddr(pt);
- vaddr[gen8_pd_index(idx, 0) / 16] = gen8_pte_encode(addr, level, flags);
+ vaddr[gen8_pd_index(idx, 0) / 16] = vm->pte_encode(addr, level, flags);
}
static void xehpsdv_ppgtt_insert_entry(struct i915_address_space *vm,
@@ -820,8 +848,8 @@ static int gen8_init_scratch(struct i915_address_space *vm)
pte_flags |= PTE_LM;
vm->scratch[0]->encode =
- gen8_pte_encode(px_dma(vm->scratch[0]),
- I915_CACHE_NONE, pte_flags);
+ vm->pte_encode(px_dma(vm->scratch[0]),
+ I915_CACHE_NONE, pte_flags);
for (i = 1; i <= vm->top; i++) {
struct drm_i915_gem_object *obj;
@@ -963,7 +991,10 @@ struct i915_ppgtt *gen8_ppgtt_create(struct intel_gt *gt,
*/
ppgtt->vm.alloc_scratch_dma = alloc_pt_dma;
- ppgtt->vm.pte_encode = gen8_pte_encode;
+ if (GRAPHICS_VER_FULL(gt->i915) >= IP_VER(12, 70))
+ ppgtt->vm.pte_encode = mtl_pte_encode;
+ else
+ ppgtt->vm.pte_encode = gen8_pte_encode;
ppgtt->vm.bi
[Intel-gfx] [PATCH 2/2] drm/i915/mtl: workaround coherency issue for Media
From: Fei Yang
This patch implements Wa_22016122933.
In MTL, memory writes initiated by the Media tile update the whole
cache line, even for partial writes. This creates a coherency
problem for cacheable memory if both CPU and GPU are writing data
to different locations within a single cache line.
This patch circumvents the issue by making CPU/GPU shared memory
uncacheable (WC on CPU side, and PAT index 2 for GPU). Additionally,
it ensures that CPU writes are visible to the GPU with an
intel_guc_write_barrier().
While fixing the CTB issue, we noticed some random GSC firmware
loading failure because the share buffers are cacheable (WB) on CPU
side but uncached on GPU side. To fix these issues we need to map
such shared buffers as WC on CPU side. Since such allocations are
not all done through GuC allocator, to avoid too many code changes,
the i915_coherent_map_type() is now hard coded to return WC for MTL.
v2: Simplify the commit message(Matt).
BSpec: 45101
Signed-off-by: Fei Yang
Reviewed-by: Andi Shyti
Acked-by: Nirmoy Das
Reviewed-by: Andrzej Hajda
Reviewed-by: Matt Roper
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 5 -
drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c | 13 +
drivers/gpu/drm/i915/gt/uc/intel_guc.c| 7 +++
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 6 ++
4 files changed, 30 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
index ecd86130b74f..89fc8ea6bcfc 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
@@ -469,7 +469,10 @@ enum i915_map_type i915_coherent_map_type(struct
drm_i915_private *i915,
struct drm_i915_gem_object *obj,
bool always_coherent)
{
- if (i915_gem_object_is_lmem(obj))
+ /*
+* Wa_22016122933: always return I915_MAP_WC for MTL
+*/
+ if (i915_gem_object_is_lmem(obj) || IS_METEORLAKE(i915))
return I915_MAP_WC;
if (HAS_LLC(i915) || always_coherent)
return I915_MAP_WB;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
index 1d9fdfb11268..236673c02f9a 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
@@ -110,6 +110,13 @@ static int gsc_fw_load_prepare(struct intel_gsc_uc *gsc)
if (obj->base.size < gsc->fw.size)
return -ENOSPC;
+ /*
+* Wa_22016122933: For MTL the shared memory needs to be mapped
+* as WC on CPU side and UC (PAT index 2) on GPU side
+*/
+ if (IS_METEORLAKE(i915))
+ i915_gem_object_set_cache_coherency(obj, I915_CACHE_NONE);
+
dst = i915_gem_object_pin_map_unlocked(obj,
i915_coherent_map_type(i915,
obj, true));
if (IS_ERR(dst))
@@ -125,6 +132,12 @@ static int gsc_fw_load_prepare(struct intel_gsc_uc *gsc)
memset(dst, 0, obj->base.size);
memcpy(dst, src, gsc->fw.size);
+ /*
+* Wa_22016122933: Making sure the data in dst is
+* visible to GSC right away
+*/
+ intel_guc_write_barrier(>->uc.guc);
+
i915_gem_object_unpin_map(gsc->fw.obj);
i915_gem_object_unpin_map(obj);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index e89f16ecf1ae..c9f20385f6a0 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -744,6 +744,13 @@ struct i915_vma *intel_guc_allocate_vma(struct intel_guc
*guc, u32 size)
if (IS_ERR(obj))
return ERR_CAST(obj);
+ /*
+* Wa_22016122933: For MTL the shared memory needs to be mapped
+* as WC on CPU side and UC (PAT index 2) on GPU side
+*/
+ if (IS_METEORLAKE(gt->i915))
+ i915_gem_object_set_cache_coherency(obj, I915_CACHE_NONE);
+
vma = i915_vma_instance(obj, >->ggtt->vm, NULL);
if (IS_ERR(vma))
goto err;
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 1803a633ed64..99a0a89091e7 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -902,6 +902,12 @@ static int ct_read(struct intel_guc_ct *ct, struct
ct_incoming_msg **msg)
/* now update descriptor */
WRITE_ONCE(desc->head, head);
+ /*
+* Wa_22016122933: Making sure the head update is
+* visible to GuC right away
+*/
+ intel_guc_write_barrier(ct_to_guc(ct));
+
return available - len;
corrupted:
--
2.25.1
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 2/4] lib: Make SLPC helper function per GT
On Sun, 23 Apr 2023 13:16:44 -0700, Belgaumkar, Vinay wrote:
>
Hi Vinay,
> On 4/14/2023 1:25 PM, Dixit, Ashutosh wrote:
> > On Fri, 14 Apr 2023 12:16:37 -0700, Vinay Belgaumkar wrote:
> > Hi Vinay,
> >
> >> Use default of 0 where GT id is not being used.
> >>
> >> v2: Add a helper for GT 0 (Ashutosh)
> >>
> >> Signed-off-by: Vinay Belgaumkar
> >> ---
> >> lib/igt_pm.c | 36 ++--
> >> lib/igt_pm.h | 3 ++-
> >> 2 files changed, 28 insertions(+), 11 deletions(-)
> >>
> >> diff --git a/lib/igt_pm.c b/lib/igt_pm.c
> >> index 704acf7d..8a30bb3b 100644
> >> --- a/lib/igt_pm.c
> >> +++ b/lib/igt_pm.c
> >> @@ -1329,21 +1329,37 @@ void igt_pm_print_pci_card_runtime_status(void)
> >>}
> >> }
> >>
> >> -bool i915_is_slpc_enabled(int fd)
> >> +/**
> >> + * i915_is_slpc_enabled_gt:
> >> + * @drm_fd: DRM file descriptor
> >> + * @gt: GT id
> >> + * Check if SLPC is enabled on a GT
> >> + */
> >> +bool i915_is_slpc_enabled_gt(int drm_fd, int gt)
> >> {
> >> - int debugfs_fd = igt_debugfs_dir(fd);
> >> - char buf[4096] = {};
> >> - int len;
> >> + int debugfs_fd;
> >> + char buf[256] = {};
> > Shouldn't this be 4096 as before?
> >
> >> - igt_require(debugfs_fd != -1);
> >> + debugfs_fd = igt_debugfs_gt_open(drm_fd, gt, "uc/guc_slpc_info",
> >> O_RDONLY);
> >> +
> >> + /* if guc_slpc_info not present then return false */
> >> + if (debugfs_fd < 0)
> >> + return false;
> > I think this should just be:
> >
> > igt_require_fd(debugfs_fd);
> >
> > Basically we cannot determine if SLPC is enabled or not if say debugfs is
> > not mounted, so it's not correct return false from here.
>
> Actually, rethinking on this, we should keep it to return false. This is
> making tests skip on platforms where it shouldn't. Debugfs will not be
> mounted only when driver load fails,
Debugfs not being mounted has nothing to do with driver load, it is just
that this command has not been run before running the tests (the system
would typically be configured to run this after boot):
mount -t debugfs none /sys/kernel/debug/
Ah, igt_debugfs_path() will mount debugfs if not mounted and assert if
mount fails. So IGT itself is mounting debugfs if not mounted.
> which would cause the test to fail
> when we try to create the drm fd before this. Case in point -
> https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_8839/fi-tgl-1115g4/igt@i915_pm_...@basic-api.html
> - here, the test should have run (guc disabled platform) but it skipped.
OK, sorry yes because it is checking for guc_slpc_info, which would
indicate whether or not slpc is enabled.
But the issue is still there, whether or not we solve it. Say SLPC is
enabled but debugfs was not mounted. In the code above we will conclude
that slpc is not enabled. Because mulitple conditions have been combined
into one and there is no way to check for them separately (debugfs being
mounted and guc_slpc_info being present).
The original code above has this check:
igt_require(debugfs_fd != -1);
Which is checking for whether or not debugfs is mounted. Where does this
check move in this series?
Anyway maybe for now just change the code to return false.
Thanks.
--
Ashutosh
> >> + read(debugfs_fd, buf, sizeof(buf)-1);
> >>
> >> - len = igt_debugfs_simple_read(debugfs_fd, "gt/uc/guc_slpc_info", buf,
> >> sizeof(buf));
> >>close(debugfs_fd);
> >>
> >> - if (len < 0)
> >> - return false;
> >> - else
> >> - return strstr(buf, "SLPC state: running");
> >> + return strstr(buf, "SLPC state: running");
> >> +}
> >> +
> >> +/**
> >> + * i915_is_slpc_enabled:
> >> + * @drm_fd: DRM file descriptor
> >> + * Check if SLPC is enabled on GT 0
> > Hmm, not sure why we are not using the i915_for_each_gt() loop here since
> > that is the correct way of doing it.
> >
> > At the min let's remove the GT 0 in the comment above. This function
> > doesn't check for GT0, it checks if "slpc is enabled for the device". We
> > can check only on GT0 if we are certain that checking on GT0 is sufficient,
> > that is if SLPC is disabled on GT0 it's disabled for the device. But then
> > someone can ask the question in that case why are we exposing slpc_enabled
> > for each gt from the kernel rather than at the device level.
> >
> > In any case for now let's change the above comment to:
> >
> > "Check if SLPC is enabled" or ""Check if SLPC is enabled for the i915
> > device".
> >
> > With the above comments addressed this is:
> >
> > Reviewed-by: Ashutosh Dixit
> >
> > Also, why is igt@i915_pm_rps@basic-api still skipping on DG2/ATSM in
> > pre-merge CI even after this series?
> >
> > Thanks.
> > --
> > Ashutosh
> >
> >
> >> + */
> >> +bool i915_is_slpc_enabled(int drm_fd)
> >> +{
> >> + return i915_is_slpc_enabled_gt(drm_fd, 0);
> >> }
> >> int igt_pm_get_runtime_suspended_time(struct pci_device *pci_dev)
> >> diff --git a/lib/igt_pm.h b/lib/igt_pm.h
> >> index d0d6d673..448cf42d 100644
> >> --- a/lib/igt_pm.h
> >> +++ b/lib
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 2/4] lib: Make SLPC helper function per GT
On Mon, 24 Apr 2023 09:55:14 -0700, Dixit, Ashutosh wrote:
>
> On Sun, 23 Apr 2023 13:16:44 -0700, Belgaumkar, Vinay wrote:
> >
>
> Hi Vinay,
>
> > On 4/14/2023 1:25 PM, Dixit, Ashutosh wrote:
> > > On Fri, 14 Apr 2023 12:16:37 -0700, Vinay Belgaumkar wrote:
> > > Hi Vinay,
> > >
> > >> Use default of 0 where GT id is not being used.
> > >>
> > >> v2: Add a helper for GT 0 (Ashutosh)
> > >>
> > >> Signed-off-by: Vinay Belgaumkar
> > >> ---
> > >> lib/igt_pm.c | 36 ++--
> > >> lib/igt_pm.h | 3 ++-
> > >> 2 files changed, 28 insertions(+), 11 deletions(-)
> > >>
> > >> diff --git a/lib/igt_pm.c b/lib/igt_pm.c
> > >> index 704acf7d..8a30bb3b 100644
> > >> --- a/lib/igt_pm.c
> > >> +++ b/lib/igt_pm.c
> > >> @@ -1329,21 +1329,37 @@ void igt_pm_print_pci_card_runtime_status(void)
> > >> }
> > >> }
> > >>
> > >> -bool i915_is_slpc_enabled(int fd)
> > >> +/**
> > >> + * i915_is_slpc_enabled_gt:
> > >> + * @drm_fd: DRM file descriptor
> > >> + * @gt: GT id
> > >> + * Check if SLPC is enabled on a GT
> > >> + */
> > >> +bool i915_is_slpc_enabled_gt(int drm_fd, int gt)
> > >> {
> > >> -int debugfs_fd = igt_debugfs_dir(fd);
> > >> -char buf[4096] = {};
> > >> -int len;
> > >> +int debugfs_fd;
> > >> +char buf[256] = {};
> > > Shouldn't this be 4096 as before?
> > >
> > >> -igt_require(debugfs_fd != -1);
> > >> +debugfs_fd = igt_debugfs_gt_open(drm_fd, gt,
> > >> "uc/guc_slpc_info", O_RDONLY);
> > >> +
> > >> +/* if guc_slpc_info not present then return false */
> > >> +if (debugfs_fd < 0)
> > >> +return false;
> > > I think this should just be:
> > >
> > > igt_require_fd(debugfs_fd);
> > >
> > > Basically we cannot determine if SLPC is enabled or not if say debugfs is
> > > not mounted, so it's not correct return false from here.
> >
> > Actually, rethinking on this, we should keep it to return false. This is
> > making tests skip on platforms where it shouldn't. Debugfs will not be
> > mounted only when driver load fails,
>
> Debugfs not being mounted has nothing to do with driver load, it is just
> that this command has not been run before running the tests (the system
> would typically be configured to run this after boot):
>
> mount -t debugfs none /sys/kernel/debug/
>
> Ah, igt_debugfs_path() will mount debugfs if not mounted and assert if
> mount fails. So IGT itself is mounting debugfs if not mounted.
>
> > which would cause the test to fail
> > when we try to create the drm fd before this. Case in point -
> > https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_8839/fi-tgl-1115g4/igt@i915_pm_...@basic-api.html
> > - here, the test should have run (guc disabled platform) but it skipped.
>
> OK, sorry yes because it is checking for guc_slpc_info, which would
> indicate whether or not slpc is enabled.
>
> But the issue is still there, whether or not we solve it. Say SLPC is
> enabled but debugfs was not mounted. In the code above we will conclude
> that slpc is not enabled. Because mulitple conditions have been combined
> into one and there is no way to check for them separately (debugfs being
> mounted and guc_slpc_info being present).
>
> The original code above has this check:
>
> igt_require(debugfs_fd != -1);
>
> Which is checking for whether or not debugfs is mounted. Where does this
> check move in this series?
>
> Anyway maybe for now just change the code to return false.
I think the correct way to do it would be remove igt_debugfs_gt_open from
Patch 1 and call the sequence in igt_debugfs_gt_open directly from
i915_is_slpc_enabled_gt, something like:
dir = igt_debugfs_gt_dir(device, gt);
igt_require(dir);
debugfs_fd = openat(dir, "uc/guc_slpc_info", O_RDONLY);
if (debugfs_fd < 0)
return false;
>
> Thanks.
> --
> Ashutosh
>
> > >> +read(debugfs_fd, buf, sizeof(buf)-1);
> > >>
> > >> -len = igt_debugfs_simple_read(debugfs_fd,
> > >> "gt/uc/guc_slpc_info", buf, sizeof(buf));
> > >> close(debugfs_fd);
> > >>
> > >> -if (len < 0)
> > >> -return false;
> > >> -else
> > >> -return strstr(buf, "SLPC state: running");
> > >> +return strstr(buf, "SLPC state: running");
> > >> +}
> > >> +
> > >> +/**
> > >> + * i915_is_slpc_enabled:
> > >> + * @drm_fd: DRM file descriptor
> > >> + * Check if SLPC is enabled on GT 0
> > > Hmm, not sure why we are not using the i915_for_each_gt() loop here since
> > > that is the correct way of doing it.
> > >
> > > At the min let's remove the GT 0 in the comment above. This function
> > > doesn't check for GT0, it checks if "slpc is enabled for the device". We
> > > can check only on GT0 if we are certain that checking on GT0 is
> > > sufficient,
> > > that is if SLPC is disabled on GT0 it's disabled for the device. But then
> > > someone can ask the question in that case why are we exposing slpc_enabled
> > > for each
Re: [Intel-gfx] [PATCH 8/8] drm/i915: Allow user to set cache at BO creation
On 2023-04-24 02:08:43, Tvrtko Ursulin wrote: > > Being able to "list" supported extensions sounds like a reasonable > principle, albeit a departure from the design direction to date. > Which means there are probably no quick solutions. Also, AFAIU, only > PXP context create is the problematic one, right? Everything else is > pretty much instant or delayed allocation so super cheap to probe by > attempting to use. > > If I got that right and given this series is about > drm_i915_gem_create_ext I don't think this side discussion should be > blocking it. This still leaves the issue of no reasonable detection mechanism for the extension. If the discussion gets too complicated, then can we add a GET_PARAM for the SET_PAT extension? I'm hoping we could either come up with something better reasonably quickly, or i915/Xe can add a new param for each new extensions until a better approach is available. > Furthermore the PXP context create story is even more complicated, > in a way that it is not just about querying whether the extension is > supported, but the expensive check is something more complicated. > > Going back to implementation details for this proposed new feature, > one alternative to query could be something like: > >drm_i915_gem_create_ext.flags |= I915_GEM_CREATE_EXT_FLAG_PROBE_EXTENSIONS; > > That would be somewhat more light weight to implement that the > i915_query route. And it appears it would work for all ioctls which > support extensions apart for i915_context_param_engines. This seems little better than the "try it, and if it works then it's supported". I'm not suggesting that userspace should be able to check that scenario x+y+z will work, but more a list of extensions that conceivably could work. Normally this should just a matter of the kernel unconditionally adding the newly implemented extension to the list returned in the query call. If a GET_PARAM can be made for the PXP case, then it seems like a query item returning CONTEXT_CREATE extensions could conditionally omit that extension just as easily as implementing the proposed new GET_PARAM. -Jordan
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 2/4] lib: Make SLPC helper function per GT
On Mon, 24 Apr 2023 10:07:26 -0700, Dixit, Ashutosh wrote:
>
> On Mon, 24 Apr 2023 09:55:14 -0700, Dixit, Ashutosh wrote:
> >
> > On Sun, 23 Apr 2023 13:16:44 -0700, Belgaumkar, Vinay wrote:
> > >
> >
> > Hi Vinay,
> >
> > > On 4/14/2023 1:25 PM, Dixit, Ashutosh wrote:
> > > > On Fri, 14 Apr 2023 12:16:37 -0700, Vinay Belgaumkar wrote:
> > > > Hi Vinay,
> > > >
> > > >> Use default of 0 where GT id is not being used.
> > > >>
> > > >> v2: Add a helper for GT 0 (Ashutosh)
> > > >>
> > > >> Signed-off-by: Vinay Belgaumkar
> > > >> ---
> > > >> lib/igt_pm.c | 36 ++--
> > > >> lib/igt_pm.h | 3 ++-
> > > >> 2 files changed, 28 insertions(+), 11 deletions(-)
> > > >>
> > > >> diff --git a/lib/igt_pm.c b/lib/igt_pm.c
> > > >> index 704acf7d..8a30bb3b 100644
> > > >> --- a/lib/igt_pm.c
> > > >> +++ b/lib/igt_pm.c
> > > >> @@ -1329,21 +1329,37 @@ void igt_pm_print_pci_card_runtime_status(void)
> > > >>}
> > > >> }
> > > >>
> > > >> -bool i915_is_slpc_enabled(int fd)
> > > >> +/**
> > > >> + * i915_is_slpc_enabled_gt:
> > > >> + * @drm_fd: DRM file descriptor
> > > >> + * @gt: GT id
> > > >> + * Check if SLPC is enabled on a GT
> > > >> + */
> > > >> +bool i915_is_slpc_enabled_gt(int drm_fd, int gt)
> > > >> {
> > > >> - int debugfs_fd = igt_debugfs_dir(fd);
> > > >> - char buf[4096] = {};
> > > >> - int len;
> > > >> + int debugfs_fd;
> > > >> + char buf[256] = {};
> > > > Shouldn't this be 4096 as before?
> > > >
> > > >> - igt_require(debugfs_fd != -1);
> > > >> + debugfs_fd = igt_debugfs_gt_open(drm_fd, gt,
> > > >> "uc/guc_slpc_info", O_RDONLY);
> > > >> +
> > > >> + /* if guc_slpc_info not present then return false */
> > > >> + if (debugfs_fd < 0)
> > > >> + return false;
> > > > I think this should just be:
> > > >
> > > > igt_require_fd(debugfs_fd);
> > > >
> > > > Basically we cannot determine if SLPC is enabled or not if say debugfs
> > > > is
> > > > not mounted, so it's not correct return false from here.
> > >
> > > Actually, rethinking on this, we should keep it to return false. This is
> > > making tests skip on platforms where it shouldn't. Debugfs will not be
> > > mounted only when driver load fails,
> >
> > Debugfs not being mounted has nothing to do with driver load, it is just
> > that this command has not been run before running the tests (the system
> > would typically be configured to run this after boot):
> >
> > mount -t debugfs none /sys/kernel/debug/
> >
> > Ah, igt_debugfs_path() will mount debugfs if not mounted and assert if
> > mount fails. So IGT itself is mounting debugfs if not mounted.
> >
> > > which would cause the test to fail
> > > when we try to create the drm fd before this. Case in point -
> > > https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_8839/fi-tgl-1115g4/igt@i915_pm_...@basic-api.html
> > > - here, the test should have run (guc disabled platform) but it skipped.
> >
> > OK, sorry yes because it is checking for guc_slpc_info, which would
> > indicate whether or not slpc is enabled.
> >
> > But the issue is still there, whether or not we solve it. Say SLPC is
> > enabled but debugfs was not mounted. In the code above we will conclude
> > that slpc is not enabled. Because mulitple conditions have been combined
> > into one and there is no way to check for them separately (debugfs being
> > mounted and guc_slpc_info being present).
> >
> > The original code above has this check:
> >
> > igt_require(debugfs_fd != -1);
> >
> > Which is checking for whether or not debugfs is mounted. Where does this
> > check move in this series?
> >
> > Anyway maybe for now just change the code to return false.
>
> I think the correct way to do it would be remove igt_debugfs_gt_open from
> Patch 1
Or retain the function but don't use it.
> and call the sequence in igt_debugfs_gt_open directly from
> i915_is_slpc_enabled_gt, something like:
>
> dir = igt_debugfs_gt_dir(device, gt);
> igt_require(dir);
>
> debugfs_fd = openat(dir, "uc/guc_slpc_info", O_RDONLY);
> if (debugfs_fd < 0)
> return false;
>
> >
> > Thanks.
> > --
> > Ashutosh
> >
> > > >> + read(debugfs_fd, buf, sizeof(buf)-1);
> > > >>
> > > >> - len = igt_debugfs_simple_read(debugfs_fd,
> > > >> "gt/uc/guc_slpc_info", buf, sizeof(buf));
> > > >>close(debugfs_fd);
> > > >>
> > > >> - if (len < 0)
> > > >> - return false;
> > > >> - else
> > > >> - return strstr(buf, "SLPC state: running");
> > > >> + return strstr(buf, "SLPC state: running");
> > > >> +}
> > > >> +
> > > >> +/**
> > > >> + * i915_is_slpc_enabled:
> > > >> + * @drm_fd: DRM file descriptor
> > > >> + * Check if SLPC is enabled on GT 0
> > > > Hmm, not sure why we are not using the i915_for_each_gt() loop here
> > > > since
> > > > that is the correct way of doing it.
> > > >
> > > > At the min let's remove the GT 0 in the comment above. This functio
Re: [Intel-gfx] [PATCH 3/8] drm/i915/mtl: Add PTE encode function
On Sun, Apr 23, 2023 at 12:37:27AM -0700, Yang, Fei wrote:
> > On Fri, Apr 21, 2023 at 10:27:22AM -0700, Yang, Fei wrote:
> >>> On Wed, Apr 19, 2023 at 04:00:53PM -0700, fei.y...@intel.com wrote:
> From: Fei Yang
>
> PTE encode functions are platform dependent. This patch implements
> PTE functions for MTL, and ensures the correct PTE encode function
> is used by calling pte_encode function pointer instead of the
> hardcoded gen8 version of PTE encode.
>
> Signed-off-by: Fei Yang
> Reviewed-by: Andrzej Hajda
> Reviewed-by: Andi Shyti
> Acked-by: Nirmoy Das
> >>>
> >>> Bspec: 45015, 45040
> >>>
> ---
> drivers/gpu/drm/i915/display/intel_dpt.c | 2 +-
> drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 45
> drivers/gpu/drm/i915/gt/intel_ggtt.c | 36 +--
> 3 files changed, 72 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dpt.c
> >>b/drivers/gpu/drm/i915/display/intel_dpt.c
> index b8027392144d..c5eacfdba1a5 100644
> --- a/drivers/gpu/drm/i915/display/intel_dpt.c
> +++ b/drivers/gpu/drm/i915/display/intel_dpt.c
> @@ -300,7 +300,7 @@ intel_dpt_create(struct intel_framebuffer *fb)
> vm->vma_ops.bind_vma= dpt_bind_vma;
> vm->vma_ops.unbind_vma = dpt_unbind_vma;
>
> - vm->pte_encode = gen8_ggtt_pte_encode;
> + vm->pte_encode = vm->gt->ggtt->vm.pte_encode;
>
> dpt->obj = dpt_obj;
> dpt->obj->is_dpt = true;
> diff --git a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
> b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
> index 4daaa6f55668..11b91e0453c8 100644
> --- a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
> +++ b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
> @@ -55,6 +55,34 @@ static u64 gen8_pte_encode(dma_addr_t addr,
> return pte;
> }
>
> +static u64 mtl_pte_encode(dma_addr_t addr,
> + enum i915_cache_level level,
> + u32 flags)
> +{
> + gen8_pte_t pte = addr | GEN8_PAGE_PRESENT | GEN8_PAGE_RW;
> +
> + if (unlikely(flags & PTE_READ_ONLY))
> + pte &= ~GEN8_PAGE_RW;
> +
> + if (flags & PTE_LM)
> + pte |= GEN12_PPGTT_PTE_LM | GEN12_PPGTT_PTE_NC;
> >>>
> >>> GEN12_PPGTT_PTE_NC got defined in the previous patch as BIT(5). But
> >>> according to bspec 45040, bit 5 is ignored in the PTE encoding. What is
> >>> this trying to do?
> >>
> >> This takes effect only for PTE_LM, doesn't affect MTL.
> >> PTE_NC is needed for PVC (use of access counter).
> >> I believe this function was writen based on the one for PVC. And this
> >> function did get extended to cover all gen12 in a later patch.
> >
> > Even though MTL doesn't have local memory, PTE_LM is supposed to be
> > used on MTL for access to BAR2 stolen memory.
>
> You were right, but I still think this code is fine because this bit is
> ignored for MTL anyway and it is needed for other platforms with LMEM.
> Otherwise this code would have some sort of platform checking which is
> hard to do because we don't have platform info here.
> Or we would have to define another PTE encode function for platforms
> needing PTE_NC just for this one difference, then manage the function
> pointer correctly.
MTL is the only platform that uses this function right now:
+ if (GRAPHICS_VER_FULL(gt->i915) >= IP_VER(12, 70))
+ ppgtt->vm.pte_encode = mtl_pte_encode;
+ else
+ ppgtt->vm.pte_encode = gen8_pte_encode;
If this is intended for PVC, then you have it in the wrong function to
begin with (and it also shouldn't be in a patch labelled "mtl"). If
you're trying to future-proof for some post-MTL discrete platform, then
such code should be saved until we enable that platform so that it can
be properly reviewed.
Matt
>
> -Fei
>
> > Matt
> >
> >> -Fei
> >>> Matt
> >>>
> +
> + switch (level) {
> + case I915_CACHE_NONE:
> + pte |= GEN12_PPGTT_PTE_PAT1;
> + break;
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
Re: [Intel-gfx] [PATCH V2] drm/i915/mtl: Add workaround 14018778641
It looks like the number you have in the title and comments isn't a
valid workaround number. It looks like you actually meant to use
Wa_14018575942.
On Mon, Apr 24, 2023 at 03:47:49PM +0530, Tejas Upadhyay wrote:
> WA 18018781329 is applicable now across all MTL
> steppings.
Wa_18018781329 hasn't changed; it's still restricted to just A-step of
MTL. What you're implementing here is a different workaround that has
the same implementation, and a broader platform list. It would be more
accurate to say something like
"Wa_14018575942 is identical to existing Wa_18018781329, but applies to
all MTL steppings."
Matt
>
> V2:
> - Remove IS_MTL check, code already running for MTL - Matt
>
> Cc: Matt Roper
> Signed-off-by: Tejas Upadhyay
> ---
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 30 ++---
> 1 file changed, 14 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index 312eb8b5f949..de4f8e2e8e8c 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -1695,19 +1695,18 @@ pvc_gt_workarounds_init(struct intel_gt *gt, struct
> i915_wa_list *wal)
> static void
> xelpg_gt_workarounds_init(struct intel_gt *gt, struct i915_wa_list *wal)
> {
> + /* Wa_14018778641 / Wa_18018781329 */
> + wa_mcr_write_or(wal, RENDER_MOD_CTRL, FORCE_MISS_FTLB);
> + wa_mcr_write_or(wal, COMP_MOD_CTRL, FORCE_MISS_FTLB);
> +
> if (IS_MTL_GRAPHICS_STEP(gt->i915, M, STEP_A0, STEP_B0) ||
> IS_MTL_GRAPHICS_STEP(gt->i915, P, STEP_A0, STEP_B0)) {
> /* Wa_14014830051 */
> wa_mcr_write_clr(wal, SARB_CHICKEN1, COMP_CKN_IN);
>
> - /* Wa_18018781329 */
> - wa_mcr_write_or(wal, RENDER_MOD_CTRL, FORCE_MISS_FTLB);
> - wa_mcr_write_or(wal, COMP_MOD_CTRL, FORCE_MISS_FTLB);
> -
> /* Wa_14015795083 */
> wa_write_clr(wal, GEN7_MISCCPCTL,
> GEN12_DOP_CLOCK_GATE_RENDER_ENABLE);
> }
> -
> /*
>* Unlike older platforms, we no longer setup implicit steering here;
>* all MCR accesses are explicitly steered.
> @@ -1718,17 +1717,16 @@ xelpg_gt_workarounds_init(struct intel_gt *gt, struct
> i915_wa_list *wal)
> static void
> xelpmp_gt_workarounds_init(struct intel_gt *gt, struct i915_wa_list *wal)
> {
> - if (IS_MTL_MEDIA_STEP(gt->i915, STEP_A0, STEP_B0)) {
> - /*
> - * Wa_18018781329
> - *
> - * Note that although these registers are MCR on the primary
> - * GT, the media GT's versions are regular singleton registers.
> - */
> - wa_write_or(wal, XELPMP_GSC_MOD_CTRL, FORCE_MISS_FTLB);
> - wa_write_or(wal, XELPMP_VDBX_MOD_CTRL, FORCE_MISS_FTLB);
> - wa_write_or(wal, XELPMP_VEBX_MOD_CTRL, FORCE_MISS_FTLB);
> - }
> + /*
> + * Wa_14018778641
> + * Wa_18018781329
> + *
> + * Note that although these registers are MCR on the primary
> + * GT, the media GT's versions are regular singleton registers.
> + */
> + wa_write_or(wal, XELPMP_GSC_MOD_CTRL, FORCE_MISS_FTLB);
> + wa_write_or(wal, XELPMP_VDBX_MOD_CTRL, FORCE_MISS_FTLB);
> + wa_write_or(wal, XELPMP_VEBX_MOD_CTRL, FORCE_MISS_FTLB);
>
> debug_dump_steering(gt);
> }
> --
> 2.25.1
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
Re: [Intel-gfx] [PATCH v3 12/12] vfio/pci: Report dev_id in VFIO_DEVICE_GET_PCI_HOT_RESET_INFO
On Sun, Apr 23, 2023 at 10:28:58AM +, Liu, Yi L wrote: > This noiommu improvement shall allow user to attach ioas to noiommu devices. > is it? This may be done by calling iommufd_access_attach(). So there is a > quick question. In the cdev series, shall we allow the attachment > for noiommu? Yes, I think we need to undo the decision we talked about earlier where no-iommu would be asked for with a -1 iommufd. All vfio_devices should have an iommufd_ctx when container is compiled out. You don't need to do anything with the ctx for no-iommu beyond demand that userspace provide it. Jason
Re: [Intel-gfx] [PATCH 1/2] i915/pmu: Add support for total context runtime for GuC back-end
On Tue, 04 Apr 2023 17:14:32 -0700, Umesh Nerlige Ramappa wrote:
Hi Umesh,
> GPU accumulates the context runtime in a 32 bit counter - CTX_TIMESTAMP
> in the context image. This value is saved/restored on context switches.
> KMD accumulates these values into a 64 bit counter taking care of any
> overflows as needed. This count provides the basis for client specific
> busyness in the fdinfo interface.
>
> KMD accumulation happens just before the context is unpinned and when
> context switches out. This works for execlist back-end since execlist
> scheduling has visibility into context switches. With GuC mode, KMD does
> not have visibility into context switches and this counter is
> accumulated only when context is unpinned. Context is unpinned once the
> context scheduling is successfully disabled. Disabling context
> scheduling is an asynchronous operation.
This means guc_context_unpin() is called asynchronously, correct? From
guc_context_sched_disable()?
> Also if a context is servicing frequent requests, scheduling may never be
> disabled on it.
>
> For GuC mode, since updates to the context runtime may be delayed, add
> hooks to update the context runtime in a worker thread as well as when
> a user queries for it.
>
> Limitation:
> - If a context is never switched out or runs for a long period of time,
> the runtime value of CTX_TIMESTAMP may never be updated, so the
> counter value may be unreliable. This patch does not support such
> cases. Such support must be available from the GuC FW and it is WIP.
>
> This patch is an extract from previous work authored by John/Umesh here -
> https://patchwork.freedesktop.org/patch/496441/?series=105085&rev=4
>
> Signed-off-by: Umesh Nerlige Ramappa
> Co-developed-by: John Harrison
> Signed-off-by: John Harrison
> ---
> drivers/gpu/drm/i915/gt/intel_context.c | 12 +--
> drivers/gpu/drm/i915/gt/intel_context.h | 2 +-
> drivers/gpu/drm/i915/gt/intel_context_types.h | 5 +++
> .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 33 +++
> 4 files changed, 49 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
> b/drivers/gpu/drm/i915/gt/intel_context.c
> index 2aa63ec521b8..e01f222e9e42 100644
> --- a/drivers/gpu/drm/i915/gt/intel_context.c
> +++ b/drivers/gpu/drm/i915/gt/intel_context.c
> @@ -578,16 +578,24 @@ void intel_context_bind_parent_child(struct
> intel_context *parent,
> child->parallel.parent = parent;
> }
>
> -u64 intel_context_get_total_runtime_ns(const struct intel_context *ce)
> +u64 intel_context_get_total_runtime_ns(struct intel_context *ce)
> {
> u64 total, active;
>
> + if (ce->ops->update_stats)
> + ce->ops->update_stats(ce);
> +
> total = ce->stats.runtime.total;
> if (ce->ops->flags & COPS_RUNTIME_CYCLES)
> total *= ce->engine->gt->clock_period_ns;
>
> active = READ_ONCE(ce->stats.active);
> - if (active)
> + /*
> + * When COPS_RUNTIME_ACTIVE_TOTAL is set for ce->cops, the backend
> + * already provides the total active time of the context,
Where is this done in the GuC case? I looked but couldn't find it (at least
in this version of the patch, it is there in the old version).
> + * so skip this calculation when this flag is set.
> + */
> + if (active && !(ce->ops->flags & COPS_RUNTIME_ACTIVE_TOTAL))
> active = intel_context_clock() - active;
>
> return total + active;
> diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
> b/drivers/gpu/drm/i915/gt/intel_context.h
> index 0a8d553da3f4..720809523e2d 100644
> --- a/drivers/gpu/drm/i915/gt/intel_context.h
> +++ b/drivers/gpu/drm/i915/gt/intel_context.h
> @@ -368,7 +368,7 @@ intel_context_clear_nopreempt(struct intel_context *ce)
> clear_bit(CONTEXT_NOPREEMPT, &ce->flags);
> }
>
> -u64 intel_context_get_total_runtime_ns(const struct intel_context *ce);
> +u64 intel_context_get_total_runtime_ns(struct intel_context *ce);
> u64 intel_context_get_avg_runtime_ns(struct intel_context *ce);
>
> static inline u64 intel_context_clock(void)
> diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
> b/drivers/gpu/drm/i915/gt/intel_context_types.h
> index e36670f2e626..58b0294d359d 100644
> --- a/drivers/gpu/drm/i915/gt/intel_context_types.h
> +++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
> @@ -38,6 +38,9 @@ struct intel_context_ops {
> #define COPS_RUNTIME_CYCLES_BIT 1
> #define COPS_RUNTIME_CYCLES BIT(COPS_RUNTIME_CYCLES_BIT)
>
> +#define COPS_RUNTIME_ACTIVE_TOTAL_BIT 2
> +#define COPS_RUNTIME_ACTIVE_TOTAL BIT(COPS_RUNTIME_ACTIVE_TOTAL_BIT)
> +
> int (*alloc)(struct intel_context *ce);
>
> void (*revoke)(struct intel_context *ce, struct i915_request *rq,
> @@ -58,6 +61,8 @@ struct intel_context_ops {
>
> void (*sched_disable)(struct intel_context *ce);
>
> + void (*update_stats)(struct intel_context *ce);
> +
> void (*reset)(struct intel_context *ce);
> v
Re: [Intel-gfx] [PATCH 06/13] drm/i915/mtl: For DP2.0 10G and 20G rates use MPLLA
On Thu, Apr 20, 2023 at 03:40:43PM +0300, Mika Kahola wrote: > Use MPLLA for DP2.0 rates 20G and 20G, when ssc is enabled. > Reviewed-by: Radhakrishna Sripada - Radhakrishna(RK) Sripada > Signed-off-by: Mika Kahola > --- > drivers/gpu/drm/i915/display/intel_cx0_phy.c | 7 +-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c > b/drivers/gpu/drm/i915/display/intel_cx0_phy.c > index f7720acaf58c..4231ba98f075 100644 > --- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c > +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c > @@ -2340,8 +2340,11 @@ static void intel_program_port_clock_ctl(struct > intel_encoder *encoder, > val |= XELPDP_DDI_CLOCK_SELECT(XELPDP_DDI_CLOCK_SELECT_MAXPCLK); > > /* TODO: HDMI FRL */ > - /* TODO: DP2.0 10G and 20G rates enable MPLLA*/ > - val |= crtc_state->cx0pll_state.ssc_enabled ? XELPDP_SSC_ENABLE_PLLB : > 0; > + /* DP2.0 10G and 20G rates enable MPLLA*/ > + if (crtc_state->port_clock == 100 || crtc_state->port_clock == > 200) > + val |= crtc_state->cx0pll_state.ssc_enabled ? > XELPDP_SSC_ENABLE_PLLA : 0; > + else > + val |= crtc_state->cx0pll_state.ssc_enabled ? > XELPDP_SSC_ENABLE_PLLB : 0; > > intel_de_rmw(i915, XELPDP_PORT_CLOCK_CTL(encoder->port), >XELPDP_LANE1_PHY_CLOCK_SELECT | > XELPDP_FORWARD_CLOCK_UNGATE | > -- > 2.34.1 >
[Intel-gfx] [PATCH v2 1/2] drm/i915/mtl: Add PTE encode function
From: Fei Yang
PTE encode functions are platform dependent. This patch implements
PTE functions for MTL, and ensures the correct PTE encode function
is used by calling pte_encode function pointer instead of the
hardcoded gen8 version of PTE encode.
Fixes: b76c0deef627 ("drm/i915/mtl: Define MOCS and PAT tables for MTL")
Signed-off-by: Fei Yang
Reviewed-by: Andrzej Hajda
Reviewed-by: Andi Shyti
Acked-by: Nirmoy Das
---
drivers/gpu/drm/i915/display/intel_dpt.c | 2 +-
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 45
drivers/gpu/drm/i915/gt/intel_ggtt.c | 36 +--
drivers/gpu/drm/i915/gt/intel_gtt.h | 12 +--
4 files changed, 82 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dpt.c
b/drivers/gpu/drm/i915/display/intel_dpt.c
index b8027392144d..c5eacfdba1a5 100644
--- a/drivers/gpu/drm/i915/display/intel_dpt.c
+++ b/drivers/gpu/drm/i915/display/intel_dpt.c
@@ -300,7 +300,7 @@ intel_dpt_create(struct intel_framebuffer *fb)
vm->vma_ops.bind_vma= dpt_bind_vma;
vm->vma_ops.unbind_vma = dpt_unbind_vma;
- vm->pte_encode = gen8_ggtt_pte_encode;
+ vm->pte_encode = vm->gt->ggtt->vm.pte_encode;
dpt->obj = dpt_obj;
dpt->obj->is_dpt = true;
diff --git a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
index 4daaa6f55668..4c9a2f2db908 100644
--- a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
@@ -55,6 +55,34 @@ static u64 gen8_pte_encode(dma_addr_t addr,
return pte;
}
+static u64 mtl_pte_encode(dma_addr_t addr,
+ enum i915_cache_level level,
+ u32 flags)
+{
+ gen8_pte_t pte = addr | GEN8_PAGE_PRESENT | GEN8_PAGE_RW;
+
+ if (unlikely(flags & PTE_READ_ONLY))
+ pte &= ~GEN8_PAGE_RW;
+
+ if (flags & PTE_LM)
+ pte |= GEN12_PPGTT_PTE_LM;
+
+ switch (level) {
+ case I915_CACHE_NONE:
+ pte |= GEN12_PPGTT_PTE_PAT1;
+ break;
+ case I915_CACHE_LLC:
+ case I915_CACHE_L3_LLC:
+ pte |= GEN12_PPGTT_PTE_PAT0 | GEN12_PPGTT_PTE_PAT1;
+ break;
+ case I915_CACHE_WT:
+ pte |= GEN12_PPGTT_PTE_PAT0;
+ break;
+ }
+
+ return pte;
+}
+
static void gen8_ppgtt_notify_vgt(struct i915_ppgtt *ppgtt, bool create)
{
struct drm_i915_private *i915 = ppgtt->vm.i915;
@@ -427,7 +455,7 @@ gen8_ppgtt_insert_pte(struct i915_ppgtt *ppgtt,
u32 flags)
{
struct i915_page_directory *pd;
- const gen8_pte_t pte_encode = gen8_pte_encode(0, cache_level, flags);
+ const gen8_pte_t pte_encode = ppgtt->vm.pte_encode(0, cache_level,
flags);
gen8_pte_t *vaddr;
pd = i915_pd_entry(pdp, gen8_pd_index(idx, 2));
@@ -580,7 +608,7 @@ static void gen8_ppgtt_insert_huge(struct
i915_address_space *vm,
enum i915_cache_level cache_level,
u32 flags)
{
- const gen8_pte_t pte_encode = gen8_pte_encode(0, cache_level, flags);
+ const gen8_pte_t pte_encode = vm->pte_encode(0, cache_level, flags);
unsigned int rem = sg_dma_len(iter->sg);
u64 start = vma_res->start;
@@ -743,7 +771,7 @@ static void gen8_ppgtt_insert_entry(struct
i915_address_space *vm,
GEM_BUG_ON(pt->is_compact);
vaddr = px_vaddr(pt);
- vaddr[gen8_pd_index(idx, 0)] = gen8_pte_encode(addr, level, flags);
+ vaddr[gen8_pd_index(idx, 0)] = vm->pte_encode(addr, level, flags);
drm_clflush_virt_range(&vaddr[gen8_pd_index(idx, 0)], sizeof(*vaddr));
}
@@ -773,7 +801,7 @@ static void __xehpsdv_ppgtt_insert_entry_lm(struct
i915_address_space *vm,
}
vaddr = px_vaddr(pt);
- vaddr[gen8_pd_index(idx, 0) / 16] = gen8_pte_encode(addr, level, flags);
+ vaddr[gen8_pd_index(idx, 0) / 16] = vm->pte_encode(addr, level, flags);
}
static void xehpsdv_ppgtt_insert_entry(struct i915_address_space *vm,
@@ -820,8 +848,8 @@ static int gen8_init_scratch(struct i915_address_space *vm)
pte_flags |= PTE_LM;
vm->scratch[0]->encode =
- gen8_pte_encode(px_dma(vm->scratch[0]),
- I915_CACHE_NONE, pte_flags);
+ vm->pte_encode(px_dma(vm->scratch[0]),
+ I915_CACHE_NONE, pte_flags);
for (i = 1; i <= vm->top; i++) {
struct drm_i915_gem_object *obj;
@@ -963,7 +991,10 @@ struct i915_ppgtt *gen8_ppgtt_create(struct intel_gt *gt,
*/
ppgtt->vm.alloc_scratch_dma = alloc_pt_dma;
- ppgtt->vm.pte_encode = gen8_pte_encode;
+ if (GRAPHICS_VER_FULL(gt->i915) >= IP_VER(12, 70))
+ ppgtt->vm.pte_encode = mtl_pte_encode;
+ else
+ ppgtt->vm.pte_encode = gen8_pte_encode;
ppgtt->vm.bind_async_flags = I915
[Intel-gfx] [PATCH v2 0/2] drm/i915/mtl: Add PTE encode functions
From: Fei Yang Extract PTE patch from https://patchwork.freedesktop.org/series/116868/ to fix MTL boot issue caused by MOCS/PAT update. v2: address comment from Matt. Fei Yang (2): drm/i915/mtl: Add PTE encode function drm/i915/mtl: workaround coherency issue for Media drivers/gpu/drm/i915/display/intel_dpt.c | 2 +- drivers/gpu/drm/i915/gem/i915_gem_pages.c | 5 ++- drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 45 +++ drivers/gpu/drm/i915/gt/intel_ggtt.c | 36 -- drivers/gpu/drm/i915/gt/intel_gtt.h | 12 +- drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c | 13 +++ drivers/gpu/drm/i915/gt/uc/intel_guc.c| 7 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 6 +++ 8 files changed, 112 insertions(+), 14 deletions(-) -- 2.25.1
[Intel-gfx] [PATCH v2 2/2] drm/i915/mtl: workaround coherency issue for Media
From: Fei Yang
This patch implements Wa_22016122933.
In MTL, memory writes initiated by the Media tile update the whole
cache line, even for partial writes. This creates a coherency
problem for cacheable memory if both CPU and GPU are writing data
to different locations within a single cache line.
This patch circumvents the issue by making CPU/GPU shared memory
uncacheable (WC on CPU side, and PAT index 2 for GPU). Additionally,
it ensures that CPU writes are visible to the GPU with an
intel_guc_write_barrier().
While fixing the CTB issue, we noticed some random GSC firmware
loading failure because the share buffers are cacheable (WB) on CPU
side but uncached on GPU side. To fix these issues we need to map
such shared buffers as WC on CPU side. Since such allocations are
not all done through GuC allocator, to avoid too many code changes,
the i915_coherent_map_type() is now hard coded to return WC for MTL.
v2: Simplify the commit message(Matt).
BSpec: 45101
Signed-off-by: Fei Yang
Reviewed-by: Andi Shyti
Acked-by: Nirmoy Das
Reviewed-by: Andrzej Hajda
Reviewed-by: Matt Roper
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 5 -
drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c | 13 +
drivers/gpu/drm/i915/gt/uc/intel_guc.c| 7 +++
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 6 ++
4 files changed, 30 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
index ecd86130b74f..89fc8ea6bcfc 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
@@ -469,7 +469,10 @@ enum i915_map_type i915_coherent_map_type(struct
drm_i915_private *i915,
struct drm_i915_gem_object *obj,
bool always_coherent)
{
- if (i915_gem_object_is_lmem(obj))
+ /*
+* Wa_22016122933: always return I915_MAP_WC for MTL
+*/
+ if (i915_gem_object_is_lmem(obj) || IS_METEORLAKE(i915))
return I915_MAP_WC;
if (HAS_LLC(i915) || always_coherent)
return I915_MAP_WB;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
index 1d9fdfb11268..236673c02f9a 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
@@ -110,6 +110,13 @@ static int gsc_fw_load_prepare(struct intel_gsc_uc *gsc)
if (obj->base.size < gsc->fw.size)
return -ENOSPC;
+ /*
+* Wa_22016122933: For MTL the shared memory needs to be mapped
+* as WC on CPU side and UC (PAT index 2) on GPU side
+*/
+ if (IS_METEORLAKE(i915))
+ i915_gem_object_set_cache_coherency(obj, I915_CACHE_NONE);
+
dst = i915_gem_object_pin_map_unlocked(obj,
i915_coherent_map_type(i915,
obj, true));
if (IS_ERR(dst))
@@ -125,6 +132,12 @@ static int gsc_fw_load_prepare(struct intel_gsc_uc *gsc)
memset(dst, 0, obj->base.size);
memcpy(dst, src, gsc->fw.size);
+ /*
+* Wa_22016122933: Making sure the data in dst is
+* visible to GSC right away
+*/
+ intel_guc_write_barrier(>->uc.guc);
+
i915_gem_object_unpin_map(gsc->fw.obj);
i915_gem_object_unpin_map(obj);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index e89f16ecf1ae..c9f20385f6a0 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -744,6 +744,13 @@ struct i915_vma *intel_guc_allocate_vma(struct intel_guc
*guc, u32 size)
if (IS_ERR(obj))
return ERR_CAST(obj);
+ /*
+* Wa_22016122933: For MTL the shared memory needs to be mapped
+* as WC on CPU side and UC (PAT index 2) on GPU side
+*/
+ if (IS_METEORLAKE(gt->i915))
+ i915_gem_object_set_cache_coherency(obj, I915_CACHE_NONE);
+
vma = i915_vma_instance(obj, >->ggtt->vm, NULL);
if (IS_ERR(vma))
goto err;
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 1803a633ed64..99a0a89091e7 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -902,6 +902,12 @@ static int ct_read(struct intel_guc_ct *ct, struct
ct_incoming_msg **msg)
/* now update descriptor */
WRITE_ONCE(desc->head, head);
+ /*
+* Wa_22016122933: Making sure the head update is
+* visible to GuC right away
+*/
+ intel_guc_write_barrier(ct_to_guc(ct));
+
return available - len;
corrupted:
--
2.25.1
Re: [Intel-gfx] [PATCH] drm/i915/dsi: Always use unconditional msleep() for the panel_on_delay
On Sat, Apr 22, 2023 at 08:43:59PM +0200, Hans de Goede wrote:
> The intel_dsi_msleep() helper skips sleeping if the MIPI-sequences have
> a version of 3 or newer and the panel is in vid-mode.
>
> This is based on the big comment around line 730 which starts with
> "Panel enable/disable sequences from the VBT spec.", where
> the "v3 video mode seq" column does not have any wait t# entries.
>
> Commit 6fdb335f1c9c ("drm/i915/dsi: Use unconditional msleep for
> the panel_on_delay when there is no reset-deassert MIPI-sequence")
> switched to a direct msleep() instead of intel_dsi_msleep()
> when there is no MIPI_SEQ_DEASSERT_RESET sequence, to fix
> the panel on an Acer Aspire Switch 10 E SW3-016 not turning on.
>
> This was done under the assumption that when there is a v3
> MIPI_SEQ_DEASSERT_RESET sequence it will take care of any
> necessary delays.
>
> On the Nextbook Ares 8A (a Cherry Trail device like the Acer SW3-016)
> there is a MIPI_SEQ_DEASSERT_RESET sequence, yet panel_on_delay
> must still be honored otherwise the panel will not turn on.
>
> Switch to always using an unconditional msleep() for
> the panel_on_delay instead of making this depend on
> the presence of a MIPI_SEQ_DEASSERT_RESET sequence.
I just checked what Windows does, and at least for icl+ it
always waits for the panel power delays regardless of what
the VBT MIPI sequences are doing.
So I suspect we should just get rid of intel_dsi_msleep()
entirely and do what the power sequencing delays tell us.
Anything else is untested territory. If the VBT actually
wanted us to skip the delays then it should really be
setting them to zero.
>
> Fixes: 6fdb335f1c9c ("drm/i915/dsi: Use unconditional msleep for the
> panel_on_delay when there is no reset-deassert MIPI-sequence")
> Signed-off-by: Hans de Goede
> ---
> drivers/gpu/drm/i915/display/vlv_dsi.c | 18 +++---
> 1 file changed, 3 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/vlv_dsi.c
> b/drivers/gpu/drm/i915/display/vlv_dsi.c
> index a6d6d8b33f3f..1b87f8f5f7fd 100644
> --- a/drivers/gpu/drm/i915/display/vlv_dsi.c
> +++ b/drivers/gpu/drm/i915/display/vlv_dsi.c
> @@ -788,7 +788,6 @@ static void intel_dsi_pre_enable(struct
> intel_atomic_state *state,
> {
> struct intel_dsi *intel_dsi = enc_to_intel_dsi(encoder);
> struct intel_crtc *crtc = to_intel_crtc(pipe_config->uapi.crtc);
> - struct intel_connector *connector =
> to_intel_connector(conn_state->connector);
> struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> enum pipe pipe = crtc->pipe;
> enum port port;
> @@ -836,21 +835,10 @@ static void intel_dsi_pre_enable(struct
> intel_atomic_state *state,
> if (!IS_GEMINILAKE(dev_priv))
> intel_dsi_prepare(encoder, pipe_config);
>
> + /* Give the panel time to power-on and then deassert its reset */
> intel_dsi_vbt_exec_sequence(intel_dsi, MIPI_SEQ_POWER_ON);
> -
> - /*
> - * Give the panel time to power-on and then deassert its reset.
> - * Depending on the VBT MIPI sequences version the deassert-seq
> - * may contain the necessary delay, intel_dsi_msleep() will skip
> - * the delay in that case. If there is no deassert-seq, then an
> - * unconditional msleep is used to give the panel time to power-on.
> - */
> - if (connector->panel.vbt.dsi.sequence[MIPI_SEQ_DEASSERT_RESET]) {
> - intel_dsi_msleep(intel_dsi, intel_dsi->panel_on_delay);
> - intel_dsi_vbt_exec_sequence(intel_dsi, MIPI_SEQ_DEASSERT_RESET);
> - } else {
> - msleep(intel_dsi->panel_on_delay);
> - }
> + msleep(intel_dsi->panel_on_delay);
> + intel_dsi_vbt_exec_sequence(intel_dsi, MIPI_SEQ_DEASSERT_RESET);
>
> if (IS_GEMINILAKE(dev_priv)) {
> glk_cold_boot = glk_dsi_enable_io(encoder);
> --
> 2.39.2
--
Ville Syrjälä
Intel
Re: [Intel-gfx] [PATCH 3/8] drm/i915/mtl: Add PTE encode function
> On Sun, Apr 23, 2023 at 12:37:27AM -0700, Yang, Fei wrote:
>>> On Fri, Apr 21, 2023 at 10:27:22AM -0700, Yang, Fei wrote:
> On Wed, Apr 19, 2023 at 04:00:53PM -0700, fei.y...@intel.com wrote:
>> From: Fei Yang
>>
>> PTE encode functions are platform dependent. This patch implements
>> PTE functions for MTL, and ensures the correct PTE encode function
>> is used by calling pte_encode function pointer instead of the
>> hardcoded gen8 version of PTE encode.
>>
>> Signed-off-by: Fei Yang
>> Reviewed-by: Andrzej Hajda
>> Reviewed-by: Andi Shyti
>> Acked-by: Nirmoy Das
>
> Bspec: 45015, 45040
>
>> ---
>> drivers/gpu/drm/i915/display/intel_dpt.c | 2 +-
>> drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 45
>> drivers/gpu/drm/i915/gt/intel_ggtt.c | 36 +--
>> 3 files changed, 72 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_dpt.c
b/drivers/gpu/drm/i915/display/intel_dpt.c
>> index b8027392144d..c5eacfdba1a5 100644
>> --- a/drivers/gpu/drm/i915/display/intel_dpt.c
>> +++ b/drivers/gpu/drm/i915/display/intel_dpt.c
>> @@ -300,7 +300,7 @@ intel_dpt_create(struct intel_framebuffer *fb)
>>vm->vma_ops.bind_vma= dpt_bind_vma;
>>vm->vma_ops.unbind_vma = dpt_unbind_vma;
>>
>> - vm->pte_encode = gen8_ggtt_pte_encode;
>> + vm->pte_encode = vm->gt->ggtt->vm.pte_encode;
>>
>>dpt->obj = dpt_obj;
>>dpt->obj->is_dpt = true;
>> diff --git a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
>> b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
>> index 4daaa6f55668..11b91e0453c8 100644
>> --- a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
>> +++ b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
>> @@ -55,6 +55,34 @@ static u64 gen8_pte_encode(dma_addr_t addr,
>>return pte;
>> }
>>
>> +static u64 mtl_pte_encode(dma_addr_t addr,
>> + enum i915_cache_level level,
>> + u32 flags)
>> +{
>> + gen8_pte_t pte = addr | GEN8_PAGE_PRESENT | GEN8_PAGE_RW;
>> +
>> + if (unlikely(flags & PTE_READ_ONLY))
>> + pte &= ~GEN8_PAGE_RW;
>> +
>> + if (flags & PTE_LM)
>> + pte |= GEN12_PPGTT_PTE_LM | GEN12_PPGTT_PTE_NC;
>
> GEN12_PPGTT_PTE_NC got defined in the previous patch as BIT(5). But
> according to bspec 45040, bit 5 is ignored in the PTE encoding. What is
> this trying to do?
This takes effect only for PTE_LM, doesn't affect MTL.
PTE_NC is needed for PVC (use of access counter).
I believe this function was writen based on the one for PVC. And this
function did get extended to cover all gen12 in a later patch.
>>>
>>> Even though MTL doesn't have local memory, PTE_LM is supposed to be
>>> used on MTL for access to BAR2 stolen memory.
>>
>> You were right, but I still think this code is fine because this bit is
>> ignored for MTL anyway and it is needed for other platforms with LMEM.
>> Otherwise this code would have some sort of platform checking which is
>> hard to do because we don't have platform info here.
>> Or we would have to define another PTE encode function for platforms
>> needing PTE_NC just for this one difference, then manage the function
>> pointer correctly.
>
> MTL is the only platform that uses this function right now:
>
> + if (GRAPHICS_VER_FULL(gt->i915) >= IP_VER(12, 70))
> + ppgtt->vm.pte_encode = mtl_pte_encode;
> + else
> + ppgtt->vm.pte_encode = gen8_pte_encode;
>
> If this is intended for PVC, then you have it in the wrong function to
> begin with (and it also shouldn't be in a patch labelled "mtl"). If
> you're trying to future-proof for some post-MTL discrete platform, then
> such code should be saved until we enable that platform so that it can
> be properly reviewed.
dropped GEN12_PPGTT_PTE_NC bit in v2 of
https://patchwork.freedesktop.org/series/116900/
> Matt
>
>>
>> -Fei
>>
>>> Matt
>>>
-Fei
> Matt
>
>> +
>> + switch (level) {
>> + case I915_CACHE_NONE:
>> + pte |= GEN12_PPGTT_PTE_PAT1;
>> + break;
Re: [Intel-gfx] [PATCH] drm/i915/dsi: Always use unconditional msleep() for the panel_on_delay
Hi Ville,
On 4/24/23 20:34, Ville Syrjälä wrote:
> On Sat, Apr 22, 2023 at 08:43:59PM +0200, Hans de Goede wrote:
>> The intel_dsi_msleep() helper skips sleeping if the MIPI-sequences have
>> a version of 3 or newer and the panel is in vid-mode.
>>
>> This is based on the big comment around line 730 which starts with
>> "Panel enable/disable sequences from the VBT spec.", where
>> the "v3 video mode seq" column does not have any wait t# entries.
>>
>> Commit 6fdb335f1c9c ("drm/i915/dsi: Use unconditional msleep for
>> the panel_on_delay when there is no reset-deassert MIPI-sequence")
>> switched to a direct msleep() instead of intel_dsi_msleep()
>> when there is no MIPI_SEQ_DEASSERT_RESET sequence, to fix
>> the panel on an Acer Aspire Switch 10 E SW3-016 not turning on.
>>
>> This was done under the assumption that when there is a v3
>> MIPI_SEQ_DEASSERT_RESET sequence it will take care of any
>> necessary delays.
>>
>> On the Nextbook Ares 8A (a Cherry Trail device like the Acer SW3-016)
>> there is a MIPI_SEQ_DEASSERT_RESET sequence, yet panel_on_delay
>> must still be honored otherwise the panel will not turn on.
>>
>> Switch to always using an unconditional msleep() for
>> the panel_on_delay instead of making this depend on
>> the presence of a MIPI_SEQ_DEASSERT_RESET sequence.
>
> I just checked what Windows does, and at least for icl+ it
> always waits for the panel power delays regardless of what
> the VBT MIPI sequences are doing.
>
> So I suspect we should just get rid of intel_dsi_msleep()
> entirely and do what the power sequencing delays tell us.
> Anything else is untested territory. If the VBT actually
> wanted us to skip the delays then it should really be
> setting them to zero.
So I checked and there are only 4 (before this patch) /
3 (after this patch) callers of intel_dsi_msleep().
So just getting rid of it entirely sounds good to me.
Shall I prepare a v2 patch which does this ?
Regards,
Hans
>> Fixes: 6fdb335f1c9c ("drm/i915/dsi: Use unconditional msleep for the
>> panel_on_delay when there is no reset-deassert MIPI-sequence")
>> Signed-off-by: Hans de Goede
>> ---
>> drivers/gpu/drm/i915/display/vlv_dsi.c | 18 +++---
>> 1 file changed, 3 insertions(+), 15 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/vlv_dsi.c
>> b/drivers/gpu/drm/i915/display/vlv_dsi.c
>> index a6d6d8b33f3f..1b87f8f5f7fd 100644
>> --- a/drivers/gpu/drm/i915/display/vlv_dsi.c
>> +++ b/drivers/gpu/drm/i915/display/vlv_dsi.c
>> @@ -788,7 +788,6 @@ static void intel_dsi_pre_enable(struct
>> intel_atomic_state *state,
>> {
>> struct intel_dsi *intel_dsi = enc_to_intel_dsi(encoder);
>> struct intel_crtc *crtc = to_intel_crtc(pipe_config->uapi.crtc);
>> -struct intel_connector *connector =
>> to_intel_connector(conn_state->connector);
>> struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>> enum pipe pipe = crtc->pipe;
>> enum port port;
>> @@ -836,21 +835,10 @@ static void intel_dsi_pre_enable(struct
>> intel_atomic_state *state,
>> if (!IS_GEMINILAKE(dev_priv))
>> intel_dsi_prepare(encoder, pipe_config);
>>
>> +/* Give the panel time to power-on and then deassert its reset */
>> intel_dsi_vbt_exec_sequence(intel_dsi, MIPI_SEQ_POWER_ON);
>> -
>> -/*
>> - * Give the panel time to power-on and then deassert its reset.
>> - * Depending on the VBT MIPI sequences version the deassert-seq
>> - * may contain the necessary delay, intel_dsi_msleep() will skip
>> - * the delay in that case. If there is no deassert-seq, then an
>> - * unconditional msleep is used to give the panel time to power-on.
>> - */
>> -if (connector->panel.vbt.dsi.sequence[MIPI_SEQ_DEASSERT_RESET]) {
>> -intel_dsi_msleep(intel_dsi, intel_dsi->panel_on_delay);
>> -intel_dsi_vbt_exec_sequence(intel_dsi, MIPI_SEQ_DEASSERT_RESET);
>> -} else {
>> -msleep(intel_dsi->panel_on_delay);
>> -}
>> +msleep(intel_dsi->panel_on_delay);
>> +intel_dsi_vbt_exec_sequence(intel_dsi, MIPI_SEQ_DEASSERT_RESET);
>>
>> if (IS_GEMINILAKE(dev_priv)) {
>> glk_cold_boot = glk_dsi_enable_io(encoder);
>> --
>> 2.39.2
>
Re: [Intel-gfx] [PATCH] drm/i915/dsi: Always use unconditional msleep() for the panel_on_delay
On Mon, Apr 24, 2023 at 08:54:27PM +0200, Hans de Goede wrote:
> Hi Ville,
>
> On 4/24/23 20:34, Ville Syrjälä wrote:
> > On Sat, Apr 22, 2023 at 08:43:59PM +0200, Hans de Goede wrote:
> >> The intel_dsi_msleep() helper skips sleeping if the MIPI-sequences have
> >> a version of 3 or newer and the panel is in vid-mode.
> >>
> >> This is based on the big comment around line 730 which starts with
> >> "Panel enable/disable sequences from the VBT spec.", where
> >> the "v3 video mode seq" column does not have any wait t# entries.
> >>
> >> Commit 6fdb335f1c9c ("drm/i915/dsi: Use unconditional msleep for
> >> the panel_on_delay when there is no reset-deassert MIPI-sequence")
> >> switched to a direct msleep() instead of intel_dsi_msleep()
> >> when there is no MIPI_SEQ_DEASSERT_RESET sequence, to fix
> >> the panel on an Acer Aspire Switch 10 E SW3-016 not turning on.
> >>
> >> This was done under the assumption that when there is a v3
> >> MIPI_SEQ_DEASSERT_RESET sequence it will take care of any
> >> necessary delays.
> >>
> >> On the Nextbook Ares 8A (a Cherry Trail device like the Acer SW3-016)
> >> there is a MIPI_SEQ_DEASSERT_RESET sequence, yet panel_on_delay
> >> must still be honored otherwise the panel will not turn on.
> >>
> >> Switch to always using an unconditional msleep() for
> >> the panel_on_delay instead of making this depend on
> >> the presence of a MIPI_SEQ_DEASSERT_RESET sequence.
> >
> > I just checked what Windows does, and at least for icl+ it
> > always waits for the panel power delays regardless of what
> > the VBT MIPI sequences are doing.
> >
> > So I suspect we should just get rid of intel_dsi_msleep()
> > entirely and do what the power sequencing delays tell us.
> > Anything else is untested territory. If the VBT actually
> > wanted us to skip the delays then it should really be
> > setting them to zero.
>
> So I checked and there are only 4 (before this patch) /
> 3 (after this patch) callers of intel_dsi_msleep().
>
> So just getting rid of it entirely sounds good to me.
>
> Shall I prepare a v2 patch which does this ?
Please do.
>
> Regards,
>
> Hans
>
>
>
>
>
> >> Fixes: 6fdb335f1c9c ("drm/i915/dsi: Use unconditional msleep for the
> >> panel_on_delay when there is no reset-deassert MIPI-sequence")
> >> Signed-off-by: Hans de Goede
> >> ---
> >> drivers/gpu/drm/i915/display/vlv_dsi.c | 18 +++---
> >> 1 file changed, 3 insertions(+), 15 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/display/vlv_dsi.c
> >> b/drivers/gpu/drm/i915/display/vlv_dsi.c
> >> index a6d6d8b33f3f..1b87f8f5f7fd 100644
> >> --- a/drivers/gpu/drm/i915/display/vlv_dsi.c
> >> +++ b/drivers/gpu/drm/i915/display/vlv_dsi.c
> >> @@ -788,7 +788,6 @@ static void intel_dsi_pre_enable(struct
> >> intel_atomic_state *state,
> >> {
> >>struct intel_dsi *intel_dsi = enc_to_intel_dsi(encoder);
> >>struct intel_crtc *crtc = to_intel_crtc(pipe_config->uapi.crtc);
> >> - struct intel_connector *connector =
> >> to_intel_connector(conn_state->connector);
> >>struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> >>enum pipe pipe = crtc->pipe;
> >>enum port port;
> >> @@ -836,21 +835,10 @@ static void intel_dsi_pre_enable(struct
> >> intel_atomic_state *state,
> >>if (!IS_GEMINILAKE(dev_priv))
> >>intel_dsi_prepare(encoder, pipe_config);
> >>
> >> + /* Give the panel time to power-on and then deassert its reset */
> >>intel_dsi_vbt_exec_sequence(intel_dsi, MIPI_SEQ_POWER_ON);
> >> -
> >> - /*
> >> - * Give the panel time to power-on and then deassert its reset.
> >> - * Depending on the VBT MIPI sequences version the deassert-seq
> >> - * may contain the necessary delay, intel_dsi_msleep() will skip
> >> - * the delay in that case. If there is no deassert-seq, then an
> >> - * unconditional msleep is used to give the panel time to power-on.
> >> - */
> >> - if (connector->panel.vbt.dsi.sequence[MIPI_SEQ_DEASSERT_RESET]) {
> >> - intel_dsi_msleep(intel_dsi, intel_dsi->panel_on_delay);
> >> - intel_dsi_vbt_exec_sequence(intel_dsi, MIPI_SEQ_DEASSERT_RESET);
> >> - } else {
> >> - msleep(intel_dsi->panel_on_delay);
> >> - }
> >> + msleep(intel_dsi->panel_on_delay);
> >> + intel_dsi_vbt_exec_sequence(intel_dsi, MIPI_SEQ_DEASSERT_RESET);
> >>
> >>if (IS_GEMINILAKE(dev_priv)) {
> >>glk_cold_boot = glk_dsi_enable_io(encoder);
> >> --
> >> 2.39.2
> >
--
Ville Syrjälä
Intel
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/mtl: Add workaround 14018778641 (rev2)
== Series Details ==
Series: drm/i915/mtl: Add workaround 14018778641 (rev2)
URL : https://patchwork.freedesktop.org/series/116750/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13054 -> Patchwork_116750v2
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116750v2/index.html
Participating hosts (38 -> 36)
--
Additional (1): fi-kbl-soraka
Missing(3): bat-jsl-1 fi-snb-2520m fi-bsw-n3050
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_116750v2:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_module_load@load:
- {bat-mtlp-8}: [ABORT][1] ([i915#8361]) -> [ABORT][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13054/bat-mtlp-8/igt@i915_module_l...@load.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116750v2/bat-mtlp-8/igt@i915_module_l...@load.html
Known issues
Here are the changes found in Patchwork_116750v2 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_huc_copy@huc-copy:
- fi-kbl-soraka: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#2190])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116750v2/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@basic:
- fi-kbl-soraka: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#4613]) +3
similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116750v2/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html
* igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][5] ([i915#1886])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116750v2/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html
* igt@kms_chamelium_frames@hdmi-crc-fast:
- fi-kbl-soraka: NOTRUN -> [SKIP][6] ([fdo#109271]) +16 similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116750v2/fi-kbl-soraka/igt@kms_chamelium_fra...@hdmi-crc-fast.html
Possible fixes
* igt@i915_selftest@live@migrate:
- bat-adlp-6: [DMESG-FAIL][7] ([i915#7699]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13054/bat-adlp-6/igt@i915_selftest@l...@migrate.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116750v2/bat-adlp-6/igt@i915_selftest@l...@migrate.html
* igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence@pipe-d-dp-1:
- bat-dg2-8: [FAIL][9] ([i915#7932]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13054/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-crc-frame-seque...@pipe-d-dp-1.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116750v2/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-crc-frame-seque...@pipe-d-dp-1.html
Warnings
* igt@i915_selftest@live@requests:
- bat-rpls-1: [ABORT][11] ([i915#4983] / [i915#7911]) ->
[ABORT][12] ([i915#7911])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13054/bat-rpls-1/igt@i915_selftest@l...@requests.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116750v2/bat-rpls-1/igt@i915_selftest@l...@requests.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#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#7699]: https://gitlab.freedesktop.org/drm/intel/issues/7699
[i915#7911]: https://gitlab.freedesktop.org/drm/intel/issues/7911
[i915#7932]: https://gitlab.freedesktop.org/drm/intel/issues/7932
[i915#8361]: https://gitlab.freedesktop.org/drm/intel/issues/8361
Build changes
-
* Linux: CI_DRM_13054 -> Patchwork_116750v2
CI-20190529: 20190529
CI_DRM_13054: 8cabe2adb8e028197f9535daffd3d5ff98d51d8b @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7266: 94411dd85f9ad6d76fb7b2097197122703a3914c @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_116750v2: 8cabe2adb8e028197f9535daffd3d5ff98d51d8b @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
94266cda9f25 drm/i915/mtl: Add workaround 14018778641
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116750v2/index.html
Re: [Intel-gfx] [PATCH 0/8] drm/i915/mtl: Define MOCS and PAT tables for MTL
On 2023-04-16 23:43:20, Yang, Fei wrote: > > fei.y...@intel.com kirjoitti 17.4.2023 klo 9.24: > >> From: Fei Yang > >> > >> The series includes patches needed to enable MTL. > >> Also add new extension for GEM_CREATE uAPI to let user space set cache > >> policy for buffer objects. > > > > if I'm counting right, this would be version 5 of the series, yet > > that is not shown anywhere nor the changes between series.. > > Yes, mostly addressing minor issues, just want to keep the commit > message clean as it's the enablement patch set for new platform. One thing that could help is to use the --subject-prefix parameter to git format-patch so "PATCH v5" would be in the subject of the emails. Additionally, it's helpful to include full a version history in the cover-letter (0/8) patch so it's clear what has changed in each version of the patches sent out. -Jordan
[Intel-gfx] [PATCH] drm/i915/adlp+: Disable DC5/6 states for TC port DDI/AUX and for combo port AUX
On ADLP+ Bspec allows DC5/6 to be enabled while power well 2 is enabled.
Since the AUX and DDI power wells (except for port A/B) are also backed
by power well 2, this would suggest that DC5/6 can be enabled while any
of these AUX or DDI port functionalities are used. As opposed to this
AUX transfers will time out on ADLP TypeC ports while DC6 is enabled.
Until the restriction for DC5/6 is clarified in Bspec let's assume that
the intention is to allow for using these power states while pipe A/B is
enabled, but only for combo ports which can be used with eDP outputs.
Similarly assume that AUX transaction initiated by the driver on any port
requires DC states to be disabled.
Cc: Matt Roper
Cc: Radhakrishna Sripada
Fixes: 88c487938414 ("drm/i915: Use separate "DC off" power well for ADL-P and
DG2")
Signed-off-by: Imre Deak
---
.../i915/display/intel_display_power_map.c| 28 +++
1 file changed, 16 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_power_map.c
b/drivers/gpu/drm/i915/display/intel_display_power_map.c
index 100582f105905..ca448359a8226 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power_map.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power_map.c
@@ -1251,22 +1251,11 @@ I915_DECL_PW_DOMAINS(xelpd_pwdoms_pw_a,
POWER_DOMAIN_PIPE_PANEL_FITTER_A,
POWER_DOMAIN_INIT);
-#define XELPD_PW_2_POWER_DOMAINS \
- XELPD_PW_B_POWER_DOMAINS, \
- XELPD_PW_C_POWER_DOMAINS, \
- XELPD_PW_D_POWER_DOMAINS, \
- POWER_DOMAIN_PORT_DDI_LANES_C, \
- POWER_DOMAIN_PORT_DDI_LANES_D, \
- POWER_DOMAIN_PORT_DDI_LANES_E, \
+#define XELPD_DC_OFF_PORT_POWER_DOMAINS \
POWER_DOMAIN_PORT_DDI_LANES_TC1, \
POWER_DOMAIN_PORT_DDI_LANES_TC2, \
POWER_DOMAIN_PORT_DDI_LANES_TC3, \
POWER_DOMAIN_PORT_DDI_LANES_TC4, \
- POWER_DOMAIN_VGA, \
- POWER_DOMAIN_AUDIO_PLAYBACK, \
- POWER_DOMAIN_AUX_IO_C, \
- POWER_DOMAIN_AUX_IO_D, \
- POWER_DOMAIN_AUX_IO_E, \
POWER_DOMAIN_AUX_C, \
POWER_DOMAIN_AUX_D, \
POWER_DOMAIN_AUX_E, \
@@ -1279,6 +1268,20 @@ I915_DECL_PW_DOMAINS(xelpd_pwdoms_pw_a,
POWER_DOMAIN_AUX_TBT3, \
POWER_DOMAIN_AUX_TBT4
+#define XELPD_PW_2_POWER_DOMAINS \
+ XELPD_PW_B_POWER_DOMAINS, \
+ XELPD_PW_C_POWER_DOMAINS, \
+ XELPD_PW_D_POWER_DOMAINS, \
+ POWER_DOMAIN_PORT_DDI_LANES_C, \
+ POWER_DOMAIN_PORT_DDI_LANES_D, \
+ POWER_DOMAIN_PORT_DDI_LANES_E, \
+ POWER_DOMAIN_VGA, \
+ POWER_DOMAIN_AUDIO_PLAYBACK, \
+ POWER_DOMAIN_AUX_IO_C, \
+ POWER_DOMAIN_AUX_IO_D, \
+ POWER_DOMAIN_AUX_IO_E, \
+ XELPD_DC_OFF_PORT_POWER_DOMAINS
+
I915_DECL_PW_DOMAINS(xelpd_pwdoms_pw_2,
XELPD_PW_2_POWER_DOMAINS,
POWER_DOMAIN_INIT);
@@ -1301,6 +1304,7 @@ I915_DECL_PW_DOMAINS(xelpd_pwdoms_pw_2,
*/
I915_DECL_PW_DOMAINS(xelpd_pwdoms_dc_off,
+ XELPD_DC_OFF_PORT_POWER_DOMAINS,
XELPD_PW_C_POWER_DOMAINS,
XELPD_PW_D_POWER_DOMAINS,
POWER_DOMAIN_PORT_DSI,
--
2.37.2
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for x86/mm: Fix PAT bit missing from page protection modify mask
== Series Details == Series: x86/mm: Fix PAT bit missing from page protection modify mask URL : https://patchwork.freedesktop.org/series/116883/ State : warning == Summary == Error: dim checkpatch failed 43584c6560ff x86/mm: Fix PAT bit missing from page protection modify mask -:50: WARNING:COMMIT_LOG_USE_LINK: Unknown link reference 'Closes:', use 'Link:' instead #50: Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/7648 total: 0 errors, 1 warnings, 0 checks, 12 lines checked
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for x86/mm: Fix PAT bit missing from page protection modify mask
== Series Details == Series: x86/mm: Fix PAT bit missing from page protection modify mask URL : https://patchwork.freedesktop.org/series/116883/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✓ Fi.CI.BAT: success for x86/mm: Fix PAT bit missing from page protection modify mask
== Series Details == Series: x86/mm: Fix PAT bit missing from page protection modify mask URL : https://patchwork.freedesktop.org/series/116883/ State : success == Summary == CI Bug Log - changes from CI_DRM_13054 -> Patchwork_116883v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116883v1/index.html Participating hosts (38 -> 37) -- Missing(1): fi-snb-2520m Known issues Here are the changes found in Patchwork_116883v1 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s3@smem: - bat-rpls-1: NOTRUN -> [ABORT][1] ([i915#6687] / [i915#7978]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116883v1/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html * igt@i915_selftest@live@hangcheck: - bat-dg2-8: [PASS][2] -> [ABORT][3] ([i915#7913] / [i915#7979]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13054/bat-dg2-8/igt@i915_selftest@l...@hangcheck.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116883v1/bat-dg2-8/igt@i915_selftest@l...@hangcheck.html * igt@i915_selftest@live@slpc: - bat-rpls-1: NOTRUN -> [DMESG-FAIL][4] ([i915#6367]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116883v1/bat-rpls-1/igt@i915_selftest@l...@slpc.html * igt@kms_pipe_crc_basic@nonblocking-crc@pipe-d-dp-1: - bat-dg2-8: [PASS][5] -> [FAIL][6] ([i915#7932]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13054/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-...@pipe-d-dp-1.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116883v1/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-...@pipe-d-dp-1.html Possible fixes * igt@i915_selftest@live@migrate: - bat-adlp-6: [DMESG-FAIL][7] ([i915#7699]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13054/bat-adlp-6/igt@i915_selftest@l...@migrate.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116883v1/bat-adlp-6/igt@i915_selftest@l...@migrate.html * igt@i915_selftest@live@requests: - bat-rpls-1: [ABORT][9] ([i915#4983] / [i915#7911]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13054/bat-rpls-1/igt@i915_selftest@l...@requests.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116883v1/bat-rpls-1/igt@i915_selftest@l...@requests.html * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence@pipe-d-dp-1: - bat-dg2-8: [FAIL][11] ([i915#7932]) -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13054/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-crc-frame-seque...@pipe-d-dp-1.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116883v1/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-crc-frame-seque...@pipe-d-dp-1.html [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983 [i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367 [i915#6687]: https://gitlab.freedesktop.org/drm/intel/issues/6687 [i915#7699]: https://gitlab.freedesktop.org/drm/intel/issues/7699 [i915#7911]: https://gitlab.freedesktop.org/drm/intel/issues/7911 [i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913 [i915#7932]: https://gitlab.freedesktop.org/drm/intel/issues/7932 [i915#7978]: https://gitlab.freedesktop.org/drm/intel/issues/7978 [i915#7979]: https://gitlab.freedesktop.org/drm/intel/issues/7979 Build changes - * Linux: CI_DRM_13054 -> Patchwork_116883v1 CI-20190529: 20190529 CI_DRM_13054: 8cabe2adb8e028197f9535daffd3d5ff98d51d8b @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7266: 94411dd85f9ad6d76fb7b2097197122703a3914c @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_116883v1: 8cabe2adb8e028197f9535daffd3d5ff98d51d8b @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits 51783673cfcd x86/mm: Fix PAT bit missing from page protection modify mask == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116883v1/index.html
Re: [Intel-gfx] [PATCH 02/13] drm/i915/mtl: C20 HW readout
On Thu, Apr 20, 2023 at 03:40:39PM +0300, Mika Kahola wrote:
> Create a table for C20 DP1.4, DP2.0 and HDMI2.1 rates.
> The PLL settings are based on table, not for algorithmic alternative.
> For DP 1.4 only MPLLB is in use.
>
> Once register settings are done, we read back C20 HW state.
>
> BSpec: 64568
>
> Signed-off-by: Mika Kahola
> Signed-off-by: Arun R Murthy
> Signed-off-by: Ankit Nautiyal
> ---
> drivers/gpu/drm/i915/display/intel_cx0_phy.c | 623 +-
> drivers/gpu/drm/i915/display/intel_cx0_phy.h | 8 +-
> drivers/gpu/drm/i915/display/intel_ddi.c | 9 +-
> .../drm/i915/display/intel_display_types.h| 1 +
> drivers/gpu/drm/i915/display/intel_hdmi.c | 6 +-
> drivers/gpu/drm/i915/display/intel_hdmi.h | 1 +
> 6 files changed, 628 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> index dd96bf5e179e..61428c5145e5 100644
> --- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> @@ -11,6 +11,7 @@
> #include "intel_de.h"
> #include "intel_display_types.h"
> #include "intel_dp.h"
> +#include "intel_hdmi.h"
> #include "intel_panel.h"
> #include "intel_psr.h"
> #include "intel_tc.h"
> @@ -285,6 +286,23 @@ static void intel_c20_sram_write(struct drm_i915_private
> *i915, enum port port,
> intel_cx0_write(i915, port, lane, PHY_C20_WR_DATA_L, data & 0xff, 1);
> }
>
> +static u16 intel_c20_sram_read(struct drm_i915_private *i915, enum port port,
> +int lane, u16 addr)
> +{
> + u16 val;
> +
> + assert_dc_off(i915);
> +
> + intel_cx0_write(i915, port, lane, PHY_C20_RD_ADDRESS_H, addr >> 8, 0);
> + intel_cx0_write(i915, port, lane, PHY_C20_RD_ADDRESS_L, addr & 0xff, 1);
> +
> + val = intel_cx0_read(i915, port, lane, PHY_C20_RD_DATA_H);
> + val <<= 8;
> + val |= intel_cx0_read(i915, port, lane, PHY_C20_RD_DATA_L);
> +
> + return val;
> +}
> +
> static void __intel_cx0_rmw(struct drm_i915_private *i915, enum port port,
> int lane, u16 addr, u8 clear, u8 set, bool
> committed)
> {
> @@ -659,6 +677,199 @@ static const struct intel_c10pll_state * const
> mtl_c10_edp_tables[] = {
> NULL,
> };
>
> +/* C20 basic DP 1.4 tables */
> +static const struct intel_c20pll_state mtl_c20_dp_rbr = {
> + .link_bit_rate = 162000,
> + .clock = 162000,
> + .tx = { 0xbe88, /* tx cfg0 */
> + 0x5800, /* tx cfg1 */
> + 0x, /* tx cfg2 */
> + },
> + .cmn = {0x0500, /* cmn cfg0*/
> + 0x0005, /* cmn cfg1 */
> + 0x, /* cmn cfg2 */
> + 0x, /* cmn cfg3 */
> + },
> + .mpllb = { 0x50a8, /* mpllb cfg0 */
> + 0x2120, /* mpllb cfg1 */
> + 0xcd9a, /* mpllb cfg2 */
> + 0xbfc1, /* mpllb cfg3 */
> + 0x5ab8, /* mpllb cfg4 */
> + 0x4c34, /* mpllb cfg5 */
> + 0x2000, /* mpllb cfg6 */
> + 0x0001, /* mpllb cfg7 */
> + 0x6000, /* mpllb cfg8 */
> + 0x, /* mpllb cfg9 */
> + 0x, /* mpllb cfg10 */
> + },
> +};
> +
> +static const struct intel_c20pll_state mtl_c20_dp_hbr1 = {
> + .link_bit_rate = 27,
> + .clock = 27,
> + .tx = { 0xbe88, /* tx cfg0 */
> + 0x4800, /* tx cfg1 */
> + 0x, /* tx cfg2 */
> + },
> + .cmn = {0x0500, /* cmn cfg0*/
> + 0x0005, /* cmn cfg1 */
> + 0x, /* cmn cfg2 */
> + 0x, /* cmn cfg3 */
> + },
> + .mpllb = { 0x308c, /* mpllb cfg0 */
> + 0x2110, /* mpllb cfg1 */
> + 0xcc9c, /* mpllb cfg2 */
> + 0xbfc1, /* mpllb cfg3 */
> + 0x489a, /* mpllb cfg4 */
This should be 0x4b9a ^ for mpllb cfg4 according to the consolidated table.
> + 0x3f81, /* mpllb cfg5 */
> + 0x2000, /* mpllb cfg6 */
> + 0x0001, /* mpllb cfg7 */
> + 0x5000, /* mpllb cfg8 */
> + 0x, /* mpllb cfg9 */
> + 0x, /* mpllb cfg10 */
> + },
> +};
> +
> +static const struct intel_c20pll_state mtl_c20_dp_hbr2 = {
> + .link_bit_rate = 54,
> + .clock = 54,
> + .tx = { 0xbe88, /* tx cfg0 */
> + 0x4800, /* tx cfg1 */
> + 0x, /* tx cfg2 */
> + },
> + .cmn = {0x0500, /* cmn cfg0*/
> + 0x0005, /* cmn cfg1 */
> + 0x, /* cmn cfg2 */
> + 0x, /* cmn cfg3 */
> + },
> + .mpllb = { 0x108c, /* mpllb cfg0 */
> + 0x2108, /* mpllb cfg1 */
> + 0xcc9c, /* mpllb cfg2
Re: [Intel-gfx] [PATCH 03/13] drm/i915/mtl: Dump C20 pll hw state
On Thu, Apr 20, 2023 at 03:40:40PM +0300, Mika Kahola wrote:
> As we already do with C10 chip, let's dump the pll
> hw state for C20 as well.
>
Reviewed-by: Radhakrishna Sripada
> Signed-off-by: Mika Kahola
> ---
> drivers/gpu/drm/i915/display/intel_cx0_phy.c | 20
> drivers/gpu/drm/i915/display/intel_cx0_phy.h | 2 ++
> drivers/gpu/drm/i915/display/intel_ddi.c | 1 +
> 3 files changed, 23 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> index 61428c5145e5..144474540ef4 100644
> --- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> @@ -2035,6 +2035,26 @@ void intel_c20pll_readout_hw_state(struct
> intel_encoder *encoder,
> }
> }
>
> +void intel_c20pll_dump_hw_state(struct drm_i915_private *i915,
> + const struct intel_c20pll_state *hw_state)
> +{
> + int i;
> +
> + drm_dbg_kms(&i915->drm, "c20pll_hw_state:\n");
> + drm_dbg_kms(&i915->drm, "tx[0] = 0x%.4x, tx[1] = 0x%.4x, tx[2] =
> 0x%.4x\n",
> + hw_state->tx[0], hw_state->tx[1], hw_state->tx[2]);
> + drm_dbg_kms(&i915->drm, "cmn[0] = 0x%.4x, cmn[1] = 0x%.4x, cmn[2] =
> 0x%.4x, cmn[3] = 0x%.4x\n",
> + hw_state->cmn[0], hw_state->cmn[1], hw_state->cmn[2],
> hw_state->cmn[3]);
> +
> + if (intel_c20_use_mplla(hw_state->clock)) {
> + for (i = 0; i < ARRAY_SIZE(hw_state->mplla); i++)
> + drm_dbg_kms(&i915->drm, "mplla[%d] = 0x%.4x\n", i,
> hw_state->mplla[i]);
> + } else {
> + for (i = 0; i < ARRAY_SIZE(hw_state->mpllb); i++)
> + drm_dbg_kms(&i915->drm, "mpllb[%d] = 0x%.4x\n", i,
> hw_state->mpllb[i]);
> + }
> +}
> +
> static u8 intel_c20_get_dp_rate(u32 clock)
> {
> switch (clock) {
> diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.h
> b/drivers/gpu/drm/i915/display/intel_cx0_phy.h
> index 9760c6292c81..c643aae27bac 100644
> --- a/drivers/gpu/drm/i915/display/intel_cx0_phy.h
> +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.h
> @@ -32,6 +32,8 @@ void intel_c10pll_state_verify(struct intel_atomic_state
> *state,
> struct intel_crtc_state *new_crtc_state);
> void intel_c20pll_readout_hw_state(struct intel_encoder *encoder,
> struct intel_c20pll_state *pll_state);
> +void intel_c20pll_dump_hw_state(struct drm_i915_private *i915,
> + const struct intel_c20pll_state *hw_state);
> void intel_cx0_phy_set_signal_levels(struct intel_encoder *encoder,
>const struct intel_crtc_state *crtc_state);
> int intel_cx0_phy_check_hdmi_link_rate(struct intel_hdmi *hdmi, int clock);
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 44f07011245b..d414dd8c26bf 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -3858,6 +3858,7 @@ static void mtl_ddi_get_config(struct intel_encoder
> *encoder,
> intel_c10pll_dump_hw_state(i915, &crtc_state->cx0pll_state.c10);
> } else {
> intel_c20pll_readout_hw_state(encoder,
> &crtc_state->cx0pll_state.c20);
> + intel_c20pll_dump_hw_state(i915, &crtc_state->cx0pll_state.c20);
> }
>
> crtc_state->port_clock = intel_c10pll_calc_port_clock(encoder,
> &crtc_state->cx0pll_state.c10);
> --
> 2.34.1
>
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/mtl: add PTE encode function (rev2)
== Series Details == Series: drm/i915/mtl: add PTE encode function (rev2) URL : https://patchwork.freedesktop.org/series/116868/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/mtl: add PTE encode function (rev2)
== Series Details ==
Series: drm/i915/mtl: add PTE encode function (rev2)
URL : https://patchwork.freedesktop.org/series/116868/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13055 -> Patchwork_116868v2
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116868v2/index.html
Participating hosts (38 -> 38)
--
Additional (1): bat-mtlp-8
Missing(1): fi-snb-2520m
Known issues
Here are the changes found in Patchwork_116868v2 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@gt_heartbeat:
- fi-kbl-soraka: [PASS][1] -> [DMESG-FAIL][2] ([i915#5334] /
[i915#7872])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13055/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116868v2/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html
* igt@i915_selftest@live@slpc:
- bat-rpls-1: NOTRUN -> [DMESG-FAIL][3] ([i915#6367])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116868v2/bat-rpls-1/igt@i915_selftest@l...@slpc.html
* igt@kms_chamelium_hpd@common-hpd-after-suspend:
- bat-rpls-1: NOTRUN -> [SKIP][4] ([i915#7828])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116868v2/bat-rpls-1/igt@kms_chamelium_...@common-hpd-after-suspend.html
* igt@kms_pipe_crc_basic@nonblocking-crc@pipe-d-dp-1:
- bat-dg2-8: [PASS][5] -> [FAIL][6] ([i915#7932])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13055/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-...@pipe-d-dp-1.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116868v2/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-...@pipe-d-dp-1.html
* igt@kms_pipe_crc_basic@read-crc:
- bat-adlp-9: NOTRUN -> [SKIP][7] ([i915#3546]) +1 similar issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116868v2/bat-adlp-9/igt@kms_pipe_crc_ba...@read-crc.html
* igt@kms_pipe_crc_basic@suspend-read-crc:
- bat-rpls-1: NOTRUN -> [SKIP][8] ([i915#1845])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116868v2/bat-rpls-1/igt@kms_pipe_crc_ba...@suspend-read-crc.html
Possible fixes
* igt@gem_exec_suspend@basic-s3@lmem0:
- bat-dg2-9: [FAIL][9] ([fdo#103375]) -> [PASS][10] +3 similar
issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13055/bat-dg2-9/igt@gem_exec_suspend@basic...@lmem0.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116868v2/bat-dg2-9/igt@gem_exec_suspend@basic...@lmem0.html
* igt@gem_exec_suspend@basic-s3@smem:
- bat-rpls-1: [ABORT][11] ([i915#6687] / [i915#7978]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13055/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116868v2/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html
* igt@i915_selftest@live@mman:
- bat-rpls-1: [TIMEOUT][13] ([i915#6794]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13055/bat-rpls-1/igt@i915_selftest@l...@mman.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116868v2/bat-rpls-1/igt@i915_selftest@l...@mman.html
* igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence@pipe-d-dp-1:
- bat-dg2-8: [FAIL][15] ([i915#7932]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13055/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-crc-frame-seque...@pipe-d-dp-1.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116868v2/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-crc-frame-seque...@pipe-d-dp-1.html
* igt@kms_pipe_crc_basic@suspend-read-crc@pipe-c-dp-3:
- bat-dg2-9: [FAIL][17] ([fdo#103375] / [i915#7932]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13055/bat-dg2-9/igt@kms_pipe_crc_basic@suspend-read-...@pipe-c-dp-3.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116868v2/bat-dg2-9/igt@kms_pipe_crc_basic@suspend-read-...@pipe-c-dp-3.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375
[i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
[i915#3546]: https://gitlab.freedesktop.org/drm/intel/issues/3546
[i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
[i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
[i915#6687]: https://gitlab.freedesktop.org/drm/intel/issues/6687
[i915#6794]: https://gitlab.freedesktop.org/drm/intel/issues/6794
[i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828
[i915#7872]: ht
[Intel-gfx] [PATCH v8 0/7] drm/i915: use ref_tracker library for tracking wakerefs
This is revived patchset improving ref_tracker library and converting i915 internal tracker to ref_tracker. The old thread ended without consensus about small kernel allocations, which are performed under spinlock. I have tried to solve the problem by splitting the calls, but it results in complicated API, so I went back to original solution. If there are better solutions I am glad to discuss them. Meanwhile I send original patchset with addressed remaining comments. To: Jani Nikula To: Joonas Lahtinen To: Rodrigo Vivi To: Tvrtko Ursulin To: David Airlie To: Daniel Vetter To: Eric Dumazet Cc: linux-ker...@vger.kernel.org Cc: intel-gfx@lists.freedesktop.org Cc: dri-de...@lists.freedesktop.org Cc: Chris Wilson Cc: net...@vger.kernel.org Cc: Jakub Kicinski Cc: Dmitry Vyukov Cc: "David S. Miller" Cc: Andi Shyti Cc: Das, Nirmoy Signed-off-by: Andrzej Hajda --- Changes in v8: - addressed comments from Eric, Zhou and CI, thanks, - added ref_tracker_dir_init name argument to all callers in one patch - moved intel_wakeref_tracker_show to *.c - s/intel_wakeref_tracker_show/intel_ref_tracker_show/ - removed 'default n' from Kconfig - changed strlcpy to strscpy, - removed assignement from if condition, - removed long lines from patch description - added tags - Link to v7: https://lore.kernel.org/r/20230224-track_gt-v7-0-11f08358c...@intel.com Changes in v7: - removed 8th patch (hold wakeref), as it was already merged - added tags (thx Andi) - Link to v6: https://lore.kernel.org/r/20230224-track_gt-v6-0-0dc8601fd...@intel.com Changes in v6: - rebased to solve minor conflict and allow CI testing - Link to v5: https://lore.kernel.org/r/20230224-track_gt-v5-0-77be86f2c...@intel.com Changes in v5 (thx Andi for review): - use *_locked convention instead of __*, - improved commit messages, - re-worked i915 patches, squashed separation and conversion patches, - added tags, - Link to v4: https://lore.kernel.org/r/20230224-track_gt-v4-0-464e8ab4c...@intel.com Changes in v4: - split "Separate wakeref tracking" to smaller parts - fixed typos, - Link to v1-v3: https://patchwork.freedesktop.org/series/100327/ --- Andrzej Hajda (7): lib/ref_tracker: add unlocked leak print helper lib/ref_tracker: improve printing stats lib/ref_tracker: add printing to memory buffer lib/ref_tracker: remove warnings in case of allocation failure drm/i915: Correct type of wakeref variable drm/i915: Replace custom intel runtime_pm tracker with ref_tracker library drm/i915: Track gt pm wakerefs drivers/gpu/drm/i915/Kconfig.debug | 18 ++ drivers/gpu/drm/i915/display/intel_display_power.c | 2 +- drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 7 +- .../drm/i915/gem/selftests/i915_gem_coherency.c| 10 +- drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c | 14 +- drivers/gpu/drm/i915/gt/intel_breadcrumbs.c| 13 +- drivers/gpu/drm/i915/gt/intel_breadcrumbs_types.h | 3 +- drivers/gpu/drm/i915/gt/intel_context.h| 4 +- drivers/gpu/drm/i915/gt/intel_context_types.h | 2 + drivers/gpu/drm/i915/gt/intel_engine_pm.c | 7 +- drivers/gpu/drm/i915/gt/intel_engine_types.h | 2 + .../gpu/drm/i915/gt/intel_execlists_submission.c | 2 +- drivers/gpu/drm/i915/gt/intel_gt_pm.c | 12 +- drivers/gpu/drm/i915/gt/intel_gt_pm.h | 38 +++- drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c | 4 +- drivers/gpu/drm/i915/gt/selftest_engine_cs.c | 20 +- drivers/gpu/drm/i915/gt/selftest_gt_pm.c | 5 +- drivers/gpu/drm/i915/gt/selftest_reset.c | 10 +- drivers/gpu/drm/i915/gt/selftest_rps.c | 17 +- drivers/gpu/drm/i915/gt/selftest_slpc.c| 5 +- drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 12 +- drivers/gpu/drm/i915/i915_driver.c | 2 +- drivers/gpu/drm/i915/i915_pmu.c| 16 +- drivers/gpu/drm/i915/intel_runtime_pm.c| 221 ++--- drivers/gpu/drm/i915/intel_runtime_pm.h| 11 +- drivers/gpu/drm/i915/intel_wakeref.c | 35 +++- drivers/gpu/drm/i915/intel_wakeref.h | 73 ++- include/linux/ref_tracker.h| 25 ++- lib/ref_tracker.c | 179 ++--- lib/test_ref_tracker.c | 2 +- net/core/dev.c | 2 +- net/core/net_namespace.c | 4 +- 32 files changed, 445 insertions(+), 332 deletions(-) --- base-commit: 4d0066a1c0763d50b6fb017e27d12b081ce21b57 change-id: 20230224-track_gt-1b3da8bdacd7 Best regards, -- Andrzej Hajda
[Intel-gfx] [PATCH v8 1/7] lib/ref_tracker: add unlocked leak print helper
To have reliable detection of leaks, caller must be able to check under
the same lock both: tracked counter and the leaks. dir.lock is natural
candidate for such lock and unlocked print helper can be called with this
lock taken.
As a bonus we can reuse this helper in ref_tracker_dir_exit.
Signed-off-by: Andrzej Hajda
Reviewed-by: Andi Shyti
Reviewed-by: Eric Dumazet
---
include/linux/ref_tracker.h | 8 ++
lib/ref_tracker.c | 66 ++---
2 files changed, 46 insertions(+), 28 deletions(-)
diff --git a/include/linux/ref_tracker.h b/include/linux/ref_tracker.h
index 9ca353ab712b5e..87a92f2bec1b88 100644
--- a/include/linux/ref_tracker.h
+++ b/include/linux/ref_tracker.h
@@ -36,6 +36,9 @@ static inline void ref_tracker_dir_init(struct
ref_tracker_dir *dir,
void ref_tracker_dir_exit(struct ref_tracker_dir *dir);
+void ref_tracker_dir_print_locked(struct ref_tracker_dir *dir,
+ unsigned int display_limit);
+
void ref_tracker_dir_print(struct ref_tracker_dir *dir,
unsigned int display_limit);
@@ -56,6 +59,11 @@ static inline void ref_tracker_dir_exit(struct
ref_tracker_dir *dir)
{
}
+static inline void ref_tracker_dir_print_locked(struct ref_tracker_dir *dir,
+ unsigned int display_limit)
+{
+}
+
static inline void ref_tracker_dir_print(struct ref_tracker_dir *dir,
unsigned int display_limit)
{
diff --git a/lib/ref_tracker.c b/lib/ref_tracker.c
index dc7b14aa3431e2..d4eb0929af8f96 100644
--- a/lib/ref_tracker.c
+++ b/lib/ref_tracker.c
@@ -14,6 +14,38 @@ struct ref_tracker {
depot_stack_handle_tfree_stack_handle;
};
+void ref_tracker_dir_print_locked(struct ref_tracker_dir *dir,
+ unsigned int display_limit)
+{
+ struct ref_tracker *tracker;
+ unsigned int i = 0;
+
+ lockdep_assert_held(&dir->lock);
+
+ list_for_each_entry(tracker, &dir->list, head) {
+ if (i < display_limit) {
+ pr_err("leaked reference.\n");
+ if (tracker->alloc_stack_handle)
+ stack_depot_print(tracker->alloc_stack_handle);
+ i++;
+ } else {
+ break;
+ }
+ }
+}
+EXPORT_SYMBOL(ref_tracker_dir_print_locked);
+
+void ref_tracker_dir_print(struct ref_tracker_dir *dir,
+ unsigned int display_limit)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(&dir->lock, flags);
+ ref_tracker_dir_print_locked(dir, display_limit);
+ spin_unlock_irqrestore(&dir->lock, flags);
+}
+EXPORT_SYMBOL(ref_tracker_dir_print);
+
void ref_tracker_dir_exit(struct ref_tracker_dir *dir)
{
struct ref_tracker *tracker, *n;
@@ -27,13 +59,13 @@ void ref_tracker_dir_exit(struct ref_tracker_dir *dir)
kfree(tracker);
dir->quarantine_avail++;
}
- list_for_each_entry_safe(tracker, n, &dir->list, head) {
- pr_err("leaked reference.\n");
- if (tracker->alloc_stack_handle)
- stack_depot_print(tracker->alloc_stack_handle);
+ if (!list_empty(&dir->list)) {
+ ref_tracker_dir_print_locked(dir, 16);
leak = true;
- list_del(&tracker->head);
- kfree(tracker);
+ list_for_each_entry_safe(tracker, n, &dir->list, head) {
+ list_del(&tracker->head);
+ kfree(tracker);
+ }
}
spin_unlock_irqrestore(&dir->lock, flags);
WARN_ON_ONCE(leak);
@@ -42,28 +74,6 @@ void ref_tracker_dir_exit(struct ref_tracker_dir *dir)
}
EXPORT_SYMBOL(ref_tracker_dir_exit);
-void ref_tracker_dir_print(struct ref_tracker_dir *dir,
- unsigned int display_limit)
-{
- struct ref_tracker *tracker;
- unsigned long flags;
- unsigned int i = 0;
-
- spin_lock_irqsave(&dir->lock, flags);
- list_for_each_entry(tracker, &dir->list, head) {
- if (i < display_limit) {
- pr_err("leaked reference.\n");
- if (tracker->alloc_stack_handle)
- stack_depot_print(tracker->alloc_stack_handle);
- i++;
- } else {
- break;
- }
- }
- spin_unlock_irqrestore(&dir->lock, flags);
-}
-EXPORT_SYMBOL(ref_tracker_dir_print);
-
int ref_tracker_alloc(struct ref_tracker_dir *dir,
struct ref_tracker **trackerp,
gfp_t gfp)
--
2.34.1
[Intel-gfx] [PATCH v8 2/7] lib/ref_tracker: improve printing stats
In case the library is tracking busy subsystem, simply
printing stack for every active reference will spam log
with long, hard to read, redundant stack traces. To improve
readabilty following changes have been made:
- reports are printed per stack_handle - log is more compact,
- added display name for ref_tracker_dir - it will differentiate
multiple subsystems,
- stack trace is printed indented, in the same printk call,
- info about dropped references is printed as well.
Signed-off-by: Andrzej Hajda
Reviewed-by: Andi Shyti
---
include/linux/ref_tracker.h | 9 -
lib/ref_tracker.c | 90 +++--
lib/test_ref_tracker.c | 2 +-
net/core/dev.c | 2 +-
net/core/net_namespace.c| 4 +-
5 files changed, 90 insertions(+), 17 deletions(-)
diff --git a/include/linux/ref_tracker.h b/include/linux/ref_tracker.h
index 87a92f2bec1b88..19a69e7809d6c1 100644
--- a/include/linux/ref_tracker.h
+++ b/include/linux/ref_tracker.h
@@ -17,12 +17,15 @@ struct ref_tracker_dir {
booldead;
struct list_headlist; /* List of active trackers */
struct list_headquarantine; /* List of dead trackers */
+ charname[32];
#endif
};
#ifdef CONFIG_REF_TRACKER
+
static inline void ref_tracker_dir_init(struct ref_tracker_dir *dir,
- unsigned int quarantine_count)
+ unsigned int quarantine_count,
+ const char *name)
{
INIT_LIST_HEAD(&dir->list);
INIT_LIST_HEAD(&dir->quarantine);
@@ -31,6 +34,7 @@ static inline void ref_tracker_dir_init(struct
ref_tracker_dir *dir,
dir->dead = false;
refcount_set(&dir->untracked, 1);
refcount_set(&dir->no_tracker, 1);
+ strscpy(dir->name, name, sizeof(dir->name));
stack_depot_init();
}
@@ -51,7 +55,8 @@ int ref_tracker_free(struct ref_tracker_dir *dir,
#else /* CONFIG_REF_TRACKER */
static inline void ref_tracker_dir_init(struct ref_tracker_dir *dir,
- unsigned int quarantine_count)
+ unsigned int quarantine_count,
+ const char *name)
{
}
diff --git a/lib/ref_tracker.c b/lib/ref_tracker.c
index d4eb0929af8f96..2ffe79c90c1771 100644
--- a/lib/ref_tracker.c
+++ b/lib/ref_tracker.c
@@ -1,11 +1,16 @@
// SPDX-License-Identifier: GPL-2.0-or-later
+
+#define pr_fmt(fmt) "ref_tracker: " fmt
+
#include
+#include
#include
#include
#include
#include
#define REF_TRACKER_STACK_ENTRIES 16
+#define STACK_BUF_SIZE 1024
struct ref_tracker {
struct list_headhead; /* anchor into dir->list or
dir->quarantine */
@@ -14,24 +19,87 @@ struct ref_tracker {
depot_stack_handle_tfree_stack_handle;
};
-void ref_tracker_dir_print_locked(struct ref_tracker_dir *dir,
- unsigned int display_limit)
+struct ref_tracker_dir_stats {
+ int total;
+ int count;
+ struct {
+ depot_stack_handle_t stack_handle;
+ unsigned int count;
+ } stacks[];
+};
+
+static struct ref_tracker_dir_stats *
+ref_tracker_get_stats(struct ref_tracker_dir *dir, unsigned int limit)
{
+ struct ref_tracker_dir_stats *stats;
struct ref_tracker *tracker;
- unsigned int i = 0;
- lockdep_assert_held(&dir->lock);
+ stats = kmalloc(struct_size(stats, stacks, limit),
+ GFP_NOWAIT | __GFP_NOWARN);
+ if (!stats)
+ return ERR_PTR(-ENOMEM);
+ stats->total = 0;
+ stats->count = 0;
list_for_each_entry(tracker, &dir->list, head) {
- if (i < display_limit) {
- pr_err("leaked reference.\n");
- if (tracker->alloc_stack_handle)
- stack_depot_print(tracker->alloc_stack_handle);
- i++;
- } else {
- break;
+ depot_stack_handle_t stack = tracker->alloc_stack_handle;
+ int i;
+
+ ++stats->total;
+ for (i = 0; i < stats->count; ++i)
+ if (stats->stacks[i].stack_handle == stack)
+ break;
+ if (i >= limit)
+ continue;
+ if (i >= stats->count) {
+ stats->stacks[i].stack_handle = stack;
+ stats->stacks[i].count = 0;
+ ++stats->count;
}
+ ++stats->stacks[i].count;
+ }
+
+ return stats;
+}
+
+void ref_tracker_dir_print_locked(struct ref_tracker_dir *dir,
+ unsigned int display_limit)
+{
+ struct ref_tracker_dir_stats *stats;
+ unsigned int i = 0, skipped;
+ depot_sta
[Intel-gfx] [PATCH v8 3/7] lib/ref_tracker: add printing to memory buffer
Similar to stack_(depot|trace)_snprint the patch
adds helper to printing stats to memory buffer.
It will be helpful in case of debugfs.
Signed-off-by: Andrzej Hajda
Reviewed-by: Andi Shyti
---
include/linux/ref_tracker.h | 8 +++
lib/ref_tracker.c | 56 ++---
2 files changed, 56 insertions(+), 8 deletions(-)
diff --git a/include/linux/ref_tracker.h b/include/linux/ref_tracker.h
index 19a69e7809d6c1..8eac4f3d52547c 100644
--- a/include/linux/ref_tracker.h
+++ b/include/linux/ref_tracker.h
@@ -46,6 +46,8 @@ void ref_tracker_dir_print_locked(struct ref_tracker_dir *dir,
void ref_tracker_dir_print(struct ref_tracker_dir *dir,
unsigned int display_limit);
+int ref_tracker_dir_snprint(struct ref_tracker_dir *dir, char *buf, size_t
size);
+
int ref_tracker_alloc(struct ref_tracker_dir *dir,
struct ref_tracker **trackerp, gfp_t gfp);
@@ -74,6 +76,12 @@ static inline void ref_tracker_dir_print(struct
ref_tracker_dir *dir,
{
}
+static inline int ref_tracker_dir_snprint(struct ref_tracker_dir *dir,
+ char *buf, size_t size)
+{
+ return 0;
+}
+
static inline int ref_tracker_alloc(struct ref_tracker_dir *dir,
struct ref_tracker **trackerp,
gfp_t gfp)
diff --git a/lib/ref_tracker.c b/lib/ref_tracker.c
index 2ffe79c90c1771..cce4614b07940f 100644
--- a/lib/ref_tracker.c
+++ b/lib/ref_tracker.c
@@ -62,8 +62,27 @@ ref_tracker_get_stats(struct ref_tracker_dir *dir, unsigned
int limit)
return stats;
}
-void ref_tracker_dir_print_locked(struct ref_tracker_dir *dir,
- unsigned int display_limit)
+struct ostream {
+ char *buf;
+ int size, used;
+};
+
+#define pr_ostream(stream, fmt, args...) \
+({ \
+ struct ostream *_s = (stream); \
+\
+ if (!_s->buf) { \
+ pr_err(fmt, ##args); \
+ } else { \
+ int ret, len = _s->size - _s->used; \
+ ret = snprintf(_s->buf + _s->used, len, pr_fmt(fmt), ##args); \
+ _s->used += min(ret, len); \
+ } \
+})
+
+static void
+__ref_tracker_dir_pr_ostream(struct ref_tracker_dir *dir,
+unsigned int display_limit, struct ostream *s)
{
struct ref_tracker_dir_stats *stats;
unsigned int i = 0, skipped;
@@ -77,8 +96,8 @@ void ref_tracker_dir_print_locked(struct ref_tracker_dir *dir,
stats = ref_tracker_get_stats(dir, display_limit);
if (IS_ERR(stats)) {
- pr_err("%s@%pK: couldn't get stats, error %pe\n",
- dir->name, dir, stats);
+ pr_ostream(s, "%s@%pK: couldn't get stats, error %pe\n",
+ dir->name, dir, stats);
return;
}
@@ -88,19 +107,27 @@ void ref_tracker_dir_print_locked(struct ref_tracker_dir
*dir,
stack = stats->stacks[i].stack_handle;
if (sbuf && !stack_depot_snprint(stack, sbuf, STACK_BUF_SIZE,
4))
sbuf[0] = 0;
- pr_err("%s@%pK has %d/%d users at\n%s\n", dir->name, dir,
- stats->stacks[i].count, stats->total, sbuf);
+ pr_ostream(s, "%s@%pK has %d/%d users at\n%s\n", dir->name, dir,
+ stats->stacks[i].count, stats->total, sbuf);
skipped -= stats->stacks[i].count;
}
if (skipped)
- pr_err("%s@%pK skipped reports about %d/%d users.\n",
- dir->name, dir, skipped, stats->total);
+ pr_ostream(s, "%s@%pK skipped reports about %d/%d users.\n",
+ dir->name, dir, skipped, stats->total);
kfree(sbuf);
kfree(stats);
}
+
+void ref_tracker_dir_print_locked(struct ref_tracker_dir *dir,
+ unsigned int display_limit)
+{
+ struct ostream os = {};
+
+ __ref_tracker_dir_pr_ostream(dir, display_limit, &os);
+}
EXPORT_SYMBOL(ref_tracker_dir_print_locked);
void ref_tracker_dir_print(struct ref_tracker_dir *dir,
@@ -114,6 +141,19 @@ void ref_tracker_dir_print(struct ref_tracker_dir *dir,
}
EXPORT_SYMBOL(ref_tracker_dir_print);
+int ref_tracker_dir_snprint(struct ref_tracker_dir *dir, char *buf, size_t
size)
+{
+ struct ostream os = { .buf = buf, .size = size };
+ unsigned long flags;
+
+ spin_lock_irqsave(&dir->lock, flags);
+ __ref_tracker_dir_pr_ostream(dir, 16, &os);
+ spin_unlock_irqrestore(&dir->lock, flags);
+
+ return os.used;
+}
+EXPORT_SYMBOL(ref_tracker_dir_snprint);
+
void ref_tracker_dir_exit(struct ref_tracker_dir *dir)
{
struct ref_tracker *tracker, *n;
--
2.34.1
[Intel-gfx] [PATCH v8 7/7] drm/i915: Track gt pm wakerefs
Track every intel_gt_pm_get() until its corresponding release in
intel_gt_pm_put() by returning a cookie to the caller for acquire that
must be passed by on released. When there is an imbalance, we can see who
either tried to free a stale wakeref, or who forgot to free theirs.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/i915/Kconfig.debug | 14
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 7 ++--
.../drm/i915/gem/selftests/i915_gem_coherency.c| 10 +++---
drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c | 14
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c| 13 +---
drivers/gpu/drm/i915/gt/intel_breadcrumbs_types.h | 3 +-
drivers/gpu/drm/i915/gt/intel_context.h| 4 +--
drivers/gpu/drm/i915/gt/intel_context_types.h | 2 ++
drivers/gpu/drm/i915/gt/intel_engine_pm.c | 7 ++--
drivers/gpu/drm/i915/gt/intel_engine_types.h | 2 ++
.../gpu/drm/i915/gt/intel_execlists_submission.c | 2 +-
drivers/gpu/drm/i915/gt/intel_gt_pm.c | 12 ---
drivers/gpu/drm/i915/gt/intel_gt_pm.h | 38 +-
drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c | 4 +--
drivers/gpu/drm/i915/gt/selftest_engine_cs.c | 20 +++-
drivers/gpu/drm/i915/gt/selftest_gt_pm.c | 5 +--
drivers/gpu/drm/i915/gt/selftest_reset.c | 10 +++---
drivers/gpu/drm/i915/gt/selftest_rps.c | 17 ++
drivers/gpu/drm/i915/gt/selftest_slpc.c| 5 +--
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 10 +++---
drivers/gpu/drm/i915/i915_pmu.c| 16 +
drivers/gpu/drm/i915/intel_wakeref.c | 7 +++-
drivers/gpu/drm/i915/intel_wakeref.h | 38 --
23 files changed, 182 insertions(+), 78 deletions(-)
diff --git a/drivers/gpu/drm/i915/Kconfig.debug
b/drivers/gpu/drm/i915/Kconfig.debug
index 76454fcbf65228..01e18e4c0e2590 100644
--- a/drivers/gpu/drm/i915/Kconfig.debug
+++ b/drivers/gpu/drm/i915/Kconfig.debug
@@ -40,6 +40,7 @@ config DRM_I915_DEBUG
select DRM_I915_DEBUG_GEM_ONCE
select DRM_I915_DEBUG_MMIO
select DRM_I915_DEBUG_RUNTIME_PM
+ select DRM_I915_DEBUG_WAKEREF
select DRM_I915_SW_FENCE_DEBUG_OBJECTS
select DRM_I915_SELFTEST
default n
@@ -243,3 +244,16 @@ config DRM_I915_DEBUG_RUNTIME_PM
Recommended for driver developers only.
If in doubt, say "N"
+
+config DRM_I915_DEBUG_WAKEREF
+ bool "Enable extra tracking for wakerefs"
+ depends on DRM_I915
+ select REF_TRACKER
+ select STACKDEPOT
+ select STACKTRACE
+ help
+ Choose this option to turn on extra state checking and usage
+ tracking for the wakerefPM functionality. This may introduce
+ overhead during driver runtime.
+
+ If in doubt, say "N"
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 3aeede6aee4dcc..33a034a9c42f11 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -253,6 +253,7 @@ struct i915_execbuffer {
struct intel_gt *gt; /* gt for the execbuf */
struct intel_context *context; /* logical state for the request */
struct i915_gem_context *gem_context; /** caller's context */
+ intel_wakeref_t wakeref;
/** our requests to build */
struct i915_request *requests[MAX_ENGINE_INSTANCE + 1];
@@ -2709,7 +2710,7 @@ eb_select_engine(struct i915_execbuffer *eb)
for_each_child(ce, child)
intel_context_get(child);
- intel_gt_pm_get(ce->engine->gt);
+ eb->wakeref = intel_gt_pm_get(ce->engine->gt);
if (!test_bit(CONTEXT_ALLOC_BIT, &ce->flags)) {
err = intel_context_alloc_state(ce);
@@ -2748,7 +2749,7 @@ eb_select_engine(struct i915_execbuffer *eb)
return err;
err:
- intel_gt_pm_put(ce->engine->gt);
+ intel_gt_pm_put(ce->engine->gt, eb->wakeref);
for_each_child(ce, child)
intel_context_put(child);
intel_context_put(ce);
@@ -2761,7 +2762,7 @@ eb_put_engine(struct i915_execbuffer *eb)
struct intel_context *child;
i915_vm_put(eb->context->vm);
- intel_gt_pm_put(eb->gt);
+ intel_gt_pm_put(eb->context->engine->gt, eb->wakeref);
for_each_child(eb->context, child)
intel_context_put(child);
intel_context_put(eb->context);
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c
index 3bef1beec7cbb5..3fd68a099a85ef 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c
@@ -85,6 +85,7 @@ static int cpu_get(struct context *ctx, unsigned long offset,
u32 *v)
static int gtt_set(struct context *ctx, un
[Intel-gfx] [PATCH v8 5/7] drm/i915: Correct type of wakeref variable
Wakeref has dedicated type. Assumption it will be int compatible forever is incorrect. Signed-off-by: Andrzej Hajda Reviewed-by: Andi Shyti --- drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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 ee3e8352637f28..fe390d59929b02 100644 --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c @@ -3248,7 +3248,7 @@ static void destroyed_worker_func(struct work_struct *w) struct intel_guc *guc = container_of(w, struct intel_guc, submission_state.destroyed_worker); struct intel_gt *gt = guc_to_gt(guc); - int tmp; + intel_wakeref_t tmp; with_intel_gt_pm(gt, tmp) deregister_destroyed_contexts(guc); -- 2.34.1
[Intel-gfx] [PATCH v8 4/7] lib/ref_tracker: remove warnings in case of allocation failure
Library can handle allocation failures. To avoid allocation warnings
__GFP_NOWARN has been added everywhere. Moreover GFP_ATOMIC has been
replaced with GFP_NOWAIT in case of stack allocation on tracker free
call.
Signed-off-by: Andrzej Hajda
Reviewed-by: Andi Shyti
Reviewed-by: Eric Dumazet
---
lib/ref_tracker.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/lib/ref_tracker.c b/lib/ref_tracker.c
index cce4614b07940f..cf5609b1ca7936 100644
--- a/lib/ref_tracker.c
+++ b/lib/ref_tracker.c
@@ -189,7 +189,7 @@ int ref_tracker_alloc(struct ref_tracker_dir *dir,
unsigned long entries[REF_TRACKER_STACK_ENTRIES];
struct ref_tracker *tracker;
unsigned int nr_entries;
- gfp_t gfp_mask = gfp;
+ gfp_t gfp_mask = gfp | __GFP_NOWARN;
unsigned long flags;
WARN_ON_ONCE(dir->dead);
@@ -237,7 +237,8 @@ int ref_tracker_free(struct ref_tracker_dir *dir,
return -EEXIST;
}
nr_entries = stack_trace_save(entries, ARRAY_SIZE(entries), 1);
- stack_handle = stack_depot_save(entries, nr_entries, GFP_ATOMIC);
+ stack_handle = stack_depot_save(entries, nr_entries,
+ GFP_NOWAIT | __GFP_NOWARN);
spin_lock_irqsave(&dir->lock, flags);
if (tracker->dead) {
--
2.34.1
[Intel-gfx] [PATCH v8 6/7] drm/i915: Replace custom intel runtime_pm tracker with ref_tracker library
Beside reusing existing code, the main advantage of ref_tracker is
tracking per instance of wakeref. It allows also to catch double
put.
On the other side we lose information about the first acquire and
the last release, but the advantages outweigh it.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/i915/Kconfig.debug | 4 +
drivers/gpu/drm/i915/display/intel_display_power.c | 2 +-
drivers/gpu/drm/i915/i915_driver.c | 2 +-
drivers/gpu/drm/i915/intel_runtime_pm.c| 221 ++---
drivers/gpu/drm/i915/intel_runtime_pm.h| 11 +-
drivers/gpu/drm/i915/intel_wakeref.c | 28 +++
drivers/gpu/drm/i915/intel_wakeref.h | 35 +++-
7 files changed, 86 insertions(+), 217 deletions(-)
diff --git a/drivers/gpu/drm/i915/Kconfig.debug
b/drivers/gpu/drm/i915/Kconfig.debug
index 47e845353ffad8..76454fcbf65228 100644
--- a/drivers/gpu/drm/i915/Kconfig.debug
+++ b/drivers/gpu/drm/i915/Kconfig.debug
@@ -24,7 +24,9 @@ config DRM_I915_DEBUG
select DEBUG_FS
select PREEMPT_COUNT
select I2C_CHARDEV
+ select REF_TRACKER
select STACKDEPOT
+ select STACKTRACE
select DRM_DP_AUX_CHARDEV
select X86_MSR # used by igt/pm_rpm
select DRM_VGEM # used by igt/prime_vgem (dmabuf interop checks)
@@ -230,7 +232,9 @@ config DRM_I915_DEBUG_RUNTIME_PM
bool "Enable extra state checking for runtime PM"
depends on DRM_I915
default n
+ select REF_TRACKER
select STACKDEPOT
+ select STACKTRACE
help
Choose this option to turn on extra state checking for the
runtime PM functionality. This may introduce overhead during
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 5150069f3f8218..36d202d3391857 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -407,7 +407,7 @@ print_async_put_domains_state(struct i915_power_domains
*power_domains)
struct drm_i915_private,
display.power.domains);
- drm_dbg(&i915->drm, "async_put_wakeref %u\n",
+ drm_dbg(&i915->drm, "async_put_wakeref %lu\n",
power_domains->async_put_wakeref);
print_power_domains(power_domains, "async_put_domains[0]",
diff --git a/drivers/gpu/drm/i915/i915_driver.c
b/drivers/gpu/drm/i915/i915_driver.c
index fd198700272b10..4e2fb438e26f04 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -1018,7 +1018,7 @@ void i915_driver_shutdown(struct drm_i915_private *i915)
intel_power_domains_driver_remove(i915);
enable_rpm_wakeref_asserts(&i915->runtime_pm);
- intel_runtime_pm_driver_release(&i915->runtime_pm);
+ intel_runtime_pm_driver_last_release(&i915->runtime_pm);
}
static bool suspend_to_idle(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index cf5122299b6b8c..2166c209f17f04 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -52,182 +52,37 @@
#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_RUNTIME_PM)
-#include
-
-#define STACKDEPTH 8
-
-static noinline depot_stack_handle_t __save_depot_stack(void)
-{
- unsigned long entries[STACKDEPTH];
- unsigned int n;
-
- n = stack_trace_save(entries, ARRAY_SIZE(entries), 1);
- return stack_depot_save(entries, n, GFP_NOWAIT | __GFP_NOWARN);
-}
-
static void init_intel_runtime_pm_wakeref(struct intel_runtime_pm *rpm)
{
- spin_lock_init(&rpm->debug.lock);
- stack_depot_init();
+ ref_tracker_dir_init(&rpm->debug, INTEL_REFTRACK_DEAD_COUNT,
dev_name(rpm->kdev));
}
-static noinline depot_stack_handle_t
+static intel_wakeref_t
track_intel_runtime_pm_wakeref(struct intel_runtime_pm *rpm)
{
- depot_stack_handle_t stack, *stacks;
- unsigned long flags;
-
- if (rpm->no_wakeref_tracking)
- return -1;
-
- stack = __save_depot_stack();
- if (!stack)
+ if (!rpm->available || rpm->no_wakeref_tracking)
return -1;
- spin_lock_irqsave(&rpm->debug.lock, flags);
-
- if (!rpm->debug.count)
- rpm->debug.last_acquire = stack;
-
- stacks = krealloc(rpm->debug.owners,
- (rpm->debug.count + 1) * sizeof(*stacks),
- GFP_NOWAIT | __GFP_NOWARN);
- if (stacks) {
- stacks[rpm->debug.count++] = stack;
- rpm->debug.owners = stacks;
- } else {
- stack = -1;
- }
-
- spin_unlock_irqrestore(&rpm->debug.lock, flags);
-
- return stack;
+ return intel_ref_tracker_alloc(&rpm->debug);
}
static void untrac
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftest: Record GT error for gt failure
== Series Details == Series: drm/i915/selftest: Record GT error for gt failure URL : https://patchwork.freedesktop.org/series/116890/ State : success == Summary == CI Bug Log - changes from CI_DRM_13056 -> Patchwork_116890v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116890v1/index.html Participating hosts (39 -> 38) -- Missing(1): fi-snb-2520m Known issues Here are the changes found in Patchwork_116890v1 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s3@smem: - bat-rpls-1: NOTRUN -> [ABORT][1] ([i915#6687] / [i915#7978]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116890v1/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html * igt@i915_selftest@live@gt_heartbeat: - fi-kbl-soraka: [PASS][2] -> [DMESG-FAIL][3] ([i915#5334] / [i915#7872]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13056/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116890v1/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html * igt@i915_selftest@live@workarounds: - bat-rpls-1: [PASS][4] -> [DMESG-FAIL][5] ([i915#7102]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13056/bat-rpls-1/igt@i915_selftest@l...@workarounds.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116890v1/bat-rpls-1/igt@i915_selftest@l...@workarounds.html * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence@pipe-d-dp-1: - bat-dg2-8: [PASS][6] -> [FAIL][7] ([i915#7932]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13056/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-crc-frame-seque...@pipe-d-dp-1.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116890v1/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-crc-frame-seque...@pipe-d-dp-1.html Possible fixes * igt@i915_selftest@live@gt_heartbeat: - fi-glk-j4005: [DMESG-FAIL][8] ([i915#5334]) -> [PASS][9] [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13056/fi-glk-j4005/igt@i915_selftest@live@gt_heartbeat.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116890v1/fi-glk-j4005/igt@i915_selftest@live@gt_heartbeat.html * igt@i915_selftest@live@migrate: - bat-atsm-1: [DMESG-FAIL][10] ([i915#7699]) -> [PASS][11] [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13056/bat-atsm-1/igt@i915_selftest@l...@migrate.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116890v1/bat-atsm-1/igt@i915_selftest@l...@migrate.html * igt@i915_selftest@live@reset: - bat-rpls-1: [ABORT][12] ([i915#4983] / [i915#8384]) -> [PASS][13] [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13056/bat-rpls-1/igt@i915_selftest@l...@reset.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116890v1/bat-rpls-1/igt@i915_selftest@l...@reset.html * igt@kms_addfb_basic@unused-modifier: - fi-kbl-soraka: [INCOMPLETE][14] -> [PASS][15] [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13056/fi-kbl-soraka/igt@kms_addfb_ba...@unused-modifier.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116890v1/fi-kbl-soraka/igt@kms_addfb_ba...@unused-modifier.html [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983 [i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334 [i915#6687]: https://gitlab.freedesktop.org/drm/intel/issues/6687 [i915#7102]: https://gitlab.freedesktop.org/drm/intel/issues/7102 [i915#7699]: https://gitlab.freedesktop.org/drm/intel/issues/7699 [i915#7872]: https://gitlab.freedesktop.org/drm/intel/issues/7872 [i915#7932]: https://gitlab.freedesktop.org/drm/intel/issues/7932 [i915#7978]: https://gitlab.freedesktop.org/drm/intel/issues/7978 [i915#8384]: https://gitlab.freedesktop.org/drm/intel/issues/8384 Build changes - * Linux: CI_DRM_13056 -> Patchwork_116890v1 CI-20190529: 20190529 CI_DRM_13056: 308c0163d9e46238948942260e6d2abcad3d8bff @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7267: a267f0236e06fc282e3dc3b8c7d76f9ed6088d9b @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_116890v1: 308c0163d9e46238948942260e6d2abcad3d8bff @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits 743397c9fc60 drm/i915/selftest: Record GT error for gt failure == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116890v1/index.html
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/mtl: Add PTE encode functions (rev2)
== Series Details == Series: drm/i915/mtl: Add PTE encode functions (rev2) URL : https://patchwork.freedesktop.org/series/116900/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/mtl: Add PTE encode functions (rev2)
== Series Details ==
Series: drm/i915/mtl: Add PTE encode functions (rev2)
URL : https://patchwork.freedesktop.org/series/116900/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13056 -> Patchwork_116900v2
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116900v2/index.html
Participating hosts (39 -> 37)
--
Missing(2): fi-kbl-soraka fi-snb-2520m
Known issues
Here are the changes found in Patchwork_116900v2 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_chamelium_hpd@common-hpd-after-suspend:
- bat-rpls-1: NOTRUN -> [SKIP][1] ([i915#7828])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116900v2/bat-rpls-1/igt@kms_chamelium_...@common-hpd-after-suspend.html
* igt@kms_pipe_crc_basic@suspend-read-crc:
- bat-rpls-1: NOTRUN -> [SKIP][2] ([i915#1845])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116900v2/bat-rpls-1/igt@kms_pipe_crc_ba...@suspend-read-crc.html
Possible fixes
* igt@i915_module_load@load:
- {bat-mtlp-8}: [ABORT][3] ([i915#8361]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13056/bat-mtlp-8/igt@i915_module_l...@load.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116900v2/bat-mtlp-8/igt@i915_module_l...@load.html
* igt@i915_selftest@live@gt_heartbeat:
- fi-glk-j4005: [DMESG-FAIL][5] ([i915#5334]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13056/fi-glk-j4005/igt@i915_selftest@live@gt_heartbeat.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116900v2/fi-glk-j4005/igt@i915_selftest@live@gt_heartbeat.html
* igt@i915_selftest@live@migrate:
- bat-atsm-1: [DMESG-FAIL][7] ([i915#7699]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13056/bat-atsm-1/igt@i915_selftest@l...@migrate.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116900v2/bat-atsm-1/igt@i915_selftest@l...@migrate.html
* igt@i915_selftest@live@reset:
- bat-rpls-1: [ABORT][9] ([i915#4983] / [i915#8384]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13056/bat-rpls-1/igt@i915_selftest@l...@reset.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116900v2/bat-rpls-1/igt@i915_selftest@l...@reset.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
[i915#3595]: https://gitlab.freedesktop.org/drm/intel/issues/3595
[i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
[i915#4077]: https://gitlab.freedesktop.org/drm/intel/issues/4077
[i915#4079]: https://gitlab.freedesktop.org/drm/intel/issues/4079
[i915#4083]: https://gitlab.freedesktop.org/drm/intel/issues/4083
[i915#4212]: https://gitlab.freedesktop.org/drm/intel/issues/4212
[i915#4213]: https://gitlab.freedesktop.org/drm/intel/issues/4213
[i915#4579]: https://gitlab.freedesktop.org/drm/intel/issues/4579
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#5190]: https://gitlab.freedesktop.org/drm/intel/issues/5190
[i915#5274]: https://gitlab.freedesktop.org/drm/intel/issues/5274
[i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
[i915#7456]: https://gitlab.freedesktop.org/drm/intel/issues/7456
[i915#7699]: https://gitlab.freedesktop.org/drm/intel/issues/7699
[i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828
[i915#7982]: https://gitlab.freedesktop.org/drm/intel/issues/7982
[i915#8346]: https://gitlab.freedesktop.org/drm/intel/issues/8346
[i915#8361]: https://gitlab.freedesktop.org/drm/intel/issues/8361
[i915#8368]: https://gitlab.freedesktop.org/drm/intel/issues/8368
[i915#8379]: https://gitlab.freedesktop.org/drm/intel/issues/8379
[i915#8384]: https://gitlab.freedesktop.org/drm/intel/issues/8384
Build changes
-
* Linux: CI_DRM_13056 -> Patchwork_116900v2
CI-20190529: 20190529
CI_DRM_13056: 308c0163d9e46238948942260e6d2abcad3d8bff @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7267: a267f0236e06fc282e3dc3b8c7d76f9ed6088d9b @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_116900v2: 308c0163d9e46238948942260e6d2abcad3d8bff @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
7e9e601b7f62 drm/i915/mtl: workaround coherency issue for Media
8514c5828c19 drm/i915/mtl: Add PTE encode function
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116900v2/index.html
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/mtl: Add workaround 14018778641 (rev2)
== Series Details ==
Series: drm/i915/mtl: Add workaround 14018778641 (rev2)
URL : https://patchwork.freedesktop.org/series/116750/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13054_full -> Patchwork_116750v2_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (7 -> 7)
--
No changes in participating hosts
Known issues
Here are the changes found in Patchwork_116750v2_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_ppgtt@blt-vs-render-ctx0:
- shard-snb: [PASS][1] -> [FAIL][2] ([i915#8295])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13054/shard-snb5/igt@gem_pp...@blt-vs-render-ctx0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116750v2/shard-snb6/igt@gem_pp...@blt-vs-render-ctx0.html
* igt@gen9_exec_parse@allowed-all:
- shard-apl: [PASS][3] -> [ABORT][4] ([i915#5566])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13054/shard-apl4/igt@gen9_exec_pa...@allowed-all.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116750v2/shard-apl2/igt@gen9_exec_pa...@allowed-all.html
* igt@i915_pm_rps@reset:
- shard-snb: [PASS][5] -> [INCOMPLETE][6] ([i915#7790])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13054/shard-snb6/igt@i915_pm_...@reset.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116750v2/shard-snb6/igt@i915_pm_...@reset.html
*
igt@kms_plane_scaling@planes-downscale-factor-0-25-upscale-0-25@pipe-a-hdmi-a-1:
- shard-snb: NOTRUN -> [SKIP][7] ([fdo#109271]) +28 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116750v2/shard-snb1/igt@kms_plane_scaling@planes-downscale-factor-0-25-upscale-0...@pipe-a-hdmi-a-1.html
Possible fixes
* igt@drm_fdinfo@most-busy-check-all@rcs0:
- {shard-rkl}:[FAIL][8] ([i915#7742]) -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13054/shard-rkl-4/igt@drm_fdinfo@most-busy-check-...@rcs0.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116750v2/shard-rkl-2/igt@drm_fdinfo@most-busy-check-...@rcs0.html
* igt@gem_exec_fair@basic-none@bcs0:
- {shard-rkl}:[FAIL][10] ([i915#2842]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13054/shard-rkl-6/igt@gem_exec_fair@basic-n...@bcs0.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116750v2/shard-rkl-7/igt@gem_exec_fair@basic-n...@bcs0.html
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk: [FAIL][12] ([i915#2842]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13054/shard-glk2/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116750v2/shard-glk6/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
* igt@i915_pm_rpm@modeset-non-lpsp:
- {shard-rkl}:[SKIP][14] ([i915#1397]) -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13054/shard-rkl-7/igt@i915_pm_...@modeset-non-lpsp.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116750v2/shard-rkl-6/igt@i915_pm_...@modeset-non-lpsp.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions:
- shard-glk: [FAIL][16] ([i915#2346]) -> [PASS][17] +1 similar
issue
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13054/shard-glk9/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116750v2/shard-glk8/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
- shard-apl: [FAIL][18] ([i915#2346]) -> [PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13054/shard-apl4/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116750v2/shard-apl4/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.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#109283]: https://bugs.freedesktop.org/show_bug.cgi?id=109283
[fdo#109289]: https://bugs.freedesktop.org/show_bug.cgi?id=109289
[fdo#110189]: https://bugs.freedesktop.org/show_bug.cgi?id=110189
[fdo#111068]: https://bugs.freedesktop.org/show_bug.cgi?id=111068
[fdo#111615]: https://bugs.freedesktop.org/show_bug.cgi?id=111615
[fdo#111825]: https://bugs.freedesktop.org/show_bug.cgi?id=111825
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[fdo#112054]: https://bugs.freedesktop.org/show_bug.cgi?id=112054
[fdo#112283]: https://bugs.freedesktop.org/show_bug.cgi?id=112283
[i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
[i9
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Restore MTL boot (rev2)
== Series Details == Series: Restore MTL boot (rev2) URL : https://patchwork.freedesktop.org/series/116894/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✓ Fi.CI.BAT: success for Restore MTL boot (rev2)
== Series Details ==
Series: Restore MTL boot (rev2)
URL : https://patchwork.freedesktop.org/series/116894/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13056 -> Patchwork_116894v2
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116894v2/index.html
Participating hosts (39 -> 37)
--
Missing(2): fi-kbl-soraka fi-snb-2520m
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_116894v2:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live@hugepages:
- {bat-mtlp-8}: NOTRUN -> [DMESG-FAIL][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116894v2/bat-mtlp-8/igt@i915_selftest@l...@hugepages.html
* igt@kms_pipe_crc_basic@suspend-read-crc@pipe-c-edp-1:
- {bat-mtlp-8}: NOTRUN -> [SKIP][2] +1 similar issue
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116894v2/bat-mtlp-8/igt@kms_pipe_crc_basic@suspend-read-...@pipe-c-edp-1.html
Known issues
Here are the changes found in Patchwork_116894v2 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@gt_heartbeat:
- fi-apl-guc: [PASS][3] -> [DMESG-FAIL][4] ([i915#5334])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13056/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116894v2/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html
* igt@i915_selftest@live@requests:
- bat-rpls-1: [PASS][5] -> [ABORT][6] ([i915#4983] / [i915#7911])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13056/bat-rpls-1/igt@i915_selftest@l...@requests.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116894v2/bat-rpls-1/igt@i915_selftest@l...@requests.html
* igt@kms_pipe_crc_basic@nonblocking-crc@pipe-d-dp-1:
- bat-dg2-8: [PASS][7] -> [FAIL][8] ([i915#7932]) +1 similar issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13056/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-...@pipe-d-dp-1.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116894v2/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-...@pipe-d-dp-1.html
Possible fixes
* igt@i915_module_load@load:
- {bat-mtlp-8}: [ABORT][9] ([i915#8361]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13056/bat-mtlp-8/igt@i915_module_l...@load.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116894v2/bat-mtlp-8/igt@i915_module_l...@load.html
* igt@i915_selftest@live@gt_heartbeat:
- fi-glk-j4005: [DMESG-FAIL][11] ([i915#5334]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13056/fi-glk-j4005/igt@i915_selftest@live@gt_heartbeat.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116894v2/fi-glk-j4005/igt@i915_selftest@live@gt_heartbeat.html
* igt@i915_selftest@live@migrate:
- bat-atsm-1: [DMESG-FAIL][13] ([i915#7699]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13056/bat-atsm-1/igt@i915_selftest@l...@migrate.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116894v2/bat-atsm-1/igt@i915_selftest@l...@migrate.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[i915#3595]: https://gitlab.freedesktop.org/drm/intel/issues/3595
[i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
[i915#4077]: https://gitlab.freedesktop.org/drm/intel/issues/4077
[i915#4079]: https://gitlab.freedesktop.org/drm/intel/issues/4079
[i915#4083]: https://gitlab.freedesktop.org/drm/intel/issues/4083
[i915#4212]: https://gitlab.freedesktop.org/drm/intel/issues/4212
[i915#4213]: https://gitlab.freedesktop.org/drm/intel/issues/4213
[i915#4579]: https://gitlab.freedesktop.org/drm/intel/issues/4579
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#5190]: https://gitlab.freedesktop.org/drm/intel/issues/5190
[i915#5274]: https://gitlab.freedesktop.org/drm/intel/issues/5274
[i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
[i915#6645]: https://gitlab.freedesktop.org/drm/intel/issues/6645
[i915#7456]: https://gitlab.freedesktop.org/drm/intel/issues/7456
[i915#7699]: https://gitlab.freedesktop.org/drm/intel/issues/7699
[i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828
[i915#7911]: https://gitlab.freedesktop.org/drm/intel/issues/7911
[i9
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/adlp+: Disable DC5/6 states for TC port DDI/AUX and for combo port AUX
== Series Details == Series: drm/i915/adlp+: Disable DC5/6 states for TC port DDI/AUX and for combo port AUX URL : https://patchwork.freedesktop.org/series/116909/ State : warning == Summary == Error: dim checkpatch failed 308b7246ce58 drm/i915/adlp+: Disable DC5/6 states for TC port DDI/AUX and for combo port AUX -:39: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in parentheses #39: FILE: drivers/gpu/drm/i915/display/intel_display_power_map.c:1254: +#define XELPD_DC_OFF_PORT_POWER_DOMAINS \ POWER_DOMAIN_PORT_DDI_LANES_TC1, \ POWER_DOMAIN_PORT_DDI_LANES_TC2, \ POWER_DOMAIN_PORT_DDI_LANES_TC3, \ POWER_DOMAIN_PORT_DDI_LANES_TC4, \ POWER_DOMAIN_AUX_C, \ POWER_DOMAIN_AUX_D, \ POWER_DOMAIN_AUX_E, \ -:56: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in parentheses #56: FILE: drivers/gpu/drm/i915/display/intel_display_power_map.c:1271: +#define XELPD_PW_2_POWER_DOMAINS \ + XELPD_PW_B_POWER_DOMAINS, \ + XELPD_PW_C_POWER_DOMAINS, \ + XELPD_PW_D_POWER_DOMAINS, \ + POWER_DOMAIN_PORT_DDI_LANES_C, \ + POWER_DOMAIN_PORT_DDI_LANES_D, \ + POWER_DOMAIN_PORT_DDI_LANES_E, \ + POWER_DOMAIN_VGA, \ + POWER_DOMAIN_AUDIO_PLAYBACK, \ + POWER_DOMAIN_AUX_IO_C, \ + POWER_DOMAIN_AUX_IO_D, \ + POWER_DOMAIN_AUX_IO_E, \ + XELPD_DC_OFF_PORT_POWER_DOMAINS total: 2 errors, 0 warnings, 0 checks, 50 lines checked
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/guc: Disable PL1 power limit when loading GuC firmware
On Thu, 20 Apr 2023 17:08:42 -0700, Patchwork wrote: > > Patch Details > > Series: drm/i915/guc: Disable PL1 power limit when loading GuC firmware > URL: https://patchwork.freedesktop.org/series/116768/ > State: failure > Details: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116768v1/index.html > > CI Bug Log - changes from CI_DRM_13034_full -> Patchwork_116768v1_full > > Summary > > FAILURE > > Serious unknown changes coming with Patchwork_116768v1_full absolutely need > to be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_116768v1_full, please notify your bug team to allow > them > to document this new failure mode, which will reduce false positives in CI. > > Participating hosts (7 -> 7) > > No changes in participating hosts > > Possible new issues > > Here are the unknown changes that may have been introduced in > Patchwork_116768v1_full: > > IGT changes > > Possible regressions > > * igt@gem_ppgtt@blt-vs-render-ctx0: > > * shard-snb: PASS -> DMESG-FAIL This failure is unrelated to this series. The series has effect only for dGFX. Thanks. -- Ashutosh
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/adlp+: Disable DC5/6 states for TC port DDI/AUX and for combo port AUX
== Series Details == Series: drm/i915/adlp+: Disable DC5/6 states for TC port DDI/AUX and for combo port AUX URL : https://patchwork.freedesktop.org/series/116909/ State : success == Summary == CI Bug Log - changes from CI_DRM_13056 -> Patchwork_116909v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116909v1/index.html Participating hosts (39 -> 37) -- Missing(2): fi-kbl-soraka fi-snb-2520m Known issues Here are the changes found in Patchwork_116909v1 that come from known issues: ### IGT changes ### Issues hit * igt@gem_mmap@basic: - bat-dg2-11: NOTRUN -> [SKIP][1] ([i915#4083]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116909v1/bat-dg2-11/igt@gem_m...@basic.html * igt@gem_tiled_fence_blits@basic: - bat-dg2-11: NOTRUN -> [SKIP][2] ([i915#4077]) +2 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116909v1/bat-dg2-11/igt@gem_tiled_fence_bl...@basic.html * igt@gem_tiled_pread_basic: - bat-dg2-11: NOTRUN -> [SKIP][3] ([i915#4079]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116909v1/bat-dg2-11/igt@gem_tiled_pread_basic.html * igt@i915_pm_backlight@basic-brightness: - bat-dg2-11: NOTRUN -> [SKIP][4] ([i915#5354] / [i915#7561]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116909v1/bat-dg2-11/igt@i915_pm_backli...@basic-brightness.html * igt@i915_selftest@live@requests: - bat-rpls-1: [PASS][5] -> [ABORT][6] ([i915#4983] / [i915#7911]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13056/bat-rpls-1/igt@i915_selftest@l...@requests.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116909v1/bat-rpls-1/igt@i915_selftest@l...@requests.html * igt@kms_addfb_basic@addfb25-x-tiled-mismatch-legacy: - bat-dg2-11: NOTRUN -> [SKIP][7] ([i915#4212]) +7 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116909v1/bat-dg2-11/igt@kms_addfb_ba...@addfb25-x-tiled-mismatch-legacy.html * igt@kms_addfb_basic@addfb25-y-tiled-small-legacy: - bat-dg2-11: NOTRUN -> [SKIP][8] ([i915#5190]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116909v1/bat-dg2-11/igt@kms_addfb_ba...@addfb25-y-tiled-small-legacy.html * igt@kms_addfb_basic@basic-y-tiled-legacy: - bat-dg2-11: NOTRUN -> [SKIP][9] ([i915#4215] / [i915#5190]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116909v1/bat-dg2-11/igt@kms_addfb_ba...@basic-y-tiled-legacy.html * igt@kms_chamelium_hpd@vga-hpd-fast: - bat-dg2-11: NOTRUN -> [SKIP][10] ([i915#7828]) +8 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116909v1/bat-dg2-11/igt@kms_chamelium_...@vga-hpd-fast.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - bat-dg2-11: NOTRUN -> [SKIP][11] ([i915#4103] / [i915#4213]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116909v1/bat-dg2-11/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html * igt@kms_force_connector_basic@force-load-detect: - bat-dg2-11: NOTRUN -> [SKIP][12] ([fdo#109285]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116909v1/bat-dg2-11/igt@kms_force_connector_ba...@force-load-detect.html * igt@kms_force_connector_basic@prune-stale-modes: - bat-dg2-11: NOTRUN -> [SKIP][13] ([i915#5274]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116909v1/bat-dg2-11/igt@kms_force_connector_ba...@prune-stale-modes.html * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence: - bat-dg2-11: NOTRUN -> [SKIP][14] ([i915#5354]) +2 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116909v1/bat-dg2-11/igt@kms_pipe_crc_ba...@nonblocking-crc-frame-sequence.html * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence@pipe-d-dp-1: - bat-dg2-8: [PASS][15] -> [FAIL][16] ([i915#7932]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13056/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-crc-frame-seque...@pipe-d-dp-1.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116909v1/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-crc-frame-seque...@pipe-d-dp-1.html * igt@kms_psr@sprite_plane_onoff: - bat-dg2-11: NOTRUN -> [SKIP][17] ([i915#1072]) +3 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116909v1/bat-dg2-11/igt@kms_psr@sprite_plane_onoff.html * igt@kms_setmode@basic-clone-single-crtc: - bat-dg2-11: NOTRUN -> [SKIP][18] ([i915#3555] / [i915#4579]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116909v1/bat-dg2-11/igt@kms_setm...@basic-clone-single-crtc.html * igt@prime_vgem@basic-fence-flip: - b
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: use ref_tracker library for tracking wakerefs (rev9)
== Series Details ==
Series: drm/i915: use ref_tracker library for tracking wakerefs (rev9)
URL : https://patchwork.freedesktop.org/series/100327/
State : warning
== Summary ==
Error: dim checkpatch failed
b36b281bc951 lib/ref_tracker: add unlocked leak print helper
258df8024aa3 lib/ref_tracker: improve printing stats
01639e0ff3f5 lib/ref_tracker: add printing to memory buffer
-:54: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'fmt' - possible side-effects?
#54: FILE: lib/ref_tracker.c:70:
+#define pr_ostream(stream, fmt, args...) \
+({ \
+ struct ostream *_s = (stream); \
+\
+ if (!_s->buf) { \
+ pr_err(fmt, ##args); \
+ } else { \
+ int ret, len = _s->size - _s->used; \
+ ret = snprintf(_s->buf + _s->used, len, pr_fmt(fmt), ##args); \
+ _s->used += min(ret, len); \
+ } \
+})
total: 0 errors, 0 warnings, 1 checks, 109 lines checked
c550719bba07 lib/ref_tracker: remove warnings in case of allocation failure
e264da9fddbb drm/i915: Correct type of wakeref variable
f61172c5bde1 drm/i915: Replace custom intel runtime_pm tracker with ref_tracker
library
-:440: WARNING:NEW_TYPEDEFS: do not add new typedefs
#440: FILE: drivers/gpu/drm/i915/intel_wakeref.h:24:
+typedef unsigned long intel_wakeref_t;
total: 0 errors, 1 warnings, 0 checks, 431 lines checked
31bb5ae81e11 drm/i915: Track gt pm wakerefs
-:513: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'gt' - possible side-effects?
#513: FILE: drivers/gpu/drm/i915/gt/intel_gt_pm.h:75:
+#define with_intel_gt_pm(gt, wf) \
+ for (wf = intel_gt_pm_get(gt); wf; intel_gt_pm_put(gt, wf), wf = 0)
-:513: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'wf' - possible side-effects?
#513: FILE: drivers/gpu/drm/i915/gt/intel_gt_pm.h:75:
+#define with_intel_gt_pm(gt, wf) \
+ for (wf = intel_gt_pm_get(gt); wf; intel_gt_pm_put(gt, wf), wf = 0)
total: 0 errors, 0 warnings, 2 checks, 826 lines checked
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: use ref_tracker library for tracking wakerefs (rev9)
== Series Details == Series: drm/i915: use ref_tracker library for tracking wakerefs (rev9) URL : https://patchwork.freedesktop.org/series/100327/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: use ref_tracker library for tracking wakerefs (rev9)
== Series Details == Series: drm/i915: use ref_tracker library for tracking wakerefs (rev9) URL : https://patchwork.freedesktop.org/series/100327/ State : success == Summary == CI Bug Log - changes from CI_DRM_13056 -> Patchwork_100327v9 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_100327v9/index.html Participating hosts (39 -> 37) -- Missing(2): fi-kbl-soraka fi-snb-2520m Known issues Here are the changes found in Patchwork_100327v9 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s3@smem: - bat-rpls-1: NOTRUN -> [ABORT][1] ([i915#6687] / [i915#7978]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_100327v9/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html * igt@i915_selftest@live@slpc: - bat-rpls-1: NOTRUN -> [DMESG-FAIL][2] ([i915#6367] / [i915#7996]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_100327v9/bat-rpls-1/igt@i915_selftest@l...@slpc.html * igt@i915_suspend@basic-s2idle-without-i915: - fi-tgl-1115g4: [PASS][3] -> [ABORT][4] ([i915#8213]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13056/fi-tgl-1115g4/igt@i915_susp...@basic-s2idle-without-i915.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_100327v9/fi-tgl-1115g4/igt@i915_susp...@basic-s2idle-without-i915.html * igt@kms_pipe_crc_basic@suspend-read-crc@pipe-c-dp-3: - bat-dg2-9: [PASS][5] -> [FAIL][6] ([fdo#103375] / [i915#7932]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13056/bat-dg2-9/igt@kms_pipe_crc_basic@suspend-read-...@pipe-c-dp-3.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_100327v9/bat-dg2-9/igt@kms_pipe_crc_basic@suspend-read-...@pipe-c-dp-3.html * igt@kms_pipe_crc_basic@suspend-read-crc@pipe-d-dp-3: - bat-dg2-9: [PASS][7] -> [FAIL][8] ([fdo#103375]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13056/bat-dg2-9/igt@kms_pipe_crc_basic@suspend-read-...@pipe-d-dp-3.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_100327v9/bat-dg2-9/igt@kms_pipe_crc_basic@suspend-read-...@pipe-d-dp-3.html Possible fixes * igt@i915_selftest@live@gt_heartbeat: - fi-glk-j4005: [DMESG-FAIL][9] ([i915#5334]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13056/fi-glk-j4005/igt@i915_selftest@live@gt_heartbeat.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_100327v9/fi-glk-j4005/igt@i915_selftest@live@gt_heartbeat.html * igt@i915_selftest@live@migrate: - bat-atsm-1: [DMESG-FAIL][11] ([i915#7699]) -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13056/bat-atsm-1/igt@i915_selftest@l...@migrate.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_100327v9/bat-atsm-1/igt@i915_selftest@l...@migrate.html * igt@i915_selftest@live@reset: - bat-rpls-1: [ABORT][13] ([i915#4983] / [i915#8384]) -> [PASS][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13056/bat-rpls-1/igt@i915_selftest@l...@reset.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_100327v9/bat-rpls-1/igt@i915_selftest@l...@reset.html [fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375 [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983 [i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334 [i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367 [i915#6687]: https://gitlab.freedesktop.org/drm/intel/issues/6687 [i915#7699]: https://gitlab.freedesktop.org/drm/intel/issues/7699 [i915#7932]: https://gitlab.freedesktop.org/drm/intel/issues/7932 [i915#7978]: https://gitlab.freedesktop.org/drm/intel/issues/7978 [i915#7996]: https://gitlab.freedesktop.org/drm/intel/issues/7996 [i915#8213]: https://gitlab.freedesktop.org/drm/intel/issues/8213 [i915#8384]: https://gitlab.freedesktop.org/drm/intel/issues/8384 Build changes - * Linux: CI_DRM_13056 -> Patchwork_100327v9 CI-20190529: 20190529 CI_DRM_13056: 308c0163d9e46238948942260e6d2abcad3d8bff @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7267: a267f0236e06fc282e3dc3b8c7d76f9ed6088d9b @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_100327v9: 308c0163d9e46238948942260e6d2abcad3d8bff @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits d228ccbdaa95 drm/i915: Track gt pm wakerefs 92ea65873196 drm/i915: Replace custom intel runtime_pm tracker with ref_tracker library 336dd8060dc7 drm/i915: Correct type of wakeref variable 42364f5dc1d5 lib/ref_tracker: remove warnings in case of allocation failure 788748ceea86 lib/ref_tracker: add printing to memory buffer e964ded80869 lib/ref_tracker: improve printing stats fe2bacb27519 lib/ref_tracker: add unlocked
[Intel-gfx] ✓ Fi.CI.IGT: success for x86/mm: Fix PAT bit missing from page protection modify mask
== Series Details ==
Series: x86/mm: Fix PAT bit missing from page protection modify mask
URL : https://patchwork.freedesktop.org/series/116883/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13054_full -> Patchwork_116883v1_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (7 -> 7)
--
No changes in participating hosts
Known issues
Here are the changes found in Patchwork_116883v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_barrier_race@remote-request@rcs0:
- shard-apl: [PASS][1] -> [ABORT][2] ([i915#8211] / [i915#8234])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13054/shard-apl6/igt@gem_barrier_race@remote-requ...@rcs0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116883v1/shard-apl1/igt@gem_barrier_race@remote-requ...@rcs0.html
* igt@gen9_exec_parse@allowed-single:
- shard-apl: [PASS][3] -> [ABORT][4] ([i915#5566])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13054/shard-apl2/igt@gen9_exec_pa...@allowed-single.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116883v1/shard-apl3/igt@gen9_exec_pa...@allowed-single.html
* igt@i915_pm_rps@reset:
- shard-snb: [PASS][5] -> [INCOMPLETE][6] ([i915#7790])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13054/shard-snb6/igt@i915_pm_...@reset.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116883v1/shard-snb4/igt@i915_pm_...@reset.html
* igt@kms_color@ctm-green-to-red@pipe-a-hdmi-a-1:
- shard-snb: NOTRUN -> [SKIP][7] ([fdo#109271]) +36 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116883v1/shard-snb1/igt@kms_color@ctm-green-to-...@pipe-a-hdmi-a-1.html
* igt@kms_setmode@basic@pipe-a-hdmi-a-1:
- shard-snb: NOTRUN -> [FAIL][8] ([i915#5465]) +1 similar issue
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116883v1/shard-snb1/igt@kms_setmode@ba...@pipe-a-hdmi-a-1.html
* igt@perf@oa-exponents@0-rcs0:
- shard-glk: [PASS][9] -> [ABORT][10] ([i915#5213])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13054/shard-glk7/igt@perf@oa-expone...@0-rcs0.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116883v1/shard-glk6/igt@perf@oa-expone...@0-rcs0.html
Possible fixes
* igt@gem_eio@reset-stress:
- {shard-dg1}:[FAIL][11] ([i915#5784]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13054/shard-dg1-17/igt@gem_...@reset-stress.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116883v1/shard-dg1-17/igt@gem_...@reset-stress.html
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk: [FAIL][13] ([i915#2842]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13054/shard-glk2/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116883v1/shard-glk5/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
* igt@i915_pm_rc6_residency@rc6-idle@vecs0:
- {shard-dg1}:[FAIL][15] ([i915#3591]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13054/shard-dg1-14/igt@i915_pm_rc6_residency@rc6-i...@vecs0.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116883v1/shard-dg1-16/igt@i915_pm_rc6_residency@rc6-i...@vecs0.html
* igt@i915_pm_rpm@modeset-non-lpsp:
- {shard-rkl}:[SKIP][17] ([i915#1397]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13054/shard-rkl-7/igt@i915_pm_...@modeset-non-lpsp.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116883v1/shard-rkl-3/igt@i915_pm_...@modeset-non-lpsp.html
* igt@i915_pm_rps@engine-order:
- shard-apl: [FAIL][19] ([i915#6537]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13054/shard-apl3/igt@i915_pm_...@engine-order.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116883v1/shard-apl4/igt@i915_pm_...@engine-order.html
* igt@kms_async_flips@alternate-sync-async-flip@pipe-a-hdmi-a-1:
- shard-glk: [FAIL][21] ([i915#2521]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13054/shard-glk1/igt@kms_async_flips@alternate-sync-async-f...@pipe-a-hdmi-a-1.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116883v1/shard-glk4/igt@kms_async_flips@alternate-sync-async-f...@pipe-a-hdmi-a-1.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions:
- shard-glk: [FAIL][23] ([i915#2346]) -> [PASS][24]
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13054/shard-glk9/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116883v1/shard-glk8/igt@kms_cursor_leg...@flip-vs-cursor-
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Improvements to uc firmare management (rev4)
== Series Details == Series: Improvements to uc firmare management (rev4) URL : https://patchwork.freedesktop.org/series/116517/ State : warning == Summary == Error: dim checkpatch failed 767fe16369d4 drm/i915/guc: Decode another GuC load failure case 95f43703948d drm/i915/guc: Print status register when waiting for GuC to load 739f30be54fc drm/i915/uc: Track patch level versions on reduced version firmware files -:61: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'major_' - possible side-effects? #61: FILE: drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:200: +#define GUC_FW_BLOB(prefix_, major_, minor_, patch_) \ + UC_FW_BLOB_NEW(major_, minor_, patch_, false, \ + MAKE_GUC_FW_PATH_MAJOR(prefix_, major_, minor_, patch_)) -:61: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'minor_' - possible side-effects? #61: FILE: drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:200: +#define GUC_FW_BLOB(prefix_, major_, minor_, patch_) \ + UC_FW_BLOB_NEW(major_, minor_, patch_, false, \ + MAKE_GUC_FW_PATH_MAJOR(prefix_, major_, minor_, patch_)) -:61: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'patch_' - possible side-effects? #61: FILE: drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:200: +#define GUC_FW_BLOB(prefix_, major_, minor_, patch_) \ + UC_FW_BLOB_NEW(major_, minor_, patch_, false, \ + MAKE_GUC_FW_PATH_MAJOR(prefix_, major_, minor_, patch_)) total: 0 errors, 0 warnings, 3 checks, 73 lines checked e4b70f34344b drm/i915/uc: Enhancements to firmware table validation 1f175721171c drm/i915/uc: Reject duplicate entries in firmware table 4d4fd1a1efe2 drm/i915/uc: Make unexpected firmware versions an error in debug builds
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Improvements to uc firmare management (rev4)
== Series Details == Series: Improvements to uc firmare management (rev4) URL : https://patchwork.freedesktop.org/series/116517/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✓ Fi.CI.BAT: success for Improvements to uc firmare management (rev4)
== Series Details ==
Series: Improvements to uc firmare management (rev4)
URL : https://patchwork.freedesktop.org/series/116517/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13056 -> Patchwork_116517v4
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116517v4/index.html
Participating hosts (39 -> 38)
--
Missing(1): fi-snb-2520m
Known issues
Here are the changes found in Patchwork_116517v4 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@gt_heartbeat:
- fi-kbl-soraka: [PASS][1] -> [DMESG-FAIL][2] ([i915#5334] /
[i915#7872])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13056/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116517v4/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html
* igt@kms_pipe_crc_basic@nonblocking-crc@pipe-d-dp-1:
- bat-dg2-8: [PASS][3] -> [FAIL][4] ([i915#7932]) +1 similar issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13056/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-...@pipe-d-dp-1.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116517v4/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-...@pipe-d-dp-1.html
Possible fixes
* igt@i915_selftest@live@gt_heartbeat:
- fi-glk-j4005: [DMESG-FAIL][5] ([i915#5334]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13056/fi-glk-j4005/igt@i915_selftest@live@gt_heartbeat.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116517v4/fi-glk-j4005/igt@i915_selftest@live@gt_heartbeat.html
* igt@kms_addfb_basic@unused-modifier:
- fi-kbl-soraka: [INCOMPLETE][7] -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13056/fi-kbl-soraka/igt@kms_addfb_ba...@unused-modifier.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116517v4/fi-kbl-soraka/igt@kms_addfb_ba...@unused-modifier.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
[i915#7872]: https://gitlab.freedesktop.org/drm/intel/issues/7872
[i915#7932]: https://gitlab.freedesktop.org/drm/intel/issues/7932
[i915#8176]: https://gitlab.freedesktop.org/drm/intel/issues/8176
[i915#8361]: https://gitlab.freedesktop.org/drm/intel/issues/8361
Build changes
-
* Linux: CI_DRM_13056 -> Patchwork_116517v4
CI-20190529: 20190529
CI_DRM_13056: 308c0163d9e46238948942260e6d2abcad3d8bff @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7267: a267f0236e06fc282e3dc3b8c7d76f9ed6088d9b @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_116517v4: 308c0163d9e46238948942260e6d2abcad3d8bff @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
73551022be0b drm/i915/uc: Make unexpected firmware versions an error in debug
builds
88e712f9b743 drm/i915/uc: Reject duplicate entries in firmware table
167ae011abe2 drm/i915/uc: Enhancements to firmware table validation
840667ca3eca drm/i915/uc: Track patch level versions on reduced version
firmware files
bc3e7163bbb3 drm/i915/guc: Print status register when waiting for GuC to load
5f41dc0364f0 drm/i915/guc: Decode another GuC load failure case
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116517v4/index.html
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/mtl: add PTE encode function (rev2)
== Series Details ==
Series: drm/i915/mtl: add PTE encode function (rev2)
URL : https://patchwork.freedesktop.org/series/116868/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13055_full -> Patchwork_116868v2_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (7 -> 8)
--
Additional (1): shard-rkl0
Known issues
Here are the changes found in Patchwork_116868v2_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_barrier_race@remote-request@rcs0:
- shard-glk: [PASS][1] -> [ABORT][2] ([i915#8211])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13055/shard-glk2/igt@gem_barrier_race@remote-requ...@rcs0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116868v2/shard-glk1/igt@gem_barrier_race@remote-requ...@rcs0.html
* igt@gem_exec_fair@basic-deadline:
- shard-glk: [PASS][3] -> [FAIL][4] ([i915#2846])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13055/shard-glk2/igt@gem_exec_f...@basic-deadline.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116868v2/shard-glk1/igt@gem_exec_f...@basic-deadline.html
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-apl: [PASS][5] -> [FAIL][6] ([i915#2842])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13055/shard-apl2/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116868v2/shard-apl6/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
* igt@kms_async_flips@alternate-sync-async-flip@pipe-a-hdmi-a-1:
- shard-glk: [PASS][7] -> [FAIL][8] ([i915#2521])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13055/shard-glk3/igt@kms_async_flips@alternate-sync-async-f...@pipe-a-hdmi-a-1.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116868v2/shard-glk5/igt@kms_async_flips@alternate-sync-async-f...@pipe-a-hdmi-a-1.html
* igt@kms_color@ctm-green-to-red@pipe-a-hdmi-a-1:
- shard-snb: NOTRUN -> [SKIP][9] ([fdo#109271]) +35 similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116868v2/shard-snb1/igt@kms_color@ctm-green-to-...@pipe-a-hdmi-a-1.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size:
- shard-apl: [PASS][10] -> [FAIL][11] ([i915#2346])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13055/shard-apl6/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions-varying-size.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116868v2/shard-apl1/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions-varying-size.html
Possible fixes
* igt@drm_fdinfo@most-busy-idle-check-all@rcs0:
- {shard-rkl}:[FAIL][12] ([i915#7742]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13055/shard-rkl-4/igt@drm_fdinfo@most-busy-idle-check-...@rcs0.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116868v2/shard-rkl-6/igt@drm_fdinfo@most-busy-idle-check-...@rcs0.html
* igt@gem_exec_fair@basic-none-solo@rcs0:
- shard-apl: [FAIL][14] ([i915#2842]) -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13055/shard-apl7/igt@gem_exec_fair@basic-none-s...@rcs0.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116868v2/shard-apl4/igt@gem_exec_fair@basic-none-s...@rcs0.html
* igt@gem_exec_fair@basic-pace-share@rcs0:
- {shard-tglu}: [FAIL][16] ([i915#2842]) -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13055/shard-tglu-6/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116868v2/shard-tglu-8/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
* igt@gem_exec_fair@basic-pace@rcs0:
- {shard-rkl}:[FAIL][18] ([i915#2842]) -> [PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13055/shard-rkl-1/igt@gem_exec_fair@basic-p...@rcs0.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116868v2/shard-rkl-2/igt@gem_exec_fair@basic-p...@rcs0.html
* igt@i915_pm_rpm@dpms-mode-unset-lpsp:
- {shard-rkl}:[SKIP][20] ([i915#1397]) -> [PASS][21] +1 similar
issue
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13055/shard-rkl-3/igt@i915_pm_...@dpms-mode-unset-lpsp.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116868v2/shard-rkl-7/igt@i915_pm_...@dpms-mode-unset-lpsp.html
* igt@i915_selftest@live@gt_heartbeat:
- shard-apl: [DMESG-FAIL][22] ([i915#5334]) -> [PASS][23]
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13055/shard-apl3/igt@i915_selftest@live@gt_heartbeat.html
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116868v2/shard-apl1/igt@i915_selftest@live@gt_heartbeat.html
* igt@kms_cursor_legacy@forked-move@pipe-b:
-
[Intel-gfx] [PATCHv3] drm/i915/display/dp: 128/132b LT requirement
For 128b/132b LT prior to LT DPTX should set power state, DP channel
coding and then link rate.
v2: added separate function to avoid code duplication(Jani N)
v3: DP2.1 section 3.5.2.16 is ordered, 3.5.1.2 is unordered and hence
discarding
Signed-off-by: Arun R Murthy
---
.../drm/i915/display/intel_dp_link_training.c | 56 +--
1 file changed, 38 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
index 6aa4ae5e7ebe..27eb41499d7e 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
@@ -637,6 +637,37 @@ static bool intel_dp_link_max_vswing_reached(struct
intel_dp *intel_dp,
return true;
}
+static void
+intel_dp_update_downspread_ctrl(struct intel_dp *intel_dp,
+ const struct intel_crtc_state *crtc_state)
+{
+ u8 link_config[2];
+
+ link_config[0] = crtc_state->vrr.flipline ? DP_MSA_TIMING_PAR_IGNORE_EN
: 0;
+ link_config[1] = intel_dp_is_uhbr(crtc_state) ?
+DP_SET_ANSI_128B132B : DP_SET_ANSI_8B10B;
+ drm_dp_dpcd_write(&intel_dp->aux, DP_DOWNSPREAD_CTRL, link_config, 2);
+}
+
+static void
+intel_dp_update_link_bw_set(struct intel_dp *intel_dp,
+ const struct intel_crtc_state *crtc_state,
+ u8 link_bw, u8 rate_select)
+{
+ u8 link_config[2];
+
+ /* Write the link configuration data */
+ link_config[0] = link_bw;
+ link_config[1] = crtc_state->lane_count;
+ if (drm_dp_enhanced_frame_cap(intel_dp->dpcd))
+ link_config[1] |= DP_LANE_COUNT_ENHANCED_FRAME_EN;
+ drm_dp_dpcd_write(&intel_dp->aux, DP_LINK_BW_SET, link_config, 2);
+ /* eDP 1.4 rate select method. */
+ if (!link_bw)
+ drm_dp_dpcd_write(&intel_dp->aux, DP_LINK_RATE_SET,
+ &rate_select, 1);
+}
+
/*
* Prepare link training by configuring the link parameters. On DDI platforms
* also enable the port here.
@@ -647,7 +678,6 @@ intel_dp_prepare_link_train(struct intel_dp *intel_dp,
{
struct intel_encoder *encoder = &dp_to_dig_port(intel_dp)->base;
struct drm_i915_private *i915 = to_i915(encoder->base.dev);
- u8 link_config[2];
u8 link_bw, rate_select;
if (intel_dp->prepare_link_retrain)
@@ -686,23 +716,13 @@ intel_dp_prepare_link_train(struct intel_dp *intel_dp,
drm_dbg_kms(&i915->drm,
"[ENCODER:%d:%s] Using LINK_RATE_SET value %02x\n",
encoder->base.base.id, encoder->base.name,
rate_select);
-
- /* Write the link configuration data */
- link_config[0] = link_bw;
- link_config[1] = crtc_state->lane_count;
- if (drm_dp_enhanced_frame_cap(intel_dp->dpcd))
- link_config[1] |= DP_LANE_COUNT_ENHANCED_FRAME_EN;
- drm_dp_dpcd_write(&intel_dp->aux, DP_LINK_BW_SET, link_config, 2);
-
- /* eDP 1.4 rate select method. */
- if (!link_bw)
- drm_dp_dpcd_write(&intel_dp->aux, DP_LINK_RATE_SET,
- &rate_select, 1);
-
- link_config[0] = crtc_state->vrr.flipline ? DP_MSA_TIMING_PAR_IGNORE_EN
: 0;
- link_config[1] = intel_dp_is_uhbr(crtc_state) ?
- DP_SET_ANSI_128B132B : DP_SET_ANSI_8B10B;
- drm_dp_dpcd_write(&intel_dp->aux, DP_DOWNSPREAD_CTRL, link_config, 2);
+ /*
+* Spec DP2.1 Section 3.5.2.16
+* Prior to LT DPTX should set 128b/132b DP Channel coding and then set
link rate
+*/
+ intel_dp_update_downspread_ctrl(intel_dp, crtc_state);
+ intel_dp_update_link_bw_set(intel_dp, crtc_state, link_bw,
+ rate_select);
return true;
}
--
2.25.1
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display/dp: 128/132b LT requirement (rev4)
== Series Details ==
Series: drm/i915/display/dp: 128/132b LT requirement (rev4)
URL : https://patchwork.freedesktop.org/series/116562/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13056 -> Patchwork_116562v4
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116562v4/index.html
Participating hosts (39 -> 37)
--
Missing(2): fi-kbl-soraka fi-snb-2520m
Known issues
Here are the changes found in Patchwork_116562v4 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s3@smem:
- bat-rpls-1: NOTRUN -> [ABORT][1] ([i915#6687] / [i915#7978])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116562v4/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html
* igt@i915_selftest@live@slpc:
- bat-rpls-1: NOTRUN -> [DMESG-FAIL][2] ([i915#6367] / [i915#7996])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116562v4/bat-rpls-1/igt@i915_selftest@l...@slpc.html
* igt@kms_pipe_crc_basic@nonblocking-crc@pipe-d-dp-1:
- bat-dg2-8: [PASS][3] -> [FAIL][4] ([i915#7932])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13056/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-...@pipe-d-dp-1.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116562v4/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-...@pipe-d-dp-1.html
Possible fixes
* igt@i915_selftest@live@gt_heartbeat:
- fi-glk-j4005: [DMESG-FAIL][5] ([i915#5334]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13056/fi-glk-j4005/igt@i915_selftest@live@gt_heartbeat.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116562v4/fi-glk-j4005/igt@i915_selftest@live@gt_heartbeat.html
* igt@i915_selftest@live@migrate:
- bat-atsm-1: [DMESG-FAIL][7] ([i915#7699]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13056/bat-atsm-1/igt@i915_selftest@l...@migrate.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116562v4/bat-atsm-1/igt@i915_selftest@l...@migrate.html
* igt@i915_selftest@live@reset:
- bat-rpls-1: [ABORT][9] ([i915#4983] / [i915#8384]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13056/bat-rpls-1/igt@i915_selftest@l...@reset.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116562v4/bat-rpls-1/igt@i915_selftest@l...@reset.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
[i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
[i915#6687]: https://gitlab.freedesktop.org/drm/intel/issues/6687
[i915#7699]: https://gitlab.freedesktop.org/drm/intel/issues/7699
[i915#7932]: https://gitlab.freedesktop.org/drm/intel/issues/7932
[i915#7978]: https://gitlab.freedesktop.org/drm/intel/issues/7978
[i915#7996]: https://gitlab.freedesktop.org/drm/intel/issues/7996
[i915#8176]: https://gitlab.freedesktop.org/drm/intel/issues/8176
[i915#8361]: https://gitlab.freedesktop.org/drm/intel/issues/8361
[i915#8384]: https://gitlab.freedesktop.org/drm/intel/issues/8384
Build changes
-
* Linux: CI_DRM_13056 -> Patchwork_116562v4
CI-20190529: 20190529
CI_DRM_13056: 308c0163d9e46238948942260e6d2abcad3d8bff @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7267: a267f0236e06fc282e3dc3b8c7d76f9ed6088d9b @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_116562v4: 308c0163d9e46238948942260e6d2abcad3d8bff @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
30ae6e72ee71 drm/i915/display/dp: 128/132b LT requirement
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116562v4/index.html
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/selftest: Record GT error for gt failure
== Series Details ==
Series: drm/i915/selftest: Record GT error for gt failure
URL : https://patchwork.freedesktop.org/series/116890/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13056_full -> Patchwork_116890v1_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (7 -> 7)
--
No changes in participating hosts
Known issues
Here are the changes found in Patchwork_116890v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_mmap_gtt@fault-concurrent-y:
- shard-snb: [PASS][1] -> [ABORT][2] ([i915#5161])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13056/shard-snb4/igt@gem_mmap_...@fault-concurrent-y.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116890v1/shard-snb2/igt@gem_mmap_...@fault-concurrent-y.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions:
- shard-glk: [PASS][3] -> [FAIL][4] ([i915#2346])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13056/shard-glk8/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116890v1/shard-glk4/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size:
- shard-apl: [PASS][5] -> [FAIL][6] ([i915#2346])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13056/shard-apl6/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions-varying-size.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116890v1/shard-apl6/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions-varying-size.html
* igt@kms_dither@fb-8bpc-vs-panel-6bpc@pipe-a-hdmi-a-1:
- shard-glk: NOTRUN -> [SKIP][7] ([fdo#109271])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116890v1/shard-glk4/igt@kms_dither@fb-8bpc-vs-panel-6...@pipe-a-hdmi-a-1.html
*
igt@kms_plane_scaling@planes-downscale-factor-0-25-unity-scaling@pipe-a-hdmi-a-1:
- shard-snb: NOTRUN -> [SKIP][8] ([fdo#109271]) +8 similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116890v1/shard-snb1/igt@kms_plane_scaling@planes-downscale-factor-0-25-unity-scal...@pipe-a-hdmi-a-1.html
Possible fixes
* igt@gem_barrier_race@remote-request@rcs0:
- {shard-tglu}: [ABORT][9] ([i915#8211]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13056/shard-tglu-6/igt@gem_barrier_race@remote-requ...@rcs0.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116890v1/shard-tglu-5/igt@gem_barrier_race@remote-requ...@rcs0.html
* igt@gem_exec_fair@basic-deadline:
- {shard-rkl}:[FAIL][11] ([i915#2846]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13056/shard-rkl-6/igt@gem_exec_f...@basic-deadline.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116890v1/shard-rkl-3/igt@gem_exec_f...@basic-deadline.html
* igt@gem_exec_fair@basic-none@vcs0:
- {shard-rkl}:[FAIL][13] ([i915#2842]) -> [PASS][14] +3 similar
issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13056/shard-rkl-4/igt@gem_exec_fair@basic-n...@vcs0.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116890v1/shard-rkl-4/igt@gem_exec_fair@basic-n...@vcs0.html
* igt@gem_ppgtt@blt-vs-render-ctxn:
- shard-snb: [FAIL][15] -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13056/shard-snb1/igt@gem_pp...@blt-vs-render-ctxn.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116890v1/shard-snb7/igt@gem_pp...@blt-vs-render-ctxn.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions:
- shard-apl: [FAIL][17] ([i915#2346]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13056/shard-apl7/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116890v1/shard-apl1/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
* igt@kms_cursor_legacy@forked-move@pipe-b:
- {shard-dg1}:[INCOMPLETE][19] ([i915#8011] / [i915#8347]) ->
[PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13056/shard-dg1-14/igt@kms_cursor_legacy@forked-m...@pipe-b.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116890v1/shard-dg1-17/igt@kms_cursor_legacy@forked-m...@pipe-b.html
* igt@kms_flip@2x-flip-vs-expired-vblank@ac-hdmi-a1-hdmi-a2:
- shard-glk: [FAIL][21] ([i915#79]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13056/shard-glk4/igt@kms_flip@2x-flip-vs-expired-vbl...@ac-hdmi-a1-hdmi-a2.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116890v1/shard-glk9/igt@kms_flip@2x-flip-vs-expired-vbl...@ac-hdmi-a1-hdmi-a2.html
*
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/mtl: Add PTE encode functions (rev2)
== Series Details ==
Series: drm/i915/mtl: Add PTE encode functions (rev2)
URL : https://patchwork.freedesktop.org/series/116900/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13056_full -> Patchwork_116900v2_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (7 -> 7)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_116900v2_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_spin_batch@resubmit-all@bcs0:
- {shard-tglu}: [PASS][1] -> [ABORT][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13056/shard-tglu-6/igt@gem_spin_batch@resubmit-...@bcs0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116900v2/shard-tglu-2/igt@gem_spin_batch@resubmit-...@bcs0.html
* igt@gem_spin_batch@resubmit-all@vecs0:
- {shard-tglu}: [PASS][3] -> [DMESG-WARN][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13056/shard-tglu-6/igt@gem_spin_batch@resubmit-...@vecs0.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116900v2/shard-tglu-2/igt@gem_spin_batch@resubmit-...@vecs0.html
Known issues
Here are the changes found in Patchwork_116900v2_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_barrier_race@remote-request@rcs0:
- shard-glk: [PASS][5] -> [ABORT][6] ([i915#8211])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13056/shard-glk8/igt@gem_barrier_race@remote-requ...@rcs0.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116900v2/shard-glk4/igt@gem_barrier_race@remote-requ...@rcs0.html
* igt@gem_exec_fair@basic-deadline:
- shard-glk: [PASS][7] -> [FAIL][8] ([i915#2846])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13056/shard-glk8/igt@gem_exec_f...@basic-deadline.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116900v2/shard-glk4/igt@gem_exec_f...@basic-deadline.html
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk: [PASS][9] -> [FAIL][10] ([i915#2842])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13056/shard-glk5/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116900v2/shard-glk7/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-apl: [PASS][11] -> [FAIL][12] ([i915#2842]) +1 similar
issue
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13056/shard-apl1/igt@gem_exec_fair@basic-pace-s...@rcs0.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116900v2/shard-apl6/igt@gem_exec_fair@basic-pace-s...@rcs0.html
* igt@gen9_exec_parse@allowed-all:
- shard-apl: [PASS][13] -> [ABORT][14] ([i915#5566]) +1 similar
issue
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13056/shard-apl4/igt@gen9_exec_pa...@allowed-all.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116900v2/shard-apl2/igt@gen9_exec_pa...@allowed-all.html
* igt@i915_pm_rps@reset:
- shard-snb: [PASS][15] -> [INCOMPLETE][16] ([i915#7790])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13056/shard-snb4/igt@i915_pm_...@reset.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116900v2/shard-snb4/igt@i915_pm_...@reset.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size:
- shard-apl: [PASS][17] -> [FAIL][18] ([i915#2346])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13056/shard-apl6/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions-varying-size.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116900v2/shard-apl3/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions-varying-size.html
* igt@kms_flip@2x-flip-vs-expired-vblank-interruptible@ab-hdmi-a1-hdmi-a2:
- shard-glk: [PASS][19] -> [FAIL][20] ([i915#79])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13056/shard-glk8/igt@kms_flip@2x-flip-vs-expired-vblank-interrupti...@ab-hdmi-a1-hdmi-a2.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116900v2/shard-glk6/igt@kms_flip@2x-flip-vs-expired-vblank-interrupti...@ab-hdmi-a1-hdmi-a2.html
* igt@kms_flip@plain-flip-ts-check@c-hdmi-a1:
- shard-glk: [PASS][21] -> [FAIL][22] ([i915#2122])
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13056/shard-glk8/igt@kms_flip@plain-flip-ts-ch...@c-hdmi-a1.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116900v2/shard-glk6/igt@kms_flip@plain-flip-ts-ch...@c-hdmi-a1.html
*
igt@kms_plane_scaling@planes-downscale-factor-0-25-unity-scaling@pipe-a-hdmi-a
[Intel-gfx] [linux-next:master] BUILD REGRESSION 3b85b9b39960c08f29fa91b8d984d055dde6017e
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master branch HEAD: 3b85b9b39960c08f29fa91b8d984d055dde6017e Add linux-next specific files for 20230424 Error/Warning reports: https://lore.kernel.org/oe-kbuild-all/202304102354.q4voxgte-...@intel.com https://lore.kernel.org/oe-kbuild-all/202304210303.nlmi0srq-...@intel.com https://lore.kernel.org/oe-kbuild-all/202304210349.dykci88s-...@intel.com https://lore.kernel.org/oe-kbuild-all/202304230014.ybscpx20-...@intel.com https://lore.kernel.org/oe-kbuild-all/202304250419.ytcltuhg-...@intel.com Error/Warning: (recently discovered and may have been fixed) arch/um/drivers/harddog_user.c:6:10: fatal error: stdio.h: No such file or directory drivers/accel/habanalabs/gaudi/gaudi.c:117:19: warning: unused variable 'gaudi_irq_name' [-Wunused-const-variable] drivers/base/regmap/regcache-maple.c:113:23: warning: 'lower_index' is used uninitialized [-Wuninitialized] drivers/base/regmap/regcache-maple.c:113:36: warning: 'lower_last' is used uninitialized [-Wuninitialized] drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c:456:16: warning: variable 'j' set but not used [-Wunused-but-set-variable] drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c:1078:6: warning: no previous prototype for 'gfx_v9_4_3_disable_gpa_mode' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c:1078:6: warning: no previous prototype for function 'gfx_v9_4_3_disable_gpa_mode' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c:48:38: warning: unused variable 'golden_settings_gc_9_4_3' [-Wunused-const-variable] drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:62: warning: wrong kernel-doc identifier on line: drivers/gpu/drm/i915/i915_pmu.h:41: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst drivers/gpu/drm/i915/i915_request.h:176: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst drivers/gpu/drm/i915/i915_vma.h:145: warning: expecting prototype for i915_vma_offset(). Prototype was for i915_vma_size() instead drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c:298:6: warning: variable 'ret' is uninitialized when used here [-Wuninitialized] fs/ext4/super.c:1262:13: warning: unused variable 'i' [-Wunused-variable] fs/ext4/super.c:1262:6: warning: unused variable 'i' [-Wunused-variable] ld.lld: error: .btf.vmlinux.bin.o: unknown file type Unverified Error/Warning (likely false positive, please contact us if interested): drivers/acpi/property.c:985 acpi_data_prop_read_single() error: potentially dereferencing uninitialized 'obj'. Error/Warning ids grouped by kconfigs: gcc_recent_errors |-- alpha-allyesconfig | |-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:no-previous-prototype-for-gfx_v9_4_3_disable_gpa_mode |-- arc-allyesconfig | |-- drivers-base-regmap-regcache-maple.c:warning:lower_index-is-used-uninitialized | |-- drivers-base-regmap-regcache-maple.c:warning:lower_last-is-used-uninitialized | |-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:no-previous-prototype-for-gfx_v9_4_3_disable_gpa_mode |-- arc-randconfig-r043-20230424 | |-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:no-previous-prototype-for-gfx_v9_4_3_disable_gpa_mode |-- arm-allmodconfig | |-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:no-previous-prototype-for-gfx_v9_4_3_disable_gpa_mode |-- arm-allyesconfig | |-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:no-previous-prototype-for-gfx_v9_4_3_disable_gpa_mode |-- arm64-allyesconfig | |-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:no-previous-prototype-for-gfx_v9_4_3_disable_gpa_mode |-- arm64-buildonly-randconfig-r001-20230423 | |-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:no-previous-prototype-for-gfx_v9_4_3_disable_gpa_mode |-- i386-allyesconfig | |-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:no-previous-prototype-for-gfx_v9_4_3_disable_gpa_mode |-- i386-randconfig-a011-20230424 | `-- fs-ext4-super.c:warning:unused-variable-i |-- i386-randconfig-a016-20230424 | `-- fs-ext4-super.c:warning:unused-variable-i |-- i386-randconfig-
[Intel-gfx] ✓ Fi.CI.IGT: success for Restore MTL boot (rev2)
== Series Details ==
Series: Restore MTL boot (rev2)
URL : https://patchwork.freedesktop.org/series/116894/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13056_full -> Patchwork_116894v2_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (7 -> 7)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_116894v2_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_workarounds@basic-read-context:
- {shard-dg1}:[PASS][1] -> [DMESG-WARN][2] +1 similar issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13056/shard-dg1-15/igt@gem_workarou...@basic-read-context.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116894v2/shard-dg1-14/igt@gem_workarou...@basic-read-context.html
Known issues
Here are the changes found in Patchwork_116894v2_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_barrier_race@remote-request@rcs0:
- shard-apl: [PASS][3] -> [ABORT][4] ([i915#8211] / [i915#8234])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13056/shard-apl2/igt@gem_barrier_race@remote-requ...@rcs0.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116894v2/shard-apl3/igt@gem_barrier_race@remote-requ...@rcs0.html
* igt@gem_exec_fair@basic-deadline:
- shard-glk: [PASS][5] -> [FAIL][6] ([i915#2846])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13056/shard-glk8/igt@gem_exec_f...@basic-deadline.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116894v2/shard-glk3/igt@gem_exec_f...@basic-deadline.html
* igt@kms_color@ctm-max@pipe-b-dp-1:
- shard-apl: [PASS][7] -> [DMESG-WARN][8] ([i915#62]) +8 similar
issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13056/shard-apl1/igt@kms_color@ctm-...@pipe-b-dp-1.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116894v2/shard-apl1/igt@kms_color@ctm-...@pipe-b-dp-1.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size:
- shard-apl: [PASS][9] -> [FAIL][10] ([i915#2346])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13056/shard-apl6/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions-varying-size.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116894v2/shard-apl6/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions-varying-size.html
* igt@kms_dither@fb-8bpc-vs-panel-6bpc@pipe-a-hdmi-a-1:
- shard-glk: NOTRUN -> [SKIP][11] ([fdo#109271])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116894v2/shard-glk3/igt@kms_dither@fb-8bpc-vs-panel-6...@pipe-a-hdmi-a-1.html
* igt@kms_flip@plain-flip-ts-check-interruptible@c-dp1:
- shard-apl: [PASS][12] -> [FAIL][13] ([i915#2122])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13056/shard-apl2/igt@kms_flip@plain-flip-ts-check-interrupti...@c-dp1.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116894v2/shard-apl6/igt@kms_flip@plain-flip-ts-check-interrupti...@c-dp1.html
* igt@kms_frontbuffer_tracking@fbc-badstride:
- shard-snb: [PASS][14] -> [SKIP][15] ([fdo#109271])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13056/shard-snb5/igt@kms_frontbuffer_track...@fbc-badstride.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116894v2/shard-snb6/igt@kms_frontbuffer_track...@fbc-badstride.html
Possible fixes
* igt@gem_barrier_race@remote-request@rcs0:
- {shard-tglu}: [ABORT][16] ([i915#8211]) -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13056/shard-tglu-6/igt@gem_barrier_race@remote-requ...@rcs0.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116894v2/shard-tglu-7/igt@gem_barrier_race@remote-requ...@rcs0.html
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- {shard-rkl}:[FAIL][18] ([i915#2842]) -> [PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13056/shard-rkl-7/igt@gem_exec_fair@basic-pace-s...@rcs0.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116894v2/shard-rkl-4/igt@gem_exec_fair@basic-pace-s...@rcs0.html
* igt@gem_ppgtt@blt-vs-render-ctxn:
- shard-snb: [FAIL][20] ([i915#8295]) -> [PASS][21]
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13056/shard-snb1/igt@gem_pp...@blt-vs-render-ctxn.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116894v2/shard-snb1/igt@gem_pp...@blt-vs-render-ctxn.html
* igt@i915_pm_lpsp@kms-lpsp@kms-lpsp-hdmi-a:
- {shard-dg1}:[SKIP][22] ([i915#1937]) -> [PASS][23]
[22]:
https://intel-gfx-ci.01.
Re: [Intel-gfx] [PATCH] drm/i915/adlp+: Disable DC5/6 states for TC port DDI/AUX and for combo port AUX
On 24.04.2023 22:02, Imre Deak wrote:
On ADLP+ Bspec allows DC5/6 to be enabled while power well 2 is enabled.
Since the AUX and DDI power wells (except for port A/B) are also backed
by power well 2, this would suggest that DC5/6 can be enabled while any
of these AUX or DDI port functionalities are used. As opposed to this
AUX transfers will time out on ADLP TypeC ports while DC6 is enabled.
Until the restriction for DC5/6 is clarified in Bspec let's assume that
the intention is to allow for using these power states while pipe A/B is
enabled, but only for combo ports which can be used with eDP outputs.
Similarly assume that AUX transaction initiated by the driver on any port
requires DC states to be disabled.
Cc: Matt Roper
Cc: Radhakrishna Sripada
Fixes: 88c487938414 ("drm/i915: Use separate "DC off" power well for ADL-P and
DG2")
Signed-off-by: Imre Deak
Great it revives bat-dg2-11.
Reviewed-by: Andrzej Hajda
Regards
Andrzej
---
.../i915/display/intel_display_power_map.c| 28 +++
1 file changed, 16 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_power_map.c
b/drivers/gpu/drm/i915/display/intel_display_power_map.c
index 100582f105905..ca448359a8226 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power_map.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power_map.c
@@ -1251,22 +1251,11 @@ I915_DECL_PW_DOMAINS(xelpd_pwdoms_pw_a,
POWER_DOMAIN_PIPE_PANEL_FITTER_A,
POWER_DOMAIN_INIT);
-#define XELPD_PW_2_POWER_DOMAINS \
- XELPD_PW_B_POWER_DOMAINS, \
- XELPD_PW_C_POWER_DOMAINS, \
- XELPD_PW_D_POWER_DOMAINS, \
- POWER_DOMAIN_PORT_DDI_LANES_C, \
- POWER_DOMAIN_PORT_DDI_LANES_D, \
- POWER_DOMAIN_PORT_DDI_LANES_E, \
+#define XELPD_DC_OFF_PORT_POWER_DOMAINS \
POWER_DOMAIN_PORT_DDI_LANES_TC1, \
POWER_DOMAIN_PORT_DDI_LANES_TC2, \
POWER_DOMAIN_PORT_DDI_LANES_TC3, \
POWER_DOMAIN_PORT_DDI_LANES_TC4, \
- POWER_DOMAIN_VGA, \
- POWER_DOMAIN_AUDIO_PLAYBACK, \
- POWER_DOMAIN_AUX_IO_C, \
- POWER_DOMAIN_AUX_IO_D, \
- POWER_DOMAIN_AUX_IO_E, \
POWER_DOMAIN_AUX_C, \
POWER_DOMAIN_AUX_D, \
POWER_DOMAIN_AUX_E, \
@@ -1279,6 +1268,20 @@ I915_DECL_PW_DOMAINS(xelpd_pwdoms_pw_a,
POWER_DOMAIN_AUX_TBT3, \
POWER_DOMAIN_AUX_TBT4
+#define XELPD_PW_2_POWER_DOMAINS \
+ XELPD_PW_B_POWER_DOMAINS, \
+ XELPD_PW_C_POWER_DOMAINS, \
+ XELPD_PW_D_POWER_DOMAINS, \
+ POWER_DOMAIN_PORT_DDI_LANES_C, \
+ POWER_DOMAIN_PORT_DDI_LANES_D, \
+ POWER_DOMAIN_PORT_DDI_LANES_E, \
+ POWER_DOMAIN_VGA, \
+ POWER_DOMAIN_AUDIO_PLAYBACK, \
+ POWER_DOMAIN_AUX_IO_C, \
+ POWER_DOMAIN_AUX_IO_D, \
+ POWER_DOMAIN_AUX_IO_E, \
+ XELPD_DC_OFF_PORT_POWER_DOMAINS
+
I915_DECL_PW_DOMAINS(xelpd_pwdoms_pw_2,
XELPD_PW_2_POWER_DOMAINS,
POWER_DOMAIN_INIT);
@@ -1301,6 +1304,7 @@ I915_DECL_PW_DOMAINS(xelpd_pwdoms_pw_2,
*/
I915_DECL_PW_DOMAINS(xelpd_pwdoms_dc_off,
+ XELPD_DC_OFF_PORT_POWER_DOMAINS,
XELPD_PW_C_POWER_DOMAINS,
XELPD_PW_D_POWER_DOMAINS,
POWER_DOMAIN_PORT_DSI,
Re: [Intel-gfx] [PATCH 1/2] Revert "drm/i915/mtl: fix mocs selftest"
On 24.04.2023 18:09, Andi Shyti wrote:
This reverts commit faca6aaa4838c3c234caa619d3c7d1f09da0d303.
This patch, in series with the next "Define MOCS and PAT tables
for MTL" are causing boot failures for MTL.
Revert them both.
Signed-off-by: Andi Shyti
Cc: Fei Yang
Cc: Matt Roper
Reviewed-by: Andrzej Hajda
Regards
Andrzej
---
drivers/gpu/drm/i915/gt/selftest_mocs.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_mocs.c
b/drivers/gpu/drm/i915/gt/selftest_mocs.c
index a8446ab825012..ca009a6a13bdb 100644
--- a/drivers/gpu/drm/i915/gt/selftest_mocs.c
+++ b/drivers/gpu/drm/i915/gt/selftest_mocs.c
@@ -131,14 +131,13 @@ static int read_mocs_table(struct i915_request *rq,
const struct drm_i915_mocs_table *table,
u32 *offset)
{
- struct intel_gt *gt = rq->engine->gt;
u32 addr;
if (!table)
return 0;
if (HAS_GLOBAL_MOCS_REGISTERS(rq->engine->i915))
- addr = global_mocs_offset() + gt->uncore->gsi_offset;
+ addr = global_mocs_offset();
else
addr = mocs_offset(rq->engine);
Re: [Intel-gfx] [PATCH 2/2] Revert "drm/i915/mtl: Define MOCS and PAT tables for MTL"
On 24.04.2023 18:09, Andi Shyti wrote:
This reverts commit b76c0deef6273609c02ed5053209f6397cd1b0fb.
This patch is causing boot failures for MTL.
Revert it.
Signed-off-by: Andi Shyti
Cc: Matt Roper
Cc: Lucas De Marchi
Cc: Aravind Iddamsetty
Cc: Nirmoy Das
Cc: Fei Yang
Cc: Andrzej Hajda
Reviewed-by: Andrzej Hajda
Regards
Andrzej
---
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 6 +--
drivers/gpu/drm/i915/gt/intel_gtt.c | 47 +
drivers/gpu/drm/i915/gt/intel_gtt.h | 8 ---
drivers/gpu/drm/i915/gt/intel_mocs.c| 70 +
4 files changed, 3 insertions(+), 128 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index e8c3b762a92a3..fd1f9cd35e9d7 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -356,11 +356,7 @@
#define GEN7_TLB_RD_ADDR _MMIO(0x4700)
#define GEN12_PAT_INDEX(index) _MMIO(0x4800 + (index) * 4)
-#define _PAT_INDEX(index) _PICK_EVEN_2RANGES(index, 8, \
- 0x4800,
0x4804, \
- 0x4848,
0x484c)
-#define XEHP_PAT_INDEX(index) MCR_REG(_PAT_INDEX(index))
-#define XELPMP_PAT_INDEX(index)_MMIO(_PAT_INDEX(index))
+#define XEHP_PAT_INDEX(index) MCR_REG(0x4800 + (index) * 4)
#define XEHP_TILE0_ADDR_RANGE MCR_REG(0x4900)
#define XEHP_TILE_LMEM_RANGE_SHIFT 8
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c
b/drivers/gpu/drm/i915/gt/intel_gtt.c
index 2f6a9be0ffe61..4f436ba7a3c83 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
@@ -468,44 +468,6 @@ void gtt_write_workarounds(struct intel_gt *gt)
}
}
-static void xelpmp_setup_private_ppat(struct intel_uncore *uncore)
-{
- intel_uncore_write(uncore, XELPMP_PAT_INDEX(0),
- MTL_PPAT_L4_0_WB);
- intel_uncore_write(uncore, XELPMP_PAT_INDEX(1),
- MTL_PPAT_L4_1_WT);
- intel_uncore_write(uncore, XELPMP_PAT_INDEX(2),
- MTL_PPAT_L4_3_UC);
- intel_uncore_write(uncore, XELPMP_PAT_INDEX(3),
- MTL_PPAT_L4_0_WB | MTL_2_COH_1W);
- intel_uncore_write(uncore, XELPMP_PAT_INDEX(4),
- MTL_PPAT_L4_0_WB | MTL_3_COH_2W);
-
- /*
-* Remaining PAT entries are left at the hardware-default
-* fully-cached setting
-*/
-}
-
-static void xelpg_setup_private_ppat(struct intel_gt *gt)
-{
- intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(0),
-MTL_PPAT_L4_0_WB);
- intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(1),
-MTL_PPAT_L4_1_WT);
- intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(2),
-MTL_PPAT_L4_3_UC);
- intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(3),
-MTL_PPAT_L4_0_WB | MTL_2_COH_1W);
- intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(4),
-MTL_PPAT_L4_0_WB | MTL_3_COH_2W);
-
- /*
-* Remaining PAT entries are left at the hardware-default
-* fully-cached setting
-*/
-}
-
static void tgl_setup_private_ppat(struct intel_uncore *uncore)
{
/* TGL doesn't support LLC or AGE settings */
@@ -641,14 +603,7 @@ void setup_private_pat(struct intel_gt *gt)
GEM_BUG_ON(GRAPHICS_VER(i915) < 8);
- if (gt->type == GT_MEDIA) {
- xelpmp_setup_private_ppat(gt->uncore);
- return;
- }
-
- if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 70))
- xelpg_setup_private_ppat(gt);
- else if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 50))
+ if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 50))
xehp_setup_private_ppat(gt);
else if (GRAPHICS_VER(i915) >= 12)
tgl_setup_private_ppat(uncore);
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h
b/drivers/gpu/drm/i915/gt/intel_gtt.h
index ea17849e7a5c8..69ce55f517f56 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
@@ -147,14 +147,6 @@ typedef u64 gen8_pte_t;
#define GEN8_PDE_IPS_64K BIT(11)
#define GEN8_PDE_PS_2M BIT(7)
-#define MTL_PPAT_L4_CACHE_POLICY_MASK REG_GENMASK(3, 2)
-#define MTL_PAT_INDEX_COH_MODE_MASKREG_GENMASK(1, 0)
-#define MTL_PPAT_L4_3_UC REG_FIELD_PREP(MTL_PPAT_L4_CACHE_POLICY_MASK, 3)
-#define MTL_PPAT_L4_1_WT REG_FIELD_PREP(MTL_PPAT_L4_CACHE_POLICY_MASK, 1)
-#define MTL_PPAT_L4_0_WB REG_FIELD_PREP(MTL_PPAT_L4_CACHE_POLICY_MASK, 0)
-#define MTL_3_COH_2W REG_FIELD_PREP(MTL_PAT_INDEX_COH_MODE_MASK, 3)
-#define MTL_2_COH_1W REG_FIELD_PREP(MTL_PAT_INDEX_COH_MODE_MASK, 2)
-
en
