On 2021.04.06 16:40:38 -0300, Jason Gunthorpe wrote:
> At some point there may have been some reason for this weird split in this
> driver, but today only the VFIO side is actually implemented.
>
> However, it got messed up at some point and mdev code was put in gvt.c and
> is pretending to be "ge
On 2021.04.06 16:40:39 -0300, Jason Gunthorpe wrote:
> intel_gvt_init_vgpu_type_groups() makes gvt->types 1:1 with the
> supported_type_groups array, so the type_group_id is also the index into
> gvt->types. Use it directly and remove the string matching.
>
> Reviewed-by: Kevin Tian
> Reviewed-by
== Series Details ==
Series: drm/i915: Fix glk display version regressions
URL : https://patchwork.freedesktop.org/series/88938/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9955_full -> Patchwork_19910_full
Summary
--
Avoid using apply_to_page_range() from modules, use the safer
verify_page_range() instead.
Signed-off-by: Peter Zijlstra (Intel)
---
drivers/xen/privcmd.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -946,9 +946,9 @@
Now that all module users of apply_to_page_range() have been removed,
unexport this function.
This is an unsafe function in that it gives direct access to the
page-tables.
Signed-off-by: Peter Zijlstra (Intel)
---
mm/memory.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/m
There are no modular in-tree users, remove the EXPORT.
This is an unsafe function in that it gives direct access to the
page-tables.
Signed-off-by: Peter Zijlstra (Intel)
---
mm/memory.c |1 -
1 file changed, 1 deletion(-)
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -2558,7 +2558,6 @@ int apply
Hi,
These patches remove the last few modular apply_to_page_range() users and
unexports these interface. Since these functions provide direct access to our
page-tables they're a prime target for nefarious activities.
These patches rely on the remap_pfn_range_notrack() patches from Christoph that
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 | 16
1 file changed, 8 insertions(+), 8 deletions(-)
--
Instead of relying on apply_to_page_range() being available to
modules, move its use into core kernel code and export it's
application.
Signed-off-by: Peter Zijlstra (Intel)
---
drivers/xen/gntdev-common.h |2 ++
drivers/xen/gntdev.c| 30 +-
drivers/xen/
Introduce and EXPORT a read-only counterpart to apply_to_page_range().
It only exposes the PTE value, not a pointer to the pagetables itself
and is thus quite a bit safer to export. A number of
apply_to_page_range() users can be converted to this primitive.
Signed-off-by: Peter Zijlstra (Intel)
Instead of relying on apply_to_page_range() being available to
modules, move its use into core kernel code and export it's
application.
NOTE: ideally we do: use_ptemod = !auto_translate_physmap &&
gnttab_map_avail_bits and remove this hack.
Signed-off-by: Peter Zijlstra (Intel)
---
arch/x86/inc
On Mon, Apr 12, 2021 at 10:00:13AM +0200, Peter Zijlstra wrote:
> There are no modular in-tree users, remove the EXPORT.
>
> This is an unsafe function in that it gives direct access to the
> page-tables.
>
> Signed-off-by: Peter Zijlstra (Intel)
Looks good,
Reviewed-by: Christoph Hellwig
___
On Mon, Apr 12, 2021 at 10:00:14AM +0200, Peter Zijlstra wrote:
> Instead of relying on apply_to_page_range() being available to
> modules, move its use into core kernel code and export it's
> application.
This doesn't exactly look great, but at least it contains the damage..
>
> NOTE: ideally w
On Mon, Apr 12, 2021 at 10:00:15AM +0200, Peter Zijlstra wrote:
> --- a/drivers/xen/grant-table.c
> +++ b/drivers/xen/grant-table.c
> @@ -1591,6 +1591,43 @@ int gnttab_init(void)
> }
> EXPORT_SYMBOL_GPL(gnttab_init);
>
> +#include
> +#include "gntdev-common.h"
Can't we keep the includes at th
Looks good,
Reviewed-by: Christoph Hellwig
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Mon, Apr 12, 2021 at 10:00:16AM +0200, Peter Zijlstra wrote:
> +extern int verify_page_range(struct mm_struct *mm,
No need for the extern here.
> +int verify_page_range(struct mm_struct *mm,
> + unsigned long addr, unsigned long size,
> + int (*fn)(pte_t pte
Looks good,
Reviewed-by: Christoph Hellwig
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Looks good,
Reviewed-by: Christoph Hellwig
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
== Series Details ==
Series: mm: Unexport apply_to_page_range()
URL : https://patchwork.freedesktop.org/series/88943/
State : failure
== Summary ==
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
DESCEND objtool
CHK include/generated/compile.h
Kernel: arch/x
On Mon, Apr 12, 2021 at 10:27:21AM +0200, Christoph Hellwig wrote:
> On Mon, Apr 12, 2021 at 10:00:15AM +0200, Peter Zijlstra wrote:
> > --- a/drivers/xen/grant-table.c
> > +++ b/drivers/xen/grant-table.c
> > @@ -1591,6 +1591,43 @@ int gnttab_init(void)
> > }
> > EXPORT_SYMBOL_GPL(gnttab_init);
>
Next batch of DG1 patches. With this we should now get a booting DG1 system with
the kernel selftests passing.
Anshuman Gupta (1):
drm/i915/oprom: Basic sanitization
Anusha Srivatsa (1):
drm/i915/lmem: Bypass aperture when lmem is available
CQ Tang (3):
drm/i915: Create stolen memory regio
From: Chris Wilson
RAPL provides an on-package power measurements which does not encompass
discrete graphics, so let's avoid using the igfx masurements when testing
dgfx. Later we will abstract the simple librapl interface over hwmon so
that we can verify basic power consumption scenarios.
Signe
From: Chris Wilson
If there is no mappable aperture, we cannot remap it for access, and the
selftest is void.
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
Reviewed-by: Imre Deak
---
drivers/gpu/drm/i915/selftests/i915_vma.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/driv
From: CQ Tang
Stolen memory is always allocated as physically contiguous pages, mark
the object flags as such.
Signed-off-by: CQ Tang
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drive
From: CQ Tang
Since stolen can now be device local-memory underneath, we should try to
enforce any min_page_size restrictions when allocating pages.
Signed-off-by: CQ Tang
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 7 ---
1 file changed, 4 insertions(+),
From: Mohammed Khajapasha
use local memory io BAR address for fbdev's fb_mmap() operation on
discrete, fbdev uses the physical address of our framebuffer for its
fb_mmap() fn.
Signed-off-by: Mohammed Khajapasha
---
drivers/gpu/drm/i915/display/intel_fbdev.c | 29 +-
1 file
From: Mohammed Khajapasha
Return EREMOTE value when frame buffer object is not backed by LMEM
for discrete. If Local memory is supported by hardware the framebuffer
backing gem objects should be from local memory.
Signed-off-by: Mohammed Khajapasha
---
drivers/gpu/drm/i915/display/intel_displa
From: CQ Tang
Add "REGION_STOLEN" device info to dg1, create stolen memory
region from upper portion of local device memory, starting
from DSMBASE.
v2:
- s/drm_info/drm_dbg; userspace likely doesn't care about stolen.
- mem->type is only setup after the region probe, so setting the name
Underneath it's the same stuff, so things like the PTE_LM bits for the
GTT should just keep working as-is.
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_lmem.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
b/
From: Matt Roper
Boot firmware performs memory training and health assessment during
startup. If the memory training fails, the firmware will consider the
GPU unusable and will instruct the punit to keep the GT powered down.
If this happens, our driver will be unable to communicate with the GT
(
From: Venkata Ramana Nayana
Use I915_MAP_WC when default state object is allocated in LMEM.
Signed-off-by: Venkata Ramana Nayana
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gt/shmem_utils.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/s
From: Venkata Sandeep Dhanalakota
Determine the possible coherent map type based on object location,
and if target has llc or if user requires an always coherent
mapping.
Cc: Matthew Auld
Cc: CQ Tang
Suggested-by: Michal Wajdeczko
Signed-off-by: Venkata Sandeep Dhanalakota
---
drivers/gpu/d
From: Anusha Srivatsa
In the scenario where local memory is available, we have
rely on CPU access via lmem directly instead of aperture.
v2:
gmch is only relevant for much older hw, therefore we can drop the
has_aperture check since it should always be present on such platforms.
(Chris)
Cc: Vil
From: Clint Taylor
Read OPROM SPI through MMIO and find VBT entry since we can't use
OpRegion and PCI mapping may not work on some systems due to the BIOS
not leaving the Option ROM mapped.
v2 by Jani:
- switch to intel_uncore_read/intel_uncore_write
Cc: Ville Syrjälä
Cc: Tomas Winkler
Cc: Jo
From: José Roberto de Souza
Commit c457d9cf256e ("drm/i915: Make sure we have enough memory
bandwidth on ICL") assumes that we always have a non-zero
dram_info->channels and uses it as a divisor. We need num memory
channels to be at least 1 for sane bw limits checking, even when PCode
returns 0,
From: Anshuman Gupta
Sanitize OPROM header, CPD signature and OPROM PCI version.
OPROM_HEADER, EXPANSION_ROM_HEADER and OPROM_MEU_BLOB structures
and PCI struct offsets are provided by GSC counterparts.
These are yet to be Documented in B.Spec.
After successful sanitization, extract VBT from opre
From: Clint Taylor
The PUNIT FW is currently returning 0 for all memory bandwidth
parameters. Read the values directly from MCHBAR offsets 0x5918 and
0x4000(4). This is a temporary WA until the PUNIT FW returns valid
values.
v2 (Lucas): Add error to log since this is fixed in new pcode available
We need to general our accessor for the page directories and tables from
using the simple kmap_atomic to support local memory, and this setup
must be done on acquisition of the backing storage prior to entering
fence execution contexts. Here we replace the kmap with the object
maping code that for
It's a requirement that for dgfx we place all the paging structures in
device local-memory.
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 5 -
drivers/gpu/drm/i915/gt/intel_gtt.c | 27 +--
drivers/gpu/drm/i915/gt/intel_gtt.h | 1 +
3 files
From: Clint Taylor
Use MCHBAR Gear_type information to compute memory bandwidth available
during MCHBAR calculations.
v2 by Jani:
- switch to intel_uncore_read/intel_uncore_write
Tested-by: Swati Sharma
Cc: Swati Sharma
Cc: Ville Syrjälä
Signed-off-by: Clint Taylor
Signed-off-by: Jani Nikul
On Mon, Apr 12, 2021 at 10:28:05AM +0200, Christoph Hellwig wrote:
> On Mon, Apr 12, 2021 at 10:00:16AM +0200, Peter Zijlstra wrote:
> > +extern int verify_page_range(struct mm_struct *mm,
>
> No need for the extern here.
It's consistent with the rest of the functions there. Also, I personally
li
On Mon, Apr 12, 2021 at 10:26:40AM +0200, Christoph Hellwig wrote:
> On Mon, Apr 12, 2021 at 10:00:14AM +0200, Peter Zijlstra wrote:
> > Instead of relying on apply_to_page_range() being available to
> > modules, move its use into core kernel code and export it's
> > application.
>
> This doesn't
On Mon, Apr 12, 2021 at 09:00:16AM -, Patchwork wrote:
> == Series Details ==
>
> Series: mm: Unexport apply_to_page_range()
> URL : https://patchwork.freedesktop.org/series/88943/
> State : failure
>
> == Summary ==
>
> CALLscripts/checksyscalls.sh
> CALLscripts/atomic/check-ato
Hi,
On 4/7/21 3:57 PM, Ville Syrjälä wrote:
> On Wed, Apr 07, 2021 at 03:50:35PM +0200, Hans de Goede wrote:
>> Hi,
>>
>> On 4/7/21 2:34 PM, Ville Syrjälä wrote:
>>> On Tue, Apr 06, 2021 at 03:57:32PM +0200, Hans de Goede wrote:
Hi,
On 3/25/21 12:48 PM, Hans de Goede wrote:
> Af
On Sun, 11 Apr 2021, Matt Roper wrote:
> On Wed, Apr 07, 2021 at 09:52:16PM -0700, 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" an
== Series Details ==
Series: More DG1 enabling
URL : https://patchwork.freedesktop.org/series/88947/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
525b7ae56cfd drm/i915/gt: Skip aperture remapping selftest where there is no
aperture
530e7443c201 drm/i915/selftests: Only query
== Series Details ==
Series: More DG1 enabling
URL : https://patchwork.freedesktop.org/series/88947/
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 'i915
On Wed, 07 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
== Series Details ==
Series: More DG1 enabling
URL : https://patchwork.freedesktop.org/series/88947/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9957 -> Patchwork_19912
Summary
---
**SUCCESS**
No regressions fou
On Mon, 12 Apr 2021, Jani Nikula wrote:
> On Wed, 07 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
Fix the following coccicheck warning:
drivers/gpu/drm/i915/display/intel_psr.c:1530:29-31: WARNING
!A || A && B is equivalent to !A || B
Signed-off-by: Qiheng Lin
---
drivers/gpu/drm/i915/display/intel_psr.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/
Add an entry for the new uAPI needed for DG1.
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc: Daniel Vetter
Cc: Dave Airlie
---
Documentation/gpu/rfc/i915_create_ext.c | 48 ++
.../gpu/rfc/i915_create_ext_placements.c | 19
Documentation/gpu/rfc/i915_region_query.c
On Mon, Apr 12, 2021 at 2:18 PM Matthew Auld wrote:
>
> Add an entry for the new uAPI needed for DG1.
>
> Signed-off-by: Matthew Auld
> Cc: Joonas Lahtinen
> Cc: Daniel Vetter
> Cc: Dave Airlie
> ---
> Documentation/gpu/rfc/i915_create_ext.c | 48 ++
> .../gpu/rfc/i915_create_ex
On 12.04.21 10:26, Christoph Hellwig wrote:
On Mon, Apr 12, 2021 at 10:00:14AM +0200, Peter Zijlstra wrote:
Instead of relying on apply_to_page_range() being available to
modules, move its use into core kernel code and export it's
application.
This doesn't exactly look great, but at least it c
== Series Details ==
Series: More DG1 enabling
URL : https://patchwork.freedesktop.org/series/88947/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9957_full -> Patchwork_19912_full
Summary
---
**FAILURE**
Serious
On Mon, Apr 12, 2021 at 10:05:08AM +0100, Matthew Auld wrote:
> From: Chris Wilson
>
> If there is no mappable aperture, we cannot remap it for access, and the
> selftest is void.
>
> Signed-off-by: Chris Wilson
> Reviewed-by: Matthew Auld
> Reviewed-by: Imre Deak
I guess subject should have
On Mon, Apr 12, 2021 at 10:05:14AM +0100, Matthew Auld wrote:
> From: Mohammed Khajapasha
>
> use local memory io BAR address for fbdev's fb_mmap() operation on
> discrete, fbdev uses the physical address of our framebuffer for its
> fb_mmap() fn.
>
> Signed-off-by: Mohammed Khajapasha
Sob mis
== Series Details ==
Series: drm/i915/display: remove redundant NULL check
URL : https://patchwork.freedesktop.org/series/88955/
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
On Mon, Apr 12, 2021 at 10:05:25AM +0100, Matthew Auld wrote:
> We need to general our accessor for the page directories and tables from
> using the simple kmap_atomic to support local memory, and this setup
> must be done on acquisition of the backing storage prior to entering
> fence execution co
== Series Details ==
Series: drm/i915/display: remove redundant NULL check
URL : https://patchwork.freedesktop.org/series/88955/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9960 -> Patchwork_19913
Summary
---
**SUC
== Series Details ==
Series: drm/doc/rfc: i915 DG1 uAPI
URL : https://patchwork.freedesktop.org/series/88958/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
e8f92650b42d drm/doc/rfc: i915 DG1 uAPI
-:14: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINER
== Series Details ==
Series: drm/doc/rfc: i915 DG1 uAPI
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 described
On Mon, 12 Apr 2021, Daniel Vetter wrote:
> And that's some serious wtf. Yes we've done some compile-time type
> casting automagic between i915_priv and dev in the past, and I think even
> that was bad taste. But it was justified with that we have these
> everywhere (especially in the mmio macros)
== Series Details ==
Series: drm/doc/rfc: i915 DG1 uAPI
URL : https://patchwork.freedesktop.org/series/88958/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9960 -> Patchwork_19914
Summary
---
**SUCCESS**
No regres
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 directories and tables from
> > using the simple kmap_atomic to support local memory, and this setup
> > must be done on acquisition
Running a Windows guest on a i915-GVTg_V4_2 from an HD 5500 IGD on
v5.12-rc6 results in host logs:
gvt: vgpu 1: lrm access to register (20c0)
gvt: vgpu 1: MI_LOAD_REGISTER_MEM handler error
gvt: vgpu 1: cmd parser error
0x0
0x29
gvt: vgpu 1: scan wa ctx error
gvt: vgpu 1: failed to submit des
On Mon, Apr 12, 2021 at 07:01:19PM +0300, Jani Nikula wrote:
> On Mon, 12 Apr 2021, Daniel Vetter wrote:
> > And that's some serious wtf. Yes we've done some compile-time type
> > casting automagic between i915_priv and dev in the past, and I think even
> > that was bad taste. But it was justified
On Fri, 2021-04-09 at 03:06 +, Patchwork wrote:
Patch Details
Series: series starting with [1/2] drm/i915/display: Implement Wa_14013723622
URL:https://patchwork.freedesktop.org/series/0/
State: success
Details:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19906/index.htm
On Mon, 2021-04-12 at 10:05 +0100, Matthew Auld wrote:
> From: José Roberto de Souza
>
> Commit c457d9cf256e ("drm/i915: Make sure we have enough memory
> bandwidth on ICL") assumes that we always have a non-zero
> dram_info->channels and uses it as a divisor. We need num memory
> channels to be
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 directories and tables from
> > > using the simple kmap_atomic to sup
Use an rwlock instead of spinlock for the global notifier lock
to reduce risk of contention in execbuf.
Protect object state with the object lock whenever possible rather
than with the global notifier lock
Don't take an explicit page_ref in userptr_submit_init() but rather
call get_pages() after
== Series Details ==
Series: drm/i915: Simplify userptr locking
URL : https://patchwork.freedesktop.org/series/88974/
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 d
== Series Details ==
Series: drm/i915/display: remove redundant NULL check
URL : https://patchwork.freedesktop.org/series/88955/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9960_full -> Patchwork_19913_full
Summary
--
== Series Details ==
Series: drm/i915: Simplify userptr locking
URL : https://patchwork.freedesktop.org/series/88974/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9962 -> Patchwork_19915
Summary
---
**SUCCESS**
N
== Series Details ==
Series: drm/doc/rfc: i915 DG1 uAPI
URL : https://patchwork.freedesktop.org/series/88958/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9960_full -> Patchwork_19914_full
Summary
---
**SUCCESS**
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. Stored function
pointer with stored (3rd) argument.
This doesn't se
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 Mon, Apr 12, 2021 at 02:40:24PM +0300, Jani Nikula wrote:
On Mon, 12 Apr 2021, Jani Nikula wrote:
On Wed, 07 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. Goin
test robot
---
url:
https://github.com/0day-ci/linux/commits/Matthew-Auld/More-DG1-enabling/20210412-171139
base: git://anongit.freedesktop.org/drm-intel for-linux-next
intel_bios.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/drivers/gpu/drm/i915/display/intel_bios.c
wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Matthew-Auld/More-DG1-enabling/20210412-171139
base: git://anongit.freedesktop.org
There's a lockdep splat that currently prevents booting on CI, fix it.
Maarten Lankhorst (2):
drm/i915: Remove asynchronous vma binding
drm/i915: Use trylock in shrinker for ggtt on bsw vt-d and bxt.
drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 13 +-
drivers/gpu/drm/i915/gem/i915_gem_sto
The stop_machine() lock may allocate memory, but is called inside
vm->mutex, which is taken in the shrinker. This will cause a lockdep
splat, as can be seen below:
<4>[ 462.585762] ==
<4>[ 462.585768] WARNING: possible circular locking dependen
Commit e3793468b466 ("drm/i915: Use the async worker to avoid reclaim
tainting the ggtt->mutex") moves the vma binding to dma_fence_work,
but dma_fence_work has has signalling fence semantics.
On braswell, we can call stop_machine inside fence_work, causing a splat
because memory allocation inside
== Series Details ==
Series: drm/i915: Simplify userptr locking
URL : https://patchwork.freedesktop.org/series/88974/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9962_full -> Patchwork_19915_full
Summary
---
**FAIL
== Series Details ==
Series: drm/i915: Fix for BSW and BXT vt-d.
URL : https://patchwork.freedesktop.org/series/88976/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
7a02bf8bdd14 drm/i915: Remove asynchronous vma binding
-:8: WARNING:REPEATED_WORD: Possible repeated word: 'has'
== Series Details ==
Series: drm/i915: Fix for BSW and BXT vt-d.
URL : https://patchwork.freedesktop.org/series/88976/
State : warning
== Summary ==
$ make htmldocs 2>&1 > /dev/null | grep i915
./drivers/gpu/drm/i915/gem/i915_gem_shrinker.c:104: warning: Function parameter
or member 'ww' not
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 includes port initialization steps. Not doing that
can leave the po
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
---
drivers/gpu/drm/i915/display/intel_dp_link_training.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_
== Series Details ==
Series: drm/i915: Fix for BSW and BXT vt-d.
URL : https://patchwork.freedesktop.org/series/88976/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9962 -> Patchwork_19916
Summary
---
**FAILURE**
== Series Details ==
Series: series starting with [1/2] drm/i915: Fix modesetting in case of
unexpected AUX timeouts
URL : https://patchwork.freedesktop.org/series/88982/
State : warning
== Summary ==
$ make htmldocs 2>&1 > /dev/null | grep i915
./drivers/gpu/drm/i915/gem/i915_gem_shrinker.c:
== Series Details ==
Series: series starting with [1/2] drm/i915: Fix modesetting in case of
unexpected AUX timeouts
URL : https://patchwork.freedesktop.org/series/88982/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9962 -> Patchwork_19917
===
On Mon, 12 Apr 2021 10:32:14 -0600
Alex Williamson wrote:
> Running a Windows guest on a i915-GVTg_V4_2 from an HD 5500 IGD on
> v5.12-rc6 results in host logs:
>
> gvt: vgpu 1: lrm access to register (20c0)
> gvt: vgpu 1: MI_LOAD_REGISTER_MEM handler error
> gvt: vgpu 1: cmd parser error
> 0x0
== Series Details ==
Series: series starting with [1/2] drm/i915: Fix modesetting in case of
unexpected AUX timeouts
URL : https://patchwork.freedesktop.org/series/88982/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9962_full -> Patchwork_19917_full
=
On 2021.04.12 19:23:47 -0600, Alex Williamson wrote:
> On Mon, 12 Apr 2021 10:32:14 -0600
> Alex Williamson wrote:
>
> > Running a Windows guest on a i915-GVTg_V4_2 from an HD 5500 IGD on
> > v5.12-rc6 results in host logs:
> >
> > gvt: vgpu 1: lrm access to register (20c0)
> > gvt: vgpu 1: MI_L
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
---
drivers/gpu/drm/i915/gt/selftest_workarounds.c | 10 +-
1 file changed, 5 insertions(+), 5 del
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-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/i915
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_RANGE() using a mask is
not that big as it has pretty li
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 later.
Signed-off-by: Lucas De Marchi
---
drivers
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 complete name, the shorhand
DISPLAY_VER() / GRAPHICS_VER / M
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 | 2 +-
drivers/gpu/drm/i915/intel_device_info.c | 2
1 - 100 of 119 matches
Mail list logo
