Re: [Intel-gfx] [PATCH i-g-t] lib/drmtest: make DRIVER_ANY match any driver
On Mon, Jan 30, 2017 at 12:18:07PM +, Eric Engestrom wrote: > On Monday, 2017-01-30 11:50:52 +, Daniel Stone wrote: > > Hi, > > > > On 30 January 2017 at 11:46, Petri Latvala wrote: > > > NAK. > > > > > > DRIVER_VGEM is omitted from DRIVER_ANY intentionally. Vgem is unable > > > to modeset, unable to render, practically it only supports the > > > vgem-specific tests. See also: lib/drmtest.c, __drm_open_driver(). > > > > Yeah, I agree with this. It's mostly just there as an auxiliary > > helper. Opening DRIVER_ANY to vgem means that, if you run on a system > > with vgem as well as a supported driver, you can end up with a > > near-100% skip rate if you don't explicitly specify the device, > > depending on device-load ordering. > > > > Cheers, > > Daniel > > OK. This should probably be documented then (a simple comment next to > the #define would go a long way), so that the next guy who see this > doesn't make the same mistake I did :) Maybe we should rename it to DRIVER_ANY_KMS, and check in the open function that there's at least 1 plane/crtc/encoder/connector there and otherwise skip? I think that would be even better than documenting it, since it'd also catch e.g. tegra+nouveau systems. -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] Broken DPMS with DisplayPort on CHV (also BYT?)
Hi Takashi
How is the test kernel ? Just wonder when Sridhara team can test again.
Regards
Jeffrey
>>> Takashi Iwai 2017/1/27 下午 18:29 >>>On Thu, 26 Jan 2017
>>> 15:19:44 +0100,
Takashi Iwai wrote:
>
> On Thu, 26 Jan 2017 14:58:55 +0100,
> Ville Syrjälä wrote:
> >
> > Hmm. Have you tried 9f2bdb006a7e ("drm/i915: Prevent PPS stealing
> > from a normal DP port on VLV/CHV") ?
>
> No, it's not tested. I'll prepare a test kernel with it.
Sridhara reported that my backport didn't help, unfortunately.
But it was a backport, so I might have missed something.
To be sure, I'll try to build a kernel from drm-intel-nightly, and let
them test again.
thanks,
Takashi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH RFC] drm/i915: reduce cursor size for GEN5 hardware
From: Chris Wilson
As the introduced comment admits this is clearly a workaround, but for
me this is the only known way to make my Lenovo X201 work without
flickering and crashing.
Signed-off-by: Uwe Kleine-König
[uwe: added changelog, comment and restrict to GEN5]
---
Hello,
as I don't like having to compile my own kernel (which has this workaround) I
suggest to apply this patch until someone with more knowledge than me about
i915 finds the muse and time to work on this.
If applying this patch means that I will become i915 maintainer, then please
don't apply; I'm not ready for this :-)
Best regards
Uwe
drivers/gpu/drm/i915/intel_display.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index f0b9aa7a0483..126825c207b3 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -16488,6 +16488,17 @@ int intel_modeset_init(struct drm_device *dev)
} else if (IS_GEN2(dev_priv)) {
dev->mode_config.cursor_width = GEN2_CURSOR_WIDTH;
dev->mode_config.cursor_height = GEN2_CURSOR_HEIGHT;
+ } else if (IS_GEN5(dev_priv)) {
+ /*
+* actually the hardware should be capable to handle
+* MAX_CURSOR_{WIDTH,HEIGHT} (i.e. 256), but on some GEN 5
+* hardware this results in fifo underruns, occasional
+* hardware lockups and display artifacts.
+* See https://bugs.freedesktop.org/show_bug.cgi?id=98742 for
+* more details.
+*/
+ dev->mode_config.cursor_width = 64;
+ dev->mode_config.cursor_height = 64;
} else {
dev->mode_config.cursor_width = MAX_CURSOR_WIDTH;
dev->mode_config.cursor_height = MAX_CURSOR_HEIGHT;
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Broken DPMS with DisplayPort on CHV (also BYT?)
Hi Takashi
Thanks a lot.
---
Hi Sridhara
Can you please try the test kernel ?
Regards
Jeffrey
>>> Takashi Iwai 2017/1/31 下午 13:49 >>>On Tue, 31 Jan 2017
>>> 03:34:23 +0100,
Jeffrey Cheung wrote:
>
> Hi Takashi
>
> How is the test kernel ? Just wonder when Sridhara team can test again.
I already informed it in bugzilla and waiting for the test result...
http://bugzilla.suse.com/show_bug.cgi?id=1019061#c35
It's found in
http://download.opensuse.org/repositories/home:/tiwai:/bnc1019061-3/standard/
Takashi
>
> Regards
>
> Jeffrey
>
> >>> Takashi Iwai 2017/1/27 下午 18:29 >>>On Thu, 26 Jan 2017
> >>> 15:19:44 +0100,
> Takashi Iwai wrote:
> >
> > On Thu, 26 Jan 2017 14:58:55 +0100,
> > Ville Syrjälä wrote:
> > >
> > > Hmm. Have you tried 9f2bdb006a7e ("drm/i915: Prevent PPS stealing
> > > from a normal DP port on VLV/CHV") ?
> >
> > No, it's not tested. I'll prepare a test kernel with it.
>
> Sridhara reported that my backport didn't help, unfortunately.
>
> But it was a backport, so I might have missed something.
> To be sure, I'll try to build a kernel from drm-intel-nightly, and let
> them test again.
>
>
> thanks,
>
> Takashi
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [GLK MIPI DSI V3 0/7] GLK MIPI DSI VIDEO MODE PATCHES
> -Original Message- > From: Chauhan, Madhav > Sent: Monday, January 2, 2017 6:24 PM > To: intel-gfx@lists.freedesktop.org > Cc: Nikula, Jani ; Shankar, Uma > ; Mukherjee, Indranil > ; Kamath, Sunil ; > Saarinen, Jani ; Conselvan De Oliveira, Ander > ; Konduru, Chandra > ; Kumar, Shobhit > ; Syrjala, Ville ; > Chauhan, Madhav > Subject: [GLK MIPI DSI V3 0/7] GLK MIPI DSI VIDEO MODE PATCHES > > The patches in this list enable MIPI DSI video mode support for GLK platform. > Tesed locally. > v2: Renamed bitfields macros as per review comments(Jani) > v3: Code alignment/abstraction as per arch (Jani review comments) > Found one issue in the MIPI DSI disable sequence during the testing. Working on fix. Will be able to publish the next series having fix and Jani review comments for couple of patches. > Deepak M (7): > drm/i915/glk: Program dphy param reg for GLK > drm/i915/glk: Program new MIPI DSI PHY registers for GLK > drm/i915/glk: Add MIPIIO Enable/disable sequence > drm/i915: Set the Z inversion overlap field > drm/i915/glk: Add DSI PLL divider range for glk > drm/i915i/glk: Program MIPI_CLOCK_CTRL only for BXT > drm/i915/glk: Program txesc clock divider for GLK > > drivers/gpu/drm/i915/i915_reg.h| 17 +++ > drivers/gpu/drm/i915/intel_dsi.c | 207 > - > drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 33 - > drivers/gpu/drm/i915/intel_dsi_pll.c | 106 --- > 4 files changed, 332 insertions(+), 31 deletions(-) > > -- > 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/docs: Fix documentation for drm_atomic_set_mode_for_crtc
On Mon, Jan 30, 2017 at 10:18:38PM -0800, Dhinakaran Pandiyan wrote: > drm_atomic_set_mode_for_crtc() modifies the .enable member of CRTC state > but documentation claims otherwise, fix that. > > Signed-off-by: Dhinakaran Pandiyan Indeed, thanks for the fix, applied to drm-misc. -Daniel > --- > drivers/gpu/drm/drm_atomic.c | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c > index 78b54df..25944ab 100644 > --- a/drivers/gpu/drm/drm_atomic.c > +++ b/drivers/gpu/drm/drm_atomic.c > @@ -322,9 +322,8 @@ static s32 __user *get_out_fence_for_crtc(struct > drm_atomic_state *state, > * @state: the CRTC whose incoming state to update > * @mode: kernel-internal mode to use for the CRTC, or NULL to disable > * > - * Set a mode (originating from the kernel) on the desired CRTC state. Does > - * not change any other state properties, including enable, active, or > - * mode_changed. > + * Set a mode (originating from the kernel) on the desired CRTC state and > update > + * the enable property. > * > * RETURNS: > * Zero on success, error code on failure. Cannot return -EDEADLK. > -- > 2.7.4 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] lRE: Broken DPMS with DisplayPort on CHV (also BYT?)
Ok, look like we have improvement of using the drm-intel-nightly tree kernel.
Hi takashi and ville, any clue of the single dell e type monitor ?
Regards
Jeffrey
>>> 2017/1/31 下午 15:36 >>>Hi,
Installed RPM,
Issue still present with Single Dell E- Series monitor (Display doesn't appear )
Issue not observed with Dual Dell E-Series monitor.
Sleep issue not observed.
Thanks
Sridhar
-Original Message-
From: Jeffrey Cheung [mailto:jche...@suse.com]
Sent: Tuesday, January 31, 2017 11:39 AM
To: ti...@suse.de
Cc: Venkatanara, Sridhara ;
angus.c...@intel.com; ray@intel.com; ville.syrj...@linux.intel.com;
intel-gfx@lists.freedesktop.org; mma...@suse.cz
Subject: Re: [Intel-gfx] Broken DPMS with DisplayPort on CHV (also BYT?)
Hi Takashi
Thanks a lot.
---
Hi Sridhara
Can you please try the test kernel ?
Regards
Jeffrey
>>> Takashi Iwai 2017/1/31 下午 13:49 >>>On Tue, 31 Jan
>>> 2017 03:34:23 +0100,
Jeffrey Cheung wrote:
>
> Hi Takashi
>
> How is the test kernel ? Just wonder when Sridhara team can test again.
I already informed it in bugzilla and waiting for the test result...
http://bugzilla.suse.com/show_bug.cgi?id=1019061#c35
It's found in
http://download.opensuse.org/repositories/home:/tiwai:/bnc1019061-3/standard/
Takashi
>
> Regards
>
> Jeffrey
>
> >>> Takashi Iwai 2017/1/27 下午 18:29 >>>On Thu, 26 Jan
> >>> 2017 15:19:44 +0100,
> Takashi Iwai wrote:
> >
> > On Thu, 26 Jan 2017 14:58:55 +0100,
> > Ville Syrjälä wrote:
> > >
> > > Hmm. Have you tried 9f2bdb006a7e ("drm/i915: Prevent PPS stealing
> > > from a normal DP port on VLV/CHV") ?
> >
> > No, it's not tested. I'll prepare a test kernel with it.
>
> Sridhara reported that my backport didn't help, unfortunately.
>
> But it was a backport, so I might have missed something.
> To be sure, I'll try to build a kernel from drm-intel-nightly, and let
> them test again.
>
>
> thanks,
>
> Takashi
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH RFC] drm/i915: reduce cursor size for GEN5 hardware
Op 31-01-17 om 09:09 schreef Uwe Kleine-König: > From: Chris Wilson > > As the introduced comment admits this is clearly a workaround, but for > me this is the only known way to make my Lenovo X201 work without > flickering and crashing. > > Signed-off-by: Uwe Kleine-König > [uwe: added changelog, comment and restrict to GEN5] > --- > Hello, > > as I don't like having to compile my own kernel (which has this workaround) I > suggest to apply this patch until someone with more knowledge than me about > i915 finds the muse and time to work on this. > > If applying this patch means that I will become i915 maintainer, then please > don't apply; I'm not ready for this :-) > > Best regards > Uwe Just curious, does this help? diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index ae2c0bb4b2e8..13de4c526ca6 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -1838,7 +1838,7 @@ static uint32_t ilk_compute_cur_wm(const struct intel_crtc_state *cstate, * this is necessary to avoid flickering. */ int cpp = 4; - int width = pstate->base.visible ? pstate->base.crtc_w : 64; + int width = 256; if (!cstate->base.active) return 0; ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/3] drm/i915: Handle hanging during nonblocking modeset correctly.
Hey, Op 31-01-17 om 08:46 schreef Daniel Vetter: > On Mon, Jan 30, 2017 at 03:42:17PM +0100, Maarten Lankhorst wrote: >> Op 30-01-17 om 09:17 schreef Daniel Vetter: >>> On Fri, Jan 27, 2017 at 03:08:45PM +, Chris Wilson wrote: On Fri, Jan 27, 2017 at 03:58:08PM +0100, Daniel Vetter wrote: > On Fri, Jan 27, 2017 at 02:31:55PM +, Chris Wilson wrote: >> On Fri, Jan 27, 2017 at 03:21:29PM +0100, Daniel Vetter wrote: >>> On Fri, Jan 27, 2017 at 09:30:50AM +, Chris Wilson wrote: On Thu, Jan 26, 2017 at 04:59:21PM +0100, Maarten Lankhorst wrote: > When writing some testcases for nonblocking modesets. I found out > that the > infinite wait on the old fb was causing issues. The crux of the issue here is the locked wait for old dependencies and the inability to inject the intel_prepare_reset disabling of all planes. There are a couple of locked waits on struct_mutex within the modeset locks for intel_overlay and if we happen to be using the display plane for the first time. The first I suggested solving using fences to track dependencies and keep the order between atomic states. Cancelling the outstanding modesets, replacing with a disable and then on restore jumping to the final state look doable. It also requires avoiding the struct_mutex for disabling, which is quite easy. To avoid the wait under struct_mutex, we've talked about switching to mmio, but for starters we could move the wait from inside intel_overlay into the fence for the atomic operation. (But's that a little more surgery than we would like for intel_overlay I guess - dig out Ville's patches for overlay planes?) And to prevent the wait under struct_mutex for pin_to_display_plane, my plane is to move that to an async fenced operation that is then naturally waited upon by the atomic modeset. >>> A bit more a hack, but a different idea, and I think hack for gen234.0 >>> is >>> ok: >>> >>> We complete all the requests before we start the hw reset with >>> fence.error >>> = -EIO. But we do this only when we need to get at the display locks. A >>> slightly more elegant solution would be to trylock modeset locks, and if >>> one of them fails (and only then) complete all requests with -EIO to get >>> the concurrent modeset to proceed before we reset the hardware. That's >>> essentially the logic we had before all the reworks, and it worked. But >>> I >>> didn't look at how scary that all would be to make it work again ... >> The modeset lock may not just be waiting on our requests (even on pnv we >> can expect that there are already users celebrating that pnv+nouveau >> finally works ;) and that the display is not the only user/observer of >> those requests. Using the requests to break the modeset lock just feels >> like the wrong approach. > It's a cycle, and we need to break it somewhere. Another option might be > to break the cycle the same way we do it for gem locks: Wake up everyone > and restart the modeset ioctl. Since the trouble only happens for > synchronous modesets where we hold the locks while waiting for fences, we > can also break out of that and restart. And I also don't think that would > leak to other drivers, after all our gem locking restart dances also don't > leak to other drivers - it's just our own driver's lock which are affected > by these special wakupe semantics. It's a queue of nonblocking modesets that we need to worry about, afaik. Moving the wait for blocking modeset outside of modeset lock is easily achievable (and avoiding the other waits under both the modeset + struct_mutex I have at least an idea for). So the challenge is how to inject all-planes-off for gen3 and then allow the queue to continue again afterwards. >>> Hm right, I missed the nonblocking updates which don't take locks. But >>> assuming we do the display reset for gpu resets as a full modeset (i.e. >>> going through ->atomic_commit) it should still work out correctly: >>> >>> Starting state: gpu is hung, nonblocking modeset waiting for some requests >>> to complete. >> Missing one evil detail here, else things would have moved forward.. >> >> A unrelated thread performs a blocking commit, and holds all locks until the >> nonblocking modeset completes. > And where is the problem in that? If we first set all fences to -EIO, and > then try to grab locks, that other thread will be able to complete. After > all this scheme worked before we reworked the reset logic completely. True, but we probably still want to cap the timeout (patch 2) to prevent a deadlock when a fence on another driver misbehaves. And if we have a timeout, then things will move forward eventually even if
[Intel-gfx] [PATCH 1/2] drm/atomic: Unconditionally call prepare_fb.
Atomic drivers may set properties like rotation on the same fb, which
may require a call to prepare_fb even when framebuffer stays identical.
Instead of handling all the special cases in the core, let the driver
decide when prepare_fb and cleanup_fb are noops.
This is a revert of:
commit fcc60b413d14dd06ddbd79ec50e83c4fb2a097ba
Author: Keith Packard
Date: Sat Jun 4 01:16:22 2016 -0700
drm: Don't prepare or cleanup unchanging frame buffers [v3]
The original commit mentions that this prevents waiting in i915 on all
previous rendering during cursor updates, but there are better ways to
fix this.
Signed-off-by: Maarten Lankhorst
Acked-by: Laurent Pinchart
Signed-off-by: Daniel Vetter
Link:
http://patchwork.freedesktop.org/patch/msgid/6d82f9b6-9d16-91d1-d176-4a37b09af...@linux.intel.com
(cherry picked from commit 0532be078a207d7dd6ad26ebd0834e258acc4ee7)
---
drivers/gpu/drm/drm_atomic_helper.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 34f757bcabae..4594477dee00 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1666,9 +1666,6 @@ int drm_atomic_helper_prepare_planes(struct drm_device
*dev,
funcs = plane->helper_private;
- if (!drm_atomic_helper_framebuffer_changed(dev, state,
plane_state->crtc))
- continue;
-
if (funcs->prepare_fb) {
ret = funcs->prepare_fb(plane, plane_state);
if (ret)
@@ -1685,9 +1682,6 @@ int drm_atomic_helper_prepare_planes(struct drm_device
*dev,
if (j >= i)
continue;
- if (!drm_atomic_helper_framebuffer_changed(dev, state,
plane_state->crtc))
- continue;
-
funcs = plane->helper_private;
if (funcs->cleanup_fb)
@@ -1954,9 +1948,6 @@ void drm_atomic_helper_cleanup_planes(struct drm_device
*dev,
for_each_plane_in_state(old_state, plane, plane_state, i) {
const struct drm_plane_helper_funcs *funcs;
- if (!drm_atomic_helper_framebuffer_changed(dev, old_state,
plane_state->crtc))
- continue;
-
funcs = plane->helper_private;
if (funcs->cleanup_fb)
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Track pinned vma in intel_plane_state
From: Chris Wilson
With atomic plane states we are able to track an allocation right from
preparation, during use and through to the final free after being
swapped out for a new plane. We can couple the VMA we pin for the
framebuffer (and its rotation) to this lifetime and avoid all the clumsy
lookups in between.
v2: Remove residual vma on plane cleanup (Chris)
v3: Add a description for the vma destruction in
intel_plane_destroy_state (Maarten)
References: https://bugs.freedesktop.org/show_bug.cgi?id=98829
Signed-off-by: Chris Wilson
Signed-off-by: Maarten Lankhorst
Link:
http://patchwork.freedesktop.org/patch/msgid/20170116152131.18089-1-ch...@chris-wilson.co.uk
Acked-by: Joonas Lahtinen
(cherry picked from commit be1e341513ca23b0668b7b0f26fa6e2ffc46ba20)
---
drivers/gpu/drm/i915/i915_drv.h | 16 +---
drivers/gpu/drm/i915/intel_atomic_plane.c | 20 +
drivers/gpu/drm/i915/intel_display.c | 125 ++
drivers/gpu/drm/i915/intel_drv.h | 9 ++-
drivers/gpu/drm/i915/intel_fbc.c | 52 +
drivers/gpu/drm/i915/intel_fbdev.c| 4 +-
drivers/gpu/drm/i915/intel_sprite.c | 8 +-
7 files changed, 99 insertions(+), 135 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 69bc3b0c4390..8493e19b563a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1012,6 +1012,8 @@ struct intel_fbc {
struct work_struct underrun_work;
struct intel_fbc_state_cache {
+ struct i915_vma *vma;
+
struct {
unsigned int mode_flags;
uint32_t hsw_bdw_pixel_rate;
@@ -1025,15 +1027,14 @@ struct intel_fbc {
} plane;
struct {
- u64 ilk_ggtt_offset;
uint32_t pixel_format;
unsigned int stride;
- int fence_reg;
- unsigned int tiling_mode;
} fb;
} state_cache;
struct intel_fbc_reg_params {
+ struct i915_vma *vma;
+
struct {
enum pipe pipe;
enum plane plane;
@@ -1041,10 +1042,8 @@ struct intel_fbc {
} crtc;
struct {
- u64 ggtt_offset;
uint32_t pixel_format;
unsigned int stride;
- int fence_reg;
} fb;
int cfb_size;
@@ -3168,13 +3167,6 @@ i915_gem_object_to_ggtt(struct drm_i915_gem_object *obj,
return i915_gem_obj_to_vma(obj, &to_i915(obj->base.dev)->ggtt.base,
view);
}
-static inline unsigned long
-i915_gem_object_ggtt_offset(struct drm_i915_gem_object *o,
- const struct i915_ggtt_view *view)
-{
- return i915_ggtt_offset(i915_gem_object_to_ggtt(o, view));
-}
-
/* i915_gem_fence_reg.c */
int __must_check i915_vma_get_fence(struct i915_vma *vma);
int __must_check i915_vma_put_fence(struct i915_vma *vma);
diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c
b/drivers/gpu/drm/i915/intel_atomic_plane.c
index dbe9fb41ae53..8d3e515f27ba 100644
--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
@@ -85,6 +85,8 @@ intel_plane_duplicate_state(struct drm_plane *plane)
__drm_atomic_helper_plane_duplicate_state(plane, state);
+ intel_state->vma = NULL;
+
return state;
}
@@ -100,6 +102,24 @@ void
intel_plane_destroy_state(struct drm_plane *plane,
struct drm_plane_state *state)
{
+ struct i915_vma *vma;
+
+ vma = fetch_and_zero(&to_intel_plane_state(state)->vma);
+
+ /*
+* FIXME: Normally intel_cleanup_plane_fb handles destruction of vma.
+* We currently don't clear all planes during driver unload, so we have
+* to be able to unpin vma here for now.
+*
+* Normally this can only happen during unload when kmscon is disabled
+* and userspace doesn't attempt to set a framebuffer at all.
+*/
+ if (vma) {
+ mutex_lock(&plane->dev->struct_mutex);
+ intel_unpin_fb_vma(vma);
+ mutex_unlock(&plane->dev->struct_mutex);
+ }
+
drm_atomic_helper_plane_destroy_state(plane, state);
}
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index f0b9aa7a0483..f1e4a21d4664 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2235,27 +2235,22 @@ intel_pin_and_fence_fb_obj(struct drm_framebuffer *fb,
unsigned int rotation)
i915_vma_pin_fence(vma);
}
+ i915_vma_get(vma);
err:
intel_runtime_pm_put(dev_priv);
return vma;
}
-void intel_unpin_fb_obj(struct drm_framebuffer *fb, unsig
[Intel-gfx] [PATCH 0/2] drm/i915: Backport vma fixes for 4.10-rc6
With atomic plane states we are able to track an allocation right from preparation, during use and through to the final free after being swapped out for a new plane. We can couple the VMA we pin for the framebuffer (and its rotation) to this lifetime and avoid all the clumsy lookups in between. This is marked for rc6 because it seems the issue is triggerable on mainline and resulting in an oops. The backport also requires a preparation patch, which is required because otherwise the vma is not always populated and then we dereference a null pointer. References: https://bugs.freedesktop.org/show_bug.cgi?id=98829 Chris Wilson (1): drm/i915: Track pinned vma in intel_plane_state Maarten Lankhorst (1): drm/atomic: Unconditionally call prepare_fb. drivers/gpu/drm/drm_atomic_helper.c | 9 --- drivers/gpu/drm/i915/i915_drv.h | 16 +--- drivers/gpu/drm/i915/intel_atomic_plane.c | 20 + drivers/gpu/drm/i915/intel_display.c | 125 ++ drivers/gpu/drm/i915/intel_drv.h | 9 ++- drivers/gpu/drm/i915/intel_fbc.c | 52 + drivers/gpu/drm/i915/intel_fbdev.c| 4 +- drivers/gpu/drm/i915/intel_sprite.c | 8 +- 8 files changed, 99 insertions(+), 144 deletions(-) -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: reduce cursor size for GEN5 hardware
== Series Details == Series: drm/i915: reduce cursor size for GEN5 hardware URL : https://patchwork.freedesktop.org/series/18822/ State : warning == Summary == Series 18822v1 drm/i915: reduce cursor size for GEN5 hardware https://patchwork.freedesktop.org/api/1.0/series/18822/revisions/1/mbox/ Test kms_flip: Subgroup basic-flip-vs-wf_vblank: dmesg-warn -> PASS (fi-snb-2520m) Test kms_force_connector_basic: Subgroup force-connector-state: dmesg-warn -> PASS (fi-snb-2520m) Test kms_pipe_crc_basic: Subgroup nonblocking-crc-pipe-a: dmesg-warn -> PASS (fi-snb-2520m) Test prime_vgem: Subgroup basic-fence-flip: pass -> DMESG-WARN (fi-skl-6770hq) fi-bdw-5557u total:246 pass:232 dwarn:0 dfail:0 fail:0 skip:14 fi-bsw-n3050 total:246 pass:207 dwarn:0 dfail:0 fail:0 skip:39 fi-bxt-j4205 total:246 pass:224 dwarn:0 dfail:0 fail:0 skip:22 fi-bxt-t5700 total:78 pass:65 dwarn:0 dfail:0 fail:0 skip:12 fi-byt-j1900 total:246 pass:219 dwarn:0 dfail:0 fail:0 skip:27 fi-byt-n2820 total:246 pass:215 dwarn:0 dfail:0 fail:0 skip:31 fi-hsw-4770 total:246 pass:227 dwarn:0 dfail:0 fail:0 skip:19 fi-hsw-4770r total:246 pass:227 dwarn:0 dfail:0 fail:0 skip:19 fi-ivb-3520m total:246 pass:225 dwarn:0 dfail:0 fail:0 skip:21 fi-ivb-3770 total:246 pass:225 dwarn:0 dfail:0 fail:0 skip:21 fi-kbl-7500u total:246 pass:223 dwarn:0 dfail:0 fail:2 skip:21 fi-skl-6260u total:246 pass:233 dwarn:0 dfail:0 fail:0 skip:13 fi-skl-6700hqtotal:246 pass:226 dwarn:0 dfail:0 fail:0 skip:20 fi-skl-6700k total:246 pass:221 dwarn:4 dfail:0 fail:0 skip:21 fi-skl-6770hqtotal:246 pass:232 dwarn:1 dfail:0 fail:0 skip:13 fi-snb-2520m total:246 pass:215 dwarn:0 dfail:0 fail:0 skip:31 fi-snb-2600 total:246 pass:214 dwarn:0 dfail:0 fail:0 skip:32 123d798c350471aba7e0625c154c6d9e395756c8 drm-tip: 2017y-01m-30d-21h-14m-37s UTC integration manifest 2ed3050 drm/i915: reduce cursor size for GEN5 hardware == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3649/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/atomic: Fix double free in drm_atomic_state_default_clear
drm_atomic_helper_page_flip and drm_atomic_ioctl set their own events
in crtc_state->event. But when it's set the event is freed in 2 places.
Solve this by only freeing the event in the atomic ioctl when it
allocated its own event.
This has been broken twice. The first time when the code was introduced,
but only in the corner case when an event is allocated, but more crtc's
were included by atomic check and then failing. This can mostly
happen when you do an atomic modeset in i915 and the display clock is
changed, which forces all crtc's to be included to the state.
This has been broken worse by adding in-fences support, which caused
the double free to be done unconditionally.
[IGT] kms_rotation_crc: starting subtest primary-rotation-180
=
BUG kmalloc-128 (Tainted: G U ): Object already free
-
Disabling lock debugging due to kernel taint
INFO: Allocated in drm_atomic_helper_setup_commit+0x285/0x2f0 [drm_kms_helper]
age=0 cpu=3 pid=1529
___slab_alloc+0x308/0x3b0
__slab_alloc+0xd/0x20
kmem_cache_alloc_trace+0x92/0x1c0
drm_atomic_helper_setup_commit+0x285/0x2f0 [drm_kms_helper]
intel_atomic_commit+0x35/0x4f0 [i915]
drm_atomic_commit+0x46/0x50 [drm]
drm_mode_atomic_ioctl+0x7d4/0xab0 [drm]
drm_ioctl+0x2b3/0x490 [drm]
do_vfs_ioctl+0x69c/0x700
SyS_ioctl+0x4e/0x80
entry_SYSCALL_64_fastpath+0x13/0x94
INFO: Freed in drm_event_cancel_free+0xa3/0xb0 [drm] age=0 cpu=3 pid=1529
__slab_free+0x48/0x2e0
kfree+0x159/0x1a0
drm_event_cancel_free+0xa3/0xb0 [drm]
drm_mode_atomic_ioctl+0x86d/0xab0 [drm]
drm_ioctl+0x2b3/0x490 [drm]
do_vfs_ioctl+0x69c/0x700
SyS_ioctl+0x4e/0x80
entry_SYSCALL_64_fastpath+0x13/0x94
INFO: Slab 0xde1f0997b080 objects=17 used=2 fp=0x92fb65ec2578
flags=0x2008101
INFO: Object 0x92fb65ec2578 @offset=1400 fp=0x92fb65ec2ae8
Redzone 92fb65ec2570: bb bb bb bb bb bb bb bb
Object 92fb65ec2578: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
Object 92fb65ec2588: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
Object 92fb65ec2598: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
Object 92fb65ec25a8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
Object 92fb65ec25b8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
Object 92fb65ec25c8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
Object 92fb65ec25d8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
Object 92fb65ec25e8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5
kkk.
Redzone 92fb65ec25f8: bb bb bb bb bb bb bb bb
Padding 92fb65ec2738: 5a 5a 5a 5a 5a 5a 5a 5a
CPU: 3 PID: 180 Comm: kworker/3:2 Tainted: GBU 4.10.0-rc6-patser+
#5039
Hardware name: /NUC5PPYB, BIOS
PYBSWCEL.86A.0031.2015.0601.1712 06/01/2015
Workqueue: events intel_atomic_helper_free_state [i915]
Call Trace:
dump_stack+0x4d/0x6d
print_trailer+0x20c/0x220
free_debug_processing+0x1c6/0x330
? drm_atomic_state_default_clear+0xf7/0x1c0 [drm]
__slab_free+0x48/0x2e0
? drm_atomic_state_default_clear+0xf7/0x1c0 [drm]
kfree+0x159/0x1a0
drm_atomic_state_default_clear+0xf7/0x1c0 [drm]
? drm_atomic_state_clear+0x30/0x30 [drm]
intel_atomic_state_clear+0xd/0x20 [i915]
drm_atomic_state_clear+0x1a/0x30 [drm]
__drm_atomic_state_free+0x13/0x60 [drm]
intel_atomic_helper_free_state+0x5d/0x70 [i915]
process_one_work+0x260/0x4a0
worker_thread+0x2d1/0x4f0
kthread+0x127/0x130
? process_one_work+0x4a0/0x4a0
? kthread_stop+0x120/0x120
ret_from_fork+0x29/0x40
FIX kmalloc-128: Object at 0x92fb65ec2578 not freed
Fixes: 3b24f7d67581 ("drm/atomic: Add struct drm_crtc_commit to track async
updates")
Fixes: 9626014258a5 ("drm/fence: add in-fences support")
Cc: # v4.8+
Cc: Daniel Vetter
Signed-off-by: Maarten Lankhorst
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_atomic.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 50f5cf7b69d1..fdfb1ec17e66 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -2032,13 +2032,16 @@ static void complete_crtc_signaling(struct drm_device
*dev,
}
for_each_crtc_in_state(state, crtc, crtc_state, i) {
+ struct drm_pending_vblank_event *event = crtc_state->event;
/*
-* TEST_ONLY and PAGE_FLIP_EVENT are mutually
-* exclusive, if they weren't, this code should be
-* called on success for TEST_ONLY too.
+* Free the allocated event. drm_atomic_helper_setup_commit
+* can allocate an event too
[Intel-gfx] [dim PATCH 2/2] dim: document how to define subcommand aliases
Cc: Gerd Hoffmann Signed-off-by: Jani Nikula --- dim.rst | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/dim.rst b/dim.rst index 97b375e34e90..911b4666b4aa 100644 --- a/dim.rst +++ b/dim.rst @@ -330,9 +330,10 @@ Run the given command in all active workdirs including the main repository under list-aliases - List all aliases for the subcommand names. Useful for autocompletion scripts. +See \$dim_alias_ under ENVIRONMENT below on how to define aliases. + list-branches - @@ -401,6 +402,14 @@ DIM_TEMPLATE_SIGNATURE -- Path to a file containing a signature template for pull request mails. +dim_alias_ +- +Make an alias for the subcommand defined as the value. For example, +`dim_alias_ub=update-branches`. There are some built-in aliases. Aliases can be +listed using the **list-aliases** subcommand. + +The alias functionality requires **bash(1)** version 4.3 or later to work. + CONTRIBUTING -- 2.1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [dim PATCH 1/2] dim: handle missing declare -n option gracefully
The declare -n option was added in bash 4.3. Handle missing -n
gracefully, at the expense of losing dim alias functionality.
Cc: Gerd Hoffmann
Reported-by: Gerd Hoffmann
Signed-off-by: Jani Nikula
---
dim | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/dim b/dim
index 9500a9df102a..20eac8c58c58 100755
--- a/dim
+++ b/dim
@@ -1598,9 +1598,9 @@ function dim_usage
echo "See '$dim help' for more information."
}
-# dim subcommand aliases
-declare -n subcmd=dim_alias_${subcommand//-/_}
-if [ -z "$subcmd" ]; then
+# dim subcommand aliases (with bash 4.3+)
+if ! declare -n subcmd=dim_alias_${subcommand//-/_} &> /dev/null || \
+ test -z "$subcmd"; then
subcmd="$subcommand"
fi
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH igt] intel-ci: Minimal exercise of explicit fencing
On Fri, Jan 27, 2017 at 09:36:23PM +, Chris Wilson wrote: > Signed-off-by: Chris Wilson > Cc: Petri Latvala Ping? And any feedback from the earlier ringfill-fds? -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Add MIPI_IO WA and program DSI regulators
Gentle remainder - could you kindly check the patch please? Thank you.
> -Original Message-
> From: Srinivas, Vidya
> Sent: Wednesday, January 25, 2017 7:43 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Shankar, Uma ; Nikula, Jani
> ; Syrjala, Ville ; Kahola,
> Mika ; Srinivas, Vidya
> Subject: [PATCH] drm/i915: Add MIPI_IO WA and program DSI regulators
>
> From: Uma Shankar
>
> Enable MIPI IO WA for BXT DSI as per bspec and program the DSI regulators.
>
> v2: Moved IO enable to pre-enable as per Mika's review comments. Also
> reused the existing register definition for BXT_P_CR_GT_DISP_PWRON.
>
> v3: Added Programming the DSI regulators as per disable/enable sequences.
>
> v4: Restricting regulator changes to BXT as suggested by Jani/Mika
>
> v5: Removed redundant read/modify for regulator register as per Jani's
> comment. Maintain enable/disable symmetry as per spec.
>
> Signed-off-by: Uma Shankar
> Signed-off-by: Vidya Srinivas
> ---
> drivers/gpu/drm/i915/i915_reg.h | 7 +++
> drivers/gpu/drm/i915/intel_dsi.c | 24
> 2 files changed, 31 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h
> b/drivers/gpu/drm/i915/i915_reg.h index 00970aa..0a9ad44 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1553,6 +1553,7 @@ enum skl_disp_power_wells {
> _MMIO(_BXT_PHY_CH(phy, ch, reg_ch0, reg_ch1))
>
> #define BXT_P_CR_GT_DISP_PWRON _MMIO(0x138090)
> +#define MIPIO_RST_CTRL (1 << 2)
>
> #define _BXT_PHY_CTL_DDI_A 0x64C00
> #define _BXT_PHY_CTL_DDI_B 0x64C10
> @@ -8301,6 +8302,12 @@ enum {
> #define _BXT_MIPIC_PORT_CTRL 0x6B8C0
> #define BXT_MIPI_PORT_CTRL(tc) _MMIO_MIPI(tc,
> _BXT_MIPIA_PORT_CTRL, _BXT_MIPIC_PORT_CTRL)
>
> +#define BXT_P_DSI_REGULATOR_CFG _MMIO(0x160020)
> +#define STAP_SELECT (1 << 0)
> +
> +#define BXT_P_DSI_REGULATOR_TX_CTRL _MMIO(0x160054)
> +#define HS_IO_CTRL_SELECT (1 << 0)
> +
> #define DPI_ENABLE (1 << 31) /* A + C */
> #define MIPIA_MIPI4DPHY_DELAY_COUNT_SHIFT 27
> #define MIPIA_MIPI4DPHY_DELAY_COUNT_MASK(0xf << 27)
> diff --git a/drivers/gpu/drm/i915/intel_dsi.c
> b/drivers/gpu/drm/i915/intel_dsi.c
> index 16732e7..c98234e 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.c
> +++ b/drivers/gpu/drm/i915/intel_dsi.c
> @@ -548,6 +548,7 @@ static void intel_dsi_pre_enable(struct
> intel_encoder *encoder,
> struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> struct intel_dsi *intel_dsi = enc_to_intel_dsi(&encoder->base);
> enum port port;
> + u32 val;
>
> DRM_DEBUG_KMS("\n");
>
> @@ -558,6 +559,17 @@ static void intel_dsi_pre_enable(struct
> intel_encoder *encoder,
> intel_disable_dsi_pll(encoder);
> intel_enable_dsi_pll(encoder, pipe_config);
>
> + if (IS_BROXTON(dev_priv)) {
> + /* Add MIPI IO reset programming for modeset */
> + val = I915_READ(BXT_P_CR_GT_DISP_PWRON);
> + I915_WRITE(BXT_P_CR_GT_DISP_PWRON,
> + val | MIPIO_RST_CTRL);
> +
> + /* Power up DSI regulator */
> + I915_WRITE(BXT_P_DSI_REGULATOR_CFG, STAP_SELECT);
> + I915_WRITE(BXT_P_DSI_REGULATOR_TX_CTRL, 0);
> + }
> +
> intel_dsi_prepare(encoder, pipe_config);
>
> /* Panel Enable over CRC PMIC */
> @@ -707,6 +719,7 @@ static void intel_dsi_post_disable(struct
> intel_encoder *encoder, {
> struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> struct intel_dsi *intel_dsi = enc_to_intel_dsi(&encoder->base);
> + u32 val;
>
> DRM_DEBUG_KMS("\n");
>
> @@ -714,6 +727,17 @@ static void intel_dsi_post_disable(struct
> intel_encoder *encoder,
>
> intel_dsi_clear_device_ready(encoder);
>
> + if (IS_BROXTON(dev_priv)) {
> + /* Power down DSI regulator to save power */
> + I915_WRITE(BXT_P_DSI_REGULATOR_CFG, STAP_SELECT);
> + I915_WRITE(BXT_P_DSI_REGULATOR_TX_CTRL,
> HS_IO_CTRL_SELECT);
> +
> + /* Add MIPI IO reset programming for modeset */
> + val = I915_READ(BXT_P_CR_GT_DISP_PWRON);
> + I915_WRITE(BXT_P_CR_GT_DISP_PWRON,
> + val & ~MIPIO_RST_CTRL);
> + }
> +
> intel_disable_dsi_pll(encoder);
>
> if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
> --
> 1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Sanity check the computed size and base of stolen memory
On ma, 2017-01-30 at 13:47 +, Chris Wilson wrote: > Just do a quick check that the stolen memory address range doesn't > overflow our chosen integer type. > > v2: Add add_overflows() to utils with the promise that gcc7 can do this > better than C and then maybe it will have a proper definition in core. > > Signed-off-by: Chris Wilson > Cc: Joonas Lahtinen Reviewed-by: Joonas Lahtinen Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t v3 00/11] tests/kms_atomic_transition add fence testing
On Mon, Jan 30, 2017 at 08:58:36PM -0500, Robert Foss wrote: > This series adds in/out fence testing to kms_atomic_transition test and makes > some minor cleanups. > > This series is rebased ontop of the dyn_n_planes_v3 series. > > This series can be found here: > https://git.collabora.com/cgit/user/robertfoss/intel-gpu-tools.git/log/?h=fences_$VER > > > Changes since v1: > > lib/igt_kms: >- Added gtk-doc for exported symbols >- Changed integer casting to avoid potential issues >- Changed out_fence_ptr type to int64_t* >- Fixed igt_plane_set_fence_fd comment > > tests/: >- Rework timeout change in commit_display() >- Extract plane_invalid_params_fence() out plane_invalid_params() >- Extract crtc_invalid_params_fence() out crtc_invalid_params() >- Prevent add igt_require_sw_sync to subtests using sw_sync > > > Changes since v2: > Rebased on upstream/master > > lib/igt_kms: > - Reset plane->fence_fd to -1 during igt_atomic_prepare_plane_commit() > - Rework out_fencs_ptr to be an int64_t named out_fence > - Add igt_pipe_request_out_fence() > tests/: > - Switch to using igt_pipe_request_out_fence() > - Close out_fence fd > - Change out_fence to int64_t in run_transition_test() > - Added comments noting that two testcases are not invalid > - Added igt_pipe_get_last_out_fence() that wraps pipe->fence_out Looks like this this missing the uabi conversion to s32 (int). -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ 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/atomic: Fix double free in drm_atomic_state_default_clear
== Series Details == Series: drm/atomic: Fix double free in drm_atomic_state_default_clear URL : https://patchwork.freedesktop.org/series/18826/ State : success == Summary == Series 18826v1 drm/atomic: Fix double free in drm_atomic_state_default_clear https://patchwork.freedesktop.org/api/1.0/series/18826/revisions/1/mbox/ Test kms_flip: Subgroup basic-flip-vs-wf_vblank: dmesg-warn -> PASS (fi-snb-2520m) Test kms_force_connector_basic: Subgroup force-connector-state: dmesg-warn -> PASS (fi-snb-2520m) Test kms_pipe_crc_basic: Subgroup nonblocking-crc-pipe-a: dmesg-warn -> PASS (fi-snb-2520m) fi-bdw-5557u total:246 pass:232 dwarn:0 dfail:0 fail:0 skip:14 fi-bsw-n3050 total:246 pass:207 dwarn:0 dfail:0 fail:0 skip:39 fi-bxt-j4205 total:246 pass:224 dwarn:0 dfail:0 fail:0 skip:22 fi-bxt-t5700 total:78 pass:65 dwarn:0 dfail:0 fail:0 skip:12 fi-byt-j1900 total:246 pass:219 dwarn:0 dfail:0 fail:0 skip:27 fi-byt-n2820 total:246 pass:215 dwarn:0 dfail:0 fail:0 skip:31 fi-hsw-4770 total:246 pass:227 dwarn:0 dfail:0 fail:0 skip:19 fi-hsw-4770r total:246 pass:227 dwarn:0 dfail:0 fail:0 skip:19 fi-ivb-3520m total:246 pass:225 dwarn:0 dfail:0 fail:0 skip:21 fi-kbl-7500u total:246 pass:223 dwarn:0 dfail:0 fail:2 skip:21 fi-skl-6260u total:246 pass:233 dwarn:0 dfail:0 fail:0 skip:13 fi-skl-6700hqtotal:246 pass:226 dwarn:0 dfail:0 fail:0 skip:20 fi-skl-6700k total:246 pass:221 dwarn:4 dfail:0 fail:0 skip:21 fi-skl-6770hqtotal:246 pass:233 dwarn:0 dfail:0 fail:0 skip:13 fi-snb-2520m total:246 pass:215 dwarn:0 dfail:0 fail:0 skip:31 fi-snb-2600 total:246 pass:214 dwarn:0 dfail:0 fail:0 skip:32 123d798c350471aba7e0625c154c6d9e395756c8 drm-tip: 2017y-01m-30d-21h-14m-37s UTC integration manifest 3d83408 drm/atomic: Fix double free in drm_atomic_state_default_clear == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3651/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: The return of i915_gpu_info to debugfs
Once upon a time before we had automated GPU state capture upon hangs,
we had intel_gpu_dump. Now we come almost full circle and reinstate that
view of the current GPU queues and registers by using the error capture
facility to snapshot the GPU state when debugfs/.../i915_gpu_info is
opened - which should provided useful debugging to both the error
capture routines (without having to cause a hang and avoid the error
state being eaten by igt) and generally.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_debugfs.c | 123 +++---
drivers/gpu/drm/i915/i915_drv.h | 26 ---
drivers/gpu/drm/i915/i915_gpu_error.c | 71
drivers/gpu/drm/i915/i915_sysfs.c | 31 +
4 files changed, 132 insertions(+), 119 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 3ae06568df7b..124a184389a8 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -954,89 +954,103 @@ static int i915_gem_fence_regs_info(struct seq_file *m,
void *data)
}
#if IS_ENABLED(CONFIG_DRM_I915_CAPTURE_ERROR)
-
-static ssize_t
-i915_error_state_write(struct file *filp,
- const char __user *ubuf,
- size_t cnt,
- loff_t *ppos)
+static ssize_t error_state_read(struct file *file, char __user *ubuf,
+ size_t count, loff_t *pos)
{
- struct i915_error_state_file_priv *error_priv = filp->private_data;
-
- DRM_DEBUG_DRIVER("Resetting error state\n");
- i915_destroy_error_state(error_priv->i915);
-
- return cnt;
-}
+ struct drm_i915_error_state *error = file->private_data;
+ struct drm_i915_error_state_buf str;
+ ssize_t ret;
+ loff_t tmp;
-static int i915_error_state_open(struct inode *inode, struct file *file)
-{
- struct drm_i915_private *dev_priv = inode->i_private;
- struct i915_error_state_file_priv *error_priv;
+ if (!error)
+ return 0;
- error_priv = kzalloc(sizeof(*error_priv), GFP_KERNEL);
- if (!error_priv)
- return -ENOMEM;
+ ret = i915_error_state_buf_init(&str, error->i915, count, *pos);
+ if (ret)
+ return ret;
- error_priv->i915 = dev_priv;
+ ret = i915_error_state_to_str(&str, error);
+ if (ret)
+ goto out;
- i915_error_state_get(&dev_priv->drm, error_priv);
+ tmp = 0;
+ ret = simple_read_from_buffer(ubuf, count, &tmp, str.buf, str.bytes);
+ if (ret < 0)
+ goto out;
- file->private_data = error_priv;
+ *pos = str.start + ret;
+out:
+ i915_error_state_buf_release(&str);
+ return ret;
+}
+static int error_state_release(struct inode *inode, struct file *file)
+{
+ i915_error_state_put(file->private_data);
return 0;
}
-static int i915_error_state_release(struct inode *inode, struct file *file)
+static int i915_gpu_info_open(struct inode *inode, struct file *file)
{
- struct i915_error_state_file_priv *error_priv = file->private_data;
+ struct drm_i915_error_state *error;
- i915_error_state_put(error_priv);
- kfree(error_priv);
+ error = i915_error_state(inode->i_private);
+ if (!error)
+ return -ENOMEM;
+ file->private_data = error;
return 0;
}
-static ssize_t i915_error_state_read(struct file *file, char __user *userbuf,
-size_t count, loff_t *pos)
+static const struct file_operations i915_gpu_info_fops = {
+ .owner = THIS_MODULE,
+ .open = i915_gpu_info_open,
+ .read = error_state_read,
+ .llseek = default_llseek,
+ .release = error_state_release,
+};
+
+static ssize_t
+i915_error_state_write(struct file *filp,
+ const char __user *ubuf,
+ size_t cnt,
+ loff_t *ppos)
{
- struct i915_error_state_file_priv *error_priv = file->private_data;
- struct drm_i915_error_state_buf error_str;
- loff_t tmp_pos = 0;
- ssize_t ret_count = 0;
- int ret;
+ struct drm_i915_error_state *error = filp->private_data;
- ret = i915_error_state_buf_init(&error_str, error_priv->i915,
- count, *pos);
- if (ret)
- return ret;
+ if (!error)
+ return 0;
- ret = i915_error_state_to_str(&error_str, error_priv);
- if (ret)
- goto out;
+ DRM_DEBUG_DRIVER("Resetting error state\n");
+ i915_destroy_error_state(error->i915);
- ret_count = simple_read_from_buffer(userbuf, count, &tmp_pos,
- error_str.buf,
- error_str.bytes);
+ return cnt;
+}
- if (ret_count < 0)
- ret =
[Intel-gfx] [PATCH] drm/i915: Be defensive when cleaning up i915_gem_internal pages
If we abort the i915_gem_internal get_pages, we mark the failing sg as
the last. However, that means we iterate upto and including the failing
sg element and results us in trying to free the unallocated sg_page().
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_internal.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_internal.c
b/drivers/gpu/drm/i915/i915_gem_internal.c
index 17ce53d0d092..64d8fb3fd764 100644
--- a/drivers/gpu/drm/i915/i915_gem_internal.c
+++ b/drivers/gpu/drm/i915/i915_gem_internal.c
@@ -35,8 +35,10 @@ static void internal_free_pages(struct sg_table *st)
{
struct scatterlist *sg;
- for (sg = st->sgl; sg; sg = __sg_next(sg))
- __free_pages(sg_page(sg), get_order(sg->length));
+ for (sg = st->sgl; sg; sg = __sg_next(sg)) {
+ if (sg_page(sg))
+ __free_pages(sg_page(sg), get_order(sg->length));
+ }
sg_free_table(st);
kfree(st);
@@ -116,6 +118,7 @@ i915_gem_object_get_pages_internal(struct
drm_i915_gem_object *obj)
return st;
err:
+ sg_set_page(sg, NULL, 0, 0);
sg_mark_end(sg);
internal_free_pages(st);
return ERR_PTR(-ENOMEM);
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 30/38] drm/i915: Test creation of VMA
On to, 2017-01-19 at 11:41 +, Chris Wilson wrote:
> Simple test to exercise creation and lookup of VMA within an object.
>
> Signed-off-by: Chris Wilson
> +static bool assert_vma(struct i915_vma *vma,
> + struct drm_i915_gem_object *obj,
> + struct i915_gem_context *ctx)
> +{
> + if (vma->vm != &ctx->ppgtt->base) {
> + pr_err("VMA created with wrong VM\n");
> + return false;
> + }
maybe "bool correct = true;" and list all the errors he VMA has? and
finally return correct;
> + for_each_prime_number(num_obj, ULONG_MAX - 1) {
> + for (; no < num_obj; no++) {
> + obj = i915_gem_object_create_internal(i915, PAGE_SIZE);
> + if (IS_ERR(obj))
> + goto err;
> +
> + list_add(&obj->batch_pool_link, &objects);
See below;
> + }
> +
> + nc = 0;
> + for_each_prime_number(num_ctx, MAX_CONTEXT_HW_ID) {
> + for (; nc < num_ctx; nc++) {
> + ctx = mock_context(i915, "mock");
> + if (!ctx)
> + goto err;
> +
> + list_move(&ctx->link, &contexts);
Why the difference?
> + }
> +
> + err = create_vmas(i915, &objects, &contexts);
> + if (err)
> + goto err;
> +
> + if (igt_timeout(end_time,
> + "%s timed out: after %lu objects\n",
> + __func__, no))
Maybe also context count, because it's available.
Reviewed-by: Joonas Lahtinen
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Linux v4.10.0-rc1+] Still call-traces after suspend-resume (pm? i915? cpu/hotplug?)
Hi Rafael,
On Mon, Jan 30, 2017 at 11:44:37PM +0100, Rafael J. Wysocki wrote:
> On 1/24/2017 2:33 AM, Sedat Dilek wrote:
> >On Fri, Dec 30, 2016 at 3:02 PM, Rafael J. Wysocki wrote:
> >>On Fri, Dec 30, 2016 at 12:40 PM, Sedat Dilek wrote:
> >>>Hi,
> >>>
> >>>I have already reported this issue in [1].
> >>>One of the issue was solved.
> >>>Unfortunately, it looks like there is still a different problem here
> >>>(Ubuntu/precise AMD64).
> >>>
> >>>I tried v4.10-rc1 and latest Linus tree up to...
> >>>
> >>>commit 98473f9f3f9bd404873cd1178c8be7d6d619f0d1
> >>>"mm/filemap: fix parameters to test_bit()"
> >>>
> >>>Here we go...
> >>>
> >>>[ 29.636047] BUG: sleeping function called from invalid context at
> >>>drivers/base/power/runtime.c:1032
> >>>[ 29.636055] in_atomic(): 1, irqs_disabled(): 0, pid: 1500, name: Xorg
> >>>[ 29.636058] 1 lock held by Xorg/1500:
> >>>[ 29.636060] #0: (&dev->struct_mutex){+.+.+.}, at:
> >>>[] i915_mutex_lock_interruptible+0x43/0x140 [i915]
> >>>[ 29.636107] CPU: 0 PID: 1500 Comm: Xorg Not tainted
> >>>4.10.0-rc1-6-iniza-amd64 #1
> >>>[ 29.636109] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
> >>>530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
> >>>[ 29.636111] Call Trace:
> >>>[ 29.636120] dump_stack+0x85/0xc2
> >>>[ 29.636124] ___might_sleep+0x196/0x260
> >>>[ 29.636127] __might_sleep+0x53/0xb0
> >>>[ 29.636131] __pm_runtime_resume+0x7a/0x90
> >>>[ 29.636159] intel_runtime_pm_get+0x25/0x90 [i915]
> >>>[ 29.636189] aliasing_gtt_bind_vma+0xaa/0xf0 [i915]
> >>>[ 29.636220] i915_vma_bind+0xaf/0x1e0 [i915]
> >>>[ 29.636248] i915_gem_execbuffer_relocate_entry+0x513/0x6f0 [i915]
> >>>[ 29.636272] i915_gem_execbuffer_relocate_vma.isra.34+0x188/0x250 [i915]
> >>>[ 29.636275] ? trace_hardirqs_on+0xd/0x10
> >>>[ 29.636294] ? i915_gem_execbuffer_reserve_vma.isra.31+0x152/0x1f0
> >>>[i915]
> >>>[ 29.636316] ? i915_gem_execbuffer_reserve.isra.32+0x372/0x3a0 [i915]
> >>>[ 29.636342] i915_gem_do_execbuffer.isra.38+0xa70/0x1a40 [i915]
> >>>[ 29.636347] ? __might_fault+0x4e/0xb0
> >>>[ 29.636373] i915_gem_execbuffer2+0xc5/0x260 [i915]
> >>>[ 29.636376] ? __might_fault+0x4e/0xb0
> >>>[ 29.636395] drm_ioctl+0x206/0x450 [drm]
> >>>[ 29.636420] ? i915_gem_execbuffer+0x340/0x340 [i915]
> >>>[ 29.636425] ? __fget+0x5/0x200
> >>>[ 29.636429] do_vfs_ioctl+0x91/0x6f0
> >>>[ 29.636431] ? __fget+0x111/0x200
> >>>[ 29.636433] ? __fget+0x5/0x200
> >>>[ 29.636436] SyS_ioctl+0x79/0x90
> >>>[ 29.636441] entry_SYSCALL_64_fastpath+0x23/0xc6
> >>>
> >>>On suspend/resume I see the same call trace.
> >>>[2] points to the "BUG" line.
> >>Well, this appears to be an i915 issue, but not a serious one.
> >>
> >>Clearly, a function that may sleep (pm_runtime_get_sync() in
> >>intel_runtime_pm_get()) is called with disabled interrupts. If I
> >>understand the code correctly, though, it actually is not going to
> >>sleep in this particular case, because pm_runtime_get_sync() has
> >>already been called once for this device in the same code path which
> >>means that this particular instance will return immediately, so this
> >>is a false-positive (most likely).
Not sure what's the root cause, but thought to clarify the above:
Yes, i915_gem_do_execbuffer() does take an RPM reference to optimize
things, so the RPM get in aliasing_gtt_bind_vma() won't need to resume
the device on this path. This isn't a guarantee though,
aliasing_gtt_bind_vma() could be called from other places without an RPM
reference. So preemption being disabled at that point is not
intentional. I also can't see where on the above path it would get
disabled due to a bug or otherwise.
--Imre
> >>
> >>Let me see if I the might_sleep_if() assertion in
> >>__pm_runtime_resume(() can be moved to a better place.
> >>
> >Hi Rafael,
> >
> >did you had a chance to look at this?
> >The problem still remains in Linux v4.10-rc5.
>
> No, I didn't.
>
> As I said, this is not a serious issue.
>
> Thanks,
> Rafael
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Add MIPI_IO WA and program DSI regulators
Looks ok.
Acked-by: Mika Kahola
On Wed, 2017-01-25 at 19:43 +0530, Vidya Srinivas wrote:
> From: Uma Shankar
>
> Enable MIPI IO WA for BXT DSI as per bspec and
> program the DSI regulators.
>
> v2: Moved IO enable to pre-enable as per Mika's
> review comments. Also reused the existing register
> definition for BXT_P_CR_GT_DISP_PWRON.
>
> v3: Added Programming the DSI regulators as per disable/enable
> sequences.
>
> v4: Restricting regulator changes to BXT as suggested by
> Jani/Mika
>
> v5: Removed redundant read/modify for regulator register as
> per Jani's comment. Maintain enable/disable symmetry as per spec.
>
> Signed-off-by: Uma Shankar
> Signed-off-by: Vidya Srinivas
> ---
> drivers/gpu/drm/i915/i915_reg.h | 7 +++
> drivers/gpu/drm/i915/intel_dsi.c | 24
> 2 files changed, 31 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h
> b/drivers/gpu/drm/i915/i915_reg.h
> index 00970aa..0a9ad44 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1553,6 +1553,7 @@ enum skl_disp_power_wells {
> _MMIO(_BXT_PHY_CH(phy, ch, reg_ch0, reg_ch1))
>
> #define BXT_P_CR_GT_DISP_PWRON _MMIO(0x138090)
> +#define MIPIO_RST_CTRL (1 << 2)
>
> #define _BXT_PHY_CTL_DDI_A 0x64C00
> #define _BXT_PHY_CTL_DDI_B 0x64C10
> @@ -8301,6 +8302,12 @@ enum {
> #define _BXT_MIPIC_PORT_CTRL 0x6B8C0
> #define BXT_MIPI_PORT_CTRL(tc) _MMIO_MIPI(tc,
> _BXT_MIPIA_PORT_CTRL, _BXT_MIPIC_PORT_CTRL)
>
> +#define BXT_P_DSI_REGULATOR_CFG _MMIO(0x16002
> 0)
> +#define STAP_SELECT (1 << 0)
> +
> +#define BXT_P_DSI_REGULATOR_TX_CTRL _MMIO(0x160054)
> +#define HS_IO_CTRL_SELECT (1 << 0)
> +
> #define DPI_ENABLE (1 << 31)
> /* A + C */
> #define MIPIA_MIPI4DPHY_DELAY_COUNT_SHIFT 27
> #define MIPIA_MIPI4DPHY_DELAY_COUNT_MASK(0xf << 27)
> diff --git a/drivers/gpu/drm/i915/intel_dsi.c
> b/drivers/gpu/drm/i915/intel_dsi.c
> index 16732e7..c98234e 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.c
> +++ b/drivers/gpu/drm/i915/intel_dsi.c
> @@ -548,6 +548,7 @@ static void intel_dsi_pre_enable(struct
> intel_encoder *encoder,
> struct drm_i915_private *dev_priv = to_i915(encoder-
> >base.dev);
> struct intel_dsi *intel_dsi = enc_to_intel_dsi(&encoder-
> >base);
> enum port port;
> + u32 val;
>
> DRM_DEBUG_KMS("\n");
>
> @@ -558,6 +559,17 @@ static void intel_dsi_pre_enable(struct
> intel_encoder *encoder,
> intel_disable_dsi_pll(encoder);
> intel_enable_dsi_pll(encoder, pipe_config);
>
> + if (IS_BROXTON(dev_priv)) {
> + /* Add MIPI IO reset programming for modeset */
> + val = I915_READ(BXT_P_CR_GT_DISP_PWRON);
> + I915_WRITE(BXT_P_CR_GT_DISP_PWRON,
> + val | MIPIO_RST_CTRL);
> +
> + /* Power up DSI regulator */
> + I915_WRITE(BXT_P_DSI_REGULATOR_CFG, STAP_SELECT);
> + I915_WRITE(BXT_P_DSI_REGULATOR_TX_CTRL, 0);
> + }
> +
> intel_dsi_prepare(encoder, pipe_config);
>
> /* Panel Enable over CRC PMIC */
> @@ -707,6 +719,7 @@ static void intel_dsi_post_disable(struct
> intel_encoder *encoder,
> {
> struct drm_i915_private *dev_priv = to_i915(encoder-
> >base.dev);
> struct intel_dsi *intel_dsi = enc_to_intel_dsi(&encoder-
> >base);
> + u32 val;
>
> DRM_DEBUG_KMS("\n");
>
> @@ -714,6 +727,17 @@ static void intel_dsi_post_disable(struct
> intel_encoder *encoder,
>
> intel_dsi_clear_device_ready(encoder);
>
> + if (IS_BROXTON(dev_priv)) {
> + /* Power down DSI regulator to save power */
> + I915_WRITE(BXT_P_DSI_REGULATOR_CFG, STAP_SELECT);
> + I915_WRITE(BXT_P_DSI_REGULATOR_TX_CTRL,
> HS_IO_CTRL_SELECT);
> +
> + /* Add MIPI IO reset programming for modeset */
> + val = I915_READ(BXT_P_CR_GT_DISP_PWRON);
> + I915_WRITE(BXT_P_CR_GT_DISP_PWRON,
> + val & ~MIPIO_RST_CTRL);
> + }
> +
> intel_disable_dsi_pll(encoder);
>
> if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
--
Mika Kahola - Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Be defensive when cleaning up i915_gem_internal pages
On 31 January 2017 at 10:46, Chris Wilson wrote: > If we abort the i915_gem_internal get_pages, we mark the failing sg as > the last. However, that means we iterate upto and including the failing > sg element and results us in trying to free the unallocated sg_page(). s/us in/in us/ > > Signed-off-by: Chris Wilson Reviewed-by: Matthew Auld ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH igt] intel-ci: Add multiple ringfill for execlists
On Tue, Jan 24, 2017 at 01:02:23PM +0200, Petri Latvala wrote: > On Tue, Jan 24, 2017 at 09:31:39AM +, Chris Wilson wrote: > > On Wed, Jan 18, 2017 at 08:54:10PM +, Chris Wilson wrote: > > > Execlists introduces a new wrinkle to filling rings, in that each > > > context has an independent set of rings. Add the subtest that exercises > > > filling multiple execlist rings (for the same engine) to BAT. > > > > > > Signed-off-by: Chris Wilson > > > Cc: Petri Latvala > > > > Ping? This provides coverage of some hairy paths on execlists/guc that > > currently have nothing explicit. > > > Sent to farm2 for a test round. Acked-by: Petri Latvala ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH igt] intel-ci: Minimal exercise of explicit fencing
On Tue, Jan 31, 2017 at 09:54:21AM +, Chris Wilson wrote: > Ping? And any feedback from the earlier ringfill-fds? > -Chris Sent ack on the ringfill test. This one has been queued for a test round at farm2. For those following along and smelling chances of getting their $favoritefeatureoftheday into BAT, I'm being a little more lenient than I should with allowing more tests into fast-feedback at this time. As soon as we can deploy Ezbench-driven extended testing (not far now btw), fast-feedback will go on a diet. -- Petri Latvala ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Be defensive when cleaning up i915_gem_internal pages
On Tue, Jan 31, 2017 at 11:04:49AM +, Matthew Auld wrote: > On 31 January 2017 at 10:46, Chris Wilson wrote: > > If we abort the i915_gem_internal get_pages, we mark the failing sg as > > the last. However, that means we iterate upto and including the failing > > sg element and results us in trying to free the unallocated sg_page(). > s/us in/in us/ Ta. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ 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: The return of i915_gpu_info to debugfs
== Series Details == Series: drm/i915: The return of i915_gpu_info to debugfs URL : https://patchwork.freedesktop.org/series/18833/ State : failure == Summary == Series 18833v1 drm/i915: The return of i915_gpu_info to debugfs https://patchwork.freedesktop.org/api/1.0/series/18833/revisions/1/mbox/ Test drv_hangman: Subgroup error-state-basic: pass -> FAIL (fi-snb-2520m) pass -> FAIL (fi-snb-2600) pass -> FAIL (fi-skl-6700k) pass -> FAIL (fi-bxt-j4205) pass -> FAIL (fi-hsw-4770) pass -> FAIL (fi-skl-6770hq) pass -> FAIL (fi-hsw-4770r) pass -> FAIL (fi-skl-6700hq) pass -> FAIL (fi-byt-n2820) pass -> FAIL (fi-bsw-n3050) pass -> FAIL (fi-bxt-t5700) pass -> FAIL (fi-ivb-3520m) pass -> FAIL (fi-ivb-3770) pass -> FAIL (fi-bdw-5557u) pass -> FAIL (fi-byt-j1900) pass -> FAIL (fi-skl-6260u) fi-bdw-5557u total:246 pass:231 dwarn:0 dfail:0 fail:1 skip:14 fi-bsw-n3050 total:246 pass:206 dwarn:0 dfail:0 fail:1 skip:39 fi-bxt-j4205 total:246 pass:223 dwarn:0 dfail:0 fail:1 skip:22 fi-bxt-t5700 total:78 pass:64 dwarn:0 dfail:0 fail:1 skip:12 fi-byt-j1900 total:246 pass:218 dwarn:0 dfail:0 fail:1 skip:27 fi-byt-n2820 total:246 pass:214 dwarn:0 dfail:0 fail:1 skip:31 fi-hsw-4770 total:246 pass:226 dwarn:0 dfail:0 fail:1 skip:19 fi-hsw-4770r total:246 pass:226 dwarn:0 dfail:0 fail:1 skip:19 fi-ivb-3520m total:246 pass:224 dwarn:0 dfail:0 fail:1 skip:21 fi-ivb-3770 total:246 pass:224 dwarn:0 dfail:0 fail:1 skip:21 fi-skl-6260u total:246 pass:232 dwarn:0 dfail:0 fail:1 skip:13 fi-skl-6700hqtotal:246 pass:225 dwarn:0 dfail:0 fail:1 skip:20 fi-skl-6700k total:246 pass:220 dwarn:4 dfail:0 fail:1 skip:21 fi-skl-6770hqtotal:246 pass:232 dwarn:0 dfail:0 fail:1 skip:13 fi-snb-2520m total:246 pass:214 dwarn:0 dfail:0 fail:1 skip:31 fi-snb-2600 total:246 pass:213 dwarn:0 dfail:0 fail:1 skip:32 5689d1f0e8e542fc5a89191493fb77188add8807 drm-tip: 2017y-01m-31d-10h-05m-02s UTC integration manifest 5e63eb9 drm/i915: The return of i915_gpu_info to debugfs == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3652/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH igt] intel-ci: Minimal exercise of explicit fencing
On Tue, Jan 31, 2017 at 01:21:15PM +0200, Petri Latvala wrote: > On Tue, Jan 31, 2017 at 09:54:21AM +, Chris Wilson wrote: > > Ping? And any feedback from the earlier ringfill-fds? > > -Chris > > > Sent ack on the ringfill test. This one has been queued for a test > round at farm2. > > For those following along and smelling chances of getting their > $favoritefeatureoftheday into BAT, I'm being a little more lenient > than I should with allowing more tests into fast-feedback at this > time. As soon as we can deploy Ezbench-driven extended testing (not > far now btw), fast-feedback will go on a diet. Unless that is accompanied by some coverage based feedback methodology consider me grumpy. I wish that we had the tools for BAT to be an automatic selection of the testcases that gave excellent coverage and sensitivity. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Linux v4.10.0-rc1+] Still call-traces after suspend-resume (pm? i915? cpu/hotplug?)
On 1/31/2017 11:58 AM, Imre Deak wrote:
Hi Rafael,
Hi,
On Mon, Jan 30, 2017 at 11:44:37PM +0100, Rafael J. Wysocki wrote:
On 1/24/2017 2:33 AM, Sedat Dilek wrote:
On Fri, Dec 30, 2016 at 3:02 PM, Rafael J. Wysocki wrote:
On Fri, Dec 30, 2016 at 12:40 PM, Sedat Dilek wrote:
Hi,
I have already reported this issue in [1].
One of the issue was solved.
Unfortunately, it looks like there is still a different problem here
(Ubuntu/precise AMD64).
I tried v4.10-rc1 and latest Linus tree up to...
commit 98473f9f3f9bd404873cd1178c8be7d6d619f0d1
"mm/filemap: fix parameters to test_bit()"
Here we go...
[ 29.636047] BUG: sleeping function called from invalid context at
drivers/base/power/runtime.c:1032
[ 29.636055] in_atomic(): 1, irqs_disabled(): 0, pid: 1500, name: Xorg
[ 29.636058] 1 lock held by Xorg/1500:
[ 29.636060] #0: (&dev->struct_mutex){+.+.+.}, at:
[] i915_mutex_lock_interruptible+0x43/0x140 [i915]
[ 29.636107] CPU: 0 PID: 1500 Comm: Xorg Not tainted
4.10.0-rc1-6-iniza-amd64 #1
[ 29.636109] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
[ 29.636111] Call Trace:
[ 29.636120] dump_stack+0x85/0xc2
[ 29.636124] ___might_sleep+0x196/0x260
[ 29.636127] __might_sleep+0x53/0xb0
[ 29.636131] __pm_runtime_resume+0x7a/0x90
[ 29.636159] intel_runtime_pm_get+0x25/0x90 [i915]
[ 29.636189] aliasing_gtt_bind_vma+0xaa/0xf0 [i915]
[ 29.636220] i915_vma_bind+0xaf/0x1e0 [i915]
[ 29.636248] i915_gem_execbuffer_relocate_entry+0x513/0x6f0 [i915]
[ 29.636272] i915_gem_execbuffer_relocate_vma.isra.34+0x188/0x250 [i915]
[ 29.636275] ? trace_hardirqs_on+0xd/0x10
[ 29.636294] ? i915_gem_execbuffer_reserve_vma.isra.31+0x152/0x1f0 [i915]
[ 29.636316] ? i915_gem_execbuffer_reserve.isra.32+0x372/0x3a0 [i915]
[ 29.636342] i915_gem_do_execbuffer.isra.38+0xa70/0x1a40 [i915]
[ 29.636347] ? __might_fault+0x4e/0xb0
[ 29.636373] i915_gem_execbuffer2+0xc5/0x260 [i915]
[ 29.636376] ? __might_fault+0x4e/0xb0
[ 29.636395] drm_ioctl+0x206/0x450 [drm]
[ 29.636420] ? i915_gem_execbuffer+0x340/0x340 [i915]
[ 29.636425] ? __fget+0x5/0x200
[ 29.636429] do_vfs_ioctl+0x91/0x6f0
[ 29.636431] ? __fget+0x111/0x200
[ 29.636433] ? __fget+0x5/0x200
[ 29.636436] SyS_ioctl+0x79/0x90
[ 29.636441] entry_SYSCALL_64_fastpath+0x23/0xc6
On suspend/resume I see the same call trace.
[2] points to the "BUG" line.
Well, this appears to be an i915 issue, but not a serious one.
Clearly, a function that may sleep (pm_runtime_get_sync() in
intel_runtime_pm_get()) is called with disabled interrupts. If I
understand the code correctly, though, it actually is not going to
sleep in this particular case, because pm_runtime_get_sync() has
already been called once for this device in the same code path which
means that this particular instance will return immediately, so this
is a false-positive (most likely).
Not sure what's the root cause, but thought to clarify the above:
Yes, i915_gem_do_execbuffer() does take an RPM reference to optimize
things, so the RPM get in aliasing_gtt_bind_vma() won't need to resume
the device on this path. This isn't a guarantee though,
aliasing_gtt_bind_vma() could be called from other places without an RPM
reference. So preemption being disabled at that point is not
intentional. I also can't see where on the above path it would get
disabled due to a bug or otherwise.
The i915 code is correct AFAICS, but the core complains about a nested
invocation of pm_runtime_get_sync() with disabled interrupts (which
looks OK though), so the complaint is a false positive.
As I said, the way to go here appears to be to tweak the core, which I'm
going to do.
Thanks,
Rafael
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 33/38] drm/i915: Test creation of partial VMA
On to, 2017-01-19 at 11:41 +, Chris Wilson wrote:
> Mock testing to ensure we can create and lookup partial VMA.
>
> Signed-off-by: Chris Wilson
> +static bool assert_partial(struct drm_i915_gem_object *obj,
> + struct i915_vma *vma,
> + unsigned long offset,
> + unsigned long size)
> +{
> + struct sgt_iter sgt;
Confusing name, could rather be "sgti" or just "i", or "iter".
> +static int igt_vma_partial(void *arg)
> +{
> + struct drm_i915_private *i915 = arg;
> + const unsigned int npages = 1021; /* prime! */
#define THE_MAGIC_PRIME 1021
> + for (loop = 0; loop <= 1; loop++) { /* exercise both create/lookup */
I'd like the phase array/variable more. "loop" variable is kinda
confusing easily.
> + unsigned int count, nvma;
> +
Make a comment here that a whole VMA is also created at the end and it
needs to be accounted. This is why the phase array might be more
readable.
> + nvma = loop;
> + for_each_prime_number_from(sz, 1, npages) {
> + for_each_prime_number_from(offset, 0, npages - sz) {
> + struct i915_address_space *vm =
> + &i915->ggtt.base;
Could be out of the loop, too.
> +
> + /* Create a mapping for the entire object, just for extra fun */
> + vma = i915_vma_instance(obj, &i915->ggtt.base, NULL);
No helper for this block?
With the variable renamed;
Reviewed-by: Joonas Lahtinen
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Linux v4.10.0-rc1+] Still call-traces after suspend-resume (pm? i915? cpu/hotplug?)
On Tue, Jan 31, 2017 at 12:39:35PM +0100, Rafael J. Wysocki wrote:
> On 1/31/2017 11:58 AM, Imre Deak wrote:
> >Hi Rafael,
>
> Hi,
>
> >On Mon, Jan 30, 2017 at 11:44:37PM +0100, Rafael J. Wysocki wrote:
> >>On 1/24/2017 2:33 AM, Sedat Dilek wrote:
> >>>On Fri, Dec 30, 2016 at 3:02 PM, Rafael J. Wysocki
> >>>wrote:
> On Fri, Dec 30, 2016 at 12:40 PM, Sedat Dilek
> wrote:
> >Hi,
> >
> >I have already reported this issue in [1].
> >One of the issue was solved.
> >Unfortunately, it looks like there is still a different problem here
> >(Ubuntu/precise AMD64).
> >
> >I tried v4.10-rc1 and latest Linus tree up to...
> >
> >commit 98473f9f3f9bd404873cd1178c8be7d6d619f0d1
> >"mm/filemap: fix parameters to test_bit()"
> >
> >Here we go...
> >
> >[ 29.636047] BUG: sleeping function called from invalid context at
> >drivers/base/power/runtime.c:1032
> >[ 29.636055] in_atomic(): 1, irqs_disabled(): 0, pid: 1500, name: Xorg
> >[ 29.636058] 1 lock held by Xorg/1500:
> >[ 29.636060] #0: (&dev->struct_mutex){+.+.+.}, at:
> >[] i915_mutex_lock_interruptible+0x43/0x140 [i915]
> >[ 29.636107] CPU: 0 PID: 1500 Comm: Xorg Not tainted
> >4.10.0-rc1-6-iniza-amd64 #1
> >[ 29.636109] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
> >530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
> >[ 29.636111] Call Trace:
> >[ 29.636120] dump_stack+0x85/0xc2
> >[ 29.636124] ___might_sleep+0x196/0x260
> >[ 29.636127] __might_sleep+0x53/0xb0
> >[ 29.636131] __pm_runtime_resume+0x7a/0x90
> >[ 29.636159] intel_runtime_pm_get+0x25/0x90 [i915]
> >[ 29.636189] aliasing_gtt_bind_vma+0xaa/0xf0 [i915]
> >[ 29.636220] i915_vma_bind+0xaf/0x1e0 [i915]
> >[ 29.636248] i915_gem_execbuffer_relocate_entry+0x513/0x6f0 [i915]
> >[ 29.636272] i915_gem_execbuffer_relocate_vma.isra.34+0x188/0x250
> >[i915]
> >[ 29.636275] ? trace_hardirqs_on+0xd/0x10
> >[ 29.636294] ? i915_gem_execbuffer_reserve_vma.isra.31+0x152/0x1f0
> >[i915]
> >[ 29.636316] ? i915_gem_execbuffer_reserve.isra.32+0x372/0x3a0 [i915]
> >[ 29.636342] i915_gem_do_execbuffer.isra.38+0xa70/0x1a40 [i915]
> >[ 29.636347] ? __might_fault+0x4e/0xb0
> >[ 29.636373] i915_gem_execbuffer2+0xc5/0x260 [i915]
> >[ 29.636376] ? __might_fault+0x4e/0xb0
> >[ 29.636395] drm_ioctl+0x206/0x450 [drm]
> >[ 29.636420] ? i915_gem_execbuffer+0x340/0x340 [i915]
> >[ 29.636425] ? __fget+0x5/0x200
> >[ 29.636429] do_vfs_ioctl+0x91/0x6f0
> >[ 29.636431] ? __fget+0x111/0x200
> >[ 29.636433] ? __fget+0x5/0x200
> >[ 29.636436] SyS_ioctl+0x79/0x90
> >[ 29.636441] entry_SYSCALL_64_fastpath+0x23/0xc6
> >
> >On suspend/resume I see the same call trace.
> >[2] points to the "BUG" line.
> Well, this appears to be an i915 issue, but not a serious one.
>
> Clearly, a function that may sleep (pm_runtime_get_sync() in
> intel_runtime_pm_get()) is called with disabled interrupts. If I
> understand the code correctly, though, it actually is not going to
> sleep in this particular case, because pm_runtime_get_sync() has
> already been called once for this device in the same code path which
> means that this particular instance will return immediately, so this
> is a false-positive (most likely).
> >Not sure what's the root cause, but thought to clarify the above:
> >
> >Yes, i915_gem_do_execbuffer() does take an RPM reference to optimize
> >things, so the RPM get in aliasing_gtt_bind_vma() won't need to resume
> >the device on this path. This isn't a guarantee though,
> >aliasing_gtt_bind_vma() could be called from other places without an RPM
> >reference. So preemption being disabled at that point is not
> >intentional. I also can't see where on the above path it would get
> >disabled due to a bug or otherwise.
>
> The i915 code is correct AFAICS, but the core complains about a nested
> invocation of pm_runtime_get_sync() with disabled interrupts (which looks OK
> though), so the complaint is a false positive.
Well, my point was that interrupts (or preemption) doesn't seem to get
disabled anywhere on that path.
--Imre
>
> As I said, the way to go here appears to be to tweak the core, which I'm
> going to do.
>
> Thanks,
> Rafael
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/atomic: Fix double free in drm_atomic_state_default_clear
Hi Maarten,
2017-01-31 Maarten Lankhorst :
> drm_atomic_helper_page_flip and drm_atomic_ioctl set their own events
> in crtc_state->event. But when it's set the event is freed in 2 places.
>
> Solve this by only freeing the event in the atomic ioctl when it
> allocated its own event.
>
> This has been broken twice. The first time when the code was introduced,
> but only in the corner case when an event is allocated, but more crtc's
> were included by atomic check and then failing. This can mostly
> happen when you do an atomic modeset in i915 and the display clock is
> changed, which forces all crtc's to be included to the state.
>
> This has been broken worse by adding in-fences support, which caused
> the double free to be done unconditionally.
>
> [IGT] kms_rotation_crc: starting subtest primary-rotation-180
> =
> BUG kmalloc-128 (Tainted: G U ): Object already free
> -
>
> Disabling lock debugging due to kernel taint
> INFO: Allocated in drm_atomic_helper_setup_commit+0x285/0x2f0
> [drm_kms_helper] age=0 cpu=3 pid=1529
> ___slab_alloc+0x308/0x3b0
> __slab_alloc+0xd/0x20
> kmem_cache_alloc_trace+0x92/0x1c0
> drm_atomic_helper_setup_commit+0x285/0x2f0 [drm_kms_helper]
> intel_atomic_commit+0x35/0x4f0 [i915]
> drm_atomic_commit+0x46/0x50 [drm]
> drm_mode_atomic_ioctl+0x7d4/0xab0 [drm]
> drm_ioctl+0x2b3/0x490 [drm]
> do_vfs_ioctl+0x69c/0x700
> SyS_ioctl+0x4e/0x80
> entry_SYSCALL_64_fastpath+0x13/0x94
> INFO: Freed in drm_event_cancel_free+0xa3/0xb0 [drm] age=0 cpu=3 pid=1529
> __slab_free+0x48/0x2e0
> kfree+0x159/0x1a0
> drm_event_cancel_free+0xa3/0xb0 [drm]
> drm_mode_atomic_ioctl+0x86d/0xab0 [drm]
> drm_ioctl+0x2b3/0x490 [drm]
> do_vfs_ioctl+0x69c/0x700
> SyS_ioctl+0x4e/0x80
> entry_SYSCALL_64_fastpath+0x13/0x94
> INFO: Slab 0xde1f0997b080 objects=17 used=2 fp=0x92fb65ec2578
> flags=0x2008101
> INFO: Object 0x92fb65ec2578 @offset=1400 fp=0x92fb65ec2ae8
>
> Redzone 92fb65ec2570: bb bb bb bb bb bb bb bb
>
> Object 92fb65ec2578: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
>
> Object 92fb65ec2588: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
>
> Object 92fb65ec2598: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
>
> Object 92fb65ec25a8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
>
> Object 92fb65ec25b8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
>
> Object 92fb65ec25c8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
>
> Object 92fb65ec25d8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
>
> Object 92fb65ec25e8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5
> kkk.
> Redzone 92fb65ec25f8: bb bb bb bb bb bb bb bb
>
> Padding 92fb65ec2738: 5a 5a 5a 5a 5a 5a 5a 5a
>
> CPU: 3 PID: 180 Comm: kworker/3:2 Tainted: GBU
> 4.10.0-rc6-patser+ #5039
> Hardware name: /NUC5PPYB, BIOS
> PYBSWCEL.86A.0031.2015.0601.1712 06/01/2015
> Workqueue: events intel_atomic_helper_free_state [i915]
> Call Trace:
> dump_stack+0x4d/0x6d
> print_trailer+0x20c/0x220
> free_debug_processing+0x1c6/0x330
> ? drm_atomic_state_default_clear+0xf7/0x1c0 [drm]
> __slab_free+0x48/0x2e0
> ? drm_atomic_state_default_clear+0xf7/0x1c0 [drm]
> kfree+0x159/0x1a0
> drm_atomic_state_default_clear+0xf7/0x1c0 [drm]
> ? drm_atomic_state_clear+0x30/0x30 [drm]
> intel_atomic_state_clear+0xd/0x20 [i915]
> drm_atomic_state_clear+0x1a/0x30 [drm]
> __drm_atomic_state_free+0x13/0x60 [drm]
> intel_atomic_helper_free_state+0x5d/0x70 [i915]
> process_one_work+0x260/0x4a0
> worker_thread+0x2d1/0x4f0
> kthread+0x127/0x130
> ? process_one_work+0x4a0/0x4a0
> ? kthread_stop+0x120/0x120
> ret_from_fork+0x29/0x40
> FIX kmalloc-128: Object at 0x92fb65ec2578 not freed
>
> Fixes: 3b24f7d67581 ("drm/atomic: Add struct drm_crtc_commit to track async
> updates")
> Fixes: 9626014258a5 ("drm/fence: add in-fences support")
> Cc: # v4.8+
> Cc: Daniel Vetter
> Signed-off-by: Maarten Lankhorst
> Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_atomic.c | 13 -
> 1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 50f5cf7b69d1..fdfb1ec17e66 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -2032,13 +2032,16 @@ static void complete_crtc_signaling(struct drm_device
> *dev,
> }
>
> for_each_crtc_in_state(state, crtc, crtc_state, i) {
> + struct drm_pending_vblank_event *event = crtc_state->event;
> /*
> - * TEST_ONLY and
Re: [Intel-gfx] [Linux v4.10.0-rc1+] Still call-traces after suspend-resume (pm? i915? cpu/hotplug?)
On 1/31/2017 1:02 PM, Imre Deak wrote:
On Tue, Jan 31, 2017 at 12:39:35PM +0100, Rafael J. Wysocki wrote:
On 1/31/2017 11:58 AM, Imre Deak wrote:
Hi Rafael,
Hi,
On Mon, Jan 30, 2017 at 11:44:37PM +0100, Rafael J. Wysocki wrote:
On 1/24/2017 2:33 AM, Sedat Dilek wrote:
On Fri, Dec 30, 2016 at 3:02 PM, Rafael J. Wysocki wrote:
On Fri, Dec 30, 2016 at 12:40 PM, Sedat Dilek wrote:
Hi,
I have already reported this issue in [1].
One of the issue was solved.
Unfortunately, it looks like there is still a different problem here
(Ubuntu/precise AMD64).
I tried v4.10-rc1 and latest Linus tree up to...
commit 98473f9f3f9bd404873cd1178c8be7d6d619f0d1
"mm/filemap: fix parameters to test_bit()"
Here we go...
[ 29.636047] BUG: sleeping function called from invalid context at
drivers/base/power/runtime.c:1032
[ 29.636055] in_atomic(): 1, irqs_disabled(): 0, pid: 1500, name: Xorg
[ 29.636058] 1 lock held by Xorg/1500:
[ 29.636060] #0: (&dev->struct_mutex){+.+.+.}, at:
[] i915_mutex_lock_interruptible+0x43/0x140 [i915]
[ 29.636107] CPU: 0 PID: 1500 Comm: Xorg Not tainted
4.10.0-rc1-6-iniza-amd64 #1
[ 29.636109] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
[ 29.636111] Call Trace:
[ 29.636120] dump_stack+0x85/0xc2
[ 29.636124] ___might_sleep+0x196/0x260
[ 29.636127] __might_sleep+0x53/0xb0
[ 29.636131] __pm_runtime_resume+0x7a/0x90
[ 29.636159] intel_runtime_pm_get+0x25/0x90 [i915]
[ 29.636189] aliasing_gtt_bind_vma+0xaa/0xf0 [i915]
[ 29.636220] i915_vma_bind+0xaf/0x1e0 [i915]
[ 29.636248] i915_gem_execbuffer_relocate_entry+0x513/0x6f0 [i915]
[ 29.636272] i915_gem_execbuffer_relocate_vma.isra.34+0x188/0x250 [i915]
[ 29.636275] ? trace_hardirqs_on+0xd/0x10
[ 29.636294] ? i915_gem_execbuffer_reserve_vma.isra.31+0x152/0x1f0 [i915]
[ 29.636316] ? i915_gem_execbuffer_reserve.isra.32+0x372/0x3a0 [i915]
[ 29.636342] i915_gem_do_execbuffer.isra.38+0xa70/0x1a40 [i915]
[ 29.636347] ? __might_fault+0x4e/0xb0
[ 29.636373] i915_gem_execbuffer2+0xc5/0x260 [i915]
[ 29.636376] ? __might_fault+0x4e/0xb0
[ 29.636395] drm_ioctl+0x206/0x450 [drm]
[ 29.636420] ? i915_gem_execbuffer+0x340/0x340 [i915]
[ 29.636425] ? __fget+0x5/0x200
[ 29.636429] do_vfs_ioctl+0x91/0x6f0
[ 29.636431] ? __fget+0x111/0x200
[ 29.636433] ? __fget+0x5/0x200
[ 29.636436] SyS_ioctl+0x79/0x90
[ 29.636441] entry_SYSCALL_64_fastpath+0x23/0xc6
On suspend/resume I see the same call trace.
[2] points to the "BUG" line.
Well, this appears to be an i915 issue, but not a serious one.
Clearly, a function that may sleep (pm_runtime_get_sync() in
intel_runtime_pm_get()) is called with disabled interrupts. If I
understand the code correctly, though, it actually is not going to
sleep in this particular case, because pm_runtime_get_sync() has
already been called once for this device in the same code path which
means that this particular instance will return immediately, so this
is a false-positive (most likely).
Not sure what's the root cause, but thought to clarify the above:
Yes, i915_gem_do_execbuffer() does take an RPM reference to optimize
things, so the RPM get in aliasing_gtt_bind_vma() won't need to resume
the device on this path. This isn't a guarantee though,
aliasing_gtt_bind_vma() could be called from other places without an RPM
reference. So preemption being disabled at that point is not
intentional. I also can't see where on the above path it would get
disabled due to a bug or otherwise.
The i915 code is correct AFAICS, but the core complains about a nested
invocation of pm_runtime_get_sync() with disabled interrupts (which looks OK
though), so the complaint is a false positive.
Well, my point was that interrupts (or preemption) doesn't seem to get
disabled anywhere on that path.
But the might_sleep_if() assertion in __pm_runtime_resume() triggers for
some reason. I wonder why then?
Of course, I may be overlooking something in the i915 code.
In any case, if you do
pm_runtime_get_sync(dev)
local_irq_disable()
pm_runtime_get_sync(dev)
pm_runtime_put(dev)
local_irq_enable()
pm_runtime_put(dev)
that is technically correct, but it will cause the core to complain.
Thanks,
Rafael
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 26/38] drm/i915: Exercise filling the top/bottom portions of the ppgtt
On to, 2017-01-19 at 11:41 +, Chris Wilson wrote:
> Allocate objects with varying number of pages (which should hopefully
> consist of a mixture of contiguous page chunks and so coalesced sg
> lists) and check that the sg walkers in insert_pages cope.
>
> Signed-off-by: Chris Wilson
> +static int fill_hole(struct drm_i915_private *i915,
> + struct i915_address_space *vm,
> + u64 hole_start, u64 hole_end,
> + unsigned long end_time)
> +{
> + const u64 hole_size = hole_end - hole_start;
> + struct drm_i915_gem_object *obj;
> + const unsigned long max_pages =
> + min_t(u64, 1 << 20, hole_size/2 >> PAGE_SHIFT);
At least make a comment, why this specific number. It's good to know if
something is a hard limit vs. pulled out of thin air.
> + for_each_prime_number_from(prime, 2, 13) {
SMALL_PRIME_MAX or something similar? Also, what are we targeting with
the selected number, staying below X bytes, N seconds or what?
I think all the tests could be clarified with such comments.
> + GEM_BUG_ON(!full_size);
This could be in huge_gem_object too?
> + obj = huge_gem_object(i915, PAGE_SIZE, full_size);
> + if (IS_ERR(obj))
> + break;
> +
> + list_add(&obj->batch_pool_link, &objects);
> +
> + /* Align differing sized objects against the edges, and
> + * check we don't walk off into the void when binding
> + * them into the GTT.
> + */
> + for (p = phases; p->name; p++) {
> + u64 flags;
> +
> + flags = p->base;
"offset" and "flags" could be separate variables, just for readability
as this is a test.
> + list_for_each_entry(obj, &objects,
> batch_pool_link) {
> + vma = i915_vma_instance(obj, vm, NULL);
> + if (IS_ERR(vma))
> + continue;
> +
> + err = i915_vma_pin(vma, 0, 0, flags);
> + if (err) {
> + pr_err("Fill %s pin failed with
> err=%d on size=%lu pages (prime=%lu), flags=%llx\n", p->name, err, npages,
> prime, flags);
> + goto err;
> + }
> +
> + i915_vma_unpin(vma);
> +
> + flags += p->step;
> + if (flags < hole_start ||
> + flags > hole_end)
This is also why I'd prefer the variables to be separate, you could
check <= and >= .
> + break;
Make a comment for this block, each previous object is smaller, and
that we rely on the list for ordering.
Even when the lack of comments tried to deceive me, I think I
understood it right;
Reviewed-by: Joonas Lahtinen
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/atomic: Fix double free in drm_atomic_state_default_clear
On Tue, Jan 31, 2017 at 10:04:09AM -0200, Gustavo Padovan wrote:
> Hi Maarten,
>
> 2017-01-31 Maarten Lankhorst :
>
> > drm_atomic_helper_page_flip and drm_atomic_ioctl set their own events
> > in crtc_state->event. But when it's set the event is freed in 2 places.
> >
> > Solve this by only freeing the event in the atomic ioctl when it
> > allocated its own event.
> >
> > This has been broken twice. The first time when the code was introduced,
> > but only in the corner case when an event is allocated, but more crtc's
> > were included by atomic check and then failing. This can mostly
> > happen when you do an atomic modeset in i915 and the display clock is
> > changed, which forces all crtc's to be included to the state.
> >
> > This has been broken worse by adding in-fences support, which caused
> > the double free to be done unconditionally.
> >
> > [IGT] kms_rotation_crc: starting subtest primary-rotation-180
> > =
> > BUG kmalloc-128 (Tainted: G U ): Object already free
> > -
> >
> > Disabling lock debugging due to kernel taint
> > INFO: Allocated in drm_atomic_helper_setup_commit+0x285/0x2f0
> > [drm_kms_helper] age=0 cpu=3 pid=1529
> > ___slab_alloc+0x308/0x3b0
> > __slab_alloc+0xd/0x20
> > kmem_cache_alloc_trace+0x92/0x1c0
> > drm_atomic_helper_setup_commit+0x285/0x2f0 [drm_kms_helper]
> > intel_atomic_commit+0x35/0x4f0 [i915]
> > drm_atomic_commit+0x46/0x50 [drm]
> > drm_mode_atomic_ioctl+0x7d4/0xab0 [drm]
> > drm_ioctl+0x2b3/0x490 [drm]
> > do_vfs_ioctl+0x69c/0x700
> > SyS_ioctl+0x4e/0x80
> > entry_SYSCALL_64_fastpath+0x13/0x94
> > INFO: Freed in drm_event_cancel_free+0xa3/0xb0 [drm] age=0 cpu=3 pid=1529
> > __slab_free+0x48/0x2e0
> > kfree+0x159/0x1a0
> > drm_event_cancel_free+0xa3/0xb0 [drm]
> > drm_mode_atomic_ioctl+0x86d/0xab0 [drm]
> > drm_ioctl+0x2b3/0x490 [drm]
> > do_vfs_ioctl+0x69c/0x700
> > SyS_ioctl+0x4e/0x80
> > entry_SYSCALL_64_fastpath+0x13/0x94
> > INFO: Slab 0xde1f0997b080 objects=17 used=2 fp=0x92fb65ec2578
> > flags=0x2008101
> > INFO: Object 0x92fb65ec2578 @offset=1400 fp=0x92fb65ec2ae8
> >
> > Redzone 92fb65ec2570: bb bb bb bb bb bb bb bb
> >
> > Object 92fb65ec2578: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> >
> > Object 92fb65ec2588: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> >
> > Object 92fb65ec2598: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> >
> > Object 92fb65ec25a8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> >
> > Object 92fb65ec25b8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> >
> > Object 92fb65ec25c8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> >
> > Object 92fb65ec25d8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> >
> > Object 92fb65ec25e8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5
> > kkk.
> > Redzone 92fb65ec25f8: bb bb bb bb bb bb bb bb
> >
> > Padding 92fb65ec2738: 5a 5a 5a 5a 5a 5a 5a 5a
> >
> > CPU: 3 PID: 180 Comm: kworker/3:2 Tainted: GBU
> > 4.10.0-rc6-patser+ #5039
> > Hardware name: /NUC5PPYB, BIOS
> > PYBSWCEL.86A.0031.2015.0601.1712 06/01/2015
> > Workqueue: events intel_atomic_helper_free_state [i915]
> > Call Trace:
> > dump_stack+0x4d/0x6d
> > print_trailer+0x20c/0x220
> > free_debug_processing+0x1c6/0x330
> > ? drm_atomic_state_default_clear+0xf7/0x1c0 [drm]
> > __slab_free+0x48/0x2e0
> > ? drm_atomic_state_default_clear+0xf7/0x1c0 [drm]
> > kfree+0x159/0x1a0
> > drm_atomic_state_default_clear+0xf7/0x1c0 [drm]
> > ? drm_atomic_state_clear+0x30/0x30 [drm]
> > intel_atomic_state_clear+0xd/0x20 [i915]
> > drm_atomic_state_clear+0x1a/0x30 [drm]
> > __drm_atomic_state_free+0x13/0x60 [drm]
> > intel_atomic_helper_free_state+0x5d/0x70 [i915]
> > process_one_work+0x260/0x4a0
> > worker_thread+0x2d1/0x4f0
> > kthread+0x127/0x130
> > ? process_one_work+0x4a0/0x4a0
> > ? kthread_stop+0x120/0x120
> > ret_from_fork+0x29/0x40
> > FIX kmalloc-128: Object at 0x92fb65ec2578 not freed
> >
> > Fixes: 3b24f7d67581 ("drm/atomic: Add struct drm_crtc_commit to track async
> > updates")
> > Fixes: 9626014258a5 ("drm/fence: add in-fences support")
> > Cc: # v4.8+
> > Cc: Daniel Vetter
> > Signed-off-by: Maarten Lankhorst
> > Reviewed-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/drm_atomic.c | 13 -
> > 1 file changed, 8 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index 50f5cf7b69d1..fdfb1ec17e66 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomi
Re: [Intel-gfx] [Linux v4.10.0-rc1+] Still call-traces after suspend-resume (pm? i915? cpu/hotplug?)
On Tue, Jan 31, 2017 at 01:12:05PM +0100, Rafael J. Wysocki wrote:
> On 1/31/2017 1:02 PM, Imre Deak wrote:
> >On Tue, Jan 31, 2017 at 12:39:35PM +0100, Rafael J. Wysocki wrote:
> >>On 1/31/2017 11:58 AM, Imre Deak wrote:
> >>>Hi Rafael,
> >>Hi,
> >>
> >>>On Mon, Jan 30, 2017 at 11:44:37PM +0100, Rafael J. Wysocki wrote:
> On 1/24/2017 2:33 AM, Sedat Dilek wrote:
> >On Fri, Dec 30, 2016 at 3:02 PM, Rafael J. Wysocki
> >wrote:
> >>On Fri, Dec 30, 2016 at 12:40 PM, Sedat Dilek
> >>wrote:
> >>>Hi,
> >>>
> >>>I have already reported this issue in [1].
> >>>One of the issue was solved.
> >>>Unfortunately, it looks like there is still a different problem here
> >>>(Ubuntu/precise AMD64).
> >>>
> >>>I tried v4.10-rc1 and latest Linus tree up to...
> >>>
> >>>commit 98473f9f3f9bd404873cd1178c8be7d6d619f0d1
> >>>"mm/filemap: fix parameters to test_bit()"
> >>>
> >>>Here we go...
> >>>
> >>>[ 29.636047] BUG: sleeping function called from invalid context at
> >>>drivers/base/power/runtime.c:1032
> >>>[ 29.636055] in_atomic(): 1, irqs_disabled(): 0, pid: 1500, name:
> >>>Xorg
> >>>[ 29.636058] 1 lock held by Xorg/1500:
> >>>[ 29.636060] #0: (&dev->struct_mutex){+.+.+.}, at:
> >>>[] i915_mutex_lock_interruptible+0x43/0x140 [i915]
> >>>[ 29.636107] CPU: 0 PID: 1500 Comm: Xorg Not tainted
> >>>4.10.0-rc1-6-iniza-amd64 #1
> >>>[ 29.636109] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
> >>>530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
> >>>[ 29.636111] Call Trace:
> >>>[ 29.636120] dump_stack+0x85/0xc2
> >>>[ 29.636124] ___might_sleep+0x196/0x260
> >>>[ 29.636127] __might_sleep+0x53/0xb0
> >>>[ 29.636131] __pm_runtime_resume+0x7a/0x90
> >>>[ 29.636159] intel_runtime_pm_get+0x25/0x90 [i915]
> >>>[ 29.636189] aliasing_gtt_bind_vma+0xaa/0xf0 [i915]
> >>>[ 29.636220] i915_vma_bind+0xaf/0x1e0 [i915]
> >>>[ 29.636248] i915_gem_execbuffer_relocate_entry+0x513/0x6f0 [i915]
> >>>[ 29.636272] i915_gem_execbuffer_relocate_vma.isra.34+0x188/0x250
> >>>[i915]
> >>>[ 29.636275] ? trace_hardirqs_on+0xd/0x10
> >>>[ 29.636294] ? i915_gem_execbuffer_reserve_vma.isra.31+0x152/0x1f0
> >>>[i915]
> >>>[ 29.636316] ? i915_gem_execbuffer_reserve.isra.32+0x372/0x3a0
> >>>[i915]
> >>>[ 29.636342] i915_gem_do_execbuffer.isra.38+0xa70/0x1a40 [i915]
> >>>[ 29.636347] ? __might_fault+0x4e/0xb0
> >>>[ 29.636373] i915_gem_execbuffer2+0xc5/0x260 [i915]
> >>>[ 29.636376] ? __might_fault+0x4e/0xb0
> >>>[ 29.636395] drm_ioctl+0x206/0x450 [drm]
> >>>[ 29.636420] ? i915_gem_execbuffer+0x340/0x340 [i915]
> >>>[ 29.636425] ? __fget+0x5/0x200
> >>>[ 29.636429] do_vfs_ioctl+0x91/0x6f0
> >>>[ 29.636431] ? __fget+0x111/0x200
> >>>[ 29.636433] ? __fget+0x5/0x200
> >>>[ 29.636436] SyS_ioctl+0x79/0x90
> >>>[ 29.636441] entry_SYSCALL_64_fastpath+0x23/0xc6
> >>>
> >>>On suspend/resume I see the same call trace.
> >>>[2] points to the "BUG" line.
> >>Well, this appears to be an i915 issue, but not a serious one.
> >>
> >>Clearly, a function that may sleep (pm_runtime_get_sync() in
> >>intel_runtime_pm_get()) is called with disabled interrupts. If I
> >>understand the code correctly, though, it actually is not going to
> >>sleep in this particular case, because pm_runtime_get_sync() has
> >>already been called once for this device in the same code path which
> >>means that this particular instance will return immediately, so this
> >>is a false-positive (most likely).
> >>>Not sure what's the root cause, but thought to clarify the above:
> >>>
> >>>Yes, i915_gem_do_execbuffer() does take an RPM reference to optimize
> >>>things, so the RPM get in aliasing_gtt_bind_vma() won't need to resume
> >>>the device on this path. This isn't a guarantee though,
> >>>aliasing_gtt_bind_vma() could be called from other places without an RPM
> >>>reference. So preemption being disabled at that point is not
> >>>intentional. I also can't see where on the above path it would get
> >>>disabled due to a bug or otherwise.
> >>The i915 code is correct AFAICS, but the core complains about a nested
> >>invocation of pm_runtime_get_sync() with disabled interrupts (which looks OK
> >>though), so the complaint is a false positive.
> >Well, my point was that interrupts (or preemption) doesn't seem to get
> >disabled anywhere on that path.
>
> But the might_sleep_if() assertion in __pm_runtime_resume() triggers for
> some reason. I wonder why then?
>
> Of course, I may be overlooking something in the i915 code.
>
> In any case, if you do
>
> pm_runtime_get_sync(dev)
> local_irq_disable()
> pm_runtime_get_sync(dev)
>
> pm_runtime_put(dev)
> local_irq_enable()
> pm_runtime_put(dev)
>
> that is technica
[Intel-gfx] [PATCH 09/10] drm/i915: Pass file_priv to eb_select_engine
From: Tvrtko Ursulin
file_priv is what it needs to pass on to gen8_dispatch_bsd_engine so
simplify things by passing it straight away.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index ae94cc27c9ba..ff102b39c3b3 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1496,10 +1496,8 @@ execbuf_submit(struct drm_i915_gem_request *req, u32
batch_start,
*/
static unsigned int
gen8_dispatch_bsd_engine(struct drm_i915_private *dev_priv,
-struct drm_file *file)
+struct drm_i915_file_private *file_priv)
{
- struct drm_i915_file_private *file_priv = file->driver_priv;
-
/* Check whether the file_priv has already selected one ring. */
if ((int)file_priv->bsd_engine < 0)
file_priv->bsd_engine = atomic_fetch_xor(1,
@@ -1519,8 +1517,8 @@ static const enum intel_engine_id
user_ring_map[I915_USER_RINGS + 1] = {
};
static struct intel_engine_cs *
-eb_select_engine(struct drm_i915_private *dev_priv, struct drm_file *file,
-u64 flags)
+eb_select_engine(struct drm_i915_private *dev_priv,
+struct drm_i915_file_private *file_priv, u64 flags)
{
unsigned int user_ring_id = flags & I915_EXEC_RING_MASK;
struct intel_engine_cs *engine;
@@ -1541,7 +1539,7 @@ eb_select_engine(struct drm_i915_private *dev_priv,
struct drm_file *file,
unsigned int bsd_idx = flags & I915_EXEC_BSD_MASK;
if (bsd_idx == I915_EXEC_BSD_DEFAULT) {
- bsd_idx = gen8_dispatch_bsd_engine(dev_priv, file);
+ bsd_idx = gen8_dispatch_bsd_engine(dev_priv, file_priv);
} else if (bsd_idx >= I915_EXEC_BSD_RING1 &&
bsd_idx <= I915_EXEC_BSD_RING2) {
bsd_idx >>= I915_EXEC_BSD_SHIFT;
@@ -1603,7 +1601,7 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
if (args->flags & I915_EXEC_IS_PINNED)
dispatch_flags |= I915_DISPATCH_PINNED;
- engine = eb_select_engine(dev_priv, file, args->flags);
+ engine = eb_select_engine(dev_priv, file->driver_priv, args->flags);
if (!engine)
return -EINVAL;
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 03/10] drm/i915: Tidy execbuf_submit
From: Tvrtko Ursulin
Use a local variable for storing the request and engine
and at the same time drop the engine field from
i915_execbuffer_params since it is available from the
request.
textdata bss dec hex filename
1085402 263982628 1114428 11013c i915.ko.0
1085354 263982628 1114380 11010c i915.ko.1
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 35 +++---
1 file changed, 17 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 2991751516f8..119322eb9897 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -53,7 +53,6 @@ struct i915_execbuffer_params {
struct i915_vma *batch;
u32 dispatch_flags;
u32 batch_start;
- struct intel_engine_cs *engine;
struct drm_i915_gem_request *request;
};
@@ -1410,17 +1409,19 @@ execbuf_submit(struct i915_execbuffer_params *params,
struct drm_i915_gem_execbuffer2 *args,
struct list_head *vmas)
{
- struct drm_i915_private *dev_priv = params->request->i915;
+ struct drm_i915_gem_request *req = params->request;
+ struct drm_i915_private *dev_priv = req->i915;
+ struct intel_engine_cs *engine = req->engine;
u64 exec_start, exec_len;
int instp_mode;
u32 instp_mask;
int ret;
- ret = i915_gem_execbuffer_move_to_gpu(params->request, vmas);
+ ret = i915_gem_execbuffer_move_to_gpu(req, vmas);
if (ret)
return ret;
- ret = i915_switch_context(params->request);
+ ret = i915_switch_context(req);
if (ret)
return ret;
@@ -1430,25 +1431,25 @@ execbuf_submit(struct i915_execbuffer_params *params,
case I915_EXEC_CONSTANTS_REL_GENERAL:
case I915_EXEC_CONSTANTS_ABSOLUTE:
case I915_EXEC_CONSTANTS_REL_SURFACE:
- if (instp_mode != 0 && params->engine->id != RCS) {
+ if (instp_mode != 0 && engine->id != RCS) {
DRM_DEBUG("non-0 rel constants mode on non-RCS\n");
return -EINVAL;
}
if (instp_mode != dev_priv->relative_constants_mode) {
- if (INTEL_INFO(dev_priv)->gen < 4) {
+ if (INTEL_GEN(dev_priv) < 4) {
DRM_DEBUG("no rel constants on pre-gen4\n");
return -EINVAL;
}
- if (INTEL_INFO(dev_priv)->gen > 5 &&
+ if (INTEL_GEN(dev_priv) > 5 &&
instp_mode == I915_EXEC_CONSTANTS_REL_SURFACE) {
DRM_DEBUG("rel surface constants mode invalid
on gen5+\n");
return -EINVAL;
}
/* The HW changed the meaning on this bit on gen6 */
- if (INTEL_INFO(dev_priv)->gen >= 6)
+ if (INTEL_GEN(dev_priv) >= 6)
instp_mask &= ~I915_EXEC_CONSTANTS_REL_SURFACE;
}
break;
@@ -1457,11 +1458,11 @@ execbuf_submit(struct i915_execbuffer_params *params,
return -EINVAL;
}
- if (params->engine->id == RCS &&
+ if (engine->id == RCS &&
instp_mode != dev_priv->relative_constants_mode) {
- struct intel_ring *ring = params->request->ring;
+ struct intel_ring *ring = req->ring;
- ret = intel_ring_begin(params->request, 4);
+ ret = intel_ring_begin(req, 4);
if (ret)
return ret;
@@ -1475,7 +1476,7 @@ execbuf_submit(struct i915_execbuffer_params *params,
}
if (args->flags & I915_EXEC_GEN7_SOL_RESET) {
- ret = i915_reset_gen7_sol_offsets(params->request);
+ ret = i915_reset_gen7_sol_offsets(req);
if (ret)
return ret;
}
@@ -1486,15 +1487,14 @@ execbuf_submit(struct i915_execbuffer_params *params,
if (exec_len == 0)
exec_len = params->batch->size - params->batch_start;
- ret = params->engine->emit_bb_start(params->request,
- exec_start, exec_len,
- params->dispatch_flags);
+ ret = engine->emit_bb_start(req, exec_start, exec_len,
+ params->dispatch_flags);
if (ret)
return ret;
- trace_i915_gem_ring_dispatch(params->request, params->dispatch_flags);
+ trace_i915_gem_ring_dispatch(req, params->dispatch_flags);
- i915_gem_execbuffer_move_to_active(vmas, params->r
[Intel-gfx] [PATCH 00/10] do_execbuffer tidy
From: Tvrtko Ursulin I've noticed a few opportunities to improve the readability of this functions and then kept spotting more and more which can be removed or compacted. Eventually ended up with removing i915_execbuffer_params completely. But I think it's OK since the plan between when it was added to now changed. Overall reduction in source and binary, hopefully for tidier code. textdata bss dec hex filename 1085466 263982628 1114492 11017c i915.ko.0 1085290 263982628 1114316 1100cc i915.ko.1 Tvrtko Ursulin (10): drm/i915: Tidy i915_gem_do_execbuffer drm/i915: Drop some unused fields from i915_execbuffer_params drm/i915: Tidy execbuf_submit drm/i915: Remove batch field from i915_execbuffer_params drm/i915: Nuke i915_execbuffer_params drm/i915: Remove some single use locals i915_gem_do_execbuffer drm/i915: Drop unused engine parameter from i915_gem_validate_context drm/i915: eb_engine_select only needs flags drm/i915: Pass file_priv to eb_select_engine drm/i915: Remove some unecessary line breaks drivers/gpu/drm/i915/i915_gem_execbuffer.c | 159 +++-- 1 file changed, 60 insertions(+), 99 deletions(-) -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 04/10] drm/i915: Remove batch field from i915_execbuffer_params
From: Tvrtko Ursulin
Also redundant since it is stored in the request.
textdata bss dec hex filename
1085354 263982628 1114380 11010c i915.ko.0
1085338 263982628 1114364 1100fc i915.ko.1
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 119322eb9897..afbb56196162 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -50,7 +50,6 @@
#define BATCH_OFFSET_BIAS (256*1024)
struct i915_execbuffer_params {
- struct i915_vma *batch;
u32 dispatch_flags;
u32 batch_start;
struct drm_i915_gem_request *request;
@@ -1482,10 +1481,10 @@ execbuf_submit(struct i915_execbuffer_params *params,
}
exec_len = args->batch_len;
- exec_start = params->batch->node.start + params->batch_start;
+ exec_start = req->batch->node.start + params->batch_start;
if (exec_len == 0)
- exec_len = params->batch->size - params->batch_start;
+ exec_len = req->batch->size - params->batch_start;
ret = engine->emit_bb_start(req, exec_start, exec_len,
params->dispatch_flags);
@@ -1832,7 +1831,6 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
* scheduler arrives.
*/
params.dispatch_flags = dispatch_flags;
- params.batch = batch;
params.batch_start= batch_start_offset;
params.request= req;
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 10/10] drm/i915: Remove some unecessary line breaks
From: Tvrtko Ursulin
Just spotted a few lines which fit in 80 chars and were split.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index ff102b39c3b3..18312959f961 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1066,8 +1066,7 @@ i915_gem_execbuffer_relocate_slow(struct drm_device *dev,
goto err;
need_relocs = (args->flags & I915_EXEC_NO_RELOC) == 0;
- ret = i915_gem_execbuffer_reserve(engine, &eb->vmas, ctx,
- &need_relocs);
+ ret = i915_gem_execbuffer_reserve(engine, &eb->vmas, ctx, &need_relocs);
if (ret)
goto err;
@@ -1682,8 +1681,7 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
/* Move the objects en-masse into the GTT, evicting if necessary. */
need_relocs = (args->flags & I915_EXEC_NO_RELOC) == 0;
- ret = i915_gem_execbuffer_reserve(engine, &eb->vmas, ctx,
- &need_relocs);
+ ret = i915_gem_execbuffer_reserve(engine, &eb->vmas, ctx, &need_relocs);
if (ret)
goto err;
@@ -1693,8 +1691,8 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
if (ret) {
if (ret == -EFAULT) {
ret = i915_gem_execbuffer_relocate_slow(dev, args, file,
- engine,
- eb, exec, ctx);
+ engine, eb,
+ exec, ctx);
BUG_ON(!mutex_is_locked(&dev->struct_mutex));
}
if (ret)
@@ -1719,8 +1717,7 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
struct i915_vma *vma;
vma = i915_gem_execbuffer_parse(engine, &shadow_exec_entry,
- batch->obj,
- eb,
+ batch->obj, eb,
args->batch_start_offset,
args->batch_len,
drm_is_current_master(file));
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 05/10] drm/i915: Nuke i915_execbuffer_params
From: Tvrtko Ursulin
Now that it only contains three parameters we can pass them
directly to execbuf_submit just as well.
No effect on generated binary, just a source reduction.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 39 --
1 file changed, 10 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index afbb56196162..82e74db5923b 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -49,12 +49,6 @@
#define BATCH_OFFSET_BIAS (256*1024)
-struct i915_execbuffer_params {
- u32 dispatch_flags;
- u32 batch_start;
- struct drm_i915_gem_request *request;
-};
-
struct eb_vmas {
struct drm_i915_private *i915;
struct list_head vmas;
@@ -1404,11 +1398,10 @@ i915_gem_execbuffer_parse(struct intel_engine_cs
*engine,
}
static int
-execbuf_submit(struct i915_execbuffer_params *params,
- struct drm_i915_gem_execbuffer2 *args,
+execbuf_submit(struct drm_i915_gem_request *req, u32 batch_start,
+ u32 dispatch_flags, struct drm_i915_gem_execbuffer2 *args,
struct list_head *vmas)
{
- struct drm_i915_gem_request *req = params->request;
struct drm_i915_private *dev_priv = req->i915;
struct intel_engine_cs *engine = req->engine;
u64 exec_start, exec_len;
@@ -1481,17 +1474,16 @@ execbuf_submit(struct i915_execbuffer_params *params,
}
exec_len = args->batch_len;
- exec_start = req->batch->node.start + params->batch_start;
+ exec_start = req->batch->node.start + batch_start;
if (exec_len == 0)
- exec_len = req->batch->size - params->batch_start;
+ exec_len = req->batch->size - batch_start;
- ret = engine->emit_bb_start(req, exec_start, exec_len,
- params->dispatch_flags);
+ ret = engine->emit_bb_start(req, exec_start, exec_len, dispatch_flags);
if (ret)
return ret;
- trace_i915_gem_ring_dispatch(req, params->dispatch_flags);
+ trace_i915_gem_ring_dispatch(req, dispatch_flags);
i915_gem_execbuffer_move_to_active(vmas, req);
@@ -1589,8 +1581,7 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
struct i915_address_space *vm;
struct drm_i915_gem_request *req;
struct i915_vma *batch;
- u32 batch_start_offset;
- struct i915_execbuffer_params params;
+ u32 batch_start;
const u32 ctx_id = i915_execbuffer2_get_context_id(*args);
u32 dispatch_flags;
struct dma_fence *in_fence = NULL;
@@ -1732,7 +1723,7 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
goto err;
}
- batch_start_offset = args->batch_start_offset;
+ batch_start = args->batch_start_offset;
if (engine->needs_cmd_parser && args->batch_len) {
struct i915_vma *vma;
@@ -1758,7 +1749,7 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
* command parser has accepted.
*/
dispatch_flags |= I915_DISPATCH_SECURE;
- batch_start_offset = 0;
+ batch_start = 0;
batch = vma;
}
}
@@ -1824,17 +1815,7 @@ i915_gem_do_execbuffer(struct drm_device *dev, void
*data,
if (ret)
goto err_request;
- /*
-* Save assorted stuff away to pass through to *_submission().
-* NB: This data should be 'persistent' and not local as it will
-* kept around beyond the duration of the IOCTL once the GPU
-* scheduler arrives.
-*/
- params.dispatch_flags = dispatch_flags;
- params.batch_start= batch_start_offset;
- params.request= req;
-
- ret = execbuf_submit(¶ms, args, &eb->vmas);
+ ret = execbuf_submit(req, batch_start, dispatch_flags, args, &eb->vmas);
err_request:
__i915_add_request(req, ret == 0);
if (out_fence) {
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 08/10] drm/i915: eb_engine_select only needs flags
From: Tvrtko Ursulin
Not the whole args struct needs to be passed in.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 51cf3ff3e21d..ae94cc27c9ba 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1519,11 +1519,10 @@ static const enum intel_engine_id
user_ring_map[I915_USER_RINGS + 1] = {
};
static struct intel_engine_cs *
-eb_select_engine(struct drm_i915_private *dev_priv,
-struct drm_file *file,
-struct drm_i915_gem_execbuffer2 *args)
+eb_select_engine(struct drm_i915_private *dev_priv, struct drm_file *file,
+u64 flags)
{
- unsigned int user_ring_id = args->flags & I915_EXEC_RING_MASK;
+ unsigned int user_ring_id = flags & I915_EXEC_RING_MASK;
struct intel_engine_cs *engine;
if (user_ring_id > I915_USER_RINGS) {
@@ -1532,14 +1531,14 @@ eb_select_engine(struct drm_i915_private *dev_priv,
}
if ((user_ring_id != I915_EXEC_BSD) &&
- ((args->flags & I915_EXEC_BSD_MASK) != 0)) {
+ ((flags & I915_EXEC_BSD_MASK) != 0)) {
DRM_DEBUG("execbuf with non bsd ring but with invalid "
- "bsd dispatch flags: %d\n", (int)(args->flags));
+ "bsd dispatch flags: %d\n", (int)(flags));
return NULL;
}
if (user_ring_id == I915_EXEC_BSD && HAS_BSD2(dev_priv)) {
- unsigned int bsd_idx = args->flags & I915_EXEC_BSD_MASK;
+ unsigned int bsd_idx = flags & I915_EXEC_BSD_MASK;
if (bsd_idx == I915_EXEC_BSD_DEFAULT) {
bsd_idx = gen8_dispatch_bsd_engine(dev_priv, file);
@@ -1604,7 +1603,7 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
if (args->flags & I915_EXEC_IS_PINNED)
dispatch_flags |= I915_DISPATCH_PINNED;
- engine = eb_select_engine(dev_priv, file, args);
+ engine = eb_select_engine(dev_priv, file, args->flags);
if (!engine)
return -EINVAL;
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 01/10] drm/i915: Tidy i915_gem_do_execbuffer
From: Tvrtko Ursulin
Instead of sprinkling around usage and initialization of
i915_execbuffer_params we can consolidate it just before
execbuf_submit for maintability and readability.
That way we can also drop the memset since it becomes
easy to spot we initialize all the fields.
textdata bss dec hex filename
1085466 263982628 1114492 11017c i915.ko.0
1085402 263982628 1114428 11013c i915.ko.1
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 87 +++---
1 file changed, 44 insertions(+), 43 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 91c2393199a3..ee7b7bd17e29 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -50,14 +50,14 @@
#define BATCH_OFFSET_BIAS (256*1024)
struct i915_execbuffer_params {
- struct drm_device *dev;
- struct drm_file *file;
- struct i915_vma *batch;
- u32 dispatch_flags;
- u32 args_batch_start_offset;
- struct intel_engine_cs *engine;
- struct i915_gem_context *ctx;
- struct drm_i915_gem_request *request;
+ struct drm_device *dev;
+ struct drm_file *file;
+ struct i915_vma *batch;
+ u32 dispatch_flags;
+ u32 batch_start;
+ struct intel_engine_cs *engine;
+ struct i915_gem_context *ctx;
+ struct drm_i915_gem_request *request;
};
struct eb_vmas {
@@ -1484,11 +1484,10 @@ execbuf_submit(struct i915_execbuffer_params *params,
}
exec_len = args->batch_len;
- exec_start = params->batch->node.start +
-params->args_batch_start_offset;
+ exec_start = params->batch->node.start + params->batch_start;
if (exec_len == 0)
- exec_len = params->batch->size -
params->args_batch_start_offset;
+ exec_len = params->batch->size - params->batch_start;
ret = params->engine->emit_bb_start(params->request,
exec_start, exec_len,
@@ -1592,8 +1591,10 @@ i915_gem_do_execbuffer(struct drm_device *dev, void
*data,
struct intel_engine_cs *engine;
struct i915_gem_context *ctx;
struct i915_address_space *vm;
- struct i915_execbuffer_params params_master; /* XXX: will be removed
later */
- struct i915_execbuffer_params *params = ¶ms_master;
+ struct drm_i915_gem_request *req;
+ struct i915_vma *batch;
+ u32 batch_start_offset;
+ struct i915_execbuffer_params params;
const u32 ctx_id = i915_execbuffer2_get_context_id(*args);
u32 dispatch_flags;
struct dma_fence *in_fence = NULL;
@@ -1685,8 +1686,6 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
else
vm = &ggtt->base;
- memset(¶ms_master, 0x00, sizeof(params_master));
-
eb = eb_create(dev_priv, args);
if (eb == NULL) {
i915_gem_context_put(ctx);
@@ -1701,7 +1700,7 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
goto err;
/* take note of the batch buffer before we might reorder the lists */
- params->batch = eb_get_batch(eb);
+ batch = eb_get_batch(eb);
/* Move the objects en-masse into the GTT, evicting if necessary. */
need_relocs = (args->flags & I915_EXEC_NO_RELOC) == 0;
@@ -1725,24 +1724,24 @@ i915_gem_do_execbuffer(struct drm_device *dev, void
*data,
}
/* Set the pending read domains for the batch buffer to COMMAND */
- if (params->batch->obj->base.pending_write_domain) {
+ if (batch->obj->base.pending_write_domain) {
DRM_DEBUG("Attempting to use self-modifying batch buffer\n");
ret = -EINVAL;
goto err;
}
- if (args->batch_start_offset > params->batch->size ||
- args->batch_len > params->batch->size - args->batch_start_offset) {
+ if (args->batch_start_offset > batch->size ||
+ args->batch_len > batch->size - args->batch_start_offset) {
DRM_DEBUG("Attempting to use out-of-bounds batch\n");
ret = -EINVAL;
goto err;
}
- params->args_batch_start_offset = args->batch_start_offset;
+ batch_start_offset = args->batch_start_offset;
if (engine->needs_cmd_parser && args->batch_len) {
struct i915_vma *vma;
vma = i915_gem_execbuffer_parse(engine, &shadow_exec_entry,
- params->batch->obj,
+ batch->obj,
e
[Intel-gfx] [PATCH 07/10] drm/i915: Drop unused engine parameter from i915_gem_validate_context
From: Tvrtko Ursulin
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 57ae6573a37b..51cf3ff3e21d 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1222,7 +1222,7 @@ validate_exec_list(struct drm_device *dev,
static struct i915_gem_context *
i915_gem_validate_context(struct drm_device *dev, struct drm_file *file,
- struct intel_engine_cs *engine, const u32 ctx_id)
+ const u32 ctx_id)
{
struct i915_gem_context *ctx;
@@ -1656,7 +1656,7 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
if (ret)
goto pre_mutex_err;
- ctx = i915_gem_validate_context(dev, file, engine,
+ ctx = i915_gem_validate_context(dev, file,
i915_execbuffer2_get_context_id(*args));
if (IS_ERR(ctx)) {
mutex_unlock(&dev->struct_mutex);
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 06/10] drm/i915: Remove some single use locals i915_gem_do_execbuffer
From: Tvrtko Ursulin
Remove ctx_id, ggtt and vm since they are single use.
textdata bss dec hex filename
1085338 263982628 1114364 1100fc i915.ko.0
1085290 263982628 1114316 1100cc i915.ko.1
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 82e74db5923b..57ae6573a37b 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1573,16 +1573,13 @@ i915_gem_do_execbuffer(struct drm_device *dev, void
*data,
struct drm_i915_gem_exec_object2 *exec)
{
struct drm_i915_private *dev_priv = to_i915(dev);
- struct i915_ggtt *ggtt = &dev_priv->ggtt;
struct eb_vmas *eb;
struct drm_i915_gem_exec_object2 shadow_exec_entry;
struct intel_engine_cs *engine;
struct i915_gem_context *ctx;
- struct i915_address_space *vm;
struct drm_i915_gem_request *req;
struct i915_vma *batch;
u32 batch_start;
- const u32 ctx_id = i915_execbuffer2_get_context_id(*args);
u32 dispatch_flags;
struct dma_fence *in_fence = NULL;
struct sync_file *out_fence = NULL;
@@ -1659,7 +1656,8 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
if (ret)
goto pre_mutex_err;
- ctx = i915_gem_validate_context(dev, file, engine, ctx_id);
+ ctx = i915_gem_validate_context(dev, file, engine,
+ i915_execbuffer2_get_context_id(*args));
if (IS_ERR(ctx)) {
mutex_unlock(&dev->struct_mutex);
ret = PTR_ERR(ctx);
@@ -1668,11 +1666,6 @@ i915_gem_do_execbuffer(struct drm_device *dev, void
*data,
i915_gem_context_get(ctx);
- if (ctx->ppgtt)
- vm = &ctx->ppgtt->base;
- else
- vm = &ggtt->base;
-
eb = eb_create(dev_priv, args);
if (eb == NULL) {
i915_gem_context_put(ctx);
@@ -1682,7 +1675,8 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
}
/* Look up object handles */
- ret = eb_lookup_vmas(eb, exec, args, vm, file);
+ ret = eb_lookup_vmas(eb, exec, args, ctx->ppgtt ? &ctx->ppgtt->base :
+&dev_priv->ggtt.base, file);
if (ret)
goto err;
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 02/10] drm/i915: Drop some unused fields from i915_execbuffer_params
From: Tvrtko Ursulin
dev, file and ctx are unused.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index ee7b7bd17e29..2991751516f8 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -50,13 +50,10 @@
#define BATCH_OFFSET_BIAS (256*1024)
struct i915_execbuffer_params {
- struct drm_device *dev;
- struct drm_file *file;
struct i915_vma *batch;
u32 dispatch_flags;
u32 batch_start;
struct intel_engine_cs *engine;
- struct i915_gem_context *ctx;
struct drm_i915_gem_request *request;
};
@@ -1834,11 +1831,8 @@ i915_gem_do_execbuffer(struct drm_device *dev, void
*data,
* kept around beyond the duration of the IOCTL once the GPU
* scheduler arrives.
*/
- params.dev= dev;
- params.file = file;
params.engine = engine;
params.dispatch_flags = dispatch_flags;
- params.ctx= ctx;
params.batch = batch;
params.batch_start= batch_start_offset;
params.request= req;
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/10] do_execbuffer tidy
On Tue, Jan 31, 2017 at 01:15:36PM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > I've noticed a few opportunities to improve the readability of this functions > and then kept spotting more and more which can be removed or compacted. > > Eventually ended up with removing i915_execbuffer_params completely. But I > think > it's OK since the plan between when it was added to now changed. Most of it looks like churn duplicating patches I've already sent. :( We have an open performance regression bug (that has only gotten worse with multiple timelines) that I really would like to see some progress on. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/color: un-inline drm_color_lut_extract()
On Fri, 27 Jan 2017, Jani Nikula wrote:
> The function is not that big, but it's also not used for anything
> performance critical. Make it a normal function.
>
> As a side effect, this apparently makes sparse smarter about what it's
> doing, and gets rid of the warning:
>
> ./include/drm/drm_color_mgmt.h:53:28: warning: shift too big (4294967295) for
> type unsigned long
> ./include/drm/drm_color_mgmt.h:53:28: warning: cast truncates bits from
> constant value (8000 becomes 0)
>
> v2: rebased
>
> Cc: Lionel Landwerlin
> Reviewed-by: Daniel Vetter
> Reviewed-by: Lionel Landwerlin
> Signed-off-by: Jani Nikula
This time, pushed to drm-misc-next. Thanks for the review.
BR,
Jani.
> ---
> drivers/gpu/drm/drm_color_mgmt.c | 24
> include/drm/drm_color_mgmt.h | 27 ++-
> 2 files changed, 26 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_color_mgmt.c
> b/drivers/gpu/drm/drm_color_mgmt.c
> index 789b4c65cd69..cc23b9a505c0 100644
> --- a/drivers/gpu/drm/drm_color_mgmt.c
> +++ b/drivers/gpu/drm/drm_color_mgmt.c
> @@ -88,6 +88,30 @@
> */
>
> /**
> + * drm_color_lut_extract - clamp and round LUT entries
> + * @user_input: input value
> + * @bit_precision: number of bits the hw LUT supports
> + *
> + * Extract a degamma/gamma LUT value provided by user (in the form of
> + * &drm_color_lut entries) and round it to the precision supported by the
> + * hardware.
> + */
> +uint32_t drm_color_lut_extract(uint32_t user_input, uint32_t bit_precision)
> +{
> + uint32_t val = user_input;
> + uint32_t max = 0x >> (16 - bit_precision);
> +
> + /* Round only if we're not using full precision. */
> + if (bit_precision < 16) {
> + val += 1UL << (16 - bit_precision - 1);
> + val >>= 16 - bit_precision;
> + }
> +
> + return clamp_val(val, 0, max);
> +}
> +EXPORT_SYMBOL(drm_color_lut_extract);
> +
> +/**
> * drm_crtc_enable_color_mgmt - enable color management properties
> * @crtc: DRM CRTC
> * @degamma_lut_size: the size of the degamma lut (before CSC)
> diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h
> index d9c2f680f5ae..bce4a532836d 100644
> --- a/include/drm/drm_color_mgmt.h
> +++ b/include/drm/drm_color_mgmt.h
> @@ -25,6 +25,8 @@
>
> #include
>
> +uint32_t drm_color_lut_extract(uint32_t user_input, uint32_t bit_precision);
> +
> void drm_crtc_enable_color_mgmt(struct drm_crtc *crtc,
> uint degamma_lut_size,
> bool has_ctm,
> @@ -33,29 +35,4 @@ void drm_crtc_enable_color_mgmt(struct drm_crtc *crtc,
> int drm_mode_crtc_set_gamma_size(struct drm_crtc *crtc,
>int gamma_size);
>
> -/**
> - * drm_color_lut_extract - clamp and round LUT entries
> - * @user_input: input value
> - * @bit_precision: number of bits the hw LUT supports
> - *
> - * Extract a degamma/gamma LUT value provided by user (in the form of
> - * &drm_color_lut entries) and round it to the precision supported by the
> - * hardware.
> - */
> -static inline uint32_t drm_color_lut_extract(uint32_t user_input,
> - uint32_t bit_precision)
> -{
> - uint32_t val = user_input;
> - uint32_t max = 0x >> (16 - bit_precision);
> -
> - /* Round only if we're not using full precision. */
> - if (bit_precision < 16) {
> - val += 1UL << (16 - bit_precision - 1);
> - val >>= 16 - bit_precision;
> - }
> -
> - return clamp_val(val, 0, max);
> -}
> -
> -
> #endif
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] tools: rename intel_bios_reader to intel_vbt_decode
On Mon, 30 Jan 2017, Ville Syrjälä wrote:
> On Mon, Jan 30, 2017 at 10:00:54AM +0200, Jani Nikula wrote:
>> On Tue, 24 Jan 2017, Jani Nikula wrote:
>> > After all these years intel_bios_reader and intel_bios_dumper still
>> > manage to confuse me. Read or dump, which one decodes. Rename
>> > intel_bios_reader to intel_vbt_decode to be in line with the naming of
>> > all the other tools (particularly the closely related
>> > intel_opregion_decode tool) that decode previously gathered or dumped
>> > information.
>> >
>> > Signed-off-by: Jani Nikula
>>
>> Pushed patches 1-5 because they were trivial and I don't expect anyone
>> to care.
>>
>> How about this one? I don't dare push without acks on the change.
>
> You're not alone in your confusion. I routinely end up trying to use
> the wrong tool. So I for one welcome this change.
>
> Acked-by: Ville Syrjälä
Thanks, pushed with that and Petri's IRC ack.
BR,
Jani.
>
>>
>> BR,
>> Jani.
>>
>> >
>> > ---
>> >
>> > Patch 6/6 with -M option.
>> > ---
>> > man/Makefile.am | 4 ++--
>> > man/intel_bios_dumper.rst | 2 +-
>> > man/{intel_bios_reader.rst => intel_vbt_decode.rst} | 10 +-
>> > tools/.gitignore| 2 +-
>> > tools/Makefile.sources | 6 +++---
>> > tools/intel_opregion_decode.c | 2 +-
>> > tools/{intel_bios_reader.c => intel_vbt_decode.c} | 0
>> > 7 files changed, 13 insertions(+), 13 deletions(-)
>> > rename man/{intel_bios_reader.rst => intel_vbt_decode.rst} (89%)
>> > rename tools/{intel_bios_reader.c => intel_vbt_decode.c} (100%)
>> >
>> > diff --git a/man/Makefile.am b/man/Makefile.am
>> > index e40e2e931ada..0098fa45a618 100644
>> > --- a/man/Makefile.am
>> > +++ b/man/Makefile.am
>> > @@ -3,7 +3,6 @@ appman_RST = \
>> >intel_aubdump.rst \
>> >intel_audio_dump.rst\
>> >intel_bios_dumper.rst \
>> > - intel_bios_reader.rst \
>> >intel_error_decode.rst \
>> >intel_gpu_frequency.rst \
>> >intel_gpu_top.rst \
>> > @@ -16,7 +15,8 @@ appman_RST = \
>> >intel_upload_blit_large.rst \
>> >intel_upload_blit_large_gtt.rst \
>> >intel_upload_blit_large_map.rst \
>> > - intel_upload_blit_small.rst
>> > + intel_upload_blit_small.rst \
>> > + intel_vbt_decode.rst
>> >
>> > if HAVE_RST2MAN
>> > appman_DATA = $(appman_RST:rst=$(APP_MAN_SUFFIX))
>> > diff --git a/man/intel_bios_dumper.rst b/man/intel_bios_dumper.rst
>> > index 89e0001a70f7..b271b9b1afef 100644
>> > --- a/man/intel_bios_dumper.rst
>> > +++ b/man/intel_bios_dumper.rst
>> > @@ -33,4 +33,4 @@ Report bugs to https://bugs.freedesktop.org.
>> > SEE ALSO
>> >
>> >
>> > -**intel_bios_reader(1)**
>> > +**intel_vbt_decode(1)**
>> > diff --git a/man/intel_bios_reader.rst b/man/intel_vbt_decode.rst
>> > similarity index 89%
>> > rename from man/intel_bios_reader.rst
>> > rename to man/intel_vbt_decode.rst
>> > index 0e935904bcfb..a8d36d500b6d 100644
>> > --- a/man/intel_bios_reader.rst
>> > +++ b/man/intel_vbt_decode.rst
>> > @@ -1,6 +1,6 @@
>> > -=
>> > -intel_bios_reader
>> > -=
>> > +
>> > +intel_vbt_decode
>> > +
>> >
>> > -
>> > Intel Video BIOS Table parser
>> > @@ -16,12 +16,12 @@ Intel Video BIOS Table parser
>> > SYNOPSIS
>> >
>> >
>> > -**intel_bios_reader** [*OPTIONS*]
>> > +**intel_vbt_decode** [*OPTIONS*]
>> >
>> > DESCRIPTION
>> > ===
>> >
>> > -**intel_bios_reader** is a tool to parse the Intel Video BIOS Tables
>> > (VBT) and
>> > +**intel_vbt_decode** is a tool to parse the Intel Video BIOS Tables (VBT)
>> > and
>> > present the information in a human readable format.
>> >
>> > The preferred ways of getting the binary VBT to parse are:
>> > diff --git a/tools/.gitignore b/tools/.gitignore
>> > index 13825a3c9a74..7f5de26f1d07 100644
>> > --- a/tools/.gitignore
>> > +++ b/tools/.gitignore
>> > @@ -5,7 +5,7 @@ intel_aubdump
>> > intel_audio_dump
>> > intel_backlight
>> > intel_bios_dumper
>> > -intel_bios_reader
>> > +intel_vbt_decode
>> > intel_display_crc
>> > intel_display_poller
>> > intel_dump_decode
>> > diff --git a/tools/Makefile.sources b/tools/Makefile.sources
>> > index e2451ea1272c..2c41afffea39 100644
>> > --- a/tools/Makefile.sources
>> > +++ b/tools/Makefile.sources
>> > @@ -10,7 +10,6 @@ tools_prog_lists = \
>> >intel_reg \
>> >intel_backlight \
>> >intel_bios_dumper \
>> > - intel_bios_reader \
>> >intel_display_crc \
>> >intel_display_poller\
>> >intel_forcewaked\
>> > @@ -28,6 +27,7 @@ tools_prog_lists = \
>> >intel_reg_checker \
>> >intel_residency \
>
[Intel-gfx] [PATCH 0/3] Enable IPC & WM related WA's
This series include remaining patches from following series to enable IPC and Enable/update memory BW related WA's for WM. https://patchwork.freedesktop.org/series/15562/ Mahesh Kumar (3): drm/i915/bxt: Enable IPC support drm/i915: Decode system memory bandwidth drm/i915/gen9: WM memory bandwidth related workaround drivers/gpu/drm/i915/i915_drv.c | 184 ++- drivers/gpu/drm/i915/i915_drv.h | 27 + drivers/gpu/drm/i915/i915_reg.h | 38 drivers/gpu/drm/i915/intel_display.c | 35 +++ drivers/gpu/drm/i915/intel_drv.h | 1 + drivers/gpu/drm/i915/intel_pm.c | 179 ++ 6 files changed, 444 insertions(+), 20 deletions(-) -- 2.11.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/i915: Decode system memory bandwidth
This patch adds support to decode system memory bandwidth
which will be used for arbitrated display memory percentage
calculation in GEN9 based system.
Changes from v1:
- Address comments from Paulo
- implement decode function for SKL/KBL also
Changes from v2:
- Rewrite the code as per HW team inputs
- Addresses review comments
Changes from v3:
- Fix compilation warning
Changes from v4:
- Address review comments
- Round-off the frequency & bandwidth results
Signed-off-by: Mahesh Kumar
---
drivers/gpu/drm/i915/i915_drv.c | 179
drivers/gpu/drm/i915/i915_drv.h | 12 +++
drivers/gpu/drm/i915/i915_reg.h | 37 +
3 files changed, 228 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 5f3b22946971..b8d0dd2811a9 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -975,6 +975,179 @@ static void intel_sanitize_options(struct
drm_i915_private *dev_priv)
DRM_DEBUG_DRIVER("use GPU sempahores? %s\n", yesno(i915.semaphores));
}
+static enum rank
+skl_memdev_get_channel_rank(uint32_t val)
+{
+ uint8_t l_rank, s_rank;
+ uint8_t l_size, s_size;
+
+ if (!val)
+ return I915_DRAM_RANK_INVALID;
+
+ l_size = (val >> SKL_DRAM_SIZE_L_SHIFT) & SKL_DRAM_SIZE_MASK;
+ s_size = (val >> SKL_DRAM_SIZE_S_SHIFT) & SKL_DRAM_SIZE_MASK;
+ l_rank = (val >> SKL_DRAM_RANK_L_SHIFT) & SKL_DRAM_RANK_MASK;
+ s_rank = (val >> SKL_DRAM_RANK_S_SHIFT) & SKL_DRAM_RANK_MASK;
+
+ if ((l_size == 0) && (s_size == 0))
+ return I915_DRAM_RANK_INVALID;
+
+ if (l_rank == SKL_DRAM_RANK_DUAL || s_rank == SKL_DRAM_RANK_DUAL)
+ return I915_DRAM_RANK_DUAL;
+
+ if ((l_size && l_rank == SKL_DRAM_RANK_SINGLE) &&
+ (s_size && s_rank == SKL_DRAM_RANK_SINGLE))
+ return I915_DRAM_RANK_DUAL;
+ return I915_DRAM_RANK_SINGLE;
+}
+
+static int
+skl_get_memdev_info(struct drm_i915_private *dev_priv)
+{
+ struct memdev_info *memdev_info = &dev_priv->memdev_info;
+ uint32_t mem_freq_khz;
+ uint32_t val;
+ enum rank ch0_rank, ch1_rank;
+
+ val = I915_READ(SKL_MC_BIOS_DATA_0_0_0_MCHBAR_PCU);
+ mem_freq_khz = DIV_ROUND_UP((val & SKL_REQ_DATA_MASK) *
+ SKL_MEMORY_FREQ_MULTIPLIER_HZ, 1000);
+
+ val = I915_READ(SKL_MAD_DIMM_CH0_0_0_0_MCHBAR_MCMAIN);
+ ch0_rank = skl_memdev_get_channel_rank(val);
+ if (ch0_rank != I915_DRAM_RANK_INVALID)
+ memdev_info->num_channels++;
+
+ val = I915_READ(SKL_MAD_DIMM_CH1_0_0_0_MCHBAR_MCMAIN);
+ ch1_rank = skl_memdev_get_channel_rank(val);
+ if (ch1_rank != I915_DRAM_RANK_INVALID)
+ memdev_info->num_channels++;
+
+ if (memdev_info->num_channels == 0) {
+ DRM_ERROR("Number of mem channels are zero\n");
+ return -EINVAL;
+ }
+
+ memdev_info->bandwidth_kbps = memdev_info->num_channels *
+ mem_freq_khz * 8;
+
+ if (memdev_info->bandwidth_kbps == 0) {
+ DRM_ERROR("Couldn't get system memory bandwidth\n");
+ return -EINVAL;
+ }
+
+ /*
+* If any of channel is single rank channel, worst case output will be
+* same as if single rank memory, so consider single rank memory.
+*/
+ if (ch0_rank == I915_DRAM_RANK_SINGLE
+ || ch1_rank == I915_DRAM_RANK_SINGLE)
+ memdev_info->rank = I915_DRAM_RANK_SINGLE;
+ else
+ memdev_info->rank = max(ch0_rank, ch1_rank);
+
+ if (memdev_info->rank == I915_DRAM_RANK_INVALID) {
+ DRM_ERROR("couldn't get memory rank information\n");
+ return -EINVAL;
+ }
+
+ memdev_info->valid = true;
+ return 0;
+}
+
+static int
+bxt_get_memdev_info(struct drm_i915_private *dev_priv)
+{
+ struct memdev_info *memdev_info = &dev_priv->memdev_info;
+ uint32_t dram_channels;
+ uint32_t mem_freq_khz, val;
+ uint8_t num_active_channels;
+ int i;
+
+ val = I915_READ(BXT_P_CR_MC_BIOS_REQ_0_0_0);
+ mem_freq_khz = DIV_ROUND_UP((val & BXT_REQ_DATA_MASK) *
+ BXT_MEMORY_FREQ_MULTIPLIER_HZ, 1000);
+
+ dram_channels = (val >> BXT_DRAM_CHANNEL_ACTIVE_SHIFT) &
+ BXT_DRAM_CHANNEL_ACTIVE_MASK;
+ num_active_channels = hweight32(dram_channels);
+
+ /* each active bit represents 4-byte channel */
+ memdev_info->bandwidth_kbps = (mem_freq_khz * num_active_channels * 4);
+
+ if (memdev_info->bandwidth_kbps == 0) {
+ DRM_ERROR("Couldn't get system memory bandwidth\n");
+ return -EINVAL;
+ }
+
+ /*
+* Now read each DUNIT8/9/10/11 to check the rank of each dimms.
+*/
+ for (i = 0;
[Intel-gfx] [PATCH 3/3] drm/i915/gen9: WM memory bandwidth related workaround
This patch enables workarounds related to display arbitrated memory
bandwidth only if it's necessary. WA's are applicable for all GEN9
based platforms.
Changes since v1:
- Rebase on top of Paulo's patch series
Changes since v2:
- Address review comments
- Rebase/rework as per other patch changes in series
Changes since v3:
- Rebase the patch
- introduce ww_mutex to protect WM operations
- Protect system memory bandwidth calculation with ww_mutex
Signed-off-by: Mahesh Kumar
---
drivers/gpu/drm/i915/i915_drv.c | 1 +
drivers/gpu/drm/i915/i915_drv.h | 15
drivers/gpu/drm/i915/intel_display.c | 34
drivers/gpu/drm/i915/intel_pm.c | 163 +++
4 files changed, 194 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index b8d0dd2811a9..a14b2a9d2e6a 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -814,6 +814,7 @@ static int i915_driver_init_early(struct drm_i915_private
*dev_priv,
mutex_init(&dev_priv->modeset_restore_lock);
mutex_init(&dev_priv->av_mutex);
mutex_init(&dev_priv->wm.wm_mutex);
+ drm_modeset_lock_init(&dev_priv->wm.wm_ww_mutex);
mutex_init(&dev_priv->pps_mutex);
intel_uc_init_early(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index df24de2b65f2..6e5cdd6c9dfd 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1174,6 +1174,13 @@ enum intel_sbi_destination {
SBI_MPHY,
};
+/* SKL+ Watermark arbitrated display bandwidth Workarounds */
+enum watermark_memory_wa {
+ WATERMARK_WA_NONE,
+ WATERMARK_WA_X_TILED,
+ WATERMARK_WA_Y_TILED,
+};
+
#define QUIRK_PIPEA_FORCE (1<<0)
#define QUIRK_LVDS_SSC_DISABLE (1<<1)
#define QUIRK_INVERT_BRIGHTNESS (1<<2)
@@ -1744,8 +1751,15 @@ struct skl_ddb_allocation {
struct skl_ddb_entry y_plane[I915_MAX_PIPES][I915_MAX_PLANES];
};
+struct skl_mem_bw_attr {
+ enum watermark_memory_wa mem_wa;
+ uint32_t pipe_bw_kbps[I915_MAX_PIPES];
+ bool pipe_y_tiled[I915_MAX_PIPES];
+};
+
struct skl_wm_values {
unsigned dirty_pipes;
+ struct skl_mem_bw_attr mem_attr;
struct skl_ddb_allocation ddb;
};
@@ -2348,6 +2362,7 @@ struct drm_i915_private {
* cstate->wm.need_postvbl_update.
*/
struct mutex wm_mutex;
+ struct drm_modeset_lock wm_ww_mutex; /* protect DDB/WM
redistribution among pipes */
/*
* Set during HW readout of watermarks/DDB. Some platforms
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 1aa708b6f55e..de512bd8136b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14589,6 +14589,38 @@ static void intel_atomic_track_fbs(struct
drm_atomic_state *state)
to_intel_plane(plane)->frontbuffer_bit);
}
+static void
+intel_update_wm_bw_wa(struct drm_atomic_state *state)
+{
+ struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
+ struct drm_i915_private *dev_priv = to_i915(state->dev);
+ const struct drm_crtc *crtc;
+ const struct drm_crtc_state *cstate;
+ const struct memdev_info *memdev_info = &dev_priv->memdev_info;
+ struct skl_mem_bw_attr *results = &intel_state->wm_results.mem_attr;
+ struct skl_mem_bw_attr *hw_vals = &dev_priv->wm.skl_hw.mem_attr;
+ int i;
+
+ if (!IS_GEN9(dev_priv))
+ return;
+
+ if (!memdev_info->valid)
+ return;
+
+ for_each_crtc_in_state(state, crtc, cstate, i) {
+ hw_vals->pipe_bw_kbps[i] = results->pipe_bw_kbps[i];
+ hw_vals->pipe_y_tiled[i] = results->pipe_y_tiled[i];
+ }
+
+ hw_vals->mem_wa = results->mem_wa;
+
+ /*
+* As we already updated state variables no need to hold the lock,
+* other commits can proceed now with their calculation
+*/
+ drm_modeset_unlock(&dev_priv->wm.wm_ww_mutex);
+}
+
/**
* intel_atomic_commit - commit validated state object
* @dev: DRM device
@@ -14629,6 +14661,8 @@ static int intel_atomic_commit(struct drm_device *dev,
intel_shared_dpll_swap_state(state);
intel_atomic_track_fbs(state);
+ intel_update_wm_bw_wa(state);
+
if (intel_state->modeset) {
memcpy(dev_priv->min_pixclk, intel_state->min_pixclk,
sizeof(intel_state->min_pixclk));
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 16e83efa1118..ae43df5cdfd8 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2887,21 +2887,6 @@ bool ilk_disable_lp_wm(struct drm_device *dev)
#define SKL_SAGV_BLOCK_TIME30 /* µs */
-/*
- * FIXME: We still don
[Intel-gfx] [PATCH 1/3] drm/i915/bxt: Enable IPC support
This patch adds IPC support for platforms. This patch enables IPC
only for BXT/KBL platform as for SKL recommendation is to keep it disabled.
IPC (Isochronous Priority Control) is the hardware feature, which
dynamically controls the memory read priority of Display.
When IPC is enabled, plane read requests are sent at high priority until
filling above the transition watermark, then the requests are sent at
lower priority until dropping below the level 0 watermark.
The lower priority requests allow other memory clients to have better
memory access. When IPC is disabled, all plane read requests are sent at
high priority.
Changes since V1:
- Remove commandline parameter to disable ipc
- Address Paulo's comments
Changes since V2:
- Address review comments
- Set ipc_enabled flag
Changes since V3:
- move ipc_enabled flag assignment inside intel_ipc_enable function
Changes since V4:
- Re-enable IPC after suspend/resume
Signed-off-by: Mahesh Kumar
---
drivers/gpu/drm/i915/i915_drv.c | 4 +++-
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_display.c | 1 +
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 16
5 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index ca168b22ee26..5f3b22946971 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1246,7 +1246,7 @@ int i915_driver_load(struct pci_dev *pdev, const struct
pci_device_id *ent)
intel_runtime_pm_enable(dev_priv);
- dev_priv->ipc_enabled = false;
+ intel_enable_ipc(dev_priv);
/* Everything is in place, we can now relax! */
DRM_INFO("Initialized %s %d.%d.%d %s for %s on minor %d\n",
@@ -2439,6 +2439,8 @@ static int intel_runtime_resume(struct device *kdev)
enable_rpm_wakeref_asserts(dev_priv);
+ intel_enable_ipc(dev_priv);
+
if (ret)
DRM_ERROR("Runtime resume failed, disabling it (%d)\n", ret);
else
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 72f9f36ae5ce..36e0a33f876c 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6466,6 +6466,7 @@ enum {
#define DISP_FBC_WM_DIS (1<<15)
#define DISP_ARB_CTL2 _MMIO(0x45004)
#define DISP_DATA_PARTITION_5_6 (1<<6)
+#define DISP_IPC_ENABLE (1<<3)
#define DBUF_CTL _MMIO(0x45008)
#define DBUF_POWER_REQUEST(1<<31)
#define DBUF_POWER_STATE (1<<30)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 0bf8e1bfbe7e..1aa708b6f55e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -17222,6 +17222,7 @@ void intel_display_resume(struct drm_device *dev)
if (!ret)
ret = __intel_display_resume(dev, state);
+ intel_enable_ipc(dev_priv);
drm_modeset_drop_locks(&ctx);
drm_modeset_acquire_fini(&ctx);
mutex_unlock(&dev->mode_config.mutex);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 0cec0013ace0..ab7423b0a41b 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1787,6 +1787,7 @@ bool skl_ddb_allocation_overlaps(const struct
skl_ddb_entry **entries,
uint32_t ilk_pipe_pixel_rate(const struct intel_crtc_state *pipe_config);
bool ilk_disable_lp_wm(struct drm_device *dev);
int sanitize_rc6_option(struct drm_i915_private *dev_priv, int enable_rc6);
+void intel_enable_ipc(struct drm_i915_private *dev_priv);
static inline int intel_enable_rc6(void)
{
return i915.enable_rc6;
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 249623d45be0..16e83efa1118 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4667,6 +4667,22 @@ void intel_update_watermarks(struct intel_crtc *crtc)
dev_priv->display.update_wm(crtc);
}
+void intel_enable_ipc(struct drm_i915_private *dev_priv)
+{
+ u32 val;
+
+ dev_priv->ipc_enabled = false;
+ if (!(IS_BROXTON(dev_priv) || IS_KABYLAKE(dev_priv)))
+ return;
+
+ val = I915_READ(DISP_ARB_CTL2);
+
+ val |= DISP_IPC_ENABLE;
+
+ I915_WRITE(DISP_ARB_CTL2, val);
+ dev_priv->ipc_enabled = true;
+}
+
/*
* Lock protecting IPS related data structures
*/
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: warning for do_execbuffer tidy
== Series Details == Series: do_execbuffer tidy URL : https://patchwork.freedesktop.org/series/18838/ State : warning == Summary == Series 18838v1 do_execbuffer tidy https://patchwork.freedesktop.org/api/1.0/series/18838/revisions/1/mbox/ Test kms_force_connector_basic: Subgroup force-connector-state: pass -> DMESG-WARN (fi-snb-2520m) fi-bdw-5557u total:247 pass:233 dwarn:0 dfail:0 fail:0 skip:14 fi-bsw-n3050 total:247 pass:208 dwarn:0 dfail:0 fail:0 skip:39 fi-bxt-j4205 total:247 pass:225 dwarn:0 dfail:0 fail:0 skip:22 fi-bxt-t5700 total:78 pass:65 dwarn:0 dfail:0 fail:0 skip:12 fi-byt-j1900 total:247 pass:220 dwarn:0 dfail:0 fail:0 skip:27 fi-byt-n2820 total:247 pass:216 dwarn:0 dfail:0 fail:0 skip:31 fi-hsw-4770 total:247 pass:228 dwarn:0 dfail:0 fail:0 skip:19 fi-hsw-4770r total:247 pass:228 dwarn:0 dfail:0 fail:0 skip:19 fi-ivb-3520m total:247 pass:226 dwarn:0 dfail:0 fail:0 skip:21 fi-ivb-3770 total:247 pass:226 dwarn:0 dfail:0 fail:0 skip:21 fi-kbl-7500u total:247 pass:224 dwarn:0 dfail:0 fail:2 skip:21 fi-skl-6260u total:247 pass:234 dwarn:0 dfail:0 fail:0 skip:13 fi-skl-6700hqtotal:247 pass:227 dwarn:0 dfail:0 fail:0 skip:20 fi-skl-6700k total:247 pass:222 dwarn:4 dfail:0 fail:0 skip:21 fi-skl-6770hqtotal:247 pass:234 dwarn:0 dfail:0 fail:0 skip:13 fi-snb-2520m total:247 pass:215 dwarn:1 dfail:0 fail:0 skip:31 fi-snb-2600 total:247 pass:215 dwarn:0 dfail:0 fail:0 skip:32 a0695bf4e1c12de4863e775747fe850b92661dc6 drm-tip: 2017y-01m-31d-13h-38m-55s UTC integration manifest db7e420 drm/i915: Remove some unecessary line breaks c87579b drm/i915: Pass file_priv to eb_select_engine a436b4e drm/i915: eb_engine_select only needs flags c17110c drm/i915: Drop unused engine parameter from i915_gem_validate_context a07e08f drm/i915: Remove some single use locals i915_gem_do_execbuffer d6e08ae drm/i915: Nuke i915_execbuffer_params 51324f0 drm/i915: Remove batch field from i915_execbuffer_params 84b1d2e drm/i915: Tidy execbuf_submit eb4ad7b drm/i915: Drop some unused fields from i915_execbuffer_params 5029d71 drm/i915: Tidy i915_gem_do_execbuffer == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3654/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Enable IPC & WM related WA's
== Series Details == Series: Enable IPC & WM related WA's URL : https://patchwork.freedesktop.org/series/18842/ State : success == Summary == Series 18842v1 Enable IPC & WM related WA's https://patchwork.freedesktop.org/api/1.0/series/18842/revisions/1/mbox/ fi-bdw-5557u total:247 pass:233 dwarn:0 dfail:0 fail:0 skip:14 fi-bsw-n3050 total:247 pass:208 dwarn:0 dfail:0 fail:0 skip:39 fi-bxt-j4205 total:247 pass:225 dwarn:0 dfail:0 fail:0 skip:22 fi-bxt-t5700 total:78 pass:65 dwarn:0 dfail:0 fail:0 skip:12 fi-byt-j1900 total:247 pass:220 dwarn:0 dfail:0 fail:0 skip:27 fi-byt-n2820 total:247 pass:216 dwarn:0 dfail:0 fail:0 skip:31 fi-hsw-4770 total:247 pass:228 dwarn:0 dfail:0 fail:0 skip:19 fi-hsw-4770r total:247 pass:228 dwarn:0 dfail:0 fail:0 skip:19 fi-ivb-3520m total:247 pass:226 dwarn:0 dfail:0 fail:0 skip:21 fi-ivb-3770 total:247 pass:226 dwarn:0 dfail:0 fail:0 skip:21 fi-kbl-7500u total:247 pass:224 dwarn:0 dfail:0 fail:2 skip:21 fi-skl-6260u total:247 pass:234 dwarn:0 dfail:0 fail:0 skip:13 fi-skl-6700hqtotal:247 pass:227 dwarn:0 dfail:0 fail:0 skip:20 fi-skl-6700k total:247 pass:222 dwarn:4 dfail:0 fail:0 skip:21 fi-skl-6770hqtotal:247 pass:234 dwarn:0 dfail:0 fail:0 skip:13 fi-snb-2520m total:247 pass:216 dwarn:0 dfail:0 fail:0 skip:31 fi-snb-2600 total:247 pass:215 dwarn:0 dfail:0 fail:0 skip:32 a0695bf4e1c12de4863e775747fe850b92661dc6 drm-tip: 2017y-01m-31d-13h-38m-55s UTC integration manifest 7876fae drm/i915: Decode system memory bandwidth 41469f0 drm/i915/bxt: Enable IPC support == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3655/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH igt] intel-ci: Move start of gvt tests last
The purpose of the current placeholder gvt is to reload the module with gvt enabled. As a reload, it should be last after the basic reload checks. Signed-off-by: Chris Wilson --- tests/intel-ci/fast-feedback.testlist | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/intel-ci/fast-feedback.testlist b/tests/intel-ci/fast-feedback.testlist index 0ca499a4..828bd3ff 100644 --- a/tests/intel-ci/fast-feedback.testlist +++ b/tests/intel-ci/fast-feedback.testlist @@ -130,7 +130,6 @@ igt@gem_tiled_pread_basic igt@gem_wait@basic-busy-all igt@gem_wait@basic-wait-all igt@gem_workarounds@basic-read -igt@gvt_basic@invalid-placeholder-test igt@kms_addfb_basic@addfb25-bad-modifier igt@kms_addfb_basic@addfb25-framebuffer-vs-set-tiling igt@kms_addfb_basic@addfb25-modifier-no-flag @@ -250,3 +249,4 @@ igt@drv_module_reload@basic-reload igt@drv_module_reload@basic-no-display igt@drv_module_reload@basic-reload-inject igt@drv_module_reload@basic-reload-final +igt@gvt_basic@invalid-placeholder-test -- 2.11.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t v3 00/11] tests/kms_atomic_transition add fence testing
On 2017-01-31 05:18 AM, Chris Wilson wrote: On Mon, Jan 30, 2017 at 08:58:36PM -0500, Robert Foss wrote: This series adds in/out fence testing to kms_atomic_transition test and makes some minor cleanups. This series is rebased ontop of the dyn_n_planes_v3 series. This series can be found here: https://git.collabora.com/cgit/user/robertfoss/intel-gpu-tools.git/log/?h=fences_$VER Changes since v1: lib/igt_kms: - Added gtk-doc for exported symbols - Changed integer casting to avoid potential issues - Changed out_fence_ptr type to int64_t* - Fixed igt_plane_set_fence_fd comment tests/: - Rework timeout change in commit_display() - Extract plane_invalid_params_fence() out plane_invalid_params() - Extract crtc_invalid_params_fence() out crtc_invalid_params() - Prevent add igt_require_sw_sync to subtests using sw_sync Changes since v2: Rebased on upstream/master lib/igt_kms: - Reset plane->fence_fd to -1 during igt_atomic_prepare_plane_commit() - Rework out_fencs_ptr to be an int64_t named out_fence - Add igt_pipe_request_out_fence() tests/: - Switch to using igt_pipe_request_out_fence() - Close out_fence fd - Change out_fence to int64_t in run_transition_test() - Added comments noting that two testcases are not invalid - Added igt_pipe_get_last_out_fence() that wraps pipe->fence_out Looks like this this missing the uabi conversion to s32 (int). -Chris Correct, I'll submit a v4 with this fix later today if no other major issues are reported. Rob. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915/bxt: Enable IPC support
On Tue, 2017-01-31 at 20:27 +0530, Mahesh Kumar wrote:
> This patch adds IPC support for platforms. This patch enables IPC
> only for BXT/KBL platform as for SKL recommendation is to keep it disabled.
> IPC (Isochronous Priority Control) is the hardware feature, which
> dynamically controls the memory read priority of Display.
>
> When IPC is enabled, plane read requests are sent at high priority until
> filling above the transition watermark, then the requests are sent at
> lower priority until dropping below the level 0 watermark.
> The lower priority requests allow other memory clients to have better
> memory access. When IPC is disabled, all plane read requests are sent at
> high priority.
>
> Changes since V1:
> - Remove commandline parameter to disable ipc
> - Address Paulo's comments
> Changes since V2:
> - Address review comments
> - Set ipc_enabled flag
> Changes since V3:
> - move ipc_enabled flag assignment inside intel_ipc_enable function
> Changes since V4:
> - Re-enable IPC after suspend/resume
>
> Signed-off-by: Mahesh Kumar
> ---
> drivers/gpu/drm/i915/i915_drv.c | 4 +++-
> drivers/gpu/drm/i915/i915_reg.h | 1 +
> drivers/gpu/drm/i915/intel_display.c | 1 +
> drivers/gpu/drm/i915/intel_drv.h | 1 +
> drivers/gpu/drm/i915/intel_pm.c | 16
> 5 files changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index ca168b22ee26..5f3b22946971 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1246,7 +1246,7 @@ int i915_driver_load(struct pci_dev *pdev, const struct
> pci_device_id *ent)
>
> intel_runtime_pm_enable(dev_priv);
>
> - dev_priv->ipc_enabled = false;
> + intel_enable_ipc(dev_priv);
>
> /* Everything is in place, we can now relax! */
> DRM_INFO("Initialized %s %d.%d.%d %s for %s on minor %d\n",
> @@ -2439,6 +2439,8 @@ static int intel_runtime_resume(struct device *kdev)
>
> enable_rpm_wakeref_asserts(dev_priv);
>
> + intel_enable_ipc(dev_priv);
> +
> if (ret)
> DRM_ERROR("Runtime resume failed, disabling it (%d)\n", ret);
> else
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 72f9f36ae5ce..36e0a33f876c 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -6466,6 +6466,7 @@ enum {
> #define DISP_FBC_WM_DIS (1<<15)
> #define DISP_ARB_CTL2_MMIO(0x45004)
> #define DISP_DATA_PARTITION_5_6 (1<<6)
> +#define DISP_IPC_ENABLE (1<<3)
> #define DBUF_CTL _MMIO(0x45008)
> #define DBUF_POWER_REQUEST (1<<31)
> #define DBUF_POWER_STATE(1<<30)
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 0bf8e1bfbe7e..1aa708b6f55e 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -17222,6 +17222,7 @@ void intel_display_resume(struct drm_device *dev)
> if (!ret)
> ret = __intel_display_resume(dev, state);
>
> + intel_enable_ipc(dev_priv);
> drm_modeset_drop_locks(&ctx);
> drm_modeset_acquire_fini(&ctx);
> mutex_unlock(&dev->mode_config.mutex);
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 0cec0013ace0..ab7423b0a41b 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1787,6 +1787,7 @@ bool skl_ddb_allocation_overlaps(const struct
> skl_ddb_entry **entries,
> uint32_t ilk_pipe_pixel_rate(const struct intel_crtc_state *pipe_config);
> bool ilk_disable_lp_wm(struct drm_device *dev);
> int sanitize_rc6_option(struct drm_i915_private *dev_priv, int enable_rc6);
> +void intel_enable_ipc(struct drm_i915_private *dev_priv);
> static inline int intel_enable_rc6(void)
> {
> return i915.enable_rc6;
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 249623d45be0..16e83efa1118 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -4667,6 +4667,22 @@ void intel_update_watermarks(struct intel_crtc *crtc)
> dev_priv->display.update_wm(crtc);
> }
>
> +void intel_enable_ipc(struct drm_i915_private *dev_priv)
> +{
> + u32 val;
> +
> + dev_priv->ipc_enabled = false;
> + if (!(IS_BROXTON(dev_priv) || IS_KABYLAKE(dev_priv)))
> + return;
Do we want this enabled in Geminilake?
Ander
> +
> + val = I915_READ(DISP_ARB_CTL2);
> +
> + val |= DISP_IPC_ENABLE;
> +
> + I915_WRITE(DISP_ARB_CTL2, val);
> + dev_priv->ipc_enabled = true;
> +}
> +
> /*
> * Lock protecting IPS related data structures
> */
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Sanity check the computed size and base of stolen memory
On Tue, Jan 31, 2017 at 12:13:47PM +0200, Joonas Lahtinen wrote: > On ma, 2017-01-30 at 13:47 +, Chris Wilson wrote: > > Just do a quick check that the stolen memory address range doesn't > > overflow our chosen integer type. > > > > v2: Add add_overflows() to utils with the promise that gcc7 can do this > > better than C and then maybe it will have a proper definition in core. > > > > Signed-off-by: Chris Wilson > > Cc: Joonas Lahtinen > > Reviewed-by: Joonas Lahtinen Applied, thanks, -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/3] drm/i915: Make intel_detect_preproduction_hw easier to extend
On Mon, Jan 30, 2017 at 05:54:14PM -, Patchwork wrote: > == Series Details == > > Series: series starting with [v2,1/3] drm/i915: Make > intel_detect_preproduction_hw easier to extend > URL : https://patchwork.freedesktop.org/series/18758/ > State : success > > == Summary == > > Series 18758v1 Series without cover letter > https://patchwork.freedesktop.org/api/1.0/series/18758/revisions/1/mbox/ > > > fi-bdw-5557u total:246 pass:232 dwarn:0 dfail:0 fail:0 skip:14 > fi-bsw-n3050 total:246 pass:207 dwarn:0 dfail:0 fail:0 skip:39 > fi-bxt-j4205 total:246 pass:224 dwarn:0 dfail:0 fail:0 skip:22 > fi-bxt-t5700 total:78 pass:65 dwarn:0 dfail:0 fail:0 skip:12 > fi-byt-j1900 total:246 pass:219 dwarn:0 dfail:0 fail:0 skip:27 > fi-byt-n2820 total:246 pass:215 dwarn:0 dfail:0 fail:0 skip:31 > fi-hsw-4770 total:246 pass:227 dwarn:0 dfail:0 fail:0 skip:19 > fi-hsw-4770r total:246 pass:227 dwarn:0 dfail:0 fail:0 skip:19 > fi-ivb-3520m total:246 pass:225 dwarn:0 dfail:0 fail:0 skip:21 > fi-ivb-3770 total:246 pass:225 dwarn:0 dfail:0 fail:0 skip:21 > fi-skl-6260u total:246 pass:233 dwarn:0 dfail:0 fail:0 skip:13 > fi-skl-6700hqtotal:246 pass:226 dwarn:0 dfail:0 fail:0 skip:20 > fi-skl-6700k total:246 pass:221 dwarn:4 dfail:0 fail:0 skip:21 > fi-skl-6770hqtotal:246 pass:233 dwarn:0 dfail:0 fail:0 skip:13 > fi-snb-2520m total:246 pass:215 dwarn:0 dfail:0 fail:0 skip:31 > fi-snb-2600 total:246 pass:214 dwarn:0 dfail:0 fail:0 skip:32 Applied in spite of some late background noise about bxt-a0 support, a bit late now. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t v3 06/11] lib/igt_kms: Add support for the IN_FENCE_FD property
On Mon, Jan 30, 2017 at 08:58:42PM -0500, Robert Foss wrote:
Add support dor the IN_FENCE_FD property to enable setting in fences for atomic
commits.
Signed-off-by: Robert Foss
---
lib/igt_kms.c | 20
lib/igt_kms.h | 5 +
2 files changed, 25 insertions(+)
diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index f0e38b75..b79d2867 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -168,6 +168,7 @@ const char *igt_plane_prop_names[IGT_NUM_PLANE_PROPS] = {
"CRTC_H",
"FB_ID",
"CRTC_ID",
+ "IN_FENCE_FD",
"type",
"rotation"
};
@@ -1667,6 +1668,7 @@ void igt_display_init(igt_display_t *display, int drm_fd)
plane->type = type;
plane->pipe = pipe;
plane->drm_plane = drm_plane;
+ plane->fence_fd = -1;
if (is_atomic == 0) {
display->is_atomic = 1;
@@ -2002,6 +2004,11 @@ igt_atomic_prepare_plane_commit(igt_plane_t *plane,
igt_pipe_t *pipe,
plane->index,
fb_id);
+ if (plane->fence_fd >= 0) {
+ uint64_t fence_fd = (int64_t) plane->fence_fd;
+ igt_atomic_populate_plane_req(req, plane,
IGT_PLANE_IN_FENCE_FD, fence_fd);
+ }
+
if (plane->fb_changed) {
igt_atomic_populate_plane_req(req, plane, IGT_PLANE_CRTC_ID,
fb_id ? crtc_id : 0);
igt_atomic_populate_plane_req(req, plane, IGT_PLANE_FB_ID,
fb_id);
@@ -2823,6 +2830,19 @@ void igt_plane_set_fb(igt_plane_t *plane, struct igt_fb
*fb)
plane->size_changed = true;
}
+/**
+ * igt_plane_set_fence_fd:
+ * @plane: plane
+ * @fence_fd: fence fd, disable fence_fd by setting it to -1
+ *
+ * This function sets a fence fd to enable a commit to wait for some event to
+ * occur before completing.
+ */
+void igt_plane_set_fence_fd(igt_plane_t *plane, uint32_t fence_fd)
nitpick, but should that be "int fence_fd" ?
Also have some comments later in the series around the fd ownership.
If nothing else, the comment here could say what's expected.
-Brian
+{
+ plane->fence_fd = fence_fd;
+}
+
void igt_plane_set_position(igt_plane_t *plane, int x, int y)
{
igt_pipe_t *pipe = plane->pipe;
diff --git a/lib/igt_kms.h b/lib/igt_kms.h
index 94ff27bb..85688853 100644
--- a/lib/igt_kms.h
+++ b/lib/igt_kms.h
@@ -248,6 +248,7 @@ enum igt_atomic_plane_properties {
IGT_PLANE_FB_ID,
IGT_PLANE_CRTC_ID,
+ IGT_PLANE_IN_FENCE_FD,
IGT_PLANE_TYPE,
IGT_PLANE_ROTATION,
IGT_NUM_PLANE_PROPS
@@ -306,6 +307,9 @@ typedef struct {
uint32_t src_h;
igt_rotation_t rotation;
+
+ /* in fence fd */
+ int32_t fence_fd;
uint32_t atomic_props_plane[IGT_NUM_PLANE_PROPS];
} igt_plane_t;
@@ -397,6 +401,7 @@ void igt_pipe_set_ctm_matrix(igt_pipe_t *pipe, void *ptr,
size_t length);
void igt_pipe_set_gamma_lut(igt_pipe_t *pipe, void *ptr, size_t length);
void igt_plane_set_fb(igt_plane_t *plane, struct igt_fb *fb);
+void igt_plane_set_fence_fd(igt_plane_t *plane, uint32_t fence_fd);
void igt_plane_set_position(igt_plane_t *plane, int x, int y);
void igt_plane_set_size(igt_plane_t *plane, int w, int h);
void igt_plane_set_rotation(igt_plane_t *plane, igt_rotation_t rotation);
--
2.11.0.453.g787f75f05
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t v3 07/11] lib/igt_kms: Add support for the OUT_FENCE_PTR property
On Mon, Jan 30, 2017 at 08:58:43PM -0500, Robert Foss wrote:
From: Gustavo Padovan
Add support for the OUT_FENCE_PTR property to enable setting out fences for
atomic commits.
Signed-off-by: Gustavo Padovan
Signed-off-by: Robert Foss
---
lib/igt_kms.c | 26 +-
lib/igt_kms.h | 6 +-
2 files changed, 30 insertions(+), 2 deletions(-)
diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index b79d2867..f14496dd 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -179,7 +179,8 @@ const char *igt_crtc_prop_names[IGT_NUM_CRTC_PROPS] = {
"DEGAMMA_LUT",
"GAMMA_LUT",
"MODE_ID",
- "ACTIVE"
+ "ACTIVE",
+ "OUT_FENCE_PTR"
};
const char *igt_connector_prop_names[IGT_NUM_CONNECTOR_PROPS] = {
@@ -2393,6 +2394,15 @@ static void igt_atomic_prepare_crtc_commit(igt_pipe_t
*pipe_obj, drmModeAtomicRe
igt_atomic_populate_crtc_req(req, pipe_obj, IGT_CRTC_ACTIVE,
!!output);
}
+ pipe_obj->out_fence = -1;
+ if (pipe_obj->out_fence_requested)
+ {
+ pipe_obj->out_fence_requested = false;
+ igt_atomic_populate_crtc_req(req, pipe_obj,
IGT_CRTC_OUT_FENCE_PTR,
+ (uint64_t)(uintptr_t) &pipe_obj->out_fence);
+ igt_assert_f(pipe_obj->out_fence != -1, "Unable to get fence,
received -1 fd\n");
Doesn't this assertion always fail? You just set it to -1
+ }
+
/*
* TODO: Add all crtc level properties here
*/
@@ -2984,6 +2994,20 @@ igt_pipe_set_gamma_lut(igt_pipe_t *pipe, void *ptr,
size_t length)
}
/**
+ * igt_pipe_set_out_fence_ptr:
+ * @pipe: pipe pointer to which background color to be set
+ * @fence_ptr: out fence pointer
+ *
+ * Sets the out fence pointer that will be passed to the kernel in
+ * the atomic ioctl. When the kernel returns the out fence pointer
+ * will contain the fd number of the out fence created by KMS.
+ */
+void igt_pipe_set_out_fence_ptr(igt_pipe_t *pipe, int64_t *fence_ptr)
+{
+ pipe->out_fence_ptr = fence_ptr;
+}
Is this ever used? You seem to use &pipe_obj->out_fence
unconditionally above (and igt_pipe has no member named
out_fence_ptr).
I guess is left over from the previous API and needs to be removed?
+
+/**
* igt_crtc_set_background:
* @pipe: pipe pointer to which background color to be set
* @background: background color value in BGR 16bpc
diff --git a/lib/igt_kms.h b/lib/igt_kms.h
index 85688853..9672dadc 100644
--- a/lib/igt_kms.h
+++ b/lib/igt_kms.h
@@ -94,6 +94,7 @@ enum igt_atomic_crtc_properties {
IGT_CRTC_GAMMA_LUT,
IGT_CRTC_MODE_ID,
IGT_CRTC_ACTIVE,
+ IGT_CRTC_OUT_FENCE_PTR,
IGT_NUM_CRTC_PROPS
};
@@ -341,6 +342,9 @@ struct igt_pipe {
uint64_t mode_blob;
bool mode_changed;
+
+ int64_t out_fence;
+ bool out_fence_requested;
};
typedef struct {
@@ -395,7 +399,7 @@ static inline bool igt_plane_supports_rotation(igt_plane_t
*plane)
{
return plane->rotation_property != 0;
}
-
+void igt_pipe_request_out_fence(igt_pipe_t *pipe);
Not implemented? I think this patch got confused somewhere :-(
-Brian
void igt_pipe_set_degamma_lut(igt_pipe_t *pipe, void *ptr, size_t length);
void igt_pipe_set_ctm_matrix(igt_pipe_t *pipe, void *ptr, size_t length);
void igt_pipe_set_gamma_lut(igt_pipe_t *pipe, void *ptr, size_t length);
--
2.11.0.453.g787f75f05
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t v3 08/11] tests/kms_atomic: stress possible fence settings
This one lgtm, just need to swap all the uint64_t out_fence_ptrs for
int32_t.
-Brian
On Mon, Jan 30, 2017 at 08:58:44PM -0500, Robert Foss wrote:
From: Gustavo Padovan
Signed-off-by: Gustavo Padovan
Signed-off-by: Robert Foss
---
tests/kms_atomic.c | 187 ++---
1 file changed, 177 insertions(+), 10 deletions(-)
diff --git a/tests/kms_atomic.c b/tests/kms_atomic.c
index 8df51ccd..09605e38 100644
--- a/tests/kms_atomic.c
+++ b/tests/kms_atomic.c
@@ -44,6 +44,7 @@
#include "drmtest.h"
#include "igt.h"
#include "igt_aux.h"
+#include "sw_sync.h"
#ifndef DRM_CLIENT_CAP_ATOMIC
#define DRM_CLIENT_CAP_ATOMIC 3
@@ -126,6 +127,7 @@ struct kms_atomic_plane_state {
uint32_t fb_id; /* 0 to disable */
uint32_t src_x, src_y, src_w, src_h; /* 16.16 fixed-point */
uint32_t crtc_x, crtc_y, crtc_w, crtc_h; /* normal integers */
+ int32_t fence_fd;
};
struct kms_atomic_crtc_state {
@@ -133,6 +135,7 @@ struct kms_atomic_crtc_state {
uint32_t obj;
int idx;
bool active;
+ uint64_t out_fence_ptr;
struct kms_atomic_blob mode;
};
@@ -190,11 +193,13 @@ static uint32_t blob_duplicate(int fd, uint32_t id_orig)
crtc_populate_req(crtc, req); \
plane_populate_req(plane, req); \
do_atomic_commit((crtc)->state->desc->fd, req, flags); \
- crtc_check_current_state(crtc, plane, relax); \
- plane_check_current_state(plane, relax); \
+ if (!(flags & DRM_MODE_ATOMIC_TEST_ONLY)) { \
+ crtc_check_current_state(crtc, plane, relax); \
+ plane_check_current_state(plane, relax); \
+ } \
}
-#define crtc_commit_atomic_err(crtc, plane, crtc_old, plane_old, req, relax,
e) { \
+#define crtc_commit_atomic_err(crtc, plane, crtc_old, plane_old, req, flags,
relax, e) { \
drmModeAtomicSetCursor(req, 0); \
crtc_populate_req(crtc, req); \
plane_populate_req(plane, req); \
@@ -299,6 +304,9 @@ find_connector(struct kms_atomic_state *state,
static void plane_populate_req(struct kms_atomic_plane_state *plane,
drmModeAtomicReq *req)
{
+ if (plane->fence_fd)
+ plane_set_prop(req, plane, IGT_PLANE_IN_FENCE_FD,
plane->fence_fd);
+
plane_set_prop(req, plane, IGT_PLANE_CRTC_ID, plane->crtc_id);
plane_set_prop(req, plane, IGT_PLANE_FB_ID, plane->fb_id);
plane_set_prop(req, plane, IGT_PLANE_SRC_X, plane->src_x);
@@ -433,6 +441,10 @@ find_plane(struct kms_atomic_state *state, enum plane_type
type,
static void crtc_populate_req(struct kms_atomic_crtc_state *crtc,
drmModeAtomicReq *req)
{
+ if (crtc->out_fence_ptr)
+ crtc_set_prop(req, crtc, IGT_CRTC_OUT_FENCE_PTR,
+ crtc->out_fence_ptr);
+
crtc_set_prop(req, crtc, IGT_CRTC_MODE_ID, crtc->mode.id);
crtc_set_prop(req, crtc, IGT_CRTC_ACTIVE, crtc->active);
}
@@ -1061,6 +1073,37 @@ static void plane_invalid_params(struct
kms_atomic_crtc_state *crtc,
drmModeAtomicFree(req);
}
+static void plane_invalid_params_fence(struct kms_atomic_crtc_state *crtc,
+ struct kms_atomic_plane_state *plane_old,
+ struct kms_atomic_connector_state *conn)
+{
+ struct kms_atomic_plane_state plane = *plane_old;
+ drmModeAtomicReq *req = drmModeAtomicAlloc();
+ int timeline, fence_fd;
+
+ igt_require_sw_sync();
+
+ /* invalid fence fd */
+ plane.fence_fd = plane.state->desc->fd;
+ plane.crtc_id = plane_old->crtc_id;
+ plane_commit_atomic_err(&plane, plane_old, req,
+ ATOMIC_RELAX_NONE, EINVAL);
+
+ /* Valid fence_fd but invalid CRTC */
+ timeline = sw_sync_timeline_create();
+ fence_fd = sw_sync_timeline_create_fence(timeline, 1);
+ plane.fence_fd = fence_fd;
+ plane.crtc_id = ~0U;
+ plane_commit_atomic_err(&plane, plane_old, req,
+ ATOMIC_RELAX_NONE, EINVAL);
+
+ plane.fence_fd = -1;
+ close(fence_fd);
+ close(timeline);
+
+ drmModeAtomicFree(req);
+}
+
static void crtc_invalid_params(struct kms_atomic_crtc_state *crtc_old,
struct kms_atomic_plane_state *plane,
struct kms_atomic_connector_state *conn)
@@ -1072,30 +1115,32 @@ static void crtc_invalid_params(struct
kms_atomic_crtc_state *crtc_old,
/* Pass a series of invalid object IDs for the mode ID. */
crtc.mode.id = plane->obj;
- crtc_commit_atomic_err(&crtc, plane, crtc_old, plane, req,
+ crtc_commit_atomic_err(&crtc, plane, crtc_old, plane, req, 0,
ATOMIC_RELAX_NONE, EINVAL);
crtc.mode.id = crtc.obj;
- crtc_commit_atomic_err(&crtc, plane, crtc_old, plane, req,
+ crtc_commit_atomic_err(&crtc, plane, crtc_old, plane, req, 0,
Re: [Intel-gfx] [PATCH i-g-t v3 10/11] tests/kms_atomic_transition: add out_fences tests
On Mon, Jan 30, 2017 at 08:58:46PM -0500, Robert Foss wrote:
Signed-off-by: Gustavo Padovan
Signed-off-by: Robert Foss
---
lib/igt_kms.c | 35 ++
tests/kms_atomic_transition.c | 148 ++
2 files changed, 169 insertions(+), 14 deletions(-)
diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index f14496dd..523f3f57 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -53,6 +53,7 @@
#include "intel_chipset.h"
#include "igt_debugfs.h"
#include "igt_sysfs.h"
+#include "sw_sync.h"
/**
* SECTION:igt_kms
@@ -2479,6 +2480,21 @@ static int igt_atomic_commit(igt_display_t *display,
uint32_t flags, void *user_
}
ret = drmModeAtomicCommit(display->drm_fd, req, flags, user_data);
+ if (!ret) {
+
+ for_each_pipe(display, pipe) {
+ igt_pipe_t *pipe_obj = &display->pipes[pipe];
+
+ if (pipe_obj->out_fence != -1)
+ continue;
Should be "if (pipe_obj->fence == -1)" ? The stuff below seems to be
assuming the fence is valid.
+
+ igt_assert(pipe_obj->out_fence >= 0);
+ ret = sync_fence_wait(pipe_obj->out_fence, 1000);
+ igt_assert(ret == 0);
+ close(pipe_obj->out_fence);
+ }
+ }
+
drmModeAtomicFree(req);
return ret;
@@ -2972,6 +2988,11 @@ void igt_plane_set_rotation(igt_plane_t *plane,
igt_rotation_t rotation)
plane->rotation_changed = true;
}
+void igt_pipe_request_out_fence(igt_pipe_t *pipe)
Oh here it is!
+{
+ pipe->out_fence_requested = true;
+}
+
void
igt_pipe_set_degamma_lut(igt_pipe_t *pipe, void *ptr, size_t length)
{
@@ -2994,20 +3015,6 @@ igt_pipe_set_gamma_lut(igt_pipe_t *pipe, void *ptr,
size_t length)
}
/**
- * igt_pipe_set_out_fence_ptr:
- * @pipe: pipe pointer to which background color to be set
- * @fence_ptr: out fence pointer
- *
- * Sets the out fence pointer that will be passed to the kernel in
- * the atomic ioctl. When the kernel returns the out fence pointer
- * will contain the fd number of the out fence created by KMS.
- */
-void igt_pipe_set_out_fence_ptr(igt_pipe_t *pipe, int64_t *fence_ptr)
... and there this one goes. This deletion and the function above
need to be squashed into the earlier commit I suppose.
-{
- pipe->out_fence_ptr = fence_ptr;
-}
-
-/**
* igt_crtc_set_background:
* @pipe: pipe pointer to which background color to be set
* @background: background color value in BGR 16bpc
diff --git a/tests/kms_atomic_transition.c b/tests/kms_atomic_transition.c
index 72429759..eebb5d66 100644
--- a/tests/kms_atomic_transition.c
+++ b/tests/kms_atomic_transition.c
@@ -253,6 +253,93 @@ retry:
sprite_width, sprite_height, alpha);
}
+int *timeline;
+pthread_t *thread;
+int *seqno;
+
+static void prepare_fencing(igt_display_t *display, enum pipe pipe)
+{
+ igt_plane_t *plane;
+ int n_planes;
+
+ igt_require_sw_sync();
+
+ n_planes = display->pipes[pipe].n_planes;
+timeline = calloc(sizeof(*timeline), n_planes);
+igt_assert_f(timeline != NULL, "Failed to allocate memory for
timelines\n");
+thread = calloc(sizeof(*thread), n_planes);
+igt_assert_f(thread != NULL, "Failed to allocate memory for thread\n");
+seqno = calloc(sizeof(*seqno), n_planes);
+igt_assert_f(seqno != NULL, "Failed to allocate memory for seqno\n");
The 6 lines above are space-indented
+
+ for_each_plane_on_pipe(display, pipe, plane)
+ timeline[plane->index] = sw_sync_timeline_create();
+}
+
+static void unprepare_fencing(igt_display_t *display, enum pipe pipe)
+{
+ igt_plane_t *plane;
+
+ for_each_plane_on_pipe(display, pipe, plane)
+ close(timeline[plane->index]);
+
+ free(timeline);
+ free(thread);
+ free(seqno);
+}
+
+static void *fence_inc_thread(void *arg)
+{
+ int t = *((int *) arg);
+
+ pthread_detach(pthread_self());
+
+ usleep(5000);
+ sw_sync_timeline_inc(t, 1);
+ return NULL;
+}
+
+static void configure_fencing(igt_display_t *display, enum pipe pipe)
+{
+ igt_plane_t *plane;
+ int i, fd, ret;
+
+ for_each_plane_on_pipe(display, pipe, plane) {
+
+ if (!plane->fb)
+ continue;
+
+ i = plane->index;
+
+ seqno[i]++;
+ fd = sw_sync_timeline_create_fence(timeline[i], seqno[i]);
+ igt_plane_set_fence_fd(plane, fd);
+ ret = pthread_create(&thread[i], NULL, fence_inc_thread,
&timeline[i]);
+ igt_assert_eq(ret, 0);
+ }
+}
+
+static void clear_fencing(igt_display_t *display, enum pipe pipe)
+{
+ igt_plane_t *plane;
+
+ for_each_plane_on_pipe(display, pipe, plane)
+ igt_plane_set_fence_fd(plane, -1);
Someone should close the old fence_fd if it's not -1.
I
Re: [Intel-gfx] [PATCH i-g-t v3 11/11] tests/kms_atomic_transition: add in_fences tests
On Mon, Jan 30, 2017 at 08:58:47PM -0500, Robert Foss wrote:
From: Gustavo Padovan
Signed-off-by: Gustavo Padovan
Signed-off-by: Robert Foss
---
lib/igt_kms.c | 3 +++
tests/kms_atomic_transition.c | 48 ++-
2 files changed, 32 insertions(+), 19 deletions(-)
diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index 523f3f57..bc815363 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -2009,6 +2009,9 @@ igt_atomic_prepare_plane_commit(igt_plane_t *plane,
igt_pipe_t *pipe,
if (plane->fence_fd >= 0) {
uint64_t fence_fd = (int64_t) plane->fence_fd;
igt_atomic_populate_plane_req(req, plane,
IGT_PLANE_IN_FENCE_FD, fence_fd);
+
+ /* reset fence_fd to prevent it from being set for the next
commit */
+ plane->fence_fd = -1;
Who closes it?
}
if (plane->fb_changed) {
diff --git a/tests/kms_atomic_transition.c b/tests/kms_atomic_transition.c
index eebb5d66..0876bbb3 100644
--- a/tests/kms_atomic_transition.c
+++ b/tests/kms_atomic_transition.c
@@ -23,7 +23,9 @@
#include "igt.h"
#include "drmtest.h"
+#include "sw_sync.h"
#include
+#include
#include
#include
#include
@@ -362,6 +364,9 @@ run_transition_test(igt_display_t *display, enum pipe pipe,
igt_output_t *output
unsigned flags = DRM_MODE_PAGE_FLIP_EVENT;
int ret;
+ if (fencing)
+ prepare_fencing(display, pipe);
+
if (nonblocking)
flags |= DRM_MODE_ATOMIC_NONBLOCK;
@@ -404,18 +409,19 @@ run_transition_test(igt_display_t *display, enum pipe
pipe, igt_output_t *output
wm_setup_plane(display, pipe, iter_max - 1, parms);
if (fencing)
- igt_pipe_set_out_fence_ptr(&display->pipes[pipe],
- (int64_t *) &out_fence);
+ igt_pipe_request_out_fence(&display->pipes[pipe]);
+
Hopefully this can get rebased away? I'm getting confused about
what's actually being added/changed in this commit.
ret = igt_display_try_commit_atomic(display,
DRM_MODE_ATOMIC_TEST_ONLY | DRM_MODE_ATOMIC_ALLOW_MODESET, NULL);
- if (ret != -EINVAL || n_planes < 3)
+ if (ret != -EINVAL || display->pipes[pipe].n_planes < 3)
break;
ret = 0;
for_each_plane_on_pipe(display, pipe, plane) {
i = plane->index;
- if (plane->is_primary || plane->is_cursor)
+ if (plane->type == DRM_PLANE_TYPE_PRIMARY ||
+ plane->type == DRM_PLANE_TYPE_CURSOR)
continue;
This seems spurious?
...
A bit more add/remove churn below which can hopefully go away with a
rebase.
Cheers,
-Brian
if (parms[i].width <= 512)
@@ -436,10 +442,8 @@ run_transition_test(igt_display_t *display, enum pipe
pipe, igt_output_t *output
wm_setup_plane(display, pipe, i, parms);
- if (fencing)
- igt_pipe_set_out_fence_ptr(&display->pipes[pipe],
&out_fence);
+ atomic_commit(display, pipe, flags, (void *)(unsigned long)i,
fencing);
- igt_display_commit_atomic(display, flags, (void *)(unsigned
long)i);
drmHandleEvent(display->drm_fd, &drm_events);
if (type == TRANSITION_MODESET_DISABLE) {
@@ -463,19 +467,14 @@ run_transition_test(igt_display_t *display, enum pipe
pipe, igt_output_t *output
if (type == TRANSITION_MODESET)
igt_output_override_mode(output,
&override_mode);
- if (fencing)
-
igt_pipe_set_out_fence_ptr(&display->pipes[pipe], &out_fence);
-
- igt_display_commit_atomic(display, flags, (void
*)(unsigned long)j);
+ atomic_commit(display, pipe, flags, (void
*)(unsigned long)i, fencing);
drmHandleEvent(display->drm_fd, &drm_events);
wm_setup_plane(display, pipe, i, parms);
if (type == TRANSITION_MODESET)
igt_output_override_mode(output, NULL);
- if (fencing)
-
igt_pipe_set_out_fence_ptr(&display->pipes[pipe], &out_fence);
-
+ atomic_commit(display, pipe, flags, (void
*)(unsigned long)i, fencing);
igt_display_commit_atomic(display, flags, (void
*)(unsigned long)i);
drmHandleEvent(display->drm_fd, &drm_events);
}
@@ -483,6 +482,8 @@ run_transition_test(igt_display_t *display, enum pipe pipe,
igt_output_t *output
}
cleanup:
+ unprepare_fenci
Re: [Intel-gfx] [PATCH i-g-t v3 05/11] lib/igt_kms: Added igt_pipe_get_last_out_fence()
On Mon, Jan 30, 2017 at 08:58:41PM -0500, Robert Foss wrote:
Added the igt_pipe_get_last_out_fence() helper function
that wraps accesses to pipe->fence_out.
Signed-off-by: Robert Foss
---
lib/igt_kms.c | 8
lib/igt_kms.h | 1 +
2 files changed, 9 insertions(+)
diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index 142658a6..f0e38b75 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -1934,6 +1934,14 @@ static igt_output_t *igt_pipe_get_output(igt_pipe_t
*pipe)
return NULL;
}
+int igt_pipe_get_last_out_fence(igt_pipe_t *pipe)
+{
+ int fd = (int) pipe->out_fence;
+ pipe->out_fence = -1;
+
+ return fd;
If this wasn't the compile error you already found, then "out_fence"
doesn't seem to have been added to igt_pipe_t yet.
-Brian
+}
+
bool igt_pipe_get_property(igt_pipe_t *pipe, const char *name,
uint32_t *prop_id, uint64_t *value,
drmModePropertyPtr *prop)
diff --git a/lib/igt_kms.h b/lib/igt_kms.h
index 00e0dc68..94ff27bb 100644
--- a/lib/igt_kms.h
+++ b/lib/igt_kms.h
@@ -382,6 +382,7 @@ igt_plane_t *igt_output_get_plane_type(igt_output_t
*output, int plane_type);
igt_output_t *igt_output_from_connector(igt_display_t *display,
drmModeConnector *connector);
igt_plane_t *igt_pipe_get_plane_type(igt_pipe_t *pipe, int plane_type);
+int igt_pipe_get_last_out_fence(igt_pipe_t *pipe);
bool igt_pipe_get_property(igt_pipe_t *pipe, const char *name,
uint32_t *prop_id, uint64_t *value,
drmModePropertyPtr *prop);
--
2.11.0.453.g787f75f05
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915/gen9: WM memory bandwidth related workaround
Hi Mahesh,
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on next-20170130]
[cannot apply to v4.10-rc6]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Mahesh-Kumar/Enable-IPC-WM-related-WA-s/20170131-230708
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-rhel (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed by >>):
drivers/gpu/drm/i915/intel_pm.c: In function
'skl_compute_memory_bandwidth_wm_wa':
>> drivers/gpu/drm/i915/intel_pm.c:4118:56: warning: argument to 'sizeof' in
>> 'memcpy' call is the same expression as the destination; did you mean to
>> dereference it? [-Wsizeof-pointer-memaccess]
memcpy(mem_attr, &dev_priv->wm.skl_hw.mem_attr, sizeof(mem_attr));
^
vim +4118 drivers/gpu/drm/i915/intel_pm.c
4102 mem_attr->mem_wa = WATERMARK_WA_NONE;
4103 return 0;
4104 }
4105
4106 if (!memdev_info->valid)
4107 goto exit;
4108
4109 /*
4110 * We hold wm_mutex lock, so any other flip can't proceed
beyond WM
4111 * calculation step until this flip writes modified WM values.
4112 * So it's safe to read plane_state of other pipes without
taking CRTC lock
4113 */
4114 ret = drm_modeset_lock(&dev_priv->wm.wm_ww_mutex,
state->acquire_ctx);
4115 if (ret)
4116 return ret;
4117
> 4118 memcpy(mem_attr, &dev_priv->wm.skl_hw.mem_attr,
> sizeof(mem_attr));
4119
4120 for_each_crtc_in_state(state, crtc, cstate, i) {
4121 struct drm_plane *plane;
4122 const struct drm_plane_state *pstate;
4123 int active_planes = 0;
4124 uint32_t max_plane_bw_kbps = 0;
4125
4126 mem_attr->pipe_y_tiled[i] = false;
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-misc-fixes
Hi Dave, 2 patches to fix the oops Dave Hanse reported, plus a double kfree fix Maarten discovered while backporting the fix for Linus. For Linus' vma tracking oops the plan is to send you a dedicated pull with the 2 patches we need, but since it's tricky we're letting CI beat on it a bit more. Cheers, Daniel The following changes since commit 566cf877a1fcb6d6dc0126b076aad062054c2637: Linux 4.10-rc6 (2017-01-29 14:25:17 -0800) are available in the git repository at: git://anongit.freedesktop.org/git/drm-misc tags/drm-misc-fixes-2017-01-31 for you to fetch changes up to 92c715fca907686f5298220ece53423e38ba3aed: drm/atomic: Fix double free in drm_atomic_state_default_clear (2017-01-31 13:41:46 +0100) Daniel Vetter (2): drm: prevent double-(un)registration for connectors drm: Don't race connector registration Maarten Lankhorst (1): drm/atomic: Fix double free in drm_atomic_state_default_clear drivers/gpu/drm/drm_atomic.c| 13 - drivers/gpu/drm/drm_connector.c | 23 ++- drivers/gpu/drm/drm_drv.c | 4 include/drm/drmP.h | 1 + include/drm/drm_connector.h | 16 +++- 5 files changed, 46 insertions(+), 11 deletions(-) -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm-misc: Document small drivers expectations
For the experiement we have right now Eric (with vc4) and Sean Paul (with rockchip and zte) volunteering, and Gerd (entire pile of qemu drivers) and Boris (atmel) are also considering to participate. I think that's enough to get started and figure things out as we go. I tried to summarize the main points from the rfc discussions into a short chapter. v2: Spelling fixes (Anholt). Cc: Boris Brezillon Cc: Eric Anholt Cc: Sean Paul Cc: Gerd Hoffmann Cc: Mark Yao Cc: Shawn Guo Acked-by: Sean Paul Acked-by: Gerd Hoffmann Acked-by: Boris Brezillon Acked-by: Eric Anholt Signed-off-by: Daniel Vetter --- drm-misc.rst | 30 ++ 1 file changed, 30 insertions(+) diff --git a/drm-misc.rst b/drm-misc.rst index 3d711ec60047..7f7233cf3c61 100644 --- a/drm-misc.rst +++ b/drm-misc.rst @@ -93,6 +93,36 @@ Right now the only hard merge criteria are: * See also the extensive `committer guidelines for drm-intel `_. +Small Drivers += + +Small drivers, where a full tree is overkill, can be maintained in drm-misc. For +now it's just an experiment with a few drivers to figure out a working process. +Slightly different rules apply: + +* Small is measured in patches merged per kernel release. The occasional big + patch series is still acceptable if it's not a common thing (e.g. new hw + enabling once a year), and if the series is really big (more than 20 patches) + it should probably be managed through a topic branch in drm-misc and with a + separate pull request to drm maintainer. dim_ supports this with the + create-branch command. + +* Group maintainership is assumed, i.e. all regular contributors (not just + the primary maintainer) will get commit rights. + +* Since even a broken driver is more useful than no driver minimal review + standards are a lot lower. The default should be some notes about what could + be improved in follow-up work and accepting patches by default. Maintainer + group for drivers can agree on stricter rules, especially when they have a + bigger user base that shouldn't suffer from regressions. + +* Minimal peer-review is also expected for drivers with just one contributor, + but obviously then only focuses on best practices for the interaction with drm + core and helpers. Plus a bit looking for common patterns in dealing with the + hardware, since display IP all has to handle the same issues in the end. In + most cases this will just along the lines of "Looks good, Ack". drm-misc + maintainers will help out with getting that review market going. + Tooling === -- 2.11.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915/gen9: WM memory bandwidth related workaround
Hi Mahesh,
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on next-20170130]
[cannot apply to v4.10-rc6]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Mahesh-Kumar/Enable-IPC-WM-related-WA-s/20170131-230708
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: i386-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All warnings (new ones prefixed by >>):
In file included from arch/x86/include/asm/string.h:2:0,
from include/linux/string.h:18,
from arch/x86/include/asm/page_32.h:34,
from arch/x86/include/asm/page.h:13,
from arch/x86/include/asm/processor.h:17,
from include/linux/mutex.h:19,
from include/linux/notifier.h:13,
from include/linux/clk.h:17,
from include/linux/cpufreq.h:14,
from drivers/gpu/drm/i915/intel_pm.c:28:
drivers/gpu/drm/i915/intel_pm.c: In function
'skl_compute_memory_bandwidth_wm_wa':
>> drivers/gpu/drm/i915/intel_pm.c:4118:56: warning: argument to 'sizeof' in
>> '__builtin_memcpy' call is the same expression as the destination; did you
>> mean to dereference it? [-Wsizeof-pointer-memaccess]
memcpy(mem_attr, &dev_priv->wm.skl_hw.mem_attr, sizeof(mem_attr));
^
arch/x86/include/asm/string_32.h:182:48: note: in definition of macro
'memcpy'
#define memcpy(t, f, n) __builtin_memcpy(t, f, n)
^
vim +4118 drivers/gpu/drm/i915/intel_pm.c
4102 mem_attr->mem_wa = WATERMARK_WA_NONE;
4103 return 0;
4104 }
4105
4106 if (!memdev_info->valid)
4107 goto exit;
4108
4109 /*
4110 * We hold wm_mutex lock, so any other flip can't proceed
beyond WM
4111 * calculation step until this flip writes modified WM values.
4112 * So it's safe to read plane_state of other pipes without
taking CRTC lock
4113 */
4114 ret = drm_modeset_lock(&dev_priv->wm.wm_ww_mutex,
state->acquire_ctx);
4115 if (ret)
4116 return ret;
4117
> 4118 memcpy(mem_attr, &dev_priv->wm.skl_hw.mem_attr,
> sizeof(mem_attr));
4119
4120 for_each_crtc_in_state(state, crtc, cstate, i) {
4121 struct drm_plane *plane;
4122 const struct drm_plane_state *pstate;
4123 int active_planes = 0;
4124 uint32_t max_plane_bw_kbps = 0;
4125
4126 mem_attr->pipe_y_tiled[i] = false;
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH RFC] drm/i915: reduce cursor size for GEN5 hardware
Hello, On Tue, Jan 31, 2017 at 10:03:26AM +0100, Maarten Lankhorst wrote: > Op 31-01-17 om 09:09 schreef Uwe Kleine-König: > > From: Chris Wilson > > > > As the introduced comment admits this is clearly a workaround, but for > > me this is the only known way to make my Lenovo X201 work without > > flickering and crashing. > > > > Signed-off-by: Uwe Kleine-König > > [uwe: added changelog, comment and restrict to GEN5] > > --- > > Hello, > > > > as I don't like having to compile my own kernel (which has this workaround) > > I > > suggest to apply this patch until someone with more knowledge than me about > > i915 finds the muse and time to work on this. > > Just curious, does this help? > > diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c > index ae2c0bb4b2e8..13de4c526ca6 100644 > --- a/drivers/gpu/drm/i915/intel_pm.c > +++ b/drivers/gpu/drm/i915/intel_pm.c > @@ -1838,7 +1838,7 @@ static uint32_t ilk_compute_cur_wm(const struct > intel_crtc_state *cstate, >* this is necessary to avoid flickering. >*/ > int cpp = 4; > - int width = pstate->base.visible ? pstate->base.crtc_w : 64; > + int width = 256; > > if (!cstate->base.active) > return 0; > On a kernel with this patch applied I cannot reproduce the flickering. I keep that kernel running but expect that it also fixes the crash. Best regards Uwe signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm-misc: Document small drivers expectations
On Tue, Jan 31, 2017 at 07:01:44PM +0100, Daniel Vetter wrote: > For the experiement we have right now Eric (with vc4) and Sean Paul > (with rockchip and zte) volunteering, and Gerd (entire pile of qemu > drivers) and Boris (atmel) are also considering to participate. I > think that's enough to get started and figure things out as we go. > > I tried to summarize the main points from the rfc discussions into a > short chapter. Did we decide on whether we're using a topic branch to start out? Also, are you on the hook for pull requests? Sean > > v2: Spelling fixes (Anholt). > > Cc: Boris Brezillon > Cc: Eric Anholt > Cc: Sean Paul > Cc: Gerd Hoffmann > Cc: Mark Yao > Cc: Shawn Guo > Acked-by: Sean Paul > Acked-by: Gerd Hoffmann > Acked-by: Boris Brezillon > Acked-by: Eric Anholt > Signed-off-by: Daniel Vetter > --- > drm-misc.rst | 30 ++ > 1 file changed, 30 insertions(+) > > diff --git a/drm-misc.rst b/drm-misc.rst > index 3d711ec60047..7f7233cf3c61 100644 > --- a/drm-misc.rst > +++ b/drm-misc.rst > @@ -93,6 +93,36 @@ Right now the only hard merge criteria are: > * See also the extensive `committer guidelines for drm-intel >`_. > > +Small Drivers > += > + > +Small drivers, where a full tree is overkill, can be maintained in drm-misc. > For > +now it's just an experiment with a few drivers to figure out a working > process. > +Slightly different rules apply: > + > +* Small is measured in patches merged per kernel release. The occasional big > + patch series is still acceptable if it's not a common thing (e.g. new hw > + enabling once a year), and if the series is really big (more than 20 > patches) > + it should probably be managed through a topic branch in drm-misc and with a > + separate pull request to drm maintainer. dim_ supports this with the > + create-branch command. > + > +* Group maintainership is assumed, i.e. all regular contributors (not just > + the primary maintainer) will get commit rights. > + > +* Since even a broken driver is more useful than no driver minimal review > + standards are a lot lower. The default should be some notes about what > could > + be improved in follow-up work and accepting patches by default. Maintainer > + group for drivers can agree on stricter rules, especially when they have a > + bigger user base that shouldn't suffer from regressions. > + > +* Minimal peer-review is also expected for drivers with just one contributor, > + but obviously then only focuses on best practices for the interaction with > drm > + core and helpers. Plus a bit looking for common patterns in dealing with > the > + hardware, since display IP all has to handle the same issues in the end. In > + most cases this will just along the lines of "Looks good, Ack". drm-misc > + maintainers will help out with getting that review market going. > + > Tooling > === > > -- > 2.11.0 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Sean Paul, Software Engineer, Google / Chromium OS ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm-misc: Document small drivers expectations
On Tue, Jan 31, 2017 at 02:31:32PM -0500, Sean Paul wrote: > On Tue, Jan 31, 2017 at 07:01:44PM +0100, Daniel Vetter wrote: > > For the experiement we have right now Eric (with vc4) and Sean Paul > > (with rockchip and zte) volunteering, and Gerd (entire pile of qemu > > drivers) and Boris (atmel) are also considering to participate. I > > think that's enough to get started and figure things out as we go. > > > > I tried to summarize the main points from the rfc discussions into a > > short chapter. > > Did we decide on whether we're using a topic branch to start out? Also, are > you > on the hook for pull requests? Hm, I guess that was too implicit. The idea is that anything small goes directly into drm-misc-next, and only really huge stuff (I've picked an arbitrary limit of 20+ patches) goes into a topic branch. That's definitely something we need to refine as we go I think. But for one-off patches I think the common tree is really a benefit, since no coordination between subsytem wide refactoring and driver patches is needed through pull requests. And yes since it's the same tree I'm volunteering for pull requests. dim status tells me when there's something pending (I wrote that a bit ago as prep to make drm-misc easy for me). -Daniel > > Sean > > > > > v2: Spelling fixes (Anholt). > > > > Cc: Boris Brezillon > > Cc: Eric Anholt > > Cc: Sean Paul > > Cc: Gerd Hoffmann > > Cc: Mark Yao > > Cc: Shawn Guo > > Acked-by: Sean Paul > > Acked-by: Gerd Hoffmann > > Acked-by: Boris Brezillon > > Acked-by: Eric Anholt > > Signed-off-by: Daniel Vetter > > --- > > drm-misc.rst | 30 ++ > > 1 file changed, 30 insertions(+) > > > > diff --git a/drm-misc.rst b/drm-misc.rst > > index 3d711ec60047..7f7233cf3c61 100644 > > --- a/drm-misc.rst > > +++ b/drm-misc.rst > > @@ -93,6 +93,36 @@ Right now the only hard merge criteria are: > > * See also the extensive `committer guidelines for drm-intel > >`_. > > > > +Small Drivers > > += > > + > > +Small drivers, where a full tree is overkill, can be maintained in > > drm-misc. For > > +now it's just an experiment with a few drivers to figure out a working > > process. > > +Slightly different rules apply: > > + > > +* Small is measured in patches merged per kernel release. The occasional > > big > > + patch series is still acceptable if it's not a common thing (e.g. new hw > > + enabling once a year), and if the series is really big (more than 20 > > patches) > > + it should probably be managed through a topic branch in drm-misc and > > with a > > + separate pull request to drm maintainer. dim_ supports this with the > > + create-branch command. > > + > > +* Group maintainership is assumed, i.e. all regular contributors (not just > > + the primary maintainer) will get commit rights. > > + > > +* Since even a broken driver is more useful than no driver minimal review > > + standards are a lot lower. The default should be some notes about what > > could > > + be improved in follow-up work and accepting patches by default. > > Maintainer > > + group for drivers can agree on stricter rules, especially when they have > > a > > + bigger user base that shouldn't suffer from regressions. > > + > > +* Minimal peer-review is also expected for drivers with just one > > contributor, > > + but obviously then only focuses on best practices for the interaction > > with drm > > + core and helpers. Plus a bit looking for common patterns in dealing with > > the > > + hardware, since display IP all has to handle the same issues in the end. > > In > > + most cases this will just along the lines of "Looks good, Ack". drm-misc > > + maintainers will help out with getting that review market going. > > + > > Tooling > > === > > > > -- > > 2.11.0 > > > > ___ > > Intel-gfx mailing list > > Intel-gfx@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx > > -- > Sean Paul, Software Engineer, Google / Chromium OS -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/2] drm/i915: Backport vma fixes for 4.10-rc6
On Tue, Jan 31, 2017 at 1:21 AM, Maarten Lankhorst
wrote:
>
> This is marked for rc6 because it seems the issue is triggerable on
> mainline and resulting in an oops.
So I did apply my obvious "avoid the oops and just warn about it"
patch: commit 39cb2c9a316e ("drm/i915: Check for NULL i915_vma in
intel_unpin_fb_obj()").
I haven't actually triggered the problem since, so I don't know if
there might be some other downstream issue, but the workaround *may*
just be acceptable from a 4.10 standpoint.
Some maintainer who knows the code better should make the judgment call.
Linus
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/2] drm/i915: Backport vma fixes for 4.10-rc6
On Tue, Jan 31, 2017 at 12:28:40PM -0800, Linus Torvalds wrote:
> On Tue, Jan 31, 2017 at 1:21 AM, Maarten Lankhorst
> wrote:
> >
> > This is marked for rc6 because it seems the issue is triggerable on
> > mainline and resulting in an oops.
>
> So I did apply my obvious "avoid the oops and just warn about it"
> patch: commit 39cb2c9a316e ("drm/i915: Check for NULL i915_vma in
> intel_unpin_fb_obj()").
>
> I haven't actually triggered the problem since, so I don't know if
> there might be some other downstream issue, but the workaround *may*
> just be acceptable from a 4.10 standpoint.
You need sufficient memory pressure to start using partial views, and then
kill the X server while it's using that partial view still (i.e. not too
much memory pressure to prevent them from getting evicted). And it's
global gttt pressure, so not much do to with what's going on on your
machine. So hard to hit, but when you do the book-keeping is rather
completely wreaked since we throw away the views while they're still in
use.
> Some maintainer who knows the code better should make the judgment call.
It's a lot less scary than what I thought:
- the cherry picks needed are a lot less than what I feared, a lot of the
prep work landed in 4.10 and a bunch of it in patches in linux-next
aren't needed for 4.10 due to other reasons.
- we have a testcase to repro this instantly. It uses rotation instead of
partial views (which depend upon allocation order to hit the bug,
rotation is deterministic), but the same code blows up for the same
reasons because it's a bug in the view code, not with a specific view.
The only thing that's mildly scary is that we need a drm core patch to
make it happen. But that one has been for a while in linux-next too, so
should be acceptable. Only thing left to do is let CI beat on this
specifically for a bit, so pull request should be ready for -rc7 I hope.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/7] DisplayPort audio support on Cherrytrail
Hi, the following patches enable DisplayPort Audio on Cherrytrail machines when applied on top of my topic/intel-lpe-audio branch. Tests of DP audio were run on Dell Wyse 3040. The regression test were performed on Baytrail (Compute Stick) and Cherrytrail (Zotac PI330) in HDMI mode. On Cherrytrail there were no issues changing between HDMI and DP connectors dynamically. Could you i915 people review and give ACK if they are OK? The changes in drm/i915 side are fairly trivial, so I'd like to take them through sound git tree once after I receive your ACKs. Changes since RFC: - reordered and squashed patches - clean-up of register definitions and offsets (based on feedback from Jani/Ville) - unmute amp for both HDMI and DP unconditionally - mute amp on invalid ELD (unplug) - remove test for chicken bit which seems to have no effect in hardware - cosmetic edits to make checkpatch happy - change i915 notification argument to pass the plataform device instead Most of hard work in this patchset has been done by Pierre, so all credits go to him. thanks, Takashi === Pierre-Louis Bossart (4): drm/i915: add DP support in LPE audio mode drm/i915: add DisplayPort amp unmute for LPE audio mode ALSA: x86: intel_hdmi: add definitions and logic for DP audio ALSA: x86: Use config base depending on the pipe Takashi Iwai (3): drm/i915: Avoid MST pipe handling for LPE audio drm/i915: Pass pipe to LPE audio notification drm/i915: Pass platform device to LPE audio notifier drivers/gpu/drm/i915/i915_drv.h| 3 +- drivers/gpu/drm/i915/i915_reg.h| 10 ++ drivers/gpu/drm/i915/intel_audio.c | 38 +--- drivers/gpu/drm/i915/intel_lpe_audio.c | 28 +- include/drm/intel_lpe_audio.h | 7 +- sound/x86/intel_hdmi_audio.c | 173 - sound/x86/intel_hdmi_audio.h | 8 +- sound/x86/intel_hdmi_lpe_audio.c | 83 sound/x86/intel_hdmi_lpe_audio.h | 29 ++ 9 files changed, 315 insertions(+), 64 deletions(-) -- 2.11.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: add DP support in LPE audio mode
From: Pierre-Louis Bossart
If DisplayPort is detected, pass flag and link rate to audio driver
Signed-off-by: Pierre-Louis Bossart
Signed-off-by: Takashi Iwai
---
drivers/gpu/drm/i915/i915_drv.h| 3 ++-
drivers/gpu/drm/i915/intel_audio.c | 19 +++
drivers/gpu/drm/i915/intel_lpe_audio.c | 7 ++-
include/drm/intel_lpe_audio.h | 2 ++
4 files changed, 25 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 3e3102cedc82..836d823d476b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3401,7 +3401,8 @@ int intel_lpe_audio_init(struct drm_i915_private
*dev_priv);
void intel_lpe_audio_teardown(struct drm_i915_private *dev_priv);
void intel_lpe_audio_irq_handler(struct drm_i915_private *dev_priv);
void intel_lpe_audio_notify(struct drm_i915_private *dev_priv,
- void *eld, int port, int tmds_clk_speed);
+ void *eld, int port, int tmds_clk_speed,
+ bool dp_output, int link_rate);
/* intel_i2c.c */
extern int intel_setup_gmbus(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/intel_audio.c
b/drivers/gpu/drm/i915/intel_audio.c
index 364f96207c40..1645ce42b898 100644
--- a/drivers/gpu/drm/i915/intel_audio.c
+++ b/drivers/gpu/drm/i915/intel_audio.c
@@ -631,9 +631,20 @@ void intel_audio_codec_enable(struct intel_encoder
*intel_encoder,
if (acomp && acomp->audio_ops && acomp->audio_ops->pin_eld_notify)
acomp->audio_ops->pin_eld_notify(acomp->audio_ops->audio_ptr,
(int) port, (int) pipe);
-
- intel_lpe_audio_notify(dev_priv, connector->eld, port,
- crtc_state->port_clock);
+ switch (intel_encoder->type) {
+ case INTEL_OUTPUT_HDMI:
+ intel_lpe_audio_notify(dev_priv, connector->eld, port,
+ crtc_state->port_clock,
+ false, 0);
+ break;
+ case INTEL_OUTPUT_DP:
+ intel_lpe_audio_notify(dev_priv, connector->eld, port,
+ adjusted_mode->crtc_clock,
+ true, crtc_state->port_clock);
+ break;
+ default:
+ break;
+ }
}
/**
@@ -668,7 +679,7 @@ void intel_audio_codec_disable(struct intel_encoder
*intel_encoder)
acomp->audio_ops->pin_eld_notify(acomp->audio_ops->audio_ptr,
(int) port, (int) pipe);
- intel_lpe_audio_notify(dev_priv, NULL, port, 0);
+ intel_lpe_audio_notify(dev_priv, NULL, port, 0, false, 0);
}
/**
diff --git a/drivers/gpu/drm/i915/intel_lpe_audio.c
b/drivers/gpu/drm/i915/intel_lpe_audio.c
index 27d94255872d..245523e14418 100644
--- a/drivers/gpu/drm/i915/intel_lpe_audio.c
+++ b/drivers/gpu/drm/i915/intel_lpe_audio.c
@@ -332,7 +332,8 @@ void intel_lpe_audio_teardown(struct drm_i915_private
*dev_priv)
* Notify lpe audio driver of eld change.
*/
void intel_lpe_audio_notify(struct drm_i915_private *dev_priv,
- void *eld, int port, int tmds_clk_speed)
+ void *eld, int port, int tmds_clk_speed,
+ bool dp_output, int link_rate)
{
unsigned long irq_flags;
struct intel_hdmi_lpe_audio_pdata *pdata = NULL;
@@ -351,12 +352,16 @@ void intel_lpe_audio_notify(struct drm_i915_private
*dev_priv,
pdata->eld.port_id = port;
pdata->hdmi_connected = true;
+ pdata->dp_output = dp_output;
if (tmds_clk_speed)
pdata->tmds_clock_speed = tmds_clk_speed;
+ if (link_rate)
+ pdata->link_rate = link_rate;
} else {
memset(pdata->eld.eld_data, 0,
HDMI_MAX_ELD_BYTES);
pdata->hdmi_connected = false;
+ pdata->dp_output = false;
}
if (pdata->notify_audio_lpe)
diff --git a/include/drm/intel_lpe_audio.h b/include/drm/intel_lpe_audio.h
index 952de05a9d76..857e0eafed79 100644
--- a/include/drm/intel_lpe_audio.h
+++ b/include/drm/intel_lpe_audio.h
@@ -38,6 +38,8 @@ struct intel_hdmi_lpe_audio_pdata {
bool notify_pending;
int tmds_clock_speed;
bool hdmi_connected;
+ bool dp_output;
+ int link_rate;
struct intel_hdmi_lpe_audio_eld eld;
void (*notify_audio_lpe)(void *audio_ptr);
spinlock_t lpe_audio_slock;
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/7] drm/i915: Avoid MST pipe handling for LPE audio
The pipe gets cleared to -1 for non-MST before the ELD audio
notification due to the MST audio support. This makes sense for
HD-audio that received the MST handling, but it's useless for LPE
audio. Handle the MST pipe hack conditionally only for HD-audio.
Reported-by: Pierre-Louis Bossart
Signed-off-by: Takashi Iwai
---
drivers/gpu/drm/i915/intel_audio.c | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_audio.c
b/drivers/gpu/drm/i915/intel_audio.c
index 1645ce42b898..d4e6d1136cfe 100644
--- a/drivers/gpu/drm/i915/intel_audio.c
+++ b/drivers/gpu/drm/i915/intel_audio.c
@@ -624,13 +624,14 @@ void intel_audio_codec_enable(struct intel_encoder
*intel_encoder,
dev_priv->av_enc_map[pipe] = intel_encoder;
mutex_unlock(&dev_priv->av_mutex);
- /* audio drivers expect pipe = -1 to indicate Non-MST cases */
- if (intel_encoder->type != INTEL_OUTPUT_DP_MST)
- pipe = -1;
-
- if (acomp && acomp->audio_ops && acomp->audio_ops->pin_eld_notify)
+ if (acomp && acomp->audio_ops && acomp->audio_ops->pin_eld_notify) {
+ /* audio drivers expect pipe = -1 to indicate Non-MST cases */
+ if (intel_encoder->type != INTEL_OUTPUT_DP_MST)
+ pipe = -1;
acomp->audio_ops->pin_eld_notify(acomp->audio_ops->audio_ptr,
(int) port, (int) pipe);
+ }
+
switch (intel_encoder->type) {
case INTEL_OUTPUT_HDMI:
intel_lpe_audio_notify(dev_priv, connector->eld, port,
@@ -671,13 +672,13 @@ void intel_audio_codec_disable(struct intel_encoder
*intel_encoder)
dev_priv->av_enc_map[pipe] = NULL;
mutex_unlock(&dev_priv->av_mutex);
- /* audio drivers expect pipe = -1 to indicate Non-MST cases */
- if (intel_encoder->type != INTEL_OUTPUT_DP_MST)
- pipe = -1;
-
- if (acomp && acomp->audio_ops && acomp->audio_ops->pin_eld_notify)
+ if (acomp && acomp->audio_ops && acomp->audio_ops->pin_eld_notify) {
+ /* audio drivers expect pipe = -1 to indicate Non-MST cases */
+ if (intel_encoder->type != INTEL_OUTPUT_DP_MST)
+ pipe = -1;
acomp->audio_ops->pin_eld_notify(acomp->audio_ops->audio_ptr,
(int) port, (int) pipe);
+ }
intel_lpe_audio_notify(dev_priv, NULL, port, 0, false, 0);
}
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/7] ALSA: x86: intel_hdmi: add definitions and logic for DP audio
From: Pierre-Louis Bossart
Imported from legacy patches
Note: the new code doesn't assume a modified ELD but
an explicit notification that DP is present. It appears
that the i915 code does change the ELD so we could use
the ELD-based tests to check for DP audio
Signed-off-by: Pierre-Louis Bossart
Signed-off-by: Takashi Iwai
---
sound/x86/intel_hdmi_audio.c | 173 +--
sound/x86/intel_hdmi_audio.h | 8 +-
sound/x86/intel_hdmi_lpe_audio.c | 36 +++-
sound/x86/intel_hdmi_lpe_audio.h | 29 +++
4 files changed, 216 insertions(+), 30 deletions(-)
diff --git a/sound/x86/intel_hdmi_audio.c b/sound/x86/intel_hdmi_audio.c
index f30155446117..5ce139c1b21d 100644
--- a/sound/x86/intel_hdmi_audio.c
+++ b/sound/x86/intel_hdmi_audio.c
@@ -396,6 +396,7 @@ static int snd_intelhad_prog_audio_ctrl_v2(struct
snd_pcm_substream *substream,
else
cfg_val.cfg_regx_v2.layout = LAYOUT1;
+ cfg_val.cfg_regx_v2.val_bit = 1;
had_write_register(AUD_CONFIG, cfg_val.cfg_regval);
return 0;
}
@@ -447,6 +448,7 @@ static int snd_intelhad_prog_audio_ctrl_v1(struct
snd_pcm_substream *substream,
}
+ cfg_val.cfg_regx.val_bit = 1;
had_write_register(AUD_CONFIG, cfg_val.cfg_regval);
return 0;
}
@@ -548,6 +550,7 @@ void had_build_channel_allocation_map(struct snd_intelhad
*intelhaddata)
}
had_get_caps(HAD_GET_ELD, &intelhaddata->eeld);
+ had_get_caps(HAD_GET_DP_OUTPUT, &intelhaddata->dp_output);
pr_debug("eeld.speaker_allocation_block = %x\n",
intelhaddata->eeld.speaker_allocation_block);
@@ -685,7 +688,7 @@ static void snd_intelhad_prog_dip_v1(struct
snd_pcm_substream *substream,
/*Calculte the byte wide checksum for all valid DIP words*/
for (i = 0; i < BYTES_PER_WORD; i++)
- checksum += (INFO_FRAME_WORD1 >> i*BITS_PER_BYTE) & MASK_BYTE0;
+ checksum += (HDMI_INFO_FRAME_WORD1 >> i*BITS_PER_BYTE) &
MASK_BYTE0;
for (i = 0; i < BYTES_PER_WORD; i++)
checksum += (frame2.fr2_val >> i*BITS_PER_BYTE) & MASK_BYTE0;
for (i = 0; i < BYTES_PER_WORD; i++)
@@ -693,7 +696,7 @@ static void snd_intelhad_prog_dip_v1(struct
snd_pcm_substream *substream,
frame2.fr2_regx.chksum = -(checksum);
- had_write_register(AUD_HDMIW_INFOFR, INFO_FRAME_WORD1);
+ had_write_register(AUD_HDMIW_INFOFR, HDMI_INFO_FRAME_WORD1);
had_write_register(AUD_HDMIW_INFOFR, frame2.fr2_val);
had_write_register(AUD_HDMIW_INFOFR, frame3.fr3_val);
@@ -722,28 +725,35 @@ static void snd_intelhad_prog_dip_v2(struct
snd_pcm_substream *substream,
union aud_info_frame2 frame2 = {.fr2_val = 0};
union aud_info_frame3 frame3 = {.fr3_val = 0};
u8 checksum = 0;
+ u32 info_frame;
int channels;
channels = substream->runtime->channels;
had_write_register(AUD_CNTL_ST, ctrl_state.ctrl_val);
- frame2.fr2_regx.chnl_cnt = substream->runtime->channels - 1;
+ if (intelhaddata->dp_output) {
+ info_frame = DP_INFO_FRAME_WORD1;
+ frame2.fr2_val = 1;
+ } else {
+ info_frame = HDMI_INFO_FRAME_WORD1;
+ frame2.fr2_regx.chnl_cnt = substream->runtime->channels - 1;
- frame3.fr3_regx.chnl_alloc = snd_intelhad_channel_allocation(
- intelhaddata, channels);
+ frame3.fr3_regx.chnl_alloc = snd_intelhad_channel_allocation(
+ intelhaddata, channels);
- /*Calculte the byte wide checksum for all valid DIP words*/
- for (i = 0; i < BYTES_PER_WORD; i++)
- checksum += (INFO_FRAME_WORD1 >> i*BITS_PER_BYTE) & MASK_BYTE0;
- for (i = 0; i < BYTES_PER_WORD; i++)
- checksum += (frame2.fr2_val >> i*BITS_PER_BYTE) & MASK_BYTE0;
- for (i = 0; i < BYTES_PER_WORD; i++)
- checksum += (frame3.fr3_val >> i*BITS_PER_BYTE) & MASK_BYTE0;
+ /*Calculte the byte wide checksum for all valid DIP words*/
+ for (i = 0; i < BYTES_PER_WORD; i++)
+ checksum += (info_frame >> i*BITS_PER_BYTE) &
MASK_BYTE0;
+ for (i = 0; i < BYTES_PER_WORD; i++)
+ checksum += (frame2.fr2_val >> i*BITS_PER_BYTE) &
MASK_BYTE0;
+ for (i = 0; i < BYTES_PER_WORD; i++)
+ checksum += (frame3.fr3_val >> i*BITS_PER_BYTE) &
MASK_BYTE0;
- frame2.fr2_regx.chksum = -(checksum);
+ frame2.fr2_regx.chksum = -(checksum);
+ }
- had_write_register(AUD_HDMIW_INFOFR_v2, INFO_FRAME_WORD1);
+ had_write_register(AUD_HDMIW_INFOFR_v2, info_frame);
had_write_register(AUD_HDMIW_INFOFR_v2, frame2.fr2_val);
had_write_register(AUD_HDMIW_INFOFR_v2, frame3.fr3_val);
@@ -839,6 +849,85 @@ int snd_intelhad_read_len(struct snd_intelhad
[Intel-gfx] [PATCH 6/7] ALSA: x86: Use config base depending on the pipe
From: Pierre-Louis Bossart
Now the pipe that is being used is passed over i915 notification, we
can re-setup the relevant register offset depending on pipe assignments
during hotplug.
This allows playback on single port machines such Zotac Pi330 or
dual-port machines such as Dell Wyse 3040 box
Signed-off-by: Pierre-Louis Bossart
Signed-off-by: Takashi Iwai
---
sound/x86/intel_hdmi_lpe_audio.c | 26 +-
1 file changed, 21 insertions(+), 5 deletions(-)
diff --git a/sound/x86/intel_hdmi_lpe_audio.c b/sound/x86/intel_hdmi_lpe_audio.c
index cea05dfc081a..6d630f20bca8 100644
--- a/sound/x86/intel_hdmi_lpe_audio.c
+++ b/sound/x86/intel_hdmi_lpe_audio.c
@@ -463,6 +463,22 @@ static void notify_audio_lpe(void *audio_ptr)
} else if (eld != NULL) {
+ switch (eld->pipe_id) {
+ case 0:
+ ctx->had_config_offset = AUDIO_HDMI_CONFIG_A;
+ break;
+ case 1:
+ ctx->had_config_offset = AUDIO_HDMI_CONFIG_B;
+ break;
+ case 2:
+ ctx->had_config_offset = AUDIO_HDMI_CONFIG_C;
+ break;
+ default:
+ dev_dbg(&hlpe_pdev->dev, "Invalid pipe %d\n",
+ eld->pipe_id);
+ break;
+ }
+
hdmi_set_eld(eld->eld_data);
mid_hdmi_audio_signal_event(HAD_EVENT_HOT_PLUG);
@@ -560,15 +576,15 @@ static int hdmi_lpe_audio_probe(struct platform_device
*pdev)
ctx->mmio_start = mmio_start;
ctx->tmds_clock_speed = DIS_SAMPLE_RATE_148_5;
- if (pci_dev_present(cherryview_ids)) {
+ if (pci_dev_present(cherryview_ids))
dev_dbg(&hlpe_pdev->dev, "%s: Cherrytrail LPE - Detected\n",
__func__);
- ctx->had_config_offset = AUDIO_HDMI_CONFIG_C;
- } else {
+ else
dev_dbg(&hlpe_pdev->dev, "%s: Baytrail LPE - Assume\n",
__func__);
- ctx->had_config_offset = AUDIO_HDMI_CONFIG_A;
- }
+
+ /* assume pipe A as default */
+ ctx->had_config_offset = AUDIO_HDMI_CONFIG_A;
pdata = pdev->dev.platform_data;
--
2.11.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: Pass platform device to LPE audio notifier
This allows the LPE HDMI driver to clean up its global variable
reference.
Also drop to pass the eld pointer because the connection status and
the ELD bytes can be retrieved from the attached pdata.
Signed-off-by: Takashi Iwai
---
drivers/gpu/drm/i915/intel_lpe_audio.c | 3 +--
include/drm/intel_lpe_audio.h | 4 +++-
sound/x86/intel_hdmi_lpe_audio.c | 23 +++
3 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lpe_audio.c
b/drivers/gpu/drm/i915/intel_lpe_audio.c
index 2ca3c775c6b1..ef0e74830289 100644
--- a/drivers/gpu/drm/i915/intel_lpe_audio.c
+++ b/drivers/gpu/drm/i915/intel_lpe_audio.c
@@ -383,8 +383,7 @@ void intel_lpe_audio_notify(struct drm_i915_private
*dev_priv,
}
if (pdata->notify_audio_lpe)
- pdata->notify_audio_lpe(
- (eld != NULL) ? &pdata->eld : NULL);
+ pdata->notify_audio_lpe(dev_priv->lpe_audio.platdev);
else
pdata->notify_pending = true;
diff --git a/include/drm/intel_lpe_audio.h b/include/drm/intel_lpe_audio.h
index 410128e4cd70..e9892b4c3af1 100644
--- a/include/drm/intel_lpe_audio.h
+++ b/include/drm/intel_lpe_audio.h
@@ -27,6 +27,8 @@
#include
#include
+struct platform_device;
+
#define HDMI_MAX_ELD_BYTES 128
struct intel_hdmi_lpe_audio_eld {
@@ -42,7 +44,7 @@ struct intel_hdmi_lpe_audio_pdata {
bool dp_output;
int link_rate;
struct intel_hdmi_lpe_audio_eld eld;
- void (*notify_audio_lpe)(void *audio_ptr);
+ void (*notify_audio_lpe)(struct platform_device *pdev);
spinlock_t lpe_audio_slock;
};
diff --git a/sound/x86/intel_hdmi_lpe_audio.c b/sound/x86/intel_hdmi_lpe_audio.c
index 6d630f20bca8..3cb0f642575c 100644
--- a/sound/x86/intel_hdmi_lpe_audio.c
+++ b/sound/x86/intel_hdmi_lpe_audio.c
@@ -439,15 +439,14 @@ static irqreturn_t display_pipe_interrupt_handler(int
irq, void *dev_id)
return IRQ_HANDLED;
}
-static void notify_audio_lpe(void *audio_ptr)
+static void notify_audio_lpe(struct platform_device *pdev)
{
- struct hdmi_lpe_audio_ctx *ctx = get_hdmi_context();
- struct intel_hdmi_lpe_audio_pdata *pdata = hlpe_pdev->dev.platform_data;
- struct intel_hdmi_lpe_audio_eld *eld = audio_ptr;
+ struct hdmi_lpe_audio_ctx *ctx = platform_get_drvdata(pdev);
+ struct intel_hdmi_lpe_audio_pdata *pdata = pdev->dev.platform_data;
if (pdata->hdmi_connected != true) {
- dev_dbg(&hlpe_pdev->dev, "%s: Event: HAD_NOTIFY_HOT_UNPLUG\n",
+ dev_dbg(&pdev->dev, "%s: Event: HAD_NOTIFY_HOT_UNPLUG\n",
__func__);
if (hlpe_state == hdmi_connector_status_connected) {
@@ -458,10 +457,11 @@ static void notify_audio_lpe(void *audio_ptr)
mid_hdmi_audio_signal_event(
HAD_EVENT_HOT_UNPLUG);
} else
- dev_dbg(&hlpe_pdev->dev, "%s: Already Unplugged!\n",
+ dev_dbg(&pdev->dev, "%s: Already Unplugged!\n",
__func__);
- } else if (eld != NULL) {
+ } else {
+ struct intel_hdmi_lpe_audio_eld *eld = &pdata->eld;
switch (eld->pipe_id) {
case 0:
@@ -474,7 +474,7 @@ static void notify_audio_lpe(void *audio_ptr)
ctx->had_config_offset = AUDIO_HDMI_CONFIG_C;
break;
default:
- dev_dbg(&hlpe_pdev->dev, "Invalid pipe %d\n",
+ dev_dbg(&pdev->dev, "Invalid pipe %d\n",
eld->pipe_id);
break;
}
@@ -485,7 +485,7 @@ static void notify_audio_lpe(void *audio_ptr)
hlpe_state = hdmi_connector_status_connected;
- dev_dbg(&hlpe_pdev->dev, "%s: HAD_NOTIFY_ELD : port = %d, tmds
= %d\n",
+ dev_dbg(&pdev->dev, "%s: HAD_NOTIFY_ELD : port = %d, tmds =
%d\n",
__func__, eld->port_id, pdata->tmds_clock_speed);
if (pdata->tmds_clock_speed) {
@@ -494,8 +494,7 @@ static void notify_audio_lpe(void *audio_ptr)
ctx->link_rate = pdata->link_rate;
mid_hdmi_audio_signal_event(HAD_EVENT_MODE_CHANGING);
}
- } else
- dev_dbg(&hlpe_pdev->dev, "%s: Event: NULL EDID!!\n", __func__);
+ }
}
/**
@@ -606,7 +605,7 @@ static int hdmi_lpe_audio_probe(struct platform_device
*pdev)
if (pdata->notify_pending) {
dev_dbg(&hlpe_pdev->dev, "%s: handle pending notification\n",
__func__);
- notify_audio_lpe(&pdata->eld);
+ notify_audio_lpe(pdev);
pdata->notify_pending = false;
}
spin_unlock_irqrestore(&pdata->lpe_audio_slock, flag_irq);
--
2.11.0
___
[Intel-gfx] [PATCH 2/7] drm/i915: add DisplayPort amp unmute for LPE audio mode
From: Pierre-Louis Bossart
Enable unmute/mute amp notification. This doesn't seem to affect
HDMI support so this is done unconditionally.
An earlier version of this patch set a chicken bit at address 0x62F38
prior to the mute/unmute but this register doesn't seem to do anything
so this phase was removed.
Signed-off-by: Pierre-Louis Bossart
Signed-off-by: Takashi Iwai
---
drivers/gpu/drm/i915/i915_reg.h| 10 ++
drivers/gpu/drm/i915/intel_lpe_audio.c | 17 +
2 files changed, 27 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index a9ffc8df241b..8fcc80cb864b 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2061,6 +2061,16 @@ enum skl_disp_power_wells {
#define I915_HDMI_LPE_AUDIO_BASE (VLV_DISPLAY_BASE + 0x65000)
#define I915_HDMI_LPE_AUDIO_SIZE 0x1000
+/* DisplayPort Audio w/ LPE */
+#define VLV_AUD_PORT_EN_B_DBG (VLV_DISPLAY_BASE + 0x62F20)
+#define VLV_AUD_PORT_EN_C_DBG (VLV_DISPLAY_BASE + 0x62F30)
+#define VLV_AUD_PORT_EN_D_DBG (VLV_DISPLAY_BASE + 0x62F34)
+#define VLV_AUD_PORT_EN_DBG(port) _MMIO_PORT3((port) - PORT_B, \
+ VLV_AUD_PORT_EN_B_DBG, \
+ VLV_AUD_PORT_EN_C_DBG, \
+ VLV_AUD_PORT_EN_D_DBG)
+#define VLV_AMP_MUTE (1 << 1)
+
#define GEN6_BSD_RNCID _MMIO(0x12198)
#define GEN7_FF_THREAD_MODE_MMIO(0x20a0)
diff --git a/drivers/gpu/drm/i915/intel_lpe_audio.c
b/drivers/gpu/drm/i915/intel_lpe_audio.c
index 245523e14418..f95624a46f27 100644
--- a/drivers/gpu/drm/i915/intel_lpe_audio.c
+++ b/drivers/gpu/drm/i915/intel_lpe_audio.c
@@ -337,15 +337,25 @@ void intel_lpe_audio_notify(struct drm_i915_private
*dev_priv,
{
unsigned long irq_flags;
struct intel_hdmi_lpe_audio_pdata *pdata = NULL;
+ u32 audio_enable;
+ i915_reg_t mmio;
if (!HAS_LPE_AUDIO(dev_priv))
return;
+ if (port == PORT_A) {
+ DRM_ERROR("PORT_A is not valid for HDMI/DP usages\n");
+ return;
+ }
+
pdata = dev_get_platdata(
&(dev_priv->lpe_audio.platdev->dev));
spin_lock_irqsave(&pdata->lpe_audio_slock, irq_flags);
+ mmio = VLV_AUD_PORT_EN_DBG(port);
+ audio_enable = I915_READ(mmio);
+
if (eld != NULL) {
memcpy(pdata->eld.eld_data, eld,
HDMI_MAX_ELD_BYTES);
@@ -357,11 +367,18 @@ void intel_lpe_audio_notify(struct drm_i915_private
*dev_priv,
pdata->tmds_clock_speed = tmds_clk_speed;
if (link_rate)
pdata->link_rate = link_rate;
+
+ /* Unmute the amp for both DP and HDMI */
+ I915_WRITE(mmio, audio_enable & ~VLV_AMP_MUTE);
+
} else {
memset(pdata->eld.eld_data, 0,
HDMI_MAX_ELD_BYTES);
pdata->hdmi_connected = false;
pdata->dp_output = false;
+
+ /* Mute the amp for both DP and HDMI */
+ I915_WRITE(mmio, audio_enable | VLV_AMP_MUTE);
}
if (pdata->notify_audio_lpe)
--
2.11.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: Pass pipe to LPE audio notification
The LPE audio configuration depends on the pipe, thus we need to pass
the currently used pipe. It's now embedded in struct
intel_hdmi_lpe_audio_eld as well as port id.
Signed-off-by: Takashi Iwai
---
drivers/gpu/drm/i915/i915_drv.h| 2 +-
drivers/gpu/drm/i915/intel_audio.c | 6 +++---
drivers/gpu/drm/i915/intel_lpe_audio.c | 3 ++-
include/drm/intel_lpe_audio.h | 1 +
4 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 836d823d476b..27311a337e2b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3401,7 +3401,7 @@ int intel_lpe_audio_init(struct drm_i915_private
*dev_priv);
void intel_lpe_audio_teardown(struct drm_i915_private *dev_priv);
void intel_lpe_audio_irq_handler(struct drm_i915_private *dev_priv);
void intel_lpe_audio_notify(struct drm_i915_private *dev_priv,
- void *eld, int port, int tmds_clk_speed,
+ void *eld, int port, int pipe, int tmds_clk_speed,
bool dp_output, int link_rate);
/* intel_i2c.c */
diff --git a/drivers/gpu/drm/i915/intel_audio.c
b/drivers/gpu/drm/i915/intel_audio.c
index d4e6d1136cfe..892169b7952b 100644
--- a/drivers/gpu/drm/i915/intel_audio.c
+++ b/drivers/gpu/drm/i915/intel_audio.c
@@ -634,12 +634,12 @@ void intel_audio_codec_enable(struct intel_encoder
*intel_encoder,
switch (intel_encoder->type) {
case INTEL_OUTPUT_HDMI:
- intel_lpe_audio_notify(dev_priv, connector->eld, port,
+ intel_lpe_audio_notify(dev_priv, connector->eld, port, pipe,
crtc_state->port_clock,
false, 0);
break;
case INTEL_OUTPUT_DP:
- intel_lpe_audio_notify(dev_priv, connector->eld, port,
+ intel_lpe_audio_notify(dev_priv, connector->eld, port, pipe,
adjusted_mode->crtc_clock,
true, crtc_state->port_clock);
break;
@@ -680,7 +680,7 @@ void intel_audio_codec_disable(struct intel_encoder
*intel_encoder)
(int) port, (int) pipe);
}
- intel_lpe_audio_notify(dev_priv, NULL, port, 0, false, 0);
+ intel_lpe_audio_notify(dev_priv, NULL, port, pipe, 0, false, 0);
}
/**
diff --git a/drivers/gpu/drm/i915/intel_lpe_audio.c
b/drivers/gpu/drm/i915/intel_lpe_audio.c
index f95624a46f27..2ca3c775c6b1 100644
--- a/drivers/gpu/drm/i915/intel_lpe_audio.c
+++ b/drivers/gpu/drm/i915/intel_lpe_audio.c
@@ -332,7 +332,7 @@ void intel_lpe_audio_teardown(struct drm_i915_private
*dev_priv)
* Notify lpe audio driver of eld change.
*/
void intel_lpe_audio_notify(struct drm_i915_private *dev_priv,
- void *eld, int port, int tmds_clk_speed,
+ void *eld, int port, int pipe, int tmds_clk_speed,
bool dp_output, int link_rate)
{
unsigned long irq_flags;
@@ -360,6 +360,7 @@ void intel_lpe_audio_notify(struct drm_i915_private
*dev_priv,
memcpy(pdata->eld.eld_data, eld,
HDMI_MAX_ELD_BYTES);
pdata->eld.port_id = port;
+ pdata->eld.pipe_id = pipe;
pdata->hdmi_connected = true;
pdata->dp_output = dp_output;
diff --git a/include/drm/intel_lpe_audio.h b/include/drm/intel_lpe_audio.h
index 857e0eafed79..410128e4cd70 100644
--- a/include/drm/intel_lpe_audio.h
+++ b/include/drm/intel_lpe_audio.h
@@ -31,6 +31,7 @@
struct intel_hdmi_lpe_audio_eld {
int port_id;
+ int pipe_id;
unsigned char eld_data[HDMI_MAX_ELD_BYTES];
};
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for DisplayPort audio support on Cherrytrail
== Series Details == Series: DisplayPort audio support on Cherrytrail URL : https://patchwork.freedesktop.org/series/18864/ State : success == Summary == Series 18864v1 DisplayPort audio support on Cherrytrail https://patchwork.freedesktop.org/api/1.0/series/18864/revisions/1/mbox/ fi-bdw-5557u total:247 pass:233 dwarn:0 dfail:0 fail:0 skip:14 fi-bsw-n3050 total:247 pass:208 dwarn:0 dfail:0 fail:0 skip:39 fi-bxt-j4205 total:247 pass:225 dwarn:0 dfail:0 fail:0 skip:22 fi-bxt-t5700 total:78 pass:65 dwarn:0 dfail:0 fail:0 skip:12 fi-byt-j1900 total:247 pass:220 dwarn:0 dfail:0 fail:0 skip:27 fi-byt-n2820 total:247 pass:216 dwarn:0 dfail:0 fail:0 skip:31 fi-hsw-4770 total:247 pass:228 dwarn:0 dfail:0 fail:0 skip:19 fi-hsw-4770r total:247 pass:228 dwarn:0 dfail:0 fail:0 skip:19 fi-ivb-3520m total:247 pass:226 dwarn:0 dfail:0 fail:0 skip:21 fi-ivb-3770 total:247 pass:226 dwarn:0 dfail:0 fail:0 skip:21 fi-kbl-7500u total:247 pass:224 dwarn:0 dfail:0 fail:2 skip:21 fi-skl-6260u total:247 pass:234 dwarn:0 dfail:0 fail:0 skip:13 fi-skl-6700hqtotal:247 pass:227 dwarn:0 dfail:0 fail:0 skip:20 fi-skl-6700k total:247 pass:222 dwarn:4 dfail:0 fail:0 skip:21 fi-skl-6770hqtotal:247 pass:234 dwarn:0 dfail:0 fail:0 skip:13 fi-snb-2520m total:247 pass:216 dwarn:0 dfail:0 fail:0 skip:31 fi-snb-2600 total:247 pass:215 dwarn:0 dfail:0 fail:0 skip:32 83f390eaec64a1b0566f5f747d20741c077fcff5 drm-tip: 2017y-01m-31d-20h-19m-59s UTC integration manifest 15954fb drm/i915: Pass platform device to LPE audio notifier 1358641 ALSA: x86: Use config base depending on the pipe 0545a59 ALSA: x86: intel_hdmi: add definitions and logic for DP audio 14efa05 drm/i915: Pass pipe to LPE audio notification 32b5514 drm/i915: Avoid MST pipe handling for LPE audio 82dd01f drm/i915: add DisplayPort amp unmute for LPE audio mode 9bf23c4 drm/i915: add DP support in LPE audio mode == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3656/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t v3 07/11] lib/igt_kms: Add support for the OUT_FENCE_PTR property
On 2017-01-31 11:49 AM, Brian Starkey wrote:
On Mon, Jan 30, 2017 at 08:58:43PM -0500, Robert Foss wrote:
From: Gustavo Padovan
Add support for the OUT_FENCE_PTR property to enable setting out
fences for
atomic commits.
Signed-off-by: Gustavo Padovan
Signed-off-by: Robert Foss
---
lib/igt_kms.c | 26 +-
lib/igt_kms.h | 6 +-
2 files changed, 30 insertions(+), 2 deletions(-)
diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index b79d2867..f14496dd 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -179,7 +179,8 @@ const char
*igt_crtc_prop_names[IGT_NUM_CRTC_PROPS] = {
"DEGAMMA_LUT",
"GAMMA_LUT",
"MODE_ID",
-"ACTIVE"
+"ACTIVE",
+"OUT_FENCE_PTR"
};
const char *igt_connector_prop_names[IGT_NUM_CONNECTOR_PROPS] = {
@@ -2393,6 +2394,15 @@ static void
igt_atomic_prepare_crtc_commit(igt_pipe_t *pipe_obj, drmModeAtomicRe
igt_atomic_populate_crtc_req(req, pipe_obj, IGT_CRTC_ACTIVE,
!!output);
}
+pipe_obj->out_fence = -1;
+if (pipe_obj->out_fence_requested)
+{
+pipe_obj->out_fence_requested = false;
+igt_atomic_populate_crtc_req(req, pipe_obj,
IGT_CRTC_OUT_FENCE_PTR,
+(uint64_t)(uintptr_t) &pipe_obj->out_fence);
+igt_assert_f(pipe_obj->out_fence != -1, "Unable to get fence,
received -1 fd\n");
Doesn't this assertion always fail? You just set it to -1
Ack, fixed in v4
+}
+
/*
*TODO: Add all crtc level properties here
*/
@@ -2984,6 +2994,20 @@ igt_pipe_set_gamma_lut(igt_pipe_t *pipe, void
*ptr, size_t length)
}
/**
+ * igt_pipe_set_out_fence_ptr:
+ * @pipe: pipe pointer to which background color to be set
+ * @fence_ptr: out fence pointer
+ *
+ * Sets the out fence pointer that will be passed to the kernel in
+ * the atomic ioctl. When the kernel returns the out fence pointer
+ * will contain the fd number of the out fence created by KMS.
+ */
+void igt_pipe_set_out_fence_ptr(igt_pipe_t *pipe, int64_t *fence_ptr)
+{
+pipe->out_fence_ptr = fence_ptr;
+}
Is this ever used? You seem to use &pipe_obj->out_fence
unconditionally above (and igt_pipe has no member named
out_fence_ptr).
I guess is left over from the previous API and needs to be removed?
That's exactly what happened. Removed in v4.
+
+/**
* igt_crtc_set_background:
* @pipe: pipe pointer to which background color to be set
* @background: background color value in BGR 16bpc
diff --git a/lib/igt_kms.h b/lib/igt_kms.h
index 85688853..9672dadc 100644
--- a/lib/igt_kms.h
+++ b/lib/igt_kms.h
@@ -94,6 +94,7 @@ enum igt_atomic_crtc_properties {
IGT_CRTC_GAMMA_LUT,
IGT_CRTC_MODE_ID,
IGT_CRTC_ACTIVE,
+ IGT_CRTC_OUT_FENCE_PTR,
IGT_NUM_CRTC_PROPS
};
@@ -341,6 +342,9 @@ struct igt_pipe {
uint64_t mode_blob;
bool mode_changed;
+
+int64_t out_fence;
+bool out_fence_requested;
};
typedef struct {
@@ -395,7 +399,7 @@ static inline bool
igt_plane_supports_rotation(igt_plane_t *plane)
{
return plane->rotation_property != 0;
}
-
+void igt_pipe_request_out_fence(igt_pipe_t *pipe);
Not implemented? I think this patch got confused somewhere :-(
-Brian
Yes, some code has been moved around and this piece was not properly
moved. Fixed in v4.
Rob.
void igt_pipe_set_degamma_lut(igt_pipe_t *pipe, void *ptr, size_t
length);
void igt_pipe_set_ctm_matrix(igt_pipe_t *pipe, void *ptr, size_t length);
void igt_pipe_set_gamma_lut(igt_pipe_t *pipe, void *ptr, size_t length);
--
2.11.0.453.g787f75f05
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t v3 08/11] tests/kms_atomic: stress possible fence settings
On 2017-01-31 11:50 AM, Brian Starkey wrote:
This one lgtm, just need to swap all the uint64_t out_fence_ptrs for
int32_t.
-Brian
Fixed in v4.
Rob.
On Mon, Jan 30, 2017 at 08:58:44PM -0500, Robert Foss wrote:
From: Gustavo Padovan
Signed-off-by: Gustavo Padovan
Signed-off-by: Robert Foss
---
tests/kms_atomic.c | 187
++---
1 file changed, 177 insertions(+), 10 deletions(-)
diff --git a/tests/kms_atomic.c b/tests/kms_atomic.c
index 8df51ccd..09605e38 100644
--- a/tests/kms_atomic.c
+++ b/tests/kms_atomic.c
@@ -44,6 +44,7 @@
#include "drmtest.h"
#include "igt.h"
#include "igt_aux.h"
+#include "sw_sync.h"
#ifndef DRM_CLIENT_CAP_ATOMIC
#define DRM_CLIENT_CAP_ATOMIC 3
@@ -126,6 +127,7 @@ struct kms_atomic_plane_state {
uint32_t fb_id; /* 0 to disable */
uint32_t src_x, src_y, src_w, src_h; /* 16.16 fixed-point */
uint32_t crtc_x, crtc_y, crtc_w, crtc_h; /* normal integers */
+int32_t fence_fd;
};
struct kms_atomic_crtc_state {
@@ -133,6 +135,7 @@ struct kms_atomic_crtc_state {
uint32_t obj;
int idx;
bool active;
+uint64_t out_fence_ptr;
struct kms_atomic_blob mode;
};
@@ -190,11 +193,13 @@ static uint32_t blob_duplicate(int fd, uint32_t
id_orig)
crtc_populate_req(crtc, req); \
plane_populate_req(plane, req); \
do_atomic_commit((crtc)->state->desc->fd, req, flags); \
-crtc_check_current_state(crtc, plane, relax); \
-plane_check_current_state(plane, relax); \
+if (!(flags & DRM_MODE_ATOMIC_TEST_ONLY)) { \
+crtc_check_current_state(crtc, plane, relax); \
+plane_check_current_state(plane, relax); \
+} \
}
-#define crtc_commit_atomic_err(crtc, plane, crtc_old, plane_old, req,
relax, e) { \
+#define crtc_commit_atomic_err(crtc, plane, crtc_old, plane_old, req,
flags, relax, e) { \
drmModeAtomicSetCursor(req, 0); \
crtc_populate_req(crtc, req); \
plane_populate_req(plane, req); \
@@ -299,6 +304,9 @@ find_connector(struct kms_atomic_state *state,
static void plane_populate_req(struct kms_atomic_plane_state *plane,
drmModeAtomicReq *req)
{
+if (plane->fence_fd)
+plane_set_prop(req, plane, IGT_PLANE_IN_FENCE_FD,
plane->fence_fd);
+
plane_set_prop(req, plane, IGT_PLANE_CRTC_ID, plane->crtc_id);
plane_set_prop(req, plane, IGT_PLANE_FB_ID, plane->fb_id);
plane_set_prop(req, plane, IGT_PLANE_SRC_X, plane->src_x);
@@ -433,6 +441,10 @@ find_plane(struct kms_atomic_state *state, enum
plane_type type,
static void crtc_populate_req(struct kms_atomic_crtc_state *crtc,
drmModeAtomicReq *req)
{
+if (crtc->out_fence_ptr)
+crtc_set_prop(req, crtc, IGT_CRTC_OUT_FENCE_PTR,
+ crtc->out_fence_ptr);
+
crtc_set_prop(req, crtc, IGT_CRTC_MODE_ID, crtc->mode.id);
crtc_set_prop(req, crtc, IGT_CRTC_ACTIVE, crtc->active);
}
@@ -1061,6 +1073,37 @@ static void plane_invalid_params(struct
kms_atomic_crtc_state *crtc,
drmModeAtomicFree(req);
}
+static void plane_invalid_params_fence(struct kms_atomic_crtc_state
*crtc,
+struct kms_atomic_plane_state *plane_old,
+struct kms_atomic_connector_state *conn)
+{
+struct kms_atomic_plane_state plane = *plane_old;
+drmModeAtomicReq *req = drmModeAtomicAlloc();
+int timeline, fence_fd;
+
+igt_require_sw_sync();
+
+/* invalid fence fd */
+plane.fence_fd = plane.state->desc->fd;
+plane.crtc_id = plane_old->crtc_id;
+plane_commit_atomic_err(&plane, plane_old, req,
+ATOMIC_RELAX_NONE, EINVAL);
+
+/* Valid fence_fd but invalid CRTC */
+timeline = sw_sync_timeline_create();
+fence_fd = sw_sync_timeline_create_fence(timeline, 1);
+plane.fence_fd = fence_fd;
+plane.crtc_id = ~0U;
+plane_commit_atomic_err(&plane, plane_old, req,
+ATOMIC_RELAX_NONE, EINVAL);
+
+plane.fence_fd = -1;
+close(fence_fd);
+close(timeline);
+
+drmModeAtomicFree(req);
+}
+
static void crtc_invalid_params(struct kms_atomic_crtc_state *crtc_old,
struct kms_atomic_plane_state *plane,
struct kms_atomic_connector_state *conn)
@@ -1072,30 +1115,32 @@ static void crtc_invalid_params(struct
kms_atomic_crtc_state *crtc_old,
/* Pass a series of invalid object IDs for the mode ID. */
crtc.mode.id = plane->obj;
-crtc_commit_atomic_err(&crtc, plane, crtc_old, plane, req,
+crtc_commit_atomic_err(&crtc, plane, crtc_old, plane, req, 0,
ATOMIC_RELAX_NONE, EINVAL);
crtc.mode.id = crtc.obj;
-crtc_commit_atomic_err(&crtc, plane, crtc_old, plane, req,
+crtc_commit_atomic_err(&crtc, plane, crtc_old, plane, req, 0,
ATOMIC_RELAX_NONE, EINVAL);
crtc.mode.id = conn->obj;
-crtc_commit_atomic_err(&crtc, plane, crtc_old, plane, req,
+crtc_commit_atomic_err(&crtc, plane, crtc_old, plane, req, 0,
ATOMIC_REL
[Intel-gfx] [PATCH v2] drm/i915: Get correct display clock on 945gm
This is according to Mobile Intel® 945 Express Chipset
Family datasheet.
Signed-off-by: Arthur Heymans
---
drivers/gpu/drm/i915/i915_reg.h | 2 +-
drivers/gpu/drm/i915/intel_display.c | 29 ++---
2 files changed, 27 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 02a65ddae3a3..f0b7849ace17 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -119,7 +119,7 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
#define GCFGC 0xf0 /* 915+ only */
#define GC_LOW_FREQUENCY_ENABLE (1 << 7)
#define GC_DISPLAY_CLOCK_190_200_MHZ (0 << 4)
-#define GC_DISPLAY_CLOCK_333_MHZ (4 << 4)
+#define GC_DISPLAY_CLOCK_333_320_MHZ (4 << 4)
#define GC_DISPLAY_CLOCK_267_MHZ_PNV (0 << 4)
#define GC_DISPLAY_CLOCK_333_MHZ_PNV (1 << 4)
#define GC_DISPLAY_CLOCK_444_MHZ_PNV (2 << 4)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index ac25706b7d4d..3e1deb501983 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7407,7 +7407,27 @@ static int i945_get_display_clock_speed(struct
drm_i915_private *dev_priv)
return 40;
}
-static int i915_get_display_clock_speed(struct drm_i915_private *dev_priv)
+static int i945gm_get_display_clock_speed(struct drm_i915_private *dev_priv)
+{
+ struct pci_dev *pdev = dev_priv->drm.pdev;
+ u16 gcfgc = 0;
+
+ pci_read_config_word(pdev, GCFGC, &gcfgc);
+
+ if (gcfgc & GC_LOW_FREQUENCY_ENABLE)
+ return 13;
+ else {
+ switch (gcfgc & GC_DISPLAY_CLOCK_MASK) {
+ case GC_DISPLAY_CLOCK_333_320_MHZ:
+ return 32;
+ default:
+ case GC_DISPLAY_CLOCK_190_200_MHZ:
+ return 20;
+ }
+ }
+}
+
+static int i915_get_display_clock_speed(struct drm_device *dev)
{
return 33;
}
@@ -7453,7 +7473,7 @@ static int i915gm_get_display_clock_speed(struct
drm_i915_private *dev_priv)
return 13;
else {
switch (gcfgc & GC_DISPLAY_CLOCK_MASK) {
- case GC_DISPLAY_CLOCK_333_MHZ:
+ case GC_DISPLAY_CLOCK_333_320_MHZ:
return 33;
default:
case GC_DISPLAY_CLOCK_190_200_MHZ:
@@ -16244,9 +16264,12 @@ void intel_init_display_hooks(struct drm_i915_private
*dev_priv)
else if (IS_I915G(dev_priv))
dev_priv->display.get_display_clock_speed =
i915_get_display_clock_speed;
- else if (IS_I945GM(dev_priv) || IS_I845G(dev_priv))
+ else if (IS_I845G(dev_priv))
dev_priv->display.get_display_clock_speed =
i9xx_misc_get_display_clock_speed;
+ else if (IS_I945GM(dev_priv))
+ dev_priv->display.get_display_clock_speed =
+ i945gm_get_display_clock_speed;
else if (IS_I915GM(dev_priv))
dev_priv->display.get_display_clock_speed =
i915gm_get_display_clock_speed;
--
2.11.0
___
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: Get correct display clock on 945gm (rev2)
== Series Details == Series: drm/i915: Get correct display clock on 945gm (rev2) URL : https://patchwork.freedesktop.org/series/18693/ State : failure == Summary == CC drivers/acpi/acpica/utpredef.o CC [M] drivers/gpu/drm/i915/i915_perf.o CC [M] drivers/gpu/drm/i915/i915_oa_hsw.o CC drivers/acpi/acpica/utresrc.o CC drivers/acpi/acpica/utstate.o CC drivers/acpi/acpica/utstring.o CC drivers/acpi/acpica/utstrtoul64.o CC drivers/acpi/acpica/utxface.o CC [M] drivers/gpu/drm/i915/intel_gvt.o CC drivers/acpi/acpica/utxfinit.o CC drivers/acpi/acpica/utxferror.o LD net/ipv6/built-in.o CC drivers/acpi/acpica/utxfmutex.o CC [M] drivers/gpu/drm/i915/gvt/aperture_gm.o CC [M] drivers/gpu/drm/i915/gvt/gvt.o LD drivers/iommu/built-in.o CC [M] drivers/gpu/drm/i915/gvt/handlers.o CC [M] drivers/gpu/drm/i915/gvt/vgpu.o CC [M] drivers/gpu/drm/i915/gvt/trace_points.o CC [M] drivers/gpu/drm/i915/gvt/interrupt.o CC [M] drivers/gpu/drm/i915/gvt/firmware.o LD [M] drivers/gpu/drm/vgem/vgem.o CC [M] drivers/gpu/drm/i915/gvt/gtt.o CC [M] drivers/gpu/drm/i915/gvt/cfg_space.o CC [M] drivers/gpu/drm/i915/gvt/opregion.o CC [M] drivers/gpu/drm/i915/gvt/mmio.o CC [M] drivers/gpu/drm/i915/gvt/edid.o CC [M] drivers/gpu/drm/i915/gvt/display.o CC [M] drivers/gpu/drm/i915/gvt/sched_policy.o CC [M] drivers/gpu/drm/i915/gvt/scheduler.o CC [M] drivers/gpu/drm/i915/gvt/execlist.o CC [M] drivers/gpu/drm/i915/gvt/render.o CC [M] drivers/gpu/drm/i915/intel_lpe_audio.o CC [M] drivers/gpu/drm/i915/gvt/cmd_parser.o LD drivers/pci/built-in.o LD drivers/usb/gadget/libcomposite.o LD drivers/video/console/built-in.o LD drivers/video/built-in.o LD drivers/acpi/acpica/acpi.o LD drivers/usb/gadget/udc/udc-core.o LD drivers/gpu/drm/drm.o LD drivers/usb/gadget/udc/built-in.o LD drivers/usb/gadget/built-in.o LD net/xfrm/built-in.o LD drivers/scsi/sd_mod.o LD drivers/scsi/built-in.o LD drivers/acpi/acpica/built-in.o LD [M] drivers/net/ethernet/broadcom/genet/genet.o LD drivers/tty/serial/8250/8250_base.o LD drivers/tty/serial/8250/built-in.o LD drivers/tty/serial/built-in.o LD drivers/acpi/built-in.o drivers/gpu/drm/i915/intel_display.c: In function ‘intel_init_display_hooks’: drivers/gpu/drm/i915/intel_display.c:16268:45: error: assignment from incompatible pointer type [-Werror=incompatible-pointer-types] dev_priv->display.get_display_clock_speed = ^ LD drivers/usb/host/xhci-hcd.o LD [M] sound/pci/hda/snd-hda-codec-generic.o LD sound/pci/built-in.o LD fs/btrfs/btrfs.o LD [M] drivers/net/ethernet/intel/e1000/e1000.o LD sound/built-in.o LD fs/btrfs/built-in.o AR lib/lib.a EXPORTS lib/lib-ksyms.o LD lib/built-in.o LD drivers/usb/core/usbcore.o LD drivers/usb/core/built-in.o LD [M] drivers/net/ethernet/intel/igbvf/igbvf.o CC arch/x86/kernel/cpu/capflags.o LD arch/x86/kernel/cpu/built-in.o LD arch/x86/kernel/built-in.o LD drivers/tty/vt/built-in.o LD drivers/tty/built-in.o LD drivers/md/md-mod.o LD drivers/md/built-in.o LD arch/x86/built-in.o LD net/ipv4/built-in.o LD drivers/usb/host/built-in.o LD drivers/usb/built-in.o LD fs/ext4/ext4.o LD fs/ext4/built-in.o LD net/core/built-in.o LD fs/built-in.o LD net/built-in.o LD [M] drivers/net/ethernet/intel/igb/igb.o LD [M] drivers/net/ethernet/intel/e1000e/e1000e.o LD drivers/net/ethernet/built-in.o LD drivers/net/built-in.o cc1: all warnings being treated as errors scripts/Makefile.build:293: recipe for target 'drivers/gpu/drm/i915/intel_display.o' failed make[4]: *** [drivers/gpu/drm/i915/intel_display.o] Error 1 scripts/Makefile.build:551: recipe for target 'drivers/gpu/drm/i915' failed make[3]: *** [drivers/gpu/drm/i915] Error 2 scripts/Makefile.build:551: recipe for target 'drivers/gpu/drm' failed make[2]: *** [drivers/gpu/drm] Error 2 scripts/Makefile.build:551: recipe for target 'drivers/gpu' failed make[1]: *** [drivers/gpu] Error 2 Makefile:988: 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] [PATCH] drm/i915: Get correct display clock on 945gm
This is according to Mobile Intel® 945 Express Chipset
Family datasheet.
Signed-off-by: Arthur Heymans
---
drivers/gpu/drm/i915/i915_reg.h | 2 +-
drivers/gpu/drm/i915/intel_display.c | 27 +--
2 files changed, 26 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 02a65ddae3a3..f0b7849ace17 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -119,7 +119,7 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
#define GCFGC 0xf0 /* 915+ only */
#define GC_LOW_FREQUENCY_ENABLE (1 << 7)
#define GC_DISPLAY_CLOCK_190_200_MHZ (0 << 4)
-#define GC_DISPLAY_CLOCK_333_MHZ (4 << 4)
+#define GC_DISPLAY_CLOCK_333_320_MHZ (4 << 4)
#define GC_DISPLAY_CLOCK_267_MHZ_PNV (0 << 4)
#define GC_DISPLAY_CLOCK_333_MHZ_PNV (1 << 4)
#define GC_DISPLAY_CLOCK_444_MHZ_PNV (2 << 4)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index ac25706b7d4d..998920ab3ec8 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7407,6 +7407,26 @@ static int i945_get_display_clock_speed(struct
drm_i915_private *dev_priv)
return 40;
}
+static int i945gm_get_display_clock_speed(struct drm_i915_private *dev_priv)
+{
+ struct pci_dev *pdev = dev_priv->drm.pdev;
+ u16 gcfgc = 0;
+
+ pci_read_config_word(pdev, GCFGC, &gcfgc);
+
+ if (gcfgc & GC_LOW_FREQUENCY_ENABLE)
+ return 13;
+ else {
+ switch (gcfgc & GC_DISPLAY_CLOCK_MASK) {
+ case GC_DISPLAY_CLOCK_333_320_MHZ:
+ return 32;
+ default:
+ case GC_DISPLAY_CLOCK_190_200_MHZ:
+ return 20;
+ }
+ }
+}
+
static int i915_get_display_clock_speed(struct drm_i915_private *dev_priv)
{
return 33;
@@ -7453,7 +7473,7 @@ static int i915gm_get_display_clock_speed(struct
drm_i915_private *dev_priv)
return 13;
else {
switch (gcfgc & GC_DISPLAY_CLOCK_MASK) {
- case GC_DISPLAY_CLOCK_333_MHZ:
+ case GC_DISPLAY_CLOCK_333_320_MHZ:
return 33;
default:
case GC_DISPLAY_CLOCK_190_200_MHZ:
@@ -16244,9 +16264,12 @@ void intel_init_display_hooks(struct drm_i915_private
*dev_priv)
else if (IS_I915G(dev_priv))
dev_priv->display.get_display_clock_speed =
i915_get_display_clock_speed;
- else if (IS_I945GM(dev_priv) || IS_I845G(dev_priv))
+ else if (IS_I845G(dev_priv))
dev_priv->display.get_display_clock_speed =
i9xx_misc_get_display_clock_speed;
+ else if (IS_I945GM(dev_priv))
+ dev_priv->display.get_display_clock_speed =
+ i945gm_get_display_clock_speed;
else if (IS_I915GM(dev_priv))
dev_priv->display.get_display_clock_speed =
i915gm_get_display_clock_speed;
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Get correct display clock on 945gm
Hi Arthur, [auto build test ERROR on drm-intel/for-linux-next] [also build test ERROR on next-20170131] [cannot apply to v4.10-rc6] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Arthur-Heymans/drm-i915-Get-correct-display-clock-on-945gm/20170201-072757 base: git://anongit.freedesktop.org/drm-intel for-linux-next config: x86_64-rhel (attached as .config) compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 reproduce: # save the attached .config to linux build tree make ARCH=x86_64 All errors (new ones prefixed by >>): drivers/gpu/drm/i915/intel_display.c: In function 'intel_init_display_hooks': >> drivers/gpu/drm/i915/intel_display.c:16240:45: error: assignment from >> incompatible pointer type [-Werror=incompatible-pointer-types] dev_priv->display.get_display_clock_speed = ^ cc1: some warnings being treated as errors vim +16240 drivers/gpu/drm/i915/intel_display.c 34edce2f Ville Syrjälä 2015-05-22 16234 dev_priv->display.get_display_clock_speed = 34edce2f Ville Syrjälä 2015-05-22 16235 pnv_get_display_clock_speed; 88212941 Imre Deak 2016-03-16 16236 else if (IS_G33(dev_priv) || IS_G4X(dev_priv)) 34edce2f Ville Syrjälä 2015-05-22 16237 dev_priv->display.get_display_clock_speed = 34edce2f Ville Syrjälä 2015-05-22 16238 g33_get_display_clock_speed; 88212941 Imre Deak 2016-03-16 16239 else if (IS_I915G(dev_priv)) e70236a8 Jesse Barnes 2009-09-21 @16240 dev_priv->display.get_display_clock_speed = e70236a8 Jesse Barnes 2009-09-21 16241 i915_get_display_clock_speed; 52d2d756 Arthur Heymans 2017-02-01 16242 else if (IS_I845G(dev_priv)) e70236a8 Jesse Barnes 2009-09-21 16243 dev_priv->display.get_display_clock_speed = :: The code at line 16240 was first introduced by commit :: e70236a8d3d0a4c100a0b9f7d394d9bda9c56aca drm/i915: split display functions by chip type :: TO: Jesse Barnes :: CC: Eric Anholt --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Linux v4.10.0-rc1+] Still call-traces after suspend-resume (pm? i915? cpu/hotplug?)
On Mon, Jan 30, 2017 at 11:44 PM, Rafael J. Wysocki
wrote:
> On 1/24/2017 2:33 AM, Sedat Dilek wrote:
>>
>> On Fri, Dec 30, 2016 at 3:02 PM, Rafael J. Wysocki
>> wrote:
>>>
>>> On Fri, Dec 30, 2016 at 12:40 PM, Sedat Dilek
>>> wrote:
Hi,
I have already reported this issue in [1].
One of the issue was solved.
Unfortunately, it looks like there is still a different problem here
(Ubuntu/precise AMD64).
I tried v4.10-rc1 and latest Linus tree up to...
commit 98473f9f3f9bd404873cd1178c8be7d6d619f0d1
"mm/filemap: fix parameters to test_bit()"
Here we go...
[ 29.636047] BUG: sleeping function called from invalid context at
drivers/base/power/runtime.c:1032
[ 29.636055] in_atomic(): 1, irqs_disabled(): 0, pid: 1500, name: Xorg
[ 29.636058] 1 lock held by Xorg/1500:
[ 29.636060] #0: (&dev->struct_mutex){+.+.+.}, at:
[] i915_mutex_lock_interruptible+0x43/0x140 [i915]
[ 29.636107] CPU: 0 PID: 1500 Comm: Xorg Not tainted
4.10.0-rc1-6-iniza-amd64 #1
[ 29.636109] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
[ 29.636111] Call Trace:
[ 29.636120] dump_stack+0x85/0xc2
[ 29.636124] ___might_sleep+0x196/0x260
[ 29.636127] __might_sleep+0x53/0xb0
[ 29.636131] __pm_runtime_resume+0x7a/0x90
[ 29.636159] intel_runtime_pm_get+0x25/0x90 [i915]
[ 29.636189] aliasing_gtt_bind_vma+0xaa/0xf0 [i915]
[ 29.636220] i915_vma_bind+0xaf/0x1e0 [i915]
[ 29.636248] i915_gem_execbuffer_relocate_entry+0x513/0x6f0 [i915]
[ 29.636272] i915_gem_execbuffer_relocate_vma.isra.34+0x188/0x250
[i915]
[ 29.636275] ? trace_hardirqs_on+0xd/0x10
[ 29.636294] ? i915_gem_execbuffer_reserve_vma.isra.31+0x152/0x1f0
[i915]
[ 29.636316] ? i915_gem_execbuffer_reserve.isra.32+0x372/0x3a0 [i915]
[ 29.636342] i915_gem_do_execbuffer.isra.38+0xa70/0x1a40 [i915]
[ 29.636347] ? __might_fault+0x4e/0xb0
[ 29.636373] i915_gem_execbuffer2+0xc5/0x260 [i915]
[ 29.636376] ? __might_fault+0x4e/0xb0
[ 29.636395] drm_ioctl+0x206/0x450 [drm]
[ 29.636420] ? i915_gem_execbuffer+0x340/0x340 [i915]
[ 29.636425] ? __fget+0x5/0x200
[ 29.636429] do_vfs_ioctl+0x91/0x6f0
[ 29.636431] ? __fget+0x111/0x200
[ 29.636433] ? __fget+0x5/0x200
[ 29.636436] SyS_ioctl+0x79/0x90
[ 29.636441] entry_SYSCALL_64_fastpath+0x23/0xc6
On suspend/resume I see the same call trace.
[2] points to the "BUG" line.
>>>
>>> Well, this appears to be an i915 issue, but not a serious one.
>>>
>>> Clearly, a function that may sleep (pm_runtime_get_sync() in
>>> intel_runtime_pm_get()) is called with disabled interrupts. If I
>>> understand the code correctly, though, it actually is not going to
>>> sleep in this particular case, because pm_runtime_get_sync() has
>>> already been called once for this device in the same code path which
>>> means that this particular instance will return immediately, so this
>>> is a false-positive (most likely).
>>>
>>> Let me see if I the might_sleep_if() assertion in
>>> __pm_runtime_resume(() can be moved to a better place.
>>>
>> Hi Rafael,
>>
>> did you had a chance to look at this?
>> The problem still remains in Linux v4.10-rc5.
>
>
> No, I didn't.
>
> As I said, this is not a serious issue.
Something like the attached (untested).
Please try it and let me know if it makes the splat go away.
Thanks,
Rafael
---
drivers/base/power/runtime.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
Index: linux-pm/drivers/base/power/runtime.c
===
--- linux-pm.orig/drivers/base/power/runtime.c
+++ linux-pm/drivers/base/power/runtime.c
@@ -966,13 +966,13 @@ int __pm_runtime_idle(struct device *dev
unsigned long flags;
int retval;
- might_sleep_if(!(rpmflags & RPM_ASYNC) && !dev->power.irq_safe);
-
if (rpmflags & RPM_GET_PUT) {
if (!atomic_dec_and_test(&dev->power.usage_count))
return 0;
}
+ might_sleep_if(!(rpmflags & RPM_ASYNC) && !dev->power.irq_safe);
+
spin_lock_irqsave(&dev->power.lock, flags);
retval = rpm_idle(dev, rpmflags);
spin_unlock_irqrestore(&dev->power.lock, flags);
@@ -998,13 +998,13 @@ int __pm_runtime_suspend(struct device *
unsigned long flags;
int retval;
- might_sleep_if(!(rpmflags & RPM_ASYNC) && !dev->power.irq_safe);
-
if (rpmflags & RPM_GET_PUT) {
if (!atomic_dec_and_test(&dev->power.usage_count))
return 0;
}
+ might_sleep_if(!(rpmflags & RPM_ASYNC) && !dev->power.irq_safe);
+
spin_lock_irqsave(&dev->power.lock, flags);
retval = rpm_suspend(dev, rpmflags);
spin_unlock_irqrestore(&dev->power.lock, flags);
@@ -1029,7 +1029,8 @@ int __pm_runtime_resume(struct device *d
unsigned long flags;
int retval;
- migh
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Get correct display clock on 945gm (rev3)
== Series Details == Series: drm/i915: Get correct display clock on 945gm (rev3) URL : https://patchwork.freedesktop.org/series/18693/ State : success == Summary == Series 18693v3 drm/i915: Get correct display clock on 945gm https://patchwork.freedesktop.org/api/1.0/series/18693/revisions/3/mbox/ fi-bdw-5557u total:247 pass:233 dwarn:0 dfail:0 fail:0 skip:14 fi-bsw-n3050 total:247 pass:208 dwarn:0 dfail:0 fail:0 skip:39 fi-bxt-j4205 total:247 pass:225 dwarn:0 dfail:0 fail:0 skip:22 fi-bxt-t5700 total:78 pass:65 dwarn:0 dfail:0 fail:0 skip:12 fi-byt-j1900 total:247 pass:220 dwarn:0 dfail:0 fail:0 skip:27 fi-byt-n2820 total:247 pass:216 dwarn:0 dfail:0 fail:0 skip:31 fi-hsw-4770 total:247 pass:228 dwarn:0 dfail:0 fail:0 skip:19 fi-hsw-4770r total:247 pass:228 dwarn:0 dfail:0 fail:0 skip:19 fi-ivb-3520m total:247 pass:226 dwarn:0 dfail:0 fail:0 skip:21 fi-ivb-3770 total:247 pass:226 dwarn:0 dfail:0 fail:0 skip:21 fi-kbl-7500u total:247 pass:224 dwarn:0 dfail:0 fail:2 skip:21 fi-skl-6260u total:247 pass:234 dwarn:0 dfail:0 fail:0 skip:13 fi-skl-6700hqtotal:247 pass:227 dwarn:0 dfail:0 fail:0 skip:20 fi-skl-6700k total:247 pass:222 dwarn:4 dfail:0 fail:0 skip:21 fi-skl-6770hqtotal:247 pass:234 dwarn:0 dfail:0 fail:0 skip:13 fi-snb-2520m total:247 pass:216 dwarn:0 dfail:0 fail:0 skip:31 fi-snb-2600 total:247 pass:215 dwarn:0 dfail:0 fail:0 skip:32 83f390eaec64a1b0566f5f747d20741c077fcff5 drm-tip: 2017y-01m-31d-20h-19m-59s UTC integration manifest a784911 drm/i915: Get correct display clock on 945gm == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3658/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: Don't race connector registration
I added some printk()s all over and gathered a bit more information about what's going on. It looks like the display doesn't work until the drm connector code cleans up the *old* connector. For some reason, it isn't motivated to do that until I go to the console and back. In this case, the display was connected to DP-4. intel_dp_destroy_mst_connector() got called on it when I switched away, but drm_connector_cleanup() did not get called. Upon switching back DP-3/5/6 get created. One of these *eventually* ends up being "enabled", but is not now. When I switch over to the console, drm_connector_cleanup() finally gets called on the old connector: DP-4 and I can switch back to X and I see one of DP-3/5/6 enabled and working. Here are some snippets of dmesg interspersed with what I was doing: Push DVI switch button to switch to other system: > [ 6824.562838] drm_dp_destroy_port() kfree(8801ade46800) > [ 6824.563164] drm_dp_destroy_connector_work() port: 8801ade42000 > connector: 8801ade46000 > [ 6824.563178] intel_dp_destroy_mst_connector() connector: 8801ade46000 > name: DP-3 &name: 8801ade46048 intel_connector: 8801ade46000 > [ 6824.563186] drm_sysfs_connector_remove() connector: 8801ade46000 kdev: > 8801a941b400 > [ 6824.571556] drm_connector_cleanup(8801ade46000)::329 > connector->registered: 0 cpu: 3 > [ 6824.571570] drm_connector_cleanup() kfree() connector->name: 'DP-3' &name: > 8801ade46048 > [ 6824.571581] drm_dp_free_mst_port() kfree port: 8801ade42000 > [ 6824.571587] drm_dp_destroy_connector_work() port: 8801ade42800 > connector: 8801ade47000 > [ 6824.571594] intel_dp_destroy_mst_connector() connector: 8801ade47000 > name: DP-4 &name: 8801ade47048 intel_connector: 8801ade47000 > [ 6824.571601] drm_sysfs_connector_remove() connector: 8801ade47000 kdev: > 8801a941a000 > [ 6824.571915] drm_dp_free_mst_port() kfree port: 8801ade42800 > [ 6824.571925] drm_dp_destroy_connector_work() port: 8801ade40800 > connector: 8801ade43000 > [ 6824.571934] intel_dp_destroy_mst_connector() connector: 8801ade43000 > name: DP-6 &name: 8801ade43048 intel_connector: 8801ade43000 > [ 6824.571943] drm_sysfs_connector_remove() connector: 8801ade43000 kdev: > 8801a9419800 > [ 6824.572091] drm_connector_cleanup(8801ade43000)::329 > connector->registered: 0 cpu: 3 > [ 6824.572101] drm_connector_cleanup() kfree() connector->name: 'DP-6' &name: > 8801ade43048 > [ 6824.572110] drm_dp_free_mst_branch_device() kfree mstb: 88030ac22600 > [ 6824.572117] drm_dp_free_mst_port() kfree port: 8801ade40800 Push button to switch back: > [ 6837.349693] drm_connector_init() connector->name: 'DP-3' &name: > 88040231d848 > [ 6837.349894] drm_sysfs_connector_add() connector: 88040231d800 kdev: > 8801ae99f400 > [ 6837.352786] drm_connector_init() connector->name: 'DP-5' &name: > 880402318048 > [ 6837.352951] drm_sysfs_connector_add() connector: 880402318000 kdev: > 8801ae99c000 > [ 6837.353036] drm_connector_init() connector->name: 'DP-6' &name: > 88040d37f048 > [ 6837.353154] drm_sysfs_connector_add() connector: 88040d37f000 kdev: > 8801ae99ec00 I can type into the X session, but both screens are blank. When I press Ctrl-Alt-F2, I get: > [ 6850.494310] drm_connector_cleanup(8801ade47000)::329 > connector->registered: 0 cpu: 1 > [ 6850.494314] drm_connector_cleanup() kfree() connector->name: 'DP-4' &name: > 8801ade47048 Now I can switch back to X and everything is OK again. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t v3 10/11] tests/kms_atomic_transition: add out_fences tests
On 2017-01-31 11:52 AM, Brian Starkey wrote:
On Mon, Jan 30, 2017 at 08:58:46PM -0500, Robert Foss wrote:
Signed-off-by: Gustavo Padovan
Signed-off-by: Robert Foss
---
lib/igt_kms.c | 35 ++
tests/kms_atomic_transition.c | 148
++
2 files changed, 169 insertions(+), 14 deletions(-)
diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index f14496dd..523f3f57 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -53,6 +53,7 @@
#include "intel_chipset.h"
#include "igt_debugfs.h"
#include "igt_sysfs.h"
+#include "sw_sync.h"
/**
* SECTION:igt_kms
@@ -2479,6 +2480,21 @@ static int igt_atomic_commit(igt_display_t
*display, uint32_t flags, void *user_
}
ret = drmModeAtomicCommit(display->drm_fd, req, flags, user_data);
+if (!ret) {
+
+for_each_pipe(display, pipe) {
+igt_pipe_t *pipe_obj = &display->pipes[pipe];
+
+if (pipe_obj->out_fence != -1)
+continue;
Should be "if (pipe_obj->fence == -1)" ? The stuff below seems to be
assuming the fence is valid.
Correct, fixed in v4.
+
+igt_assert(pipe_obj->out_fence >= 0);
+ret = sync_fence_wait(pipe_obj->out_fence, 1000);
+igt_assert(ret == 0);
+close(pipe_obj->out_fence);
+}
+}
+
drmModeAtomicFree(req);
return ret;
@@ -2972,6 +2988,11 @@ void igt_plane_set_rotation(igt_plane_t *plane,
igt_rotation_t rotation)
plane->rotation_changed = true;
}
+void igt_pipe_request_out_fence(igt_pipe_t *pipe)
Oh here it is!
+{
+pipe->out_fence_requested = true;
+}
+
void
igt_pipe_set_degamma_lut(igt_pipe_t *pipe, void *ptr, size_t length)
{
@@ -2994,20 +3015,6 @@ igt_pipe_set_gamma_lut(igt_pipe_t *pipe, void
*ptr, size_t length)
}
/**
- * igt_pipe_set_out_fence_ptr:
- * @pipe: pipe pointer to which background color to be set
- * @fence_ptr: out fence pointer
- *
- * Sets the out fence pointer that will be passed to the kernel in
- * the atomic ioctl. When the kernel returns the out fence pointer
- * will contain the fd number of the out fence created by KMS.
- */
-void igt_pipe_set_out_fence_ptr(igt_pipe_t *pipe, int64_t *fence_ptr)
... and there this one goes. This deletion and the function above
need to be squashed into the earlier commit I suppose.
Ack, fixed in v4.
-{
-pipe->out_fence_ptr = fence_ptr;
-}
-
-/**
* igt_crtc_set_background:
* @pipe: pipe pointer to which background color to be set
* @background: background color value in BGR 16bpc
diff --git a/tests/kms_atomic_transition.c
b/tests/kms_atomic_transition.c
index 72429759..eebb5d66 100644
--- a/tests/kms_atomic_transition.c
+++ b/tests/kms_atomic_transition.c
@@ -253,6 +253,93 @@ retry:
sprite_width, sprite_height, alpha);
}
+int *timeline;
+pthread_t *thread;
+int *seqno;
+
+static void prepare_fencing(igt_display_t *display, enum pipe pipe)
+{
+igt_plane_t *plane;
+int n_planes;
+
+igt_require_sw_sync();
+
+n_planes = display->pipes[pipe].n_planes;
+timeline = calloc(sizeof(*timeline), n_planes);
+igt_assert_f(timeline != NULL, "Failed to allocate memory for
timelines\n");
+thread = calloc(sizeof(*thread), n_planes);
+igt_assert_f(thread != NULL, "Failed to allocate memory for
thread\n");
+seqno = calloc(sizeof(*seqno), n_planes);
+igt_assert_f(seqno != NULL, "Failed to allocate memory for
seqno\n");
The 6 lines above are space-indented
Ack, fixed in v4.
+
+for_each_plane_on_pipe(display, pipe, plane)
+timeline[plane->index] = sw_sync_timeline_create();
+}
+
+static void unprepare_fencing(igt_display_t *display, enum pipe pipe)
+{
+igt_plane_t *plane;
+
+for_each_plane_on_pipe(display, pipe, plane)
+close(timeline[plane->index]);
+
+free(timeline);
+free(thread);
+free(seqno);
+}
+
+static void *fence_inc_thread(void *arg)
+{
+int t = *((int *) arg);
+
+pthread_detach(pthread_self());
+
+usleep(5000);
+sw_sync_timeline_inc(t, 1);
+return NULL;
+}
+
+static void configure_fencing(igt_display_t *display, enum pipe pipe)
+{
+igt_plane_t *plane;
+int i, fd, ret;
+
+for_each_plane_on_pipe(display, pipe, plane) {
+
+if (!plane->fb)
+continue;
+
+i = plane->index;
+
+seqno[i]++;
+fd = sw_sync_timeline_create_fence(timeline[i], seqno[i]);
+igt_plane_set_fence_fd(plane, fd);
+ret = pthread_create(&thread[i], NULL, fence_inc_thread,
&timeline[i]);
+igt_assert_eq(ret, 0);
+}
+}
+
+static void clear_fencing(igt_display_t *display, enum pipe pipe)
+{
+igt_plane_t *plane;
+
+for_each_plane_on_pipe(display, pipe, plane)
+igt_plane_set_fence_fd(plane, -1);
Someone should close the old fence_fd if it's not -1.
I think igt_plane_set_fence_fd() should dup() the passed in fence, and
igt_display_atomic_commit() should set it to -1 after the commit.
That makes it very obvious, and t
[Intel-gfx] ✓ Fi.CI.BAT: success for Still call-traces after suspend-resume (pm? i915? cpu/hotplug?)
== Series Details == Series: Still call-traces after suspend-resume (pm? i915? cpu/hotplug?) URL : https://patchwork.freedesktop.org/series/18871/ State : success == Summary == Series 18871v1 Still call-traces after suspend-resume (pm? i915? cpu/hotplug?) https://patchwork.freedesktop.org/api/1.0/series/18871/revisions/1/mbox/ fi-bdw-5557u total:247 pass:233 dwarn:0 dfail:0 fail:0 skip:14 fi-bsw-n3050 total:247 pass:208 dwarn:0 dfail:0 fail:0 skip:39 fi-bxt-j4205 total:247 pass:225 dwarn:0 dfail:0 fail:0 skip:22 fi-bxt-t5700 total:78 pass:65 dwarn:0 dfail:0 fail:0 skip:12 fi-byt-j1900 total:247 pass:220 dwarn:0 dfail:0 fail:0 skip:27 fi-byt-n2820 total:247 pass:216 dwarn:0 dfail:0 fail:0 skip:31 fi-hsw-4770 total:247 pass:228 dwarn:0 dfail:0 fail:0 skip:19 fi-hsw-4770r total:247 pass:228 dwarn:0 dfail:0 fail:0 skip:19 fi-ivb-3520m total:247 pass:226 dwarn:0 dfail:0 fail:0 skip:21 fi-ivb-3770 total:247 pass:226 dwarn:0 dfail:0 fail:0 skip:21 fi-kbl-7500u total:247 pass:224 dwarn:0 dfail:0 fail:2 skip:21 fi-skl-6260u total:247 pass:234 dwarn:0 dfail:0 fail:0 skip:13 fi-skl-6700hqtotal:247 pass:227 dwarn:0 dfail:0 fail:0 skip:20 fi-skl-6700k total:247 pass:222 dwarn:4 dfail:0 fail:0 skip:21 fi-skl-6770hqtotal:247 pass:234 dwarn:0 dfail:0 fail:0 skip:13 fi-snb-2520m total:247 pass:216 dwarn:0 dfail:0 fail:0 skip:31 fi-snb-2600 total:247 pass:215 dwarn:0 dfail:0 fail:0 skip:32 83f390eaec64a1b0566f5f747d20741c077fcff5 drm-tip: 2017y-01m-31d-20h-19m-59s UTC integration manifest 9beee45 Still call-traces after suspend-resume (pm? i915? cpu/hotplug?) == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3659/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
