No need to have special handling for swSMU supported ASICs.
Change-Id: I49395bfc31b43b09bac78527cd8f08e8600749b3
Signed-off-by: Evan Quan
---
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c| 10 ++
drivers/gpu/drm/amd/pm/amdgpu_dpm.c | 5 ++-
drivers/gpu/drm/amd/pm/inc/amdgpu_smu.h | 4
Add "static" declarations for those APIs used internally.
Change-Id: I38bfa8a117b3056202935163935a867f03ebaefe
Signed-off-by: Evan Quan
---
drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/am
Correct the check for vblank short.
Change-Id: I0eb3a6bd95b7f6d97029772914154324c8ccd2c0
Signed-off-by: Evan Quan
---
drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c
b/d
[AMD Public Use]
Maybe we can have an API like is_hw_access_blocked(). So that we can put all
those checks below within it.
if (amdgpu_in_reset(adev))
return -EPERM;
+ if (adev->in_suspend && !adev->in_runpm)
+ return -EPERM;
Anyway, patch is reviewed-b
On 24/03/2021 22.26, Harry Wentland wrote:
>
>
> On 2021-03-24 5:13 p.m., Harry Wentland wrote:
>> +Nick, Bhawan
>>
>> On 2021-03-24 4:39 p.m., Alex Deucher wrote:
>>> On Tue, Mar 23, 2021 at 4:18 AM Thomas Lambertz
>>> wrote:
DMCUB_SCRATCH_0 sometimes contains 0xdeadbeef during ini
On 3/24/21 6:50 AM, Bhaskar Chowdhury wrote:
>
> s/miror/mirror/
> s/needind/needing/
>
> Signed-off-by: Bhaskar Chowdhury
> ---
> drivers/gpu/drm/radeon/r600_cs.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/r600_cs.c
> b/drivers/gpu/drm
On 14:48 Wed 24 Mar 2021, Randy Dunlap wrote:
On 3/24/21 6:50 AM, Bhaskar Chowdhury wrote:
s/miror/mirror/
s/needind/needing/
Signed-off-by: Bhaskar Chowdhury
---
drivers/gpu/drm/radeon/r600_cs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r
On 3/24/21 4:29 PM, Bhaskar Chowdhury wrote:
> s/miror/mirror/
> s/needind/needing/
> s/informations/information/
>
> Signed-off-by: Bhaskar Chowdhury
Acked-by: Randy Dunlap
Thanks.
> ---
> Changes from V1:
> Randy's finding incorporated ,i.e in one place,informations->information
> Adjus
s/miror/mirror/
s/needind/needing/
s/informations/information/
Signed-off-by: Bhaskar Chowdhury
---
Changes from V1:
Randy's finding incorporated ,i.e in one place,informations->information
Adjusted the subject line accordingly
drivers/gpu/drm/radeon/r600_cs.c | 6 +++---
1 file changed, 3
On 2021-03-24 5:13 p.m., Harry Wentland wrote:
+Nick, Bhawan
On 2021-03-24 4:39 p.m., Alex Deucher wrote:
On Tue, Mar 23, 2021 at 4:18 AM Thomas Lambertz
wrote:
DMCUB_SCRATCH_0 sometimes contains 0xdeadbeef during initialization.
If this is detected, return 0 instead. This prevents wrong b
The GPU is in the process of being shutdown. Spurious queries during
suspend and resume can put the SMU into a bad state. Runtime PM is
handled dynamically so we check if we are in non-runtime suspend.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/pm/amdgpu_pm.c | 98
+Nick, Bhawan
On 2021-03-24 4:39 p.m., Alex Deucher wrote:
On Tue, Mar 23, 2021 at 4:18 AM Thomas Lambertz wrote:
DMCUB_SCRATCH_0 sometimes contains 0xdeadbeef during initialization.
If this is detected, return 0 instead. This prevents wrong bit-flags
from being read.
The main impact of this
Hi Dave, Daniel,
Fixes for 5.12.
The following changes since commit d27ce83fa4baa5cb908a42e9878564cad6ea0eb3:
Merge tag 'du-fixes-20210316' of git://linuxtv.org/pinchartl/media into
drm-fixes (2021-03-22 13:49:55 +1000)
are available in the Git repository at:
https://gitlab.freedesktop.or
On Tue, Mar 23, 2021 at 4:18 AM Thomas Lambertz wrote:
>
> DMCUB_SCRATCH_0 sometimes contains 0xdeadbeef during initialization.
> If this is detected, return 0 instead. This prevents wrong bit-flags
> from being read.
>
> The main impact of this bug is in the status check loop in
> dmub_srv_wait_f
On Wed, Mar 17, 2021 at 11:25 AM Werner Sembach
wrote:
>
> When encoder validation of a display mode fails, retry with less bandwidth
> heavy YCbCr420 color mode, if available. This enables some HDMI 1.4 setups
> to support 4k60Hz output, which previously failed silently.
>
> On some setups, whil
From: Mark Yacoub
On initializing the framebuffer, call drm_any_plane_has_format to do a
check if the modifier is supported. drm_any_plane_has_format calls
dm_plane_format_mod_supported which is extended to validate that the
modifier is on the list of the plane's supported modifiers.
The bug was
On Wed, Mar 24, 2021 at 11:25 AM Daniel Stone wrote:
>
> Hi Mark,
>
> On Wed, 24 Mar 2021 at 14:58, Mark Yacoub wrote:
>>
>> So you mean it would make more sense to be more explicit in handling
>> DRM_FORMAT_MOD_INVALID as an incoming modifier (which will, just like
>> DRM_FORMAT_MOD_LINEAR, will
On Wed, Mar 24, 2021 at 01:07:44PM +0100, Christian König wrote:
>
>
> Am 24.03.21 um 13:01 schrieb Daniel Vetter:
> > On Wed, Mar 24, 2021 at 01:00:28PM +0100, Christian König wrote:
> > > Am 24.03.21 um 12:55 schrieb Daniel Vetter:
> > > > On Wed, Mar 24, 2021 at 11:19:13AM +0100, Thomas Hellst
[AMD Official Use Only - Internal Distribution Only]
Reviewed-by: Alex Deucher
From: Tuikov, Luben
Sent: Wednesday, March 24, 2021 1:11 AM
To: amd-gfx@lists.freedesktop.org
Cc: Tuikov, Luben ; Yang, Stanley ;
Deucher, Alexander
Subject: [PATCH] drm/amdgpu: Fix
[AMD Public Use]
Reviewed-by: Kent Russell
> -Original Message-
> From: amd-gfx On Behalf Of Philip Cox
> Sent: Wednesday, March 24, 2021 9:24 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Cox, Philip
> Subject: [PATCH] drm/amdgpu: Set amdgpu.noretry=1 for Arcturus
>
> Setting amdg
Hi Mark,
On Wed, 24 Mar 2021 at 14:58, Mark Yacoub wrote:
> So you mean it would make more sense to be more explicit in handling
> DRM_FORMAT_MOD_INVALID as an incoming modifier (which will, just like
> DRM_FORMAT_MOD_LINEAR, will return true in
> dm_plane_format_mod_supported)?
>
That's correc
On Wed, Mar 24, 2021 at 8:10 AM Daniel Stone wrote:
>
> On Wed, 24 Mar 2021 at 10:53, Bas Nieuwenhuizen
> wrote:
>>
>> On Wed, Mar 24, 2021 at 11:13 AM Michel Dänzer wrote:
>>>
>>> No modifier support does not imply linear. It's generally signalled via
>>> DRM_FORMAT_MOD_INVALID, which roughly
On Tue, 2021-03-23 at 14:04 +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> gcc warns about an sprintf() that uses the same buffer as source
> and destination, which is undefined behavior in C99:
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_securedisplay.c: In function
> 'amdgpu_securedisplay_de
On 24/03/2021 14.33, Arnd Bergmann wrote:
> On Tue, Mar 23, 2021 at 4:57 PM Rasmus Villemoes
> wrote:
>> On 23/03/2021 14.04, Arnd Bergmann wrote:
>>> if (securedisplay_cmd->status ==
>>> TA_SECUREDISPLAY_STATUS__SUCCESS) {
>>> + int pos = 0;
>>>
s/miror/mirror/
s/needind/needing/
Signed-off-by: Bhaskar Chowdhury
---
drivers/gpu/drm/radeon/r600_cs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600_cs.c b/drivers/gpu/drm/radeon/r600_cs.c
index 34b7c6f16479..aded1f2264e0 100644
--- a/dri
From: Arnd Bergmann
A previous fix I did left a rather complicated loop in
amdgpu_securedisplay_debugfs_write() for what could be expressed in a
simple sprintf, as Rasmus pointed out.
This drops the leading 0x for each byte, but is otherwise
much nicer.
Suggested-by: Rasmus Villemoes
Signed-of
On Tue, Mar 23, 2021 at 4:57 PM Rasmus Villemoes
wrote:
> On 23/03/2021 14.04, Arnd Bergmann wrote:
> > if (securedisplay_cmd->status ==
> > TA_SECUREDISPLAY_STATUS__SUCCESS) {
> > + int pos = 0;
> > memset(i2c_output
Setting amdgpu.noretry=1 as default for Arcturus.
Signed-off-by: Philip Cox
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
index 1e07c66676c2..b9d68fd2610c 100644
-
Use the generic sysfs_emit() function to take place of
snprintf/scnprintf, to avoid buffer overrun.
Tian Tao (2):
drm/amdgpu: Convert sysfs sprintf/snprintf family to sysfs_emit
drm/amd/pm: Convert sysfs sprintf/snprintf family to sysfs_emit
drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c | 2
Fix the following coccicheck warning:
drivers/gpu//drm/amd/amdgpu/amdgpu_ras.c:434:9-17: WARNING:
use scnprintf or sprintf
drivers/gpu//drm/amd/amdgpu/amdgpu_xgmi.c:220:8-16: WARNING:
use scnprintf or sprintf
drivers/gpu//drm/amd/amdgpu/amdgpu_xgmi.c:249:8-16: WARNING:
use scnprintf or sprintf
driv
Daniel,
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> This is a resend of the remaining patches.
>
> All of these patches have been sent before.
Are you still keen to 'hoover these up'?
Just leave the one that requires work and take the res
Fix the following coccicheck warning:
drivers/gpu/drm/amd/pm/amdgpu_pm.c:1940:8-16: WARNING:
use scnprintf or sprintf
drivers/gpu/drm/amd/pm/amdgpu_pm.c:1978:8-16: WARNING:
use scnprintf or sprintf
drivers/gpu/drm/amd/pm/amdgpu_pm.c:2022:8-16: WARNING:
use scnprintf or sprintf
drivers/gpu/drm/amd/p
On Wed, 24 Mar 2021 at 10:53, Bas Nieuwenhuizen
wrote:
> On Wed, Mar 24, 2021 at 11:13 AM Michel Dänzer wrote:
>
>> No modifier support does not imply linear. It's generally signalled via
>> DRM_FORMAT_MOD_INVALID, which roughly means "tiling is determined by driver
>> specific mechanisms".
>>
>
Am 24.03.21 um 13:01 schrieb Daniel Vetter:
On Wed, Mar 24, 2021 at 01:00:28PM +0100, Christian König wrote:
Am 24.03.21 um 12:55 schrieb Daniel Vetter:
On Wed, Mar 24, 2021 at 11:19:13AM +0100, Thomas Hellström (Intel) wrote:
On 3/23/21 4:45 PM, Christian König wrote:
Am 23.03.21 um 16:13
On Wed, Mar 24, 2021 at 01:00:28PM +0100, Christian König wrote:
> Am 24.03.21 um 12:55 schrieb Daniel Vetter:
> > On Wed, Mar 24, 2021 at 11:19:13AM +0100, Thomas Hellström (Intel) wrote:
> > > On 3/23/21 4:45 PM, Christian König wrote:
> > > > Am 23.03.21 um 16:13 schrieb Michal Hocko:
> > > > >
Am 24.03.21 um 12:55 schrieb Daniel Vetter:
On Wed, Mar 24, 2021 at 11:19:13AM +0100, Thomas Hellström (Intel) wrote:
On 3/23/21 4:45 PM, Christian König wrote:
Am 23.03.21 um 16:13 schrieb Michal Hocko:
On Tue 23-03-21 14:56:54, Christian König wrote:
Am 23.03.21 um 14:41 schrieb Michal Hock
On Wed, Mar 24, 2021 at 11:19:13AM +0100, Thomas Hellström (Intel) wrote:
>
> On 3/23/21 4:45 PM, Christian König wrote:
> > Am 23.03.21 um 16:13 schrieb Michal Hocko:
> > > On Tue 23-03-21 14:56:54, Christian König wrote:
> > > > Am 23.03.21 um 14:41 schrieb Michal Hocko:
> > > [...]
> > > > > An
On Wed, Mar 24, 2021 at 11:13 AM Michel Dänzer wrote:
> On 2021-03-23 4:32 p.m., Mark Yacoub wrote:
> > On Tue, Mar 23, 2021 at 11:02 AM Alex Deucher
> wrote:
> >>
> >> On Wed, Mar 10, 2021 at 11:15 AM Mark Yacoub
> wrote:
> >>>
> >>> From: Mark Yacoub
> >>>
> >>> On initializing the framebuff
On 3/23/21 4:45 PM, Christian König wrote:
Am 23.03.21 um 16:13 schrieb Michal Hocko:
On Tue 23-03-21 14:56:54, Christian König wrote:
Am 23.03.21 um 14:41 schrieb Michal Hocko:
[...]
Anyway, I am wondering whether the overall approach is sound. Why
don't
you simply use shmem as your backing
On 2021-03-23 4:32 p.m., Mark Yacoub wrote:
> On Tue, Mar 23, 2021 at 11:02 AM Alex Deucher wrote:
>>
>> On Wed, Mar 10, 2021 at 11:15 AM Mark Yacoub wrote:
>>>
>>> From: Mark Yacoub
>>>
>>> On initializing the framebuffer, call drm_any_plane_has_format to do a
>>> check if the modifier is suppo
Hello,
is the information which color mode is currently in used for a display (RGB,
YCbCr444, or YCbCr420) exposed to user space somewhere?
If no: Where would be the best place to put code to expose it to sysfs?
Thanks in advance,
Werner Sembach
__
Fix the following coccicheck warning:
drivers/gpu//drm/radeon/radeon_pm.c:521:9-17: WARNING: use scnprintf or
sprintf
drivers/gpu//drm/radeon/radeon_pm.c:475:8-16: WARNING: use scnprintf or
sprintf
drivers/gpu//drm/radeon/radeon_pm.c:418:8-16: WARNING: use scnprintf or
sprintf
drivers/gpu//drm/rade
Am 24.03.21 um 04:26 schrieb Pan, Xinhui:
[AMD Official Use Only - Internal Distribution Only]
I don’t think so. Start is offset here. We get the valid physical address from
pages_addr[offset] when we update mapping.
Good point, mhm need to take an even closer look at this then.
Btw, what i
43 matches
Mail list logo
