== Series Details ==
Series: drm/i915: Split a setting of MSA to MST and SST (rev3)
URL : https://patchwork.freedesktop.org/series/69092/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7288_full -> Patchwork_15183_full
== Series Details ==
Series: series starting with [CI,1/5] drm: Move EXPORT_SYMBOL_FOR_TESTS_ONLY
under a separate Kconfig
URL : https://patchwork.freedesktop.org/series/69147/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7288_full -> Patchwork_15182_full
== Series Details ==
Series: drm/i915: Expand documentation for gen12 DP pre-enable sequence
URL : https://patchwork.freedesktop.org/series/69146/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7288_full -> Patchwork_15181_full
== Series Details ==
Series: series starting with [v2,1/2] drm/i915/bios: store child devices in a
list
URL : https://patchwork.freedesktop.org/series/69143/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7288_full -> Patchwork_15179_full
== Series Details ==
Series: Refactor Gen11+ SAGV support (rev10)
URL : https://patchwork.freedesktop.org/series/68028/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7288_full -> Patchwork_15178_full
Summary
---
== Series Details ==
Series: drm/fbdev: Fallback to non tiled mode if all tiles not present (rev2)
URL : https://patchwork.freedesktop.org/series/68838/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7299 -> Patchwork_15202
In case of tiled displays, if we hotplug just one connector,
fbcon currently just selects the preferred mode and if it is
tiled mode then that becomes a problem if rest of the tiles are
not present.
So in the fbdev driver on hotplug when we probe the client modeset,
if we dont find all the
== Series Details ==
Series: mdev based hardware virtio offloading support
URL : https://patchwork.freedesktop.org/series/69135/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7288_full -> Patchwork_15176_full
Summary
== Series Details ==
Series: drm/i915: do not warn late about hdmi on port A
URL : https://patchwork.freedesktop.org/series/69226/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7299 -> Patchwork_15201
Summary
---
Check that if two contexts (one high priority, one low) share the same
buffer that has taken a page fault that we do not create an implicit
dependency between the two contexts for servicing that page fault and
binding the vma.
Signed-off-by: Chris Wilson
---
tests/i915/gem_exec_schedule.c | 154
== Series Details ==
Series: series starting with [1/3] drm/i915/bios: rename bios to oprom when
mapping pci rom
URL : https://patchwork.freedesktop.org/series/69220/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7299 -> Patchwork_15200
The warning should be just a warning. Where it is currently is wrong
since we already registered the connector on drm, meaning it dies later
on a NULL pointer deref if the VBT-overriding we have is removed. Move
the warning up.
Signed-off-by: Lucas De Marchi
---
Quoting Daniel Vetter (2019-11-08 21:13:13)
> On Fri, Nov 8, 2019 at 9:49 PM Chris Wilson wrote:
> >
> > One of the hardest priority inversion tasks to both handle and to
> > simulate in testing is inversion due to resource contention. The
> > challenge is that a high priority context should
oprom is actually a better name to use when using
pci_map_rom(). "bios" is way too generic and confusing.
Signed-off-by: Lucas De Marchi
Reviewed-by: Jani Nikula
Link:
https://patchwork.freedesktop.org/patch/msgid/20191108003602.33526-2-lucas.demar...@intel.com
---
When we map the VBT through pci_map_rom() we may not be allowed
to simply discard the address space and go on reading the memory.
That doesn't work on my test system, but by dumping the rom via
sysfs I can can get the correct vbt. So change our find_vbt() to do
the same as done by pci_read_rom(),
When we call intel_bios_is_valid_vbt(), size may not actually be the
size of the VBT, but rather the size of the blob the VBT is contained
in. For example, when mapping the PCI oprom, size will be the entire
oprom size. We don't want to read beyond what is reported to be the
VBT. So make sure we
On Fri, Nov 8, 2019 at 9:49 PM Chris Wilson wrote:
>
> One of the hardest priority inversion tasks to both handle and to
> simulate in testing is inversion due to resource contention. The
> challenge is that a high priority context should never be blocked by a
> low priority context, even if both
On Fri, Nov 08, 2019 at 11:02:46PM +0200, Ville Syrjälä wrote:
On Fri, Nov 08, 2019 at 12:14:05PM -0800, Lucas De Marchi wrote:
On Fri, Nov 08, 2019 at 09:19:15PM +0200, Ville Syrjälä wrote:
>On Fri, Nov 08, 2019 at 10:18:52AM -0800, Lucas De Marchi wrote:
>> On Fri, Nov 08, 2019 at 01:14:03PM
On Fri, Nov 08, 2019 at 12:14:05PM -0800, Lucas De Marchi wrote:
> On Fri, Nov 08, 2019 at 09:19:15PM +0200, Ville Syrjälä wrote:
> >On Fri, Nov 08, 2019 at 10:18:52AM -0800, Lucas De Marchi wrote:
> >> On Fri, Nov 08, 2019 at 01:14:03PM +0200, Jani Nikula wrote:
> >> >On Thu, 07 Nov 2019, Lucas
pi-ringfull uses 2 contexts that share a buffer. The intent was that the
contexts were independent, but it was the effect of the global lock held
by the low priority client that prevented the high priority client from
executing. I began to add a second variant where there was a shared
resource
One of the hardest priority inversion tasks to both handle and to
simulate in testing is inversion due to resource contention. The
challenge is that a high priority context should never be blocked by a
low priority context, even if both are starving for resources --
ideally, at least for some RT
Register a userspace fault handler for a memory region that we also pass
to the GPU via userptr, and make sure the pagefault is properly serviced
before we execute.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
tests/i915/gem_userptr_blits.c | 119 -
1 file
== Series Details ==
Series: drm/i915/userptr: Track gup locked track
URL : https://patchwork.freedesktop.org/series/69218/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7299 -> Patchwork_15199
Summary
---
== Series Details ==
Series: drm/i915/gem: Silence sparse for RCU protection inside the constructor
URL : https://patchwork.freedesktop.org/series/69119/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7285_full -> Patchwork_15172_full
On Fri, Nov 08, 2019 at 09:19:15PM +0200, Ville Syrjälä wrote:
On Fri, Nov 08, 2019 at 10:18:52AM -0800, Lucas De Marchi wrote:
On Fri, Nov 08, 2019 at 01:14:03PM +0200, Jani Nikula wrote:
>On Thu, 07 Nov 2019, Lucas De Marchi wrote:
>> When we are mapping the VBT through pci_map_rom() we may
Enable gup to retry and fault the pages outside of the mmap_sem lock in
our worker. As we are inside our worker, outside of any critical path,
we can allow the mmap_sem lock to be dropped in order to service a page
fault; this in turn allows the mm to populate the page using a slow
fault handler.
== Series Details ==
Series: drm/i915: Show guilty context name on GPU reset
URL : https://patchwork.freedesktop.org/series/69217/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7299 -> Patchwork_15198
Summary
---
On Fri, Nov 08, 2019 at 10:18:52AM -0800, Lucas De Marchi wrote:
> On Fri, Nov 08, 2019 at 01:14:03PM +0200, Jani Nikula wrote:
> >On Thu, 07 Nov 2019, Lucas De Marchi wrote:
> >> When we are mapping the VBT through pci_map_rom() we may not be allowed
> >> to simply discard the address space and
We mention that we are resetting the GPU, and dump the device state for
post mortem debugging. However, while that dump contains the active
processes and the one flagged as causing the error, we do not always
include that information in dmesg. Include the name of the guilty
process in dmesg for
pi-ringfull uses 2 contexts that share a buffer. The intent was that the
contexts were independent, but it was the effect of the global lock held
by the low priority client that prevented the high priority client from
executing. I began to add a second variant where there was a shared
resource
== Series Details ==
Series: drm/i915/dsi: enable DSC
URL : https://patchwork.freedesktop.org/series/69202/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7299 -> Patchwork_15197
Summary
---
**SUCCESS**
No
On Fri, Nov 08, 2019 at 01:14:03PM +0200, Jani Nikula wrote:
On Thu, 07 Nov 2019, Lucas De Marchi wrote:
When we are mapping the VBT through pci_map_rom() we may not be allowed
to simply discard the address space and go on reading the memory. After
checking on my test system that dumping the
== Series Details ==
Series: drm/i915/dsi: enable DSC
URL : https://patchwork.freedesktop.org/series/69202/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
a5c514d75474 drm/i915/bios: use a flag for vbt hdmi level shift presence
af24a1b0a92c drm/i915/bios: store child devices in
== Series Details ==
Series: drm/i915: Gamma cleanups (rev2)
URL : https://patchwork.freedesktop.org/series/69136/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7299 -> Patchwork_15196
Summary
---
**SUCCESS**
No
== Series Details ==
Series: drm/i915: Gamma cleanups (rev2)
URL : https://patchwork.freedesktop.org/series/69136/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.6.0
Commit: drm: Inline drm_color_lut_extract()
+./include/drm/drm_color_mgmt.h:48:28: warning: shift
== Series Details ==
Series: drm/i915: Gamma cleanups (rev2)
URL : https://patchwork.freedesktop.org/series/69136/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
21be37521e2e drm: Inline drm_color_lut_extract()
54271b0bb942 drm/i915: Polish CHV .load_luts() a bit
08381a7f1283
== Series Details ==
Series: drm/i915: Enable second dbuf slice for ICL and TGL (rev3)
URL : https://patchwork.freedesktop.org/series/69124/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7299 -> Patchwork_15195
Summary
On Fri, Nov 08, 2019 at 12:08:52PM +0200, Jani Nikula wrote:
On Thu, 07 Nov 2019, Lucas De Marchi wrote:
When we call intel_bios_is_valid_vbt(), size may not actually be the
size of the VBT, but rather the size of the blob the VBT is contained
in. For example, when mapping the PCI oprom, size
On Fri, Nov 8, 2019 at 12:07 AM Brian Welty wrote:
>
>
>
> On 8/28/2019 11:50 PM, Daniel Vetter wrote:
> > On Wed, Aug 28, 2019 at 08:31:27PM +, Souza, Jose wrote:
> >> On Wed, 2019-08-28 at 21:13 +0100, Chris Wilson wrote:
> >>> Quoting Souza, Jose (2019-08-28 21:11:53)
> Reviewed-by:
On Fri, Nov 08, 2019 at 11:16:47AM +0200, Jani Nikula wrote:
On Thu, 07 Nov 2019, Lucas De Marchi wrote:
Convert the code to return-early style and fix missing calls
to release_firmware() if vbt is not valid.
I don't understand where anything would leak in the current code. Please
elaborate.
== Series Details ==
Series: tools: Add a simple rapl wrapper
URL : https://patchwork.freedesktop.org/series/69213/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7299 -> IGTPW_3673
Summary
---
**SUCCESS**
No
== Series Details ==
Series: drm/i915: Enable second dbuf slice for ICL and TGL (rev3)
URL : https://patchwork.freedesktop.org/series/69124/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.6.0
Commit: drm/i915: Enable second dbuf slice for ICL and TGL
== Series Details ==
Series: drm/i915: Enable second dbuf slice for ICL and TGL (rev3)
URL : https://patchwork.freedesktop.org/series/69124/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
ccd035456d7a drm/i915: Enable second dbuf slice for ICL and TGL
-:48:
Hi,
On Tuesday, November 5, 2019 3:27:55 PM CET Daniel Vetter wrote:
> On Thu, Oct 31, 2019 at 09:29:56AM +0100, Janusz Krzysztofik wrote:
> > We need dmabuf specific pwrite() callback utilizing dma-buf API,
> > otherwise GEM_PWRITE IOCTL will no longer work with dma-buf backed
> > (i.e., PRIME
Hi Jonas,
On Tuesday, November 5, 2019 10:14:20 AM CET Joonas Lahtinen wrote:
> Quoting Janusz Krzysztofik (2019-11-04 19:13:27)
> > Some tests assume 4kB offset alignment while using softpin. That
> > assumption may be wrong on future GEM backends with possibly larger
> > minimum page sizes.
Run a command; print how much power rapl reported the system using.
Signed-off-by: Chris Wilson
Cc: Andi Shyti
Cc: Tvrtko Ursulin
---
tools/igt_rapl.c | 202 ++
tools/meson.build | 5 ++
2 files changed, 207 insertions(+)
create mode 100644
On Fri, Nov 08, 2019 at 03:36:57PM +0200, Ville Syrjälä wrote:
> On Thu, Nov 07, 2019 at 06:40:14PM +0100, Daniel Vetter wrote:
> > On Thu, Nov 07, 2019 at 05:17:14PM +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > This thing can get called several thousand times per LUT
> > >
On Fri, Nov 8, 2019 at 11:05 AM Chris Wilson wrote:
> Quoting Daniel Vetter (2019-11-08 09:53:51)
> > On Wed, Nov 6, 2019 at 4:48 PM Chris Wilson
> > wrote:
> > > For our convenience, and to avoid frequent allocations, we placed some
> > > lists we use for execbuf inside the common i915_vma
On Fri, Nov 8, 2019 at 11:40 AM Chris Wilson wrote:
>
> Quoting Daniel Vetter (2019-11-08 10:20:23)
> > On Fri, Nov 8, 2019 at 11:11 AM Chris Wilson
> > wrote:
> > > Quoting Daniel Vetter (2019-11-08 09:54:42)
> > > > On Wed, Nov 6, 2019 at 4:49 PM Chris Wilson
> > > > wrote:
> > > > >
> > >
Turns out this isn't compatible with DSI.
Cc: Manasi Navare
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_dp.c | 12
drivers/gpu/drm/i915/display/intel_vdsc.c | 11 ---
2 files changed, 12 insertions(+), 11 deletions(-)
diff --git
Allow accessing the parent structure later on. Drop const for allowing
future modification as well.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_bios.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
Enable DSC for DSI, if specified in VBT.
This is now excessively dynamic, being enabled at compute config. I
don't expect us to need to switch between DSC and non-DSC for the same
panel. Cargo culting the DP DSC shows.
Mode valid lacks a sensible implementation, as does get config.
Turns out future DSI specific parameters aren't workable with the
approach of having the encoder specific functions in intel_vdsc.c. Make
intel_dsc_compute_params() a helper that does the encoder independent
parts, and have encoder code call it. Move intel_dsc_dp_compute_params()
to intel_dp.c as
Using the array is getting clumsy. Make things a bit more dynamic.
Remove early returns on not having child devices when the end result
after "iterating" the empty list would be the same.
v3:
- use list_add_tail to not reverse the child device list (Ville)
v2:
- stick to previous naming of
First attempt at enabling DSC on ICL+ DSI. Completely untested, fingers
crossed.
There are still gaps, and some details of the implementation, in
particular around VBT, are ghastly. But the bulk of the code should be
here.
BR,
Jani.
Jani Nikula (9):
drm/i915/bios: use a flag for vbt hdmi
Add DSI specific computation and transmission to display of PPS.
With hopes that this approach will work for both DP and DSI encoders.
Cc: Manasi Navare
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_vdsc.c | 26 ++-
1 file changed, 25 insertions(+), 1
Check for child devices that specify compression, and store the device
specific compression parameters in the display device data struct for
later use. Warn if compression is requested but not available.
Use fairly rigid checks for compression data for starters. These can be
made more dynamic
Add function for retrieving the DSC data for an encoder.
Initially, this is DSI specific, as DP does not use VBT settings for DSC
at all. It's also not very pretty.
In the future we might have a pointer from encoder to the child device,
which would make the child device list query here so much
The pre-initialized magic value is a bit silly, switch to a flag
instead.
v2: Reduce paranoia to a single sanity check (Ville)
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_bios.c | 10 +-
drivers/gpu/drm/i915/display/intel_ddi.c | 13
== Series Details ==
Series: series starting with [1/3] i915/gem_exec_fence: KMS master is not
required
URL : https://patchwork.freedesktop.org/series/69193/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7298 -> IGTPW_3668
== Series Details ==
Series: drm/i915/bios: use a flag for vbt hdmi level shift presence (rev2)
URL : https://patchwork.freedesktop.org/series/68998/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7282_full -> Patchwork_15171_full
Within this set of fence execution tests, we never once try to modeset;
being KMS master is not required.
Signed-off-by: Chris Wilson
---
tests/i915/gem_exec_fence.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/i915/gem_exec_fence.c b/tests/i915/gem_exec_fence.c
The pair of *-hang-all will generate sufficient hangs for the kernel to
ban the client. This is unfortunate as it means all further tests are
skipped. Ask nicely not to be banned.
Signed-off-by: Chris Wilson
---
tests/i915/gem_exec_fence.c | 7 +++
1 file changed, 7 insertions(+)
diff
The kernel is now enforcing that clients are not allowed to block higher
priority contexts from accessing the GPU; one is no longer allowed to
sleep for a second hogging the GPU. Reduce the sleep down to 50ms, short
enough not to anger the preempt-off checks while long enough for any
ordinary GPU
From: Ville Syrjälä
This thing can get called several thousand times per LUT
so seems like we want to inline it to:
- avoid the function call overhead
- allow constant folding
A quick synthetic test (w/o any hardware interaction) with
a ridiculously large LUT size shows about 50% reduction in
On Thu, 2019-11-07 at 16:52 -0800, Matt Roper wrote:
> On Thu, Nov 07, 2019 at 11:22:34PM +0200, Stanislav Lisovskiy wrote:
> > Also implemented algorithm for choosing DBuf slice configuration
> > based on active pipes, pipe ratio as stated in BSpec 12716.
> >
> > Now pipe allocation still stays
On Thu, Nov 07, 2019 at 12:37:22PM -0800, Matt Roper wrote:
> If INTEL_DISPLAY_ENABLED is false, then the modesetting resources were
> never initialized. Userspace may still call DRM_IOCTL_MODE_CREATE_DUMB
> which will eventually lead i915_gem_dumb_create() to try to dereference
> a non-existent
Also implemented algorithm for choosing DBuf slice configuration
based on active pipes, pipe ratio as stated in BSpec 12716.
Now pipe allocation still stays proportional to pipe width as before,
however within allowed DBuf slice for this particular configuration.
v2: Remove unneeded check from
On Thu, Nov 07, 2019 at 06:40:14PM +0100, Daniel Vetter wrote:
> On Thu, Nov 07, 2019 at 05:17:14PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > This thing can get called several thousand times per LUT
> > so seems like we want to inline it to:
> > - avoid the function call
On Wed, Nov 6, 2019 at 5:15 PM Daniele Ceraolo Spurio
wrote:
>
> Hi,
>
> Kindly add the below i915 changes to linux-firmware.git
>
> The following changes since commit 11bdc578ec861c7797ec614d60737a0448b68195:
>
> rtw88: RTL8723D: add firmware file v48 (2019-11-04 06:37:16 -0500)
>
> are
== Series Details ==
Series: series starting with [1/3] drm/i915: Handle i915_active_fence_set()
with the same fence
URL : https://patchwork.freedesktop.org/series/69074/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7273_full -> Patchwork_15157_full
== Series Details ==
Series: series starting with [CI,1/2] drm/i915/pmu: Cheat when reading the
actual frequency to avoid fw
URL : https://patchwork.freedesktop.org/series/69186/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7295 -> Patchwork_15194
On Thu, 07 Nov 2019, Lucas De Marchi wrote:
> When we are mapping the VBT through pci_map_rom() we may not be allowed
> to simply discard the address space and go on reading the memory. After
> checking on my test system that dumping the rom via sysfs I could
> actually get the correct vbt, I
== Series Details ==
Series: series starting with [CI,1/2] drm/i915/pmu: Cheat when reading the
actual frequency to avoid fw
URL : https://patchwork.freedesktop.org/series/69186/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.6.0
Commit: drm/i915/pmu: Cheat when
== Series Details ==
Series: series starting with [CI,1/2] drm/i915/pmu: Cheat when reading the
actual frequency to avoid fw
URL : https://patchwork.freedesktop.org/series/69186/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
85db03072ed3 drm/i915/pmu: Cheat when reading the
== Series Details ==
Series: drm/i915: make more headers self-contained
URL : https://patchwork.freedesktop.org/series/69183/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7294 -> Patchwork_15193
Summary
---
Quoting Tvrtko Ursulin (2019-11-08 10:37:37)
>
> On 06/11/2019 15:48, Chris Wilson wrote:
> > If the caller wants to overwrite the currently tracked fence, with
> > itself, as far as the tracking is concerned it is a no-op, so simply
> > allow it.
>
> This is needed for some of the following
On 07/11/2019 22:12, Chris Wilson wrote:
In the selftests, where we are accessing a private ctx from within the
confines of a single test, we know that the ctx->vm pointer is static
and bounded by the lifetime of the test. We can use a simple helper to
provide the RCU annotations to keep sparse
Quoting Daniel Vetter (2019-11-08 10:20:23)
> On Fri, Nov 8, 2019 at 11:11 AM Chris Wilson wrote:
> > Quoting Daniel Vetter (2019-11-08 09:54:42)
> > > On Wed, Nov 6, 2019 at 4:49 PM Chris Wilson
> > > wrote:
> > > >
> > > > With the goal of removing the serialisation from around execbuf, we
On 06/11/2019 15:48, Chris Wilson wrote:
If the caller wants to overwrite the currently tracked fence, with
itself, as far as the tracking is concerned it is a no-op, so simply
allow it.
This is needed for some of the following patches in this series?
Regards,
Tvrtko
Signed-off-by: Chris
We want to avoid taking forcewake when querying the performance stats,
as we wish to avoid perturbing the system under observation. (And with
the forcewake being kept alive for 1ms after use, sampling the frequency
from a timer keeps forcewake 60% active.)
Signed-off-by: Chris Wilson
Cc: Tvrtko
On gen7, we have to avoid concurrent access to the same mmio cacheline,
and so coordinate all mmio access with the uncore->lock. However, for
pmu, we want to avoid perturbing the system and disabling interrupts
unnecessarily, so restrict the w/a to gen7 where it is requied to
prevent machine
Quoting Tvrtko Ursulin (2019-11-08 10:21:22)
>
> On 08/11/2019 08:56, Chris Wilson wrote:
> > On gen7, we have to avoid concurrent access to the same mmio cacheline,
> > and so coordinate all mmio access with the uncore->lock. However, for
> > pmu, we want to avoid perturbing the system and
On 08/11/2019 08:56, Chris Wilson wrote:
On gen7, we have to avoid concurrent access to the same mmio cacheline,
and so coordinate all mmio access with the uncore->lock. However, for
pmu, we want to avoid perturbing the system and disabling interrupts
unnecessarily, so restrict the w/a to gen7
On Fri, Nov 8, 2019 at 11:11 AM Chris Wilson wrote:
> Quoting Daniel Vetter (2019-11-08 09:54:42)
> > On Wed, Nov 6, 2019 at 4:49 PM Chris Wilson
> > wrote:
> > >
> > > With the goal of removing the serialisation from around execbuf, we will
> > > no longer have the privilege of there being a
On 08/11/2019 08:56, Chris Wilson wrote:
We want to avoid taking forcewake when querying the performance stats,
as we wish to avoid perturbing the system under observation. (And with
the forcewake being kept alive for 1ms after use, sampling the frequency
from a timer keeps forcewake 60%
Quoting Daniel Vetter (2019-11-08 09:54:42)
> On Wed, Nov 6, 2019 at 4:49 PM Chris Wilson wrote:
> >
> > With the goal of removing the serialisation from around execbuf, we will
> > no longer have the privilege of there being a single execbuf in flight
> > at any time and so will only be able to
On Thu, Nov 7, 2019 at 8:57 PM Tang, CQ wrote:
>
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> > @@ -22,6 +22,8 @@
> > *
> > */
> >
> > +#include
> > +
> > #include "display/intel_frontbuffer.h"
> > #include "gt/intel_gt.h"
> >
On Thu, 07 Nov 2019, Lucas De Marchi wrote:
> When we call intel_bios_is_valid_vbt(), size may not actually be the
> size of the VBT, but rather the size of the blob the VBT is contained
> in. For example, when mapping the PCI oprom, size will be the entire
> oprom size. We don't want to read
Quoting Daniel Vetter (2019-11-08 09:53:51)
> On Wed, Nov 6, 2019 at 4:48 PM Chris Wilson wrote:
> > For our convenience, and to avoid frequent allocations, we placed some
> > lists we use for execbuf inside the common i915_vma struct. As we look
> > to parallelise execbuf, such fields guarded by
== Series Details ==
Series: series starting with [1/4] drm/i915/icl: Refine PG_HYSTERESIS
URL : https://patchwork.freedesktop.org/series/69181/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7293 -> Patchwork_15192
Summary
On Thu, 07 Nov 2019, Lucas De Marchi wrote:
> oprom is actually a better name to use when using
> pci_map_rom(). "bios" is way too generic and confusing.
>
> Signed-off-by: Lucas De Marchi
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_bios.c | 18 +-
>
Quoting Masahiro Yamada (2019-11-08 09:41:42)
> The headers in the gem/selftests/, gt/selftests, gvt/, selftests/
> directories have never been compile-tested, but it would be possible
> to make them self-contained.
>
> This commit only addresses missing and forward
> struct declarations.
>
>
On Wed, Nov 6, 2019 at 4:49 PM Chris Wilson wrote:
>
> With the goal of removing the serialisation from around execbuf, we will
> no longer have the privilege of there being a single execbuf in flight
> at any time and so will only be able to inspect the user's flags within
> the carefully
On Wed, Nov 6, 2019 at 4:48 PM Chris Wilson wrote:
> For our convenience, and to avoid frequent allocations, we placed some
> lists we use for execbuf inside the common i915_vma struct. As we look
> to parallelise execbuf, such fields guarded by the struct_mutex BKL must
> be pulled under local
The headers in the gem/selftests/, gt/selftests, gvt/, selftests/
directories have never been compile-tested, but it would be possible
to make them self-contained.
This commit only addresses missing and forward
struct declarations.
Signed-off-by: Masahiro Yamada
---
Rebase on
On 07/11/2019 21:39, Chris Wilson wrote:
Since drm provided us with a real struct file we can use for our
anonymous internal clients (mock_file), complete our transition to using
that as the primary interface (and not the mocked up struct drm_file we
previous were using).
Signed-off-by: Chris
On Thu, 07 Nov 2019, Lucas De Marchi wrote:
> Convert the code to return-early style and fix missing calls
> to release_firmware() if vbt is not valid.
I don't understand where anything would leak in the current code. Please
elaborate.
You could make a case for a change in style to avoid so
== Series Details ==
Series: series starting with [1/4] drm/i915/icl: Refine PG_HYSTERESIS
URL : https://patchwork.freedesktop.org/series/69181/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.6.0
Commit: drm/i915/icl: Refine PG_HYSTERESIS
Okay!
Commit:
== Series Details ==
Series: series starting with [1/4] drm/i915/icl: Refine PG_HYSTERESIS
URL : https://patchwork.freedesktop.org/series/69181/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
e90afdfcc256 drm/i915/icl: Refine PG_HYSTERESIS
9b2231304fc1 drm/i915/execlists:
1 - 100 of 109 matches
Mail list logo
