When some GPUs don't support SVM, don't disabe it for the entire process.
That would be inconsistent with the information the process got from the
topology, which indicates SVM support per GPU.
Instead disable SVM support only for the unsupported GPUs. This is done
by checking any per-device
On 2021-06-10 5:12 p.m., Alex Deucher wrote:
> On Tue, Jun 8, 2021 at 5:41 PM Luben Tuikov wrote:
>> "req" is now a pointer , i.e. it is no longer
>> allocated on the stack, thus taking its reference
>> and passing that is a bug.
>>
>> This commit fixes this bug.
>>
>> Cc: Alex Deucher
>>
On 2021-06-07 10:53 a.m., Mark Yacoub wrote:
> On Fri, Jun 4, 2021 at 4:17 PM Harry Wentland wrote:
>>
>>
>>
>> On 2021-06-04 1:01 p.m., Mark Yacoub wrote:
>>> From: Mark Yacoub
>>>
>>> For each CRTC state, check the size of Gamma and Degamma LUTs so
>>> unexpected and larger sizes wouldn't
On 2021-06-10 3:00 p.m., Eric Huang wrote:
It is to fix a failure for SDMA updating PTEs.
Signed-off-by: Eric Huang
Reviewed-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 26 +---
1 file changed, 23 insertions(+), 3 deletions(-)
diff --git
It is to fix a failure for SDMA updating PTEs.
Signed-off-by: Eric Huang
---
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 26 +---
1 file changed, 23 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
On Tue, Jun 8, 2021 at 5:41 PM Luben Tuikov wrote:
>
> 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: Alex Deucher
> ---
>
Page table entries are now in embedded in VM BO, so
we do not need struct amdgpu_vm_pt. This patch replaces
struct amdgpu_vm_pt with struct amdgpu_vm_bo_base.
Signed-off-by: Nirmoy Das
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 26 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c|
On Tue, Jun 8, 2021 at 5:41 PM Luben Tuikov wrote:
>
> 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
On Tue, Jun 8, 2021 at 5:41 PM Luben Tuikov wrote:
>
> 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
On Tue, Jun 8, 2021 at 5:41 PM Luben Tuikov wrote:
>
> 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: Alex Deucher
> ---
>
On Tue, Jun 8, 2021 at 5:41 PM Luben Tuikov wrote:
>
> "req" is now a pointer , i.e. it is no longer
> allocated on the stack, thus taking its reference
> and passing that is a bug.
>
> This commit fixes this bug.
>
> Cc: Alex Deucher
> Signed-off-by: Luben Tuikov
Can we just squash this into
On Tue, Jun 8, 2021 at 5:41 PM Luben Tuikov wrote:
>
> 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,
On Tue, Jun 8, 2021 at 5:41 PM Luben Tuikov wrote:
>
> 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.
>
>
On Tue, Jun 8, 2021 at 5:41 PM Luben Tuikov wrote:
>
> 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
On Tue, Jun 8, 2021 at 5:40 PM Luben Tuikov wrote:
>
> 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.
On Tue, Jun 8, 2021 at 5:40 PM Luben Tuikov wrote:
>
> 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
On Tue, Jun 8, 2021 at 5:40 PM Luben Tuikov wrote:
>
> 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
On Tue, Jun 8, 2021 at 5:40 PM Luben Tuikov wrote:
>
> 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
On Tue, Jun 8, 2021 at 5:40 PM Luben Tuikov wrote:
>
> 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
On Tue, Jun 8, 2021 at 5:40 PM Luben Tuikov wrote:
>
> 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:
On Tue, Jun 8, 2021 at 5:40 PM Luben Tuikov wrote:
>
> 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
On Tue, Jun 8, 2021 at 5:40 PM Luben Tuikov wrote:
>
> 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:
On Tue, Jun 8, 2021 at 5:40 PM Luben Tuikov wrote:
>
> * "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,
>
On Tue, Jun 8, 2021 at 5:40 PM Luben Tuikov wrote:
>
> * 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
>
On Tue, Jun 8, 2021 at 5:40 PM Luben Tuikov wrote:
>
> 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
From: Wesley Chalmers
[WHY]
7 is the minimum number of retries TX must attempt on an AUX DEFER, not
the maximum.
Signed-off-by: Wesley Chalmers
Reviewed-by: Jun Lei
Acked-by: Anson Jacob
---
drivers/gpu/drm/amd/display/dc/dce/dce_aux.c | 6 +++---
1 file changed, 3 insertions(+), 3
From: Wesley Chalmers
[WHY]
Hardware has handed down a new sequence requiring the value of this
register be read from clk_mgr.
Signed-off-by: Wesley Chalmers
Reviewed-by: Dmytro Laktyushkin
Acked-by: Anson Jacob
---
.../display/dc/dcn10/dcn10_stream_encoder.h | 24 +++
From: Wesley Chalmers
[WHY]
SCR for DP 2.0 Spec states that a DPTX shall put LTTPRs into Transparent
mode after reading LTTPR Capability registers on HPD.
The wording of the SCR is somewhat ambiguous as to whether
Transparent mode must be set explicity, or is implicitly set on LTTPR
capability
From: Wesley Chalmers
[WHY]
DP specifies that an LTTPR device is only present if PHY_REPEATER_CNT is
0x80, 0x40, 0x20, 0x10, 0x08, 0x04, 0x02, or 0x01.
All other values should be considered no LTTPRs present.
[HOW]
Function dp_convert_to_count already does this check. Use it to determine
if
From: Josip Pavic
[Why & How]
Tune backlight ramping profiles for each Vari-Bright level to suit
customer preferences
Signed-off-by: Josip Pavic
Reviewed-by: Anthony Koo
Acked-by: Anson Jacob
---
.../amd/display/modules/power/power_helpers.c | 20 +--
1 file changed, 10
From: Wesley Chalmers
[WHY]
When changing the DISPCLK_WDIVIDER value from 126 to 127, the change in
clock rate is too great for the FIFOs to handle. This can cause visible
corruption during clock change.
HW has handed down this register sequence to fix the issue.
[HOW]
The sequence, from HW:
From: Wesley Chalmers
[WHY]
SCR for DP 2.0 spec says that multiple LTTPRs must not be accessed in a
single AUX transaction.
There may be other places in future where breaking up AUX accesses is
necessary.
[HOW]
Partition the entire DPCD address space into blocks. When an incoming AUX
request
From: Wesley Chalmers
[WHY]
DP 2.0 SCR specifies that TX devices must retry at least 7 times when
receiving an AUX DEFER reply from RX. In addition, the specification
states that the TX shall not retry indefinitely, and gives a suggestive
timeout interval of 50ms.
[HOW]
Keep retrying until both
From: Wesley Chalmers
[WHY]
Some DPCD addresses, notably LTTPR Capability registers, are expected to
be read all together in a single DPCD transaction. Rather than force callers to
read registers they don't need, we want to quietly extend the addresses
read, and only return back the values the
From: Wesley Chalmers
[WHY]
DP LL Compliance tests require that the first DPCD transactions after a
hotplug have a timeout interval of 3.2 ms. In cases where LTTPR is
disabled, this means that the first reads from DP_SET_POWER and DP_DPCD_REV
must have an extended
timeout.
Signed-off-by:
From: Wesley Chalmers
[WHY]
A new SCR for the DP2.0 spec requires that LTTPR caps be the first thing
read from DPCD upon hotplug.
Signed-off-by: Wesley Chalmers
Reviewed-by: Jun Lei
Acked-by: Anson Jacob
---
.../gpu/drm/amd/display/dc/core/dc_link_dp.c | 65 ++-
1 file
From: Yi-Ling Chen
[Why]
Some custom platforms use eDP hotplug events to notify panel
capability changes that should be reported
[How]
Add a DC config option that unblocks eDP hotplug events
Signed-off-by: Yi-Ling Chen
Reviewed-by: Aric Cyr
Acked-by: Anson Jacob
---
From: Roman Li
[Why]
Improve the maintain/read abilities of dm code.
[How]
Create amdgpu_dm_psr.c/h files.
Move psr function from amdgpu_dm.c
Signed-off-by: Roman Li
Reviewed-by: Nicholas Kazlauskas
Acked-by: Anson Jacob
---
.../gpu/drm/amd/display/amdgpu_dm/Makefile| 2 +-
From: Wesley Chalmers
[WHY]
We want LTTPR capabilities to be readable from more places than just
retrieve_link_cap
Signed-off-by: Wesley Chalmers
Reviewed-by: Jun Lei
Acked-by: Anson Jacob
---
.../gpu/drm/amd/display/dc/core/dc_link_dp.c | 75 ++-
1 file changed, 41
From: Dmytro Laktyushkin
cleanup
Signed-off-by: Dmytro Laktyushkin
Reviewed-by: Aric Cyr
Acked-by: Anson Jacob
---
drivers/gpu/drm/amd/display/dc/dml/display_mode_vba.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dml/display_mode_vba.c
From: Ashley Thomas
[WHY]
Ability to triage DMCUB is improved with availability of certain
dmub registers not currently captured in crash dump diagnostic data.
[HOW]
Add dmub registers to diagnostic data collection.
Thanks Nicholas Kazlauskas for awesome input on this!
Signed-off-by: Ashley
From: Anthony Koo
Signed-off-by: Anthony Koo
Reviewed-by: Anthony Koo
Acked-by: Anson Jacob
---
drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h
From: David Galiffi
[Why]
Fixed spelling error.
[How]
Changed "currnet_setting" to "current_setting".
Signed-off-by: David Galiffi
Reviewed-by: Wesley Chalmers
Acked-by: Anson Jacob
---
drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 12 ++--
1 file changed, 6 insertions(+), 6
From: Wesley Chalmers
[WHY]
SCR for DP 2.0 requires that LTTPR caps be read first on hotplug.
For the sake of consistency, this should also be the case on bootup.
Signed-off-by: Wesley Chalmers
Reviewed-by: Jun Lei
Acked-by: Anson Jacob
---
From: Wesley Chalmers
[WHY]
DP 2.0 SCR specifies that
"A DPTX shall distinguish I2C_DEFER|AUX_ACK from AUX_DEFER. AUX retries
due to
I2C_DEFER are not counted as part of minimum 7 retires (sic) upon
AUX_DEFER’s"
Signed-off-by: Wesley Chalmers
Reviewed-by: Jun Lei
Acked-by: Anson Jacob
---
From: Wesley Chalmers
[WHY]
SCR for DP2.0 requires that LT be performed with PHY_REPEATER_MODE
programmed to 0x55 (Transparent) whenever PHY_REPEATER_CNT is any value
other than 0x80, 0x40, 0x20, 0x10, 0x08, 0x04, 0x02, or 0x01.
[HOW]
Write Non-Transparent (0xAA) to PHY_REPEATER_MODE when
From: Wenjing Liu
[why]
Move mst start top mgr in dc_link_detect layer.
Remove unused same_dpcd variable.
Move PEAK_FACTOR_X1000 and LINK_TRAINING_MAX_VERIFY_RETRY
to the proper header for defining dc link internal constant.
Signed-off-by: Wenjing Liu
Reviewed-by: George Shen
Acked-by: Anson
From: Aric Cyr
This version brings along following fixed:
- LTTPR improvements
- Backlight improvements
- eDP hotplug detection
Signed-off-by: Aric Cyr
Reviewed-by: Aric Cyr
Acked-by: Anson Jacob
---
drivers/gpu/drm/amd/display/dc/dc.h | 2 +-
1 file changed, 1 insertion(+), 1
This DC patchset brings improvements in multiple areas. In summary, we have:
* LTTPR improvements
* Backlight improvements
* eDP hotplug detection
*** BLURB HERE ***
Anthony Koo (1):
drm/amd/display: [FW Promotion] Release 0.0.70
Aric Cyr (1):
drm/amd/display: 3.2.140
Ashley Thomas (1):
On Tue, Jun 8, 2021 at 5:40 PM Luben Tuikov wrote:
>
> 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
>
On Tue, Jun 8, 2021 at 5:40 PM Luben Tuikov wrote:
>
> 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
>
On Tue, Jun 8, 2021 at 5:40 PM Luben Tuikov wrote:
>
> 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.
On Tue, Jun 8, 2021 at 5:40 PM Luben Tuikov wrote:
>
> From: Andrey Grodzovsky
Needs a commit message. With that fixed:
Acked-by: Alex Deucher
>
> Cc: Jean Delvare
> Cc: Alexander Deucher
> Cc: Andrey Grodzovsky
> Cc: Lijo Lazar
> Cc: Stanley Yang
> Cc: Hawking Zhang
> Signed-off-by:
On Tue, Jun 8, 2021 at 5:40 PM Luben Tuikov wrote:
>
> 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
Recently, we added support for an experimental feature named Freesync
video; for more details on that, refer to:
commit a372f4abecb1 ("drm/amd/display: Skip modeset for front porch change")
commit 952bc47fb2ca ("drm/amd/display: Add freesync video modes based on
preferred modes")
commit
Am 10.06.21 um 18:34 schrieb Michel Dänzer:
On 2021-06-10 11:17 a.m., Christian König wrote:
Since we can't find a consensus on hot to move forward with the dma_resv object
I concentrated on changing the approach for amdgpu first.
This new approach changes how the driver stores the command
On 2021-06-10 11:17 a.m., Christian König wrote:
> Since we can't find a consensus on hot to move forward with the dma_resv
> object I concentrated on changing the approach for amdgpu first.
>
> This new approach changes how the driver stores the command submission fence
> in the dma_resv
From: Po-Ting Chen
[Why]
To change the swizzle visual confirm reference pipe from top pipe to
bottom pipe due to bottom pipe information would be more important
for multiple overlay case.
Signed-off-by: Po-Ting Chen
Reviewed-by: Anthony Koo
Acked-by: Anson Jacob
---
On Tue, Jun 08, 2021 at 07:19:31PM +0200, Werner Sembach wrote:
>
> Am 07.06.21 um 22:33 schrieb Werner Sembach:
> > Am 07.06.21 um 08:47 schrieb Werner Sembach:
> >>
> >> Am 04.06.21 um 19:30 schrieb Ville Syrjälä:
> >>> On Fri, Jun 04, 2021 at 07:17:23PM +0200, Werner Sembach wrote:
> This
On Thu, Jun 10, 2021 at 02:50:36PM +0200, Maxime Ripard wrote:
> Hi
>
> On Tue, Jun 08, 2021 at 07:43:17PM +0200, Werner Sembach wrote:
> > This commits implements the "active bpc" drm property for the Intel GPU
> > driver.
> >
> > Signed-off-by: Werner Sembach
> > ---
> >
Hi
On Tue, Jun 08, 2021 at 07:43:17PM +0200, Werner Sembach wrote:
> This commits implements the "active bpc" drm property for the Intel GPU
> driver.
>
> Signed-off-by: Werner Sembach
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 14 ++
>
When compiling the kernel for MIPS with CONFIG_DRM_AMDGPU = y, errors are
encountered as follows:
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.o: In function `amdgpu_vram_mgr_new':
amdgpu_vram_mgr.c:(.text+0x740): undefined reference to `__udivdi3'
Making a 64 bit division by a/b (a is uint64_t)
Hello,
在 2021/6/10 16:20, Christian König 写道:
Am 10.06.21 um 10:20 schrieb He Ying:
When compiling the kernel for MIPS with CONFIG_DRM_AMDGPU = y, errors
are
encountered as follows:
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.o: In function
`amdgpu_vram_mgr_new':
Am 10.06.21 um 10:20 schrieb He Ying:
When compiling the kernel for MIPS with CONFIG_DRM_AMDGPU = y, errors are
encountered as follows:
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.o: In function `amdgpu_vram_mgr_new':
amdgpu_vram_mgr.c:(.text+0x740): undefined reference to `__udivdi3'
Making
Hello,
I receive warning/crash on kernel 5.12.9 on amdgpu. I paste the error
below, did you ppl need detailed information described
Documentation/admin-guide/reporting-bugs.rst or this is enought ?
<6>[6.591737] [drm] fb depth is 24
<6>[6.591738] [drm]pitch is 10240
<6>[
[AMD Official Use Only]
Reviewed-by: Horace Chen
-Original Message-
From: amd-gfx On Behalf Of YuBiao Wang
Sent: Wednesday, June 9, 2021 11:02 AM
To: amd-gfx@lists.freedesktop.org
Cc: Wang, YuBiao ; Grodzovsky, Andrey
; Xiao, Jack ; Xu, Feifei
; Chen, Horace ; Wang, Kevin(Yang)
;
[AMD Official Use Only]
Reviewed-by: Lijo Lazar
-Original Message-
From: Ashish Pawar
Sent: Thursday, June 10, 2021 12:18 AM
To: amd-gfx@lists.freedesktop.org
Cc: Lazar, Lijo ; Quan, Evan ; Pawar,
Ashish
Subject: [PATCH] drm/amdgpu: PWRBRK sequence changes for Aldebaran
Modify
Add a common allocation helper. Cleaning up the mix of kzalloc/kmalloc
and some unused code in the selftest.
Signed-off-by: Christian König
---
drivers/dma-buf/st-dma-fence-chain.c | 16 --
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c| 4 ++--
Unwrap a the explicit fence if it is a dma_fence_chain and
sync to the first fence not matching the owner rules.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c | 118 +--
1 file changed, 68 insertions(+), 50 deletions(-)
diff --git
Drop the workaround and instead implement a better solution.
Basically we are now chaining all submissions using a dma_fence_chain
container and adding them as exclusive fence to the dma_resv object.
This way other drivers can still sync to the single exclusive fence
while amdgpu only sync to
Exercise the newly added functions.
Signed-off-by: Christian König
---
drivers/dma-buf/st-dma-fence-chain.c | 48
1 file changed, 48 insertions(+)
diff --git a/drivers/dma-buf/st-dma-fence-chain.c
b/drivers/dma-buf/st-dma-fence-chain.c
index
Not needed any more since dma_fence_chain objects take care of this now.
Signed-off-by: Christian König
---
drivers/gpu/drm/drm_syncobj.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 1c5b9ef6da37..e6d144775a87 100644
Add some rather sophisticated lockless garbage collection
for dma_fence_chain objects.
For this keep all initialized dma_fence_chain nodes an a
queue and trigger garbage collection before a new one is
allocated.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-fence-chain.c | 160
The callback and the irq work are never used at the same
time. Putting them into an union saves us 24 bytes and
makes the structure only 120 bytes in size.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-fence-chain.c | 2 +-
include/linux/dma-fence-chain.h | 8 +---
2 files
Since we can't find a consensus on hot to move forward with the dma_resv object
I concentrated on changing the approach for amdgpu first.
This new approach changes how the driver stores the command submission fence in
the dma_resv object in DMA-buf exported BOs.
For exported BOs we now store
On Wed, 09 Jun 2021 21:23:27 +
Simon Ser wrote:
> This function sends a hotplug uevent with a CONNECTOR property.
>
> Signed-off-by: Simon Ser
> ---
> drivers/gpu/drm/drm_sysfs.c | 25 +
> include/drm/drm_sysfs.h | 1 +
> 2 files changed, 26 insertions(+)
>
>
On Tue, 8 Jun 2021 19:43:18 +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
Hi Dave, Daniel,
Fixes for 5.13.
The following changes since commit 614124bea77e452aa6df7a8714e8bc820b489922:
Linux 5.13-rc5 (2021-06-06 15:47:27 -0700)
are available in the Git repository at:
https://gitlab.freedesktop.org/agd5f/linux.git
tags/amd-drm-fixes-5.13-2021-06-09
for you to
On Tue, 8 Jun 2021 19:43:15 +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
>
Hi Dave, Daniel,
More new stuff for 5.14.
The following changes since commit 5745d647d5563d3e9d32013ad4e5c629acff04d7:
Merge tag 'amd-drm-next-5.14-2021-06-02' of
https://gitlab.freedesktop.org/agd5f/linux into drm-next (2021-06-04 06:13:57
+1000)
are available in the Git repository at:
Am 10.06.21 um 04:47 schrieb Guchun Chen:
Use adev_to_drm() to get to the drm_device pointer.
Signed-off-by: Guchun Chen
Reviewed-by: Luben Tuikov
Reviewed-by: Alex Deucher
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 2 +-
Am 2021-06-09 um 10:47 p.m. schrieb Guchun Chen:
> Use adev_to_drm() to get to the drm_device pointer.
>
> Signed-off-by: Guchun Chen
> Reviewed-by: Luben Tuikov
> Reviewed-by: Alex Deucher
Reviewed-by: Felix Kuehling
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 2 +-
>
Use adev_to_drm() to get to the drm_device pointer.
Signed-off-by: Guchun Chen
Reviewed-by: Luben Tuikov
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 2 +-
2 files changed, 2 insertions(+), 2
[Public]
Thanks for your kind feedback, Luben, Felix and Alex.
I will send a v2 set with your comments addressed and RB added.
Regards,
Guchun
-Original Message-
From: Tuikov, Luben
Sent: Thursday, June 10, 2021 1:06 AM
To: Alex Deucher ; Chen, Guchun
Cc: amd-gfx list ; Kuehling,
84 matches
Mail list logo
