Re: [PATCH] drm/drm_fb_helper: fix fbdev with sparc64
Hi
Am 24.07.20 um 06:53 schrieb Dave Airlie:
> On Tue, 14 Jul 2020 at 18:56, Thomas Zimmermann wrote:
>>
>> Hi
>>
>> Am 14.07.20 um 10:41 schrieb Daniel Vetter:
>>> On Tue, Jul 14, 2020 at 08:41:58AM +0200, Thomas Zimmermann wrote:
Hi
Am 13.07.20 um 18:21 schrieb Daniel Vetter:
> On Fri, Jul 10, 2020 at 08:28:16AM +0200, Thomas Zimmermann wrote:
>> Hi
>>
>> Am 09.07.20 um 21:30 schrieb Sam Ravnborg:
>>> Mark reported that sparc64 would panic while booting using qemu.
>>> Mark bisected this to a patch that introduced generic fbdev emulation to
>>> the bochs DRM driver.
>>> Mark pointed out that a similar bug was fixed before where
>>> the sys helpers was replaced by cfb helpers.
>>>
>>> The culprint here is that the framebuffer reside in IO memory which
>>> requires SPARC ASI_PHYS (physical) loads and stores.
>>>
>>> The current bohcs DRM driver uses a shadow buffer.
>>> So all copying to the framebuffer happens in
>>> drm_fb_helper_dirty_blit_real().
>>>
>>> The fix is to replace the memcpy with memcpy_toio() from io.h.
>>>
>>> memcpy_toio() uses writeb() where the original fbdev code
>>> used sbus_memcpy_toio(). The latter uses sbus_writeb().
>>>
>>> The difference between writeb() and sbus_memcpy_toio() is
>>> that writeb() writes bytes in little-endian, where sbus_writeb() writes
>>> bytes in big-endian. As endian does not matter for byte writes they are
>>> the same. So we can safely use memcpy_toio() here.
>>>
>>> For many architectures memcpy_toio() is a simple memcpy().
>>> One sideeffect that is unknow is if this has any impact on other
>>> architectures.
>>> So far the analysis tells that this change is OK for other arch's.
>>> but testing would be good.
>>>
>>> Signed-off-by: Sam Ravnborg
>>> Reported-by: Mark Cave-Ayland
>>> Tested-by: Mark Cave-Ayland
>>> Cc: Mark Cave-Ayland
>>> Cc: Thomas Zimmermann
>>> Cc: Gerd Hoffmann
>>> Cc: "David S. Miller"
>>> Cc: sparcli...@vger.kernel.org
>>
>> So this actually is a problem in practice. Do you know how userspace
>> handles this?
>>
>> For this patch
>>
>> Acked-by: Thomas Zimmermann
>>
>> but I'd like to have someone with more architecture expertise ack this
>> as well.
>>
>> Best regards
>> Thomas
>>
>>> ---
>>> drivers/gpu/drm/drm_fb_helper.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/drm_fb_helper.c
>>> b/drivers/gpu/drm/drm_fb_helper.c
>>> index 5609e164805f..4d05b0ab1592 100644
>>> --- a/drivers/gpu/drm/drm_fb_helper.c
>>> +++ b/drivers/gpu/drm/drm_fb_helper.c
>>> @@ -399,7 +399,7 @@ static void drm_fb_helper_dirty_blit_real(struct
>>> drm_fb_helper *fb_helper,
>>> unsigned int y;
>>>
>>> for (y = clip->y1; y < clip->y2; y++) {
>>> - memcpy(dst, src, len);
>>> + memcpy_toio(dst, src, len);
>
> I don't think we can do this unconditionally, there's fbdev-helper drivers
> using shmem helpers, and for shmem memcpy_toio is wrong. We need a switch
> to fix this properly I think.
I once has a patch set for this problem, but it didn't make it. [1]
Buffers can move between I/O and system memory, so a simple flag would
not work. I'd propose this
bool drm_gem_is_iomem(struct drm_gem_object *obj)
{
if (obj->funcs && obj->funcs->is_iomem)
return obj->funcs->is_iomem(obj);
return false;
}
Most GEM implmentations wouldn't bother, but VRAM helpers could set the
is_iomem function and return the current state. Fbdev helpers can then
pick the correct memcpy_*() function.
>>>
>>> Hm wasn't the (long term at least) idea to add the is_iomem flag to the
>>> vmap functions? is_iomem is kinda only well-defined if there's a vmap of
>>> the buffer around (which also pins it), or in general when the buffer is
>>> pinned. Outside of that an ->is_iomem function doesn't make much sense.
>>
>> Oh. From how I understood the original discussion, you shoot down the
>> idea because sparse would not support it well?
>>
>> The other idea was to add an additional vmap_iomem() helper that returns
>> an__iomem pointer. Can we try that?
>>
> Did we get anywhere with this yet?
Not yet. But I intend to work on it ASAP.
Best regards
Thomas
>
> Dave.
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
--
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
signature.asc
Description: OpenPGP digital signature
___
Re: [PATCH 8/9] drm/vram-helper: stop implementing init_mem_type
Am 23.07.20 um 17:17 schrieb Christian König:
> Instead just initialize the memory type parameters
> before calling ttm_bo_init_mm.
>
> Signed-off-by: Christian König
Reviewed-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/drm_gem_vram_helper.c | 16
> 1 file changed, 4 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
> b/drivers/gpu/drm/drm_gem_vram_helper.c
> index 801a14c6e9e0..f7f93a49cd7f 100644
> --- a/drivers/gpu/drm/drm_gem_vram_helper.c
> +++ b/drivers/gpu/drm/drm_gem_vram_helper.c
> @@ -1007,18 +1007,6 @@ static struct ttm_tt *bo_driver_ttm_tt_create(struct
> ttm_buffer_object *bo,
> static int bo_driver_init_mem_type(struct ttm_bo_device *bdev, uint32_t type,
> struct ttm_mem_type_manager *man)
> {
> - switch (type) {
> - case TTM_PL_SYSTEM:
> - break;
> - case TTM_PL_VRAM:
> - man->func = &ttm_bo_manager_func;
> - man->available_caching = TTM_PL_FLAG_UNCACHED |
> - TTM_PL_FLAG_WC;
> - man->default_caching = TTM_PL_FLAG_WC;
> - break;
> - default:
> - return -EINVAL;
> - }
> return 0;
> }
>
> @@ -1126,6 +1114,7 @@ EXPORT_SYMBOL(drm_vram_mm_debugfs_init);
> static int drm_vram_mm_init(struct drm_vram_mm *vmm, struct drm_device *dev,
> uint64_t vram_base, size_t vram_size)
> {
> + struct ttm_mem_type_manager *man = &vmm->bdev.man[TTM_PL_VRAM];
> int ret;
>
> vmm->vram_base = vram_base;
> @@ -1138,6 +1127,9 @@ static int drm_vram_mm_init(struct drm_vram_mm *vmm,
> struct drm_device *dev,
> if (ret)
> return ret;
>
> + man->func = &ttm_bo_manager_func;
> + man->available_caching = TTM_PL_FLAG_UNCACHED | TTM_PL_FLAG_WC;
> + man->default_caching = TTM_PL_FLAG_WC;
> ret = ttm_bo_init_mm(&vmm->bdev, TTM_PL_VRAM, vram_size >> PAGE_SHIFT);
> if (ret)
> return ret;
>
--
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
signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 9/9] drm/ttm: remove the init_mem_type callback
Am 23.07.20 um 17:17 schrieb Christian König:
> It is a very strange concept to call a function which just
> calls back the caller for the functions parameters.
>
> Signed-off-by: Christian König
Reviewed-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 7 ---
> drivers/gpu/drm/drm_gem_vram_helper.c | 7 ---
> drivers/gpu/drm/nouveau/nouveau_bo.c | 8
> drivers/gpu/drm/qxl/qxl_ttm.c | 7 ---
> drivers/gpu/drm/radeon/radeon_ttm.c| 7 ---
> drivers/gpu/drm/ttm/ttm_bo.c | 4
> drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 7 ---
> include/drm/ttm/ttm_bo_driver.h| 6 --
> 8 files changed, 53 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> index 98a77fc4a90c..da6434ea07f1 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> @@ -62,12 +62,6 @@
>
> #define AMDGPU_TTM_VRAM_MAX_DW_READ (size_t)128
>
> -static int amdgpu_init_mem_type(struct ttm_bo_device *bdev, uint32_t type,
> - struct ttm_mem_type_manager *man)
> -{
> - return 0;
> -}
> -
> static int amdgpu_ttm_init_vram(struct amdgpu_device *adev)
> {
>
> @@ -1727,7 +1721,6 @@ static struct ttm_bo_driver amdgpu_bo_driver = {
> .ttm_tt_create = &amdgpu_ttm_tt_create,
> .ttm_tt_populate = &amdgpu_ttm_tt_populate,
> .ttm_tt_unpopulate = &amdgpu_ttm_tt_unpopulate,
> - .init_mem_type = &amdgpu_init_mem_type,
> .eviction_valuable = amdgpu_ttm_bo_eviction_valuable,
> .evict_flags = &amdgpu_evict_flags,
> .move = &amdgpu_bo_move,
> diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
> b/drivers/gpu/drm/drm_gem_vram_helper.c
> index f7f93a49cd7f..5f03c6137ef9 100644
> --- a/drivers/gpu/drm/drm_gem_vram_helper.c
> +++ b/drivers/gpu/drm/drm_gem_vram_helper.c
> @@ -1004,12 +1004,6 @@ static struct ttm_tt *bo_driver_ttm_tt_create(struct
> ttm_buffer_object *bo,
> return NULL;
> }
>
> -static int bo_driver_init_mem_type(struct ttm_bo_device *bdev, uint32_t type,
> -struct ttm_mem_type_manager *man)
> -{
> - return 0;
> -}
> -
> static void bo_driver_evict_flags(struct ttm_buffer_object *bo,
> struct ttm_placement *placement)
> {
> @@ -1069,7 +1063,6 @@ static struct ttm_bo_driver bo_driver = {
> .ttm_tt_create = bo_driver_ttm_tt_create,
> .ttm_tt_populate = ttm_pool_populate,
> .ttm_tt_unpopulate = ttm_pool_unpopulate,
> - .init_mem_type = bo_driver_init_mem_type,
> .eviction_valuable = ttm_bo_eviction_valuable,
> .evict_flags = bo_driver_evict_flags,
> .move_notify = bo_driver_move_notify,
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
> b/drivers/gpu/drm/nouveau/nouveau_bo.c
> index 23ef9b1aaabc..5efc572c14cc 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> @@ -646,13 +646,6 @@ nouveau_ttm_tt_create(struct ttm_buffer_object *bo,
> uint32_t page_flags)
> return nouveau_sgdma_create_ttm(bo, page_flags);
> }
>
> -static int
> -nouveau_bo_init_mem_type(struct ttm_bo_device *bdev, uint32_t type,
> - struct ttm_mem_type_manager *man)
> -{
> - return 0;
> -}
> -
> static void
> nouveau_bo_evict_flags(struct ttm_buffer_object *bo, struct ttm_placement
> *pl)
> {
> @@ -1643,7 +1636,6 @@ struct ttm_bo_driver nouveau_bo_driver = {
> .ttm_tt_create = &nouveau_ttm_tt_create,
> .ttm_tt_populate = &nouveau_ttm_tt_populate,
> .ttm_tt_unpopulate = &nouveau_ttm_tt_unpopulate,
> - .init_mem_type = nouveau_bo_init_mem_type,
> .eviction_valuable = ttm_bo_eviction_valuable,
> .evict_flags = nouveau_bo_evict_flags,
> .move_notify = nouveau_bo_move_ntfy,
> diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
> index 852089d7f783..32069e4799f3 100644
> --- a/drivers/gpu/drm/qxl/qxl_ttm.c
> +++ b/drivers/gpu/drm/qxl/qxl_ttm.c
> @@ -48,12 +48,6 @@ static struct qxl_device *qxl_get_qdev(struct
> ttm_bo_device *bdev)
> return qdev;
> }
>
> -static int qxl_init_mem_type(struct ttm_bo_device *bdev, uint32_t type,
> - struct ttm_mem_type_manager *man)
> -{
> - return 0;
> -}
> -
> static void qxl_evict_flags(struct ttm_buffer_object *bo,
> struct ttm_placement *placement)
> {
> @@ -215,7 +209,6 @@ static void qxl_bo_move_notify(struct ttm_buffer_object
> *bo,
>
> static struct ttm_bo_driver qxl_bo_driver = {
> .ttm_tt_create = &qxl_ttm_tt_create,
> - .init_mem_type = &qxl_init_mem_type,
> .eviction_valuable = ttm_bo_eviction_valuable,
> .evict_flags = &qxl_evict_flags,
> .move = &qxl_bo_move,
> diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
> b/drivers/gpu/drm/radeon/radeon_ttm.c
> index b0b59c553785..
Re: [PATCH 2/9] drm/ttm: remove TTM_MEMTYPE_FLAG_FIXED
Am 23.07.20 um 17:17 schrieb Christian König:
> Instead use a boolean field in the memory manager structure.
>
> Also invert the meaning of the field since the use of a TT
> structure is the special case here.
>
> Signed-off-by: Christian König
There's a comment further below. In any case
Reviewed-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 4 +---
> drivers/gpu/drm/drm_gem_vram_helper.c | 1 -
> drivers/gpu/drm/nouveau/nouveau_bo.c | 4 +---
> drivers/gpu/drm/qxl/qxl_ttm.c | 1 -
> drivers/gpu/drm/radeon/radeon_ttm.c| 3 +--
> drivers/gpu/drm/ttm/ttm_bo.c | 14 +++---
> drivers/gpu/drm/ttm/ttm_bo_util.c | 12 ++--
> drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 3 ++-
> include/drm/ttm/ttm_bo_driver.h| 4 +---
> 9 files changed, 19 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> index e57c49a91b73..406bcb03df48 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> @@ -87,15 +87,14 @@ static int amdgpu_init_mem_type(struct ttm_bo_device
> *bdev, uint32_t type,
> break;
> case TTM_PL_TT:
> /* GTT memory */
> + man->use_tt = true;
> man->func = &amdgpu_gtt_mgr_func;
> man->available_caching = TTM_PL_MASK_CACHING;
> man->default_caching = TTM_PL_FLAG_CACHED;
> - man->flags = 0;
> break;
> case TTM_PL_VRAM:
> /* "On-card" video ram */
> man->func = &amdgpu_vram_mgr_func;
> - man->flags = TTM_MEMTYPE_FLAG_FIXED;
> man->available_caching = TTM_PL_FLAG_UNCACHED | TTM_PL_FLAG_WC;
> man->default_caching = TTM_PL_FLAG_WC;
> break;
> @@ -104,7 +103,6 @@ static int amdgpu_init_mem_type(struct ttm_bo_device
> *bdev, uint32_t type,
> case AMDGPU_PL_OA:
> /* On-chip GDS memory*/
> man->func = &ttm_bo_manager_func;
> - man->flags = TTM_MEMTYPE_FLAG_FIXED;
> man->available_caching = TTM_PL_FLAG_UNCACHED;
> man->default_caching = TTM_PL_FLAG_UNCACHED;
> break;
> diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
> b/drivers/gpu/drm/drm_gem_vram_helper.c
> index be177afdeb9a..801a14c6e9e0 100644
> --- a/drivers/gpu/drm/drm_gem_vram_helper.c
> +++ b/drivers/gpu/drm/drm_gem_vram_helper.c
> @@ -1012,7 +1012,6 @@ static int bo_driver_init_mem_type(struct ttm_bo_device
> *bdev, uint32_t type,
> break;
> case TTM_PL_VRAM:
> man->func = &ttm_bo_manager_func;
> - man->flags = TTM_MEMTYPE_FLAG_FIXED;
> man->available_caching = TTM_PL_FLAG_UNCACHED |
>TTM_PL_FLAG_WC;
> man->default_caching = TTM_PL_FLAG_WC;
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
> b/drivers/gpu/drm/nouveau/nouveau_bo.c
> index 53af25020bb2..a3ad66ad3817 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> @@ -657,7 +657,6 @@ nouveau_bo_init_mem_type(struct ttm_bo_device *bdev,
> uint32_t type,
> case TTM_PL_SYSTEM:
> break;
> case TTM_PL_VRAM:
> - man->flags = TTM_MEMTYPE_FLAG_FIXED;
> man->available_caching = TTM_PL_FLAG_UNCACHED |
>TTM_PL_FLAG_WC;
> man->default_caching = TTM_PL_FLAG_WC;
> @@ -685,13 +684,12 @@ nouveau_bo_init_mem_type(struct ttm_bo_device *bdev,
> uint32_t type,
> else
> man->func = &ttm_bo_manager_func;
>
> + man->use_tt = true;
> if (drm->agp.bridge) {
> - man->flags = 0;
> man->available_caching = TTM_PL_FLAG_UNCACHED |
> TTM_PL_FLAG_WC;
> man->default_caching = TTM_PL_FLAG_WC;
> } else {
> - man->flags = 0;
> man->available_caching = TTM_PL_MASK_CACHING;
> man->default_caching = TTM_PL_FLAG_CACHED;
> }
> diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
> index e9b8c921c1f0..abb9fa4d80cf 100644
> --- a/drivers/gpu/drm/qxl/qxl_ttm.c
> +++ b/drivers/gpu/drm/qxl/qxl_ttm.c
> @@ -59,7 +59,6 @@ static int qxl_init_mem_type(struct ttm_bo_device *bdev,
> uint32_t type,
> case TTM_PL_PRIV:
> /* "On-card" video ram */
> man->func = &ttm_bo_manager_func;
> - man->flags = TTM_MEMTYPE_FLAG_FIXED;
> man->available_caching = TTM_PL_MASK_CACHING;
> man->default_caching = TTM_PL_FLAG_CACHED;
> break;
> diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
> b/drivers/gpu/drm/ra
Re: [PATCH 1/9] drm/ttm: initialize the system domain with defaults
Am 23.07.20 um 17:17 schrieb Christian König:
> Instead of repeating that in each driver.
>
> Signed-off-by: Christian König
Reviewed-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 3 ---
> drivers/gpu/drm/drm_gem_vram_helper.c | 3 ---
> drivers/gpu/drm/nouveau/nouveau_bo.c | 3 ---
> drivers/gpu/drm/qxl/qxl_ttm.c | 3 ---
> drivers/gpu/drm/radeon/radeon_ttm.c| 3 ---
> drivers/gpu/drm/ttm/ttm_bo.c | 2 ++
> drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 2 --
> 7 files changed, 2 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> index 0dd5e802091d..e57c49a91b73 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> @@ -84,9 +84,6 @@ static int amdgpu_init_mem_type(struct ttm_bo_device *bdev,
> uint32_t type,
> switch (type) {
> case TTM_PL_SYSTEM:
> /* System memory */
> - man->flags = 0;
> - man->available_caching = TTM_PL_MASK_CACHING;
> - man->default_caching = TTM_PL_FLAG_CACHED;
> break;
> case TTM_PL_TT:
> /* GTT memory */
> diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
> b/drivers/gpu/drm/drm_gem_vram_helper.c
> index 3296ed3df358..be177afdeb9a 100644
> --- a/drivers/gpu/drm/drm_gem_vram_helper.c
> +++ b/drivers/gpu/drm/drm_gem_vram_helper.c
> @@ -1009,9 +1009,6 @@ static int bo_driver_init_mem_type(struct ttm_bo_device
> *bdev, uint32_t type,
> {
> switch (type) {
> case TTM_PL_SYSTEM:
> - man->flags = 0;
> - man->available_caching = TTM_PL_MASK_CACHING;
> - man->default_caching = TTM_PL_FLAG_CACHED;
> break;
> case TTM_PL_VRAM:
> man->func = &ttm_bo_manager_func;
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
> b/drivers/gpu/drm/nouveau/nouveau_bo.c
> index 4ccf937df0d0..53af25020bb2 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> @@ -655,9 +655,6 @@ nouveau_bo_init_mem_type(struct ttm_bo_device *bdev,
> uint32_t type,
>
> switch (type) {
> case TTM_PL_SYSTEM:
> - man->flags = 0;
> - man->available_caching = TTM_PL_MASK_CACHING;
> - man->default_caching = TTM_PL_FLAG_CACHED;
> break;
> case TTM_PL_VRAM:
> man->flags = TTM_MEMTYPE_FLAG_FIXED;
> diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
> index 1d8e07b8b19e..e9b8c921c1f0 100644
> --- a/drivers/gpu/drm/qxl/qxl_ttm.c
> +++ b/drivers/gpu/drm/qxl/qxl_ttm.c
> @@ -54,9 +54,6 @@ static int qxl_init_mem_type(struct ttm_bo_device *bdev,
> uint32_t type,
> switch (type) {
> case TTM_PL_SYSTEM:
> /* System memory */
> - man->flags = 0;
> - man->available_caching = TTM_PL_MASK_CACHING;
> - man->default_caching = TTM_PL_FLAG_CACHED;
> break;
> case TTM_PL_VRAM:
> case TTM_PL_PRIV:
> diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
> b/drivers/gpu/drm/radeon/radeon_ttm.c
> index b474781a0920..b4cb75361577 100644
> --- a/drivers/gpu/drm/radeon/radeon_ttm.c
> +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
> @@ -76,9 +76,6 @@ static int radeon_init_mem_type(struct ttm_bo_device *bdev,
> uint32_t type,
> switch (type) {
> case TTM_PL_SYSTEM:
> /* System memory */
> - man->flags = 0;
> - man->available_caching = TTM_PL_MASK_CACHING;
> - man->default_caching = TTM_PL_FLAG_CACHED;
> break;
> case TTM_PL_TT:
> man->func = &ttm_bo_manager_func;
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index 7c02ce784805..1f1f9e463265 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -1677,6 +1677,8 @@ int ttm_bo_device_init(struct ttm_bo_device *bdev,
>* Initialize the system memory buffer type.
>* Other types need to be driver / IOCTL initialized.
>*/
> + bdev->man[TTM_PL_SYSTEM].available_caching = TTM_PL_MASK_CACHING;
> + bdev->man[TTM_PL_SYSTEM].default_caching = TTM_PL_FLAG_CACHED;
> ret = ttm_bo_init_mm(bdev, TTM_PL_SYSTEM, 0);
> if (unlikely(ret != 0))
> goto out_no_sys;
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
> index 1d78187eaba6..00cef1a3a178 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
> @@ -742,8 +742,6 @@ static int vmw_init_mem_type(struct ttm_bo_device *bdev,
> uint32_t type,
> switch (type) {
> case TTM_PL_SYSTEM:
> /* System memory */
> - man->available_caching = TTM_PL_FLAG_CACHED;
> - man->default_caching = TTM_PL_FLA
[PATCH] newport_con: vc_color is now in state
Since commit 28bc24fc46f9 (vc: separate state), vc->vc_color is known as
vc->state.color. Somehow both me and 0-day bot missed this driver during
the conversion.
So fix the driver now.
Signed-off-by: Jiri Slaby
Cc: Bartlomiej Zolnierkiewicz
Cc: dri-devel@lists.freedesktop.org
Cc: linux-fb...@vger.kernel.org
Cc: linux-m...@vger.kernel.org
---
drivers/video/console/newport_con.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/video/console/newport_con.c
b/drivers/video/console/newport_con.c
index df3c52d72159..72f146d047d9 100644
--- a/drivers/video/console/newport_con.c
+++ b/drivers/video/console/newport_con.c
@@ -362,12 +362,12 @@ static void newport_clear(struct vc_data *vc, int sy, int
sx, int height,
if (ystart < yend) {
newport_clear_screen(sx << 3, ystart, xend, yend,
-(vc->vc_color & 0xf0) >> 4);
+(vc->state.color & 0xf0) >> 4);
} else {
newport_clear_screen(sx << 3, ystart, xend, 1023,
-(vc->vc_color & 0xf0) >> 4);
+(vc->state.color & 0xf0) >> 4);
newport_clear_screen(sx << 3, 0, xend, yend,
-(vc->vc_color & 0xf0) >> 4);
+(vc->state.color & 0xf0) >> 4);
}
}
@@ -591,11 +591,11 @@ static bool newport_scroll(struct vc_data *vc, unsigned
int t, unsigned int b,
topscan = (topscan + (lines << 4)) & 0x3ff;
newport_clear_lines(vc->vc_rows - lines,
vc->vc_rows - 1,
- (vc->vc_color & 0xf0) >> 4);
+ (vc->state.color & 0xf0) >> 4);
} else {
topscan = (topscan + (-lines << 4)) & 0x3ff;
newport_clear_lines(0, lines - 1,
- (vc->vc_color & 0xf0) >> 4);
+ (vc->state.color & 0xf0) >> 4);
}
npregs->cset.topscan = (topscan - 1) & 0x3ff;
return false;
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/drm_fb_helper: fix fbdev with sparc64
Hi Dave.
On Fri, Jul 24, 2020 at 02:53:30PM +1000, Dave Airlie wrote:
> On Tue, 14 Jul 2020 at 18:56, Thomas Zimmermann wrote:
> >
> > Hi
> >
> > Am 14.07.20 um 10:41 schrieb Daniel Vetter:
> > > On Tue, Jul 14, 2020 at 08:41:58AM +0200, Thomas Zimmermann wrote:
> > >> Hi
> > >>
> > >> Am 13.07.20 um 18:21 schrieb Daniel Vetter:
> > >>> On Fri, Jul 10, 2020 at 08:28:16AM +0200, Thomas Zimmermann wrote:
> > Hi
> >
> > Am 09.07.20 um 21:30 schrieb Sam Ravnborg:
> > > Mark reported that sparc64 would panic while booting using qemu.
> > > Mark bisected this to a patch that introduced generic fbdev emulation
> > > to
> > > the bochs DRM driver.
> > > Mark pointed out that a similar bug was fixed before where
> > > the sys helpers was replaced by cfb helpers.
> > >
> > > The culprint here is that the framebuffer reside in IO memory which
> > > requires SPARC ASI_PHYS (physical) loads and stores.
> > >
> > > The current bohcs DRM driver uses a shadow buffer.
> > > So all copying to the framebuffer happens in
> > > drm_fb_helper_dirty_blit_real().
> > >
> > > The fix is to replace the memcpy with memcpy_toio() from io.h.
> > >
> > > memcpy_toio() uses writeb() where the original fbdev code
> > > used sbus_memcpy_toio(). The latter uses sbus_writeb().
> > >
> > > The difference between writeb() and sbus_memcpy_toio() is
> > > that writeb() writes bytes in little-endian, where sbus_writeb()
> > > writes
> > > bytes in big-endian. As endian does not matter for byte writes they
> > > are
> > > the same. So we can safely use memcpy_toio() here.
> > >
> > > For many architectures memcpy_toio() is a simple memcpy().
> > > One sideeffect that is unknow is if this has any impact on other
> > > architectures.
> > > So far the analysis tells that this change is OK for other arch's.
> > > but testing would be good.
> > >
> > > Signed-off-by: Sam Ravnborg
> > > Reported-by: Mark Cave-Ayland
> > > Tested-by: Mark Cave-Ayland
> > > Cc: Mark Cave-Ayland
> > > Cc: Thomas Zimmermann
> > > Cc: Gerd Hoffmann
> > > Cc: "David S. Miller"
> > > Cc: sparcli...@vger.kernel.org
> >
> > So this actually is a problem in practice. Do you know how userspace
> > handles this?
> >
> > For this patch
> >
> > Acked-by: Thomas Zimmermann
> >
> > but I'd like to have someone with more architecture expertise ack this
> > as well.
> >
> > Best regards
> > Thomas
> >
> > > ---
> > > drivers/gpu/drm/drm_fb_helper.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_fb_helper.c
> > > b/drivers/gpu/drm/drm_fb_helper.c
> > > index 5609e164805f..4d05b0ab1592 100644
> > > --- a/drivers/gpu/drm/drm_fb_helper.c
> > > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > > @@ -399,7 +399,7 @@ static void drm_fb_helper_dirty_blit_real(struct
> > > drm_fb_helper *fb_helper,
> > > unsigned int y;
> > >
> > > for (y = clip->y1; y < clip->y2; y++) {
> > > - memcpy(dst, src, len);
> > > + memcpy_toio(dst, src, len);
> > >>>
> > >>> I don't think we can do this unconditionally, there's fbdev-helper
> > >>> drivers
> > >>> using shmem helpers, and for shmem memcpy_toio is wrong. We need a
> > >>> switch
> > >>> to fix this properly I think.
> > >>
> > >> I once has a patch set for this problem, but it didn't make it. [1]
> > >>
> > >> Buffers can move between I/O and system memory, so a simple flag would
> > >> not work. I'd propose this
> > >>
> > >> bool drm_gem_is_iomem(struct drm_gem_object *obj)
> > >> {
> > >> if (obj->funcs && obj->funcs->is_iomem)
> > >> return obj->funcs->is_iomem(obj);
> > >> return false;
> > >> }
> > >>
> > >> Most GEM implmentations wouldn't bother, but VRAM helpers could set the
> > >> is_iomem function and return the current state. Fbdev helpers can then
> > >> pick the correct memcpy_*() function.
> > >
> > > Hm wasn't the (long term at least) idea to add the is_iomem flag to the
> > > vmap functions? is_iomem is kinda only well-defined if there's a vmap of
> > > the buffer around (which also pins it), or in general when the buffer is
> > > pinned. Outside of that an ->is_iomem function doesn't make much sense.
> >
> > Oh. From how I understood the original discussion, you shoot down the
> > idea because sparse would not support it well?
> >
> > The other idea was to add an additional vmap_iomem() helper that returns
> > an__iomem pointer. Can we try that?
> >
> Did we get anywhere with this yet?
A few on the work I did so far.
Using qemu the original reported bug was fixed only be replacing a
memcpy with memcpy_toio.
But this looks like only a half solution as we would still use the sys_*
variants to copy data to the framebuffer,
[git pull] drm fixes for 5.8-rc7
Quiet fixes, I may have a single regression fix follow up to this for nouveau, but it might be next week, Ben was testing it a bit more . Otherwise two amdgpu fixes, one lima and one sun4i. Dave. drm-fixes-2020-07-24: drm fixes for 5.6-rc7 amdgpu: - Fix crash when overclocking VegaM - Fix possible crash when editing dpm levels sun4i: - Fix inverted HPD result; fixes an earlier fix lima: - fix timeout during reset The following changes since commit ba47d845d715a010f7b51f6f89bae32845e6acb7: Linux 5.8-rc6 (2020-07-19 15:41:18 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-07-24 for you to fetch changes up to d8904ca9d338cdaa67e3bd06d7a7d418e426648c: Merge tag 'amd-drm-fixes-5.8-2020-07-22' of git://people.freedesktop.org/~agd5f/linux into drm-fixes (2020-07-23 14:06:16 +1000) drm fixes for 5.6-rc7 amdgpu: - Fix crash when overclocking VegaM - Fix possible crash when editing dpm levels sun4i: - Fix inverted HPD result; fixes an earlier fix lima: - fix timeout during reset Chen-Yu Tsai (1): drm: sun4i: hdmi: Fix inverted HPD result Dave Airlie (2): Merge tag 'drm-misc-fixes-2020-07-22' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes Merge tag 'amd-drm-fixes-5.8-2020-07-22' of git://people.freedesktop.org/~agd5f/linux into drm-fixes Paweł Gronowski (1): drm/amdgpu: Fix NULL dereference in dpm sysfs handlers Qiang Yu (1): drm/lima: fix wait pp reset timeout Qiu Wenbo (1): drm/amd/powerplay: fix a crash when overclocking Vega M drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 9 +++-- drivers/gpu/drm/amd/powerplay/smumgr/vegam_smumgr.c | 10 ++ drivers/gpu/drm/lima/lima_pp.c | 2 ++ drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 2 +- 4 files changed, 12 insertions(+), 11 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/drm_fb_helper: fix fbdev with sparc64
On Tue, 14 Jul 2020 at 18:56, Thomas Zimmermann wrote:
>
> Hi
>
> Am 14.07.20 um 10:41 schrieb Daniel Vetter:
> > On Tue, Jul 14, 2020 at 08:41:58AM +0200, Thomas Zimmermann wrote:
> >> Hi
> >>
> >> Am 13.07.20 um 18:21 schrieb Daniel Vetter:
> >>> On Fri, Jul 10, 2020 at 08:28:16AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 09.07.20 um 21:30 schrieb Sam Ravnborg:
> > Mark reported that sparc64 would panic while booting using qemu.
> > Mark bisected this to a patch that introduced generic fbdev emulation to
> > the bochs DRM driver.
> > Mark pointed out that a similar bug was fixed before where
> > the sys helpers was replaced by cfb helpers.
> >
> > The culprint here is that the framebuffer reside in IO memory which
> > requires SPARC ASI_PHYS (physical) loads and stores.
> >
> > The current bohcs DRM driver uses a shadow buffer.
> > So all copying to the framebuffer happens in
> > drm_fb_helper_dirty_blit_real().
> >
> > The fix is to replace the memcpy with memcpy_toio() from io.h.
> >
> > memcpy_toio() uses writeb() where the original fbdev code
> > used sbus_memcpy_toio(). The latter uses sbus_writeb().
> >
> > The difference between writeb() and sbus_memcpy_toio() is
> > that writeb() writes bytes in little-endian, where sbus_writeb() writes
> > bytes in big-endian. As endian does not matter for byte writes they are
> > the same. So we can safely use memcpy_toio() here.
> >
> > For many architectures memcpy_toio() is a simple memcpy().
> > One sideeffect that is unknow is if this has any impact on other
> > architectures.
> > So far the analysis tells that this change is OK for other arch's.
> > but testing would be good.
> >
> > Signed-off-by: Sam Ravnborg
> > Reported-by: Mark Cave-Ayland
> > Tested-by: Mark Cave-Ayland
> > Cc: Mark Cave-Ayland
> > Cc: Thomas Zimmermann
> > Cc: Gerd Hoffmann
> > Cc: "David S. Miller"
> > Cc: sparcli...@vger.kernel.org
>
> So this actually is a problem in practice. Do you know how userspace
> handles this?
>
> For this patch
>
> Acked-by: Thomas Zimmermann
>
> but I'd like to have someone with more architecture expertise ack this
> as well.
>
> Best regards
> Thomas
>
> > ---
> > drivers/gpu/drm/drm_fb_helper.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_fb_helper.c
> > b/drivers/gpu/drm/drm_fb_helper.c
> > index 5609e164805f..4d05b0ab1592 100644
> > --- a/drivers/gpu/drm/drm_fb_helper.c
> > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > @@ -399,7 +399,7 @@ static void drm_fb_helper_dirty_blit_real(struct
> > drm_fb_helper *fb_helper,
> > unsigned int y;
> >
> > for (y = clip->y1; y < clip->y2; y++) {
> > - memcpy(dst, src, len);
> > + memcpy_toio(dst, src, len);
> >>>
> >>> I don't think we can do this unconditionally, there's fbdev-helper drivers
> >>> using shmem helpers, and for shmem memcpy_toio is wrong. We need a switch
> >>> to fix this properly I think.
> >>
> >> I once has a patch set for this problem, but it didn't make it. [1]
> >>
> >> Buffers can move between I/O and system memory, so a simple flag would
> >> not work. I'd propose this
> >>
> >> bool drm_gem_is_iomem(struct drm_gem_object *obj)
> >> {
> >> if (obj->funcs && obj->funcs->is_iomem)
> >> return obj->funcs->is_iomem(obj);
> >> return false;
> >> }
> >>
> >> Most GEM implmentations wouldn't bother, but VRAM helpers could set the
> >> is_iomem function and return the current state. Fbdev helpers can then
> >> pick the correct memcpy_*() function.
> >
> > Hm wasn't the (long term at least) idea to add the is_iomem flag to the
> > vmap functions? is_iomem is kinda only well-defined if there's a vmap of
> > the buffer around (which also pins it), or in general when the buffer is
> > pinned. Outside of that an ->is_iomem function doesn't make much sense.
>
> Oh. From how I understood the original discussion, you shoot down the
> idea because sparse would not support it well?
>
> The other idea was to add an additional vmap_iomem() helper that returns
> an__iomem pointer. Can we try that?
>
Did we get anywhere with this yet?
Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: bridge: adv7511: Add missing bridge type
On 24-07-20, 04:30, Laurent Pinchart wrote: > Hi Vinod, > > Thank you for the patch. > > On Thu, Jul 23, 2020 at 04:15:23PM +0530, Vinod Koul wrote: > > Add bridge type as DRM_MODE_CONNECTOR_HDMIA > > > > Signed-off-by: Vinod Koul > > This has already been submitted: > https://lore.kernel.org/dri-devel/20200720124228.12552-1-laurentiu.pa...@oss.nxp.com/ OKay lets drop this one then -- ~Vinod ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge/adv7511: set the bridge type properly
On 22-07-20, 15:15, Laurent Pinchart wrote: > Hi Laurentiu, > > Thank you for the patch. > > On Mon, Jul 20, 2020 at 03:42:27PM +0300, Laurentiu Palcu wrote: > > From: Laurentiu Palcu > > > > After the drm_bridge_connector_init() helper function has been added, the > > ADV > > driver has been changed accordingly. However, the 'type' field of the bridge > > structure was left unset, which makes the helper function always return > > -EINVAL. > > > > Signed-off-by: Laurentiu Palcu > > Reviewed-by: Laurent Pinchart Thanks Laurent for pointing me to this. Reviewed-by: Vinod Koul I have tested this on DragonBoard 410c: Tested-by: Vinod Koul -- ~Vinod ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/2] dt-bindings: display: panel: Add bindings for Tianma nt36672a panel
Hi Rob,
Thanks for the review!
On Thu, 23 Jul 2020 at 23:25, Rob Herring wrote:
>
> On Wed, Jul 22, 2020 at 11:28:15AM +0530, Sumit Semwal wrote:
> > The nt36672a panel from Tianma is a FHD+ panel with a resolution of
> > 1080x2246
> > and 6.18 inches size. It is found in some of the Poco F1 phones.
> >
> > Signed-off-by: Sumit Semwal
> > Change-Id: I401dfbfe23ff2d806c956002f45e349cb9688c16
>
> You know better...
Yes - Sorry :( - will correct.
>
> > ---
> > v2: remove ports node, making port@0 directly under panel@0 node.
> > ---
> > .../display/panel/tianma,nt36672a.yaml| 104 ++
> > 1 file changed, 104 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
> > b/Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
> > new file mode 100644
> > index ..cb1799fbbd32
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
> > @@ -0,0 +1,104 @@
> > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/display/panel/tianma,nt36672a.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Tianma model NT36672A DSI Panel display driver
> > +
> > +maintainers:
> > + - Sumit Semwal
> > +
> > +description: |
> > + The nt36672a panel from Tianma is a FHD+ LCD display panel with a
> > resolution
> > + of 1080x2246. It is a video mode DSI panel.
> > +
> > +allOf:
> > + - $ref: panel-common.yaml#
> > +
> > +properties:
> > + compatible:
> > +const: tianma,nt36672a
> > +
> > + reg:
> > +description: DSI virtual channel of the peripheral
> > +
> > + reset-gpios:
> > +description: phandle of gpio for reset line - This should be 8mA, gpio
> > + can be configured using mux, pinctrl, pinctrl-names (active high)
> > +
> > + vddio-supply:
> > +description: phandle of the regulator that provides the supply voltage
> > + Power IC supply
> > +
> > + vddpos-supply:
> > +description: phandle of the positive boost supply regulator
> > +
> > + vddneg-supply:
> > +description: phandle of the negative boost supply regulator
> > +
> > + pinctrl-names:
> > +description: Pinctrl for panel active and suspend
> > +
> > + pinctrl-0:
> > +description: Active pinctrls
> > +
> > + pinctrl-1:
> > +description: Suspend pinctrls
> > +
> > + port@0:
>
> Just 'port' as there can only be 1 in this case.
>
> You can do just: 'port: true' as panel-common.yaml already has a
> definition.
Ok, let me try that and send out v3.
>
> > +type: object
> > +description: DSI input port driven by master DSI
> > +properties:
> > + reg:
> > +const: 0
> > +
> > +required:
> > + - reg
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - vddi0-supply
> > + - vddpos-supply
> > + - vddneg-supply
> > + - reset-gpios
> > + - pinctrl-names
> > + - pinctrl-0
> > + - pinctrl-1
> > + - port@0
> > +
> > +unevaluatedProperties: false
> > +
> > +examples:
> > + - |+
> > +#include
> > +dsi0 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + panel@0 {
> > +compatible = "tianma,nt36672a";
> > +reg = <0>;
> > +vddi0-supply = <&vreg_l14a_1p88>;
> > +vddpos-supply = <&lab>;
> > +vddneg-supply = <&ibb>;
> > +
> > +reset-gpios = <&tlmm 6 GPIO_ACTIVE_HIGH>;
> > +
> > +pinctrl-names = "panel_active", "panel_suspend";
> > +pinctrl-0 = <&sde_dsi_active>;
> > +pinctrl-1 = <&sde_dsi_suspend>;
> > +
> > +#address-cells = <1>;
> > +#size-cells = <0>;
> > +port@0 {
> > + reg = <0>;
> > + tianma_nt36672a_in_0: endpoint {
> > +remote-endpoint = <&dsi0_out>;
> > + };
> > +};
> > + };
> > +};
> > +
> > +...
> > --
> > 2.27.0
> >
>
Best,
Sumit.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Nouveau] [PATCH v2] drm/nouveau: Accept 'legacy' format modifiers
On Sat, 18 Jul 2020 at 13:34, James Jones wrote:
>
> Accept the DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK()
> family of modifiers to handle broken userspace
> Xorg modesetting and Mesa drivers. Existing Mesa
> drivers are still aware of only these older
> format modifiers which do not differentiate
> between different variations of the block linear
> layout. When the format modifier support flag was
> flipped in the nouveau kernel driver, the X.org
> modesetting driver began attempting to use its
> format modifier-enabled framebuffer path. Because
> the set of format modifiers advertised by the
> kernel prior to this change do not intersect with
> the set of format modifiers advertised by Mesa,
> allocating GBM buffers using format modifiers
> fails and the modesetting driver falls back to
> non-modifier allocation. However, it still later
> queries the modifier of the GBM buffer when
> creating its DRM-KMS framebuffer object, receives
> the old-format modifier from Mesa, and attempts
> to create a framebuffer with it. Since the kernel
> is still not aware of these formats, this fails.
>
> Userspace should not be attempting to query format
> modifiers of GBM buffers allocated with a non-
> format-modifier-aware allocation path, but to
> avoid breaking existing userspace behavior, this
> change accepts the old-style format modifiers when
> creating framebuffers and applying them to planes
> by translating them to the equivalent new-style
> modifier. To accomplish this, some layout
> parameters must be assumed to match properties of
> the device targeted by the relevant ioctls. To
> avoid perpetuating misuse of the old-style
> modifiers, this change does not advertise support
> for them. Doing so would imply compatibility
> between devices with incompatible memory layouts.
>
> Tested with Xorg 1.20 modesetting driver,
> weston@c46c70dac84a4b3030cd05b380f9f410536690fc,
> gnome & KDE wayland desktops from Ubuntu 18.04,
> and sway 1.5
>
> Reported-by: Kirill A. Shutemov
> Fixes: fa4f4c213f5f ("drm/nouveau/kms: Support NVIDIA format modifiers")
> Link: https://lkml.org/lkml/2020/6/30/1251
> Signed-off-by: James Jones
> ---
> drivers/gpu/drm/nouveau/nouveau_display.c | 26 +--
> 1 file changed, 24 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
> b/drivers/gpu/drm/nouveau/nouveau_display.c
> index 496c4621cc78..31543086254b 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_display.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_display.c
> @@ -191,8 +191,14 @@ nouveau_decode_mod(struct nouveau_drm *drm,
>uint32_t *tile_mode,
>uint8_t *kind)
> {
> + struct nouveau_display *disp = nouveau_display(drm->dev);
> BUG_ON(!tile_mode || !kind);
>
> + if ((modifier & (0xffull << 12)) == 0ull) {
> + /* Legacy modifier. Translate to this device's 'kind.' */
> + modifier |= disp->format_modifiers[0] & (0xffull << 12);
> + }
I believe this should be moved into the != MOD_LINEAR case.
> +
> if (modifier == DRM_FORMAT_MOD_LINEAR) {
> /* tile_mode will not be used in this case */
> *tile_mode = 0;
> @@ -227,6 +233,16 @@ nouveau_framebuffer_get_layout(struct drm_framebuffer
> *fb,
> }
> }
>
> +static const u64 legacy_modifiers[] = {
> + DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(0),
> + DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(1),
> + DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(2),
> + DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(3),
> + DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(4),
> + DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK(5),
> + DRM_FORMAT_MOD_INVALID
> +};
> +
> static int
> nouveau_validate_decode_mod(struct nouveau_drm *drm,
> uint64_t modifier,
> @@ -247,8 +263,14 @@ nouveau_validate_decode_mod(struct nouveau_drm *drm,
> (disp->format_modifiers[mod] != modifier);
> mod++);
>
> - if (disp->format_modifiers[mod] == DRM_FORMAT_MOD_INVALID)
> - return -EINVAL;
> + if (disp->format_modifiers[mod] == DRM_FORMAT_MOD_INVALID) {
> + for (mod = 0;
> +(legacy_modifiers[mod] != DRM_FORMAT_MOD_INVALID) &&
> +(legacy_modifiers[mod] != modifier);
> +mod++);
> + if (legacy_modifiers[mod] == DRM_FORMAT_MOD_INVALID)
> + return -EINVAL;
> + }
>
> nouveau_decode_mod(drm, modifier, tile_mode, kind);
>
> --
> 2.17.1
>
> ___
> Nouveau mailing list
> nouv...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ttm: fix pipelined gutting for evictions
Am 2020-07-23 um 9:58 p.m. schrieb philip yang:
>
> On 2020-07-23 7:02 p.m., Felix Kuehling wrote:
>> Am 2020-07-23 um 5:00 a.m. schrieb Christian König:
>>> We can't pipeline that during eviction because the memory needs
>>> to be available immediately.
>>>
>>> Signed-off-by: Christian König
>>> ---
>>> drivers/gpu/drm/ttm/ttm_bo.c | 12 ++--
>>> 1 file changed, 10 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c
>>> b/drivers/gpu/drm/ttm/ttm_bo.c
>>> index bc2230ecb7e3..122040056a07 100644
>>> --- a/drivers/gpu/drm/ttm/ttm_bo.c
>>> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
>>> @@ -651,8 +651,16 @@ static int ttm_bo_evict(struct
>>> ttm_buffer_object *bo,
>>> placement.num_busy_placement = 0;
>>> bdev->driver->evict_flags(bo, &placement);
>>> - if (!placement.num_placement && !placement.num_busy_placement)
>>> - return ttm_bo_pipeline_gutting(bo);
>>> + if (!placement.num_placement && !placement.num_busy_placement) {
>>> + ttm_bo_wait(bo, false, false);
>>> +
>>> + ttm_tt_destroy(bo->ttm);
>>> +
>>> + memset(&bo->mem, 0, sizeof(bo->mem));
>> Where does the memory in the bo->mem (ttm_mem_reg) get destroyed? It
>> doesn't get attached to a ghost BO in this case, so someone will have to
>> call ttm_bo_mem_put explicitly before you wipe out bo->mem.
>
> After migrating to ram,
> svm_range_bo_unref-->amdgpu_unref_bo->ttm_bo_put->ttm_bo_release calls
> ttm_bo_mem_put.
amdgpu_bo_unref won't free anything if the reference count doesn't go to
0. And TTM is still holding a reference here. The BO won't be freed
until ttm_mem_evict_first calls ttm_bo_put.
The memset above overwrites the ttm_mem_reg structure, which means it
will forget about the VRAM nodes held by the BO. They need to be
released first. That's what frees the space that ttm_bo_evict was trying
to make available in the first place.
Regards,
Felix
> vram is already freed before we signal fence, right?
>
> Regards,
>
> Philip
>
>> Regards,
>> Felix
>>
>>
>>> + bo->mem.mem_type = TTM_PL_SYSTEM;
>>> + bo->ttm = NULL;
>>> + return 0;
>>> + }
>>> evict_mem = bo->mem;
>>> evict_mem.mm_node = NULL;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ttm: fix pipelined gutting for evictions
On 2020-07-23 7:02 p.m., Felix Kuehling wrote:
Am 2020-07-23 um 5:00 a.m. schrieb Christian König:
We can't pipeline that during eviction because the memory needs
to be available immediately.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index bc2230ecb7e3..122040056a07 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -651,8 +651,16 @@ static int ttm_bo_evict(struct ttm_buffer_object *bo,
placement.num_busy_placement = 0;
bdev->driver->evict_flags(bo, &placement);
- if (!placement.num_placement && !placement.num_busy_placement)
- return ttm_bo_pipeline_gutting(bo);
+ if (!placement.num_placement && !placement.num_busy_placement) {
+ ttm_bo_wait(bo, false, false);
+
+ ttm_tt_destroy(bo->ttm);
+
+ memset(&bo->mem, 0, sizeof(bo->mem));
Where does the memory in the bo->mem (ttm_mem_reg) get destroyed? It
doesn't get attached to a ghost BO in this case, so someone will have to
call ttm_bo_mem_put explicitly before you wipe out bo->mem.
After migrating to ram,
svm_range_bo_unref-->amdgpu_unref_bo->ttm_bo_put->ttm_bo_release calls
ttm_bo_mem_put.
vram is already freed before we signal fence, right?
Regards,
Philip
Regards,
Felix
+ bo->mem.mem_type = TTM_PL_SYSTEM;
+ bo->ttm = NULL;
+ return 0;
+ }
evict_mem = bo->mem;
evict_mem.mm_node = NULL;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: of: Fix double-free bug
Hi Biju,
Thank you for the patch.
On Thu, Jul 23, 2020 at 12:10:54PM +0100, Biju Das wrote:
> Fix double-free bug in the error path.
>
> Fixes: 6529007522de ("drm: of: Add drm_of_lvds_get_dual_link_pixel_order")
> Reported-by: Pavel Machek
> Signed-off-by: Biju Das
> Cc: sta...@vger.kernel.org
Reviewed-by: Laurent Pinchart
> ---
> This patch is tested against drm-fixes and drm-next.
> ---
> drivers/gpu/drm/drm_of.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
> index fdb05fb..ca04c34 100644
> --- a/drivers/gpu/drm/drm_of.c
> +++ b/drivers/gpu/drm/drm_of.c
> @@ -331,10 +331,8 @@ static int drm_of_lvds_get_remote_pixels_type(
>* configurations by passing the endpoints explicitly to
>* drm_of_lvds_get_dual_link_pixel_order().
>*/
> - if (!current_pt || pixels_type != current_pt) {
> - of_node_put(remote_port);
> + if (!current_pt || pixels_type != current_pt)
> return -EINVAL;
> - }
> }
>
> return pixels_type;
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: bridge: adv7511: Add missing bridge type
Hi Vinod, Thank you for the patch. On Thu, Jul 23, 2020 at 04:15:23PM +0530, Vinod Koul wrote: > Add bridge type as DRM_MODE_CONNECTOR_HDMIA > > Signed-off-by: Vinod Koul This has already been submitted: https://lore.kernel.org/dri-devel/20200720124228.12552-1-laurentiu.pa...@oss.nxp.com/ > --- > > I found this when testing Dragon-board 410c which uses this bridge > [6.671913] msm 1a0.mdss: [drm:msm_dsi_manager_ext_bridge_init [msm]] > *ERROR* drm_bridge_connector_init failed: -22 > [6.678879] msm 1a0.mdss: [drm:msm_dsi_modeset_init [msm]] *ERROR* > failed to create dsi connector: -19 > > drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c > b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c > index f45cdca9cce5..a0d392c338da 100644 > --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c > +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c > @@ -1283,6 +1283,7 @@ static int adv7511_probe(struct i2c_client *i2c, const > struct i2c_device_id *id) > adv7511->bridge.ops = DRM_BRIDGE_OP_DETECT | DRM_BRIDGE_OP_EDID > | DRM_BRIDGE_OP_HPD; > adv7511->bridge.of_node = dev->of_node; > + adv7511->bridge.type = DRM_MODE_CONNECTOR_HDMIA; > > drm_bridge_add(&adv7511->bridge); > -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] usb: cdns3: gadget: Replace trace_printk by dev_dbg
On Thu, Jul 23, 2020 at 9:17 PM Felipe Balbi wrote:
>
> Nicolas Boichat writes:
>
> > trace_printk should not be used in production code, replace it
> > call with dev_dbg.
> >
> > Signed-off-by: Nicolas Boichat
> >
> > ---
> >
> > Unclear why a trace_printk was used in the first place, it's
> > possible that some rate-limiting is necessary here.
> >
> > drivers/usb/cdns3/gadget.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/usb/cdns3/gadget.c b/drivers/usb/cdns3/gadget.c
> > index 5e24c2e57c0d8c8..c303ab7c62d1651 100644
> > --- a/drivers/usb/cdns3/gadget.c
> > +++ b/drivers/usb/cdns3/gadget.c
> > @@ -421,7 +421,7 @@ static int cdns3_start_all_request(struct cdns3_device
> > *priv_dev,
> > if ((priv_req->flags & REQUEST_INTERNAL) ||
> > (priv_ep->flags & EP_TDLCHK_EN) ||
> > priv_ep->use_streams) {
> > - trace_printk("Blocking external request\n");
> > + dev_dbg(priv_dev->dev, "Blocking external request\n");
>
> Instead, I would suggest adding a proper trace event here; one that
> includes "priv_ep->flags" in the output.
The patch was already merged by Greg
(https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/usb/cdns3/gadget.c?id=b3a5ce874c2619c9b8a6c5bbcfefdb95e0227600),
but feel free to do that as a follow-up CL.
Looks like Peter -- the main author, is ok with dev_dbg (also,
apologies for missing the R-b tag when I sent a v2 -- which is the one
that was merged by Greg).
Thanks,
>
> --
> balbi
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ttm: fix pipelined gutting for evictions
Am 2020-07-23 um 5:00 a.m. schrieb Christian König:
> We can't pipeline that during eviction because the memory needs
> to be available immediately.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/ttm/ttm_bo.c | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index bc2230ecb7e3..122040056a07 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -651,8 +651,16 @@ static int ttm_bo_evict(struct ttm_buffer_object *bo,
> placement.num_busy_placement = 0;
> bdev->driver->evict_flags(bo, &placement);
>
> - if (!placement.num_placement && !placement.num_busy_placement)
> - return ttm_bo_pipeline_gutting(bo);
> + if (!placement.num_placement && !placement.num_busy_placement) {
> + ttm_bo_wait(bo, false, false);
> +
> + ttm_tt_destroy(bo->ttm);
> +
> + memset(&bo->mem, 0, sizeof(bo->mem));
Where does the memory in the bo->mem (ttm_mem_reg) get destroyed? It
doesn't get attached to a ghost BO in this case, so someone will have to
call ttm_bo_mem_put explicitly before you wipe out bo->mem.
Regards,
Felix
> + bo->mem.mem_type = TTM_PL_SYSTEM;
> + bo->ttm = NULL;
> + return 0;
> + }
>
> evict_mem = bo->mem;
> evict_mem.mm_node = NULL;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] amdgpu_dm: fix nonblocking atomic commit use-after-free
On Thu, Jul 23, 2020 at 09:10:15PM +, Mazin Rezk wrote:
> When amdgpu_dm_atomic_commit_tail is running in the workqueue,
> drm_atomic_state_put will get called while amdgpu_dm_atomic_commit_tail is
> running, causing a race condition where state (and then dm_state) is
> sometimes freed while amdgpu_dm_atomic_commit_tail is running. This bug has
> occurred since 5.7-rc1 and is well documented among polaris11 users [1].
>
> Prior to 5.7, this was not a noticeable issue since the freelist pointer
> was stored at the beginning of dm_state (base), which was unused. After
> changing the freelist pointer to be stored in the middle of the struct, the
> freelist pointer overwrote the context, causing dc_state to become garbage
> data and made the call to dm_enable_per_frame_crtc_master_sync dereference
> a freelist pointer.
>
> This patch fixes the aforementioned issue by calling drm_atomic_state_get
> in amdgpu_dm_atomic_commit before drm_atomic_helper_commit is called and
> drm_atomic_state_put after amdgpu_dm_atomic_commit_tail is complete.
>
> According to my testing on 5.8.0-rc6, this should fix bug 207383 on
> Bugzilla [1].
>
> [1] https://bugzilla.kernel.org/show_bug.cgi?id=207383
Nice work tracking this down!
> Fixes: 3202fa62f ("slub: relocate freelist pointer to middle of object")
I do, however, object to this Fixes tag. :) The flaw appears to have
been with amdgpu_dm's reference tracking of "state" in the nonblocking
case. (How this reference counting is supposed to work correctly, though,
I'm not sure.) If I look at where the drm helper was split from being
the default callback, it looks like this was what introduced the bug:
da5c47f682ab ("drm/amd/display: Remove acrtc->stream")
? 3202fa62f certainly exposed it much more quickly, but there was a race
even without 3202fa62f where something could have realloced the memory
and written over it.
--
Kees Cook
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] amdgpu_dm: fix nonblocking atomic commit use-after-free
On 2020-07-23 5:10 p.m., Mazin Rezk wrote:
When amdgpu_dm_atomic_commit_tail is running in the workqueue,
drm_atomic_state_put will get called while amdgpu_dm_atomic_commit_tail is
running, causing a race condition where state (and then dm_state) is
sometimes freed while amdgpu_dm_atomic_commit_tail is running. This bug has
occurred since 5.7-rc1 and is well documented among polaris11 users [1].
Prior to 5.7, this was not a noticeable issue since the freelist pointer
was stored at the beginning of dm_state (base), which was unused. After
changing the freelist pointer to be stored in the middle of the struct, the
freelist pointer overwrote the context, causing dc_state to become garbage
data and made the call to dm_enable_per_frame_crtc_master_sync dereference
a freelist pointer.
This patch fixes the aforementioned issue by calling drm_atomic_state_get
in amdgpu_dm_atomic_commit before drm_atomic_helper_commit is called and
drm_atomic_state_put after amdgpu_dm_atomic_commit_tail is complete.
According to my testing on 5.8.0-rc6, this should fix bug 207383 on
Bugzilla [1].
[1] https://bugzilla.kernel.org/show_bug.cgi?id=207383
Fixes: 3202fa62f ("slub: relocate freelist pointer to middle of object")
Reported-by: Duncan <1i5t5.dun...@cox.net>
Signed-off-by: Mazin Rezk
Thanks for the investigation and your patch. I appreciate the help in
trying to narrow down the root cause as this issue has been difficult to
reproduce on my setups.
Though I'm not sure this really resolves the issue - we make use of the
drm_atomic_helper_commit helper function from DRM which internally does
what you're doing with this patch:
drm_atomic_state_get(state);
if (nonblock)
queue_work(system_unbound_wq, &state->commit_work);
else
commit_tail(state);
So even when it gets queued off to the unbound workqueue we still have a
reference on the state.
That reference gets dropped as part of commit tail helper in DRM as well:
if (funcs && funcs->atomic_commit_tail)
funcs->atomic_commit_tail(old_state);
else
drm_atomic_helper_commit_tail(old_state);
commit_time_ms = ktime_ms_delta(ktime_get(), start);
if (commit_time_ms > 0)
drm_self_refresh_helper_update_avg_times(old_state,
(unsigned long)commit_time_ms,
new_self_refresh_mask);
drm_atomic_helper_commit_cleanup_done(old_state);
drm_atomic_state_put(old_state);
So instead of a use after free happening when we access the state we get
a double-free happening later at the end of commit tail in DRM.
What I think would be the right next step here is to actually determine
what sequence of IOCTLs and atomic commits are happening under your
setup with a very verbose dmesg log. You can set a debug level for DRM
in your kernel parameters with something like:
drm.debug=0x54
I don't see anything in amdgpu_dm.c that looks like it would be freeing
the state so I suspect something in the core is this doing this.
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 86ffa0c2880f..86d6652872f2 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -7303,6 +7303,7 @@ static int amdgpu_dm_atomic_commit(struct drm_device *dev,
* unset legacy_cursor_update
*/
+ drm_atomic_state_get(state);
Also note that if the drm_atomic_helper_commit() call fails here then
we're going to never free this structure. So we should really be
checking the return code here below before trying to do this, if at all.
Regards,
Nicholas Kazlauskas
return drm_atomic_helper_commit(dev, state, nonblock);
/*TODO Handle EINTR, reenable IRQ*/
@@ -7628,6 +7629,8 @@ static void amdgpu_dm_atomic_commit_tail(struct
drm_atomic_state *state)
if (dc_state_temp)
dc_release_state(dc_state_temp);
+
+ drm_atomic_state_put(state);
}
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 207383] [Regression] 5.7 amdgpu/polaris11 gpf: amdgpu_atomic_commit_tail
https://bugzilla.kernel.org/show_bug.cgi?id=207383 --- Comment #88 from mn...@protonmail.com --- Created attachment 290485 --> https://bugzilla.kernel.org/attachment.cgi?id=290485&action=edit Possible bug fix #1 (In reply to mnrzk from comment #87) > Good news, I wrote a patch that fixed this bug on my machine and submitted > it to the Linux kernel mailing list [1]. > > I've tested this for almost 12 hours with KASAN enabled and 3 hours with > all debugging options disabled while watching videos and there have been no > crashes. The longest it's taken for the bug to occur in the past for me was > about 1 hour. > > To anyone experiencing this bug, please test out the patch and report on > whether on not it works. I think we'll need some Tested-bys in the LKML > thread and in here before we can consider this bug fixed. > > [1] https://lkml.org/lkml/2020/7/23/1123 For convenience, I'll attach the patch here as well. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 207383] [Regression] 5.7 amdgpu/polaris11 gpf: amdgpu_atomic_commit_tail
https://bugzilla.kernel.org/show_bug.cgi?id=207383 --- Comment #87 from mn...@protonmail.com --- Good news, I wrote a patch that fixed this bug on my machine and submitted it to the Linux kernel mailing list [1]. I've tested this for almost 12 hours with KASAN enabled and 3 hours with all debugging options disabled while watching videos and there have been no crashes. The longest it's taken for the bug to occur in the past for me was about 1 hour. To anyone experiencing this bug, please test out the patch and report on whether on not it works. I think we'll need some Tested-bys in the LKML thread and in here before we can consider this bug fixed. [1] https://lkml.org/lkml/2020/7/23/1123 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/4] dt-bindings: ili9881c: add compatible string for Feixin K101-IM2BYL02
On Mon, 20 Jul 2020 01:10:04 +0800, Icenowy Zheng wrote: > Feixin K101-IM2BYL02 is a drop-in replacement of K101-IM2BA02 panel > (which is already supported by panel-feixin-k101-im2ba02 driver) with > the same pinout. It utilizes an Ilitek ILI9881C controller chip, so its > compatible string should be added to ilitek,ili9881c file. > > Add the compatible string for it. > > Signed-off-by: Icenowy Zheng > --- > .../devicetree/bindings/display/panel/ilitek,ili9881c.yaml | 1 + > 1 file changed, 1 insertion(+) > Acked-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: nouveau regression with 5.7 caused by "PCI/PM: Assume ports without DLL Link Active train links in 100 ms"
On Wed, Jul 22, 2020 at 11:25 AM Mika Westerberg wrote: > > On Tue, Jul 21, 2020 at 01:37:12PM -0500, Patrick Volkerding wrote: > > On 7/21/20 10:27 AM, Mika Westerberg wrote: > > > On Tue, Jul 21, 2020 at 11:01:55AM -0400, Lyude Paul wrote: > > >> Sure thing. Also, feel free to let me know if you'd like access to one > > >> of the > > >> systems we saw breaking with this patch - I'm fairly sure I've got one > > >> of them > > >> locally at my apartment and don't mind setting up AMT/KVM/SSH > > > Probably no need for remote access (thanks for the offer, though). I > > > attached a test patch to the bug report: > > > > > > https://bugzilla.kernel.org/show_bug.cgi?id=208597 > > > > > > that tries to work it around (based on the ->pm_cap == 0). I wonder if > > > anyone would have time to try it out. > > > > > > Hi Mika, > > > > I can confirm that this patch applied to 5.4.52 fixes the issue with > > hybrid graphics on the Thinkpad X1 Extreme gen2. > > Great, thanks for testing! > yeah, works on the P1G2 as well. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 9/9] drm/ttm: remove the init_mem_type callback
On Thu, Jul 23, 2020 at 11:17 AM Christian König
wrote:
>
> It is a very strange concept to call a function which just
> calls back the caller for the functions parameters.
>
> Signed-off-by: Christian König
Series is:
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 7 ---
> drivers/gpu/drm/drm_gem_vram_helper.c | 7 ---
> drivers/gpu/drm/nouveau/nouveau_bo.c | 8
> drivers/gpu/drm/qxl/qxl_ttm.c | 7 ---
> drivers/gpu/drm/radeon/radeon_ttm.c| 7 ---
> drivers/gpu/drm/ttm/ttm_bo.c | 4
> drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 7 ---
> include/drm/ttm/ttm_bo_driver.h| 6 --
> 8 files changed, 53 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> index 98a77fc4a90c..da6434ea07f1 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> @@ -62,12 +62,6 @@
>
> #define AMDGPU_TTM_VRAM_MAX_DW_READ(size_t)128
>
> -static int amdgpu_init_mem_type(struct ttm_bo_device *bdev, uint32_t type,
> - struct ttm_mem_type_manager *man)
> -{
> - return 0;
> -}
> -
> static int amdgpu_ttm_init_vram(struct amdgpu_device *adev)
> {
>
> @@ -1727,7 +1721,6 @@ static struct ttm_bo_driver amdgpu_bo_driver = {
> .ttm_tt_create = &amdgpu_ttm_tt_create,
> .ttm_tt_populate = &amdgpu_ttm_tt_populate,
> .ttm_tt_unpopulate = &amdgpu_ttm_tt_unpopulate,
> - .init_mem_type = &amdgpu_init_mem_type,
> .eviction_valuable = amdgpu_ttm_bo_eviction_valuable,
> .evict_flags = &amdgpu_evict_flags,
> .move = &amdgpu_bo_move,
> diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
> b/drivers/gpu/drm/drm_gem_vram_helper.c
> index f7f93a49cd7f..5f03c6137ef9 100644
> --- a/drivers/gpu/drm/drm_gem_vram_helper.c
> +++ b/drivers/gpu/drm/drm_gem_vram_helper.c
> @@ -1004,12 +1004,6 @@ static struct ttm_tt *bo_driver_ttm_tt_create(struct
> ttm_buffer_object *bo,
> return NULL;
> }
>
> -static int bo_driver_init_mem_type(struct ttm_bo_device *bdev, uint32_t type,
> - struct ttm_mem_type_manager *man)
> -{
> - return 0;
> -}
> -
> static void bo_driver_evict_flags(struct ttm_buffer_object *bo,
> struct ttm_placement *placement)
> {
> @@ -1069,7 +1063,6 @@ static struct ttm_bo_driver bo_driver = {
> .ttm_tt_create = bo_driver_ttm_tt_create,
> .ttm_tt_populate = ttm_pool_populate,
> .ttm_tt_unpopulate = ttm_pool_unpopulate,
> - .init_mem_type = bo_driver_init_mem_type,
> .eviction_valuable = ttm_bo_eviction_valuable,
> .evict_flags = bo_driver_evict_flags,
> .move_notify = bo_driver_move_notify,
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
> b/drivers/gpu/drm/nouveau/nouveau_bo.c
> index 23ef9b1aaabc..5efc572c14cc 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> @@ -646,13 +646,6 @@ nouveau_ttm_tt_create(struct ttm_buffer_object *bo,
> uint32_t page_flags)
> return nouveau_sgdma_create_ttm(bo, page_flags);
> }
>
> -static int
> -nouveau_bo_init_mem_type(struct ttm_bo_device *bdev, uint32_t type,
> -struct ttm_mem_type_manager *man)
> -{
> - return 0;
> -}
> -
> static void
> nouveau_bo_evict_flags(struct ttm_buffer_object *bo, struct ttm_placement
> *pl)
> {
> @@ -1643,7 +1636,6 @@ struct ttm_bo_driver nouveau_bo_driver = {
> .ttm_tt_create = &nouveau_ttm_tt_create,
> .ttm_tt_populate = &nouveau_ttm_tt_populate,
> .ttm_tt_unpopulate = &nouveau_ttm_tt_unpopulate,
> - .init_mem_type = nouveau_bo_init_mem_type,
> .eviction_valuable = ttm_bo_eviction_valuable,
> .evict_flags = nouveau_bo_evict_flags,
> .move_notify = nouveau_bo_move_ntfy,
> diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
> index 852089d7f783..32069e4799f3 100644
> --- a/drivers/gpu/drm/qxl/qxl_ttm.c
> +++ b/drivers/gpu/drm/qxl/qxl_ttm.c
> @@ -48,12 +48,6 @@ static struct qxl_device *qxl_get_qdev(struct
> ttm_bo_device *bdev)
> return qdev;
> }
>
> -static int qxl_init_mem_type(struct ttm_bo_device *bdev, uint32_t type,
> -struct ttm_mem_type_manager *man)
> -{
> - return 0;
> -}
> -
> static void qxl_evict_flags(struct ttm_buffer_object *bo,
> struct ttm_placement *placement)
> {
> @@ -215,7 +209,6 @@ static void qxl_bo_move_notify(struct ttm_buffer_object
> *bo,
>
> static struct ttm_bo_driver qxl_bo_driver = {
> .ttm_tt_create = &qxl_ttm_tt_create,
> - .init_mem_type = &qxl_init_mem_type,
> .eviction_valuable = ttm_bo_eviction_valuable,
> .evict_flags = &qxl_evict_flags,
> .move = &qxl_bo_move,
> diff --git a/drivers/gpu/drm/ra
Re: [PATCH] drm/amd/display: remove redundant initialization of variable result
Applied. Thanks!
Alex
On Thu, Jul 23, 2020 at 10:36 AM Colin King wrote:
>
> From: Colin Ian King
>
> The variable result is being initialized with a value that is never read
> and it is being updated later with a new value. The initialization is
> redundant and can be removed.
>
> Signed-off-by: Colin Ian King
> ---
> drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c
> b/drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c
> index 5d83e8174005..0853bc9917c7 100644
> --- a/drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c
> +++ b/drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c
> @@ -1017,7 +1017,7 @@ enum dc_status dce112_add_stream_to_ctx(
> struct dc_state *new_ctx,
> struct dc_stream_state *dc_stream)
> {
> - enum dc_status result = DC_ERROR_UNEXPECTED;
> + enum dc_status result;
>
> result = resource_map_pool_resources(dc, new_ctx, dc_stream);
>
> --
> 2.27.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH -resend] Documentation: fb, fix path to modedb.c
On Thu, 23 Jul 2020 12:34:54 +0200 Jiri Slaby wrote: > modedb.c was moved twice since the modedb documentation was written. > Update the path to the current one. > > Signed-off-by: Jiri Slaby > Cc: Bartlomiej Zolnierkiewicz > Cc: Jonathan Corbet > Cc: dri-devel@lists.freedesktop.org > Cc: linux-fb...@vger.kernel.org > Cc: linux-...@vger.kernel.org > --- > Documentation/fb/modedb.rst | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Documentation/fb/modedb.rst b/Documentation/fb/modedb.rst > index 624d08fd2856..4d2411e32ebb 100644 > --- a/Documentation/fb/modedb.rst > +++ b/Documentation/fb/modedb.rst > @@ -152,7 +152,7 @@ To specify a video mode at bootup, use the following boot > options:: > video=:x[-][@refresh] > > where is a name from the table below. Valid default modes can be > -found in linux/drivers/video/modedb.c. Check your driver's documentation. > +found in drivers/video/fbdev/core/modedb.c. Check your driver's > documentation. > There may be more modes:: "resend" but I've never seen it before...in any case I've applied it now. Thanks, jon ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/2] dt-bindings: display: panel: Add bindings for Tianma nt36672a panel
On Wed, Jul 22, 2020 at 11:28:15AM +0530, Sumit Semwal wrote:
> The nt36672a panel from Tianma is a FHD+ panel with a resolution of 1080x2246
> and 6.18 inches size. It is found in some of the Poco F1 phones.
>
> Signed-off-by: Sumit Semwal
> Change-Id: I401dfbfe23ff2d806c956002f45e349cb9688c16
You know better...
> ---
> v2: remove ports node, making port@0 directly under panel@0 node.
> ---
> .../display/panel/tianma,nt36672a.yaml| 104 ++
> 1 file changed, 104 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
> b/Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
> new file mode 100644
> index ..cb1799fbbd32
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
> @@ -0,0 +1,104 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/panel/tianma,nt36672a.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Tianma model NT36672A DSI Panel display driver
> +
> +maintainers:
> + - Sumit Semwal
> +
> +description: |
> + The nt36672a panel from Tianma is a FHD+ LCD display panel with a
> resolution
> + of 1080x2246. It is a video mode DSI panel.
> +
> +allOf:
> + - $ref: panel-common.yaml#
> +
> +properties:
> + compatible:
> +const: tianma,nt36672a
> +
> + reg:
> +description: DSI virtual channel of the peripheral
> +
> + reset-gpios:
> +description: phandle of gpio for reset line - This should be 8mA, gpio
> + can be configured using mux, pinctrl, pinctrl-names (active high)
> +
> + vddio-supply:
> +description: phandle of the regulator that provides the supply voltage
> + Power IC supply
> +
> + vddpos-supply:
> +description: phandle of the positive boost supply regulator
> +
> + vddneg-supply:
> +description: phandle of the negative boost supply regulator
> +
> + pinctrl-names:
> +description: Pinctrl for panel active and suspend
> +
> + pinctrl-0:
> +description: Active pinctrls
> +
> + pinctrl-1:
> +description: Suspend pinctrls
> +
> + port@0:
Just 'port' as there can only be 1 in this case.
You can do just: 'port: true' as panel-common.yaml already has a
definition.
> +type: object
> +description: DSI input port driven by master DSI
> +properties:
> + reg:
> +const: 0
> +
> +required:
> + - reg
> +
> +required:
> + - compatible
> + - reg
> + - vddi0-supply
> + - vddpos-supply
> + - vddneg-supply
> + - reset-gpios
> + - pinctrl-names
> + - pinctrl-0
> + - pinctrl-1
> + - port@0
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |+
> +#include
> +dsi0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + panel@0 {
> +compatible = "tianma,nt36672a";
> +reg = <0>;
> +vddi0-supply = <&vreg_l14a_1p88>;
> +vddpos-supply = <&lab>;
> +vddneg-supply = <&ibb>;
> +
> +reset-gpios = <&tlmm 6 GPIO_ACTIVE_HIGH>;
> +
> +pinctrl-names = "panel_active", "panel_suspend";
> +pinctrl-0 = <&sde_dsi_active>;
> +pinctrl-1 = <&sde_dsi_suspend>;
> +
> +#address-cells = <1>;
> +#size-cells = <0>;
> +port@0 {
> + reg = <0>;
> + tianma_nt36672a_in_0: endpoint {
> +remote-endpoint = <&dsi0_out>;
> + };
> +};
> + };
> +};
> +
> +...
> --
> 2.27.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH 2/3] drm/i915/gem: Move context decoupling from postclose to preclose
Quoting Tang, CQ (2020-07-23 18:44:08)
>
>
> > -Original Message-
> > From: Chris Wilson
> > Sent: Thursday, July 23, 2020 10:21 AM
> > To: intel-...@lists.freedesktop.org
> > Cc: dri-devel@lists.freedesktop.org; Chris Wilson
> > ;
> > Tang, CQ ; Vetter, Daniel ;
> > sta...@vger.kernel.org
> > Subject: [PATCH 2/3] drm/i915/gem: Move context decoupling from
> > postclose to preclose
> >
> > Since the GEM contexts refer to other GEM state, we need to nerf those
> > pointers before that state is freed during drm_gem_release(). We need to
> > move i915_gem_context_close() from the postclose callback to the preclose.
> >
> > In particular, debugfs likes to peek into the GEM contexts, and from there
> > peek at the drm core objects. If the context is closed during the peeking,
> > we
> > may attempt to dereference a stale core object.
> >
> > Signed-off-by: Chris Wilson
> > Cc: CQ Tang
> > Cc: Daniel Vetter
> > Cc: sta...@vger.kernel.org
> > ---
> > drivers/gpu/drm/i915/i915_drv.c | 7 ++-
> > 1 file changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c
> > b/drivers/gpu/drm/i915/i915_drv.c index 5fd5af4bc855..15242a8c70f7 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -1114,11 +1114,15 @@ static void i915_driver_lastclose(struct
> > drm_device *dev)
> > vga_switcheroo_process_delayed_switch();
> > }
> >
> > +static void i915_driver_preclose(struct drm_device *dev, struct
> > +drm_file *file) {
> > + i915_gem_context_close(file);
> > +}
> > +
> > static void i915_driver_postclose(struct drm_device *dev, struct drm_file
> > *file) {
> > struct drm_i915_file_private *file_priv = file->driver_priv;
> >
> > - i915_gem_context_close(file);
> > i915_gem_release(dev, file);
>
> Now we separate i915_gem_context_close() from i915_gem_release() and other
> freeing code in postclose(), is there any side effect to allow code to run in
> between?
> Can we move all postclose() code into preclose()?
i915_gem_release() is scheduled for deletion, so I didn't care. What
remains in postclose are the kfree + tidyup, which seem like a good idea
to keep last.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH 2/3] drm/i915/gem: Move context decoupling from postclose to preclose
> -Original Message-
> From: Chris Wilson
> Sent: Thursday, July 23, 2020 10:21 AM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; Chris Wilson ;
> Tang, CQ ; Vetter, Daniel ;
> sta...@vger.kernel.org
> Subject: [PATCH 2/3] drm/i915/gem: Move context decoupling from
> postclose to preclose
>
> Since the GEM contexts refer to other GEM state, we need to nerf those
> pointers before that state is freed during drm_gem_release(). We need to
> move i915_gem_context_close() from the postclose callback to the preclose.
>
> In particular, debugfs likes to peek into the GEM contexts, and from there
> peek at the drm core objects. If the context is closed during the peeking, we
> may attempt to dereference a stale core object.
>
> Signed-off-by: Chris Wilson
> Cc: CQ Tang
> Cc: Daniel Vetter
> Cc: sta...@vger.kernel.org
> ---
> drivers/gpu/drm/i915/i915_drv.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c
> b/drivers/gpu/drm/i915/i915_drv.c index 5fd5af4bc855..15242a8c70f7 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1114,11 +1114,15 @@ static void i915_driver_lastclose(struct
> drm_device *dev)
> vga_switcheroo_process_delayed_switch();
> }
>
> +static void i915_driver_preclose(struct drm_device *dev, struct
> +drm_file *file) {
> + i915_gem_context_close(file);
> +}
> +
> static void i915_driver_postclose(struct drm_device *dev, struct drm_file
> *file) {
> struct drm_i915_file_private *file_priv = file->driver_priv;
>
> - i915_gem_context_close(file);
> i915_gem_release(dev, file);
Now we separate i915_gem_context_close() from i915_gem_release() and other
freeing code in postclose(), is there any side effect to allow code to run in
between?
Can we move all postclose() code into preclose()?
--CQ
>
> kfree_rcu(file_priv, rcu);
> @@ -1850,6 +1854,7 @@ static struct drm_driver driver = {
> .release = i915_driver_release,
> .open = i915_driver_open,
> .lastclose = i915_driver_lastclose,
> + .preclose = i915_driver_preclose,
> .postclose = i915_driver_postclose,
>
> .gem_close_object = i915_gem_close_object,
> --
> 2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] drm: Restore driver.preclose() for all to use
An unfortunate sequence of events, but it turns out there is a valid
usecase for being able to free/decouple the driver objects before they
are freed by the DRM core. In particular, if we have a pointer into a
drm core object from inside a driver object, that pointer needs to be
nerfed *before* it is freed so that concurrent access (e.g. debugfs)
does not following the dangling pointer.
The legacy marker was adding in the code movement from drp_fops.c to
drm_file.c
References: 9acdac68bcdc ("drm: rename drm_fops.c to drm_file.c")
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
Cc: Gustavo Padovan
Cc: CQ Tang
Cc: # v4.12+
---
drivers/gpu/drm/drm_file.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index 0ac4566ae3f4..7b4258d6f7cc 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -258,8 +258,7 @@ void drm_file_free(struct drm_file *file)
(long)old_encode_dev(file->minor->kdev->devt),
atomic_read(&dev->open_count));
- if (drm_core_check_feature(dev, DRIVER_LEGACY) &&
- dev->driver->preclose)
+ if (dev->driver->preclose)
dev->driver->preclose(dev, file);
if (drm_core_check_feature(dev, DRIVER_LEGACY))
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm/i915/gem: Serialise debugfs i915_gem_objects with ctx->mutex
Since the debugfs may peek into the GEM contexts as the corresponding
client/fd is being closed, we may try and follow a dangling pointer.
However, the context closure itself is serialised with the ctx->mutex,
so if we hold that mutex as we inspect the state coupled in the context,
we know the pointers within the context are stable and will remain valid
as we inspect their tables.
Signed-off-by: Chris Wilson
Cc: CQ Tang
Cc: Daniel Vetter
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 784219962193..ea469168cd44 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -326,6 +326,7 @@ static void print_context_stats(struct seq_file *m,
}
i915_gem_context_unlock_engines(ctx);
+ mutex_lock(&ctx->mutex);
if (!IS_ERR_OR_NULL(ctx->file_priv)) {
struct file_stats stats = {
.vm = rcu_access_pointer(ctx->vm),
@@ -346,6 +347,7 @@ static void print_context_stats(struct seq_file *m,
print_file_stats(m, name, stats);
}
+ mutex_unlock(&ctx->mutex);
spin_lock(&i915->gem.contexts.lock);
list_safe_reset_next(ctx, cn, link);
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] drm/i915/gem: Move context decoupling from postclose to preclose
Since the GEM contexts refer to other GEM state, we need to nerf those
pointers before that state is freed during drm_gem_release(). We need to
move i915_gem_context_close() from the postclose callback to the
preclose.
In particular, debugfs likes to peek into the GEM contexts, and from
there peek at the drm core objects. If the context is closed during the
peeking, we may attempt to dereference a stale core object.
Signed-off-by: Chris Wilson
Cc: CQ Tang
Cc: Daniel Vetter
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/i915/i915_drv.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 5fd5af4bc855..15242a8c70f7 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1114,11 +1114,15 @@ static void i915_driver_lastclose(struct drm_device
*dev)
vga_switcheroo_process_delayed_switch();
}
+static void i915_driver_preclose(struct drm_device *dev, struct drm_file *file)
+{
+ i915_gem_context_close(file);
+}
+
static void i915_driver_postclose(struct drm_device *dev, struct drm_file
*file)
{
struct drm_i915_file_private *file_priv = file->driver_priv;
- i915_gem_context_close(file);
i915_gem_release(dev, file);
kfree_rcu(file_priv, rcu);
@@ -1850,6 +1854,7 @@ static struct drm_driver driver = {
.release = i915_driver_release,
.open = i915_driver_open,
.lastclose = i915_driver_lastclose,
+ .preclose = i915_driver_preclose,
.postclose = i915_driver_postclose,
.gem_close_object = i915_gem_close_object,
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] video: fbdev: fix setting of pixclock because a pass-by-value error
From: Colin Ian King
The pixclock is being set locally because it is being passed as a
pass-by-value argument rather than pass-by-reference, so the computed
pixclock is never being set in var->pixclock. Fix this by passing
by reference.
[This dates back to 2002, I found the offending commit from the git
history git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git ]
Addresses-Coverity: ("Unused value")
Fixes: 115f4504a64a ("Removed currcon and other console related code. Very
little is now left.")
Signed-off-by: Colin Ian King
---
drivers/video/fbdev/vga16fb.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/video/fbdev/vga16fb.c b/drivers/video/fbdev/vga16fb.c
index a20eeb8308ff..52f273af6cae 100644
--- a/drivers/video/fbdev/vga16fb.c
+++ b/drivers/video/fbdev/vga16fb.c
@@ -243,7 +243,7 @@ static void vga16fb_update_fix(struct fb_info *info)
}
static void vga16fb_clock_chip(struct vga16fb_par *par,
- unsigned int pixclock,
+ unsigned int *pixclock,
const struct fb_info *info,
int mul, int div)
{
@@ -259,14 +259,14 @@ static void vga16fb_clock_chip(struct vga16fb_par *par,
{ 0 /* bad */,0x00, 0x00}};
int err;
- pixclock = (pixclock * mul) / div;
+ *pixclock = (*pixclock * mul) / div;
best = vgaclocks;
- err = pixclock - best->pixclock;
+ err = *pixclock - best->pixclock;
if (err < 0) err = -err;
for (ptr = vgaclocks + 1; ptr->pixclock; ptr++) {
int tmp;
- tmp = pixclock - ptr->pixclock;
+ tmp = *pixclock - ptr->pixclock;
if (tmp < 0) tmp = -tmp;
if (tmp < err) {
err = tmp;
@@ -275,7 +275,7 @@ static void vga16fb_clock_chip(struct vga16fb_par *par,
}
par->misc |= best->misc;
par->clkdiv = best->seq_clock_mode;
- pixclock = (best->pixclock * div) / mul;
+ *pixclock = (best->pixclock * div) / mul;
}
#define FAIL(X) return -EINVAL
@@ -497,10 +497,10 @@ static int vga16fb_check_var(struct fb_var_screeninfo
*var,
if (mode & MODE_8BPP)
/* pixel clock == vga clock / 2 */
- vga16fb_clock_chip(par, var->pixclock, info, 1, 2);
+ vga16fb_clock_chip(par, &var->pixclock, info, 1, 2);
else
/* pixel clock == vga clock */
- vga16fb_clock_chip(par, var->pixclock, info, 1, 1);
+ vga16fb_clock_chip(par, &var->pixclock, info, 1, 1);
var->red.offset = var->green.offset = var->blue.offset =
var->transp.offset = 0;
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [v7, PATCH 4/7] dt-bindings: mediatek: add rdma_fifo_size description for mt8183 display
On Thu, Jul 23, 2020 at 10:03:15AM +0800, Yongqiang Niu wrote:
> Update device tree binding document for rdma_fifo_size
>
> Signed-off-by: Yongqiang Niu
> ---
> .../devicetree/bindings/display/mediatek/mediatek,disp.txt | 14
> ++
> 1 file changed, 14 insertions(+)
>
> diff --git
> a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
> b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
> index b91e709..e6bbe32 100644
> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
> @@ -66,6 +66,11 @@ Required properties (DMA function blocks):
>argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
>for details.
>
> +Optional properties (RDMA function blocks):
> +- mediatek,rdma_fifo_size: rdma fifo size may be different even in same SOC,
> add this
s/_/-/
> + property to the corresponding rdma
> + the value is the Max value which defined in hardware data sheet.
> +
> Examples:
>
> mmsys: clock-controller@1400 {
> @@ -207,3 +212,12 @@ od@14023000 {
> power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
> clocks = <&mmsys CLK_MM_DISP_OD>;
> };
> +
> +rdma1: rdma@1400c000 {
> + compatible = "mediatek,mt8183-disp-rdma";
> + reg = <0 0x1400c000 0 0x1000>;
> + interrupts = ;
> + power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
> + clocks = <&mmsys CLK_MM_DISP_RDMA1>;
> + mediatek,rdma_fifo_size = <2048>;
> +};
> --
> 1.8.1.1.dirty
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 3/3] drm/bridge: Introduce LT9611 DSI to HDMI bridge
Lontium Lt9611 is a DSI to HDMI bridge which supports two DSI ports and
I2S port as an input and HDMI port as output
Co-developed-by: Bjorn Andersson
Signed-off-by: Bjorn Andersson
Co-developed-by: Srinivas Kandagatla
Signed-off-by: Srinivas Kandagatla
Tested-by: John Stultz
Signed-off-by: Vinod Koul
---
drivers/gpu/drm/bridge/Kconfig | 13 +
drivers/gpu/drm/bridge/Makefile |1 +
drivers/gpu/drm/bridge/lontium-lt9611.c | 1229 +++
3 files changed, 1243 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/lontium-lt9611.c
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 43271c21d3fc..c7f0dacfb57a 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -48,6 +48,19 @@ config DRM_DISPLAY_CONNECTOR
on ARM-based platforms. Saying Y here when this driver is not needed
will not cause any issue.
+config DRM_LONTIUM_LT9611
+ tristate "Lontium LT9611 DSI/HDMI bridge"
+ select SND_SOC_HDMI_CODEC if SND_SOC
+ depends on OF
+ select DRM_PANEL_BRIDGE
+ select DRM_KMS_HELPER
+ select REGMAP_I2C
+ help
+ Driver for Lontium LT9611 DSI to HDMI bridge
+ chip driver that converts dual DSI and I2S to
+ HDMI signals
+ Please say Y if you have such hardware.
+
config DRM_LVDS_CODEC
tristate "Transparent LVDS encoders and decoders support"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index d63d4b7e4347..7d7c123a95e4 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -2,6 +2,7 @@
obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
obj-$(CONFIG_DRM_CHRONTEL_CH7033) += chrontel-ch7033.o
obj-$(CONFIG_DRM_DISPLAY_CONNECTOR) += display-connector.o
+obj-$(CONFIG_DRM_LONTIUM_LT9611) += lontium-lt9611.o
obj-$(CONFIG_DRM_LVDS_CODEC) += lvds-codec.o
obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) +=
megachips-stdp-ge-b850v3-fw.o
obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
diff --git a/drivers/gpu/drm/bridge/lontium-lt9611.c
b/drivers/gpu/drm/bridge/lontium-lt9611.c
new file mode 100644
index ..2904567c87e0
--- /dev/null
+++ b/drivers/gpu/drm/bridge/lontium-lt9611.c
@@ -0,0 +1,1229 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2019-2020. Linaro Limited.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#define EDID_SEG_SIZE 256
+#define EDID_LEN 32
+#define EDID_LOOP 8
+#define KEY_DDC_ACCS_DONE 0x02
+#define DDC_NO_ACK 0x50
+
+#define LT9611_4LANES 0
+
+struct lt9611 {
+ struct device *dev;
+ struct drm_bridge bridge;
+ struct drm_connector connector;
+
+ struct regmap *regmap;
+
+ struct device_node *dsi0_node;
+ struct device_node *dsi1_node;
+ struct mipi_dsi_device *dsi0;
+ struct mipi_dsi_device *dsi1;
+ struct platform_device *audio_pdev;
+
+ bool ac_mode;
+
+ struct gpio_desc *reset_gpio;
+ struct gpio_desc *enable_gpio;
+
+ bool power_on;
+ bool sleep;
+
+ struct regulator_bulk_data supplies[2];
+
+ struct i2c_client *client;
+
+ enum drm_connector_status status;
+
+ u8 edid_buf[EDID_SEG_SIZE];
+ u32 vic;
+};
+
+#define LT9611_PAGE_CONTROL0xff
+
+static const struct regmap_range_cfg lt9611_ranges[] = {
+ {
+ .name = "register_range",
+ .range_min = 0,
+ .range_max = 0x85ff,
+ .selector_reg = LT9611_PAGE_CONTROL,
+ .selector_mask = 0xff,
+ .selector_shift = 0,
+ .window_start = 0,
+ .window_len = 0x100,
+ },
+};
+
+static const struct regmap_config lt9611_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .max_register = 0x,
+ .ranges = lt9611_ranges,
+ .num_ranges = ARRAY_SIZE(lt9611_ranges),
+};
+
+struct lt9611_mode {
+ u16 hdisplay;
+ u16 vdisplay;
+ u8 vrefresh;
+ u8 lanes;
+ u8 intfs;
+};
+
+static struct lt9611_mode lt9611_modes[] = {
+ { 3840, 2160, 30, 4, 2 }, /* 3840x2160 24bit 30Hz 4Lane 2ports */
+ { 1920, 1080, 60, 4, 1 }, /* 1080P 24bit 60Hz 4lane 1port */
+ { 1920, 1080, 30, 3, 1 }, /* 1080P 24bit 30Hz 3lane 1port */
+ { 1920, 1080, 24, 3, 1 },
+ { 720, 480, 60, 4, 1 },
+ { 720, 576, 50, 2, 1 },
+ { 640, 480, 60, 2, 1 },
+};
+
+static struct lt9611 *bridge_to_lt9611(struct drm_bridge *bridge)
+{
+ return container_of(bridge, struct lt9611, bridge);
+}
+
+static struct lt9611 *connector_to_lt9611(struct drm_connector *connector)
+{
+ return container_of(connector, struct lt9611, connector);
+}
+
+static int lt9611_mipi_input_analog(st
[PATCH v6 2/3] dt-bindings: display: bridge: Add documentation for LT9611
Lontium LT9611 is a DSI to HDMI bridge which supports 2 DSI ports
and I2S port as input and one HDMI port as output
Reviewed-by: Rob Herring
Tested-by: John Stultz
Signed-off-by: Vinod Koul
---
.../display/bridge/lontium,lt9611.yaml| 176 ++
1 file changed, 176 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
diff --git
a/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
b/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
new file mode 100644
index ..d60208359234
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
@@ -0,0 +1,176 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/lontium,lt9611.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Lontium LT9611 2 Port MIPI to HDMI Bridge
+
+maintainers:
+ - Vinod Koul
+
+description: |
+ The LT9611 is a bridge device which converts DSI to HDMI
+
+properties:
+ compatible:
+enum:
+ - lontium,lt9611
+
+ reg:
+maxItems: 1
+
+ "#sound-dai-cells":
+const: 1
+
+ interrupts:
+maxItems: 1
+
+ reset-gpios:
+maxItems: 1
+description: GPIO connected to active high RESET pin.
+
+ vdd-supply:
+description: Regulator for 1.8V MIPI phy power.
+
+ vcc-supply:
+description: Regulator for 3.3V IO power.
+
+ ports:
+type: object
+
+properties:
+ "#address-cells":
+const: 1
+
+ "#size-cells":
+const: 0
+
+ port@0:
+type: object
+description: |
+ Primary MIPI port-1 for MIPI input
+
+properties:
+ reg:
+const: 0
+
+patternProperties:
+ "^endpoint(@[0-9])$":
+type: object
+additionalProperties: false
+
+properties:
+ remote-endpoint:
+$ref: /schemas/types.yaml#/definitions/phandle
+
+required:
+ - reg
+
+ port@1:
+type: object
+description: |
+ Additional MIPI port-2 for MIPI input, used in combination
+ with primary MIPI port-1 to drive higher resolution displays
+
+properties:
+ reg:
+const: 1
+
+patternProperties:
+ "^endpoint(@[0-9])$":
+type: object
+additionalProperties: false
+
+properties:
+ remote-endpoint:
+$ref: /schemas/types.yaml#/definitions/phandle
+
+required:
+ - reg
+
+ port@2:
+type: object
+description: |
+ HDMI port for HDMI output
+
+properties:
+ reg:
+const: 2
+
+patternProperties:
+ "^endpoint(@[0-9])$":
+type: object
+additionalProperties: false
+
+properties:
+ remote-endpoint:
+$ref: /schemas/types.yaml#/definitions/phandle
+
+required:
+ - reg
+
+required:
+ - "#address-cells"
+ - "#size-cells"
+ - port@0
+ - port@2
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - vdd-supply
+ - vcc-supply
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+
+i2c10 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ hdmi-bridge@3b {
+compatible = "lontium,lt9611";
+reg = <0x3b>;
+
+reset-gpios = <&tlmm 128 GPIO_ACTIVE_HIGH>;
+interrupts-extended = <&tlmm 84 IRQ_TYPE_EDGE_FALLING>;
+
+vdd-supply = <<9611_1v8>;
+vcc-supply = <<9611_3v3>;
+
+ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+reg = <0>;
+lt9611_a: endpoint {
+ remote-endpoint = <&dsi0_out>;
+};
+ };
+
+ port@1 {
+reg = <1>;
+lt9611_b: endpoint {
+ remote-endpoint = <&dsi1_out>;
+};
+ };
+
+ port@2 {
+reg = <2>;
+lt9611_out: endpoint {
+ remote-endpoint = <&hdmi_con>;
+};
+ };
+};
+ };
+};
+
+...
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 1/3] dt-bindings: vendor-prefixes: Add Lontium vendor prefix
Add prefix for Lontium Semiconductor Corporation Acked-by: Rob Herring Tested-by: John Stultz Signed-off-by: Vinod Koul --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 9aeab66be85f..31cdb21a3d22 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -595,6 +595,8 @@ patternProperties: description: Logic Technologies Limited "^longcheer,.*": description: Longcheer Technology (Shanghai) Co., Ltd. + "^lontium,.*": +description: Lontium Semiconductor Corporation "^loongson,.*": description: Loongson Technology Corporation Limited "^lsi,.*": -- 2.26.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 0/3] Add LT9611 DSI to HDMI bridge
Hi, This series adds driver and bindings for Lontium LT9611 bridge chip which takes MIPI DSI as input and HDMI as output. This chip can be found in 96boards RB3 platform [1] commonly called DB845c. [1]: https://www.96boards.org/product/rb3-platform/ Changes in v6: - Drop msm/dsi patch as we need to get more bridges fixed before we add that - Bring back support for DRM_BRIDGE_ATTACH_NO_CONNECTOR not set, now driver supports both - Fix nits found by Sam Changes in v5: - make symbol static, reported by kbuild-bot Changes in v4: - Add msm/dsi patch to create connector and support DRM_BRIDGE_ATTACH_NO_CONNECTOR - Fix comments provided by Sam Changes in v3: - fix kbuild reported error - rebase on v5.8-rc1 Changes in v2: - Add acks by Rob - Fix comments reported by Emil and rename the file to lontium-lt9611.c - Fix comments reported by Laurent on binding and driver - Add HDMI audio support Vinod Koul (3): dt-bindings: vendor-prefixes: Add Lontium vendor prefix dt-bindings: display: bridge: Add documentation for LT9611 drm/bridge: Introduce LT9611 DSI to HDMI bridge .../display/bridge/lontium,lt9611.yaml| 176 +++ .../devicetree/bindings/vendor-prefixes.yaml |2 + drivers/gpu/drm/bridge/Kconfig| 13 + drivers/gpu/drm/bridge/Makefile |1 + drivers/gpu/drm/bridge/lontium-lt9611.c | 1229 + 5 files changed, 1421 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml create mode 100644 drivers/gpu/drm/bridge/lontium-lt9611.c -- 2.26.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [v7, PATCH 1/7] drm/mediatek: move ddp component defint into mtk_mmsys.h
Yongqiang Niu 於 2020年7月23日 週四 下午6:06寫道：
>
> On Thu, 2020-07-23 at 11:34 +0200, Enric Balletbo Serra wrote:
> > Hi Yongqian Niu,
> >
> > Thank you for your patch
> >
> > Missatge de Yongqiang Niu del dia dj., 23
> > de jul. 2020 a les 4:05:
> > >
> > > move ddp component defint into mtk_mmsys.h
> > >
> >
> > There is a typo, should be "defines". But why you should move these
> > defines to mtk-mmsys?
> >
>
> ck do not like this :
> > -#include "../../gpu/drm/mediatek/mtk_drm_ddp.h"
> > -#include "../../gpu/drm/mediatek/mtk_drm_ddp_comp.h"
I think no one like this.
>
> after remove this, we need move the ddp component define
>
> type error will fixed in next version.
>
mmsys is the driver which control the routing of these ddp component,
so the definition of mtk_ddp_comp_id should be placed in mtk-mmsys.h
Regards,
Chun-Kuang.
>
> >
> >
> > > Signed-off-by: Yongqiang Niu
> > > ---
> > > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 34
> > > +
> > > drivers/soc/mediatek/mtk-mmsys.c| 4 +---
> > > include/linux/soc/mediatek/mtk-mmsys.h | 33
> > >
> > > 3 files changed, 35 insertions(+), 36 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> > > b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> > > index debe363..161201f 100644
> > > --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> > > +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> > > @@ -7,6 +7,7 @@
> > > #define MTK_DRM_DDP_COMP_H
> > >
> > > #include
> > > +#include
> > >
> > > struct device;
> > > struct device_node;
> > > @@ -35,39 +36,6 @@ enum mtk_ddp_comp_type {
> > > MTK_DDP_COMP_TYPE_MAX,
> > > };
> > >
> > > -enum mtk_ddp_comp_id {
> > > - DDP_COMPONENT_AAL0,
> > > - DDP_COMPONENT_AAL1,
> > > - DDP_COMPONENT_BLS,
> > > - DDP_COMPONENT_CCORR,
> > > - DDP_COMPONENT_COLOR0,
> > > - DDP_COMPONENT_COLOR1,
> > > - DDP_COMPONENT_DITHER,
> > > - DDP_COMPONENT_DPI0,
> > > - DDP_COMPONENT_DPI1,
> > > - DDP_COMPONENT_DSI0,
> > > - DDP_COMPONENT_DSI1,
> > > - DDP_COMPONENT_DSI2,
> > > - DDP_COMPONENT_DSI3,
> > > - DDP_COMPONENT_GAMMA,
> > > - DDP_COMPONENT_OD0,
> > > - DDP_COMPONENT_OD1,
> > > - DDP_COMPONENT_OVL0,
> > > - DDP_COMPONENT_OVL_2L0,
> > > - DDP_COMPONENT_OVL_2L1,
> > > - DDP_COMPONENT_OVL1,
> > > - DDP_COMPONENT_PWM0,
> > > - DDP_COMPONENT_PWM1,
> > > - DDP_COMPONENT_PWM2,
> > > - DDP_COMPONENT_RDMA0,
> > > - DDP_COMPONENT_RDMA1,
> > > - DDP_COMPONENT_RDMA2,
> > > - DDP_COMPONENT_UFOE,
> > > - DDP_COMPONENT_WDMA0,
> > > - DDP_COMPONENT_WDMA1,
> > > - DDP_COMPONENT_ID_MAX,
> > > -};
> > > -
> > > struct mtk_ddp_comp;
> > > struct cmdq_pkt;
> > > struct mtk_ddp_comp_funcs {
> > > diff --git a/drivers/soc/mediatek/mtk-mmsys.c
> > > b/drivers/soc/mediatek/mtk-mmsys.c
> > > index a55f255..36ad66b 100644
> > > --- a/drivers/soc/mediatek/mtk-mmsys.c
> > > +++ b/drivers/soc/mediatek/mtk-mmsys.c
> > > @@ -5,13 +5,11 @@
> > > */
> > >
> > > #include
> > > +#include
> > > #include
> > > #include
> > > #include
> > >
> > > -#include "../../gpu/drm/mediatek/mtk_drm_ddp.h"
> > > -#include "../../gpu/drm/mediatek/mtk_drm_ddp_comp.h"
> > > -
> > > #define DISP_REG_CONFIG_DISP_OVL0_MOUT_EN 0x040
> > > #define DISP_REG_CONFIG_DISP_OVL1_MOUT_EN 0x044
> > > #define DISP_REG_CONFIG_DISP_OD_MOUT_EN0x048
> > > diff --git a/include/linux/soc/mediatek/mtk-mmsys.h
> > > b/include/linux/soc/mediatek/mtk-mmsys.h
> > > index 7bab5d9..2228bf6 100644
> > > --- a/include/linux/soc/mediatek/mtk-mmsys.h
> > > +++ b/include/linux/soc/mediatek/mtk-mmsys.h
> > > @@ -9,6 +9,39 @@
> > > enum mtk_ddp_comp_id;
> > > struct device;
> > >
> > > +enum mtk_ddp_comp_id {
> > > + DDP_COMPONENT_AAL0,
> > > + DDP_COMPONENT_AAL1,
> > > + DDP_COMPONENT_BLS,
> > > + DDP_COMPONENT_CCORR,
> > > + DDP_COMPONENT_COLOR0,
> > > + DDP_COMPONENT_COLOR1,
> > > + DDP_COMPONENT_DITHER,
> > > + DDP_COMPONENT_DPI0,
> > > + DDP_COMPONENT_DPI1,
> > > + DDP_COMPONENT_DSI0,
> > > + DDP_COMPONENT_DSI1,
> > > + DDP_COMPONENT_DSI2,
> > > + DDP_COMPONENT_DSI3,
> > > + DDP_COMPONENT_GAMMA,
> > > + DDP_COMPONENT_OD0,
> > > + DDP_COMPONENT_OD1,
> > > + DDP_COMPONENT_OVL0,
> > > + DDP_COMPONENT_OVL_2L0,
> > > + DDP_COMPONENT_OVL_2L1,
> > > + DDP_COMPONENT_OVL1,
> > > + DDP_COMPONENT_PWM0,
> > > + DDP_COMPONENT_PWM1,
> > > + DDP_COMPONENT_PWM2,
> > > + DDP_COMPONENT_RDMA0,
> > > + DDP_COMPONENT_RDMA1,
> > > + DDP_COMPONENT_RDMA2,
> > > + DDP_COMPONENT_UFOE,
> > > + DDP_COMPONENT_WDMA0,
> > > + DDP_COMPONENT_WDMA1,
> > > + DDP_COMPONENT_ID_MAX,
> > > +};
> > > +
> > > void mtk_mmsys_ddp_
[Bug 208661] Backlight doesn't work with both nv_backlight and acpi_video
https://bugzilla.kernel.org/show_bug.cgi?id=208661 Ilia Mirkin (imir...@alum.mit.edu) changed: What|Removed |Added CC||imir...@alum.mit.edu --- Comment #3 from Ilia Mirkin (imir...@alum.mit.edu) --- So given that this works via acpi_video with NVIDIA's drivers, this suggests to me that nouveau is either doing something it shouldn't, which breaks the acpi method, or it doesn't do something which enables the acpi method to work. Unfortunately I'm not an expert on the ACPI stuff, so we need to 1. Figure out how acpi_video works (BCL method? something like that) 2. Find the method in the acpi dump, and decode it 3. Profit... -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [v7, PATCH 5/7] arm64: dts: add display nodes for mt8183
On 23/07/2020 04:03, Yongqiang Niu wrote:
This patch add display nodes for mt8183
In comparison, DTS patches should go last in a series as you will need the
driver patches to make it work.
Regards,
Matthias
Signed-off-by: Yongqiang Niu
---
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 98
1 file changed, 98 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index 7b781eb..440cf22 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -31,6 +31,11 @@
i2c9 = &i2c9;
i2c10 = &i2c10;
i2c11 = &i2c11;
+ ovl0 = &ovl0;
+ ovl_2l0 = &ovl_2l0;
+ ovl_2l1 = &ovl_2l1;
+ rdma0 = &rdma0;
+ rdma1 = &rdma1;
};
cpus {
@@ -707,9 +712,102 @@
mmsys: syscon@1400 {
compatible = "mediatek,mt8183-mmsys", "syscon";
reg = <0 0x1400 0 0x1000>;
+ power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
#clock-cells = <1>;
};
+ ovl0: ovl@14008000 {
+ compatible = "mediatek,mt8183-disp-ovl";
+ reg = <0 0x14008000 0 0x1000>;
+ interrupts = ;
+ power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
+ clocks = <&mmsys CLK_MM_DISP_OVL0>;
+ };
+
+ ovl_2l0: ovl@14009000 {
+ compatible = "mediatek,mt8183-disp-ovl-2l";
+ reg = <0 0x14009000 0 0x1000>;
+ interrupts = ;
+ power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
+ clocks = <&mmsys CLK_MM_DISP_OVL0_2L>;
+ };
+
+ ovl_2l1: ovl@1400a000 {
+ compatible = "mediatek,mt8183-disp-ovl-2l";
+ reg = <0 0x1400a000 0 0x1000>;
+ interrupts = ;
+ power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
+ clocks = <&mmsys CLK_MM_DISP_OVL1_2L>;
+ };
+
+ rdma0: rdma@1400b000 {
+ compatible = "mediatek,mt8183-disp-rdma";
+ reg = <0 0x1400b000 0 0x1000>;
+ interrupts = ;
+ power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
+ clocks = <&mmsys CLK_MM_DISP_RDMA0>;
+ mediatek,rdma_fifo_size = <5120>;
+ };
+
+ rdma1: rdma@1400c000 {
+ compatible = "mediatek,mt8183-disp-rdma";
+ reg = <0 0x1400c000 0 0x1000>;
+ interrupts = ;
+ power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
+ clocks = <&mmsys CLK_MM_DISP_RDMA1>;
+ mediatek,rdma_fifo_size = <2048>;
+ };
+
+ color0: color@1400e000 {
+ compatible = "mediatek,mt8183-disp-color",
+"mediatek,mt8173-disp-color";
+ reg = <0 0x1400e000 0 0x1000>;
+ interrupts = ;
+ power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
+ clocks = <&mmsys CLK_MM_DISP_COLOR0>;
+ };
+
+ ccorr0: ccorr@1400f000 {
+ compatible = "mediatek,mt8183-disp-ccorr";
+ reg = <0 0x1400f000 0 0x1000>;
+ interrupts = ;
+ power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
+ clocks = <&mmsys CLK_MM_DISP_CCORR0>;
+ };
+
+ aal0: aal@1401 {
+ compatible = "mediatek,mt8183-disp-aal",
+"mediatek,mt8173-disp-aal";
+ reg = <0 0x1401 0 0x1000>;
+ interrupts = ;
+ power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
+ clocks = <&mmsys CLK_MM_DISP_AAL0>;
+ };
+
+ gamma0: gamma@14011000 {
+ compatible = "mediatek,mt8183-disp-gamma",
+"mediatek,mt8173-disp-gamma";
+ reg = <0 0x14011000 0 0x1000>;
+ interrupts = ;
+ power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
+ clocks = <&mmsys CLK_MM_DISP_GAMMA0>;
+ };
+
+ dither0: dither@14012000 {
+ compatible = "mediatek,mt8183-disp-dither";
+ reg = <0 0x14012000 0 0x1000>;
+ interrupts = ;
+ power-domai
Re: [v7, PATCH 4/7] dt-bindings: mediatek: add rdma_fifo_size description for mt8183 display
On 23/07/2020 04:03, Yongqiang Niu wrote:
Update device tree binding document for rdma_fifo_size
Please explain better what you are doing in the patch.
Also DT binding patches should normally go as the first of a series, as this
helps Rob to review them.
Regards,
Matthias
Signed-off-by: Yongqiang Niu
---
.../devicetree/bindings/display/mediatek/mediatek,disp.txt | 14 ++
1 file changed, 14 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
index b91e709..e6bbe32 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
@@ -66,6 +66,11 @@ Required properties (DMA function blocks):
argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
for details.
+Optional properties (RDMA function blocks):
+- mediatek,rdma_fifo_size: rdma fifo size may be different even in same SOC,
add this
+ property to the corresponding rdma
+ the value is the Max value which defined in hardware data sheet.
+
Examples:
mmsys: clock-controller@1400 {
@@ -207,3 +212,12 @@ od@14023000 {
power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
clocks = <&mmsys CLK_MM_DISP_OD>;
};
+
+rdma1: rdma@1400c000 {
+ compatible = "mediatek,mt8183-disp-rdma";
+ reg = <0 0x1400c000 0 0x1000>;
+ interrupts = ;
+ power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
+ clocks = <&mmsys CLK_MM_DISP_RDMA1>;
+ mediatek,rdma_fifo_size = <2048>;
+};
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [v7, PATCH 7/7] drm/mediatek: add support for mediatek SOC MT8183
On 23/07/2020 04:03, Yongqiang Niu wrote:
This patch add support for mediatek SOC MT8183
1.ovl_2l share driver with ovl
2.rdma1 share drive with rdma0, but fifo size is different
3.add mt8183 mutex private data, and mmsys private data
4.add mt8183 main and external path module for crtc create
Please fix your commit message, this is seems to describe what the whole series
is doing.
Regards,
Matthias
Signed-off-by: Yongqiang Niu
---
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 18
drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 6
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 47
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 43 +
4 files changed, 114 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index 28651bc..8cf9f3b 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -430,11 +430,29 @@ static int mtk_disp_ovl_remove(struct platform_device
*pdev)
.fmt_rgb565_is_0 = true,
};
+static const struct mtk_disp_ovl_data mt8183_ovl_driver_data = {
+ .addr = DISP_REG_OVL_ADDR_MT8173,
+ .gmc_bits = 10,
+ .layer_nr = 4,
+ .fmt_rgb565_is_0 = true,
+};
+
+static const struct mtk_disp_ovl_data mt8183_ovl_2l_driver_data = {
+ .addr = DISP_REG_OVL_ADDR_MT8173,
+ .gmc_bits = 10,
+ .layer_nr = 2,
+ .fmt_rgb565_is_0 = true,
+};
+
static const struct of_device_id mtk_disp_ovl_driver_dt_match[] = {
{ .compatible = "mediatek,mt2701-disp-ovl",
.data = &mt2701_ovl_driver_data},
{ .compatible = "mediatek,mt8173-disp-ovl",
.data = &mt8173_ovl_driver_data},
+ { .compatible = "mediatek,mt8183-disp-ovl",
+ .data = &mt8183_ovl_driver_data},
+ { .compatible = "mediatek,mt8183-disp-ovl-2l",
+ .data = &mt8183_ovl_2l_driver_data},
{},
};
MODULE_DEVICE_TABLE(of, mtk_disp_ovl_driver_dt_match);
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
index 794acc5..51f2a0c 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
@@ -355,11 +355,17 @@ static int mtk_disp_rdma_remove(struct platform_device
*pdev)
.fifo_size = SZ_8K,
};
+static const struct mtk_disp_rdma_data mt8183_rdma_driver_data = {
+ .fifo_size = 5 * SZ_1K,
+};
+
static const struct of_device_id mtk_disp_rdma_driver_dt_match[] = {
{ .compatible = "mediatek,mt2701-disp-rdma",
.data = &mt2701_rdma_driver_data},
{ .compatible = "mediatek,mt8173-disp-rdma",
.data = &mt8173_rdma_driver_data},
+ { .compatible = "mediatek,mt8183-disp-rdma",
+ .data = &mt8183_rdma_driver_data},
{},
};
MODULE_DEVICE_TABLE(of, mtk_disp_rdma_driver_dt_match);
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 014c1bb..60788c1 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -15,6 +15,8 @@
#define MT2701_DISP_MUTEX0_MOD0 0x2c
#define MT2701_DISP_MUTEX0_SOF0 0x30
+#define MT8183_DISP_MUTEX0_MOD00x30
+#define MT8183_DISP_MUTEX0_SOF00x2c
#define DISP_REG_MUTEX_EN(n) (0x20 + 0x20 * (n))
#define DISP_REG_MUTEX(n) (0x24 + 0x20 * (n))
@@ -25,6 +27,18 @@
#define INT_MUTEXBIT(1)
+#define MT8183_MUTEX_MOD_DISP_RDMA0 0
+#define MT8183_MUTEX_MOD_DISP_RDMA11
+#define MT8183_MUTEX_MOD_DISP_OVL0 9
+#define MT8183_MUTEX_MOD_DISP_OVL0_2L 10
+#define MT8183_MUTEX_MOD_DISP_OVL1_2L 11
+#define MT8183_MUTEX_MOD_DISP_WDMA012
+#define MT8183_MUTEX_MOD_DISP_COLOR0 13
+#define MT8183_MUTEX_MOD_DISP_CCORR0 14
+#define MT8183_MUTEX_MOD_DISP_AAL0 15
+#define MT8183_MUTEX_MOD_DISP_GAMMA0 16
+#define MT8183_MUTEX_MOD_DISP_DITHER0 17
+
#define MT8173_MUTEX_MOD_DISP_OVL011
#define MT8173_MUTEX_MOD_DISP_OVL112
#define MT8173_MUTEX_MOD_DISP_RDMA0 13
@@ -74,6 +88,10 @@
#define MUTEX_SOF_DSI25
#define MUTEX_SOF_DSI36
+#define MT8183_MUTEX_SOF_DPI0 2
+#define MT8183_MUTEX_EOF_DSI0 (MUTEX_SOF_DSI0 << 6)
+#define MT8183_MUTEX_EOF_DPI0 (MT8183_MUTEX_SOF_DPI0 << 6)
+
struct mtk_disp_mutex {
int id;
@@ -153,6 +171,20 @@ struct mtk_ddp {
[DDP_COMPONENT_WDMA1] = MT8173_MUTEX_MOD_DISP_WDMA1,
};
+static const unsigned int mt8183_mutex_mod[DDP_COMPONENT_ID_MAX] = {
+ [DDP_COMPONENT_AAL0] = MT8183_MUTEX_MOD_DISP_AAL0,
+ [DDP_COMPONENT_CCORR] = MT8183_MUTEX_MOD_DISP_CCORR0,
+ [DDP_COMPONENT_COLOR0] = MT8183_MUTEX_MOD_DISP_COLOR0,
+ [DDP_COMPONEN
Re: [PATCH v7 1/3] dt-bindings: drm/bridge: Document Cadence MHDP bridge bindings
On Wed, 22 Jul 2020 09:40:38 +0200, Swapnil Jakhade wrote: > From: Yuti Amonkar > > Document the bindings used for the Cadence MHDP DPI/DP bridge in > yaml format. > > Signed-off-by: Yuti Amonkar > Signed-off-by: Swapnil Jakhade > Reviewed-by: Rob Herring > Reviewed-by: Laurent Pinchart > --- > .../bindings/display/bridge/cdns,mhdp.yaml| 127 ++ > 1 file changed, 127 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/bridge/cdns,mhdp.yaml > My bot found errors running 'make dt_binding_check' on your patch: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/cdns,mhdp.example.dt.yaml: example-0: dp-bridge@f0fb00:reg:0: [240, 4211081216, 0, 16777216] is too long See https://patchwork.ozlabs.org/patch/1333631 If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure dt-schema is up to date: pip3 install git+https://github.com/devicetree-org/dt-schema.git@master --upgrade Please check and re-submit. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 1/3] dt-bindings: drm/bridge: Document Cadence MHDP bridge bindings
On Wed, Jul 22, 2020 at 09:40:38AM +0200, Swapnil Jakhade wrote:
> From: Yuti Amonkar
>
> Document the bindings used for the Cadence MHDP DPI/DP bridge in
> yaml format.
>
> Signed-off-by: Yuti Amonkar
> Signed-off-by: Swapnil Jakhade
> Reviewed-by: Rob Herring
> Reviewed-by: Laurent Pinchart
> ---
> .../bindings/display/bridge/cdns,mhdp.yaml| 127 ++
> 1 file changed, 127 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/bridge/cdns,mhdp.yaml
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/cdns,mhdp.yaml
> b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp.yaml
> new file mode 100644
> index ..cdf5760d4ec5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp.yaml
> @@ -0,0 +1,127 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: "http://devicetree.org/schemas/display/bridge/cdns,mhdp.yaml#";
> +$schema: "http://devicetree.org/meta-schemas/core.yaml#";
> +
> +title: Cadence MHDP bridge
> +
> +maintainers:
> + - Swapnil Jakhade
> + - Yuti Amonkar
> +
> +properties:
> + compatible:
> +enum:
> + - cdns,mhdp8546
> + - ti,j721e-mhdp8546
> +
> + reg:
> +minItems: 1
> +maxItems: 2
> +items:
> + - description:
> + Register block of mhdptx apb registers up to PHY mapped area
> (AUX_CONFIG_P).
> + The AUX and PMA registers are not part of this range, they are
> instead
> + included in the associated PHY.
> + - description:
> + Register block for DSS_EDP0_INTG_CFG_VP registers in case of TI J7
> SoCs.
> +
> + reg-names:
> +minItems: 1
> +maxItems: 2
> +items:
> + - const: mhdptx
> + - const: j721e-intg
> +
> + clocks:
> +maxItems: 1
> +description:
> + DP bridge clock, used by the IP to know how to translate a number of
> + clock cycles into a time (which is used to comply with DP standard
> timings
> + and delays).
> +
> + phys:
maxItems: 1
> +description:
> + phandle to the DisplayPort PHY.
> +
> + ports:
> +type: object
> +description:
> + Ports as described in Documentation/devicetree/bindings/graph.txt.
> +
> +properties:
> + '#address-cells':
> +const: 1
> +
> + '#size-cells':
> +const: 0
> +
> + port@0:
> +type: object
> +description:
> + Input port representing the DP bridge input.
> +
> + port@1:
> +type: object
> +description:
> + Output port representing the DP bridge output.
> +
> +required:
> + - port@0
> + - port@1
> + - '#address-cells'
> + - '#size-cells'
> +
> +allOf:
> + - if:
> + properties:
> +compatible:
> + contains:
> +const: ti,j721e-mhdp8546
> +then:
> + properties:
> +reg:
> + minItems: 2
> +reg-names:
> + minItems: 2
else:
properties:
reg:
maxItems: 1
reg-names:
maxItems: 1
> +
> +required:
> + - compatible
> + - clocks
> + - reg
> + - reg-names
> + - phys
> + - ports
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +mhdp: dp-bridge@f0fb00 {
> +compatible = "cdns,mhdp8546";
> +reg = <0xf0 0xfb00 0x0 0x100>;
> +reg-names = "mhdptx";
> +clocks = <&mhdp_clock>;
> +phys = <&dp_phy>;
> +
> +ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + dp_bridge_input: endpoint {
> +remote-endpoint = <&xxx_dpi_output>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + dp_bridge_output: endpoint {
> +remote-endpoint = <&xxx_dp_connector_input>;
> + };
> + };
> +};
> +};
> +...
> --
> 2.26.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/9] drm/vmwgfx: stop implementing init_mem_type
Instead just initialize the memory type parameters
before calling ttm_bo_init_mm.
Signed-off-by: Christian König
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c| 18 +++
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 27 --
2 files changed, 18 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index 470428387878..45569e9ad3f5 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -864,6 +864,9 @@ static int vmw_driver_load(struct drm_device *dev, unsigned
long chipset)
* Enable VRAM, but initially don't use it until SVGA is enabled and
* unhidden.
*/
+ dev_priv->bdev.man[TTM_PL_VRAM].func = &vmw_thp_func;
+ dev_priv->bdev.man[TTM_PL_VRAM].available_caching = TTM_PL_FLAG_CACHED;
+ dev_priv->bdev.man[TTM_PL_VRAM].default_caching = TTM_PL_FLAG_CACHED;
ret = ttm_bo_init_mm(&dev_priv->bdev, TTM_PL_VRAM,
(dev_priv->vram_size >> PAGE_SHIFT));
if (unlikely(ret != 0)) {
@@ -872,7 +875,17 @@ static int vmw_driver_load(struct drm_device *dev,
unsigned long chipset)
}
dev_priv->bdev.man[TTM_PL_VRAM].use_type = false;
+ /*
+* "Guest Memory Regions" is an aperture like feature with
+* one slot per bo. There is an upper limit of the number of
+* slots as well as the bo size.
+*/
dev_priv->has_gmr = true;
+ dev_priv->bdev.man[VMW_PL_GMR].func = &vmw_gmrid_manager_func;
+ dev_priv->bdev.man[VMW_PL_GMR].available_caching = TTM_PL_FLAG_CACHED;
+ dev_priv->bdev.man[VMW_PL_GMR].default_caching = TTM_PL_FLAG_CACHED;
+ /* TODO: This is most likely not correct */
+ dev_priv->bdev.man[VMW_PL_GMR].use_tt = true;
if (((dev_priv->capabilities & (SVGA_CAP_GMR | SVGA_CAP_GMR2)) == 0) ||
refuse_dma || ttm_bo_init_mm(&dev_priv->bdev, VMW_PL_GMR,
VMW_PL_GMR) != 0) {
@@ -883,6 +896,11 @@ static int vmw_driver_load(struct drm_device *dev,
unsigned long chipset)
if (dev_priv->capabilities & SVGA_CAP_GBOBJECTS && !refuse_dma) {
dev_priv->has_mob = true;
+ dev_priv->bdev.man[VMW_PL_MOB].func = &vmw_gmrid_manager_func;
+ dev_priv->bdev.man[VMW_PL_MOB].available_caching =
TTM_PL_FLAG_CACHED;
+ dev_priv->bdev.man[VMW_PL_MOB].default_caching =
TTM_PL_FLAG_CACHED;
+ /* TODO: This is most likely not correct */
+ dev_priv->bdev.man[VMW_PL_MOB].use_tt = true;
if (ttm_bo_init_mm(&dev_priv->bdev, VMW_PL_MOB,
VMW_PL_MOB) != 0) {
DRM_INFO("No MOB memory available. "
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
index 5d8179d9f394..db4b2e2e4edb 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
@@ -739,33 +739,6 @@ static struct ttm_tt *vmw_ttm_tt_create(struct
ttm_buffer_object *bo,
static int vmw_init_mem_type(struct ttm_bo_device *bdev, uint32_t type,
struct ttm_mem_type_manager *man)
{
- switch (type) {
- case TTM_PL_SYSTEM:
- /* System memory */
- break;
- case TTM_PL_VRAM:
- /* "On-card" video ram */
- man->func = &vmw_thp_func;
- man->available_caching = TTM_PL_FLAG_CACHED;
- man->default_caching = TTM_PL_FLAG_CACHED;
- break;
- case VMW_PL_GMR:
- case VMW_PL_MOB:
- /*
-* "Guest Memory Regions" is an aperture like feature with
-* one slot per bo. There is an upper limit of the number of
-* slots as well as the bo size.
-*/
- man->func = &vmw_gmrid_manager_func;
- man->available_caching = TTM_PL_FLAG_CACHED;
- man->default_caching = TTM_PL_FLAG_CACHED;
- /* TODO: This is most likely not correct */
- man->use_tt = true;
- break;
- default:
- DRM_ERROR("Unsupported memory type %u\n", (unsigned)type);
- return -EINVAL;
- }
return 0;
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/9] drm/radeon: stop implementing init_mem_type
Instead just initialize the memory type parameters
before calling ttm_bo_init_mm.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_ttm.c | 70 ++---
1 file changed, 35 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index 9aba18a143e7..b0b59c553785 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -69,43 +69,43 @@ struct radeon_device *radeon_get_rdev(struct ttm_bo_device
*bdev)
static int radeon_init_mem_type(struct ttm_bo_device *bdev, uint32_t type,
struct ttm_mem_type_manager *man)
{
- struct radeon_device *rdev;
+ return 0;
+}
- rdev = radeon_get_rdev(bdev);
+static int radeon_ttm_init_vram(struct radeon_device *rdev)
+{
+ struct ttm_mem_type_manager *man = &rdev->mman.bdev.man[TTM_PL_VRAM];
- switch (type) {
- case TTM_PL_SYSTEM:
- /* System memory */
- break;
- case TTM_PL_TT:
- man->func = &ttm_bo_manager_func;
- man->available_caching = TTM_PL_MASK_CACHING;
- man->default_caching = TTM_PL_FLAG_CACHED;
- man->use_tt = true;
+ man->func = &ttm_bo_manager_func;
+ man->available_caching = TTM_PL_FLAG_UNCACHED | TTM_PL_FLAG_WC;
+ man->default_caching = TTM_PL_FLAG_WC;
+
+ return ttm_bo_init_mm(&rdev->mman.bdev, TTM_PL_VRAM,
+ rdev->mc.real_vram_size >> PAGE_SHIFT);
+}
+
+static int radeon_ttm_init_gtt(struct radeon_device *rdev)
+{
+ struct ttm_mem_type_manager *man = &rdev->mman.bdev.man[TTM_PL_TT];
+
+ man->func = &ttm_bo_manager_func;
+ man->available_caching = TTM_PL_MASK_CACHING;
+ man->default_caching = TTM_PL_FLAG_CACHED;
+ man->use_tt = true;
#if IS_ENABLED(CONFIG_AGP)
- if (rdev->flags & RADEON_IS_AGP) {
- if (!rdev->ddev->agp) {
- DRM_ERROR("AGP is not enabled for memory type
%u\n",
- (unsigned)type);
- return -EINVAL;
- }
- man->available_caching = TTM_PL_FLAG_UNCACHED |
-TTM_PL_FLAG_WC;
- man->default_caching = TTM_PL_FLAG_WC;
+ if (rdev->flags & RADEON_IS_AGP) {
+ if (!rdev->ddev->agp) {
+ DRM_ERROR("AGP is not enabled\n");
+ return -EINVAL;
}
-#endif
- break;
- case TTM_PL_VRAM:
- /* "On-card" video ram */
- man->func = &ttm_bo_manager_func;
- man->available_caching = TTM_PL_FLAG_UNCACHED | TTM_PL_FLAG_WC;
+ man->available_caching = TTM_PL_FLAG_UNCACHED |
+TTM_PL_FLAG_WC;
man->default_caching = TTM_PL_FLAG_WC;
- break;
- default:
- DRM_ERROR("Unsupported memory type %u\n", (unsigned)type);
- return -EINVAL;
}
- return 0;
+#endif
+
+ return ttm_bo_init_mm(&rdev->mman.bdev, TTM_PL_TT,
+ rdev->mc.gtt_size >> PAGE_SHIFT);
}
static void radeon_evict_flags(struct ttm_buffer_object *bo,
@@ -778,8 +778,8 @@ int radeon_ttm_init(struct radeon_device *rdev)
return r;
}
rdev->mman.initialized = true;
- r = ttm_bo_init_mm(&rdev->mman.bdev, TTM_PL_VRAM,
- rdev->mc.real_vram_size >> PAGE_SHIFT);
+
+ r = radeon_ttm_init_vram(rdev);
if (r) {
DRM_ERROR("Failed initializing VRAM heap.\n");
return r;
@@ -804,8 +804,8 @@ int radeon_ttm_init(struct radeon_device *rdev)
}
DRM_INFO("radeon: %uM of VRAM memory ready\n",
(unsigned) (rdev->mc.real_vram_size / (1024 * 1024)));
- r = ttm_bo_init_mm(&rdev->mman.bdev, TTM_PL_TT,
- rdev->mc.gtt_size >> PAGE_SHIFT);
+
+ r = radeon_ttm_init_gtt(rdev);
if (r) {
DRM_ERROR("Failed initializing GTT heap.\n");
return r;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 6/9] drm/nouveau: stop implementing init_mem_type
Instead just initialize the memory type parameters
before calling ttm_bo_init_mm.
Signed-off-by: Christian König
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 48 -
drivers/gpu/drm/nouveau/nouveau_ttm.c | 61 +--
2 files changed, 57 insertions(+), 52 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index a3ad66ad3817..23ef9b1aaabc 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -650,54 +650,6 @@ static int
nouveau_bo_init_mem_type(struct ttm_bo_device *bdev, uint32_t type,
struct ttm_mem_type_manager *man)
{
- struct nouveau_drm *drm = nouveau_bdev(bdev);
- struct nvif_mmu *mmu = &drm->client.mmu;
-
- switch (type) {
- case TTM_PL_SYSTEM:
- break;
- case TTM_PL_VRAM:
- man->available_caching = TTM_PL_FLAG_UNCACHED |
-TTM_PL_FLAG_WC;
- man->default_caching = TTM_PL_FLAG_WC;
-
- if (drm->client.device.info.family >= NV_DEVICE_INFO_V0_TESLA) {
- /* Some BARs do not support being ioremapped WC */
- const u8 type = mmu->type[drm->ttm.type_vram].type;
- if (type & NVIF_MEM_UNCACHED) {
- man->available_caching = TTM_PL_FLAG_UNCACHED;
- man->default_caching = TTM_PL_FLAG_UNCACHED;
- }
-
- man->func = &nouveau_vram_manager;
- man->use_io_reserve_lru = true;
- } else {
- man->func = &ttm_bo_manager_func;
- }
- break;
- case TTM_PL_TT:
- if (drm->client.device.info.family >= NV_DEVICE_INFO_V0_TESLA)
- man->func = &nouveau_gart_manager;
- else
- if (!drm->agp.bridge)
- man->func = &nv04_gart_manager;
- else
- man->func = &ttm_bo_manager_func;
-
- man->use_tt = true;
- if (drm->agp.bridge) {
- man->available_caching = TTM_PL_FLAG_UNCACHED |
- TTM_PL_FLAG_WC;
- man->default_caching = TTM_PL_FLAG_WC;
- } else {
- man->available_caching = TTM_PL_MASK_CACHING;
- man->default_caching = TTM_PL_FLAG_CACHED;
- }
-
- break;
- default:
- return -EINVAL;
- }
return 0;
}
diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c
b/drivers/gpu/drm/nouveau/nouveau_ttm.c
index e89ea052cf71..b0012021ae12 100644
--- a/drivers/gpu/drm/nouveau/nouveau_ttm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_ttm.c
@@ -180,6 +180,61 @@ nouveau_ttm_init_host(struct nouveau_drm *drm, u8 kind)
return 0;
}
+static int
+nouveau_ttm_init_vram(struct nouveau_drm *drm)
+{
+ struct ttm_mem_type_manager *man = &drm->ttm.bdev.man[TTM_PL_VRAM];
+ struct nvif_mmu *mmu = &drm->client.mmu;
+
+ man->available_caching = TTM_PL_FLAG_UNCACHED | TTM_PL_FLAG_WC;
+ man->default_caching = TTM_PL_FLAG_WC;
+
+ if (drm->client.device.info.family >= NV_DEVICE_INFO_V0_TESLA) {
+ /* Some BARs do not support being ioremapped WC */
+ const u8 type = mmu->type[drm->ttm.type_vram].type;
+
+ if (type & NVIF_MEM_UNCACHED) {
+ man->available_caching = TTM_PL_FLAG_UNCACHED;
+ man->default_caching = TTM_PL_FLAG_UNCACHED;
+ }
+
+ man->func = &nouveau_vram_manager;
+ man->use_io_reserve_lru = true;
+ } else {
+ man->func = &ttm_bo_manager_func;
+ }
+
+ return ttm_bo_init_mm(&drm->ttm.bdev, TTM_PL_VRAM,
+ drm->gem.vram_available >> PAGE_SHIFT);
+}
+
+static int
+nouveau_ttm_init_gtt(struct nouveau_drm *drm)
+{
+ struct ttm_mem_type_manager *man = &drm->ttm.bdev.man[TTM_PL_TT];
+
+ if (drm->client.device.info.family >= NV_DEVICE_INFO_V0_TESLA)
+ man->func = &nouveau_gart_manager;
+ else
+ if (!drm->agp.bridge)
+ man->func = &nv04_gart_manager;
+ else
+ man->func = &ttm_bo_manager_func;
+
+ man->use_tt = true;
+ if (drm->agp.bridge) {
+ man->available_caching = TTM_PL_FLAG_UNCACHED |
+ TTM_PL_FLAG_WC;
+ man->default_caching = TTM_PL_FLAG_WC;
+ } else {
+ man->available_caching = TTM_PL_MASK_CACHING;
+ man->default_caching = TTM_PL_FLAG_CACHED;
+ }
+
+ return ttm_bo_init_mm(&drm->ttm.bdev, TTM_PL_TT,
+ drm->gem.gart_available >> PAGE_SHIFT);
+}
+
int
nouveau_ttm_init(struct nouve
[PATCH 4/9] drm/amdgpu: stop implementing init_mem_type
Instead just initialize the memory type parameters
before calling ttm_bo_init_mm.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 96 +++--
1 file changed, 43 insertions(+), 53 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 406bcb03df48..98a77fc4a90c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -62,55 +62,49 @@
#define AMDGPU_TTM_VRAM_MAX_DW_READ(size_t)128
-
-/**
- * amdgpu_init_mem_type - Initialize a memory manager for a specific type of
- * memory request.
- *
- * @bdev: The TTM BO device object (contains a reference to amdgpu_device)
- * @type: The type of memory requested
- * @man: The memory type manager for each domain
- *
- * This is called by ttm_bo_init_mm() when a buffer object is being
- * initialized.
- */
static int amdgpu_init_mem_type(struct ttm_bo_device *bdev, uint32_t type,
struct ttm_mem_type_manager *man)
{
- struct amdgpu_device *adev;
+ return 0;
+}
- adev = amdgpu_ttm_adev(bdev);
+static int amdgpu_ttm_init_vram(struct amdgpu_device *adev)
+{
- switch (type) {
- case TTM_PL_SYSTEM:
- /* System memory */
- break;
- case TTM_PL_TT:
- /* GTT memory */
- man->use_tt = true;
- man->func = &amdgpu_gtt_mgr_func;
- man->available_caching = TTM_PL_MASK_CACHING;
- man->default_caching = TTM_PL_FLAG_CACHED;
- break;
- case TTM_PL_VRAM:
- /* "On-card" video ram */
- man->func = &amdgpu_vram_mgr_func;
- man->available_caching = TTM_PL_FLAG_UNCACHED | TTM_PL_FLAG_WC;
- man->default_caching = TTM_PL_FLAG_WC;
- break;
- case AMDGPU_PL_GDS:
- case AMDGPU_PL_GWS:
- case AMDGPU_PL_OA:
- /* On-chip GDS memory*/
- man->func = &ttm_bo_manager_func;
- man->available_caching = TTM_PL_FLAG_UNCACHED;
- man->default_caching = TTM_PL_FLAG_UNCACHED;
- break;
- default:
- DRM_ERROR("Unsupported memory type %u\n", (unsigned)type);
- return -EINVAL;
- }
- return 0;
+ struct ttm_mem_type_manager *man = &adev->mman.bdev.man[TTM_PL_VRAM];
+
+ man->func = &amdgpu_vram_mgr_func;
+ man->available_caching = TTM_PL_FLAG_UNCACHED | TTM_PL_FLAG_WC;
+ man->default_caching = TTM_PL_FLAG_WC;
+
+ return ttm_bo_init_mm(&adev->mman.bdev, TTM_PL_VRAM,
+ adev->gmc.real_vram_size >> PAGE_SHIFT);
+}
+
+static int amdgpu_ttm_init_gtt(struct amdgpu_device *adev, uint64_t gtt_size)
+{
+ struct ttm_mem_type_manager *man = &adev->mman.bdev.man[TTM_PL_TT];
+
+ man->use_tt = true;
+ man->func = &amdgpu_gtt_mgr_func;
+ man->available_caching = TTM_PL_MASK_CACHING;
+ man->default_caching = TTM_PL_FLAG_CACHED;
+
+ return ttm_bo_init_mm(&adev->mman.bdev, TTM_PL_TT,
+ gtt_size >> PAGE_SHIFT);
+}
+
+static int amdgpu_ttm_init_on_chip(struct amdgpu_device *adev,
+ unsigned int type,
+ uint64_t size)
+{
+ struct ttm_mem_type_manager *man = &adev->mman.bdev.man[type];
+
+ man->func = &ttm_bo_manager_func;
+ man->available_caching = TTM_PL_FLAG_UNCACHED;
+ man->default_caching = TTM_PL_FLAG_UNCACHED;
+
+ return ttm_bo_init_mm(&adev->mman.bdev, type, size);
}
/**
@@ -1896,8 +1890,7 @@ int amdgpu_ttm_init(struct amdgpu_device *adev)
adev->mman.bdev.no_retry = true;
/* Initialize VRAM pool with all of VRAM divided into pages */
- r = ttm_bo_init_mm(&adev->mman.bdev, TTM_PL_VRAM,
- adev->gmc.real_vram_size >> PAGE_SHIFT);
+ r = amdgpu_ttm_init_vram(adev);
if (r) {
DRM_ERROR("Failed initializing VRAM heap.\n");
return r;
@@ -1978,7 +1971,7 @@ int amdgpu_ttm_init(struct amdgpu_device *adev)
gtt_size = (uint64_t)amdgpu_gtt_size << 20;
/* Initialize GTT memory pool */
- r = ttm_bo_init_mm(&adev->mman.bdev, TTM_PL_TT, gtt_size >> PAGE_SHIFT);
+ r = amdgpu_ttm_init_gtt(adev, gtt_size);
if (r) {
DRM_ERROR("Failed initializing GTT heap.\n");
return r;
@@ -1987,22 +1980,19 @@ int amdgpu_ttm_init(struct amdgpu_device *adev)
(unsigned)(gtt_size / (1024 * 1024)));
/* Initialize various on-chip memory pools */
- r = ttm_bo_init_mm(&adev->mman.bdev, AMDGPU_PL_GDS,
- adev->gds.gds_size);
+ r = amdgpu_ttm_init_on_chip(adev, AMDGPU_PL_GDS, adev->gds.gds_size);
if (r) {
DRM_ERROR("Failed initializing GDS heap.\n");
[PATCH 8/9] drm/vram-helper: stop implementing init_mem_type
Instead just initialize the memory type parameters
before calling ttm_bo_init_mm.
Signed-off-by: Christian König
---
drivers/gpu/drm/drm_gem_vram_helper.c | 16
1 file changed, 4 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index 801a14c6e9e0..f7f93a49cd7f 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -1007,18 +1007,6 @@ static struct ttm_tt *bo_driver_ttm_tt_create(struct
ttm_buffer_object *bo,
static int bo_driver_init_mem_type(struct ttm_bo_device *bdev, uint32_t type,
struct ttm_mem_type_manager *man)
{
- switch (type) {
- case TTM_PL_SYSTEM:
- break;
- case TTM_PL_VRAM:
- man->func = &ttm_bo_manager_func;
- man->available_caching = TTM_PL_FLAG_UNCACHED |
-TTM_PL_FLAG_WC;
- man->default_caching = TTM_PL_FLAG_WC;
- break;
- default:
- return -EINVAL;
- }
return 0;
}
@@ -1126,6 +1114,7 @@ EXPORT_SYMBOL(drm_vram_mm_debugfs_init);
static int drm_vram_mm_init(struct drm_vram_mm *vmm, struct drm_device *dev,
uint64_t vram_base, size_t vram_size)
{
+ struct ttm_mem_type_manager *man = &vmm->bdev.man[TTM_PL_VRAM];
int ret;
vmm->vram_base = vram_base;
@@ -1138,6 +1127,9 @@ static int drm_vram_mm_init(struct drm_vram_mm *vmm,
struct drm_device *dev,
if (ret)
return ret;
+ man->func = &ttm_bo_manager_func;
+ man->available_caching = TTM_PL_FLAG_UNCACHED | TTM_PL_FLAG_WC;
+ man->default_caching = TTM_PL_FLAG_WC;
ret = ttm_bo_init_mm(&vmm->bdev, TTM_PL_VRAM, vram_size >> PAGE_SHIFT);
if (ret)
return ret;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 9/9] drm/ttm: remove the init_mem_type callback
It is a very strange concept to call a function which just
calls back the caller for the functions parameters.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 7 ---
drivers/gpu/drm/drm_gem_vram_helper.c | 7 ---
drivers/gpu/drm/nouveau/nouveau_bo.c | 8
drivers/gpu/drm/qxl/qxl_ttm.c | 7 ---
drivers/gpu/drm/radeon/radeon_ttm.c| 7 ---
drivers/gpu/drm/ttm/ttm_bo.c | 4
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 7 ---
include/drm/ttm/ttm_bo_driver.h| 6 --
8 files changed, 53 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 98a77fc4a90c..da6434ea07f1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -62,12 +62,6 @@
#define AMDGPU_TTM_VRAM_MAX_DW_READ(size_t)128
-static int amdgpu_init_mem_type(struct ttm_bo_device *bdev, uint32_t type,
- struct ttm_mem_type_manager *man)
-{
- return 0;
-}
-
static int amdgpu_ttm_init_vram(struct amdgpu_device *adev)
{
@@ -1727,7 +1721,6 @@ static struct ttm_bo_driver amdgpu_bo_driver = {
.ttm_tt_create = &amdgpu_ttm_tt_create,
.ttm_tt_populate = &amdgpu_ttm_tt_populate,
.ttm_tt_unpopulate = &amdgpu_ttm_tt_unpopulate,
- .init_mem_type = &amdgpu_init_mem_type,
.eviction_valuable = amdgpu_ttm_bo_eviction_valuable,
.evict_flags = &amdgpu_evict_flags,
.move = &amdgpu_bo_move,
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index f7f93a49cd7f..5f03c6137ef9 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -1004,12 +1004,6 @@ static struct ttm_tt *bo_driver_ttm_tt_create(struct
ttm_buffer_object *bo,
return NULL;
}
-static int bo_driver_init_mem_type(struct ttm_bo_device *bdev, uint32_t type,
- struct ttm_mem_type_manager *man)
-{
- return 0;
-}
-
static void bo_driver_evict_flags(struct ttm_buffer_object *bo,
struct ttm_placement *placement)
{
@@ -1069,7 +1063,6 @@ static struct ttm_bo_driver bo_driver = {
.ttm_tt_create = bo_driver_ttm_tt_create,
.ttm_tt_populate = ttm_pool_populate,
.ttm_tt_unpopulate = ttm_pool_unpopulate,
- .init_mem_type = bo_driver_init_mem_type,
.eviction_valuable = ttm_bo_eviction_valuable,
.evict_flags = bo_driver_evict_flags,
.move_notify = bo_driver_move_notify,
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 23ef9b1aaabc..5efc572c14cc 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -646,13 +646,6 @@ nouveau_ttm_tt_create(struct ttm_buffer_object *bo,
uint32_t page_flags)
return nouveau_sgdma_create_ttm(bo, page_flags);
}
-static int
-nouveau_bo_init_mem_type(struct ttm_bo_device *bdev, uint32_t type,
-struct ttm_mem_type_manager *man)
-{
- return 0;
-}
-
static void
nouveau_bo_evict_flags(struct ttm_buffer_object *bo, struct ttm_placement *pl)
{
@@ -1643,7 +1636,6 @@ struct ttm_bo_driver nouveau_bo_driver = {
.ttm_tt_create = &nouveau_ttm_tt_create,
.ttm_tt_populate = &nouveau_ttm_tt_populate,
.ttm_tt_unpopulate = &nouveau_ttm_tt_unpopulate,
- .init_mem_type = nouveau_bo_init_mem_type,
.eviction_valuable = ttm_bo_eviction_valuable,
.evict_flags = nouveau_bo_evict_flags,
.move_notify = nouveau_bo_move_ntfy,
diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
index 852089d7f783..32069e4799f3 100644
--- a/drivers/gpu/drm/qxl/qxl_ttm.c
+++ b/drivers/gpu/drm/qxl/qxl_ttm.c
@@ -48,12 +48,6 @@ static struct qxl_device *qxl_get_qdev(struct ttm_bo_device
*bdev)
return qdev;
}
-static int qxl_init_mem_type(struct ttm_bo_device *bdev, uint32_t type,
-struct ttm_mem_type_manager *man)
-{
- return 0;
-}
-
static void qxl_evict_flags(struct ttm_buffer_object *bo,
struct ttm_placement *placement)
{
@@ -215,7 +209,6 @@ static void qxl_bo_move_notify(struct ttm_buffer_object *bo,
static struct ttm_bo_driver qxl_bo_driver = {
.ttm_tt_create = &qxl_ttm_tt_create,
- .init_mem_type = &qxl_init_mem_type,
.eviction_valuable = ttm_bo_eviction_valuable,
.evict_flags = &qxl_evict_flags,
.move = &qxl_bo_move,
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index b0b59c553785..f499d02917ac 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -66,12 +66,6 @@ struct radeon_device *radeon_get_rdev(struct ttm_bo_device
*bdev)
return rdev;
}
-static int radeon_init_mem_type(struct tt
[PATCH 1/9] drm/ttm: initialize the system domain with defaults
Instead of repeating that in each driver.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 3 ---
drivers/gpu/drm/drm_gem_vram_helper.c | 3 ---
drivers/gpu/drm/nouveau/nouveau_bo.c | 3 ---
drivers/gpu/drm/qxl/qxl_ttm.c | 3 ---
drivers/gpu/drm/radeon/radeon_ttm.c| 3 ---
drivers/gpu/drm/ttm/ttm_bo.c | 2 ++
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 2 --
7 files changed, 2 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 0dd5e802091d..e57c49a91b73 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -84,9 +84,6 @@ static int amdgpu_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
switch (type) {
case TTM_PL_SYSTEM:
/* System memory */
- man->flags = 0;
- man->available_caching = TTM_PL_MASK_CACHING;
- man->default_caching = TTM_PL_FLAG_CACHED;
break;
case TTM_PL_TT:
/* GTT memory */
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index 3296ed3df358..be177afdeb9a 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -1009,9 +1009,6 @@ static int bo_driver_init_mem_type(struct ttm_bo_device
*bdev, uint32_t type,
{
switch (type) {
case TTM_PL_SYSTEM:
- man->flags = 0;
- man->available_caching = TTM_PL_MASK_CACHING;
- man->default_caching = TTM_PL_FLAG_CACHED;
break;
case TTM_PL_VRAM:
man->func = &ttm_bo_manager_func;
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 4ccf937df0d0..53af25020bb2 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -655,9 +655,6 @@ nouveau_bo_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
switch (type) {
case TTM_PL_SYSTEM:
- man->flags = 0;
- man->available_caching = TTM_PL_MASK_CACHING;
- man->default_caching = TTM_PL_FLAG_CACHED;
break;
case TTM_PL_VRAM:
man->flags = TTM_MEMTYPE_FLAG_FIXED;
diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
index 1d8e07b8b19e..e9b8c921c1f0 100644
--- a/drivers/gpu/drm/qxl/qxl_ttm.c
+++ b/drivers/gpu/drm/qxl/qxl_ttm.c
@@ -54,9 +54,6 @@ static int qxl_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
switch (type) {
case TTM_PL_SYSTEM:
/* System memory */
- man->flags = 0;
- man->available_caching = TTM_PL_MASK_CACHING;
- man->default_caching = TTM_PL_FLAG_CACHED;
break;
case TTM_PL_VRAM:
case TTM_PL_PRIV:
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index b474781a0920..b4cb75361577 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -76,9 +76,6 @@ static int radeon_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
switch (type) {
case TTM_PL_SYSTEM:
/* System memory */
- man->flags = 0;
- man->available_caching = TTM_PL_MASK_CACHING;
- man->default_caching = TTM_PL_FLAG_CACHED;
break;
case TTM_PL_TT:
man->func = &ttm_bo_manager_func;
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 7c02ce784805..1f1f9e463265 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1677,6 +1677,8 @@ int ttm_bo_device_init(struct ttm_bo_device *bdev,
* Initialize the system memory buffer type.
* Other types need to be driver / IOCTL initialized.
*/
+ bdev->man[TTM_PL_SYSTEM].available_caching = TTM_PL_MASK_CACHING;
+ bdev->man[TTM_PL_SYSTEM].default_caching = TTM_PL_FLAG_CACHED;
ret = ttm_bo_init_mm(bdev, TTM_PL_SYSTEM, 0);
if (unlikely(ret != 0))
goto out_no_sys;
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
index 1d78187eaba6..00cef1a3a178 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
@@ -742,8 +742,6 @@ static int vmw_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
switch (type) {
case TTM_PL_SYSTEM:
/* System memory */
- man->available_caching = TTM_PL_FLAG_CACHED;
- man->default_caching = TTM_PL_FLAG_CACHED;
break;
case TTM_PL_VRAM:
/* "On-card" video ram */
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.free
[PATCH 2/9] drm/ttm: remove TTM_MEMTYPE_FLAG_FIXED
Instead use a boolean field in the memory manager structure.
Also invert the meaning of the field since the use of a TT
structure is the special case here.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 4 +---
drivers/gpu/drm/drm_gem_vram_helper.c | 1 -
drivers/gpu/drm/nouveau/nouveau_bo.c | 4 +---
drivers/gpu/drm/qxl/qxl_ttm.c | 1 -
drivers/gpu/drm/radeon/radeon_ttm.c| 3 +--
drivers/gpu/drm/ttm/ttm_bo.c | 14 +++---
drivers/gpu/drm/ttm/ttm_bo_util.c | 12 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 3 ++-
include/drm/ttm/ttm_bo_driver.h| 4 +---
9 files changed, 19 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index e57c49a91b73..406bcb03df48 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -87,15 +87,14 @@ static int amdgpu_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
break;
case TTM_PL_TT:
/* GTT memory */
+ man->use_tt = true;
man->func = &amdgpu_gtt_mgr_func;
man->available_caching = TTM_PL_MASK_CACHING;
man->default_caching = TTM_PL_FLAG_CACHED;
- man->flags = 0;
break;
case TTM_PL_VRAM:
/* "On-card" video ram */
man->func = &amdgpu_vram_mgr_func;
- man->flags = TTM_MEMTYPE_FLAG_FIXED;
man->available_caching = TTM_PL_FLAG_UNCACHED | TTM_PL_FLAG_WC;
man->default_caching = TTM_PL_FLAG_WC;
break;
@@ -104,7 +103,6 @@ static int amdgpu_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
case AMDGPU_PL_OA:
/* On-chip GDS memory*/
man->func = &ttm_bo_manager_func;
- man->flags = TTM_MEMTYPE_FLAG_FIXED;
man->available_caching = TTM_PL_FLAG_UNCACHED;
man->default_caching = TTM_PL_FLAG_UNCACHED;
break;
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index be177afdeb9a..801a14c6e9e0 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -1012,7 +1012,6 @@ static int bo_driver_init_mem_type(struct ttm_bo_device
*bdev, uint32_t type,
break;
case TTM_PL_VRAM:
man->func = &ttm_bo_manager_func;
- man->flags = TTM_MEMTYPE_FLAG_FIXED;
man->available_caching = TTM_PL_FLAG_UNCACHED |
TTM_PL_FLAG_WC;
man->default_caching = TTM_PL_FLAG_WC;
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 53af25020bb2..a3ad66ad3817 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -657,7 +657,6 @@ nouveau_bo_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
case TTM_PL_SYSTEM:
break;
case TTM_PL_VRAM:
- man->flags = TTM_MEMTYPE_FLAG_FIXED;
man->available_caching = TTM_PL_FLAG_UNCACHED |
TTM_PL_FLAG_WC;
man->default_caching = TTM_PL_FLAG_WC;
@@ -685,13 +684,12 @@ nouveau_bo_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
else
man->func = &ttm_bo_manager_func;
+ man->use_tt = true;
if (drm->agp.bridge) {
- man->flags = 0;
man->available_caching = TTM_PL_FLAG_UNCACHED |
TTM_PL_FLAG_WC;
man->default_caching = TTM_PL_FLAG_WC;
} else {
- man->flags = 0;
man->available_caching = TTM_PL_MASK_CACHING;
man->default_caching = TTM_PL_FLAG_CACHED;
}
diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
index e9b8c921c1f0..abb9fa4d80cf 100644
--- a/drivers/gpu/drm/qxl/qxl_ttm.c
+++ b/drivers/gpu/drm/qxl/qxl_ttm.c
@@ -59,7 +59,6 @@ static int qxl_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
case TTM_PL_PRIV:
/* "On-card" video ram */
man->func = &ttm_bo_manager_func;
- man->flags = TTM_MEMTYPE_FLAG_FIXED;
man->available_caching = TTM_PL_MASK_CACHING;
man->default_caching = TTM_PL_FLAG_CACHED;
break;
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index b4cb75361577..9aba18a143e7 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -81,7 +81,7 @@ static int radeon_init_mem_type(struct ttm_bo_device *bdev,
uint32_t typ
[PATCH 7/9] drm/qxl: stop implementing init_mem_type
Instead just initialize the memory type parameters
before calling ttm_bo_init_mm.
Signed-off-by: Christian König
---
drivers/gpu/drm/qxl/qxl_ttm.c | 35 ---
1 file changed, 16 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
index abb9fa4d80cf..852089d7f783 100644
--- a/drivers/gpu/drm/qxl/qxl_ttm.c
+++ b/drivers/gpu/drm/qxl/qxl_ttm.c
@@ -51,21 +51,6 @@ static struct qxl_device *qxl_get_qdev(struct ttm_bo_device
*bdev)
static int qxl_init_mem_type(struct ttm_bo_device *bdev, uint32_t type,
struct ttm_mem_type_manager *man)
{
- switch (type) {
- case TTM_PL_SYSTEM:
- /* System memory */
- break;
- case TTM_PL_VRAM:
- case TTM_PL_PRIV:
- /* "On-card" video ram */
- man->func = &ttm_bo_manager_func;
- man->available_caching = TTM_PL_MASK_CACHING;
- man->default_caching = TTM_PL_FLAG_CACHED;
- break;
- default:
- DRM_ERROR("Unsupported memory type %u\n", (unsigned int)type);
- return -EINVAL;
- }
return 0;
}
@@ -238,6 +223,19 @@ static struct ttm_bo_driver qxl_bo_driver = {
.move_notify = &qxl_bo_move_notify,
};
+static int qxl_ttm_init_mem_type(struct qxl_device *qdev,
+unsigned int type,
+uint64_t size)
+{
+ struct ttm_mem_type_manager *man = &qdev->mman.bdev.man[type];
+
+ man->func = &ttm_bo_manager_func;
+ man->available_caching = TTM_PL_MASK_CACHING;
+ man->default_caching = TTM_PL_FLAG_CACHED;
+
+ return ttm_bo_init_mm(&qdev->mman.bdev, type, size);
+}
+
int qxl_ttm_init(struct qxl_device *qdev)
{
int r;
@@ -255,14 +253,13 @@ int qxl_ttm_init(struct qxl_device *qdev)
}
/* NOTE: this includes the framebuffer (aka surface 0) */
num_io_pages = qdev->rom->ram_header_offset / PAGE_SIZE;
- r = ttm_bo_init_mm(&qdev->mman.bdev, TTM_PL_VRAM,
- num_io_pages);
+ r = qxl_ttm_init_mem_type(qdev, TTM_PL_VRAM, num_io_pages);
if (r) {
DRM_ERROR("Failed initializing VRAM heap.\n");
return r;
}
- r = ttm_bo_init_mm(&qdev->mman.bdev, TTM_PL_PRIV,
- qdev->surfaceram_size / PAGE_SIZE);
+ r = qxl_ttm_init_mem_type(qdev, TTM_PL_PRIV,
+ qdev->surfaceram_size / PAGE_SIZE);
if (r) {
DRM_ERROR("Failed initializing Surfaces heap.\n");
return r;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
More TTM cleanups
Just another round of random TTM cleanups. Please review and/or comment. Thanks, Christian. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/9] drm/radeon: stop implementing init_mem_type
Instead just initialize the memory type parameters
before calling ttm_bo_init_mm.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_ttm.c | 70 ++---
1 file changed, 35 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index 9aba18a143e7..b0b59c553785 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -69,43 +69,43 @@ struct radeon_device *radeon_get_rdev(struct ttm_bo_device
*bdev)
static int radeon_init_mem_type(struct ttm_bo_device *bdev, uint32_t type,
struct ttm_mem_type_manager *man)
{
- struct radeon_device *rdev;
+ return 0;
+}
- rdev = radeon_get_rdev(bdev);
+static int radeon_ttm_init_vram(struct radeon_device *rdev)
+{
+ struct ttm_mem_type_manager *man = &rdev->mman.bdev.man[TTM_PL_VRAM];
- switch (type) {
- case TTM_PL_SYSTEM:
- /* System memory */
- break;
- case TTM_PL_TT:
- man->func = &ttm_bo_manager_func;
- man->available_caching = TTM_PL_MASK_CACHING;
- man->default_caching = TTM_PL_FLAG_CACHED;
- man->use_tt = true;
+ man->func = &ttm_bo_manager_func;
+ man->available_caching = TTM_PL_FLAG_UNCACHED | TTM_PL_FLAG_WC;
+ man->default_caching = TTM_PL_FLAG_WC;
+
+ return ttm_bo_init_mm(&rdev->mman.bdev, TTM_PL_VRAM,
+ rdev->mc.real_vram_size >> PAGE_SHIFT);
+}
+
+static int radeon_ttm_init_gtt(struct radeon_device *rdev)
+{
+ struct ttm_mem_type_manager *man = &rdev->mman.bdev.man[TTM_PL_TT];
+
+ man->func = &ttm_bo_manager_func;
+ man->available_caching = TTM_PL_MASK_CACHING;
+ man->default_caching = TTM_PL_FLAG_CACHED;
+ man->use_tt = true;
#if IS_ENABLED(CONFIG_AGP)
- if (rdev->flags & RADEON_IS_AGP) {
- if (!rdev->ddev->agp) {
- DRM_ERROR("AGP is not enabled for memory type
%u\n",
- (unsigned)type);
- return -EINVAL;
- }
- man->available_caching = TTM_PL_FLAG_UNCACHED |
-TTM_PL_FLAG_WC;
- man->default_caching = TTM_PL_FLAG_WC;
+ if (rdev->flags & RADEON_IS_AGP) {
+ if (!rdev->ddev->agp) {
+ DRM_ERROR("AGP is not enabled\n");
+ return -EINVAL;
}
-#endif
- break;
- case TTM_PL_VRAM:
- /* "On-card" video ram */
- man->func = &ttm_bo_manager_func;
- man->available_caching = TTM_PL_FLAG_UNCACHED | TTM_PL_FLAG_WC;
+ man->available_caching = TTM_PL_FLAG_UNCACHED |
+TTM_PL_FLAG_WC;
man->default_caching = TTM_PL_FLAG_WC;
- break;
- default:
- DRM_ERROR("Unsupported memory type %u\n", (unsigned)type);
- return -EINVAL;
}
- return 0;
+#endif
+
+ return ttm_bo_init_mm(&rdev->mman.bdev, TTM_PL_TT,
+ rdev->mc.gtt_size >> PAGE_SHIFT);
}
static void radeon_evict_flags(struct ttm_buffer_object *bo,
@@ -778,8 +778,8 @@ int radeon_ttm_init(struct radeon_device *rdev)
return r;
}
rdev->mman.initialized = true;
- r = ttm_bo_init_mm(&rdev->mman.bdev, TTM_PL_VRAM,
- rdev->mc.real_vram_size >> PAGE_SHIFT);
+
+ r = radeon_ttm_init_vram(rdev);
if (r) {
DRM_ERROR("Failed initializing VRAM heap.\n");
return r;
@@ -804,8 +804,8 @@ int radeon_ttm_init(struct radeon_device *rdev)
}
DRM_INFO("radeon: %uM of VRAM memory ready\n",
(unsigned) (rdev->mc.real_vram_size / (1024 * 1024)));
- r = ttm_bo_init_mm(&rdev->mman.bdev, TTM_PL_TT,
- rdev->mc.gtt_size >> PAGE_SHIFT);
+
+ r = radeon_ttm_init_gtt(rdev);
if (r) {
DRM_ERROR("Failed initializing GTT heap.\n");
return r;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/9] drm/ttm: initialize the system domain with defaults
Instead of repeating that in each driver.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 3 ---
drivers/gpu/drm/drm_gem_vram_helper.c | 3 ---
drivers/gpu/drm/nouveau/nouveau_bo.c | 3 ---
drivers/gpu/drm/qxl/qxl_ttm.c | 3 ---
drivers/gpu/drm/radeon/radeon_ttm.c| 3 ---
drivers/gpu/drm/ttm/ttm_bo.c | 2 ++
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 2 --
7 files changed, 2 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 0dd5e802091d..e57c49a91b73 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -84,9 +84,6 @@ static int amdgpu_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
switch (type) {
case TTM_PL_SYSTEM:
/* System memory */
- man->flags = 0;
- man->available_caching = TTM_PL_MASK_CACHING;
- man->default_caching = TTM_PL_FLAG_CACHED;
break;
case TTM_PL_TT:
/* GTT memory */
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index 3296ed3df358..be177afdeb9a 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -1009,9 +1009,6 @@ static int bo_driver_init_mem_type(struct ttm_bo_device
*bdev, uint32_t type,
{
switch (type) {
case TTM_PL_SYSTEM:
- man->flags = 0;
- man->available_caching = TTM_PL_MASK_CACHING;
- man->default_caching = TTM_PL_FLAG_CACHED;
break;
case TTM_PL_VRAM:
man->func = &ttm_bo_manager_func;
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 4ccf937df0d0..53af25020bb2 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -655,9 +655,6 @@ nouveau_bo_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
switch (type) {
case TTM_PL_SYSTEM:
- man->flags = 0;
- man->available_caching = TTM_PL_MASK_CACHING;
- man->default_caching = TTM_PL_FLAG_CACHED;
break;
case TTM_PL_VRAM:
man->flags = TTM_MEMTYPE_FLAG_FIXED;
diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
index 1d8e07b8b19e..e9b8c921c1f0 100644
--- a/drivers/gpu/drm/qxl/qxl_ttm.c
+++ b/drivers/gpu/drm/qxl/qxl_ttm.c
@@ -54,9 +54,6 @@ static int qxl_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
switch (type) {
case TTM_PL_SYSTEM:
/* System memory */
- man->flags = 0;
- man->available_caching = TTM_PL_MASK_CACHING;
- man->default_caching = TTM_PL_FLAG_CACHED;
break;
case TTM_PL_VRAM:
case TTM_PL_PRIV:
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index b474781a0920..b4cb75361577 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -76,9 +76,6 @@ static int radeon_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
switch (type) {
case TTM_PL_SYSTEM:
/* System memory */
- man->flags = 0;
- man->available_caching = TTM_PL_MASK_CACHING;
- man->default_caching = TTM_PL_FLAG_CACHED;
break;
case TTM_PL_TT:
man->func = &ttm_bo_manager_func;
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 7c02ce784805..1f1f9e463265 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1677,6 +1677,8 @@ int ttm_bo_device_init(struct ttm_bo_device *bdev,
* Initialize the system memory buffer type.
* Other types need to be driver / IOCTL initialized.
*/
+ bdev->man[TTM_PL_SYSTEM].available_caching = TTM_PL_MASK_CACHING;
+ bdev->man[TTM_PL_SYSTEM].default_caching = TTM_PL_FLAG_CACHED;
ret = ttm_bo_init_mm(bdev, TTM_PL_SYSTEM, 0);
if (unlikely(ret != 0))
goto out_no_sys;
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
index 1d78187eaba6..00cef1a3a178 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
@@ -742,8 +742,6 @@ static int vmw_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
switch (type) {
case TTM_PL_SYSTEM:
/* System memory */
- man->available_caching = TTM_PL_FLAG_CACHED;
- man->default_caching = TTM_PL_FLAG_CACHED;
break;
case TTM_PL_VRAM:
/* "On-card" video ram */
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.free
[PATCH 2/9] drm/ttm: remove TTM_MEMTYPE_FLAG_FIXED
Instead use a boolean field in the memory manager structure.
Also invert the meaning of the field since the use of a TT
structure is the special case here.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 4 +---
drivers/gpu/drm/drm_gem_vram_helper.c | 1 -
drivers/gpu/drm/nouveau/nouveau_bo.c | 4 +---
drivers/gpu/drm/qxl/qxl_ttm.c | 1 -
drivers/gpu/drm/radeon/radeon_ttm.c| 3 +--
drivers/gpu/drm/ttm/ttm_bo.c | 14 +++---
drivers/gpu/drm/ttm/ttm_bo_util.c | 12 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 3 ++-
include/drm/ttm/ttm_bo_driver.h| 4 +---
9 files changed, 19 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index e57c49a91b73..406bcb03df48 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -87,15 +87,14 @@ static int amdgpu_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
break;
case TTM_PL_TT:
/* GTT memory */
+ man->use_tt = true;
man->func = &amdgpu_gtt_mgr_func;
man->available_caching = TTM_PL_MASK_CACHING;
man->default_caching = TTM_PL_FLAG_CACHED;
- man->flags = 0;
break;
case TTM_PL_VRAM:
/* "On-card" video ram */
man->func = &amdgpu_vram_mgr_func;
- man->flags = TTM_MEMTYPE_FLAG_FIXED;
man->available_caching = TTM_PL_FLAG_UNCACHED | TTM_PL_FLAG_WC;
man->default_caching = TTM_PL_FLAG_WC;
break;
@@ -104,7 +103,6 @@ static int amdgpu_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
case AMDGPU_PL_OA:
/* On-chip GDS memory*/
man->func = &ttm_bo_manager_func;
- man->flags = TTM_MEMTYPE_FLAG_FIXED;
man->available_caching = TTM_PL_FLAG_UNCACHED;
man->default_caching = TTM_PL_FLAG_UNCACHED;
break;
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index be177afdeb9a..801a14c6e9e0 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -1012,7 +1012,6 @@ static int bo_driver_init_mem_type(struct ttm_bo_device
*bdev, uint32_t type,
break;
case TTM_PL_VRAM:
man->func = &ttm_bo_manager_func;
- man->flags = TTM_MEMTYPE_FLAG_FIXED;
man->available_caching = TTM_PL_FLAG_UNCACHED |
TTM_PL_FLAG_WC;
man->default_caching = TTM_PL_FLAG_WC;
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 53af25020bb2..a3ad66ad3817 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -657,7 +657,6 @@ nouveau_bo_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
case TTM_PL_SYSTEM:
break;
case TTM_PL_VRAM:
- man->flags = TTM_MEMTYPE_FLAG_FIXED;
man->available_caching = TTM_PL_FLAG_UNCACHED |
TTM_PL_FLAG_WC;
man->default_caching = TTM_PL_FLAG_WC;
@@ -685,13 +684,12 @@ nouveau_bo_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
else
man->func = &ttm_bo_manager_func;
+ man->use_tt = true;
if (drm->agp.bridge) {
- man->flags = 0;
man->available_caching = TTM_PL_FLAG_UNCACHED |
TTM_PL_FLAG_WC;
man->default_caching = TTM_PL_FLAG_WC;
} else {
- man->flags = 0;
man->available_caching = TTM_PL_MASK_CACHING;
man->default_caching = TTM_PL_FLAG_CACHED;
}
diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
index e9b8c921c1f0..abb9fa4d80cf 100644
--- a/drivers/gpu/drm/qxl/qxl_ttm.c
+++ b/drivers/gpu/drm/qxl/qxl_ttm.c
@@ -59,7 +59,6 @@ static int qxl_init_mem_type(struct ttm_bo_device *bdev,
uint32_t type,
case TTM_PL_PRIV:
/* "On-card" video ram */
man->func = &ttm_bo_manager_func;
- man->flags = TTM_MEMTYPE_FLAG_FIXED;
man->available_caching = TTM_PL_MASK_CACHING;
man->default_caching = TTM_PL_FLAG_CACHED;
break;
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index b4cb75361577..9aba18a143e7 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -81,7 +81,7 @@ static int radeon_init_mem_type(struct ttm_bo_device *bdev,
uint32_t typ
[PATCH v2 1/2] drm: add drmm_encoder_init()
Add a drm_encoder_init() variant that allocates an encoder with
drmm_kzalloc() and registers drm_encoder_cleanup() with
drmm_add_action_or_reset().
Signed-off-by: Philipp Zabel
---
New in v2
---
drivers/gpu/drm/drm_encoder.c | 101 ++
include/drm/drm_encoder.h | 30 ++
2 files changed, 108 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/drm_encoder.c b/drivers/gpu/drm/drm_encoder.c
index e555281f43d4..91184f67333c 100644
--- a/drivers/gpu/drm/drm_encoder.c
+++ b/drivers/gpu/drm/drm_encoder.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include "drm_crtc_internal.h"
@@ -91,25 +92,10 @@ void drm_encoder_unregister_all(struct drm_device *dev)
}
}
-/**
- * drm_encoder_init - Init a preallocated encoder
- * @dev: drm device
- * @encoder: the encoder to init
- * @funcs: callbacks for this encoder
- * @encoder_type: user visible type of the encoder
- * @name: printf style format string for the encoder name, or NULL for default
name
- *
- * Initialises a preallocated encoder. Encoder should be subclassed as part of
- * driver encoder objects. At driver unload time drm_encoder_cleanup() should
be
- * called from the driver's &drm_encoder_funcs.destroy hook.
- *
- * Returns:
- * Zero on success, error code on failure.
- */
-int drm_encoder_init(struct drm_device *dev,
-struct drm_encoder *encoder,
-const struct drm_encoder_funcs *funcs,
-int encoder_type, const char *name, ...)
+static int __drm_encoder_init(struct drm_device *dev,
+ struct drm_encoder *encoder,
+ const struct drm_encoder_funcs *funcs,
+ int encoder_type, const char *name, va_list ap)
{
int ret;
@@ -125,11 +111,7 @@ int drm_encoder_init(struct drm_device *dev,
encoder->encoder_type = encoder_type;
encoder->funcs = funcs;
if (name) {
- va_list ap;
-
- va_start(ap, name);
encoder->name = kvasprintf(GFP_KERNEL, name, ap);
- va_end(ap);
} else {
encoder->name = kasprintf(GFP_KERNEL, "%s-%d",
drm_encoder_enum_list[encoder_type].name,
@@ -150,6 +132,38 @@ int drm_encoder_init(struct drm_device *dev,
return ret;
}
+
+/**
+ * drm_encoder_init - Init a preallocated encoder
+ * @dev: drm device
+ * @encoder: the encoder to init
+ * @funcs: callbacks for this encoder
+ * @encoder_type: user visible type of the encoder
+ * @name: printf style format string for the encoder name, or NULL for default
name
+ *
+ * Initialises a preallocated encoder. Encoder should be subclassed as part of
+ * driver encoder objects. At driver unload time drm_encoder_cleanup() should
be
+ * called from the driver's &drm_encoder_funcs.destroy hook.
+ *
+ * Returns:
+ * Zero on success, error code on failure.
+ */
+int drm_encoder_init(struct drm_device *dev,
+struct drm_encoder *encoder,
+const struct drm_encoder_funcs *funcs,
+int encoder_type, const char *name, ...)
+{
+ va_list ap;
+ int ret;
+
+ if (name)
+ va_start(ap, name);
+ ret = __drm_encoder_init(dev, encoder, funcs, encoder_type, name, ap);
+ if (name)
+ va_end(ap);
+
+ return ret;
+}
EXPORT_SYMBOL(drm_encoder_init);
/**
@@ -181,6 +195,47 @@ void drm_encoder_cleanup(struct drm_encoder *encoder)
}
EXPORT_SYMBOL(drm_encoder_cleanup);
+void drmm_encoder_init_release(struct drm_device *dev, void *ptr)
+{
+ struct drm_encoder *encoder = ptr;
+
+ drm_encoder_cleanup(encoder);
+}
+
+void *__drmm_encoder_init(struct drm_device *dev, size_t size, size_t offset,
+ const struct drm_encoder_funcs *funcs,
+ int encoder_type, const char *name, ...)
+{
+ void *container;
+ struct drm_encoder *encoder;
+ va_list ap;
+ int ret;
+
+ if (WARN_ON(!funcs || funcs->destroy))
+ return ERR_PTR(-EINVAL);
+
+ container = drmm_kzalloc(dev, size, GFP_KERNEL);
+ if (!container)
+ return ERR_PTR(-EINVAL);
+
+ encoder = container + offset;
+
+ if (name)
+ va_start(ap, name);
+ ret = __drm_encoder_init(dev, encoder, funcs, encoder_type, name, ap);
+ if (name)
+ va_end(ap);
+ if (ret)
+ return ERR_PTR(ret);
+
+ ret = drmm_add_action_or_reset(dev, drmm_encoder_init_release, encoder);
+ if (ret)
+ return ERR_PTR(ret);
+
+ return container;
+}
+EXPORT_SYMBOL(__drmm_encoder_init);
+
static struct drm_crtc *drm_encoder_get_crtc(struct drm_encoder *encoder)
{
struct drm_connector *connector;
diff --git a/include/drm/drm_encoder.h b/include/drm/drm_encoder.h
index a60f5f1555ac..54b82554
[PATCH v2 2/2] drm/simple_kms_helper: add drmm_simple_encoder_init()
Add a drm_simple_encoder_init() variant that allocates an encoder with
drmm_kzalloc() and registers drm_encoder_cleanup() with
drmm_add_action_or_reset().
Signed-off-by: Philipp Zabel
---
Changes since v1:
- based on drmm_encoder_init
- use AE initialize spelling
- fold allocation into drmm_(simple_)encoder_init, to reduce
boilerplate
---
drivers/gpu/drm/drm_simple_kms_helper.c | 12
include/drm/drm_simple_kms_helper.h | 24
2 files changed, 36 insertions(+)
diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c
b/drivers/gpu/drm/drm_simple_kms_helper.c
index 74946690aba4..eb1ea7b6f05d 100644
--- a/drivers/gpu/drm/drm_simple_kms_helper.c
+++ b/drivers/gpu/drm/drm_simple_kms_helper.c
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -71,6 +72,17 @@ int drm_simple_encoder_init(struct drm_device *dev,
}
EXPORT_SYMBOL(drm_simple_encoder_init);
+static const struct drm_encoder_funcs drmm_simple_encoder_funcs_empty = { };
+
+void *__drmm_simple_encoder_init(struct drm_device *dev, size_t size,
+size_t offset, int encoder_type)
+{
+ return __drmm_encoder_init(dev, size, offset,
+ &drmm_simple_encoder_funcs_empty,
+ encoder_type, NULL);
+}
+EXPORT_SYMBOL(__drmm_simple_encoder_init);
+
static enum drm_mode_status
drm_simple_kms_crtc_mode_valid(struct drm_crtc *crtc,
const struct drm_display_mode *mode)
diff --git a/include/drm/drm_simple_kms_helper.h
b/include/drm/drm_simple_kms_helper.h
index a026375464ff..58f5d4d5e78a 100644
--- a/include/drm/drm_simple_kms_helper.h
+++ b/include/drm/drm_simple_kms_helper.h
@@ -185,4 +185,28 @@ int drm_simple_encoder_init(struct drm_device *dev,
struct drm_encoder *encoder,
int encoder_type);
+void *__drmm_simple_encoder_init(struct drm_device *dev, size_t size,
+size_t offset, int encoder_type);
+
+/**
+ * drmm_simple_encoder_init - Allocate and initialize an encoder with basic
+ *functionality.
+ * @dev: drm device
+ * @type: the type of the struct which contains struct &drm_encoder
+ * @member: the name of the &drm_encoder within @type.
+ * @encoder_type: user visible type of the encoder
+ *
+ * Allocates and initializes an encoder that has no further functionality.
+ * Settings for possible CRTC and clones are left to their initial values.
+ * Cleanup is automatically handled through registering drm_encoder_cleanup()
+ * with drmm_add_action().
+ *
+ * Returns:
+ * Pointer to new encoder, or ERR_PTR on failure.
+ */
+#define drmm_simple_encoder_init(dev, type, member, encoder_type) \
+ ((type *) __drmm_simple_encoder_init(dev, sizeof(type), \
+offsetof(type, member), \
+encoder_type))
+
#endif /* __LINUX_DRM_SIMPLE_KMS_HELPER_H */
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/simple_kms_helper: add drmm_simple_encoder_init()
Hi Daniel, On Thu, 2020-07-23 at 00:22 +0200, dan...@ffwll.ch wrote: [...] > Yeah the drmm_ versions of these need to check that the ->cleanup hook is > NULL. > > Also there's not actually a double-free, since drm_foo_cleanup removes it > from the lists, which means drm_mode_config_cleanup won't even see it. But > if the driver has some additional code in ->cleanup that won't ever run, > so probably still a bug. > > I also think that the drmm_foo_ wrappers should also do the allocation > (and upcasting) kinda like drmm_dev_alloc(). Otherwise we're still stuck > with tons of boilerplate. Ok, I'll try this: drmm_encoder_init() variant can verify that the passed drm_encoder_funcs::destroy hook is NULL. drmm_simple_encoder_init() can just provide empty drm_encoder_funcs internally. > For now I think it's ok if drivers that switch to drmm_ just copypaste, > until we're sure this is the right thing to do. And then maybe also roll > these out for all objects that stay for the entire lifetime of drm_device > (plane, crtc, encoder, plus variants). Just to make sure we're consistent > across all of them. Thank you for clarifying, I wasn't sure this was the goal. I've started with this function mostly because this is the most used one in imx-drm and the only one where I didn't have to deal with va_args boilerplate. regards Philipp ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/simple_kms_helper: add drmm_simple_encoder_init()
Hi Thomas,
On Thu, 2020-07-23 at 09:35 +0200, Thomas Zimmermann wrote:
> Hi
>
> I have meanwhile seen your imx patchset where this would be useful.
>
> I still think you should try to pre-allocated all encoders up to a
> limit, so that an extra drmm_kzalloc() is not required. But see my
> comments below.
Thank you for the review coments. The complication with imx-drm is that
the encoders are all in separate platform devices, using the component
framework. Preallocating encoders in the main driver would be
impractical.
The encoders are added in the component .bind() callback, so the main
driver must call drmm_mode_config_init() before binding all components.
The bind callback also is the first place where the component drivers
get to know the drm device, so it is not possible to use drmm_kzalloc()
any earlier.
> Am 22.07.20 um 15:25 schrieb Philipp Zabel:
> > Add a drm_simple_encoder_init() variant that registers
> > drm_encoder_cleanup() with drmm_add_action().
> >
> > Now drivers can store encoders in memory allocated with drmm_kmalloc()
> > after the call to drmm_mode_config_init(), without having to manually
> > make sure that drm_encoder_cleanup() is called before the memory is
> > freed.
> >
> > Signed-off-by: Philipp Zabel
> > ---
> > drivers/gpu/drm/drm_simple_kms_helper.c | 42 +
> > include/drm/drm_simple_kms_helper.h | 4 +++
> > 2 files changed, 46 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c
> > b/drivers/gpu/drm/drm_simple_kms_helper.c
> > index 74946690aba4..a243f00cf63d 100644
> > --- a/drivers/gpu/drm/drm_simple_kms_helper.c
> > +++ b/drivers/gpu/drm/drm_simple_kms_helper.c
> > @@ -9,6 +9,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -71,6 +72,47 @@ int drm_simple_encoder_init(struct drm_device *dev,
> > }
> > EXPORT_SYMBOL(drm_simple_encoder_init);
> >
> > +static void drmm_encoder_cleanup(struct drm_device *dev, void *ptr)
>
> It's the reset helper, so drmm_simple_encoder_reset() would be appropriate.
>
> > +{
> > + struct drm_encoder *encoder = ptr;
> > +
> > + drm_encoder_cleanup(encoder);
>
> This should first check for (encoder->dev) being true. If drivers
> somehow manage to clean-up the mode config first, we should detect it. I
> know it's a bug, but I wouldn't trust drivers with that.
I don't think this can happen, a previously called drm_encoder_cleanup()
would have removed the encoder from the drm_mode_config::encoder list.
> > +}
> > +
> > +/**
> > + * drmm_simple_encoder_init - Initialize a preallocated encoder with
> > + *basic functionality.
> > + * @dev: drm device
> > + * @encoder: the encoder to initialize
> > + * @encoder_type: user visible type of the encoder
> > + *
> > + * Initialises a preallocated encoder that has no further functionality.
>
> 'Initializes'
Copy & paste from the drm_simple_encoder_init, I'll fix this in the next
version.
> > + * Settings for possible CRTC and clones are left to their initial values.
> > + * Cleanup is automatically handled through registering
> > drm_encoder_cleanup()
> > + * with drmm_add_action().
> > + *
> > + * The caller of drmm_simple_encoder_init() is responsible for allocating
> > + * the encoder's memory with drmm_kzalloc() to ensure it is automatically
> > + * freed after the encoder has been cleaned up.
> > + *
>
> The idiomatic way of cleaning up an encoder is via mode-config cleanup.
> This interface is an exception for a corner case. So there needs to be a
> paragraph that clearly explains the corner case. Please also discourage
> from using drmm_simple_encoder_init() if drm_simple_encoder_init() would
> work.
I was hoping that we would eventually switch to drmres cleanup as the
preferred method, thus getting rid of the need for per-driver cleanup in
the error paths and destroy callbacks in most cases.
regards
Philipp
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ttm: fix pipelined gutting for evictions
Am 2020-07-23 um 5:00 a.m. schrieb Christian König:
> We can't pipeline that during eviction because the memory needs
> to be available immediately.
>
> Signed-off-by: Christian König
Looks good to me.
Reviewed-by: Felix Kuehling
Alex, in this case the synchronous ttm_bo_wait would be triggering the
eviction fence rather than a delayed delete.
Scheduling an eviction worker, like we currently do, would only add
unnecessary latency here. The best place to do the HMM migration to
system memory synchronously and minimize the wait time here may be in
amdgpu_eviction_flags. That way all the SDMA copies to system memory
pages would already be in the pipe by the time we get to the ttm_bo_wait.
Regards,
Felix
> ---
> drivers/gpu/drm/ttm/ttm_bo.c | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index bc2230ecb7e3..122040056a07 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -651,8 +651,16 @@ static int ttm_bo_evict(struct ttm_buffer_object *bo,
> placement.num_busy_placement = 0;
> bdev->driver->evict_flags(bo, &placement);
>
> - if (!placement.num_placement && !placement.num_busy_placement)
> - return ttm_bo_pipeline_gutting(bo);
> + if (!placement.num_placement && !placement.num_busy_placement) {
> + ttm_bo_wait(bo, false, false);
> +
> + ttm_tt_destroy(bo->ttm);
> +
> + memset(&bo->mem, 0, sizeof(bo->mem));
> + bo->mem.mem_type = TTM_PL_SYSTEM;
> + bo->ttm = NULL;
> + return 0;
> + }
>
> evict_mem = bo->mem;
> evict_mem.mm_node = NULL;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amd/display: remove redundant initialization of variable result
From: Colin Ian King
The variable result is being initialized with a value that is never read
and it is being updated later with a new value. The initialization is
redundant and can be removed.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c
b/drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c
index 5d83e8174005..0853bc9917c7 100644
--- a/drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c
@@ -1017,7 +1017,7 @@ enum dc_status dce112_add_stream_to_ctx(
struct dc_state *new_ctx,
struct dc_stream_state *dc_stream)
{
- enum dc_status result = DC_ERROR_UNEXPECTED;
+ enum dc_status result;
result = resource_map_pool_resources(dc, new_ctx, dc_stream);
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] fbdev: Detect integer underflow at "struct fbcon_ops"->clear_margins.
On Wed, Jul 22, 2020 at 10:07:06AM +0200, Daniel Vetter wrote:
> On Tue, Jul 21, 2020 at 6:08 PM Greg Kroah-Hartman
> wrote:
> >
> > On Thu, Jul 16, 2020 at 08:27:21PM +0900, Tetsuo Handa wrote:
> > > On 2020/07/16 19:00, Daniel Vetter wrote:
> > > > On Thu, Jul 16, 2020 at 12:29:00AM +0900, Tetsuo Handa wrote:
> > > >> On 2020/07/16 0:12, Dan Carpenter wrote:
> > > >>> I've complained about integer overflows in fbdev for a long time...
> > > >>>
> > > >>> What I'd like to see is something like the following maybe. I don't
> > > >>> know how to get the vc_data in fbmem.c so it doesn't include your
> > > >>> checks
> > > >>> for negative.
> > > >>
> > > >> Yes. Like I said "Thus, I consider that we need more
> > > >> sanity/constraints checks." at
> > > >> https://lore.kernel.org/lkml/b1e7dd6a-fc22-bba8-0abb-d3e779329...@i-love.sakura.ne.jp/
> > > >> ,
> > > >> we want basic checks. That's a task for fbdev people who should be
> > > >> familiar with
> > > >> necessary constraints.
> > > >
> > > > I think the worldwide supply of people who understand fbdev and willing
> > > > to
> > > > work on it is roughly 0. So if someone wants to fix this mess properly
> > > > (which likely means adding tons of over/underflow checks at entry
> > > > points,
> > > > since you're never going to catch the driver bugs, there's too many and
> > > > not enough people who care) they need to fix this themselves.
> > >
> > > But I think we can enforce reasonable constraint which is much stricter
> > > than Dan's basic_checks()
> > > (which used INT_MAX). For example, do we need to accept var->{xres,yres}
> > > >= 1048576, for
> > > "32768 rows or cols" * "32 pixels per character" = 1045876 and
> > > vc_do_resize() accepts only
> > > rows and cols < 32768 ?
> > >
> > > >
> > > > Just to avoid confusion here.
> > > >
> > > >> Anyway, my two patches are small and low cost; can we apply these
> > > >> patches regardless
> > > >> of basic checks?
> > > >
> > > > Which two patches where?
> > >
> > > [PATCH v3] vt: Reject zero-sized screen buffer size.
> > > from
> > > https://lkml.kernel.org/r/20200712111013.11881-1-penguin-ker...@i-love.sakura.ne.jp
> >
> > This is now in my tree.
> >
> > > [PATCH v2] fbdev: Detect integer underflow at "struct
> > > fbcon_ops"->clear_margins.
> > > from
> > > https://lkml.kernel.org/r/20200715015102.3814-1-penguin-ker...@i-love.sakura.ne.jp
> >
> > That should be taken by the fbdev maintainer, but I can take it too if
> > people want.
>
> Just missed this weeks pull request train and feeling like not worth
> making this an exception (it's been broken forever after all), so
> maybe best if you just add this to vt.
>
> Acked-by: Daniel Vetter
>
> Also this avoids the impression I know what's going on in fbdev code,
> maybe with sufficient abandon from my side someone will pop up who
> cares an fixes the bazillion of syzkaller issues we seem to have
> around console/vt and everything related.
Great, will go queue it up now, thanks!
greg k-h
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH -next 2/2] drm: Remove redundant NULL check
On Thu, Jul 23, 2020 at 12:11 AM Li Heng wrote:
>
> Fix below warnings reported by coccicheck:
> ./drivers/gpu/drm/amd/display/dc/clk_mgr/dcn30/dcn30_clk_mgr.c:557:2-7:
> WARNING: NULL check before some freeing functions is not needed.
>
> Fixes: 4d55b0dd1cdd ("drm/amd/display: Add DCN3 CLK_MGR")
> Signed-off-by: Li Heng
Applied. Thanks!
Alex
> ---
> drivers/gpu/drm/amd/display/dc/clk_mgr/dcn30/dcn30_clk_mgr.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn30/dcn30_clk_mgr.c
> b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn30/dcn30_clk_mgr.c
> index d94fdc5..d8af56a 100644
> --- a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn30/dcn30_clk_mgr.c
> +++ b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn30/dcn30_clk_mgr.c
> @@ -553,8 +553,7 @@ void dcn3_clk_mgr_construct(
>
> void dcn3_clk_mgr_destroy(struct clk_mgr_internal *clk_mgr)
> {
> - if (clk_mgr->base.bw_params)
> - kfree(clk_mgr->base.bw_params);
> + kfree(clk_mgr->base.bw_params);
>
> if (clk_mgr->wm_range_table)
> dm_helpers_free_gpu_mem(clk_mgr->base.ctx,
> DC_MEM_ALLOC_TYPE_GART,
> --
> 2.7.4
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: manual merge of the amdgpu tree with Linus' tree
On Thu, Jul 23, 2020 at 4:01 AM Daniel Vetter wrote:
>
> On Wed, Jul 22, 2020 at 6:34 AM Stephen Rothwell
> wrote:
> >
> > Hi all,
> >
> > [I can't find a previous email about this, sorry ...]
> >
> > There is a semantic conflict between Linus' tree and the amdgpu tree
> > between commit
> >
> > d7a6634a4cfb ("drm/amdgpu/atomfirmware: fix vram_info fetching for
> > renoir")
> >
> > from Linus' tree and commts
> >
> > fe098a5d6443 ("drm/amdgpu/atomfirmware: fix vram_info fetching for
> > renoir")
> > 836dab851903 ("drm/amdgpu/atomfirmware: update vram info handling for
> > renoir")
> >
> > The automted git merge leaves two "case 12" labels. I have been
> > reverting commit d7a6634a4cfb since July 3 ... This will need to be
> > fixed up when the amdgpu tree is next merged into the drm tree, or a back
> > merge of d7a6634a4cfb could be done into the amdgpu tree and the older
> > "case 12" label removed in that merge.
>
> Yeah this is a bit nasty, I just crashed over it too (btw moved to
> drm-next now). Alex is this the right conflict resolution for -next? I
> think we should bake this in with a backmerge ...
Yes, you can drop either d7a6634a4cfb or fe098a5d6443. I just
cherry-picked the commit from -next back to 5.8 and stable since it
was a bug fix.
Alex
> -Daniel
>
> >
> > --
> > Cheers,
> > Stephen Rothwell
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] usb: cdns3: gadget: Replace trace_printk by dev_dbg
Nicolas Boichat writes:
> trace_printk should not be used in production code, replace it
> call with dev_dbg.
>
> Signed-off-by: Nicolas Boichat
>
> ---
>
> Unclear why a trace_printk was used in the first place, it's
> possible that some rate-limiting is necessary here.
>
> drivers/usb/cdns3/gadget.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/usb/cdns3/gadget.c b/drivers/usb/cdns3/gadget.c
> index 5e24c2e57c0d8c8..c303ab7c62d1651 100644
> --- a/drivers/usb/cdns3/gadget.c
> +++ b/drivers/usb/cdns3/gadget.c
> @@ -421,7 +421,7 @@ static int cdns3_start_all_request(struct cdns3_device
> *priv_dev,
> if ((priv_req->flags & REQUEST_INTERNAL) ||
> (priv_ep->flags & EP_TDLCHK_EN) ||
> priv_ep->use_streams) {
> - trace_printk("Blocking external request\n");
> + dev_dbg(priv_dev->dev, "Blocking external request\n");
Instead, I would suggest adding a proper trace event here; one that
includes "priv_ep->flags" in the output.
--
balbi
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 3/4] drm/bridge: Introduce LT9611 DSI to HDMI bridge
On 23-07-20, 13:39, Sam Ravnborg wrote:
> On Thu, Jul 23, 2020 at 04:11:51PM +0530, Vinod Koul wrote:
> > Hi Sam, Laurent,
> >
> > On 22-07-20, 16:14, Laurent Pinchart wrote:
> > > > > +static int lt9611_bridge_attach(struct drm_bridge *bridge,
> > > > > + enum drm_bridge_attach_flags flags)
> > > > > +{
> > > > > + struct lt9611 *lt9611 = bridge_to_lt9611(bridge);
> > > > > + int ret;
> > > > > +
> > > > > + if (!(flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)) {
> > > > > + dev_err(lt9611->dev, "Fix bridge driver to make
> > > > > connector optional!");
> > > > > + return -EINVAL;
> > > > > + }
> > > >
> > > > This should say that the display driver should be fixed.
> > > > If a display driver expects this bridge to create the connector
> > > > it would not work.
> > >
> > > Actually, for new bridge drivers, connector creation should be optional
> > > from the start. We don't want a failure in that case, the feature should
> > > be implemented.
> >
> > Yes this is causing issues for me now !. The patch 4/4 adds support in
> > msm/dsi but causes regression on qualcomm laptops with ti-sn65dsi86 eDP
> > bridge. I tried to fix that up with changes like Laurent has done for
> > adv7511, but it hasnt worked yet for me (remote debug of this is bit
> > painful)
> >
> > So I am going to drop patch 4 from this series and add support for both
> > DRM_BRIDGE_ATTACH_NO_CONNECTOR set and cleared (like we have in adv7511)
> > so that it can work in both cases, while I fix all bridge uses of
> > msm/dsi and then we can drop these. Does that sound okay to you folks?
> Yes, sounds like a good plan.
> Only when all display drivers are migrated over can we drop all the
> workarounds in the bridge drivers.
> I had hoped all users of this bridge was converted - alas that was not
> the case.
Thanks, I will send updated patchset fixing the nits and supporting both
the cases and will drop msm/dsi patch for now
--
~Vinod
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 3/4] drm/bridge: Introduce LT9611 DSI to HDMI bridge
On Thu, Jul 23, 2020 at 04:11:51PM +0530, Vinod Koul wrote:
> Hi Sam, Laurent,
>
> On 22-07-20, 16:14, Laurent Pinchart wrote:
> > > > +static int lt9611_bridge_attach(struct drm_bridge *bridge,
> > > > + enum drm_bridge_attach_flags flags)
> > > > +{
> > > > + struct lt9611 *lt9611 = bridge_to_lt9611(bridge);
> > > > + int ret;
> > > > +
> > > > + if (!(flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)) {
> > > > + dev_err(lt9611->dev, "Fix bridge driver to make
> > > > connector optional!");
> > > > + return -EINVAL;
> > > > + }
> > >
> > > This should say that the display driver should be fixed.
> > > If a display driver expects this bridge to create the connector
> > > it would not work.
> >
> > Actually, for new bridge drivers, connector creation should be optional
> > from the start. We don't want a failure in that case, the feature should
> > be implemented.
>
> Yes this is causing issues for me now !. The patch 4/4 adds support in
> msm/dsi but causes regression on qualcomm laptops with ti-sn65dsi86 eDP
> bridge. I tried to fix that up with changes like Laurent has done for
> adv7511, but it hasnt worked yet for me (remote debug of this is bit
> painful)
>
> So I am going to drop patch 4 from this series and add support for both
> DRM_BRIDGE_ATTACH_NO_CONNECTOR set and cleared (like we have in adv7511)
> so that it can work in both cases, while I fix all bridge uses of
> msm/dsi and then we can drop these. Does that sound okay to you folks?
Yes, sounds like a good plan.
Only when all display drivers are migrated over can we drop all the
workarounds in the bridge drivers.
I had hoped all users of this bridge was converted - alas that was not
the case.
Sam
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 08/12] device core: Introduce DMA range map, supplanting dma_pfn_offset
On Tue, Jul 21, 2020 at 8:51 AM Christoph Hellwig wrote:
>
> On Wed, Jul 15, 2020 at 10:35:11AM -0400, Jim Quinlan wrote:
> > The new field 'dma_range_map' in struct device is used to facilitate the
> > use of single or multiple offsets between mapping regions of cpu addrs and
> > dma addrs. It subsumes the role of "dev->dma_pfn_offset" which was only
> > capable of holding a single uniform offset and had no region bounds
> > checking.
> >
> > The function of_dma_get_range() has been modified so that it takes a single
> > argument -- the device node -- and returns a map, NULL, or an error code.
> > The map is an array that holds the information regarding the DMA regions.
> > Each range entry contains the address offset, the cpu_start address, the
> > dma_start address, and the size of the region.
> >
> > of_dma_configure() is the typical manner to set range offsets but there are
> > a number of ad hoc assignments to "dev->dma_pfn_offset" in the kernel
> > driver code. These cases now invoke the function
> > dma_attach_offset_range(dev, cpu_addr, dma_addr, size).
>
> So my main higher level issue here is the dma_attach_offset_range
> function. I think it should keep the old functionality and just
> set a global range from 0 to (phys_addr_t)-1, and bail out if there
> are DMA ranges already:
>
> int dma_set_global_offset(struct device *dev, u64 offset);
Hi Christoph,
I had it this way in [V1...V5] but Robin requested that for V6 I
should change this function to
o add bounds to the call
o if there is a mapping already, check if what is requested is
already covered and return success.
Can you and Robin please discuss this and let me know which way to move forward?
>
>
> otherwise there is all kinds of minor nitpicks that aren't too
> substantial, let me know what you think of something like this
> hacked up version:
Kind of hard to see what you have changed but I will diff both of our
diffs and make the changes.
Thanks,
Jim Quinlan
Broadcom STB
>
>
> diff --git a/arch/arm/include/asm/dma-mapping.h
> b/arch/arm/include/asm/dma-mapping.h
> index bdd80ddbca3451..2405afeb79573a 100644
> --- a/arch/arm/include/asm/dma-mapping.h
> +++ b/arch/arm/include/asm/dma-mapping.h
> @@ -35,8 +35,11 @@ static inline const struct dma_map_ops
> *get_arch_dma_ops(struct bus_type *bus)
> #ifndef __arch_pfn_to_dma
> static inline dma_addr_t pfn_to_dma(struct device *dev, unsigned long pfn)
> {
> - if (dev)
> - pfn -= dev->dma_pfn_offset;
> + if (dev) {
> + phys_addr_t paddr = PFN_PHYS(pfn);
> +
> + pfn -= (dma_offset_from_phys_addr(dev, paddr) >> PAGE_SHIFT);
> + }
> return (dma_addr_t)__pfn_to_bus(pfn);
> }
>
> @@ -45,8 +48,7 @@ static inline unsigned long dma_to_pfn(struct device *dev,
> dma_addr_t addr)
> unsigned long pfn = __bus_to_pfn(addr);
>
> if (dev)
> - pfn += dev->dma_pfn_offset;
> -
> + pfn += (dma_offset_from_dma_addr(dev, addr) >> PAGE_SHIFT);
> return pfn;
> }
>
> diff --git a/arch/arm/mach-keystone/keystone.c
> b/arch/arm/mach-keystone/keystone.c
> index 638808c4e12247..7539679205fbf7 100644
> --- a/arch/arm/mach-keystone/keystone.c
> +++ b/arch/arm/mach-keystone/keystone.c
> @@ -8,6 +8,7 @@
> */
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -24,8 +25,6 @@
>
> #include "keystone.h"
>
> -static unsigned long keystone_dma_pfn_offset __read_mostly;
> -
> static int keystone_platform_notifier(struct notifier_block *nb,
> unsigned long event, void *data)
> {
> @@ -38,9 +37,12 @@ static int keystone_platform_notifier(struct
> notifier_block *nb,
> return NOTIFY_BAD;
>
> if (!dev->of_node) {
> - dev->dma_pfn_offset = keystone_dma_pfn_offset;
> - dev_err(dev, "set dma_pfn_offset%08lx\n",
> - dev->dma_pfn_offset);
> + int ret = dma_set_offset_range(dev, KEYSTONE_HIGH_PHYS_START,
> + KEYSTONE_LOW_PHYS_START,
> + KEYSTONE_HIGH_PHYS_SIZE);
> + dev_err(dev, "set dma_offset%08llx%s\n",
> + KEYSTONE_HIGH_PHYS_START - KEYSTONE_LOW_PHYS_START,
> + ret ? " failed" : "");
> }
> return NOTIFY_OK;
> }
> @@ -51,11 +53,8 @@ static struct notifier_block platform_nb = {
>
> static void __init keystone_init(void)
> {
> - if (PHYS_OFFSET >= KEYSTONE_HIGH_PHYS_START) {
> - keystone_dma_pfn_offset = PFN_DOWN(KEYSTONE_HIGH_PHYS_START -
> - KEYSTONE_LOW_PHYS_START);
> + if (PHYS_OFFSET >= KEYSTONE_HIGH_PHYS_START)
> bus_register_notifier(&platform_bus_type, &platform_nb);
> - }
> keystone_pm_runtime_init();
> }
>
> diff --git a/arch/sh/drivers/pci/pc
[PATCH] drm: bridge: adv7511: Add missing bridge type
Add bridge type as DRM_MODE_CONNECTOR_HDMIA Signed-off-by: Vinod Koul --- I found this when testing Dragon-board 410c which uses this bridge [6.671913] msm 1a0.mdss: [drm:msm_dsi_manager_ext_bridge_init [msm]] *ERROR* drm_bridge_connector_init failed: -22 [6.678879] msm 1a0.mdss: [drm:msm_dsi_modeset_init [msm]] *ERROR* failed to create dsi connector: -19 drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c index f45cdca9cce5..a0d392c338da 100644 --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c @@ -1283,6 +1283,7 @@ static int adv7511_probe(struct i2c_client *i2c, const struct i2c_device_id *id) adv7511->bridge.ops = DRM_BRIDGE_OP_DETECT | DRM_BRIDGE_OP_EDID | DRM_BRIDGE_OP_HPD; adv7511->bridge.of_node = dev->of_node; + adv7511->bridge.type = DRM_MODE_CONNECTOR_HDMIA; drm_bridge_add(&adv7511->bridge); -- 2.26.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 3/4] drm/bridge: Introduce LT9611 DSI to HDMI bridge
Hi Sam, Laurent,
On 22-07-20, 16:14, Laurent Pinchart wrote:
> > > +static int lt9611_bridge_attach(struct drm_bridge *bridge,
> > > + enum drm_bridge_attach_flags flags)
> > > +{
> > > + struct lt9611 *lt9611 = bridge_to_lt9611(bridge);
> > > + int ret;
> > > +
> > > + if (!(flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)) {
> > > + dev_err(lt9611->dev, "Fix bridge driver to make connector
> > > optional!");
> > > + return -EINVAL;
> > > + }
> >
> > This should say that the display driver should be fixed.
> > If a display driver expects this bridge to create the connector
> > it would not work.
>
> Actually, for new bridge drivers, connector creation should be optional
> from the start. We don't want a failure in that case, the feature should
> be implemented.
Yes this is causing issues for me now !. The patch 4/4 adds support in
msm/dsi but causes regression on qualcomm laptops with ti-sn65dsi86 eDP
bridge. I tried to fix that up with changes like Laurent has done for
adv7511, but it hasnt worked yet for me (remote debug of this is bit
painful)
So I am going to drop patch 4 from this series and add support for both
DRM_BRIDGE_ATTACH_NO_CONNECTOR set and cleared (like we have in adv7511)
so that it can work in both cases, while I fix all bridge uses of
msm/dsi and then we can drop these. Does that sound okay to you folks?
--
~Vinod
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH -resend] Documentation: fb, fix path to modedb.c
modedb.c was moved twice since the modedb documentation was written. Update the path to the current one. Signed-off-by: Jiri Slaby Cc: Bartlomiej Zolnierkiewicz Cc: Jonathan Corbet Cc: dri-devel@lists.freedesktop.org Cc: linux-fb...@vger.kernel.org Cc: linux-...@vger.kernel.org --- Documentation/fb/modedb.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/fb/modedb.rst b/Documentation/fb/modedb.rst index 624d08fd2856..4d2411e32ebb 100644 --- a/Documentation/fb/modedb.rst +++ b/Documentation/fb/modedb.rst @@ -152,7 +152,7 @@ To specify a video mode at bootup, use the following boot options:: video=:x[-][@refresh] where is a name from the table below. Valid default modes can be -found in linux/drivers/video/modedb.c. Check your driver's documentation. +found in drivers/video/fbdev/core/modedb.c. Check your driver's documentation. There may be more modes:: Drivers that support modedb boot options -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [v7, PATCH 1/7] drm/mediatek: move ddp component defint into mtk_mmsys.h
Hi Yongqian Niu,
Thank you for your patch
Missatge de Yongqiang Niu del dia dj., 23
de jul. 2020 a les 4:05:
>
> move ddp component defint into mtk_mmsys.h
>
There is a typo, should be "defines". But why you should move these
defines to mtk-mmsys?
> Signed-off-by: Yongqiang Niu
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 34
> +
> drivers/soc/mediatek/mtk-mmsys.c| 4 +---
> include/linux/soc/mediatek/mtk-mmsys.h | 33
> 3 files changed, 35 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> index debe363..161201f 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> @@ -7,6 +7,7 @@
> #define MTK_DRM_DDP_COMP_H
>
> #include
> +#include
>
> struct device;
> struct device_node;
> @@ -35,39 +36,6 @@ enum mtk_ddp_comp_type {
> MTK_DDP_COMP_TYPE_MAX,
> };
>
> -enum mtk_ddp_comp_id {
> - DDP_COMPONENT_AAL0,
> - DDP_COMPONENT_AAL1,
> - DDP_COMPONENT_BLS,
> - DDP_COMPONENT_CCORR,
> - DDP_COMPONENT_COLOR0,
> - DDP_COMPONENT_COLOR1,
> - DDP_COMPONENT_DITHER,
> - DDP_COMPONENT_DPI0,
> - DDP_COMPONENT_DPI1,
> - DDP_COMPONENT_DSI0,
> - DDP_COMPONENT_DSI1,
> - DDP_COMPONENT_DSI2,
> - DDP_COMPONENT_DSI3,
> - DDP_COMPONENT_GAMMA,
> - DDP_COMPONENT_OD0,
> - DDP_COMPONENT_OD1,
> - DDP_COMPONENT_OVL0,
> - DDP_COMPONENT_OVL_2L0,
> - DDP_COMPONENT_OVL_2L1,
> - DDP_COMPONENT_OVL1,
> - DDP_COMPONENT_PWM0,
> - DDP_COMPONENT_PWM1,
> - DDP_COMPONENT_PWM2,
> - DDP_COMPONENT_RDMA0,
> - DDP_COMPONENT_RDMA1,
> - DDP_COMPONENT_RDMA2,
> - DDP_COMPONENT_UFOE,
> - DDP_COMPONENT_WDMA0,
> - DDP_COMPONENT_WDMA1,
> - DDP_COMPONENT_ID_MAX,
> -};
> -
> struct mtk_ddp_comp;
> struct cmdq_pkt;
> struct mtk_ddp_comp_funcs {
> diff --git a/drivers/soc/mediatek/mtk-mmsys.c
> b/drivers/soc/mediatek/mtk-mmsys.c
> index a55f255..36ad66b 100644
> --- a/drivers/soc/mediatek/mtk-mmsys.c
> +++ b/drivers/soc/mediatek/mtk-mmsys.c
> @@ -5,13 +5,11 @@
> */
>
> #include
> +#include
> #include
> #include
> #include
>
> -#include "../../gpu/drm/mediatek/mtk_drm_ddp.h"
> -#include "../../gpu/drm/mediatek/mtk_drm_ddp_comp.h"
> -
> #define DISP_REG_CONFIG_DISP_OVL0_MOUT_EN 0x040
> #define DISP_REG_CONFIG_DISP_OVL1_MOUT_EN 0x044
> #define DISP_REG_CONFIG_DISP_OD_MOUT_EN0x048
> diff --git a/include/linux/soc/mediatek/mtk-mmsys.h
> b/include/linux/soc/mediatek/mtk-mmsys.h
> index 7bab5d9..2228bf6 100644
> --- a/include/linux/soc/mediatek/mtk-mmsys.h
> +++ b/include/linux/soc/mediatek/mtk-mmsys.h
> @@ -9,6 +9,39 @@
> enum mtk_ddp_comp_id;
> struct device;
>
> +enum mtk_ddp_comp_id {
> + DDP_COMPONENT_AAL0,
> + DDP_COMPONENT_AAL1,
> + DDP_COMPONENT_BLS,
> + DDP_COMPONENT_CCORR,
> + DDP_COMPONENT_COLOR0,
> + DDP_COMPONENT_COLOR1,
> + DDP_COMPONENT_DITHER,
> + DDP_COMPONENT_DPI0,
> + DDP_COMPONENT_DPI1,
> + DDP_COMPONENT_DSI0,
> + DDP_COMPONENT_DSI1,
> + DDP_COMPONENT_DSI2,
> + DDP_COMPONENT_DSI3,
> + DDP_COMPONENT_GAMMA,
> + DDP_COMPONENT_OD0,
> + DDP_COMPONENT_OD1,
> + DDP_COMPONENT_OVL0,
> + DDP_COMPONENT_OVL_2L0,
> + DDP_COMPONENT_OVL_2L1,
> + DDP_COMPONENT_OVL1,
> + DDP_COMPONENT_PWM0,
> + DDP_COMPONENT_PWM1,
> + DDP_COMPONENT_PWM2,
> + DDP_COMPONENT_RDMA0,
> + DDP_COMPONENT_RDMA1,
> + DDP_COMPONENT_RDMA2,
> + DDP_COMPONENT_UFOE,
> + DDP_COMPONENT_WDMA0,
> + DDP_COMPONENT_WDMA1,
> + DDP_COMPONENT_ID_MAX,
> +};
> +
> void mtk_mmsys_ddp_connect(struct device *dev,
>enum mtk_ddp_comp_id cur,
>enum mtk_ddp_comp_id next);
> --
> 1.8.1.1.dirty
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [v7, PATCH 2/7] mtk-mmsys: add mmsys private data
Hi Yongqiang Niu, Thank you for your patch. Missatge de Yongqiang Niu del dia dj., 23 de jul. 2020 a les 4:05: > > add mmsys private data > I think this change requires a better explanation of what you are doing. Although I'm really uncomfortable with this change, why you need to create a new mt2701-mmsys file? > Feature: drm/mediatek Remove this. > Signed-off-by: Yongqiang Niu > --- > drivers/soc/mediatek/Makefile | 1 + > drivers/soc/mediatek/mmsys/Makefile | 2 + > drivers/soc/mediatek/mmsys/mt2701-mmsys.c | 250 +++ > drivers/soc/mediatek/mtk-mmsys.c | 271 > +- > include/linux/soc/mediatek/mtk-mmsys.h| 15 ++ > 5 files changed, 314 insertions(+), 225 deletions(-) > create mode 100644 drivers/soc/mediatek/mmsys/Makefile > create mode 100644 drivers/soc/mediatek/mmsys/mt2701-mmsys.c > > diff --git a/drivers/soc/mediatek/Makefile b/drivers/soc/mediatek/Makefile > index 2afa7b9..b37ac2c 100644 > --- a/drivers/soc/mediatek/Makefile > +++ b/drivers/soc/mediatek/Makefile > @@ -3,3 +3,4 @@ obj-$(CONFIG_MTK_CMDQ) += mtk-cmdq-helper.o > obj-$(CONFIG_MTK_PMIC_WRAP) += mtk-pmic-wrap.o > obj-$(CONFIG_MTK_SCPSYS) += mtk-scpsys.o > obj-$(CONFIG_MTK_MMSYS) += mtk-mmsys.o > +obj-$(CONFIG_MTK_MMSYS) += mmsys/ > diff --git a/drivers/soc/mediatek/mmsys/Makefile > b/drivers/soc/mediatek/mmsys/Makefile > new file mode 100644 > index 000..33b0dab > --- /dev/null > +++ b/drivers/soc/mediatek/mmsys/Makefile > @@ -0,0 +1,2 @@ > +# SPDX-License-Identifier: GPL-2.0-only > +obj-y += mt2701-mmsys.o > diff --git a/drivers/soc/mediatek/mmsys/mt2701-mmsys.c > b/drivers/soc/mediatek/mmsys/mt2701-mmsys.c > new file mode 100644 > index 000..b8e53b0 > --- /dev/null > +++ b/drivers/soc/mediatek/mmsys/mt2701-mmsys.c > @@ -0,0 +1,250 @@ > +// SPDX-License-Identifier: GPL-2.0 > +// > +// Copyright (c) 2020 MediaTek Inc. > + > +#include > +#include > +#include > +#include > +#include > + > +#define DISP_REG_CONFIG_DISP_OVL0_MOUT_EN 0x040 > +#define DISP_REG_CONFIG_DISP_OVL1_MOUT_EN 0x044 > +#define DISP_REG_CONFIG_DISP_OD_MOUT_EN0x048 > +#define DISP_REG_CONFIG_DISP_GAMMA_MOUT_EN 0x04c > +#define DISP_REG_CONFIG_DISP_UFOE_MOUT_EN 0x050 > +#define DISP_REG_CONFIG_DISP_COLOR0_SEL_IN 0x084 > +#define DISP_REG_CONFIG_DISP_COLOR1_SEL_IN 0x088 > +#define DISP_REG_CONFIG_DSIE_SEL_IN0x0a4 > +#define DISP_REG_CONFIG_DSIO_SEL_IN0x0a8 > +#define DISP_REG_CONFIG_DPI_SEL_IN 0x0ac > +#define DISP_REG_CONFIG_DISP_RDMA2_SOUT0x0b8 > +#define DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN 0x0c4 > +#define DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN 0x0c8 > +#define DISP_REG_CONFIG_MMSYS_CG_CON0 0x100 > + > +#define DISP_REG_CONFIG_DISP_OVL_MOUT_EN 0x030 > +#define DISP_REG_CONFIG_OUT_SEL0x04c > +#define DISP_REG_CONFIG_DSI_SEL0x050 > +#define DISP_REG_CONFIG_DPI_SEL0x064 > + > +#define OVL0_MOUT_EN_COLOR00x1 > +#define OD_MOUT_EN_RDMA0 0x1 > +#define OD1_MOUT_EN_RDMA1 BIT(16) > +#define UFOE_MOUT_EN_DSI0 0x1 > +#define COLOR0_SEL_IN_OVL0 0x1 > +#define OVL1_MOUT_EN_COLOR10x1 > +#define GAMMA_MOUT_EN_RDMA10x1 > +#define RDMA0_SOUT_DPI00x2 > +#define RDMA0_SOUT_DPI10x3 > +#define RDMA0_SOUT_DSI10x1 > +#define RDMA0_SOUT_DSI20x4 > +#define RDMA0_SOUT_DSI30x5 > +#define RDMA1_SOUT_DPI00x2 > +#define RDMA1_SOUT_DPI10x3 > +#define RDMA1_SOUT_DSI10x1 > +#define RDMA1_SOUT_DSI20x4 > +#define RDMA1_SOUT_DSI30x5 > +#define RDMA2_SOUT_DPI00x2 > +#define RDMA2_SOUT_DPI10x3 > +#define RDMA2_SOUT_DSI10x1 > +#define RDMA2_SOUT_DSI20x4 > +#define RDMA2_SOUT_DSI30x5 > +#define DPI0_SEL_IN_RDMA1 0x1 > +#define DPI0_SEL_IN_RDMA2 0x3 > +#define DPI1_SEL_IN_RDMA1 (0x1 << 8) > +#define DPI1_SEL_IN_RDMA2 (0x3 << 8) > +#define DSI0_SEL_IN_RDMA1 0x1 > +#define DSI0_SEL_IN_RDMA2 0x4 > +#define DSI1_SEL_IN_RDMA1 0x1 > +#define DSI1_SEL_IN_RDMA2 0x4 > +#define DSI2_SEL_IN_RDMA1 (0x1 << 16) > +#define DSI2_SEL_IN_RDMA2 (0x4 << 16) > +#define DSI3_SEL_IN_RDMA1 (0x1 << 1
Re: [PATCH] drm/simple_kms_helper: add drmm_simple_encoder_init()
On Thu, Jul 23, 2020 at 11:13 AM Thomas Zimmermann wrote:
>
> Hi
>
> Am 23.07.20 um 11:05 schrieb Daniel Vetter:
> > On Thu, Jul 23, 2020 at 9:36 AM Thomas Zimmermann
> > wrote:
> >>
> >> Hi
> >>
> >> I have meanwhile seen your imx patchset where this would be useful.
> >>
> >> I still think you should try to pre-allocated all encoders up to a
> >> limit, so that an extra drmm_kzalloc() is not required. But see my
> >> comments below.
> >
> > Uh preallocation is horribly, because you need to first preallocate
> > all encoders, then call drmm_mode_config_init, and only then can you
> > call drm_encoder_init. That's terrible flow, and I'm aware of the
>
> Out of curiosity, what's the problem with the code flow? If you embed
> everything in the device's structure, you'd pre-allocate automatically.
> Then acquire one of the encoders just before drm_encoder_init(). Sure,
> it needs a little helper to acquire and release the preallocated encoder
> memory, but that's not that bad.
This is fine for tiny drivers, it's totally non-workable for big
drivers where the number of encoder/connector we need are very dynamic
(depending upon which platform you run on). Try doing this with admgpu
or some similar complex driver, it just doesn't work.
-Daniel
>
> Best regards
> Thomas
>
> > problem. That's why we need new set of drmm_ helpers to do all the
> > steps for kms static object setup, if we actually want to improve
> > things.
> > -Daniel
> >
> >>
> >> Am 22.07.20 um 15:25 schrieb Philipp Zabel:
> >>> Add a drm_simple_encoder_init() variant that registers
> >>> drm_encoder_cleanup() with drmm_add_action().
> >>>
> >>> Now drivers can store encoders in memory allocated with drmm_kmalloc()
> >>> after the call to drmm_mode_config_init(), without having to manually
> >>> make sure that drm_encoder_cleanup() is called before the memory is
> >>> freed.
> >>>
> >>> Signed-off-by: Philipp Zabel
> >>> ---
> >>> drivers/gpu/drm/drm_simple_kms_helper.c | 42 +
> >>> include/drm/drm_simple_kms_helper.h | 4 +++
> >>> 2 files changed, 46 insertions(+)
> >>>
> >>> diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c
> >>> b/drivers/gpu/drm/drm_simple_kms_helper.c
> >>> index 74946690aba4..a243f00cf63d 100644
> >>> --- a/drivers/gpu/drm/drm_simple_kms_helper.c
> >>> +++ b/drivers/gpu/drm/drm_simple_kms_helper.c
> >>> @@ -9,6 +9,7 @@
> >>> #include
> >>> #include
> >>> #include
> >>> +#include
> >>> #include
> >>> #include
> >>> #include
> >>> @@ -71,6 +72,47 @@ int drm_simple_encoder_init(struct drm_device *dev,
> >>> }
> >>> EXPORT_SYMBOL(drm_simple_encoder_init);
> >>>
> >>> +static void drmm_encoder_cleanup(struct drm_device *dev, void *ptr)
> >>
> >> It's the reset helper, so drmm_simple_encoder_reset() would be appropriate.
> >>
> >>> +{
> >>> + struct drm_encoder *encoder = ptr;
> >>> +
> >>> + drm_encoder_cleanup(encoder);
> >>
> >> This should first check for (encoder->dev) being true. If drivers
> >> somehow manage to clean-up the mode config first, we should detect it. I
> >> know it's a bug, but I wouldn't trust drivers with that.
> >>
> >>> +}
> >>> +
> >>> +/**
> >>> + * drmm_simple_encoder_init - Initialize a preallocated encoder with
> >>> + *basic functionality.
> >>> + * @dev: drm device
> >>> + * @encoder: the encoder to initialize
> >>> + * @encoder_type: user visible type of the encoder
> >>> + *
> >>> + * Initialises a preallocated encoder that has no further functionality.
> >>
> >> 'Initializes'
> >>
> >>> + * Settings for possible CRTC and clones are left to their initial
> >>> values.
> >>> + * Cleanup is automatically handled through registering
> >>> drm_encoder_cleanup()
> >>> + * with drmm_add_action().
> >>> + *
> >>> + * The caller of drmm_simple_encoder_init() is responsible for allocating
> >>> + * the encoder's memory with drmm_kzalloc() to ensure it is automatically
> >>> + * freed after the encoder has been cleaned up.
> >>> + *
> >>
> >> The idiomatic way of cleaning up an encoder is via mode-config cleanup.
> >> This interface is an exception for a corner case. So there needs to be a
> >> paragraph that clearly explains the corner case. Please also discourage
> >> from using drmm_simple_encoder_init() if drm_simple_encoder_init() would
> >> work.
> >>
> >> Best regards
> >> Thomas
> >>
> >>> + * Returns:
> >>> + * Zero on success, error code on failure.
> >>> + */
> >>> +int drmm_simple_encoder_init(struct drm_device *dev,
> >>> + struct drm_encoder *encoder,
> >>> + int encoder_type)
> >>> +{
> >>> + int ret;
> >>> +
> >>> + ret = drm_encoder_init(dev, encoder,
> >>> &drm_simple_encoder_funcs_cleanup,
> >>> +encoder_type, NULL);
> >>> + if (ret)
> >>> + return ret;
> >>> +
> >>> + return drmm_add_action_or_reset(dev, drmm_encoder_cleanup, encoder);
> >>> +}
> >>> +EXPORT_SYMBOL(drmm_simple_encoder_i
Re: [PATCH] drm/simple_kms_helper: add drmm_simple_encoder_init()
Hi
Am 23.07.20 um 11:05 schrieb Daniel Vetter:
> On Thu, Jul 23, 2020 at 9:36 AM Thomas Zimmermann wrote:
>>
>> Hi
>>
>> I have meanwhile seen your imx patchset where this would be useful.
>>
>> I still think you should try to pre-allocated all encoders up to a
>> limit, so that an extra drmm_kzalloc() is not required. But see my
>> comments below.
>
> Uh preallocation is horribly, because you need to first preallocate
> all encoders, then call drmm_mode_config_init, and only then can you
> call drm_encoder_init. That's terrible flow, and I'm aware of the
Out of curiosity, what's the problem with the code flow? If you embed
everything in the device's structure, you'd pre-allocate automatically.
Then acquire one of the encoders just before drm_encoder_init(). Sure,
it needs a little helper to acquire and release the preallocated encoder
memory, but that's not that bad.
Best regards
Thomas
> problem. That's why we need new set of drmm_ helpers to do all the
> steps for kms static object setup, if we actually want to improve
> things.
> -Daniel
>
>>
>> Am 22.07.20 um 15:25 schrieb Philipp Zabel:
>>> Add a drm_simple_encoder_init() variant that registers
>>> drm_encoder_cleanup() with drmm_add_action().
>>>
>>> Now drivers can store encoders in memory allocated with drmm_kmalloc()
>>> after the call to drmm_mode_config_init(), without having to manually
>>> make sure that drm_encoder_cleanup() is called before the memory is
>>> freed.
>>>
>>> Signed-off-by: Philipp Zabel
>>> ---
>>> drivers/gpu/drm/drm_simple_kms_helper.c | 42 +
>>> include/drm/drm_simple_kms_helper.h | 4 +++
>>> 2 files changed, 46 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c
>>> b/drivers/gpu/drm/drm_simple_kms_helper.c
>>> index 74946690aba4..a243f00cf63d 100644
>>> --- a/drivers/gpu/drm/drm_simple_kms_helper.c
>>> +++ b/drivers/gpu/drm/drm_simple_kms_helper.c
>>> @@ -9,6 +9,7 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>> #include
>>> #include
>>> #include
>>> @@ -71,6 +72,47 @@ int drm_simple_encoder_init(struct drm_device *dev,
>>> }
>>> EXPORT_SYMBOL(drm_simple_encoder_init);
>>>
>>> +static void drmm_encoder_cleanup(struct drm_device *dev, void *ptr)
>>
>> It's the reset helper, so drmm_simple_encoder_reset() would be appropriate.
>>
>>> +{
>>> + struct drm_encoder *encoder = ptr;
>>> +
>>> + drm_encoder_cleanup(encoder);
>>
>> This should first check for (encoder->dev) being true. If drivers
>> somehow manage to clean-up the mode config first, we should detect it. I
>> know it's a bug, but I wouldn't trust drivers with that.
>>
>>> +}
>>> +
>>> +/**
>>> + * drmm_simple_encoder_init - Initialize a preallocated encoder with
>>> + *basic functionality.
>>> + * @dev: drm device
>>> + * @encoder: the encoder to initialize
>>> + * @encoder_type: user visible type of the encoder
>>> + *
>>> + * Initialises a preallocated encoder that has no further functionality.
>>
>> 'Initializes'
>>
>>> + * Settings for possible CRTC and clones are left to their initial values.
>>> + * Cleanup is automatically handled through registering
>>> drm_encoder_cleanup()
>>> + * with drmm_add_action().
>>> + *
>>> + * The caller of drmm_simple_encoder_init() is responsible for allocating
>>> + * the encoder's memory with drmm_kzalloc() to ensure it is automatically
>>> + * freed after the encoder has been cleaned up.
>>> + *
>>
>> The idiomatic way of cleaning up an encoder is via mode-config cleanup.
>> This interface is an exception for a corner case. So there needs to be a
>> paragraph that clearly explains the corner case. Please also discourage
>> from using drmm_simple_encoder_init() if drm_simple_encoder_init() would
>> work.
>>
>> Best regards
>> Thomas
>>
>>> + * Returns:
>>> + * Zero on success, error code on failure.
>>> + */
>>> +int drmm_simple_encoder_init(struct drm_device *dev,
>>> + struct drm_encoder *encoder,
>>> + int encoder_type)
>>> +{
>>> + int ret;
>>> +
>>> + ret = drm_encoder_init(dev, encoder,
>>> &drm_simple_encoder_funcs_cleanup,
>>> +encoder_type, NULL);
>>> + if (ret)
>>> + return ret;
>>> +
>>> + return drmm_add_action_or_reset(dev, drmm_encoder_cleanup, encoder);
>>> +}
>>> +EXPORT_SYMBOL(drmm_simple_encoder_init);
>>> +
>>> static enum drm_mode_status
>>> drm_simple_kms_crtc_mode_valid(struct drm_crtc *crtc,
>>> const struct drm_display_mode *mode)
>>> diff --git a/include/drm/drm_simple_kms_helper.h
>>> b/include/drm/drm_simple_kms_helper.h
>>> index a026375464ff..27f0915599c8 100644
>>> --- a/include/drm/drm_simple_kms_helper.h
>>> +++ b/include/drm/drm_simple_kms_helper.h
>>> @@ -185,4 +185,8 @@ int drm_simple_encoder_init(struct drm_device *dev,
>>> struct drm_encoder *encoder,
>>> int encoder_type);
>>
[PATCH 2/2] drm/meson: overlay: fix Amlogic Compressed Framebuffer modifier layout extract
The bitwise operation worked because the result is casted in a lower bits
integer, and was not changed after the modifier defines rework.
Use the correct operation as already used in meson_overlay_atomic_update().
Fixes: e860785d5730 ("drm/meson: overlay: setup overlay for Amlogic FBC")
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/meson_overlay.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_overlay.c
b/drivers/gpu/drm/meson/meson_overlay.c
index a8bcc70644df..83ec613bbfb6 100644
--- a/drivers/gpu/drm/meson/meson_overlay.c
+++ b/drivers/gpu/drm/meson/meson_overlay.c
@@ -756,8 +756,7 @@ static bool meson_overlay_format_mod_supported(struct
drm_plane *plane,
if ((modifier & DRM_FORMAT_MOD_AMLOGIC_FBC(0, 0)) ==
DRM_FORMAT_MOD_AMLOGIC_FBC(0, 0)) {
unsigned int layout = modifier &
- DRM_FORMAT_MOD_AMLOGIC_FBC(
- __fourcc_mod_amlogic_layout_mask, 0);
+ __fourcc_mod_amlogic_layout_mask;
unsigned int options =
(modifier >> __fourcc_mod_amlogic_options_shift) &
__fourcc_mod_amlogic_options_mask;
--
2.22.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/fourcc: fix Amlogic Video Framebuffer Compression macro
Fix the Amlogic Video Framebuffer Compression modifier macro to
correctly add the layout options, a pair of parenthesis was missing.
Fixes: d6528ec88309 ("drm/fourcc: Add modifier definitions for describing
Amlogic Video Framebuffer Compression")
Signed-off-by: Neil Armstrong
---
include/uapi/drm/drm_fourcc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 4bee7de5f306..82f327801267 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -1004,7 +1004,7 @@ drm_fourcc_canonicalize_nvidia_format_mod(__u64 modifier)
#define DRM_FORMAT_MOD_AMLOGIC_FBC(__layout, __options) \
fourcc_mod_code(AMLOGIC, \
((__layout) & __fourcc_mod_amlogic_layout_mask) | \
- ((__options) & __fourcc_mod_amlogic_options_mask \
+ (((__options) & __fourcc_mod_amlogic_options_mask) \
<< __fourcc_mod_amlogic_options_shift))
/* Amlogic FBC Layouts */
--
2.22.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/simple_kms_helper: add drmm_simple_encoder_init()
On Thu, Jul 23, 2020 at 9:36 AM Thomas Zimmermann wrote:
>
> Hi
>
> I have meanwhile seen your imx patchset where this would be useful.
>
> I still think you should try to pre-allocated all encoders up to a
> limit, so that an extra drmm_kzalloc() is not required. But see my
> comments below.
Uh preallocation is horribly, because you need to first preallocate
all encoders, then call drmm_mode_config_init, and only then can you
call drm_encoder_init. That's terrible flow, and I'm aware of the
problem. That's why we need new set of drmm_ helpers to do all the
steps for kms static object setup, if we actually want to improve
things.
-Daniel
>
> Am 22.07.20 um 15:25 schrieb Philipp Zabel:
> > Add a drm_simple_encoder_init() variant that registers
> > drm_encoder_cleanup() with drmm_add_action().
> >
> > Now drivers can store encoders in memory allocated with drmm_kmalloc()
> > after the call to drmm_mode_config_init(), without having to manually
> > make sure that drm_encoder_cleanup() is called before the memory is
> > freed.
> >
> > Signed-off-by: Philipp Zabel
> > ---
> > drivers/gpu/drm/drm_simple_kms_helper.c | 42 +
> > include/drm/drm_simple_kms_helper.h | 4 +++
> > 2 files changed, 46 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c
> > b/drivers/gpu/drm/drm_simple_kms_helper.c
> > index 74946690aba4..a243f00cf63d 100644
> > --- a/drivers/gpu/drm/drm_simple_kms_helper.c
> > +++ b/drivers/gpu/drm/drm_simple_kms_helper.c
> > @@ -9,6 +9,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -71,6 +72,47 @@ int drm_simple_encoder_init(struct drm_device *dev,
> > }
> > EXPORT_SYMBOL(drm_simple_encoder_init);
> >
> > +static void drmm_encoder_cleanup(struct drm_device *dev, void *ptr)
>
> It's the reset helper, so drmm_simple_encoder_reset() would be appropriate.
>
> > +{
> > + struct drm_encoder *encoder = ptr;
> > +
> > + drm_encoder_cleanup(encoder);
>
> This should first check for (encoder->dev) being true. If drivers
> somehow manage to clean-up the mode config first, we should detect it. I
> know it's a bug, but I wouldn't trust drivers with that.
>
> > +}
> > +
> > +/**
> > + * drmm_simple_encoder_init - Initialize a preallocated encoder with
> > + *basic functionality.
> > + * @dev: drm device
> > + * @encoder: the encoder to initialize
> > + * @encoder_type: user visible type of the encoder
> > + *
> > + * Initialises a preallocated encoder that has no further functionality.
>
> 'Initializes'
>
> > + * Settings for possible CRTC and clones are left to their initial values.
> > + * Cleanup is automatically handled through registering
> > drm_encoder_cleanup()
> > + * with drmm_add_action().
> > + *
> > + * The caller of drmm_simple_encoder_init() is responsible for allocating
> > + * the encoder's memory with drmm_kzalloc() to ensure it is automatically
> > + * freed after the encoder has been cleaned up.
> > + *
>
> The idiomatic way of cleaning up an encoder is via mode-config cleanup.
> This interface is an exception for a corner case. So there needs to be a
> paragraph that clearly explains the corner case. Please also discourage
> from using drmm_simple_encoder_init() if drm_simple_encoder_init() would
> work.
>
> Best regards
> Thomas
>
> > + * Returns:
> > + * Zero on success, error code on failure.
> > + */
> > +int drmm_simple_encoder_init(struct drm_device *dev,
> > + struct drm_encoder *encoder,
> > + int encoder_type)
> > +{
> > + int ret;
> > +
> > + ret = drm_encoder_init(dev, encoder,
> > &drm_simple_encoder_funcs_cleanup,
> > +encoder_type, NULL);
> > + if (ret)
> > + return ret;
> > +
> > + return drmm_add_action_or_reset(dev, drmm_encoder_cleanup, encoder);
> > +}
> > +EXPORT_SYMBOL(drmm_simple_encoder_init);
> > +
> > static enum drm_mode_status
> > drm_simple_kms_crtc_mode_valid(struct drm_crtc *crtc,
> > const struct drm_display_mode *mode)
> > diff --git a/include/drm/drm_simple_kms_helper.h
> > b/include/drm/drm_simple_kms_helper.h
> > index a026375464ff..27f0915599c8 100644
> > --- a/include/drm/drm_simple_kms_helper.h
> > +++ b/include/drm/drm_simple_kms_helper.h
> > @@ -185,4 +185,8 @@ int drm_simple_encoder_init(struct drm_device *dev,
> > struct drm_encoder *encoder,
> > int encoder_type);
> >
> > +int drmm_simple_encoder_init(struct drm_device *dev,
> > + struct drm_encoder *encoder,
> > + int encoder_type);
> > +
> > #endif /* __LINUX_DRM_SIMPLE_KMS_HELPER_H */
> >
>
> --
> 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
>
>
[PATCH] drm/ttm: fix pipelined gutting for evictions
We can't pipeline that during eviction because the memory needs
to be available immediately.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index bc2230ecb7e3..122040056a07 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -651,8 +651,16 @@ static int ttm_bo_evict(struct ttm_buffer_object *bo,
placement.num_busy_placement = 0;
bdev->driver->evict_flags(bo, &placement);
- if (!placement.num_placement && !placement.num_busy_placement)
- return ttm_bo_pipeline_gutting(bo);
+ if (!placement.num_placement && !placement.num_busy_placement) {
+ ttm_bo_wait(bo, false, false);
+
+ ttm_tt_destroy(bo->ttm);
+
+ memset(&bo->mem, 0, sizeof(bo->mem));
+ bo->mem.mem_type = TTM_PL_SYSTEM;
+ bo->ttm = NULL;
+ return 0;
+ }
evict_mem = bo->mem;
evict_mem.mm_node = NULL;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: manual merge of the amdgpu tree with Linus' tree
On Wed, Jul 22, 2020 at 6:34 AM Stephen Rothwell wrote:
>
> Hi all,
>
> [I can't find a previous email about this, sorry ...]
>
> There is a semantic conflict between Linus' tree and the amdgpu tree
> between commit
>
> d7a6634a4cfb ("drm/amdgpu/atomfirmware: fix vram_info fetching for renoir")
>
> from Linus' tree and commts
>
> fe098a5d6443 ("drm/amdgpu/atomfirmware: fix vram_info fetching for renoir")
> 836dab851903 ("drm/amdgpu/atomfirmware: update vram info handling for
> renoir")
>
> The automted git merge leaves two "case 12" labels. I have been
> reverting commit d7a6634a4cfb since July 3 ... This will need to be
> fixed up when the amdgpu tree is next merged into the drm tree, or a back
> merge of d7a6634a4cfb could be done into the amdgpu tree and the older
> "case 12" label removed in that merge.
Yeah this is a bit nasty, I just crashed over it too (btw moved to
drm-next now). Alex is this the right conflict resolution for -next? I
think we should bake this in with a backmerge ...
-Daniel
>
> --
> Cheers,
> Stephen Rothwell
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/simple_kms_helper: add drmm_simple_encoder_init()
Hi
I have meanwhile seen your imx patchset where this would be useful.
I still think you should try to pre-allocated all encoders up to a
limit, so that an extra drmm_kzalloc() is not required. But see my
comments below.
Am 22.07.20 um 15:25 schrieb Philipp Zabel:
> Add a drm_simple_encoder_init() variant that registers
> drm_encoder_cleanup() with drmm_add_action().
>
> Now drivers can store encoders in memory allocated with drmm_kmalloc()
> after the call to drmm_mode_config_init(), without having to manually
> make sure that drm_encoder_cleanup() is called before the memory is
> freed.
>
> Signed-off-by: Philipp Zabel
> ---
> drivers/gpu/drm/drm_simple_kms_helper.c | 42 +
> include/drm/drm_simple_kms_helper.h | 4 +++
> 2 files changed, 46 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c
> b/drivers/gpu/drm/drm_simple_kms_helper.c
> index 74946690aba4..a243f00cf63d 100644
> --- a/drivers/gpu/drm/drm_simple_kms_helper.c
> +++ b/drivers/gpu/drm/drm_simple_kms_helper.c
> @@ -9,6 +9,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -71,6 +72,47 @@ int drm_simple_encoder_init(struct drm_device *dev,
> }
> EXPORT_SYMBOL(drm_simple_encoder_init);
>
> +static void drmm_encoder_cleanup(struct drm_device *dev, void *ptr)
It's the reset helper, so drmm_simple_encoder_reset() would be appropriate.
> +{
> + struct drm_encoder *encoder = ptr;
> +
> + drm_encoder_cleanup(encoder);
This should first check for (encoder->dev) being true. If drivers
somehow manage to clean-up the mode config first, we should detect it. I
know it's a bug, but I wouldn't trust drivers with that.
> +}
> +
> +/**
> + * drmm_simple_encoder_init - Initialize a preallocated encoder with
> + *basic functionality.
> + * @dev: drm device
> + * @encoder: the encoder to initialize
> + * @encoder_type: user visible type of the encoder
> + *
> + * Initialises a preallocated encoder that has no further functionality.
'Initializes'
> + * Settings for possible CRTC and clones are left to their initial values.
> + * Cleanup is automatically handled through registering drm_encoder_cleanup()
> + * with drmm_add_action().
> + *
> + * The caller of drmm_simple_encoder_init() is responsible for allocating
> + * the encoder's memory with drmm_kzalloc() to ensure it is automatically
> + * freed after the encoder has been cleaned up.
> + *
The idiomatic way of cleaning up an encoder is via mode-config cleanup.
This interface is an exception for a corner case. So there needs to be a
paragraph that clearly explains the corner case. Please also discourage
from using drmm_simple_encoder_init() if drm_simple_encoder_init() would
work.
Best regards
Thomas
> + * Returns:
> + * Zero on success, error code on failure.
> + */
> +int drmm_simple_encoder_init(struct drm_device *dev,
> + struct drm_encoder *encoder,
> + int encoder_type)
> +{
> + int ret;
> +
> + ret = drm_encoder_init(dev, encoder, &drm_simple_encoder_funcs_cleanup,
> +encoder_type, NULL);
> + if (ret)
> + return ret;
> +
> + return drmm_add_action_or_reset(dev, drmm_encoder_cleanup, encoder);
> +}
> +EXPORT_SYMBOL(drmm_simple_encoder_init);
> +
> static enum drm_mode_status
> drm_simple_kms_crtc_mode_valid(struct drm_crtc *crtc,
> const struct drm_display_mode *mode)
> diff --git a/include/drm/drm_simple_kms_helper.h
> b/include/drm/drm_simple_kms_helper.h
> index a026375464ff..27f0915599c8 100644
> --- a/include/drm/drm_simple_kms_helper.h
> +++ b/include/drm/drm_simple_kms_helper.h
> @@ -185,4 +185,8 @@ int drm_simple_encoder_init(struct drm_device *dev,
> struct drm_encoder *encoder,
> int encoder_type);
>
> +int drmm_simple_encoder_init(struct drm_device *dev,
> + struct drm_encoder *encoder,
> + int encoder_type);
> +
> #endif /* __LINUX_DRM_SIMPLE_KMS_HELPER_H */
>
--
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
signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 208661] Backlight doesn't work with both nv_backlight and acpi_video
https://bugzilla.kernel.org/show_bug.cgi?id=208661 --- Comment #2 from Shannon Gaines (iknstu...@protonmail.com) --- Update: nvidia-legacy-390xx driver allows me to change the backlight via acpi_video0, however nouveau doesn't under any circumstances. No clue why. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 208661] Backlight doesn't work with both nv_backlight and acpi_video
https://bugzilla.kernel.org/show_bug.cgi?id=208661 --- Comment #1 from Shannon Gaines (iknstu...@protonmail.com) --- Created attachment 290477 --> https://bugzilla.kernel.org/attachment.cgi?id=290477&action=edit acpidump.txt -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH -next] dma-fence: Make symbol 'dma_fence_lockdep_map' static
The sparse tool complains as follows:
drivers/dma-buf/dma-fence.c:249:25: warning:
symbol 'dma_fence_lockdep_map' was not declared. Should it be static?
This variable is not used outside of dma-fence.c, so this commit
marks it static.
Fixes: 5fbff813a4a3 ("dma-fence: basic lockdep annotations")
Reported-by: Hulk Robot
Signed-off-by: Wei Yongjun
---
drivers/dma-buf/dma-fence.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index af1d8ea926b3..43624b4ee13d 100644
--- a/drivers/dma-buf/dma-fence.c
+++ b/drivers/dma-buf/dma-fence.c
@@ -246,7 +246,7 @@ EXPORT_SYMBOL(dma_fence_context_alloc);
* concerned.
*/
#ifdef CONFIG_LOCKDEP
-struct lockdep_map dma_fence_lockdep_map = {
+static struct lockdep_map dma_fence_lockdep_map = {
.name = "dma_fence_map"
};
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[v7, PATCH 4/7] dt-bindings: mediatek: add rdma_fifo_size description for mt8183 display
Update device tree binding document for rdma_fifo_size
Signed-off-by: Yongqiang Niu
---
.../devicetree/bindings/display/mediatek/mediatek,disp.txt | 14 ++
1 file changed, 14 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
index b91e709..e6bbe32 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
@@ -66,6 +66,11 @@ Required properties (DMA function blocks):
argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
for details.
+Optional properties (RDMA function blocks):
+- mediatek,rdma_fifo_size: rdma fifo size may be different even in same SOC,
add this
+ property to the corresponding rdma
+ the value is the Max value which defined in hardware data sheet.
+
Examples:
mmsys: clock-controller@1400 {
@@ -207,3 +212,12 @@ od@14023000 {
power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
clocks = <&mmsys CLK_MM_DISP_OD>;
};
+
+rdma1: rdma@1400c000 {
+ compatible = "mediatek,mt8183-disp-rdma";
+ reg = <0 0x1400c000 0 0x1000>;
+ interrupts = ;
+ power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
+ clocks = <&mmsys CLK_MM_DISP_RDMA1>;
+ mediatek,rdma_fifo_size = <2048>;
+};
--
1.8.1.1.dirty
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH -next 1/2] drm: Remove redundant NULL check
Fix below warnings reported by coccicheck:
./drivers/gpu/drm/drm_drv.c:819:2-7: WARNING: NULL check before some freeing
functions is not needed.
Fixes: 5dad34f3c444 ("drm: Cleanups after drmm_add_final_kfree rollout")
Signed-off-by: Li Heng
---
drivers/gpu/drm/drm_drv.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index bc38322..13068fd 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -815,8 +815,7 @@ static void drm_dev_release(struct kref *ref)
drm_managed_release(dev);
- if (dev->managed.final_kfree)
- kfree(dev->managed.final_kfree);
+ kfree(dev->managed.final_kfree);
}
/**
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/5] drm: rockchip: add missing registers for RK3188
Add dither_up, dsp_lut_en and data_blank registers to enable their
respective functionality for RK3188's VOP.
Signed-off-by: Alex Bee
---
Changes in v2:
- drop the not yet upstreamed dsp_data_swap and rephrase the commit
message according
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index b046910129fb..a50877818a86 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -512,6 +512,9 @@ static const struct vop_common rk3188_common = {
.dither_down_en = VOP_REG(RK3188_DSP_CTRL0, 0x1, 11),
.dither_down_mode = VOP_REG(RK3188_DSP_CTRL0, 0x1, 10),
.dsp_blank = VOP_REG(RK3188_DSP_CTRL1, 0x3, 24),
+ .dither_up = VOP_REG(RK3188_DSP_CTRL0, 0x1, 9),
+ .dsp_lut_en = VOP_REG(RK3188_SYS_CTRL, 0x1, 28),
+ .data_blank = VOP_REG(RK3188_DSP_CTRL1, 0x1, 25),
};
static const struct vop_win_data rk3188_vop_win_data[] = {
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[v7, PATCH 6/7] drm/mediatek: add fifo_size into rdma private data
the fifo size of rdma in mt8183 is different.
rdma0 fifo size is 5k
rdma1 fifo size is 2k
Signed-off-by: Yongqiang Niu
---
drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
index e04319f..794acc5 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
@@ -63,6 +63,7 @@ struct mtk_disp_rdma {
struct mtk_ddp_comp ddp_comp;
struct drm_crtc *crtc;
const struct mtk_disp_rdma_data *data;
+ u32 fifo_size;
};
static inline struct mtk_disp_rdma *comp_to_rdma(struct mtk_ddp_comp *comp)
@@ -131,12 +132,18 @@ static void mtk_rdma_config(struct mtk_ddp_comp *comp,
unsigned int width,
unsigned int threshold;
unsigned int reg;
struct mtk_disp_rdma *rdma = comp_to_rdma(comp);
+ u32 rdma_fifo_size;
mtk_ddp_write_mask(cmdq_pkt, width, comp,
DISP_REG_RDMA_SIZE_CON_0, 0xfff);
mtk_ddp_write_mask(cmdq_pkt, height, comp,
DISP_REG_RDMA_SIZE_CON_1, 0xf);
+ if (rdma->fifo_size)
+ rdma_fifo_size = rdma->fifo_size;
+ else
+ rdma_fifo_size = RDMA_FIFO_SIZE(rdma);
+
/*
* Enable FIFO underflow since DSI and DPI can't be blocked.
* Keep the FIFO pseudo size reset default of 8 KiB. Set the
@@ -145,7 +152,7 @@ static void mtk_rdma_config(struct mtk_ddp_comp *comp,
unsigned int width,
*/
threshold = width * height * vrefresh * 4 * 7 / 100;
reg = RDMA_FIFO_UNDERFLOW_EN |
- RDMA_FIFO_PSEUDO_SIZE(RDMA_FIFO_SIZE(rdma)) |
+ RDMA_FIFO_PSEUDO_SIZE(rdma_fifo_size) |
RDMA_OUTPUT_VALID_FIFO_THRESHOLD(threshold);
mtk_ddp_write(cmdq_pkt, reg, comp, DISP_REG_RDMA_FIFO_CON);
}
@@ -291,6 +298,16 @@ static int mtk_disp_rdma_probe(struct platform_device
*pdev)
return comp_id;
}
+ if (of_find_property(dev->of_node, "mediatek,rdma_fifo_size", &ret)) {
+ ret = of_property_read_u32(dev->of_node,
+ "mediatek,rdma_fifo_size",
+ &priv->fifo_size);
+ if (ret) {
+ dev_err(dev, "Failed to get rdma fifo size\n");
+ return ret;
+ }
+ }
+
ret = mtk_ddp_comp_init(dev, dev->of_node, &priv->ddp_comp, comp_id,
&mtk_disp_rdma_funcs);
if (ret) {
--
1.8.1.1.dirty
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH -next 2/2] drm: Remove redundant NULL check
Fix below warnings reported by coccicheck:
./drivers/gpu/drm/amd/display/dc/clk_mgr/dcn30/dcn30_clk_mgr.c:557:2-7:
WARNING: NULL check before some freeing functions is not needed.
Fixes: 4d55b0dd1cdd ("drm/amd/display: Add DCN3 CLK_MGR")
Signed-off-by: Li Heng
---
drivers/gpu/drm/amd/display/dc/clk_mgr/dcn30/dcn30_clk_mgr.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn30/dcn30_clk_mgr.c
b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn30/dcn30_clk_mgr.c
index d94fdc5..d8af56a 100644
--- a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn30/dcn30_clk_mgr.c
+++ b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn30/dcn30_clk_mgr.c
@@ -553,8 +553,7 @@ void dcn3_clk_mgr_construct(
void dcn3_clk_mgr_destroy(struct clk_mgr_internal *clk_mgr)
{
- if (clk_mgr->base.bw_params)
- kfree(clk_mgr->base.bw_params);
+ kfree(clk_mgr->base.bw_params);
if (clk_mgr->wm_range_table)
dm_helpers_free_gpu_mem(clk_mgr->base.ctx,
DC_MEM_ALLOC_TYPE_GART,
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 2/3] drm: bridge: Add support for Cadence MHDP DPI/DP bridge
Add a new DRM bridge driver for Cadence MHDP DPTX IP used in TI J721e SoC.
MHDP DPTX IP is the component that complies with VESA DisplayPort (DP) and
embedded Display Port (eDP) standards. It integrates uCPU running the
embedded Firmware (FW) interfaced over APB interface.
Basically, it takes a DPI stream as input and outputs it encoded in DP
format. Currently, it supports only SST mode.
Co-developed-by: Tomi Valkeinen
Signed-off-by: Tomi Valkeinen
Co-developed-by: Jyri Sarha
Signed-off-by: Jyri Sarha
Signed-off-by: Quentin Schulz
Signed-off-by: Yuti Amonkar
Signed-off-by: Swapnil Jakhade
---
drivers/gpu/drm/bridge/Kconfig | 11 +
drivers/gpu/drm/bridge/Makefile |2 +
drivers/gpu/drm/bridge/cdns-mhdp-core.c | 2493 +++
drivers/gpu/drm/bridge/cdns-mhdp-core.h | 396
4 files changed, 2902 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/cdns-mhdp-core.c
create mode 100644 drivers/gpu/drm/bridge/cdns-mhdp-core.h
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 43271c21d3fc..6a4c324302a8 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -27,6 +27,17 @@ config DRM_CDNS_DSI
Support Cadence DPI to DSI bridge. This is an internal
bridge and is meant to be directly embedded in a SoC.
+config DRM_CDNS_MHDP
+ tristate "Cadence DPI/DP bridge"
+ select DRM_KMS_HELPER
+ select DRM_PANEL_BRIDGE
+ depends on OF
+ help
+ Support Cadence DPI to DP bridge. This is an internal
+ bridge and is meant to be directly embedded in a SoC.
+ It takes a DPI stream as input and outputs it encoded
+ in DP format.
+
config DRM_CHRONTEL_CH7033
tristate "Chrontel CH7033 Video Encoder"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index d63d4b7e4347..0080a9f80f29 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -1,5 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
+obj-$(CONFIG_DRM_CDNS_MHDP) += cdns-mhdp.o
+cdns-mhdp-objs := cdns-mhdp-core.o
obj-$(CONFIG_DRM_CHRONTEL_CH7033) += chrontel-ch7033.o
obj-$(CONFIG_DRM_DISPLAY_CONNECTOR) += display-connector.o
obj-$(CONFIG_DRM_LVDS_CODEC) += lvds-codec.o
diff --git a/drivers/gpu/drm/bridge/cdns-mhdp-core.c
b/drivers/gpu/drm/bridge/cdns-mhdp-core.c
new file mode 100644
index ..b16c5503cef1
--- /dev/null
+++ b/drivers/gpu/drm/bridge/cdns-mhdp-core.c
@@ -0,0 +1,2493 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Cadence MHDP DP bridge driver.
+ *
+ * Copyright: 2019 Cadence Design Systems, Inc.
+ *
+ * Author: Quentin Schulz
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include "cdns-mhdp-core.h"
+
+static DECLARE_WAIT_QUEUE_HEAD(fw_load_wq);
+
+static int cdns_mhdp_mailbox_read(struct cdns_mhdp_device *mhdp)
+{
+ int ret, empty;
+
+ WARN_ON(!mutex_is_locked(&mhdp->mbox_mutex));
+
+ ret = readx_poll_timeout(readl, mhdp->regs + CDNS_MAILBOX_EMPTY,
+empty, !empty, MAILBOX_RETRY_US,
+MAILBOX_TIMEOUT_US);
+ if (ret < 0)
+ return ret;
+
+ return readl(mhdp->regs + CDNS_MAILBOX_RX_DATA) & 0xff;
+}
+
+static int cdns_mhdp_mailbox_write(struct cdns_mhdp_device *mhdp, u8 val)
+{
+ int ret, full;
+
+ WARN_ON(!mutex_is_locked(&mhdp->mbox_mutex));
+
+ ret = readx_poll_timeout(readl, mhdp->regs + CDNS_MAILBOX_FULL,
+full, !full, MAILBOX_RETRY_US,
+MAILBOX_TIMEOUT_US);
+ if (ret < 0)
+ return ret;
+
+ writel(val, mhdp->regs + CDNS_MAILBOX_TX_DATA);
+
+ return 0;
+}
+
+static int cdns_mhdp_mailbox_validate_receive(struct cdns_mhdp_device *mhdp,
+ u8 module_id, u8 opcode,
+ u16 req_size)
+{
+ u32 mbox_size, i;
+ u8 header[4];
+ int ret;
+
+ /* read the header of the message */
+ for (i = 0; i < 4; i++) {
+ ret = cdns_mhdp_mailbox_read(mhdp);
+ if (ret < 0)
+ return ret;
+
+ header[i] = ret;
+ }
+
+ mbox_size = get_unaligned_be16(header + 2);
+
+ if (opcode != header[0] || module_id != header[1] ||
+ req_size != mbox_size) {
+ /*
+* If the message in mailbox is not what we want, we need to
+* clear the mailbox by reading its contents.
+*/
+ for (i = 0; i < mbox_size; i++)
+ if
[v7, PATCH 5/7] arm64: dts: add display nodes for mt8183
This patch add display nodes for mt8183
Signed-off-by: Yongqiang Niu
---
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 98
1 file changed, 98 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index 7b781eb..440cf22 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -31,6 +31,11 @@
i2c9 = &i2c9;
i2c10 = &i2c10;
i2c11 = &i2c11;
+ ovl0 = &ovl0;
+ ovl_2l0 = &ovl_2l0;
+ ovl_2l1 = &ovl_2l1;
+ rdma0 = &rdma0;
+ rdma1 = &rdma1;
};
cpus {
@@ -707,9 +712,102 @@
mmsys: syscon@1400 {
compatible = "mediatek,mt8183-mmsys", "syscon";
reg = <0 0x1400 0 0x1000>;
+ power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
#clock-cells = <1>;
};
+ ovl0: ovl@14008000 {
+ compatible = "mediatek,mt8183-disp-ovl";
+ reg = <0 0x14008000 0 0x1000>;
+ interrupts = ;
+ power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
+ clocks = <&mmsys CLK_MM_DISP_OVL0>;
+ };
+
+ ovl_2l0: ovl@14009000 {
+ compatible = "mediatek,mt8183-disp-ovl-2l";
+ reg = <0 0x14009000 0 0x1000>;
+ interrupts = ;
+ power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
+ clocks = <&mmsys CLK_MM_DISP_OVL0_2L>;
+ };
+
+ ovl_2l1: ovl@1400a000 {
+ compatible = "mediatek,mt8183-disp-ovl-2l";
+ reg = <0 0x1400a000 0 0x1000>;
+ interrupts = ;
+ power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
+ clocks = <&mmsys CLK_MM_DISP_OVL1_2L>;
+ };
+
+ rdma0: rdma@1400b000 {
+ compatible = "mediatek,mt8183-disp-rdma";
+ reg = <0 0x1400b000 0 0x1000>;
+ interrupts = ;
+ power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
+ clocks = <&mmsys CLK_MM_DISP_RDMA0>;
+ mediatek,rdma_fifo_size = <5120>;
+ };
+
+ rdma1: rdma@1400c000 {
+ compatible = "mediatek,mt8183-disp-rdma";
+ reg = <0 0x1400c000 0 0x1000>;
+ interrupts = ;
+ power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
+ clocks = <&mmsys CLK_MM_DISP_RDMA1>;
+ mediatek,rdma_fifo_size = <2048>;
+ };
+
+ color0: color@1400e000 {
+ compatible = "mediatek,mt8183-disp-color",
+"mediatek,mt8173-disp-color";
+ reg = <0 0x1400e000 0 0x1000>;
+ interrupts = ;
+ power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
+ clocks = <&mmsys CLK_MM_DISP_COLOR0>;
+ };
+
+ ccorr0: ccorr@1400f000 {
+ compatible = "mediatek,mt8183-disp-ccorr";
+ reg = <0 0x1400f000 0 0x1000>;
+ interrupts = ;
+ power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
+ clocks = <&mmsys CLK_MM_DISP_CCORR0>;
+ };
+
+ aal0: aal@1401 {
+ compatible = "mediatek,mt8183-disp-aal",
+"mediatek,mt8173-disp-aal";
+ reg = <0 0x1401 0 0x1000>;
+ interrupts = ;
+ power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
+ clocks = <&mmsys CLK_MM_DISP_AAL0>;
+ };
+
+ gamma0: gamma@14011000 {
+ compatible = "mediatek,mt8183-disp-gamma",
+"mediatek,mt8173-disp-gamma";
+ reg = <0 0x14011000 0 0x1000>;
+ interrupts = ;
+ power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
+ clocks = <&mmsys CLK_MM_DISP_GAMMA0>;
+ };
+
+ dither0: dither@14012000 {
+ compatible = "mediatek,mt8183-disp-dither";
+ reg = <0 0x14012000 0 0x1000>;
+ interrupts = ;
+ power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
+ clocks = <&mmsys CLK_MM_DISP_DITHER0>;
+ };
+
+ mutex: mutex@14016000 {
+
[PATCH v7 1/3] dt-bindings: drm/bridge: Document Cadence MHDP bridge bindings
From: Yuti Amonkar
Document the bindings used for the Cadence MHDP DPI/DP bridge in
yaml format.
Signed-off-by: Yuti Amonkar
Signed-off-by: Swapnil Jakhade
Reviewed-by: Rob Herring
Reviewed-by: Laurent Pinchart
---
.../bindings/display/bridge/cdns,mhdp.yaml| 127 ++
1 file changed, 127 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/cdns,mhdp.yaml
diff --git a/Documentation/devicetree/bindings/display/bridge/cdns,mhdp.yaml
b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp.yaml
new file mode 100644
index ..cdf5760d4ec5
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp.yaml
@@ -0,0 +1,127 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/display/bridge/cdns,mhdp.yaml#";
+$schema: "http://devicetree.org/meta-schemas/core.yaml#";
+
+title: Cadence MHDP bridge
+
+maintainers:
+ - Swapnil Jakhade
+ - Yuti Amonkar
+
+properties:
+ compatible:
+enum:
+ - cdns,mhdp8546
+ - ti,j721e-mhdp8546
+
+ reg:
+minItems: 1
+maxItems: 2
+items:
+ - description:
+ Register block of mhdptx apb registers up to PHY mapped area
(AUX_CONFIG_P).
+ The AUX and PMA registers are not part of this range, they are
instead
+ included in the associated PHY.
+ - description:
+ Register block for DSS_EDP0_INTG_CFG_VP registers in case of TI J7
SoCs.
+
+ reg-names:
+minItems: 1
+maxItems: 2
+items:
+ - const: mhdptx
+ - const: j721e-intg
+
+ clocks:
+maxItems: 1
+description:
+ DP bridge clock, used by the IP to know how to translate a number of
+ clock cycles into a time (which is used to comply with DP standard
timings
+ and delays).
+
+ phys:
+description:
+ phandle to the DisplayPort PHY.
+
+ ports:
+type: object
+description:
+ Ports as described in Documentation/devicetree/bindings/graph.txt.
+
+properties:
+ '#address-cells':
+const: 1
+
+ '#size-cells':
+const: 0
+
+ port@0:
+type: object
+description:
+ Input port representing the DP bridge input.
+
+ port@1:
+type: object
+description:
+ Output port representing the DP bridge output.
+
+required:
+ - port@0
+ - port@1
+ - '#address-cells'
+ - '#size-cells'
+
+allOf:
+ - if:
+ properties:
+compatible:
+ contains:
+const: ti,j721e-mhdp8546
+then:
+ properties:
+reg:
+ minItems: 2
+reg-names:
+ minItems: 2
+
+required:
+ - compatible
+ - clocks
+ - reg
+ - reg-names
+ - phys
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+mhdp: dp-bridge@f0fb00 {
+compatible = "cdns,mhdp8546";
+reg = <0xf0 0xfb00 0x0 0x100>;
+reg-names = "mhdptx";
+clocks = <&mhdp_clock>;
+phys = <&dp_phy>;
+
+ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dp_bridge_input: endpoint {
+remote-endpoint = <&xxx_dpi_output>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dp_bridge_output: endpoint {
+remote-endpoint = <&xxx_dp_connector_input>;
+ };
+ };
+};
+};
+...
--
2.26.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 0/3] drm: Add support for Cadence MHDP DPI/DP bridge and J721E wrapper.
This patch series adds new DRM bridge driver for Cadence MHDP DPI/DP bridge. The Cadence Display Port IP is also referred as MHDP (Mobile High Definition Link, High-Definition Multimedia Interface, Display Port). Cadence Display Port complies with VESA DisplayPort (DP) and embedded Display Port (eDP) standards. The MHDP bridge driver currently implements Single Stream Transport (SST) mode. It also adds Texas Instruments j721e SoC specific wrapper and adds the device tree bindings in YAML format. Some of the features that will be added later on include (but are not limited to): - Power Management (PM) support: We will implement the PM functions in next stage once there will be a stable driver in upstream - Converting to connector bridge operations: This is not supported currently because of dependency on TIDSS driver which has some limitations in supporting new model - Audio and MST support The patch series has three patches in the below sequence: 1. 0001-dt-bindings-drm-bridge-Document-Cadence-MHDP-brid.patch Documents the bindings in yaml format. 2. 0002-drm-bridge-Add-support-for-Cadence-MHDP-DPI-DP-br.patch This patch adds new DRM bridge driver for Cadence MHDP Display Port. The patch implements support for single stream transport mode. 3. 0003-drm-bridge-cdns-mhdp-Add-j721e-wrapper.patch Adds Texas Instruments (TI) j721e wrapper for MHDP. The wrapper configures MHDP clocks and muxes as required by SoC. This patch series is dependent on PHY patch series [1] to add new PHY APIs to get/set PHY attributes which is under review and not merged yet. [1] https://lkml.org/lkml/2020/7/17/158 Version History: v7: In 1/3 - No change In 2/3 - Switch to atomic versions of bridge operations - Implement atomic_check() handler to perform all validation checks - Add struct cdns_mhdp_bridge_state with subclassed bridge state - Use PHY API[1] to get PHY attributes instead of reading from PHY DT node - Updated HPD handling and link configuration in IRQ handler - Add "link_mutex" protecting the access to all the link parameters - Add support to check and print FW version information - Add separate function to initialize host parameters to simplify probe - Use waitqueue instead of manual loop in cdns_mhdp_remove - Add forward declarations and header files in cdns-mhdp-core.h file - Use bool instead of single bit values in struct cdns_mhdp_device - Fix for other minor comments given for v6 patches In 3/3 - Use of_device_is_compatible() to set compatible string specific values - Move mhdp_ti_j721e_ops structure to cdns-mhdp-j721e.c - Remove duplicate Copyright message - Remove CONFIG_DRM_CDNS_MHDP_J721E check - Add Reviewed-by: Laurent Pinchart v6: - Added minor fixes in YAML file. - Added Reviewed-by: Laurent Pinchart to the YAML patch. - Removed all the FIXME comments which are invalid in drm driver. - Reduced the mailbox timeout from 5s to 2s. - Added Reviewed-by: Tomi Valkeinen to the 003-drm-mhdp-add-j721e-wrapper patch. - Added Signed-off all the module authors. - Fixed the compiler error Reported-by: kbuild test robot . v5: - Added Signed-off-by: Jyri Sarha tag to the code patches. v4: - Added SPDX dual license tag to YAML bindings. - Corrected indentation of the child node properties. - Removed the maxItems in the conditional statement. - Add Reviewed-by: Rob Herring tag to the Document Cadence MHDP bridge bindings patch. - Renamed the DRM driver executable name from mhdp8546 to cdns-mhdp in Makefile. - Renamed the DRM driver and header file from cdns-mhdp to cdns-mhdp-core. v3: - Added if / then clause to validate that the reg length is proper based on the value of the compatible property. - Updated phy property description in YAML to a generic one. - Renamed num_lanes and max_bit_rate property strings to cdns,num-lanes and cdns,max-bit-rate. v2: - Use enum in compatible property of YAML file. - Add reg-names property to YAML file - Add minItems and maxItems to reg property in YAML. - Remove cdns_mhdp_link_probe function to remove duplication of reading dpcd capabilities. Swapnil Jakhade (2): drm: bridge: Add support for Cadence MHDP DPI/DP bridge drm: bridge: cdns-mhdp: Add j721e wrapper Yuti Amonkar (1): dt-bindings: drm/bridge: Document Cadence MHDP bridge bindings .../bindings/display/bridge/cdns,mhdp.yaml| 127 + drivers/gpu/drm/bridge/Kconfig| 24 + drivers/gpu/drm/bridge/Makefile |7 + drivers/gpu/drm/bridge/cdns-mhdp-core.c | 2508 + drivers/gpu/drm/bridge/cdns-mhdp-core.h | 397 +++ drivers/gpu/drm/bridge/cdns-mhdp-j721e.c | 75 + drivers/gpu/drm/bridge/cdns-mhdp-j721e.h | 19 + 7 files changed, 3157 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/bridge/cdns,mhdp.yaml create mode 100644 drivers/gpu/drm/bridge/cdns-mhdp-core.c create mode 100644 drivers/gpu/drm/bridge/cdns-mhdp-core.h create mode 100644 drivers/gpu/drm/bridge/cdns-mhdp-j721e.c
[v7, PATCH 2/7] mtk-mmsys: add mmsys private data
add mmsys private data Feature: drm/mediatek Signed-off-by: Yongqiang Niu --- drivers/soc/mediatek/Makefile | 1 + drivers/soc/mediatek/mmsys/Makefile | 2 + drivers/soc/mediatek/mmsys/mt2701-mmsys.c | 250 +++ drivers/soc/mediatek/mtk-mmsys.c | 271 +- include/linux/soc/mediatek/mtk-mmsys.h| 15 ++ 5 files changed, 314 insertions(+), 225 deletions(-) create mode 100644 drivers/soc/mediatek/mmsys/Makefile create mode 100644 drivers/soc/mediatek/mmsys/mt2701-mmsys.c diff --git a/drivers/soc/mediatek/Makefile b/drivers/soc/mediatek/Makefile index 2afa7b9..b37ac2c 100644 --- a/drivers/soc/mediatek/Makefile +++ b/drivers/soc/mediatek/Makefile @@ -3,3 +3,4 @@ obj-$(CONFIG_MTK_CMDQ) += mtk-cmdq-helper.o obj-$(CONFIG_MTK_PMIC_WRAP) += mtk-pmic-wrap.o obj-$(CONFIG_MTK_SCPSYS) += mtk-scpsys.o obj-$(CONFIG_MTK_MMSYS) += mtk-mmsys.o +obj-$(CONFIG_MTK_MMSYS) += mmsys/ diff --git a/drivers/soc/mediatek/mmsys/Makefile b/drivers/soc/mediatek/mmsys/Makefile new file mode 100644 index 000..33b0dab --- /dev/null +++ b/drivers/soc/mediatek/mmsys/Makefile @@ -0,0 +1,2 @@ +# SPDX-License-Identifier: GPL-2.0-only +obj-y += mt2701-mmsys.o diff --git a/drivers/soc/mediatek/mmsys/mt2701-mmsys.c b/drivers/soc/mediatek/mmsys/mt2701-mmsys.c new file mode 100644 index 000..b8e53b0 --- /dev/null +++ b/drivers/soc/mediatek/mmsys/mt2701-mmsys.c @@ -0,0 +1,250 @@ +// SPDX-License-Identifier: GPL-2.0 +// +// Copyright (c) 2020 MediaTek Inc. + +#include +#include +#include +#include +#include + +#define DISP_REG_CONFIG_DISP_OVL0_MOUT_EN 0x040 +#define DISP_REG_CONFIG_DISP_OVL1_MOUT_EN 0x044 +#define DISP_REG_CONFIG_DISP_OD_MOUT_EN0x048 +#define DISP_REG_CONFIG_DISP_GAMMA_MOUT_EN 0x04c +#define DISP_REG_CONFIG_DISP_UFOE_MOUT_EN 0x050 +#define DISP_REG_CONFIG_DISP_COLOR0_SEL_IN 0x084 +#define DISP_REG_CONFIG_DISP_COLOR1_SEL_IN 0x088 +#define DISP_REG_CONFIG_DSIE_SEL_IN0x0a4 +#define DISP_REG_CONFIG_DSIO_SEL_IN0x0a8 +#define DISP_REG_CONFIG_DPI_SEL_IN 0x0ac +#define DISP_REG_CONFIG_DISP_RDMA2_SOUT0x0b8 +#define DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN 0x0c4 +#define DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN 0x0c8 +#define DISP_REG_CONFIG_MMSYS_CG_CON0 0x100 + +#define DISP_REG_CONFIG_DISP_OVL_MOUT_EN 0x030 +#define DISP_REG_CONFIG_OUT_SEL0x04c +#define DISP_REG_CONFIG_DSI_SEL0x050 +#define DISP_REG_CONFIG_DPI_SEL0x064 + +#define OVL0_MOUT_EN_COLOR00x1 +#define OD_MOUT_EN_RDMA0 0x1 +#define OD1_MOUT_EN_RDMA1 BIT(16) +#define UFOE_MOUT_EN_DSI0 0x1 +#define COLOR0_SEL_IN_OVL0 0x1 +#define OVL1_MOUT_EN_COLOR10x1 +#define GAMMA_MOUT_EN_RDMA10x1 +#define RDMA0_SOUT_DPI00x2 +#define RDMA0_SOUT_DPI10x3 +#define RDMA0_SOUT_DSI10x1 +#define RDMA0_SOUT_DSI20x4 +#define RDMA0_SOUT_DSI30x5 +#define RDMA1_SOUT_DPI00x2 +#define RDMA1_SOUT_DPI10x3 +#define RDMA1_SOUT_DSI10x1 +#define RDMA1_SOUT_DSI20x4 +#define RDMA1_SOUT_DSI30x5 +#define RDMA2_SOUT_DPI00x2 +#define RDMA2_SOUT_DPI10x3 +#define RDMA2_SOUT_DSI10x1 +#define RDMA2_SOUT_DSI20x4 +#define RDMA2_SOUT_DSI30x5 +#define DPI0_SEL_IN_RDMA1 0x1 +#define DPI0_SEL_IN_RDMA2 0x3 +#define DPI1_SEL_IN_RDMA1 (0x1 << 8) +#define DPI1_SEL_IN_RDMA2 (0x3 << 8) +#define DSI0_SEL_IN_RDMA1 0x1 +#define DSI0_SEL_IN_RDMA2 0x4 +#define DSI1_SEL_IN_RDMA1 0x1 +#define DSI1_SEL_IN_RDMA2 0x4 +#define DSI2_SEL_IN_RDMA1 (0x1 << 16) +#define DSI2_SEL_IN_RDMA2 (0x4 << 16) +#define DSI3_SEL_IN_RDMA1 (0x1 << 16) +#define DSI3_SEL_IN_RDMA2 (0x4 << 16) +#define COLOR1_SEL_IN_OVL1 0x1 + +#define OVL_MOUT_EN_RDMA 0x1 +#define BLS_TO_DSI_RDMA1_TO_DPI1 0x8 +#define BLS_TO_DPI_RDMA1_TO_DSI0x2 +#define DSI_SEL_IN_BLS 0x0 +#define DPI_SEL_IN_BLS 0x0 +#define DSI_SEL_IN_RDMA0x1 + +static unsigned int mtk_mmsys_ddp_mout_en(enum mtk_ddp_comp_id
[PATCH v2 3/5] drm: rockchip: add alpha support for RK3036, RK3066, RK3126 and RK3188
With commit 2aae8ed1f390
("drm/rockchip: Add per-pixel alpha support for the PX30 VOP") alpha
support was introduced for PX30's VOP.
RK3036, RK3066, RK3126 and RK3188 VOPs support alpha blending in the
same manner.
With the exception of RK3066 all of them support pre-multiplied alpha.
Lets add these registers to make this work for those VOPs as well.
Signed-off-by: Alex Bee
---
Changes in v2:
- rephrase commit message
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 21 +
drivers/gpu/drm/rockchip/rockchip_vop_reg.h | 1 +
2 files changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index a50877818a86..5a13b4ab77e1 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -104,6 +104,9 @@ static const struct vop_win_phy rk3036_win0_data = {
.uv_mst = VOP_REG(RK3036_WIN0_CBR_MST, 0x, 0),
.yrgb_vir = VOP_REG(RK3036_WIN0_VIR, 0x, 0),
.uv_vir = VOP_REG(RK3036_WIN0_VIR, 0x1fff, 16),
+ .alpha_mode = VOP_REG(RK3036_DSP_CTRL0, 0x1, 18),
+ .alpha_en = VOP_REG(RK3036_ALPHA_CTRL, 0x1, 0),
+ .alpha_pre_mul = VOP_REG(RK3036_DSP_CTRL0, 0x1, 29),
};
static const struct vop_win_phy rk3036_win1_data = {
@@ -119,6 +122,9 @@ static const struct vop_win_phy rk3036_win1_data = {
.dsp_st = VOP_REG(RK3036_WIN1_DSP_ST, 0x1fff1fff, 0),
.yrgb_mst = VOP_REG(RK3036_WIN1_MST, 0x, 0),
.yrgb_vir = VOP_REG(RK3036_WIN1_VIR, 0x, 0),
+ .alpha_mode = VOP_REG(RK3036_DSP_CTRL0, 0x1, 19),
+ .alpha_en = VOP_REG(RK3036_ALPHA_CTRL, 0x1, 1),
+ .alpha_pre_mul = VOP_REG(RK3036_DSP_CTRL0, 0x1, 29),
};
static const struct vop_win_data rk3036_vop_win_data[] = {
@@ -185,6 +191,9 @@ static const struct vop_win_phy rk3126_win1_data = {
.dsp_st = VOP_REG(RK3126_WIN1_DSP_ST, 0x1fff1fff, 0),
.yrgb_mst = VOP_REG(RK3126_WIN1_MST, 0x, 0),
.yrgb_vir = VOP_REG(RK3036_WIN1_VIR, 0x, 0),
+ .alpha_mode = VOP_REG(RK3036_DSP_CTRL0, 0x1, 19),
+ .alpha_en = VOP_REG(RK3036_ALPHA_CTRL, 0x1, 1),
+ .alpha_pre_mul = VOP_REG(RK3036_DSP_CTRL0, 0x1, 29),
};
static const struct vop_win_data rk3126_vop_win_data[] = {
@@ -364,6 +373,8 @@ static const struct vop_win_phy rk3066_win0_data = {
.uv_mst = VOP_REG(RK3066_WIN0_CBR_MST0, 0x, 0),
.yrgb_vir = VOP_REG(RK3066_WIN0_VIR, 0x, 0),
.uv_vir = VOP_REG(RK3066_WIN0_VIR, 0x1fff, 16),
+ .alpha_mode = VOP_REG(RK3066_DSP_CTRL0, 0x1, 21),
+ .alpha_en = VOP_REG(RK3066_BLEND_CTRL, 0x1, 0),
};
static const struct vop_win_phy rk3066_win1_data = {
@@ -381,6 +392,8 @@ static const struct vop_win_phy rk3066_win1_data = {
.uv_mst = VOP_REG(RK3066_WIN1_CBR_MST, 0x, 0),
.yrgb_vir = VOP_REG(RK3066_WIN1_VIR, 0x, 0),
.uv_vir = VOP_REG(RK3066_WIN1_VIR, 0x1fff, 16),
+ .alpha_mode = VOP_REG(RK3066_DSP_CTRL0, 0x1, 22),
+ .alpha_en = VOP_REG(RK3066_BLEND_CTRL, 0x1, 1),
};
static const struct vop_win_phy rk3066_win2_data = {
@@ -394,6 +407,8 @@ static const struct vop_win_phy rk3066_win2_data = {
.dsp_st = VOP_REG(RK3066_WIN2_DSP_ST, 0x1fff1fff, 0),
.yrgb_mst = VOP_REG(RK3066_WIN2_MST, 0x, 0),
.yrgb_vir = VOP_REG(RK3066_WIN2_VIR, 0x, 0),
+ .alpha_mode = VOP_REG(RK3066_DSP_CTRL0, 0x1, 23),
+ .alpha_en = VOP_REG(RK3066_BLEND_CTRL, 0x1, 2),
};
static const struct vop_modeset rk3066_modeset = {
@@ -476,6 +491,9 @@ static const struct vop_win_phy rk3188_win0_data = {
.yrgb_mst = VOP_REG(RK3188_WIN0_YRGB_MST0, 0x, 0),
.uv_mst = VOP_REG(RK3188_WIN0_CBR_MST0, 0x, 0),
.yrgb_vir = VOP_REG(RK3188_WIN_VIR, 0x1fff, 0),
+ .alpha_mode = VOP_REG(RK3188_DSP_CTRL0, 0x1, 18),
+ .alpha_en = VOP_REG(RK3188_ALPHA_CTRL, 0x1, 0),
+ .alpha_pre_mul = VOP_REG(RK3188_DSP_CTRL0, 0x1, 29),
};
static const struct vop_win_phy rk3188_win1_data = {
@@ -490,6 +508,9 @@ static const struct vop_win_phy rk3188_win1_data = {
.dsp_st = VOP_REG(RK3188_WIN1_DSP_ST, 0x0fff0fff, 0),
.yrgb_mst = VOP_REG(RK3188_WIN1_MST, 0x, 0),
.yrgb_vir = VOP_REG(RK3188_WIN_VIR, 0x1fff, 16),
+ .alpha_mode = VOP_REG(RK3188_DSP_CTRL0, 0x1, 19),
+ .alpha_en = VOP_REG(RK3188_ALPHA_CTRL, 0x1, 1),
+ .alpha_pre_mul = VOP_REG(RK3188_DSP_CTRL0, 0x1, 29),
};
static const struct vop_modeset rk3188_modeset = {
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.h
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.h
index 6e9fa5815d4d..0b3cd65ba5c1 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.h
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.h
@@ -955,6 +955,7 @@
#define RK3188_DSP_CTRL0 0x04
#define RK3188_DSP_CTRL1 0x08
#define RK3188_INT_STATUS 0x10
+#define RK3188_ALPHA_CTRL 0x14
