Quoting Ville Syrjala (2020-01-10 18:32:23)
> From: Ville Syrjälä
>
> intel_prepare_plane_fb() will always pin plane_state->hw.fb whenever
> it is present. We copy that from the master plane to the slave plane,
> but we fail to copy the corresponding ggtt view. Thus when it comes time
> to pin
== Series Details ==
Series: Add ops to intel_uc (rev3)
URL : https://patchwork.freedesktop.org/series/70716/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
bb5e4aea2877 drm/i915/uc: Add ops to intel_uc
-:142: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed
== Series Details ==
Series: drm/i915: Bump up CDCLK to eliminate underruns on TGL (rev4)
URL : https://patchwork.freedesktop.org/series/71760/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7721 -> Patchwork_16060
Summary
From: Ville Syrjälä
Let's do the intel_plane_copy_uapi_to_hw_state() before we bail out
due to both old and new uapi.crtc being NULL. This will drop the
reference to the old hw.fb for planes that are transitioning from
being a slave plane to simply being disabled.
Signed-off-by: Ville Syrjälä
From: Ville Syrjälä
intel_prepare_plane_fb() will always pin plane_state->hw.fb whenever
it is present. We copy that from the master plane to the slave plane,
but we fail to copy the corresponding ggtt view. Thus when it comes time
to pin the slave plane's fb we use some stale ggtt view left
Quoting Ville Syrjala (2020-01-10 18:32:27)
> From: Ville Syrjälä
>
> intel_prepare_plane_fb() bails early if there is no fb (or rather
> no obj, which is the same thing). intel_cleanup_plane_fb() does not.
> This means the steps performed by intel_cleanup_plane_fb() aren't
> balanced with with
On Fri, Jan 10, 2020 at 02:33:04PM +0530, Anshuamn Gupta wrote:
> 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
== Series Details ==
Series: drm/i915/gt: Validation rotated vma bounds are within the object (rev2)
URL : https://patchwork.freedesktop.org/series/71827/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
933176d41e65 drm/i915/gt: Validate rotated vma bounds are within the object
== Series Details ==
Series: Add ops to intel_uc (rev3)
URL : https://patchwork.freedesktop.org/series/70716/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7721 -> Patchwork_16059
Summary
---
**SUCCESS**
No
Quoting Ville Syrjala (2020-01-10 18:32:26)
> From: Ville Syrjälä
>
> Drop the redundant intel_ prefix from our atomic state variable.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 22 ++--
> 1 file changed, 11 insertions(+), 11
From: Ville Syrjälä
We've already pinned the vma and fence by the time we try to
deal with implicit fencing. Properly unpin the vma and fence
if the fence setup fails instead of just bailing straight out
from .prepare_fb(). As can be expected
drm_atomic_helper_prepare_planes() will not call
From: Ville Syrjälä
intel_prepare_plane_fb() bails early if there is no fb (or rather
no obj, which is the same thing). intel_cleanup_plane_fb() does not.
This means the steps performed by intel_cleanup_plane_fb() aren't
balanced with with what was done intel_prepare_plane_fb() if there
is no fb
From: Ville Syrjälä
Switch over to using explicit old/new planes states instead of
digging the old state out via plane->state. The main issue is that
plane->state will point to the uapi state which we generally don't
even want to look at.
Also it sets a bad example as using plane->state during
From: Ville Syrjälä
Drop the redundant intel_ prefix from our atomic state variable.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 22 ++--
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git
== Series Details ==
Series: drm/i915/gt: Validation rotated vma bounds are within the object (rev2)
URL : https://patchwork.freedesktop.org/series/71827/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7720 -> Patchwork_16056
== Series Details ==
Series: drm/i915/dsi: Parse the I2C element from the VBT MIPI sequence block
(rev3)
URL : https://patchwork.freedesktop.org/series/71581/
State : failure
== Summary ==
Applying: drm/i915/dsi: Parse the I2C element from the VBT MIPI sequence block
(v3)
Using index info
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
Reviewed-by: Chris Wilson
---
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
Reviewed-by: Chris Wilson
---
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
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
v3: reuse __uc_check_hw to avoid redundant comment
v4: forward declare
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
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 10
. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Chris-Wilson/drm-i915-gt-Push-context-state-allocation-earlier/20200110-090110
base
On Fri, 10 Jan 2020 17:57:22 +0100, Chris Wilson
wrote:
Quoting Michal Wajdeczko (2020-01-10 16:29:27)
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
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
TGL has now a table for RBR and HBR and another table for HBR2 over
combo phys. The HBR2 one has some small changes comparing to the ICL
one, so adding two new tables and adding a function to return TGL
combo phy tables.
v2:
- reordered the tgl_combo_phy_ddi_translations_dp_hbr2 to reduce diff
Quoting Michal Wajdeczko (2020-01-10 18:47:50)
> On Fri, 10 Jan 2020 17:57:22 +0100, Chris Wilson
> wrote:
>
> > Quoting Michal Wajdeczko (2020-01-10 16:29:27)
> >> Instead of spreading multiple conditionals across the uC code
> >> to find out current mode of uC operation, start using
Quoting Michal Wajdeczko (2020-01-10 16:29:30)
> 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
Series is
Quoting Ville Syrjala (2020-01-10 18:32:25)
> From: Ville Syrjälä
>
> Switch over to using explicit old/new planes states instead of
> digging the old state out via plane->state. The main issue is that
> plane->state will point to the uapi state which we generally don't
> even want to look at.
>
Renaming to match the BSpec and struct name.
BSpec: 20150
Cc: Jani Nikula
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_bios.c | 2 +-
drivers/gpu/drm/i915/display/intel_vbt_defs.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git
== Series Details ==
Series: Add ops to intel_uc (rev4)
URL : https://patchwork.freedesktop.org/series/70716/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7721 -> Patchwork_16061
Summary
---
**SUCCESS**
No
Quoting Ville Syrjala (2020-01-10 18:32:28)
> From: Ville Syrjälä
>
> We've already pinned the vma and fence by the time we try to
> deal with implicit fencing. Properly unpin the vma and fence
> if the fence setup fails instead of just bailing straight out
> from .prepare_fb(). As can be
On Wed, 2020-01-08 at 18:20 +0200, Ville Syrjälä wrote:
> On Wed, Jan 08, 2020 at 04:09:31PM +, Souza, Jose wrote:
> > On Wed, 2020-01-08 at 16:45 +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > When moving the pipe disable & co. function calls from
> > >
On Fri, Jan 10, 2020 at 10:11:23AM -0800, Vivek Kasireddy wrote:
> Parsing the i2c element is mainly done to transfer the payload from the
> MIPI sequence block to the relevant slave device. In some cases, the
> commands that are part of the payload can be used to turn on the backlight.
>
> This
== Series Details ==
Series: drm/i915/gt: Hold rpm wakeref before taking ggtt->vm.mutex
URL : https://patchwork.freedesktop.org/series/71889/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7720 -> Patchwork_16054
Summary
== Series Details ==
Series: i915: ggtt: include asm/smp.h
URL : https://patchwork.freedesktop.org/series/71892/
State : failure
== Summary ==
Applying: i915: ggtt: include asm/smp.h
Using index info to reconstruct a base tree...
M drivers/gpu/drm/i915/gt/intel_ggtt.c
Falling back to
== Series Details ==
Series: drm/i915: Bump up CDCLK to eliminate underruns on TGL (rev3)
URL : https://patchwork.freedesktop.org/series/71760/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7714_full -> Patchwork_16045_full
== Series Details ==
Series: series starting with [1/6] drm/i915: Make a copy of the ggtt view for
slave plane
URL : https://patchwork.freedesktop.org/series/71896/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7721 -> Patchwork_16058
== Series Details ==
Series: Add ops to intel_uc (rev4)
URL : https://patchwork.freedesktop.org/series/70716/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
2e1f188d8ce3 drm/i915/uc: Add ops to intel_uc
-:147: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed
On Fri, 10 Jan 2020 13:45:31 -0300
Arnaldo Carvalho de Melo wrote:
> Em Sat, Jan 11, 2020 at 12:52:13AM +0900, Masami Hiramatsu escreveu:
> > On Fri, 10 Jan 2020 15:02:34 +0100 Peter Zijlstra
> > wrote:
> > > Again, this only allows attaching to previously created kprobes, it does
> > > not
== Series Details ==
Series: drm/i915/dp/tgl+: Update combo phy vswing tables
URL : https://patchwork.freedesktop.org/series/71909/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7721 -> Patchwork_16062
Summary
---
On Fri, Jan 10, 2020 at 03:39:02PM -0800, José Roberto de Souza wrote:
> TGL has now a table for RBR and HBR and another table for HBR2 over
> combo phys. The HBR2 one has some small changes comparing to the ICL
> one, so adding two new tables and adding a function to return TGL
> combo phy
I don't think we've ever hit these new error codes, but they're
documented in the gen11 pcode document, so we might as well add them to
the handler.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/i915_reg.h | 2 ++
drivers/gpu/drm/i915/intel_sideband.c | 4
2 files changed, 6
tree: git://anongit.freedesktop.org/drm-intel for-linux-next
head: 1a8585bd774c4058038ad827c9e93847ff509cf3
commit: 742379c0c4001fd2a6e02005c1ffa1ff611b28fa [4/7] drm/i915: Start chopping
up the GPU error capture
config: x86_64-randconfig-s1-20200111 (attached as .config)
compiler: gcc-4.9
== Series Details ==
Series: drm/i915/vbt: Rename BDB_LVDS_POWER to BDB_LFP_POWER
URL : https://patchwork.freedesktop.org/series/71912/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7721 -> Patchwork_16063
Summary
---
== Series Details ==
Series: drm/i915/gen11: Add additional pcode status values
URL : https://patchwork.freedesktop.org/series/71915/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7721 -> Patchwork_16064
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.
>
>
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
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
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
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(-)
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 -
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
== 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!
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
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
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,
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
== 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 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
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
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
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.
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
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
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
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
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
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
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 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
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
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
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
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
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,
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().
>>>
>>>
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
>
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
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
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
== 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
---
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
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
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:
== 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
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
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
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)
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
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:
> > >
>
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
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
> +++
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
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,
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
> ---
>
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.
> ---
>
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
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'?
1 - 100 of 156 matches
Mail list logo
