Cleanup code related to vm pasid by adding helper functions.
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 105 -
1 file changed, 50 insertions(+), 55 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
b/drivers/gpu/drm/amd/amdgpu/
On Fri, 18 Jun 2021 11:11:05 +0200
Werner Sembach wrote:
> Add a new general drm property "active color format" which can be used by
> graphic drivers to report the used color format back to userspace.
>
> There was no way to check which color format got actually used on a given
> monitor. To su
On Fri, 18 Jun 2021 11:11:02 +0200
Werner Sembach wrote:
> 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
Am 22.06.21 um 01:29 schrieb Jason Gunthorpe:
On Mon, Jun 21, 2021 at 10:24:16PM +0300, Oded Gabbay wrote:
Another thing I want to emphasize is that we are doing p2p only
through the export/import of the FD. We do *not* allow the user to
mmap the dma-buf as we do not support direct IO. So there
[AMD Official Use Only]
Thanks Lijo.
However, I'm not quite sure whether " 0x << (4 * max_wgp_per_sh);" is a
valid expression since it kind of triggers some overflow.
Can that work for non-x86 platform or even work reliably for x86 platform?
BR
Evan
> -Original Message-
> From: L
[Public]
AFAIK, that expression is legal (some code analyzer may warn on value of
4*max_wgp_per_sh); similar kind is used in rotate shift operations.
Thanks,
Lijo
-Original Message-
From: Quan, Evan
Sent: Tuesday, June 22, 2021 7:56 AM
To: Lazar, Lijo ; amd-gfx@lists.freedesktop.org
C
[Public]
>From: Liu, Zhan
>Sent: Monday, June 21, 2021 9:13 PM
>To: amd-gfx@lists.freedesktop.org ; Cornij,
>Nikola
>Cc: Liu, Charlene
>Subject: [PATCH] drm/amd/display: Enabling eDP no power sequencing with DAL
>feature mask
>
>[Public]
>
>[Why]
>Sometimes, DP receiver chip power-controlle
[Public]
[Why]
Sometimes, DP receiver chip power-controlled externally by an
Embedded Controller could be treated and used as eDP,
if it drives mobile display. In this case,
we shouldn't be doing power-sequencing, hence we can skip
waiting for T7-ready and T9-ready."
[How]
Added a feature mask to
On 2021-06-21 12:04 p.m., Alex Sierra wrote:
Keep track of all the pages inside of pranges referenced to
the same svm_bo.
This description is a bit confusing because you're not tracking page
references but BO references.
This is done, by using the ref count inside this object.
This makes
Hi Dave, Daniel,
Last minute fixes for 5.13.
The following changes since commit 13311e74253fe64329390df80bed3f07314ddd61:
Linux 5.13-rc7 (2021-06-20 15:03:15 -0700)
are available in the Git repository at:
https://gitlab.freedesktop.org/agd5f/linux.git
tags/amd-drm-fixes-5.13-2021-06-21
f
On Mon, Jun 21, 2021 at 10:24:16PM +0300, Oded Gabbay wrote:
> Another thing I want to emphasize is that we are doing p2p only
> through the export/import of the FD. We do *not* allow the user to
> mmap the dma-buf as we do not support direct IO. So there is no access
> to these pages through the
On 2021-06-21 4:58 p.m., Alex Deucher wrote:
No need for a separate flag now that DCN3.1 is not in bring up.
Fold into DRM_AMD_DC_DCN like previous DCN IPs.
Signed-off-by: Alex Deucher
Reviewed-by: Nicholas Kazlauskas
Regards,
Nicholas Kazlauskas
---
drivers/gpu/drm/amd/display/Kconfig
On 2021-06-21 12:04 p.m., Alex Sierra wrote:
This is for debug purposes only.
It conditionally generates partial migrations to test mixed
CPU/GPU memory domain pages in a prange easily.
Signed-off-by: Alex Sierra
Reviewed-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdkfd/kfd_migrate.c |
On 2021-06-21 12:04 p.m., Alex Sierra wrote:
Migration skipped for pages that are already in VRAM
domain. These could be the result of previous partial
migrations to SYS RAM, and prefetch back to VRAM.
Ex. Coherent pages in VRAM that were not written/invalidated after
a copy-on-write.
Signed-off
No need for a separate flag now that DCN3.1 is not in bring up.
Fold into DRM_AMD_DC_DCN like previous DCN IPs.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/display/Kconfig | 7 --
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 22 +--
.../amd/display/amdgp
On 2021-06-21 12:04 p.m., Alex Sierra wrote:
[Why]
svm ranges can have mixed pages from device or system memory.
A good example is, after a prange has been allocated in VRAM and a
copy-on-write is triggered by a fork. This invalidates some pages
inside the prange. Endding up in mixed pages.
[How
On 2021-06-21 12:04 p.m., Alex Sierra wrote:
Get the proper owner reference for amdgpu_hmm_range_get_pages function.
This is useful for partial migrations. To avoid migrating back to
system memory, VRAM pages, that are accessible by all devices in the
same memory domain.
Ex. multiple devices in t
On 2021-06-21 12:04 p.m., Alex Sierra wrote:
The parameter is used in the dev_private_owner to decide if device
pages in the range require to be migrated back to system memory, based
if they are or not in the same memory domain.
In this case, this reference could come from the same memory domain
On 2021-06-21 12:04 p.m., Alex Sierra wrote:
pgmap owner member at the svm migrate init could be referenced
to either adev or hive, depending on device topology.
The reasoning for this change is, that GPUs in the same XGMI hive have
direct access to all members' VRAM. When mapping memory to a
Flag peers as a direct link if over PCIe or over xGMI if they are adjacent
in the hive.
Signed-off-by: Jonathan Kim
---
drivers/gpu/drm/amd/amdkfd/kfd_crat.h | 3 ++-
drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 11 +++
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/d
Similar to xGMI reporting the min/max bandwidth as the number of links
between peers, PCIe will report the min/max bandwidth as the number of
supported lanes.
Signed-off-by: Jonathan Kim
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 24 ++
drivers/gpu/drm/amd/amdgpu/amdgpu
The TA can now be invoked to provide the number of xgmi links connecting
a direct source and destination peer.
Non-direct peers will report zero links.
Signed-off-by: Jonathan Kim
---
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 23 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.h |
Since Min/Max bandwidth was never used, it will repurposed to report the
number of xgmi links between direct peers to the KFD topology.
Signed-off-by: Jonathan Kim
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 15 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h | 1 +
drivers/gpu/
On 2021-06-21 12:04 p.m., Alex Sierra wrote:
actual_loc should not be used anymore, as pranges
could have mixed locations (VRAM & SYSRAM) at the
same time.
Signed-off-by: Alex Sierra
---
drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 12 +---
drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 71 +++
buff --> buf. Essentially buffer abbreviates to
buf, remove 1/2 of it, or just the iron part, as
opposed to just the Er,
Cc: Alexander Deucher
Cc: Andrey Grodzovsky
Signed-off-by: Luben Tuikov
Reviewed-by: Alexander Deucher
---
.../gpu/drm/amd/amdgpu/amdgpu_ras_eeprom.c| 98 +-
Qualify with "ras_". Use kernel's own--don't
redefine your own.
Cc: Alexander Deucher
Cc: Andrey Grodzovsky
Signed-off-by: Luben Tuikov
Reviewed-by: Alexander Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 16 +-
.../gpu/drm/amd/amdgpu/amdgpu_ras_eeprom.c| 30
The code is now tested from userspace.
Remove already macroed out test function.
Cc: Alexander Deucher
Cc: Andrey Grodzovsky
Signed-off-by: Luben Tuikov
Reviewed-by: Alexander Deucher
---
.../gpu/drm/amd/amdgpu/amdgpu_ras_eeprom.c| 33 ---
.../gpu/drm/amd/amdgpu/amdgpu_ras
In smu_v11_0_i2c_transmit() use a single loop to
transmit bytes, instead of two nested loops.
Cc: Alexander Deucher
Cc: Andrey Grodzovsky
Signed-off-by: Luben Tuikov
Reviewed-by: Alexander Deucher
---
drivers/gpu/drm/amd/amdgpu/smu_v11_0_i2c.c | 72 ++
1 file changed, 34 i
The low level EEPROM write method, doesn't return
1, but the number of bytes written. Thus do not
compare to 1, instead, compare to greater than 0
for success.
Other cleanup: if the lower layers returned
-errno, then return that, as opposed to
overwriting the error code with one-fits-all
-EINVAL.
On long transfers to the EEPROM device,
i.e. write, it is observed that the driver aborts
the transfer.
The reason for this is that the driver isn't
patient enough--the IC_STATUS register's contents
is 0x27, which is MST_ACTIVITY | TFE | TFNF |
ACTIVITY. That is, while the transmission FIFO is
emp
Rename update_table_header() to
write_table_header() as this function is actually
writing it to EEPROM.
Use kernel types; use u8 to carry around the
checksum, in order to take advantage of arithmetic
modulo 8-bits (256).
Tidy up to 80 columns.
When updating the checksum, just recalculate the
who
Add "ras_eeprom_size" file in debugfs, which
reports the maximum size allocated to the RAS
table in EEROM, as the number of bytes and the
number of records it could store. For instance,
$cat /sys/kernel/debug/dri/0/ras/ras_eeprom_size
262144 bytes or 10921 records
$_
Add "ras_eeprom_table" file i
Split functionality between read and write, which
simplifies the code and exposes areas of
optimization and more or less complexity, and take
advantage of that.
Read and write the table in one go; use a separate
stage to decode or encode the data, as opposed to
on the fly, which keeps the I2C bus
RAS_MAX_RECORD_NUM may mean the maximum record
number, as in the maximum house number on your
street, or it may mean the maximum number of
records, as in the count of records, which is also
a number. To make this distinction whether the
number is ordinal (index) or cardinal (count),
rename this mac
Debugfs RAS EEPROM files are available when
the ASIC supports RAS, and when the debugfs is
enabled, an also when "ras_enable" module
parameter is set to 0. However in this case,
we get a kernel oops when accessing some of
the "ras_..." controls in debugfs. The reason
for this is that struct amdgpu_
The I2C address is kept as a 16-bit quantity in
the kernel. The I2C_TAR::I2C_TAR field is 10-bit
wide.
Fix the width of the I2C address for Vega20 from 8
bits to 16 bits to accommodate the full spectrum
of I2C address space.
Cc: Jean Delvare
Cc: Alexander Deucher
Cc: Andrey Grodzovsky
Cc: Lijo
No need to account for the 2 bytes of EEPROM
address--this is now well abstracted away by
the fixes the the lower layers.
Cc: Andrey Grodzovsky
Cc: Alexander Deucher
Signed-off-by: Luben Tuikov
Acked-by: Alexander Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ras_eeprom.c | 2 +-
1 file chang
Now that we have an I2C quirk table for
SMU-managed I2C controllers, the I2C core does the
checks for us, so we don't need to do them, and so
simplify the managed I2C transfer functions.
Also, for Arcturus and Navi10, fix setting the
command type from "cmd->CmdConfig" to "cmd->Cmd".
The latter is
From: Alex Deucher
Not sure that this really matters that much, but these could
have various other hwmon chips on them.
Signed-off-by: Alex Deucher
Reviewed-by: Luben Tuikov
---
drivers/gpu/drm/amd/amdgpu/smu_v11_0_i2c.c | 2 +-
drivers/gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c
* When reading from the EEPROM device, there is no
device limitation on the number of bytes
read--they're simply sequenced out. Thus, read
the whole data requested in one go.
* When writing to the EEPROM device, there is a
256-byte page limit to write to before having to
generate a STOP
From: Andrey Grodzovsky
Let's just ignore the I2C_M_STOP hint from upper
layer for SMU I2C code as there is no clean
mapping between single per I2C message STOP flag
at the kernel I2C layer and the SMU, per each byte
STOP flag. We will just by default set it at the
end of the SMU I2C message.
Cc
Set the auto-discoverable class of I2C bus to
HWMON. Remove SPD.
Cc: Jean Delvare
Cc: Alexander Deucher
Cc: Andrey Grodzovsky
Cc: Lijo Lazar
Cc: Stanley Yang
Cc: Hawking Zhang
Signed-off-by: Luben Tuikov
Reviewed-by: Alexander Deucher
---
drivers/gpu/drm/amd/amdgpu/smu_v11_0_i2c.c
From: Alex Deucher
Convert from 8 bit to 7 bit.
Signed-off-by: Alex Deucher
Reviewed-by: Luben Tuikov
---
drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ras_eeprom.c | 10 +-
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/driv
From: Andrey Grodzovsky
Also generilize the code to accept and translate to
HW bits any I2C relvent flags both for read and write.
Cc: Jean Delvare
Cc: Alexander Deucher
Cc: Andrey Grodzovsky
Cc: Lijo Lazar
Cc: Stanley Yang
Cc: Hawking Zhang
Signed-off-by: Andrey Grodzovsky
Signed-off-by:
From: Alex Deucher
Use the new helper rather than doing i2c transfers directly.
Signed-off-by: Alex Deucher
Reviewed-by: Luben Tuikov
---
.../gpu/drm/amd/amdgpu/amdgpu_ras_eeprom.c| 86 ++-
1 file changed, 28 insertions(+), 58 deletions(-)
diff --git a/drivers/gpu/drm/amd
Teach Vega20 I2C to be agnostic. Allow addressing
different devices while the master holds the bus.
Set STOP as per the controller's specification.
v2: Qualify generating ReSTART before the 1st byte
of the message, when set by the caller, as
those functions are separated, as caught by
Convert RAS and FRU code to use the 19-bit I2C
memory address and remove all "slave_addr", as
this is now absolved into the 19-bit address.
Cc: Jean Delvare
Cc: John Clements
Cc: Alexander Deucher
Cc: Andrey Grodzovsky
Cc: Lijo Lazar
Cc: Stanley Yang
Cc: Hawking Zhang
Signed-off-by: Luben T
From: Alex Deucher
Make it generic so we can support more than just EEPROMs.
v2: fix restart handling between transactions.
v3: handle 7 to 8 bit addr conversion
v4: Fix &req --> req. (Luben T)
Signed-off-by: Alex Deucher
Signed-off-by: Luben Tuikov
Reviewed-by: Luben Tuikov
---
.../gpu/drm
Extend the I2C quirk table for SMU access
controlled I2C adapters. Let the kernel I2C layer
check that the messages all have the same address,
and that their combined size doesn't exceed the
maximum size of a SMU software I2C request.
Suggested-by: Jean Delvare
Cc: Jean Delvare
Cc: Alexander Deu
From: Alex Deucher
Make it generic so we can support more than just EEPROMs.
v2: fix restart handling between transactions.
v3: handle 7 to 8 bit addr conversion
v4: Fix &req --> req. (Luben T)
Signed-off-by: Alex Deucher
Signed-off-by: Luben Tuikov
Reviewed-by: Luben Tuikov
---
.../amd/pm/
I2C fixes from various people. Some RAS touch-ups too.
A rebased tree can also be found here:
https://gitlab.freedesktop.org/ltuikov/linux/-/commits/i2c-rework-luben
Tested on Vega20 and Sienna Cichlid.
This first revision includes acks, squashes patch 33 by absolving it
into earlier commits it
From: Andrey Grodzovsky
EEPROM spec requests this.
v2: Only to be done for write data transactions.
Signed-off-by: Andrey Grodzovsky
Signed-off-by: Alex Deucher
Reviewed-by: Luben Tuikov
---
drivers/gpu/drm/amd/amdgpu/amdgpu_eeprom.c | 15 +++
1 file changed, 15 insertions(+)
d
Instead of fixing the spelling in
amdgpu_ras_eeprom_process_recods(),
rename it to,
amdgpu_ras_eeprom_xfer(),
to look similar to other I2C and protocol
transfer (read/write) functions.
Also to keep the column span to within reason by
using a shorter name.
Change the "num" function parameter f
From: Alex Deucher
And handle more than just EEPROMs.
v2: fix restart handling between transactions.
v3: handle 7 to 8 bit addr conversion
v4: Fix &req --> req. (Luben T)
Signed-off-by: Alex Deucher
Signed-off-by: Luben Tuikov
Reviewed-by: Luben Tuikov
---
.../gpu/drm/amd/pm/swsmu/smu11/nav
From: Andrey Grodzovsky
Drop i > 0 restriction for issuing RESTART.
Cc: Jean Delvare
Cc: Alexander Deucher
Cc: Andrey Grodzovsky
Cc: Lijo Lazar
Cc: Stanley Yang
Cc: Hawking Zhang
Signed-off-by: Andrey Grodzovsky
Signed-off-by: Luben Tuikov
Reviewed-by: Luben Tuikov
---
drivers/gpu/drm/
From: Alex Deucher
Not sure how the firmware interprets these.
Signed-off-by: Alex Deucher
Reviewed-by: Luben Tuikov
---
drivers/gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c | 2 +-
drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c | 2 +-
drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_ci
Wrap amdgpu_ras_eeprom_xfer(..., bool write),
into amdgpu_ras_eeprom_read() and
amdgpu_ras_eeprom_write(), as that makes reading
and understanding the code clearer.
Cc: Jean Delvare
Cc: Alexander Deucher
Cc: Andrey Grodzovsky
Cc: Lijo Lazar
Cc: Stanley Yang
Cc: Hawking Zhang
Signed-off-by: L
Add explicit amdgpu_eeprom_read() and
amdgpu_eeprom_write() for clarity.
Cc: Jean Delvare
Cc: Alexander Deucher
Cc: Andrey Grodzovsky
Cc: Lijo Lazar
Cc: Stanley Yang
Cc: Hawking Zhang
Signed-off-by: Luben Tuikov
Acked-by: Alexander Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_eeprom.h
From: Andrey Grodzovsky
To be used by kernel clients of the adapter.
Cc: Jean Delvare
Cc: Alexander Deucher
Cc: Andrey Grodzovsky
Cc: Lijo Lazar
Cc: Stanley Yang
Cc: Hawking Zhang
Signed-off-by: Andrey Grodzovsky
Suggested-by: Lazar Lijo
Signed-off-by: Luben Tuikov
Reviewed-by: Luben Tu
Consult the i2c_adapter.quirks table for
the maximum read/write data length per bus
transaction. Do not exceed this transaction
limit.
Cc: Jean Delvare
Cc: Alexander Deucher
Cc: Andrey Grodzovsky
Cc: Lijo Lazar
Cc: Stanley Yang
Cc: Hawking Zhang
Signed-off-by: Luben Tuikov
Acked-by: Alexand
* "eeprom_addr" is now 32-bit wide.
* Remove "slave_addr" from the I2C EEPROM driver
interface. The I2C EEPROM Device Type Identifier
is fixed at 1010b, and the rest of the bits
of the Device Address Byte/Device Select Code,
are memory address bits, where the first three
of those bits are
From: Alex Deucher
Encapsulates the i2c protocol handling so other parts of the
driver can just tell it the offset and size of data to write.
Signed-off-by: Alex Deucher
Reviewed-by: Luben Tuikov
---
drivers/gpu/drm/amd/amdgpu/Makefile| 3 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_eeprom.
In amdgpu_ras_eeprom.c--the interface from RAS to
EEPROM, rename macros from EEPROM to RAS, to
indicate that the quantities and objects are RAS
specific, not EEPROM. We can decrease the RAS
table, or put it in different offset of EEPROM as
needed in the future.
Remove EEPROM_ADDRESS_SIZE macro def
From: Andrey Grodzovsky
Fix from number of processed bytes to number of
processed I2C messages.
Cc: Jean Delvare
Cc: Alexander Deucher
Cc: Andrey Grodzovsky
Cc: Lijo Lazar
Cc: Stanley Yang
Cc: Hawking Zhang
Signed-off-by: Andrey Grodzovsky
Signed-off-by: Luben Tuikov
Reviewed-by: Luben T
From: Alex Deucher
Use the new helper rather than doing i2c transfers directly.
v2: fix typo
Signed-off-by: Alex Deucher
Reviewed-by: Luben Tuikov
---
.../gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c| 22 +--
1 file changed, 6 insertions(+), 16 deletions(-)
diff --git a/driver
Fix the size of the EEPROM from 256000 bytes
to 262144 bytes (256 KiB).
Fix a couple or wrap around bugs. If a valid
value/address is 0 <= addr < size, the inverse of
this inequality (barring negative values which
make no sense here) is addr >= size. Fix this in
the RAS code.
Cc: Jean Delvare
Cc
From: Aaron Rice
Handle things besides EEPROMS.
Signed-off-by: Aaron Rice
Signed-off-by: Alex Deucher
Reviewed-by: Luben Tuikov
---
drivers/gpu/drm/amd/amdgpu/smu_v11_0_i2c.c | 47 +-
1 file changed, 9 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgp
From: Alex Deucher
So we lock software as well as hardware access to the bus.
v2: fix mutex handling.
Signed-off-by: Alex Deucher
Reviewed-by: Luben Tuikov
---
drivers/gpu/drm/amd/amdgpu/smu_v11_0_i2c.c | 19 +--
drivers/gpu/drm/amd/pm/inc/amdgpu_dpm.h| 1 +
2 files chan
Pulls print functions for GPUVM page tables on AI+ chips into their
own set of generalized functions, so that we don't have subtly
different printouts for different layers.
Explicitly prints PDEs with P bit (which makes it a PTE) and makes
the PTE with F bit set (further, which makes it a PDE) pro
Keep track of all the pages inside of pranges referenced to
the same svm_bo. This is done, by using the ref count inside this object.
This makes sure the object has freed after the last prange is not longer
at any GPU. Including references shared between a parent and child during
a fork.
Signed-of
[Why]
svm ranges can have mixed pages from device or system memory.
A good example is, after a prange has been allocated in VRAM and a
copy-on-write is triggered by a fork. This invalidates some pages
inside the prange. Endding up in mixed pages.
[How]
By classifying each page inside a prange, bas
The parameter is used in the dev_private_owner to decide if device
pages in the range require to be migrated back to system memory, based
if they are or not in the same memory domain.
In this case, this reference could come from the same memory domain
with devices connected to the same hive.
Signe
Invalid pages can be the result of pages that have been migrated
already due to copy-on-write procedure or pages that were never
migrated to VRAM in first place. This is not an issue anymore,
as pranges now support mixed memory domains (CPU/GPU).
Signed-off-by: Alex Sierra
Reviewed-by: Felix Kueh
Migration skipped for pages that are already in VRAM
domain. These could be the result of previous partial
migrations to SYS RAM, and prefetch back to VRAM.
Ex. Coherent pages in VRAM that were not written/invalidated after
a copy-on-write.
Signed-off-by: Alex Sierra
---
drivers/gpu/drm/amd/amdk
svm_range_prefault is called right before migrations to VRAM,
to make sure pages are resident in system memory before the migration.
With partial migrations, this reference is used by hmm range get pages
to avoid migrating pages that are already in the same VRAM domain.
Signed-off-by: Alex Sierra
pgmap owner member at the svm migrate init could be referenced
to either adev or hive, depending on device topology.
Signed-off-by: Alex Sierra
---
drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 6 +++---
drivers/gpu/drm/amd/amdkfd/kfd_svm.h | 3 +++
2 files changed, 6 insertions(+), 3 deletions
actual_loc should not be used anymore, as pranges
could have mixed locations (VRAM & SYSRAM) at the
same time.
Signed-off-by: Alex Sierra
---
drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 12 +---
drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 71 ++--
2 files changed, 29 insertions
This is for debug purposes only.
It conditionally generates partial migrations to test mixed
CPU/GPU memory domain pages in a prange easily.
Signed-off-by: Alex Sierra
---
drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/gpu/drm
Get the proper owner reference for amdgpu_hmm_range_get_pages function.
This is useful for partial migrations. To avoid migrating back to
system memory, VRAM pages, that are accessible by all devices in the
same memory domain.
Ex. multiple devices in the same hive.
Signed-off-by: Alex Sierra
---
On 2021-06-21 12:04 p.m., Alex Sierra wrote:
svm_range_prefault is called right before migrations to VRAM,
to make sure pages are resident in system memory before the migration.
With partial migrations, this reference is used by hmm range get pages
to avoid migrating pages that are already in the
[Public]
I've dropped it from my tree in that case.
From: Christian König
Sent: Monday, June 21, 2021 6:27 AM
To: Alex Deucher ; Kuehling, Felix
Cc: David Airlie ; Pan, Xinhui ;
kernel-janit...@vger.kernel.org ; Maling list
- DRI developers ; amd-gfx list
; D
On Mon, Jun 21, 2021 at 9:27 PM Daniel Vetter wrote:
>
> On Mon, Jun 21, 2021 at 7:55 PM Jason Gunthorpe wrote:
> > On Mon, Jun 21, 2021 at 07:26:14PM +0300, Oded Gabbay wrote:
> > > On Mon, Jun 21, 2021 at 5:12 PM Jason Gunthorpe wrote:
> > > >
> > > > On Mon, Jun 21, 2021 at 03:02:10PM +0200,
Applied. Thanks!
Alex
On Mon, Jun 21, 2021 at 9:15 AM Christian König
wrote:
>
> Am 21.06.21 um 15:05 schrieb Bernard Zhao:
> > Function radeon_fence_driver_init always returns success,
> > the function type maybe coule be changed to void.
> > This patch first delete the check of the return
> >
On 2021-06-18 3:07 p.m., Bindu Ramamurthy wrote:
> From: Logush Oliver
>
> [why]
> Updating the file to fix the missing line
>
> Signed-off-by: Logush Oliver
> Reviewed-by: Charlene Liu
> Acked-by: Bindu Ramamurthy
> ---
> drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c | 2 +-
> 1 fil
On Mon, Jun 21, 2021 at 7:55 PM Jason Gunthorpe wrote:
> On Mon, Jun 21, 2021 at 07:26:14PM +0300, Oded Gabbay wrote:
> > On Mon, Jun 21, 2021 at 5:12 PM Jason Gunthorpe wrote:
> > >
> > > On Mon, Jun 21, 2021 at 03:02:10PM +0200, Greg KH wrote:
> > > > On Mon, Jun 21, 2021 at 02:28:48PM +0200, D
On Mon, Jun 21, 2021 at 07:26:14PM +0300, Oded Gabbay wrote:
> On Mon, Jun 21, 2021 at 5:12 PM Jason Gunthorpe wrote:
> >
> > On Mon, Jun 21, 2021 at 03:02:10PM +0200, Greg KH wrote:
> > > On Mon, Jun 21, 2021 at 02:28:48PM +0200, Daniel Vetter wrote:
> >
> > > > Also I'm wondering which is the ot
On Mon, Jun 21, 2021 at 5:12 PM Jason Gunthorpe wrote:
>
> On Mon, Jun 21, 2021 at 03:02:10PM +0200, Greg KH wrote:
> > On Mon, Jun 21, 2021 at 02:28:48PM +0200, Daniel Vetter wrote:
>
> > > Also I'm wondering which is the other driver that we share buffers
> > > with. The gaudi stuff doesn't have
lied to the wrong git tree, kindly drop us a note.
> And when submitting patch, we suggest to use '--base' as documented in
> https://git-scm.com/docs/git-format-patch]
>
> url:
> https://github.com/0day-ci/linux/commits/Mikel-Rychliski/drm-radeon-Fix-NULL-derefere
One minor comment below, apart from that the series looks good.
Reviewed-by: Lijo Lazar
On 6/21/2021 12:30 PM, Evan Quan wrote:
Add missing settings for SQC bits. And correct some confusing logics
around active wgp bitmap calculation.
Change-Id: If4992e175fd61d5609b00328cbe21f487517d039
Signe
On Mon, Jun 21, 2021 at 5:49 PM Christian König
wrote:
>
> Am 21.06.21 um 16:54 schrieb Daniel Vetter:
> > On Mon, Jun 21, 2021 at 03:03:26PM +0200, Christian König wrote:
> >> We actually need to wait for the moving fence after pinning
> >> the BO to make sure that the pin is completed.
> >>
> >>
Am 21.06.21 um 16:54 schrieb Daniel Vetter:
On Mon, Jun 21, 2021 at 03:03:26PM +0200, Christian König wrote:
We actually need to wait for the moving fence after pinning
the BO to make sure that the pin is completed.
Signed-off-by: Christian König
CC: sta...@kernel.org
---
drivers/gpu/drm/nou
On 6/21/2021 1:35 PM, Christian König wrote:
Am 21.06.21 um 13:27 schrieb Das, Nirmoy:
On 6/21/2021 1:18 PM, Christian König wrote:
Am 21.06.21 um 13:10 schrieb Das, Nirmoy:
On 6/21/2021 12:59 PM, Christian König wrote:
Am 21.06.21 um 12:56 schrieb Das, Nirmoy:
On 6/21/2021 12:26 PM, Chr
Am 21.06.21 um 13:27 schrieb Das, Nirmoy:
On 6/21/2021 1:18 PM, Christian König wrote:
Am 21.06.21 um 13:10 schrieb Das, Nirmoy:
On 6/21/2021 12:59 PM, Christian König wrote:
Am 21.06.21 um 12:56 schrieb Das, Nirmoy:
On 6/21/2021 12:26 PM, Christian König wrote:
Well you completely break t
On 6/21/2021 1:18 PM, Christian König wrote:
Am 21.06.21 um 13:10 schrieb Das, Nirmoy:
On 6/21/2021 12:59 PM, Christian König wrote:
Am 21.06.21 um 12:56 schrieb Das, Nirmoy:
On 6/21/2021 12:26 PM, Christian König wrote:
Well you completely break the handling in amdgpu_vm_handle_fault()
wi
On Mon, Jun 21, 2021 at 04:20:35PM +0200, Daniel Vetter wrote:
> Also unless we're actually doing this properly there's zero incentive for
> me to review the kernel code and check whether it follows the rules
> correctly, so you have excellent chances that you just break the rules.
> And dma_buf/f
On 6/21/2021 12:59 PM, Christian König wrote:
Am 21.06.21 um 12:56 schrieb Das, Nirmoy:
On 6/21/2021 12:26 PM, Christian König wrote:
Well you completely break the handling in amdgpu_vm_handle_fault()
with this.
I see one issue with: if (!vm || (vm && vm->root.bo != root)) . I
will split
Am 21.06.21 um 12:56 schrieb Das, Nirmoy:
On 6/21/2021 12:26 PM, Christian König wrote:
Well you completely break the handling in amdgpu_vm_handle_fault()
with this.
I see one issue with: if (!vm || (vm && vm->root.bo != root)) . I
will split it and resend.
Am I missing something else ?
On 6/21/2021 12:26 PM, Christian König wrote:
Well you completely break the handling in amdgpu_vm_handle_fault()
with this.
I see one issue with: if (!vm || (vm && vm->root.bo != root)) . I will
split it and resend.
Am I missing something else ?
Regards,
Nirmoy
Christian.
Am 21.0
On Mon, Jun 21, 2021 at 03:03:28PM +0200, Christian König wrote:
> We actually need to wait for the moving fence after pinning
> the BO to make sure that the pin is completed.
>
> Signed-off-by: Christian König
> CC: sta...@kernel.org
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 14
On Mon, Jun 21, 2021 at 03:03:27PM +0200, Christian König wrote:
> We actually need to wait for the moving fence after pinning
> the BO to make sure that the pin is completed.
>
> Signed-off-by: Christian König
> CC: sta...@kernel.org
> ---
> drivers/gpu/drm/radeon/radeon_prime.c | 16 ++
1 - 100 of 136 matches
Mail list logo
