On 07.02.2020 16:39, Alexey Budankov wrote:
>
> On 07.02.2020 14:38, Thomas Gleixner wrote:
>> Alexey Budankov writes:
>>> On 22.01.2020 17:25, Alexey Budankov wrote:
On 22.01.2020 17:07, Stephen Smalley wrote:
>> It keeps the implementation simple and readable. The implementation is
On Thu, Feb 20, 2020 at 01:21:03PM +, Emil Velikov wrote:
> On Wed, 19 Feb 2020 at 20:35, Ville Syrjala
> wrote:
> >
> > From: Ville Syrjälä
> >
> > struct drm_display_mode is extremely fat. Put it on diet.
> >
> > Some stats for the whole series:
> >
> > 64bit sizeof(struct
Hi Greg,
On Wed, Feb 19, 2020 at 07:19:32PM +0100, Greg Kroah-Hartman wrote:
> On Wed, Feb 19, 2020 at 07:36:52PM +0200, Laurent Pinchart wrote:
> > On Wed, Feb 19, 2020 at 06:00:46PM +0100, Greg Kroah-Hartman wrote:
> >> On Wed, Feb 19, 2020 at 03:22:49PM +0100, Daniel Vetter wrote:
> >>> On
On Thu, Feb 20, 2020 at 04:27:59PM +0200, Ville Syrjälä wrote:
> On Thu, Feb 20, 2020 at 01:21:03PM +, Emil Velikov wrote:
> > On Wed, 19 Feb 2020 at 20:35, Ville Syrjala
> > wrote:
> > >
> > > From: Ville Syrjälä
> > >
> > > struct drm_display_mode is extremely fat. Put it on diet.
> > >
>
Quoting Janusz Krzysztofik (2020-02-20 15:57:24)
> Hi Chris,
>
> On Monday, December 2, 2019 3:59:19 PM CET Chris Wilson wrote:
> > Quoting Janusz Krzysztofik (2019-12-02 14:42:58)
> > > Hi Chris,
> > >
> > > I have a few questions rather than comments. I hope they are worth
> > > spending
>
Quoting Janusz Krzysztofik (2020-02-20 15:32:03)
> Commit b0da8bb705c0 ("lib/i915: for_each_mmap_offset_type()")
> introduced a macro that makes it easy to repeat a test body within a
> loop for each mmap-offset mapping type supported by v4 of i915 MMAP_GTT
> API. However, when run on an older
Quoting Chris Wilson (2020-02-20 16:09:14)
> Quoting Janusz Krzysztofik (2020-02-20 15:32:03)
> > Commit b0da8bb705c0 ("lib/i915: for_each_mmap_offset_type()")
> > introduced a macro that makes it easy to repeat a test body within a
> > loop for each mmap-offset mapping type supported by v4 of
There seems to be a bit of confusing redundancy in a way, how
plane data rate/min cdclk are calculated.
In fact both min cdclk, pixel rate and plane data rate are all
part of the same formula as per BSpec.
However currently we have intel_plane_data_rate, which is used
to calculate plane data rate
Den 19.02.2020 11.21, skrev Daniel Vetter:
> Allows us to drop the drm_driver.release callback.
>
> Signed-off-by: Daniel Vetter
> Cc: "Noralf Trønnes"
> ---
Reviewed-by: Noralf Trønnes
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
On Thu, Feb 20, 2020 at 05:23:47PM +0200, Stanislav Lisovskiy wrote:
> There seems to be a bit of confusing redundancy in a way, how
> plane data rate/min cdclk are calculated.
> In fact both min cdclk, pixel rate and plane data rate are all
> part of the same formula as per BSpec.
>
> However
== Series Details ==
Series: Refactor Gen11+ SAGV support
URL : https://patchwork.freedesktop.org/series/73703/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
5d070083c766 drm/i915: Start passing latency as parameter
0ada6eb4565d drm/i915: Introduce skl_plane_wm_level accessor.
== Series Details ==
Series: Refactor Gen11+ SAGV support
URL : https://patchwork.freedesktop.org/series/73703/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7973 -> Patchwork_16644
Summary
---
**FAILURE**
On Wed, Feb 19, 2020 at 10:22:58PM -0800, Kees Cook wrote:
> Variables declared in a switch statement before any case statements
> cannot be automatically initialized with compiler instrumentation (as
> they are not part of any execution flow). With GCC's proposed automatic
> stack variable
On Thu, Feb 20, 2020 at 11:20:05AM +, Emil Velikov wrote:
> On Thu, 7 Nov 2019 at 15:17, Ville Syrjala
> wrote:
> >
> > From: Ville Syrjälä
> >
> > We have a nice little helper to compute a single LUT entry
> > for everything except the 8bpc legacy gamma mode. Let's
> > complete the set.
> >
== Series Details ==
Series: drm/i915: Add support for HDCP 1.4 over MST connectors (rev4)
URL : https://patchwork.freedesktop.org/series/70393/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7963_full -> Patchwork_16610_full
== Series Details ==
Series: Refactor Gen11+ SAGV support
URL : https://patchwork.freedesktop.org/series/73703/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.6.0
Commit: drm/i915: Start passing latency as parameter
Okay!
Commit: drm/i915: Introduce
On Thu, 2020-02-20 at 17:43 +0200, Ville Syrjälä wrote:
> On Thu, Feb 20, 2020 at 05:23:47PM +0200, Stanislav Lisovskiy wrote:
> > There seems to be a bit of confusing redundancy in a way, how
> > plane data rate/min cdclk are calculated.
> > In fact both min cdclk, pixel rate and plane data rate
There seems to be a bit of confusing redundancy in a way, how
plane data rate/min cdclk are calculated.
In fact both min cdclk, pixel rate and plane data rate are all
part of the same formula as per BSpec.
However currently we have intel_plane_data_rate, which is used
to calculate plane data rate
On Thu, Feb 20, 2020 at 3:19 PM Philippe CORNU wrote:
>
> Hi Daniel,
>
> On 2/19/20 11:21 AM, Daniel Vetter wrote:
> > It's right above the drm_dev_put().
> >
> > Aside: Another driver with a bit much devm_kzalloc, which should
> > probably use drmm_kzalloc instead ...
> >
> > Signed-off-by:
Den 19.02.2020 11.21, skrev Daniel Vetter:
> 7/7 drivers agree that's the right choice, let's do this.
>
> This avoids duplicating the same old error checking code over all 7
> drivers, which is the motivation here.
>
> Signed-off-by: Daniel Vetter
> ---
Reviewed-by: Noralf Trønnes
Den 19.02.2020 11.21, skrev Daniel Vetter:
> Allows us to drop the drm_driver.release callback from all
> drivers, and remove the mipi_dbi_release() function.
>
> Signed-off-by: Daniel Vetter
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Thomas Zimmermann
> Cc: David Airlie
> Cc: Daniel
On Thu, 2020-02-20 at 14:40 +0200, Jani Nikula wrote:
> On Thu, 20 Feb 2020, Stanislav Lisovskiy <
> stanislav.lisovs...@intel.com> wrote:
> > We might be willing to call intel_atomic_get_old_global_obj_state
> > and intel_atomic_get_new_global_obj_state right away, however
> > those are not
On Wed, 19 Feb 2020 at 20:35, Ville Syrjala
wrote:
>
> From: Ville Syrjälä
>
> struct drm_display_mode is extremely fat. Put it on diet.
>
> Some stats for the whole series:
>
> 64bit sizeof(struct drm_display_mode):
> 200 -> 136 bytes (-32%)
>
> 64bit bloat-o-meter -c drm.ko:
> add/remove: 1/0
On 20/02/2020 12:36, Chris Wilson wrote:
In preparation for making GEM execbuf parallel, we need to be prepared
to handle very early declaration of dependencies -- even before our
signaler has itself been submitted.
References: a79ca656b648 ("drm/i915: Push the wakeref->count deferral to the
On Thu, 2020-02-20 at 15:11 +0200, stanislav.lisovs...@intel.com wrote:
> On Thu, 2020-02-20 at 14:40 +0200, Jani Nikula wrote:
> > On Thu, 20 Feb 2020, Stanislav Lisovskiy <
> > stanislav.lisovs...@intel.com> wrote:
> > > We might be willing to call intel_atomic_get_old_global_obj_state
> > > and
== Series Details ==
Series: drm/i915: make i915_debugfs_register return void.
URL : https://patchwork.freedesktop.org/series/73587/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7963_full -> Patchwork_16604_full
Summary
On 20/02/2020 12:52, Chris Wilson wrote:
Quoting Matthew Auld (2020-02-20 12:47:28)
On 20/02/2020 07:50, Chris Wilson wrote:
While we know that the waiters cannot disappear as we walk our list
(only that they might be added), the same cannot be said for our
signalers as they may be completed
Hi Daniel,
On 2/19/20 11:21 AM, Daniel Vetter wrote:
> It's right above the drm_dev_put().
>
> Aside: Another driver with a bit much devm_kzalloc, which should
> probably use drmm_kzalloc instead ...
>
> Signed-off-by: Daniel Vetter
> Cc: Yannick Fertre
> Cc: Philippe Cornu
> Cc: Benjamin
== Series Details ==
Series: drm/i915/psr: Force PSR probe only after full initialization (rev5)
URL : https://patchwork.freedesktop.org/series/73436/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7963_full -> Patchwork_16607_full
== Series Details ==
Series: series starting with [1/1] drm/i915: MCHBAR memory info registers are
moved since GEN 12. (rev3)
URL : https://patchwork.freedesktop.org/series/73332/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7963_full -> Patchwork_16609_full
Commit b0da8bb705c0 ("lib/i915: for_each_mmap_offset_type()")
introduced a macro that makes it easy to repeat a test body within a
loop for each mmap-offset mapping type supported by v4 of i915 MMAP_GTT
API. However, when run on an older version of the driver, those
subtests are believed to be
On Thu, Feb 20, 2020 at 11:24:20AM +, Emil Velikov wrote:
> On Wed, 19 Feb 2020 at 20:36, Ville Syrjala
> wrote:
> >
> > From: Ville Syrjälä
> >
> > The driver never sets mode->private_flags so copying
> > it back and forth is entirely pointless. Stop doing it.
> >
> > Also drop
Hi Chris,
On Monday, December 2, 2019 3:59:19 PM CET Chris Wilson wrote:
> Quoting Janusz Krzysztofik (2019-12-02 14:42:58)
> > Hi Chris,
> >
> > I have a few questions rather than comments. I hope they are worth
> > spending
> > your time.
> >
> > On Wednesday, November 13, 2019 1:52:40 PM
Den 19.02.2020 11.20, skrev Daniel Vetter:
> They all share mipi_dbi_release so we need to switch them all
> together. With this we can drop the final kfree from the release
> function.
>
> Aside, I think we could perhaps have a tiny additional helper for
> these mipi_dbi drivers, the first few
Den 19.02.2020 11.20, skrev Daniel Vetter:
> With this we can drop the final kfree from the release function.
>
> Signed-off-by: Daniel Vetter
> Cc: "Noralf Trønnes"
> ---
Reviewed-by: Noralf Trønnes
___
Intel-gfx mailing list
Commit b0da8bb705c0 ("lib/i915: for_each_mmap_offset_type()")
introduced a macro that makes it easy to repeat a test body within a
loop for each mmap-offset mapping type supported by v4 of i915 MMAP_GTT
API. However, when run on an older version of the driver, those
subtests are believed to be
== Series Details ==
Series: drm/i915/tgl: Remove require_force_probe protection
URL : https://patchwork.freedesktop.org/series/73613/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7963_full -> Patchwork_16613_full
Summary
On Thu, Feb 20, 2020 at 08:46:27PM +0100, Thomas Hellström (VMware) wrote:
> On 2/20/20 7:04 PM, Daniel Vetter wrote:
> > On Thu, Feb 20, 2020 at 10:39:06AM +0100, Thomas Hellström (VMware) wrote:
> > > On 2/19/20 7:42 AM, Thomas Hellström (VMware) wrote:
> > > > On 2/18/20 10:01 PM, Daniel Vetter
== Series Details ==
Series: HDCP 2.2 Comp fixes
URL : https://patchwork.freedesktop.org/series/73708/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7975 -> Patchwork_16646
Summary
---
**SUCCESS**
No regressions
Disable Push Constant buffer addition for TGL.
v2: typos, add additional Wa reference
v3: use REG_BIT macro, move to rcs_engine_wa_init, clean up commit
message.
Bspec: 52890
Cc: Rafael Antognolli
Cc: Matt Roper
Signed-off-by: Matt Atwood
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 5
drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_i915_private struct pointer is
readily available.
The conversion was done
drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_device or drm_i915_private struct
pointer is readily available.
The conversion
Drm specific drm_WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_device struct pointer is readily
available.
The conversion was done
drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_i915_private struct pointer is
readily available.
The conversion was done
drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_i915_private struct pointer is
readily available.
The conversion was done
== Series Details ==
Series: series starting with [CI,01/10] drm/i915/debugfs: Pass guc_log struct
to i915_guc_log_info
URL : https://patchwork.freedesktop.org/series/73610/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7963_full -> Patchwork_16611_full
From: Anusha Srivatsa
According to BSpec. Wa_1606931601 applies for all
TGL steppings.This patch moves the WA implementation
out of A0 only block of rcs_engine_wa_init().
The WA is has also been referred to by an alternate name
Wa_1607090982.
Bspec: 46045,52890
Fixes: 3873fd1a43c7 ("drm/i915:
Please ignore this submission, the code is broken. Sorry for that.
Janusz
On Thursday, February 20, 2020 6:08:19 PM CET Janusz Krzysztofik wrote:
> Commit b0da8bb705c0 ("lib/i915: for_each_mmap_offset_type()")
> introduced a macro that makes it easy to repeat a test body within a
> loop for
On Tue, Feb 11, 2020 at 10:55:32PM +0530, Anshuman Gupta wrote:
> skl_ddb_allocation_overlaps() num_entries hass been passed as
> INTEL_NUM_PIPES, it should be I915_MAX_PIPES.
>
> Cc: Ville Syrjälä
> Signed-off-by: Anshuman Gupta
Reviewed-by: Ville Syrjälä
> ---
>
Commit b0da8bb705c0 ("lib/i915: for_each_mmap_offset_type()")
introduced a macro that makes it easy to repeat a test body within a
loop for each mmap-offset mapping type supported by v4 of i915 MMAP_GTT
API. However, when run on an older version of the driver, those
subtests are believed to be
On Thu, Feb 20, 2020 at 05:33:09PM +0200, Ville Syrjälä wrote:
> On Thu, Feb 20, 2020 at 11:24:20AM +, Emil Velikov wrote:
> > On Wed, 19 Feb 2020 at 20:36, Ville Syrjala
> > wrote:
> > >
> > > From: Ville Syrjälä
> > >
> > > The driver never sets mode->private_flags so copying
> > > it back
On Wed, Feb 19, 2020 at 10:35:39PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We only have 7 bits defined for mode->type. Shrink the storage to u8.
>
> Signed-off-by: Ville Syrjälä
> ---
> include/drm/drm_modes.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff
On Wed, Feb 19, 2020 at 10:35:41PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Store the timings (apart from the clock) as u16. The uapi mode
> struct already uses u16 for everything so using something bigger
> internally doesn't really help us.
>
> Signed-off-by: Ville Syrjälä
== Series Details ==
Series: Security mitigation for Intel Gen7/7.5 HWs
URL : https://patchwork.freedesktop.org/series/73615/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7963_full -> Patchwork_16614_full
Summary
---
== Series Details ==
Series: series starting with [1/2] drm/i915: Double check bumping after the
spinlock
URL : https://patchwork.freedesktop.org/series/73707/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
00c160893898 drm/i915: Double check bumping after the spinlock
-:10:
== Series Details ==
Series: series starting with [1/2] drm/i915: Double check bumping after the
spinlock
URL : https://patchwork.freedesktop.org/series/73707/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7973 -> Patchwork_16645
On Tue, Feb 11, 2020 at 10:55:29PM +0530, Anshuman Gupta wrote:
> As a disabled pipe in pipe_mask is not having a valid intel crtc,
> driver wrongly populates the possible_crtcs mask while initializing
> the plane for a CRTC. Fixing up the plane possible_crtcs mask.
>
> changes since RFC:
> -
Since we check before and then after each debugfs entry, we do not need
to check before each time as well. We will error out as soon as it does
fail, at all other times we know the system to be idle.
No impact on runtime for glk (which apparently is one of the better
behaving systems).
On Thu, Feb 20, 2020 at 07:16:32PM +0200, Ville Syrjälä wrote:
> On Tue, Feb 11, 2020 at 10:55:28PM +0530, Anshuman Gupta wrote:
> > Skip the transcoder whose pipe is disabled while
> > initializing transcoder error state in 3 non-contiguous
> > display pipe system.
> >
> > v2:
> > - Don't skip
We don't need to try reset-stress on every engine with the display, just
once is enough to stress any interlinkage.
This should reduce the runtime to 10s.
Signed-off-by: Chris Wilson
Cc: Martin Peres
---
tests/i915/gem_eio.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_device or drm_i915_private struct
pointer is readily available.
The conversion
drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_i915_private struct pointer is
readily available.
The conversion was done
drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_device or drm_i915_private struct
pointer is readily available.
The conversion
Device specific dev_WARN and dev_WARN_ONCE macros available in kernel
include device information in the backtrace, so we know what device
the warnings originate from.
Similar to this, add new struct drm_device based drm_WARN* macros. These
macros include device information in the backtrace, so we
On Tue, Feb 18, 2020 at 05:42:30PM -0800, José Roberto de Souza wrote:
> dGFX have local memory so it do not have aperture and do not support
> CPU fences but even for iGFX it have a small number of fences.
>
> As replacement for fences to track frontbuffer modifications by CPU
> we have a
On Wed, Feb 19, 2020 at 04:32:50PM -0800, Radhakrishna Sripada wrote:
Elkhartlake does not have as many PLL combinations as Icelake.
Use a simpler get pll function and reuse intel_put_pll for ehl.
v2: Fix the build error
Suggested-by: Matt Roper
Cc: Lucas De Marchi
Signed-off-by:
On Thu, Feb 20, 2020 at 10:39:06AM +0100, Thomas Hellström (VMware) wrote:
> On 2/19/20 7:42 AM, Thomas Hellström (VMware) wrote:
> > On 2/18/20 10:01 PM, Daniel Vetter wrote:
> > > On Tue, Feb 18, 2020 at 9:17 PM Thomas Hellström (VMware)
> > > wrote:
> > > > On 2/17/20 6:55 PM, Daniel Vetter
Convert from using a fixed number of iterations (1 million), to using a
fixed runtime so that we have predictable (and shorter!) run times across
a wide variety of machines.
Signed-off-by: Chris Wilson
Cc: Martin Peres
---
tests/sw_sync.c | 17 +++--
1 file changed, 7
On Thu, Feb 20, 2020 at 07:19:08PM +0100, Daniel Vetter wrote:
> On Wed, Feb 19, 2020 at 10:35:41PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Store the timings (apart from the clock) as u16. The uapi mode
> > struct already uses u16 for everything so using something bigger
> >
On 2/20/20 7:04 PM, Daniel Vetter wrote:
On Thu, Feb 20, 2020 at 10:39:06AM +0100, Thomas Hellström (VMware) wrote:
On 2/19/20 7:42 AM, Thomas Hellström (VMware) wrote:
On 2/18/20 10:01 PM, Daniel Vetter wrote:
On Tue, Feb 18, 2020 at 9:17 PM Thomas Hellström (VMware)
wrote:
On 2/17/20 6:55
On Thu, 20 Feb 2020 at 14:28, Ville Syrjälä
wrote:
>
> On Thu, Feb 20, 2020 at 01:21:03PM +, Emil Velikov wrote:
> > On Wed, 19 Feb 2020 at 20:35, Ville Syrjala
> > wrote:
> > >
> > > From: Ville Syrjälä
> > >
> > > struct drm_display_mode is extremely fat. Put it on diet.
> > >
> > > Some
On Tue, Feb 11, 2020 at 10:55:27PM +0530, Anshuman Gupta wrote:
> we can't have (pipe == crtc->index) assumption in
> driver in order to support 3 non-contiguous
> display pipe system.
>
> FIXME: Remove the WARN_ON(drm_crtc_index(>base) != crtc->pipe)
> when we will fix all such assumption.
>
>
On Tue, Feb 11, 2020 at 10:55:28PM +0530, Anshuman Gupta wrote:
> Skip the transcoder whose pipe is disabled while
> initializing transcoder error state in 3 non-contiguous
> display pipe system.
>
> v2:
> - Don't skip EDP_TRANSCODER error state. [Ville]
> - Use a helper has_transcoder(). [Ville]
== Series Details ==
Series: drm/i915: Use intel_plane_data_rate for min_cdclk calculation (rev2)
URL : https://patchwork.freedesktop.org/series/73718/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7975 -> Patchwork_16647
== Series Details ==
Series: drm/i915: Use intel_plane_data_rate for min_cdclk calculation (rev2)
URL : https://patchwork.freedesktop.org/series/73718/
State : warning
== Summary ==
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
CHK
On Thu, 2020-02-20 at 09:41 +0530, Anshuman Gupta wrote:
> On 2020-02-18 at 23:53:28 +0530, José Roberto de Souza wrote:
> > Commit 60c6a14b489b ("drm/i915/display: Force the state compute
> > phase
> > once to enable PSR") was forcing the state compute too earlier
> > causing errors because not
On 2/20/20 9:08 PM, Daniel Vetter wrote:
On Thu, Feb 20, 2020 at 08:46:27PM +0100, Thomas Hellström (VMware) wrote:
On 2/20/20 7:04 PM, Daniel Vetter wrote:
On Thu, Feb 20, 2020 at 10:39:06AM +0100, Thomas Hellström (VMware) wrote:
On 2/19/20 7:42 AM, Thomas Hellström (VMware) wrote:
On
== Series Details ==
Series: drm/i915/tgl: Allow DC5/DC6 entry while PG2 is active
URL : https://patchwork.freedesktop.org/series/73739/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7977 -> Patchwork_16650
Summary
---
== Series Details ==
Series: drm/i915: Distribute switch variables for initialization (rev2)
URL : https://patchwork.freedesktop.org/series/73690/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7977 -> Patchwork_16651
On Mon, Feb 03, 2020 at 05:10:31PM -0800, Matt Roper wrote:
> It wasn't terribly clear from the bspec's wording, but after discussion
> with the hardware folks, it turns out that we need to preserve the
> pre-existing contents of the MBUS ABOX control register when
> initializing a few specific
On gen12, we no longer need to disable DC5/DC6 when when PG2 is in use
(which translates to cases where we're using VDSC on pipe A).
Bspec: 49193
Cc: Lucas De Marchi
Cc: José Roberto de Souza
Signed-off-by: Matt Roper
---
.../gpu/drm/i915/display/intel_display_power.c | 16 +++-
== Series Details ==
Series: drm/i915: Extend Wa_1606931601 for all steppings.
URL : https://patchwork.freedesktop.org/series/73621/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7963_full -> Patchwork_16616_full
Summary
On Mon, Feb 10, 2020 at 10:20:17PM +, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [1/2] drm/i915: Program MBUS with rmw during
> initialization (rev2)
> URL : https://patchwork.freedesktop.org/series/72950/
> State : success
>
> == Summary ==
>
> CI Bug Log -
== Series Details ==
Series: drm/i915/psr: Force PSR probe only after full initialization (rev6)
URL : https://patchwork.freedesktop.org/series/73436/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7977 -> Patchwork_16649
On Mon, Feb 03, 2020 at 05:10:32PM -0800, Matt Roper wrote:
> On gen11 we only needed to program MBus credits into MBUS_ABOX_CTL
> during display initialization, but on gen12 we're now supposed to
> program the same values into MBUS_ABOX1_CTL and MBUS_ABOX2_CTL as well.
>
> v2:
> - Program
== Series Details ==
Series: drm: Introduce struct drm_device based WARN* and use them in i915 (rev7)
URL : https://patchwork.freedesktop.org/series/72035/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
f3e1e10ac32d drm/i915/display/cdclk: Make WARN* drm specific where drm_priv
Variables declared in a switch statement before any case statements
cannot be automatically initialized with compiler instrumentation (as
they are not part of any execution flow). With GCC's proposed automatic
stack variable initialization feature, this triggers a warning (and they
don't get
On Thu, Feb 20, 2020 at 12:21:14PM +0200, Jani Nikula wrote:
> On Wed, 19 Feb 2020, Kees Cook wrote:
> > Variables declared in a switch statement before any case statements
> > cannot be automatically initialized with compiler instrumentation (as
> > they are not part of any execution flow). With
== Series Details ==
Series: drm/i915/perf: conversion to struct drm_device based logging macros.
(rev2)
URL : https://patchwork.freedesktop.org/series/73589/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7963_full -> Patchwork_16617_full
On Thu, 2020-02-20 at 12:39 +, Mun, Gwan-gyeong wrote:
> On Tue, 2020-02-18 at 12:39 -0800, José Roberto de Souza wrote:
> > Commit 60c6a14b489b ("drm/i915/display: Force the state compute
> > phase
> > once to enable PSR") was forcing the state compute too earlier
> > causing errors because
== Series Details ==
Series: drm: Introduce struct drm_device based WARN* and use them in i915 (rev7)
URL : https://patchwork.freedesktop.org/series/72035/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7976 -> Patchwork_16648
Commit 60c6a14b489b ("drm/i915/display: Force the state compute phase
once to enable PSR") was forcing the state compute too earlier
causing errors because not everything was initialized, so here
moving to the end of i915_driver_modeset_probe() when the display is
all initialized.
Also fixing the
looping in intel-gfx + Jani.
On Tue, 18 Feb 2020 at 05:20, sinisa wrote:
>
>
> On 2020-02-16 22:32, Linus Torvalds wrote:
> > ...
> > Chris Wilson (19):
> > drm/i915/pmu: Correct the rc6 offset upon enabling
> > drm/i915/gem: Take local vma references for the parser
> >
We have a fix for this issue, still going through review.
https://gitlab.freedesktop.org/drm/intel/issues/1151
On Fri, 2020-02-21 at 11:38 +1000, Dave Airlie wrote:
> looping in intel-gfx + Jani.
>
> On Tue, 18 Feb 2020 at 05:20, sinisa wrote:
> >
> > On 2020-02-16 22:32, Linus Torvalds
== Series Details ==
Series: drm/i915/userptr: Don't activate MMU notifier if no pages can be
acquired
URL : https://patchwork.freedesktop.org/series/73641/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7963_full -> Patchwork_16620_full
From: Prathap Kumar Valsan
On gen7 and gen7.5 devices, there could be leftover data residuals in
EU/L3 from the retiring context. This patch introduces workaround to clear
that residual contexts, by submitting a batch buffer with dedicated HW
context to the GPU with ring allocation for each
From: Mika Kuoppala
This patch adds framework to submit an arbitrary batchbuffer on each
context switch to clear residual state for render engine on Gen7/7.5
devices.
The idea of always emitting the context and vm setup around each request
is primary to make reset recovery easy, and not require
Intel ID: PSIRT-TA-201910-001
CVEID: CVE-2019-14615
Summary of Vulnerability
Insufficient control flow in certain data structures for some Intel(R)
Processors with Intel Processor Graphics may allow an unauthenticated
user to potentially enable information disclosure via
From: Prathap Kumar Valsan
On gen7 and gen7.5 devices, there could be leftover data residuals in
EU/L3 from the retiring context. This patch introduces workaround to clear
that residual contexts, by submitting a batch buffer with dedicated HW
context to the GPU with ring allocation for each
From: Mika Kuoppala
This patch adds framework to submit an arbitrary batchbuffer on each
context switch to clear residual state for render engine on Gen7/7.5
devices.
The idea of always emitting the context and vm setup around each request
is primary to make reset recovery easy, and not require
1 - 100 of 154 matches
Mail list logo