> -Original Message-
> From: amd-gfx On Behalf Of
> Kenneth Feng
> Sent: Friday, November 8, 2019 1:43 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Feng, Kenneth
> Subject: [PATCH v2] drm/amd/powerplay: dynamically disable ds and ulv for
> compute
>
> This is to improve the
Reviewed-by: Hawking Zhang
Regards,
Hawking
-Original Message-
From: amd-gfx On Behalf Of Kenneth Feng
Sent: 2019年11月8日 13:43
To: amd-gfx@lists.freedesktop.org
Cc: Feng, Kenneth
Subject: [PATCH v2] drm/amd/powerplay: dynamically disable ds and ulv for
compute
This is to improve the
Reviewed-by: Evan Quan
> -Original Message-
> From: amd-gfx On Behalf Of Matt
> Coffin
> Sent: Friday, November 8, 2019 2:36 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Matt Coffin
> Subject: [PATCH 3/3] drm/amdgpu/navi10: Implement od clk printing
>
> [Why]
> Before this patch,
Comment inline
> -Original Message-
> From: amd-gfx On Behalf Of Matt
> Coffin
> Sent: Friday, November 8, 2019 2:35 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Matt Coffin
> Subject: [PATCH 2/3] drm/amdgpu/navi10: implement GFXCLK_CURVE
> overdrive
>
> [Why]
> Before this patch,
Thanks for adding these. Some comments inline.
> -Original Message-
> From: amd-gfx On Behalf Of Matt
> Coffin
> Sent: Friday, November 8, 2019 2:34 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Matt Coffin
> Subject: [PATCH 1/3] drm/amdgpu/navi10: implement sclk/mclk OD via
>
This is to improve the performance in the compute mode
for vega10. For example, the original performance for a rocm
bandwidth test: 2G internal GPU copy, is about 99GB/s.
With the idle power features disabled dynamically, the porformance
is promoted to about 215GB/s.
Signed-off-by: Kenneth Feng
Reviewed-by: Evan Quan
> -Original Message-
> From: amd-gfx On Behalf Of Alex
> Deucher
> Sent: Friday, November 8, 2019 4:18 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander
> Subject: [PATCH] drm/amdgpu/powerplay: fix AVFS handling with custom
> powerplay table
>
>
>-Original Message-
>From: Christian König
>Sent: Thursday, November 7, 2019 7:28 PM
>To: Deng, Emily ; amd-gfx@lists.freedesktop.org
>Subject: Re: [PATCH] drm/amdgpu: Fix the null pointer issue for tdr
>
>Am 07.11.19 um 11:25 schrieb Emily Deng:
>> When the job is already signaled, the
Thanks Hawking, it makes sense.
I will update the patch.
-Original Message-
From: Zhang, Hawking
Sent: Thursday, November 7, 2019 9:29 PM
To: Feng, Kenneth ; amd-gfx@lists.freedesktop.org
Cc: Feng, Kenneth
Subject: RE: [PATCH] drm/amd/powerplay: disable ds and ulv for compute
Hi
Reviewed-by: Kenneth Feng
-Original Message-
From: amd-gfx On Behalf Of Quan, Evan
Sent: Thursday, November 7, 2019 3:39 PM
To: amd-gfx@lists.freedesktop.org
Cc: Li, Candice ; Quan, Evan ; Freehill,
Chris
Subject: [PATCH] drm/amd/powerplay: correct Arcturus OD support
[CAUTION:
> -Original Message-
> From: Zhu, Changfeng
> Sent: Friday, November 08, 2019 9:55 AM
> To: amd-gfx@lists.freedesktop.org; Zhang, Hawking
> ; Huang, Ray
> Cc: Zhu, Changfeng
> Subject: [PATCH] drm/amdgpu: allow direct upload save restore list for
> raven2
>
> From: changzhu
>
> It
On Fri, Nov 08, 2019 at 12:32:25AM +, Jason Gunthorpe wrote:
> On Thu, Nov 07, 2019 at 04:04:08PM -0500, Jerome Glisse wrote:
> > On Thu, Nov 07, 2019 at 08:11:06PM +, Jason Gunthorpe wrote:
> > > On Wed, Nov 06, 2019 at 09:08:07PM -0500, Jerome Glisse wrote:
> > >
> > > > >
> > > > >
From: changzhu
It will cause modprobe atombios stuck problem in raven2 if it doesn't
allow direct upload save restore list from gfx driver.
So it needs to allow direct upload save restore list for raven2
temporarily.
Change-Id: I1fece1b9c61f7a13eec948f34eb60a9120046bc2
Signed-off-by: changzhu
19. 8. 1. 오전 1:58에 Andrzej Pietrasiewicz 이(가) 쓴 글:
> Switch to using the ddc provided by the generic connector.
>
> Signed-off-by: Andrzej Pietrasiewicz
> Acked-by: Sam Ravnborg
> Reviewed-by: Emil Velikov
Acked-by: Inki Dae
Thanks,
Inki Dae
> ---
> drivers/gpu/drm/exynos/exynos_hdmi.c
On Thu, Nov 7, 2019 at 4:30 PM Ilia Mirkin wrote:
>
> On Thu, Nov 7, 2019 at 5:21 PM Bjorn Helgaas wrote:
> > diff --git a/include/uapi/linux/pci_regs.h b/include/uapi/linux/pci_regs.h
> > index 29d6e93fd15e..03446be8a7be 100644
> > --- a/include/uapi/linux/pci_regs.h
> > +++
On 11/7/19 3:36 PM, Jason Gunthorpe wrote:
> On Tue, Nov 05, 2019 at 10:16:46AM -0500, Boris Ostrovsky wrote:
>
>>> So, I suppose it can be relaxed to a null test and a WARN_ON that it
>>> hasn't changed?
>> You mean
>>
>> if (use_ptemod) {
>> WARN_ON(map->vma != vma);
>> ...
>>
>>
> -Original Message-
> From: amd-gfx On Behalf Of
> Bjorn Helgaas
> Sent: Thursday, November 7, 2019 5:21 PM
> To: Deucher, Alexander ; Koenig, Christian
> ; Zhou, David(ChunMing)
> ; David Airlie ; Daniel Vetter
>
> Cc: Bjorn Helgaas ; dri-de...@lists.freedesktop.org;
>
On Thu, Nov 7, 2019 at 5:21 PM Bjorn Helgaas wrote:
> diff --git a/include/uapi/linux/pci_regs.h b/include/uapi/linux/pci_regs.h
> index 29d6e93fd15e..03446be8a7be 100644
> --- a/include/uapi/linux/pci_regs.h
> +++ b/include/uapi/linux/pci_regs.h
> @@ -673,6 +673,8 @@
> #define
From: Bjorn Helgaas
Replace hard-coded magic numbers with the descript PCI_EXP_LNKCTL2
definitions. No functional change intended.
---
drivers/gpu/drm/amd/amdgpu/cik.c | 8
drivers/gpu/drm/amd/amdgpu/si.c | 8
drivers/gpu/drm/radeon/cik.c | 8
From: Bjorn Helgaas
Add definitions for these PCIe Link Control 2 register fields:
Enter Compliance
Transmit Margin
and use them in amdgpu and radeon.
NOTE: This is a functional change because "7 << 9" looks like it might be a
typo. That mask includes the high order bit of Transmit
From: Bjorn Helgaas
amdgpu and radeon do a bit of mucking with the PCIe Link Control 2
register, some of it using hard-coded magic numbers. The idea here is to
replace those with #defines.
I haven't signed off on these because the first one actually changes the
bits involved because the
Okay. I submitted a PSDB. Meanwhile, I got the answer from FW and SQ HW contact
that nothing bad will happen on GFX9 by writing 1 to TRAP_EN.
Regards,
Yong
From: Kuehling, Felix
Sent: Thursday, November 7, 2019 4:07 PM
To: Zhao, Yong ;
Are you sure that setting the SQ_SHADER_TBA_HI__TRAP_EN bit on GFXv9 is
completely harmless? If the field is not defined, maybe setting the bit
makes the address invalid. It's probably worth running that through a
PSDB, which would cover Vega10, Vega20 and Arcturus.
If it actually works, the
On 11/7/19 12:06 PM, Jason Gunthorpe wrote:
...
Also, it is best moved down to be next to the new MNR structs, so that all the
MNR stuff is in one group.
I agree with Jerome, this enum is part of the 'struct
mmu_notifier_range' (ie the description of the invalidation) and it
doesn't really
On Tue, Nov 05, 2019 at 10:16:46AM -0500, Boris Ostrovsky wrote:
> > So, I suppose it can be relaxed to a null test and a WARN_ON that it
> > hasn't changed?
>
> You mean
>
> if (use_ptemod) {
> WARN_ON(map->vma != vma);
> ...
>
>
> Yes, that sounds good.
I amended my copy of
On Thu, Nov 07, 2019 at 08:11:06PM +, Jason Gunthorpe wrote:
> On Wed, Nov 06, 2019 at 09:08:07PM -0500, Jerome Glisse wrote:
>
> > >
> > > Extra credit: IMHO, this clearly deserves to all be in a new
> > > mmu_range_notifier.h
> > > header file, but I know that's extra work. Maybe later as
On 2019-11-07 13:32, Alex Deucher wrote:
> On Thu, Nov 7, 2019 at 12:47 PM Kuehling, Felix
> wrote:
>> No, please lets not add a new nomenclature for PM4 packet versions. GFX
>> versions are agreed on between hardware, firmware, and software and it's
>> generally understood what they mean. If
After considering Kent's concern, I actually took the consolidation to the next
level where v9 and v10 have no divergence. With that, I think the "mustness" is
stronger. Please check out the new patch.
Regards,
Yong
On 2019-11-07 3:31 p.m., Kuehling, Felix wrote:
On 2019-11-07 14:40, Zhao,
The kernel queue functions for v9 and v10 are the same except
pm_map_process_v* which have small difference, so they should be reused.
This eliminates the need of reapplying several patches which were
applied on v9 but not on v10, such as bigger GWS and more than 2
SDMA engine support which were
On 2019-11-07 14:40, Zhao, Yong wrote:
Hi Felix,
The code working fine is true except that all not new features after this
duplication are broken. If I want to make all GFX10 feature complete, I have to
either manually adapt several duplications to the GFX10 file or do this
consolidation. From
On Wed, Nov 06, 2019 at 09:08:07PM -0500, Jerome Glisse wrote:
> >
> > Extra credit: IMHO, this clearly deserves to all be in a new
> > mmu_range_notifier.h
> > header file, but I know that's extra work. Maybe later as a follow-up patch,
> > if anyone has the time.
>
> The range notifier
On Wed, Nov 06, 2019 at 04:23:21PM -0800, John Hubbard wrote:
> Nice design, I love the seq foundation! So far, I'm not able to spot anything
> actually wrong with the implementation, sorry about that.
Alas :( I feel there must be a bug in here still, but onwards!
One of the main sad points
When a custom powerplay table is provided, we need to update
the OD VDDC flag to avoid AVFS being enabled when it shouldn't be.
Bug: https://bugzilla.kernel.org/show_bug.cgi?id=205393
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 7 +++
1 file changed,
Hi Felix,
The code working fine is true except that all not new features after this
duplication are broken. If I want to make all GFX10 feature complete, I have to
either manually adapt several duplications to the GFX10 file or do this
consolidation. From this perspective and ease of my work,
On 2019-11-07 13:54, Zhao, Yong wrote:
Hi Kent,
This consolidation is a must, because we should not have duplicated it in the
first place.
The code is working fine with the duplication. You disagree with duplicating
the code in the first place. But that's just your opinion. It's not a must in
Hi Kent,
This consolidation is a must, because we should not have duplicated it in the
first place. The kernel queue functions by design are generic. The reasson why
GFX8 and GFX9 are different is because GFX9 is SOC15 where packet formats and
doorbell size changed. On the other hand,
[Why]
Before this patch, navi10 overdrive settings could not be printed via
pp_od_clk_voltage
[How]
Implement printing for the overdrive settings for the following clocks
in navi10's ppt print_clk_levels implementation:
* SMU_OD_SCLK
* SMU_OD_MCLK
* SMU_OD_VDDC_CURVE
---
[Why]
Before this patch, there was no way to use pp_od_clk_voltage on navi
[How]
Similar to the vega20 implementation, but using the common smc_v11_0
headers, implemented the pp_od_clk_voltage API for navi10's pptable
implementation
---
drivers/gpu/drm/amd/powerplay/inc/smu_v11_0.h | 1 +
[Why]
Before this patch, there was no way to set the gfxclk voltage curve in
the overdrive settings for navi10 through pp_od_clk_voltage
[How]
Add the required implementation to navi10's ppt dpm table editing
implementation, similar to the vega20 implementation and interface.
---
[Why]
Before this patchset, navi10 users could not utilize the overdrive
functionality. This prevented them from overclocking, overvolting, or
undervolting their cards.
[How]
Similar to the vega20 implementation, add the pp_od_clk_voltage
interface to the navi10 powerplay table.
[Possible
On Thu, Nov 7, 2019 at 12:47 PM Kuehling, Felix wrote:
>
> No, please lets not add a new nomenclature for PM4 packet versions. GFX
> versions are agreed on between hardware, firmware, and software and it's
> generally understood what they mean. If we add a new PM4 packet versioning
> scheme on
The kernel queue functions for v9 and v10 are the same except
pm_map_process_v* which have small difference, so they should be reused.
This eliminates the need of reapplying several patches which were
applied on v9 but not on v10, such as bigger GWS and more than 2
SDMA engine support which were
That makes sense, Felix.
My big issue is that if I am looking for Hawaii, I go to gfx7, I don’t look in
gfx8. And then I have to search the git history to see if it was a mistake, or
intentional. As it stands, the consolidation of code is just going to make
things more confusing in the end
Hi Yong,
That has been submitted.
MC address is the address sent to memory controller bus to address the physical
memory. In many places it is also called physical address.
Logical address is the address before it is translated to physical address. The
translation can be either linear or
On 2019-11-07 12:33, Zhao, Yong wrote:
> The new code uses straightforward bit shifts and thus has better readability.
>
> Change-Id: I0c1f7cca7e24ddb7b4ffe1cb0fa71943828ae373
> Signed-off-by: Yong Zhao
Reviewed-by: Felix Kuehling
> ---
> drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 17
No, please lets not add a new nomenclature for PM4 packet versions. GFX
versions are agreed on between hardware, firmware, and software and it's
generally understood what they mean. If we add a new PM4 packet versioning
scheme on our own, then this will add a lot of confusion when talking to
Hi Kent,
I can't agree more on this. Also, the same applies to the file names.
Definitely we need to agree on the naming scheme before making it happen.
Yong
On 2019-11-07 12:33 p.m., Russell, Kent wrote:
I think that the versioning is getting a little confusing since we’re using the
old GFX
The new code uses straightforward bit shifts and thus has better readability.
Change-Id: I0c1f7cca7e24ddb7b4ffe1cb0fa71943828ae373
Signed-off-by: Yong Zhao
---
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 17 +++--
drivers/gpu/drm/amd/amdkfd/kfd_events.c | 1 -
I think that the versioning is getting a little confusing since we're using the
old GFX versions, but not really sticking to it due to the shareability of
certain managers and shaders. Could we look into doing something like gen1 or
gen2, or some other more ambiguous non-GFX-related versioning?
True. Thank you for spotting that. MMAP-related code was added after I
inititally drafted this change earlier this year.
Regards,
Yong
From: Kuehling, Felix
Sent: Thursday, November 7, 2019 12:05 AM
To: Zhao, Yong ; amd-gfx@lists.freedesktop.org
Subject: Re:
If this is not submitted, I would like to see some comments regarding the
explanation of MC address and logical address, which I prefer to mention as GPU
physical/virtual address.
Regards,
Yong
From: amd-gfx on behalf of Alex Deucher
Sent: Thursday,
Hi Felix,
That's because v8 and v7 share the same packet_manager_funcs. In this case, it
is better to keep it as it is.
Regards,
Yong
From: Kuehling, Felix
Sent: Wednesday, November 6, 2019 11:45 PM
To: Zhao, Yong ; amd-gfx@lists.freedesktop.org
Subject: Re:
On 2019-11-06 8:52 p.m., Alex Deucher wrote:
> Need to protect some DSC functions.
>
> Signed-off-by: Alex Deucher
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git
[Why]
These defines/macros exist already no need to redefine them
[How]
Use the defines/macros from drm_hdcp.h
-we share the rxstatus between HDMI and DP (2 bytes), But upstream
defines/macros for HDMI are for 1 byte. So we need to create a separate
rxstatus for HDMI
Signed-off-by: Bhawanpreet
[Why]
static analysis throws the error below
Out-of-bounds read (OVERRUN)
Overrunning array of 5 bytes at byte offset 7 by dereferencing pointer
(uint64_t *)hdcp->auth.msg.hdcp1.bksv.
var n is going to contain r0p and bcaps. if they are non-zero the count
will be wrong
How]
Use memcpy instead
The module works like a state machine
+-+
--> | Execution.c | --
| +-+ |
| V
++
[Why]
Before we had a disable_type1 flag, this forced HDCP 2.2 to type0
There was no way to force type1.
[How]
Remove disable_type1 flag and instead add a flag to force type0/1.
Signed-off-by: Bhawanpreet Lakha
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c| 2 +-
[Why]
Currently we share rxstatus between HDMI and DP, so we use 16bits
The drm defines work with 1bytes at a time. So we need to
split the HDMI rxstatus into 2bytes before we can use drm defines
[How]
-create rxstatus for dp and hdmi. rxstatus for hdmi is split into bytes
using arrays.
-use
[Why]
The old way was to poll PSP and update the properties. But due to a
limitation in the PSP interface this doesn't work for MST.
[How]
According to PSP if set_encryption return success, the link is encrypted
and the only way it will not be is if we get a link loss(which we handle
already).
[Why]
We need to log the state changes for 2.2
This patch extends the existing logging functions to handle
HDCP2.2.
[How]
We do this by adding if/else in the defines, and output the log
based on the hdcp version
Signed-off-by: Bhawanpreet Lakha
---
.../drm/amd/display/modules/hdcp/hdcp_log.c
[Why]
We need these to read and write to aux/i2c, during
authentication
[How]
Create read/write functions for all the steps
(Eg, h_prime, paring_info etc)
Signed-off-by: Bhawanpreet Lakha
---
.../drm/amd/display/modules/hdcp/hdcp_ddc.c | 326 ++
1 file changed, 326
[Why]
drm already has this define
[How]
drm Mask is 0x08 vs 0x0800. The reason is because drm mask
works on a byte.^^
===||
||
Since the first byte is always zero we can ignore it and only check the
second byte.
Signed-off-by: Bhawanpreet Lakha
---
[Why]
HDCP 2.2 was disabled, we need to enable it
[How]
-Update display topology to support 2.2
-Unset hdcp2.disable in update_config
-Change logic of event_update_property, now we set the property to be
ENABLED for any level of encryption (2.2 or 1.4).
Signed-off-by: Bhawanpreet Lakha
---
[Why]
We need to do this to support HDCP over MST
Currently we save a display per link, in a MST case we need to save
multiple displays per link.
[How]
We can create an array per link to cache the displays, but it
complicates the design. Instead we can use the module to cache the
displays.
Now
[Why]
HDCP is a bit finicky so we try it 3 times, this leads to a case where
if we fail the first time and pass the second time the error is still
shown in dmesg for the first failed attempt.
This leads to false positive errors.
[How]
Change the logging from ERROR to WARNING. Warnings are still
[Why]
HDCP 2.2 uses type0 and type1 content type. This is passed to the receiver
to stream the proper content.
For example, in a MST case if the main
device is HDCP2.2 capable but the secondary device is only 1.4 capabale
we can use Type0
Type0 content: use HDCP 1.4 or HDCP2.2 type0
Type1
Just like with the 1.4 series of patches This only introduces the
ability to authenticate and encrypt the link. These patches by
themselves don't constitute a complete and compliant HDCP content
protection solution but are a requirement for such a solution.
Summary of the changes
*Adds 2.2 code
[Why]
All the HDCP transactions should be verified using PSP
[How]
This patch adds the psp calls we need to verify the steps
Signed-off-by: Bhawanpreet Lakha
---
.../gpu/drm/amd/display/modules/hdcp/hdcp.h | 44 ++
.../drm/amd/display/modules/hdcp/hdcp_psp.c | 502 +-
From: Mikita Lipski
Adding a helper function to be called by
drivers outside of DRM to enable DSC on
the MST ports.
Function is called to recalculate VCPI allocation
if DSC is enabled and raise the DSC flag to enable.
In case of disabling DSC the flag is set to false
and recalculation of VCPI
From: Mikita Lipski
Since for DSC MST connector's PBN is claculated differently
due to compression, we have to recalculate both PBN and
VCPI slots for that connector.
The function iterates through all the active streams to
find, which have DSC enabled, then recalculates PBN for
it and calls
From: Mikita Lipski
Synaptics DP1.4 hubs (BRANCH_ID 0x90CC24) do not
support virtual DPCD registers, but do support DSC.
The DSC caps can be read from the physical aux,
like in SST DSC. These hubs have many different
DEVICE_IDs. Add a new quirk to detect this case.
Reviewed-by: Wenjing Liu
From: Mikita Lipski
Adding PBN attribute to drm_dp_vcpi_allocation structure to
keep track of how much bandwidth each Port requires.
Adding drm_dp_mst_atomic_check_bw_limit to verify that
state's bandwidth needs doesn't exceed available bandwidth.
The funtion is called in drm_dp_mst_atomic_check
From: David Francis
For DSC MST, sometimes monitors would break out
in full-screen static. The issue traced back to the
PPS generation code, where these variables were being used
uninitialized and were picking up garbage.
memset to 0 to avoid this
Reviewed-by: Nicholas Kazlauskas
From: David Francis
If there is limited link bandwidth on a MST network,
it must be divided fairly between the streams on that network
Implement an algorithm to determine the correct DSC config
for each stream
The algorithm:
This
[ ] ( )
represents the range of
From: David Francis
Instead of having drm_dp_dpcd_read/write and
drm_dp_mst_dpcd_read/write as entry points into the
aux code, have drm_dp_dpcd_read/write handle both.
This means that DRM drivers can make MST DPCD read/writes.
v2: Fix spacing
v3: Dump dpcd access on MST read/writes
v4: Fix
From: David Francis
Add drm_dp_mst_dsc_aux_for_port. To enable DSC, the DSC_ENABLED
register might have to be written on the leaf port's DPCD,
its parent's DPCD, or the MST manager's DPCD. This function
finds the correct aux for the job.
As part of this, add drm_dp_mst_is_virtual_dpcd. Virtual
From: David Francis
This field on drm_dp_mst_branch was never filled
It is initialized to zero when the port is kzallocced.
When a port is added to the list, increment num_ports,
and when a port is removed from the list, decrement num_ports.
v2: remember to decrement on port removal
v3: don't
From: David Francis
Rework the dm_helpers_write_dsc_enable callback to
handle the MST case.
Use the cached dsc_aux field.
Reviewed-by: Wenjing Liu
Signed-off-by: David Francis
---
.../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 19 ++-
1 file changed, 18 insertions(+), 1
From: David Francis
During MST mode enumeration, if a new dc_sink is created,
populate it with dsc caps as appropriate.
Use drm_dp_mst_dsc_aux_for_port to get the raw caps,
then parse them onto dc_sink with dc_dsc_parse_dsc_dpcd.
Reviewed-by: Wenjing Liu
Signed-off-by: David Francis
---
From: Mikita Lipski
Patches are based of amd-staging-drm-next, the follow up
set of patches will be sent for drm-tip
This set of patches is a continuation of DSC enablement
patches for AMDGPU. This set enables DSC on MST. It also
contains implementation of both encoder and connector
atomic
From: David Francis
As of DP1.4, ENUM_PATH_RESOURCES returns a bit indicating
if FEC can be supported up to that point in the MST network.
The bit is the first byte of the ENUM_PATH_RESOURCES ack reply,
bottom-most bit (refer to section 2.11.9.4 of DP standard,
v1.4)
That value is needed for
From: David Francis
With DSC, bpp can be fractional in multiples of 1/16.
Change drm_dp_calc_pbn_mode to reflect this, adding a new
parameter bool dsc. When this parameter is true, treat the
bpp parameter as having units not of bits per pixel, but
1/16 of a bit per pixel
v2: Don't add separate
I think Kent has more insight with demand for this feature than I do, so I
defer to his opinion. I haven't received any feedback on that API.
Main thing is that if it's not supported, don't have the file visible.
Thanks,
Chris
-Original Message-
From: Russell, Kent
Sent: Thursday,
On Thu, Nov 7, 2019 at 7:03 AM Christian König
wrote:
>
> Hey Alex,
>
> any objections that I merge those two patches through drm-misc-next?
>
> It's a cleanup I wanted to do for years and Thomas finally fixed up TTM
> for this.
Fine with me. Series is:
Acked-by: Alex Deucher
>
> Cheers,
>
While we do like OverDrive being available (mostly our open-source community
users who are using consumer cards vs server cards), if it's not supported on
the HW for whatever reason, we'll adapt. If we get a request later for its
enablement (since OverDrive is consumer-card-only in general, and
On Wed, Nov 6, 2019 at 12:27 PM Zeng, Oak wrote:
>
> Explain fields like aper_base, agp_start etc. The definition
> of those fields are confusing as they are from different view
> (CPU or GPU). Add comments for easier understand.
>
> Change-Id: I02c2a27cd0dbc205498eb86aafa722f2e0c25fe6
>
On Thu, Nov 7, 2019 at 2:38 AM Quan, Evan wrote:
>
> OD is not supported on Arcturus. Thus the
> pp_od_clk_voltage sysfs interface is also not supported.
>
> Change-Id: Ib70632a55a0980cf04c3432d43dbcf869cd1b4bf
> Signed-off-by: Evan Quan
You might want to check with Chris and Kent about this.
Hi Kenneth,
I don't think there is sequence dependency between disabling power feature and
setting specific workload, correct? If so, we can move the enabling/disabling
power feature logic out of the "out" goto tag.
Secondly, It seems to me the new logical will result to duplicate power
Hey Alex,
any objections that I merge those two patches through drm-misc-next?
It's a cleanup I wanted to do for years and Thomas finally fixed up TTM
for this.
Cheers,
Christian.
Am 07.11.19 um 13:01 schrieb Christian König:
From: Christian König
Finally clean up the VMA setup for
From: Christian König
That is needed by at least a cleanup in radeon.
v2: also export ttm_bo_vm_access
Signed-off-by: Christian König
Reviewed-by: Huang Rui
---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 8 +---
include/drm/ttm/ttm_bo_api.h| 6 ++
2 files changed, 11 insertions(+), 3
From: Christian König
Finally clean up the VMA setup for radeon now that TTM exports the
necessary functions.
No functional change, but only compile tested.
Signed-off-by: Christian König
Reviewed-by: Huang Rui
---
drivers/gpu/drm/radeon/radeon_ttm.c | 29 ++---
1
Am 07.11.19 um 11:25 schrieb Emily Deng:
When the job is already signaled, the s_fence is freed. Then it will has
null pointer in amdgpu_device_gpu_recover.
NAK, the s_fence is only set to NULL when the job is destroyed. See
drm_sched_job_cleanup().
When you see a job without an s_fence
When the job is already signaled, the s_fence is freed. Then it will has
null pointer in amdgpu_device_gpu_recover.
Signed-off-by: Emily Deng
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +-
drivers/gpu/drm/scheduler/sched_main.c | 11 ++-
2 files changed, 7 insertions(+), 6
Am 07.11.19 um 08:36 schrieb Jesse Zhang:
move cancel_delayed_work_sync() to the begining
of amdgpu_device_fini() to cancel unfinished
works which are no longer needed.
Change-Id: I8831935b797c78b971aa7233697c36140374f1ac
Signed-off-by: Jesse Zhang
---
Am 06.11.19 um 18:51 schrieb Andrey Grodzovsky:
> This reverts commit 3cdf9bd0089723c468d5f6240e54d1afa52e9a04.
>
> We will do a proper fix in next patch.
>
> Signed-off-by: Andrey Grodzovsky
The order of this one and patch #2 needs to be swapped, or otherwise we
have the bug in between those
Am 06.11.19 um 18:26 schrieb Zeng, Oak:
Explain fields like aper_base, agp_start etc. The definition
of those fields are confusing as they are from different view
(CPU or GPU). Add comments for easier understand.
Change-Id: I02c2a27cd0dbc205498eb86aafa722f2e0c25fe6
Signed-off-by: Oak Zeng
---
Am 06.11.19 um 21:05 schrieb Zeng, Oak:
> Thanks Alex.
>
>> AGP is also used for page tables in system memory.
> I am not aware of this usage. I thought page table are all in frame buffer
> today. Was this a use case in old asics?
No, that is pretty new and only works for Renoir. But we have
This is to improve the performance in the compute mode
for vega10. For example, the original performance for a rocm
bandwidth test: 2G internal GPU copy, is about 99GB/s.
With the idle power features disabled dynamically, the porformance
is promoted to about 215GB/s.
Signed-off-by: Kenneth Feng
98 matches
Mail list logo
