== Series Details ==
Series: drm/i915: fix an error code in intel_overlay_do_put_image()
URL : https://patchwork.freedesktop.org/series/89050/
State : warning
== Summary ==
$ make htmldocs 2>&1 > /dev/null | grep i915
./drivers/gpu/drm/i915/gem/i915_gem_shrinker.c:102: warning: Function parame
== Series Details ==
Series: drm/i915/gvt: Fix error code in intel_gvt_init_device()
URL : https://patchwork.freedesktop.org/series/89047/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9966 -> Patchwork_19930
Summary
--
Screen flickers on Innolux panel when clock rate 54 is in use.
According to the panel vendor, though clock rate 54 is advertised,
but the max clock rate it really supports is 27.
So use slow and wide training for panels with DPCP rev < 1.4 to resolve
the issue. User also confirmed the
== Series Details ==
Series: drm/i915/gvt: Fix error code in intel_gvt_init_device()
URL : https://patchwork.freedesktop.org/series/89047/
State : warning
== Summary ==
$ make htmldocs 2>&1 > /dev/null | grep i915
./drivers/gpu/drm/i915/gem/i915_gem_shrinker.c:102: warning: Function parameter
This code should propagate the error from intel_overlay_pin_fb()
but currently it returns success.
Fixes: 1b321026e213 ("drm/i915: Pass ww ctx to intel_pin_to_display_plane")
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/i915/display/intel_overlay.c | 4 +++-
1 file changed, 3 insertions(+),
The intel_gvt_init_vgpu_type_groups() function is only called from
intel_gvt_init_device(). If it fails then the intel_gvt_init_device()
prints the error code and propagates it back again. That's a bug
because false is zero/success. The fix is to modify it to return zero
or negative error codes
== Series Details ==
Series: drm/i915: FBC cleanups
URL : https://patchwork.freedesktop.org/series/89036/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9966 -> Patchwork_19928
Summary
---
**FAILURE**
Serious unkno
== Series Details ==
Series: sna: Eliminate sna_mode_wants_tear_free()
URL : https://patchwork.freedesktop.org/series/89038/
State : failure
== Summary ==
Applying: sna: Eliminate sna_mode_wants_tear_free()
error: sha1 information is lacking or useless (src/sna/sna.h).
error: could not build f
== Series Details ==
Series: drm/i915: FBC cleanups
URL : https://patchwork.freedesktop.org/series/89036/
State : warning
== Summary ==
$ make htmldocs 2>&1 > /dev/null | grep i915
./drivers/gpu/drm/i915/gem/i915_gem_shrinker.c:102: warning: Function parameter
or member 'ww' not described in
== Series Details ==
Series: drm/i915: FBC cleanups
URL : https://patchwork.freedesktop.org/series/89036/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+drivers/gpu/drm/i915/gt/intel_engine_sta
== Series Details ==
Series: drm/i915: FBC cleanups
URL : https://patchwork.freedesktop.org/series/89036/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
d006a5bb82f9 drm/i915: Add frontbuffer tracking tracepoints
-:58: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#58:
On Mon, Apr 12, 2021 at 10:00:18AM +0200, Peter Zijlstra wrote:
> check_{present,absent}() only need R/O access, use verify_page_range()
> instead to remove modular use of apply_to_page_range().
>
> Signed-off-by: Peter Zijlstra (Intel)
> ---
> drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
On Tue, Apr 13, 2021 at 09:36:32AM +0200, Peter Zijlstra wrote:
> On Mon, Apr 12, 2021 at 01:05:09PM -0700, Kees Cook wrote:
> > On Mon, Apr 12, 2021 at 10:00:16AM +0200, Peter Zijlstra wrote:
> > > +struct vpr_data {
> > > + int (*fn)(pte_t pte, unsigned long addr, void *data);
> > > + void *data;
From: Ville Syrjälä
The modparam checks performed by sna_mode_wants_tear_free() don't
generally work when the server is running as a regular user. Hence
we can't rely on them to indicate whether FBC/PSR/etc is enabled.
A lso the "Panel Self-Refresh" connector property doesn't actually
exist so we
From: Ville Syrjälä
Now that each pipe tracks its own no_fbc_reason we can print that
out in debugfs, and we can also show which pipe is currently
selected for FBC duty.
Signed-off-by: Ville Syrjälä
---
.../drm/i915/display/intel_display_debugfs.c | 50 +--
1 file changed, 36
From: Ville Syrjälä
There's no need to store all this stuff in intel_fbc_state_cache.
Just check it all against the plane/crtc states and store only
what we need. Probably more should get nuked still, but this
is a start.
So what we'll do is:
- each crtc will check its own state and update its l
From: Ville Syrjälä
FBC and double wide pipe are mutually exclusive. Disable FBC when
we have to resort to double wide.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_fbc.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
b
From: Ville Syrjälä
On ILK+ we current do a nuke right after activating FBC. If my
memory isn't playing tricks on me this is actially required if
FBC didn't stay disabled for a full frame. In that case the
deactivate+reactivate may not invalidate the cfb. I'd have to
double chekc to be sure thoug
From: Ville Syrjälä
We try to set no_fbc_reason when FBC is not possible, let's
consistently clear when activating FBC.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_fbc.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i9
From: Ville Syrjälä
Pull the fbc enable vs. disable stuff into a small helper so
we don't have to have it pollute the higher level modeset code.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 5 +---
drivers/gpu/drm/i915/display/intel_fbc.c | 26 ++
From: Ville Syrjälä
Write the tiling check in a nicer form.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_fbc.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
b/drivers/gpu/drm/i915/display/intel_fbc.c
i
From: Ville Syrjälä
Add some tracpoints for frontbuffer tracking so we can
try to figure out what's going on.
Signed-off-by: Ville Syrjälä
---
.../gpu/drm/i915/display/intel_frontbuffer.c | 5 +++
drivers/gpu/drm/i915/i915_trace.h | 38 +++
2 files changed, 43 ins
From: Ville Syrjälä
The FBC code is a bit of mess. Start cleaning it up a bit.
The main thing here is throwing out tons of redundant state
from the fbc_state_cache and just checkng that stuff ahead of
time from the plane/crtc states.
Ville Syrjälä (8):
drm/i915: Add frontbuffer tracking tracep
== Series Details ==
Series: drm/i915/dg1: Add HWMON power sensor support (rev2)
URL : https://patchwork.freedesktop.org/series/88459/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9964 -> Patchwork_19927
Summary
---
== Series Details ==
Series: drm/i915/dg1: Add HWMON power sensor support (rev2)
URL : https://patchwork.freedesktop.org/series/88459/
State : warning
== Summary ==
$ make htmldocs 2>&1 > /dev/null | grep i915
./drivers/gpu/drm/i915/gem/i915_gem_shrinker.c:102: warning: Function parameter
or
== Series Details ==
Series: drm/i915/dg1: Add HWMON power sensor support (rev2)
URL : https://patchwork.freedesktop.org/series/88459/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
fd48aa4fd9a8 drm/i915/dg1: Add HWMON power sensor support
-:104: WARNING:FILE_PATH_CHANGES: added
As part of the System Managemenent Interface (SMI), use the HWMON
subsystem to display power utilization.
The following standard HWMON power sensors are currently supported
(and appropriately scaled):
/sys/class/drm/card0/device/hwmon/hwmon
- energy1_input
- power1_cap
-
As part of the System Managemenent Interface (SMI), use the HWMON
subsystem to display power utilization.
The following standard HWMON power sensors are currently supported
(and appropriately scaled):
/sys/class/drm/card0/device/hwmon/hwmon
- energy1_input
- power1_cap
-
On Thu, 2021-04-01 at 20:05 +0300, Gwan-gyeong Mun wrote:
> As per b.spec 49274, the IO buffer Wake lines and Fast Wake lines can be
> calculated based on the following formula.
>
> IO buffer wake lines = ROUNDUP(PSR2 IO wake time / total line time in
> microseconds)
> Fast wake lines = ROUNDUP
== Series Details ==
Series: drm/i915/pm: Make the wm parameter of print_wm_latency a pointer
URL : https://patchwork.freedesktop.org/series/89022/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9963_full -> Patchwork_19926_full
=
== Series Details ==
Series: drm/i915/pm: Make the wm parameter of print_wm_latency a pointer
URL : https://patchwork.freedesktop.org/series/89022/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9963 -> Patchwork_19926
Summa
On Tue, Apr 13, 2021 at 08:39:07PM +0300, Ville Syrjälä wrote:
On Tue, Apr 13, 2021 at 10:22:24AM -0700, Lucas De Marchi wrote:
On Tue, Apr 13, 2021 at 06:45:16PM +0300, Ville Syrjälä wrote:
>On Mon, Apr 12, 2021 at 11:09:27PM -0700, Lucas De Marchi wrote:
>> Direction on gen9+ was to stop readi
== Series Details ==
Series: drm/i915/pm: Make the wm parameter of print_wm_latency a pointer
URL : https://patchwork.freedesktop.org/series/89022/
State : warning
== Summary ==
$ make htmldocs 2>&1 > /dev/null | grep i915
./drivers/gpu/drm/i915/gem/i915_gem_shrinker.c:102: warning: Function p
== Series Details ==
Series: drm/i915/pm: Make the wm parameter of print_wm_latency a pointer
URL : https://patchwork.freedesktop.org/series/89022/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
03e2f5a6dc70 drm/i915/pm: Make the wm parameter of print_wm_latency a pointer
-:13:
On Tue, Apr 13, 2021 at 10:22:24AM -0700, Lucas De Marchi wrote:
> On Tue, Apr 13, 2021 at 06:45:16PM +0300, Ville Syrjälä wrote:
> >On Mon, Apr 12, 2021 at 11:09:27PM -0700, Lucas De Marchi wrote:
> >> Direction on gen9+ was to stop reading the straps and only rely on the
> >> VBT for marking the
This fixes the following build error with GCC 11:
In function ‘snb_wm_latency_quirk’,
inlined from ‘ilk_setup_wm_latency’ at
drivers/gpu/drm/i915/intel_pm.c:3109:3,
inlined from ‘intel_init_pm’ at drivers/gpu/drm/i915/intel_pm.c:7695:3:
drivers/gpu/drm/i915/intel_pm.c:3058
On Tue, Apr 13, 2021 at 06:45:16PM +0300, Ville Syrjälä wrote:
On Mon, Apr 12, 2021 at 11:09:27PM -0700, Lucas De Marchi wrote:
Direction on gen9+ was to stop reading the straps and only rely on the
VBT for marking the port presence. This happened while dealing with
WaIgnoreDDIAStrap and instead
On Tue, Apr 13, 2021 at 02:24:13AM +0300, Imre Deak wrote:
> The addres-of op in front of an array is just an alias to using the
> array on its own, so drop the op.
>
> Signed-off-by: Imre Deak
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_dp_link_training.c | 2 +-
>
On Tue, Apr 13, 2021 at 02:24:12AM +0300, Imre Deak wrote:
> In case AUX failures happen unexpectedly during a modeset, the driver
> should still complete the modeset. In particular the driver should
> perform the link training sequence steps even in case of an AUX failure,
> as this sequence also
On Tue, Apr 13, 2021 at 05:02:40PM +0800, Jisheng Zhang wrote:
> I met below error during boot with i915 builtin if pass
> "i915.mitigations=off":
> [0.015589] Booting kernel: `off' invalid for parameter `i915.mitigations'
>
> The reason is slab subsystem isn't ready at that time, so kstrdup()
On Mon, Apr 12, 2021 at 11:09:27PM -0700, Lucas De Marchi wrote:
> Direction on gen9+ was to stop reading the straps and only rely on the
> VBT for marking the port presence. This happened while dealing with
> WaIgnoreDDIAStrap and instead of using it as a WA, it should now be the
> normal flow. Se
On Tuesday, April 13th, 2021 at 11:49 AM, Daniel Vetter
wrote:
> + * Note that userspace can check the DRM_CAP_ADDFB2_MODIFIERS driver
Prepend an ampersand like so and a hyperlink will be rendered:
Note that userspace can check the &DRM_CAP_ADDFB2_MODIFIERS driver
_
== Series Details ==
Series: drm/doc/rfc: i915 DG1 uAPI (rev2)
URL : https://patchwork.freedesktop.org/series/88958/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9963_full -> Patchwork_19924_full
Summary
---
**SUCCE
== Series Details ==
Series: series starting with [01/12] drm/arm: Don't set allow_fb_modifiers
explicitly
URL : https://patchwork.freedesktop.org/series/88999/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9963_full -> Patchwork_19922_full
===
On Tue, Apr 13, 2021 at 04:11:29PM +0200, Daniel Vetter wrote:
> On Tue, Apr 13, 2021 at 02:56:02PM +0300, Pekka Paalanen wrote:
> > On Tue, 13 Apr 2021 11:49:03 +0200
> > Daniel Vetter wrote:
> >
> > > It's very confusing for userspace to have to deal with inconsistencies
> > > here, and some dr
On Tue, Apr 13, 2021 at 01:54:00PM +0200, Lucas Stach wrote:
> Am Dienstag, dem 13.04.2021 um 11:49 +0200 schrieb Daniel Vetter:
> > It's very confusing for userspace to have to deal with inconsistencies
> > here, and some drivers screwed this up a bit. Most just ommitted the
> > format list when t
Am Dienstag, dem 13.04.2021 um 16:04 +0200 schrieb Daniel Vetter:
> On Tue, Apr 13, 2021 at 01:47:28PM +0200, Lucas Stach wrote:
> > Am Dienstag, dem 13.04.2021 um 11:48 +0200 schrieb Daniel Vetter:
> > > Since
> > >
> > > commit 890880ddfdbe256083170866e49c87618b706ac7
> > > Author: Paul Kocialko
On Tue, Apr 13, 2021 at 02:56:02PM +0300, Pekka Paalanen wrote:
> On Tue, 13 Apr 2021 11:49:03 +0200
> Daniel Vetter wrote:
>
> > It's very confusing for userspace to have to deal with inconsistencies
> > here, and some drivers screwed this up a bit. Most just ommitted the
> > format list when th
On Tue, Apr 13, 2021 at 01:47:28PM +0200, Lucas Stach wrote:
> Am Dienstag, dem 13.04.2021 um 11:48 +0200 schrieb Daniel Vetter:
> > Since
> >
> > commit 890880ddfdbe256083170866e49c87618b706ac7
> > Author: Paul Kocialkowski
> > Date: Fri Jan 4 09:56:10 2019 +0100
> >
> > drm: Auto-set all
== Series Details ==
Series: drm/i915: Fix "mitigations" parsing if i915 is builtin
URL : https://patchwork.freedesktop.org/series/88998/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9963_full -> Patchwork_19921_full
Summa
== Series Details ==
Series: drm/doc/rfc: i915 DG1 uAPI (rev2)
URL : https://patchwork.freedesktop.org/series/88958/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9963 -> Patchwork_19924
Summary
---
**SUCCESS**
No
== Series Details ==
Series: series starting with [v2,1/5] drm/connector: Create a helper to attach
the hdr_output_metadata property
URL : https://patchwork.freedesktop.org/series/89008/
State : failure
== Summary ==
Applying: drm/connector: Create a helper to attach the hdr_output_metadata
== Series Details ==
Series: drm/doc/rfc: i915 DG1 uAPI (rev2)
URL : https://patchwork.freedesktop.org/series/88958/
State : warning
== Summary ==
$ make htmldocs 2>&1 > /dev/null | grep i915
./drivers/gpu/drm/i915/gem/i915_gem_shrinker.c:102: warning: Function parameter
or member 'ww' not de
== Series Details ==
Series: drm/doc/rfc: i915 DG1 uAPI (rev2)
URL : https://patchwork.freedesktop.org/series/88958/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
8258e1583be6 drm/doc/rfc: i915 DG1 uAPI
-:19: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAI
== Series Details ==
Series: series starting with [1/3] dma-buf: Require VM_PFNMAP vma for mmap
URL : https://patchwork.freedesktop.org/series/89003/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9963 -> Patchwork_19923
Sum
== Series Details ==
Series: series starting with [1/3] dma-buf: Require VM_PFNMAP vma for mmap
URL : https://patchwork.freedesktop.org/series/89003/
State : warning
== Summary ==
$ make htmldocs 2>&1 > /dev/null | grep i915
./drivers/gpu/drm/i915/gem/i915_gem_shrinker.c:102: warning: Function
== Series Details ==
Series: series starting with [1/3] dma-buf: Require VM_PFNMAP vma for mmap
URL : https://patchwork.freedesktop.org/series/89003/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
8ed494629919 dma-buf: Require VM_PFNMAP vma for mmap
-:34: WARNING:TYPO_SPELLING:
== Series Details ==
Series: series starting with [01/12] drm/arm: Don't set allow_fb_modifiers
explicitly
URL : https://patchwork.freedesktop.org/series/88999/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9963 -> Patchwork_19922
=
== Series Details ==
Series: series starting with [01/12] drm/arm: Don't set allow_fb_modifiers
explicitly
URL : https://patchwork.freedesktop.org/series/88999/
State : warning
== Summary ==
$ make htmldocs 2>&1 > /dev/null | grep i915
./drivers/gpu/drm/i915/gem/i915_gem_shrinker.c:102: warni
From: Dave Stevenson
Now that we can export deeper colour depths, add in the signalling
for HDR metadata.
Signed-off-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
Changes from v1:
- Rebased on latest drm-misc-next tag
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 53 +
All the drivers that implement HDR output call pretty much the same
function to initialise the hdr_output_metadata property, and while the
creation of that property is in a helper, every driver uses the same
code to attach it.
Provide a helper for it as well
Reviewed-by: Harry Wentland
Reviewed-
All the drivers that support the HDR metadata property have a similar
function to compare the metadata from one connector state to the next,
and force a mode change if they differ.
All these functions run pretty much the same code, so let's turn it into
an helper that can be shared across those dr
Our driver while supporting HDR didn't send the proper colorimetry info
in the AVI infoframe.
Let's add the property needed so that the userspace can let us know what
the colorspace is supposed to be.
Signed-off-by: Maxime Ripard
---
Changes from v1:
- New patch
---
drivers/gpu/drm/vc4/vc4_
The intel driver uses the same logic to attach the Colorspace property
in multiple places and we'll need it in vc4 too. Let's move that common
code in a helper.
Signed-off-by: Maxime Ripard
---
Changes from v1:
- New patch
---
drivers/gpu/drm/drm_connector.c | 20 ++
== Series Details ==
Series: series starting with [01/12] drm/arm: Don't set allow_fb_modifiers
explicitly
URL : https://patchwork.freedesktop.org/series/88999/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
95d1b78648fe drm/arm: Don't set allow_fb_modifiers explicitly
-:8: ERR
== Series Details ==
Series: drm/i915: Fix "mitigations" parsing if i915 is builtin
URL : https://patchwork.freedesktop.org/series/88998/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9963 -> Patchwork_19921
Summary
---
== Series Details ==
Series: drm/i915/gvt: remove useless function
URL : https://patchwork.freedesktop.org/series/88996/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9963_full -> Patchwork_19920_full
Summary
---
**F
On Tue, 13 Apr 2021 11:49:03 +0200
Daniel Vetter wrote:
> It's very confusing for userspace to have to deal with inconsistencies
> here, and some drivers screwed this up a bit. Most just ommitted the
> format list when they meant to say that only linear modifier is
> allowed, but some also meant
Am Dienstag, dem 13.04.2021 um 11:49 +0200 schrieb Daniel Vetter:
> It's very confusing for userspace to have to deal with inconsistencies
> here, and some drivers screwed this up a bit. Most just ommitted the
> format list when they meant to say that only linear modifier is
> allowed, but some als
Am Dienstag, dem 13.04.2021 um 11:48 +0200 schrieb Daniel Vetter:
> Since
>
> commit 890880ddfdbe256083170866e49c87618b706ac7
> Author: Paul Kocialkowski
> Date: Fri Jan 4 09:56:10 2019 +0100
>
> drm: Auto-set allow_fb_modifiers when given modifiers at plane init
>
> this is done automati
Add an entry for the new uAPI needed for DG1.
v2(Daniel):
- include the overall upstreaming plan
- add a note for mmap, there are differences here for TTM vs i915
- bunch of other suggestions from Daniel
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc: Daniel Vetter
Cc: Dave Airlie
-
== Series Details ==
Series: drm/i915: Fix "mitigations" parsing if i915 is builtin
URL : https://patchwork.freedesktop.org/series/88998/
State : warning
== Summary ==
$ make htmldocs 2>&1 > /dev/null | grep i915
./drivers/gpu/drm/i915/gem/i915_gem_shrinker.c:102: warning: Function parameter
On Tue, Apr 13, 2021 at 11:49:01AM +0200, Daniel Vetter wrote:
> Since
>
> commit 890880ddfdbe256083170866e49c87618b706ac7
> Author: Paul Kocialkowski
> Date: Fri Jan 4 09:56:10 2019 +0100
>
> drm: Auto-set allow_fb_modifiers when given modifiers at plane init
>
> this is done automatical
On Mon, 12 Apr 2021, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Fix a couple of regressions due to the glk display version 9->10
> change. I *think* all the ones that slipped through involved
> either DISPLAY_VER==9 or DISPLAY_VER<10 checks. These three
> regressions are the ones I found thro
Hi
Am 13.04.21 um 11:49 schrieb Daniel Vetter:
shmem helpers seem a bit sloppy here by automatically rounding up when
actually creating the buffer, which results in under-reporting of what
we actually have. Caught by igt/vgem_basic tests.
Signed-off-by: Daniel Vetter
Drivers get it more wron
== Series Details ==
Series: drm/i915/gvt: remove useless function
URL : https://patchwork.freedesktop.org/series/88996/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9963 -> Patchwork_19920
Summary
---
**SUCCESS**
On Tue, Apr 13, 2021 at 11:29 AM Matthew Auld
wrote:
>
> On Mon, 12 Apr 2021 at 18:01, Daniel Vetter wrote:
> >
> > On Mon, Apr 12, 2021 at 6:08 PM Matthew Auld
> > wrote:
> > >
> > > On Mon, 12 Apr 2021 at 16:17, Daniel Vetter wrote:
> > > >
> > > > On Mon, Apr 12, 2021 at 10:05:25AM +0100, Ma
On Mon, 12 Apr 2021, Lucas De Marchi wrote:
> Like was done for the display part that parted ways with INTEL_GEN(),
> replacing with DISPLAY_VER(), do a similar conversion for the rest of
> the driver.
>
> v1.1: Remove .ko that was incorrectly added as part of patch 11, making it
> very big and no
== Series Details ==
Series: drm/i915/gvt: remove useless function
URL : https://patchwork.freedesktop.org/series/88996/
State : warning
== Summary ==
$ make htmldocs 2>&1 > /dev/null | grep i915
./drivers/gpu/drm/i915/gem/i915_gem_shrinker.c:102: warning: Function parameter
or member 'ww' no
shmem helpers seem a bit sloppy here by automatically rounding up when
actually creating the buffer, which results in under-reporting of what
we actually have. Caught by igt/vgem_basic tests.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 4 ++--
1 file changed, 2 inse
tldr; DMA buffers aren't normal memory, expecting that you can use
them like that (like calling get_user_pages works, or that they're
accounting like any other normal memory) cannot be guaranteed.
Since some userspace only runs on integrated devices, where all
buffers are actually all resident sys
Since
commit 890880ddfdbe256083170866e49c87618b706ac7
Author: Paul Kocialkowski
Date: Fri Jan 4 09:56:10 2019 +0100
drm: Auto-set allow_fb_modifiers when given modifiers at plane init
this is done automatically as part of plane init, if drivers set the
modifier list correctly. Which is th
Since
commit 890880ddfdbe256083170866e49c87618b706ac7
Author: Paul Kocialkowski
Date: Fri Jan 4 09:56:10 2019 +0100
drm: Auto-set allow_fb_modifiers when given modifiers at plane init
this is done automatically as part of plane init, if drivers set the
modifier list correctly. Which is th
Since
commit 890880ddfdbe256083170866e49c87618b706ac7
Author: Paul Kocialkowski
Date: Fri Jan 4 09:56:10 2019 +0100
drm: Auto-set allow_fb_modifiers when given modifiers at plane init
this is done automatically as part of plane init, if drivers set the
modifier list correctly. Which is th
Since
commit 890880ddfdbe256083170866e49c87618b706ac7
Author: Paul Kocialkowski
Date: Fri Jan 4 09:56:10 2019 +0100
drm: Auto-set allow_fb_modifiers when given modifiers at plane init
this is done automatically as part of plane init, if drivers set the
modifier list correctly. Which is th
Aside from deleting lots of code the real motivation here is to switch
the mmap over to VM_PFNMAP, to be more consistent with what real gpu
drivers do. They're all VM_PFNMP, which means get_user_pages doesn't
work, and even if you try and there's a struct page behind that,
touching it and mucking a
It's very confusing for userspace to have to deal with inconsistencies
here, and some drivers screwed this up a bit. Most just ommitted the
format list when they meant to say that only linear modifier is
allowed, but some also meant that only implied modifiers are
acceptable (because actually none
Since
commit 890880ddfdbe256083170866e49c87618b706ac7
Author: Paul Kocialkowski
Date: Fri Jan 4 09:56:10 2019 +0100
drm: Auto-set allow_fb_modifiers when given modifiers at plane init
this is done automatically as part of plane init, if drivers set the
modifier list correctly. Which is th
Since
commit 890880ddfdbe256083170866e49c87618b706ac7
Author: Paul Kocialkowski
Date: Fri Jan 4 09:56:10 2019 +0100
drm: Auto-set allow_fb_modifiers when given modifiers at plane init
this is done automatically as part of plane init, if drivers set the
modifier list correctly. Which is th
Setting the cap without the modifier list is very confusing to
userspace. Fix that by listing the ones we support explicitly.
Stable backport so that userspace can rely on this working in a
reasonable way, i.e. that the cap set implies IN_FORMATS is available.
Cc: sta...@vger.kernel.org
Cc: Pekka
Since
commit 890880ddfdbe256083170866e49c87618b706ac7
Author: Paul Kocialkowski
Date: Fri Jan 4 09:56:10 2019 +0100
drm: Auto-set allow_fb_modifiers when given modifiers at plane init
this is done automatically as part of plane init, if drivers set the
modifier list correctly. Which is th
Since
commit 890880ddfdbe256083170866e49c87618b706ac7
Author: Paul Kocialkowski
Date: Fri Jan 4 09:56:10 2019 +0100
drm: Auto-set allow_fb_modifiers when given modifiers at plane init
this is done automatically as part of plane init, if drivers set the
modifier list correctly. Which is th
Even when all we support is linear, make that explicit. Otherwise the
uapi is rather confusing.
Cc: sta...@vger.kernel.org
Cc: Pekka Paalanen
Cc: Liviu Dudau
Cc: Brian Starkey
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/arm/malidp_planes.c | 9 +++--
1 file changed, 7 insertions(+),
Since
commit 890880ddfdbe256083170866e49c87618b706ac7
Author: Paul Kocialkowski
Date: Fri Jan 4 09:56:10 2019 +0100
drm: Auto-set allow_fb_modifiers when given modifiers at plane init
this is done automatically as part of plane init, if drivers set the
modifier list correctly. Which is th
On Mon, 12 Apr 2021, Lucas De Marchi wrote:
> Make them independent so we can use DGFX_FEATURES more generically.
> For future platforms that do not use the GEN nomenclature we will define
> graphics, media and display separately, so we avoid setting graphics_ver
> with the GEN() macro.
>
> Signed
On Mon, 12 Apr 2021, Lucas De Marchi wrote:
> Since we are now converting from a single gen version to graphics_ver,
> media_ver and display_ver, add the last 2 when printing the device info.
>
> Signed-off-by: Lucas De Marchi
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_device
On Mon, 12 Apr 2021, Lucas De Marchi wrote:
> Now that it's not being used anymore, finish its removal. Like for
> gen_mask, we replace INTEL_GEN() and IS_GEN() macros to use the new
> field.
>
> Signed-off-by: Lucas De Marchi
> ---
> drivers/gpu/drm/i915/i915_drv.h | 10 +-
On Mon, 12 Apr 2021, Lucas De Marchi wrote:
> Replace gen with the new graphics_ver value and use GRAPHICS_VER()
> in those places.
>
> Signed-off-by: Lucas De Marchi
> ---
> .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 22 +--
> drivers/gpu/drm/i915/i915_drv.c |
On Mon, 12 Apr 2021, Lucas De Marchi wrote:
> Now that it's not used anywhere, remove it from struct
> intel_device_info. To allow a period in which code will be converted to
> the new macro, keep IS_GEN_RANGE() around, just redefining it to use
> the new fields. The size advantage from IS_GEN_RAN
On Mon, 12 Apr 2021, Lucas De Marchi wrote:
> Remove the remaining uses of INTEL_GEN_MASK() and the correspondent
> gen_mask in struct intel_device_info. This will allow the removal of
> gen_mask later since it's incompatible with the new per-IP versioning
> scheme.
>
> Signed-off-by: Lucas De Mar
1 - 100 of 117 matches
Mail list logo
