== Series Details ==
Series: series starting with [1/4] kms_content_protection: Fix log bug on
32-bit platforms.
URL : https://patchwork.freedesktop.org/series/52505/
State : failure
== Summary ==
= CI Bug Log - changes from IGT_4714_full -> IGTPW_2062_full =
== Summary - FAILURE ==
Serio
== Series Details ==
Series: drm/i915: Program SKL+ watermarks/ddb more carefully (rev7)
URL : https://patchwork.freedesktop.org/series/51878/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_5140_full -> Patchwork_10827_full =
== Summary - FAILURE ==
Serious unknown change
== Series Details ==
Series: drm/i915: Disable LP3 watermarks on all SNB machines (rev2)
URL : https://patchwork.freedesktop.org/series/52440/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_5140_full -> Patchwork_10826_full =
== Summary - WARNING ==
Minor unknown changes
On Wed, Nov 14, 2018 at 11:17:25AM -0500, Sean Paul wrote:
> On Tue, Nov 13, 2018 at 03:21:48PM -0800, Matt Roper wrote:
> > Some display controllers can be programmed to present non-black colors
> > for pixels not covered by any plane (or pixels covered by the
> > transparent regions of higher pla
== Series Details ==
Series: series starting with [1/4] kms_content_protection: Fix log bug on
32-bit platforms.
URL : https://patchwork.freedesktop.org/series/52505/
State : success
== Summary ==
= CI Bug Log - changes from IGT_4714 -> IGTPW_2062 =
== Summary - WARNING ==
Minor unknown c
Just a few little ioctl wrappers that v3d tests will use.
Signed-off-by: Eric Anholt
---
lib/Makefile.sources | 2 +
lib/drmtest.c| 3 +
lib/drmtest.h| 1 +
lib/igt_v3d.c| 130 +++
lib/igt_v3d.h| 46 +++
l
These are basic non-rendering tests of the UABI.
Signed-off-by: Eric Anholt
---
lib/igt_v3d.c | 4 --
tests/Makefile.am | 2 +
tests/Makefile.sources| 6 +++
tests/meson.build | 3 ++
tests/v3d_ci/README | 26 +
tests/v3d_ci/v3d.testlist | 6
long is different between 32 and 64 and should basically never be
used. Fixes compiler warning about passing the wrong type.
Signed-off-by: Eric Anholt
---
tests/kms_content_protection.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tests/kms_content_protection.c b/tests
Copied from make headers_install at drm-misc-next 783195ec1cad
("drm/syncobj: disable the timeline UAPI for now v2")
Signed-off-by: Eric Anholt
---
include/drm-uapi/v3d_drm.h | 204 +
1 file changed, 204 insertions(+)
create mode 100644 include/drm-uapi/v3d_d
== Series Details ==
Series: drm/i915: Program SKL+ watermarks/ddb more carefully (rev7)
URL : https://patchwork.freedesktop.org/series/51878/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_5140 -> Patchwork_10827 =
== Summary - SUCCESS ==
No regressions found.
Externa
== Series Details ==
Series: drm/i915: Program SKL+ watermarks/ddb more carefully (rev7)
URL : https://patchwork.freedesktop.org/series/51878/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Reorganize plane register writes to make them more a
== Series Details ==
Series: drm/i915: Program SKL+ watermarks/ddb more carefully (rev7)
URL : https://patchwork.freedesktop.org/series/51878/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
5a11dbcbd5cb drm/i915: Reorganize plane register writes to make them more atomic
eb3c2f39
From: Ville Syrjälä
skl+ can go belly up if there are overlapping ddb allocations between
planes. If we could absolutely guarantee that we can perform the atomic
update within a single frame we shouldn't have to worry about this. But
we can't rely on that so let's steal the ddb overlap check tric
From: Ville Syrjälä
We memset(0) the entire watermark struct the start, so there's no
need to clear things later on.
v2: Rebase due to some stale w/a removal
Reviewed-by: Rodrigo Vivi
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 16
1 file changed, 4 in
From: Ville Syrjälä
On icl+ the plane state that gets passed to update_slave() is not
the plane state of the plane we're programming. With NV12 the
plane state would be coming from the master (UV) plane whereas
the plane we're programming is the slave (Y) plane. For that reason
we need to explici
From: Ville Syrjälä
Simplify the calling convention of the skl+ watermark functions
by not passing around dev_priv needlessly. The callees have
what they need to dig it out anyway.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 27 +--
1 file changed
From: Ville Syrjälä
We have to pass both level 0 watermark struct and the transition
watermark struct to skl_compute_transition_wm(). Make life less
confusing by just passing the entire plane watermark struct that
contains both aforementioned structures.
Cc: Matt Roper
Signed-off-by: Ville Syrj
From: Ville Syrjälä
A variable whose name is 'plane_id' is expected to be of the
enum plane_id type. In this case we have a raw int, which turns
out to refer to the plane of the framebuffer. Rename the variable
to 'color_plane' in line with the trend started earlier.
Signed-off-by: Ville Syrjälä
From: Ville Syrjälä
If the level 0 latency is 0 we can't do anything. Return an error
rather than success.
While this can't happen due to WaWmMemoryReadLatency, it can
happen if the user clears out the level 0 latency via debugfs.
v2: Clarify how how we can end here with zero level 0 latency (M
From: Ville Syrjälä
The plane color correction registers are single buffered. So
ideally we would write them at the start of vblank just after the
double buffered plane registers have been latched. Since we have
no convenient way to do that for now let's at least move the
single buffered register
From: Ville Syrjälä
On SKL+ the plane WM/BUF_CFG registers are a proper part of each
plane's register set. That means accessing them will cancel any
pending plane update, and we would need a PLANE_SURF register write
to arm the wm/ddb change as well.
To avoid all the problems with that let's jus
From: Ville Syrjälä
Make a cleaner split between the skl+ and icl+ ways of computing
watermarks. This way skl_build_pipe_wm() doesn't have to know any
of the gritty details of icl+ master/slave planes.
We can also simplify a bunch of the lower level code by pulling
the plane visibility checks a
From: Ville Syrjälä
We're going to need access to the new crtc state in ->disable_plane()
for SKL+ wm/ddb programming and pre-skl pipe gamma/csc control. Pass
the crtc state down.
We'll also try to make intel_crtc_disable_planes() do the right
thing as much as it's possible. The fact that we don
From: Ville Syrjälä
Keep track which planes need updating during the commit. For now this
is just (was_visible || is_visible) but I'll have need to update
invisible planes later on for skl plane ddbs and for pre-skl pipe
gamma/csc control (which lives in the primary plane control register).
Revi
From: Ville Syrjälä
Here's the remainder of the skl+ ddb/wm programming series. I tried to
split up the ugly monster patch into a few chunks, and I tossed in
a few extra nuggets on top. I also tried to improve the commit
messages a bit based on the previous review feedback.
Entire series availab
From: Ville Syrjälä
Some observations about the plane registers:
- the control register will self-arm if the plane is not already
enabled, thus we want to write it as close to (or ideally after)
the surface register
- tileoff/linoff/offset/aux_offset are self-arming as well so we want
them
== Series Details ==
Series: drm/i915: use appropriate integer types for flags
URL : https://patchwork.freedesktop.org/series/52481/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_5138_full -> Patchwork_10824_full =
== Summary - WARNING ==
Minor unknown changes coming wit
Hi Dave,
Hope you're having a good time in Vancouver, sorry I missed y'all!
A bit more activity this week in -fixes, and that's all due to omap. We've
got some initialization fixes, the most notable is migrating dss child
instantiation from mach-* to the omapdss driver.
Please pull at your conve
== Series Details ==
Series: drm/i915: Disable LP3 watermarks on all SNB machines (rev2)
URL : https://patchwork.freedesktop.org/series/52440/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_5140 -> Patchwork_10826 =
== Summary - SUCCESS ==
No regressions found.
Externa
On Tue, Nov 13, 2018 at 03:21:49PM -0800, Matt Roper wrote:
> Gen9+ platforms allow CRTC's to be programmed with a background/canvas
> color below the programmable planes. Let's expose this for use by
> compositors.
>
> v2:
> - Split out bgcolor sanitization and programming of csc/gamma bits to
On Wed, Nov 14, 2018 at 09:36:39AM -0800, Matt Roper wrote:
> On Wed, Nov 14, 2018 at 07:28:12PM +0200, Ville Syrjälä wrote:
> > On Tue, Nov 13, 2018 at 03:21:47PM -0800, Matt Roper wrote:
> > > We don't yet allow userspace to control the CRTC background color, but
> > > we should manually program
On Wed, Nov 14, 2018 at 07:28:12PM +0200, Ville Syrjälä wrote:
> On Tue, Nov 13, 2018 at 03:21:47PM -0800, Matt Roper wrote:
> > We don't yet allow userspace to control the CRTC background color, but
> > we should manually program the color to black to ensure the BIOS didn't
> > leave us with some
From: Ville Syrjälä
I have a Thinkpad X220 Tablet in my hands that is losing vblank
interrupts whenever LP3 watermarks are used.
If I nudge the latency value written to the WM3 register just
by one in either direction the problem disappears. That to me
suggests that the punit will not enter the
On Wed, Nov 14, 2018 at 07:20:36PM +0200, Ville Syrjälä wrote:
> On Tue, Nov 13, 2018 at 03:21:48PM -0800, Matt Roper wrote:
...
> >
> > +/*
> > + * Put RGBA values into a standard 64-bit representation that can be used
> > + * for ioctl parameters, inter-driver commmunication, etc. If the
> >
On Tue, Nov 13, 2018 at 03:21:47PM -0800, Matt Roper wrote:
> We don't yet allow userspace to control the CRTC background color, but
> we should manually program the color to black to ensure the BIOS didn't
> leave us with some other color. We should also set the pipe gamma and
> pipe CSC bits so
== Series Details ==
Series: series starting with [v2,1/2] drm/i915/icl: replace check for combo phy
(rev2)
URL : https://patchwork.freedesktop.org/series/52400/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_5133_full -> Patchwork_10818_full =
== Summary - WARNING ==
Mi
On Tue, Nov 13, 2018 at 03:21:48PM -0800, Matt Roper wrote:
> Some display controllers can be programmed to present non-black colors
> for pixels not covered by any plane (or pixels covered by the
> transparent regions of higher planes). Compositors that want a UI with
> a solid color background c
Quoting Ville Syrjälä (2018-11-13 18:40:20)
> On Tue, Nov 13, 2018 at 06:25:47PM +, Chris Wilson wrote:
> > Quoting Ville Syrjala (2018-11-13 18:10:23)
> > > From: Ville Syrjälä
> > >
> > > I have a Thinkpad X220 Tablet in my hands that is losing vblank
> > > interrupts whenever LP3 watermark
== Series Details ==
Series: drm/i915: Disable LP3 watermarks on all SNB machines
URL : https://patchwork.freedesktop.org/series/52440/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_5133_full -> Patchwork_10817_full =
== Summary - WARNING ==
Minor unknown changes coming
== Series Details ==
Series: series starting with [1/3] drm/i915: Use explicit old crtc state in
skl_compute_wm()
URL : https://patchwork.freedesktop.org/series/52436/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_5133_full -> Patchwork_10816_full =
== Summary - WARNING ==
On Tue, Nov 13, 2018 at 03:21:48PM -0800, Matt Roper wrote:
> Some display controllers can be programmed to present non-black colors
> for pixels not covered by any plane (or pixels covered by the
> transparent regions of higher planes). Compositors that want a UI with
> a solid color background c
== Series Details ==
Series: drm/i915: remove excess line continuation backslashes
URL : https://patchwork.freedesktop.org/series/52477/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_5139 -> Patchwork_10825 =
== Summary - WARNING ==
Minor unknown changes coming with Patc
== Series Details ==
Series: drm/i915: use appropriate integer types for flags
URL : https://patchwork.freedesktop.org/series/52481/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_5138 -> Patchwork_10824 =
== Summary - SUCCESS ==
No regressions found.
External URL:
ht
== Series Details ==
Series: drm/i915: remove excess line continuation backslashes
URL : https://patchwork.freedesktop.org/series/52477/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_5138 -> Patchwork_10823 =
== Summary - FAILURE ==
Serious unknown changes coming with Pa
>-Original Message-
>From: Roper, Matthew D
>Sent: Wednesday, November 14, 2018 6:39 AM
>To: Shankar, Uma
>Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>dcasta...@chromium.org; alexandru-cosmin.gheor...@arm.com;
>seanp...@chromium.org; Syrjala, Ville ;
>harry.wen
From: Ville Syrjälä
To get the initial phase correct we need to account for the scale
factor as well. I forgot this initially and was mostly looking at
heavily upscaled content where the minor difference between -0.5
and the proper initial phase was not readily apparent.
And let's toss in a comm
On Wed, Nov 14, 2018 at 01:49:25PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> To get the initial phase correct we need to account for the scale
> factor as well. I forgot this initially and was mostly looking at
> heavily upscaled content where the minor difference between -0.5
> and t
On Wed, Nov 14, 2018 at 12:08:06PM +, Lionel Landwerlin wrote:
> We've been dealing a number of 32/64 bits flags issues lately :
>
> - 085603287452fc ("drm/i915: Compare user's 64b GTT offset even on 32b")
> - c58281056a8b26 ("drm/i915: Mark up GTT sizes as u64")
> - 83b466b1dc5f0b ("drm/i9
== Series Details ==
Series: drm/i915: use appropriate integer types for flags
URL : https://patchwork.freedesktop.org/series/52481/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
04bef9eefcf0 drm/i915: use appropriate integer types for flags
-:8: ERROR:GIT_COMMIT_ID: Please use
Quoting Lionel Landwerlin (2018-11-14 12:08:06)
> We've been dealing a number of 32/64 bits flags issues lately :
>
> - 085603287452fc ("drm/i915: Compare user's 64b GTT offset even on 32b")
> - c58281056a8b26 ("drm/i915: Mark up GTT sizes as u64")
> - 83b466b1dc5f0b ("drm/i915: Mark pin flags
We've been dealing a number of 32/64 bits flags issues lately :
- 085603287452fc ("drm/i915: Compare user's 64b GTT offset even on 32b")
- c58281056a8b26 ("drm/i915: Mark up GTT sizes as u64")
- 83b466b1dc5f0b ("drm/i915: Mark pin flags as u64")
As userspace and in particular Mesa pulls in the
On Sat, Nov 10, 2018 at 12:57:13AM +, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [1/3] drm/i915/gen9_bc: Work around DMC bug
> zeroing power well requests
> URL : https://patchwork.freedesktop.org/series/52302/
> State : success
Pushed to -dinq, thanks for the
Reminds me that we should probably update the uAPI...
struct drm_i915_gem_exec_object2 has a u64 flags and all the
EXEC_OBJECT_* flags are (1<
-
Lionel
On 25/10/2018 10:18, Chris Wilson wrote:
Beware mixing unsigned long constants and 64b values, as on 32b the
constant will be zero extended a
From: Maarten Lankhorst
This cleans the code up slightly, and will make other changes easier.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Matt Roper
Link:
https://patchwork.freedesktop.org/patch/msgid/20180920102711.4184-8-maarten.lankho...@linux.intel.com
(cherry picked from commit ab5c60b
From: Ville Syrjälä
To get the initial phase correct we need to account for the scale
factor as well. I forgot this initially and was mostly looking at
heavily upscaled content where the minor difference between -0.5
and the proper initial phase was not readily apparent.
And let's toss in a comm
From: Ville Syrjälä
Remove the "sizes are 0 based" stuff that is not even true for the
scaler.
v2: Rebase
Signed-off-by: Ville Syrjälä
Link:
https://patchwork.freedesktop.org/patch/msgid/20181101151736.20522-1-ville.syrj...@linux.intel.com
Reviewed-by: Rodrigo Vivi
(cherry picked from commit
On Wed, 14 Nov 2018, Ville Syrjälä wrote:
> On Wed, Nov 14, 2018 at 01:21:30PM +0200, Jani Nikula wrote:
>> While removing .palette_offsets, I removed the commas after
>> .trans_offsets in the macros, but failed to remove the line continuation
>> backslashes.
>>
>> While at it, also remove anothe
On Mon, Nov 12, 2018 at 07:19:44PM +0200, Ville Syrjälä wrote:
> On Fri, Nov 09, 2018 at 04:58:22PM +0200, Imre Deak wrote:
> > Even though PW#1 and the MISC_IO power wells are managed by the
> > DMC firmware (toggled dynamically if conditions allow it) from the
> > driver's POV they are always on
On Wed, Nov 14, 2018 at 01:21:30PM +0200, Jani Nikula wrote:
> While removing .palette_offsets, I removed the commas after
> .trans_offsets in the macros, but failed to remove the line continuation
> backslashes.
>
> While at it, also remove another extra comma to be in line with the
> other relat
Quoting Joonas Lahtinen (2018-11-12 14:49:14)
> The following patches with Fixes: do not cleanly apply
> to drm-intel-fixes:
>
> - 5a3aeca97af1 ("drm/i915: Fix hpd handling for pins with two encoders")
One more:
- e7a278a329dd ("drm/i915: Account for scale factor when calculating initial
phase"
While removing .palette_offsets, I removed the commas after
.trans_offsets in the macros, but failed to remove the line continuation
backslashes.
While at it, also remove another extra comma to be in line with the
other related macros.
Fixes: 74c1e826427a ("drm/i915: remove palette_offsets from d
On Fri, Nov 09, 2018 at 04:44:54PM +0200, Mika Kuoppala wrote:
> Skip the hardware dbuf slice update if we don't have active
> pipes. With no active pipes, we don't have powerwell and thus
> programming the dbuf slice counts leads to accessing
> hardware without runtime pm ref.
>
> v2: bugzilla ta
On Wed, Nov 14, 2018 at 08:19:26AM +, Lisovskiy, Stanislav wrote:
> On Tue, 2018-11-13 at 16:40 +, Chris Wilson wrote:
> > Quoting Stanislav Lisovskiy (2018-11-13 14:31:38)
> > > Currently whenever we attempt to recalculate
> > > watermarks, we assign dirty_pipes to zero,
> > > then compare
Chris Wilson writes:
> Quoting Mika Kuoppala (2018-11-09 14:53:33)
>> Align icl workarounds whitespace with the rest of the file
>>
>> Cc: Chris Wilson
>> Signed-off-by: Mika Kuoppala
>
> That'll do. Fine piece of Wensleydale,
> Reviewed-by: Chris Wilson
Both patches pushed, thanks for revie
Imre Deak writes:
> On Fri, Nov 09, 2018 at 04:09:23PM +0200, Mika Kuoppala wrote:
>> Register DBUF_CTL_S2 is read and it's value is not used. As
>> there is no explanation why we should prime the hardware with
>> read, remove it as spurious.
>>
>> Fixes: aa9664ffe863 ("drm/i915/icl: Enable 2nd
On Tue, 2018-11-13 at 16:40 +, Chris Wilson wrote:
> Quoting Stanislav Lisovskiy (2018-11-13 14:31:38)
> > Currently whenever we attempt to recalculate
> > watermarks, we assign dirty_pipes to zero,
> > then compare current wm results to the recalculated
> > one and if they changed we set corre
On Tue, 13 Nov 2018, Lucas De Marchi wrote:
> Do like it's done for list.h macros, and use "reverse" suffix rather
> than "rev".
>
> Signed-off-by: Lucas De Marchi
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_display.h| 6 +++---
> drivers/gpu/drm/i915/intel_runtime_pm.c |
On Tue, 13 Nov 2018, Lucas De Marchi wrote:
> Bspec 21257 says "DDIA PHY is the comp master, so it must
> not be un-initialized if other combo PHYs are in use". Here
> we are shutting down all phys, so it's not strictly required.
> However let's be consistent on deinitializing things in the
> reve
On Tue, 13 Nov 2018, Lucas De Marchi wrote:
> These are the only places that assume ports A and B are the ones with
> combo phy. Let's use intel_port_is_combophy() there to make sure
> it checks for combo phy ports the same way everywhere.
>
> v2: define for_each_combo_port() helper to check the
69 matches
Mail list logo
