From: "Tianci.Yin"
There is a NULL pointer crash when DCN disabled on headless SKU.
On normal SKU, the variable adev->ddev.mode_config.funcs is
initialized in dm_hw_init(), and it is fine to access it in
amdgpu_device_resume(). But on headless SKU, DCN is disabled,
the funcs variable is not initi
Hi Dave, Daniel,
Updates for 5.11. This should merge pretty cleanly. I created a backmerge
branch[1] in case you run into any issues.
[1] https://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-5.11-backmerge
The following changes since commit f2fa07b39fafb2a5f49c71a504862c5efa57d03e:
drm
On Thu, 05 Nov 2020, Daniel Vetter wrote:
> On Thu, Nov 5, 2020 at 7:10 PM Lee Jones wrote:
> >
> > On Thu, 05 Nov 2020, Thierry Reding wrote:
> >
> > > On Thu, Nov 05, 2020 at 02:44:58PM +, Lee Jones wrote:
> > > > This set is part of a larger effort attempting to clean-up W=1
> > > > kernel
On Thu, 05 Nov 2020, Thierry Reding wrote:
> On Thu, Nov 05, 2020 at 02:44:58PM +, Lee Jones wrote:
> > This set is part of a larger effort attempting to clean-up W=1
> > kernel builds, which are currently overwhelmingly riddled with
> > niggly little warnings.
> >
> > There are 5000 warnings
On Thu, 05 Nov 2020, Sam Ravnborg wrote:
> Hi Lee.
>
> On Thu, Nov 05, 2020 at 02:44:58PM +, Lee Jones wrote:
> > This set is part of a larger effort attempting to clean-up W=1
> > kernel builds, which are currently overwhelmingly riddled with
> > niggly little warnings.
>
> Thanks for looki
On Thu, Nov 5, 2020 at 7:10 PM Lee Jones wrote:
>
> On Thu, 05 Nov 2020, Thierry Reding wrote:
>
> > On Thu, Nov 05, 2020 at 02:44:58PM +, Lee Jones wrote:
> > > This set is part of a larger effort attempting to clean-up W=1
> > > kernel builds, which are currently overwhelmingly riddled with
On Wed, Nov 04, 2020 at 03:01:17PM -0500, Felix Kuehling wrote:
> On 2020-11-04 10:13 a.m., Deepak R Varma wrote:
> > idr_init() uses base 0 which is an invalid identifier. The new function
> > idr_init_base allows IDR to set the ID lookup from base 1. This avoids
> > all lookups that otherwise sta
On Thu, Nov 05, 2020 at 02:44:58PM +, Lee Jones wrote:
> This set is part of a larger effort attempting to clean-up W=1
> kernel builds, which are currently overwhelmingly riddled with
> niggly little warnings.
>
> There are 5000 warnings to work through.
>
> It will take a couple more sets.
Hi Lee.
On Thu, Nov 05, 2020 at 02:44:58PM +, Lee Jones wrote:
> This set is part of a larger effort attempting to clean-up W=1
> kernel builds, which are currently overwhelmingly riddled with
> niggly little warnings.
Thanks for looking into this.
> There are 5000 warnings to work through.
This set is part of a larger effort attempting to clean-up W=1
kernel builds, which are currently overwhelmingly riddled with
niggly little warnings.
There are 5000 warnings to work through.
It will take a couple more sets.
Lee Jones (19):
gpu: host1x: bus: Add missing description for 'driver'
- Demote non-conformant headers
- Fix misnaming issues
- Rename labels with identical names
- Remove incorrect descriptions
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/radeon_device.c:637:6: warning: no previous prototype
for ‘radeon_device_is_virtual’ [-Wmissing
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/radeon_drv.c: In function
‘radeon_pmops_runtime_suspend’:
drivers/gpu/drm/radeon/radeon_drv.c:455:6: warning: variable ‘ret’ set but not
used [-Wunused-but-set-variable]
Cc: Alex Deucher
Cc: "Christian König"
Cc: David
These 3 variables are used in *some* sourcefiles which include
amdgpu.h, but not *all*. This leads to a flurry of build warnings.
Fixes the following W=1 kernel build warning(s):
from drivers/gpu/drm/amd/amdgpu/amdgpu.h:67,
drivers/gpu/drm/amd/amdgpu/amdgpu.h:198:19: warning: ‘no_system_mem_li
[AMD Official Use Only - Internal Distribution Only]
Acked-by: Alex Deucher
From: amd-gfx on behalf of Kent Russell
Sent: Thursday, November 5, 2020 10:20 AM
To: amd-gfx@lists.freedesktop.org
Cc: Russell, Kent
Subject: [PATCH] drm/amdgpu: Fix Arcturus fan spe
Arcturus doesn't have a fan. The assumption of "if the manual fan
control bit isn't set, it's on automatic mode" does not hold true if the
fan is missing, and results in exposing an invalid value for fan speed.
The SMU metrics table accurately reflects the lack of fan and will
return 0 for the fan
Reviewed-by: Alex Deucher
On Thu, Nov 5, 2020 at 8:27 AM wrote:
>
> From: Roman Li
>
> [Why]
> In preparation to enabling hdcp on green sardine.
>
> [How]
> Add green-sardine ta f/w loading in psp_v12
>
> Signed-off-by: Roman Li
> ---
> drivers/gpu/drm/amd/amdgpu/psp_v12_0.c | 1 +
> 1 file c
From: Roman Li
[Why]
In preparation to enabling hdcp on green sardine.
[How]
Add green-sardine ta f/w loading in psp_v12
Signed-off-by: Roman Li
---
drivers/gpu/drm/amd/amdgpu/psp_v12_0.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/psp_v12_0.c
b/drivers/gpu
On Thu, Nov 05, 2020 at 11:37:08AM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 05.11.20 um 11:07 schrieb Linus Walleij:
> > Overall I like this, just an inline question:
> >
> > On Tue, Oct 20, 2020 at 2:20 PM Thomas Zimmermann
> > wrote:
> >
> >> To do framebuffer updates, one needs memcpy fr
Hi
Am 05.11.20 um 11:07 schrieb Linus Walleij:
> Overall I like this, just an inline question:
>
> On Tue, Oct 20, 2020 at 2:20 PM Thomas Zimmermann wrote:
>
>> To do framebuffer updates, one needs memcpy from system memory and a
>> pointer-increment function. Add both interfaces with documenta
Overall I like this, just an inline question:
On Tue, Oct 20, 2020 at 2:20 PM Thomas Zimmermann wrote:
> To do framebuffer updates, one needs memcpy from system memory and a
> pointer-increment function. Add both interfaces with documentation.
(...)
> +/**
> + * dma_buf_map_memcpy_to - Memcpy i
20 matches
Mail list logo
