[AMD Public Use]
Sorry for spamming.
It's a duplicate one and should be ignored.
> -Original Message-
> From: Wayne Lin
> Sent: Tuesday, August 4, 2020 11:37 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Pillai, Aurabindo ; Wu, Hersen
> ; Kazlauskas, Nicholas
> ; Siqueira, Rodrigo
> ;
[Why]
According to DP spec, DPRX with DPCD r1.2 or higher shall have the
same Link/Sink Device Status field registers at DPCD Addresses 00200h
through 00205h to the corresponding DPRX Event Status Indicator
registers at DPCD Addresses 02002h through 0200Fh. We now only read from
02002h when DPCD
[Why]
Under DP daisy chain scenario as below:
Src - Monitor_1 - Monitor_2
If unplug 2nd Monitor_2 and plug in again, observe that Monitor_1
doesn't light up.
When unplug 2nd monitor, we clear the
dc_link->cur_link_settings.lane_count in dm_dp_destroy_mst_connector().
However this link
[Why]
Under DP daisy chain scenario as below:
Src - Monitor_1 - Monitor_2
If unplug 2nd Monitor_2 and plug in again, observe that Monitor_1
doesn't light up.
When unplug 2nd monitor, we clear the
dc_link->cur_link_settings.lane_count in dm_dp_destroy_mst_connector().
However this link
On 8/3/20 8:12 AM, Andy Lutomirski wrote:
> I could easily be convinced that the PASID fixup is so trivial and so
> obviously free of misfiring in a way that causes an infinite loop that
> this code is fine. But I think we first need to answer the bigger
> question of why we're doing a lazy fixup
On Mon, Aug 03, 2020 at 08:12:18AM -0700, Andy Lutomirski wrote:
> On Mon, Aug 3, 2020 at 8:03 AM Dave Hansen wrote:
> >
> > On 7/31/20 4:34 PM, Andy Lutomirski wrote:
> > >> Thomas suggested to provide a reason for the #GP caused by executing
> > >> ENQCMD
> > >> without a valid PASID value
On 8/3/20 10:16 AM, Andy Lutomirski wrote:
> - TILE: genuinely per-thread, but it's expensive so it's
> lazy-loadable. But the lazy-load mechanism reuses #NM, and it's not
> fully disambiguated from the other use of #NM. So it sort of works,
> but it's gross.
For those playing along at home,
Hi, Andy,
On Fri, Jul 31, 2020 at 06:28:37PM -0700, Andy Lutomirski wrote:
> On Mon, Jul 13, 2020 at 4:48 PM Fenghua Yu wrote:
> >
> > A #GP fault is generated when ENQCMD instruction is executed without
> > a valid PASID value programmed in the current thread's PASID MSR. The
> > #GP fault
On 7/31/20 4:34 PM, Andy Lutomirski wrote:
>> Thomas suggested to provide a reason for the #GP caused by executing ENQCMD
>> without a valid PASID value programmed. #GP error codes are 16 bits and all
>> 16 bits are taken. Refer to SDM Vol 3, Chapter 16.13 for details. The other
>> choice was to
On Mon, Aug 3, 2020 at 9:37 AM Dave Hansen wrote:
>
> On 8/3/20 8:12 AM, Andy Lutomirski wrote:
> > I could easily be convinced that the PASID fixup is so trivial and so
> > obviously free of misfiring in a way that causes an infinite loop that
> > this code is fine. But I think we first need to
Hi Evan,
Thanks for the work. It would have taken me probably forever to find that.
I replied to your series with a Tested-by, and I tested locally. With
edad8312cbbf9a33c86873fc4093664f150dd5c1 reverted to fix the sysfs
interfaces, and your series, I once again have a 100% working OD system!
Thanks Evan! I can confirm that this resolved the following GitLab
issue. Thanks for CC'ing me!
https://gitlab.freedesktop.org/drm/amd/-/issues/1243
Series is Tested-by: Matt Coffin
On 8/2/20 10:46 PM, Evan Quan wrote:
> As VCN related dpm table setup needs VCN be in PG ungate state. Same
On Mon, Aug 3, 2020 at 8:03 AM Dave Hansen wrote:
>
> On 7/31/20 4:34 PM, Andy Lutomirski wrote:
> >> Thomas suggested to provide a reason for the #GP caused by executing ENQCMD
> >> without a valid PASID value programmed. #GP error codes are 16 bits and all
> >> 16 bits are taken. Refer to SDM
The if statement wasn't indented so it's confusing.
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/amd/display/dc/core/dc_resource.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
Hi, Andy,
On Fri, Jul 31, 2020 at 04:34:11PM -0700, Andy Lutomirski wrote:
> On Mon, Jul 13, 2020 at 4:48 PM Fenghua Yu wrote:
> >
> > A #GP fault is generated when ENQCMD instruction is executed without
> > a valid PASID value programmed in the current thread's PASID MSR. The
> > #GP fault
On an error exit path, a negative error code should be returned
instead of a positive return value.
Fixes: 9e869063b0021 ("drm/amd/display: Move iteration out of dm_update_planes")
Cc: Leo Li
Signed-off-by: Tianjia Zhang
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 +--
1 file
On Thu, Jul 30, 2020 at 11:09 PM Luben Tuikov wrote:
> On 2020-07-29 9:49 a.m., Alex Deucher wrote:
> > On Wed, Jul 29, 2020 at 4:11 AM Christian König
> > wrote:
> >>
> >> Am 28.07.20 um 21:29 schrieb Peilin Ye:
> >>> Compiler leaves a 4-byte hole near the end of `dev_info`, causing
> >>>
Hello again,
I just finished a bisect of amd-staging-drm-next and it looks like
the hang is first introduced in edad8312cbbf9a33c86873fc4093664f150dd5c1
("drm/amdgpu: fix system hang issue during GPU reset").
It is a bit tricky, because it is commited on top of my first faulty patch
Hey Matt,
I have just tested the amd-staging-drm-next branch
(dd654c76d6e854afad716ded899e4404734aaa10) with my patches reverted
and I can reproduce your issue with:
sudo sh -c 'echo "s 0 305 750" >
/sys/class/drm/card0/device/pp_od_clk_voltage'
Which makes the sh hang with 100% usage.
The
[AMD Public Use]
Please put the check __is_ras_eeprom_supported behind the line
'*exceed_err_limit = false;' in function amdgpu_ras_eeprom_init and
amdgpu_ras_eeprom_check_err_threshold respectively. That promises, even when
eeprom is not available on several ASICs, exceed_err_limit must set
[AMD Public Use]
Submitting patch to with added device support check before trying to access RAS
EEPROM.
Thank you,
John Clements
0001-drm-amdgpu-added-RAS-EEPROM-device-support-check.patch
Description: 0001-drm-amdgpu-added-RAS-EEPROM-device-support-check.patch
[AMD Public Use]
Thank you Guchun!
From: Chen, Guchun
Sent: Monday, August 3, 2020 2:15 PM
To: Clements, John ; amd-gfx list
; Zhang, Hawking
Subject: RE: [PATCH] drm/amdgpu: enable RAS support for sienna
[AMD Public Use]
In patch subject, chip full name SIENNA_CICHLID is preferred.
With
[AMD Public Use]
In patch subject, chip full name SIENNA_CICHLID is preferred.
With above addressed, the patch is:
Reviewed-by: Guchun Chen
Regards,
Guchun
From: Clements, John
Sent: Monday, August 3, 2020 2:01 PM
To: amd-gfx list ; Zhang, Hawking
; Chen, Guchun
Subject: [PATCH]
[AMD Public Use]
Submitting patch to turn on GECC error injection /query support for sienna
cichilid.
Thank you,
John Clements
0001-drm-amdgpu-enable-RAS-support-for-sienna.patch
Description: 0001-drm-amdgpu-enable-RAS-support-for-sienna.patch
___
24 matches
Mail list logo
