Re: [Intel-gfx] [PATCH] drm/i915/gt: Fix -EDEADLK handling regression

[Maarten Lankhorst]

Op 30-06-2021 om 18:44 schreef Ville Syrjala:
> From: Ville Syrjälä 
>
> The conversion to ww mutexes failed to address the fence code which
> already returns -EDEADLK when we run out of fences. Ww mutexes on
> the other hand treat -EDEADLK as an internal errno value indicating
> a need to restart the operation due to a deadlock. So now when the
> fence code returns -EDEADLK the higher level code erroneously
> restarts everything instead of returning the error to userspace
> as is expected.
>
> To remedy this let's switch the fence code to use a different errno
> value for this. -ENOBUFS seems like a semi-reasonable unique choice.
> Apart from igt the only user of this I could find is sna, and even
> there all we do is dump the current fence registers from debugfs
> into the X server log. So no user visible functionality is affected.
> If we really cared about preserving this we could of course convert
> back to -EDEADLK higher up, but doesn't seem like that's worth
> the hassle here.
>
> Not quite sure which commit specifically broke this, but I'll
> just attribute it to the general gem ww mutex work.
>
> Cc: sta...@vger.kernel.org
> Cc: Maarten Lankhorst 
> Cc: Thomas Hellström 
> Testcase: igt/gem_pread/exhaustion
> Testcase: igt/gem_pwrite/basic-exhaustion
> Testcase: igt/gem_fenced_exec_thrash/too-many-fences
> Fixes: 80f0b679d6f0 ("drm/i915: Add an implementation for i915_gem_ww_ctx 
> locking, v2.")
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c 
> b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
> index cac7f3f44642..f8948de72036 100644
> --- a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
> +++ b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
> @@ -348,7 +348,7 @@ static struct i915_fence_reg *fence_find(struct i915_ggtt 
> *ggtt)
>   if (intel_has_pending_fb_unpin(ggtt->vm.i915))
>   return ERR_PTR(-EAGAIN);
>  
> - return ERR_PTR(-EDEADLK);
> + return ERR_PTR(-ENOBUFS);
>  }
>  
>  int __i915_vma_pin_fence(struct i915_vma *vma)

Makes sense..

Reviewed-by: Maarten Lankhorst 

Is it a slightly more reent commit? Might probably be the part that converts 
execbuffer to use ww locks.

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v4 03/17] drm/uAPI: Add "active bpc" as feedback channel for "max bpc" drm property

[Pekka Paalanen]

On Wed, 30 Jun 2021 11:42:10 +0200
Werner Sembach  wrote:

> Am 30.06.21 um 10:21 schrieb Pekka Paalanen:
> > On Tue, 29 Jun 2021 13:02:05 +0200
> > Werner Sembach  wrote:
> >  
> >> Am 28.06.21 um 19:03 schrieb Werner Sembach:  
> >>> Am 18.06.21 um 11:11 schrieb Werner Sembach:  
>  Add a new general drm property "active bpc" which can be used by graphic
>  drivers to report the applied bit depth per pixel back to userspace.
> 
>  While "max bpc" can be used to change the color depth, there was no way 
>  to
>  check which one actually got used. While in theory the driver chooses the
>  best/highest color depth within the max bpc setting a user might not be
>  fully aware what his hardware is or isn't capable off. This is meant as a
>  quick way to double check the setup.
> 
>  In the future, automatic color calibration for screens might also depend 
>  on
>  this information being available.
> 
>  Signed-off-by: Werner Sembach 
>  ---
>    drivers/gpu/drm/drm_connector.c | 51 +
>    include/drm/drm_connector.h |  8 ++
>    2 files changed, 59 insertions(+)
> 
>  diff --git a/drivers/gpu/drm/drm_connector.c 
>  b/drivers/gpu/drm/drm_connector.c
>  index da39e7ff6965..943f6b61053b 100644
>  --- a/drivers/gpu/drm/drm_connector.c
>  +++ b/drivers/gpu/drm/drm_connector.c
>  @@ -1197,6 +1197,14 @@ static const struct drm_prop_enum_list 
>  dp_colorspaces[] = {
> * drm_connector_attach_max_bpc_property() to create and attach the
> * property to the connector during initialization.
> *
>  + * active bpc:
>  + *  This read-only range property tells userspace the pixel color 
>  bit depth
>  + *  actually used by the hardware display engine on "the cable" on a
>  + *  connector. The chosen value depends on hardware capabilities, 
>  both
>  + *  display engine and connected monitor, and the "max bpc" 
>  property.
>  + *  Drivers shall use drm_connector_attach_active_bpc_property() to 
>  install
>  + *  this property.
>  + *  
> >>> Regarding "on the cable" and dithering: As far as I can tell, what the 
> >>> dithering option does, is setting a hardware
> >>> register here:
> >>>
> >>> - 
> >>> https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/i915/display/intel_display.c#L4534
> >>>
> >>> - 
> >>> https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/i915/display/intel_display.c#L4571
> >>>
> >>> So dithering seems to be calculated by fixed purpose hardware/firmware 
> >>> outside of the driver?
> >>>
> >>> The Intel driver does not seem to set a target bpc/bpp for this hardware 
> >>> so I guess it defaults to 6 or 8 bpc?  
> >> Never mind it does. This switch-case does affect the dithering output:
> >> https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/i915/display/intel_display.c#L4537
> >>   
> > Hi,
> >
> > I obviously do not know the intel driver or hardware at all, but
> > to me that just looks like translating from bits per pixel to bits per
> > channel in RGB mapping?  
> No, if i understand the documentation correctly: Writing bit depth here 
> with dithering enabled sets the dithering target bpc.
> >  
> >> As found in this documentation p.548:
> >> https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-lkf-vol02c-commandreference-registers-part2.pdf
> >>
> >> So max bpc and active bpc are affecting/affected by the bpc after 
> >> dithering.  
> > By definition, if the cable carries N bpc, then dithering does not
> > change that. The cable still carries N bpc, but due to spatial or
> > temporal dithering, the *observed* color resolution may or may not be
> > higher than the cable bpc.  
> Yes, and max bpc and active bpc tell the cable bpc ist not the 
> *observed* bpc.
> >
> > Of course, if the cable bpc is 8, and dithering targets 6 bpc, then 2
> > LSB on the cable are always zero, right?  
> I would assume that in this case only 6 bpc are actually send? Isn't the 
> whole thing of dithering that you can't send, for example, 8 bpc?
> >
> > Maybe one would want to do that if the monitor has a 6 bit panel and it
> > simply ignored the 2 LSB, and the cable cannot go down to 6 bpc.  
> 
> Is there dithering actually doing this? aka is my assumption above wrong?
> 
> AMD code that confused me before, is hinting that you might be right: 
> https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/amd/display/dc/dce/dce_transform.c#L826
> 
> there is a set_clamp depth and a separate DCP_SPATIAL_DITHER_DEPTH_30BPP
> 
> >
> > So, what does "max bpc" mean right now?
> >
> > It seems like dither on/off is insufficient information, one would also
> > need to control the dithering target bpc. I suppose the driver has a
> > policy on how it chooses the target bpc, but what is that policy? Is
> > the dither target bpc t

Re: [Intel-gfx] [PATCH v4 12/17] drm/uAPI: Add "preferred color format" drm property as setting for userspace

[Pekka Paalanen]

On Wed, 30 Jun 2021 11:20:18 +0200
Werner Sembach  wrote:

> Am 30.06.21 um 10:41 schrieb Pekka Paalanen:
> 
> > On Tue, 29 Jun 2021 13:39:18 +0200
> > Werner Sembach  wrote:
> >  
> >> Am 29.06.21 um 13:17 schrieb Pekka Paalanen:  
> >>> On Tue, 29 Jun 2021 08:12:54 +
> >>> Simon Ser  wrote:
> >>> 
>  On Tuesday, June 22nd, 2021 at 09:15, Pekka Paalanen 
>   wrote:
>  
> > yes, I think this makes sense, even if it is a property that one can't
> > tell for sure what it does before hand.
> >
> > Using a pair of properties, preference and active, to ask for something
> > and then check what actually worked is good for reducing the
> > combinatorial explosion caused by needing to "atomic TEST_ONLY commit"
> > test different KMS configurations. Userspace has a better chance of
> > finding a configuration that is possible.
> >
> > OTOH, this has the problem than in UI one cannot tell the user in
> > advance which options are truly possible. Given that KMS properties are
> > rarely completely independent, and in this case known to depend on
> > several other KMS properties, I think it is good enough to know after
> > the fact.
> >
> > If a driver does not use what userspace prefers, there is no way to
> > understand why, or what else to change to make it happen. That problem
> > exists anyway, because TEST_ONLY commits do not give useful feedback
> > but only a yes/no.  
>  By submitting incremental atomic reqs with TEST_ONLY (i.e. only changing 
>  one
>  property at a time), user-space can discover which property makes the 
>  atomic
>  commit fail.  
> >>> That works if the properties are independent of each other. Color
> >>> range, color format, bpc and more may all be interconnected,
> >>> allowing only certain combinations to work.
> >>>
> >>> If all these properties have "auto" setting too, then it would be
> >>> possible to probe each property individually, but that still does not
> >>> tell which combinations are valid.
> >>>
> >>> If you probe towards a certain configuration by setting the properties
> >>> one by one, then depending on the order you pick the properties, you
> >>> may come to a different conclusion on which property breaks the
> >>> configuration.  
> >> My mind crossed another point that must be considered: When plugin in
> >> a Monitor a list of possible Resolutions+Framerate combinations is
> >> created for xrandr and other userspace (I guess by atomic checks? but
> >> I don't know).  
> > Hi,
> >
> > I would not think so, but I hope to be corrected if I'm wrong.
> >
> > My belief is that the driver collects a list of modes from EDID, some
> > standard modes, and maybe some other hardcoded modes, and then
> > validates each entry against all the known limitations like vertical
> > and horizontal frequency limits, discarding modes that do not fit.
> >
> > Not all limitations are known during that phase, which is why KMS
> > property "link-status" exists. When userspace actually programs a mode
> > (not a TEST_ONLY commit), the link training may fail. The kernel prunes
> > the mode from the list and sets the link status property to signal
> > failure, and sends a hotplug uevent. Userspace needs to re-check the
> > mode list and try again.
> >
> > That is a generic escape hatch for when TEST_ONLY commit succeeds, but
> > in reality the hardware cannot do it, you just cannot know until you
> > actually try for real. It causes end user visible flicker if it happens
> > on an already running connector, but since it usually happens when
> > turning a connector on to begin with, there is no flicker to be seen,
> > just a small delay in finding a mode that works.
> >  
> >> During this drm
> >> properties are already considered, which is no problem atm because as
> >> far as i can tell there is currently no drm property that would make
> >> a certain Resolutions+Framerate combination unreachable that would be
> >> possible with everything on default.  
> > I would not expect KMS properties to be considered at all. It would
> > reject modes that are actually possible if the some KMS properties were
> > changed. So at least going forward, current KMS property values cannot
> > factor in.  
> 
> At least the debugfs variable "force_yuv420_output" did change the 
> available modes here: 
> https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c#L5165
>  
> before my patch 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=68eb3ae3c63708f823aeeb63bb15197c727bd9bf

Hi,

debugfs is not proper UAPI, so we can just ignore it. Display servers
cannot be expected to poke in debugfs. Debugfs is not even supposed to
exist in production systems, but I'm sure people use it for hacking
stuff. But that's all it is for: developer testing and hacking.

> Forcing a color format via a DRM property in this function would 
> rei

Re: [Intel-gfx] [PATCH 47/47] drm/i915/guc: Unblock GuC submission on Gen11+

[Pekka Paalanen]

On Wed, 30 Jun 2021 11:58:25 -0700
John Harrison  wrote:

> On 6/30/2021 01:22, Martin Peres wrote:
> > On 24/06/2021 10:05, Matthew Brost wrote:  
> >> From: Daniele Ceraolo Spurio 
> >>
> >> Unblock GuC submission on Gen11+ platforms.
> >>
> >> Signed-off-by: Michal Wajdeczko 
> >> Signed-off-by: Daniele Ceraolo Spurio 
> >> Signed-off-by: Matthew Brost 
> >> ---
> >>   drivers/gpu/drm/i915/gt/uc/intel_guc.h    |  1 +
> >>   drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c |  8 
> >>   drivers/gpu/drm/i915/gt/uc/intel_guc_submission.h |  3 +--
> >>   drivers/gpu/drm/i915/gt/uc/intel_uc.c | 14 +-
> >>   4 files changed, 19 insertions(+), 7 deletions(-)
> >>

...

> >> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c 
> >> b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> >> index 7a69c3c027e9..61be0aa81492 100644
> >> --- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> >> +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> >> @@ -34,8 +34,15 @@ static void uc_expand_default_options(struct 
> >> intel_uc *uc)
> >>   return;
> >>   }
> >>   -    /* Default: enable HuC authentication only */
> >> -    i915->params.enable_guc = ENABLE_GUC_LOAD_HUC;
> >> +    /* Intermediate platforms are HuC authentication only */
> >> +    if (IS_DG1(i915) || IS_ALDERLAKE_S(i915)) {
> >> +    drm_dbg(&i915->drm, "Disabling GuC only due to old 
> >> platform\n");  
> >
> > This comment does not seem accurate, given that DG1 is barely out, and 
> > ADL is not out yet. How about:
> >
> > "Disabling GuC on untested platforms"?
> >  
> Just because something is not in the shops yet does not mean it is new. 
> Technology is always obsolete by the time it goes on sale.

That is a very good reason to not use terminology like "new", "old",
"current", "modern" etc. at all.

End users like me definitely do not share your interpretation of "old".


Thanks,
pq


> And the issue is not a lack of testing, it is a question of whether we 
> are allowed to change the default on something that has already started 
> being used by customers or not (including pre-release beta customers). 
> I.e. it is basically a political decision not an engineering decision.



pgpu6Rzg_2OT7.pgp
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PULL] drm-intel-next-fixes

[Jani Nikula]

On Wed, 30 Jun 2021, Rodrigo Vivi  wrote:
> On Wed, Jun 30, 2021 at 01:05:35PM +0300, Jani Nikula wrote:
>> On Tue, 29 Jun 2021, Rodrigo Vivi  wrote:
>> > Hi Dave and Daniel,
>> >
>> > Here goes drm-intel-next-fixes-2021-06-29:
>> >
>> > The biggest fix is the restoration of mmap ioctl for gen12 integrated parts
>> > which lack was breaking ADL-P with media stack.
>> > Besides that a small selftest fix and a theoretical overflow on
>> > i915->pipe_to_crtc_mapping.
>> 
>> My last fixes pull for v5.13 fell between the cracks [1]. There was one
>> stable worthy fix, but since it was still in drm-intel-fixes when you
>> ran dim cherry-pick-next-fixes, it was skipped for drm-intel-next-fixes.
>> 
>> I've now dropped the commit and pushed v5.13 to drm-intel-fixes, as
>> we're past that point. Subsequent dim cherry-pick-next-fixes should pick
>> it up now.
>
> it didn't, probably because the Fixes hash not being part of the drm-next 
> yet?!

Odd, should be.

> I can cherry-pick that directly. Please let me know the commit id.

c88e2647c5bb ("drm/i915/display: Do not zero past infoframes.vsc")

Thanks,
Jani.


>
> Thanks,
> Rodrigo.
>
>> 
>> Please do another next fixes pull request with that. (It's okay to pull
>> this one already though, doesn't make a difference.)
>> 
>> 
>> BR,
>> Jani.
>> 
>> 
>> [1] https://lore.kernel.org/r/87czsbu15r@intel.com
>> 
>> 
>> 
>> >
>> > Thanks,
>> > Rodrigo.
>> >
>> > The following changes since commit 
>> > 1bd8a7dc28c1c410f1ceefae1f2a97c06d1a67c2:
>> >
>> >   Merge tag 'exynos-drm-next-for-v5.14' of 
>> > git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into 
>> > drm-next (2021-06-11 14:19:12 +1000)
>> >
>> > are available in the Git repository at:
>> >
>> >   git://anongit.freedesktop.org/drm/drm-intel 
>> > tags/drm-intel-next-fixes-2021-06-29
>> >
>> > for you to fetch changes up to c90c4c6574f3feaf2203b5671db1907a1e15c653:
>> >
>> >   drm/i915: Reinstate the mmap ioctl for some platforms (2021-06-28 
>> > 07:43:56 -0400)
>> >
>> > 
>> > The biggest fix is the restoration of mmap ioctl for gen12 integrated parts
>> > which lack was breaking ADL-P with media stack.
>> > Besides that a small selftest fix and a theoretical overflow on
>> > i915->pipe_to_crtc_mapping.
>> >
>> > 
>> > Chris Wilson (1):
>> >   drm/i915/selftests: Reorder tasklet_disable vs local_bh_disable
>> >
>> > Jani Nikula (1):
>> >   drm/i915/dsc: abstract helpers to get bigjoiner primary/secondary 
>> > crtc
>> >
>> > Thomas Hellström (1):
>> >   drm/i915: Reinstate the mmap ioctl for some platforms
>> >
>> >  drivers/gpu/drm/i915/display/intel_display.c   |  7 ++-
>> >  drivers/gpu/drm/i915/display/intel_display_types.h |  8 
>> >  drivers/gpu/drm/i915/display/intel_vdsc.c  | 40 +++-
>> >  drivers/gpu/drm/i915/display/intel_vdsc.h  |  1 +
>> >  drivers/gpu/drm/i915/gem/i915_gem_mman.c   |  7 +--
>> >  drivers/gpu/drm/i915/gt/selftest_execlists.c   | 55 
>> > +-
>> >  6 files changed, 76 insertions(+), 42 deletions(-)
>> 
>> -- 
>> Jani Nikula, Intel Open Source Graphics Center

-- 
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v4 1/2] drm/i915: Use the correct IRQ during resume

[Thomas Zimmermann]

The code in xcs_resume() probably didn't work as intended. It uses
struct drm_device.irq, which is allocated to 0, but never initialized
by i915 to the device's interrupt number.

Change all calls to synchronize_hardirq() to intel_synchronize_irq(),
which uses the correct interrupt. _hardirq() functions are not needed
in this context.

v4:
* switch everything to intel_synchronize_irq() (Daniel)
v3:
* also use intel_synchronize_hardirq() at another callsite
v2:
* wrap irq code in intel_synchronize_hardirq() (Ville)

Signed-off-by: Thomas Zimmermann 
Fixes: 536f77b1caa0 ("drm/i915/gt: Call stop_ring() from ring resume, again")
Cc: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Daniel Vetter 
Cc: Rodrigo Vivi 
Cc: Joonas Lahtinen 
Cc: Maarten Lankhorst 
Cc: Lucas De Marchi 
---
 drivers/gpu/drm/i915/gt/intel_engine_cs.c   | 2 +-
 drivers/gpu/drm/i915/gt/intel_ring_submission.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 88694822716a..8a2a54d2d739 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1229,7 +1229,7 @@ bool intel_engine_is_idle(struct intel_engine_cs *engine)
return true;
 
/* Waiting to drain ELSP? */
-   synchronize_hardirq(to_pci_dev(engine->i915->drm.dev)->irq);
+   intel_synchronize_irq(engine->i915);
intel_engine_flush_submission(engine);
 
/* ELSP is empty, but there are ready requests? E.g. after reset */
diff --git a/drivers/gpu/drm/i915/gt/intel_ring_submission.c 
b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
index 5d42a12ef3d6..d50b515b0c55 100644
--- a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
@@ -185,7 +185,7 @@ static int xcs_resume(struct intel_engine_cs *engine)
 ring->head, ring->tail);
 
/* Double check the ring is empty & disabled before we resume */
-   synchronize_hardirq(engine->i915->drm.irq);
+   intel_synchronize_irq(engine->i915);
if (!stop_ring(engine))
goto err;
 
-- 
2.32.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v4 0/2] drm/i915: IRQ fixes

[Thomas Zimmermann]

Fix a bug in the usage of IRQs and cleanup references to the DRM
IRQ midlayer.

Preferably this patchset would be merged through drm-misc-next.

v4:
* switch IRQ code to intel_synchronize_irq() (Daniel)
v3:
* also use intel_synchronize_hardirq() from other callsite
v2:
* split patch
* also fix comment
* add intel_synchronize_hardirq() (Ville)
* update Fixes tag (Daniel)

Thomas Zimmermann (2):
  drm/i915: Use the correct IRQ during resume
  drm/i915: Drop all references to DRM IRQ midlayer

 drivers/gpu/drm/i915/gt/intel_engine_cs.c   | 2 +-
 drivers/gpu/drm/i915/gt/intel_ring_submission.c | 2 +-
 drivers/gpu/drm/i915/i915_drv.c | 1 -
 drivers/gpu/drm/i915/i915_irq.c | 5 -
 4 files changed, 2 insertions(+), 8 deletions(-)


base-commit: 67f5a18128770817e4218a9e496d2bf5047c51e8
--
2.32.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v4 2/2] drm/i915: Drop all references to DRM IRQ midlayer

[Thomas Zimmermann]

Remove all references to DRM's IRQ midlayer. i915 uses Linux' interrupt
functions directly.

v2:
* also remove an outdated comment
* move IRQ fix into separate patch
* update Fixes tag (Daniel)

Signed-off-by: Thomas Zimmermann 
Fixes: b318b82455bd ("drm/i915: Nuke drm_driver irq vfuncs")
Cc: Ville Syrjälä 
Cc: Chris Wilson 
Cc: Jani Nikula 
Cc: Joonas Lahtinen 
Cc: Rodrigo Vivi 
Cc: intel-gfx@lists.freedesktop.org
---
 drivers/gpu/drm/i915/i915_drv.c | 1 -
 drivers/gpu/drm/i915/i915_irq.c | 5 -
 2 files changed, 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 850b499c71c8..73de45472f60 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -42,7 +42,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 7d0ce8b9f8ed..2de51ea83e09 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -33,7 +33,6 @@
 #include 
 
 #include 
-#include 
 
 #include "display/intel_de.h"
 #include "display/intel_display_types.h"
@@ -4564,10 +4563,6 @@ void intel_runtime_pm_enable_interrupts(struct 
drm_i915_private *dev_priv)
 
 bool intel_irqs_enabled(struct drm_i915_private *dev_priv)
 {
-   /*
-* We only use drm_irq_uninstall() at unload and VT switch, so
-* this is the only thing we need to check.
-*/
return dev_priv->runtime_pm.irqs_enabled;
 }
 
-- 
2.32.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915/display: check if compressed_llb was allocated

[Matthew Auld]

If we hit the error path here we unconditionally call
i915_gem_stolen_remove_node, even though we only allocate the
compressed_llb on older platforms. Therefore we should first check that
we actually allocated the node before trying to remove it.

References: https://gitlab.freedesktop.org/drm/intel/-/issues/3709
Fixes: 46b2c40e0af3 ("drm/i915/fbc: Allocate llb before cfb")
Signed-off-by: Matthew Auld 
Cc: Ville Syrjälä 
Cc: José Roberto de Souza 
---
 drivers/gpu/drm/i915/display/intel_fbc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c 
b/drivers/gpu/drm/i915/display/intel_fbc.c
index 7dc72e4a4656..82effb64a3b9 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -516,7 +516,8 @@ static int intel_fbc_alloc_cfb(struct drm_i915_private 
*dev_priv,
return 0;
 
 err_llb:
-   i915_gem_stolen_remove_node(dev_priv, &fbc->compressed_llb);
+   if (drm_mm_node_allocated(&fbc->compressed_llb))
+   i915_gem_stolen_remove_node(dev_priv, &fbc->compressed_llb);
 err:
if (drm_mm_initialized(&dev_priv->mm.stolen))
drm_info_once(&dev_priv->drm, "not enough stolen space for 
compressed buffer (need %d more bytes), disabling. Hint: you may be able to 
increase stolen memory size in the BIOS to avoid this.\n", size);
-- 
2.26.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PULL] drm-misc-next-fixes

[Thomas Zimmermann]

Hi Dave and Daniel,

this week's PR for drm-misc-next-fixes contains a number of BO-related
fixes in amdgpu, gma500 and radeon, and a documentation fix for dma-buf.

Best regards
Thomas

drm-misc-next-fixes-2021-07-01:
Short summary of fixes pull:

 * amdgpu: TTM fixes
 * dma-buf: Doc fixes
 * gma500: Fix potential BO leaks in error handling
 * radeon: Fix NULL-ptr deref
The following changes since commit eed75ce7c8260e0d5612ced4a88180ab991e207c:

  drm/amdgpu: fix amdgpu_preempt_mgr_new() (2021-06-21 15:24:29 +0200)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-fixes-2021-07-01

for you to fetch changes up to f18f58012ee894039cd59ee8c889bf499d7a3943:

  drm/radeon: Fix NULL dereference when updating memory stats (2021-06-30 
11:56:21 +0200)


Short summary of fixes pull:

 * amdgpu: TTM fixes
 * dma-buf: Doc fixes
 * gma500: Fix potential BO leaks in error handling
 * radeon: Fix NULL-ptr deref


Jing Xiangfeng (1):
  drm/gma500: Add the missed drm_gem_object_put() in 
psb_user_framebuffer_create()

Mikel Rychliski (1):
  drm/radeon: Fix NULL dereference when updating memory stats

Nirmoy Das (1):
  drm/amdgpu: return early for non-TTM_PL_TT type BOs

Randy Dunlap (1):
  : correct a function name in kernel-doc

 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c |  3 ++-
 drivers/gpu/drm/gma500/framebuffer.c|  7 ++-
 drivers/gpu/drm/radeon/radeon_object.c  | 29 -
 drivers/gpu/drm/radeon/radeon_object.h  |  2 +-
 drivers/gpu/drm/radeon/radeon_ttm.c | 13 ++---
 include/linux/dma-resv.h|  2 +-
 6 files changed, 32 insertions(+), 24 deletions(-)

--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: IRQ fixes (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915: IRQ fixes (rev3)
URL   : https://patchwork.freedesktop.org/series/92053/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+drivers/gpu/drm/i915/gt/intel_ring_submission.c:1207:24: warning: Using plain 
integer as NULL pointer


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [v3 1/2] drm/i915/display/dsc: Add Per connector debugfs node for DSC BPP enable

[venkata . sai . patnana]

From: Patnana Venkata Sai 

[What]:
This patch creates a per connector debugfs node to expose
the Input and Compressed BPP.

The same node can be used from userspace to force
DSC to a certain BPP(all accepted values).

[Why]:
Useful to verify all supported/requested compression bpp's
through IGT

Cc: Vandita Kulkarni 
Cc: Navare Manasi D 
Cc: Jani Nikula 
Signed-off-by: Anusha Srivatsa 
Signed-off-by: Patnana Venkata Sai 
---
 .../drm/i915/display/intel_display_debugfs.c  | 76 ++-
 .../drm/i915/display/intel_display_types.h|  1 +
 2 files changed, 76 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c 
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index af9e58619667d..2305a0c2498cc 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -2389,6 +2389,73 @@ static const struct file_operations 
i915_dsc_fec_support_fops = {
.write = i915_dsc_fec_support_write
 };
 
+static int i915_dsc_bpp_support_show(struct seq_file *m, void *data)
+{
+   struct drm_connector *connector = m->private;
+   struct drm_device *dev = connector->dev;
+   struct drm_crtc *crtc;
+   struct intel_crtc_state *crtc_state = NULL;
+   int ret = 0;
+
+   ret = 
drm_modeset_lock_single_interruptible(&dev->mode_config.connection_mutex);
+   if (ret)
+   return ret;
+
+   crtc = connector->state->crtc;
+   crtc_state = to_intel_crtc_state(crtc->state);
+   seq_printf(m, "Input_BPP: %d\n", crtc_state->pipe_bpp);
+   seq_printf(m, "Compressed_BPP: %d\n",
+   crtc_state->dsc.compressed_bpp);
+
+   drm_modeset_unlock(&dev->mode_config.connection_mutex);
+
+   return ret;
+}
+
+static ssize_t i915_dsc_bpp_support_write(struct file *file,
+   const char __user *ubuf,
+   size_t len, loff_t *offp)
+{
+   int dsc_bpp = 0;
+   int ret;
+   struct drm_connector *connector =
+   ((struct seq_file *)file->private_data)->private;
+   struct intel_encoder *encoder = 
intel_attached_encoder(to_intel_connector(connector));
+   struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+   struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+
+   if (len == 0)
+   return 0;
+
+   drm_dbg(&i915->drm,
+   "Copied %zu bytes from user to force BPP\n", len);
+
+   ret = kstrtoint_from_user(ubuf, len, 0, &dsc_bpp);
+
+   intel_dp->force_dsc_bpp = dsc_bpp;
+   if (ret < 0)
+   return ret;
+
+   *offp += len;
+   return len;
+}
+
+static int i915_dsc_bpp_support_open(struct inode *inode,
+  struct file *file)
+{
+   return single_open(file, i915_dsc_bpp_support_show,
+  inode->i_private);
+}
+
+static const struct file_operations i915_dsc_bpp_support_fops = {
+   .owner = THIS_MODULE,
+   .open = i915_dsc_bpp_support_open,
+   .read = seq_read,
+   .llseek = seq_lseek,
+   .release = single_release,
+   .write = i915_dsc_bpp_support_write
+};
+
 /**
  * intel_connector_debugfs_add - add i915 specific connector debugfs files
  * @connector: pointer to a registered drm_connector
@@ -2427,9 +2494,16 @@ int intel_connector_debugfs_add(struct drm_connector 
*connector)
connector, &i915_hdcp_sink_capability_fops);
}
 
-   if ((DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv)) && 
((connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort && 
!to_intel_connector(connector)->mst_port) || connector->connector_type == 
DRM_MODE_CONNECTOR_eDP))
+   if ((DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv)) &&
+   ((connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort &&
+ !to_intel_connector(connector)->mst_port) ||
+connector->connector_type == DRM_MODE_CONNECTOR_eDP)) {
debugfs_create_file("i915_dsc_fec_support", S_IRUGO, root,
connector, &i915_dsc_fec_support_fops);
+   debugfs_create_file("i915_dsc_bpp_support", S_IRUGO,
+   root, connector,
+   &i915_dsc_bpp_support_fops);
+   }
 
/* Legacy panels doesn't lpsp on any platform */
if ((DISPLAY_VER(dev_priv) >= 9 || IS_HASWELL(dev_priv) ||
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index d94f361b548b7..19d8d3eefbc27 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1612,6 +1612,7 @@ struct intel_dp {
 
/* Display stream compression testing */
bool force_dsc_en;
+   int force_dsc_bpp;
 
bool ho

[Intel-gfx] [v3 2/2] drm/i915/display/dsc: Set BPP in the kernel

[venkata . sai . patnana]

From: Anusha Srivatsa 

Set compress BPP in kernel while connector DP or eDP

Cc: Vandita Kulkarni 
Cc: Navare Manasi D 
Signed-off-by: Anusha Srivatsa 
Signed-off-by: Patnana Venkata Sai 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 23 ++-
 1 file changed, 18 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 5b52beaddada0..4ce15da3e33ce 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -1241,9 +1241,15 @@ static int intel_dp_dsc_compute_config(struct intel_dp 
*intel_dp,
pipe_config->lane_count = limits->max_lane_count;
 
if (intel_dp_is_edp(intel_dp)) {
-   pipe_config->dsc.compressed_bpp =
-   min_t(u16, 
drm_edp_dsc_sink_output_bpp(intel_dp->dsc_dpcd) >> 4,
- pipe_config->pipe_bpp);
+   if (intel_dp->force_dsc_bpp) {
+   drm_dbg_kms(&dev_priv->drm,
+   "DSC BPP forced to %d", 
intel_dp->force_dsc_bpp);
+   pipe_config->dsc.compressed_bpp = 
intel_dp->force_dsc_bpp;
+   } else {
+   pipe_config->dsc.compressed_bpp =
+   min_t(u16, 
drm_edp_dsc_sink_output_bpp(intel_dp->dsc_dpcd) >> 4,
+   pipe_config->pipe_bpp);
+   }
pipe_config->dsc.slice_count =
drm_dp_dsc_sink_max_slice_count(intel_dp->dsc_dpcd,
true);
@@ -1269,9 +1275,15 @@ static int intel_dp_dsc_compute_config(struct intel_dp 
*intel_dp,
"Compressed BPP/Slice Count not 
supported\n");
return -EINVAL;
}
-   pipe_config->dsc.compressed_bpp = min_t(u16,
+   if (intel_dp->force_dsc_bpp) {
+   drm_dbg_kms(&dev_priv->drm,
+   "DSC BPP forced to %d\n", 
intel_dp->force_dsc_bpp);
+   pipe_config->dsc.compressed_bpp = 
intel_dp->force_dsc_bpp;
+   } else {
+   pipe_config->dsc.compressed_bpp = min_t(u16,
   
dsc_max_output_bpp >> 4,
   
pipe_config->pipe_bpp);
+   }
pipe_config->dsc.slice_count = dsc_dp_slice_count;
}
/*
@@ -1374,7 +1386,8 @@ intel_dp_compute_link_config(struct intel_encoder 
*encoder,
 * Pipe joiner needs compression upto display12 due to BW limitation. 
DG2
 * onwards pipe joiner can be enabled without compression.
 */
-   drm_dbg_kms(&i915->drm, "Force DSC en = %d\n", intel_dp->force_dsc_en);
+   drm_dbg_kms(&i915->drm, "Force DSC en = %d\n Force DSC BPP = %d\n",
+   intel_dp->force_dsc_en, intel_dp->force_dsc_bpp);
if (ret || intel_dp->force_dsc_en || (DISPLAY_VER(i915) < 13 &&
  pipe_config->bigjoiner)) {
ret = intel_dp_dsc_compute_config(intel_dp, pipe_config,
-- 
2.25.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [v3 1/2] drm/i915/display/dsc: Add Per connector debugfs node for DSC BPP enable

[venkata . sai . patnana]

From: Patnana Venkata Sai 

[What]:
This patch creates a per connector debugfs node to expose
the Input and Compressed BPP.

The same node can be used from userspace to force
DSC to a certain BPP(all accepted values).

[Why]:
Useful to verify all supported/requested compression bpp's
through IGT

Cc: Vandita Kulkarni 
Cc: Navare Manasi D 
Cc: Jani Nikula 
Signed-off-by: Anusha Srivatsa 
Signed-off-by: Patnana Venkata Sai 
---
 .../drm/i915/display/intel_display_debugfs.c  | 76 ++-
 .../drm/i915/display/intel_display_types.h|  1 +
 2 files changed, 76 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c 
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index af9e58619667d..2305a0c2498cc 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -2389,6 +2389,73 @@ static const struct file_operations 
i915_dsc_fec_support_fops = {
.write = i915_dsc_fec_support_write
 };
 
+static int i915_dsc_bpp_support_show(struct seq_file *m, void *data)
+{
+   struct drm_connector *connector = m->private;
+   struct drm_device *dev = connector->dev;
+   struct drm_crtc *crtc;
+   struct intel_crtc_state *crtc_state = NULL;
+   int ret = 0;
+
+   ret = 
drm_modeset_lock_single_interruptible(&dev->mode_config.connection_mutex);
+   if (ret)
+   return ret;
+
+   crtc = connector->state->crtc;
+   crtc_state = to_intel_crtc_state(crtc->state);
+   seq_printf(m, "Input_BPP: %d\n", crtc_state->pipe_bpp);
+   seq_printf(m, "Compressed_BPP: %d\n",
+   crtc_state->dsc.compressed_bpp);
+
+   drm_modeset_unlock(&dev->mode_config.connection_mutex);
+
+   return ret;
+}
+
+static ssize_t i915_dsc_bpp_support_write(struct file *file,
+   const char __user *ubuf,
+   size_t len, loff_t *offp)
+{
+   int dsc_bpp = 0;
+   int ret;
+   struct drm_connector *connector =
+   ((struct seq_file *)file->private_data)->private;
+   struct intel_encoder *encoder = 
intel_attached_encoder(to_intel_connector(connector));
+   struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+   struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+
+   if (len == 0)
+   return 0;
+
+   drm_dbg(&i915->drm,
+   "Copied %zu bytes from user to force BPP\n", len);
+
+   ret = kstrtoint_from_user(ubuf, len, 0, &dsc_bpp);
+
+   intel_dp->force_dsc_bpp = dsc_bpp;
+   if (ret < 0)
+   return ret;
+
+   *offp += len;
+   return len;
+}
+
+static int i915_dsc_bpp_support_open(struct inode *inode,
+  struct file *file)
+{
+   return single_open(file, i915_dsc_bpp_support_show,
+  inode->i_private);
+}
+
+static const struct file_operations i915_dsc_bpp_support_fops = {
+   .owner = THIS_MODULE,
+   .open = i915_dsc_bpp_support_open,
+   .read = seq_read,
+   .llseek = seq_lseek,
+   .release = single_release,
+   .write = i915_dsc_bpp_support_write
+};
+
 /**
  * intel_connector_debugfs_add - add i915 specific connector debugfs files
  * @connector: pointer to a registered drm_connector
@@ -2427,9 +2494,16 @@ int intel_connector_debugfs_add(struct drm_connector 
*connector)
connector, &i915_hdcp_sink_capability_fops);
}
 
-   if ((DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv)) && 
((connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort && 
!to_intel_connector(connector)->mst_port) || connector->connector_type == 
DRM_MODE_CONNECTOR_eDP))
+   if ((DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv)) &&
+   ((connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort &&
+ !to_intel_connector(connector)->mst_port) ||
+connector->connector_type == DRM_MODE_CONNECTOR_eDP)) {
debugfs_create_file("i915_dsc_fec_support", S_IRUGO, root,
connector, &i915_dsc_fec_support_fops);
+   debugfs_create_file("i915_dsc_bpp_support", S_IRUGO,
+   root, connector,
+   &i915_dsc_bpp_support_fops);
+   }
 
/* Legacy panels doesn't lpsp on any platform */
if ((DISPLAY_VER(dev_priv) >= 9 || IS_HASWELL(dev_priv) ||
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index d94f361b548b7..19d8d3eefbc27 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1612,6 +1612,7 @@ struct intel_dp {
 
/* Display stream compression testing */
bool force_dsc_en;
+   int force_dsc_bpp;
 
bool ho

Re: [Intel-gfx] [PATCH 1/4] Klock work Fix for NULL dereferencing in i915_gem_ttm.c

[Matthew Auld]

On Mon, 28 Jun 2021 at 15:49, Bommu Krishnaiah
 wrote:
>
> Signed-off-by: Bommu Krishnaiah 
> Cc: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> index c39d982c4fa66..97093a9bfccc2 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> @@ -590,6 +590,7 @@ static unsigned long i915_ttm_io_mem_pfn(struct 
> ttm_buffer_object *bo,
> GEM_WARN_ON(bo->ttm);
>
> sg = __i915_gem_object_get_sg(obj, &obj->ttm.get_io_page, 
> page_offset, &ofs, true, true);
> +   GEM_BUG_ON(!sg);

Is there some analysis for how this could happen? The commit message
should ideally have something like that. It looks like we already have
a GEM_BUG_ON(!sg) for the lookup case, and in the event of doing the
manual walk we already dereference the sg, so not seeing it.

>
> return ((base + sg_dma_address(sg)) >> PAGE_SHIFT) + ofs;
>  }
> --
> 2.25.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: IRQ fixes (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915: IRQ fixes (rev3)
URL   : https://patchwork.freedesktop.org/series/92053/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10296 -> Patchwork_20502


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_20502 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_20502, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20502/index.html

Possible new issues
---

  Here are the unknown changes that may have been introduced in Patchwork_20502:

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@workarounds:
- fi-ivb-3770:[PASS][1] -> [DMESG-FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10296/fi-ivb-3770/igt@i915_selftest@l...@workarounds.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20502/fi-ivb-3770/igt@i915_selftest@l...@workarounds.html

  
Known issues


  Here are the changes found in Patchwork_20502 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_cs_nop@sync-fork-compute0:
- fi-snb-2600:NOTRUN -> [SKIP][3] ([fdo#109271]) +17 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20502/fi-snb-2600/igt@amdgpu/amd_cs_...@sync-fork-compute0.html

  * igt@i915_selftest@live@workarounds:
- fi-hsw-4770:[PASS][4] -> [DMESG-FAIL][5] ([i915#2927])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10296/fi-hsw-4770/igt@i915_selftest@l...@workarounds.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20502/fi-hsw-4770/igt@i915_selftest@l...@workarounds.html

  * igt@runner@aborted:
- fi-hsw-4770:NOTRUN -> [FAIL][6] ([fdo#109271] / [i915#1436] / 
[i915#2505])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20502/fi-hsw-4770/igt@run...@aborted.html
- fi-ivb-3770:NOTRUN -> [FAIL][7] ([fdo#109271])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20502/fi-ivb-3770/igt@run...@aborted.html

  
 Possible fixes 

  * igt@i915_module_load@reload:
- fi-kbl-soraka:  [DMESG-WARN][8] ([i915#1982]) -> [PASS][9]
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10296/fi-kbl-soraka/igt@i915_module_l...@reload.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20502/fi-kbl-soraka/igt@i915_module_l...@reload.html

  * igt@i915_selftest@live@hangcheck:
- fi-snb-2600:[INCOMPLETE][10] ([i915#2782]) -> [PASS][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10296/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20502/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html

  * igt@kms_flip@basic-flip-vs-wf_vblank@a-dsi1:
- {fi-tgl-dsi}:   [DMESG-WARN][12] ([i915#1982]) -> [PASS][13]
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10296/fi-tgl-dsi/igt@kms_flip@basic-flip-vs-wf_vbl...@a-dsi1.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20502/fi-tgl-dsi/igt@kms_flip@basic-flip-vs-wf_vbl...@a-dsi1.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#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#2505]: https://gitlab.freedesktop.org/drm/intel/issues/2505
  [i915#2782]: https://gitlab.freedesktop.org/drm/intel/issues/2782
  [i915#2927]: https://gitlab.freedesktop.org/drm/intel/issues/2927
  [i915#3717]: https://gitlab.freedesktop.org/drm/intel/issues/3717


Participating hosts (37 -> 35)
--

  Missing(2): fi-bsw-cyan fi-bdw-samus 


Build changes
-

  * Linux: CI_DRM_10296 -> Patchwork_20502

  CI-20190529: 20190529
  CI_DRM_10296: 1ad092a7879a55938159b58a5b662370cab95ec8 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6125: 5bb62cb290fa32777934de4b39e107ccd282f7e8 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_20502: 21c6e6f45c89cd7f4f38e9a6ef4992b6a5204031 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

21c6e6f45c89 drm/i915: Drop all references to DRM IRQ midlayer
1b2c2d630094 drm/i915: Use the correct IRQ during resume

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20502/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/4] Klock work Fix for NULL dereferencing in i915_gem_ttm.c

[Matthew Auld]

On Thu, 1 Jul 2021 at 10:39, Matthew Auld
 wrote:
>
> On Mon, 28 Jun 2021 at 15:49, Bommu Krishnaiah
>  wrote:
> >
> > Signed-off-by: Bommu Krishnaiah 
> > Cc: Maarten Lankhorst 
> > ---
> >  drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c 
> > b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> > index c39d982c4fa66..97093a9bfccc2 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> > @@ -590,6 +590,7 @@ static unsigned long i915_ttm_io_mem_pfn(struct 
> > ttm_buffer_object *bo,
> > GEM_WARN_ON(bo->ttm);
> >
> > sg = __i915_gem_object_get_sg(obj, &obj->ttm.get_io_page, 
> > page_offset, &ofs, true, true);
> > +   GEM_BUG_ON(!sg);
>
> Is there some analysis for how this could happen? The commit message
> should ideally have something like that. It looks like we already have
> a GEM_BUG_ON(!sg) for the lookup case, and in the event of doing the
> manual walk we already dereference the sg, so not seeing it.

So simply adding GEM_BUG_ON(!sg) here I don't think does anything. But
maybe this tool is trying to point out a potential bug inside
__i915_gem_object_get_sg(), hence needs proper analysis.

>
> >
> > return ((base + sg_dma_address(sg)) >> PAGE_SHIFT) + ofs;
> >  }
> > --
> > 2.25.1
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: IRQ fixes (rev3)

[Thomas Zimmermann]

Am 01.07.21 um 11:43 schrieb Patchwork:

*Patch Details*
*Series:*   drm/i915: IRQ fixes (rev3)
*URL:*	https://patchwork.freedesktop.org/series/92053/ 


*State:*failure
*Details:* 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20502/index.html 




  CI Bug Log - changes from CI_DRM_10296 -> Patchwork_20502


Summary

*FAILURE*

Serious unknown changes coming with Patchwork_20502 absolutely need to be
verified manually.

If you think the reported changes have nothing to do with the changes
introduced in Patchwork_20502, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.

External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20502/index.html



Possible new issues

Here are the unknown changes that may have been introduced in 
Patchwork_20502:



  IGT changes


Possible regressions

  * igt@i915_selftest@live@workarounds:
  o fi-ivb-3770: PASS


-> DMESG-FAIL




This looks like it was introduced by v4. v3 didn't have this problem

https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20502/fi-ivb-3770/igt@i915_selftest@l...@workarounds.html#dmesg-warnings249




Known issues

Here are the changes found in Patchwork_20502 that come from known issues:


  IGT changes


Issues hit

  *

igt@amdgpu/amd_cs_nop@sync-fork-compute0:

  o fi-snb-2600: NOTRUN -> SKIP


(fdo#109271
) +17
similar issues
  *

igt@i915_selftest@live@workarounds:

  o fi-hsw-4770: PASS


-> DMESG-FAIL


(i915#2927 )
  *

igt@runner@aborted:

  o

fi-hsw-4770: NOTRUN -> FAIL


(fdo#109271
 /
i915#1436 
/ i915#2505 )

  o

fi-ivb-3770: NOTRUN -> FAIL


(fdo#109271 )


Possible fixes

  *

igt@i915_module_load@reload:

  o fi-kbl-soraka: DMESG-WARN


(i915#1982
) -> PASS


  *

igt@i915_selftest@live@hangcheck:

  o fi-snb-2600: INCOMPLETE


(i915#2782
) -> PASS


  *

igt@kms_flip@basic-flip-vs-wf_vblank@a-dsi1:

  o {fi-tgl-dsi}: DMESG-WARN


(i915#1982
) -> PASS



{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).


Participating hosts (37 -> 35)

Missing (2): fi-bsw-cyan fi-bdw-samus


Build changes

  * Linux: CI_DRM_10296 -> Patchwork_20502

CI-20190529: 20190529
CI_DRM_10296: 1ad092a7879a55938159b58a5b662370cab95ec8 @ 
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6125: 5bb62cb290fa32777934de4b39e107ccd282f7e8 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_20502: 21c6e6f45c89cd7f4f38e9a6ef4992b6a5204031 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

21c6e6f45c89 drm/i915: Drop all references to DRM IR

[Intel-gfx] [v4 0/2] drm/i915/display/dsc: Set BPP in the kernel

[venkata . sai . patnana]

From: Patnana Venkata Sai 

DSC can be supported per DP connector. This patch creates
a per connector debugfs node to expose the Input and
Compressed BPP.

The same node can be used from userspace to force
DSC to a certain BPP.

force_dsc_bpp is written through this debugfs
node to force DSC BPP to all accepted values

Test-with: <20210622102454.8922-1-venkata.sai.patn...@intel.com>

Anusha Srivatsa (1):
  drm/i915/display/dsc: Set BPP in the kernel

Patnana Venkata Sai (1):
  drm/i915/display/dsc: Add Per connector debugfs node for DSC BPP
enable

 .../drm/i915/display/intel_display_debugfs.c  | 74 ++-
 .../drm/i915/display/intel_display_types.h|  1 +
 drivers/gpu/drm/i915/display/intel_dp.c   | 23 --
 3 files changed, 92 insertions(+), 6 deletions(-)

-- 
2.25.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [v4 1/2] drm/i915/display/dsc: Add Per connector debugfs node for DSC BPP enable

[venkata . sai . patnana]

From: Patnana Venkata Sai 

[What]:
This patch creates a per connector debugfs node to expose
the Input and Compressed BPP.

The same node can be used from userspace to force
DSC to a certain BPP(all accepted values).

[Why]:
Useful to verify all supported/requested compression bpp's
through IGT

v2: Remove unnecessary logic & update commit message 
with in detail(Jani)
v3: Drop pipe bpp in debugfs node (Vandita)

Cc: Vandita Kulkarni 
Cc: Navare Manasi D 
Signed-off-by: Anusha Srivatsa 
Signed-off-by: Patnana Venkata Sai 
---
 .../drm/i915/display/intel_display_debugfs.c  | 74 ++-
 .../drm/i915/display/intel_display_types.h|  1 +
 2 files changed, 74 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c 
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index af9e58619667d..619667ad15fa0 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -2389,6 +2389,71 @@ static const struct file_operations 
i915_dsc_fec_support_fops = {
.write = i915_dsc_fec_support_write
 };
 
+static int i915_dsc_bpp_support_show(struct seq_file *m, void *data)
+{
+   struct drm_connector *connector = m->private;
+   struct drm_device *dev = connector->dev;
+   struct drm_crtc *crtc;
+   struct intel_crtc_state *crtc_state = NULL;
+   int ret = 0;
+
+   ret = 
drm_modeset_lock_single_interruptible(&dev->mode_config.connection_mutex);
+   if (ret)
+   return ret;
+
+   crtc = connector->state->crtc;
+   crtc_state = to_intel_crtc_state(crtc->state);
+   seq_printf(m, "Compressed_BPP: %d\n", crtc_state->dsc.compressed_bpp);
+
+   drm_modeset_unlock(&dev->mode_config.connection_mutex);
+
+   return ret;
+}
+
+static ssize_t i915_dsc_bpp_support_write(struct file *file,
+   const char __user *ubuf,
+   size_t len, loff_t *offp)
+{
+   int dsc_bpp = 0;
+   int ret;
+   struct drm_connector *connector =
+   ((struct seq_file *)file->private_data)->private;
+   struct intel_encoder *encoder = 
intel_attached_encoder(to_intel_connector(connector));
+   struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+   struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+
+   if (len == 0)
+   return 0;
+
+   drm_dbg(&i915->drm,
+   "Copied %zu bytes from user to force BPP\n", len);
+
+   ret = kstrtoint_from_user(ubuf, len, 0, &dsc_bpp);
+
+   intel_dp->force_dsc_bpp = dsc_bpp;
+   if (ret < 0)
+   return ret;
+
+   *offp += len;
+   return len;
+}
+
+static int i915_dsc_bpp_support_open(struct inode *inode,
+  struct file *file)
+{
+   return single_open(file, i915_dsc_bpp_support_show,
+  inode->i_private);
+}
+
+static const struct file_operations i915_dsc_bpp_support_fops = {
+   .owner = THIS_MODULE,
+   .open = i915_dsc_bpp_support_open,
+   .read = seq_read,
+   .llseek = seq_lseek,
+   .release = single_release,
+   .write = i915_dsc_bpp_support_write
+};
+
 /**
  * intel_connector_debugfs_add - add i915 specific connector debugfs files
  * @connector: pointer to a registered drm_connector
@@ -2427,9 +2492,16 @@ int intel_connector_debugfs_add(struct drm_connector 
*connector)
connector, &i915_hdcp_sink_capability_fops);
}
 
-   if ((DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv)) && 
((connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort && 
!to_intel_connector(connector)->mst_port) || connector->connector_type == 
DRM_MODE_CONNECTOR_eDP))
+   if ((DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv)) &&
+   ((connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort &&
+ !to_intel_connector(connector)->mst_port) ||
+connector->connector_type == DRM_MODE_CONNECTOR_eDP)) {
debugfs_create_file("i915_dsc_fec_support", S_IRUGO, root,
connector, &i915_dsc_fec_support_fops);
+   debugfs_create_file("i915_dsc_bpp_support", S_IRUGO,
+   root, connector,
+   &i915_dsc_bpp_support_fops);
+   }
 
/* Legacy panels doesn't lpsp on any platform */
if ((DISPLAY_VER(dev_priv) >= 9 || IS_HASWELL(dev_priv) ||
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index d94f361b548b7..19d8d3eefbc27 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1612,6 +1612,7 @@ struct intel_dp {
 
/* Display stream compression testing */
bool force_dsc_en;
+   int force_dsc_bpp

[Intel-gfx] [v4 2/2] drm/i915/display/dsc: Set BPP in the kernel

[venkata . sai . patnana]

From: Anusha Srivatsa 

Set compress BPP in kernel while connector DP or eDP

Cc: Vandita Kulkarni 
Cc: Navare Manasi D 
Signed-off-by: Anusha Srivatsa 
Signed-off-by: Patnana Venkata Sai 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 23 ++-
 1 file changed, 18 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 5b52beaddada0..4ce15da3e33ce 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -1241,9 +1241,15 @@ static int intel_dp_dsc_compute_config(struct intel_dp 
*intel_dp,
pipe_config->lane_count = limits->max_lane_count;
 
if (intel_dp_is_edp(intel_dp)) {
-   pipe_config->dsc.compressed_bpp =
-   min_t(u16, 
drm_edp_dsc_sink_output_bpp(intel_dp->dsc_dpcd) >> 4,
- pipe_config->pipe_bpp);
+   if (intel_dp->force_dsc_bpp) {
+   drm_dbg_kms(&dev_priv->drm,
+   "DSC BPP forced to %d", 
intel_dp->force_dsc_bpp);
+   pipe_config->dsc.compressed_bpp = 
intel_dp->force_dsc_bpp;
+   } else {
+   pipe_config->dsc.compressed_bpp =
+   min_t(u16, 
drm_edp_dsc_sink_output_bpp(intel_dp->dsc_dpcd) >> 4,
+   pipe_config->pipe_bpp);
+   }
pipe_config->dsc.slice_count =
drm_dp_dsc_sink_max_slice_count(intel_dp->dsc_dpcd,
true);
@@ -1269,9 +1275,15 @@ static int intel_dp_dsc_compute_config(struct intel_dp 
*intel_dp,
"Compressed BPP/Slice Count not 
supported\n");
return -EINVAL;
}
-   pipe_config->dsc.compressed_bpp = min_t(u16,
+   if (intel_dp->force_dsc_bpp) {
+   drm_dbg_kms(&dev_priv->drm,
+   "DSC BPP forced to %d\n", 
intel_dp->force_dsc_bpp);
+   pipe_config->dsc.compressed_bpp = 
intel_dp->force_dsc_bpp;
+   } else {
+   pipe_config->dsc.compressed_bpp = min_t(u16,
   
dsc_max_output_bpp >> 4,
   
pipe_config->pipe_bpp);
+   }
pipe_config->dsc.slice_count = dsc_dp_slice_count;
}
/*
@@ -1374,7 +1386,8 @@ intel_dp_compute_link_config(struct intel_encoder 
*encoder,
 * Pipe joiner needs compression upto display12 due to BW limitation. 
DG2
 * onwards pipe joiner can be enabled without compression.
 */
-   drm_dbg_kms(&i915->drm, "Force DSC en = %d\n", intel_dp->force_dsc_en);
+   drm_dbg_kms(&i915->drm, "Force DSC en = %d\n Force DSC BPP = %d\n",
+   intel_dp->force_dsc_en, intel_dp->force_dsc_bpp);
if (ret || intel_dp->force_dsc_en || (DISPLAY_VER(i915) < 13 &&
  pipe_config->bigjoiner)) {
ret = intel_dp_dsc_compute_config(intel_dp, pipe_config,
-- 
2.25.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display: check if compressed_llb was allocated

[Patchwork]

== Series Details ==

Series: drm/i915/display: check if compressed_llb was allocated
URL   : https://patchwork.freedesktop.org/series/92100/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10296 -> Patchwork_20503


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20503/index.html

Known issues


  Here are the changes found in Patchwork_20503 that come from known issues:

### IGT changes ###

 Possible fixes 

  * igt@kms_flip@basic-flip-vs-wf_vblank@a-dsi1:
- {fi-tgl-dsi}:   [DMESG-WARN][1] ([i915#1982]) -> [PASS][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10296/fi-tgl-dsi/igt@kms_flip@basic-flip-vs-wf_vbl...@a-dsi1.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20503/fi-tgl-dsi/igt@kms_flip@basic-flip-vs-wf_vbl...@a-dsi1.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#3303]: https://gitlab.freedesktop.org/drm/intel/issues/3303


Participating hosts (37 -> 33)
--

  Missing(4): fi-kbl-soraka fi-bsw-cyan fi-bdw-samus fi-bsw-n3050 


Build changes
-

  * Linux: CI_DRM_10296 -> Patchwork_20503

  CI-20190529: 20190529
  CI_DRM_10296: 1ad092a7879a55938159b58a5b662370cab95ec8 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6125: 5bb62cb290fa32777934de4b39e107ccd282f7e8 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_20503: fc420969e0c01726cf0f4bbf2ac12d596f7ceb10 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

fc420969e0c0 drm/i915/display: check if compressed_llb was allocated

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20503/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/display/dsc: Set BPP in the kernel (rev4)

[Patchwork]

== Series Details ==

Series: drm/i915/display/dsc: Set BPP in the kernel (rev4)
URL   : https://patchwork.freedesktop.org/series/91917/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
e4fb01832beb drm/i915/display/dsc: Add Per connector debugfs node for DSC BPP 
enable
-:48: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#48: FILE: drivers/gpu/drm/i915/display/intel_display_debugfs.c:2408:
+   seq_printf(m, "Compressed_BPP: %d\n",
+   crtc_state->dsc.compressed_bpp);

-:56: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#56: FILE: drivers/gpu/drm/i915/display/intel_display_debugfs.c:2416:
+static ssize_t i915_dsc_bpp_support_write(struct file *file,
+   const char __user *ubuf,

-:84: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#84: FILE: drivers/gpu/drm/i915/display/intel_display_debugfs.c:2444:
+static int i915_dsc_bpp_support_open(struct inode *inode,
+  struct file *file)

-:113: WARNING:SYMBOLIC_PERMS: Symbolic permissions 'S_IRUGO' are not 
preferred. Consider using octal permissions '0444'.
#113: FILE: drivers/gpu/drm/i915/display/intel_display_debugfs.c:2503:
+   debugfs_create_file("i915_dsc_bpp_support", S_IRUGO,

total: 0 errors, 1 warnings, 3 checks, 97 lines checked
f9001417c3a0 drm/i915/display/dsc: Set BPP in the kernel
-:26: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#26: FILE: drivers/gpu/drm/i915/display/intel_dp.c:1246:
+   drm_dbg_kms(&dev_priv->drm,
+   "DSC BPP forced to %d", 
intel_dp->force_dsc_bpp);

-:31: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#31: FILE: drivers/gpu/drm/i915/display/intel_dp.c:1251:
+   min_t(u16, 
drm_edp_dsc_sink_output_bpp(intel_dp->dsc_dpcd) >> 4,
+   pipe_config->pipe_bpp);

-:47: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#47: FILE: drivers/gpu/drm/i915/display/intel_dp.c:1284:
+   pipe_config->dsc.compressed_bpp = min_t(u16,
   
dsc_max_output_bpp >> 4,

total: 0 errors, 0 warnings, 3 checks, 43 lines checked


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/display/dsc: Set BPP in the kernel (rev4)

[Patchwork]

== Series Details ==

Series: drm/i915/display/dsc: Set BPP in the kernel (rev4)
URL   : https://patchwork.freedesktop.org/series/91917/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+drivers/gpu/drm/i915/display/intel_display.c:1896:21:expected struct 
i915_vma *[assigned] vma
+drivers/gpu/drm/i915/display/intel_display.c:1896:21:got void [noderef] 
__iomem *[assigned] iomem
+drivers/gpu/drm/i915/display/intel_display.c:1896:21: warning: incorrect type 
in assignment (different address spaces)
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_reset.c:1396:5: warning: context imbalance in 
'intel_gt_reset_trylock' - different lock contexts for basic block
+./include/asm-generic/bitops/find.h:112:45: warning: shift count is negative 
(-262080)
+./include/asm-generic/bitops/find.h:32:31: warning: shift count is negative 
(-262080)
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read16' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read32' 
- different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read64' 
- different lock contexts for basic block
+./include/linux/spinlock.h:

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/display: check if compressed_llb was allocated

[Patchwork]

== Series Details ==

Series: drm/i915/display: check if compressed_llb was allocated
URL   : https://patchwork.freedesktop.org/series/92100/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10296_full -> Patchwork_20503_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_20503_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_20503_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  

Possible new issues
---

  Here are the unknown changes that may have been introduced in 
Patchwork_20503_full:

### IGT changes ###

 Possible regressions 

  * igt@i915_pm_rps@basic-api:
- shard-tglb: [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10296/shard-tglb5/igt@i915_pm_...@basic-api.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20503/shard-tglb1/igt@i915_pm_...@basic-api.html

  
Known issues


  Here are the changes found in Patchwork_20503_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_persistence@legacy-engines-mixed:
- shard-snb:  NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#1099]) +1 
similar issue
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20503/shard-snb7/igt@gem_ctx_persiste...@legacy-engines-mixed.html

  * igt@gem_ctx_persistence@many-contexts:
- shard-tglb: [PASS][4] -> [FAIL][5] ([i915#2410])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10296/shard-tglb2/igt@gem_ctx_persiste...@many-contexts.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20503/shard-tglb5/igt@gem_ctx_persiste...@many-contexts.html

  * igt@gem_eio@in-flight-contexts-immediate:
- shard-tglb: [PASS][6] -> [TIMEOUT][7] ([i915#3063])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10296/shard-tglb6/igt@gem_...@in-flight-contexts-immediate.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20503/shard-tglb3/igt@gem_...@in-flight-contexts-immediate.html

  * igt@gem_exec_fair@basic-none-solo@rcs0:
- shard-kbl:  [PASS][8] -> [FAIL][9] ([i915#2842]) +1 similar issue
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10296/shard-kbl2/igt@gem_exec_fair@basic-none-s...@rcs0.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20503/shard-kbl6/igt@gem_exec_fair@basic-none-s...@rcs0.html

  * igt@gem_exec_fair@basic-pace@vcs1:
- shard-tglb: [PASS][10] -> [FAIL][11] ([i915#2842]) +1 similar 
issue
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10296/shard-tglb5/igt@gem_exec_fair@basic-p...@vcs1.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20503/shard-tglb2/igt@gem_exec_fair@basic-p...@vcs1.html

  * igt@gem_mmap_gtt@cpuset-medium-copy:
- shard-iclb: [PASS][12] -> [FAIL][13] ([i915#2428])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10296/shard-iclb7/igt@gem_mmap_...@cpuset-medium-copy.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20503/shard-iclb3/igt@gem_mmap_...@cpuset-medium-copy.html

  * igt@gem_pread@exhaustion:
- shard-skl:  NOTRUN -> [WARN][14] ([i915#2658])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20503/shard-skl3/igt@gem_pr...@exhaustion.html

  * igt@gem_vm_create@destroy-race:
- shard-tglb: [PASS][15] -> [FAIL][16] ([i915#2822])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10296/shard-tglb7/igt@gem_vm_cre...@destroy-race.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20503/shard-tglb6/igt@gem_vm_cre...@destroy-race.html

  * igt@gem_workarounds@suspend-resume-context:
- shard-apl:  [PASS][17] -> [DMESG-WARN][18] ([i915#180]) +4 
similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10296/shard-apl6/igt@gem_workarou...@suspend-resume-context.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20503/shard-apl2/igt@gem_workarou...@suspend-resume-context.html

  * igt@kms_ccs@pipe-d-crc-primary-rotation-180-yf_tiled_ccs:
- shard-apl:  NOTRUN -> [SKIP][19] ([fdo#109271]) +136 similar 
issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20503/shard-apl7/igt@kms_ccs@pipe-d-crc-primary-rotation-180-yf_tiled_ccs.html

  * igt@kms_chamelium@hdmi-hpd-with-enabled-mode:
- shard-kbl:  NOTRUN -> [SKIP][20] ([fdo#109271] / [fdo#111827])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20503/shard-kbl3/igt@kms_chamel...@hdmi-hpd-with-enabled-mode.html

  * igt@kms_chamelium@vga-edid-read:
- shard-apl:  NOTRUN -> [SKIP][21] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20503

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/display/dsc: Set BPP in the kernel (rev4)

[Patchwork]

== Series Details ==

Series: drm/i915/display/dsc: Set BPP in the kernel (rev4)
URL   : https://patchwork.freedesktop.org/series/91917/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10297 -> Patchwork_20504


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_20504 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_20504, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20504/index.html

Possible new issues
---

  Here are the unknown changes that may have been introduced in Patchwork_20504:

### IGT changes ###

 Possible regressions 

  * igt@debugfs_test@read_all_entries:
- fi-icl-y:   [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10297/fi-icl-y/igt@debugfs_test@read_all_entries.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20504/fi-icl-y/igt@debugfs_test@read_all_entries.html

  
 Warnings 

  * igt@debugfs_test@read_all_entries:
- fi-icl-u2:  [{ABORT}][3] ([i915#1814]) -> [INCOMPLETE][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10297/fi-icl-u2/igt@debugfs_test@read_all_entries.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20504/fi-icl-u2/igt@debugfs_test@read_all_entries.html

  
 Suppressed 

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@debugfs_test@read_all_entries:
- {fi-ehl-2}: [PASS][5] -> [INCOMPLETE][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10297/fi-ehl-2/igt@debugfs_test@read_all_entries.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20504/fi-ehl-2/igt@debugfs_test@read_all_entries.html
- {fi-tgl-dsi}:   [PASS][7] -> [INCOMPLETE][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10297/fi-tgl-dsi/igt@debugfs_test@read_all_entries.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20504/fi-tgl-dsi/igt@debugfs_test@read_all_entries.html
- {fi-tgl-1115g4}:[PASS][9] -> [INCOMPLETE][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10297/fi-tgl-1115g4/igt@debugfs_test@read_all_entries.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20504/fi-tgl-1115g4/igt@debugfs_test@read_all_entries.html
- {fi-jsl-1}: [PASS][11] -> [INCOMPLETE][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10297/fi-jsl-1/igt@debugfs_test@read_all_entries.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20504/fi-jsl-1/igt@debugfs_test@read_all_entries.html

  * igt@runner@aborted:
- {fi-ehl-2}: NOTRUN -> [FAIL][13]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20504/fi-ehl-2/igt@run...@aborted.html

  
Known issues


  Here are the changes found in Patchwork_20504 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@kms_chamelium@dp-crc-fast:
- fi-kbl-7500u:   [PASS][14] -> [FAIL][15] ([i915#1372])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10297/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20504/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html

  * igt@runner@aborted:
- fi-icl-y:   NOTRUN -> [FAIL][16] ([i915#1814])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20504/fi-icl-y/igt@run...@aborted.html

  
 Warnings 

  * igt@runner@aborted:
- fi-icl-u2:  [FAIL][17] ([i915#1814] / [i915#3363]) -> [FAIL][18] 
([i915#1814] / [i915#2722] / [i915#3363])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10297/fi-icl-u2/igt@run...@aborted.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20504/fi-icl-u2/igt@run...@aborted.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [i915#1372]: https://gitlab.freedesktop.org/drm/intel/issues/1372
  [i915#1814]: https://gitlab.freedesktop.org/drm/intel/issues/1814
  [i915#2722]: https://gitlab.freedesktop.org/drm/intel/issues/2722
  [i915#3363]: https://gitlab.freedesktop.org/drm/intel/issues/3363
  [i915#3717]: https://gitlab.freedesktop.org/drm/intel/issues/3717


Participating hosts (37 -> 35)
--

  Missing(2): fi-bsw-cyan fi-bdw-samus 


Build changes
-

  * IGT: IGT_6125 -> IGTPW_5971
  * Linux: CI_DRM_10297 -> Patchwork_20504

  CI-20190529: 20190529
  CI_DRM_10297: 96c7ad60de68518bdcd0d0e6381a2359034a0226 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGTPW_5971: https://intel-gfx-ci.01.org/tree/drm-ti

Re: [Intel-gfx] [PATCH v4 03/17] drm/uAPI: Add "active bpc" as feedback channel for "max bpc" drm property

[Werner Sembach]

Am 01.07.21 um 09:42 schrieb Pekka Paalanen:
> On Wed, 30 Jun 2021 11:42:10 +0200
> Werner Sembach  wrote:
>
>> Am 30.06.21 um 10:21 schrieb Pekka Paalanen:
>>> On Tue, 29 Jun 2021 13:02:05 +0200
>>> Werner Sembach  wrote:
>>>  
 Am 28.06.21 um 19:03 schrieb Werner Sembach:  
> Am 18.06.21 um 11:11 schrieb Werner Sembach:  
>> Add a new general drm property "active bpc" which can be used by graphic
>> drivers to report the applied bit depth per pixel back to userspace.
>>
>> While "max bpc" can be used to change the color depth, there was no way 
>> to
>> check which one actually got used. While in theory the driver chooses the
>> best/highest color depth within the max bpc setting a user might not be
>> fully aware what his hardware is or isn't capable off. This is meant as a
>> quick way to double check the setup.
>>
>> In the future, automatic color calibration for screens might also depend 
>> on
>> this information being available.
>>
>> Signed-off-by: Werner Sembach 
>> ---
>>   drivers/gpu/drm/drm_connector.c | 51 +
>>   include/drm/drm_connector.h |  8 ++
>>   2 files changed, 59 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_connector.c 
>> b/drivers/gpu/drm/drm_connector.c
>> index da39e7ff6965..943f6b61053b 100644
>> --- a/drivers/gpu/drm/drm_connector.c
>> +++ b/drivers/gpu/drm/drm_connector.c
>> @@ -1197,6 +1197,14 @@ static const struct drm_prop_enum_list 
>> dp_colorspaces[] = {
>>* drm_connector_attach_max_bpc_property() to create and attach the
>>* property to the connector during initialization.
>>*
>> + * active bpc:
>> + *  This read-only range property tells userspace the pixel color 
>> bit depth
>> + *  actually used by the hardware display engine on "the cable" on a
>> + *  connector. The chosen value depends on hardware capabilities, 
>> both
>> + *  display engine and connected monitor, and the "max bpc" 
>> property.
>> + *  Drivers shall use drm_connector_attach_active_bpc_property() to 
>> install
>> + *  this property.
>> + *  
> Regarding "on the cable" and dithering: As far as I can tell, what the 
> dithering option does, is setting a hardware
> register here:
>
> - 
> https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/i915/display/intel_display.c#L4534
>
> - 
> https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/i915/display/intel_display.c#L4571
>
> So dithering seems to be calculated by fixed purpose hardware/firmware 
> outside of the driver?
>
> The Intel driver does not seem to set a target bpc/bpp for this hardware 
> so I guess it defaults to 6 or 8 bpc?  
 Never mind it does. This switch-case does affect the dithering output:
 https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/i915/display/intel_display.c#L4537
   
>>> Hi,
>>>
>>> I obviously do not know the intel driver or hardware at all, but
>>> to me that just looks like translating from bits per pixel to bits per
>>> channel in RGB mapping?  
>> No, if i understand the documentation correctly: Writing bit depth here 
>> with dithering enabled sets the dithering target bpc.
>>>  
 As found in this documentation p.548:
 https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-lkf-vol02c-commandreference-registers-part2.pdf

 So max bpc and active bpc are affecting/affected by the bpc after 
 dithering.  
>>> By definition, if the cable carries N bpc, then dithering does not
>>> change that. The cable still carries N bpc, but due to spatial or
>>> temporal dithering, the *observed* color resolution may or may not be
>>> higher than the cable bpc.  
>> Yes, and max bpc and active bpc tell the cable bpc ist not the 
>> *observed* bpc.
>>> Of course, if the cable bpc is 8, and dithering targets 6 bpc, then 2
>>> LSB on the cable are always zero, right?  
>> I would assume that in this case only 6 bpc are actually send? Isn't the 
>> whole thing of dithering that you can't send, for example, 8 bpc?
>>> Maybe one would want to do that if the monitor has a 6 bit panel and it
>>> simply ignored the 2 LSB, and the cable cannot go down to 6 bpc.  
>> Is there dithering actually doing this? aka is my assumption above wrong?
>>
>> AMD code that confused me before, is hinting that you might be right: 
>> https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/amd/display/dc/dce/dce_transform.c#L826
>>
>> there is a set_clamp depth and a separate DCP_SPATIAL_DITHER_DEPTH_30BPP
>>
>>> So, what does "max bpc" mean right now?
>>>
>>> It seems like dither on/off is insufficient information, one would also
>>> need to control the dithering target bpc. I suppose the driver has a
>>> policy on how it chooses the target bpc, but wha

[Intel-gfx] [PATCH] drm/i915: Add TTM offset argument to mmap.

[Maarten Lankhorst]

This is only used for ttm, and tells userspace that the mapping type is
ignored. This disables the other type of mmap offsets when discrete
memory is used, so fix the selftests as well.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/gem/i915_gem_mman.c  | 17 +++-
 .../gpu/drm/i915/gem/i915_gem_object_types.h  |  1 +
 .../drm/i915/gem/selftests/i915_gem_mman.c| 27 +--
 include/uapi/drm/i915_drm.h   |  9 ---
 4 files changed, 47 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c 
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index a90f796e85c0..b34be9e5d094 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -679,10 +679,16 @@ __assign_mmap_offset(struct drm_i915_gem_object *obj,
return -ENODEV;
 
if (obj->ops->mmap_offset)  {
+   if (mmap_type != I915_MMAP_TYPE_TTM)
+   return -ENODEV;
+
*offset = obj->ops->mmap_offset(obj);
return 0;
}
 
+   if (mmap_type == I915_MMAP_TYPE_TTM)
+   return -ENODEV;
+
if (mmap_type != I915_MMAP_TYPE_GTT &&
!i915_gem_object_has_struct_page(obj) &&
!i915_gem_object_has_iomem(obj))
@@ -727,7 +733,9 @@ i915_gem_dumb_mmap_offset(struct drm_file *file,
 {
enum i915_mmap_type mmap_type;
 
-   if (boot_cpu_has(X86_FEATURE_PAT))
+   if (HAS_LMEM(to_i915(dev)))
+   mmap_type = I915_MMAP_TYPE_TTM;
+   else if (boot_cpu_has(X86_FEATURE_PAT))
mmap_type = I915_MMAP_TYPE_WC;
else if (!i915_ggtt_has_aperture(&to_i915(dev)->ggtt))
return -ENODEV;
@@ -798,6 +806,10 @@ i915_gem_mmap_offset_ioctl(struct drm_device *dev, void 
*data,
type = I915_MMAP_TYPE_UC;
break;
 
+   case I915_MMAP_OFFSET_TTM:
+   type = I915_MMAP_TYPE_TTM;
+   break;
+
default:
return -EINVAL;
}
@@ -968,6 +980,9 @@ int i915_gem_mmap(struct file *filp, struct vm_area_struct 
*vma)
vma->vm_ops = &vm_ops_cpu;
break;
 
+   case I915_MMAP_TYPE_TTM:
+   GEM_WARN_ON(mmo->mmap_type == I915_MMAP_TYPE_TTM);
+   /* fall-through */
case I915_MMAP_TYPE_WB:
vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
vma->vm_ops = &vm_ops_cpu;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h 
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index 441f913c87e6..8b872b22a7ec 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -96,6 +96,7 @@ enum i915_mmap_type {
I915_MMAP_TYPE_WC,
I915_MMAP_TYPE_WB,
I915_MMAP_TYPE_UC,
+   I915_MMAP_TYPE_TTM,
 };
 
 struct i915_mmap_offset {
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c 
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
index 607b7d2d4c29..321271bd2fa1 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
@@ -573,6 +573,14 @@ static int make_obj_busy(struct drm_i915_gem_object *obj)
return 0;
 }
 
+static enum i915_mmap_type default_mapping(struct drm_i915_private *i915)
+{
+   if (HAS_LMEM(i915))
+   return I915_MMAP_TYPE_TTM;
+
+   return I915_MMAP_TYPE_GTT;
+}
+
 static bool assert_mmap_offset(struct drm_i915_private *i915,
   unsigned long size,
   int expected)
@@ -585,7 +593,7 @@ static bool assert_mmap_offset(struct drm_i915_private 
*i915,
if (IS_ERR(obj))
return expected && expected == PTR_ERR(obj);
 
-   ret = __assign_mmap_offset(obj, I915_MMAP_TYPE_GTT, &offset, NULL);
+   ret = __assign_mmap_offset(obj, default_mapping(i915), &offset, NULL);
i915_gem_object_put(obj);
 
return ret == expected;
@@ -689,7 +697,7 @@ static int igt_mmap_offset_exhaustion(void *arg)
goto out;
}
 
-   err = __assign_mmap_offset(obj, I915_MMAP_TYPE_GTT, &offset, NULL);
+   err = __assign_mmap_offset(obj, default_mapping(i915), &offset, NULL);
if (err) {
pr_err("Unable to insert object into reclaimed hole\n");
goto err_obj;
@@ -831,8 +839,14 @@ static int wc_check(struct drm_i915_gem_object *obj)
 
 static bool can_mmap(struct drm_i915_gem_object *obj, enum i915_mmap_type type)
 {
+   struct drm_i915_private *i915 = to_i915(obj->base.dev);
bool no_map;
 
+   if (HAS_LMEM(i915))
+   return type == I915_MMAP_TYPE_TTM;
+   else if (type == I915_MMAP_TYPE_TTM)
+   return false;
+
if (type == I915_MMAP_TYPE_GTT &&
!i915_ggtt_has_aperture(&to_i915(obj->base.dev)->ggtt))
return false;
@@ -970,6 +9

Re: [Intel-gfx] [PATCH] drm/i915: Add TTM offset argument to mmap.

[Maarten Lankhorst]

Op 01-07-2021 om 13:42 schreef Maarten Lankhorst:
> This is only used for ttm, and tells userspace that the mapping type is
> ignored. This disables the other type of mmap offsets when discrete
> memory is used, so fix the selftests as well.
>
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/i915/gem/i915_gem_mman.c  | 17 +++-
>  .../gpu/drm/i915/gem/i915_gem_object_types.h  |  1 +
>  .../drm/i915/gem/selftests/i915_gem_mman.c| 27 +--
>  include/uapi/drm/i915_drm.h   |  9 ---
>  4 files changed, 47 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> index a90f796e85c0..b34be9e5d094 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> @@ -679,10 +679,16 @@ __assign_mmap_offset(struct drm_i915_gem_object *obj,
>   return -ENODEV;
>  
>   if (obj->ops->mmap_offset)  {
> + if (mmap_type != I915_MMAP_TYPE_TTM)
> + return -ENODEV;
> +
>   *offset = obj->ops->mmap_offset(obj);
>   return 0;
>   }
>  
> + if (mmap_type == I915_MMAP_TYPE_TTM)
> + return -ENODEV;
> +
>   if (mmap_type != I915_MMAP_TYPE_GTT &&
>   !i915_gem_object_has_struct_page(obj) &&
>   !i915_gem_object_has_iomem(obj))
> @@ -727,7 +733,9 @@ i915_gem_dumb_mmap_offset(struct drm_file *file,
>  {
>   enum i915_mmap_type mmap_type;
>  
> - if (boot_cpu_has(X86_FEATURE_PAT))
> + if (HAS_LMEM(to_i915(dev)))
> + mmap_type = I915_MMAP_TYPE_TTM;
> + else if (boot_cpu_has(X86_FEATURE_PAT))
>   mmap_type = I915_MMAP_TYPE_WC;
>   else if (!i915_ggtt_has_aperture(&to_i915(dev)->ggtt))
>   return -ENODEV;
> @@ -798,6 +806,10 @@ i915_gem_mmap_offset_ioctl(struct drm_device *dev, void 
> *data,
>   type = I915_MMAP_TYPE_UC;
>   break;
>  
> + case I915_MMAP_OFFSET_TTM:
> + type = I915_MMAP_TYPE_TTM;
> + break;
> +
>   default:
>   return -EINVAL;
>   }
> @@ -968,6 +980,9 @@ int i915_gem_mmap(struct file *filp, struct 
> vm_area_struct *vma)
>   vma->vm_ops = &vm_ops_cpu;
>   break;
>  
> + case I915_MMAP_TYPE_TTM:
> + GEM_WARN_ON(mmo->mmap_type == I915_MMAP_TYPE_TTM);
> + /* fall-through */
>   case I915_MMAP_TYPE_WB:
>   vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
>   vma->vm_ops = &vm_ops_cpu;
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h 
> b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> index 441f913c87e6..8b872b22a7ec 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> @@ -96,6 +96,7 @@ enum i915_mmap_type {
>   I915_MMAP_TYPE_WC,
>   I915_MMAP_TYPE_WB,
>   I915_MMAP_TYPE_UC,
> + I915_MMAP_TYPE_TTM,
>  };
>  
>  struct i915_mmap_offset {
> diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c 
> b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
> index 607b7d2d4c29..321271bd2fa1 100644
> --- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
> +++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
> @@ -573,6 +573,14 @@ static int make_obj_busy(struct drm_i915_gem_object *obj)
>   return 0;
>  }
>  
> +static enum i915_mmap_type default_mapping(struct drm_i915_private *i915)
> +{
> + if (HAS_LMEM(i915))
> + return I915_MMAP_TYPE_TTM;
> +
> + return I915_MMAP_TYPE_GTT;
> +}
> +
>  static bool assert_mmap_offset(struct drm_i915_private *i915,
>  unsigned long size,
>  int expected)
> @@ -585,7 +593,7 @@ static bool assert_mmap_offset(struct drm_i915_private 
> *i915,
>   if (IS_ERR(obj))
>   return expected && expected == PTR_ERR(obj);
>  
> - ret = __assign_mmap_offset(obj, I915_MMAP_TYPE_GTT, &offset, NULL);
> + ret = __assign_mmap_offset(obj, default_mapping(i915), &offset, NULL);
>   i915_gem_object_put(obj);
>  
>   return ret == expected;
> @@ -689,7 +697,7 @@ static int igt_mmap_offset_exhaustion(void *arg)
>   goto out;
>   }
>  
> - err = __assign_mmap_offset(obj, I915_MMAP_TYPE_GTT, &offset, NULL);
> + err = __assign_mmap_offset(obj, default_mapping(i915), &offset, NULL);
>   if (err) {
>   pr_err("Unable to insert object into reclaimed hole\n");
>   goto err_obj;
> @@ -831,8 +839,14 @@ static int wc_check(struct drm_i915_gem_object *obj)
>  
>  static bool can_mmap(struct drm_i915_gem_object *obj, enum i915_mmap_type 
> type)
>  {
> + struct drm_i915_private *i915 = to_i915(obj->base.dev);
>   bool no_map;
>  
> + if (HAS_LMEM(i915))
> + return type == I915_MMAP_TYPE_TTM;
> + else if (type == I915_MMAP_TYPE_TTM)
>

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Add TTM offset argument to mmap.

[Patchwork]

== Series Details ==

Series: drm/i915: Add TTM offset argument to mmap.
URL   : https://patchwork.freedesktop.org/series/92103/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
182e2988c2da drm/i915: Add TTM offset argument to mmap.
-:61: WARNING:PREFER_FALLTHROUGH: Prefer 'fallthrough;' over fallthrough comment
#61: FILE: drivers/gpu/drm/i915/gem/i915_gem_mman.c:985:
+   /* fall-through */

total: 0 errors, 1 warnings, 0 checks, 150 lines checked


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Add TTM offset argument to mmap.

[Patchwork]

== Series Details ==

Series: drm/i915: Add TTM offset argument to mmap.
URL   : https://patchwork.freedesktop.org/series/92103/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10297 -> Patchwork_20505


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20505/index.html

Known issues


  Here are the changes found in Patchwork_20505 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_cs_nop@sync-fork-compute0:
- fi-snb-2600:NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20505/fi-snb-2600/igt@amdgpu/amd_cs_...@sync-fork-compute0.html

  
 Possible fixes 

  * igt@i915_selftest@live@hangcheck:
- fi-snb-2600:[INCOMPLETE][2] ([i915#2782]) -> [PASS][3]
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10297/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20505/fi-snb-2600/igt@i915_selftest@l...@hangcheck.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#2782]: https://gitlab.freedesktop.org/drm/intel/issues/2782
  [i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
  [i915#3717]: https://gitlab.freedesktop.org/drm/intel/issues/3717


Participating hosts (37 -> 34)
--

  Missing(3): fi-kbl-soraka fi-bsw-cyan fi-bdw-samus 


Build changes
-

  * Linux: CI_DRM_10297 -> Patchwork_20505

  CI-20190529: 20190529
  CI_DRM_10297: 96c7ad60de68518bdcd0d0e6381a2359034a0226 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6125: 5bb62cb290fa32777934de4b39e107ccd282f7e8 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_20505: 182e2988c2da3bcc301241b71dd643b3ce0e6b27 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

182e2988c2da drm/i915: Add TTM offset argument to mmap.

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20505/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v15 06/12] swiotlb: Use is_swiotlb_force_bounce for swiotlb data bouncing

[Nathan Chancellor]

Hi Will and Claire,

On Wed, Jun 30, 2021 at 12:43:48PM +0100, Will Deacon wrote:
> On Wed, Jun 30, 2021 at 05:17:27PM +0800, Claire Chang wrote:
> > On Wed, Jun 30, 2021 at 9:43 AM Nathan Chancellor  wrote:
> > >
> > > On Thu, Jun 24, 2021 at 11:55:20PM +0800, Claire Chang wrote:
> > > > Propagate the swiotlb_force into io_tlb_default_mem->force_bounce and
> > > > use it to determine whether to bounce the data or not. This will be
> > > > useful later to allow for different pools.
> > > >
> > > > Signed-off-by: Claire Chang 
> > > > Reviewed-by: Christoph Hellwig 
> > > > Tested-by: Stefano Stabellini 
> > > > Tested-by: Will Deacon 
> > > > Acked-by: Stefano Stabellini 
> > >
> > > This patch as commit af452ec1b1a3 ("swiotlb: Use is_swiotlb_force_bounce
> > > for swiotlb data bouncing") causes my Ryzen 3 4300G system to fail to
> > > get to an X session consistently (although not every single time),
> > > presumably due to a crash in the AMDGPU driver that I see in dmesg.
> > >
> > > I have attached logs at af452ec1b1a3 and f127c9556a8e and I am happy
> > > to provide any further information, debug, or test patches as necessary.
> > 
> > Are you using swiotlb=force? or the swiotlb_map is called because of
> > !dma_capable? 
> > (https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/kernel/dma/direct.h#n93)
> 
> The command line is in the dmesg:
> 
>   | Kernel command line: initrd=\amd-ucode.img 
> initrd=\initramfs-linux-next-llvm.img 
> root=PARTUUID=8680aa0c-cf09-4a69-8cf3-970478040ee7 rw intel_pstate=no_hwp 
> irqpoll
> 
> but I worry that this looks _very_ similar to the issue reported by Qian
> Cai which we thought we had fixed. Nathan -- is the failure deterministic?

Yes, for the most part. It does not happen every single boot so when I
was bisecting, I did a series of seven boots and only considered the
revision good when all seven of them made it to LightDM's greeter. My
results that I notated show most bad revisions failed anywhere from four
to six times.

> > `BUG: unable to handle page fault for address: 003a8290` and
> > the fact it crashed at `_raw_spin_lock_irqsave` look like the memory
> > (maybe dev->dma_io_tlb_mem) was corrupted?
> > The dev->dma_io_tlb_mem should be set here
> > (https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/pci/probe.c#n2528)
> > through device_initialize.
> 
> I'm less sure about this. 'dma_io_tlb_mem' should be pointing at
> 'io_tlb_default_mem', which is a page-aligned allocation from memblock.
> The spinlock is at offset 0x24 in that structure, and looking at the
> register dump from the crash:
> 
> Jun 29 18:28:42 hp-4300G kernel: RSP: 0018:adb4013db9e8 EFLAGS: 00010006
> Jun 29 18:28:42 hp-4300G kernel: RAX: 003a8290 RBX:  
> RCX: 8900572ad580
> Jun 29 18:28:42 hp-4300G kernel: RDX: 89005653f024 RSI: 000c 
> RDI: 1d17
> Jun 29 18:28:42 hp-4300G kernel: RBP: 0a20d000 R08: 000c 
> R09: 
> Jun 29 18:28:42 hp-4300G kernel: R10: 0a20d000 R11: 89005653f000 
> R12: 0212
> Jun 29 18:28:42 hp-4300G kernel: R13: 1000 R14: 0002 
> R15: 0020
> Jun 29 18:28:42 hp-4300G kernel: FS:  7f1f8898ea40() 
> GS:89005728() knlGS:
> Jun 29 18:28:42 hp-4300G kernel: CS:  0010 DS:  ES:  CR0: 
> 80050033
> Jun 29 18:28:42 hp-4300G kernel: CR2: 003a8290 CR3: 0001020d 
> CR4: 00350ee0
> Jun 29 18:28:42 hp-4300G kernel: Call Trace:
> Jun 29 18:28:42 hp-4300G kernel:  _raw_spin_lock_irqsave+0x39/0x50
> Jun 29 18:28:42 hp-4300G kernel:  swiotlb_tbl_map_single+0x12b/0x4c0
> 
> Then that correlates with R11 holding the 'dma_io_tlb_mem' pointer and
> RDX pointing at the spinlock. Yet RAX is holding junk :/
> 
> I agree that enabling KASAN would be a good idea, but I also think we
> probably need to get some more information out of swiotlb_tbl_map_single()
> to see see what exactly is going wrong in there.

I can certainly enable KASAN and if there is any debug print I can add
or dump anything, let me know!

Cheers,
Nathan
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v15 06/12] swiotlb: Use is_swiotlb_force_bounce for swiotlb data bouncing

[Will Deacon]

On Wed, Jun 30, 2021 at 08:56:51AM -0700, Nathan Chancellor wrote:
> On Wed, Jun 30, 2021 at 12:43:48PM +0100, Will Deacon wrote:
> > On Wed, Jun 30, 2021 at 05:17:27PM +0800, Claire Chang wrote:
> > > `BUG: unable to handle page fault for address: 003a8290` and
> > > the fact it crashed at `_raw_spin_lock_irqsave` look like the memory
> > > (maybe dev->dma_io_tlb_mem) was corrupted?
> > > The dev->dma_io_tlb_mem should be set here
> > > (https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/pci/probe.c#n2528)
> > > through device_initialize.
> > 
> > I'm less sure about this. 'dma_io_tlb_mem' should be pointing at
> > 'io_tlb_default_mem', which is a page-aligned allocation from memblock.
> > The spinlock is at offset 0x24 in that structure, and looking at the
> > register dump from the crash:
> > 
> > Jun 29 18:28:42 hp-4300G kernel: RSP: 0018:adb4013db9e8 EFLAGS: 00010006
> > Jun 29 18:28:42 hp-4300G kernel: RAX: 003a8290 RBX: 
> >  RCX: 8900572ad580
> > Jun 29 18:28:42 hp-4300G kernel: RDX: 89005653f024 RSI: 
> > 000c RDI: 1d17
> > Jun 29 18:28:42 hp-4300G kernel: RBP: 0a20d000 R08: 
> > 000c R09: 
> > Jun 29 18:28:42 hp-4300G kernel: R10: 0a20d000 R11: 
> > 89005653f000 R12: 0212
> > Jun 29 18:28:42 hp-4300G kernel: R13: 1000 R14: 
> > 0002 R15: 0020
> > Jun 29 18:28:42 hp-4300G kernel: FS:  7f1f8898ea40() 
> > GS:89005728() knlGS:
> > Jun 29 18:28:42 hp-4300G kernel: CS:  0010 DS:  ES:  CR0: 
> > 80050033
> > Jun 29 18:28:42 hp-4300G kernel: CR2: 003a8290 CR3: 
> > 0001020d CR4: 00350ee0
> > Jun 29 18:28:42 hp-4300G kernel: Call Trace:
> > Jun 29 18:28:42 hp-4300G kernel:  _raw_spin_lock_irqsave+0x39/0x50
> > Jun 29 18:28:42 hp-4300G kernel:  swiotlb_tbl_map_single+0x12b/0x4c0
> > 
> > Then that correlates with R11 holding the 'dma_io_tlb_mem' pointer and
> > RDX pointing at the spinlock. Yet RAX is holding junk :/
> > 
> > I agree that enabling KASAN would be a good idea, but I also think we
> > probably need to get some more information out of swiotlb_tbl_map_single()
> > to see see what exactly is going wrong in there.
> 
> I can certainly enable KASAN and if there is any debug print I can add
> or dump anything, let me know!

I bit the bullet and took v5.13 with swiotlb/for-linus-5.14 merged in, built
x86 defconfig and ran it on my laptop. However, it seems to work fine!

Please can you share your .config?

Will
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v4 12/17] drm/uAPI: Add "preferred color format" drm property as setting for userspace

[Werner Sembach]

Am 01.07.21 um 10:07 schrieb Pekka Paalanen:

> On Wed, 30 Jun 2021 11:20:18 +0200
> Werner Sembach  wrote:
>
>> Am 30.06.21 um 10:41 schrieb Pekka Paalanen:
>>
>>> On Tue, 29 Jun 2021 13:39:18 +0200
>>> Werner Sembach  wrote:
>>>  
 Am 29.06.21 um 13:17 schrieb Pekka Paalanen:  
> On Tue, 29 Jun 2021 08:12:54 +
> Simon Ser  wrote:
> 
>> On Tuesday, June 22nd, 2021 at 09:15, Pekka Paalanen 
>>  wrote:
>> 
>>> yes, I think this makes sense, even if it is a property that one can't
>>> tell for sure what it does before hand.
>>>
>>> Using a pair of properties, preference and active, to ask for something
>>> and then check what actually worked is good for reducing the
>>> combinatorial explosion caused by needing to "atomic TEST_ONLY commit"
>>> test different KMS configurations. Userspace has a better chance of
>>> finding a configuration that is possible.
>>>
>>> OTOH, this has the problem than in UI one cannot tell the user in
>>> advance which options are truly possible. Given that KMS properties are
>>> rarely completely independent, and in this case known to depend on
>>> several other KMS properties, I think it is good enough to know after
>>> the fact.
>>>
>>> If a driver does not use what userspace prefers, there is no way to
>>> understand why, or what else to change to make it happen. That problem
>>> exists anyway, because TEST_ONLY commits do not give useful feedback
>>> but only a yes/no.  
>> By submitting incremental atomic reqs with TEST_ONLY (i.e. only changing 
>> one
>> property at a time), user-space can discover which property makes the 
>> atomic
>> commit fail.  
> That works if the properties are independent of each other. Color
> range, color format, bpc and more may all be interconnected,
> allowing only certain combinations to work.
>
> If all these properties have "auto" setting too, then it would be
> possible to probe each property individually, but that still does not
> tell which combinations are valid.
>
> If you probe towards a certain configuration by setting the properties
> one by one, then depending on the order you pick the properties, you
> may come to a different conclusion on which property breaks the
> configuration.  
 My mind crossed another point that must be considered: When plugin in
 a Monitor a list of possible Resolutions+Framerate combinations is
 created for xrandr and other userspace (I guess by atomic checks? but
 I don't know).  
>>> Hi,
>>>
>>> I would not think so, but I hope to be corrected if I'm wrong.
>>>
>>> My belief is that the driver collects a list of modes from EDID, some
>>> standard modes, and maybe some other hardcoded modes, and then
>>> validates each entry against all the known limitations like vertical
>>> and horizontal frequency limits, discarding modes that do not fit.
>>>
>>> Not all limitations are known during that phase, which is why KMS
>>> property "link-status" exists. When userspace actually programs a mode
>>> (not a TEST_ONLY commit), the link training may fail. The kernel prunes
>>> the mode from the list and sets the link status property to signal
>>> failure, and sends a hotplug uevent. Userspace needs to re-check the
>>> mode list and try again.
>>>
>>> That is a generic escape hatch for when TEST_ONLY commit succeeds, but
>>> in reality the hardware cannot do it, you just cannot know until you
>>> actually try for real. It causes end user visible flicker if it happens
>>> on an already running connector, but since it usually happens when
>>> turning a connector on to begin with, there is no flicker to be seen,
>>> just a small delay in finding a mode that works.
>>>  
 During this drm
 properties are already considered, which is no problem atm because as
 far as i can tell there is currently no drm property that would make
 a certain Resolutions+Framerate combination unreachable that would be
 possible with everything on default.  
>>> I would not expect KMS properties to be considered at all. It would
>>> reject modes that are actually possible if the some KMS properties were
>>> changed. So at least going forward, current KMS property values cannot
>>> factor in.  
>> At least the debugfs variable "force_yuv420_output" did change the 
>> available modes here: 
>> https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c#L5165
>>  
>> before my patch 
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=68eb3ae3c63708f823aeeb63bb15197c727bd9bf
> Hi,
>
> debugfs is not proper UAPI, so we can just ignore it. Display servers
> cannot be expected to poke in debugfs. Debugfs is not even supposed to
> exist in production systems, but I'm sure people use it for hacking
> stuff. But that's all it is for: developer testing and hacking.
e.g. Ubun

[Intel-gfx] [PATCH 0/3] lpsp with hdmi/dp outputs

[Anshuman Gupta]

This revision has fixed review comment from Imre on RFC patch.
https://patchwork.freedesktop.org/series/90827/

Anshuman Gupta (3):
  drm/i915/dg1: Adjust the AUDIO power domain
  drm/i915/display: Use AUDIO_MMIO for crtc power domain mask
  drm/i915/audio: Use AUDIO_PLAYBACK power domain

 drivers/gpu/drm/i915/display/intel_audio.c|   4 +-
 drivers/gpu/drm/i915/display/intel_ddi.c  |   2 +-
 drivers/gpu/drm/i915/display/intel_display.c  |   2 +-
 .../drm/i915/display/intel_display_power.c| 232 --
 .../drm/i915/display/intel_display_power.h|   3 +-
 5 files changed, 223 insertions(+), 20 deletions(-)

-- 
2.26.2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 0/3] lpsp with hdmi/dp outputs

[Anshuman Gupta]

This revision has fixed review comment from Imre on RFC patch.
https://patchwork.freedesktop.org/series/90827/

Anshuman Gupta (3):
  drm/i915/dg1: Adjust the AUDIO power domain
  drm/i915/display: Use AUDIO_MMIO for crtc power domain mask
  drm/i915/audio: Use AUDIO_PLAYBACK power domain

 drivers/gpu/drm/i915/display/intel_audio.c|   4 +-
 drivers/gpu/drm/i915/display/intel_ddi.c  |   2 +-
 drivers/gpu/drm/i915/display/intel_display.c  |   2 +-
 .../drm/i915/display/intel_display_power.c| 232 --
 .../drm/i915/display/intel_display_power.h|   3 +-
 5 files changed, 223 insertions(+), 20 deletions(-)

-- 
2.26.2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 2/3] drm/i915/display: Use AUDIO_MMIO for crtc power domain mask

[Anshuman Gupta]

Use POWER_DOMAIN_AUDIO_MMIO power domain instead of
POWER_DOMAIN_AUDIO in crtc power domain mask.

It will save the power in use cases when DP/HDMI connectors
configured with PIPE_A without any audio playback.

v1: Changes since RFC
- changed power domain names. [Imre]

Cc: Ville Syrjälä 
Cc: Kai Vehmanen 
Cc: Uma Shankar 
Cc: Imre Deak 
Signed-off-by: Anshuman Gupta 
---
 drivers/gpu/drm/i915/display/intel_ddi.c | 2 +-
 drivers/gpu/drm/i915/display/intel_display.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 91fd85bee1d2..4778c3e377aa 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3441,7 +3441,7 @@ static bool intel_ddi_is_audio_enabled(struct 
drm_i915_private *dev_priv,
if (cpu_transcoder == TRANSCODER_EDP)
return false;
 
-   if (!intel_display_power_is_enabled(dev_priv, POWER_DOMAIN_AUDIO))
+   if (!intel_display_power_is_enabled(dev_priv, POWER_DOMAIN_AUDIO_MMIO))
return false;
 
return intel_de_read(dev_priv, HSW_AUD_PIN_ELD_CP_VLD) &
diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 026c28c612f0..dd5994c44c3f 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -3864,7 +3864,7 @@ static u64 get_crtc_power_domains(struct intel_crtc_state 
*crtc_state)
}
 
if (HAS_DDI(dev_priv) && crtc_state->has_audio)
-   mask |= BIT_ULL(POWER_DOMAIN_AUDIO);
+   mask |= BIT_ULL(POWER_DOMAIN_AUDIO_MMIO);
 
if (crtc_state->shared_dpll)
mask |= BIT_ULL(POWER_DOMAIN_DISPLAY_CORE);
-- 
2.26.2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 3/3] drm/i915/audio: Use AUDIO_PLAYBACK power domain

[Anshuman Gupta]

Use POWER_DOMAIN_AUDIO_PLAYBACK to enable/disable
display audio codec power in intel_display_power_{get, put}

v1: Changes since RFC
- changed power domain names. [Imre]

Cc: Kai Vehmanen 
Cc: Uma Shankar 
Signed-off-by: Anshuman Gupta 
---
 drivers/gpu/drm/i915/display/intel_audio.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_audio.c 
b/drivers/gpu/drm/i915/display/intel_audio.c
index 5f4f316b3ab5..532237588511 100644
--- a/drivers/gpu/drm/i915/display/intel_audio.c
+++ b/drivers/gpu/drm/i915/display/intel_audio.c
@@ -1001,7 +1001,7 @@ static unsigned long 
i915_audio_component_get_power(struct device *kdev)
/* Catch potential impedance mismatches before they occur! */
BUILD_BUG_ON(sizeof(intel_wakeref_t) > sizeof(unsigned long));
 
-   ret = intel_display_power_get(dev_priv, POWER_DOMAIN_AUDIO);
+   ret = intel_display_power_get(dev_priv, POWER_DOMAIN_AUDIO_PLAYBACK);
 
if (dev_priv->audio_power_refcount++ == 0) {
if (DISPLAY_VER(dev_priv) >= 9) {
@@ -1034,7 +1034,7 @@ static void i915_audio_component_put_power(struct device 
*kdev,
if (IS_GEMINILAKE(dev_priv))
glk_force_audio_cdclk(dev_priv, false);
 
-   intel_display_power_put(dev_priv, POWER_DOMAIN_AUDIO, cookie);
+   intel_display_power_put(dev_priv, POWER_DOMAIN_AUDIO_PLAYBACK, cookie);
 }
 
 static void i915_audio_component_codec_wake_override(struct device *kdev,
-- 
2.26.2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/3] drm/i915/dg1: Adjust the AUDIO power domain

[Anshuman Gupta]

DG1 and XE_PLD platforms has Audio MMIO/VERBS lies in PG0 power
well. Adjusting the power domain accordingly to
POWER_DOMAIN_AUDIO_VERBS for audio detection and POWER_DOMAIN_AUDIO
for audio playback.

v1: Changes since RFC
- changed power domain names. [Imre]
- Removed TC{3,6}, AUX_USBC{3,6} and TBT from DG1
  power well and PW_3 power domains. [Imre]
- Fixed the order of powe wells , power domains and its
  registration. [Imre]

Cc: Ville Syrjälä 
Cc: Kai Vehmanen 
Cc: Uma Shankar 
Cc: Imre Deak 
Signed-off-by: Anshuman Gupta 
---
 .../drm/i915/display/intel_display_power.c| 232 --
 .../drm/i915/display/intel_display_power.h|   3 +-
 2 files changed, 219 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c 
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 285380079aab..e2d1c4f5ee88 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -106,8 +106,10 @@ intel_display_power_domain_str(enum 
intel_display_power_domain domain)
return "PORT_OTHER";
case POWER_DOMAIN_VGA:
return "VGA";
-   case POWER_DOMAIN_AUDIO:
-   return "AUDIO";
+   case POWER_DOMAIN_AUDIO_MMIO:
+   return "AUDIO_MMIO";
+   case POWER_DOMAIN_AUDIO_PLAYBACK:
+   return "AUDIO_PLAYBAK";
case POWER_DOMAIN_AUX_A:
return "AUX_A";
case POWER_DOMAIN_AUX_B:
@@ -2508,7 +2510,8 @@ intel_display_power_put_mask_in_set(struct 
drm_i915_private *i915,
BIT_ULL(POWER_DOMAIN_PORT_DSI) |\
BIT_ULL(POWER_DOMAIN_PORT_CRT) |\
BIT_ULL(POWER_DOMAIN_VGA) | \
-   BIT_ULL(POWER_DOMAIN_AUDIO) |   \
+   BIT_ULL(POWER_DOMAIN_AUDIO_MMIO) |  \
+   BIT_ULL(POWER_DOMAIN_AUDIO_PLAYBACK) |  \
BIT_ULL(POWER_DOMAIN_AUX_B) |   \
BIT_ULL(POWER_DOMAIN_AUX_C) |   \
BIT_ULL(POWER_DOMAIN_GMBUS) |   \
@@ -2558,7 +2561,8 @@ intel_display_power_put_mask_in_set(struct 
drm_i915_private *i915,
BIT_ULL(POWER_DOMAIN_PORT_DDI_D_LANES) |\
BIT_ULL(POWER_DOMAIN_PORT_DSI) |\
BIT_ULL(POWER_DOMAIN_VGA) | \
-   BIT_ULL(POWER_DOMAIN_AUDIO) |   \
+   BIT_ULL(POWER_DOMAIN_AUDIO_MMIO) |  \
+   BIT_ULL(POWER_DOMAIN_AUDIO_PLAYBACK) |  \
BIT_ULL(POWER_DOMAIN_AUX_B) |   \
BIT_ULL(POWER_DOMAIN_AUX_C) |   \
BIT_ULL(POWER_DOMAIN_AUX_D) |   \
@@ -2591,7 +2595,8 @@ intel_display_power_put_mask_in_set(struct 
drm_i915_private *i915,
BIT_ULL(POWER_DOMAIN_PORT_DDI_D_LANES) |\
BIT_ULL(POWER_DOMAIN_PORT_CRT) | /* DDI E */\
BIT_ULL(POWER_DOMAIN_VGA) | \
-   BIT_ULL(POWER_DOMAIN_AUDIO) |   \
+   BIT_ULL(POWER_DOMAIN_AUDIO_MMIO) |  \
+   BIT_ULL(POWER_DOMAIN_AUDIO_PLAYBACK) |  \
BIT_ULL(POWER_DOMAIN_INIT))
 
 #define BDW_DISPLAY_POWER_DOMAINS (\
@@ -2607,7 +2612,8 @@ intel_display_power_put_mask_in_set(struct 
drm_i915_private *i915,
BIT_ULL(POWER_DOMAIN_PORT_DDI_D_LANES) |\
BIT_ULL(POWER_DOMAIN_PORT_CRT) | /* DDI E */\
BIT_ULL(POWER_DOMAIN_VGA) | \
-   BIT_ULL(POWER_DOMAIN_AUDIO) |   \
+   BIT_ULL(POWER_DOMAIN_AUDIO_MMIO) |  \
+   BIT_ULL(POWER_DOMAIN_AUDIO_PLAYBACK) |  \
BIT_ULL(POWER_DOMAIN_INIT))
 
 #define SKL_DISPLAY_POWERWELL_2_POWER_DOMAINS (\
@@ -2625,7 +2631,8 @@ intel_display_power_put_mask_in_set(struct 
drm_i915_private *i915,
BIT_ULL(POWER_DOMAIN_AUX_B) |   \
BIT_ULL(POWER_DOMAIN_AUX_C) |   \
BIT_ULL(POWER_DOMAIN_AUX_D) |   \
-   BIT_ULL(POWER_DOMAIN_AUDIO) |   \
+   BIT_ULL(POWER_DOMAIN_AUDIO_MMIO) |  \
+   BIT_ULL(POWER_DOMAIN_AUDIO_PLAYBACK) |  \
BIT_ULL(POWER_DOMAIN_VGA) | \
BIT_ULL(POWER_DOMAIN_INIT))
 #define SKL_DISPLAY_DDI_IO_A_E_POWER_DOMAINS ( \
@@ -2660,7 +2667,8 @@ intel_display_power_put_mask_in_set(struct 
drm_i915_private *i915,
BIT_ULL(POWER_DOMAIN_PORT_DDI_C_LANES) |\
BIT_ULL(POWER_DOMAIN_AUX_B) |   \
BIT_ULL(POWER_DOMAIN_AUX_C) |   \
-   BIT_ULL(POWER_DOMAIN_AUDIO) |   \
+   BIT_ULL(POWER_DOMAIN_AUDIO_MMIO) |  \
+   BIT_ULL(POWER_DOMAIN_AUDIO_PLAYBACK) |  \
BIT_ULL(POWER_DOMAIN_VGA) | \
BIT_ULL(POWER_DOMAIN_INIT))
 #define BXT_DISPLAY_DC_OFF_POWER_DOMAINS (   

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for lpsp with hdmi/dp outputs

[Patchwork]

== Series Details ==

Series: lpsp with hdmi/dp outputs
URL   : https://patchwork.freedesktop.org/series/92108/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+drivers/gpu/drm/i915/display/intel_display.c:1896:21:expected struct 
i915_vma *[assigned] vma
+drivers/gpu/drm/i915/display/intel_display.c:1896:21:got void [noderef] 
__iomem *[assigned] iomem
+drivers/gpu/drm/i915/display/intel_display.c:1896:21: warning: incorrect type 
in assignment (different address spaces)
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_reset.c:1396:5: warning: context imbalance in 
'intel_gt_reset_trylock' - different lock contexts for basic block
+drivers/gpu/drm/i915/gt/intel_ring_submission.c:1207:24: warning: Using plain 
integer as NULL pointer
+drivers/gpu/drm/i915/i915_perf.c:1434:15: warning: memset with byte count of 
16777216
+drivers/gpu/drm/i915/i915_perf.c:1488:15: warning: memset with byte count of 
16777216
+./include/asm-generic/bitops/find.h:112:45: warning: shift count is negative 
(-262080)
+./include/asm-generic/bitops/find.h:32:31: warning: shift count is negative 
(-262080)
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read16' 
- different lock contexts for basic block
+./include/linux/

Re: [Intel-gfx] [PATCH v4 12/17] drm/uAPI: Add "preferred color format" drm property as setting for userspace

[Pekka Paalanen]

On Thu, 1 Jul 2021 14:50:13 +0200
Werner Sembach  wrote:

> Am 01.07.21 um 10:07 schrieb Pekka Paalanen:
> 
> > On Wed, 30 Jun 2021 11:20:18 +0200
> > Werner Sembach  wrote:
> >  
> >> Am 30.06.21 um 10:41 schrieb Pekka Paalanen:
> >>  
> >>> On Tue, 29 Jun 2021 13:39:18 +0200
> >>> Werner Sembach  wrote:
> >>>
>  Am 29.06.21 um 13:17 schrieb Pekka Paalanen:
> > On Tue, 29 Jun 2021 08:12:54 +
> > Simon Ser  wrote:
> >   
> >> On Tuesday, June 22nd, 2021 at 09:15, Pekka Paalanen 
> >>  wrote:
> >>   
> >>> yes, I think this makes sense, even if it is a property that one can't
> >>> tell for sure what it does before hand.
> >>>
> >>> Using a pair of properties, preference and active, to ask for 
> >>> something
> >>> and then check what actually worked is good for reducing the
> >>> combinatorial explosion caused by needing to "atomic TEST_ONLY commit"
> >>> test different KMS configurations. Userspace has a better chance of
> >>> finding a configuration that is possible.
> >>>
> >>> OTOH, this has the problem than in UI one cannot tell the user in
> >>> advance which options are truly possible. Given that KMS properties 
> >>> are
> >>> rarely completely independent, and in this case known to depend on
> >>> several other KMS properties, I think it is good enough to know after
> >>> the fact.
> >>>
> >>> If a driver does not use what userspace prefers, there is no way to
> >>> understand why, or what else to change to make it happen. That problem
> >>> exists anyway, because TEST_ONLY commits do not give useful feedback
> >>> but only a yes/no.
> >> By submitting incremental atomic reqs with TEST_ONLY (i.e. only 
> >> changing one
> >> property at a time), user-space can discover which property makes the 
> >> atomic
> >> commit fail.
> > That works if the properties are independent of each other. Color
> > range, color format, bpc and more may all be interconnected,
> > allowing only certain combinations to work.
> >
> > If all these properties have "auto" setting too, then it would be
> > possible to probe each property individually, but that still does not
> > tell which combinations are valid.
> >
> > If you probe towards a certain configuration by setting the properties
> > one by one, then depending on the order you pick the properties, you
> > may come to a different conclusion on which property breaks the
> > configuration.
>  My mind crossed another point that must be considered: When plugin in
>  a Monitor a list of possible Resolutions+Framerate combinations is
>  created for xrandr and other userspace (I guess by atomic checks? but
>  I don't know).
> >>> Hi,
> >>>
> >>> I would not think so, but I hope to be corrected if I'm wrong.
> >>>
> >>> My belief is that the driver collects a list of modes from EDID, some
> >>> standard modes, and maybe some other hardcoded modes, and then
> >>> validates each entry against all the known limitations like vertical
> >>> and horizontal frequency limits, discarding modes that do not fit.
> >>>
> >>> Not all limitations are known during that phase, which is why KMS
> >>> property "link-status" exists. When userspace actually programs a mode
> >>> (not a TEST_ONLY commit), the link training may fail. The kernel prunes
> >>> the mode from the list and sets the link status property to signal
> >>> failure, and sends a hotplug uevent. Userspace needs to re-check the
> >>> mode list and try again.
> >>>
> >>> That is a generic escape hatch for when TEST_ONLY commit succeeds, but
> >>> in reality the hardware cannot do it, you just cannot know until you
> >>> actually try for real. It causes end user visible flicker if it happens
> >>> on an already running connector, but since it usually happens when
> >>> turning a connector on to begin with, there is no flicker to be seen,
> >>> just a small delay in finding a mode that works.
> >>>
>  During this drm
>  properties are already considered, which is no problem atm because as
>  far as i can tell there is currently no drm property that would make
>  a certain Resolutions+Framerate combination unreachable that would be
>  possible with everything on default.
> >>> I would not expect KMS properties to be considered at all. It would
> >>> reject modes that are actually possible if the some KMS properties were
> >>> changed. So at least going forward, current KMS property values cannot
> >>> factor in.
> >> At least the debugfs variable "force_yuv420_output" did change the 
> >> available modes here: 
> >> https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c#L5165
> >>  
> >> before my patch 
> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=68eb3ae3c63708f823aeeb63bb15197c727bd9bf
> 

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Add TTM offset argument to mmap.

[Patchwork]

== Series Details ==

Series: drm/i915: Add TTM offset argument to mmap.
URL   : https://patchwork.freedesktop.org/series/92103/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10297_full -> Patchwork_20505_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_20505_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_20505_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  

Possible new issues
---

  Here are the unknown changes that may have been introduced in 
Patchwork_20505_full:

### IGT changes ###

 Possible regressions 

  * igt@kms_big_fb@yf-tiled-16bpp-rotate-0:
- shard-glk:  [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10297/shard-glk3/igt@kms_big...@yf-tiled-16bpp-rotate-0.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20505/shard-glk2/igt@kms_big...@yf-tiled-16bpp-rotate-0.html

  * igt@kms_big_fb@yf-tiled-max-hw-stride-32bpp-rotate-180-async-flip:
- shard-skl:  NOTRUN -> [FAIL][3]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20505/shard-skl1/igt@kms_big...@yf-tiled-max-hw-stride-32bpp-rotate-180-async-flip.html

  
Known issues


  Here are the changes found in Patchwork_20505_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@debugfs_test@read_all_entries_display_on:
- shard-skl:  [PASS][4] -> [DMESG-WARN][5] ([i915#1982]) +1 similar 
issue
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10297/shard-skl9/igt@debugfs_test@read_all_entries_display_on.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20505/shard-skl5/igt@debugfs_test@read_all_entries_display_on.html

  * igt@gem_ctx_persistence@many-contexts:
- shard-tglb: [PASS][6] -> [FAIL][7] ([i915#2410])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10297/shard-tglb7/igt@gem_ctx_persiste...@many-contexts.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20505/shard-tglb5/igt@gem_ctx_persiste...@many-contexts.html

  * igt@gem_eio@unwedge-stress:
- shard-tglb: [PASS][8] -> [TIMEOUT][9] ([i915#2369] / [i915#3063] 
/ [i915#3648])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10297/shard-tglb3/igt@gem_...@unwedge-stress.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20505/shard-tglb7/igt@gem_...@unwedge-stress.html

  * igt@gem_exec_fair@basic-none@vecs0:
- shard-kbl:  [PASS][10] -> [FAIL][11] ([i915#2842]) +1 similar 
issue
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10297/shard-kbl3/igt@gem_exec_fair@basic-n...@vecs0.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20505/shard-kbl6/igt@gem_exec_fair@basic-n...@vecs0.html

  * igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-glk:  NOTRUN -> [FAIL][12] ([i915#2842])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20505/shard-glk7/igt@gem_exec_fair@basic-pace-s...@rcs0.html

  * igt@gem_exec_flush@basic-batch-kernel-default-cmd:
- shard-iclb: NOTRUN -> [SKIP][13] ([fdo#109313])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20505/shard-iclb1/igt@gem_exec_fl...@basic-batch-kernel-default-cmd.html

  * igt@gem_mmap_gtt@cpuset-big-copy-xy:
- shard-iclb: [PASS][14] -> [FAIL][15] ([i915#2428])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10297/shard-iclb3/igt@gem_mmap_...@cpuset-big-copy-xy.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20505/shard-iclb7/igt@gem_mmap_...@cpuset-big-copy-xy.html

  * igt@gen9_exec_parse@bb-large:
- shard-skl:  NOTRUN -> [FAIL][16] ([i915#3296])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20505/shard-skl1/igt@gen9_exec_pa...@bb-large.html
- shard-glk:  NOTRUN -> [FAIL][17] ([i915#3296])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20505/shard-glk7/igt@gen9_exec_pa...@bb-large.html
- shard-kbl:  NOTRUN -> [FAIL][18] ([i915#3296])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20505/shard-kbl7/igt@gen9_exec_pa...@bb-large.html

  * igt@i915_pm_rpm@modeset-pc8-residency-stress:
- shard-apl:  NOTRUN -> [SKIP][19] ([fdo#109271]) +111 similar 
issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20505/shard-apl3/igt@i915_pm_...@modeset-pc8-residency-stress.html

  * igt@i915_query@query-topology-known-pci-ids:
- shard-iclb: NOTRUN -> [SKIP][20] ([fdo#109303])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20505/shard-iclb1/igt@i915_qu...@query-topology-known-pci-ids.html

  * igt@kms_color@pipe-b-ctm-0-25:
- shard-skl:  NOTRUN -> [DMESG-WARN][21] (

[Intel-gfx] ✓ Fi.CI.BAT: success for lpsp with hdmi/dp outputs

[Patchwork]

== Series Details ==

Series: lpsp with hdmi/dp outputs
URL   : https://patchwork.freedesktop.org/series/92108/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10297 -> Patchwork_20506


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20506/index.html


Changes
---

  No changes found


Participating hosts (37 -> 35)
--

  Missing(2): fi-bsw-cyan fi-bdw-samus 


Build changes
-

  * Linux: CI_DRM_10297 -> Patchwork_20506

  CI-20190529: 20190529
  CI_DRM_10297: 96c7ad60de68518bdcd0d0e6381a2359034a0226 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6125: 5bb62cb290fa32777934de4b39e107ccd282f7e8 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_20506: b5cbf9ab064d49157bca393b17aa93a1d726d2ab @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

b5cbf9ab064d drm/i915/audio: Use AUDIO_PLAYBACK power domain
ccb7234a2d9f drm/i915/display: Use AUDIO_MMIO for crtc power domain mask
9b0be9be5168 drm/i915/dg1: Adjust the AUDIO power domain

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20506/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 2/2] drm/i915/gem: Migrate to system at dma-buf attach time

[Michael J. Ruhl]

From: Thomas Hellström 

Until we support p2p dma or as a complement to that, migrate data
to system memory at dma-buf attach time if possible.

v2:
- Rebase on dynamic exporter. Update the igt_dmabuf_import_same_driver
  selftest to migrate if we are LMEM capable.
v3:
- Migrate also in the pin() callback.
v4:
- Migrate in attach

Signed-off-by: Thomas Hellström 
Signed-off-by: Michael J. Ruhl 
---
 drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c   | 12 +++-
 drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c |  4 +++-
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c 
b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
index 00338c8d3739..406016aeb200 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
@@ -170,9 +170,19 @@ static int i915_gem_dmabuf_attach(struct dma_buf *dmabuf,
  struct dma_buf_attachment *attach)
 {
struct drm_i915_gem_object *obj = dma_buf_to_obj(dmabuf);
+   int ret;
 
assert_object_held(obj);
-   return i915_gem_object_pin_pages(obj);
+
+   if (!i915_gem_object_can_migrate(obj, INTEL_REGION_SMEM))
+   return -EOPNOTSUPP;
+   ret = i915_gem_object_migrate(obj, NULL, INTEL_REGION_SMEM);
+   if (!ret)
+   ret = i915_gem_object_wait_migration(obj, 0);
+   if (!ret)
+   ret = i915_gem_object_pin_pages(obj);
+
+   return ret;
 }
 
 static void i915_gem_dmabuf_detach(struct dma_buf *dmabuf,
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c 
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
index 10a113cc00a5..6feac1a14281 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
@@ -101,7 +101,9 @@ static int igt_dmabuf_import_same_driver(void *arg)
int err;
 
force_different_devices = true;
-   obj = i915_gem_object_create_shmem(i915, PAGE_SIZE);
+   obj = i915_gem_object_create_lmem(i915, PAGE_SIZE, 0);
+   if (IS_ERR(obj))
+   obj = i915_gem_object_create_shmem(i915, PAGE_SIZE);
if (IS_ERR(obj))
goto out_ret;
 
-- 
2.31.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/2] drm/i915/gem: Correct the locking and pin pattern for dma-buf

[Michael J. Ruhl]

From: Thomas Hellström 

If our exported dma-bufs are imported by another instance of our driver,
that instance will typically have the imported dma-bufs locked during
dma_buf_map_attachment(). But the exporter also locks the same reservation
object in the map_dma_buf() callback, which leads to recursive locking.

So taking the lock inside _pin_pages_unlocked() is incorrect.

Additionally, the current pinning code path is contrary to the defined
way that pinning should occur.

Remove the explicit pin/unpin from the map/umap functions and move them
to the attach/detach allowing correct locking to occur, and to match
the static dma-buf drm_prime pattern.

Add a live selftest to exercise both dynamic and non-dynamic
exports.

v2:
- Extend the selftest with a fake dynamic importer.
- Provide real pin and unpin callbacks to not abuse the interface.
v3: (ruhl)
- Remove the dynamic export support and move the pinning into the
  attach/detach path.

Reported-by: Michael J. Ruhl 
Signed-off-by: Thomas Hellström 
Signed-off-by: Michael J. Ruhl 
---
 drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c|  46 ++--
 .../drm/i915/gem/selftests/i915_gem_dmabuf.c  | 111 +-
 2 files changed, 143 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c 
b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
index 616c3a2f1baf..00338c8d3739 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
@@ -12,6 +12,8 @@
 #include "i915_gem_object.h"
 #include "i915_scatterlist.h"
 
+I915_SELFTEST_DECLARE(static bool force_different_devices;)
+
 static struct drm_i915_gem_object *dma_buf_to_obj(struct dma_buf *buf)
 {
return to_intel_bo(buf->priv);
@@ -25,15 +27,11 @@ static struct sg_table *i915_gem_map_dma_buf(struct 
dma_buf_attachment *attachme
struct scatterlist *src, *dst;
int ret, i;
 
-   ret = i915_gem_object_pin_pages_unlocked(obj);
-   if (ret)
-   goto err;
-
/* Copy sg so that we make an independent mapping */
st = kmalloc(sizeof(struct sg_table), GFP_KERNEL);
if (st == NULL) {
ret = -ENOMEM;
-   goto err_unpin_pages;
+   goto err;
}
 
ret = sg_alloc_table(st, obj->mm.pages->nents, GFP_KERNEL);
@@ -58,8 +56,6 @@ static struct sg_table *i915_gem_map_dma_buf(struct 
dma_buf_attachment *attachme
sg_free_table(st);
 err_free:
kfree(st);
-err_unpin_pages:
-   i915_gem_object_unpin_pages(obj);
 err:
return ERR_PTR(ret);
 }
@@ -68,13 +64,9 @@ static void i915_gem_unmap_dma_buf(struct dma_buf_attachment 
*attachment,
   struct sg_table *sg,
   enum dma_data_direction dir)
 {
-   struct drm_i915_gem_object *obj = dma_buf_to_obj(attachment->dmabuf);
-
dma_unmap_sgtable(attachment->dev, sg, dir, DMA_ATTR_SKIP_CPU_SYNC);
sg_free_table(sg);
kfree(sg);
-
-   i915_gem_object_unpin_pages(obj);
 }
 
 static int i915_gem_dmabuf_vmap(struct dma_buf *dma_buf, struct dma_buf_map 
*map)
@@ -168,7 +160,32 @@ static int i915_gem_end_cpu_access(struct dma_buf 
*dma_buf, enum dma_data_direct
return err;
 }
 
+/**
+ * i915_gem_dmabuf_attach - Do any extra attach work necessary
+ * @dmabuf: imported dma-buf
+ * @attach: new attach to do work on
+ *
+ */
+static int i915_gem_dmabuf_attach(struct dma_buf *dmabuf,
+ struct dma_buf_attachment *attach)
+{
+   struct drm_i915_gem_object *obj = dma_buf_to_obj(dmabuf);
+
+   assert_object_held(obj);
+   return i915_gem_object_pin_pages(obj);
+}
+
+static void i915_gem_dmabuf_detach(struct dma_buf *dmabuf,
+ struct dma_buf_attachment *attach)
+{
+   struct drm_i915_gem_object *obj = dma_buf_to_obj(dmabuf);
+
+   i915_gem_object_unpin_pages(obj);
+}
+
 static const struct dma_buf_ops i915_dmabuf_ops =  {
+   .attach = i915_gem_dmabuf_attach,
+   .detach = i915_gem_dmabuf_detach,
.map_dma_buf = i915_gem_map_dma_buf,
.unmap_dma_buf = i915_gem_unmap_dma_buf,
.release = drm_gem_dmabuf_release,
@@ -204,6 +221,8 @@ static int i915_gem_object_get_pages_dmabuf(struct 
drm_i915_gem_object *obj)
struct sg_table *pages;
unsigned int sg_page_sizes;
 
+   assert_object_held(obj);
+
pages = dma_buf_map_attachment(obj->base.import_attach,
   DMA_BIDIRECTIONAL);
if (IS_ERR(pages))
@@ -219,6 +238,8 @@ static int i915_gem_object_get_pages_dmabuf(struct 
drm_i915_gem_object *obj)
 static void i915_gem_object_put_pages_dmabuf(struct drm_i915_gem_object *obj,
 struct sg_table *pages)
 {
+   assert_object_held(obj);
+
dma_buf_unmap_attachment(obj->base.import_attach, pages,
 DMA_BIDIRECTIONAL);
 }
@@ -241,7 +262,8 @@ struct d

[Intel-gfx] [PATCH 1/3] drm/i915: use consistent CPU mappings for pin_map users

[Matthew Auld]

For discrete, users of pin_map() needs to obey the same rules at the TTM
backend, where we map system only objects as WB, and everything else as
WC. The simplest for now is to just force the correct mapping type as
per the new rules for discrete.

Suggested-by: Thomas Hellström 
Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Maarten Lankhorst 
Cc: Daniel Vetter 
Cc: Ramalingam C 
---
 drivers/gpu/drm/i915/gem/i915_gem_object.c | 34 ++
 drivers/gpu/drm/i915/gem/i915_gem_object.h |  4 +++
 drivers/gpu/drm/i915/gem/i915_gem_pages.c  | 22 --
 3 files changed, 58 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c 
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 547cc9dad90d..52ffd057259e 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -625,6 +625,40 @@ int i915_gem_object_migrate(struct drm_i915_gem_object 
*obj,
return obj->ops->migrate(obj, mr);
 }
 
+/**
+ * i915_gem_object_placement_possible - Check whether the object can be
+ * placed at certain memory type
+ * @obj: Pointer to the object
+ * @type: The memory type to check
+ *
+ * Return: True if the object can be placed in @type. False otherwise.
+ */
+bool i915_gem_object_placement_possible(struct drm_i915_gem_object *obj,
+   enum intel_memory_type type)
+{
+   unsigned int i;
+
+   if (!obj->mm.n_placements) {
+   switch(type) {
+   case INTEL_MEMORY_LOCAL:
+   return i915_gem_object_has_iomem(obj);
+   case INTEL_MEMORY_SYSTEM:
+   return i915_gem_object_has_pages(obj);
+   default:
+   /* Ignore stolen for now */
+   GEM_BUG_ON(1);
+   return false;
+   }
+   }
+
+   for (i = 0; i < obj->mm.n_placements; i++) {
+   if (obj->mm.placements[i]->type == type)
+   return true;
+   }
+
+   return false;
+}
+
 void i915_gem_init__objects(struct drm_i915_private *i915)
 {
INIT_WORK(&i915->mm.free_work, __i915_gem_free_work);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h 
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index d423d8cac4f2..8be4fadeee48 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -12,6 +12,7 @@
 #include 
 
 #include "display/intel_frontbuffer.h"
+#include "intel_memory_region.h"
 #include "i915_gem_object_types.h"
 #include "i915_gem_gtt.h"
 #include "i915_gem_ww.h"
@@ -607,6 +608,9 @@ bool i915_gem_object_can_migrate(struct drm_i915_gem_object 
*obj,
 int i915_gem_object_wait_migration(struct drm_i915_gem_object *obj,
   unsigned int flags);
 
+bool i915_gem_object_placement_possible(struct drm_i915_gem_object *obj,
+   enum intel_memory_type type);
+
 #ifdef CONFIG_MMU_NOTIFIER
 static inline bool
 i915_gem_object_is_userptr(struct drm_i915_gem_object *obj)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c 
b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
index f2f850e31b8e..810a157a18f8 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
@@ -321,8 +321,7 @@ static void *i915_gem_object_map_pfn(struct 
drm_i915_gem_object *obj,
dma_addr_t addr;
void *vaddr;
 
-   if (type != I915_MAP_WC)
-   return ERR_PTR(-ENODEV);
+   GEM_BUG_ON(type != I915_MAP_WC);
 
if (n_pfn > ARRAY_SIZE(stack)) {
/* Too big for stack -- allocate temporary array instead */
@@ -374,6 +373,25 @@ void *i915_gem_object_pin_map(struct drm_i915_gem_object 
*obj,
}
GEM_BUG_ON(!i915_gem_object_has_pages(obj));
 
+   /*
+* For discrete our CPU mappings needs to be consistent in order to
+* function correctly on !x86. When mapping things through TTM, we use
+* the same rules to determine the caching type.
+*
+* Internal users of lmem are already expected to get this right, so no
+* fudging needed there.
+*/
+   if (i915_gem_object_placement_possible(obj, INTEL_MEMORY_LOCAL)) {
+   if (type != I915_MAP_WC && !obj->mm.n_placements) {
+   ptr = ERR_PTR(-ENODEV);
+   goto err_unpin;
+   }
+
+   type = I915_MAP_WC;
+   } else if (IS_DGFX(to_i915(obj->base.dev))) {
+   type = I915_MAP_WB;
+   }
+
ptr = page_unpack_bits(obj->mm.mapping, &has_type);
if (ptr && has_type != type) {
if (pinned) {
-- 
2.26.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 2/3] drm/i915/uapi: reject caching ioctls for discrete

[Matthew Auld]

It's a noop on DG1, and in the future when need to support other devices
which let us control the coherency, then it should be an immutable
creation time property for the BO.

Suggested-by: Daniel Vetter 
Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Maarten Lankhorst 
Cc: Kenneth Graunke 
Cc: Jason Ekstrand 
Cc: Daniel Vetter 
Cc: Ramalingam C 
---
 drivers/gpu/drm/i915/gem/i915_gem_domain.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c 
b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
index 7d1400b13429..43004bef55cb 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
@@ -268,6 +268,9 @@ int i915_gem_get_caching_ioctl(struct drm_device *dev, void 
*data,
struct drm_i915_gem_object *obj;
int err = 0;
 
+   if (IS_DGFX(to_i915(dev)))
+   return -ENODEV;
+
rcu_read_lock();
obj = i915_gem_object_lookup_rcu(file, args->handle);
if (!obj) {
@@ -303,6 +306,9 @@ int i915_gem_set_caching_ioctl(struct drm_device *dev, void 
*data,
enum i915_cache_level level;
int ret = 0;
 
+   if (IS_DGFX(i915))
+   return -ENODEV;
+
switch (args->caching) {
case I915_CACHING_NONE:
level = I915_CACHE_NONE;
-- 
2.26.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 3/3] drm/i915/uapi: reject set_domain for discrete

[Matthew Auld]

The CPU domain should be static for discrete, and on DG1 we don't need
any flushing since everything is already coherent, so really all this
does is an object wait, for which we have an ioctl. Longer term the
desired caching should be an immutable creation time property for the
BO.

One other user is iris + userptr, which uses the set_domain to probe all
the pages to check if the GUP succeeds, however keeping the set_domain
around just for that seems rather scuffed. We could equally just submit
a dummy batch, which should hopefully be good enough, otherwise adding a
new creation time flag for userptr might be an option. Although longer
term we will also have vm_bind, which should also be a nice fit for
this, so adding a whole new flag is likely overkill.

Suggested-by: Daniel Vetter 
Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Maarten Lankhorst 
Cc: Kenneth Graunke 
Cc: Jason Ekstrand 
Cc: Daniel Vetter 
Cc: Ramalingam C 
---
 drivers/gpu/drm/i915/gem/i915_gem_domain.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c 
b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
index 43004bef55cb..b684a62bf3b0 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
@@ -490,6 +490,9 @@ i915_gem_set_domain_ioctl(struct drm_device *dev, void 
*data,
u32 write_domain = args->write_domain;
int err;
 
+   if (IS_DGFX(to_i915(dev)))
+   return -ENODEV;
+
/* Only handle setting domains to types used by the CPU. */
if ((write_domain | read_domains) & I915_GEM_GPU_DOMAINS)
return -EINVAL;
-- 
2.26.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [1/2] drm/i915/gem: Correct the locking and pin pattern for dma-buf

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915/gem: Correct the locking and pin 
pattern for dma-buf
URL   : https://patchwork.freedesktop.org/series/92109/
State : failure

== Summary ==

CALLscripts/checksyscalls.sh
  CALLscripts/atomic/check-atomics.sh
  DESCEND objtool
  CHK include/generated/compile.h
  CC [M]  drivers/gpu/drm/i915/gem/i915_gem_dmabuf.o
In file included from ./include/linux/init.h:5,
 from ./include/linux/io.h:10,
 from ./include/linux/dma-buf-map.h:9,
 from ./include/linux/dma-buf.h:16,
 from drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c:7:
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c: In function ‘i915_gem_prime_import’:
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c:276:27: error: 
‘force_differnt_devices’ undeclared (first use in this function); did you mean 
‘force_different_devices’?
   !I915_SELFTEST_ONLY(force_differnt_devices)) {
   ^~
./include/linux/compiler.h:78:42: note: in definition of macro ‘unlikely’
 # define unlikely(x) __builtin_expect(!!(x), 0)
  ^
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c:276:8: note: in expansion of macro 
‘I915_SELFTEST_ONLY’
   !I915_SELFTEST_ONLY(force_differnt_devices)) {
^~
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c:276:27: note: each undeclared 
identifier is reported only once for each function it appears in
   !I915_SELFTEST_ONLY(force_differnt_devices)) {
   ^~
./include/linux/compiler.h:78:42: note: in definition of macro ‘unlikely’
 # define unlikely(x) __builtin_expect(!!(x), 0)
  ^
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c:276:8: note: in expansion of macro 
‘I915_SELFTEST_ONLY’
   !I915_SELFTEST_ONLY(force_differnt_devices)) {
^~
In file included from drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c:327:
drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c: At top level:
drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c:89:17: error: 
‘igt_dmabuf_move_notify’ undeclared here (not in a function); did you mean 
‘dma_buf_move_notify’?
  .move_notify = igt_dmabuf_move_notify,
 ^~
 dma_buf_move_notify
scripts/Makefile.build:272: recipe for target 
'drivers/gpu/drm/i915/gem/i915_gem_dmabuf.o' failed
make[4]: *** [drivers/gpu/drm/i915/gem/i915_gem_dmabuf.o] Error 1
scripts/Makefile.build:515: recipe for target 'drivers/gpu/drm/i915' failed
make[3]: *** [drivers/gpu/drm/i915] Error 2
scripts/Makefile.build:515: recipe for target 'drivers/gpu/drm' failed
make[2]: *** [drivers/gpu/drm] Error 2
scripts/Makefile.build:515: recipe for target 'drivers/gpu' failed
make[1]: *** [drivers/gpu] Error 2
Makefile:1847: recipe for target 'drivers' failed
make: *** [drivers] Error 2


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/3] drm/i915: use consistent CPU mappings for pin_map users

[Patchwork]

== Series Details ==

Series: series starting with [1/3] drm/i915: use consistent CPU mappings for 
pin_map users
URL   : https://patchwork.freedesktop.org/series/92113/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
4a7bd95f84c8 drm/i915: use consistent CPU mappings for pin_map users
-:43: ERROR:SPACING: space required before the open parenthesis '('
#43: FILE: drivers/gpu/drm/i915/gem/i915_gem_object.c:642:
+   switch(type) {

total: 1 errors, 0 warnings, 0 checks, 90 lines checked
98384c7fbb4c drm/i915/uapi: reject caching ioctls for discrete
70c8c6810057 drm/i915/uapi: reject set_domain for discrete


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/3] drm/i915: use consistent CPU mappings for pin_map users

[Patchwork]

== Series Details ==

Series: series starting with [1/3] drm/i915: use consistent CPU mappings for 
pin_map users
URL   : https://patchwork.freedesktop.org/series/92113/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+drivers/gpu/drm/i915/display/intel_display.c:1896:21:expected struct 
i915_vma *[assigned] vma
+drivers/gpu/drm/i915/display/intel_display.c:1896:21:got void [noderef] 
__iomem *[assigned] iomem
+drivers/gpu/drm/i915/display/intel_display.c:1896:21: warning: incorrect type 
in assignment (different address spaces)
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_reset.c:1396:5: warning: context imbalance in 
'intel_gt_reset_trylock' - different lock contexts for basic block
+drivers/gpu/drm/i915/gt/intel_ring_submission.c:1207:24: warning: Using plain 
integer as NULL pointer
+drivers/gpu/drm/i915/i915_perf.c:1434:15: warning: memset with byte count of 
16777216
+drivers/gpu/drm/i915/i915_perf.c:1488:15: warning: memset with byte count of 
16777216
+./include/asm-generic/bitops/find.h:112:45: warning: shift count is negative 
(-262080)
+./include/asm-generic/bitops/find.h:32:31: warning: shift count is negative 
(-262080)
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read16' 
-

[Intel-gfx] [PATCH v2 1/3] drm/i915: use consistent CPU mappings for pin_map users

[Matthew Auld]

For discrete, users of pin_map() needs to obey the same rules at the TTM
backend, where we map system only objects as WB, and everything else as
WC. The simplest for now is to just force the correct mapping type as
per the new rules for discrete.

Suggested-by: Thomas Hellström 
Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Maarten Lankhorst 
Cc: Daniel Vetter 
Cc: Ramalingam C 
---
 drivers/gpu/drm/i915/gem/i915_gem_object.c | 34 ++
 drivers/gpu/drm/i915/gem/i915_gem_object.h |  4 +++
 drivers/gpu/drm/i915/gem/i915_gem_pages.c  | 22 --
 3 files changed, 58 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c 
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 547cc9dad90d..9da7b288b7ed 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -625,6 +625,40 @@ int i915_gem_object_migrate(struct drm_i915_gem_object 
*obj,
return obj->ops->migrate(obj, mr);
 }
 
+/**
+ * i915_gem_object_placement_possible - Check whether the object can be
+ * placed at certain memory type
+ * @obj: Pointer to the object
+ * @type: The memory type to check
+ *
+ * Return: True if the object can be placed in @type. False otherwise.
+ */
+bool i915_gem_object_placement_possible(struct drm_i915_gem_object *obj,
+   enum intel_memory_type type)
+{
+   unsigned int i;
+
+   if (!obj->mm.n_placements) {
+   switch (type) {
+   case INTEL_MEMORY_LOCAL:
+   return i915_gem_object_has_iomem(obj);
+   case INTEL_MEMORY_SYSTEM:
+   return i915_gem_object_has_pages(obj);
+   default:
+   /* Ignore stolen for now */
+   GEM_BUG_ON(1);
+   return false;
+   }
+   }
+
+   for (i = 0; i < obj->mm.n_placements; i++) {
+   if (obj->mm.placements[i]->type == type)
+   return true;
+   }
+
+   return false;
+}
+
 void i915_gem_init__objects(struct drm_i915_private *i915)
 {
INIT_WORK(&i915->mm.free_work, __i915_gem_free_work);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h 
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index d423d8cac4f2..8be4fadeee48 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -12,6 +12,7 @@
 #include 
 
 #include "display/intel_frontbuffer.h"
+#include "intel_memory_region.h"
 #include "i915_gem_object_types.h"
 #include "i915_gem_gtt.h"
 #include "i915_gem_ww.h"
@@ -607,6 +608,9 @@ bool i915_gem_object_can_migrate(struct drm_i915_gem_object 
*obj,
 int i915_gem_object_wait_migration(struct drm_i915_gem_object *obj,
   unsigned int flags);
 
+bool i915_gem_object_placement_possible(struct drm_i915_gem_object *obj,
+   enum intel_memory_type type);
+
 #ifdef CONFIG_MMU_NOTIFIER
 static inline bool
 i915_gem_object_is_userptr(struct drm_i915_gem_object *obj)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c 
b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
index f2f850e31b8e..810a157a18f8 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
@@ -321,8 +321,7 @@ static void *i915_gem_object_map_pfn(struct 
drm_i915_gem_object *obj,
dma_addr_t addr;
void *vaddr;
 
-   if (type != I915_MAP_WC)
-   return ERR_PTR(-ENODEV);
+   GEM_BUG_ON(type != I915_MAP_WC);
 
if (n_pfn > ARRAY_SIZE(stack)) {
/* Too big for stack -- allocate temporary array instead */
@@ -374,6 +373,25 @@ void *i915_gem_object_pin_map(struct drm_i915_gem_object 
*obj,
}
GEM_BUG_ON(!i915_gem_object_has_pages(obj));
 
+   /*
+* For discrete our CPU mappings needs to be consistent in order to
+* function correctly on !x86. When mapping things through TTM, we use
+* the same rules to determine the caching type.
+*
+* Internal users of lmem are already expected to get this right, so no
+* fudging needed there.
+*/
+   if (i915_gem_object_placement_possible(obj, INTEL_MEMORY_LOCAL)) {
+   if (type != I915_MAP_WC && !obj->mm.n_placements) {
+   ptr = ERR_PTR(-ENODEV);
+   goto err_unpin;
+   }
+
+   type = I915_MAP_WC;
+   } else if (IS_DGFX(to_i915(obj->base.dev))) {
+   type = I915_MAP_WB;
+   }
+
ptr = page_unpack_bits(obj->mm.mapping, &has_type);
if (ptr && has_type != type) {
if (pinned) {
-- 
2.26.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2 2/3] drm/i915/uapi: reject caching ioctls for discrete

[Matthew Auld]

It's a noop on DG1, and in the future when need to support other devices
which let us control the coherency, then it should be an immutable
creation time property for the BO. This will likely be controlled
through a new gem_create_ext extension.

Suggested-by: Daniel Vetter 
Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Maarten Lankhorst 
Cc: Jordan Justen 
Cc: Kenneth Graunke 
Cc: Jason Ekstrand 
Cc: Daniel Vetter 
Cc: Ramalingam C 
---
 drivers/gpu/drm/i915/gem/i915_gem_domain.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c 
b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
index 7d1400b13429..43004bef55cb 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
@@ -268,6 +268,9 @@ int i915_gem_get_caching_ioctl(struct drm_device *dev, void 
*data,
struct drm_i915_gem_object *obj;
int err = 0;
 
+   if (IS_DGFX(to_i915(dev)))
+   return -ENODEV;
+
rcu_read_lock();
obj = i915_gem_object_lookup_rcu(file, args->handle);
if (!obj) {
@@ -303,6 +306,9 @@ int i915_gem_set_caching_ioctl(struct drm_device *dev, void 
*data,
enum i915_cache_level level;
int ret = 0;
 
+   if (IS_DGFX(i915))
+   return -ENODEV;
+
switch (args->caching) {
case I915_CACHING_NONE:
level = I915_CACHE_NONE;
-- 
2.26.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2 3/3] drm/i915/uapi: reject set_domain for discrete

[Matthew Auld]

The CPU domain should be static for discrete, and on DG1 we don't need
any flushing since everything is already coherent, so really all this
does is an object wait, for which we have an ioctl. Longer term the
desired caching should be an immutable creation time property for the
BO, which can be set with something like gem_create_ext.

One other user is iris + userptr, which uses the set_domain to probe all
the pages to check if the GUP succeeds, however keeping the set_domain
around just for that seems rather scuffed. We could equally just submit
a dummy batch, which should hopefully be good enough, otherwise adding a
new creation time flag for userptr might be an option. Although longer
term we will also have vm_bind, which should also be a nice fit for
this, so adding a whole new flag is likely overkill.

Suggested-by: Daniel Vetter 
Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Maarten Lankhorst 
Cc: Jordan Justen 
Cc: Kenneth Graunke 
Cc: Jason Ekstrand 
Cc: Daniel Vetter 
Cc: Ramalingam C 
---
 drivers/gpu/drm/i915/gem/i915_gem_domain.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c 
b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
index 43004bef55cb..b684a62bf3b0 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
@@ -490,6 +490,9 @@ i915_gem_set_domain_ioctl(struct drm_device *dev, void 
*data,
u32 write_domain = args->write_domain;
int err;
 
+   if (IS_DGFX(to_i915(dev)))
+   return -ENODEV;
+
/* Only handle setting domains to types used by the CPU. */
if ((write_domain | read_domains) & I915_GEM_GPU_DOMAINS)
return -EINVAL;
-- 
2.26.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.IGT: failure for lpsp with hdmi/dp outputs

[Patchwork]

== Series Details ==

Series: lpsp with hdmi/dp outputs
URL   : https://patchwork.freedesktop.org/series/92108/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10297_full -> Patchwork_20506_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_20506_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_20506_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  

Possible new issues
---

  Here are the unknown changes that may have been introduced in 
Patchwork_20506_full:

### IGT changes ###

 Possible regressions 

  * igt@kms_big_fb@yf-tiled-max-hw-stride-32bpp-rotate-180-async-flip:
- shard-skl:  NOTRUN -> [FAIL][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20506/shard-skl6/igt@kms_big...@yf-tiled-max-hw-stride-32bpp-rotate-180-async-flip.html

  
Known issues


  Here are the changes found in Patchwork_20506_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@gem_create@create-massive:
- shard-snb:  NOTRUN -> [DMESG-WARN][2] ([i915#3002])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20506/shard-snb5/igt@gem_cre...@create-massive.html

  * igt@gem_ctx_persistence@legacy-engines-mixed:
- shard-snb:  NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#1099]) +6 
similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20506/shard-snb5/igt@gem_ctx_persiste...@legacy-engines-mixed.html

  * igt@gem_ctx_persistence@smoketest:
- shard-tglb: [PASS][4] -> [FAIL][5] ([i915#2896])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10297/shard-tglb2/igt@gem_ctx_persiste...@smoketest.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20506/shard-tglb3/igt@gem_ctx_persiste...@smoketest.html

  * igt@gem_exec_flush@basic-batch-kernel-default-cmd:
- shard-iclb: NOTRUN -> [SKIP][6] ([fdo#109313])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20506/shard-iclb1/igt@gem_exec_fl...@basic-batch-kernel-default-cmd.html

  * igt@gem_exec_reloc@basic-wide-active@rcs0:
- shard-snb:  NOTRUN -> [FAIL][7] ([i915#3633]) +2 similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20506/shard-snb5/igt@gem_exec_reloc@basic-wide-act...@rcs0.html

  * igt@gem_mmap_gtt@big-copy-odd:
- shard-glk:  [PASS][8] -> [FAIL][9] ([i915#307])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10297/shard-glk6/igt@gem_mmap_...@big-copy-odd.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20506/shard-glk2/igt@gem_mmap_...@big-copy-odd.html

  * igt@gem_pread@exhaustion:
- shard-snb:  NOTRUN -> [WARN][10] ([i915#2658])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20506/shard-snb7/igt@gem_pr...@exhaustion.html

  * igt@gen9_exec_parse@allowed-all:
- shard-kbl:  [PASS][11] -> [DMESG-WARN][12] ([i915#1436] / 
[i915#716])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10297/shard-kbl4/igt@gen9_exec_pa...@allowed-all.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20506/shard-kbl6/igt@gen9_exec_pa...@allowed-all.html

  * igt@gen9_exec_parse@bb-large:
- shard-skl:  NOTRUN -> [FAIL][13] ([i915#3296])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20506/shard-skl6/igt@gen9_exec_pa...@bb-large.html
- shard-kbl:  NOTRUN -> [FAIL][14] ([i915#3296])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20506/shard-kbl7/igt@gen9_exec_pa...@bb-large.html

  * igt@i915_query@query-topology-known-pci-ids:
- shard-iclb: NOTRUN -> [SKIP][15] ([fdo#109303])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20506/shard-iclb1/igt@i915_qu...@query-topology-known-pci-ids.html

  * igt@kms_color@pipe-a-ctm-0-5:
- shard-skl:  [PASS][16] -> [DMESG-WARN][17] ([i915#1982])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10297/shard-skl5/igt@kms_co...@pipe-a-ctm-0-5.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20506/shard-skl5/igt@kms_co...@pipe-a-ctm-0-5.html

  * igt@kms_color_chamelium@pipe-a-ctm-limited-range:
- shard-apl:  NOTRUN -> [SKIP][18] ([fdo#109271] / [fdo#111827]) 
+13 similar issues
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20506/shard-apl6/igt@kms_color_chamel...@pipe-a-ctm-limited-range.html

  * igt@kms_color_chamelium@pipe-a-ctm-max:
- shard-iclb: NOTRUN -> [SKIP][19] ([fdo#109284] / [fdo#111827]) +2 
similar issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20506/shard-iclb1/igt@kms_color_chamel...@pipe-a-ctm-max.html

  * igt@kms_color_chamelium@pipe-a-ctm-negative:
- shard-kbl:  

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915: use consistent CPU mappings for pin_map users

[Patchwork]

== Series Details ==

Series: series starting with [1/3] drm/i915: use consistent CPU mappings for 
pin_map users
URL   : https://patchwork.freedesktop.org/series/92113/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10297 -> Patchwork_20508


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20508/index.html

Known issues


  Here are the changes found in Patchwork_20508 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_cs_nop@sync-fork-compute0:
- fi-snb-2600:NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20508/fi-snb-2600/igt@amdgpu/amd_cs_...@sync-fork-compute0.html

  * igt@gem_exec_suspend@basic-s3:
- fi-skl-6700k2:  [PASS][2] -> [INCOMPLETE][3] ([i915#146] / [i915#198])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10297/fi-skl-6700k2/igt@gem_exec_susp...@basic-s3.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20508/fi-skl-6700k2/igt@gem_exec_susp...@basic-s3.html

  
 Possible fixes 

  * igt@i915_selftest@live@hangcheck:
- fi-snb-2600:[INCOMPLETE][4] ([i915#2782]) -> [PASS][5]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10297/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20508/fi-snb-2600/igt@i915_selftest@l...@hangcheck.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#146]: https://gitlab.freedesktop.org/drm/intel/issues/146
  [i915#198]: https://gitlab.freedesktop.org/drm/intel/issues/198
  [i915#2782]: https://gitlab.freedesktop.org/drm/intel/issues/2782
  [i915#3717]: https://gitlab.freedesktop.org/drm/intel/issues/3717


Participating hosts (37 -> 33)
--

  Missing(4): fi-kbl-soraka fi-bsw-cyan fi-bdw-samus fi-bsw-n3050 


Build changes
-

  * Linux: CI_DRM_10297 -> Patchwork_20508

  CI-20190529: 20190529
  CI_DRM_10297: 96c7ad60de68518bdcd0d0e6381a2359034a0226 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6125: 5bb62cb290fa32777934de4b39e107ccd282f7e8 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_20508: 70c8c6810057ca7b506673982cd2b218797ee10d @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

70c8c6810057 drm/i915/uapi: reject set_domain for discrete
98384c7fbb4c drm/i915/uapi: reject caching ioctls for discrete
4a7bd95f84c8 drm/i915: use consistent CPU mappings for pin_map users

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20508/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v2,1/3] drm/i915: use consistent CPU mappings for pin_map users

[Patchwork]

== Series Details ==

Series: series starting with [v2,1/3] drm/i915: use consistent CPU mappings for 
pin_map users
URL   : https://patchwork.freedesktop.org/series/92114/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+drivers/gpu/drm/i915/display/intel_display.c:1896:21:expected struct 
i915_vma *[assigned] vma
+drivers/gpu/drm/i915/display/intel_display.c:1896:21:got void [noderef] 
__iomem *[assigned] iomem
+drivers/gpu/drm/i915/display/intel_display.c:1896:21: warning: incorrect type 
in assignment (different address spaces)
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_reset.c:1396:5: warning: context imbalance in 
'intel_gt_reset_trylock' - different lock contexts for basic block
+drivers/gpu/drm/i915/gt/intel_ring_submission.c:1207:24: warning: Using plain 
integer as NULL pointer
+drivers/gpu/drm/i915/i915_perf.c:1434:15: warning: memset with byte count of 
16777216
+drivers/gpu/drm/i915/i915_perf.c:1488:15: warning: memset with byte count of 
16777216
+./include/asm-generic/bitops/find.h:112:45: warning: shift count is negative 
(-262080)
+./include/asm-generic/bitops/find.h:32:31: warning: shift count is negative 
(-262080)
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read16'

[Intel-gfx] [PATCH 1/2] drm/i915/gem: Correct the locking and pin pattern for dma-buf

[Michael J. Ruhl]

From: Thomas Hellström 

If our exported dma-bufs are imported by another instance of our driver,
that instance will typically have the imported dma-bufs locked during
dma_buf_map_attachment(). But the exporter also locks the same reservation
object in the map_dma_buf() callback, which leads to recursive locking.

So taking the lock inside _pin_pages_unlocked() is incorrect.

Additionally, the current pinning code path is contrary to the defined
way that pinning should occur.

Remove the explicit pin/unpin from the map/umap functions and move them
to the attach/detach allowing correct locking to occur, and to match
the static dma-buf drm_prime pattern.

Add a live selftest to exercise both dynamic and non-dynamic
exports.

v2:
- Extend the selftest with a fake dynamic importer.
- Provide real pin and unpin callbacks to not abuse the interface.
v3: (ruhl)
- Remove the dynamic export support and move the pinning into the
  attach/detach path.

Reported-by: Michael J. Ruhl 
Signed-off-by: Thomas Hellström 
Signed-off-by: Michael J. Ruhl 
---
 drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c|  46 +--
 .../drm/i915/gem/selftests/i915_gem_dmabuf.c  | 116 +-
 2 files changed, 148 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c 
b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
index 616c3a2f1baf..8c528b693a30 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
@@ -12,6 +12,8 @@
 #include "i915_gem_object.h"
 #include "i915_scatterlist.h"
 
+I915_SELFTEST_DECLARE(static bool force_different_devices;)
+
 static struct drm_i915_gem_object *dma_buf_to_obj(struct dma_buf *buf)
 {
return to_intel_bo(buf->priv);
@@ -25,15 +27,11 @@ static struct sg_table *i915_gem_map_dma_buf(struct 
dma_buf_attachment *attachme
struct scatterlist *src, *dst;
int ret, i;
 
-   ret = i915_gem_object_pin_pages_unlocked(obj);
-   if (ret)
-   goto err;
-
/* Copy sg so that we make an independent mapping */
st = kmalloc(sizeof(struct sg_table), GFP_KERNEL);
if (st == NULL) {
ret = -ENOMEM;
-   goto err_unpin_pages;
+   goto err;
}
 
ret = sg_alloc_table(st, obj->mm.pages->nents, GFP_KERNEL);
@@ -58,8 +56,6 @@ static struct sg_table *i915_gem_map_dma_buf(struct 
dma_buf_attachment *attachme
sg_free_table(st);
 err_free:
kfree(st);
-err_unpin_pages:
-   i915_gem_object_unpin_pages(obj);
 err:
return ERR_PTR(ret);
 }
@@ -68,13 +64,9 @@ static void i915_gem_unmap_dma_buf(struct dma_buf_attachment 
*attachment,
   struct sg_table *sg,
   enum dma_data_direction dir)
 {
-   struct drm_i915_gem_object *obj = dma_buf_to_obj(attachment->dmabuf);
-
dma_unmap_sgtable(attachment->dev, sg, dir, DMA_ATTR_SKIP_CPU_SYNC);
sg_free_table(sg);
kfree(sg);
-
-   i915_gem_object_unpin_pages(obj);
 }
 
 static int i915_gem_dmabuf_vmap(struct dma_buf *dma_buf, struct dma_buf_map 
*map)
@@ -168,7 +160,32 @@ static int i915_gem_end_cpu_access(struct dma_buf 
*dma_buf, enum dma_data_direct
return err;
 }
 
+/**
+ * i915_gem_dmabuf_attach - Do any extra attach work necessary
+ * @dmabuf: imported dma-buf
+ * @attach: new attach to do work on
+ *
+ */
+static int i915_gem_dmabuf_attach(struct dma_buf *dmabuf,
+ struct dma_buf_attachment *attach)
+{
+   struct drm_i915_gem_object *obj = dma_buf_to_obj(dmabuf);
+
+   assert_object_held(obj);
+   return i915_gem_object_pin_pages(obj);
+}
+
+static void i915_gem_dmabuf_detach(struct dma_buf *dmabuf,
+  struct dma_buf_attachment *attach)
+{
+   struct drm_i915_gem_object *obj = dma_buf_to_obj(dmabuf);
+
+   i915_gem_object_unpin_pages(obj);
+}
+
 static const struct dma_buf_ops i915_dmabuf_ops =  {
+   .attach = i915_gem_dmabuf_attach,
+   .detach = i915_gem_dmabuf_detach,
.map_dma_buf = i915_gem_map_dma_buf,
.unmap_dma_buf = i915_gem_unmap_dma_buf,
.release = drm_gem_dmabuf_release,
@@ -204,6 +221,8 @@ static int i915_gem_object_get_pages_dmabuf(struct 
drm_i915_gem_object *obj)
struct sg_table *pages;
unsigned int sg_page_sizes;
 
+   assert_object_held(obj);
+
pages = dma_buf_map_attachment(obj->base.import_attach,
   DMA_BIDIRECTIONAL);
if (IS_ERR(pages))
@@ -219,6 +238,8 @@ static int i915_gem_object_get_pages_dmabuf(struct 
drm_i915_gem_object *obj)
 static void i915_gem_object_put_pages_dmabuf(struct drm_i915_gem_object *obj,
 struct sg_table *pages)
 {
+   assert_object_held(obj);
+
dma_buf_unmap_attachment(obj->base.import_attach, pages,
 DMA_BIDIRECTIONAL);
 }
@@ -241,7 +262,8 @@ struct d

[Intel-gfx] [PATCH 2/2] drm/i915/gem: Migrate to system at dma-buf attach time

[Michael J. Ruhl]

From: Thomas Hellström 

Until we support p2p dma or as a complement to that, migrate data
to system memory at dma-buf attach time if possible.

v2:
- Rebase on dynamic exporter. Update the igt_dmabuf_import_same_driver
  selftest to migrate if we are LMEM capable.
v3:
- Migrate also in the pin() callback.
v4:
- Migrate in attach

Signed-off-by: Thomas Hellström 
Signed-off-by: Michael J. Ruhl 
---
 drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c   | 12 +++-
 drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c |  4 +++-
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c 
b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
index 8c528b693a30..a325f33f35b8 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
@@ -170,9 +170,19 @@ static int i915_gem_dmabuf_attach(struct dma_buf *dmabuf,
  struct dma_buf_attachment *attach)
 {
struct drm_i915_gem_object *obj = dma_buf_to_obj(dmabuf);
+   int ret;
 
assert_object_held(obj);
-   return i915_gem_object_pin_pages(obj);
+
+   if (!i915_gem_object_can_migrate(obj, INTEL_REGION_SMEM))
+   return -EOPNOTSUPP;
+   ret = i915_gem_object_migrate(obj, NULL, INTEL_REGION_SMEM);
+   if (!ret)
+   ret = i915_gem_object_wait_migration(obj, 0);
+   if (!ret)
+   ret = i915_gem_object_pin_pages(obj);
+
+   return ret;
 }
 
 static void i915_gem_dmabuf_detach(struct dma_buf *dmabuf,
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c 
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
index 868b3469ecbd..b1e87ec08741 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
@@ -106,7 +106,9 @@ static int igt_dmabuf_import_same_driver(void *arg)
int err;
 
force_different_devices = true;
-   obj = i915_gem_object_create_shmem(i915, PAGE_SIZE);
+   obj = i915_gem_object_create_lmem(i915, PAGE_SIZE, 0);
+   if (IS_ERR(obj))
+   obj = i915_gem_object_create_shmem(i915, PAGE_SIZE);
if (IS_ERR(obj))
goto out_ret;
 
-- 
2.31.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 2/4] drm/i915/guc: Print error name on CTB (de)registration failure

[Michal Wajdeczko]

Instead of plain error value (%d) print more user friendly error
name (%pe).

Signed-off-by: Michal Wajdeczko 
---
 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index a26bb55c0898..18d52c39f0c2 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -167,8 +167,8 @@ static int ct_register_buffer(struct intel_guc_ct *ct, u32 
type,
err = guc_action_register_ct_buffer(ct_to_guc(ct), type,
desc_addr, buff_addr, size);
if (unlikely(err))
-   CT_ERROR(ct, "Failed to register %s buffer (err=%d)\n",
-guc_ct_buffer_type_to_str(type), err);
+   CT_ERROR(ct, "Failed to register %s buffer (%pe)\n",
+guc_ct_buffer_type_to_str(type), ERR_PTR(err));
return err;
 }
 
@@ -195,8 +195,8 @@ static int ct_deregister_buffer(struct intel_guc_ct *ct, 
u32 type)
int err = guc_action_deregister_ct_buffer(ct_to_guc(ct), type);
 
if (unlikely(err))
-   CT_ERROR(ct, "Failed to deregister %s buffer (err=%d)\n",
-guc_ct_buffer_type_to_str(type), err);
+   CT_ERROR(ct, "Failed to deregister %s buffer (%pe)\n",
+guc_ct_buffer_type_to_str(type), ERR_PTR(err));
return err;
 }
 
-- 
2.25.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/4] drm/i915/guc: Verify result from CTB (de)register action

[Michal Wajdeczko]

In commit b839a869dfc9 ("drm/i915/guc: Add support for data
reporting in GuC responses") we missed the hypothetical case
that GuC might return positive non-zero value as success data.

While that would be lucky treated as error case, and at the
end will result in reporting valid -EIO, in the meantime this
value will be passed to ERR_PTR that could be misleading.

v2: rebased

Reported-by: Dan Carpenter 
Signed-off-by: Michal Wajdeczko 
Cc: Dan Carpenter 
---
 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index 43409044528e..a26bb55c0898 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -148,12 +148,15 @@ static int guc_action_register_ct_buffer(struct intel_guc 
*guc, u32 type,
FIELD_PREP(HOST2GUC_REGISTER_CTB_REQUEST_MSG_2_DESC_ADDR, 
desc_addr),
FIELD_PREP(HOST2GUC_REGISTER_CTB_REQUEST_MSG_3_BUFF_ADDR, 
buff_addr),
};
+   int ret;
 
GEM_BUG_ON(type != GUC_CTB_TYPE_HOST2GUC && type != 
GUC_CTB_TYPE_GUC2HOST);
GEM_BUG_ON(size % SZ_4K);
 
/* CT registration must go over MMIO */
-   return intel_guc_send_mmio(guc, request, ARRAY_SIZE(request), NULL, 0);
+   ret = intel_guc_send_mmio(guc, request, ARRAY_SIZE(request), NULL, 0);
+
+   return ret > 0 ? -EPROTO : ret;
 }
 
 static int ct_register_buffer(struct intel_guc_ct *ct, u32 type,
@@ -177,11 +180,14 @@ static int guc_action_deregister_ct_buffer(struct 
intel_guc *guc, u32 type)
FIELD_PREP(GUC_HXG_REQUEST_MSG_0_ACTION, 
GUC_ACTION_HOST2GUC_DEREGISTER_CTB),
FIELD_PREP(HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_1_TYPE, type),
};
+   int ret;
 
GEM_BUG_ON(type != GUC_CTB_TYPE_HOST2GUC && type != 
GUC_CTB_TYPE_GUC2HOST);
 
/* CT deregistration must go over MMIO */
-   return intel_guc_send_mmio(guc, request, ARRAY_SIZE(request), NULL, 0);
+   ret = intel_guc_send_mmio(guc, request, ARRAY_SIZE(request), NULL, 0);
+
+   return ret > 0 ? -EPROTO : ret;
 }
 
 static int ct_deregister_buffer(struct intel_guc_ct *ct, u32 type)
-- 
2.25.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 3/4] drm/i915/guc: Print error name on CTB send failure

[Michal Wajdeczko]

Instead of plain error value (%d) print more user friendly error
name (%pe).

Signed-off-by: Michal Wajdeczko 
---
 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index 18d52c39f0c2..8110586ce1fd 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -580,8 +580,8 @@ int intel_guc_ct_send(struct intel_guc_ct *ct, const u32 
*action, u32 len,
 
ret = ct_send(ct, action, len, response_buf, response_buf_size, 
&status);
if (unlikely(ret < 0)) {
-   CT_ERROR(ct, "Sending action %#x failed (err=%d status=%#X)\n",
-action[0], ret, status);
+   CT_ERROR(ct, "Sending action %#x failed (%pe) status=%#X\n",
+action[0], ERR_PTR(ret), status);
} else if (unlikely(ret)) {
CT_DEBUG(ct, "send action %#x returned %d (%#x)\n",
 action[0], ret, ret);
-- 
2.25.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 0/4] drm/i915/guc: Improve CTB error handling

[Michal Wajdeczko]

There was a gap in handling MMIO result from CTB (de)registration
and while fixing it improve some other error reports.

Signed-off-by: Michal Wajdeczko 

Michal Wajdeczko (4):
  drm/i915/guc: Verify result from CTB (de)register action
  drm/i915/guc: Print error name on CTB (de)registration failure
  drm/i915/guc: Print error name on CTB send failure
  drm/i915/guc: Move and improve error message for missed CTB reply

 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 30 ++-
 1 file changed, 18 insertions(+), 12 deletions(-)

-- 
2.25.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 4/4] drm/i915/guc: Move and improve error message for missed CTB reply

[Michal Wajdeczko]

If we timeout waiting for a CT reply we print very simple error
message. Improve that and by moving error reporting to the caller
we can use CT_ERROR instead of DRM_ERROR and report just fence
as error code will be reported later anyway.

Signed-off-by: Michal Wajdeczko 
---
 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index 8110586ce1fd..f488a51e1ebe 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -490,9 +490,6 @@ static int wait_for_ct_request_update(struct ct_request 
*req, u32 *status)
err = wait_for(done, 10);
 #undef done
 
-   if (unlikely(err))
-   DRM_ERROR("CT: fence %u err %d\n", req->fence, err);
-
*status = req->status;
return err;
 }
@@ -536,8 +533,11 @@ static int ct_send(struct intel_guc_ct *ct,
intel_guc_notify(ct_to_guc(ct));
 
err = wait_for_ct_request_update(&request, status);
-   if (unlikely(err))
+   if (unlikely(err)) {
+   CT_ERROR(ct, "No response for request %#x (fence %u)\n",
+action[0], request.fence);
goto unlink;
+   }
 
if (FIELD_GET(GUC_HXG_MSG_0_TYPE, *status) != 
GUC_HXG_TYPE_RESPONSE_SUCCESS) {
err = -EIO;
-- 
2.25.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/3] drm/i915: use consistent CPU mappings for pin_map users

[Patchwork]

== Series Details ==

Series: series starting with [v2,1/3] drm/i915: use consistent CPU mappings for 
pin_map users
URL   : https://patchwork.freedesktop.org/series/92114/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10297 -> Patchwork_20509


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20509/index.html

Known issues


  Here are the changes found in Patchwork_20509 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@cs-gfx:
- fi-kbl-soraka:  NOTRUN -> [SKIP][1] ([fdo#109271]) +3 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20509/fi-kbl-soraka/igt@amdgpu/amd_ba...@cs-gfx.html

  * igt@i915_pm_rpm@module-reload:
- fi-kbl-guc: [PASS][2] -> [FAIL][3] ([i915#2203])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10297/fi-kbl-guc/igt@i915_pm_...@module-reload.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20509/fi-kbl-guc/igt@i915_pm_...@module-reload.html

  * igt@kms_chamelium@dp-crc-fast:
- fi-kbl-7500u:   [PASS][4] -> [FAIL][5] ([i915#1372])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10297/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20509/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [i915#1372]: https://gitlab.freedesktop.org/drm/intel/issues/1372
  [i915#2203]: https://gitlab.freedesktop.org/drm/intel/issues/2203
  [i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
  [i915#3717]: https://gitlab.freedesktop.org/drm/intel/issues/3717


Participating hosts (37 -> 35)
--

  Missing(2): fi-bsw-cyan fi-bdw-samus 


Build changes
-

  * Linux: CI_DRM_10297 -> Patchwork_20509

  CI-20190529: 20190529
  CI_DRM_10297: 96c7ad60de68518bdcd0d0e6381a2359034a0226 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6125: 5bb62cb290fa32777934de4b39e107ccd282f7e8 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_20509: 11c689134982034df96812e0fd3c64a73845ff7b @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

11c689134982 drm/i915/uapi: reject set_domain for discrete
cf29b90656be drm/i915/uapi: reject caching ioctls for discrete
c99f7340de54 drm/i915: use consistent CPU mappings for pin_map users

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20509/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915/guc: Improve GuC CTB ABI

[Michal Wajdeczko]

Make CTB Header explicit and separate from CTB Message.

Signed-off-by: Michal Wajdeczko 
Cc: Matthew Brost 
---
 .../gt/uc/abi/guc_communication_ctb_abi.h | 51 +++
 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 24 -
 2 files changed, 43 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h 
b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
index e933ca02d0eb..90a86759e108 100644
--- a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
+++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
@@ -56,8 +56,9 @@ struct guc_ct_buffer_desc {
 } __packed;
 static_assert(sizeof(struct guc_ct_buffer_desc) == 64);
 
+
 /**
- * DOC: CTB Message
+ * DOC: CTB Header
  *
  *  
+---+---+--+
  *  |   | Bits  | Description  
|
@@ -71,21 +72,34 @@ static_assert(sizeof(struct guc_ct_buffer_desc) == 64);
  *  |   
+---+--+
  *  |   |   7:0 | **NUM_DWORDS** - length of the CTB message (w/o header)  
|
  *  
+---+---+--+
- *  | 1 |  31:0 | optional (depends on FORMAT) 
|
- *  +---+---+  
|
- *  |...|   |  
|
- *  +---+---+  
|
- *  | n |  31:0 |  
|
+ */
+
+#define GUC_CTB_HDR_LEN1u
+#define GUC_CTB_HDR_0_FENCE(0x << 16)
+#define GUC_CTB_HDR_0_FORMAT   (0xf << 12)
+#define   GUC_CTB_FORMAT_HXG   0u
+#define GUC_CTB_HDR_0_RESERVED (0xf << 8)
+#define GUC_CTB_HDR_0_NUM_DWORDS   (0xff << 0)
+#define   GUC_CTB_MAX_DWORDS   255u
+
+/**
+ * DOC: CTB Message
+ *
+ *  
+---+---+--+
+ *  |   | Bits  | Description  
|
+ *  
+===+===+==+
+ *  | 0 |  31:0 | `CTB Header`_
|
+ *  
+---+---+--+
+ *  | 1 |  31:0 |  ++  
|
+ *  +---+---+  ||  
|
+ *  |...|   |  |  optional payload (depends on FORMAT)  |  
|
+ *  +---+---+  ||  
|
+ *  | n |  31:0 |  ++  
|
  *  
+---+---+--+
  */
 
-#define GUC_CTB_MSG_MIN_LEN1u
-#define GUC_CTB_MSG_MAX_LEN256u
-#define GUC_CTB_MSG_0_FENCE(0x << 16)
-#define GUC_CTB_MSG_0_FORMAT   (0xf << 12)
-#define   GUC_CTB_FORMAT_HXG   0u
-#define GUC_CTB_MSG_0_RESERVED (0xf << 8)
-#define GUC_CTB_MSG_0_NUM_DWORDS   (0xff << 0)
+#define GUC_CTB_MSG_MIN_LENGUC_CTB_HDR_LEN
+#define GUC_CTB_MSG_MAX_LEN(GUC_CTB_HDR_LEN + GUC_CTB_MAX_DWORDS)
 
 /**
  * DOC: CTB HXG Message
@@ -93,13 +107,10 @@ static_assert(sizeof(struct guc_ct_buffer_desc) == 64);
  *  
+---+---+--+
  *  |   | Bits  | Description  
|
  *  
+===+===+==+
- *  | 0 | 31:16 | FENCE
|
- *  |   
+---+--+
- *  |   | 15:12 | FORMAT = GUC_CTB_FORMAT_HXG_ 
|
- *  |   
+---+--+
- *  |   |  11:8 | RESERVED = MBZ   
|
- *  |   
+---+--+
- *  |   |   7:0 | NUM_DWORDS = length (in dwords) of the embedded HXG message  
|
+ *  | 0 |  31:0 | `CTB Header`_ with:  
|
+ *  |   |   |  
|
+ *  |   |   |  - FORMAT = GUC_CTB_FORMAT_HXG_  
|
+ *  |   |   |  - NUM_DWORDS = **n**
|
  *  
+---+---+--+
  *  | 1 |  3

[Intel-gfx] [PATCH 2/7] drm/i915/guc: Improve error message for unsolicited CT response

[Matthew Brost]

Improve the error message when a unsolicited CT response is received by
printing fence that couldn't be found, the last fence, and all requests
with a response outstanding.

Signed-off-by: Matthew Brost 
Reviewed-by: Michal Wajdeczko 
---
 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index b86575b99537..80db59b45c45 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -732,12 +732,16 @@ static int ct_handle_response(struct intel_guc_ct *ct, 
struct ct_incoming_msg *r
found = true;
break;
}
-   spin_unlock_irqrestore(&ct->requests.lock, flags);
-
if (!found) {
CT_ERROR(ct, "Unsolicited response (fence %u)\n", fence);
-   return -ENOKEY;
+   CT_ERROR(ct, "Could not find fence=%u, last_fence=%u\n", fence,
+ct->requests.last_fence);
+   list_for_each_entry(req, &ct->requests.pending, link)
+   CT_ERROR(ct, "request %u awaits response\n",
+req->fence);
+   err = -ENOKEY;
}
+   spin_unlock_irqrestore(&ct->requests.lock, flags);
 
if (unlikely(err))
return err;
-- 
2.28.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/7] drm/i915/guc: Relax CTB response timeout

[Matthew Brost]

In upcoming patch we will allow more CTB requests to be sent in
parallel to the GuC for processing, so we shouldn't assume any more
that GuC will always reply without 10ms.

Use bigger value hardcoded value of 1s instead.

v2: Add CONFIG_DRM_I915_GUC_CTB_TIMEOUT config option
v3:
 (Daniel Vetter)
  - Use hardcoded value of 1s rather than config option
v4:
 (Michal)
  - Use defines for timeout values

Signed-off-by: Matthew Brost 
Cc: Michal Wajdeczko 
Reviewed-by: Michal Wajdeczko 
---
 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index 43409044528e..b86575b99537 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -474,14 +474,18 @@ static int wait_for_ct_request_update(struct ct_request 
*req, u32 *status)
/*
 * Fast commands should complete in less than 10us, so sample quickly
 * up to that length of time, then switch to a slower sleep-wait loop.
-* No GuC command should ever take longer than 10ms.
+* No GuC command should ever take longer than 10ms but many GuC
+* commands can be inflight at time, so use a 1s timeout on the slower
+* sleep-wait loop.
 */
+#define GUC_CTB_RESPONSE_TIMEOUT_SHORT_MS 10
+#define GUC_CTB_RESPONSE_TIMEOUT_LONG_MS 1000
 #define done \
(FIELD_GET(GUC_HXG_MSG_0_ORIGIN, READ_ONCE(req->status)) == \
 GUC_HXG_ORIGIN_GUC)
-   err = wait_for_us(done, 10);
+   err = wait_for_us(done, GUC_CTB_RESPONSE_TIMEOUT_SHORT_MS);
if (err)
-   err = wait_for(done, 10);
+   err = wait_for(done, GUC_CTB_RESPONSE_TIMEOUT_LONG_MS);
 #undef done
 
if (unlikely(err))
-- 
2.28.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 0/7] CT changes required for GuC submission

[Matthew Brost]

As part of enabling GuC submission discussed in [1], [2], and [3] we
need optimize and update the CT code as this is now in the critical
path of submission. This series includes the patches to do that which is
the first 7 patches from [3]. The patches should have addressed all the
feedback in [3] and should be ready to merge once CI returns a we get a
few more RBs.

v2: Fix checkpatch warning, address a couple of Michal's comments

Signed-off-by: Matthew Brost 

[1] https://patchwork.freedesktop.org/series/89844/
[2] https://patchwork.freedesktop.org/series/91417/
[3] https://patchwork.freedesktop.org/series/91840/

John Harrison (1):
  drm/i915/guc: Module load failure test for CT buffer creation

Matthew Brost (6):
  drm/i915/guc: Relax CTB response timeout
  drm/i915/guc: Improve error message for unsolicited CT response
  drm/i915/guc: Increase size of CTB buffers
  drm/i915/guc: Add non blocking CTB send function
  drm/i915/guc: Add stall timer to non blocking CTB send function
  drm/i915/guc: Optimize CTB writes and reads

 .../gt/uc/abi/guc_communication_ctb_abi.h |   3 +-
 drivers/gpu/drm/i915/gt/uc/intel_guc.h|  11 +-
 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 250 +++---
 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h |  14 +-
 4 files changed, 232 insertions(+), 46 deletions(-)

-- 
2.28.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 4/7] drm/i915/guc: Add non blocking CTB send function

[Matthew Brost]

Add non blocking CTB send function, intel_guc_send_nb. GuC submission
will send CTBs in the critical path and does not need to wait for these
CTBs to complete before moving on, hence the need for this new function.

The non-blocking CTB now must have a flow control mechanism to ensure
the buffer isn't overrun. A lazy spin wait is used as we believe the
flow control condition should be rare with a properly sized buffer.

The function, intel_guc_send_nb, is exported in this patch but unused.
Several patches later in the series make use of this function.

v2:
 (Michal)
  - Use define for H2G room calculations
  - Move INTEL_GUC_SEND_NB define
 (Daniel Vetter)
  - Use msleep_interruptible rather than cond_resched
v3:
 (Michal)
  - Move includes to following patch
  - s/INTEL_GUC_SEND_NB/INTEL_GUC_CT_SEND_NB/g

Signed-off-by: John Harrison 
Signed-off-by: Matthew Brost 
---
 .../gt/uc/abi/guc_communication_ctb_abi.h |  3 +-
 drivers/gpu/drm/i915/gt/uc/intel_guc.h| 11 ++-
 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 87 +--
 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h |  4 +-
 4 files changed, 91 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h 
b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
index e933ca02d0eb..99e1fad5ca20 100644
--- a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
+++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
@@ -79,7 +79,8 @@ static_assert(sizeof(struct guc_ct_buffer_desc) == 64);
  *  
+---+---+--+
  */
 
-#define GUC_CTB_MSG_MIN_LEN1u
+#define GUC_CTB_HDR_LEN1u
+#define GUC_CTB_MSG_MIN_LENGUC_CTB_HDR_LEN
 #define GUC_CTB_MSG_MAX_LEN256u
 #define GUC_CTB_MSG_0_FENCE(0x << 16)
 #define GUC_CTB_MSG_0_FORMAT   (0xf << 12)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h 
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index 4abc59f6f3cd..72e4653222e2 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -74,7 +74,14 @@ static inline struct intel_guc *log_to_guc(struct 
intel_guc_log *log)
 static
 inline int intel_guc_send(struct intel_guc *guc, const u32 *action, u32 len)
 {
-   return intel_guc_ct_send(&guc->ct, action, len, NULL, 0);
+   return intel_guc_ct_send(&guc->ct, action, len, NULL, 0, 0);
+}
+
+static
+inline int intel_guc_send_nb(struct intel_guc *guc, const u32 *action, u32 len)
+{
+   return intel_guc_ct_send(&guc->ct, action, len, NULL, 0,
+INTEL_GUC_CT_SEND_NB);
 }
 
 static inline int
@@ -82,7 +89,7 @@ intel_guc_send_and_receive(struct intel_guc *guc, const u32 
*action, u32 len,
   u32 *response_buf, u32 response_buf_size)
 {
return intel_guc_ct_send(&guc->ct, action, len,
-response_buf, response_buf_size);
+response_buf, response_buf_size, 0);
 }
 
 static inline void intel_guc_to_host_event_handler(struct intel_guc *guc)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index 43e03aa2dde8..fb825cc1d090 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -3,6 +3,8 @@
  * Copyright © 2016-2019 Intel Corporation
  */
 
+#include 
+
 #include "i915_drv.h"
 #include "intel_guc_ct.h"
 #include "gt/intel_gt.h"
@@ -373,7 +375,7 @@ static void write_barrier(struct intel_guc_ct *ct)
 static int ct_write(struct intel_guc_ct *ct,
const u32 *action,
u32 len /* in dwords */,
-   u32 fence)
+   u32 fence, u32 flags)
 {
struct intel_guc_ct_buffer *ctb = &ct->ctbs.send;
struct guc_ct_buffer_desc *desc = ctb->desc;
@@ -409,7 +411,7 @@ static int ct_write(struct intel_guc_ct *ct,
used = tail - head;
 
/* make sure there is a space including extra dw for the fence */
-   if (unlikely(used + len + 1 >= size))
+   if (unlikely(used + len + GUC_CTB_HDR_LEN >= size))
return -ENOSPC;
 
/*
@@ -421,9 +423,13 @@ static int ct_write(struct intel_guc_ct *ct,
 FIELD_PREP(GUC_CTB_MSG_0_NUM_DWORDS, len) |
 FIELD_PREP(GUC_CTB_MSG_0_FENCE, fence);
 
-   hxg = FIELD_PREP(GUC_HXG_MSG_0_TYPE, GUC_HXG_TYPE_REQUEST) |
- FIELD_PREP(GUC_HXG_REQUEST_MSG_0_ACTION |
-GUC_HXG_REQUEST_MSG_0_DATA0, action[0]);
+   hxg = (flags & INTEL_GUC_CT_SEND_NB) ?
+   (FIELD_PREP(GUC_HXG_MSG_0_TYPE, GUC_HXG_TYPE_EVENT) |
+FIELD_PREP(GUC_HXG_EVENT_MSG_0_ACTION |
+   GUC_HXG_EVENT_MSG_0_DATA0, action[0])) :
+   (FIELD_PREP(GUC_HXG_MSG_0_TYPE, GUC_HXG_TY

[Intel-gfx] [PATCH 3/7] drm/i915/guc: Increase size of CTB buffers

[Matthew Brost]

With the introduction of non-blocking CTBs more than one CTB can be in
flight at a time. Increasing the size of the CTBs should reduce how
often software hits the case where no space is available in the CTB
buffer.

Cc: John Harrison 
Signed-off-by: Matthew Brost 
Reviewed-by: Michal Wajdeczko 
---
 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index 80db59b45c45..43e03aa2dde8 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -58,11 +58,16 @@ static inline struct drm_device *ct_to_drm(struct 
intel_guc_ct *ct)
  *  ++---+--+
  *
  * Size of each `CT Buffer`_ must be multiple of 4K.
- * As we don't expect too many messages, for now use minimum sizes.
+ * We don't expect too many messages in flight at any time, unless we are
+ * using the GuC submission. In that case each request requires a minimum
+ * 2 dwords which gives us a maximum 256 queue'd requests. Hopefully this
+ * enough space to avoid backpressure on the driver. We increase the size
+ * of the receive buffer (relative to the send) to ensure a G2H response
+ * CTB has a landing spot.
  */
 #define CTB_DESC_SIZE  ALIGN(sizeof(struct guc_ct_buffer_desc), SZ_2K)
 #define CTB_H2G_BUFFER_SIZE(SZ_4K)
-#define CTB_G2H_BUFFER_SIZE(SZ_4K)
+#define CTB_G2H_BUFFER_SIZE(4 * CTB_H2G_BUFFER_SIZE)
 
 struct ct_request {
struct list_head link;
@@ -643,7 +648,7 @@ static int ct_read(struct intel_guc_ct *ct, struct 
ct_incoming_msg **msg)
/* beware of buffer wrap case */
if (unlikely(available < 0))
available += size;
-   CT_DEBUG(ct, "available %d (%u:%u)\n", available, head, tail);
+   CT_DEBUG(ct, "available %d (%u:%u:%u)\n", available, head, tail, size);
GEM_BUG_ON(available < 0);
 
header = cmds[head];
-- 
2.28.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 7/7] drm/i915/guc: Module load failure test for CT buffer creation

[Matthew Brost]

From: John Harrison 

Add several module failure load inject points in the CT buffer creation
code path.

Signed-off-by: John Harrison 
Signed-off-by: Matthew Brost 
Reviewed-by: Michal Wajdeczko 
---
 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 8 
 1 file changed, 8 insertions(+)

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 5b8b4ff609e2..d2a55521ef25 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -175,6 +175,10 @@ static int ct_register_buffer(struct intel_guc_ct *ct, u32 
type,
 {
int err;
 
+   err = i915_inject_probe_error(guc_to_gt(ct_to_guc(ct))->i915, -ENXIO);
+   if (unlikely(err))
+   return err;
+
err = guc_action_register_ct_buffer(ct_to_guc(ct), type,
desc_addr, buff_addr, size);
if (unlikely(err))
@@ -226,6 +230,10 @@ int intel_guc_ct_init(struct intel_guc_ct *ct)
u32 *cmds;
int err;
 
+   err = i915_inject_probe_error(guc_to_gt(guc)->i915, -ENXIO);
+   if (err)
+   return err;
+
GEM_BUG_ON(ct->vma);
 
blob_size = 2 * CTB_DESC_SIZE + CTB_H2G_BUFFER_SIZE + 
CTB_G2H_BUFFER_SIZE;
-- 
2.28.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 6/7] drm/i915/guc: Optimize CTB writes and reads

[Matthew Brost]

CTB writes are now in the path of command submission and should be
optimized for performance. Rather than reading CTB descriptor values
(e.g. head, tail) which could result in accesses across the PCIe bus,
store shadow local copies and only read/write the descriptor values when
absolutely necessary. Also store the current space in the each channel
locally.

v2:
 (Michel)
  - Add additional sanity checks for head / tail pointers
  - Use GUC_CTB_HDR_LEN rather than magic 1

Signed-off-by: John Harrison 
Signed-off-by: Matthew Brost 
---
 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 88 +++
 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h |  6 ++
 2 files changed, 65 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index a9cb7b608520..5b8b4ff609e2 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -130,6 +130,10 @@ static void guc_ct_buffer_desc_init(struct 
guc_ct_buffer_desc *desc)
 static void guc_ct_buffer_reset(struct intel_guc_ct_buffer *ctb)
 {
ctb->broken = false;
+   ctb->tail = 0;
+   ctb->head = 0;
+   ctb->space = CIRC_SPACE(ctb->tail, ctb->head, ctb->size);
+
guc_ct_buffer_desc_init(ctb->desc);
 }
 
@@ -383,10 +387,8 @@ static int ct_write(struct intel_guc_ct *ct,
 {
struct intel_guc_ct_buffer *ctb = &ct->ctbs.send;
struct guc_ct_buffer_desc *desc = ctb->desc;
-   u32 head = desc->head;
-   u32 tail = desc->tail;
+   u32 tail = ctb->tail;
u32 size = ctb->size;
-   u32 used;
u32 header;
u32 hxg;
u32 *cmds = ctb->cmds;
@@ -395,25 +397,22 @@ static int ct_write(struct intel_guc_ct *ct,
if (unlikely(desc->status))
goto corrupted;
 
-   if (unlikely((tail | head) >= size)) {
+   GEM_BUG_ON(tail > size);
+
+#ifdef CONFIG_DRM_I915_DEBUG_GUC
+   if (unlikely(tail != READ_ONCE(desc->tail))) {
+   CT_ERROR(ct, "Tail was modified %u != %u\n",
+desc->tail, ctb->tail);
+   desc->status |= GUC_CTB_STATUS_MISMATCH;
+   goto corrupted;
+   }
+   if (unlikely((desc->tail | desc->head) >= size)) {
CT_ERROR(ct, "Invalid offsets head=%u tail=%u (size=%u)\n",
-head, tail, size);
+desc->head, desc->tail, size);
desc->status |= GUC_CTB_STATUS_OVERFLOW;
goto corrupted;
}
-
-   /*
-* tail == head condition indicates empty. GuC FW does not support
-* using up the entire buffer to get tail == head meaning full.
-*/
-   if (tail < head)
-   used = (size - head) + tail;
-   else
-   used = tail - head;
-
-   /* make sure there is a space including extra dw for the fence */
-   if (unlikely(used + len + GUC_CTB_HDR_LEN >= size))
-   return -ENOSPC;
+#endif
 
/*
 * dw0: CT header (including fence)
@@ -454,7 +453,9 @@ static int ct_write(struct intel_guc_ct *ct,
write_barrier(ct);
 
/* now update descriptor */
+   ctb->tail = tail;
WRITE_ONCE(desc->tail, tail);
+   ctb->space -= len + GUC_CTB_HDR_LEN;
 
return 0;
 
@@ -470,7 +471,7 @@ static int ct_write(struct intel_guc_ct *ct,
  * @req:   pointer to pending request
  * @status:placeholder for status
  *
- * For each sent request, Guc shall send bac CT response message.
+ * For each sent request, GuC shall send back CT response message.
  * Our message handler will update status of tracked request once
  * response message with given fence is received. Wait here and
  * check for valid response status value.
@@ -526,24 +527,35 @@ static inline bool ct_deadlocked(struct intel_guc_ct *ct)
return ret;
 }
 
-static inline bool h2g_has_room(struct intel_guc_ct_buffer *ctb, u32 len_dw)
+static inline bool h2g_has_room(struct intel_guc_ct *ct, u32 len_dw)
 {
-   struct guc_ct_buffer_desc *desc = ctb->desc;
-   u32 head = READ_ONCE(desc->head);
+   struct intel_guc_ct_buffer *ctb = &ct->ctbs.send;
+   u32 head;
u32 space;
 
-   space = CIRC_SPACE(desc->tail, head, ctb->size);
+   if (ctb->space >= len_dw)
+   return true;
+
+   head = READ_ONCE(ctb->desc->head);
+   if (unlikely(head > ctb->size)) {
+   CT_ERROR(ct, "Corrupted descriptor head=%u tail=%u size=%u\n",
+ctb->desc->head, ctb->desc->tail, ctb->size);
+   ctb->desc->status |= GUC_CTB_STATUS_OVERFLOW;
+   ctb->broken = true;
+   return false;
+   }
+
+   space = CIRC_SPACE(ctb->tail, head, ctb->size);
+   ctb->space = space;
 
return space >= len_dw;
 }
 
 static int has_room_nb(struct intel_guc_ct *ct, u32 len_dw)
 {
-   struct intel_guc_ct_buffer *ctb = &ct->ctbs.send;
-
lockdep_a

[Intel-gfx] [PATCH 5/7] drm/i915/guc: Add stall timer to non blocking CTB send function

[Matthew Brost]

Implement a stall timer which fails H2G CTBs once a period of time
with no forward progress is reached to prevent deadlock.

v2:
 (Michal)
  - Improve error message in ct_deadlock()
  - Set broken when ct_deadlock() returns true
  - Return -EPIPE on ct_deadlock()
v3:
 (Michal)
  - Add ms to stall timer comment
 (Matthew)
  - Move broken check to intel_guc_ct_send()

Signed-off-by: John Harrison 
Signed-off-by: Daniele Ceraolo Spurio 
Signed-off-by: Matthew Brost 
---
 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 62 ---
 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h |  4 ++
 2 files changed, 59 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index fb825cc1d090..a9cb7b608520 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -4,6 +4,9 @@
  */
 
 #include 
+#include 
+#include 
+#include 
 
 #include "i915_drv.h"
 #include "intel_guc_ct.h"
@@ -316,6 +319,7 @@ int intel_guc_ct_enable(struct intel_guc_ct *ct)
goto err_deregister;
 
ct->enabled = true;
+   ct->stall_time = KTIME_MAX;
 
return 0;
 
@@ -388,9 +392,6 @@ static int ct_write(struct intel_guc_ct *ct,
u32 *cmds = ctb->cmds;
unsigned int i;
 
-   if (unlikely(ctb->broken))
-   return -EPIPE;
-
if (unlikely(desc->status))
goto corrupted;
 
@@ -506,6 +507,25 @@ static int wait_for_ct_request_update(struct ct_request 
*req, u32 *status)
return err;
 }
 
+#define GUC_CTB_TIMEOUT_MS 1500
+static inline bool ct_deadlocked(struct intel_guc_ct *ct)
+{
+   long timeout = GUC_CTB_TIMEOUT_MS;
+   bool ret = ktime_ms_delta(ktime_get(), ct->stall_time) > timeout;
+
+   if (unlikely(ret)) {
+   struct guc_ct_buffer_desc *send = ct->ctbs.send.desc;
+   struct guc_ct_buffer_desc *recv = ct->ctbs.send.desc;
+
+   CT_ERROR(ct, "Communication stalled for %lld ms, desc 
status=%#x,%#x\n",
+ktime_ms_delta(ktime_get(), ct->stall_time),
+send->status, recv->status);
+   ct->ctbs.send.broken = true;
+   }
+
+   return ret;
+}
+
 static inline bool h2g_has_room(struct intel_guc_ct_buffer *ctb, u32 len_dw)
 {
struct guc_ct_buffer_desc *desc = ctb->desc;
@@ -517,6 +537,26 @@ static inline bool h2g_has_room(struct intel_guc_ct_buffer 
*ctb, u32 len_dw)
return space >= len_dw;
 }
 
+static int has_room_nb(struct intel_guc_ct *ct, u32 len_dw)
+{
+   struct intel_guc_ct_buffer *ctb = &ct->ctbs.send;
+
+   lockdep_assert_held(&ct->ctbs.send.lock);
+
+   if (unlikely(!h2g_has_room(ctb, len_dw))) {
+   if (ct->stall_time == KTIME_MAX)
+   ct->stall_time = ktime_get();
+
+   if (unlikely(ct_deadlocked(ct)))
+   return -EPIPE;
+   else
+   return -EBUSY;
+   }
+
+   ct->stall_time = KTIME_MAX;
+   return 0;
+}
+
 static int ct_send_nb(struct intel_guc_ct *ct,
  const u32 *action,
  u32 len,
@@ -529,11 +569,9 @@ static int ct_send_nb(struct intel_guc_ct *ct,
 
spin_lock_irqsave(&ctb->lock, spin_flags);
 
-   ret = h2g_has_room(ctb, len + GUC_CTB_HDR_LEN);
-   if (unlikely(!ret)) {
-   ret = -EBUSY;
+   ret = has_room_nb(ct, len + GUC_CTB_HDR_LEN);
+   if (unlikely(ret))
goto out;
-   }
 
fence = ct_get_next_fence(ct);
ret = ct_write(ct, action, len, fence, flags);
@@ -576,8 +614,13 @@ static int ct_send(struct intel_guc_ct *ct,
 retry:
spin_lock_irqsave(&ctb->lock, flags);
if (unlikely(!h2g_has_room(ctb, len + GUC_CTB_HDR_LEN))) {
+   if (ct->stall_time == KTIME_MAX)
+   ct->stall_time = ktime_get();
spin_unlock_irqrestore(&ctb->lock, flags);
 
+   if (unlikely(ct_deadlocked(ct)))
+   return -EPIPE;
+
if (msleep_interruptible(sleep_period_ms))
return -EINTR;
sleep_period_ms = sleep_period_ms << 1;
@@ -585,6 +628,8 @@ static int ct_send(struct intel_guc_ct *ct,
goto retry;
}
 
+   ct->stall_time = KTIME_MAX;
+
fence = ct_get_next_fence(ct);
request.fence = fence;
request.status = 0;
@@ -647,6 +692,9 @@ int intel_guc_ct_send(struct intel_guc_ct *ct, const u32 
*action, u32 len,
return -ENODEV;
}
 
+   if (unlikely(ct->ctbs.send.broken))
+   return -EPIPE;
+
if (flags & INTEL_GUC_CT_SEND_NB)
return ct_send_nb(ct, action, len, flags);
 
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
index 5bb8bef024c8..bee03794c1eb 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h

Re: [Intel-gfx] [PATCH] drm/i915/gt: Fix -EDEADLK handling regression

[Ville Syrjälä]

On Thu, Jul 01, 2021 at 09:07:27AM +0200, Maarten Lankhorst wrote:
> Op 30-06-2021 om 18:44 schreef Ville Syrjala:
> > From: Ville Syrjälä 
> >
> > The conversion to ww mutexes failed to address the fence code which
> > already returns -EDEADLK when we run out of fences. Ww mutexes on
> > the other hand treat -EDEADLK as an internal errno value indicating
> > a need to restart the operation due to a deadlock. So now when the
> > fence code returns -EDEADLK the higher level code erroneously
> > restarts everything instead of returning the error to userspace
> > as is expected.
> >
> > To remedy this let's switch the fence code to use a different errno
> > value for this. -ENOBUFS seems like a semi-reasonable unique choice.
> > Apart from igt the only user of this I could find is sna, and even
> > there all we do is dump the current fence registers from debugfs
> > into the X server log. So no user visible functionality is affected.
> > If we really cared about preserving this we could of course convert
> > back to -EDEADLK higher up, but doesn't seem like that's worth
> > the hassle here.
> >
> > Not quite sure which commit specifically broke this, but I'll
> > just attribute it to the general gem ww mutex work.
> >
> > Cc: sta...@vger.kernel.org
> > Cc: Maarten Lankhorst 
> > Cc: Thomas Hellström 
> > Testcase: igt/gem_pread/exhaustion
> > Testcase: igt/gem_pwrite/basic-exhaustion
> > Testcase: igt/gem_fenced_exec_thrash/too-many-fences
> > Fixes: 80f0b679d6f0 ("drm/i915: Add an implementation for i915_gem_ww_ctx 
> > locking, v2.")
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c 
> > b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
> > index cac7f3f44642..f8948de72036 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
> > @@ -348,7 +348,7 @@ static struct i915_fence_reg *fence_find(struct 
> > i915_ggtt *ggtt)
> > if (intel_has_pending_fb_unpin(ggtt->vm.i915))
> > return ERR_PTR(-EAGAIN);
> >  
> > -   return ERR_PTR(-EDEADLK);
> > +   return ERR_PTR(-ENOBUFS);
> >  }
> >  
> >  int __i915_vma_pin_fence(struct i915_vma *vma)
> 
> Makes sense..
> 
> Reviewed-by: Maarten Lankhorst 
> 
> Is it a slightly more reent commit? Might probably be the part that converts 
> execbuffer to use ww locks.

No idea about the specific commit since I've not actually bisected it.
It's just been bugging CI for quite a while now so figured I need to
fix it.

-- 
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/display: check if compressed_llb was allocated

[Souza, Jose]

On Thu, 2021-07-01 at 10:03 +0100, Matthew Auld wrote:
> If we hit the error path here we unconditionally call
> i915_gem_stolen_remove_node, even though we only allocate the
> compressed_llb on older platforms. Therefore we should first check that
> we actually allocated the node before trying to remove it.

Reviewed-by: José Roberto de Souza 

> 
> References: https://gitlab.freedesktop.org/drm/intel/-/issues/3709
> Fixes: 46b2c40e0af3 ("drm/i915/fbc: Allocate llb before cfb")
> Signed-off-by: Matthew Auld 
> Cc: Ville Syrjälä 
> Cc: José Roberto de Souza 
> ---
>  drivers/gpu/drm/i915/display/intel_fbc.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c 
> b/drivers/gpu/drm/i915/display/intel_fbc.c
> index 7dc72e4a4656..82effb64a3b9 100644
> --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
> @@ -516,7 +516,8 @@ static int intel_fbc_alloc_cfb(struct drm_i915_private 
> *dev_priv,
>   return 0;
>  
>  err_llb:
> - i915_gem_stolen_remove_node(dev_priv, &fbc->compressed_llb);
> + if (drm_mm_node_allocated(&fbc->compressed_llb))
> + i915_gem_stolen_remove_node(dev_priv, &fbc->compressed_llb);
>  err:
>   if (drm_mm_initialized(&dev_priv->mm.stolen))
>   drm_info_once(&dev_priv->drm, "not enough stolen space for 
> compressed buffer (need %d more bytes), disabling. Hint: you may be able to 
> increase stolen memory size in the BIOS to avoid this.\n", size);

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/display/dg1: Correctly map DPLLs during state readout

[Souza, Jose]

On Thu, 2021-07-01 at 05:21 +, Patchwork wrote:
Patch Details
Series: drm/i915/display/dg1: Correctly map DPLLs during state readout
URL:https://patchwork.freedesktop.org/series/92086/
State:  failure
Details:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20499/index.html
CI Bug Log - changes from CI_DRM_10295_full -> Patchwork_20499_full
Summary

FAILURE

Serious unknown changes coming with Patchwork_20499_full absolutely need to be
verified manually.

If you think the reported changes have nothing to do with the changes
introduced in Patchwork_20499_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.

Possible new issues

Here are the unknown changes that may have been introduced in 
Patchwork_20499_full:

IGT changes
Possible regressions

  *   igt@kms_big_fb@yf-tiled-max-hw-stride-32bpp-rotate-180-async-flip:
 *   shard-skl: NOTRUN -> 
FAIL

Not related.
Patch pushed, thanks for the review Lucas.

Suppressed

The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.

  *   igt@i915_pm_dc@dc6-psr:

 *   {shard-rkl}: 
FAIL
 ([i915#2951]) -> 
SKIP
  *   igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-180-hflip-async-flip:

 *   {shard-rkl}: 
PASS
 -> 
SKIP
 +66 similar issues
  *   igt@kms_ccs@pipe-a-crc-primary-rotation-180-y_tiled_ccs:

 *   {shard-rkl}: NOTRUN -> 
FAIL
 +7 similar issues
  *   igt@kms_ccs@pipe-a-missing-ccs-buffer-y_tiled_ccs:

 *   {shard-rkl}: 
FAIL
 -> 
SKIP
 +9 similar issues
  *   igt@kms_ccs@pipe-b-ccs-on-another-bo-y_tiled_gen12_rc_ccs_cc:

 *   {shard-rkl}: 
PASS
 -> 
FAIL
 +6 similar issues
  *   igt@kms_ccs@pipe-c-bad-rotation-90-yf_tiled_ccs:

 *   {shard-rkl}: 
SKIP
 -> 
FAIL
 +9 similar issues
  *   igt@kms_ccs@pipe-d-crc-primary-basic-y_tiled_gen12_rc_ccs:

 *   {shard-rkl}: 
SKIP
 ([i915#533]) -> 
FAIL
 +4 similar issues
  *   igt@kms_content_protection@atomic:

 *   {shard-rkl}: 
SKIP
 ([fdo#109300]) -> 
SKIP
  *   igt@kms_cursor_crc@pipe-a-cursor-64x64-rapid-movement:

 *   {shard-rkl}: 
SKIP
 ([fdo#112022]) -> 
SKIP
 +5 similar issues
  *   igt@kms_cursor_crc@pipe-b-cursor-max-size-onscreen:

 *   {shard-rkl}: 
SKIP
 ([i915#3359]) -> 
SKIP
 +4 similar issues
  *   igt@kms_cursor_crc@pipe-c-cursor-32x32-offscreen:

 *   {shard-rkl}: 
SKIP

[Intel-gfx] [PATCH v5 0/2] drm/i915: IRQ fixes

[Thomas Zimmermann]

Fix a bug in the usage of IRQs and cleanup references to the DRM
IRQ midlayer.

Preferably this patchset would be merged through drm-misc-next.

v5:
* go back to _hardirq() after CI tests reported atomic
  context in PCI probe; add rsp comment
v4:
* switch IRQ code to intel_synchronize_irq() (Daniel)
v3:
* also use intel_synchronize_hardirq() from other callsite
v2:
* split patch
* also fix comment
* add intel_synchronize_hardirq() (Ville)
* update Fixes tag (Daniel)

Thomas Zimmermann (2):
  drm/i915: Use the correct IRQ during resume
  drm/i915: Drop all references to DRM IRQ midlayer

 drivers/gpu/drm/i915/gt/intel_engine_cs.c   |  2 +-
 drivers/gpu/drm/i915/gt/intel_ring_submission.c |  7 +--
 drivers/gpu/drm/i915/i915_drv.c |  1 -
 drivers/gpu/drm/i915/i915_irq.c | 10 +-
 drivers/gpu/drm/i915/i915_irq.h |  1 +
 5 files changed, 12 insertions(+), 9 deletions(-)


base-commit: 67f5a18128770817e4218a9e496d2bf5047c51e8
prerequisite-patch-id: c2b2f08f0eccc9f5df0c0da49fa1d36267deb11d
prerequisite-patch-id: c67e5d886a47b7d0266d81100837557fda34cb24
prerequisite-patch-id: 0cca17365e65370fa95d193ed2f1c88917ee1aef
prerequisite-patch-id: 12b9894350a0b56579d29542943465ef5134751c
prerequisite-patch-id: 3e1c37d3425f4820fe36ea3da57c65e166fe0ee5
prerequisite-patch-id: 1017c860a0bf95ce370d82b8db1745f5548fb321
prerequisite-patch-id: dcc022baab7c172978de9809702c2f4f54323047
prerequisite-patch-id: 0d05ee247042b43d5ab8f3af216e708a8e09bee8
prerequisite-patch-id: 110c411161bed6072c32185940fcd052d0bdb09a
prerequisite-patch-id: d2d1aeccffdfadf2b951487b8605f59c795d84cf
prerequisite-patch-id: 85fe31e27ca13adc0d1bcc7c19b1ce238a77ee6a
prerequisite-patch-id: c61fdacbe035ba5c17f1ff393bc9087f16aaea7b
prerequisite-patch-id: c4821af5dbba4d121769f1da85d91fbb53020ec0
prerequisite-patch-id: 0b20ef3302abfe6dc123dbc54b9dd087865f935b
prerequisite-patch-id: d34eb96cbbdeb91870ace4250ea75920b1653dc2
prerequisite-patch-id: 7f64fce347d15232134d7636ca7a8d9f5bf1a3a0
prerequisite-patch-id: c83be7a285eb6682cdae0df401ab5d4c208f036b
prerequisite-patch-id: eb1a44d2eb2685cea154dd3f17f5f463dfafd39a
prerequisite-patch-id: 92a8c37dae4b8394fd6702f4af58ac7815ac3069
prerequisite-patch-id: f0237988fe4ae6eba143432d1ace8beb52d935f8
prerequisite-patch-id: bcf4d29437ed7cb78225dec4c99249eb40c18302
prerequisite-patch-id: 6407b4c7f1b80af8d329d5f796b30da11959e936
prerequisite-patch-id: 4a69e6e49d691b555f0e0874d638cd204dcb0c48
prerequisite-patch-id: be09cfa8a67dd435a25103b85bd4b1649c5190a3
prerequisite-patch-id: 813ecc9f94251c3d669155faf64c0c9e6a458393
prerequisite-patch-id: beb2b5000a1682cbd74a7e2ab1566fcae5bccbf0
prerequisite-patch-id: 754c8878611864475a0b75fd49ff38e71a21c795
prerequisite-patch-id: d7d4bac3c19f94ba9593143b3c147d83d82cb71f
prerequisite-patch-id: 983d1efbe060743f5951e474961fa431d886d757
prerequisite-patch-id: 3c78b20c3b9315cd39e0ae9ea1510c6121bf9ca9
--
2.32.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v5 1/2] drm/i915: Use the correct IRQ during resume

[Thomas Zimmermann]

The code in xcs_resume() probably didn't work as intended. It uses
struct drm_device.irq, which is allocated to 0, but never initialized
by i915 to the device's interrupt number.

Change all calls to synchronize_hardirq() to intel_synchronize_irq(),
which uses the correct interrupt. _hardirq() functions are not needed
in this context.

v5:
* go back to _hardirq() after PCI probe reported wrong
  context; add rsp comment
v4:
* switch everything to intel_synchronize_irq() (Daniel)
v3:
* also use intel_synchronize_hardirq() at another callsite
v2:
* wrap irq code in intel_synchronize_hardirq() (Ville)

Signed-off-by: Thomas Zimmermann 
Fixes: 536f77b1caa0 ("drm/i915/gt: Call stop_ring() from ring resume, again")
Cc: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Daniel Vetter 
Cc: Rodrigo Vivi 
Cc: Joonas Lahtinen 
Cc: Maarten Lankhorst 
Cc: Lucas De Marchi 
---
 drivers/gpu/drm/i915/gt/intel_engine_cs.c   | 2 +-
 drivers/gpu/drm/i915/gt/intel_ring_submission.c | 7 +--
 drivers/gpu/drm/i915/i915_irq.c | 5 +
 drivers/gpu/drm/i915/i915_irq.h | 1 +
 4 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 88694822716a..5ca3d1664335 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1229,7 +1229,7 @@ bool intel_engine_is_idle(struct intel_engine_cs *engine)
return true;
 
/* Waiting to drain ELSP? */
-   synchronize_hardirq(to_pci_dev(engine->i915->drm.dev)->irq);
+   intel_synchronize_hardirq(engine->i915);
intel_engine_flush_submission(engine);
 
/* ELSP is empty, but there are ready requests? E.g. after reset */
diff --git a/drivers/gpu/drm/i915/gt/intel_ring_submission.c 
b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
index 5d42a12ef3d6..5c4d204d07cc 100644
--- a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
@@ -184,8 +184,11 @@ static int xcs_resume(struct intel_engine_cs *engine)
ENGINE_TRACE(engine, "ring:{HEAD:%04x, TAIL:%04x}\n",
 ring->head, ring->tail);
 
-   /* Double check the ring is empty & disabled before we resume */
-   synchronize_hardirq(engine->i915->drm.irq);
+   /*
+* Double check the ring is empty & disabled before we resume. Called
+* from atomic context during PCI probe, so _hardirq().
+*/
+   intel_synchronize_hardirq(engine->i915);
if (!stop_ring(engine))
goto err;
 
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 7d0ce8b9f8ed..2203dca19895 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -4575,3 +4575,8 @@ void intel_synchronize_irq(struct drm_i915_private *i915)
 {
synchronize_irq(to_pci_dev(i915->drm.dev)->irq);
 }
+
+void intel_synchronize_hardirq(struct drm_i915_private *i915)
+{
+   synchronize_hardirq(to_pci_dev(i915->drm.dev)->irq);
+}
diff --git a/drivers/gpu/drm/i915/i915_irq.h b/drivers/gpu/drm/i915/i915_irq.h
index db34d5dbe402..e43b6734f21b 100644
--- a/drivers/gpu/drm/i915/i915_irq.h
+++ b/drivers/gpu/drm/i915/i915_irq.h
@@ -94,6 +94,7 @@ void intel_runtime_pm_disable_interrupts(struct 
drm_i915_private *dev_priv);
 void intel_runtime_pm_enable_interrupts(struct drm_i915_private *dev_priv);
 bool intel_irqs_enabled(struct drm_i915_private *dev_priv);
 void intel_synchronize_irq(struct drm_i915_private *i915);
+void intel_synchronize_hardirq(struct drm_i915_private *i915);
 
 int intel_get_crtc_scanline(struct intel_crtc *crtc);
 void gen8_irq_power_well_post_enable(struct drm_i915_private *dev_priv,
-- 
2.32.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v5 2/2] drm/i915: Drop all references to DRM IRQ midlayer

[Thomas Zimmermann]

Remove all references to DRM's IRQ midlayer. i915 uses Linux' interrupt
functions directly.

v2:
* also remove an outdated comment
* move IRQ fix into separate patch
* update Fixes tag (Daniel)

Signed-off-by: Thomas Zimmermann 
Fixes: b318b82455bd ("drm/i915: Nuke drm_driver irq vfuncs")
Cc: Ville Syrjälä 
Cc: Chris Wilson 
Cc: Jani Nikula 
Cc: Joonas Lahtinen 
Cc: Rodrigo Vivi 
Cc: intel-gfx@lists.freedesktop.org
---
 drivers/gpu/drm/i915/i915_drv.c | 1 -
 drivers/gpu/drm/i915/i915_irq.c | 5 -
 2 files changed, 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 62327c15f457..30d8cd8c69b1 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -42,7 +42,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 2203dca19895..1d4c683c9de9 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -33,7 +33,6 @@
 #include 
 
 #include 
-#include 
 
 #include "display/intel_de.h"
 #include "display/intel_display_types.h"
@@ -4564,10 +4563,6 @@ void intel_runtime_pm_enable_interrupts(struct 
drm_i915_private *dev_priv)
 
 bool intel_irqs_enabled(struct drm_i915_private *dev_priv)
 {
-   /*
-* We only use drm_irq_uninstall() at unload and VT switch, so
-* this is the only thing we need to check.
-*/
return dev_priv->runtime_pm.irqs_enabled;
 }
 
-- 
2.32.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/display: check if compressed_llb was allocated

[Ville Syrjälä]

On Thu, Jul 01, 2021 at 10:03:26AM +0100, Matthew Auld wrote:
> If we hit the error path here we unconditionally call
> i915_gem_stolen_remove_node, even though we only allocate the
> compressed_llb on older platforms. Therefore we should first check that
> we actually allocated the node before trying to remove it.
> 
> References: https://gitlab.freedesktop.org/drm/intel/-/issues/3709

Doh! Seems pre-merge testing didn't hit this, or I just suck at reading
the logs :(

Reviewed-by: Ville Syrjälä 

> Fixes: 46b2c40e0af3 ("drm/i915/fbc: Allocate llb before cfb")
> Signed-off-by: Matthew Auld 
> Cc: Ville Syrjälä 
> Cc: José Roberto de Souza 
> ---
>  drivers/gpu/drm/i915/display/intel_fbc.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c 
> b/drivers/gpu/drm/i915/display/intel_fbc.c
> index 7dc72e4a4656..82effb64a3b9 100644
> --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
> @@ -516,7 +516,8 @@ static int intel_fbc_alloc_cfb(struct drm_i915_private 
> *dev_priv,
>   return 0;
>  
>  err_llb:
> - i915_gem_stolen_remove_node(dev_priv, &fbc->compressed_llb);
> + if (drm_mm_node_allocated(&fbc->compressed_llb))
> + i915_gem_stolen_remove_node(dev_priv, &fbc->compressed_llb);
>  err:
>   if (drm_mm_initialized(&dev_priv->mm.stolen))
>   drm_info_once(&dev_priv->drm, "not enough stolen space for 
> compressed buffer (need %d more bytes), disabling. Hint: you may be able to 
> increase stolen memory size in the BIOS to avoid this.\n", size);
> -- 
> 2.26.3

-- 
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/dmc: Use RUNTIME_INFO->stp for DMC

[Lucas De Marchi]

On Wed, Jun 30, 2021 at 05:17:52PM -0700, Lucas De Marchi wrote:

On Wed, Jun 30, 2021 at 05:15:00PM -0700, Jose Souza wrote:

On Wed, 2021-06-30 at 17:01 -0700, Lucas De Marchi wrote:

Typo: RUNTIME_INFO->stp

On Wed, Jun 30, 2021 at 04:06:24PM -0700, Anusha Srivatsa wrote:

On the dmc side,we maintain a lookup table with different display
stepping-substepping combinations.

Instead of adding new table for every new platform, lets ues
the stepping info from RUNTIME_INFO(dev_priv)->step
Adding the helper intel_get_display_step().

Cc: Lucas De Marchi 
Signed-off-by: Anusha Srivatsa 
---
drivers/gpu/drm/i915/display/intel_dmc.c | 49 ++--
1 file changed, 45 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c 
b/drivers/gpu/drm/i915/display/intel_dmc.c
index f8789d4543bf..c7ff7ff3f412 100644
--- a/drivers/gpu/drm/i915/display/intel_dmc.c
+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
@@ -266,14 +266,55 @@ static const struct stepping_info icl_stepping_info[] = {
};

static const struct stepping_info no_stepping_info = { '*', '*' };
+struct stepping_info *display_step;
+
+static struct stepping_info *
+intel_get_display_stepping(struct intel_step_info step)
+{
+
+   switch (step.display_step) {
+   case STEP_A0:
+   display_step->stepping = 'A';
+   display_step->substepping = '0';
+   break;
+   case STEP_A2:
+   display_step->stepping = 'A';
+   display_step->substepping = '2';
+   break;
+   case STEP_B0:
+   display_step->stepping = 'B';
+   display_step->substepping = '0';
+   break;
+   case STEP_B1:
+   display_step->stepping = 'B';
+   display_step->substepping = '1';
+   break;
+   case STEP_C0:
+   display_step->stepping = 'C';
+   display_step->substepping = '0';
+   break;
+   case STEP_D0:
+   display_step->stepping = 'D';
+   display_step->substepping = '0';
+   break;
+   default:
+   display_step->stepping = '*';
+   display_step->substepping = '*';
+   break;
+   }



"crazy" idea that would avoid this type of conversion:
changing the step enum to be:


#define make_step(letter, num) (int)(((letter) << 8 ) | (num))

STEP_A0 = make_step('A', '0'),
STEP_A1 = make_step('A', '1'),


Looks a good idea to me, we could also keep it u8 using 4bits for each if there 
is memory concerns.


humn... indeed. Not much a concern actually, but not having to change
additional code is already a good thing.


I hope no stepping goes beyond Z9 :)


I take that out. Even if we would do (number - 'A'), there is not enough
room in 4bits to handle until Z. In fact we could go only until P8 - so
if we are going that route we will need to have some extra build checks
that we don't go beyond that.

Lucas De Marchi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v7 0/5] drm: address potential UAF bugs with drm_master ptrs

[Desmond Cheong Zhi Xi]

This patch series addresses potential use-after-free errors when dereferencing 
pointers to struct drm_master. These were identified after one such bug was 
caught by Syzbot in drm_getunique():
https://syzkaller.appspot.com/bug?id=148d2f1dfac64af52ffd27b661981a540724f803

The series is broken up into five patches:

1. Move a call to drm_is_current_master() out from a section locked by 
&dev->mode_config.mutex in drm_mode_getconnector(). This patch does not apply 
to stable.

2. Move a call to _drm_lease_held() out from the section locked by 
&dev->mode_config.idr_mutex in __drm_mode_object_find().

3. Implement a locked version of drm_is_current_master() function that's used 
within drm_auth.c.

4. Serialize drm_file.master by introducing a new lock that's held whenever the 
value of drm_file.master changes.

5. Identify areas in drm_lease.c where pointers to struct drm_master are 
dereferenced, and ensure that the master pointers are not freed during use.

Changes in v6 -> v7:
- Patch 2:
Modify code alignment as suggested by the intel-gfx CI.

Update commit message based on the changes to patch 5.

- Patch 4:
Add patch 4 to the series. This patch adds a new lock to serialize 
drm_file.master, in response to the lockdep splat by the intel-gfx CI.

- Patch 5:
Move kerneldoc comment about protecting drm_file.master with 
drm_device.master_mutex into patch 4.

Update drm_file_get_master to use the new drm_file.master_lock instead of 
drm_device.master_mutex, in response to the lockdep splat by the intel-gfx CI.

Changes in v5 -> v6:
- Patch 2:
Add patch 2 to the series. This patch moves the call to _drm_lease_held out 
from the section locked by &dev->mode_config.idr_mutex in 
__drm_mode_object_find.

- Patch 5:
Clarify the kerneldoc for dereferencing drm_file.master, as suggested by Daniel 
Vetter.

Refactor error paths with goto labels so that each function only has a single 
drm_master_put(), as suggested by Emil Velikov.

Modify comparison to NULL into "!master", as suggested by the intel-gfx CI.

Changes in v4 -> v5:
- Patch 1:
Add patch 1 to the series. The changes in patch 1 do not apply to stable 
because they apply to new changes in the drm-misc-next branch. This patch moves 
the call to drm_is_current_master in drm_mode_getconnector out from the section 
locked by &dev->mode_config.mutex.

Additionally, added a missing semicolon to the patch, caught by the intel-gfx 
CI.

- Patch 3:
Move changes to drm_connector.c into patch 1.

Changes in v3 -> v4:
- Patch 3:
Move the call to drm_is_current_master in drm_mode_getconnector out from the 
section locked by &dev->mode_config.mutex. As suggested by Daniel Vetter. This 
avoids a circular lock lock dependency as reported here 
https://patchwork.freedesktop.org/patch/440406/

Additionally, inside drm_is_current_master, instead of grabbing 
&fpriv->master->dev->master_mutex, we grab &fpriv->minor->dev->master_mutex to 
avoid dereferencing a null ptr if fpriv->master is not set.

- Patch 5:
Modify kerneldoc formatting.

Additionally, add a file_priv->master NULL check inside drm_file_get_master, 
and handle the NULL result accordingly in drm_lease.c. As suggested by Daniel 
Vetter.

Changes in v2 -> v3:
- Patch 3:
Move the definition of drm_is_current_master and the _locked version higher up 
in drm_auth.c to avoid needing a forward declaration of 
drm_is_current_master_locked. As suggested by Daniel Vetter.

- Patch 5:
Instead of leaking drm_device.master_mutex into drm_lease.c to protect 
drm_master pointers, add a new drm_file_get_master() function that returns 
drm_file->master while increasing its reference count, to prevent 
drm_file->master from being freed. As suggested by Daniel Vetter.

Changes in v1 -> v2:
- Patch 5:
Move the lock and assignment before the DRM_DEBUG_LEASE in 
drm_mode_get_lease_ioctl, as suggested by Emil Velikov.

Desmond Cheong Zhi Xi (5):
  drm: avoid circular locks in drm_mode_getconnector
  drm: separate locks in __drm_mode_object_find
  drm: add a locked version of drm_is_current_master
  drm: serialize drm_file.master with a master lock
  drm: protect drm_master pointers in drm_lease.c

 drivers/gpu/drm/drm_auth.c| 86 +++
 drivers/gpu/drm/drm_connector.c   |  5 +-
 drivers/gpu/drm/drm_file.c|  1 +
 drivers/gpu/drm/drm_lease.c   | 81 ++---
 drivers/gpu/drm/drm_mode_object.c | 10 ++--
 include/drm/drm_auth.h|  1 +
 include/drm/drm_file.h| 18 +--
 7 files changed, 153 insertions(+), 49 deletions(-)

-- 
2.25.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v7 1/5] drm: avoid circular locks in drm_mode_getconnector

[Desmond Cheong Zhi Xi]

In preparation for a future patch to take a lock on
drm_device.master_mutex inside drm_is_current_master(), we first move
the call to drm_is_current_master() in drm_mode_getconnector out from the
section locked by &dev->mode_config.mutex. This avoids creating a
circular lock dependency.

Failing to avoid this lock dependency produces the following lockdep
splat:

==
WARNING: possible circular locking dependency detected
5.13.0-rc7-CI-CI_DRM_10254+ #1 Not tainted
--
kms_frontbuffer/1087 is trying to acquire lock:
88810dcd01a8 (&dev->master_mutex){+.+.}-{3:3}, at: 
drm_is_current_master+0x1b/0x40
but task is already holding lock:
88810dcd0488 (&dev->mode_config.mutex){+.+.}-{3:3}, at: 
drm_mode_getconnector+0x1c6/0x4a0
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (&dev->mode_config.mutex){+.+.}-{3:3}:
   __mutex_lock+0xab/0x970
   drm_client_modeset_probe+0x22e/0xca0
   __drm_fb_helper_initial_config_and_unlock+0x42/0x540
   intel_fbdev_initial_config+0xf/0x20 [i915]
   async_run_entry_fn+0x28/0x130
   process_one_work+0x26d/0x5c0
   worker_thread+0x37/0x380
   kthread+0x144/0x170
   ret_from_fork+0x1f/0x30
-> #1 (&client->modeset_mutex){+.+.}-{3:3}:
   __mutex_lock+0xab/0x970
   drm_client_modeset_commit_locked+0x1c/0x180
   drm_client_modeset_commit+0x1c/0x40
   __drm_fb_helper_restore_fbdev_mode_unlocked+0x88/0xb0
   drm_fb_helper_set_par+0x34/0x40
   intel_fbdev_set_par+0x11/0x40 [i915]
   fbcon_init+0x270/0x4f0
   visual_init+0xc6/0x130
   do_bind_con_driver+0x1e5/0x2d0
   do_take_over_console+0x10e/0x180
   do_fbcon_takeover+0x53/0xb0
   register_framebuffer+0x22d/0x310
   __drm_fb_helper_initial_config_and_unlock+0x36c/0x540
   intel_fbdev_initial_config+0xf/0x20 [i915]
   async_run_entry_fn+0x28/0x130
   process_one_work+0x26d/0x5c0
   worker_thread+0x37/0x380
   kthread+0x144/0x170
   ret_from_fork+0x1f/0x30
-> #0 (&dev->master_mutex){+.+.}-{3:3}:
   __lock_acquire+0x151e/0x2590
   lock_acquire+0xd1/0x3d0
   __mutex_lock+0xab/0x970
   drm_is_current_master+0x1b/0x40
   drm_mode_getconnector+0x37e/0x4a0
   drm_ioctl_kernel+0xa8/0xf0
   drm_ioctl+0x1e8/0x390
   __x64_sys_ioctl+0x6a/0xa0
   do_syscall_64+0x39/0xb0
   entry_SYSCALL_64_after_hwframe+0x44/0xae
other info that might help us debug this:
Chain exists of: &dev->master_mutex --> &client->modeset_mutex --> 
&dev->mode_config.mutex
 Possible unsafe locking scenario:
   CPU0CPU1
   
  lock(&dev->mode_config.mutex);
   lock(&client->modeset_mutex);
   lock(&dev->mode_config.mutex);
  lock(&dev->master_mutex);
*** DEADLOCK ***
1 lock held by kms_frontbuffer/1087:
 #0: 88810dcd0488 (&dev->mode_config.mutex){+.+.}-{3:3}, at: 
drm_mode_getconnector+0x1c6/0x4a0
stack backtrace:
CPU: 7 PID: 1087 Comm: kms_frontbuffer Not tainted 5.13.0-rc7-CI-CI_DRM_10254+ 
#1
Hardware name: Intel Corporation Ice Lake Client Platform/IceLake U DDR4 SODIMM 
PD RVP TLC, BIOS ICLSFWR1.R00.3234.A01.1906141750 06/14/2019
Call Trace:
 dump_stack+0x7f/0xad
 check_noncircular+0x12e/0x150
 __lock_acquire+0x151e/0x2590
 lock_acquire+0xd1/0x3d0
 __mutex_lock+0xab/0x970
 drm_is_current_master+0x1b/0x40
 drm_mode_getconnector+0x37e/0x4a0
 drm_ioctl_kernel+0xa8/0xf0
 drm_ioctl+0x1e8/0x390
 __x64_sys_ioctl+0x6a/0xa0
 do_syscall_64+0x39/0xb0
 entry_SYSCALL_64_after_hwframe+0x44/0xae

Reported-by: Daniel Vetter 
Signed-off-by: Desmond Cheong Zhi Xi 
Reviewed-by: Emil Velikov 
---
 drivers/gpu/drm/drm_connector.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index da39e7ff6965..2ba257b1ae20 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -2414,6 +2414,7 @@ int drm_mode_getconnector(struct drm_device *dev, void 
*data,
struct drm_mode_modeinfo u_mode;
struct drm_mode_modeinfo __user *mode_ptr;
uint32_t __user *encoder_ptr;
+   bool is_current_master;
 
if (!drm_core_check_feature(dev, DRIVER_MODESET))
return -EOPNOTSUPP;
@@ -2444,9 +2445,11 @@ int drm_mode_getconnector(struct drm_device *dev, void 
*data,
out_resp->connector_type = connector->connector_type;
out_resp->connector_type_id = connector->connector_type_id;
 
+   is_current_master = drm_is_current_master(file_priv);
+
mutex_lock(&dev->mode_config.mutex);
if (out_resp->count_modes == 0) {
-   if (drm_is_current_master(file_priv))
+   if (is_current_master)
connector->funcs->fill_modes(connector,

[Intel-gfx] [PATCH v7 5/5] drm: protect drm_master pointers in drm_lease.c

[Desmond Cheong Zhi Xi]

drm_file->master pointers should be protected by
drm_device.master_mutex or drm_file.master_lock when being
dereferenced.

However, in drm_lease.c, there are multiple instances where
drm_file->master is accessed and dereferenced while neither lock is
held. This makes drm_lease.c vulnerable to use-after-free bugs.

We address this issue in 2 ways:

1. Add a new drm_file_get_master() function that calls drm_master_get
on drm_file->master while holding on to drm_file.master_lock. Since
drm_master_get increments the reference count of master, this
prevents master from being freed until we unreference it with
drm_master_put.

2. In each case where drm_file->master is directly accessed and
eventually dereferenced in drm_lease.c, we wrap the access in a call
to the new drm_file_get_master function, then unreference the master
pointer once we are done using it.

Reported-by: Daniel Vetter 
Signed-off-by: Desmond Cheong Zhi Xi 
Reviewed-by: Emil Velikov 
---
 drivers/gpu/drm/drm_auth.c  | 25 
 drivers/gpu/drm/drm_lease.c | 81 -
 include/drm/drm_auth.h  |  1 +
 include/drm/drm_file.h  |  6 +++
 4 files changed, 93 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
index fe5b6adc6133..17440ee54f30 100644
--- a/drivers/gpu/drm/drm_auth.c
+++ b/drivers/gpu/drm/drm_auth.c
@@ -390,6 +390,31 @@ struct drm_master *drm_master_get(struct drm_master 
*master)
 }
 EXPORT_SYMBOL(drm_master_get);
 
+/**
+ * drm_file_get_master - reference &drm_file.master of @file_priv
+ * @file_priv: DRM file private
+ *
+ * Increments the reference count of @file_priv's &drm_file.master and returns
+ * the &drm_file.master. If @file_priv has no &drm_file.master, returns NULL.
+ *
+ * Master pointers returned from this function should be unreferenced using
+ * drm_master_put().
+ */
+struct drm_master *drm_file_get_master(struct drm_file *file_priv)
+{
+   struct drm_master *master = NULL;
+
+   mutex_lock(&file_priv->master_lock);
+   if (!file_priv->master)
+   goto unlock;
+   master = drm_master_get(file_priv->master);
+
+unlock:
+   mutex_unlock(&file_priv->master_lock);
+   return master;
+}
+EXPORT_SYMBOL(drm_file_get_master);
+
 static void drm_master_destroy(struct kref *kref)
 {
struct drm_master *master = container_of(kref, struct drm_master, 
refcount);
diff --git a/drivers/gpu/drm/drm_lease.c b/drivers/gpu/drm/drm_lease.c
index 00fb433bcef1..92eac73d9001 100644
--- a/drivers/gpu/drm/drm_lease.c
+++ b/drivers/gpu/drm/drm_lease.c
@@ -106,10 +106,19 @@ static bool _drm_has_leased(struct drm_master *master, 
int id)
  */
 bool _drm_lease_held(struct drm_file *file_priv, int id)
 {
-   if (!file_priv || !file_priv->master)
+   bool ret;
+   struct drm_master *master;
+
+   if (!file_priv)
return true;
 
-   return _drm_lease_held_master(file_priv->master, id);
+   master = drm_file_get_master(file_priv);
+   if (!master)
+   return true;
+   ret = _drm_lease_held_master(master, id);
+   drm_master_put(&master);
+
+   return ret;
 }
 
 /**
@@ -128,13 +137,22 @@ bool drm_lease_held(struct drm_file *file_priv, int id)
struct drm_master *master;
bool ret;
 
-   if (!file_priv || !file_priv->master || !file_priv->master->lessor)
+   if (!file_priv)
return true;
 
-   master = file_priv->master;
+   master = drm_file_get_master(file_priv);
+   if (!master)
+   return true;
+   if (!master->lessor) {
+   ret = true;
+   goto out;
+   }
mutex_lock(&master->dev->mode_config.idr_mutex);
ret = _drm_lease_held_master(master, id);
mutex_unlock(&master->dev->mode_config.idr_mutex);
+
+out:
+   drm_master_put(&master);
return ret;
 }
 
@@ -154,10 +172,16 @@ uint32_t drm_lease_filter_crtcs(struct drm_file 
*file_priv, uint32_t crtcs_in)
int count_in, count_out;
uint32_t crtcs_out = 0;
 
-   if (!file_priv || !file_priv->master || !file_priv->master->lessor)
+   if (!file_priv)
return crtcs_in;
 
-   master = file_priv->master;
+   master = drm_file_get_master(file_priv);
+   if (!master)
+   return crtcs_in;
+   if (!master->lessor) {
+   crtcs_out = crtcs_in;
+   goto out;
+   }
dev = master->dev;
 
count_in = count_out = 0;
@@ -176,6 +200,9 @@ uint32_t drm_lease_filter_crtcs(struct drm_file *file_priv, 
uint32_t crtcs_in)
count_in++;
}
mutex_unlock(&master->dev->mode_config.idr_mutex);
+
+out:
+   drm_master_put(&master);
return crtcs_out;
 }
 
@@ -489,7 +516,7 @@ int drm_mode_create_lease_ioctl(struct drm_device *dev,
size_t object_count;
int ret = 0;
struct idr leases;
-   struct drm_master *lessor = lessor_priv->master;
+  

[Intel-gfx] [PATCH v7 4/5] drm: serialize drm_file.master with a master lock

[Desmond Cheong Zhi Xi]

Currently, drm_file.master pointers should be protected by
drm_device.master_mutex when being dereferenced. This is because
drm_file.master is not invariant for the lifetime of drm_file. If
drm_file is not the creator of master, then drm_file.is_master is
false, and a call to drm_setmaster_ioctl will invoke
drm_new_set_master, which then allocates a new master for drm_file and
puts the old master.

Thus, without holding drm_device.master_mutex, the old value of
drm_file.master could be freed while it is being used by another
concurrent process.

However, it is not always possible to lock drm_device.master_mutex to
dereference drm_file.master. Through the fbdev emulation code, this
might occur in a deep nest of other locks. But drm_device.master_mutex
is also the outermost lock in the nesting hierarchy, so this leads to
potential deadlocks.

To address this, we introduce a new mutex at the bottom of the lock
hierarchy that only serializes drm_file.master. With this change, the
value of drm_file.master changes only when both
drm_device.master_mutex and drm_file.master_lock are held. Hence, any
process holding either of those locks can ensure that the value of
drm_file.master will not change concurrently.

Since no lock depends on the new drm_file.master_lock, when
drm_file.master is dereferenced, but drm_device.master_mutex cannot be
held, we can safely protect the master pointer with
drm_file.master_lock.

Reported-by: Daniel Vetter 
Signed-off-by: Desmond Cheong Zhi Xi 
---

Since our lock inversions were a result of dev->master_mutex being
used to serialize many other things, perhaps a finer grained lock will
solve the lockdep issues.

 drivers/gpu/drm/drm_auth.c | 10 --
 drivers/gpu/drm/drm_file.c |  1 +
 include/drm/drm_file.h | 12 +---
 3 files changed, 18 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
index ab1863c5a5a0..fe5b6adc6133 100644
--- a/drivers/gpu/drm/drm_auth.c
+++ b/drivers/gpu/drm/drm_auth.c
@@ -169,11 +169,14 @@ static int drm_new_set_master(struct drm_device *dev, 
struct drm_file *fpriv)
 
WARN_ON(fpriv->is_master);
old_master = fpriv->master;
+   mutex_lock(&fpriv->master_lock);
fpriv->master = drm_master_create(dev);
if (!fpriv->master) {
fpriv->master = old_master;
+   mutex_unlock(&fpriv->master_lock);
return -ENOMEM;
}
+   mutex_unlock(&fpriv->master_lock);
 
fpriv->is_master = 1;
fpriv->authenticated = 1;
@@ -332,10 +335,13 @@ int drm_master_open(struct drm_file *file_priv)
 * any master object for render clients
 */
mutex_lock(&dev->master_mutex);
-   if (!dev->master)
+   if (!dev->master) {
ret = drm_new_set_master(dev, file_priv);
-   else
+   } else {
+   mutex_lock(&file_priv->master_lock);
file_priv->master = drm_master_get(dev->master);
+   mutex_unlock(&file_priv->master_lock);
+   }
mutex_unlock(&dev->master_mutex);
 
return ret;
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index d4f0bac6f8f8..8ccadfa1c752 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -176,6 +176,7 @@ struct drm_file *drm_file_alloc(struct drm_minor *minor)
init_waitqueue_head(&file->event_wait);
file->event_space = 4096; /* set aside 4k for event buffer */
 
+   mutex_init(&file->master_lock);
mutex_init(&file->event_read_lock);
 
if (drm_core_check_feature(dev, DRIVER_GEM))
diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
index b81b3bfb08c8..88539f93fc8e 100644
--- a/include/drm/drm_file.h
+++ b/include/drm/drm_file.h
@@ -226,15 +226,21 @@ struct drm_file {
/**
 * @master:
 *
-* Master this node is currently associated with. Only relevant if
-* drm_is_primary_client() returns true. Note that this only
-* matches &drm_device.master if the master is the currently active one.
+* Master this node is currently associated with. Protected by struct
+* &drm_device.master_mutex, and serialized by @master_lock.
+*
+* Only relevant if drm_is_primary_client() returns true. Note that
+* this only matches &drm_device.master if the master is the currently
+* active one.
 *
 * See also @authentication and @is_master and the :ref:`section on
 * primary nodes and authentication `.
 */
struct drm_master *master;
 
+   /** @master_lock: Serializes @master. */
+   struct mutex master_lock;
+
/** @pid: Process that opened this file. */
struct pid *pid;
 
-- 
2.25.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v7 2/5] drm: separate locks in __drm_mode_object_find

[Desmond Cheong Zhi Xi]

In a future patch, _drm_lease_held will dereference drm_file->master
only after making a call to drm_file_get_master. This will increment
the reference count of drm_file->master while holding onto a new
drm_file.master_lock.

In preparation for this, the call to _drm_lease_held should be moved
out from the section locked by &dev->mode_config.idr_mutex. This
avoids creating new lock hierarchies between
&dev->mode_config.idr_mutex and &drm_file->master_lock.

Reported-by: Daniel Vetter 
Signed-off-by: Desmond Cheong Zhi Xi 
---
 drivers/gpu/drm/drm_mode_object.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_mode_object.c 
b/drivers/gpu/drm/drm_mode_object.c
index b26588b52795..83e35ff3b13a 100644
--- a/drivers/gpu/drm/drm_mode_object.c
+++ b/drivers/gpu/drm/drm_mode_object.c
@@ -146,16 +146,18 @@ struct drm_mode_object *__drm_mode_object_find(struct 
drm_device *dev,
if (obj && obj->id != id)
obj = NULL;
 
-   if (obj && drm_mode_object_lease_required(obj->type) &&
-   !_drm_lease_held(file_priv, obj->id))
-   obj = NULL;
-
if (obj && obj->free_cb) {
if (!kref_get_unless_zero(&obj->refcount))
obj = NULL;
}
mutex_unlock(&dev->mode_config.idr_mutex);
 
+   if (obj && drm_mode_object_lease_required(obj->type) &&
+   !_drm_lease_held(file_priv, obj->id)) {
+   drm_mode_object_put(obj);
+   obj = NULL;
+   }
+
return obj;
 }
 
-- 
2.25.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [Mesa-dev] Requests For Proposals for hosting XDC 2022 are now open

[Samuel Iglesias Gonsálvez]

This is a reminder that the call for proposals for hosting XDC 2022
period finishes in two months.

Be sure to prepare your submission before you leave on holiday!

Sam

On Thu, 2021-05-20 at 12:15 +0200, Samuel Iglesias Gonsálvez wrote:
> Hello everyone!
> 
> The X.org board is soliciting proposals to host XDC in 2022. Since
> XDC 2021 is being held in Europe this year (although virtually),
> we've
> decided to host in North America. However, the board is open to other
> locations, especially if there's an interesting co-location with
> another conference.
> 
> Of course though, due to the ongoing COVID-19 pandemic it's not yet
> clear whether or not it will be possible to host XDC 2022 in person,
> although is seems very likely. Because of this, we would like to
> make it clear that sponsors should prepare for both the possibility
> of an in person conference, and the possibility of a virtual
> conference. We will work with organizers on coming up with a
> deadline for deciding whether or not we'll be going virtual, likely
> sometime around July 2022.
> 
> If you're considering hosting XDC, we've assembled a wiki page with
> what's generally expected and needed:
> 
> https://www.x.org/wiki/Events/RFP/
> 
> When submitting your proposal, please make sure to include at least
> the
> key information about the potential location in question, possible
> dates along with estimated costs. Proposals can be submitted to board
> at foundation.x.org until the deadline of *September 1st, 2021*. 
> 
> Additionally, an quirk early heads-up to the board if you're
> considering hosting would be appreciated, in case we need to adjust
> the
> schedule a bit. Also, earlier is better since there generally will be
> a
> bit of Q&A with organizers.
> 
> And if you just have some questions about what organizing XDC
> entails,
> please feel free to chat with previous organizers, or someone from
> the
> board.
> 
> Thanks,
> 
> Sam
> 
> ___
> mesa-dev mailing list
> mesa-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev



signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v7 3/5] drm: add a locked version of drm_is_current_master

[Desmond Cheong Zhi Xi]

While checking the master status of the DRM file in
drm_is_current_master(), the device's master mutex should be
held. Without the mutex, the pointer fpriv->master may be freed
concurrently by another process calling drm_setmaster_ioctl(). This
could lead to use-after-free errors when the pointer is subsequently
dereferenced in drm_lease_owner().

The callers of drm_is_current_master() from drm_auth.c hold the
device's master mutex, but external callers do not. Hence, we implement
drm_is_current_master_locked() to be used within drm_auth.c, and
modify drm_is_current_master() to grab the device's master mutex
before checking the master status.

Reported-by: Daniel Vetter 
Signed-off-by: Desmond Cheong Zhi Xi 
Reviewed-by: Emil Velikov 
---
 drivers/gpu/drm/drm_auth.c | 51 --
 1 file changed, 32 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
index f00e5abdbbf4..ab1863c5a5a0 100644
--- a/drivers/gpu/drm/drm_auth.c
+++ b/drivers/gpu/drm/drm_auth.c
@@ -61,6 +61,35 @@
  * trusted clients.
  */
 
+static bool drm_is_current_master_locked(struct drm_file *fpriv)
+{
+   lockdep_assert_held_once(&fpriv->minor->dev->master_mutex);
+
+   return fpriv->is_master && drm_lease_owner(fpriv->master) == 
fpriv->minor->dev->master;
+}
+
+/**
+ * drm_is_current_master - checks whether @priv is the current master
+ * @fpriv: DRM file private
+ *
+ * Checks whether @fpriv is current master on its device. This decides whether 
a
+ * client is allowed to run DRM_MASTER IOCTLs.
+ *
+ * Most of the modern IOCTL which require DRM_MASTER are for kernel modesetting
+ * - the current master is assumed to own the non-shareable display hardware.
+ */
+bool drm_is_current_master(struct drm_file *fpriv)
+{
+   bool ret;
+
+   mutex_lock(&fpriv->minor->dev->master_mutex);
+   ret = drm_is_current_master_locked(fpriv);
+   mutex_unlock(&fpriv->minor->dev->master_mutex);
+
+   return ret;
+}
+EXPORT_SYMBOL(drm_is_current_master);
+
 int drm_getmagic(struct drm_device *dev, void *data, struct drm_file 
*file_priv)
 {
struct drm_auth *auth = data;
@@ -223,7 +252,7 @@ int drm_setmaster_ioctl(struct drm_device *dev, void *data,
if (ret)
goto out_unlock;
 
-   if (drm_is_current_master(file_priv))
+   if (drm_is_current_master_locked(file_priv))
goto out_unlock;
 
if (dev->master) {
@@ -272,7 +301,7 @@ int drm_dropmaster_ioctl(struct drm_device *dev, void *data,
if (ret)
goto out_unlock;
 
-   if (!drm_is_current_master(file_priv)) {
+   if (!drm_is_current_master_locked(file_priv)) {
ret = -EINVAL;
goto out_unlock;
}
@@ -321,7 +350,7 @@ void drm_master_release(struct drm_file *file_priv)
if (file_priv->magic)
idr_remove(&file_priv->master->magic_map, file_priv->magic);
 
-   if (!drm_is_current_master(file_priv))
+   if (!drm_is_current_master_locked(file_priv))
goto out;
 
drm_legacy_lock_master_cleanup(dev, master);
@@ -342,22 +371,6 @@ void drm_master_release(struct drm_file *file_priv)
mutex_unlock(&dev->master_mutex);
 }
 
-/**
- * drm_is_current_master - checks whether @priv is the current master
- * @fpriv: DRM file private
- *
- * Checks whether @fpriv is current master on its device. This decides whether 
a
- * client is allowed to run DRM_MASTER IOCTLs.
- *
- * Most of the modern IOCTL which require DRM_MASTER are for kernel modesetting
- * - the current master is assumed to own the non-shareable display hardware.
- */
-bool drm_is_current_master(struct drm_file *fpriv)
-{
-   return fpriv->is_master && drm_lease_owner(fpriv->master) == 
fpriv->minor->dev->master;
-}
-EXPORT_SYMBOL(drm_is_current_master);
-
 /**
  * drm_master_get - reference a master pointer
  * @master: &struct drm_master
-- 
2.25.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/3] drm/i915: use consistent CPU mappings for pin_map users

[Patchwork]

== Series Details ==

Series: series starting with [1/3] drm/i915: use consistent CPU mappings for 
pin_map users
URL   : https://patchwork.freedesktop.org/series/92113/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10297_full -> Patchwork_20508_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_20508_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_20508_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  

Possible new issues
---

  Here are the unknown changes that may have been introduced in 
Patchwork_20508_full:

### IGT changes ###

 Possible regressions 

  * igt@kms_big_fb@yf-tiled-16bpp-rotate-0:
- shard-glk:  [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10297/shard-glk3/igt@kms_big...@yf-tiled-16bpp-rotate-0.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20508/shard-glk2/igt@kms_big...@yf-tiled-16bpp-rotate-0.html

  * igt@kms_big_fb@yf-tiled-max-hw-stride-32bpp-rotate-180-async-flip:
- shard-skl:  NOTRUN -> [FAIL][3]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20508/shard-skl4/igt@kms_big...@yf-tiled-max-hw-stride-32bpp-rotate-180-async-flip.html

  * igt@kms_cursor_legacy@pipe-d-torture-move:
- shard-tglb: [PASS][4] -> [INCOMPLETE][5]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10297/shard-tglb7/igt@kms_cursor_leg...@pipe-d-torture-move.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20508/shard-tglb6/igt@kms_cursor_leg...@pipe-d-torture-move.html

  
Known issues


  Here are the changes found in Patchwork_20508_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@gem_create@create-massive:
- shard-snb:  NOTRUN -> [DMESG-WARN][6] ([i915#3002])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20508/shard-snb7/igt@gem_cre...@create-massive.html

  * igt@gem_ctx_persistence@legacy-engines-mixed:
- shard-snb:  NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#1099]) +7 
similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20508/shard-snb5/igt@gem_ctx_persiste...@legacy-engines-mixed.html

  * igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-glk:  NOTRUN -> [FAIL][8] ([i915#2842])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20508/shard-glk7/igt@gem_exec_fair@basic-pace-s...@rcs0.html

  * igt@gem_exec_reloc@basic-wide-active@rcs0:
- shard-snb:  NOTRUN -> [FAIL][9] ([i915#3633]) +2 similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20508/shard-snb7/igt@gem_exec_reloc@basic-wide-act...@rcs0.html

  * igt@gem_huc_copy@huc-copy:
- shard-apl:  NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#2190])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20508/shard-apl1/igt@gem_huc_c...@huc-copy.html

  * igt@gem_pread@exhaustion:
- shard-snb:  NOTRUN -> [WARN][11] ([i915#2658])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20508/shard-snb6/igt@gem_pr...@exhaustion.html

  * igt@gem_pwrite@basic-exhaustion:
- shard-apl:  NOTRUN -> [WARN][12] ([i915#2658])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20508/shard-apl7/igt@gem_pwr...@basic-exhaustion.html

  * igt@gen9_exec_parse@allowed-single:
- shard-skl:  [PASS][13] -> [DMESG-WARN][14] ([i915#1436] / 
[i915#716])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10297/shard-skl7/igt@gen9_exec_pa...@allowed-single.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20508/shard-skl5/igt@gen9_exec_pa...@allowed-single.html

  * igt@gen9_exec_parse@bb-large:
- shard-skl:  NOTRUN -> [FAIL][15] ([i915#3296])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20508/shard-skl4/igt@gen9_exec_pa...@bb-large.html
- shard-glk:  NOTRUN -> [FAIL][16] ([i915#3296])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20508/shard-glk7/igt@gen9_exec_pa...@bb-large.html
- shard-kbl:  NOTRUN -> [FAIL][17] ([i915#3296])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20508/shard-kbl7/igt@gen9_exec_pa...@bb-large.html

  * igt@i915_pm_dc@dc6-psr:
- shard-iclb: [PASS][18] -> [FAIL][19] ([i915#454])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10297/shard-iclb5/igt@i915_pm...@dc6-psr.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20508/shard-iclb4/igt@i915_pm...@dc6-psr.html

  * igt@kms_color@pipe-a-ctm-0-5:
- shard-skl:  [PASS][20] -> [DMESG-WARN][21] ([i915#1982])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10297/shard-skl5/igt@kms_co...@pipe-a-ctm-

Re: [Intel-gfx] [PATCH 47/47] drm/i915/guc: Unblock GuC submission on Gen11+

[Martin Peres]

On 30/06/2021 21:00, Matthew Brost wrote:

On Wed, Jun 30, 2021 at 11:22:38AM +0300, Martin Peres wrote:



On 24/06/2021 10:05, Matthew Brost wrote:

From: Daniele Ceraolo Spurio 

Unblock GuC submission on Gen11+ platforms.

Signed-off-by: Michal Wajdeczko 
Signed-off-by: Daniele Ceraolo Spurio 
Signed-off-by: Matthew Brost 
---
   drivers/gpu/drm/i915/gt/uc/intel_guc.h|  1 +
   drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c |  8 
   drivers/gpu/drm/i915/gt/uc/intel_guc_submission.h |  3 +--
   drivers/gpu/drm/i915/gt/uc/intel_uc.c | 14 +-
   4 files changed, 19 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h 
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index fae01dc8e1b9..77981788204f 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -54,6 +54,7 @@ struct intel_guc {
struct ida guc_ids;
struct list_head guc_id_list;
+   bool submission_supported;
bool submission_selected;
struct i915_vma *ads_vma;
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 a427336ce916..405339202280 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -2042,6 +2042,13 @@ void intel_guc_submission_disable(struct intel_guc *guc)
/* Note: By the time we're here, GuC may have already been reset */
   }
+static bool __guc_submission_supported(struct intel_guc *guc)
+{
+   /* GuC submission is unavailable for pre-Gen11 */
+   return intel_guc_is_supported(guc) &&
+  INTEL_GEN(guc_to_gt(guc)->i915) >= 11;
+}
+
   static bool __guc_submission_selected(struct intel_guc *guc)
   {
struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
@@ -2054,6 +2061,7 @@ static bool __guc_submission_selected(struct intel_guc 
*guc)
   void intel_guc_submission_init_early(struct intel_guc *guc)
   {
+   guc->submission_supported = __guc_submission_supported(guc);
guc->submission_selected = __guc_submission_selected(guc);
   }
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.h 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.h
index a2a3fad72be1..be767eb6ff71 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.h
@@ -37,8 +37,7 @@ int intel_guc_wait_for_pending_msg(struct intel_guc *guc,
   static inline bool intel_guc_submission_is_supported(struct intel_guc *guc)
   {
-   /* XXX: GuC submission is unavailable for now */
-   return false;
+   return guc->submission_supported;
   }
   static inline bool intel_guc_submission_is_wanted(struct intel_guc *guc)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index 7a69c3c027e9..61be0aa81492 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -34,8 +34,15 @@ static void uc_expand_default_options(struct intel_uc *uc)
return;
}
-   /* Default: enable HuC authentication only */
-   i915->params.enable_guc = ENABLE_GUC_LOAD_HUC;
+   /* Intermediate platforms are HuC authentication only */
+   if (IS_DG1(i915) || IS_ALDERLAKE_S(i915)) {
+   drm_dbg(&i915->drm, "Disabling GuC only due to old platform\n");


This comment does not seem accurate, given that DG1 is barely out, and ADL
is not out yet. How about:

"Disabling GuC on untested platforms"?


This isn't my comment but it seems right to me. AFAIK this describes the
current PR but it is subject to change (i.e. we may enable GuC on DG1 by
default at some point).


Well, it's pretty bad PR to say that DG1 and ADL are old when they are 
not even out ;)


But seriously, fix this sentence, it makes no sense at all unless you 
are really trying to confuse non-native speakers (and annoy language 
purists too).







+   i915->params.enable_guc = ENABLE_GUC_LOAD_HUC;
+   return;
+   }
+
+   /* Default: enable HuC authentication and GuC submission */
+   i915->params.enable_guc = ENABLE_GUC_LOAD_HUC | ENABLE_GUC_SUBMISSION;


This seems to be in contradiction with the GuC submission plan which states:

"Not enabled by default on any current platforms but can be enabled via
modparam enable_guc".



I don't believe any current platform gets this point where GuC
submission would be enabled by default. The first would be ADL-P which
isn't out yet.


Isn't that exactly what the line above does?




When you rework the patch, could you please add a warning when the user
force-enables the GuC Command Submission? Something like:

"WARNING: The user force-enabled the experimental GuC command submission
backend using i915.enable_guc. Please disable it if experiencing stability
issues. No bug reports will be accepted on this backend".

This should allow you to work on the 

Re: [Intel-gfx] [PATCH 47/47] drm/i915/guc: Unblock GuC submission on Gen11+

[Martin Peres]

On 01/07/2021 11:14, Pekka Paalanen wrote:

On Wed, 30 Jun 2021 11:58:25 -0700
John Harrison  wrote:


On 6/30/2021 01:22, Martin Peres wrote:

On 24/06/2021 10:05, Matthew Brost wrote:

From: Daniele Ceraolo Spurio 

Unblock GuC submission on Gen11+ platforms.

Signed-off-by: Michal Wajdeczko 
Signed-off-by: Daniele Ceraolo Spurio 
Signed-off-by: Matthew Brost 
---
   drivers/gpu/drm/i915/gt/uc/intel_guc.h    |  1 +
   drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c |  8 
   drivers/gpu/drm/i915/gt/uc/intel_guc_submission.h |  3 +--
   drivers/gpu/drm/i915/gt/uc/intel_uc.c | 14 +-
   4 files changed, 19 insertions(+), 7 deletions(-)



...


diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index 7a69c3c027e9..61be0aa81492 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -34,8 +34,15 @@ static void uc_expand_default_options(struct
intel_uc *uc)
   return;
   }
   -    /* Default: enable HuC authentication only */
-    i915->params.enable_guc = ENABLE_GUC_LOAD_HUC;
+    /* Intermediate platforms are HuC authentication only */
+    if (IS_DG1(i915) || IS_ALDERLAKE_S(i915)) {
+    drm_dbg(&i915->drm, "Disabling GuC only due to old
platform\n");


This comment does not seem accurate, given that DG1 is barely out, and
ADL is not out yet. How about:

"Disabling GuC on untested platforms"?
  

Just because something is not in the shops yet does not mean it is new.
Technology is always obsolete by the time it goes on sale.


That is a very good reason to not use terminology like "new", "old",
"current", "modern" etc. at all.

End users like me definitely do not share your interpretation of "old".


Yep, old and new is relative. In the end, what matters is the validation 
effort, which is why I was proposing "untested platforms".


Also, remember that you are not writing these messages for Intel 
engineers, but instead are writing for Linux *users*.


Cheers,
Martin




Thanks,
pq



And the issue is not a lack of testing, it is a question of whether we
are allowed to change the default on something that has already started
being used by customers or not (including pre-release beta customers).
I.e. it is basically a political decision not an engineering decision.



___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v2,1/3] drm/i915: use consistent CPU mappings for pin_map users

[Patchwork]

== Series Details ==

Series: series starting with [v2,1/3] drm/i915: use consistent CPU mappings for 
pin_map users
URL   : https://patchwork.freedesktop.org/series/92114/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10297_full -> Patchwork_20509_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_20509_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_20509_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  

Possible new issues
---

  Here are the unknown changes that may have been introduced in 
Patchwork_20509_full:

### IGT changes ###

 Possible regressions 

  * igt@kms_big_fb@yf-tiled-16bpp-rotate-0:
- shard-glk:  [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10297/shard-glk3/igt@kms_big...@yf-tiled-16bpp-rotate-0.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20509/shard-glk3/igt@kms_big...@yf-tiled-16bpp-rotate-0.html

  * igt@kms_big_fb@yf-tiled-max-hw-stride-32bpp-rotate-180-async-flip:
- shard-skl:  NOTRUN -> [FAIL][3]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20509/shard-skl9/igt@kms_big...@yf-tiled-max-hw-stride-32bpp-rotate-180-async-flip.html

  * igt@sysfs_heartbeat_interval@precise@rcs0:
- shard-tglb: [PASS][4] -> [INCOMPLETE][5]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10297/shard-tglb7/igt@sysfs_heartbeat_interval@prec...@rcs0.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20509/shard-tglb5/igt@sysfs_heartbeat_interval@prec...@rcs0.html

  
Known issues


  Here are the changes found in Patchwork_20509_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@gem_create@create-massive:
- shard-snb:  NOTRUN -> [DMESG-WARN][6] ([i915#3002])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20509/shard-snb7/igt@gem_cre...@create-massive.html

  * igt@gem_ctx_persistence@legacy-engines-mixed:
- shard-snb:  NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#1099]) +7 
similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20509/shard-snb7/igt@gem_ctx_persiste...@legacy-engines-mixed.html

  * igt@gem_exec_fair@basic-none@vcs0:
- shard-kbl:  [PASS][8] -> [FAIL][9] ([i915#2842])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10297/shard-kbl3/igt@gem_exec_fair@basic-n...@vcs0.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20509/shard-kbl4/igt@gem_exec_fair@basic-n...@vcs0.html

  * igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-glk:  NOTRUN -> [FAIL][10] ([i915#2842])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20509/shard-glk7/igt@gem_exec_fair@basic-pace-s...@rcs0.html

  * igt@gem_exec_flush@basic-batch-kernel-default-cmd:
- shard-iclb: NOTRUN -> [SKIP][11] ([fdo#109313])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20509/shard-iclb7/igt@gem_exec_fl...@basic-batch-kernel-default-cmd.html

  * igt@gem_exec_reloc@basic-wide-active@rcs0:
- shard-snb:  NOTRUN -> [FAIL][12] ([i915#3633]) +2 similar issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20509/shard-snb7/igt@gem_exec_reloc@basic-wide-act...@rcs0.html

  * igt@gem_huc_copy@huc-copy:
- shard-apl:  NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#2190])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20509/shard-apl7/igt@gem_huc_c...@huc-copy.html

  * igt@gem_mmap_gtt@big-copy:
- shard-glk:  [PASS][14] -> [FAIL][15] ([i915#307])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10297/shard-glk8/igt@gem_mmap_...@big-copy.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20509/shard-glk8/igt@gem_mmap_...@big-copy.html

  * igt@gem_mmap_gtt@big-copy-odd:
- shard-skl:  [PASS][16] -> [FAIL][17] ([i915#307])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10297/shard-skl3/igt@gem_mmap_...@big-copy-odd.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20509/shard-skl3/igt@gem_mmap_...@big-copy-odd.html

  * igt@gem_mmap_gtt@cpuset-big-copy:
- shard-iclb: [PASS][18] -> [FAIL][19] ([i915#307])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10297/shard-iclb3/igt@gem_mmap_...@cpuset-big-copy.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20509/shard-iclb3/igt@gem_mmap_...@cpuset-big-copy.html

  * igt@gem_mmap_offset@clear:
- shard-skl:  [PASS][20] -> [FAIL][21] ([i915#3160])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10297/shard-skl2/igt@gem_mmap_off...@clear.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20509/shard-sk

Re: [Intel-gfx] [PATCH 1/1] drm/i915/dg1: Compute MEM Bandwidth using MCHBAR

[Souza, Jose]

On Wed, 2021-06-30 at 21:06 -0700, Lucas De Marchi wrote:
> From: Clint Taylor 
> 
> The PUNIT FW is currently returning 0 for all memory bandwidth
> parameters. Read the values directly from MCHBAR offsets 0x5918 and
> 0x4000(4).
> 
> v2 (Lucas): tidy up checking for ret slightly
> v3 (Lucas):
>   - Squash change to double the memory bandwidth based on
> MCHBAR Gear_type
>   - Move ICL_GEAR_TYPE_MASK to the appropriate place and change prefix
> to DG1
>   - Move register definitions to i915_reg.h
>   - Make the MCHBAR path permanent for DG1
>   - Convert to REG_BIT()/REG_GENMASK()
> 
> Cc: Ville Syrjälä 
> Cc: Matt Roper 
> Cc: Jani Saarinen 
> Signed-off-by: Clint Taylor 
> Signed-off-by: Jani Nikula 
> Signed-off-by: Matthew Auld 
> Reviewed-by: Lucas De Marchi 
> Signed-off-by: Lucas De Marchi 
> ---
>  drivers/gpu/drm/i915/display/intel_bw.c | 41 -
>  drivers/gpu/drm/i915/i915_reg.h | 12 
>  2 files changed, 52 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_bw.c 
> b/drivers/gpu/drm/i915/display/intel_bw.c
> index bfb398f0432e..c913c2151680 100644
> --- a/drivers/gpu/drm/i915/display/intel_bw.c
> +++ b/drivers/gpu/drm/i915/display/intel_bw.c
> @@ -23,6 +23,41 @@ struct intel_qgv_info {
>   u8 t_bl;
>  };
>  
> +static int dg1_mchbar_read_qgv_point_info(struct drm_i915_private *dev_priv,
> +   struct intel_qgv_point *sp,
> +   int point)
> +{
> + u32 dclk_ratio = 0, dclk_reference = 0;
> + u32 val = 0;

Only one nitpick, the initializations above are not needed.

Reviewed-by: José Roberto de Souza 

> +
> + val = intel_uncore_read(&dev_priv->uncore, 
> SA_PERF_STATUS_0_0_0_MCHBAR_PC);
> + dclk_ratio = REG_FIELD_GET(DG1_QCLK_RATIO_MASK, val);
> + if (val & DG1_QCLK_REFERENCE)
> + dclk_reference = 6; /* 6 * 16.666 MHz = 100 MHz */
> + else
> + dclk_reference = 8; /* 8 * 16.666 MHz = 133 MHz */
> + sp->dclk = dclk_ratio * dclk_reference;
> +
> + val = intel_uncore_read(&dev_priv->uncore, 
> SKL_MC_BIOS_DATA_0_0_0_MCHBAR_PCU);
> + if (val & DG1_GEAR_TYPE)
> + sp->dclk *= 2;
> +
> + if (sp->dclk == 0)
> + return -EINVAL;
> +
> + val = intel_uncore_read(&dev_priv->uncore, 
> MCHBAR_CH0_CR_TC_PRE_0_0_0_MCHBAR);
> + sp->t_rp = REG_FIELD_GET(DG1_DRAM_T_RP_MASK, val);
> + sp->t_rdpre = REG_FIELD_GET(DG1_DRAM_T_RDPRE_MASK, val);
> +
> + val = intel_uncore_read(&dev_priv->uncore, 
> MCHBAR_CH0_CR_TC_PRE_0_0_0_MCHBAR_HIGH);
> + sp->t_rcd = REG_FIELD_GET(DG1_DRAM_T_RCD_MASK, val);
> + sp->t_ras = REG_FIELD_GET(DG1_DRAM_T_RAS_MASK, val);
> +
> + sp->t_rc = sp->t_rp + sp->t_ras;
> +
> + return 0;
> +}
> +
>  static int icl_pcode_read_qgv_point_info(struct drm_i915_private *dev_priv,
>struct intel_qgv_point *sp,
>int point)
> @@ -99,7 +134,11 @@ static int icl_get_qgv_points(struct drm_i915_private 
> *dev_priv,
>   for (i = 0; i < qi->num_points; i++) {
>   struct intel_qgv_point *sp = &qi->points[i];
>  
> - ret = icl_pcode_read_qgv_point_info(dev_priv, sp, i);
> + if (IS_DG1(dev_priv))
> + ret = dg1_mchbar_read_qgv_point_info(dev_priv, sp, i);
> + else
> + ret = icl_pcode_read_qgv_point_info(dev_priv, sp, i);
> +
>   if (ret)
>   return ret;
>  
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 65c155b14189..182190da3036 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -11063,6 +11063,7 @@ enum skl_power_gate {
>  #define SKL_MEMORY_FREQ_MULTIPLIER_HZ2
>  #define SKL_MC_BIOS_DATA_0_0_0_MCHBAR_PCU_MMIO(MCHBAR_MIRROR_BASE_SNB + 
> 0x5E04)
>  #define  SKL_REQ_DATA_MASK   (0xF << 0)
> +#define  DG1_GEAR_TYPE   REG_BIT(16)
>  
>  #define SKL_MAD_INTER_CHANNEL_0_0_0_MCHBAR_MCMAIN 
> _MMIO(MCHBAR_MIRROR_BASE_SNB + 0x5000)
>  #define  SKL_DRAM_DDR_TYPE_MASK  (0x3 << 0)
> @@ -11098,6 +11099,17 @@ enum skl_power_gate {
>  #define  CNL_DRAM_RANK_3 (0x2 << 9)
>  #define  CNL_DRAM_RANK_4 (0x3 << 9)
>  
> +#define SA_PERF_STATUS_0_0_0_MCHBAR_PC   
> _MMIO(MCHBAR_MIRROR_BASE_SNB + 0x5918)
> +#define  DG1_QCLK_RATIO_MASK REG_GENMASK(9, 2)
> +#define  DG1_QCLK_REFERENCE  REG_BIT(10)
> +
> +#define MCHBAR_CH0_CR_TC_PRE_0_0_0_MCHBAR_MMIO(MCHBAR_MIRROR_BASE_SNB + 
> 0x4000)
> +#define   DG1_DRAM_T_RDPRE_MASK  REG_GENMASK(16, 11)
> +#define   DG1_DRAM_T_RP_MASK REG_GENMASK(6, 0)
> +#define MCHBAR_CH0_CR_TC_PRE_0_0_0_MCHBAR_HIGH   
> _MMIO(MCHBAR_MIRROR_BASE_SNB + 0x4

Re: [Intel-gfx] [PATCH 47/47] drm/i915/guc: Unblock GuC submission on Gen11+

[Daniel Vetter]

On Thu, Jul 1, 2021 at 8:27 PM Martin Peres  wrote:
>
> On 01/07/2021 11:14, Pekka Paalanen wrote:
> > On Wed, 30 Jun 2021 11:58:25 -0700
> > John Harrison  wrote:
> >
> >> On 6/30/2021 01:22, Martin Peres wrote:
> >>> On 24/06/2021 10:05, Matthew Brost wrote:
>  From: Daniele Ceraolo Spurio 
> 
>  Unblock GuC submission on Gen11+ platforms.
> 
>  Signed-off-by: Michal Wajdeczko 
>  Signed-off-by: Daniele Ceraolo Spurio 
>  Signed-off-by: Matthew Brost 
>  ---
> drivers/gpu/drm/i915/gt/uc/intel_guc.h|  1 +
> drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c |  8 
> drivers/gpu/drm/i915/gt/uc/intel_guc_submission.h |  3 +--
> drivers/gpu/drm/i915/gt/uc/intel_uc.c | 14 +-
> 4 files changed, 19 insertions(+), 7 deletions(-)
> 
> >
> > ...
> >
>  diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
>  b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
>  index 7a69c3c027e9..61be0aa81492 100644
>  --- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
>  +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
>  @@ -34,8 +34,15 @@ static void uc_expand_default_options(struct
>  intel_uc *uc)
> return;
> }
> -/* Default: enable HuC authentication only */
>  -i915->params.enable_guc = ENABLE_GUC_LOAD_HUC;
>  +/* Intermediate platforms are HuC authentication only */
>  +if (IS_DG1(i915) || IS_ALDERLAKE_S(i915)) {
>  +drm_dbg(&i915->drm, "Disabling GuC only due to old
>  platform\n");
> >>>
> >>> This comment does not seem accurate, given that DG1 is barely out, and
> >>> ADL is not out yet. How about:
> >>>
> >>> "Disabling GuC on untested platforms"?
> >>>
> >> Just because something is not in the shops yet does not mean it is new.
> >> Technology is always obsolete by the time it goes on sale.
> >
> > That is a very good reason to not use terminology like "new", "old",
> > "current", "modern" etc. at all.
> >
> > End users like me definitely do not share your interpretation of "old".
>
> Yep, old and new is relative. In the end, what matters is the validation
> effort, which is why I was proposing "untested platforms".
>
> Also, remember that you are not writing these messages for Intel
> engineers, but instead are writing for Linux *users*.

It's drm_dbg. Users don't read this stuff, at least not users with no
clue what the driver does and stuff like that.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PULL] drm-intel-next-fixes

[Rodrigo Vivi]

On Thu, Jul 01, 2021 at 11:57:53AM +0300, Jani Nikula wrote:
> On Wed, 30 Jun 2021, Rodrigo Vivi  wrote:
> > On Wed, Jun 30, 2021 at 01:05:35PM +0300, Jani Nikula wrote:
> >> On Tue, 29 Jun 2021, Rodrigo Vivi  wrote:
> >> > Hi Dave and Daniel,
> >> >
> >> > Here goes drm-intel-next-fixes-2021-06-29:
> >> >
> >> > The biggest fix is the restoration of mmap ioctl for gen12 integrated 
> >> > parts
> >> > which lack was breaking ADL-P with media stack.
> >> > Besides that a small selftest fix and a theoretical overflow on
> >> > i915->pipe_to_crtc_mapping.
> >> 
> >> My last fixes pull for v5.13 fell between the cracks [1]. There was one
> >> stable worthy fix, but since it was still in drm-intel-fixes when you
> >> ran dim cherry-pick-next-fixes, it was skipped for drm-intel-next-fixes.
> >> 
> >> I've now dropped the commit and pushed v5.13 to drm-intel-fixes, as
> >> we're past that point. Subsequent dim cherry-pick-next-fixes should pick
> >> it up now.
> >
> > it didn't, probably because the Fixes hash not being part of the drm-next 
> > yet?!
> 
> Odd, should be.

indeed...

> 
> > I can cherry-pick that directly. Please let me know the commit id.
> 
> c88e2647c5bb ("drm/i915/display: Do not zero past infoframes.vsc")

pushed to drm-intel-next-queue... will wait for CI results and send another PR.
I hope there's still time, otherwise it can wait for the -fixes flow

> 
> Thanks,
> Jani.
> 
> 
> >
> > Thanks,
> > Rodrigo.
> >
> >> 
> >> Please do another next fixes pull request with that. (It's okay to pull
> >> this one already though, doesn't make a difference.)
> >> 
> >> 
> >> BR,
> >> Jani.
> >> 
> >> 
> >> [1] https://lore.kernel.org/r/87czsbu15r@intel.com
> >> 
> >> 
> >> 
> >> >
> >> > Thanks,
> >> > Rodrigo.
> >> >
> >> > The following changes since commit 
> >> > 1bd8a7dc28c1c410f1ceefae1f2a97c06d1a67c2:
> >> >
> >> >   Merge tag 'exynos-drm-next-for-v5.14' of 
> >> > git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into 
> >> > drm-next (2021-06-11 14:19:12 +1000)
> >> >
> >> > are available in the Git repository at:
> >> >
> >> >   git://anongit.freedesktop.org/drm/drm-intel 
> >> > tags/drm-intel-next-fixes-2021-06-29
> >> >
> >> > for you to fetch changes up to c90c4c6574f3feaf2203b5671db1907a1e15c653:
> >> >
> >> >   drm/i915: Reinstate the mmap ioctl for some platforms (2021-06-28 
> >> > 07:43:56 -0400)
> >> >
> >> > 
> >> > The biggest fix is the restoration of mmap ioctl for gen12 integrated 
> >> > parts
> >> > which lack was breaking ADL-P with media stack.
> >> > Besides that a small selftest fix and a theoretical overflow on
> >> > i915->pipe_to_crtc_mapping.
> >> >
> >> > 
> >> > Chris Wilson (1):
> >> >   drm/i915/selftests: Reorder tasklet_disable vs local_bh_disable
> >> >
> >> > Jani Nikula (1):
> >> >   drm/i915/dsc: abstract helpers to get bigjoiner primary/secondary 
> >> > crtc
> >> >
> >> > Thomas Hellström (1):
> >> >   drm/i915: Reinstate the mmap ioctl for some platforms
> >> >
> >> >  drivers/gpu/drm/i915/display/intel_display.c   |  7 ++-
> >> >  drivers/gpu/drm/i915/display/intel_display_types.h |  8 
> >> >  drivers/gpu/drm/i915/display/intel_vdsc.c  | 40 +++-
> >> >  drivers/gpu/drm/i915/display/intel_vdsc.h  |  1 +
> >> >  drivers/gpu/drm/i915/gem/i915_gem_mman.c   |  7 +--
> >> >  drivers/gpu/drm/i915/gt/selftest_execlists.c   | 55 
> >> > +-
> >> >  6 files changed, 76 insertions(+), 42 deletions(-)
> >> 
> >> -- 
> >> Jani Nikula, Intel Open Source Graphics Center
> 
> -- 
> Jani Nikula, Intel Open Source Graphics Center
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 0/2] Stepping/substepping reorg for DMC

[Anusha Srivatsa]

This series addresses the following:
1. Add missing stepping/substepping info for all platforms.
2. Use RUNTIME_INFO->step to grab the actual stepping info
for a platform instead of having separate lookup tables
for each platform on DMC side.

Anusha Srivatsa (2):
  drm/i915/dmc: Use RUNTIME_INFO->step for DMC
  drm/i915/dmc: Add steping info table for remaining platforms

 drivers/gpu/drm/i915/display/intel_dmc.c | 117 +++
 drivers/gpu/drm/i915/intel_step.c|  69 +
 drivers/gpu/drm/i915/intel_step.h|   7 ++
 3 files changed, 154 insertions(+), 39 deletions(-)

-- 
2.32.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 2/2] drm/i915/dmc: Add steping info table for remaining platforms

[Anusha Srivatsa]

intel_step.c has stepping_info for  most platforms. With DMC using
display_step from here, lets add the info for all older platforms
as well

Cc: Lucas De Marchi 
Signed-off-by: Anusha Srivatsa 
---
 drivers/gpu/drm/i915/intel_step.c | 28 
 1 file changed, 28 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_step.c 
b/drivers/gpu/drm/i915/intel_step.c
index c8542161c5d0..d8f5ef9ac158 100644
--- a/drivers/gpu/drm/i915/intel_step.c
+++ b/drivers/gpu/drm/i915/intel_step.c
@@ -38,6 +38,13 @@ static const struct intel_step_info skl_revid_step_tbl[] = {
[9] = { .gt_step = STEP_J0, .display_step = STEP_J0 },
 };
 
+static const struct intel_step_info glk_revid_step_tbl[] = {
+   [0] = { .gt_step = STEP_A0, .display_step = STEP_A0 },
+   [1] = { .gt_step = STEP_A1, .display_step = STEP_A1 },
+   [2] = { .gt_step = STEP_A2, .display_step = STEP_A2 },
+   [3] = { .gt_step = STEP_B0, .display_step = STEP_B0 },
+};
+
 static const struct intel_step_info icl_revid_step_tbl[] = {
[0] = { .gt_step = STEP_A0, .display_step = STEP_A0 },
[3] = { .gt_step = STEP_B0, .display_step = STEP_B0 },
@@ -71,6 +78,18 @@ static const struct intel_step_info tgl_revid_step_tbl[] = {
[1] = { .gt_step = STEP_B0, .display_step = STEP_D0 },
 };
 
+static const struct intel_step_info dg1_revid_step_tbl[] = {
+   [0x0] = { .gt_step = STEP_A0, .display_step = STEP_A0 },
+   [0x1] = { .gt_step = STEP_B0, .display_step = STEP_B0 },
+};
+
+static const struct intel_step_info rkl_revid_step_tbl[] = {
+   [0x0] = { .gt_step = STEP_A0, .display_step = STEP_A0 },
+   [0x1] = { .gt_step = STEP_B0, .display_step = STEP_B0 },
+   [0x4] = { .gt_step = STEP_C0, .display_step = STEP_C0 },
+
+};
+
 static const struct intel_step_info adls_revid_step_tbl[] = {
[0x0] = { .gt_step = STEP_A0, .display_step = STEP_A0 },
[0x1] = { .gt_step = STEP_A0, .display_step = STEP_A2 },
@@ -99,6 +118,12 @@ void intel_step_init(struct drm_i915_private *i915)
} else if (IS_ALDERLAKE_S(i915)) {
revids = adls_revid_step_tbl;
size = ARRAY_SIZE(adls_revid_step_tbl);
+   } else if (IS_ROCKETLAKE(i915)) {
+   revids = rkl_revid_step_tbl;
+   size = ARRAY_SIZE(rkl_revid_step_tbl);
+   } else if (IS_DG1(i915)) {
+   revids = dg1_revid_step_tbl;
+   size = ARRAY_SIZE(dg1_revid_step_tbl);
} else if (IS_TGL_U(i915) || IS_TGL_Y(i915)) {
revids = tgl_uy_revid_step_tbl;
size = ARRAY_SIZE(tgl_uy_revid_step_tbl);
@@ -111,6 +136,9 @@ void intel_step_init(struct drm_i915_private *i915)
} else if (IS_ICELAKE(i915)) {
revids = icl_revid_step_tbl;
size = ARRAY_SIZE(icl_revid_step_tbl);
+   } else if (IS_GEMINILAKE(i915)) {
+   revids = glk_revid_step_tbl;
+   size = ARRAY_SIZE(glk_revid_step_tbl);
} else if (IS_SKYLAKE(i915)) {
revids = skl_revid_step_tbl;
size = ARRAY_SIZE(skl_revid_step_tbl);
-- 
2.32.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/2] drm/i915/dmc: Use RUNTIME_INFO->step for DMC

[Anusha Srivatsa]

On the dmc side,we maintain a lookup table with different display
stepping-substepping combinations.

Instead of adding new table for every new platform, lets ues
the stepping info from RUNTIME_INFO(dev_priv)->step

v2: Add stepping table for older platforms in intel_step.c (Lucas)

Cc: Lucas De Marchi 
Signed-off-by: Anusha Srivatsa 
---
 drivers/gpu/drm/i915/display/intel_dmc.c | 117 +++
 drivers/gpu/drm/i915/intel_step.c|  41 
 drivers/gpu/drm/i915/intel_step.h|   7 ++
 3 files changed, 126 insertions(+), 39 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c 
b/drivers/gpu/drm/i915/display/intel_dmc.c
index f8789d4543bf..df888a3d086e 100644
--- a/drivers/gpu/drm/i915/display/intel_dmc.c
+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
@@ -247,50 +247,89 @@ bool intel_dmc_has_payload(struct drm_i915_private *i915)
return i915->dmc.dmc_info[DMC_FW_MAIN].payload;
 }
 
-static const struct stepping_info skl_stepping_info[] = {
-   {'A', '0'}, {'B', '0'}, {'C', '0'},
-   {'D', '0'}, {'E', '0'}, {'F', '0'},
-   {'G', '0'}, {'H', '0'}, {'I', '0'},
-   {'J', '0'}, {'K', '0'}
-};
-
-static const struct stepping_info bxt_stepping_info[] = {
-   {'A', '0'}, {'A', '1'}, {'A', '2'},
-   {'B', '0'}, {'B', '1'}, {'B', '2'}
-};
-
-static const struct stepping_info icl_stepping_info[] = {
-   {'A', '0'}, {'A', '1'}, {'A', '2'},
-   {'B', '0'}, {'B', '2'},
-   {'C', '0'}
-};
-
 static const struct stepping_info no_stepping_info = { '*', '*' };
+struct stepping_info *display_step;
 
-static const struct stepping_info *
+static struct stepping_info *
 intel_get_stepping_info(struct drm_i915_private *dev_priv)
 {
-   const struct stepping_info *si;
-   unsigned int size;
-
-   if (IS_ICELAKE(dev_priv)) {
-   size = ARRAY_SIZE(icl_stepping_info);
-   si = icl_stepping_info;
-   } else if (IS_SKYLAKE(dev_priv)) {
-   size = ARRAY_SIZE(skl_stepping_info);
-   si = skl_stepping_info;
-   } else if (IS_BROXTON(dev_priv)) {
-   size = ARRAY_SIZE(bxt_stepping_info);
-   si = bxt_stepping_info;
-   } else {
-   size = 0;
-   si = NULL;
+   struct intel_step_info step = RUNTIME_INFO(dev_priv)->step;
+
+   switch (step.display_step) {
+   case STEP_A0:
+   display_step->stepping = 'A';
+   display_step->substepping = '0';
+   break;
+   case STEP_A1:
+   display_step->stepping = 'A';
+   display_step->substepping = '1';
+   break;
+   case STEP_A2:
+   display_step->stepping = 'A';
+   display_step->substepping = '2';
+   break;
+   case STEP_B0:
+   display_step->stepping = 'B';
+   display_step->substepping = '0';
+   break;
+   case STEP_B1:
+   display_step->stepping = 'B';
+   display_step->substepping = '1';
+   break;
+   case STEP_B2:
+   display_step->stepping = 'B';
+   display_step->substepping = '2';
+   break;
+   case STEP_C0:
+   display_step->stepping = 'C';
+   display_step->substepping = '0';
+   break;
+   case STEP_C1:
+   display_step->stepping = 'C';
+   display_step->substepping = '1';
+   break;
+   case STEP_D0:
+   display_step->stepping = 'D';
+   display_step->substepping = '0';
+   break;
+   case STEP_D1:
+   display_step->stepping = 'D';
+   display_step->substepping = '1';
+   break;
+   case STEP_E0:
+   display_step->stepping = 'E';
+   display_step->substepping = '0';
+   break;
+   case STEP_F0:
+   display_step->stepping = 'F';
+   display_step->substepping = '0';
+   break;
+   case STEP_G0:
+   display_step->stepping = 'G';
+   display_step->substepping = '0';
+   break;
+   case STEP_H0:
+   display_step->stepping = 'H';
+   display_step->substepping = '0';
+   break;
+   case STEP_I0:
+   display_step->stepping = 'I';
+   display_step->substepping = '0';
+   break;
+   case STEP_J0:
+   display_step->stepping = 'J';
+   display_step->substepping = '0';
+   break;
+   case STEP_K0:
+   display_step->stepping = 'K';
+   display_step->substepping = '0';
+   break;
+   default:
+   display_step->stepping = '*';
+   display_step->substepping = '*';
+   break;
}
-
-   if (INTEL_REVID(dev_priv) < size)
-   return si + INTEL_REVID(dev_priv);
-
-

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915/gem: Correct the locking and pin pattern for dma-buf

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915/gem: Correct the locking and pin 
pattern for dma-buf
URL   : https://patchwork.freedesktop.org/series/92117/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10299 -> Patchwork_20510


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_20510 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_20510, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20510/index.html

Possible new issues
---

  Here are the unknown changes that may have been introduced in Patchwork_20510:

### IGT changes ###

 Possible regressions 

  * igt@gem_exec_fence@basic-busy@rcs0:
- fi-pnv-d510:[PASS][1] -> [DMESG-WARN][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10299/fi-pnv-d510/igt@gem_exec_fence@basic-b...@rcs0.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20510/fi-pnv-d510/igt@gem_exec_fence@basic-b...@rcs0.html

  * igt@gem_exec_fence@basic-busy@vcs0:
- fi-ivb-3770:[PASS][3] -> [DMESG-WARN][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10299/fi-ivb-3770/igt@gem_exec_fence@basic-b...@vcs0.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20510/fi-ivb-3770/igt@gem_exec_fence@basic-b...@vcs0.html
- fi-elk-e7500:   [PASS][5] -> [DMESG-WARN][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10299/fi-elk-e7500/igt@gem_exec_fence@basic-b...@vcs0.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20510/fi-elk-e7500/igt@gem_exec_fence@basic-b...@vcs0.html
- fi-ilk-650: [PASS][7] -> [DMESG-WARN][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10299/fi-ilk-650/igt@gem_exec_fence@basic-b...@vcs0.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20510/fi-ilk-650/igt@gem_exec_fence@basic-b...@vcs0.html

  * igt@gem_exec_fence@basic-busy@vecs0:
- fi-apl-guc: [PASS][9] -> [DMESG-WARN][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10299/fi-apl-guc/igt@gem_exec_fence@basic-b...@vecs0.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20510/fi-apl-guc/igt@gem_exec_fence@basic-b...@vecs0.html
- fi-hsw-4770:[PASS][11] -> [DMESG-WARN][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10299/fi-hsw-4770/igt@gem_exec_fence@basic-b...@vecs0.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20510/fi-hsw-4770/igt@gem_exec_fence@basic-b...@vecs0.html
- fi-bxt-dsi: [PASS][13] -> [DMESG-WARN][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10299/fi-bxt-dsi/igt@gem_exec_fence@basic-b...@vecs0.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20510/fi-bxt-dsi/igt@gem_exec_fence@basic-b...@vecs0.html
- fi-skl-6700k2:  [PASS][15] -> [DMESG-WARN][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10299/fi-skl-6700k2/igt@gem_exec_fence@basic-b...@vecs0.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20510/fi-skl-6700k2/igt@gem_exec_fence@basic-b...@vecs0.html
- fi-cfl-8700k:   [PASS][17] -> [DMESG-WARN][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10299/fi-cfl-8700k/igt@gem_exec_fence@basic-b...@vecs0.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20510/fi-cfl-8700k/igt@gem_exec_fence@basic-b...@vecs0.html
- fi-bsw-n3050:   [PASS][19] -> [DMESG-WARN][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10299/fi-bsw-n3050/igt@gem_exec_fence@basic-b...@vecs0.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20510/fi-bsw-n3050/igt@gem_exec_fence@basic-b...@vecs0.html
- fi-kbl-soraka:  [PASS][21] -> [DMESG-WARN][22]
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10299/fi-kbl-soraka/igt@gem_exec_fence@basic-b...@vecs0.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20510/fi-kbl-soraka/igt@gem_exec_fence@basic-b...@vecs0.html
- fi-cml-s:   [PASS][23] -> [DMESG-WARN][24]
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10299/fi-cml-s/igt@gem_exec_fence@basic-b...@vecs0.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20510/fi-cml-s/igt@gem_exec_fence@basic-b...@vecs0.html
- fi-bsw-kefka:   NOTRUN -> [DMESG-WARN][25]
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20510/fi-bsw-kefka/igt@gem_exec_fence@basic-b...@vecs0.html
- fi-glk-dsi: [PASS][26] -> [DMESG-WARN][27]
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10299/fi-glk-dsi/igt@gem_exec_fence@basic-b...@vecs0.html
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20510/fi-glk-dsi/igt@gem