You can't use PCI_BASE_CLASS with pci_get_class(). This
happens to work by luck on devices with PCI_CLASS_DISPLAY_VGA, but
misses PCI_CLASS_DISPLAY_OTHER. Add a check for those as well.
Signed-off-by: Alex Deucher
---
sound/pci/hda/hda_intel.c | 12 +++-
1 file changed, 11
This reverts commit f5fda6d89afe6e9cedaa1c3303903c905262f6e8.
You can't use BASE_CLASS in pci_get_class.
Bug: https://gitlab.freedesktop.org/drm/amd/issues/995
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c | 12 +++-
1 file changed, 11 insertions(+),
Mhh-I think I understand the problem you're trying to solve here but I think
this solution might be a bit overkill. When I did the rework of topology
references for ports, I made it so that we can guarantee memory access to a
port without it needing to be a valid part of the topology. As well, all
On 2019-12-20 6:50 p.m., Yong Zhao wrote:
Inline.
On 2019-12-20 4:35 p.m., Felix Kuehling wrote:
On 2019-12-20 1:24, Alex Sierra wrote:
[Why]
TLB flush method has been deprecated using kfd2kgd interface.
This implementation is now on the amdgpu_amdkfd API.
[How]
TLB flush functions now
On 2019-12-20 1:24 a.m., Alex Sierra wrote:
This can be used directly from amdgpu and amdkfd to invalidate
TLB through pasid.
It supports gmc v7, v8, v9 and v10.
Change-Id: I6563a8eba2e42d1a67fa2547156c20da41d1e490
Signed-off-by: Alex Sierra
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.h | 6
Inline.
On 2019-12-20 4:35 p.m., Felix Kuehling wrote:
On 2019-12-20 1:24, Alex Sierra wrote:
[Why]
TLB flush method has been deprecated using kfd2kgd interface.
This implementation is now on the amdgpu_amdkfd API.
[How]
TLB flush functions now implemented in amdgpu_amdkfd.
Change-Id:
One style comment inline.
Yong
On 2019-12-20 1:24 a.m., Alex Sierra wrote:
[Why]
Avoid reclaim filesystem while eviction lock is held called from
MMU notifier.
[How]
Setting PF_MEMALLOC_NOFS flags while eviction mutex is locked.
Using memalloc_nofs_save / memalloc_nofs_restore API.
On 2019-12-13 3:08 p.m., mikita.lip...@amd.com wrote:
> From: Mikita Lipski
>
> [why]
> Need to calculate VCPI slots differently for DSC
> to take in account current link rate, link count
> and FEC.
> [how]
> Add helper to get pbn_div from dc_link
>
> Cc: Harry Wentland
> Cc: Lyude Paul
>
I agree this patch is a big improvement , I think we need this patch so
SRIOV can put the amdkfd_pre_reset in right place as bare metal mode .
The further improvement can be in separate change .
This serial is reviewed by shaoyun.liu < shaoyun@amd.com>
Regards
shaoyun.liu
On
On 2019-12-20 10:27 a.m., Alex Deucher wrote:
> On Thu, Dec 19, 2019 at 9:00 PM Yin, Tianci (Rico) wrote:
>>
>> [AMD Official Use Only - Internal Distribution Only]
>>
>>
>> Hi Luben,
>>
>> May I have your Review-by?
>>
If you'd like--it's completely up to you. If you choose to, like Alex's
Reviewed-by: Lyude Paul
On Fri, 2019-12-13 at 15:08 -0500, mikita.lip...@amd.com wrote:
> From: Mikita Lipski
>
> [why]
> For DSC case we cannot use topology manager's PBN divider
> variable. The default divider does not take FEC into account.
> Therefore the driver has to calculate its own
Acked-by: Lyude Paul
On Fri, 2019-12-13 at 15:08 -0500, mikita.lip...@amd.com wrote:
> From: Mikita Lipski
>
> [why]
> Need to calculate VCPI slots differently for DSC
> to take in account current link rate, link count
> and FEC.
> [how]
> Add helper to get pbn_div from dc_link
>
> Cc: Harry
Acked-by: Lyude Paul
On Fri, 2019-12-13 at 15:08 -0500, mikita.lip...@amd.com wrote:
> 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
>
So I reviewed this already but realized I made a very silly mistake, comments
down below:
On Fri, 2019-12-13 at 15:08 -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
I think this patch is just a proof of concept for now. It should not be
submitted because there are still some known locking issues that need to
be solved, and we don't have the code yet that handles the recoverable
page faults resulting from this.
Regards,
Felix
On 2019-12-20 1:24, Alex
On 2019-12-20 1:24, Alex Sierra wrote:
[Why]
kfd2kgd interface will be deprecated. This removal only covers TLB
invalidation for now. They have been replaced in amdgpu_amdkfd API.
[How]
TLB invalidate functions removed from the different amdkfd_gfx_v*
versions.
Change-Id:
On 2019-12-20 1:24, Alex Sierra wrote:
[Why]
Avoid reclaim filesystem while eviction lock is held called from
MMU notifier.
[How]
Setting PF_MEMALLOC_NOFS flags while eviction mutex is locked.
Using memalloc_nofs_save / memalloc_nofs_restore API.
Change-Id:
Actually, one comment on this that should be very simple to add
On Fri, 2019-12-13 at 15:08 -0500, mikita.lip...@amd.com wrote:
> 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.
On 2019-12-20 1:24, Alex Sierra wrote:
[Why]
TLB flush method has been deprecated using kfd2kgd interface.
This implementation is now on the amdgpu_amdkfd API.
[How]
TLB flush functions now implemented in amdgpu_amdkfd.
Change-Id: Ic51cccdfe6e71288d78da772b6e1b6ced72f8ef7
Signed-off-by: Alex
On 2019-12-20 1:24, Alex Sierra wrote:
This can be used directly from amdgpu and amdkfd to invalidate
TLB through pasid.
It supports gmc v7, v8, v9 and v10.
Two small corrections inline to make the behaviour between KIQ and
MMIO-based flushing consistent. Looks good otherwise.
Change-Id:
Fetch the sclk from the pptable if there is no specified sclk for
the board.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/powerplay/navi10_ppt.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/navi10_ppt.c
Add defined peak sclk for navi12 peak profile mode.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/powerplay/navi10_ppt.c | 3 +++
drivers/gpu/drm/amd/powerplay/navi10_ppt.h | 2 ++
2 files changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/amd/powerplay/navi10_ppt.c
Fetch the sclk from the pptable if there is no specified sclk for
the board.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/powerplay/navi10_ppt.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/navi10_ppt.c
On 2019-12-20 2:40 p.m., Zuo, Jerry wrote:
> Hi All:
>
> I got CI check failures. Among those, hdmi-hpd-fast seems related, but I
> am not sure why. Please take a brief review and help to determine if it is a
> real false-positive again.
>
It looks like the hdmi-hpd-fast failures are
On 2019-12-20 14:31, shaoyunl wrote:
Can we use the dqm_lock when we try to get the dqm->is_hw_hang and
dqm->is_resetting inside function kq_uninitialize ?
Spreading the DQM lock around is probably not a good idea. Then I'd
rather do more refactoring to move hqd_load and hqd_destroy out of
On Fri, Dec 20, 2019 at 10:10 AM Tom Anderson wrote:
>
> Ping. Is there any action required to get this landed?
Looks good to me, but I'd like to hear from the display guys.
Alex
>
> On Tue, Dec 10, 2019 at 10:59:24AM -0800, Tom Anderson wrote:
> > Friendly ping.
> >
> > On Mon, Dec 02, 2019
Hi All:
I got CI check failures. Among those, hdmi-hpd-fast seems related, but I am
not sure why. Please take a brief review and help to determine if it is a real
false-positive again.
Thanks a lot.
Regards,
Jerry
-Original Message-
From: Patchwork
Sent: December 9, 2019
On Fri, Dec 20, 2019 at 10:10 AM Ma Feng wrote:
>
> Fixes coccicheck warning:
>
> drivers/gpu/drm/amd/amdgpu/navi10_ih.c:113:5-8: Unneeded variable: "ret".
> Return "0" on line 182
>
> Reported-by: Hulk Robot
> Signed-off-by: Ma Feng
Applied. Thanks!
Alex
> ---
>
On Fri, Dec 20, 2019 at 10:10 AM Ma Feng wrote:
>
> Fixes coccicheck warning:
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1036:5-8: Unneeded variable:
> "ret". Return "0" on line 1079
>
> Reported-by: Hulk Robot
> Signed-off-by: Ma Feng
Applied. thanks!
Alex
> ---
>
Can we use the dqm_lock when we try to get the dqm->is_hw_hang and
dqm->is_resetting inside function kq_uninitialize ?
I think more closer we check the status to hqd_destroy it will be more
accurate . It does look better with this logic if the status are changed
after dqm unmap_queue call
On 2019-12-20 12:18, Zeng, Oak wrote:
[AMD Official Use Only - Internal Distribution Only]
With this improvement, it is still possible that two reset be scheduled. There
is a period of time after HWS hang and before kfd pre-reset is called, during
which, if a thread already passed the
Hi! I will try to review this patch today, must have gotten lost in the noise
On Fri, 2019-12-20 at 01:46 +, Lin, Wayne wrote:
> [AMD Official Use Only - Internal Distribution Only]
>
> Pinged.
> Hi, can someone help to review please.
>
> Thanks a lot.
>
> Regards,
> Wayne
>
>
[AMD Official Use Only - Internal Distribution Only]
I see. Thank you Felix for the explanation.
Regards,
Oak
-Original Message-
From: Kuehling, Felix
Sent: Friday, December 20, 2019 12:28 PM
To: Zeng, Oak ; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH 4/4] drm/amdkfd: Avoid
On 2019-12-20 12:22, Zeng, Oak wrote:
[AMD Official Use Only - Internal Distribution Only]
Regards,
Oak
-Original Message-
From: amd-gfx On Behalf Of Felix
Kuehling
Sent: Friday, December 20, 2019 3:30 AM
To: amd-gfx@lists.freedesktop.org
Subject: [PATCH 4/4] drm/amdkfd: Avoid
[AMD Official Use Only - Internal Distribution Only]
Regards,
Oak
-Original Message-
From: amd-gfx On Behalf Of Felix
Kuehling
Sent: Friday, December 20, 2019 3:30 AM
To: amd-gfx@lists.freedesktop.org
Subject: [PATCH 4/4] drm/amdkfd: Avoid hanging hardware in stop_cpsch
Don't use
[AMD Official Use Only - Internal Distribution Only]
With this improvement, it is still possible that two reset be scheduled. There
is a period of time after HWS hang and before kfd pre-reset is called, during
which, if a thread already passed the is_hws_hang check but was scheduled out,
then
dqm->is_hws_hang is protected by the DQM lock. kq_uninitialize runs
outside that lock protection. Therefore I opted to pass in the hanging
flag as a parameter. It also keeps the logic that decides all of that
inside the device queue manager, which I think is cleaner.
I was trying to clean
Looks like patch 2 is not related to this serial , but anyway .
Patch 1,2,3 are reviewed by shaoyunl
For patch 4 , is it possible we directly check dqm->is_hws_hang ||
dqm->is_resetting inside function kq_uninitialize. so we don't need
other interface change .
I think even Inside that
On Thu, Dec 19, 2019 at 9:00 PM Yin, Tianci (Rico) wrote:
>
> [AMD Official Use Only - Internal Distribution Only]
>
>
> Hi Luben,
>
> May I have your Review-by?
>
Series is:
Reviewed-by: Alex Deucher
> Thanks a lot!
> Rico
>
> From: Tuikov, Luben
> Sent:
Fixes coccicheck warning:
drivers/gpu/drm/amd/amdgpu/navi10_ih.c:113:5-8: Unneeded variable: "ret".
Return "0" on line 182
Reported-by: Hulk Robot
Signed-off-by: Ma Feng
---
drivers/gpu/drm/amd/amdgpu/navi10_ih.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git
Fixes coccicheck warning:
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1036:5-8: Unneeded variable: "ret".
Return "0" on line 1079
Reported-by: Hulk Robot
Signed-off-by: Ma Feng
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git
Hi,
The length of table->mc_reg_address is SMU7_DISCRETE_MC_REGISTER_ARRAY_SIZE.
In ci_set_mc_special_registers(), the boundary checking
here("if (j > SMU7_DISCRETE_MC_REGISTER_ARRAY_SIZE)") allows 'j' equal to
SMU7_DISCRETE_MC_REGISTER_ARRAY_SIZE which can easily cause the
From: Guchun Chen
[ Upstream commit 6e807535dae5dbbd53bcc5e81047a20bf5eb08ea ]
When security violation from new vbios happens, data fabric is
risky to stop working. So prevent the direct access to DF
mmFabricConfigAccessControl from the new vbios and onwards.
Signed-off-by: Guchun Chen
From: Pierre-Eric Pelloux-Prayer
[ Upstream commit bf26da927a1cd57c9deb2db29ae8cf276ba8b17b ]
The same workaround is used for gfx7.
Both PAL and Mesa use it for gfx8 too, so port this commit to
gfx_v8_0_ring_emit_fence_gfx.
Signed-off-by: Pierre-Eric Pelloux-Prayer
Reviewed-by: Alex Deucher
From: David Galiffi
[ Upstream commit a51d9f8fe756beac51ce26ef54195da00a260d13 ]
[Why]
In dc_link_is_dp_sink_present, if dal_ddc_open fails, then
dal_gpio_destroy_ddc is called, destroying pin_data and pin_clock. They
are created only on dc_construct, and next aux access will cause a panic.
From: "Leo (Hanghong) Ma"
[ Upstream commit 28fa24ad14e8f7d23c62283eaf9c79b4fd165c16 ]
[why]
DP spec requires 1000 symbols delay between the end of link training
and enabling FEC in the stream. Currently we are using 1 miliseconds
delay which is not accurate.
[how]
One lane RBR should have the
From: Eric Yang
[ Upstream commit 44ce6c3dc8479bb3ed68df13b502b0901675e7d6 ]
Value obtained from DV is not allowing 8k60 CTA mode with DSC to
pass, after checking real value being used in hw, find out that
correct value is 3600, which will allow that mode.
Signed-off-by: Eric Yang
From: Alex Deucher
[ Upstream commit 14891c316ca7e15d81dba78f30fb630e3f9ee2c9 ]
So the output is consistent with other asics.
Reviewed-by: Evan Quan
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/powerplay/arcturus_ppt.c | 5 +
1 file changed, 5
From: Nikola Cornij
[ Upstream commit a1fc44b609b4e9c0941f0e4a1fc69d367af5ab69 ]
[why]
On ASICs where number of DSCs is the same as OPPs there's no need
for DSC resource management. Mappping 1-to-1 fixes mode-set- or S3-
-related issues for such platforms.
[how]
Map DSC resources 1-to-1 to
From: Nikola Cornij
[ Upstream commit 87de6cb2f28153bc74d0a001ca099c29453e145f ]
[why]
During mode transition steer fifo could overflow. Quite often it
recovers by itself, but sometimes it doesn't.
[how]
Add steer fifo reset before unblanking the stream. Also add a short
delay when resetting
From: Guchun Chen
[ Upstream commit 6e807535dae5dbbd53bcc5e81047a20bf5eb08ea ]
When security violation from new vbios happens, data fabric is
risky to stop working. So prevent the direct access to DF
mmFabricConfigAccessControl from the new vbios and onwards.
Signed-off-by: Guchun Chen
From: David Galiffi
[ Upstream commit a51d9f8fe756beac51ce26ef54195da00a260d13 ]
[Why]
In dc_link_is_dp_sink_present, if dal_ddc_open fails, then
dal_gpio_destroy_ddc is called, destroying pin_data and pin_clock. They
are created only on dc_construct, and next aux access will cause a panic.
From: Pierre-Eric Pelloux-Prayer
[ Upstream commit bf26da927a1cd57c9deb2db29ae8cf276ba8b17b ]
The same workaround is used for gfx7.
Both PAL and Mesa use it for gfx8 too, so port this commit to
gfx_v8_0_ring_emit_fence_gfx.
Signed-off-by: Pierre-Eric Pelloux-Prayer
Reviewed-by: Alex Deucher
[AMD Official Use Only - Internal Distribution Only]
Reviewed-by: Emily Deng
Best wishes
Emily Deng
>-Original Message-
>From: amd-gfx On Behalf Of
>Frank.Min
>Sent: Thursday, December 19, 2019 7:44 PM
>To: amd-gfx@lists.freedesktop.org
>Cc: Min, Frank
>Subject: [PATCH 1/2]
[AMD Official Use Only - Internal Distribution Only]
Series Tested-by: Emily Deng on sriov environment with
vege10 about TDR-1, TDR-2 and TDR-3 test cases.
Best wishes
Emily Deng
>-Original Message-
>From: amd-gfx On Behalf Of Felix
>Kuehling
>Sent: Friday, December 20, 2019 4:30
Move HWS hand detection into unmap_queues_cpsch to catch hangs in all
cases. If this happens during a reset, don't schedule another reset
because the reset already in progress is expected to take care of it.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdkfd/kfd_device.c | 3
Reading from /sys/kernel/debug/kfd/hang_hws would cause a kernel
oops because we didn't implement a read callback. Set the permission
to write-only to prevent that.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdkfd/kfd_debugfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Don't use the HWS if it's known to be hanging. In a reset also
don't try to destroy the HIQ because that may hang on SRIOV if the
KIQ is unresponsive.
Signed-off-by: Felix Kuehling
---
.../gpu/drm/amd/amdkfd/kfd_device_queue_manager.c| 12
dqm->pipeline_mem wasn't used anywhere.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 1 -
drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h | 1 -
2 files changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
Okay
Can you send me the patch (in attachment) once you finished it, I need to
verify it on SRIOV
Thanks
_
Monk Liu|GPU Virtualization Team |AMD
-Original Message-
From: Kuehling, Felix
Sent: Friday, December 20, 2019 3:56 PM
To: Liu, Monk ;
60 matches
Mail list logo
