Re: [PATCH v2 2/3] drm/i915/utils: do not depend on config being defined
W dniu 30.09.2021 o 00:54, Lucas De Marchi pisze:
> On Wed, Sep 29, 2021 at 11:08:18PM +0200, Andrzej Hajda wrote:
>>
>> W dniu 29.09.2021 o 20:33, Lucas De Marchi pisze:
>>> 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.*
>>> text data bss dec hex filename
>>> 52021 1070 232 53323 d04b
>>> drivers/gpu/drm/i915/gem/i915_gem_context.o.new
>>> 52021 1070 232 53323 d04b
>>> 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') || \
>>> + __stringify_1(config)[0] == '-' \
>>> +)
>>
>>
>> Quite clever trick, but I see two issues:
>>
>> - gcc < 8.1 treats expressions with string indices (ex. "abc"[0]) as
>> non-constant expressions, so they cannot be used everywhere, for example
>> in global variable initializations,
>
> ugh, that would kill the idea - having the strings and additional
> runtime checks would not be good. Maybe if we check with
> __builtin_constant_p() and do the simpler expansion if it's not
> constant?
I think it is just matter of disallowing such construct in places where
compiler expects constant expression.
If accepted, the expression is apparently evaluated in compile time. See
[1].
[1]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69960#c18
>
>>
>> - it does not work with hex (0x1) or octal values (01)
>
> indeed, but I guess that would be fixable by checking (s[0] == '0' &&
> s[1] == '\0')?
> However, it seems kconfig doesn't support setting int options to hex or
> octal.
I've spotted in include/generated/autoconf.h following line:
#define CONFIG_ILLEGAL_POINTER_VALUE 0xdead
It corresponds to following kconfig entry:
config ILLEGAL_POINTER_VALUE
hex
default 0 if X86_32
default 0xdead if X86_64
Grepping shows more: grep -r --include=Kconfig -3 -P '^\s*hex' .
Anyway do you really need to handle undefined case? If not, the macro
can stay simple, w/o hacky constructs.
Regards
Andrzej
>
> If I try an hex value in menuconfig it says "You have made an invalid
> entry."
> If I try editing .config or setting via scripts/config --set-val, it
> just gets reset when trying to generate include/generated/autoconf.h
>
> Lucas De Marchi
>
>>
>> It is probably OK for private macro, but it can hurt in kconfig.h,
>> especially the 2nd issue
>>
>>
>> Regards
>>
>> Andrzej
>>
>>>
>>> #endif /* !__I915_UTILS_H */
>
Re: [v2 PATCH 1/3] drm/mediatek: Fix crash at using pkt->cl->chan in cmdq_pkt_finalize
Hi Jason,
Missatge de jason-jh.lin del dia dj., 30
de set. 2021 a les 4:47:
>
> Because mtk_drm_crtc_create_pkt didn't assign pkt->cl, it will
> crash at using pkt->cl->chan in cmdq_pkt_finalize.
>
> So add struct cmdq_client and let mtk_drm_crtc instance define
> cmdq_client as:
>
> struct mtk_drm_crtc {
> /* client instance data */
> struct cmdq_client cmdq_client;
> };
>
> and in rx_callback function can use pkt->cl to get
> struct cmdq_client.
>
> Fixes: f4be17cd5b14 ("drm/mediatek: Remove struct cmdq_client")
Looking at this patchset looks like you're fixing the above commit by
reintroducing the 'struct cmdq_client' again, which makes the above
commit as a non-sense commit. That's confusing and not clear. I'm
wondering if it wouldn't be more clear if you can just revert that
patch. Then if there are more changes that need to be done do it with
a follow up patch and really explain why these changes are needed.
Thanks,
Enric
> Signed-off-by: jason-jh.lin
> ---
> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 73 +
> 1 file changed, 38 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> index 5f81489fc60c..411d99fcbb8f 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> @@ -52,8 +52,7 @@ struct mtk_drm_crtc {
> boolpending_async_planes;
>
> #if IS_REACHABLE(CONFIG_MTK_CMDQ)
> - struct mbox_client cmdq_cl;
> - struct mbox_chan*cmdq_chan;
> + struct cmdq_client cmdq_client;
> struct cmdq_pkt cmdq_handle;
> u32 cmdq_event;
> u32 cmdq_vblank_cnt;
> @@ -227,8 +226,8 @@ struct mtk_ddp_comp *mtk_drm_ddp_comp_for_plane(struct
> drm_crtc *crtc,
> }
>
> #if IS_REACHABLE(CONFIG_MTK_CMDQ)
> -static int mtk_drm_cmdq_pkt_create(struct mbox_chan *chan, struct cmdq_pkt
> *pkt,
> - size_t size)
> +static int mtk_drm_cmdq_pkt_create(struct cmdq_client *client, struct
> cmdq_pkt *pkt,
> + size_t size)
> {
> struct device *dev;
> dma_addr_t dma_addr;
> @@ -239,8 +238,9 @@ static int mtk_drm_cmdq_pkt_create(struct mbox_chan
> *chan, struct cmdq_pkt *pkt,
> return -ENOMEM;
> }
> pkt->buf_size = size;
> + pkt->cl = (void *)client;
>
> - dev = chan->mbox->dev;
> + dev = client->chan->mbox->dev;
> dma_addr = dma_map_single(dev, pkt->va_base, pkt->buf_size,
> DMA_TO_DEVICE);
> if (dma_mapping_error(dev, dma_addr)) {
> @@ -255,9 +255,11 @@ static int mtk_drm_cmdq_pkt_create(struct mbox_chan
> *chan, struct cmdq_pkt *pkt,
> return 0;
> }
>
> -static void mtk_drm_cmdq_pkt_destroy(struct mbox_chan *chan, struct cmdq_pkt
> *pkt)
> +static void mtk_drm_cmdq_pkt_destroy(struct cmdq_pkt *pkt)
> {
> - dma_unmap_single(chan->mbox->dev, pkt->pa_base, pkt->buf_size,
> + struct cmdq_client *client = (struct cmdq_client *)pkt->cl;
> +
> + dma_unmap_single(client->chan->mbox->dev, pkt->pa_base, pkt->buf_size,
> DMA_TO_DEVICE);
> kfree(pkt->va_base);
> kfree(pkt);
> @@ -265,8 +267,9 @@ static void mtk_drm_cmdq_pkt_destroy(struct mbox_chan
> *chan, struct cmdq_pkt *pk
>
> static void ddp_cmdq_cb(struct mbox_client *cl, void *mssg)
> {
> - struct mtk_drm_crtc *mtk_crtc = container_of(cl, struct mtk_drm_crtc,
> cmdq_cl);
> struct cmdq_cb_data *data = mssg;
> + struct cmdq_client *cmdq_cl = container_of(cl, struct cmdq_client,
> client);
> + struct mtk_drm_crtc *mtk_crtc = container_of(cmdq_cl, struct
> mtk_drm_crtc, cmdq_client);
> struct mtk_crtc_state *state;
> unsigned int i;
>
> @@ -299,7 +302,7 @@ static void ddp_cmdq_cb(struct mbox_client *cl, void
> *mssg)
> }
>
> mtk_crtc->cmdq_vblank_cnt = 0;
> - mtk_drm_cmdq_pkt_destroy(mtk_crtc->cmdq_chan, data->pkt);
> + mtk_drm_cmdq_pkt_destroy(data->pkt);
> }
> #endif
>
> @@ -550,24 +553,24 @@ static void mtk_drm_crtc_update_config(struct
> mtk_drm_crtc *mtk_crtc,
> mtk_mutex_release(mtk_crtc->mutex);
> }
> #if IS_REACHABLE(CONFIG_MTK_CMDQ)
> - if (mtk_crtc->cmdq_chan) {
> - mbox_flush(mtk_crtc->cmdq_chan, 2000);
> + if (mtk_crtc->cmdq_client.chan) {
> + mbox_flush(mtk_crtc->cmdq_client.chan, 2000);
> cmdq_handle->cmd_buf_size = 0;
> cmdq_pkt_clear_event(cmdq_handle, mtk_crtc->cmdq_event);
> cmdq_pkt_wfe(cmdq_handle, mtk_crtc->cmdq_event, false);
> mtk_crtc_ddp_config(crtc, cmdq_handle);
> cmdq_pkt_finalize(cmdq_handle);
> - dma_sync_single_fo
Re: [PATCH v8 03/12] iommu/mediatek: Add probe_defer for smi-larb
On Wed, 2021-09-29 at 18:33 +0200, Dafna Hirschfeld wrote:
>
> On 29.09.21 03:37, Yong Wu wrote:
> > Prepare for adding device_link.
> >
> > The iommu consumer should use device_link to connect with the
> > smi-larb(supplier). then the smi-larb should run before the iommu
> > consumer. Here we delay the iommu driver until the smi driver is
> > ready,
> > then all the iommu consumers always are after the smi driver.
> >
> > When there is no this patch, if some consumer drivers run before
> > smi-larb, the supplier link_status is DL_DEV_NO_DRIVER(0) in the
> > device_link_add, then device_links_driver_bound will use WARN_ON
> > to complain that the link_status of supplier is not right.
> >
> > device_is_bound may be more elegant here. but it is not allowed to
> > EXPORT from https://lore.kernel.org/patchwork/patch/1334670/.
> >
> > Signed-off-by: Yong Wu
> > Tested-by: Frank Wunderlich # BPI-
> > R2/MT7623
> > ---
> > drivers/iommu/mtk_iommu.c| 2 +-
> > drivers/iommu/mtk_iommu_v1.c | 2 +-
> > 2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> > index d837adfd1da5..d5848f78a677 100644
> > --- a/drivers/iommu/mtk_iommu.c
> > +++ b/drivers/iommu/mtk_iommu.c
> > @@ -844,7 +844,7 @@ static int mtk_iommu_probe(struct
> > platform_device *pdev)
> > id = i;
> >
> > plarbdev = of_find_device_by_node(larbnode);
> > - if (!plarbdev) {
> > + if (!plarbdev || !plarbdev->dev.driver) {
> > of_node_put(larbnode);
> > return -EPROBE_DEFER;
>
> if plarbdev is null doesn't that mean that the device does not exist?
This is probe function, Is it possible the platform device is not ready
at this time?
I checked the platform device should be created at:
of_platform_default_populate_init: arch_initcall_sync
->of_platform_populate
->of_platform_device_create_pdata
Not sure if this may be delayed for some device. If not, it should be
ENODEV here.
> so we should return -ENODEV in that case?
>
> thanks,
> Dafna
>
> > }
> > diff --git a/drivers/iommu/mtk_iommu_v1.c
> > b/drivers/iommu/mtk_iommu_v1.c
> > index 1467ba1e4417..4d7809432239 100644
> > --- a/drivers/iommu/mtk_iommu_v1.c
> > +++ b/drivers/iommu/mtk_iommu_v1.c
> > @@ -602,7 +602,7 @@ static int mtk_iommu_probe(struct
> > platform_device *pdev)
> > }
> >
> > plarbdev = of_find_device_by_node(larbnode);
> > - if (!plarbdev) {
> > + if (!plarbdev || !plarbdev->dev.driver) {
> > of_node_put(larbnode);
> > return -EPROBE_DEFER;
> > }
> >
>
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
RE: [PATCH] drm/ast: Atomic CR/SR reg R/W
-Original Message-
From: Thomas Zimmermann [mailto:tzimmerm...@suse.de]
Sent: Monday, September 20, 2021 4:17 PM
To: Kuo-Hsiang Chou ;
dri-devel@lists.freedesktop.org; linux-ker...@vger.kernel.org
Subject: Re: [PATCH] drm/ast: Atomic CR/SR reg R/W
Hi
Am 17.09.21 um 09:22 schrieb KuoHsiang Chou:
> 1. Avoid IO-index racing
> 2. IO-index racing happened on resolustion switching
> and mouse moving at the same time
> 3. System hung while IO-index racing occurred.
I'd say that there's something else going one here. Mode setting and cursor
movement should be protected against each other by DRM locking.
Changing these low-level functions would not solve the issues. I'll try to
reproduce the problem ASAP.
Hi Thomas,
Sorry to interrupt you again!
May I understand the review's situation? Thanks!
Best Regards,
Kuo-Hsiang Chou
Best regards
Thomas
>
> Signed-off-by: KuoHsiang Chou
> ---
> drivers/gpu/drm/ast/ast_main.c | 48 +-
> 1 file changed, 36 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/ast/ast_main.c
> b/drivers/gpu/drm/ast/ast_main.c index 79a361867..1d8fa70c5 100644
> --- a/drivers/gpu/drm/ast/ast_main.c
> +++ b/drivers/gpu/drm/ast/ast_main.c
> @@ -41,28 +41,52 @@ void ast_set_index_reg_mask(struct ast_private *ast,
> uint32_t base, uint8_t index,
> uint8_t mask, uint8_t val)
> {
> - u8 tmp;
> - ast_io_write8(ast, base, index);
> - tmp = (ast_io_read8(ast, base + 1) & mask) | val;
> - ast_set_index_reg(ast, base, index, tmp);
> + uint16_t volatile usData;
> + uint8_t volatile jData;
> +
> + do {
> + ast_io_write8(ast, base, index);
> + usData = ast_io_read16(ast, base);
> + } while ((uint8_t)(usData) != index);
> +
> + jData = (uint8_t)(usData >> 8);
> + jData &= mask;
> + jData |= val;
> + usData = ((uint16_t) jData << 8) | (uint16_t) index;
> + ast_io_write16(ast, base, usData);
> }
>
> uint8_t ast_get_index_reg(struct ast_private *ast,
> uint32_t base, uint8_t index)
> {
> - uint8_t ret;
> - ast_io_write8(ast, base, index);
> - ret = ast_io_read8(ast, base + 1);
> - return ret;
> + uint16_t volatile usData;
> + uint8_t volatile jData;
> +
> + do {
> + ast_io_write8(ast, base, index);
> + usData = ast_io_read16(ast, base);
> + } while ((uint8_t)(usData) != index);
> +
> + jData = (uint8_t)(usData >> 8);
> +
> + return jData;
> }
>
> uint8_t ast_get_index_reg_mask(struct ast_private *ast,
> uint32_t base, uint8_t index, uint8_t mask)
> {
> - uint8_t ret;
> - ast_io_write8(ast, base, index);
> - ret = ast_io_read8(ast, base + 1) & mask;
> - return ret;
> + uint16_t volatile usData;
> + uint8_t volatile jData;
> +
> + do {
> + ast_io_write8(ast, base, index);
> + usData = ast_io_read16(ast, base);
> + } while ((uint8_t)(usData) != index);
> +
> + jData = (uint8_t)(usData >> 8);
> + jData &= mask;
> +
> + return jData;
> }
>
> static void ast_detect_config_mode(struct drm_device *dev, u32
> *scu_rev)
> --
> 2.18.4
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
Re: [PATCH] drm/prime: Fix use after free in mmap with drm_gem_ttm_mmap
Hi
Am 30.09.21 um 01:00 schrieb Anand K Mistry:
drm_gem_ttm_mmap() drops a reference to the gem object on success. If
the gem object's refcount == 1 on entry to drm_gem_prime_mmap(), that
drop will free the gem object, and the subsequent drm_gem_object_get()
will be a UAF. Fix by grabbing a reference before calling the mmap
helper.
This issue was forseen when the reference dropping was adding in
commit 9786b65bc61ac ("drm/ttm: fix mmap refcounting"):
"For that to work properly the drm_gem_object_get() call in
drm_gem_ttm_mmap() must be moved so it happens before calling
obj->funcs->mmap(), otherwise the gem refcount would go down
to zero."
Signed-off-by: Anand K Mistry
Acked-by: Thomas Zimmermann
This looks fine to me, but it affects many drivers. Let's maybe wait a
bit if more reviews come it.
Best regards
Thomas
---
drivers/gpu/drm/drm_prime.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 2a54f86856af..e1854fd24bb0 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -719,11 +719,13 @@ int drm_gem_prime_mmap(struct drm_gem_object *obj, struct
vm_area_struct *vma)
if (obj->funcs && obj->funcs->mmap) {
vma->vm_ops = obj->funcs->vm_ops;
+ drm_gem_object_get(obj);
ret = obj->funcs->mmap(obj, vma);
- if (ret)
+ if (ret) {
+ drm_gem_object_put(obj);
return ret;
+ }
vma->vm_private_data = obj;
- drm_gem_object_get(obj);
return 0;
}
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PATCH 1/3] drm/ttm: s/FLAG_SG/FLAG_EXTERNAL/
I pushed those to drm-misc-next and fixed the i915 merge fallout in drm-tip.
Maybe take another look at the resolution in drm-tip if you have time.
Christian.
Am 29.09.21 um 15:26 schrieb Matthew Auld:
It covers more than just ttm_bo_type_sg usage, like with say dma-buf,
since one other user is userptr in amdgpu, and in the future we might
have some more. Hence EXTERNAL is likely a more suitable name.
v2(Christian):
- Rename these to TTM_TT_FLAGS_*
- Fix up all the holes in the flag values
Suggested-by: Christian König
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Christian König
Acked-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 10 +-
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 6 +++---
drivers/gpu/drm/nouveau/nouveau_bo.c| 4 ++--
drivers/gpu/drm/radeon/radeon_ttm.c | 8
drivers/gpu/drm/ttm/ttm_bo.c| 4 ++--
drivers/gpu/drm/ttm/ttm_bo_util.c | 4 ++--
drivers/gpu/drm/ttm/ttm_bo_vm.c | 2 +-
drivers/gpu/drm/ttm/ttm_pool.c | 2 +-
drivers/gpu/drm/ttm/ttm_tt.c| 24
include/drm/ttm/ttm_device.h| 2 +-
include/drm/ttm/ttm_tt.h| 18 +-
11 files changed, 42 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 60b12bb55244..e8d70b6e6737 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -894,7 +894,7 @@ static int amdgpu_ttm_backend_bind(struct ttm_device *bdev,
DRM_ERROR("failed to pin userptr\n");
return r;
}
- } else if (ttm->page_flags & TTM_PAGE_FLAG_SG) {
+ } else if (ttm->page_flags & TTM_TT_FLAG_EXTERNAL) {
if (!ttm->sg) {
struct dma_buf_attachment *attach;
struct sg_table *sgt;
@@ -1130,7 +1130,7 @@ static int amdgpu_ttm_tt_populate(struct ttm_device *bdev,
return 0;
}
- if (ttm->page_flags & TTM_PAGE_FLAG_SG)
+ if (ttm->page_flags & TTM_TT_FLAG_EXTERNAL)
return 0;
ret = ttm_pool_alloc(&adev->mman.bdev.pool, ttm, ctx);
@@ -1165,7 +1165,7 @@ static void amdgpu_ttm_tt_unpopulate(struct ttm_device
*bdev,
return;
}
- if (ttm->page_flags & TTM_PAGE_FLAG_SG)
+ if (ttm->page_flags & TTM_TT_FLAG_EXTERNAL)
return;
for (i = 0; i < ttm->num_pages; ++i)
@@ -1198,8 +1198,8 @@ int amdgpu_ttm_tt_set_userptr(struct ttm_buffer_object
*bo,
return -ENOMEM;
}
- /* Set TTM_PAGE_FLAG_SG before populate but after create. */
- bo->ttm->page_flags |= TTM_PAGE_FLAG_SG;
+ /* Set TTM_TT_FLAG_EXTERNAL before populate but after create. */
+ bo->ttm->page_flags |= TTM_TT_FLAG_EXTERNAL;
gtt = (void *)bo->ttm;
gtt->userptr = addr;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index f0a61a9474fc..8beef57ba52b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -182,7 +182,7 @@ static struct ttm_tt *i915_ttm_tt_create(struct
ttm_buffer_object *bo,
if (obj->flags & I915_BO_ALLOC_CPU_CLEAR &&
man->use_tt)
- page_flags |= TTM_PAGE_FLAG_ZERO_ALLOC;
+ page_flags |= TTM_TT_FLAG_ZERO_ALLOC;
ret = ttm_tt_init(&i915_tt->ttm, bo, page_flags,
i915_ttm_select_tt_caching(obj));
@@ -451,7 +451,7 @@ static int i915_ttm_accel_move(struct ttm_buffer_object *bo,
if (bo->type == ttm_bo_type_kernel)
return -EINVAL;
- if (ttm && !(ttm->page_flags & TTM_PAGE_FLAG_ZERO_ALLOC))
+ if (ttm && !(ttm->page_flags & TTM_TT_FLAG_ZERO_ALLOC))
return 0;
intel_engine_pm_get(i915->gt.migrate.context->engine);
@@ -525,7 +525,7 @@ static int i915_ttm_move(struct ttm_buffer_object *bo, bool
evict,
/* Populate ttm with pages if needed. Typically system memory. */
if (bo->ttm && (dst_man->use_tt ||
- (bo->ttm->page_flags & TTM_PAGE_FLAG_SWAPPED))) {
+ (bo->ttm->page_flags & TTM_TT_FLAG_SWAPPED))) {
ret = ttm_tt_populate(bo->bdev, bo->ttm, ctx);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 33dca2565cca..b2c7e0802ac3 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1249,7 +1249,7 @@ nouveau_ttm_tt_populate(struct ttm_device *bdev,
struct ttm_tt *ttm_dma = (void *)ttm;
struct nouveau_drm *drm;
struct device *dev;
- bool slave = !!(ttm->page_flags & TTM_PAGE_FLAG_SG);
+ bool slave = !!(ttm->page
Re: [RFC PATCH v2 1/1] Providers/rxe: Add dma-buf support
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
>
> ~
Re: [RFC PATCH v2 1/1] Providers/rxe: Add dma-buf support
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
> + ret = ibv_cmd_reg_dmabuf_mr(pd, offset, length, iova, fd, access,
> vmr);
> + if (ret) {
> + free(vmr);
> + return NULL;
> + }
> +
> + return &vmr->ibv_mr;
> +}
> +
> static int rxe_dereg_mr(struct verbs_mr *vmr)
> {
> int ret;
> @@ -1706,6 +1726,7 @@ static const struct verbs_context_ops rxe_ctx_ops = {
> .alloc_pd = rxe_alloc_pd,
> .dealloc_pd = rxe_dealloc_pd,
> .reg_mr = rxe_reg_mr,
> + .reg_dmabuf_mr = rxe_reg_dmabuf_mr,
> .dereg_mr = rxe_dereg_mr,
> .alloc_mw = rxe_alloc_mw,
> .dealloc_mw = rxe_dealloc_mw,
> --
> 2.17.1
>
Re: [Intel-gfx] [PATCH 1/3] drm/ttm: s/FLAG_SG/FLAG_EXTERNAL/
On Thu, 30 Sept 2021 at 08:28, Christian König wrote:
>
> I pushed those to drm-misc-next and fixed the i915 merge fallout in drm-tip.
>
> Maybe take another look at the resolution in drm-tip if you have time.
Thanks, although it looks like there is some breakage in the build on drm-tip:
drivers/gpu/drm/ttm/ttm_bo_util.c: In function ‘ttm_bo_move_memcpy’:
drivers/gpu/drm/ttm/ttm_bo_util.c:172:44: error:
‘TTM_PAGE_FLAG_ZERO_ALLOC’ undeclared (first use in this function);
did you mean ‘TTM_TT_FLAG_ZERO_ALLOC’?
172 | if (!(clear && ttm && !(ttm->page_flags & TTM_PAGE_FLAG_ZERO_ALLOC)))
...
drivers/gpu/drm/i915/gem/i915_gem_ttm.c: In function ‘i915_ttm_move’:
drivers/gpu/drm/i915/gem/i915_gem_ttm.c:576:44: error:
‘TTM_PAGE_FLAG_ZERO_ALLOC’ undeclared (first use in this function);
did you mean ‘TTM_TT_FLAG_ZERO_ALLOC’?
576 | if (!(clear && ttm && !(ttm->page_flags & TTM_PAGE_FLAG_ZERO_ALLOC)))
| ^~~~
| TTM_TT_FLAG_ZERO_ALLOC
Do we just need to revert the bad commit in drm-rerere, rebuild tip,
and try again? If so I can try to attempt this.
>
> Christian.
>
> Am 29.09.21 um 15:26 schrieb Matthew Auld:
> > It covers more than just ttm_bo_type_sg usage, like with say dma-buf,
> > since one other user is userptr in amdgpu, and in the future we might
> > have some more. Hence EXTERNAL is likely a more suitable name.
> >
> > v2(Christian):
> >- Rename these to TTM_TT_FLAGS_*
> >- Fix up all the holes in the flag values
> >
> > Suggested-by: Christian König
> > Signed-off-by: Matthew Auld
> > Cc: Thomas Hellström
> > Cc: Christian König
> > Acked-by: Christian König
> > ---
> > drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 10 +-
> > drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 6 +++---
> > drivers/gpu/drm/nouveau/nouveau_bo.c| 4 ++--
> > drivers/gpu/drm/radeon/radeon_ttm.c | 8
> > drivers/gpu/drm/ttm/ttm_bo.c| 4 ++--
> > drivers/gpu/drm/ttm/ttm_bo_util.c | 4 ++--
> > drivers/gpu/drm/ttm/ttm_bo_vm.c | 2 +-
> > drivers/gpu/drm/ttm/ttm_pool.c | 2 +-
> > drivers/gpu/drm/ttm/ttm_tt.c| 24
> > include/drm/ttm/ttm_device.h| 2 +-
> > include/drm/ttm/ttm_tt.h| 18 +-
> > 11 files changed, 42 insertions(+), 42 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> > index 60b12bb55244..e8d70b6e6737 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> > @@ -894,7 +894,7 @@ static int amdgpu_ttm_backend_bind(struct ttm_device
> > *bdev,
> > DRM_ERROR("failed to pin userptr\n");
> > return r;
> > }
> > - } else if (ttm->page_flags & TTM_PAGE_FLAG_SG) {
> > + } else if (ttm->page_flags & TTM_TT_FLAG_EXTERNAL) {
> > if (!ttm->sg) {
> > struct dma_buf_attachment *attach;
> > struct sg_table *sgt;
> > @@ -1130,7 +1130,7 @@ static int amdgpu_ttm_tt_populate(struct ttm_device
> > *bdev,
> > return 0;
> > }
> >
> > - if (ttm->page_flags & TTM_PAGE_FLAG_SG)
> > + if (ttm->page_flags & TTM_TT_FLAG_EXTERNAL)
> > return 0;
> >
> > ret = ttm_pool_alloc(&adev->mman.bdev.pool, ttm, ctx);
> > @@ -1165,7 +1165,7 @@ static void amdgpu_ttm_tt_unpopulate(struct
> > ttm_device *bdev,
> > return;
> > }
> >
> > - if (ttm->page_flags & TTM_PAGE_FLAG_SG)
> > + if (ttm->page_flags & TTM_TT_FLAG_EXTERNAL)
> > return;
> >
> > for (i = 0; i < ttm->num_pages; ++i)
> > @@ -1198,8 +1198,8 @@ int amdgpu_ttm_tt_set_userptr(struct
> > ttm_buffer_object *bo,
> > return -ENOMEM;
> > }
> >
> > - /* Set TTM_PAGE_FLAG_SG before populate but after create. */
> > - bo->ttm->page_flags |= TTM_PAGE_FLAG_SG;
> > + /* Set TTM_TT_FLAG_EXTERNAL before populate but after create. */
> > + bo->ttm->page_flags |= TTM_TT_FLAG_EXTERNAL;
> >
> > gtt = (void *)bo->ttm;
> > gtt->userptr = addr;
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> > index f0a61a9474fc..8beef57ba52b 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> > @@ -182,7 +182,7 @@ static struct ttm_tt *i915_ttm_tt_create(struct
> > ttm_buffer_object *bo,
> >
> > if (obj->flags & I915_BO_ALLOC_CPU_CLEAR &&
> > man->use_tt)
> > - page_flags |= TTM_PAGE_FLAG_ZERO_ALLOC;
> > + page_flags |= TTM_TT_FLAG_ZERO_ALLOC;
> >
> > ret = ttm_tt_init(&i915_tt->ttm, bo, page_flags,
> > i915_ttm_select_tt_caching(obj));
> > @@ -451,7 +451,7 @@ static int i915_ttm_accel_move(struct ttm_buffer_object
> > *bo,
> > if (bo->type == ttm_bo_type_ke
Re: [Intel-gfx] [PATCH 1/3] drm/ttm: s/FLAG_SG/FLAG_EXTERNAL/
Am 30.09.21 um 09:42 schrieb Matthew Auld:
On Thu, 30 Sept 2021 at 08:28, Christian König wrote:
I pushed those to drm-misc-next and fixed the i915 merge fallout in drm-tip.
Maybe take another look at the resolution in drm-tip if you have time.
Thanks, although it looks like there is some breakage in the build on drm-tip:
drivers/gpu/drm/ttm/ttm_bo_util.c: In function ‘ttm_bo_move_memcpy’:
drivers/gpu/drm/ttm/ttm_bo_util.c:172:44: error:
‘TTM_PAGE_FLAG_ZERO_ALLOC’ undeclared (first use in this function);
did you mean ‘TTM_TT_FLAG_ZERO_ALLOC’?
172 | if (!(clear && ttm && !(ttm->page_flags & TTM_PAGE_FLAG_ZERO_ALLOC)))
...
drivers/gpu/drm/i915/gem/i915_gem_ttm.c: In function ‘i915_ttm_move’:
drivers/gpu/drm/i915/gem/i915_gem_ttm.c:576:44: error:
‘TTM_PAGE_FLAG_ZERO_ALLOC’ undeclared (first use in this function);
did you mean ‘TTM_TT_FLAG_ZERO_ALLOC’?
576 | if (!(clear && ttm && !(ttm->page_flags & TTM_PAGE_FLAG_ZERO_ALLOC)))
| ^~~~
| TTM_TT_FLAG_ZERO_ALLOC
Crap, I hoped that I got all of those.
Do we just need to revert the bad commit in drm-rerere, rebuild tip,
and try again? If so I can try to attempt this.
Yes, please do so. I can't easily build drm-tip, would need to setup
another box extra for this.
Christian.
Christian.
Am 29.09.21 um 15:26 schrieb Matthew Auld:
It covers more than just ttm_bo_type_sg usage, like with say dma-buf,
since one other user is userptr in amdgpu, and in the future we might
have some more. Hence EXTERNAL is likely a more suitable name.
v2(Christian):
- Rename these to TTM_TT_FLAGS_*
- Fix up all the holes in the flag values
Suggested-by: Christian König
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Christian König
Acked-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 10 +-
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 6 +++---
drivers/gpu/drm/nouveau/nouveau_bo.c| 4 ++--
drivers/gpu/drm/radeon/radeon_ttm.c | 8
drivers/gpu/drm/ttm/ttm_bo.c| 4 ++--
drivers/gpu/drm/ttm/ttm_bo_util.c | 4 ++--
drivers/gpu/drm/ttm/ttm_bo_vm.c | 2 +-
drivers/gpu/drm/ttm/ttm_pool.c | 2 +-
drivers/gpu/drm/ttm/ttm_tt.c| 24
include/drm/ttm/ttm_device.h| 2 +-
include/drm/ttm/ttm_tt.h| 18 +-
11 files changed, 42 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 60b12bb55244..e8d70b6e6737 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -894,7 +894,7 @@ static int amdgpu_ttm_backend_bind(struct ttm_device *bdev,
DRM_ERROR("failed to pin userptr\n");
return r;
}
- } else if (ttm->page_flags & TTM_PAGE_FLAG_SG) {
+ } else if (ttm->page_flags & TTM_TT_FLAG_EXTERNAL) {
if (!ttm->sg) {
struct dma_buf_attachment *attach;
struct sg_table *sgt;
@@ -1130,7 +1130,7 @@ static int amdgpu_ttm_tt_populate(struct ttm_device *bdev,
return 0;
}
- if (ttm->page_flags & TTM_PAGE_FLAG_SG)
+ if (ttm->page_flags & TTM_TT_FLAG_EXTERNAL)
return 0;
ret = ttm_pool_alloc(&adev->mman.bdev.pool, ttm, ctx);
@@ -1165,7 +1165,7 @@ static void amdgpu_ttm_tt_unpopulate(struct ttm_device
*bdev,
return;
}
- if (ttm->page_flags & TTM_PAGE_FLAG_SG)
+ if (ttm->page_flags & TTM_TT_FLAG_EXTERNAL)
return;
for (i = 0; i < ttm->num_pages; ++i)
@@ -1198,8 +1198,8 @@ int amdgpu_ttm_tt_set_userptr(struct ttm_buffer_object
*bo,
return -ENOMEM;
}
- /* Set TTM_PAGE_FLAG_SG before populate but after create. */
- bo->ttm->page_flags |= TTM_PAGE_FLAG_SG;
+ /* Set TTM_TT_FLAG_EXTERNAL before populate but after create. */
+ bo->ttm->page_flags |= TTM_TT_FLAG_EXTERNAL;
gtt = (void *)bo->ttm;
gtt->userptr = addr;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index f0a61a9474fc..8beef57ba52b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -182,7 +182,7 @@ static struct ttm_tt *i915_ttm_tt_create(struct
ttm_buffer_object *bo,
if (obj->flags & I915_BO_ALLOC_CPU_CLEAR &&
man->use_tt)
- page_flags |= TTM_PAGE_FLAG_ZERO_ALLOC;
+ page_flags |= TTM_TT_FLAG_ZERO_ALLOC;
ret = ttm_tt_init(&i915_tt->ttm, bo, page_flags,
i915_ttm_select_tt_caching(obj));
@@ -451,7 +451,7 @@ static int i915_ttm_accel_move(struct ttm_buffer_object *bo,
if (bo->type == ttm_bo_type_kernel)
return -EINVAL;
- if (ttm && !(ttm->page_flags & TTM_PAGE_FLAG_ZERO_ALLOC))
+
Re: [Intel-gfx] [PATCH 1/3] drm/ttm: s/FLAG_SG/FLAG_EXTERNAL/
On Thu, 30 Sept 2021 at 08:45, Christian König wrote:
>
> Am 30.09.21 um 09:42 schrieb Matthew Auld:
> > On Thu, 30 Sept 2021 at 08:28, Christian König
> > wrote:
> >> I pushed those to drm-misc-next and fixed the i915 merge fallout in
> >> drm-tip.
> >>
> >> Maybe take another look at the resolution in drm-tip if you have time.
> > Thanks, although it looks like there is some breakage in the build on
> > drm-tip:
> >
> > drivers/gpu/drm/ttm/ttm_bo_util.c: In function ‘ttm_bo_move_memcpy’:
> > drivers/gpu/drm/ttm/ttm_bo_util.c:172:44: error:
> > ‘TTM_PAGE_FLAG_ZERO_ALLOC’ undeclared (first use in this function);
> > did you mean ‘TTM_TT_FLAG_ZERO_ALLOC’?
> > 172 | if (!(clear && ttm && !(ttm->page_flags & TTM_PAGE_FLAG_ZERO_ALLOC)))
> >
> > ...
> >
> > drivers/gpu/drm/i915/gem/i915_gem_ttm.c: In function ‘i915_ttm_move’:
> > drivers/gpu/drm/i915/gem/i915_gem_ttm.c:576:44: error:
> > ‘TTM_PAGE_FLAG_ZERO_ALLOC’ undeclared (first use in this function);
> > did you mean ‘TTM_TT_FLAG_ZERO_ALLOC’?
> > 576 | if (!(clear && ttm && !(ttm->page_flags & TTM_PAGE_FLAG_ZERO_ALLOC)))
> > | ^~~~
> > | TTM_TT_FLAG_ZERO_ALLOC
> >
>
> Crap, I hoped that I got all of those.
>
> > Do we just need to revert the bad commit in drm-rerere, rebuild tip,
> > and try again? If so I can try to attempt this.
>
> Yes, please do so. I can't easily build drm-tip, would need to setup
> another box extra for this.
Ok, hopefully sorted now.
>
> Christian.
>
> >
> >> Christian.
> >>
> >> Am 29.09.21 um 15:26 schrieb Matthew Auld:
> >>> It covers more than just ttm_bo_type_sg usage, like with say dma-buf,
> >>> since one other user is userptr in amdgpu, and in the future we might
> >>> have some more. Hence EXTERNAL is likely a more suitable name.
> >>>
> >>> v2(Christian):
> >>> - Rename these to TTM_TT_FLAGS_*
> >>> - Fix up all the holes in the flag values
> >>>
> >>> Suggested-by: Christian König
> >>> Signed-off-by: Matthew Auld
> >>> Cc: Thomas Hellström
> >>> Cc: Christian König
> >>> Acked-by: Christian König
> >>> ---
> >>>drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 10 +-
> >>>drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 6 +++---
> >>>drivers/gpu/drm/nouveau/nouveau_bo.c| 4 ++--
> >>>drivers/gpu/drm/radeon/radeon_ttm.c | 8
> >>>drivers/gpu/drm/ttm/ttm_bo.c| 4 ++--
> >>>drivers/gpu/drm/ttm/ttm_bo_util.c | 4 ++--
> >>>drivers/gpu/drm/ttm/ttm_bo_vm.c | 2 +-
> >>>drivers/gpu/drm/ttm/ttm_pool.c | 2 +-
> >>>drivers/gpu/drm/ttm/ttm_tt.c| 24
> >>>include/drm/ttm/ttm_device.h| 2 +-
> >>>include/drm/ttm/ttm_tt.h| 18 +-
> >>>11 files changed, 42 insertions(+), 42 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> >>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> >>> index 60b12bb55244..e8d70b6e6737 100644
> >>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> >>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> >>> @@ -894,7 +894,7 @@ static int amdgpu_ttm_backend_bind(struct ttm_device
> >>> *bdev,
> >>>DRM_ERROR("failed to pin userptr\n");
> >>>return r;
> >>>}
> >>> - } else if (ttm->page_flags & TTM_PAGE_FLAG_SG) {
> >>> + } else if (ttm->page_flags & TTM_TT_FLAG_EXTERNAL) {
> >>>if (!ttm->sg) {
> >>>struct dma_buf_attachment *attach;
> >>>struct sg_table *sgt;
> >>> @@ -1130,7 +1130,7 @@ static int amdgpu_ttm_tt_populate(struct ttm_device
> >>> *bdev,
> >>>return 0;
> >>>}
> >>>
> >>> - if (ttm->page_flags & TTM_PAGE_FLAG_SG)
> >>> + if (ttm->page_flags & TTM_TT_FLAG_EXTERNAL)
> >>>return 0;
> >>>
> >>>ret = ttm_pool_alloc(&adev->mman.bdev.pool, ttm, ctx);
> >>> @@ -1165,7 +1165,7 @@ static void amdgpu_ttm_tt_unpopulate(struct
> >>> ttm_device *bdev,
> >>>return;
> >>>}
> >>>
> >>> - if (ttm->page_flags & TTM_PAGE_FLAG_SG)
> >>> + if (ttm->page_flags & TTM_TT_FLAG_EXTERNAL)
> >>>return;
> >>>
> >>>for (i = 0; i < ttm->num_pages; ++i)
> >>> @@ -1198,8 +1198,8 @@ int amdgpu_ttm_tt_set_userptr(struct
> >>> ttm_buffer_object *bo,
> >>>return -ENOMEM;
> >>>}
> >>>
> >>> - /* Set TTM_PAGE_FLAG_SG before populate but after create. */
> >>> - bo->ttm->page_flags |= TTM_PAGE_FLAG_SG;
> >>> + /* Set TTM_TT_FLAG_EXTERNAL before populate but after create. */
> >>> + bo->ttm->page_flags |= TTM_TT_FLAG_EXTERNAL;
> >>>
> >>>gtt = (void *)bo->ttm;
> >>>gtt->userptr = addr;
> >>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> >>> b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> >>> index f0a61a9474fc..8beef57ba52b 100644
> >>> --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> >>> +++ b/drive
[PATCH v4 0/7] Add support to the mmsys driver to be a reset controller
Dear all,
The following patchset is a reimplementation of the patch sent by Jitao
Shi [1] some time ago. As suggested by Chun-Kuang Hu, this time the
reset is done using the reset API, where the mmsys driver is the reset
controller and the mtk_dsi driver is the reset consumer.
Note that the first patch is kind of unrelated change, it's just a
cleanup but is needed if you want to apply all the following patches
cleanly.
This patchset is important in order to have the DSI panel working on some
kukui MT8183 Chromebooks (i.e Lenovo IdeaPad Duet). Without it, you just
get a black screen.
Best regards,
Enric
[1]
https://lore.kernel.org/linux-arm-kernel/20210420132614.150242-4-jitao@mediatek.com/
Changes in v4:
- Remove unnused variable as pointed by Hsin-Yi
Changes in v3:
- Based on top of the patch that converts mmsys to schema
- Fix typo in the commit description
Changes in v2:
- Fix build test ERROR Reported-by: kernel test robot
- Added a new patch to describe the dsi reset optional property.
Enric Balletbo i Serra (7):
arm64: dts: mediatek: Move reset controller constants into common
location
dt-bindings: mediatek: Add #reset-cells to mmsys system controller
dt-bindings: display: mediatek: add dsi reset optional property
arm64: dts: mt8173: Add the mmsys reset bit to reset the dsi0
arm64: dts: mt8183: Add the mmsys reset bit to reset the dsi0
soc: mediatek: mmsys: Add reset controller support
drm/mediatek: mtk_dsi: Reset the dsi0 hardware
.../bindings/arm/mediatek/mediatek,mmsys.yaml | 4 ++
.../display/mediatek/mediatek,dsi.txt | 6 ++
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 2 +
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 5 +-
drivers/gpu/drm/mediatek/mtk_dsi.c| 5 +-
drivers/soc/mediatek/mtk-mmsys.c | 68 +++
drivers/soc/mediatek/mtk-mmsys.h | 2 +
drivers/watchdog/mtk_wdt.c| 6 +-
.../mt2712-resets.h | 0
include/dt-bindings/reset/mt8173-resets.h | 2 +
.../mt8183-resets.h | 3 +
.../mt8192-resets.h | 0
12 files changed, 97 insertions(+), 6 deletions(-)
rename include/dt-bindings/{reset-controller => reset}/mt2712-resets.h (100%)
rename include/dt-bindings/{reset-controller => reset}/mt8183-resets.h (98%)
rename include/dt-bindings/{reset-controller => reset}/mt8192-resets.h (100%)
--
2.30.2
[PATCH v4 3/7] dt-bindings: display: mediatek: add dsi reset optional property
Update device tree binding documentation for the dsi to add the optional
property to reset the dsi controller.
Signed-off-by: Enric Balletbo i Serra
Acked-by: Rob Herring
---
(no changes since v2)
Changes in v2:
- Added a new patch to describe the dsi reset optional property.
.../devicetree/bindings/display/mediatek/mediatek,dsi.txt | 6 ++
1 file changed, 6 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
index d30428b9fb33..36b01458f45c 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
@@ -19,6 +19,11 @@ Required properties:
Documentation/devicetree/bindings/graph.txt. This port should be connected
to the input port of an attached DSI panel or DSI-to-eDP encoder chip.
+Optional properties:
+- resets: list of phandle + reset specifier pair, as described in [1].
+
+[1] Documentation/devicetree/bindings/reset/reset.txt
+
MIPI TX Configuration Module
@@ -45,6 +50,7 @@ dsi0: dsi@1401b000 {
clocks = <&mmsys MM_DSI0_ENGINE>, <&mmsys MM_DSI0_DIGITAL>,
<&mipi_tx0>;
clock-names = "engine", "digital", "hs";
+ resets = <&mmsys MT8173_MMSYS_SW0_RST_B_DISP_DSI0>;
phys = <&mipi_tx0>;
phy-names = "dphy";
--
2.30.2
[PATCH v4 7/7] drm/mediatek: mtk_dsi: Reset the dsi0 hardware
Reset dsi0 HW to default when power on. This prevents to have different settingis between the bootloader and the kernel. As not all Mediatek boards have the reset consumer configured in their board description, also is not needed on all of them, the reset is optional, so the change is compatible with all boards. Cc: Jitao Shi Suggested-by: Chun-Kuang Hu Signed-off-by: Enric Balletbo i Serra Acked-by: Chun-Kuang Hu Reviewed-by: Matthias Brugger --- (no changes since v3) Changes in v3: - Fix typo in the commit description drivers/gpu/drm/mediatek/mtk_dsi.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c index 93b40c245f00..5d90d2eb0019 100644 --- a/drivers/gpu/drm/mediatek/mtk_dsi.c +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c @@ -11,6 +11,7 @@ #include #include #include +#include #include #include @@ -980,8 +981,10 @@ static int mtk_dsi_bind(struct device *dev, struct device *master, void *data) struct mtk_dsi *dsi = dev_get_drvdata(dev); ret = mtk_dsi_encoder_init(drm, dsi); + if (ret) + return ret; - return ret; + return device_reset_optional(dev); } static void mtk_dsi_unbind(struct device *dev, struct device *master, -- 2.30.2
Re: [PATCH v2 2/4] drm/v3d: alloc and init job in one shot
On Wed, 2021-09-29 at 10:43 +0100, Melissa Wen wrote:
> 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.
>
> Suggested-by: Iago Toral
> Signed-off-by: Melissa Wen
> ---
> drivers/gpu/drm/v3d/v3d_gem.c | 115 +---
> --
> 1 file changed, 42 insertions(+), 73 deletions(-)
>
> diff --git a/drivers/gpu/drm/v3d/v3d_gem.c
> b/drivers/gpu/drm/v3d/v3d_gem.c
> index e60fbc28ef29..9cfa6f8d4357 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,12 +453,20 @@ 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;
>
Right below this hunk we have an early return that doesn't jump to
fail:
ret = pm_runtime_get_sync(v3d->drm.dev);
if (ret < 0)
return ret;
so we should kfree(*container) and set it to NULL there, right?
> @@ -479,6 +490,9 @@ v3d_job_init(struct v3d_dev *v3d, struct drm_file
> *file_priv,
> drm_sched_job_cleanup(&job->base);
> fail:
> pm_runtime_put_autosuspend(v3d->drm.dev);
> + kfree(*container);
> + *container = NULL;
> +
> return ret;
> }
>
(...)
> @@ -806,29 +789,15 @@ v3d_submit_csd_ioctl(struct drm_device *dev,
> void *data,
> return -EINVAL;
> }
>
> - job = kcalloc(1, sizeof(*job), GFP_KERNEL);
> - if (!job)
> - return -ENOMEM;
> -
> - ret = v3d_job_init(v3d, file_priv, &job->base,
> + ret = v3d_job_init(v3d, file_priv, (void *)&job, sizeof(*job),
> v3d_job_free, args->in_sync, V3D_CSD);
> - if (ret) {
> - kfree(job);
> - return ret;
> - }
> -
> - clean_job = kcalloc(1, sizeof(*clean_job), GFP_KERNEL);
> - if (!clean_job) {
> - v3d_job_cleanup(&job->base);
> - return -ENOMEM;
> - }
> + if (ret)
> + goto fail;
>
For this to work we need to explicitly initialize clean_job to NULL.
Notice that the same applies to the bin and clean jobs in the CL ioctl,
but in that case we're already initializing them to NULL.
> - ret = v3d_job_init(v3d, file_priv, clean_job, v3d_job_free, 0,
> V3D_CACHE_CLEAN);
> - if (ret) {
> - v3d_job_cleanup(&job->base);
> - kfree(clean_job);
> - return ret;
> - }
> + ret = v3d_job_init(v3d, file_priv, (void *)&clean_job,
> sizeof(*clean_job),
> +v3d_job_free, 0, V3D_CACHE_CLEAN);
> + if (ret)
> + goto fail;
>
> job->args = *args;
>
> @@ -877,7 +846,7 @@ v3d_submit_csd_ioctl(struct drm_device *dev, void
> *data,
> drm_gem_unlock_reservations(clean_job->bo, clean_job->bo_count,
> &acquire_ctx);
> fail:
> - v3d_job_cleanup(&job->base);
> + v3d_job_cleanup((void *)job);
> v3d_job_cleanup(clean_job);
>
> return ret;
[PULL] drm-intel-fixes
Hi Dave & Daniel - drm-intel-fixes-2021-09-30: drm/i915 fixes for v5.15-rc4: - Fix GVT scheduler ww lock usage - Fix pdfdocs documentation build - Fix request early tracepoints - Fix an invalid warning from rps worker BR, Jani. The following changes since commit 5816b3e6577eaa676ceb00a848f0fd65fe2adc29: Linux 5.15-rc3 (2021-09-26 14:08:19 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2021-09-30 for you to fetch changes up to 4b8bcaf8a6d6ab5db51e30865def5cb694eb2966: drm/i915: Remove warning from the rps worker (2021-09-27 12:46:40 +0300) drm/i915 fixes for v5.15-rc4: - Fix GVT scheduler ww lock usage - Fix pdfdocs documentation build - Fix request early tracepoints - Fix an invalid warning from rps worker Akira Yokosawa (1): drm/i915/guc, docs: Fix pdfdocs build error by removing nested grid Jani Nikula (1): Merge tag 'gvt-fixes-2021-09-18' of https://github.com/intel/gvt-linux into drm-intel-fixes Matthew Auld (1): drm/i915/request: fix early tracepoints Tejas Upadhyay (1): drm/i915: Remove warning from the rps worker Zhi A Wang (1): drm/i915/gvt: fix the usage of ww lock in gvt scheduler. drivers/gpu/drm/i915/gt/intel_rps.c | 2 -- drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h | 10 +- drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h | 10 +- drivers/gpu/drm/i915/gvt/scheduler.c| 4 ++-- drivers/gpu/drm/i915/i915_request.c | 11 ++- 5 files changed, 14 insertions(+), 23 deletions(-) -- Jani Nikula, Intel Open Source Graphics Center
Re: [PATCH] dma-buf: fix and rework dma_buf_poll v7
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 - if we're waiting already and new fences have been added, wont we miss them? Or does this all work because the poll machinery restarts everything again? 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 v3 0/6] drm/gud: Add some more pixel formats
Hi Am 29.09.21 um 21:11 schrieb Noralf Trønnes: Hi, I'd appreciate if someone could review the 3 small driver patches. Series is Acked-by: Thomas Zimmermann Best regards Thomas Changes since version 2: - Drop the patch adding module parameter 'xrgb'. Both Daniel and Thomas had some comments that eventually led me to to drop this for now. Noralf. Noralf Trønnes (6): drm/fourcc: Add R8 to drm_format_info drm/format-helper: Add drm_fb_xrgb_to_rgb332() drm/format-helper: Add drm_fb_xrgb_to_rgb888() drm/gud: Add GUD_PIXEL_FORMAT_R8 drm/gud: Add GUD_PIXEL_FORMAT_RGB332 drm/gud: Add GUD_PIXEL_FORMAT_RGB888 drivers/gpu/drm/drm_format_helper.c | 88 + drivers/gpu/drm/drm_fourcc.c| 1 + drivers/gpu/drm/gud/gud_drv.c | 6 ++ drivers/gpu/drm/gud/gud_internal.h | 12 drivers/gpu/drm/gud/gud_pipe.c | 6 ++ include/drm/drm_format_helper.h | 4 ++ include/drm/gud.h | 6 +- 7 files changed, 121 insertions(+), 2 deletions(-) -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer OpenPGP_signature Description: OpenPGP digital signature
Re: [PATCH v2 2/2] drm/lease: allow empty leases
Hey, On Wed, 22 Sept 2021 at 09:48, Pekka Paalanen wrote: > that is one awesome commit message! It explains everything I might have wanted > to ask. Yeah, what he said. An awesome explanation of a terrible problem. My main worry is that we'd end up tripping over our own feet in either the kernel or libdrm when GetResources got called against an empty-lease file description, but that doesn't seem to be the case: the worst I can see is that we'll return the list of all encoders, which is useless but AFAIK harmless. So this is: Reviewed-by: Daniel Stone Cheers, Daniel
Re: [PATCH v2 3/4] drm/v3d: add generic ioctl extension
On Wed, 2021-09-29 at 10:44 +0100, Melissa Wen wrote:
> 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)
>
> Signed-off-by: Melissa Wen
> ---
> drivers/gpu/drm/v3d/v3d_drv.c | 4 +-
> drivers/gpu/drm/v3d/v3d_gem.c | 71
> +--
> include/uapi/drm/v3d_drm.h| 31 +++
> 3 files changed, 100 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 9cfa6f8d4357..b912419027f7 100644
> --- a/drivers/gpu/drm/v3d/v3d_gem.c
> +++ b/drivers/gpu/drm/v3d/v3d_gem.c
> @@ -535,6 +535,33 @@ v3d_attach_fences_and_unlock_reservation(struct
> drm_file *file_priv,
> }
> }
>
> +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
> @@ -563,15 +590,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_bcl,
> V3D_RENDER);
> if (ret)
> @@ -700,6 +736,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->extension
Re: [PATCH v6 0/2] Add p2p via dmabuf to habanalabs
On Tue, Sep 28, 2021 at 10:04:29AM +0300, Oded Gabbay wrote: > On Thu, Sep 23, 2021 at 12:22 PM Oded Gabbay wrote: > > > > On Sat, Sep 18, 2021 at 11:38 AM Oded Gabbay wrote: > > > > > > On Fri, Sep 17, 2021 at 3:30 PM Daniel Vetter wrote: > > > > > > > > On Thu, Sep 16, 2021 at 10:10:14AM -0300, Jason Gunthorpe wrote: > > > > > On Thu, Sep 16, 2021 at 02:31:34PM +0200, Daniel Vetter wrote: > > > > > > On Wed, Sep 15, 2021 at 10:45:36AM +0300, Oded Gabbay wrote: > > > > > > > On Tue, Sep 14, 2021 at 7:12 PM Jason Gunthorpe > > > > > > > wrote: > > > > > > > > > > > > > > > > On Tue, Sep 14, 2021 at 04:18:31PM +0200, Daniel Vetter wrote: > > > > > > > > > On Sun, Sep 12, 2021 at 07:53:07PM +0300, Oded Gabbay wrote: > > > > > > > > > > Hi, > > > > > > > > > > Re-sending this patch-set following the release of our > > > > > > > > > > user-space TPC > > > > > > > > > > compiler and runtime library. > > > > > > > > > > > > > > > > > > > > I would appreciate a review on this. > > > > > > > > > > > > > > > > > > I think the big open we have is the entire revoke > > > > > > > > > discussions. Having the > > > > > > > > > option to let dma-buf hang around which map to random local > > > > > > > > > memory ranges, > > > > > > > > > without clear ownership link and a way to kill it sounds bad > > > > > > > > > to me. > > > > > > > > > > > > > > > > > > I think there's a few options: > > > > > > > > > - We require revoke support. But I've heard rdma really > > > > > > > > > doesn't like that, > > > > > > > > > I guess because taking out an MR while holding the > > > > > > > > > dma_resv_lock would > > > > > > > > > be an inversion, so can't be done. Jason, can you recap > > > > > > > > > what exactly the > > > > > > > > > hold-up was again that makes this a no-go? > > > > > > > > > > > > > > > > RDMA HW can't do revoke. > > > > > > > > > > > > Like why? I'm assuming when the final open handle or whatever for > > > > > > that MR > > > > > > is closed, you do clean up everything? Or does that MR still stick > > > > > > around > > > > > > forever too? > > > > > > > > > > It is a combination of uAPI and HW specification. > > > > > > > > > > revoke here means you take a MR object and tell it to stop doing DMA > > > > > without causing the MR object to be destructed. > > > > > > > > > > All the drivers can of course destruct the MR, but doing such a > > > > > destruction without explicit synchronization with user space opens > > > > > things up to a serious use-after potential that could be a security > > > > > issue. > > > > > > > > > > When the open handle closes the userspace is synchronized with the > > > > > kernel and we can destruct the HW objects safely. > > > > > > > > > > So, the special HW feature required is 'stop doing DMA but keep the > > > > > object in an error state' which isn't really implemented, and doesn't > > > > > extend very well to other object types beyond simple MRs. > > > > > > > > Yeah revoke without destroying the MR doesn't work, and it sounds like > > > > revoke by destroying the MR just moves the can of worms around to > > > > another > > > > place. > > > > > > > > > > 1. User A opens gaudi device, sets up dma-buf export > > > > > > > > > > > > 2. User A registers that with RDMA, or anything else that doesn't > > > > > > support > > > > > > revoke. > > > > > > > > > > > > 3. User A closes gaudi device > > > > > > > > > > > > 4. User B opens gaudi device, assumes that it has full control over > > > > > > the > > > > > > device and uploads some secrets, which happen to end up in the > > > > > > dma-buf > > > > > > region user A set up > > > > > > > > > > I would expect this is blocked so long as the DMABUF exists - eg the > > > > > DMABUF will hold a fget on the FD of #1 until the DMABUF is closed, so > > > > > that #3 can't actually happen. > > > > > > > > > > > It's not mlocked memory, it's mlocked memory and I can exfiltrate > > > > > > it. > > > > > > > > > > That's just bug, don't make buggy drivers :) > > > > > > > > Well yeah, but given that habanalabs hand rolled this I can't just check > > > > for the usual things we have to enforce this in drm. And generally you > > > > can > > > > just open chardevs arbitrarily, and multiple users fighting over each > > > > another. The troubles only start when you have private state or memory > > > > allocations of some kind attached to the struct file (instead of the > > > > underlying device), or something else that requires device exclusivity. > > > > There's no standard way to do that. > > > > > > > > Plus in many cases you really want revoke on top (can't get that here > > > > unfortunately it seems), and the attempts to get towards a generic > > > > revoke() just never went anywhere. So again it's all hand-rolled > > > > per-subsystem. *insert lament about us not having done this through a > > > > proper subsystem* > > > > > > > > Anyway it sounds like the code takes care of that. > > > > -Daniel > > > > > > Daniel, J
Re: [PATCH v2 2/4] drm/v3d: alloc and init job in one shot
On 09/30, Iago Toral wrote:
> On Wed, 2021-09-29 at 10:43 +0100, Melissa Wen wrote:
> > 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.
> >
> > Suggested-by: Iago Toral
> > Signed-off-by: Melissa Wen
> > ---
> > drivers/gpu/drm/v3d/v3d_gem.c | 115 +---
> > --
> > 1 file changed, 42 insertions(+), 73 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/v3d/v3d_gem.c
> > b/drivers/gpu/drm/v3d/v3d_gem.c
> > index e60fbc28ef29..9cfa6f8d4357 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,12 +453,20 @@ 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;
> >
>
> Right below this hunk we have an early return that doesn't jump to
> fail:
>
> ret = pm_runtime_get_sync(v3d->drm.dev);
> if (ret < 0)
> return ret;
>
>
> so we should kfree(*container) and set it to NULL there, right?
oh, yes. I missed it on porting downstream to upstream.
>
> > @@ -479,6 +490,9 @@ v3d_job_init(struct v3d_dev *v3d, struct drm_file
> > *file_priv,
> > drm_sched_job_cleanup(&job->base);
> > fail:
> > pm_runtime_put_autosuspend(v3d->drm.dev);
> > + kfree(*container);
> > + *container = NULL;
> > +
> > return ret;
> > }
> >
>
> (...)
>
> > @@ -806,29 +789,15 @@ v3d_submit_csd_ioctl(struct drm_device *dev,
> > void *data,
> > return -EINVAL;
> > }
> >
> > - job = kcalloc(1, sizeof(*job), GFP_KERNEL);
> > - if (!job)
> > - return -ENOMEM;
> > -
> > - ret = v3d_job_init(v3d, file_priv, &job->base,
> > + ret = v3d_job_init(v3d, file_priv, (void *)&job, sizeof(*job),
> >v3d_job_free, args->in_sync, V3D_CSD);
> > - if (ret) {
> > - kfree(job);
> > - return ret;
> > - }
> > -
> > - clean_job = kcalloc(1, sizeof(*clean_job), GFP_KERNEL);
> > - if (!clean_job) {
> > - v3d_job_cleanup(&job->base);
> > - return -ENOMEM;
> > - }
> > + if (ret)
> > + goto fail;
> >
>
> For this to work we need to explicitly initialize clean_job to NULL.
> Notice that the same applies to the bin and clean jobs in the CL ioctl,
> but in that case we're already initializing them to NULL.
yes, thanks for pointing it out.
Melissa
>
> > - ret = v3d_job_init(v3d, file_priv, clean_job, v3d_job_free, 0,
> > V3D_CACHE_CLEAN);
> > - if (ret) {
> > - v3d_job_cleanup(&job->base);
> > - kfree(clean_job);
> > - return ret;
> > - }
> > + ret = v3d_job_init(v3d, file_priv, (void *)&clean_job,
> > sizeof(*clean_job),
> > + v3d_job_free, 0, V3D_CACHE_CLEAN);
> > + if (ret)
> > + goto fail;
> >
> > job->args = *args;
> >
> > @@ -877,7 +846,7 @@ v3d_submit_csd_ioctl(struct drm_device *dev, void
> > *data,
> > drm_gem_unlock_reservations(clean_job->bo, clean_job->bo_count,
> > &acquire_ctx);
> > fail:
> > - v3d_job_cleanup(&job->base);
> > + v3d_job_cleanup((void *)job);
> > v3d_job_cleanup(clean_job);
> >
> > return ret;
>
signature.asc
Description: PGP signature
Re: Regression with mainline kernel on rpi4
On Tue, Sep 28, 2021 at 10:34:46AM +0200, Maxime Ripard wrote: > Hi Daniel, > > On Sat, Sep 25, 2021 at 12:50:17AM +0200, Daniel Vetter wrote: > > On Fri, Sep 24, 2021 at 3:30 PM Maxime Ripard wrote: > > > > > > On Wed, Sep 22, 2021 at 01:25:21PM -0700, Linus Torvalds wrote: > > > > On Wed, Sep 22, 2021 at 1:19 PM Sudip Mukherjee > > > > wrote: > > > > > > > > > > I added some debugs to print the addresses, and I am getting: > > > > > [ 38.813809] sudip crtc > > > > > > > > > > This is from struct drm_crtc *crtc = connector->state->crtc; > > > > > > > > Yeah, that was my personal suspicion, because while the line number > > > > implied "crtc->state" being NULL, the drm data structure documentation > > > > and other drivers both imply that "crtc" was the more likely one. > > > > > > > > I suspect a simple > > > > > > > > if (!crtc) > > > > return; > > > > > > > > in vc4_hdmi_set_n_cts() is at least part of the fix for this all, but > > > > I didn't check if there is possibly something else that needs to be > > > > done too. > > > > > > Thanks for the decode_stacktrace.sh and the follow-up > > > > > > Yeah, it looks like we have several things wrong here: > > > > > > * we only check that connector->state is set, and not > > > connector->state->crtc indeed. > > > > > > * We also check only in startup(), so at open() and not later on when > > > the sound streaming actually start. This has been there for a while, > > > so I guess it's never really been causing a practical issue before. > > > > You also have no locking > > Indeed. Do we just need locking to prevent a concurrent audio setup and > modeset, or do you have another corner case in mind? > > Also, generally, what locks should we make sure we have locked when > accessing the connector and CRTC state? drm_mode_config.connection_mutex > and drm_mode_config.mutex, respectively? > > > plus looking at ->state objects outside of atomic commit machinery > > makes no sense because you're not actually in sync with the hw state. > > Relevant bits need to be copied over at commit time, protected by some > > spinlock (and that spinlock also needs to be held over whatever other > > stuff you're setting to make sure we don't get a funny out-of-sync > > state anywhere). > > If we already have a lock protecting against having both an ASoC and KMS > function running, it's not clear to me what the spinlock would prevent > here? Replicating the irc chat here. With commit 6c5ed5ae353cdf156f9ac4db17e15db56b4de880 Author: Maarten Lankhorst Date: Thu Apr 6 20:55:20 2017 +0200 drm/atomic: Acquire connection_mutex lock in drm_helper_probe_single_connector_modes, v4. this is already taken care of for drivers and should be all good from a locking pov. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH v2 3/4] drm/v3d: add generic ioctl extension
O 09/30, Iago Toral wrote:
> On Wed, 2021-09-29 at 10:44 +0100, Melissa Wen wrote:
> > 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)
> >
> > Signed-off-by: Melissa Wen
> > ---
> > drivers/gpu/drm/v3d/v3d_drv.c | 4 +-
> > drivers/gpu/drm/v3d/v3d_gem.c | 71
> > +--
> > include/uapi/drm/v3d_drm.h| 31 +++
> > 3 files changed, 100 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 9cfa6f8d4357..b912419027f7 100644
> > --- a/drivers/gpu/drm/v3d/v3d_gem.c
> > +++ b/drivers/gpu/drm/v3d/v3d_gem.c
> > @@ -535,6 +535,33 @@ v3d_attach_fences_and_unlock_reservation(struct
> > drm_file *file_priv,
> > }
> > }
> >
> > +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
> > @@ -563,15 +590,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_bcl,
> > V3D_RENDER);
> > if (ret)
> > @@ -700,6 +736,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
Re: Handling DRM master transitions cooperatively
On Thu, Sep 23, 2021 at 11:23:00AM +0300, Pekka Paalanen wrote: > On Wed, 22 Sep 2021 11:21:16 +0200 > Hans de Goede wrote: > > > Hi, > > > > On 9/22/21 10:56 AM, Pekka Paalanen wrote: > > > On Tue, 14 Sep 2021 15:45:21 +0200 > > > Daniel Vetter wrote: > > > > > >> On Thu, Sep 09, 2021 at 10:37:03AM +0300, Pekka Paalanen wrote: > > >>> On Wed, 8 Sep 2021 18:27:09 +0200 > > >>> Daniel Vetter wrote: > > >>> > > On Wed, Sep 8, 2021 at 9:36 AM Pekka Paalanen > > wrote: > > > > > > On Tue, 7 Sep 2021 14:42:56 +0200 > > > Hans de Goede wrote: > > > > > >> Hi, > > >> > > >> On 9/7/21 12:07 PM, Pekka Paalanen wrote: > > >>> On Fri, 3 Sep 2021 21:08:21 +0200 > > >>> Dennis Filder wrote: > > >>> > > Hans de Goede asked me to take a topic from a private discussion > > here. > > I must also preface that I'm not a graphics person and my > > knowledge of > > DRI/DRM is cursory at best. > > > > I initiated the conversation with de Goede after learning that the > > X > > server now supports being started with an open DRM file descriptor > > (this was added for Keith Packard's xlease project). I wondered if > > that could be used to smoothen the Plymouth->X transition somehow > > and > > asked de Goede if there were any such plans. He denied, but > > mentioned > > that a new ioctl is in the works to prevent the kernel from wiping > > the > > contents of a frame buffer after a device is closed, and that this > > would help to keep transitions smooth. > > >>> > > >>> Hi, > > >>> > > >>> I believe the kernel is not wiping anything on device close. If > > >>> something in the KMS state is wiped, it originates in userspace: > > >>> > > >>> - Plymouth doing something (e.g. RmFB on an in-use FB will turn the > > >>> output off, you need to be careful to "leak" your FB if you want a > > >>> smooth hand-over) > > >> > > >> The "kernel is not wiping anything on device close" is not true, > > >> when closing /dev/dri/card# any remaining FBs from the app closing > > >> it will be dealt with as if they were RmFB-ed, causing the screen > > >> to show what I call "the fallback fb", at least with the i915 > > >> driver. > > > > > > No, that's not what should happen AFAIK. > > > > > > True, all FBs that are not referenced by active CRTCs or planes will > > > get freed, since their refcount drops to zero, but those CRTCs and > > > planes that are active will remain active and therefore keep their > > > reference to the respective FBs and so the FBs remain until replaced > > > or > > > turned off explicitly (by e.g. fbcon if you switch to that rather than > > > another userspace KMS client). I believe that is the whole reason why > > > e.g. DRM_IOCTL_MODE_GETFB2 can be useful, otherwise the next KMS > > > client > > > would not have anything to scrape. > > > > > > danvet, what is the DRM core intention? > > > > Historical accidents mostly. There's two things that foil easy > > handover to the next compositor: > > - RMFB instead of CLOSEFB semantics, especially when closing the > > drmfd. This is uapi, so anything we change needs to be opt-in > > >>> > > >>> What does this mean and refer to? > > >>> > > >>> Are you trying to say, that closing the DRM device fd (freeing the file > > >>> description) causes an implicit RmFB on all the FBs tied to that DRM > > >>> device file description? > > >>> > > >>> I never realised that before. > > >> > > >> Yes, final close does iterate over fb and do an RMFB. Which is why we've > > >> had this discussion whether closefb semantics should be an ADDFB2 flag at > > >> creation time instead. > > > > > > Hi Daniel, > > > > > > such flag would make sense to me. > > > > Hmm, I was thinking having a separate call to mark a FB to switch to > > closefb semantics. But both plymouth (because of end of animation) > > and GNOME (because a mostly empty gnome-shell needs to be rendered > > to avoid leaking privacy sensitive info) will need to prepare a > > special FB on exit anyways, so then an ADDFB2 flag would work fine. > > > > I would be happy to work on the plymouth side of this, so that we > > have at least one consumer of such a flag lined up for merging. > > Right, but I'm thinking this from the other side: why would anyone > deliberately *want* RmFB semantics on device close? > > I can't think of any, and hence I would be inclined to assume that > userspace would just switch to using closefb semantics for everything > all the time. > > Legacy userspace is one thing, but userspace that is updated to set > closefb semantics will also be aware of what closefb means: i
Re: [PATCH v2 2/2] drm/lease: allow empty leases
Thanks a lot for the reviews!
[PATCH] drm/amdgpu: fix some repeated includings
Remove two repeated includings in line 62 and 63. Signed-off-by: Guo Zhengkui --- drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c | 2 -- 1 file changed, 2 deletions(-) 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 @@ -59,8 +59,6 @@ #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" -- 2.20.1
Re: [PATCH] dma-buf: fix and rework dma_buf_poll v7
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. - 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. 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
Re: [PATCH v2 4/4] drm/v3d: add multiple syncobjs support
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.
> + 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 (has_multisync) {
> + if (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_job;
> + }
> + ret = v3d_job_add_deps(file_priv, job,
> in.handle, 0);
> + if (ret)
> + goto fail_job;
> + }
> + }
> + } else {
> + ret = v3d_job_add_deps(file_priv,
Re: [PATCH v2 3/4] drm/v3d: add generic ioctl extension
On Thu, 2021-09-30 at 10:22 +0100, Melissa Wen wrote:
> > >
> O 09/30, Iago Toral wrote:
> > On Wed, 2021-09-29 at 10:44 +0100, Melissa Wen wrote:
(...)
> > > /**
> > > * struct drm_v3d_submit_cl - ioctl argument for submitting
> > > commands
> > > to the 3D
> > > @@ -135,12 +149,16 @@ struct drm_v3d_submit_cl {
> > > /* Number of BO handles passed in (size is that times 4). */
> > > __u32 bo_handle_count;
> > >
> > > + /* DRM_V3D_SUBMIT_* properties */
> > > __u32 flags;
> > >
> > > /* ID of the perfmon to attach to this job. 0 means no perfmon.
> > > */
> > > __u32 perfmon_id;
> > >
> > > __u32 pad;
> > > +
> > > + /* Pointer to an array of ioctl extensions*/
> > > + __u64 extensions;
> > > };
> > >
> > > /**
> > > @@ -248,6 +266,12 @@ struct drm_v3d_submit_tfu {
> > > __u32 in_sync;
> > > /* Sync object to signal when the TFU job is done. */
> > > __u32 out_sync;
> > > +
> > > + __u32 flags;
> > > +
> > > + /* Pointer to an array of ioctl extensions*/
> > > + __u64 extensions;
> >
> > We want __u64 fields aligned to 64-bit so we should swap the
> > positions
> > of flags and extensions.
>
> hmm.. not sure. before two arrays of 4 x _u32 elements, we have seven
> _u32 elements... this is why I counted a odd number of _u32 and put
> _u32
> flags before _u64 extensions... or is it working different for array
> types?
>
Ah yes, I was confused by the patch format, but you're right.
> For the same reason, I think there is an unalignment issue on
> submit_csd that would need to change the current interface to solve
> (afaiu)...
>
Yes, that one is not aligned, but it is too late to fix now without
braking the interface. We have not seen any issues caused by that on
32-bit Raspbian though.
Iago
> > > +
> > > };
> > >
> > > /* Submits a compute shader for dispatch. This job will block
> > > on
> > > any
> > > @@ -276,6 +300,13 @@ struct drm_v3d_submit_csd {
> > >
> > > /* ID of the perfmon to attach to this job. 0 means no perfmon.
> > > */
> > > __u32 perfmon_id;
> > > +
> > > + /* Pointer to an array of ioctl extensions*/
> > > + __u64 extensions;
> > > +
> > > + __u32 flags;
> > > +
> > > + __u32 pad;
> > > };
> > >
> > > enum {
Re: [PATCH v2 2/3] drm/i915/utils: do not depend on config being defined
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".
Steve
> + __stringify_1(config)[0] == '-'
> \
> +)
>
> #endif /* !__I915_UTILS_H */
>
Re: [PATCH v5 12/13] drm/i915/ttm: use cached system pages when evicting lmem
On 2021-09-29 13:54, Thomas Hellström wrote:
> On Mon, 2021-09-27 at 12:41 +0100, Matthew Auld wrote:
>> This should let us do an accelerated copy directly to the shmem pages
>> when temporarily moving lmem-only objects, where the i915-gem
>> shrinker
>> can later kick in to swap out the pages, if needed.
>>
>> Signed-off-by: Matthew Auld
>> Cc: Thomas Hellström
>> ---
>> drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 8
>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
>> b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
>> index 194e5f1deda8..46d57541c0b2 100644
>> --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
>> @@ -134,11 +134,11 @@ static enum ttm_caching
>> i915_ttm_select_tt_caching(const struct drm_i915_gem_object *obj)
>> {
>> /*
>> - * Objects only allowed in system get cached cpu-mappings.
>> - * Other objects get WC mapping for now. Even if in system.
>> + * Objects only allowed in system get cached cpu-mappings, or
>> when
>> + * evicting lmem-only buffers to system for swapping. Other
>> objects get
>> + * WC mapping for now. Even if in system.
>> */
>> - if (obj->mm.region->type == INTEL_MEMORY_SYSTEM &&
>> - obj->mm.n_placements <= 1)
>> + if (obj->mm.n_placements <= 1)
>> return ttm_cached;
>>
>> return ttm_write_combined;
>
> We should be aware that with TTM, even evicted bos can be mapped by
> user-space while evicted, and this will appear to user-space like the
> WC-mapped object suddenly became WB-mapped. But it appears like mesa
> doesn't care about this as long as the mappings are fully coherent.
FWIW, the Mesa radeonsi driver avoids surprises due to this (e.g. some path
which involves CPU access suddenly goes faster if the BO was evicted from VRAM)
by asking for WC mapping of BOs intended to be in VRAM even while they're
evicted (via the AMDGPU_GEM_CREATE_CPU_GTT_USWC flag).
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
[PATCH v1 2/3] drm: panel-simple: Add support for the Innolux G070Y2-T02 panel
Add compatible and timings for the Innolux G070Y2-T02 panel. It is 7"
WVGA (800x480) TFT LCD panel with TTL interface and a backlight unit.
Co-Developed-by: Robin van der Gracht
Signed-off-by: Robin van der Gracht
Signed-off-by: Oleksij Rempel
---
drivers/gpu/drm/panel/panel-simple.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 9b6c4e6c38a1..a03b60f6fa99 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2524,6 +2524,19 @@ static const struct panel_desc innolux_g070y2_l01 = {
.connector_type = DRM_MODE_CONNECTOR_LVDS,
};
+static const struct panel_desc innolux_g070y2_t02 = {
+ .modes = &innolux_at070tn92_mode,
+ .num_modes = 1,
+ .bpc = 8,
+ .size = {
+ .width = 152,
+ .height = 92,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
+ .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE,
+ .connector_type = DRM_MODE_CONNECTOR_DPI,
+};
+
static const struct display_timing innolux_g101ice_l01_timing = {
.pixelclock = { 6040, 7110, 7470 },
.hactive = { 1280, 1280, 1280 },
@@ -4663,6 +4676,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "innolux,g070y2-l01",
.data = &innolux_g070y2_l01,
+ }, {
+ .compatible = "innolux,g070y2-t02",
+ .data = &innolux_g070y2_t02,
}, {
.compatible = "innolux,g101ice-l01",
.data = &innolux_g101ice_l01
--
2.30.2
[PATCH v1 1/3] dt-bindings: display: simple: add Innolux G070Y2-T02 panel
Add binding for the Innolux G070Y2-T02 panel. It is 7" WVGA (800x480) TFT LCD panel with TTL interface and a backlight unit. Signed-off-by: Oleksij Rempel --- .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml index 335776c45474..2f1c0928d260 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -166,6 +166,8 @@ properties: - innolux,at070tn92 # Innolux G070Y2-L01 7" WVGA (800x480) TFT LCD panel - innolux,g070y2-l01 +# Innolux G070Y2-T02 7" WVGA (800x480) TFT LCD TTL panel + - innolux,g070y2-t02 # Innolux Corporation 10.1" G101ICE-L01 WXGA (1280x800) LVDS panel - innolux,g101ice-l01 # Innolux Corporation 12.1" WXGA (1280x800) TFT LCD panel -- 2.30.2
[PATCH v1 3/3] panel-simple: add LOGIC Technologies LTTD800480070-L2RT panel
From: Søren Andersen
Add support for the Logic Technologies LTTD800x480 L2RT 7" 800x480 TFT
Resistive Touch Module.
Signed-off-by: Søren Andersen
Signed-off-by: Sam Ravnborg
Signed-off-by: Oleksij Rempel
---
drivers/gpu/drm/panel/panel-simple.c | 35
1 file changed, 35 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index a03b60f6fa99..fdcba94c02da 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -3139,6 +3139,38 @@ static const struct panel_desc logictechno_lt170410_2whc
= {
.connector_type = DRM_MODE_CONNECTOR_LVDS,
};
+static const struct drm_display_mode logictechno_lttd800480070_l2rt_mode = {
+ .clock = 33000,
+ .hdisplay = 800,
+ .hsync_start = 800 + 112,
+ .hsync_end = 800 + 112 + 3,
+ .htotal = 800 + 112 + 3 + 85,
+ .vdisplay = 480,
+ .vsync_start = 480 + 38,
+ .vsync_end = 480 + 38 + 3,
+ .vtotal = 480 + 38 + 3 + 29,
+ .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
+};
+
+static const struct panel_desc logictechno_lttd800480070_l2rt = {
+ .modes = &logictechno_lttd800480070_l2rt_mode,
+ .num_modes = 1,
+ .bpc = 8,
+ .size = {
+ .width = 154,
+ .height = 86,
+ },
+ .delay = {
+ .prepare = 45,
+ .enable = 100,
+ .disable = 100,
+ .unprepare = 45
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
+ .bus_flags = DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE,
+ .connector_type = DRM_MODE_CONNECTOR_DPI,
+};
+
static const struct drm_display_mode logictechno_lttd800480070_l6wh_rt_mode = {
.clock = 33000,
.hdisplay = 800,
@@ -4754,6 +4786,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "logictechno,lt170410-2whc",
.data = &logictechno_lt170410_2whc,
+ }, {
+ .compatible = "logictechno,lttd800480070-l2rt",
+ .data = &logictechno_lttd800480070_l2rt,
}, {
.compatible = "logictechno,lttd800480070-l6wh-rt",
.data = &logictechno_lttd800480070_l6wh_rt,
--
2.30.2
[PULL] drm-misc-fixes
drm-misc-fixes-2021-09-30: drm-misc-fixes for v5.15: - Not sure if drm-misc-fixes-2021-09-08 tag was pulled, assuming it is. - Power management fixes for vc4. - Compiler fix for vc4. - Cursor fix for nouveau. - Fix ttm buffer moves for ampere gpu's by adding minimal acceleration support. - Small rockchip fixes. - Fix DT bindings indent for ili9341. - Fix y030xx067a init sequence to not get a yellow tint. - Kconfig fix for fb_simple vs simpledrm. The following changes since commit 6880fa6c56601bb8ed59df6c30fd390cc5f6dd8f: Linux 5.15-rc1 (2021-09-12 16:28:37 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2021-09-30 for you to fetch changes up to fd09961dbb9ca6558d8ad318a3967c1048bdb090: fbdev: simplefb: fix Kconfig dependencies (2021-09-29 09:26:58 +0200) drm-misc-fixes for v5.15: - Not sure if drm-misc-fixes-2021-09-08 tag was pulled, assuming it is. - Power management fixes for vc4. - Compiler fix for vc4. - Cursor fix for nouveau. - Fix ttm buffer moves for ampere gpu's by adding minimal acceleration support. - Small rockchip fixes. - Fix DT bindings indent for ili9341. - Fix y030xx067a init sequence to not get a yellow tint. - Kconfig fix for fb_simple vs simpledrm. Arnd Bergmann (1): fbdev: simplefb: fix Kconfig dependencies Ben Skeggs (3): drm/nouveau/kms/tu102-: delay enabling cursor until after assign_windows drm/nouveau/ga102-: support ttm buffer moves via copy engine drm/nouveau/fifo/ga102: initialise chid on return from channel creation Chris Morgan (1): drm/rockchip: Update crtc fixup to account for fractional clk change Christophe Branchereau (1): drm/panel: abt-y030xx067a: yellow tint fix Edmund Dea (1): drm/kmb: Enable alpha blended second plane Jernej Skrabec (1): drm/sun4i: dw-hdmi: Fix HDMI PHY clock setup Krzysztof Kozlowski (1): dt-bindings: panel: ili9341: correct indentation Maarten Lankhorst (1): Merge drm/drm-fixes into drm-misc-fixes Maxime Ripard (7): drm/vc4: select PM drm/vc4: hdmi: Make sure the controller is powered up during bind drm/vc4: hdmi: Rework the pre_crtc_configure error handling drm/vc4: hdmi: Split the CEC disable / enable functions in two drm/vc4: hdmi: Make sure the device is powered with CEC drm/vc4: hdmi: Warn if we access the controller while disabled drm/vc4: hdmi: Remove unused struct Palmer Dabbelt (1): drm/rockchip: cdn-dp-core: Fix cdn_dp_resume unused warning xinhui pan (1): drm/ttm: Fix a deadlock if the target BO is not idle during swap .../bindings/display/panel/ilitek,ili9341.yaml | 2 +- drivers/gpu/drm/kmb/kmb_drv.c | 8 +- drivers/gpu/drm/kmb/kmb_drv.h | 5 + drivers/gpu/drm/kmb/kmb_plane.c| 81 +- drivers/gpu/drm/kmb/kmb_plane.h| 5 +- drivers/gpu/drm/kmb/kmb_regs.h | 3 + drivers/gpu/drm/nouveau/dispnv50/head.c| 2 +- drivers/gpu/drm/nouveau/include/nvif/class.h | 2 + drivers/gpu/drm/nouveau/include/nvkm/engine/fifo.h | 1 + drivers/gpu/drm/nouveau/nouveau_bo.c | 1 + drivers/gpu/drm/nouveau/nouveau_chan.c | 6 +- drivers/gpu/drm/nouveau/nouveau_drm.c | 4 + drivers/gpu/drm/nouveau/nv84_fence.c | 2 +- drivers/gpu/drm/nouveau/nvkm/engine/device/base.c | 3 + drivers/gpu/drm/nouveau/nvkm/engine/fifo/Kbuild| 1 + drivers/gpu/drm/nouveau/nvkm/engine/fifo/ga102.c | 311 + drivers/gpu/drm/nouveau/nvkm/subdev/top/ga100.c| 7 +- drivers/gpu/drm/panel/panel-abt-y030xx067a.c | 4 +- drivers/gpu/drm/rockchip/cdn-dp-core.c | 2 +- drivers/gpu/drm/rockchip/rockchip_drm_vop.c| 26 +- drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 7 +- drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 4 +- drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 97 --- drivers/gpu/drm/vc4/Kconfig| 1 + drivers/gpu/drm/vc4/vc4_hdmi.c | 133 + drivers/gpu/drm/vc4/vc4_hdmi_regs.h| 6 + drivers/of/base.c | 1 + drivers/video/fbdev/Kconfig| 5 +- 28 files changed, 591 insertions(+), 139 deletions(-) create mode 100644 drivers/gpu/drm/nouveau/nvkm/engine/fifo/ga102.c
Re: [PATCH] drm/amdgpu: fix some repeated includings
One include is v2, the other is v3, or am I missing something?
[PATCH][next] drm/virtio: fix potential integer overflow on shift of a int
From: Colin Ian King
The left shift of unsigned int 32 bit integer constant 1 is evaluated
using 32 bit arithmetic and then assigned to a signed 64 bit integer.
In the case where i is 32 or more this can lead to an overflow. Fix
this by shifting the value 1ULL instead.
Addresses-Coverity: ("Uninitentional integer overflow")
Fixes: 8d6b006e1f51 ("drm/virtio: implement context init: handle
VIRTGPU_CONTEXT_PARAM_POLL_RINGS_MASK")
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
index 5618a1d5879c..b3b0557d72cf 100644
--- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
+++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
@@ -819,7 +819,7 @@ static int virtio_gpu_context_init_ioctl(struct drm_device
*dev,
if (vfpriv->ring_idx_mask) {
valid_ring_mask = 0;
for (i = 0; i < vfpriv->num_rings; i++)
- valid_ring_mask |= 1 << i;
+ valid_ring_mask |= 1ULL << i;
if (~valid_ring_mask & vfpriv->ring_idx_mask) {
ret = -EINVAL;
--
2.32.0
Re: [PATCH] dma-buf: fix and rework dma_buf_poll v7
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) -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
[PATCH][next] drm/virtio: fix another potential integer overflow on shift of a int
From: Colin Ian King
The left shift of unsigned int 32 bit integer constant 1 is evaluated
using 32 bit arithmetic and then assigned to a signed 64 bit integer.
In the case where value is 32 or more this can lead to an overflow
(value can be in range 0..MAX_CAPSET_ID (63). Fix this by shifting
the value 1ULL instead.
Addresses-Coverity: ("Uninitentional integer overflow")
Fixes: 4fb530e5caf7 ("drm/virtio: implement context init: support init ioctl")
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
index b3b0557d72cf..0007e423d885 100644
--- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
+++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
@@ -774,7 +774,7 @@ static int virtio_gpu_context_init_ioctl(struct drm_device
*dev,
goto out_unlock;
}
- if ((vgdev->capset_id_mask & (1 << value)) == 0) {
+ if ((vgdev->capset_id_mask & (1ULL << value)) == 0) {
ret = -EINVAL;
goto out_unlock;
}
--
2.32.0
Re: [PATCH v2 4/4] drm/v3d: add multiple syncobjs support
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) {
> > + 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) {
> > +
Re: [Intel-gfx] [PATCH] drm/i915: Add ww context to intel_dpt_pin, v2.
Op 29-09-2021 om 16:50 schreef Thomas Hellström (Intel):
>
> On 9/29/21 10:59, Maarten Lankhorst wrote:
>> Ensure i915_vma_pin_iomap and vma_unpin are done with dpt->obj lock held.
>>
>> I don't think there's much of a point in merging intel_dpt_pin() with
>> intel_pin_fb_obj_dpt(), they touch different objects.
>>
>> Changes since v1:
>> - Fix using the wrong pointer to retrieve error code (Julia)
>>
>> Signed-off-by: Maarten Lankhorst
>> Reported-by: kernel test robot
>> Reported-by: Julia Lawall
>
> LGTM.
>
> Reviewed-by: Thomas Hellström
>
>> ---
>> drivers/gpu/drm/i915/display/intel_dpt.c | 40 +++-
>> 1 file changed, 25 insertions(+), 15 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_dpt.c
>> b/drivers/gpu/drm/i915/display/intel_dpt.c
>> index de62bd77b15e..8f7b1f7534a4 100644
>> --- a/drivers/gpu/drm/i915/display/intel_dpt.c
>> +++ b/drivers/gpu/drm/i915/display/intel_dpt.c
>> @@ -121,32 +121,42 @@ struct i915_vma *intel_dpt_pin(struct
>> i915_address_space *vm)
>> intel_wakeref_t wakeref;
>> struct i915_vma *vma;
>> void __iomem *iomem;
>> + struct i915_gem_ww_ctx ww;
>> + int err;
>> wakeref = intel_runtime_pm_get(&i915->runtime_pm);
>> atomic_inc(&i915->gpu_error.pending_fb_pin);
>> - vma = i915_gem_object_ggtt_pin(dpt->obj, NULL, 0, 4096,
>> - HAS_LMEM(i915) ? 0 : PIN_MAPPABLE);
>> - if (IS_ERR(vma))
>> - goto err;
>> + for_i915_gem_ww(&ww, err, true) {
>> + err = i915_gem_object_lock(dpt->obj, &ww);
>> + if (err)
>> + continue;
>> - iomem = i915_vma_pin_iomap(vma);
>> - i915_vma_unpin(vma);
>> - if (IS_ERR(iomem)) {
>> - vma = ERR_CAST(iomem);
>> - goto err;
>> - }
>> + vma = i915_gem_object_ggtt_pin_ww(dpt->obj, &ww, NULL, 0, 4096,
>> + HAS_LMEM(i915) ? 0 : PIN_MAPPABLE);
>> + if (IS_ERR(vma)) {
>> + err = PTR_ERR(vma);
>> + continue;
>> + }
>> +
>> + iomem = i915_vma_pin_iomap(vma);
>> + i915_vma_unpin(vma);
>> - dpt->vma = vma;
>> - dpt->iomem = iomem;
>> + if (IS_ERR(iomem)) {
>> + err = PTR_ERR(iomem);
>> + continue;
>> + }
>> - i915_vma_get(vma);
>> + dpt->vma = vma;
>> + dpt->iomem = iomem;
>> +
>> + i915_vma_get(vma);
>> + }
>> -err:
>> atomic_dec(&i915->gpu_error.pending_fb_pin);
>> intel_runtime_pm_put(&i915->runtime_pm, wakeref);
>> - return vma;
>> + return err ? ERR_PTR(err) : vma;
>> }
>> void intel_dpt_unpin(struct i915_address_space *vm)
Thanks, pushed
Re: [PATCH v2 1/3] drm/i915: rename IS_ACTIVE
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").
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.
BR,
Jani.
> Rename it to something else that would be more
> suitable to include in kconfig.h and shared with other subsystems rather
> than maintaining it only in i915.
>
> Name here is pretty open for suggestions, but I think this is slightly
> better than "active".
>
> Signed-off-by: Lucas De Marchi
> ---
> drivers/gpu/drm/i915/gem/i915_gem_context.c| 2 +-
> drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 +-
> drivers/gpu/drm/i915/gt/intel_engine.h | 4 ++--
> drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c | 2 +-
> drivers/gpu/drm/i915/gt/intel_engine_types.h | 2 +-
> .../gpu/drm/i915/gt/intel_execlists_submission.c | 2 +-
> .../gpu/drm/i915/gt/selftest_engine_heartbeat.c| 4 ++--
> drivers/gpu/drm/i915/gt/selftest_execlists.c | 14 +++---
> drivers/gpu/drm/i915/i915_config.c | 2 +-
> drivers/gpu/drm/i915/i915_request.c| 2 +-
> drivers/gpu/drm/i915/i915_utils.h | 2 +-
> 11 files changed, 19 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> index 8208fd5b72c3..ff748441a0e2 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -761,7 +761,7 @@ static int intel_context_set_gem(struct intel_context *ce,
> intel_engine_has_semaphores(ce->engine))
> __set_bit(CONTEXT_USE_SEMAPHORES, &ce->flags);
>
> - if (IS_ACTIVE(CONFIG_DRM_I915_REQUEST_TIMEOUT) &&
> + if (IS_CONFIG_NONZERO(CONFIG_DRM_I915_REQUEST_TIMEOUT) &&
> ctx->i915->params.request_timeout_ms) {
> unsigned int timeout_ms = ctx->i915->params.request_timeout_ms;
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> index 5130e8ed9564..9e12c026e59f 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> @@ -395,7 +395,7 @@ static vm_fault_t vm_fault_gtt(struct vm_fault *vmf)
> /* Track the mmo associated with the fenced vma */
> vma->mmo = mmo;
>
> - if (IS_ACTIVE(CONFIG_DRM_I915_USERFAULT_AUTOSUSPEND))
> + if (IS_CONFIG_NONZERO(CONFIG_DRM_I915_USERFAULT_AUTOSUSPEND))
> intel_wakeref_auto(&i915->ggtt.userfault_wakeref,
>
> msecs_to_jiffies_timeout(CONFIG_DRM_I915_USERFAULT_AUTOSUSPEND));
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h
> b/drivers/gpu/drm/i915/gt/intel_engine.h
> index 87579affb952..f181c8654cbf 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine.h
> +++ b/drivers/gpu/drm/i915/gt/intel_engine.h
> @@ -273,7 +273,7 @@ static inline bool intel_engine_uses_guc(const struct
> intel_engine_cs *engine)
> static inline bool
> intel_engine_has_preempt_reset(const struct intel_engine_cs *engine)
> {
> - if (!IS_ACTIVE(CONFIG_DRM_I915_PREEMPT_TIMEOUT))
> + if (!IS_CONFIG_NONZERO(CONFIG_DRM_I915_PREEMPT_TIMEOUT))
> return false;
>
> return intel_engine_has_preemption(engine);
> @@ -300,7 +300,7 @@ intel_virtual_engine_has_heartbeat(const struct
> intel_engine_cs *engine)
> static inline bool
> intel_engine_has_heartbeat(const struct intel_engine_cs *engine)
> {
> - if (!IS_ACTIVE(CONFIG_DRM_I915_HEARTBEAT_INTERVAL))
> + if (!IS_CONFIG_NONZERO(CONFIG_DRM_I915_HEARTBEAT_INTERVAL))
> return false;
>
> if (intel_engine_is_virtual(engine))
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> index 74775ae961b2..9b2eb0491c9d 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> @@ -207,7 +207,7 @@ static void heartbeat(struct work_struct *wrk)
>
> void intel_engine_unpark_heartbeat(struct intel_engine_cs *engine)
> {
> - if (!IS_ACTIVE(CONFIG_DRM_I915_HEARTBEAT_INTERVAL))
> + if (!IS_CONFIG_NONZERO(CONFIG_DRM_I915_HEARTBEAT_INTERVAL))
> return;
>
> next_heartbeat(engine);
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
> b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> index 5ae1207c363b..938b49e41e48 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> @@ -556,7 +556,7 @@ intel_engine_has_semaphores(const struct intel_engine_cs
> *engine)
> static
AW: [PATCH] drm/amdgpu: fix some repeated includings
Seconded, there is one include for each hardware version. At least of hand I don't see a duplicate. Von: Simon Ser Gesendet: Donnerstag, 30. September 2021 12:17 An: Guo Zhengkui Cc: Deucher, Alexander ; Koenig, Christian ; 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 ; ker...@vivo.com Betreff: Re: [PATCH] drm/amdgpu: fix some repeated includings One include is v2, the other is v3, or am I missing something?
Re: [Freedreno] [PATCH v2 00/22] drm/msm/dpu: switch dpu_plane to be virtual
Hi, On Thu, 30 Sept 2021 at 05:19, wrote: > > Hi Dmitry > > On 2021-07-04 18:20, Dmitry Baryshkov wrote: > > As discussed on IRC, change dpu_plane implementation to be virtual: > > register unified planes and select backing SSPP block at runtime. > > > > Use msm.dpu_use_virtual_planes=1 to enable usage of virtual planes > > rather than statically allocated SSPPs at the plane registration. > > > > Patches 1-9 move state variables from struct dpu_plane onto the stack > > allocation. State should not be a part of struct dpu_plane anyway. > > > > Patches 10-18 make additional changes to plane code, reworking check, > > debugfs, dropping old multirec support, which results in patch 19 > > adding > > support for virtual planes per se. > > > > Patches 20-22 demonstrate my main goal behind reworking dpu_plane > > support. They change dpu_plane to automatically use one of SSPP block > > features - multirec, an ability to display two unscaled RGB rectangles > > using single SSPP block. This allows us to double the amount of created > > planes. If the user tries to enable more planes than actually supported > > by the underlying SSPP blocks, atomic_check code would return an error. > > > > As you can see, this patchset is not atomic, so different patches can > > go > > separately. > > I am half way through this series and have finished checking patches > 1-12 > I am okay with patches 1-4, 6-12. Its a reasonable cleanup to make the > dpu_plane struct lighter. > I need a little more time with the rest as I am comparing the downstream > solution against yours. > > As you mentioned, this patchset is not atomic, hence can you break it up > like > -> cleanup of dpu_plane struct in one series > -> removal of current multirect and current src split which will include > patch 5 as well > > So that the first series can go through and it gives us a little more > time to check the second > series. Ok, I'll split the series according to your review. > > Thanks > > Abhinav > > > > > Changes since v1: > > - Add multirec implementation > > - Added msm.dpu_use_virtual_planes kernel parameter instead of using > >compile time switch > > - Changed code to always reallocate SSPPs in the CRTC atomic check to > >let the kernel pick up the best multirec config. This can be > >optimized later. > > - Rework RM SSPP API to always receive plane id > > - Removed scaler_cfg, pixel_ext and cdp_cfg from struct > > dpu_plane_state > > - Made _dpu_scaler_setup() call sspp's setup_scaler and setup_pe > > - Removed dpu_csc_cfg from dpu_plane > > > > The following changes since commit > > e88bbc91849b2bf57683119c339e52916d34433f: > > > > Revert "drm/msm/mdp5: provide dynamic bandwidth management" > > (2021-06-23 14:06:20 -0700) > > > > are available in the Git repository at: > > > > https://git.linaro.org/people/dmitry.baryshkov/kernel.git > > dpu-multirec-2 > > > > for you to fetch changes up to > > 19f6afd40097d4c826e56b8f4a8cbd807f7b61f6: > > > > drm/msm/dpu: add multirect support (2021-07-05 04:04:50 +0300) > > > > > > Dmitry Baryshkov (22): > > drm/msm/dpu: move LUT levels out of QOS config > > drm/msm/dpu: remove pipe_qos_cfg from struct dpu_plane > > drm/msm/dpu: drop pipe_name from struct dpu_plane > > drm/msm/dpu: remove stage_cfg from struct dpu_crtc > > drm/msm/dpu: rip out master planes support > > drm/msm/dpu: move dpu_hw_pipe_cfg out of struct dpu_plane > > drm/msm/dpu: drop scaler config from plane state > > drm/msm/dpu: drop dpu_csc_cfg from dpu_plane > > drm/msm/dpu: remove dpu_hw_pipe_cdp_cfg from dpu_plane > > drm/msm/dpu: don't cache pipe->cap->features in dpu_plane > > drm/msm/dpu: don't cache pipe->cap->sblk in dpu_plane > > drm/msm/dpu: rip out debugfs support from dpu_plane > > drm/msm/dpu: drop src_split and multirect check from > > dpu_crtc_atomic_check > > drm/msm/dpu: add list of supported formats to the DPU caps > > drm/msm/dpu: simplify DPU_SSPP features checks > > drm/msm/dpu: do not limit the zpos property > > drm/msm/dpu: add support for SSPP allocation to RM > > drm/msm/dpu: move pipe_hw to dpu_plane_state > > drm/msm/dpu: add support for virtualized planes > > drm/msm/dpu: fix smart dma support > > drm/msm/dpu: fix CDP setup to account for multirect index > > drm/msm/dpu: add multirect support > > > > drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 261 +++- > > drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h | 2 - > > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 20 +- > > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 20 +- > > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c| 41 +- > > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h| 52 +- > > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.c| 2 +- > > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h| 2 +- > > drivers/gpu
Re: [PATCH v8 09/12] media: mtk-vcodec: Get rid of mtk_smi_larb_get/put
On 30.09.21 05:28, Yong Wu wrote:
Hi Dafna,
Thanks very much for the review.
On Wed, 2021-09-29 at 14:13 +0200, Dafna Hirschfeld wrote:
On 29.09.21 03:37, Yong Wu wrote:
MediaTek IOMMU has already added the device_link between the
consumer
and smi-larb device. If the vcodec device call the
pm_runtime_get_sync,
the smi-larb's pm_runtime_get_sync also be called automatically.
CC: Tiffany Lin
CC: Irui Wang
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
Acked-by: Tiffany Lin
Reviewed-by: Dafna Hirschfeld
---
.../platform/mtk-vcodec/mtk_vcodec_dec_pm.c | 37 +++---
--
.../platform/mtk-vcodec/mtk_vcodec_drv.h | 3 --
.../platform/mtk-vcodec/mtk_vcodec_enc.c | 1 -
.../platform/mtk-vcodec/mtk_vcodec_enc_pm.c | 44 +++---
-
4 files changed, 10 insertions(+), 75 deletions(-)
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
index 6038db96f71c..d0bf9aa3b29d 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
@@ -8,14 +8,12 @@
#include
#include
#include
-#include
#include "mtk_vcodec_dec_pm.h"
#include "mtk_vcodec_util.h"
int mtk_vcodec_init_dec_pm(struct mtk_vcodec_dev *mtkdev)
{
- struct device_node *node;
struct platform_device *pdev;
struct mtk_vcodec_pm *pm;
struct mtk_vcodec_clk *dec_clk;
@@ -26,18 +24,7 @@ int mtk_vcodec_init_dec_pm(struct mtk_vcodec_dev
*mtkdev)
pm = &mtkdev->pm;
pm->mtkdev = mtkdev;
dec_clk = &pm->vdec_clk;
- node = of_parse_phandle(pdev->dev.of_node, "mediatek,larb", 0);
- if (!node) {
- mtk_v4l2_err("of_parse_phandle mediatek,larb fail!");
- return -1;
- }
- pdev = of_find_device_by_node(node);
- of_node_put(node);
- if (WARN_ON(!pdev)) {
- return -1;
- }
- pm->larbvdec = &pdev->dev;
pdev = mtkdev->plat_dev;
pm->dev = &pdev->dev;
@@ -47,14 +34,11 @@ int mtk_vcodec_init_dec_pm(struct
mtk_vcodec_dev *mtkdev)
dec_clk->clk_info = devm_kcalloc(&pdev->dev,
dec_clk->clk_num, sizeof(*clk_info),
GFP_KERNEL);
- if (!dec_clk->clk_info) {
- ret = -ENOMEM;
- goto put_device;
- }
+ if (!dec_clk->clk_info)
+ return -ENOMEM;
} else {
mtk_v4l2_err("Failed to get vdec clock count");
- ret = -EINVAL;
- goto put_device;
+ return -EINVAL;
}
for (i = 0; i < dec_clk->clk_num; i++) {
@@ -63,29 +47,24 @@ int mtk_vcodec_init_dec_pm(struct
mtk_vcodec_dev *mtkdev)
"clock-names", i, &clk_info->clk_name);
if (ret) {
mtk_v4l2_err("Failed to get clock name id =
%d", i);
- goto put_device;
+ return ret;
}
clk_info->vcodec_clk = devm_clk_get(&pdev->dev,
clk_info->clk_name);
if (IS_ERR(clk_info->vcodec_clk)) {
mtk_v4l2_err("devm_clk_get (%d)%s fail", i,
clk_info->clk_name);
- ret = PTR_ERR(clk_info->vcodec_clk);
- goto put_device;
+ return PTR_ERR(clk_info->vcodec_clk);
}
}
pm_runtime_enable(&pdev->dev);
return 0;
-put_device:
- put_device(pm->larbvdec);
- return ret;
}
void mtk_vcodec_release_dec_pm(struct mtk_vcodec_dev *dev)
{
pm_runtime_disable(dev->pm.dev);
- put_device(dev->pm.larbvdec);
}
Now that functions only do 'pm_runtime_disable(dev->pm.dev);' so it
will be more
readable to remove the function mtk_vcodec_release_dec_pm
and replace with pm_runtime_disable(dev->pm.dev);
Same for the 'enc' equivalent.
Make sense. But It may be not proper if using pm_runtime_disable
as the symmetry with mtk_vcodec_init_dec_pm in the mtk_vcodec_probe.
Maybe we should move pm_runtime_enable out from mtk_vcodec_init_dec_pm
into mtk_vcodec_probe. I could do a new patch for this. Is this ok for
you?
yes, there is also asymettry when calling pm_runtime* in general,
I see in the decoder it is called from mtk_vcodec_dec_pm.c
but in the encoder it is called from mtk_vcodec_enc.c,
I think all calls to pm_runtime* should be out of the *_pm.c files
since for example 'mtk_vcodec_dec_pw_on' also do just one call to
pm_runtime_resume_and_get so this function can also be removed.
thanks,
Dafna
Thanks,
Dafna
[snip]
___
Linux-mediatek mailing list
linux-media...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
Re: [RFC PATCH v2 1/1] Providers/rxe: Add dma-buf support
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.
Thanks,
Shunsuke
Re: [RFC PATCH v2 1/1] Providers/rxe: Add dma-buf support
2021年9月30日(木) 20:18 Zhu Yanjun :
>
> 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
Ok, I understand that thought. I'll send a patch.
Shunsuke.
[PULL] drm-misc-next
Hi Daniel, Dave,
Here's this week PR for drm-misc-next
Maxime
drm-misc-next-2021-09-30:
drm-misc-next for 5.16:
UAPI Changes:
- virtio: UAPI additions to support context init
Cross-subsystem Changes:
Core Changes:
- bridge: documentation improvements
- mipi-dsi: new devm_mipi_dsi_device_register_full and
devm_mipi_dsi_attach functions
- probe-helper: New HPD helper for devices with per-connector
interrupts
- ttm: ttm_tt improvements, flags documentation improvements
Driver Changes:
- Convertion to devm_arch_phys_wc_add and
devm_arch_io_reserve_memtype_wc
- gma500: Cleanups
- vc4: Fix for hotplug reporting
- virtio: Implement Context Init
- bridge: Suport DP-AUX in ps8640
- panel: Support for Boe TV110C9M-LL3, Innolux HJ110IZ-01A
The following changes since commit 9c2fce137852e6434ca0c6fe3d75e00feb168c07:
drm: Fix scaling_mode docs (2021-09-22 22:11:53 +0300)
are available in the Git repository at:
git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2021-09-30
for you to fetch changes up to 49e7f76fc514cecf2cad1303fa74d99be7e5d9a6:
drm/ttm: add TTM_TT_FLAG_EXTERNAL_MAPPABLE (2021-09-29 16:18:43 +0200)
drm-misc-next for 5.16:
UAPI Changes:
- virtio: UAPI additions to support context init
Cross-subsystem Changes:
Core Changes:
- bridge: documentation improvements
- mipi-dsi: new devm_mipi_dsi_device_register_full and
devm_mipi_dsi_attach functions
- probe-helper: New HPD helper for devices with per-connector
interrupts
- ttm: ttm_tt improvements, flags documentation improvements
Driver Changes:
- Convertion to devm_arch_phys_wc_add and
devm_arch_io_reserve_memtype_wc
- gma500: Cleanups
- vc4: Fix for hotplug reporting
- virtio: Implement Context Init
- bridge: Suport DP-AUX in ps8640
- panel: Support for Boe TV110C9M-LL3, Innolux HJ110IZ-01A
Anthoine Bourgeois (2):
drm/virtio: implement context init: probe for feature
drm/virtio: implement context init: support init ioctl
Christian König (1):
drm/msm: allow compile_test on !ARM
Douglas Anderson (3):
drm/edid: Fix EDID quirk compile error on older compilers
drm/print: Add deprecation notes to DRM_...() functions
drm/edid: Fix drm_edid_encode_panel_id() kerneldoc warning
Gurchetan Singh (10):
virtio-gpu api: multiple context types with explicit initialization
drm/virtgpu api: create context init feature
drm/virtio: implement context init: track valid capabilities in a mask
drm/virtio: implement context init: track {ring_idx, emit_fence_info} in
virtio_gpu_fence
drm/virtio: implement context init: plumb {base_fence_ctx, ring_idx} to
virtio_gpu_fence_alloc
drm/virtio: implement context init: stop using drv->context when creating
fence
drm/virtio: implement context init: allocate an array of fence contexts
drm/virtio: implement context init: handle
VIRTGPU_CONTEXT_PARAM_POLL_RINGS_MASK
drm/virtio: implement context init: add virtio_gpu_fence_event
drm/virtio: implement context init: advertise feature to userspace
Matthew Auld (7):
drm/ttm: stop calling tt_swapin in vm_access
drm/ttm: stop setting page->index for the ttm_tt
drm/ttm: move ttm_tt_{add, clear}_mapping into amdgpu
drm/ttm: remove TTM_PAGE_FLAG_NO_RETRY
drm/ttm: s/FLAG_SG/FLAG_EXTERNAL/
drm/ttm: add some kernel-doc for TTM_TT_FLAG_*
drm/ttm: add TTM_TT_FLAG_EXTERNAL_MAPPABLE
Maxime Ripard (7):
drm/bridge: Add documentation sections
drm/bridge: Document the probe issue with MIPI-DSI bridges
drm/mipi-dsi: Create devm device registration
drm/mipi-dsi: Create devm device attachment
drm/probe-helper: Document drm_helper_hpd_irq_event() return value
drm/probe-helper: Create a HPD IRQ event helper for a single connector
drm/vc4: hdmi: Actually check for the connector status in hotplug
Philip Chen (2):
drm/bridge: parade-ps8640: Use regmap APIs
drm/bridge: parade-ps8640: Add support for AUX channel
Thomas Zimmermann (10):
lib: devres: Add managed arch_phys_wc_add()
lib: devres: Add managed arch_io_reserve_memtype_wc()
drm/ast: Use managed interfaces for framebuffer write combining
drm/mgag200: Use managed interfaces for framebuffer write combining
drm/vboxvideo: Use managed interfaces for framebuffer write combining
drm/gma500: Replace references to dev_private with helper function
drm/gma500: Disable PCI device during shutdown
drm/gma500: Embed struct drm_device in struct drm_psb_private
drm/gma500: Remove dev_priv branch from unload function
drm/gma500: Managed device release
Yang Yingliang (1):
drm/gma500: Fix wrong pointer passed to PTR_ERR()
yangcong (4):
dt-bindings: drm/panel: boe-tv101wum-nl6: Support
Re: [PATCH] dma-buf: fix and rework dma_buf_poll v7
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. 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
[PATCH v3] drm/i915/ttm: Rework object initialization slightly
We may end up in i915_ttm_bo_destroy() in an error path before the
object is fully initialized. In that case it's not correct to call
__i915_gem_free_object(), because that function
a) Assumes the gem object refcount is 0, which it isn't.
b) frees the placements which are owned by the caller until the
init_object() region ops returns successfully. Fix this by providing
a lightweight cleanup function __i915_gem_object_fini() which is also
called by __i915_gem_free_object().
While doing this, also make sure we call dma_resv_fini() as part of
ordinary object destruction and not from the RCU callback that frees
the object. This will help track down bugs where the object is incorrectly
locked from an RCU lookup.
Finally, make sure the object isn't put on the region list until it's
either locked or fully initialized in order to block list processing of
partially initialized objects.
v2:
- The TTM object backend memory was freed before the gem pages were
put. Separate this functionality into __i915_gem_object_pages_fini()
and call it from the TTM delete_mem_notify() callback.
v3:
- Include i915_gem_object_free_mmaps() in __i915_gem_object_pages_fini()
to make sure we don't inadvertedly introduce a race.
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld #v1
---
drivers/gpu/drm/i915/gem/i915_gem_object.c | 43 +++---
drivers/gpu/drm/i915/gem/i915_gem_object.h | 5 +++
drivers/gpu/drm/i915/gem/i915_gem_ttm.c| 36 +++---
3 files changed, 64 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 6fb9afb65034..b88b121e244a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -89,6 +89,22 @@ void i915_gem_object_init(struct drm_i915_gem_object *obj,
mutex_init(&obj->mm.get_dma_page.lock);
}
+/**
+ * i915_gem_object_fini - Clean up a GEM object initialization
+ * @obj: The gem object to cleanup
+ *
+ * This function cleans up gem object fields that are set up by
+ * drm_gem_private_object_init() and i915_gem_object_init().
+ * It's primarily intended as a helper for backends that need to
+ * clean up the gem object in separate steps.
+ */
+void __i915_gem_object_fini(struct drm_i915_gem_object *obj)
+{
+ mutex_destroy(&obj->mm.get_page.lock);
+ mutex_destroy(&obj->mm.get_dma_page.lock);
+ dma_resv_fini(&obj->base._resv);
+}
+
/**
* Mark up the object's coherency levels for a given cache_level
* @obj: #drm_i915_gem_object
@@ -174,7 +190,6 @@ void __i915_gem_free_object_rcu(struct rcu_head *head)
container_of(head, typeof(*obj), rcu);
struct drm_i915_private *i915 = to_i915(obj->base.dev);
- dma_resv_fini(&obj->base._resv);
i915_gem_object_free(obj);
GEM_BUG_ON(!atomic_read(&i915->mm.free_count));
@@ -204,10 +219,17 @@ static void __i915_gem_object_free_mmaps(struct
drm_i915_gem_object *obj)
}
}
-void __i915_gem_free_object(struct drm_i915_gem_object *obj)
+/**
+ * __i915_gem_object_pages_fini - Clean up pages use of a gem object
+ * @obj: The gem object to clean up
+ *
+ * This function cleans up usage of the object mm.pages member. It
+ * is intended for backends that need to clean up a gem object in
+ * separate steps and needs to be called when the object is idle before
+ * the object's backing memory is freed.
+ */
+void __i915_gem_object_pages_fini(struct drm_i915_gem_object *obj)
{
- trace_i915_gem_object_destroy(obj);
-
if (!list_empty(&obj->vma.list)) {
struct i915_vma *vma;
@@ -233,11 +255,17 @@ void __i915_gem_free_object(struct drm_i915_gem_object
*obj)
__i915_gem_object_free_mmaps(obj);
- GEM_BUG_ON(!list_empty(&obj->lut_list));
-
atomic_set(&obj->mm.pages_pin_count, 0);
__i915_gem_object_put_pages(obj);
GEM_BUG_ON(i915_gem_object_has_pages(obj));
+}
+
+void __i915_gem_free_object(struct drm_i915_gem_object *obj)
+{
+ trace_i915_gem_object_destroy(obj);
+
+ GEM_BUG_ON(!list_empty(&obj->lut_list));
+
bitmap_free(obj->bit_17);
if (obj->base.import_attach)
@@ -253,6 +281,8 @@ void __i915_gem_free_object(struct drm_i915_gem_object *obj)
if (obj->shares_resv_from)
i915_vm_resv_put(obj->shares_resv_from);
+
+ __i915_gem_object_fini(obj);
}
static void __i915_gem_free_objects(struct drm_i915_private *i915,
@@ -266,6 +296,7 @@ static void __i915_gem_free_objects(struct drm_i915_private
*i915,
obj->ops->delayed_free(obj);
continue;
}
+ __i915_gem_object_pages_fini(obj);
__i915_gem_free_object(obj);
/* But keep the pointer alive for RCU-protected lookups */
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index 3043fcbd31bd..7f9f2e5b
RE: [PATCH] drm/amdgpu: fix some repeated includings
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] 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 v1 2/4] arm64: dts: qcom: sc7280: add display dt nodes
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
@@ -5,6 +5,7 @@
* Copyright (c) 2020-2021, The Linux Foundation. All rights
reserved.
*/
+#include
#include
#include
#include
@@ -1424,6 +1425,90 @@
#power-domain-cells = <1>;
};
+ mdss: mdss@ae0 {
subsystem@ae0
+ compatible = "qcom,sc7280-mdss";
+ reg = <0 0x0ae0 0 0x1000>;
+ reg-names = "mdss";
+
+ power-domains = <&dispcc
DISP_CC_MDSS_CORE_GDSC>;
+
+ clocks = <&gcc GCC_DISP_AHB_CLK>,
+<&dispcc DISP_CC_MDSS_AHB_CLK>,
+ <&dispcc DISP_CC_MDSS_MDP_CLK>;
+ clock-names = "iface", "ahb", "core";
+
+ assigned-clocks = <&dispcc
DISP_CC_MDSS_MDP_CLK>;
+ assigned-clock-rates = <3>;
+
+ interrupts = ;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ interconnects = <&mmss_noc MASTER_MDP0 0
&mc_virt SLAVE_EBI1 0>;
+ interconnect-names = "mdp0-mem";
+
+ iommus = <&apps_smmu 0x900 0x402>;
+
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ 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?
Thanks,
Krishna
+ compatible = "qcom,sc7280-dpu";
+ reg = <0 0x0ae01000 0 0x8f030>,
+ <0 0x0aeb 0 0x2008>;
+ reg-names = "mdp", "vbif";
+
+ clocks = <&gcc GCC_DISP_HF_AXI_CLK>,
+ <&gcc GCC_DISP_SF_AXI_CLK>,
+ <&dispcc
DISP_CC_MDSS_AHB_CLK>,
+ <&dispcc
DISP_CC_MDSS_MDP_LUT_CLK>,
+ <&dispcc
DISP_CC_MDSS_MDP_CLK>,
+ <&dispcc
DISP_CC_MDSS_VSYNC_CLK>;
+ clock-names = "bus", "nrt_bus",
"iface", "lut", "core",
+ "vsync";
One line per string please.
+ assigned-clocks = <&dispcc
DISP_CC_MDSS_MDP_CLK>,
+ <&dispcc
DISP_CC_MDSS_VSYNC_CLK>,
+ <&dispcc
DISP_CC_MDSS_AHB_CLK>;
+ assigned-clock-rates = <3>,
+ <1920>,
+ <1920>;
+ operating-points-v2 =
<&mdp_opp_table>;
+ power-domains = <&rpmhpd SC7280_CX>;
+
+ interrupt-parent = <&mdss>;
+ interrupts = <0>;
+
+ status = "disabled";
+
+ mdp_opp_table: mdp-opp-table {
mdp_opp_table: opp-table {
+ compatible =
"operating-points-v2";
+
+ opp-2 {
+ opp-hz = /bits/ 64
<2>;
+ required-opps =
<&rpmhpd_opp_low_svs>;
+ };
+
+ opp-3 {
+ opp-hz = /bits/ 64
<3>;
+ required-opps =
<&rpmhpd_opp_svs>;
+ };
+
+ opp-38000 {
+ opp-hz = /bits/ 64
<38000>;
+ required-opps =
<&rpmhpd_opp_svs_l1>;
+ };
+
+ opp-50667 {
+ opp-hz = /bits/ 64
<50667>;
+ required-opps =
<&rpmhpd_opp_nom>;
+
Re: [PATCH v5 12/13] drm/i915/ttm: use cached system pages when evicting lmem
On 30/09/2021 11:04, Michel Dänzer wrote:
On 2021-09-29 13:54, Thomas Hellström wrote:
On Mon, 2021-09-27 at 12:41 +0100, Matthew Auld wrote:
This should let us do an accelerated copy directly to the shmem pages
when temporarily moving lmem-only objects, where the i915-gem
shrinker
can later kick in to swap out the pages, if needed.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 194e5f1deda8..46d57541c0b2 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -134,11 +134,11 @@ static enum ttm_caching
i915_ttm_select_tt_caching(const struct drm_i915_gem_object *obj)
{
/*
- * Objects only allowed in system get cached cpu-mappings.
- * Other objects get WC mapping for now. Even if in system.
+ * Objects only allowed in system get cached cpu-mappings, or
when
+ * evicting lmem-only buffers to system for swapping. Other
objects get
+ * WC mapping for now. Even if in system.
*/
- if (obj->mm.region->type == INTEL_MEMORY_SYSTEM &&
- obj->mm.n_placements <= 1)
+ if (obj->mm.n_placements <= 1)
return ttm_cached;
return ttm_write_combined;
We should be aware that with TTM, even evicted bos can be mapped by
user-space while evicted, and this will appear to user-space like the
WC-mapped object suddenly became WB-mapped. But it appears like mesa
doesn't care about this as long as the mappings are fully coherent.
FWIW, the Mesa radeonsi driver avoids surprises due to this (e.g. some path
which involves CPU access suddenly goes faster if the BO was evicted from VRAM)
by asking for WC mapping of BOs intended to be in VRAM even while they're
evicted (via the AMDGPU_GEM_CREATE_CPU_GTT_USWC flag).
Ok, so amdgpu just defaults to cached system memory, even for evicted
VRAM, unless userspace requests USWC, in which case it will use WC?
Re: [PATCH v6 2/2] habanalabs: add support for dma-buf exporter
On Wed, Sep 29, 2021 at 12:17 AM Oded Gabbay wrote:
>
> On Tue, Sep 28, 2021 at 8:36 PM Jason Gunthorpe wrote:
> >
> > On Sun, Sep 12, 2021 at 07:53:09PM +0300, Oded Gabbay wrote:
> > > From: Tomer Tayar
> > >
> > > Implement the calls to the dma-buf kernel api to create a dma-buf
> > > object backed by FD.
> > >
> > > We block the option to mmap the DMA-BUF object because we don't support
> > > DIRECT_IO and implicit P2P.
> >
> > This statement doesn't make sense, you can mmap your dmabuf if you
> > like. All dmabuf mmaps are supposed to set the special bit/etc to
> > exclude them from get_user_pages() anyhow - and since this is BAR
> > memory not struct page memory this driver would be doing it anyhow.
> >
> But we block mmap the dmabuf fd from user-space.
> If you try to do it, you will get MAP_FAILED.
> That's because we don't supply a function to the mmap callback in dmabuf.
> We did that per Christian's advice. It is in one of the long email
> threads on previous versions of this patch.
>
>
> > > We check the p2p distance using pci_p2pdma_distance_many() and refusing
> > > to map dmabuf in case the distance doesn't allow p2p.
> >
> > Does this actually allow the p2p transfer for your intended use cases?
> >
> It depends on the system. If we are working bare-metal, then yes, it allows.
> If inside a VM, then no. The virtualized root complex is not
> white-listed and the kernel can't know the distance.
> But I remember you asked me to add this check, in v3 of the review IIRC.
> I don't mind removing this check if you don't object.
>
> > > diff --git a/drivers/misc/habanalabs/common/memory.c
> > > b/drivers/misc/habanalabs/common/memory.c
> > > index 33986933aa9e..8cf5437c0390 100644
> > > +++ b/drivers/misc/habanalabs/common/memory.c
> > > @@ -1,7 +1,7 @@
> > > // SPDX-License-Identifier: GPL-2.0
> > >
> > > /*
> > > - * Copyright 2016-2019 HabanaLabs, Ltd.
> > > + * Copyright 2016-2021 HabanaLabs, Ltd.
> > > * All Rights Reserved.
> > > */
> > >
> > > @@ -11,11 +11,13 @@
> > >
> > > #include
> > > #include
> > > +#include
> > >
> > > #define HL_MMU_DEBUG 0
> > >
> > > /* use small pages for supporting non-pow2 (32M/40M/48M) DRAM phys page
> > > sizes */
> > > -#define DRAM_POOL_PAGE_SIZE SZ_8M
> > > +#define DRAM_POOL_PAGE_SIZE SZ_8M
> > > +
> >
> > ??
> ok, I 'll remove
> >
> > > /*
> > > * The va ranges in context object contain a list with the available
> > > chunks of
> > > @@ -347,6 +349,13 @@ static int free_device_memory(struct hl_ctx *ctx,
> > > struct hl_mem_in *args)
> > > return -EINVAL;
> > > }
> > >
> > > + if (phys_pg_pack->exporting_cnt) {
> > > + dev_err(hdev->dev,
> > > + "handle %u is exported, cannot free\n",
> > > handle);
> > > + spin_unlock(&vm->idr_lock);
> >
> > Don't write to the kernel log from user space triggered actions
> at all ?
> It's the first time I hear about this limitation...
> How do you tell the user it has done something wrong ?
> I agree it might be better to rate limit it, but why not give the
> information to the user ?
>
> >
> > > +static int alloc_sgt_from_device_pages(struct hl_device *hdev,
> > > + struct sg_table **sgt, u64 *pages,
> > > + u64 npages, u64 page_size,
> > > + struct device *dev,
> > > + enum dma_data_direction dir)
> >
> > Why doesn't this return a sg_table * and an ERR_PTR?
> Basically I modeled this function after amdgpu_vram_mgr_alloc_sgt()
> And in that function they also return int and pass the sg_table as **
>
> If it's critical I can change.
>
> >
> > > +{
> > > + u64 chunk_size, bar_address, dma_max_seg_size;
> > > + struct asic_fixed_properties *prop;
> > > + int rc, i, j, nents, cur_page;
> > > + struct scatterlist *sg;
> > > +
> > > + prop = &hdev->asic_prop;
> > > +
> > > + dma_max_seg_size = dma_get_max_seg_size(dev);
> >
> > > +
> > > + /* We would like to align the max segment size to PAGE_SIZE, so the
> > > + * SGL will contain aligned addresses that can be easily mapped to
> > > + * an MMU
> > > + */
> > > + dma_max_seg_size = ALIGN_DOWN(dma_max_seg_size, PAGE_SIZE);
> > > + if (dma_max_seg_size < PAGE_SIZE) {
> > > + dev_err_ratelimited(hdev->dev,
> > > + "dma_max_seg_size %llu can't be smaller
> > > than PAGE_SIZE\n",
> > > + dma_max_seg_size);
> > > + return -EINVAL;
> > > + }
> > > +
> > > + *sgt = kzalloc(sizeof(**sgt), GFP_KERNEL);
> > > + if (!*sgt)
> > > + return -ENOMEM;
> > > +
> > > + /* If the size of each page is larger than the dma max segment size,
> > > + * then we can't combine pages and the number of entries in the SGL
> > > + * will just be the
> > >
Re: [PATCH v5 12/13] drm/i915/ttm: use cached system pages when evicting lmem
On 2021-09-30 14:27, Matthew Auld wrote:
> On 30/09/2021 11:04, Michel Dänzer wrote:
>> On 2021-09-29 13:54, Thomas Hellström wrote:
>>> On Mon, 2021-09-27 at 12:41 +0100, Matthew Auld wrote:
This should let us do an accelerated copy directly to the shmem pages
when temporarily moving lmem-only objects, where the i915-gem
shrinker
can later kick in to swap out the pages, if needed.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 194e5f1deda8..46d57541c0b2 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -134,11 +134,11 @@ static enum ttm_caching
i915_ttm_select_tt_caching(const struct drm_i915_gem_object *obj)
{
/*
- * Objects only allowed in system get cached cpu-mappings.
- * Other objects get WC mapping for now. Even if in system.
+ * Objects only allowed in system get cached cpu-mappings, or
when
+ * evicting lmem-only buffers to system for swapping. Other
objects get
+ * WC mapping for now. Even if in system.
*/
- if (obj->mm.region->type == INTEL_MEMORY_SYSTEM &&
- obj->mm.n_placements <= 1)
+ if (obj->mm.n_placements <= 1)
return ttm_cached;
return ttm_write_combined;
>>>
>>> We should be aware that with TTM, even evicted bos can be mapped by
>>> user-space while evicted, and this will appear to user-space like the
>>> WC-mapped object suddenly became WB-mapped. But it appears like mesa
>>> doesn't care about this as long as the mappings are fully coherent.
>>
>> FWIW, the Mesa radeonsi driver avoids surprises due to this (e.g. some path
>> which involves CPU access suddenly goes faster if the BO was evicted from
>> VRAM) by asking for WC mapping of BOs intended to be in VRAM even while
>> they're evicted (via the AMDGPU_GEM_CREATE_CPU_GTT_USWC flag).
>>
>
> Ok, so amdgpu just defaults to cached system memory, even for evicted VRAM,
> unless userspace requests USWC, in which case it will use WC?
Right.
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
Repository for additional color and HDR related documentation (Re: [RFC PATCH v3 1/6] drm/doc: Color Management and HDR10 RFC)
On Thu, 23 Sep 2021 10:43:54 +0300 Pekka Paalanen wrote: > On Wed, 22 Sep 2021 11:28:37 -0400 > Harry Wentland wrote: > > > On 2021-09-22 04:31, Pekka Paalanen wrote: > > > On Tue, 21 Sep 2021 14:05:05 -0400 > > > Harry Wentland wrote: > > > > > >> On 2021-09-21 09:31, Pekka Paalanen wrote: > > >>> On Mon, 20 Sep 2021 20:14:50 -0400 > > >>> Harry Wentland wrote: > > >>> > > > > ... > > > > > > > >> Did anybody start any CM doc patches in Weston or Wayland yet? > > > > > > There is the > > > https://gitlab.freedesktop.org/swick/wayland-protocols/-/blob/color/unstable/color-management/color.rst > > > we started a long time ago, and have not really touched it for a while. > > > Since we last touched it, at least my understanding has developed > > > somewhat. > > > > > > It is linked from the overview in > > > https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/14 > > > and if you want to propose changes, the way to do it is file a MR in > > > https://gitlab.freedesktop.org/swick/wayland-protocols/-/merge_requests > > > against the 'color' branch. Patches very much welcome, that doc does > > > not need to limit itself to Wayland. :-) > > > > > > > Right, I've read all that a while back. > > > > It might be a good place to consolidate most of the Linux CM/HDR discussion, > > since gitlab is good with allowing discussions, we can track changes, and > > it's more formatting and diagram friendly than text-only email. > > Fine by me, but the way things are right now, we'd be hijacking > Sebastian's personal repository for these things. That's not ideal. > > We can't merge the protocol XML into wayland-protocols until it has the > accepted implementations required by the governance rules, but I wonder > if we could land color.rst ahead of time, then work on that in > wayland-protocols upstream repo. > > It's hard to pick a good place for a cross-project document. Any other > ideas? > > > > We also have issues tracked at > > > https://gitlab.freedesktop.org/swick/wayland-protocols/-/issues?scope=all&utf8=%E2%9C%93&state=opened > > > Hi all, we discussed things in https://gitlab.freedesktop.org/swick/wayland-protocols/-/issues/6 and we have a new home for the color related WIP documentation we can use across Wayland, Mesa, DRM, and even X11 if people want to: https://gitlab.freedesktop.org/pq/color-and-hdr Yes, it's still someone's personal repository, but we avoid entangling it with wayland-protocols which also means we can keep the full git history. If this gets enough traction, the repository can be moved from under my personal group to somewhere more communal, and if that is still inside gitlab.fd.o then all merge requests and issues will move with it. The README notes that we will deal out merge permissions as well. This is not meant to supersede the documentation of individual APIs, but to host additional documentation that would be too verbose, too big, or out of scope to host within respective API docs. Feel free to join the effort or just to discuss. Thanks, pq pgpuN8ns33YQU.pgp Description: OpenPGP digital signature
Re: [v2 PATCH 1/3] drm/mediatek: Fix crash at using pkt->cl->chan in cmdq_pkt_finalize
Hi, Enric:
Enric Balletbo Serra 於 2021年9月30日 週四 下午3:12寫道：
>
> Hi Jason,
>
>
> Missatge de jason-jh.lin del dia dj., 30
> de set. 2021 a les 4:47:
> >
> > Because mtk_drm_crtc_create_pkt didn't assign pkt->cl, it will
> > crash at using pkt->cl->chan in cmdq_pkt_finalize.
> >
> > So add struct cmdq_client and let mtk_drm_crtc instance define
> > cmdq_client as:
> >
> > struct mtk_drm_crtc {
> > /* client instance data */
> > struct cmdq_client cmdq_client;
> > };
> >
> > and in rx_callback function can use pkt->cl to get
> > struct cmdq_client.
> >
> > Fixes: f4be17cd5b14 ("drm/mediatek: Remove struct cmdq_client")
>
> Looking at this patchset looks like you're fixing the above commit by
> reintroducing the 'struct cmdq_client' again, which makes the above
> commit as a non-sense commit. That's confusing and not clear. I'm
> wondering if it wouldn't be more clear if you can just revert that
> patch. Then if there are more changes that need to be done do it with
> a follow up patch and really explain why these changes are needed.
The patch f4be17cd5b14 ("drm/mediatek: Remove struct cmdq_client")
does two things. One is to remove struct cmdq_client, another one is
to embed cmdq_cl
in mtk_drm_crtc (This means the pointer of cmdq_cl could be used to
find the pointer of mtk_drm_crtc). The correct way to fix that patch
is to remove the access to cmdq_client in cmdq_pkt_finalize(), but
that would be a long term process. The simple way is to revert that
patch, but the other patches depend on embedding cmdq_cl in
mtk_drm_crtc. So this patch just revert the removing of struct
cmdq_client but keep embedding cmdq_cl in mtk_drm_crtc.
Regards,
Chun-Kuang.
>
> Thanks,
> Enric
>
>
> > Signed-off-by: jason-jh.lin
> > ---
> > drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 73 +
> > 1 file changed, 38 insertions(+), 35 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > index 5f81489fc60c..411d99fcbb8f 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > @@ -52,8 +52,7 @@ struct mtk_drm_crtc {
> > boolpending_async_planes;
> >
> > #if IS_REACHABLE(CONFIG_MTK_CMDQ)
> > - struct mbox_client cmdq_cl;
> > - struct mbox_chan*cmdq_chan;
> > + struct cmdq_client cmdq_client;
> > struct cmdq_pkt cmdq_handle;
> > u32 cmdq_event;
> > u32 cmdq_vblank_cnt;
> > @@ -227,8 +226,8 @@ struct mtk_ddp_comp *mtk_drm_ddp_comp_for_plane(struct
> > drm_crtc *crtc,
> > }
> >
> > #if IS_REACHABLE(CONFIG_MTK_CMDQ)
> > -static int mtk_drm_cmdq_pkt_create(struct mbox_chan *chan, struct cmdq_pkt
> > *pkt,
> > - size_t size)
> > +static int mtk_drm_cmdq_pkt_create(struct cmdq_client *client, struct
> > cmdq_pkt *pkt,
> > + size_t size)
> > {
> > struct device *dev;
> > dma_addr_t dma_addr;
> > @@ -239,8 +238,9 @@ static int mtk_drm_cmdq_pkt_create(struct mbox_chan
> > *chan, struct cmdq_pkt *pkt,
> > return -ENOMEM;
> > }
> > pkt->buf_size = size;
> > + pkt->cl = (void *)client;
> >
> > - dev = chan->mbox->dev;
> > + dev = client->chan->mbox->dev;
> > dma_addr = dma_map_single(dev, pkt->va_base, pkt->buf_size,
> > DMA_TO_DEVICE);
> > if (dma_mapping_error(dev, dma_addr)) {
> > @@ -255,9 +255,11 @@ static int mtk_drm_cmdq_pkt_create(struct mbox_chan
> > *chan, struct cmdq_pkt *pkt,
> > return 0;
> > }
> >
> > -static void mtk_drm_cmdq_pkt_destroy(struct mbox_chan *chan, struct
> > cmdq_pkt *pkt)
> > +static void mtk_drm_cmdq_pkt_destroy(struct cmdq_pkt *pkt)
> > {
> > - dma_unmap_single(chan->mbox->dev, pkt->pa_base, pkt->buf_size,
> > + struct cmdq_client *client = (struct cmdq_client *)pkt->cl;
> > +
> > + dma_unmap_single(client->chan->mbox->dev, pkt->pa_base,
> > pkt->buf_size,
> > DMA_TO_DEVICE);
> > kfree(pkt->va_base);
> > kfree(pkt);
> > @@ -265,8 +267,9 @@ static void mtk_drm_cmdq_pkt_destroy(struct mbox_chan
> > *chan, struct cmdq_pkt *pk
> >
> > static void ddp_cmdq_cb(struct mbox_client *cl, void *mssg)
> > {
> > - struct mtk_drm_crtc *mtk_crtc = container_of(cl, struct
> > mtk_drm_crtc, cmdq_cl);
> > struct cmdq_cb_data *data = mssg;
> > + struct cmdq_client *cmdq_cl = container_of(cl, struct cmdq_client,
> > client);
> > + struct mtk_drm_crtc *mtk_crtc = container_of(cmdq_cl, struct
> > mtk_drm_crtc, cmdq_client);
> > struct mtk_crtc_state *state;
> > unsigned int i;
> >
> > @@ -299,7 +302,7 @@ static void ddp_cmdq_cb(struct mbox_client *cl, void
> > *mssg)
> > }
> >
Re: [v2 PATCH 3/3] drm/mediatek: Fix cursor plane is not config when primary is updating
Hi, Jason:
jason-jh.lin 於 2021年9月30日 週四 上午10:47寫道：
>
> If cursor plane has updated but primary plane config task is not
> finished, mtk_drm_crtc_update_config will call mbox_flush() to clear
> all task in current GCE thread and let cursor plane re-send a new
> GCE task with cursor + primary plane config to replace the unfinished
> GCE task.
>
> So the plane config flag should not be cleared when mailbox callback
> with a error status.
Reviewed-by: Chun-Kuang Hu
>
> Fixes: 9efb16c2fdd6 ("drm/mediatek: Clear pending flag when cmdq packet is
> done")
> Signed-off-by: jason-jh.lin
> ---
> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> index 274e5c67507d..b96dbc867890 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> @@ -281,6 +281,9 @@ static void ddp_cmdq_cb(struct mbox_client *cl, void
> *mssg)
> struct mtk_crtc_state *state;
> unsigned int i;
>
> + if (data->sta < 0)
> + return;
> +
> state = to_mtk_crtc_state(mtk_crtc->base.state);
>
> state->pending_config = false;
> --
> 2.18.0
>
[PATCH v2, 0/1] mailbox: cmdq: add instruction time-out interrupt support
Base v5.15 Yongqiang Niu (1): mailbox: cmdq: add instruction time-out interrupt support drivers/mailbox/mtk-cmdq-mailbox.c | 11 +++ 1 file changed, 11 insertions(+) -- 2.25.1
[PATCH v2, 1/1] mailbox: cmdq: add instruction time-out interrupt support
add time-out cycle setting to make sure time-out interrupt irq
will happened when instruction time-out for wait and poll
Signed-off-by: Yongqiang Niu
---
drivers/mailbox/mtk-cmdq-mailbox.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/mailbox/mtk-cmdq-mailbox.c
b/drivers/mailbox/mtk-cmdq-mailbox.c
index 64175a893312..197b03222f94 100644
--- a/drivers/mailbox/mtk-cmdq-mailbox.c
+++ b/drivers/mailbox/mtk-cmdq-mailbox.c
@@ -36,6 +36,7 @@
#define CMDQ_THR_END_ADDR 0x24
#define CMDQ_THR_WAIT_TOKEN0x30
#define CMDQ_THR_PRIORITY 0x40
+#define CMDQ_THR_INSTN_TIMEOUT_CYCLES 0x50
#define GCE_GCTL_VALUE 0x48
@@ -54,6 +55,15 @@
#define CMDQ_JUMP_BY_OFFSET0x1000
#define CMDQ_JUMP_BY_PA0x1001
+/*
+ * instruction time-out
+ * cycles to issue instruction time-out interrupt for wait and poll
instructions
+ * GCE axi_clock 156MHz
+ * 1 cycle = 6.41ns
+ * instruction time out 2^22*2*6.41ns = 53ms
+ */
+#define CMDQ_INSTN_TIMEOUT_CYCLES 22
+
struct cmdq_thread {
struct mbox_chan*chan;
void __iomem*base;
@@ -376,6 +386,7 @@ static int cmdq_mbox_send_data(struct mbox_chan *chan, void
*data)
writel((task->pa_base + pkt->cmd_buf_size) >> cmdq->shift_pa,
thread->base + CMDQ_THR_END_ADDR);
+ writel(CMDQ_INSTN_TIMEOUT_CYCLES, thread->base +
CMDQ_THR_INSTN_TIMEOUT_CYCLES);
writel(thread->priority, thread->base + CMDQ_THR_PRIORITY);
writel(CMDQ_THR_IRQ_EN, thread->base + CMDQ_THR_IRQ_ENABLE);
writel(CMDQ_THR_ENABLED, thread->base + CMDQ_THR_ENABLE_TASK);
--
2.25.1
Re: [PATCH v1 4/4] drm/mediatek: add mt8195 hdmi TX support
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 >
[PATCH v3] drm/i915/bdb: Fix version check
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)
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];
--
2.33.0.685.g46640cef36-goog
Re: [v2 PATCH 1/3] drm/mediatek: Fix crash at using pkt->cl->chan in cmdq_pkt_finalize
Hi Chun-Kuang,
Missatge de Chun-Kuang Hu del dia dj., 30 de
set. 2021 a les 15:11:
>
> Hi, Enric:
>
> Enric Balletbo Serra 於 2021年9月30日 週四 下午3:12寫道：
> >
> > Hi Jason,
> >
> >
> > Missatge de jason-jh.lin del dia dj., 30
> > de set. 2021 a les 4:47:
> > >
> > > Because mtk_drm_crtc_create_pkt didn't assign pkt->cl, it will
> > > crash at using pkt->cl->chan in cmdq_pkt_finalize.
> > >
> > > So add struct cmdq_client and let mtk_drm_crtc instance define
> > > cmdq_client as:
> > >
> > > struct mtk_drm_crtc {
> > > /* client instance data */
> > > struct cmdq_client cmdq_client;
> > > };
> > >
> > > and in rx_callback function can use pkt->cl to get
> > > struct cmdq_client.
> > >
> > > Fixes: f4be17cd5b14 ("drm/mediatek: Remove struct cmdq_client")
> >
> > Looking at this patchset looks like you're fixing the above commit by
> > reintroducing the 'struct cmdq_client' again, which makes the above
> > commit as a non-sense commit. That's confusing and not clear. I'm
> > wondering if it wouldn't be more clear if you can just revert that
> > patch. Then if there are more changes that need to be done do it with
> > a follow up patch and really explain why these changes are needed.
>
> The patch f4be17cd5b14 ("drm/mediatek: Remove struct cmdq_client")
> does two things. One is to remove struct cmdq_client, another one is
> to embed cmdq_cl
Then it should have been two patches, one thing for patch really
helps, specially when something breaks and you try to bisect it.
> in mtk_drm_crtc (This means the pointer of cmdq_cl could be used to
> find the pointer of mtk_drm_crtc). The correct way to fix that patch
> is to remove the access to cmdq_client in cmdq_pkt_finalize(), but
> that would be a long term process. The simple way is to revert that
> patch, but the other patches depend on embedding cmdq_cl in
> mtk_drm_crtc. So this patch just revert the removing of struct
> cmdq_client but keep embedding cmdq_cl in mtk_drm_crtc.
>
Yes, I know and I suffered that when bisecting and I ended to revert
the full series in my local tree, although I figured out that the
problem was this specific patch.
The following series landed during -rc1 cycle and break the Acer Chromebook R13
9efb16c2fdd6 ("drm/mediatek: Clear pending flag when cmdq packet is done")
bc9241be73d9 ("drm/mediatek: Add cmdq_handle in mtk_crtc")
8cdcb3653424 ("drm/mediatek: Detect CMDQ execution timeout")
f4be17cd5b14 ("drm/mediatek: Remove struct cmdq_client")
c1ec54b7b5af ("drm/mediatek: Use mailbox rx_callback instead of cmdq_task_cb")
Apart from that it was a pain bisecting and introduced different
behaviours between patches, all the above commits have a follow-up
patch (see [1] and [2]) as a fix for the landed series. That makes me
think that were no stable enough. As we're in the rc, and as you said
this is not the correct way to fix it, and the landed patches seems
more a cleanup that really solving a real problem I'd consider to just
revert the full series and resubmit again for next release with these
fixes squashed. IMO that will also help to no miss anything when
someone would backport all this to the stable versions and understand
better the history.
Just my 5 cents. In any case, I can confirm that applying the full
series solves the current problems that I have with my Acer Chromebook
R13.
Thanks,
Enric
[1] https://patchwork.kernel.org/project/linux-mediatek/list/?series=555383
[2] https://patchwork.kernel.org/project/linux-mediatek/list/?series=554767
> Regards,
> Chun-Kuang.
>
> >
> > Thanks,
> > Enric
> >
> >
> > > Signed-off-by: jason-jh.lin
> > > ---
> > > drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 73 +
> > > 1 file changed, 38 insertions(+), 35 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > > b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > > index 5f81489fc60c..411d99fcbb8f 100644
> > > --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > > +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > > @@ -52,8 +52,7 @@ struct mtk_drm_crtc {
> > > boolpending_async_planes;
> > >
> > > #if IS_REACHABLE(CONFIG_MTK_CMDQ)
> > > - struct mbox_client cmdq_cl;
> > > - struct mbox_chan*cmdq_chan;
> > > + struct cmdq_client cmdq_client;
> > > struct cmdq_pkt cmdq_handle;
> > > u32 cmdq_event;
> > > u32 cmdq_vblank_cnt;
> > > @@ -227,8 +226,8 @@ struct mtk_ddp_comp
> > > *mtk_drm_ddp_comp_for_plane(struct drm_crtc *crtc,
> > > }
> > >
> > > #if IS_REACHABLE(CONFIG_MTK_CMDQ)
> > > -static int mtk_drm_cmdq_pkt_create(struct mbox_chan *chan, struct
> > > cmdq_pkt *pkt,
> > > - size_t size)
> > > +static int mtk_drm_cmdq_pkt_create(struct cmdq_client *client, struct
> > > cmdq_pkt *pkt,
> > > + size_t size)
>
[PATCH v9, 1/2] soc: mediatek: mmsys: add comp OVL_2L2/POSTMASK/RDMA4
This patch add some more ddp component
OVL_2L2 is ovl which include 2 layers overlay
POSTMASK control round corner for display frame
RDMA4 read dma buffer
Signed-off-by: Yongqiang Niu
Reviewed-by: Chun-Kuang Hu
Reviewed-by: Enric Balletbo i Serra
Signed-off-by: Yongqiang Niu
---
include/linux/soc/mediatek/mtk-mmsys.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/linux/soc/mediatek/mtk-mmsys.h
b/include/linux/soc/mediatek/mtk-mmsys.h
index 2228bf6133da..4bba275e235a 100644
--- a/include/linux/soc/mediatek/mtk-mmsys.h
+++ b/include/linux/soc/mediatek/mtk-mmsys.h
@@ -29,13 +29,16 @@ enum mtk_ddp_comp_id {
DDP_COMPONENT_OVL0,
DDP_COMPONENT_OVL_2L0,
DDP_COMPONENT_OVL_2L1,
+ DDP_COMPONENT_OVL_2L2,
DDP_COMPONENT_OVL1,
+ DDP_COMPONENT_POSTMASK0,
DDP_COMPONENT_PWM0,
DDP_COMPONENT_PWM1,
DDP_COMPONENT_PWM2,
DDP_COMPONENT_RDMA0,
DDP_COMPONENT_RDMA1,
DDP_COMPONENT_RDMA2,
+ DDP_COMPONENT_RDMA4,
DDP_COMPONENT_UFOE,
DDP_COMPONENT_WDMA0,
DDP_COMPONENT_WDMA1,
--
2.25.1
[PATCH v9, 0/2] soc: mediatek: mmsys: add mt8192 mmsys support
base 5.15 Yongqiang Niu (2): soc: mediatek: mmsys: add comp OVL_2L2/POSTMASK/RDMA4 soc: mediatek: mmsys: Add mt8192 mmsys routing table drivers/soc/mediatek/mt8192-mmsys.h| 77 ++ drivers/soc/mediatek/mtk-mmsys.c | 11 include/linux/soc/mediatek/mtk-mmsys.h | 3 + 3 files changed, 91 insertions(+) create mode 100644 drivers/soc/mediatek/mt8192-mmsys.h -- 2.25.1
[PATCH v9, 2/2] soc: mediatek: mmsys: Add mt8192 mmsys routing table
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 struct mtk_mmsys_driver_data
mt8365_mmsys_driver_data = {
.num_routes = ARRAY_SIZE(mt8365_mmsys_routing_table),
};
+static const struct mtk_mmsys_driver_data mt8192_mmsys_driver_data = {
+ .clk_driver = "clk-mt8192-mm",
+ .routes = mmsys_mt8192_routing_table,
+ .num_routes = ARRAY_SIZE(mmsys_mt8192_routing_table),
+};
+
struct mtk_mmsys {
[PATCH 04/11] drm/msm/dpu: remove stage_cfg from struct dpu_crtc
The stage_cfg is not used outside of _dpu_crtc_blend_setup(), so remove
the temporary config from global struct.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 11 ++-
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h | 2 --
2 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 768012243b44..19f0715a4089 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -207,7 +207,8 @@ static void _dpu_crtc_program_lm_output_roi(struct drm_crtc
*crtc)
}
static void _dpu_crtc_blend_setup_mixer(struct drm_crtc *crtc,
- struct dpu_crtc *dpu_crtc, struct dpu_crtc_mixer *mixer)
+ struct dpu_crtc *dpu_crtc, struct dpu_crtc_mixer *mixer,
+ struct dpu_hw_stage_cfg *stage_cfg)
{
struct drm_plane *plane;
struct drm_framebuffer *fb;
@@ -216,7 +217,6 @@ static void _dpu_crtc_blend_setup_mixer(struct drm_crtc
*crtc,
struct dpu_plane_state *pstate = NULL;
struct dpu_format *format;
struct dpu_hw_ctl *ctl = mixer->lm_ctl;
- struct dpu_hw_stage_cfg *stage_cfg = &dpu_crtc->stage_cfg;
u32 flush_mask;
uint32_t stage_idx, lm_idx;
@@ -292,6 +292,7 @@ static void _dpu_crtc_blend_setup(struct drm_crtc *crtc)
struct dpu_crtc_mixer *mixer = cstate->mixers;
struct dpu_hw_ctl *ctl;
struct dpu_hw_mixer *lm;
+ struct dpu_hw_stage_cfg stage_cfg;
int i;
DRM_DEBUG_ATOMIC("%s\n", dpu_crtc->name);
@@ -305,9 +306,9 @@ static void _dpu_crtc_blend_setup(struct drm_crtc *crtc)
}
/* initialize stage cfg */
- memset(&dpu_crtc->stage_cfg, 0, sizeof(struct dpu_hw_stage_cfg));
+ memset(&stage_cfg, 0, sizeof(struct dpu_hw_stage_cfg));
- _dpu_crtc_blend_setup_mixer(crtc, dpu_crtc, mixer);
+ _dpu_crtc_blend_setup_mixer(crtc, dpu_crtc, mixer, &stage_cfg);
for (i = 0; i < cstate->num_mixers; i++) {
ctl = mixer[i].lm_ctl;
@@ -328,7 +329,7 @@ static void _dpu_crtc_blend_setup(struct drm_crtc *crtc)
mixer[i].flush_mask);
ctl->ops.setup_blendstage(ctl, mixer[i].hw_lm->idx,
- &dpu_crtc->stage_cfg);
+ &stage_cfg);
}
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
index cec3474340e8..30535acec670 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
@@ -116,7 +116,6 @@ struct dpu_crtc_frame_event {
* @drm_requested_vblank : Whether vblanks have been enabled in the encoder
* @property_info : Opaque structure for generic property support
* @property_defaults : Array of default values for generic property support
- * @stage_cfg : H/w mixer stage configuration
* @debugfs_root : Parent of debugfs node
* @vblank_cb_count : count of vblank callback since last reset
* @play_count: frame count between crtc enable and disable
@@ -147,7 +146,6 @@ struct dpu_crtc {
struct drm_pending_vblank_event *event;
u32 vsync_count;
- struct dpu_hw_stage_cfg stage_cfg;
struct dentry *debugfs_root;
u32 vblank_cb_count;
--
2.33.0
[PATCH 03/11] drm/msm/dpu: drop pipe_name from struct dpu_plane
Use plane->name instead of artificial pipe_name.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index 88d726133b8b..ef3737642b0c 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -115,7 +115,6 @@ struct dpu_plane {
struct dpu_csc_cfg *csc_ptr;
const struct dpu_sspp_sub_blks *pipe_sblk;
- char pipe_name[DPU_NAME_SIZE];
/* debugfs related stuff */
struct dentry *debugfs_root;
@@ -1429,7 +1428,7 @@ static int _dpu_plane_init_debugfs(struct drm_plane
*plane)
/* create overall sub-directory for the pipe */
pdpu->debugfs_root =
- debugfs_create_dir(pdpu->pipe_name,
+ debugfs_create_dir(plane->name,
plane->dev->primary->debugfs_root);
/* don't error check these */
@@ -1660,12 +1659,9 @@ struct drm_plane *dpu_plane_init(struct drm_device *dev,
/* success! finalize initialization */
drm_plane_helper_add(plane, &dpu_plane_helper_funcs);
- /* save user friendly pipe name for later */
- snprintf(pdpu->pipe_name, DPU_NAME_SIZE, "plane%u", plane->base.id);
-
mutex_init(&pdpu->lock);
- DPU_DEBUG("%s created for pipe:%u id:%u virtual:%u\n", pdpu->pipe_name,
+ DPU_DEBUG("%s created for pipe:%u id:%u virtual:%u\n", plane->name,
pipe, plane->base.id, master_plane_id);
return plane;
--
2.33.0
[PATCH 07/11] drm/msm/dpu: drop dpu_csc_cfg from dpu_plane
Simplify code surrounding CSC table setup by removing struct dpu_csc_cfg
pointer from dpu_plane and getting it directly at the CSC setup time.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 2 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h | 2 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.c | 2 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h | 2 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 96 +++--
5 files changed, 54 insertions(+), 50 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 cbafb61404d0..103d4bd7585b 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
@@ -537,7 +537,7 @@ static void dpu_hw_sspp_setup_sourceaddress(struct
dpu_hw_pipe *ctx,
}
static void dpu_hw_sspp_setup_csc(struct dpu_hw_pipe *ctx,
- struct dpu_csc_cfg *data)
+ const struct dpu_csc_cfg *data)
{
u32 idx;
bool csc10 = false;
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 27263bc1a1ef..e8939d7387cb 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
@@ -262,7 +262,7 @@ struct dpu_hw_sspp_ops {
* @ctx: Pointer to pipe context
* @data: Pointer to config structure
*/
- void (*setup_csc)(struct dpu_hw_pipe *ctx, struct dpu_csc_cfg *data);
+ void (*setup_csc)(struct dpu_hw_pipe *ctx, const struct dpu_csc_cfg
*data);
/**
* setup_solidfill - enable/disable colorfill
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.c
index f94584c982cd..aad85116b0a0 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.c
@@ -374,7 +374,7 @@ u32 dpu_hw_get_scaler3_ver(struct dpu_hw_blk_reg_map *c,
void dpu_hw_csc_setup(struct dpu_hw_blk_reg_map *c,
u32 csc_reg_off,
- struct dpu_csc_cfg *data, bool csc10)
+ const struct dpu_csc_cfg *data, bool csc10)
{
static const u32 matrix_shift = 7;
u32 clamp_shift = csc10 ? 16 : 8;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h
index ff3cffde84cd..bc2fdb2b8f5f 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h
@@ -321,6 +321,6 @@ u32 dpu_hw_get_scaler3_ver(struct dpu_hw_blk_reg_map *c,
void dpu_hw_csc_setup(struct dpu_hw_blk_reg_map *c,
u32 csc_reg_off,
- struct dpu_csc_cfg *data, bool csc10);
+ const struct dpu_csc_cfg *data, bool csc10);
#endif /* _DPU_HW_UTIL_H */
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index 4259c4ecde9b..b8836c089863 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -90,7 +90,6 @@ enum dpu_plane_qos {
/*
* struct dpu_plane - local dpu plane structure
* @aspace: address space pointer
- * @csc_ptr: Points to dpu_csc_cfg structure to use for current
* @mplane_list: List of multirect planes of the same pipe
* @catalog: Points to dpu catalog structure
* @revalidate: force revalidation of all the plane properties
@@ -111,8 +110,6 @@ struct dpu_plane {
struct list_head mplane_list;
struct dpu_mdss_cfg *catalog;
- struct dpu_csc_cfg *csc_ptr;
-
const struct dpu_sspp_sub_blks *pipe_sblk;
/* debugfs related stuff */
@@ -605,51 +602,59 @@ static void _dpu_plane_setup_scaler3(struct dpu_plane
*pdpu,
scale_cfg->enable = 1;
}
-static void _dpu_plane_setup_csc(struct dpu_plane *pdpu)
-{
- static const struct dpu_csc_cfg dpu_csc_YUV2RGB_601L = {
- {
- /* S15.16 format */
- 0x00012A00, 0x, 0x00019880,
- 0x00012A00, 0x9B80, 0x3000,
- 0x00012A00, 0x00020480, 0x,
+static const struct dpu_csc_cfg dpu_csc_YUV2RGB_601L = {
+ {
+ /* S15.16 format */
+ 0x00012A00, 0x, 0x00019880,
+ 0x00012A00, 0x9B80, 0x3000,
+ 0x00012A00, 0x00020480, 0x,
+ },
+ /* signed bias */
+ { 0xfff0, 0xff80, 0xff80,},
+ { 0x0, 0x0, 0x0,},
+ /* unsigned clamp */
+ { 0x10, 0xeb, 0x10, 0xf0, 0x10, 0xf0,},
+ { 0x00, 0xff, 0x00, 0xff, 0x00, 0xff,},
+};
+
+static const struct dpu_csc_cfg dpu_csc10_YUV2RGB_601L = {
+ {
+ /* S15.16 format */
+ 0x00012A00, 0x, 0x00019880,
+ 0x00012A00, 0x9B80, 0x3000,
+ 0x00012A00, 0x00020480, 0x,
},
- /* signed bias */
- { 0x
[PATCH 06/11] drm/msm/dpu: drop scaler config from plane state
Scaler and pixel_ext configuration does not contain a long living state,
it is used only during plane update, so remove these two fiels from
dpu_plane_state and allocate them on stack.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 59 ++-
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h | 6 ---
2 files changed, 26 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index 5288b5b824f8..4259c4ecde9b 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -542,14 +542,12 @@ static void _dpu_plane_setup_scaler3(struct dpu_plane
*pdpu,
struct dpu_plane_state *pstate,
uint32_t src_w, uint32_t src_h, uint32_t dst_w, uint32_t dst_h,
struct dpu_hw_scaler3_cfg *scale_cfg,
+ struct dpu_hw_pixel_ext *pixel_ext,
const struct dpu_format *fmt,
uint32_t chroma_subsmpl_h, uint32_t chroma_subsmpl_v)
{
uint32_t i;
- memset(scale_cfg, 0, sizeof(*scale_cfg));
- memset(&pstate->pixel_ext, 0, sizeof(struct dpu_hw_pixel_ext));
-
scale_cfg->phase_step_x[DPU_SSPP_COMP_0] =
mult_frac((1 << PHASE_STEP_SHIFT), src_w, dst_w);
scale_cfg->phase_step_y[DPU_SSPP_COMP_0] =
@@ -588,9 +586,9 @@ static void _dpu_plane_setup_scaler3(struct dpu_plane *pdpu,
scale_cfg->preload_y[i] = DPU_QSEED3_DEFAULT_PRELOAD_V;
}
- pstate->pixel_ext.num_ext_pxls_top[i] =
+ pixel_ext->num_ext_pxls_top[i] =
scale_cfg->src_height[i];
- pstate->pixel_ext.num_ext_pxls_left[i] =
+ pixel_ext->num_ext_pxls_left[i] =
scale_cfg->src_width[i];
}
if (!(DPU_FORMAT_IS_YUV(fmt)) && (src_h == dst_h)
@@ -660,6 +658,11 @@ static void _dpu_plane_setup_scaler(struct dpu_plane *pdpu,
struct dpu_hw_pipe_cfg *pipe_cfg)
{
const struct drm_format_info *info =
drm_format_info(fmt->base.pixel_format);
+ struct dpu_hw_scaler3_cfg scaler3_cfg;
+ struct dpu_hw_pixel_ext pixel_ext;
+
+ memset(&scaler3_cfg, 0, sizeof(scaler3_cfg));
+ memset(&pixel_ext, 0, sizeof(pixel_ext));
/* don't chroma subsample if decimating */
/* update scaler. calculate default config for QSEED3 */
@@ -668,8 +671,23 @@ static void _dpu_plane_setup_scaler(struct dpu_plane *pdpu,
drm_rect_height(&pipe_cfg->src_rect),
drm_rect_width(&pipe_cfg->dst_rect),
drm_rect_height(&pipe_cfg->dst_rect),
- &pstate->scaler3_cfg, fmt,
+ &scaler3_cfg, &pixel_ext, fmt,
info->hsub, info->vsub);
+
+ if (pdpu->pipe_hw->ops.setup_pe)
+ pdpu->pipe_hw->ops.setup_pe(pdpu->pipe_hw,
+ &pixel_ext);
+
+ /**
+* when programmed in multirect mode, scalar block will be
+* bypassed. Still we need to update alpha and bitwidth
+* ONLY for RECT0
+*/
+ if (pdpu->pipe_hw->ops.setup_scaler &&
+ pstate->multirect_index != DPU_SSPP_RECT_1)
+ pdpu->pipe_hw->ops.setup_scaler(pdpu->pipe_hw,
+ pipe_cfg, &pixel_ext,
+ &scaler3_cfg);
}
/**
@@ -710,7 +728,6 @@ static int _dpu_plane_color_fill(struct dpu_plane *pdpu,
drm_rect_width(&pipe_cfg.dst_rect);
pipe_cfg.src_rect.y2 =
drm_rect_height(&pipe_cfg.dst_rect);
- _dpu_plane_setup_scaler(pdpu, pstate, fmt, true, &pipe_cfg);
if (pdpu->pipe_hw->ops.setup_format)
pdpu->pipe_hw->ops.setup_format(pdpu->pipe_hw,
@@ -722,15 +739,7 @@ static int _dpu_plane_color_fill(struct dpu_plane *pdpu,
&pipe_cfg,
pstate->multirect_index);
- if (pdpu->pipe_hw->ops.setup_pe)
- pdpu->pipe_hw->ops.setup_pe(pdpu->pipe_hw,
- &pstate->pixel_ext);
-
- if (pdpu->pipe_hw->ops.setup_scaler &&
- pstate->multirect_index != DPU_SSPP_RECT_1)
- pdpu->pipe_hw->ops.setup_scaler(pdpu->pipe_hw,
- &pipe_cfg, &pstate->pixel_ext,
- &pstate->scaler3_cfg);
+ _dpu_plane_setup_scaler(pdpu, pstate, fmt, true, &pipe_cfg);
}
return 0;
@@ -1122,8 +1131,6 @@ static void dpu_plane_sspp_atomic_update(struct drm_plane
*plane)
pipe_cfg.dst_rect = state->dst;
- _dpu_plane_setup_scaler(pdpu, pstate, fmt, false, &pipe_cfg);
-
/* ov
[PATCH 00/11] drm/msm/dpu: cleanup plane state
This is a cleanup part of the DPU multirect patchset [1], split away to ease review and merging per Abhinav's request. Currently significant part of atomic plane state is stored in the drm_plane's subclass rather than drm_plane_state's subclass. Move it either to the drm_plane_state or even to the on-stack allocation. [1] https://lore.kernel.org/linux-arm-msm/20210705012115.4179824-1-dmitry.barysh...@linaro.org/
[PATCH 02/11] drm/msm/dpu: remove pipe_qos_cfg from struct dpu_plane
The pipe_qos_cfg is used only in _dpu_plane_set_qos_ctrl(), so remove it
from the dpu_plane struct and allocate it on stack when necessary.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 30 ---
1 file changed, 16 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index 5e0d06f26e53..88d726133b8b 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -105,7 +105,6 @@ struct dpu_plane {
struct dpu_hw_pipe *pipe_hw;
struct dpu_hw_pipe_cfg pipe_cfg;
- struct dpu_hw_pipe_qos_cfg pipe_qos_cfg;
uint32_t color_fill;
bool is_error;
bool is_rt_pipe;
@@ -422,38 +421,41 @@ static void _dpu_plane_set_qos_ctrl(struct drm_plane
*plane,
bool enable, u32 flags)
{
struct dpu_plane *pdpu = to_dpu_plane(plane);
+ struct dpu_hw_pipe_qos_cfg pipe_qos_cfg;
+
+ memset(&pipe_qos_cfg, 0, sizeof(pipe_qos_cfg));
if (flags & DPU_PLANE_QOS_VBLANK_CTRL) {
- pdpu->pipe_qos_cfg.creq_vblank = pdpu->pipe_sblk->creq_vblank;
- pdpu->pipe_qos_cfg.danger_vblank =
+ pipe_qos_cfg.creq_vblank = pdpu->pipe_sblk->creq_vblank;
+ pipe_qos_cfg.danger_vblank =
pdpu->pipe_sblk->danger_vblank;
- pdpu->pipe_qos_cfg.vblank_en = enable;
+ pipe_qos_cfg.vblank_en = enable;
}
if (flags & DPU_PLANE_QOS_VBLANK_AMORTIZE) {
/* this feature overrules previous VBLANK_CTRL */
- pdpu->pipe_qos_cfg.vblank_en = false;
- pdpu->pipe_qos_cfg.creq_vblank = 0; /* clear vblank bits */
+ pipe_qos_cfg.vblank_en = false;
+ pipe_qos_cfg.creq_vblank = 0; /* clear vblank bits */
}
if (flags & DPU_PLANE_QOS_PANIC_CTRL)
- pdpu->pipe_qos_cfg.danger_safe_en = enable;
+ pipe_qos_cfg.danger_safe_en = enable;
if (!pdpu->is_rt_pipe) {
- pdpu->pipe_qos_cfg.vblank_en = false;
- pdpu->pipe_qos_cfg.danger_safe_en = false;
+ pipe_qos_cfg.vblank_en = false;
+ pipe_qos_cfg.danger_safe_en = false;
}
DPU_DEBUG_PLANE(pdpu, "pnum:%d ds:%d vb:%d pri[0x%x, 0x%x] is_rt:%d\n",
pdpu->pipe - SSPP_VIG0,
- pdpu->pipe_qos_cfg.danger_safe_en,
- pdpu->pipe_qos_cfg.vblank_en,
- pdpu->pipe_qos_cfg.creq_vblank,
- pdpu->pipe_qos_cfg.danger_vblank,
+ pipe_qos_cfg.danger_safe_en,
+ pipe_qos_cfg.vblank_en,
+ pipe_qos_cfg.creq_vblank,
+ pipe_qos_cfg.danger_vblank,
pdpu->is_rt_pipe);
pdpu->pipe_hw->ops.setup_qos_ctrl(pdpu->pipe_hw,
- &pdpu->pipe_qos_cfg);
+ &pipe_qos_cfg);
}
/**
--
2.33.0
[PATCH 05/11] drm/msm/dpu: move dpu_hw_pipe_cfg out of struct dpu_plane
struct dpu_hw_pipe_cfg represents an interim state during atomic
update/color fill, so move it out of struct dpu_plane.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 104 --
1 file changed, 57 insertions(+), 47 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index ef3737642b0c..5288b5b824f8 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -104,7 +104,6 @@ struct dpu_plane {
uint32_t features; /* capabilities from catalog */
struct dpu_hw_pipe *pipe_hw;
- struct dpu_hw_pipe_cfg pipe_cfg;
uint32_t color_fill;
bool is_error;
bool is_rt_pipe;
@@ -143,14 +142,15 @@ static struct dpu_kms *_dpu_plane_get_kms(struct
drm_plane *plane)
* _dpu_plane_calc_bw - calculate bandwidth required for a plane
* @plane: Pointer to drm plane.
* @fb: Pointer to framebuffer associated with the given plane
+ * @pipe_cfg: Pointer to pipe configuration
* Result: Updates calculated bandwidth in the plane state.
* BW Equation: src_w * src_h * bpp * fps * (v_total / v_dest)
* Prefill BW Equation: line src bytes * line_time
*/
static void _dpu_plane_calc_bw(struct drm_plane *plane,
- struct drm_framebuffer *fb)
+ struct drm_framebuffer *fb,
+ struct dpu_hw_pipe_cfg *pipe_cfg)
{
- struct dpu_plane *pdpu = to_dpu_plane(plane);
struct dpu_plane_state *pstate;
struct drm_display_mode *mode;
const struct dpu_format *fmt = NULL;
@@ -167,9 +167,9 @@ static void _dpu_plane_calc_bw(struct drm_plane *plane,
fmt = dpu_get_dpu_format_ext(fb->format->format, fb->modifier);
- src_width = drm_rect_width(&pdpu->pipe_cfg.src_rect);
- src_height = drm_rect_height(&pdpu->pipe_cfg.src_rect);
- dst_height = drm_rect_height(&pdpu->pipe_cfg.dst_rect);
+ src_width = drm_rect_width(&pipe_cfg->src_rect);
+ src_height = drm_rect_height(&pipe_cfg->src_rect);
+ dst_height = drm_rect_height(&pipe_cfg->dst_rect);
fps = drm_mode_vrefresh(mode);
vbp = mode->vtotal - mode->vsync_end;
vpw = mode->vsync_end - mode->vsync_start;
@@ -200,12 +200,12 @@ static void _dpu_plane_calc_bw(struct drm_plane *plane,
/**
* _dpu_plane_calc_clk - calculate clock required for a plane
* @plane: Pointer to drm plane.
+ * @pipe_cfg: Pointer to pipe configuration
* Result: Updates calculated clock in the plane state.
* Clock equation: dst_w * v_total * fps * (src_h / dst_h)
*/
-static void _dpu_plane_calc_clk(struct drm_plane *plane)
+static void _dpu_plane_calc_clk(struct drm_plane *plane, struct
dpu_hw_pipe_cfg *pipe_cfg)
{
- struct dpu_plane *pdpu = to_dpu_plane(plane);
struct dpu_plane_state *pstate;
struct drm_display_mode *mode;
int dst_width, src_height, dst_height, fps;
@@ -213,9 +213,9 @@ static void _dpu_plane_calc_clk(struct drm_plane *plane)
pstate = to_dpu_plane_state(plane->state);
mode = &plane->state->crtc->mode;
- src_height = drm_rect_height(&pdpu->pipe_cfg.src_rect);
- dst_width = drm_rect_width(&pdpu->pipe_cfg.dst_rect);
- dst_height = drm_rect_height(&pdpu->pipe_cfg.dst_rect);
+ src_height = drm_rect_height(&pipe_cfg->src_rect);
+ dst_width = drm_rect_width(&pipe_cfg->dst_rect);
+ dst_height = drm_rect_height(&pipe_cfg->dst_rect);
fps = drm_mode_vrefresh(mode);
pstate->plane_clk =
@@ -252,14 +252,17 @@ static int _dpu_plane_calc_fill_level(struct drm_plane
*plane,
fixed_buff_size = pdpu->catalog->caps->pixel_ram_size;
list_for_each_entry(tmp, &pdpu->mplane_list, mplane_list) {
+ u32 tmp_width;
+
if (!tmp->base.state->visible)
continue;
+ tmp_width = drm_rect_width(&tmp->base.state->src) >> 16;
DPU_DEBUG("plane%d/%d src_width:%d/%d\n",
pdpu->base.base.id, tmp->base.base.id,
src_width,
- drm_rect_width(&tmp->pipe_cfg.src_rect));
+ tmp_width);
src_width = max_t(u32, src_width,
- drm_rect_width(&tmp->pipe_cfg.src_rect));
+ tmp_width);
}
if (fmt->fetch_planes == DPU_PLANE_PSEUDO_PLANAR) {
@@ -319,9 +322,10 @@ static u64 _dpu_plane_get_qos_lut(const struct
dpu_qos_lut_tbl *tbl,
* _dpu_plane_set_qos_lut - set QoS LUT of the given plane
* @plane: Pointer to drm plane
* @fb:Pointer to framebuffer associated with the
given plane
+ * @pipe_cfg: Pointer to pipe configuration
*/
static void _dpu_plane_set_qos_lut(struct drm_plane *plane,
- struct drm_framebuffer *fb)
+ struct drm_framebuffer *fb, struct dp
[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
[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 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 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 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
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
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: [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 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] 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] 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] 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] [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/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: [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: 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
[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
[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
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);
> >>> +
> >>>
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 > >
[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 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
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 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 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
