this set adds support for removal of gpu drm dead code.
patch2:
`num_entries` is a data of unsigned type(compilers always treat as unsigned
int) and SIZE_MAX == ~0,
so there is a impossible condition:
'(num_entries > ((~0) - 56) / 72) => (max(0-u32) > 256204778801521549)'.
Signed-off-by: Pan Zh
this set adds support for removal of gpu drm dead code.
patch3 is similar with patch 1:
`num` is a data of u8 type and ATOM_MAX_HW_I2C_READ == 255,
so there is a impossible condition '(num > 255) => (0-255 > 255)'.
Signed-off-by: Pan Zhang
---
drivers/gpu/drm/radeon/atombios_i2c.c | 5 -
1
this set adds support for removal of gpu drm dead code.
patch1:
`num` is a data of u8 type and ATOM_MAX_HW_I2C_READ == 255,
so there is a impossible condition '(num > 255) => (0-255 > 255)'.
Signed-off-by: Pan Zhang
---
drivers/gpu/drm/amd/amdgpu/atombios_i2c.c | 5 -
1 file changed, 5 de
[AMD Official Use Only - Internal Distribution Only]
On Wed, Dec 18, 2019 at 07:40:26AM +0800, Kuehling, Felix wrote:
> See comment inline. Other than that, the series looks good to me.
>
> On 2019-12-16 2:02, Huang Rui wrote:
> > Thunk driver would like to know the num_cp_queues data, however th
Thunk driver would like to know the num_cp_queues data, however this data relied
on different asic specific. So it's better to get it from kfd driver.
v2: don't update name size.
Signed-off-by: Huang Rui
---
drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 3 +++
drivers/gpu/drm/amd/amdkfd/kfd_topol
Thunk driver would like to know the num_sdma_queues_per_engine data, however
this data relied on different asic specific. So it's better to get it from kfd
driver.
v2: don't update the name size.
Signed-off-by: Huang Rui
---
drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 4
drivers/gpu/drm/am
From: "Tianci.Yin"
IP discovery TMR(occupied the top VRAM with size DISCOVERY_TMR_SIZE)
has been reserved, and the p2c buffer is in the range of this TMR, so
the p2c buffer reservation is unnecessary.
Change-Id: Ib1f2f2b4a1f3869c03ffe22e2836cdbee17ba99f
Signed-off-by: Tianci.Yin
---
drivers/gp
From: "Tianci.Yin"
The method of getting fb_loc changed from parsing VBIOS to
taking certain offset from top of VRAM
Change-Id: I053b42fdb1d822722fa7980b2cd9f86b3fdce539
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 3 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c | 2 +-
.../gpu/drm
Hi Kevin,
Thanks very much!
I have rename the amdgpu_atomfirmware_get_mem_train_fb_loc function to
amdgpu_atomfirmware_get_mem_train_info, please review again.
Rico
From: Wang, Kevin(Yang)
Sent: Wednesday, December 18, 2019 13:32
To: Yin, Tianci (Rico) ; amd-gf
[AMD Official Use Only - Internal Distribution Only]
Reviewed-by: Kevin Wang
Best Regards,
Kevin
From: Tianci Yin
Sent: Wednesday, December 18, 2019 4:50 PM
To: amd-gfx@lists.freedesktop.org
Cc: Tuikov, Luben ; Koenig, Christian
; Deucher, Alexander ;
Zhang,
Thanks Kevin!
From: Wang, Kevin(Yang)
Sent: Wednesday, December 18, 2019 16:53
To: Yin, Tianci (Rico) ; amd-gfx@lists.freedesktop.org
Cc: Tuikov, Luben ; Koenig, Christian
; Deucher, Alexander ;
Zhang, Hawking ; Xu, Feifei ; Yuan,
Xiaojie ; Long, Gang
Subject
[AMD Official Use Only - Internal Distribution Only]
comment inline.
From: Tianci Yin
Sent: Wednesday, December 18, 2019 4:50 PM
To: amd-gfx@lists.freedesktop.org
Cc: Tuikov, Luben ; Koenig, Christian
; Deucher, Alexander ;
Zhang, Hawking ; Xu, Feifei ; Yuan,
Hi Kevin,
You mean like this? It's a bit lengthy.
- ctx->c2p_train_data_offset &= ~(ONE_MiB - 1);
+ ctx->c2p_train_data_offset = ALIGN(ctx->c2p_train_data_offset, ONE_MiB);
Rico
From: Wang, Kevin(Yang)
Sent: Wednesday, December 18, 2019 16:56
To: Yin, Tianci (Ri
Am 18.12.19 um 04:50 schrieb Pan Zhang:
this set adds support for removal of gpu drm dead code.
patch2:
`num_entries` is a data of unsigned type(compilers always treat as unsigned
int) and SIZE_MAX == ~0,
so there is a impossible condition:
'(num_entries > ((~0) - 56) / 72) => (max(0-u32) > 25
Am 18.12.19 um 04:25 schrieb Evan Quan:
Knowing whether gpu recovery was performed successfully or not
is important for our BACO development.
Change-Id: I0e3ca4dcb65a053eb26bc55ad7431e4a42e160de
Signed-off-by: Evan Quan
---
drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 4 +---
1 file changed,
On 2019-12-18 4:50 a.m., Pan Zhang wrote:
> this set adds support for removal of gpu drm dead code.
>
> patch2:
> `num_entries` is a data of unsigned type(compilers always treat as unsigned
> int) and SIZE_MAX == ~0,
>
> so there is a impossible condition:
> '(num_entries > ((~0) - 56) / 72) =>
Under sriov, the disable operation is no allowed.
Signed-off-by: Yintian Tao
---
drivers/gpu/drm/amd/powerplay/hwmgr/hardwaremanager.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/hardwaremanager.c
b/drivers/gpu/drm/amd/powerplay/hwmgr/hardwaremanag
[AMD Official Use Only - Internal Distribution Only]
Reviewed-by: Kenneth Feng
-Original Message-
From: Yintian Tao
Sent: Wednesday, December 18, 2019 6:15 PM
To: Feng, Kenneth
Cc: amd-gfx@lists.freedesktop.org; Tao, Yintian
Subject: [PATCH] drm/amd/powerplay: skip disable dynamic s
enlarge agp_start address into 48bit with all bits set
Change-Id: I36eb757310fa71555c8355f99f89c89fed306638
Signed-off-by: Frank.Min
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
b/drivers/
1. enable xgmi ta initialization for sriov
2. enable xgmi initialization for sriov
Change-Id: I0b333ede6933381debba6b6d61d986c897c32a2b
Signed-off-by: Frank.Min
---
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 26 +++--
1 file changed, 7 insertions(+), 19 deletions(-)
diff --gi
On Tue, Dec 17, 2019 at 10:25 PM Evan Quan wrote:
>
> For non-RAS baco reset, there is no need to reset the SMC. Thus
> the firmware reloading should be avoided.
>
> Change-Id: I73f6284541d0ca0e82761380a27e32484fb0061c
> Signed-off-by: Evan Quan
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c |
On Fri, Dec 13, 2019 at 11:19:16AM +0100, Daniel Vetter wrote:
> On Wed, Dec 11, 2019 at 10:57:13PM +, Jason Gunthorpe wrote:
> > On Thu, Dec 05, 2019 at 11:03:24AM -0500, Jerome Glisse wrote:
> >
> > > > struct mmu_notifier_mm (ie the mm->mmu_notifier_mm)
> > > >-> mmn_mm
> > > > struct m
In skip_modeset label within dm_update_crtc_state(), the dc stream
cannot be NULL. Using BUG_ON as an assertion is not required and
can be removed. The patch replaces the check with a WARN_ON in case
dm_new_crtc_state->stream is NULL.
Signed-off-by: Aditya Pakki
---
drivers/gpu/drm/amd/display/a
On 2019-12-18 3:45 a.m., Huang Rui wrote:
Thunk driver would like to know the num_cp_queues data, however this data relied
on different asic specific. So it's better to get it from kfd driver.
v2: don't update name size.
Signed-off-by: Huang Rui
The series is
Reviewed-by: Felix Kuehling
On Wed, Dec 18, 2019 at 6:59 AM Jason Gunthorpe wrote:
>
> Do you think calling it 'mmn_subscriptions' is clear?
Why do you want that "mmn"?
Guys, the "mmn" part is clear from the _context_. The function name is
When the function name is something like "mmu_interval_read_begin()",
and the filen
The DF routines to arm xGMI performance will attempt to re-arm both on
performance monitoring start and read on initial failure to arm.
v2: Roll back reset_perfmon_cntr to void return since new perfmon
counters are now safe to write to during DF C-States. Do single perfmon
controller re-arm when
On Tue, Dec 17, 2019 at 10:57:11AM -0500, Harry Wentland wrote:
> On 2019-12-11 2:33 a.m., Louis Li wrote:
> > [Why]
> > External monitor cannot be displayed consistently, if connecting
> > via this Apple dongle (A1621, USB Type-C to HDMI).
> > Experiments prove that the dongle needs 200ms at least
On Wed, Dec 18, 2019 at 08:53:05AM -0800, Linus Torvalds wrote:
> On Wed, Dec 18, 2019 at 6:59 AM Jason Gunthorpe wrote:
> Yes, global function names need to be unique, and if they aren't
> really core, they want some prefix that explains the context, because
> global functions are called from _o
On Wed, Dec 18, 2019 at 10:37 AM Jason Gunthorpe wrote:
>
> I think this is what you are looking for?
I think that with these names, I would have had an easier time reading
the original patch that made me go "Eww", yes.
Of course, now that it's just a rename patch, it's not like the patch
is all
On Wed, Dec 18, 2019 at 7:14 AM Frank.Min wrote:
>
> enlarge agp_start address into 48bit with all bits set
Might want to add a note that the max range of the agp aperture is 48
bits. With that fixed, the series is:
Reviewed-by: Alex Deucher
>
> Change-Id: I36eb757310fa71555c8355f99f89c89fed30
On Wed, Dec 18, 2019 at 3:13 AM Pan Zhang wrote:
>
> this set adds support for removal of gpu drm dead code.
>
> patch1:
> `num` is a data of u8 type and ATOM_MAX_HW_I2C_READ == 255,
>
> so there is a impossible condition '(num > 255) => (0-255 > 255)'.
>
> Signed-off-by: Pan Zhang
This change w
On Wed, Dec 18, 2019 at 3:14 AM Pan Zhang wrote:
>
> this set adds support for removal of gpu drm dead code.
>
> patch3 is similar with patch 1:
> `num` is a data of u8 type and ATOM_MAX_HW_I2C_READ == 255,
>
> so there is a impossible condition '(num > 255) => (0-255 > 255)'.
>
> Signed-off-by: P
On 2019-12-18 4:14 a.m., Yin, Tianci (Rico) wrote:
> Hi Kevin,
>
> You mean like this? It's a bit lengthy.
> - ctx->c2p_train_data_offset &= ~(ONE_MiB - 1);
> + ctx->c2p_train_data_offset = ALIGN(ctx->c2p_train_data_offset, ONE_MiB);
>
> - ctx->c2p_train_data_offset = adev->fw_vram_usage.me
Some nit-picks inline. Looks good otherwise.
On 2019-12-18 2:04 p.m., Jonathan Kim wrote:
The DF routines to arm xGMI performance will attempt to re-arm both on
performance monitoring start and read on initial failure to arm.
v2: Roll back reset_perfmon_cntr to void return since new perfmon
cou
Hey,
I've pulled in these two patches to drm-next directly because my arm
test build was broken.
Dave.
On Wed, 18 Dec 2019 at 06:47, Alex Deucher wrote:
>
> ARM has a 2000us limit for udelay. Switch to msleep. This code
> executes in a worker thread so shouldn't be an atomic context.
>
> Sign
Simplify padding calculations.
1. Taking the remainder of a binary value when
the divisor is a power of two, such as,
a % 2^n is identical to, a & (2^n - 1) in base-2
arithmetic, and so expressions like this:
(12 - (lower_32_bits(ring->wptr) & 7)) % 8
are superflous. And can be reduced to a sing
This patch seems to have been dropped after posting
and reposting. I'm not sure why it keeps being dropped.
In v3, I added an explanation in the commit text
below the original commit text of the single sentence
of "Simplify padding calculations." Identical diffstat
as v2.
Regards,
Luben
On 2019-
Hi Christian,
Here is some background for this change:
I'm debugging a random failure issue on baco reset.
I used a while loop to run the continuous baco reset tests and hope it can exit
immediately on failure occurred.
However, due to wrong return value, it did not. And as you can image, the
fa
Hi Alex,
"Power saving" means the regular suspend/resume case, right? That was
considered.
With current amdgpu code, the MP1 state was not correctly set for the regular
suspend case.
More straightforwardly I believe PrepareMP1_for_unload should be issued to MP1
on regular suspend path(excludi
From: "Tianci.Yin"
The method of getting fb_loc changed from parsing VBIOS to
taking certain offset from top of VRAM
Change-Id: I053b42fdb1d822722fa7980b2cd9f86b3fdce539
Signed-off-by: Tianci.Yin
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 3 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_atomb
[AMD Official Use Only - Internal Distribution Only]
Hi Luben,
Thank you very much for your suggestion and detailed explanation!
Patch has been refined, please help review.
Rico
From: Tuikov, Luben
Sent: Thursday, December 19, 2019 4:14
To: Yin, Tianci (Rico) ;
> -Original Message-
> From: Tuikov, Luben
> Sent: Wednesday, December 18, 2019 6:17 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander ; Koenig, Christian
>
> Subject: Re: [PATCH] drm/amdgpu: simplify padding calculations (v3)
>
> This patch seems to have been dropped after
From: "Tianci.Yin"
IP discovery TMR(occupied the top VRAM with size DISCOVERY_TMR_SIZE)
has been reserved, and the p2c buffer is in the range of this TMR, so
the p2c buffer reservation is unnecessary.
Change-Id: Ib1f2f2b4a1f3869c03ffe22e2836cdbee17ba99f
Reviewed-by: Kevin Wang
Signed-off-by: Ti
[AMD Official Use Only - Internal Distribution Only]
Reviewed-by: Xiaojie Yuan
BR,
Xiaojie
From: Tianci Yin
Sent: Thursday, December 19, 2019 10:44 AM
To: amd-gfx@lists.freedesktop.org
Cc: Tuikov, Luben; Koenig, Christian; Deucher, Alexander; Zhang, Haw
Thanks Xiaojie!
From: Yuan, Xiaojie
Sent: Thursday, December 19, 2019 11:02
To: Yin, Tianci (Rico) ; amd-gfx@lists.freedesktop.org
Cc: Tuikov, Luben ; Koenig, Christian
; Deucher, Alexander ;
Zhang, Hawking ; Xu, Feifei ; Long,
Gang ; Wang, Kevin(Yang)
Subjec
On 2019-12-18 9:44 p.m., Tianci Yin wrote:
> From: "Tianci.Yin"
>
> The method of getting fb_loc changed from parsing VBIOS to
> taking certain offset from top of VRAM
>
> Change-Id: I053b42fdb1d822722fa7980b2cd9f86b3fdce539
> Signed-off-by: Tianci.Yin
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu
On 2019-12-18 9:59 p.m., Deucher, Alexander wrote:
>> -Original Message-
>> From: Tuikov, Luben
>> Sent: Wednesday, December 18, 2019 6:17 PM
>> To: amd-gfx@lists.freedesktop.org
>> Cc: Deucher, Alexander ; Koenig, Christian
>>
>> Subject: Re: [PATCH] drm/amdgpu: simplify padding calculat
On Wed, Dec 18, 2019 at 9:12 PM Quan, Evan wrote:
>
> Hi Alex,
>
> "Power saving" means the regular suspend/resume case, right? That was
> considered.
I mean BACO for runtime power management support. I landed the code
to enable BACO for saving power at runtime when the GPU is not in use.
It's
Hi Shaoyun
>>> Do we know the root cause why this function would ruin MEC ? From the
>>> logic, I think this function should be called before FLR since we need to
>>> disable the user queue submission first.
Right now I don't know which detail step lead to KIQ ring test fail, I totally
agree wi
Oh, by the way
>>> Do we know the root cause why this function would ruin MEC ?
Only we call this function right after VF FLR will ruin MEC and lead to
following KIQ ring test fail , and on bare-metal it is called before gpu rest ,
so that's why on bare-metal we don't have this issue
But the
I don't remember any register access by amdkfd_pre_reset call, please let me
know if this assumption is wrong .
This function will use hiq to access CP, in case CP already hang, we might not
able to get the response from hw and will got a timeout. I think kfd internal
should handle this. Felix
On 2019-12-18 5:52 p.m., Michel Dänzer wrote:
>> this set adds support for removal of gpu drm dead code.
>>
>> patch2:
>> `num_entries` is a data of unsigned type(compilers always treat as
>> unsigned int) and SIZE_MAX == ~0,
>>
>> so there is a impossible condition:
>> '(num_entries > ((~0) -
On Wed, Dec 18, 2019 at 6:07 PM Dave Airlie wrote:
>
> Hey,
>
> I've pulled in these two patches to drm-next directly because my arm
> test build was broken.
Sounds good.
Alex
>
> Dave.
>
> On Wed, 18 Dec 2019 at 06:47, Alex Deucher wrote:
> >
> > ARM has a 2000us limit for udelay. Switch to
Set r to 0 as a default value.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c
b/drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c
index 3271de38cb08..4ea8e20ed15d 100644
--- a/dr
>>> I would like to check why we need a special sequences for sriov on this
>>> pre_reset. If possible, make it the same as bare metal mode sounds better
>>> solution.
Because before VF FLR calling function would lead to register access through
KIQ, which will not complete because KIQ/GFX alre
SMU12 not support WORKLOAD_DEFAULT_BIT and WORKLOAD_PPLIB_POWER_SAVING_BIT.
Signed-off-by: Prike Liang
---
drivers/gpu/drm/amd/powerplay/renoir_ppt.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/renoir_ppt.c
b/drivers/gpu/drm/amd/powe
Reviewed-by: Evan Quan
> -Original Message-
> From: Liang, Prike
> Sent: Thursday, December 19, 2019 2:46 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Quan, Evan ; Huang, Ray ;
> Dai, Yuxian (David) ; Liang, Prike
>
> Subject: [PATCH] drm/amd/powerplay: suppress nonsupport profile mode
For we don't support the mode, so shouldn't print the error message, or regard
as a error.
For log message, the error is high level .maybe change from "error" to
"warning" , it will be much better.
-Original Message-
From: Liang, Prike
Sent: Thursday, December 19, 2019 2:46 PM
To: a
[AMD Official Use Only - Internal Distribution Only]
On Thu, Dec 19, 2019 at 03:04:12PM +0800, Dai, Yuxian (David) wrote:
> For we don't support the mode, so shouldn't print the error message, or
> regard as a error.
> For log message, the error is high level .maybe change from "error" to
> "wa
[AMD Official Use Only - Internal Distribution Only]
> -Original Message-
> From: Huang, Ray
> Sent: Thursday, December 19, 2019 3:17 PM
> To: Dai, Yuxian (David)
> Cc: Liang, Prike ; amd-gfx@lists.freedesktop.org;
> Quan, Evan
> Subject: Re: [PATCH] drm/amd/powerplay: suppress nonsup
As Ray point out. We should set the SMU_MSG_SetWorkloadMask with specified
value to indicate unsupported.
But the current a value with system error value: "-EINVAL"
The firmware maybe response with unexpected action to driver.
-Original Message-
From: Huang, Ray
Sent: Thursday, D
[AMD Official Use Only - Internal Distribution Only]
> -Original Message-
> From: Dai, Yuxian (David)
> Sent: Thursday, December 19, 2019 3:39 PM
> To: Huang, Ray ; Liang, Prike
> Cc: amd-gfx@lists.freedesktop.org; Quan, Evan
> Subject: RE: [PATCH] drm/amd/powerplay: suppress nonsuppo
62 matches
Mail list logo
