Reference:
https://bugs.freedesktop.org/show_bug.cgi?id=112126
The issue we hit is the GPU keeps very high load after running
the subtest min-max-config-loaded.
Some background of the issue:
Currently the rps is not fully enabled yet on TGL, and running
the subtest min-max-config-loaded will hit
== Series Details ==
Series: drm/i915: Do not initialize display BW when display not available
URL : https://patchwork.freedesktop.org/series/69714/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7380 -> Patchwork_15339
Summ
On 2019/11/19 下午10:14, Jason Gunthorpe wrote:
On Tue, Nov 19, 2019 at 10:02:08PM +0800, Jason Wang wrote:
On 2019/11/19 下午8:38, Jason Gunthorpe wrote:
On Tue, Nov 19, 2019 at 10:41:31AM +0800, Jason Wang wrote:
On 2019/11/19 上午4:28, Jason Gunthorpe wrote:
On Mon, Nov 18, 2019 at 03:27:13PM -
On Tue, Nov 19, 2019 at 1:08 PM Daniel Vetter wrote:
>
> For locking semantics it really doesn't matter when we grab the
> ticket. But for lockdep validation it does: the acquire ctx is a fake
> lockdep. Since other drivers might want to do a full multi-lock dance
> in their fault-handler, not jus
== Series Details ==
Series: Skip MCHBAR queries when display is not available
URL : https://patchwork.freedesktop.org/series/69712/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7380 -> Patchwork_15338
Summary
---
*
When display is not available, finding the memory bandwidth available
for display is not useful. Skip this sequence here.
References: HSDES 1209978255
Signed-off-by: Stuart Summers
---
drivers/gpu/drm/i915/display/intel_bw.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm
== Series Details ==
Series: drm/i915/selftests: re-init the GT in live_gt_pm
URL : https://patchwork.freedesktop.org/series/69710/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7380 -> Patchwork_15337
Summary
---
**
== Series Details ==
Series: drm/i915: make pool objects read-only
URL : https://patchwork.freedesktop.org/series/69684/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7371_full -> Patchwork_15330_full
Summary
---
**S
Platforms without display do not map the MCHBAR MMIO into the GFX
device BAR. Skip this sequence when display is not available.
Signed-off-by: Stuart Summers
---
drivers/gpu/drm/i915/i915_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/
On 11/19/19 4:21 PM, Chris Wilson wrote:
Quoting Daniele Ceraolo Spurio (2019-11-20 00:04:25)
When GuC is in use we need to make sure it is re-loaded before the call
to gt_resume, otherwise communication from the engines to the GuC will
not be processed, which blocks the engines from ctx switc
Quoting Daniele Ceraolo Spurio (2019-11-20 00:04:25)
> When GuC is in use we need to make sure it is re-loaded before the call
> to gt_resume, otherwise communication from the engines to the GuC will
> not be processed, which blocks the engines from ctx switching and from
> being reset.
>
> Bugzil
On Fri, Nov 15, 2019 at 04:54:01PM +0200, Stanislav Lisovskiy wrote:
> According to BSpec 53998, we should try to
> restrict qgv points, which can't provide
> enough bandwidth for desired display configuration.
>
> Currently we are just comparing against all of
> those and take minimum(worst case)
@@ -220,7 +200,7 @@ static void guc_wq_item_append(struct intel_guc_client
*client,
GEM_BUG_ON(wq_off & (wqi_size - 1));
/* WQ starts from the page after process_desc */
Just realized that I stupidly forgot to actually commit the fix...
I'll send the fixed (for real) version a
When GuC is in use we need to make sure it is re-loaded before the call
to gt_resume, otherwise communication from the engines to the GuC will
not be processed, which blocks the engines from ctx switching and from
being reset.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112205
Cc: Andi
== Series Details ==
Series: drm/i915: Cleanups around .crtc_enable/disable() (rev4)
URL : https://patchwork.freedesktop.org/series/69352/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7371_full -> Patchwork_15329_full
Summ
On Fri, Nov 15, 2019 at 04:54:00PM +0200, Stanislav Lisovskiy wrote:
> Currently intel_can_enable_sagv function contains
> a mix of workarounds for different platforms
> some of them are not valid for gens >= 11 already,
> so lets split it into separate functions.
>
> v2:
> - Rework watermark
== Series Details ==
Series: i915/gem_mmap_gtt: Exercise many, many mappings of the same objects
URL : https://patchwork.freedesktop.org/series/69678/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7371_full -> IGTPW_3727_full
===
On Tue, 2019-11-19 at 22:57 +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915/gem: Ensure aperture exists before setting domain to
> GTT
> URL : https://patchwork.freedesktop.org/series/69698/
> State : failure
>
> == Summary ==
>
> CALLscripts/checksyscalls.sh
> CALL
Quoting Summers, Stuart (2019-11-19 22:58:38)
> On Tue, 2019-11-19 at 22:08 +, Chris Wilson wrote:
> > Quoting Stuart Summers (2019-11-19 21:30:32)
> > > mmap_gtt is already covered by a check for aperture presence.
> > > Also add the case to the gem_set_domain IOCTL to avoid this
> > > path fo
On Tue, 2019-11-19 at 22:08 +, Chris Wilson wrote:
> Quoting Stuart Summers (2019-11-19 21:30:32)
> > mmap_gtt is already covered by a check for aperture presence.
> > Also add the case to the gem_set_domain IOCTL to avoid this
> > path for unsupported platforms.
>
> It doesn't harm either, it
== Series Details ==
Series: drm/i915/gem: Ensure aperture exists before setting domain to GTT
URL : https://patchwork.freedesktop.org/series/69698/
State : failure
== Summary ==
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
DESCEND objtool
CHK include/gen
== Series Details ==
Series: more dma-buf lockdep priming
URL : https://patchwork.freedesktop.org/series/69695/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7380 -> Patchwork_15335
Summary
---
**SUCCESS**
No regr
== Series Details ==
Series: more dma-buf lockdep priming
URL : https://patchwork.freedesktop.org/series/69695/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
877e4edf1ff5 drm/modeset: Prime modeset lock vs dma_resv
-:68: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line b
Quoting Stuart Summers (2019-11-19 21:30:32)
> mmap_gtt is already covered by a check for aperture presence.
> Also add the case to the gem_set_domain IOCTL to avoid this
> path for unsupported platforms.
It doesn't harm either, it will just mean in a place where it is neither
in the GPU nor in th
Hi Vandita,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[cannot apply to v5.4-rc8 next-20191118]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' optio
mmap_gtt is already covered by a check for aperture presence.
Also add the case to the gem_set_domain IOCTL to avoid this
path for unsupported platforms.
Signed-off-by: Stuart Summers
---
drivers/gpu/drm/i915/gem/i915_gem_domain.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gp
On Fri, Nov 15, 2019 at 10:33:24AM +, Oleksandr Andrushchenko wrote:
> On 11/15/19 11:21 AM, Daniel Vetter wrote:
> > The current code is a pretty good wtf moment, since we drop the
> > reference before we use it. It's not a big deal, because a) we only
> > use the pointer, so doesn't blow up a
On Fri, Nov 15, 2019 at 03:21:20PM +0200, Jyri Sarha wrote:
> On 15/11/2019 11:21, Daniel Vetter wrote:
> > Doesn't do anything.
> >
> > Signed-off-by: Daniel Vetter
> > Cc: Jyri Sarha
> > Cc: Tomi Valkeinen
>
> Acked-by: Jyri Sarha
Thanks for taking a look, pushed to drm-misc-next.
-Daniel
On Fri, Nov 15, 2019 at 10:33:24AM +0100, Boris Brezillon wrote:
> On Fri, 15 Nov 2019 10:21:14 +0100
> Daniel Vetter wrote:
>
> > Spotted while looking through them all.
> >
> > Signed-off-by: Daniel Vetter
> > Cc: Sam Ravnborg
> > Cc: Boris Brezillon
>
> Acked-by: Boris Brezillon
Merged,
Hi,
On 19-11-2019 20:33, Patchwork wrote:
== Series Details ==
Series: drm/i915 / LPSS / mfd: Select correct PWM controller to use based on VBT
URL : https://patchwork.freedesktop.org/series/69686/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7377 -> Patchwork_15332
==
For locking semantics it really doesn't matter when we grab the
ticket. But for lockdep validation it does: the acquire ctx is a fake
lockdep. Since other drivers might want to do a full multi-lock dance
in their fault-handler, not just lock a single dma_resv. Therefore we
must init the acquire_ctx
It's kinda really hard to get this wrong on a driver with both display
and dma_resv locking. But who ever knows, so better to make sure that
really all drivers nest these the same way.
For actual lock semantics the acquire context nesting doesn't matter.
But to teach lockdep what's going on with w
Semnatically it really doesn't matter where we grab the ticket. But
since the ticket is a fake lockdep lock, it matters for lockdep
validation purposes.
This means stuff like grabbing a ticket and then doing
copy_from/to_user isn't allowed anymore. This is a changed compared to
the current ttm fau
Hi all,
While looking at (dynamic) dma-buf issues and ideas I've spotted a bit
more room for locking down the cross-driver dma_resv rules.
Only functional fallout is a tiny patch for msm, assuming I didn't botch
anything in the auditing of all relevant code.
Comments, review and testing very muc
Hi Vandita,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[cannot apply to v5.4-rc8 next-20191118]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' optio
Hi Vandita,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[cannot apply to v5.4-rc8 next-20191118]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' optio
Hi Vandita,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[cannot apply to v5.4-rc8 next-20191118]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base'
== Series Details ==
Series: drm/i915/selftests: Exercise rc6 w/a handling
URL : https://patchwork.freedesktop.org/series/69687/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7377 -> Patchwork_15333
Summary
---
**SUC
== Series Details ==
Series: series starting with [CI,1/2] drm/i915/gt: Move new timelines to the
end of active_list
URL : https://patchwork.freedesktop.org/series/69690/
State : failure
== Summary ==
Applying: drm/i915/gt: Move new timelines to the end of active_list
Using index info to reco
Hi Vandita,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[cannot apply to v5.4-rc8 next-20191118]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' optio
== Series Details ==
Series: drm/i915/selftests: Exercise rc6 w/a handling
URL : https://patchwork.freedesktop.org/series/69687/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
2337a2988c7f drm/i915/selftests: Exercise rc6 w/a handling
-:61: WARNING:FILE_PATH_CHANGES: added, move
== Series Details ==
Series: drm/i915 / LPSS / mfd: Select correct PWM controller to use based on VBT
URL : https://patchwork.freedesktop.org/series/69686/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7377 -> Patchwork_15332
===
== Series Details ==
Series: Add support for mipi dsi cmd mode (rev2)
URL : https://patchwork.freedesktop.org/series/69290/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7370_full -> Patchwork_15328_full
Summary
---
== Series Details ==
Series: drm/i915 / LPSS / mfd: Select correct PWM controller to use based on VBT
URL : https://patchwork.freedesktop.org/series/69686/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
076ee6713181 ACPI / LPSS: Rename pwm_backlight pwm-lookup to pwm_soc_backlig
== Series Details ==
Series: series starting with [01/19] drm/i915/selftests: Force bonded
submission to overlap (rev2)
URL : https://patchwork.freedesktop.org/series/69647/
State : failure
== Summary ==
Applying: drm/i915/selftests: Force bonded submission to overlap
Applying: drm/i915/gem:
Quoting Chris Wilson (2019-11-19 16:42:28)
> Quoting Tvrtko Ursulin (2019-11-19 16:33:18)
> > I also wonder if the current flush_submission wasn't the reason for
> > performance regression you were seeing with this? It makes this tasklet
> > wait for all other engines, if they are busy. But not s
== Series Details ==
Series: drm/i915/gem: Track ggtt writes from userspace on the bound vma
URL : https://patchwork.freedesktop.org/series/69672/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7370_full -> Patchwork_15326_full
==
Quoting Tvrtko Ursulin (2019-11-19 16:12:18)
>
> On 18/11/2019 23:02, Chris Wilson wrote:
> > Retire all requests if we resort to wedged the driver on suspend. They
> > will now be idle, so we might as we free them before shutting down.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/g
Hi,
On 19-11-2019 16:47, Ville Syrjälä wrote:
On Tue, Nov 19, 2019 at 04:18:18PM +0100, Hans de Goede wrote:
At least Bay Trail (BYT) and Cherry Trail (CHT) devices can use 1 of 2
different PWM controllers for controlling the LCD's backlight brightness.
Either the one integrated into the PMIC o
Chris Wilson writes:
concurrent pint? Sure, thirsty already.
But I am afraid you just mean concurrent pin :O
> In order to avoid some nasty mutex inversions, commit 09c5ab384f6f
> ("drm/i915: Keep rings pinned while the context is active") allowed the
> intel_ring unpinning to be run concurrent
On Tue, Nov 19, 2019 at 05:25:31AM +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915/tgl: Add DKL PHY vswing table for HDMI
> URL : https://patchwork.freedesktop.org/series/69639/
> State : success
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_7365_full -> Patchwork_
Quoting Tvrtko Ursulin (2019-11-19 16:33:18)
>
> On 19/11/2019 16:20, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-11-19 15:04:46)
> >>
> >> On 18/11/2019 23:02, Chris Wilson wrote:
> >>> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> >>> b/drivers/gpu/drm/i915/gt/intel_lrc.c
> >>> in
On Tue, Nov 19, 2019 at 10:07:18PM +0800, Jason Wang wrote:
>
> On 2019/11/19 下午8:40, Jason Gunthorpe wrote:
> > On Tue, Nov 19, 2019 at 11:03:39AM +0800, Jason Wang wrote:
> > > > Also, see the other conversations we are having about a "virtual" bus
> > > > and devices. I do not want to have two
Quoting Mika Kuoppala (2019-11-19 16:12:18)
> Chris Wilson writes:
>
> > When waiting for idle, serialise with any ongoing callback so that it
> > will have completed before completing the wait.
>
> Might be come apparent and evident when reading the patch
> that introduce the intel_wakeref_unlo
On 19/11/2019 16:20, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-11-19 15:04:46)
On 18/11/2019 23:02, Chris Wilson wrote:
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 33ce258d484f..f7c8fec436a9 100644
--- a/drivers/gpu/drm/i915/gt/intel_lr
On Tue, Nov 19, 2019 at 04:18:15PM +0100, Hans de Goede wrote:
> Hi All,
>
> This series needs to be merged through a single tree, to keep things
> bisectable. I have even considered just squashing all 3 patches into 1,
> but having separate commits seems better, but that does lead to an
> interme
When adding a new active timeline, place it at the end of the list. This
allows for intel_gt_retire_requests() to pick up the newcomer more
quickly and hopefully complete the retirement sooner. A miniscule
optimisation.
References: 7936a22dd466 ("drm/i915/gt: Wait for new requests in
intel_gt_ret
As we may park the gt during request retirement, we may then cancel the
retirement worker only to then program the delayed worker once more.
If we schedule the next delayed retirement worker first, if we then park
the gt, the work remain cancelled [until we unpark].
Signed-off-by: Chris Wilson
R
Chris Wilson writes:
> Since igt now defaults to not enabling ftrace-on-oops, we need to
> manually invoke GEM_TRACE_DUMP() to see the debug log prior to a
> GEM_BUG_ON panicking.
>
> Signed-off-by: Chris Wilson
Acked-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_gem.h | 3 +++
> 1 fil
Quoting Tvrtko Ursulin (2019-11-19 15:04:46)
>
> On 18/11/2019 23:02, Chris Wilson wrote:
> > diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> > b/drivers/gpu/drm/i915/gt/intel_lrc.c
> > index 33ce258d484f..f7c8fec436a9 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> > +++ b/drivers/gpu/
On 18/11/2019 23:02, Chris Wilson wrote:
When waiting for idle, serialise with any ongoing callback so that it
will have completed before completing the wait.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_wakeref.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(
Chris Wilson writes:
> When waiting for idle, serialise with any ongoing callback so that it
> will have completed before completing the wait.
Might be come apparent and evident when reading the patch
that introduce the intel_wakeref_unlock_wait(),
but reader is yearning for a why part.
The 'wa
On 18/11/2019 23:02, Chris Wilson wrote:
Retire all requests if we resort to wedged the driver on suspend. They
will now be idle, so we might as we free them before shutting down.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_gt_pm.c | 1 +
1 file changed, 1 insertion(+)
di
Quoting Tvrtko Ursulin (2019-11-19 15:57:24)
>
> On 18/11/2019 23:02, Chris Wilson wrote:
> > diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> > b/drivers/gpu/drm/i915/gt/intel_lrc.c
> > index f7c8fec436a9..fec46afb9264 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> > +++ b/drivers/gpu/
On 18/11/2019 23:02, Chris Wilson wrote:
As we may park the gt during request retirement, we may then cancel the
retirement worker only to then program the delayed worker once more.
If we schedule the next delayed retirement worker first, if we then park
the gt, the work remain cancelled [until
== Series Details ==
Series: drm/i915: make pool objects read-only
URL : https://patchwork.freedesktop.org/series/69684/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7371 -> Patchwork_15330
Summary
---
**SUCCESS**
On 18/11/2019 23:02, Chris Wilson wrote:
When adding a new active timeline, place it at the end of the list. This
allows for intel_gt_retire_requests() to pick up the newcomer more
quickly and hopefully complete the retirement sooner.
References: 7936a22dd466 ("drm/i915/gt: Wait for new request
On 18/11/2019 23:02, Chris Wilson wrote:
Now that we never allow the intel_wakeref callbacks to be invoked from
interrupt context, we do not need the irqsafe spinlock for the timeline.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_gt_requests.c | 9 -
drivers/gpu/dr
On 18/11/2019 23:02, Chris Wilson wrote:
Previously, we assumed we could use mutex_trylock() within an atomic
context, falling back to a working if contended. However, such trickery
is illegal inside interrupt context, and so we need to always use a
worker under such circumstances. As we normall
On Tue, 19 Nov 2019, Vandita Kulkarni wrote:
> As per the Bspec, port mapping is fixed for mipi dsi.
>
> v2: Reuse the existing function (Jani)
>
> Signed-off-by: Vandita Kulkarni
Pushed, thanks for the patch.
BR,
Jani.
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 17 +++
Reading from CTX_INFO upsets rc6, requiring us to detect and prevent
possible rc6 context corruption. Poke at the bear!
Signed-off-by: Chris Wilson
Cc: Imre Deak
Cc: Mika Kuoppala
Reviewed-by: Andi Shyti
Tested-by: Andi Shyti
---
drivers/gpu/drm/i915/gt/intel_rc6.c | 4 +
drivers
On Tue, Nov 19, 2019 at 04:18:18PM +0100, Hans de Goede wrote:
> At least Bay Trail (BYT) and Cherry Trail (CHT) devices can use 1 of 2
> different PWM controllers for controlling the LCD's backlight brightness.
> Either the one integrated into the PMIC or the one integrated into the
> SoC (the 1st
On Tue, 19 Nov 2019, Hans de Goede wrote:
> Hi All,
>
> This series needs to be merged through a single tree, to keep things
> bisectable. I have even considered just squashing all 3 patches into 1,
> but having separate commits seems better, but that does lead to an
> intermediate state where the
On 11/19/19 12:46 AM, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20191118:
on x86_64:
ERROR: "pm_suspend_target_state" [drivers/gpu/drm/i915/i915.ko] undefined!
# CONFIG_SUSPEND is not set
--
~Randy
Reported-by: Randy Dunlap
___
Intel-gfx
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-Schedule-request-retirement-when-submission-idles/20191119-023819
b
Quoting Andi Shyti (2019-11-19 15:24:59)
> Hi Chris,
>
> On Tue, Nov 19, 2019 at 10:09:29AM +, Chris Wilson wrote:
> > Reading from CTX_INFO upsets rc6, requiring us to detect and prevent
> > possible rc6 context corruption. Poke at the bear!
> >
> > Signed-off-by: Chris Wilson
> > Cc: Imre
Hi Chris,
On Tue, Nov 19, 2019 at 10:09:29AM +, Chris Wilson wrote:
> Reading from CTX_INFO upsets rc6, requiring us to detect and prevent
> possible rc6 context corruption. Poke at the bear!
>
> Signed-off-by: Chris Wilson
> Cc: Imre Deak
> Cc: Mika Kuoppala
it looks good,
Reviewed-by:
== Series Details ==
Series: drm/i915: Cleanups around .crtc_enable/disable() (rev4)
URL : https://patchwork.freedesktop.org/series/69352/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7371 -> Patchwork_15329
Summary
--
At least Bay Trail (BYT) and Cherry Trail (CHT) devices can use 1 of 2
different PWM controllers for controlling the LCD's backlight brightness.
Either the one integrated into the PMIC or the one integrated into the
SoC (the 1st LPSS PWM controller).
So far in the LPSS code on BYT we have skipped
Hi All,
This series needs to be merged through a single tree, to keep things
bisectable. I have even considered just squashing all 3 patches into 1,
but having separate commits seems better, but that does lead to an
intermediate state where the backlight sysfs interface will be broken
(and fixed 2
At least Bay Trail (BYT) and Cherry Trail (CHT) devices can use 1 of 2
different PWM controllers for controlling the LCD's backlight brightness.
Either the one integrated into the PMIC or the one integrated into the
SoC (the 1st LPSS PWM controller).
So far in the LPSS code on BYT we have skipped
At least Bay Trail (BYT) and Cherry Trail (CHT) devices can use 1 of 2
different PWM controllers for controlling the LCD's backlight brightness.
Either the one integrated into the PMIC or the one integrated into the
SoC (the 1st LPSS PWM controller).
So far in the LPSS code on BYT we have skipped
Quoting Matthew Auld (2019-11-19 15:01:54)
> For our current users we don't expect pool objects to be writable from
> the gpu.
>
Fixes: 4f7af1948abc ("drm/i915: Support ro ppgtt mapped cmdparser shadow
buffers")
> Signed-off-by: Matthew Auld
> Cc: Chris Wilson
Reviewed-by: Chris Wilson
-Chris
On 18/11/2019 23:02, Chris Wilson wrote:
The major drawback of commit 7e34f4e4aad3 ("drm/i915/gen8+: Add RC6 CTX
corruption WA") is that it disables RC6 while Skylake (and friends) is
active, and we do not consider the GPU idle until all outstanding
requests have been retired and the engine swit
In commit a79ca656b648 ("drm/i915: Push the wakeref->count deferral to
the backend"), I erroneously concluded that we last modify the engine
inside __i915_request_commit() meaning that we could enable concurrent
submission for userspace as we enqueued this request. However, this
falls into a trap w
For our current users we don't expect pool objects to be writable from
the gpu.
Signed-off-by: Matthew Auld
Cc: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_engine_pool.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pool.c
b/drivers/gpu/drm/i915/
== Series Details ==
Series: i915/gem_mmap_gtt: Exercise many, many mappings of the same objects
URL : https://patchwork.freedesktop.org/series/69678/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7371 -> IGTPW_3727
Summary
Chris Wilson writes:
> When userspace writes into the GTT itself, it is supposed to call
> set-domain to let the kernel keep track and so manage the CPU/GPU
> caches. As we track writes on the individual i915_vma, we should also be
> sure to mark them as dirty.
>
> Signed-off-by: Chris Wilson
>
On 18/11/2019 23:02, Chris Wilson wrote:
In order to avoid some nasty mutex inversions, commit 09c5ab384f6f
("drm/i915: Keep rings pinned while the context is active") allowed the
intel_ring unpinning to be run concurrently with the next context
pinning it. Thus each step in intel_ring_unpin() n
Quoting Tvrtko Ursulin (2019-11-19 14:35:04)
>
> On 18/11/2019 23:02, Chris Wilson wrote:
> > In commit a79ca656b648 ("drm/i915: Push the wakeref->count deferral to
> > the backend"), I erroneously concluded that we last modify the engine
> > inside __i915_request_commit() meaning that we could en
== Series Details ==
Series: series starting with [01/17] drm/i915/gem: Manually dump the debug
trace on GEM_BUG_ON
URL : https://patchwork.freedesktop.org/series/69669/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7370_full -> Patchwork_15325_full
==
== Series Details ==
Series: i915/gem_mmap_gtt: Exercise many, many mappings of the same objects
URL : https://patchwork.freedesktop.org/series/69678/
State : warning
== Summary ==
Did not get list of undocumented tests for this run, something is wrong!
Other than that, pipeline status: FAILE
Quoting Tvrtko Ursulin (2019-11-19 14:15:49)
>
> On 18/11/2019 23:02, Chris Wilson wrote:
> > The general concept was that intel_timeline.active_count was locked by
> > the intel_timeline.mutex. The exception was for power management, where
> > the engine->kernel_context->timeline could be manipul
On 18/11/2019 23:02, Chris Wilson wrote:
In commit a79ca656b648 ("drm/i915: Push the wakeref->count deferral to
the backend"), I erroneously concluded that we last modify the engine
inside __i915_request_commit() meaning that we could enable concurrent
submission for userspace as we enqueued thi
On Mon, Nov 18, 2019 at 08:00:07PM -, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Cleanups around .crtc_enable/disable() (rev3)
> URL : https://patchwork.freedesktop.org/series/69352/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_7365 -> Patchwo
Fork and remap the same object into a new process space under a new file
descriptor. Principally to check list management and find scaling issues
in using such lists.
Signed-off-by: Chris Wilson
Cc: Abdiel Janulgue
---
tests/i915/gem_mmap_gtt.c | 72 ++-
1 fi
On 18/11/2019 23:02, Chris Wilson wrote:
The general concept was that intel_timeline.active_count was locked by
the intel_timeline.mutex. The exception was for power management, where
the engine->kernel_context->timeline could be manipulated under the
global wakeref.mutex.
This was quite solid,
On Tue, Nov 19, 2019 at 10:02:08PM +0800, Jason Wang wrote:
>
> On 2019/11/19 下午8:38, Jason Gunthorpe wrote:
> > On Tue, Nov 19, 2019 at 10:41:31AM +0800, Jason Wang wrote:
> > > On 2019/11/19 上午4:28, Jason Gunthorpe wrote:
> > > > On Mon, Nov 18, 2019 at 03:27:13PM -0500, Michael S. Tsirkin wrote
On 2019/11/19 下午8:40, Jason Gunthorpe wrote:
On Tue, Nov 19, 2019 at 11:03:39AM +0800, Jason Wang wrote:
Also, see the other conversations we are having about a "virtual" bus
and devices. I do not want to have two different ways of doing the same
thing in the kernel at the same time please. P
On 2019/11/19 下午8:38, Jason Gunthorpe wrote:
On Tue, Nov 19, 2019 at 10:41:31AM +0800, Jason Wang wrote:
On 2019/11/19 上午4:28, Jason Gunthorpe wrote:
On Mon, Nov 18, 2019 at 03:27:13PM -0500, Michael S. Tsirkin wrote:
On Mon, Nov 18, 2019 at 01:41:00PM +, Jason Gunthorpe wrote:
On Mon, N
1 - 100 of 161 matches
Mail list logo
