On Mon, May 06, 2019 at 06:30:49PM +0200, Andrey Konovalov wrote:
> This patch is a part of a series that extends arm64 kernel ABI to allow to
> pass tagged user pointers (with the top byte set to something else other
> than 0x00) as syscall arguments.
>
> strncpy_from_user and strnlen_user
On Mon, May 06, 2019 at 06:30:51PM +0200, Andrey Konovalov wrote:
> This patch is a part of a series that extends arm64 kernel ABI to allow to
> pass tagged user pointers (with the top byte set to something else other
> than 0x00) as syscall arguments.
>
> This patch allows tagged pointers to be
On Mon, May 06, 2019 at 06:30:53PM +0200, Andrey Konovalov wrote:
> This patch is a part of a series that extends arm64 kernel ABI to allow to
> pass tagged user pointers (with the top byte set to something else other
> than 0x00) as syscall arguments.
>
> mm/gup.c provides a kernel interface
For passthrough, after rebooted the VM, driver will do
a baco reset before doing other driver initialization during loading
driver. For doing the baco reset, it will first
check the baco reset capability. So first need to set the
cap from the vbios information or baco reset won't be
enabled.
On Mon, May 06, 2019 at 06:30:50PM +0200, Andrey Konovalov wrote:
> This patch is a part of a series that extends arm64 kernel ABI to allow to
> pass tagged user pointers (with the top byte set to something else other
> than 0x00) as syscall arguments.
>
> This patch adds ksys_ wrappers to the
Hi Kees,
Thanks for joining the thread ;).
On Tue, May 21, 2019 at 05:04:39PM -0700, Kees Cook wrote:
> On Tue, May 21, 2019 at 07:29:33PM +0100, Catalin Marinas wrote:
> > On Mon, May 20, 2019 at 04:53:07PM -0700, Evgenii Stepanov wrote:
> > > On Fri, May 17, 2019 at 7:49 AM Catalin Marinas
>
On Mon, May 06, 2019 at 06:30:52PM +0200, Andrey Konovalov wrote:
> This patch is a part of a series that extends arm64 kernel ABI to allow to
> pass tagged user pointers (with the top byte set to something else other
> than 0x00) as syscall arguments.
>
> do_pages_move() is used in the
On Mon, May 06, 2019 at 06:30:55PM +0200, Andrey Konovalov wrote:
> This patch is a part of a series that extends arm64 kernel ABI to allow to
> pass tagged user pointers (with the top byte set to something else other
> than 0x00) as syscall arguments.
>
> In copy_mount_options a user address is
On Tue, May 21, 2019 at 03:48:56PM -0300, Jason Gunthorpe wrote:
> On Fri, May 17, 2019 at 03:49:31PM +0100, Catalin Marinas wrote:
>
> > The tagged pointers (whether hwasan or MTE) should ideally be a
> > transparent feature for the application writer but I don't think we can
> > solve it
[Why]
The current state on the connector is queried when getting the max bpc
rather than the new state. This means that a new max bpc value can only
currently take effect on the commit *after* it changes.
The new state should be passed in instead.
[How]
Pass down the dm_state as drm state to
[Why]
The custom "max bpc" property was added to limit color depth while the
DRM one was still being merged. It's been a few kernel versions since
then and this TODO was still sticking around.
[How]
Attach the DRM max bpc property to the connector and drop all of our
custom property management.
On Wed, May 22, 2019 at 3:11 AM Catalin Marinas wrote:
>
> Hi Kees,
>
> Thanks for joining the thread ;).
>
> On Tue, May 21, 2019 at 05:04:39PM -0700, Kees Cook wrote:
> > On Tue, May 21, 2019 at 07:29:33PM +0100, Catalin Marinas wrote:
> > > On Mon, May 20, 2019 at 04:53:07PM -0700, Evgenii
The messages about amdgpu_cs_list_validate are duplicated because the
caller will complain into the logs as well and we can also get
interrupted by a signal here.
Also fix the the caller to not report -EAGAIN from validation.
Signed-off-by: Christian König
---
If drivers don't prefer a system memory placement
they should not but it into the placement list first.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c
When a signal arrives we should return immediately for
handling it and not try other placements first.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c
We are already doing this for DMA-buf imports and also for
amdgpu VM BOs for quite a while now.
If this doesn't run into any problems we are probably going
to stop removing BOs from the LRU altogether.
Signed-off-by: Christian König
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 9
BOs on the LRU might be blocked during command submission
and cause OOM situations.
Avoid this by blocking for the first busy BO not locked by
the same ticket as the BO we are searching space for.
v10: completely start over with the patch since we didn't
handled a whole bunch of corner
This avoids OOM situations when we have lots of threads
submitting at the same time.
v3: apply this to the whole driver, not just CS
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c| 2 +-
From: Chunming Zhou
add ticket for display bo, so that it can preempt busy bo.
v2: fix stupid rebase error
Change-Id: I9f031cdcc8267de00e819ae303baa0a52df8ebb9
Signed-off-by: Chunming Zhou
Reviewed-by: Christian König
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 21
And only move them in on validation. This allows for better control
when multiple processes are fighting over those resources.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git
Am 22.05.19 um 15:57 schrieb Andrey Grodzovsky:
Signed-off-by: Andrey Grodzovsky
Reviewed-by: Christian König
---
drivers/gpu/drm/scheduler/sched_main.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
Series is:
Acked-by: Alex Deucher
From: amd-gfx on behalf of Nicholas
Kazlauskas
Sent: Wednesday, May 22, 2019 11:11 AM
To: amd-gfx@lists.freedesktop.org
Cc: Li, Sun peng (Leo); Wentland, Harry; Kazlauskas, Nicholas
Subject: [PATCH 2/2] drm/amd/display: Use new
Move BOs which are currently in a lower domain to the new
LRU before allocating backing space while validating.
This makes sure that we always have enough entries on the
LRU to allow for other processes to wait for an operation
to complete.
v2: generalize the test
Signed-off-by: Christian König
We tried this once before, but that turned out to be more
complicated than thought. With all the right prerequisites
it looks like we can do this now.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 127 ++-
1 file changed, 66 insertions(+), 61
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/scheduler/sched_main.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index 90d7a82..ec7faca 100644
---
On Mon, May 06, 2019 at 06:31:03PM +0200, Andrey Konovalov wrote:
> This patch is a part of a series that extends arm64 kernel ABI to allow to
> pass tagged user pointers (with the top byte set to something else other
> than 0x00) as syscall arguments.
>
> This patch adds a simple test, that
Can you explain how this avoids OOM situations? When is it safe to leave
a reserved BO on the LRU list? Could we do the same thing in
amdgpu_amdkfd_gpuvm.c? And if we did, what would be the expected side
effects or consequences?
Thanks,
Felix
On 2019-05-22 8:59 a.m., Christian König wrote:
On Wed, May 22, 2019 at 05:35:27PM +0100, Catalin Marinas wrote:
> The two hard requirements I have for supporting any new hardware feature
> in Linux are (1) a single kernel image binary continues to run on old
> hardware while making use of the new feature if available and (2) old
> user space
On Wed, May 22, 2019 at 1:47 PM Kees Cook wrote:
>
> On Wed, May 22, 2019 at 05:35:27PM +0100, Catalin Marinas wrote:
> > The two hard requirements I have for supporting any new hardware feature
> > in Linux are (1) a single kernel image binary continues to run on old
> > hardware while making
On Wed, May 22, 2019 at 4:03 PM Evgenii Stepanov wrote:
>
> On Wed, May 22, 2019 at 1:47 PM Kees Cook wrote:
> >
> > On Wed, May 22, 2019 at 05:35:27PM +0100, Catalin Marinas wrote:
> > > The two hard requirements I have for supporting any new hardware feature
> > > in Linux are (1) a single
On Wed, May 22, 2019 at 02:49:28PM +0100, Dave Martin wrote:
> On Tue, May 21, 2019 at 03:48:56PM -0300, Jason Gunthorpe wrote:
> > On Fri, May 17, 2019 at 03:49:31PM +0100, Catalin Marinas wrote:
> >
> > > The tagged pointers (whether hwasan or MTE) should ideally be a
> > > transparent feature
On Wed, May 22, 2019 at 1:39 PM Alex Deucher wrote:
>
> On Tue, May 21, 2019 at 1:46 PM Micah Morton wrote:
> >
> > On Fri, May 17, 2019 at 9:59 AM Alex Deucher wrote:
> > >
> > > On Fri, May 17, 2019 at 11:36 AM Micah Morton
> > > wrote:
> > > >
> > > > On Thu, May 16, 2019 at 1:39 PM Alex
On 5/22/19 11:11 AM, Nicholas Kazlauskas wrote:
> [CAUTION: External Email]
>
> [Why]
> The custom "max bpc" property was added to limit color depth while the
> DRM one was still being merged. It's been a few kernel versions since
> then and this TODO was still sticking around.
>
> [How]
>
On Wed, May 22, 2019 at 08:30:21AM -0700, enh wrote:
> On Wed, May 22, 2019 at 3:11 AM Catalin Marinas
> wrote:
> > On Tue, May 21, 2019 at 05:04:39PM -0700, Kees Cook wrote:
> > > I just want to make sure I fully understand your concern about this
> > > being an ABI break, and I work best with
On device initialization, KFD allocates all (64) gws which
is shared by all KFD processes.
Change-Id: I1f1274b8d4f6a8ad08785e2791a9a79def75e913
Signed-off-by: Oak Zeng
Reviewed-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdkfd/kfd_device.c | 14 +-
GWS bo is shared between all kfd processes. Add function to add gws
to kfd process's bo list so gws can be evicted from and restored
for process.
Change-Id: I75d74cfdadb7075ff8b2b68634e205deb73dc1ea
Signed-off-by: Oak Zeng
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h | 2 +
Add a new kfd ioctl to allocate queue GWS. Queue
GWS is released on queue destroy.
Change-Id: I60153c26a577992ad873e4292e759e5c3d5bbd15
Signed-off-by: Oak Zeng
---
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 39
include/uapi/linux/kfd_ioctl.h | 20
Add a field in map_queues packet to indicate whether
this is a gws control queue. Only one queue per process
can be gws control queue. Change num_gws field in
map_process packet to 7 bits
Change-Id: I0db91d99c6962d14f9202b2eb950f8e7e497b79e
Signed-off-by: Oak Zeng
Reviewed-by: Felix Kuehling
Add functions in process queue manager to
set/get queue gws. Also set process's number
of gws used. Currently only one queue in
process can use and use all gws.
Change-Id: I03e480c8692db3eabfc3a188cce8904d5d962ab7
Signed-off-by: Oak Zeng
---
drivers/gpu/drm/amd/amdkfd/kfd_priv.h |
Add amdgpu_amdkfd interface to alloc and free gws
from amdgpu
Change-Id: I4eb418356e5a6051aa09c5e2c4a454263631d6ab
Signed-off-by: Oak Zeng
Reviewed-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 34 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
Add amdgpu_amdkfd interface to get num_gws and add num_gws
to /sys/class/kfd/kfd/topology/nodes/x/properties. Only report
num_gws if MEC FW support GWS barriers. Currently it is
determined by a module parameter which will be replaced
with MEC FW version check when firmware is ready.
Change-Id:
[Why]
The current state on the connector is queried when getting the max bpc
rather than the new state. This means that a new max bpc value can only
currently take effect on the commit *after* it changes.
The new state should be passed in instead.
[How]
Pass down the dm_state as drm state to
Hi Christian,
On Sat, 27 Apr 2019 at 05:31, Liam Mark wrote:
>
> On Tue, 16 Apr 2019, Christian König wrote:
>
> > To allow a smooth transition from pinning buffer objects to dynamic
> > invalidation we first start to cache the sg_table for an attachment
> > unless the driver explicitly says to
On 2019-05-22 12:00 p.m., Nicholas Kazlauskas wrote:
> [CAUTION: External Email]
>
> [Why]
> The current state on the connector is queried when getting the max bpc
> rather than the new state. This means that a new max bpc value can only
> currently take effect on the commit *after* it changes.
>
[Why]
The custom "max bpc" property was added to limit color depth while the
DRM one was still being merged. It's been a few kernel versions since
then and this TODO was still sticking around.
[How]
Attach the DRM max bpc property to the connector and drop all of our
custom property management.
On Wed, May 22, 2019 at 9:35 AM Catalin Marinas wrote:
>
> On Wed, May 22, 2019 at 08:30:21AM -0700, enh wrote:
> > On Wed, May 22, 2019 at 3:11 AM Catalin Marinas
> > wrote:
> > > On Tue, May 21, 2019 at 05:04:39PM -0700, Kees Cook wrote:
> > > > I just want to make sure I fully understand
Series is
Reviewed-by: Harry Wentland
Harry
On 2019-05-22 11:11 a.m., Nicholas Kazlauskas wrote:
> [CAUTION: External Email]
>
> [Why]
> The current state on the connector is queried when getting the max bpc
> rather than the new state. This means that a new max bpc value can only
> currently
Am 22.05.19 um 18:17 schrieb Sumit Semwal:
Hi Christian,
On Sat, 27 Apr 2019 at 05:31, Liam Mark wrote:
On Tue, 16 Apr 2019, Christian König wrote:
To allow a smooth transition from pinning buffer objects to dynamic
invalidation we first start to cache the sg_table for an attachment
unless
On Wed, May 22, 2019 at 11:27 PM Emily Deng wrote:
>
Please include a patch description.
> Signed-off-by: Emily Deng
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 10 +-
> drivers/gpu/drm/amd/include/kgd_pp_interface.h | 1 +
>
I would actually expect the followings
if (!amdgpu_sriov_vf(adev) && amdgpu_asic_need_reset_on_init(adev)) {
--> no touch for this
+if (amdgpu_passthrough(adev) && adev->powerplay.pp_funcs &&
adev->powerplay.pp_funcs->set_asic_baco_cap) {
+ r =
On Wed, May 22, 2019 at 11:48 PM Alex Deucher wrote:
>
> On Wed, May 22, 2019 at 11:27 PM Emily Deng wrote:
> >
>
> Please include a patch description.
>
> > Signed-off-by: Emily Deng
> > ---
> > drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 10 +-
> >
Hi Evan,
If don’t call set_asic_baco_cap， then couldn't enable baco, so need to
modify amdgpu_sriov_vf to limit to passthrough. And the comment is in the
patch, but don't know why it lost when using " git send-email".
And as you gave the reviewed-by, I already pushed the patch to the
Sorry, I have pushed the change as Evan gave the reviewed-by, I will send
another patch to reference your review comments, do you think it is Ok?
>-Original Message-
>From: Alex Deucher
>Sent: Thursday, May 23, 2019 11:54 AM
>To: Deng, Emily
>Cc: amd-gfx list
>Subject: Re: [PATCH v2]
Signed-off-by: Emily Deng
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 10 +-
drivers/gpu/drm/amd/include/kgd_pp_interface.h | 1 +
drivers/gpu/drm/amd/powerplay/amd_powerplay.c | 16
drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 1 +
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hello team,
Thank for you making mobile Raven Ridge nearly fully functional with the
open source driver for multiple devices like HP Envy x360 Ryzen 2500u.
However, missing is the ability to auto-rotate the screen when switching
from landscape to
With this limited to passthough case only, this patch is reviewed-by: Evan Quan
Regards,
Evan
> -Original Message-
> From: amd-gfx On Behalf Of
> Emily Deng
> Sent: Wednesday, May 22, 2019 6:07 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Deng, Emily
> Subject: [PATCH] drm/amdgpu:
On Wed, May 22, 2019 at 7:00 PM Micah Morton wrote:
>
> On Wed, May 22, 2019 at 1:39 PM Alex Deucher wrote:
> >
> > On Tue, May 21, 2019 at 1:46 PM Micah Morton wrote:
> > >
> > > On Fri, May 17, 2019 at 9:59 AM Alex Deucher
> > > wrote:
> > > >
> > > > On Fri, May 17, 2019 at 11:36 AM Micah
On Tue, May 21, 2019 at 1:46 PM Micah Morton wrote:
>
> On Fri, May 17, 2019 at 9:59 AM Alex Deucher wrote:
> >
> > On Fri, May 17, 2019 at 11:36 AM Micah Morton wrote:
> > >
> > > On Thu, May 16, 2019 at 1:39 PM Alex Deucher
> > > wrote:
> > > >
> > > > On Thu, May 16, 2019 at 4:07 PM Micah
On 2019-05-22 11:51 a.m., Zeng, Oak wrote:
> Add functions in process queue manager to
> set/get queue gws. Also set process's number
> of gws used. Currently only one queue in
> process can use and use all gws.
>
> Change-Id: I03e480c8692db3eabfc3a188cce8904d5d962ab7
> Signed-off-by: Oak Zeng
>
On Wed, May 22, 2019 at 7:28 PM Christian König
wrote:
>
> Am 22.05.19 um 18:17 schrieb Sumit Semwal:
> > Hi Christian,
> >
> > On Sat, 27 Apr 2019 at 05:31, Liam Mark wrote:
> >> On Tue, 16 Apr 2019, Christian König wrote:
> >>
> >>> To allow a smooth transition from pinning buffer objects to
On Wed, May 22, 2019 at 08:30:21AM -0700, enh wrote:
> On Wed, May 22, 2019 at 3:11 AM Catalin Marinas
> wrote:
> > On Tue, May 21, 2019 at 05:04:39PM -0700, Kees Cook wrote:
> > > I just want to make sure I fully understand your concern about this
> > > being an ABI break, and I work best with
Hi Dave, Daniel,
Fixes for 5.2:
- Fix for DMCU firmware issues for stable
- Add missing polaris10 pci id to kfd
- Screen corruption fix on picasso
- Fix for driver reload on vega10
- SR-IOV fixes
- Locking fix in new SMU code
- Compute profile switching fix for KFD
The following changes since
On Wed, May 22, 2019 at 4:49 AM Catalin Marinas wrote:
>
> On Mon, May 06, 2019 at 06:30:51PM +0200, Andrey Konovalov wrote:
> > This patch is a part of a series that extends arm64 kernel ABI to allow to
> > pass tagged user pointers (with the top byte set to something else other
> > than 0x00)
On Wed, May 22, 2019 at 12:21 PM Kees Cook wrote:
>
> On Wed, May 22, 2019 at 08:30:21AM -0700, enh wrote:
> > On Wed, May 22, 2019 at 3:11 AM Catalin Marinas
> > wrote:
> > > On Tue, May 21, 2019 at 05:04:39PM -0700, Kees Cook wrote:
> > > > I just want to make sure I fully understand your
On 2019-05-22 11:51 a.m., Zeng, Oak wrote:
> GWS bo is shared between all kfd processes. Add function to add gws
> to kfd process's bo list so gws can be evicted from and restored
> for process.
>
> Change-Id: I75d74cfdadb7075ff8b2b68634e205deb73dc1ea
> Signed-off-by: Oak Zeng
Reviewed-by: Felix
On 2019-05-22 11:51 a.m., Zeng, Oak wrote:
> Add a new kfd ioctl to allocate queue GWS. Queue
> GWS is released on queue destroy.
>
> Change-Id: I60153c26a577992ad873e4292e759e5c3d5bbd15
> Signed-off-by: Oak Zeng
> ---
> drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 39
>
66 matches
Mail list logo
