On 3/10/2023 12:00 PM, S, Shirish wrote:
On 3/8/2023 11:52 PM, Hamza Mahfooz wrote:
On 3/8/23 02:10, Shirish S wrote:
[Why]
Currently there aren't any methods to determine PSR state residency.
[How]
create a sysfs entry for reading residency and internally hook it up
to exi
On 3/8/2023 11:52 PM, Hamza Mahfooz wrote:
On 3/8/23 02:10, Shirish S wrote:
[Why]
Currently there aren't any methods to determine PSR state residency.
[How]
create a sysfs entry for reading residency and internally hook it up
to existing functionality of reading PSR residency from firmware.
On 10/6/2022 10:51 PM, Leo Li wrote:
On 2022-10-06 03:46, S, Shirish wrote:
On 10/6/2022 4:33 AM, Leo Li wrote:
On 2022-10-03 11:26, S, Shirish wrote:
Ping!
Regards,
Shirish S
On 9/30/2022 7:17 PM, S, Shirish wrote:
On 9/30/2022 6:59 PM, Harry Wentland wrote:
+Leo
On 9/30/22
On 10/6/2022 4:33 AM, Leo Li wrote:
On 2022-10-03 11:26, S, Shirish wrote:
Ping!
Regards,
Shirish S
On 9/30/2022 7:17 PM, S, Shirish wrote:
On 9/30/2022 6:59 PM, Harry Wentland wrote:
+Leo
On 9/30/22 06:27, Shirish S wrote:
[Why]
psr feature continues to be enabled for non capable
Ping!
Regards,
Shirish S
On 9/30/2022 7:17 PM, S, Shirish wrote:
On 9/30/2022 6:59 PM, Harry Wentland wrote:
+Leo
On 9/30/22 06:27, Shirish S wrote:
[Why]
psr feature continues to be enabled for non capable links.
Do you have more info on what issues you're seeing with this?
On 9/30/2022 6:59 PM, Harry Wentland wrote:
+Leo
On 9/30/22 06:27, Shirish S wrote:
[Why]
psr feature continues to be enabled for non capable links.
Do you have more info on what issues you're seeing with this?
Code wise without this change we end up setting
"vblank_disable_immediate" par
[AMD Official Use Only]
Ping!
Regards,
Shirish S
-Original Message-
From: S, Shirish
Sent: Monday, March 14, 2022 12:24 PM
To: Wentland, Harry ; S, Shirish ;
Wentland, Harry ; Kazlauskas, Nicholas
; Lakha, Bhawanpreet
Cc: amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] amd
On 3/11/2022 9:11 PM, Harry Wentland wrote:
On 3/11/22 10:33, Shirish S wrote:
[Why]
comparing pwm bl values (coverted) with user brightness(converted)
levels in commit_tail leads to continuous setting of backlight via dmub
as they don't to match.
Why do the values not match?
Here is a sam
Hi Shashank,
On 1/12/2022 6:30 PM, Sharma, Shashank wrote:
On 1/11/2022 12:26 PM, Christian König wrote:
Am 11.01.22 um 08:12 schrieb Somalapuram Amaranath:
AMDGPURESET uevent added to notify userspace,
collect dump_stack and amdgpu_reset_reg_dumps
Signed-off-by: Somalapuram Amaranath
---
On 11/8/2021 8:27 PM, Harry Wentland wrote:
On 2021-11-08 06:23, Christian König wrote:
Am 08.11.21 um 12:13 schrieb S, Shirish:
Hi Paul,
On 11/8/2021 2:27 PM, Paul Menzel wrote:
Dear Shrish,
Am 08.11.21 um 09:40 schrieb Shirish S:
update user with next level of info about which
Hi Paul,
On 11/8/2021 7:51 PM, Paul Menzel wrote:
[Which address should be used: sshan...@amd.com or shiris...@amd.com?]
"shiris...@amd.com"
Dear Shirish,
Am 08.11.21 um 12:11 schrieb S, Shirish:
On 11/8/2021 2:25 PM, Paul Menzel wrote:
Am 08.11.21 um 09:15 schrieb Shirish
Hi Paul,
On 11/8/2021 2:27 PM, Paul Menzel wrote:
Dear Shrish,
Am 08.11.21 um 09:40 schrieb Shirish S:
update user with next level of info about which condition led to
atomic check failure.
Signed-off-by: Shirish S
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 70 ++-
Hi Paul,
On 11/8/2021 2:25 PM, Paul Menzel wrote:
Dear Shirish,
Am 08.11.21 um 09:15 schrieb Shirish S:
limit the MPO rejection only for DCN1x as its not required on later
it’s
versions.
Where is it documented, that it’s not required for later versions?
This is a workaround to avoid s
Tested-by: Shirish S
Regards,
Shirish S
-Original Message-
From: amd-gfx On Behalf Of Quan, Evan
Sent: Wednesday, March 10, 2021 1:11 PM
To: Deucher, Alexander ;
amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: RE: [PATCH] drm/amdgpu/powerplay/smu10: add support for gpu
Some basic nit-picks inline.
On 6/22/2020 7:34 AM, Chauhan, Ikshwaku wrote:
[AMD Official Use Only - Internal Distribution Only]
Hello All,
Could you please provide your feedback for this patch?
Regards,
Ikshwaku
-Original Message-
From: Chauhan, Ikshwaku
Sent: Wednesday, June 17, 2
On 10/30/2019 3:50 PM, Koenig, Christian wrote:
> Am 30.10.19 um 10:13 schrieb S, Shirish:
>> [Why]
>>
>> doing kthread_park()/unpark() from drm_sched_entity_fini
>> while GPU reset is in progress defeats all the purpose of
>> drm_sched_stop->kthre
[Why]
doing kthread_park()/unpark() from drm_sched_entity_fini
while GPU reset is in progress defeats all the purpose of
drm_sched_stop->kthread_park.
If drm_sched_entity_fini->kthread_unpark() happens AFTER
drm_sched_stop->kthread_park nothing prevents from another
(third) thread to keep submitti
On 10/25/2019 9:32 PM, Grodzovsky, Andrey wrote:
On 10/25/19 11:57 AM, Koenig, Christian wrote:
Am 25.10.19 um 17:35 schrieb Grodzovsky, Andrey:
On 10/25/19 5:26 AM, Koenig, Christian wrote:
Am 25.10.19 um 11:22 schrieb S, Shirish:
On 10/25/2019 2:23 PM, Koenig, Christian wrote
On 10/25/2019 2:56 PM, Koenig, Christian wrote:
Am 25.10.19 um 11:22 schrieb S, Shirish:
On 10/25/2019 2:23 PM, Koenig, Christian wrote:
amdgpu_do_asic_reset starting to resume blocks
...
amdgpu :03:00.0: couldn't schedule ib on ring
[drm:amdgpu_job_run] *ERROR* Error schedulin
, drm_sched_main() is responsible for this
job_run which seems to be called during cleanup.
Regards,
Shirish S
Regards,
Christian.
Am 25.10.19 um 10:50 schrieb S, Shirish:
Here is the call trace:
Call Trace:
dump_stack+0x4d/0x63
amdgpu_ib_schedule+0x86/0x4b7
? __mod_timer+0x21e/0x244
amdgp
tian König wrote:
Am 24.10.19 um 12:58 schrieb S, Shirish:
[Why]
Upon GPU reset, kernel cleans up already submitted jobs
via drm_sched_cleanup_jobs.
This schedules ib's via drm_sched_main()->run_job, leading to
race condition of rings being ready or not, since during reset
rings may be susp
[Why]
Upon GPU reset, kernel cleans up already submitted jobs
via drm_sched_cleanup_jobs.
This schedules ib's via drm_sched_main()->run_job, leading to
race condition of rings being ready or not, since during reset
rings may be suspended.
[How]
make GPU reset's amdgpu_device_ip_resume_phase2() &
a
The UPSTREAM tag in the commit message needs to be removed.
On 10/21/2019 1:24 PM, Louis Li wrote:
> [Why]
> External monitor cannot be displayed consistently, if connecting
> via this Apple dongle (A1621, USB Type-C to HDMI).
> By experiments, it is confirmed that the dongle needs 200ms at least
...@google.com; S, Shirish
; Zhou, David(ChunMing) ; Koenig,
Christian ; amd-gfx@lists.freedesktop.org;
linux-ker...@vger.kernel.org; Nick Desaulniers
Subject: [PATCH 1/3] drm/amdgpu: fix stack alignment ABI mismatch for Clang
The x86 kernel is compiled with an 8B stack alignment via
`-mpreferred-stack
Hi Nick,
On 10/15/2019 3:52 AM, Nick Desaulniers wrote:
Hello!
The x86 kernel is compiled with an 8B stack alignment via
`-mpreferred-stack-boundary=3` for GCC since 3.6-rc1 via
commit d9b0cde91c60 ("x86-64, gcc: Use
-mpreferred-stack-boundary=3 if supported")
or `-mstack-alignment=8
log the response status related error to the driver's
debug log since psp response status is not 0 even though
there was no problem while the command was submitted.
This warning misleads, hence this change.
Signed-off-by: Shirish S
---
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 2 +-
1 file cha
On 9/12/2019 3:29 AM, Kuehling, Felix wrote:
> On 2019-09-11 2:52 a.m., S, Shirish wrote:
>> If CONFIG_HSA_AMD is not set, build fails:
>>
>> drivers/gpu/drm/amd/amdgpu/amdgpu_device.o: In function
>> `amdgpu_device_ip_early_init':
>> drivers/gpu/drm/amd/
define sched_policy in case CONFIG_HSA_AMD is not
enabled, with this there is no need to check for CONFIG_HSA_AMD
else where in driver code.
Suggested-by: Felix Kuehling
Signed-off-by: Shirish S
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 2 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |
Agree, have sent V2.
My patch was actually in line to already up streamed patch:
https://lkml.org/lkml/2019/8/26/201
Regards,
Shirish S
-Original Message-
From: Kuehling, Felix
Sent: Wednesday, September 11, 2019 9:09 AM
To: Huang, Ray ; S, Shirish ; Deucher,
Alexander ; Koenig
If CONFIG_HSA_AMD is not set, build fails:
drivers/gpu/drm/amd/amdgpu/amdgpu_device.o: In function
`amdgpu_device_ip_early_init':
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1626: undefined reference to
`sched_policy'
Use CONFIG_HSA_AMD to guard this.
Fixes: 1abb680ad371 ("drm/amdgpu: disable g
If CONFIG_HSA_AMD is not set, build fails:
drivers/gpu/drm/amd/amdgpu/amdgpu_device.o: In function
`amdgpu_device_ip_early_init':
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1626: undefined reference to
`sched_policy'
Use CONFIG_HSA_AMD to guard this.
Fixes: 1abb680ad371 ("drm/amdgpu: disable g
Hi Alex,
On 6/4/2019 9:43 PM, Alex Deucher wrote:
> On Tue, Jun 4, 2019 at 12:07 PM S, Shirish wrote:
>> [What]
>> readptr read always returns zero, since most likely
>> UVD block is either power or clock gated.
>>
>> [How]
>> fetch rptr after amdgpu_
Thanks Christian.
Have sent the patch for uvd & vcn.
(https://patchwork.freedesktop.org/patch/308575/)
Regards,
Shirish S
-Original Message-
From: Christian König
Sent: Tuesday, June 4, 2019 4:38 PM
To: S, Shirish ; Deucher, Alexander
; Koenig, Christian ;
jerry.zh...@amd.com;
[What]
readptr read always returns zero, since most likely
UVD block is either power or clock gated.
[How]
fetch rptr after amdgpu_ring_alloc() which informs
the power management code that the block is about to be
used and hence the gating is turned off.
Signed-off-by: Louis Li
Signed-off-by: Sh
From: Louis Li
[What]
vce ring test fails consistently during resume in s3 cycle, due to
mismatch read & write pointers.
On debug/analysis its found that rptr to be compared is not being
correctly updated/read, which leads to this failure.
Below is the failure signature:
[drm:amdgpu_vce_r
From: Louis Li
[What]
vce ring test fails consistently during resume in s3 cycle, due to
mismatch read & write pointers.
On debug/analysis its found that rptr to be compared is not being
correctly updated/read, which leads to this failure.
Below is the failure signature:
[drm:amdgpu_vce_r
On 4/4/2019 8:58 PM, Alex Deucher wrote:
> On Thu, Apr 4, 2019 at 6:38 AM S, Shirish wrote:
>> Signed-off-by: Shirish S
> Please include a patch description. Why are you you making this change?
Was not aware of the debugfs entry, i wish to abandon this patch.
I shall get back wit
Signed-off-by: Shirish S
---
drivers/gpu/drm/amd/powerplay/smumgr/smu10_smumgr.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/smu10_smumgr.c
b/drivers/gpu/drm/amd/powerplay/smumgr/smu10_smumgr.c
index 6d11076a..373f384 100644
-
Please mail your query to
amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org> .
Regards,
Shirish S
From: shahul hameed
Sent: Wednesday, February 20, 2019 3:14 PM
To: S, Shirish
Subject: s2idle not working
Hi Shirish
I am porting Android_N and keenel 4.19.2 to
On 2/4/2019 9:00 PM, Liu, Leo wrote:
> On 2/4/19 7:49 AM, Koenig, Christian wrote:
>> Am 04.02.19 um 13:44 schrieb S, Shirish:
>>> vce ring test fails during resume since mmVCE_RB_RPTR*
>>> is not intitalized/updated.
>>>
>>> Hence start vce block bef
vce ring test fails during resume since mmVCE_RB_RPTR*
is not intitalized/updated.
Hence start vce block before ring test.
Signed-off-by: Shirish S
---
* vce_v4_0.c's hw_init sequence already has this change.
drivers/gpu/drm/amd/amdgpu/vce_v3_0.c | 4
1 file changed, 4 insertions(+)
diff
[What]
FBC fails to get enabled when switched between LINEAR(console/VT)
and non-LINEAR(GUI) based rendering due to default value of
tiling info stored in the current_state which is used for deciding
whether or not to turn FBC on or off.
[How]
Use context structure's tiling information which is co
Initializing structures with { } is known to be problematic since
it doesn't necessararily initialize all bytes, in case of padding,
causing random failures when structures are memcmp().
This patch fixes the structure initialisation related compiler
error by memset().
V2: rectified missing peice
Initializing structures with { } is known to be problematic since
it doesn't necessararily initializes all bytes, in case of padding,
causing random failures when structures are memcmp().
This patch fixes the structure initialisation compiler error by memsetting
the entire structure elements inste
Initializing structures with { } is known to be problematic since
it doesn't necessararily initializes all bytes, in case of padding,
causing random failures when structures are memcmp().
This patch fixes the structure initialisation compiler error by memsetting
the entire structure elements inste
eucher, Alexander
Sent: Wednesday, November 28, 2018 12:06:26 AM
To: S, Shirish; Li, Sun peng (Leo); Wentland, Harry
Cc: amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amd/display: limit high pixel clock modes on ST/CZ
Is this a DP to HDMI adapter? I think 4k@60 should be valid on DP in g
However, while using Type-C connectors noted that the signal type is actually
SIGNAL_TYPE_DISPLAY_PORT and found that the check was missing.
Hence have added the same in https://patchwork.freedesktop.org/patch/264033/
Regards,
Shirish S
From: S, Shirish
Sent: Tuesday, November 27, 2018 9:54 AM
This patch extends the below patch to apply DP signal type, for exactly
the same reasons it was disabled for HDMI.
"1a0e348 drm/amd/display: Disable 4k 60 HDMI on DCE11"
Signed-off-by: Shirish S
---
drivers/gpu/drm/amd/display/dc/dce/dce_link_encoder.c | 4
1 file changed, 4 insertions(+)
Thanks Alex, found that patch.
My patch is no more required.
Regards,
Shirish S
From: Deucher, Alexander
Sent: Monday, November 26, 2018 7:46 PM
To: S, Shirish ; Li, Sun peng (Leo) ;
Wentland, Harry
Cc: amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amd/display: limit high pixel
[Why]
ST/CZ (dce110) advertises modes such as 4k@60Hz etc.,
that it cannot handle correctly, hence resulting in
several issues like flickering, black lines/flashes and so on.
[How]
These modes are basically high pixel clock ones, hence
limit the same to be advertised to avoid bad user experiences
From: Daniel Kurtz
This patch refactors smu8_send_msg_to_smc_with_parameter() to include
smu8_send_msg_to_smc_async() so that all the messages sent to SMU can be
profiled and appropriately reported if they fail.
Signed-off-by: Daniel Kurtz
Signed-off-by: Shirish S
---
drivers/gpu/drm/amd/powe
From: Daniel Kurtz
This patch refactors smu8_send_msg_to_smc_with_parameter() to include
smu8_send_msg_to_smc_async() so that all the messages sent to SMU can be
profiled and appropriately reported if they fail.
Signed-off-by: Daniel Kurtz
Signed-off-by: Shirish S
---
drivers/gpu/drm/amd/powe
This patch prints the version of SMU firmware.
Signed-off-by: Shirish S
---
drivers/gpu/drm/amd/powerplay/smumgr/smu8_smumgr.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/smu8_smumgr.c
b/drivers/gpu/drm/amd/powerplay/smumgr/smu8_smumgr.c
index 09
Currently send_msg_to_smc_async() only report which message
failed, but the actual failing message is the previous one,
which SMU is unable to service.
This patch reads the contents of register where the SMU is stuck
and report appropriately.
Signed-off-by: Shirish S
---
drivers/gpu/drm/amd/pow
This reverts commit dbd8299c32f6f413f6cfe322fe0308f3cfc577e8.
Reason for revert:
This patch sends msg PPSMC_MSG_DisableLowMemoryPstate(0x002e)
in wrong of sequence to SMU which is before PPSMC_MSG_UVDPowerON (0x0008).
This leads to SMU failing to service the request as it is
dependent on UVD to b
Yes.
Is there any dependant patches?
Regards,
Shirish S
From: Zhu, Rex
Sent: Tuesday, October 16, 2018 12:29 PM
To: S, Shirish ; Deucher, Alexander
; amd-gfx@lists.freedesktop.org
Subject: RE: [PATCH] drm/amdgpu: Poweroff uvd/vce/vcn/acp block if they were
disabled by user
The code base is
Nope, I have just cherry-picked this patch.
Is there any dependency?
Regards,
Shirish S
From: Zhu, Rex
Sent: Tuesday, October 16, 2018 12:15 PM
To: S, Shirish ; Deucher, Alexander
; amd-gfx@lists.freedesktop.org
Subject: RE: [PATCH] drm/amdgpu: Poweroff uvd/vce/vcn/acp block if they were
This patch fails on the very first resume as below:
[ 53.632732] [drm:vce_v3_0_set_powergating_state] *ERROR* VCE not responding,
trying to reset the ECPU!!!
[ 54.653212] [drm:vce_v3_0_set_powergating_state] *ERROR* VCE not responding,
trying to reset the ECPU!!!
[ 55.673692] [drm:vce_v3_0_
On 10/4/2018 12:41 PM, Christian König wrote:
Am 03.10.2018 um 17:15 schrieb Shirish S:
From: Pratik Vishwakarma
[Why]
1. We never submit IBs to KIQ.
2. Ring test pass without KIQ's ring also.
3. By skipping we see an improvement of around 500ms
in the amdgpu's resume time.
[How]
skip I
This workaround is not fixing the issue.
Regards,
Shirish S
-Original Message-
From: amd-gfx On Behalf Of Harry
Wentland
Sent: Friday, September 28, 2018 6:46 PM
To: amd-gfx@lists.freedesktop.org; S, Shirish ; Li, Sun peng
(Leo)
Cc: Wentland, Harry
Subject: [PATCH] drm/amd/display
.
Best Regards
Rex
*From:* S, Shirish
*Sent:* Friday, August 10, 2018 2:15 PM
*To:* Deucher, Alexander; Zhu, Rex; Liu, Leo
*Cc:* amd-gfx@lists.freedesktop.org; S, Shirish
*Subject:* [PATCH] drm/amdpu/vce_v3: skip suspend
Sure Michel, but not immediately.
Is that fine?
Regards,
Shirish S
-Original Message-
From: Michel Dänzer [mailto:mic...@daenzer.net]
Sent: Friday, July 20, 2018 1:04 PM
To: S, Shirish
Cc: amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdgpu: lock and unlock console only for
On 7/18/2018 3:30 PM, Michel Dänzer wrote:
On 2018-07-18 11:40 AM, Shirish S wrote:
[Why]
1. To ensure that resume path reciprocates the sequence followed during
suspend.
2. While the console_lock is held, console output will be buffered, till
its unlocked it wont be emitted, hence its ideal t
On 6/22/2018 9:19 AM, S, Shirish wrote:
On 6/22/2018 9:00 AM, Dave Airlie wrote:
On 31 May 2018 at 20:02, Shirish S wrote:
mutex's lead to sleeps which should be avoided in
atomic context.
Hence this patch replaces it with the spin_locks.
Below is the stack trace:
I'm not sur
On 6/22/2018 9:00 AM, Dave Airlie wrote:
On 31 May 2018 at 20:02, Shirish S wrote:
mutex's lead to sleeps which should be avoided in
atomic context.
Hence this patch replaces it with the spin_locks.
Below is the stack trace:
I'm not sure I really like this series of patches, going around
re
On 6/8/2018 1:08 PM, Christian König wrote:
Am 08.06.2018 um 07:23 schrieb zhoucm1:
On 2018年06月08日 12:54, Shirish S wrote:
This patch is extends the usage of WB in
gfx8's ib test which was originally
implemented in the below upstream patch:
"ed9324a drm/amdgpu: change gfx9 ib test to use WB
The V2 of this patch is already reviewed by Harry.
The change i have made in dc_create() is no more applicable.
Regards,
Shirish S
On 5/31/2018 11:35 PM, Christian König wrote:
Am 30.05.2018 um 18:03 schrieb Harry Wentland:
On 2018-05-30 06:17 AM, Shirish S wrote:
This patch fixes the warning
On 5/30/2018 9:33 PM, Harry Wentland wrote:
On 2018-05-30 06:17 AM, Shirish S wrote:
This patch fixes the warning messages that are caused due to calling
sleep in atomic context as below:
BUG: sleeping function called from invalid context at mm/slab.h:419
in_atomic(): 1, irqs_disabled(): 1, p
On 5/30/2018 9:10 PM, Christian König wrote:
Keep in mind that under SRIOV you can read registers while in atomic
context, e.g. while holding a spinlock.
Please double check if that won't bite us.
Apart from that the change looks good to me,
Thanks Christian, i verified boot, s3, s5 on Ston
On 5/30/2018 8:51 PM, Deucher, Alexander wrote:
-Original Message-
From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
Of Shirish S
Sent: Wednesday, May 30, 2018 6:20 AM
To: amd-gfx@lists.freedesktop.org; Wentland, Harry
; Zhu, Rex
Cc: S, Shirish
Subject: [PATCH
On 5/30/2018 8:51 PM, Deucher, Alexander wrote:
-Original Message-
From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
Of Shirish S
Sent: Wednesday, May 30, 2018 6:19 AM
To: amd-gfx@lists.freedesktop.org; Wentland, Harry
; Zhu, Rex
Cc: S, Shirish
Subject: [PATCH
On 5/4/2018 6:27 PM, Andrey Grodzovsky wrote:
On 05/03/2018 02:11 PM, Harry Wentland wrote:
On 2018-05-03 04:00 AM, S, Shirish wrote:
On 5/2/2018 7:21 PM, Harry Wentland wrote:
On 2018-04-27 06:27 AM, Shirish S wrote:
This patch is in continuation to the
"843e3c7 drm/amd/display:
On 5/2/2018 7:21 PM, Harry Wentland wrote:
On 2018-04-27 06:27 AM, Shirish S wrote:
This patch is in continuation to the
"843e3c7 drm/amd/display: defer modeset check in dm_update_planes_state"
where we started to eliminate the dependency on
DRM_MODE_ATOMIC_ALLOW_MODESET to be set by the user
On 5/2/2018 12:53 AM, Stéphane Marchesin wrote:
On Fri, Apr 27, 2018 at 3:27 AM Shirish S wrote:
This patch is in continuation to the
"843e3c7 drm/amd/display: defer modeset check in dm_update_planes_state"
where we started to eliminate the dependency on
DRM_MODE_ATOMIC_ALLOW_MODESET to be s
Thanks Harry, it works.
Patch is Reviewed-by: Shirish S
Regards,
Shirish S
-Original Message-
From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of Harry
Wentland
Sent: Tuesday, April 24, 2018 8:57 PM
To: amd-gfx@lists.freedesktop.org; S, Shirish ; Deucher
On 4/23/2018 9:53 AM, S, Shirish wrote:
On 4/20/2018 11:52 PM, Harry Wentland wrote:
On 2018-04-17 10:56 PM, Shirish S wrote:
Currently the dm_dp_aux_transfer() does not parse
the return value of dal_ddc_service_read_dpcd_data(), which also
has a failure case.
This patch captures the same
On 4/19/2018 8:08 PM, Harry Wentland wrote:
On 2018-04-19 03:43 AM, Michel Dänzer wrote:
[ Dropping stable@ (fixes with Cc: stable are picked up for stable
branches once they land in Linus' tree, there's no point sending them to
stable@ during review), adding dri-devel ]
On 2018-04-18 10:26 P
On 4/24/2018 8:19 AM, Huang Rui wrote:
"aaabaf4 drm/amdgpu: defer test IBs on the rings at boot (V3)"
Above patch defers the execution of gfx/compute ib tests. However, at that time,
the gfx may already go into idle state. If "idle" gfx receives command
submission, then will get hang in the s
On 4/20/2018 11:54 PM, Harry Wentland wrote:
On 2018-04-17 02:57 AM, Shirish S wrote:
The dp aux channel cannot read messages of size greater
than 16 bytes, this patch adds quirks feild accordingly
at the initialization of the adaptor.
Is this in response to a bug?
Yes, its in continuation to
On 4/20/2018 11:52 PM, Harry Wentland wrote:
On 2018-04-17 10:56 PM, Shirish S wrote:
Currently the dm_dp_aux_transfer() does not parse
the return value of dal_ddc_service_read_dpcd_data(), which also
has a failure case.
This patch captures the same and ensures the i2c operation status is
sent
On 4/13/2018 10:20 PM, Alex Deucher wrote:
On Fri, Apr 13, 2018 at 9:25 AM, Christian König
wrote:
Am 13.04.2018 um 10:31 schrieb Shirish S:
amdgpu_ib_ring_tests() runs test IB's on rings at boot
contributes to ~500 ms of amdgpu driver's boot time.
This patch defers it and ensures that its
On 4/13/2018 12:38 PM, Christian König wrote:
Am 13.04.2018 um 09:01 schrieb S, Shirish:
On 4/13/2018 11:53 AM, Christian König wrote:
Am 13.04.2018 um 06:07 schrieb Shirish S:
amdgpu_ib_ring_tests() runs test IB's on rings at boot
contributes to ~500 ms of amdgpu driver's
On 4/13/2018 11:53 AM, Christian König wrote:
Am 13.04.2018 um 06:07 schrieb Shirish S:
amdgpu_ib_ring_tests() runs test IB's on rings at boot
contributes to ~500 ms of amdgpu driver's boot time.
This patch defers it and adds a check to report
in amdgpu_info_ioctl() if it was scheduled or not
8 8:39 PM
To: Wentland, Harry
Cc: amd-gfx@lists.freedesktop.org; Deucher, Alexander
; S, Shirish
Subject: Re: [PATCH 2/2] Revert "drm/amd/display: disable CRTCs with NULL FB on
their primary plane (V2)"
On 2018-04-12 04:51 PM, Harry Wentland wrote:
> This seems to cause flicker
S, Shirish would like to recall the message, "[PATCH] drm/amdgpu: defer initing
UVD & VCE IP blocks".
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
- DRI
developers ; S, Shirish
Subject: Re: [PATCH] drm/atomic: Add new reverse iterator over all plane state
On Tue, Mar 6, 2018 at 5:52 AM, Vishwakarma, Pratik
wrote:
> Hi Daniel,
>
> I have checked make htmldocs on v2 of this patch. I have attached output
> drm-kms.html on that
From: Shirish S
Add reverse iterator for_each_oldnew_plane_in_state_reverse to compliment the
for_each_oldnew_plane_in_state way or reading plane states.
The plane states are required to be read in reverse order for amd drivers,
cause the z order convention followed in linux is opposite to how
From: Shirish S
The below commit
"drm/atomic: Try to preserve the crtc enabled state in drm_atomic_remove_fb, v2"
introduces a slight behavioral change to rmfb. Instead of disabling a crtc when
the primary plane is disabled, it now preserves it.
This change leads to BUG hit while performing
From: Shirish S
Add reverse iterator "for_each_oldnew_plane_in_state_reverse" to
complement "for_each_oldnew_plane_in_state" way of reading plane
states.
The plane states are required to be read in reverse order for
amdgpu, as the z order convention followed in linux is
opposite to how the plane
From: Shirish S
Currently all cursor related functions are made to all pipes that are attached
to a particular stream.
This is not applicable to pipes that do not have cursor plane initialised like
underlay.
Hence this patch allows cursor related operations on a pipe only if ipp in
available
From: Shirish S
The drm layer expects aux->transfer() to return the payload bytes read.
Currently dm_dp_aux_transfer() returns the payload size which does not gets
updated during the read, hence not giving the right data for the drm layer to
pars edid. This leads to the drm layer to conclude a
CC:arindam.n...@amd.com
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
From: Shirish S
The CGCG feature on Stoney is causing GFX related issues such as freezes
and blank outs.
Signed-off-by: Shirish S
---
drivers/gpu/drm/amd/amdgpu/vi.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c
b/drivers/gpu/drm/amd/amdgpu/vi.c index 3b66
From: Shirish S
Currently the atomic check code uses legacy_cursor_update to differnetiate if
the cursor plane is being requested by the user, which is not required as we
shall be updating plane only if modeset is requested/required.
Have tested cursor plane and underlay get updated seamlessl
From: Shirish S
While validation fbc, array_mode of the pipe is accessed without checking
plane_state exists for it.
Causing to null pointer dereferencing followed by reboot when a crtc associated
with external display(not
connected) is page flipped.
This patch adds a check for plane_state bef
From: Shirish S
Currently the atomic check code uses legacy_cursor_update to differnetiate if
the cursor plane is being requested by the user, which is not required as we
shall be updating plane only if modeset is requested/required.
Have tested cursor plane and underlay get updated seamlessly
Done, applied to amd-staging-drm-next.
Thanks.
Regards,
Shirish S
-Original Message-
From: Wentland, Harry
Sent: Tuesday, November 14, 2017 8:56 PM
To: S, Shirish ; amd-gfx@lists.freedesktop.org
Cc: Dan Carpenter
Subject: Re: [PATCH] drm/amd/display: fix static checker warning
On
Hi All,
I find the below WARN_ON() message while rendering on eDP in ST platform with
https://cgit.freedesktop.org/~airlied/linux/log/?h=drm-next-amd-dc-staging
branch:
WARNING kernel: [ 344.159552] WARNING: CPU: 1 PID: 899 at
/mnt/host/source/src/third_party/kernel/v4.12/drivers/gpu/drm/ttm/
From: Shirish S
This patch fixes static checker warning of
"warn: cast after binop" introduced by
56087b31 drm/amd/display: fix high part address in dm_plane_helper_prepare_fb()
Signed-off-by: Shirish S
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
1 file changed, 1 insertion(+
On 11/7/2017 2:06 PM, Michel Dänzer wrote:
> On 07/11/17 04:29 AM, S, Shirish wrote:
>> From: Shirish S
>>
>> This patch fixes static checker warning of
>> "warn: cast after binop" introduced by
>> 4d3e00dad80a: "drm/amd/display : add high part ad
1 - 100 of 124 matches
Mail list logo
