On 2020-01-10 at 03:51:49 -0500, Matt Atwood wrote:
> The bspec tells us we need to set this bit to avoid potential underruns.
>
> Bspec: 33450
> Bspec: 33451
> Bspec: 33452
It would be nice to add index 7386 which is having the bit for PMRSP.
>
> Signed-off-by: Matt Atwood
> ---
> drivers/gpu/
VBLANK handlers in struct drm_driver are deprecated. Only legacy,
non-KMS drivers are supposed to used them. DRM drivers with kernel
modesetting are supposed to use VBLANK callbacks of the CRTC
infrastructure.
This patchset converts all DRM drivers to CRTC VBLANK callbacks and
cleans up struct drm
The new callback get_scanout_position() reads the current location of
the scanout process. The operation is currentyl located in struct
drm_driver, but really belongs to the CRTC. Drivers will be converted
in separate patches.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_vblank.c
The callback struct drm_driver.get_scanout_position() is deprecated in
favor of struct drm_crtc_helper_funcs.get_scanout_position(). Convert stm
over.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/stm/drv.c | 1 -
drivers/gpu/drm/stm/ltdc.c | 65 --
d
The callback get_vblank_timestamp() is currently located in struct
drm_driver, but really belongs into struct drm_crtc_funcs. Add an
equivalent there. Driver will be converted in separate patches.
The default implementation is drm_calc_vbltimestamp_from_scanoutpos().
The patch adds drm_crtc_calc_v
The callback struct drm_driver.get_scanout_position() is deprecated in
favor of struct drm_crtc_helper_funcs.get_scanout_position(). Convert
mem over.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 67 +++
drivers/gpu/drm/msm/disp/mdp5/mdp5_k
The callback struct drm_driver.get_scanout_position() is deprecated in
favor of struct drm_crtc_helper_funcs.get_scanout_position().
i915 doesn't use CRTC helpers. The patch duplicates the caller
drm_calc_vbltimestamp_from_scanoutpos() for i915, such that the callback
function is not needed.
Sign
VBLANK interrupts can be disabled immediately or with a delay, where the
latter is the default. The former option can be selected by setting
get_vblank_timestamp, and enabling vblank_disable_immediate in struct
drm_device.
The setup is only evaluated once when DRM initializes VBLANKs. Evaluating
t
The callback struct drm_driver.get_scanout_position() is deprecated in
favor of struct drm_crtc_helper_funcs.get_scanout_position(). Convert
nouveau over.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/nouveau/dispnv04/crtc.c | 1 +
drivers/gpu/drm/nouveau/dispnv50/head.c | 1 +
driv
VBLANK callbacks in struct drm_driver are deprecated in favor of
their equivalents in struct drm_crtc_funcs. Convert vkms over.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/vkms/vkms_crtc.c | 9 ++---
drivers/gpu/drm/vkms/vkms_drv.c | 1 -
drivers/gpu/drm/vkms/vkms_drv.h | 4
All users of struct drm_driver.get_scanout_position() have been
covnerted to the respective CRTC helper function. Remove the callback
from struct drm_driver.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_vblank.c | 13 ++---
include/drm/drm_drv.h| 52 --
VBLANK callbacks in struct drm_driver are deprecated in favor of
their equivalents in struct drm_crtc_funcs. Convert amdgpu over.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 3 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 4
drivers/gpu/drm/
VBLANK callbacks in struct drm_driver are deprecated in favor of
their equivalents in struct drm_crtc_funcs. Convert i915 over.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/i915/display/intel_display.c | 7 +++
drivers/gpu/drm/i915/i915_drv.c | 2 --
drivers/gpu/drm/i9
All non-legacy users of VBLANK functions in struct drm_driver have been
converted to use the respective interfaces in struct drm_crtc_funcs. The
remaining users of VBLANK callbacks in struct drm_driver are legacy drivers
with userspace modesetting.
There are no users left of get_vblank_timestamp()
VBLANK callbacks in struct drm_driver are deprecated in favor of
their equivalents in struct drm_crtc_funcs. Convert gma500 over.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/gma500/cdv_intel_display.c | 3 +++
drivers/gpu/drm/gma500/psb_drv.c | 4
drivers/gpu/drm/gma500
VBLANK callbacks in struct drm_driver are deprecated in favor of
their equivalents in struct drm_crtc_funcs. Convert nouvean over.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/nouveau/dispnv04/crtc.c | 3 +++
drivers/gpu/drm/nouveau/dispnv50/head.c | 4
drivers/gpu/drm/nouveau
VBLANK callbacks in struct drm_driver are deprecated in favor of
their equivalents in struct drm_crtc_funcs. Convert stm over.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/stm/drv.c | 1 -
drivers/gpu/drm/stm/ltdc.c | 1 +
2 files changed, 1 insertion(+), 1 deletion(-)
diff --git a/dri
The callback struct drm_driver.get_scanout_position() is deprecated in
favor of struct drm_crtc_helper_funcs.get_scanout_position(). Convert vc4
over.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/vc4/vc4_crtc.c | 12 +++-
drivers/gpu/drm/vc4/vc4_drv.c | 1 -
drivers/gpu/drm/vc4
VBLANK callbacks in struct drm_driver are deprecated in favor of
their equivalents in struct drm_crtc_funcs. Convert radeon over.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/radeon/radeon_display.c | 12 --
drivers/gpu/drm/radeon/radeon_drv.c | 7 --
drivers/gpu/drm/rad
The callback struct drm_driver.get_scanout_position() is deprecated in
favor of struct drm_crtc_helper_funcs.get_scanout_position(). Convert
radeon over.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/radeon/atombios_crtc.c | 1 +
drivers/gpu/drm/radeon/radeon_display.c | 13
The callback struct drm_driver.get_scanout_position() is deprecated in
favor of struct drm_crtc_helper_funcs.get_scanout_position(). Convert
amdgpu over.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 12
drivers/gpu/drm/amd/amdgpu/amdgpu_dr
VBLANK callbacks in struct drm_driver are deprecated in favor of
their equivalents in struct drm_crtc_funcs. Convert msm over.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 2 ++
drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c | 2 ++
drivers/gpu/drm/msm/disp/mdp5/
VBLANK callbacks in struct drm_driver are deprecated in favor of
their equivalents in struct drm_crtc_funcs. Convert sti over.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/sti/sti_crtc.c | 11 ---
drivers/gpu/drm/sti/sti_crtc.h | 2 --
drivers/gpu/drm/sti/sti_drv.c | 3 ---
3
VBLANK callbacks in struct drm_driver are deprecated in favor of
their equivalents in struct drm_crtc_funcs. Convert vc4 over.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/vc4/vc4_crtc.c | 1 +
drivers/gpu/drm/vc4/vc4_drv.c | 2 --
2 files changed, 1 insertion(+), 2 deletions(-)
diff -
VBLANK callbacks in struct drm_driver are deprecated in favor of
their equivalents in struct drm_crtc_funcs. Convert vmwgfx over.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 5 +
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 6 +++---
drivers/gpu/drm/vmwgfx/vmwgfx_km
== Series Details ==
Series: drm: Clean up VBLANK callbacks in struct drm_driver
URL : https://patchwork.freedesktop.org/series/71873/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
30f2cd6c8fad drm: Add get_scanout_position() to struct drm_crtc_helper_funcs
-:58: CHECK:OPEN_END
== Series Details ==
Series: drm: Clean up VBLANK callbacks in struct drm_driver
URL : https://patchwork.freedesktop.org/series/71873/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.6.0
Commit: drm: Add get_scanout_position() to struct drm_crtc_helper_funcs
Okay!
== Series Details ==
Series: drm: Clean up VBLANK callbacks in struct drm_driver
URL : https://patchwork.freedesktop.org/series/71873/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7715 -> Patchwork_16048
Summary
---
On Fri, 10 Jan 2020, Thomas Zimmermann wrote:
> The new callback get_scanout_position() reads the current location of
> the scanout process. The operation is currentyl located in struct
> drm_driver, but really belongs to the CRTC. Drivers will be converted
> in separate patches.
>
> Signed-off-by
Chris Wilson writes:
> Quoting Mika Kuoppala (2020-01-09 09:04:31)
>> Chris Wilson writes:
>>
>> > The shadow ring regs (ring->head, ring->tail) are meaningless in the
>> > post-mortem dump as they do not related to anything on HW. Remove them
>> > from the coredump.
>>
>> We have been dumping
Hi Chris,
On Thu, Jan 09, 2020 at 08:58:37AM +, Chris Wilson wrote:
> While this is technically the batch as executed by the HW (in part at
> least), it is confusing, and only used for a minority of gen.
>
> Signed-off-by: Chris Wilson
Acked-by: Andi Shyti
Andi
___
As we use the active state to keep the vma alive while we are reading
its contents during GPU error capture, we need to mark the
ring->vma as active during execution if we want to include the rinbuffer
in the error state.
Reported-by: Lionel Landwerlin
Fixes: b1e3177bd1d8 ("drm/i915: Coordinate i
As we use the active state to keep the vma alive while we are reading
its contents during GPU error capture, we need to mark the
context->state vma as active during execution if we want to include it
in the error state.
Reported-by: Lionel Landwerlin
Fixes: b1e3177bd1d8 ("drm/i915: Coordinate i91
Hi Chris,
On Thu, Jan 09, 2020 at 08:58:38AM +, Chris Wilson wrote:
> The list of requests from after the hang tells little about the hang
> itself, only how busy userspace was after the fact. As it pertains
> nothing to the HW state, drop it from the error state.
>
> Signed-off-by: Chris Wil
Currently we first to try to unbind the VMA (and lazily rebind on next
use) as an optimisation during restore_ggtt_mappings. Ideally, the only
objects in the GGTT upon resume are the pinned kernel objects which
can't be unbound and need to be restored. As the unbind interferes with
the plan to mark
From: Tvrtko Ursulin
We use PCI device path in the registered PMU name in order to distinguish
between multiple GPUs. But since tools/perf reserves a special meaning to
the colon character we need to transliterate them to something else. We
choose a dash.
Signed-off-by: Tvrtko Ursulin
Reported-
Quoting Tvrtko Ursulin (2020-01-10 11:11:26)
> From: Tvrtko Ursulin
>
> We use PCI device path in the registered PMU name in order to distinguish
> between multiple GPUs. But since tools/perf reserves a special meaning to
> the colon character we need to transliterate them to something else. We
>
On 10/01/2020 11:21, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-01-10 11:11:26)
From: Tvrtko Ursulin
We use PCI device path in the registered PMU name in order to distinguish
between multiple GPUs. But since tools/perf reserves a special meaning to
the colon character we need to transl
Quoting Tvrtko Ursulin (2020-01-10 11:27:55)
>
> On 10/01/2020 11:21, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2020-01-10 11:11:26)
> >> From: Tvrtko Ursulin
> >>
> >> We use PCI device path in the registered PMU name in order to distinguish
> >> between multiple GPUs. But since tools/perf
From: Tvrtko Ursulin
We use PCI device path in the registered PMU name in order to distinguish
between multiple GPUs. But since tools/perf reserves a special meaning to
dash and colon characters we need to transliterate them to something else.
We choose an underscore.
v2:
* Use strreplace. (Chr
On 10/01/2020 11:32, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-01-10 11:27:55)
On 10/01/2020 11:21, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-01-10 11:11:26)
From: Tvrtko Ursulin
We use PCI device path in the registered PMU name in order to distinguish
between multiple GPUs.
Chris Wilson writes:
> Access through the GGTT (iomap) into the vma does require the device to
> be awake. However, we often take the i915_vma_pin_iomap() as an early
> preparatory step that is long before we use the iomap. Asserting that
> the device is awake at pin time does not protect us, and
On Sun, 05 Jan 2020, Hans de Goede wrote:
> From: Derek Basehore
>
> Not every platform needs quirk detection for panel orientation, so
> split the drm_connector_init_panel_orientation_property into two
> functions. One for platforms without the need for quirks, and the
> other for platforms that
Quoting Tvrtko Ursulin (2020-01-10 11:32:53)
> From: Tvrtko Ursulin
>
> We use PCI device path in the registered PMU name in order to distinguish
> between multiple GPUs. But since tools/perf reserves a special meaning to
> dash and colon characters we need to transliterate them to something else
drm-misc-next-2020-01-10:
drm-misc-next for v5.6:
UAPI Changes:
Cross-subsystem Changes:
- Convert simple panel bindings to a template.
Core Changes:
- Revert drm-bridge-state changes, it causes a dependency error
between drm and drm_kms_helper.
- Fix when disabling crc's.
- Assorted Kconfig f
Since with multiple devices, we may have multiple different perf_pmu
each with their own type, we want to find the right one for the job.
The tests are run with a specific fd, from which we can extract the
appropriate bus-id and find the associated perf-type. The performance
monitoring tools are a
On Fri, 10 Jan 2020, Thomas Zimmermann wrote:
> The callback struct drm_driver.get_scanout_position() is deprecated in
> favor of struct drm_crtc_helper_funcs.get_scanout_position().
>
> i915 doesn't use CRTC helpers. The patch duplicates the caller
> drm_calc_vbltimestamp_from_scanoutpos() for i9
Hi
Am 10.01.20 um 12:59 schrieb Jani Nikula:
> On Fri, 10 Jan 2020, Thomas Zimmermann wrote:
>> The callback struct drm_driver.get_scanout_position() is deprecated in
>> favor of struct drm_crtc_helper_funcs.get_scanout_position().
>>
>> i915 doesn't use CRTC helpers. The patch duplicates the cal
The list of requests from after the hang tells little about the hang
itself, only how busy userspace was after the fact. As it pertains
nothing to the HW state, drop it from the error state.
Signed-off-by: Chris Wilson
Acked-by: Andi Shyti
---
drivers/gpu/drm/i915/i915_gpu_error.c | 75 +++-
In the near future, we will want to start a GPU error capture from a new
context, from inside the softirq region of a forced preemption. To do
so requires us to break up the monolithic error capture to provide new
entry points with finer control; in particular focusing on one
engine/gt, and being a
While this is technically the batch as executed by the HW (in part at
least), it is confusing, and only used for a minority of gen.
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
Acked-by: Andi Shyti
---
drivers/gpu/drm/i915/i915_gpu_error.c | 2 --
1 file changed, 2 deletions(-)
diff
The shadow ring regs (ring->head, ring->tail) are meaningless in the
post-mortem dump as they do not related to anything on HW. Remove them
from the coredump.
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gpu_error.c | 5 -
drivers/gpu/drm/i915/i915_gp
== Series Details ==
Series: series starting with [1/3] drm/i915/gt: Skip trying to unbind in
restore_ggtt_mappings
URL : https://patchwork.freedesktop.org/series/71876/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7716 -> Patchwork_16049
== Series Details ==
Series: Add support for mipi dsi cmd mode (rev5)
URL : https://patchwork.freedesktop.org/series/69290/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7712_full -> Patchwork_16037_full
Summary
---
From: Tvrtko Ursulin
Expose a list of clients with open file handles in sysfs.
This will be a basis for a top-like utility showing per-client and per-
engine GPU load.
Currently we only expose each client's pid and name under opaque numbered
directories in /sys/class/drm/card0/clients/.
For in
From: Tvrtko Ursulin
In GuC mode we are not receiving the context switch interrupts to be able
to accurately track context runtimes.
We can fallback to using PPHWSP counter updated by the GPU on context save.
QQQ
Downsides are: 1) we do not see currently executing batch and 2) with a
12MHz comm
From: Tvrtko Ursulin
Another re-spin of the per-client engine busyness series. Highlights from this
version:
* Two patches added on top of the series to provide the data in GuC mode.
(For warnings and limitations please read the respective commit messages.)
* Refactor to introduce a notion
From: Tvrtko Ursulin
Now that contexts keep their parent client reference counted, we can
remove separate struct pid reference owned by contexts in favour of the
one already held by the client.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 13 ---
From: Tvrtko Ursulin
GPU saves accumulated context runtime (in CS timestamp units) in PPHWSP
which will be useful for us in cases when we are not able to track context
busyness ourselves (like with GuC). Keep a copy of this in struct
intel_context from where it can be easily read even if the cont
From: Tvrtko Ursulin
We soon want to start answering questions like how much GPU time is the
context belonging to a client which exited still using.
To enable this we start tracking all context belonging to a client on a
separate list, plus we make contexts take a reference on their clients
file
From: Tvrtko Ursulin
Some clients have the DRM fd passed to them over a socket by the X server.
Grab the real client and pid when they create their first context and
update the exposed data for more useful enumeration.
v2:
* Do not leak the pid reference and borrow context idr_lock. (Chris)
v
From: Tvrtko Ursulin
Expose per-client and per-engine busyness under the previously added sysfs
client root.
The new files are one per-engine instance and located under the 'busy'
directory. Each contains a monotonically increasing nano-second resolution
times each client's jobs were executing o
From: Tvrtko Ursulin
Some customers want to know how much of the GPU time are their clients
using in order to make dynamic load balancing decisions.
With the hooks already in place which track the overall engine busyness,
we can extend that slightly to split that time between contexts.
v2: Fix
On Thu, Jan 09, 2020 at 09:19:07PM +0100, Mario Kleiner wrote:
> On Thu, Jan 9, 2020 at 7:24 PM Ville Syrjälä
> wrote:
>
> > On Thu, Jan 09, 2020 at 06:57:14PM +0100, Mario Kleiner wrote:
> > > On Thu, Jan 9, 2020 at 5:47 PM Ville Syrjälä <
> > ville.syrj...@linux.intel.com>
> > > wrote:
> > >
>
Quoting Tvrtko Ursulin (2020-01-10 13:30:42)
> +static ssize_t
> +show_client_name(struct device *kdev, struct device_attribute *attr, char
> *buf)
> +{
> + struct i915_drm_client *client =
> + container_of(attr, typeof(*client), attr.name);
> +
> + return snprintf(buf, P
Le ven. 10 janv. 2020 à 10:21, Thomas Zimmermann a écrit :
>
> VBLANK callbacks in struct drm_driver are deprecated in favor of
> their equivalents in struct drm_crtc_funcs. Convert sti over.
>
Hi Thomas,
Since you remove the last calls to sti_crtc functions from sti_drv.c I
think that the inclu
Quoting Tvrtko Ursulin (2020-01-10 13:30:43)
> From: Tvrtko Ursulin
>
> Some clients have the DRM fd passed to them over a socket by the X server.
>
> Grab the real client and pid when they create their first context and
> update the exposed data for more useful enumeration.
>
> v2:
> * Do not
Quoting Tvrtko Ursulin (2020-01-10 13:30:46)
> From: Tvrtko Ursulin
>
> Now that contexts keep their parent client reference counted, we can
> remove separate struct pid reference owned by contexts in favour of the
> one already held by the client.
>
> Signed-off-by: Tvrtko Ursulin
> ---
> dri
On Thu, 29 Aug 2019, Oleg Vasilev wrote:
> The helper should always be used.
>
> Reviewed-by: Emil Velikov
> Signed-off-by: Oleg Vasilev
> Cc: Ville Syrjälä
> Cc: intel-gfx@lists.freedesktop.org
Pushed patches 1-2 to drm-misc-next, thanks for the patches and review.
BR,
Jani.
> ---
> drive
Quoting Tvrtko Ursulin (2020-01-10 13:30:44)
> #endif /* __INTEL_CONTEXT_TYPES__ */
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> index 825c94e7ca0b..9a346c060469 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> +++ b/drivers/gp
On Fri, 10 Jan 2020, Thomas Zimmermann wrote:
> Hi
>
> Am 10.01.20 um 12:59 schrieb Jani Nikula:
>> On Fri, 10 Jan 2020, Thomas Zimmermann wrote:
>>> The callback struct drm_driver.get_scanout_position() is deprecated in
>>> favor of struct drm_crtc_helper_funcs.get_scanout_position().
>>>
>>> i9
When port is disabled due to modeset crtc disable sequence
or DPMS off, it eventually disables the HDCP encryption
keeping its content protection property to CP_ENABLED.
Since content protection property left at CP_ENABLED by
mistake, HDCP authentication is not attempted at next DDI
enable sequence
Quoting Tvrtko Ursulin (2020-01-10 13:30:47)
> +static ssize_t
> +show_client_busy(struct device *kdev, struct device_attribute *attr, char
> *buf)
> +{
> + struct i915_engine_busy_attribute *i915_attr =
> + container_of(attr, typeof(*i915_attr), attr);
> + struct list_he
Quoting Tvrtko Ursulin (2020-01-10 13:30:48)
> From: Tvrtko Ursulin
>
> GPU saves accumulated context runtime (in CS timestamp units) in PPHWSP
> which will be useful for us in cases when we are not able to track context
> busyness ourselves (like with GuC). Keep a copy of this in struct
> intel_
On 10/01/2020 13:58, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-01-10 13:30:47)
+static ssize_t
+show_client_busy(struct device *kdev, struct device_attribute *attr, char *buf)
+{
+ struct i915_engine_busy_attribute *i915_attr =
+ container_of(attr, typeof(*i915_attr)
Quoting Tvrtko Ursulin (2020-01-10 14:09:09)
>
> On 10/01/2020 13:58, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2020-01-10 13:30:47)
> >> +static ssize_t
> >> +show_client_busy(struct device *kdev, struct device_attribute *attr, char
> >> *buf)
> >> +{
> >> + struct i915_engine_busy_a
On Tue, 07 Jan 2020, Wambui Karuga wrote:
> This series begins the conversion to using the new struct drm_device
> based logging macros in drm/i915.
>
> Wambui Karuga (5):
> drm/i915: convert to using the drm_dbg_kms() macro.
> drm/i915: use new struct drm_device logging macros.
> drm/i915:
Chris Wilson writes:
> Now that we have moved the runtime-pm management out of
> intel_context_acctive_acquire, and that itself out of ce->ops->pin(),
> no
s/acctive/active
> explicit runtime pm wakeref is required in intel_context_pin().
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuop
We need to hold the runtime-pm wakeref to update the global PTEs (as
they exist behind a PCI BAR). However, some systems invoke ACPI during
runtime resume and so require allocations, which is verboten inside the
vm->mutex. Ergo, we must not use intel_runtime_pm_get() inside the
mutex, but lift the
On Fri, 10 Jan 2020 at 11:04, Chris Wilson wrote:
>
> Currently we first to try to unbind the VMA (and lazily rebind on next
> use) as an optimisation during restore_ggtt_mappings. Ideally, the only
> objects in the GGTT upon resume are the pinned kernel objects which
> can't be unbound and need t
On Thu, Jan 09, 2020 at 02:36:50PM +0300, Alexey Budankov wrote:
> On 08.01.2020 19:07, Peter Zijlstra wrote:
> > On Wed, Dec 18, 2019 at 12:25:35PM +0300, Alexey Budankov wrote:
> >> diff --git a/kernel/events/core.c b/kernel/events/core.c
> >> index 059ee7116008..d9db414f2197 100644
> >> --- a/k
Splitting up the i915_gem_gtt caused a build failure in some configurations:
drivers/gpu/drm/i915/gt/intel_ggtt.c: In function 'ggtt_restore_mappings':
drivers/gpu/drm/i915/gt/intel_ggtt.c:1239:3: error: implicit declaration of
function 'wbinvd_on_all_cpus'; did you mean 'wrmsr_on_cpus'?
[-Werro
Quoting Arnd Bergmann (2020-01-10 15:17:54)
> Splitting up the i915_gem_gtt caused a build failure in some configurations:
>
> drivers/gpu/drm/i915/gt/intel_ggtt.c: In function 'ggtt_restore_mappings':
> drivers/gpu/drm/i915/gt/intel_ggtt.c:1239:3: error: implicit declaration of
> function 'wbinv
On Fri, Jan 10, 2020 at 03:56:06PM +0200, Jani Nikula wrote:
> On Fri, 10 Jan 2020, Thomas Zimmermann wrote:
> > Hi
> >
> > Am 10.01.20 um 12:59 schrieb Jani Nikula:
> >> On Fri, 10 Jan 2020, Thomas Zimmermann wrote:
> >>> The callback struct drm_driver.get_scanout_position() is deprecated in
> >
== Series Details ==
Series: drm/i915/pmu: Do not use colon characters in PMU names (rev2)
URL : https://patchwork.freedesktop.org/series/71878/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7718 -> Patchwork_16050
Summary
On Fri, Jan 10, 2020 at 2:32 PM Ville Syrjälä
wrote:
> On Thu, Jan 09, 2020 at 09:19:07PM +0100, Mario Kleiner wrote:
> > On Thu, Jan 9, 2020 at 7:24 PM Ville Syrjälä <
> ville.syrj...@linux.intel.com>
> > wrote:
> >
> > > On Thu, Jan 09, 2020 at 06:57:14PM +0100, Mario Kleiner wrote:
> > > > On
On Fri, 10 Jan 2020 15:02:34 +0100
Peter Zijlstra wrote:
> On Thu, Jan 09, 2020 at 02:36:50PM +0300, Alexey Budankov wrote:
> > On 08.01.2020 19:07, Peter Zijlstra wrote:
> > > On Wed, Dec 18, 2019 at 12:25:35PM +0300, Alexey Budankov wrote:
>
> > >> diff --git a/kernel/events/core.c b/kernel/ev
== Series Details ==
Series: series starting with [CI,1/4] drm/i915: Start chopping up the GPU error
capture
URL : https://patchwork.freedesktop.org/series/71885/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
d117616075ef drm/i915: Start chopping up the GPU error capture
-:90:
Quite understandably, we bug out when asked to find a page that doesn't
belong to the object. However, we should report the error back to the
user long before we attempt the out-of-bound access! In this case, it is
insufficient validation on the rotated vma, with the simplest/cheapest
point for us
Quoting Chris Wilson (2020-01-10 15:53:34)
> Quite understandably, we bug out when asked to find a page that doesn't
> belong to the object. However, we should report the error back to the
> user long before we attempt the out-of-bound access! In this case, it is
> insufficient validation on the ro
On Thu, Jan 9, 2020 at 10:26 PM Harry Wentland wrote:
>
>
> On 2020-01-09 4:04 p.m., Mario Kleiner wrote:
>
> On Thu, Jan 9, 2020 at 8:49 PM Alex Deucher wrote:
>
>> On Thu, Jan 9, 2020 at 11:47 AM Mario Kleiner
>> wrote:
>> >
>> > On Thu, Jan 9, 2020 at 4:40 PM Alex Deucher
>> wrote:
>> >>
>>
On Thu, Jan 09, 2020 at 10:23:00PM +, Chris Wilson wrote:
> Long ago, we would only approach runtime-suspend if the GPU had been
> idle (no userspace submissions) for a second or two. However, since
> disabling automatic HW RC6 such a relaxed approach to runtime-suspend
> caused us to never ent
== Series Details ==
Series: series starting with [CI,1/4] drm/i915: Start chopping up the GPU error
capture
URL : https://patchwork.freedesktop.org/series/71885/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7718 -> Patchwork_16051
===
Quoting Imre Deak (2020-01-10 16:16:27)
> On Thu, Jan 09, 2020 at 10:23:00PM +, Chris Wilson wrote:
> > Long ago, we would only approach runtime-suspend if the GPU had been
> > idle (no userspace submissions) for a second or two. However, since
> > disabling automatic HW RC6 such a relaxed appr
== Series Details ==
Series: Per client engine busyness (rev3)
URL : https://patchwork.freedesktop.org/series/70977/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
f2a2ab0fb90e drm/i915: Expose list of clients in sysfs
-:61: WARNING:FILE_PATH_CHANGES: added, moved or deleted fil
uC sanitization is only meaningful if we are running with uC present
or enabled. Make this function part of the uc_ops.
Signed-off-by: Michal Wajdeczko
Cc: Joonas Lahtinen
Cc: Chris Wilson
Cc: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 10 ++
drivers/gpu/drm/i9
uC preparation and cleanup steps are only meaningful if we are
running with uC enabled. Make these functions part of the uc_ops.
Signed-off-by: Michal Wajdeczko
Cc: Joonas Lahtinen
Cc: Chris Wilson
Cc: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 12 +++-
drivers
Instead of spreading multiple conditionals across the uC code
to find out current mode of uC operation, start using predefined
set of function pointers that reflect that mode.
Begin with pair of init_hw/fini_hw functions that are responsible
for uC hardware initialization and cleanup.
v2: drop op
Firmware fetching and cleanup steps are only meaningful if we are
running with uC enabled. Make these functions part of the uc_ops.
Signed-off-by: Michal Wajdeczko
Cc: Joonas Lahtinen
Cc: Chris Wilson
Cc: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 12
driv
Instead of spreading multiple conditionals across the uC code
to find out current mode of uC operation, start using predefined
set of function pointers that reflect that mode.
v2: rebased, using macro to generate ops helpers
Michal Wajdeczko (4):
drm/i915/uc: Add ops to intel_uc
drm/i915/uc:
1 - 100 of 156 matches
Mail list logo
