> -Original Message-
> From: Roper, Matthew D
> Sent: Wednesday, September 15, 2021 9:09 AM
> To: Siddiqui, Ayaz A
> Cc: intel-gfx@lists.freedesktop.org; Tang, CQ
> Subject: Re: [PATCH V5 1/5] drm/i915/gt: Add support of mocs propagation
>
> On Fri, Sep 03, 2021 at 02:51:49PM +0530,
== Series Details ==
Series: drm/i915/gt: Add "intel_" as prefix in set_mocs_index()
URL : https://patchwork.freedesktop.org/series/94721/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10594 -> Patchwork_21069
Summary
-
Hi Dave, Daniel,
Here's the first drm-misc-next PR for 5.16
Thanks!
Maxime
drm-misc-next-2021-09-16:
drm-misc-next for $kernel-version:
UAPI Changes:
Cross-subsystem Changes:
- dma-buf: Avoid a warning with some allocations, Remove
DMA_FENCE_TRACE macros
Core Changes:
- bridge: New he
On 15/09/2021 20:23, Tim Gardner wrote:
In capture_vma() Coverity complains of a possible buffer overrun. Even
though this is a static function where all call sites can be checked,
limiting the copy length could save some future grief.
CID 93300 (#1 of 1): Copy into fixed size buffer (STRING_O
On Wed, 15 Sep 2021, Lyude Paul wrote:
> On Mon, 2021-09-06 at 09:35 +0200, Hans de Goede wrote:
>>
>> + /**
>> + * @privacy_screen_sw_state: See :ref:`Standard Connector
>> + * Properties`
>> + */
>
> So THAT'S how you reference other sections. I've always wondered!
On 15/09/2021 17:58, Matthew Brost wrote:
On Wed, Sep 15, 2021 at 09:24:15AM +0100, Tvrtko Ursulin wrote:
On 14/09/2021 19:04, Matthew Brost wrote:
On Tue, Sep 14, 2021 at 09:34:08AM +0100, Tvrtko Ursulin wrote:
8<
Today we have:
for_each intel_engines: // intel_engines is a flat list
Hi,
On 16/09/2021 05:37, Hugh Dickins wrote:
Two Lenovo ThinkPads, old T420s (2011), newer X1 Carbon 5th gen (2017):
i915 working fine on both up to 5.14, but blank screens booting 5.15-rc1,
kernel crashed in some way.
T420s could be SandyBridge and X1 Carbon KabyLake.
I wanted to say what
Hi Lyude,
Thank you very much for the review of this series.
On 9/15/21 10:01 PM, Lyude Paul wrote:
> On Mon, 2021-09-06 at 09:35 +0200, Hans de Goede wrote:
>> On some new laptops the LCD panel has a builtin electronic privacy-screen.
>> We want to export this functionality as a property on the
On Mon, 06 Sep 2021, Hans de Goede wrote:
> Add X86 specific arch init code, which fills the privacy-screen lookup
> table by checking for various vendor specific ACPI interfaces for
> controlling the privacy-screen.
>
> This initial version only checks for the Lenovo Thinkpad specific ACPI
> meth
On Wed, Sep 15, 2021 at 02:55:58PM -0700, john.c.harri...@intel.com wrote:
> From: Rodrigo Vivi
>
> Newer platforms have an embedded table giving details about that
> platform's hardware configuration. This table can be retrieved from
> the KMD via the existing query API. So add a test for it as
On Thu, 2021-09-16 at 08:55 +0200, Christian König wrote:
>
>
> Am 15.09.21 um 20:59 schrieb Matthew Auld:
> > In commit:
> >
> > commit 667a50db0477d47fdff01c666f5ee1ce26b5264c
> > Author: Thomas Hellstrom
> > Date: Fri Jan 3 11:17:18 2014 +0100
> >
> > drm/ttm: Refuse to fault (prime-
Hi,
On 9/15/21 10:26 PM, Lyude Paul wrote:
> On Mon, 2021-09-06 at 09:35 +0200, Hans de Goede wrote:
>> Add support for privacy-screen consumers to register a notifier to
>> be notified of external (e.g. done by the hw itself on a hotkey press)
>> state changes.
>>
>> Reviewed-by: Emil Velikov
>>
Hi,
On 9/15/21 10:55 PM, Lyude Paul wrote:
> On Mon, 2021-09-06 at 09:35 +0200, Hans de Goede wrote:
>> Register a privacy-screen device on laptops with a privacy-screen,
>> this exports the PrivacyGuard features to user-space using a
>> standardized vendor-agnostic sysfs interface. Note the sysfs
Hi,
On 9/15/21 11:11 PM, Lyude Paul wrote:
> On Mon, 2021-09-06 at 09:35 +0200, Hans de Goede wrote:
>> Add support for eDP panels with a built-in privacy screen using the
>> new drm_privacy_screen class.
>>
>> One thing which stands out here is the addition of these 2 lines to
>> intel_atomic_com
Hi,
On 9/16/21 10:51 AM, Jani Nikula wrote:
> On Mon, 06 Sep 2021, Hans de Goede wrote:
>> Add X86 specific arch init code, which fills the privacy-screen lookup
>> table by checking for various vendor specific ACPI interfaces for
>> controlling the privacy-screen.
>>
>> This initial version only
== Series Details ==
Series: i915/display: split and constify vtable (rev6)
URL : https://patchwork.freedesktop.org/series/94459/
State : failure
== Summary ==
Applying: drm/i915/uncore: split the fw get function into separate vfunc
Applying: drm/i915/pm: drop get_fifo_size vfunc.
Applying: dr
On Tue, 3 Aug 2021 11:38:19 +0200
Werner Sembach wrote:
> Greetings,
>
> Original proposal:
> https://www.mail-archive.com/amd-gfx@lists.freedesktop.org/msg62387.html
>
> Abstract: Add "preferred color format", "active color format", "active bpc",
> and "active Broadcast RGB" drm properties,
Hi,
On 9/15/21 11:12 PM, Lyude Paul wrote:
> OK! Looked over all of these patches. Patches 2 and 4 have some comments that
> should be addressed, but otherwise this series is:
>
> Reviewed-by: Lyude Paul
Thank you!
> Let me know when/if you need help pushing this upstream
My plan was to just
Op 08-09-2021 om 20:57 schreef Sebastian Andrzej Siewior:
> execlists_dequeue() is invoked from a function which uses
> local_irq_disable() to disable interrupts so the spin_lock() behaves
> like spin_lock_irq().
> This breaks PREEMPT_RT because local_irq_disable() + spin_lock() is not
> the same a
Cc: Ville for input here, see question inline.
On Mon, 06 Sep 2021, Hans de Goede wrote:
> Add support for eDP panels with a built-in privacy screen using the
> new drm_privacy_screen class.
>
> One thing which stands out here is the addition of these 2 lines to
> intel_atomic_commit_tail:
>
>
On 8/30/21 2:09 PM, Maarten Lankhorst wrote:
Remove some parts of the i915_vma api, ensure obj->vma always exists,
and finally force the object lock to be taken when calling i915_vma_unbind
is called.
Should this be vma->obj?
With this, locking is a lot cleaner, and we no longer need all
On 8/30/21 2:10 PM, Maarten Lankhorst wrote:
We want to get rid of i915_vma tracking to simplify the code and
lifetimes. Add a way to set/put the moving fence, in preparation for
removing the tracking.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_object.c | 15
On 8/30/21 2:09 PM, Maarten Lankhorst wrote:
When we implement delayed destroy, we may have a second
call to the delete_mem_notify() handler, while free_object()
only should be called once.
Move it to bo->destroy(), to ensure it's only called once.
This fixes some weird memory corruption issue
From: Patchwork
Sent: Wednesday, September 15, 2021 5:05 PM
To: Kulkarni, Vandita
Cc: intel-gfx@lists.freedesktop.org
Subject: ✗ Fi.CI.BAT: failure for drm/i915/display: Fix the dsc check while
selecting min_cdclk (rev2)
Patch Details
Series:
drm/i915/display: Fix the dsc check while selecting
On 16/09/2021 10:03, Thomas Hellström wrote:
On Thu, 2021-09-16 at 08:55 +0200, Christian König wrote:
Am 15.09.21 um 20:59 schrieb Matthew Auld:
In commit:
commit 667a50db0477d47fdff01c666f5ee1ce26b5264c
Author: Thomas Hellstrom
Date: Fri Jan 3 11:17:18 2014 +0100
drm/ttm: Refuse
Hi,
We're moving towards a failsafe migration on DG1, but on DG2+ we'd have
to wedge the GPU when an error occurs during initial clearing or swapin.
But CPU maps don't care whether the GPU is wedged so we need to check
the error status both below and in the TTM fault handler, I guess.
On 8/3
On 9/16/21 11:58 AM, Matthew Auld wrote:
On 16/09/2021 10:03, Thomas Hellström wrote:
On Thu, 2021-09-16 at 08:55 +0200, Christian König wrote:
Am 15.09.21 um 20:59 schrieb Matthew Auld:
In commit:
commit 667a50db0477d47fdff01c666f5ee1ce26b5264c
Author: Thomas Hellstrom
Date: Fri Jan 3
On Thu, 16 Sep 2021, Hans de Goede wrote:
> Hi,
>
> On 9/15/21 11:12 PM, Lyude Paul wrote:
>> OK! Looked over all of these patches. Patches 2 and 4 have some comments that
>> should be addressed, but otherwise this series is:
>>
>> Reviewed-by: Lyude Paul
>
> Thank you!
>
>> Let me know when/if
Gmbus driver would setup all Intel i2c GMBuses. But DDC bus
may configured as gpio and reserved for MIPI driver to control
panel power on/off sequence.
Using i2c tool to communicate to peripherals via i2c interface
reversed for gmbus(DDC). There will be some high/low pulse
appear on DDC SCL and SD
On 14/09/2021 20:31, Thomas Hellström wrote:
When backing up or restoring contents of pinned objects at suspend /
resume time we need to allocate a new object as the backup. Add a function
to facilitate copies between the two. Some data needs to be copied before
the migration context is ready for
On Thu, 16 Sep 2021, Tvrtko Ursulin wrote:
> Hi,
>
> On 16/09/2021 05:37, Hugh Dickins wrote:
>> Two Lenovo ThinkPads, old T420s (2011), newer X1 Carbon 5th gen (2017):
>> i915 working fine on both up to 5.14, but blank screens booting 5.15-rc1,
>> kernel crashed in some way.
>
> T420s could be Sa
On 14/09/2021 20:31, Thomas Hellström wrote:
An upcoming common pattern is to traverse the region object list and
perform certain actions on all objects in a region. It's a little tricky
to get the list locking right, in particular since a gem object may
change region unless it's pinned or the ob
Hi,
On 9/16/21 11:40 AM, Jani Nikula wrote:
>
> Cc: Ville for input here, see question inline.
>
> On Mon, 06 Sep 2021, Hans de Goede wrote:
>> Add support for eDP panels with a built-in privacy screen using the
>> new drm_privacy_screen class.
>>
>> One thing which stands out here is the addit
On Thu, 16 Sep 2021, Lee Shawn C wrote:
> Gmbus driver would setup all Intel i2c GMBuses. But DDC bus
> may configured as gpio and reserved for MIPI driver to control
> panel power on/off sequence.
>
> Using i2c tool to communicate to peripherals via i2c interface
> reversed for gmbus(DDC). There
On Thu, 16 Sep 2021, Tvrtko Ursulin wrote:
> On 15/09/2021 20:23, Tim Gardner wrote:
>> In capture_vma() Coverity complains of a possible buffer overrun. Even
>> though this is a static function where all call sites can be checked,
>> limiting the copy length could save some future grief.
>>
>> C
Am 15.09.21 um 20:59 schrieb Matthew Auld:
Now that setting page->index shouldn't be needed anymore, we are just
left with setting page->mapping, and here it looks like amdgpu is the
only user, where pointing the page->mapping at the dev_mapping is used
to verify that the pages do indeed belon
Am 15.09.21 um 20:59 schrieb Matthew Auld:
No longer used it seems.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Christian König
Reviewed-by: Christian König
---
include/drm/ttm/ttm_tt.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/drm/ttm/ttm_tt.h b/include/drm/
Am 15.09.21 um 20:59 schrieb Matthew Auld:
In commit:
commit 58aa6622d32af7d2c08d45085f44c54554a16ed7
Author: Thomas Hellstrom
Date: Fri Jan 3 11:47:23 2014 +0100
drm/ttm: Correctly set page mapping and -index members
we started setting the page->mapping and page->index to point to the
Am 15.09.21 um 20:59 schrieb Matthew Auld:
It covers more than just ttm_bo_type_sg usage, like with say dma-buf,
since one other user is userptr in amdgpu, and in the future we might
have some more. Hence EXTERNAL is likely a more suitable name.
Suggested-by: Christian König
Signed-off-by: M
Am 15.09.21 um 20:59 schrieb Matthew Auld:
Move it to inline kernel-doc, otherwise we can't add empty lines it
seems. Also drop the kernel-doc for pages_list, which doesn't seem to
exist, and get rid of all the strange holes.
As suggested on the other patch I would do the rename and renumbering
Am 15.09.21 um 20:59 schrieb Matthew Auld:
In commit:
commit 667a50db0477d47fdff01c666f5ee1ce26b5264c
Author: Thomas Hellstrom
Date: Fri Jan 3 11:17:18 2014 +0100
drm/ttm: Refuse to fault (prime-) imported pages
we introduced the restriction that imported pages should not be directl
== Series Details ==
Series: drm/i915/dsi: unregister gmbus if LFP display was MIPI panel
URL : https://patchwork.freedesktop.org/series/94733/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10596 -> Patchwork_21071
Summary
On Thu, 16 Sep 2021, Jani Nikula wrote:
>On Thu, 16 Sep 2021, Lee Shawn C wrote:
>> Gmbus driver would setup all Intel i2c GMBuses. But DDC bus may
>> configured as gpio and reserved for MIPI driver to control panel power
>> on/off sequence.
>>
>> Using i2c tool to communicate to peripherals vi
On Wed, 15 Sep 2021, Rodrigo Vivi wrote:
> On Wed, Sep 15, 2021 at 04:53:35PM +0300, Jani Nikula wrote:
>> On Fri, 10 Sep 2021, Daniele Ceraolo Spurio
>> wrote:
>> > diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.h
>> > b/drivers/gpu/drm/i915/pxp/intel_pxp.h
>> > new file mode 100644
>> > inde
On Thu, 16 Sep 2021, "Lee, Shawn C" wrote:
> On Thu, 16 Sep 2021, Jani Nikula wrote:
>>On Thu, 16 Sep 2021, Lee Shawn C wrote:
>>> Gmbus driver would setup all Intel i2c GMBuses. But DDC bus may
>>> configured as gpio and reserved for MIPI driver to control panel power
>>> on/off sequence.
>>>
drm/i915/ttm: Add async migration to the TTM backend?
On 8/30/21 2:10 PM, Maarten Lankhorst wrote:
Expose the fence to ttm_bo->moving, which will get picked up by i915
through the i915_gem_object_get_moving_fence call. Should be sufficient
for the needs we have.
Signed-off-by: Maarten Lankhorst
Op 16-09-2021 om 11:40 schreef Thomas Hellström (Intel):
>
> On 8/30/21 2:09 PM, Maarten Lankhorst wrote:
>> Remove some parts of the i915_vma api, ensure obj->vma always exists,
>> and finally force the object lock to be taken when calling i915_vma_unbind
>> is called.
>
> Should this be vma->obj?
On 9/16/21 4:43 AM, Jani Nikula wrote:
On Thu, 16 Sep 2021, Tvrtko Ursulin wrote:
On 15/09/2021 20:23, Tim Gardner wrote:
In capture_vma() Coverity complains of a possible buffer overrun. Even
though this is a static function where all call sites can be checked,
limiting the copy length cou
This is maybe even a fix since the RCU usage here looks incorrect.
v2: add missing rcu_read_lock()/unlock()
Signed-off-by: Christian König
---
drivers/gpu/drm/i915/gem/i915_gem_object.h | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i9
stack_depot_save allocates slabs that will be used for storing
objects in future.If this slab allocation fails we may get to
a situation where space allocation for a new stack_record fails,
causing stack_depot_save to return 0 as handle.
If user of this handle ends up invoking stack_depot_fetch wit
This makes the function much simpler since the complex
retry logic is now handled elsewhere.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-resv.c | 54 +-
1 file changed, 7 insertions(+), 47 deletions(-)
diff --git a/drivers/dma-buf/dma-resv.c b/driv
Simplifying the code a bit.
v2: use dma_resv_for_each_fence
Signed-off-by: Christian König
---
drivers/gpu/drm/scheduler/sched_main.c | 26 ++
1 file changed, 6 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/schedul
This makes the function much simpler since the complex
retry logic is now handled else where.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-resv.c | 81 +++---
1 file changed, 32 insertions(+), 49 deletions(-)
diff --git a/drivers/dma-buf/dma-resv.c b/dr
Simplifying the code a bit.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 1129e17e9f09..b3859c
Simplifying the code a bit.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_sync.c | 22 +++---
1 file changed, 3 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_sync.c
b/drivers/gpu/drm/radeon/radeon_sync.c
index 9257b60144c4..23fa98d
This makes the function much simpler since the complex
retry logic is now handled elsewhere.
v2: use sizeof(void*) instead
Signed-off-by: Christian König
---
drivers/dma-buf/dma-resv.c | 110 +
1 file changed, 37 insertions(+), 73 deletions(-)
diff --git a/d
Simplifying the code a bit.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c | 44
1 file changed, 14 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c
index 862eb3
This is probably a fix since we didn't even grabed a reference to the
fences.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 12 ++--
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 3b22c0
Makes the handling a bit more complex, but avoids the use of
dma_resv_get_excl_unlocked().
v2: add missing rcu_read_lock()/unlock()
Signed-off-by: Christian König
---
drivers/gpu/drm/drm_gem_atomic_helper.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/driver
Abstract the complexity of iterating over all the fences
in a dma_resv object.
The new loop handles the whole RCU and retry dance and
returns only fences where we can be sure we grabbed the
right one.
v2: fix accessing the shared fences while they might be freed,
improve kerneldoc, rename _cu
Makes the handling a bit more complex, but avoids the use of
dma_resv_get_excl_unlocked().
v2: add missing rcu_read_lock()/unlock()
Signed-off-by: Christian König
---
drivers/gpu/drm/nouveau/dispnv50/wndw.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/
This makes the function much simpler since the complex
retry logic is now handled else where.
Signed-off-by: Christian König
---
drivers/gpu/drm/i915/gem/i915_gem_busy.c | 30 +++-
1 file changed, 9 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_ge
Next round for that one here, maybe the CI systems are now more
gracefully with me :)
I'm pretty sure that a couple of those dma_resv_for_each_fence_unlocked
should actually be replaced with lock+dma_resv_for_each_fence, but that
needs more auditing.
Please review and comment.
Thanks,
Christian.
Simplifying the code a bit.
Signed-off-by: Christian König
---
drivers/gpu/drm/nouveau/nouveau_fence.c | 48 +++--
1 file changed, 12 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c
b/drivers/gpu/drm/nouveau/nouveau_fence.c
index 05d0b3eb
Heureka, that's finally not used any more.
Signed-off-by: Christian König
---
include/linux/dma-resv.h | 26 --
1 file changed, 26 deletions(-)
diff --git a/include/linux/dma-resv.h b/include/linux/dma-resv.h
index 6761512ba662..3e6ffba0af70 100644
--- a/include/linux/dm
A simpler version of the iterator to be used when the dma_resv object is
locked.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-resv.c | 37 +
include/linux/dma-resv.h | 18 ++
2 files changed, 55 insertions(+)
diff --git a/drivers/d
Simplifying the code a bit.
v2: use dma_resv_for_each_fence instead, according to Tvrtko the lock is
held here anyway.
Signed-off-by: Christian König
---
drivers/gpu/drm/i915/i915_sw_fence.c | 51 +---
1 file changed, 9 insertions(+), 42 deletions(-)
diff --git a/dr
Instead of hand rolling the logic.
Signed-off-by: Christian König
---
drivers/gpu/drm/etnaviv/etnaviv_gem.c | 27 +--
1 file changed, 9 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
index 8f1b5a
Simplifying the code a bit.
v2: add missing rcu read unlock.
Signed-off-by: Christian König
---
drivers/gpu/drm/i915/gem/i915_gem_wait.c | 57 +++-
1 file changed, 15 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_wait.c
b/drivers/gpu/drm/i91
This makes the function much simpler since the complex
retry logic is now handled elsewhere.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-resv.c | 64 +-
1 file changed, 7 insertions(+), 57 deletions(-)
diff --git a/drivers/dma-buf/dma-resv.c b/driv
Simplifying the code a bit.
v2: add missing rcu_read_lock()/unlock()
Signed-off-by: Christian König
---
drivers/gpu/drm/drm_gem.c | 36 +---
1 file changed, 13 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
inde
Simplifying the code a bit.
v2: add rcu_read_lock()/unlock()
Signed-off-by: Christian König
---
drivers/gpu/drm/i915/display/intel_display.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/displa
Simplifying the code a bit.
v2: add missing rcu_read_lock()/rcu_read_unlock()
Signed-off-by: Christian König
---
drivers/gpu/drm/i915/i915_request.c | 40 -
1 file changed, 11 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers
Changes in v2:
- Fixed compilation error [1] due to typo in patch-3 (stack_depot_print
used in place of stack_depot_snprint)
This compilation error appears with CONFIG_DRM_I915_DEBUG_RUNTIME_PM=y
and this was missed by my test config (x86_64_defconfig)
[1] https://patchwork.freedesktop.o
We certainly hold the reservation lock here, no need for the RCU dance.
Signed-off-by: Christian König
---
drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
b/drivers/gpu/drm/etnaviv/etna
Simplifying the code a bit.
v2: add missing rcu_read_lock()/unlock()
Signed-off-by: Christian König
---
drivers/gpu/drm/i915/gem/i915_gem_wait.c | 33 +++-
1 file changed, 9 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_wait.c
b/drivers/gpu/
To print stack entries into a buffer, users of stackdepot,
first get a list of stack entries using stack_depot_fetch
and then print this list into a buffer using stack_trace_snprint.
Provide a helper in stackdepot for this purpose.
Also change above mentioned users to use this helper.
Signed-off-b
To print a stack entries, users of stackdepot, first
use stack_depot_fetch to get a list of stack entries
and then use stack_trace_print to print this list.
Provide a helper in stackdepot to print stack entries
based on stackdepot handle.
Also change above mentioned users to use this helper.
Signe
Simplifying the code a bit. Also drop the RCU read side lock since the
object is locked anyway.
Untested since I can't get the driver to compile on !ARM.
Signed-off-by: Christian König
---
drivers/gpu/drm/msm/msm_gem.c | 19 +--
1 file changed, 5 insertions(+), 14 deletions(-)
On Thu, Sep 16, 2021 at 01:30:17PM +0200, Christian König wrote:
> Abstract the complexity of iterating over all the fences
> in a dma_resv object.
>
> The new loop handles the whole RCU and retry dance and
> returns only fences where we can be sure we grabbed the
> right one.
>
> v2: fix accessi
== Series Details ==
Series: lib, stackdepot: check stackdepot handle before accessing slabs (rev2)
URL : https://patchwork.freedesktop.org/series/94696/
State : failure
== Summary ==
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
DESCEND objtool
CHK include
On Wed, 15 Sep 2021 16:38:31 -0400, Sean Paul wrote:
> From: Sean Paul
>
> This patch adds the bindings for the MSM DisplayPort HDCP registers
> which are required to write the HDCP key into the display controller as
> well as the registers to enable HDCP authentication/key
> exchange/encryption.
In capture_vma() Coverity complains of a possible buffer overrun. Even
though this is a static function where all call sites can be checked,
limiting the copy length could save some future grief.
CID 93300 (#1 of 1): Copy into fixed size buffer (STRING_OVERFLOW)
4. fixed_size_dest: You might overr
== Series Details ==
Series: series starting with [01/26] dma-buf: add
dma_resv_for_each_fence_unlocked v2
URL : https://patchwork.freedesktop.org/series/94750/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
79becb99fccc dma-buf: add dma_resv_for_each_fence_unlocked v2
-:72: CH
== Series Details ==
Series: drm/i915/dsi: unregister gmbus if LFP display was MIPI panel
URL : https://patchwork.freedesktop.org/series/94733/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10596_full -> Patchwork_21071_full
== Series Details ==
Series: series starting with [01/26] dma-buf: add
dma_resv_for_each_fence_unlocked v2
URL : https://patchwork.freedesktop.org/series/94750/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10596 -> Patchwork_21073
== Series Details ==
Series: drm/i915: zero fill vma name buffer (rev2)
URL : https://patchwork.freedesktop.org/series/94708/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
129ca4e746b8 drm/i915: use strscpy() to avoid buffer overrun
-:11: WARNING:COMMIT_LOG_LONG_LINE: Possible
On Wed, Sep 15, 2021 at 04:38:31PM -0400, Sean Paul wrote:
> From: Sean Paul
>
> This patch adds the bindings for the MSM DisplayPort HDCP registers
> which are required to write the HDCP key into the display controller as
> well as the registers to enable HDCP authentication/key
> exchange/encry
Op 14-09-2021 om 15:54 schreef Daniel Vetter:
> On Tue, Sep 14, 2021 at 02:43:02PM +0200, Maarten Lankhorst wrote:
>> Op 14-09-2021 om 08:50 schreef Peter Zijlstra:
>>> On Mon, Sep 13, 2021 at 10:42:36AM +0200, Maarten Lankhorst wrote:
>>>
> +/**
> + * ww_mutex_trylock - tries to acquire th
On Wed, Sep 15, 2021 at 06:18:35PM +, Souza, Jose wrote:
> On Wed, 2021-09-15 at 17:58 +0300, Ville Syrjälä wrote:
> > On Tue, Sep 14, 2021 at 02:25:05PM -0700, José Roberto de Souza wrote:
> > > Not sure why but when moving the cursor fast it causes some artifacts
> > > of the cursor to be lef
Hi,
On 9/16/21 5:20 AM, Stephen Boyd wrote:
> Quoting Hans de Goede (2021-08-17 14:52:01)
>> diff --git a/drivers/usb/typec/altmodes/displayport.c
>> b/drivers/usb/typec/altmodes/displayport.c
>> index aa669b9cf70e..c1d8c23baa39 100644
>> --- a/drivers/usb/typec/altmodes/displayport.c
>> +++ b/dr
== Series Details ==
Series: drm/i915: zero fill vma name buffer (rev2)
URL : https://patchwork.freedesktop.org/series/94708/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10596 -> Patchwork_21074
Summary
---
**FAILU
On Wed, Sep 15, 2021 at 08:19:41PM +, Souza, Jose wrote:
> On Wed, 2021-09-15 at 15:30 +0300, Ville Syrjälä wrote:
> > On Wed, Sep 15, 2021 at 12:00:28AM +, Souza, Jose wrote:
> > > On Tue, 2021-09-14 at 16:30 -0700, José Roberto de Souza wrote:
> > > > On Tue, 2021-09-14 at 11:20 +0300, Vi
On Thu, Sep 16, 2021 at 03:00:39PM +0200, Maarten Lankhorst wrote:
> > For merge logistics, can we pls have a stable branch? I expect that the
> > i915 patches will be ready for 5.16.
> >
> > Or send it in for -rc2 so that the interface change doesn't cause needless
> > conflicts, whatever you thi
Hi Dave & Daniel -
Fixes for v5.15-rc2. Looks like our CI is currently unhealthy. It's a
wip, but these don't seem to make matters worse, so I think better get
them moving than holding on.
drm-intel-fixes-2021-09-16:
drm/i915 fixes for v5.15-rc2:
- Propagate DP link training error returns
- Us
Op 16-09-2021 om 11:43 schreef Thomas Hellström (Intel):
>
> On 8/30/21 2:09 PM, Maarten Lankhorst wrote:
>> When we implement delayed destroy, we may have a second
>> call to the delete_mem_notify() handler, while free_object()
>> only should be called once.
>>
>> Move it to bo->destroy(), to ensu
To print a stack entries, users of stackdepot, first
use stack_depot_fetch to get a list of stack entries
and then use stack_trace_print to print this list.
Provide a helper in stackdepot to print stack entries
based on stackdepot handle.
Also change above mentioned users to use this helper.
Signe
To print stack entries into a buffer, users of stackdepot,
first get a list of stack entries using stack_depot_fetch
and then print this list into a buffer using stack_trace_snprint.
Provide a helper in stackdepot for this purpose.
Also change above mentioned users to use this helper.
Signed-off-b
Changes in v3:
- Fixed build error [1], due to missing EXPORT_SYMBOL_GPL in patch-3
[1] https://patchwork.freedesktop.org/series/94696/#rev2
Changes in v2:
- Fixed compilation error [1] due to typo in patch-3 (stack_depot_print
used in place of stack_depot_snprint)
This compilation error
stack_depot_save allocates slabs that will be used for storing
objects in future.If this slab allocation fails we may get to
a situation where space allocation for a new stack_record fails,
causing stack_depot_save to return 0 as handle.
If user of this handle ends up invoking stack_depot_fetch wit
1 - 100 of 182 matches
Mail list logo
