== Series Details ==
Series: drm/i915/tgl: Add Wa_1606054188;tgl
URL : https://patchwork.freedesktop.org/series/72148/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7758_full -> Patchwork_16140_full
Summary
---
**SUC
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 implementation is drm_calc_vbltimestamp_from_scanoutpos().
The patch adds drm_crtc_vblank
The callback struct drm_driver.get_scanout_position() is deprecated in
favor of struct drm_crtc_helper_funcs.get_scanout_position(). Convert
amdgpu over.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 12
drivers/gpu/drm/amd/amdgpu/amdgpu_dr
VBLANK callbacks in struct drm_driver are deprecated in favor of their
equivalents in struct drm_crtc_funcs. Convert i915 over.
The callback struct drm_driver.get_scanout_position() is deprecated
in favor of struct drm_crtc_helper_funcs.get_scanout_position().
i915 doesn't use CRTC helpers. Instea
VBLANK interrupts can be disabled immediately or with a delay, where the
latter is the default. The former option can be selected by setting
get_vblank_timestamp and enabling vblank_disable_immediate in struct
drm_device. Simplify the code in preparation of the removal of struct
drm_device.get_vbla
The new callback get_scanout_position() reads the current location
of the scanout process. The operation is currently located in struct
drm_driver, but really belongs to the CRTC. Drivers will be converted
in separate patches.
To help with the conversion, the timestamp calculation has been
moved f
The callback struct drm_driver.get_scanout_position() is deprecated in
favor of struct drm_crtc_helper_funcs.get_scanout_position(). Convert
mem over.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 67 +++
drivers/gpu/drm/msm/disp/mdp5/mdp5_k
The callback struct drm_driver.get_scanout_position() is deprecated in
favor of struct drm_crtc_helper_funcs.get_scanout_position(). Convert stm
over.
Signed-off-by: Thomas Zimmermann
Tested-by: Yannick Fertré
---
drivers/gpu/drm/stm/drv.c | 1 -
drivers/gpu/drm/stm/ltdc.c | 65 ++
The callback struct drm_driver.get_scanout_position() is deprecated in
favor of struct drm_crtc_helper_funcs.get_scanout_position(). Convert
nouveau over.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/nouveau/dispnv04/crtc.c | 1 +
drivers/gpu/drm/nouveau/dispnv50/head.c | 1 +
driv
VBLANK callbacks in struct drm_driver are deprecated in favor of
their equivalents in struct drm_crtc_funcs. Convert amdgpu over.
v2:
* don't wrap existing functions; change signature instead
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 6 +++---
VBLANK callbacks in struct drm_driver are deprecated in favor of
their equivalents in struct drm_crtc_funcs. Convert radeon over.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_display.c | 12 --
drivers/gpu/drm/radeon/radeon_drv.c | 7
VBLANK callbacks in struct drm_driver are deprecated in favor of
their equivalents in struct drm_crtc_funcs. Convert nouvean over.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/nouveau/dispnv04/crtc.c | 3 +++
drivers/gpu/drm/nouveau/dispnv50/head.c | 4
drivers/gpu/drm/nouveau
VBLANK handlers in struct drm_driver are deprecated. Only legacy,
non-KMS drivers are supposed to used them. DRM drivers with kernel
modesetting are supposed to use VBLANK callbacks of the CRTC
infrastructure.
This patchset converts all DRM drivers to CRTC VBLANK callbacks and
cleans up struct drm
The callback struct drm_driver.get_scanout_position() is deprecated in
favor of struct drm_crtc_helper_funcs.get_scanout_position(). Convert
radeon over.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/radeon/atombios_crtc.c | 1 +
drivers/gpu/drm/radeon/radeon_display.c | 13
VBLANK callbacks in struct drm_driver are deprecated in favor of
their equivalents in struct drm_crtc_funcs. Convert msm over.
Signed-off-by: Thomas Zimmermann
Tested-by: Yannick Fertré
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 2 ++
drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c | 2 ++
dri
VBLANK callbacks in struct drm_driver are deprecated in favor of
their equivalents in struct drm_crtc_funcs. Convert vkms over.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Rodrigo Siqueira
Tested-by: Rodrigo Siqueira
---
drivers/gpu/drm/vkms/vkms_crtc.c | 9 ++---
drivers/gpu/drm/vkms/vk
All non-legacy users of VBLANK functions in struct drm_driver have been
converted to use the respective interfaces in struct drm_crtc_funcs. The
remaining users of VBLANK callbacks in struct drm_driver are legacy drivers
with userspace modesetting.
All users of struct drm_driver.get_scanout_positi
VBLANK callbacks in struct drm_driver are deprecated in favor of
their equivalents in struct drm_crtc_funcs. Convert vc4 over.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/vc4/vc4_crtc.c | 1 +
drivers/gpu/drm/vc4/vc4_drv.c | 2 --
2 files changed, 1 insertion(+), 2 deletions(-)
diff -
VBLANK callbacks in struct drm_driver are deprecated in favor of
their equivalents in struct drm_crtc_funcs. Convert sti over.
v2:
* remove unnecessary include of sti_crtc.h from sti_drv.c
Signed-off-by: Thomas Zimmermann
Acked-by: Benjamin Gaignard
---
drivers/gpu/drm/sti/sti_crtc.c |
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
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 3 ---
drivers/gpu/drm/vmwgfx/vmwgfx_drv
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 Zimmermann
---
drivers/gpu/drm/drm_vblank.c| 27 +++
d
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
---
drivers/gpu/drm/gma500/cdv_intel_display.c | 3 +++
drivers/gpu/drm/gma500/psb_drv.c | 4
drivers/gpu/drm/gma500
VBLANK callbacks in struct drm_driver are deprecated in favor of
their equivalents in struct drm_crtc_funcs. Convert stm over.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/stm/drv.c | 1 -
drivers/gpu/drm/stm/ltdc.c | 1 +
2 files changed, 1 insertion(+), 1 deletion(-)
diff --git a/dri
The callback struct drm_driver.get_scanout_position() is deprecated in
favor of struct drm_crtc_helper_funcs.get_scanout_position(). Convert vc4
over.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/vc4/vc4_crtc.c | 12 +++-
drivers/gpu/drm/vc4/vc4_drv.c | 1 -
drivers/gpu/drm/vc4
On Fri, 2020-01-17 at 11:06 -0800, Matt Roper wrote:
> On Fri, Jan 17, 2020 at 11:50:25AM +0200, Stanislav Lisovskiy wrote:
> > 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 m
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 request it again,
but when kernel disables the HDCP due to any DD
Test-with: <20200120085158.9151-2-anshuman.gu...@intel.com>
Anshuman Gupta (1):
drm/i915/hdcp: Update CP as per the kernel internal state
drivers/gpu/drm/i915/display/intel_display_types.h | 6 ++
drivers/gpu/drm/i915/display/intel_hdcp.c | 13 -
2 files changed, 18 i
== Series Details ==
Series: Security mitigation for Intel Gen7 HWs (rev3)
URL : https://patchwork.freedesktop.org/series/72028/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7758_full -> Patchwork_16141_full
Summary
--
On 17/01/2020 20:58, Ye, Tony wrote:
Failed on parsing the trace log:
Died at ./trace.pl line 296.
Raw data attached.
I need to add better error messages - that line is command line argument
handling. I have dropped "-s" from this version in favour of always
trying to track ELSP port oc
Quoting Akeem G Abodunrin (2020-01-16 17:46:55)
> +static u32
> +gen7_fill_interface_descriptor(struct batch_chunk *state,
> + const struct batch_vals *bv,
> + const struct cb_kernel *kernel,
> + unsigned int cou
On Mon, 20 Jan 2020, 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 request it ag
On Mon, 20 Jan 2020, Ramalingam C wrote:
> 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
>> rea
== Series Details ==
Series: drm: Clean up VBLANK callbacks in struct drm_driver (rev8)
URL : https://patchwork.freedesktop.org/series/71873/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
9ff81bf712fd drm: Remove internal setup of struct
drm_device.vblank_disable_immediate
c83
== Series Details ==
Series: series starting with [1/4] drm/mst: Don't do atomic checks over
disabled managers
URL : https://patchwork.freedesktop.org/series/72152/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7758_full -> Patchwork_16142_full
===
== Series Details ==
Series: drm: Clean up VBLANK callbacks in struct drm_driver (rev8)
URL : https://patchwork.freedesktop.org/series/71873/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.6.0
Commit: drm: Remove internal setup of struct drm_device.vblank_disable_
Replace the vm_idr + vm_idr_mutex to an XArray. The XArray data
structure is now used to implement IDRs, and provides its won locking.
We can simply remove the IDR wrapper and in the process also remove our
extra mutex.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem
drivers/gpu/drm/i915/display/intel_atomic.c:185: warning: Function parameter or
member 'state' not described in 'intel_connector_needs_modeset'
drivers/gpu/drm/i915/display/intel_atomic.c:185: warning: Function parameter or
member 'connector' not described in 'intel_connector_needs_modeset'
driv
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 addition to the exhaustion, a
very long linear list of mm
As we use a mutex to serialise the first acquire (as it may be a lengthy
operation), but only an atomic decrement for the release, we have to
be careful in case a second thread races and completes both
acquire/release as the first finishes its acquire.
Fixes: c9ad602feabe ("drm/i915: Split i915_ac
<0> [198.668822] gem_exec-12460 193899010us : timeline_advance:
timeline_advance:387 GEM_BUG_ON(!atomic_read(&tl->pin_count))
<0> [198.668859] -
<4> [198.669619] [ cut here ]
<2> [198.669621] kernel BUG at drivers/gpu/drm/i915/gt/inte
== Series Details ==
Series: drm/i915: Check require bandwidth did not exceed LSPCON limitation
URL : https://patchwork.freedesktop.org/series/72157/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7758_full -> Patchwork_16143_full
===
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 should be updated as per the kernel
> >> internal state. Let's say if Content protection is disabled
> >> by us
On 17/01/2020 23.11, Chris Wilson wrote:
> Just keep on generating a new mmap_offset for the same old buffer, but
> for different handles and so exercise the scaling of the obj->mmo lists.
>
Reviewed-by: Abdiel Janulgue
> Signed-off-by: Chris Wilson
> Cc: Abdiel Janulgue
__
Currently access to perf_events, i915_perf and other performance monitoring and
observability subsystems of the kernel is open for a privileged process [1] with
CAP_SYS_ADMIN capability enabled in the process effective set [2].
This patch set introduces CAP_PERFMON capability designed to secure
Introduce CAP_PERFMON capability designed to secure system performance
monitoring and observability operations so that CAP_PERFMON would assist
CAP_SYS_ADMIN capability in its governing role for perf_events, i915_perf
and other performance monitoring and observability subsystems.
CAP_PERFMON int
Open access to monitoring of kernel code, system, tracepoints and namespaces
data for a CAP_PERFMON privileged process. For backward compatibility
reasons access to perf_events subsystem remains open for CAP_SYS_ADMIN
privileged processes but CAP_SYS_ADMIN usage for secure perf_events
monitoring
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 should be updated as per the kernel
>> >> internal state. Let's
Open access to anon kprobes, uprobes and eBPF tracing for CAP_PERFMON
privileged processes. For backward compatibility reasons access remains
open for CAP_SYS_ADMIN privileged processes but CAP_SYS_ADMIN usage for
secure monitoring is discouraged with respect to CAP_PERFMON capability.
Providing
Extend error messages to mention CAP_PERFMON capability as an option
to substitute CAP_SYS_ADMIN capability for secure system performance
monitoring and observability operations. Make perf_event_paranoid_check()
and __cmd_ftrace() to be aware of CAP_PERFMON capability.
Signed-off-by: Alexey Buda
Open access to i915_perf monitoring for CAP_PERFMON privileged processes.
For backward compatibility reasons access to i915_perf subsystem remains
open for CAP_SYS_ADMIN privileged processes but CAP_SYS_ADMIN usage for
secure i915_perf monitoring is discouraged with respect to CAP_PERFMON
capabil
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: Chang
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
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: Mo
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: Rename
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 "enabled_s
Open access to bpf_trace monitoring for CAP_PERFMON privileged processes.
For backward compatibility reasons access to bpf_trace monitoring remains
open for CAP_SYS_ADMIN privileged processes but CAP_SYS_ADMIN usage for
secure bpf_trace monitoring is discouraged with respect to CAP_PERFMON
capabi
== Series Details ==
Series: Misc GuC CT improvements - part II (rev2)
URL : https://patchwork.freedesktop.org/series/72071/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7758_full -> Patchwork_16144_full
Summary
---
Open access to monitoring for CAP_PERFMON privileged processes.
For backward compatibility reasons access to the monitoring remains
open for CAP_SYS_ADMIN privileged processes but CAP_SYS_ADMIN usage
for secure monitoring is discouraged with respect to CAP_PERFMON
capability. Providing the access
Open access to monitoring for CAP_PERFMON privileged processes.
For backward compatibility reasons access to the monitoring remains
open for CAP_SYS_ADMIN privileged processes but CAP_SYS_ADMIN usage
for secure monitoring is discouraged with respect to CAP_PERFMON
capability. Providing the access
Open access to monitoring for CAP_PERFMON privileged processes.
For backward compatibility reasons access to the monitoring remains
open for CAP_SYS_ADMIN privileged processes but CAP_SYS_ADMIN usage
for secure monitoring is discouraged with respect to CAP_PERFMON
capability. Providing the access
Open access to monitoring for CAP_PERFMON privileged processes.
For backward compatibility reasons access to the monitoring remains
open for CAP_SYS_ADMIN privileged processes but CAP_SYS_ADMIN usage
for secure monitoring is discouraged with respect to CAP_PERFMON
capability. Providing the access
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 li
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 diff
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 a/t
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: Rename
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 "enabled_s
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: Chang
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
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: Mo
== 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
---
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 sh
== 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 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
> ---
> drivers/gpu/drm/vmwg
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: Chang
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
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 "enabled_s
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: Rename
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: Mo
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
> ---
>
== 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, 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/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
===
== 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
===
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 veri
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 forc
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
> ---
> tests/intel-ci/fast-feedback.t
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 e
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 i
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 context
== 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
== 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 ce
== 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
===
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 additi
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 implementati
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 Zimmerm
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 +
== 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
1 - 100 of 162 matches
Mail list logo
