On Fri, Jul 17, 2020 at 03:37:37PM +0200, Hans de Goede wrote:
> Hi All,
>
> Here is v5 of my patch series converting the i915 driver's code for
> controlling the panel's backlight with an external PWM controller to
> use the atomic PWM API. See below for the changelog.
>
> This series consists o
The GT subsystem is highly dependent on interrupts for driving the GPU;
while the interrupt is being processed the GPU may idle leading to lower
throughput and higher latency. Since the GT interrupts dominate, push
the incidental display interrupt handling to later.
gem_exec_nop/parallel on ivb [i
== Series Details ==
Series: drm/i915: Reduce register reads around GT interrupts
URL : https://patchwork.freedesktop.org/series/79919/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
84189faf3bc4 drm/i915: Reduce register reads around GT interrupts
-:73: WARNING:LINE_SPACING: Mi
== Series Details ==
Series: drm/i915: Reduce register reads around GT interrupts
URL : https://patchwork.freedesktop.org/series/79919/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8793 -> Patchwork_18244
Summary
---
Hi, Chris,
It appears to me like this series is doing a lot of different things:
- Various optimizations
- Locking rework
- Adding schedulers
- Other misc fixes
Could you please separate out as much as possible the locking rework
prerequisites in one series with cover letter, and most importan
On 23/07/2020 21:32, Dave Airlie wrote:
I've got a 66 patch series here, does it have a cover letter I missed?
>
> Does it have a what is the goal of this series? Does it tell the
> reviewer where things are headed and why this is a good idea from a
> high level.
Chris sent it on one of the p
Chris Wilson writes:
> The GT subsystem is highly dependent on interrupts for driving the GPU;
> while the interrupt is being processed the GPU may idle leading to lower
> throughput and higher latency. Since the GT interrupts dominate, push
> the incidental display interrupt handling to later.
>
== Series Details ==
Series: drm/i915: Reduce register reads around GT interrupts
URL : https://patchwork.freedesktop.org/series/79919/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8793_full -> Patchwork_18244_full
Summary
On 2020-07-25 1:26 a.m., Paulo Zanoni wrote:
> Em seg, 2020-07-20 às 17:01 +0530, Karthik B S escreveu:
>>
>> diff --git a/drivers/gpu/drm/i915/i915_irq.c
>> b/drivers/gpu/drm/i915/i915_irq.c
>> index 1fa67700d8f4..95953b393941 100644
>> --- a/drivers/gpu/drm/i915/i915_irq.c
>> +++ b/drivers/gpu/d
Em Tue, Jul 21, 2020 at 04:06:34PM +0300, Alexey Budankov escreveu:
>
> On 13.07.2020 21:51, Arnaldo Carvalho de Melo wrote:
> > Em Mon, Jul 13, 2020 at 03:37:51PM +0300, Alexey Budankov escreveu:
> >>
> >> On 13.07.2020 15:17, Arnaldo Carvalho de Melo wrote:
> >>> Em Mon, Jul 13, 2020 at 12:48:25
On 7/3/20 4:41 PM, Samuel Iglesias Gonsálvez wrote:
> Hi,
>
> In the last meeting, X.Org Foundation board has decided that XDC 2020
> will be a virtual conference, given the uncertain COVID-19 situation in
> Europe by September, including the possibility of a second wave,
> outbreaks and travel
On Fri, 17 Jul 2020 20:32:44 +0100 Chris Wilson wrote:
>
>
> Quoting Jisheng Zhang (2020-07-17 07:11:38)
> > The i915 doesn't depend on IOSF_MBI, asm/iosf_mbi.h already defines
> > isof_mbi_* APIs when ISOF_MBI is disabled.
> >
> > Don't force IOSF_MBI to allow disabling IOSF_MBI for non SoC pl
Am 22.07.20 um 16:07 schrieb Daniel Vetter:
On Wed, Jul 22, 2020 at 3:12 PM Thomas Hellström (Intel)
wrote:
On 2020-07-22 14:41, Daniel Vetter wrote:
I'm pretty sure there's more bugs, I just haven't heard from them yet.
Also due to the opt-in nature of dma-fence we can limit the scope of
what
> On Jul 21, 2020, at 5:42 PM, Zhenyu Wang wrote:
>
> On 2020.07.21 14:04:41 +0300, Joonas Lahtinen wrote:
>> Quoting Zhenyu Wang (2020-07-20 11:05:41)
>>>
>>> Hi,
>>>
>>> Sorry that this might be a bit late as last week our QA people were
>>> busy on something else..So this is gvt changes q
Although the WA description targets the platforms it is a workaround
for the affected PCHs, that is why it is being checked.
v2: excluding DG1 fake PCH from WA
BSpec: 52890
BSpec: 53273
BSpec: 52888
Reviewed-by: Matt Roper
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/i
== Series Details ==
Series: drm/i915: Implement WA 14011294188 (rev2)
URL : https://patchwork.freedesktop.org/series/79825/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be checked separately.
__
On 7/15/20 1:51 PM, Chris Wilson wrote:
Acquire all the objects and their backing storage, and page directories,
as used by execbuf under a single common ww_mutex. Albeit we have to
restart the critical section a few times in order to handle various
restrictions (such as avoiding copy_(from|to)
On 7/15/20 1:51 PM, Chris Wilson wrote:
It is illegal to wait on an another vma while holding the vm->mutex, as
that easily leads to ABBA deadlocks (we wait on a second vma that waits
on us to release the vm->mutex). So while the vm->mutex exists, move the
waiting outside of the lock into the a
== Series Details ==
Series: drm/i915: Implement WA 14011294188 (rev2)
URL : https://patchwork.freedesktop.org/series/79825/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8797 -> Patchwork_18245
Summary
---
**SUCCESS
On 7/6/20 8:19 AM, Chris Wilson wrote:
This is the easy part; pulling reservation of multiple objects under an
ww acquire context. With one simple rule that eviction is handled by the
ww acquire context, we can carefully transition the driver over to using
eviction. Instead of feeding the acquir
On Thu, Jul 23, 2020 at 7:21 PM Chris Wilson wrote:
>
> An unfortunate sequence of events, but it turns out there is a valid
> usecase for being able to free/decouple the driver objects before they
> are freed by the DRM core. In particular, if we have a pointer into a
> drm core object from insid
On Fri, Jul 24, 2020 at 09:55:35AM +0100, Chris Wilson wrote:
Quoting Umesh Nerlige Ramappa (2020-07-24 01:19:00)
From: Piotr Maciejewski
It is useful to have markers in the OA reports to identify triggered
reports. Whitelist some OA counters that can be used as markers.
A triggered report ca
> -Original Message-
> From: Daniel Vetter
> Sent: Monday, July 27, 2020 12:33 PM
> To: Chris Wilson ; Dave Airlie
> Cc: intel-gfx ; stable
> ; Gustavo Padovan
> ; Tang, CQ ; dri-
> devel ; Vetter, Daniel
>
> Subject: Re: [PATCH 1/3] drm: Restore driver.preclose() for all to use
>
>
== Series Details ==
Series: drm/i915: Implement WA 14011294188 (rev2)
URL : https://patchwork.freedesktop.org/series/79825/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8797_full -> Patchwork_18245_full
Summary
---
Hi
[This is an automated email]
This commit has been processed because it contains a -stable tag.
The stable tag indicates that it's relevant for the following trees: all
The bot has tested the following trees: v5.7.10, v5.4.53, v4.19.134, v4.14.189,
v4.9.231, v4.4.231.
v5.7.10: Build OK!
v5.4
Hi
[This is an automated email]
This commit has been processed because it contains a -stable tag.
The stable tag indicates that it's relevant for the following trees: 4.12+
The bot has tested the following trees: v5.7.10, v5.4.53, v4.19.134, v4.14.189.
v5.7.10: Build OK!
v5.4.53: Build OK!
v4.1
Trying to grab dma_resv_lock while in commit_tail before we've done
all the code that leads to the eventual signalling of the vblank event
(which can be a dma_fence) is deadlock-y. Don't do that.
Here the solution is easy because just grabbing locks to read
something races anyway. We don't need to
On Mon, Jul 27, 2020 at 2:27 PM Michel Dänzer wrote:
>
> On 2020-07-25 1:26 a.m., Paulo Zanoni wrote:
> > Em seg, 2020-07-20 às 17:01 +0530, Karthik B S escreveu:
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_irq.c
> >> b/drivers/gpu/drm/i915/i915_irq.c
> >> index 1fa67700d8f4..95953b393941 10
Add a vga-switcheroo callback for reprobing displays. Use this new
callback to retrain the link on all DP encoders after a mux switch.
Signed-off-by: Daniel Dadap
---
drivers/gpu/drm/i915/i915_switcheroo.c | 27 +-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --g
Changes to allow vga-switcheroo to switch the mux while modesetting
clients remain active. There is existing support for switching the
mux without checking can_switch; however, this support also does not
reprobe after the mux switch is complete. This patch series adds a new
type of switch event whi
Attempting to commit a modeset while mux-switched away can cause
problems due to DisplayPort links being unavailable while they are
physically disconnected. In order to avoid this, bail out of atomic
commit early if attempted while a display mux is switched away.
Signed-off-by: Daniel Dadap
---
vga-switcheroo clients may wish to know whether they are currently
active, i.e., whether the mux is currently switched to the client
in question. Add an in-kernel API to test whether a vga-switcheroo
client, as identified by PCI device, is actively switched.
Signed-off-by: Daniel Dadap
---
drive
It is not possible to train a Displayport link while the lanes are
physically disconnected by a display mux. In order to prevent problems
associated with attempting to train a disconnected link, abort eDP
link training if the i915 GPU is not an active vga-switcheroo client.
This short circuit is eD
Add a new vga-switcheroo client callback to allow clients to register
for receiving notifications when a mux switch is pending, completed,
or failed. This allows individual client drivers to prepare for or
respond to mux switches to and from the registered client device.
Signed-off-by: Daniel Dada
vga-switcheroo supports the following types of mux switch events:
* standard: checks the clients' can_switch() callbacks and switches
the mux if the client drivers report that they are prepared for a
switch. Also uses client and handler callbacks to manage power on
the GPUs and reprobe displ
== Series Details ==
Series: drm/amdgpu/dc: Stop dma_resv_lock inversion in commit_tail
URL : https://patchwork.freedesktop.org/series/79937/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
be92e429f9aa drm/amdgpu/dc: Stop dma_resv_lock inversion in commit_tail
-:60: WARNING:NO_A
== Series Details ==
Series: drm/amdgpu/dc: Stop dma_resv_lock inversion in commit_tail
URL : https://patchwork.freedesktop.org/series/79937/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be checked separately.
_
== Series Details ==
Series: drm/amdgpu/dc: Stop dma_resv_lock inversion in commit_tail
URL : https://patchwork.freedesktop.org/series/79937/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8799 -> Patchwork_18246
Summary
---
== Series Details ==
Series: series starting with [1/6] vga-switcheroo: add new "immediate" switch
event type
URL : https://patchwork.freedesktop.org/series/79940/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
c641759bc9fc vga-switcheroo: add new "immediate" switch event type
== Series Details ==
Series: series starting with [1/6] vga-switcheroo: add new "immediate" switch
event type
URL : https://patchwork.freedesktop.org/series/79940/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be chec
== Series Details ==
Series: series starting with [1/6] vga-switcheroo: add new "immediate" switch
event type
URL : https://patchwork.freedesktop.org/series/79940/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8799 -> Patchwork_18247
==
== Series Details ==
Series: drm/amdgpu/dc: Stop dma_resv_lock inversion in commit_tail
URL : https://patchwork.freedesktop.org/series/79937/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8799_full -> Patchwork_18246_full
S
== Series Details ==
Series: series starting with [1/6] vga-switcheroo: add new "immediate" switch
event type
URL : https://patchwork.freedesktop.org/series/79940/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8799_full -> Patchwork_18247_full
On Mon, 2020-07-27 at 20:51 +, Patchwork wrote:
> Patch Details
> Series: drm/i915: Implement WA 14011294188 (rev2)
> URL: https://patchwork.freedesktop.org/series/79825/
> State:success
> Details:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18245/index.html
> CI B
Hi Nathan
Are you planning to check this regressions and send another version with the
fix?Or can I do it on top of your patch?
On Thu, 2020-07-16 at 05:06 +, Patchwork wrote:
> Patch Details
> Series: drm/i915/display: Ensure that ret is always initialized in
> icl_combo_phy_verify_s
On 2020.07.27 16:39:58 +, Vivi, Rodrigo wrote:
>
>
> > On Jul 21, 2020, at 5:42 PM, Zhenyu Wang wrote:
> >
> > On 2020.07.21 14:04:41 +0300, Joonas Lahtinen wrote:
> >> Quoting Zhenyu Wang (2020-07-20 11:05:41)
> >>>
> >>> Hi,
> >>>
> >>> Sorry that this might be a bit late as last week o
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/drm_gem.c
between commit:
8490d6a7e0a0 ("drm: hold gem reference until object is no longer accessed")
from the drm-misc-fixes tree and commit:
be6ee102341b ("drm: remove _unlocked suffix in drm_gem_objec
Hi Jose,
On Tue, Jul 28, 2020 at 01:47:56AM +, Souza, Jose wrote:
> Hi Nathan
>
> Are you planning to check this regressions and send another version with the
> fix?Or can I do it on top of your patch?
Unfortunately, I have had little time for kernel work (full time retail
worker in the mid
Am 27.07.20 um 23:30 schrieb Daniel Vetter:
Trying to grab dma_resv_lock while in commit_tail before we've done
all the code that leads to the eventual signalling of the vblank event
(which can be a dma_fence) is deadlock-y. Don't do that.
Here the solution is easy because just grabbing locks to
49 matches
Mail list logo
