== Series Details ==
Series: drm/i915/ehl: Ensure that the DDI selection MUX is programmed correctly
URL : https://patchwork.freedesktop.org/series/72357/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7787_full -> Patchwork_16202_full
==
== Series Details ==
Series: drm/i915/gt: Poison GTT scratch pages (rev3)
URL : https://patchwork.freedesktop.org/series/72423/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7799 -> Patchwork_16225
Summary
---
**FAIL
Using a clear page for scratch means that we have relatively benign
errors in case it is accidentally used, but that can be rather too
benign for debugging. If we poison the scratch, ideally it quickly
results in an obvious error.
Suggested-by: Mika Kuoppala
Signed-off-by: Chris Wilson
Cc: Mika
Quoting Dale B Stimson (2020-01-22 23:26:57)
> Switch from simple iteration over all potential engines to using
> macro __for_each_physical_engine which only returns engines that are
> actually present.
>
> For each context (as it is created) call gem_context_set_all_engines
> so that execbuf will
On Wed, Jan 22, 2020 at 06:22:17PM +0200, Jani Nikula wrote:
> On Wed, 15 Jan 2020, Pankaj Bharadiya
> wrote:
> > 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.
> >
> >
== Series Details ==
Series: series starting with [CI,1/2] drm/i915/guc: Provide mmio list to be
saved/restored on engine reset
URL : https://patchwork.freedesktop.org/series/72358/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7787_full -> Patchwork_16203_full
==
On Tue, 21 Jan 2020, Chris Wilson wrote:
> Quoting Jani Nikula (2020-01-21 13:58:08)
>> On Tue, 21 Jan 2020, Chris Wilson wrote:
>> > Quoting Jani Nikula (2020-01-21 11:39:15)
>> >> Add convenience helpers for the most common uncore operations with
>> >> struct drm_i915_private * as context rathe
On Thu, 23 Jan 2020, "Bharadiya,Pankaj"
wrote:
> Will rebase remaining patches and submit.
Please also add a patch to convert MISSING_CASE(), and another to remove
the WARN_ON/WARN_ON_ONCE "overrides" that we have in i915_utils.h.
Thanks,
Jani.
--
Jani Nikula, Intel Open Source Graphics Cente
On Thu, 23 Jan 2020 at 08:51, Chris Wilson wrote:
>
> Using a clear page for scratch means that we have relatively benign
> errors in case it is accidentally used, but that can be rather too
> benign for debugging. If we poison the scratch, ideally it quickly
> results in an obvious error.
>
> Sug
== Series Details ==
Series: drm/i915/gt: Poison GTT scratch pages (rev4)
URL : https://patchwork.freedesktop.org/series/72423/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7799 -> Patchwork_16226
Summary
---
**FAIL
Quoting Matthew Auld (2020-01-23 09:38:02)
> On Thu, 23 Jan 2020 at 08:51, Chris Wilson wrote:
> >
> > Using a clear page for scratch means that we have relatively benign
> > errors in case it is accidentally used, but that can be rather too
> > benign for debugging. If we poison the scratch, idea
Using a clear page for scratch means that we have relatively benign
errors in case it is accidentally used, but that can be rather too
benign for debugging. If we poison the scratch, ideally it quickly
results in an obvious error.
v2: Set each page individual just in case we are using highmem for
This converts various instances of printk based logging macros in
i915/display/intel_dp.c with the new struct drm_device based logging
macros using the following coccinelle script:
@rule1@
identifier fn, T;
@@
fn(...,struct drm_i915_private *T,...) {
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-D
Converts various instances of the printk based logging macros in
i915/display/intel_display_power.c to the struct drm_device based
logging macros using the following coccinelle script:
@rule1@
identifier fn, T;
@@
fn(...,struct drm_i915_private *T,...) {
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
This converts various instances of the printk based logging macros in
i915/display/intel_opregion.c with the new struct drm_device based
logging macros using the following coccinelle script:
@rule1@
identifier fn, T;
@@
fn(...,struct drm_i915_private *T,...) {
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
First pass of conversion to the new struct drm_based device logging
macros in the drm/i915/gem directory. This conversion was achieved using
the following coccinelle script that transforms based on the existence
of a straightforward struct drm_i915_private device:
@rule1@
identifier fn, T;
@@
fn(
If the module happens to be loaded later at runtime there is a chance
memory is already fragmented enough to fail allocation of firmware
blob storage and consequently GVT init. Since it doesn't seem to be
necessary to have the blob contiguous, use vmalloc() instead to avoid
the issue.
Signed-off-b
On Tue, Jan 21, 2020 at 9:31 AM Alexey Budankov
wrote:
>
>
> On 21.01.2020 17:43, Stephen Smalley wrote:
> > On 1/20/20 6:23 AM, Alexey Budankov wrote:
> >>
> >> Introduce CAP_PERFMON capability designed to secure system performance
> >> monitoring and observability operations so that CAP_PERFMON
On 1/22/20 5:45 AM, Alexey Budankov wrote:
On 21.01.2020 21:27, Alexey Budankov wrote:
On 21.01.2020 20:55, Alexei Starovoitov wrote:
On Tue, Jan 21, 2020 at 9:31 AM Alexey Budankov
wrote:
On 21.01.2020 17:43, Stephen Smalley wrote:
On 1/20/20 6:23 AM, Alexey Budankov wrote:
Introduce
This patch converts various instances of the printk based logging macros
into the struct drm_device based macros. This was achieved using the
following coccinelle script for matching existing struct
drm_i915_private devices:
@rule1@
identifier fn, T;
@@
fn(...,struct drm_i915_private *T,...) {
<+.
On Tue, 21 Jan 2020, Patchwork wrote:
== Series Details ==
Series: conversion to struct drm_device logging macros.
URL : https://patchwork.freedesktop.org/series/72349/
State : failure
== Summary ==
Applying: drm/i915/dsi: conversion to struct drm_device log macros
Applying: drm/i915/ddi
Converts various instances of the printk based logging macros in
i915/display/intel_hdcp.c with the struct drm_device based macros using
coccinelle. The script matches based on the existence of an existing
struct drm_i915_private device:
@rule1@
identifier fn, T;
@@
fn(...,struct drm_i915_private
This series is a part of the conversion to the new struct drm_device
based logging macros in drm/i915.
This series focuses on the drm/i915/gem directory and converts all
straightforward instances of the printk based logging macros to the new
macros.
Wambui Karuga (2):
drm/i915/gem: initial conv
This converts the more straightforward instances of the printk based
logging macros with the struct drm_device based logging macros.
This transformation was achieved using coccinelle and the following
script for matching an existing struct drm_i915_private device:
@rule1@
identifier fn, T;
@@
fn(.
This series continues the ongoing conversion to the new struct
drm_device based logging macros for debug in i915.
v2: address merge conflict in i915/display/intel_dp.c due to newer
changes in file.
Wambui Karuga (6):
drm/i915/dsi: conversion to struct drm_device log macros
drm/i915/ddi: conve
On 1/20/20 5:00 PM, Alexey Budankov wrote:
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
Convert most of the remaining uses of the printk based logging macros to
the new struct drm_device based logging macros in drm/i915/gem.
This also involves extracting the struct drm_i915_private device
from various types, and using it in the various macros.
Signed-off-by: Wambui Karuga
---
drive
This patch converts various instances of the printk based logging macros
in drm/i915/display/intel_display.c to the new struct drm_device based
logging macros.
In some instances, this involves extracting the struct drm_i915_private
device from various intel types and using it in the macros.
v2: us
On Wed, Jan 22, 2020 at 05:25:40PM +0200, Jani Nikula wrote:
>
> Hi Maarten/Maxime,
>
> Please pull the drm_device based drm_WARN* macros from the topic
> branch. I'll pull the same to drm-intel-next-queued.
>
> I like to use the topic branch here, because due to timing it'll take
> forever for the
Sorry for replying to myself again.
On Wednesday, January 22, 2020 4:24:49 PM CET Janusz Krzysztofik wrote:
> Hi Chris,
>
> On Thursday, January 9, 2020 4:03:30 PM CET Chris Wilson wrote:
> > Quoting Janusz Krzysztofik (2020-01-09 14:01:25)
> > > On future hardware with missing GGTT BAR we won't
Using a clear page for scratch means that we have relatively benign
errors in case it is accidentally used, but that can be rather too
benign for debugging. If we poison the scratch, ideally it quickly
results in an obvious error.
v2: Set each page individually just in case we are using highmem fo
== Series Details ==
Series: drm/i915: conversion to new drm logging macros. (rev2)
URL : https://patchwork.freedesktop.org/series/72350/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7787_full -> Patchwork_16205_full
Summa
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 automatica
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
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 automatica
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 automati
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 automati
== Series Details ==
Series: series starting with [v3,1/2] drm: add drm_core_check_all_features() to
check for a mask of features (rev2)
URL : https://patchwork.freedesktop.org/series/72407/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7801 -> Patchwork_16227
===
Chris Wilson writes:
> Using a clear page for scratch means that we have relatively benign
> errors in case it is accidentally used, but that can be rather too
> benign for debugging. If we poison the scratch, ideally it quickly
> results in an obvious error.
>
> v2: Set each page individually ju
From: Tvrtko Ursulin
Quick fixup to the test so correct way of iterating the static engine list
is used. More comprehensive fixes to the test are in progress.
Signed-off-by: Tvrtko Ursulin
---
tests/i915/gem_ctx_isolation.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
Quoting Mika Kuoppala (2020-01-23 11:56:20)
> Chris Wilson writes:
>
> > Using a clear page for scratch means that we have relatively benign
> > errors in case it is accidentally used, but that can be rather too
> > benign for debugging. If we poison the scratch, ideally it quickly
> > results in
On Thu, Jan 23, 2020 at 12:01:34PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Quick fixup to the test so correct way of iterating the static engine list
> is used. More comprehensive fixes to the test are in progress.
>
> Signed-off-by: Tvrtko Ursulin
Reviewed-by: Petri Latvala
For our threaded clear test, we want to create as many buffers as can
fit into the available memory. However, since we don't know the size of
that available memory, it can be easy to create too large or too many
buffers, and waste our time testing the unobtainable. Instead, try
probing the availabl
From: Tvrtko Ursulin
In test cases which create new contexts and submit work against them using
the passed in engine index we are sometimes unsure whether this engine
index was potentially created based on a default context with engine map
configured (such as when under the __for_each_physical_en
Use drm_core_check_all_features() to ensure both the driver features and
the per-device driver features are taken into account when registering
debugfs files.
v3:
- files[i].driver_features == 0 actually means "don't care"
v2:
- use drm_core_check_all_features()
Cc: Ville Syrjälä
Cc: Thomas Zim
Add new drm_core_check_all_features() function to check for a mask of
features. All features in the mask are required.
Redefine existing drm_core_check_feature() in terms of this function,
using the drm_driver_feature enum for the parameter.
v3:
- add drm_core_check_all_features() (Thomas)
v2:
-
Quoting Tvrtko Ursulin (2020-01-23 12:43:06)
> From: Tvrtko Ursulin
>
> In test cases which create new contexts and submit work against them using
> the passed in engine index we are sometimes unsure whether this engine
> index was potentially created based on a default context with engine map
>
To multiply 2 u32 numbers to generate a u64 in C requires a bit of
forewarning for the compiler.
Signed-off-by: Chris Wilson
Cc: Ramalingam C
Cc: Joonas Lahtinen
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/i915/i915_gem.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git
On Wed, 22 Jan 2020, Thomas Zimmermann wrote:
> Hi
>
> Am 22.01.20 um 16:50 schrieb Jani Nikula:
>> Use drm_core_check_all_features() to ensure both the driver features and
>> the per-device driver features are taken into account when registering
>> debugfs files.
>>
>> v2:
>> - use drm_core_chec
On 23/01/2020 12:54, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-01-23 12:43:06)
From: Tvrtko Ursulin
In test cases which create new contexts and submit work against them using
the passed in engine index we are sometimes unsure whether this engine
index was potentially created based on
From: Tvrtko Ursulin
In test cases which create new contexts and submit work against them using
the passed in engine index we are sometimes unsure whether this engine
index was potentially created based on a default context with engine map
configured (such as when under the __for_each_physical_en
Quoting Tvrtko Ursulin (2020-01-23 13:08:26)
>
> On 23/01/2020 12:54, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2020-01-23 12:43:06)
> >> From: Tvrtko Ursulin
> >>
> >> In test cases which create new contexts and submit work against them using
> >> the passed in engine index we are sometime
On Thu, Jan 23, 2020 at 12:59:34PM +, Chris Wilson wrote:
> To multiply 2 u32 numbers to generate a u64 in C requires a bit of
> forewarning for the compiler.
>
> Signed-off-by: Chris Wilson
> Cc: Ramalingam C
> Cc: Joonas Lahtinen
> Cc: sta...@vger.kernel.org
> ---
> drivers/gpu/drm/i915/
On Tue, 21 Jan 2020, Wambui Karuga wrote:
> This series continues the conversion to the new struct drm_device based
> logging macros in various files in drm/i915. These patches were
> achieved both using coccinelle and manually.
>
> v2: rebase patches onto drm-tip to fix merge conflict in v1 serie
This is a proposed RFC solution for 3 display pipes combination
system support.
Anshuman Gupta (6):
drm/i915: Iterate over pipe and skip the disabled one
drm/i915: Remove (pipe == crtc->index) asummption
drm/i915: Fix wrongly populated plane possible_crtcs bit mask
drm/i915: Get right max
Allow 3-display pipes SKU system with any combination
in INTEL_INFO pipe mask.
B.Spec:50075
Cc: Ville Syrjälä
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/intel_device_info.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_device_i
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_crtc mask.
Cc: Ville Syrjälä
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_display.c |
It should not be assumed that a disabled display pipe will be
always last the pipe.
for_each_pipe() should iterate over I915_MAX_PIPES and check
for the disabled pipe and skip that pipe so that it should not
initialize the intel crtc for any disabled pipes.
Few compilation error needed to handle a
intel_plane_fb_max_stride should return the max stride of
primary plane for first available pipe in intel device info
pipe_mask.
Cc: Ville Syrjälä
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_display.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --
we can't have (pipe == crtc->index) assumption in
driver in order to support 3 non-contiguous
display pipe system.
Cc: Ville Syrjälä
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_display.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/driv
Add a WARN_ON for a disabled pipe in pipe_mask at
intel_get_crtc_for_pipe() function.
Cc: Ville Syrjälä
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_display_types.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
Quoting Ville Syrjälä (2020-01-23 13:27:07)
> On Thu, Jan 23, 2020 at 12:59:34PM +, Chris Wilson wrote:
> > To multiply 2 u32 numbers to generate a u64 in C requires a bit of
> > forewarning for the compiler.
> >
> > Signed-off-by: Chris Wilson
> > Cc: Ramalingam C
> > Cc: Joonas Lahtinen
>
On Thu, Jan 23, 2020 at 06:56:55PM +0530, Anshuman Gupta wrote:
> we can't have (pipe == crtc->index) assumption in
> driver in order to support 3 non-contiguous
> display pipe system.
>
> Cc: Ville Syrjälä
> Signed-off-by: Anshuman Gupta
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 1
On Thu, 23 Jan 2020, Anshuman Gupta wrote:
> It should not be assumed that a disabled display pipe will be
> always last the pipe.
> for_each_pipe() should iterate over I915_MAX_PIPES and check
> for the disabled pipe and skip that pipe so that it should not
> initialize the intel crtc for any dis
On Thu, Jan 23, 2020 at 06:56:56PM +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_crtc mask.
>
> Cc: Ville Syrjälä
> Signed-
On Thu, 23 Jan 2020, Anshuman Gupta wrote:
> we can't have (pipe == crtc->index) assumption in
> driver in order to support 3 non-contiguous
> display pipe system.
>
> Cc: Ville Syrjälä
> Signed-off-by: Anshuman Gupta
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_displa
On Thu, Jan 23, 2020 at 06:56:57PM +0530, Anshuman Gupta wrote:
> intel_plane_fb_max_stride should return the max stride of
> primary plane for first available pipe in intel device info
> pipe_mask.
>
> Cc: Ville Syrjälä
> Signed-off-by: Anshuman Gupta
> ---
> drivers/gpu/drm/i915/display/intel
Hi Dave & Daniel,
Last pull request for 5.5. Then it's Jani's turn
to handle 5.6.
A fix for huge userptr objects and a fix that is
also cc stable, to correctly handle negative values
in engine->uabi_class/instance.
Regards, Joonas
***
drm-intel-fixes-2020-01-23:
- Avoid overflow with huge use
On Thu, Jan 23, 2020 at 06:56:58PM +0530, Anshuman Gupta wrote:
> Add a WARN_ON for a disabled pipe in pipe_mask at
> intel_get_crtc_for_pipe() function.
>
> Cc: Ville Syrjälä
> Signed-off-by: Anshuman Gupta
> ---
> drivers/gpu/drm/i915/display/intel_display_types.h | 2 ++
> 1 file changed, 2
On Thu, Jan 23, 2020 at 06:56:59PM +0530, Anshuman Gupta wrote:
> Allow 3-display pipes SKU system with any combination
> in INTEL_INFO pipe mask.
> B.Spec:50075
>
> Cc: Ville Syrjälä
> Signed-off-by: Anshuman Gupta
> ---
> drivers/gpu/drm/i915/intel_device_info.c | 7 ---
> 1 file changed,
We disabled rps while it appeared to be a contributing factor to system
instablity, as that is now resolved, re-enable RPS and see how we fare.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_pci.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/i9
On Thu, Jan 23, 2020 at 01:39:03PM +, Chris Wilson wrote:
> Quoting Ville Syrjälä (2020-01-23 13:27:07)
> > On Thu, Jan 23, 2020 at 12:59:34PM +, Chris Wilson wrote:
> > > To multiply 2 u32 numbers to generate a u64 in C requires a bit of
> > > forewarning for the compiler.
> > >
> > > Sig
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
amdgpu over.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 12
drivers/gpu/drm/amd/amdgpu/amdgpu_dr
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
nouveau over.
v4:
* add argument names in function declaration
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/nouveau/dispnv04/crtc.c | 1
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
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 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
Tested-by: Yannick Fertré
---
drivers/gpu/drm/stm/drv.c | 1 -
drivers/gpu/drm/stm/ltdc.c | 1 +
2 files changed, 1 insertion(+), 1 de
VBLANK callbacks in struct drm_driver are deprecated in favor of
their equivalents in struct drm_crtc_funcs. Convert nouvean over.
v4:
* add argument names in function declaration
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/nouveau/dispnv04/crtc.c | 3 +++
drivers/gpu/drm/no
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
The callback struct drm_driver.get_scanout_position() is deprecated in
favor of struct drm_crtc_helper_funcs.get_scanout_position(). Convert
radeon over.
v4:
* 80-character line fixes
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/radeon/atombios_crtc.c | 1 +
drivers/gpu/dr
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
Acked-by: Patrik Jakobsson
---
drivers/gpu/drm/gma500/cdv_intel_display.c | 3 +++
drivers/gpu/drm/gma500/psb_drv.c | 4
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 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
On Wed, Jan 22, 2020 at 04:24:14PM -0800, Manasi Navare wrote:
> In the port sync mode, for the master crtc, the master_transcoder is INVALID.
> In that case since its value is -1, do not set the bit in the bitmask.
>
> Cc: Ville Syrjälä
> Fixes: d0eed1545fe7 ("drm/i915: Fix post-fastset modeset
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
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/drm_vblank.c| 27 ++
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
Move away from I915_READ_FW() and I915_WRITE_FW() in display code, and
switch to using intel_de_read_fw() and intel_de_write_fw(),
respectively.
No functional changes.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display.c | 79 +++-
1 file changed, 42 inser
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 |
Move away from I915_READ_FW() and I915_WRITE_FW() in display code, and
switch to using intel_de_read_fw() and intel_de_write_fw(),
respectively. Also switch I915_READ() and I915_WRITE() over in this file
while at it.
No functional changes.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/dis
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 ++
On 23/01/2020 13:16, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-01-23 13:08:26)
On 23/01/2020 12:54, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-01-23 12:43:06)
From: Tvrtko Ursulin
In test cases which create new contexts and submit work against them using
the passed in engine
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 -
Move away from I915_READ_FW() and I915_WRITE_FW() and switch to using
intel_uncore_read_fw() and intel_uncore_write_fw(), respectively.
No functional changes.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_csr.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/dr
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
Move away from I915_READ_FW() and I915_WRITE_FW() in display code, and
switch to using intel_de_read_fw() and intel_de_write_fw(),
respectively.
No functional changes.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_pm.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
di
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
Acked-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 3 ---
drive
1 - 100 of 190 matches
Mail list logo
