Re: [PATCH v4 1/9] fs: Constify vma argument to vma_is_dax
On Thu, Feb 20, 2020 at 4:27 AM Thomas Hellström (VMware)
wrote:
>
> From: Thomas Hellstrom
>
> The vma argument is only dereferenced for reading.
>
> Cc: Andrew Morton
> Cc: Michal Hocko
> Cc: "Matthew Wilcox (Oracle)"
> Cc: "Kirill A. Shutemov"
> Cc: Ralph Campbell
> Cc: "Jérôme Glisse"
> Cc: "Christian König"
> Cc: Dan Williams
> Signed-off-by: Thomas Hellstrom
> Reviewed-by: Roland Scheidegger
> Acked-by: Christian König
> ---
> include/linux/fs.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index 98e0349adb52..4f41fdbf402f 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -3367,7 +3367,7 @@ static inline bool io_is_direct(struct file *filp)
> return (filp->f_flags & O_DIRECT) || IS_DAX(filp->f_mapping->host);
> }
>
> -static inline bool vma_is_dax(struct vm_area_struct *vma)
> +static inline bool vma_is_dax(const struct vm_area_struct *vma)
> {
> return vma->vm_file && IS_DAX(vma->vm_file->f_mapping->host);
> }
Looks good to me:
Acked-by: Dan Williams
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ttm: clean up the inteface which is not used
On Thu, Mar 26, 2020 at 01:30:31AM +0800, Christian König wrote:
> Am 25.03.20 um 18:27 schrieb Alex Deucher:
> > On Wed, Mar 25, 2020 at 1:20 PM Christian König
> > wrote:
> >> Am 25.03.20 um 16:34 schrieb Huang Rui:
> >>> invalidate_caches is actually not used, so clean it up.
> >>>
> >>> Signed-off-by: Huang Rui
> >> Already had the same patch around for a while, looks like I've just
> >> forgot to commit it.
> >>
> >> Reviewed-by: Christian König
> >>
> > Is it already in drm-misc and just hasn't made it into
> > amd-staging-drm-next yet? I can try and rebase next week if so.
>
> Ah! Yeah there it is:
>
> > commit 5e791166d377c539db0f889e7793204912c374da
> > Author: Christian König
> > Date: Fri Jan 10 16:09:54 2020 +0100
> >
> > drm/ttm: nuke invalidate_caches callback
> >
> > Another completely unused feature.
> >
> > Signed-off-by: Christian König
> > Reviewed-by: Huang Rui
> > Link:
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.freedesktop.org%2Fpatch%2F348265%2Fdata=02%7C01%7Cray.huang%40amd.com%7C544ea2a584b94dd75d8808d7d0e23993%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637207542363429381sdata=j9xr%2B%2F0apX3fcSVWRfljfRD%2BJVDzMe7tZ1%2FKVqZysjo%3Dreserved=0
>
> Looks like we haven't merged that into amd-staging-drm-next yet.
I also forgot to look at this patch before. :-)
OK, let's use your orignal patch.
Thanks,
Ray
>
> Christian.
>
> >
> > Alex
> >
> >
> >>> ---
> >>>drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 6 --
> >>>drivers/gpu/drm/nouveau/nouveau_bo.c | 7 ---
> >>>drivers/gpu/drm/qxl/qxl_ttm.c | 6 --
> >>>drivers/gpu/drm/radeon/radeon_ttm.c| 6 --
> >>>drivers/gpu/drm/ttm/ttm_bo.c | 8 +---
> >>>drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 6 --
> >>>include/drm/ttm/ttm_bo_driver.h| 13 -
> >>>7 files changed, 1 insertion(+), 51 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> >>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> >>> index cd2bde6..b397148 100644
> >>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> >>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> >>> @@ -62,11 +62,6 @@
> >>>
> >>>#define AMDGPU_TTM_VRAM_MAX_DW_READ (size_t)128
> >>>
> >>> -static int amdgpu_invalidate_caches(struct ttm_bo_device *bdev, uint32_t
> >>> flags)
> >>> -{
> >>> - return 0;
> >>> -}
> >>> -
> >>>/**
> >>> * amdgpu_init_mem_type - Initialize a memory manager for a specific
> >>> type of
> >>> * memory request.
> >>> @@ -1746,7 +1741,6 @@ static struct ttm_bo_driver amdgpu_bo_driver = {
> >>>.ttm_tt_create = _ttm_tt_create,
> >>>.ttm_tt_populate = _ttm_tt_populate,
> >>>.ttm_tt_unpopulate = _ttm_tt_unpopulate,
> >>> - .invalidate_caches = _invalidate_caches,
> >>>.init_mem_type = _init_mem_type,
> >>>.eviction_valuable = amdgpu_ttm_bo_eviction_valuable,
> >>>.evict_flags = _evict_flags,
> >>> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
> >>> b/drivers/gpu/drm/nouveau/nouveau_bo.c
> >>> index 1b62ccc..7dd94e6 100644
> >>> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> >>> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> >>> @@ -647,13 +647,6 @@ nouveau_ttm_tt_create(struct ttm_buffer_object *bo,
> >>> uint32_t page_flags)
> >>>}
> >>>
> >>>static int
> >>> -nouveau_bo_invalidate_caches(struct ttm_bo_device *bdev, uint32_t flags)
> >>> -{
> >>> - /* We'll do this from user space. */
> >>> - return 0;
> >>> -}
> >>> -
> >>> -static int
> >>>nouveau_bo_init_mem_type(struct ttm_bo_device *bdev, uint32_t type,
> >>> struct ttm_mem_type_manager *man)
> >>>{
> >>> diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
> >>> index 16a5e90..62a5e42 100644
> >>> --- a/drivers/gpu/drm/qxl/qxl_ttm.c
> >>> +++ b/drivers/gpu/drm/qxl/qxl_ttm.c
> >>> @@ -48,11 +48,6 @@ static struct qxl_device *qxl_get_qdev(struct
> >>> ttm_bo_device *bdev)
> >>>return qdev;
> >>>}
> >>>
> >>> -static int qxl_invalidate_caches(struct ttm_bo_device *bdev, uint32_t
> >>> flags)
> >>> -{
> >>> - return 0;
> >>> -}
> >>> -
> >>>static int qxl_init_mem_type(struct ttm_bo_device *bdev, uint32_t type,
> >>> struct ttm_mem_type_manager *man)
> >>>{
> >>> @@ -256,7 +251,6 @@ static void qxl_bo_move_notify(struct
> >>> ttm_buffer_object *bo,
> >>>
> >>>static struct ttm_bo_driver qxl_bo_driver = {
> >>>.ttm_tt_create = _ttm_tt_create,
> >>> - .invalidate_caches = _invalidate_caches,
> >>>.init_mem_type = _init_mem_type,
> >>>.eviction_valuable = ttm_bo_eviction_valuable,
> >>>.evict_flags = _evict_flags,
> >>> diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
> >>> b/drivers/gpu/drm/radeon/radeon_ttm.c
> >>> index f4af6703..40282bf 100644
> >>> ---
Re: [RESEND PATCH v12 3/5] clk / soc: mediatek: Move mt8173 MMSYS to platform driver
Quoting Enric Balletbo i Serra (2020-03-25 10:31:21) > From: Matthias Brugger > > There is no strong reason for this to use CLK_OF_DECLARE instead of > being a platform driver. Plus, MMSYS provides clocks but also a shared > register space for the mediatek-drm and the mediatek-mdp > driver. So move the MMSYS clocks to a new platform driver and also > create a new MMSYS platform driver in drivers/soc/mediatek that > instantiates the clock driver. > > Signed-off-by: Matthias Brugger > Signed-off-by: Enric Balletbo i Serra > Reviewed-by: CK Hu > --- Acked-by: Stephen Boyd Reviewed-by: Stephen Boyd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/virtio: delete notify in virtio_gpu_object_create
On Thu, Mar 26, 2020 at 7:10 AM Gurchetan Singh wrote: > > For 3D buffers, virtio_gpu_gem_object_open notifies. > We can have the same behavior for dumb buffer. > > v2: virtio_gpu_gem_object_open always notifies > v3: avoid boolean variable Series is Reviewed-by: Chia-I Wu > > Signed-off-by: Gurchetan Singh > --- > drivers/gpu/drm/virtio/virtgpu_gem.c| 3 ++- > drivers/gpu/drm/virtio/virtgpu_object.c | 1 - > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/virtio/virtgpu_gem.c > b/drivers/gpu/drm/virtio/virtgpu_gem.c > index 90c0a8ea1708c..1025658be4df2 100644 > --- a/drivers/gpu/drm/virtio/virtgpu_gem.c > +++ b/drivers/gpu/drm/virtio/virtgpu_gem.c > @@ -114,7 +114,7 @@ int virtio_gpu_gem_object_open(struct drm_gem_object *obj, > struct virtio_gpu_object_array *objs; > > if (!vgdev->has_virgl_3d) > - return 0; > + goto out_notify; > > objs = virtio_gpu_array_alloc(1); > if (!objs) > @@ -123,6 +123,7 @@ int virtio_gpu_gem_object_open(struct drm_gem_object *obj, > > virtio_gpu_cmd_context_attach_resource(vgdev, vfpriv->ctx_id, >objs); > +out_notify: > virtio_gpu_notify(vgdev); > return 0; > } > diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c > b/drivers/gpu/drm/virtio/virtgpu_object.c > index d9039bb7c5e37..51a8da7d5ef3b 100644 > --- a/drivers/gpu/drm/virtio/virtgpu_object.c > +++ b/drivers/gpu/drm/virtio/virtgpu_object.c > @@ -241,7 +241,6 @@ int virtio_gpu_object_create(struct virtio_gpu_device > *vgdev, > return ret; > } > > - virtio_gpu_notify(vgdev); > *bo_ptr = bo; > return 0; > > -- > 2.24.1 > > ___ > 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 v12 4/5] soc / drm: mediatek: Move routing control to mmsys device
Hi, Matthias:
On Wed, 2020-03-25 at 17:16 +0100, Matthias Brugger wrote:
>
> On 11/03/2020 17:53, Enric Balletbo i Serra wrote:
> > Provide a mtk_mmsys_ddp_connect() and mtk_mmsys_disconnect() functions to
> > replace mtk_ddp_add_comp_to_path() and mtk_ddp_remove_comp_from_path().
> > Those functions will allow DRM driver and others to control the data
> > path routing.
> >
> > Signed-off-by: Enric Balletbo i Serra
> > Reviewed-by: Matthias Brugger
> > Reviewed-by: CK Hu
> > Acked-by: CK Hu
>
> This patch does not apply against v5.6-rc1.
> Please rebase as this is a quite big patch and it won't be easy to do that by
> hand.
I think this patch depends on [1] which has been acked by me and I have
not picked it. The simple way is that you pick [1] first and then pick
this series.
[1]
https://patchwork.kernel.org/patch/11406227/
Regards,
CK
>
> Regards,
> Matthias
>
> > ---
> >
> > Changes in v12: None
> > Changes in v10:
> > - Select CONFIG_MTK_MMSYS (CK)
> > - Pass device pointer of mmsys device instead of config regs (CK)
> >
> > Changes in v9:
> > - Introduced a new patch to move routing control into mmsys driver.
> > - Removed the patch to use regmap as is not needed anymore.
> >
> > Changes in v8: None
> > Changes in v7: None
> >
> > drivers/gpu/drm/mediatek/Kconfig| 1 +
> > drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 19 +-
> > drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 256 --
> > drivers/gpu/drm/mediatek/mtk_drm_ddp.h | 7 -
> > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 14 +-
> > drivers/gpu/drm/mediatek/mtk_drm_drv.h | 2 +-
> > drivers/soc/mediatek/mtk-mmsys.c| 279
> > include/linux/soc/mediatek/mtk-mmsys.h | 20 ++
> > 8 files changed, 316 insertions(+), 282 deletions(-)
> > create mode 100644 include/linux/soc/mediatek/mtk-mmsys.h
> >
> > diff --git a/drivers/gpu/drm/mediatek/Kconfig
> > b/drivers/gpu/drm/mediatek/Kconfig
> > index fa5ffc4fe823..c420f5a3d33b 100644
> > --- a/drivers/gpu/drm/mediatek/Kconfig
> > +++ b/drivers/gpu/drm/mediatek/Kconfig
> > @@ -11,6 +11,7 @@ config DRM_MEDIATEK
> > select DRM_MIPI_DSI
> > select DRM_PANEL
> > select MEMORY
> > + select MTK_MMSYS
> > select MTK_SMI
> > select VIDEOMODE_HELPERS
> > help
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > index 0e05683d7b53..579a5a5d4472 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > @@ -6,6 +6,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #include
> > #include
> > @@ -28,7 +29,7 @@
> > * @enabled: records whether crtc_enable succeeded
> > * @planes: array of 4 drm_plane structures, one for each overlay plane
> > * @pending_planes: whether any plane has pending changes to be applied
> > - * @config_regs: memory mapped mmsys configuration register space
> > + * @mmsys_dev: pointer to the mmsys device for configuration registers
> > * @mutex: handle to one of the ten disp_mutex streams
> > * @ddp_comp_nr: number of components in ddp_comp
> > * @ddp_comp: array of pointers the mtk_ddp_comp structures used by this
> > crtc
> > @@ -50,7 +51,7 @@ struct mtk_drm_crtc {
> > u32 cmdq_event;
> > #endif
> >
> > - void __iomem*config_regs;
> > + struct device *mmsys_dev;
> > struct mtk_disp_mutex *mutex;
> > unsigned intddp_comp_nr;
> > struct mtk_ddp_comp **ddp_comp;
> > @@ -296,9 +297,9 @@ static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc
> > *mtk_crtc)
> > }
> >
> > for (i = 0; i < mtk_crtc->ddp_comp_nr - 1; i++) {
> > - mtk_ddp_add_comp_to_path(mtk_crtc->config_regs,
> > -mtk_crtc->ddp_comp[i]->id,
> > -mtk_crtc->ddp_comp[i + 1]->id);
> > + mtk_mmsys_ddp_connect(mtk_crtc->mmsys_dev,
> > + mtk_crtc->ddp_comp[i]->id,
> > + mtk_crtc->ddp_comp[i + 1]->id);
> > mtk_disp_mutex_add_comp(mtk_crtc->mutex,
> > mtk_crtc->ddp_comp[i]->id);
> > }
> > @@ -355,9 +356,9 @@ static void mtk_crtc_ddp_hw_fini(struct mtk_drm_crtc
> > *mtk_crtc)
> >mtk_crtc->ddp_comp[i]->id);
> > mtk_disp_mutex_disable(mtk_crtc->mutex);
> > for (i = 0; i < mtk_crtc->ddp_comp_nr - 1; i++) {
> > - mtk_ddp_remove_comp_from_path(mtk_crtc->config_regs,
> > - mtk_crtc->ddp_comp[i]->id,
> > - mtk_crtc->ddp_comp[i + 1]->id);
> > + mtk_mmsys_ddp_disconnect(mtk_crtc->mmsys_dev,
> > +mtk_crtc->ddp_comp[i]->id,
> > +
[PATCH] drm/virtio: delete notify in virtio_gpu_object_create
For 3D buffers, virtio_gpu_gem_object_open notifies. We can have the same behavior for dumb buffer. v2: virtio_gpu_gem_object_open always notifies v3: avoid boolean variable Signed-off-by: Gurchetan Singh --- drivers/gpu/drm/virtio/virtgpu_gem.c| 3 ++- drivers/gpu/drm/virtio/virtgpu_object.c | 1 - 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/virtio/virtgpu_gem.c b/drivers/gpu/drm/virtio/virtgpu_gem.c index 90c0a8ea1708c..1025658be4df2 100644 --- a/drivers/gpu/drm/virtio/virtgpu_gem.c +++ b/drivers/gpu/drm/virtio/virtgpu_gem.c @@ -114,7 +114,7 @@ int virtio_gpu_gem_object_open(struct drm_gem_object *obj, struct virtio_gpu_object_array *objs; if (!vgdev->has_virgl_3d) - return 0; + goto out_notify; objs = virtio_gpu_array_alloc(1); if (!objs) @@ -123,6 +123,7 @@ int virtio_gpu_gem_object_open(struct drm_gem_object *obj, virtio_gpu_cmd_context_attach_resource(vgdev, vfpriv->ctx_id, objs); +out_notify: virtio_gpu_notify(vgdev); return 0; } diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c b/drivers/gpu/drm/virtio/virtgpu_object.c index d9039bb7c5e37..51a8da7d5ef3b 100644 --- a/drivers/gpu/drm/virtio/virtgpu_object.c +++ b/drivers/gpu/drm/virtio/virtgpu_object.c @@ -241,7 +241,6 @@ int virtio_gpu_object_create(struct virtio_gpu_device *vgdev, return ret; } - virtio_gpu_notify(vgdev); *bo_ptr = bo; return 0; -- 2.24.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/mediatek: Remove debug messages for function calls
Hi, Enric:
On Wed, 2020-02-26 at 12:27 +0100, Enric Balletbo i Serra wrote:
> Equivalent information can be nowadays obtained using function tracer.
>
> Signed-off-by: Enric Balletbo i Serra
> ---
Acked-by: CK Hu
>
> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 5 -
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 --
> 2 files changed, 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> index a236499123aa..882c690d3f13 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> @@ -192,7 +192,6 @@ static int mtk_crtc_ddp_clk_enable(struct mtk_drm_crtc
> *mtk_crtc)
> int ret;
> int i;
>
> - DRM_DEBUG_DRIVER("%s\n", __func__);
> for (i = 0; i < mtk_crtc->ddp_comp_nr; i++) {
> ret = clk_prepare_enable(mtk_crtc->ddp_comp[i]->clk);
> if (ret) {
> @@ -212,7 +211,6 @@ static void mtk_crtc_ddp_clk_disable(struct mtk_drm_crtc
> *mtk_crtc)
> {
> int i;
>
> - DRM_DEBUG_DRIVER("%s\n", __func__);
> for (i = 0; i < mtk_crtc->ddp_comp_nr; i++)
> clk_disable_unprepare(mtk_crtc->ddp_comp[i]->clk);
> }
> @@ -257,7 +255,6 @@ static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc
> *mtk_crtc)
> int ret;
> int i;
>
> - DRM_DEBUG_DRIVER("%s\n", __func__);
> if (WARN_ON(!crtc->state))
> return -EINVAL;
>
> @@ -298,7 +295,6 @@ static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc
> *mtk_crtc)
> goto err_mutex_unprepare;
> }
>
> - DRM_DEBUG_DRIVER("mediatek_ddp_ddp_path_setup\n");
> for (i = 0; i < mtk_crtc->ddp_comp_nr - 1; i++) {
> mtk_ddp_add_comp_to_path(mtk_crtc->config_regs,
>mtk_crtc->ddp_comp[i]->id,
> @@ -348,7 +344,6 @@ static void mtk_crtc_ddp_hw_fini(struct mtk_drm_crtc
> *mtk_crtc)
> struct drm_crtc *crtc = _crtc->base;
> int i;
>
> - DRM_DEBUG_DRIVER("%s\n", __func__);
> for (i = 0; i < mtk_crtc->ddp_comp_nr; i++) {
> mtk_ddp_comp_stop(mtk_crtc->ddp_comp[i]);
> if (i == 1)
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index 17f118ee0e57..4934834977b3 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -570,7 +570,6 @@ static int mtk_drm_sys_suspend(struct device *dev)
> int ret;
>
> ret = drm_mode_config_helper_suspend(drm);
> - DRM_DEBUG_DRIVER("mtk_drm_sys_suspend\n");
>
> return ret;
> }
> @@ -582,7 +581,6 @@ static int mtk_drm_sys_resume(struct device *dev)
> int ret;
>
> ret = drm_mode_config_helper_resume(drm);
> - DRM_DEBUG_DRIVER("mtk_drm_sys_resume\n");
>
> return ret;
> }
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [SPAM][PATCH] drm/mediatek: Remove debug messages for function calls
Hi, Enric:
On Wed, 2020-02-26 at 12:27 +0100, Enric Balletbo i Serra wrote:
> Equivalent information can be nowadays obtained using function tracer.
>
Acked-by: CK Hu
> Signed-off-by: Enric Balletbo i Serra
> ---
>
> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 5 -
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 --
> 2 files changed, 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> index a236499123aa..882c690d3f13 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> @@ -192,7 +192,6 @@ static int mtk_crtc_ddp_clk_enable(struct mtk_drm_crtc
> *mtk_crtc)
> int ret;
> int i;
>
> - DRM_DEBUG_DRIVER("%s\n", __func__);
> for (i = 0; i < mtk_crtc->ddp_comp_nr; i++) {
> ret = clk_prepare_enable(mtk_crtc->ddp_comp[i]->clk);
> if (ret) {
> @@ -212,7 +211,6 @@ static void mtk_crtc_ddp_clk_disable(struct mtk_drm_crtc
> *mtk_crtc)
> {
> int i;
>
> - DRM_DEBUG_DRIVER("%s\n", __func__);
> for (i = 0; i < mtk_crtc->ddp_comp_nr; i++)
> clk_disable_unprepare(mtk_crtc->ddp_comp[i]->clk);
> }
> @@ -257,7 +255,6 @@ static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc
> *mtk_crtc)
> int ret;
> int i;
>
> - DRM_DEBUG_DRIVER("%s\n", __func__);
> if (WARN_ON(!crtc->state))
> return -EINVAL;
>
> @@ -298,7 +295,6 @@ static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc
> *mtk_crtc)
> goto err_mutex_unprepare;
> }
>
> - DRM_DEBUG_DRIVER("mediatek_ddp_ddp_path_setup\n");
> for (i = 0; i < mtk_crtc->ddp_comp_nr - 1; i++) {
> mtk_ddp_add_comp_to_path(mtk_crtc->config_regs,
>mtk_crtc->ddp_comp[i]->id,
> @@ -348,7 +344,6 @@ static void mtk_crtc_ddp_hw_fini(struct mtk_drm_crtc
> *mtk_crtc)
> struct drm_crtc *crtc = _crtc->base;
> int i;
>
> - DRM_DEBUG_DRIVER("%s\n", __func__);
> for (i = 0; i < mtk_crtc->ddp_comp_nr; i++) {
> mtk_ddp_comp_stop(mtk_crtc->ddp_comp[i]);
> if (i == 1)
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index 17f118ee0e57..4934834977b3 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -570,7 +570,6 @@ static int mtk_drm_sys_suspend(struct device *dev)
> int ret;
>
> ret = drm_mode_config_helper_suspend(drm);
> - DRM_DEBUG_DRIVER("mtk_drm_sys_suspend\n");
>
> return ret;
> }
> @@ -582,7 +581,6 @@ static int mtk_drm_sys_resume(struct device *dev)
> int ret;
>
> ret = drm_mode_config_helper_resume(drm);
> - DRM_DEBUG_DRIVER("mtk_drm_sys_resume\n");
>
> return ret;
> }
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206021] AMDGPU/DC: freesync disabled on the monitor side after the monitor sleeps and resumes
https://bugzilla.kernel.org/show_bug.cgi?id=206021 --- Comment #6 from Clément Guérin (li...@protonmail.com) --- Is anyone looking at this? I can still reproduce the bug 100%. -- 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 4/4] dt-bindings: Add missing 'additionalProperties: false'
On Wed, Mar 25, 2020 at 04:05:41PM -0600, Rob Herring wrote: > Setting 'additionalProperties: false' is frequently omitted, but is > important in order to check that there aren't extra undocumented > properties in a binding. > > Ideally, we'd just add this automatically and make this the default, but > there's some cases where it doesn't work. For example, if a common > schema is referenced, then properties in the common schema aren't part > of what's considered for 'additionalProperties'. Also, sometimes there > are bus specific properties such as 'spi-max-frequency' that go into > bus child nodes, but aren't defined in the child node's schema. Acked-by: Mark Brown signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/4] dt-bindings: iio/accel: Drop duplicate adi, adxl345/6 from trivial-devices.yaml
The 'adi,adxl345' definition is a duplicate as there's a full binding in: Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml The trivial-devices binding doesn't capture that 'adi,adxl346' has a fallback compatible 'adi,adxl345', so let's add it to adi,adxl345.yaml. Cc: Michael Hennerich Cc: Jonathan Cameron Cc: Hartmut Knaack Cc: Lars-Peter Clausen Cc: Peter Meerwald-Stadler Cc: linux-...@vger.kernel.org Signed-off-by: Rob Herring --- .../devicetree/bindings/iio/accel/adi,adxl345.yaml | 10 +++--- Documentation/devicetree/bindings/trivial-devices.yaml | 4 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml b/Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml index c602b6fe1c0c..d124eba1ce54 100644 --- a/Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml +++ b/Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml @@ -17,9 +17,13 @@ description: | properties: compatible: -enum: - - adi,adxl345 - - adi,adxl375 +oneOf: + - items: + - const: adi,adxl346 + - const: adi,adxl345 + - enum: + - adi,adxl345 + - adi,adxl375 reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml index 978de7d37c66..51d1f6e43c02 100644 --- a/Documentation/devicetree/bindings/trivial-devices.yaml +++ b/Documentation/devicetree/bindings/trivial-devices.yaml @@ -42,10 +42,6 @@ properties: - adi,adt7476 # +/-1C TDM Extended Temp Range I.C - adi,adt7490 -# Three-Axis Digital Accelerometer - - adi,adxl345 -# Three-Axis Digital Accelerometer (backward-compatibility value "adi,adxl345" must be listed too) - - adi,adxl346 # AMS iAQ-Core VOC Sensor - ams,iaq-core # i2c serial eeprom (24cxx) -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/4] dt-bindings: additionalProperties clean-up
Setting 'additionalProperties: false' is frequently omitted, but is important in order to check that there aren't extra undocumented properties in a binding. This series is a bunch of fixes in patches 1-3 found by setting 'additionalProperties: false' and then patch 4 sets additionalProperties on a bunch of schema. Rob Rob Herring (4): dt-bindings: iio/accel: Drop duplicate adi,adxl345/6 from trivial-devices.yaml dt-bindings: sram: qcom: Clean-up 'ranges' and child node names dt-bindings: Clean-up schema errors due to missing 'addtionalProperties: false' dt-bindings: Add missing 'additionalProperties: false' .../arm/altera/socfpga-clk-manager.yaml | 2 ++ .../amlogic/amlogic,meson-gx-ao-secure.yaml | 2 ++ .../bindings/arm/msm/qcom,llcc.yaml | 2 ++ .../devicetree/bindings/arm/renesas,prr.yaml | 2 ++ .../bindings/arm/samsung/exynos-chipid.yaml | 2 ++ .../devicetree/bindings/arm/samsung/pmu.yaml | 2 ++ .../arm/samsung/samsung-secure-firmware.yaml | 2 ++ .../bindings/arm/stm32/st,stm32-syscon.yaml | 2 ++ .../devicetree/bindings/clock/fsl,plldig.yaml | 5 .../bindings/clock/imx8mn-clock.yaml | 2 ++ .../bindings/clock/imx8mp-clock.yaml | 2 ++ .../bindings/clock/milbeaut-clock.yaml| 2 ++ .../bindings/clock/qcom,gcc-apq8064.yaml | 2 ++ .../bindings/clock/qcom,gcc-ipq8074.yaml | 2 ++ .../bindings/clock/qcom,gcc-msm8996.yaml | 2 ++ .../bindings/clock/qcom,gcc-msm8998.yaml | 2 ++ .../bindings/clock/qcom,gcc-qcs404.yaml | 2 ++ .../bindings/clock/qcom,gcc-sc7180.yaml | 2 ++ .../bindings/clock/qcom,gcc-sm8150.yaml | 2 ++ .../devicetree/bindings/clock/qcom,gcc.yaml | 2 ++ .../devicetree/bindings/clock/qcom,mmcc.yaml | 2 ++ .../bindings/clock/qcom,msm8998-gpucc.yaml| 2 ++ .../bindings/clock/qcom,rpmhcc.yaml | 2 ++ .../bindings/clock/qcom,sc7180-dispcc.yaml| 2 ++ .../bindings/clock/qcom,sc7180-gpucc.yaml | 2 ++ .../bindings/clock/qcom,sc7180-videocc.yaml | 2 ++ .../bindings/clock/qcom,sdm845-dispcc.yaml| 2 ++ .../bindings/clock/qcom,sdm845-gpucc.yaml | 2 ++ .../bindings/clock/qcom,sdm845-videocc.yaml | 2 ++ .../bindings/display/amlogic,meson-vpu.yaml | 2 ++ .../bindings/dma/sifive,fu540-c000-pdma.yaml | 2 ++ .../devicetree/bindings/dsp/fsl,dsp.yaml | 2 ++ .../devicetree/bindings/eeprom/at24.yaml | 2 ++ ...ntel,ixp4xx-network-processing-engine.yaml | 3 +++ .../bindings/gpio/brcm,xgs-iproc-gpio.yaml| 2 ++ .../gpio/socionext,uniphier-gpio.yaml | 4 +++ .../bindings/gpio/xylon,logicvc-gpio.yaml | 2 ++ .../bindings/gpu/arm,mali-bifrost.yaml| 8 +++--- .../bindings/gpu/arm,mali-midgard.yaml| 5 .../bindings/gpu/arm,mali-utgard.yaml | 2 ++ .../bindings/gpu/samsung-rotator.yaml | 2 ++ .../bindings/hwmon/adi,adm1177.yaml | 2 ++ .../bindings/hwmon/adi,ltc2947.yaml | 2 ++ .../bindings/hwmon/pmbus/ti,ucd90320.yaml | 2 ++ .../devicetree/bindings/hwmon/ti,tmp513.yaml | 2 ++ .../bindings/iio/accel/adi,adxl345.yaml | 10 +--- .../bindings/iio/accel/bosch,bma400.yaml | 2 ++ .../bindings/iio/adc/adi,ad7192.yaml | 1 - .../bindings/iio/adc/adi,ad7780.yaml | 2 ++ .../bindings/iio/adc/avia-hx711.yaml | 2 ++ .../bindings/iio/adc/lltc,ltc2496.yaml| 2 ++ .../bindings/iio/adc/microchip,mcp3911.yaml | 2 ++ .../bindings/iio/adc/st,stm32-dfsdm-adc.yaml | 2 ++ .../iio/chemical/plantower,pms7003.yaml | 2 ++ .../iio/chemical/sensirion,sps30.yaml | 2 ++ .../bindings/iio/dac/lltc,ltc1660.yaml| 2 ++ .../bindings/iio/light/adux1020.yaml | 2 ++ .../devicetree/bindings/iio/light/bh1750.yaml | 2 ++ .../bindings/iio/light/isl29018.yaml | 2 ++ .../bindings/iio/light/noa1305.yaml | 2 ++ .../bindings/iio/light/stk33xx.yaml | 2 ++ .../bindings/iio/light/tsl2583.yaml | 2 ++ .../bindings/iio/light/tsl2772.yaml | 2 ++ .../bindings/iio/light/veml6030.yaml | 2 ++ .../bindings/iio/pressure/asc,dlhl60d.yaml| 2 ++ .../bindings/iio/pressure/bmp085.yaml | 5 .../iio/proximity/devantech-srf04.yaml| 2 ++ .../bindings/iio/proximity/parallax-ping.yaml | 2 ++ .../bindings/iio/temperature/adi,ltc2983.yaml | 2 ++ .../bindings/input/gpio-vibrator.yaml | 2 ++ .../bindings/input/max77650-onkey.yaml| 3 +++ .../intel,ixp4xx-interrupt.yaml | 2 ++ .../bindings/iommu/samsung,sysmmu.yaml| 2 ++ .../bindings/leds/leds-max77650.yaml | 3 +++ .../bindings/leds/rohm,bd71828-leds.yaml | 3 +++ .../mailbox/amlogic,meson-gxbb-mhu.yaml | 2 ++ .../bindings/media/amlogic,gx-vdec.yaml | 2 ++ .../media/amlogic,meson-gx-ao-cec.yaml| 11 +--- .../bindings/media/renesas,ceu.yaml
[PATCH 2/4] dt-bindings: sram: qcom: Clean-up 'ranges' and child node names
The regex for child nodes doesn't match the example. This wasn't flagged
with 'additionalProperties: false' missing. The child node schema was also
incorrect with 'ranges' property as it applies to child nodes and should
be moved up to the parent node.
Fixes: 957fd69d396b ("dt-bindings: soc: qcom: add On Chip MEMory (OCMEM)
bindings")
Cc: Brian Masney
Cc: Bjorn Andersson
Cc: linux-arm-...@vger.kernel.org
Signed-off-by: Rob Herring
---
.../devicetree/bindings/sram/qcom,ocmem.yaml | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/sram/qcom,ocmem.yaml
b/Documentation/devicetree/bindings/sram/qcom,ocmem.yaml
index 222990f9923c..469cec133647 100644
--- a/Documentation/devicetree/bindings/sram/qcom,ocmem.yaml
+++ b/Documentation/devicetree/bindings/sram/qcom,ocmem.yaml
@@ -43,6 +43,9 @@ properties:
'#size-cells':
const: 1
+ ranges:
+maxItems: 1
+
required:
- compatible
- reg
@@ -51,9 +54,10 @@ required:
- clock-names
- '#address-cells'
- '#size-cells'
+ - ranges
patternProperties:
- "^.+-sram$":
+ "-sram@[0-9a-f]+$":
type: object
description: A region of reserved memory.
@@ -61,12 +65,8 @@ patternProperties:
reg:
maxItems: 1
- ranges:
-maxItems: 1
-
required:
- reg
- - ranges
examples:
- |
@@ -88,9 +88,9 @@ examples:
#address-cells = <1>;
#size-cells = <1>;
+ranges = <0 0xfec0 0x10>;
gmu-sram@0 {
reg = <0x0 0x10>;
-ranges = <0 0 0xfec0 0x10>;
};
};
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/4] dt-bindings: Add missing 'additionalProperties: false'
Setting 'additionalProperties: false' is frequently omitted, but is important in order to check that there aren't extra undocumented properties in a binding. Ideally, we'd just add this automatically and make this the default, but there's some cases where it doesn't work. For example, if a common schema is referenced, then properties in the common schema aren't part of what's considered for 'additionalProperties'. Also, sometimes there are bus specific properties such as 'spi-max-frequency' that go into bus child nodes, but aren't defined in the child node's schema. So let's stick with the json-schema defined default and add 'additionalProperties: false' where needed. This will be a continual review comment and game of wack-a-mole. Signed-off-by: Rob Herring --- .../devicetree/bindings/arm/altera/socfpga-clk-manager.yaml| 2 ++ .../bindings/arm/amlogic/amlogic,meson-gx-ao-secure.yaml | 2 ++ Documentation/devicetree/bindings/arm/msm/qcom,llcc.yaml | 2 ++ Documentation/devicetree/bindings/arm/renesas,prr.yaml | 2 ++ .../devicetree/bindings/arm/samsung/exynos-chipid.yaml | 2 ++ Documentation/devicetree/bindings/arm/samsung/pmu.yaml | 2 ++ .../bindings/arm/samsung/samsung-secure-firmware.yaml | 2 ++ .../devicetree/bindings/arm/stm32/st,stm32-syscon.yaml | 2 ++ Documentation/devicetree/bindings/clock/fsl,plldig.yaml| 2 ++ Documentation/devicetree/bindings/clock/imx8mn-clock.yaml | 2 ++ Documentation/devicetree/bindings/clock/imx8mp-clock.yaml | 2 ++ Documentation/devicetree/bindings/clock/milbeaut-clock.yaml| 2 ++ Documentation/devicetree/bindings/clock/qcom,gcc-apq8064.yaml | 2 ++ Documentation/devicetree/bindings/clock/qcom,gcc-ipq8074.yaml | 2 ++ Documentation/devicetree/bindings/clock/qcom,gcc-msm8996.yaml | 2 ++ Documentation/devicetree/bindings/clock/qcom,gcc-msm8998.yaml | 2 ++ Documentation/devicetree/bindings/clock/qcom,gcc-qcs404.yaml | 2 ++ Documentation/devicetree/bindings/clock/qcom,gcc-sc7180.yaml | 2 ++ Documentation/devicetree/bindings/clock/qcom,gcc-sm8150.yaml | 2 ++ Documentation/devicetree/bindings/clock/qcom,gcc.yaml | 2 ++ Documentation/devicetree/bindings/clock/qcom,mmcc.yaml | 2 ++ .../devicetree/bindings/clock/qcom,msm8998-gpucc.yaml | 2 ++ Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml | 2 ++ .../devicetree/bindings/clock/qcom,sc7180-dispcc.yaml | 2 ++ Documentation/devicetree/bindings/clock/qcom,sc7180-gpucc.yaml | 2 ++ .../devicetree/bindings/clock/qcom,sc7180-videocc.yaml | 2 ++ .../devicetree/bindings/clock/qcom,sdm845-dispcc.yaml | 2 ++ Documentation/devicetree/bindings/clock/qcom,sdm845-gpucc.yaml | 2 ++ .../devicetree/bindings/clock/qcom,sdm845-videocc.yaml | 2 ++ .../devicetree/bindings/display/amlogic,meson-vpu.yaml | 2 ++ .../devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml| 2 ++ Documentation/devicetree/bindings/dsp/fsl,dsp.yaml | 2 ++ Documentation/devicetree/bindings/eeprom/at24.yaml | 2 ++ .../firmware/intel,ixp4xx-network-processing-engine.yaml | 3 +++ .../devicetree/bindings/gpio/brcm,xgs-iproc-gpio.yaml | 2 ++ .../devicetree/bindings/gpio/socionext,uniphier-gpio.yaml | 2 ++ Documentation/devicetree/bindings/gpio/xylon,logicvc-gpio.yaml | 2 ++ Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml| 2 ++ Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml| 2 ++ Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml | 2 ++ Documentation/devicetree/bindings/gpu/samsung-rotator.yaml | 2 ++ Documentation/devicetree/bindings/hwmon/adi,adm1177.yaml | 2 ++ Documentation/devicetree/bindings/hwmon/adi,ltc2947.yaml | 2 ++ Documentation/devicetree/bindings/hwmon/pmbus/ti,ucd90320.yaml | 2 ++ Documentation/devicetree/bindings/hwmon/ti,tmp513.yaml | 2 ++ Documentation/devicetree/bindings/iio/accel/bosch,bma400.yaml | 2 ++ Documentation/devicetree/bindings/iio/adc/adi,ad7780.yaml | 2 ++ Documentation/devicetree/bindings/iio/adc/avia-hx711.yaml | 2 ++ Documentation/devicetree/bindings/iio/adc/lltc,ltc2496.yaml| 2 ++ .../devicetree/bindings/iio/adc/microchip,mcp3911.yaml | 2 ++ .../devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml| 2 ++ .../devicetree/bindings/iio/chemical/plantower,pms7003.yaml| 2 ++ .../devicetree/bindings/iio/chemical/sensirion,sps30.yaml | 2 ++ Documentation/devicetree/bindings/iio/dac/lltc,ltc1660.yaml| 2 ++ Documentation/devicetree/bindings/iio/light/adux1020.yaml | 2 ++ Documentation/devicetree/bindings/iio/light/bh1750.yaml| 2 ++ Documentation/devicetree/bindings/iio/light/isl29018.yaml | 2 ++ Documentation/devicetree/bindings/iio/light/noa1305.yaml | 2 ++ Documentation/devicetree/bindings/iio/light/stk33xx.yaml | 2 ++
[PATCH 3/4] dt-bindings: Clean-up schema errors due to missing 'addtionalProperties: false'
Numerous schemas are missing 'additionalProperties: false' statements which ensures a binding doesn't have any extra undocumented properties or child nodes. Fixing this reveals various missing properties, so let's fix all those occurrences. Cc: Stephen Boyd Cc: Linus Walleij Cc: Bartosz Golaszewski Cc: Masahiro Yamada Cc: Jonathan Cameron Cc: Hartmut Knaack Cc: Lars-Peter Clausen Cc: Peter Meerwald-Stadler Cc: Neil Armstrong Cc: Mauro Carvalho Chehab Cc: Kevin Hilman Cc: Lee Jones Cc: "David S. Miller" Cc: Liam Girdwood Cc: Mark Brown Cc: Guillaume La Roque Cc: Zhang Rui Cc: Daniel Lezcano Cc: Thomas Gleixner Cc: linux-...@vger.kernel.org Cc: linux-g...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: dri-devel@lists.freedesktop.org Cc: linux-...@vger.kernel.org Cc: linux-me...@vger.kernel.org Cc: linux-amlo...@lists.infradead.org Cc: net...@vger.kernel.org Cc: linux...@vger.kernel.org Signed-off-by: Rob Herring --- .../devicetree/bindings/clock/fsl,plldig.yaml | 3 +++ .../gpio/socionext,uniphier-gpio.yaml | 2 ++ .../bindings/gpu/arm,mali-bifrost.yaml| 6 ++--- .../bindings/gpu/arm,mali-midgard.yaml| 3 +++ .../bindings/iio/adc/adi,ad7192.yaml | 1 - .../bindings/iio/pressure/bmp085.yaml | 3 +++ .../media/amlogic,meson-gx-ao-cec.yaml| 9 +--- .../bindings/mfd/rohm,bd71828-pmic.yaml | 3 +++ .../bindings/net/ti,cpsw-switch.yaml | 23 --- .../regulator/max77650-regulator.yaml | 2 +- .../bindings/thermal/amlogic,thermal.yaml | 2 ++ .../bindings/timer/arm,arch_timer_mmio.yaml | 2 ++ 12 files changed, 43 insertions(+), 16 deletions(-) diff --git a/Documentation/devicetree/bindings/clock/fsl,plldig.yaml b/Documentation/devicetree/bindings/clock/fsl,plldig.yaml index c8350030b374..d1c040228cf7 100644 --- a/Documentation/devicetree/bindings/clock/fsl,plldig.yaml +++ b/Documentation/devicetree/bindings/clock/fsl,plldig.yaml @@ -21,6 +21,9 @@ properties: reg: maxItems: 1 + clocks: +maxItems: 1 + '#clock-cells': const: 0 diff --git a/Documentation/devicetree/bindings/gpio/socionext,uniphier-gpio.yaml b/Documentation/devicetree/bindings/gpio/socionext,uniphier-gpio.yaml index 580a39e09d39..c58ff9a94f45 100644 --- a/Documentation/devicetree/bindings/gpio/socionext,uniphier-gpio.yaml +++ b/Documentation/devicetree/bindings/gpio/socionext,uniphier-gpio.yaml @@ -41,6 +41,8 @@ properties: minimum: 0 maximum: 512 + gpio-ranges: true + gpio-ranges-group-names: $ref: /schemas/types.yaml#/definitions/string-array diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml index e8b99adcb1bd..05fd9a404ff7 100644 --- a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml +++ b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml @@ -43,6 +43,9 @@ properties: operating-points-v2: true + resets: +maxItems: 2 + required: - compatible - reg @@ -57,9 +60,6 @@ allOf: contains: const: amlogic,meson-g12a-mali then: - properties: -resets: - minItems: 2 required: - resets diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml index 8d966f3ff3db..6819cde050df 100644 --- a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml +++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml @@ -75,6 +75,9 @@ properties: mali-supply: true + power-domains: +maxItems: 1 + resets: minItems: 1 maxItems: 2 diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7192.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad7192.yaml index 84d25bd39488..d0913034b1d8 100644 --- a/Documentation/devicetree/bindings/iio/adc/adi,ad7192.yaml +++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7192.yaml @@ -106,7 +106,6 @@ examples: spi-cpha; clocks = <_mclk>; clock-names = "mclk"; -#interrupt-cells = <2>; interrupts = <25 0x2>; interrupt-parent = <>; dvdd-supply = <>; diff --git a/Documentation/devicetree/bindings/iio/pressure/bmp085.yaml b/Documentation/devicetree/bindings/iio/pressure/bmp085.yaml index 519137e5c170..5d4aec0e0d24 100644 --- a/Documentation/devicetree/bindings/iio/pressure/bmp085.yaml +++ b/Documentation/devicetree/bindings/iio/pressure/bmp085.yaml @@ -25,6 +25,9 @@ properties: - bosch,bmp280 - bosch,bme280 + reg: +maxItems: 1 + vddd-supply: description: digital voltage regulator (see regulator/regulator.txt) diff --git a/Documentation/devicetree/bindings/media/amlogic,meson-gx-ao-cec.yaml b/Documentation/devicetree/bindings/media/amlogic,meson-gx-ao-cec.yaml index 41197578f19a..e8ce37fcbfec 100644 ---
Re: [PATCH] drm/virtio: delete notify in virtio_gpu_object_create
On Wed, Mar 25, 2020 at 8:41 AM Gurchetan Singh
wrote:
>
> For 3D buffers, virtio_gpu_gem_object_open notifies.
> We can have the same behavior for dumb buffer. We just
> need to make sure the first open notifies the host for
> dumb buffers.
virtio_gpu_notify is cheap and does not kick unless there is a need.
I probably won't bother with adding `bool notified', which adds a
(harmless) data race.
>
> v2: virtio_gpu_gem_object_open always notifies
>
> Signed-off-by: Gurchetan Singh
> ---
> drivers/gpu/drm/virtio/virtgpu_drv.h| 1 +
> drivers/gpu/drm/virtio/virtgpu_gem.c| 10 --
> drivers/gpu/drm/virtio/virtgpu_object.c | 1 -
> 3 files changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
> b/drivers/gpu/drm/virtio/virtgpu_drv.h
> index 79ad176aca5a8..842200e01d785 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_drv.h
> +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
> @@ -71,6 +71,7 @@ struct virtio_gpu_object {
> uint32_t hw_res_handle;
> bool dumb;
> bool created;
> + bool notified;
> };
> #define gem_to_virtio_gpu_obj(gobj) \
> container_of((gobj), struct virtio_gpu_object, base.base)
> diff --git a/drivers/gpu/drm/virtio/virtgpu_gem.c
> b/drivers/gpu/drm/virtio/virtgpu_gem.c
> index 90c0a8ea1708c..597ddb7391fb9 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_gem.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_gem.c
> @@ -111,10 +111,13 @@ int virtio_gpu_gem_object_open(struct drm_gem_object
> *obj,
> {
> struct virtio_gpu_device *vgdev = obj->dev->dev_private;
> struct virtio_gpu_fpriv *vfpriv = file->driver_priv;
> + struct virtio_gpu_object *bo = gem_to_virtio_gpu_obj(obj);
> struct virtio_gpu_object_array *objs;
>
> - if (!vgdev->has_virgl_3d)
> - return 0;
> + if (!vgdev->has_virgl_3d && !bo->notified)
> + goto out_notify;
> + else if (!vgdev->has_virgl_3d)
> + goto out;
>
> objs = virtio_gpu_array_alloc(1);
> if (!objs)
> @@ -123,7 +126,10 @@ int virtio_gpu_gem_object_open(struct drm_gem_object
> *obj,
>
> virtio_gpu_cmd_context_attach_resource(vgdev, vfpriv->ctx_id,
>objs);
> +out_notify:
> + bo->notified = true;
> virtio_gpu_notify(vgdev);
> +out:
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c
> b/drivers/gpu/drm/virtio/virtgpu_object.c
> index d9039bb7c5e37..51a8da7d5ef3b 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_object.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_object.c
> @@ -241,7 +241,6 @@ int virtio_gpu_object_create(struct virtio_gpu_device
> *vgdev,
> return ret;
> }
>
> - virtio_gpu_notify(vgdev);
> *bo_ptr = bo;
> return 0;
>
> --
> 2.24.1
>
> ___
> 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 2/2] gpu: host1x: Use SMMU on Tegra124 and Tegra210
On 25/03/2020 20:16, Thierry Reding wrote: > From: Thierry Reding > > Tegra124 and Tegra210 support addressing more than 32 bits of physical > memory. However, since their host1x does not support the wide GATHER > opcode, they should use the SMMU if at all possible to ensure that all > the system memory can be used for command buffers, irrespective of > whether or not the host1x firewall is enabled. > > Signed-off-by: Thierry Reding > --- > drivers/gpu/host1x/dev.c | 46 > 1 file changed, 42 insertions(+), 4 deletions(-) Tested-by: Jon Hunter Cheers Jon -- nvpublic ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/tegra: Fix SMMU support on Tegra124 and Tegra210
On 25/03/2020 20:16, Thierry Reding wrote:
> From: Thierry Reding
>
> When testing whether or not to enable the use of the SMMU, consult the
> supported DMA mask rather than the actually configured DMA mask, since
> the latter might already have been restricted.
>
> Fixes: 2d9384ff9177 ("drm/tegra: Relax IOMMU usage criteria on old Tegra")
> Signed-off-by: Thierry Reding
> ---
> drivers/gpu/drm/tegra/drm.c | 3 ++-
> drivers/gpu/host1x/dev.c| 13 +
> include/linux/host1x.h | 3 +++
> 3 files changed, 18 insertions(+), 1 deletion(-)
Tested-by: Jon Hunter
Cheers
Jon
--
nvpublic
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/tegra: Fix SMMU support on Tegra124 and Tegra210
From: Thierry Reding
When testing whether or not to enable the use of the SMMU, consult the
supported DMA mask rather than the actually configured DMA mask, since
the latter might already have been restricted.
Fixes: 2d9384ff9177 ("drm/tegra: Relax IOMMU usage criteria on old Tegra")
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/drm.c | 3 ++-
drivers/gpu/host1x/dev.c| 13 +
include/linux/host1x.h | 3 +++
3 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index bd268028fb3d..583cd6e0ae27 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -1039,6 +1039,7 @@ void tegra_drm_free(struct tegra_drm *tegra, size_t size,
void *virt,
static bool host1x_drm_wants_iommu(struct host1x_device *dev)
{
+ struct host1x *host1x = dev_get_drvdata(dev->dev.parent);
struct iommu_domain *domain;
/*
@@ -1076,7 +1077,7 @@ static bool host1x_drm_wants_iommu(struct host1x_device
*dev)
* sufficient and whether or not the host1x is attached to an IOMMU
* doesn't matter.
*/
- if (!domain && dma_get_mask(dev->dev.parent) <= DMA_BIT_MASK(32))
+ if (!domain && host1x_get_dma_mask(host1x) <= DMA_BIT_MASK(32))
return true;
return domain != NULL;
diff --git a/drivers/gpu/host1x/dev.c b/drivers/gpu/host1x/dev.c
index 388bcc2889aa..40a4b9f8b861 100644
--- a/drivers/gpu/host1x/dev.c
+++ b/drivers/gpu/host1x/dev.c
@@ -502,6 +502,19 @@ static void __exit tegra_host1x_exit(void)
}
module_exit(tegra_host1x_exit);
+/**
+ * host1x_get_dma_mask() - query the supported DMA mask for host1x
+ * @host1x: host1x instance
+ *
+ * Note that this returns the supported DMA mask for host1x, which can be
+ * different from the applicable DMA mask under certain circumstances.
+ */
+u64 host1x_get_dma_mask(struct host1x *host1x)
+{
+ return host1x->info->dma_mask;
+}
+EXPORT_SYMBOL(host1x_get_dma_mask);
+
MODULE_AUTHOR("Thierry Reding ");
MODULE_AUTHOR("Terje Bergstrom ");
MODULE_DESCRIPTION("Host1x driver for Tegra products");
diff --git a/include/linux/host1x.h b/include/linux/host1x.h
index 62d216ff1097..c230b4e70d75 100644
--- a/include/linux/host1x.h
+++ b/include/linux/host1x.h
@@ -17,9 +17,12 @@ enum host1x_class {
HOST1X_CLASS_GR3D = 0x60,
};
+struct host1x;
struct host1x_client;
struct iommu_group;
+u64 host1x_get_dma_mask(struct host1x *host1x);
+
/**
* struct host1x_client_ops - host1x client operations
* @init: host1x client initialization code
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] gpu: host1x: Use SMMU on Tegra124 and Tegra210
From: Thierry Reding
Tegra124 and Tegra210 support addressing more than 32 bits of physical
memory. However, since their host1x does not support the wide GATHER
opcode, they should use the SMMU if at all possible to ensure that all
the system memory can be used for command buffers, irrespective of
whether or not the host1x firewall is enabled.
Signed-off-by: Thierry Reding
---
drivers/gpu/host1x/dev.c | 46
1 file changed, 42 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/host1x/dev.c b/drivers/gpu/host1x/dev.c
index 40a4b9f8b861..d24344e91922 100644
--- a/drivers/gpu/host1x/dev.c
+++ b/drivers/gpu/host1x/dev.c
@@ -192,17 +192,55 @@ static void host1x_setup_sid_table(struct host1x *host)
}
}
+static bool host1x_wants_iommu(struct host1x *host1x)
+{
+ /*
+* If we support addressing a maximum of 32 bits of physical memory
+* and if the host1x firewall is enabled, there's no need to enable
+* IOMMU support. This can happen for example on Tegra20, Tegra30
+* and Tegra114.
+*
+* Tegra124 and later can address up to 34 bits of physical memory and
+* many platforms come equipped with more than 2 GiB of system memory,
+* which requires crossing the 4 GiB boundary. But there's a catch: on
+* SoCs before Tegra186 (i.e. Tegra124 and Tegra210), the host1x can
+* only address up to 32 bits of memory in GATHER opcodes, which means
+* that command buffers need to either be in the first 2 GiB of system
+* memory (which could quickly lead to memory exhaustion), or command
+* buffers need to be treated differently from other buffers (which is
+* not possible with the current ABI).
+*
+* A third option is to use the IOMMU in these cases to make sure all
+* buffers will be mapped into a 32-bit IOVA space that host1x can
+* address. This allows all of the system memory to be used and works
+* within the limitations of the host1x on these SoCs.
+*
+* In summary, default to enable IOMMU on Tegra124 and later. For any
+* of the earlier SoCs, only use the IOMMU for additional safety when
+* the host1x firewall is disabled.
+*/
+ if (host1x->info->dma_mask <= DMA_BIT_MASK(32)) {
+ if (IS_ENABLED(CONFIG_TEGRA_HOST1X_FIREWALL))
+ return false;
+ }
+
+ return true;
+}
+
static struct iommu_domain *host1x_iommu_attach(struct host1x *host)
{
struct iommu_domain *domain = iommu_get_domain_for_dev(host->dev);
int err;
/*
-* If the host1x firewall is enabled, there's no need to enable IOMMU
-* support. Similarly, if host1x is already attached to an IOMMU (via
-* the DMA API), don't try to attach again.
+* We may not always want to enable IOMMU support (for example if the
+* host1x firewall is already enabled and we don't support addressing
+* more than 32 bits of physical memory), so check for that first.
+*
+* Similarly, if host1x is already attached to an IOMMU (via the DMA
+* API), don't try to attach again.
*/
- if (IS_ENABLED(CONFIG_TEGRA_HOST1X_FIREWALL) || domain)
+ if (!host1x_wants_iommu(host) || domain)
return domain;
host->group = iommu_group_get(host->dev);
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/3] dt-bindings: display: panel: Convert sitronix,st7701 to DT schema
On Wed, Mar 18, 2020 at 11:10 AM Jagan Teki wrote:
>
> Convert the sitronix,st7701 panel bindings to DT schema.
>
> Signed-off-by: Jagan Teki
> ---
> Changes for v2:
> - fix dt_binding_check
>
> .../display/panel/sitronix,st7701.txt | 30
> .../display/panel/sitronix,st7701.yaml| 68 +++
> 2 files changed, 68 insertions(+), 30 deletions(-)
> delete mode 100644
> Documentation/devicetree/bindings/display/panel/sitronix,st7701.txt
> create mode 100644
> Documentation/devicetree/bindings/display/panel/sitronix,st7701.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/panel/sitronix,st7701.txt
> b/Documentation/devicetree/bindings/display/panel/sitronix,st7701.txt
> deleted file mode 100644
> index ccd17597f1f6..
> --- a/Documentation/devicetree/bindings/display/panel/sitronix,st7701.txt
> +++ /dev/null
> @@ -1,30 +0,0 @@
> -Sitronix ST7701 based LCD panels
> -
> -ST7701 designed for small and medium sizes of TFT LCD display, is
> -capable of supporting up to 480RGBX864 in resolution. It provides
> -several system interfaces like MIPI/RGB/SPI.
> -
> -Techstar TS8550B is 480x854, 2-lane MIPI DSI LCD panel which has
> -inbuilt ST7701 chip.
> -
> -Required properties:
> -- compatible: must be "sitronix,st7701" and one of
> - * "techstar,ts8550b"
> -- reset-gpios: a GPIO phandle for the reset pin
> -
> -Required properties for techstar,ts8550b:
> -- reg: DSI virtual channel used by that screen
> -- VCC-supply: analog regulator for MIPI circuit
> -- IOVCC-supply: I/O system regulator
> -
> -Optional properties:
> -- backlight: phandle for the backlight control.
> -
> -panel@0 {
> - compatible = "techstar,ts8550b", "sitronix,st7701";
> - reg = <0>;
> - VCC-supply = <_dldo2>;
> - IOVCC-supply = <_dldo2>;
> - reset-gpios = < 3 24 GPIO_ACTIVE_HIGH>; /* LCD-RST: PD24 */
> - backlight = <>;
> -};
> diff --git
> a/Documentation/devicetree/bindings/display/panel/sitronix,st7701.yaml
> b/Documentation/devicetree/bindings/display/panel/sitronix,st7701.yaml
> new file mode 100644
> index ..e02686dfd937
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/sitronix,st7701.yaml
> @@ -0,0 +1,68 @@
> +# SPDX-License-Identifier: (GPL-2.0+ OR X11)
Do you have rights on the old doc to change the license? If so, it should be:
(GPL-2.0-only OR BSD-2-Clause)
If not, GPL-2.0-only.
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/panel/sitronix,st7701.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Sitronix ST7701 based LCD panels
> +
> +maintainers:
> + - Jagan Teki
> +
> +description: |
> + ST7701 designed for small and medium sizes of TFT LCD display, is
> + capable of supporting up to 480RGBX864 in resolution. It provides
> + several system interfaces like MIPI/RGB/SPI.
> +
> + Techstar TS8550B is 480x854, 2-lane MIPI DSI LCD panel which has
> + inbuilt ST7701 chip.
Reference panel-common.yaml here.
> +
> +properties:
> + compatible:
> +items:
> + - enum:
> + - techstar,ts8550b
> + - const: sitronix,st7701
> +
> + reg:
> +description: DSI virtual channel used by that screen
maxItems: 1
> +
> + VCC-supply:
> +description: analog regulator for MIPI circuit
> +
> + IOVCC-supply:
> +description: I/O system regulator
> +
> + reset-gpios:
> +description: a GPIO phandle for the reset pin
Just 'reset-gpios: true'. Already defined by panel-common.yaml.
> +
> + backlight:
> +description: Backlight used by the panel
> +$ref: "/schemas/types.yaml#/definitions/phandle"
Same here. Just need 'true'.
> +
> +required:
> + - compatible
> + - reg
> + - VCC-supply
> + - IOVCC-supply
> + - reset-gpios
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +#include
> +
> +dsi {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +panel@0 {
> +compatible = "techstar,ts8550b", "sitronix,st7701";
> +reg = <0>;
> +VCC-supply = <_dldo2>;
> +IOVCC-supply = <_dldo2>;
> +reset-gpios = < 3 24 GPIO_ACTIVE_HIGH>; /* LCD-RST: PD24 */
> +backlight = <>;
> +};
> +};
> --
> 2.17.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Variable Refresh Rate & flickering screens
On Tue, Mar 17, 2020 at 09:25:33AM -0400, Harry Wentland wrote: > > > On 2020-03-17 5:08 a.m., Simon Ser wrote: > > On Thursday, March 12, 2020 3:43 PM, Harry Wentland > > wrote: > > > >> Not the main VRR expert and we're still discussing this internally but I > >> think it'll very much depend on the display whether you'll see flicker > >> in this case. > >> > >> The other complication is that for gaming we don't want to use the > >> cursor as a VRR trigger and only look at page flips in order to allow > >> for smooth gameplay. For a desktop use-case that's probably not the > >> right policy. > > > > I think user-space can handle this and correctly synchronize cursor > > updates with game updates via the KMS atomic API. > > > > However I still think flickering should be avoided by the hardware. > > Flickering is a completely separate issue and user-space shouldn't add > > workarounds for screen issues like this. > > > > Do you think that would be acceptable? Do you have any "slew rate > > register" in AMD hardware? > > In case of Intel HW, we do have a way to program the maxshift so the max increment or decrement in the vblank in successive frames. This is designed to be used for the displays that have a restriction on the maximum change in refresh rate between two consecutive frames. But I am still figuring out how the panel indicates this restriction that we need to program in the HW registers. Harry/SImon, do you know of any such panels that have these restrictions and if they indicate this limitation or the maxshift through EDID or DPCD? Manasi > > There are no slew rate registers in current AMD HW but I also think > slewing would best be done in kernel space, either directly in HW by HW > that supports it or in SW for HW that doesn't support it. > > Harry > > > Thanks, > > > > Simon > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: Improve CONFIG_DMABUF_MOVE_NOTIFY help text
On Tue, Mar 24, 2020 at 8:54 AM Geert Uytterhoeven
wrote:
>
> Improve the help text for the CONFIG_DMABUF_MOVE_NOTIFY symbol by:
> 1. Removing duplicated single quotes,
> 2. Adding a missing subject,
> 3. Fixing a misspelling of "yet",
> 4. Wrapping long lines.
>
> Fixes: bb42df4662a44765 ("dma-buf: add dynamic DMA-buf handling v15")
> Signed-off-by: Geert Uytterhoeven
Applied. Thanks!
Alex
> ---
> drivers/dma-buf/Kconfig | 11 ++-
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig
> index ef73b678419c6d86..9626673f1d83ae64 100644
> --- a/drivers/dma-buf/Kconfig
> +++ b/drivers/dma-buf/Kconfig
> @@ -43,11 +43,12 @@ config DMABUF_MOVE_NOTIFY
> bool "Move notify between drivers (EXPERIMENTAL)"
> default n
> help
> - Don''t pin buffers if the dynamic DMA-buf interface is available on
> both the
> - exporter as well as the importer. This fixes a security problem
> where
> - userspace is able to pin unrestricted amounts of memory through
> DMA-buf.
> - But marked experimental because we don''t jet have a consistent
> execution
> - context and memory management between drivers.
> + Don't pin buffers if the dynamic DMA-buf interface is available on
> + both the exporter as well as the importer. This fixes a security
> + problem where userspace is able to pin unrestricted amounts of
> memory
> + through DMA-buf.
> + This is marked experimental because we don't yet have a consistent
> + execution context and memory management between drivers.
>
> config DMABUF_SELFTESTS
> tristate "Selftests for the dma-buf interfaces"
> --
> 2.17.1
>
> ___
> 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: [Intel-gfx] [PATCH 02/51] drm/i915: Don't clear drvdata in ->release
On Mon, 23 Mar 2020, Daniel Vetter wrote: > For two reasons: > > - The driver core clears this already for us after we're unloaded in > __device_release_driver(). > > - It's way too late, the drm_device ->release callback might massively > outlive the underlying physical device, since a drm_device can't be *can be*? > kept alive by open drm_file or well really anything else userspace > is still hanging onto. So if we clear this ourselves, we should > clear it in the pci ->remove callback, not in the drm_device > ->relase callback. ->release Reviewed-by: Jani Nikula > > Looking at git history this was fixed in the driver core with > > commit 0998d0631001288a5974afc0b2a5f568bcdecb4d > Author: Hans de Goede > Date: Wed May 23 00:09:34 2012 +0200 > > device-core: Ensure drvdata = NULL when no driver is bound > > v2: Cite the core fix in the commit message (Chris). > > Cc: Greg Kroah-Hartman > Cc: Chris Wilson > Signed-off-by: Daniel Vetter > --- > drivers/gpu/drm/i915/i915_drv.c | 3 --- > 1 file changed, 3 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c > index 48ba37e35bea..4792051e9e2e 100644 > --- a/drivers/gpu/drm/i915/i915_drv.c > +++ b/drivers/gpu/drm/i915/i915_drv.c > @@ -909,9 +909,6 @@ static void i915_driver_destroy(struct drm_i915_private > *i915) > > drm_dev_fini(>drm); > kfree(i915); > - > - /* And make sure we never chase our dangling pointer from pci_dev */ > - pci_set_drvdata(pdev, NULL); > } > > /** -- Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH -next] drm/amdgpu/uvd7: remove unnecessary conversion to bool
On Wed, Mar 25, 2020 at 4:17 AM Chen Zhou wrote:
>
> The conversion to bool is not needed, remove it.
>
> Signed-off-by: Chen Zhou
Applied. Thanks!
Alex
> ---
> drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c
> b/drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c
> index 0995378..20f10a5 100644
> --- a/drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c
> @@ -1694,7 +1694,7 @@ static int uvd_v7_0_set_clockgating_state(void *handle,
> enum amd_clockgating_state state)
> {
> struct amdgpu_device *adev = (struct amdgpu_device *)handle;
> - bool enable = (state == AMD_CG_STATE_GATE) ? true : false;
> + bool enable = (state == AMD_CG_STATE_GATE);
>
> uvd_v7_0_set_bypass_mode(adev, enable);
>
> --
> 2.7.4
>
> ___
> 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] drm/ttm: clean up the inteface which is not used
Am 25.03.20 um 18:27 schrieb Alex Deucher:
On Wed, Mar 25, 2020 at 1:20 PM Christian König
wrote:
Am 25.03.20 um 16:34 schrieb Huang Rui:
invalidate_caches is actually not used, so clean it up.
Signed-off-by: Huang Rui
Already had the same patch around for a while, looks like I've just
forgot to commit it.
Reviewed-by: Christian König
Is it already in drm-misc and just hasn't made it into
amd-staging-drm-next yet? I can try and rebase next week if so.
Ah! Yeah there it is:
commit 5e791166d377c539db0f889e7793204912c374da
Author: Christian König
Date: Fri Jan 10 16:09:54 2020 +0100
drm/ttm: nuke invalidate_caches callback
Another completely unused feature.
Signed-off-by: Christian König
Reviewed-by: Huang Rui
Link: https://patchwork.freedesktop.org/patch/348265/
Looks like we haven't merged that into amd-staging-drm-next yet.
Christian.
Alex
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 6 --
drivers/gpu/drm/nouveau/nouveau_bo.c | 7 ---
drivers/gpu/drm/qxl/qxl_ttm.c | 6 --
drivers/gpu/drm/radeon/radeon_ttm.c| 6 --
drivers/gpu/drm/ttm/ttm_bo.c | 8 +---
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 6 --
include/drm/ttm/ttm_bo_driver.h| 13 -
7 files changed, 1 insertion(+), 51 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index cd2bde6..b397148 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -62,11 +62,6 @@
#define AMDGPU_TTM_VRAM_MAX_DW_READ (size_t)128
-static int amdgpu_invalidate_caches(struct ttm_bo_device *bdev, uint32_t flags)
-{
- return 0;
-}
-
/**
* amdgpu_init_mem_type - Initialize a memory manager for a specific type of
* memory request.
@@ -1746,7 +1741,6 @@ static struct ttm_bo_driver amdgpu_bo_driver = {
.ttm_tt_create = _ttm_tt_create,
.ttm_tt_populate = _ttm_tt_populate,
.ttm_tt_unpopulate = _ttm_tt_unpopulate,
- .invalidate_caches = _invalidate_caches,
.init_mem_type = _init_mem_type,
.eviction_valuable = amdgpu_ttm_bo_eviction_valuable,
.evict_flags = _evict_flags,
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 1b62ccc..7dd94e6 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -647,13 +647,6 @@ nouveau_ttm_tt_create(struct ttm_buffer_object *bo,
uint32_t page_flags)
}
static int
-nouveau_bo_invalidate_caches(struct ttm_bo_device *bdev, uint32_t flags)
-{
- /* We'll do this from user space. */
- return 0;
-}
-
-static int
nouveau_bo_init_mem_type(struct ttm_bo_device *bdev, uint32_t type,
struct ttm_mem_type_manager *man)
{
diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
index 16a5e90..62a5e42 100644
--- a/drivers/gpu/drm/qxl/qxl_ttm.c
+++ b/drivers/gpu/drm/qxl/qxl_ttm.c
@@ -48,11 +48,6 @@ static struct qxl_device *qxl_get_qdev(struct ttm_bo_device
*bdev)
return qdev;
}
-static int qxl_invalidate_caches(struct ttm_bo_device *bdev, uint32_t flags)
-{
- return 0;
-}
-
static int qxl_init_mem_type(struct ttm_bo_device *bdev, uint32_t type,
struct ttm_mem_type_manager *man)
{
@@ -256,7 +251,6 @@ static void qxl_bo_move_notify(struct ttm_buffer_object *bo,
static struct ttm_bo_driver qxl_bo_driver = {
.ttm_tt_create = _ttm_tt_create,
- .invalidate_caches = _invalidate_caches,
.init_mem_type = _init_mem_type,
.eviction_valuable = ttm_bo_eviction_valuable,
.evict_flags = _evict_flags,
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index f4af6703..40282bf 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -66,11 +66,6 @@ static struct radeon_device *radeon_get_rdev(struct
ttm_bo_device *bdev)
return rdev;
}
-static int radeon_invalidate_caches(struct ttm_bo_device *bdev, uint32_t flags)
-{
- return 0;
-}
-
static int radeon_init_mem_type(struct ttm_bo_device *bdev, uint32_t type,
struct ttm_mem_type_manager *man)
{
@@ -774,7 +769,6 @@ static struct ttm_bo_driver radeon_bo_driver = {
.ttm_tt_create = _ttm_tt_create,
.ttm_tt_populate = _ttm_tt_populate,
.ttm_tt_unpopulate = _ttm_tt_unpopulate,
- .invalidate_caches = _invalidate_caches,
.init_mem_type = _init_mem_type,
.eviction_valuable = ttm_bo_eviction_valuable,
.evict_flags = _evict_flags,
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 2445e2b..fd09bbb 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -343,14 +343,8 @@ static int ttm_bo_handle_move_mem(struct ttm_buffer_object
*bo,
}
moved:
-
Re: [PATCH] drm/ttm: clean up the inteface which is not used
On Wed, Mar 25, 2020 at 1:20 PM Christian König
wrote:
>
> Am 25.03.20 um 16:34 schrieb Huang Rui:
> > invalidate_caches is actually not used, so clean it up.
> >
> > Signed-off-by: Huang Rui
>
> Already had the same patch around for a while, looks like I've just
> forgot to commit it.
>
> Reviewed-by: Christian König
>
Is it already in drm-misc and just hasn't made it into
amd-staging-drm-next yet? I can try and rebase next week if so.
Alex
> > ---
> > drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 6 --
> > drivers/gpu/drm/nouveau/nouveau_bo.c | 7 ---
> > drivers/gpu/drm/qxl/qxl_ttm.c | 6 --
> > drivers/gpu/drm/radeon/radeon_ttm.c| 6 --
> > drivers/gpu/drm/ttm/ttm_bo.c | 8 +---
> > drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 6 --
> > include/drm/ttm/ttm_bo_driver.h| 13 -
> > 7 files changed, 1 insertion(+), 51 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> > index cd2bde6..b397148 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> > @@ -62,11 +62,6 @@
> >
> > #define AMDGPU_TTM_VRAM_MAX_DW_READ (size_t)128
> >
> > -static int amdgpu_invalidate_caches(struct ttm_bo_device *bdev, uint32_t
> > flags)
> > -{
> > - return 0;
> > -}
> > -
> > /**
> >* amdgpu_init_mem_type - Initialize a memory manager for a specific type
> > of
> >* memory request.
> > @@ -1746,7 +1741,6 @@ static struct ttm_bo_driver amdgpu_bo_driver = {
> > .ttm_tt_create = _ttm_tt_create,
> > .ttm_tt_populate = _ttm_tt_populate,
> > .ttm_tt_unpopulate = _ttm_tt_unpopulate,
> > - .invalidate_caches = _invalidate_caches,
> > .init_mem_type = _init_mem_type,
> > .eviction_valuable = amdgpu_ttm_bo_eviction_valuable,
> > .evict_flags = _evict_flags,
> > diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
> > b/drivers/gpu/drm/nouveau/nouveau_bo.c
> > index 1b62ccc..7dd94e6 100644
> > --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> > +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> > @@ -647,13 +647,6 @@ nouveau_ttm_tt_create(struct ttm_buffer_object *bo,
> > uint32_t page_flags)
> > }
> >
> > static int
> > -nouveau_bo_invalidate_caches(struct ttm_bo_device *bdev, uint32_t flags)
> > -{
> > - /* We'll do this from user space. */
> > - return 0;
> > -}
> > -
> > -static int
> > nouveau_bo_init_mem_type(struct ttm_bo_device *bdev, uint32_t type,
> >struct ttm_mem_type_manager *man)
> > {
> > diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
> > index 16a5e90..62a5e42 100644
> > --- a/drivers/gpu/drm/qxl/qxl_ttm.c
> > +++ b/drivers/gpu/drm/qxl/qxl_ttm.c
> > @@ -48,11 +48,6 @@ static struct qxl_device *qxl_get_qdev(struct
> > ttm_bo_device *bdev)
> > return qdev;
> > }
> >
> > -static int qxl_invalidate_caches(struct ttm_bo_device *bdev, uint32_t
> > flags)
> > -{
> > - return 0;
> > -}
> > -
> > static int qxl_init_mem_type(struct ttm_bo_device *bdev, uint32_t type,
> >struct ttm_mem_type_manager *man)
> > {
> > @@ -256,7 +251,6 @@ static void qxl_bo_move_notify(struct ttm_buffer_object
> > *bo,
> >
> > static struct ttm_bo_driver qxl_bo_driver = {
> > .ttm_tt_create = _ttm_tt_create,
> > - .invalidate_caches = _invalidate_caches,
> > .init_mem_type = _init_mem_type,
> > .eviction_valuable = ttm_bo_eviction_valuable,
> > .evict_flags = _evict_flags,
> > diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
> > b/drivers/gpu/drm/radeon/radeon_ttm.c
> > index f4af6703..40282bf 100644
> > --- a/drivers/gpu/drm/radeon/radeon_ttm.c
> > +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
> > @@ -66,11 +66,6 @@ static struct radeon_device *radeon_get_rdev(struct
> > ttm_bo_device *bdev)
> > return rdev;
> > }
> >
> > -static int radeon_invalidate_caches(struct ttm_bo_device *bdev, uint32_t
> > flags)
> > -{
> > - return 0;
> > -}
> > -
> > static int radeon_init_mem_type(struct ttm_bo_device *bdev, uint32_t type,
> > struct ttm_mem_type_manager *man)
> > {
> > @@ -774,7 +769,6 @@ static struct ttm_bo_driver radeon_bo_driver = {
> > .ttm_tt_create = _ttm_tt_create,
> > .ttm_tt_populate = _ttm_tt_populate,
> > .ttm_tt_unpopulate = _ttm_tt_unpopulate,
> > - .invalidate_caches = _invalidate_caches,
> > .init_mem_type = _init_mem_type,
> > .eviction_valuable = ttm_bo_eviction_valuable,
> > .evict_flags = _evict_flags,
> > diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> > index 2445e2b..fd09bbb 100644
> > --- a/drivers/gpu/drm/ttm/ttm_bo.c
> > +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> > @@ -343,14 +343,8 @@ static int ttm_bo_handle_move_mem(struct
> > ttm_buffer_object *bo,
> > }
> >
> > moved:
> > - if (bo->evicted)
Re: [PATCH] drm/ttm: clean up the inteface which is not used
Am 25.03.20 um 16:34 schrieb Huang Rui:
invalidate_caches is actually not used, so clean it up.
Signed-off-by: Huang Rui
Already had the same patch around for a while, looks like I've just
forgot to commit it.
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 6 --
drivers/gpu/drm/nouveau/nouveau_bo.c | 7 ---
drivers/gpu/drm/qxl/qxl_ttm.c | 6 --
drivers/gpu/drm/radeon/radeon_ttm.c| 6 --
drivers/gpu/drm/ttm/ttm_bo.c | 8 +---
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 6 --
include/drm/ttm/ttm_bo_driver.h| 13 -
7 files changed, 1 insertion(+), 51 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index cd2bde6..b397148 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -62,11 +62,6 @@
#define AMDGPU_TTM_VRAM_MAX_DW_READ (size_t)128
-static int amdgpu_invalidate_caches(struct ttm_bo_device *bdev, uint32_t flags)
-{
- return 0;
-}
-
/**
* amdgpu_init_mem_type - Initialize a memory manager for a specific type of
* memory request.
@@ -1746,7 +1741,6 @@ static struct ttm_bo_driver amdgpu_bo_driver = {
.ttm_tt_create = _ttm_tt_create,
.ttm_tt_populate = _ttm_tt_populate,
.ttm_tt_unpopulate = _ttm_tt_unpopulate,
- .invalidate_caches = _invalidate_caches,
.init_mem_type = _init_mem_type,
.eviction_valuable = amdgpu_ttm_bo_eviction_valuable,
.evict_flags = _evict_flags,
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 1b62ccc..7dd94e6 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -647,13 +647,6 @@ nouveau_ttm_tt_create(struct ttm_buffer_object *bo,
uint32_t page_flags)
}
static int
-nouveau_bo_invalidate_caches(struct ttm_bo_device *bdev, uint32_t flags)
-{
- /* We'll do this from user space. */
- return 0;
-}
-
-static int
nouveau_bo_init_mem_type(struct ttm_bo_device *bdev, uint32_t type,
struct ttm_mem_type_manager *man)
{
diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
index 16a5e90..62a5e42 100644
--- a/drivers/gpu/drm/qxl/qxl_ttm.c
+++ b/drivers/gpu/drm/qxl/qxl_ttm.c
@@ -48,11 +48,6 @@ static struct qxl_device *qxl_get_qdev(struct ttm_bo_device
*bdev)
return qdev;
}
-static int qxl_invalidate_caches(struct ttm_bo_device *bdev, uint32_t flags)
-{
- return 0;
-}
-
static int qxl_init_mem_type(struct ttm_bo_device *bdev, uint32_t type,
struct ttm_mem_type_manager *man)
{
@@ -256,7 +251,6 @@ static void qxl_bo_move_notify(struct ttm_buffer_object *bo,
static struct ttm_bo_driver qxl_bo_driver = {
.ttm_tt_create = _ttm_tt_create,
- .invalidate_caches = _invalidate_caches,
.init_mem_type = _init_mem_type,
.eviction_valuable = ttm_bo_eviction_valuable,
.evict_flags = _evict_flags,
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index f4af6703..40282bf 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -66,11 +66,6 @@ static struct radeon_device *radeon_get_rdev(struct
ttm_bo_device *bdev)
return rdev;
}
-static int radeon_invalidate_caches(struct ttm_bo_device *bdev, uint32_t flags)
-{
- return 0;
-}
-
static int radeon_init_mem_type(struct ttm_bo_device *bdev, uint32_t type,
struct ttm_mem_type_manager *man)
{
@@ -774,7 +769,6 @@ static struct ttm_bo_driver radeon_bo_driver = {
.ttm_tt_create = _ttm_tt_create,
.ttm_tt_populate = _ttm_tt_populate,
.ttm_tt_unpopulate = _ttm_tt_unpopulate,
- .invalidate_caches = _invalidate_caches,
.init_mem_type = _init_mem_type,
.eviction_valuable = ttm_bo_eviction_valuable,
.evict_flags = _evict_flags,
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 2445e2b..fd09bbb 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -343,14 +343,8 @@ static int ttm_bo_handle_move_mem(struct ttm_buffer_object
*bo,
}
moved:
- if (bo->evicted) {
- if (bdev->driver->invalidate_caches) {
- ret = bdev->driver->invalidate_caches(bdev,
bo->mem.placement);
- if (ret)
- pr_err("Can not flush read caches\n");
- }
+ if (bo->evicted)
bo->evicted = false;
- }
if (bo->mem.mm_node)
bo->offset = (bo->mem.start << PAGE_SHIFT) +
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
index d8ea3dd..3f3b2c7 100644
---
Re: [PATCH v4 7/8] drm/fourcc: amlogic: Add modifier definitions for the Scatter layout
Hi, On 25/03/2020 14:49, Pekka Paalanen wrote: > On Wed, 25 Mar 2020 11:24:15 +0100 > Neil Armstrong wrote: > >> Hi, >> >> On 25/03/2020 10:04, Simon Ser wrote: >>> On Wednesday, March 25, 2020 9:50 AM, Neil Armstrong >>> wrote: >>> Amlogic uses a proprietary lossless image compression protocol and format for their hardware video codec accelerators, either video decoders or video input encoders. This introduces the Scatter Memory layout, means the header contains IOMMU references to the compressed frames content to optimize memory access and layout. In this mode, only the header memory address is needed, thus the content memory organization is tied to the current producer execution and cannot be saved/dumped neither transferrable between Amlogic SoCs supporting this modifier. >>> >>> I don't think this is suitable for modifiers. User-space relies on >>> being able to copy a buffer from one machine to another over the >>> network. It would be pretty annoying for user-space to have a blacklist >>> of modifiers that don't work this way. >>> >>> Example of such user-space: >>> https://gitlab.freedesktop.org/mstoeckl/waypipe/ >>> >> >> I really understand your point, but this is one of the use-cases we need >> solve. >> This is why I split the fourcc patch and added an explicit comment. >> >> Please point me a way to display such buffer, the HW exists, works like that >> and >> it's a fact and can't change. >> >> It will be the same for secure zero-copy buffers we can't map from >> userspace, but >> only the HW decoder can read/write and HW display can read. > > The comparison to secure buffers is a good one. > > Are buffers with the DRM_FORMAT_MOD_AMLOGIC_FBC_LAYOUT_SCATTER modifier > meaningfully mmappable to CPU always / sometimes / never / > varies-and-cannot-know? mmappable, yes in our WIP V4L2 driver in non-secure path, meaningful, absolutely never. So yeah, these should not be mmappable since not meaningful. > > Maybe this type should be handled similar to secure buffers, with the > exception that they are not actually secured but only mostly > inaccessible. Then again, I haven't looked at any of the secure buffer > proposals. Actually, the Amlogic platforms offers secure video path using these exact modifiers, AFAIK it doesn't support the NV12 dual-write output in secure. AFAIK last submission is from AMD, and it doesn't talk at all about mmapability of the secure BOs. Neil > > > Thanks, > pq > 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 v4 3/3] drm/radeon: fix scatter-gather mapping with user pages
On Wed, Mar 25, 2020 at 11:54 AM Shane Francis wrote: > > > >-Original Message- > > >From: dri-devel On Behalf Of > > >Shane Francis > > >Sent: Wednesday, March 25, 2020 5:08 AM > > >To: dri-devel@lists.freedesktop.org > > >Cc: airl...@linux.ie; linux-ker...@vger.kernel.org; bigbeesh...@gmail.com; > > >amd-gfx-requ...@lists.freedesktop.org; alexander.deuc...@amd.com; > > >christian.koe...@amd.com > > >Subject: [PATCH v4 3/3] drm/radeon: fix scatter-gather mapping with user > > >pages > > > > > >Calls to dma_map_sg may return segments / entries than requested > > > > "may return less segment..." ? > >^^^ > > I will reword / fix the highlighted issues with the text and send a updated > patch set later today. I'll fix it up locally when I apply it. Thanks! Alex > > > > > >if they fall on page bounderies. The old implementation did not > > >support this use case. > > > > > >Signed-off-by: Shane Francis > > >--- > > > drivers/gpu/drm/radeon/radeon_ttm.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > >diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c > > >b/drivers/gpu/drm/radeon/radeon_ttm.c > > >index 3b92311d30b9..b3380ffab4c2 100644 > > >--- a/drivers/gpu/drm/radeon/radeon_ttm.c > > >+++ b/drivers/gpu/drm/radeon/radeon_ttm.c > > >@@ -528,7 +528,7 @@ static int radeon_ttm_tt_pin_userptr(struct ttm_tt > > >*ttm) > > > > > > r = -ENOMEM; > > > nents = dma_map_sg(rdev->dev, ttm->sg->sgl, ttm->sg->nents, > > >direction); > > >- if (nents != ttm->sg->nents) > > >+ if (nents == 0) > > > goto release_sg; > > > > This looks correct to me. > > > > Reviewed-by: Michael J. Ruhl > > > > M > > > drm_prime_sg_to_page_addr_arrays(ttm->sg, ttm->pages, > > >-- > > >2.26.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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 3/3] drm/radeon: fix scatter-gather mapping with user pages
> >-Original Message- > >From: dri-devel On Behalf Of > >Shane Francis > >Sent: Wednesday, March 25, 2020 5:08 AM > >To: dri-devel@lists.freedesktop.org > >Cc: airl...@linux.ie; linux-ker...@vger.kernel.org; bigbeesh...@gmail.com; > >amd-gfx-requ...@lists.freedesktop.org; alexander.deuc...@amd.com; > >christian.koe...@amd.com > >Subject: [PATCH v4 3/3] drm/radeon: fix scatter-gather mapping with user > >pages > > > >Calls to dma_map_sg may return segments / entries than requested > > "may return less segment..." ? >^^^ I will reword / fix the highlighted issues with the text and send a updated patch set later today. > > >if they fall on page bounderies. The old implementation did not > >support this use case. > > > >Signed-off-by: Shane Francis > >--- > > drivers/gpu/drm/radeon/radeon_ttm.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > >diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c > >b/drivers/gpu/drm/radeon/radeon_ttm.c > >index 3b92311d30b9..b3380ffab4c2 100644 > >--- a/drivers/gpu/drm/radeon/radeon_ttm.c > >+++ b/drivers/gpu/drm/radeon/radeon_ttm.c > >@@ -528,7 +528,7 @@ static int radeon_ttm_tt_pin_userptr(struct ttm_tt > >*ttm) > > > > r = -ENOMEM; > > nents = dma_map_sg(rdev->dev, ttm->sg->sgl, ttm->sg->nents, > >direction); > >- if (nents != ttm->sg->nents) > >+ if (nents == 0) > > goto release_sg; > > This looks correct to me. > > Reviewed-by: Michael J. Ruhl > > M > > drm_prime_sg_to_page_addr_arrays(ttm->sg, ttm->pages, > >-- > >2.26.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 1/4] drm/radeon: remove unneeded header include path
On Tue, Mar 24, 2020 at 9:14 PM Masahiro Yamada wrote: > > On Wed, Mar 25, 2020 at 4:42 AM Alex Deucher wrote: > > > > On Tue, Mar 24, 2020 at 12:48 PM Masahiro Yamada > > wrote: > > > > > > Hi, > > > > > > I think this series is a good clean-up. > > > > > > Could you take a look at this please? > > > > Can you resend? I don't seem to have gotten it. Must have ended up > > getting flagged a spam or something. > > > Can you take it from patchwork ? (4 patches) > > https://lore.kernel.org/patchwork/project/lkml/list/?series=429491 Applied. thanks! Alex > > > Thanks. > > > > > > > > Alex > > > > > > > > > > > > > > On Fri, Feb 14, 2020 at 12:40 AM Masahiro Yamada > > > wrote: > > > > > > > > A header include path without $(srctree)/ is suspicious because it does > > > > not work with O= builds. > > > > > > > > You can build drivers/gpu/drm/radeon/ without this include path. > > > > > > > > Signed-off-by: Masahiro Yamada > > > > --- > > > > > > > > drivers/gpu/drm/radeon/Makefile | 2 -- > > > > 1 file changed, 2 deletions(-) > > > > > > > > diff --git a/drivers/gpu/drm/radeon/Makefile > > > > b/drivers/gpu/drm/radeon/Makefile > > > > index c693b2ca0329..9d5d3dc1011f 100644 > > > > --- a/drivers/gpu/drm/radeon/Makefile > > > > +++ b/drivers/gpu/drm/radeon/Makefile > > > > @@ -3,8 +3,6 @@ > > > > # Makefile for the drm device driver. This driver provides support > > > > for the > > > > # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher. > > > > > > > > -ccflags-y := -Idrivers/gpu/drm/amd/include > > > > - > > > > hostprogs := mkregtable > > > > clean-files := rn50_reg_safe.h r100_reg_safe.h r200_reg_safe.h > > > > rv515_reg_safe.h r300_reg_safe.h r420_reg_safe.h rs600_reg_safe.h > > > > r600_reg_safe.h evergreen_reg_safe.h cayman_reg_safe.h > > > > > > > > -- > > > > 2.17.1 > > > > > > > > > > > > > -- > > > Best Regards > > > Masahiro Yamada > > > ___ > > > dri-devel mailing list > > > dri-devel@lists.freedesktop.org > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > > -- > Best Regards > Masahiro Yamada > ___ > 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: [PATCH] drm/msm/dpu: ensure device suspend happens during PM sleep
Hi,
On Wed, Mar 25, 2020 at 8:40 AM Rob Clark wrote:
>
> On Tue, Mar 24, 2020 at 7:35 AM Doug Anderson wrote:
> >
> > Hi,
> >
> > On Sun, Mar 22, 2020 at 11:14 PM Kalyan Thota
> > wrote:
> > >
> > > "The PM core always increments the runtime usage counter
> > > before calling the ->suspend() callback and decrements it
> > > after calling the ->resume() callback"
> > >
> > > DPU and DSI are managed as runtime devices. When
> > > suspend is triggered, PM core adds a refcount on all the
> > > devices and calls device suspend, since usage count is
> > > already incremented, runtime suspend was not getting called
> > > and it kept the clocks on which resulted in target not
> > > entering into XO shutdown.
> > >
> > > Add changes to manage runtime devices during pm sleep.
> > >
> > > Changes in v1:
> > > - Remove unnecessary checks in the function
> > > _dpu_kms_disable_dpu (Rob Clark).
> >
> > I'm wondering what happened with my feedback on v1, AKA:
> >
> > https://lore.kernel.org/r/CAD=FV=VxzEV40g+ieuEN+7o=34+wm8mho8o7t5za1yosx7s...@mail.gmail.com
> >
> > Maybe you didn't see it? ...or if you or Rob think I'm way off base
> > (always possible) then please tell me so.
> >
>
> At least w/ the current patch, disable_dpu should not be called for
> screen-off (although I'd hope if all the screens are off the device
> would suspend).
OK, that's good.
> But I won't claim to be a pm expert.. so not really
> sure if this is the best approach or not. I don't think our
> arrangement of sub-devices under a parent is completely abnormal, so
> it does feel like there should be a simpler solution..
I think the other arguments about asymmetry are still valid and I've
fixed bugs around this type of thing in the past. For instance, see
commit f7ccbed656f7 ("drm/rockchip: Suspend DP late").
-Doug
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm/dpu: ensure device suspend happens during PM sleep
On Tue, Mar 24, 2020 at 7:35 AM Doug Anderson wrote: > > Hi, > > On Sun, Mar 22, 2020 at 11:14 PM Kalyan Thota wrote: > > > > "The PM core always increments the runtime usage counter > > before calling the ->suspend() callback and decrements it > > after calling the ->resume() callback" > > > > DPU and DSI are managed as runtime devices. When > > suspend is triggered, PM core adds a refcount on all the > > devices and calls device suspend, since usage count is > > already incremented, runtime suspend was not getting called > > and it kept the clocks on which resulted in target not > > entering into XO shutdown. > > > > Add changes to manage runtime devices during pm sleep. > > > > Changes in v1: > > - Remove unnecessary checks in the function > > _dpu_kms_disable_dpu (Rob Clark). > > I'm wondering what happened with my feedback on v1, AKA: > > https://lore.kernel.org/r/CAD=FV=VxzEV40g+ieuEN+7o=34+wm8mho8o7t5za1yosx7s...@mail.gmail.com > > Maybe you didn't see it? ...or if you or Rob think I'm way off base > (always possible) then please tell me so. > At least w/ the current patch, disable_dpu should not be called for screen-off (although I'd hope if all the screens are off the device would suspend). But I won't claim to be a pm expert.. so not really sure if this is the best approach or not. I don't think our arrangement of sub-devices under a parent is completely abnormal, so it does feel like there should be a simpler solution.. BR, -R ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V4 3/4] backlight: qcom-wled: Add WLED5 bindings
On Mon, Mar 23, 2020 at 11:16:57PM +0530, Kiran Gunda wrote: > Add WLED5 specific bindings. > > Signed-off-by: Kiran Gunda > Signed-off-by: Subbaraman Narayanamurthy > --- > .../bindings/leds/backlight/qcom-wled.yaml | 39 > ++ > 1 file changed, 39 insertions(+) > > diff --git a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml > b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml > index 8a388bf..159115f 100644 > --- a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml > +++ b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml > @@ -20,6 +20,7 @@ properties: > - qcom,pm8941-wled > - qcom,pmi8998-wled > - qcom,pm660l-wled > + - qcom,pm8150l-wled > >reg: > maxItems: 1 > @@ -28,10 +29,23 @@ properties: > maxItems: 1 > description: >brightness value on boot, value from 0-4095. > + For pm8150l this value vary from 0-4095 or 0-32767 > + depending on the brightness control mode. If CABC is > + enabled 0-4095 range is used. I rather dislike some of the property descriptions using PMIC version numbers to distinguish between peripheral versions and others using WLEDx version numbers. Could the property description be rephrased to use WLED3/4/5 terminology instead? > allOf: >- $ref: /schemas/types.yaml#/definitions/uint32 > default: 2048 > > + max-brightness: > +maxItems: 1 > +description: > + Maximum brightness level. Allowed values are, > + for pmi8998 it is 0-4095. > + For pm8150l, this can be either 4095 or 32767. > + If CABC is enabled, this is capped to 4095. > +allOf: > + - $ref: /schemas/types.yaml#/definitions/uint32 > + Similar thing here, is PMI8998 simply a synonym for WLED4 or there something special about the PMIC versioning that requires it to be used? Daniel. >label: > maxItems: 1 > description: > @@ -124,6 +138,31 @@ properties: >value for PM8941 from 1 to 3. Default 2 >For PMI8998 from 1 to 4. > > + qcom,modulator-sel: > +maxItems: 1 > +allOf: > + - $ref: /schemas/types.yaml#/definitions/uint32 > +description: > + Selects the modulator used for brightness modulation. > + Allowed values are, > + 0 - Modulator A > + 1 - Modulator B > + If not specified, then modulator A will be used by default. > + This property is applicable only to WLED5 peripheral. > + > + qcom,cabc-sel: > +maxItems: 1 > +allOf: > + - $ref: /schemas/types.yaml#/definitions/uint32 > +description: > + Selects the CABC pin signal used for brightness modulation. > + Allowed values are, > + 0 - CABC disabled > + 1 - CABC 1 > + 2 - CABC 2 > + 3 - External signal (e.g. LPG) is used for dimming > + This property is applicable only to WLED5 peripheral. > + >interrupts: > maxItems: 2 > description: > -- > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, > a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v12 3/5] clk / soc: mediatek: Move mt8173 MMSYS to platform driver
Stephen Boyd 於 2020年3月21日 週六 上午7:14寫道： > > Quoting Enric Balletbo i Serra (2020-03-11 09:53:20) > > From: Matthias Brugger > > > > There is no strong reason for this to use CLK_OF_DECLARE instead of > > being a platform driver. Plus, MMSYS provides clocks but also a shared > > register space for the mediatek-drm and the mediatek-mdp > > driver. So move the MMSYS clocks to a new platform driver and also > > create a new MMSYS platform driver in drivers/soc/mediatek that > > instantiates the clock driver. > > > > Signed-off-by: Matthias Brugger > > Signed-off-by: Enric Balletbo i Serra > > Reviewed-by: CK Hu > > --- > > Reviewed-by: Stephen Boyd > > Unless you want me to pick this up by itself? I would like Matthias to pick up this series together. > ___ > 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
[PATCH] drm/ttm: clean up the inteface which is not used
invalidate_caches is actually not used, so clean it up.
Signed-off-by: Huang Rui
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 6 --
drivers/gpu/drm/nouveau/nouveau_bo.c | 7 ---
drivers/gpu/drm/qxl/qxl_ttm.c | 6 --
drivers/gpu/drm/radeon/radeon_ttm.c| 6 --
drivers/gpu/drm/ttm/ttm_bo.c | 8 +---
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 6 --
include/drm/ttm/ttm_bo_driver.h| 13 -
7 files changed, 1 insertion(+), 51 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index cd2bde6..b397148 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -62,11 +62,6 @@
#define AMDGPU_TTM_VRAM_MAX_DW_READ(size_t)128
-static int amdgpu_invalidate_caches(struct ttm_bo_device *bdev, uint32_t flags)
-{
- return 0;
-}
-
/**
* amdgpu_init_mem_type - Initialize a memory manager for a specific type of
* memory request.
@@ -1746,7 +1741,6 @@ static struct ttm_bo_driver amdgpu_bo_driver = {
.ttm_tt_create = _ttm_tt_create,
.ttm_tt_populate = _ttm_tt_populate,
.ttm_tt_unpopulate = _ttm_tt_unpopulate,
- .invalidate_caches = _invalidate_caches,
.init_mem_type = _init_mem_type,
.eviction_valuable = amdgpu_ttm_bo_eviction_valuable,
.evict_flags = _evict_flags,
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 1b62ccc..7dd94e6 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -647,13 +647,6 @@ nouveau_ttm_tt_create(struct ttm_buffer_object *bo,
uint32_t page_flags)
}
static int
-nouveau_bo_invalidate_caches(struct ttm_bo_device *bdev, uint32_t flags)
-{
- /* We'll do this from user space. */
- return 0;
-}
-
-static int
nouveau_bo_init_mem_type(struct ttm_bo_device *bdev, uint32_t type,
struct ttm_mem_type_manager *man)
{
diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
index 16a5e90..62a5e42 100644
--- a/drivers/gpu/drm/qxl/qxl_ttm.c
+++ b/drivers/gpu/drm/qxl/qxl_ttm.c
@@ -48,11 +48,6 @@ static struct qxl_device *qxl_get_qdev(struct ttm_bo_device
*bdev)
return qdev;
}
-static int qxl_invalidate_caches(struct ttm_bo_device *bdev, uint32_t flags)
-{
- return 0;
-}
-
static int qxl_init_mem_type(struct ttm_bo_device *bdev, uint32_t type,
struct ttm_mem_type_manager *man)
{
@@ -256,7 +251,6 @@ static void qxl_bo_move_notify(struct ttm_buffer_object *bo,
static struct ttm_bo_driver qxl_bo_driver = {
.ttm_tt_create = _ttm_tt_create,
- .invalidate_caches = _invalidate_caches,
.init_mem_type = _init_mem_type,
.eviction_valuable = ttm_bo_eviction_valuable,
.evict_flags = _evict_flags,
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index f4af6703..40282bf 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -66,11 +66,6 @@ static struct radeon_device *radeon_get_rdev(struct
ttm_bo_device *bdev)
return rdev;
}
-static int radeon_invalidate_caches(struct ttm_bo_device *bdev, uint32_t flags)
-{
- return 0;
-}
-
static int radeon_init_mem_type(struct ttm_bo_device *bdev, uint32_t type,
struct ttm_mem_type_manager *man)
{
@@ -774,7 +769,6 @@ static struct ttm_bo_driver radeon_bo_driver = {
.ttm_tt_create = _ttm_tt_create,
.ttm_tt_populate = _ttm_tt_populate,
.ttm_tt_unpopulate = _ttm_tt_unpopulate,
- .invalidate_caches = _invalidate_caches,
.init_mem_type = _init_mem_type,
.eviction_valuable = ttm_bo_eviction_valuable,
.evict_flags = _evict_flags,
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 2445e2b..fd09bbb 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -343,14 +343,8 @@ static int ttm_bo_handle_move_mem(struct ttm_buffer_object
*bo,
}
moved:
- if (bo->evicted) {
- if (bdev->driver->invalidate_caches) {
- ret = bdev->driver->invalidate_caches(bdev,
bo->mem.placement);
- if (ret)
- pr_err("Can not flush read caches\n");
- }
+ if (bo->evicted)
bo->evicted = false;
- }
if (bo->mem.mm_node)
bo->offset = (bo->mem.start << PAGE_SHIFT) +
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
index d8ea3dd..3f3b2c7 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
@@ -736,11 +736,6 @@ static struct ttm_tt *vmw_ttm_tt_create(struct
ttm_buffer_object *bo,
return NULL;
}
-static int
Re: [PATCH V4 2/4] backlight: qcom-wled: Add callback functions
On Mon, Mar 23, 2020 at 11:16:56PM +0530, Kiran Gunda wrote:
> Add wled_cabc_config, wled_sync_toggle, wled_ovp_fault_status
> and wled_ovp_delay callback functions to prepare the driver for
> adding WLED5 support.
>
> wled_cabc_config() ===> Used to configure the cabc register.
> It is applicable for wled4 and wled5.
>
> wled_sync_toggle() ===> used to toggle the Sync register bit for the
> brightness update to take place.
> It is applicable for WLED3, WLED4 and WLED5.
>
> wled_ovp_fault_status() ===> Used to determine if the OVP fault is triggered.
> It is applicable for WLED4 and WLED5.
>
> wled_ovp_delay() ===> Provides the time to wait before checking the OVP status
> after wled module enable.
> It is applicable for WLED4 and WLED5.
These look like comments to me. Move them out of the patch header and
make them into real comments!
> Signed-off-by: Kiran Gunda
This patch does not compile. Please fix this.
> ---
> drivers/video/backlight/qcom-wled.c | 188
> ++--
> 1 file changed, 118 insertions(+), 70 deletions(-)
>
> diff --git a/drivers/video/backlight/qcom-wled.c
> b/drivers/video/backlight/qcom-wled.c
> index 3d276b3..a3daf9e 100644
> --- a/drivers/video/backlight/qcom-wled.c
> +++ b/drivers/video/backlight/qcom-wled.c
> @@ -147,6 +147,7 @@ struct wled {
> u32 max_brightness;
> u32 short_count;
> u32 auto_detect_count;
> + u32 version;
Why does some of the changes here use function pointers and other parts
use if/else networks (wled->version == X) ?
Overall I almost wonder if the reduced clarify that comes from function
pointers is actually adding much value?
> bool disabled_by_short;
> bool has_short_detect;
> int short_irq;
> @@ -155,6 +156,10 @@ struct wled {
> struct wled_config cfg;
> struct delayed_work ovp_work;
> int (*wled_set_brightness)(struct wled *wled, u16 brightness);
> + int (*wled_cabc_config)(struct wled *wled, bool enable);
> + int (*wled_sync_toggle)(struct wled *wled);
> + int (*wled_ovp_fault_status)(struct wled *wled, bool *fault_set);
> + int (*wled_ovp_delay)(struct wled *wled);
> };
>
> static int wled3_set_brightness(struct wled *wled, u16 brightness)
> @@ -237,7 +242,7 @@ static int wled_module_enable(struct wled *wled, int val)
> return 0;
> }
>
> -static int wled_sync_toggle(struct wled *wled)
> +static int wled3_sync_toggle(struct wled *wled)
> {
> int rc;
> unsigned int mask = GENMASK(wled->max_string_count - 1, 0);
> @@ -255,6 +260,46 @@ static int wled_sync_toggle(struct wled *wled)
> return rc;
> }
>
> +static int wled4_ovp_fault_status(struct wled *wled, bool *fault_set)
> +{
> + int rc;
> + u32 int_rt_sts, fault_sts;
> +
> + *fault_set = false;
> + rc = regmap_read(wled->regmap,
> + wled->ctrl_addr + WLED3_CTRL_REG_INT_RT_STS,
> + _rt_sts);
> + if (rc < 0) {
> + dev_err(wled->dev, "Failed to read INT_RT_STS rc=%d\n", rc);
> + return rc;
> + }
> +
> + rc = regmap_read(wled->regmap,
> + wled->ctrl_addr + WLED3_CTRL_REG_FAULT_STATUS,
> + _sts);
> + if (rc < 0) {
> + dev_err(wled->dev, "Failed to read FAULT_STATUS rc=%d\n", rc);
> + return rc;
> + }
> +
> + if (int_rt_sts & WLED3_CTRL_REG_OVP_FAULT_STATUS)
> + *fault_set = true;
> +
> + if (fault_sts & WLED3_CTRL_REG_OVP_FAULT_BIT)
> + *fault_set = true;
> +
> + if (*fault_set)
> + dev_dbg(wled->dev, "WLED OVP fault detected, int_rt_sts=0x%x
> fault_sts=0x%x\n",
> + int_rt_sts, fault_sts);
> +
> + return rc;
> +}
> +
> +static int wled4_ovp_delay(struct wled *wled)
> +{
> + return WLED_SOFT_START_DLY_US;
> +}
> +
> static int wled_update_status(struct backlight_device *bl)
> {
> struct wled *wled = bl_get_data(bl);
> @@ -275,7 +320,7 @@ static int wled_update_status(struct backlight_device *bl)
> goto unlock_mutex;
> }
>
> - rc = wled_sync_toggle(wled);
> + rc = wled->wled_sync_toggle(wled);
> if (rc < 0) {
> dev_err(wled->dev, "wled sync failed rc:%d\n", rc);
> goto unlock_mutex;
> @@ -298,6 +343,25 @@ static int wled_update_status(struct backlight_device
> *bl)
> return rc;
> }
>
> +static int wled4_cabc_config(struct wled *wled, bool enable)
> +{
> + int i, j, rc;
> + u8 val;
> +
> + for (i = 0; i < wled->cfg.num_strings; i++) {
> + j = wled->cfg.enabled_strings[i];
> +
> + val = enable ? WLED4_SINK_REG_STR_CABC_MASK : 0;
> + rc = regmap_update_bits(wled->regmap, wled->sink_addr +
> +
[PATCH] drm/vboxvideo: Add missing remove_conflicting_pci_framebuffers call
The vboxvideo driver is missing a call to remove conflicting framebuffers.
Surprisingly, when using legacy BIOS booting this does not really cause
any issues. But when using UEFI to boot the VM then plymouth will draw
on both the efifb /dev/fb0 and /dev/drm/card0 (which has registered
/dev/fb1 as fbdev emulation).
VirtualBox will actual display the output of both devices (I guess it is
showing whatever was drawn last), this causes weird artifacts because of
pitch issues in the efifb when the VM window is not sized at 1024x768
(the window will resize to its last size once the vboxvideo driver loads,
changing the pitch).
Adding the missing drm_fb_helper_remove_conflicting_pci_framebuffers()
call fixes this.
Cc: sta...@vger.kernel.org
Fixes: 2695eae1f6d3 ("drm/vboxvideo: Switch to generic fbdev emulation")
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/vboxvideo/vbox_drv.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/vboxvideo/vbox_drv.c
b/drivers/gpu/drm/vboxvideo/vbox_drv.c
index 8512d970a09f..261255085918 100644
--- a/drivers/gpu/drm/vboxvideo/vbox_drv.c
+++ b/drivers/gpu/drm/vboxvideo/vbox_drv.c
@@ -76,6 +76,10 @@ static int vbox_pci_probe(struct pci_dev *pdev, const struct
pci_device_id *ent)
if (ret)
goto err_mode_fini;
+ ret = drm_fb_helper_remove_conflicting_pci_framebuffers(pdev,
"vboxvideodrmfb");
+ if (ret)
+ goto err_irq_fini;
+
ret = drm_fbdev_generic_setup(>ddev, 32);
if (ret)
goto err_irq_fini;
--
2.26.0.rc2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v4 3/3] drm/radeon: fix scatter-gather mapping with user pages
>-Original Message- >From: dri-devel On Behalf Of >Shane Francis >Sent: Wednesday, March 25, 2020 5:08 AM >To: dri-devel@lists.freedesktop.org >Cc: airl...@linux.ie; linux-ker...@vger.kernel.org; bigbeesh...@gmail.com; >amd-gfx-requ...@lists.freedesktop.org; alexander.deuc...@amd.com; >christian.koe...@amd.com >Subject: [PATCH v4 3/3] drm/radeon: fix scatter-gather mapping with user >pages > >Calls to dma_map_sg may return segments / entries than requested "may return less segment..." ? ^^^ >if they fall on page bounderies. The old implementation did not >support this use case. > >Signed-off-by: Shane Francis >--- > drivers/gpu/drm/radeon/radeon_ttm.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c >b/drivers/gpu/drm/radeon/radeon_ttm.c >index 3b92311d30b9..b3380ffab4c2 100644 >--- a/drivers/gpu/drm/radeon/radeon_ttm.c >+++ b/drivers/gpu/drm/radeon/radeon_ttm.c >@@ -528,7 +528,7 @@ static int radeon_ttm_tt_pin_userptr(struct ttm_tt >*ttm) > > r = -ENOMEM; > nents = dma_map_sg(rdev->dev, ttm->sg->sgl, ttm->sg->nents, >direction); >- if (nents != ttm->sg->nents) >+ if (nents == 0) > goto release_sg; This looks correct to me. Reviewed-by: Michael J. Ruhl M > drm_prime_sg_to_page_addr_arrays(ttm->sg, ttm->pages, >-- >2.26.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 v4 2/3] drm/amdgpu: fix scatter-gather mapping with user pages
>-Original Message- >From: dri-devel On Behalf Of >Shane Francis >Sent: Wednesday, March 25, 2020 5:08 AM >To: dri-devel@lists.freedesktop.org >Cc: airl...@linux.ie; linux-ker...@vger.kernel.org; bigbeesh...@gmail.com; >amd-gfx-requ...@lists.freedesktop.org; alexander.deuc...@amd.com; >christian.koe...@amd.com >Subject: [PATCH v4 2/3] drm/amdgpu: fix scatter-gather mapping with user >pages > >Calls to dma_map_sg may return segments / entries than requested "may return less segments/entries" ? ^^^ >if they fall on page bounderies. The old implementation did not >support this use case. > >Signed-off-by: Shane Francis >--- > drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c >b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c >index dee446278417..c6e9885c071f 100644 >--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c >+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c >@@ -974,7 +974,7 @@ static int amdgpu_ttm_tt_pin_userptr(struct ttm_tt >*ttm) > /* Map SG to device */ > r = -ENOMEM; > nents = dma_map_sg(adev->dev, ttm->sg->sgl, ttm->sg->nents, >direction); >- if (nents != ttm->sg->nents) >+ if (nents == 0) > goto release_sg; this looks correct to me. Reviewed-by: Michael J. Ruhl > /* convert SG to linear array of pages and dma addresses */ >-- >2.26.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 v4 1/3] drm/prime: use dma length macro when mapping sg
>-Original Message-
>From: dri-devel On Behalf Of
>Shane Francis
>Sent: Wednesday, March 25, 2020 5:08 AM
>To: dri-devel@lists.freedesktop.org
>Cc: airl...@linux.ie; linux-ker...@vger.kernel.org; bigbeesh...@gmail.com;
>amd-gfx-requ...@lists.freedesktop.org; alexander.deuc...@amd.com;
>christian.koe...@amd.com
>Subject: [PATCH v4 1/3] drm/prime: use dma length macro when mapping sg
>
>As dma_map_sg can reorganize scatter-gather lists in a
>way that can cause some later segments to be empty we should
>always use the sg_dma_len macro to fetch the actual length.
>
>This could now be 0 and not need to be mapped to a page or
>address array
>Signed-off-by: Shane Francis
>---
> drivers/gpu/drm/drm_prime.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
>index 86d9b0e45c8c..1de2cde2277c 100644
>--- a/drivers/gpu/drm/drm_prime.c
>+++ b/drivers/gpu/drm/drm_prime.c
>@@ -967,7 +967,7 @@ int drm_prime_sg_to_page_addr_arrays(struct
>sg_table *sgt, struct page **pages,
>
> index = 0;
> for_each_sg(sgt->sgl, sg, sgt->nents, count) {
>- len = sg->length;
>+ len = sg_dma_len(sg);
> page = sg_page(sg);
> addr = sg_dma_address(sg);
This looks correct to me.
Reviewed-by: Michael J. Ruhl
M
>
>--
>2.26.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 v4 7/8] drm/fourcc: amlogic: Add modifier definitions for the Scatter layout
On Wed, 25 Mar 2020 11:24:15 +0100 Neil Armstrong wrote: > Hi, > > On 25/03/2020 10:04, Simon Ser wrote: > > On Wednesday, March 25, 2020 9:50 AM, Neil Armstrong > > wrote: > > > >> Amlogic uses a proprietary lossless image compression protocol and format > >> for their hardware video codec accelerators, either video decoders or > >> video input encoders. > >> > >> This introduces the Scatter Memory layout, means the header contains IOMMU > >> references to the compressed frames content to optimize memory access > >> and layout. > >> > >> In this mode, only the header memory address is needed, thus the content > >> memory organization is tied to the current producer execution and cannot > >> be saved/dumped neither transferrable between Amlogic SoCs supporting this > >> modifier. > > > > I don't think this is suitable for modifiers. User-space relies on > > being able to copy a buffer from one machine to another over the > > network. It would be pretty annoying for user-space to have a blacklist > > of modifiers that don't work this way. > > > > Example of such user-space: > > https://gitlab.freedesktop.org/mstoeckl/waypipe/ > > > > I really understand your point, but this is one of the use-cases we need > solve. > This is why I split the fourcc patch and added an explicit comment. > > Please point me a way to display such buffer, the HW exists, works like that > and > it's a fact and can't change. > > It will be the same for secure zero-copy buffers we can't map from userspace, > but > only the HW decoder can read/write and HW display can read. The comparison to secure buffers is a good one. Are buffers with the DRM_FORMAT_MOD_AMLOGIC_FBC_LAYOUT_SCATTER modifier meaningfully mmappable to CPU always / sometimes / never / varies-and-cannot-know? Maybe this type should be handled similar to secure buffers, with the exception that they are not actually secured but only mostly inaccessible. Then again, I haven't looked at any of the secure buffer proposals. Thanks, pq pgpV70bI_Pfsv.pgp Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv2 07/56] drm/omap: dsi: add generic transfer function
On 25/02/2020 01:20, Sebastian Reichel wrote: This prepares the driver for becoming a mipi_dsi_host implementation, which provides a generic transfer function instead of all kind of different read/write functions. The implementation will become more elegant after unexporting the specific functions in the following patches. Signed-off-by: Sebastian Reichel --- drivers/gpu/drm/omapdrm/dss/dsi.c | 52 +++ drivers/gpu/drm/omapdrm/dss/omapdss.h | 3 ++ 2 files changed, 55 insertions(+) With the white-space issues Laurent reported fixed: Reviewed-by: Tomi Valkeinen Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v4 0/3] AMDGPU / RADEON / DRM Fix mapping of user pages
>-Original Message- >From: dri-devel On Behalf Of >Shane Francis >Sent: Wednesday, March 25, 2020 5:08 AM >To: dri-devel@lists.freedesktop.org >Cc: airl...@linux.ie; linux-ker...@vger.kernel.org; bigbeesh...@gmail.com; >amd-gfx-requ...@lists.freedesktop.org; alexander.deuc...@amd.com; >christian.koe...@amd.com >Subject: [PATCH v4 0/3] AMDGPU / RADEON / DRM Fix mapping of user pages > >This patch set is to fix a bug in amdgpu / radeon drm that results in >a crash when dma_map_sg combines elemnets within a scatterlist table. s/elemnets/elements >There are 2 shortfalls in the current kernel. > >1) AMDGPU / RADEON assumes that the requested and created scatterlist > table lengths using from dma_map_sg are equal. This may not be the > case using the newer dma-iommu implementation > >2) drm_prime does not fetch the length of the scatterlist > via the correct dma macro, this can use the incorrect length > being used (>0) in places where dma_map_sg has updated the table > elements. > > The sg_dma_len macro is representative of the length of the sg item > after dma_map_sg > >Example Crash : >> [drm:amdgpu_ttm_backend_bind [amdgpu]] *ERROR* failed to pin userptr > >This happens in OpenCL applications, causing them to crash or hang, on >either amdgpu-pro or ROCm OpenCL implementations > >I have verified this fixes the above on kernel 5.5 and 5.5rc using an >AMD Vega 64 GPU > >Shane Francis (3): > drm/prime: use dma length macro when mapping sg to arrays > drm/amdgpu: fix scatter-gather mapping with user pages > drm/radeon: fix scatter-gather mapping with user pages > > drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 2 +- > drivers/gpu/drm/drm_prime.c | 2 +- > drivers/gpu/drm/radeon/radeon_ttm.c | 2 +- > 3 files changed, 3 insertions(+), 3 deletions(-) > >-- >2.26.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: [PATCHv2 06/56] drm/omap: constify write buffers
On 25/02/2020 01:20, Sebastian Reichel wrote: The write buffers are not modified, so they can be constant. Signed-off-by: Sebastian Reichel --- drivers/gpu/drm/omapdrm/dss/dsi.c | 24 drivers/gpu/drm/omapdrm/dss/omapdss.h | 10 +- 2 files changed, 17 insertions(+), 17 deletions(-) Reviewed-by: Tomi Valkeinen Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv2 05/56] drm/omap: dsi: use MIPI_DSI_FMT_* instead of OMAP_DSS_DSI_FMT_*
On 25/02/2020 01:20, Sebastian Reichel wrote: This replaces OMAP specific enum for pixel format with common implementation. Signed-off-by: Sebastian Reichel --- .../gpu/drm/omapdrm/displays/panel-dsi-cm.c | 2 +- drivers/gpu/drm/omapdrm/dss/dsi.c | 49 +++ drivers/gpu/drm/omapdrm/dss/omapdss.h | 10 +--- 3 files changed, 20 insertions(+), 41 deletions(-) Reviewed-by: Tomi Valkeinen Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv2 00/56] drm/omap: Convert DSI code to use drm_mipi_dsi and drm_panel
Hi Tomi, On Wed, Mar 25, 2020 at 02:47:48PM +0200, Tomi Valkeinen wrote: > On 25/02/2020 01:20, Sebastian Reichel wrote: > > This updates the existing omapdrm DSI code, so that it uses > > common drm_mipi_dsi API and drm_panel. > > > > The patchset has been tested with Droid 4 using Linux console, X.org and > > Weston. The patchset is based on Laurent Pinchartl's patch series [0] > > and removes the last custom panel driver, so quite a few cleanups on the > > omapdrm codebase were possible. > > This is a big series, and I suggest to keep the cleanups to minimum. > Things can be cleaned up afterwards after the functional parts of this > series have been merged. There are a few cleanups at the bottom of the series that could be merged without waiting for the rest though :-) -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv2 00/56] drm/omap: Convert DSI code to use drm_mipi_dsi and drm_panel
On 25/02/2020 01:20, Sebastian Reichel wrote: This updates the existing omapdrm DSI code, so that it uses common drm_mipi_dsi API and drm_panel. The patchset has been tested with Droid 4 using Linux console, X.org and Weston. The patchset is based on Laurent Pinchartl's patch series [0] and removes the last custom panel driver, so quite a few cleanups on the omapdrm codebase were possible. This is a big series, and I suggest to keep the cleanups to minimum. Things can be cleaned up afterwards after the functional parts of this series have been merged. Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv2 04/56] omap/drm: drop unused dsi.configure_pins
On 25/02/2020 01:20, Sebastian Reichel wrote: The panel-dsi-cm's ddata->pin_config is always NULL, so this callback is never called. Instead the DSI encoder gets the pin configuration directly from DT. Signed-off-by: Sebastian Reichel --- drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c | 11 --- drivers/gpu/drm/omapdrm/dss/dsi.c | 1 - drivers/gpu/drm/omapdrm/dss/omapdss.h | 2 -- 3 files changed, 14 deletions(-) Reviewed-by: Tomi Valkeinen Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv2 03/56] Revert "drm/omap: dss: Remove unused omap_dss_device operations"
Hi, On 25/02/2020 01:20, Sebastian Reichel wrote: From: Sebastian Reichel This reverts commit 4ff8e98879e6eeae9d125dfcf3b642075d00089d. --- drivers/gpu/drm/omapdrm/dss/base.c | 26 +++ drivers/gpu/drm/omapdrm/dss/omapdss.h | 6 drivers/gpu/drm/omapdrm/omap_encoder.c | 44 +++--- 3 files changed, 71 insertions(+), 5 deletions(-) This is missing description. Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 1/2] dt-bindings: display: convert rockchip vop bindings to yaml
Current dts files with 'vop' nodes are manually verified.
In order to automate this process rockchip-vop.txt
has to be converted to yaml.
Signed-off-by: Johan Jonker
---
Changes v4:
Change description
Replace compatible oneOf by enum
Change interrupts description
Remove resets minItems
Changes v3:
Change description
Changes v2:
No new properties
---
.../bindings/display/rockchip/rockchip-vop.txt | 74
.../bindings/display/rockchip/rockchip-vop.yaml| 124 +
2 files changed, 124 insertions(+), 74 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt
create mode 100644
Documentation/devicetree/bindings/display/rockchip/rockchip-vop.yaml
diff --git
a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt
b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt
deleted file mode 100644
index 8b3a5f514..0
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt
+++ /dev/null
@@ -1,74 +0,0 @@
-device-tree bindings for rockchip soc display controller (vop)
-
-VOP (Visual Output Processor) is the Display Controller for the Rockchip
-series of SoCs which transfers the image data from a video memory
-buffer to an external LCD interface.
-
-Required properties:
-- compatible: value should be one of the following
- "rockchip,rk3036-vop";
- "rockchip,rk3126-vop";
- "rockchip,px30-vop-lit";
- "rockchip,px30-vop-big";
- "rockchip,rk3066-vop";
- "rockchip,rk3188-vop";
- "rockchip,rk3288-vop";
- "rockchip,rk3368-vop";
- "rockchip,rk3366-vop";
- "rockchip,rk3399-vop-big";
- "rockchip,rk3399-vop-lit";
- "rockchip,rk3228-vop";
- "rockchip,rk3328-vop";
-
-- reg: Must contain one entry corresponding to the base address and length
- of the register space. Can optionally contain a second entry
- corresponding to the CRTC gamma LUT address.
-
-- interrupts: should contain a list of all VOP IP block interrupts in the
-order: VSYNC, LCD_SYSTEM. The interrupt specifier
-format depends on the interrupt controller used.
-
-- clocks: must include clock specifiers corresponding to entries in the
- clock-names property.
-
-- clock-names: Must contain
- aclk_vop: for ddr buffer transfer.
- hclk_vop: for ahb bus to R/W the phy regs.
- dclk_vop: pixel clock.
-
-- resets: Must contain an entry for each entry in reset-names.
- See ../reset/reset.txt for details.
-- reset-names: Must include the following entries:
- - axi
- - ahb
- - dclk
-
-- iommus: required a iommu node
-
-- port: A port node with endpoint definitions as defined in
- Documentation/devicetree/bindings/media/video-interfaces.txt.
-
-Example:
-SoC specific DT entry:
- vopb: vopb@ff93 {
- compatible = "rockchip,rk3288-vop";
- reg = <0x0 0xff93 0x0 0x19c>, <0x0 0xff931000 0x0 0x1000>;
- interrupts = ;
- clocks = < ACLK_VOP0>, < DCLK_VOP0>, < HCLK_VOP0>;
- clock-names = "aclk_vop", "dclk_vop", "hclk_vop";
- resets = < SRST_LCDC1_AXI>, < SRST_LCDC1_AHB>, <
SRST_LCDC1_DCLK>;
- reset-names = "axi", "ahb", "dclk";
- iommus = <_mmu>;
- vopb_out: port {
- #address-cells = <1>;
- #size-cells = <0>;
- vopb_out_edp: endpoint@0 {
- reg = <0>;
- remote-endpoint=<_in_vopb>;
- };
- vopb_out_hdmi: endpoint@1 {
- reg = <1>;
- remote-endpoint=<_in_vopb>;
- };
- };
- };
diff --git
a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.yaml
b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.yaml
new file mode 100644
index 0..bc58c5132
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.yaml
@@ -0,0 +1,124 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/rockchip/rockchip-vop.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip SoC display controller (VOP)
+
+description:
+ VOP (Video Output Processor) is the display controller for the Rockchip
+ series of SoCs which transfers the image data from a video memory
+ buffer to an external LCD interface.
+
+maintainers:
+ - Sandy Huang
+ - Heiko Stuebner
+
+properties:
+ compatible:
+enum:
+ - rockchip,px30-vop-big
+ - rockchip,px30-vop-lit
+ - rockchip,rk3036-vop
+ - rockchip,rk3066-vop
+ - rockchip,rk3126-vop
+ -
[PATCH RFC 0/1] Support virtio objects in virtio-video driver
This implements a feature in virtio-video driver to use exported virtio objects as video buffers. So, the users will be able to use resources allocated by other virtio devices such as virtio-gpu. The virtio protocol for this feature is proposed by [1]. This commit depends on the following unmerged patches: * Virtio-video driver patch [2] * Patch series for virtio cross-device resources [3] * ChromeOS's local patch to use data_offset for offset of multiplanar format [4] [1]: https://markmail.org/message/wxdne5re7aaugbjg [2]: https://patchwork.linuxtv.org/patch/61717/ [3]: https://patchwork.kernel.org/project/linux-media/list/?series=254707 [4]: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/1057eb620ccd3da4632c14df269d545cb9a1ccb2 Keiichi Watanabe (1): drivers: media: virtio: Support virtio objects in virtio-video driver drivers/media/virtio/virtio_video.h| 26 +++- drivers/media/virtio/virtio_video_dec.c| 1 + drivers/media/virtio/virtio_video_device.c | 131 - drivers/media/virtio/virtio_video_driver.c | 25 +++- drivers/media/virtio/virtio_video_vq.c | 81 ++--- include/uapi/linux/virtio_video.h | 15 ++- 6 files changed, 243 insertions(+), 36 deletions(-) -- 2.25.1.696.g5e7596f4ac-goog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 2/2] dt-bindings: display: rockchip-vop: add additional properties
In the old txt situation we add/describe only properties that are used
by the driver/hardware itself. With yaml it also filters things in a
node that are used by other drivers like 'assigned-clocks' and
'assigned-clock-rates' for rk3399 and 'power-domains' for most
Rockchip Socs in 'vop' nodes, so add them to 'rockchip-vop.yaml'.
Signed-off-by: Johan Jonker
---
.../devicetree/bindings/display/rockchip/rockchip-vop.yaml| 11 +++
1 file changed, 11 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.yaml
b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.yaml
index bc58c5132..497a9fb2d 100644
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.yaml
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.yaml
@@ -75,9 +75,18 @@ properties:
A port node with endpoint definitions as defined in
Documentation/devicetree/bindings/media/video-interfaces.txt.
+ assigned-clocks:
+maxItems: 2
+
+ assigned-clock-rates:
+maxItems: 2
+
iommus:
maxItems: 1
+ power-domains:
+maxItems: 1
+
required:
- compatible
- reg
@@ -95,6 +104,7 @@ examples:
#include
#include
#include
+#include
vopb: vopb@ff93 {
compatible = "rockchip,rk3288-vop";
reg = <0x0 0xff93 0x0 0x19c>,
@@ -104,6 +114,7 @@ examples:
< DCLK_VOP0>,
< HCLK_VOP0>;
clock-names = "aclk_vop", "dclk_vop", "hclk_vop";
+ power-domains = < RK3288_PD_VIO>;
resets = < SRST_LCDC1_AXI>,
< SRST_LCDC1_AHB>,
< SRST_LCDC1_DCLK>;
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RFC 1/1] drivers: media: virtio: Support virtio objects in virtio-video driver
This patch makes the virtio-video driver use virtio objects as DMA buffers.
So, users will beable to import resources exported by other virtio devices
such as virtio-gpu.
Currently, we assumes that only one virtio object for each v4l2_buffer
format even if it's for a multiplanar format.
Signed-off-by: Keiichi Watanabe
---
drivers/media/virtio/virtio_video.h| 26 +++-
drivers/media/virtio/virtio_video_dec.c| 1 +
drivers/media/virtio/virtio_video_device.c | 131 -
drivers/media/virtio/virtio_video_driver.c | 25 +++-
drivers/media/virtio/virtio_video_vq.c | 81 ++---
include/uapi/linux/virtio_video.h | 15 ++-
6 files changed, 243 insertions(+), 36 deletions(-)
diff --git a/drivers/media/virtio/virtio_video.h
b/drivers/media/virtio/virtio_video.h
index c5a5704326c0..b74e5a06753f 100644
--- a/drivers/media/virtio/virtio_video.h
+++ b/drivers/media/virtio/virtio_video.h
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -123,10 +124,17 @@ struct virtio_video_queue {
struct work_struct dequeue_work;
};
+enum virtio_video_resource_type {
+ RESOURCE_TYPE_GUEST_PAGES = 0,
+ RESOURCE_TYPE_VIRTIO_OBJECT,
+};
+
struct virtio_video {
struct v4l2_device v4l2_dev;
int instance;
+ enum virtio_video_resource_type res_type;
+
struct virtio_device *vdev;
struct virtio_video_queue commandq;
struct virtio_video_queue eventq;
@@ -207,6 +215,9 @@ struct virtio_video_buffer {
struct v4l2_m2m_buffer v4l2_m2m_vb;
uint32_t resource_id;
bool queued;
+
+ /* Only for virtio object buffer */
+ uuid_t uuid;
};
static inline gfp_t
@@ -300,12 +311,14 @@ int virtio_video_cmd_stream_create(struct virtio_video
*vv, uint32_t stream_id,
int virtio_video_cmd_stream_destroy(struct virtio_video *vv,
uint32_t stream_id);
int virtio_video_cmd_stream_drain(struct virtio_video *vv, uint32_t stream_id);
-int virtio_video_cmd_resource_create(struct virtio_video *vv,
-uint32_t stream_id, uint32_t resource_id,
-uint32_t queue_type,
-struct virtio_video_mem_entry *ents,
- unsigned int num_planes,
-unsigned int *num_entry);
+int virtio_video_cmd_resource_create_page(
+ struct virtio_video *vv, uint32_t stream_id, uint32_t resource_id,
+ uint32_t queue_type, unsigned int num_planes, unsigned int *num_entries,
+ struct virtio_video_mem_entry *ents);
+int virtio_video_cmd_resource_create_object(
+ struct virtio_video *vv, uint32_t stream_id, uint32_t resource_id,
+ uint32_t queue_type, unsigned int num_planes, struct vb2_plane *planes,
+ struct virtio_video_object_entry *ents);
int virtio_video_cmd_resource_destroy_all(struct virtio_video *vv,
struct virtio_video_stream *stream,
uint32_t queue_type);
@@ -354,6 +367,7 @@ void virtio_video_mark_drain_complete(struct
virtio_video_stream *stream,
int virtio_video_queue_setup(struct vb2_queue *vq, unsigned int *num_buffers,
unsigned int *num_planes, unsigned int sizes[],
struct device *alloc_devs[]);
+int virtio_video_buf_prepare(struct vb2_buffer *vb);
int virtio_video_buf_init(struct vb2_buffer *vb);
void virtio_video_buf_cleanup(struct vb2_buffer *vb);
int virtio_video_querycap(struct file *file, void *fh,
diff --git a/drivers/media/virtio/virtio_video_dec.c
b/drivers/media/virtio/virtio_video_dec.c
index 4b85337bb9f3..5d763191f436 100644
--- a/drivers/media/virtio/virtio_video_dec.c
+++ b/drivers/media/virtio/virtio_video_dec.c
@@ -122,6 +122,7 @@ static void virtio_video_dec_stop_streaming(struct
vb2_queue *vq)
static const struct vb2_ops virtio_video_dec_qops = {
.queue_setup = virtio_video_queue_setup,
.buf_init= virtio_video_buf_init,
+ .buf_prepare = virtio_video_buf_prepare,
.buf_cleanup = virtio_video_buf_cleanup,
.buf_queue = virtio_video_dec_buf_queue,
.start_streaming = virtio_video_dec_start_streaming,
diff --git a/drivers/media/virtio/virtio_video_device.c
b/drivers/media/virtio/virtio_video_device.c
index 8e6bc317339b..e91107082d97 100644
--- a/drivers/media/virtio/virtio_video_device.c
+++ b/drivers/media/virtio/virtio_video_device.c
@@ -17,6 +17,7 @@
* along with this program; if not, see
Re: [PATCH v4 7/8] drm/fourcc: amlogic: Add modifier definitions for the Scatter layout
Hi, On 25/03/2020 10:04, Simon Ser wrote: > On Wednesday, March 25, 2020 9:50 AM, Neil Armstrong > wrote: > >> Amlogic uses a proprietary lossless image compression protocol and format >> for their hardware video codec accelerators, either video decoders or >> video input encoders. >> >> This introduces the Scatter Memory layout, means the header contains IOMMU >> references to the compressed frames content to optimize memory access >> and layout. >> >> In this mode, only the header memory address is needed, thus the content >> memory organization is tied to the current producer execution and cannot >> be saved/dumped neither transferrable between Amlogic SoCs supporting this >> modifier. > > I don't think this is suitable for modifiers. User-space relies on > being able to copy a buffer from one machine to another over the > network. It would be pretty annoying for user-space to have a blacklist > of modifiers that don't work this way. > > Example of such user-space: > https://gitlab.freedesktop.org/mstoeckl/waypipe/ > I really understand your point, but this is one of the use-cases we need solve. This is why I split the fourcc patch and added an explicit comment. Please point me a way to display such buffer, the HW exists, works like that and it's a fact and can't change. It will be the same for secure zero-copy buffers we can't map from userspace, but only the HW decoder can read/write and HW display can read. We need a solution for those if we want embedded and secure products to be supported upstream, otherwise they will stay in an obscure off-tree linux tree and for example AOSP support (which will support these secure video buffers) will use these vendor specific hacks. Neil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: manage drm_minor cleanup with drmm_
On Tue, Mar 24, 2020 at 10:42 PM Sam Ravnborg wrote:
>
> On Tue, Mar 24, 2020 at 09:39:36PM +0100, Daniel Vetter wrote:
> > The cleanup here is somewhat tricky, since we can't tell apart the
> > allocated minor index from 0. So register a cleanup action first, and
> > if the index allocation fails, unregister that cleanup action again to
> > avoid bad mistakes.
> >
> > The kdev for the minor already handles NULL, so no problem there.
> >
> > Hence add drmm_remove_action() to the drm_managed library.
> >
> > v2: Make pointer math around void ** consistent with what Laurent
> > suggested.
> >
> > v3: Use drmm_add_action_or_reset and remove drmm_remove_action. Noticed
> > because of some questions from Thomas. This also means we need to move
> > the drmm_add_action_or_reset helper earlier in the series.
> >
> > v4: Uh ... fix slightly embarrassing bug CI spotted.
> Looks like the one I spotted in my review.
> Saw your mail only after posting.
Yup, but thanks for spotting it in your review too, gives me lots of
confidence that you really checked all the details - I was totally
blind and took me an afternoon with the clue bat to find the bug I
created :-)
> One Q below.
>
> >
> > Cc: Thomas Zimmermann
> > Cc: Laurent Pinchart
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/drm_drv.c | 69 ---
> > drivers/gpu/drm/drm_managed.c | 14 +++
> > include/drm/drm_managed.h | 9 -
> > 3 files changed, 46 insertions(+), 46 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> > index a710c53d13a8..50c56ff24c71 100644
> > --- a/drivers/gpu/drm/drm_drv.c
> > +++ b/drivers/gpu/drm/drm_drv.c
> > @@ -93,13 +93,25 @@ static struct drm_minor **drm_minor_get_slot(struct
> > drm_device *dev,
> > }
> > }
> >
> > +static void drm_minor_alloc_release(struct drm_device *dev, void *data)
> > +{
> > + struct drm_minor *minor = data;
> > + unsigned long flags;
> > +
> > + put_device(minor->kdev);
> > +
> > + spin_lock_irqsave(_minor_lock, flags);
> > + idr_remove(_minors_idr, minor->index);
> > + spin_unlock_irqrestore(_minor_lock, flags);
> > +}
> > +
> > static int drm_minor_alloc(struct drm_device *dev, unsigned int type)
> > {
> > struct drm_minor *minor;
> > unsigned long flags;
> > int r;
> >
> > - minor = kzalloc(sizeof(*minor), GFP_KERNEL);
> > + minor = drmm_kzalloc(dev, sizeof(*minor), GFP_KERNEL);
> > if (!minor)
> > return -ENOMEM;
> >
> > @@ -117,46 +129,20 @@ static int drm_minor_alloc(struct drm_device *dev,
> > unsigned int type)
> > idr_preload_end();
> >
> > if (r < 0)
> > - goto err_free;
> > + return r;
> >
> > minor->index = r;
> >
> > + r = drmm_add_action_or_reset(dev, drm_minor_alloc_release, minor);
> > + if (r)
> > + return r;
> > +
> > minor->kdev = drm_sysfs_minor_alloc(minor);
> > - if (IS_ERR(minor->kdev)) {
> > - r = PTR_ERR(minor->kdev);
> > - goto err_index;
> > - }
> > + if (IS_ERR(minor->kdev))
> > + return PTR_ERR(minor->kdev);
> >
> > *drm_minor_get_slot(dev, type) = minor;
> > return 0;
> > -
> > -err_index:
> > - spin_lock_irqsave(_minor_lock, flags);
> > - idr_remove(_minors_idr, minor->index);
> > - spin_unlock_irqrestore(_minor_lock, flags);
> > -err_free:
> > - kfree(minor);
> > - return r;
> > -}
> > -
> > -static void drm_minor_free(struct drm_device *dev, unsigned int type)
> > -{
> > - struct drm_minor **slot, *minor;
> > - unsigned long flags;
> > -
> > - slot = drm_minor_get_slot(dev, type);
> > - minor = *slot;
> > - if (!minor)
> > - return;
> > -
> > - put_device(minor->kdev);
> > -
> > - spin_lock_irqsave(_minor_lock, flags);
> > - idr_remove(_minors_idr, minor->index);
> > - spin_unlock_irqrestore(_minor_lock, flags);
> > -
> > - kfree(minor);
>
> > - *slot = NULL;
>
> In drm_minor_alloc_release() there is no equivalent to this
> NULL assignment.
> Did you consider if there was any real reason for the NULL assignment?
I think they're just prudence, so that you oops if you do a
use-after-free. But nowadays we have KASAN (and slab poisoning, and
lots more stuff), which is massively more powerful at catching these
kinds of bugs. There's a bunch of these "set to NULL" that I've
dropped, since with drmm you easily get access to the higher level
structure that has the pointer to the thing you're cleaning up.
-Daniel
>
> Sam
>
>
> > }
> >
> > static int drm_minor_register(struct drm_device *dev, unsigned int type)
> > @@ -678,16 +664,16 @@ int drm_dev_init(struct drm_device *dev,
> > if (drm_core_check_feature(dev, DRIVER_RENDER)) {
> > ret = drm_minor_alloc(dev, DRM_MINOR_RENDER);
> > if (ret)
> > - goto err_minors;
> > +
[PATCH v4 3/3] drm/radeon: fix scatter-gather mapping with user pages
Calls to dma_map_sg may return segments / entries than requested if they fall on page bounderies. The old implementation did not support this use case. Signed-off-by: Shane Francis --- drivers/gpu/drm/radeon/radeon_ttm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c b/drivers/gpu/drm/radeon/radeon_ttm.c index 3b92311d30b9..b3380ffab4c2 100644 --- a/drivers/gpu/drm/radeon/radeon_ttm.c +++ b/drivers/gpu/drm/radeon/radeon_ttm.c @@ -528,7 +528,7 @@ static int radeon_ttm_tt_pin_userptr(struct ttm_tt *ttm) r = -ENOMEM; nents = dma_map_sg(rdev->dev, ttm->sg->sgl, ttm->sg->nents, direction); - if (nents != ttm->sg->nents) + if (nents == 0) goto release_sg; drm_prime_sg_to_page_addr_arrays(ttm->sg, ttm->pages, -- 2.26.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 2/3] drm/amdgpu: fix scatter-gather mapping with user pages
Calls to dma_map_sg may return segments / entries than requested if they fall on page bounderies. The old implementation did not support this use case. Signed-off-by: Shane Francis --- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c index dee446278417..c6e9885c071f 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c @@ -974,7 +974,7 @@ static int amdgpu_ttm_tt_pin_userptr(struct ttm_tt *ttm) /* Map SG to device */ r = -ENOMEM; nents = dma_map_sg(adev->dev, ttm->sg->sgl, ttm->sg->nents, direction); - if (nents != ttm->sg->nents) + if (nents == 0) goto release_sg; /* convert SG to linear array of pages and dma addresses */ -- 2.26.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 1/3] drm/prime: use dma length macro when mapping sg
As dma_map_sg can reorganize scatter-gather lists in a
way that can cause some later segments to be empty we should
always use the sg_dma_len macro to fetch the actual length.
This could now be 0 and not need to be mapped to a page or
address array
Signed-off-by: Shane Francis
---
drivers/gpu/drm/drm_prime.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 86d9b0e45c8c..1de2cde2277c 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -967,7 +967,7 @@ int drm_prime_sg_to_page_addr_arrays(struct sg_table *sgt,
struct page **pages,
index = 0;
for_each_sg(sgt->sgl, sg, sgt->nents, count) {
- len = sg->length;
+ len = sg_dma_len(sg);
page = sg_page(sg);
addr = sg_dma_address(sg);
--
2.26.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 0/3] AMDGPU / RADEON / DRM Fix mapping of user pages
This patch set is to fix a bug in amdgpu / radeon drm that results in a crash when dma_map_sg combines elemnets within a scatterlist table. There are 2 shortfalls in the current kernel. 1) AMDGPU / RADEON assumes that the requested and created scatterlist table lengths using from dma_map_sg are equal. This may not be the case using the newer dma-iommu implementation 2) drm_prime does not fetch the length of the scatterlist via the correct dma macro, this can use the incorrect length being used (>0) in places where dma_map_sg has updated the table elements. The sg_dma_len macro is representative of the length of the sg item after dma_map_sg Example Crash : > [drm:amdgpu_ttm_backend_bind [amdgpu]] *ERROR* failed to pin userptr This happens in OpenCL applications, causing them to crash or hang, on either amdgpu-pro or ROCm OpenCL implementations I have verified this fixes the above on kernel 5.5 and 5.5rc using an AMD Vega 64 GPU Shane Francis (3): drm/prime: use dma length macro when mapping sg to arrays drm/amdgpu: fix scatter-gather mapping with user pages drm/radeon: fix scatter-gather mapping with user pages drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 2 +- drivers/gpu/drm/drm_prime.c | 2 +- drivers/gpu/drm/radeon/radeon_ttm.c | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) -- 2.26.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 22/51] drm: manage drm_minor cleanup with drmm_
On Tue, Mar 24, 2020 at 10:36 PM Sam Ravnborg wrote:
>
> On Mon, Mar 23, 2020 at 03:49:21PM +0100, Daniel Vetter wrote:
> > The cleanup here is somewhat tricky, since we can't tell apart the
> > allocated minor index from 0. So register a cleanup action first, and
> > if the index allocation fails, unregister that cleanup action again to
> > avoid bad mistakes.
> >
> > The kdev for the minor already handles NULL, so no problem there.
> >
> > Hence add drmm_remove_action() to the drm_managed library.
> >
> > v2: Make pointer math around void ** consistent with what Laurent
> > suggested.
> >
> > v3: Use drmm_add_action_or_reset and remove drmm_remove_action. Noticed
> > because of some questions from Thomas. This also means we need to move
> > the drmm_add_action_or_reset helper earlier in the series.
> >
> > Cc: Thomas Zimmermann
> > Cc: Laurent Pinchart
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/drm_drv.c | 70 ---
> > drivers/gpu/drm/drm_managed.c | 14 +++
> > include/drm/drm_managed.h | 9 -
> > 3 files changed, 46 insertions(+), 47 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> > index a710c53d13a8..25fc2107057c 100644
> > --- a/drivers/gpu/drm/drm_drv.c
> > +++ b/drivers/gpu/drm/drm_drv.c
> > @@ -93,13 +93,25 @@ static struct drm_minor **drm_minor_get_slot(struct
> > drm_device *dev,
> > }
> > }
> >
> > +static void drm_minor_alloc_release(struct drm_device *dev, void *data)
> > +{
> > + struct drm_minor *minor = data;
> > + unsigned long flags;
> > +
> > + put_device(minor->kdev);
> > +
> > + spin_lock_irqsave(_minor_lock, flags);
> > + idr_remove(_minors_idr, minor->index);
> > + spin_unlock_irqrestore(_minor_lock, flags);
> > +}
> > +
> > static int drm_minor_alloc(struct drm_device *dev, unsigned int type)
> > {
> > struct drm_minor *minor;
> > unsigned long flags;
> > int r;
> >
> > - minor = kzalloc(sizeof(*minor), GFP_KERNEL);
> > + minor = drmm_kzalloc(dev, sizeof(*minor), GFP_KERNEL);
> > if (!minor)
> > return -ENOMEM;
> >
> > @@ -117,46 +129,19 @@ static int drm_minor_alloc(struct drm_device *dev,
> > unsigned int type)
> > idr_preload_end();
> >
> > if (r < 0)
> > - goto err_free;
> > + return r;
> >
> > - minor->index = r;
> > + r = drmm_add_action_or_reset(dev, drm_minor_alloc_release, minor);
> > + if (r)
> > + return r;
> >
> > + minor->index = r;
>
> This looks wrong.
>
> We do:
> r = idr_alloc(_minors_idr,
>
> And then we loose the value when we reuse r
> in the call to drmm_add_action_or_reset().
> So the index we assign is the return value of
> drmm_add_action_or_reset() and not the ID returned
> by idr_alloc()
>
> With this fixed:
>
> Reviewed-by: Sam Ravnborg
>
> > minor->kdev = drm_sysfs_minor_alloc(minor);
> > - if (IS_ERR(minor->kdev)) {
> > - r = PTR_ERR(minor->kdev);
> > - goto err_index;
> > - }
> > + if (IS_ERR(minor->kdev))
> > + return PTR_ERR(minor->kdev);
> >
> > *drm_minor_get_slot(dev, type) = minor;
> > return 0;
> > -
> > -err_index:
> > - spin_lock_irqsave(_minor_lock, flags);
> > - idr_remove(_minors_idr, minor->index);
> > - spin_unlock_irqrestore(_minor_lock, flags);
> > -err_free:
> > - kfree(minor);
> > - return r;
> > -}
> > -
> > -static void drm_minor_free(struct drm_device *dev, unsigned int type)
> > -{
> > - struct drm_minor **slot, *minor;
> > - unsigned long flags;
> > -
> > - slot = drm_minor_get_slot(dev, type);
> > - minor = *slot;
> > - if (!minor)
> > - return;
> > -
> > - put_device(minor->kdev);
> > -
> > - spin_lock_irqsave(_minor_lock, flags);
> > - idr_remove(_minors_idr, minor->index);
> > - spin_unlock_irqrestore(_minor_lock, flags);
> > -
> > - kfree(minor);
> > - *slot = NULL;
> > }
> >
> > static int drm_minor_register(struct drm_device *dev, unsigned int type)
> > @@ -678,16 +663,16 @@ int drm_dev_init(struct drm_device *dev,
> > if (drm_core_check_feature(dev, DRIVER_RENDER)) {
> > ret = drm_minor_alloc(dev, DRM_MINOR_RENDER);
> > if (ret)
> > - goto err_minors;
> > + goto err;
> > }
> >
> > ret = drm_minor_alloc(dev, DRM_MINOR_PRIMARY);
> > if (ret)
> > - goto err_minors;
> > + goto err;
> >
> > ret = drm_legacy_create_map_hash(dev);
> > if (ret)
> > - goto err_minors;
> > + goto err;
> >
> > drm_legacy_ctxbitmap_init(dev);
> >
> > @@ -695,7 +680,7 @@ int drm_dev_init(struct drm_device *dev,
> > ret = drm_gem_init(dev);
> > if (ret) {
> > DRM_ERROR("Cannot initialize graphics
Re: [PATCH v4 7/8] drm/fourcc: amlogic: Add modifier definitions for the Scatter layout
On Wednesday, March 25, 2020 9:50 AM, Neil Armstrong wrote: > Amlogic uses a proprietary lossless image compression protocol and format > for their hardware video codec accelerators, either video decoders or > video input encoders. > > This introduces the Scatter Memory layout, means the header contains IOMMU > references to the compressed frames content to optimize memory access > and layout. > > In this mode, only the header memory address is needed, thus the content > memory organization is tied to the current producer execution and cannot > be saved/dumped neither transferrable between Amlogic SoCs supporting this > modifier. I don't think this is suitable for modifiers. User-space relies on being able to copy a buffer from one machine to another over the network. It would be pretty annoying for user-space to have a blacklist of modifiers that don't work this way. Example of such user-space: https://gitlab.freedesktop.org/mstoeckl/waypipe/ ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 3/8] drm/meson: overlay: setup overlay for Amlogic FBC
Setup the Amlogic FBC decoder for the VD1 video overlay plane.
The VD1 Amlogic FBC decoder is integrated in the pipeline like the
YUV pixel reading/formatter but used a direct memory address instead.
This adds support for the basic layout, and needs to calculate the content
body size since the header is allocated after.
Tested-by: Kevin Hilman
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/meson_drv.h | 16 ++
drivers/gpu/drm/meson/meson_overlay.c | 233 +-
2 files changed, 241 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_drv.h
b/drivers/gpu/drm/meson/meson_drv.h
index 04fdf3826643..da951964e988 100644
--- a/drivers/gpu/drm/meson/meson_drv.h
+++ b/drivers/gpu/drm/meson/meson_drv.h
@@ -80,6 +80,7 @@ struct meson_drm {
bool vd1_enabled;
bool vd1_commit;
+ bool vd1_afbc;
unsigned int vd1_planes;
uint32_t vd1_if0_gen_reg;
uint32_t vd1_if0_luma_x0;
@@ -105,6 +106,21 @@ struct meson_drm {
uint32_t vd1_height0;
uint32_t vd1_height1;
uint32_t vd1_height2;
+ uint32_t vd1_afbc_mode;
+ uint32_t vd1_afbc_en;
+ uint32_t vd1_afbc_head_addr;
+ uint32_t vd1_afbc_body_addr;
+ uint32_t vd1_afbc_conv_ctrl;
+ uint32_t vd1_afbc_dec_def_color;
+ uint32_t vd1_afbc_vd_cfmt_ctrl;
+ uint32_t vd1_afbc_vd_cfmt_w;
+ uint32_t vd1_afbc_vd_cfmt_h;
+ uint32_t vd1_afbc_mif_hor_scope;
+ uint32_t vd1_afbc_mif_ver_scope;
+ uint32_t vd1_afbc_size_out;
+ uint32_t vd1_afbc_pixel_hor_scope;
+ uint32_t vd1_afbc_pixel_ver_scope;
+ uint32_t vd1_afbc_size_in;
uint32_t vpp_pic_in_height;
uint32_t vpp_postblend_vd1_h_start_end;
uint32_t vpp_postblend_vd1_v_start_end;
diff --git a/drivers/gpu/drm/meson/meson_overlay.c
b/drivers/gpu/drm/meson/meson_overlay.c
index 2468b0212d52..51fa038ad5d7 100644
--- a/drivers/gpu/drm/meson/meson_overlay.c
+++ b/drivers/gpu/drm/meson/meson_overlay.c
@@ -5,6 +5,7 @@
* Copyright (C) 2015 Amlogic, Inc. All rights reserved.
*/
+#define DEBUG
#include
#include
@@ -76,6 +77,84 @@
#define VD_REGION24_START(value) FIELD_PREP(GENMASK(11, 0), value)
#define VD_REGION13_END(value) FIELD_PREP(GENMASK(27, 16), value)
+/* AFBC_ENABLE */
+#define AFBC_DEC_ENABLEBIT(8)
+#define AFBC_FRM_START BIT(0)
+
+/* AFBC_MODE */
+#define AFBC_HORZ_SKIP_UV(value) FIELD_PREP(GENMASK(1, 0), value)
+#define AFBC_VERT_SKIP_UV(value) FIELD_PREP(GENMASK(3, 2), value)
+#define AFBC_HORZ_SKIP_Y(value)FIELD_PREP(GENMASK(5, 4), value)
+#define AFBC_VERT_SKIP_Y(value)FIELD_PREP(GENMASK(7, 6), value)
+#define AFBC_COMPBITS_YUV(value) FIELD_PREP(GENMASK(13, 8), value)
+#define AFBC_COMPBITS_8BIT 0
+#define AFBC_COMPBITS_10BIT(2 | (2 << 2) | (2 << 4))
+#define AFBC_BURST_LEN(value) FIELD_PREP(GENMASK(15, 14), value)
+#define AFBC_HOLD_LINE_NUM(value) FIELD_PREP(GENMASK(22, 16), value)
+#define AFBC_MIF_URGENT(value) FIELD_PREP(GENMASK(25, 24), value)
+#define AFBC_REV_MODE(value) FIELD_PREP(GENMASK(27, 26), value)
+#define AFBC_BLK_MEM_MODE BIT(28)
+#define AFBC_SCATTER_MODE BIT(29)
+#define AFBC_SOFT_RESETBIT(31)
+
+/* AFBC_SIZE_IN */
+#define AFBC_HSIZE_IN(value) FIELD_PREP(GENMASK(28, 16), value)
+#define AFBC_VSIZE_IN(value) FIELD_PREP(GENMASK(12, 0), value)
+
+/* AFBC_DEC_DEF_COLOR */
+#define AFBC_DEF_COLOR_Y(value)FIELD_PREP(GENMASK(29, 20),
value)
+#define AFBC_DEF_COLOR_U(value)FIELD_PREP(GENMASK(19, 10),
value)
+#define AFBC_DEF_COLOR_V(value)FIELD_PREP(GENMASK(9, 0), value)
+
+/* AFBC_CONV_CTRL */
+#define AFBC_CONV_LBUF_LEN(value) FIELD_PREP(GENMASK(11, 0), value)
+
+/* AFBC_LBUF_DEPTH */
+#define AFBC_DEC_LBUF_DEPTH(value) FIELD_PREP(GENMASK(27, 16), value)
+#define AFBC_MIF_LBUF_DEPTH(value) FIELD_PREP(GENMASK(11, 0), value)
+
+/* AFBC_OUT_XSCOPE/AFBC_SIZE_OUT */
+#define AFBC_HSIZE_OUT(value) FIELD_PREP(GENMASK(28, 16), value)
+#define AFBC_VSIZE_OUT(value) FIELD_PREP(GENMASK(12, 0), value)
+#define AFBC_OUT_HORZ_BGN(value) FIELD_PREP(GENMASK(28, 16), value)
+#define AFBC_OUT_HORZ_END(value) FIELD_PREP(GENMASK(12, 0), value)
+
+/* AFBC_OUT_YSCOPE */
+#define AFBC_OUT_VERT_BGN(value) FIELD_PREP(GENMASK(28, 16), value)
+#define AFBC_OUT_VERT_END(value) FIELD_PREP(GENMASK(12, 0), value)
+
+/* AFBC_VD_CFMT_CTRL */
+#define AFBC_HORZ_RPT_PIXEL0 BIT(23)
+#define AFBC_HORZ_Y_C_RATIO(value) FIELD_PREP(GENMASK(22, 21), value)
[PATCH v4 7/8] drm/fourcc: amlogic: Add modifier definitions for the Scatter layout
Amlogic uses a proprietary lossless image compression protocol and format
for their hardware video codec accelerators, either video decoders or
video input encoders.
This introduces the Scatter Memory layout, means the header contains IOMMU
references to the compressed frames content to optimize memory access
and layout.
In this mode, only the header memory address is needed, thus the content
memory organization is tied to the current producer execution and cannot
be saved/dumped neither transferrable between Amlogic SoCs supporting this
modifier.
Tested-by: Kevin Hilman
Signed-off-by: Neil Armstrong
---
include/uapi/drm/drm_fourcc.h | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 84edc5d69613..b49f1d45e1b4 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -840,6 +840,19 @@ extern "C" {
*/
#define DRM_FORMAT_MOD_AMLOGIC_FBC_LAYOUT_BASIC(1ULL << 0)
+/*
+ * Amlogic FBC Scatter Memory layout
+ *
+ * Indicates the header contains IOMMU references to the compressed
+ * frames content to optimize memory access and layout.
+ *
+ * In this mode, only the header memory address is needed, thus the
+ * content memory organization is tied to the current producer
+ * execution and cannot be saved/dumped neither transferrable between
+ * Amlogic SoCs supporting this modifier.
+ */
+#define DRM_FORMAT_MOD_AMLOGIC_FBC_LAYOUT_SCATTER (2ULL << 0)
+
/*
* Amlogic FBC Layout Options
*/
@@ -852,7 +865,8 @@ extern "C" {
* memory.
*
* This mode reduces body layout to 3072 bytes per 64x32 superblock with
- * the basic layout.
+ * the basic layout and 3200 bytes per 64x32 superblock combined with
+ * the scatter layout.
*/
#define DRM_FORMAT_MOD_AMLOGIC_FBC_MEM_SAVING (1ULL << 8)
--
2.22.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 0/8] drm/meson: add support for Amlogic Video FBC
Amlogic uses a proprietary lossless image compression protocol and format for their hardware video codec accelerators, either video decoders or video input encoders. It considerably reduces memory bandwidth while writing and reading frames in memory. The underlying storage is considered to be 3 components, 8bit or 10-bit per component, YCbCr 420, single plane : - DRM_FORMAT_YUV420_8BIT - DRM_FORMAT_YUV420_10BIT This modifier will be notably added to DMA-BUF frames imported from the V4L2 Amlogic VDEC decoder. At least two layout are supported : - Basic: composed of a body and a header - Scatter: the buffer is filled with a IOMMU scatter table referring to the encoder current memory layout. This mode if more efficient in terms of memory allocation but frames are not dumpable and only valid during until the buffer is freed and back in control of the encoder At least two options are supported : - Memory saving: when the pixel bpp is 8b, the size of the superblock can be reduced, thus saving memory. This serie adds the missing register, updated the FBC decoder registers content to be committed by the crtc code. The Amlogic FBC has been tested with compressed content from the Amlogic HW VP9 decoder on S905X (GXL), S905D2 (G12A) and S905X3 (SM1) in 8bit (Scatter+Mem Saving on G12A/SM1, Mem Saving on GXL) and 10bit (Scatter on G12A/SM1, default on GXL). It's expected to work as-is on GXM and G12B SoCs. Changes since v3 at [3]: - added dropped fourcc patch for scatter - fixed build of last patch Changes since v2 at [2]: - Added "BASIC" layout and moved the SCATTER mode as layout, making BASIC and SCATTER layout exclusives - Moved the Memory Saving at bit 8 for options fields - Split fourcc and overlay patch to introduce basic, mem saving and then scatter in separate patches - Added comment about "transferability" of the buffers Changes since v1 at [1]: - s/VD1_AXI_SEL_AFB/VD1_AXI_SEL_AFBC/ into meson_registers.h [1] https://patchwork.freedesktop.org/series/73722/#rev1 [2] https://patchwork.freedesktop.org/series/73722/#rev2 Neil Armstrong (8): drm/fourcc: Add modifier definitions for describing Amlogic Video Framebuffer Compression drm/meson: add Amlogic Video FBC registers drm/meson: overlay: setup overlay for Amlogic FBC drm/meson: crtc: handle commit of Amlogic FBC frames drm/fourcc: amlogic: Add modifier definitions for Memory Saving option drm/meson: overlay: setup overlay for Amlogic FBC Memory Saving mode drm/fourcc: amlogic: Add modifier definitions for the Scatter layout drm/meson: overlay: setup overlay for Amlogic FBC Scatter Memory layout drivers/gpu/drm/meson/meson_crtc.c | 118 --- drivers/gpu/drm/meson/meson_drv.h | 16 ++ drivers/gpu/drm/meson/meson_overlay.c | 257 +++- drivers/gpu/drm/meson/meson_registers.h | 22 ++ include/uapi/drm/drm_fourcc.h | 66 ++ 5 files changed, 441 insertions(+), 38 deletions(-) -- 2.22.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 2/8] drm/meson: add Amlogic Video FBC registers
Add the registers of the VPU VD1 Amlogic FBC decoder module, and routing register. Tested-by: Kevin Hilman Signed-off-by: Neil Armstrong --- drivers/gpu/drm/meson/meson_registers.h | 22 ++ 1 file changed, 22 insertions(+) diff --git a/drivers/gpu/drm/meson/meson_registers.h b/drivers/gpu/drm/meson/meson_registers.h index 8ea00546cd4e..08631fdfe4b9 100644 --- a/drivers/gpu/drm/meson/meson_registers.h +++ b/drivers/gpu/drm/meson/meson_registers.h @@ -144,10 +144,15 @@ #defineVIU_SW_RESET_OSD1 BIT(0) #define VIU_MISC_CTRL0 0x1a06 #defineVIU_CTRL0_VD1_AFBC_MASK 0x17 +#defineVIU_CTRL0_AFBC_TO_VD1 BIT(20) #define VIU_MISC_CTRL1 0x1a07 #defineMALI_AFBC_MISC GENMASK(15, 8) #define D2D3_INTF_LENGTH 0x1a08 #define D2D3_INTF_CTRL0 0x1a09 +#define VD1_AFBCD0_MISC_CTRL 0x1a0a +#defineVD1_AXI_SEL_AFBC(1 << 12) +#defineAFBC_VD1_SEL(1 << 10) +#define VD2_AFBCD1_MISC_CTRL 0x1a0b #define VIU_OSD1_CTRL_STAT 0x1a10 #defineVIU_OSD1_OSD_BLK_ENABLE BIT(0) #defineVIU_OSD1_OSD_MEM_MODE_LINEARBIT(2) @@ -365,6 +370,23 @@ #define VIU_OSD1_OETF_LUT_ADDR_PORT 0x1add #define VIU_OSD1_OETF_LUT_DATA_PORT 0x1ade #define AFBC_ENABLE 0x1ae0 +#define AFBC_MODE 0x1ae1 +#define AFBC_SIZE_IN 0x1ae2 +#define AFBC_DEC_DEF_COLOR 0x1ae3 +#define AFBC_CONV_CTRL 0x1ae4 +#define AFBC_LBUF_DEPTH 0x1ae5 +#define AFBC_HEAD_BADDR 0x1ae6 +#define AFBC_BODY_BADDR 0x1ae7 +#define AFBC_SIZE_OUT 0x1ae8 +#define AFBC_OUT_YSCOPE 0x1ae9 +#define AFBC_STAT 0x1aea +#define AFBC_VD_CFMT_CTRL 0x1aeb +#define AFBC_VD_CFMT_W 0x1aec +#define AFBC_MIF_HOR_SCOPE 0x1aed +#define AFBC_MIF_VER_SCOPE 0x1aee +#define AFBC_PIXEL_HOR_SCOPE 0x1aef +#define AFBC_PIXEL_VER_SCOPE 0x1af0 +#define AFBC_VD_CFMT_H 0x1af1 /* vpp */ #define VPP_DUMMY_DATA 0x1d00 -- 2.22.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 1/8] drm/fourcc: Add modifier definitions for describing Amlogic Video Framebuffer Compression
Amlogic uses a proprietary lossless image compression protocol and format
for their hardware video codec accelerators, either video decoders or
video input encoders.
It considerably reduces memory bandwidth while writing and reading
frames in memory.
The underlying storage is considered to be 3 components, 8bit or 10-bit
per component, YCbCr 420, single plane :
- DRM_FORMAT_YUV420_8BIT
- DRM_FORMAT_YUV420_10BIT
This modifier will be notably added to DMA-BUF frames imported from the V4L2
Amlogic VDEC decoder.
This introduces the basic layout composed of:
- a body content organized in 64x32 superblocks with 4096 bytes per
superblock in default mode.
- a 32 bytes per 128x64 header block
This layout is tranferrable between Amlogic SoCs supporting this modifier.
Tested-by: Kevin Hilman
Signed-off-by: Neil Armstrong
---
include/uapi/drm/drm_fourcc.h | 30 ++
1 file changed, 30 insertions(+)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 8bc0b31597d8..6564813d2f7a 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -309,6 +309,7 @@ extern "C" {
#define DRM_FORMAT_MOD_VENDOR_BROADCOM 0x07
#define DRM_FORMAT_MOD_VENDOR_ARM 0x08
#define DRM_FORMAT_MOD_VENDOR_ALLWINNER 0x09
+#define DRM_FORMAT_MOD_VENDOR_AMLOGIC 0x0a
/* add more to the end as needed */
@@ -804,6 +805,35 @@ extern "C" {
*/
#define DRM_FORMAT_MOD_ALLWINNER_TILED fourcc_mod_code(ALLWINNER, 1)
+/*
+ * Amlogic Video Framebuffer Compression modifiers
+ *
+ * Amlogic uses a proprietary lossless image compression protocol and format
+ * for their hardware video codec accelerators, either video decoders or
+ * video input encoders.
+ *
+ * It considerably reduces memory bandwidth while writing and reading
+ * frames in memory.
+ *
+ * The underlying storage is considered to be 3 components, 8bit or 10-bit
+ * per component YCbCr 420, single plane :
+ * - DRM_FORMAT_YUV420_8BIT
+ * - DRM_FORMAT_YUV420_10BIT
+ */
+#define DRM_FORMAT_MOD_AMLOGIC_FBC(__modes) fourcc_mod_code(AMLOGIC, __modes)
+
+/*
+ * Amlogic FBC Basic Layout
+ *
+ * The basic layout is composed of:
+ * - a body content organized in 64x32 superblocks with 4096 bytes per
+ * superblock in default mode.
+ * - a 32 bytes per 128x64 header block
+ *
+ * This layout is transferrable between Amlogic SoCs supporting this modifier.
+ */
+#define DRM_FORMAT_MOD_AMLOGIC_FBC_LAYOUT_BASIC(1ULL << 0)
+
#if defined(__cplusplus)
}
#endif
--
2.22.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 8/8] drm/meson: overlay: setup overlay for Amlogic FBC Scatter Memory layout
Setup the Amlogic FBC decoder for the VD1 video overlay plane to use
read the FBC header as Scatter Memory layout reference.
Tested-by: Kevin Hilman
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/meson_overlay.c | 48 +--
1 file changed, 31 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_overlay.c
b/drivers/gpu/drm/meson/meson_overlay.c
index 8b9d4984b2a7..3c54135f53a0 100644
--- a/drivers/gpu/drm/meson/meson_overlay.c
+++ b/drivers/gpu/drm/meson/meson_overlay.c
@@ -487,6 +487,9 @@ static void meson_overlay_atomic_update(struct drm_plane
*plane,
AFBC_HOLD_LINE_NUM(8) |
AFBC_BURST_LEN(2);
+ if (fb->modifier & DRM_FORMAT_MOD_AMLOGIC_FBC_LAYOUT_SCATTER)
+ priv->viu.vd1_afbc_mode |= AFBC_SCATTER_MODE;
+
if (fb->modifier & DRM_FORMAT_MOD_AMLOGIC_FBC_MEM_SAVING)
priv->viu.vd1_afbc_mode |= AFBC_BLK_MEM_MODE;
@@ -675,23 +678,32 @@ static void meson_overlay_atomic_update(struct drm_plane
*plane,
}
if (priv->viu.vd1_afbc) {
- /* Default mode is 4k per superblock */
- unsigned long block_size = 4096;
- unsigned long body_size;
-
- /* 8bit mem saving mode is 3072bytes per superblock */
- if (priv->viu.vd1_afbc_mode & AFBC_BLK_MEM_MODE)
- block_size = 3072;
-
- body_size = (ALIGN(priv->viu.vd1_stride0, 64) / 64) *
- (ALIGN(priv->viu.vd1_height0, 32) / 32) *
- block_size;
-
- priv->viu.vd1_afbc_body_addr = priv->viu.vd1_addr0 >> 4;
-
- /* Header is after body content */
- priv->viu.vd1_afbc_head_addr = (priv->viu.vd1_addr0 +
- body_size) >> 4;
+ if (priv->viu.vd1_afbc_mode & AFBC_SCATTER_MODE) {
+ /*
+* In Scatter mode, the header contains the physical
+* body content layout, thus the body content
+* size isn't needed.
+*/
+ priv->viu.vd1_afbc_head_addr = priv->viu.vd1_addr0 >> 4;
+ priv->viu.vd1_afbc_body_addr = 0;
+ } else {
+ /* Default mode is 4k per superblock */
+ unsigned long block_size = 4096;
+ unsigned long body_size;
+
+ /* 8bit mem saving mode is 3072bytes per superblock */
+ if (priv->viu.vd1_afbc_mode & AFBC_BLK_MEM_MODE)
+ block_size = 3072;
+
+ body_size = (ALIGN(priv->viu.vd1_stride0, 64) / 64) *
+ (ALIGN(priv->viu.vd1_height0, 32) / 32) *
+ block_size;
+
+ priv->viu.vd1_afbc_body_addr = priv->viu.vd1_addr0 >> 4;
+ /* Header is after body content */
+ priv->viu.vd1_afbc_head_addr = (priv->viu.vd1_addr0 +
+ body_size) >> 4;
+ }
}
priv->viu.vd1_enabled = true;
@@ -771,6 +783,8 @@ static const uint32_t supported_drm_formats[] = {
};
static const uint64_t format_modifiers[] = {
+ DRM_FORMAT_MOD_AMLOGIC_FBC(DRM_FORMAT_MOD_AMLOGIC_FBC_LAYOUT_SCATTER |
+ DRM_FORMAT_MOD_AMLOGIC_FBC_MEM_SAVING),
DRM_FORMAT_MOD_AMLOGIC_FBC(DRM_FORMAT_MOD_AMLOGIC_FBC_LAYOUT_BASIC |
DRM_FORMAT_MOD_AMLOGIC_FBC_MEM_SAVING),
DRM_FORMAT_MOD_AMLOGIC_FBC(DRM_FORMAT_MOD_AMLOGIC_FBC_LAYOUT_BASIC),
--
2.22.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 6/8] drm/meson: overlay: setup overlay for Amlogic FBC Memory Saving mode
Setup the Amlogic FBC decoder for the VD1 video overlay plane to use
a different superblock size for the Memory Saving mode.
Tested-by: Kevin Hilman
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/meson_overlay.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_overlay.c
b/drivers/gpu/drm/meson/meson_overlay.c
index 51fa038ad5d7..8b9d4984b2a7 100644
--- a/drivers/gpu/drm/meson/meson_overlay.c
+++ b/drivers/gpu/drm/meson/meson_overlay.c
@@ -487,6 +487,9 @@ static void meson_overlay_atomic_update(struct drm_plane
*plane,
AFBC_HOLD_LINE_NUM(8) |
AFBC_BURST_LEN(2);
+ if (fb->modifier & DRM_FORMAT_MOD_AMLOGIC_FBC_MEM_SAVING)
+ priv->viu.vd1_afbc_mode |= AFBC_BLK_MEM_MODE;
+
priv->viu.vd1_afbc_en = 0x1600 | AFBC_DEC_ENABLE;
priv->viu.vd1_afbc_conv_ctrl = AFBC_CONV_LBUF_LEN(256);
@@ -672,12 +675,17 @@ static void meson_overlay_atomic_update(struct drm_plane
*plane,
}
if (priv->viu.vd1_afbc) {
+ /* Default mode is 4k per superblock */
+ unsigned long block_size = 4096;
unsigned long body_size;
- /* Default mode is 4k per superblock */
+ /* 8bit mem saving mode is 3072bytes per superblock */
+ if (priv->viu.vd1_afbc_mode & AFBC_BLK_MEM_MODE)
+ block_size = 3072;
+
body_size = (ALIGN(priv->viu.vd1_stride0, 64) / 64) *
(ALIGN(priv->viu.vd1_height0, 32) / 32) *
- 4096;
+ block_size;
priv->viu.vd1_afbc_body_addr = priv->viu.vd1_addr0 >> 4;
@@ -763,6 +771,8 @@ static const uint32_t supported_drm_formats[] = {
};
static const uint64_t format_modifiers[] = {
+ DRM_FORMAT_MOD_AMLOGIC_FBC(DRM_FORMAT_MOD_AMLOGIC_FBC_LAYOUT_BASIC |
+ DRM_FORMAT_MOD_AMLOGIC_FBC_MEM_SAVING),
DRM_FORMAT_MOD_AMLOGIC_FBC(DRM_FORMAT_MOD_AMLOGIC_FBC_LAYOUT_BASIC),
DRM_FORMAT_MOD_LINEAR,
DRM_FORMAT_MOD_INVALID,
--
2.22.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 0/7] drm/meson: add support for Amlogic Video FBC
On 24/03/2020 15:20, Neil Armstrong wrote: > Amlogic uses a proprietary lossless image compression protocol and format > for their hardware video codec accelerators, either video decoders or > video input encoders. > > It considerably reduces memory bandwidth while writing and reading > frames in memory. > > The underlying storage is considered to be 3 components, 8bit or 10-bit > per component, YCbCr 420, single plane : > - DRM_FORMAT_YUV420_8BIT > - DRM_FORMAT_YUV420_10BIT > > This modifier will be notably added to DMA-BUF frames imported from the V4L2 > Amlogic VDEC decoder. > > At least two layout are supported : > - Basic: composed of a body and a header > - Scatter: the buffer is filled with a IOMMU scatter table referring > to the encoder current memory layout. This mode if more efficient in terms > of memory allocation but frames are not dumpable and only valid during until > the buffer is freed and back in control of the encoder > > At least two options are supported : > - Memory saving: when the pixel bpp is 8b, the size of the superblock can > be reduced, thus saving memory. > > This serie adds the missing register, updated the FBC decoder registers > content to be committed by the crtc code. > > The Amlogic FBC has been tested with compressed content from the Amlogic > HW VP9 decoder on S905X (GXL), S905D2 (G12A) and S905X3 (SM1) in 8bit > (Scatter+Mem Saving on G12A/SM1, Mem Saving on GXL) and 10bit > (Scatter on G12A/SM1, default on GXL). > > It's expected to work as-is on GXM and G12B SoCs. > > Changes since v2 at [2]: > - Added "BASIC" layout and moved the SCATTER mode as layout, making > BASIC and SCATTER layout exclusives > - Moved the Memory Saving at bit 8 for options fields > - Split fourcc and overlay patch to introduce basic, mem saving and then > scatter in separate patches > - Added comment about "transferability" of the buffers > > Changes since v1 at [1]: > - s/VD1_AXI_SEL_AFB/VD1_AXI_SEL_AFBC/ into meson_registers.h > > [1] https://patchwork.freedesktop.org/series/73722/#rev1 > [2] https://patchwork.freedesktop.org/series/73722/#rev2 > > Neil Armstrong (7): > drm/fourcc: Add modifier definitions for describing Amlogic Video > Framebuffer Compression > drm/meson: add Amlogic Video FBC registers > drm/meson: overlay: setup overlay for Amlogic FBC > drm/meson: crtc: handle commit of Amlogic FBC frames > drm/fourcc: amlogic: Add modifier definitions for Memory Saving option > drm/meson: overlay: setup overlay for Amlogic FBC Memory Saving mode > drm/meson: overlay: setup overlay for Amlogic FBC Scatter Memory > layout > > drivers/gpu/drm/meson/meson_crtc.c | 118 --- > drivers/gpu/drm/meson/meson_drv.h | 16 ++ > drivers/gpu/drm/meson/meson_overlay.c | 257 +++- > drivers/gpu/drm/meson/meson_registers.h | 22 ++ > include/uapi/drm/drm_fourcc.h | 66 ++ > 5 files changed, 441 insertions(+), 38 deletions(-) > Please ignore this serie, v4 has been sent. Neil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 5/8] drm/fourcc: amlogic: Add modifier definitions for Memory Saving option
Amlogic uses a proprietary lossless image compression protocol and format
for their hardware video codec accelerators, either video decoders or
video input encoders.
An option exist changing the layout superblock size to save memory when
using 8bit components pixels size.
The layout options starts at the 8th bit, keeping the first 8bits of the
modifiers bits to define the layout.
Tested-by: Kevin Hilman
Signed-off-by: Neil Armstrong
---
include/uapi/drm/drm_fourcc.h | 22 ++
1 file changed, 22 insertions(+)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 6564813d2f7a..84edc5d69613 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -819,6 +819,12 @@ extern "C" {
* per component YCbCr 420, single plane :
* - DRM_FORMAT_YUV420_8BIT
* - DRM_FORMAT_YUV420_10BIT
+ *
+ * The first 8 bits of the mode defines the layout, then the following 8 bits
+ * defined the options changing the layout.
+ *
+ * Not all combinations are valid, and different SoCs may support different
+ * combinations of layout and options.
*/
#define DRM_FORMAT_MOD_AMLOGIC_FBC(__modes) fourcc_mod_code(AMLOGIC, __modes)
@@ -834,6 +840,22 @@ extern "C" {
*/
#define DRM_FORMAT_MOD_AMLOGIC_FBC_LAYOUT_BASIC(1ULL << 0)
+/*
+ * Amlogic FBC Layout Options
+ */
+
+/*
+ * Amlogic FBC Memory Saving mode
+ *
+ * Indicates the storage is packed when pixel size is multiple of word
+ * boudaries, i.e. 8bit should be stored in this mode to save allocation
+ * memory.
+ *
+ * This mode reduces body layout to 3072 bytes per 64x32 superblock with
+ * the basic layout.
+ */
+#define DRM_FORMAT_MOD_AMLOGIC_FBC_MEM_SAVING (1ULL << 8)
+
#if defined(__cplusplus)
}
#endif
--
2.22.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 4/8] drm/meson: crtc: handle commit of Amlogic FBC frames
Since the VD1 Amlogic FBC decoder is now configured by the overlay driver,
commit the right registers to decode the Amlogic FBC frame.
Tested-by: Kevin Hilman
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/meson_crtc.c | 118 +
1 file changed, 88 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_crtc.c
b/drivers/gpu/drm/meson/meson_crtc.c
index e66b6271ff58..d6dcfd654e9c 100644
--- a/drivers/gpu/drm/meson/meson_crtc.c
+++ b/drivers/gpu/drm/meson/meson_crtc.c
@@ -291,6 +291,10 @@ static void meson_crtc_enable_vd1(struct meson_drm *priv)
VPP_VD1_PREBLEND | VPP_VD1_POSTBLEND |
VPP_COLOR_MNG_ENABLE,
priv->io_base + _REG(VPP_MISC));
+
+ writel_bits_relaxed(VIU_CTRL0_AFBC_TO_VD1,
+ priv->viu.vd1_afbc ? VIU_CTRL0_AFBC_TO_VD1 : 0,
+ priv->io_base + _REG(VIU_MISC_CTRL0));
}
static void meson_g12a_crtc_enable_vd1(struct meson_drm *priv)
@@ -300,6 +304,10 @@ static void meson_g12a_crtc_enable_vd1(struct meson_drm
*priv)
VD_BLEND_POSTBLD_SRC_VD1 |
VD_BLEND_POSTBLD_PREMULT_EN,
priv->io_base + _REG(VD1_BLEND_SRC_CTRL));
+
+ writel_relaxed(priv->viu.vd1_afbc ?
+ (VD1_AXI_SEL_AFBC | AFBC_VD1_SEL) : 0,
+ priv->io_base + _REG(VD1_AFBCD0_MISC_CTRL));
}
void meson_crtc_irq(struct meson_drm *priv)
@@ -383,36 +391,86 @@ void meson_crtc_irq(struct meson_drm *priv)
/* Update the VD1 registers */
if (priv->viu.vd1_enabled && priv->viu.vd1_commit) {
- switch (priv->viu.vd1_planes) {
- case 3:
- meson_canvas_config(priv->canvas,
- priv->canvas_id_vd1_2,
- priv->viu.vd1_addr2,
- priv->viu.vd1_stride2,
- priv->viu.vd1_height2,
- MESON_CANVAS_WRAP_NONE,
- MESON_CANVAS_BLKMODE_LINEAR,
- MESON_CANVAS_ENDIAN_SWAP64);
- /* fallthrough */
- case 2:
- meson_canvas_config(priv->canvas,
- priv->canvas_id_vd1_1,
- priv->viu.vd1_addr1,
- priv->viu.vd1_stride1,
- priv->viu.vd1_height1,
- MESON_CANVAS_WRAP_NONE,
- MESON_CANVAS_BLKMODE_LINEAR,
- MESON_CANVAS_ENDIAN_SWAP64);
- /* fallthrough */
- case 1:
- meson_canvas_config(priv->canvas,
- priv->canvas_id_vd1_0,
- priv->viu.vd1_addr0,
- priv->viu.vd1_stride0,
- priv->viu.vd1_height0,
- MESON_CANVAS_WRAP_NONE,
- MESON_CANVAS_BLKMODE_LINEAR,
- MESON_CANVAS_ENDIAN_SWAP64);
+ if (priv->viu.vd1_afbc) {
+ writel_relaxed(priv->viu.vd1_afbc_head_addr,
+ priv->io_base +
+ _REG(AFBC_HEAD_BADDR));
+ writel_relaxed(priv->viu.vd1_afbc_body_addr,
+ priv->io_base +
+ _REG(AFBC_BODY_BADDR));
+ writel_relaxed(priv->viu.vd1_afbc_en,
+ priv->io_base +
+ _REG(AFBC_ENABLE));
+ writel_relaxed(priv->viu.vd1_afbc_mode,
+ priv->io_base +
+ _REG(AFBC_MODE));
+ writel_relaxed(priv->viu.vd1_afbc_size_in,
+ priv->io_base +
+ _REG(AFBC_SIZE_IN));
+ writel_relaxed(priv->viu.vd1_afbc_dec_def_color,
+ priv->io_base +
+ _REG(AFBC_DEC_DEF_COLOR));
+ writel_relaxed(priv->viu.vd1_afbc_conv_ctrl,
+ priv->io_base +
+ _REG(AFBC_CONV_CTRL));
+ writel_relaxed(priv->viu.vd1_afbc_size_out,
+ priv->io_base +
+
[PATCH] drm/panel: boe-tv101wum-n16: extend LCD support list
Add entries for BOE TV105WUM-NW0 10.5" WUXGA TFT LCD panel.
Signed-off-by: David Lu
Change-Id: I5b1cef259de5fb498220dcc47baa035083c41667
---
.../gpu/drm/panel/panel-boe-tv101wum-nl6.c| 31 +++
1 file changed, 31 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
index 48a164257d18..f89861c8598a 100644
--- a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
+++ b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
@@ -696,6 +696,34 @@ static const struct panel_desc auo_b101uan08_3_desc = {
.init_cmds = auo_b101uan08_3_init_cmd,
};
+static const struct drm_display_mode boe_tv105wum_nw0_default_mode = {
+ .clock = 159260,
+ .hdisplay = 1200,
+ .hsync_start = 1200 + 80,
+ .hsync_end = 1200 + 80 + 24,
+ .htotal = 1200 + 80 + 24 + 60,
+ .vdisplay = 1920,
+ .vsync_start = 1920 + 10,
+ .vsync_end = 1920 + 10 + 2,
+ .vtotal = 1920 + 10 + 2 + 14,
+ .vrefresh = 60,
+ .type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED,
+};
+
+static const struct panel_desc boe_tv105wum_nw0_desc = {
+ .modes = _tv105wum_nw0_default_mode,
+ .bpc = 8,
+ .size = {
+ .width_mm = 141,
+ .height_mm = 226,
+ },
+ .lanes = 4,
+ .format = MIPI_DSI_FMT_RGB888,
+ .mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_SYNC_PULSE |
+ MIPI_DSI_MODE_LPM,
+ .init_cmds = boe_init_cmd,
+};
+
static int boe_panel_get_modes(struct drm_panel *panel,
struct drm_connector *connector)
{
@@ -834,6 +862,9 @@ static const struct of_device_id boe_of_match[] = {
{ .compatible = "auo,b101uan08.3",
.data = _b101uan08_3_desc
},
+ { .compatible = "boe,tv105wum-nw0",
+ .data = _tv105wum_nw0_desc
+ },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, boe_of_match);
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] dt-bindings: boe, tv101wum-n16: Add compatible for boe tv105wum-nw0.
Add bindings documentation for BOE TV105WUM-NW0 10.5" WUXGA TFT LCD panel. Signed-off-by: David Lu Change-Id: I450c0e52aae080728d4794bdffc50bb0d2f39f40 --- .../devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml b/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml index 740213459134..7f5df5851017 100644 --- a/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml +++ b/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml @@ -24,6 +24,8 @@ properties: - boe,tv101wum-n53 # AUO B101UAN08.3 10.1" WUXGA TFT LCD panel - auo,b101uan08.3 +# BOE TV105WUM-NW0 10.5" WUXGA TFT LCD panel + - boe,tv105wum-nw0 reg: description: the virtual channel number of a DSI peripheral -- 2.24.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 hmm 7/9] mm/hmm: do not unconditionally set pfns when returning EBUSY
On Tue, Mar 24, 2020 at 08:37:46AM +0100, Christoph Hellwig wrote:
> On Mon, Mar 23, 2020 at 10:14:55PM -0300, Jason Gunthorpe wrote:
> > if (pte_none(pte)) {
> > required_fault = hmm_pte_need_fault(hmm_vma_walk, orig_pfn, 0);
> > if (required_fault)
> > goto fault;
> > + *pfn = range->values[HMM_PFN_NONE];
> > return 0;
> > }
> >
> > @@ -274,8 +274,10 @@ static int hmm_vma_handle_pte(struct mm_walk *walk,
> > unsigned long addr,
> > }
> >
> > required_fault = hmm_pte_need_fault(hmm_vma_walk, orig_pfn, 0);
> > - if (!required_fault)
> > + if (!required_fault) {
> > + *pfn = range->values[HMM_PFN_NONE];
> > return 0;
> > + }
>
> Maybe throw in a goto hole to consolidaste the set PFN and return
> 0 cases?
Then we have goto fault and goto none both ending in returns. I
generally prefer the goto labels to have a single return
The pte_unmap() before faulting makes this routine twisty and I
haven't thought of a good way to untwist it
Thanks,
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/4] drm: ipk: Add extensions for DW MIPI DSI Host driver
Add Synopsys DesignWare IPK specific extensions for Synopsys DesignWare
MIPI DSI Host driver.
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: David Airlie
Cc: Daniel Vetter
Cc: Gustavo Pimentel
Cc: Joao Pinto
Signed-off-by: Angelo Ribeiro
---
drivers/gpu/drm/ipk/Kconfig | 9 +
drivers/gpu/drm/ipk/Makefile | 2 +
drivers/gpu/drm/ipk/dw-mipi-dsi-ipk.c | 556 ++
3 files changed, 567 insertions(+)
create mode 100644 drivers/gpu/drm/ipk/dw-mipi-dsi-ipk.c
diff --git a/drivers/gpu/drm/ipk/Kconfig b/drivers/gpu/drm/ipk/Kconfig
index 1f87444..49819e5 100644
--- a/drivers/gpu/drm/ipk/Kconfig
+++ b/drivers/gpu/drm/ipk/Kconfig
@@ -11,3 +11,12 @@ config DRM_IPK
Enable support for the Synopsys DesignWare DRM DSI.
To compile this driver as a module, choose M here: the module
will be called ipk-drm.
+
+config DRM_IPK_DSI
+ tristate "Synopsys DesignWare IPK specific extensions for MIPI DSI"
+ depends on DRM_IPK
+ select DRM_DW_MIPI_DSI
+ help
+ Choose this option for Synopsys DesignWare IPK MIPI DSI support.
+ To compile this driver as a module, choose M here: the module
+ will be called dw-mipi-dsi-ipk.
diff --git a/drivers/gpu/drm/ipk/Makefile b/drivers/gpu/drm/ipk/Makefile
index 51d2774..c80503f 100644
--- a/drivers/gpu/drm/ipk/Makefile
+++ b/drivers/gpu/drm/ipk/Makefile
@@ -4,3 +4,5 @@ ipk-drm-y := \
dw-vpg.o
obj-$(CONFIG_DRM_IPK) += ipk-drm.o
+
+obj-$(CONFIG_DRM_IPK_DSI) += dw-mipi-dsi-ipk.o
diff --git a/drivers/gpu/drm/ipk/dw-mipi-dsi-ipk.c
b/drivers/gpu/drm/ipk/dw-mipi-dsi-ipk.c
new file mode 100644
index 000..070eccb
--- /dev/null
+++ b/drivers/gpu/drm/ipk/dw-mipi-dsi-ipk.c
@@ -0,0 +1,556 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019-2020 Synopsys, Inc. and/or its affiliates.
+ * Synopsys DesignWare MIPI DSI solution driver
+ *
+ * Author: Angelo Ribeiro
+ * Author: Luis Oliveira
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#define DW_DPHY_LPCLK_CTRL 0x94
+#define DW_DPHY_RSTZ 0xA0
+#define DW_DPHY_IF_CFG 0xA4
+#define DW_DPHY_ULPS_CTRL 0xA8
+#define DW_DPHY_TX_TRIGGERS0xAC
+#define DW_DPHY_STATUS 0xB0
+#define DW_DPHY_TST_CTRL0 0xB4
+#define DW_DPHY_TST_CTRL1 0xB8
+#define DW_GEN3_IF_TESTER 0x3c
+#define DW_GEN3_IF_SOC_PLL 0x48
+#define DW_GEN3_IF_SOC_PLL_EN 0x4C
+
+#define DW_12BITS_DPHY_RDY_L0 0x507
+#define DW_12BITS_DPHY_RDY_L1 0x707
+#define DW_12BITS_DPHY_RDY_L2 0x907
+#define DW_12BITS_DPHY_RDY_L3 0xB07
+
+#define DW_LANE_MIN_KBPS 8
+#define DW_LANE_MAX_KBPS 25
+#define DW_DPHY_DIV_UPPER_LIMIT8000
+#define DW_DPHY_DIV_LOWER_LIMIT2000
+#define DW_MIN_OUTPUT_FREQ 80
+#define DW_LPHS_TIM_TRANSIONS 0x40
+
+enum dw_glueiftester {
+ GLUE_LOGIC = 0x4,
+ RX_PHY = 0x2,
+ TX_PHY = 0x1,
+ RESET = 0x0,
+};
+
+struct dw_range_dphy {
+ u32 freq;
+ u8 hs_freq_range;
+ u32 osc_freq_target;
+} dw_range_gen3[] = {
+ { 80, 0x00, 0x3f }, { 90, 0x10, 0x3f }, { 100, 0x20, 0x3f },
+ { 110, 0x30, 0x39 }, { 120, 0x01, 0x39 }, { 130, 0x11, 0x39 },
+ { 140, 0x21, 0x39 }, { 150, 0x31, 0x39 }, { 160, 0x02, 0x39 },
+ { 170, 0x12, 0x2f }, { 180, 0x22, 0x2f }, { 190, 0x32, 0x2f },
+ { 205, 0x03, 0x2f }, { 220, 0x13, 0x29 }, { 235, 0x23, 0x29 },
+ { 250, 0x33, 0x29 }, { 275, 0x04, 0x29 }, { 300, 0x14, 0x29 },
+ { 325, 0x25, 0x29 }, { 350, 0x35, 0x1f }, { 400, 0x05, 0x1f },
+ { 450, 0x16, 0x19 }, { 500, 0x26, 0x19 }, { 550, 0x37, 0x19 },
+ { 600, 0x07, 0x19 }, { 650, 0x18, 0x19 }, { 700, 0x28, 0x0f },
+ { 750, 0x39, 0x0f }, { 800, 0x09, 0x0f }, { 850, 0x19, 0x0f },
+ { 900, 0x29, 0x09 }, { 950, 0x3a, 0x09 }, { 1000, 0x0a, 0x09 },
+ { 1050, 0x1a, 0x09 }, { 1100, 0x2a, 0x09 }, { 1150, 0x3b, 0x09 },
+ { 1200, 0x0b, 0x09 }, { 1250, 0x1b, 0x09 }, { 1300, 0x2b, 0x09 },
+ { 1350, 0x3c, 0x03 }, { 1400, 0x0c, 0x03 }, { 1450, 0x1c, 0x03 },
+ { 1500, 0x2c, 0x03 }, { 1550, 0x3d, 0x03 }, { 1600, 0x0d, 0x03 },
+ { 1650, 0x1d, 0x03 }, { 1700, 0x2e, 0x03 }, { 1750, 0x3e, 0x03 },
+ { 1800, 0x0e, 0x03 }, { 1850, 0x1e, 0x03 }, { 1900, 0x2f, 0x03 },
+ { 1950, 0x3f, 0x03 }, { 2000, 0x0f, 0x03 }, { 2050, 0x40, 0x03 },
+ { 2100, 0x41, 0x03 }, { 2150, 0x42, 0x03 }, { 2200, 0x43, 0x03 },
+ { 2250, 0x44, 0x03 }, { 2300, 0x45, 0x01 }, { 2350, 0x46, 0x01 },
+ { 2400, 0x47, 0x01 }, { 2450, 0x48, 0x01 }, { 2500, 0x49, 0x01 }
+};
+
+struct dw_dsi_ipk {
+ void __iomem *base;
+ void __iomem *base_phy;
+ struct clk *pllref_clk;
+ struct dw_mipi_dsi *dsi;
+ u32 lane_min_kbps;
+ u32 lane_max_kbps;
+ int range;
+ int in_div;
+ int loop_div;
+};
+
+#define dw_mipi_dsi_to_dw_dsi_ipk(target)
[PATCH -next] drm/amdgpu/uvd7: remove unnecessary conversion to bool
The conversion to bool is not needed, remove it.
Signed-off-by: Chen Zhou
---
drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c
b/drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c
index 0995378..20f10a5 100644
--- a/drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c
@@ -1694,7 +1694,7 @@ static int uvd_v7_0_set_clockgating_state(void *handle,
enum amd_clockgating_state state)
{
struct amdgpu_device *adev = (struct amdgpu_device *)handle;
- bool enable = (state == AMD_CG_STATE_GATE) ? true : false;
+ bool enable = (state == AMD_CG_STATE_GATE);
uvd_v7_0_set_bypass_mode(adev, enable);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 4/4] RFC: drm/sun4i: Process alpha channel of most bottom layer
Hi! Dne ponedeljek, 02. marec 2020 ob 11:31:38 CET je Roman Stratiienko napisal(a): > Allwinner display engine blender consists of 3 pipelined blending units. > > PIPE0->\ > BLD0-\ > PIPE1->/ BLD1-\ > PIPE2->--/ BLD2->OUT > PIPE3->/ > > This pipeline produces incorrect composition if PIPE0 buffer has alpha. I always thought that if bottom layer has alpha, it's blended with background color, which is set to opaque black. If that is not the case, can you solve this by changing blending formula located in BLD control registers (offsets 0x90, 0x94, 0x98 and 0x9c)? Best regards, Jernej > Correct solution is to add one more blending step and mix PIPE0 with > background, but it is not supported by the hardware. > > Use premultiplied alpha buffer of PIPE0 overlay channel as is. > In this case we got same effect as mixing PIPE0 with black background. > > Signed-off-by: Roman Stratiienko > > --- > > v4: > - Initial version, depends on other unmerged patches in the patchset. > --- > drivers/gpu/drm/sun4i/sun8i_ui_layer.c | 2 +- > drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/sun4i/sun8i_ui_layer.c > b/drivers/gpu/drm/sun4i/sun8i_ui_layer.c index dd6145f80c36..d94f4d8b9128 > 100644 > --- a/drivers/gpu/drm/sun4i/sun8i_ui_layer.c > +++ b/drivers/gpu/drm/sun4i/sun8i_ui_layer.c > @@ -106,7 +106,7 @@ static void sun8i_ui_layer_update_alpha(struct > sun8i_mixer *mixer, int channel, regmap_update_bits(mixer->engine.regs, > SUN8I_MIXER_BLEND_PREMULTIPLY(bld_base), > SUN8I_MIXER_BLEND_PREMULTIPLY_EN(zpos), > -SUN8I_MIXER_BLEND_PREMULTIPLY_EN(zpos)); > +zpos ? SUN8I_MIXER_BLEND_PREMULTIPLY_EN(zpos) : 0); > } > > static int sun8i_ui_layer_update_coord(struct sun8i_mixer *mixer, int > channel, diff --git a/drivers/gpu/drm/sun4i/sun8i_vi_layer.c > b/drivers/gpu/drm/sun4i/sun8i_vi_layer.c index e6d8a539614f..68a6843db4ab > 100644 > --- a/drivers/gpu/drm/sun4i/sun8i_vi_layer.c > +++ b/drivers/gpu/drm/sun4i/sun8i_vi_layer.c > @@ -108,7 +108,7 @@ static void sun8i_vi_layer_update_alpha(struct > sun8i_mixer *mixer, int channel, regmap_update_bits(mixer->engine.regs, > SUN8I_MIXER_BLEND_PREMULTIPLY(bld_base), > SUN8I_MIXER_BLEND_PREMULTIPLY_EN(zpos), > -(mixer->cfg->is_de3) ? > +(zpos != 0 && mixer->cfg->is_de3) ? > SUN8I_MIXER_BLEND_PREMULTIPLY_EN(zpos) : 0); > > } ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm: bridge: adv7511: Enable SPDIF DAI
From: Bogdan Togorean
ADV7511 support I2S or SPDIF as audio input interfaces. This commit
enable support for SPDIF.
Signed-off-by: Bogdan Togorean
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/bridge/adv7511/adv7511_audio.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c
b/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c
index a428185be2c1..1e9b128d229b 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c
@@ -119,6 +119,9 @@ int adv7511_hdmi_hw_params(struct device *dev, void *data,
audio_source = ADV7511_AUDIO_SOURCE_I2S;
i2s_format = ADV7511_I2S_FORMAT_LEFT_J;
break;
+ case HDMI_SPDIF:
+ audio_source = ADV7511_AUDIO_SOURCE_SPDIF;
+ break;
default:
return -EINVAL;
}
@@ -175,11 +178,21 @@ static int audio_startup(struct device *dev, void *data)
/* use Audio infoframe updated info */
regmap_update_bits(adv7511->regmap, ADV7511_REG_GC(1),
BIT(5), 0);
+ /* enable SPDIF receiver */
+ if (adv7511->audio_source == ADV7511_AUDIO_SOURCE_SPDIF)
+ regmap_update_bits(adv7511->regmap, ADV7511_REG_AUDIO_CONFIG,
+ BIT(7), BIT(7));
+
return 0;
}
static void audio_shutdown(struct device *dev, void *data)
{
+ struct adv7511 *adv7511 = dev_get_drvdata(dev);
+
+ if (adv7511->audio_source == ADV7511_AUDIO_SOURCE_SPDIF)
+ regmap_update_bits(adv7511->regmap, ADV7511_REG_AUDIO_CONFIG,
+ BIT(7), 0);
}
static int adv7511_hdmi_i2s_get_dai_id(struct snd_soc_component *component,
@@ -213,6 +226,7 @@ static const struct hdmi_codec_pdata codec_data = {
.ops = _codec_ops,
.max_i2s_channels = 2,
.i2s = 1,
+ .spdif = 1,
};
int adv7511_audio_init(struct device *dev, struct adv7511 *adv7511)
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/4] dt-bindings: display: Add IPK DSI subsystem bindings
Add dt-bindings for Synopsys DesignWare MIPI DSI Host and VPG (Video
Pattern Generator) support in the IPK display subsystem.
The Synopsys DesignWare IPK display video pipeline is composed by a DSI
controller (snps,dw-ipk-dsi) and a VPG (snps,dw-ipk-vpg) as DPI
stimulus. Typically is used the Raspberry Pi
(raspberrypi,7inch-touchscreen-panel) as DSI panel that requires a
I2C controller (snps,designware-i2c).
Cc: David Airlie
Cc: Daniel Vetter
Cc: Rob Herring
Cc: Mark Rutland
Signed-off-by: Angelo Ribeiro
---
.../bindings/display/snps,dw-ipk-dsi.yaml | 163 +
.../bindings/display/snps,dw-ipk-vpg.yaml | 77 ++
2 files changed, 240 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/snps,dw-ipk-dsi.yaml
create mode 100644
Documentation/devicetree/bindings/display/snps,dw-ipk-vpg.yaml
diff --git a/Documentation/devicetree/bindings/display/snps,dw-ipk-dsi.yaml
b/Documentation/devicetree/bindings/display/snps,dw-ipk-dsi.yaml
new file mode 100644
index 000..75e65ec
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/snps,dw-ipk-dsi.yaml
@@ -0,0 +1,163 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/snps,dw-ipk-dsi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Synopsys DesignWare IPK specific extensions for the Synopsys DSI host
+ controller.
+
+maintainers:
+ - Angelo Ribeiro
+
+description:
+ The Synopsys DesignWare IPK DSI controller uses the Synopsys DesignWare MIPI
+ DSI host controller.
+ For more info please refer to
+ Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt.
+
+properties:
+ compatible:
+const: snps,dw-ipk-dsi
+
+ reg:
+minItems: 2
+maxItems: 2
+items:
+ - description: DW MIPI DSI Host registers
+ - description: DW Phy registers
+
+ reg-names:
+items:
+ - const: dsi
+ - const: phy
+
+ clocks:
+minItems: 2
+maxItems: 3
+items:
+ - description: Peripheral clock
+ - description: PLL clock
+ - description: Pixel clock
+
+ clock-names:
+items:
+ - const: pclk
+ - const: ref
+ - const: px_clk
+
+ resets:
+maxItems: 1
+items:
+ - description: APB reset line
+
+ reset-names:
+items:
+ - const: apb
+
+ ports:
+type: object
+description:
+ A port node as defined in
+ Documentation/devicetree/bindings/media/video-interfaces.txt and
+ Documentation/devicetree/bindings/graph.txt.
+properties:
+ port@0:
+type: object
+description:
+ Input endpoint of the controller, connects to a DPI source.
+
+ port@1:
+type: object
+description:
+ Output endpoint of the controller, connects to a panel or a bridge
+ input port.
+
+patternProperties:
+ "^(panel|panel-dsi)@[0-9]$":
+type: object
+description:
+ A node containing the panel or bridge description as defined in
+ Documentation/devicetree/bindings/display/mipi-dsi-bus.txt.
+properties:
+ port:
+type: object
+description:
+ Panel or bridge port node connected to the DSI output port (port@1).
+
+ "#address-cells":
+const: 1
+
+ "#size-cells":
+const: 0
+
+required:
+ - "#address-cells"
+ - "#size-cells"
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - clock-names
+ - reset
+ - reset-names
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+dsi1: dw-ipk-dsi@0x02000 {
+compatible = "snps,dw-ipk-dsi";
+reg = <0x02000 0xfff>, <0x05000 0xfff>;
+reg-names = "dsi", "phy";
+clocks = <_clk>, <_clk>;
+clock-names = "pclk", "ref";
+resets = <_rst 1>;
+reset-names = "apb";
+
+#address-cells = <1>;
+#size-cells = <0>;
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+reg = <0>;
+dsi1_in: endpoint@0 {
+remote-endpoint = <_out>;
+};
+};
+
+port@1 {
+reg = <1>;
+dsi_out_port: endpoint {
+remote-endpoint = <_dsi_port>;
+};
+};
+};
+};
+
+i2c@0x01000 {
+compatible = "snps,designware-i2c";
+reg = <0x01000 0x100>;
+clock-frequency = <40>;
+clocks = <>;
+interrupts = <0>;
+resets = <_rst 0>;
+reset-names = "i2c";
+
+lcd@45 {
+compatible = "raspberrypi,7inch-touchscreen-panel";
+reg = <0x45>;
+
+port {
+panel_dsi_port: endpoint {
+remote-endpoint = <_out_port>;
+};
+};
+};
+};
+
+...
diff --git a/Documentation/devicetree/bindings/display/snps,dw-ipk-vpg.yaml
[PATCH 2/2] drm/msm/dpu: add support for pcc color block in dpu driver
This change adds support for color correction sub block
for SC7180 device.
Signed-off-by: Kalyan Thota
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 77 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 9 ++-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c| 49 +++-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.h| 33 ++-
4 files changed, 164 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index bf51341..156a997 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include
#include
@@ -20,6 +21,7 @@
#include "dpu_kms.h"
#include "dpu_hw_lm.h"
#include "dpu_hw_ctl.h"
+#include "dpu_hw_dspp.h"
#include "dpu_crtc.h"
#include "dpu_plane.h"
#include "dpu_encoder.h"
@@ -40,6 +42,9 @@
/* timeout in ms waiting for frame done */
#define DPU_CRTC_FRAME_DONE_TIMEOUT_MS 60
+#defineCONVERT_S3_15(val) \
+ (u64)val) & ~BIT_ULL(63)) >> 17) & GENMASK_ULL(17, 0))
+
static struct dpu_kms *_dpu_crtc_get_kms(struct drm_crtc *crtc)
{
struct msm_drm_private *priv = crtc->dev->dev_private;
@@ -422,6 +427,74 @@ static void _dpu_crtc_setup_lm_bounds(struct drm_crtc
*crtc,
drm_mode_debug_printmodeline(adj_mode);
}
+static void _dpu_crtc_get_pcc_coeff(struct drm_crtc_state *state,
+ struct dpu_hw_pcc_cfg *cfg)
+{
+ struct drm_color_ctm *ctm;
+
+ memset(cfg, 0, sizeof(struct dpu_hw_pcc_cfg));
+
+ ctm = (struct drm_color_ctm *)state->ctm->data;
+
+ if (!ctm)
+ return;
+
+ cfg->r.r = CONVERT_S3_15(ctm->matrix[0]);
+ cfg->g.r = CONVERT_S3_15(ctm->matrix[1]);
+ cfg->b.r = CONVERT_S3_15(ctm->matrix[2]);
+
+ cfg->r.g = CONVERT_S3_15(ctm->matrix[3]);
+ cfg->g.g = CONVERT_S3_15(ctm->matrix[4]);
+ cfg->b.g = CONVERT_S3_15(ctm->matrix[5]);
+
+ cfg->r.b = CONVERT_S3_15(ctm->matrix[6]);
+ cfg->g.b = CONVERT_S3_15(ctm->matrix[7]);
+ cfg->b.b = CONVERT_S3_15(ctm->matrix[8]);
+}
+
+static void _dpu_crtc_setup_cp_blocks(struct drm_crtc *crtc)
+{
+ struct drm_crtc_state *state = crtc->state;
+ struct dpu_crtc_state *cstate = to_dpu_crtc_state(crtc->state);
+ struct dpu_crtc_mixer *mixer = cstate->mixers;
+ struct dpu_hw_pcc_cfg cfg;
+ struct dpu_hw_ctl *ctl;
+ struct dpu_hw_mixer *lm;
+ struct dpu_hw_dspp *dspp;
+ int i;
+
+
+ if (!state->color_mgmt_changed)
+ return;
+
+ for (i = 0; i < cstate->num_mixers; i++) {
+ ctl = mixer[i].lm_ctl;
+ lm = mixer[i].hw_lm;
+ dspp = mixer[i].hw_dspp;
+
+ if (!dspp || !dspp->ops.setup_pcc)
+ continue;
+
+ if (!state->ctm) {
+ dspp->ops.setup_pcc(dspp, NULL);
+ } else {
+ _dpu_crtc_get_pcc_coeff(state, );
+ dspp->ops.setup_pcc(dspp, );
+ }
+
+ mixer[i].flush_mask |= ctl->ops.get_bitmask_dspp(ctl,
+ mixer[i].hw_dspp->idx);
+
+ /* stage config flush mask */
+ ctl->ops.update_pending_flush(ctl, mixer[i].flush_mask);
+
+ DPU_DEBUG("lm %d, ctl %d, flush mask 0x%x\n",
+ mixer[i].hw_lm->idx - DSPP_0,
+ ctl->idx - CTL_0,
+ mixer[i].flush_mask);
+ }
+}
+
static void dpu_crtc_atomic_begin(struct drm_crtc *crtc,
struct drm_crtc_state *old_state)
{
@@ -475,6 +548,8 @@ static void dpu_crtc_atomic_begin(struct drm_crtc *crtc,
_dpu_crtc_blend_setup(crtc);
+ _dpu_crtc_setup_cp_blocks(crtc);
+
/*
* PP_DONE irq is only used by command mode for now.
* It is better to request pending before FLUSH and START trigger
@@ -1317,6 +1392,8 @@ struct drm_crtc *dpu_crtc_init(struct drm_device *dev,
struct drm_plane *plane,
drm_crtc_helper_add(crtc, _crtc_helper_funcs);
+ drm_crtc_enable_color_mgmt(crtc, 0, true, 0);
+
/* save user friendly CRTC name for later */
snprintf(dpu_crtc->name, DPU_CRTC_NAME_SIZE, "crtc%u", crtc->base.id);
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index 19d065a..731b4fb 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -41,7 +41,7 @@
#define PINGPONG_SDM845_SPLIT_MASK \
(PINGPONG_SDM845_MASK | BIT(DPU_PINGPONG_TE2))
-#define DSPP_SC7180_MASK 0
+#define DSPP_SC7180_MASK BIT(DPU_DSPP_PCC)
#define DEFAULT_PIXEL_RAM_SIZE (50 * 1024)
#define DEFAULT_DPU_LINE_WIDTH 2048
@@ -339,12 +339,17 @@
/*
*
[PATCH 2/2] drm: bridge: adv7511: Extend list of audio sample rates
From: Bogdan Togorean ADV7511 support sample rates up to 192kHz. CTS and N parameters should be computed accordingly so this commit extend the list up to maximum supported sample rate. Signed-off-by: Bogdan Togorean --- drivers/gpu/drm/bridge/adv7511/adv7511_audio.c | 12 1 file changed, 12 insertions(+) diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c b/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c index 1e9b128d229b..13e8cee6e827 100644 --- a/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c @@ -27,6 +27,18 @@ static void adv7511_calc_cts_n(unsigned int f_tmds, unsigned int fs, case 48000: *n = 6144; break; + case 88200: + *n = 12544; + break; + case 96000: + *n = 12288; + break; + case 176400: + *n = 25088; + break; + case 192000: + *n = 24576; + break; } *cts = ((f_tmds * *n) / (128 * fs)) * 1000; -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/4] drm: Add support for IPK DSI Host Driver
This patch series adds support for the display subsystem in the Synopsys DesignWare IPK devices. The display pipeline is limited and does not have access to memory, the validation is done using a VPG (Video Pattern Generator), as DPI stimulus for the DW MIPI DSI Host. A Synopsys DesignWare MIPI DSI Host v1.40 is used in the IPK device, that so far, is fully compatible with the driver dw-mipi-dsi. To activate the VPG use the sysfs pattern variable, assigning values from 0 (shutdown) to 4. The usage of the VPG and the Synopsys DesignWare MIPI DSI Host internal video generator is mutually exclusive. The submission of this driver aims to be used as a work base for the submission of enhancements over the Synopsys DesignWare MIPI DSI Host. Angelo Ribeiro (4): dt-bindings: display: Add IPK DSI subsystem bindings drm: ipk: Add DRM driver for DesignWare IPK DSI drm: ipk: Add extensions for DW MIPI DSI Host driver MAINTAINERS: Add IPK MIPI DSI Host driver entry .../bindings/display/snps,dw-ipk-dsi.yaml | 163 ++ .../bindings/display/snps,dw-ipk-vpg.yaml | 77 +++ MAINTAINERS| 8 + drivers/gpu/drm/Kconfig| 2 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/ipk/Kconfig| 22 + drivers/gpu/drm/ipk/Makefile | 8 + drivers/gpu/drm/ipk/dw-drv.c | 189 +++ drivers/gpu/drm/ipk/dw-ipk.h | 30 ++ drivers/gpu/drm/ipk/dw-mipi-dsi-ipk.c | 556 drivers/gpu/drm/ipk/dw-vpg.c | 559 + drivers/gpu/drm/ipk/dw-vpg.h | 55 ++ 12 files changed, 1670 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/snps,dw-ipk-dsi.yaml create mode 100644 Documentation/devicetree/bindings/display/snps,dw-ipk-vpg.yaml create mode 100644 drivers/gpu/drm/ipk/Kconfig create mode 100644 drivers/gpu/drm/ipk/Makefile create mode 100644 drivers/gpu/drm/ipk/dw-drv.c create mode 100644 drivers/gpu/drm/ipk/dw-ipk.h create mode 100644 drivers/gpu/drm/ipk/dw-mipi-dsi-ipk.c create mode 100644 drivers/gpu/drm/ipk/dw-vpg.c create mode 100644 drivers/gpu/drm/ipk/dw-vpg.h -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 4/4] RFC: drm/sun4i: Process alpha channel of most bottom layer
On Mon, Mar 02, 2020 at 12:31:38PM +0200, Roman Stratiienko wrote: > Allwinner display engine blender consists of 3 pipelined blending units. > > PIPE0->\ > BLD0-\ > PIPE1->/ BLD1-\ > PIPE2->--/ BLD2->OUT > PIPE3->/ > > This pipeline produces incorrect composition if PIPE0 buffer has alpha. Why? What happens in that case? > Correct solution is to add one more blending step and mix PIPE0 with > background, but it is not supported by the hardware. > > Use premultiplied alpha buffer of PIPE0 overlay channel as is. > In this case we got same effect as mixing PIPE0 with black background. > > Signed-off-by: Roman Stratiienko > > --- > > v4: > - Initial version, depends on other unmerged patches in the patchset. > --- > drivers/gpu/drm/sun4i/sun8i_ui_layer.c | 2 +- > drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/sun4i/sun8i_ui_layer.c > b/drivers/gpu/drm/sun4i/sun8i_ui_layer.c > index dd6145f80c36..d94f4d8b9128 100644 > --- a/drivers/gpu/drm/sun4i/sun8i_ui_layer.c > +++ b/drivers/gpu/drm/sun4i/sun8i_ui_layer.c > @@ -106,7 +106,7 @@ static void sun8i_ui_layer_update_alpha(struct > sun8i_mixer *mixer, int channel, > regmap_update_bits(mixer->engine.regs, > SUN8I_MIXER_BLEND_PREMULTIPLY(bld_base), > SUN8I_MIXER_BLEND_PREMULTIPLY_EN(zpos), > -SUN8I_MIXER_BLEND_PREMULTIPLY_EN(zpos)); > +zpos ? SUN8I_MIXER_BLEND_PREMULTIPLY_EN(zpos) : 0); Can you really use the zpos here? What happens if the zpos doesn't match the pipe? Maxime signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/5] Add support for Topwise A721 tablet
Hi, On Fri, Mar 20, 2020 at 12:21:31PM +0100, Pascal Roeleven wrote: > This series add support for the Topwise A721 tablet and it's display. > It is an old tablet (around 2012) but it might be useful as reference > as the devicetree is pretty complete. It looks good to me for the last 2 patches, I'll wait for feedback from Thierry or Sam on the panel side. Maxime signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 hmm 2/9] mm/hmm: return the fault type from hmm_pte_need_fault()
On Tue, Mar 24, 2020 at 08:27:12AM +0100, Christoph Hellwig wrote:
> On Mon, Mar 23, 2020 at 10:14:50PM -0300, Jason Gunthorpe wrote:
> > +enum {
> > + HMM_NEED_FAULT = 1 << 0,
> > + HMM_NEED_WRITE_FAULT = HMM_NEED_FAULT | (1 << 1),
> > + HMM_NEED_ALL_BITS = HMM_NEED_FAULT | HMM_NEED_WRITE_FAULT,
>
> I have to say I find the compound version of HMM_NEED_WRITE_FAULT
> way harder to understand than the logic in the previous version,
> and would refer keeping separate bits here.
>
> Mostly beccause of statements like this:
>
> > + if ((required_fault & HMM_NEED_WRITE_FAULT) == HMM_NEED_WRITE_FAULT) {
>
> which seems rather weird.
Okay, I checked it over, and there is one weird statement above but
only one place that |'s them together, so it is overall simpler to
split the enum.
I'll keep the HMM_NEED_ALL_BITS, I think that purpose is clear enough.
Thanks,
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3] fbdev: s1d13xxxfb: add missed unregister_framebuffer in remove
The driver calls register_framebuffer() in probe but does not call
unregister_framebuffer() in remove.
Rename current remove to __s1d13xxxfb_remove() for error handler.
Then add a new remove to call unregister_framebuffer().
Signed-off-by: Chuhong Yuan
---
Changes in v3:
- Fix code style.
- Set __s1d13xxxfb_remove() to return void.
- Remove redundant check for info.
drivers/video/fbdev/s1d13xxxfb.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/video/fbdev/s1d13xxxfb.c b/drivers/video/fbdev/s1d13xxxfb.c
index 8048499e398d..d51ef7619115 100644
--- a/drivers/video/fbdev/s1d13xxxfb.c
+++ b/drivers/video/fbdev/s1d13xxxfb.c
@@ -721,9 +721,7 @@ static void s1d13xxxfb_fetch_hw_state(struct fb_info *info)
xres, yres, xres_virtual, yres_virtual, is_color, is_dual,
is_tft);
}
-
-static int
-s1d13xxxfb_remove(struct platform_device *pdev)
+static void __s1d13xxxfb_remove(struct platform_device *pdev)
{
struct fb_info *info = platform_get_drvdata(pdev);
struct s1d13xxxfb_par *par = NULL;
@@ -749,9 +747,18 @@ s1d13xxxfb_remove(struct platform_device *pdev)
pdev->resource[0].end - pdev->resource[0].start +1);
release_mem_region(pdev->resource[1].start,
pdev->resource[1].end - pdev->resource[1].start +1);
+}
+
+static int s1d13xxxfb_remove(struct platform_device *pdev)
+{
+ struct fb_info *info = platform_get_drvdata(pdev);
+
+ unregister_framebuffer(info);
+ __s1d13xxxfb_remove(pdev);
return 0;
}
+
static int s1d13xxxfb_probe(struct platform_device *pdev)
{
struct s1d13xxxfb_par *default_par;
@@ -895,7 +902,7 @@ static int s1d13xxxfb_probe(struct platform_device *pdev)
return 0;
bail:
- s1d13xxxfb_remove(pdev);
+ __s1d13xxxfb_remove(pdev);
return ret;
}
--
2.25.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 3/4] drm/sun4i: Add support for premulti/coverage blending mode handling
Hi!
Dne ponedeljek, 02. marec 2020 ob 11:31:37 CET je Roman Stratiienko
napisal(a):
> Argument:
>
> All information below is author's understanding of underlying processes.
> This information was obtained from DE2.0-3.0 datasheet analysis and
> analysis of different DRM driver source code and commit messages.
>
> Input buffers could have 2 ways of holding pixel alpha channel value.
> 1. Coverage means that in case of transparency - only alpha channel changes.
> Example of 50% transparent white pixel: R=0xff B=0xff B=0xff A=0x7f
>
> 2. Premultiply means that RGB pixel values should be dimmed proportional to
>alpha channel value. Alpha channel value has also to be set in this case.
> Example of 50% transparent white pixel: R=0x7f B=0x7f B=0x7f A=0x7f
>
> Userspace informs DRM/KMS which blending type frame buffer uses with
> 'pixel blend mode' property.
>
> Allwinner DE2.0 and DE3.0 have 2 block of image processing:
> Overlay and Blending. Both should aware of blending type are used in the
> buffer.
>
> Overlay block uses this information to:
> 1. Unify blending types if more then 1 overlay channel are used. It can
> unify it only as premultiplied by converting coverage to premultiplied.
> 2. Calculate correct pixel value in case of applying plane alpha.
>For coverage alpha only alpha channel should be affected:
> [Ro=Ri, Go=Gi, Bo=Bi, Ao=Ai*AGlobal]
>For premultiplied alpha all 4 channels should be affected:
> [Ro=Ri*AGlobal, Go=Gi*AGlobal, Bo=Bi*AGlobal, Ao=Ai*AGlobal]
>
> Blending functional block should aware of blending type each pipe
> channel uses. Otherwise image can't blend correctly.
>
> In case we've specified premultiplied format for blending PIPE0, blender
> converts premultiplied RGB values to original (divides by normalized Alpha).
> In case for some reason pixel value after division exceeds 0xff, blender
> clamps it to 0xff. [Was discovered in experimental way]
> If image that passed through PIPE1-3 restored to coverage before mixing or
> used in premultiplied form still require testing and out of scope of this
> patch.
>
> Implementation:
>
> 1. Add blend property to UI channel
> 2. Add blend property to VI channel in case of DE3.0 used
> 3. Make all DE2.0 UI and DE3.0 VI overlay channels to use premultiply
> format. Mark all blending pipes as premultiply except DE2.0 VI plane.
> 4. If DRM plane uses coverage blending format, set blending mode register
>to convert it to premultiply.
Regarding 3 and 4 - do we really need to convert everything to premultiply?
Currently only one overlay is used in each channel, so there is no need to
convert coverage to premultiply if I understand datasheet correctly. Just mark
it accordingly in BLD premultiply control register.
>
> Signed-off-by: Roman Stratiienko
>
> --
>
> v4:
> - Initial version (Depends on unmerged patches from patchset)
> ---
> drivers/gpu/drm/sun4i/sun8i_mixer.h| 2 ++
> drivers/gpu/drm/sun4i/sun8i_ui_layer.c | 33 ++-
> drivers/gpu/drm/sun4i/sun8i_ui_layer.h | 5
> drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 36 +-
> drivers/gpu/drm/sun4i/sun8i_vi_layer.h | 5
> 5 files changed, 69 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.h
> b/drivers/gpu/drm/sun4i/sun8i_mixer.h index 915479cc3077..8a18372938d5
> 100644
> --- a/drivers/gpu/drm/sun4i/sun8i_mixer.h
> +++ b/drivers/gpu/drm/sun4i/sun8i_mixer.h
> @@ -70,6 +70,8 @@
> #define SUN8I_MIXER_BLEND_ROUTE_PIPE_MSK(n) (0xf << ((n) << 2))
> #define SUN8I_MIXER_BLEND_ROUTE_PIPE_SHIFT(n)((n) << 2)
>
> +#define SUN8I_MIXER_BLEND_PREMULTIPLY_EN(pipe) BIT(pipe)
> +
> #define SUN8I_MIXER_BLEND_OUTCTL_INTERLACED BIT(1)
>
> #define SUN50I_MIXER_BLEND_CSC_CTL_EN(ch)BIT(ch)
> diff --git a/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
> b/drivers/gpu/drm/sun4i/sun8i_ui_layer.c index 5278032567a3..dd6145f80c36
> 100644
> --- a/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
> +++ b/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
> @@ -73,10 +73,12 @@ static void sun8i_ui_layer_enable(struct sun8i_mixer
> *mixer, int channel, }
>
> static void sun8i_ui_layer_update_alpha(struct sun8i_mixer *mixer, int
> channel, -int overlay, struct
drm_plane *plane)
> + int overlay, struct
drm_plane *plane,
> + unsigned int zpos)
> {
> - u32 mask, val, ch_base;
> + u32 mask, val, ch_base, bld_base;
>
> + bld_base = sun8i_blender_base(mixer);
> ch_base = sun8i_channel_base(mixer, channel);
>
> mask = SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA_MODE_MASK |
> @@ -84,13 +86,27 @@ static void sun8i_ui_layer_update_alpha(struct
> sun8i_mixer *mixer, int channel,
>
> val = SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA(plane->state->alpha >>
8);
>
> - val |= (plane->state->alpha == DRM_BLEND_ALPHA_OPAQUE) ?
> -
[PATCH v4 0/3] drm: Add support for Chrontel CH7033 VGA/DVI Encoder
Hi, chained to this message is another spin of a driver for CH7033. Only cosmetic changes since the previous version [1]. Please take a look. [1] https://lore.kernel.org/lkml/20200314101627.336939-1-lkund...@v3.sk/ Thanks, Lubo ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 3/3] drm/bridge: chrontel-ch7033: Add a new driver
This is a driver for video encoder with VGA and DVI/HDMI outputs.
There is no documentation for the chip -- the operation was guessed from
what was sniffed on a Dell Wyse 3020 ThinOS terminal, the register names
come from the ch7035 driver in Mediatek's GPL code dump.
Only bare minimum is implemented -- no fancy stuff, such as scaling. That
would only worsen our misery. We don't load the firmware and we don't need
to even bother enabling the MCU. There are probably no distributable
firmware images anyway.
Just like the tda998x driver, this one uses the component framework and
adds an encoder on component bind, so that it works with the Armada DRM
driver.
Tested with a handful of monitors ranging from 1024x768@75 to 1400x1050@60,
with VGA as well as DVI.
Signed-off-by: Lubomir Rintel
---
Changes since v3:
- Cosmetic changes; drop ch7033_encoder_destroy() and use
drm_encoder_cleanup() for drm_encoder_funcs.destroy callback
directly.
Changes since v1:
- Sort the includes
- Drop a useless model id read
- Chain to the bridge-connector instead of dealing with the HPD/EDID
readout machinery ourselves
- Utilize regmap to access the registers
drivers/gpu/drm/bridge/Kconfig | 10 +
drivers/gpu/drm/bridge/Makefile | 1 +
drivers/gpu/drm/bridge/chrontel-ch7033.c | 669 +++
3 files changed, 680 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/chrontel-ch7033.c
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index aaed2347ace9d..0ebc72d62a5b2 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -27,6 +27,16 @@ 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_CHRONTEL_CH7033
+ tristate "Chrontel CH7033 Video Encoder"
+ depends on OF
+ select DRM_KMS_HELPER
+ help
+ Enable support for the Chrontel CH7033 VGA/DVI/HDMI Encoder, as
+ found in the Dell Wyse 3020 thin client.
+
+ If in doubt, say "N".
+
config DRM_DISPLAY_CONNECTOR
tristate "Display connector support"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 6fb062b5b0f04..a844315feddb4 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -1,5 +1,6 @@
# SPDX-License-Identifier: GPL-2.0
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_LVDS_CODEC) += lvds-codec.o
obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) +=
megachips-stdp-ge-b850v3-fw.o
diff --git a/drivers/gpu/drm/bridge/chrontel-ch7033.c
b/drivers/gpu/drm/bridge/chrontel-ch7033.c
new file mode 100644
index 0..f5cb2130684f7
--- /dev/null
+++ b/drivers/gpu/drm/bridge/chrontel-ch7033.c
@@ -0,0 +1,669 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Chrontel CH7033 Video Encoder Driver
+ *
+ * Copyright (C) 2019,2020 Lubomir Rintel
+ */
+
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Page 0, Register 0x07 */
+enum {
+ DRI_PD = BIT(3),
+ IO_PD = BIT(5),
+};
+
+/* Page 0, Register 0x08 */
+enum {
+ DRI_PDDRI = GENMASK(7, 4),
+ PDDAC = GENMASK(3, 1),
+ PANEN = BIT(0),
+};
+
+/* Page 0, Register 0x09 */
+enum {
+ DPD = BIT(7),
+ GCKOFF = BIT(6),
+ TV_BP = BIT(5),
+ SCLPD = BIT(4),
+ SDPD= BIT(3),
+ VGA_PD = BIT(2),
+ HDBKPD = BIT(1),
+ HDMI_PD = BIT(0),
+};
+
+/* Page 0, Register 0x0a */
+enum {
+ MEMINIT = BIT(7),
+ MEMIDLE = BIT(6),
+ MEMPD = BIT(5),
+ STOP= BIT(4),
+ LVDS_PD = BIT(3),
+ HD_DVIB = BIT(2),
+ HDCP_PD = BIT(1),
+ MCU_PD = BIT(0),
+};
+
+/* Page 0, Register 0x18 */
+enum {
+ IDF = GENMASK(7, 4),
+ INTEN = BIT(3),
+ SWAP= GENMASK(2, 0),
+};
+
+enum {
+ BYTE_SWAP_RGB = 0,
+ BYTE_SWAP_RBG = 1,
+ BYTE_SWAP_GRB = 2,
+ BYTE_SWAP_GBR = 3,
+ BYTE_SWAP_BRG = 4,
+ BYTE_SWAP_BGR = 5,
+};
+
+/* Page 0, Register 0x19 */
+enum {
+ HPO_I = BIT(5),
+ VPO_I = BIT(4),
+ DEPO_I = BIT(3),
+ CRYS_EN = BIT(2),
+ GCLKFREQ= GENMASK(2, 0),
+};
+
+/* Page 0, Register 0x2e */
+enum {
+ HFLIP = BIT(7),
+ VFLIP = BIT(6),
+ DEPO_O = BIT(5),
+ HPO_O = BIT(4),
+ VPO_O = BIT(3),
+ TE = GENMASK(2, 0),
+};
+
+/* Page 0, Register 0x2b */
+enum {
+
[PATCH v4 2/3] dt-bindings: display: Add Chrontel CH7033 Video Encoder binding
Add binding document for the Chrontel CH7033 VGA/DVI/HDMI Encoder.
Signed-off-by: Lubomir Rintel
Reviewed-by: Rob Herring
---
Changes since v3:
- Fixed the example so that it validates
Changes since v1:
- Dual licensed with BSD-2-Clause
- Collected Rob's reviewed-by tag
.../display/bridge/chrontel,ch7033.yaml | 77 +++
1 file changed, 77 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/chrontel,ch7033.yaml
diff --git
a/Documentation/devicetree/bindings/display/bridge/chrontel,ch7033.yaml
b/Documentation/devicetree/bindings/display/bridge/chrontel,ch7033.yaml
new file mode 100644
index 0..9f38f55fc9904
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/chrontel,ch7033.yaml
@@ -0,0 +1,77 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2019,2020 Lubomir Rintel
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/chrontel,ch7033.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Chrontel CH7033 Video Encoder Device Tree Bindings
+
+maintainers:
+ - Lubomir Rintel
+
+properties:
+ compatible:
+const: chrontel,ch7033
+
+ reg:
+maxItems: 1
+description: I2C address of the device
+
+ ports:
+type: object
+
+properties:
+ port@0:
+type: object
+description: |
+ Video port for RGB input.
+
+ port@1:
+type: object
+description: |
+ DVI port, should be connected to a node compatible with the
+ dvi-connector binding.
+
+required:
+ - port@0
+ - port@1
+
+required:
+ - compatible
+ - reg
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+i2c {
+#address-cells = <1>;
+#size-cells = <0>;
+
+vga-dvi-encoder@76 {
+compatible = "chrontel,ch7033";
+reg = <0x76>;
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+reg = <0>;
+endpoint {
+remote-endpoint = <_rgb_out>;
+};
+};
+
+port@1 {
+reg = <1>;
+endpoint {
+remote-endpoint = <_in>;
+};
+};
+
+};
+};
+};
--
2.26.0.rc2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/7] docs: fix broken references to text files
Quoting Mauro Carvalho Chehab (2020-02-22 01:00:03) > Several references got broken due to txt to ReST conversion. > > Several of them can be automatically fixed with: > > scripts/documentation-file-ref-check --fix > > Signed-off-by: Mauro Carvalho Chehab > --- > drivers/hwtracing/coresight/Kconfig | 2 +- > > diff --git a/drivers/hwtracing/coresight/Kconfig > b/drivers/hwtracing/coresight/Kconfig > index 6ff30e25af55..6d42a6d3766f 100644 > --- a/drivers/hwtracing/coresight/Kconfig > +++ b/drivers/hwtracing/coresight/Kconfig > @@ -107,7 +107,7 @@ config CORESIGHT_CPU_DEBUG > can quickly get to know program counter (PC), secure state, > exception level, etc. Before use debugging functionality, platform > needs to ensure the clock domain and power domain are enabled > - properly, please refer Documentation/trace/coresight-cpu-debug.rst > + properly, please refer > Documentation/trace/coresight/coresight-cpu-debug.rst > for detailed description and the example for usage. > > endif I ran into this today and almost sent a patch. Can you split this patch up into more pieces and send it off to the respective subsystem maintainers? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/4] drm: ipk: Add DRM driver for DesignWare IPK DSI
Add support for Synopsys DesignWare VPG (Video Pattern Generator) and
DRM driver for Synopsys DesignWare DSI Host IPK solution.
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: David Airlie
Cc: Daniel Vetter
Cc: Gustavo Pimentel
Cc: Joao Pinto
Signed-off-by: Angelo Ribeiro
---
drivers/gpu/drm/Kconfig | 2 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/ipk/Kconfig | 13 +
drivers/gpu/drm/ipk/Makefile | 6 +
drivers/gpu/drm/ipk/dw-drv.c | 189 +++
drivers/gpu/drm/ipk/dw-ipk.h | 30 +++
drivers/gpu/drm/ipk/dw-vpg.c | 559 +++
drivers/gpu/drm/ipk/dw-vpg.h | 55 +
8 files changed, 855 insertions(+)
create mode 100644 drivers/gpu/drm/ipk/Kconfig
create mode 100644 drivers/gpu/drm/ipk/Makefile
create mode 100644 drivers/gpu/drm/ipk/dw-drv.c
create mode 100644 drivers/gpu/drm/ipk/dw-ipk.h
create mode 100644 drivers/gpu/drm/ipk/dw-vpg.c
create mode 100644 drivers/gpu/drm/ipk/dw-vpg.h
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 4359497..29ea1d1 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -388,6 +388,8 @@ source "drivers/gpu/drm/mcde/Kconfig"
source "drivers/gpu/drm/tidss/Kconfig"
+source "drivers/gpu/drm/ipk/Kconfig"
+
# Keep legacy drivers last
menuconfig DRM_LEGACY
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 7f72ef5..c5afb63 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -124,3 +124,4 @@ obj-$(CONFIG_DRM_PANFROST) += panfrost/
obj-$(CONFIG_DRM_ASPEED_GFX) += aspeed/
obj-$(CONFIG_DRM_MCDE) += mcde/
obj-$(CONFIG_DRM_TIDSS) += tidss/
+obj-$(CONFIG_DRM_IPK) += ipk/
diff --git a/drivers/gpu/drm/ipk/Kconfig b/drivers/gpu/drm/ipk/Kconfig
new file mode 100644
index 000..1f87444
--- /dev/null
+++ b/drivers/gpu/drm/ipk/Kconfig
@@ -0,0 +1,13 @@
+# SPDX-License-Identifier: GPL-2.0-only
+config DRM_IPK
+ tristate "DRM Support for Synopsys DesignWare IPK DSI"
+ depends on DRM
+ select DRM_KMS_HELPER
+ select DRM_GEM_CMA_HELPER
+ select DRM_KMS_CMA_HELPER
+ select DRM_PANEL_BRIDGE
+ select VIDEOMODE_HELPERS
+ help
+ Enable support for the Synopsys DesignWare DRM DSI.
+ To compile this driver as a module, choose M here: the module
+ will be called ipk-drm.
diff --git a/drivers/gpu/drm/ipk/Makefile b/drivers/gpu/drm/ipk/Makefile
new file mode 100644
index 000..51d2774
--- /dev/null
+++ b/drivers/gpu/drm/ipk/Makefile
@@ -0,0 +1,6 @@
+# SPDX-License-Identifier: GPL-2.0-only
+ipk-drm-y := \
+ dw-drv.o \
+ dw-vpg.o
+
+obj-$(CONFIG_DRM_IPK) += ipk-drm.o
diff --git a/drivers/gpu/drm/ipk/dw-drv.c b/drivers/gpu/drm/ipk/dw-drv.c
new file mode 100644
index 000..6205f1c
--- /dev/null
+++ b/drivers/gpu/drm/ipk/dw-drv.c
@@ -0,0 +1,189 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019-2020 Synopsys, Inc. and/or its affiliates.
+ * Synopsys DesignWare MIPI DSI DRM driver
+ *
+ * Author: Angelo Ribeiro
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "dw-ipk.h"
+#include "dw-vpg.h"
+
+static const struct drm_mode_config_funcs dw_ipk_drm_modecfg_funcs = {
+ .fb_create = drm_gem_fb_create_with_dirty,
+ .atomic_check = drm_atomic_helper_check,
+ .atomic_commit = drm_atomic_helper_commit,
+};
+
+static int dw_ipk_load(struct drm_device *drm)
+{
+ int ret;
+
+ drm_mode_config_init(drm);
+
+ drm->mode_config.min_width = 0;
+ drm->mode_config.min_height = 0;
+
+ /* To handle orientation */
+ drm->mode_config.max_width = 2048;
+ drm->mode_config.max_height = 2048;
+
+ drm->mode_config.funcs = _ipk_drm_modecfg_funcs;
+
+ /* TODO
+* Optional framebuffer memory resources allocation
+*/
+
+ ret = vpg_load(drm);
+ if (ret)
+ return ret;
+
+ /* Calls all the crtc's, encoder's and connector's reset */
+ drm_mode_config_reset(drm);
+
+ /* Initialize and enable output polling */
+ drm_kms_helper_poll_init(drm);
+
+ return ret;
+}
+
+static void dw_ipk_unload(struct drm_device *drm)
+{
+ DRM_DEBUG_DRIVER("\n");
+
+ drm_kms_helper_poll_fini(drm);
+ vpg_unload(drm);
+}
+
+DEFINE_DRM_GEM_CMA_FOPS(ipk_drm_driver_fops);
+
+static int ipk_gem_cma_dumb_create(struct drm_file *file,
+ struct drm_device *dev,
+ struct drm_mode_create_dumb *args)
+{
+ unsigned int min_pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
+ int err;
+
+ /*
+* In order to optimize data transfer, pitch is aligned on
+* 128 bytes, height is aligned on 4 bytes
+*/
+ args->pitch = roundup(min_pitch, 128);
+ args->height = roundup(args->height, 4);
+
+ err =
Re: [PATCH v2 hmm 4/9] mm/hmm: remove HMM_FAULT_SNAPSHOT
On Tue, Mar 24, 2020 at 08:33:39AM +0100, Christoph Hellwig wrote:
> >
> > +/*
> > + * If the valid flag is masked off, and default_flags doesn't set valid,
> > then
> > + * hmm_pte_need_fault() always returns 0.
> > + */
> > +static bool hmm_can_fault(struct hmm_range *range)
> > +{
> > + return ((range->flags[HMM_PFN_VALID] & range->pfn_flags_mask) |
> > + range->default_flags) &
> > + range->flags[HMM_PFN_VALID];
> > +}
>
> So my idea behind the helper was to turn this into something readable :)
Well, it does help to give the expression a name :)
> E.g.
>
> /*
> * We only need to fault if either the default mask requires to fault all
> * pages, or at least the mask allows for individual pages to be faulted.
> */
> static bool hmm_can_fault(struct hmm_range *range)
> {
> return ((range->default_flags | range->pfn_flags_mask) &
> range->flags[HMM_PFN_VALID]);
> }
Okay, I find this as understandable and it is less cluttered. I think
the comment is good enough now.
Can we concur on this then:
static unsigned int
hmm_range_need_fault(const struct hmm_vma_walk *hmm_vma_walk,
const uint64_t *pfns, unsigned long npages,
uint64_t cpu_flags)
{
+ struct hmm_range *range = hmm_vma_walk->range;
unsigned int required_fault = 0;
unsigned long i;
- if (hmm_vma_walk->flags & HMM_FAULT_SNAPSHOT)
+ /*
+* If the default flags do not request to fault pages, and the mask does
+* not allow for individual pages to be faulted, then
+* hmm_pte_need_fault() will always return 0.
+*/
+ if (!((range->default_flags | range->pfn_flags_mask) &
+ range->flags[HMM_PFN_VALID]))
return 0;
I think everything else is sorted now, so if yes I'll send this as v3.
Thanks,
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 1/3] dt-bindings: Add vendor prefix for Chrontel, Inc.
Chrontel makes encoders for video displays and perhaps other stuff. Their web site is http://www.chrontel.com/. Signed-off-by: Lubomir Rintel Acked-by: Rob Herring --- Changes since v1: - Collect Rob's ack 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 a2da166df1bc7..0ab86d876f4d2 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -185,6 +185,8 @@ patternProperties: description: ChipOne "^chipspark,.*": description: ChipSPARK + "^chrontel,.*": +description: Chrontel, Inc. "^chrp,.*": description: Common Hardware Reference Platform "^chunghwa,.*": -- 2.26.0.rc2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/msm/dpu: add support for color processing blocks in dpu driver
This change adds support to configure dspp blocks in
the dpu driver.
Macro description of the changes coming in this patch.
1) Add dspp definitions in the hw catalog.
2) Add capability to reserve dspp blocks in the display data path.
3) Attach the reserved block to the encoder.
Signed-off-by: Kalyan Thota
---
drivers/gpu/drm/msm/Makefile | 1 +
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h | 2 +
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c| 12 +++-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 39
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 39
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 26
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h | 3 +
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c| 82 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.h| 69 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h| 2 +
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h| 1 +
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 58 --
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h | 2 +
drivers/gpu/drm/msm/msm_drv.h | 1 +
14 files changed, 322 insertions(+), 15 deletions(-)
create mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c
create mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.h
diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index 1579cf0..42f8aae 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -65,6 +65,7 @@ msm-y := \
disp/dpu1/dpu_hw_lm.o \
disp/dpu1/dpu_hw_pingpong.o \
disp/dpu1/dpu_hw_sspp.o \
+ disp/dpu1/dpu_hw_dspp.o \
disp/dpu1/dpu_hw_top.o \
disp/dpu1/dpu_hw_util.o \
disp/dpu1/dpu_hw_vbif.o \
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
index 5174e86..cec3474 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
@@ -73,12 +73,14 @@ struct dpu_crtc_smmu_state_data {
* struct dpu_crtc_mixer: stores the map for each virtual pipeline in the CRTC
* @hw_lm: LM HW Driver context
* @lm_ctl:CTL Path HW driver context
+ * @lm_dspp: DSPP HW driver context
* @mixer_op_mode: mixer blending operation mode
* @flush_mask:mixer flush mask for ctl, mixer and pipe
*/
struct dpu_crtc_mixer {
struct dpu_hw_mixer *hw_lm;
struct dpu_hw_ctl *lm_ctl;
+ struct dpu_hw_dspp *hw_dspp;
u32 mixer_op_mode;
u32 flush_mask;
};
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 42bf5c8..deebbba 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -20,6 +20,7 @@
#include "dpu_hw_catalog.h"
#include "dpu_hw_intf.h"
#include "dpu_hw_ctl.h"
+#include "dpu_hw_dspp.h"
#include "dpu_formats.h"
#include "dpu_encoder_phys.h"
#include "dpu_crtc.h"
@@ -537,6 +538,7 @@ static struct msm_display_topology dpu_encoder_get_topology(
* 1 LM, 1 INTF
* 2 LM, 1 INTF (stream merge to support high resolution interfaces)
*
+* Adding color blocks only to primary interface
*/
if (intf_count == 2)
topology.num_lm = 2;
@@ -545,6 +547,9 @@ static struct msm_display_topology dpu_encoder_get_topology(
else
topology.num_lm = (mode->hdisplay > MAX_HDISPLAY_SPLIT) ? 2 : 1;
+ if (dpu_enc->disp_info.intf_type == DRM_MODE_ENCODER_DSI)
+ topology.num_dspp = topology.num_lm;
+
topology.num_enc = 0;
topology.num_intf = intf_count;
@@ -960,7 +965,8 @@ static void dpu_encoder_virt_mode_set(struct drm_encoder
*drm_enc,
struct dpu_hw_blk *hw_pp[MAX_CHANNELS_PER_ENC];
struct dpu_hw_blk *hw_ctl[MAX_CHANNELS_PER_ENC];
struct dpu_hw_blk *hw_lm[MAX_CHANNELS_PER_ENC];
- int num_lm, num_ctl, num_pp;
+ struct dpu_hw_blk *hw_dspp[MAX_CHANNELS_PER_ENC] = { NULL };
+ int num_lm, num_ctl, num_pp, num_dspp;
int i, j;
if (!drm_enc) {
@@ -1009,6 +1015,9 @@ static void dpu_encoder_virt_mode_set(struct drm_encoder
*drm_enc,
drm_enc->base.id, DPU_HW_BLK_CTL, hw_ctl, ARRAY_SIZE(hw_ctl));
num_lm = dpu_rm_get_assigned_resources(_kms->rm, global_state,
drm_enc->base.id, DPU_HW_BLK_LM, hw_lm, ARRAY_SIZE(hw_lm));
+ num_dspp = dpu_rm_get_assigned_resources(_kms->rm, global_state,
+ drm_enc->base.id, DPU_HW_BLK_DSPP, hw_dspp,
+ ARRAY_SIZE(hw_dspp));
for (i = 0; i < MAX_CHANNELS_PER_ENC; i++)
dpu_enc->hw_pp[i] = i < num_pp ? to_dpu_hw_pingpong(hw_pp[i])
@@ -1021,6 +1030,7 @@ static void dpu_encoder_virt_mode_set(struct drm_encoder
*drm_enc,
cstate->mixers[i].hw_lm = to_dpu_hw_mixer(hw_lm[i]);
[PATCH v4] video: fbdev: arcfb: add missed free_irq and fix the order of request_irq
The driver forgets to free irq in remove which is requested in
probe.
Add the missed call to fix it.
Also, the position of request_irq() in probe should be put before
register_framebuffer().
Signed-off-by: Chuhong Yuan
---
Changes in v4:
- Use info->par->irq instead of par->irq to avoid dereferencing NULL pointer.
drivers/video/fbdev/arcfb.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/video/fbdev/arcfb.c b/drivers/video/fbdev/arcfb.c
index 314ab82e01c0..6f7838979f0a 100644
--- a/drivers/video/fbdev/arcfb.c
+++ b/drivers/video/fbdev/arcfb.c
@@ -544,10 +544,6 @@ static int arcfb_probe(struct platform_device *dev)
par->cslut[1] = 0x06;
info->flags = FBINFO_FLAG_DEFAULT;
spin_lock_init(>lock);
- retval = register_framebuffer(info);
- if (retval < 0)
- goto err1;
- platform_set_drvdata(dev, info);
if (irq) {
par->irq = irq;
if (request_irq(par->irq, _interrupt, IRQF_SHARED,
@@ -558,6 +554,10 @@ static int arcfb_probe(struct platform_device *dev)
goto err1;
}
}
+ retval = register_framebuffer(info);
+ if (retval < 0)
+ goto err1;
+ platform_set_drvdata(dev, info);
fb_info(info, "Arc frame buffer device, using %dK of video memory\n",
videomemorysize >> 10);
@@ -593,6 +593,8 @@ static int arcfb_remove(struct platform_device *dev)
if (info) {
unregister_framebuffer(info);
+ if (irq)
+ free_irq(((struct arcfb_par *)(info->par))->irq, info);
vfree((void __force *)info->screen_base);
framebuffer_release(info);
}
--
2.25.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/4] MAINTAINERS: Add IPK MIPI DSI Host driver entry
Creates entry for Synopsys DesignWare IPK MIPI DSI host driver and adds myself as maintainer. Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: David Airlie Cc: Daniel Vetter Cc: Gustavo Pimentel Cc: Joao Pinto Signed-off-by: Angelo Ribeiro --- MAINTAINERS | 8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 19eea09..3de4365 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5445,6 +5445,14 @@ S: Maintained F: drivers/gpu/drm/mcde/ F: Documentation/devicetree/bindings/display/ste,mcde.txt +DRM DRIVER FOR SYNOPSYS DESIGNWARE IPK +M: Angelo Ribeiro +L: dri-devel@lists.freedesktop.org +S: Maintained +F: drivers/gpu/drm/ipk/ +F: Documentation/devicetree/bindings/display/ipk/ +T: git git://anongit.freedesktop.org/drm/drm-misc + DRM DRIVER FOR TDFX VIDEO CARDS S: Orphan / Obsolete F: drivers/gpu/drm/tdfx/ -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] video: fbdev: vesafb: add missed release_region
On Fri, Mar 20, 2020 at 8:01 PM Bartlomiej Zolnierkiewicz
wrote:
>
>
> On 3/10/20 3:35 AM, Chuhong Yuan wrote:
> > The driver forgets to free the I/O region in remove and probe
> > failure.
> > Add the missed calls to fix it.
> >
> > Signed-off-by: Chuhong Yuan
> > ---
> > Changes in v3:
> > - Revise the commit message.
> > - Add an error handler to suit the "goto error" before request_region().
> > - Revise the order of operations in remove.
> >
> > drivers/video/fbdev/vesafb.c | 9 ++---
> > 1 file changed, 6 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/video/fbdev/vesafb.c b/drivers/video/fbdev/vesafb.c
> > index a1fe24ea869b..c7bc9ace47d4 100644
> > --- a/drivers/video/fbdev/vesafb.c
> > +++ b/drivers/video/fbdev/vesafb.c
> > @@ -439,7 +439,7 @@ static int vesafb_probe(struct platform_device *dev)
> > "vesafb: abort, cannot ioremap video memory 0x%x @
> > 0x%lx\n",
> > vesafb_fix.smem_len, vesafb_fix.smem_start);
> > err = -EIO;
> > - goto err;
> > + goto err_release_region;
> > }
> >
> > printk(KERN_INFO "vesafb: framebuffer at 0x%lx, mapped to 0x%p, "
> > @@ -458,15 +458,17 @@ static int vesafb_probe(struct platform_device *dev)
> >
> > if (fb_alloc_cmap(>cmap, 256, 0) < 0) {
> > err = -ENOMEM;
> > - goto err;
> > + goto err_release_region;
> > }
> > if (register_framebuffer(info)<0) {
> > err = -EINVAL;
> > fb_dealloc_cmap(>cmap);
> > - goto err;
> > + goto err_release_region;
> > }
> > fb_info(info, "%s frame buffer device\n", info->fix.id);
> > return 0;
> > +err_release_region:
> > + release_region(0x3c0, 32);
>
> This is incorrect.
>
> The cleanup order should be the reverse of the probing order.
>
> Also request_region() return value is not checked by the driver
> (there is a comment that it can fail and is optional):
>
> /* request failure does not faze us, as vgacon probably has this
> * region already (FIXME) */
> request_region(0x3c0, 32, "vesafb");
>
> so what would happen in such case? It seems that unconditionally
> doing the release will result in freeing the I/O region owned by
> the other driver (vgacon)..
>
Maybe we can add a field to represent whether the request succeeds?
request_region() returns source *, we can store it and check whether
it is null when
we are going to call release_region().
> > err:
> > arch_phys_wc_del(par->wc_cookie);
> > if (info->screen_base)
> > @@ -481,6 +483,7 @@ static int vesafb_remove(struct platform_device *pdev)
> > struct fb_info *info = platform_get_drvdata(pdev);
> >
> > unregister_framebuffer(info);
> > + release_region(0x3c0, 32);
> > framebuffer_release(info);
> >
> > return 0;
> >
>
> Best regards,
> --
> Bartlomiej Zolnierkiewicz
> Samsung R Institute Poland
> Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
