On Mon, Sep 14, 2020 at 11:24 PM Herbert Xu wrote:
>
> On Tue, Sep 15, 2020 at 09:20:59AM +0300, Ard Biesheuvel wrote:
> >
> > The documentation of kmap_atomic() states the following:
> >
> > * The use of kmap_atomic/kunmap_atomic is discouraged - kmap/kunmap
> > * gives a more generic (and cach
On Tue, Sep 15, 2020 at 09:20:59AM +0300, Ard Biesheuvel wrote:
>
> The documentation of kmap_atomic() states the following:
>
> * The use of kmap_atomic/kunmap_atomic is discouraged - kmap/kunmap
> * gives a more generic (and caching) interface. But kmap_atomic can
> * be used in IRQ contexts,
== Series Details ==
Series: drm/i915: Fix the race between the GEM close and debugfs (rev2)
URL : https://patchwork.freedesktop.org/series/81646/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9008 -> Patchwork_18497
Summar
As we close GEM object and set file_priv to -EBADF which is protected
by ctx->mutex, populating the GEM debugfs info is not protected
and results in the crash shown below.
Make sure to protect the access to file_priv using ctx->mutex to avoid
race.
BUG: unable to handle page fault for address: ff
On Mon, Sep 14, 2020 at 03:37:49PM -0700, Linus Torvalds wrote:
>
> So it _looks_ like this code started using kmap() - probably back when
> kmap_atomic() was so cumbersome to use - and was then converted
> (conditionally) to kmap_atomic() rather than just changed whole-sale.
> Is there actually so
Hi Tvrtko,
On 9/14/20 4:04 PM, Tvrtko Ursulin wrote:
Hi,
On 12/09/2020 04:21, Lu Baolu wrote:
Tom Murphy has almost done all the work. His latest patch series was
posted here.
https://lore.kernel.org/linux-iommu/20200903201839.7327-1-murph...@tcd.ie/
Thanks a lot!
This series is a follow-u
== Series Details ==
Series: drm/i915/pll: Centralize PLL_ENABLE register lookup (rev5)
URL : https://patchwork.freedesktop.org/series/81150/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9007_full -> Patchwork_18494_full
S
== Series Details ==
Series: series starting with [1/2] drm/i915: Reduce INTEL_DISPLAY_ENABLED to
just removing the outputs (rev4)
URL : https://patchwork.freedesktop.org/series/81507/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9007_full -> Patchwork_18492_full
===
== Series Details ==
Series: Per client engine busyness
URL : https://patchwork.freedesktop.org/series/81652/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9007_full -> Patchwork_18491_full
Summary
---
**SUCCESS**
> On Sep 14, 2020, at 1:05 PM, Vivi, Rodrigo wrote:
>
>
>
>> On Sep 11, 2020, at 9:00 PM, Dhanavanthri, Swathi
>> wrote:
>>
>> It is in the if statement: if (IS_ROCKETLAKE(i915) || IS_TIGERLAKE(i915)) {
>
> duh! sorry...
>
> more below:
>
>>
>> -Original Message-
>> From: Rodr
On Mon, Sep 14, 2020 at 3:24 PM Linus Torvalds
wrote:
>
> Ard and Herbert added to participants: see
> chacha20poly1305_crypt_sg_inplace(), which does
>
> flags = SG_MITER_TO_SG;
> if (!preemptible())
> flags |= SG_MITER_ATOMIC;
>
> introduced in commit d95312a3ccc0
On Mon, Sep 14, 2020 at 2:55 PM Thomas Gleixner wrote:
>
> Yes it does generate better code, but I tried hard to spot a difference
> in various metrics exposed by perf. It's all in the noise and I only
> can spot a difference when the actual preemption check after the
> decrement
I'm somewhat mor
== Series Details ==
Series: Enable HDR on MCA LSPCON based Gen9 devices (rev6)
URL : https://patchwork.freedesktop.org/series/68081/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9008 -> Patchwork_18495
Summary
---
== Series Details ==
Series: preempt: Make preempt count unconditional
URL : https://patchwork.freedesktop.org/series/81661/
State : failure
== Summary ==
Applying: lib/debug: Remove pointless ARCH_NO_PREEMPT dependencies
Applying: preempt: Make preempt count unconditional
Applying: preempt: C
On Mon, Sep 14 2020 at 13:59, Linus Torvalds wrote:
> On Mon, Sep 14, 2020 at 1:45 PM Thomas Gleixner wrote:
>>
>> Recently merged code does:
>>
>> gfp = preemptible() ? GFP_KERNEL : GFP_ATOMIC;
>>
>> Looks obviously correct, except for the fact that preemptible() is
>> unconditionally fa
== Series Details ==
Series: Enable HDR on MCA LSPCON based Gen9 devices (rev6)
URL : https://patchwork.freedesktop.org/series/68081/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+drivers/gpu/
On Mon, Sep 14, 2020 at 1:45 PM Thomas Gleixner wrote:
>
> Recently merged code does:
>
> gfp = preemptible() ? GFP_KERNEL : GFP_ATOMIC;
>
> Looks obviously correct, except for the fact that preemptible() is
> unconditionally false for CONFIF_PREEMPT_COUNT=n, i.e. all allocations in
> tha
On Mon, 2020-09-14 at 23:30 +0300, Ville Syrjälä wrote:
> On Mon, Sep 14, 2020 at 07:57:34PM +, Souza, Jose wrote:
> > On Mon, 2020-09-14 at 17:24 +0300, Ville Syrjälä wrote:
> > > On Mon, Aug 31, 2020 at 06:09:22PM -0700, José Roberto de Souza wrote:
> > > > In case PSR2 is disabled by debugfs
CONFIG_PREEMPT_COUNT is now unconditionally enabled and will be
removed. Cleanup the leftovers before doing so.
Signed-off-by: Thomas Gleixner
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Juri Lelli
Cc: Vincent Guittot
Cc: Dietmar Eggemann
Cc: Steven Rostedt
Cc: Ben Segall
Cc: Mel Gorman
Cc: Da
Folks!
While working on various preempt count related things, I stumbled (again)
over the inconsistency of our preempt count handling.
The handling of preempt_count() is inconsistent accross kernel
configurations. On kernels which have PREEMPT_COUNT=n
preempt_disable/enable() and the lock/unlock
CONFIG_PREEMPT_COUNT is now unconditionally enabled and will be
removed. Cleanup the leftovers before doing so.
Signed-off-by: Thomas Gleixner
Cc: Chris Zankel
Cc: Max Filippov
Cc: linux-xte...@linux-xtensa.org
---
arch/xtensa/kernel/entry.S |2 +-
1 file changed, 1 insertion(+), 1 deletio
On Mon, 14 Sep 2020 22:42:09 +0200
Thomas Gleixner wrote:
> 21 files changed, 23 insertions(+), 92 deletions(-)
This alone makes it look promising, and hopefully acceptable by Linus :-)
-- Steve
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.o
CONFIG_PREEMPT_COUNT is now unconditionally enabled and will be
removed. Cleanup the leftovers before doing so.
Signed-off-by: Thomas Gleixner
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: David Airlie
Cc: Daniel Vetter
Cc: intel-gfx@lists.freedesktop.org
Cc: dri-de...@lists.freed
CONFIG_PREEMPT_COUNT is now unconditionally enabled and will be
removed. Cleanup the leftovers before doing so.
Signed-off-by: Thomas Gleixner
---
include/linux/uaccess.h |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/include/linux/uaccess.h
+++ b/include/linux/uaccess.h
@
CONFIG_PREEMPT_COUNT is now unconditionally enabled and will be
removed. Cleanup the leftovers before doing so.
Signed-off-by: Thomas Gleixner
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Will Deacon
---
include/linux/lockdep.h |6 ++
lib/Kconfig.debug |1 -
2 files changed, 2 ins
CONFIG_PREEMPT_COUNT is now unconditionally enabled and will be
removed. Cleanup the leftovers before doing so.
Signed-off-by: Thomas Gleixner
Cc: "Paul E. McKenney"
Cc: Josh Triplett
Cc: Steven Rostedt
Cc: Mathieu Desnoyers
Cc: Lai Jiangshan
Cc: Shuah Khan
Cc: r...@vger.kernel.org
Cc: linu
CONFIG_PREEMPT_COUNT is now unconditionally enabled and will be
removed. Cleanup the leftovers before doing so.
Signed-off-by: Thomas Gleixner
Cc: Andrew Morton
Cc: linux...@kvack.org
---
include/linux/pagemap.h |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
--- a/include/linux/pa
All conditionals and irritations are gone.
Signed-off-by: Thomas Gleixner
---
kernel/Kconfig.preempt |3 ---
1 file changed, 3 deletions(-)
--- a/kernel/Kconfig.preempt
+++ b/kernel/Kconfig.preempt
@@ -74,8 +74,5 @@ config PREEMPT_RT
endchoice
-config PREEMPT_COUNT
- def_bool y
-
The handling of preempt_count() is inconsistent accross kernel
configurations. On kernels which have PREEMPT_COUNT=n
preempt_disable/enable() and the lock/unlock functions are not affecting
the preempt count, only local_bh_disable/enable() and _bh variants of
locking, soft interrupt delivery, hard
CONFIG_PREEMPT_COUNT is now unconditionally enabled and will be
removed. Cleanup the leftovers before doing so.
Signed-off-by: Thomas Gleixner
Cc: Russell King
Cc: linux-arm-ker...@lists.infradead.org
---
arch/arm/include/asm/assembler.h | 11 ---
arch/arm/kernel/iwmmxt.S
ARCH_NO_PREEMPT disables the selection of CONFIG_PREEMPT_VOLUNTARY and
CONFIG_PREEMPT, but architectures which set this config option still
support preempt count for hard and softirq accounting.
There is absolutely no reason to prevent lockdep from using the preempt
counter nor is there a reason t
CONFIG_PREEMPT_COUNT is now unconditionally enabled and will be
removed. Cleanup the leftovers before doing so.
Signed-off-by: Thomas Gleixner
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Juri Lelli
Cc: Vincent Guittot
Cc: Dietmar Eggemann
Cc: Steven Rostedt
Cc: Ben Segall
Cc: Mel Gorman
Cc: Da
CONFIG_PREEMPT_COUNT is now unconditionally enabled and will be
removed. Cleanup the leftovers before doing so.
Signed-off-by: Thomas Gleixner
---
include/linux/bit_spinlock.h |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
--- a/include/linux/bit_spinlock.h
+++ b/include/linux/bit_
igt@core_hotunplug@hotrebind-lateclose test is not yet in CI bug log. Otherwise
I filed the issue https://gitlab.freedesktop.org/drm/intel/-/issues/2464
Thanks,
Lakshmi.
-Original Message-
From: Janusz Krzysztofik
Sent: Monday, September 14, 2020 12:31 PM
To: Winiarski, Michal ;
igt-.
On Mon, Sep 14, 2020 at 07:57:34PM +, Souza, Jose wrote:
> On Mon, 2020-09-14 at 17:24 +0300, Ville Syrjälä wrote:
> > On Mon, Aug 31, 2020 at 06:09:22PM -0700, José Roberto de Souza wrote:
> > > In case PSR2 is disabled by debugfs dc3co_enabled and
> > > psr2_sel_fetch_enabled were still being
Blanking needs to be reduced to incorporate DP and HDMI timing/link
bandwidth limitations for CEA modes (4k@60 at 10 bpp). DP can drive
17.28Gbs while 4k modes (VIC97 etc) at 10 bpp required 17.8 Gbps.
This will cause mode to blank out. Reduced Htotal by shortening the
back porch and front porch wi
Enable Colorspace as BT2020 if driving HDR content.Sending Colorimetry
data for HDR using AVI infoframe. LSPCON firmware expects this and though
SOC drives DP, for HDMI panel AVI infoframe is sent to the LSPCON device
which transfers the same to HDMI sink.
v2: Dropped state managed in drm core as
Enable HDR for LSPCON based on Parade along with MCA.
Signed-off-by: Uma Shankar
Signed-off-by: Vipin Anand
---
drivers/gpu/drm/i915/display/intel_lspcon.c | 19 ---
1 file changed, 8 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c
b/dri
Gen9 hardware supports HDMI2.0 through LSPCON chips.
Extending HDR support for MCA LSPCON based GEN9 devices.
SOC will drive LSPCON as DP and send HDR metadata as standard
DP SDP packets. LSPCON will be set to operate in PCON mode,
will receive the metadata and create Dynamic Range and
Mastering I
Lspcon has Infoframes as well as DIP for HDR metadata(DRM Infoframe).
Create a separate mechanism for lspcon compared to HDMI in order to
address the same and ensure future scalability.
Suggested-by: Ville Syrjälä
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_ddi.c| 10 +
Non-HDMI sinks shouldn't be sent Dynamic Range and Mastering infoframes.
Check for that when using LSPCON.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_ddi.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.
Attach HDR property for Gen9 devices with MCA LSPCON
chips.
v2: Cleaned HDR property attachment logic based on capability
as per Jani Nikula's suggestion.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_lspcon.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/
From: Ville Syrjälä
Non-HDMI sinks shouldn't be sent infoframes. Check for that when
using LSPCON.
FIXME: How do we turn off infoframes once enabled? Do we even
have to?
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 10 --
drivers/gpu/drm
Implemented Infoframes enabled readback for LSPCON devices.
This will help align the implementation with state readback
infrastructure.
v2: Added proper bitmask of enabled infoframes as per Ville's
recommendation.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_lspcon.c | 57 +
LSPCON firmware exposes HDR capability through LPCON_CAPABILITIES
DPCD register. LSPCON implementations capable of supporting
HDR set HDR_CAPABILITY bit in LSPCON_CAPABILITIES to 1. This patch
reads the same, detects the HDR capability and adds this to
intel_lspcon struct.
v2: Addressed Jani Nikul
Gen9 hardware supports HDMI2.0 through LSPCON chips. Extending HDR
support for MCA and Parade LSPCON based GEN9 devices.
SOC will drive LSPCON as DP and send HDR metadata as standard
DP SDP packets. LSPCON will be set to operate in PCON mode,
will receive the metadata and create Dynamic Range and
Implement Read back of HDR metadata infoframes i.e Dynamic Range
and Mastering Infoframe for LSPCON devices.
v2: Added proper bitmask of enabled infoframes as per Ville's
recommendation.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_hdmi.c | 10 ++
drivers/gpu/drm/
On Mon, Sep 07, 2020 at 08:12:56PM +0200, Daniel Vetter wrote:
> On Mon, Sep 07, 2020 at 03:00:25PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > The timestamping constants have nothing to do with any legacy state
> > so should not be updated from
> > drm_atomic_helper_update_legacy
On Mon, 2020-09-14 at 17:28 +0300, Ville Syrjälä wrote:
> On Mon, Aug 31, 2020 at 06:09:23PM -0700, José Roberto de Souza wrote:
> > Another step towards PSR2 selective fetch, here programming plane
> > selective fetch registers and MAN_TRK_CTL enabling selective fetch but
> > for now it is fetchin
On Mon, Sep 14, 2020 at 12:45:59PM -0700, Navare, Manasi wrote:
> On Mon, Sep 14, 2020 at 10:34:12PM +0300, Ville Syrjälä wrote:
> > On Mon, Sep 14, 2020 at 12:27:58PM -0700, Navare, Manasi wrote:
> > > On Mon, Sep 14, 2020 at 10:20:41PM +0300, Ville Syrjälä wrote:
> > > > On Mon, Sep 14, 2020 at 1
> On Sep 11, 2020, at 9:00 PM, Dhanavanthri, Swathi
> wrote:
>
> It is in the if statement: if (IS_ROCKETLAKE(i915) || IS_TIGERLAKE(i915)) {
duh! sorry...
more below:
>
> -Original Message-
> From: Rodrigo Vivi
> Sent: Friday, September 11, 2020 6:10 PM
> To: Dhanavanthri, Swath
On Mon, 2020-09-14 at 17:24 +0300, Ville Syrjälä wrote:
> On Mon, Aug 31, 2020 at 06:09:22PM -0700, José Roberto de Souza wrote:
> > In case PSR2 is disabled by debugfs dc3co_enabled and
> > psr2_sel_fetch_enabled were still being set causing some code paths
> > to be executed were it should not.
>
On Mon, Sep 14, 2020 at 12:38:57PM -0700, Navare, Manasi wrote:
> On Mon, Sep 14, 2020 at 10:17:57PM +0300, Ville Syrjälä wrote:
> > On Mon, Sep 14, 2020 at 12:00:33PM -0700, Navare, Manasi wrote:
> > > On Mon, Sep 07, 2020 at 02:20:56PM +0300, Ville Syrjälä wrote:
> > > > On Wed, Jul 15, 2020 at 0
On Mon, 2020-09-14 at 17:50 +0100, Matthew Wilcox wrote:
> On Mon, Sep 14, 2020 at 12:17:07PM -0400, Qian Cai wrote:
> > Reverting the "Return head pages from find_*_entry" patchset [1] up to this
> > patch fixed the issue that LTP madvise06 test [2] would trigger endless
> > soft-
> > lockups belo
On Mon, Sep 14, 2020 at 10:34:12PM +0300, Ville Syrjälä wrote:
> On Mon, Sep 14, 2020 at 12:27:58PM -0700, Navare, Manasi wrote:
> > On Mon, Sep 14, 2020 at 10:20:41PM +0300, Ville Syrjälä wrote:
> > > On Mon, Sep 14, 2020 at 12:14:10PM -0700, Navare, Manasi wrote:
> > > > On Thu, Sep 03, 2020 at 1
On Mon, Sep 14, 2020 at 10:17:57PM +0300, Ville Syrjälä wrote:
> On Mon, Sep 14, 2020 at 12:00:33PM -0700, Navare, Manasi wrote:
> > On Mon, Sep 07, 2020 at 02:20:56PM +0300, Ville Syrjälä wrote:
> > > On Wed, Jul 15, 2020 at 03:42:15PM -0700, Manasi Navare wrote:
> > > > From: Maarten Lankhorst
>
On Mon, Sep 14, 2020 at 12:27:58PM -0700, Navare, Manasi wrote:
> On Mon, Sep 14, 2020 at 10:20:41PM +0300, Ville Syrjälä wrote:
> > On Mon, Sep 14, 2020 at 12:14:10PM -0700, Navare, Manasi wrote:
> > > On Thu, Sep 03, 2020 at 10:19:45PM +0300, Ville Syrjälä wrote:
> > > > On Wed, Jul 15, 2020 at 0
Am 14.09.20 um 17:05 schrieb Thomas Zimmermann:
Hi
Am 13.08.20 um 12:22 schrieb Christian König:
Am 13.08.20 um 10:36 schrieb Thomas Zimmermann:
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instan
On Mon, 2020-09-14 at 20:18 +0200, Michał Winiarski wrote:
> Quoting Janusz Krzysztofik (2020-09-11 12:30:15)
> > Clean up the test code, add some new basic subtests, then unblock
> > unbind test variants.
> >
> > No incompletes / aborts nor subsequently run test issues have been
> > reported by T
On Mon, Sep 14, 2020 at 10:20:41PM +0300, Ville Syrjälä wrote:
> On Mon, Sep 14, 2020 at 12:14:10PM -0700, Navare, Manasi wrote:
> > On Thu, Sep 03, 2020 at 10:19:45PM +0300, Ville Syrjälä wrote:
> > > On Wed, Jul 15, 2020 at 03:42:19PM -0700, Manasi Navare wrote:
> > > > From: Maarten Lankhorst
>
On Mon, Sep 14, 2020 at 12:14:10PM -0700, Navare, Manasi wrote:
> On Thu, Sep 03, 2020 at 10:19:45PM +0300, Ville Syrjälä wrote:
> > On Wed, Jul 15, 2020 at 03:42:19PM -0700, Manasi Navare wrote:
> > > From: Maarten Lankhorst
> > >
> > > Make sure that when a plane is set in a bigjoiner mode, we
On Thu, Sep 03, 2020 at 10:23:35PM +0300, Ville Syrjälä wrote:
> On Wed, Jul 15, 2020 at 03:42:21PM -0700, Manasi Navare wrote:
> > From: Maarten Lankhorst
> >
> > Enabling is done in a special sequence and so should plane updates
> > be. Ideally the end user never notices the second pipe is used
On Mon, Sep 14, 2020 at 12:00:33PM -0700, Navare, Manasi wrote:
> On Mon, Sep 07, 2020 at 02:20:56PM +0300, Ville Syrjälä wrote:
> > On Wed, Jul 15, 2020 at 03:42:15PM -0700, Manasi Navare wrote:
> > > From: Maarten Lankhorst
> > >
> > > Small changes to intel_dp_mode_valid(), allow listing modes
On Thu, Sep 03, 2020 at 10:19:45PM +0300, Ville Syrjälä wrote:
> On Wed, Jul 15, 2020 at 03:42:19PM -0700, Manasi Navare wrote:
> > From: Maarten Lankhorst
> >
> > Make sure that when a plane is set in a bigjoiner mode, we will add
> > their counterpart to the atomic state as well. This will al
== Series Details ==
Series: drm/i915/pll: Centralize PLL_ENABLE register lookup (rev5)
URL : https://patchwork.freedesktop.org/series/81150/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9007 -> Patchwork_18494
Summary
---
On Mon, Sep 07, 2020 at 02:20:56PM +0300, Ville Syrjälä wrote:
> On Wed, Jul 15, 2020 at 03:42:15PM -0700, Manasi Navare wrote:
> > From: Maarten Lankhorst
> >
> > Small changes to intel_dp_mode_valid(), allow listing modes that
> > can only be supported in the bigjoiner configuration, which is
>
On Mon, Sep 14, 2020 at 11:32:48AM -0700, Navare, Manasi wrote:
> On Mon, Sep 07, 2020 at 03:35:23PM +0300, Ville Syrjälä wrote:
> > On Thu, Sep 03, 2020 at 09:40:44PM +0300, Ville Syrjälä wrote:
> > > On Thu, Sep 03, 2020 at 11:04:33AM -0700, Navare, Manasi wrote:
> > > > On Thu, Sep 03, 2020 at 0
On Mon, Sep 14, 2020 at 11:45:37AM -0700, Navare, Manasi wrote:
> On Thu, Sep 03, 2020 at 08:54:40PM +0300, Ville Syrjälä wrote:
> > On Wed, Jul 15, 2020 at 03:42:14PM -0700, Manasi Navare wrote:
> > > From: Maarten Lankhorst
> > >
> > > v4:
> > > * Manual rebase (Manasi)
> > > v3:
> > > * Change
On Thu, Sep 03, 2020 at 08:54:40PM +0300, Ville Syrjälä wrote:
> On Wed, Jul 15, 2020 at 03:42:14PM -0700, Manasi Navare wrote:
> > From: Maarten Lankhorst
> >
> > v4:
> > * Manual rebase (Manasi)
> > v3:
> > * Change state to crtc_state, fix rebase err (Manasi)
> > v2:
> > * Manual Rebase (Mana
== Series Details ==
Series: drm/i915/pll: Centralize PLL_ENABLE register lookup (rev5)
URL : https://patchwork.freedesktop.org/series/81150/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
f5ec8439a17d drm/i915/pll: Centralize PLL_ENABLE register lookup
-:38: CHECK:BRACES: Blank
== Series Details ==
Series: series starting with [1/2] drm/i915: Reduce INTEL_DISPLAY_ENABLED to
just removing the outputs (rev4)
URL : https://patchwork.freedesktop.org/series/81507/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9007 -> Patchwork_18492
=
> On Sep 13, 2020, at 7:34 PM, Zhenyu Wang wrote:
>
> On 2020.09.11 19:58:25 -0400, Rodrigo Vivi wrote:
>> On Thu, Sep 10, 2020 at 01:37:20PM +0800, Zhenyu Wang wrote:
>>>
>>> Hi,
>>>
>>> As we split pull request for 5.10 this time, here's gvt-next pull
>>> for 5.10. For gvt ww lock fix, Zhi
== Series Details ==
Series: Return head pages from find_*_entry (rev4)
URL : https://patchwork.freedesktop.org/series/81557/
State : failure
== Summary ==
Applying: mm: Factor find_get_incore_page out of mincore_page
Applying: mm: Use find_get_incore_page in memcontrol
Applying: mm: Optimise
On Mon, Sep 07, 2020 at 03:35:23PM +0300, Ville Syrjälä wrote:
> On Thu, Sep 03, 2020 at 09:40:44PM +0300, Ville Syrjälä wrote:
> > On Thu, Sep 03, 2020 at 11:04:33AM -0700, Navare, Manasi wrote:
> > > On Thu, Sep 03, 2020 at 08:49:44PM +0300, Ville Syrjälä wrote:
> > > > On Wed, Jul 15, 2020 at 03
Quoting Janusz Krzysztofik (2020-09-11 12:30:15)
> Clean up the test code, add some new basic subtests, then unblock
> unbind test variants.
>
> No incompletes / aborts nor subsequently run test issues have been
> reported by Trybot. The hotrebind-lateclose subtest fails on a so far
> unidentifie
We currenty check for platform at multiple parts in the driver
to grab the correct PLL. Let us begin to centralize it through a
helper function.
v2: s/intel_get_pll_enable_reg()/intel_combo_pll_enable_reg() (Ville)
v3: Clean up combo_pll_disable() (Rodrigo)
v4: s/dev_priv/i915 (Jani)
Move static
== Series Details ==
Series: Per client engine busyness
URL : https://patchwork.freedesktop.org/series/81652/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9007 -> Patchwork_18491
Summary
---
**SUCCESS**
No regres
On 9/14/2020 10:17 PM, Tvrtko Ursulin wrote:
On 14/09/2020 12:00, Nikunj A. Dadhania wrote:
As we close GEM object and set file_priv to -EBADF which is protected
by ctx->mutex, populating the GEM debugfs info is not protected
and results in the crash shown below.
Make sure to protect the acces
== Series Details ==
Series: Per client engine busyness
URL : https://patchwork.freedesktop.org/series/81652/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+drivers/gpu/drm/i915/gt/intel_reset.
== Series Details ==
Series: Per client engine busyness
URL : https://patchwork.freedesktop.org/series/81652/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
ac3c07ab42f4 drm/i915: Expose list of clients in sysfs
-:84: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), d
== Series Details ==
Series: dma-buf: Flag vmap'ed memory as system or I/O memory
URL : https://patchwork.freedesktop.org/series/81647/
State : failure
== Summary ==
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
DESCEND objtool
CHK include/generated/compil
On Mon, Sep 14, 2020 at 04:58:33PM +, Souza, Jose wrote:
> On Mon, 2020-09-14 at 17:48 +0300, Ville Syrjälä wrote:
> > On Sat, Sep 12, 2020 at 01:30:23AM +, Souza, Jose wrote:
> > > On Wed, 2020-07-01 at 00:55 +0300, Ville Syrjala wrote:
> > > > From: Ville Syrjälä <
> > > > ville.syrj...@l
On Mon, 2020-09-14 at 17:48 +0300, Ville Syrjälä wrote:
> On Sat, Sep 12, 2020 at 01:30:23AM +, Souza, Jose wrote:
> > On Wed, 2020-07-01 at 00:55 +0300, Ville Syrjala wrote:
> > > From: Ville Syrjälä <
> > > ville.syrj...@linux.intel.com
> > >
> > >
> > > Make a clean split between hpd pins
On Mon, Sep 14, 2020 at 12:17:07PM -0400, Qian Cai wrote:
> Reverting the "Return head pages from find_*_entry" patchset [1] up to this
> patch fixed the issue that LTP madvise06 test [2] would trigger endless soft-
> lockups below. It does not help after applied patches fixed other separate
> issu
On 14/09/2020 12:00, Nikunj A. Dadhania wrote:
As we close GEM object and set file_priv to -EBADF which is protected
by ctx->mutex, populating the GEM debugfs info is not protected
and results in the crash shown below.
Make sure to protect the access to file_priv using ctx->mutex to avoid
race
On Mon, 2020-09-14 at 12:17 -0400, Qian Cai wrote:
> On Thu, 2020-09-10 at 19:33 +0100, Matthew Wilcox (Oracle) wrote:
> > Instead of calling find_get_entry() for every page index, use an XArray
> > iterator to skip over NULL entries, and avoid calling get_page(),
> > because we only want the swap
On 23/07/2020 18:21, Chris Wilson wrote:
Since the debugfs may peek into the GEM contexts as the corresponding
client/fd is being closed, we may try and follow a dangling pointer.
However, the context closure itself is serialised with the ctx->mutex,
so if we hold that mutex as we inspect the s
https://lore.kernel.org/lkml/20200914115559.gn6...@casper.infradead.org/
[ 2653.179563][C4] CPU: 4 PID: 23320 Comm: madvise06 Not tainted
5.9.0-rc5-next-20200914+ #2
[ 2653.220176][C4] Hardware name: HP ProLiant BL660c Gen9, BIOS I38
10/17/2018
[ 2653.254908][C4] RIP: 0010:lock_acquire+0x211
== Series Details ==
Series: drm/i915: Fix the race between the GEM close and debugfs
URL : https://patchwork.freedesktop.org/series/81646/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9006 -> Patchwork_18489
Summary
-
From: Tvrtko Ursulin
Adds support for per-client engine busyness stats i915 exports in sysfs
and produces output like the below:
==
intel-gpu-top - 935/ 935 MHz;0% RC6; 14.73 Watts; 1097 irqs/s
IMC reads:
On Mon, 14 Sep 2020, Ville Syrjälä wrote:
> On Fri, Sep 11, 2020 at 09:13:18PM +0300, Jani Nikula wrote:
>> On Thu, 06 Feb 2020, Ville Syrjala wrote:
>> > From: Ville Syrjälä
>> >
>> > g4x+ sprites have an extra cdclk limitation listed for RGB formats.
>> > For some random reason I chose to use
Tvrtko Ursulin writes:
> From: Tvrtko Ursulin
>
> As GEM contexts are closed we want to have the DRM client remember how
> much GPU time they used (per class) so later we can used it for smarter
> purposes.
>
> Signed-off-by: Tvrtko Ursulin
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm
Hi
Am 13.08.20 um 12:22 schrieb Christian König:
> Am 13.08.20 um 10:36 schrieb Thomas Zimmermann:
>> GEM object functions deprecate several similar callback interfaces in
>> struct drm_driver. This patch replaces the per-driver callbacks with
>> per-instance callbacks in amdgpu. The only exceptio
Tvrtko Ursulin writes:
> From: Tvrtko Ursulin
>
> As contexts are abandoned we want to remember how much GPU time they used
> (per class) so later we can used it for smarter purposes.
>
> Signed-off-by: Tvrtko Ursulin
> ---
> drivers/gpu/drm/i915/gem/i915_gem_context.c | 13 -
On 11/09/2020 07:44, Lucas De Marchi wrote:
On Fri, Sep 04, 2020 at 01:59:28PM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
If we make GEM contexts keep a reference to i915_drm_client for the whole
of their lifetime, we can consolidate the current task pid and name usage
by getting it fr
On Sat, Sep 12, 2020 at 01:30:23AM +, Souza, Jose wrote:
> On Wed, 2020-07-01 at 00:55 +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä <
> > ville.syrj...@linux.intel.com
> > >
> >
> > Make a clean split between hpd pins for DDI vs. TC. This matches
> > how the actual hardware is split.
>
On Mon, Aug 31, 2020 at 06:09:23PM -0700, José Roberto de Souza wrote:
> Another step towards PSR2 selective fetch, here programming plane
> selective fetch registers and MAN_TRK_CTL enabling selective fetch but
> for now it is fetching the whole area of the planes.
> The damaged area calculation w
On Mon, Aug 31, 2020 at 06:09:22PM -0700, José Roberto de Souza wrote:
> In case PSR2 is disabled by debugfs dc3co_enabled and
> psr2_sel_fetch_enabled were still being set causing some code paths
> to be executed were it should not.
> We have tests for PSR1 and PSR2 so keep those features disabled
On Fri, Sep 11, 2020 at 09:03:36PM +0300, Jani Nikula wrote:
> On Thu, 06 Feb 2020, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Even if we're not doing downscaling we should account for
> > some of the extra dotclock limitations for g4x+ sprites. In
> > particular we must never exceed th
Hi Jani,
there is also already a bug report at
https://gitlab.freedesktop.org/drm/intel/-/issues/2381 but it also seems to
get not much attention.
Ville Syrjälä from Intel provided a workaround and mentioned the issue was
encountered before, but has never been fixed.
It would be great if someone f
1 - 100 of 123 matches
Mail list logo
