On 03-06-2021 01:32, rajee...@codeaurora.org wrote:
On 02-06-2021 02:28, Rob Herring wrote:
On Mon, May 31, 2021 at 07:03:53PM +0530, Rajeev Nandan wrote:
+
+properties:
+ compatible:
+oneOf:
+ - const: qcom,dsi-phy-7nm
When would one use this?
This is for SM8250.
+ -
On Wed, Jun 16, 2021 at 12:59 PM Christoph Hellwig wrote:
>
> On Wed, Jun 16, 2021 at 12:04:16PM +0800, Claire Chang wrote:
> > Just noticed that after propagating swiotlb_force setting into
> > io_tlb_default_mem->force, the memory allocation behavior for
> > swiotlb_force will change (i.e.
On Wed, Jun 16, 2021 at 11:54 AM Claire Chang wrote:
>
> Add the functions, swiotlb_{alloc,free} to support the memory allocation
> from restricted DMA pool.
>
> The restricted DMA pool is preferred if available.
>
> Note that since coherent allocation needs remapping, one must set up
> another
v11 https://lore.kernel.org/patchwork/cover/1447216/
On Tue, Jun 15, 2021 at 9:27 PM Claire Chang wrote:
>
> This series implements mitigations for lack of DMA access control on
> systems without an IOMMU, which could result in the DMA accessing the
> system memory at unexpected times and/or
This patch adds missing MODULE_DEVICE_TABLE definition which generates
correct modalias for automatic loading of this driver when it is built
as an external module.
Signed-off-by: Yu Jiahua
---
drivers/gpu/drm/bridge/analogix/anx7625.c | 1 +
1 file changed, 1 insertion(+)
diff --git
[Why]
After unplug/hotplug hub from the system, userspace might start to
clear stale payloads gradually. If we call drm_dp_mst_deallocate_vcpi()
to release stale VCPI of those ports which are not relating to current
topology, we have chane to wrongly clear active payload table entry for
current
Use Startech 1to3 DP hub to do some mst hotplug tests and find some
light up issues.
1. ACT polling timeout:
Which is due to we didn't update DPCD payload table but still try
to send ACT and polling for "ACT Handled" bit
2. Not all monitors light up:
Due to we wrongly set unavailable VCP
[Why]
When we receive CSN message to notify one port is disconnected, we will
implicitly set its corresponding num_slots to 0. Later on, we will
eventually call drm_dp_update_payload_part1() to arrange down streams.
In drm_dp_update_payload_part1(), we iterate over all proposed_vcpis[]
to do the
If a device is not behind an IOMMU, we look up the device node and set
up the restricted DMA when the restricted-dma-pool is presented.
Signed-off-by: Claire Chang
---
drivers/of/address.c| 33 +
drivers/of/device.c | 3 +++
drivers/of/of_private.h | 6
Introduce the new compatible string, restricted-dma-pool, for restricted
DMA. One can specify the address and length of the restricted DMA memory
region by restricted-dma-pool in the reserved-memory node.
Signed-off-by: Claire Chang
---
.../reserved-memory/reserved-memory.txt | 36
Add the initialization function to create restricted DMA pools from
matching reserved-memory nodes.
Regardless of swiotlb setting, the restricted DMA pool is preferred if
available.
The restricted DMA pools provide a basic level of protection against the
DMA overwriting buffer contents at
Add the functions, swiotlb_{alloc,free} to support the memory allocation
from restricted DMA pool.
The restricted DMA pool is preferred if available.
Note that since coherent allocation needs remapping, one must set up
another device coherent pool by shared-dma-pool and use
Add a new function, swiotlb_release_slots, to make the code reusable for
supporting different bounce buffer pools.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
---
kernel/dma/swiotlb.c | 35 ---
1 file changed, 20 insertions(+), 15 deletions(-)
Rename find_slots to swiotlb_find_slots and move the maintenance of
alloc_size to it for better code reusability later.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
---
kernel/dma/swiotlb.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git
Propagate the swiotlb_force setting into io_tlb_default_mem->force and
use it to determine whether to bounce the data or not. This will be
useful later to allow for different pools.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
---
include/linux/swiotlb.h | 11 +++
Update is_swiotlb_active to add a struct device argument. This will be
useful later to allow for different pools.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
---
drivers/gpu/drm/i915/gem/i915_gem_internal.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_ttm.c| 2 +-
Update is_swiotlb_buffer to add a struct device argument. This will be
useful later to allow for different pools.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
---
drivers/iommu/dma-iommu.c | 12 ++--
drivers/xen/swiotlb-xen.c | 2 +-
include/linux/swiotlb.h | 7
Always have the pointer to the swiotlb pool used in struct device. This
could help simplify the code for other pools.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
---
drivers/base/core.c| 4
include/linux/device.h | 4
kernel/dma/swiotlb.c | 8
3 files
Split the debugfs creation to make the code reusable for supporting
different bounce buffer pools.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
---
kernel/dma/swiotlb.c | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/kernel/dma/swiotlb.c
Add a new function, swiotlb_init_io_tlb_mem, for the io_tlb_mem struct
initialization to make the code reusable.
Signed-off-by: Claire Chang
Reviewed-by: Christoph Hellwig
---
kernel/dma/swiotlb.c | 49 ++--
1 file changed, 24 insertions(+), 25
This series implements mitigations for lack of DMA access control on
systems without an IOMMU, which could result in the DMA accessing the
system memory at unexpected times and/or unexpected addresses, possibly
leading to data leakage or corruption.
For example, we plan to use the PCI-e bus for
[Public]
> From: Lyude Paul
> Sent: Wednesday, June 16, 2021 03:44
> To: Lin, Wayne; dri-devel@lists.freedesktop.org
> Cc: Kazlauskas, Nicholas; Wentland, Harry; Zuo, Jerry; Pillai, Aurabindo
> Subject: Re: [PATCH 2/2] drm/dp_mst: Avoid to mess up payload
From: Jiahua Yu
spinlock can be initialized automatically with DEFINE_SPINLOCK()
rather than explicitly calling spin_lock_init().
Signed-off-by: Jiahua Yu
---
drivers/video/fbdev/omap2/omapfb/dss/apply.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git
On Wednesday, 16 June 2021 2:25:09 AM AEST Peter Xu wrote:
> On Tue, Jun 15, 2021 at 01:08:11PM +1000, Alistair Popple wrote:
> > On Saturday, 12 June 2021 1:01:42 AM AEST Peter Xu wrote:
> > > On Fri, Jun 11, 2021 at 01:43:20PM +1000, Alistair Popple wrote:
[...]
> > > Do you think we can
On Tue, Jun 15, 2021 at 04:11:29PM +0200, Greg Kroah-Hartman wrote:
> On Tue, Jun 15, 2021 at 03:35:16PM +0200, Christoph Hellwig wrote:
> > From: Jason Gunthorpe
> >
> > This allows a mdev driver to opt out of using vfio_mdev.c, instead the
> > driver will provide a 'struct mdev_driver' and
On 6/15/2021 1:59 PM, Matthew Brost wrote:
The submission tasklet operates on i915_sched_engine, thus it is the
correct place for it.
v3:
(Jason Ekstrand)
Change sched_engine->engine to a void* private data pointer
Add kernel doc
v4:
(Daniele)
Update private_data comment
Set
From: Michal Wajdeczko
Most of the changes to the 62.0.0 firmware revolved around CTB
communication channel. Conform to the new (stable) CTB protocol.
v2:
(Michal)
Add values back to kernel DOC for actions
(Docs)
Add 'CT buffer' back in to fix warning
Signed-off-by: John Harrison
From: Michal Wajdeczko
GuC ABI documentation is now ready to be included in i915.rst
Signed-off-by: Michal Wajdeczko
Signed-off-by: Matthew Brost
Cc: Piotr Piórkowski
Reviewed-by: Matthew Brost
---
Documentation/gpu/i915.rst | 8
1 file changed, 8 insertions(+)
diff --git
From: Michal Wajdeczko
New GuC firmware will unify format of MMIO and CTB H2G messages.
Introduce their definitions now to allow gradual transition of
our code to match new changes.
Signed-off-by: Matthew Brost
Signed-off-by: Michal Wajdeczko
Cc: Michał Winiarski
Reviewed-by: Daniele Ceraolo
As part of enabling GuC submission [1] we need to update to the latest
and greatest firmware. This series does that. All backwards
compatibility breaking changes squashed into a single patch #2. Same
series sent to trybot [2] forcing GuC to be enabled to ensure we haven't
broke something.
v2:
The SN65DSI86 provides the ability to supply a PWM signal on GPIO 4,
with the primary purpose of controlling the backlight of the attached
panel. Add an implementation that exposes this using the standard PWM
framework, to allow e.g. pwm-backlight to expose this to the user.
Signed-off-by: Bjorn
The existing pxa driver and the upcoming addition of PWM support in the
TI sn565dsi86 DSI/eDP bridge driver both has a single PWM channel and
thereby a need for a of_xlate function with the period as its single
argument.
Introduce a common helper function in the core that can be used as
of_xlate
Move active request tracking and its lock to i915_sched_engine. This
lock is also the submission lock so having it in the i915_sched_engine
is the correct place.
v3:
(Jason Ekstrand)
Add kernel doc
Signed-off-by: Matthew Brost
Reviewed-by: Daniele Ceraolo Spurio
---
The schedule function should be in the schedule object.
v3:
(Jason Ekstrand)
Add kernel doc
Signed-off-by: Matthew Brost
Reviewed-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gem/i915_gem_wait.c | 4 ++--
drivers/gpu/drm/i915/gt/intel_engine_cs.c| 3 ---
Rather passing around an intel_engine_cs in the scheduling code, pass
around a i915_sched_engine.
v3:
(Jason Ekstrand)
Add READ_ONCE around rq->engine in lock_sched_engine
Signed-off-by: Matthew Brost
Reviewed-by: Jason Ekstrand
---
.../drm/i915/gt/intel_execlists_submission.c | 11 +++--
Not all back-ends require a kick after a scheduling update, so make the
kick a call-back function that the back-end can opt-in to. Also move
the current kick function from the scheduler to the execlists file as it
is specific to that back-end.
Signed-off-by: Matthew Brost
Reviewed-by: Daniele
The submission tasklet operates on i915_sched_engine, thus it is the
correct place for it.
v3:
(Jason Ekstrand)
Change sched_engine->engine to a void* private data pointer
Add kernel doc
v4:
(Daniele)
Update private_data comment
Set queue_priority_hint in kick_execlists
v5:
(CI)
As discussed in [1] we are breaking that large series into a several
smaller ones. This series is stand alone patch part of step #4 which has
no other dependencies or patches relevant to it.
v2:
(Daniel Vetter):
- Split into several smaller patches
- Add kernel doc for i915_sched_engine
Add wrapper function around RB tree to determine if i915_sched_engine is
empty.
Signed-off-by: Matthew Brost
Reviewed-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c| 2 +-
drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 6 +++---
Rather than touching schedule state in the generic PM code, reset the
priolist allocation when empty in the submission code. Add a wrapper
function to do this and update the backends to call it in the correct
place.
v3:
(Jason Ekstrand)
Update patch commit message with a better description
Introduce i915_sched_engine object which is lower level data structure
that i915_scheduler / generic code can operate on without touching
execlist specific structures. This allows additional submission backends
to be added without breaking the layering. Currently the execlists
backend uses 1 of
10.06.2021 14:04, Mikko Perttunen пишет:
> +drop_refs:
> + for (;;) {
> + if (i-- == 0)
> + break;
> +
while(i--) ?
On Tue, Jun 15, 2021 at 09:27:02PM +0800, Claire Chang wrote:
> Always have the pointer to the swiotlb pool used in struct device. This
> could help simplify the code for other pools.
Applying: swiotlb: Set dev->dma_io_tlb_mem to the swiotlb pool used
error: patch failed: kernel/dma/swiotlb.c:339
10.06.2021 14:04, Mikko Perttunen пишет:
> +++ b/drivers/gpu/drm/tegra/gather_bo.c
> @@ -0,0 +1,82 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/* Copyright (c) 2020 NVIDIA Corporation */
> +
> +#include
> +#include
> +#include
> +
> +#include "gather_bo.h"
> +
...
> +const struct
https://bugzilla.kernel.org/show_bug.cgi?id=213391
--- Comment #14 from Dominic Letz (dominic.l...@berlin.de) ---
Having the same issue on an E495 with Kernel 5.12.9. Will try to downgrade the
/lib/firmware/amdgpu any hint to which git tag you would consider safe?
--
You may reply to this email
https://bugzilla.kernel.org/show_bug.cgi?id=209457
--- Comment #25 from Leandro Jacques (ls...@yahoo.com) ---
I don't have this issue with kernel 5.12.10
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
10.06.2021 14:04, Mikko Perttunen пишет:
> Add a new property for jobs to enable or disable recovery i.e.
> CPU increments of syncpoints to max value on job timeout. This
> allows for a more solid model for hanged jobs, where userspace
> doesn't need to guess if a syncpoint increment happened
On Tue, Jun 15, 2021 at 2:49 AM Daniel Vetter wrote:
>
> On Thu, Jun 03, 2021 at 02:47:51PM -0700, Hridya Valsaraju wrote:
> > Overview
> >
> > The patch adds DMA-BUF statistics to /sys/kernel/dmabuf/buffers. It
> > allows statistics to be enabled for each DMA-BUF in sysfs by enabling
>
..
> diff --git a/drivers/gpu/host1x/fence.c b/drivers/gpu/host1x/fence.c
> new file mode 100644
> index ..2b0bb97f053f
> --- /dev/null
> +++ b/drivers/gpu/host1x/fence.c
> @@ -0,0 +1,184 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Syncpoint dma_fence implementation
> +
https://bugzilla.kernel.org/show_bug.cgi?id=213053
Alexey (skobkin...@ya.ru) changed:
What|Removed |Added
CC||skobkin...@ya.ru
--- Comment
Move active request tracking and its lock to i915_sched_engine. This
lock is also the submission lock so having it in the i915_sched_engine
is the correct place.
v3:
(Jason Ekstrand)
Add kernel doc
Signed-off-by: Matthew Brost
Reviewed-by: Daniele Ceraolo Spurio
---
Rather passing around an intel_engine_cs in the scheduling code, pass
around a i915_sched_engine.
v3:
(Jason Ekstrand)
Add READ_ONCE around rq->engine in lock_sched_engine
Signed-off-by: Matthew Brost
Reviewed-by: Jason Ekstrand
---
.../drm/i915/gt/intel_execlists_submission.c | 11 +++--
Not all back-ends require a kick after a scheduling update, so make the
kick a call-back function that the back-end can opt-in to. Also move
the current kick function from the scheduler to the execlists file as it
is specific to that back-end.
Signed-off-by: Matthew Brost
Reviewed-by: Daniele
The submission tasklet operates on i915_sched_engine, thus it is the
correct place for it.
v3:
(Jason Ekstrand)
Change sched_engine->engine to a void* private data pointer
Add kernel doc
v4:
(Daniele)
Update private_data comment
Set queue_priority_hint in kick_execlists
Signed-off-by:
The schedule function should be in the schedule object.
v3:
(Jason Ekstrand)
Add kernel doc
Signed-off-by: Matthew Brost
Reviewed-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gem/i915_gem_wait.c | 4 ++--
drivers/gpu/drm/i915/gt/intel_engine_cs.c| 3 ---
Add wrapper function around RB tree to determine if i915_sched_engine is
empty.
Signed-off-by: Matthew Brost
Reviewed-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c| 2 +-
drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 6 +++---
As discussed in [1] we are breaking that large series into a several
smaller ones. This series is stand alone patch part of step #4 which has
no other dependencies or patches relevant to it.
v2:
(Daniel Vetter):
- Split into several smaller patches
- Add kernel doc for i915_sched_engine
Rather than touching schedule state in the generic PM code, reset the
priolist allocation when empty in the submission code. Add a wrapper
function to do this and update the backends to call it in the correct
place.
v3:
(Jason Ekstrand)
Update patch commit message with a better description
Introduce i915_sched_engine object which is lower level data structure
that i915_scheduler / generic code can operate on without touching
execlist specific structures. This allows additional submission backends
to be added without breaking the layering. Currently the execlists
backend uses 1 of
On Tue, Jun 15, 2021 at 8:50 AM Sasha Levin wrote:
>
> From: Saravana Kannan
>
> [ Upstream commit 9bf3797796f570b34438235a6a537df85832bdad ]
>
> On sunxi boards that use HDMI output, HDMI device probe keeps being
> avoided indefinitely with these repeated messages in dmesg:
>
> platform
On Tue, Jun 15, 2021 at 01:35:49PM -0600, Alex Williamson wrote:
> On Tue, 15 Jun 2021 15:35:09 +0200
> Christoph Hellwig wrote:
>
> > This is my alternative take on this series from Jason:
> >
> > https://lore.kernel.org/dri-devel/87czsszi9i@redhat.com/T/
> >
> > The mdev/vfio parts are
10.06.2021 14:04, Mikko Perttunen пишет:
> Hi all,
>
> here's the seventh revision of the TegraDRM UAPI proposal.
> Only some small changes to v6 here to fix things on older
> Tegras with certain configuration combinations, as well as
> rebasing to latest linux-next.
>
> The following pieces of
Applied. Thanks!
On Tue, Jun 15, 2021 at 8:54 AM Rodrigo Siqueira
wrote:
>
> On 06/15, Wan Jiabing wrote:
> > Fix the following coccicheck warning:
> > drivers/gpu/drm/amd/display/dc/dcn31/dcn31_resource.c:917:56-57:
> > pstate_enabled: first occurrence line 935, second occurrence line 937
> >
On Fri, 2021-05-28 at 21:55 +0800, Wayne Lin wrote:
> [Why]
> After unplug/hotplug hub from the system, userspace might start to
> clear stale payloads gradually. If we call drm_dp_mst_deallocate_vcpi()
> to release stale VCPI of those ports which are not relating to current
> topology, we have
https://bugzilla.kernel.org/show_bug.cgi?id=213201
--- Comment #7 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 297379
--> https://bugzilla.kernel.org/attachment.cgi?id=297379=edit
output of /sys/kernel/debug/kmemleak (kernel 4.4.271)
--
You may reply to this email to add a
On Tue, 15 Jun 2021 15:35:13 +0200
Christoph Hellwig wrote:
> @@ -547,10 +538,9 @@ static int call_driver_probe(struct device *dev, struct
> device_driver *drv)
>
> static int really_probe(struct device *dev, struct device_driver *drv)
> {
> - int local_trigger_count =
On Tue, 15 Jun 2021 15:35:09 +0200
Christoph Hellwig wrote:
> This is my alternative take on this series from Jason:
>
> https://lore.kernel.org/dri-devel/87czsszi9i@redhat.com/T/
>
> The mdev/vfio parts are exactly the same, but this solves the driver core
> changes for the direct probing
https://bugzilla.kernel.org/show_bug.cgi?id=213201
--- Comment #6 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 297377
--> https://bugzilla.kernel.org/attachment.cgi?id=297377=edit
kernel .config (4.4.271, AMD A10 PRO-7800B)
--
You may reply to this email to add a comment.
You
https://bugzilla.kernel.org/show_bug.cgi?id=213201
--- Comment #5 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 297375
--> https://bugzilla.kernel.org/attachment.cgi?id=297375=edit
kernel dmesg (4.4.271, AMD A10 PRO-7800B)
Bisecting was no success, but I traced the memory leak
If a property has an 'items' list, then a 'minItems' or 'maxItems' with the
same size as the list is redundant and can be dropped. Note that is DT
schema specific behavior and not standard json-schema behavior. The tooling
will fixup the final schema adding any unspecified minItems/maxItems.
This
On 6/15/21 10:00 PM, Jon Hunter wrote:
On 10/06/2021 12:04, Mikko Perttunen wrote:
Implement the job submission IOCTL with a minimum feature set.
Signed-off-by: Mikko Perttunen
---
v7:
* Allocate gather BO with DMA API to get page-aligned
memory
* Add error prints to a few places where
On 10/06/2021 12:04, Mikko Perttunen wrote:
> Implement the job submission IOCTL with a minimum feature set.
>
> Signed-off-by: Mikko Perttunen
> ---
> v7:
> * Allocate gather BO with DMA API to get page-aligned
> memory
> * Add error prints to a few places where they were missing
> v6:
> *
On Tue, Jun 15, 2021 at 2:23 PM Zack Rusin wrote:
>
> Roland will be focusing on lavapipe over the next few months and
> won't have time for vmwgfx.
> vmwgfx is now maintained within drm-misc.
>
> Signed-off-by: Zack Rusin
> Reviewed-by: Roland Scheidegger
Acked-by: Alex Deucher
> ---
>
Register accesses are always 4bytes, accidently this was changed to
a void pointer whwqich badly breaks 64bit archs when running on top
of svga3.
Fixes: 2cd80dbd3551 ("drm/vmwgfx: Add basic support for SVGA3")
Signed-off-by: Zack Rusin
Reviewed-by: Martin Krastev
---
From: Martin Krastev
Fixes for ARCH
i386
* printk format specifier warnings
* inconsistent operand constraints in an ‘asm’ errors
arm64
* not targeted by the commit being fixed
Reviewed-by: Zack Rusin
Fixes: 7a7a933edd6c ("drm/vmwgfx: Introduce VMware mks-guest-stats")
Change
2ef4fb92363c ("drm/vmwgfx: Make sure bo's are unpinned before putting them
back")
caused a conflict in one of the drm trees and the merge commit
68a32ba14177 ("Merge tag 'drm-next-2021-04-28' of
git://anongit.freedesktop.org/drm/drm")
accidently re-added code that the original change was
Roland will be focusing on lavapipe over the next few months and
won't have time for vmwgfx.
vmwgfx is now maintained within drm-misc.
Signed-off-by: Zack Rusin
Reviewed-by: Roland Scheidegger
---
MAINTAINERS | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/MAINTAINERS
Am 15.06.21 um 16:14 schrieb Werner Sembach:
Add a new general drm property "active bpc" which can be used by graphic drivers
to report the applied bit depth per pixel back to userspace.
While "max bpc" can be used to change the color depth, there was no way to check
which one actually got
Add the missing unlock before return from function g2d_runqueue_worker()
in the error handling case.
Fixes: 445d3bed75de ("drm/exynos: use pm_runtime_resume_and_get()")
Reported-by: Hulk Robot
Signed-off-by: Wei Yongjun
---
drivers/gpu/drm/exynos/exynos_drm_g2d.c | 3 ++-
1 file changed, 2
On Tue, Jun 15, 2021 at 06:44:38PM +0200, Michal Wajdeczko wrote:
>
>
> On 15.06.2021 17:52, Matthew Brost wrote:
> > On Tue, Jun 15, 2021 at 11:00:09AM +0200, Michal Wajdeczko wrote:
> >>
> >>
> >> On 14.06.2021 21:42, Matthew Brost wrote:
> >>> From: Michal Wajdeczko
> >>>
> >>> Most of the
On 15.06.2021 17:52, Matthew Brost wrote:
> On Tue, Jun 15, 2021 at 11:00:09AM +0200, Michal Wajdeczko wrote:
>>
>>
>> On 14.06.2021 21:42, Matthew Brost wrote:
>>> From: Michal Wajdeczko
>>>
>>> Most of the changes to the 62.0.0 firmware revolved around CTB
>>> communication channel. Conform
On Tue, Jun 15, 2021 at 01:08:11PM +1000, Alistair Popple wrote:
> On Saturday, 12 June 2021 1:01:42 AM AEST Peter Xu wrote:
> > On Fri, Jun 11, 2021 at 01:43:20PM +1000, Alistair Popple wrote:
> > > On Friday, 11 June 2021 11:00:34 AM AEST Peter Xu wrote:
> > > > On Fri, Jun 11, 2021 at
Am 15.06.21 um 17:06 schrieb Felix Kuehling:
Am 2021-06-15 um 8:18 a.m. schrieb Christian König:
Am 15.06.21 um 14:11 schrieb Pan, Xinhui:
2021年6月15日 20:01，Christian König
写道：
Am 15.06.21 um 13:57 schrieb xinhui pan:
Amdgpu set SG flag in populate callback. So TTM still count pages
in SG
On Tue, Jun 15, 2021 at 11:00:09AM +0200, Michal Wajdeczko wrote:
>
>
> On 14.06.2021 21:42, Matthew Brost wrote:
> > From: Michal Wajdeczko
> >
> > Most of the changes to the 62.0.0 firmware revolved around CTB
> > communication channel. Conform to the new (stable) CTB protocol.
> >
> >
From: Chen Li
[ Upstream commit ab8363d3875a83f4901eb1cc00ce8afd24de6c85 ]
I met a gpu addr bug recently and the kernel log
tells me the pc is memcpy/memset and link register is
radeon_uvd_resume.
As we know, in some architectures, optimized memcpy/memset
may not work well on device memory.
From: Chen Li
[ Upstream commit ab8363d3875a83f4901eb1cc00ce8afd24de6c85 ]
I met a gpu addr bug recently and the kernel log
tells me the pc is memcpy/memset and link register is
radeon_uvd_resume.
As we know, in some architectures, optimized memcpy/memset
may not work well on device memory.
From: Chen Li
[ Upstream commit ab8363d3875a83f4901eb1cc00ce8afd24de6c85 ]
I met a gpu addr bug recently and the kernel log
tells me the pc is memcpy/memset and link register is
radeon_uvd_resume.
As we know, in some architectures, optimized memcpy/memset
may not work well on device memory.
From: Chen Li
[ Upstream commit ab8363d3875a83f4901eb1cc00ce8afd24de6c85 ]
I met a gpu addr bug recently and the kernel log
tells me the pc is memcpy/memset and link register is
radeon_uvd_resume.
As we know, in some architectures, optimized memcpy/memset
may not work well on device memory.
From: Saravana Kannan
[ Upstream commit 9bf3797796f570b34438235a6a537df85832bdad ]
On sunxi boards that use HDMI output, HDMI device probe keeps being
avoided indefinitely with these repeated messages in dmesg:
platform 1ee.hdmi: probe deferral - supplier 1ef.hdmi-phy
not ready
From: Chen Li
[ Upstream commit ab8363d3875a83f4901eb1cc00ce8afd24de6c85 ]
I met a gpu addr bug recently and the kernel log
tells me the pc is memcpy/memset and link register is
radeon_uvd_resume.
As we know, in some architectures, optimized memcpy/memset
may not work well on device memory.
From: Saravana Kannan
[ Upstream commit 9bf3797796f570b34438235a6a537df85832bdad ]
On sunxi boards that use HDMI output, HDMI device probe keeps being
avoided indefinitely with these repeated messages in dmesg:
platform 1ee.hdmi: probe deferral - supplier 1ef.hdmi-phy
not ready
From: Chen Li
[ Upstream commit ab8363d3875a83f4901eb1cc00ce8afd24de6c85 ]
I met a gpu addr bug recently and the kernel log
tells me the pc is memcpy/memset and link register is
radeon_uvd_resume.
As we know, in some architectures, optimized memcpy/memset
may not work well on device memory.
From: Saravana Kannan
[ Upstream commit 9bf3797796f570b34438235a6a537df85832bdad ]
On sunxi boards that use HDMI output, HDMI device probe keeps being
avoided indefinitely with these repeated messages in dmesg:
platform 1ee.hdmi: probe deferral - supplier 1ef.hdmi-phy
not ready
From: Chen Li
[ Upstream commit ab8363d3875a83f4901eb1cc00ce8afd24de6c85 ]
I met a gpu addr bug recently and the kernel log
tells me the pc is memcpy/memset and link register is
radeon_uvd_resume.
As we know, in some architectures, optimized memcpy/memset
may not work well on device memory.
From: Saravana Kannan
[ Upstream commit 9bf3797796f570b34438235a6a537df85832bdad ]
On sunxi boards that use HDMI output, HDMI device probe keeps being
avoided indefinitely with these repeated messages in dmesg:
platform 1ee.hdmi: probe deferral - supplier 1ef.hdmi-phy
not ready
On Tue, Jun 15, 2021 at 07:50:21AM +0200, Christoph Hellwig wrote:
> On Tue, Jun 15, 2021 at 07:21:57AM +0200, Greg Kroah-Hartman wrote:
> > This looks much better as far as the driver core changes go, thank you
> > for doing this.
> >
> > I'm guessing there will be at least one more revision of
Am 2021-06-15 um 8:18 a.m. schrieb Christian König:
> Am 15.06.21 um 14:11 schrieb Pan, Xinhui:
>>> 2021年6月15日 20:01，Christian König
>>> 写道：
>>>
>>> Am 15.06.21 um 13:57 schrieb xinhui pan:
Amdgpu set SG flag in populate callback. So TTM still count pages
in SG
BO.
>>> It's
On 6/11/2021 3:14 AM, Rob Clark wrote:
From: Jordan Crouse
Use the new adreno-smmu-priv fault info function to get more SMMU
debug registers and print the current TTBR0 to debug per-instance
pagetables and figure out which GPU block generated the request.
Signed-off-by: Jordan Crouse
On 14/06/2021 17:26, Thomas Hellström wrote:
From: Chris Wilson
Update the PTE and emit a clear within a single unpreemptible packet
such that we can schedule and pipeline clears.
Signed-off-by: Chris Wilson
Co-developed-by: Thomas Hellström
Signed-off-by: Thomas Hellström
Reviewed-by:
On 14/06/2021 17:26, Thomas Hellström wrote:
From: Chris Wilson
If we pipeline the PTE updates and then do the copy of those pages
within a single unpreemptible command packet, we can submit the copies
and leave them to be scheduled without having to synchronously wait
under a global lock. In
1 - 100 of 185 matches
Mail list logo
