== Series Details ==
Series: drm/i915: Check require bandwidth did not exceed LSPCON limitation
(rev3)
URL : https://patchwork.freedesktop.org/series/72157/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7781 -> Patchwork_16180
Hello Jani,
On Fri, Dec 20, 2019 at 12:04 PM Rajat Jain wrote:
>
> Certain laptops now come with panels that have integrated privacy
> screens on them. This patch adds support for such panels by adding
> a privacy-screen property to the intel_connector for the panel, that
> the userspace can
== Series Details ==
Series: drm/i915/dp: set fail-safe mode if EDID corrupt
URL : https://patchwork.freedesktop.org/series/72311/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7781 -> Patchwork_16179
Summary
---
Quoting Stephen Rothwell (2020-01-20 23:34:24)
> Hi all,
>
> After merging the drm-intel-fixes tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
>
> Caused by commit
>
> d8fcca47e195 ("drm/i915/userptr: fix size calculation")
>
> I have reverted that commit for
As we are not using the sysfs infrastructure anymore, link to it is
removed. And global srm data and mutex to protect it are removed,
with required handling at revocation check function.
Yet to test hence RFC tag is added.
Signed-off-by: Ramalingam C
Suggested-by: Sean Paul
---
== Series Details ==
Series: drm/i915: Check require bandwidth did not exceed LSPCON limitation
(rev5)
URL : https://patchwork.freedesktop.org/series/72157/
State : failure
== Summary ==
Applying: drm/i915: Check require bandwidth did not exceed LSPCON limitation
error: corrupt patch at line
[AMD Official Use Only - Internal Distribution Only]
-Original Message-
From: Sharma, Shashank
Sent: Tuesday, January 21, 2020 11:44 AM
To: Lee Shawn C ; intel-gfx@lists.freedesktop.org
Cc: Cooper Chiou ; Sam McNally
Subject: RE: [Intel-gfx] [PATCH v2] drm/i915: Check require
[AMD Official Use Only - Internal Distribution Only]
Hello Shawn,
-Original Message-
From: Intel-gfx On Behalf Of Lee
Shawn C
Sent: Tuesday, January 21, 2020 6:56 PM
To: intel-gfx@lists.freedesktop.org
Cc: Cooper Chiou ; Sam McNally
Subject: [Intel-gfx] [PATCH v2] drm/i915: Check
== Series Details ==
Series: dumb buffer max size available
URL : https://patchwork.freedesktop.org/series/72309/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7781 -> Patchwork_16178
Summary
---
**SUCCESS**
No
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
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
According to chapter 5.1.1.2 in DP spec. When the Sink
device capability is unknown, for example due to corruption
of an EDID. The Source device may fall back to a set of
fall-back video timing formats its choice. When none of
the fall-back video timing formats is acceptable, the
Source device
== Series Details ==
Series: drm/i915/hdcp: Update CP as per the kernel internal state
URL : https://patchwork.freedesktop.org/series/72251/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7775_full -> Patchwork_16169_full
== Series Details ==
Series: drm/i915/guc: Don't GEM_BUG_ON on corrupted H2G CTB
URL : https://patchwork.freedesktop.org/series/72305/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7781 -> Patchwork_16177
Summary
---
== Series Details ==
Series: drm/i915: Mark the removal of the i915_request from the sched.link
URL : https://patchwork.freedesktop.org/series/72302/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7781 -> Patchwork_16176
== Series Details ==
Series: drm/i915: Global state rework
URL : https://patchwork.freedesktop.org/series/72301/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7781 -> Patchwork_16175
Summary
---
**SUCCESS**
No
As per the discussion at
https://patchwork.freedesktop.org/patch/347384/?series=71618=1
I am proposing this extension for drm_getcap to provide the available
memory size for dumb buffer.
Ramalingam C (2):
drm: dumb buffer size availability
drm/i915: implement dumb_size_available callback
drm_getcap is added with another parameter called
DRM_CAP_DUMB_SIZE_AVAILABLE to get the available size
for dumb buffer from drm driver.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/drm_ioctl.c | 5 +
include/drm/drm_drv.h | 15 +++
include/uapi/drm/drm.h | 1 +
dumb_size_available callback for drm_driver is implemented at I915.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/i915_drv.c | 1 +
drivers/gpu/drm/i915/i915_drv.h | 3 +++
drivers/gpu/drm/i915/i915_gem.c | 17 +
3 files changed, 21 insertions(+)
diff --git
== Series Details ==
Series: series starting with [1/2] drm/i915/gt: Acquire ce->active before
ce->pin_count/ce->pin_mutex
URL : https://patchwork.freedesktop.org/series/72249/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7772_full -> Patchwork_16168_full
On 2020-01-20 at 15:02:46 +0200, Jani Nikula wrote:
> On Mon, 20 Jan 2020, Ramalingam C wrote:
> > hdcp->value is used to track the internal transistions during the link
> > failure and re-establishing it. When ever kernel want to update the
> > "content protection" we take the required locks and
On 2020-01-20 at 11:19:54 +0530, Anshuman Gupta wrote:
> Content Protection property should be updated as per the kernel
> internal state. Let's say if Content protection is disabled
> by userspace, CP property should be set to UNDESIRED so that
> reauthentication will not happen until userspace
== Series Details ==
Series: Enable second DBuf slice for ICL and TGL (rev20)
URL : https://patchwork.freedesktop.org/series/70059/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7781 -> Patchwork_16174
Summary
---
== Series Details ==
Series: Introduce CAP_PERFMON to secure system performance monitoring and
observability
URL : https://patchwork.freedesktop.org/series/72273/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7781 -> Patchwork_16173
== Series Details ==
Series: series starting with [1/5] drm/i915/gt: Acquire ce->active before
ce->pin_count/ce->pin_mutex
URL : https://patchwork.freedesktop.org/series/72269/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7779 -> Patchwork_16172
== Series Details ==
Series: series starting with [RFC,1/2] drm/i915/gem: Convert vm idr to xarray
URL : https://patchwork.freedesktop.org/series/72240/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7772_full -> Patchwork_16166_full
== Series Details ==
Series: series starting with [1/3] intel-ci: Drop gem_ctx_switch from fast
feedback
URL : https://patchwork.freedesktop.org/series/72275/
State : failure
== Summary ==
CI Bug Log - changes from IGT_5373 -> IGTPW_3951
== Series Details ==
Series: drm/i915/gt: Clear the whole first page of LRC on gen9
URL : https://patchwork.freedesktop.org/series/72229/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7772_full -> Patchwork_16165_full
Hi all,
After merging the drm-intel-fixes tree, today's linux-next build (x86_64
allmodconfig) failed like this:
Caused by commit
d8fcca47e195 ("drm/i915/userptr: fix size calculation")
I have reverted that commit for today.
--
Cheers,
Stephen Rothwell
pgpN5QHxyhuHR.pgp
Description:
== Series Details ==
Series: drm/i915/dsi: Ensure that the ACPI adapter lookup overrides the bus num
URL : https://patchwork.freedesktop.org/series/72225/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7770_full -> Patchwork_16164_full
Quoting Tvrtko Ursulin (2020-01-20 19:47:08)
>
> On 20/01/2020 17:57, Chris Wilson wrote:
> > Keep the rq->fence.flags consistent with the status of the
> > rq->sched.link, and clear the associated bits when decoupling the link
> > on retirement (as we may wish to inspect those flags independent
Quoting Tvrtko Ursulin (2020-01-20 19:47:08)
>
> On 20/01/2020 17:57, Chris Wilson wrote:
> > Keep the rq->fence.flags consistent with the status of the
> > rq->sched.link, and clear the associated bits when decoupling the link
> > on retirement (as we may wish to inspect those flags independent
== Series Details ==
Series: drm/i915: eDP DPCD aux backlight fixes (rev7)
URL : https://patchwork.freedesktop.org/series/69914/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7769_full -> Patchwork_16163_full
Summary
On 20/01/2020 17:57, Chris Wilson wrote:
Keep the rq->fence.flags consistent with the status of the
rq->sched.link, and clear the associated bits when decoupling the link
on retirement (as we may wish to inspect those flags independent of
other state).
Fixes: 32ff621fd744 ("drm/i915/gt: Allow
== Series Details ==
Series: drm/i915: Add support for HDCP 1.4 over MST connectors (rev3)
URL : https://patchwork.freedesktop.org/series/70393/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7769_full -> Patchwork_16160_full
== Series Details ==
Series: drm/i915/gt: Be paranoid and reset the GPU before release (rev2)
URL : https://patchwork.freedesktop.org/series/72185/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7769_full -> Patchwork_16159_full
== Series Details ==
Series: series starting with [1/2] drm/i915/gvt: Wean gvt off dev_priv->engine[]
URL : https://patchwork.freedesktop.org/series/72194/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7769_full -> Patchwork_16158_full
We should never BUG_ON on any corruption in CTB descriptor as
data there can be also modified by the GuC. Instead we can
use flag "is_in_error" to indicate that we will not process
any further messages over this CTB (until reset).
Signed-off-by: Michal Wajdeczko
Cc: Chris Wilson
Cc: Daniele
== Series Details ==
Series: drm/i915/debugfs: remove i915_dpcd file
URL : https://patchwork.freedesktop.org/series/72192/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7768_full -> Patchwork_16157_full
Summary
---
== Series Details ==
Series: drm/i915: Global state rework
URL : https://patchwork.freedesktop.org/series/72301/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
e1d119e88d09 drm/i915: Polish WM_LINETIME register stuff
15d81d275b12 drm/i915: Move linetime wms into the crtc state
== Series Details ==
Series: drm/i915/dp: debug log max vswing and pre-emphasis
URL : https://patchwork.freedesktop.org/series/72191/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7768_full -> Patchwork_16156_full
Summary
== Series Details ==
Series: drm/i915/bios: stop using vbt.ddi_port_info directly
URL : https://patchwork.freedesktop.org/series/72190/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7768_full -> Patchwork_16155_full
Keep the rq->fence.flags consistent with the status of the
rq->sched.link, and clear the associated bits when decoupling the link
on retirement (as we may wish to inspect those flags independent of
other state).
Fixes: 32ff621fd744 ("drm/i915/gt: Allow temporary suspension of inflight
requests")
From: Ville Syrjälä
Let's add a copy of the active_pipes bitmask into the cdclk_state.
While this is duplicating a bit of information we may already
have elsewhere, I think it's worth it to decopule the cdclk stuff
from whatever else wants to use that bitmask. Also we want to get
rid of all the
From: Ville Syrjälä
Extract a small helper to compute the active pipes bitmask
based on the old bitmask + the crtcs in the atomic state.
I want to decouple the cdclk state entirely from the current
global state so I want to track the active pipes also inside
the (to be introduced) full cdclk
From: Ville Syrjälä
Let's convert cdclk_state to be a proper global state. That allows
us to use the regular atomic old vs. new state accessor, hopefully
making the code less confusing.
We do have to deal with a few more error cases in case the cdclk
state duplication fails. But so be it.
From: Ville Syrjälä
Our current global state handling is pretty ad-hoc. Let's try to
make it better by imitating the standard drm core private object
approach.
The reason why we don't want to directly use the private objects
is locking; Each private object has its own lock so if we
introduce
From: Ville Syrjälä
Move the initial setup of state->{cdclk,min_cdclk[],min_voltage_level[]}
into intel_modeset_calc_cdclk(), and we'll move the counterparts into
intel_cdclk_swap_state(). This encapsulates the cdclk state much better.
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
Now that we have the more formal global state thing let's
use if for memory bandwidth tracking. No real difference
to the current private object usage since we already
tried to avoid taking the single serializing lock needlessly.
But since we're going to roll the global state
From: Ville Syrjälä
intel_cdclk_needs_cd2x_update() is named rather confusingly.
We don't have to do a cd2x update, rather we are allowed to
do one (as opposed to a full PLL reprogramming with its heavy
handed modeset). So let's rename the function to
intel_cdclk_can_cd2x_update().
From: Ville Syrjälä
Our current global state handling is pretty ad-hoc. Let's try to
make it better by imitating the standard drm core private object
approach.
The reason why we don't want to directly use the private objects
is locking; Each private object has its own lock so if we
introduce
From: Ville Syrjälä
Move intel_atomic_state_free() next to its counterpart.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_atomic.c | 11 +++
drivers/gpu/drm/i915/display/intel_atomic.h | 1 +
drivers/gpu/drm/i915/display/intel_display.c | 11 ---
3
From: Ville Syrjälä
Give the cdclk init/uninit functions a _hw suffix to make
it clear they are about initializing the actual hardware.
I'll be wanting to to add a intel_cdclk_init() which is
purely initializing software structures.
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
Move all the old vs. new state shenanigans
into intel_set_cdclk_{pre,post}_plane_update() so that the caller
doesn't need to know any of it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 44 ++--
From: Ville Syrjälä
Let's store the normal and IPS linetime watermarks individually,
and while at it we'll pimp the register definitions as well.
v2: Deal with gvt
Reviewed-by: Stanislav Lisovskiy
Signed-off-by: Ville Syrjälä
---
.../drm/i915/display/intel_display_types.h| 3 +-
From: Ville Syrjälä
The linetime watermarks really have very little in common with the
plane watermarks. It looks to be cleaner to simply track them in
the crtc_state and program them from the normal modeset/fastset
paths.
The only dark cloud comes from the fact that the register is
still
From: Ville Syrjälä
I want to have a higher level cdclk state object so let's rename
the current lower level thing to cdclk_config (because I lack
imagination).
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_cdclk.c| 426 +-
From: Ville Syrjälä
Move the min_cdclk[] and min_voltage_level[] arrays under the
rest of the cdclk state. And while at it provide a simple
helper (intel_cdclk_clear_state()) to clear the state during
the ww_mutex backoff dance.
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
Use the same structure to store the cdclk state in both
intel_atomic_state and dev_priv. First step towards proper
old vs. new cdclk states.
Signed-off-by: Ville Syrjälä
---
.../gpu/drm/i915/display/intel_atomic_plane.c | 6 +-
drivers/gpu/drm/i915/display/intel_audio.c
From: Ville Syrjälä
The dirty_pipes bitmask is now unused. Get rid of it.
Reviewed-by: Stanislav Lisovskiy
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h | 1 -
drivers/gpu/drm/i915/intel_pm.c | 35 +
2 files changed, 1 insertion(+), 35
From: Ville Syrjälä
To make life less confusing let's swap() the entire cdclk state
rather than swapping some parts, copying other parts, and leaving
the rest just as is.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 18 +++---
1 file changed, 3
From: Ville Syrjälä
Here's an attempt at making the ad-hoc global state handling more
standardized like the private obj stuff. As the first excercise we
convert the bandwidth and cdclk states to use this. Another future
target for this is probably ddb/fifo allocation for the pipes.
Entire
== Series Details ==
Series: Introduce CAP_PERFMON to secure system performance monitoring and
observability
URL : https://patchwork.freedesktop.org/series/72273/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
08ee25620fef capabilities: introduce CAP_PERFMON to kernel and user
Platforms without a HW detiler doesn't support the get_tiling IOCTL.
Fix the drm_intel_bo_gem_create_from_* functions assuming the default
no-tiling, no-swizzling setting for the GEM buffer in this case.
Signed-off-by: Imre Deak
---
intel/intel_bufmgr_gem.c | 42
On Mon, Jan 20, 2020 at 09:23:14AM +0100, Thomas Zimmermann wrote:
> The legacy version of get_scanout_position() was only useful while
> drivers still used drm_driver.get_scanout_position(). With no such
> drivers left, the related typedef and code can be removed
>
> Signed-off-by: Thomas
On Mon, Jan 20, 2020 at 09:22:55AM +0100, Thomas Zimmermann wrote:
> The callback get_vblank_timestamp() is currently located in struct
> drm_driver, but really belongs into struct drm_crtc_funcs. Add an
> equivalent there. Driver will be converted in separate patches.
>
> The default
On 20/01/2020 12.49, Chris Wilson wrote:
> Currently we create a new mmap_offset for every call to
> mmap_offset_ioctl. This exposes ourselves to an abusive client that may
> simply create new mmap_offsets ad infinitum, which will exhaust physical
> memory and the virtual address space. In
== Series Details ==
Series: series starting with [v3,1/2] drm/i915/userptr: add user_size limit
check
URL : https://patchwork.freedesktop.org/series/72186/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7764_full -> Patchwork_16154_full
== Series Details ==
Series: series starting with [1/5] drm/i915/gt: Acquire ce->active before
ce->pin_count/ce->pin_mutex
URL : https://patchwork.freedesktop.org/series/72269/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
6cbb3c0bda69 drm/i915/gt: Acquire ce->active before
== Series Details ==
Series: drm/i915/gt: Report the currently active execlists request (rev2)
URL : https://patchwork.freedesktop.org/series/72179/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7762_full -> Patchwork_16152_full
Chris Wilson writes:
> Quoting Mika Kuoppala (2020-01-20 13:50:46)
>> Chris Wilson writes:
>>
>> > Only a couple of tests from gem_ctx_switch are run in BAT, to check we
>> > have multiple contexts on RCS. It doesn't actually verify the switch,
>> > just that the execbuf API accepts the
Quoting Mika Kuoppala (2020-01-20 13:50:46)
> Chris Wilson writes:
>
> > Only a couple of tests from gem_ctx_switch are run in BAT, to check we
> > have multiple contexts on RCS. It doesn't actually verify the switch,
> > just that the execbuf API accepts the context argument.
> >
> > This test
Chris Wilson writes:
> Historically, we've had many problems with missed interrupt/seqno
> syndrome and so have focus on testing with gem_sync. However, these
> tests rely on the kernel itself reporting the issue which it no longer
> does. So why the extra variety may impose different timing of
Chris Wilson writes:
> The principle under test is that we fill the ring and the kernel waits
> rather than overrun the ring buffer. We only need one test to exercise
> that basic behaviour in BAT.
>
> Signed-off-by: Chris Wilson
Acked-by: Mika Kuoppala
> ---
>
On 15-01-2020 03:08, Manasi Navare wrote:
On Fri, Dec 13, 2019 at 10:54:20PM +0530, Animesh Manna wrote:
Hi Manasi/Jani,
Thanks for helping phy compliance design.
Added my understanding/doubts below.
On 12/12/2019 5:20 AM, Manasi Navare wrote:
Hi Animesh/Jani,
Is this the right way to
Chris Wilson writes:
> Only a couple of tests from gem_ctx_switch are run in BAT, to check we
> have multiple contexts on RCS. It doesn't actually verify the switch,
> just that the execbuf API accepts the context argument.
>
> This test is redundant as actual context switching (and more) is
== Series Details ==
Series: series starting with [1/4] drm/i915: Only retire requests when eviction
is allowed to blocked
URL : https://patchwork.freedesktop.org/series/72184/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7761_full -> Patchwork_16151_full
== Series Details ==
Series: drm/i915: Include the debugfs params header for its own definition
URL : https://patchwork.freedesktop.org/series/72181/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7760_full -> Patchwork_16148_full
On Mon, 20 Jan 2020, Ramalingam C wrote:
> hdcp->value is used to track the internal transistions during the link
> failure and re-establishing it. When ever kernel want to update the
> "content protection" we take the required locks and update the property
> state along with uevent.
My point is
== Series Details ==
Series: drm: Clean up VBLANK callbacks in struct drm_driver (rev8)
URL : https://patchwork.freedesktop.org/series/71873/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_ -> Patchwork_16170
Summary
On Mon, Jan 20, 2020 at 9:23 AM Thomas Zimmermann wrote:
>
> VBLANK callbacks in struct drm_driver are deprecated in favor of
> their equivalents in struct drm_crtc_funcs. Convert gma500 over.
>
> Signed-off-by: Thomas Zimmermann
Looks good. For this patch:
Acked-by: Patrik Jakobsson
> ---
>
Those patch series, do some initial preparation DBuf manipulating code
cleanups, i.e remove redundant structures/code, switch to mask
based DBuf manupulation, get into use DBuf assignment according to
BSpec rules.
Stanislav Lisovskiy (5):
drm/i915: Remove skl_ddl_allocation struct
drm/i915:
Added proper DBuf slice mapping to correspondent
pipes, depending on pipe configuration as stated
in BSpec.
v2:
- Remove unneeded braces
- Stop using macro for DBuf assignments as
it seems to reduce readability.
v3: Start using enabled slices mask in dev_priv
v4: Renamed
Current DBuf slices update wasn't done in proper
place, especially its "post" part, which should
disable those only once vblank had passed and
all other changes are committed.
v2: Fix to use dev_priv and intel_atomic_state
instead of skl_ddb_values
(to be nuked in Villes patch)
v3:
Current consensus that it is redundant as
we already have skl_ddb_values struct out there,
also this struct contains only single member
which makes it unnecessary.
v2: As dirty_pipes soon going to be nuked away
from skl_ddb_values, evacuating enabled_slices
to safer in dev_priv.
v3:
Start manipulating DBuf slices as a mask,
but not as a total number, as current approach
doesn't give us full control on all combinations
of slices, which we might need(like enabling S2
only can't enabled by setting enabled_slices=1).
Removed wrong code from intel_get_ddb_size as
it doesn't match
Now start using parameterized DBUF_CTL instead
of hardcoded, this would allow shorter access
functions when reading or storing entire state.
Tried to implement it in a MMIO_PIPE manner, however
DBUF_CTL1 address is higher than DBUF_CTL2, which
implies that we have to now subtract from base
rather
On 1/20/20 9:23 AM, Thomas Zimmermann wrote:
> VBLANK callbacks in struct drm_driver are deprecated in favor of
> their equivalents in struct drm_crtc_funcs. Convert vmwgfx over.
>
> v2:
> * remove accidental whitespace fixes
>
> Signed-off-by: Thomas Zimmermann
> ---
>
== Series Details ==
Series: drm/i915: Fix typo in kerneldoc function name
URL : https://patchwork.freedesktop.org/series/72180/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7758_full -> Patchwork_16147_full
Summary
On 2020-01-20 at 13:24:05 +0200, Jani Nikula wrote:
> On Mon, 20 Jan 2020, Ramalingam C wrote:
> > On 2020-01-20 at 12:29:36 +0200, Jani Nikula wrote:
> >> On Mon, 20 Jan 2020, Ramalingam C wrote:
> >> > On 2020-01-20 at 11:19:54 +0530, Anshuman Gupta wrote:
> >> >> Content Protection property
== Series Details ==
Series: Enable second DBuf slice for ICL and TGL (rev17)
URL : https://patchwork.freedesktop.org/series/70059/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7758_full -> Patchwork_16145_full
Summary
Those patch series, do some initial preparation DBuf manipulating code
cleanups, i.e remove redundant structures/code, switch to mask
based DBuf manupulation, get into use DBuf assignment according to
BSpec rules.
Stanislav Lisovskiy (5):
drm/i915: Remove skl_ddl_allocation struct
drm/i915:
Added proper DBuf slice mapping to correspondent
pipes, depending on pipe configuration as stated
in BSpec.
v2:
- Remove unneeded braces
- Stop using macro for DBuf assignments as
it seems to reduce readability.
v3: Start using enabled slices mask in dev_priv
v4: Renamed
Start manipulating DBuf slices as a mask,
but not as a total number, as current approach
doesn't give us full control on all combinations
of slices, which we might need(like enabling S2
only can't enabled by setting enabled_slices=1).
Removed wrong code from intel_get_ddb_size as
it doesn't match
Now start using parameterized DBUF_CTL instead
of hardcoded, this would allow shorter access
functions when reading or storing entire state.
Tried to implement it in a MMIO_PIPE manner, however
DBUF_CTL1 address is higher than DBUF_CTL2, which
implies that we have to now subtract from base
rather
Current consensus that it is redundant as
we already have skl_ddb_values struct out there,
also this struct contains only single member
which makes it unnecessary.
v2: As dirty_pipes soon going to be nuked away
from skl_ddb_values, evacuating enabled_slices
to safer in dev_priv.
v3:
Current DBuf slices update wasn't done in proper
place, especially its "post" part, which should
disable those only once vblank had passed and
all other changes are committed.
v2: Fix to use dev_priv and intel_atomic_state
instead of skl_ddb_values
(to be nuked in Villes patch)
v3:
Historically, we've had many problems with missed interrupt/seqno
syndrome and so have focus on testing with gem_sync. However, these
tests rely on the kernel itself reporting the issue which it no longer
does. So why the extra variety may impose different timing of execution
on the HW (and so
The principle under test is that we fill the ring and the kernel waits
rather than overrun the ring buffer. We only need one test to exercise
that basic behaviour in BAT.
Signed-off-by: Chris Wilson
---
tests/intel-ci/fast-feedback.testlist | 3 ---
1 file changed, 3 deletions(-)
diff --git
Only a couple of tests from gem_ctx_switch are run in BAT, to check we
have multiple contexts on RCS. It doesn't actually verify the switch,
just that the execbuf API accepts the context argument.
This test is redundant as actual context switching (and more) is verified by
live_gem_contexts and
1 - 100 of 162 matches
Mail list logo
