Am 22.12.21 um 21:53 schrieb Daniel Vetter:
On Mon, Dec 20, 2021 at 01:12:51PM -0500, Bhardwaj, Rajneesh wrote:
[SNIP]
Still sounds funky. I think minimally we should have an ack from CRIU
developers that this is officially the right way to solve this problem. I
really don't want to have random
On 12/22/21 19:02, a...@linux-foundation.org wrote:
> The mm-of-the-moment snapshot 2021-12-22-19-02 has been uploaded to
>
>https://www.ozlabs.org/~akpm/mmotm/
>
> mmotm-readme.txt says
>
> README for mm-of-the-moment:
>
> https://www.ozlabs.org/~akpm/mmotm/
>
> This is a snapshot of
From: Wang Qing
odd_ptr_err.cocci has complained about this warning for a long time:
lsfw.c:194:5-11: inconsistent IS_ERR and PTR_ERR on line 195.
Although there is no actual impact, it can improve scanning efficiency.
Signed-off-by: Wang Qing
---
On Wed, 22 Dec 2021 at 11:19, Kuo-Hsiang Chou
wrote:
>
> Hi
>
> -Original Message-
> From: Dave Airlie [mailto:airl...@gmail.com]
> Sent: Wednesday, December 22, 2021 5:56 AM
> To: Thomas Zimmermann
>
> Subject: Re: [PATCH] drm/ast: Support 1600x900 with 108MHz PCLK
>
> On Mon, 2 Nov
Sorry for the typo in my previous email. Please read Adrian Reber*
On 12/22/2021 8:49 PM, Bhardwaj, Rajneesh wrote:
Adding Adrian Rebel who is the CRIU maintainer and CRIU list
On 12/22/2021 3:53 PM, Daniel Vetter wrote:
On Mon, Dec 20, 2021 at 01:12:51PM -0500, Bhardwaj, Rajneesh wrote:
On
Adding Adrian Rebel who is the CRIU maintainer and CRIU list
On 12/22/2021 3:53 PM, Daniel Vetter wrote:
On Mon, Dec 20, 2021 at 01:12:51PM -0500, Bhardwaj, Rajneesh wrote:
On 12/20/2021 4:29 AM, Daniel Vetter wrote:
On Fri, Dec 10, 2021 at 07:58:50AM +0100, Christian König wrote:
Am
From: John Harrison
Don't silently drop reset notifications from the GuC. It might not be
safe to do an error capture but we still want some kind of report that
the reset happened.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 5 +
1 file changed, 5
On Wed, Dec 22, 2021 at 04:48:36PM -0800, John Harrison wrote:
> On 12/22/2021 15:29, Matthew Brost wrote:
> > Use a lockless list structure for destroyed contexts to avoid hammering
> > on global submission spin lock.
> I thought the guidance was that lockless anything without an explanation
>
On 12/22/2021 14:35, Matthew Brost wrote:
A weak implementation of parallel submission (multi-bb execbuf IOCTL) for
execlists. Doing as little as possible to support this interface for
execlists - basically just passing submit fences between each request
generated and virtual engines are not
Current DP drivers have regulators, clocks, irq and phy are grouped
together within a function and executed not in a symmetric manner.
This increase difficulty of code maintenance and limited code scalability.
This patch divides the driver life cycle of operation into four states,
resume
Add checking aux read/write status at both dp_link_parse_sink_count()
and dp_link_parse_sink_status_filed() to avoid long timeout delay if
dp aux read/write failed at timeout due to cable unplugged. Also make
sure dp controller had been initialized before start dpcd read and write.
Changes in V4:
On 12/22/2021 15:29, Matthew Brost wrote:
Use a lockless list structure for destroyed contexts to avoid hammering
on global submission spin lock.
I thought the guidance was that lockless anything without an explanation
longer than War And Peace comes with an automatic termination penalty?
From: David Yat Sin
When re-creating queues during CRIU restore, restore the queue with the
same doorbell id value used during CRIU dump.
Signed-off-by: David Yat Sin
---
.../drm/amd/amdkfd/kfd_device_queue_manager.c | 60 +--
1 file changed, 41 insertions(+), 19 deletions(-)
Both svm_range_get_attr and svm_range_set_attr helpers use mm struct
from current but for a Checkpoint or Restore operation, the current->mm
will fetch the mm for the CRIU master process. So modify these helpers to
accept the task mm for a target kfd process to support Checkpoint
Restore.
From: David Yat Sin
When doing a restore on a different node, the gpu_id's on the restore
node may be different. But the user space application will still refer
use the original gpu_id's in the ioctl calls. Adding code to create a
gpu id mapping so that kfd can determine actual gpu_id during the
During checkpoint stage, save the shared virtual memory ranges and
attributes for the target process. A process may contain a number of svm
ranges and each range might contain a number of arrtibutes. While not
all attributes may be applicable for a given prange but during
checkpoint we store all
During CRIU restore phase, the VMAs for the virtual address ranges are
not at their final location yet so in this stage, only cache the data
required to successfully resume the svm ranges during an imminent CRIU
resume phase.
Signed-off-by: Rajneesh Bhardwaj
---
From: David Yat Sin
Checkpoint contents of queue control stacks on CRIU dump and restore them
during CRIU restore.
Signed-off-by: David Yat Sin
Signed-off-by: Rajneesh Bhardwaj
---
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 2 +-
drivers/gpu/drm/amd/amdkfd/kfd_dbgdev.c | 2 +-
Recoverable page faults are represented by the xnack mode setting inside
a kfd process and are used to represent the device page faults. For CR,
we don't consider negative values which are typically used for querying
the current xnack mode without modifying it.
Signed-off-by: Rajneesh Bhardwaj
From: David Yat Sin
When re-creating queues during CRIU restore, restore the queue with the
same sdma id value used during CRIU dump.
Signed-off-by: David Yat Sin
---
.../drm/amd/amdkfd/kfd_device_queue_manager.c | 48 ++-
.../drm/amd/amdkfd/kfd_device_queue_manager.h | 3 +-
A KFD process may contain a number of virtual address ranges for shared
virtual memory management and each such range can have many SVM
attributes spanning across various nodes within the process boundary.
This change reports the total number of such SVM ranges and
their total private data size by
From: David Yat Sin
Add support to existing CRIU ioctl's to save and restore events during
criu checkpoint and restore.
Signed-off-by: David Yat Sin
---
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 70 +-
drivers/gpu/drm/amd/amdkfd/kfd_events.c | 272 ---
KFD buffer objects do not associate a GEM handle with them so cannot
directly be used with libdrm to initiate a system dma (sDMA) operation
to speedup the checkpoint and restore operation so export them as dmabuf
objects and use with libdrm helper (amdgpu_bo_import) to further process
the sdma
From: David Yat Sin
Add support to existing CRIU ioctl's to save number of queues and queue
properties for each queue during checkpoint and re-create queues on
restore.
Signed-off-by: David Yat Sin
---
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 110 -
- Add rock-rel_defconfig for release builds.
Signed-off-by: Rajneesh Bhardwaj
---
arch/x86/configs/rock-rel_defconfig | 4927 +++
1 file changed, 4927 insertions(+)
create mode 100644 arch/x86/configs/rock-rel_defconfig
diff --git a/arch/x86/configs/rock-rel_defconfig
From: David Yat Sin
Checkpoint contents of queue MQD's on CRIU dump and restore them during
CRIU restore.
Signed-off-by: David Yat Sin
---
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 2 +-
drivers/gpu/drm/amd/amdkfd/kfd_dbgdev.c | 2 +-
This implements the KFD CRIU Restore ioctl that lays the basic
foundation for the CRIU restore operation. It provides support to
create the buffer objects corresponding to Non-Paged system memory
mapped for GPU and/or CPU access and lays basic foundation for the
userptrs buffer objects which will
In CRIU resume stage, resume all the shared virtual memory ranges from
the data stored inside the resuming kfd process during CRIU restore
phase. Also setup xnack mode and free up the resources.
Signed-off-by: Rajneesh Bhardwaj
---
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 10 +
Currently the SVM ranges use actual_gpu_id but with Checkpoint Restore
support its possible that the SVM ranges can be resumed on another node
where the actual_gpu_id may not be same as the original (user_gpu_id)
gpu id. So modify svm code to use user_gpu_id.
Signed-off-by: Rajneesh Bhardwaj
---
This IOCTL is expected to be called as a precursor to the actual
Checkpoint operation. This does the basic discovery into the target
process seized by CRIU and relays the information to the userspace that
utilizes it to start the Checkpoint operation via another dedicated
IOCTL.
The process_info
From: David Yat Sin
When re-creating queues during CRIU restore, restore the queue with the
same queue id value used during CRIU dump.
Signed-off-by: Rajneesh Bhardwaj
Signed-off-by: David Yat Sin
---
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 2 +-
This adds support to create userptr BOs on restore and introduces a new
ioctl to restart memory notifiers for the restored userptr BOs.
When doing CRIU restore MMU notifications can happen anytime after we call
amdgpu_mn_register. Prevent MMU notifications until we reach stage-4 of the
restore
This adds support to discover the buffer objects that belong to a
process being checkpointed. The data corresponding to these buffer
objects is returned to user space plugin running under criu master
context which then stores this info to recreate these buffer objects
during a restore operation.
From: David Yat Sin
Introducing UNPAUSE op. After CRIU amdgpu plugin performs a PROCESS_INFO
op the queues will be stay in an evicted state. Once the plugin is done
draining BO contents, it is safe to perform an UNPAUSE op for the queues
to resume.
Signed-off-by: David Yat Sin
---
- Update debug config for Checkpoint-Restore (CR) support
- Also include necessary options for CR with docker containers.
Signed-off-by: Rajneesh Bhardwaj
---
arch/x86/configs/rock-dbg_defconfig | 53 ++---
1 file changed, 34 insertions(+), 19 deletions(-)
diff --git
Checkpoint-Restore in userspace (CRIU) is a powerful tool that can
snapshot a running process and later restore it on same or a remote
machine but expects the processes that have a device file (e.g. GPU)
associated with them, provide necessary driver support to assist CRIU
and its extensible
CRIU is a user space tool which is very popular for container live
migration in datacentres. It can checkpoint a running application, save
its complete state, memory contents and all system resources to images
on disk which can be migrated to another m achine and restored later.
More information
Use a lockless list structure for destroyed contexts to avoid hammering
on global submission spin lock.
Suggested-by: Tvrtko Ursulin
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_context.c | 2 -
drivers/gpu/drm/i915/gt/intel_context_types.h | 3 +-
A weak implementation of parallel submission (multi-bb execbuf IOCTL) for
execlists. Doing as little as possible to support this interface for
execlists - basically just passing submit fences between each request
generated and virtual engines are not allowed. This is on par with what
is there for
On Mon, Dec 06, 2021 at 12:01:04PM -0800, John Harrison wrote:
> On 11/11/2021 13:20, Matthew Brost wrote:
> > A weak implementation of parallel submission (multi-bb execbuf IOCTL) for
> > execlists. Doing as little as possible to support this interface for
> > execlists - basically just passing
On Fri, Dec 17, 2021 at 03:39:52PM +0100, Christian König wrote:
> Hi Daniel,
>
> looks like this is going nowhere and you don't seem to have time to review.
>
> What can we do?
cc more people, you didn't cc any of the driver folks :-)
Also I did find some review before I disappeared, back on
On Tue, Dec 07, 2021 at 01:34:09PM +0100, Christian König wrote:
> We have previously done that in the individual drivers but it is
> more defensive to move that into the common code.
>
> Dynamic attachments should wait for map operations to complete by themselves.
>
> Signed-off-by: Christian
Since now all GPU resets are serialzied there is no need for this.
This patch also reverts 'drm/amdgpu: race issue when jobs on 2 ring timeout'
Signed-off-by: Andrey Grodzovsky
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 89 ++
1 file
Since we serialize all resets no need to protect from concurrent
resets.
Signed-off-by: Andrey Grodzovsky
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 19 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c | 1 -
Since now flr work is serialized against GPU resets
there is no need for this.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c | 11 ---
drivers/gpu/drm/amd/amdgpu/mxgpu_nv.c | 11 ---
2 files changed, 22 deletions(-)
diff --git
No need to to trigger another work queue inside the work queue.
Suggested-by: Liu Shaoyun
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c | 7 +--
drivers/gpu/drm/amd/amdgpu/mxgpu_nv.c | 7 +--
drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c | 7 +--
3 files
On Tue, Dec 07, 2021 at 01:34:08PM +0100, Christian König wrote:
> Add an usage for submissions independent of implicit sync but still
> interesting for memory management.
>
> Signed-off-by: Christian König
Focusing on the kerneldoc first to get semantics agreed.
> diff --git
Before we initialize schedulers we must know which reset
domain are we in - for single device there iis a single
domain per device and so single wq per device. For XGMI
the reset domain spans the entire XGMI hive and so the
reset wq is per hive.
Signed-off-by: Andrey Grodzovsky
---
Use reset domain wq also for non TDR gpu recovery trigers
such as sysfs and RAS. We must serialize all possible
GPU recoveries to gurantee no concurrency there.
For TDR call the original recovery function directly since
it's already executed from within the wq. For others just
use a wrapper to
Restrict jobs resubmission to suspend case
only since schedulers not initialised yet on
probe.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
Defined a reset_domain struct such that
all the entities that go through reset
together will be serialized one against
another. Do it for both single device and
XGMI hive cases.
Signed-off-by: Andrey Grodzovsky
Suggested-by: Daniel Vetter
Suggested-by: Christian König
Reviewed-by: Christian
This patchset is based on earlier work by Boris[1] that allowed to have an
ordered workqueue at the driver level that will be used by the different
schedulers to queue their timeout work. On top of that I also serialized
any GPU reset we trigger from within amdgpu code to also go through the same
On Tue, Dec 07, 2021 at 01:34:07PM +0100, Christian König wrote:
> Add an usage for kernel submissions. Waiting for those
> are mandatory for dynamic DMA-bufs.
>
> Signed-off-by: Christian König
Again just skipping to the doc bikeshedding, maybe with more cc others
help with some code review
On Tue, Dec 07, 2021 at 01:34:05PM +0100, Christian König wrote:
> This change adds the dma_resv_usage enum and allows us to specify why a
> dma_resv object is queried for its containing fences.
>
> Additional to that a dma_resv_usage_rw() helper function is added to aid
> retrieving the fences
On 12/22/2021 08:21, Tvrtko Ursulin wrote:
On 21/12/2021 22:14, John Harrison wrote:
On 12/21/2021 05:37, Tvrtko Ursulin wrote:
On 20/12/2021 18:34, John Harrison wrote:
On 12/20/2021 07:00, Tvrtko Ursulin wrote:
On 17/12/2021 16:22, Matthew Brost wrote:
On Fri, Dec 17, 2021 at 12:15:53PM
On Tue, Dec 07, 2021 at 01:34:04PM +0100, Christian König wrote:
> Makes the code a bit more simpler.
>
> Signed-off-by: Christian König
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c | 23 +++
> 1 file changed, 3 insertions(+), 20 deletions(-)
On Tue, Dec 07, 2021 at 01:34:03PM +0100, Christian König wrote:
> Use dma_resv_get_singleton() here to eventually get more than one write
> fence as single fence.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/nouveau/dispnv50/wndw.c | 14 +-
> 1 file changed, 5
On Tue, Dec 07, 2021 at 01:34:02PM +0100, Christian König wrote:
> Use dma_resv_get_singleton() here to eventually get more than one write
> fence as single fence.
>
> Signed-off-by: Christian König
Patch title should be drm/atomic-helper: prefix, not just drm:
With that nit:
Reviewed-by:
On Tue, Dec 07, 2021 at 01:34:01PM +0100, Christian König wrote:
> Audit all the users of dma_resv_add_excl_fence() and make sure they
> reserve a shared slot also when only trying to add an exclusive fence.
>
> This is the next step towards handling the exclusive fence like a
> shared one.
>
>
On Tue, Dec 07, 2021 at 01:34:00PM +0100, Christian König wrote:
> So far we had the approach of using a directed acyclic
> graph with the dma_resv obj.
>
> This turned out to have many downsides, especially it means
> that every single driver and user of this interface needs
> to be aware of
On Tue, Dec 07, 2021 at 01:33:59PM +0100, Christian König wrote:
> Drivers should never touch this directly.
>
> Signed-off-by: Christian König
> ---
> drivers/dma-buf/dma-resv.c | 17 +
> include/linux/dma-resv.h | 17 -
> 2 files changed, 17 insertions(+), 17
On Tue, Dec 07, 2021 at 01:33:58PM +0100, Christian König wrote:
> Get the write fence using dma_resv_for_each_fence instead of accessing
> it manually.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 9 ++---
> 1 file changed, 6 insertions(+), 3
On Tue, Dec 07, 2021 at 01:33:57PM +0100, Christian König wrote:
> This was added because of the now dropped shared on excl dependency.
>
> Signed-off-by: Christian König
I didn't do a full re-audit of whether you got them all, I think latest
with the semantic change to allow more kinds of
On Tue, Dec 07, 2021 at 01:33:55PM +0100, Christian König wrote:
> Instead use the new dma_resv_get_singleton function.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git
On Tue, Dec 07, 2021 at 01:33:56PM +0100, Christian König wrote:
> Instead use the new dma_resv_get_singleton function.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/radeon/radeon_display.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git
On Tue, Dec 07, 2021 at 01:33:54PM +0100, Christian König wrote:
> Instead use the new dma_resv_get_singleton function.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/nouveau/nouveau_bo.c | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git
On Tue, Dec 07, 2021 at 01:33:53PM +0100, Christian König wrote:
> We can get the excl fence together with the shared ones as well.
>
> Signed-off-by: Christian König
Pls cc driver maintainers.
dim add-missing-cc
is your friend if you're lazy can even combine that with git rebase -x.
Same for
On Tue, Dec 07, 2021 at 01:33:52PM +0100, Christian König wrote:
> Use dma_resv_wait() instead of extracting the exclusive fence and
> waiting on it manually.
>
> Signed-off-by: Christian König
No rdma lists nor maintainers on cc, so no chances to get the ack you need
to merge this through
On Tue, Dec 07, 2021 at 01:33:51PM +0100, Christian König wrote:
> Add a function to simplify getting a single fence for all the fences in
> the dma_resv object.
>
> v2: fix ref leak in error handling
>
> Signed-off-by: Christian König
> ---
> drivers/dma-buf/dma-resv.c | 52
On Tue, Dec 07, 2021 at 01:33:50PM +0100, Christian König wrote:
> Returning the exclusive fence separately is no longer used.
>
> Instead add a write parameter to indicate the use case.
>
> Signed-off-by: Christian König
> ---
> drivers/dma-buf/dma-resv.c | 48
On Tue, Dec 07, 2021 at 01:33:49PM +0100, Christian König wrote:
> Drivers should never touch this directly.
>
> Signed-off-by: Christian König
> ---
> drivers/dma-buf/dma-resv.c | 26 ++
> include/linux/dma-resv.h | 26 +-
> 2 files changed, 27
On Tue, Dec 07, 2021 at 01:33:48PM +0100, Christian König wrote:
> This function allows to replace fences from the shared fence list when
> we can gurantee that the operation represented by the original fence has
> finished or no accesses to the resources protected by the dma_resv
> object any
On Mon, Dec 20, 2021 at 11:15:22AM +0100, Johannes Berg wrote:
> From: Johannes Berg
>
> Even if it's probably not really useful, it can get selected
> by e.g. randconfig builds, and then failing to compile is an
> annoyance. Unfortunately, it's hard to fix in Kconfig, since
> DRM_TTM is
On Mon, Dec 20, 2021 at 01:12:51PM -0500, Bhardwaj, Rajneesh wrote:
>
> On 12/20/2021 4:29 AM, Daniel Vetter wrote:
> > On Fri, Dec 10, 2021 at 07:58:50AM +0100, Christian König wrote:
> > > Am 09.12.21 um 19:28 schrieb Felix Kuehling:
> > > > Am 2021-12-09 um 10:30 a.m. schrieb Christian König:
On Wed, Dec 22, 2021 at 04:25:13PM +, Tvrtko Ursulin wrote:
>
> Ping?
>
Missed this.
This was merged before your comments landed on the list.
> Main two points being:
>
> 1) Commit message seems in contradiction with the change in
> guc_flush_destroyed_contexts. And the lock drop to
https://bugzilla.kernel.org/show_bug.cgi?id=201957
roman (cool...@gmx.at) changed:
What|Removed |Added
CC||cool...@gmx.at
--- Comment #52
On Wed, Dec 22, 2021 at 3:40 PM Heiko Stübner wrote:
>
> Am Mittwoch, 22. Dezember 2021, 14:52:51 CET schrieb Rob Herring:
> > On Wed, Dec 22, 2021 at 6:47 AM Sascha Hauer wrote:
> > >
> > > On Tue, Dec 21, 2021 at 10:31:23AM -0400, Rob Herring wrote:
> > > > On Mon, Dec 20, 2021 at 12:06:16PM
20.12.2021 13:48, Thierry Reding пишет:
> From: Thierry Reding
>
> The DPAUX hardware block exposes an DP AUX interface that provides
> access to an AUX bus and the devices on that bus. Use the DP AUX bus
> infrastructure that was recently introduced to probe devices on this
> bus from DT.
>
>
On Mittwoch, 22. Dezember 2021 20:39:58 CET Heiko Stübner wrote:
> Am Mittwoch, 22. Dezember 2021, 14:52:51 CET schrieb Rob Herring:
> > On Wed, Dec 22, 2021 at 6:47 AM Sascha Hauer wrote:
> > >
> > > On Tue, Dec 21, 2021 at 10:31:23AM -0400, Rob Herring wrote:
> > > > On Mon, Dec 20, 2021 at
On 12/22/21 16:56, Maarten Lankhorst wrote:
Convert free_work into delayed_work, similar to ttm to allow converting the
blocking lock in __i915_gem_free_objects to a trylock.
Unlike ttm, the object should already be idle, as it's kept alive
by a reference through struct i915_vma->active,
Am Mittwoch, 22. Dezember 2021, 14:52:51 CET schrieb Rob Herring:
> On Wed, Dec 22, 2021 at 6:47 AM Sascha Hauer wrote:
> >
> > On Tue, Dec 21, 2021 at 10:31:23AM -0400, Rob Herring wrote:
> > > On Mon, Dec 20, 2021 at 12:06:16PM +0100, Sascha Hauer wrote:
> > > > "vpll" is a misnomer. A clock
dp_debug_init() always returns 0. So, make it a void function and simplify
the only caller accordingly.
While at it remove a useless 'rc' initialization in dp_debug_get()
Signed-off-by: Christophe JAILLET
---
drivers/gpu/drm/msm/dp/dp_debug.c | 13 +++--
1 file changed, 3
22.12.2021 22:30, Jon Hunter пишет:
>
> On 22/12/2021 19:01, Dmitry Osipenko wrote:
>
> ...
>
>> diff --git a/drivers/gpu/host1x/syncpt.c b/drivers/gpu/host1x/syncpt.c
>> index e08e331e46ae..8194826c9ce3 100644
>> --- a/drivers/gpu/host1x/syncpt.c
>> +++ b/drivers/gpu/host1x/syncpt.c
>> @@
On 22/12/2021 19:01, Dmitry Osipenko wrote:
...
diff --git a/drivers/gpu/host1x/syncpt.c b/drivers/gpu/host1x/syncpt.c
index e08e331e46ae..8194826c9ce3 100644
--- a/drivers/gpu/host1x/syncpt.c
+++ b/drivers/gpu/host1x/syncpt.c
@@ -137,6 +137,15 @@ void host1x_syncpt_restore(struct host1x
20.12.2021 13:48, Thierry Reding пишет:
> From: Thierry Reding
>
> Move the eDP panel on Venice 2 and Nyan boards into the corresponding
> AUX bus device tree node. This allows us to avoid a nasty circular
> dependency that would otherwise be created between the DPAUX and panel
> nodes via the
22.12.2021 14:53, Thierry Reding пишет:
> On Wed, Dec 22, 2021 at 06:01:26AM +0300, Dmitry Osipenko wrote:
>> 21.12.2021 21:01, Thierry Reding пишет:
>>> On Tue, Dec 21, 2021 at 07:45:31PM +0300, Dmitry Osipenko wrote:
21.12.2021 19:17, Thierry Reding пишет:
> On Tue, Dec 21, 2021 at
On 12/22/21 19:03, Rob Herring wrote:
On Mon, 20 Dec 2021 13:51:47 +0100, Thierry Reding wrote:
From: Thierry Reding
In order to validate multiple "if" conditionals, they must be part of an
"allOf:" list, otherwise they will cause a failure in parsing the schema
because of the duplicated "if"
22.12.2021 21:41, Jon Hunter пишет:
>
> On 22/12/2021 09:47, Jon Hunter wrote:
>>
>> On 21/12/2021 20:58, Dmitry Osipenko wrote:
>>> Hi,
>>>
>>> Thank you for testing it all.
>>>
>>> 21.12.2021 21:55, Jon Hunter пишет:
Hi Dmitry, Thierry,
On 30/11/2021 23:23, Dmitry Osipenko wrote:
On 22/12/2021 09:47, Jon Hunter wrote:
On 21/12/2021 20:58, Dmitry Osipenko wrote:
Hi,
Thank you for testing it all.
21.12.2021 21:55, Jon Hunter пишет:
Hi Dmitry, Thierry,
On 30/11/2021 23:23, Dmitry Osipenko wrote:
Add runtime PM and OPP support to the Host1x driver. For the starter
On Tue, 21 Dec 2021 08:51:26 -0400, Rob Herring wrote:
> With 'unevaluatedProperties' support enabled, the novatek,nt36672a
> binding has a new warning:
>
> Documentation/devicetree/bindings/display/panel/novatek,nt36672a.example.dt.yaml:
> panel@0: Unevaluated properties are not allowed
On Mon, 20 Dec 2021 19:42:20 +0100, David Heidelberg wrote:
> Driver and dts has been already adjusted and bus moved out of dpu, let's
> update also dt-bindings.
>
> Fixes warnings as:
> arch/arm64/boot/dts/qcom/sdm845-oneplus-fajita.dt.yaml: mdss
> @ae0: clock-names: ['iface', 'core'] is too
On Mon, 20 Dec 2021 13:51:47 +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> In order to validate multiple "if" conditionals, they must be part of an
> "allOf:" list, otherwise they will cause a failure in parsing the schema
> because of the duplicated "if" property.
>
> Fixes:
On 12/22/21 18:43, Rafał Miłecki wrote:
Hi,
Hi,
ba3e86789eaf ("dt-bindings: display: bridge: lvds-codec: Document LVDS
data mapping select")
d7df3948eb49 ("dt-bindings: display: bridge: lvds-codec: Document pixel
data sampling edge select")
Both commits add "if" and "then" at YAML "root"
Hi,
I just noticed that "make dt_binding_check" doesn't work in linux-next:
SCHEMA Documentation/devicetree/bindings/processed-schema-examples.json
Traceback (most recent call last):
File "/home/rmilecki/.local/bin/dt-mk-schema", line 38, in
schemas =
On Dienstag, 21. Dezember 2021 14:44:39 CET Nicolas Frattaroli wrote:
> On Montag, 20. Dezember 2021 12:06:30 CET Sascha Hauer wrote:
> > From: Andy Yan
> >
> > The VOP2 unit is found on Rockchip SoCs beginning with rk3566/rk3568.
> > It replaces the VOP unit found in the older Rockchip SoCs.
> >
Ping?
Main two points being:
1) Commit message seems in contradiction with the change in
guc_flush_destroyed_contexts. And the lock drop to immediately
re-acquire it looks questionable to start with.
2) And in deregister_destroyed_contexts and in 1) I was therefore asking
if you can
On 21/12/2021 22:14, John Harrison wrote:
On 12/21/2021 05:37, Tvrtko Ursulin wrote:
On 20/12/2021 18:34, John Harrison wrote:
On 12/20/2021 07:00, Tvrtko Ursulin wrote:
On 17/12/2021 16:22, Matthew Brost wrote:
On Fri, Dec 17, 2021 at 12:15:53PM +, Tvrtko Ursulin wrote:
On
Convert free_work into delayed_work, similar to ttm to allow converting the
blocking lock in __i915_gem_free_objects to a trylock.
Unlike ttm, the object should already be idle, as it's kept alive
by a reference through struct i915_vma->active, which is dropped
after all vma's are idle.
Because
acpi_dev_get_resources() does perform the NULL pointer check against
ACPI companion device which is given as function parameter. Thus,
there is no need to duplicate this check in the caller.
Signed-off-by: Andy Shevchenko
---
v2: used LIST_HEAD() (Ville), initialized lookup directly on stack
Applied. Thanks!
Alex
On Fri, Dec 17, 2021 at 11:22 PM Yizhuo Zhai wrote:
>
> In function enable_stream_features(), the variable "old_downspread.raw"
> could be uninitialized if core_link_read_dpcd() fails, however, it is
> used in the later if statement, and further, core_link_write_dpcd()
>
1 - 100 of 148 matches
Mail list logo
