From: Matthew Auld
Similar to pwrite, we need pread for (better) support of non-GTT
backends.
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc: Abdiel Janulgue
Signed-off-by: Janusz Krzysztofik
Cc: Michal Wajdeczko
---
drivers/gpu/drm/i915/gem/i915_gem_object_types.h | 2 ++
drivers/gpu
We need dmabuf specific pread() callback utilizing dma-buf API,
otherwise GEM_PREAD IOCTL will no longer work with dma-buf backed
(i.e., PRIME imported) objects on hardware with no mappable aperture.
Signed-off-by: Janusz Krzysztofik
Cc: Daniele Ceraolo Spurio
Cc: Michal Wajdeczko
---
drivers
* By default, new contexts allow persistence.
> */
> #define I915_CONTEXT_PARAM_PERSISTENCE 0xb
> +
> +/*
> + *
> + * I915_CONTEXT_PARAM_RINGSIZE:
> + *
> + * Sets the size of the ringbuffer to use for logical ring contexts.
> + * Only possible to be set prio
On Friday, October 18, 2019 2:13:18 PM CEST Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Restore full symmetry in i915_driver_modeset_probe/remove
> URL : https://patchwork.freedesktop.org/series/68188/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from
On Friday, October 18, 2019 1:43:32 PM CEST Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Restore full symmetry in i915_driver_modeset_probe/remove
> URL : https://patchwork.freedesktop.org/series/68188/
> State : warning
>
> == Summary ==
>
> $ dim checkpatch origin/drm-tip
>
XME comment
provided by that commit. While being at it, update the name of
function mentioned as calling it out of sequence as that name has been
changed meanwhile by commit 78dae1ac35dd ("drm/i915: Propagate
"_remove" function name suffix down").
Suggested-by: Michal Wajdeczk
Hi Baolu,
On Friday, October 11, 2019 8:54:09 AM CEST Lu Baolu wrote:
> Hi Janusz,
>
> On 9/3/19 3:41 PM, Janusz Krzysztofik wrote:
> > Hi Baolu,
> >
> > On Tuesday, September 3, 2019 3:29:40 AM CEST Lu Baolu wrote:
> >> Hi Janusz,
> >>
> >>
Hi Chris,
On Wednesday, October 2, 2019 6:00:34 PM CEST Chris Wilson wrote:
> If we have a wedged GPU that we need to recover, but fail, add a taint
> for CI to pickup and schedule a reboot.
As your approach has been chosen by CI, FWIW:
Reviewed-by: Janusz Krzysztofik
Thanks,
, verify if we have GPU reset available
and fail with -EBUSY if not.
Suggested-by: Petri Latvala
Signed-off-by: Janusz Krzysztofik
Cc: Michał Wajdeczko
Cc: Michał Winiarski
Cc: Piotr Piórkowski
Cc: Tomasz Lis
Cc: Petri Latvala
Cc: Tvrtko Ursulin
Cc: Martin Peres
---
drivers/gpu/drm/i915
On Tuesday, October 1, 2019 9:08:48 PM CEST Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Conclude load -> probe naming convention switch
> URL : https://patchwork.freedesktop.org/series/67454/
> State : warning
>
> == Summary ==
>
> $ dim checkpatch origin/drm-tip
>
On Tuesday, October 1, 2019 9:32:32 PM CEST Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Conclude load -> probe naming convention switch
> URL : https://patchwork.freedesktop.org/series/67454/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_6986 ->
Hi Baolu,
On Tuesday, September 3, 2019 9:41:23 AM CEST Janusz Krzysztofik wrote:
> Hi Baolu,
>
> On Tuesday, September 3, 2019 3:29:40 AM CEST Lu Baolu wrote:
> > Hi Janusz,
> >
> > On 9/2/19 4:37 PM, Janusz Krzysztofik wrote:
> > >> I am not saying that
essage of 2/2, there are no such (Chris),
* add R-b (thanks Chris),
* use correct message ID of (also rerolled) IGT counterpart to be
tested with.
Janusz Krzysztofik (2):
drm/i915: Fix i915_inject_load_error() name to read *_probe_*
drm/i915: Rename "inject_load_failure"
ch to
the "probe" nomenclature.
Suggested-by: Joonas Lahtinen
Signed-off-by: Janusz Krzysztofik
Cc: Michał Wajdeczko
Cc: Michał Winiarski
Cc: Piotr Piórkowski
Cc: Tomasz Lis
Cc: Joonas Lahtinen
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_params.c | 2 +-
drivers/gpu/drm/i91
Suggested-by: Michał Wajdeczko
Signed-off-by: Janusz Krzysztofik
Cc: Michał Wajdeczko
Cc: Michał Winiarski
Cc: Piotr Piórkowski
Cc: Tomasz Lis
Cc: Joonas Lahtinen
Reviewed-by: Chris Wilson
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 2 +-
drivers/gpu/drm/i915/gt/uc/intel_huc.c
Hi Chris,
On Tuesday, October 1, 2019 3:57:27 PM CEST Chris Wilson wrote:
> Quoting Janusz Krzysztofik (2019-10-01 14:45:34)
> > Commit f2db53f14d3d ("drm/i915: Replace "_load" with "_probe"
> > consequently") deliberately left the name of the module
the "probe" nomenclature.
May affect custom user applications utilizing the old name.
Suggested-by: Joonas Lahtinen
Signed-off-by: Janusz Krzysztofik
Cc: Michał Wajdeczko
Cc: Michał Winiarski
Cc: Piotr Piórkowski
Cc: Tomasz Lis
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i91
ause I forgot to add a cover letter required for
successful joint testing when I was submitting to igt-dev list, sorry.
Thanks,
Janusz
Janusz Krzysztofik (2):
drm/i915: Fix i915_inject_load_error() name to read *_probe_*
drm/i915: Rename "inject_load_failure" module parameter
.../gp
Suggested-by: Michał Wajdeczko
Signed-off-by: Janusz Krzysztofik
Cc: Michał Wajdeczko
Cc: Michał Winiarski
Cc: Piotr Piórkowski
Cc: Tomasz Lis
Cc: Joonas Lahtinen
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 2 +-
drivers/gpu/drm/i915/gt/uc/intel_huc.c| 4 ++--
drivers/gp
t seems to be a safe choice.
Thanks,
Janusz
> Reported-by: Janusz Krzysztofik
> Signed-off-by: Chris Wilson
> Cc: Janusz Krzysztofik
> Cc: Daniele Ceraolo Spurio
> Cc: Ville Syrjälä
> Reviewed-by: Daniele Ceraolo Spurio #v1
> ---
> drivers/gpu/drm/i915/gt/intel_reset.c
On Monday, September 9, 2019 11:48:42 PM CEST Chris Wilson wrote:
> Quoting Chris Wilson (2019-09-07 09:39:52)
> > Quoting Daniele Ceraolo Spurio (2019-09-06 23:28:05)
> > >
> > >
> > > On 9/5/19 2:09 AM, Janusz Krzysztofik wrote:
> > > > Whe
Hi Chris,
On Tuesday, September 10, 2019 12:55:36 AM CEST Chris Wilson wrote:
> Unwedging the GPU requires a successful GPU reset before we restore the
> default submission, or else we may see residual context switch events
> that we were not expecting.
>
> Reported-by: Jan
Hi Fernando,
On Wednesday, August 28, 2019 2:45:57 AM CEST Fernando Pacheco wrote:
> It is not enough to check that uc supports GuC submission now
> that we can continue to load the driver after GuC initialization
> failure (support != enabled). Instead we should explicitly check
> that we
Hi Michał,
On Thursday, September 5, 2019 2:08:12 PM CEST Michal Wajdeczko wrote:
> On Thu, 05 Sep 2019 13:16:31 +0200, Janusz Krzysztofik
> wrote:
>
> > The driver always assumes active GuC submission mode if it is
> > supported. That's not true if GuC initiali
a subsequent
one may take quite a while.
Signed-off-by: Janusz Krzysztofik
---
lib/drmtest.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/lib/drmtest.c b/lib/drmtest.c
index c379a7b7..b73bc132 100644
--- a/lib/drmtest.c
+++ b/lib/drmtest.c
@@ -318,7 +318,8 @@ static void
enabled status.
Fixes: 356c484822e6 ("drm/i915/uc: Add explicit DISABLED state for firmware")
Signed-off-by: Janusz Krzysztofik
---
drivers/gpu/drm/i915/gt/uc/intel_uc.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.h
b/drive
intel_gt_reset().
Skip actual reset procedure if reset is disabled or not supported.
Suggested-by: Daniele Ceraolo Spurio
Signed-off-by: Janusz Krzysztofik
---
drivers/gpu/drm/i915/gt/intel_reset.c | 26 ++
1 file changed, 18 insertions(+), 8 deletions(-)
diff --git a/drivers
Hi Baolu,
On Tuesday, September 3, 2019 3:29:40 AM CEST Lu Baolu wrote:
> Hi Janusz,
>
> On 9/2/19 4:37 PM, Janusz Krzysztofik wrote:
> >> I am not saying that keeping data is not acceptable. I just want to
> >> check whether there are any other solutions.
>
Hi Baolu,
On Thursday, August 29, 2019 11:08:18 AM CEST Lu Baolu wrote:
> Hi,
>
> On 8/29/19 3:58 PM, Janusz Krzysztofik wrote:
> > Hi Baolu,
> >
> > On Thursday, August 29, 2019 3:43:31 AM CEST Lu Baolu wrote:
> >> Hi Janusz,
> >>
> >> On
Hi Baolu,
On Thursday, August 29, 2019 3:43:31 AM CEST Lu Baolu wrote:
> Hi Janusz,
>
> On 8/28/19 10:17 PM, Janusz Krzysztofik wrote:
> >> We should avoid kernel panic when a intel_unmap() is called against
> >> a non-existent domain.
> > Does that mean you
On Wednesday, August 28, 2019 2:56:18 AM CEST Lu Baolu wrote:
> Hi Janusz,
>
> On 8/27/19 5:35 PM, Janusz Krzysztofik wrote:
> > Hi Lu,
> >
> > On Monday, August 26, 2019 10:29:12 AM CEST Lu Baolu wrote:
> >> Hi Janusz,
> >>
> >> On
Hi Lu,
On Monday, August 26, 2019 10:29:12 AM CEST Lu Baolu wrote:
> Hi Janusz,
>
> On 8/26/19 4:15 PM, Janusz Krzysztofik wrote:
> > Hi Lu,
> >
> > On Friday, August 23, 2019 3:51:11 AM CEST Lu Baolu wrote:
> >> Hi,
> >>
> >> On
Hi Lu,
On Friday, August 23, 2019 3:51:11 AM CEST Lu Baolu wrote:
> Hi,
>
> On 8/22/19 10:29 PM, Janusz Krzysztofik wrote:
> > When a perfectly working i915 device is hot unplugged (via sysfs) and
> > hot re-plugged again, its dev->archdata.iommu field is not populated
off-by: Janusz Krzysztofik
---
drivers/iommu/intel-iommu.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 12d094d08c0a..7cdcd0595408 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -2477,6 +247
On Monday, August 12, 2019 10:23:29 PM CEST Daniele Ceraolo Spurio wrote:
>
> On 8/12/19 6:38 AM, Chris Wilson wrote:
> > Since execlista and the guc have diverged in their port tracking, we
> > cannot simply reuse the execlists cancellation code as it leads to
> > unbalanced reference counting.
If it ever happens trace_port() helper is called with NULL port 0,
kernel panic occurs. Fix it.
Signed-off-by: Janusz Krzysztofik
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers
The issue can be reproduced by interrupting "default-bomb" subtest of
"gem_ringfill" IGT, at least on simulation environment which is slow.
Janusz Krzysztofik (2):
drm/i915: Fix NULL pointer dereference in execlists' trace_ports()
drm/i915: Fix panic if nothing to p
-by: Janusz Krzysztofik
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index aa138aaf8743..1bba13ee1023 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt
ibly still active contexts
may be released prematurely, resulting in kernel panic.
Fix it by providing a local, modified copy of
execlists_cancel_port_requests() helper.
Fixes: 292ad25c22d9 ("drm/i915/guc: Implement reset locally")
Signed-off-by: Janusz Krzysztofik
---
Based on drm-intel-ne
On Thursday, July 11, 2019 8:55:05 AM CEST Chris Wilson wrote:
> Quoting Janusz Krzysztofik (2019-07-11 07:50:01)
> > Follow dim checkpatch recommendation so it doesn't complain on that now
> > and again on header file modifications.
> >
> > v2: Drop testing l
Similar to the "_release" and "_remove" cases, consequently replace
"_init" components of names of functions called from
i915_driver_probe() with "_probe" suffixes for better code readability.
Signed-off-by: Janusz Krzysztofik
Reviewed-by: Chris Wilson
Re
ce files have been suffixed with
"_driver_release" to avoid ambiguity with other possible .release entry
points.
v2: early_probe pairs better with late_release (Chris)
v3: fix typo in commit message (Joonas)
Suggested-by: Chris Wilson
Signed-off-by: Janusz Krzysztofik
Reviewed-by: Chr
Similar to the "_release" case, consistently replace mixed
"_cleanup"/"_fini"/"_fini_hw" components found in names of functions
called from i915_driver_remove() with "_remove" or "_driver_remove"
suffixes for better code readability.
Use the "_probe" nomenclature not only in i915_driver_probe() helper
name but also in other related function / variable names for
consistency. Only the userspace exposed name of a related module
parameter is left untouched.
Signed-off-by: Janusz Krzysztofik
Reviewed-by: Chris Wilson
Joonas)
* bundle with "drm/i915: Drop extern qualifiers from header
function prototypes", which the series depends on, as 1/6 (Chris)
Resubmitting with Reviewed-by: clauses added.
Janusz Krzysztofik (6):
drm/i915: Drop extern qualifiers from header function prototypes
drm
Follow dim checkpatch recommendation so it doesn't complain on that now
and again on header file modifications.
v2: drop testing leftover (Chris)
Signed-off-by: Janusz Krzysztofik
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_object.h | 2 +-
drivers/gpu/drm/i915/gvt/gtt.h
Current names of i915_driver_load/unload() functions originate in
legacy DRM stubs. Reduce nomenclature ambiguity by renaming them to
match their current use as helpers called from PCI entry points.
Suggested by: Chris Wilson
Signed-off-by: Janusz Krzysztofik
Reviewed-by: Chris Wilson
On Friday, July 12, 2019 1:12:52 PM CEST Janusz Krzysztofik wrote:
> Need for this was identified while working on split of driver unbind
> path into _remove() and _release() parts. Consistency in function
> naming has been recognized as helpful when trying to work out which
> ph
Use the "_probe" nomenclature not only in i915_driver_probe() helper
name but also in other related function / variable names for
consistency. Only the userspace exposed name of a related module
parameter is left untouched.
Signed-off-by: Janusz Krzysztofik
---
.../gpu/drm/i9
Follow dim checkpatch recommendation so it doesn't complain on that now
and again on header file modifications.
v2: drop testing leftover (Chris)
Signed-off-by: Janusz Krzysztofik
---
drivers/gpu/drm/i915/gem/i915_gem_object.h | 2 +-
drivers/gpu/drm/i915/gvt/gtt.h | 13
Similar to the "_release" and "_remove" cases, consequently replace
"_init" components of names of functions called from
i915_driver_probe() with "_probe" suffixes for better code readability.
Signed-off-by: Janusz Krzysztofik
-
Joonas)
* bundle with "drm/i915: Drop extern qualifiers from header
function prototypes", which the series depends on, as 1/6 (Chris)
Janusz Krzysztofik (6):
drm/i915: Drop extern qualifiers from header function prototypes
drm/i915: Rename "_load"/"_unloa
ce files have been suffixed with
"_driver_release" to avoid ambiguity with other possible .release entry
points.
v2: early_probe pairs better with late_release (Chris)
v3: fix typo in commit message (Joonas)
Suggested-by: Chris Wilson
Signed-off-by: Janusz Krzysztofik
---
drivers/gpu/d
Similar to the "_release" case, consistently replace mixed
"_cleanup"/"_fini"/"_fini_hw" components found in names of functions
called from i915_driver_remove() with "_remove" or "_driver_remove"
suffixes for better code readability.
Current names of i915_driver_load/unload() functions originate in
legacy DRM stubs. Reduce nomenclature ambiguity by renaming them to
match their current use as helpers called from PCI entry points.
Suggested by: Chris Wilson
Signed-off-by: Janusz Krzysztofik
---
drivers/gpu/drm/i915
On Friday, July 12, 2019 9:36:31 AM CEST Joonas Lahtinen wrote:
> Quoting Janusz Krzysztofik (2019-07-11 10:31:54)
> > Use the "_probe" nomenclature not only in i915_driver_probe() helper
> > name but also in other related function / variable names for
> > consiste
patch 6/6 "drm/i915: Rename "inject_load_failure" module
parameter" for now, it requires updates on user (IGT) side
* rebase on top of "drm/i915: Drop extern qualifiers from header
function prototypes"
Janusz Krzysztofik (5):
drm/i915: Rename "
Similar to the "_release" case, consistently replace mixed
"_cleanup"/"_fini"/"_fini_hw" components found in names of functions
called from i915_driver_remove() with "_remove" or "_driver_remove"
suffixes for better code readability.
ce files have been suffixed with
"_driver_release" to avoid ambiguity with other possible .release entry
points.
v2: early_probe pairs better with late_release (Chris)
Suggested-by: Chris Wilson
Signed-off-by: Janusz Krzysztofik
---
drivers/gpu/drm/i915/i915_drv.c | 33 ++
Similar to the "_release" and "_remove" cases, consequently replace
"_init" components of names of functions called from
i915_driver_probe() with "_probe" suffixes for better code readability.
Signed-off-by: Janusz Krzysztofik
-
Current names of i915_driver_load/unload() functions originate in
legacy DRM stubs. Reduce nomenclature ambiguity by renaming them to
match their current use as helpers called from PCI entry points.
Suggested by: Chris Wilson
Signed-off-by: Janusz Krzysztofik
---
drivers/gpu/drm/i915
Use the "_probe" nomenclature not only in i915_driver_probe() helper
name but also in other related function / variable names for
consistency. Only the userspace exposed name of a related module
parameter is left untouched.
Signed-off-by: Janusz Krzysztofik
---
.../gpu/drm/i9
Follow dim checkpatch recommendation so it doesn't complain on that now
and again on header file modifications.
v2: Drop testing leftover
Signed-off-by: Janusz Krzysztofik
---
drivers/gpu/drm/i915/gem/i915_gem_object.h | 2 +-
drivers/gpu/drm/i915/gvt/gtt.h | 13 +++---
drivers
Hi Chris,
On Wednesday, July 10, 2019 5:01:04 PM CEST Chris Wilson wrote:
> Quoting Janusz Krzysztofik (2019-07-10 15:52:39)
> > Follow dim checkpatch recommendation so it doesn't complain on that now
> > and again on header file modifications.
> >
> > Signed
Follow dim checkpatch recommendations so it doesn't complain now and
again on consistent modifications of i915_params.c
Signed-off-by: Janusz Krzysztofik
---
drivers/gpu/drm/i915/i915_params.c | 96 ++
1 file changed, 33 insertions(+), 63 deletions(-)
diff --git
Follow dim checkpatch recommendation so it doesn't complain on that now
and again on header file modifications.
Signed-off-by: Janusz Krzysztofik
---
drivers/gpu/drm/i915/gem/i915_gem_object.h | 2 +-
drivers/gpu/drm/i915/gvt/gtt.h | 13 +++---
drivers/gpu/drm/i915/i915_drv.h
On Wednesday, July 10, 2019 2:47:08 PM CEST Chris Wilson wrote:
> Quoting Janusz Krzysztofik (2019-07-10 13:36:25)
> > Need for this was identified while working on split of driver unbind
> > path into _remove() and _release() parts. Consistency in function
> > namin
Use the "probe" nomenclature for consistency with internally used names
of functions and variables.
Requires adjustment of IGT tests and possibly affects other user custom
applications.
Signed-off-by: Janusz Krzysztofik
---
drivers/gpu/drm/i915/i915_drv.c| 10 +-
drive
ce files have been suffixed with
"_driver_release" to avoid ambiguity with other possible .release entry
points.
Suggested-by: Chris Wilson
Signed-off-by: Janusz Krzysztofik
---
drivers/gpu/drm/i915/i915_drv.c | 33 +
drivers/gpu/drm/i915/i915_drv.h |
Similar to the "_release" case, consistently replace mixed
"_cleanup"/"_fini"/"_fini_hw" components found in names of functions
called from i915_driver_remove() with "_remove" or "_driver_remove"
suffixes for better code readability.
Similar to the "_release" and "_remove" cases, consequently replace
"_init" components of names of functions called from
i915_driver_probe() with "_probe" suffixes for better code readability.
Signed-off-by: Janusz Krzysztofik
-
Use the "_probe" nomenclature not only in i915_driver_probe() helper
name but also in other related function / variable names for
consistency. Only the userspace exposed name of a related module
parameter is left untouched.
Signed-off-by: Janusz Krzysztofik
---
.../gpu/drm/i9
Current names of i915_driver_load/unload() functions originate in
legacy DRM stubs. Reduce nomenclature ambiguity by renaming them to
match their current use as helpers called from PCI entry points.
Suggested by: Chris Wilson
Signed-off-by: Janusz Krzysztofik
---
drivers/gpu/drm/i915
-
how deep should we go down with renaming to not override meaningfull
function names. Please advise if you think still more deep renaming
makes sense.
Thanks,
Janusz
Janusz Krzysztofik (6):
drm/i915: Rename "_load"/"_unload" to match PCI entry points
drm/i915: Replace
eec99f5fd ("drm/i915: Avoid use-after-free in reporting create.size")
Signed-off-by: Janusz Krzysztofik
---
drivers/gpu/drm/i915/i915_gem.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 7ade42b8ec99..16bae5870d6
On Monday, June 10, 2019 8:49:38 AM CEST Petri Latvala wrote:
> On Fri, Jun 07, 2019 at 01:51:42PM +0200, Janusz Krzysztofik wrote:
> > - use SPDX license identifier,
>
>
> Why? We don't use those in IGT.
I must have had got an idea to change it from somewhere, unfortuna
From: Janusz Krzysztofik
There is a test which verifies unloading of i915 driver module but no test
exists that checks how a driver behaves when it gets unbound from a device
or when the device gets unplugged. Provide such test using sysfs
interface.
Two minimalistic subtests - "unbind-r
to be resolved before CI is happy with this new test.
[1]
https://cgit.freedesktop.org/drm/drm-tip/commit/?id=47bc28d7ee6d8378ba4451c43885cb3241302243
Janusz Krzysztofik (1):
tests: Add a new test for device hot unplug
tests/Makefile.sources | 1 +
tests/core_hotunplug.c | 222
On Monday, June 3, 2019 9:28:18 AM CEST Daniel Vetter wrote:
> On Thu, May 30, 2019 at 10:40:09AM +0100, Chris Wilson wrote:
> > Quoting Janusz Krzysztofik (2019-05-30 10:24:26)
> > > In order to support driver hot unbind, some cleanup operations, now
> > > performed
From: Janusz Krzysztofik
If a test calls a function which depends on availability of a specific
version of MMAP_GTT interface, an error may occur on unsupported hardware.
That may negatively affect results reported by a test framework even if
that test ignores the failure and succeedes
On Friday, May 31, 2019 11:35:39 AM CEST Chris Wilson wrote:
> Quoting Janusz Krzysztofik (2019-05-31 10:29:16)
> > From: Janusz Krzysztofik
> >
> > If a test calls a function which depends on availability of a specific
> > version of MMAP_GTT interface, an err
From: Janusz Krzysztofik
If a test calls a function which depends on availability of a specific
version of MMAP_GTT interface, an error may occur on unsupported hardware.
That may negatively affect results reported by a test framework even if
that test ignores the failure and succeedes
On Friday, May 31, 2019 10:55:46 AM CEST Chris Wilson wrote:
> Quoting Janusz Krzysztofik (2019-05-31 09:53:41)
> > Hi Chris,
> >
> > On Friday, May 31, 2019 10:39:47 AM CEST Chris Wilson wrote:
> > > Quoting Janusz Krzysztofik (2019-05-31 09:33:38)
&g
On Friday, May 31, 2019 10:41:36 AM CEST Chris Wilson wrote:
> Quoting Janusz Krzysztofik (2019-05-31 09:33:38)
> > From: Janusz Krzysztofik
>
> This is nothing to do with the mappable aperture version. This is the
> nee MMAP_GTT interface version.
> -Chris
>
Sorry for m
Hi Chris,
On Friday, May 31, 2019 10:39:47 AM CEST Chris Wilson wrote:
> Quoting Janusz Krzysztofik (2019-05-31 09:33:38)
> > From: Janusz Krzysztofik
> >
> > If a test calls a function which depends on availabiblity of a
> > supported mappable aperture, an error ma
From: Janusz Krzysztofik
If a test calls a function which depends on availabiblity of a
supported mappable aperture, an error may be reported by the kernel on
unsupported hardware. That may negatively affect results reported by a
test framework even if that test ignores the failure
as soon
as all references to the driver are put. As a result, those cleanups
will be now run on last drm_dev_put(), either still called from
pci_driver.remove() if all device file descriptors are already closed,
or on last drm_release() file operation.
Signed-off-by: Janusz Krzysztofik
Reviewed
unbind.
Thanks,
Janusz
Janusz Krzysztofik (1):
drm/i915: Split off pci_driver.remove() tail to drm_driver.release()
drivers/gpu/drm/i915/i915_drv.c | 17 +
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_gem.c | 10 +-
3 files changed, 23 insertions(+), 5
as soon
as all references to the driver are put. As a result, those cleanups
will be now run on last drm_dev_put(), either still called from
pci_driver.remove() if all device file descriptors are already closed,
or on last drm_release() file operation.
Signed-off-by: Janusz Krzysztofik
On Friday, May 17, 2019 4:32:35 PM CEST Chris Wilson wrote:
> Quoting Janusz Krzysztofik (2019-05-17 15:06:17)
> > From: Janusz Krzysztofik
> >
> > During i915_driver_unload(), GEM contexts are verified restrictively
> > inside i915_gem_fini() if they don't con
From: Janusz Krzysztofik
During i915_driver_unload(), GEM contexts are verified restrictively
inside i915_gem_fini() if they don't consume shared resources which
should be cleaned up before the driver is released. If those checks
don't result in kernel panic, one more check is performed
On Thursday, May 16, 2019 8:20:18 AM CEST Janusz Krzysztofik wrote:
> On Wednesday, May 15, 2019 5:00:40 PM CEST Chris Wilson wrote:
> > Janus, some old patches that may be of use for shutdown prior to kexec.
> > -Chris
>
> Hi Chris,
>
> Thanks for sharing.
>
From: Janusz Krzysztofik
The driver does not currently support unbinding from a device which is
in use. Since open file descriptors may still be pointing into kernel
memory where the device structures used to be, entirely correct kernel
panics protect the driver from being unbound as we should
Use drm_dev_unplug() to have device resources protected from user access
by DRM layer as soon as the driver is going to be unbound.
Janusz Krzysztofik (1):
drm/i915: Use drm_dev_unplug()
drivers/gpu/drm/i915/i915_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Since this patch
On Friday, April 5, 2019 7:37:04 PM CEST Chris Wilson wrote:
> Quoting Chris Wilson (2019-04-05 17:26:46)
>
> > Quoting Patchwork (2019-04-05 17:20:39)
> >
> > > == Series Details ==
> > >
> > > Series: Stop users from using the device on driver unbind
> > > URL :
From: Janusz Krzysztofik
If there are active users of a device during driver unbind, the driver
now panics on non-empty list of free cachelines.
By design, cachelines which are not in use are kept on a list of free
cachelines associated with a timeline and removed from that list either
when
As soon as a device is considered unplugged, not only prevent pending
users from accessing the device structures but also cancel all their
pending requests so all consumed resources can be cleaned up as soon
as possible.
Suggested-by: Chris Wilson
Signed-off-by: Janusz Krzysztofik
Reviewed
Use drm_dev_unplug() to have device resources protected from user access
by DRM layer as soon as the driver is going to be unbound. Also, cancel
all pending work so associated resources can be quickly released.
Janusz Krzysztofik (2):
drm/i915: Use drm_dev_unplug()
drm/i915: Mark GEM wedged
From: Janusz Krzysztofik
The driver does not currently support unbinding from a device which is
in use. Since open file descriptors may still be pointing into kernel
memory where the device structures used to be, entirely correct kernel
panics protect the driver from being unbound as we should
On Fri, 2019-04-05 at 13:20 +0100, Chris Wilson wrote:
> Quoting Janusz Krzysztofik (2019-04-05 13:13:31)
> > From: Janusz Krzysztofik
> >
> > If there are active users of a device during driver unbind, the
> > driver
> > now panics on non-empty list of
701 - 800 of 808 matches
Mail list logo
