Re: [PATCH] drm/nouveau/therm: Fix pointer dereferenced before checking
在 2022/5/30 上午11:10, Haowen Bai 写道: > The fan->base is dereferencing before null checking, so move > it after checking. > > Signed-off-by: Haowen Bai > --- > drivers/gpu/drm/nouveau/nvkm/subdev/therm/fanpwm.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/fanpwm.c > b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/fanpwm.c > index 340f37a299dc..b13ba9b2f6be 100644 > --- a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/fanpwm.c > +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/fanpwm.c > @@ -98,10 +98,10 @@ nvkm_fanpwm_create(struct nvkm_therm *therm, struct > dcb_gpio_func *func) > return -ENODEV; > > fan = kzalloc(sizeof(*fan), GFP_KERNEL); > - therm->fan = >base; > if (!fan) > return -ENOMEM; > > + therm->fan = >base; > fan->base.type = "PWM"; > fan->base.get = nvkm_fanpwm_get; > fan->base.set = nvkm_fanpwm_set; Sorry, plz ignore this patch. fan->base is dereferenced, >base is just a pointer math for pointer address offset, so it would not cause a bug(dereferencing null pointer). -- Haowen Bai
[PATCH] drm: hisilicon: depends on MMU
Prevent a kconfig warning when MMU is not enabled by making
DRM_HISI_HIBMC depend on MMU.
WARNING: unmet direct dependencies detected for DRM_TTM
Depends on [n]: HAS_IOMEM [=y] && DRM [=m] && MMU [=n]
Selected by [m]:
- DRM_TTM_HELPER [=m] && HAS_IOMEM [=y] && DRM [=m]
- DRM_HISI_HIBMC [=m] && HAS_IOMEM [=y] && DRM [=m] && PCI [=y] && (ARM64 ||
COMPILE_TEST [=y])
Fixes: 4f7f1973b0c8 ("drm/vram: fix Kconfig")
Signed-off-by: Randy Dunlap
Cc: Gerd Hoffmann
Cc: Thomas Zimmermann
Cc: Xinliang Liu
Cc: Tian Tao
Cc: John Stultz
Cc: Xinwei Kong
Cc: Chen Feng
Cc: Christian Koenig
Cc: Huang Rui
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/hisilicon/hibmc/Kconfig |1 +
1 file changed, 1 insertion(+)
--- a/drivers/gpu/drm/hisilicon/hibmc/Kconfig
+++ b/drivers/gpu/drm/hisilicon/hibmc/Kconfig
@@ -2,6 +2,7 @@
config DRM_HISI_HIBMC
tristate "DRM Support for Hisilicon Hibmc"
depends on DRM && PCI && (ARM64 || COMPILE_TEST)
+ depends on MMU
select DRM_KMS_HELPER
select DRM_VRAM_HELPER
select DRM_TTM
Re: [PATCH] dma-fence: allow dma fence to have their own lock
On (22/05/30 16:55), Christian König wrote: > Am 30.05.22 um 16:22 schrieb Sergey Senozhatsky: > > [SNIP] > > So the `lock` should have at least same lifespan as the DMA fence > > that borrows it, which is impossible to guarantee in our case. > > Nope, that's not correct. The lock should have at least same lifespan as the > context of the DMA fence. How does one know when it's safe to release the context? DMA fence objects are still transparently refcount-ed and "live their own lives", how does one synchronize lifespans?
Re: [PATCH] drm/msm/dpu: Fix pointer dereferenced before checking
在 2022/5/31 上午8:36, Abhinav Kumar 写道:
>
>
> On 5/30/2022 12:33 AM, Haowen Bai wrote:
>> The ctx->hw is dereferencing before null checking, so move
>> it after checking.
>>
>> Signed-off-by: Haowen Bai
>
> Agree with Dmitry's comment. Adjust the patch subject to a different one
> otherwise PW thinks they are same patches.
>
> Reviewed-by: Abhinav Kumar
>
>> ---
>> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c
>> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c
>> index be292937..e59680cdd0ce 100644
>> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c
>> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c
>> @@ -155,11 +155,13 @@ static void dpu_hw_wb_roi(struct dpu_hw_wb *ctx,
>> struct dpu_hw_wb_cfg *wb)
>> static void dpu_hw_wb_setup_qos_lut(struct dpu_hw_wb *ctx,
>> struct dpu_hw_wb_qos_cfg *cfg)
>> {
>> - struct dpu_hw_blk_reg_map *c = >hw;
>> + struct dpu_hw_blk_reg_map *c;
>> u32 qos_ctrl = 0;
>> if (!ctx || !cfg)
>> return;
>> +
>> + c = >hw;
>> DPU_REG_WRITE(c, WB_DANGER_LUT, cfg->danger_lut);
>> DPU_REG_WRITE(c, WB_SAFE_LUT, cfg->safe_lut);
Sorry, plz ignore this patch.
ctx->hw is dereferenced, >hw is just a pointer math for pointer address
offset, so it would not cause a bug(dereferencing null pointer).
--
Haowen Bai
Re: [PATCH] drm/msm/dpu: Fix pointer dereferenced before checking
在 2022/5/30 下午3:33, Haowen Bai 写道:
> The ctx->hw is dereferencing before null checking, so move
> it after checking.
>
> Signed-off-by: Haowen Bai
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c
> index be292937..e59680cdd0ce 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c
> @@ -155,11 +155,13 @@ static void dpu_hw_wb_roi(struct dpu_hw_wb *ctx, struct
> dpu_hw_wb_cfg *wb)
> static void dpu_hw_wb_setup_qos_lut(struct dpu_hw_wb *ctx,
> struct dpu_hw_wb_qos_cfg *cfg)
> {
> - struct dpu_hw_blk_reg_map *c = >hw;
> + struct dpu_hw_blk_reg_map *c;
> u32 qos_ctrl = 0;
>
> if (!ctx || !cfg)
> return;
> +
> + c = >hw;
>
> DPU_REG_WRITE(c, WB_DANGER_LUT, cfg->danger_lut);
> DPU_REG_WRITE(c, WB_SAFE_LUT, cfg->safe_lut);
Sorry, plz ignore this patch.
ctx->hw is dereferenced, >hw is just a pointer math for pointer address
offset, so it would not cause a bug(dereferencing null pointer).
--
Haowen Bai
Re: [PATCH] drm/msm/dpu: Fix pointer dereferenced before checking
On 5/30/2022 12:33 AM, Haowen Bai wrote:
The ctx->hw is dereferencing before null checking, so move
it after checking.
Signed-off-by: Haowen Bai
Agree with Dmitry's comment. Adjust the patch subject to a different one
otherwise PW thinks they are same patches.
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c
index be292937..e59680cdd0ce 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c
@@ -155,11 +155,13 @@ static void dpu_hw_wb_roi(struct dpu_hw_wb *ctx, struct
dpu_hw_wb_cfg *wb)
static void dpu_hw_wb_setup_qos_lut(struct dpu_hw_wb *ctx,
struct dpu_hw_wb_qos_cfg *cfg)
{
- struct dpu_hw_blk_reg_map *c = >hw;
+ struct dpu_hw_blk_reg_map *c;
u32 qos_ctrl = 0;
if (!ctx || !cfg)
return;
+
+ c = >hw;
DPU_REG_WRITE(c, WB_DANGER_LUT, cfg->danger_lut);
DPU_REG_WRITE(c, WB_SAFE_LUT, cfg->safe_lut);
Re: [PATCH] drm/msm/dpu: Fix pointer dereferenced before checking
On Mon, 30 May 2022 at 05:20, Haowen Bai wrote: > > The phys_enc->wb_idx is dereferencing before null checking, so move > it after checking. > > Signed-off-by: Haowen Bai > --- > drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: [PATCH] drm/msm/dpu: Fix pointer dereferenced before checking
A nit: patchwork thinks that two patches from the same author with the same subject are two versions of the same patch. In future, could you please send such patches with distinct names? No need to send v2 now unless review shows other issues with the patches. On Mon, 30 May 2022 at 10:33, Haowen Bai wrote: > > The ctx->hw is dereferencing before null checking, so move > it after checking. > > Signed-off-by: Haowen Bai > --- > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: [GIT PULL] fbdev updates & fixes for v5.19-rc1
The pull request you sent on Mon, 30 May 2022 21:44:08 +0200: > http://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git > tags/for-5.19/fbdev-1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/8ab2afa23bd197df47819a87f0265c0ac95c5b6a Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
[GIT PULL] fbdev updates & fixes for v5.19-rc1
The following changes since commit 42226c989789d8da4af1de0c31070c96726d990c: Linux 5.18-rc7 (2022-05-15 18:08:58 -0700) are available in the Git repository at: http://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git tags/for-5.19/fbdev-1 for you to fetch changes up to 79b66128f13f5c22dea03a2197495c4b96ab31f5: video: fbdev: omap: Add prototype for hwa742_update_window_async() (2022-05-29 10:20:15 +0200) fbdev fixes and updates for kernel v5.19-rc1 A buch of small fixes and cleanups, including: - vesafb: Fix a use-after-free due early fb_info cleanup - clcdfb: Fix refcount leak in clcdfb_of_vram_setup - hyperv_fb: Allow resolutions with size > 64 MB for Gen1 - pxa3xx-gcu: release the resources correctly in pxa3xx_gcu_probe/remove() - omapfb: Prevent compiler warning regarding hwa742_update_window_async() Helge Deller (1): video: fbdev: omap: Add prototype for hwa742_update_window_async() Javier Martinez Canillas (1): video: fbdev: vesafb: Fix a use-after-free due early fb_info cleanup Miaoqian Lin (1): video: fbdev: clcdfb: Fix refcount leak in clcdfb_of_vram_setup Minghao Chi (2): video: fbdev: omapfb: simplify the return expression of dsi_init_pll_data() video: fbdev: omapfb: simplify the return expression of nec_8048_connect() Saurabh Sengar (1): video: fbdev: hyperv_fb: Allow resolutions with size > 64 MB for Gen1 Tom Rix (1): video: fbdev: xen: remove setting of 'transp' parameter Yang Yingliang (1): video: fbdev: pxa3xx-gcu: release the resources correctly in pxa3xx_gcu_probe/remove() pengfuyuan (1): video: fbdev: radeon: Fix spelling typo in comment drivers/video/fbdev/amba-clcd.c | 5 - drivers/video/fbdev/hyperv_fb.c | 19 +-- drivers/video/fbdev/omap/omapfb.h | 4 .../omap2/omapfb/displays/panel-nec-nl8048hl11.c | 7 +-- drivers/video/fbdev/omap2/omapfb/dss/hdmi_pll.c | 8 +--- drivers/video/fbdev/pxa3xx-gcu.c | 12 +++- drivers/video/fbdev/vesafb.c | 5 +++-- drivers/video/fbdev/xen-fbfront.c | 1 - include/video/radeon.h| 2 +- 9 files changed, 22 insertions(+), 41 deletions(-)
Re: [PATCH] drm/prime: Ensure mmap offset is initialized
On Mon, May 30, 2022 at 10:20 AM Thomas Zimmermann wrote:
>
> Hi
>
> Am 30.05.22 um 17:41 schrieb Rob Clark:
> > On Mon, May 30, 2022 at 7:49 AM Daniel Vetter wrote:
> >>
> >> On Mon, 30 May 2022 at 15:54, Rob Clark wrote:
> >>>
> >>> On Mon, May 30, 2022 at 12:26 AM Thomas Zimmermann
> >>> wrote:
>
> Hi
>
> Am 29.05.22 um 18:29 schrieb Rob Clark:
> > From: Rob Clark
> >
> > If a GEM object is allocated, and then exported as a dma-buf fd which is
> > mmap'd before or without the GEM buffer being directly mmap'd, the
> > vma_node could be unitialized. This leads to a situation where the CPU
> > mapping is not correctly torn down in drm_vma_node_unmap().
>
> Which drivers are affected by this problem?
>
> I checked several drivers and most appear to be initializing the offset
> during object construction, such as GEM SHMEM. [1] TTM-based drivers
> also seem unaffected. [2]
>
> From a quick grep, only etnaviv, msm and omapdrm appear to be affected?
> They only seem to run drm_gem_create_mmap_offset() from their
> ioctl-handling code.
>
> If so, I'd say it's preferable to fix these drivers and put a
> drm_WARN_ONCE() into drm_gem_prime_mmap().
> >>>
> >>> That is good if fewer drivers are affected, however I disagree with
> >>> your proposal. At least for freedreno userspace, a lot of bo's never
> >>> get mmap'd (either directly of via dmabuf), so we should not be
> >>> allocating a mmap offset unnecessarily.
> >>
> >> Does this actually matter in the grand scheme of things? We originally
> >> allocated mmap offset only on demand because userspace only had 32bit
> >> loff_t support and so simply couldn't mmap anything if the offset
> >> ended up above 32bit (even if there was still va space available).
> >>
> >> But those days are long gone (about 10 years or so) and the allocation
> >> overhead for an mmap offset is tiny. So I think unless you can
> >> benchmark an impact allocating it at bo alloc seems like the simplest
> >> design overall, and hence what we should be doing. And if the vma
> >> offset allocation every gets too slow due to fragmentation we can lift
> >> the hole tree from i915 into drm_mm and the job should be done. At
> >> that point we could also allocate the offset unconditionally in the
> >> gem_init function and be done with it.
> >>
> >> Iow I concur with Thomas here, unless there's hard data contrary
> >> simplicity imo trumps here.
> >
> > 32b userspace is still alive and well, at least on arm chromebooks ;-)
>
> I mostly dislike the inconsistency among drivers. If we want to create
> the offset on-demand in the DRM helpers, we should do so for all
> drivers. At least our generic GEM helpers and TTM should implement this
> pattern.
Possibly we should have drm_gem_get_mmap_offset() which combines
drm_gem_create_mmap_offset() and drm_vma_node_start() calls, and use
that everywhere.
But I think we should fix this issue first, and then refactor on top,
so that a fix can be backported to stable kernels ;-)
BR,
-R
> Best regards
> Thomas
>
> >
> > BR,
> > -R
> >
> >> -Daniel
> >>
> >>>
> >>> BR,
> >>> -R
> >>>
> Best regards
> Thomas
>
> [1]
> https://elixir.bootlin.com/linux/v5.18/source/drivers/gpu/drm/drm_gem_shmem_helper.c#L85
> [2]
> https://elixir.bootlin.com/linux/v5.18/source/drivers/gpu/drm/ttm/ttm_bo.c#L1002
>
> >
> > Fixes: e5516553999f ("drm: call drm_gem_object_funcs.mmap with fake
> > offset")
> > Signed-off-by: Rob Clark
> > ---
> > Note, it's possible the issue existed in some related form prior to the
> > commit tagged with Fixes.
> >
> >drivers/gpu/drm/drm_prime.c | 5 +
> >1 file changed, 5 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> > index e3f09f18110c..849eea154dfc 100644
> > --- a/drivers/gpu/drm/drm_prime.c
> > +++ b/drivers/gpu/drm/drm_prime.c
> > @@ -716,6 +716,11 @@ int drm_gem_prime_mmap(struct drm_gem_object *obj,
> > struct vm_area_struct *vma)
> >struct file *fil;
> >int ret;
> >
> > + /* Ensure that the vma_node is initialized: */
> > + ret = drm_gem_create_mmap_offset(obj);
> > + if (ret)
> > + return ret;
> > +
> >/* Add the fake offset */
> >vma->vm_pgoff += drm_vma_node_start(>vma_node);
> >
>
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> (HRB 36809, AG Nürnberg)
> Geschäftsführer: Ivo Totev
> >>
> >>
> >>
> >> --
> >> Daniel Vetter
> >> Software Engineer, Intel Corporation
> >> http://blog.ffwll.ch
>
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> (HRB
Re: [PATCH] drm/prime: Ensure mmap offset is initialized
Hi
Am 30.05.22 um 17:41 schrieb Rob Clark:
On Mon, May 30, 2022 at 7:49 AM Daniel Vetter wrote:
On Mon, 30 May 2022 at 15:54, Rob Clark wrote:
On Mon, May 30, 2022 at 12:26 AM Thomas Zimmermann wrote:
Hi
Am 29.05.22 um 18:29 schrieb Rob Clark:
From: Rob Clark
If a GEM object is allocated, and then exported as a dma-buf fd which is
mmap'd before or without the GEM buffer being directly mmap'd, the
vma_node could be unitialized. This leads to a situation where the CPU
mapping is not correctly torn down in drm_vma_node_unmap().
Which drivers are affected by this problem?
I checked several drivers and most appear to be initializing the offset
during object construction, such as GEM SHMEM. [1] TTM-based drivers
also seem unaffected. [2]
From a quick grep, only etnaviv, msm and omapdrm appear to be affected?
They only seem to run drm_gem_create_mmap_offset() from their
ioctl-handling code.
If so, I'd say it's preferable to fix these drivers and put a
drm_WARN_ONCE() into drm_gem_prime_mmap().
That is good if fewer drivers are affected, however I disagree with
your proposal. At least for freedreno userspace, a lot of bo's never
get mmap'd (either directly of via dmabuf), so we should not be
allocating a mmap offset unnecessarily.
Does this actually matter in the grand scheme of things? We originally
allocated mmap offset only on demand because userspace only had 32bit
loff_t support and so simply couldn't mmap anything if the offset
ended up above 32bit (even if there was still va space available).
But those days are long gone (about 10 years or so) and the allocation
overhead for an mmap offset is tiny. So I think unless you can
benchmark an impact allocating it at bo alloc seems like the simplest
design overall, and hence what we should be doing. And if the vma
offset allocation every gets too slow due to fragmentation we can lift
the hole tree from i915 into drm_mm and the job should be done. At
that point we could also allocate the offset unconditionally in the
gem_init function and be done with it.
Iow I concur with Thomas here, unless there's hard data contrary
simplicity imo trumps here.
32b userspace is still alive and well, at least on arm chromebooks ;-)
I mostly dislike the inconsistency among drivers. If we want to create
the offset on-demand in the DRM helpers, we should do so for all
drivers. At least our generic GEM helpers and TTM should implement this
pattern.
Best regards
Thomas
BR,
-R
-Daniel
BR,
-R
Best regards
Thomas
[1]
https://elixir.bootlin.com/linux/v5.18/source/drivers/gpu/drm/drm_gem_shmem_helper.c#L85
[2]
https://elixir.bootlin.com/linux/v5.18/source/drivers/gpu/drm/ttm/ttm_bo.c#L1002
Fixes: e5516553999f ("drm: call drm_gem_object_funcs.mmap with fake offset")
Signed-off-by: Rob Clark
---
Note, it's possible the issue existed in some related form prior to the
commit tagged with Fixes.
drivers/gpu/drm/drm_prime.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index e3f09f18110c..849eea154dfc 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -716,6 +716,11 @@ int drm_gem_prime_mmap(struct drm_gem_object *obj, struct
vm_area_struct *vma)
struct file *fil;
int ret;
+ /* Ensure that the vma_node is initialized: */
+ ret = drm_gem_create_mmap_offset(obj);
+ if (ret)
+ return ret;
+
/* Add the fake offset */
vma->vm_pgoff += drm_vma_node_start(>vma_node);
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PATCH 03/10] drm/i915/uapi: expose the avail tracking
On 26/05/2022 09:33, Tvrtko Ursulin wrote:
On 26/05/2022 09:10, Matthew Auld wrote:
On 26/05/2022 08:58, Tvrtko Ursulin wrote:
On 25/05/2022 19:43, Matthew Auld wrote:
Vulkan would like to have a rough measure of how much device memory can
in theory be allocated. Also add unallocated_cpu_visible_size to track
the visible portion, in case the device is using small BAR.
I have concerns here that it isn't useful and could even be
counter-productive. If we give unprivileged access it may be
considered a side channel, but if we "lie" (report total region size)
to unprivileged clients (like in this patch), then they don't
co-operate well and end trashing.
Is Vulkan really sure it wants this and why?
Lionel pointed out:
https://www.khronos.org/registry/vulkan/specs/1.3-extensions/man/html/VK_EXT_memory_budget.html
So this query would provide
VkPhysicalDeviceMemoryBudgetPropertiesEXT::heapBudget. Apart that it
wouldn't since we thought to lie. And apart that it's text says:
"""
...how much total memory from each heap the current process can use at
any given time, before allocations may start failing or causing
performance degradation. The values may change based on other activity
in the system that is outside the scope and control of the Vulkan
implementation.
"""
It acknowledges itself in the second sentence that the first sentence is
questionable.
And VkPhysicalDeviceMemoryBudgetPropertiesEXT::heapUsage would be still
missing and would maybe come via fdinfo? Or you plan to add it to this
same query later?
IIUC the heapUsage is something like per app usage, which already looks
to be tracked in anv, although I don't think it knows if stuff is
actually resident or not. The heapBudget looks to then be roughly the
heapUsage + info.unallocated.
I like to source knowledge of best practices from the long established
world of CPU scheduling and process memory management. Is anyone aware
of this kind of techniques there - applications actively looking at free
memory data from /proc/meminfo and dynamically adjusting their runtime
behaviour based on it? And that they are not single application on a
dedicated system type of things.
Or perhaps this Vk extension is envisaged for exactly those kind of
scenarios? However if so then userspace can know all this data from
probed size and the data set it created.
Also note that the existing behaviour was to lie. I'm not sure what's
the best option here.
Uapi reserved -1 for unknown so we could do that?
AFAICT we can do that for the info.unallocated_cpu_visible, but not for
the existing info.unallocated without maybe breaking something?
Regards,
Tvrtko
Regards,
Tvrtko
Testcase: igt@i915_query@query-regions-unallocated
Testcase: igt@i915_query@query-regions-sanity-check
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Lionel Landwerlin
Cc: Tvrtko Ursulin
Cc: Jon Bloomfield
Cc: Daniel Vetter
Cc: Jordan Justen
Cc: Kenneth Graunke
Cc: Akeem G Abodunrin
---
drivers/gpu/drm/i915/i915_query.c | 10 +-
drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 20
drivers/gpu/drm/i915/i915_ttm_buddy_manager.h | 3 ++
drivers/gpu/drm/i915/intel_memory_region.c | 14 +
drivers/gpu/drm/i915/intel_memory_region.h | 3 ++
include/uapi/drm/i915_drm.h | 31
++-
6 files changed, 79 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_query.c
b/drivers/gpu/drm/i915/i915_query.c
index 9aa0b28aa6ee..e095c55f4d4b 100644
--- a/drivers/gpu/drm/i915/i915_query.c
+++ b/drivers/gpu/drm/i915/i915_query.c
@@ -502,7 +502,15 @@ static int query_memregion_info(struct
drm_i915_private *i915,
else
info.probed_cpu_visible_size = mr->total;
- info.unallocated_size = mr->avail;
+ if (perfmon_capable()) {
+ intel_memory_region_avail(mr,
+ _size,
+ _cpu_visible_size);
+ } else {
+ info.unallocated_size = info.probed_size;
+ info.unallocated_cpu_visible_size =
+ info.probed_cpu_visible_size;
+ }
if (__copy_to_user(info_ptr, , sizeof(info)))
return -EFAULT;
diff --git a/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
b/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
index a5109548abc0..aa5c91e44438 100644
--- a/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
+++ b/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
@@ -365,6 +365,26 @@ u64 i915_ttm_buddy_man_visible_size(struct
ttm_resource_manager *man)
return bman->visible_size;
}
+/**
+ * i915_ttm_buddy_man_visible_size - Query the avail tracking for
the manager.
+ *
+ * @man: The buddy allocator ttm manager
+ * @avail: The total available memory in pages for the entire manager.
+ * @visible_avail: The total available memory in pages for the CPU
visible
+ * portion. Note that this will always give the same value
Re: mainline build failure due to f1e4c916f97f ("drm/edid: add EDID block count and size helpers")
On Mon, May 30, 2022 at 03:35:28PM +0200, Arnd Bergmann wrote:
> The annotations for edid are completely correct and necessary. However
> other driver authors just slap __packed annotations on any structure
> even if the layout is not fixed at all like:
>
> struct my_driver_priv {
>struct device dev;
>u8 causes_misalignment;
>spinlock_t lock;
>atomic_t counter;
> } __packed; /* this annotation is harmful because it breaks the atomics */
>
> or if the annotation does not change the layout like
>
> struct my_dma_descriptor {
> __le64 address;
> __le64 length;
> } __packed; /* does not change layout but makes access slow on some
> architectures */
Sounds like we need a howto document for people to ignore and continue
doing their own thing. :P
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
Re: mainline build failure due to f1e4c916f97f ("drm/edid: add EDID block count and size helpers")
On Mon, May 30, 2022 at 02:43:45PM +0200, Arnd Bergmann wrote: > Overall I'm not that worried because the only machines running OABI > kernels would be on really old hardware that runs a limited set of > driver code. ... and from what I remember, none of them care about EDID anyway. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
Re: mainline build failure due to f1e4c916f97f ("drm/edid: add EDID block count and size helpers")
On Mon, May 30, 2022 at 12:33:17PM +0300, Jani Nikula wrote: > On Mon, 30 May 2022, Jani Nikula wrote: > > On Sat, 28 May 2022, Linus Torvalds wrote: > >> On Sat, May 28, 2022 at 11:59 AM Arnd Bergmann wrote: > >>> > >>> It's CONFIG_ARM_AEABI, which is normally set everywhere. Without this > >>> option, you the kernel is built for the old 'OABI' that forces all > >>> non-packed > >>> struct members to be at least 16-bit aligned. > >> > >> Looks like forced word (32 bit) alignment to me. > >> > >> I wonder how many other structures that messes up, but I committed the > >> EDID fix for now. > > > > Thanks for the fix, and the thorough commit message! > > > >> This has presumably been broken for a long time, but maybe the > >> affected targets don't typically use EDID and kernel modesetting, and > >> only use some fixed display setup instead. > >> > >> Those structure definitions go back a _loong_ time (from a quick 'git > >> blame' I see November 2008). > >> > >> But despite that, I did not mark my fix 'cc:stable' because I don't > >> know if any of those machines affected by this bad arm ABI issue could > >> possibly care. > >> > >> At least my tree hopefully now builds on them, with the BUILD_BUG_ON() > >> that uncovered this. > > > > Indeed the bug is ancient. I just threw in the BUILD_BUG_ON() on a whim > > as an extra sanity check when doing pointer arithmetics on struct edid > > *. > > > > If there are affected machines, buffer overflows are the real danger due > > to edid->extensions indicating the number of extensions. > > That is, for EDID. Makes you wonder about all the other packed structs > with enum members across the kernel. enum should not be used in structures if the layout of the struct matters. ISTR there was a proposal for EABI to make enums just about big enough to hold their enumerated constants - so you'd end up with 8-bit, 16-bit etc according to the largest enumerated value that the compiler thinks it could hold. That's a latent disaster when enums get used in structs where the layout matters, __packed or not. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
Re: [RFC PATCH 1/1] drm/format-helper: Add KUnit tests for drm_fb_xrgb8888_to_rgb332()
Hi Maxime, On Mon, May 30, 2022 at 03:11:58PM +0200, Maxime Ripard wrote: > > Hi, > > On Mon, May 30, 2022 at 12:20:17PM +0200, José Expósito wrote: > > Test the conversion from XRGB to RGB332. > > > > What is tested? > > > > - Different values for the X in XRGB to make sure it is ignored > > - Different clip values: Single pixel and full and partial buffer > > - Well know colors: White, black, red, green, blue, magenta, yellow > >and cyan > > - Other colors: Randomly picked > > - Destination pitch > > > > Suggested-by: Javier Martinez Canillas > > Signed-off-by: José Expósito > > It looks mostly good to me, but I think we should Cc > kunit-...@googlegroups.com to have their feedback. Thanks a lot for the quick feedback. I just cc'ed kunit-...@googlegroups.com. For anyone joining the conversation, here is the link to the patch and the cover letter with some questions: https://lore.kernel.org/dri-devel/20220530102017.471865-1-jose.exposit...@gmail.com/T/ > > > --- > > drivers/gpu/drm/Kconfig | 12 ++ > > drivers/gpu/drm/Makefile | 3 + > > drivers/gpu/drm/drm_format_helper_test.c | 166 +++ > > 3 files changed, 181 insertions(+) > > create mode 100644 drivers/gpu/drm/drm_format_helper_test.c > > > > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig > > index e88c497fa010..d92be6faef15 100644 > > --- a/drivers/gpu/drm/Kconfig > > +++ b/drivers/gpu/drm/Kconfig > > @@ -76,6 +76,18 @@ config DRM_KMS_HELPER > > help > > CRTC helpers for KMS drivers. > > > > +config DRM_FORMAR_HELPER_TEST > > + bool "drm_format_helper tests" if !KUNIT_ALL_TESTS > > + depends on DRM && KUNIT=y > > + select DRM_KMS_HELPER > > + default KUNIT_ALL_TESTS > > + help > > + KUnit tests for the drm_format_helper APIs. This option is not > > + useful for distributions or general kernels, but only for kernel > > + developers working on DRM and associated drivers. > > + > > + If in doubt, say "N". > > + > > AFAIK, kunit test cases are supposed to have a .kunitconfig too to > enable the kunit tests easily. > > Maxime A .kuniconfig example is present in the cover letter. My understanding from the docs: https://docs.kernel.org/dev-tools/kunit/run_wrapper.html#create-a-kunitconfig-file Is that, like the .config file, the .kunitconfig file is not meant to be included in git, but I'm sure someone else will clarify this point. Thanks again, José Expósito
[PATCH v3 3/3] drm/panel: introduce ebbg,ft8719 panel
Add DRM panel driver for EBBG FT8719 6.18" 2246x1080 DSI video mode
panel, which can be found on some Xiaomi Poco F1 phones. The panel's
backlight is managed through QCOM WLED driver.
Signed-off-by: Joel Selvaraj
Reviewed-by: Sam Ravnborg
---
Changes in v3: (Mostly Linus Walleij's Suggestions)
- Removed ctx->prepared state variable as it's handled by the core
- Print error in dsi_dcs_write_seq macro if it fails to write
- Removed magic power on sequences as panel works fine without them
MAINTAINERS | 7 +
drivers/gpu/drm/panel/Kconfig | 11 +
drivers/gpu/drm/panel/Makefile| 1 +
drivers/gpu/drm/panel/panel-ebbg-ft8719.c | 296 ++
4 files changed, 315 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-ebbg-ft8719.c
diff --git a/MAINTAINERS b/MAINTAINERS
index cd0f68d4a34a..dfd2c53aea00 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6018,6 +6018,13 @@ S: Maintained
F: Documentation/devicetree/bindings/display/bridge/chipone,icn6211.yaml
F: drivers/gpu/drm/bridge/chipone-icn6211.c
+DRM DRIVER FOR EBBG FT8719 PANEL
+M: Joel Selvaraj
+S: Maintained
+T: git git://anongit.freedesktop.org/drm/drm-misc
+F: Documentation/devicetree/bindings/display/panel/ebbg,ft8719.yaml
+F: drivers/gpu/drm/panel/panel-ebbg-ft8719.c
+
DRM DRIVER FOR FARADAY TVE200 TV ENCODER
M: Linus Walleij
S: Maintained
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 9989a316fe88..77176df2e2ec 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -114,6 +114,17 @@ config DRM_PANEL_EDP
that it can be automatically turned off when the panel goes into a
low power state.
+config DRM_PANEL_EBBG_FT8719
+ tristate "EBBG FT8719 panel driver"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y here if you want to enable support for the EBBG FT8719
+ video mode panel. Mainly found on Xiaomi Poco F1 mobile phone.
+ The panel has a resolution of 1080x2246. It provides a MIPI DSI
+ interface to the host.
+
config DRM_PANEL_ELIDA_KD35T133
tristate "Elida KD35T133 panel driver"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index d99fbbce49d1..47cc20c1a770 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_DRM_PANEL_DSI_CM) += panel-dsi-cm.o
obj-$(CONFIG_DRM_PANEL_LVDS) += panel-lvds.o
obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
obj-$(CONFIG_DRM_PANEL_EDP) += panel-edp.o
+obj-$(CONFIG_DRM_PANEL_EBBG_FT8719) += panel-ebbg-ft8719.o
obj-$(CONFIG_DRM_PANEL_ELIDA_KD35T133) += panel-elida-kd35t133.o
obj-$(CONFIG_DRM_PANEL_FEIXIN_K101_IM2BA02) += panel-feixin-k101-im2ba02.o
obj-$(CONFIG_DRM_PANEL_FEIYANG_FY07024DI26A30D) +=
panel-feiyang-fy07024di26a30d.o
diff --git a/drivers/gpu/drm/panel/panel-ebbg-ft8719.c
b/drivers/gpu/drm/panel/panel-ebbg-ft8719.c
new file mode 100644
index ..9f3819cabd75
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-ebbg-ft8719.c
@@ -0,0 +1,296 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2022 Joel Selvaraj
+ * Generated with linux-mdss-dsi-panel-driver-generator from vendor device
tree:
+ * Copyright (c) 2013, The Linux Foundation. All rights reserved.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include
+#include
+#include
+
+static const char * const regulator_names[] = {
+ "vddio",
+ "vddpos",
+ "vddneg",
+};
+
+static const unsigned long regulator_enable_loads[] = {
+ 62000,
+ 10,
+ 10
+};
+
+struct ebbg_ft8719 {
+ struct drm_panel panel;
+ struct mipi_dsi_device *dsi;
+
+ struct regulator_bulk_data supplies[ARRAY_SIZE(regulator_names)];
+
+ struct gpio_desc *reset_gpio;
+};
+
+static inline
+struct ebbg_ft8719 *to_ebbg_ft8719(struct drm_panel *panel)
+{
+ return container_of(panel, struct ebbg_ft8719, panel);
+}
+
+#define dsi_dcs_write_seq(dsi, cmd, seq...) do {
\
+ static const u8 d[] = { cmd, seq };
\
+ struct device *dev = >dev; \
+ int ret;\
+ ret = mipi_dsi_dcs_write_buffer(dsi, d, ARRAY_SIZE(d)); \
+ if (ret < 0) { \
+ dev_err_ratelimited(dev, "sending command %#02x failed:
%d\n", cmd, ret); \
+ return ret;
\
+ } \
+ } while (0)
+
+static void ebbg_ft8719_reset(struct ebbg_ft8719 *ctx)
+{
+ gpiod_set_value_cansleep(ctx->reset_gpio, 0);
+
[PATCH v3 2/3] dt-bindings: display: Add bindings for EBBG FT8719
Add bindings for the EBBG FT8719 6.18" 2246x1080 DSI video mode panel,
which can be found on some Xiaomi Poco F1 phones. The backlight is
managed through the QCOM WLED driver.
Signed-off-by: Joel Selvaraj
Reviewed-by: Krzysztof Kozlowski
Reviewed-by: Linus Walleij
---
Changes in v2: (Krzysztof Kozlowski's Suggestions)
- Specify maxItems for reg
- Cleanup and simplify the panel properties
- In example change "|+" to "|' and "dsi0" to "dsi"
.../bindings/display/panel/ebbg,ft8719.yaml | 74 +++
1 file changed, 74 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/ebbg,ft8719.yaml
diff --git a/Documentation/devicetree/bindings/display/panel/ebbg,ft8719.yaml
b/Documentation/devicetree/bindings/display/panel/ebbg,ft8719.yaml
new file mode 100644
index ..80deedc01c7c
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/ebbg,ft8719.yaml
@@ -0,0 +1,74 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/ebbg,ft8719.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: EBBG FT8719 MIPI-DSI LCD panel
+
+maintainers:
+ - Joel Selvaraj
+
+description: |
+ The FT8719 panel from EBBG is a FHD+ LCD display panel with a resolution
+ of 1080x2246. It is a video mode DSI panel. The backlight is managed
+ through the QCOM WLED driver.
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+const: ebbg,ft8719
+
+ reg:
+maxItems: 1
+description: DSI virtual channel of the peripheral
+
+ vddio-supply:
+description: power IC supply regulator
+
+ vddpos-supply:
+description: positive boost supply regulator
+
+ vddneg-supply:
+description: negative boost supply regulator
+
+required:
+ - compatible
+ - reg
+ - vddio-supply
+ - vddpos-supply
+ - vddneg-supply
+ - reset-gpios
+ - port
+
+unevaluatedProperties: false
+
+examples:
+ - |
+#include
+
+dsi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ panel@0 {
+compatible = "ebbg,ft8719";
+reg = <0>;
+
+vddio-supply = <_l14a_1p88>;
+vddpos-supply = <>;
+vddneg-supply = <>;
+
+reset-gpios = < 6 GPIO_ACTIVE_LOW>;
+
+backlight = <_wled>;
+
+port {
+ ebbg_ft8719_in_0: endpoint {
+remote-endpoint = <_out>;
+ };
+};
+ };
+};
--
2.36.1
[PATCH v3 1/3] dt-bindings: vendor-prefixes: Add prefix for EBBG
Add a prefix for EBBG. They manufacture displays which are used in some Xiaomi phones, but I could not find much details about the company. Signed-off-by: Joel Selvaraj Acked-by: Krzysztof Kozlowski --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 80e80fa53f8a..effd1cb995cf 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -337,6 +337,8 @@ patternProperties: description: Embedded Artists AB "^ebang,.*": description: Zhejiang Ebang Communication Co., Ltd + "^ebbg,.*": +description: EBBG "^ebs-systart,.*": description: EBS-SYSTART GmbH "^ebv,.*": -- 2.36.1
[PATCH v3 0/3] Introduce EBBG FT8719 DRM panel driver
Add bindings and DRM panel driver for EBBG FT8719 6.18" 2246x1080 DSI video mode panel, which can be found on some Xiaomi Poco F1 phones. The panel's backlight is managed through QCOM WLED driver. The driver is built using linux-mdss-dsi-panel-driver-generator[1], and additionally support for handling regulators and linking external backlight is added. [1] https://github.com/msm8916-mainline/linux-mdss-dsi-panel-driver-generator Changes in v3: (Mostly Linus Walleij's Suggestions) - Removed ctx->prepared state variable as it's handled by the core - Print error in dsi_dcs_write_seq macro if it fails to write - Removed magic power on sequences as panel works fine without them Changes in v2: (Krzysztof Kozlowski's Suggestions) - dt-bindings: specify maxItems for reg - dt-bindings: cleanup and simplify the panel properties - dt-bindings: in example change "|+" to "|' and "dsi0" to "dsi" Joel Selvaraj (3): dt-bindings: vendor-prefixes: Add prefix for EBBG dt-bindings: display: Add bindings for EBBG FT8719 drm/panel: introduce ebbg,ft8719 panel .../bindings/display/panel/ebbg,ft8719.yaml | 74 + .../devicetree/bindings/vendor-prefixes.yaml | 2 + MAINTAINERS | 7 + drivers/gpu/drm/panel/Kconfig | 11 + drivers/gpu/drm/panel/Makefile| 1 + drivers/gpu/drm/panel/panel-ebbg-ft8719.c | 296 ++ 6 files changed, 391 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/ebbg,ft8719.yaml create mode 100644 drivers/gpu/drm/panel/panel-ebbg-ft8719.c -- 2.36.1
Re: [PATCH] dma-fence: allow dma fence to have their own lock
On (22/05/30 16:55), Christian König wrote:
>
> If you just want to create a single dma_fence which is also only bound to a
> single context you can embed the lock into the fence without much problem.
>
> See how the dma_fence_array does that for example:
> https://elixir.bootlin.com/linux/latest/source/include/linux/dma-fence-array.h#L37
Christian, I'm not sure I'm following you on the "embed the lock into the
fence without much problem" part. If I understand it correctly this should
be something like:
fences = kmalloc_array(1, sizeof(*fences), GFP_KERNEL);
for_each_fence(...) {
// what spinlock should I use here?
dma_fence_init([i], .. ..);
dma_fence_get([i]);
}
fence_array = dma_fence_array_create(1, fences, );
sync_file_create(_array->base);
Re: [PATCH] drm/prime: Ensure mmap offset is initialized
On Mon, May 30, 2022 at 7:49 AM Daniel Vetter wrote:
>
> On Mon, 30 May 2022 at 15:54, Rob Clark wrote:
> >
> > On Mon, May 30, 2022 at 12:26 AM Thomas Zimmermann
> > wrote:
> > >
> > > Hi
> > >
> > > Am 29.05.22 um 18:29 schrieb Rob Clark:
> > > > From: Rob Clark
> > > >
> > > > If a GEM object is allocated, and then exported as a dma-buf fd which is
> > > > mmap'd before or without the GEM buffer being directly mmap'd, the
> > > > vma_node could be unitialized. This leads to a situation where the CPU
> > > > mapping is not correctly torn down in drm_vma_node_unmap().
> > >
> > > Which drivers are affected by this problem?
> > >
> > > I checked several drivers and most appear to be initializing the offset
> > > during object construction, such as GEM SHMEM. [1] TTM-based drivers
> > > also seem unaffected. [2]
> > >
> > > From a quick grep, only etnaviv, msm and omapdrm appear to be affected?
> > > They only seem to run drm_gem_create_mmap_offset() from their
> > > ioctl-handling code.
> > >
> > > If so, I'd say it's preferable to fix these drivers and put a
> > > drm_WARN_ONCE() into drm_gem_prime_mmap().
> >
> > That is good if fewer drivers are affected, however I disagree with
> > your proposal. At least for freedreno userspace, a lot of bo's never
> > get mmap'd (either directly of via dmabuf), so we should not be
> > allocating a mmap offset unnecessarily.
>
> Does this actually matter in the grand scheme of things? We originally
> allocated mmap offset only on demand because userspace only had 32bit
> loff_t support and so simply couldn't mmap anything if the offset
> ended up above 32bit (even if there was still va space available).
>
> But those days are long gone (about 10 years or so) and the allocation
> overhead for an mmap offset is tiny. So I think unless you can
> benchmark an impact allocating it at bo alloc seems like the simplest
> design overall, and hence what we should be doing. And if the vma
> offset allocation every gets too slow due to fragmentation we can lift
> the hole tree from i915 into drm_mm and the job should be done. At
> that point we could also allocate the offset unconditionally in the
> gem_init function and be done with it.
>
> Iow I concur with Thomas here, unless there's hard data contrary
> simplicity imo trumps here.
32b userspace is still alive and well, at least on arm chromebooks ;-)
BR,
-R
> -Daniel
>
> >
> > BR,
> > -R
> >
> > > Best regards
> > > Thomas
> > >
> > > [1]
> > > https://elixir.bootlin.com/linux/v5.18/source/drivers/gpu/drm/drm_gem_shmem_helper.c#L85
> > > [2]
> > > https://elixir.bootlin.com/linux/v5.18/source/drivers/gpu/drm/ttm/ttm_bo.c#L1002
> > >
> > > >
> > > > Fixes: e5516553999f ("drm: call drm_gem_object_funcs.mmap with fake
> > > > offset")
> > > > Signed-off-by: Rob Clark
> > > > ---
> > > > Note, it's possible the issue existed in some related form prior to the
> > > > commit tagged with Fixes.
> > > >
> > > > drivers/gpu/drm/drm_prime.c | 5 +
> > > > 1 file changed, 5 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> > > > index e3f09f18110c..849eea154dfc 100644
> > > > --- a/drivers/gpu/drm/drm_prime.c
> > > > +++ b/drivers/gpu/drm/drm_prime.c
> > > > @@ -716,6 +716,11 @@ int drm_gem_prime_mmap(struct drm_gem_object *obj,
> > > > struct vm_area_struct *vma)
> > > > struct file *fil;
> > > > int ret;
> > > >
> > > > + /* Ensure that the vma_node is initialized: */
> > > > + ret = drm_gem_create_mmap_offset(obj);
> > > > + if (ret)
> > > > + return ret;
> > > > +
> > > > /* Add the fake offset */
> > > > vma->vm_pgoff += drm_vma_node_start(>vma_node);
> > > >
> > >
> > > --
> > > Thomas Zimmermann
> > > Graphics Driver Developer
> > > SUSE Software Solutions Germany GmbH
> > > Maxfeldstr. 5, 90409 Nürnberg, Germany
> > > (HRB 36809, AG Nürnberg)
> > > Geschäftsführer: Ivo Totev
>
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
Re: [PATCH] dma-fence: allow dma fence to have their own lock
Hi Christian, On (22/05/30 16:55), Christian König wrote: > Hi Sergey, > > I'm removing most of the mail because you have a very fundamental > misunderstanding about what this dma_fence lock is all about. Happy to learn. > Am 30.05.22 um 16:22 schrieb Sergey Senozhatsky: > > [SNIP] > > So the `lock` should have at least same lifespan as the DMA fence > > that borrows it, which is impossible to guarantee in our case. > > Nope, that's not correct. The lock should have at least same lifespan as the > context of the DMA fence. In our case we have one context and it lives as long as the module is loaded. Does this mean that all DMA fences within that context should be serialized by a single spinlock? We can have a number of "active" fences so the lock can become a bit congested. But each operation creates, exports and signals just once fence. > The idea here is that DMA fence signaling and callback calling serializes. > E.g. when you have fence a,b,c,d... they must signal in the order a,b,c,d... > and that's what this lock is good for. Hmm, OK. So that borrowed ->lock is in fact something like context_lock_irqsave() and context_unlock_irqrestore(). > If you just want to create a single dma_fence which is also only bound to a > single context you can embed the lock into the fence without much problem. Aha, I guess this is what we need then. I'll take a look. Thanks.
[PATCH 4/6] drm/bridge: ti-sn65dsi83: make use of dev_err_probe
Use the new helper to improve the debug capabilities. Signed-off-by: Marco Felsch --- drivers/gpu/drm/bridge/ti-sn65dsi83.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c b/drivers/gpu/drm/bridge/ti-sn65dsi83.c index baf94b2b78a1..3c1dc16985b5 100644 --- a/drivers/gpu/drm/bridge/ti-sn65dsi83.c +++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c @@ -757,7 +757,8 @@ static int sn65dsi83_probe(struct i2c_client *client, ctx->enable_gpio = devm_gpiod_get_optional(ctx->dev, "enable", GPIOD_OUT_LOW); if (IS_ERR(ctx->enable_gpio)) - return PTR_ERR(ctx->enable_gpio); + return dev_err_probe(ctx->dev, PTR_ERR(ctx->enable_gpio), +"Failed to get GPIO\n"); usleep_range(1, 11000); -- 2.30.2
[PATCH 6/6] drm/bridge: ti-sn65dsi83: add support for a external reset controller
The bridge chip has an enable gpio which of course can enable/disable
the bridge. Most the time this gpio is connected directly to the host
but sometimes it is connected to a reset controller chip and the host
controlls the reset controller chip instead. This commit adds the
support to handle that.
Therefore we need either the reset controller or a gpio to be present
and valid. The behaviour is changed in that way that a gpio or a reset
controller have to be successfully requested else the driver probe
fails, like the current behaviour.
Signed-off-by: Marco Felsch
---
drivers/gpu/drm/bridge/ti-sn65dsi83.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c
b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
index 3c1dc16985b5..7b232a4f8bcb 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi83.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
#include
#include
@@ -146,6 +147,7 @@ struct sn65dsi83 {
struct drm_bridge *panel_bridge;
struct gpio_desc*enable_gpio;
struct regulator*vcc;
+ struct reset_control*reset;
int dsi_lanes;
boollvds_dual_link;
boollvds_dual_link_even_odd_swap;
@@ -350,6 +352,7 @@ static void sn65dsi83_atomic_enable(struct drm_bridge
*bridge,
/* Deassert reset */
gpiod_set_value(ctx->enable_gpio, 1);
+ reset_control_deassert(ctx->reset);
usleep_range(1000, 1100);
/* Get the LVDS format from the bridge state. */
@@ -511,6 +514,7 @@ static void sn65dsi83_atomic_disable(struct drm_bridge
*bridge,
/* Put the chip in reset, pull EN line low, and assure 10ms reset low
timing. */
gpiod_set_value(ctx->enable_gpio, 0);
+ reset_control_assert(ctx->reset);
usleep_range(1, 11000);
ret = regulator_disable(ctx->vcc);
@@ -760,6 +764,13 @@ static int sn65dsi83_probe(struct i2c_client *client,
return dev_err_probe(ctx->dev, PTR_ERR(ctx->enable_gpio),
"Failed to get GPIO\n");
+ /* Or use a external reset chip to do so */
+ ctx->reset = devm_reset_control_get_optional(ctx->dev, NULL);
+ if (IS_ERR(ctx->reset))
+ return dev_err_probe(ctx->dev, PTR_ERR(ctx->reset),
+"Failed to get reset\n");
+ reset_control_assert(ctx->reset);
+
usleep_range(1, 11000);
ret = sn65dsi83_parse_dt(ctx, model);
--
2.30.2
[PATCH 5/6] dt-bindings: drm/bridge: ti-sn65dsi83: Add reset controller documentation
The bridge device can now also be enabled/disabled by an external reset controller. So the device now supports either enable/disable by simple GPIO or by an Reset-Controller. Signed-off-by: Marco Felsch --- .../devicetree/bindings/display/bridge/ti,sn65dsi83.yaml| 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml index 7306b9874dc3..eff8360c184e 100644 --- a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml +++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml @@ -35,6 +35,12 @@ properties: vcc-supply: description: A 1.8V power supply (see regulator/regulator.yaml). + resets: +maxItems: 1 +description: | + Reset specifier for bridge_en pin. This is required only if the brdige_en + pin is connected to a reset controller. + ports: $ref: /schemas/graph.yaml#/properties/ports -- 2.30.2
[PATCH 1/6] drm/bridge: ti-sn65dsi83: make lvds lane register setup more readable
No functional change. Just reuse the already existing val variable to setup the register. This is in preparation for adding the new feature to reverse the CHA/CHB lane orders. Without this change this call gets very unreadable. Signed-off-by: Marco Felsch --- drivers/gpu/drm/bridge/ti-sn65dsi83.c | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c b/drivers/gpu/drm/bridge/ti-sn65dsi83.c index 2831f0813c3a..112fea004c8e 100644 --- a/drivers/gpu/drm/bridge/ti-sn65dsi83.c +++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c @@ -437,11 +437,12 @@ static void sn65dsi83_atomic_enable(struct drm_bridge *bridge, regmap_write(ctx->regmap, REG_LVDS_FMT, val); regmap_write(ctx->regmap, REG_LVDS_VCOM, 0x05); - regmap_write(ctx->regmap, REG_LVDS_LANE, -(ctx->lvds_dual_link_even_odd_swap ? - REG_LVDS_LANE_EVEN_ODD_SWAP : 0) | -REG_LVDS_LANE_CHA_LVDS_TERM | -REG_LVDS_LANE_CHB_LVDS_TERM); + + val = REG_LVDS_LANE_CHA_LVDS_TERM | REG_LVDS_LANE_CHB_LVDS_TERM; + if (ctx->lvds_dual_link_even_odd_swap) + val |= REG_LVDS_LANE_EVEN_ODD_SWAP; + + regmap_write(ctx->regmap, REG_LVDS_LANE, val); regmap_write(ctx->regmap, REG_LVDS_CM, 0x00); le16val = cpu_to_le16(mode->hdisplay); -- 2.30.2
[PATCH 0/6] TI SN65DSI83 Features
Hi, the purpose of this small series is to enable the support for the reverse lane feature and to add support for reset controllers which can drive the enable pin. Regards, Marco Marco Felsch (6): drm/bridge: ti-sn65dsi83: make lvds lane register setup more readable dt-bindings: drm/bridge: ti-sn65dsi83: add documentation for reverse lvds lanes drm/bridge: ti-sn65dsi83: add support to swap the LVDS data lanes drm/bridge: ti-sn65dsi83: make use of dev_err_probe dt-bindings: drm/bridge: ti-sn65dsi83: Add reset controller documentation drm/bridge: ti-sn65dsi83: add support for a external reset controller .../bindings/display/bridge/ti,sn65dsi83.yaml | 64 - drivers/gpu/drm/bridge/ti-sn65dsi83.c | 89 +-- 2 files changed, 145 insertions(+), 8 deletions(-) -- 2.30.2
[PATCH 3/6] drm/bridge: ti-sn65dsi83: add support to swap the LVDS data lanes
The chip can swap the LVDS channel A/B data lanes e.g. to improve the
layout characteristic. This commit adds the feature so the system
integrator can specify it within the device-tree.
Signed-off-by: Marco Felsch
---
drivers/gpu/drm/bridge/ti-sn65dsi83.c | 64 +++
1 file changed, 64 insertions(+)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c
b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
index 112fea004c8e..baf94b2b78a1 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi83.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include
#include
@@ -148,6 +149,8 @@ struct sn65dsi83 {
int dsi_lanes;
boollvds_dual_link;
boollvds_dual_link_even_odd_swap;
+ boollvds_reverse_cha;
+ boollvds_reverse_chb;
};
static const struct regmap_range sn65dsi83_readable_ranges[] = {
@@ -441,6 +444,10 @@ static void sn65dsi83_atomic_enable(struct drm_bridge
*bridge,
val = REG_LVDS_LANE_CHA_LVDS_TERM | REG_LVDS_LANE_CHB_LVDS_TERM;
if (ctx->lvds_dual_link_even_odd_swap)
val |= REG_LVDS_LANE_EVEN_ODD_SWAP;
+ if (ctx->lvds_reverse_cha)
+ val |= REG_LVDS_LANE_CHA_REVERSE_LVDS;
+ if (ctx->lvds_reverse_chb)
+ val |= REG_LVDS_LANE_CHB_REVERSE_LVDS;
regmap_write(ctx->regmap, REG_LVDS_LANE, val);
regmap_write(ctx->regmap, REG_LVDS_CM, 0x00);
@@ -566,6 +573,47 @@ static const struct drm_bridge_funcs sn65dsi83_funcs = {
.atomic_get_input_bus_fmts = sn65dsi83_atomic_get_input_bus_fmts,
};
+static int sn65dsi83_parse_lvds_lane_order(struct sn65dsi83 *ctx, unsigned
char port)
+{
+ struct device *dev = ctx->dev;
+ struct device_node *ep;
+ int lvds_lanes;
+ int ret = 0;
+
+ if (port < 2 || port > 3)
+ return -EINVAL;
+
+ ep = of_graph_get_endpoint_by_regs(dev->of_node, port, 0);
+ lvds_lanes = of_property_count_u32_elems(ep, "data-lanes");
+ if (lvds_lanes == 4) {
+ u32 lane_assignments[] = { 1, 2, 3, 4 };
+
+ of_property_read_u32_array(ep, "data-lanes", lane_assignments,
+ lvds_lanes);
+ if (lane_assignments[0] == 4 &&
+ lane_assignments[1] == 3 &&
+ lane_assignments[2] == 2 &&
+ lane_assignments[3] == 1) {
+ if (port == 2)
+ ctx->lvds_reverse_cha = true;
+ else
+ ctx->lvds_reverse_chb = true;
+ } else if (lane_assignments[0] != 1 ||
+ lane_assignments[1] != 2 ||
+ lane_assignments[2] != 3 ||
+ lane_assignments[3] != 4) {
+ dev_err(dev, "Unsupported LVDS lane order\n");
+ ret = -EINVAL;
+ }
+ } else if (lvds_lanes > 0) {
+ dev_err(dev, "All 4 LVDS data-lanes must be specified\n");
+ ret = -EINVAL;
+ }
+ of_node_put(ep);
+
+ return ret;
+}
+
static int sn65dsi83_parse_dt(struct sn65dsi83 *ctx, enum sn65dsi83_model
model)
{
struct drm_bridge *panel_bridge;
@@ -610,6 +658,22 @@ static int sn65dsi83_parse_dt(struct sn65dsi83 *ctx, enum
sn65dsi83_model model)
}
}
+ /*
+* Todo:
+* Check if the reverse lane setup is working in dual-link as well.
+*/
+ if (!ctx->lvds_dual_link) {
+ ret = sn65dsi83_parse_lvds_lane_order(ctx, 2);
+ if (ret)
+ return ret;
+
+ if (model != MODEL_SN65DSI83) {
+ ret = sn65dsi83_parse_lvds_lane_order(ctx, 3);
+ if (ret)
+ return ret;
+ }
+ }
+
panel_bridge = devm_drm_of_get_bridge(dev, dev->of_node, 2, 0);
if (IS_ERR(panel_bridge)) {
ret = PTR_ERR(panel_bridge);
--
2.30.2
[PATCH 2/6] dt-bindings: drm/bridge: ti-sn65dsi83: add documentation for reverse lvds lanes
The TI converter chip can swap the LVDS data lanes in a pre-defined manner. This can be useful to improve the layout characteristic. Signed-off-by: Marco Felsch --- .../bindings/display/bridge/ti,sn65dsi83.yaml | 58 ++- 1 file changed, 56 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml index 48a97bb3e2e0..7306b9874dc3 100644 --- a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml +++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml @@ -80,13 +80,67 @@ properties: - const: 4 port@2: -$ref: /schemas/graph.yaml#/properties/port +$ref: /schemas/graph.yaml#/$defs/port-base +unevaluatedProperties: false description: Video port for LVDS Channel-A output (panel or bridge). +properties: + endpoint: +$ref: /schemas/media/video-interfaces.yaml# +unevaluatedProperties: false + +properties: + data-lanes: +description: | + Array of physical LVDS data lane indexes in reverse or normal + order. Specify it in reverse order to enable the bridge CHA + reverse ordering. If not specified normal order is used. +items: + oneOf: +# reverse order +- items: +- const: 4 +- const: 3 +- const: 2 +- const: 1 +# normal order +- items: +- const: 1 +- const: 2 +- const: 3 +- const: 4 + port@3: -$ref: /schemas/graph.yaml#/properties/port +$ref: /schemas/graph.yaml#/$defs/port-base +unevaluatedProperties: false description: Video port for LVDS Channel-B output (panel or bridge). +properties: + endpoint: +$ref: /schemas/media/video-interfaces.yaml# +unevaluatedProperties: false + +properties: + data-lanes: +description: | + Array of physical LVDS data lane indexes in reverse or normal + order. Specify it in reverse order to enable the bridge CHB + reverse ordering. If not specified normal order is used. +items: + oneOf: +# reverse order +- items: +- const: 4 +- const: 3 +- const: 2 +- const: 1 +# normal order +- items: +- const: 1 +- const: 2 +- const: 3 +- const: 4 + required: - port@0 - port@2 -- 2.30.2
Re: [PATCH] dma-fence: allow dma fence to have their own lock
Hi Sergey, I'm removing most of the mail because you have a very fundamental misunderstanding about what this dma_fence lock is all about. Am 30.05.22 um 16:22 schrieb Sergey Senozhatsky: [SNIP] So the `lock` should have at least same lifespan as the DMA fence that borrows it, which is impossible to guarantee in our case. Nope, that's not correct. The lock should have at least same lifespan as the context of the DMA fence. The idea here is that DMA fence signaling and callback calling serializes. E.g. when you have fence a,b,c,d... they must signal in the order a,b,c,d... and that's what this lock is good for. If you just want to create a single dma_fence which is also only bound to a single context you can embed the lock into the fence without much problem. See how the dma_fence_array does that for example: https://elixir.bootlin.com/linux/latest/source/include/linux/dma-fence-array.h#L37 Regards, Christian.
Re: [PATCH] drm/prime: Ensure mmap offset is initialized
On Mon, 30 May 2022 at 15:54, Rob Clark wrote:
>
> On Mon, May 30, 2022 at 12:26 AM Thomas Zimmermann
> wrote:
> >
> > Hi
> >
> > Am 29.05.22 um 18:29 schrieb Rob Clark:
> > > From: Rob Clark
> > >
> > > If a GEM object is allocated, and then exported as a dma-buf fd which is
> > > mmap'd before or without the GEM buffer being directly mmap'd, the
> > > vma_node could be unitialized. This leads to a situation where the CPU
> > > mapping is not correctly torn down in drm_vma_node_unmap().
> >
> > Which drivers are affected by this problem?
> >
> > I checked several drivers and most appear to be initializing the offset
> > during object construction, such as GEM SHMEM. [1] TTM-based drivers
> > also seem unaffected. [2]
> >
> > From a quick grep, only etnaviv, msm and omapdrm appear to be affected?
> > They only seem to run drm_gem_create_mmap_offset() from their
> > ioctl-handling code.
> >
> > If so, I'd say it's preferable to fix these drivers and put a
> > drm_WARN_ONCE() into drm_gem_prime_mmap().
>
> That is good if fewer drivers are affected, however I disagree with
> your proposal. At least for freedreno userspace, a lot of bo's never
> get mmap'd (either directly of via dmabuf), so we should not be
> allocating a mmap offset unnecessarily.
Does this actually matter in the grand scheme of things? We originally
allocated mmap offset only on demand because userspace only had 32bit
loff_t support and so simply couldn't mmap anything if the offset
ended up above 32bit (even if there was still va space available).
But those days are long gone (about 10 years or so) and the allocation
overhead for an mmap offset is tiny. So I think unless you can
benchmark an impact allocating it at bo alloc seems like the simplest
design overall, and hence what we should be doing. And if the vma
offset allocation every gets too slow due to fragmentation we can lift
the hole tree from i915 into drm_mm and the job should be done. At
that point we could also allocate the offset unconditionally in the
gem_init function and be done with it.
Iow I concur with Thomas here, unless there's hard data contrary
simplicity imo trumps here.
-Daniel
>
> BR,
> -R
>
> > Best regards
> > Thomas
> >
> > [1]
> > https://elixir.bootlin.com/linux/v5.18/source/drivers/gpu/drm/drm_gem_shmem_helper.c#L85
> > [2]
> > https://elixir.bootlin.com/linux/v5.18/source/drivers/gpu/drm/ttm/ttm_bo.c#L1002
> >
> > >
> > > Fixes: e5516553999f ("drm: call drm_gem_object_funcs.mmap with fake
> > > offset")
> > > Signed-off-by: Rob Clark
> > > ---
> > > Note, it's possible the issue existed in some related form prior to the
> > > commit tagged with Fixes.
> > >
> > > drivers/gpu/drm/drm_prime.c | 5 +
> > > 1 file changed, 5 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> > > index e3f09f18110c..849eea154dfc 100644
> > > --- a/drivers/gpu/drm/drm_prime.c
> > > +++ b/drivers/gpu/drm/drm_prime.c
> > > @@ -716,6 +716,11 @@ int drm_gem_prime_mmap(struct drm_gem_object *obj,
> > > struct vm_area_struct *vma)
> > > struct file *fil;
> > > int ret;
> > >
> > > + /* Ensure that the vma_node is initialized: */
> > > + ret = drm_gem_create_mmap_offset(obj);
> > > + if (ret)
> > > + return ret;
> > > +
> > > /* Add the fake offset */
> > > vma->vm_pgoff += drm_vma_node_start(>vma_node);
> > >
> >
> > --
> > Thomas Zimmermann
> > Graphics Driver Developer
> > SUSE Software Solutions Germany GmbH
> > Maxfeldstr. 5, 90409 Nürnberg, Germany
> > (HRB 36809, AG Nürnberg)
> > Geschäftsführer: Ivo Totev
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH AUTOSEL 4.19 16/38] drm/sun4i: Add support for D1 TCONs
Hi Sasha,
On 5/30/22 8:49 AM, Sasha Levin wrote:
> From: Samuel Holland
>
> [ Upstream commit b9b52d2f4aafa2bd637ace0f24615bdad8e49f01 ]
>
> D1 has a TCON TOP, so its quirks are similar to those for the R40 TCONs.
> While there are some register changes, the part of the TCON TV supported
> by the driver matches the R40 quirks, so that quirks structure can be
> reused. D1 has the first supported TCON LCD with a TCON TOP, so the TCON
> LCD needs a new quirks structure.
>
> D1's TCON LCD hardware supports LVDS; in fact it provides dual-link LVDS
> from a single TCON. However, it comes with a brand new LVDS PHY. Since
> this PHY has not been tested, leave out LVDS driver support for now.
>
> Signed-off-by: Samuel Holland
> Reviewed-by: Jernej Skrabec
> Signed-off-by: Maxime Ripard
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20220424162633.12369-14-sam...@sholland.org
> Signed-off-by: Sasha Levin
This patch adds support for hardware in a SoC that will not boot on earlier
kernel releases, so there is no benefit to backporting the patch (to any
previous release).
Regards,
Samuel
> ---
> drivers/gpu/drm/sun4i/sun4i_tcon.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> index 113c032a2720..0ebb7c1dfee6 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> @@ -1316,6 +1316,12 @@ static const struct sun4i_tcon_quirks
> sun9i_a80_tcon_tv_quirks = {
> .needs_edp_reset = true,
> };
>
> +static const struct sun4i_tcon_quirks sun20i_d1_lcd_quirks = {
> + .has_channel_0 = true,
> + .dclk_min_div = 1,
> + .set_mux= sun8i_r40_tcon_tv_set_mux,
> +};
> +
> /* sun4i_drv uses this list to check if a device node is a TCON */
> const struct of_device_id sun4i_tcon_of_table[] = {
> { .compatible = "allwinner,sun4i-a10-tcon", .data = _a10_quirks },
> @@ -1329,6 +1335,8 @@ const struct of_device_id sun4i_tcon_of_table[] = {
> { .compatible = "allwinner,sun8i-v3s-tcon", .data = _v3s_quirks },
> { .compatible = "allwinner,sun9i-a80-tcon-lcd", .data =
> _a80_tcon_lcd_quirks },
> { .compatible = "allwinner,sun9i-a80-tcon-tv", .data =
> _a80_tcon_tv_quirks },
> + { .compatible = "allwinner,sun20i-d1-tcon-lcd", .data =
> _d1_lcd_quirks },
> + { .compatible = "allwinner,sun20i-d1-tcon-tv", .data =
> _r40_tv_quirks },
> { }
> };
> MODULE_DEVICE_TABLE(of, sun4i_tcon_of_table);
>
Re: [PATCH] drm/prime: Ensure mmap offset is initialized
On Mon, May 30, 2022 at 7:16 AM Thomas Zimmermann wrote:
>
> Hi
>
> Am 30.05.22 um 15:47 schrieb Rob Clark:
> > On Mon, May 30, 2022 at 12:26 AM Thomas Zimmermann
> > wrote:
> >>
> >> Hi
> >>
> >> Am 29.05.22 um 18:29 schrieb Rob Clark:
> >>> From: Rob Clark
> >>>
> >>> If a GEM object is allocated, and then exported as a dma-buf fd which is
> >>> mmap'd before or without the GEM buffer being directly mmap'd, the
> >>> vma_node could be unitialized. This leads to a situation where the CPU
> >>> mapping is not correctly torn down in drm_vma_node_unmap().
> >>
> >> Which drivers are affected by this problem?
> >>
> >> I checked several drivers and most appear to be initializing the offset
> >> during object construction, such as GEM SHMEM. [1] TTM-based drivers
> >> also seem unaffected. [2]
> >>
> >> From a quick grep, only etnaviv, msm and omapdrm appear to be affected?
> >> They only seem to run drm_gem_create_mmap_offset() from their
> >> ioctl-handling code.
> >>
> >> If so, I'd say it's preferable to fix these drivers and put a
> >> drm_WARN_ONCE() into drm_gem_prime_mmap().
> >
> > That is good if fewer drivers are affected, however I disagree with
> > your proposal. At least for freedreno userspace, a lot of bo's never
> > get mmap'd (either directly of via dmabuf), so we should not be
> > allocating a mmap offset unnecessarily.
>
> I see.
>
> I the reason I'm arguing against the current patch is that the fix
> appears like a workaround and 6 months from now, few will remember why
> it's there. Especially since most drivers initialize the offset
> correctly. (Not too long ago, I refactored the handling of these mmap
> calls throughout DRM drivers and it was confusing at times.)
I dispute the "correctly" part.. and that this is a workaround ;-)
But I can send a v2 with the addition of a comment explaining the
reason, so git-blame archeology isn't required to understand the
reasoning
BR,
-R
> So here's another suggestion: I further looked at the 3 drivers that I
> mentioned. etnaviv and msm can easily wrap the call to
> drm_gem_prime_mmap() and init the offset first. [1][2] omapdrm doesn't
> actually use drm_gem_prime_mmap(). The offset can instead be initialized
> at the top of the driver's dmabuf mmap function. [3]
>
> Best regards
> Thomas
>
> [1]
> https://elixir.bootlin.com/linux/v5.18/source/drivers/gpu/drm/etnaviv/etnaviv_drv.c#L480
> [2]
> https://elixir.bootlin.com/linux/v5.18/source/drivers/gpu/drm/msm/msm_drv.c#L961
> [3]
> https://elixir.bootlin.com/linux/v5.18/source/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c#L66
>
> >
> > BR,
> > -R
> >
> >> Best regards
> >> Thomas
> >>
> >> [1]
> >> https://elixir.bootlin.com/linux/v5.18/source/drivers/gpu/drm/drm_gem_shmem_helper.c#L85
> >> [2]
> >> https://elixir.bootlin.com/linux/v5.18/source/drivers/gpu/drm/ttm/ttm_bo.c#L1002
> >>
> >>>
> >>> Fixes: e5516553999f ("drm: call drm_gem_object_funcs.mmap with fake
> >>> offset")
> >>> Signed-off-by: Rob Clark
> >>> ---
> >>> Note, it's possible the issue existed in some related form prior to the
> >>> commit tagged with Fixes.
> >>>
> >>>drivers/gpu/drm/drm_prime.c | 5 +
> >>>1 file changed, 5 insertions(+)
> >>>
> >>> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> >>> index e3f09f18110c..849eea154dfc 100644
> >>> --- a/drivers/gpu/drm/drm_prime.c
> >>> +++ b/drivers/gpu/drm/drm_prime.c
> >>> @@ -716,6 +716,11 @@ int drm_gem_prime_mmap(struct drm_gem_object *obj,
> >>> struct vm_area_struct *vma)
> >>>struct file *fil;
> >>>int ret;
> >>>
> >>> + /* Ensure that the vma_node is initialized: */
> >>> + ret = drm_gem_create_mmap_offset(obj);
> >>> + if (ret)
> >>> + return ret;
> >>> +
> >>>/* Add the fake offset */
> >>>vma->vm_pgoff += drm_vma_node_start(>vma_node);
> >>>
> >>
> >> --
> >> Thomas Zimmermann
> >> Graphics Driver Developer
> >> SUSE Software Solutions Germany GmbH
> >> Maxfeldstr. 5, 90409 Nürnberg, Germany
> >> (HRB 36809, AG Nürnberg)
> >> Geschäftsführer: Ivo Totev
>
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> (HRB 36809, AG Nürnberg)
> Geschäftsführer: Ivo Totev
Re: mainline build failure due to f1e4c916f97f ("drm/edid: add EDID block count and size helpers")
On Mon, May 30, 2022 at 4:08 PM Jani Nikula wrote:
> On Mon, 30 May 2022, Arnd Bergmann wrote:
> > struct my_driver_priv {
> >struct device dev;
> >u8 causes_misalignment;
> >spinlock_t lock;
> >atomic_t counter;
> > } __packed; /* this annotation is harmful because it breaks the atomics */
>
> I wonder if this is something that could be caught with coccinelle. Or
> sparse. Are there any cases where this combo is necessary? (I can't
> think of any, but it's a low bar. ;)
>
> Cc: Julia.
I think one would first have to make a list of data types that are not
meant to be in a packed structure. It could be a good start to
search for any packed aggregates with a pointer, atomic_t or spinlock_t
in them, but there are of course many more types that you won't
find in hardware structures.
> > or if the annotation does not change the layout like
> >
> > struct my_dma_descriptor {
> > __le64 address;
> > __le64 length;
> > } __packed; /* does not change layout but makes access slow on some
> > architectures */
>
> Why is this the case, though? I'd imagine the compiler could figure this
> out.
When you annotate the entire structure as __packed without an
extra __aligned() annotation, the compiler has to assume that the
structure itself is unaligned as well. On many of the older architectures,
this will result in accessing the values one byte at a time. Marking
the structure as "__packed __aligned(8)" instead would be harmless.
When I have a structure with a few misaligned members, I generally
prefer to only annotate the members that are not naturally aligned,
but this approach is not very common.
Arnd
[PATCH] dma-fence: allow dma fence to have their own lock
RFC
I don't have a good name for this yet and I did not spend
any time on documentataion (for that reason)
We create fences (out fences) as part of operations execution, which
are short-lived objects, we want to release all memory after operation
execution is completed or when operation gets cancelled/deleted via
ioctl().
This creates a bit of a problem. DMA fences are refcounted objects and
exporter never knows when importer imports a fence or puts its refcount,
so exporter never knows when fence will be destoyed, which should not
be a problem for refcounted objects, but here comes the twist...
operation A - creates and exports out fence X
... user-space imports fence X
operation A - finishes execution, signals fence X
kfree operation A, put dma_fence
DMA fences are designed to borrow spinlock that DMA fences use to
protect struct dma_fence members:
struct dma_fence {
spinlock_t *lock;
const struct dma_fence_ops *ops;
.
};
void dma_fence_init(struct dma_fence *fence,
const struct dma_fence_ops *ops,
spinlock_t *lock,
u64 context,
u64 seqno);
So the `lock` should have at least same lifespan as the DMA fence
that borrows it, which is impossible to guarantee in our case. When
we kfree operation A struct we also kfree ->lock that operation
lends to DMA fence, which outlives operation A (depending on what
fence importers do and when they drop imported fence refcount).
This patch adds a new memnber to struct dma_fence: __lock_inplace.
Which is a lock that DMA fence will use to protect its own data when
it cannot reliably borrow a lock from the outside object.
I also had a patch that puts inplace and borrowed locks to an unnamed
uninon and adds one more dma_fence_flag_bits to distinguish between
fences with borrowed and inplace locks
struct dma_fence {
uninon {
spinlock_t *lock;
spinlock_t __lock_inplace;
};
...
};
And then instead of locking/unlocking ->lock directly we would use
dma_fence_lock_irqsave()/dma_fence_unlock_irqrestore() macros which
would check fence flags and either use borrowed lock or inplace lock.
But after seeing how owten drivers directly access fence ->lock I
decided to scratch that approach and just add extra spinlock member.
Not-Yet-Signed-off-by: Sergey Senozhatsky
---
drivers/dma-buf/dma-fence.c | 10 ++
include/linux/dma-fence.h | 6 ++
2 files changed, 16 insertions(+)
diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index 066400ed8841..7ae40b8adb73 100644
--- a/drivers/dma-buf/dma-fence.c
+++ b/drivers/dma-buf/dma-fence.c
@@ -958,3 +958,13 @@ dma_fence_init(struct dma_fence *fence, const struct
dma_fence_ops *ops,
trace_dma_fence_init(fence);
}
EXPORT_SYMBOL(dma_fence_init);
+
+void dma_fence_inplace_lock_init(struct dma_fence *fence,
+const struct dma_fence_ops *ops,
+u64 context, u64 seqno)
+{
+ spin_lock_init(>__lock_inplace);
+
+ dma_fence_init(fence, ops, >__lock_inplace, context, seqno);
+}
+EXPORT_SYMBOL(dma_fence_inplace_lock_init);
diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
index 1ea691753bd3..6b15a0d2eccf 100644
--- a/include/linux/dma-fence.h
+++ b/include/linux/dma-fence.h
@@ -64,6 +64,8 @@ struct dma_fence_cb;
*/
struct dma_fence {
spinlock_t *lock;
+ spinlock_t __lock_inplace;
+
const struct dma_fence_ops *ops;
/*
* We clear the callback list on kref_put so that by the time we
@@ -262,6 +264,10 @@ struct dma_fence_ops {
void dma_fence_init(struct dma_fence *fence, const struct dma_fence_ops *ops,
spinlock_t *lock, u64 context, u64 seqno);
+void dma_fence_inplace_lock_init(struct dma_fence *fence,
+const struct dma_fence_ops *ops,
+u64 context, u64 seqno);
+
void dma_fence_release(struct kref *kref);
void dma_fence_free(struct dma_fence *fence);
void dma_fence_describe(struct dma_fence *fence, struct seq_file *seq);
--
2.36.1.124.g0e6072fb45-goog
Re: [PATCH] drm/prime: Ensure mmap offset is initialized
Hi
Am 30.05.22 um 15:47 schrieb Rob Clark:
On Mon, May 30, 2022 at 12:26 AM Thomas Zimmermann wrote:
Hi
Am 29.05.22 um 18:29 schrieb Rob Clark:
From: Rob Clark
If a GEM object is allocated, and then exported as a dma-buf fd which is
mmap'd before or without the GEM buffer being directly mmap'd, the
vma_node could be unitialized. This leads to a situation where the CPU
mapping is not correctly torn down in drm_vma_node_unmap().
Which drivers are affected by this problem?
I checked several drivers and most appear to be initializing the offset
during object construction, such as GEM SHMEM. [1] TTM-based drivers
also seem unaffected. [2]
From a quick grep, only etnaviv, msm and omapdrm appear to be affected?
They only seem to run drm_gem_create_mmap_offset() from their
ioctl-handling code.
If so, I'd say it's preferable to fix these drivers and put a
drm_WARN_ONCE() into drm_gem_prime_mmap().
That is good if fewer drivers are affected, however I disagree with
your proposal. At least for freedreno userspace, a lot of bo's never
get mmap'd (either directly of via dmabuf), so we should not be
allocating a mmap offset unnecessarily.
I see.
I the reason I'm arguing against the current patch is that the fix
appears like a workaround and 6 months from now, few will remember why
it's there. Especially since most drivers initialize the offset
correctly. (Not too long ago, I refactored the handling of these mmap
calls throughout DRM drivers and it was confusing at times.)
So here's another suggestion: I further looked at the 3 drivers that I
mentioned. etnaviv and msm can easily wrap the call to
drm_gem_prime_mmap() and init the offset first. [1][2] omapdrm doesn't
actually use drm_gem_prime_mmap(). The offset can instead be initialized
at the top of the driver's dmabuf mmap function. [3]
Best regards
Thomas
[1]
https://elixir.bootlin.com/linux/v5.18/source/drivers/gpu/drm/etnaviv/etnaviv_drv.c#L480
[2]
https://elixir.bootlin.com/linux/v5.18/source/drivers/gpu/drm/msm/msm_drv.c#L961
[3]
https://elixir.bootlin.com/linux/v5.18/source/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c#L66
BR,
-R
Best regards
Thomas
[1]
https://elixir.bootlin.com/linux/v5.18/source/drivers/gpu/drm/drm_gem_shmem_helper.c#L85
[2]
https://elixir.bootlin.com/linux/v5.18/source/drivers/gpu/drm/ttm/ttm_bo.c#L1002
Fixes: e5516553999f ("drm: call drm_gem_object_funcs.mmap with fake offset")
Signed-off-by: Rob Clark
---
Note, it's possible the issue existed in some related form prior to the
commit tagged with Fixes.
drivers/gpu/drm/drm_prime.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index e3f09f18110c..849eea154dfc 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -716,6 +716,11 @@ int drm_gem_prime_mmap(struct drm_gem_object *obj, struct
vm_area_struct *vma)
struct file *fil;
int ret;
+ /* Ensure that the vma_node is initialized: */
+ ret = drm_gem_create_mmap_offset(obj);
+ if (ret)
+ return ret;
+
/* Add the fake offset */
vma->vm_pgoff += drm_vma_node_start(>vma_node);
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
OpenPGP_signature
Description: OpenPGP digital signature
[PATCH AUTOSEL 4.19 18/38] drm/plane: Move range check for format_count earlier
From: Steven Price
[ Upstream commit 4b674dd69701c2e22e8e7770c1706a69f3b17269 ]
While the check for format_count > 64 in __drm_universal_plane_init()
shouldn't be hit (it's a WARN_ON), in its current position it will then
leak the plane->format_types array and fail to call
drm_mode_object_unregister() leaking the modeset identifier. Move it to
the start of the function to avoid allocating those resources in the
first place.
Signed-off-by: Steven Price
Signed-off-by: Liviu Dudau
Link:
https://lore.kernel.org/dri-devel/20211203102815.38624-1-steven.pr...@arm.com/
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/drm_plane.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 2411b6de055e..425e76e39b3b 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -177,6 +177,13 @@ int drm_universal_plane_init(struct drm_device *dev,
struct drm_plane *plane,
if (WARN_ON(config->num_total_plane >= 32))
return -EINVAL;
+ /*
+* First driver to need more than 64 formats needs to fix this. Each
+* format is encoded as a bit and the current code only supports a u64.
+*/
+ if (WARN_ON(format_count > 64))
+ return -EINVAL;
+
WARN_ON(drm_drv_uses_atomic_modeset(dev) &&
(!funcs->atomic_destroy_state ||
!funcs->atomic_duplicate_state));
@@ -198,13 +205,6 @@ int drm_universal_plane_init(struct drm_device *dev,
struct drm_plane *plane,
return -ENOMEM;
}
- /*
-* First driver to need more than 64 formats needs to fix this. Each
-* format is encoded as a bit and the current code only supports a u64.
-*/
- if (WARN_ON(format_count > 64))
- return -EINVAL;
-
if (format_modifiers) {
const uint64_t *temp_modifiers = format_modifiers;
while (*temp_modifiers++ != DRM_FORMAT_MOD_INVALID)
--
2.35.1
Re: mainline build failure due to f1e4c916f97f ("drm/edid: add EDID block count and size helpers")
On Mon, 30 May 2022, Arnd Bergmann wrote:
> On Mon, May 30, 2022 at 3:10 PM Jani Nikula wrote:
>> >
>> > I think in general, most __packed annotations we have in the kernel are
>> > completely pointless because they do not change the structure layout on
>> > any architecture but instead just make member access slower on
>>
>> Please explain.
>>
>> They are used quite a bit for parsing blob data, or
>> serialization/deserialization, like in the EDID case at hand. Try
>> removing __attribute__((packed)) from include/drm/drm_edid.h and see the
>> sizeof(struct edid) on any architecture.
>
> The annotations for edid are completely correct and necessary. However
> other driver authors just slap __packed annotations on any structure
> even if the layout is not fixed at all like:
Right. Thanks for the examples.
> struct my_driver_priv {
>struct device dev;
>u8 causes_misalignment;
>spinlock_t lock;
>atomic_t counter;
> } __packed; /* this annotation is harmful because it breaks the atomics */
I wonder if this is something that could be caught with coccinelle. Or
sparse. Are there any cases where this combo is necessary? (I can't
think of any, but it's a low bar. ;)
Cc: Julia.
> or if the annotation does not change the layout like
>
> struct my_dma_descriptor {
> __le64 address;
> __le64 length;
> } __packed; /* does not change layout but makes access slow on some
> architectures */
Why is this the case, though? I'd imagine the compiler could figure this
out.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
[PATCH] drm/ssd130x: Only define a SPI device ID table when built as a module
The kernel test robot reports a compile warning due the ssd130x_spi_table
variable being defined but not used. This happen when ssd130x-spi driver
is built-in instead of being built as a module, i.e:
CC drivers/gpu/drm/solomon/ssd130x-spi.o
AR drivers/base/firmware_loader/built-in.a
AR drivers/base/built-in.a
CC kernel/trace/trace.o
drivers/gpu/drm/solomon/ssd130x-spi.c:155:35: warning: ‘ssd130x_spi_table’
defined but not used [-Wunused-const-variable=]
155 | static const struct spi_device_id ssd130x_spi_table[] = {
| ^
The driver shouldn't need a SPI device ID table and only have an OF device
ID table, but the former is needed to workaround an issue in the SPI core.
This always reports a MODALIAS of the form "spi:" even for devices
registered through Device Trees.
But the table is only needed when the driver built as a module to populate
the .ko alias info. It's not needed when the driver is built-in the kernel.
Fixes: 74373977d2ca ("drm/solomon: Add SSD130x OLED displays SPI support")
Reported-by: kernel test robot
Signed-off-by: Javier Martinez Canillas
---
drivers/gpu/drm/solomon/ssd130x-spi.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/solomon/ssd130x-spi.c
b/drivers/gpu/drm/solomon/ssd130x-spi.c
index 43722adab1f8..07802907e39a 100644
--- a/drivers/gpu/drm/solomon/ssd130x-spi.c
+++ b/drivers/gpu/drm/solomon/ssd130x-spi.c
@@ -143,6 +143,7 @@ static const struct of_device_id ssd130x_of_match[] = {
};
MODULE_DEVICE_TABLE(of, ssd130x_of_match);
+#if IS_MODULE(CONFIG_DRM_SSD130X_SPI)
/*
* The SPI core always reports a MODALIAS uevent of the form "spi:", even
* if the device was registered via OF. This means that the module will not be
@@ -160,6 +161,7 @@ static const struct spi_device_id ssd130x_spi_table[] = {
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(spi, ssd130x_spi_table);
+#endif
static struct spi_driver ssd130x_spi_driver = {
.driver = {
--
2.36.1
[PATCH AUTOSEL 5.15 015/109] drm/komeda: return early if drm_universal_plane_init() fails.
From: Liviu Dudau
[ Upstream commit c8f76c37cc3668ee45e081e76a15f24a352ebbdd ]
If drm_universal_plane_init() fails early we jump to the common cleanup code
that calls komeda_plane_destroy() which in turn could access the uninitalised
drm_plane and crash. Return early if an error is detected without going through
the common code.
Reported-by: Steven Price
Reviewed-by: Steven Price
Signed-off-by: Liviu Dudau
Link:
https://lore.kernel.org/dri-devel/20211203100946.2706922-1-liviu.du...@arm.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/arm/display/komeda/komeda_plane.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
b/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
index d63d83800a8a..d646e3ae1a23 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
@@ -275,8 +275,10 @@ static int komeda_plane_add(struct komeda_kms_dev *kms,
komeda_put_fourcc_list(formats);
- if (err)
- goto cleanup;
+ if (err) {
+ kfree(kplane);
+ return err;
+ }
drm_plane_helper_add(plane, _plane_helper_funcs);
--
2.35.1
[PATCH AUTOSEL 4.19 10/38] drm/amd/pm: fix double free in si_parse_power_table()
From: Keita Suzuki
[ Upstream commit f3fa2becf2fc25b6ac7cf8d8b1a2e4a86b3b72bd ]
In function si_parse_power_table(), array adev->pm.dpm.ps and its member
is allocated. If the allocation of each member fails, the array itself
is freed and returned with an error code. However, the array is later
freed again in si_dpm_fini() function which is called when the function
returns an error.
This leads to potential double free of the array adev->pm.dpm.ps, as
well as leak of its array members, since the members are not freed in
the allocation function and the array is not nulled when freed.
In addition adev->pm.dpm.num_ps, which keeps track of the allocated
array member, is not updated until the member allocation is
successfully finished, this could also lead to either use after free,
or uninitialized variable access in si_dpm_fini().
Fix this by postponing the free of the array until si_dpm_fini() and
increment adev->pm.dpm.num_ps everytime the array member is allocated.
Signed-off-by: Keita Suzuki
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/si_dpm.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/si_dpm.c
b/drivers/gpu/drm/amd/amdgpu/si_dpm.c
index 1de96995e690..9f811051ceb0 100644
--- a/drivers/gpu/drm/amd/amdgpu/si_dpm.c
+++ b/drivers/gpu/drm/amd/amdgpu/si_dpm.c
@@ -7247,17 +7247,15 @@ static int si_parse_power_table(struct amdgpu_device
*adev)
if (!adev->pm.dpm.ps)
return -ENOMEM;
power_state_offset = (u8 *)state_array->states;
- for (i = 0; i < state_array->ucNumEntries; i++) {
+ for (adev->pm.dpm.num_ps = 0, i = 0; i < state_array->ucNumEntries;
i++) {
u8 *idx;
power_state = (union pplib_power_state *)power_state_offset;
non_clock_array_index = power_state->v2.nonClockInfoIndex;
non_clock_info = (struct _ATOM_PPLIB_NONCLOCK_INFO *)
_clock_info_array->nonClockInfo[non_clock_array_index];
ps = kzalloc(sizeof(struct si_ps), GFP_KERNEL);
- if (ps == NULL) {
- kfree(adev->pm.dpm.ps);
+ if (ps == NULL)
return -ENOMEM;
- }
adev->pm.dpm.ps[i].ps_priv = ps;
si_parse_pplib_non_clock_info(adev, >pm.dpm.ps[i],
non_clock_info,
@@ -7279,8 +7277,8 @@ static int si_parse_power_table(struct amdgpu_device
*adev)
k++;
}
power_state_offset += 2 + power_state->v2.ucNumDPMLevels;
+ adev->pm.dpm.num_ps++;
}
- adev->pm.dpm.num_ps = state_array->ucNumEntries;
/* fill in the vce power states */
for (i = 0; i < adev->pm.dpm.num_of_vce_states; i++) {
--
2.35.1
Re: [PATCH v6 14/22] dma-buf: Introduce new locking convention
On 5/30/22 16:41, Christian König wrote: > Hi Dmitry, > > Am 30.05.22 um 15:26 schrieb Dmitry Osipenko: >> Hello Christian, >> >> On 5/30/22 09:50, Christian König wrote: >>> Hi Dmitry, >>> >>> First of all please separate out this patch from the rest of the series, >>> since this is a complex separate structural change. >> I assume all the patches will go via the DRM tree in the end since the >> rest of the DRM patches in this series depend on this dma-buf change. >> But I see that separation may ease reviewing of the dma-buf changes, so >> let's try it. > > That sounds like you are underestimating a bit how much trouble this > will be. > >>> I have tried this before and failed because catching all the locks in >>> the right code paths are very tricky. So expect some fallout from this >>> and make sure the kernel test robot and CI systems are clean. >> Sure, I'll fix up all the reported things in the next iteration. >> >> BTW, have you ever posted yours version of the patch? Will be great if >> we could compare the changed code paths. > > No, I never even finished creating it after realizing how much work it > would be. > This patch introduces new locking convention for dma-buf users. From now on all dma-buf importers are responsible for holding dma-buf reservation lock around operations performed over dma-bufs. This patch implements the new dma-buf locking convention by: 1. Making dma-buf API functions to take the reservation lock. 2. Adding new locked variants of the dma-buf API functions for drivers that need to manage imported dma-bufs under the held lock. >>> Instead of adding new locked variants please mark all variants which >>> expect to be called without a lock with an _unlocked postfix. >>> >>> This should make it easier to remove those in a follow up patch set and >>> then fully move the locking into the importer. >> Do we really want to move all the locks to the importers? Seems the >> majority of drivers should be happy with the dma-buf helpers handling >> the locking for them. > > Yes, I clearly think so. > >> 3. Converting all drivers to the new locking scheme. >>> I have strong doubts that you got all of them. At least radeon and >>> nouveau should grab the reservation lock in their ->attach callbacks >>> somehow. >> Radeon and Nouveau use gem_prime_import_sg_table() and they take resv >> lock already, seems they should be okay (?) > > You are looking at the wrong side. You need to fix the export code path, > not the import ones. > > See for example attach on radeon works like this > drm_gem_map_attach->drm_gem_pin->radeon_gem_prime_pin->radeon_bo_reserve->ttm_bo_reserve->dma_resv_lock. Yeah, I was looking at the both sides, but missed this one. > Same for nouveau and probably a few other exporters as well. That will > certainly cause a deadlock if you don't fix it. > > I strongly suggest to do this step by step, first attach/detach and then > the rest. Thank you very much for the suggestions. I'll implement them in the next version. -- Best regards, Dmitry
[PATCH AUTOSEL 4.19 19/38] drm/amd/pm: fix the compile warning
From: Evan Quan
[ Upstream commit 555238d92ac32dbad2d77ad2bafc48d17391990c ]
Fix the compile warning below:
drivers/gpu/drm/amd/amdgpu/../pm/legacy-dpm/kv_dpm.c:1641
kv_get_acp_boot_level() warn: always true condition '(table->entries[i]->clk >=
0) => (0-u32max >= 0)'
Reported-by: kernel test robot
CC: Alex Deucher
Signed-off-by: Evan Quan
Reviewed-by: Alex Deucher
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/kv_dpm.c | 14 +-
1 file changed, 1 insertion(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/kv_dpm.c
b/drivers/gpu/drm/amd/amdgpu/kv_dpm.c
index cb79a93c2eb7..91504eccc60c 100644
--- a/drivers/gpu/drm/amd/amdgpu/kv_dpm.c
+++ b/drivers/gpu/drm/amd/amdgpu/kv_dpm.c
@@ -1610,19 +1610,7 @@ static int kv_update_samu_dpm(struct amdgpu_device
*adev, bool gate)
static u8 kv_get_acp_boot_level(struct amdgpu_device *adev)
{
- u8 i;
- struct amdgpu_clock_voltage_dependency_table *table =
- >pm.dpm.dyn_state.acp_clock_voltage_dependency_table;
-
- for (i = 0; i < table->count; i++) {
- if (table->entries[i].clk >= 0) /* XXX */
- break;
- }
-
- if (i >= table->count)
- i = table->count - 1;
-
- return i;
+ return 0;
}
static void kv_update_acp_boot_level(struct amdgpu_device *adev)
--
2.35.1
Re: [PATCH v6 14/22] dma-buf: Introduce new locking convention
Hi Dmitry, Am 30.05.22 um 15:26 schrieb Dmitry Osipenko: Hello Christian, On 5/30/22 09:50, Christian König wrote: Hi Dmitry, First of all please separate out this patch from the rest of the series, since this is a complex separate structural change. I assume all the patches will go via the DRM tree in the end since the rest of the DRM patches in this series depend on this dma-buf change. But I see that separation may ease reviewing of the dma-buf changes, so let's try it. That sounds like you are underestimating a bit how much trouble this will be. I have tried this before and failed because catching all the locks in the right code paths are very tricky. So expect some fallout from this and make sure the kernel test robot and CI systems are clean. Sure, I'll fix up all the reported things in the next iteration. BTW, have you ever posted yours version of the patch? Will be great if we could compare the changed code paths. No, I never even finished creating it after realizing how much work it would be. This patch introduces new locking convention for dma-buf users. From now on all dma-buf importers are responsible for holding dma-buf reservation lock around operations performed over dma-bufs. This patch implements the new dma-buf locking convention by: 1. Making dma-buf API functions to take the reservation lock. 2. Adding new locked variants of the dma-buf API functions for drivers that need to manage imported dma-bufs under the held lock. Instead of adding new locked variants please mark all variants which expect to be called without a lock with an _unlocked postfix. This should make it easier to remove those in a follow up patch set and then fully move the locking into the importer. Do we really want to move all the locks to the importers? Seems the majority of drivers should be happy with the dma-buf helpers handling the locking for them. Yes, I clearly think so. 3. Converting all drivers to the new locking scheme. I have strong doubts that you got all of them. At least radeon and nouveau should grab the reservation lock in their ->attach callbacks somehow. Radeon and Nouveau use gem_prime_import_sg_table() and they take resv lock already, seems they should be okay (?) You are looking at the wrong side. You need to fix the export code path, not the import ones. See for example attach on radeon works like this drm_gem_map_attach->drm_gem_pin->radeon_gem_prime_pin->radeon_bo_reserve->ttm_bo_reserve->dma_resv_lock. Same for nouveau and probably a few other exporters as well. That will certainly cause a deadlock if you don't fix it. I strongly suggest to do this step by step, first attach/detach and then the rest. Regards, Christian. I assume all the basics should covered in this v6. At minimum Intel, Tegra, Panfrost, Lima and Rockchip drivers should be good. If I missed something, then please let me know and I'll correct it. Signed-off-by: Dmitry Osipenko --- drivers/dma-buf/dma-buf.c | 270 +++--- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 6 +- drivers/gpu/drm/drm_client.c | 4 +- drivers/gpu/drm/drm_gem.c | 33 +++ drivers/gpu/drm/drm_gem_framebuffer_helper.c | 6 +- drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 10 +- drivers/gpu/drm/qxl/qxl_object.c | 17 +- drivers/gpu/drm/qxl/qxl_prime.c | 4 +- .../common/videobuf2/videobuf2-dma-contig.c | 11 +- .../media/common/videobuf2/videobuf2-dma-sg.c | 11 +- .../common/videobuf2/videobuf2-vmalloc.c | 11 +- include/drm/drm_gem.h | 3 + include/linux/dma-buf.h | 14 +- 13 files changed, 241 insertions(+), 159 deletions(-) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index 32f55640890c..64a9909ccfa2 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -552,7 +552,6 @@ struct dma_buf *dma_buf_export(const struct dma_buf_export_info *exp_info) file->f_mode |= FMODE_LSEEK; dmabuf->file = file; - mutex_init(>lock); Please make removing dmabuf->lock a separate change. Alright
[PATCH AUTOSEL 4.19 07/38] fbcon: Consistently protect deferred_takeover with console_lock()
From: Daniel Vetter
[ Upstream commit 43553559121ca90965b572cf8a1d6d0fd618b449 ]
This shouldn't be a problem in practice since until we've actually
taken over the console there's nothing we've registered with the
console/vt subsystem, so the exit/unbind path that check this can't
do the wrong thing. But it's confusing, so fix it by moving it a tad
later.
Acked-by: Sam Ravnborg
Signed-off-by: Daniel Vetter
Cc: Daniel Vetter
Cc: Du Cheng
Cc: Tetsuo Handa
Cc: Claudio Suarez
Cc: Thomas Zimmermann
Link:
https://patchwork.freedesktop.org/patch/msgid/20220405210335.3434130-14-daniel.vet...@ffwll.ch
Signed-off-by: Sasha Levin
---
drivers/video/fbdev/core/fbcon.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index bf7959fdf9f4..7c2582892eab 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -3314,6 +3314,9 @@ static void fbcon_register_existing_fbs(struct
work_struct *work)
console_lock();
+ deferred_takeover = false;
+ logo_shown = FBCON_LOGO_DONTSHOW;
+
for_each_registered_fb(i)
fbcon_fb_registered(registered_fb[i]);
@@ -3331,8 +3334,6 @@ static int fbcon_output_notifier(struct notifier_block
*nb,
pr_info("fbcon: Taking over console\n");
dummycon_unregister_output_notifier(_output_nb);
- deferred_takeover = false;
- logo_shown = FBCON_LOGO_DONTSHOW;
/* We may get called in atomic context */
schedule_work(_deferred_takeover_work);
--
2.35.1
[PATCH AUTOSEL 4.19 01/38] drm/virtio: fix NULL pointer dereference in virtio_gpu_conn_get_modes
From: Liu Zixian
[ Upstream commit 194d250cdc4a40ccbd179afd522a9e9846957402 ]
drm_cvt_mode may return NULL and we should check it.
This bug is found by syzkaller:
FAULT_INJECTION stacktrace:
[ 168.567394] FAULT_INJECTION: forcing a failure.
name failslab, interval 1, probability 0, space 0, times 1
[ 168.567403] CPU: 1 PID: 6425 Comm: syz Kdump: loaded Not tainted
4.19.90-vhulk2201.1.0.h1035.kasan.eulerosv2r10.aarch64 #1
[ 168.567406] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
[ 168.567408] Call trace:
[ 168.567414] dump_backtrace+0x0/0x310
[ 168.567418] show_stack+0x28/0x38
[ 168.567423] dump_stack+0xec/0x15c
[ 168.567427] should_fail+0x3ac/0x3d0
[ 168.567437] __should_failslab+0xb8/0x120
[ 168.567441] should_failslab+0x28/0xc0
[ 168.567445] kmem_cache_alloc_trace+0x50/0x640
[ 168.567454] drm_mode_create+0x40/0x90
[ 168.567458] drm_cvt_mode+0x48/0xc78
[ 168.567477] virtio_gpu_conn_get_modes+0xa8/0x140 [virtio_gpu]
[ 168.567485] drm_helper_probe_single_connector_modes+0x3a4/0xd80
[ 168.567492] drm_mode_getconnector+0x2e0/0xa70
[ 168.567496] drm_ioctl_kernel+0x11c/0x1d8
[ 168.567514] drm_ioctl+0x558/0x6d0
[ 168.567522] do_vfs_ioctl+0x160/0xf30
[ 168.567525] ksys_ioctl+0x98/0xd8
[ 168.567530] __arm64_sys_ioctl+0x50/0xc8
[ 168.567536] el0_svc_common+0xc8/0x320
[ 168.567540] el0_svc_handler+0xf8/0x160
[ 168.567544] el0_svc+0x10/0x218
KASAN stacktrace:
[ 168.567561] BUG: KASAN: null-ptr-deref in
virtio_gpu_conn_get_modes+0xb4/0x140 [virtio_gpu]
[ 168.567565] Read of size 4 at addr 0054 by task syz/6425
[ 168.567566]
[ 168.567571] CPU: 1 PID: 6425 Comm: syz Kdump: loaded Not tainted
4.19.90-vhulk2201.1.0.h1035.kasan.eulerosv2r10.aarch64 #1
[ 168.567573] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
[ 168.567575] Call trace:
[ 168.567578] dump_backtrace+0x0/0x310
[ 168.567582] show_stack+0x28/0x38
[ 168.567586] dump_stack+0xec/0x15c
[ 168.567591] kasan_report+0x244/0x2f0
[ 168.567594] __asan_load4+0x58/0xb0
[ 168.567607] virtio_gpu_conn_get_modes+0xb4/0x140 [virtio_gpu]
[ 168.567612] drm_helper_probe_single_connector_modes+0x3a4/0xd80
[ 168.567617] drm_mode_getconnector+0x2e0/0xa70
[ 168.567621] drm_ioctl_kernel+0x11c/0x1d8
[ 168.567624] drm_ioctl+0x558/0x6d0
[ 168.567628] do_vfs_ioctl+0x160/0xf30
[ 168.567632] ksys_ioctl+0x98/0xd8
[ 168.567636] __arm64_sys_ioctl+0x50/0xc8
[ 168.567641] el0_svc_common+0xc8/0x320
[ 168.567645] el0_svc_handler+0xf8/0x160
[ 168.567649] el0_svc+0x10/0x218
Signed-off-by: Liu Zixian
Link:
http://patchwork.freedesktop.org/patch/msgid/20220322091730.1653-1-liuzixi...@huawei.com
Signed-off-by: Gerd Hoffmann
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/virtio/virtgpu_display.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c
b/drivers/gpu/drm/virtio/virtgpu_display.c
index 25503b933599..7511f416eb67 100644
--- a/drivers/gpu/drm/virtio/virtgpu_display.c
+++ b/drivers/gpu/drm/virtio/virtgpu_display.c
@@ -180,6 +180,8 @@ static int virtio_gpu_conn_get_modes(struct drm_connector
*connector)
DRM_DEBUG("add mode: %dx%d\n", width, height);
mode = drm_cvt_mode(connector->dev, width, height, 60,
false, false, false);
+ if (!mode)
+ return count;
mode->type |= DRM_MODE_TYPE_PREFERRED;
drm_mode_probed_add(connector, mode);
count++;
--
2.35.1
Re: [PATCH] drm/prime: Ensure mmap offset is initialized
On Mon, May 30, 2022 at 12:26 AM Thomas Zimmermann wrote:
>
> Hi
>
> Am 29.05.22 um 18:29 schrieb Rob Clark:
> > From: Rob Clark
> >
> > If a GEM object is allocated, and then exported as a dma-buf fd which is
> > mmap'd before or without the GEM buffer being directly mmap'd, the
> > vma_node could be unitialized. This leads to a situation where the CPU
> > mapping is not correctly torn down in drm_vma_node_unmap().
>
> Which drivers are affected by this problem?
>
> I checked several drivers and most appear to be initializing the offset
> during object construction, such as GEM SHMEM. [1] TTM-based drivers
> also seem unaffected. [2]
>
> From a quick grep, only etnaviv, msm and omapdrm appear to be affected?
> They only seem to run drm_gem_create_mmap_offset() from their
> ioctl-handling code.
>
> If so, I'd say it's preferable to fix these drivers and put a
> drm_WARN_ONCE() into drm_gem_prime_mmap().
That is good if fewer drivers are affected, however I disagree with
your proposal. At least for freedreno userspace, a lot of bo's never
get mmap'd (either directly of via dmabuf), so we should not be
allocating a mmap offset unnecessarily.
BR,
-R
> Best regards
> Thomas
>
> [1]
> https://elixir.bootlin.com/linux/v5.18/source/drivers/gpu/drm/drm_gem_shmem_helper.c#L85
> [2]
> https://elixir.bootlin.com/linux/v5.18/source/drivers/gpu/drm/ttm/ttm_bo.c#L1002
>
> >
> > Fixes: e5516553999f ("drm: call drm_gem_object_funcs.mmap with fake offset")
> > Signed-off-by: Rob Clark
> > ---
> > Note, it's possible the issue existed in some related form prior to the
> > commit tagged with Fixes.
> >
> > drivers/gpu/drm/drm_prime.c | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> > index e3f09f18110c..849eea154dfc 100644
> > --- a/drivers/gpu/drm/drm_prime.c
> > +++ b/drivers/gpu/drm/drm_prime.c
> > @@ -716,6 +716,11 @@ int drm_gem_prime_mmap(struct drm_gem_object *obj,
> > struct vm_area_struct *vma)
> > struct file *fil;
> > int ret;
> >
> > + /* Ensure that the vma_node is initialized: */
> > + ret = drm_gem_create_mmap_offset(obj);
> > + if (ret)
> > + return ret;
> > +
> > /* Add the fake offset */
> > vma->vm_pgoff += drm_vma_node_start(>vma_node);
> >
>
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> (HRB 36809, AG Nürnberg)
> Geschäftsführer: Ivo Totev
[PATCH AUTOSEL 4.9 12/24] drm/amd/pm: fix the compile warning
From: Evan Quan
[ Upstream commit 555238d92ac32dbad2d77ad2bafc48d17391990c ]
Fix the compile warning below:
drivers/gpu/drm/amd/amdgpu/../pm/legacy-dpm/kv_dpm.c:1641
kv_get_acp_boot_level() warn: always true condition '(table->entries[i]->clk >=
0) => (0-u32max >= 0)'
Reported-by: kernel test robot
CC: Alex Deucher
Signed-off-by: Evan Quan
Reviewed-by: Alex Deucher
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/kv_dpm.c | 14 +-
1 file changed, 1 insertion(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/kv_dpm.c
b/drivers/gpu/drm/amd/amdgpu/kv_dpm.c
index f61c489e5f6d..81f1591a9be9 100644
--- a/drivers/gpu/drm/amd/amdgpu/kv_dpm.c
+++ b/drivers/gpu/drm/amd/amdgpu/kv_dpm.c
@@ -1617,19 +1617,7 @@ static int kv_update_samu_dpm(struct amdgpu_device
*adev, bool gate)
static u8 kv_get_acp_boot_level(struct amdgpu_device *adev)
{
- u8 i;
- struct amdgpu_clock_voltage_dependency_table *table =
- >pm.dpm.dyn_state.acp_clock_voltage_dependency_table;
-
- for (i = 0; i < table->count; i++) {
- if (table->entries[i].clk >= 0) /* XXX */
- break;
- }
-
- if (i >= table->count)
- i = table->count - 1;
-
- return i;
+ return 0;
}
static void kv_update_acp_boot_level(struct amdgpu_device *adev)
--
2.35.1
[PATCH AUTOSEL 4.9 08/24] drm/amd/pm: fix double free in si_parse_power_table()
From: Keita Suzuki
[ Upstream commit f3fa2becf2fc25b6ac7cf8d8b1a2e4a86b3b72bd ]
In function si_parse_power_table(), array adev->pm.dpm.ps and its member
is allocated. If the allocation of each member fails, the array itself
is freed and returned with an error code. However, the array is later
freed again in si_dpm_fini() function which is called when the function
returns an error.
This leads to potential double free of the array adev->pm.dpm.ps, as
well as leak of its array members, since the members are not freed in
the allocation function and the array is not nulled when freed.
In addition adev->pm.dpm.num_ps, which keeps track of the allocated
array member, is not updated until the member allocation is
successfully finished, this could also lead to either use after free,
or uninitialized variable access in si_dpm_fini().
Fix this by postponing the free of the array until si_dpm_fini() and
increment adev->pm.dpm.num_ps everytime the array member is allocated.
Signed-off-by: Keita Suzuki
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/si_dpm.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/si_dpm.c
b/drivers/gpu/drm/amd/amdgpu/si_dpm.c
index 4826befc1bc3..fe6fda42fde8 100644
--- a/drivers/gpu/drm/amd/amdgpu/si_dpm.c
+++ b/drivers/gpu/drm/amd/amdgpu/si_dpm.c
@@ -7313,17 +7313,15 @@ static int si_parse_power_table(struct amdgpu_device
*adev)
if (!adev->pm.dpm.ps)
return -ENOMEM;
power_state_offset = (u8 *)state_array->states;
- for (i = 0; i < state_array->ucNumEntries; i++) {
+ for (adev->pm.dpm.num_ps = 0, i = 0; i < state_array->ucNumEntries;
i++) {
u8 *idx;
power_state = (union pplib_power_state *)power_state_offset;
non_clock_array_index = power_state->v2.nonClockInfoIndex;
non_clock_info = (struct _ATOM_PPLIB_NONCLOCK_INFO *)
_clock_info_array->nonClockInfo[non_clock_array_index];
ps = kzalloc(sizeof(struct si_ps), GFP_KERNEL);
- if (ps == NULL) {
- kfree(adev->pm.dpm.ps);
+ if (ps == NULL)
return -ENOMEM;
- }
adev->pm.dpm.ps[i].ps_priv = ps;
si_parse_pplib_non_clock_info(adev, >pm.dpm.ps[i],
non_clock_info,
@@ -7345,8 +7343,8 @@ static int si_parse_power_table(struct amdgpu_device
*adev)
k++;
}
power_state_offset += 2 + power_state->v2.ucNumDPMLevels;
+ adev->pm.dpm.num_ps++;
}
- adev->pm.dpm.num_ps = state_array->ucNumEntries;
/* fill in the vce power states */
for (i = 0; i < AMDGPU_MAX_VCE_LEVELS; i++) {
--
2.35.1
[PATCH AUTOSEL 4.9 01/24] drm/virtio: fix NULL pointer dereference in virtio_gpu_conn_get_modes
From: Liu Zixian
[ Upstream commit 194d250cdc4a40ccbd179afd522a9e9846957402 ]
drm_cvt_mode may return NULL and we should check it.
This bug is found by syzkaller:
FAULT_INJECTION stacktrace:
[ 168.567394] FAULT_INJECTION: forcing a failure.
name failslab, interval 1, probability 0, space 0, times 1
[ 168.567403] CPU: 1 PID: 6425 Comm: syz Kdump: loaded Not tainted
4.19.90-vhulk2201.1.0.h1035.kasan.eulerosv2r10.aarch64 #1
[ 168.567406] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
[ 168.567408] Call trace:
[ 168.567414] dump_backtrace+0x0/0x310
[ 168.567418] show_stack+0x28/0x38
[ 168.567423] dump_stack+0xec/0x15c
[ 168.567427] should_fail+0x3ac/0x3d0
[ 168.567437] __should_failslab+0xb8/0x120
[ 168.567441] should_failslab+0x28/0xc0
[ 168.567445] kmem_cache_alloc_trace+0x50/0x640
[ 168.567454] drm_mode_create+0x40/0x90
[ 168.567458] drm_cvt_mode+0x48/0xc78
[ 168.567477] virtio_gpu_conn_get_modes+0xa8/0x140 [virtio_gpu]
[ 168.567485] drm_helper_probe_single_connector_modes+0x3a4/0xd80
[ 168.567492] drm_mode_getconnector+0x2e0/0xa70
[ 168.567496] drm_ioctl_kernel+0x11c/0x1d8
[ 168.567514] drm_ioctl+0x558/0x6d0
[ 168.567522] do_vfs_ioctl+0x160/0xf30
[ 168.567525] ksys_ioctl+0x98/0xd8
[ 168.567530] __arm64_sys_ioctl+0x50/0xc8
[ 168.567536] el0_svc_common+0xc8/0x320
[ 168.567540] el0_svc_handler+0xf8/0x160
[ 168.567544] el0_svc+0x10/0x218
KASAN stacktrace:
[ 168.567561] BUG: KASAN: null-ptr-deref in
virtio_gpu_conn_get_modes+0xb4/0x140 [virtio_gpu]
[ 168.567565] Read of size 4 at addr 0054 by task syz/6425
[ 168.567566]
[ 168.567571] CPU: 1 PID: 6425 Comm: syz Kdump: loaded Not tainted
4.19.90-vhulk2201.1.0.h1035.kasan.eulerosv2r10.aarch64 #1
[ 168.567573] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
[ 168.567575] Call trace:
[ 168.567578] dump_backtrace+0x0/0x310
[ 168.567582] show_stack+0x28/0x38
[ 168.567586] dump_stack+0xec/0x15c
[ 168.567591] kasan_report+0x244/0x2f0
[ 168.567594] __asan_load4+0x58/0xb0
[ 168.567607] virtio_gpu_conn_get_modes+0xb4/0x140 [virtio_gpu]
[ 168.567612] drm_helper_probe_single_connector_modes+0x3a4/0xd80
[ 168.567617] drm_mode_getconnector+0x2e0/0xa70
[ 168.567621] drm_ioctl_kernel+0x11c/0x1d8
[ 168.567624] drm_ioctl+0x558/0x6d0
[ 168.567628] do_vfs_ioctl+0x160/0xf30
[ 168.567632] ksys_ioctl+0x98/0xd8
[ 168.567636] __arm64_sys_ioctl+0x50/0xc8
[ 168.567641] el0_svc_common+0xc8/0x320
[ 168.567645] el0_svc_handler+0xf8/0x160
[ 168.567649] el0_svc+0x10/0x218
Signed-off-by: Liu Zixian
Link:
http://patchwork.freedesktop.org/patch/msgid/20220322091730.1653-1-liuzixi...@huawei.com
Signed-off-by: Gerd Hoffmann
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/virtio/virtgpu_display.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c
b/drivers/gpu/drm/virtio/virtgpu_display.c
index 58048709c34e..1e528f13959d 100644
--- a/drivers/gpu/drm/virtio/virtgpu_display.c
+++ b/drivers/gpu/drm/virtio/virtgpu_display.c
@@ -184,6 +184,8 @@ static int virtio_gpu_conn_get_modes(struct drm_connector
*connector)
DRM_DEBUG("add mode: %dx%d\n", width, height);
mode = drm_cvt_mode(connector->dev, width, height, 60,
false, false, false);
+ if (!mode)
+ return count;
mode->type |= DRM_MODE_TYPE_PREFERRED;
drm_mode_probed_add(connector, mode);
count++;
--
2.35.1
[PATCH AUTOSEL 4.14 14/29] drm/amd/pm: fix the compile warning
From: Evan Quan
[ Upstream commit 555238d92ac32dbad2d77ad2bafc48d17391990c ]
Fix the compile warning below:
drivers/gpu/drm/amd/amdgpu/../pm/legacy-dpm/kv_dpm.c:1641
kv_get_acp_boot_level() warn: always true condition '(table->entries[i]->clk >=
0) => (0-u32max >= 0)'
Reported-by: kernel test robot
CC: Alex Deucher
Signed-off-by: Evan Quan
Reviewed-by: Alex Deucher
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/kv_dpm.c | 14 +-
1 file changed, 1 insertion(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/kv_dpm.c
b/drivers/gpu/drm/amd/amdgpu/kv_dpm.c
index c76073b422d6..d99fb88341f4 100644
--- a/drivers/gpu/drm/amd/amdgpu/kv_dpm.c
+++ b/drivers/gpu/drm/amd/amdgpu/kv_dpm.c
@@ -1608,19 +1608,7 @@ static int kv_update_samu_dpm(struct amdgpu_device
*adev, bool gate)
static u8 kv_get_acp_boot_level(struct amdgpu_device *adev)
{
- u8 i;
- struct amdgpu_clock_voltage_dependency_table *table =
- >pm.dpm.dyn_state.acp_clock_voltage_dependency_table;
-
- for (i = 0; i < table->count; i++) {
- if (table->entries[i].clk >= 0) /* XXX */
- break;
- }
-
- if (i >= table->count)
- i = table->count - 1;
-
- return i;
+ return 0;
}
static void kv_update_acp_boot_level(struct amdgpu_device *adev)
--
2.35.1
Re: [PATCH] drm/sun4i: Fix blend route/enable register corruption for DE2.0/DE3.0
Hi Maxime, пн, 30 мая 2022 г. в 16:22, Maxime Ripard : > > Hi Roman, > > On Wed, May 25, 2022 at 11:54:45AM +, Roman Stratiienko wrote: > > By this commit 2 related issues are solved: > > > > Issue #1. Corruption in blend route/enable register: > > > > Register corruption happens after using old_state->zpos to disable layer > > state. Blend route/enable registers are shared with other layers > > and other layers may have already assigned this PIPE to valid value. > > > > Solution: Do not use old_state->zpos to disable the plane pipe in > > blend registers. > > > > Issue #2. Remove disabled layer from blend route/enable registers: > > > > Since sun4i/drm are using normalized_zpos, .atomic_update() will setup > > blend route/enable pipes starting from PIPE0 to PIPEX, where X+1 is a > > number of layers used by the CRTC in this frame. > > > > Remaining pipes (PIPE[X+1] - PIPE[MAX]) can have old data that MUST be > > updated. > > > > new_state->normalized_zpos can't be used, since drm helpers won't update > > it for disabled planes. > > > > Solution: > > > > 1. Track the number of total used planes for crtc. > > 2. Use this number instead of zpos to disable unused blend pipes. > > > > Signed-off-by: Roman Stratiienko > > If there's two issues, and two solutions, it should be two patches. I would say.. It's a single complex issue. Solving one part without solving another will make things only worse. > > Maxime
[PATCH AUTOSEL 4.14 08/29] drm/amd/pm: fix double free in si_parse_power_table()
From: Keita Suzuki
[ Upstream commit f3fa2becf2fc25b6ac7cf8d8b1a2e4a86b3b72bd ]
In function si_parse_power_table(), array adev->pm.dpm.ps and its member
is allocated. If the allocation of each member fails, the array itself
is freed and returned with an error code. However, the array is later
freed again in si_dpm_fini() function which is called when the function
returns an error.
This leads to potential double free of the array adev->pm.dpm.ps, as
well as leak of its array members, since the members are not freed in
the allocation function and the array is not nulled when freed.
In addition adev->pm.dpm.num_ps, which keeps track of the allocated
array member, is not updated until the member allocation is
successfully finished, this could also lead to either use after free,
or uninitialized variable access in si_dpm_fini().
Fix this by postponing the free of the array until si_dpm_fini() and
increment adev->pm.dpm.num_ps everytime the array member is allocated.
Signed-off-by: Keita Suzuki
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/si_dpm.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/si_dpm.c
b/drivers/gpu/drm/amd/amdgpu/si_dpm.c
index 55613f425931..288ac692f536 100644
--- a/drivers/gpu/drm/amd/amdgpu/si_dpm.c
+++ b/drivers/gpu/drm/amd/amdgpu/si_dpm.c
@@ -7238,17 +7238,15 @@ static int si_parse_power_table(struct amdgpu_device
*adev)
if (!adev->pm.dpm.ps)
return -ENOMEM;
power_state_offset = (u8 *)state_array->states;
- for (i = 0; i < state_array->ucNumEntries; i++) {
+ for (adev->pm.dpm.num_ps = 0, i = 0; i < state_array->ucNumEntries;
i++) {
u8 *idx;
power_state = (union pplib_power_state *)power_state_offset;
non_clock_array_index = power_state->v2.nonClockInfoIndex;
non_clock_info = (struct _ATOM_PPLIB_NONCLOCK_INFO *)
_clock_info_array->nonClockInfo[non_clock_array_index];
ps = kzalloc(sizeof(struct si_ps), GFP_KERNEL);
- if (ps == NULL) {
- kfree(adev->pm.dpm.ps);
+ if (ps == NULL)
return -ENOMEM;
- }
adev->pm.dpm.ps[i].ps_priv = ps;
si_parse_pplib_non_clock_info(adev, >pm.dpm.ps[i],
non_clock_info,
@@ -7270,8 +7268,8 @@ static int si_parse_power_table(struct amdgpu_device
*adev)
k++;
}
power_state_offset += 2 + power_state->v2.ucNumDPMLevels;
+ adev->pm.dpm.num_ps++;
}
- adev->pm.dpm.num_ps = state_array->ucNumEntries;
/* fill in the vce power states */
for (i = 0; i < adev->pm.dpm.num_of_vce_states; i++) {
--
2.35.1
[PATCH AUTOSEL 4.14 01/29] drm/virtio: fix NULL pointer dereference in virtio_gpu_conn_get_modes
From: Liu Zixian
[ Upstream commit 194d250cdc4a40ccbd179afd522a9e9846957402 ]
drm_cvt_mode may return NULL and we should check it.
This bug is found by syzkaller:
FAULT_INJECTION stacktrace:
[ 168.567394] FAULT_INJECTION: forcing a failure.
name failslab, interval 1, probability 0, space 0, times 1
[ 168.567403] CPU: 1 PID: 6425 Comm: syz Kdump: loaded Not tainted
4.19.90-vhulk2201.1.0.h1035.kasan.eulerosv2r10.aarch64 #1
[ 168.567406] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
[ 168.567408] Call trace:
[ 168.567414] dump_backtrace+0x0/0x310
[ 168.567418] show_stack+0x28/0x38
[ 168.567423] dump_stack+0xec/0x15c
[ 168.567427] should_fail+0x3ac/0x3d0
[ 168.567437] __should_failslab+0xb8/0x120
[ 168.567441] should_failslab+0x28/0xc0
[ 168.567445] kmem_cache_alloc_trace+0x50/0x640
[ 168.567454] drm_mode_create+0x40/0x90
[ 168.567458] drm_cvt_mode+0x48/0xc78
[ 168.567477] virtio_gpu_conn_get_modes+0xa8/0x140 [virtio_gpu]
[ 168.567485] drm_helper_probe_single_connector_modes+0x3a4/0xd80
[ 168.567492] drm_mode_getconnector+0x2e0/0xa70
[ 168.567496] drm_ioctl_kernel+0x11c/0x1d8
[ 168.567514] drm_ioctl+0x558/0x6d0
[ 168.567522] do_vfs_ioctl+0x160/0xf30
[ 168.567525] ksys_ioctl+0x98/0xd8
[ 168.567530] __arm64_sys_ioctl+0x50/0xc8
[ 168.567536] el0_svc_common+0xc8/0x320
[ 168.567540] el0_svc_handler+0xf8/0x160
[ 168.567544] el0_svc+0x10/0x218
KASAN stacktrace:
[ 168.567561] BUG: KASAN: null-ptr-deref in
virtio_gpu_conn_get_modes+0xb4/0x140 [virtio_gpu]
[ 168.567565] Read of size 4 at addr 0054 by task syz/6425
[ 168.567566]
[ 168.567571] CPU: 1 PID: 6425 Comm: syz Kdump: loaded Not tainted
4.19.90-vhulk2201.1.0.h1035.kasan.eulerosv2r10.aarch64 #1
[ 168.567573] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
[ 168.567575] Call trace:
[ 168.567578] dump_backtrace+0x0/0x310
[ 168.567582] show_stack+0x28/0x38
[ 168.567586] dump_stack+0xec/0x15c
[ 168.567591] kasan_report+0x244/0x2f0
[ 168.567594] __asan_load4+0x58/0xb0
[ 168.567607] virtio_gpu_conn_get_modes+0xb4/0x140 [virtio_gpu]
[ 168.567612] drm_helper_probe_single_connector_modes+0x3a4/0xd80
[ 168.567617] drm_mode_getconnector+0x2e0/0xa70
[ 168.567621] drm_ioctl_kernel+0x11c/0x1d8
[ 168.567624] drm_ioctl+0x558/0x6d0
[ 168.567628] do_vfs_ioctl+0x160/0xf30
[ 168.567632] ksys_ioctl+0x98/0xd8
[ 168.567636] __arm64_sys_ioctl+0x50/0xc8
[ 168.567641] el0_svc_common+0xc8/0x320
[ 168.567645] el0_svc_handler+0xf8/0x160
[ 168.567649] el0_svc+0x10/0x218
Signed-off-by: Liu Zixian
Link:
http://patchwork.freedesktop.org/patch/msgid/20220322091730.1653-1-liuzixi...@huawei.com
Signed-off-by: Gerd Hoffmann
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/virtio/virtgpu_display.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c
b/drivers/gpu/drm/virtio/virtgpu_display.c
index b6d52055a11f..3a5f73bc2a37 100644
--- a/drivers/gpu/drm/virtio/virtgpu_display.c
+++ b/drivers/gpu/drm/virtio/virtgpu_display.c
@@ -187,6 +187,8 @@ static int virtio_gpu_conn_get_modes(struct drm_connector
*connector)
DRM_DEBUG("add mode: %dx%d\n", width, height);
mode = drm_cvt_mode(connector->dev, width, height, 60,
false, false, false);
+ if (!mode)
+ return count;
mode->type |= DRM_MODE_TYPE_PREFERRED;
drm_mode_probed_add(connector, mode);
count++;
--
2.35.1
[PATCH AUTOSEL 5.18 129/159] drm/amd/pm: update smartshift powerboost calc for smu12
From: Sathishkumar S
[ Upstream commit 138292f1dc00e7e0724f44769f9da39cf2f3bf0b ]
smartshift apu and dgpu power boost are reported as percentage with
respect to their power limits. This value[0-100] reflects the boost
for the respective device.
Signed-off-by: Sathishkumar S
Reviewed-by: Lijo Lazar
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
.../gpu/drm/amd/pm/swsmu/smu12/renoir_ppt.c | 60 ++-
1 file changed, 44 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu12/renoir_ppt.c
b/drivers/gpu/drm/amd/pm/swsmu/smu12/renoir_ppt.c
index fd6c44ece168..012e3bd99cc2 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu12/renoir_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu12/renoir_ppt.c
@@ -1119,6 +1119,39 @@ static int renoir_get_power_profile_mode(struct
smu_context *smu,
return size;
}
+static void renoir_get_ss_power_percent(SmuMetrics_t *metrics,
+ uint32_t *apu_percent, uint32_t
*dgpu_percent)
+{
+ uint32_t apu_boost = 0;
+ uint32_t dgpu_boost = 0;
+ uint16_t apu_limit = 0;
+ uint16_t dgpu_limit = 0;
+ uint16_t apu_power = 0;
+ uint16_t dgpu_power = 0;
+
+ apu_power = metrics->ApuPower;
+ apu_limit = metrics->StapmOriginalLimit;
+ if (apu_power > apu_limit && apu_limit != 0)
+ apu_boost = ((apu_power - apu_limit) * 100) / apu_limit;
+ apu_boost = (apu_boost > 100) ? 100 : apu_boost;
+
+ dgpu_power = metrics->dGpuPower;
+ if (metrics->StapmCurrentLimit > metrics->StapmOriginalLimit)
+ dgpu_limit = metrics->StapmCurrentLimit -
metrics->StapmOriginalLimit;
+ if (dgpu_power > dgpu_limit && dgpu_limit != 0)
+ dgpu_boost = ((dgpu_power - dgpu_limit) * 100) / dgpu_limit;
+ dgpu_boost = (dgpu_boost > 100) ? 100 : dgpu_boost;
+
+ if (dgpu_boost >= apu_boost)
+ apu_boost = 0;
+ else
+ dgpu_boost = 0;
+
+ *apu_percent = apu_boost;
+ *dgpu_percent = dgpu_boost;
+}
+
+
static int renoir_get_smu_metrics_data(struct smu_context *smu,
MetricsMember_t member,
uint32_t *value)
@@ -1127,6 +1160,9 @@ static int renoir_get_smu_metrics_data(struct smu_context
*smu,
SmuMetrics_t *metrics = (SmuMetrics_t *)smu_table->metrics_table;
int ret = 0;
+ uint32_t apu_percent = 0;
+ uint32_t dgpu_percent = 0;
+
ret = smu_cmn_get_metrics_table(smu,
NULL,
@@ -1171,26 +1207,18 @@ static int renoir_get_smu_metrics_data(struct
smu_context *smu,
*value = metrics->Voltage[1];
break;
case METRICS_SS_APU_SHARE:
- /* return the percentage of APU power with respect to APU's
power limit.
-* percentage is reported, this isn't boost value. Smartshift
power
-* boost/shift is only when the percentage is more than 100.
+ /* return the percentage of APU power boost
+* with respect to APU's power limit.
*/
- if (metrics->StapmOriginalLimit > 0)
- *value = (metrics->ApuPower * 100) /
metrics->StapmOriginalLimit;
- else
- *value = 0;
+ renoir_get_ss_power_percent(metrics, _percent,
_percent);
+ *value = apu_percent;
break;
case METRICS_SS_DGPU_SHARE:
- /* return the percentage of dGPU power with respect to dGPU's
power limit.
-* percentage is reported, this isn't boost value. Smartshift
power
-* boost/shift is only when the percentage is more than 100.
+ /* return the percentage of dGPU power boost
+* with respect to dGPU's power limit.
*/
- if ((metrics->dGpuPower > 0) &&
- (metrics->StapmCurrentLimit > metrics->StapmOriginalLimit))
- *value = (metrics->dGpuPower * 100) /
- (metrics->StapmCurrentLimit -
metrics->StapmOriginalLimit);
- else
- *value = 0;
+ renoir_get_ss_power_percent(metrics, _percent,
_percent);
+ *value = dgpu_percent;
break;
default:
*value = UINT_MAX;
--
2.35.1
[PATCH AUTOSEL 5.15 011/109] fbcon: Consistently protect deferred_takeover with console_lock()
From: Daniel Vetter
[ Upstream commit 43553559121ca90965b572cf8a1d6d0fd618b449 ]
This shouldn't be a problem in practice since until we've actually
taken over the console there's nothing we've registered with the
console/vt subsystem, so the exit/unbind path that check this can't
do the wrong thing. But it's confusing, so fix it by moving it a tad
later.
Acked-by: Sam Ravnborg
Signed-off-by: Daniel Vetter
Cc: Daniel Vetter
Cc: Du Cheng
Cc: Tetsuo Handa
Cc: Claudio Suarez
Cc: Thomas Zimmermann
Link:
https://patchwork.freedesktop.org/patch/msgid/20220405210335.3434130-14-daniel.vet...@ffwll.ch
Signed-off-by: Sasha Levin
---
drivers/video/fbdev/core/fbcon.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index a53c1f6906f0..a25b63b56223 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -3265,6 +3265,9 @@ static void fbcon_register_existing_fbs(struct
work_struct *work)
console_lock();
+ deferred_takeover = false;
+ logo_shown = FBCON_LOGO_DONTSHOW;
+
for_each_registered_fb(i)
fbcon_fb_registered(registered_fb[i]);
@@ -3282,8 +3285,6 @@ static int fbcon_output_notifier(struct notifier_block
*nb,
pr_info("fbcon: Taking over console\n");
dummycon_unregister_output_notifier(_output_nb);
- deferred_takeover = false;
- logo_shown = FBCON_LOGO_DONTSHOW;
/* We may get called in atomic context */
schedule_work(_deferred_takeover_work);
--
2.35.1
[PATCH AUTOSEL 5.15 003/109] drm/virtio: fix NULL pointer dereference in virtio_gpu_conn_get_modes
From: Liu Zixian
[ Upstream commit 194d250cdc4a40ccbd179afd522a9e9846957402 ]
drm_cvt_mode may return NULL and we should check it.
This bug is found by syzkaller:
FAULT_INJECTION stacktrace:
[ 168.567394] FAULT_INJECTION: forcing a failure.
name failslab, interval 1, probability 0, space 0, times 1
[ 168.567403] CPU: 1 PID: 6425 Comm: syz Kdump: loaded Not tainted
4.19.90-vhulk2201.1.0.h1035.kasan.eulerosv2r10.aarch64 #1
[ 168.567406] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
[ 168.567408] Call trace:
[ 168.567414] dump_backtrace+0x0/0x310
[ 168.567418] show_stack+0x28/0x38
[ 168.567423] dump_stack+0xec/0x15c
[ 168.567427] should_fail+0x3ac/0x3d0
[ 168.567437] __should_failslab+0xb8/0x120
[ 168.567441] should_failslab+0x28/0xc0
[ 168.567445] kmem_cache_alloc_trace+0x50/0x640
[ 168.567454] drm_mode_create+0x40/0x90
[ 168.567458] drm_cvt_mode+0x48/0xc78
[ 168.567477] virtio_gpu_conn_get_modes+0xa8/0x140 [virtio_gpu]
[ 168.567485] drm_helper_probe_single_connector_modes+0x3a4/0xd80
[ 168.567492] drm_mode_getconnector+0x2e0/0xa70
[ 168.567496] drm_ioctl_kernel+0x11c/0x1d8
[ 168.567514] drm_ioctl+0x558/0x6d0
[ 168.567522] do_vfs_ioctl+0x160/0xf30
[ 168.567525] ksys_ioctl+0x98/0xd8
[ 168.567530] __arm64_sys_ioctl+0x50/0xc8
[ 168.567536] el0_svc_common+0xc8/0x320
[ 168.567540] el0_svc_handler+0xf8/0x160
[ 168.567544] el0_svc+0x10/0x218
KASAN stacktrace:
[ 168.567561] BUG: KASAN: null-ptr-deref in
virtio_gpu_conn_get_modes+0xb4/0x140 [virtio_gpu]
[ 168.567565] Read of size 4 at addr 0054 by task syz/6425
[ 168.567566]
[ 168.567571] CPU: 1 PID: 6425 Comm: syz Kdump: loaded Not tainted
4.19.90-vhulk2201.1.0.h1035.kasan.eulerosv2r10.aarch64 #1
[ 168.567573] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
[ 168.567575] Call trace:
[ 168.567578] dump_backtrace+0x0/0x310
[ 168.567582] show_stack+0x28/0x38
[ 168.567586] dump_stack+0xec/0x15c
[ 168.567591] kasan_report+0x244/0x2f0
[ 168.567594] __asan_load4+0x58/0xb0
[ 168.567607] virtio_gpu_conn_get_modes+0xb4/0x140 [virtio_gpu]
[ 168.567612] drm_helper_probe_single_connector_modes+0x3a4/0xd80
[ 168.567617] drm_mode_getconnector+0x2e0/0xa70
[ 168.567621] drm_ioctl_kernel+0x11c/0x1d8
[ 168.567624] drm_ioctl+0x558/0x6d0
[ 168.567628] do_vfs_ioctl+0x160/0xf30
[ 168.567632] ksys_ioctl+0x98/0xd8
[ 168.567636] __arm64_sys_ioctl+0x50/0xc8
[ 168.567641] el0_svc_common+0xc8/0x320
[ 168.567645] el0_svc_handler+0xf8/0x160
[ 168.567649] el0_svc+0x10/0x218
Signed-off-by: Liu Zixian
Link:
http://patchwork.freedesktop.org/patch/msgid/20220322091730.1653-1-liuzixi...@huawei.com
Signed-off-by: Gerd Hoffmann
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/virtio/virtgpu_display.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c
b/drivers/gpu/drm/virtio/virtgpu_display.c
index a6caebd4a0dd..ef1f19083cd3 100644
--- a/drivers/gpu/drm/virtio/virtgpu_display.c
+++ b/drivers/gpu/drm/virtio/virtgpu_display.c
@@ -179,6 +179,8 @@ static int virtio_gpu_conn_get_modes(struct drm_connector
*connector)
DRM_DEBUG("add mode: %dx%d\n", width, height);
mode = drm_cvt_mode(connector->dev, width, height, 60,
false, false, false);
+ if (!mode)
+ return count;
mode->type |= DRM_MODE_TYPE_PREFERRED;
drm_mode_probed_add(connector, mode);
count++;
--
2.35.1
[PATCH AUTOSEL 5.15 002/109] drm/vmwgfx: validate the screen formats
From: Zack Rusin
[ Upstream commit 8bb75aeb58bd688d70827ae179bd3da57b6d975b ]
The kms code wasn't validating the modifiers and was letting through
unsupported formats. rgb8 was never properly supported and has no
matching svga screen target format so remove it.
This fixes format/modifier failures in kms_addfb_basic from IGT.
Signed-off-by: Zack Rusin
Reviewed-by: Martin Krastev
Link:
https://patchwork.freedesktop.org/patch/msgid/20220318174332.440068-4-z...@kde.org
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 30 +++--
drivers/gpu/drm/vmwgfx/vmwgfx_kms.h | 1 -
2 files changed, 16 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 50c64e7813be..171e90c4b9f3 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -916,6 +916,15 @@ static int vmw_kms_new_framebuffer_surface(struct
vmw_private *dev_priv,
* Sanity checks.
*/
+ if (!drm_any_plane_has_format(_priv->drm,
+ mode_cmd->pixel_format,
+ mode_cmd->modifier[0])) {
+ drm_dbg(_priv->drm,
+ "unsupported pixel format %p4cc / modifier 0x%llx\n",
+ _cmd->pixel_format, mode_cmd->modifier[0]);
+ return -EINVAL;
+ }
+
/* Surface must be marked as a scanout. */
if (unlikely(!surface->metadata.scanout))
return -EINVAL;
@@ -1229,20 +1238,13 @@ static int vmw_kms_new_framebuffer_bo(struct
vmw_private *dev_priv,
return -EINVAL;
}
- /* Limited framebuffer color depth support for screen objects */
- if (dev_priv->active_display_unit == vmw_du_screen_object) {
- switch (mode_cmd->pixel_format) {
- case DRM_FORMAT_XRGB:
- case DRM_FORMAT_ARGB:
- break;
- case DRM_FORMAT_XRGB1555:
- case DRM_FORMAT_RGB565:
- break;
- default:
- DRM_ERROR("Invalid pixel format: %p4cc\n",
- _cmd->pixel_format);
- return -EINVAL;
- }
+ if (!drm_any_plane_has_format(_priv->drm,
+ mode_cmd->pixel_format,
+ mode_cmd->modifier[0])) {
+ drm_dbg(_priv->drm,
+ "unsupported pixel format %p4cc / modifier 0x%llx\n",
+ _cmd->pixel_format, mode_cmd->modifier[0]);
+ return -EINVAL;
}
vfbd = kzalloc(sizeof(*vfbd), GFP_KERNEL);
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
index bbc809f7bd8a..8c8ee87fd3ac 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
@@ -248,7 +248,6 @@ struct vmw_framebuffer_bo {
static const uint32_t __maybe_unused vmw_primary_plane_formats[] = {
DRM_FORMAT_XRGB1555,
DRM_FORMAT_RGB565,
- DRM_FORMAT_RGB888,
DRM_FORMAT_XRGB,
DRM_FORMAT_ARGB,
};
--
2.35.1
[PATCH AUTOSEL 5.4 31/55] drm/amdgpu/ucode: Remove firmware load type check in amdgpu_ucode_free_bo
From: Alice Wong
[ Upstream commit ab0cd4a9ae5b4679b714d8dbfedc0901fecdce9f ]
When psp_hw_init failed, it will set the load_type to AMDGPU_FW_LOAD_DIRECT.
During amdgpu_device_ip_fini, amdgpu_ucode_free_bo checks that load_type is
AMDGPU_FW_LOAD_DIRECT and skips deallocating fw_buf causing memory leak.
Remove load_type check in amdgpu_ucode_free_bo.
Signed-off-by: Alice Wong
Reviewed-by: Alex Deucher
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
index 3a6115ad0196..f3250db7f9c2 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
@@ -568,8 +568,7 @@ int amdgpu_ucode_create_bo(struct amdgpu_device *adev)
void amdgpu_ucode_free_bo(struct amdgpu_device *adev)
{
- if (adev->firmware.load_type != AMDGPU_FW_LOAD_DIRECT)
- amdgpu_bo_free_kernel(>firmware.fw_buf,
+ amdgpu_bo_free_kernel(>firmware.fw_buf,
>firmware.fw_buf_mc,
>firmware.fw_buf_ptr);
}
--
2.35.1
[PATCH AUTOSEL 5.4 26/55] drm: msm: fix error check return value of irq_of_parse_and_map()
From: Lv Ruyi
[ Upstream commit b9e4f1d2b505df8e2439b63e67afaa287c1c43e2 ]
The irq_of_parse_and_map() function returns 0 on failure, and does not
return an negative value.
Reported-by: Zeal Robot
Signed-off-by: Lv Ruyi
Reviewed-by: Dmitry Baryshkov
Patchwork: https://patchwork.freedesktop.org/patch/483175/
Link: https://lore.kernel.org/r/20220424031959.3172406-1-lv.r...@zte.com.cn
Signed-off-by: Dmitry Baryshkov
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
index 77823ccdd0f8..39d0082eedcc 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
@@ -698,9 +698,9 @@ struct msm_kms *mdp5_kms_init(struct drm_device *dev)
pdev = mdp5_kms->pdev;
irq = irq_of_parse_and_map(pdev->dev.of_node, 0);
- if (irq < 0) {
- ret = irq;
- DRM_DEV_ERROR(>dev, "failed to get irq: %d\n", ret);
+ if (!irq) {
+ ret = -EINVAL;
+ DRM_DEV_ERROR(>dev, "failed to get irq\n");
goto fail;
}
--
2.35.1
[PATCH AUTOSEL 5.4 24/55] drm/amd/pm: fix the compile warning
From: Evan Quan
[ Upstream commit 555238d92ac32dbad2d77ad2bafc48d17391990c ]
Fix the compile warning below:
drivers/gpu/drm/amd/amdgpu/../pm/legacy-dpm/kv_dpm.c:1641
kv_get_acp_boot_level() warn: always true condition '(table->entries[i]->clk >=
0) => (0-u32max >= 0)'
Reported-by: kernel test robot
CC: Alex Deucher
Signed-off-by: Evan Quan
Reviewed-by: Alex Deucher
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/kv_dpm.c | 14 +-
1 file changed, 1 insertion(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/kv_dpm.c
b/drivers/gpu/drm/amd/amdgpu/kv_dpm.c
index 4b3faaccecb9..c8a5a5698edd 100644
--- a/drivers/gpu/drm/amd/amdgpu/kv_dpm.c
+++ b/drivers/gpu/drm/amd/amdgpu/kv_dpm.c
@@ -1609,19 +1609,7 @@ static int kv_update_samu_dpm(struct amdgpu_device
*adev, bool gate)
static u8 kv_get_acp_boot_level(struct amdgpu_device *adev)
{
- u8 i;
- struct amdgpu_clock_voltage_dependency_table *table =
- >pm.dpm.dyn_state.acp_clock_voltage_dependency_table;
-
- for (i = 0; i < table->count; i++) {
- if (table->entries[i].clk >= 0) /* XXX */
- break;
- }
-
- if (i >= table->count)
- i = table->count - 1;
-
- return i;
+ return 0;
}
static void kv_update_acp_boot_level(struct amdgpu_device *adev)
--
2.35.1
[PATCH AUTOSEL 5.4 23/55] drm/plane: Move range check for format_count earlier
From: Steven Price
[ Upstream commit 4b674dd69701c2e22e8e7770c1706a69f3b17269 ]
While the check for format_count > 64 in __drm_universal_plane_init()
shouldn't be hit (it's a WARN_ON), in its current position it will then
leak the plane->format_types array and fail to call
drm_mode_object_unregister() leaking the modeset identifier. Move it to
the start of the function to avoid allocating those resources in the
first place.
Signed-off-by: Steven Price
Signed-off-by: Liviu Dudau
Link:
https://lore.kernel.org/dri-devel/20211203102815.38624-1-steven.pr...@arm.com/
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/drm_plane.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index d6ad60ab0d38..6bdebcca5690 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -186,6 +186,13 @@ int drm_universal_plane_init(struct drm_device *dev,
struct drm_plane *plane,
if (WARN_ON(config->num_total_plane >= 32))
return -EINVAL;
+ /*
+* First driver to need more than 64 formats needs to fix this. Each
+* format is encoded as a bit and the current code only supports a u64.
+*/
+ if (WARN_ON(format_count > 64))
+ return -EINVAL;
+
WARN_ON(drm_drv_uses_atomic_modeset(dev) &&
(!funcs->atomic_destroy_state ||
!funcs->atomic_duplicate_state));
@@ -207,13 +214,6 @@ int drm_universal_plane_init(struct drm_device *dev,
struct drm_plane *plane,
return -ENOMEM;
}
- /*
-* First driver to need more than 64 formats needs to fix this. Each
-* format is encoded as a bit and the current code only supports a u64.
-*/
- if (WARN_ON(format_count > 64))
- return -EINVAL;
-
if (format_modifiers) {
const uint64_t *temp_modifiers = format_modifiers;
while (*temp_modifiers++ != DRM_FORMAT_MOD_INVALID)
--
2.35.1
[PATCH AUTOSEL 5.4 20/55] drm/sun4i: Add support for D1 TCONs
From: Samuel Holland
[ Upstream commit b9b52d2f4aafa2bd637ace0f24615bdad8e49f01 ]
D1 has a TCON TOP, so its quirks are similar to those for the R40 TCONs.
While there are some register changes, the part of the TCON TV supported
by the driver matches the R40 quirks, so that quirks structure can be
reused. D1 has the first supported TCON LCD with a TCON TOP, so the TCON
LCD needs a new quirks structure.
D1's TCON LCD hardware supports LVDS; in fact it provides dual-link LVDS
from a single TCON. However, it comes with a brand new LVDS PHY. Since
this PHY has not been tested, leave out LVDS driver support for now.
Signed-off-by: Samuel Holland
Reviewed-by: Jernej Skrabec
Signed-off-by: Maxime Ripard
Link:
https://patchwork.freedesktop.org/patch/msgid/20220424162633.12369-14-sam...@sholland.org
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index eb3b2350687f..9687f2b9652d 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -1509,6 +1509,12 @@ static const struct sun4i_tcon_quirks
sun9i_a80_tcon_tv_quirks = {
.needs_edp_reset = true,
};
+static const struct sun4i_tcon_quirks sun20i_d1_lcd_quirks = {
+ .has_channel_0 = true,
+ .dclk_min_div = 1,
+ .set_mux= sun8i_r40_tcon_tv_set_mux,
+};
+
/* sun4i_drv uses this list to check if a device node is a TCON */
const struct of_device_id sun4i_tcon_of_table[] = {
{ .compatible = "allwinner,sun4i-a10-tcon", .data = _a10_quirks },
@@ -1526,6 +1532,8 @@ const struct of_device_id sun4i_tcon_of_table[] = {
{ .compatible = "allwinner,sun8i-v3s-tcon", .data = _v3s_quirks },
{ .compatible = "allwinner,sun9i-a80-tcon-lcd", .data =
_a80_tcon_lcd_quirks },
{ .compatible = "allwinner,sun9i-a80-tcon-tv", .data =
_a80_tcon_tv_quirks },
+ { .compatible = "allwinner,sun20i-d1-tcon-lcd", .data =
_d1_lcd_quirks },
+ { .compatible = "allwinner,sun20i-d1-tcon-tv", .data =
_r40_tv_quirks },
{ }
};
MODULE_DEVICE_TABLE(of, sun4i_tcon_of_table);
--
2.35.1
[PATCH AUTOSEL 5.4 13/55] drm/amd/pm: fix double free in si_parse_power_table()
From: Keita Suzuki
[ Upstream commit f3fa2becf2fc25b6ac7cf8d8b1a2e4a86b3b72bd ]
In function si_parse_power_table(), array adev->pm.dpm.ps and its member
is allocated. If the allocation of each member fails, the array itself
is freed and returned with an error code. However, the array is later
freed again in si_dpm_fini() function which is called when the function
returns an error.
This leads to potential double free of the array adev->pm.dpm.ps, as
well as leak of its array members, since the members are not freed in
the allocation function and the array is not nulled when freed.
In addition adev->pm.dpm.num_ps, which keeps track of the allocated
array member, is not updated until the member allocation is
successfully finished, this could also lead to either use after free,
or uninitialized variable access in si_dpm_fini().
Fix this by postponing the free of the array until si_dpm_fini() and
increment adev->pm.dpm.num_ps everytime the array member is allocated.
Signed-off-by: Keita Suzuki
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/si_dpm.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/si_dpm.c
b/drivers/gpu/drm/amd/amdgpu/si_dpm.c
index 4cb4c891120b..9931d5c17cfb 100644
--- a/drivers/gpu/drm/amd/amdgpu/si_dpm.c
+++ b/drivers/gpu/drm/amd/amdgpu/si_dpm.c
@@ -7250,17 +7250,15 @@ static int si_parse_power_table(struct amdgpu_device
*adev)
if (!adev->pm.dpm.ps)
return -ENOMEM;
power_state_offset = (u8 *)state_array->states;
- for (i = 0; i < state_array->ucNumEntries; i++) {
+ for (adev->pm.dpm.num_ps = 0, i = 0; i < state_array->ucNumEntries;
i++) {
u8 *idx;
power_state = (union pplib_power_state *)power_state_offset;
non_clock_array_index = power_state->v2.nonClockInfoIndex;
non_clock_info = (struct _ATOM_PPLIB_NONCLOCK_INFO *)
_clock_info_array->nonClockInfo[non_clock_array_index];
ps = kzalloc(sizeof(struct si_ps), GFP_KERNEL);
- if (ps == NULL) {
- kfree(adev->pm.dpm.ps);
+ if (ps == NULL)
return -ENOMEM;
- }
adev->pm.dpm.ps[i].ps_priv = ps;
si_parse_pplib_non_clock_info(adev, >pm.dpm.ps[i],
non_clock_info,
@@ -7282,8 +7280,8 @@ static int si_parse_power_table(struct amdgpu_device
*adev)
k++;
}
power_state_offset += 2 + power_state->v2.ucNumDPMLevels;
+ adev->pm.dpm.num_ps++;
}
- adev->pm.dpm.num_ps = state_array->ucNumEntries;
/* fill in the vce power states */
for (i = 0; i < adev->pm.dpm.num_of_vce_states; i++) {
--
2.35.1
[PATCH AUTOSEL 5.4 09/55] drm/komeda: return early if drm_universal_plane_init() fails.
From: Liviu Dudau
[ Upstream commit c8f76c37cc3668ee45e081e76a15f24a352ebbdd ]
If drm_universal_plane_init() fails early we jump to the common cleanup code
that calls komeda_plane_destroy() which in turn could access the uninitalised
drm_plane and crash. Return early if an error is detected without going through
the common code.
Reported-by: Steven Price
Reviewed-by: Steven Price
Signed-off-by: Liviu Dudau
Link:
https://lore.kernel.org/dri-devel/20211203100946.2706922-1-liviu.du...@arm.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/arm/display/komeda/komeda_plane.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
b/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
index 98e915e325dd..a5f57b38d193 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
@@ -274,8 +274,10 @@ static int komeda_plane_add(struct komeda_kms_dev *kms,
komeda_put_fourcc_list(formats);
- if (err)
- goto cleanup;
+ if (err) {
+ kfree(kplane);
+ return err;
+ }
drm_plane_helper_add(plane, _plane_helper_funcs);
--
2.35.1
[PATCH AUTOSEL 5.4 07/55] fbcon: Consistently protect deferred_takeover with console_lock()
From: Daniel Vetter
[ Upstream commit 43553559121ca90965b572cf8a1d6d0fd618b449 ]
This shouldn't be a problem in practice since until we've actually
taken over the console there's nothing we've registered with the
console/vt subsystem, so the exit/unbind path that check this can't
do the wrong thing. But it's confusing, so fix it by moving it a tad
later.
Acked-by: Sam Ravnborg
Signed-off-by: Daniel Vetter
Cc: Daniel Vetter
Cc: Du Cheng
Cc: Tetsuo Handa
Cc: Claudio Suarez
Cc: Thomas Zimmermann
Link:
https://patchwork.freedesktop.org/patch/msgid/20220405210335.3434130-14-daniel.vet...@ffwll.ch
Signed-off-by: Sasha Levin
---
drivers/video/fbdev/core/fbcon.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 75b770514067..1decded4845f 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -3286,6 +3286,9 @@ static void fbcon_register_existing_fbs(struct
work_struct *work)
console_lock();
+ deferred_takeover = false;
+ logo_shown = FBCON_LOGO_DONTSHOW;
+
for_each_registered_fb(i)
fbcon_fb_registered(registered_fb[i]);
@@ -3303,8 +3306,6 @@ static int fbcon_output_notifier(struct notifier_block
*nb,
pr_info("fbcon: Taking over console\n");
dummycon_unregister_output_notifier(_output_nb);
- deferred_takeover = false;
- logo_shown = FBCON_LOGO_DONTSHOW;
/* We may get called in atomic context */
schedule_work(_deferred_takeover_work);
--
2.35.1
[PATCH AUTOSEL 5.4 01/55] drm/virtio: fix NULL pointer dereference in virtio_gpu_conn_get_modes
From: Liu Zixian
[ Upstream commit 194d250cdc4a40ccbd179afd522a9e9846957402 ]
drm_cvt_mode may return NULL and we should check it.
This bug is found by syzkaller:
FAULT_INJECTION stacktrace:
[ 168.567394] FAULT_INJECTION: forcing a failure.
name failslab, interval 1, probability 0, space 0, times 1
[ 168.567403] CPU: 1 PID: 6425 Comm: syz Kdump: loaded Not tainted
4.19.90-vhulk2201.1.0.h1035.kasan.eulerosv2r10.aarch64 #1
[ 168.567406] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
[ 168.567408] Call trace:
[ 168.567414] dump_backtrace+0x0/0x310
[ 168.567418] show_stack+0x28/0x38
[ 168.567423] dump_stack+0xec/0x15c
[ 168.567427] should_fail+0x3ac/0x3d0
[ 168.567437] __should_failslab+0xb8/0x120
[ 168.567441] should_failslab+0x28/0xc0
[ 168.567445] kmem_cache_alloc_trace+0x50/0x640
[ 168.567454] drm_mode_create+0x40/0x90
[ 168.567458] drm_cvt_mode+0x48/0xc78
[ 168.567477] virtio_gpu_conn_get_modes+0xa8/0x140 [virtio_gpu]
[ 168.567485] drm_helper_probe_single_connector_modes+0x3a4/0xd80
[ 168.567492] drm_mode_getconnector+0x2e0/0xa70
[ 168.567496] drm_ioctl_kernel+0x11c/0x1d8
[ 168.567514] drm_ioctl+0x558/0x6d0
[ 168.567522] do_vfs_ioctl+0x160/0xf30
[ 168.567525] ksys_ioctl+0x98/0xd8
[ 168.567530] __arm64_sys_ioctl+0x50/0xc8
[ 168.567536] el0_svc_common+0xc8/0x320
[ 168.567540] el0_svc_handler+0xf8/0x160
[ 168.567544] el0_svc+0x10/0x218
KASAN stacktrace:
[ 168.567561] BUG: KASAN: null-ptr-deref in
virtio_gpu_conn_get_modes+0xb4/0x140 [virtio_gpu]
[ 168.567565] Read of size 4 at addr 0054 by task syz/6425
[ 168.567566]
[ 168.567571] CPU: 1 PID: 6425 Comm: syz Kdump: loaded Not tainted
4.19.90-vhulk2201.1.0.h1035.kasan.eulerosv2r10.aarch64 #1
[ 168.567573] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
[ 168.567575] Call trace:
[ 168.567578] dump_backtrace+0x0/0x310
[ 168.567582] show_stack+0x28/0x38
[ 168.567586] dump_stack+0xec/0x15c
[ 168.567591] kasan_report+0x244/0x2f0
[ 168.567594] __asan_load4+0x58/0xb0
[ 168.567607] virtio_gpu_conn_get_modes+0xb4/0x140 [virtio_gpu]
[ 168.567612] drm_helper_probe_single_connector_modes+0x3a4/0xd80
[ 168.567617] drm_mode_getconnector+0x2e0/0xa70
[ 168.567621] drm_ioctl_kernel+0x11c/0x1d8
[ 168.567624] drm_ioctl+0x558/0x6d0
[ 168.567628] do_vfs_ioctl+0x160/0xf30
[ 168.567632] ksys_ioctl+0x98/0xd8
[ 168.567636] __arm64_sys_ioctl+0x50/0xc8
[ 168.567641] el0_svc_common+0xc8/0x320
[ 168.567645] el0_svc_handler+0xf8/0x160
[ 168.567649] el0_svc+0x10/0x218
Signed-off-by: Liu Zixian
Link:
http://patchwork.freedesktop.org/patch/msgid/20220322091730.1653-1-liuzixi...@huawei.com
Signed-off-by: Gerd Hoffmann
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/virtio/virtgpu_display.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c
b/drivers/gpu/drm/virtio/virtgpu_display.c
index e622485ae826..7e34307eb075 100644
--- a/drivers/gpu/drm/virtio/virtgpu_display.c
+++ b/drivers/gpu/drm/virtio/virtgpu_display.c
@@ -174,6 +174,8 @@ static int virtio_gpu_conn_get_modes(struct drm_connector
*connector)
DRM_DEBUG("add mode: %dx%d\n", width, height);
mode = drm_cvt_mode(connector->dev, width, height, 60,
false, false, false);
+ if (!mode)
+ return count;
mode->type |= DRM_MODE_TYPE_PREFERRED;
drm_mode_probed_add(connector, mode);
count++;
--
2.35.1
[PATCH AUTOSEL 5.10 34/76] drm/amd/pm: fix the compile warning
From: Evan Quan
[ Upstream commit 555238d92ac32dbad2d77ad2bafc48d17391990c ]
Fix the compile warning below:
drivers/gpu/drm/amd/amdgpu/../pm/legacy-dpm/kv_dpm.c:1641
kv_get_acp_boot_level() warn: always true condition '(table->entries[i]->clk >=
0) => (0-u32max >= 0)'
Reported-by: kernel test robot
CC: Alex Deucher
Signed-off-by: Evan Quan
Reviewed-by: Alex Deucher
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/pm/powerplay/kv_dpm.c | 14 +-
1 file changed, 1 insertion(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/powerplay/kv_dpm.c
b/drivers/gpu/drm/amd/pm/powerplay/kv_dpm.c
index 4b3faaccecb9..c8a5a5698edd 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/kv_dpm.c
+++ b/drivers/gpu/drm/amd/pm/powerplay/kv_dpm.c
@@ -1609,19 +1609,7 @@ static int kv_update_samu_dpm(struct amdgpu_device
*adev, bool gate)
static u8 kv_get_acp_boot_level(struct amdgpu_device *adev)
{
- u8 i;
- struct amdgpu_clock_voltage_dependency_table *table =
- >pm.dpm.dyn_state.acp_clock_voltage_dependency_table;
-
- for (i = 0; i < table->count; i++) {
- if (table->entries[i].clk >= 0) /* XXX */
- break;
- }
-
- if (i >= table->count)
- i = table->count - 1;
-
- return i;
+ return 0;
}
static void kv_update_acp_boot_level(struct amdgpu_device *adev)
--
2.35.1
[PATCH AUTOSEL 5.10 33/76] drm/plane: Move range check for format_count earlier
From: Steven Price
[ Upstream commit 4b674dd69701c2e22e8e7770c1706a69f3b17269 ]
While the check for format_count > 64 in __drm_universal_plane_init()
shouldn't be hit (it's a WARN_ON), in its current position it will then
leak the plane->format_types array and fail to call
drm_mode_object_unregister() leaking the modeset identifier. Move it to
the start of the function to avoid allocating those resources in the
first place.
Signed-off-by: Steven Price
Signed-off-by: Liviu Dudau
Link:
https://lore.kernel.org/dri-devel/20211203102815.38624-1-steven.pr...@arm.com/
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/drm_plane.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index affe1cfed009..24f643982903 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -186,6 +186,13 @@ int drm_universal_plane_init(struct drm_device *dev,
struct drm_plane *plane,
if (WARN_ON(config->num_total_plane >= 32))
return -EINVAL;
+ /*
+* First driver to need more than 64 formats needs to fix this. Each
+* format is encoded as a bit and the current code only supports a u64.
+*/
+ if (WARN_ON(format_count > 64))
+ return -EINVAL;
+
WARN_ON(drm_drv_uses_atomic_modeset(dev) &&
(!funcs->atomic_destroy_state ||
!funcs->atomic_duplicate_state));
@@ -207,13 +214,6 @@ int drm_universal_plane_init(struct drm_device *dev,
struct drm_plane *plane,
return -ENOMEM;
}
- /*
-* First driver to need more than 64 formats needs to fix this. Each
-* format is encoded as a bit and the current code only supports a u64.
-*/
- if (WARN_ON(format_count > 64))
- return -EINVAL;
-
if (format_modifiers) {
const uint64_t *temp_modifiers = format_modifiers;
--
2.35.1
[PATCH AUTOSEL 5.10 27/76] drm/sun4i: Add support for D1 TCONs
From: Samuel Holland
[ Upstream commit b9b52d2f4aafa2bd637ace0f24615bdad8e49f01 ]
D1 has a TCON TOP, so its quirks are similar to those for the R40 TCONs.
While there are some register changes, the part of the TCON TV supported
by the driver matches the R40 quirks, so that quirks structure can be
reused. D1 has the first supported TCON LCD with a TCON TOP, so the TCON
LCD needs a new quirks structure.
D1's TCON LCD hardware supports LVDS; in fact it provides dual-link LVDS
from a single TCON. However, it comes with a brand new LVDS PHY. Since
this PHY has not been tested, leave out LVDS driver support for now.
Signed-off-by: Samuel Holland
Reviewed-by: Jernej Skrabec
Signed-off-by: Maxime Ripard
Link:
https://patchwork.freedesktop.org/patch/msgid/20220424162633.12369-14-sam...@sholland.org
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 9f06dec0fc61..e27103f5a075 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -1544,6 +1544,12 @@ static const struct sun4i_tcon_quirks
sun9i_a80_tcon_tv_quirks = {
.needs_edp_reset = true,
};
+static const struct sun4i_tcon_quirks sun20i_d1_lcd_quirks = {
+ .has_channel_0 = true,
+ .dclk_min_div = 1,
+ .set_mux= sun8i_r40_tcon_tv_set_mux,
+};
+
/* sun4i_drv uses this list to check if a device node is a TCON */
const struct of_device_id sun4i_tcon_of_table[] = {
{ .compatible = "allwinner,sun4i-a10-tcon", .data = _a10_quirks },
@@ -1561,6 +1567,8 @@ const struct of_device_id sun4i_tcon_of_table[] = {
{ .compatible = "allwinner,sun8i-v3s-tcon", .data = _v3s_quirks },
{ .compatible = "allwinner,sun9i-a80-tcon-lcd", .data =
_a80_tcon_lcd_quirks },
{ .compatible = "allwinner,sun9i-a80-tcon-tv", .data =
_a80_tcon_tv_quirks },
+ { .compatible = "allwinner,sun20i-d1-tcon-lcd", .data =
_d1_lcd_quirks },
+ { .compatible = "allwinner,sun20i-d1-tcon-tv", .data =
_r40_tv_quirks },
{ }
};
MODULE_DEVICE_TABLE(of, sun4i_tcon_of_table);
--
2.35.1
[PATCH AUTOSEL 5.10 19/76] drm/amd/pm: fix double free in si_parse_power_table()
From: Keita Suzuki
[ Upstream commit f3fa2becf2fc25b6ac7cf8d8b1a2e4a86b3b72bd ]
In function si_parse_power_table(), array adev->pm.dpm.ps and its member
is allocated. If the allocation of each member fails, the array itself
is freed and returned with an error code. However, the array is later
freed again in si_dpm_fini() function which is called when the function
returns an error.
This leads to potential double free of the array adev->pm.dpm.ps, as
well as leak of its array members, since the members are not freed in
the allocation function and the array is not nulled when freed.
In addition adev->pm.dpm.num_ps, which keeps track of the allocated
array member, is not updated until the member allocation is
successfully finished, this could also lead to either use after free,
or uninitialized variable access in si_dpm_fini().
Fix this by postponing the free of the array until si_dpm_fini() and
increment adev->pm.dpm.num_ps everytime the array member is allocated.
Signed-off-by: Keita Suzuki
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/pm/powerplay/si_dpm.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/powerplay/si_dpm.c
b/drivers/gpu/drm/amd/pm/powerplay/si_dpm.c
index a1e7ba5995c5..d6544a6dabc7 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/si_dpm.c
+++ b/drivers/gpu/drm/amd/pm/powerplay/si_dpm.c
@@ -7250,17 +7250,15 @@ static int si_parse_power_table(struct amdgpu_device
*adev)
if (!adev->pm.dpm.ps)
return -ENOMEM;
power_state_offset = (u8 *)state_array->states;
- for (i = 0; i < state_array->ucNumEntries; i++) {
+ for (adev->pm.dpm.num_ps = 0, i = 0; i < state_array->ucNumEntries;
i++) {
u8 *idx;
power_state = (union pplib_power_state *)power_state_offset;
non_clock_array_index = power_state->v2.nonClockInfoIndex;
non_clock_info = (struct _ATOM_PPLIB_NONCLOCK_INFO *)
_clock_info_array->nonClockInfo[non_clock_array_index];
ps = kzalloc(sizeof(struct si_ps), GFP_KERNEL);
- if (ps == NULL) {
- kfree(adev->pm.dpm.ps);
+ if (ps == NULL)
return -ENOMEM;
- }
adev->pm.dpm.ps[i].ps_priv = ps;
si_parse_pplib_non_clock_info(adev, >pm.dpm.ps[i],
non_clock_info,
@@ -7282,8 +7280,8 @@ static int si_parse_power_table(struct amdgpu_device
*adev)
k++;
}
power_state_offset += 2 + power_state->v2.ucNumDPMLevels;
+ adev->pm.dpm.num_ps++;
}
- adev->pm.dpm.num_ps = state_array->ucNumEntries;
/* fill in the vce power states */
for (i = 0; i < adev->pm.dpm.num_of_vce_states; i++) {
--
2.35.1
[PATCH AUTOSEL 5.10 12/76] drm/komeda: return early if drm_universal_plane_init() fails.
From: Liviu Dudau
[ Upstream commit c8f76c37cc3668ee45e081e76a15f24a352ebbdd ]
If drm_universal_plane_init() fails early we jump to the common cleanup code
that calls komeda_plane_destroy() which in turn could access the uninitalised
drm_plane and crash. Return early if an error is detected without going through
the common code.
Reported-by: Steven Price
Reviewed-by: Steven Price
Signed-off-by: Liviu Dudau
Link:
https://lore.kernel.org/dri-devel/20211203100946.2706922-1-liviu.du...@arm.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/arm/display/komeda/komeda_plane.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
b/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
index 98e915e325dd..a5f57b38d193 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
@@ -274,8 +274,10 @@ static int komeda_plane_add(struct komeda_kms_dev *kms,
komeda_put_fourcc_list(formats);
- if (err)
- goto cleanup;
+ if (err) {
+ kfree(kplane);
+ return err;
+ }
drm_plane_helper_add(plane, _plane_helper_funcs);
--
2.35.1
[PATCH AUTOSEL 5.10 09/76] fbcon: Consistently protect deferred_takeover with console_lock()
From: Daniel Vetter
[ Upstream commit 43553559121ca90965b572cf8a1d6d0fd618b449 ]
This shouldn't be a problem in practice since until we've actually
taken over the console there's nothing we've registered with the
console/vt subsystem, so the exit/unbind path that check this can't
do the wrong thing. But it's confusing, so fix it by moving it a tad
later.
Acked-by: Sam Ravnborg
Signed-off-by: Daniel Vetter
Cc: Daniel Vetter
Cc: Du Cheng
Cc: Tetsuo Handa
Cc: Claudio Suarez
Cc: Thomas Zimmermann
Link:
https://patchwork.freedesktop.org/patch/msgid/20220405210335.3434130-14-daniel.vet...@ffwll.ch
Signed-off-by: Sasha Levin
---
drivers/video/fbdev/core/fbcon.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index f102519ccefb..13de2bebb09a 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -3300,6 +3300,9 @@ static void fbcon_register_existing_fbs(struct
work_struct *work)
console_lock();
+ deferred_takeover = false;
+ logo_shown = FBCON_LOGO_DONTSHOW;
+
for_each_registered_fb(i)
fbcon_fb_registered(registered_fb[i]);
@@ -3317,8 +3320,6 @@ static int fbcon_output_notifier(struct notifier_block
*nb,
pr_info("fbcon: Taking over console\n");
dummycon_unregister_output_notifier(_output_nb);
- deferred_takeover = false;
- logo_shown = FBCON_LOGO_DONTSHOW;
/* We may get called in atomic context */
schedule_work(_deferred_takeover_work);
--
2.35.1
[PATCH AUTOSEL 5.10 02/76] drm/virtio: fix NULL pointer dereference in virtio_gpu_conn_get_modes
From: Liu Zixian
[ Upstream commit 194d250cdc4a40ccbd179afd522a9e9846957402 ]
drm_cvt_mode may return NULL and we should check it.
This bug is found by syzkaller:
FAULT_INJECTION stacktrace:
[ 168.567394] FAULT_INJECTION: forcing a failure.
name failslab, interval 1, probability 0, space 0, times 1
[ 168.567403] CPU: 1 PID: 6425 Comm: syz Kdump: loaded Not tainted
4.19.90-vhulk2201.1.0.h1035.kasan.eulerosv2r10.aarch64 #1
[ 168.567406] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
[ 168.567408] Call trace:
[ 168.567414] dump_backtrace+0x0/0x310
[ 168.567418] show_stack+0x28/0x38
[ 168.567423] dump_stack+0xec/0x15c
[ 168.567427] should_fail+0x3ac/0x3d0
[ 168.567437] __should_failslab+0xb8/0x120
[ 168.567441] should_failslab+0x28/0xc0
[ 168.567445] kmem_cache_alloc_trace+0x50/0x640
[ 168.567454] drm_mode_create+0x40/0x90
[ 168.567458] drm_cvt_mode+0x48/0xc78
[ 168.567477] virtio_gpu_conn_get_modes+0xa8/0x140 [virtio_gpu]
[ 168.567485] drm_helper_probe_single_connector_modes+0x3a4/0xd80
[ 168.567492] drm_mode_getconnector+0x2e0/0xa70
[ 168.567496] drm_ioctl_kernel+0x11c/0x1d8
[ 168.567514] drm_ioctl+0x558/0x6d0
[ 168.567522] do_vfs_ioctl+0x160/0xf30
[ 168.567525] ksys_ioctl+0x98/0xd8
[ 168.567530] __arm64_sys_ioctl+0x50/0xc8
[ 168.567536] el0_svc_common+0xc8/0x320
[ 168.567540] el0_svc_handler+0xf8/0x160
[ 168.567544] el0_svc+0x10/0x218
KASAN stacktrace:
[ 168.567561] BUG: KASAN: null-ptr-deref in
virtio_gpu_conn_get_modes+0xb4/0x140 [virtio_gpu]
[ 168.567565] Read of size 4 at addr 0054 by task syz/6425
[ 168.567566]
[ 168.567571] CPU: 1 PID: 6425 Comm: syz Kdump: loaded Not tainted
4.19.90-vhulk2201.1.0.h1035.kasan.eulerosv2r10.aarch64 #1
[ 168.567573] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
[ 168.567575] Call trace:
[ 168.567578] dump_backtrace+0x0/0x310
[ 168.567582] show_stack+0x28/0x38
[ 168.567586] dump_stack+0xec/0x15c
[ 168.567591] kasan_report+0x244/0x2f0
[ 168.567594] __asan_load4+0x58/0xb0
[ 168.567607] virtio_gpu_conn_get_modes+0xb4/0x140 [virtio_gpu]
[ 168.567612] drm_helper_probe_single_connector_modes+0x3a4/0xd80
[ 168.567617] drm_mode_getconnector+0x2e0/0xa70
[ 168.567621] drm_ioctl_kernel+0x11c/0x1d8
[ 168.567624] drm_ioctl+0x558/0x6d0
[ 168.567628] do_vfs_ioctl+0x160/0xf30
[ 168.567632] ksys_ioctl+0x98/0xd8
[ 168.567636] __arm64_sys_ioctl+0x50/0xc8
[ 168.567641] el0_svc_common+0xc8/0x320
[ 168.567645] el0_svc_handler+0xf8/0x160
[ 168.567649] el0_svc+0x10/0x218
Signed-off-by: Liu Zixian
Link:
http://patchwork.freedesktop.org/patch/msgid/20220322091730.1653-1-liuzixi...@huawei.com
Signed-off-by: Gerd Hoffmann
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/virtio/virtgpu_display.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c
b/drivers/gpu/drm/virtio/virtgpu_display.c
index f84b7e61311b..9b2b99e85342 100644
--- a/drivers/gpu/drm/virtio/virtgpu_display.c
+++ b/drivers/gpu/drm/virtio/virtgpu_display.c
@@ -177,6 +177,8 @@ static int virtio_gpu_conn_get_modes(struct drm_connector
*connector)
DRM_DEBUG("add mode: %dx%d\n", width, height);
mode = drm_cvt_mode(connector->dev, width, height, 60,
false, false, false);
+ if (!mode)
+ return count;
mode->type |= DRM_MODE_TYPE_PREFERRED;
drm_mode_probed_add(connector, mode);
count++;
--
2.35.1
[PATCH AUTOSEL 5.15 089/109] drm/amd/pm: update smartshift powerboost calc for smu13
From: Sathishkumar S
[ Upstream commit cdf4c8ec39872a61a58d62f19b4db80f0f7bc586 ]
smartshift apu and dgpu power boost are reported as percentage
with respect to their power limits. adjust the units of power before
calculating the percentage of boost.
Signed-off-by: Sathishkumar S
Reviewed-by: Lijo Lazar
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
.../drm/amd/pm/swsmu/smu13/yellow_carp_ppt.c | 62 ++-
1 file changed, 46 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/yellow_carp_ppt.c
b/drivers/gpu/drm/amd/pm/swsmu/smu13/yellow_carp_ppt.c
index 0e1a843608e4..33bd5430c6de 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu13/yellow_carp_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/yellow_carp_ppt.c
@@ -305,6 +305,42 @@ static int yellow_carp_mode2_reset(struct smu_context *smu)
return yellow_carp_mode_reset(smu, SMU_RESET_MODE_2);
}
+
+static void yellow_carp_get_ss_power_percent(SmuMetrics_t *metrics,
+ uint32_t *apu_percent, uint32_t
*dgpu_percent)
+{
+ uint32_t apu_boost = 0;
+ uint32_t dgpu_boost = 0;
+ uint16_t apu_limit = 0;
+ uint16_t dgpu_limit = 0;
+ uint16_t apu_power = 0;
+ uint16_t dgpu_power = 0;
+
+ /* APU and dGPU power values are reported in milli Watts
+* and STAPM power limits are in Watts */
+ apu_power = metrics->ApuPower/1000;
+ apu_limit = metrics->StapmOpnLimit;
+ if (apu_power > apu_limit && apu_limit != 0)
+ apu_boost = ((apu_power - apu_limit) * 100) / apu_limit;
+ apu_boost = (apu_boost > 100) ? 100 : apu_boost;
+
+ dgpu_power = metrics->dGpuPower/1000;
+ if (metrics->StapmCurrentLimit > metrics->StapmOpnLimit)
+ dgpu_limit = metrics->StapmCurrentLimit -
metrics->StapmOpnLimit;
+ if (dgpu_power > dgpu_limit && dgpu_limit != 0)
+ dgpu_boost = ((dgpu_power - dgpu_limit) * 100) / dgpu_limit;
+ dgpu_boost = (dgpu_boost > 100) ? 100 : dgpu_boost;
+
+ if (dgpu_boost >= apu_boost)
+ apu_boost = 0;
+ else
+ dgpu_boost = 0;
+
+ *apu_percent = apu_boost;
+ *dgpu_percent = dgpu_boost;
+
+}
+
static int yellow_carp_get_smu_metrics_data(struct smu_context *smu,
MetricsMember_t member,
uint32_t *value)
@@ -313,6 +349,8 @@ static int yellow_carp_get_smu_metrics_data(struct
smu_context *smu,
SmuMetrics_t *metrics = (SmuMetrics_t *)smu_table->metrics_table;
int ret = 0;
+ uint32_t apu_percent = 0;
+ uint32_t dgpu_percent = 0;
mutex_lock(>metrics_lock);
@@ -365,26 +403,18 @@ static int yellow_carp_get_smu_metrics_data(struct
smu_context *smu,
*value = metrics->Voltage[1];
break;
case METRICS_SS_APU_SHARE:
- /* return the percentage of APU power with respect to APU's
power limit.
-* percentage is reported, this isn't boost value. Smartshift
power
-* boost/shift is only when the percentage is more than 100.
+ /* return the percentage of APU power boost
+* with respect to APU's power limit.
*/
- if (metrics->StapmOpnLimit > 0)
- *value = (metrics->ApuPower * 100) /
metrics->StapmOpnLimit;
- else
- *value = 0;
+ yellow_carp_get_ss_power_percent(metrics, _percent,
_percent);
+ *value = apu_percent;
break;
case METRICS_SS_DGPU_SHARE:
- /* return the percentage of dGPU power with respect to dGPU's
power limit.
-* percentage is reported, this isn't boost value. Smartshift
power
-* boost/shift is only when the percentage is more than 100.
+ /* return the percentage of dGPU power boost
+* with respect to dGPU's power limit.
*/
- if ((metrics->dGpuPower > 0) &&
- (metrics->StapmCurrentLimit > metrics->StapmOpnLimit))
- *value = (metrics->dGpuPower * 100) /
- (metrics->StapmCurrentLimit -
metrics->StapmOpnLimit);
- else
- *value = 0;
+ yellow_carp_get_ss_power_percent(metrics, _percent,
_percent);
+ *value = dgpu_percent;
break;
default:
*value = UINT_MAX;
--
2.35.1
[PATCH AUTOSEL 5.15 088/109] drm/amd/pm: update smartshift powerboost calc for smu12
From: Sathishkumar S
[ Upstream commit 138292f1dc00e7e0724f44769f9da39cf2f3bf0b ]
smartshift apu and dgpu power boost are reported as percentage with
respect to their power limits. This value[0-100] reflects the boost
for the respective device.
Signed-off-by: Sathishkumar S
Reviewed-by: Lijo Lazar
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
.../gpu/drm/amd/pm/swsmu/smu12/renoir_ppt.c | 60 ++-
1 file changed, 44 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu12/renoir_ppt.c
b/drivers/gpu/drm/amd/pm/swsmu/smu12/renoir_ppt.c
index 145f13b8c977..138466081875 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu12/renoir_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu12/renoir_ppt.c
@@ -1127,6 +1127,39 @@ static int renoir_get_power_profile_mode(struct
smu_context *smu,
return size;
}
+static void renoir_get_ss_power_percent(SmuMetrics_t *metrics,
+ uint32_t *apu_percent, uint32_t
*dgpu_percent)
+{
+ uint32_t apu_boost = 0;
+ uint32_t dgpu_boost = 0;
+ uint16_t apu_limit = 0;
+ uint16_t dgpu_limit = 0;
+ uint16_t apu_power = 0;
+ uint16_t dgpu_power = 0;
+
+ apu_power = metrics->ApuPower;
+ apu_limit = metrics->StapmOriginalLimit;
+ if (apu_power > apu_limit && apu_limit != 0)
+ apu_boost = ((apu_power - apu_limit) * 100) / apu_limit;
+ apu_boost = (apu_boost > 100) ? 100 : apu_boost;
+
+ dgpu_power = metrics->dGpuPower;
+ if (metrics->StapmCurrentLimit > metrics->StapmOriginalLimit)
+ dgpu_limit = metrics->StapmCurrentLimit -
metrics->StapmOriginalLimit;
+ if (dgpu_power > dgpu_limit && dgpu_limit != 0)
+ dgpu_boost = ((dgpu_power - dgpu_limit) * 100) / dgpu_limit;
+ dgpu_boost = (dgpu_boost > 100) ? 100 : dgpu_boost;
+
+ if (dgpu_boost >= apu_boost)
+ apu_boost = 0;
+ else
+ dgpu_boost = 0;
+
+ *apu_percent = apu_boost;
+ *dgpu_percent = dgpu_boost;
+}
+
+
static int renoir_get_smu_metrics_data(struct smu_context *smu,
MetricsMember_t member,
uint32_t *value)
@@ -1135,6 +1168,9 @@ static int renoir_get_smu_metrics_data(struct smu_context
*smu,
SmuMetrics_t *metrics = (SmuMetrics_t *)smu_table->metrics_table;
int ret = 0;
+ uint32_t apu_percent = 0;
+ uint32_t dgpu_percent = 0;
+
mutex_lock(>metrics_lock);
@@ -1183,26 +1219,18 @@ static int renoir_get_smu_metrics_data(struct
smu_context *smu,
*value = metrics->Voltage[1];
break;
case METRICS_SS_APU_SHARE:
- /* return the percentage of APU power with respect to APU's
power limit.
-* percentage is reported, this isn't boost value. Smartshift
power
-* boost/shift is only when the percentage is more than 100.
+ /* return the percentage of APU power boost
+* with respect to APU's power limit.
*/
- if (metrics->StapmOriginalLimit > 0)
- *value = (metrics->ApuPower * 100) /
metrics->StapmOriginalLimit;
- else
- *value = 0;
+ renoir_get_ss_power_percent(metrics, _percent,
_percent);
+ *value = apu_percent;
break;
case METRICS_SS_DGPU_SHARE:
- /* return the percentage of dGPU power with respect to dGPU's
power limit.
-* percentage is reported, this isn't boost value. Smartshift
power
-* boost/shift is only when the percentage is more than 100.
+ /* return the percentage of dGPU power boost
+* with respect to dGPU's power limit.
*/
- if ((metrics->dGpuPower > 0) &&
- (metrics->StapmCurrentLimit > metrics->StapmOriginalLimit))
- *value = (metrics->dGpuPower * 100) /
- (metrics->StapmCurrentLimit -
metrics->StapmOriginalLimit);
- else
- *value = 0;
+ renoir_get_ss_power_percent(metrics, _percent,
_percent);
+ *value = dgpu_percent;
break;
default:
*value = UINT_MAX;
--
2.35.1
[PATCH AUTOSEL 5.15 058/109] drm/amdgpu/ucode: Remove firmware load type check in amdgpu_ucode_free_bo
From: Alice Wong
[ Upstream commit ab0cd4a9ae5b4679b714d8dbfedc0901fecdce9f ]
When psp_hw_init failed, it will set the load_type to AMDGPU_FW_LOAD_DIRECT.
During amdgpu_device_ip_fini, amdgpu_ucode_free_bo checks that load_type is
AMDGPU_FW_LOAD_DIRECT and skips deallocating fw_buf causing memory leak.
Remove load_type check in amdgpu_ucode_free_bo.
Signed-off-by: Alice Wong
Reviewed-by: Alex Deucher
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
index abd8469380e5..0ed0736d515a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
@@ -723,8 +723,7 @@ int amdgpu_ucode_create_bo(struct amdgpu_device *adev)
void amdgpu_ucode_free_bo(struct amdgpu_device *adev)
{
- if (adev->firmware.load_type != AMDGPU_FW_LOAD_DIRECT)
- amdgpu_bo_free_kernel(>firmware.fw_buf,
+ amdgpu_bo_free_kernel(>firmware.fw_buf,
>firmware.fw_buf_mc,
>firmware.fw_buf_ptr);
}
--
2.35.1
[PATCH AUTOSEL 5.15 057/109] drm/amdgpu/psp: move PSP memory alloc from hw_init to sw_init
From: Alex Deucher
[ Upstream commit b95b5391684b39695887afb4a13cccee7820f5d6 ]
Memory allocations should be done in sw_init. hw_init should
just be hardware programming needed to initialize the IP block.
This is how most other IP blocks work. Move the GPU memory
allocations from psp hw_init to psp sw_init and move the memory
free to sw_fini. This also fixes a potential GPU memory leak
if psp hw_init fails.
Reviewed-by: Hawking Zhang
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 95 -
1 file changed, 47 insertions(+), 48 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
index 86e2090bbd6e..57e9932d8a04 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
@@ -314,7 +314,39 @@ static int psp_sw_init(void *handle)
}
}
+ ret = amdgpu_bo_create_kernel(adev, PSP_1_MEG, PSP_1_MEG,
+ amdgpu_sriov_vf(adev) ?
+ AMDGPU_GEM_DOMAIN_VRAM :
AMDGPU_GEM_DOMAIN_GTT,
+ >fw_pri_bo,
+ >fw_pri_mc_addr,
+ >fw_pri_buf);
+ if (ret)
+ return ret;
+
+ ret = amdgpu_bo_create_kernel(adev, PSP_FENCE_BUFFER_SIZE, PAGE_SIZE,
+ AMDGPU_GEM_DOMAIN_VRAM,
+ >fence_buf_bo,
+ >fence_buf_mc_addr,
+ >fence_buf);
+ if (ret)
+ goto failed1;
+
+ ret = amdgpu_bo_create_kernel(adev, PSP_CMD_BUFFER_SIZE, PAGE_SIZE,
+ AMDGPU_GEM_DOMAIN_VRAM,
+ >cmd_buf_bo, >cmd_buf_mc_addr,
+ (void **)>cmd_buf_mem);
+ if (ret)
+ goto failed2;
+
return 0;
+
+failed2:
+ amdgpu_bo_free_kernel(>fw_pri_bo,
+ >fw_pri_mc_addr, >fw_pri_buf);
+failed1:
+ amdgpu_bo_free_kernel(>fence_buf_bo,
+ >fence_buf_mc_addr, >fence_buf);
+ return ret;
}
static int psp_sw_fini(void *handle)
@@ -344,6 +376,13 @@ static int psp_sw_fini(void *handle)
kfree(cmd);
cmd = NULL;
+ amdgpu_bo_free_kernel(>fw_pri_bo,
+ >fw_pri_mc_addr, >fw_pri_buf);
+ amdgpu_bo_free_kernel(>fence_buf_bo,
+ >fence_buf_mc_addr, >fence_buf);
+ amdgpu_bo_free_kernel(>cmd_buf_bo, >cmd_buf_mc_addr,
+ (void **)>cmd_buf_mem);
+
return 0;
}
@@ -2580,51 +2619,18 @@ static int psp_load_fw(struct amdgpu_device *adev)
struct psp_context *psp = >psp;
if (amdgpu_sriov_vf(adev) && amdgpu_in_reset(adev)) {
- psp_ring_stop(psp, PSP_RING_TYPE__KM); /* should not destroy
ring, only stop */
- goto skip_memalloc;
- }
-
- if (amdgpu_sriov_vf(adev)) {
- ret = amdgpu_bo_create_kernel(adev, PSP_1_MEG, PSP_1_MEG,
- AMDGPU_GEM_DOMAIN_VRAM,
- >fw_pri_bo,
- >fw_pri_mc_addr,
- >fw_pri_buf);
+ /* should not destroy ring, only stop */
+ psp_ring_stop(psp, PSP_RING_TYPE__KM);
} else {
- ret = amdgpu_bo_create_kernel(adev, PSP_1_MEG, PSP_1_MEG,
- AMDGPU_GEM_DOMAIN_GTT,
- >fw_pri_bo,
- >fw_pri_mc_addr,
- >fw_pri_buf);
- }
-
- if (ret)
- goto failed;
-
- ret = amdgpu_bo_create_kernel(adev, PSP_FENCE_BUFFER_SIZE, PAGE_SIZE,
- AMDGPU_GEM_DOMAIN_VRAM,
- >fence_buf_bo,
- >fence_buf_mc_addr,
- >fence_buf);
- if (ret)
- goto failed;
-
- ret = amdgpu_bo_create_kernel(adev, PSP_CMD_BUFFER_SIZE, PAGE_SIZE,
- AMDGPU_GEM_DOMAIN_VRAM,
- >cmd_buf_bo, >cmd_buf_mc_addr,
- (void **)>cmd_buf_mem);
- if (ret)
- goto failed;
+ memset(psp->fence_buf, 0, PSP_FENCE_BUFFER_SIZE);
- memset(psp->fence_buf, 0, PSP_FENCE_BUFFER_SIZE);
-
- ret = psp_ring_init(psp, PSP_RING_TYPE__KM);
- if (ret) {
- DRM_ERROR("PSP ring init failed!\n");
- goto failed;
+ ret =
[PATCH AUTOSEL 5.15 050/109] drm: msm: fix error check return value of irq_of_parse_and_map()
From: Lv Ruyi
[ Upstream commit b9e4f1d2b505df8e2439b63e67afaa287c1c43e2 ]
The irq_of_parse_and_map() function returns 0 on failure, and does not
return an negative value.
Reported-by: Zeal Robot
Signed-off-by: Lv Ruyi
Reviewed-by: Dmitry Baryshkov
Patchwork: https://patchwork.freedesktop.org/patch/483175/
Link: https://lore.kernel.org/r/20220424031959.3172406-1-lv.r...@zte.com.cn
Signed-off-by: Dmitry Baryshkov
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
index b3b42672b2d4..a2b276ae9673 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
@@ -598,9 +598,9 @@ struct msm_kms *mdp5_kms_init(struct drm_device *dev)
}
irq = irq_of_parse_and_map(pdev->dev.of_node, 0);
- if (irq < 0) {
- ret = irq;
- DRM_DEV_ERROR(>dev, "failed to get irq: %d\n", ret);
+ if (!irq) {
+ ret = -EINVAL;
+ DRM_DEV_ERROR(>dev, "failed to get irq\n");
goto fail;
}
--
2.35.1
[PATCH AUTOSEL 5.15 047/109] drm/amd/pm: fix the compile warning
From: Evan Quan
[ Upstream commit 555238d92ac32dbad2d77ad2bafc48d17391990c ]
Fix the compile warning below:
drivers/gpu/drm/amd/amdgpu/../pm/legacy-dpm/kv_dpm.c:1641
kv_get_acp_boot_level() warn: always true condition '(table->entries[i]->clk >=
0) => (0-u32max >= 0)'
Reported-by: kernel test robot
CC: Alex Deucher
Signed-off-by: Evan Quan
Reviewed-by: Alex Deucher
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/pm/powerplay/kv_dpm.c | 14 +-
1 file changed, 1 insertion(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/powerplay/kv_dpm.c
b/drivers/gpu/drm/amd/pm/powerplay/kv_dpm.c
index bcae42cef374..6ba4c2ae69a6 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/kv_dpm.c
+++ b/drivers/gpu/drm/amd/pm/powerplay/kv_dpm.c
@@ -1609,19 +1609,7 @@ static int kv_update_samu_dpm(struct amdgpu_device
*adev, bool gate)
static u8 kv_get_acp_boot_level(struct amdgpu_device *adev)
{
- u8 i;
- struct amdgpu_clock_voltage_dependency_table *table =
- >pm.dpm.dyn_state.acp_clock_voltage_dependency_table;
-
- for (i = 0; i < table->count; i++) {
- if (table->entries[i].clk >= 0) /* XXX */
- break;
- }
-
- if (i >= table->count)
- i = table->count - 1;
-
- return i;
+ return 0;
}
static void kv_update_acp_boot_level(struct amdgpu_device *adev)
--
2.35.1
[PATCH AUTOSEL 5.17 004/135] drm/virtio: fix NULL pointer dereference in virtio_gpu_conn_get_modes
From: Liu Zixian
[ Upstream commit 194d250cdc4a40ccbd179afd522a9e9846957402 ]
drm_cvt_mode may return NULL and we should check it.
This bug is found by syzkaller:
FAULT_INJECTION stacktrace:
[ 168.567394] FAULT_INJECTION: forcing a failure.
name failslab, interval 1, probability 0, space 0, times 1
[ 168.567403] CPU: 1 PID: 6425 Comm: syz Kdump: loaded Not tainted
4.19.90-vhulk2201.1.0.h1035.kasan.eulerosv2r10.aarch64 #1
[ 168.567406] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
[ 168.567408] Call trace:
[ 168.567414] dump_backtrace+0x0/0x310
[ 168.567418] show_stack+0x28/0x38
[ 168.567423] dump_stack+0xec/0x15c
[ 168.567427] should_fail+0x3ac/0x3d0
[ 168.567437] __should_failslab+0xb8/0x120
[ 168.567441] should_failslab+0x28/0xc0
[ 168.567445] kmem_cache_alloc_trace+0x50/0x640
[ 168.567454] drm_mode_create+0x40/0x90
[ 168.567458] drm_cvt_mode+0x48/0xc78
[ 168.567477] virtio_gpu_conn_get_modes+0xa8/0x140 [virtio_gpu]
[ 168.567485] drm_helper_probe_single_connector_modes+0x3a4/0xd80
[ 168.567492] drm_mode_getconnector+0x2e0/0xa70
[ 168.567496] drm_ioctl_kernel+0x11c/0x1d8
[ 168.567514] drm_ioctl+0x558/0x6d0
[ 168.567522] do_vfs_ioctl+0x160/0xf30
[ 168.567525] ksys_ioctl+0x98/0xd8
[ 168.567530] __arm64_sys_ioctl+0x50/0xc8
[ 168.567536] el0_svc_common+0xc8/0x320
[ 168.567540] el0_svc_handler+0xf8/0x160
[ 168.567544] el0_svc+0x10/0x218
KASAN stacktrace:
[ 168.567561] BUG: KASAN: null-ptr-deref in
virtio_gpu_conn_get_modes+0xb4/0x140 [virtio_gpu]
[ 168.567565] Read of size 4 at addr 0054 by task syz/6425
[ 168.567566]
[ 168.567571] CPU: 1 PID: 6425 Comm: syz Kdump: loaded Not tainted
4.19.90-vhulk2201.1.0.h1035.kasan.eulerosv2r10.aarch64 #1
[ 168.567573] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
[ 168.567575] Call trace:
[ 168.567578] dump_backtrace+0x0/0x310
[ 168.567582] show_stack+0x28/0x38
[ 168.567586] dump_stack+0xec/0x15c
[ 168.567591] kasan_report+0x244/0x2f0
[ 168.567594] __asan_load4+0x58/0xb0
[ 168.567607] virtio_gpu_conn_get_modes+0xb4/0x140 [virtio_gpu]
[ 168.567612] drm_helper_probe_single_connector_modes+0x3a4/0xd80
[ 168.567617] drm_mode_getconnector+0x2e0/0xa70
[ 168.567621] drm_ioctl_kernel+0x11c/0x1d8
[ 168.567624] drm_ioctl+0x558/0x6d0
[ 168.567628] do_vfs_ioctl+0x160/0xf30
[ 168.567632] ksys_ioctl+0x98/0xd8
[ 168.567636] __arm64_sys_ioctl+0x50/0xc8
[ 168.567641] el0_svc_common+0xc8/0x320
[ 168.567645] el0_svc_handler+0xf8/0x160
[ 168.567649] el0_svc+0x10/0x218
Signed-off-by: Liu Zixian
Link:
http://patchwork.freedesktop.org/patch/msgid/20220322091730.1653-1-liuzixi...@huawei.com
Signed-off-by: Gerd Hoffmann
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/virtio/virtgpu_display.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c
b/drivers/gpu/drm/virtio/virtgpu_display.c
index 5b00310ac4cd..f73352e7b832 100644
--- a/drivers/gpu/drm/virtio/virtgpu_display.c
+++ b/drivers/gpu/drm/virtio/virtgpu_display.c
@@ -179,6 +179,8 @@ static int virtio_gpu_conn_get_modes(struct drm_connector
*connector)
DRM_DEBUG("add mode: %dx%d\n", width, height);
mode = drm_cvt_mode(connector->dev, width, height, 60,
false, false, false);
+ if (!mode)
+ return count;
mode->type |= DRM_MODE_TYPE_PREFERRED;
drm_mode_probed_add(connector, mode);
count++;
--
2.35.1
[PATCH AUTOSEL 5.18 131/159] drm/amdgpu: Move mutex_init(>message_lock) to smu_early_init()
From: Hans de Goede [ Upstream commit 4b9caaa0281972ca5ea4e1cdac2e12b9df1ae00b ] Lockdep complains about the smu->message_lock mutex being used before it is initialized through the following call path: amdgpu_device_init() amdgpu_dpm_mode2_reset() smu_mode2_reset() smu_v12_0_mode2_reset() smu_cmn_send_smc_msg_with_param() Move the mutex_init() call to smu_early_init() to fix the mutex being used before it is initialized. This fixes the following lockdep splat: [3.867331] [ cut here ] [3.867335] fbcon: Taking over console [3.867338] DEBUG_LOCKS_WARN_ON(lock->magic != lock) [3.867340] WARNING: CPU: 14 PID: 491 at kernel/locking/mutex.c:579 __mutex_lock+0x44c/0x830 [3.867349] Modules linked in: amdgpu(+) crct10dif_pclmul drm_ttm_helper crc32_pclmul ttm crc32c_intel ghash_clmulni_intel hid_lg_g15 iommu_v2 sp5100_tco nvme gpu_sched drm_dp_helper nvme_core ccp wmi video hid_logitech_dj ip6_tables ip_tables ipmi_devintf ipmi_msghandler fuse i2c_dev [3.867363] CPU: 14 PID: 491 Comm: systemd-udevd Tainted: G I 5.18.0-rc5+ #33 [3.867366] Hardware name: Micro-Star International Co., Ltd. MS-7C95/B550M PRO-VDH WIFI (MS-7C95), BIOS 2.90 12/23/2021 [3.867369] RIP: 0010:__mutex_lock+0x44c/0x830 [3.867372] Code: ff 85 c0 0f 84 33 fc ff ff 8b 0d b7 50 25 01 85 c9 0f 85 25 fc ff ff 48 c7 c6 fb 41 82 99 48 c7 c7 6b 63 80 99 e8 88 2a f8 ff <0f> 0b e9 0b fc ff ff f6 83 b9 0c 00 00 01 0f 85 64 ff ff ff 4c 89 [3.867377] RSP: 0018:aef8c0fc79f0 EFLAGS: 00010286 [3.867380] RAX: 0028 RBX: RCX: 0027 [3.867382] RDX: 9ccc0dda0928 RSI: 0001 RDI: 9ccc0dda0920 [3.867384] RBP: aef8c0fc7a80 R08: R09: aef8c0fc7820 [3.867386] R10: 0003 R11: 9ccc2a2fffe8 R12: 0002 [3.867388] R13: 9cc990808058 R14: R15: 9cc98bfc [3.867390] FS: 7fc4d830f580() GS:9ccc0dd8() knlGS: [3.867394] CS: 0010 DS: ES: CR0: 80050033 [3.867396] CR2: 560a77031410 CR3: 00010f522000 CR4: 00750ee0 [3.867398] PKRU: 5554 [3.867399] Call Trace: [3.867401] [3.867403] ? smu_cmn_send_smc_msg_with_param+0x98/0x240 [amdgpu] [3.867533] ? __mutex_lock+0x90/0x830 [3.867535] ? amdgpu_dpm_mode2_reset+0x37/0x60 [amdgpu] [3.867653] ? smu_cmn_send_smc_msg_with_param+0x98/0x240 [amdgpu] [3.867758] smu_cmn_send_smc_msg_with_param+0x98/0x240 [amdgpu] [3.867857] smu_mode2_reset+0x2b/0x50 [amdgpu] [3.867953] amdgpu_dpm_mode2_reset+0x46/0x60 [amdgpu] [3.868096] amdgpu_device_init.cold+0x1069/0x1e78 [amdgpu] [3.868219] ? _raw_spin_unlock_irqrestore+0x30/0x50 [3.868222] ? pci_conf1_read+0x9b/0xf0 [3.868226] amdgpu_driver_load_kms+0x15/0x110 [amdgpu] [3.868314] amdgpu_pci_probe+0x1a9/0x3c0 [amdgpu] [3.868398] local_pci_probe+0x41/0x80 [3.868401] pci_device_probe+0xab/0x200 [3.868404] really_probe+0x1a1/0x370 [3.868407] __driver_probe_device+0xfc/0x170 [3.868410] driver_probe_device+0x1f/0x90 [3.868412] __driver_attach+0xbf/0x1a0 [3.868414] ? __device_attach_driver+0xe0/0xe0 [3.868416] bus_for_each_dev+0x65/0x90 [3.868419] bus_add_driver+0x151/0x1f0 [3.868421] driver_register+0x89/0xd0 [3.868423] ? 0xc0bd4000 [3.868425] do_one_initcall+0x5d/0x300 [3.868428] ? do_init_module+0x22/0x240 [3.868431] ? rcu_read_lock_sched_held+0x3c/0x70 [3.868434] ? trace_kmalloc+0x30/0xe0 [3.868437] ? kmem_cache_alloc_trace+0x1e6/0x3a0 [3.868440] do_init_module+0x4a/0x240 [3.868442] __do_sys_finit_module+0x93/0xf0 [3.868446] do_syscall_64+0x5b/0x80 [3.868449] ? rcu_read_lock_sched_held+0x3c/0x70 [3.868451] ? lockdep_hardirqs_on_prepare+0xd9/0x180 [3.868454] ? do_syscall_64+0x67/0x80 [3.868456] ? do_syscall_64+0x67/0x80 [3.868458] ? do_syscall_64+0x67/0x80 [3.868460] ? do_syscall_64+0x67/0x80 [3.868462] entry_SYSCALL_64_after_hwframe+0x44/0xae [3.868465] RIP: 0033:0x7fc4d8ec1ced [3.868467] Code: 5d c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d fb 70 0e 00 f7 d8 64 89 01 48 [3.868472] RSP: 002b:7fff687ae6b8 EFLAGS: 0246 ORIG_RAX: 0139 [3.868475] RAX: ffda RBX: 560a76fbca60 RCX: 7fc4d8ec1ced [3.868477] RDX: RSI: 7fc4d902343c RDI: 0011 [3.868479] RBP: 7fc4d902343c R08: R09: 560a76fb59c0 [3.868481] R10: 0011 R11: 0246 R12: 0002 [3.868484] R13: 560a76f8bfd0 R14: R15: 560a76fc2d10 [3.868487] [3.868489] irq event stamp: 120617 [3.868490] hardirqs last
[PATCH AUTOSEL 5.17 109/135] drm/amd/pm: update smartshift powerboost calc for smu13
From: Sathishkumar S
[ Upstream commit cdf4c8ec39872a61a58d62f19b4db80f0f7bc586 ]
smartshift apu and dgpu power boost are reported as percentage
with respect to their power limits. adjust the units of power before
calculating the percentage of boost.
Signed-off-by: Sathishkumar S
Reviewed-by: Lijo Lazar
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
.../drm/amd/pm/swsmu/smu13/yellow_carp_ppt.c | 62 ++-
1 file changed, 46 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/yellow_carp_ppt.c
b/drivers/gpu/drm/amd/pm/swsmu/smu13/yellow_carp_ppt.c
index 0bc84b709a93..d0715927b07f 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu13/yellow_carp_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/yellow_carp_ppt.c
@@ -296,6 +296,42 @@ static int yellow_carp_mode2_reset(struct smu_context *smu)
return yellow_carp_mode_reset(smu, SMU_RESET_MODE_2);
}
+
+static void yellow_carp_get_ss_power_percent(SmuMetrics_t *metrics,
+ uint32_t *apu_percent, uint32_t
*dgpu_percent)
+{
+ uint32_t apu_boost = 0;
+ uint32_t dgpu_boost = 0;
+ uint16_t apu_limit = 0;
+ uint16_t dgpu_limit = 0;
+ uint16_t apu_power = 0;
+ uint16_t dgpu_power = 0;
+
+ /* APU and dGPU power values are reported in milli Watts
+* and STAPM power limits are in Watts */
+ apu_power = metrics->ApuPower/1000;
+ apu_limit = metrics->StapmOpnLimit;
+ if (apu_power > apu_limit && apu_limit != 0)
+ apu_boost = ((apu_power - apu_limit) * 100) / apu_limit;
+ apu_boost = (apu_boost > 100) ? 100 : apu_boost;
+
+ dgpu_power = metrics->dGpuPower/1000;
+ if (metrics->StapmCurrentLimit > metrics->StapmOpnLimit)
+ dgpu_limit = metrics->StapmCurrentLimit -
metrics->StapmOpnLimit;
+ if (dgpu_power > dgpu_limit && dgpu_limit != 0)
+ dgpu_boost = ((dgpu_power - dgpu_limit) * 100) / dgpu_limit;
+ dgpu_boost = (dgpu_boost > 100) ? 100 : dgpu_boost;
+
+ if (dgpu_boost >= apu_boost)
+ apu_boost = 0;
+ else
+ dgpu_boost = 0;
+
+ *apu_percent = apu_boost;
+ *dgpu_percent = dgpu_boost;
+
+}
+
static int yellow_carp_get_smu_metrics_data(struct smu_context *smu,
MetricsMember_t member,
uint32_t *value)
@@ -304,6 +340,8 @@ static int yellow_carp_get_smu_metrics_data(struct
smu_context *smu,
SmuMetrics_t *metrics = (SmuMetrics_t *)smu_table->metrics_table;
int ret = 0;
+ uint32_t apu_percent = 0;
+ uint32_t dgpu_percent = 0;
mutex_lock(>metrics_lock);
@@ -356,26 +394,18 @@ static int yellow_carp_get_smu_metrics_data(struct
smu_context *smu,
*value = metrics->Voltage[1];
break;
case METRICS_SS_APU_SHARE:
- /* return the percentage of APU power with respect to APU's
power limit.
-* percentage is reported, this isn't boost value. Smartshift
power
-* boost/shift is only when the percentage is more than 100.
+ /* return the percentage of APU power boost
+* with respect to APU's power limit.
*/
- if (metrics->StapmOpnLimit > 0)
- *value = (metrics->ApuPower * 100) /
metrics->StapmOpnLimit;
- else
- *value = 0;
+ yellow_carp_get_ss_power_percent(metrics, _percent,
_percent);
+ *value = apu_percent;
break;
case METRICS_SS_DGPU_SHARE:
- /* return the percentage of dGPU power with respect to dGPU's
power limit.
-* percentage is reported, this isn't boost value. Smartshift
power
-* boost/shift is only when the percentage is more than 100.
+ /* return the percentage of dGPU power boost
+* with respect to dGPU's power limit.
*/
- if ((metrics->dGpuPower > 0) &&
- (metrics->StapmCurrentLimit > metrics->StapmOpnLimit))
- *value = (metrics->dGpuPower * 100) /
- (metrics->StapmCurrentLimit -
metrics->StapmOpnLimit);
- else
- *value = 0;
+ yellow_carp_get_ss_power_percent(metrics, _percent,
_percent);
+ *value = dgpu_percent;
break;
default:
*value = UINT_MAX;
--
2.35.1
[PATCH AUTOSEL 5.17 108/135] drm/amd/pm: update smartshift powerboost calc for smu12
From: Sathishkumar S
[ Upstream commit 138292f1dc00e7e0724f44769f9da39cf2f3bf0b ]
smartshift apu and dgpu power boost are reported as percentage with
respect to their power limits. This value[0-100] reflects the boost
for the respective device.
Signed-off-by: Sathishkumar S
Reviewed-by: Lijo Lazar
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
.../gpu/drm/amd/pm/swsmu/smu12/renoir_ppt.c | 60 ++-
1 file changed, 44 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu12/renoir_ppt.c
b/drivers/gpu/drm/amd/pm/swsmu/smu12/renoir_ppt.c
index 25c4b135f830..5e7c9e6d8125 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu12/renoir_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu12/renoir_ppt.c
@@ -1119,6 +1119,39 @@ static int renoir_get_power_profile_mode(struct
smu_context *smu,
return size;
}
+static void renoir_get_ss_power_percent(SmuMetrics_t *metrics,
+ uint32_t *apu_percent, uint32_t
*dgpu_percent)
+{
+ uint32_t apu_boost = 0;
+ uint32_t dgpu_boost = 0;
+ uint16_t apu_limit = 0;
+ uint16_t dgpu_limit = 0;
+ uint16_t apu_power = 0;
+ uint16_t dgpu_power = 0;
+
+ apu_power = metrics->ApuPower;
+ apu_limit = metrics->StapmOriginalLimit;
+ if (apu_power > apu_limit && apu_limit != 0)
+ apu_boost = ((apu_power - apu_limit) * 100) / apu_limit;
+ apu_boost = (apu_boost > 100) ? 100 : apu_boost;
+
+ dgpu_power = metrics->dGpuPower;
+ if (metrics->StapmCurrentLimit > metrics->StapmOriginalLimit)
+ dgpu_limit = metrics->StapmCurrentLimit -
metrics->StapmOriginalLimit;
+ if (dgpu_power > dgpu_limit && dgpu_limit != 0)
+ dgpu_boost = ((dgpu_power - dgpu_limit) * 100) / dgpu_limit;
+ dgpu_boost = (dgpu_boost > 100) ? 100 : dgpu_boost;
+
+ if (dgpu_boost >= apu_boost)
+ apu_boost = 0;
+ else
+ dgpu_boost = 0;
+
+ *apu_percent = apu_boost;
+ *dgpu_percent = dgpu_boost;
+}
+
+
static int renoir_get_smu_metrics_data(struct smu_context *smu,
MetricsMember_t member,
uint32_t *value)
@@ -1127,6 +1160,9 @@ static int renoir_get_smu_metrics_data(struct smu_context
*smu,
SmuMetrics_t *metrics = (SmuMetrics_t *)smu_table->metrics_table;
int ret = 0;
+ uint32_t apu_percent = 0;
+ uint32_t dgpu_percent = 0;
+
mutex_lock(>metrics_lock);
@@ -1175,26 +1211,18 @@ static int renoir_get_smu_metrics_data(struct
smu_context *smu,
*value = metrics->Voltage[1];
break;
case METRICS_SS_APU_SHARE:
- /* return the percentage of APU power with respect to APU's
power limit.
-* percentage is reported, this isn't boost value. Smartshift
power
-* boost/shift is only when the percentage is more than 100.
+ /* return the percentage of APU power boost
+* with respect to APU's power limit.
*/
- if (metrics->StapmOriginalLimit > 0)
- *value = (metrics->ApuPower * 100) /
metrics->StapmOriginalLimit;
- else
- *value = 0;
+ renoir_get_ss_power_percent(metrics, _percent,
_percent);
+ *value = apu_percent;
break;
case METRICS_SS_DGPU_SHARE:
- /* return the percentage of dGPU power with respect to dGPU's
power limit.
-* percentage is reported, this isn't boost value. Smartshift
power
-* boost/shift is only when the percentage is more than 100.
+ /* return the percentage of dGPU power boost
+* with respect to dGPU's power limit.
*/
- if ((metrics->dGpuPower > 0) &&
- (metrics->StapmCurrentLimit > metrics->StapmOriginalLimit))
- *value = (metrics->dGpuPower * 100) /
- (metrics->StapmCurrentLimit -
metrics->StapmOriginalLimit);
- else
- *value = 0;
+ renoir_get_ss_power_percent(metrics, _percent,
_percent);
+ *value = dgpu_percent;
break;
default:
*value = UINT_MAX;
--
2.35.1
[PATCH AUTOSEL 5.17 072/135] drm/tegra: gem: Do not try to dereference ERR_PTR()
From: Thierry Reding
[ Upstream commit cb7e1abc2c73633e1eefa168ab2dad6e838899c9 ]
When mapping the DMA-BUF attachment fails, map->sgt will be an ERR_PTR-
encoded error code and the cleanup code would try to free that memory,
which obviously would fail.
Zero out that pointer after extracting the error code when this happens
so that kfree() can do the right thing.
Reported-by: kernel test robot
Reported-by: Dan Carpenter
Signed-off-by: Thierry Reding
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/tegra/gem.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c
index fce0e52973c2..9810b3bdd342 100644
--- a/drivers/gpu/drm/tegra/gem.c
+++ b/drivers/gpu/drm/tegra/gem.c
@@ -88,6 +88,7 @@ static struct host1x_bo_mapping *tegra_bo_pin(struct device
*dev, struct host1x_
if (IS_ERR(map->sgt)) {
dma_buf_detach(buf, map->attach);
err = PTR_ERR(map->sgt);
+ map->sgt = NULL;
goto free;
}
--
2.35.1
[PATCH AUTOSEL 5.17 054/135] drm/plane: Move range check for format_count earlier
From: Steven Price
[ Upstream commit 4b674dd69701c2e22e8e7770c1706a69f3b17269 ]
While the check for format_count > 64 in __drm_universal_plane_init()
shouldn't be hit (it's a WARN_ON), in its current position it will then
leak the plane->format_types array and fail to call
drm_mode_object_unregister() leaking the modeset identifier. Move it to
the start of the function to avoid allocating those resources in the
first place.
Signed-off-by: Steven Price
Signed-off-by: Liviu Dudau
Link:
https://lore.kernel.org/dri-devel/20211203102815.38624-1-steven.pr...@arm.com/
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/drm_plane.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 82afb854141b..fd0bf90fb4c2 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -249,6 +249,13 @@ static int __drm_universal_plane_init(struct drm_device
*dev,
if (WARN_ON(config->num_total_plane >= 32))
return -EINVAL;
+ /*
+* First driver to need more than 64 formats needs to fix this. Each
+* format is encoded as a bit and the current code only supports a u64.
+*/
+ if (WARN_ON(format_count > 64))
+ return -EINVAL;
+
WARN_ON(drm_drv_uses_atomic_modeset(dev) &&
(!funcs->atomic_destroy_state ||
!funcs->atomic_duplicate_state));
@@ -270,13 +277,6 @@ static int __drm_universal_plane_init(struct drm_device
*dev,
return -ENOMEM;
}
- /*
-* First driver to need more than 64 formats needs to fix this. Each
-* format is encoded as a bit and the current code only supports a u64.
-*/
- if (WARN_ON(format_count > 64))
- return -EINVAL;
-
if (format_modifiers) {
const uint64_t *temp_modifiers = format_modifiers;
--
2.35.1
[PATCH AUTOSEL 5.17 049/135] drm/amdgpu/sdma: Fix incorrect calculations of the wptr of the doorbells
From: Haohui Mai
[ Upstream commit 7dba6e838e741caadcf27ef717b6dcb561e77f89 ]
This patch fixes the issue where the driver miscomputes the 64-bit
values of the wptr of the SDMA doorbell when initializing the
hardware. SDMA engines v4 and later on have full 64-bit registers for
wptr thus they should be set properly.
Older generation hardwares like CIK / SI have only 16 / 20 / 24bits
for the WPTR, where the calls of lower_32_bits() will be removed in a
following patch.
Reviewed-by: Christian König
Signed-off-by: Haohui Mai
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c | 4 ++--
drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c | 8
drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c | 8
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
b/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
index f0638db57111..66b6b175ae90 100644
--- a/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
@@ -772,8 +772,8 @@ static void sdma_v4_0_ring_set_wptr(struct amdgpu_ring
*ring)
DRM_DEBUG("Using doorbell -- "
"wptr_offs == 0x%08x "
- "lower_32_bits(ring->wptr) << 2 == 0x%08x "
- "upper_32_bits(ring->wptr) << 2 == 0x%08x\n",
+ "lower_32_bits(ring->wptr << 2) == 0x%08x "
+ "upper_32_bits(ring->wptr << 2) == 0x%08x\n",
ring->wptr_offs,
lower_32_bits(ring->wptr << 2),
upper_32_bits(ring->wptr << 2));
diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c
b/drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c
index 81e033549dda..6982735e88ba 100644
--- a/drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c
@@ -400,8 +400,8 @@ static void sdma_v5_0_ring_set_wptr(struct amdgpu_ring
*ring)
if (ring->use_doorbell) {
DRM_DEBUG("Using doorbell -- "
"wptr_offs == 0x%08x "
- "lower_32_bits(ring->wptr) << 2 == 0x%08x "
- "upper_32_bits(ring->wptr) << 2 == 0x%08x\n",
+ "lower_32_bits(ring->wptr << 2) == 0x%08x "
+ "upper_32_bits(ring->wptr << 2) == 0x%08x\n",
ring->wptr_offs,
lower_32_bits(ring->wptr << 2),
upper_32_bits(ring->wptr << 2));
@@ -780,9 +780,9 @@ static int sdma_v5_0_gfx_resume(struct amdgpu_device *adev)
if (!amdgpu_sriov_vf(adev)) { /* only bare-metal use register
write for wptr */
WREG32(sdma_v5_0_get_reg_offset(adev, i,
mmSDMA0_GFX_RB_WPTR),
- lower_32_bits(ring->wptr) << 2);
+ lower_32_bits(ring->wptr << 2));
WREG32(sdma_v5_0_get_reg_offset(adev, i,
mmSDMA0_GFX_RB_WPTR_HI),
- upper_32_bits(ring->wptr) << 2);
+ upper_32_bits(ring->wptr << 2));
}
doorbell = RREG32_SOC15_IP(GC, sdma_v5_0_get_reg_offset(adev,
i, mmSDMA0_GFX_DOORBELL));
diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c
b/drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c
index d3d6d5b045b8..ce3a3d1bdaa8 100644
--- a/drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c
+++ b/drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c
@@ -287,8 +287,8 @@ static void sdma_v5_2_ring_set_wptr(struct amdgpu_ring
*ring)
if (ring->use_doorbell) {
DRM_DEBUG("Using doorbell -- "
"wptr_offs == 0x%08x "
- "lower_32_bits(ring->wptr) << 2 == 0x%08x "
- "upper_32_bits(ring->wptr) << 2 == 0x%08x\n",
+ "lower_32_bits(ring->wptr << 2) == 0x%08x "
+ "upper_32_bits(ring->wptr << 2) == 0x%08x\n",
ring->wptr_offs,
lower_32_bits(ring->wptr << 2),
upper_32_bits(ring->wptr << 2));
@@ -664,8 +664,8 @@ static int sdma_v5_2_gfx_resume(struct amdgpu_device *adev)
WREG32_SOC15_IP(GC, sdma_v5_2_get_reg_offset(adev, i,
mmSDMA0_GFX_MINOR_PTR_UPDATE), 1);
if (!amdgpu_sriov_vf(adev)) { /* only bare-metal use register
write for wptr */
- WREG32(sdma_v5_2_get_reg_offset(adev, i,
mmSDMA0_GFX_RB_WPTR), lower_32_bits(ring->wptr) << 2);
- WREG32(sdma_v5_2_get_reg_offset(adev, i,
mmSDMA0_GFX_RB_WPTR_HI), upper_32_bits(ring->wptr) << 2);
+ WREG32(sdma_v5_2_get_reg_offset(adev, i,
mmSDMA0_GFX_RB_WPTR), lower_32_bits(ring->wptr << 2));
+
[PATCH AUTOSEL 5.17 047/135] drm/sun4i: Add support for D1 TCONs
From: Samuel Holland
[ Upstream commit b9b52d2f4aafa2bd637ace0f24615bdad8e49f01 ]
D1 has a TCON TOP, so its quirks are similar to those for the R40 TCONs.
While there are some register changes, the part of the TCON TV supported
by the driver matches the R40 quirks, so that quirks structure can be
reused. D1 has the first supported TCON LCD with a TCON TOP, so the TCON
LCD needs a new quirks structure.
D1's TCON LCD hardware supports LVDS; in fact it provides dual-link LVDS
from a single TCON. However, it comes with a brand new LVDS PHY. Since
this PHY has not been tested, leave out LVDS driver support for now.
Signed-off-by: Samuel Holland
Reviewed-by: Jernej Skrabec
Signed-off-by: Maxime Ripard
Link:
https://patchwork.freedesktop.org/patch/msgid/20220424162633.12369-14-sam...@sholland.org
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 88db2d2a9336..2ee158aaeb9e 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -1542,6 +1542,12 @@ static const struct sun4i_tcon_quirks
sun9i_a80_tcon_tv_quirks = {
.needs_edp_reset = true,
};
+static const struct sun4i_tcon_quirks sun20i_d1_lcd_quirks = {
+ .has_channel_0 = true,
+ .dclk_min_div = 1,
+ .set_mux= sun8i_r40_tcon_tv_set_mux,
+};
+
/* sun4i_drv uses this list to check if a device node is a TCON */
const struct of_device_id sun4i_tcon_of_table[] = {
{ .compatible = "allwinner,sun4i-a10-tcon", .data = _a10_quirks },
@@ -1559,6 +1565,8 @@ const struct of_device_id sun4i_tcon_of_table[] = {
{ .compatible = "allwinner,sun8i-v3s-tcon", .data = _v3s_quirks },
{ .compatible = "allwinner,sun9i-a80-tcon-lcd", .data =
_a80_tcon_lcd_quirks },
{ .compatible = "allwinner,sun9i-a80-tcon-tv", .data =
_a80_tcon_tv_quirks },
+ { .compatible = "allwinner,sun20i-d1-tcon-lcd", .data =
_d1_lcd_quirks },
+ { .compatible = "allwinner,sun20i-d1-tcon-tv", .data =
_r40_tv_quirks },
{ }
};
MODULE_DEVICE_TABLE(of, sun4i_tcon_of_table);
--
2.35.1
[PATCH AUTOSEL 5.17 035/135] drm/amd/pm: fix double free in si_parse_power_table()
From: Keita Suzuki
[ Upstream commit f3fa2becf2fc25b6ac7cf8d8b1a2e4a86b3b72bd ]
In function si_parse_power_table(), array adev->pm.dpm.ps and its member
is allocated. If the allocation of each member fails, the array itself
is freed and returned with an error code. However, the array is later
freed again in si_dpm_fini() function which is called when the function
returns an error.
This leads to potential double free of the array adev->pm.dpm.ps, as
well as leak of its array members, since the members are not freed in
the allocation function and the array is not nulled when freed.
In addition adev->pm.dpm.num_ps, which keeps track of the allocated
array member, is not updated until the member allocation is
successfully finished, this could also lead to either use after free,
or uninitialized variable access in si_dpm_fini().
Fix this by postponing the free of the array until si_dpm_fini() and
increment adev->pm.dpm.num_ps everytime the array member is allocated.
Signed-off-by: Keita Suzuki
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/pm/powerplay/si_dpm.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/powerplay/si_dpm.c
b/drivers/gpu/drm/amd/pm/powerplay/si_dpm.c
index 81f82aa05ec2..66fc63f1f1c1 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/si_dpm.c
+++ b/drivers/gpu/drm/amd/pm/powerplay/si_dpm.c
@@ -7247,17 +7247,15 @@ static int si_parse_power_table(struct amdgpu_device
*adev)
if (!adev->pm.dpm.ps)
return -ENOMEM;
power_state_offset = (u8 *)state_array->states;
- for (i = 0; i < state_array->ucNumEntries; i++) {
+ for (adev->pm.dpm.num_ps = 0, i = 0; i < state_array->ucNumEntries;
i++) {
u8 *idx;
power_state = (union pplib_power_state *)power_state_offset;
non_clock_array_index = power_state->v2.nonClockInfoIndex;
non_clock_info = (struct _ATOM_PPLIB_NONCLOCK_INFO *)
_clock_info_array->nonClockInfo[non_clock_array_index];
ps = kzalloc(sizeof(struct si_ps), GFP_KERNEL);
- if (ps == NULL) {
- kfree(adev->pm.dpm.ps);
+ if (ps == NULL)
return -ENOMEM;
- }
adev->pm.dpm.ps[i].ps_priv = ps;
si_parse_pplib_non_clock_info(adev, >pm.dpm.ps[i],
non_clock_info,
@@ -7279,8 +7277,8 @@ static int si_parse_power_table(struct amdgpu_device
*adev)
k++;
}
power_state_offset += 2 + power_state->v2.ucNumDPMLevels;
+ adev->pm.dpm.num_ps++;
}
- adev->pm.dpm.num_ps = state_array->ucNumEntries;
/* fill in the vce power states */
for (i = 0; i < adev->pm.dpm.num_of_vce_states; i++) {
--
2.35.1
[PATCH AUTOSEL 5.17 019/135] drm/amd/display: Disabling Z10 on DCN31
From: Saaem Rizvi
[ Upstream commit 5d5af34072c8b11f60960c3bea57ff9de5877791 ]
[WHY]
Z10 is should not be enabled by default on DCN31.
[HOW]
Using DC debug flags to disable Z10 by default on DCN31.
Reviewed-by: Eric Yang
Acked-by: Pavle Kotarac
Signed-off-by: Saaem Rizvi
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/dcn31/dcn31_resource.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_resource.c
b/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_resource.c
index f3933c9f5746..6966b72eefc6 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_resource.c
@@ -1030,6 +1030,7 @@ static const struct dc_debug_options debug_defaults_drv =
{
.afmt = true,
}
},
+ .disable_z10 = true,
.optimize_edp_link_rate = true,
.enable_sw_cntl_psr = true,
.apply_vendor_specific_lttpr_wa = true,
--
2.35.1
[PATCH AUTOSEL 5.17 018/135] drm/komeda: return early if drm_universal_plane_init() fails.
From: Liviu Dudau
[ Upstream commit c8f76c37cc3668ee45e081e76a15f24a352ebbdd ]
If drm_universal_plane_init() fails early we jump to the common cleanup code
that calls komeda_plane_destroy() which in turn could access the uninitalised
drm_plane and crash. Return early if an error is detected without going through
the common code.
Reported-by: Steven Price
Reviewed-by: Steven Price
Signed-off-by: Liviu Dudau
Link:
https://lore.kernel.org/dri-devel/20211203100946.2706922-1-liviu.du...@arm.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/arm/display/komeda/komeda_plane.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
b/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
index d63d83800a8a..d646e3ae1a23 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
@@ -275,8 +275,10 @@ static int komeda_plane_add(struct komeda_kms_dev *kms,
komeda_put_fourcc_list(formats);
- if (err)
- goto cleanup;
+ if (err) {
+ kfree(kplane);
+ return err;
+ }
drm_plane_helper_add(plane, _plane_helper_funcs);
--
2.35.1
[PATCH AUTOSEL 5.17 013/135] fbcon: Consistently protect deferred_takeover with console_lock()
From: Daniel Vetter
[ Upstream commit 43553559121ca90965b572cf8a1d6d0fd618b449 ]
This shouldn't be a problem in practice since until we've actually
taken over the console there's nothing we've registered with the
console/vt subsystem, so the exit/unbind path that check this can't
do the wrong thing. But it's confusing, so fix it by moving it a tad
later.
Acked-by: Sam Ravnborg
Signed-off-by: Daniel Vetter
Cc: Daniel Vetter
Cc: Du Cheng
Cc: Tetsuo Handa
Cc: Claudio Suarez
Cc: Thomas Zimmermann
Link:
https://patchwork.freedesktop.org/patch/msgid/20220405210335.3434130-14-daniel.vet...@ffwll.ch
Signed-off-by: Sasha Levin
---
drivers/video/fbdev/core/fbcon.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 2fc1b80a26ad..9a8ae6fa6ecb 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -3265,6 +3265,9 @@ static void fbcon_register_existing_fbs(struct
work_struct *work)
console_lock();
+ deferred_takeover = false;
+ logo_shown = FBCON_LOGO_DONTSHOW;
+
for_each_registered_fb(i)
fbcon_fb_registered(registered_fb[i]);
@@ -3282,8 +3285,6 @@ static int fbcon_output_notifier(struct notifier_block
*nb,
pr_info("fbcon: Taking over console\n");
dummycon_unregister_output_notifier(_output_nb);
- deferred_takeover = false;
- logo_shown = FBCON_LOGO_DONTSHOW;
/* We may get called in atomic context */
schedule_work(_deferred_takeover_work);
--
2.35.1
[PATCH AUTOSEL 5.18 083/159] drm/amdgpu/ucode: Remove firmware load type check in amdgpu_ucode_free_bo
From: Alice Wong
[ Upstream commit ab0cd4a9ae5b4679b714d8dbfedc0901fecdce9f ]
When psp_hw_init failed, it will set the load_type to AMDGPU_FW_LOAD_DIRECT.
During amdgpu_device_ip_fini, amdgpu_ucode_free_bo checks that load_type is
AMDGPU_FW_LOAD_DIRECT and skips deallocating fw_buf causing memory leak.
Remove load_type check in amdgpu_ucode_free_bo.
Signed-off-by: Alice Wong
Reviewed-by: Alex Deucher
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
index ca3350502618..aebafbc327fb 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
@@ -714,8 +714,7 @@ int amdgpu_ucode_create_bo(struct amdgpu_device *adev)
void amdgpu_ucode_free_bo(struct amdgpu_device *adev)
{
- if (adev->firmware.load_type != AMDGPU_FW_LOAD_DIRECT)
- amdgpu_bo_free_kernel(>firmware.fw_buf,
+ amdgpu_bo_free_kernel(>firmware.fw_buf,
>firmware.fw_buf_mc,
>firmware.fw_buf_ptr);
}
--
2.35.1
[PATCH AUTOSEL 5.18 082/159] drm/amdgpu/psp: move PSP memory alloc from hw_init to sw_init
From: Alex Deucher
[ Upstream commit b95b5391684b39695887afb4a13cccee7820f5d6 ]
Memory allocations should be done in sw_init. hw_init should
just be hardware programming needed to initialize the IP block.
This is how most other IP blocks work. Move the GPU memory
allocations from psp hw_init to psp sw_init and move the memory
free to sw_fini. This also fixes a potential GPU memory leak
if psp hw_init fails.
Reviewed-by: Hawking Zhang
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 95 -
1 file changed, 47 insertions(+), 48 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
index a6acec1a6155..21aa556a6bef 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
@@ -357,7 +357,39 @@ static int psp_sw_init(void *handle)
}
}
+ ret = amdgpu_bo_create_kernel(adev, PSP_1_MEG, PSP_1_MEG,
+ amdgpu_sriov_vf(adev) ?
+ AMDGPU_GEM_DOMAIN_VRAM :
AMDGPU_GEM_DOMAIN_GTT,
+ >fw_pri_bo,
+ >fw_pri_mc_addr,
+ >fw_pri_buf);
+ if (ret)
+ return ret;
+
+ ret = amdgpu_bo_create_kernel(adev, PSP_FENCE_BUFFER_SIZE, PAGE_SIZE,
+ AMDGPU_GEM_DOMAIN_VRAM,
+ >fence_buf_bo,
+ >fence_buf_mc_addr,
+ >fence_buf);
+ if (ret)
+ goto failed1;
+
+ ret = amdgpu_bo_create_kernel(adev, PSP_CMD_BUFFER_SIZE, PAGE_SIZE,
+ AMDGPU_GEM_DOMAIN_VRAM,
+ >cmd_buf_bo, >cmd_buf_mc_addr,
+ (void **)>cmd_buf_mem);
+ if (ret)
+ goto failed2;
+
return 0;
+
+failed2:
+ amdgpu_bo_free_kernel(>fw_pri_bo,
+ >fw_pri_mc_addr, >fw_pri_buf);
+failed1:
+ amdgpu_bo_free_kernel(>fence_buf_bo,
+ >fence_buf_mc_addr, >fence_buf);
+ return ret;
}
static int psp_sw_fini(void *handle)
@@ -391,6 +423,13 @@ static int psp_sw_fini(void *handle)
kfree(cmd);
cmd = NULL;
+ amdgpu_bo_free_kernel(>fw_pri_bo,
+ >fw_pri_mc_addr, >fw_pri_buf);
+ amdgpu_bo_free_kernel(>fence_buf_bo,
+ >fence_buf_mc_addr, >fence_buf);
+ amdgpu_bo_free_kernel(>cmd_buf_bo, >cmd_buf_mc_addr,
+ (void **)>cmd_buf_mem);
+
return 0;
}
@@ -2430,51 +2469,18 @@ static int psp_load_fw(struct amdgpu_device *adev)
struct psp_context *psp = >psp;
if (amdgpu_sriov_vf(adev) && amdgpu_in_reset(adev)) {
- psp_ring_stop(psp, PSP_RING_TYPE__KM); /* should not destroy
ring, only stop */
- goto skip_memalloc;
- }
-
- if (amdgpu_sriov_vf(adev)) {
- ret = amdgpu_bo_create_kernel(adev, PSP_1_MEG, PSP_1_MEG,
- AMDGPU_GEM_DOMAIN_VRAM,
- >fw_pri_bo,
- >fw_pri_mc_addr,
- >fw_pri_buf);
+ /* should not destroy ring, only stop */
+ psp_ring_stop(psp, PSP_RING_TYPE__KM);
} else {
- ret = amdgpu_bo_create_kernel(adev, PSP_1_MEG, PSP_1_MEG,
- AMDGPU_GEM_DOMAIN_GTT,
- >fw_pri_bo,
- >fw_pri_mc_addr,
- >fw_pri_buf);
- }
-
- if (ret)
- goto failed;
-
- ret = amdgpu_bo_create_kernel(adev, PSP_FENCE_BUFFER_SIZE, PAGE_SIZE,
- AMDGPU_GEM_DOMAIN_VRAM,
- >fence_buf_bo,
- >fence_buf_mc_addr,
- >fence_buf);
- if (ret)
- goto failed;
-
- ret = amdgpu_bo_create_kernel(adev, PSP_CMD_BUFFER_SIZE, PAGE_SIZE,
- AMDGPU_GEM_DOMAIN_VRAM,
- >cmd_buf_bo, >cmd_buf_mc_addr,
- (void **)>cmd_buf_mem);
- if (ret)
- goto failed;
+ memset(psp->fence_buf, 0, PSP_FENCE_BUFFER_SIZE);
- memset(psp->fence_buf, 0, PSP_FENCE_BUFFER_SIZE);
-
- ret = psp_ring_init(psp, PSP_RING_TYPE__KM);
- if (ret) {
- DRM_ERROR("PSP ring init failed!\n");
- goto failed;
+ ret =
[PATCH AUTOSEL 5.18 087/159] drm/tegra: gem: Do not try to dereference ERR_PTR()
From: Thierry Reding
[ Upstream commit cb7e1abc2c73633e1eefa168ab2dad6e838899c9 ]
When mapping the DMA-BUF attachment fails, map->sgt will be an ERR_PTR-
encoded error code and the cleanup code would try to free that memory,
which obviously would fail.
Zero out that pointer after extracting the error code when this happens
so that kfree() can do the right thing.
Reported-by: kernel test robot
Reported-by: Dan Carpenter
Signed-off-by: Thierry Reding
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/tegra/gem.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c
index 0063403ab5e1..7c7dd84e6db8 100644
--- a/drivers/gpu/drm/tegra/gem.c
+++ b/drivers/gpu/drm/tegra/gem.c
@@ -88,6 +88,7 @@ static struct host1x_bo_mapping *tegra_bo_pin(struct device
*dev, struct host1x_
if (IS_ERR(map->sgt)) {
dma_buf_detach(buf, map->attach);
err = PTR_ERR(map->sgt);
+ map->sgt = NULL;
goto free;
}
--
2.35.1
[PATCH AUTOSEL 5.18 070/159] drm: msm: fix error check return value of irq_of_parse_and_map()
From: Lv Ruyi
[ Upstream commit b9e4f1d2b505df8e2439b63e67afaa287c1c43e2 ]
The irq_of_parse_and_map() function returns 0 on failure, and does not
return an negative value.
Reported-by: Zeal Robot
Signed-off-by: Lv Ruyi
Reviewed-by: Dmitry Baryshkov
Patchwork: https://patchwork.freedesktop.org/patch/483175/
Link: https://lore.kernel.org/r/20220424031959.3172406-1-lv.r...@zte.com.cn
Signed-off-by: Dmitry Baryshkov
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
index 3b92372e7bdf..1d4bbde29320 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
@@ -570,9 +570,9 @@ struct msm_kms *mdp5_kms_init(struct drm_device *dev)
}
irq = irq_of_parse_and_map(pdev->dev.of_node, 0);
- if (irq < 0) {
- ret = irq;
- DRM_DEV_ERROR(>dev, "failed to get irq: %d\n", ret);
+ if (!irq) {
+ ret = -EINVAL;
+ DRM_DEV_ERROR(>dev, "failed to get irq\n");
goto fail;
}
--
2.35.1
[PATCH AUTOSEL 5.18 067/159] drm/amd/pm: fix the compile warning
From: Evan Quan
[ Upstream commit 555238d92ac32dbad2d77ad2bafc48d17391990c ]
Fix the compile warning below:
drivers/gpu/drm/amd/amdgpu/../pm/legacy-dpm/kv_dpm.c:1641
kv_get_acp_boot_level() warn: always true condition '(table->entries[i]->clk >=
0) => (0-u32max >= 0)'
Reported-by: kernel test robot
CC: Alex Deucher
Signed-off-by: Evan Quan
Reviewed-by: Alex Deucher
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/pm/legacy-dpm/kv_dpm.c | 14 +-
1 file changed, 1 insertion(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/legacy-dpm/kv_dpm.c
b/drivers/gpu/drm/amd/pm/legacy-dpm/kv_dpm.c
index 8b23cc9f098a..8fd0782a2b20 100644
--- a/drivers/gpu/drm/amd/pm/legacy-dpm/kv_dpm.c
+++ b/drivers/gpu/drm/amd/pm/legacy-dpm/kv_dpm.c
@@ -1623,19 +1623,7 @@ static int kv_update_samu_dpm(struct amdgpu_device
*adev, bool gate)
static u8 kv_get_acp_boot_level(struct amdgpu_device *adev)
{
- u8 i;
- struct amdgpu_clock_voltage_dependency_table *table =
- >pm.dpm.dyn_state.acp_clock_voltage_dependency_table;
-
- for (i = 0; i < table->count; i++) {
- if (table->entries[i].clk >= 0) /* XXX */
- break;
- }
-
- if (i >= table->count)
- i = table->count - 1;
-
- return i;
+ return 0;
}
static void kv_update_acp_boot_level(struct amdgpu_device *adev)
--
2.35.1
[PATCH AUTOSEL 5.18 066/159] drm/amdkfd: Fix circular lock dependency warning
From: Mukul Joshi
[ Upstream commit b179fc28d521379ba7e0a38eec1a4c722e7ea634 ]
[ 168.544078] ==
[ 168.550309] WARNING: possible circular locking dependency detected
[ 168.556523] 5.16.0-kfd-fkuehlin #148 Tainted: GE
[ 168.562558] --
[ 168.568764] kfdtest/3479 is trying to acquire lock:
[ 168.573672] c0927a70 (_lock){}-{3:3}, at:
kfd_topology_device_by_id+0x16/0x60 [amdgpu] [ 168.583663]
but task is already holding lock:
[ 168.589529] 97d303dee668 (>mmap_lock#2){}-{3:3}, at:
vm_mmap_pgoff+0xa9/0x180 [ 168.597755]
which lock already depends on the new lock.
[ 168.605970]
the existing dependency chain (in reverse order) is:
[ 168.613487]
-> #3 (>mmap_lock#2){}-{3:3}:
[ 168.619700]lock_acquire+0xca/0x2e0
[ 168.623814]down_read+0x3e/0x140
[ 168.627676]do_user_addr_fault+0x40d/0x690
[ 168.632399]exc_page_fault+0x6f/0x270
[ 168.636692]asm_exc_page_fault+0x1e/0x30
[ 168.641249]filldir64+0xc8/0x1e0
[ 168.645115]call_filldir+0x7c/0x110
[ 168.649238]ext4_readdir+0x58e/0x940
[ 168.653442]iterate_dir+0x16a/0x1b0
[ 168.657558]__x64_sys_getdents64+0x83/0x140
[ 168.662375]do_syscall_64+0x35/0x80
[ 168.666492]entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 168.672095]
-> #2 (>i_mutex_dir_key#6){}-{3:3}:
[ 168.679008]lock_acquire+0xca/0x2e0
[ 168.683122]down_read+0x3e/0x140
[ 168.686982]path_openat+0x5b2/0xa50
[ 168.691095]do_file_open_root+0xfc/0x190
[ 168.695652]file_open_root+0xd8/0x1b0
[ 168.702010]kernel_read_file_from_path_initns+0xc4/0x140
[ 168.709542]_request_firmware+0x2e9/0x5e0
[ 168.715741]request_firmware+0x32/0x50
[ 168.721667]amdgpu_cgs_get_firmware_info+0x370/0xdd0 [amdgpu]
[ 168.730060]smu7_upload_smu_firmware_image+0x53/0x190 [amdgpu]
[ 168.738414]fiji_start_smu+0xcf/0x4e0 [amdgpu]
[ 168.745539]pp_dpm_load_fw+0x21/0x30 [amdgpu]
[ 168.752503]amdgpu_pm_load_smu_firmware+0x4b/0x80 [amdgpu]
[ 168.760698]amdgpu_device_fw_loading+0xb8/0x140 [amdgpu]
[ 168.768412]amdgpu_device_init.cold+0xdf6/0x1716 [amdgpu]
[ 168.776285]amdgpu_driver_load_kms+0x15/0x120 [amdgpu]
[ 168.784034]amdgpu_pci_probe+0x19b/0x3a0 [amdgpu]
[ 168.791161]local_pci_probe+0x40/0x80
[ 168.797027]work_for_cpu_fn+0x10/0x20
[ 168.802839]process_one_work+0x273/0x5b0
[ 168.808903]worker_thread+0x20f/0x3d0
[ 168.814700]kthread+0x176/0x1a0
[ 168.819968]ret_from_fork+0x1f/0x30
[ 168.825563]
-> #1 (>pm.mutex){+.+.}-{3:3}:
[ 168.834721]lock_acquire+0xca/0x2e0
[ 168.840364]__mutex_lock+0xa2/0x930
[ 168.846020]amdgpu_dpm_get_mclk+0x37/0x60 [amdgpu]
[ 168.853257]amdgpu_amdkfd_get_local_mem_info+0xba/0xe0 [amdgpu]
[ 168.861547]kfd_create_vcrat_image_gpu+0x1b1/0xbb0 [amdgpu]
[ 168.869478]kfd_create_crat_image_virtual+0x447/0x510 [amdgpu]
[ 168.877884]kfd_topology_add_device+0x5c8/0x6f0 [amdgpu]
[ 168.885556]kgd2kfd_device_init.cold+0x385/0x4c5 [amdgpu]
[ 168.893347]amdgpu_amdkfd_device_init+0x138/0x180 [amdgpu]
[ 168.901177]amdgpu_device_init.cold+0x141b/0x1716 [amdgpu]
[ 168.909025]amdgpu_driver_load_kms+0x15/0x120 [amdgpu]
[ 168.916458]amdgpu_pci_probe+0x19b/0x3a0 [amdgpu]
[ 168.923442]local_pci_probe+0x40/0x80
[ 168.929249]work_for_cpu_fn+0x10/0x20
[ 168.935008]process_one_work+0x273/0x5b0
[ 168.940944]worker_thread+0x20f/0x3d0
[ 168.946623]kthread+0x176/0x1a0
[ 168.951765]ret_from_fork+0x1f/0x30
[ 168.957277]
-> #0 (_lock){}-{3:3}:
[ 168.965993]check_prev_add+0x8f/0xbf0
[ 168.971613]__lock_acquire+0x1299/0x1ca0
[ 168.977485]lock_acquire+0xca/0x2e0
[ 168.982877]down_read+0x3e/0x140
[ 168.987975]kfd_topology_device_by_id+0x16/0x60 [amdgpu]
[ 168.995583]kfd_device_by_id+0xa/0x20 [amdgpu]
[ 169.002180]kfd_mmap+0x95/0x200 [amdgpu]
[ 169.008293]mmap_region+0x337/0x5a0
[ 169.013679]do_mmap+0x3aa/0x540
[ 169.018678]vm_mmap_pgoff+0xdc/0x180
[ 169.024095]ksys_mmap_pgoff+0x186/0x1f0
[ 169.029734]do_syscall_64+0x35/0x80
[ 169.035005]entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 169.041754]
other info that might help us debug this:
[ 169.053276] Chain exists of:
_lock --> >i_mutex_dir_key#6 -->
>mmap_lock#2
[ 169.068389] Possible unsafe locking scenario:
[ 169.076661]CPU0CPU1
[ 169.082383]
