I've still gotta do a little bit of thinking on this one, but I'll make sure
to get back to you about this patch on monday. In the mean time, everything
else looks great! Thanks for the good work :)
On Tue, 2019-12-03 at 09:35 -0500, mikita.lip...@amd.com wrote:
> From: David Francis
>
> If
Reviewed-by: Lyude Paul
On Tue, 2019-12-03 at 09:35 -0500, mikita.lip...@amd.com wrote:
> From: Mikita Lipski
>
> [why]
> 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.
>
> [how]
> The
Reviewed-by: Lyude Paul
On Tue, 2019-12-03 at 09:35 -0500, mikita.lip...@amd.com wrote:
> From: Mikita Lipski
>
> Whenever a connector on an MST network is attached, detached, or
> undergoes a modeset, the DSC configs for each stream on that
> topology will be recalculated. This can change
On Tue, 2019-12-03 at 09:35 -0500, mikita.lip...@amd.com wrote:
> From: Mikita Lipski
>
> [why]
> Whenever a connector on an MST network is changed or
> undergoes a modeset, the DSC configs for each stream on that
> topology will be recalculated. This can change their required
> bandwidth,
On Tue, 2019-12-03 at 09:35 -0500, mikita.lip...@amd.com wrote:
> 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
Nice! All I've got is a couple of typos I noticed and one question, this looks
great :)
On Tue, 2019-12-03 at 09:35 -0500, mikita.lip...@amd.com wrote:
> From: Mikita Lipski
>
> Adding a helper function to be called by
> drivers outside of DRM to enable DSC on
> the MST ports.
>
> Function is
This patch still needs to be rebased, and the selftests for the PBN
calculation that got added still need to be updated to reflect the changes for
dsc. The code for PBN calculation changed quite a bit upstream since this
series started.
On Tue, 2019-12-03 at 09:35 -0500, mikita.lip...@amd.com
On 2019-12-06 3:49 a.m., Christian König wrote:
> Am 06.12.19 um 05:32 schrieb Luben Tuikov:
>> This patch fixes the following warnings:
>> -Wformat=
>> -Wmaybe-uninitialized
>> -Wmisleading-indentation
>> -Wstringop-truncation
>> -Wunused-function
>> -Wunused-variable
>>
>> It also removes
On 2019-12-06 3:47 a.m., Christian König wrote:
> Am 06.12.19 um 09:03 schrieb Chen, Guchun:
>> [AMD Official Use Only - Internal Distribution Only]
>>
>>
>>
>> -Original Message-
>> From: amd-gfx On Behalf Of Luben
>> Tuikov
>> Sent: Friday, December 6, 2019 12:32 PM
>> To:
Hey Ma, attached a solution - it's just compiled as I still can't make
my XGMI setup work (with bridge connected only one device is visible to
the system while the other is not). Please try it on your system if you
have a chance.
Andrey
On 12/4/19 10:14 PM, Ma, Le wrote:
AFAIK it's enough
- Original Message -
> From: "Michel Dänzer"
> To: "Timothy Pearson" , "Harry Wentland"
>
> Cc: "Zhan Liu" , "amd-gfx"
> Sent: Friday, December 6, 2019 10:12:42 AM
> Subject: Re: amdgpu: Enable full DCN support on POWER
> On 2019-12-06 12:34 a.m., Timothy Pearson wrote:
>>> From:
[AMD Official Use Only - Internal Distribution Only]
Hi All:
I just checked the CI report
https://patchwork.freedesktop.org/series/70530/. The failures described in
there are not quite related to my patch. Seems it is a false-positive. Does
anyone know something about the issue described
On Fri, 2019-12-06 at 14:24 -0500, Lyude Paul wrote:
> Reviewed-by: Lyude Paul
>
> I'll go ahead and push this to drm-misc-next-fixes right now, thanks!
Whoops-meant to say drm-misc-next here, anyway, pushed!
>
> On Thu, 2019-12-05 at 17:00 +0800, Wayne Lin wrote:
> > [Why]
> >
> > This patch
Am 06.12.19 um 18:33 schrieb Nirmoy Das:
entity should not keep copy and maintain sched list for
itself.
That is a good step, but we need to take this further.
The sched_list is static for the whole device and we shouldn't allocate
it inside the context at all.
Christian.
Signed-off-by:
Am 06.12.19 um 18:33 schrieb Nirmoy Das:
Currently we pre-allocate entities for all the HW IPs on
context creation and some of which are might never be used.
This patch tries to resolve entity wastage by creating entities
for a HW IP only when it is required.
Please delay that until we have
Am 06.12.19 um 18:33 schrieb Nirmoy Das:
drm_sched_entity_init() takes drm gpu scheduler list instead of
drm_sched_rq list. This makes conversion of drm_sched_rq list
to drm gpu scheduler list unnecessary
Signed-off-by: Nirmoy Das
Reviewed-by: Christian König
---
Reviewed-by: Lyude Paul
I'll go ahead and push this to drm-misc-next-fixes right now, thanks!
On Thu, 2019-12-05 at 17:00 +0800, Wayne Lin wrote:
> [Why]
>
> This patch is trying to address the issue observed when hotplug DP
> daisy chain monitors.
>
> e.g.
> src-mstb-mstb-sst -> src (unplug)
[AMD Official Use Only - Internal Distribution Only]
Thanks, Hawking.
--Zhigang
-Original Message-
From: Zhang, Hawking
Sent: December 6, 2019 12:35 PM
To: Luo, Zhigang ; Alex Deucher
Cc: Quan, Evan ; Yuan, Xiaojie ;
amd-gfx@lists.freedesktop.org
Subject: RE: [PATCH]
entity should not keep copy and maintain sched list for
itself.
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 11 ---
drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.h | 1 +
drivers/gpu/drm/scheduler/sched_entity.c | 12 +---
3 files changed, 10
Currently we pre-allocate entities for all the HW IPs on
context creation and some of which are might never be used.
This patch tries to resolve entity wastage by creating entities
for a HW IP only when it is required.
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 176
Entity currently keeps a copy of run_queue list and modify it in
drm_sched_entity_set_priority(). Entities shouldn't modify run_queue
list. Use drm_gpu_scheduler list instead of drm_sched_rq list
in drm_sched_entity struct. In this way we can select a runqueue based
on entity/ctx's priority for a
drm_sched_entity_init() takes drm gpu scheduler list instead of
drm_sched_rq list. This makes conversion of drm_sched_rq list
to drm gpu scheduler list unnecessary
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 11
It was used to indicate whether bios or driver to handle display mode for
various display type. And also some field to indicate other display status like
docking/undocking, LID open/close, etc.
Check atombios_encoder.c for its major usage
Regards,
Hawking
-Original Message-
From:
On 2019-12-05 8:58 a.m., Rodrigo Siqueira wrote:
> FEC is supported since DP 1.4, and it was expanded for LT-tunable in DP
> 1.4a. This commit adds the address registers for
> FEC_ERROR_COUNT_PHY_REPEATER1 and FEC_CAPABILITY_PHY_REPEATER1.
>
> Cc: Abdoulaye Berthe
> Cc: Harry Wentland
> Cc: Leo
[AMD Official Use Only - Internal Distribution Only]
Thanks, Alex.
> > This was reported by Zhigang team. Under their special use case, scratch
> > register 7 has be to 0 to perform asic init(@Luo, Zhigang right?).
Yes, sriov driver use this register to detect if asic init performed or not.
On 2019-12-06 12:34 a.m., Timothy Pearson wrote:
>> From: "Harry Wentland" On 2019-12-05 6:02 p.m.,
>> Liu, Zhan wrote:
From: amd-gfx On Behalf
Of Timothy Pearson
diff --git a/drivers/gpu/drm/amd/display/dc/Makefile
b/drivers/gpu/drm/amd/display/dc/Makefile index
The WARN stack trace after GPU reset kicks in points to not the latest
code - can you please try running the same with kernel at the tip of
https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-drm-next ?
Andrey
On 12/5/19 6:14 PM, Christian Pernegger wrote:
Hello,
one of my
On Fri, Dec 6, 2019 at 10:37 AM Luo, Zhigang wrote:
>
> [AMD Official Use Only - Internal Distribution Only]
>
> Can someone tell me what's BIOS_SCRATCH_6 used for? I know BIOS_SCRATCH_7 is
> used for asic init.
ATOM_S6_CRITICAL_STATE and ATOM_S6_ACC_MODE. See the other S6 defines
in
[AMD Official Use Only - Internal Distribution Only]
Can someone tell me what's BIOS_SCRATCH_6 used for? I know BIOS_SCRATCH_7 is
used for asic init.
Thanks,
Zhigang
-Original Message-
From: Zhang, Hawking
Sent: December 6, 2019 9:22 AM
To: Alex Deucher
Cc: Quan, Evan ; Yuan,
This reverts commit a4840d91c984f93b2acdcd1d624bbc1af0d2.
Reverting due to power efficiency issues seen on Raven 1 and 2
when DPG mode is enabled.
Signed-off-by: Thong Thai
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/soc15.c | 8 ++--
1 file changed, 2 insertions(+), 6
Ah yes, I made a logical mistake. This should work.
Regards,
Hawking
-Original Message-
From: Alex Deucher
Sent: 2019年12月6日 22:01
To: Zhang, Hawking
Cc: Quan, Evan ; Yuan, Xiaojie ; Luo,
Zhigang ; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amd/powerplay: clear VBIOS
On Fri, Dec 6, 2019 at 3:14 AM Zhang, Hawking wrote:
>
> Correct my typo
>
> This is in high risk to break gpu resume and reset just because you clear the
> ATOM_S7_ASIC_INIT_COMPLETE_MASK field in scratch register 7. And the
> atom_bios init will be skipped.
>
I think we should be ok. If
On Thu, Dec 5, 2019 at 10:36 PM Evan Quan wrote:
>
> This is needed for coming asic init on performing gpu reset.
>
> Change-Id: If3671a24d239e3d288665fadaa2c40c87d5da40b
> Signed-off-by: Evan Quan
> ---
> drivers/gpu/drm/amd/powerplay/smu_v11_0.c | 6 ++
> 1 file changed, 6 insertions(+)
>
Am Fr., 6. Dez. 2019 um 02:43 Uhr schrieb Liu, Zhan :
> I've seen a few people reported this issue on Freedesktop/Bugzilla. For
> example:
> https://bugs.freedesktop.org/show_bug.cgi?id=24.
Yes, there's also https://bugs.freedesktop.org/show_bug.cgi?id=109955.
To be honest, I couldn't say if
this fix the regression caused by asd/ta loading sequence
adjustment recently. asd/ta loading was move out from
hw_start and should also be applied to psp_resume.
otherwise those fw loading will be ignored in resume phase.
v2: add the mutex unlock for asd loading failure case
v3: merge the error
[AMD Official Use Only - Internal Distribution Only]
Reviewed-by: Guchun Chen
Regards,
Guchun
-Original Message-
From: Hawking Zhang
Sent: Friday, December 6, 2019 6:12 PM
To: amd-gfx@lists.freedesktop.org; Ma, Le ; Clements, John
; Deucher, Alexander ; Chen,
Guchun
Cc: Zhang,
[AMD Official Use Only - Internal Distribution Only]
Reviewed-by: Le Ma
Regards,
Ma Le
-Original Message-
From: Hawking Zhang
Sent: Friday, December 6, 2019 6:12 PM
To: amd-gfx@lists.freedesktop.org; Ma, Le ; Clements, John
; Deucher, Alexander ; Chen,
Guchun
Cc: Zhang, Hawking
I'm fine with it. Please check v3
Regards,
Hawking
-Original Message-
From: Chen, Guchun
Sent: 2019年12月6日 17:52
To: Zhang, Hawking ; amd-gfx@lists.freedesktop.org; Ma,
Le ; Clements, John ; Deucher, Alexander
Cc: Zhang, Hawking
Subject: RE: [PATCH] drm/amdgpu: fix resume failures
[AMD Public Use]
I recommend we use the existing "goto failed" for psp load failure case,
instead of adding one new mutex unlock before returning.
This will help reduce redundant code, and moreover, there is one error print "
PSP resume failed " in "failed" route, which may be captured for
Good point. Please check v2.
Regards,
Hawking
-Original Message-
From: Chen, Guchun
Sent: 2019年12月6日 17:04
To: Zhang, Hawking ; amd-gfx@lists.freedesktop.org; Ma,
Le ; Clements, John ; Deucher, Alexander
Cc: Zhang, Hawking
Subject: RE: [PATCH] drm/amdgpu: fix resume failures casued
this fix the regression caused by asd/ta loading sequence
adjustment recently. asd/ta loading was move out from hw_start
and should also be applied to psp_resume. otherwise those fw
loading will be ignored in resume phase.
Change-Id: I678f82b5dd552d70435bfdbd010c4ed8536314c9
Signed-off-by:
[AMD Public Use]
Regards,
Guchun
-Original Message-
From: amd-gfx On Behalf Of Hawking Zhang
Sent: Friday, December 6, 2019 5:00 PM
To: amd-gfx@lists.freedesktop.org; Ma, Le ; Clements, John
; Deucher, Alexander
Cc: Zhang, Hawking
Subject: [PATCH] drm/amdgpu: fix resume failures
this fix the regression caused by asd/ta loading sequence
adjustment recently. asd/ta loading was move out from hw_start
and should also be applied to psp_resume. otherwise those fw
loading will be ignored in resume phase.
Change-Id: I57010bc7ddf71ac46d3fb544d27932664190cf04
Signed-off-by:
Am 06.12.19 um 05:32 schrieb Luben Tuikov:
This patch fixes the following warnings:
-Wformat=
-Wmaybe-uninitialized
-Wmisleading-indentation
-Wstringop-truncation
-Wunused-function
-Wunused-variable
It also removes forward declarations and moves
global functions to the bottom, keeping locals
at
Am 06.12.19 um 09:03 schrieb Chen, Guchun:
[AMD Official Use Only - Internal Distribution Only]
-Original Message-
From: amd-gfx On Behalf Of Luben Tuikov
Sent: Friday, December 6, 2019 12:32 PM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Tuikov, Luben
; Koenig,
[Why]
When change the connection status in a MST topology, mst device
which detect the event will send out CONNECTION_STATUS_NOTIFY messgae.
e.g. src-mst-mst-sst => src-mst (unplug) mst-sst
Currently, under the above case of unplugging device, ports which have
been allocated payloads and are no
Correct my typo
This is in high risk to break gpu resume and reset just because you clear the
ATOM_S7_ASIC_INIT_COMPLETE_MASK field in scratch register 7. And the atom_bios
init will be skipped.
Regards,
Hawking
-Original Message-
From: amd-gfx On Behalf Of Zhang,
Hawking
Sent:
This is in high risk to break secondary gpu resume and reset just because you
clear the ATOM_S7_ASIC_INIT_COMPLETE_MASK field in scratch register 7. And the
atom_bios init will be skipped.
We shall understand any libgv fixes very well before "copy" it to bare-metal.
Libgv don't need to take
[AMD Official Use Only - Internal Distribution Only]
-Original Message-
From: amd-gfx On Behalf Of Luben Tuikov
Sent: Friday, December 6, 2019 12:32 PM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Tuikov, Luben
; Koenig, Christian
Subject: [PATCH 2/3] tests/amdgpu: Fix
49 matches
Mail list logo
