Re: [PATCH] drm/panfrost: Add PANFROST_BO_NO{READ,WRITE} flags
On Thu, 30 Sep 2021 18:12:11 -0400 Alyssa Rosenzweig wrote: > > > > + /* Executable implies readable */ > > > > + if ((args->flags & PANFROST_BO_NOREAD) && > > > > + !(args->flags & PANFROST_BO_NOEXEC)) > > > > + return -EINVAL; > > > > > > Generally, executable also implies not-writeable. Should we check that? > > > > We were allowing it until now, so doing that would break the backward > > compat, unfortunately. > > Not a problem if you only enforce this starting with the appropriate > UABI version, but... I still don't see how that solves the situation, since old-userspace doesn't know about the new UABI, and there's no version field on the CREATE_BO ioctl() to let the kernel know about the UABI used by this userspace program. I mean, we could add one, or add a new PANFROST_BO_EXTENDED_FLAGS flag to enforce this 'noexec implies nowrite' behavior, but is it really simpler than explicitly passing the NOWRITE flag when NOEXEC is passed? > > > Steve also mentioned that the DDK might use shaders modifying other > > shaders here [1] > > What? I believe it, but what? > > For the case of pilot shaders, that shouldn't require self-modifying > code. As I understand, the DDK binds the push uniform (FAU / RMU) buffer > as global shader memory (SSBO) and uses regular STORE instructions on > it. That requires writability on that BO but that should be fine. Okay.
Re: [PATCH v9, 2/2] soc: mediatek: mmsys: Add mt8192 mmsys routing table
Hi Yongqiang,
This patch already have my reviewed tag but I just noticed a small nit
Missatge de Yongqiang Niu del dia dj., 30
de set. 2021 a les 16:00:
>
> mt8192 has different routing registers than mt8183
>
> Signed-off-by: Yongqiang Niu
> Reviewed-by: Enric Balletbo i Serra
> ---
> drivers/soc/mediatek/mt8192-mmsys.h | 77 +
> drivers/soc/mediatek/mtk-mmsys.c| 11 +
> 2 files changed, 88 insertions(+)
> create mode 100644 drivers/soc/mediatek/mt8192-mmsys.h
>
> diff --git a/drivers/soc/mediatek/mt8192-mmsys.h
> b/drivers/soc/mediatek/mt8192-mmsys.h
> new file mode 100644
> index ..7ea1531ee8af
> --- /dev/null
> +++ b/drivers/soc/mediatek/mt8192-mmsys.h
> @@ -0,0 +1,77 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +
> +#ifndef __SOC_MEDIATEK_MT8192_MMSYS_H
> +#define __SOC_MEDIATEK_MT8192_MMSYS_H
> +
> +#define MT8192_MMSYS_OVL_MOUT_EN 0xf04
> +#define MT8192_DISP_OVL1_2L_MOUT_EN0xf08
> +#define MT8192_DISP_OVL0_2L_MOUT_EN0xf18
> +#define MT8192_DISP_OVL0_MOUT_EN 0xf1c
> +#define MT8192_DISP_RDMA0_SEL_IN 0xf2c
> +#define MT8192_DISP_RDMA0_SOUT_SEL 0xf30
> +#define MT8192_DISP_CCORR0_SOUT_SEL0xf34
> +#define MT8192_DISP_AAL0_SEL_IN0xf38
> +#define MT8192_DISP_DITHER0_MOUT_EN0xf3c
> +#define MT8192_DISP_DSI0_SEL_IN0xf40
> +#define MT8192_DISP_OVL2_2L_MOUT_EN0xf4c
> +
> +#define MT8192_DISP_OVL0_GO_BLEND BIT(0)
> +#define MT8192_DITHER0_MOUT_IN_DSI0BIT(0)
> +#define MT8192_OVL0_MOUT_EN_DISP_RDMA0 BIT(0)
> +#define MT8192_OVL2_2L_MOUT_EN_RDMA4 BIT(0)
> +#define MT8192_DISP_OVL0_GO_BG BIT(1)
> +#define MT8192_DISP_OVL0_2L_GO_BLEND BIT(2)
> +#define MT8192_DISP_OVL0_2L_GO_BG BIT(3)
> +#define MT8192_OVL1_2L_MOUT_EN_RDMA1 BIT(4)
> +#define MT8192_OVL0_MOUT_EN_OVL0_2LBIT(4)
> +#define MT8192_RDMA0_SEL_IN_OVL0_2L0x3
> +#define MT8192_RDMA0_SOUT_COLOR0 0x1
> +#define MT8192_CCORR0_SOUT_AAL00x1
> +#define MT8192_AAL0_SEL_IN_CCORR0 0x1
> +#define MT8192_DSI0_SEL_IN_DITHER0 0x1
> +
> +static const struct mtk_mmsys_routes mmsys_mt8192_routing_table[] = {
> + {
> + DDP_COMPONENT_OVL_2L0, DDP_COMPONENT_RDMA0,
> + MT8192_DISP_OVL0_2L_MOUT_EN, MT8192_OVL0_MOUT_EN_DISP_RDMA0,
> + MT8192_OVL0_MOUT_EN_DISP_RDMA0
> + }, {
> + DDP_COMPONENT_OVL_2L2, DDP_COMPONENT_RDMA4,
> + MT8192_DISP_OVL2_2L_MOUT_EN, MT8192_OVL2_2L_MOUT_EN_RDMA4,
> + MT8192_OVL2_2L_MOUT_EN_RDMA4
> + }, {
> + DDP_COMPONENT_DITHER, DDP_COMPONENT_DSI0,
> + MT8192_DISP_DITHER0_MOUT_EN, MT8192_DITHER0_MOUT_IN_DSI0,
> + MT8192_DITHER0_MOUT_IN_DSI0
> + }, {
> + DDP_COMPONENT_OVL_2L0, DDP_COMPONENT_RDMA0,
> + MT8192_DISP_RDMA0_SEL_IN, MT8192_RDMA0_SEL_IN_OVL0_2L,
> + MT8192_RDMA0_SEL_IN_OVL0_2L
> + }, {
> + DDP_COMPONENT_CCORR, DDP_COMPONENT_AAL0,
> + MT8192_DISP_AAL0_SEL_IN, MT8192_AAL0_SEL_IN_CCORR0,
> + MT8192_AAL0_SEL_IN_CCORR0
> + }, {
> + DDP_COMPONENT_DITHER, DDP_COMPONENT_DSI0,
> + MT8192_DISP_DSI0_SEL_IN, MT8192_DSI0_SEL_IN_DITHER0,
> + MT8192_DSI0_SEL_IN_DITHER0
> + }, {
> + DDP_COMPONENT_RDMA0, DDP_COMPONENT_COLOR0,
> + MT8192_DISP_RDMA0_SOUT_SEL, MT8192_RDMA0_SOUT_COLOR0,
> + MT8192_RDMA0_SOUT_COLOR0
> + }, {
> + DDP_COMPONENT_CCORR, DDP_COMPONENT_AAL0,
> + MT8192_DISP_CCORR0_SOUT_SEL, MT8192_CCORR0_SOUT_AAL0,
> + MT8192_CCORR0_SOUT_AAL0
> + }, {
> + DDP_COMPONENT_OVL0, DDP_COMPONENT_OVL_2L0,
> + MT8192_MMSYS_OVL_MOUT_EN, MT8192_DISP_OVL0_GO_BG,
> + MT8192_DISP_OVL0_GO_BG,
> + }, {
> + DDP_COMPONENT_OVL_2L0, DDP_COMPONENT_RDMA0,
> + MT8192_MMSYS_OVL_MOUT_EN, MT8192_DISP_OVL0_2L_GO_BLEND,
> + MT8192_DISP_OVL0_2L_GO_BLEND,
> + }
> +};
> +
> +#endif /* __SOC_MEDIATEK_MT8192_MMSYS_H */
> diff --git a/drivers/soc/mediatek/mtk-mmsys.c
> b/drivers/soc/mediatek/mtk-mmsys.c
> index a78e88f27b62..6e97d1468183 100644
> --- a/drivers/soc/mediatek/mtk-mmsys.c
> +++ b/drivers/soc/mediatek/mtk-mmsys.c
> @@ -14,6 +14,7 @@
> #include "mt8167-mmsys.h"
> #include "mt8183-mmsys.h"
> #include "mt8365-mmsys.h"
> +#include "mt8192-mmsys.h"
>
> static const struct mtk_mmsys_driver_data mt2701_mmsys_driver_data = {
> .clk_driver = "clk-mt2701-mm",
> @@ -59,6 +60,12 @@ static const s
[Bug 214413] Kernel oops on boot for amdgpu (in si_dpm_set_power_state)
https://bugzilla.kernel.org/show_bug.cgi?id=214413 Marco Piazza (mpia...@gmail.com) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |CODE_FIX -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 214413] Kernel oops on boot for amdgpu (in si_dpm_set_power_state)
https://bugzilla.kernel.org/show_bug.cgi?id=214413 --- Comment #6 from Marco Piazza (mpia...@gmail.com) --- A patch with the bug fix has been included in 5.14.9 release. I've downloaded the new version, compiled and booted fine. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: [PATCH v1 2/4] arm64: dts: qcom: sc7280: add display dt nodes
On 2021-09-30 23:28, Stephen Boyd wrote:
Quoting mkri...@codeaurora.org (2021-09-30 04:56:59)
On 2021-08-19 01:27, Stephen Boyd wrote:
> Quoting Krishna Manikandan (2021-08-18 03:27:02)
>> diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi
>> b/arch/arm64/boot/dts/qcom/sc7280.dtsi
>> index 53a21d0..fd7ff1c 100644
>> --- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
>> +
>> + status = "disabled";
>> +
>> + mdp: mdp@ae01000 {
>
> display-controller@ae01000
Stephen,
In the current driver code, there is a substring comparison for
"mdp"
in device node name as part of probe sequence. If "mdp" is not present
in the node name, it will
return an error resulting in probe failure. Can we continue using
mdp
as nodename instead of display controller?
Can we fix the driver to not look for node names and look for
compatible
strings instead? It took me a minute to find compare_name_mdp() in
drivers/gpu/drm/msm/msm_drv.c to understand what you're talking about.
Perhaps looking for qcom,mdp5 in there will be sufficient instead of
looking at the node name.
Sure Stephen. I will make the necessary changes in msm_drv.c to look for
compatible string instead of node name.
Can I include these two changes (changing mdp--> display controller and
msm_drv.c changes) in a separate series ?
Thanks,
Krishna
Re: [RFC PATCH v2 2/2] RDMA/rxe: Add dma-buf support
2021年9月30日(木) 23:41 Daniel Vetter :
>
> On Wed, Sep 29, 2021 at 01:19:05PM +0900, Shunsuke Mie wrote:
> > Implement a ib device operation ‘reg_user_mr_dmabuf’. Generate a
> > rxe_map from the memory space linked the passed dma-buf.
> >
> > Signed-off-by: Shunsuke Mie
> > ---
> > drivers/infiniband/sw/rxe/rxe_loc.h | 2 +
> > drivers/infiniband/sw/rxe/rxe_mr.c| 118 ++
> > drivers/infiniband/sw/rxe/rxe_verbs.c | 34
> > drivers/infiniband/sw/rxe/rxe_verbs.h | 2 +
> > 4 files changed, 156 insertions(+)
> >
> > diff --git a/drivers/infiniband/sw/rxe/rxe_loc.h
> > b/drivers/infiniband/sw/rxe/rxe_loc.h
> > index 1ca43b859d80..8bc19ea1a376 100644
> > --- a/drivers/infiniband/sw/rxe/rxe_loc.h
> > +++ b/drivers/infiniband/sw/rxe/rxe_loc.h
> > @@ -75,6 +75,8 @@ u8 rxe_get_next_key(u32 last_key);
> > void rxe_mr_init_dma(struct rxe_pd *pd, int access, struct rxe_mr *mr);
> > int rxe_mr_init_user(struct rxe_pd *pd, u64 start, u64 length, u64 iova,
> >int access, struct rxe_mr *mr);
> > +int rxe_mr_dmabuf_init_user(struct rxe_pd *pd, int fd, u64 start, u64
> > length,
> > + u64 iova, int access, struct rxe_mr *mr);
> > int rxe_mr_init_fast(struct rxe_pd *pd, int max_pages, struct rxe_mr *mr);
> > int rxe_mr_copy(struct rxe_mr *mr, u64 iova, void *addr, int length,
> > enum rxe_mr_copy_dir dir);
> > diff --git a/drivers/infiniband/sw/rxe/rxe_mr.c
> > b/drivers/infiniband/sw/rxe/rxe_mr.c
> > index 53271df10e47..af6ef671c3a5 100644
> > --- a/drivers/infiniband/sw/rxe/rxe_mr.c
> > +++ b/drivers/infiniband/sw/rxe/rxe_mr.c
> > @@ -4,6 +4,7 @@
> > * Copyright (c) 2015 System Fabric Works, Inc. All rights reserved.
> > */
> >
> > +#include
> > #include "rxe.h"
> > #include "rxe_loc.h"
> >
> > @@ -245,6 +246,120 @@ int rxe_mr_init_user(struct rxe_pd *pd, u64 start,
> > u64 length, u64 iova,
> > return err;
> > }
> >
> > +static int rxe_map_dmabuf_mr(struct rxe_mr *mr,
> > + struct ib_umem_dmabuf *umem_dmabuf)
> > +{
> > + struct rxe_map_set *set;
> > + struct rxe_phys_buf *buf = NULL;
> > + struct rxe_map **map;
> > + void *vaddr, *vaddr_end;
> > + int num_buf = 0;
> > + int err;
> > + size_t remain;
> > +
> > + mr->dmabuf_map = kzalloc(sizeof &mr->dmabuf_map, GFP_KERNEL);
>
> dmabuf_maps are just tagged pointers (and we could shrink them to actually
> just a tagged pointer if anyone cares about the overhead of the separate
> bool), allocating them seperately is overkill.
I agree with you. However, I think it is needed to unmap by
dma_buf_vunmap(). If there is another simple way to unmap it. It is not
needed I think. What do you think about it?
> > + if (!mr->dmabuf_map) {
> > + err = -ENOMEM;
> > + goto err_out;
> > + }
> > +
> > + err = dma_buf_vmap(umem_dmabuf->dmabuf, mr->dmabuf_map);
> > + if (err)
> > + goto err_free_dmabuf_map;
> > +
> > + set = mr->cur_map_set;
> > + set->page_shift = PAGE_SHIFT;
> > + set->page_mask = PAGE_SIZE - 1;
> > +
> > + map = set->map;
> > + buf = map[0]->buf;
> > +
> > + vaddr = mr->dmabuf_map->vaddr;
>
> dma_buf_map can be an __iomem too, you shouldn't dig around in this, but
> use the dma-buf-map.h helpers instead. On x86 (and I think also on most
> arm) it doesn't matter, but it's kinda not very nice in a pure software
> driver.
>
> If anything is missing in dma-buf-map.h wrappers just add more.
>
> Or alternatively you need to fail the import if you can't handle __iomem.
>
> Aside from these I think the dma-buf side here for cpu access looks
> reasonable now.
> -Daniel
I'll see the dma-buf-map.h and consider the error handling that you suggested.
I appreciate your support.
Thanks a lot,
Shunsuke.
> > + vaddr_end = vaddr + umem_dmabuf->dmabuf->size;
> > + remain = umem_dmabuf->dmabuf->size;
> > +
> > + for (; remain; vaddr += PAGE_SIZE) {
> > + if (num_buf >= RXE_BUF_PER_MAP) {
> > + map++;
> > + buf = map[0]->buf;
> > + num_buf = 0;
> > + }
> > +
> > + buf->addr = (uintptr_t)vaddr;
> > + if (remain >= PAGE_SIZE)
> > + buf->size = PAGE_SIZE;
> > + else
> > + buf->size = remain;
> > + remain -= buf->size;
> > +
> > + num_buf++;
> > + buf++;
> > + }
> > +
> > + return 0;
> > +
> > +err_free_dmabuf_map:
> > + kfree(mr->dmabuf_map);
> > +err_out:
> > + return err;
> > +}
> > +
> > +static void rxe_unmap_dmabuf_mr(struct rxe_mr *mr)
> > +{
> > + struct ib_umem_dmabuf *umem_dmabuf = to_ib_umem_dmabuf(mr->umem);
> > +
> > + dma_buf_vunmap(umem_dmabuf->dmabuf, mr->dmabuf_map);
> > + kfree(mr->dmabuf_map);
> > +}
> > +
> > +int rxe_mr_dmabuf_init_user(struct rxe_pd *pd, int fd, u64 start, u64
> > length,
>
RE: [PATCH] drm/amdgpu: fix some repeated includings
So, it means I need to make another commit?
Zhengkui
From: guozheng...@vivo.com On Behalf Of Christian K?nig
Sent: Thursday, September 30, 2021 7:56 PM
To: Guo Zhengkui ; Simon Ser
Cc: Deucher, Alexander ; Pan, Xinhui
; David Airlie ; Daniel Vetter
; Chen, Guchun ; Zhou, Peng Ju
; Zhang, Bokun ; Gao, Likun
; amd-...@lists.freedesktop.org;
dri-devel@lists.freedesktop.org; linux-ker...@vger.kernel.org; kernel
Subject: Re: [PATCH] drm/amdgpu: fix some repeated includings
Ah, that makes more sense. Then please remove the duplicates in lines 46 and 47
instead since the other ones are more correctly grouped together with their
blocks.
Christian.
Am 30.09.21 um 13:54 schrieb 郭正奎:
Actually the duplicates take place in line 46, 47 and 62, 63.
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
index 291a47f7992a..94fca56583a0 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
@@ -46,34 +46,32 @@
#include "vcn_v2_0.h"
#include "jpeg_v2_0.h"
#include "vcn_v2_5.h"
#include "jpeg_v2_5.h"
#include "smuio_v9_0.h"
#include "gmc_v10_0.h"
#include "gfxhub_v2_0.h"
#include "mmhub_v2_0.h"
#include "nbio_v2_3.h"
#include "nbio_v7_2.h"
#include "hdp_v5_0.h"
#include "nv.h"
#include "navi10_ih.h"
#include "gfx_v10_0.h"
#include "sdma_v5_0.h"
#include "sdma_v5_2.h"
-#include "vcn_v2_0.h"
-#include "jpeg_v2_0.h"
#include "vcn_v3_0.h"
#include "jpeg_v3_0.h"
#include "amdgpu_vkms.h"
#include "mes_v10_1.h"
#include "smuio_v11_0.h"
#include "smuio_v11_0_6.h"
#include "smuio_v13_0.h"
MODULE_FIRMWARE("amdgpu/ip_discovery.bin");
#define mmRCC_CONFIG_MEMSIZE 0xde3
#define mmMM_INDEX 0x0
#define mmMM_INDEX_HI 0x6
#define mmMM_DATA 0x1
static const char *hw_id_names[HW_ID_MAX] = {
Re: [PATCH v2 3/3] Move IS_CONFIG_NONZERO() to kconfig.h
On Fri, Oct 1, 2021 at 12:55 AM Lucas De Marchi
wrote:
>
> On Thu, Sep 30, 2021 at 11:01:36PM +0900, Masahiro Yamada wrote:
> >On Thu, Sep 30, 2021 at 3:34 AM Lucas De Marchi
> > wrote:
> >>
> >> The check for config value doesn't really belong to i915_utils.h - we
> >> are trying to eliminate that utils helper and share them when possible
> >> with other drivers and subsystems.
> >>
> >> Rationale for having such macro is in commit
> >> babaab2f4738 ("drm/i915: Encapsulate kconfig constant values inside
> >> boolean predicates")
> >> whereas later it is improved to not break the build if used with
> >> undefined configs. The caveat is detailed in the documentation: unlike
> >> IS_ENABLED(): it's not preprocessor-only logic so can't be used for
> >> things like `#if IS_CONFIG_NONZERO(...)`
> >>
> >> Signed-off-by: Lucas De Marchi
> >
> >
> >Hypothetical "it would be nice to have ..." is really unneeded.
> >
> > if (context && CONFIG_DRM_I915_FENCE_TIMEOUT > 0)
> > return
> >msecs_to_jiffies_timeout(CONFIG_DRM_I915_FENCE_TIMEOUT);
> >
> >
> >is enough, and much cleaner.
> >
> >
> >
> >This warning is shown only when a constant is used
> >together with '&&'.
> >
> >Most of IS_ACTIVE can go away.
> >
> >Given that, there are not many places where the IS_ACTIVE macro
> >is useful, even in the i915 driver.
> >
> >For a few sources of the warnings,
> >replacing it with != 0 or > 0 is just fine.
>
> humn... maybe. Let me do a conversion in that direction and see what is
> the outcome.
>
> My original intention was to make IS_ENABLED() even uglier to cover the
> int case, but after some tries it seems impossible to do on preprocessor
> context, so I thought maybe it would be ok as a separate one.
>
> >
> >Of course, such an ugly macro is not worth being moved to
>
> if we don't handle the undefined case and only worry about encapsulating
> it inside a boolean predicate, the macro would be very simple. Would
> that be worth having in kconfig.h maybe?
I do not think so.
#define IS_CONFIG_NONZERO(config) ((config) != 0)
seems like a stupid macro.
What is bad about writing the direct code?
if (x && CONFIG_FOO > 0)
>
>
> thanks
> Lucas De Marchi
--
Best Regards
Masahiro Yamada
Re: [PATCH v2 10/12] lib: add support for device public type in test_hmm
On Tuesday, 14 September 2021 2:16:02 AM AEST Alex Sierra wrote:
> Device Public type uses device memory that is coherently accesible by
> the CPU. This could be shown as SP (special purpose) memory range
> at the BIOS-e820 memory enumeration. If no SP memory is supported in
> system, this could be faked by setting CONFIG_EFI_FAKE_MEMMAP.
>
> Currently, test_hmm only supports two different SP ranges of at least
> 256MB size. This could be specified in the kernel parameter variable
> efi_fake_mem. Ex. Two SP ranges of 1GB starting at 0x1 &
> 0x14000 physical address. Ex.
> efi_fake_mem=1G@0x1:0x4,1G@0x14000:0x4
>
> Signed-off-by: Alex Sierra
> ---
> lib/test_hmm.c | 166 +++-
> lib/test_hmm_uapi.h | 10 ++-
> 2 files changed, 113 insertions(+), 63 deletions(-)
>
> diff --git a/lib/test_hmm.c b/lib/test_hmm.c
> index ef27e355738a..e346a48e2509 100644
> --- a/lib/test_hmm.c
> +++ b/lib/test_hmm.c
> @@ -469,6 +469,7 @@ static int dmirror_allocate_chunk(struct dmirror_device
> *mdevice,
> unsigned long pfn_first;
> unsigned long pfn_last;
> void *ptr;
> + int ret = -ENOMEM;
>
> devmem = kzalloc(sizeof(*devmem), GFP_KERNEL);
> if (!devmem)
> @@ -551,7 +552,7 @@ static int dmirror_allocate_chunk(struct dmirror_device
> *mdevice,
> }
> spin_unlock(&mdevice->lock);
>
> - return true;
> + return 0;
>
> err_release:
> mutex_unlock(&mdevice->devmem_lock);
> @@ -560,7 +561,7 @@ static int dmirror_allocate_chunk(struct dmirror_device
> *mdevice,
> err_devmem:
> kfree(devmem);
>
> - return false;
> + return ret;
> }
>
> static struct page *dmirror_devmem_alloc_page(struct dmirror_device *mdevice)
> @@ -569,8 +570,10 @@ static struct page *dmirror_devmem_alloc_page(struct
> dmirror_device *mdevice)
> struct page *rpage;
>
> /*
> - * This is a fake device so we alloc real system memory to store
> - * our device memory.
> + * For ZONE_DEVICE private type, this is a fake device so we alloc real
> + * system memory to store our device memory.
> + * For ZONE_DEVICE public type we use the actual dpage to store the data
> + * and ignore rpage.
>*/
> rpage = alloc_page(GFP_HIGHUSER);
> if (!rpage)
> @@ -603,7 +606,7 @@ static void dmirror_migrate_alloc_and_copy(struct
> migrate_vma *args,
> struct dmirror *dmirror)
> {
> struct dmirror_device *mdevice = dmirror->mdevice;
> - const unsigned long *src = args->src;
> + unsigned long *src = args->src;
> unsigned long *dst = args->dst;
> unsigned long addr;
>
> @@ -621,12 +624,18 @@ static void dmirror_migrate_alloc_and_copy(struct
> migrate_vma *args,
>* unallocated pte_none() or read-only zero page.
>*/
> spage = migrate_pfn_to_page(*src);
> -
> + if (spage && is_zone_device_page(spage)) {
> + pr_debug("page already in device spage pfn: 0x%lx\n",
> + page_to_pfn(spage));
> + *src &= ~MIGRATE_PFN_MIGRATE;
I don't think this is quite correct, callers shouldn't modify the src array. To
mark a page as not migrating callers need to set *dst = 0.
However I think this should be considered a test failure anyway. If we are
migrating from system to device memory we would have set
MIGRATE_VMA_SELECT_SYSTEM meaning no device private pages should be returned.
Therefore I don't think we can reach this unless there is a bug right?
> + continue;
> + }
> dpage = dmirror_devmem_alloc_page(mdevice);
> if (!dpage)
> continue;
>
> - rpage = dpage->zone_device_data;
> + rpage = is_device_private_page(dpage) ? dpage->zone_device_data
> :
> + dpage;
> if (spage)
> copy_highpage(rpage, spage);
> else
> @@ -638,8 +647,10 @@ static void dmirror_migrate_alloc_and_copy(struct
> migrate_vma *args,
>* the simulated device memory and that page holds the pointer
>* to the mirror.
>*/
> + rpage = dpage->zone_device_data;
> rpage->zone_device_data = dmirror;
> -
> + pr_debug("migrating from sys to dev pfn src: 0x%lx pfn dst:
> 0x%lx\n",
> + page_to_pfn(spage), page_to_pfn(dpage));
> *dst = migrate_pfn(page_to_pfn(dpage)) |
> MIGRATE_PFN_LOCKED;
> if ((*src & MIGRATE_PFN_WRITE) ||
> @@ -673,10 +684,13 @@ static int dmirror_migrate_finalize_and_map(struct
> migrate_vma *args,
> continue;
>
> /*
> - * Store the page that holds the data so the page table
> -
[PATCH] drm/i915: Stop using I915_TILING_* in client blit selftest
The I915_TILING_* definitions in the uapi header are intended solely for
tiling modes that are visible to the old de-tiling fence ioctls. Since
modern hardware does not support de-tiling fences, we should not add new
definitions for new tiling types going forward. However we do want the
client blit selftest to eventually cover other new tiling modes (such as
Tile4), so switch it to using its own enum of tiling modes.
Cc: Ville Syrjälä
Cc: Stanislav Lisovskiy
Signed-off-by: Matt Roper
---
.../i915/gem/selftests/i915_gem_client_blt.c | 29 ---
include/uapi/drm/i915_drm.h | 6
2 files changed, 24 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
index ecbcbb86ae1e..8402ed925a69 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
@@ -17,13 +17,20 @@
#include "huge_gem_object.h"
#include "mock_context.h"
+enum client_tiling {
+ CLIENT_TILING_LINEAR,
+ CLIENT_TILING_X,
+ CLIENT_TILING_Y,
+ CLIENT_NUM_TILING_TYPES
+};
+
#define WIDTH 512
#define HEIGHT 32
struct blit_buffer {
struct i915_vma *vma;
u32 start_val;
- u32 tiling;
+ enum client_tiling tiling;
};
struct tiled_blits {
@@ -53,9 +60,9 @@ static int prepare_blit(const struct tiled_blits *t,
*cs++ = MI_LOAD_REGISTER_IMM(1);
*cs++ = i915_mmio_reg_offset(BCS_SWCTRL);
cmd = (BCS_SRC_Y | BCS_DST_Y) << 16;
- if (src->tiling == I915_TILING_Y)
+ if (src->tiling == CLIENT_TILING_Y)
cmd |= BCS_SRC_Y;
- if (dst->tiling == I915_TILING_Y)
+ if (dst->tiling == CLIENT_TILING_Y)
cmd |= BCS_DST_Y;
*cs++ = cmd;
@@ -172,7 +179,7 @@ static int tiled_blits_create_buffers(struct tiled_blits *t,
t->buffers[i].vma = vma;
t->buffers[i].tiling =
- i915_prandom_u32_max_state(I915_TILING_Y + 1, prng);
+ i915_prandom_u32_max_state(CLIENT_TILING_Y + 1, prng);
}
return 0;
@@ -197,17 +204,17 @@ static u64 swizzle_bit(unsigned int bit, u64 offset)
static u64 tiled_offset(const struct intel_gt *gt,
u64 v,
unsigned int stride,
- unsigned int tiling)
+ enum client_tiling tiling)
{
unsigned int swizzle;
u64 x, y;
- if (tiling == I915_TILING_NONE)
+ if (tiling == CLIENT_TILING_LINEAR)
return v;
y = div64_u64_rem(v, stride, &x);
- if (tiling == I915_TILING_X) {
+ if (tiling == CLIENT_TILING_X) {
v = div64_u64_rem(y, 8, &y) * stride * 8;
v += y * 512;
v += div64_u64_rem(x, 512, &x) << 12;
@@ -244,12 +251,12 @@ static u64 tiled_offset(const struct intel_gt *gt,
return v;
}
-static const char *repr_tiling(int tiling)
+static const char *repr_tiling(enum client_tiling tiling)
{
switch (tiling) {
- case I915_TILING_NONE: return "linear";
- case I915_TILING_X: return "X";
- case I915_TILING_Y: return "Y";
+ case CLIENT_TILING_LINEAR: return "linear";
+ case CLIENT_TILING_X: return "X";
+ case CLIENT_TILING_Y: return "Y";
default: return "unknown";
}
}
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index bde5860b3686..00311a63068e 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -1522,6 +1522,12 @@ struct drm_i915_gem_caching {
#define I915_TILING_NONE 0
#define I915_TILING_X 1
#define I915_TILING_Y 2
+/*
+ * Do not add new tiling types here. The I915_TILING_* values are for
+ * de-tiling fence registers that no longer exist on modern platforms.
Although
+ * the hardware may support new types of tiling in general (e.g., Tile4), we
+ * do not need to add them to the uapi that is specific to now-defunct ioctls.
+ */
#define I915_TILING_LAST I915_TILING_Y
#define I915_BIT_6_SWIZZLE_NONE0
--
2.33.0
Re: [PATCH v2 09/12] lib: test_hmm add module param for zone device type
On Friday, 24 September 2021 1:52:47 AM AEST Sierra Guiza, Alejandro (Alex) wrote: > > On 9/21/2021 12:14 AM, Alistair Popple wrote: > > On Tuesday, 21 September 2021 6:05:30 AM AEST Sierra Guiza, Alejandro > > (Alex) wrote: > >> On 9/20/2021 3:53 AM, Alistair Popple wrote: > >>> On Tuesday, 14 September 2021 2:16:01 AM AEST Alex Sierra wrote: > In order to configure device public in test_hmm, two module parameters > should be passed, which correspond to the SP start address of each > device (2) spm_addr_dev0 & spm_addr_dev1. If no parameters are passed, > private device type is configured. > >>> It's a pity that testing this seems to require some amount of special > >>> setup to > >>> test. Is there a way this could be made to work on a more standard setup > >>> similar to how DEVICE_PRIVATE is tested? > >> Hi Alistair > >> We tried to do it as simpler as possible. Unfortunately, there are two main > >> requirements to register dev memory as DEVICE_PUBLIC type. This memory must > >> NOT be accessed by any memory allocator (SLAB, SLOB, SLUB) plus, it has > >> to be > >> CPU coherently accessed. We also want to avoid aliasing the same PFNs for > >> different page types (regular system memory and DEVICE_PUBLIC). So we don't > >> want the reserved memory to be part of the kernel's memory map before we > >> call > >> memremap_pages. A transparent way of doing it, without any special HW, was > >> setting a portion of system memory as SPM (Special purpose memory). And use > >> this as our “device fake” memory. > > Ok, I think it's great that we can test this without special HW but the boot > > time configuration is still a bit annoying. Would it be possible to allocate > > memory fitting the above requirements by hot unplugging it with something > > like > > offline_and_remove_memory()? > > I also don't see why the DEVICE_PRIVATE and DEVICE_PUBLIC testing should be > > mutually exclusive - why can't we test both without reloading the module? > You could do both DEVICE_PRIVATE and DEVICE_PUBLIC tests by running the > test_hmm_sh > script twice, just passing the proper parameters. Even when you booted > with fake EFI SP > regions. If spm_address_dev0/1 parameters are passed, the module gets > configured with > DEVICE_PUBLIC type. Otherwise DEVICE_PRIVATE type is set. Technically > the only > complication in testing DEVICE_PUBLIC is the fake SPM boot parameter. Or you could just have the test specify what sort of memory it wants to use (DEVICE_PRIVATE or DEVICE_GENERIC). That seems preferable to requiring a module reload. A module reload also makes it impossible to test interactions between DEVICE_PRIVATE and DEVICE_GENERIC memory. - Alistair > Alex Sierra > > > > - Alistair > > > >> Regards, > >> Alex Sierra > >> > Signed-off-by: Alex Sierra > --- > v5: > Remove devmem->pagemap.type = MEMORY_DEVICE_PRIVATE at > dmirror_allocate_chunk that was forcing to configure pagemap.type > to MEMORY_DEVICE_PRIVATE > > v6: > Check for null pointers for resource and memremap references > at dmirror_allocate_chunk > > v7: > Due to patch dropped from these patch series "kernel: resource: > lookup_resource as exported symbol", lookup_resource was not longer a > callable function. This was used in public device configuration, to > get start and end addresses, to create pgmap->range struct. This > information is now taken directly from the spm_addr_devX parameters and > the fixed size DEVMEM_CHUNK_SIZE. > --- > lib/test_hmm.c | 66 +++-- > lib/test_hmm_uapi.h | 1 + > 2 files changed, 47 insertions(+), 20 deletions(-) > > diff --git a/lib/test_hmm.c b/lib/test_hmm.c > index 3cd91ca31dd7..ef27e355738a 100644 > --- a/lib/test_hmm.c > +++ b/lib/test_hmm.c > @@ -33,6 +33,16 @@ > #define DEVMEM_CHUNK_SIZE (256 * 1024 * 1024U) > #define DEVMEM_CHUNKS_RESERVE 16 > > +static unsigned long spm_addr_dev0; > +module_param(spm_addr_dev0, long, 0644); > +MODULE_PARM_DESC(spm_addr_dev0, > +"Specify start address for SPM (special purpose memory) > used for device 0. By setting this Generic device type will be used. > Make sure spm_addr_dev1 is set too"); > + > +static unsigned long spm_addr_dev1; > +module_param(spm_addr_dev1, long, 0644); > +MODULE_PARM_DESC(spm_addr_dev1, > +"Specify start address for SPM (special purpose memory) > used for device 1. By setting this Generic device type will be used. > Make sure spm_addr_dev0 is set too"); > + > static const struct dev_pagemap_ops dmirror_devmem_ops; > static const struct mmu_interval_notifier_ops dmirror_min_ops; > static dev_t dmirror_dev; > @@ -450,11 +460,11 @@ static int dmirror_write(stru
[PATCH] drm/i915/gt: move remaining debugfs interfaces into gt
The following interfaces:
i915_wedged
i915_forcewake_user
i915_gem_interrupt
are dependent on gt values. Put them inside gt/ and drop the
"i915_" prefix name. This would be the new structure:
dri/0/gt
|
+-- forcewake_user
|
+-- interrupt_info
|
\-- reset
Signed-off-by: Andi Shyti
Cc: Tvrtko Ursulin
Cc: Chris Wilson
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/gt/intel_gt_debugfs.c| 47 -
.../gpu/drm/i915/gt/intel_gt_irq_debugfs.c| 178 ++
.../gpu/drm/i915/gt/intel_gt_irq_debugfs.h| 15 ++
drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c | 31 +++
drivers/gpu/drm/i915/i915_debugfs.c | 71 ---
6 files changed, 271 insertions(+), 72 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gt/intel_gt_irq_debugfs.c
create mode 100644 drivers/gpu/drm/i915/gt/intel_gt_irq_debugfs.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 5c8e022a7383..770565c38448 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -100,6 +100,7 @@ gt-y += \
gt/intel_gt_debugfs.o \
gt/intel_gt_engines_debugfs.o \
gt/intel_gt_irq.o \
+ gt/intel_gt_irq_debugfs.o \
gt/intel_gt_pm.o \
gt/intel_gt_pm_debugfs.o \
gt/intel_gt_pm_irq.o \
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
b/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
index 03fb4aefbf90..2daff03a705a 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
@@ -8,10 +8,53 @@
#include "i915_drv.h"
#include "intel_gt_debugfs.h"
#include "intel_gt_engines_debugfs.h"
+#include "intel_gt_irq_debugfs.h"
+#include "intel_gt_pm.h"
#include "intel_gt_pm_debugfs.h"
+#include "intel_gt_requests.h"
#include "intel_sseu_debugfs.h"
#include "uc/intel_uc_debugfs.h"
+static int reset_show(void *data, u64 *val)
+{
+ struct intel_gt *gt = data;
+ int ret = intel_gt_terminally_wedged(gt);
+
+ switch (ret) {
+ case -EIO:
+ *val = 1;
+ return 0;
+ case 0:
+ *val = 0;
+ return 0;
+ default:
+ return ret;
+ }
+}
+
+static int reset_store(void *data, u64 val)
+{
+ struct intel_gt *gt = data;
+
+ /* Flush any previous reset before applying for a new one */
+ wait_event(gt->reset.queue,
+ !test_bit(I915_RESET_BACKOFF, >->reset.flags));
+
+ intel_gt_handle_error(gt, val, I915_ERROR_CAPTURE,
+ "Manually reset engine mask to %llx", val);
+ return 0;
+}
+DEFINE_SIMPLE_ATTRIBUTE(reset_fops, reset_show, reset_store, "%llu\n");
+
+static void gt_debugfs_register(struct intel_gt *gt, struct dentry *root)
+{
+ static const struct intel_gt_debugfs_file files[] = {
+ { "reset", &reset_fops, NULL },
+ };
+
+ intel_gt_debugfs_register_files(root, files, ARRAY_SIZE(files), gt);
+}
+
void intel_gt_debugfs_register(struct intel_gt *gt)
{
struct dentry *root;
@@ -23,10 +66,12 @@ void intel_gt_debugfs_register(struct intel_gt *gt)
if (IS_ERR(root))
return;
+ gt_debugfs_register(gt, root);
+
intel_gt_engines_debugfs_register(gt, root);
intel_gt_pm_debugfs_register(gt, root);
+ intel_gt_irq_debugfs_register(gt, root);
intel_sseu_debugfs_register(gt, root);
-
intel_uc_debugfs_register(>->uc, root);
}
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_irq_debugfs.c
b/drivers/gpu/drm/i915/gt/intel_gt_irq_debugfs.c
new file mode 100644
index ..3cf9ae8437e5
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/intel_gt_irq_debugfs.c
@@ -0,0 +1,178 @@
+// SPDX-License-Identifier: MIT
+
+/*
+ * Copyright © 2020 Intel Corporation
+ */
+
+#include "i915_drv.h"
+#include "intel_gt_debugfs.h"
+#include "intel_gt_irq_debugfs.h"
+
+static int interrupt_info_show(struct seq_file *m, void *data)
+{
+ struct intel_gt *gt = m->private;
+ struct drm_i915_private *i915 = gt->i915;
+ struct intel_uncore *uncore = gt->uncore;
+ struct intel_engine_cs *engine;
+ enum intel_engine_id id;
+ intel_wakeref_t wakeref;
+ int i;
+
+ wakeref = intel_runtime_pm_get(uncore->rpm);
+
+ if (IS_CHERRYVIEW(i915)) {
+ seq_printf(m, "Master Interrupt Control:\t%08x\n",
+ intel_uncore_read(uncore, GEN8_MASTER_IRQ));
+
+ for (i = 0; i < 4; i++) {
+ seq_printf(m, "GT Interrupt IMR %d:\t%08x\n",
+ i, intel_uncore_read(uncore,
+ GEN8_GT_IMR(i)));
+ seq_printf(m, "GT Interrupt IIR %d:\t%08x\n",
+ i, intel_uncore_read(uncore,
+ GEN8_GT_IIR(i)));
+ seq_prin
Re: [Intel-gfx] [PATCH 24/27] drm/i915: Multi-BB execbuf
On Fri, Aug 20, 2021 at 03:44:43PM -0700, Matthew Brost wrote:
Did a review offline with John Harrison, adding notes for what we found.
> Allow multiple batch buffers to be submitted in a single execbuf IOCTL
> after a context has been configured with the 'set_parallel' extension.
> The number batches is implicit based on the contexts configuration.
>
> This is implemented with a series of loops. First a loop is used to find
> all the batches, a loop to pin all the HW contexts, a loop to generate
> all the requests, a loop to submit all the requests, a loop to commit
> all the requests, and finally a loop to tie the requests to the VMAs
> they touch.
Clarify these steps a bit, also tieing requests to the VMAs is the 2nd to last
step with commiting requests to be the last.
>
> A composite fence is also created for the also the generated requests to
> return to the user and to stick in dma resv slots.
>
Add a comment saying there should be no change in behavior for existing IOCTLs
expect if throttling because to space in the ring, the wait is done with the VMA
locks being held rather than dropping the locks and putting to the slow path.
> IGT: https://patchwork.freedesktop.org/patch/447008/?series=93071&rev=1
> media UMD: link to come
>
> Signed-off-by: Matthew Brost
> ---
> .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 765 --
> drivers/gpu/drm/i915/gt/intel_context.h | 8 +-
> drivers/gpu/drm/i915/gt/intel_context_types.h | 12 +
> .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 2 +
> drivers/gpu/drm/i915/i915_request.h | 9 +
> drivers/gpu/drm/i915/i915_vma.c | 21 +-
> drivers/gpu/drm/i915/i915_vma.h | 13 +-
> 7 files changed, 573 insertions(+), 257 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index 8290bdadd167..481978974627 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -244,17 +244,23 @@ struct i915_execbuffer {
> struct drm_i915_gem_exec_object2 *exec; /** ioctl execobj[] */
> struct eb_vma *vma;
>
> - struct intel_engine_cs *engine; /** engine to queue the request to */
> + struct intel_gt *gt; /* gt for the execbuf */
> struct intel_context *context; /* logical state for the request */
> struct i915_gem_context *gem_context; /** caller's context */
>
> - struct i915_request *request; /** our request to build */
> - struct eb_vma *batch; /** identity of the batch obj/vma */
Line wrap of these comments.
> + struct i915_request *requests[MAX_ENGINE_INSTANCE + 1]; /** our
> requests to build */
> + struct eb_vma *batches[MAX_ENGINE_INSTANCE + 1]; /** identity of the
> batch obj/vma */
> struct i915_vma *trampoline; /** trampoline used for chaining */
>
> + /** used for excl fence in dma_resv objects when > 1 BB submitted */
> + struct dma_fence *composite_fence;
> +
> /** actual size of execobj[] as we may extend it for the cmdparser */
> unsigned int buffer_count;
>
> + /* number of batches in execbuf IOCTL */
> + unsigned int num_batches;
> +
> /** list of vma not yet bound during reservation phase */
> struct list_head unbound;
>
> @@ -281,7 +287,7 @@ struct i915_execbuffer {
>
> u64 invalid_flags; /** Set of execobj.flags that are invalid */
>
> - u64 batch_len; /** Length of batch within object */
> + u64 batch_len[MAX_ENGINE_INSTANCE + 1]; /** Length of batch within
> object */
> u32 batch_start_offset; /** Location within object of batch */
> u32 batch_flags; /** Flags composed for emit_bb_start() */
> struct intel_gt_buffer_pool_node *batch_pool; /** pool node for batch
> buffer */
> @@ -299,14 +305,13 @@ struct i915_execbuffer {
> };
>
> static int eb_parse(struct i915_execbuffer *eb);
> -static struct i915_request *eb_pin_engine(struct i915_execbuffer *eb,
> - bool throttle);
> +static int eb_pin_engine(struct i915_execbuffer *eb, bool throttle);
> static void eb_unpin_engine(struct i915_execbuffer *eb);
>
> static inline bool eb_use_cmdparser(const struct i915_execbuffer *eb)
> {
> - return intel_engine_requires_cmd_parser(eb->engine) ||
> - (intel_engine_using_cmd_parser(eb->engine) &&
> + return intel_engine_requires_cmd_parser(eb->context->engine) ||
> + (intel_engine_using_cmd_parser(eb->context->engine) &&
>eb->args->batch_len);
> }
>
> @@ -544,11 +549,21 @@ eb_validate_vma(struct i915_execbuffer *eb,
> return 0;
> }
>
> -static void
> +static inline bool
> +is_batch_buffer(struct i915_execbuffer *eb, unsigned int buffer_idx)
> +{
> + return eb->args->flags & I915_EXEC_BATCH_FIRST ?
> + buffer_idx < eb->num_batches :
> + buffer_idx >= eb->args->buffer_count - eb->num_b
Re: [PATCH] drm/panfrost: Add PANFROST_BO_NO{READ,WRITE} flags
> > > + /* Executable implies readable */ > > > + if ((args->flags & PANFROST_BO_NOREAD) && > > > + !(args->flags & PANFROST_BO_NOEXEC)) > > > + return -EINVAL; > > > > Generally, executable also implies not-writeable. Should we check that? > > We were allowing it until now, so doing that would break the backward > compat, unfortunately. Not a problem if you only enforce this starting with the appropriate UABI version, but... > Steve also mentioned that the DDK might use shaders modifying other > shaders here [1] What? I believe it, but what? For the case of pilot shaders, that shouldn't require self-modifying code. As I understand, the DDK binds the push uniform (FAU / RMU) buffer as global shader memory (SSBO) and uses regular STORE instructions on it. That requires writability on that BO but that should be fine.
Re: [PATCH] drm/i915: Use fixed offset for PTEs location
On Sun, Sep 26, 2021 at 10:10:05PM +0200, Michal Wajdeczko wrote:
> We assumed that for all modern GENs the PTEs and register space are
> split in the GTTMMADR BAR, but while it is true, we should rather use
> fixed offset as it is defined in the specification.
>
> Bspec: 4409, 4457, 4604, 11181, 9027, 13246, 13321, 44980
>
> Signed-off-by: Michal Wajdeczko
> Cc: CQ Tang
> Cc: Matt Roper
Matches the descriptions on all the various bspec pages.
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/intel_ggtt.c | 19 +--
> 1 file changed, 17 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
> b/drivers/gpu/drm/i915/gt/intel_ggtt.c
> index ba7c7ed89fa8..f17383e76eb7 100644
> --- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
> +++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
> @@ -813,6 +813,21 @@ static unsigned int chv_get_total_gtt_size(u16 gmch_ctrl)
> return 0;
> }
>
> +static unsigned int gen6_gttmmadr_size(struct drm_i915_private *i915)
> +{
> + /*
> + * GEN6: GTTMMADR size is 4MB and GTTADR starts at 2MB offset
> + * GEN8: GTTMMADR size is 16MB and GTTADR starts at 8MB offset
> + */
> + GEM_BUG_ON(GRAPHICS_VER(i915) < 6);
> + return (GRAPHICS_VER(i915) < 8) ? SZ_4M : SZ_16M;
> +}
> +
> +static unsigned int gen6_gttadr_offset(struct drm_i915_private *i915)
> +{
> + return gen6_gttmmadr_size(i915) / 2;
> +}
> +
> static int ggtt_probe_common(struct i915_ggtt *ggtt, u64 size)
> {
> struct drm_i915_private *i915 = ggtt->vm.i915;
> @@ -821,8 +836,8 @@ static int ggtt_probe_common(struct i915_ggtt *ggtt, u64
> size)
> u32 pte_flags;
> int ret;
>
> - /* For Modern GENs the PTEs and register space are split in the BAR */
> - phys_addr = pci_resource_start(pdev, 0) + pci_resource_len(pdev, 0) / 2;
> + GEM_WARN_ON(pci_resource_len(pdev, 0) != gen6_gttmmadr_size(i915));
> + phys_addr = pci_resource_start(pdev, 0) + gen6_gttadr_offset(i915);
>
> /*
>* On BXT+/ICL+ writes larger than 64 bit to the GTT pagetable range
> --
> 2.25.1
>
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
[Bug 214587] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, signaled seq=5900910, emitted seq=5900912
https://bugzilla.kernel.org/show_bug.cgi?id=214587 --- Comment #1 from Lahfa Samy (s...@lahfa.xyz) --- The computer did unfreeze then after the reset of the GPU but it seems hashcat cannot use the GPU anymore for some reason, I'm not too sure why, but I think I need to reboot my machine. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 214587] New: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, signaled seq=5900910, emitted seq=5900912
https://bugzilla.kernel.org/show_bug.cgi?id=214587 Bug ID: 214587 Summary: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, signaled seq=5900910, emitted seq=5900912 Product: Drivers Version: 2.5 Kernel Version: 5.14.7-arch1-1 Hardware: Intel OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: s...@lahfa.xyz Regression: No Hi, I've just recently hit this issue on ArchLinux kernel 5.14.7-arch1-1, linux-firmware 20210919.d526e04-1 with a Thinkpad T495 AMD Ryzen 7 3700U along a Vega Radeon RX 10 while using hashcat to brute-force hashes, hashcat was using OpenCL in order to use the GPU and then the computer just froze, and a GPU reset happened see the following logs. Logs from dmesg: [87507.678904] [drm] Fence fallback timer expired on ring gfx [87512.691933] [drm] Fence fallback timer expired on ring gfx [87517.572033] [drm] Fence fallback timer expired on ring gfx [87523.012214] [drm] Fence fallback timer expired on ring gfx [87533.129069] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, signaled seq=5900910, emitted seq=5900912 [87533.129518] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process Xorg pid 2937 thread Xorg:cs0 pid 3143 [87533.129957] amdgpu :06:00.0: amdgpu: GPU reset begin! [87533.138994] amdgpu :06:00.0: amdgpu: Guilty job already signaled, skipping HW reset [87533.139056] amdgpu :06:00.0: amdgpu: GPU reset(2) succeeded! -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: [PATCH v6 1/3] pwm: Introduce single-PWM of_xlate function
On 9/29/21 10:05 PM, Bjorn Andersson wrote:
> The existing pxa driver and the upcoming addition of PWM support in the
> TI sn565dsi86 DSI/eDP bridge driver both has a single PWM channel and
> thereby a need for a of_xlate function with the period as its single
> argument.
>
> Introduce a common helper function in the core that can be used as
> of_xlate by such drivers and migrate the pxa driver to use this.
>
> Signed-off-by: Bjorn Andersson
> ---
>
> Changes since v4:
> - None
>
> drivers/pwm/core.c| 26 ++
> drivers/pwm/pwm-pxa.c | 16 +---
> include/linux/pwm.h | 2 ++
> 3 files changed, 29 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
> index 4527f09a5c50..2c6b155002a2 100644
> --- a/drivers/pwm/core.c
> +++ b/drivers/pwm/core.c
> @@ -152,6 +152,32 @@ of_pwm_xlate_with_flags(struct pwm_chip *pc, const
> struct of_phandle_args *args)
> }
> EXPORT_SYMBOL_GPL(of_pwm_xlate_with_flags);
>
> +struct pwm_device *
> +of_pwm_single_xlate(struct pwm_chip *pc, const struct of_phandle_args *args)
> +{
> + struct pwm_device *pwm;
> +
> + if (pc->of_pwm_n_cells < 1)
> + return ERR_PTR(-EINVAL);
> +
> + /* validate that one cell is specified, optionally with flags */
> + if (args->args_count != 1 && args->args_count != 2)
> + return ERR_PTR(-EINVAL);
> +
> + pwm = pwm_request_from_chip(pc, 0, NULL);
> + if (IS_ERR(pwm))
> + return pwm;
> +
> + pwm->args.period = args->args[0];
> + pwm->args.polarity = PWM_POLARITY_NORMAL;
> +
> + if (args->args_count == 2 && args->args[2] & PWM_POLARITY_INVERTED)
> + pwm->args.polarity = PWM_POLARITY_INVERSED;
> +
> + return pwm;
> +}
> +EXPORT_SYMBOL_GPL(of_pwm_single_xlate);
> +
> static void of_pwmchip_add(struct pwm_chip *chip)
> {
> if (!chip->dev || !chip->dev->of_node)
> diff --git a/drivers/pwm/pwm-pxa.c b/drivers/pwm/pwm-pxa.c
> index a9efdcf839ae..238ec88c130b 100644
> --- a/drivers/pwm/pwm-pxa.c
> +++ b/drivers/pwm/pwm-pxa.c
> @@ -148,20 +148,6 @@ static const struct platform_device_id
> *pxa_pwm_get_id_dt(struct device *dev)
> return id ? id->data : NULL;
> }
>
> -static struct pwm_device *
> -pxa_pwm_of_xlate(struct pwm_chip *pc, const struct of_phandle_args *args)
> -{
> - struct pwm_device *pwm;
> -
> - pwm = pwm_request_from_chip(pc, 0, NULL);
> - if (IS_ERR(pwm))
> - return pwm;
> -
> - pwm->args.period = args->args[0];
> -
> - return pwm;
> -}
> -
> static int pwm_probe(struct platform_device *pdev)
> {
> const struct platform_device_id *id = platform_get_device_id(pdev);
> @@ -187,7 +173,7 @@ static int pwm_probe(struct platform_device *pdev)
> pc->chip.npwm = (id->driver_data & HAS_SECONDARY_PWM) ? 2 : 1;
>
> if (IS_ENABLED(CONFIG_OF)) {
> - pc->chip.of_xlate = pxa_pwm_of_xlate;
> + pc->chip.of_xlate = of_pwm_single_xlate;
> pc->chip.of_pwm_n_cells = 1;
> }
>
> diff --git a/include/linux/pwm.h b/include/linux/pwm.h
> index 725c9b784e60..dd51d4931fdc 100644
> --- a/include/linux/pwm.h
> +++ b/include/linux/pwm.h
> @@ -414,6 +414,8 @@ struct pwm_device *pwm_request_from_chip(struct pwm_chip
> *chip,
>
> struct pwm_device *of_pwm_xlate_with_flags(struct pwm_chip *pc,
> const struct of_phandle_args *args);
> +struct pwm_device *of_pwm_single_xlate(struct pwm_chip *pc,
> +const struct of_phandle_args *args);
>
> struct pwm_device *pwm_get(struct device *dev, const char *con_id);
> struct pwm_device *of_pwm_get(struct device *dev, struct device_node *np,
I've tested these v6 all 3 patches on the Lenovo Yoga C630
Tested-by: Steev Klimaszewski
Re: [PATCH v3] drm/dp: Add Additional DP2 Headers
Applied to drm-misc-next. Thanks On 09/28, Harry Wentland wrote: > On 2021-09-27 15:23, Fangzhi Zuo wrote: > > Include FEC, DSC, Link Training related headers. > > > > Change since v2 > > - Align with the spec for DP_DSC_SUPPORT_AND_DSC_DECODER_COUNT > > > > Signed-off-by: Fangzhi Zuo > > Reviewed-by: Harry Wentland > > Harry > > > --- > > This patch is based on top of the other DP2.0 work in > > "drm/dp: add LTTPR DP 2.0 DPCD addresses" > > --- > > include/drm/drm_dp_helper.h | 20 > > 1 file changed, 20 insertions(+) > > > > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h > > index 1d5b3dbb6e56..a1df35aa6e68 100644 > > --- a/include/drm/drm_dp_helper.h > > +++ b/include/drm/drm_dp_helper.h > > @@ -453,6 +453,7 @@ struct drm_panel; > > # define DP_FEC_UNCORR_BLK_ERROR_COUNT_CAP (1 << 1) > > # define DP_FEC_CORR_BLK_ERROR_COUNT_CAP(1 << 2) > > # define DP_FEC_BIT_ERROR_COUNT_CAP(1 << 3) > > +#define DP_FEC_CAPABILITY_10x091 /* 2.0 */ > > > > /* DP-HDMI2.1 PCON DSC ENCODER SUPPORT */ > > #define DP_PCON_DSC_ENCODER_CAP_SIZE0xC/* 0x9E - 0x92 */ > > @@ -537,6 +538,9 @@ struct drm_panel; > > #define DP_DSC_BRANCH_OVERALL_THROUGHPUT_1 0x0a1 > > #define DP_DSC_BRANCH_MAX_LINE_WIDTH0x0a2 > > > > +/* DFP Capability Extension */ > > +#define DP_DFP_CAPABILITY_EXTENSION_SUPPORT0x0a3 /* 2.0 */ > > + > > /* Link Configuration */ > > #defineDP_LINK_BW_SET 0x100 > > # define DP_LINK_RATE_TABLE0x00/* eDP 1.4 */ > > @@ -688,6 +692,7 @@ struct drm_panel; > > > > #define DP_DSC_ENABLE 0x160 /* DP 1.4 */ > > # define DP_DECOMPRESSION_EN(1 << 0) > > +#define DP_DSC_CONFIGURATION 0x161 /* DP > > 2.0 */ > > > > #define DP_PSR_EN_CFG 0x170 /* XXX 1.2? */ > > # define DP_PSR_ENABLE BIT(0) > > @@ -743,6 +748,7 @@ struct drm_panel; > > # define DP_RECEIVE_PORT_0_STATUS (1 << 0) > > # define DP_RECEIVE_PORT_1_STATUS (1 << 1) > > # define DP_STREAM_REGENERATION_STATUS (1 << 2) /* 2.0 */ > > +# define DP_INTRA_HOP_AUX_REPLY_INDICATION (1 << 3) /* 2.0 */ > > > > #define DP_ADJUST_REQUEST_LANE0_1 0x206 > > #define DP_ADJUST_REQUEST_LANE2_3 0x207 > > @@ -865,6 +871,8 @@ struct drm_panel; > > # define DP_PHY_TEST_PATTERN_80BIT_CUSTOM 0x4 > > # define DP_PHY_TEST_PATTERN_CP2520 0x5 > > > > +#define DP_PHY_SQUARE_PATTERN 0x249 > > + > > #define DP_TEST_HBR2_SCRAMBLER_RESET0x24A > > #define DP_TEST_80BIT_CUSTOM_PATTERN_7_00x250 > > #defineDP_TEST_80BIT_CUSTOM_PATTERN_15_8 0x251 > > @@ -1109,6 +1117,18 @@ struct drm_panel; > > #define DP_128B132B_TRAINING_AUX_RD_INTERVAL 0x2216 /* 2.0 */ > > # define DP_128B132B_TRAINING_AUX_RD_INTERVAL_MASK 0x7f > > > > +#define DP_TEST_264BIT_CUSTOM_PATTERN_7_0 0x2230 > > +#define DP_TEST_264BIT_CUSTOM_PATTERN_263_256 0x2250 > > + > > +/* DSC Extended Capability Branch Total DSC Resources */ > > +#define DP_DSC_SUPPORT_AND_DSC_DECODER_COUNT 0x2260 /* 2.0 > > */ > > +# define DP_DSC_DECODER_COUNT_MASK (0b111 << 5) > > +# define DP_DSC_DECODER_COUNT_SHIFT5 > > +#define DP_DSC_MAX_SLICE_COUNT_AND_AGGREGATION_0 0x2270 /* 2.0 */ > > +# define DP_DSC_DECODER_0_MAXIMUM_SLICE_COUNT_MASK (1 << 0) > > +# define DP_DSC_DECODER_0_AGGREGATION_SUPPORT_MASK (0b111 << 1) > > +# define DP_DSC_DECODER_0_AGGREGATION_SUPPORT_SHIFT1 > > + > > /* Protocol Converter Extension */ > > /* HDMI CEC tunneling over AUX DP 1.3 section 5.3.3.3.1 DPCD 1.4+ */ > > #define DP_CEC_TUNNELING_CAPABILITY0x3000 > > > -- Rodrigo Siqueira https://siqueira.tech
Re: [PATCH] drm/amdkfd: match the signatures of the real and stub kgd2kfd_probe()
On Thu, Sep 30, 2021 at 4:35 PM wrote:
>
> From: Tom Rix
>
> When CONFIG_HSA_AMD=n this there is this error
> amdgpu_amdkfd.c:75:56: error: incompatible type for
> argument 2 of ‘kgd2kfd_probe’
>75 | adev->kfd.dev = kgd2kfd_probe((struct kgd_dev *)adev, vf);
>
> amdgpu_amdkfd.h:349:17: note: declared here
> 349 | struct kfd_dev *kgd2kfd_probe(struct kgd_dev *kgd,
> struct pci_dev *pdev,
>
> The signature of the stub kgd2kfd_probe() does not match the real one.
> So change the stub to match.
>
> Fixes: 920f37e6a3fc ("drm/amdkfd: clean up parameters in kgd2kfd_probe")
> Signed-off-by: Tom Rix
Anson fixed this up earlier today. Thanks!
Alex
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
> index 38d883dffc20..69de31754907 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
> @@ -346,8 +346,7 @@ static inline void kgd2kfd_exit(void)
> }
>
> static inline
> -struct kfd_dev *kgd2kfd_probe(struct kgd_dev *kgd, struct pci_dev *pdev,
> - unsigned int asic_type, bool vf)
> +struct kfd_dev *kgd2kfd_probe(struct kgd_dev *kgd, bool vf)
> {
> return NULL;
> }
> --
> 2.26.3
>
[PATCH] drm/amdkfd: match the signatures of the real and stub kgd2kfd_probe()
From: Tom Rix
When CONFIG_HSA_AMD=n this there is this error
amdgpu_amdkfd.c:75:56: error: incompatible type for
argument 2 of ‘kgd2kfd_probe’
75 | adev->kfd.dev = kgd2kfd_probe((struct kgd_dev *)adev, vf);
amdgpu_amdkfd.h:349:17: note: declared here
349 | struct kfd_dev *kgd2kfd_probe(struct kgd_dev *kgd,
struct pci_dev *pdev,
The signature of the stub kgd2kfd_probe() does not match the real one.
So change the stub to match.
Fixes: 920f37e6a3fc ("drm/amdkfd: clean up parameters in kgd2kfd_probe")
Signed-off-by: Tom Rix
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
index 38d883dffc20..69de31754907 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
@@ -346,8 +346,7 @@ static inline void kgd2kfd_exit(void)
}
static inline
-struct kfd_dev *kgd2kfd_probe(struct kgd_dev *kgd, struct pci_dev *pdev,
- unsigned int asic_type, bool vf)
+struct kfd_dev *kgd2kfd_probe(struct kgd_dev *kgd, bool vf)
{
return NULL;
}
--
2.26.3
Re: [PATCH v4 00/24] drm/bridge: Make panel and bridge probe order consistent
Hi, On 30/09/2021 20:49, Amit Pundir wrote: On Thu, 30 Sept 2021 at 04:50, Rob Clark wrote: On Wed, Sep 29, 2021 at 2:51 PM John Stultz wrote: On Wed, Sep 29, 2021 at 2:32 PM John Stultz wrote: On Wed, Sep 29, 2021 at 2:27 PM John Stultz wrote: On Fri, Sep 10, 2021 at 3:12 AM Maxime Ripard wrote: The best practice to avoid those issues is to register its functions only after all its dependencies are live. We also shouldn't wait any longer than we should to play nice with the other components that are waiting for us, so in our case that would mean moving the DSI device registration to the bridge probe. I also had a look at all the DSI hosts, and it seems that exynos, kirin and msm would be affected by this and wouldn't probe anymore after those changes. Exynos and kirin seems to be simple enough for a mechanical change (that still requires to be tested), but the changes in msm seemed to be far more important and I wasn't confortable doing them. Hey Maxime, Sorry for taking so long to get to this, but now that plumbers is over I've had a chance to check it out on kirin Rob Clark pointed me to his branch with some fixups here: https://gitlab.freedesktop.org/robclark/msm/-/commits/for-mripard/bridge-rework But trying to boot hikey with that, I see the following loop indefinitely: [4.632132] adv7511 2-0039: supply avdd not found, using dummy regulator [4.638961] adv7511 2-0039: supply dvdd not found, using dummy regulator [4.645741] adv7511 2-0039: supply pvdd not found, using dummy regulator [4.652483] adv7511 2-0039: supply a2vdd not found, using dummy regulator [4.659342] adv7511 2-0039: supply v3p3 not found, using dummy regulator [4.666086] adv7511 2-0039: supply v1p2 not found, using dummy regulator [4.681898] adv7511 2-0039: failed to find dsi host I just realized Rob's tree is missing the kirin patch. My apologies! I'll retest and let you know. Ok, just retested including the kirin patch and unfortunately I'm still seeing the same thing. :( Will dig a bit and let you know when I find more. Did you have a chance to test it on anything using drm/msm with DSI panels? That would at least confirm that I didn't miss anything in the drm/msm patch to swap the dsi-host vs bridge ordering.. Hi, smoke tested https://gitlab.freedesktop.org/robclark/msm/-/commits/for-mripard/bridge-rework on Pocophone F1 (sdm845 / A630) with v5.15-rc3. I see no obvious regressions in my limited testing so far including video (youtube) playback. Tested on the OnePlus 6 too booting AOSP, works fine. This *fixes* FBDEV_EMULATION (so we can get a working framebuffer console) which was otherwise broken on 5.15. However it spits out some warnings during boot: https://p.calebs.dev/gucysowyna.yaml BR, -R -- Kind Regards, Caleb (they/them)
Re: [PATCH v4 00/24] drm/bridge: Make panel and bridge probe order consistent
On Thu, 30 Sept 2021 at 04:50, Rob Clark wrote: > > On Wed, Sep 29, 2021 at 2:51 PM John Stultz wrote: > > > > On Wed, Sep 29, 2021 at 2:32 PM John Stultz wrote: > > > On Wed, Sep 29, 2021 at 2:27 PM John Stultz > > > wrote: > > > > On Fri, Sep 10, 2021 at 3:12 AM Maxime Ripard wrote: > > > > > The best practice to avoid those issues is to register its functions > > > > > only after > > > > > all its dependencies are live. We also shouldn't wait any longer than > > > > > we should > > > > > to play nice with the other components that are waiting for us, so in > > > > > our case > > > > > that would mean moving the DSI device registration to the bridge > > > > > probe. > > > > > > > > > > I also had a look at all the DSI hosts, and it seems that exynos, > > > > > kirin and msm > > > > > would be affected by this and wouldn't probe anymore after those > > > > > changes. > > > > > Exynos and kirin seems to be simple enough for a mechanical change > > > > > (that still > > > > > requires to be tested), but the changes in msm seemed to be far more > > > > > important > > > > > and I wasn't confortable doing them. > > > > > > > > > > > > Hey Maxime, > > > > Sorry for taking so long to get to this, but now that plumbers is > > > > over I've had a chance to check it out on kirin > > > > > > > > Rob Clark pointed me to his branch with some fixups here: > > > > > > > > https://gitlab.freedesktop.org/robclark/msm/-/commits/for-mripard/bridge-rework > > > > > > > > But trying to boot hikey with that, I see the following loop > > > > indefinitely: > > > > [4.632132] adv7511 2-0039: supply avdd not found, using dummy > > > > regulator > > > > [4.638961] adv7511 2-0039: supply dvdd not found, using dummy > > > > regulator > > > > [4.645741] adv7511 2-0039: supply pvdd not found, using dummy > > > > regulator > > > > [4.652483] adv7511 2-0039: supply a2vdd not found, using dummy > > > > regulator > > > > [4.659342] adv7511 2-0039: supply v3p3 not found, using dummy > > > > regulator > > > > [4.666086] adv7511 2-0039: supply v1p2 not found, using dummy > > > > regulator > > > > [4.681898] adv7511 2-0039: failed to find dsi host > > > > > > I just realized Rob's tree is missing the kirin patch. My apologies! > > > I'll retest and let you know. > > > > Ok, just retested including the kirin patch and unfortunately I'm > > still seeing the same thing. :( > > > > Will dig a bit and let you know when I find more. > > Did you have a chance to test it on anything using drm/msm with DSI > panels? That would at least confirm that I didn't miss anything in > the drm/msm patch to swap the dsi-host vs bridge ordering.. Hi, smoke tested https://gitlab.freedesktop.org/robclark/msm/-/commits/for-mripard/bridge-rework on Pocophone F1 (sdm845 / A630) with v5.15-rc3. I see no obvious regressions in my limited testing so far including video (youtube) playback. > > BR, > -R
Re: [PATCH] drm/panfrost: Add PANFROST_BO_NO{READ,WRITE} flags
On Thu, 30 Sep 2021 20:47:23 +0200 Boris Brezillon wrote: > So we can create GPU mappings without R/W permissions. Particularly > useful to debug corruptions caused by out-of-bound writes. Oops, I forgot to add the PANFROST_BO_PRIVATE flag suggested by Robin here [1]. I'll send a v2. [1]https://oftc.irclog.whitequark.org/panfrost/2021-09-02
Re: [PATCH] drm/panfrost: Add PANFROST_BO_NO{READ,WRITE} flags
On Thu, 30 Sep 2021 15:13:29 -0400 Alyssa Rosenzweig wrote: > > + /* Executable implies readable */ > > + if ((args->flags & PANFROST_BO_NOREAD) && > > + !(args->flags & PANFROST_BO_NOEXEC)) > > + return -EINVAL; > > Generally, executable also implies not-writeable. Should we check that? We were allowing it until now, so doing that would break the backward compat, unfortunately. Steve also mentioned that the DDK might use shaders modifying other shaders here [1], it clearly doesn't happen in panfrost, but I think I'd prefer to keep the existing behavior by default, just to be safe. I'll send a patch setting the RO flag on all executable BOs in mesa/panfrost. [1]https://oftc.irclog.whitequark.org/panfrost/2021-09-02
Re: [PATCH] drm/panfrost: Add PANFROST_BO_NO{READ,WRITE} flags
> + /* Executable implies readable */ > + if ((args->flags & PANFROST_BO_NOREAD) && > + !(args->flags & PANFROST_BO_NOEXEC)) > + return -EINVAL; Generally, executable also implies not-writeable. Should we check that?
[PATCH v5 3/8] drm/panfrost: Add BO access flags to relax dependencies between jobs
Jobs reading from the same BO should not be serialized. Add access
flags so we can relax the implicit dependencies in that case. We force
exclusive access for now to keep the behavior unchanged, but a new
SUBMIT ioctl taking explicit access flags will be introduced.
Signed-off-by: Boris Brezillon
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_drv.c | 10 ++
drivers/gpu/drm/panfrost/panfrost_job.c | 21 ++---
drivers/gpu/drm/panfrost/panfrost_job.h | 1 +
include/uapi/drm/panfrost_drm.h | 3 +++
4 files changed, 32 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
b/drivers/gpu/drm/panfrost/panfrost_drv.c
index b131da3c9399..a386c66f349c 100644
--- a/drivers/gpu/drm/panfrost/panfrost_drv.c
+++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
@@ -165,6 +165,7 @@ panfrost_lookup_bos(struct drm_device *dev,
struct drm_panfrost_submit *args,
struct panfrost_job *job)
{
+ unsigned int i;
int ret;
job->bo_count = args->bo_handle_count;
@@ -172,6 +173,15 @@ panfrost_lookup_bos(struct drm_device *dev,
if (!job->bo_count)
return 0;
+ job->bo_flags = kvmalloc_array(job->bo_count,
+ sizeof(*job->bo_flags),
+ GFP_KERNEL | __GFP_ZERO);
+ if (!job->bo_flags)
+ return -ENOMEM;
+
+ for (i = 0; i < job->bo_count; i++)
+ job->bo_flags[i] = PANFROST_BO_REF_EXCLUSIVE;
+
ret = drm_gem_objects_lookup(file_priv,
(void __user *)(uintptr_t)args->bo_handles,
job->bo_count, &job->bos);
diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c
b/drivers/gpu/drm/panfrost/panfrost_job.c
index ed8d1588b1de..1a9085d8dcf1 100644
--- a/drivers/gpu/drm/panfrost/panfrost_job.c
+++ b/drivers/gpu/drm/panfrost/panfrost_job.c
@@ -245,9 +245,17 @@ static int panfrost_acquire_object_fences(struct
panfrost_job *job)
int i, ret;
for (i = 0; i < job->bo_count; i++) {
+ bool exclusive = job->bo_flags[i] & PANFROST_BO_REF_EXCLUSIVE;
+
+ if (!exclusive) {
+ ret = dma_resv_reserve_shared(job->bos[i]->resv, 1);
+ if (ret)
+ return ret;
+ }
+
/* panfrost always uses write mode in its current uapi */
ret = drm_sched_job_add_implicit_dependencies(&job->base,
job->bos[i],
- true);
+ exclusive);
if (ret)
return ret;
}
@@ -259,8 +267,14 @@ static void panfrost_attach_object_fences(struct
panfrost_job *job)
{
int i;
- for (i = 0; i < job->bo_count; i++)
- dma_resv_add_excl_fence(job->bos[i]->resv,
job->render_done_fence);
+ for (i = 0; i < job->bo_count; i++) {
+ struct dma_resv *robj = job->bos[i]->resv;
+
+ if (job->bo_flags[i] & PANFROST_BO_REF_EXCLUSIVE)
+ dma_resv_add_excl_fence(robj, job->render_done_fence);
+ else
+ dma_resv_add_shared_fence(robj, job->render_done_fence);
+ }
}
int panfrost_job_push(struct panfrost_job *job)
@@ -326,6 +340,7 @@ static void panfrost_job_cleanup(struct kref *ref)
kvfree(job->bos);
}
+ kvfree(job->bo_flags);
kfree(job);
}
diff --git a/drivers/gpu/drm/panfrost/panfrost_job.h
b/drivers/gpu/drm/panfrost/panfrost_job.h
index 77e6d0e6f612..96d755f12cf7 100644
--- a/drivers/gpu/drm/panfrost/panfrost_job.h
+++ b/drivers/gpu/drm/panfrost/panfrost_job.h
@@ -28,6 +28,7 @@ struct panfrost_job {
struct panfrost_gem_mapping **mappings;
struct drm_gem_object **bos;
+ u32 *bo_flags;
u32 bo_count;
/* Fence to be signaled by drm-sched once its done with the job */
diff --git a/include/uapi/drm/panfrost_drm.h b/include/uapi/drm/panfrost_drm.h
index a2de81225125..c8fdf45b1573 100644
--- a/include/uapi/drm/panfrost_drm.h
+++ b/include/uapi/drm/panfrost_drm.h
@@ -226,6 +226,9 @@ struct drm_panfrost_madvise {
__u32 retained; /* out, whether backing store still exists */
};
+/* Exclusive (AKA write) access to the BO */
+#define PANFROST_BO_REF_EXCLUSIVE 0x1
+
#if defined(__cplusplus)
}
#endif
--
2.31.1
[PATCH v5 5/8] drm/panfrost: Add a new ioctl to submit batches
This should help limit the number of ioctls when submitting multiple
jobs. The new ioctl also supports syncobj timelines and BO access flags.
v5:
* Fix typos
* Add BUILD_BUG_ON() checks to make sure SUBMIT_BATCH_VERSION and
descriptor sizes are synced
* Simplify error handling in panfrost_ioctl_batch_submit()
* Don't disable implicit fences on exclusive references
v4:
* Implement panfrost_ioctl_submit() as a wrapper around
panfrost_submit_job()
* Replace stride fields by a version field which is mapped to
a tuple internally
v3:
* Re-use panfrost_get_job_bos() and panfrost_get_job_in_syncs() in the
old submit path
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/panfrost/panfrost_drv.c | 584
drivers/gpu/drm/panfrost/panfrost_job.c | 4 +-
include/uapi/drm/panfrost_drm.h | 92
3 files changed, 492 insertions(+), 188 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
b/drivers/gpu/drm/panfrost/panfrost_drv.c
index f8f430f68090..30dc158d56e6 100644
--- a/drivers/gpu/drm/panfrost/panfrost_drv.c
+++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
@@ -147,193 +147,6 @@ panfrost_get_job_mappings(struct drm_file *file_priv,
struct panfrost_job *job)
return 0;
}
-/**
- * panfrost_lookup_bos() - Sets up job->bo[] with the GEM objects
- * referenced by the job.
- * @dev: DRM device
- * @file_priv: DRM file for this fd
- * @args: IOCTL args
- * @job: job being set up
- *
- * Resolve handles from userspace to BOs and attach them to job.
- *
- * Note that this function doesn't need to unreference the BOs on
- * failure, because that will happen at panfrost_job_cleanup() time.
- */
-static int
-panfrost_lookup_bos(struct drm_device *dev,
- struct drm_file *file_priv,
- struct drm_panfrost_submit *args,
- struct panfrost_job *job)
-{
- unsigned int i;
- int ret;
-
- job->bo_count = args->bo_handle_count;
-
- if (!job->bo_count)
- return 0;
-
- job->bo_flags = kvmalloc_array(job->bo_count,
- sizeof(*job->bo_flags),
- GFP_KERNEL | __GFP_ZERO);
- if (!job->bo_flags)
- return -ENOMEM;
-
- for (i = 0; i < job->bo_count; i++)
- job->bo_flags[i] = PANFROST_BO_REF_EXCLUSIVE;
-
- ret = drm_gem_objects_lookup(file_priv,
-(void __user *)(uintptr_t)args->bo_handles,
-job->bo_count, &job->bos);
- if (ret)
- return ret;
-
- return panfrost_get_job_mappings(file_priv, job);
-}
-
-/**
- * panfrost_copy_in_sync() - Sets up job->deps with the sync objects
- * referenced by the job.
- * @dev: DRM device
- * @file_priv: DRM file for this fd
- * @args: IOCTL args
- * @job: job being set up
- *
- * Resolve syncobjs from userspace to fences and attach them to job.
- *
- * Note that this function doesn't need to unreference the fences on
- * failure, because that will happen at panfrost_job_cleanup() time.
- */
-static int
-panfrost_copy_in_sync(struct drm_device *dev,
- struct drm_file *file_priv,
- struct drm_panfrost_submit *args,
- struct panfrost_job *job)
-{
- u32 *handles;
- int ret = 0;
- int i, in_fence_count;
-
- in_fence_count = args->in_sync_count;
-
- if (!in_fence_count)
- return 0;
-
- handles = kvmalloc_array(in_fence_count, sizeof(u32), GFP_KERNEL);
- if (!handles) {
- ret = -ENOMEM;
- DRM_DEBUG("Failed to allocate incoming syncobj handles\n");
- goto fail;
- }
-
- if (copy_from_user(handles,
- (void __user *)(uintptr_t)args->in_syncs,
- in_fence_count * sizeof(u32))) {
- ret = -EFAULT;
- DRM_DEBUG("Failed to copy in syncobj handles\n");
- goto fail;
- }
-
- for (i = 0; i < in_fence_count; i++) {
- struct dma_fence *fence;
-
- ret = drm_syncobj_find_fence(file_priv, handles[i], 0, 0,
-&fence);
- if (ret)
- goto fail;
-
- ret = drm_sched_job_add_dependency(&job->base, fence);
-
- if (ret)
- goto fail;
- }
-
-fail:
- kvfree(handles);
- return ret;
-}
-
-static int panfrost_ioctl_submit(struct drm_device *dev, void *data,
- struct drm_file *file)
-{
- struct panfrost_device *pfdev = dev->dev_private;
- struct drm_panfrost_submit *args = data;
- struct drm_syncobj *sync_out = NULL;
- struct panfrost_submitqueue *queue;
- struct panfrost_job *job;
- int ret = 0, slot;
-
- if (!args->jc)
- return -EINVAL;
-
- if (args->requirements && args->requir
[PATCH v5 2/8] drm/panfrost: Move the mappings collection out of panfrost_lookup_bos()
So we can re-use it from elsewhere.
Signed-off-by: Boris Brezillon
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_drv.c | 53 ++---
1 file changed, 29 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
b/drivers/gpu/drm/panfrost/panfrost_drv.c
index 40e4a4db3ab1..b131da3c9399 100644
--- a/drivers/gpu/drm/panfrost/panfrost_drv.c
+++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
@@ -118,6 +118,34 @@ static int panfrost_ioctl_create_bo(struct drm_device
*dev, void *data,
return 0;
}
+static int
+panfrost_get_job_mappings(struct drm_file *file_priv, struct panfrost_job *job)
+{
+ struct panfrost_file_priv *priv = file_priv->driver_priv;
+ unsigned int i;
+
+ job->mappings = kvmalloc_array(job->bo_count,
+ sizeof(*job->mappings),
+ GFP_KERNEL | __GFP_ZERO);
+ if (!job->mappings)
+ return -ENOMEM;
+
+ for (i = 0; i < job->bo_count; i++) {
+ struct panfrost_gem_mapping *mapping;
+ struct panfrost_gem_object *bo;
+
+ bo = to_panfrost_bo(job->bos[i]);
+ mapping = panfrost_gem_mapping_get(bo, priv);
+ if (!mapping)
+ return -EINVAL;
+
+ atomic_inc(&bo->gpu_usecount);
+ job->mappings[i] = mapping;
+ }
+
+ return 0;
+}
+
/**
* panfrost_lookup_bos() - Sets up job->bo[] with the GEM objects
* referenced by the job.
@@ -137,9 +165,6 @@ panfrost_lookup_bos(struct drm_device *dev,
struct drm_panfrost_submit *args,
struct panfrost_job *job)
{
- struct panfrost_file_priv *priv = file_priv->driver_priv;
- struct panfrost_gem_object *bo;
- unsigned int i;
int ret;
job->bo_count = args->bo_handle_count;
@@ -153,27 +178,7 @@ panfrost_lookup_bos(struct drm_device *dev,
if (ret)
return ret;
- job->mappings = kvmalloc_array(job->bo_count,
- sizeof(struct panfrost_gem_mapping *),
- GFP_KERNEL | __GFP_ZERO);
- if (!job->mappings)
- return -ENOMEM;
-
- for (i = 0; i < job->bo_count; i++) {
- struct panfrost_gem_mapping *mapping;
-
- bo = to_panfrost_bo(job->bos[i]);
- mapping = panfrost_gem_mapping_get(bo, priv);
- if (!mapping) {
- ret = -EINVAL;
- break;
- }
-
- atomic_inc(&bo->gpu_usecount);
- job->mappings[i] = mapping;
- }
-
- return ret;
+ return panfrost_get_job_mappings(file_priv, job);
}
/**
--
2.31.1
[PATCH v5 7/8] drm/panfrost: Advertise the SYNCOBJ_TIMELINE feature
Now that we have a new SUBMIT ioctl dealing with timelined syncojbs we
can advertise the feature.
Signed-off-by: Boris Brezillon
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
b/drivers/gpu/drm/panfrost/panfrost_drv.c
index 89a0c484310c..9f983b763372 100644
--- a/drivers/gpu/drm/panfrost/panfrost_drv.c
+++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
@@ -817,7 +817,8 @@ DEFINE_DRM_GEM_FOPS(panfrost_drm_driver_fops);
* - 1.3 - adds PANFROST_BO_NO{READ,WRITE} flags
*/
static const struct drm_driver panfrost_drm_driver = {
- .driver_features= DRIVER_RENDER | DRIVER_GEM | DRIVER_SYNCOBJ,
+ .driver_features= DRIVER_RENDER | DRIVER_GEM | DRIVER_SYNCOBJ |
+ DRIVER_SYNCOBJ_TIMELINE,
.open = panfrost_open,
.postclose = panfrost_postclose,
.ioctls = panfrost_drm_driver_ioctls,
--
2.31.1
[PATCH v5 6/8] drm/panfrost: Support synchronization jobs
Sometimes, all the user wants to do is add a synchronization point.
Userspace can already do that by submitting a NULL job, but this implies
submitting something to the GPU when we could simply skip the job and
signal the done fence directly.
v5:
* New patch
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/panfrost/panfrost_drv.c | 9 +++--
drivers/gpu/drm/panfrost/panfrost_job.c | 6 ++
include/uapi/drm/panfrost_drm.h | 7 +++
3 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
b/drivers/gpu/drm/panfrost/panfrost_drv.c
index 30dc158d56e6..89a0c484310c 100644
--- a/drivers/gpu/drm/panfrost/panfrost_drv.c
+++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
@@ -542,7 +542,9 @@ static const struct panfrost_submit_ioctl_version_info
submit_versions[] = {
[1] = { 48, 8, 16 },
};
-#define PANFROST_JD_ALLOWED_REQS PANFROST_JD_REQ_FS
+#define PANFROST_JD_ALLOWED_REQS \
+ (PANFROST_JD_REQ_FS | \
+PANFROST_JD_REQ_DEP_ONLY)
static int
panfrost_submit_job(struct drm_device *dev, struct drm_file *file_priv,
@@ -559,7 +561,10 @@ panfrost_submit_job(struct drm_device *dev, struct
drm_file *file_priv,
if (args->requirements & ~PANFROST_JD_ALLOWED_REQS)
return -EINVAL;
- if (!args->head)
+ /* If this is a dependency-only job, the job chain head should be NULL,
+* otherwise it should be non-NULL.
+*/
+ if ((args->head != 0) != !(args->requirements &
PANFROST_JD_REQ_DEP_ONLY))
return -EINVAL;
bo_stride = submit_versions[version].bo_ref_stride;
diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c
b/drivers/gpu/drm/panfrost/panfrost_job.c
index 0367cee8f6df..6d8706d4a096 100644
--- a/drivers/gpu/drm/panfrost/panfrost_job.c
+++ b/drivers/gpu/drm/panfrost/panfrost_job.c
@@ -192,6 +192,12 @@ static void panfrost_job_hw_submit(struct panfrost_job
*job, int js)
u64 jc_head = job->jc;
int ret;
+ if (job->requirements & PANFROST_JD_REQ_DEP_ONLY) {
+ /* Nothing to execute, signal the fence directly. */
+ dma_fence_signal_locked(job->done_fence);
+ return;
+ }
+
panfrost_devfreq_record_busy(&pfdev->pfdevfreq);
ret = pm_runtime_get_sync(pfdev->dev);
diff --git a/include/uapi/drm/panfrost_drm.h b/include/uapi/drm/panfrost_drm.h
index 5e3f8a344f41..b9df066970f6 100644
--- a/include/uapi/drm/panfrost_drm.h
+++ b/include/uapi/drm/panfrost_drm.h
@@ -46,6 +46,13 @@ extern "C" {
#define DRM_IOCTL_PANFROST_PERFCNT_DUMP
DRM_IOW(DRM_COMMAND_BASE + DRM_PANFROST_PERFCNT_DUMP, struct
drm_panfrost_perfcnt_dump)
#define PANFROST_JD_REQ_FS (1 << 0)
+
+/*
+ * Dependency only job. The job chain head should be set to 0 when this flag
+ * is set.
+ */
+#define PANFROST_JD_REQ_DEP_ONLY (1 << 1)
+
/**
* struct drm_panfrost_submit - ioctl argument for submitting commands to the
3D
* engine.
--
2.31.1
[PATCH v5 4/8] drm/panfrost: Add the ability to create submit queues
Needed to keep VkQueues isolated from each other.
v4:
* Make panfrost_ioctl_create_submitqueue() return the queue ID
instead of a queue object
v3:
* Limit the number of submitqueue per context to 16
* Fix a deadlock
Signed-off-by: Boris Brezillon
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/Makefile | 3 +-
drivers/gpu/drm/panfrost/panfrost_device.h| 2 +-
drivers/gpu/drm/panfrost/panfrost_drv.c | 71 --
drivers/gpu/drm/panfrost/panfrost_job.c | 44 ++
drivers/gpu/drm/panfrost/panfrost_job.h | 7 +-
.../gpu/drm/panfrost/panfrost_submitqueue.c | 132 ++
.../gpu/drm/panfrost/panfrost_submitqueue.h | 26
include/uapi/drm/panfrost_drm.h | 17 +++
8 files changed, 260 insertions(+), 42 deletions(-)
create mode 100644 drivers/gpu/drm/panfrost/panfrost_submitqueue.c
create mode 100644 drivers/gpu/drm/panfrost/panfrost_submitqueue.h
diff --git a/drivers/gpu/drm/panfrost/Makefile
b/drivers/gpu/drm/panfrost/Makefile
index b71935862417..e99192b66ec9 100644
--- a/drivers/gpu/drm/panfrost/Makefile
+++ b/drivers/gpu/drm/panfrost/Makefile
@@ -9,6 +9,7 @@ panfrost-y := \
panfrost_gpu.o \
panfrost_job.o \
panfrost_mmu.o \
- panfrost_perfcnt.o
+ panfrost_perfcnt.o \
+ panfrost_submitqueue.o
obj-$(CONFIG_DRM_PANFROST) += panfrost.o
diff --git a/drivers/gpu/drm/panfrost/panfrost_device.h
b/drivers/gpu/drm/panfrost/panfrost_device.h
index 8b25278f34c8..51c0ba4e50f5 100644
--- a/drivers/gpu/drm/panfrost/panfrost_device.h
+++ b/drivers/gpu/drm/panfrost/panfrost_device.h
@@ -137,7 +137,7 @@ struct panfrost_mmu {
struct panfrost_file_priv {
struct panfrost_device *pfdev;
- struct drm_sched_entity sched_entity[NUM_JOB_SLOTS];
+ struct idr queues;
struct panfrost_mmu *mmu;
};
diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
b/drivers/gpu/drm/panfrost/panfrost_drv.c
index a386c66f349c..f8f430f68090 100644
--- a/drivers/gpu/drm/panfrost/panfrost_drv.c
+++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
@@ -19,6 +19,7 @@
#include "panfrost_job.h"
#include "panfrost_gpu.h"
#include "panfrost_perfcnt.h"
+#include "panfrost_submitqueue.h"
static bool unstable_ioctls;
module_param_unsafe(unstable_ioctls, bool, 0600);
@@ -259,6 +260,7 @@ static int panfrost_ioctl_submit(struct drm_device *dev,
void *data,
struct panfrost_device *pfdev = dev->dev_private;
struct drm_panfrost_submit *args = data;
struct drm_syncobj *sync_out = NULL;
+ struct panfrost_submitqueue *queue;
struct panfrost_job *job;
int ret = 0, slot;
@@ -268,10 +270,16 @@ static int panfrost_ioctl_submit(struct drm_device *dev,
void *data,
if (args->requirements && args->requirements != PANFROST_JD_REQ_FS)
return -EINVAL;
+ queue = panfrost_submitqueue_get(file->driver_priv, 0);
+ if (IS_ERR(queue))
+ return PTR_ERR(queue);
+
if (args->out_sync > 0) {
sync_out = drm_syncobj_find(file, args->out_sync);
- if (!sync_out)
- return -ENODEV;
+ if (!sync_out) {
+ ret = -ENODEV;
+ goto fail_put_queue;
+ }
}
job = kzalloc(sizeof(*job), GFP_KERNEL);
@@ -291,7 +299,7 @@ static int panfrost_ioctl_submit(struct drm_device *dev,
void *data,
slot = panfrost_job_get_slot(job);
ret = drm_sched_job_init(&job->base,
-&job->file_priv->sched_entity[slot],
+&queue->sched_entity[slot],
NULL);
if (ret)
goto out_put_job;
@@ -304,7 +312,7 @@ static int panfrost_ioctl_submit(struct drm_device *dev,
void *data,
if (ret)
goto out_cleanup_job;
- ret = panfrost_job_push(job);
+ ret = panfrost_job_push(queue, job);
if (ret)
goto out_cleanup_job;
@@ -320,6 +328,8 @@ static int panfrost_ioctl_submit(struct drm_device *dev,
void *data,
out_put_syncout:
if (sync_out)
drm_syncobj_put(sync_out);
+fail_put_queue:
+ panfrost_submitqueue_put(queue);
return ret;
}
@@ -469,6 +479,36 @@ static int panfrost_ioctl_madvise(struct drm_device *dev,
void *data,
return ret;
}
+static int
+panfrost_ioctl_create_submitqueue(struct drm_device *dev, void *data,
+ struct drm_file *file_priv)
+{
+ struct panfrost_file_priv *priv = file_priv->driver_priv;
+ struct drm_panfrost_create_submitqueue *args = data;
+ int ret;
+
+ ret = panfrost_submitqueue_create(priv, args->priority, args->flags);
+ if (ret < 0)
+ return ret;
+
+ args->id = ret;
+ return 0;
+}
+
+static int
+panfrost_ioctl_destroy_submitqueue(struct drm_device *dev, void *data,
+
[PATCH v5 8/8] drm/panfrost: Bump minor version to reflect the feature additions
We now have a new ioctl that allows submitting multiple jobs at once
(among other things) and we support timelined syncobjs. Bump the
minor version number to reflect those changes.
Signed-off-by: Boris Brezillon
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_drv.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
b/drivers/gpu/drm/panfrost/panfrost_drv.c
index 9f983b763372..21871810df77 100644
--- a/drivers/gpu/drm/panfrost/panfrost_drv.c
+++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
@@ -815,6 +815,9 @@ DEFINE_DRM_GEM_FOPS(panfrost_drm_driver_fops);
* - 1.1 - adds HEAP and NOEXEC flags for CREATE_BO
* - 1.2 - adds AFBC_FEATURES query
* - 1.3 - adds PANFROST_BO_NO{READ,WRITE} flags
+ * - 1.4 - adds the BATCH_SUBMIT, CREATE_SUBMITQUEUE, DESTROY_SUBMITQUEUE
+ *ioctls, adds support for DEP_ONLY jobs and advertises the
+ *SYNCOBJ_TIMELINE feature
*/
static const struct drm_driver panfrost_drm_driver = {
.driver_features= DRIVER_RENDER | DRIVER_GEM | DRIVER_SYNCOBJ |
--
2.31.1
[PATCH v5 0/8] drm/panfrost: drm/panfrost: Add a new submit ioctl
Hello,
I finally got to resubmitting a new version of this series. I think
I fixed all the issues reported by Steve and Daniel. Still no support
for {IN,OUT}_FENCE_FD, but that can be added later if we need it.
For those who didn't follow the previous iterations, this is an
attempt at providing a new submit ioctl that's more Vulkan-friendly
than the existing one. This ioctl
1/ allows passing several out syncobjs so we can easily update
several fence/semaphore in a single ioctl() call
2/ allows passing several jobs so we don't have to have one ioctl
per job-chain recorded in the command buffer
3/ supports disabling implicit dependencies as well as
non-exclusive access to BOs, thus removing unnecessary
synchronization
I've also been looking at adding {IN,OUT}_FENCE_FD support (allowing
one to pass at most one sync_file object in input and/or creating a
sync_file FD embedding the render out fence), but it's not entirely
clear to me when that's useful. Indeed, we can already do the
sync_file <-> syncobj conversion using the
SYNCOBJ_{FD_TO_HANDLE,HANDLE_TO_FD} ioctls if we have to.
Note that, unlike Turnip, PanVk is using syncobjs to implement
vkQueueWaitIdle(), so the syncobj -> sync_file conversion doesn't
have to happen for each submission, but maybe there's a good reason
to use sync_files for that too. Any feedback on that aspect would
be useful I guess.
Any feedback on this new ioctl is welcome, in particular, do you
think other things are missing/would be nice to have for Vulkan?
Regards,
Boris
P.S.: basic igt tests for these new ioctls re available there [1]
[1]https://gitlab.freedesktop.org/bbrezillon/igt-gpu-tools/-/tree/panfrost-batch-submit
Boris Brezillon (8):
drm/panfrost: Pass a job to panfrost_{acquire,attach}_object_fences()
drm/panfrost: Move the mappings collection out of
panfrost_lookup_bos()
drm/panfrost: Add BO access flags to relax dependencies between jobs
drm/panfrost: Add the ability to create submit queues
drm/panfrost: Add a new ioctl to submit batches
drm/panfrost: Support synchronization jobs
drm/panfrost: Advertise the SYNCOBJ_TIMELINE feature
drm/panfrost: Bump minor version to reflect the feature additions
drivers/gpu/drm/panfrost/Makefile | 3 +-
drivers/gpu/drm/panfrost/panfrost_device.h| 2 +-
drivers/gpu/drm/panfrost/panfrost_drv.c | 637 +-
drivers/gpu/drm/panfrost/panfrost_job.c | 93 ++-
drivers/gpu/drm/panfrost/panfrost_job.h | 8 +-
.../gpu/drm/panfrost/panfrost_submitqueue.c | 132
.../gpu/drm/panfrost/panfrost_submitqueue.h | 26 +
include/uapi/drm/panfrost_drm.h | 119
8 files changed, 796 insertions(+), 224 deletions(-)
create mode 100644 drivers/gpu/drm/panfrost/panfrost_submitqueue.c
create mode 100644 drivers/gpu/drm/panfrost/panfrost_submitqueue.h
--
2.31.1
[PATCH v5 1/8] drm/panfrost: Pass a job to panfrost_{acquire, attach}_object_fences()
So we don't have to change the prototype if we extend the function.
v3:
* Fix subject
Signed-off-by: Boris Brezillon
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_job.c | 22 --
1 file changed, 8 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c
b/drivers/gpu/drm/panfrost/panfrost_job.c
index 908d79520853..ed8d1588b1de 100644
--- a/drivers/gpu/drm/panfrost/panfrost_job.c
+++ b/drivers/gpu/drm/panfrost/panfrost_job.c
@@ -240,15 +240,13 @@ static void panfrost_job_hw_submit(struct panfrost_job
*job, int js)
spin_unlock(&pfdev->js->job_lock);
}
-static int panfrost_acquire_object_fences(struct drm_gem_object **bos,
- int bo_count,
- struct drm_sched_job *job)
+static int panfrost_acquire_object_fences(struct panfrost_job *job)
{
int i, ret;
- for (i = 0; i < bo_count; i++) {
+ for (i = 0; i < job->bo_count; i++) {
/* panfrost always uses write mode in its current uapi */
- ret = drm_sched_job_add_implicit_dependencies(job, bos[i],
+ ret = drm_sched_job_add_implicit_dependencies(&job->base,
job->bos[i],
true);
if (ret)
return ret;
@@ -257,14 +255,12 @@ static int panfrost_acquire_object_fences(struct
drm_gem_object **bos,
return 0;
}
-static void panfrost_attach_object_fences(struct drm_gem_object **bos,
- int bo_count,
- struct dma_fence *fence)
+static void panfrost_attach_object_fences(struct panfrost_job *job)
{
int i;
- for (i = 0; i < bo_count; i++)
- dma_resv_add_excl_fence(bos[i]->resv, fence);
+ for (i = 0; i < job->bo_count; i++)
+ dma_resv_add_excl_fence(job->bos[i]->resv,
job->render_done_fence);
}
int panfrost_job_push(struct panfrost_job *job)
@@ -283,8 +279,7 @@ int panfrost_job_push(struct panfrost_job *job)
job->render_done_fence = dma_fence_get(&job->base.s_fence->finished);
- ret = panfrost_acquire_object_fences(job->bos, job->bo_count,
-&job->base);
+ ret = panfrost_acquire_object_fences(job);
if (ret) {
mutex_unlock(&pfdev->sched_lock);
goto unlock;
@@ -296,8 +291,7 @@ int panfrost_job_push(struct panfrost_job *job)
mutex_unlock(&pfdev->sched_lock);
- panfrost_attach_object_fences(job->bos, job->bo_count,
- job->render_done_fence);
+ panfrost_attach_object_fences(job);
unlock:
drm_gem_unlock_reservations(job->bos, job->bo_count, &acquire_ctx);
--
2.31.1
Re: [RFC PATCH v2 1/1] Providers/rxe: Add dma-buf support
On Thu, Sep 30, 2021 at 7:06 PM Shunsuke Mie wrote:
>
> 2021年9月30日(木) 16:23 Zhu Yanjun :
> >
> > On Thu, Sep 30, 2021 at 2:58 PM Shunsuke Mie wrote:
> > >
> > > 2021年9月30日(木) 15:37 Zhu Yanjun :
> > > >
> > > > On Thu, Sep 30, 2021 at 2:20 PM Shunsuke Mie wrote:
> > > > >
> > > > > Implement a new provider method for dma-buf base memory registration.
> > > > >
> > > > > Signed-off-by: Shunsuke Mie
> > > > > ---
> > > > > providers/rxe/rxe.c | 21 +
> > > > > 1 file changed, 21 insertions(+)
> > > > >
> > > > > diff --git a/providers/rxe/rxe.c b/providers/rxe/rxe.c
> > > > > index 3c3ea8bb..84e00e60 100644
> > > > > --- a/providers/rxe/rxe.c
> > > > > +++ b/providers/rxe/rxe.c
> > > > > @@ -239,6 +239,26 @@ static struct ibv_mr *rxe_reg_mr(struct ibv_pd
> > > > > *pd, void *addr, size_t length,
> > > > > return &vmr->ibv_mr;
> > > > > }
> > > > >
> > > > > +static struct ibv_mr *rxe_reg_dmabuf_mr(struct ibv_pd *pd, uint64_t
> > > > > offset,
> > > > > + size_t length, uint64_t iova,
> > > > > int fd,
> > > > > + int access)
> > > > > +{
> > > > > + struct verbs_mr *vmr;
> > > > > + int ret;
> > > > > +
> > > > > + vmr = malloc(sizeof(*vmr));
> > > > > + if (!vmr)
> > > > > + return NULL;
> > > > > +
> > > >
> > > > Do we need to set vmr to zero like the following?
> > > >
> > > > memset(vmr, 0, sizeof(*vmr));
> > > >
> > > > Zhu Yanjun
> > > Thank you for your quick response.
> > >
> > > I think it is better to clear the vmr. Actually the mlx5 driver allocates
> > > the vmr using calloc().
> > >
> > > In addition, rxe_reg_mr() (not rxe_reg_dmabuf_mr()) is used the malloc
> > > and not clear the vmr. I think It has to be fixed too. Should I make
> > > another patch to fix this problem?
> >
> > Yes. Please.
> >
> > Zhu Yanjun
> >
> > >
> > > Thanks a lot.
> > > Shunsuke
> > >
> > > ~
>
> I looked into the vmr more, but there was no need to clear it. Moreover,
> some implementations also use malloc without memory clear.
>
I confronted a lot of problems with memory not initialization.
And a latest bug is https://www.spinics.net/lists/linux-rdma/msg105001.html
So it is a good habit to clear a newly allocated memory.
Zhu Yanjun
> Thanks,
> Shunsuke
Re: [PATCH] drm/i915: Use direction definition DMA_BIDIRECTIONAL instead of PCI_DMA_BIDIRECTIONAL
Le 30/09/2021 à 16:21, Daniel Vetter a écrit :
On Sat, Sep 25, 2021 at 08:46:12PM +0800, Cai Huoqing wrote:
Replace direction definition PCI_DMA_BIDIRECTIONAL
with DMA_BIDIRECTIONAL, because it helps to enhance readability
and avoid possible inconsistency.
Signed-off-by: Cai Huoqing
Applied to drm-intel-gt-next, thanks for the patch.
-Daniel
Hi,
just in case, a similar patch received some (unrelated) comments a few
weeks ago. See [1].
Should it rings some bells to someone who know who knows what should be
done.
Just my 2c.
[1]:
https://lore.kernel.org/kernel-janitors/0cd61d5b-ac88-31e8-99ad-143af4804...@arm.com/
CJ
---
drivers/gpu/drm/i915/gt/intel_region_lmem.c | 4 ++--
drivers/gpu/drm/i915/gvt/gtt.c | 17 -
drivers/gpu/drm/i915/gvt/kvmgt.c| 4 ++--
drivers/gpu/drm/i915/i915_gem_gtt.c | 4 ++--
4 files changed, 14 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_region_lmem.c
b/drivers/gpu/drm/i915/gt/intel_region_lmem.c
index a74b72f50cc9..afb35d2e5c73 100644
--- a/drivers/gpu/drm/i915/gt/intel_region_lmem.c
+++ b/drivers/gpu/drm/i915/gt/intel_region_lmem.c
@@ -32,7 +32,7 @@ static int init_fake_lmem_bar(struct intel_memory_region *mem)
mem->remap_addr = dma_map_resource(i915->drm.dev,
mem->region.start,
mem->fake_mappable.size,
- PCI_DMA_BIDIRECTIONAL,
+ DMA_BIDIRECTIONAL,
DMA_ATTR_FORCE_CONTIGUOUS);
if (dma_mapping_error(i915->drm.dev, mem->remap_addr)) {
drm_mm_remove_node(&mem->fake_mappable);
@@ -62,7 +62,7 @@ static void release_fake_lmem_bar(struct intel_memory_region
*mem)
dma_unmap_resource(mem->i915->drm.dev,
mem->remap_addr,
mem->fake_mappable.size,
- PCI_DMA_BIDIRECTIONAL,
+ DMA_BIDIRECTIONAL,
DMA_ATTR_FORCE_CONTIGUOUS);
}
diff --git a/drivers/gpu/drm/i915/gvt/gtt.c b/drivers/gpu/drm/i915/gvt/gtt.c
index e5c2fdfc20e3..53d0cb327539 100644
--- a/drivers/gpu/drm/i915/gvt/gtt.c
+++ b/drivers/gpu/drm/i915/gvt/gtt.c
@@ -745,7 +745,7 @@ static void ppgtt_free_spt(struct intel_vgpu_ppgtt_spt *spt)
trace_spt_free(spt->vgpu->id, spt, spt->guest_page.type);
dma_unmap_page(kdev, spt->shadow_page.mfn << I915_GTT_PAGE_SHIFT, 4096,
- PCI_DMA_BIDIRECTIONAL);
+ DMA_BIDIRECTIONAL);
radix_tree_delete(&spt->vgpu->gtt.spt_tree, spt->shadow_page.mfn);
@@ -849,7 +849,7 @@ static struct intel_vgpu_ppgtt_spt *ppgtt_alloc_spt(
*/
spt->shadow_page.type = type;
daddr = dma_map_page(kdev, spt->shadow_page.page,
-0, 4096, PCI_DMA_BIDIRECTIONAL);
+0, 4096, DMA_BIDIRECTIONAL);
if (dma_mapping_error(kdev, daddr)) {
gvt_vgpu_err("fail to map dma addr\n");
ret = -EINVAL;
@@ -865,7 +865,7 @@ static struct intel_vgpu_ppgtt_spt *ppgtt_alloc_spt(
return spt;
err_unmap_dma:
- dma_unmap_page(kdev, daddr, PAGE_SIZE, PCI_DMA_BIDIRECTIONAL);
+ dma_unmap_page(kdev, daddr, PAGE_SIZE, DMA_BIDIRECTIONAL);
err_free_spt:
free_spt(spt);
return ERR_PTR(ret);
@@ -2409,8 +2409,7 @@ static int alloc_scratch_pages(struct intel_vgpu *vgpu,
return -ENOMEM;
}
- daddr = dma_map_page(dev, virt_to_page(scratch_pt), 0,
- 4096, PCI_DMA_BIDIRECTIONAL);
+ daddr = dma_map_page(dev, virt_to_page(scratch_pt), 0, 4096,
DMA_BIDIRECTIONAL);
if (dma_mapping_error(dev, daddr)) {
gvt_vgpu_err("fail to dmamap scratch_pt\n");
__free_page(virt_to_page(scratch_pt));
@@ -2461,7 +2460,7 @@ static int release_scratch_page_tree(struct intel_vgpu
*vgpu)
if (vgpu->gtt.scratch_pt[i].page != NULL) {
daddr = (dma_addr_t)(vgpu->gtt.scratch_pt[i].page_mfn <<
I915_GTT_PAGE_SHIFT);
- dma_unmap_page(dev, daddr, 4096, PCI_DMA_BIDIRECTIONAL);
+ dma_unmap_page(dev, daddr, 4096, DMA_BIDIRECTIONAL);
__free_page(vgpu->gtt.scratch_pt[i].page);
vgpu->gtt.scratch_pt[i].page = NULL;
vgpu->gtt.scratch_pt[i].page_mfn = 0;
@@ -2741,7 +2740,7 @@ int intel_gvt_init_gtt(struct intel_gvt *gvt)
}
daddr = dma_map_page(dev, virt_to_page(page), 0,
- 4096, PCI_DMA_BIDIRECTIONAL);
+ 4096, DMA_BIDIRECTIONAL);
if (dma_mapping_error(dev, daddr)) {
gvt_err("fail to dmamap scratch ggtt page\n");
__free_page(v
Re: [PATCH] drm/msm/a6xx: Track current ctx by seqno
On Thu, Sep 30, 2021 at 11:34 AM Daniel Vetter wrote:
>
> On Thu, Sep 30, 2021 at 8:20 PM Rob Clark wrote:
> >
> > From: Rob Clark
> >
> > In theory a context can be destroyed and a new one allocated at the same
> > address, making the pointer comparision to detect when we don't need to
> > update the current pagetables invalid. Instead assign a sequence number
> > to each context on creation, and use this for the check.
> >
> > Fixes: 84c31ee16f90 ("drm/msm/a6xx: Add support for per-instance
> > pagetables")
> > Signed-off-by: Rob Clark
>
> Usually the weak reference pattern is to wrap a spinlock or something
> around it and clear it out on destruction. Or hold a full reference
> (e.g. on intel hw the hw goes unhappy if there's no context/pagetables
> at all, so we always need some). But I guess this works too.
yeah, the seqno approach was so that gen agnostic code didn't have to
go fishing around in a6xx_gpu..
I guess the downside is userspace could open/close the dev file 2^32
times without submitting any rendering to trigger the same sort of
issue. But there are plenty of easier ways for userspace to trigger
faults if it wanted.
BR,
-R
> -Daniel
>
> > ---
> > drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 6 +++---
> > drivers/gpu/drm/msm/adreno/a6xx_gpu.h | 11 ++-
> > drivers/gpu/drm/msm/msm_drv.c | 3 +++
> > drivers/gpu/drm/msm/msm_drv.h | 1 +
> > 4 files changed, 17 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> > b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> > index 5e1ae3df42ba..e0a8b2fd1ff0 100644
> > --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> > +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> > @@ -106,7 +106,7 @@ static void a6xx_set_pagetable(struct a6xx_gpu
> > *a6xx_gpu,
> > u32 asid;
> > u64 memptr = rbmemptr(ring, ttbr0);
> >
> > - if (ctx == a6xx_gpu->cur_ctx)
> > + if (ctx->seqno == a6xx_gpu->cur_ctx_seqno)
> > return;
> >
> > if (msm_iommu_pagetable_params(ctx->aspace->mmu, &ttbr, &asid))
> > @@ -139,7 +139,7 @@ static void a6xx_set_pagetable(struct a6xx_gpu
> > *a6xx_gpu,
> > OUT_PKT7(ring, CP_EVENT_WRITE, 1);
> > OUT_RING(ring, 0x31);
> >
> > - a6xx_gpu->cur_ctx = ctx;
> > + a6xx_gpu->cur_ctx_seqno = ctx->seqno;
> > }
> >
> > static void a6xx_submit(struct msm_gpu *gpu, struct msm_gem_submit *submit)
> > @@ -1081,7 +1081,7 @@ static int hw_init(struct msm_gpu *gpu)
> > /* Always come up on rb 0 */
> > a6xx_gpu->cur_ring = gpu->rb[0];
> >
> > - a6xx_gpu->cur_ctx = NULL;
> > + a6xx_gpu->cur_ctx_seqno = 0;
> >
> > /* Enable the SQE_to start the CP engine */
> > gpu_write(gpu, REG_A6XX_CP_SQE_CNTL, 1);
> > diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
> > b/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
> > index 0bc2d062f54a..8e5527c881b1 100644
> > --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
> > +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
> > @@ -19,7 +19,16 @@ struct a6xx_gpu {
> > uint64_t sqe_iova;
> >
> > struct msm_ringbuffer *cur_ring;
> > - struct msm_file_private *cur_ctx;
> > +
> > + /**
> > +* cur_ctx_seqno:
> > +*
> > +* The ctx->seqno value of the context with current pgtables
> > +* installed. Tracked by seqno rather than pointer value to
> > +* avoid dangling pointers, and cases where a ctx can be freed
> > +* and a new one created with the same address.
> > +*/
> > + int cur_ctx_seqno;
> >
> > struct a6xx_gmu gmu;
> >
> > diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
> > index 624078b3adf2..30c1efc3d8a0 100644
> > --- a/drivers/gpu/drm/msm/msm_drv.c
> > +++ b/drivers/gpu/drm/msm/msm_drv.c
> > @@ -711,6 +711,7 @@ static void load_gpu(struct drm_device *dev)
> >
> > static int context_init(struct drm_device *dev, struct drm_file *file)
> > {
> > + static atomic_t ident = ATOMIC_INIT(0);
> > struct msm_drm_private *priv = dev->dev_private;
> > struct msm_file_private *ctx;
> >
> > @@ -727,6 +728,8 @@ static int context_init(struct drm_device *dev, struct
> > drm_file *file)
> > ctx->aspace = msm_gpu_create_private_address_space(priv->gpu,
> > current);
> > file->driver_priv = ctx;
> >
> > + ctx->seqno = atomic_inc_return(&ident);
> > +
> > return 0;
> > }
> >
> > diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
> > index de062450add4..8633d0059a3e 100644
> > --- a/drivers/gpu/drm/msm/msm_drv.h
> > +++ b/drivers/gpu/drm/msm/msm_drv.h
> > @@ -59,6 +59,7 @@ struct msm_file_private {
> > int queueid;
> > struct msm_gem_address_space *aspace;
> > struct kref ref;
> > + int seqno;
> > };
> >
> > enum msm_mdp_plane_property {
> > --
> > 2.31.1
> >
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
[PATCH] drm/panfrost: Add PANFROST_BO_NO{READ,WRITE} flags
So we can create GPU mappings without R/W permissions. Particularly
useful to debug corruptions caused by out-of-bound writes.
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/panfrost/panfrost_drv.c | 14 --
drivers/gpu/drm/panfrost/panfrost_gem.c | 2 ++
drivers/gpu/drm/panfrost/panfrost_gem.h | 2 ++
drivers/gpu/drm/panfrost/panfrost_mmu.c | 8 +++-
include/uapi/drm/panfrost_drm.h | 2 ++
5 files changed, 25 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
b/drivers/gpu/drm/panfrost/panfrost_drv.c
index 82ad9a67f251..40e4a4db3ab1 100644
--- a/drivers/gpu/drm/panfrost/panfrost_drv.c
+++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
@@ -75,6 +75,10 @@ static int panfrost_ioctl_get_param(struct drm_device *ddev,
void *data, struct
return 0;
}
+#define PANFROST_BO_FLAGS \
+ (PANFROST_BO_NOEXEC | PANFROST_BO_HEAP | \
+PANFROST_BO_NOREAD | PANFROST_BO_NOWRITE)
+
static int panfrost_ioctl_create_bo(struct drm_device *dev, void *data,
struct drm_file *file)
{
@@ -84,7 +88,7 @@ static int panfrost_ioctl_create_bo(struct drm_device *dev,
void *data,
struct panfrost_gem_mapping *mapping;
if (!args->size || args->pad ||
- (args->flags & ~(PANFROST_BO_NOEXEC | PANFROST_BO_HEAP)))
+ (args->flags & ~PANFROST_BO_FLAGS))
return -EINVAL;
/* Heaps should never be executable */
@@ -92,6 +96,11 @@ static int panfrost_ioctl_create_bo(struct drm_device *dev,
void *data,
!(args->flags & PANFROST_BO_NOEXEC))
return -EINVAL;
+ /* Executable implies readable */
+ if ((args->flags & PANFROST_BO_NOREAD) &&
+ !(args->flags & PANFROST_BO_NOEXEC))
+ return -EINVAL;
+
bo = panfrost_gem_create_with_handle(file, dev, args->size, args->flags,
&args->handle);
if (IS_ERR(bo))
@@ -520,6 +529,7 @@ DEFINE_DRM_GEM_FOPS(panfrost_drm_driver_fops);
* - 1.0 - initial interface
* - 1.1 - adds HEAP and NOEXEC flags for CREATE_BO
* - 1.2 - adds AFBC_FEATURES query
+ * - 1.3 - adds PANFROST_BO_NO{READ,WRITE} flags
*/
static const struct drm_driver panfrost_drm_driver = {
.driver_features= DRIVER_RENDER | DRIVER_GEM | DRIVER_SYNCOBJ,
@@ -532,7 +542,7 @@ static const struct drm_driver panfrost_drm_driver = {
.desc = "panfrost DRM",
.date = "20180908",
.major = 1,
- .minor = 2,
+ .minor = 3,
.gem_create_object = panfrost_gem_create_object,
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
diff --git a/drivers/gpu/drm/panfrost/panfrost_gem.c
b/drivers/gpu/drm/panfrost/panfrost_gem.c
index 23377481f4e3..d6c1bb1445f2 100644
--- a/drivers/gpu/drm/panfrost/panfrost_gem.c
+++ b/drivers/gpu/drm/panfrost/panfrost_gem.c
@@ -251,6 +251,8 @@ panfrost_gem_create_with_handle(struct drm_file *file_priv,
bo = to_panfrost_bo(&shmem->base);
bo->noexec = !!(flags & PANFROST_BO_NOEXEC);
+ bo->noread = !!(flags & PANFROST_BO_NOREAD);
+ bo->nowrite = !!(flags & PANFROST_BO_NOWRITE);
bo->is_heap = !!(flags & PANFROST_BO_HEAP);
/*
diff --git a/drivers/gpu/drm/panfrost/panfrost_gem.h
b/drivers/gpu/drm/panfrost/panfrost_gem.h
index 8088d5fd8480..6246b5fef446 100644
--- a/drivers/gpu/drm/panfrost/panfrost_gem.h
+++ b/drivers/gpu/drm/panfrost/panfrost_gem.h
@@ -37,6 +37,8 @@ struct panfrost_gem_object {
atomic_t gpu_usecount;
bool noexec :1;
+ bool noread :1;
+ bool nowrite:1;
bool is_heap:1;
};
diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.c
b/drivers/gpu/drm/panfrost/panfrost_mmu.c
index f51d3f791a17..6a5c9d94d6f2 100644
--- a/drivers/gpu/drm/panfrost/panfrost_mmu.c
+++ b/drivers/gpu/drm/panfrost/panfrost_mmu.c
@@ -307,7 +307,7 @@ int panfrost_mmu_map(struct panfrost_gem_mapping *mapping)
struct drm_gem_object *obj = &bo->base.base;
struct panfrost_device *pfdev = to_panfrost_device(obj->dev);
struct sg_table *sgt;
- int prot = IOMMU_READ | IOMMU_WRITE;
+ int prot = 0;
if (WARN_ON(mapping->active))
return 0;
@@ -315,6 +315,12 @@ int panfrost_mmu_map(struct panfrost_gem_mapping *mapping)
if (bo->noexec)
prot |= IOMMU_NOEXEC;
+ if (!bo->nowrite)
+ prot |= IOMMU_WRITE;
+
+ if (!bo->noread)
+ prot |= IOMMU_READ;
+
sgt = drm_gem_shmem_get_pages_sgt(obj);
if (WARN_ON(IS_ERR(sgt)))
return PTR_ERR(sgt);
diff --git a/include/uapi/drm/panfrost_drm.h b/include/uapi/drm/panfrost_drm.h
index 061e700dd06c..a2de81225125 100644
--- a/include/uapi/drm/panfrost_drm.h
+++ b/include/uapi/drm/panfrost_drm.h
@@ -86,6 +86,8 @@ struct d
Re: [RFC 0/6] CPU + GPU synchronised priority scheduling
On Thu, Sep 30, 2021 at 06:15:46PM +0100, Tvrtko Ursulin wrote: > (Note I did not copy > everyone on all patches but just the cover letter for context and the rest > should be available from the mailing list.) In general, if you can't be arsed to send it to me, I can't be arsed to dig it out. I've got plenty other email I can read without having to go looking for more.
Re: [PATCH] drm/msm/a6xx: Track current ctx by seqno
On Thu, Sep 30, 2021 at 8:20 PM Rob Clark wrote:
>
> From: Rob Clark
>
> In theory a context can be destroyed and a new one allocated at the same
> address, making the pointer comparision to detect when we don't need to
> update the current pagetables invalid. Instead assign a sequence number
> to each context on creation, and use this for the check.
>
> Fixes: 84c31ee16f90 ("drm/msm/a6xx: Add support for per-instance pagetables")
> Signed-off-by: Rob Clark
Usually the weak reference pattern is to wrap a spinlock or something
around it and clear it out on destruction. Or hold a full reference
(e.g. on intel hw the hw goes unhappy if there's no context/pagetables
at all, so we always need some). But I guess this works too.
-Daniel
> ---
> drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 6 +++---
> drivers/gpu/drm/msm/adreno/a6xx_gpu.h | 11 ++-
> drivers/gpu/drm/msm/msm_drv.c | 3 +++
> drivers/gpu/drm/msm/msm_drv.h | 1 +
> 4 files changed, 17 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> index 5e1ae3df42ba..e0a8b2fd1ff0 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> @@ -106,7 +106,7 @@ static void a6xx_set_pagetable(struct a6xx_gpu *a6xx_gpu,
> u32 asid;
> u64 memptr = rbmemptr(ring, ttbr0);
>
> - if (ctx == a6xx_gpu->cur_ctx)
> + if (ctx->seqno == a6xx_gpu->cur_ctx_seqno)
> return;
>
> if (msm_iommu_pagetable_params(ctx->aspace->mmu, &ttbr, &asid))
> @@ -139,7 +139,7 @@ static void a6xx_set_pagetable(struct a6xx_gpu *a6xx_gpu,
> OUT_PKT7(ring, CP_EVENT_WRITE, 1);
> OUT_RING(ring, 0x31);
>
> - a6xx_gpu->cur_ctx = ctx;
> + a6xx_gpu->cur_ctx_seqno = ctx->seqno;
> }
>
> static void a6xx_submit(struct msm_gpu *gpu, struct msm_gem_submit *submit)
> @@ -1081,7 +1081,7 @@ static int hw_init(struct msm_gpu *gpu)
> /* Always come up on rb 0 */
> a6xx_gpu->cur_ring = gpu->rb[0];
>
> - a6xx_gpu->cur_ctx = NULL;
> + a6xx_gpu->cur_ctx_seqno = 0;
>
> /* Enable the SQE_to start the CP engine */
> gpu_write(gpu, REG_A6XX_CP_SQE_CNTL, 1);
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
> b/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
> index 0bc2d062f54a..8e5527c881b1 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
> @@ -19,7 +19,16 @@ struct a6xx_gpu {
> uint64_t sqe_iova;
>
> struct msm_ringbuffer *cur_ring;
> - struct msm_file_private *cur_ctx;
> +
> + /**
> +* cur_ctx_seqno:
> +*
> +* The ctx->seqno value of the context with current pgtables
> +* installed. Tracked by seqno rather than pointer value to
> +* avoid dangling pointers, and cases where a ctx can be freed
> +* and a new one created with the same address.
> +*/
> + int cur_ctx_seqno;
>
> struct a6xx_gmu gmu;
>
> diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
> index 624078b3adf2..30c1efc3d8a0 100644
> --- a/drivers/gpu/drm/msm/msm_drv.c
> +++ b/drivers/gpu/drm/msm/msm_drv.c
> @@ -711,6 +711,7 @@ static void load_gpu(struct drm_device *dev)
>
> static int context_init(struct drm_device *dev, struct drm_file *file)
> {
> + static atomic_t ident = ATOMIC_INIT(0);
> struct msm_drm_private *priv = dev->dev_private;
> struct msm_file_private *ctx;
>
> @@ -727,6 +728,8 @@ static int context_init(struct drm_device *dev, struct
> drm_file *file)
> ctx->aspace = msm_gpu_create_private_address_space(priv->gpu,
> current);
> file->driver_priv = ctx;
>
> + ctx->seqno = atomic_inc_return(&ident);
> +
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
> index de062450add4..8633d0059a3e 100644
> --- a/drivers/gpu/drm/msm/msm_drv.h
> +++ b/drivers/gpu/drm/msm/msm_drv.h
> @@ -59,6 +59,7 @@ struct msm_file_private {
> int queueid;
> struct msm_gem_address_space *aspace;
> struct kref ref;
> + int seqno;
> };
>
> enum msm_mdp_plane_property {
> --
> 2.31.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [RFC 1/6] sched: Add nice value change notifier
On Thu, Sep 30, 2021 at 06:15:47PM +0100, Tvrtko Ursulin wrote:
> void set_user_nice(struct task_struct *p, long nice)
> {
> bool queued, running;
> - int old_prio;
> + int old_prio, ret;
> struct rq_flags rf;
> struct rq *rq;
>
> @@ -6913,6 +6945,9 @@ void set_user_nice(struct task_struct *p, long nice)
>*/
> p->sched_class->prio_changed(rq, p, old_prio);
>
> + ret = atomic_notifier_call_chain(&user_nice_notifier_list, nice, p);
> + WARN_ON_ONCE(ret != NOTIFY_DONE);
> +
> out_unlock:
> task_rq_unlock(rq, p, &rf);
> }
No, we're not going to call out to exported, and potentially unbounded,
functions under scheduler locks.
[PATCH] drm/msm/a6xx: Track current ctx by seqno
From: Rob Clark
In theory a context can be destroyed and a new one allocated at the same
address, making the pointer comparision to detect when we don't need to
update the current pagetables invalid. Instead assign a sequence number
to each context on creation, and use this for the check.
Fixes: 84c31ee16f90 ("drm/msm/a6xx: Add support for per-instance pagetables")
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 6 +++---
drivers/gpu/drm/msm/adreno/a6xx_gpu.h | 11 ++-
drivers/gpu/drm/msm/msm_drv.c | 3 +++
drivers/gpu/drm/msm/msm_drv.h | 1 +
4 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 5e1ae3df42ba..e0a8b2fd1ff0 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -106,7 +106,7 @@ static void a6xx_set_pagetable(struct a6xx_gpu *a6xx_gpu,
u32 asid;
u64 memptr = rbmemptr(ring, ttbr0);
- if (ctx == a6xx_gpu->cur_ctx)
+ if (ctx->seqno == a6xx_gpu->cur_ctx_seqno)
return;
if (msm_iommu_pagetable_params(ctx->aspace->mmu, &ttbr, &asid))
@@ -139,7 +139,7 @@ static void a6xx_set_pagetable(struct a6xx_gpu *a6xx_gpu,
OUT_PKT7(ring, CP_EVENT_WRITE, 1);
OUT_RING(ring, 0x31);
- a6xx_gpu->cur_ctx = ctx;
+ a6xx_gpu->cur_ctx_seqno = ctx->seqno;
}
static void a6xx_submit(struct msm_gpu *gpu, struct msm_gem_submit *submit)
@@ -1081,7 +1081,7 @@ static int hw_init(struct msm_gpu *gpu)
/* Always come up on rb 0 */
a6xx_gpu->cur_ring = gpu->rb[0];
- a6xx_gpu->cur_ctx = NULL;
+ a6xx_gpu->cur_ctx_seqno = 0;
/* Enable the SQE_to start the CP engine */
gpu_write(gpu, REG_A6XX_CP_SQE_CNTL, 1);
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
index 0bc2d062f54a..8e5527c881b1 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
@@ -19,7 +19,16 @@ struct a6xx_gpu {
uint64_t sqe_iova;
struct msm_ringbuffer *cur_ring;
- struct msm_file_private *cur_ctx;
+
+ /**
+* cur_ctx_seqno:
+*
+* The ctx->seqno value of the context with current pgtables
+* installed. Tracked by seqno rather than pointer value to
+* avoid dangling pointers, and cases where a ctx can be freed
+* and a new one created with the same address.
+*/
+ int cur_ctx_seqno;
struct a6xx_gmu gmu;
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 624078b3adf2..30c1efc3d8a0 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -711,6 +711,7 @@ static void load_gpu(struct drm_device *dev)
static int context_init(struct drm_device *dev, struct drm_file *file)
{
+ static atomic_t ident = ATOMIC_INIT(0);
struct msm_drm_private *priv = dev->dev_private;
struct msm_file_private *ctx;
@@ -727,6 +728,8 @@ static int context_init(struct drm_device *dev, struct
drm_file *file)
ctx->aspace = msm_gpu_create_private_address_space(priv->gpu, current);
file->driver_priv = ctx;
+ ctx->seqno = atomic_inc_return(&ident);
+
return 0;
}
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index de062450add4..8633d0059a3e 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -59,6 +59,7 @@ struct msm_file_private {
int queueid;
struct msm_gem_address_space *aspace;
struct kref ref;
+ int seqno;
};
enum msm_mdp_plane_property {
--
2.31.1
Re: [PATCH] drm/amd: Guard IS_OLD_GCC assignment with CONFIG_CC_IS_GCC
On Thu, Sep 30, 2021 at 12:02 PM Nathan Chancellor wrote:
>
> cc-ifversion only works for GCC, as clang pretends to be GCC 4.2.1 for
> glibc compatibility, which means IS_OLD_GCC will get set and unsupported
> flags will be passed to clang when building certain code within the DCN
> files:
>
> clang-14: error: unknown argument: '-mpreferred-stack-boundary=4'
> make[5]: *** [scripts/Makefile.build:277:
> drivers/gpu/drm/amd/amdgpu/../display/dc/dcn201/dcn201_resource.o] Error 1
>
> Guard the call to cc-ifversion with CONFIG_CC_IS_GCC so that everything
> continues to work properly. See commit 00db297106e8 ("drm/amdgpu: fix stack
> alignment ABI mismatch for GCC 7.1+") for more context.
>
> Fixes: ff7e396f822f ("drm/amd/display: add cyan_skillfish display support")
> Link: https://github.com/ClangBuiltLinux/linux/issues/1468
> Signed-off-by: Nathan Chancellor
Harry beat you to the punch by a little bit.
Thanks!
Alex
> ---
> drivers/gpu/drm/amd/display/dc/dcn201/Makefile | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dcn201/Makefile
> b/drivers/gpu/drm/amd/display/dc/dcn201/Makefile
> index d98d69705117..96cbd4ccd344 100644
> --- a/drivers/gpu/drm/amd/display/dc/dcn201/Makefile
> +++ b/drivers/gpu/drm/amd/display/dc/dcn201/Makefile
> @@ -14,9 +14,11 @@ ifdef CONFIG_PPC64
> CFLAGS_$(AMDDALPATH)/dc/dcn201/dcn201_resource.o := -mhard-float -maltivec
> endif
>
> +ifdef CONFIG_CC_IS_GCC
> ifeq ($(call cc-ifversion, -lt, 0701, y), y)
> IS_OLD_GCC = 1
> endif
> +endif
>
> ifdef CONFIG_X86
> ifdef IS_OLD_GCC
>
> base-commit: b47b99e30cca8906753c83205e8c6179045dd725
> --
> 2.33.0.591.gddb1055343
>
Re: [PATCH] drm/amd: Return NULL instead of false in dcn201_acquire_idle_pipe_for_layer()
On Thu, Sep 30, 2021 at 1:23 PM Nick Desaulniers wrote: > > On Thu, Sep 30, 2021 at 10:10 AM Alex Deucher wrote: > > > > Applied. Thanks! > > > > Alex > > > > On Thu, Sep 30, 2021 at 12:23 PM Nathan Chancellor > > wrote: > > > > > > Clang warns: > > Any chance AMDGPU folks can look into adding clang to the CI roster? We can look into it. We may already be doing it for some groups. Alex > -- > Thanks, > ~Nick Desaulniers
Re: [PATCH v1 2/4] arm64: dts: qcom: sc7280: add display dt nodes
Quoting mkri...@codeaurora.org (2021-09-30 04:56:59)
> On 2021-08-19 01:27, Stephen Boyd wrote:
> > Quoting Krishna Manikandan (2021-08-18 03:27:02)
> >> diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi
> >> b/arch/arm64/boot/dts/qcom/sc7280.dtsi
> >> index 53a21d0..fd7ff1c 100644
> >> --- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
> >> +++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
> >> +
> >> + status = "disabled";
> >> +
> >> + mdp: mdp@ae01000 {
> >
> > display-controller@ae01000
>
> Stephen,
> In the current driver code, there is a substring comparison for "mdp"
> in device node name as part of probe sequence. If "mdp" is not present
> in the node name, it will
> return an error resulting in probe failure. Can we continue using mdp
> as nodename instead of display controller?
>
Can we fix the driver to not look for node names and look for compatible
strings instead? It took me a minute to find compare_name_mdp() in
drivers/gpu/drm/msm/msm_drv.c to understand what you're talking about.
Perhaps looking for qcom,mdp5 in there will be sufficient instead of
looking at the node name.
Re: [PATCH v3] drm/i915/bdb: Fix version check
On Thu, 2021-09-30 at 15:46 +0200, Lukasz Majczak wrote:
> With patch "drm/i915/vbt: Fix backlight parsing for VBT 234+"
> the size of bdb_lfp_backlight_data structure has been increased,
> causing if-statement in the parse_lfp_backlight function
> that comapres this structure size to the one retrieved from BDB,
> always to fail for older revisions.
> This patch calculates expected size of the structure for a given
> BDB version and compares it with the value gathered from BDB.
> Tested on Chromebook Pixelbook (Nocturne) (reports bdb->version = 221)
Reviewed-by: José Roberto de Souza
>
> Tested-by: Lukasz Majczak
> Signed-off-by: Lukasz Majczak
> ---
> drivers/gpu/drm/i915/display/intel_bios.c | 22 ++-
> drivers/gpu/drm/i915/display/intel_vbt_defs.h | 5 +
> 2 files changed, 21 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
> b/drivers/gpu/drm/i915/display/intel_bios.c
> index 3c25926092de..f9776ca85de3 100644
> --- a/drivers/gpu/drm/i915/display/intel_bios.c
> +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> @@ -451,13 +451,23 @@ parse_lfp_backlight(struct drm_i915_private *i915,
> }
>
> i915->vbt.backlight.type = INTEL_BACKLIGHT_DISPLAY_DDI;
> - if (bdb->version >= 191 &&
> - get_blocksize(backlight_data) >= sizeof(*backlight_data)) {
> - const struct lfp_backlight_control_method *method;
> + if (bdb->version >= 191) {
> + size_t exp_size;
>
> - method = &backlight_data->backlight_control[panel_type];
> - i915->vbt.backlight.type = method->type;
> - i915->vbt.backlight.controller = method->controller;
> + if (bdb->version >= 236)
> + exp_size = sizeof(struct bdb_lfp_backlight_data);
> + else if (bdb->version >= 234)
> + exp_size = EXP_BDB_LFP_BL_DATA_SIZE_REV_234;
> + else
> + exp_size = EXP_BDB_LFP_BL_DATA_SIZE_REV_191;
> +
> + if (get_blocksize(backlight_data) >= exp_size) {
> + const struct lfp_backlight_control_method *method;
> +
> + method = &backlight_data->backlight_control[panel_type];
> + i915->vbt.backlight.type = method->type;
> + i915->vbt.backlight.controller = method->controller;
> + }
> }
>
> i915->vbt.backlight.pwm_freq_hz = entry->pwm_freq_hz;
> diff --git a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> index 330077c2e588..a2108a8f544d 100644
> --- a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> +++ b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
> @@ -814,6 +814,11 @@ struct lfp_brightness_level {
> u16 reserved;
> } __packed;
>
> +#define EXP_BDB_LFP_BL_DATA_SIZE_REV_191 \
> + offsetof(struct bdb_lfp_backlight_data, brightness_level)
> +#define EXP_BDB_LFP_BL_DATA_SIZE_REV_234 \
> + offsetof(struct bdb_lfp_backlight_data, brightness_precision_bits)
> +
> struct bdb_lfp_backlight_data {
> u8 entry_size;
> struct lfp_backlight_data_entry data[16];
Re: [PATCH] drm/amd: Return NULL instead of false in dcn201_acquire_idle_pipe_for_layer()
On Thu, Sep 30, 2021 at 10:10 AM Alex Deucher wrote: > > Applied. Thanks! > > Alex > > On Thu, Sep 30, 2021 at 12:23 PM Nathan Chancellor wrote: > > > > Clang warns: Any chance AMDGPU folks can look into adding clang to the CI roster? -- Thanks, ~Nick Desaulniers
Re: [PATCH] drm/amd: Initialize remove_mpcc in dcn201_update_mpcc()
Applied. Thanks!
Alex
On Thu, Sep 30, 2021 at 12:16 PM Nathan Chancellor wrote:
>
> Clang warns:
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/dcn201/dcn201_hwseq.c:505:6: error:
> variable 'remove_mpcc' is used uninitialized whenever 'if' condition is false
> [-Werror,-Wsometimes-uninitialized]
> if (mpc->funcs->get_mpcc_for_dpp_from_secondary)
> ^~~
> drivers/gpu/drm/amd/amdgpu/../display/dc/dcn201/dcn201_hwseq.c:509:6: note:
> uninitialized use occurs here
> if (remove_mpcc != NULL && mpc->funcs->remove_mpcc_from_secondary)
> ^~~
> drivers/gpu/drm/amd/amdgpu/../display/dc/dcn201/dcn201_hwseq.c:505:2: note:
> remove the 'if' if its condition is always true
> if (mpc->funcs->get_mpcc_for_dpp_from_secondary)
> ^~~~
> drivers/gpu/drm/amd/amdgpu/../display/dc/dcn201/dcn201_hwseq.c:442:26: note:
> initialize the variable 'remove_mpcc' to silence this warning
> struct mpcc *remove_mpcc;
> ^
> = NULL
> 1 error generated.
>
> The code already handles remove_mpcc being NULL just fine so initialize
> it to NULL at the beginning of the function so it is never used
> uninitialized.
>
> Fixes: ff7e396f822f ("drm/amd/display: add cyan_skillfish display support")
> Link: https://github.com/ClangBuiltLinux/linux/issues/1469
> Signed-off-by: Nathan Chancellor
> ---
> drivers/gpu/drm/amd/display/dc/dcn201/dcn201_hwseq.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dcn201/dcn201_hwseq.c
> b/drivers/gpu/drm/amd/display/dc/dcn201/dcn201_hwseq.c
> index ceaaeeb8f2de..cfd09b3f705e 100644
> --- a/drivers/gpu/drm/amd/display/dc/dcn201/dcn201_hwseq.c
> +++ b/drivers/gpu/drm/amd/display/dc/dcn201/dcn201_hwseq.c
> @@ -439,7 +439,7 @@ void dcn201_update_mpcc(struct dc *dc, struct pipe_ctx
> *pipe_ctx)
> bool per_pixel_alpha = pipe_ctx->plane_state->per_pixel_alpha &&
> pipe_ctx->bottom_pipe;
> int mpcc_id, dpp_id;
> struct mpcc *new_mpcc;
> - struct mpcc *remove_mpcc;
> + struct mpcc *remove_mpcc = NULL;
> struct mpc *mpc = dc->res_pool->mpc;
> struct mpc_tree *mpc_tree_params =
> &(pipe_ctx->stream_res.opp->mpc_tree_params);
>
>
> base-commit: 30fc33064c846df29888c3c61e30a064aad3a342
> --
> 2.33.0.591.gddb1055343
>
[RFC 5/6] drm/i915: Keep track of registered clients indexed by task struct
From: Tvrtko Ursulin
A simple hash table of registered clients indexed by the task struct
pointer is kept to be used in a following patch.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 2 ++
drivers/gpu/drm/i915/i915_drm_client.c | 31 -
drivers/gpu/drm/i915/i915_drm_client.h | 13 +
3 files changed, 45 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index d1992ba59ed8..8d4d687ab1d0 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1932,6 +1932,8 @@ int i915_gem_context_create_ioctl(struct drm_device *dev,
void *data,
return -EIO;
}
+ i915_drm_client_update_owner(ext_data.fpriv->client, current);
+
ext_data.pc = proto_context_create(i915, args->flags);
if (IS_ERR(ext_data.pc))
return PTR_ERR(ext_data.pc);
diff --git a/drivers/gpu/drm/i915/i915_drm_client.c
b/drivers/gpu/drm/i915/i915_drm_client.c
index 91a8559bebf7..82b9636482ef 100644
--- a/drivers/gpu/drm/i915/i915_drm_client.c
+++ b/drivers/gpu/drm/i915/i915_drm_client.c
@@ -18,6 +18,9 @@ void i915_drm_clients_init(struct i915_drm_clients *clients,
clients->next_id = 0;
xa_init_flags(&clients->xarray, XA_FLAGS_ALLOC | XA_FLAGS_LOCK_IRQ);
+
+ rwlock_init(&clients->lock);
+ hash_init(clients->tasks);
}
struct i915_drm_client *i915_drm_client_add(struct i915_drm_clients *clients)
@@ -42,6 +45,8 @@ struct i915_drm_client *i915_drm_client_add(struct
i915_drm_clients *clients)
INIT_LIST_HEAD(&client->ctx_list);
client->clients = clients;
+ i915_drm_client_update_owner(client, current);
+
return client;
err:
@@ -54,9 +59,14 @@ void __i915_drm_client_free(struct kref *kref)
{
struct i915_drm_client *client =
container_of(kref, typeof(*client), kref);
- struct xarray *xa = &client->clients->xarray;
+ struct i915_drm_clients *clients = client->clients;
+ struct xarray *xa = &clients->xarray;
unsigned long flags;
+ write_lock(&clients->lock);
+ hash_del(&client->node);
+ write_unlock(&clients->lock);
+
xa_lock_irqsave(xa, flags);
__xa_erase(xa, client->id);
xa_unlock_irqrestore(xa, flags);
@@ -68,3 +78,22 @@ void i915_drm_clients_fini(struct i915_drm_clients *clients)
GEM_BUG_ON(!xa_empty(&clients->xarray));
xa_destroy(&clients->xarray);
}
+
+void i915_drm_client_update_owner(struct i915_drm_client *client,
+ struct task_struct *owner)
+{
+ struct i915_drm_clients *clients;
+
+ if (READ_ONCE(client->owner) == owner)
+ return;
+
+ clients = client->clients;
+ write_lock(&clients->lock);
+ if (READ_ONCE(client->owner) != owner) {
+ if (client->owner)
+ hash_del(&client->node);
+ client->owner = owner;
+ hash_add(clients->tasks, &client->node, (uintptr_t)owner);
+ }
+ write_unlock(&clients->lock);
+}
diff --git a/drivers/gpu/drm/i915/i915_drm_client.h
b/drivers/gpu/drm/i915/i915_drm_client.h
index 0207dfad4568..42fd79f0558a 100644
--- a/drivers/gpu/drm/i915/i915_drm_client.h
+++ b/drivers/gpu/drm/i915/i915_drm_client.h
@@ -6,8 +6,11 @@
#ifndef __I915_DRM_CLIENT_H__
#define __I915_DRM_CLIENT_H__
+#include
#include
#include
+#include
+#include
#include
#include
@@ -18,6 +21,9 @@ struct i915_drm_clients {
struct xarray xarray;
u32 next_id;
+
+ rwlock_t lock;
+ DECLARE_HASHTABLE(tasks, 6);
};
struct i915_drm_client {
@@ -28,6 +34,9 @@ struct i915_drm_client {
spinlock_t ctx_lock; /* For add/remove from ctx_list. */
struct list_head ctx_list; /* List of contexts belonging to client. */
+ struct task_struct *owner; /* No reference kept, never dereferenced. */
+ struct hlist_node node;
+
struct i915_drm_clients *clients;
};
@@ -52,4 +61,8 @@ struct i915_drm_client *i915_drm_client_add(struct
i915_drm_clients *clients);
void i915_drm_clients_fini(struct i915_drm_clients *clients);
+void i915_drm_client_update_owner(struct i915_drm_client *client,
+ struct task_struct *owner);
+
+
#endif /* !__I915_DRM_CLIENT_H__ */
--
2.30.2
[RFC 4/6] drm/i915: Track all user contexts per client
From: Tvrtko Ursulin
We soon want to start answering questions like how much GPU time is the
context belonging to a client which exited still using.
To enable this we start tracking all context belonging to a client on a
separate list.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Aravind Iddamsetty
Reviewed-by: Chris Wilson
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 12
drivers/gpu/drm/i915/gem/i915_gem_context_types.h | 3 +++
drivers/gpu/drm/i915/i915_drm_client.c| 2 ++
drivers/gpu/drm/i915/i915_drm_client.h| 5 +
4 files changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 9296d69681d7..d1992ba59ed8 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1169,6 +1169,7 @@ static void set_closed_name(struct i915_gem_context *ctx)
static void context_close(struct i915_gem_context *ctx)
{
+ struct i915_drm_client *client;
struct i915_address_space *vm;
/* Flush any concurrent set_engines() */
@@ -1205,6 +1206,13 @@ static void context_close(struct i915_gem_context *ctx)
list_del(&ctx->link);
spin_unlock(&ctx->i915->gem.contexts.lock);
+ client = ctx->client;
+ if (client) {
+ spin_lock(&client->ctx_lock);
+ list_del_rcu(&ctx->client_link);
+ spin_unlock(&client->ctx_lock);
+ }
+
mutex_unlock(&ctx->mutex);
/*
@@ -1385,6 +1393,10 @@ static void gem_context_register(struct i915_gem_context
*ctx,
old = xa_store(&fpriv->context_xa, id, ctx, GFP_KERNEL);
WARN_ON(old);
+ spin_lock(&ctx->client->ctx_lock);
+ list_add_tail_rcu(&ctx->client_link, &ctx->client->ctx_list);
+ spin_unlock(&ctx->client->ctx_lock);
+
spin_lock(&i915->gem.contexts.lock);
list_add_tail(&ctx->link, &i915->gem.contexts.list);
spin_unlock(&i915->gem.contexts.lock);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
index 598c57ac5cdf..b878e1b13b38 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
@@ -280,6 +280,9 @@ struct i915_gem_context {
/** @client: struct i915_drm_client */
struct i915_drm_client *client;
+ /** link: &drm_client.context_list */
+ struct list_head client_link;
+
/**
* @ref: reference count
*
diff --git a/drivers/gpu/drm/i915/i915_drm_client.c
b/drivers/gpu/drm/i915/i915_drm_client.c
index e61e9ba15256..91a8559bebf7 100644
--- a/drivers/gpu/drm/i915/i915_drm_client.c
+++ b/drivers/gpu/drm/i915/i915_drm_client.c
@@ -38,6 +38,8 @@ struct i915_drm_client *i915_drm_client_add(struct
i915_drm_clients *clients)
goto err;
kref_init(&client->kref);
+ spin_lock_init(&client->ctx_lock);
+ INIT_LIST_HEAD(&client->ctx_list);
client->clients = clients;
return client;
diff --git a/drivers/gpu/drm/i915/i915_drm_client.h
b/drivers/gpu/drm/i915/i915_drm_client.h
index e8986ad51176..0207dfad4568 100644
--- a/drivers/gpu/drm/i915/i915_drm_client.h
+++ b/drivers/gpu/drm/i915/i915_drm_client.h
@@ -7,6 +7,8 @@
#define __I915_DRM_CLIENT_H__
#include
+#include
+#include
#include
struct drm_i915_private;
@@ -23,6 +25,9 @@ struct i915_drm_client {
unsigned int id;
+ spinlock_t ctx_lock; /* For add/remove from ctx_list. */
+ struct list_head ctx_list; /* List of contexts belonging to client. */
+
struct i915_drm_clients *clients;
};
--
2.30.2
[RFC 2/6] drm/i915: Explicitly track DRM clients
From: Tvrtko Ursulin
Tracking DRM clients more explicitly will allow later patches to
accumulate past and current GPU usage in a centralised place and also
consolidate access to owning task pid/name.
Unique client id is also assigned for the purpose of distinguishing/
consolidating between multiple file descriptors owned by the same process.
v2:
Chris Wilson:
* Enclose new members into dedicated structs.
* Protect against failed sysfs registration.
v3:
* sysfs_attr_init.
v4:
* Fix for internal clients.
v5:
* Use cyclic ida for client id. (Chris)
* Do not leak pid reference. (Chris)
* Tidy code with some locals.
v6:
* Use xa_alloc_cyclic to simplify locking. (Chris)
* No need to unregister individial sysfs files. (Chris)
* Rebase on top of fpriv kref.
* Track client closed status and reflect in sysfs.
v7:
* Make drm_client more standalone concept.
v8:
* Simplify sysfs show. (Chris)
* Always track name and pid.
v9:
* Fix cyclic id assignment.
v10:
* No need for a mutex around xa_alloc_cyclic.
* Refactor sysfs into own function.
* Unregister sysfs before freeing pid and name.
* Move clients setup into own function.
v11:
* Call clients init directly from driver init. (Chris)
v12:
* Do not fail client add on id wrap. (Maciej)
v13 (Lucas): Rebase.
v14:
* Dropped sysfs bits.
v15:
* Dropped tracking of pid/ and name.
* Dropped RCU freeing of the client object.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson # v11
Reviewed-by: Aravind Iddamsetty # v11
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/Makefile | 5 +-
drivers/gpu/drm/i915/i915_drm_client.c | 68 ++
drivers/gpu/drm/i915/i915_drm_client.h | 50 +++
drivers/gpu/drm/i915/i915_drv.c| 6 +++
drivers/gpu/drm/i915/i915_drv.h| 5 ++
drivers/gpu/drm/i915/i915_gem.c| 21 ++--
6 files changed, 150 insertions(+), 5 deletions(-)
create mode 100644 drivers/gpu/drm/i915/i915_drm_client.c
create mode 100644 drivers/gpu/drm/i915/i915_drm_client.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 5c8e022a7383..005b5df425a1 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -32,8 +32,9 @@ subdir-ccflags-y += -I$(srctree)/$(src)
# Please keep these build lists sorted!
# core driver code
-i915-y += i915_drv.o \
- i915_config.o \
+i915-y += i915_config.o \
+ i915_drm_client.o \
+ i915_drv.o \
i915_irq.o \
i915_getparam.o \
i915_mitigations.o \
diff --git a/drivers/gpu/drm/i915/i915_drm_client.c
b/drivers/gpu/drm/i915/i915_drm_client.c
new file mode 100644
index ..e61e9ba15256
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_drm_client.c
@@ -0,0 +1,68 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2020 Intel Corporation
+ */
+
+#include
+#include
+#include
+
+#include "i915_drm_client.h"
+#include "i915_gem.h"
+#include "i915_utils.h"
+
+void i915_drm_clients_init(struct i915_drm_clients *clients,
+ struct drm_i915_private *i915)
+{
+ clients->i915 = i915;
+ clients->next_id = 0;
+
+ xa_init_flags(&clients->xarray, XA_FLAGS_ALLOC | XA_FLAGS_LOCK_IRQ);
+}
+
+struct i915_drm_client *i915_drm_client_add(struct i915_drm_clients *clients)
+{
+ struct i915_drm_client *client;
+ struct xarray *xa = &clients->xarray;
+ int ret;
+
+ client = kzalloc(sizeof(*client), GFP_KERNEL);
+ if (!client)
+ return ERR_PTR(-ENOMEM);
+
+ xa_lock_irq(xa);
+ ret = __xa_alloc_cyclic(xa, &client->id, client, xa_limit_32b,
+ &clients->next_id, GFP_KERNEL);
+ xa_unlock_irq(xa);
+ if (ret < 0)
+ goto err;
+
+ kref_init(&client->kref);
+ client->clients = clients;
+
+ return client;
+
+err:
+ kfree(client);
+
+ return ERR_PTR(ret);
+}
+
+void __i915_drm_client_free(struct kref *kref)
+{
+ struct i915_drm_client *client =
+ container_of(kref, typeof(*client), kref);
+ struct xarray *xa = &client->clients->xarray;
+ unsigned long flags;
+
+ xa_lock_irqsave(xa, flags);
+ __xa_erase(xa, client->id);
+ xa_unlock_irqrestore(xa, flags);
+ kfree(client);
+}
+
+void i915_drm_clients_fini(struct i915_drm_clients *clients)
+{
+ GEM_BUG_ON(!xa_empty(&clients->xarray));
+ xa_destroy(&clients->xarray);
+}
diff --git a/drivers/gpu/drm/i915/i915_drm_client.h
b/drivers/gpu/drm/i915/i915_drm_client.h
new file mode 100644
index ..e8986ad51176
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_drm_client.h
@@ -0,0 +1,50 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2020 Intel Corporation
+ */
+
+#ifndef __I915_DRM_CLIENT_H__
+#define __I915_DRM_CLIENT_H__
+
+#include
+#include
+
+struct drm_i915_private;
+
+struct i915_drm_clients {
+ struct drm_i915_private *i915;
+
[RFC 1/6] sched: Add nice value change notifier
From: Tvrtko Ursulin
Implement a simple notifier chain via which interested parties can track
when process nice value changes. Simple because it is global so each user
would have to track which tasks it is interested in.
To use register_user_nice_notifier and unregister_user_nice_notifier
functions are provided and new nice value and pointer to task_struct
being modified passed to the callbacks.
Opens:
* Security. Would some sort of a per process mechanism be better and
feasible?
* Put it all behind kconfig to be selected by interested drivers?
Signed-off-by: Tvrtko Ursulin
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Juri Lelli
Cc: Vincent Guittot
---
include/linux/sched.h | 5 +
kernel/sched/core.c | 37 -
2 files changed, 41 insertions(+), 1 deletion(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 39039ce8ac4c..45ae9eca38c6 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -2309,4 +2309,9 @@ static inline void sched_core_free(struct task_struct
*tsk) { }
static inline void sched_core_fork(struct task_struct *p) { }
#endif
+struct notifier_block;
+
+extern int register_user_nice_notifier(struct notifier_block *);
+extern int unregister_user_nice_notifier(struct notifier_block *);
+
#endif
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 1bba4128a3e6..26ff75d6fe00 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -6864,10 +6864,42 @@ static inline int rt_effective_prio(struct task_struct
*p, int prio)
}
#endif
+ATOMIC_NOTIFIER_HEAD(user_nice_notifier_list);
+
+/**
+ * register_user_nice_notifier - Register function to be called when task nice
changes
+ * @nb: Info about notifier function to be called
+ *
+ * Registers a function with the list of functions to be called when task nice
+ * value changes.
+ *
+ * Currently always returns zero, as atomic_notifier_chain_register()
+ * always returns zero.
+ */
+int register_user_nice_notifier(struct notifier_block *nb)
+{
+ return atomic_notifier_chain_register(&user_nice_notifier_list, nb);
+}
+EXPORT_SYMBOL(register_user_nice_notifier);
+
+/**
+ * unregister_user_nice_notifier - Unregister previously registered user nice
notifier
+ * @nb: Hook to be unregistered
+ *
+ * Unregisters a previously registered user nice notifier function.
+ *
+ * Returns zero on success, or %-ENOENT on failure.
+ */
+int unregister_user_nice_notifier(struct notifier_block *nb)
+{
+ return atomic_notifier_chain_unregister(&user_nice_notifier_list, nb);
+}
+EXPORT_SYMBOL(unregister_user_nice_notifier);
+
void set_user_nice(struct task_struct *p, long nice)
{
bool queued, running;
- int old_prio;
+ int old_prio, ret;
struct rq_flags rf;
struct rq *rq;
@@ -6913,6 +6945,9 @@ void set_user_nice(struct task_struct *p, long nice)
*/
p->sched_class->prio_changed(rq, p, old_prio);
+ ret = atomic_notifier_call_chain(&user_nice_notifier_list, nice, p);
+ WARN_ON_ONCE(ret != NOTIFY_DONE);
+
out_unlock:
task_rq_unlock(rq, p, &rf);
}
--
2.30.2
[RFC 3/6] drm/i915: Make GEM contexts track DRM clients
From: Tvrtko Ursulin
Make GEM contexts keep a reference to i915_drm_client for the whole of
of their lifetime which will come handy in following patches.
v2: Don't bother supporting selftests contexts from debugfs. (Chris)
v3 (Lucas): Finish constructing ctx before adding it to the list
v4 (Ram): Rebase.
v5: Trivial rebase for proto ctx changes.
v6: Rebase after clients no longer track name and pid.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson # v5
Reviewed-by: Aravind Iddamsetty # v5
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 5 +
drivers/gpu/drm/i915/gem/i915_gem_context_types.h | 3 +++
2 files changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 8208fd5b72c3..9296d69681d7 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -956,6 +956,9 @@ static void i915_gem_context_release_work(struct
work_struct *work)
if (vm)
i915_vm_put(vm);
+ if (ctx->client)
+ i915_drm_client_put(ctx->client);
+
mutex_destroy(&ctx->engines_mutex);
mutex_destroy(&ctx->lut_mutex);
@@ -1373,6 +1376,8 @@ static void gem_context_register(struct i915_gem_context
*ctx,
ctx->file_priv = fpriv;
ctx->pid = get_task_pid(current, PIDTYPE_PID);
+ ctx->client = i915_drm_client_get(fpriv->client);
+
snprintf(ctx->name, sizeof(ctx->name), "%s[%d]",
current->comm, pid_nr(ctx->pid));
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
index c4617e4d9fa9..598c57ac5cdf 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
@@ -277,6 +277,9 @@ struct i915_gem_context {
/** @link: place with &drm_i915_private.context_list */
struct list_head link;
+ /** @client: struct i915_drm_client */
+ struct i915_drm_client *client;
+
/**
* @ref: reference count
*
--
2.30.2
[RFC 0/6] CPU + GPU synchronised priority scheduling
From: Tvrtko Ursulin This is a somewhat early sketch of one of my ideas intended for early feedback from the core scheduler experts. First and last two patches in the series are the most interesting ones for people outside of i915. (Note I did not copy everyone on all patches but just the cover letter for context and the rest should be available from the mailing list.) General idea is that current processing landscape seems to be more and more composed of pipelines where computations are done on multiple hardware devices. Furthermore some of the non-CPU devices, like in this case many GPUs supported by the i915 driver, actually support priority based scheduling which is currently rather inaccesible to the user (in terms of being able to control it from the outside). >From these two statements a question arises on how to allow for a simple, effective and consolidated user experience. In other words why user would not be able to do something like: $ nice ffmmpeg ...transcode my videos... $ my-favourite-game And have the nice hint apply to GPU parts of the transcode pipeline as well? Another reason why I started thinking about this is that I noticed Chrome browser for instance uses nice to de-prioritise background tabs. So again, having that decision propagate to the GPU rendering pipeline sounds like a big plus to the overall user experience. This RFC implements this idea with the hairy part being the notifier chain I added to enable dynamic adjustments. It is a global notifier which raises a few questions so I am very curious what experts will think here. Please see the opens in the first patch for more on this. And also the last two patches are the ones which implement a hash table in i915 so it can associate the notifier call- back with the correct GPU rendering contexts. On a more positive note the thing seems to even work as is. For instance I roughly simulated the above scenario by running a GPU hog at three nice levels and a GfxBench TRex in parallel (as a game proxy). This is what I got: GPU hog nice | TRex fps -- 0 | 34.8 10 | 38.0 -10 | 30.8 So it is visible the feature can improve the user experience. Question is just if people are happy with this method of implementing it. Cc: Ingo Molnar Cc: Peter Zijlstra Cc: Juri Lelli Cc: Vincent Guittot Tvrtko Ursulin (6): sched: Add nice value change notifier drm/i915: Explicitly track DRM clients drm/i915: Make GEM contexts track DRM clients drm/i915: Track all user contexts per client drm/i915: Keep track of registered clients indexed by task struct drm/i915: Connect task and GPU scheduling priorities drivers/gpu/drm/i915/Makefile | 5 +- drivers/gpu/drm/i915/gem/i915_gem_context.c | 20 +++ .../gpu/drm/i915/gem/i915_gem_context_types.h | 6 + .../drm/i915/gt/intel_execlists_submission.c | 2 +- drivers/gpu/drm/i915/i915_drm_client.c| 129 ++ drivers/gpu/drm/i915/i915_drm_client.h| 71 ++ drivers/gpu/drm/i915/i915_drv.c | 6 + drivers/gpu/drm/i915/i915_drv.h | 5 + drivers/gpu/drm/i915/i915_gem.c | 21 ++- drivers/gpu/drm/i915/i915_request.c | 2 +- drivers/gpu/drm/i915/i915_request.h | 5 + drivers/gpu/drm/i915/i915_scheduler.c | 3 +- drivers/gpu/drm/i915/i915_scheduler.h | 14 ++ drivers/gpu/drm/i915/i915_scheduler_types.h | 8 ++ include/linux/sched.h | 5 + kernel/sched/core.c | 37 - 16 files changed, 330 insertions(+), 9 deletions(-) create mode 100644 drivers/gpu/drm/i915/i915_drm_client.c create mode 100644 drivers/gpu/drm/i915/i915_drm_client.h -- 2.30.2
[RFC 6/6] drm/i915: Connect task and GPU scheduling priorities
From: Tvrtko Ursulin
Introduce the concept of context nice value which exactly matches the
process nice, and also make use of the task user nice notifier chain to be
able to dynamically adjust GPU scheduling. Apart from runtime adjustments
context also inherits the nice value when created.
Context nice is utilised secondary to context priority, only when the
latter has been left at the default setting, in order to avoid disturbing
any application made choices of low and high (batch processing and maybe
latency sensitive compositing). In those cases nice value adjusts the
effective priority in the narrow band of -19 to +20 around
I915_CONTEXT_DEFAULT_PRIORITY.
Opens:
* The [-19, +20] range should work well with GuC scheduling since it
effectively translates to three available buckets there, but should
it perhaps be streched to cover the full [-1023, +1023] range?
* Current implementation only has the nice apply to future submissions
against the context. Is it worth dealing with already submitted work?
I opted to avoid the complication since benefit seems marginal outside
of the endless compute workloads (which would probably start up with
the correct priority).
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 1 +
.../drm/i915/gt/intel_execlists_submission.c | 2 +-
drivers/gpu/drm/i915/i915_drm_client.c| 38 +--
drivers/gpu/drm/i915/i915_drm_client.h| 3 ++
drivers/gpu/drm/i915/i915_request.c | 2 +-
drivers/gpu/drm/i915/i915_request.h | 5 +++
drivers/gpu/drm/i915/i915_scheduler.c | 3 +-
drivers/gpu/drm/i915/i915_scheduler.h | 14 +++
drivers/gpu/drm/i915/i915_scheduler_types.h | 8
9 files changed, 69 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 8d4d687ab1d0..fed0733cb652 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -257,6 +257,7 @@ proto_context_create(struct drm_i915_private *i915,
unsigned int flags)
if (i915->params.enable_hangcheck)
pc->user_flags |= BIT(UCONTEXT_PERSISTENCE);
pc->sched.priority = I915_PRIORITY_NORMAL;
+ pc->sched.nice = task_nice(current);
if (flags & I915_CONTEXT_CREATE_FLAGS_SINGLE_TIMELINE) {
if (!HAS_EXECLISTS(i915)) {
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index 7147fe80919e..13c41f1f8ba5 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -250,7 +250,7 @@ static struct i915_priolist *to_priolist(struct rb_node *rb)
static int rq_prio(const struct i915_request *rq)
{
- return READ_ONCE(rq->sched.attr.priority);
+ return i915_request_priority(rq);
}
static int effective_prio(const struct i915_request *rq)
diff --git a/drivers/gpu/drm/i915/i915_drm_client.c
b/drivers/gpu/drm/i915/i915_drm_client.c
index 82b9636482ef..13ac2311eb84 100644
--- a/drivers/gpu/drm/i915/i915_drm_client.c
+++ b/drivers/gpu/drm/i915/i915_drm_client.c
@@ -8,9 +8,33 @@
#include
#include "i915_drm_client.h"
+#include "gem/i915_gem_context.h"
#include "i915_gem.h"
#include "i915_utils.h"
+static int
+clients_notify(struct notifier_block *nb, unsigned long val, void *ptr)
+{
+ struct i915_drm_clients *clients =
+ container_of(nb, typeof(*clients), prio_notifier);
+ struct i915_drm_client *client;
+ unsigned long flags;
+
+ read_lock_irqsave(&clients->lock, flags);
+ hash_for_each_possible(clients->tasks, client, node, (uintptr_t)ptr) {
+ struct i915_gem_context *ctx;
+
+ if (client->owner != ptr)
+ continue;
+
+ list_for_each_entry_rcu(ctx, &client->ctx_list, client_link)
+ ctx->sched.nice = (int)val;
+ }
+ read_unlock_irqrestore(&clients->lock, flags);
+
+ return NOTIFY_DONE;
+}
+
void i915_drm_clients_init(struct i915_drm_clients *clients,
struct drm_i915_private *i915)
{
@@ -21,6 +45,10 @@ void i915_drm_clients_init(struct i915_drm_clients *clients,
rwlock_init(&clients->lock);
hash_init(clients->tasks);
+
+ memset(&clients->prio_notifier, 0, sizeof(clients->prio_notifier));
+ clients->prio_notifier.notifier_call = clients_notify;
+ register_user_nice_notifier(&clients->prio_notifier);
}
struct i915_drm_client *i915_drm_client_add(struct i915_drm_clients *clients)
@@ -63,9 +91,9 @@ void __i915_drm_client_free(struct kref *kref)
struct xarray *xa = &clients->xarray;
unsigned long flags;
- write_lock(&clients->lock);
+ write_lock_irq(&clients->lock);
hash_del(&client->node);
- write_unlock(&clients->
Re: [PATCH] drm/amd: Return NULL instead of false in dcn201_acquire_idle_pipe_for_layer()
Applied. Thanks!
Alex
On Thu, Sep 30, 2021 at 12:23 PM Nathan Chancellor wrote:
>
> Clang warns:
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/dcn201/dcn201_resource.c:1017:10:
> error: expression which evaluates to zero treated as a null pointer constant
> of type 'struct pipe_ctx *' [-Werror,-Wnon-literal-null-conversion]
> return false;
>^
> 1 error generated.
>
> Use NULL instead of false since the function is returning a pointer
> rather than a boolean.
>
> Fixes: ff7e396f822f ("drm/amd/display: add cyan_skillfish display support")
> Link: https://github.com/ClangBuiltLinux/linux/issues/1470
> Signed-off-by: Nathan Chancellor
> ---
> drivers/gpu/drm/amd/display/dc/dcn201/dcn201_resource.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dcn201/dcn201_resource.c
> b/drivers/gpu/drm/amd/display/dc/dcn201/dcn201_resource.c
> index aec276e1db65..8523a048e6f6 100644
> --- a/drivers/gpu/drm/amd/display/dc/dcn201/dcn201_resource.c
> +++ b/drivers/gpu/drm/amd/display/dc/dcn201/dcn201_resource.c
> @@ -1014,7 +1014,7 @@ static struct pipe_ctx
> *dcn201_acquire_idle_pipe_for_layer(
> ASSERT(0);
>
> if (!idle_pipe)
> - return false;
> + return NULL;
>
> idle_pipe->stream = head_pipe->stream;
> idle_pipe->stream_res.tg = head_pipe->stream_res.tg;
>
> base-commit: b47b99e30cca8906753c83205e8c6179045dd725
> --
> 2.33.0.591.gddb1055343
>
Re: [PATCH V4 2/2] drm/bridge: lvds-codec: Add support for LVDS data mapping select
On 7/27/21 6:13 PM, Marek Vasut wrote:
Decoder input LVDS format is a property of the decoder chip or even
its strapping. Handle data-mapping the same way lvds-panel does. In
case data-mapping is not present, do nothing, since there are still
legacy bindings which do not specify this property.
Signed-off-by: Marek Vasut
Cc: Laurent Pinchart
Cc: Sam Ravnborg
To: dri-devel@lists.freedesktop.org
---
V2: - Move the data-mapping to endpoint
V3: - Rebase on V2 submitted a while ago, reinstate changelog
- Use .atomic_get_input_bus_fmts for the decoder, separate funcs for
encoder
V4: - No change
---
drivers/gpu/drm/bridge/lvds-codec.c | 76 -
1 file changed, 75 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/lvds-codec.c
b/drivers/gpu/drm/bridge/lvds-codec.c
index dcf579a4cf833..afa7ce7ea01e8 100644
--- a/drivers/gpu/drm/bridge/lvds-codec.c
+++ b/drivers/gpu/drm/bridge/lvds-codec.c
@@ -12,6 +12,7 @@
#include
#include
+#include
#include
#include
@@ -22,6 +23,7 @@ struct lvds_codec {
struct regulator *vcc;
struct gpio_desc *powerdown_gpio;
u32 connector_type;
+ unsigned int bus_format;
};
static inline struct lvds_codec *to_lvds_codec(struct drm_bridge *bridge)
@@ -74,12 +76,50 @@ static const struct drm_bridge_funcs funcs = {
.disable = lvds_codec_disable,
};
+#define MAX_INPUT_SEL_FORMATS 1
+static u32 *
+lvds_codec_atomic_get_input_bus_fmts(struct drm_bridge *bridge,
+struct drm_bridge_state *bridge_state,
+struct drm_crtc_state *crtc_state,
+struct drm_connector_state *conn_state,
+u32 output_fmt,
+unsigned int *num_input_fmts)
+{
+ struct lvds_codec *lvds_codec = to_lvds_codec(bridge);
+ u32 *input_fmts;
+
+ *num_input_fmts = 0;
+
+ input_fmts = kcalloc(MAX_INPUT_SEL_FORMATS, sizeof(*input_fmts),
+GFP_KERNEL);
+ if (!input_fmts)
+ return NULL;
+
+ input_fmts[0] = lvds_codec->bus_format;
+ *num_input_fmts = MAX_INPUT_SEL_FORMATS;
+
+ return input_fmts;
+}
+
+static const struct drm_bridge_funcs funcs_decoder = {
+ .attach = lvds_codec_attach,
+ .enable = lvds_codec_enable,
+ .disable = lvds_codec_disable,
+ .atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
+ .atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
+ .atomic_reset = drm_atomic_helper_bridge_reset,
+ .atomic_get_input_bus_fmts = lvds_codec_atomic_get_input_bus_fmts,
+};
+
static int lvds_codec_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
struct device_node *panel_node;
+ struct device_node *bus_node;
struct drm_panel *panel;
struct lvds_codec *lvds_codec;
+ const char *mapping;
+ int ret;
lvds_codec = devm_kzalloc(dev, sizeof(*lvds_codec), GFP_KERNEL);
if (!lvds_codec)
@@ -119,13 +159,47 @@ static int lvds_codec_probe(struct platform_device *pdev)
if (IS_ERR(lvds_codec->panel_bridge))
return PTR_ERR(lvds_codec->panel_bridge);
+ lvds_codec->bridge.funcs = &funcs;
+
+ /*
+* Decoder input LVDS format is a property of the decoder chip or even
+* its strapping. Handle data-mapping the same way lvds-panel does. In
+* case data-mapping is not present, do nothing, since there are still
+* legacy bindings which do not specify this property.
+*/
+ if (lvds_codec->connector_type != DRM_MODE_CONNECTOR_LVDS) {
+ bus_node = of_graph_get_endpoint_by_regs(dev->of_node, 1, 0);
+ if (!bus_node) {
+ dev_dbg(dev, "bus DT node not found\n");
+ return -ENXIO;
+ }
+
+ ret = of_property_read_string(bus_node, "data-mapping",
+ &mapping);
+ of_node_put(bus_node);
+ if (ret < 0) {
+ dev_err(dev, "missing 'data-mapping' DT property\n");
+ } else {
+ if (!strcmp(mapping, "jeida-18")) {
+ lvds_codec->bus_format =
MEDIA_BUS_FMT_RGB666_1X7X3_SPWG;
+ } else if (!strcmp(mapping, "jeida-24")) {
+ lvds_codec->bus_format =
MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA;
+ } else if (!strcmp(mapping, "vesa-24")) {
+ lvds_codec->bus_format =
MEDIA_BUS_FMT_RGB888_1X7X4_SPWG;
+ } else {
+ dev_err(dev, "invalid 'data-mapping' DT
property\n");
+ return -EINVAL;
+ }
+ lvds_codec->bridg
Re: [PATCH v2 4/4] drm/v3d: add multiple syncobjs support
On 09/30, Melissa Wen wrote:
> On 09/30, Iago Toral wrote:
> > On Wed, 2021-09-29 at 10:45 +0100, Melissa Wen wrote:
> > > Using the generic extension from the previous patch, a specific
> > > multisync
> > > extension enables more than one in/out binary syncobj per job
> > > submission.
> > > Arrays of syncobjs are set in struct drm_v3d_multisync, that also
> > > cares
> > > of determining the stage for sync (wait deps) according to the job
> > > queue.
> > >
> > > v2:
> > > - subclass the generic extension struct (Daniel)
> > > - simplify adding dependency conditions to make understandable (Iago)
> > >
> > > Signed-off-by: Melissa Wen
> > > ---
> > > drivers/gpu/drm/v3d/v3d_drv.c | 6 +-
> > > drivers/gpu/drm/v3d/v3d_drv.h | 23 +++--
> > > drivers/gpu/drm/v3d/v3d_gem.c | 176 ++
> > >
> > > include/uapi/drm/v3d_drm.h| 49 +-
> > > 4 files changed, 224 insertions(+), 30 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/v3d/v3d_drv.c
> > > b/drivers/gpu/drm/v3d/v3d_drv.c
> > > index 3d6b9bcce2f7..bd46396a1ae0 100644
> > > --- a/drivers/gpu/drm/v3d/v3d_drv.c
> > > +++ b/drivers/gpu/drm/v3d/v3d_drv.c
> > > @@ -96,6 +96,9 @@ static int v3d_get_param_ioctl(struct drm_device
> > > *dev, void *data,
> > > case DRM_V3D_PARAM_SUPPORTS_PERFMON:
> > > args->value = (v3d->ver >= 40);
> > > return 0;
> > > + case DRM_V3D_PARAM_SUPPORTS_MULTISYNC_EXT:
> > > + args->value = 1;
> > > + return 0;
> > > default:
> > > DRM_DEBUG("Unknown parameter %d\n", args->param);
> > > return -EINVAL;
> > > @@ -135,9 +138,8 @@ v3d_postclose(struct drm_device *dev, struct
> > > drm_file *file)
> > > struct v3d_file_priv *v3d_priv = file->driver_priv;
> > > enum v3d_queue q;
> > >
> > > - for (q = 0; q < V3D_MAX_QUEUES; q++) {
> > > + for (q = 0; q < V3D_MAX_QUEUES; q++)
> > > drm_sched_entity_destroy(&v3d_priv->sched_entity[q]);
> > > - }
> > >
> > > v3d_perfmon_close_file(v3d_priv);
> > > kfree(v3d_priv);
> > > diff --git a/drivers/gpu/drm/v3d/v3d_drv.h
> > > b/drivers/gpu/drm/v3d/v3d_drv.h
> > > index b900a050d5e2..b14ff1e96f49 100644
> > > --- a/drivers/gpu/drm/v3d/v3d_drv.h
> > > +++ b/drivers/gpu/drm/v3d/v3d_drv.h
> > > @@ -19,15 +19,6 @@ struct reset_control;
> > >
> > > #define GMP_GRANULARITY (128 * 1024)
> > >
> > > -/* Enum for each of the V3D queues. */
> > > -enum v3d_queue {
> > > - V3D_BIN,
> > > - V3D_RENDER,
> > > - V3D_TFU,
> > > - V3D_CSD,
> > > - V3D_CACHE_CLEAN,
> > > -};
> > > -
> > > #define V3D_MAX_QUEUES (V3D_CACHE_CLEAN + 1)
> > >
> > > struct v3d_queue_state {
> > > @@ -294,6 +285,20 @@ struct v3d_csd_job {
> > > struct drm_v3d_submit_csd args;
> > > };
> > >
> > > +struct v3d_submit_outsync {
> > > + struct drm_syncobj *syncobj;
> > > +};
> > > +
> > > +struct v3d_submit_ext {
> > > + u32 wait_stage;
> > > +
> > > + u32 in_sync_count;
> > > + u64 in_syncs;
> > > +
> > > + u32 out_sync_count;
> > > + struct v3d_submit_outsync *out_syncs;
> > > +};
> > > +
> > > /**
> > > * __wait_for - magic wait macro
> > > *
> > > diff --git a/drivers/gpu/drm/v3d/v3d_gem.c
> > > b/drivers/gpu/drm/v3d/v3d_gem.c
> > > index b912419027f7..e92998d39eaa 100644
> > > --- a/drivers/gpu/drm/v3d/v3d_gem.c
> > > +++ b/drivers/gpu/drm/v3d/v3d_gem.c
> > > @@ -454,11 +454,12 @@ v3d_job_add_deps(struct drm_file *file_priv,
> > > struct v3d_job *job,
> > > static int
> > > v3d_job_init(struct v3d_dev *v3d, struct drm_file *file_priv,
> > >void **container, size_t size, void (*free)(struct kref
> > > *ref),
> > > - u32 in_sync, enum v3d_queue queue)
> > > + u32 in_sync, struct v3d_submit_ext *se, enum v3d_queue
> > > queue)
> > > {
> > > struct v3d_file_priv *v3d_priv = file_priv->driver_priv;
> > > struct v3d_job *job;
> > > - int ret;
> > > + bool has_multisync = (se && se->in_sync_count);
> >
> > I think this is not correct... we could be using the multisync
> > interface and pass 0 in_syncs and/or 0 out_syncs... what should
> > determine if we take the multisync path is the presence of the
> > extension alone.
> hmm.. yeah. so, I should drop this has_multisync and change conditions
> to only check if we have a submit_ext (that means we have multisync
> support) and move the in_sync_count to check if we should add any wait
> semaphores, as below:
>
> >
> > > + int ret, i;
> > >
> > > *container = kcalloc(1, size, GFP_KERNEL);
> > > if (!*container) {
> > > @@ -479,9 +480,28 @@ v3d_job_init(struct v3d_dev *v3d, struct
> > > drm_file *file_priv,
> > > if (ret)
> > > goto fail;
> > >
> > > - ret = v3d_job_add_deps(file_priv, job, in_sync, 0);
> > > - if (ret)
> > > - goto fail_job;
> if (se) {
> if (se->in_sync_count && se->wait_stage == queue) {
never mind. I realized store extension flag on v3d_submit_ext works
better for handling multiples wait and signal semaphores.
Just sent a v3.
Thanks,
Melissa
> > >
[PATCH] drm/amd: Return NULL instead of false in dcn201_acquire_idle_pipe_for_layer()
Clang warns:
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn201/dcn201_resource.c:1017:10:
error: expression which evaluates to zero treated as a null pointer constant of
type 'struct pipe_ctx *' [-Werror,-Wnon-literal-null-conversion]
return false;
^
1 error generated.
Use NULL instead of false since the function is returning a pointer
rather than a boolean.
Fixes: ff7e396f822f ("drm/amd/display: add cyan_skillfish display support")
Link: https://github.com/ClangBuiltLinux/linux/issues/1470
Signed-off-by: Nathan Chancellor
---
drivers/gpu/drm/amd/display/dc/dcn201/dcn201_resource.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn201/dcn201_resource.c
b/drivers/gpu/drm/amd/display/dc/dcn201/dcn201_resource.c
index aec276e1db65..8523a048e6f6 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn201/dcn201_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn201/dcn201_resource.c
@@ -1014,7 +1014,7 @@ static struct pipe_ctx
*dcn201_acquire_idle_pipe_for_layer(
ASSERT(0);
if (!idle_pipe)
- return false;
+ return NULL;
idle_pipe->stream = head_pipe->stream;
idle_pipe->stream_res.tg = head_pipe->stream_res.tg;
base-commit: b47b99e30cca8906753c83205e8c6179045dd725
--
2.33.0.591.gddb1055343
[PATCH v3 4/4] drm/v3d: add multiple syncobjs support
Using the generic extension from the previous patch, a specific multisync
extension enables more than one in/out binary syncobj per job submission.
Arrays of syncobjs are set in struct drm_v3d_multisync, that also cares
of determining the stage for sync (wait deps) according to the job
queue.
v2:
- subclass the generic extension struct (Daniel)
- simplify adding dependency conditions to make understandable (Iago)
v3:
- fix conditions to consider single or multiples in/out_syncs (Iago)
- remove irrelevant comment (Iago)
Signed-off-by: Melissa Wen
---
drivers/gpu/drm/v3d/v3d_drv.c | 6 +-
drivers/gpu/drm/v3d/v3d_drv.h | 24 +++--
drivers/gpu/drm/v3d/v3d_gem.c | 185 ++
include/uapi/drm/v3d_drm.h| 49 -
4 files changed, 232 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/v3d/v3d_drv.c b/drivers/gpu/drm/v3d/v3d_drv.c
index 3d6b9bcce2f7..bd46396a1ae0 100644
--- a/drivers/gpu/drm/v3d/v3d_drv.c
+++ b/drivers/gpu/drm/v3d/v3d_drv.c
@@ -96,6 +96,9 @@ static int v3d_get_param_ioctl(struct drm_device *dev, void
*data,
case DRM_V3D_PARAM_SUPPORTS_PERFMON:
args->value = (v3d->ver >= 40);
return 0;
+ case DRM_V3D_PARAM_SUPPORTS_MULTISYNC_EXT:
+ args->value = 1;
+ return 0;
default:
DRM_DEBUG("Unknown parameter %d\n", args->param);
return -EINVAL;
@@ -135,9 +138,8 @@ v3d_postclose(struct drm_device *dev, struct drm_file *file)
struct v3d_file_priv *v3d_priv = file->driver_priv;
enum v3d_queue q;
- for (q = 0; q < V3D_MAX_QUEUES; q++) {
+ for (q = 0; q < V3D_MAX_QUEUES; q++)
drm_sched_entity_destroy(&v3d_priv->sched_entity[q]);
- }
v3d_perfmon_close_file(v3d_priv);
kfree(v3d_priv);
diff --git a/drivers/gpu/drm/v3d/v3d_drv.h b/drivers/gpu/drm/v3d/v3d_drv.h
index b900a050d5e2..b74b1351bfc8 100644
--- a/drivers/gpu/drm/v3d/v3d_drv.h
+++ b/drivers/gpu/drm/v3d/v3d_drv.h
@@ -19,15 +19,6 @@ struct reset_control;
#define GMP_GRANULARITY (128 * 1024)
-/* Enum for each of the V3D queues. */
-enum v3d_queue {
- V3D_BIN,
- V3D_RENDER,
- V3D_TFU,
- V3D_CSD,
- V3D_CACHE_CLEAN,
-};
-
#define V3D_MAX_QUEUES (V3D_CACHE_CLEAN + 1)
struct v3d_queue_state {
@@ -294,6 +285,21 @@ struct v3d_csd_job {
struct drm_v3d_submit_csd args;
};
+struct v3d_submit_outsync {
+ struct drm_syncobj *syncobj;
+};
+
+struct v3d_submit_ext {
+ u32 flags;
+ u32 wait_stage;
+
+ u32 in_sync_count;
+ u64 in_syncs;
+
+ u32 out_sync_count;
+ struct v3d_submit_outsync *out_syncs;
+};
+
/**
* __wait_for - magic wait macro
*
diff --git a/drivers/gpu/drm/v3d/v3d_gem.c b/drivers/gpu/drm/v3d/v3d_gem.c
index 93f130fb3a13..d344eae36b57 100644
--- a/drivers/gpu/drm/v3d/v3d_gem.c
+++ b/drivers/gpu/drm/v3d/v3d_gem.c
@@ -454,11 +454,12 @@ v3d_job_add_deps(struct drm_file *file_priv, struct
v3d_job *job,
static int
v3d_job_init(struct v3d_dev *v3d, struct drm_file *file_priv,
void **container, size_t size, void (*free)(struct kref *ref),
-u32 in_sync, enum v3d_queue queue)
+u32 in_sync, struct v3d_submit_ext *se, enum v3d_queue queue)
{
struct v3d_file_priv *v3d_priv = file_priv->driver_priv;
struct v3d_job *job;
- int ret;
+ bool has_multisync = se && (se->flags & DRM_V3D_EXT_ID_MULTI_SYNC);
+ int ret, i;
*container = kcalloc(1, size, GFP_KERNEL);
if (!*container) {
@@ -479,9 +480,28 @@ v3d_job_init(struct v3d_dev *v3d, struct drm_file
*file_priv,
if (ret)
goto fail_job;
- ret = v3d_job_add_deps(file_priv, job, in_sync, 0);
- if (ret)
- goto fail_deps;
+ if (has_multisync) {
+ if (se->in_sync_count && se->wait_stage == queue) {
+ struct drm_v3d_sem __user *handle =
u64_to_user_ptr(se->in_syncs);
+
+ for (i = 0; i < se->in_sync_count; i++) {
+ struct drm_v3d_sem in;
+
+ ret = copy_from_user(&in, handle++, sizeof(in));
+ if (ret) {
+ DRM_DEBUG("Failed to copy wait dep
handle.\n");
+ goto fail_deps;
+ }
+ ret = v3d_job_add_deps(file_priv, job,
in.handle, 0);
+ if (ret)
+ goto fail_deps;
+ }
+ }
+ } else {
+ ret = v3d_job_add_deps(file_priv, job, in_sync, 0);
+ if (ret)
+ goto fail_deps;
+ }
kref_init(&job->refcount);
@@ -516,9 +536,11 @@ v3d_attach_fences_and_unlock_reservation(struct drm_file
*file_priv,
[PATCH v3 3/4] drm/v3d: add generic ioctl extension
Add support to attach generic extensions on job submission. This patch
is third prep work to enable multiple syncobjs on job submission. With
this work, when the job submission interface needs to be extended to
accomodate a new feature, we will use a generic extension struct where
an id determines the data type to be pointed. The first application is
to enable multiples in/out syncobj (next patch), but the base is
already done for future features. Therefore, to attach a new feature,
a specific extension struct should subclass drm_v3d_extension and
update the list of extensions in a job submission.
v2:
- remove redundant elements to subclass struct (Daniel)
v3:
- add comment for v3d_get_extensions
Signed-off-by: Melissa Wen
---
drivers/gpu/drm/v3d/v3d_drv.c | 4 +-
drivers/gpu/drm/v3d/v3d_gem.c | 74 +--
include/uapi/drm/v3d_drm.h| 31 +++
3 files changed, 103 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/v3d/v3d_drv.c b/drivers/gpu/drm/v3d/v3d_drv.c
index c1deab2cf38d..3d6b9bcce2f7 100644
--- a/drivers/gpu/drm/v3d/v3d_drv.c
+++ b/drivers/gpu/drm/v3d/v3d_drv.c
@@ -83,7 +83,6 @@ static int v3d_get_param_ioctl(struct drm_device *dev, void
*data,
return 0;
}
-
switch (args->param) {
case DRM_V3D_PARAM_SUPPORTS_TFU:
args->value = 1;
@@ -147,7 +146,7 @@ v3d_postclose(struct drm_device *dev, struct drm_file *file)
DEFINE_DRM_GEM_FOPS(v3d_drm_fops);
/* DRM_AUTH is required on SUBMIT_CL for now, while we don't have GMP
- * protection between clients. Note that render nodes would be be
+ * protection between clients. Note that render nodes would be
* able to submit CLs that could access BOs from clients authenticated
* with the master node. The TFU doesn't use the GMP, so it would
* need to stay DRM_AUTH until we do buffer size/offset validation.
@@ -219,7 +218,6 @@ static int v3d_platform_drm_probe(struct platform_device
*pdev)
u32 mmu_debug;
u32 ident1;
-
v3d = devm_drm_dev_alloc(dev, &v3d_drm_driver, struct v3d_dev, drm);
if (IS_ERR(v3d))
return PTR_ERR(v3d);
diff --git a/drivers/gpu/drm/v3d/v3d_gem.c b/drivers/gpu/drm/v3d/v3d_gem.c
index f932e73fb5c6..93f130fb3a13 100644
--- a/drivers/gpu/drm/v3d/v3d_gem.c
+++ b/drivers/gpu/drm/v3d/v3d_gem.c
@@ -537,6 +537,36 @@ v3d_attach_fences_and_unlock_reservation(struct drm_file
*file_priv,
}
}
+/* Whenever userspace sets ioctl extensions, v3d_get_extensions parses data
+ * according to the extension id (name).
+ */
+static int
+v3d_get_extensions(struct drm_file *file_priv, u64 ext_handles)
+{
+ struct drm_v3d_extension __user *user_ext;
+
+ user_ext = u64_to_user_ptr(ext_handles);
+ while (user_ext) {
+ struct drm_v3d_extension ext;
+
+ if (copy_from_user(&ext, user_ext, sizeof(ext))) {
+ DRM_DEBUG("Failed to copy submit extension\n");
+ return -EFAULT;
+ }
+
+ switch (ext.id) {
+ case 0:
+ default:
+ DRM_DEBUG_DRIVER("Unknown extension id: %d\n", ext.id);
+ return -EINVAL;
+ }
+
+ user_ext = u64_to_user_ptr(ext.next);
+ }
+
+ return 0;
+}
+
/**
* v3d_submit_cl_ioctl() - Submits a job (frame) to the V3D.
* @dev: DRM device
@@ -565,15 +595,24 @@ v3d_submit_cl_ioctl(struct drm_device *dev, void *data,
trace_v3d_submit_cl_ioctl(&v3d->drm, args->rcl_start, args->rcl_end);
- if (args->pad != 0)
+ if (args->pad)
return -EINVAL;
- if (args->flags != 0 &&
- args->flags != DRM_V3D_SUBMIT_CL_FLUSH_CACHE) {
+ if (args->flags &&
+ args->flags & ~(DRM_V3D_SUBMIT_CL_FLUSH_CACHE |
+ DRM_V3D_SUBMIT_EXTENSION)) {
DRM_INFO("invalid flags: %d\n", args->flags);
return -EINVAL;
}
+ if (args->flags & DRM_V3D_SUBMIT_EXTENSION) {
+ ret = v3d_get_extensions(file_priv, args->extensions);
+ if (ret) {
+ DRM_DEBUG("Failed to get extensions.\n");
+ return ret;
+ }
+ }
+
ret = v3d_job_init(v3d, file_priv, (void *)&render, sizeof(*render),
v3d_render_job_free, args->in_sync_rcl, V3D_RENDER);
if (ret)
@@ -702,6 +741,19 @@ v3d_submit_tfu_ioctl(struct drm_device *dev, void *data,
trace_v3d_submit_tfu_ioctl(&v3d->drm, args->iia);
+ if (args->flags && !(args->flags & DRM_V3D_SUBMIT_EXTENSION)) {
+ DRM_DEBUG("invalid flags: %d\n", args->flags);
+ return -EINVAL;
+ }
+
+ if (args->flags & DRM_V3D_SUBMIT_EXTENSION) {
+ ret = v3d_get_extensions(file_priv, args->extensions);
+ if (ret) {
+ DRM_DEBU
[PATCH v3 2/4] drm/v3d: alloc and init job in one shot
Move job memory allocation to v3d_job_init function. This aim to facilitate
error handling in job initialization, since cleanup steps are similar for all
(struct v3d_job)-based types of job involved in a command submission. To
generalize v3d_job_init(), this change takes into account that all job structs
have the first element a struct v3d_job (bin, render, tfu, csd) or it is a
v3d_job itself (clean_job) for pointer casting.
v3:
- explicitly init job as NULL (Iago)
- fix pm failure handling on v3_job_init (Iago)
Suggested-by: Iago Toral
Signed-off-by: Melissa Wen
---
drivers/gpu/drm/v3d/v3d_gem.c | 135 +-
1 file changed, 53 insertions(+), 82 deletions(-)
diff --git a/drivers/gpu/drm/v3d/v3d_gem.c b/drivers/gpu/drm/v3d/v3d_gem.c
index e60fbc28ef29..f932e73fb5c6 100644
--- a/drivers/gpu/drm/v3d/v3d_gem.c
+++ b/drivers/gpu/drm/v3d/v3d_gem.c
@@ -392,6 +392,9 @@ v3d_render_job_free(struct kref *ref)
void v3d_job_cleanup(struct v3d_job *job)
{
+ if (!job)
+ return;
+
drm_sched_job_cleanup(&job->base);
v3d_job_put(job);
}
@@ -450,35 +453,48 @@ v3d_job_add_deps(struct drm_file *file_priv, struct
v3d_job *job,
static int
v3d_job_init(struct v3d_dev *v3d, struct drm_file *file_priv,
-struct v3d_job *job, void (*free)(struct kref *ref),
+void **container, size_t size, void (*free)(struct kref *ref),
u32 in_sync, enum v3d_queue queue)
{
struct v3d_file_priv *v3d_priv = file_priv->driver_priv;
+ struct v3d_job *job;
int ret;
+ *container = kcalloc(1, size, GFP_KERNEL);
+ if (!*container) {
+ DRM_ERROR("Cannot allocate memory for v3d job.");
+ return -ENOMEM;
+ }
+
+ job = *container;
job->v3d = v3d;
job->free = free;
ret = pm_runtime_get_sync(v3d->drm.dev);
if (ret < 0)
- return ret;
+ goto fail;
ret = drm_sched_job_init(&job->base, &v3d_priv->sched_entity[queue],
v3d_priv);
if (ret)
- goto fail;
+ goto fail_job;
ret = v3d_job_add_deps(file_priv, job, in_sync, 0);
if (ret)
- goto fail_job;
+ goto fail_deps;
kref_init(&job->refcount);
return 0;
-fail_job:
+
+fail_deps:
drm_sched_job_cleanup(&job->base);
-fail:
+fail_job:
pm_runtime_put_autosuspend(v3d->drm.dev);
+fail:
+ kfree(*container);
+ *container = NULL;
+
return ret;
}
@@ -541,7 +557,7 @@ v3d_submit_cl_ioctl(struct drm_device *dev, void *data,
struct v3d_file_priv *v3d_priv = file_priv->driver_priv;
struct drm_v3d_submit_cl *args = data;
struct v3d_bin_job *bin = NULL;
- struct v3d_render_job *render;
+ struct v3d_render_job *render = NULL;
struct v3d_job *clean_job = NULL;
struct v3d_job *last_job;
struct ww_acquire_ctx acquire_ctx;
@@ -558,35 +574,20 @@ v3d_submit_cl_ioctl(struct drm_device *dev, void *data,
return -EINVAL;
}
- render = kcalloc(1, sizeof(*render), GFP_KERNEL);
- if (!render)
- return -ENOMEM;
+ ret = v3d_job_init(v3d, file_priv, (void *)&render, sizeof(*render),
+ v3d_render_job_free, args->in_sync_rcl, V3D_RENDER);
+ if (ret)
+ goto fail;
render->start = args->rcl_start;
render->end = args->rcl_end;
INIT_LIST_HEAD(&render->unref_list);
- ret = v3d_job_init(v3d, file_priv, &render->base,
- v3d_render_job_free, args->in_sync_rcl, V3D_RENDER);
- if (ret) {
- kfree(render);
- return ret;
- }
-
if (args->bcl_start != args->bcl_end) {
- bin = kcalloc(1, sizeof(*bin), GFP_KERNEL);
- if (!bin) {
- v3d_job_cleanup(&render->base);
- return -ENOMEM;
- }
-
- ret = v3d_job_init(v3d, file_priv, &bin->base,
+ ret = v3d_job_init(v3d, file_priv, (void *)&bin, sizeof(*bin),
v3d_job_free, args->in_sync_bcl, V3D_BIN);
- if (ret) {
- v3d_job_cleanup(&render->base);
- kfree(bin);
- return ret;
- }
+ if (ret)
+ goto fail;
bin->start = args->bcl_start;
bin->end = args->bcl_end;
@@ -597,18 +598,10 @@ v3d_submit_cl_ioctl(struct drm_device *dev, void *data,
}
if (args->flags & DRM_V3D_SUBMIT_CL_FLUSH_CACHE) {
- clean_job = kcalloc(1, sizeof(*clean_job), GFP_KERNEL);
- if (!clean_job) {
- ret = -ENOMEM;
- goto fail;
- }
-
- ret = v3d_job_init(v3d,
[PATCH] drm/amd: Initialize remove_mpcc in dcn201_update_mpcc()
Clang warns:
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn201/dcn201_hwseq.c:505:6: error:
variable 'remove_mpcc' is used uninitialized whenever 'if' condition is false
[-Werror,-Wsometimes-uninitialized]
if (mpc->funcs->get_mpcc_for_dpp_from_secondary)
^~~
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn201/dcn201_hwseq.c:509:6: note:
uninitialized use occurs here
if (remove_mpcc != NULL && mpc->funcs->remove_mpcc_from_secondary)
^~~
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn201/dcn201_hwseq.c:505:2: note:
remove the 'if' if its condition is always true
if (mpc->funcs->get_mpcc_for_dpp_from_secondary)
^~~~
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn201/dcn201_hwseq.c:442:26: note:
initialize the variable 'remove_mpcc' to silence this warning
struct mpcc *remove_mpcc;
^
= NULL
1 error generated.
The code already handles remove_mpcc being NULL just fine so initialize
it to NULL at the beginning of the function so it is never used
uninitialized.
Fixes: ff7e396f822f ("drm/amd/display: add cyan_skillfish display support")
Link: https://github.com/ClangBuiltLinux/linux/issues/1469
Signed-off-by: Nathan Chancellor
---
drivers/gpu/drm/amd/display/dc/dcn201/dcn201_hwseq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn201/dcn201_hwseq.c
b/drivers/gpu/drm/amd/display/dc/dcn201/dcn201_hwseq.c
index ceaaeeb8f2de..cfd09b3f705e 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn201/dcn201_hwseq.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn201/dcn201_hwseq.c
@@ -439,7 +439,7 @@ void dcn201_update_mpcc(struct dc *dc, struct pipe_ctx
*pipe_ctx)
bool per_pixel_alpha = pipe_ctx->plane_state->per_pixel_alpha &&
pipe_ctx->bottom_pipe;
int mpcc_id, dpp_id;
struct mpcc *new_mpcc;
- struct mpcc *remove_mpcc;
+ struct mpcc *remove_mpcc = NULL;
struct mpc *mpc = dc->res_pool->mpc;
struct mpc_tree *mpc_tree_params =
&(pipe_ctx->stream_res.opp->mpc_tree_params);
base-commit: 30fc33064c846df29888c3c61e30a064aad3a342
--
2.33.0.591.gddb1055343
[PATCH v3 1/4] drm/v3d: decouple adding job dependencies steps from job init
Prep work to enable a job to wait for more than one syncobj before
start. Also get rid of old checkpatch warnings in the v3d_gem file.
No functional changes.
Signed-off-by: Melissa Wen
---
drivers/gpu/drm/v3d/v3d_gem.c | 28 ++--
1 file changed, 18 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/v3d/v3d_gem.c b/drivers/gpu/drm/v3d/v3d_gem.c
index ead0be8d48a7..e60fbc28ef29 100644
--- a/drivers/gpu/drm/v3d/v3d_gem.c
+++ b/drivers/gpu/drm/v3d/v3d_gem.c
@@ -416,7 +416,7 @@ v3d_wait_bo_ioctl(struct drm_device *dev, void *data,
return -EINVAL;
ret = drm_gem_dma_resv_wait(file_priv, args->handle,
- true, timeout_jiffies);
+ true, timeout_jiffies);
/* Decrement the user's timeout, in case we got interrupted
* such that the ioctl will be restarted.
@@ -434,12 +434,25 @@ v3d_wait_bo_ioctl(struct drm_device *dev, void *data,
return ret;
}
+static int
+v3d_job_add_deps(struct drm_file *file_priv, struct v3d_job *job,
+u32 in_sync, u32 point)
+{
+ struct dma_fence *in_fence = NULL;
+ int ret;
+
+ ret = drm_syncobj_find_fence(file_priv, in_sync, point, 0, &in_fence);
+ if (ret == -EINVAL)
+ return ret;
+
+ return drm_sched_job_add_dependency(&job->base, in_fence);
+}
+
static int
v3d_job_init(struct v3d_dev *v3d, struct drm_file *file_priv,
struct v3d_job *job, void (*free)(struct kref *ref),
u32 in_sync, enum v3d_queue queue)
{
- struct dma_fence *in_fence = NULL;
struct v3d_file_priv *v3d_priv = file_priv->driver_priv;
int ret;
@@ -455,11 +468,7 @@ v3d_job_init(struct v3d_dev *v3d, struct drm_file
*file_priv,
if (ret)
goto fail;
- ret = drm_syncobj_find_fence(file_priv, in_sync, 0, 0, &in_fence);
- if (ret == -EINVAL)
- goto fail_job;
-
- ret = drm_sched_job_add_dependency(&job->base, in_fence);
+ ret = v3d_job_add_deps(file_priv, job, in_sync, 0);
if (ret)
goto fail_job;
@@ -499,7 +508,7 @@ v3d_attach_fences_and_unlock_reservation(struct drm_file
*file_priv,
for (i = 0; i < job->bo_count; i++) {
/* XXX: Use shared fences for read-only objects. */
dma_resv_add_excl_fence(job->bo[i]->resv,
- job->done_fence);
+ job->done_fence);
}
drm_gem_unlock_reservations(job->bo, job->bo_count, acquire_ctx);
@@ -903,8 +912,7 @@ v3d_gem_init(struct drm_device *dev)
if (!v3d->pt) {
drm_mm_takedown(&v3d->mm);
dev_err(v3d->drm.dev,
- "Failed to allocate page tables. "
- "Please ensure you have CMA enabled.\n");
+ "Failed to allocate page tables. Please ensure you have
CMA enabled.\n");
return -ENOMEM;
}
--
2.30.2
signature.asc
Description: PGP signature
[PATCH v3 0/4] drm/v3d: add multiple in/out syncobjs support
Currently, v3d only supports single in/out syncobj per submission (in v3d_submit_cl, there are two in_sync, one for bin and another for render job); however, Vulkan queue submit operations expect multiples wait and signal semaphores. This series extends v3d interface and job dependency operations to handle more than one in/out syncobj. The first patch just decouples the steps to lookup and add job dependency from the job init code, since the operation repeats for every syncobj that a job should wait before starting. So, the fourth patch of this series will reuse it to handle multiples wait for semaphores. The second patch moves job memory allocation to v3d_job_init() for any type of v3d_job-based job. The main goal is to prevent errors when handling job initialization failures (doing a proper cleanup). The third patch extends our interface by using a generic extension. This approach was inspired by i915_user_extension[1] and amd_cs_chunks[2] to give a little more flexibility in adding other submission features in the future. Therefore, the list of extensions would work as a hub of features that use an id to determine the corresponding feature data type. With this base, the fourth patch adds multiple wait/signal semaphores support. For this, we add to the list of the generic extensions a new data type (drm_v3d_multi_sync) that points to two arrays of syncobjs (in/out) and also determines (wait_stage) the job to add wait dependencies (v3d_queue). An auxiliary struct (v3d_submit_ext) is used when parsing submission extensions. Finally, we reserve some space in the semaphore struct (drm_v3d_sem) to accommodate timeline semaphores that we aim to add support soon (same reason for already defining v3d_submit_outsync). [1] https://cgit.freedesktop.org/drm/drm-misc/commit/drivers/gpu/drm/i915/i915_user_extensions.c?id=9d1305ef80b95dde0337106ed8b826604e2155ad [2] https://cgit.freedesktop.org/drm/drm-misc/tree/include/uapi/drm/amdgpu_drm.h#n556 In the mesa side, the work related to this series is in progress at https://gitlab.freedesktop.org/mwen/mesa/-/commit/6c340bb35203a0418af87a7921d7295a4047b77f v2: - move job mem alloc to v3d_job_init (Iago) - simplify and subclass the generic extension struct (Daniel) - make job dependency conditions more understandable (Iago) v3 (Iago): - job should be initialized NULL - fix error handling for pm ops in v3d_job_init - remove irrelevant comment - fix multisync conditions to multiple vs single sempahores Melissa Wen (4): drm/v3d: decouple adding job dependencies steps from job init drm/v3d: alloc and init job in one shot drm/v3d: add generic ioctl extension drm/v3d: add multiple syncobjs support drivers/gpu/drm/v3d/v3d_drv.c | 10 +- drivers/gpu/drm/v3d/v3d_drv.h | 24 ++- drivers/gpu/drm/v3d/v3d_gem.c | 390 +- include/uapi/drm/v3d_drm.h| 78 +++ 4 files changed, 389 insertions(+), 113 deletions(-) -- 2.30.2 signature.asc Description: PGP signature
[PATCH] drm/amd: Guard IS_OLD_GCC assignment with CONFIG_CC_IS_GCC
cc-ifversion only works for GCC, as clang pretends to be GCC 4.2.1 for
glibc compatibility, which means IS_OLD_GCC will get set and unsupported
flags will be passed to clang when building certain code within the DCN
files:
clang-14: error: unknown argument: '-mpreferred-stack-boundary=4'
make[5]: *** [scripts/Makefile.build:277:
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn201/dcn201_resource.o] Error 1
Guard the call to cc-ifversion with CONFIG_CC_IS_GCC so that everything
continues to work properly. See commit 00db297106e8 ("drm/amdgpu: fix stack
alignment ABI mismatch for GCC 7.1+") for more context.
Fixes: ff7e396f822f ("drm/amd/display: add cyan_skillfish display support")
Link: https://github.com/ClangBuiltLinux/linux/issues/1468
Signed-off-by: Nathan Chancellor
---
drivers/gpu/drm/amd/display/dc/dcn201/Makefile | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn201/Makefile
b/drivers/gpu/drm/amd/display/dc/dcn201/Makefile
index d98d69705117..96cbd4ccd344 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn201/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dcn201/Makefile
@@ -14,9 +14,11 @@ ifdef CONFIG_PPC64
CFLAGS_$(AMDDALPATH)/dc/dcn201/dcn201_resource.o := -mhard-float -maltivec
endif
+ifdef CONFIG_CC_IS_GCC
ifeq ($(call cc-ifversion, -lt, 0701, y), y)
IS_OLD_GCC = 1
endif
+endif
ifdef CONFIG_X86
ifdef IS_OLD_GCC
base-commit: b47b99e30cca8906753c83205e8c6179045dd725
--
2.33.0.591.gddb1055343
Re: [PATCH v2 3/3] Move IS_CONFIG_NONZERO() to kconfig.h
On Thu, Sep 30, 2021 at 11:01:36PM +0900, Masahiro Yamada wrote:
On Thu, Sep 30, 2021 at 3:34 AM Lucas De Marchi
wrote:
The check for config value doesn't really belong to i915_utils.h - we
are trying to eliminate that utils helper and share them when possible
with other drivers and subsystems.
Rationale for having such macro is in commit
babaab2f4738 ("drm/i915: Encapsulate kconfig constant values inside boolean
predicates")
whereas later it is improved to not break the build if used with
undefined configs. The caveat is detailed in the documentation: unlike
IS_ENABLED(): it's not preprocessor-only logic so can't be used for
things like `#if IS_CONFIG_NONZERO(...)`
Signed-off-by: Lucas De Marchi
Hypothetical "it would be nice to have ..." is really unneeded.
if (context && CONFIG_DRM_I915_FENCE_TIMEOUT > 0)
return
msecs_to_jiffies_timeout(CONFIG_DRM_I915_FENCE_TIMEOUT);
is enough, and much cleaner.
This warning is shown only when a constant is used
together with '&&'.
Most of IS_ACTIVE can go away.
Given that, there are not many places where the IS_ACTIVE macro
is useful, even in the i915 driver.
For a few sources of the warnings,
replacing it with != 0 or > 0 is just fine.
humn... maybe. Let me do a conversion in that direction and see what is
the outcome.
My original intention was to make IS_ENABLED() even uglier to cover the
int case, but after some tries it seems impossible to do on preprocessor
context, so I thought maybe it would be ok as a separate one.
Of course, such an ugly macro is not worth being moved to
if we don't handle the undefined case and only worry about encapsulating
it inside a boolean predicate, the macro would be very simple. Would
that be worth having in kconfig.h maybe?
thanks
Lucas De Marchi
[PATCH v10, 4/5] soc: mediatek: add mtk mutex support for MT8192
Add mtk mutex support for MT8192 SoC.
Signed-off-by: Yongqiang Niu
Signed-off-by: Hsin-Yi Wang
Reviewed-by: CK Hu
---
drivers/soc/mediatek/mtk-mutex.c | 35
1 file changed, 35 insertions(+)
diff --git a/drivers/soc/mediatek/mtk-mutex.c b/drivers/soc/mediatek/mtk-mutex.c
index 2e4bcc300576..2ca55bb5a8be 100644
--- a/drivers/soc/mediatek/mtk-mutex.c
+++ b/drivers/soc/mediatek/mtk-mutex.c
@@ -39,6 +39,18 @@
#define MT8167_MUTEX_MOD_DISP_DITHER 15
#define MT8167_MUTEX_MOD_DISP_UFOE 16
+#define MT8192_MUTEX_MOD_DISP_OVL0 0
+#define MT8192_MUTEX_MOD_DISP_OVL0_2L 1
+#define MT8192_MUTEX_MOD_DISP_RDMA02
+#define MT8192_MUTEX_MOD_DISP_COLOR0 4
+#define MT8192_MUTEX_MOD_DISP_CCORR0 5
+#define MT8192_MUTEX_MOD_DISP_AAL0 6
+#define MT8192_MUTEX_MOD_DISP_GAMMA0 7
+#define MT8192_MUTEX_MOD_DISP_POSTMASK08
+#define MT8192_MUTEX_MOD_DISP_DITHER0 9
+#define MT8192_MUTEX_MOD_DISP_OVL2_2L 16
+#define MT8192_MUTEX_MOD_DISP_RDMA417
+
#define MT8183_MUTEX_MOD_DISP_RDMA00
#define MT8183_MUTEX_MOD_DISP_RDMA11
#define MT8183_MUTEX_MOD_DISP_OVL0 9
@@ -214,6 +226,20 @@ static const unsigned int
mt8183_mutex_mod[DDP_COMPONENT_ID_MAX] = {
[DDP_COMPONENT_WDMA0] = MT8183_MUTEX_MOD_DISP_WDMA0,
};
+static const unsigned int mt8192_mutex_mod[DDP_COMPONENT_ID_MAX] = {
+ [DDP_COMPONENT_AAL0] = MT8192_MUTEX_MOD_DISP_AAL0,
+ [DDP_COMPONENT_CCORR] = MT8192_MUTEX_MOD_DISP_CCORR0,
+ [DDP_COMPONENT_COLOR0] = MT8192_MUTEX_MOD_DISP_COLOR0,
+ [DDP_COMPONENT_DITHER] = MT8192_MUTEX_MOD_DISP_DITHER0,
+ [DDP_COMPONENT_GAMMA] = MT8192_MUTEX_MOD_DISP_GAMMA0,
+ [DDP_COMPONENT_POSTMASK0] = MT8192_MUTEX_MOD_DISP_POSTMASK0,
+ [DDP_COMPONENT_OVL0] = MT8192_MUTEX_MOD_DISP_OVL0,
+ [DDP_COMPONENT_OVL_2L0] = MT8192_MUTEX_MOD_DISP_OVL0_2L,
+ [DDP_COMPONENT_OVL_2L2] = MT8192_MUTEX_MOD_DISP_OVL2_2L,
+ [DDP_COMPONENT_RDMA0] = MT8192_MUTEX_MOD_DISP_RDMA0,
+ [DDP_COMPONENT_RDMA4] = MT8192_MUTEX_MOD_DISP_RDMA4,
+};
+
static const unsigned int mt2712_mutex_sof[MUTEX_SOF_DSI3 + 1] = {
[MUTEX_SOF_SINGLE_MODE] = MUTEX_SOF_SINGLE_MODE,
[MUTEX_SOF_DSI0] = MUTEX_SOF_DSI0,
@@ -275,6 +301,13 @@ static const struct mtk_mutex_data
mt8183_mutex_driver_data = {
.no_clk = true,
};
+static const struct mtk_mutex_data mt8192_mutex_driver_data = {
+ .mutex_mod = mt8192_mutex_mod,
+ .mutex_sof = mt8183_mutex_sof,
+ .mutex_mod_reg = MT8183_MUTEX0_MOD0,
+ .mutex_sof_reg = MT8183_MUTEX0_SOF0,
+};
+
struct mtk_mutex *mtk_mutex_get(struct device *dev)
{
struct mtk_mutex_ctx *mtx = dev_get_drvdata(dev);
@@ -507,6 +540,8 @@ static const struct of_device_id mutex_driver_dt_match[] = {
.data = &mt8173_mutex_driver_data},
{ .compatible = "mediatek,mt8183-disp-mutex",
.data = &mt8183_mutex_driver_data},
+ { .compatible = "mediatek,mt8192-disp-mutex",
+ .data = &mt8192_mutex_driver_data},
{},
};
MODULE_DEVICE_TABLE(of, mutex_driver_dt_match);
--
2.25.1
[PATCH v10, 5/5] drm/mediatek: add support for mediatek SOC MT8192
add support for mediatek SOC MT8192
Signed-off-by: Yongqiang Niu
Signed-off-by: Hsin-Yi Wang
Reviewed-by: CK Hu
---
drivers/gpu/drm/mediatek/mtk_disp_ccorr.c | 6
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 20 +++
drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 6
drivers/gpu/drm/mediatek/mtk_drm_drv.c| 42 +++
4 files changed, 74 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ccorr.c
b/drivers/gpu/drm/mediatek/mtk_disp_ccorr.c
index 141cb36b9c07..3a53ebc4e172 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ccorr.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ccorr.c
@@ -205,9 +205,15 @@ static const struct mtk_disp_ccorr_data
mt8183_ccorr_driver_data = {
.matrix_bits = 10,
};
+static const struct mtk_disp_ccorr_data mt8192_ccorr_driver_data = {
+ .matrix_bits = 11,
+};
+
static const struct of_device_id mtk_disp_ccorr_driver_dt_match[] = {
{ .compatible = "mediatek,mt8183-disp-ccorr",
.data = &mt8183_ccorr_driver_data},
+ { .compatible = "mediatek,mt8192-disp-ccorr",
+ .data = &mt8192_ccorr_driver_data},
{},
};
MODULE_DEVICE_TABLE(of, mtk_disp_ccorr_driver_dt_match);
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index 5326989d5206..2146299e5f52 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -456,6 +456,22 @@ static const struct mtk_disp_ovl_data
mt8183_ovl_2l_driver_data = {
.fmt_rgb565_is_0 = true,
};
+static const struct mtk_disp_ovl_data mt8192_ovl_driver_data = {
+ .addr = DISP_REG_OVL_ADDR_MT8173,
+ .gmc_bits = 10,
+ .layer_nr = 4,
+ .fmt_rgb565_is_0 = true,
+ .smi_id_en = true,
+};
+
+static const struct mtk_disp_ovl_data mt8192_ovl_2l_driver_data = {
+ .addr = DISP_REG_OVL_ADDR_MT8173,
+ .gmc_bits = 10,
+ .layer_nr = 2,
+ .fmt_rgb565_is_0 = true,
+ .smi_id_en = true,
+};
+
static const struct of_device_id mtk_disp_ovl_driver_dt_match[] = {
{ .compatible = "mediatek,mt2701-disp-ovl",
.data = &mt2701_ovl_driver_data},
@@ -465,6 +481,10 @@ static const struct of_device_id
mtk_disp_ovl_driver_dt_match[] = {
.data = &mt8183_ovl_driver_data},
{ .compatible = "mediatek,mt8183-disp-ovl-2l",
.data = &mt8183_ovl_2l_driver_data},
+ { .compatible = "mediatek,mt8192-disp-ovl",
+ .data = &mt8192_ovl_driver_data},
+ { .compatible = "mediatek,mt8192-disp-ovl-2l",
+ .data = &mt8192_ovl_2l_driver_data},
{},
};
MODULE_DEVICE_TABLE(of, mtk_disp_ovl_driver_dt_match);
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
index 75d7f45579e2..d41a3970b944 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
@@ -353,6 +353,10 @@ static const struct mtk_disp_rdma_data
mt8183_rdma_driver_data = {
.fifo_size = 5 * SZ_1K,
};
+static const struct mtk_disp_rdma_data mt8192_rdma_driver_data = {
+ .fifo_size = 5 * SZ_1K,
+};
+
static const struct of_device_id mtk_disp_rdma_driver_dt_match[] = {
{ .compatible = "mediatek,mt2701-disp-rdma",
.data = &mt2701_rdma_driver_data},
@@ -360,6 +364,8 @@ static const struct of_device_id
mtk_disp_rdma_driver_dt_match[] = {
.data = &mt8173_rdma_driver_data},
{ .compatible = "mediatek,mt8183-disp-rdma",
.data = &mt8183_rdma_driver_data},
+ { .compatible = "mediatek,mt8192-disp-rdma",
+ .data = &mt8192_rdma_driver_data},
{},
};
MODULE_DEVICE_TABLE(of, mtk_disp_rdma_driver_dt_match);
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index aec39724ebeb..fa86485b4b9a 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -158,6 +158,25 @@ static const enum mtk_ddp_comp_id mt8183_mtk_ddp_ext[] = {
DDP_COMPONENT_DPI0,
};
+static const enum mtk_ddp_comp_id mt8192_mtk_ddp_main[] = {
+ DDP_COMPONENT_OVL0,
+ DDP_COMPONENT_OVL_2L0,
+ DDP_COMPONENT_RDMA0,
+ DDP_COMPONENT_COLOR0,
+ DDP_COMPONENT_CCORR,
+ DDP_COMPONENT_AAL0,
+ DDP_COMPONENT_GAMMA,
+ DDP_COMPONENT_POSTMASK0,
+ DDP_COMPONENT_DITHER,
+ DDP_COMPONENT_DSI0,
+};
+
+static const enum mtk_ddp_comp_id mt8192_mtk_ddp_ext[] = {
+ DDP_COMPONENT_OVL_2L2,
+ DDP_COMPONENT_RDMA4,
+ DDP_COMPONENT_DPI0,
+};
+
static const struct mtk_mmsys_driver_data mt2701_mmsys_driver_data = {
.main_path = mt2701_mtk_ddp_main,
.main_len = ARRAY_SIZE(mt2701_mtk_ddp_main),
@@ -202,6 +221,13 @@ static const struct mtk_mmsys_driver_data
mt8183_mmsys_driver_data = {
.ext_len = ARRAY_SIZE(mt8183_mtk_ddp_ext),
};
+static const struct mtk_mmsys_driver_data mt8192_mmsys_driver_data = {
+ .main_path = mt8192_mtk_ddp_main,
+
[PATCH v10, 1/5] drm/mediatek: add component OVL_2L2
This patch add component OVL_2L2
Signed-off-by: Yongqiang Niu
Reviewed-by: Chun-Kuang Hu
Signed-off-by: Hsin-Yi Wang
---
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index 33e8789fde8a..4a2abcf3e5f9 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -353,6 +353,7 @@ static const struct mtk_ddp_comp_match
mtk_ddp_matches[DDP_COMPONENT_ID_MAX] = {
[DDP_COMPONENT_OVL1]= { MTK_DISP_OVL, 1, &ddp_ovl },
[DDP_COMPONENT_OVL_2L0] = { MTK_DISP_OVL_2L,0, &ddp_ovl },
[DDP_COMPONENT_OVL_2L1] = { MTK_DISP_OVL_2L,1, &ddp_ovl },
+ [DDP_COMPONENT_OVL_2L2] = { MTK_DISP_OVL_2L,2, &ddp_ovl },
[DDP_COMPONENT_PWM0]= { MTK_DISP_PWM, 0, NULL },
[DDP_COMPONENT_PWM1]= { MTK_DISP_PWM, 1, NULL },
[DDP_COMPONENT_PWM2]= { MTK_DISP_PWM, 2, NULL },
--
2.25.1
[PATCH v10, 2/5] drm/mediatek: add component POSTMASK
This patch add component POSTMASK.
Signed-off-by: Yongqiang Niu
Signed-off-by: Hsin-Yi Wang
Reviewed-by: CK Hu
---
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 102 ++--
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 1 +
2 files changed, 73 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index 4a2abcf3e5f9..89170ad825fd 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -62,6 +62,12 @@
#define DITHER_ADD_LSHIFT_G(x) (((x) & 0x7) << 4)
#define DITHER_ADD_RSHIFT_G(x) (((x) & 0x7) << 0)
+#define DISP_POSTMASK_EN 0x
+#define POSTMASK_ENBIT(0)
+#define DISP_POSTMASK_CFG 0x0020
+#define POSTMASK_RELAY_MODEBIT(0)
+#define DISP_POSTMASK_SIZE 0x0030
+
struct mtk_ddp_comp_dev {
struct clk *clk;
void __iomem *regs;
@@ -214,6 +220,32 @@ static void mtk_dither_stop(struct device *dev)
writel_relaxed(0x0, priv->regs + DISP_DITHER_EN);
}
+static void mtk_postmask_config(struct device *dev, unsigned int w,
+ unsigned int h, unsigned int vrefresh,
+ unsigned int bpc, struct cmdq_pkt *cmdq_pkt)
+{
+ struct mtk_ddp_comp_dev *priv = dev_get_drvdata(dev);
+
+ mtk_ddp_write(cmdq_pkt, w << 16 | h, &priv->cmdq_reg, priv->regs,
+ DISP_POSTMASK_SIZE);
+ mtk_ddp_write(cmdq_pkt, POSTMASK_RELAY_MODE, &priv->cmdq_reg,
+ priv->regs, DISP_POSTMASK_CFG);
+}
+
+static void mtk_postmask_start(struct device *dev)
+{
+ struct mtk_ddp_comp_dev *priv = dev_get_drvdata(dev);
+
+ writel(POSTMASK_EN, priv->regs + DISP_POSTMASK_EN);
+}
+
+static void mtk_postmask_stop(struct device *dev)
+{
+ struct mtk_ddp_comp_dev *priv = dev_get_drvdata(dev);
+
+ writel_relaxed(0x0, priv->regs + DISP_POSTMASK_EN);
+}
+
static const struct mtk_ddp_comp_funcs ddp_aal = {
.clk_enable = mtk_aal_clk_enable,
.clk_disable = mtk_aal_clk_disable,
@@ -289,6 +321,14 @@ static const struct mtk_ddp_comp_funcs ddp_ovl = {
.bgclr_in_off = mtk_ovl_bgclr_in_off,
};
+static const struct mtk_ddp_comp_funcs ddp_postmask = {
+ .clk_enable = mtk_ddp_clk_enable,
+ .clk_disable = mtk_ddp_clk_disable,
+ .config = mtk_postmask_config,
+ .start = mtk_postmask_start,
+ .stop = mtk_postmask_stop,
+};
+
static const struct mtk_ddp_comp_funcs ddp_rdma = {
.clk_enable = mtk_rdma_clk_enable,
.clk_disable = mtk_rdma_clk_disable,
@@ -324,6 +364,7 @@ static const char * const
mtk_ddp_comp_stem[MTK_DDP_COMP_TYPE_MAX] = {
[MTK_DISP_MUTEX] = "mutex",
[MTK_DISP_OD] = "od",
[MTK_DISP_BLS] = "bls",
+ [MTK_DISP_POSTMASK] = "postmask",
};
struct mtk_ddp_comp_match {
@@ -333,36 +374,37 @@ struct mtk_ddp_comp_match {
};
static const struct mtk_ddp_comp_match mtk_ddp_matches[DDP_COMPONENT_ID_MAX] =
{
- [DDP_COMPONENT_AAL0]= { MTK_DISP_AAL, 0, &ddp_aal },
- [DDP_COMPONENT_AAL1]= { MTK_DISP_AAL, 1, &ddp_aal },
- [DDP_COMPONENT_BLS] = { MTK_DISP_BLS, 0, NULL },
- [DDP_COMPONENT_CCORR] = { MTK_DISP_CCORR, 0, &ddp_ccorr },
- [DDP_COMPONENT_COLOR0] = { MTK_DISP_COLOR, 0, &ddp_color },
- [DDP_COMPONENT_COLOR1] = { MTK_DISP_COLOR, 1, &ddp_color },
- [DDP_COMPONENT_DITHER] = { MTK_DISP_DITHER,0, &ddp_dither },
- [DDP_COMPONENT_DPI0]= { MTK_DPI,0, &ddp_dpi },
- [DDP_COMPONENT_DPI1]= { MTK_DPI,1, &ddp_dpi },
- [DDP_COMPONENT_DSI0]= { MTK_DSI,0, &ddp_dsi },
- [DDP_COMPONENT_DSI1]= { MTK_DSI,1, &ddp_dsi },
- [DDP_COMPONENT_DSI2]= { MTK_DSI,2, &ddp_dsi },
- [DDP_COMPONENT_DSI3]= { MTK_DSI,3, &ddp_dsi },
- [DDP_COMPONENT_GAMMA] = { MTK_DISP_GAMMA, 0, &ddp_gamma },
- [DDP_COMPONENT_OD0] = { MTK_DISP_OD,0, &ddp_od },
- [DDP_COMPONENT_OD1] = { MTK_DISP_OD,1, &ddp_od },
- [DDP_COMPONENT_OVL0]= { MTK_DISP_OVL, 0, &ddp_ovl },
- [DDP_COMPONENT_OVL1]= { MTK_DISP_OVL, 1, &ddp_ovl },
- [DDP_COMPONENT_OVL_2L0] = { MTK_DISP_OVL_2L,0, &ddp_ovl },
- [DDP_COMPONENT_OVL_2L1] = { MTK_DISP_OVL_2L,1, &ddp_ovl },
- [DDP_COMPONENT_OVL_2L2] = { MTK_DISP_OVL_2L,2, &ddp_ovl },
- [DDP_COMPONENT_PWM0]= { MTK_DISP_PWM, 0, NULL },
- [DDP_COMPONENT_PWM1]= { MTK_DISP_PWM, 1, NULL },
- [DDP_COMPONENT_PWM2]= { MTK_DISP_PWM, 2, NULL },
- [DDP_COMPONENT_RDMA0] = { MTK_DISP_RDMA, 0, &ddp_rdma },
- [DDP_COMPONENT_RDMA1] = { MTK_DISP_RDMA, 1, &ddp
[PATCH v10, 3/5] drm/mediatek: add component RDMA4
This patch add component RDMA4
Signed-off-by: Yongqiang Niu
Reviewed-by: Chun-Kuang Hu
Signed-off-by: Hsin-Yi Wang
---
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index 89170ad825fd..6491eadf34c2 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -402,6 +402,7 @@ static const struct mtk_ddp_comp_match
mtk_ddp_matches[DDP_COMPONENT_ID_MAX] = {
[DDP_COMPONENT_RDMA0] = { MTK_DISP_RDMA, 0, &ddp_rdma },
[DDP_COMPONENT_RDMA1] = { MTK_DISP_RDMA, 1, &ddp_rdma },
[DDP_COMPONENT_RDMA2] = { MTK_DISP_RDMA, 2, &ddp_rdma },
+ [DDP_COMPONENT_RDMA4] = { MTK_DISP_RDMA, 4, &ddp_rdma },
[DDP_COMPONENT_UFOE]= { MTK_DISP_UFOE, 0, &ddp_ufoe },
[DDP_COMPONENT_WDMA0] = { MTK_DISP_WDMA, 0, NULL },
[DDP_COMPONENT_WDMA1] = { MTK_DISP_WDMA, 1, NULL },
--
2.25.1
[PATCH v10, 0/5] soc: mediatek: add mtk mutex support for MT8192
base v5.15 Yongqiang Niu (5): drm/mediatek: add component OVL_2L2 drm/mediatek: add component POSTMASK drm/mediatek: add component RDMA4 soc: mediatek: add mtk mutex support for MT8192 drm/mediatek: add support for mediatek SOC MT8192 drivers/gpu/drm/mediatek/mtk_disp_ccorr.c | 6 ++ drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 20 drivers/gpu/drm/mediatek/mtk_disp_rdma.c| 6 ++ drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 102 ++-- drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 1 + drivers/gpu/drm/mediatek/mtk_drm_drv.c | 42 drivers/soc/mediatek/mtk-mutex.c| 35 +++ 7 files changed, 183 insertions(+), 29 deletions(-) -- 2.25.1
Re: [PATCH v2 1/3] drm/i915: rename IS_ACTIVE
On Thu, Sep 30, 2021 at 01:46:21PM +0300, Jani Nikula wrote:
On Wed, 29 Sep 2021, Lucas De Marchi wrote:
It took me some time to understand the need for IS_ACTIVE and why we
couldn't use kconfig.h.
For anyone else wondering, the clues are in babaab2f4738 ("drm/i915:
Encapsulate kconfig constant values inside boolean predicates").
yeah, I had added that info on the third patch when I try to move the
macro to kconfig.h since it would give information for kconfig
developers on why the macro is being used.
But this series tries to take it further; we currently don't have a need
for checking whether the config is defined or not. It always is. I mean
it's probably a useful feature, but not the original problem we had.
yep, not trying to push hard on that direction... just tried to have the
same thing the other macros on kconfig.h have.
thanks
Lucas De Marchi
Re: [PATCH v2 2/3] dt-bindings: drm/bridge: ps8640: Add aux-bus child
Hi, On Wed, Sep 29, 2021 at 5:35 PM Philip Chen wrote: > > dp-aux-bus.yaml says we can list an eDP panel as a child of > an eDP controller node to represent the fact that the panel > is connected to the controller's DP AUX bus. > > Let's add it to the ps8640 bindings. > > Signed-off-by: Philip Chen > --- > > (no changes since v1) > > .../bindings/display/bridge/ps8640.yaml | 19 ++- > 1 file changed, 18 insertions(+), 1 deletion(-) Reviewed-by: Douglas Anderson
Re: [PATCH v2 2/3] drm/i915/utils: do not depend on config being defined
On Thu, Sep 30, 2021 at 11:00:06AM +0100, Steven Price wrote:
On 29/09/2021 19:33, Lucas De Marchi wrote:
Like the IS_ENABLED() counterpart, we can make IS_CONFIG_NONZERO() to
return the right thing when the config is not defined rather than a
build error, with the limitation that it can't be used on preprocessor
context.
The trick here is that macro names can't start with a number or dash, so
we stringify the argument and check that the first char is a number != 0
(or starting with a dash to cover negative numbers). Except for -O0
builds the strings are all eliminated.
Taking CONFIG_DRM_I915_REQUEST_TIMEOUT in
drivers/gpu/drm/i915/gem/i915_gem_context.c as example, we have the
following output of the preprocessor:
old:
if (((2) != 0) &&
new:
if (( ("2"[0] > '0' && "2"[0] < '9') || "2"[0] == '-' ) &&
New one looks worse, but is also eliminated from the object:
$ size drivers/gpu/drm/i915/gem/i915_gem_context.o.*
textdata bss dec hex filename
520211070 232 53323d04b
drivers/gpu/drm/i915/gem/i915_gem_context.o.new
520211070 232 53323d04b
drivers/gpu/drm/i915/gem/i915_gem_context.o.old
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/i915_utils.h | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_utils.h
b/drivers/gpu/drm/i915/i915_utils.h
index 02bbfa4d68d3..436ce612c46a 100644
--- a/drivers/gpu/drm/i915/i915_utils.h
+++ b/drivers/gpu/drm/i915/i915_utils.h
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#include
@@ -469,6 +470,9 @@ static inline bool timer_expired(const struct timer_list *t)
*
* Returns 0 if @config is 0, 1 if set to any value.
*/
-#define IS_CONFIG_NONZERO(config) ((config) != 0)
+#define IS_CONFIG_NONZERO(config) (
\
+ (__stringify_1(config)[0] > '0' && __stringify_1(config)[0] < '9') ||
\
Shouldn't this be "<= '9'". Otherwise numbers starting with a 9 are not
"non zero".
yes! thanks for catching it. However from the other discussion it seems
we can either
a) just remove the macro, or
b) use the simpler version that doesn't cover undefined values
I will investigate those options.
Lucas De Marchi
Re: [PATCH] drm/vc4: crtc: Make sure the HDMI controller is powered when disabling
On Thu, 2021-09-23 at 20:50 +0200, Maxime Ripard wrote:
> Since commit 875a4d536842 ("drm/vc4: drv: Disable the CRTC at boot
> time"), during the initial setup of the driver we call into the VC4 HDMI
> controller hooks to make sure the controller is properly disabled.
>
> However, we were never making sure that the device was properly powered
> while doing so. This never resulted in any (reported) issue in practice,
> but since the introduction of commit 4209f03fcb8e ("drm/vc4: hdmi: Warn
> if we access the controller while disabled") we get a loud complaint
> when we do that kind of access.
>
> Let's make sure we have the HDMI controller properly powered while
> disabling it.
>
> Fixes: 875a4d536842 ("drm/vc4: drv: Disable the CRTC at boot time")
> Signed-off-by: Maxime Ripard
> ---
Reviewed-by: Nicolas Saenz Julienne
Tested-by: Nicolas Saenz Julienne
Regards,
Nicolas
Re: [PATCH v6 2/3] drm/bridge: ti-sn65dsi86: Use regmap_bulk_write API
Hi, On Wed, Sep 29, 2021 at 8:06 PM Bjorn Andersson wrote: > > The multi-register u16 write operation can use regmap_bulk_write() > instead of two separate regmap_write() calls. > > It's uncertain if this has any effect on the actual updates of the > underlying registers, but this at least gives the hardware the > opportunity and saves us one transation on the bus. s/transation/transaction/ > Signed-off-by: Bjorn Andersson > --- > > Changes since v5: > - Extracted this hunk from patch 3. > > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) Looks keen. I'll plan to apply this after giving it a few days on the list to make sure nobody is upset, though I'm not sure why they would be. ;-) Reviewed-by: Douglas Anderson
[PATCH] fbdev: Garbage collect fbdev scrolling acceleration, part 1 (from TODO list)
Scroll acceleration is disabled in fbcon by hard-wiring
p->scrollmode = SCROLL_REDRAW. Remove the obsolete code in fbcon.c
and fbdev/core/
Signed-off-by: Claudio Suarez
---
- This is a task in the TODO list Documentation/gpu/todo.rst
- The contact in the task is Daniel Vetter. He is/you are in copy.
- To ease the things and saving time, I did a patch. It is included in this
message. I can redo it if there is something wrong.
- I tested it in some configurations.
My plan for new patches in this task:
- A buch of patches to remove code from drivers: fb_copyarea and related.
- Simplify the code around fbcon_ops as much as possible to remove the hooks
as the TODO suggests.
- Remove fb_copyarea in headers and exported symbols: cfb_copyarea, etc. This
must be done when all the drivers are changed.
I think that the correct list to ask questions about this
is linux-fb...@vger.kernel.org . Is it correct ?
My question: I can develop the new changes. I can test in two computers/two
drivers. Is there a way to test the rest of the patches ? I have not hardware
to test them. Is anyone helping with this? Only regression tests are needed.
I can test other patches in return.
Thank you.
Claudio Suarez.
Patch follows:
Documentation/gpu/todo.rst | 13 +-
drivers/video/fbdev/core/bitblit.c | 16 -
drivers/video/fbdev/core/fbcon.c| 509 ++--
drivers/video/fbdev/core/fbcon.h| 59
drivers/video/fbdev/core/fbcon_ccw.c| 28 +-
drivers/video/fbdev/core/fbcon_cw.c | 28 +-
drivers/video/fbdev/core/fbcon_rotate.h | 9 -
drivers/video/fbdev/core/fbcon_ud.c | 37 +--
drivers/video/fbdev/core/tileblit.c | 16 -
drivers/video/fbdev/skeletonfb.c| 12 +-
include/linux/fb.h | 2 +-
11 files changed, 51 insertions(+), 678 deletions(-)
diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 12e61869939e..bb1e04bbf4fb 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -314,16 +314,19 @@ Level: Advanced
Garbage collect fbdev scrolling acceleration
-Scroll acceleration is disabled in fbcon by hard-wiring p->scrollmode =
-SCROLL_REDRAW. There's a ton of code this will allow us to remove:
+Scroll acceleration has been disabled in fbcon. Now it works as the old
+SCROLL_REDRAW mode. A ton of code was removed in fbcon.c and the hook bmove was
+removed from fbcon_ops.
+Remaining tasks:
-- lots of code in fbcon.c
-
-- a bunch of the hooks in fbcon_ops, maybe the remaining hooks could be called
+- a bunch of the hooks in fbcon_ops could be removed or simplified by calling
directly instead of the function table (with a switch on p->rotate)
- fb_copyarea is unused after this, and can be deleted from all drivers
+- after that, fb_copyarea can be deleted from fb_ops in include/linux/fb.h as
+ well as cfb_copyarea
+
Note that not all acceleration code can be deleted, since clearing and cursor
support is still accelerated, which might be good candidates for further
deletion projects.
diff --git a/drivers/video/fbdev/core/bitblit.c
b/drivers/video/fbdev/core/bitblit.c
index f98e8f298bc1..01fae2c96965 100644
--- a/drivers/video/fbdev/core/bitblit.c
+++ b/drivers/video/fbdev/core/bitblit.c
@@ -43,21 +43,6 @@ static void update_attr(u8 *dst, u8 *src, int attribute,
}
}
-static void bit_bmove(struct vc_data *vc, struct fb_info *info, int sy,
- int sx, int dy, int dx, int height, int width)
-{
- struct fb_copyarea area;
-
- area.sx = sx * vc->vc_font.width;
- area.sy = sy * vc->vc_font.height;
- area.dx = dx * vc->vc_font.width;
- area.dy = dy * vc->vc_font.height;
- area.height = height * vc->vc_font.height;
- area.width = width * vc->vc_font.width;
-
- info->fbops->fb_copyarea(info, &area);
-}
-
static void bit_clear(struct vc_data *vc, struct fb_info *info, int sy,
int sx, int height, int width)
{
@@ -393,7 +378,6 @@ static int bit_update_start(struct fb_info *info)
void fbcon_set_bitops(struct fbcon_ops *ops)
{
- ops->bmove = bit_bmove;
ops->clear = bit_clear;
ops->putcs = bit_putcs;
ops->clear_margins = bit_clear_margins;
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 22bb3892f6bd..99ecd9a6d844 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -173,8 +173,6 @@ static void fbcon_putcs(struct vc_data *vc, const unsigned
short *s,
int count, int ypos, int xpos);
static void fbcon_clear_margins(struct vc_data *vc, int bottom_only);
static void fbcon_cursor(struct vc_data *vc, int mode);
-static void fbcon_bmove(struct vc_data *vc, int sy, int sx, int dy, int dx,
- int height, int width);
static int fbcon_switch(struct vc_data *vc);
static int fbcon_blank(struct
Re: [PATCH v1 4/4] drm/mediatek: add mt8195 hdmi TX support
Hi Chun-Kuang. Thank you for your input. I have tried to find commonalities between the two drivers but I didn't find enough shared code to warrant that architecture. I'll have another look, especially now that I'm more familiar with the driver. Regarding 2, I have removed as much functionalities as I could from the original vendor tree (like hdcp, hdr, cec...) to keep only HDMI audio and video TX. There might be some more things to remove, but I'm no expert in the domain and I'm working without access to mediatek datasheets and documentation. Though, at this stage I could split the patch in two with video first and then audio. I will try to work something out for a V2. Thx, Guillaume. Quoting Chun-Kuang Hu (2021-09-30 15:36:42) > Hi, Guillaume: > > This is a big patch, and I'm not familiar with this driver, so the > review process would be long. So I tell you about how I review this > patch, and if you could process according to my way, the process would > be more short. > > 1. Find the common part of all hdmi driver. > Even though mt8195 hdmi has many difference with other mediatek soc > hdmi driver, I would like to find the common part and have just one > copy of the common part. I expect there would three file finally: > > mtk_hdmi.c (the common part) > mtk_hdmi_mt8173.c (each soc special part) > mtk_hdmi_mt8195.c (each soc special part) > > But this would be difficult in this stage, so you could temporarily > have these three file: > > mtk_hdmi_common.c (the common part) > mtk_hdmi.c (each soc special part) > mtk_hdmi_mt8195.c (each soc special part) > > When review is almost done, then change the file name as I wish. > > 2. The first patch has only basic function, separate advance function > to another patch. > When comparing mt8195 hdmi driver with other hdmi driver, if mt8195 > hdmi driver has some function that other hdmi does not have, I would > think that function is advance function and should be separate to > another patch. > > If you follow this way, I think the review process would be short. > Because this patch is big, I would just review partial part each time. > > Regards, > Chun-Kuang. > > > Guillaume Ranquet 於 2021年9月29日 週三 下午5:47寫道： > > > > Add basic hdmi TX support for the mediatek mt8195 SoCs > > > > Signed-off-by: Guillaume Ranquet > > --- > > drivers/gpu/drm/mediatek/Kconfig | 10 + > > drivers/gpu/drm/mediatek/Makefile |4 +- > > drivers/gpu/drm/mediatek/mtk_mt8195_hdmi.c| 2293 + > > drivers/gpu/drm/mediatek/mtk_mt8195_hdmi.h| 128 + > > .../gpu/drm/mediatek/mtk_mt8195_hdmi_ddc.c| 530 > > .../gpu/drm/mediatek/mtk_mt8195_hdmi_ddc.h| 20 + > > .../gpu/drm/mediatek/mtk_mt8195_hdmi_regs.h | 329 +++ > > 7 files changed, 3313 insertions(+), 1 deletion(-) > > create mode 100644 drivers/gpu/drm/mediatek/mtk_mt8195_hdmi.c > > create mode 100644 drivers/gpu/drm/mediatek/mtk_mt8195_hdmi.h > > create mode 100644 drivers/gpu/drm/mediatek/mtk_mt8195_hdmi_ddc.c > > create mode 100644 drivers/gpu/drm/mediatek/mtk_mt8195_hdmi_ddc.h > > create mode 100644 drivers/gpu/drm/mediatek/mtk_mt8195_hdmi_regs.h > > > > diff --git a/drivers/gpu/drm/mediatek/Kconfig > > b/drivers/gpu/drm/mediatek/Kconfig > > index 2976d21e9a34a..517d065f0511b 100644 > > --- a/drivers/gpu/drm/mediatek/Kconfig > > +++ b/drivers/gpu/drm/mediatek/Kconfig > > @@ -28,3 +28,13 @@ config DRM_MEDIATEK_HDMI > > select PHY_MTK_HDMI > > help > > DRM/KMS HDMI driver for Mediatek SoCs > > + > > +config DRM_MEDIATEK_HDMI_MT8195_SUSPEND_LOW_POWER > > + tristate "DRM HDMI SUSPEND LOW POWER Support for Mediatek mt8195 > > SoCs" > > + depends on DRM_MEDIATEK_HDMI > > + help > > + DRM/KMS HDMI SUSPEND_LOW_POWER for Mediatek SoCs. > > + Choose this option if you want to disable/enable > > + clock and power domain when platform enter suspend, > > + and this config depends on DRM_MEDIATEK_HDMI. > > + > > diff --git a/drivers/gpu/drm/mediatek/Makefile > > b/drivers/gpu/drm/mediatek/Makefile > > index 29098d7c8307c..736f0816083d0 100644 > > --- a/drivers/gpu/drm/mediatek/Makefile > > +++ b/drivers/gpu/drm/mediatek/Makefile > > @@ -18,6 +18,8 @@ obj-$(CONFIG_DRM_MEDIATEK) += mediatek-drm.o > > > > mediatek-drm-hdmi-objs := mtk_cec.o \ > > mtk_hdmi.o \ > > - mtk_hdmi_ddc.o > > + mtk_hdmi_ddc.o \ > > + mtk_mt8195_hdmi.o \ > > + mtk_mt8195_hdmi_ddc.o \ > > > > obj-$(CONFIG_DRM_MEDIATEK_HDMI) += mediatek-drm-hdmi.o > > diff --git a/drivers/gpu/drm/mediatek/mtk_mt8195_hdmi.c > > b/drivers/gpu/drm/mediatek/mtk_mt8195_hdmi.c > > new file mode 100644 > > index 0..46c7c8af524ac > > --- /dev/null > >
Re: [PATCH] drm/amdgpu: use generic fb helpers instead of setting up AMD own's.
@Christian Koenig
Have you had a chance to look at this yet?
Alex
On Mon, Sep 20, 2021 at 4:44 AM Thomas Zimmermann wrote:
>
> Hi
>
> Am 20.09.21 um 10:41 schrieb Thomas Zimmermann:
> > (cc'ing dri-devel)
> >
> > Hi
> >
> > Am 13.09.21 um 16:36 schrieb Alex Deucher:
> >> On Thu, Sep 9, 2021 at 11:25 PM Evan Quan wrote:
> >>>
> >>> With the shadow buffer support from generic framebuffer emulation, it's
> >>> possible now to have runpm kicked when no update for console.
> >>>
> >>> Change-Id: I285472c9100ee6f649d3f3f3548f402b9cd34eaf
> >>> Signed-off-by: Evan Quan
> >>> Acked-by: Christian König
> >>
> >> Reviewed-by: Alex Deucher
> >
> > There was a long discussion about this change within radeon and the
> > result was that it cannot be done. [1] I don't remember the full
> > details, but semantics of the vmap/vunmap for dma-bufs were not
> > compatible IIRC. And the resolution was a redesign of the API.
>
> I posted a patchset with a new interface at [1].
>
> Best regards
> Thomas
>
> [1]
> https://lore.kernel.org/dri-devel/20201209142527.26415-1-tzimmerm...@suse.de/
>
> >
> > If that has changed, I'd be happy to see this patch merged. Otherwise,
> > it should better not be taken.
> >
> > Best regards
> > Thomas
> >
> > [1] https://patchwork.freedesktop.org/patch/400054/?series=83765&rev=1
> >
> >>
> >>> --
> >>> v1->v2:
> >>>- rename amdgpu_align_pitch as amdgpu_gem_align_pitch to align with
> >>> other APIs from the same file (Alex)
> >>> ---
> >>> drivers/gpu/drm/amd/amdgpu/Makefile | 2 +-
> >>> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 12 +-
> >>> drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 11 +-
> >>> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 13 +
> >>> drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c | 388
> >>> drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 30 +-
> >>> drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h| 20 -
> >>> 7 files changed, 50 insertions(+), 426 deletions(-)
> >>> delete mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
> >>>
> >>> diff --git a/drivers/gpu/drm/amd/amdgpu/Makefile
> >>> b/drivers/gpu/drm/amd/amdgpu/Makefile
> >>> index 8d0748184a14..73a2151ee43f 100644
> >>> --- a/drivers/gpu/drm/amd/amdgpu/Makefile
> >>> +++ b/drivers/gpu/drm/amd/amdgpu/Makefile
> >>> @@ -45,7 +45,7 @@ amdgpu-y += amdgpu_device.o amdgpu_kms.o \
> >>> amdgpu_atombios.o atombios_crtc.o amdgpu_connectors.o \
> >>> atom.o amdgpu_fence.o amdgpu_ttm.o amdgpu_object.o
> >>> amdgpu_gart.o \
> >>> amdgpu_encoders.o amdgpu_display.o amdgpu_i2c.o \
> >>> - amdgpu_fb.o amdgpu_gem.o amdgpu_ring.o \
> >>> + amdgpu_gem.o amdgpu_ring.o \
> >>> amdgpu_cs.o amdgpu_bios.o amdgpu_benchmark.o amdgpu_test.o \
> >>> atombios_dp.o amdgpu_afmt.o amdgpu_trace_points.o \
> >>> atombios_encoders.o amdgpu_sa.o atombios_i2c.o \
> >>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> >>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> >>> index 682d459e992a..bcc308b7f826 100644
> >>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> >>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> >>> @@ -3695,8 +3695,6 @@ int amdgpu_device_init(struct amdgpu_device *adev,
> >>> /* Get a log2 for easy divisions. */
> >>> adev->mm_stats.log2_max_MBps = ilog2(max(1u, max_MBps));
> >>>
> >>> - amdgpu_fbdev_init(adev);
> >>> -
> >>> r = amdgpu_pm_sysfs_init(adev);
> >>> if (r) {
> >>> adev->pm_sysfs_en = false;
> >>> @@ -3854,8 +3852,6 @@ void amdgpu_device_fini_hw(struct amdgpu_device
> >>> *adev)
> >>> amdgpu_ucode_sysfs_fini(adev);
> >>> sysfs_remove_files(&adev->dev->kobj, amdgpu_dev_attributes);
> >>>
> >>> - amdgpu_fbdev_fini(adev);
> >>> -
> >>> amdgpu_irq_fini_hw(adev);
> >>>
> >>> amdgpu_device_ip_fini_early(adev);
> >>> @@ -3931,7 +3927,7 @@ int amdgpu_device_suspend(struct drm_device
> >>> *dev, bool fbcon)
> >>> drm_kms_helper_poll_disable(dev);
> >>>
> >>> if (fbcon)
> >>> - amdgpu_fbdev_set_suspend(adev, 1);
> >>> +
> >>> drm_fb_helper_set_suspend_unlocked(adev_to_drm(adev)->fb_helper, true);
> >>>
> >>> cancel_delayed_work_sync(&adev->delayed_init_work);
> >>>
> >>> @@ -4009,7 +4005,7 @@ int amdgpu_device_resume(struct drm_device
> >>> *dev, bool fbcon)
> >>> flush_delayed_work(&adev->delayed_init_work);
> >>>
> >>> if (fbcon)
> >>> - amdgpu_fbdev_set_suspend(adev, 0);
> >>> +
> >>> drm_fb_helper_set_suspend_unlocked(adev_to_drm(adev)->fb_helper, false);
> >>>
> >>> drm_kms_helper_poll_enable(dev);
> >>>
> >>> @@ -4638,7 +4634,7 @@ int amdgpu_do_asic_reset(struct list_head
> >>> *device_list_handle,
> >>> if (r)
> >>> goto out;
> >>>
> >>> - amdgpu_fbdev_set_suspend(tmp_adev, 0);
> >>> +
> >>>
[PATCH v6, 0/1] drm/mediatek: add dither 6 setting
base v5.15 Yongqiang Niu (1): drm/mediatek: add dither 6 setting drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 3 +++ 1 file changed, 3 insertions(+) -- 2.25.1
[PATCHi v6, 1/1] drm/mediatek: add dither 6 setting
dither 6 setting is missed in a6b7c98afdca
bit 1 is lfsr_en( "Enables LFSR-type dithering"), need enable
bit 2 is rdither_en(Enables running order dithering), need disable
Fixes: a6b7c98afdca(drm/mediatek: add mtk_dither_set_common())
Signed-off-by: Yongqiang Niu
Change-Id: I30258dd4129d17fb7d94b1714d78bc133e88338e
---
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index 99cbf44463e4..33e8789fde8a 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -26,6 +26,8 @@
#define DISP_OD_CFG0x0020
#define DISP_OD_SIZE 0x0030
#define DISP_DITHER_5 0x0114
+#define DISP_DITHER_6 0x0118
+#define LFSR_ENBIT(1)
#define DISP_DITHER_7 0x011c
#define DISP_DITHER_15 0x013c
#define DISP_DITHER_16 0x0140
@@ -135,6 +137,7 @@ void mtk_dither_set_common(void __iomem *regs, struct
cmdq_client_reg *cmdq_reg,
if (bpc >= MTK_MIN_BPC) {
mtk_ddp_write(cmdq_pkt, 0, cmdq_reg, regs, DISP_DITHER_5);
+ mtk_ddp_write_mask(cmdq_pkt, LFSR_EN, cmdq_reg, regs,
DISP_DITHER_6, LFSR_EN);
mtk_ddp_write(cmdq_pkt, 0, cmdq_reg, regs, DISP_DITHER_7);
mtk_ddp_write(cmdq_pkt,
DITHER_LSB_ERR_SHIFT_R(MTK_MAX_BPC - bpc) |
--
2.25.1
Re: [PATCH] drm: document pre-multiplied assumptions
On Wed, Sep 29, 2021 at 04:07:01PM +0300, Pekka Paalanen wrote: > On Wed, 29 Sep 2021 09:54:14 + > Simon Ser wrote: > > > When a plane is missing the "alpha blend mode" property, KMS drivers > > will use the pre-multiplied mode. > > > > Signed-off-by: Simon Ser > > Cc: Daniel Vetter > > Cc: Pekka Paalanen > > --- > > drivers/gpu/drm/drm_blend.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c > > index ec37cbfabb50..eebb32ba84d7 100644 > > --- a/drivers/gpu/drm/drm_blend.c > > +++ b/drivers/gpu/drm/drm_blend.c > > @@ -185,6 +185,9 @@ > > * plane does not expose the "alpha" property, then this is > > * assumed to be 1.0 > > * > > + * When a plane is missing this property, the plane uses the > > + * "Pre-multiplied" equation. > > + * > > * Note that all the property extensions described here apply either to the > > * plane or the CRTC (e.g. for the background color, which currently is not > > * exposed and assumed to be black). > > Hi Simon, > > thank you! :-D > > I have no idea if that's correct though, but also nothing against it, > and it does help with what I ranted about in > https://lists.freedesktop.org/archives/wayland-devel/2021-September/041993.html > so is it appropriate to offer my > > Acked-by: Pekka Paalanen I think if it's not correct we can add an immutable prop like Ville suggested for that driver. -Daniel > > ? > > > Thanks, > pq -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [RFC PATCH v2 2/2] RDMA/rxe: Add dma-buf support
On Wed, Sep 29, 2021 at 01:19:05PM +0900, Shunsuke Mie wrote:
> Implement a ib device operation ‘reg_user_mr_dmabuf’. Generate a
> rxe_map from the memory space linked the passed dma-buf.
>
> Signed-off-by: Shunsuke Mie
> ---
> drivers/infiniband/sw/rxe/rxe_loc.h | 2 +
> drivers/infiniband/sw/rxe/rxe_mr.c| 118 ++
> drivers/infiniband/sw/rxe/rxe_verbs.c | 34
> drivers/infiniband/sw/rxe/rxe_verbs.h | 2 +
> 4 files changed, 156 insertions(+)
>
> diff --git a/drivers/infiniband/sw/rxe/rxe_loc.h
> b/drivers/infiniband/sw/rxe/rxe_loc.h
> index 1ca43b859d80..8bc19ea1a376 100644
> --- a/drivers/infiniband/sw/rxe/rxe_loc.h
> +++ b/drivers/infiniband/sw/rxe/rxe_loc.h
> @@ -75,6 +75,8 @@ u8 rxe_get_next_key(u32 last_key);
> void rxe_mr_init_dma(struct rxe_pd *pd, int access, struct rxe_mr *mr);
> int rxe_mr_init_user(struct rxe_pd *pd, u64 start, u64 length, u64 iova,
>int access, struct rxe_mr *mr);
> +int rxe_mr_dmabuf_init_user(struct rxe_pd *pd, int fd, u64 start, u64 length,
> + u64 iova, int access, struct rxe_mr *mr);
> int rxe_mr_init_fast(struct rxe_pd *pd, int max_pages, struct rxe_mr *mr);
> int rxe_mr_copy(struct rxe_mr *mr, u64 iova, void *addr, int length,
> enum rxe_mr_copy_dir dir);
> diff --git a/drivers/infiniband/sw/rxe/rxe_mr.c
> b/drivers/infiniband/sw/rxe/rxe_mr.c
> index 53271df10e47..af6ef671c3a5 100644
> --- a/drivers/infiniband/sw/rxe/rxe_mr.c
> +++ b/drivers/infiniband/sw/rxe/rxe_mr.c
> @@ -4,6 +4,7 @@
> * Copyright (c) 2015 System Fabric Works, Inc. All rights reserved.
> */
>
> +#include
> #include "rxe.h"
> #include "rxe_loc.h"
>
> @@ -245,6 +246,120 @@ int rxe_mr_init_user(struct rxe_pd *pd, u64 start, u64
> length, u64 iova,
> return err;
> }
>
> +static int rxe_map_dmabuf_mr(struct rxe_mr *mr,
> + struct ib_umem_dmabuf *umem_dmabuf)
> +{
> + struct rxe_map_set *set;
> + struct rxe_phys_buf *buf = NULL;
> + struct rxe_map **map;
> + void *vaddr, *vaddr_end;
> + int num_buf = 0;
> + int err;
> + size_t remain;
> +
> + mr->dmabuf_map = kzalloc(sizeof &mr->dmabuf_map, GFP_KERNEL);
dmabuf_maps are just tagged pointers (and we could shrink them to actually
just a tagged pointer if anyone cares about the overhead of the separate
bool), allocating them seperately is overkill.
> + if (!mr->dmabuf_map) {
> + err = -ENOMEM;
> + goto err_out;
> + }
> +
> + err = dma_buf_vmap(umem_dmabuf->dmabuf, mr->dmabuf_map);
> + if (err)
> + goto err_free_dmabuf_map;
> +
> + set = mr->cur_map_set;
> + set->page_shift = PAGE_SHIFT;
> + set->page_mask = PAGE_SIZE - 1;
> +
> + map = set->map;
> + buf = map[0]->buf;
> +
> + vaddr = mr->dmabuf_map->vaddr;
dma_buf_map can be an __iomem too, you shouldn't dig around in this, but
use the dma-buf-map.h helpers instead. On x86 (and I think also on most
arm) it doesn't matter, but it's kinda not very nice in a pure software
driver.
If anything is missing in dma-buf-map.h wrappers just add more.
Or alternatively you need to fail the import if you can't handle __iomem.
Aside from these I think the dma-buf side here for cpu access looks
reasonable now.
-Daniel
> + vaddr_end = vaddr + umem_dmabuf->dmabuf->size;
> + remain = umem_dmabuf->dmabuf->size;
> +
> + for (; remain; vaddr += PAGE_SIZE) {
> + if (num_buf >= RXE_BUF_PER_MAP) {
> + map++;
> + buf = map[0]->buf;
> + num_buf = 0;
> + }
> +
> + buf->addr = (uintptr_t)vaddr;
> + if (remain >= PAGE_SIZE)
> + buf->size = PAGE_SIZE;
> + else
> + buf->size = remain;
> + remain -= buf->size;
> +
> + num_buf++;
> + buf++;
> + }
> +
> + return 0;
> +
> +err_free_dmabuf_map:
> + kfree(mr->dmabuf_map);
> +err_out:
> + return err;
> +}
> +
> +static void rxe_unmap_dmabuf_mr(struct rxe_mr *mr)
> +{
> + struct ib_umem_dmabuf *umem_dmabuf = to_ib_umem_dmabuf(mr->umem);
> +
> + dma_buf_vunmap(umem_dmabuf->dmabuf, mr->dmabuf_map);
> + kfree(mr->dmabuf_map);
> +}
> +
> +int rxe_mr_dmabuf_init_user(struct rxe_pd *pd, int fd, u64 start, u64 length,
> + u64 iova, int access, struct rxe_mr *mr)
> +{
> + struct ib_umem_dmabuf *umem_dmabuf;
> + struct rxe_map_set *set;
> + int err;
> +
> + umem_dmabuf = ib_umem_dmabuf_get(pd->ibpd.device, start, length, fd,
> + access, NULL);
> + if (IS_ERR(umem_dmabuf)) {
> + err = PTR_ERR(umem_dmabuf);
> + goto err_out;
> + }
> +
> + rxe_mr_init(access, mr);
> +
> + err = rxe_mr_alloc(mr, ib_umem_num_pages(&umem_dmabuf->umem), 0);
> + if (err) {
> + pr_warn("%s: Unable to all
Re: [PATCH] drm/locking: add backtrace for locking contended locks without backoff
On Wed, Sep 29, 2021 at 01:32:41AM +0300, Jani Nikula wrote:
> If drm_modeset_lock() returns -EDEADLK, the caller is supposed to drop
> all currently held locks using drm_modeset_backoff(). Failing to do so
> will result in warnings and backtraces on the paths trying to lock a
> contended lock. Add support for optionally printing the backtrace on the
> path that hit the deadlock and didn't gracefully handle the situation.
>
> For example, the patch [1] inadvertently dropped the return value check
> and error return on replacing calc_watermark_data() with
> intel_compute_global_watermarks(). The backtraces on the subsequent
> locking paths hitting WARN_ON(ctx->contended) were unhelpful, but adding
> the backtrace to the deadlock path produced this helpful printout:
>
> <7> [98.002465] drm_modeset_lock attempting to lock a contended lock without
> backoff:
>drm_modeset_lock+0x107/0x130
>drm_atomic_get_plane_state+0x76/0x150
>skl_compute_wm+0x251d/0x2b20 [i915]
>intel_atomic_check+0x1942/0x29e0 [i915]
>drm_atomic_check_only+0x554/0x910
>drm_atomic_nonblocking_commit+0xe/0x50
>drm_mode_atomic_ioctl+0x8c2/0xab0
>drm_ioctl_kernel+0xac/0x140
>
> Add new CONFIG_DRM_DEBUG_MODESET_LOCK to enable modeset lock debugging
> with stack depot and trace.
>
> [1] https://lore.kernel.org/r/20210924114741.15940-4-jani.nik...@intel.com
>
> Cc: Daniel Vetter
> Cc: Dave Airlie
> Signed-off-by: Jani Nikula
I wonder whether we shouldn't just enable this when lock debugging is
enabled? Otherwise we need to make sure CI have this set or it's not very
useful. Or at least a default y if CONFIG_DEBUG_WW_MUTEX_SLOWPATH or
something like that.
Either way:
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/Kconfig| 13
> drivers/gpu/drm/drm_modeset_lock.c | 49 --
> include/drm/drm_modeset_lock.h | 8 +
> 3 files changed, 68 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index b17e231ca6f7..7334975c788b 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -100,6 +100,19 @@ config DRM_DEBUG_DP_MST_TOPOLOGY_REFS
>This has the potential to use a lot of memory and print some very
>large kernel messages. If in doubt, say "N".
>
> +config DRM_DEBUG_MODESET_LOCK
> + bool "Enable backtrace history for lock contention"
> + depends on STACKTRACE_SUPPORT
> + select STACKDEPOT
> + depends on EXPERT
> + help
> + Enable debug tracing of failures to gracefully handle drm modeset lock
> + contention. A history of each drm modeset lock path hitting -EDEADLK
> + will be saved until gracefully handled, and the backtrace will be
> + printed when attempting to lock a contended lock.
> +
> + If in doubt, say "N".
> +
> config DRM_FBDEV_EMULATION
> bool "Enable legacy fbdev support for your modesetting driver"
> depends on DRM
> diff --git a/drivers/gpu/drm/drm_modeset_lock.c
> b/drivers/gpu/drm/drm_modeset_lock.c
> index bf8a6e823a15..4d32b61fa1fd 100644
> --- a/drivers/gpu/drm/drm_modeset_lock.c
> +++ b/drivers/gpu/drm/drm_modeset_lock.c
> @@ -25,6 +25,7 @@
> #include
> #include
> #include
> +#include
>
> /**
> * DOC: kms locking
> @@ -77,6 +78,45 @@
>
> static DEFINE_WW_CLASS(crtc_ww_class);
>
> +#if IS_ENABLED(CONFIG_DRM_DEBUG_MODESET_LOCK)
> +static noinline depot_stack_handle_t __stack_depot_save(void)
> +{
> + unsigned long entries[8];
> + unsigned int n;
> +
> + n = stack_trace_save(entries, ARRAY_SIZE(entries), 1);
> +
> + return stack_depot_save(entries, n, GFP_NOWAIT | __GFP_NOWARN);
> +}
> +
> +static void __stack_depot_print(depot_stack_handle_t stack_depot)
> +{
> + struct drm_printer p = drm_debug_printer("drm_modeset_lock");
> + unsigned long *entries;
> + unsigned int nr_entries;
> + char *buf;
> +
> + buf = kmalloc(PAGE_SIZE, GFP_NOWAIT | __GFP_NOWARN);
> + if (!buf)
> + return;
> +
> + nr_entries = stack_depot_fetch(stack_depot, &entries);
> + stack_trace_snprint(buf, PAGE_SIZE, entries, nr_entries, 2);
> +
> + drm_printf(&p, "attempting to lock a contended lock without
> backoff:\n%s", buf);
> +
> + kfree(buf);
> +}
> +#else /* CONFIG_DRM_DEBUG_MODESET_LOCK */
> +static depot_stack_handle_t __stack_depot_save(void)
> +{
> + return 0;
> +}
> +static void __stack_depot_print(depot_stack_handle_t stack_depot)
> +{
> +}
> +#endif /* CONFIG_DRM_DEBUG_MODESET_LOCK */
> +
> /**
> * drm_modeset_lock_all - take all modeset locks
> * @dev: DRM device
> @@ -225,7 +265,9 @@ EXPORT_SYMBOL(drm_modeset_acquire_fini);
> */
> void drm_modeset_drop_locks(struct drm_modeset_acquire_ctx *ctx)
> {
> - WARN_ON(ctx->contended);
> + if (WARN_ON(ctx->contended))
> + __stack_depot_print(ctx->stack_depot);
> +
> while (!list_empty(&ctx->locked)) {
> struct drm_mode
Re: [PATCH] [RESEND] drm: fb_helper: fix CONFIG_FB dependency
On Mon, Sep 27, 2021 at 09:23:45AM -0700, Kees Cook wrote:
> On Mon, Sep 27, 2021 at 04:28:02PM +0200, Arnd Bergmann wrote:
> > From: Arnd Bergmann
> >
> > With CONFIG_FB=m and CONFIG_DRM=y, we get a link error in the fb helper:
> >
> > aarch64-linux-ld: drivers/gpu/drm/drm_fb_helper.o: in function
> > `drm_fb_helper_alloc_fbi':
> > (.text+0x10cc): undefined reference to `framebuffer_alloc'
> >
> > Tighten the dependency so it is only allowed in the case that DRM can
> > link against FB.
> >
> > Fixes: f611b1e7624c ("drm: Avoid circular dependencies for CONFIG_FB")
> > Link: https://lore.kernel.org/all/20210721152211.2706171-1-a...@kernel.org/
> > Signed-off-by: Arnd Bergmann
>
> Thanks for fixing this!
>
> Reviewed-by: Kees Cook
Stuffed into drm-misc-next.
Arnd, I guess I still can't volunteer you for commit rights so I don't
have to bother with this anymore? It's nice to be lazy and comfy :-)
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH] drm/i915: Use direction definition DMA_BIDIRECTIONAL instead of PCI_DMA_BIDIRECTIONAL
On Sat, Sep 25, 2021 at 08:46:12PM +0800, Cai Huoqing wrote:
> Replace direction definition PCI_DMA_BIDIRECTIONAL
> with DMA_BIDIRECTIONAL, because it helps to enhance readability
> and avoid possible inconsistency.
>
> Signed-off-by: Cai Huoqing
Applied to drm-intel-gt-next, thanks for the patch.
-Daniel
> ---
> drivers/gpu/drm/i915/gt/intel_region_lmem.c | 4 ++--
> drivers/gpu/drm/i915/gvt/gtt.c | 17 -
> drivers/gpu/drm/i915/gvt/kvmgt.c| 4 ++--
> drivers/gpu/drm/i915/i915_gem_gtt.c | 4 ++--
> 4 files changed, 14 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_region_lmem.c
> b/drivers/gpu/drm/i915/gt/intel_region_lmem.c
> index a74b72f50cc9..afb35d2e5c73 100644
> --- a/drivers/gpu/drm/i915/gt/intel_region_lmem.c
> +++ b/drivers/gpu/drm/i915/gt/intel_region_lmem.c
> @@ -32,7 +32,7 @@ static int init_fake_lmem_bar(struct intel_memory_region
> *mem)
> mem->remap_addr = dma_map_resource(i915->drm.dev,
> mem->region.start,
> mem->fake_mappable.size,
> -PCI_DMA_BIDIRECTIONAL,
> +DMA_BIDIRECTIONAL,
> DMA_ATTR_FORCE_CONTIGUOUS);
> if (dma_mapping_error(i915->drm.dev, mem->remap_addr)) {
> drm_mm_remove_node(&mem->fake_mappable);
> @@ -62,7 +62,7 @@ static void release_fake_lmem_bar(struct
> intel_memory_region *mem)
> dma_unmap_resource(mem->i915->drm.dev,
> mem->remap_addr,
> mem->fake_mappable.size,
> -PCI_DMA_BIDIRECTIONAL,
> +DMA_BIDIRECTIONAL,
> DMA_ATTR_FORCE_CONTIGUOUS);
> }
>
> diff --git a/drivers/gpu/drm/i915/gvt/gtt.c b/drivers/gpu/drm/i915/gvt/gtt.c
> index e5c2fdfc20e3..53d0cb327539 100644
> --- a/drivers/gpu/drm/i915/gvt/gtt.c
> +++ b/drivers/gpu/drm/i915/gvt/gtt.c
> @@ -745,7 +745,7 @@ static void ppgtt_free_spt(struct intel_vgpu_ppgtt_spt
> *spt)
> trace_spt_free(spt->vgpu->id, spt, spt->guest_page.type);
>
> dma_unmap_page(kdev, spt->shadow_page.mfn << I915_GTT_PAGE_SHIFT, 4096,
> -PCI_DMA_BIDIRECTIONAL);
> +DMA_BIDIRECTIONAL);
>
> radix_tree_delete(&spt->vgpu->gtt.spt_tree, spt->shadow_page.mfn);
>
> @@ -849,7 +849,7 @@ static struct intel_vgpu_ppgtt_spt *ppgtt_alloc_spt(
>*/
> spt->shadow_page.type = type;
> daddr = dma_map_page(kdev, spt->shadow_page.page,
> - 0, 4096, PCI_DMA_BIDIRECTIONAL);
> + 0, 4096, DMA_BIDIRECTIONAL);
> if (dma_mapping_error(kdev, daddr)) {
> gvt_vgpu_err("fail to map dma addr\n");
> ret = -EINVAL;
> @@ -865,7 +865,7 @@ static struct intel_vgpu_ppgtt_spt *ppgtt_alloc_spt(
> return spt;
>
> err_unmap_dma:
> - dma_unmap_page(kdev, daddr, PAGE_SIZE, PCI_DMA_BIDIRECTIONAL);
> + dma_unmap_page(kdev, daddr, PAGE_SIZE, DMA_BIDIRECTIONAL);
> err_free_spt:
> free_spt(spt);
> return ERR_PTR(ret);
> @@ -2409,8 +2409,7 @@ static int alloc_scratch_pages(struct intel_vgpu *vgpu,
> return -ENOMEM;
> }
>
> - daddr = dma_map_page(dev, virt_to_page(scratch_pt), 0,
> - 4096, PCI_DMA_BIDIRECTIONAL);
> + daddr = dma_map_page(dev, virt_to_page(scratch_pt), 0, 4096,
> DMA_BIDIRECTIONAL);
> if (dma_mapping_error(dev, daddr)) {
> gvt_vgpu_err("fail to dmamap scratch_pt\n");
> __free_page(virt_to_page(scratch_pt));
> @@ -2461,7 +2460,7 @@ static int release_scratch_page_tree(struct intel_vgpu
> *vgpu)
> if (vgpu->gtt.scratch_pt[i].page != NULL) {
> daddr = (dma_addr_t)(vgpu->gtt.scratch_pt[i].page_mfn <<
> I915_GTT_PAGE_SHIFT);
> - dma_unmap_page(dev, daddr, 4096, PCI_DMA_BIDIRECTIONAL);
> + dma_unmap_page(dev, daddr, 4096, DMA_BIDIRECTIONAL);
> __free_page(vgpu->gtt.scratch_pt[i].page);
> vgpu->gtt.scratch_pt[i].page = NULL;
> vgpu->gtt.scratch_pt[i].page_mfn = 0;
> @@ -2741,7 +2740,7 @@ int intel_gvt_init_gtt(struct intel_gvt *gvt)
> }
>
> daddr = dma_map_page(dev, virt_to_page(page), 0,
> - 4096, PCI_DMA_BIDIRECTIONAL);
> + 4096, DMA_BIDIRECTIONAL);
> if (dma_mapping_error(dev, daddr)) {
> gvt_err("fail to dmamap scratch ggtt page\n");
> __free_page(virt_to_page(page));
> @@ -2755,7 +2754,7 @@ int intel_gvt_init_gtt(struct intel_gvt *gvt)
> ret = setup_spt_oos(gvt);
> if (ret) {
> gvt_err("fail to initialize SPT oos\n");
> - dma_unma
Re: [PATCH] video: fbdev: gbefb: Only instantiate device when built for IP32
On Tue, Sep 21, 2021 at 10:21:02PM +0100, Mark Brown wrote:
> The gbefb driver not only registers a driver but also the device for that
> driver. This is all well and good when run on the IP32 machines that are
> supported by the driver but since the driver supports building with
> COMPILE_TEST we might also be building on other platforms which do not have
> this hardware and will crash instantiating the driver. Add an IS_ENABLED()
> check so we compile out the device registration if we don't have the Kconfig
> option for the machine enabled.
>
> Fixes: 552ccf6b259d290c0c ("video: fbdev: gbefb: add COMPILE_TEST support")
> Signed-off-by: Mark Brown
> Cc: Bartlomiej Zolnierkiewicz
Stuffed into drm-misc-fixes, thanks for the patch.
-Daniel
> ---
> drivers/video/fbdev/gbefb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/video/fbdev/gbefb.c b/drivers/video/fbdev/gbefb.c
> index c5b99a4861e8..6b4d5a7f3e15 100644
> --- a/drivers/video/fbdev/gbefb.c
> +++ b/drivers/video/fbdev/gbefb.c
> @@ -1267,7 +1267,7 @@ static struct platform_device *gbefb_device;
> static int __init gbefb_init(void)
> {
> int ret = platform_driver_register(&gbefb_driver);
> - if (!ret) {
> + if (IS_ENABLED(CONFIG_SGI_IP32) && !ret) {
> gbefb_device = platform_device_alloc("gbefb", 0);
> if (gbefb_device) {
> ret = platform_device_add(gbefb_device);
> --
> 2.20.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH] dma-buf: fix and rework dma_buf_poll v7
On Thu, Sep 30, 2021 at 01:32:28PM +0200, Christian König wrote: > Am 30.09.21 um 12:26 schrieb Daniel Vetter: > > On Thu, Sep 30, 2021 at 11:48:42AM +0200, Christian König wrote: > > > > > > Am 30.09.21 um 11:00 schrieb Daniel Vetter: > > > > On Wed, Sep 22, 2021 at 01:08:44PM +0200, Christian König wrote: > > > > > Totally forgotten to ping once more about that. > > > > > > > > > > Michel has tested this now and I think we should push it ASAP. So can > > > > > I get > > > > > an rb? > > > > spin_lock_irq(&dmabuf->poll.lock); > > > > if (dcb->active) > > > > events &= ~EPOLLIN; > > > > else > > > > dcb->active = EPOLLIN; > > > > spin_unlock_irq(&dmabuf->poll.lock); > > > > > > > > > > > > This pattern (and same for EPOLLOUT) makes no sense to me. I guess the > > > > intent is that this filters out events for which we're already > > > > listening, > > > > but: > > > > > > > > - it checks for any active event, not the specific one > > > Which is correct. We now use one dcb for EPOLLIN and another one for > > > EPOLLOUT. > > > > > > We could make that a boolean instead if that makes it cleaner. > > Ha yes I missed that. Boolean sounds much better. > > > > - if we're waiting already and new fences have been added, wont we miss > > > > them? > > > No, when we are already waiting the callback will sooner or later fire and > > > result in a re-check. > > > > > > > Or does this all work because the poll machinery restarts everything > > > > again? > > > Yes, exactly that. Otherwise waiting for multiple fences wouldn't work > > > either. > > Ok with that clarified can you cut a v8 with booleans and I whack an r-b > > on that? Or just include it, I'm massively burried here and trying to dig > > out :-/ > > > > Reviewed-by: Daniel Vetter (with the booleans) > > My bad, boolean won't work because we also use the flags for the call to > "wake_up_locked_poll(dcb->poll, dcb->active);". > > Anyway that doesn't really change anything on the logic and I inherited that > handling from the existing code, just moved it around a bit. Hm yeah. I guess Reviewed-by: Daniel Vetter But this poll stuff just massively confuses me. -Daniel > > Christian. > > > > > -Daniel > > > Regards, > > > Christian. > > > > > > > I'm totally confused here for sure. The other changes in the patch look > > > > good though. > > > > -Daniel > > > > > > > > > Thanks, > > > > > Christian. > > > > > > > > > > Am 23.07.21 um 10:04 schrieb Michel Dänzer: > > > > > > On 2021-07-20 3:11 p.m., Christian König wrote: > > > > > > > Daniel pointed me towards this function and there are multiple > > > > > > > obvious problems > > > > > > > in the implementation. > > > > > > > > > > > > > > First of all the retry loop is not working as intended. In > > > > > > > general the retry > > > > > > > makes only sense if you grab the reference first and then check > > > > > > > the sequence > > > > > > > values. > > > > > > > > > > > > > > Then we should always also wait for the exclusive fence. > > > > > > > > > > > > > > It's also good practice to keep the reference around when > > > > > > > installing callbacks > > > > > > > to fences you don't own. > > > > > > > > > > > > > > And last the whole implementation was unnecessary complex and > > > > > > > rather hard to > > > > > > > understand which could lead to probably unexpected behavior of > > > > > > > the IOCTL. > > > > > > > > > > > > > > Fix all this by reworking the implementation from scratch. > > > > > > > Dropping the > > > > > > > whole RCU approach and taking the lock instead. > > > > > > > > > > > > > > Only mildly tested and needs a thoughtful review of the code. > > > > > > > > > > > > > > v2: fix the reference counting as well > > > > > > > v3: keep the excl fence handling as is for stable > > > > > > > v4: back to testing all fences, drop RCU > > > > > > > v5: handle in and out separately > > > > > > > v6: add missing clear of events > > > > > > > v7: change coding style as suggested by Michel, drop unused > > > > > > > variables > > > > > > > > > > > > > > Signed-off-by: Christian König > > > > > > > CC: sta...@vger.kernel.org > > > > > > Working fine with > > > > > > https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880 > > > > > > > > > > > > Tested-by: Michel Dänzer > > > > > > > > > > > > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH v13 16/35] usb: chipidea: tegra: Add runtime PM and OPP support
30.09.2021 17:06, Peter Chen пишет: > On 21-09-27 01:40:39, Dmitry Osipenko wrote: >> The Tegra USB controller belongs to the core power domain and we're going >> to enable GENPD support for the core domain. Now USB controller must be >> resumed using runtime PM API in order to initialize the USB power state. >> We already support runtime PM for the CI device, but CI's PM is separated >> from the RPM managed by tegra-usb driver. Add runtime PM and OPP support >> to the driver. >> >> Signed-off-by: Dmitry Osipenko >> --- >> drivers/usb/chipidea/ci_hdrc_tegra.c | 53 >> 1 file changed, 46 insertions(+), 7 deletions(-) ... > > I got below compile error if only compile this file, I think previous patches > should include the definition, if that, feel free to add my ack to this > patch. > > Acked-by: Peter Chen > > drivers/usb/chipidea/ci_hdrc_tegra.c:308:8: error: implicit declaration of > function ‘devm_tegra_core_dev_init_opp_table_common’; > did you mean ‘devm_tegra_core_dev_init_opp_table’? > [-Werror=implicit-function-declaration] > 308 | err = devm_tegra_core_dev_init_opp_table_common(&pdev->dev); > |^ > |devm_tegra_core_dev_init_opp_table That's correct, devm_tegra_core_dev_init_opp_table_common() is added by an earlier patch of this series. Thank you!
Re: [PATCH v13 16/35] usb: chipidea: tegra: Add runtime PM and OPP support
On 21-09-27 01:40:39, Dmitry Osipenko wrote:
> The Tegra USB controller belongs to the core power domain and we're going
> to enable GENPD support for the core domain. Now USB controller must be
> resumed using runtime PM API in order to initialize the USB power state.
> We already support runtime PM for the CI device, but CI's PM is separated
> from the RPM managed by tegra-usb driver. Add runtime PM and OPP support
> to the driver.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/usb/chipidea/ci_hdrc_tegra.c | 53
> 1 file changed, 46 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/usb/chipidea/ci_hdrc_tegra.c
> b/drivers/usb/chipidea/ci_hdrc_tegra.c
> index 60361141ac04..3142ef7ebe42 100644
> --- a/drivers/usb/chipidea/ci_hdrc_tegra.c
> +++ b/drivers/usb/chipidea/ci_hdrc_tegra.c
> @@ -7,6 +7,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include
> @@ -15,6 +16,8 @@
> #include
> #include
>
> +#include
> +
> #include "../host/ehci.h"
>
> #include "ci.h"
> @@ -278,6 +281,8 @@ static int tegra_usb_probe(struct platform_device *pdev)
> if (!usb)
> return -ENOMEM;
>
> + platform_set_drvdata(pdev, usb);
> +
> soc = of_device_get_match_data(&pdev->dev);
> if (!soc) {
> dev_err(&pdev->dev, "failed to match OF data\n");
> @@ -296,11 +301,17 @@ static int tegra_usb_probe(struct platform_device *pdev)
> return err;
> }
>
> - err = clk_prepare_enable(usb->clk);
> - if (err < 0) {
> - dev_err(&pdev->dev, "failed to enable clock: %d\n", err);
> + err = devm_pm_runtime_enable(&pdev->dev);
> + if (err)
> + return err;
> +
> + err = devm_tegra_core_dev_init_opp_table_common(&pdev->dev);
> + if (err)
> + return err;
> +
> + err = pm_runtime_resume_and_get(&pdev->dev);
> + if (err)
> return err;
> - }
>
> if (device_property_present(&pdev->dev, "nvidia,needs-double-reset"))
> usb->needs_double_reset = true;
> @@ -320,8 +331,6 @@ static int tegra_usb_probe(struct platform_device *pdev)
> if (err)
> goto fail_power_off;
>
> - platform_set_drvdata(pdev, usb);
> -
> /* setup and register ChipIdea HDRC device */
> usb->soc = soc;
> usb->data.name = "tegra-usb";
> @@ -350,7 +359,8 @@ static int tegra_usb_probe(struct platform_device *pdev)
> phy_shutdown:
> usb_phy_shutdown(usb->phy);
> fail_power_off:
> - clk_disable_unprepare(usb->clk);
> + pm_runtime_put(&pdev->dev);
> +
> return err;
> }
>
> @@ -360,15 +370,44 @@ static int tegra_usb_remove(struct platform_device
> *pdev)
>
> ci_hdrc_remove_device(usb->dev);
> usb_phy_shutdown(usb->phy);
> + pm_runtime_put(&pdev->dev);
> +
> + return 0;
> +}
> +
> +static int __maybe_unused tegra_usb_runtime_resume(struct device *dev)
> +{
> + struct tegra_usb *usb = dev_get_drvdata(dev);
> + int err;
> +
> + err = clk_prepare_enable(usb->clk);
> + if (err < 0) {
> + dev_err(dev, "failed to enable clock: %d\n", err);
> + return err;
> + }
> +
> + return 0;
> +}
> +
> +static int __maybe_unused tegra_usb_runtime_suspend(struct device *dev)
> +{
> + struct tegra_usb *usb = dev_get_drvdata(dev);
> +
> clk_disable_unprepare(usb->clk);
>
> return 0;
> }
>
> +static const struct dev_pm_ops tegra_usb_pm = {
> + SET_RUNTIME_PM_OPS(tegra_usb_runtime_suspend, tegra_usb_runtime_resume,
> +NULL)
> +};
> +
> static struct platform_driver tegra_usb_driver = {
> .driver = {
> .name = "tegra-usb",
> .of_match_table = tegra_usb_of_match,
> + .pm = &tegra_usb_pm,
> },
> .probe = tegra_usb_probe,
> .remove = tegra_usb_remove,
> --
> 2.32.0
>
I got below compile error if only compile this file, I think previous patches
should include the definition, if that, feel free to add my ack to this
patch.
Acked-by: Peter Chen
drivers/usb/chipidea/ci_hdrc_tegra.c:308:8: error: implicit declaration of
function ‘devm_tegra_core_dev_init_opp_table_common’;
did you mean ‘devm_tegra_core_dev_init_opp_table’?
[-Werror=implicit-function-declaration]
308 | err = devm_tegra_core_dev_init_opp_table_common(&pdev->dev);
|^
|devm_tegra_core_dev_init_opp_table
--
Thanks,
Peter Chen
Re: [PATCH v2 3/3] Move IS_CONFIG_NONZERO() to kconfig.h
On Thu, Sep 30, 2021 at 3:34 AM Lucas De Marchi
wrote:
>
> The check for config value doesn't really belong to i915_utils.h - we
> are trying to eliminate that utils helper and share them when possible
> with other drivers and subsystems.
>
> Rationale for having such macro is in commit
> babaab2f4738 ("drm/i915: Encapsulate kconfig constant values inside boolean
> predicates")
> whereas later it is improved to not break the build if used with
> undefined configs. The caveat is detailed in the documentation: unlike
> IS_ENABLED(): it's not preprocessor-only logic so can't be used for
> things like `#if IS_CONFIG_NONZERO(...)`
>
> Signed-off-by: Lucas De Marchi
Hypothetical "it would be nice to have ..." is really unneeded.
if (context && CONFIG_DRM_I915_FENCE_TIMEOUT > 0)
return
msecs_to_jiffies_timeout(CONFIG_DRM_I915_FENCE_TIMEOUT);
is enough, and much cleaner.
This warning is shown only when a constant is used
together with '&&'.
Most of IS_ACTIVE can go away.
Given that, there are not many places where the IS_ACTIVE macro
is useful, even in the i915 driver.
For a few sources of the warnings,
replacing it with != 0 or > 0 is just fine.
Of course, such an ugly macro is not worth being moved to
--
Best Regards
Masahiro Yamada
Re: (subset) [PATCH] drm/bridge: Add stubs for devm_drm_of_get_bridge when OF is disabled
On Tue, 28 Sep 2021 20:13:33 +0200, Maxime Ripard wrote: > If CONFIG_OF is disabled, devm_drm_of_get_bridge won't be compiled in > and drivers using that function will fail to build. > > Add an inline stub so that we can still build-test those cases. > > Applied to drm/drm-misc (drm-misc-next). Thanks! Maxime
[PATCH 10/11] drm/msm/dpu: don't cache pipe->cap->sblk in dpu_plane
Do not cache hw_pipe's sblk in dpu_plane. Use
pdpu->pipe_hw->cap->sblk directly.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 25 ---
1 file changed, 8 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index af403c0d3d7d..d8018e664925 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -109,8 +109,6 @@ struct dpu_plane {
struct list_head mplane_list;
struct dpu_mdss_cfg *catalog;
- const struct dpu_sspp_sub_blks *pipe_sblk;
-
/* debugfs related stuff */
struct dentry *debugfs_root;
struct dpu_debugfs_regset32 debugfs_src;
@@ -425,9 +423,9 @@ static void _dpu_plane_set_qos_ctrl(struct drm_plane *plane,
memset(&pipe_qos_cfg, 0, sizeof(pipe_qos_cfg));
if (flags & DPU_PLANE_QOS_VBLANK_CTRL) {
- pipe_qos_cfg.creq_vblank = pdpu->pipe_sblk->creq_vblank;
+ pipe_qos_cfg.creq_vblank =
pdpu->pipe_hw->cap->sblk->creq_vblank;
pipe_qos_cfg.danger_vblank =
- pdpu->pipe_sblk->danger_vblank;
+ pdpu->pipe_hw->cap->sblk->danger_vblank;
pipe_qos_cfg.vblank_en = enable;
}
@@ -982,10 +980,10 @@ static int dpu_plane_atomic_check(struct drm_plane *plane,
crtc_state = drm_atomic_get_new_crtc_state(state,
new_plane_state->crtc);
- min_scale = FRAC_16_16(1, pdpu->pipe_sblk->maxupscale);
+ min_scale = FRAC_16_16(1, pdpu->pipe_hw->cap->sblk->maxupscale);
ret = drm_atomic_helper_check_plane_state(new_plane_state, crtc_state,
min_scale,
- pdpu->pipe_sblk->maxdwnscale
<< 16,
+
pdpu->pipe_hw->cap->sblk->maxdwnscale << 16,
true, true);
if (ret) {
DPU_DEBUG_PLANE(pdpu, "Check plane state failed (%d)\n", ret);
@@ -1611,20 +1609,13 @@ struct drm_plane *dpu_plane_init(struct drm_device *dev,
goto clean_sspp;
}
- /* cache features mask for later */
- pdpu->pipe_sblk = pdpu->pipe_hw->cap->sblk;
- if (!pdpu->pipe_sblk) {
- DPU_ERROR("[%u]invalid sblk\n", pipe);
- goto clean_sspp;
- }
-
if (pdpu->is_virtual) {
- format_list = pdpu->pipe_sblk->virt_format_list;
- num_formats = pdpu->pipe_sblk->virt_num_formats;
+ format_list = pdpu->pipe_hw->cap->sblk->virt_format_list;
+ num_formats = pdpu->pipe_hw->cap->sblk->virt_num_formats;
}
else {
- format_list = pdpu->pipe_sblk->format_list;
- num_formats = pdpu->pipe_sblk->num_formats;
+ format_list = pdpu->pipe_hw->cap->sblk->format_list;
+ num_formats = pdpu->pipe_hw->cap->sblk->num_formats;
}
ret = drm_universal_plane_init(dev, plane, 0xff, &dpu_plane_funcs,
--
2.33.0
[PATCH 01/11] drm/msm/dpu: move LUT levels out of QOS config
LUT levels are setup outside of setup_qos_ctrl, so remove them from the
struct dpu_hw_pipe_qos_cfg.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 15 ---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h | 16 ++--
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 17 ++---
3 files changed, 20 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
index 69eed7932486..cbafb61404d0 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
@@ -569,19 +569,20 @@ static void dpu_hw_sspp_setup_solidfill(struct
dpu_hw_pipe *ctx, u32 color, enum
}
static void dpu_hw_sspp_setup_danger_safe_lut(struct dpu_hw_pipe *ctx,
- struct dpu_hw_pipe_qos_cfg *cfg)
+ u32 danger_lut,
+ u32 safe_lut)
{
u32 idx;
if (_sspp_subblk_offset(ctx, DPU_SSPP_SRC, &idx))
return;
- DPU_REG_WRITE(&ctx->hw, SSPP_DANGER_LUT + idx, cfg->danger_lut);
- DPU_REG_WRITE(&ctx->hw, SSPP_SAFE_LUT + idx, cfg->safe_lut);
+ DPU_REG_WRITE(&ctx->hw, SSPP_DANGER_LUT + idx, danger_lut);
+ DPU_REG_WRITE(&ctx->hw, SSPP_SAFE_LUT + idx, safe_lut);
}
static void dpu_hw_sspp_setup_creq_lut(struct dpu_hw_pipe *ctx,
- struct dpu_hw_pipe_qos_cfg *cfg)
+ u64 creq_lut)
{
u32 idx;
@@ -589,11 +590,11 @@ static void dpu_hw_sspp_setup_creq_lut(struct dpu_hw_pipe
*ctx,
return;
if (ctx->cap && test_bit(DPU_SSPP_QOS_8LVL, &ctx->cap->features)) {
- DPU_REG_WRITE(&ctx->hw, SSPP_CREQ_LUT_0 + idx, cfg->creq_lut);
+ DPU_REG_WRITE(&ctx->hw, SSPP_CREQ_LUT_0 + idx, creq_lut);
DPU_REG_WRITE(&ctx->hw, SSPP_CREQ_LUT_1 + idx,
- cfg->creq_lut >> 32);
+ creq_lut >> 32);
} else {
- DPU_REG_WRITE(&ctx->hw, SSPP_CREQ_LUT + idx, cfg->creq_lut);
+ DPU_REG_WRITE(&ctx->hw, SSPP_CREQ_LUT + idx, creq_lut);
}
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
index fdfd4b46e2c6..27263bc1a1ef 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
@@ -166,18 +166,12 @@ struct dpu_hw_pipe_cfg {
/**
* struct dpu_hw_pipe_qos_cfg : Source pipe QoS configuration
- * @danger_lut: LUT for generate danger level based on fill level
- * @safe_lut: LUT for generate safe level based on fill level
- * @creq_lut: LUT for generate creq level based on fill level
* @creq_vblank: creq value generated to vbif during vertical blanking
* @danger_vblank: danger value generated during vertical blanking
* @vblank_en: enable creq_vblank and danger_vblank during vblank
* @danger_safe_en: enable danger safe generation
*/
struct dpu_hw_pipe_qos_cfg {
- u32 danger_lut;
- u32 safe_lut;
- u64 creq_lut;
u32 creq_vblank;
u32 danger_vblank;
bool vblank_en;
@@ -302,20 +296,22 @@ struct dpu_hw_sspp_ops {
/**
* setup_danger_safe_lut - setup danger safe LUTs
* @ctx: Pointer to pipe context
-* @cfg: Pointer to pipe QoS configuration
+* @danger_lut: LUT for generate danger level based on fill level
+* @safe_lut: LUT for generate safe level based on fill level
*
*/
void (*setup_danger_safe_lut)(struct dpu_hw_pipe *ctx,
- struct dpu_hw_pipe_qos_cfg *cfg);
+ u32 danger_lut,
+ u32 safe_lut);
/**
* setup_creq_lut - setup CREQ LUT
* @ctx: Pointer to pipe context
-* @cfg: Pointer to pipe QoS configuration
+* @creq_lut: LUT for generate creq level based on fill level
*
*/
void (*setup_creq_lut)(struct dpu_hw_pipe *ctx,
- struct dpu_hw_pipe_qos_cfg *cfg);
+ u64 creq_lut);
/**
* setup_qos_ctrl - setup QoS control
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index c989621209aa..5e0d06f26e53 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -348,8 +348,6 @@ static void _dpu_plane_set_qos_lut(struct drm_plane *plane,
qos_lut = _dpu_plane_get_qos_lut(
&pdpu->catalog->perf.qos_lut_tbl[lut_usage], total_fl);
- pdpu->pipe_qos_cfg.creq_lut = qos_lut;
-
trace_dpu_perf_set_qos_luts(pdpu->pipe - SSPP_VIG0,
(fmt) ? fmt->base.pixel_format : 0,
pdpu->is_rt_pipe, total_fl, qos_lut, lut_usage);
@@ -359,7 +357,7 @@ static void _dpu_plane_set_qos_lut(struct drm_plane *plane,
[PATCH 08/11] drm/msm/dpu: remove dpu_hw_pipe_cdp_cfg from dpu_plane
Remove struct dpu_hw_pipe_cdp_cfg instance from dpu_plane, it is an
interim configuration structure. Allocate it on stack instead.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 14 +++---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h | 2 --
2 files changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index b8836c089863..d3ae0cb2047c 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -1182,20 +1182,20 @@ static void dpu_plane_sspp_atomic_update(struct
drm_plane *plane)
pstate->multirect_index);
if (pdpu->pipe_hw->ops.setup_cdp) {
- struct dpu_hw_pipe_cdp_cfg *cdp_cfg = &pstate->cdp_cfg;
+ struct dpu_hw_pipe_cdp_cfg cdp_cfg;
- memset(cdp_cfg, 0, sizeof(struct dpu_hw_pipe_cdp_cfg));
+ memset(&cdp_cfg, 0, sizeof(struct dpu_hw_pipe_cdp_cfg));
- cdp_cfg->enable = pdpu->catalog->perf.cdp_cfg
+ cdp_cfg.enable = pdpu->catalog->perf.cdp_cfg
[DPU_PERF_CDP_USAGE_RT].rd_enable;
- cdp_cfg->ubwc_meta_enable =
+ cdp_cfg.ubwc_meta_enable =
DPU_FORMAT_IS_UBWC(fmt);
- cdp_cfg->tile_amortize_enable =
+ cdp_cfg.tile_amortize_enable =
DPU_FORMAT_IS_UBWC(fmt) ||
DPU_FORMAT_IS_TILE(fmt);
- cdp_cfg->preload_ahead = DPU_SSPP_CDP_PRELOAD_AHEAD_64;
+ cdp_cfg.preload_ahead = DPU_SSPP_CDP_PRELOAD_AHEAD_64;
- pdpu->pipe_hw->ops.setup_cdp(pdpu->pipe_hw, cdp_cfg);
+ pdpu->pipe_hw->ops.setup_cdp(pdpu->pipe_hw, &cdp_cfg);
}
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h
index 087194be3c22..1ee5ca5fcdf7 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h
@@ -23,7 +23,6 @@
* @multirect_index: index of the rectangle of SSPP
* @multirect_mode: parallel or time multiplex multirect mode
* @pending: whether the current update is still pending
- * @cdp_cfg: CDP configuration
* @plane_fetch_bw: calculated BW per plane
* @plane_clk: calculated clk per plane
*/
@@ -36,7 +35,6 @@ struct dpu_plane_state {
uint32_t multirect_mode;
bool pending;
- struct dpu_hw_pipe_cdp_cfg cdp_cfg;
u64 plane_fetch_bw;
u64 plane_clk;
};
--
2.33.0
[PATCH 09/11] drm/msm/dpu: don't cache pipe->cap->features in dpu_plane
Do not cache hw_pipe's features in dpu_plane. Use
pdpu->pipe_hw->cap->features directly.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index d3ae0cb2047c..af403c0d3d7d 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -100,7 +100,6 @@ struct dpu_plane {
struct mutex lock;
enum dpu_sspp pipe;
- uint32_t features; /* capabilities from catalog */
struct dpu_hw_pipe *pipe_hw;
uint32_t color_fill;
@@ -644,7 +643,7 @@ static const struct dpu_csc_cfg *_dpu_plane_get_csc(struct
dpu_plane *pdpu, cons
if (!DPU_FORMAT_IS_YUV(fmt))
return NULL;
- if (BIT(DPU_SSPP_CSC_10BIT) & pdpu->features)
+ if (BIT(DPU_SSPP_CSC_10BIT) & pdpu->pipe_hw->cap->features)
csc_ptr = &dpu_csc10_YUV2RGB_601L;
else
csc_ptr = &dpu_csc_YUV2RGB_601L;
@@ -1012,8 +1011,8 @@ static int dpu_plane_atomic_check(struct drm_plane *plane,
min_src_size = DPU_FORMAT_IS_YUV(fmt) ? 2 : 1;
if (DPU_FORMAT_IS_YUV(fmt) &&
- (!(pdpu->features & DPU_SSPP_SCALER) ||
-!(pdpu->features & (BIT(DPU_SSPP_CSC)
+ (!(pdpu->pipe_hw->cap->features & DPU_SSPP_SCALER) ||
+!(pdpu->pipe_hw->cap->features & (BIT(DPU_SSPP_CSC)
| BIT(DPU_SSPP_CSC_10BIT) {
DPU_DEBUG_PLANE(pdpu,
"plane doesn't have scaler/csc for yuv\n");
@@ -1439,8 +1438,8 @@ static int _dpu_plane_init_debugfs(struct drm_plane
*plane)
plane->dev->primary->debugfs_root);
/* don't error check these */
- debugfs_create_x32("features", 0600,
- pdpu->debugfs_root, &pdpu->features);
+ debugfs_create_xul("features", 0600,
+ pdpu->debugfs_root, (unsigned long
*)&pdpu->pipe_hw->cap->features);
/* add register dump support */
dpu_debugfs_setup_regset32(&pdpu->debugfs_src,
@@ -1613,7 +1612,6 @@ struct drm_plane *dpu_plane_init(struct drm_device *dev,
}
/* cache features mask for later */
- pdpu->features = pdpu->pipe_hw->cap->features;
pdpu->pipe_sblk = pdpu->pipe_hw->cap->sblk;
if (!pdpu->pipe_sblk) {
DPU_ERROR("[%u]invalid sblk\n", pipe);
--
2.33.0
[PATCH 11/11] drm/msm/dpu: rip out debugfs support from dpu_plane
In preparations of virtualizing the dpu_plane rip out debugfs support
from dpu_plane (as it is mostly used to expose plane's pipe registers).
Also move disable_danger file to danger/ debugfs subdir where it belongs.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 123
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 69 -
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 171 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h | 6 +
4 files changed, 69 insertions(+), 300 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index ae48f41821cf..fe33273cdf57 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -101,84 +101,85 @@ static int dpu_debugfs_safe_stats_show(struct seq_file
*s, void *v)
}
DEFINE_SHOW_ATTRIBUTE(dpu_debugfs_safe_stats);
-static void dpu_debugfs_danger_init(struct dpu_kms *dpu_kms,
- struct dentry *parent)
+static ssize_t _dpu_plane_danger_read(struct file *file,
+ char __user *buff, size_t count, loff_t *ppos)
{
- struct dentry *entry = debugfs_create_dir("danger", parent);
+ struct dpu_kms *kms = file->private_data;
+ int len;
+ char buf[40];
- debugfs_create_file("danger_status", 0600, entry,
- dpu_kms, &dpu_debugfs_danger_stats_fops);
- debugfs_create_file("safe_status", 0600, entry,
- dpu_kms, &dpu_debugfs_safe_stats_fops);
+ len = scnprintf(buf, sizeof(buf), "%d\n", !kms->has_danger_ctrl);
+
+ return simple_read_from_buffer(buff, count, ppos, buf, len);
}
-static int _dpu_debugfs_show_regset32(struct seq_file *s, void *data)
+static void _dpu_plane_set_danger_state(struct dpu_kms *kms, bool enable)
{
- struct dpu_debugfs_regset32 *regset = s->private;
- struct dpu_kms *dpu_kms = regset->dpu_kms;
- void __iomem *base;
- uint32_t i, addr;
-
- if (!dpu_kms->mmio)
- return 0;
-
- base = dpu_kms->mmio + regset->offset;
-
- /* insert padding spaces, if needed */
- if (regset->offset & 0xF) {
- seq_printf(s, "[%x]", regset->offset & ~0xF);
- for (i = 0; i < (regset->offset & 0xF); i += 4)
- seq_puts(s, " ");
- }
-
- pm_runtime_get_sync(&dpu_kms->pdev->dev);
-
- /* main register output */
- for (i = 0; i < regset->blk_len; i += 4) {
- addr = regset->offset + i;
- if ((addr & 0xF) == 0x0)
- seq_printf(s, i ? "\n[%x]" : "[%x]", addr);
- seq_printf(s, " %08x", readl_relaxed(base + i));
+ struct drm_plane *plane;
+
+ drm_for_each_plane(plane, kms->dev) {
+ if (plane->fb && plane->state) {
+ dpu_plane_danger_signal_ctrl(plane, enable);
+ DPU_DEBUG("plane:%d img:%dx%d ",
+ plane->base.id, plane->fb->width,
+ plane->fb->height);
+ DPU_DEBUG("src[%d,%d,%d,%d] dst[%d,%d,%d,%d]\n",
+ plane->state->src_x >> 16,
+ plane->state->src_y >> 16,
+ plane->state->src_w >> 16,
+ plane->state->src_h >> 16,
+ plane->state->crtc_x, plane->state->crtc_y,
+ plane->state->crtc_w, plane->state->crtc_h);
+ } else {
+ DPU_DEBUG("Inactive plane:%d\n", plane->base.id);
+ }
}
- seq_puts(s, "\n");
- pm_runtime_put_sync(&dpu_kms->pdev->dev);
-
- return 0;
}
-static int dpu_debugfs_open_regset32(struct inode *inode,
- struct file *file)
+static ssize_t _dpu_plane_danger_write(struct file *file,
+ const char __user *user_buf, size_t count, loff_t *ppos)
{
- return single_open(file, _dpu_debugfs_show_regset32, inode->i_private);
-}
+ struct dpu_kms *kms = file->private_data;
+ int disable_panic;
+ int ret;
-static const struct file_operations dpu_fops_regset32 = {
- .open = dpu_debugfs_open_regset32,
- .read = seq_read,
- .llseek = seq_lseek,
- .release = single_release,
-};
+ ret = kstrtouint_from_user(user_buf, count, 0, &disable_panic);
+ if (ret)
+ return ret;
-void dpu_debugfs_setup_regset32(struct dpu_debugfs_regset32 *regset,
- uint32_t offset, uint32_t length, struct dpu_kms *dpu_kms)
-{
- if (regset) {
- regset->offset = offset;
- regset->blk_len = length;
- regset->dpu_kms = dpu_kms;
+ if (disable_panic) {
+ /* Disable panic signal for all active pipes */
+ DPU_DEBUG("Disa
