== Series Details ==
Series: Security mitigation for Intel Gen7/7.5 HWs
URL : https://patchwork.freedesktop.org/series/73745/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7979 -> Patchwork_16654
Summary
---
On 2020-02-20 19:41, Chris Wilson wrote:
> 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
On 2020-02-20 18:57, Chris Wilson wrote:
> 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
Thanks for making this
On 2020-02-20 18:53, Chris Wilson wrote:
> We don't need to try reset-stress on every engine with the display, just
> once is enough to stress any interlinkage.
If you say so :)
>
> This should reduce the runtime to 10s.
That would be appreciated!
>
> Signed-off-by: Chris Wilson
> Cc:
== Series Details ==
Series: Security mitigation for Intel Gen7/7.5 HWs
URL : https://patchwork.freedesktop.org/series/73745/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
ce61523e6b22 drm/i915: Add mechanism to submit a context WA on ring submission
00161707fff0
== Series Details ==
Series: Security mitigation for Intel Gen7/7.5 HWs
URL : https://patchwork.freedesktop.org/series/73743/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7979 -> Patchwork_16653
Summary
---
== Series Details ==
Series: Security mitigation for Intel Gen7/7.5 HWs
URL : https://patchwork.freedesktop.org/series/73743/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
a3dc644c8ea3 drm/i915: Add mechanism to submit a context WA on ring submission
49dc47834a5e
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: 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
== Series Details ==
Series: drm/i915/lspcon: Make sure link rate did not exceed downstream and
lspcon limitation (rev2)
URL : https://patchwork.freedesktop.org/series/73012/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7978 -> Patchwork_16652
== 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
On 2/12/2020 5:54 AM, Fosha, Robert M wrote:
On 2/11/20 11:57 AM, Michal Wajdeczko wrote:
On Tue, 11 Feb 2020 18:53:05 +0100, Fosha, Robert M
wrote:
On 2/4/20 4:43 PM, Ye, Tony wrote:
On 1/27/2020 1:41 AM, Michal Wajdeczko wrote:
On Thu, 23 Jan 2020 16:51:58 +0100, Chris Wilson
While mode setting, driver would calculate mode rate based on
resolution and bpp. And choose the best bpp that did not exceed
DP bandwidtd.
But LSPCON had more restriction due to it convert DP to HDMI.
Driver should respect HDMI's bandwidth limitation if LSPCON
was active. This change would
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
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
> >
== Series Details ==
Series: drm_device managed resources
URL : https://patchwork.freedesktop.org/series/73633/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7963_full -> Patchwork_16618_full
Summary
---
**FAILURE**
== 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
== 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/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
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
== 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, 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
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 +++-
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
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: 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
== 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
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 -
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 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/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 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
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
== 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
== 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
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:
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
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
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
== 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: 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 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 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ä
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 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 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
== 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
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:
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).
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 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 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ä
> ---
>
== 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:
> -
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]
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.
>
>
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
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
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
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_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 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 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
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
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(-)
== 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: 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**
== 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
== 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.
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
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.
>
> Signed-off-by: Daniel Vetter
> Cc: "Noralf Trønnes"
> ---
Reviewed-by: Noralf Trønnes
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
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
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
== 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
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:
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
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
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 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
>
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
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
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
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.
> > >
>
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
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
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
== 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
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
1 - 100 of 154 matches
Mail list logo
