On Mon, Feb 25, 2019 at 02:20:37PM +0100, Hans de Goede wrote:
> Use the new drm_kms_call_oob_hotplug_notifier_chain() function to load
> drm/kms drivers know about DisplayPort over Type-C hotplug events.
>
> Signed-off-by: Hans de Goede
I'm OK with this. I'll wait for the v2 and see if I can te
Op 26-02-2019 om 17:17 schreef Matt Roper:
> On Tue, Feb 26, 2019 at 08:26:36AM +0100, Maarten Lankhorst wrote:
>> Hey,
>>
>> Op 21-02-2019 om 01:28 schreef Matt Roper:
>>> Some display controllers can be programmed to present non-black colors
>>> for pixels not covered by any plane (or pixels cove
Quoting Daniel Vetter (2017-08-07 10:28:58)
> On Fri, Aug 04, 2017 at 09:23:28AM +0100, Chris Wilson wrote:
> > After an event is sent, we try to copy it into the user buffer of the
> > first waiter in drm_read() and if the user buffer doesn't have enough
> > room we put it back onto the list. Howe
On 26/02/2019 10:23, Chris Wilson wrote:
When a request has its priority changed, we traverse the graph of all of
its signalers to raise their priorities to match (priority inheritance).
If the request has already started executing its payload, we know that
all of its signalers must have signale
On 26/02/2019 10:23, Chris Wilson wrote:
As kmem_caches share the same properties (size, allocation/free behaviour)
for all potential devices, we can use global caches. While this
potential has worse fragmentation behaviour (one can argue that
different devices would have different activity life
Quoting Tvrtko Ursulin (2019-02-27 10:29:43)
>
> On 26/02/2019 10:23, Chris Wilson wrote:
> > As kmem_caches share the same properties (size, allocation/free behaviour)
> > for all potential devices, we can use global caches. While this
> > potential has worse fragmentation behaviour (one can argu
On 26/02/2019 10:23, Chris Wilson wrote:
In preparation for enabling HW semaphores, we need to keep in flight
timeline HWSP alive until its use across entire system has completed,
as any other timeline active on the GPU may still refer back to the
already retired timeline. We both have to delay
Quoting Tvrtko Ursulin (2019-02-27 10:44:42)
>
> On 26/02/2019 10:23, Chris Wilson wrote:
> > In preparation for enabling HW semaphores, we need to keep in flight
> > timeline HWSP alive until its use across entire system has completed,
> > as any other timeline active on the GPU may still refer b
Hi Hans,
On Mon, Feb 25, 2019 at 02:20:34PM +0100, Hans de Goede wrote:
> Hi All,
>
> On some Cherry Trail devices, DisplayPort over Type-C is supported through
> a USB-PD microcontroller (e.g. a fusb302) + a mux to switch the superspeed
> datalines between USB-3 and DP (e.g. a pi3usb30532). The
On Thu, 17 Jan 2019, Chris Wilson wrote:
> Quoting Jani Nikula (2019-01-17 12:13:59)
>> The v1 [1] kind of died down because the FIELD_PREP() build-time checks
>> were lost as it didn't evaluate to integer constant expression. I looked
>> at this again, and managed to include the checks in the loc
On Wed, 27 Feb 2019, Heikki Krogerus wrote:
> One thing that this series does not consider is the DP lane count
> problem. The GPU drivers (i915 in this case) does not know is four,
> two or one DP lanes in use.
Also, orientation.
> I guess that is not a critical issue since there is a workaroun
In preparation for enabling HW semaphores, we need to keep in flight
timeline HWSP alive until its use across entire system has completed,
as any other timeline active on the GPU may still refer back to the
already retired timeline. We both have to delay recycling available
cachelines and unpinning
Quoting Jani Nikula (2019-02-27 11:01:58)
> On Thu, 17 Jan 2019, Chris Wilson wrote:
> > Quoting Jani Nikula (2019-01-17 12:13:59)
> >> The v1 [1] kind of died down because the FIELD_PREP() build-time checks
> >> were lost as it didn't evaluate to integer constant expression. I looked
> >> at this
== Series Details ==
Series: series starting with [01/11] drm/i915: Skip scanning for signalers if
we are already inflight (rev3)
URL : https://patchwork.freedesktop.org/series/57244/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
12e479dbed40 drm/i915/execlists: Suppress mere
== Series Details ==
Series: series starting with [01/11] drm/i915: Skip scanning for signalers if
we are already inflight (rev3)
URL : https://patchwork.freedesktop.org/series/57244/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915/execlists:
Exploit that reads of the ring registers return 0 from the engine when
it is idle and we do not apply forcewake to know that if the engine is
idle then both reads will be identical (and so we interpret the ring as
idle).
The ulterior motive is to try and reduce the number of spurious wakeups
to av
On Wed, Feb 27, 2019 at 01:16:27PM +0200, Jani Nikula wrote:
> On Wed, 27 Feb 2019, Heikki Krogerus wrote:
> > One thing that this series does not consider is the DP lane count
> > problem. The GPU drivers (i915 in this case) does not know is four,
> > two or one DP lanes in use.
>
> Also, orient
== Series Details ==
Series: drm/i915: Avoid waking the engines just to check if they are idle
URL : https://patchwork.freedesktop.org/series/57292/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
125ec713a4f5 drm/i915: Avoid waking the engines just to check if they are idle
-:15
== Series Details ==
Series: series starting with [01/11] drm/i915: Skip scanning for signalers if
we are already inflight (rev3)
URL : https://patchwork.freedesktop.org/series/57244/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5665 -> Patchwork_12313
==
Am 27.02.19 um 00:04 schrieb Dave Airlie:
At the end of the day, I don't really care that much. I get it, we
all have large projects with scarce resources. I just think a few
years down the road we'll all regret it as a community.
AMD and others have also spent years tuning TTM for both UMA an
== Series Details ==
Series: drm/i915: Avoid waking the engines just to check if they are idle
URL : https://patchwork.freedesktop.org/series/57292/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5665 -> Patchwork_12314
Summ
Chris Wilson writes:
> Exploit that reads of the ring registers return 0 from the engine when
> it is idle and we do not apply forcewake to know that if the engine is
> idle then both reads will be identical (and so we interpret the ring as
> idle).
>
> The ulterior motive is to try and reduce th
== Series Details ==
Series: series starting with [01/11] drm/i915: Skip scanning for signalers if
we are already inflight (rev3)
URL : https://patchwork.freedesktop.org/series/57244/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5665_full -> Patchwork_12313_full
On Mon, Feb 25, 2019 at 03:42:26PM +0100, Noralf Trønnes wrote:
> This makes it safe to access drm_device->dev after the parent device has
> been removed/unplugged.
>
> Signed-off-by: Noralf Trønnes
Reviewed-by: Gerd Hoffmann
___
Intel-gfx mailing li
On Mon, Feb 25, 2019 at 03:42:27PM +0100, Noralf Trønnes wrote:
> This adds a resource managed (devres) version of drm_dev_init().
>
> v2: Remove devm_drm_dev_register() since we can't touch hw in devm
> release functions and drivers want to disable hw on driver module
> unload (Daniel Vet
On 27/02/2019 10:44, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-02-27 10:29:43)
On 26/02/2019 10:23, Chris Wilson wrote:
As kmem_caches share the same properties (size, allocation/free behaviour)
for all potential devices, we can use global caches. While this
potential has worse fragmen
On Mon, Feb 25, 2019 at 03:42:28PM +0100, Noralf Trønnes wrote:
> Add driver example that shows how devm_drm_dev_init() can be used.
>
> v2: Expand docs (Sam, Daniel)
Acked-by: Gerd Hoffmann
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
h
On 27/02/2019 11:15, Chris Wilson wrote:
In preparation for enabling HW semaphores, we need to keep in flight
timeline HWSP alive until its use across entire system has completed,
as any other timeline active on the GPU may still refer back to the
already retired timeline. We both have to delay
On Mon, Feb 25, 2019 at 03:42:30PM +0100, Noralf Trønnes wrote:
> Use devm_drm_dev_init() and drop using tinydrm_device.
>
> v2: devm_drm_dev_register() was dropped so add driver release callbacks.
>
> Signed-off-by: Noralf Trønnes
> ---
> drivers/gpu/drm/tinydrm/hx8357d.c | 40 +--
>
On Mon, Feb 25, 2019 at 03:42:32PM +0100, Noralf Trønnes wrote:
> This protects device resources from use after device removal.
>
> There are 3 ways for driver-device unbinding to happen:
> - The driver module is unloaded causing the driver to be unregistered.
> This can't happen as long as ther
Quoting Christian König (2019-02-27 04:17:01)
> Am 27.02.19 um 00:04 schrieb Dave Airlie:
> >>> At the end of the day, I don't really care that much. I get it, we
> >>> all have large projects with scarce resources. I just think a few
> >>> years down the road we'll all regret it as a community.
Quoting Tvrtko Ursulin (2019-02-27 14:17:25)
>
> On 27/02/2019 10:44, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-02-27 10:29:43)
> >>
> >> On 26/02/2019 10:23, Chris Wilson wrote:
> >>> As kmem_caches share the same properties (size, allocation/free behaviour)
> >>> for all potential dev
== Series Details ==
Series: drm/i915: Avoid waking the engines just to check if they are idle
URL : https://patchwork.freedesktop.org/series/57292/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5665_full -> Patchwork_12314_full
Quoting Patchwork (2019-02-27 15:07:07)
> Possible fixes
>
> * igt@drm_read@short-buffer-nonblock:
> - shard-snb: INCOMPLETE [fdo#105411] -> PASS
That's the one, that's been 100% since the last IGT reorder.
-Chris
___
Intel-gfx
Hi,
On 27-02-19 12:16, Jani Nikula wrote:
On Wed, 27 Feb 2019, Heikki Krogerus wrote:
One thing that this series does not consider is the DP lane count
problem. The GPU drivers (i915 in this case) does not know is four,
two or one DP lanes in use.
Also, orientation.
The orientation should
Hi,
On 27-02-19 10:44, Heikki Krogerus wrote:
On Mon, Feb 25, 2019 at 02:20:37PM +0100, Hans de Goede wrote:
Use the new drm_kms_call_oob_hotplug_notifier_chain() function to load
drm/kms drivers know about DisplayPort over Type-C hotplug events.
Signed-off-by: Hans de Goede
I'm OK with thi
We assumed that the default preemption granularity is fine for ICL.
Unfortunately, it turns out that some drivers don't support mid-thread
preemption for compute workloads.
If a workload that doesn't support mid-thread preemption gets mid-thread
preempted, we're going to observe a GPU hang.
While I
There are still some cases where userspace needs to change the
preemption granularity for compute workloads. Let's whitelist the
per-ctx granularity control register to allow it.
Signed-off-by: Michał Winiarski
Cc: Anuj Phogat
Cc: Joonas Lahtinen
Cc: Matt Roper
Cc: Rafael Antognolli
---
driv
Quoting Michał Winiarski (2019-02-27 15:51:09)
> There are still some cases where userspace needs to change the
> preemption granularity for compute workloads. Let's whitelist the
> per-ctx granularity control register to allow it.
Just wondering aloud if this should a single patch; change the def
Quoting Michał Winiarski (2019-02-27 15:51:09)
> There are still some cases where userspace needs to change the
> preemption granularity for compute workloads. Let's whitelist the
> per-ctx granularity control register to allow it.
>
> Signed-off-by: Michał Winiarski
> Cc: Anuj Phogat
> Cc: Joon
As we already have the previous portion of the mmap mlocked, we only
need to mlock() the fresh portion for testing available memory.
v2: Fixup the uint64_t pointer arithmetric and only use a single mmap to
avoid subsequent mlock fail (for reasons unknown, but bet on mm/).
Signed-off-by: Chris Wil
Hardware cannot be in a middle of idle flow messaging
when we pull the plug from ringbuffer. Disable idle
messaging before we do so to avoid potential deadlock
on engine initialization and reset.
v2: INVALID_MMIO_REG, unconditional enable (Chris)
Cc: Chris Wilson
Signed-off-by: Mika Kuoppala
--
We have an exported function for stopping the engine before
disabling a ringbuffer. Take it into use.
Cc: Chris Wilson
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_engine_cs.c | 3 +++
drivers/gpu/drm/i915/intel_ringbuffer.c | 31 +++--
2 files changed, 16 i
We use identical sequence of stopping ringbuffer on reset
handing and on ring initialization. Make a function
to handle both cases.
Cc: Chris Wilson
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_reset.c | 18 +---
drivers/gpu/drm/i915/intel_engine_cs.c | 28 +
Introduce REG_BIT(n) to define register bits and REG_GENMASK(h, l) to
define register bitfield masks.
We define the above as wrappers to BIT() and GENMASK() respectively to
force u32 type to go with our register size, and to add compile time
checks on the bit numbers.
The intention is that these
Slightly verbose, but does away with hand rolled shifts. Ties the field
values with the mask defining the field.
Unfortunately we have to make a local copy of FIELD_PREP() to evaluate
to a integer constant expression. But with this, we can ensure the mask
is non-zero, power of 2, fits u32, and the
v3 of [1] with naming hopefully settled (fingers crossed), and some more
compile time checks, documentation and other polish added.
The naming scheme of the local wrappers/copies of bit fiddling macros is
to just use REG_ prefix for the regular kernel ones, with hopefully
minimal confusion. So we
bitfield.h defines FIELD_GET() and FIELD_PREP() macros to access
bitfields using the mask alone, with no need for separate shift. Indeed,
the shift is redundant.
We define REG_FIELD_GET() and REG_FIELD_PREP() wrappers for the above,
in part to force u32 and for consistency with REG_BIT() and
REG_G
Den 27.02.2019 15.27, skrev Gerd Hoffmann:
> On Mon, Feb 25, 2019 at 03:42:30PM +0100, Noralf Trønnes wrote:
>> Use devm_drm_dev_init() and drop using tinydrm_device.
>>
>> v2: devm_drm_dev_register() was dropped so add driver release callbacks.
>>
>> Signed-off-by: Noralf Trønnes
>> ---
>> dri
Mika Kuoppala writes:
> We have an exported function for stopping the engine before
> disabling a ringbuffer. Take it into use.
>
> Cc: Chris Wilson
> Signed-off-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/intel_engine_cs.c | 3 +++
> drivers/gpu/drm/i915/intel_ringbuffer.c | 31 +
== Series Details ==
Series: series starting with [1/2] drm/i915/icl: Default to Thread Group
preemption for compute workloads
URL : https://patchwork.freedesktop.org/series/57300/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5666 -> Patchwork_12315
=
Quoting Mika Kuoppala (2019-02-27 16:58:48)
> We have an exported function for stopping the engine before
> disabling a ringbuffer. Take it into use.
>
> Cc: Chris Wilson
> Signed-off-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/intel_engine_cs.c | 3 +++
> drivers/gpu/drm/i915/intel_ringbu
Quoting Mika Kuoppala (2019-02-27 16:58:49)
> We use identical sequence of stopping ringbuffer on reset
> handing and on ring initialization. Make a function
> to handle both cases.
>
> Cc: Chris Wilson
> Signed-off-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_reset.c | 18 +---
From: Ville Syrjälä
Some monitors apparently forget to mark any mode as preferred in the
EDID. In this particular case we have a very generic looking ID
"PNP Model 0 Serial Number 4" / "LVDS 800x600" so a specific quirk
doesn't seem particularly wise. Also the quirk we have
(EDID_QUIRK_FIRST_DETA
From: Ville Syrjälä
Looks like EDID_QUIRK_FIRST_DETAILED_PREFERRED never did anything.
Its counterpart in f86EdidModes.c is properly hooked up but somehow
that functionality was lost when it was copied into the kernel.
Assuming that another preferred mode didn't sneak in somehow
(is that even po
Quoting Mika Kuoppala (2019-02-27 17:03:38)
> Mika Kuoppala writes:
>
> > We have an exported function for stopping the engine before
> > disabling a ringbuffer. Take it into use.
> >
> > Cc: Chris Wilson
> > Signed-off-by: Mika Kuoppala
> > ---
> > drivers/gpu/drm/i915/intel_engine_cs.c | 3
Quoting Mika Kuoppala (2019-02-27 16:58:50)
> Hardware cannot be in a middle of idle flow messaging
> when we pull the plug from ringbuffer. Disable idle
> messaging before we do so to avoid potential deadlock
> on engine initialization and reset.
>
> v2: INVALID_MMIO_REG, unconditional enable (Ch
inline.
v2 patches fixes
- address calculation bug
- not killed
However, the test does not runs faster.
-caz
On Wed, 2019-02-27 at 16:29 +, Chris Wilson wrote:
> As we already have the previous portion of the mmap mlocked, we only
> need to mlock() the fresh portion for testing available memo
== Series Details ==
Series: series starting with [1/3] drm/i915: Use intel_engine_stop_cs when
stopping ringbuffer
URL : https://patchwork.freedesktop.org/series/57304/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5666 -> Patchwork_12316
== Series Details ==
Series: drm/i915: introduce macros to define register contents (rev3)
URL : https://patchwork.freedesktop.org/series/50513/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
918ed22b15ea drm/i915: introduce REG_BIT() and REG_GENMASK() to define register
conten
== Series Details ==
Series: drm/i915: introduce macros to define register contents (rev3)
URL : https://patchwork.freedesktop.org/series/50513/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: introduce REG_BIT() and REG_GENMASK() to define re
Quoting Patchwork (2019-02-27 17:41:59)
> Possible regressions
>
> * igt@i915_selftest@live_active:
> - fi-apl-guc: PASS -> DMESG-WARN
Second flip due to "drm/i915: Avoid waking the engines just to check if
they are idle", both skl.
Suggests that its passing earlier was f
So CI is reporting a few flips on Skylake for intel_engines_are_idle(),
so apply a double check that the ring is valid before inspecting the
registers. However, we keep the forcewake omission in play to avoid the
Sandybridge failure.
Fixes: 0b702dca2658 ("drm/i915: Avoid waking the engines just to
On Tue, Feb 26, 2019 at 11:15:44AM -0800, Lucas De Marchi wrote:
> On Tue, Feb 26, 2019 at 04:21:01PM +0200, Ville Syrjälä wrote:
> >On Mon, Feb 25, 2019 at 04:03:05PM -0800, Lucas De Marchi wrote:
> >> On Mon, Feb 25, 2019 at 10:42:12PM +0200, Ville Syrjälä wrote:
> >> >On Fri, Feb 22, 2019 at 03:
On Tue, Feb 26, 2019 at 11:02:58AM -0800, Lucas De Marchi wrote:
> On Tue, Feb 26, 2019 at 04:48:23PM +0200, Ville Syrjälä wrote:
> >> >This seems a rather roundabout way of doing things when we already have
> >> >the vfuncs.
> >> >
> >> >How about just:
> >> >
> >> >mg_pll_enable()
> >> >{
> >> >
== Series Details ==
Series: drm/i915: introduce macros to define register contents (rev3)
URL : https://patchwork.freedesktop.org/series/50513/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5666 -> Patchwork_12317
Summary
== Series Details ==
Series: series starting with [1/2] drm/edid: If no preferred mode is found
assume the first mode is preferred
URL : https://patchwork.freedesktop.org/series/57306/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5666 -> Patchwork_12318
=
== Series Details ==
Series: series starting with [1/2] drm/i915/icl: Default to Thread Group
preemption for compute workloads
URL : https://patchwork.freedesktop.org/series/57300/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5666_full -> Patchwork_12315_full
===
== Series Details ==
Series: drm/i915: Add a security blanket to ring_is_idle()
URL : https://patchwork.freedesktop.org/series/57308/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5666 -> Patchwork_12319
Summary
---
Hi Masahiro.
On Thu, Jan 31, 2019 at 12:56:39PM +0900, Masahiro Yamada wrote:
> Currently, the Kbuild core manipulates header search paths in a crazy
> way [1].
>
> To fix this mess, I want all Makefiles to add explicit $(srctree)/ to
> the search paths in the srctree. Some Makefiles are already
== Series Details ==
Series: drm/i915: introduce macros to define register contents (rev3)
URL : https://patchwork.freedesktop.org/series/50513/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5666_full -> Patchwork_12317_full
On Wed, 2019-02-27 at 19:14 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Some monitors apparently forget to mark any mode as preferred in the
> EDID. In this particular case we have a very generic looking ID
> "PNP Model 0 Serial Number 4" / "LVDS 800x600" so a specific quirk
> doesn't s
If we have parked, then we must have passed an idleness test and still
be idle. We chose not to use this shortcut in the past so that we could
use the idleness test at any time and inspect HW, however some HW like
Sandybridge doesn't like being woken up frivolously so avoid doing so.
References: 0
Quoting Jani Nikula (2019-02-27 17:02:36)
> Introduce REG_BIT(n) to define register bits and REG_GENMASK(h, l) to
> define register bitfield masks.
>
> We define the above as wrappers to BIT() and GENMASK() respectively to
> force u32 type to go with our register size, and to add compile time
> ch
Quoting Jani Nikula (2019-02-27 17:02:37)
> bitfield.h defines FIELD_GET() and FIELD_PREP() macros to access
> bitfields using the mask alone, with no need for separate shift. Indeed,
> the shift is redundant.
>
> We define REG_FIELD_GET() and REG_FIELD_PREP() wrappers for the above,
> in part to
On Wed, Feb 27, 2019 at 03:23:01PM -0500, Adam Jackson wrote:
> On Wed, 2019-02-27 at 19:14 +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Some monitors apparently forget to mark any mode as preferred in the
> > EDID. In this particular case we have a very generic looking ID
> > "PNP
This reverts commit 0b702dca26580e3bbfbbaf22dfc29280b6263414.
CI reports that this is not as reliable as it first appears, with
failures starting to sporadically occur in selftests.
Fixes: 0b702dca2658 ("drm/i915: Avoid waking the engines just to check if they
are idle")
Signed-off-by: Chris Wil
Quoting Jani Nikula (2019-02-27 17:02:38)
> Slightly verbose, but does away with hand rolled shifts. Ties the field
> values with the mask defining the field.
>
> Unfortunately we have to make a local copy of FIELD_PREP() to evaluate
> to a integer constant expression. But with this, we can ensure
On Wed, Feb 27, 2019 at 07:02:38PM +0200, Jani Nikula wrote:
> Slightly verbose, but does away with hand rolled shifts. Ties the field
> values with the mask defining the field.
>
> Unfortunately we have to make a local copy of FIELD_PREP() to evaluate
> to a integer constant expression. But with
On Wed, Feb 27, 2019 at 08:50:31PM +, Chris Wilson wrote:
> Quoting Jani Nikula (2019-02-27 17:02:36)
> > #define PP_REFERENCE_DIVIDER_SHIFT8
> > -#define PANEL_POWER_CYCLE_DELAY_MASK 0x1f
> > +#define PANEL_POWER_CYCLE_DELAY_MASK REG_GENMASK(4, 0)
>
> Ok.
>
> I'll get used to the
Quoting Caz Yokoyama (2019-02-27 17:34:57)
> inline.
>
> v2 patches fixes
> - address calculation bug
> - not killed
> However, the test does not runs faster.
Fair enough, I expected some improvement from the incremental and
avoiding the second mlock + populate of a large region, but if it's not
== Series Details ==
Series: series starting with [1/2] Revert "drm/i915: Avoid waking the engines
just to check if they are idle"
URL : https://patchwork.freedesktop.org/series/57311/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
74f5ddaa45e2 Revert "drm/i915: Avoid waking th
If we have parked, then we must have passed an idleness test and still
be idle. We chose not to use this shortcut in the past so that we could
use the idleness test at any time and inspect HW. However, some HW like
Sandybridge, doesn't like being woken up frivolously, so avoid doing so.
References
== Series Details ==
Series: series starting with [1/2] Revert "drm/i915: Avoid waking the engines
just to check if they are idle"
URL : https://patchwork.freedesktop.org/series/57311/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5666 -> Patchwork_12320
=
== Series Details ==
Series: series starting with [1/2] Revert "drm/i915: Avoid waking the engines
just to check if they are idle" (rev2)
URL : https://patchwork.freedesktop.org/series/57311/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
35705bcdfb67 Revert "drm/i915: Avoid wa
Quoting Chris Wilson (2019-02-27 10:17:15)
> Quoting Daniel Vetter (2017-08-07 10:28:58)
> > On Fri, Aug 04, 2017 at 09:23:28AM +0100, Chris Wilson wrote:
> > > After an event is sent, we try to copy it into the user buffer of the
> > > first waiter in drm_read() and if the user buffer doesn't have
== Series Details ==
Series: series starting with [1/2] Revert "drm/i915: Avoid waking the engines
just to check if they are idle" (rev2)
URL : https://patchwork.freedesktop.org/series/57311/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5666 -> Patchwork_12321
==
Tested both the patches with drm-tip kernel. Fixes multiple gpu hangs
in vulkan cts and piglit. I will do more thorough testing with updated
version of these patches based on review.
On Wed, Feb 27, 2019 at 7:52 AM Michał Winiarski
wrote:
>
> We assumed that the default preemption granularity i
Atomic state needs to be put even if the commit was successful.
Fixes: dba14b27dd3c ("drm/i915: Reinitialize sink scrambling/TMDS clock ratio
on HPD")
Cc: Ville Syrjälä
Cc: Lyude Paul
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/intel_ddi.c | 7 +--
1 file changed, 1 inse
drm_atomic_commit() call chain already takes care of adding
connectors and planes, so lets no add then manually if not changing
their states.
Cc: Ville Syrjälä
Cc: Lyude Paul
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/intel_ddi.c | 8
1 file changed, 8 deletions(-)
On Wed, 27 Feb 2019 18:02:36 +0100, Jani Nikula
wrote:
@@ -116,6 +116,34 @@
* #define GEN8_BAR_MMIO(0xb888)
*/
+/**
+ * REG_BIT() - Prepare a u32 bit value
+ * @__n: 0-based bit number
+ *
+ * Local wrapper for BIT() to force u32, with compile time checks.
+ *
+ * @re
We currently use a worker queued from an rcu callback to determine when
a how grace period has elapsed while we remained idle. We use this idle
delay to infer that we will be idle for a while and this is a suitable
point at which we can trim our global memory caches.
Since we wrote that, this mech
As kmem_caches share the same properties (size, allocation/free behaviour)
for all potential devices, we can use global caches. While this
potential has worse fragmentation behaviour (one can argue that
different devices would have different activity lifetimes, but you can
also argue that activity
As our allocations are not device specific, we can move our slab caches
to a global scope.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gvt/dmabuf.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 6 ---
drivers/gpu/drm/i915/i915_gem.c | 47 ++-
== Series Details ==
Series: series starting with [1/2] Revert "drm/i915: Avoid waking the engines
just to check if they are idle" (rev2)
URL : https://patchwork.freedesktop.org/series/57311/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5666_full -> Patchwork_12321_full
On Wed, 27 Feb 2019 18:02:38 +0100, Jani Nikula
wrote:
@@ -108,9 +108,9 @@
* #define FOO(pipe) _MMIO_PIPE(pipe, _FOO_A, _FOO_B)
* #define FOO_ENABLEREG_BIT(31)
* #define FOO_MODE_MASK REG_GENMASK(19, 16)
- * #define FOO_MODE_BAR
== Series Details ==
Series: series starting with [1/2] drm/i915: Fix atomic state leak when
resetting HDMI link
URL : https://patchwork.freedesktop.org/series/57318/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5668 -> Patchwork_12322
===
== Series Details ==
Series: series starting with [1/3] drm/i915: Make request allocation caches
global
URL : https://patchwork.freedesktop.org/series/57319/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
158b026641f1 drm/i915: Make request allocation caches global
-:162: WARNI
== Series Details ==
Series: series starting with [1/3] drm/i915: Make request allocation caches
global
URL : https://patchwork.freedesktop.org/series/57319/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Make request allocation caches globa
On Tue, 2019-02-26 at 16:08 +0200, Imre Deak wrote:
> On Fri, Feb 22, 2019 at 01:08:34PM -0800, José Roberto de Souza
> wrote:
> > Unpowered type-c dongles can take some time to boot and be
> > responsible, causing the probe to fail and sink never be detected
> > without further actions from usersp
1 - 100 of 118 matches
Mail list logo
