== Series Details ==
Series: Simplify intel_setup_outputs
URL : https://patchwork.freedesktop.org/series/88988/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9962 -> Patchwork_19919
Summary
---
**WARNING**
Minor u
== Series Details ==
Series: drm/i915: Extend GEN renames to the rest of the driver (rev3)
URL : https://patchwork.freedesktop.org/series/88825/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9962_full -> Patchwork_19918_full
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;
> > +};
>
> Eeerg. This is likely to become an attack target itself.
Hi!
During the dma_resv conversion of the i915 driver, we've been using ww
transaction lock lists to keep track of ww_mutexes that are locked
during the transaction so that they can be batch unlocked at suitable
locations. Including also the LMEM/VRAM eviction we've ended up with
two static lists
Am 13.04.21 um 09:50 schrieb Thomas Hellström:
Hi!
During the dma_resv conversion of the i915 driver, we've been using ww
transaction lock lists to keep track of ww_mutexes that are locked
during the transaction so that they can be batch unlocked at suitable
locations. Including also the LMEM/
Hi,
On 4/13/21 9:57 AM, Christian König wrote:
Am 13.04.21 um 09:50 schrieb Thomas Hellström:
Hi!
During the dma_resv conversion of the i915 driver, we've been using ww
transaction lock lists to keep track of ww_mutexes that are locked
during the transaction so that they can be batch unlocke
== Series Details ==
Series: Simplify intel_setup_outputs
URL : https://patchwork.freedesktop.org/series/88988/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9962_full -> Patchwork_19919_full
Summary
---
**FAILURE**
Fix the following clang warning:
drivers/gpu/drm/i915/gvt/gtt.c:590:20: warning: unused function
'ppgtt_set_guest_root_entry' [-Wunused-function].
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong
---
drivers/gpu/drm/i915/gvt/gtt.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/d
On Mon, 12 Apr 2021, 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. See commit 885d3e5b6f0
On Mon, 12 Apr 2021, Lucas De Marchi wrote:
> Commit 989634fb49ad ("drm/i915/audio: set HDA link parameters in driver")
> added INTEL_GEN() in the display code, where it should actually be using
> DISPLAY_VER(). Switch to the new macro.
>
> Cc: Kai Vehmanen
> Signed-off-by: Lucas De Marchi
Revi
On Mon, 12 Apr 2021, Lucas De Marchi wrote:
> The macro we use to check is called DISPLAY_VER(). While using this
> macro and the new ones being added in following changes I made the
> mistake multiple times when mixing both "ver" and "version". Although
> it's usually better to prefer the complet
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, Matthew Auld wrote:
> > > > We need to general our accessor for the page d
On Mon, 12 Apr 2021, Lucas De Marchi wrote:
> Like it was done in
> commit 01eb15c9165e ("drm/i915: Add DISPLAY_VER() and related macros")
> add the correspondent macros for graphics and media. Going forward we
> will prefer checking the versions for the specific IPs (graphics, media
> and display
On Mon, 12 Apr 2021, Lucas De Marchi wrote:
> While converting the rest of the driver to use GRAPHICS_VER() and
> MEDIA_VER(), following what was done for display, some discussions went
> back on what we did for display:
>
> 1) Why is the == comparison special that deserves a separate
>
On Mon, 12 Apr 2021, Lucas De Marchi wrote:
> Start using the new fields graphics_version for the previous gen checks.
> Here we rename the "gen" field and replace the comparisons using it to
> start using the new GRAPHICS_VER(). Other uses of INTEL_GEN() were left
> as is for automatic conversion
On Mon, 12 Apr 2021, Lucas De Marchi wrote:
> Since its introduction 2 years ago, we never used the mask to span more
> than one gen. Replace gen_mask a single number and start using the new
> GRAPHICS_VER().
>
> Signed-off-by: Lucas De Marchi
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/
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()
returns NULL. Fix this issue by using stack var instead of kstrdup().
F
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
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:
> 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 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:
> 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:
> 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
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
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
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
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
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
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
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
== 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
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
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
== 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**
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
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
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
== 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
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
-
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
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
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
== 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
== 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: 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
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 ++
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_
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
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-
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 +
== 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
== 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 [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 [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 : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9963 -> Patchwork_19923
Sum
== 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: 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: 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 : success
== Summary ==
CI Bug Log - changes from CI_DRM_9963 -> Patchwork_19924
Summary
---
**SUCCESS**
No
== 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
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
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
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 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
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
== 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
===
== 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
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
_
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 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 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 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 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
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 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
== 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:
== 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
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 : success
== Summary ==
CI Bug Log - changes from CI_DRM_9963 -> Patchwork_19926
Summa
== 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
=
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
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
-
== 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
== 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 : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9964 -> Patchwork_19927
Summary
---
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
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ä
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ä
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ä
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
1 - 100 of 117 matches
Mail list logo
