Re: [PATCH RESEND drm-misc 4/4] dma-buf: heaps: make dma_heap_class constant
Hello Ricardo,
On Tue, 5 Mar 2024 at 22:37, T.J. Mercier wrote:
>
> On Tue, Mar 5, 2024 at 3:34 AM Ricardo B. Marliere
> wrote:
> >
> > Since commit 43a7206b0963 ("driver core: class: make class_register() take
> > a const *"), the driver core allows for struct class to be in read-only
> > memory, so move the dma_heap_class structure to be declared at build time
> > placing it into read-only memory, instead of having to be dynamically
> > allocated at boot time.
> >
> > Cc: Greg Kroah-Hartman
> > Suggested-by: Greg Kroah-Hartman
> > Signed-off-by: Ricardo B. Marliere
> > ---
> > drivers/dma-buf/dma-heap.c | 26 ++
> > 1 file changed, 14 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c
> > index 84ae708fafe7..bcca6a2bbce8 100644
> > --- a/drivers/dma-buf/dma-heap.c
> > +++ b/drivers/dma-buf/dma-heap.c
> > @@ -43,10 +43,18 @@ struct dma_heap {
> > struct cdev heap_cdev;
> > };
> >
> > +static char *dma_heap_devnode(const struct device *dev, umode_t *mode)
> > +{
> > + return kasprintf(GFP_KERNEL, "dma_heap/%s", dev_name(dev));
> > +}
> > +
> > static LIST_HEAD(heap_list);
> > static DEFINE_MUTEX(heap_list_lock);
> > static dev_t dma_heap_devt;
> > -static struct class *dma_heap_class;
> > +static struct class dma_heap_class = {
> > + .name = DEVNAME,
> > + .devnode = dma_heap_devnode,
> > +};
> > static DEFINE_XARRAY_ALLOC(dma_heap_minors);
> >
> > static int dma_heap_buffer_alloc(struct dma_heap *heap, size_t len,
> > @@ -261,7 +269,7 @@ struct dma_heap *dma_heap_add(const struct
> > dma_heap_export_info *exp_info)
> > goto err1;
> > }
> >
> > - dev_ret = device_create(dma_heap_class,
> > + dev_ret = device_create(_heap_class,
> > NULL,
> > heap->heap_devt,
> > NULL,
> > @@ -291,7 +299,7 @@ struct dma_heap *dma_heap_add(const struct
> > dma_heap_export_info *exp_info)
> > return heap;
> >
> > err3:
> > - device_destroy(dma_heap_class, heap->heap_devt);
> > + device_destroy(_heap_class, heap->heap_devt);
> > err2:
> > cdev_del(>heap_cdev);
> > err1:
> > @@ -301,11 +309,6 @@ struct dma_heap *dma_heap_add(const struct
> > dma_heap_export_info *exp_info)
> > return err_ret;
> > }
> >
> > -static char *dma_heap_devnode(const struct device *dev, umode_t *mode)
> > -{
> > - return kasprintf(GFP_KERNEL, "dma_heap/%s", dev_name(dev));
> > -}
> > -
> > static int dma_heap_init(void)
> > {
> > int ret;
> > @@ -314,12 +317,11 @@ static int dma_heap_init(void)
> > if (ret)
> > return ret;
> >
> > - dma_heap_class = class_create(DEVNAME);
> > - if (IS_ERR(dma_heap_class)) {
> > + ret = class_register(_heap_class);
> > + if (ret) {
> > unregister_chrdev_region(dma_heap_devt, NUM_HEAP_MINORS);
> > - return PTR_ERR(dma_heap_class);
> > + return ret;
> > }
> > - dma_heap_class->devnode = dma_heap_devnode;
> >
> > return 0;
> > }
> >
> > --
> > 2.43.0
>
> Reviewed-by: T.J. Mercier
FWIW, please free to add my
Acked-by: Sumit Semwal
>
>
> Is this really a resend? I don't see anything on lore and I can't
> recall seeing this patch in my inbox before.
Best,
Sumit.
--
Thanks and regards,
Sumit Semwal (he / him)
Tech Lead - LCG, Vertical Technologies
Linaro.org │ Open source software for ARM SoCs
Re: [PATCH] dma-buf: heaps: Don't track CMA dma-buf pages under RssFile
Hi TJ,
On Thu, 18 Jan 2024 at 15:32, Christian König
wrote:
> Am 17.01.24 um 19:11 schrieb T.J. Mercier:
>
> DMA buffers allocated from the CMA dma-buf heap get counted under
> RssFile for processes that map them and trigger page faults. In
> addition to the incorrect accounting reported to userspace, reclaim
> behavior was influenced by the MM_FILEPAGES counter until linux 6.8, but
> this memory is not reclaimable. [1] Change the CMA dma-buf heap to set
> VM_PFNMAP on the VMA so MM does not poke at the memory managed by this
> dma-buf heap, and use vmf_insert_pfn to correct the RSS accounting.
>
> The system dma-buf heap does not suffer from this issue since
> remap_pfn_range is used during the mmap of the buffer, which also sets
> VM_PFNMAP on the VMA.
>
>
> Mhm, not an issue with this patch but Daniel wanted to add a check for
> VM_PFNMAP to dma_buf_mmap() which would have noted this earlier.
>
> I don't fully remember the discussion but for some reason that was never
> committed. We should probably try that again.
>
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/mm/vmscan.c?id=fb46e22a9e3863e08aef8815df9f17d0f4b9aede
>
> Fixes: b61614ec318a ("dma-buf: heaps: Add CMA heap to dmabuf heaps")
> Signed-off-by: T.J. Mercier
>
>
> Acked-by: Christian König
>
>
Thanks for the patch; pushed to drm-misc-fixes.
Best,
Sumit
>
>
> ---
> drivers/dma-buf/heaps/cma_heap.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/dma-buf/heaps/cma_heap.c
> b/drivers/dma-buf/heaps/cma_heap.c
> index ee899f8e6721..4a63567e93ba 100644
> --- a/drivers/dma-buf/heaps/cma_heap.c
> +++ b/drivers/dma-buf/heaps/cma_heap.c
> @@ -168,10 +168,7 @@ static vm_fault_t cma_heap_vm_fault(struct vm_fault *vmf)
> if (vmf->pgoff > buffer->pagecount)
> return VM_FAULT_SIGBUS;
>
> - vmf->page = buffer->pages[vmf->pgoff];
> - get_page(vmf->page);
> -
> - return 0;
> + return vmf_insert_pfn(vma, vmf->address,
> page_to_pfn(buffer->pages[vmf->pgoff]));
> }
>
> static const struct vm_operations_struct dma_heap_vm_ops = {
> @@ -185,6 +182,8 @@ static int cma_heap_mmap(struct dma_buf *dmabuf, struct
> vm_area_struct *vma)
> if ((vma->vm_flags & (VM_SHARED | VM_MAYSHARE)) == 0)
> return -EINVAL;
>
> + vm_flags_set(vma, VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP);
> +
> vma->vm_ops = _heap_vm_ops;
> vma->vm_private_data = buffer;
>
>
>
>
--
Thanks and regards,
Sumit Semwal (he / him)
Tech Lead - LCG, Vertical Technologies
Linaro.org │ Open source software for ARM SoCs
Re: [PATCH v2] Remove the parameter not described warning
Hi Vinayak,
On Wed, 6 Sept 2023 at 22:21, Vinayak Hegde wrote:
>
> I encountered a warning during kernel documentation compilation
> due to a missing colon in the documentation for the
> 'num_fences' variable in the sync_file.h header file.
> This change adds the missing colon to align with the documentation format.
>
> Signed-off-by: Vinayak Hegde
Thanks for your patch; I'll queue it via drm-misc.
> ---
> include/uapi/linux/sync_file.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/uapi/linux/sync_file.h b/include/uapi/linux/sync_file.h
> index 7e42a5b7558b..b389a5495181 100644
> --- a/include/uapi/linux/sync_file.h
> +++ b/include/uapi/linux/sync_file.h
> @@ -56,7 +56,7 @@ struct sync_fence_info {
> * @name: name of fence
> * @status:status of fence. 1: signaled 0:active <0:error
> * @flags: sync_file_info flags
> - * @num_fences number of fences in the sync_file
> + * @num_fences: number of fences in the sync_file
> * @pad: padding for 64-bit alignment, should always be zero
> * @sync_fence_info: pointer to array of struct _fence_info with all
> * fences in the sync_file
> --
> 2.34.1
>
Best,
Sumit.
--
Thanks and regards,
Sumit Semwal (he / him)
Tech Lead - LCG, Vertical Technologies
Linaro.org │ Open source software for ARM SoCs
Re: [PATCH] Remove the parameter not described warning
Hello Vinayak,
On Mon, 21 Aug 2023 at 20:56, Vinayak Hegde wrote:
>
> Signed-off-by: Vinayak Hegde
Thank you for your patch. Could you please make the git commit message
a bit more descriptive? Please describe how did you find this warning,
atleast.
> ---
> include/uapi/linux/sync_file.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/uapi/linux/sync_file.h b/include/uapi/linux/sync_file.h
> index 7e42a5b7558b..ff0a931833e2 100644
> --- a/include/uapi/linux/sync_file.h
> +++ b/include/uapi/linux/sync_file.h
> @@ -56,7 +56,7 @@ struct sync_fence_info {
> * @name: name of fence
> * @status:status of fence. 1: signaled 0:active <0:error
> * @flags: sync_file_info flags
> - * @num_fences number of fences in the sync_file
> + * @num_fences:number of fences in the sync_file
> * @pad: padding for 64-bit alignment, should always be zero
> * @sync_fence_info: pointer to array of struct _fence_info with all
> * fences in the sync_file
> --
> 2.34.1
>
Best,
Sumit.
--
Thanks and regards,
Sumit Semwal (he / him)
Tech Lead - LCG, Vertical Technologies
Linaro.org │ Open source software for ARM SoCs
Re: [PATCH v2] dma-buf: fix an error pointer vs NULL bug
On Thu, 6 Jul 2023 at 18:24, Christian König wrote:
>
> Am 06.07.23 um 14:37 schrieb Dan Carpenter:
> > Smatch detected potential error pointer dereference.
> >
> > drivers/gpu/drm/drm_syncobj.c:888 drm_syncobj_transfer_to_timeline()
> > error: 'fence' dereferencing possible ERR_PTR()
> >
> > The error pointer comes from dma_fence_allocate_private_stub(). One
> > caller expected error pointers and one expected NULL pointers. Change
> > it to return NULL and update the caller which expected error pointers,
> > drm_syncobj_assign_null_handle(), to check for NULL instead.
> >
> > Fixes: f781f661e8c9 ("dma-buf: keep the signaling time of merged fences v3")
> > Signed-off-by: Dan Carpenter
>
Thanks for catching this!
> Reviewed-by: Christian König
Reviewed-by: Sumit Semwal
>
> Should I push that one to drm-misc-fixes?
If you haven't pushed already, I can push it now.
>
> Regards,
> Christian.
Best,
Sumit.
>
> > ---
> > v2: Fix it in dma_fence_allocate_private_stub() instead of
> > __dma_fence_unwrap_merge().
> >
> >
> > drivers/dma-buf/dma-fence.c | 2 +-
> > drivers/gpu/drm/drm_syncobj.c | 4 ++--
> > 2 files changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
> > index ad076f208760..8aa8f8cb7071 100644
> > --- a/drivers/dma-buf/dma-fence.c
> > +++ b/drivers/dma-buf/dma-fence.c
> > @@ -160,7 +160,7 @@ struct dma_fence
> > *dma_fence_allocate_private_stub(ktime_t timestamp)
> >
> > fence = kzalloc(sizeof(*fence), GFP_KERNEL);
> > if (fence == NULL)
> > - return ERR_PTR(-ENOMEM);
> > + return NULL;
> >
> > dma_fence_init(fence,
> > _fence_stub_ops,
> > diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
> > index 04589a35eb09..e592c5da70ce 100644
> > --- a/drivers/gpu/drm/drm_syncobj.c
> > +++ b/drivers/gpu/drm/drm_syncobj.c
> > @@ -355,8 +355,8 @@ static int drm_syncobj_assign_null_handle(struct
> > drm_syncobj *syncobj)
> > {
> > struct dma_fence *fence =
> > dma_fence_allocate_private_stub(ktime_get());
> >
> > - if (IS_ERR(fence))
> > - return PTR_ERR(fence);
> > + if (!fence)
> > + return -ENOMEM;
> >
> > drm_syncobj_replace_fence(syncobj, fence);
> > dma_fence_put(fence);
>
--
Thanks and regards,
Sumit Semwal (he / him)
Tech Lead - LCG, Vertical Technologies
Linaro.org │ Open source software for ARM SoCs
Re: [PATCH] MAINTAINERS: Add T.J. Mercier as reviewer for DMA-BUF HEAPS FRAMEWORK
Hi John, On Fri, 30 Jun 2023 at 10:22, John Stultz wrote: > > T.J. has been responsible for dmab-buf items on the Android team > for awhile now, so it would be great to have him on as a reviewer. > > Cc: T.J. Mercier > Cc: Sumit Semwal > Cc: Benjamin Gaignard > Cc: Brian Starkey > Cc: John Stultz > Cc: linux-me...@vger.kernel.org > Cc: dri-devel@lists.freedesktop.org > Cc: linaro-mm-...@lists.linaro.org > Cc: kernel-t...@android.com > Signed-off-by: John Stultz Thank you for the patch; Acked-by: Sumit Semwal I'll push it to drm-misc along with the one removing Liam. > --- > MAINTAINERS | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index cb075f52d97b..f4e92b968ed7 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -6184,6 +6184,7 @@ R:Benjamin Gaignard > > R: Laura Abbott > R: Brian Starkey > R: John Stultz > +R: T.J. Mercier > L: linux-me...@vger.kernel.org > L: dri-devel@lists.freedesktop.org > L: linaro-mm-...@lists.linaro.org (moderated for non-subscribers) > -- > 2.41.0.255.g8b1d071c50-goog > Best, Sumit.
Re: [Freedreno] [PATCH 2/2] drm/msm/dpu/catalog: define DSPP blocks found on sdm845
On Mon, 12 Jun 2023 at 23:55, Dmitry Baryshkov
wrote:
>
> Add definitions of DSPP blocks present on the sdm845 platform. This
> should enable color-management on sdm845-bassed devices.
>
> Signed-off-by: Dmitry Baryshkov
> ---
> .../msm/disp/dpu1/catalog/dpu_4_0_sdm845.h| 21 +++
> 1 file changed, 17 insertions(+), 4 deletions(-)
Thanks for your patch, Dmitry. LGTM.
Please feel free to add:
Reviewed-by: Sumit Semwal
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
> b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
> index 36ea1af10894..b6098141bb9b 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
> @@ -96,19 +96,30 @@ static const struct dpu_sspp_cfg sdm845_sspp[] = {
>
> static const struct dpu_lm_cfg sdm845_lm[] = {
> LM_BLK("lm_0", LM_0, 0x44000, MIXER_SDM845_MASK,
> - _lm_sblk, PINGPONG_0, LM_1, 0),
> + _lm_sblk, PINGPONG_0, LM_1, DSPP_0),
> LM_BLK("lm_1", LM_1, 0x45000, MIXER_SDM845_MASK,
> - _lm_sblk, PINGPONG_1, LM_0, 0),
> + _lm_sblk, PINGPONG_1, LM_0, DSPP_1),
> LM_BLK("lm_2", LM_2, 0x46000, MIXER_SDM845_MASK,
> - _lm_sblk, PINGPONG_2, LM_5, 0),
> + _lm_sblk, PINGPONG_2, LM_5, DSPP_2),
> LM_BLK("lm_3", LM_3, 0x0, MIXER_SDM845_MASK,
> - _lm_sblk, PINGPONG_NONE, 0, 0),
> + _lm_sblk, PINGPONG_NONE, 0, DSPP_3),
> LM_BLK("lm_4", LM_4, 0x0, MIXER_SDM845_MASK,
> _lm_sblk, PINGPONG_NONE, 0, 0),
> LM_BLK("lm_5", LM_5, 0x49000, MIXER_SDM845_MASK,
> _lm_sblk, PINGPONG_3, LM_2, 0),
> };
>
> +static const struct dpu_dspp_cfg sdm845_dspp[] = {
> + DSPP_BLK("dspp_0", DSPP_0, 0x54000, DSPP_SC7180_MASK,
> +_dspp_sblk),
> + DSPP_BLK("dspp_1", DSPP_1, 0x56000, DSPP_SC7180_MASK,
> +_dspp_sblk),
> + DSPP_BLK("dspp_2", DSPP_2, 0x58000, DSPP_SC7180_MASK,
> +_dspp_sblk),
> + DSPP_BLK("dspp_3", DSPP_3, 0x5a000, DSPP_SC7180_MASK,
> +_dspp_sblk),
> +};
> +
> static const struct dpu_pingpong_cfg sdm845_pp[] = {
> PP_BLK("pingpong_0", PINGPONG_0, 0x7, PINGPONG_SDM845_TE2_MASK,
> 0, sdm845_pp_sblk_te,
> DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 8),
> @@ -193,6 +204,8 @@ const struct dpu_mdss_cfg dpu_sdm845_cfg = {
> .sspp = sdm845_sspp,
> .mixer_count = ARRAY_SIZE(sdm845_lm),
> .mixer = sdm845_lm,
> + .dspp_count = ARRAY_SIZE(sdm845_dspp),
> + .dspp = sdm845_dspp,
> .pingpong_count = ARRAY_SIZE(sdm845_pp),
> .pingpong = sdm845_pp,
> .dsc_count = ARRAY_SIZE(sdm845_dsc),
> --
> 2.39.2
>
--
Thanks and regards,
Sumit Semwal (he / him)
Tech Lead - LCG, Vertical Technologies
Linaro.org │ Open source software for ARM SoCs
Re: [Freedreno] [PATCH 1/2] drm/msm/dpu: do not enable color-management if DSPPs are not available
On Mon, 12 Jun 2023 at 23:55, Dmitry Baryshkov
wrote:
>
> We can not support color management without DSPP blocks being provided
> in the HW catalog. Do not enable color management for CRTCs if num_dspps
> is 0.
>
> Fixes: 4259ff7ae509 ("drm/msm/dpu: add support for pcc color block in dpu
> driver")
> Reported-by: Yongqin Liu
> Signed-off-by: Dmitry Baryshkov
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
Thanks for your patch, Dmitry. LGTM.
Please feel free to add:
Reviewed-by: Sumit Semwal
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> index 6e684a7b49a1..1edf2b6b0a26 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> @@ -1463,6 +1463,8 @@ static const struct drm_crtc_helper_funcs
> dpu_crtc_helper_funcs = {
> struct drm_crtc *dpu_crtc_init(struct drm_device *dev, struct drm_plane
> *plane,
> struct drm_plane *cursor)
> {
> + struct msm_drm_private *priv = dev->dev_private;
> + struct dpu_kms *dpu_kms = to_dpu_kms(priv->kms);
> struct drm_crtc *crtc = NULL;
> struct dpu_crtc *dpu_crtc = NULL;
> int i, ret;
> @@ -1494,7 +1496,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);
> + if (dpu_kms->catalog->dspp_count)
> + 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);
> --
> 2.39.2
>
--
Thanks and regards,
Sumit Semwal (he / him)
Tech Lead - LCG, Vertical Technologies
Linaro.org │ Open source software for ARM SoCs
Re: [PATCH] dma-buf/sw_sync: Replace all non-returning strlcpy with strscpy
Hello Azeem, On Tue, 23 May 2023 at 22:52, Kees Cook wrote: > > On Tue, May 23, 2023 at 02:19:43AM +, Azeem Shaikh wrote: > > strlcpy() reads the entire source buffer first. > > This read may exceed the destination size limit. > > This is both inefficient and can lead to linear read > > overflows if a source string is not NUL-terminated [1]. > > In an effort to remove strlcpy() completely [2], replace > > strlcpy() here with strscpy(). > > No return values were used, so direct replacement is safe. > > > > [1] https://www.kernel.org/doc/html/latest/process/deprecated.html#strlcpy > > [2] https://github.com/KSPP/linux/issues/89 Thank you for the patch; I'll queue it up. > > > > Signed-off-by: Azeem Shaikh > > Reviewed-by: Kees Cook > > -- > Kees Cook Best, Sumit. -- Thanks and regards, Sumit Semwal (he / him) Tech Lead - LCG, Vertical Technologies Linaro.org │ Open source software for ARM SoCs
Re: [PATCH] dma-buf: fix dma_buf_export init order v2
Hi Christian,
On Fri, 9 Dec 2022 at 12:45, Christian König
wrote:
>
> The init order and resulting error handling in dma_buf_export
> was pretty messy.
>
> Subordinate objects like the file and the sysfs kernel objects
> were initializing and wiring itself up with the object in the
> wrong order resulting not only in complicating and partially
> incorrect error handling, but also in publishing only halve
> initialized DMA-buf objects.
>
> Clean this up thoughtfully by allocating the file independent
> of the DMA-buf object. Then allocate and initialize the DMA-buf
> object itself, before publishing it through sysfs. If everything
> works as expected the file is then connected with the DMA-buf
> object and publish it through debugfs.
>
> Also adds the missing dma_resv_fini() into the error handling.
>
> v2: add some missing changes to dma_bug_getfile() and a missing NULL
> check in dma_buf_file_release()
>
> Signed-off-by: Christian König
Thank you for this nice cleanup.
Acked-by: Sumit Semwal
Best,
Sumit.
> ---
> drivers/dma-buf/dma-buf-sysfs-stats.c | 7 +--
> drivers/dma-buf/dma-buf-sysfs-stats.h | 4 +-
> drivers/dma-buf/dma-buf.c | 84 +--
> 3 files changed, 43 insertions(+), 52 deletions(-)
>
> diff --git a/drivers/dma-buf/dma-buf-sysfs-stats.c
> b/drivers/dma-buf/dma-buf-sysfs-stats.c
> index 2bba0babcb62..4b680e10c15a 100644
> --- a/drivers/dma-buf/dma-buf-sysfs-stats.c
> +++ b/drivers/dma-buf/dma-buf-sysfs-stats.c
> @@ -168,14 +168,11 @@ void dma_buf_uninit_sysfs_statistics(void)
> kset_unregister(dma_buf_stats_kset);
> }
>
> -int dma_buf_stats_setup(struct dma_buf *dmabuf)
> +int dma_buf_stats_setup(struct dma_buf *dmabuf, struct file *file)
> {
> struct dma_buf_sysfs_entry *sysfs_entry;
> int ret;
>
> - if (!dmabuf || !dmabuf->file)
> - return -EINVAL;
> -
> if (!dmabuf->exp_name) {
> pr_err("exporter name must not be empty if stats needed\n");
> return -EINVAL;
> @@ -192,7 +189,7 @@ int dma_buf_stats_setup(struct dma_buf *dmabuf)
>
> /* create the directory for buffer stats */
> ret = kobject_init_and_add(_entry->kobj, _buf_ktype, NULL,
> - "%lu", file_inode(dmabuf->file)->i_ino);
> + "%lu", file_inode(file)->i_ino);
> if (ret)
> goto err_sysfs_dmabuf;
>
> diff --git a/drivers/dma-buf/dma-buf-sysfs-stats.h
> b/drivers/dma-buf/dma-buf-sysfs-stats.h
> index a49c6e2650cc..7a8a995b75ba 100644
> --- a/drivers/dma-buf/dma-buf-sysfs-stats.h
> +++ b/drivers/dma-buf/dma-buf-sysfs-stats.h
> @@ -13,7 +13,7 @@
> int dma_buf_init_sysfs_statistics(void);
> void dma_buf_uninit_sysfs_statistics(void);
>
> -int dma_buf_stats_setup(struct dma_buf *dmabuf);
> +int dma_buf_stats_setup(struct dma_buf *dmabuf, struct file *file);
>
> void dma_buf_stats_teardown(struct dma_buf *dmabuf);
> #else
> @@ -25,7 +25,7 @@ static inline int dma_buf_init_sysfs_statistics(void)
>
> static inline void dma_buf_uninit_sysfs_statistics(void) {}
>
> -static inline int dma_buf_stats_setup(struct dma_buf *dmabuf)
> +static inline int dma_buf_stats_setup(struct dma_buf *dmabuf, struct file
> *file)
> {
> return 0;
> }
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index e6f36c014c4c..eb6b59363c4f 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -95,10 +95,11 @@ static int dma_buf_file_release(struct inode *inode,
> struct file *file)
> return -EINVAL;
>
> dmabuf = file->private_data;
> -
> - mutex_lock(_list.lock);
> - list_del(>list_node);
> - mutex_unlock(_list.lock);
> + if (dmabuf) {
> + mutex_lock(_list.lock);
> + list_del(>list_node);
> + mutex_unlock(_list.lock);
> + }
>
> return 0;
> }
> @@ -523,17 +524,17 @@ static inline int is_dma_buf_file(struct file *file)
> return file->f_op == _buf_fops;
> }
>
> -static struct file *dma_buf_getfile(struct dma_buf *dmabuf, int flags)
> +static struct file *dma_buf_getfile(size_t size, int flags)
> {
> static atomic64_t dmabuf_inode = ATOMIC64_INIT(0);
> - struct file *file;
> struct inode *inode = alloc_anon_inode(dma_buf_mnt->mnt_sb);
> + struct file *file;
>
> if (IS_ERR(inode))
> return ERR_CAST(inode);
>
> - inode->i_size = dmabuf->size;
> - inode_set_bytes(inode,
Re: [PATCH 2/5] driver core: make struct class.devnode() take a const *
Hello Greg,
On Fri, 25 Nov 2022 at 17:25, Mauro Carvalho Chehab wrote:
>
> Em Wed, 23 Nov 2022 13:25:20 +0100
> Greg Kroah-Hartman escreveu:
>
> > The devnode() in struct class should not be modifying the device that is
> > passed into it, so mark it as a const * and propagate the function
> > signature changes out into all relevant subsystems that use this
> > callback.
>
> Acked-by: Mauro Carvalho Chehab
> >
Please feel free to add my
Acked-by: Sumit Semwal
for the dma-buf portion.
Best,
Sumit.
> > Cc: Fenghua Yu
> > Cc: Reinette Chatre
> > Cc: Thomas Gleixner
> > Cc: Ingo Molnar
> > Cc: Borislav Petkov
> > Cc: Dave Hansen
> > Cc: x...@kernel.org
> > Cc: "H. Peter Anvin"
> > Cc: FUJITA Tomonori
> > Cc: Jens Axboe
> > Cc: Justin Sanders
> > Cc: Arnd Bergmann
> > Cc: Sumit Semwal
> > Cc: Benjamin Gaignard
> > Cc: Liam Mark
> > Cc: Laura Abbott
> > Cc: Brian Starkey
> > Cc: John Stultz
> > Cc: "Christian König"
> > Cc: Maarten Lankhorst
> > Cc: Maxime Ripard
> > Cc: Thomas Zimmermann
> > Cc: David Airlie
> > Cc: Daniel Vetter
> > Cc: Jason Gunthorpe
> > Cc: Leon Romanovsky
> > Cc: Dennis Dalessandro
> > Cc: Dmitry Torokhov
> > Cc: Mauro Carvalho Chehab
> > Cc: Sean Young
> > Cc: Frank Haverkamp
> > Cc: Jiri Slaby
> > Cc: "Michael S. Tsirkin"
> > Cc: Jason Wang
> > Cc: Alex Williamson
> > Cc: Cornelia Huck
> > Cc: Kees Cook
> > Cc: Anton Vorontsov
> > Cc: Colin Cross
> > Cc: Tony Luck
> > Cc: Jaroslav Kysela
> > Cc: Takashi Iwai
> > Cc: Hans Verkuil
> > Cc: Christophe JAILLET
> > Cc: Xie Yongji
> > Cc: Gautam Dawar
> > Cc: Dan Carpenter
> > Cc: Eli Cohen
> > Cc: Parav Pandit
> > Cc: Maxime Coquelin
> > Cc: alsa-de...@alsa-project.org
> > Cc: dri-devel@lists.freedesktop.org
> > Cc: k...@vger.kernel.org
> > Cc: linaro-mm-...@lists.linaro.org
> > Cc: linux-bl...@vger.kernel.org
> > Cc: linux-in...@vger.kernel.org
> > Cc: linux-ker...@vger.kernel.org
> > Cc: linux-me...@vger.kernel.org
> > Cc: linux-r...@vger.kernel.org
> > Cc: linux-s...@vger.kernel.org
> > Cc: linux-...@vger.kernel.org
> > Cc: virtualizat...@lists.linux-foundation.org
> > Signed-off-by: Greg Kroah-Hartman
> > ---
> > arch/x86/kernel/cpu/resctrl/pseudo_lock.c | 4 ++--
> > arch/x86/kernel/cpuid.c| 2 +-
> > arch/x86/kernel/msr.c | 2 +-
> > block/bsg.c| 2 +-
> > drivers/block/aoe/aoechr.c | 2 +-
> > drivers/char/mem.c | 2 +-
> > drivers/char/misc.c| 4 ++--
> > drivers/dma-buf/dma-heap.c | 2 +-
> > drivers/gpu/drm/drm_sysfs.c| 2 +-
> > drivers/infiniband/core/user_mad.c | 2 +-
> > drivers/infiniband/core/uverbs_main.c | 2 +-
> > drivers/infiniband/hw/hfi1/device.c| 4 ++--
> > drivers/input/input.c | 2 +-
> > drivers/media/dvb-core/dvbdev.c| 4 ++--
> > drivers/media/pci/ddbridge/ddbridge-core.c | 4 ++--
> > drivers/media/rc/rc-main.c | 2 +-
> > drivers/misc/genwqe/card_base.c| 2 +-
> > drivers/tty/tty_io.c | 2 +-
> > drivers/usb/core/file.c| 2 +-
> > drivers/vdpa/vdpa_user/vduse_dev.c | 2 +-
> > drivers/vfio/vfio_main.c | 2 +-
> > fs/pstore/pmsg.c | 2 +-
> > include/linux/device/class.h | 2 +-
> > sound/sound_core.c | 2 +-
> > 24 files changed, 29 insertions(+), 29 deletions(-)
> >
> > diff --git a/arch/x86/kernel/cpu/resctrl/pseudo_lock.c
> > b/arch/x86/kernel/cpu/resctrl/pseudo_lock.c
> > index d961ae3ed96e..4e4231a58f38 100644
> > --- a/arch/x86/kernel/cpu/resctrl/pseudo_lock.c
> > +++ b/arch/x86/kernel/cpu/resctrl/pseudo_lock.c
> > @@ -1560,9 +1560,9 @@ static const struct file_operations
> > pseudo_lock_dev_fops = {
> > .mmap = pseudo_lock_dev_mmap,
> > };
> >
> > -static char *pseudo_lock_devnode(struct device *dev, umode_t *mode)
> > +static char *pseudo_lock_devnode(const struct device *dev, umode_t *mode)
> > {
> > - struct rdtgroup *rdtgrp;
> > + const struct rdtgroup *rdtgrp;
> >
> > rdtgrp = dev_get_drvdata(dev);
> > i
Re: [PATCH v4] dma-buf: fix racing conflict of dma_heap_add()
Hi Dawei Li,
On Mon, 21 Nov 2022 at 23:53, Christian König wrote:
>
> Hi Dawei,
>
> from the technical description, coding style etc.. it looks clean to me,
> but I'm the completely wrong person to ask for a background check.
>
> I have a high level understanding of how dma-heaps work, but not a
> single line of this code is from me.
>
> Feel free to add my Acked-by, but Laura, John and others do you have any
> opinion?
>
> Regards,
> Christian.
>
> Am 21.11.22 um 16:28 schrieb Dawei Li:
> > On Sat, Nov 05, 2022 at 12:05:36AM +0800, Dawei Li wrote:
> >
> > Hi Christian,
> > May I have your opinion on this change?
> >
> > Thanks,
> > Dawei
> >
> >> Racing conflict could be:
> >> task A task B
> >> list_for_each_entry
> >> strcmp(h->name))
> >> list_for_each_entry
> >> strcmp(h->name)
> >> kzallockzalloc
> >> .. .
> >> device_create device_create
> >> list_add
> >> list_add
> >>
> >> The root cause is that task B has no idea about the fact someone
> >> else(A) has inserted heap with same name when it calls list_add,
> >> so a potential collision occurs.
> >>
> >> Fixes: c02a81fba74f ("dma-buf: Add dma-buf heaps framework")
> >> Signed-off-by: Dawei Li
Looks good to me as well. I will apply it over on drm-misc.
Best,
Sumit.
> >> ---
> >> v1:
> >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fall%2FTYCP286MB2323950197F60FC3473123B7CA349%40TYCP286MB2323.JPNP286.PROD.OUTLOOK.COM%2Fdata=05%7C01%7Cchristian.koenig%40amd.com%7C1989f31257fc458a27c508dacbd5078e%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638046413707443203%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=OWPUPrIHGnzwXyQE4WlIthThwSuSK2y3Eq2Wq5zAzbo%3Dreserved=0
> >> v1->v2: Narrow down locking scope, check the existence of heap before
> >> insertion, as suggested by Andrew Davis.
> >> v2->v3: Remove double checking.
> >> v3->v4: Minor coding style and patch formatting adjustment.
> >> ---
> >> drivers/dma-buf/dma-heap.c | 28 +++-
> >> 1 file changed, 15 insertions(+), 13 deletions(-)
> >>
> >> diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c
> >> index 8f5848aa144f..59d158873f4c 100644
> >> --- a/drivers/dma-buf/dma-heap.c
> >> +++ b/drivers/dma-buf/dma-heap.c
> >> @@ -233,18 +233,6 @@ struct dma_heap *dma_heap_add(const struct
> >> dma_heap_export_info *exp_info)
> >> return ERR_PTR(-EINVAL);
> >> }
> >>
> >> -/* check the name is unique */
> >> -mutex_lock(_list_lock);
> >> -list_for_each_entry(h, _list, list) {
> >> -if (!strcmp(h->name, exp_info->name)) {
> >> -mutex_unlock(_list_lock);
> >> -pr_err("dma_heap: Already registered heap named %s\n",
> >> - exp_info->name);
> >> -return ERR_PTR(-EINVAL);
> >> -}
> >> -}
> >> -mutex_unlock(_list_lock);
> >> -
> >> heap = kzalloc(sizeof(*heap), GFP_KERNEL);
> >> if (!heap)
> >> return ERR_PTR(-ENOMEM);
> >> @@ -283,13 +271,27 @@ struct dma_heap *dma_heap_add(const struct
> >> dma_heap_export_info *exp_info)
> >> err_ret = ERR_CAST(dev_ret);
> >> goto err2;
> >> }
> >> -/* Add heap to the list */
> >> +
> >> mutex_lock(_list_lock);
> >> +/* check the name is unique */
> >> +list_for_each_entry(h, _list, list) {
> >> +if (!strcmp(h->name, exp_info->name)) {
> >> +mutex_unlock(_list_lock);
> >> +pr_err("dma_heap: Already registered heap named %s\n",
> >> + exp_info->name);
> >> +err_ret = ERR_PTR(-EINVAL);
> >> +goto err3;
> >> +}
> >> +}
> >> +
> >> +/* Add heap to the list */
> >> list_add(>list, _list);
> >> mutex_unlock(_list_lock);
> >>
> >> return heap;
> >>
> >> +err3:
> >> +device_destroy(dma_heap_class, heap->heap_devt);
> >> err2:
> >> cdev_del(>heap_cdev);
> >> err1:
> >> --
> >> 2.25.1
> >>
>
--
Thanks and regards,
Sumit Semwal (he / him)
Tech Lead - LCG, Vertical Technologies
Linaro.org │ Open source software for ARM SoCs
Re: [PATCH v5 00/21] Move all drivers to a common dma-buf locking convention
Hi Dmitry, On Wed, 14 Sept 2022 at 00:58, Dmitry Osipenko wrote: > > Hello, > > This series moves all drivers to a dynamic dma-buf locking specification. > From now on all dma-buf importers are made responsible for holding > dma-buf's reservation lock around all operations performed over dma-bufs > in accordance to the locking specification. This allows us to utilize > reservation lock more broadly around kernel without fearing of a potential > deadlocks. Thank you for the excellent work on this series - apart from a minor nit in patch 15, please feel free to add my: Acked-by: Sumit Semwal for the relevant dma-buf patches (1, 2, 15-19, 21). Best regards, Sumit. > > This patchset passes all i915 selftests. It was also tested using VirtIO, > Panfrost, Lima, Tegra, udmabuf, AMDGPU and Nouveau drivers. I tested cases > of display+GPU, display+V4L and GPU+V4L dma-buf sharing (where appropriate), > which covers majority of kernel drivers since rest of the drivers share > same or similar code paths. > > Changelog: > > v5: - Added acks and r-bs that were given to v4. > > - Changed i915 preparation patch like was suggested by Michael Ruhl. > The scope of reservation locking is smaller now. > > v4: - Added dma_buf_mmap() to the "locking convention" documentation, > which was missed by accident in v3. > > - Added acks from Christian König, Tomasz Figa and Hans Verkuil that > they gave to couple v3 patches. > > - Dropped the "_unlocked" postfix from function names that don't have > the locked variant, as was requested by Christian König. > > - Factored out the per-driver preparations into separate patches > to ease reviewing of the changes, which is now doable without the > global dma-buf functions renaming. > > - Factored out the dynamic locking convention enforcements into separate > patches which add the final dma_resv_assert_held(dmabuf->resv) to the > dma-buf API functions. > > v3: - Factored out dma_buf_mmap_unlocked() and attachment functions > into aseparate patches, like was suggested by Christian König. > > - Corrected and factored out dma-buf locking documentation into > a separate patch, like was suggested by Christian König. > > - Intel driver dropped the reservation locking fews days ago from > its BO-release code path, but we need that locking for the imported > GEMs because in the end that code path unmaps the imported GEM. > So I added back the locking needed by the imported GEMs, updating > the "dma-buf attachment locking specification" patch appropriately. > > - Tested Nouveau+Intel dma-buf import/export combo. > > - Tested udmabuf import to i915/Nouveau/AMDGPU. > > - Fixed few places in Etnaviv, Panfrost and Lima drivers that I missed > to switch to locked dma-buf vmapping in the drm/gem: Take reservation > lock for vmap/vunmap operations" patch. In a result invalidated the > Christian's r-b that he gave to v2. > > - Added locked dma-buf vmap/vunmap functions that are needed for fixing > vmappping of Etnaviv, Panfrost and Lima drivers mentioned above. > I actually had this change stashed for the drm-shmem shrinker patchset, > but then realized that it's already needed by the dma-buf patches. > Also improved my tests to better cover these code paths. > > v2: - Changed locking specification to avoid problems with a cross-driver > ww locking, like was suggested by Christian König. Now the attach/detach > callbacks are invoked without the held lock and exporter should take the > lock. > > - Added "locking convention" documentation that explains which dma-buf > functions and callbacks are locked/unlocked for importers and exporters, > which was requested by Christian König. > > - Added ack from Tomasz Figa to the V4L patches that he gave to v1. > > Dmitry Osipenko (21): > dma-buf: Add unlocked variant of vmapping functions > dma-buf: Add unlocked variant of attachment-mapping functions > drm/gem: Take reservation lock for vmap/vunmap operations > drm/prime: Prepare to dynamic dma-buf locking specification > drm/armada: Prepare to dynamic dma-buf locking specification > drm/i915: Prepare to dynamic dma-buf locking specification > drm/omapdrm: Prepare to dynamic dma-buf locking specification > drm/tegra: Prepare to dynamic dma-buf locking specification > drm/etnaviv: Prepare to dynamic dma-buf locking specification > RDMA/umem: Prepare to dynamic dma-buf locking specification > misc: fastrpc: Prepare to dynamic dma-buf locking specification > x
Re: [PATCH v5 15/21] dma-buf: Move dma_buf_vmap() to dynamic locking specification
Hi Dmitry, Thanks very much for the series. On Wed, 14 Sept 2022 at 00:59, Dmitry Osipenko wrote: > > Move dma_buf_vmap/vunmap_unlocked() functions to the dynamic locking > specification by asserting that the reservation lock is held. Thanks for the patch; just a minor nit - I think you mean dma_buf_vmap / vunmap() here, and not _unlocked? Best, Sumit. > > Acked-by: Christian König > Signed-off-by: Dmitry Osipenko > --- > drivers/dma-buf/dma-buf.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c > index 50db7571dc4b..80fd6ccc88c6 100644 > --- a/drivers/dma-buf/dma-buf.c > +++ b/drivers/dma-buf/dma-buf.c > @@ -1450,6 +1450,8 @@ int dma_buf_vmap(struct dma_buf *dmabuf, struct > iosys_map *map) > if (WARN_ON(!dmabuf)) > return -EINVAL; > > + dma_resv_assert_held(dmabuf->resv); > + > if (!dmabuf->ops->vmap) > return -EINVAL; > > @@ -1510,6 +1512,8 @@ void dma_buf_vunmap(struct dma_buf *dmabuf, struct > iosys_map *map) > if (WARN_ON(!dmabuf)) > return; > > + dma_resv_assert_held(dmabuf->resv); > + > BUG_ON(iosys_map_is_null(>vmap_ptr)); > BUG_ON(dmabuf->vmapping_counter == 0); > BUG_ON(!iosys_map_is_equal(>vmap_ptr, map)); > -- > 2.37.3 > -- Thanks and regards, Sumit Semwal (he / him) Tech Lead - LCG, Vertical Technologies Linaro.org │ Open source software for ARM SoCs
Re: [PATCH v2 7/8] dma-buf: remove useless FMODE_LSEEK flag
On Mon, 27 Jun 2022 at 14:38, Daniel Vetter wrote: > > On Sat, Jun 25, 2022 at 01:01:14PM +0200, Jason A. Donenfeld wrote: > > This is already set by anon_inode_getfile(), since dma_buf_fops has > > non-NULL ->llseek, so we don't need to set it here too. > > > > Suggested-by: Al Viro > > Cc: Sumit Semwal > > Cc: Christian König > > Cc: dri-devel@lists.freedesktop.org > > Signed-off-by: Jason A. Donenfeld > > I'm assuming this is part of a vfs cleanup and lands through that tree? > For that: > > Acked-by: Daniel Vetter FWIW, please feel free to add Acked-by: Sumit Semwal > > > --- > > drivers/dma-buf/dma-buf.c | 1 - > > 1 file changed, 1 deletion(-) > > > > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c > > index 32f55640890c..3f08e0b960ec 100644 > > --- a/drivers/dma-buf/dma-buf.c > > +++ b/drivers/dma-buf/dma-buf.c > > @@ -549,7 +549,6 @@ struct dma_buf *dma_buf_export(const struct > > dma_buf_export_info *exp_info) > > goto err_dmabuf; > > } > > > > - file->f_mode |= FMODE_LSEEK; > > dmabuf->file = file; > > > > mutex_init(>lock); > > -- > > 2.35.1 > > > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch Best, Sumit.
Re: [PATCH v2 1/3] drm/panel: nt36672a: add backlight support
Hi Joel, On Wed, 8 Jun 2022 at 22:10, Joel Selvaraj wrote: > > Hi Sumit, > > On 08/06/22 22:00, Sumit Semwal wrote: > > This is entirely my fault - It somehow missed my radar, and I didn't > > queue it up. I will push it via drm-misc tree tonight. Apologies > > again! > > No problem. Thanks for the update! So it will land on upcoming 5.19-rcs > or 5.20-rc? Not for 5.19-rcs for sure, but I think it should make it for 5.20-rcs? > > > Best, > > Sumit. > > Best Regards, > Joel Selvaraj Best, Sumit.
Re: [PATCH v2 1/3] drm/panel: nt36672a: add backlight support
Hi Joel, On Wed, 8 Jun 2022 at 00:01, Joel Selvaraj wrote: > > Hi, > > I can see that the dts changes from this patch series has been applied > to 5.19-rc1 release. However, this patch that has the related change to > the panel driver, is not applied in the 5.19-rc1 release. Any particular > reason why it's not picked up? or just that, it got missed out? Kindly > let me know if changes are required from my end. This is entirely my fault - It somehow missed my radar, and I didn't queue it up. I will push it via drm-misc tree tonight. Apologies again! > > With Regards, > Joel Selvaraj Best, Sumit.
Re: [PATCH] dma-buf: add the name field to the table header
Hi Christian,
On Thu, 28 Apr 2022 at 13:33, Christian König wrote:
>
> Am 28.04.22 um 08:39 schrieb Yuanzheng Song:
> > 'cat /sys/kernel/debug/dma_buf/bufinfo' will print the Dma-buf
> > Objects' information when the CONFIG_DEBUG_FS=y.
> > However, the printed table header information does not contain
> > the name field. So we need to add the name field to the table
> > header and use the '' to replace the empty buf_obj->name.
> >
> > Signed-off-by: Yuanzheng Song
>
> Reviewed-by: Christian König
>
> Sumit do you want to push this or should I go ahead?
No worries, I can push it out.
Thanks :)
>
> > ---
> > drivers/dma-buf/dma-buf.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> > index 79795857be3e..a2f9a1815e38 100644
> > --- a/drivers/dma-buf/dma-buf.c
> > +++ b/drivers/dma-buf/dma-buf.c
> > @@ -1351,7 +1351,7 @@ static int dma_buf_debug_show(struct seq_file *s,
> > void *unused)
> > return ret;
> >
> > seq_puts(s, "\nDma-buf Objects:\n");
> > - seq_printf(s, "%-8s\t%-8s\t%-8s\t%-8s\texp_name\t%-8s\n",
> > + seq_printf(s, "%-8s\t%-8s\t%-8s\t%-8s\texp_name\t%-8s\tname\n",
> > "size", "flags", "mode", "count", "ino");
> >
> > list_for_each_entry(buf_obj, _list.head, list_node) {
> > @@ -1368,7 +1368,7 @@ static int dma_buf_debug_show(struct seq_file *s,
> > void *unused)
> > file_count(buf_obj->file),
> > buf_obj->exp_name,
> > file_inode(buf_obj->file)->i_ino,
> > - buf_obj->name ?: "");
> > + buf_obj->name ?: "");
> > spin_unlock(_obj->name_lock);
> >
> > dma_resv_describe(buf_obj->resv, s);
>
Best,
Sumit.
Re: [PATCH] dma-buf: check the return value of kstrdup()
Hi Xiaoke,
On Tue, 22 Feb 2022 at 17:00, wrote:
>
> From: Xiaoke Wang
>
> kstrdup() is a memory allocation function which can return NULL when
> some internaly memory errors happen. It is better to check the return
> value of it to prevent further wrong memory access.
Thanks for the patch; looks sane.
>
> Signed-off-by: Xiaoke Wang
Acked-by: Sumit Semwal
Will queue it up.
> ---
> drivers/dma-buf/selftest.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/dma-buf/selftest.c b/drivers/dma-buf/selftest.c
> index c60b694..2c29e2a 100644
> --- a/drivers/dma-buf/selftest.c
> +++ b/drivers/dma-buf/selftest.c
> @@ -50,6 +50,9 @@ static bool apply_subtest_filter(const char *caller, const
> char *name)
> bool result = true;
>
> filter = kstrdup(__st_filter, GFP_KERNEL);
> + if (!filter)
> + return false;
> +
> for (sep = filter; (tok = strsep(, ","));) {
> bool allow = true;
> char *sl;
> --
Best,
Sumit.
Re: [PATCH v2] dma-buf-map: Rename to iosys-map
Hello Lucas, On Wed, 2 Feb 2022 at 15:08, Lucas De Marchi wrote: > > On Wed, Feb 02, 2022 at 10:25:28AM +0100, Christian König wrote: > >Am 02.02.22 um 10:11 schrieb Lucas De Marchi: > >>[SNIP] > >>diff --git a/MAINTAINERS b/MAINTAINERS > >>index d03ad8da1f36..112676f11792 100644 > >>--- a/MAINTAINERS > >>+++ b/MAINTAINERS > >>@@ -5675,7 +5675,6 @@ T: git git://anongit.freedesktop.org/drm/drm-misc > >> F: Documentation/driver-api/dma-buf.rst > >> F: drivers/dma-buf/ > >> F: include/linux/*fence.h > > > >Oh, that is not correct to begin with. > > right, include/linux/dma-fence* > > > > >>-F: include/linux/dma-buf* > > > >That here should probably be changed to point directly to > >include/linux/dma-buf.h, but that can come later on. > > thanks for catching that. I will change it on next version and add your > (and any additional) ack. > > Lucas De Marchi > > > > >Feel free to add an Acked-by: Christian König > > to the patch. > > > >If nobody objects I'm going to push it drm-misc-next and provide a > >follow up to cleanup the MAINTAINERS file a bit more. Thank you for the patch; apologies for not being able to respond earlier (was out due to covid, just getting back slowly). With Christian's suggestions, looks good to me as well - feel free to add an Acked-by: Sumit Semwal to the same. > > > >Regards, > >Christian. Best, Sumit. > > > >> F: include/linux/dma-resv.h > >> K: \bdma_(?:buf|fence|resv)\b > >>@@ -9976,6 +9975,13 @@ F: include/linux/iova.h > >> F: include/linux/of_iommu.h > >> F: include/uapi/linux/iommu.h > >>+IOSYS-MAP HELPERS > >>+M: Thomas Zimmermann > >>+L: dri-devel@lists.freedesktop.org > >>+S: Maintained > >>+T: git git://anongit.freedesktop.org/drm/drm-misc > >>+F: include/linux/iosys-map.h > >>+ > >
Re: [PATCH] dma-buf: heaps: Fix potential spectre v1 gadget
Hello Jordy, On Tue, 1 Feb 2022 at 02:09, John Stultz wrote: > > On Sat, Jan 29, 2022 at 7:06 AM Jordy Zomer wrote: > > > > It appears like nr could be a Spectre v1 gadget as it's supplied by a > > user and used as an array index. Prevent the contents > > of kernel memory from being leaked to userspace via speculative > > execution by using array_index_nospec. > > > > Signed-off-by: Jordy Zomer Thanks very much for your patch; I've pushed it to drm-misc-fixes, so we should see it in mainline soon. > > --- > > drivers/dma-buf/dma-heap.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c > > index 56bf5ad01ad5..8f5848aa144f 100644 > > --- a/drivers/dma-buf/dma-heap.c > > +++ b/drivers/dma-buf/dma-heap.c > > @@ -14,6 +14,7 @@ > > #include > > #include > > #include > > +#include > > #include > > #include > > #include > > @@ -135,6 +136,7 @@ static long dma_heap_ioctl(struct file *file, unsigned > > int ucmd, > > if (nr >= ARRAY_SIZE(dma_heap_ioctl_cmds)) > > return -EINVAL; > > > > + nr = array_index_nospec(nr, ARRAY_SIZE(dma_heap_ioctl_cmds)); > > /* Get the kernel ioctl cmd that matches */ > > kcmd = dma_heap_ioctl_cmds[nr]; > > Thanks for submitting this! It looks sane to me. > > Acked-by: John Stultz > > thanks > -john Best, Sumit.
Re: [PATCH] dma-buf: cma_heap: Fix mutex locking section
Hello Weizhao,
On Tue, 4 Jan 2022 at 13:13, John Stultz wrote:
>
> On Mon, Jan 3, 2022 at 11:36 PM Weizhao Ouyang wrote:
> >
> > Fix cma_heap_buffer mutex locking critical section to protect vmap_cnt
> > and vaddr.
> >
> > Fixes: a5d2d29e24be ("dma-buf: heaps: Move heap-helper logic into the
> > cma_heap implementation")
> > Signed-off-by: Weizhao Ouyang
>
> Looks good to me! Thanks so much for sending this in!
Thanks for the patch; it's merged to drm-misc-fixes.
>
> Acked-by: John Stultz
>
> thanks again
> -john
Best,
Sumit.
Re: [PATCH v2] dma-buf: dma-heap: Add a size check for allocation
Hello Guangming, On Wed, 5 Jan 2022 at 12:05, wrote: > > From: Guangming.Cao > > On Tue, 2022-01-04 at 08:47 +0100, Christian K鰊ig wrote: > > Am 03.01.22 um 19:57 schrieb John Stultz: > > > On Mon, Dec 27, 2021 at 1:52 AM wrote: > > > > From: Guangming > > > > > > > > > > Thanks for submitting this! > > > > > > > Add a size check for allcation since the allocation size is > > > > > > nit: "allocation" above. > > > > > > > always less than the total DRAM size. > > > > > > In general, it might be good to add more context to the commit > > > message > > > to better answer *why* this change is needed rather than what the > > > change is doing. ie: What negative thing happens without this > > > change? > > > And so how does this change avoid or improve things? > > > > Completely agree, just one little addition: Could you also add this > > why > > as comment to the code? > > > > When we stumble over this five years from now it is absolutely not > > obvious why we do this. > > > > Thanks, > > Christian. > > > Thanks for your reply! > I will update the related reason in the patch later. > > The reason for adding this check is that we met a case that the user > sent an invalid size(It seems it's a negative value, MSB is 0xff, it's > larger than DRAM size after convert it to size_t) to dma-heap to alloc > memory, and this allocation was running on a process(such as "gralloc" > on Android device) can't be killed by OOM flow, and we also couldn't > find the related dmabuf in "dma_buf_debug_show" because the related > dmabuf was not exported yet since the allocation is still on going. > > Since this invalid argument case can be prevented at dma-heap side, so, > I added this size check, and moreover, to let debug it easily, I also > added logs when size is bigger than a threshold we set in mtk system > heap. > If you think that print logs in dma-heap framework is better, I will > update it in next version. > > If you have better solution(such as dump the size under allocating > in "dma_buf_debug_show", which maybe need add global variable to record > it), please kindly let me know. Thank you for the patch! I think just adding the reasoning above as the commit message and a comment in the code should be enough for now; the debug parts may be easy to add in case someone runs into issues. > Thanks :) > Guangming Best, Sumit. > > > > > > > > > > > Signed-off-by: Guangming > > > > Signed-off-by: jianjiao zeng > > > > --- > > > > v2: 1. update size limitation as total_dram page size. > > > > 2. update commit message > > > > --- > > > > drivers/dma-buf/dma-heap.c | 2 ++ > > > > 1 file changed, 2 insertions(+) > > > > > > > > diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma- > > > > heap.c > > > > index 56bf5ad01ad5..e39d2be98d69 100644 > > > > --- a/drivers/dma-buf/dma-heap.c > > > > +++ b/drivers/dma-buf/dma-heap.c > > > > @@ -55,6 +55,8 @@ static int dma_heap_buffer_alloc(struct > > > > dma_heap *heap, size_t len, > > > > struct dma_buf *dmabuf; > > > > int fd; > > > > > > > > + if (len / PAGE_SIZE > totalram_pages()) > > > > + return -EINVAL; > > > > > > This seems sane. I know ION used to have some 1/2 of memory cap to > > > avoid unnecessary memory pressure on crazy allocations. > > > > > > Could you send again with an improved commit message? > > > > > > thanks > > > -john > > > > -- Thanks and regards, Sumit Semwal (he / him) Tech Lead - LCG, Vertical Technologies Linaro.org │ Open source software for ARM SoCs
Re: [PATCH] MAINTAINERS: Update e-mail addresses for Laura Abbott
Hello Laura, On Wed, 8 Dec 2021 at 04:25, wrote: > > From: Laura Abbott > > Consolodate everything under an @kernel.org address. > > Signed-off-by: Laura Abbott > --- > Sumit, can you take this through your tree? Thanks for the patch; sure I will! > --- > .mailmap| 3 +++ > MAINTAINERS | 2 +- > 2 files changed, 4 insertions(+), 1 deletion(-) > > diff --git a/.mailmap b/.mailmap > index 6277bb27b4bf..e7a5bb0c35ae 100644 > --- a/.mailmap > +++ b/.mailmap > @@ -203,6 +203,9 @@ Koushik > Krzysztof Kozlowski > Krzysztof Kozlowski > Kuninori Morimoto > +Laura Abbott > +Laura Abbott > +Laura Abbott > Leonardo Bras > Leonid I Ananiev > Leon Romanovsky > diff --git a/MAINTAINERS b/MAINTAINERS > index 43007f2d29e0..21ab7c9d1bee 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -5715,7 +5715,7 @@ DMA-BUF HEAPS FRAMEWORK > M: Sumit Semwal > R: Benjamin Gaignard > R: Liam Mark > -R: Laura Abbott > +R: Laura Abbott > R: Brian Starkey > R: John Stultz > L: linux-me...@vger.kernel.org > -- > 2.33.1 > Best, Sumit. -- Thanks and regards, Sumit Semwal (he / him) Tech Lead - LCG, Vertical Technologies Linaro.org │ Open source software for ARM SoCs
Re: [PATCH v4] dma-buf: system_heap: Use 'for_each_sgtable_sg' in pages free flow
Hello Guangming,
On Mon, 29 Nov 2021 at 23:35, John Stultz wrote:
>
> On Thu, Nov 25, 2021 at 11:48 PM wrote:
> >
> > From: Guangming
> >
> > For previous version, it uses 'sg_table.nent's to traverse sg_table in pages
> > free flow.
> > However, 'sg_table.nents' is reassigned in 'dma_map_sg', it means the
> > number of
> > created entries in the DMA adderess space.
> > So, use 'sg_table.nents' in pages free flow will case some pages can't be
> > freed.
> >
> > Here we should use sg_table.orig_nents to free pages memory, but use the
> > sgtable helper 'for each_sgtable_sg'(, instead of the previous rather common
> > helper 'for_each_sg' which maybe cause memory leak) is much better.
Thanks for catching this and the patch; applied to drm-misc-fixes.
> >
> > Fixes: d963ab0f15fb0 ("dma-buf: system_heap: Allocate higher order pages if
> > available")
> > Signed-off-by: Guangming
> > Reviewed-by: Robin Murphy
> > Cc: # 5.11.*
>
> Thanks so much for catching this and sending in all the revisions!
>
> Reviewed-by: John Stultz
Best,
Sumit.
--
Thanks and regards,
Sumit Semwal (he / him)
Tech Lead - LCG, Vertical Technologies
Linaro.org │ Open source software for ARM SoCs
Re: [PATCH v2] dma-buf: move dma-buf symbols into the DMA_BUF module namespace
Hi Greg, On Mon, 25 Oct 2021 at 16:29, Christian König wrote: > > Am 25.10.21 um 12:36 schrieb Greg Kroah-Hartman: > > On Sun, Oct 10, 2021 at 02:46:28PM +0200, Greg Kroah-Hartman wrote: > >> In order to better track where in the kernel the dma-buf code is used, > >> put the symbols in the namespace DMA_BUF and modify all users of the > >> symbols to properly import the namespace to not break the build at the > >> same time. > >> > >> Now the output of modinfo shows the use of these symbols, making it > >> easier to watch for users over time: > >> > >> $ modinfo drivers/misc/fastrpc.ko | grep import > >> import_ns: DMA_BUF > >> > >> Cc: "Pan, Xinhui" > >> Cc: David Airlie > >> Cc: Maarten Lankhorst > >> Cc: Maxime Ripard > >> Cc: Thomas Zimmermann > >> Cc: Mauro Carvalho Chehab > >> Cc: dri-devel@lists.freedesktop.org > >> Acked-by: Daniel Vetter > >> Acked-by: Christian König > >> Acked-by: Arnd Bergmann > >> Acked-by: Sumit Semwal > >> Acked-by: Alex Deucher > >> Signed-off-by: Greg Kroah-Hartman > >> --- > >> v2: added lots of acks > >> added 2 more drivers that needed the change, as found by Arnd > > Ping? Any ideas on what needs to happen to get this into the tree? > > > > Or can I take it through my char-misc tree? I seem to have a bunch of > > acks on it by the respective maintainers... > > I could push that upstream through the drm-misc-next tree if you like, > but honestly char-misc sounds like the better approach since this > touches a lot of drivers outside of drm as well. I agree with Christian here - char-misc might be a better way for this. > > > Thanks, > Christian. > > > > > thanks, > > > > greg k-h > Best, Sumit.
Re: [PATCH] dma-buf: fix kerneldoc for renamed members
Hi Christian,
On Thu, 21 Oct 2021 at 19:55, Alex Deucher wrote:
> On Thu, Oct 21, 2021 at 10:19 AM Christian König
> wrote:
> >
> > Those members where renamed, update the kerneldoc as well.
> >
> > Signed-off-by: Christian König
>
> Reviewed-by: Alex Deucher
>
LGTM, but perhaps you want to send it from your amd.com account?
Acked-by: Sumit Semwal
>
> > ---
> > include/linux/dma-buf.h | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> > index 02c2eb874da6..9807aef33685 100644
> > --- a/include/linux/dma-buf.h
> > +++ b/include/linux/dma-buf.h
> > @@ -433,8 +433,8 @@ struct dma_buf {
> > /** @poll: for userspace poll support */
> > wait_queue_head_t poll;
> >
> > - /** @cb_excl: for userspace poll support */
> > - /** @cb_shared: for userspace poll support */
> > + /** @cb_in: for userspace poll support */
> > + /** @cb_out: for userspace poll support */
> > struct dma_buf_poll_cb_t {
> > struct dma_fence_cb cb;
> > wait_queue_head_t *poll;
> > --
> > 2.25.1
> >
>
Best,
Sumit.
--
Thanks and regards,
Sumit Semwal (he / him)
Tech Lead - LCG, Vertical Technologies
Linaro.org │ Open source software for ARM SoCs
Re: [PATCH v2] dma-buf: remove restriction of IOCTL:DMA_BUF_SET_NAME
Hello Guangming, Christian,
On Tue, 12 Oct 2021, 14:09 , wrote:
> From: Guangming Cao
>
> > Am 09.10.21 um 07:55 schrieb guangming@mediatek.com:
> > From: Guangming Cao
> > >
> > > If dma-buf don't want userspace users to touch the dmabuf buffer,
> > > it seems we should add this restriction into dma_buf_ops.mmap,
> > > not in this IOCTL:DMA_BUF_SET_NAME.
> > >
> > > With this restriction, we can only know the kernel users of the dmabuf
> > > by attachments.
> > > However, for many userspace users, such as userpsace users of dma_heap,
> > > they also need to mark the usage of dma-buf, and they don't care about
> > > who attached to this dmabuf, and seems it's no meaning to be waiting
> for
> > > IOCTL:DMA_BUF_SET_NAME rather than mmap.
> >
> > Sounds valid to me, but I have no idea why this restriction was added in
> > the first place.
> >
> > Can you double check the git history and maybe identify when that was
> > added? Mentioning this change in the commit message then might make
> > things a bit easier to understand.
> >
> > Thanks,
> > Christian.
> It was add in this patch: https://patchwork.freedesktop.org/patch/310349/.
> However, there is no illustration about it.
> I guess it wants users to set_name when no attachments on the dmabuf,
> for case with attachments, we can find owner by device in attachments.
> But just I said in commit message, this is might not a good idea.
>
> Do you have any idea?
>
For the original series, the idea was that allowing name change mid-use
could confuse the users about the dma-buf. However, the rest of the series
also makes sure each dma-buf have a unique inode, and any accounting should
probably use that, without relying on the name as much.
So I don't have an objection to this change.
Best,
Sumit.
> >
> > >
> > > Signed-off-by: Guangming Cao
> > > ---
> > > drivers/dma-buf/dma-buf.c | 14 ++
> > > 1 file changed, 2 insertions(+), 12 deletions(-)
> > >
> > > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> > > index 511fe0d217a0..db2f4efdec32 100644
> > > --- a/drivers/dma-buf/dma-buf.c
> > > +++ b/drivers/dma-buf/dma-buf.c
> > > @@ -325,10 +325,8 @@ static __poll_t dma_buf_poll(struct file *file,
> poll_table *poll)
> > >
> > > /**
> > >* dma_buf_set_name - Set a name to a specific dma_buf to track the
> usage.
> > > - * The name of the dma-buf buffer can only be set when the dma-buf is
> not
> > > - * attached to any devices. It could theoritically support changing
> the
> > > - * name of the dma-buf if the same piece of memory is used for
> multiple
> > > - * purpose between different devices.
> > > + * It could theoretically support changing the name of the dma-buf if
> the same
> > > + * piece of memory is used for multiple purpose between different
> devices.
> > >*
> > >* @dmabuf: [in] dmabuf buffer that will be renamed.
> > >* @buf:[in] A piece of userspace memory that contains the
> name of
> > > @@ -346,19 +344,11 @@ static long dma_buf_set_name(struct dma_buf
> *dmabuf, const char __user *buf)
> > > if (IS_ERR(name))
> > > return PTR_ERR(name);
> > >
> > > - dma_resv_lock(dmabuf->resv, NULL);
> > > - if (!list_empty(>attachments)) {
> > > - ret = -EBUSY;
> > > - kfree(name);
> > > - goto out_unlock;
> > > - }
> > > spin_lock(>name_lock);
> > > kfree(dmabuf->name);
> > > dmabuf->name = name;
> > > spin_unlock(>name_lock);
> > >
> > > -out_unlock:
> > > - dma_resv_unlock(dmabuf->resv);
> > > return ret;
> > > }
> > >
>
Re: [PATCH] dma-buf: move dma-buf symbols into the DMA_BUF module namespace
Hello Greg,
Thanks for the patch!
On Sat, 25 Sept 2021 at 19:17, Greg Kroah-Hartman <
gre...@linuxfoundation.org> wrote:
> In order to better track where in the kernel the dma-buf code is used,
> put the symbols in the namespace DMA_BUF and modify all users of the
> symbols to properly import the namespace to not break the build at the
> same time.
>
> Now the output of modinfo shows the use of these symbols, making it
> easier to watch for users over time:
>
> $ modinfo drivers/misc/fastrpc.ko | grep import
> import_ns: DMA_BUF
>
> Cc: Sumit Semwal
> Cc: "Christian König"
> Cc: Alex Deucher
> Cc: "Pan, Xinhui"
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Thomas Zimmermann
> Cc: Mauro Carvalho Chehab
> Cc: Arnd Bergmann
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Greg Kroah-Hartman
>
With the addition of the 2 misses found by Arnd, please feel free to add my
Acked-by: Sumit Semwal
> ---
>
> The topic of dma-buf came up in the Maintainer's summit yesterday, and
> one comment was to put the symbols in their own module namespace, to
> make it easier to notice and track who was using them. This patch does
> so, and finds some "interesting" users of the api already in the tree.
>
> Only test-built on x86 allmodconfig, don't know what other arches will
> pick up, will let 0-day run on it for a bit...
>
> Comments?
>
>
> drivers/dma-buf/dma-buf.c | 34 +--
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 3 ++
> drivers/gpu/drm/drm_gem_framebuffer_helper.c | 3 ++
> drivers/gpu/drm/drm_prime.c | 3 ++
> drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 3 ++
> drivers/gpu/drm/exynos/exynos_drm_gem.c | 3 ++
> drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 3 ++
> drivers/gpu/drm/tegra/gem.c | 3 ++
> drivers/gpu/drm/vmwgfx/ttm_object.c | 3 ++
> drivers/infiniband/core/umem_dmabuf.c | 3 ++
> .../media/common/videobuf2/videobuf2-core.c | 1 +
> .../common/videobuf2/videobuf2-dma-contig.c | 1 +
> .../media/common/videobuf2/videobuf2-dma-sg.c | 1 +
> .../common/videobuf2/videobuf2-vmalloc.c | 1 +
> drivers/misc/fastrpc.c| 1 +
> .../staging/media/tegra-vde/dmabuf-cache.c| 3 ++
> drivers/tee/tee_shm.c | 3 ++
> drivers/virtio/virtio_dma_buf.c | 1 +
> drivers/xen/gntdev-dmabuf.c | 3 ++
> samples/vfio-mdev/mbochs.c| 1 +
> 20 files changed, 60 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 63d32261b63f..6c2b5ea828a6 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -610,7 +610,7 @@ struct dma_buf *dma_buf_export(const struct
> dma_buf_export_info *exp_info)
> module_put(exp_info->owner);
> return ERR_PTR(ret);
> }
> -EXPORT_SYMBOL_GPL(dma_buf_export);
> +EXPORT_SYMBOL_NS_GPL(dma_buf_export, DMA_BUF);
>
> /**
> * dma_buf_fd - returns a file descriptor for the given struct dma_buf
> @@ -634,7 +634,7 @@ int dma_buf_fd(struct dma_buf *dmabuf, int flags)
>
> return fd;
> }
> -EXPORT_SYMBOL_GPL(dma_buf_fd);
> +EXPORT_SYMBOL_NS_GPL(dma_buf_fd, DMA_BUF);
>
> /**
> * dma_buf_get - returns the struct dma_buf related to an fd
> @@ -660,7 +660,7 @@ struct dma_buf *dma_buf_get(int fd)
>
> return file->private_data;
> }
> -EXPORT_SYMBOL_GPL(dma_buf_get);
> +EXPORT_SYMBOL_NS_GPL(dma_buf_get, DMA_BUF);
>
> /**
> * dma_buf_put - decreases refcount of the buffer
> @@ -679,7 +679,7 @@ void dma_buf_put(struct dma_buf *dmabuf)
>
> fput(dmabuf->file);
> }
> -EXPORT_SYMBOL_GPL(dma_buf_put);
> +EXPORT_SYMBOL_NS_GPL(dma_buf_put, DMA_BUF);
>
> static void mangle_sg_table(struct sg_table *sg_table)
> {
> @@ -810,7 +810,7 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct
> device *dev,
> dma_buf_detach(dmabuf, attach);
> return ERR_PTR(ret);
> }
> -EXPORT_SYMBOL_GPL(dma_buf_dynamic_attach);
> +EXPORT_SYMBOL_NS_GPL(dma_buf_dynamic_attach, DMA_BUF);
>
> /**
> * dma_buf_attach - Wrapper for dma_buf_dynamic_attach
> @@ -825,7 +825,7 @@ struct dma_buf_attachment *dma_buf_attach(struct
> dma_buf *dmabuf,
> {
> return dma_buf_dynamic_attach(dmabuf, dev, NULL, NULL);
> }
> -EXPORT_SYMBOL_GPL(dma_buf_attach);
> +EXPORT_SYMBOL_NS_GPL(dma_buf_attach, DMA_BUF);
>
> static void __unmap_dma_buf(struct dma_buf_attachment *attach,
>
Re: [PATCH] dma-buf: system_heap: Avoid warning on mid-order allocations
Thanks John!
On Tue, 14 Sept 2021 at 19:26, Daniel Vetter wrote:
>
> On Thu, Sep 09, 2021 at 02:37:41AM +, John Stultz wrote:
> > When trying to do mid-order allocations, set __GFP_NOWARN to
> > avoid warning messages if the allocation fails, as we will
> > still fall back to single page allocatitions in that case.
> > This is the similar to what we already do for large order
> > allocations.
> >
> > Cc: Daniel Vetter
> > Cc: Christian Koenig
> > Cc: Sumit Semwal
> > Cc: Liam Mark
> > Cc: Chris Goldsworthy
> > Cc: Laura Abbott
> > Cc: Brian Starkey
> > Cc: Hridya Valsaraju
> > Cc: Suren Baghdasaryan
> > Cc: Sandeep Patil
> > Cc: Daniel Mentz
> > Cc: Ørjan Eide
> > Cc: Robin Murphy
> > Cc: Simon Ser
> > Cc: James Jones
> > Cc: Leo Yan
> > Cc: linux-me...@vger.kernel.org
> > Cc: dri-devel@lists.freedesktop.org
> > Signed-off-by: John Stultz
>
> Acked-by: Daniel Vetter
>
Pushed to drm-misc-next.
> > ---
> > drivers/dma-buf/heaps/system_heap.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/dma-buf/heaps/system_heap.c
> > b/drivers/dma-buf/heaps/system_heap.c
> > index 23a7e74ef966..f57a39ddd063 100644
> > --- a/drivers/dma-buf/heaps/system_heap.c
> > +++ b/drivers/dma-buf/heaps/system_heap.c
> > @@ -40,11 +40,12 @@ struct dma_heap_attachment {
> > bool mapped;
> > };
> >
> > +#define LOW_ORDER_GFP (GFP_HIGHUSER | __GFP_ZERO | __GFP_COMP)
> > +#define MID_ORDER_GFP (LOW_ORDER_GFP | __GFP_NOWARN)
> > #define HIGH_ORDER_GFP (((GFP_HIGHUSER | __GFP_ZERO | __GFP_NOWARN \
> > | __GFP_NORETRY) & ~__GFP_RECLAIM) \
> > | __GFP_COMP)
> > -#define LOW_ORDER_GFP (GFP_HIGHUSER | __GFP_ZERO | __GFP_COMP)
> > -static gfp_t order_flags[] = {HIGH_ORDER_GFP, LOW_ORDER_GFP,
> > LOW_ORDER_GFP};
> > +static gfp_t order_flags[] = {HIGH_ORDER_GFP, MID_ORDER_GFP,
> > LOW_ORDER_GFP};
> > /*
> > * The selection of the orders used for allocation (1MB, 64K, 4K) is
> > designed
> > * to match with the sizes often found in IOMMUs. Using order 4 pages
> > instead
> > --
> > 2.25.1
> >
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
Best,
Sumit.
Re: [PATCH 0/3] dma-buf: Add missing dependencies on DMA_SHARED_BUFFER
Hello Geert,
On Thu, 2 Sept 2021 at 18:19, Geert Uytterhoeven wrote:
>
> Hi Sumit, Christian,
>
> This patch series adds missing dependencies on DMA_SHARED_BUFFER to
> various options of DMA-BUF, and drops a bogus select.
>
> As drivers/dma-buf/Kconfig contains interleaved options that select or
> depend on DMA_SHARED_BUFFER, they can't be wrapped inside a big
> "if DMA_SHARED_BUFFER / endif" block.
Thanks for catching these issues and the patch-set. LGTM!
I'll apply them over.
>
> Thanks!
>
> Geert Uytterhoeven (3):
> dma-buf: DMABUF_MOVE_NOTIFY should depend on DMA_SHARED_BUFFER
> dma-buf: DMABUF_DEBUG should depend on DMA_SHARED_BUFFER
> dma-buf: DMABUF_SYSFS_STATS should depend on DMA_SHARED_BUFFER
>
> drivers/dma-buf/Kconfig | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> --
> 2.25.1
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
Best,
Sumit.
Re: [PATCH] dma-buf: cleanup kerneldoc of removed component
Hi Christian,
On Wed, 1 Sept 2021 at 13:30, Christian König
wrote:
>
> The seqno-fence was removed, cleanup the kerneldoc include as well.
>
> Signed-off-by: Christian König
> Fixes: 992c238188a8 ("dma-buf: nuke seqno-fence")
Thanks for fixing; LGTM, please feel free to add my
Acked-by: Sumit Semwal
Or I could push it as well, if you'd like.
> ---
> Documentation/driver-api/dma-buf.rst | 6 --
> 1 file changed, 6 deletions(-)
>
> diff --git a/Documentation/driver-api/dma-buf.rst
> b/Documentation/driver-api/dma-buf.rst
> index f5ac4c90b237..2cd7db82d9fe 100644
> --- a/Documentation/driver-api/dma-buf.rst
> +++ b/Documentation/driver-api/dma-buf.rst
> @@ -176,12 +176,6 @@ DMA Fences Functions Reference
> .. kernel-doc:: include/linux/dma-fence.h
> :internal:
>
> -Seqno Hardware Fences
> -~
> -
> -.. kernel-doc:: include/linux/seqno-fence.h
> - :internal:
> -
> DMA Fence Array
> ~~~
>
> --
> 2.25.1
>
Best,
Sumit.
Re: [PATCH] dma-buf: heaps: Set allocation limit for system heap
Hi Hridya, Apologies for the delay in responding; On Wed, 4 Aug 2021 at 03:09, Hridya Valsaraju wrote: > > On Mon, Aug 2, 2021 at 7:18 PM John Stultz wrote: > > > > On Thu, Jul 22, 2021 at 12:07 PM Hridya Valsaraju wrote: > > > This patch limits the size of total memory that can be requested in a > > > single allocation from the system heap. This would prevent a > > > buggy/malicious client from depleting system memory by requesting for an > > > extremely large allocation which might destabilize the system. > > > > > > The limit is set to half the size of the device's total RAM which is the > > > same as what was set by the deprecated ION system heap. > > > > > > Signed-off-by: Hridya Valsaraju > > > > Seems sane to me, unless folks have better suggestions for allocation > > limits. > > > > Reviewed-by: John Stultz > > Thank you for taking a look John! Looks good to me; I will apply it to drm-misc today. > > Regards, > Hridya > > > > > thanks > > -john Best, Sumit. -- Thanks and regards, Sumit Semwal (he / him) Tech Lead - LCG, Vertical Technologies Linaro.org │ Open source software for ARM SoCs
Re: [PATCH] dma-buf: heaps: Set allocation limit for system heap
Hi Hridya, Apologies for the delay in responding. On Wed, 4 Aug 2021 at 03:09, Hridya Valsaraju wrote: > On Mon, Aug 2, 2021 at 7:18 PM John Stultz wrote: > > > > On Thu, Jul 22, 2021 at 12:07 PM Hridya Valsaraju > wrote: > > > This patch limits the size of total memory that can be requested in a > > > single allocation from the system heap. This would prevent a > > > buggy/malicious client from depleting system memory by requesting for > an > > > extremely large allocation which might destabilize the system. > > > > > > The limit is set to half the size of the device's total RAM which is > the > > > same as what was set by the deprecated ION system heap. > > > > > > Signed-off-by: Hridya Valsaraju > > > > Seems sane to me, unless folks have better suggestions for allocation > limits. > > > > Reviewed-by: John Stultz > > Thank you for taking a look John! > Looks good to me; I will apply it to drm-misc today. > > Regards, > Hridya > > > > > thanks > > -john > Best, Sumit. -- Thanks and regards, Sumit Semwal (he / him) Tech Lead - LCG, Vertical Technologies Linaro.org │ Open source software for ARM SoCs
Re: [PATCH 4/7] dma-buf: Document DMA_BUF_IOCTL_SYNC
Hi Daniel,
On Thu, 27 May 2021 at 16:08, Daniel Vetter wrote:
> On Tue, May 25, 2021 at 04:17:50PM -0500, Jason Ekstrand wrote:
> > This adds a new "DMA Buffer ioctls" section to the dma-buf docs and adds
> > documentation for DMA_BUF_IOCTL_SYNC.
> >
> > Signed-off-by: Jason Ekstrand
> > Cc: Daniel Vetter
> > Cc: Christian König
> > Cc: Sumit Semwal
>
> We're still missing the doc for the SET_NAME ioctl, but maybe Sumit can be
> motivated to fix that?
>
Yes, certainly, I'll cook up a patch and send it soon.
>
> > ---
> > Documentation/driver-api/dma-buf.rst | 8 +++
> > include/uapi/linux/dma-buf.h | 32 +++-
> > 2 files changed, 39 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/driver-api/dma-buf.rst
> b/Documentation/driver-api/dma-buf.rst
> > index 7f37ec30d9fd7..784f84fe50a5e 100644
> > --- a/Documentation/driver-api/dma-buf.rst
> > +++ b/Documentation/driver-api/dma-buf.rst
> > @@ -88,6 +88,9 @@ consider though:
> > - The DMA buffer FD is also pollable, see `Implicit Fence Poll
> Support`_ below for
> >details.
> >
> > +- The DMA buffer FD also supports a few dma-buf-specific ioctls, see
> > + `DMA Buffer ioctls`_ below for details.
> > +
> > Basic Operation and Device DMA Access
> > ~
> >
> > @@ -106,6 +109,11 @@ Implicit Fence Poll Support
> > .. kernel-doc:: drivers/dma-buf/dma-buf.c
> > :doc: implicit fence polling
> >
> > +DMA Buffer ioctls
> > +~
> > +
> > +.. kernel-doc:: include/uapi/linux/dma-buf.h
> > +
> > Kernel Functions and Structures Reference
> > ~
> >
> > diff --git a/include/uapi/linux/dma-buf.h b/include/uapi/linux/dma-buf.h
> > index 7f30393b92c3b..1f67ced853b14 100644
> > --- a/include/uapi/linux/dma-buf.h
> > +++ b/include/uapi/linux/dma-buf.h
> > @@ -22,8 +22,38 @@
> >
> > #include
> >
> > -/* begin/end dma-buf functions used for userspace mmap. */
> > +/**
> > + * struct dma_buf_sync - Synchronize with CPU access.
> > + *
> > + * When a DMA buffer is accessed from the CPU via mmap, it is not always
> > + * possible to guarantee coherency between the CPU-visible map and
> underlying
> > + * memory. To manage coherency, DMA_BUF_IOCTL_SYNC must be used to
> bracket
> > + * any CPU access to give the kernel the chance to shuffle memory
> around if
> > + * needed.
> > + *
> > + * Prior to accessing the map, the client should call DMA_BUF_IOCTL_SYNC
>
> s/should/must/
>
> > + * with DMA_BUF_SYNC_START and the appropriate read/write flags. Once
> the
> > + * access is complete, the client should call DMA_BUF_IOCTL_SYNC with
> > + * DMA_BUF_SYNC_END and the same read/write flags.
>
> I think we should make it really clear here that this is _only_ for cache
> coherency, and that furthermore if you want coherency with gpu access you
> either need to use poll() for implicit sync (link to the relevant section)
> or handle explicit sync with sync_file (again link would be awesome).
>
> > + */
> > struct dma_buf_sync {
> > + /**
> > + * @flags: Set of access flags
> > + *
> > + * - DMA_BUF_SYNC_START: Indicates the start of a map access
>
> Bikeshed, but I think the item list format instead of bullet point list
> looks neater, e.g. DOC: standard plane properties in drm_plane.c.
>
>
> > + * session.
> > + *
> > + * - DMA_BUF_SYNC_END: Indicates the end of a map access session.
> > + *
> > + * - DMA_BUF_SYNC_READ: Indicates that the mapped DMA buffer will
> > + * be read by the client via the CPU map.
> > + *
> > + * - DMA_BUF_SYNC_READ: Indicates that the mapped DMA buffer will
>
> s/READ/WRITE/
>
> > + * be written by the client via the CPU map.
> > + *
> > + * - DMA_BUF_SYNC_RW: An alias for DMA_BUF_SYNC_READ |
> > + * DMA_BUF_SYNC_WRITE.
> > + */
>
> With the nits addressed: Reviewed-by: Daniel Vetter <
> daniel.vet...@ffwll.ch>
>
> > __u64 flags;
> > };
> >
> > --
> > 2.31.1
> >
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
>
Best,
Sumit.
--
Thanks and regards,
Sumit Semwal
Tech Lead - Android, Vertical Technologies
Linaro.org │ Open source software for ARM SoCs
Re: [RFC][PATCH 2/2] dma-buf: heaps: Fix the name used when exporting dmabufs to be the actual heap name
Hi Daniel, On Tue, 9 Feb 2021 at 02:36, Daniel Vetter wrote: > > On Mon, Feb 8, 2021 at 9:51 PM John Stultz wrote: > > On Mon, Feb 8, 2021 at 2:08 AM Daniel Vetter wrote: > > > On Sat, Feb 06, 2021 at 05:47:48AM +, John Stultz wrote: > > > > By default dma_buf_export() sets the exporter name to be > > > > KBUILD_MODNAME. Unfortunately this may not be identical to the > > > > string used as the heap name (ie: "system" vs "system_heap"). > > > > > > > > This can cause some minor confusion with tooling, and there is > > > > the future potential where multiple heap types may be exported > > > > by the same module (but would all have the same name). > > > > > > > > So to avoid all this, set the exporter exp_name to the heap name. > > > > > > > > Cc: Daniel Vetter > > > > Cc: Sumit Semwal > > > > Cc: Liam Mark > > > > Cc: Chris Goldsworthy > > > > Cc: Laura Abbott > > > > Cc: Brian Starkey > > > > Cc: Hridya Valsaraju > > > > Cc: Suren Baghdasaryan > > > > Cc: Sandeep Patil > > > > Cc: Daniel Mentz > > > > Cc: Ørjan Eide > > > > Cc: Robin Murphy > > > > Cc: Ezequiel Garcia > > > > Cc: Simon Ser > > > > Cc: James Jones > > > > Cc: linux-me...@vger.kernel.org > > > > Cc: dri-devel@lists.freedesktop.org > > > > Signed-off-by: John Stultz > > > > > > Looks reasonable to me. > > > > > > I guess the main worry is "does this mean heap names become uapi", in > > > which case I'm maybe not so sure anymore how this will tie into the > > > overall gpu memory accounting story. > > > > > > Since for dma-buf heaps one name per buffer is perfectly fine, since > > > dma-buf heaps aren't very dynamic. But on discrete gpu drivers buffers > > > move, so baking in the assumption that "exporter name = resource usage for > > > this buffer" is broken. > > > > I suspect I'm missing a subtlety in what you're describing. My sense > > of the exporter name doesn't account for a buffer's usage, it just > > describes what code allocated it and implicitly which dmabuf_ops > > handles it. Maybe could you give a more specific example of what > > you're hoping to avoid? > > Just paranoia really - on the linux side where we allocate most > buffers (even shared ones) with the driver, that allocator info isn't > that meaningful, it really just tells you which code > allocated/exported that dma-buf. > > But on Android, where all shared buffers come from specific heaps, it > is rather meaningful information. So I wondered whether e.g. the > android dmabuf debug tool uses that to collect per-heap stats, but > sounds like no right now. Plus with the chat we've had I think we have > a long-term plan for how to expose that information properly. > > > To me this patch is mostly just a consistency/least-surprise thing, so > > the heaps exporter name matches the string used for the heap's chardev > > device (the interface used to allocate it) in output like > > debugfs/dma_buf/bufinfo. > > Yeah for debug this makes sense. a-b: me if you want that somewhere on > the patches. Great that this got sorted; I'll apply both the patches of this series to drm-misc-next, with your a-b. > -Daniel Best Sumit. > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch -- Thanks and regards, Sumit Semwal Linaro Consumer Group - Tech Lead Linaro.org │ Open source software for ARM SoCs ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linaro-mm-sig] [PATCH v3] dmabuf: Add the capability to expose DMA-BUF stats in sysfs
Hi Simon, On Thu, 28 Jan 2021 at 20:01, Simon Ser wrote: > > On Thursday, January 28th, 2021 at 1:03 PM, Sumit Semwal > wrote: > > > Since he didn't comment over Hridya's last clarification about the > > tracepoints to track total GPU memory allocations being orthogonal to > > this series, I assumed he agreed with it. > > IIRC he's away this week. (I don't remember when he comes back.) > > > Daniel, do you still have objections around adding this patch in? > > (Adding him explicitly in CC) Thanks for doing this! Best, Sumit. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linaro-mm-sig] [PATCH v3] dmabuf: Add the capability to expose DMA-BUF stats in sysfs
On Thu, 28 Jan 2021 at 17:23, Christian König wrote: > > Am 28.01.21 um 12:00 schrieb Sumit Semwal: > > Hi Hridya, > > > > On Wed, 27 Jan 2021 at 17:36, Greg KH wrote: > >> On Tue, Jan 26, 2021 at 12:42:36PM -0800, Hridya Valsaraju wrote: > >>> This patch allows statistics to be enabled for each DMA-BUF in > >>> sysfs by enabling the config CONFIG_DMABUF_SYSFS_STATS. > >>> > >>> The following stats will be exposed by the interface: > >>> > >>> /sys/kernel/dmabuf/buffers//exporter_name > >>> /sys/kernel/dmabuf/buffers//size > >>> /sys/kernel/dmabuf/buffers//attachments//device > >>> /sys/kernel/dmabuf/buffers//attachments//map_counter > >>> > >>> The inode_number is unique for each DMA-BUF and was added earlier [1] > >>> in order to allow userspace to track DMA-BUF usage across different > >>> processes. > >>> > >>> Currently, this information is exposed in > >>> /sys/kernel/debug/dma_buf/bufinfo. > >>> However, since debugfs is considered unsafe to be mounted in production, > >>> it is being duplicated in sysfs. > >>> > >>> This information will be used to derive DMA-BUF > >>> per-exporter stats and per-device usage stats for Android Bug reports. > >>> The corresponding userspace changes can be found at [2]. > >>> Telemetry tools will also capture this information(along with other > >>> memory metrics) periodically as well as on important events like a > >>> foreground app kill (which might have been triggered by Low Memory > >>> Killer). It will also contribute to provide a snapshot of the system > >>> memory usage on other events such as OOM kills and Application Not > >>> Responding events. > >>> > >>> A shell script that can be run on a classic Linux environment to read > >>> out the DMA-BUF statistics can be found at [3](suggested by John > >>> Stultz). > >>> > >>> The patch contains the following improvements over the previous version: > >>> 1) Each attachment is represented by its own directory to allow creating > >>> a symlink to the importing device and to also provide room for future > >>> expansion. > >>> 2) The number of distinct mappings of each attachment is exposed in a > >>> separate file. > >>> 3) The per-buffer statistics are now in /sys/kernel/dmabuf/buffers > >>> inorder to make the interface expandable in future. > >>> > >>> All of the improvements above are based on suggestions/feedback from > >>> Daniel Vetter and Christian König. > >>> > >>> [1]: https://lore.kernel.org/patchwork/patch/1088791/ > >>> [2]: > >>> https://android-review.googlesource.com/q/topic:%22dmabuf-sysfs%22+(status:open%20OR%20status:merged) > >>> [3]: > >>> https://android-review.googlesource.com/c/platform/system/memory/libmeminfo/+/1549734 > >>> > >>> Signed-off-by: Hridya Valsaraju > >>> Reported-by: kernel test robot > > Thanks for the patch! > > > > Christian: If you're satisfied with the explanation around not > > directly embedding kobjects into the dma_buf and dma_buf_attachment > > structs, then with Greg's r-b from sysfs PoV, I think we can merge it. > > Please let me know if you feel otherwise! > > From the technical side it looks clean to me, feel free to add my > acked-by while pushing. > > But I would at least try to convince Daniel on the design. At least some > of his concerns seems to be valid and keep in mind that we need to > support this interface forever. Naturally. Since he didn't comment over Hridya's last clarification about the tracepoints to track total GPU memory allocations being orthogonal to this series, I assumed he agreed with it. Daniel, do you still have objections around adding this patch in? > > Regards, > Christian. Best, Sumit. > > > > >>> --- > >>> Changes in v3: > >>> Fix a warning reported by the kernel test robot. > >>> > >>> Changes in v2: > >>> -Move statistics to /sys/kernel/dmabuf/buffers in oder to allow addition > >>> of other DMA-BUF-related sysfs stats in future. Based on feedback from > >>> Daniel Vetter. > >>> -Each attachment has its own directory to represent attaching devices as > >>> symlinks and to introduce map_count as a separate file. Based on > >>> feedback from Daniel Vette
Re: [PATCH v3] dmabuf: Add the capability to expose DMA-BUF stats in sysfs
Hi Hridya, On Wed, 27 Jan 2021 at 17:36, Greg KH wrote: > > On Tue, Jan 26, 2021 at 12:42:36PM -0800, Hridya Valsaraju wrote: > > This patch allows statistics to be enabled for each DMA-BUF in > > sysfs by enabling the config CONFIG_DMABUF_SYSFS_STATS. > > > > The following stats will be exposed by the interface: > > > > /sys/kernel/dmabuf/buffers//exporter_name > > /sys/kernel/dmabuf/buffers//size > > /sys/kernel/dmabuf/buffers//attachments//device > > /sys/kernel/dmabuf/buffers//attachments//map_counter > > > > The inode_number is unique for each DMA-BUF and was added earlier [1] > > in order to allow userspace to track DMA-BUF usage across different > > processes. > > > > Currently, this information is exposed in > > /sys/kernel/debug/dma_buf/bufinfo. > > However, since debugfs is considered unsafe to be mounted in production, > > it is being duplicated in sysfs. > > > > This information will be used to derive DMA-BUF > > per-exporter stats and per-device usage stats for Android Bug reports. > > The corresponding userspace changes can be found at [2]. > > Telemetry tools will also capture this information(along with other > > memory metrics) periodically as well as on important events like a > > foreground app kill (which might have been triggered by Low Memory > > Killer). It will also contribute to provide a snapshot of the system > > memory usage on other events such as OOM kills and Application Not > > Responding events. > > > > A shell script that can be run on a classic Linux environment to read > > out the DMA-BUF statistics can be found at [3](suggested by John > > Stultz). > > > > The patch contains the following improvements over the previous version: > > 1) Each attachment is represented by its own directory to allow creating > > a symlink to the importing device and to also provide room for future > > expansion. > > 2) The number of distinct mappings of each attachment is exposed in a > > separate file. > > 3) The per-buffer statistics are now in /sys/kernel/dmabuf/buffers > > inorder to make the interface expandable in future. > > > > All of the improvements above are based on suggestions/feedback from > > Daniel Vetter and Christian König. > > > > [1]: https://lore.kernel.org/patchwork/patch/1088791/ > > [2]: > > https://android-review.googlesource.com/q/topic:%22dmabuf-sysfs%22+(status:open%20OR%20status:merged) > > [3]: > > https://android-review.googlesource.com/c/platform/system/memory/libmeminfo/+/1549734 > > > > Signed-off-by: Hridya Valsaraju > > Reported-by: kernel test robot Thanks for the patch! Christian: If you're satisfied with the explanation around not directly embedding kobjects into the dma_buf and dma_buf_attachment structs, then with Greg's r-b from sysfs PoV, I think we can merge it. Please let me know if you feel otherwise! > > --- > > Changes in v3: > > Fix a warning reported by the kernel test robot. > > > > Changes in v2: > > -Move statistics to /sys/kernel/dmabuf/buffers in oder to allow addition > > of other DMA-BUF-related sysfs stats in future. Based on feedback from > > Daniel Vetter. > > -Each attachment has its own directory to represent attaching devices as > > symlinks and to introduce map_count as a separate file. Based on > > feedback from Daniel Vetter and Christian König. Thank you both! > > -Commit messages updated to point to userspace code in AOSP that will > > read the DMA-BUF sysfs stats. > > > > > > .../ABI/testing/sysfs-kernel-dmabuf-buffers | 52 > > drivers/dma-buf/Kconfig | 11 + > > drivers/dma-buf/Makefile | 1 + > > drivers/dma-buf/dma-buf-sysfs-stats.c | 285 ++ > > drivers/dma-buf/dma-buf-sysfs-stats.h | 62 > > drivers/dma-buf/dma-buf.c | 37 +++ > > include/linux/dma-buf.h | 20 ++ > > 7 files changed, 468 insertions(+) > > create mode 100644 Documentation/ABI/testing/sysfs-kernel-dmabuf-buffers > > create mode 100644 drivers/dma-buf/dma-buf-sysfs-stats.c > > create mode 100644 drivers/dma-buf/dma-buf-sysfs-stats.h > > I don't know the dma-buf code at all, but from a sysfs/kobject point of > view, this patch looks good to me: > > Reviewed-by: Greg Kroah-Hartman Best, Sumit. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND][PATCH 2/3] dma-buf: heaps: Add a WARN_ON should the vmap_cnt go negative
Hi John, Suren,
On Wed, 20 Jan 2021 at 02:15, John Stultz wrote:
>
> We shouldn't vunmap more then we vmap, but if we do, make
> sure we complain loudly.
I was checking the general usage of vunmap in the kernel, and I
couldn't find many instances where we need to WARN_ON for the vunmap
count more than vmap count. Is there a specific need for this in the heaps?
Best,
Sumit.
>
> Cc: Sumit Semwal
> Cc: Liam Mark
> Cc: Laura Abbott
> Cc: Brian Starkey
> Cc: Hridya Valsaraju
> Cc: Suren Baghdasaryan
> Cc: Sandeep Patil
> Cc: Daniel Mentz
> Cc: Chris Goldsworthy
> Cc: Ørjan Eide
> Cc: Robin Murphy
> Cc: Ezequiel Garcia
> Cc: Simon Ser
> Cc: James Jones
> Cc: linux-me...@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Suggested-by: Suren Baghdasaryan
> Signed-off-by: John Stultz
> ---
> drivers/dma-buf/heaps/cma_heap.c| 1 +
> drivers/dma-buf/heaps/system_heap.c | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/drivers/dma-buf/heaps/cma_heap.c
> b/drivers/dma-buf/heaps/cma_heap.c
> index 364fc2f3e499..0c76cbc3fb11 100644
> --- a/drivers/dma-buf/heaps/cma_heap.c
> +++ b/drivers/dma-buf/heaps/cma_heap.c
> @@ -232,6 +232,7 @@ static void cma_heap_vunmap(struct dma_buf *dmabuf,
> struct dma_buf_map *map)
> struct cma_heap_buffer *buffer = dmabuf->priv;
>
> mutex_lock(>lock);
> + WARN_ON(buffer->vmap_cnt == 0);
> if (!--buffer->vmap_cnt) {
> vunmap(buffer->vaddr);
> buffer->vaddr = NULL;
> diff --git a/drivers/dma-buf/heaps/system_heap.c
> b/drivers/dma-buf/heaps/system_heap.c
> index 405351aad2a8..2321c91891f6 100644
> --- a/drivers/dma-buf/heaps/system_heap.c
> +++ b/drivers/dma-buf/heaps/system_heap.c
> @@ -273,6 +273,7 @@ static void system_heap_vunmap(struct dma_buf *dmabuf,
> struct dma_buf_map *map)
> struct system_heap_buffer *buffer = dmabuf->priv;
>
> mutex_lock(>lock);
> + WARN_ON(buffer->vmap_cnt == 0);
> if (!--buffer->vmap_cnt) {
> vunmap(buffer->vaddr);
> buffer->vaddr = NULL;
> --
> 2.17.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 1/2] dma-fence: allow signaling drivers to set fence timestamp
Hi Veera, On Wed, 20 Jan 2021 at 02:00, John Stultz wrote: > > On Fri, Jan 15, 2021 at 4:31 PM Veera Sundaram Sankaran > wrote: > > > > Some drivers have hardware capability to get the precise HW timestamp > > of certain events based on which the fences are triggered. The delta > > between the event HW timestamp & current HW reference timestamp can > > be used to calculate the timestamp in kernel's CLOCK_MONOTONIC time > > domain. This allows it to set accurate timestamp factoring out any > > software and IRQ latencies. Add a timestamp variant of fence signal > > function, dma_fence_signal_timestamp to allow drivers to update the > > precise timestamp for fences. Thank you for the patches! Daniel, Christian, Gustavo: if there are no objections, I will queue up this series via drm-misc-next. > > > > Changes in v2: > > - Add a new fence signal variant instead of modifying fence struct > > > > Changes in v3: > > - Add timestamp domain information to commit-text and > > dma_fence_signal_timestamp documentation > > > > Signed-off-by: Veera Sundaram Sankaran > > --- > > drivers/dma-buf/dma-fence.c | 70 > > - > > include/linux/dma-fence.h | 3 ++ > > 2 files changed, 66 insertions(+), 7 deletions(-) > > Thanks for respinning this! > > Reviewed-by: John Stultz > > -john Best, Sumit. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND][PATCH 3/3] dma-buf: heaps: Rework heep allocation hooks to return struct dma_buf instead of fd
Hi John,
On Wed, 20 Jan 2021 at 02:15, John Stultz wrote:
>
> Every heap needs to create a dmabuf and then export it to a fd
> via dma_buf_fd(), so to consolidate things a bit, have the heaps
> just return a struct dmabuf * and let the top level
> dma_heap_buffer_alloc() call handle creating the fd via
> dma_buf_fd().
Thanks for the patch! LGTM, feels a lot neater now. I'll merge into
drm-misc-next.
>
> Cc: Sumit Semwal
> Cc: Liam Mark
> Cc: Laura Abbott
> Cc: Brian Starkey
> Cc: Hridya Valsaraju
> Cc: Suren Baghdasaryan
> Cc: Sandeep Patil
> Cc: Daniel Mentz
> Cc: Chris Goldsworthy
> Cc: Ørjan Eide
> Cc: Robin Murphy
> Cc: Ezequiel Garcia
> Cc: Simon Ser
> Cc: James Jones
> Cc: linux-me...@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: John Stultz
> ---
> drivers/dma-buf/dma-heap.c | 14 +-
> drivers/dma-buf/heaps/cma_heap.c| 22 +++---
> drivers/dma-buf/heaps/system_heap.c | 21 +++--
> include/linux/dma-heap.h| 12 ++--
> 4 files changed, 33 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c
> index afd22c9dbdcf..6b5db954569f 100644
> --- a/drivers/dma-buf/dma-heap.c
> +++ b/drivers/dma-buf/dma-heap.c
> @@ -52,6 +52,9 @@ static int dma_heap_buffer_alloc(struct dma_heap *heap,
> size_t len,
> unsigned int fd_flags,
> unsigned int heap_flags)
> {
> + struct dma_buf *dmabuf;
> + int fd;
> +
> /*
> * Allocations from all heaps have to begin
> * and end on page boundaries.
> @@ -60,7 +63,16 @@ static int dma_heap_buffer_alloc(struct dma_heap *heap,
> size_t len,
> if (!len)
> return -EINVAL;
>
> - return heap->ops->allocate(heap, len, fd_flags, heap_flags);
> + dmabuf = heap->ops->allocate(heap, len, fd_flags, heap_flags);
> + if (IS_ERR(dmabuf))
> + return PTR_ERR(dmabuf);
> +
> + fd = dma_buf_fd(dmabuf, fd_flags);
> + if (fd < 0) {
> + dma_buf_put(dmabuf);
> + /* just return, as put will call release and that will free */
> + }
> + return fd;
> }
>
> static int dma_heap_open(struct inode *inode, struct file *file)
> diff --git a/drivers/dma-buf/heaps/cma_heap.c
> b/drivers/dma-buf/heaps/cma_heap.c
> index 0c76cbc3fb11..985c41ffd85b 100644
> --- a/drivers/dma-buf/heaps/cma_heap.c
> +++ b/drivers/dma-buf/heaps/cma_heap.c
> @@ -272,10 +272,10 @@ static const struct dma_buf_ops cma_heap_buf_ops = {
> .release = cma_heap_dma_buf_release,
> };
>
> -static int cma_heap_allocate(struct dma_heap *heap,
> - unsigned long len,
> - unsigned long fd_flags,
> - unsigned long heap_flags)
> +static struct dma_buf *cma_heap_allocate(struct dma_heap *heap,
> +unsigned long len,
> +unsigned long fd_flags,
> +unsigned long heap_flags)
> {
> struct cma_heap *cma_heap = dma_heap_get_drvdata(heap);
> struct cma_heap_buffer *buffer;
> @@ -290,7 +290,7 @@ static int cma_heap_allocate(struct dma_heap *heap,
>
> buffer = kzalloc(sizeof(*buffer), GFP_KERNEL);
> if (!buffer)
> - return -ENOMEM;
> + return ERR_PTR(-ENOMEM);
>
> INIT_LIST_HEAD(>attachments);
> mutex_init(>lock);
> @@ -349,15 +349,7 @@ static int cma_heap_allocate(struct dma_heap *heap,
> ret = PTR_ERR(dmabuf);
> goto free_pages;
> }
> -
> - ret = dma_buf_fd(dmabuf, fd_flags);
> - if (ret < 0) {
> - dma_buf_put(dmabuf);
> - /* just return, as put will call release and that will free */
> - return ret;
> - }
> -
> - return ret;
> + return dmabuf;
>
> free_pages:
> kfree(buffer->pages);
> @@ -366,7 +358,7 @@ static int cma_heap_allocate(struct dma_heap *heap,
> free_buffer:
> kfree(buffer);
>
> - return ret;
> + return ERR_PTR(ret);
> }
>
> static const struct dma_heap_ops cma_heap_ops = {
> diff --git a/drivers/dma-buf/heaps/system_heap.c
> b/drivers/dma-buf/heaps/system_heap.c
> index 2321c91891f6..7b154424aeb3 100644
> --- a/drivers/dma-buf/heaps/system_heap.c
> +++ b/drivers/dma-buf/heaps/system_heap.c
> @@ -332,10
Re: [RESEND][PATCH 1/3] dma-buf: system_heap: Make sure to return an error if we abort
Hi John,
On Wed, 20 Jan 2021 at 02:15, John Stultz wrote:
>
> If we abort from the allocation due to a fatal_signal_pending(),
> be sure we report an error so any return code paths don't trip
> over the fact that the allocation didn't succeed.
Thanks for the patch; LGTM, will push into drm-misc-next.
>
> Cc: Sumit Semwal
> Cc: Liam Mark
> Cc: Laura Abbott
> Cc: Brian Starkey
> Cc: Hridya Valsaraju
> Cc: Suren Baghdasaryan
> Cc: Sandeep Patil
> Cc: Daniel Mentz
> Cc: Chris Goldsworthy
> Cc: Ørjan Eide
> Cc: Robin Murphy
> Cc: Ezequiel Garcia
> Cc: Simon Ser
> Cc: James Jones
> Cc: linux-me...@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Suggested-by: Suren Baghdasaryan
> Signed-off-by: John Stultz
> ---
> drivers/dma-buf/heaps/system_heap.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/dma-buf/heaps/system_heap.c
> b/drivers/dma-buf/heaps/system_heap.c
> index 17e0e9a68baf..405351aad2a8 100644
> --- a/drivers/dma-buf/heaps/system_heap.c
> +++ b/drivers/dma-buf/heaps/system_heap.c
> @@ -363,8 +363,10 @@ static int system_heap_allocate(struct dma_heap *heap,
> * Avoid trying to allocate memory if the process
> * has been killed by SIGKILL
> */
> - if (fatal_signal_pending(current))
> + if (fatal_signal_pending(current)) {
> + ret = -EINTR;
> goto free_buffer;
> + }
>
> page = alloc_largest_available(size_remaining, max_order);
> if (!page)
> --
> 2.17.1
>
Best,
Sumit.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: cma_heap: Fix memory leak in CMA heap
Hi John,
On Fri, 8 Jan 2021 at 01:56, John Stultz wrote:
>
> Bing Song noticed the CMA heap was leaking memory due to a flub
> I made in commit a5d2d29e24be ("dma-buf: heaps: Move heap-helper
> logic into the cma_heap implementation"), and provided this fix
> which ensures the pagelist is also freed on release.
Thanks for your patch.
>
> Cc: Bing Song
> Cc: Sumit Semwal
> Cc: Liam Mark
> Cc: Laura Abbott
> Cc: Brian Starkey
> Cc: Hridya Valsaraju
> Cc: Suren Baghdasaryan
> Cc: Sandeep Patil
> Cc: Daniel Mentz
> Cc: Chris Goldsworthy
> Cc: Ørjan Eide
> Cc: Robin Murphy
> Cc: Ezequiel Garcia
> Cc: Simon Ser
> Cc: James Jones
> Cc: linux-me...@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Reported-by: Bing Song
> Fixes: a5d2d29e24be ("dma-buf: heaps: Move heap-helper logic into the
> cma_heap implementation")
> Signed-off-by: John Stultz
I will queue it up so it gets in the v5.11 cycle.
> ---
> drivers/dma-buf/heaps/cma_heap.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/dma-buf/heaps/cma_heap.c
> b/drivers/dma-buf/heaps/cma_heap.c
> index 3c4e34301172..364fc2f3e499 100644
> --- a/drivers/dma-buf/heaps/cma_heap.c
> +++ b/drivers/dma-buf/heaps/cma_heap.c
> @@ -251,6 +251,9 @@ static void cma_heap_dma_buf_release(struct dma_buf
> *dmabuf)
> buffer->vaddr = NULL;
> }
>
> + /* free page list */
> + kfree(buffer->pages);
> + /* release memory */
> cma_release(cma_heap->cma, buffer->cma_pages, buffer->pagecount);
> kfree(buffer);
> }
> --
> 2.17.1
>
Best,
Sumit.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linaro-mm-sig] [PATCH] dmabuf: fix use-after-free of dmabuf's file->f_inode
Hi Charan,
On Mon, 4 Jan 2021 at 17:22, Christian König
wrote:
>
> Am 04.01.21 um 12:36 schrieb Charan Teja Reddy:
> > It is observed 'use-after-free' on the dmabuf's file->f_inode with the
> > race between closing the dmabuf file and reading the dmabuf's debug
> > info.
> >
> > Consider the below scenario where P1 is closing the dma_buf file
> > and P2 is reading the dma_buf's debug info in the system:
> >
> > P1P2
> > dma_buf_debug_show()
> > dma_buf_put()
> >__fput()
> > file->f_op->release()
> > dput()
> >
> >dentry_unlink_inode()
> > iput(dentry->d_inode)
> > (where the inode is freed)
> > mutex_lock(_list.lock)
> > read 'dma_buf->file->f_inode'
> > (the same inode is freed by P1)
> > mutex_unlock(_list.lock)
> >dentry->d_op->d_release()-->
> > dma_buf_release()
> >.
> >mutex_lock(_list.lock)
> >removes the dmabuf from the list
> >mutex_unlock(_list.lock)
> >
> > In the above scenario, when dma_buf_put() is called on a dma_buf, it
> > first frees the dma_buf's file->f_inode(=dentry->d_inode) and then
> > removes this dma_buf from the system db_list. In between P2 traversing
> > the db_list tries to access this dma_buf's file->f_inode that was freed
> > by P1 which is a use-after-free case.
> >
> > Since, __fput() calls f_op->release first and then later calls the
> > d_op->d_release, move the dma_buf's db_list removal from d_release() to
> > f_op->release(). This ensures that dma_buf's file->f_inode is not
> > accessed after it is released.
> >
> > Fixes: 4ab59c3c638c ("dma-buf: Move dma_buf_release() from fops to
> > dentry_ops")
> > Signed-off-by: Charan Teja Reddy
>
> Not an expert on the debugfs stuff in DMA-buf, but the explanation
> sounds perfectly correct to me.
>
> Acked-by: Christian König
Thanks for your fix; I will queue it up in the fixes branch. Can you
please also send it to be queued to 5.4+ stable branches?
>
> > ---
> > drivers/dma-buf/dma-buf.c | 21 +
> > 1 file changed, 17 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> > index 0eb80c1..a14dcbb 100644
> > --- a/drivers/dma-buf/dma-buf.c
> > +++ b/drivers/dma-buf/dma-buf.c
> > @@ -76,10 +76,6 @@ static void dma_buf_release(struct dentry *dentry)
> >
> > dmabuf->ops->release(dmabuf);
> >
> > - mutex_lock(_list.lock);
> > - list_del(>list_node);
> > - mutex_unlock(_list.lock);
> > -
> > if (dmabuf->resv == (struct dma_resv *)[1])
> > dma_resv_fini(dmabuf->resv);
> >
> > @@ -88,6 +84,22 @@ static void dma_buf_release(struct dentry *dentry)
> > kfree(dmabuf);
> > }
> >
> > +static int dma_buf_file_release(struct inode *inode, struct file *file)
> > +{
> > + struct dma_buf *dmabuf;
> > +
> > + if (!is_dma_buf_file(file))
> > + return -EINVAL;
> > +
> > + dmabuf = file->private_data;
> > +
> > + mutex_lock(_list.lock);
> > + list_del(>list_node);
> > + mutex_unlock(_list.lock);
> > +
> > + return 0;
> > +}
> > +
> > static const struct dentry_operations dma_buf_dentry_ops = {
> > .d_dname = dmabuffs_dname,
> > .d_release = dma_buf_release,
> > @@ -413,6 +425,7 @@ static void dma_buf_show_fdinfo(struct seq_file *m,
> > struct file *file)
> > }
> >
> > static const struct file_operations dma_buf_fops = {
> > + .release= dma_buf_file_release,
> > .mmap = dma_buf_mmap_internal,
> > .llseek = dma_buf_llseek,
> > .poll = dma_buf_poll,
>
Best,
Sumit.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: cma_heap: Include linux/vmalloc.h to fix build failures on MIPS
Hi John,
On Wed, 16 Dec 2020 at 06:19, John Stultz wrote:
>
> We need to include in order for MIPS to find
> vmap(), as it doesn't otherwise get included there.
>
> Without this patch, one can hit the following build error:
> drivers/dma-buf/heaps/cma_heap.c: In function 'cma_heap_do_vmap':
> drivers/dma-buf/heaps/cma_heap.c:195:10: error: implicit declaration of
> function 'vmap'
Thanks for the patch; I've merged it to drm-misc-next-fixes.
>
> Cc: Sumit Semwal
> Cc: Liam Mark
> Cc: Laura Abbott
> Cc: Brian Starkey
> Cc: Hridya Valsaraju
> Cc: Suren Baghdasaryan
> Cc: Sandeep Patil
> Cc: Daniel Mentz
> Cc: Chris Goldsworthy
> Cc: Ørjan Eide
> Cc: Robin Murphy
> Cc: Ezequiel Garcia
> Cc: Simon Ser
> Cc: James Jones
> Cc: linux-me...@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Fixes: a5d2d29e24be ("dma-buf: heaps: Move heap-helper logic into the
> cma_heap implementation")
> Reported-by: Guenter Roeck
> Signed-off-by: John Stultz
> ---
> drivers/dma-buf/heaps/cma_heap.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/dma-buf/heaps/cma_heap.c
> b/drivers/dma-buf/heaps/cma_heap.c
> index 5e7c3436310c..3c4e34301172 100644
> --- a/drivers/dma-buf/heaps/cma_heap.c
> +++ b/drivers/dma-buf/heaps/cma_heap.c
> @@ -20,6 +20,7 @@
> #include
> #include
> #include
> +#include
>
>
> struct cma_heap {
> --
> 2.17.1
>
Best,
Sumit.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 0/7] dma-buf: Performance improvements for system heap & a system-uncached implementation
Hi Daniel, On Wed, 18 Nov 2020 at 13:16, Daniel Vetter wrote: > > On Wed, Nov 18, 2020 at 3:40 AM John Stultz wrote: > > On Fri, Nov 13, 2020 at 12:39 PM Daniel Vetter wrote: > > > On Thu, Nov 12, 2020 at 08:11:02PM -0800, John Stultz wrote: > > > > On Thu, Nov 12, 2020 at 1:32 AM Daniel Vetter wrote: > > > > > On Thu, Nov 12, 2020 at 11:09:04AM +0530, Sumit Semwal wrote: > > > > > > On Tue, 10 Nov 2020 at 09:19, John Stultz > > > > > > wrote: > > > > > > > > > > > > > > Hey All, > > > > > > > So just wanted to send my last revision of my patch series > > > > > > > of performance optimizations to the dma-buf system heap. > > > > > > > > > > > > Thanks very much for your patches - I think the first 5 patches > > > > > > look good to me. > > > > > > > > > > > > I know there was a bit of discussion over adding a new > > > > > > system-uncached > > > > > > heap v/s using a flag to identify that; I think I prefer the > > > > > > separate > > > > > > heap idea, but lets ask one last time if any one else has any real > > > > > > objections to it. > > > > > > > > > > > > Daniel, Christian: any comments from your side on this? > > > > > > > > > > I do wonder a bit where the userspace stack for this all is, since > > > > > tuning > > > > > allocators without a full stack is fairly pointless. dma-buf heaps is > > > > > a > > > > > bit in a limbo situation here it feels like. > > > > > > > > As mentioned in the system-uncached patch: > > > > Pending opensource users of this code include: > > > > * AOSP HiKey960 gralloc: > > > > - > > > > https://android-review.googlesource.com/c/device/linaro/hikey/+/1399519 > > > > - Visibly improves performance over the system heap > > > > * AOSP Codec2 (possibly, needs more review): > > > > - > > > > https://android-review.googlesource.com/c/platform/frameworks/av/+/1360640/17/media/codec2/vndk/C2DmaBufAllocator.cpp#325 > > > > > > > > Additionally both the HiKey, HiKey960 grallocs and Codec2 are already > > > > able to use the current dmabuf heaps instead of ION. > > > > > > > > So I'm not sure what you mean by limbo, other than it being in a > > > > transition state where the interface is upstream and we're working on > > > > moving vendors to it from ION (which is staged to be dropped in 5.11). > > > > Part of that work is making sure we don't regress the performance > > > > expectations. > > > > > > The mesa thing below, since if we test this with some downstream kernel > > > drivers or at least non-mesa userspace I'm somewhat worried we're just > > > creating a nice split world between the android gfx world and the > > > mesa/linux desktop gfx world. > > > > > > But then that's kinda how android rolls, so *shrug* > > > > > > > > Plus I'm vary of anything related to leaking this kind of stuff > > > > > beyond the > > > > > dma-api because dma api maintainers don't like us doing that. But > > > > > personally no concern on that front really, gpus need this. It's just > > > > > that > > > > > we do need solid justification I think if we land this. Hence back to > > > > > first point. > > > > > > > > > > Ideally first point comes in the form of benchmarking on android > > > > > together > > > > > with a mesa driver (or mesa + some v4l driver or whatever it takes to > > > > > actually show the benefits, I have no idea). > > > > > > > > Tying it with mesa is a little tough as the grallocs for mesa devices > > > > usually use gbm (gralloc.gbm or gralloc.minigbm). Swapping the > > > > allocation path for dmabuf heaps there gets a little complex as last I > > > > tried that (when trying to get HiKey working with Lima graphics, as > > > > gbm wouldn't allocate the contiguous buffers required by the display), > > > > I ran into issues with the drm_hwcomposer and mesa expecting the gbm > > > > private handle metadata in the buffer when it was passed in. > > > > > > > > But I might take a look at it again. I
Re: [PATCH v5 0/7] dma-buf: Performance improvements for system heap & a system-uncached implementation
Hi John, On Tue, 10 Nov 2020 at 09:19, John Stultz wrote: > > Hey All, > So just wanted to send my last revision of my patch series > of performance optimizations to the dma-buf system heap. Thanks very much for your patches - I think the first 5 patches look good to me. I know there was a bit of discussion over adding a new system-uncached heap v/s using a flag to identify that; I think I prefer the separate heap idea, but lets ask one last time if any one else has any real objections to it. Daniel, Christian: any comments from your side on this? I am planning to merge this series to drm-misc this week if I hear no objections. > > This series reworks the system heap to use sgtables, and then > consolidates the pagelist method from the heap-helpers into the > CMA heap. After which the heap-helpers logic is removed (as it > is unused). I'd still like to find a better way to avoid some of > the logic duplication in implementing the entire dma_buf_ops > handlers per heap. But unfortunately that code is tied somewhat > to how the buffer's memory is tracked. As more heaps show up I > think we'll have a better idea how to best share code, so for > now I think this is ok. > > After this, the series introduces an optimization that > Ørjan Eide implemented for ION that avoids calling sync on > attachments that don't have a mapping. > > Next, an optimization to use larger order pages for the system > heap. This change brings us closer to the current performance > of the ION allocation code (though there still is a gap due > to ION using a mix of deferred-freeing and page pools, I'll be > looking at integrating those eventually). > > Finally, a reworked version of my uncached system heap > implementation I was submitting a few weeks back. Since it > duplicated a lot of the now reworked system heap code, I > realized it would be much simpler to add the functionality to > the system_heap implementation itself. > > While not improving the core allocation performance, the > uncached heap allocations do result in *much* improved > performance on HiKey960 as it avoids a lot of flushing and > invalidating buffers that the cpu doesn't touch often. > > Feedback on these would be great! > > thanks > -john > > New in v5: > * Added a comment explaining why the order sizes are > chosen as they are > > Cc: Sumit Semwal > Cc: Liam Mark > Cc: Laura Abbott > Cc: Brian Starkey > Cc: Hridya Valsaraju > Cc: Suren Baghdasaryan > Cc: Sandeep Patil > Cc: Daniel Mentz > Cc: Chris Goldsworthy > Cc: Ørjan Eide > Cc: Robin Murphy > Cc: Ezequiel Garcia > Cc: Simon Ser > Cc: James Jones > Cc: linux-me...@vger.kernel.org > Cc: dri-devel@lists.freedesktop.org > > John Stultz (7): > dma-buf: system_heap: Rework system heap to use sgtables instead of > pagelists > dma-buf: heaps: Move heap-helper logic into the cma_heap > implementation > dma-buf: heaps: Remove heap-helpers code > dma-buf: heaps: Skip sync if not mapped > dma-buf: system_heap: Allocate higher order pages if available > dma-buf: dma-heap: Keep track of the heap device struct > dma-buf: system_heap: Add a system-uncached heap re-using the system > heap > > drivers/dma-buf/dma-heap.c | 33 +- > drivers/dma-buf/heaps/Makefile | 1 - > drivers/dma-buf/heaps/cma_heap.c | 324 +++--- > drivers/dma-buf/heaps/heap-helpers.c | 270 --- > drivers/dma-buf/heaps/heap-helpers.h | 53 --- > drivers/dma-buf/heaps/system_heap.c | 494 --- > include/linux/dma-heap.h | 9 + > 7 files changed, 753 insertions(+), 431 deletions(-) > delete mode 100644 drivers/dma-buf/heaps/heap-helpers.c > delete mode 100644 drivers/dma-buf/heaps/heap-helpers.h > > -- > 2.17.1 > Thanks much, Best, Sumit. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 1/2] dt-bindings: display: panel: Add bindings for Novatek nt36672a
Hi Sam,
On Thu, 15 Oct 2020 at 00:14, Sam Ravnborg wrote:
>
> Hi Sumit.
> On Wed, Sep 02, 2020 at 12:14:06PM +0530, Sumit Semwal wrote:
> > Novatek nt36672a is a display driver IC that can drive DSI panel. It
> > is also present in the Tianma video mode panel, which is a FHD+ panel
> > with a resolution of 1080x2246 and 6.18 inches size. It is found in
> > some of the Poco F1 phones.
> >
> > This patch adds the display driver for the IC, with support added for
> > this tianma fhd video mode panel.
> >
> > Signed-off-by: Sumit Semwal
> > Reviewed-by: Rob Herring
> Reviewed-by: Sam Ravnborg
> I assume you will apply the patch yourself.
Thanks, I will.
>
> Sam
Best,
Sumit.
> >
> > ---
> > v2: remove ports node, making port@0 directly under panel@0 node.
> > v3: updated to replace port@0 to just 'port'.
> > v5: renamed to novatek,nt36672a, since the binding is for the IC and not
> > the panel.
> > v6: v5 review comments incorporated.
> > - added enum for the compatible part, since it can be extended in
> > future.
> > - few cosmetic updates.
> > ---
> > .../display/panel/novatek,nt36672a.yaml | 87 +++
> > 1 file changed, 87 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml
> > b/Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml
> > new file mode 100644
> > index ..d2170de6b723
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml
> > @@ -0,0 +1,87 @@
> > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/display/panel/novatek,nt36672a.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Novatek NT36672A based DSI display Panels
> > +
> > +maintainers:
> > + - Sumit Semwal
> > +
> > +description: |
> > + The nt36672a IC from Novatek is a generic DSI Panel IC used to drive dsi
> > + panels.
> > + Right now, support is added only for a Tianma FHD+ LCD display panel
> > with a
> > + resolution of 1080x2246. It is a video mode DSI panel.
> > +
> > +allOf:
> > + - $ref: panel-common.yaml#
> > +
> > +properties:
> > + compatible:
> > +items:
> > + - enum:
> > + - tianma,fhd-video
> > + - const: novatek,nt36672a
> > +description: This indicates the panel manufacturer of the panel that is
> > + in turn using the NT36672A panel driver. This compatible string
> > + determines how the NT36672A panel driver is configured for the
> > indicated
> > + panel. The novatek,nt36672a compatible shall always be provided as a
> > fallback.
> > +
> > + reset-gpios:
> > +description: phandle of gpio for reset line - This should be 8mA, gpio
> > + can be configured using mux, pinctrl, pinctrl-names (active high)
> > +
> > + vddio-supply:
> > +description: phandle of the regulator that provides the supply voltage
> > + Power IC supply
> > +
> > + vddpos-supply:
> > +description: phandle of the positive boost supply regulator
> > +
> > + vddneg-supply:
> > +description: phandle of the negative boost supply regulator
> > +
> > + reg: true
> > + port: true
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - vddi0-supply
> > + - vddpos-supply
> > + - vddneg-supply
> > + - reset-gpios
> > + - port
> > +
> > +unevaluatedProperties: false
> > +
> > +examples:
> > + - |+
> > +#include
> > +
> > +dsi0 {
> > +#address-cells = <1>;
> > +#size-cells = <0>;
> > +
> > +panel@0 {
> > +compatible = "tianma,fhd-video", "novatek,nt36672a";
> > +reg = <0>;
> > +vddi0-supply = <_l14a_1p88>;
> > +vddpos-supply = <>;
> > +vddneg-supply = <>;
> > +
> > +reset-gpios = < 6 GPIO_ACTIVE_HIGH>;
> > +
> > +#address-cells = <1>;
> > +#size-cells = <0>;
> > +port {
> > +tianma_nt36672a_in_0: endpoint {
> > +remote-endpoint = <_out>;
> > +};
> > +};
> > +};
> > +};
> > +
> > +...
> > --
> > 2.28.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 -next] dma-buf: heaps: Remove unused variable ret
Hello Zou,
On Tue, 22 Sep 2020 at 18:12, Christian König wrote:
>
> Am 22.09.20 um 09:53 schrieb Zou Wei:
> > This patch fixes below warnings reported by coccicheck
> >
> > ./drivers/dma-buf/heaps/heap-helpers.c:202:5-8: Unneeded variable: "ret".
> > Return "0" on line 215
> >
> > Signed-off-by: Zou Wei
>
> Acked-by: Christian König
>
> Going to pick this up for drm-misc-next.
Thanks Christian!
Fwiw, feel free to add my
Acked-by: Sumit Semwal
>
> > ---
> > drivers/dma-buf/heaps/heap-helpers.c | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/drivers/dma-buf/heaps/heap-helpers.c
> > b/drivers/dma-buf/heaps/heap-helpers.c
> > index d0696cf..7969510 100644
> > --- a/drivers/dma-buf/heaps/heap-helpers.c
> > +++ b/drivers/dma-buf/heaps/heap-helpers.c
> > @@ -199,7 +199,6 @@ static int dma_heap_dma_buf_begin_cpu_access(struct
> > dma_buf *dmabuf,
> > {
> > struct heap_helper_buffer *buffer = dmabuf->priv;
> > struct dma_heaps_attachment *a;
> > - int ret = 0;
> >
> > mutex_lock(>lock);
> >
> > @@ -212,7 +211,7 @@ static int dma_heap_dma_buf_begin_cpu_access(struct
> > dma_buf *dmabuf,
> > }
> > mutex_unlock(>lock);
> >
> > - return ret;
> > + return 0;
> > }
> >
> > static int dma_heap_dma_buf_end_cpu_access(struct dma_buf *dmabuf,
>
Best,
Sumit.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 0/2]dd support for Tianma nt36672a video mode panel
Hi Sam / Theirry, On Wed, 2 Sep 2020 at 12:14, Sumit Semwal wrote: > > Some Poco F1 phones from Xiaomi have a FHD+ video mode panel based on the > Novatek NT36672A display controller; Add support for the same. This latest version (v7) had all the outstanding comments fixed, and Bjorn has also given his r-b, so could you please get this set of patches merged? > Best, Sumit. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] dma-buf: Flag vmap'ed memory as system or I/O memory
Hi Thomas, On Fri, 18 Sep 2020 at 11:36, Sumit Semwal wrote: > > Hello Thomas, > > On Mon, 14 Sep 2020 at 16:55, Thomas Zimmermann wrote: > > > > Dma-buf provides vmap() and vunmap() for retrieving and releasing mappings > > of dma-buf memory in kernel address space. The functions operate with plain > > addresses and the assumption is that the memory can be accessed with load > > and store operations. This is not the case on some architectures (e.g., > > sparc64) where I/O memory can only be accessed with dedicated instructions. > > > > This patchset introduces struct dma_buf_map, which contains the address of > > a buffer and a flag that tells whether system- or I/O-memory instructions > > are required. > > Thank you for the patchset - it is a really nice, clean bit to add! > > > > Some background: updating the DRM framebuffer console on sparc64 makes the > > kernel panic. This is because the framebuffer memory cannot be accessed with > > system-memory instructions. We currently employ a workaround in DRM to > > address this specific problem. [1] > > > > To resolve the problem, we'd like to address it at the most common point, > > which is the dma-buf framework. The dma-buf mapping ideally knows if I/O > > instructions are required and exports this information to it's users. The > > new structure struct dma_buf_map stores the buffer address and a flag that > > signals I/O memory. Affected users of the buffer (e.g., drivers, frameworks) > > can then access the memory accordingly. > > > > This patchset only introduces struct dma_buf_map, and updates struct dma_buf > > and it's interfaces. Further patches can update dma-buf users. For example, > > there's a prototype patchset for DRM that fixes the framebuffer problem. [2] > > > > Further work: TTM, one of DRM's memory managers, already exports an > > is_iomem flag of its own. It could later be switched over to exporting > > struct > > dma_buf_map, thus simplifying some code. Several DRM drivers expect their > > fbdev console to operate on I/O memory. These could possibly be switched > > over > > to the generic fbdev emulation, as soon as the generic code uses struct > > dma_buf_map. > > > > [1] https://lore.kernel.org/dri-devel/20200725191012.ga434...@ravnborg.org/ > > [2] > > https://lore.kernel.org/dri-devel/20200806085239.4606-1-tzimmerm...@suse.de/ > > > > Thomas Zimmermann (3): > > dma-buf: Add struct dma-buf-map for storing struct dma_buf.vaddr_ptr > > dma-buf: Use struct dma_buf_map in dma_buf_vmap() interfaces > > dma-buf: Use struct dma_buf_map in dma_buf_vunmap() interfaces > > FWIW, for the series, please feel free to add my > Acked-by: Sumit Semwal Of course, once the errors found by kernel test robot are fixed :). > > > > > Documentation/driver-api/dma-buf.rst | 3 + > > drivers/dma-buf/dma-buf.c | 40 +++--- > > drivers/gpu/drm/drm_gem_cma_helper.c | 16 ++- > > drivers/gpu/drm/drm_gem_shmem_helper.c| 17 ++- > > drivers/gpu/drm/drm_prime.c | 14 +- > > drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 13 +- > > drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 13 +- > > .../drm/i915/gem/selftests/i915_gem_dmabuf.c | 18 ++- > > drivers/gpu/drm/tegra/gem.c | 23 ++-- > > .../common/videobuf2/videobuf2-dma-contig.c | 17 ++- > > .../media/common/videobuf2/videobuf2-dma-sg.c | 19 ++- > > .../common/videobuf2/videobuf2-vmalloc.c | 21 ++- > > include/drm/drm_prime.h | 5 +- > > include/linux/dma-buf-map.h | 126 ++ > > include/linux/dma-buf.h | 11 +- > > 15 files changed, 274 insertions(+), 82 deletions(-) > > create mode 100644 include/linux/dma-buf-map.h > > > > -- > > 2.28.0 > > > > Best, > Sumit. Best, Sumit. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] dma-buf: Flag vmap'ed memory as system or I/O memory
Hello Thomas, On Mon, 14 Sep 2020 at 16:55, Thomas Zimmermann wrote: > > Dma-buf provides vmap() and vunmap() for retrieving and releasing mappings > of dma-buf memory in kernel address space. The functions operate with plain > addresses and the assumption is that the memory can be accessed with load > and store operations. This is not the case on some architectures (e.g., > sparc64) where I/O memory can only be accessed with dedicated instructions. > > This patchset introduces struct dma_buf_map, which contains the address of > a buffer and a flag that tells whether system- or I/O-memory instructions > are required. Thank you for the patchset - it is a really nice, clean bit to add! > > Some background: updating the DRM framebuffer console on sparc64 makes the > kernel panic. This is because the framebuffer memory cannot be accessed with > system-memory instructions. We currently employ a workaround in DRM to > address this specific problem. [1] > > To resolve the problem, we'd like to address it at the most common point, > which is the dma-buf framework. The dma-buf mapping ideally knows if I/O > instructions are required and exports this information to it's users. The > new structure struct dma_buf_map stores the buffer address and a flag that > signals I/O memory. Affected users of the buffer (e.g., drivers, frameworks) > can then access the memory accordingly. > > This patchset only introduces struct dma_buf_map, and updates struct dma_buf > and it's interfaces. Further patches can update dma-buf users. For example, > there's a prototype patchset for DRM that fixes the framebuffer problem. [2] > > Further work: TTM, one of DRM's memory managers, already exports an > is_iomem flag of its own. It could later be switched over to exporting struct > dma_buf_map, thus simplifying some code. Several DRM drivers expect their > fbdev console to operate on I/O memory. These could possibly be switched over > to the generic fbdev emulation, as soon as the generic code uses struct > dma_buf_map. > > [1] https://lore.kernel.org/dri-devel/20200725191012.ga434...@ravnborg.org/ > [2] > https://lore.kernel.org/dri-devel/20200806085239.4606-1-tzimmerm...@suse.de/ > > Thomas Zimmermann (3): > dma-buf: Add struct dma-buf-map for storing struct dma_buf.vaddr_ptr > dma-buf: Use struct dma_buf_map in dma_buf_vmap() interfaces > dma-buf: Use struct dma_buf_map in dma_buf_vunmap() interfaces FWIW, for the series, please feel free to add my Acked-by: Sumit Semwal > > Documentation/driver-api/dma-buf.rst | 3 + > drivers/dma-buf/dma-buf.c | 40 +++--- > drivers/gpu/drm/drm_gem_cma_helper.c | 16 ++- > drivers/gpu/drm/drm_gem_shmem_helper.c| 17 ++- > drivers/gpu/drm/drm_prime.c | 14 +- > drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 13 +- > drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 13 +- > .../drm/i915/gem/selftests/i915_gem_dmabuf.c | 18 ++- > drivers/gpu/drm/tegra/gem.c | 23 ++-- > .../common/videobuf2/videobuf2-dma-contig.c | 17 ++- > .../media/common/videobuf2/videobuf2-dma-sg.c | 19 ++- > .../common/videobuf2/videobuf2-vmalloc.c | 21 ++- > include/drm/drm_prime.h | 5 +- > include/linux/dma-buf-map.h | 126 ++ > include/linux/dma-buf.h | 11 +- > 15 files changed, 274 insertions(+), 82 deletions(-) > create mode 100644 include/linux/dma-buf-map.h > > -- > 2.28.0 > Best, Sumit. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 08/29] dma-buf: Avoid comma separated statements
Hello Joe,
On Wed, 26 Aug 2020 at 20:38, Christian König wrote:
>
> Am 25.08.20 um 06:56 schrieb Joe Perches:
> > Use semicolons and braces.
> >
> > Signed-off-by: Joe Perches
>
> Acked-by: Christian König
FWIW,
Acked-by: Sumit Semwal
>
> > ---
> > drivers/dma-buf/st-dma-fence.c | 7 +--
> > 1 file changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/dma-buf/st-dma-fence.c b/drivers/dma-buf/st-dma-fence.c
> > index e593064341c8..c8a12d7ad71a 100644
> > --- a/drivers/dma-buf/st-dma-fence.c
> > +++ b/drivers/dma-buf/st-dma-fence.c
> > @@ -471,8 +471,11 @@ static int thread_signal_callback(void *arg)
> > dma_fence_signal(f1);
> >
> > smp_store_mb(cb.seen, false);
> > - if (!f2 || dma_fence_add_callback(f2, ,
> > simple_callback))
> > - miss++, cb.seen = true;
> > + if (!f2 ||
> > + dma_fence_add_callback(f2, , simple_callback)) {
> > + miss++;
> > + cb.seen = true;
> > + }
> >
> > if (!t->before)
> > dma_fence_signal(f1);
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 2/2] drm: panel: Add novatek nt36672a panel driver
Novatek NT36672a is a generic DSI IC that drives command and video mode panels. Add the driver for it. Right now adding support for some Poco F1 phones that have an LCD panel from Tianma connected with this IC, with a resolution of 1080x2246 that operates in DSI video mode. During testing, Benni Steini helped us fix the reset sequence timing (from 10ms to 20ms), to get the bootanimation to work on Android. With current AOSP, we need to increase it to 200ms - this seems to be a safe high value to avoid a white screen occasionally. Signed-off-by: Sumit Semwal Cc: Benni Steini --- v2: increase reset sequence timing to a safe 200ms v4: Since "0425662fdf05: drm: Nuke mode->vrefresh", we have to calculate vrefresh on demand. Update for it. v5: Fixed review comments from Sam: - rebased on top of drm-misc-next remove return of drm_panel_add() remove drm_panel_detach() - renamed the panel driver file to reflect that this is a novatek nt36672a display driver and not only for tianma panels. Adjusted some internal names also to reflect the same. - corrected changelog to add info about the generic Novatek DSI IC - corrected compatible string accordingly - removed pinctrl - used drm_panel* API for prepare/unprepare/disable/remove v6: Fixed few review comments on v5 from Sam: - add dev_err_probe() support - move DRM_* error printing to dev_err() - removed a few unnecessary bits v7: Fixed review comments on v6 from Bjorn: - Reworked the send_mipi_commands functionality - removed regulator disable_loads; moved active_load setting to probe time - made function names and struct less generic - updated the reset_gpio working to active_low - update MAINTAINERS for file name changes --- MAINTAINERS | 7 + drivers/gpu/drm/panel/Kconfig | 10 + drivers/gpu/drm/panel/Makefile| 1 + .../gpu/drm/panel/panel-novatek-nt36672a.c| 711 ++ 4 files changed, 729 insertions(+) create mode 100644 drivers/gpu/drm/panel/panel-novatek-nt36672a.c diff --git a/MAINTAINERS b/MAINTAINERS index 01fb9ee6b951..c6fb966c0959 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5517,6 +5517,13 @@ T: git git://anongit.freedesktop.org/drm/drm-misc F: Documentation/devicetree/bindings/display/panel/novatek,nt35510.yaml F: drivers/gpu/drm/panel/panel-novatek-nt35510.c +DRM DRIVER FOR NOVATEK NT36672A PANELS +M: Sumit Semwal +S: Maintained +T: git git://anongit.freedesktop.org/drm/drm-misc +F: Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml +F: drivers/gpu/drm/panel/panel-novatek-nt36672a.c + DRM DRIVER FOR NVIDIA GEFORCE/QUADRO GPUS M: Ben Skeggs L: dri-devel@lists.freedesktop.org diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig index 8d97d07c5871..51e6cb6c7826 100644 --- a/drivers/gpu/drm/panel/Kconfig +++ b/drivers/gpu/drm/panel/Kconfig @@ -208,6 +208,16 @@ config DRM_PANEL_NOVATEK_NT35510 around the Novatek NT35510 display controller, such as some Hydis panels. +config DRM_PANEL_NOVATEK_NT36672A + tristate "Novatek NT36672A DSI panel" + depends on OF + depends on DRM_MIPI_DSI + depends on BACKLIGHT_CLASS_DEVICE + help + Say Y here if you want to enable support for the panels built + around the Novatek NT36672A display controller, such as some + Tianma panels used in a few Xiaomi Poco F1 mobile phones. + config DRM_PANEL_NOVATEK_NT39016 tristate "Novatek NT39016 RGB/SPI panel" depends on OF && SPI diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile index 15a4e7752951..4a36eb45f670 100644 --- a/drivers/gpu/drm/panel/Makefile +++ b/drivers/gpu/drm/panel/Makefile @@ -19,6 +19,7 @@ obj-$(CONFIG_DRM_PANEL_LG_LB035Q02) += panel-lg-lb035q02.o obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o obj-$(CONFIG_DRM_PANEL_NEC_NL8048HL11) += panel-nec-nl8048hl11.o obj-$(CONFIG_DRM_PANEL_NOVATEK_NT35510) += panel-novatek-nt35510.o +obj-$(CONFIG_DRM_PANEL_NOVATEK_NT36672A) += panel-novatek-nt36672a.o obj-$(CONFIG_DRM_PANEL_NOVATEK_NT39016) += panel-novatek-nt39016.o obj-$(CONFIG_DRM_PANEL_MANTIX_MLAF057WE51) += panel-mantix-mlaf057we51.o obj-$(CONFIG_DRM_PANEL_OLIMEX_LCD_OLINUXINO) += panel-olimex-lcd-olinuxino.o diff --git a/drivers/gpu/drm/panel/panel-novatek-nt36672a.c b/drivers/gpu/drm/panel/panel-novatek-nt36672a.c new file mode 100644 index ..533cd3934b8b --- /dev/null +++ b/drivers/gpu/drm/panel/panel-novatek-nt36672a.c @@ -0,0 +1,711 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright (C) 2020 Linaro Ltd + * Author: Sumit Semwal + * + * This driver is for the DSI interface to panels using the NT36672A display driver IC + * from Novatek. + * Curre
[PATCH v7 1/2] dt-bindings: display: panel: Add bindings for Novatek nt36672a
Novatek nt36672a is a display driver IC that can drive DSI panel. It
is also present in the Tianma video mode panel, which is a FHD+ panel
with a resolution of 1080x2246 and 6.18 inches size. It is found in
some of the Poco F1 phones.
This patch adds the display driver for the IC, with support added for
this tianma fhd video mode panel.
Signed-off-by: Sumit Semwal
Reviewed-by: Rob Herring
---
v2: remove ports node, making port@0 directly under panel@0 node.
v3: updated to replace port@0 to just 'port'.
v5: renamed to novatek,nt36672a, since the binding is for the IC and not
the panel.
v6: v5 review comments incorporated.
- added enum for the compatible part, since it can be extended in
future.
- few cosmetic updates.
---
.../display/panel/novatek,nt36672a.yaml | 87 +++
1 file changed, 87 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml
b/Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml
new file mode 100644
index ..d2170de6b723
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml
@@ -0,0 +1,87 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/novatek,nt36672a.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Novatek NT36672A based DSI display Panels
+
+maintainers:
+ - Sumit Semwal
+
+description: |
+ The nt36672a IC from Novatek is a generic DSI Panel IC used to drive dsi
+ panels.
+ Right now, support is added only for a Tianma FHD+ LCD display panel with a
+ resolution of 1080x2246. It is a video mode DSI panel.
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+items:
+ - enum:
+ - tianma,fhd-video
+ - const: novatek,nt36672a
+description: This indicates the panel manufacturer of the panel that is
+ in turn using the NT36672A panel driver. This compatible string
+ determines how the NT36672A panel driver is configured for the indicated
+ panel. The novatek,nt36672a compatible shall always be provided as a
fallback.
+
+ reset-gpios:
+description: phandle of gpio for reset line - This should be 8mA, gpio
+ can be configured using mux, pinctrl, pinctrl-names (active high)
+
+ vddio-supply:
+description: phandle of the regulator that provides the supply voltage
+ Power IC supply
+
+ vddpos-supply:
+description: phandle of the positive boost supply regulator
+
+ vddneg-supply:
+description: phandle of the negative boost supply regulator
+
+ reg: true
+ port: true
+
+required:
+ - compatible
+ - reg
+ - vddi0-supply
+ - vddpos-supply
+ - vddneg-supply
+ - reset-gpios
+ - port
+
+unevaluatedProperties: false
+
+examples:
+ - |+
+#include
+
+dsi0 {
+#address-cells = <1>;
+#size-cells = <0>;
+
+panel@0 {
+compatible = "tianma,fhd-video", "novatek,nt36672a";
+reg = <0>;
+vddi0-supply = <_l14a_1p88>;
+vddpos-supply = <>;
+vddneg-supply = <>;
+
+reset-gpios = < 6 GPIO_ACTIVE_HIGH>;
+
+#address-cells = <1>;
+#size-cells = <0>;
+port {
+tianma_nt36672a_in_0: endpoint {
+remote-endpoint = <_out>;
+};
+};
+};
+};
+
+...
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 0/2]dd support for Tianma nt36672a video mode panel
Some Poco F1 phones from Xiaomi have a FHD+ video mode panel based on the Novatek NT36672A display controller; Add support for the same. Most of the panel data is taken from downstream panel dts, and is converted to drm-panel based driver by me. It has been validated with v5.9-rc1 based drm-misc-next on Poco F1 phone; my tree with other dependent patches is here [1] [1]: https://git.linaro.org/people/sumit.semwal/linux-dev.git/log/?h=dev/poco-panel-upstreaming --- v2: In dt-binding, removed ports node, making port@0 directly under panel@0 node. Also updated the panel_on delay to a safer 200ms as needed for latest Android. v3: Replaced port@0 with just port in panel@0 node. v4: Since "0425662fdf05: drm: Nuke mode->vrefresh", we have to calculate vrefresh on demand. Update for it. v5: Fixed review comments from Sam: - rebased on top of drm-misc-next remove return of drm_panel_add() remove drm_panel_detach() - renamed the panel driver file to reflect that this is a novatek nt36672a display driver and not only for tianma panels. Adjusted some internal names also to reflect the same. - corrected changelog to add info about the generic Novatek DSI IC - corrected compatible string accordingly - removed pinctrl - used drm_panel* API for prepare/unprepare/disable/remove v6: Fixed few review comments on v5 from Sam: - add dev_err_probe() support - move DRM_* error printing to dev_err() - removed a few unnecessary bits v7: Fixed review comments on v6 from Bjorn: - Reworked the send_mipi_commands functionality - removed regulator disable_loads; moved active_load setting to probe time - made function names and struct less generic - updated the reset_gpio working to active_low - update MAINTAINERS for file name changes Sumit Semwal (2): dt-bindings: display: panel: Add bindings for Novatek nt36672a drm: panel: Add novatek nt36672a panel driver .../display/panel/novatek,nt36672a.yaml | 87 +++ MAINTAINERS | 7 + drivers/gpu/drm/panel/Kconfig | 10 + drivers/gpu/drm/panel/Makefile| 1 + .../gpu/drm/panel/panel-novatek-nt36672a.c| 711 ++ 5 files changed, 816 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml create mode 100644 drivers/gpu/drm/panel/panel-novatek-nt36672a.c -- 2.28.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 2/2] drm: panel: Add novatek nt36672a panel driver
Hi Sam, On Sun, 30 Aug 2020 at 03:01, Sam Ravnborg wrote: > > Hi Sumit. > > On Wed, Aug 26, 2020 at 09:33:08PM +0530, Sumit Semwal wrote: > > Novatek NT36672a is a generic DSI IC that drives command and video mode > > panels. Add the driver for it. > > > > Right now adding support for some Poco F1 phones that have an LCD panel > > from Tianma connected with this IC, with a resolution of 1080x2246 that > > operates in DSI video mode. > > > > During testing, Benni Steini helped us fix > > the reset sequence timing (from 10ms to 20ms), to get the bootanimation > > to work on Android. > > > > With current AOSP, we need to increase it to 200ms - this seems to be a > > safe high value to avoid a white screen occasionally. > > > > Signed-off-by: Sumit Semwal > > Cc: Benni Steini > > > > --- > > v2: increase reset sequence timing to a safe 200ms > > v4: Since "0425662fdf05: drm: Nuke mode->vrefresh", we have to calculate > > vrefresh on demand. Update for it. > > v5: Fixed review comments from Sam: > > - rebased on top of drm-misc-next > >remove return of drm_panel_add() > >remove drm_panel_detach() > > - renamed the panel driver file to reflect that this is a novatek > >nt36672a display driver and not only for tianma panels. > >Adjusted some internal names also to reflect the same. > > - corrected changelog to add info about the generic Novatek DSI IC > > - corrected compatible string accordingly > > - removed pinctrl > > - used drm_panel* API for prepare/unprepare/disable/remove > Thanks for the detailed follow-up - very nice. > > A few things slipped thought last review and we have gained support for > dv_err_probe() now. Also dev_err() and friends are now the right choice > for panel drivers. Thanks very much for your detailed review :) - I have incorporated the review comments, and will send v6 (hopefully last :) ) in a short while. > > Sam > > > --- > > MAINTAINERS | 7 + > > drivers/gpu/drm/panel/Kconfig | 10 + > > drivers/gpu/drm/panel/Makefile| 1 + > > .../gpu/drm/panel/panel-novatek-nt36672a.c| 767 ++ > > 4 files changed, 785 insertions(+) > > create mode 100644 drivers/gpu/drm/panel/panel-novatek-nt36672a.c > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index 01fb9ee6b951..aeecade2d65f 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -5619,6 +5619,13 @@ T: git git://anongit.freedesktop.org/drm/drm-misc > > F: Documentation/devicetree/bindings/display/ste,mcde.txt > > F: drivers/gpu/drm/mcde/ > > > > +DRM DRIVER FOR TIANMA NT36672A PANELS > > +M: Sumit Semwal > > +S: Maintained > > +T: git git://anongit.freedesktop.org/drm/drm-misc > > +F: > > Documentation/devicetree/bindings/display/panel/tianma,nt36672a-panel.yaml > > +F: drivers/gpu/drm/panel/panel-tianma-nt36672a.c > > + > > DRM DRIVER FOR TDFX VIDEO CARDS > > S: Orphan / Obsolete > > F: drivers/gpu/drm/tdfx/ > > diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig > > index 8d97d07c5871..02600f12a063 100644 > > --- a/drivers/gpu/drm/panel/Kconfig > > +++ b/drivers/gpu/drm/panel/Kconfig > > @@ -208,6 +208,16 @@ config DRM_PANEL_NOVATEK_NT35510 > > around the Novatek NT35510 display controller, such as some > > Hydis panels. > > > > +config DRM_PANEL_NOVATEK_NT36672A > > + tristate "Novatek NT36672A DSI panel" > > + depends on OF > > + depends on DRM_MIPI_DSI > > + depends on BACKLIGHT_CLASS_DEVICE > > + help > > + Say Y here if you want to enable support for the panels built > > + around the Novatek NT36672A display controller, such as some > > + Tianma panels used in a few Xiaomi Poco F1 mobile phone. > > + > > config DRM_PANEL_NOVATEK_NT39016 > > tristate "Novatek NT39016 RGB/SPI panel" > > depends on OF && SPI > > diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile > > index 15a4e7752951..4a36eb45f670 100644 > > --- a/drivers/gpu/drm/panel/Makefile > > +++ b/drivers/gpu/drm/panel/Makefile > > @@ -19,6 +19,7 @@ obj-$(CONFIG_DRM_PANEL_LG_LB035Q02) += panel-lg-lb035q02.o > > obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o > > obj-$(CONFIG_DRM_PANEL_NEC_NL8048HL11) += panel-nec-nl8048hl11.o > > ob
[PATCH v6 1/2] dt-bindings: display: panel: Add bindings for Novatek nt36672a
Novatek nt36672a is a display driver IC that can drive DSI panel. It
is also present in the Tianma video mode panel, which is a FHD+ panel
with a resolution of 1080x2246 and 6.18 inches size. It is found in
some of the Poco F1 phones.
This patch adds the display driver for the IC, with support added for
this tianma fhd video mode panel.
Signed-off-by: Sumit Semwal
Reviewed-by: Rob Herring
---
v2: remove ports node, making port@0 directly under panel@0 node.
v3: updated to replace port@0 to just 'port'.
v5: renamed to novatek,nt36672a, since the binding is for the IC and not
the panel.
v6: v5 review comments incorporated.
- added enum for the compatible part, since it can be extended in
future.
- few cosmetic updates.
---
.../display/panel/novatek,nt36672a.yaml | 87 +++
1 file changed, 87 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml
b/Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml
new file mode 100644
index ..d2170de6b723
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml
@@ -0,0 +1,87 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/novatek,nt36672a.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Novatek NT36672A based DSI display Panels
+
+maintainers:
+ - Sumit Semwal
+
+description: |
+ The nt36672a IC from Novatek is a generic DSI Panel IC used to drive dsi
+ panels.
+ Right now, support is added only for a Tianma FHD+ LCD display panel with a
+ resolution of 1080x2246. It is a video mode DSI panel.
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+items:
+ - enum:
+ - tianma,fhd-video
+ - const: novatek,nt36672a
+description: This indicates the panel manufacturer of the panel that is
+ in turn using the NT36672A panel driver. This compatible string
+ determines how the NT36672A panel driver is configured for the indicated
+ panel. The novatek,nt36672a compatible shall always be provided as a
fallback.
+
+ reset-gpios:
+description: phandle of gpio for reset line - This should be 8mA, gpio
+ can be configured using mux, pinctrl, pinctrl-names (active high)
+
+ vddio-supply:
+description: phandle of the regulator that provides the supply voltage
+ Power IC supply
+
+ vddpos-supply:
+description: phandle of the positive boost supply regulator
+
+ vddneg-supply:
+description: phandle of the negative boost supply regulator
+
+ reg: true
+ port: true
+
+required:
+ - compatible
+ - reg
+ - vddi0-supply
+ - vddpos-supply
+ - vddneg-supply
+ - reset-gpios
+ - port
+
+unevaluatedProperties: false
+
+examples:
+ - |+
+#include
+
+dsi0 {
+#address-cells = <1>;
+#size-cells = <0>;
+
+panel@0 {
+compatible = "tianma,fhd-video", "novatek,nt36672a";
+reg = <0>;
+vddi0-supply = <_l14a_1p88>;
+vddpos-supply = <>;
+vddneg-supply = <>;
+
+reset-gpios = < 6 GPIO_ACTIVE_HIGH>;
+
+#address-cells = <1>;
+#size-cells = <0>;
+port {
+tianma_nt36672a_in_0: endpoint {
+remote-endpoint = <_out>;
+};
+};
+};
+};
+
+...
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 2/2] drm: panel: Add novatek nt36672a panel driver
Novatek NT36672a is a generic DSI IC that drives command and video mode panels. Add the driver for it. Right now adding support for some Poco F1 phones that have an LCD panel from Tianma connected with this IC, with a resolution of 1080x2246 that operates in DSI video mode. During testing, Benni Steini helped us fix the reset sequence timing (from 10ms to 20ms), to get the bootanimation to work on Android. With current AOSP, we need to increase it to 200ms - this seems to be a safe high value to avoid a white screen occasionally. Signed-off-by: Sumit Semwal Cc: Benni Steini --- v2: increase reset sequence timing to a safe 200ms v4: Since "0425662fdf05: drm: Nuke mode->vrefresh", we have to calculate vrefresh on demand. Update for it. v5: Fixed review comments from Sam: - rebased on top of drm-misc-next remove return of drm_panel_add() remove drm_panel_detach() - renamed the panel driver file to reflect that this is a novatek nt36672a display driver and not only for tianma panels. Adjusted some internal names also to reflect the same. - corrected changelog to add info about the generic Novatek DSI IC - corrected compatible string accordingly - removed pinctrl - used drm_panel* API for prepare/unprepare/disable/remove v6: Fixed few review comments on v5 from Sam: - add dev_err_probe() support - move DRM_* error printing to dev_err() - removed a few unnecessary bits --- MAINTAINERS | 7 + drivers/gpu/drm/panel/Kconfig | 10 + drivers/gpu/drm/panel/Makefile| 1 + .../gpu/drm/panel/panel-novatek-nt36672a.c| 740 ++ 4 files changed, 758 insertions(+) create mode 100644 drivers/gpu/drm/panel/panel-novatek-nt36672a.c diff --git a/MAINTAINERS b/MAINTAINERS index 01fb9ee6b951..aeecade2d65f 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5619,6 +5619,13 @@ T: git git://anongit.freedesktop.org/drm/drm-misc F: Documentation/devicetree/bindings/display/ste,mcde.txt F: drivers/gpu/drm/mcde/ +DRM DRIVER FOR TIANMA NT36672A PANELS +M: Sumit Semwal +S: Maintained +T: git git://anongit.freedesktop.org/drm/drm-misc +F: Documentation/devicetree/bindings/display/panel/tianma,nt36672a-panel.yaml +F: drivers/gpu/drm/panel/panel-tianma-nt36672a.c + DRM DRIVER FOR TDFX VIDEO CARDS S: Orphan / Obsolete F: drivers/gpu/drm/tdfx/ diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig index 8d97d07c5871..02600f12a063 100644 --- a/drivers/gpu/drm/panel/Kconfig +++ b/drivers/gpu/drm/panel/Kconfig @@ -208,6 +208,16 @@ config DRM_PANEL_NOVATEK_NT35510 around the Novatek NT35510 display controller, such as some Hydis panels. +config DRM_PANEL_NOVATEK_NT36672A + tristate "Novatek NT36672A DSI panel" + depends on OF + depends on DRM_MIPI_DSI + depends on BACKLIGHT_CLASS_DEVICE + help + Say Y here if you want to enable support for the panels built + around the Novatek NT36672A display controller, such as some + Tianma panels used in a few Xiaomi Poco F1 mobile phone. + config DRM_PANEL_NOVATEK_NT39016 tristate "Novatek NT39016 RGB/SPI panel" depends on OF && SPI diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile index 15a4e7752951..4a36eb45f670 100644 --- a/drivers/gpu/drm/panel/Makefile +++ b/drivers/gpu/drm/panel/Makefile @@ -19,6 +19,7 @@ obj-$(CONFIG_DRM_PANEL_LG_LB035Q02) += panel-lg-lb035q02.o obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o obj-$(CONFIG_DRM_PANEL_NEC_NL8048HL11) += panel-nec-nl8048hl11.o obj-$(CONFIG_DRM_PANEL_NOVATEK_NT35510) += panel-novatek-nt35510.o +obj-$(CONFIG_DRM_PANEL_NOVATEK_NT36672A) += panel-novatek-nt36672a.o obj-$(CONFIG_DRM_PANEL_NOVATEK_NT39016) += panel-novatek-nt39016.o obj-$(CONFIG_DRM_PANEL_MANTIX_MLAF057WE51) += panel-mantix-mlaf057we51.o obj-$(CONFIG_DRM_PANEL_OLIMEX_LCD_OLINUXINO) += panel-olimex-lcd-olinuxino.o diff --git a/drivers/gpu/drm/panel/panel-novatek-nt36672a.c b/drivers/gpu/drm/panel/panel-novatek-nt36672a.c new file mode 100644 index ..675e9d52f3c4 --- /dev/null +++ b/drivers/gpu/drm/panel/panel-novatek-nt36672a.c @@ -0,0 +1,740 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright (C) 2020 Linaro Ltd + * Author: Sumit Semwal + * + * This driver is for the DSI interface to panels using the NT36672A display driver IC + * from Novatek. + * Currently supported are the Tianma FHD+ panels found in some Xiaomi phones, including + * some variants of the Poco F1 phone. + * + * Panels using the Novatek NT37762A IC should add appropriate configuration per-panel and + * use this driver. + */ + +#include +#include +#include +#include +#include + +#include +#include +#include + +#include +#include +#include +#include + +#incl
[PATCH v6 0/2] Add support for Tianma nt36672a video mode panel
Some Poco F1 phones from Xiaomi have a FHD+ video mode panel based on the Novatek NT36672A display controller; Add support for the same. Most of the panel data is taken from downstream panel dts, and is converted to drm-panel based driver by me. It has been validated with v5.9-rc1 based drm-misc-next on Poco F1 phone; my tree with other dependent patches is here [1] [1]: https://git.linaro.org/people/sumit.semwal/linux-dev.git/log/?h=dev/poco-panel-upstreaming --- v2: In dt-binding, removed ports node, making port@0 directly under panel@0 node. Also updated the panel_on delay to a safer 200ms as needed for latest Android. v3: Replaced port@0 with just port in panel@0 node. v4: Since "0425662fdf05: drm: Nuke mode->vrefresh", we have to calculate vrefresh on demand. Update for it. v5: Fixed review comments from Sam: - rebased on top of drm-misc-next remove return of drm_panel_add() remove drm_panel_detach() - renamed the panel driver file to reflect that this is a novatek nt36672a display driver and not only for tianma panels. Adjusted some internal names also to reflect the same. - corrected changelog to add info about the generic Novatek DSI IC - corrected compatible string accordingly - removed pinctrl - used drm_panel* API for prepare/unprepare/disable/remove v6: Fixed few review comments on v5 from Sam: - add dev_err_probe() support - move DRM_* error printing to dev_err() - removed a few unnecessary bits Sumit Semwal (2): dt-bindings: display: panel: Add bindings for Novatek nt36672a drm: panel: Add novatek nt36672a panel driver .../display/panel/novatek,nt36672a.yaml | 87 ++ MAINTAINERS | 7 + drivers/gpu/drm/panel/Kconfig | 10 + drivers/gpu/drm/panel/Makefile| 1 + .../gpu/drm/panel/panel-novatek-nt36672a.c| 740 ++ 5 files changed, 845 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml create mode 100644 drivers/gpu/drm/panel/panel-novatek-nt36672a.c -- 2.28.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 0/2] Add support for Tianma nt36672a video mode panel
Some Poco F1 phones from Xiaomi have a FHD+ video mode panel based on the Novatek NT36672A display controller; Add support for the same. Most of the panel data is taken from downstream panel dts, and is converted to drm-panel based driver by me. It has been validated with v5.9-rc1 based drm-misc-next on Poco F1 phone; my tree with other dependent patches is here [1] [1]: https://git.linaro.org/people/sumit.semwal/linux-dev.git/log/?h=dev/poco-panel-upstreaming --- v2: In dt-binding, removed ports node, making port@0 directly under panel@0 node. Also updated the panel_on delay to a safer 200ms as needed for latest Android. v3: Replaced port@0 with just port in panel@0 node. v4: Since "0425662fdf05: drm: Nuke mode->vrefresh", we have to calculate vrefresh on demand. Update for it. v5: Fixed review comments from Sam: - rebased on top of drm-misc-next remove return of drm_panel_add() remove drm_panel_detach() - renamed the panel driver file to reflect that this is a novatek nt36672a display driver and not only for tianma panels. Adjusted some internal names also to reflect the same. - corrected changelog to add info about the generic Novatek DSI IC - corrected compatible string accordingly - removed pinctrl - used drm_panel* API for prepare/unprepare/disable/remove Sumit Semwal (2): dt-bindings: display: panel: Add bindings for Novatek nt36672a drm: panel: Add novatek nt36672a panel driver .../display/panel/novatek,nt36672a.yaml | 81 ++ MAINTAINERS | 7 + drivers/gpu/drm/panel/Kconfig | 10 + drivers/gpu/drm/panel/Makefile| 1 + .../gpu/drm/panel/panel-novatek-nt36672a.c| 767 ++ 5 files changed, 866 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml create mode 100644 drivers/gpu/drm/panel/panel-novatek-nt36672a.c -- 2.28.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 2/2] drm: panel: Add novatek nt36672a panel driver
Novatek NT36672a is a generic DSI IC that drives command and video mode
panels. Add the driver for it.
Right now adding support for some Poco F1 phones that have an LCD panel
from Tianma connected with this IC, with a resolution of 1080x2246 that
operates in DSI video mode.
During testing, Benni Steini helped us fix
the reset sequence timing (from 10ms to 20ms), to get the bootanimation
to work on Android.
With current AOSP, we need to increase it to 200ms - this seems to be a
safe high value to avoid a white screen occasionally.
Signed-off-by: Sumit Semwal
Cc: Benni Steini
---
v2: increase reset sequence timing to a safe 200ms
v4: Since "0425662fdf05: drm: Nuke mode->vrefresh", we have to calculate
vrefresh on demand. Update for it.
v5: Fixed review comments from Sam:
- rebased on top of drm-misc-next
remove return of drm_panel_add()
remove drm_panel_detach()
- renamed the panel driver file to reflect that this is a novatek
nt36672a display driver and not only for tianma panels.
Adjusted some internal names also to reflect the same.
- corrected changelog to add info about the generic Novatek DSI IC
- corrected compatible string accordingly
- removed pinctrl
- used drm_panel* API for prepare/unprepare/disable/remove
---
MAINTAINERS | 7 +
drivers/gpu/drm/panel/Kconfig | 10 +
drivers/gpu/drm/panel/Makefile| 1 +
.../gpu/drm/panel/panel-novatek-nt36672a.c| 767 ++
4 files changed, 785 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-novatek-nt36672a.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 01fb9ee6b951..aeecade2d65f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5619,6 +5619,13 @@ T: git git://anongit.freedesktop.org/drm/drm-misc
F: Documentation/devicetree/bindings/display/ste,mcde.txt
F: drivers/gpu/drm/mcde/
+DRM DRIVER FOR TIANMA NT36672A PANELS
+M: Sumit Semwal
+S: Maintained
+T: git git://anongit.freedesktop.org/drm/drm-misc
+F:
Documentation/devicetree/bindings/display/panel/tianma,nt36672a-panel.yaml
+F: drivers/gpu/drm/panel/panel-tianma-nt36672a.c
+
DRM DRIVER FOR TDFX VIDEO CARDS
S: Orphan / Obsolete
F: drivers/gpu/drm/tdfx/
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 8d97d07c5871..02600f12a063 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -208,6 +208,16 @@ config DRM_PANEL_NOVATEK_NT35510
around the Novatek NT35510 display controller, such as some
Hydis panels.
+config DRM_PANEL_NOVATEK_NT36672A
+ tristate "Novatek NT36672A DSI panel"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y here if you want to enable support for the panels built
+ around the Novatek NT36672A display controller, such as some
+ Tianma panels used in a few Xiaomi Poco F1 mobile phone.
+
config DRM_PANEL_NOVATEK_NT39016
tristate "Novatek NT39016 RGB/SPI panel"
depends on OF && SPI
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 15a4e7752951..4a36eb45f670 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -19,6 +19,7 @@ obj-$(CONFIG_DRM_PANEL_LG_LB035Q02) += panel-lg-lb035q02.o
obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
obj-$(CONFIG_DRM_PANEL_NEC_NL8048HL11) += panel-nec-nl8048hl11.o
obj-$(CONFIG_DRM_PANEL_NOVATEK_NT35510) += panel-novatek-nt35510.o
+obj-$(CONFIG_DRM_PANEL_NOVATEK_NT36672A) += panel-novatek-nt36672a.o
obj-$(CONFIG_DRM_PANEL_NOVATEK_NT39016) += panel-novatek-nt39016.o
obj-$(CONFIG_DRM_PANEL_MANTIX_MLAF057WE51) += panel-mantix-mlaf057we51.o
obj-$(CONFIG_DRM_PANEL_OLIMEX_LCD_OLINUXINO) += panel-olimex-lcd-olinuxino.o
diff --git a/drivers/gpu/drm/panel/panel-novatek-nt36672a.c
b/drivers/gpu/drm/panel/panel-novatek-nt36672a.c
new file mode 100644
index ..3f0c18e46818
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-novatek-nt36672a.c
@@ -0,0 +1,767 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2020 Linaro Ltd
+ * Author: Sumit Semwal
+ *
+ * This driver is for the DSI interface to panels using the NT36672A display
driver IC
+ * from Novatek.
+ * Currently supported are the Tianma FHD+ panels found in some Xiaomi phones,
including
+ * some variants of the Poco F1 phone.
+ *
+ * Panels using the Novatek NT37762A IC should add appropriate configuration
per-panel and
+ * use this driver.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+struct panel_cmd {
+ size_t len;
+ const char *data;
+};
+
+#define _INIT_CMD(...) { \
+ .len = sizeof((char[]){__VA_ARGS__}
[PATCH v5 1/2] dt-bindings: display: panel: Add bindings for Novatek nt36672a
Novatek nt36672a is a display driver IC that can drive DSI panel. It
is also present in the Tianma video mode panel, which is a FHD+ panel
with a resolution of 1080x2246 and 6.18 inches size. It is found in
some of the Poco F1 phones.
This patch adds the display driver for the IC, with support added for
this tianma fhd video mode panel.
Signed-off-by: Sumit Semwal
Reviewed-by: Rob Herring
---
v2: remove ports node, making port@0 directly under panel@0 node.
v3: updated to replace port@0 to just 'port'.
v5: renamed to novatek,nt36672a, since the binding is for the IC and not
the panel.
---
.../display/panel/novatek,nt36672a.yaml | 81 +++
1 file changed, 81 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml
b/Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml
new file mode 100644
index ..7f8d1097bee0
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml
@@ -0,0 +1,81 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/novatek,nt36672a.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Novatek NT36672A based DSI display Panels
+
+maintainers:
+ - Sumit Semwal
+
+description: |
+ The nt36672a IC from Novatek is a generic DSI Panel IC used to drive dsi
+ panels.
+ Right now, support is added only for a Tianma FHD+ LCD display panel with a
+ resolution of 1080x2246. It is a video mode DSI panel.
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+items:
+ - const: tianma,fhd-video
+ - const: novatek,nt36672a
+description: This indicates the panel manufacturer of the panel that is
+ in turn using the NT36672A panel driver. This compatible string
+ determines how the NT36672A panel driver is configured for the indicated
+ panel. The novatek,nt36672a compatible shall always be provided as a
fallback.
+
+ reg: true
+ reset-gpios:
+description: phandle of gpio for reset line - This should be 8mA, gpio
+ can be configured using mux, pinctrl, pinctrl-names (active high)
+ vddio-supply:
+description: phandle of the regulator that provides the supply voltage
+ Power IC supply
+ vddpos-supply:
+description: phandle of the positive boost supply regulator
+ vddneg-supply:
+description: phandle of the negative boost supply regulator
+ port: true
+
+required:
+ - compatible
+ - reg
+ - vddi0-supply
+ - vddpos-supply
+ - vddneg-supply
+ - reset-gpios
+ - port
+
+unevaluatedProperties: false
+
+examples:
+ - |+
+#include
+dsi0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ panel@0 {
+compatible = "tianma,fhd-video", "novatek,nt36672a";
+reg = <0>;
+vddi0-supply = <_l14a_1p88>;
+vddpos-supply = <>;
+vddneg-supply = <>;
+
+reset-gpios = < 6 GPIO_ACTIVE_HIGH>;
+
+#address-cells = <1>;
+#size-cells = <0>;
+port {
+ tianma_nt36672a_in_0: endpoint {
+remote-endpoint = <_out>;
+ };
+};
+ };
+};
+
+...
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND PATCH 1/2] dma-buf: Fix kerneldoc of dma_buf_set_name()
Hello Krzystof, On Wed, 19 Aug 2020 at 23:21, Krzysztof Kozlowski wrote: > > Fix W=1 compile warnings (invalid kerneldoc): > > drivers/dma-buf/dma-buf.c:328: warning: Function parameter or member > 'dmabuf' not described in 'dma_buf_set_name' Thanks for the patch; I will apply it to drm-misc. > > Signed-off-by: Krzysztof Kozlowski > --- > drivers/dma-buf/dma-buf.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c > index 1699a8e309ef..58564d82a3a2 100644 > --- a/drivers/dma-buf/dma-buf.c > +++ b/drivers/dma-buf/dma-buf.c > @@ -316,9 +316,9 @@ static __poll_t dma_buf_poll(struct file *file, > poll_table *poll) > * name of the dma-buf if the same piece of memory is used for multiple > * purpose between different devices. > * > - * @dmabuf [in] dmabuf buffer that will be renamed. > - * @buf: [in] A piece of userspace memory that contains the name of > - * the dma-buf. > + * @dmabuf: [in] dmabuf buffer that will be renamed. > + * @buf:[in] A piece of userspace memory that contains the name of > + * the dma-buf. > * > * Returns 0 on success. If the dma-buf buffer is already attached to > * devices, return -EBUSY. > -- > 2.17.1 > Best, Sumit ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 2/2] drm: panel: Add tianma nt36672a panel driver
Hello Sam, Thanks very much for the review. On Fri, 14 Aug 2020 at 01:16, Sam Ravnborg wrote: > > Hi Sumit. > > On Tue, Aug 11, 2020 at 11:51:07PM +0530, Sumit Semwal wrote: > > Some Poco F1 phones have an LCD panel from Tianma, model nt36672a, > > with a resolution of 1080x2246 that operates in DSI video mode. > > > > Add the drm panel driver for it. > > > > During testing, Benni Steini helped us fix > > the reset sequence timing (from 10ms to 20ms), to get the bootanimation > > to work on Android. > > > > With current AOSP, we need to increase it to 200ms - this seems to be a > > safe high value to avoid a white screen occasionally. > > > > Signed-off-by: Sumit Semwal > > Cc: Benni Steini > > Checkpatch is not happy with this patch. > Please fix relevant warnings. > > My checkpatch options: > -q --emacs --strict --show-types > > A lot of details in the following. > Sorry for not catching these before. > > Sam > > > > > --- > > v2: increase reset sequence timing to a safe 200ms > > v4: Since "0425662fdf05: drm: Nuke mode->vrefresh", we have to calculate > > vrefresh on demand. Update for it. > > --- > > MAINTAINERS | 7 + > > drivers/gpu/drm/panel/Kconfig | 11 + > > drivers/gpu/drm/panel/Makefile| 1 + > > drivers/gpu/drm/panel/panel-tianma-nt36672a.c | 858 ++ > > 4 files changed, 877 insertions(+) > > create mode 100644 drivers/gpu/drm/panel/panel-tianma-nt36672a.c > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index f77df02e4121..9e4bc8da9b2d 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -5611,6 +5611,13 @@ T: git git://anongit.freedesktop.org/drm/drm-misc > > F: Documentation/devicetree/bindings/display/ste,mcde.txt > > F: drivers/gpu/drm/mcde/ > > > > +DRM DRIVER FOR TIANMA NT36672A PANELS > > +M: Sumit Semwal > > +S: Maintained > > +T: git git://anongit.freedesktop.org/drm/drm-misc > > +F: > > Documentation/devicetree/bindings/display/panel/tianma,nt36672a-panel.yaml > > +F: drivers/gpu/drm/panel/panel-tianma-nt36672a.c > > + > > DRM DRIVER FOR TDFX VIDEO CARDS > > S: Orphan / Obsolete > > F: drivers/gpu/drm/tdfx/ > > diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig > > index de2f2a452be5..8108a682dcb0 100644 > > --- a/drivers/gpu/drm/panel/Kconfig > > +++ b/drivers/gpu/drm/panel/Kconfig > > @@ -437,6 +437,17 @@ config DRM_PANEL_TPO_TD043MTEA1 > > Say Y here if you want to enable support for TPO TD043MTEA1 800x480 > > 4.3" panel (found on the OMAP3 Pandora board). > > > > +config DRM_PANEL_TIANMA_FHD_NT36672A > > + tristate "TIANMA NT36672A panel" > > + depends on OF > > + depends on DRM_MIPI_DSI > > + depends on BACKLIGHT_CLASS_DEVICE > > + help > > + Say Y here if you want to enable support for the Tianma NT36672A > > + panel. It is seen mostly in Xiaomi Poco F1 mobile phone. > > + The panel has a 1080x2246 resolution and uses 24 bit RGB per pixel. > > + It provides a MIPI DSI interface to the host. > > + > > config DRM_PANEL_TPO_TPG110 > > tristate "TPO TPG 800x400 panel" > > depends on OF && SPI && GPIOLIB > > diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile > > index e45ceac6286f..472ae9ba8788 100644 > > --- a/drivers/gpu/drm/panel/Makefile > > +++ b/drivers/gpu/drm/panel/Makefile > > @@ -44,6 +44,7 @@ obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7703) += > > panel-sitronix-st7703.o > > obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o > > obj-$(CONFIG_DRM_PANEL_SONY_ACX424AKP) += panel-sony-acx424akp.o > > obj-$(CONFIG_DRM_PANEL_SONY_ACX565AKM) += panel-sony-acx565akm.o > > +obj-$(CONFIG_DRM_PANEL_TIANMA_FHD_NT36672A) += panel-tianma-nt36672a.o > > obj-$(CONFIG_DRM_PANEL_TPO_TD028TTEC1) += panel-tpo-td028ttec1.o > > obj-$(CONFIG_DRM_PANEL_TPO_TD043MTEA1) += panel-tpo-td043mtea1.o > > obj-$(CONFIG_DRM_PANEL_TPO_TPG110) += panel-tpo-tpg110.o > > diff --git a/drivers/gpu/drm/panel/panel-tianma-nt36672a.c > > b/drivers/gpu/drm/panel/panel-tianma-nt36672a.c > > new file mode 100644 > > index ..2941975e039c > > --- /dev/null > > +++ b/drivers/gpu/drm/panel/panel-tianma-nt36672a.c > > @@ -0,0 +1,858 @@ > > +// SPDX-License-Identifier: GPL-2.0+ > > +/* &g
[PATCH v4 2/2] drm: panel: Add tianma nt36672a panel driver
Some Poco F1 phones have an LCD panel from Tianma, model nt36672a,
with a resolution of 1080x2246 that operates in DSI video mode.
Add the drm panel driver for it.
During testing, Benni Steini helped us fix
the reset sequence timing (from 10ms to 20ms), to get the bootanimation
to work on Android.
With current AOSP, we need to increase it to 200ms - this seems to be a
safe high value to avoid a white screen occasionally.
Signed-off-by: Sumit Semwal
Cc: Benni Steini
---
v2: increase reset sequence timing to a safe 200ms
v4: Since "0425662fdf05: drm: Nuke mode->vrefresh", we have to calculate
vrefresh on demand. Update for it.
---
MAINTAINERS | 7 +
drivers/gpu/drm/panel/Kconfig | 11 +
drivers/gpu/drm/panel/Makefile| 1 +
drivers/gpu/drm/panel/panel-tianma-nt36672a.c | 858 ++
4 files changed, 877 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-tianma-nt36672a.c
diff --git a/MAINTAINERS b/MAINTAINERS
index f77df02e4121..9e4bc8da9b2d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5611,6 +5611,13 @@ T: git git://anongit.freedesktop.org/drm/drm-misc
F: Documentation/devicetree/bindings/display/ste,mcde.txt
F: drivers/gpu/drm/mcde/
+DRM DRIVER FOR TIANMA NT36672A PANELS
+M: Sumit Semwal
+S: Maintained
+T: git git://anongit.freedesktop.org/drm/drm-misc
+F:
Documentation/devicetree/bindings/display/panel/tianma,nt36672a-panel.yaml
+F: drivers/gpu/drm/panel/panel-tianma-nt36672a.c
+
DRM DRIVER FOR TDFX VIDEO CARDS
S: Orphan / Obsolete
F: drivers/gpu/drm/tdfx/
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index de2f2a452be5..8108a682dcb0 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -437,6 +437,17 @@ config DRM_PANEL_TPO_TD043MTEA1
Say Y here if you want to enable support for TPO TD043MTEA1 800x480
4.3" panel (found on the OMAP3 Pandora board).
+config DRM_PANEL_TIANMA_FHD_NT36672A
+ tristate "TIANMA NT36672A panel"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y here if you want to enable support for the Tianma NT36672A
+ panel. It is seen mostly in Xiaomi Poco F1 mobile phone.
+ The panel has a 1080x2246 resolution and uses 24 bit RGB per pixel.
+ It provides a MIPI DSI interface to the host.
+
config DRM_PANEL_TPO_TPG110
tristate "TPO TPG 800x400 panel"
depends on OF && SPI && GPIOLIB
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index e45ceac6286f..472ae9ba8788 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -44,6 +44,7 @@ obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7703) +=
panel-sitronix-st7703.o
obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o
obj-$(CONFIG_DRM_PANEL_SONY_ACX424AKP) += panel-sony-acx424akp.o
obj-$(CONFIG_DRM_PANEL_SONY_ACX565AKM) += panel-sony-acx565akm.o
+obj-$(CONFIG_DRM_PANEL_TIANMA_FHD_NT36672A) += panel-tianma-nt36672a.o
obj-$(CONFIG_DRM_PANEL_TPO_TD028TTEC1) += panel-tpo-td028ttec1.o
obj-$(CONFIG_DRM_PANEL_TPO_TD043MTEA1) += panel-tpo-td043mtea1.o
obj-$(CONFIG_DRM_PANEL_TPO_TPG110) += panel-tpo-tpg110.o
diff --git a/drivers/gpu/drm/panel/panel-tianma-nt36672a.c
b/drivers/gpu/drm/panel/panel-tianma-nt36672a.c
new file mode 100644
index ..2941975e039c
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-tianma-nt36672a.c
@@ -0,0 +1,858 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2020 Linaro Ltd
+ * Author: Sumit Semwal
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+struct panel_cmd {
+ size_t len;
+ const char *data;
+};
+
+#define _INIT_CMD(...) { \
+ .len = sizeof((char[]){__VA_ARGS__}), \
+ .data = (char[]){__VA_ARGS__} }
+
+static const char * const regulator_names[] = {
+ "vddio",
+ "vddpos",
+ "vddneg",
+};
+
+static unsigned long const regulator_enable_loads[] = {
+ 62000,
+ 10,
+ 10
+};
+
+static unsigned long const regulator_disable_loads[] = {
+ 80,
+ 100,
+ 100
+};
+
+struct panel_desc {
+ const struct drm_display_mode *display_mode;
+ const char *panel_name;
+
+ unsigned int width_mm;
+ unsigned int height_mm;
+
+ unsigned long mode_flags;
+ enum mipi_dsi_pixel_format format;
+ unsigned int lanes;
+
+ const struct panel_cmd *on_cmds_1;
+ const struct panel_cmd *on_cmds_2;
+
+ const struct panel_cmd *off_cmds;
+};
+
+struct panel_info {
+ struct drm_panel base;
+ struct mipi_dsi_device *link;
+ const struct panel_desc *desc;
+
+
[PATCH v4 1/2] dt-bindings: display: panel: Add bindings for Tianma nt36672a panel
The nt36672a panel from Tianma is a FHD+ panel with a resolution of
1080x2246 and 6.18 inches size. It is found in some of the Poco F1
phones.
Signed-off-by: Sumit Semwal
Reviewed-by: Rob Herring
---
v2: remove ports node, making port@0 directly under panel@0 node.
v3: updated to replace port@0 to just 'port'.
---
.../display/panel/tianma,nt36672a.yaml| 95 +++
1 file changed, 95 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
b/Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
new file mode 100644
index ..03dc323332a5
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
@@ -0,0 +1,95 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/tianma,nt36672a.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Tianma model NT36672A DSI Panel display driver
+
+maintainers:
+ - Sumit Semwal
+
+description: |
+ The nt36672a panel from Tianma is a FHD+ LCD display panel with a resolution
+ of 1080x2246. It is a video mode DSI panel.
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+const: tianma,nt36672a
+
+ reg:
+description: DSI virtual channel of the peripheral
+
+ reset-gpios:
+description: phandle of gpio for reset line - This should be 8mA, gpio
+ can be configured using mux, pinctrl, pinctrl-names (active high)
+
+ vddio-supply:
+description: phandle of the regulator that provides the supply voltage
+ Power IC supply
+
+ vddpos-supply:
+description: phandle of the positive boost supply regulator
+
+ vddneg-supply:
+description: phandle of the negative boost supply regulator
+
+ pinctrl-names:
+description: Pinctrl for panel active and suspend
+
+ pinctrl-0:
+description: Active pinctrls
+
+ pinctrl-1:
+description: Suspend pinctrls
+
+ port: true
+
+required:
+ - compatible
+ - reg
+ - vddi0-supply
+ - vddpos-supply
+ - vddneg-supply
+ - reset-gpios
+ - pinctrl-names
+ - pinctrl-0
+ - pinctrl-1
+ - port
+
+unevaluatedProperties: false
+
+examples:
+ - |+
+#include
+dsi0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ panel@0 {
+compatible = "tianma,nt36672a";
+reg = <0>;
+vddi0-supply = <_l14a_1p88>;
+vddpos-supply = <>;
+vddneg-supply = <>;
+
+reset-gpios = < 6 GPIO_ACTIVE_HIGH>;
+
+pinctrl-names = "panel_active", "panel_suspend";
+pinctrl-0 = <_dsi_active>;
+pinctrl-1 = <_dsi_suspend>;
+
+#address-cells = <1>;
+#size-cells = <0>;
+port {
+ tianma_nt36672a_in_0: endpoint {
+remote-endpoint = <_out>;
+ };
+};
+ };
+};
+
+...
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 0/2] Add support for Tianma nt36672a video mode panel
Some Poco F1 phones from Xiaomi have an nt36672a video mode panel; add support for the same. Most of the panel data is taken from downstream panel dts, and is converted to drm-panel based driver by me. It has been validated with v5.8-rc5 on Poco F1 phone; my tree with other dependent patches is here [1] [1]: https://git.linaro.org/people/sumit.semwal/linux-dev.git/log/?h=dev/poco-panel-upstreaming --- v2: In dt-binding, removed ports node, making port@0 directly under panel@0 node. Also updated the panel_on delay to a safer 200ms as needed for latest Android. v3: Replaced port@0 with just port in panel@0 node. v4: Since "0425662fdf05: drm: Nuke mode->vrefresh", we have to calculate vrefresh on demand. Update for it. Sumit Semwal (2): dt-bindings: display: panel: Add bindings for Tianma nt36672a panel drm: panel: Add tianma nt36672a panel driver .../display/panel/tianma,nt36672a.yaml| 95 ++ MAINTAINERS | 7 + drivers/gpu/drm/panel/Kconfig | 11 + drivers/gpu/drm/panel/Makefile| 1 + drivers/gpu/drm/panel/panel-tianma-nt36672a.c | 858 ++ 5 files changed, 972 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml create mode 100644 drivers/gpu/drm/panel/panel-tianma-nt36672a.c -- 2.28.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND PATCH v3 0/2] Add support for Tianma nt36672a video mode panel
Some Poco F1 phones from Xiaomi have an nt36672a video mode panel; add support for the same. Most of the panel data is taken from downstream panel dts, and is converted to drm-panel based driver by me. It has been validated with v5.8-rc5 on Poco F1 phone; my tree with other dependent patches is here [1] [1]: https://git.linaro.org/people/sumit.semwal/linux-dev.git/log/?h=dev/poco-panel-upstreaming --- v2: In dt-binding, removed ports node, making port@0 directly under panel@0 node. Also updated the panel_on delay to a safer 200ms as needed for latest Android. v3: Replaced port@0 with just port in panel@0 node. [1]: Sumit Semwal (2): dt-bindings: display: panel: Add bindings for Tianma nt36672a panel drm: panel: Add tianma nt36672a panel driver .../display/panel/tianma,nt36672a.yaml| 95 ++ MAINTAINERS | 7 + drivers/gpu/drm/panel/Kconfig | 11 + drivers/gpu/drm/panel/Makefile| 1 + drivers/gpu/drm/panel/panel-tianma-nt36672a.c | 859 ++ 5 files changed, 973 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml create mode 100644 drivers/gpu/drm/panel/panel-tianma-nt36672a.c -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND PATCH v3 1/2] dt-bindings: display: panel: Add bindings for Tianma nt36672a panel
The nt36672a panel from Tianma is a FHD+ panel with a resolution of
1080x2246 and 6.18 inches size. It is found in some of the Poco F1
phones.
Signed-off-by: Sumit Semwal
Reviewed-by: Rob Herring
---
v2: remove ports node, making port@0 directly under panel@0 node.
v3: updated to replace port@0 to just 'port'.
---
.../display/panel/tianma,nt36672a.yaml| 95 +++
1 file changed, 95 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
b/Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
new file mode 100644
index ..03dc323332a5
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
@@ -0,0 +1,95 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/tianma,nt36672a.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Tianma model NT36672A DSI Panel display driver
+
+maintainers:
+ - Sumit Semwal
+
+description: |
+ The nt36672a panel from Tianma is a FHD+ LCD display panel with a resolution
+ of 1080x2246. It is a video mode DSI panel.
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+const: tianma,nt36672a
+
+ reg:
+description: DSI virtual channel of the peripheral
+
+ reset-gpios:
+description: phandle of gpio for reset line - This should be 8mA, gpio
+ can be configured using mux, pinctrl, pinctrl-names (active high)
+
+ vddio-supply:
+description: phandle of the regulator that provides the supply voltage
+ Power IC supply
+
+ vddpos-supply:
+description: phandle of the positive boost supply regulator
+
+ vddneg-supply:
+description: phandle of the negative boost supply regulator
+
+ pinctrl-names:
+description: Pinctrl for panel active and suspend
+
+ pinctrl-0:
+description: Active pinctrls
+
+ pinctrl-1:
+description: Suspend pinctrls
+
+ port: true
+
+required:
+ - compatible
+ - reg
+ - vddi0-supply
+ - vddpos-supply
+ - vddneg-supply
+ - reset-gpios
+ - pinctrl-names
+ - pinctrl-0
+ - pinctrl-1
+ - port
+
+unevaluatedProperties: false
+
+examples:
+ - |+
+#include
+dsi0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ panel@0 {
+compatible = "tianma,nt36672a";
+reg = <0>;
+vddi0-supply = <_l14a_1p88>;
+vddpos-supply = <>;
+vddneg-supply = <>;
+
+reset-gpios = < 6 GPIO_ACTIVE_HIGH>;
+
+pinctrl-names = "panel_active", "panel_suspend";
+pinctrl-0 = <_dsi_active>;
+pinctrl-1 = <_dsi_suspend>;
+
+#address-cells = <1>;
+#size-cells = <0>;
+port {
+ tianma_nt36672a_in_0: endpoint {
+remote-endpoint = <_out>;
+ };
+};
+ };
+};
+
+...
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND PATCH v3 2/2] drm: panel: Add tianma nt36672a panel driver
Some Poco F1 phones have an LCD panel from Tianma, model nt36672a,
with a resolution of 1080x2246 that operates in DSI video mode.
Add the drm panel driver for it.
During testing, Benni Steini helped us fix
the reset sequence timing (from 10ms to 20ms), to get the bootanimation
to work on Android.
With current AOSP, we need to increase it to 200ms - this seems to be a
safe high value to avoid a white screen occasionally.
Signed-off-by: Sumit Semwal
Cc: Benni Steini
---
v2: increase reset sequence timing to a safe 200ms
---
MAINTAINERS | 7 +
drivers/gpu/drm/panel/Kconfig | 11 +
drivers/gpu/drm/panel/Makefile| 1 +
drivers/gpu/drm/panel/panel-tianma-nt36672a.c | 859 ++
4 files changed, 878 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-tianma-nt36672a.c
diff --git a/MAINTAINERS b/MAINTAINERS
index b4a43a9e7fbc..2d384e51353b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5544,6 +5544,13 @@ T: git git://anongit.freedesktop.org/drm/drm-misc
F: Documentation/devicetree/bindings/display/ste,mcde.txt
F: drivers/gpu/drm/mcde/
+DRM DRIVER FOR TIANMA NT36672A PANELS
+M: Sumit Semwal
+S: Maintained
+T: git git://anongit.freedesktop.org/drm/drm-misc
+F:
Documentation/devicetree/bindings/display/panel/tianma,nt36672a-panel.yaml
+F: drivers/gpu/drm/panel/panel-tianma-nt36672a.c
+
DRM DRIVER FOR TDFX VIDEO CARDS
S: Orphan / Obsolete
F: drivers/gpu/drm/tdfx/
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 39055c1f0e2f..da9d74c1ec91 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -437,6 +437,17 @@ config DRM_PANEL_TPO_TD043MTEA1
Say Y here if you want to enable support for TPO TD043MTEA1 800x480
4.3" panel (found on the OMAP3 Pandora board).
+config DRM_PANEL_TIANMA_FHD_NT36672A
+ tristate "TIANMA NT36672A panel"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y here if you want to enable support for the Tianma NT36672A
+ panel. It is seen mostly in Xiaomi Poco F1 mobile phone.
+ The panel has a 1080x2246 resolution and uses 24 bit RGB per pixel.
+ It provides a MIPI DSI interface to the host.
+
config DRM_PANEL_TPO_TPG110
tristate "TPO TPG 800x400 panel"
depends on OF && SPI && GPIOLIB
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index de74f282c433..303e44eb50fa 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -44,6 +44,7 @@ obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7701) +=
panel-sitronix-st7701.o
obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o
obj-$(CONFIG_DRM_PANEL_SONY_ACX424AKP) += panel-sony-acx424akp.o
obj-$(CONFIG_DRM_PANEL_SONY_ACX565AKM) += panel-sony-acx565akm.o
+obj-$(CONFIG_DRM_PANEL_TIANMA_FHD_NT36672A) += panel-tianma-nt36672a.o
obj-$(CONFIG_DRM_PANEL_TPO_TD028TTEC1) += panel-tpo-td028ttec1.o
obj-$(CONFIG_DRM_PANEL_TPO_TD043MTEA1) += panel-tpo-td043mtea1.o
obj-$(CONFIG_DRM_PANEL_TPO_TPG110) += panel-tpo-tpg110.o
diff --git a/drivers/gpu/drm/panel/panel-tianma-nt36672a.c
b/drivers/gpu/drm/panel/panel-tianma-nt36672a.c
new file mode 100644
index ..07e8461b8893
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-tianma-nt36672a.c
@@ -0,0 +1,859 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2020 Linaro Ltd
+ * Author: Sumit Semwal
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+struct panel_cmd {
+ size_t len;
+ const char *data;
+};
+
+#define _INIT_CMD(...) { \
+ .len = sizeof((char[]){__VA_ARGS__}), \
+ .data = (char[]){__VA_ARGS__} }
+
+static const char * const regulator_names[] = {
+ "vddio",
+ "vddpos",
+ "vddneg",
+};
+
+static unsigned long const regulator_enable_loads[] = {
+ 62000,
+ 10,
+ 10
+};
+
+static unsigned long const regulator_disable_loads[] = {
+ 80,
+ 100,
+ 100
+};
+
+struct panel_desc {
+ const struct drm_display_mode *display_mode;
+ const char *panel_name;
+
+ unsigned int width_mm;
+ unsigned int height_mm;
+
+ unsigned long mode_flags;
+ enum mipi_dsi_pixel_format format;
+ unsigned int lanes;
+
+ const struct panel_cmd *on_cmds_1;
+ const struct panel_cmd *on_cmds_2;
+
+ const struct panel_cmd *off_cmds;
+};
+
+struct panel_info {
+ struct drm_panel base;
+ struct mipi_dsi_device *link;
+ const struct panel_desc *desc;
+
+ struct regulator_bulk_data supplies[ARRAY_SIZE(regulator_names)];
+
+ struct gpio_desc *reset_gpio;
+
+ struct
[PATCH v3 0/2] Add support for Tianma nt36672a video mode panel
Some Poco F1 phones from Xiaomi have an nt36672a video mode panel; add support for the same. Most of the panel data is taken from downstream panel dts, and is converted to drm-panel based driver by me. It has been validated with v5.8-rc5 on Poco F1 phone; my tree with other dependent patches is here [1] [1]: https://git.linaro.org/people/sumit.semwal/linux-dev.git/log/?h=dev/poco-panel-upstreaming --- v2: In dt-binding, removed ports node, making port@0 directly under panel@0 node. Also updated the panel_on delay to a safer 200ms as needed for latest Android. v3: Replaced port@0 with just port in panel@0 node. [1]: Sumit Semwal (2): dt-bindings: display: panel: Add bindings for Tianma nt36672a panel drm: panel: Add tianma nt36672a panel driver .../display/panel/tianma,nt36672a.yaml| 95 ++ MAINTAINERS | 7 + drivers/gpu/drm/panel/Kconfig | 11 + drivers/gpu/drm/panel/Makefile| 1 + drivers/gpu/drm/panel/panel-tianma-nt36672a.c | 859 ++ 5 files changed, 973 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml create mode 100644 drivers/gpu/drm/panel/panel-tianma-nt36672a.c -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/2] drm: panel: Add tianma nt36672a panel driver
Some Poco F1 phones have an LCD panel from Tianma, model nt36672a,
with a resolution of 1080x2246 that operates in DSI video mode.
Add the drm panel driver for it.
During testing, Benni Steini helped us fix
the reset sequence timing (from 10ms to 20ms), to get the bootanimation
to work on Android.
With current AOSP, we need to increase it to 200ms - this seems to be a
safe high value to avoid a white screen occasionally.
Signed-off-by: Sumit Semwal
Cc: Benni Steini
---
v2: increase reset sequence timing to a safe 200ms
---
MAINTAINERS | 7 +
drivers/gpu/drm/panel/Kconfig | 11 +
drivers/gpu/drm/panel/Makefile| 1 +
drivers/gpu/drm/panel/panel-tianma-nt36672a.c | 859 ++
4 files changed, 878 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-tianma-nt36672a.c
diff --git a/MAINTAINERS b/MAINTAINERS
index b4a43a9e7fbc..2d384e51353b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5544,6 +5544,13 @@ T: git git://anongit.freedesktop.org/drm/drm-misc
F: Documentation/devicetree/bindings/display/ste,mcde.txt
F: drivers/gpu/drm/mcde/
+DRM DRIVER FOR TIANMA NT36672A PANELS
+M: Sumit Semwal
+S: Maintained
+T: git git://anongit.freedesktop.org/drm/drm-misc
+F:
Documentation/devicetree/bindings/display/panel/tianma,nt36672a-panel.yaml
+F: drivers/gpu/drm/panel/panel-tianma-nt36672a.c
+
DRM DRIVER FOR TDFX VIDEO CARDS
S: Orphan / Obsolete
F: drivers/gpu/drm/tdfx/
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 39055c1f0e2f..da9d74c1ec91 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -437,6 +437,17 @@ config DRM_PANEL_TPO_TD043MTEA1
Say Y here if you want to enable support for TPO TD043MTEA1 800x480
4.3" panel (found on the OMAP3 Pandora board).
+config DRM_PANEL_TIANMA_FHD_NT36672A
+ tristate "TIANMA NT36672A panel"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y here if you want to enable support for the Tianma NT36672A
+ panel. It is seen mostly in Xiaomi Poco F1 mobile phone.
+ The panel has a 1080x2246 resolution and uses 24 bit RGB per pixel.
+ It provides a MIPI DSI interface to the host.
+
config DRM_PANEL_TPO_TPG110
tristate "TPO TPG 800x400 panel"
depends on OF && SPI && GPIOLIB
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index de74f282c433..303e44eb50fa 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -44,6 +44,7 @@ obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7701) +=
panel-sitronix-st7701.o
obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o
obj-$(CONFIG_DRM_PANEL_SONY_ACX424AKP) += panel-sony-acx424akp.o
obj-$(CONFIG_DRM_PANEL_SONY_ACX565AKM) += panel-sony-acx565akm.o
+obj-$(CONFIG_DRM_PANEL_TIANMA_FHD_NT36672A) += panel-tianma-nt36672a.o
obj-$(CONFIG_DRM_PANEL_TPO_TD028TTEC1) += panel-tpo-td028ttec1.o
obj-$(CONFIG_DRM_PANEL_TPO_TD043MTEA1) += panel-tpo-td043mtea1.o
obj-$(CONFIG_DRM_PANEL_TPO_TPG110) += panel-tpo-tpg110.o
diff --git a/drivers/gpu/drm/panel/panel-tianma-nt36672a.c
b/drivers/gpu/drm/panel/panel-tianma-nt36672a.c
new file mode 100644
index ..07e8461b8893
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-tianma-nt36672a.c
@@ -0,0 +1,859 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2020 Linaro Ltd
+ * Author: Sumit Semwal
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+struct panel_cmd {
+ size_t len;
+ const char *data;
+};
+
+#define _INIT_CMD(...) { \
+ .len = sizeof((char[]){__VA_ARGS__}), \
+ .data = (char[]){__VA_ARGS__} }
+
+static const char * const regulator_names[] = {
+ "vddio",
+ "vddpos",
+ "vddneg",
+};
+
+static unsigned long const regulator_enable_loads[] = {
+ 62000,
+ 10,
+ 10
+};
+
+static unsigned long const regulator_disable_loads[] = {
+ 80,
+ 100,
+ 100
+};
+
+struct panel_desc {
+ const struct drm_display_mode *display_mode;
+ const char *panel_name;
+
+ unsigned int width_mm;
+ unsigned int height_mm;
+
+ unsigned long mode_flags;
+ enum mipi_dsi_pixel_format format;
+ unsigned int lanes;
+
+ const struct panel_cmd *on_cmds_1;
+ const struct panel_cmd *on_cmds_2;
+
+ const struct panel_cmd *off_cmds;
+};
+
+struct panel_info {
+ struct drm_panel base;
+ struct mipi_dsi_device *link;
+ const struct panel_desc *desc;
+
+ struct regulator_bulk_data supplies[ARRAY_SIZE(regulator_names)];
+
+ struct gpio_desc *reset_gpio;
+
+ struct
[PATCH v3 1/2] dt-bindings: display: panel: Add bindings for Tianma nt36672a panel
The nt36672a panel from Tianma is a FHD+ panel with a resolution of
1080x2246 and 6.18 inches size. It is found in some of the Poco F1
phones.
Signed-off-by: Sumit Semwal
---
v2: remove ports node, making port@0 directly under panel@0 node.
v3: updated to replace port@0 to just 'port'.
---
.../display/panel/tianma,nt36672a.yaml| 95 +++
1 file changed, 95 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
b/Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
new file mode 100644
index ..03dc323332a5
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
@@ -0,0 +1,95 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/tianma,nt36672a.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Tianma model NT36672A DSI Panel display driver
+
+maintainers:
+ - Sumit Semwal
+
+description: |
+ The nt36672a panel from Tianma is a FHD+ LCD display panel with a resolution
+ of 1080x2246. It is a video mode DSI panel.
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+const: tianma,nt36672a
+
+ reg:
+description: DSI virtual channel of the peripheral
+
+ reset-gpios:
+description: phandle of gpio for reset line - This should be 8mA, gpio
+ can be configured using mux, pinctrl, pinctrl-names (active high)
+
+ vddio-supply:
+description: phandle of the regulator that provides the supply voltage
+ Power IC supply
+
+ vddpos-supply:
+description: phandle of the positive boost supply regulator
+
+ vddneg-supply:
+description: phandle of the negative boost supply regulator
+
+ pinctrl-names:
+description: Pinctrl for panel active and suspend
+
+ pinctrl-0:
+description: Active pinctrls
+
+ pinctrl-1:
+description: Suspend pinctrls
+
+ port: true
+
+required:
+ - compatible
+ - reg
+ - vddi0-supply
+ - vddpos-supply
+ - vddneg-supply
+ - reset-gpios
+ - pinctrl-names
+ - pinctrl-0
+ - pinctrl-1
+ - port
+
+unevaluatedProperties: false
+
+examples:
+ - |+
+#include
+dsi0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ panel@0 {
+compatible = "tianma,nt36672a";
+reg = <0>;
+vddi0-supply = <_l14a_1p88>;
+vddpos-supply = <>;
+vddneg-supply = <>;
+
+reset-gpios = < 6 GPIO_ACTIVE_HIGH>;
+
+pinctrl-names = "panel_active", "panel_suspend";
+pinctrl-0 = <_dsi_active>;
+pinctrl-1 = <_dsi_suspend>;
+
+#address-cells = <1>;
+#size-cells = <0>;
+port {
+ tianma_nt36672a_in_0: endpoint {
+remote-endpoint = <_out>;
+ };
+};
+ };
+};
+
+...
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/2] dt-bindings: display: panel: Add bindings for Tianma nt36672a panel
Hi Rob,
Thanks for the review!
On Thu, 23 Jul 2020 at 23:25, Rob Herring wrote:
>
> On Wed, Jul 22, 2020 at 11:28:15AM +0530, Sumit Semwal wrote:
> > The nt36672a panel from Tianma is a FHD+ panel with a resolution of
> > 1080x2246
> > and 6.18 inches size. It is found in some of the Poco F1 phones.
> >
> > Signed-off-by: Sumit Semwal
> > Change-Id: I401dfbfe23ff2d806c956002f45e349cb9688c16
>
> You know better...
Yes - Sorry :( - will correct.
>
> > ---
> > v2: remove ports node, making port@0 directly under panel@0 node.
> > ---
> > .../display/panel/tianma,nt36672a.yaml| 104 ++
> > 1 file changed, 104 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
> > b/Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
> > new file mode 100644
> > index ..cb1799fbbd32
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
> > @@ -0,0 +1,104 @@
> > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/display/panel/tianma,nt36672a.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Tianma model NT36672A DSI Panel display driver
> > +
> > +maintainers:
> > + - Sumit Semwal
> > +
> > +description: |
> > + The nt36672a panel from Tianma is a FHD+ LCD display panel with a
> > resolution
> > + of 1080x2246. It is a video mode DSI panel.
> > +
> > +allOf:
> > + - $ref: panel-common.yaml#
> > +
> > +properties:
> > + compatible:
> > +const: tianma,nt36672a
> > +
> > + reg:
> > +description: DSI virtual channel of the peripheral
> > +
> > + reset-gpios:
> > +description: phandle of gpio for reset line - This should be 8mA, gpio
> > + can be configured using mux, pinctrl, pinctrl-names (active high)
> > +
> > + vddio-supply:
> > +description: phandle of the regulator that provides the supply voltage
> > + Power IC supply
> > +
> > + vddpos-supply:
> > +description: phandle of the positive boost supply regulator
> > +
> > + vddneg-supply:
> > +description: phandle of the negative boost supply regulator
> > +
> > + pinctrl-names:
> > +description: Pinctrl for panel active and suspend
> > +
> > + pinctrl-0:
> > +description: Active pinctrls
> > +
> > + pinctrl-1:
> > +description: Suspend pinctrls
> > +
> > + port@0:
>
> Just 'port' as there can only be 1 in this case.
>
> You can do just: 'port: true' as panel-common.yaml already has a
> definition.
Ok, let me try that and send out v3.
>
> > +type: object
> > +description: DSI input port driven by master DSI
> > +properties:
> > + reg:
> > +const: 0
> > +
> > +required:
> > + - reg
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - vddi0-supply
> > + - vddpos-supply
> > + - vddneg-supply
> > + - reset-gpios
> > + - pinctrl-names
> > + - pinctrl-0
> > + - pinctrl-1
> > + - port@0
> > +
> > +unevaluatedProperties: false
> > +
> > +examples:
> > + - |+
> > +#include
> > +dsi0 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + panel@0 {
> > +compatible = "tianma,nt36672a";
> > +reg = <0>;
> > +vddi0-supply = <_l14a_1p88>;
> > +vddpos-supply = <>;
> > +vddneg-supply = <>;
> > +
> > +reset-gpios = < 6 GPIO_ACTIVE_HIGH>;
> > +
> > +pinctrl-names = "panel_active", "panel_suspend";
> > +pinctrl-0 = <_dsi_active>;
> > +pinctrl-1 = <_dsi_suspend>;
> > +
> > +#address-cells = <1>;
> > +#size-cells = <0>;
> > +port@0 {
> > + reg = <0>;
> > + tianma_nt36672a_in_0: endpoint {
> > +remote-endpoint = <_out>;
> > + };
> > +};
> > + };
> > +};
> > +
> > +...
> > --
> > 2.27.0
> >
>
Best,
Sumit.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/2] Add support for Tianma nt36672a video mode panel
Some Poco F1 phones from Xiaomi have an nt36672a video mode panel; add support for the same. Most of the panel data is taken from downstream panel dts, and is converted to drm-panel based driver by me. It has been validated with v5.8-rc5 on Poco F1 phone; my tree with other dependent patches is here [1] --- v2: In dt-binding, removed ports node, making port@0 directly under panel@0 node. Also updated the panel_on delay to a safer 200ms as needed for latest Android. Sumit Semwal (2): dt-bindings: display: panel: Add bindings for Tianma nt36672a panel drm: panel: Add tianma nt36672a panel driver .../display/panel/tianma,nt36672a.yaml| 104 +++ MAINTAINERS | 7 + drivers/gpu/drm/panel/Kconfig | 11 + drivers/gpu/drm/panel/Makefile| 1 + drivers/gpu/drm/panel/panel-tianma-nt36672a.c | 859 ++ 5 files changed, 982 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml create mode 100644 drivers/gpu/drm/panel/panel-tianma-nt36672a.c -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/2] dt-bindings: display: panel: Add bindings for Tianma nt36672a panel
The nt36672a panel from Tianma is a FHD+ panel with a resolution of 1080x2246
and 6.18 inches size. It is found in some of the Poco F1 phones.
Signed-off-by: Sumit Semwal
Change-Id: I401dfbfe23ff2d806c956002f45e349cb9688c16
---
v2: remove ports node, making port@0 directly under panel@0 node.
---
.../display/panel/tianma,nt36672a.yaml| 104 ++
1 file changed, 104 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
b/Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
new file mode 100644
index ..cb1799fbbd32
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
@@ -0,0 +1,104 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/tianma,nt36672a.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Tianma model NT36672A DSI Panel display driver
+
+maintainers:
+ - Sumit Semwal
+
+description: |
+ The nt36672a panel from Tianma is a FHD+ LCD display panel with a resolution
+ of 1080x2246. It is a video mode DSI panel.
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+const: tianma,nt36672a
+
+ reg:
+description: DSI virtual channel of the peripheral
+
+ reset-gpios:
+description: phandle of gpio for reset line - This should be 8mA, gpio
+ can be configured using mux, pinctrl, pinctrl-names (active high)
+
+ vddio-supply:
+description: phandle of the regulator that provides the supply voltage
+ Power IC supply
+
+ vddpos-supply:
+description: phandle of the positive boost supply regulator
+
+ vddneg-supply:
+description: phandle of the negative boost supply regulator
+
+ pinctrl-names:
+description: Pinctrl for panel active and suspend
+
+ pinctrl-0:
+description: Active pinctrls
+
+ pinctrl-1:
+description: Suspend pinctrls
+
+ port@0:
+type: object
+description: DSI input port driven by master DSI
+properties:
+ reg:
+const: 0
+
+required:
+ - reg
+
+required:
+ - compatible
+ - reg
+ - vddi0-supply
+ - vddpos-supply
+ - vddneg-supply
+ - reset-gpios
+ - pinctrl-names
+ - pinctrl-0
+ - pinctrl-1
+ - port@0
+
+unevaluatedProperties: false
+
+examples:
+ - |+
+#include
+dsi0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ panel@0 {
+compatible = "tianma,nt36672a";
+reg = <0>;
+vddi0-supply = <_l14a_1p88>;
+vddpos-supply = <>;
+vddneg-supply = <>;
+
+reset-gpios = < 6 GPIO_ACTIVE_HIGH>;
+
+pinctrl-names = "panel_active", "panel_suspend";
+pinctrl-0 = <_dsi_active>;
+pinctrl-1 = <_dsi_suspend>;
+
+#address-cells = <1>;
+#size-cells = <0>;
+port@0 {
+ reg = <0>;
+ tianma_nt36672a_in_0: endpoint {
+remote-endpoint = <_out>;
+ };
+};
+ };
+};
+
+...
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/2] drm: panel: Add tianma nt36672a panel driver
Some Poco F1 phones have an LCD panel from Tianma, model nt36672a,
with a resolution of 1080x2246 that operates in DSI video mode.
Add the drm panel driver for it.
During testing, Benni Steini helped us fix
the reset sequence timing (from 10ms to 20ms), to get the bootanimation
to work on Android.
With current AOSP, we need to increase it to 200ms - this seems to be a safe
high value to avoid a white screen occassionally.
Signed-off-by: Sumit Semwal
Cc: Benni Steini
Change-Id: Ib822ef12464abcb50d2e539d11b8983be87c31f2
---
v2: increase reset sequence timing to a safe 200ms
---
MAINTAINERS | 7 +
drivers/gpu/drm/panel/Kconfig | 11 +
drivers/gpu/drm/panel/Makefile| 1 +
drivers/gpu/drm/panel/panel-tianma-nt36672a.c | 859 ++
4 files changed, 878 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-tianma-nt36672a.c
diff --git a/MAINTAINERS b/MAINTAINERS
index b4a43a9e7fbc..2d384e51353b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5544,6 +5544,13 @@ T: git git://anongit.freedesktop.org/drm/drm-misc
F: Documentation/devicetree/bindings/display/ste,mcde.txt
F: drivers/gpu/drm/mcde/
+DRM DRIVER FOR TIANMA NT36672A PANELS
+M: Sumit Semwal
+S: Maintained
+T: git git://anongit.freedesktop.org/drm/drm-misc
+F:
Documentation/devicetree/bindings/display/panel/tianma,nt36672a-panel.yaml
+F: drivers/gpu/drm/panel/panel-tianma-nt36672a.c
+
DRM DRIVER FOR TDFX VIDEO CARDS
S: Orphan / Obsolete
F: drivers/gpu/drm/tdfx/
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 39055c1f0e2f..da9d74c1ec91 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -437,6 +437,17 @@ config DRM_PANEL_TPO_TD043MTEA1
Say Y here if you want to enable support for TPO TD043MTEA1 800x480
4.3" panel (found on the OMAP3 Pandora board).
+config DRM_PANEL_TIANMA_FHD_NT36672A
+ tristate "TIANMA NT36672A panel"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y here if you want to enable support for the Tianma NT36672A
+ panel. It is seen mostly in Xiaomi Poco F1 mobile phone.
+ The panel has a 1080x2246 resolution and uses 24 bit RGB per pixel.
+ It provides a MIPI DSI interface to the host.
+
config DRM_PANEL_TPO_TPG110
tristate "TPO TPG 800x400 panel"
depends on OF && SPI && GPIOLIB
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index de74f282c433..303e44eb50fa 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -44,6 +44,7 @@ obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7701) +=
panel-sitronix-st7701.o
obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o
obj-$(CONFIG_DRM_PANEL_SONY_ACX424AKP) += panel-sony-acx424akp.o
obj-$(CONFIG_DRM_PANEL_SONY_ACX565AKM) += panel-sony-acx565akm.o
+obj-$(CONFIG_DRM_PANEL_TIANMA_FHD_NT36672A) += panel-tianma-nt36672a.o
obj-$(CONFIG_DRM_PANEL_TPO_TD028TTEC1) += panel-tpo-td028ttec1.o
obj-$(CONFIG_DRM_PANEL_TPO_TD043MTEA1) += panel-tpo-td043mtea1.o
obj-$(CONFIG_DRM_PANEL_TPO_TPG110) += panel-tpo-tpg110.o
diff --git a/drivers/gpu/drm/panel/panel-tianma-nt36672a.c
b/drivers/gpu/drm/panel/panel-tianma-nt36672a.c
new file mode 100644
index ..0af3a6ff5d55
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-tianma-nt36672a.c
@@ -0,0 +1,859 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2020 Linaro Ltd
+ * Author: Sumit Semwal
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+struct panel_cmd {
+ size_t len;
+ const char *data;
+};
+
+#define _INIT_CMD(...) { \
+ .len = sizeof((char[]){__VA_ARGS__}), \
+ .data = (char[]){__VA_ARGS__} }
+
+static const char * const regulator_names[] = {
+ "vddio",
+ "vddpos",
+ "vddneg",
+};
+
+static unsigned long const regulator_enable_loads[] = {
+ 62000,
+ 10,
+ 10
+};
+
+static unsigned long const regulator_disable_loads[] = {
+ 80,
+ 100,
+ 100
+};
+
+struct panel_desc {
+ const struct drm_display_mode *display_mode;
+ const char *panel_name;
+
+ unsigned int width_mm;
+ unsigned int height_mm;
+
+ unsigned long mode_flags;
+ enum mipi_dsi_pixel_format format;
+ unsigned int lanes;
+
+ const struct panel_cmd *on_cmds_1;
+ const struct panel_cmd *on_cmds_2;
+
+ const struct panel_cmd *off_cmds;
+};
+
+struct panel_info {
+ struct drm_panel base;
+ struct mipi_dsi_device *link;
+ const struct panel_desc *desc;
+
+ struct regulator_bulk_data supplies[ARRAY_SIZE(regulator_names)];
+
Re: [PATCH 1/2] dt-bindings: display: panel: Add bindings for Tianma nt36672a panel
Hello Rob,
Thanks for the review!
On Tue, 21 Jul 2020 at 09:03, Rob Herring wrote:
>
> On Thu, Jul 16, 2020 at 09:08:57PM +0530, Sumit Semwal wrote:
> > The nt36672a panel from Tianma is a FHD+ panel with a resolution of
> > 1080x2246
> > and 6.18 inches size. It is found in some of the Poco F1 phones.
> >
> > Signed-off-by: Sumit Semwal
> > ---
> > .../display/panel/tianma,nt36672a.yaml| 110 ++
> > 1 file changed, 110 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
> > b/Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
> > new file mode 100644
> > index ..3c583ca926ee
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
> > @@ -0,0 +1,110 @@
> > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/display/panel/tianma,nt36672a.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Tianma model NT36672A DSI Panel display driver
> > +
> > +maintainers:
> > + - Sumit Semwal
> > +
> > +description: |
> > + The nt36672a panel from Tianma is a FHD+ LCD display panel with a
> > resolution
> > + of 1080x2246. It is a video mode DSI panel.
> > +
> > +allOf:
> > + - $ref: panel-common.yaml#
> > +
> > +properties:
> > + compatible:
> > +const: tianma,nt36672a
> > +
> > + reg:
> > +description: DSI virtual channel of the peripheral
> > +
> > + reset-gpios:
> > +description: phandle of gpio for reset line - This should be 8mA, gpio
> > + can be configured using mux, pinctrl, pinctrl-names (active high)
> > +
> > + vddio-supply:
> > +description: phandle of the regulator that provides the supply voltage
> > + Power IC supply
> > +
> > + vddpos-supply:
> > +description: phandle of the positive boost supply regulator
> > +
> > + vddneg-supply:
> > +description: phandle of the negative boost supply regulator
> > +
> > + pinctrl-names:
> > +description: Pinctrl for panel active and suspend
> > +
> > + pinctrl-0:
> > +description: Active pinctrls
> > +
> > + pinctrl-1:
> > +description: Suspend pinctrls
>
> I think the pinctrl should go in the DSI controller node, not the
> display unless it is settings for 'reset-gpios'.
Yes, from the downstream code, this seems to be for reset-gpios.
>
> > +
> > + ports:
> > +type: object
> > +properties:
> > + port@0:
> > +type: object
> > +description: DSI input port driven by master DSI
> > +properties:
> > + reg:
> > +const: 0
> > +
> > +required:
> > + - reg
>
> For a single port, you can do just 'port' (without ports node).
Thanks; will update in next version.
>
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - vddi0-supply
> > + - vddpos-supply
> > + - vddneg-supply
> > + - reset-gpios
> > + - pinctrl-names
> > + - pinctrl-0
> > + - pinctrl-1
> > + - ports
> > +
> > +unevaluatedProperties: false
> > +
> > +examples:
> > + - |+
> > +#include
> > +dsi0 {
>
> dsi {
>
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + panel@0 {
> > +compatible = "tianma,nt36672a";
> > +reg = <0>;
> > +vddi0-supply = <_l14a_1p88>;
> > +vddpos-supply = <>;
> > +vddneg-supply = <>;
> > +
> > +reset-gpios = < 6 GPIO_ACTIVE_HIGH>;
> > +
> > +pinctrl-names = "panel_active", "panel_suspend";
> > +pinctrl-0 = <_dsi_active>;
> > +pinctrl-1 = <_dsi_suspend>;
> > +
> > +ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + port@0 {
> > +reg = <0>;
> > +tianma_nt36672a_in_0: endpoint {
> > + remote-endpoint = <_out>;
> > +};
> > + };
> > +};
> > + };
> > +};
> > +
> > +...
> > --
> > 2.27.0
> >
Best,
Sumit.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] dt-bindings: display: panel: Add bindings for Tianma nt36672a panel
The nt36672a panel from Tianma is a FHD+ panel with a resolution of 1080x2246
and 6.18 inches size. It is found in some of the Poco F1 phones.
Signed-off-by: Sumit Semwal
---
.../display/panel/tianma,nt36672a.yaml| 110 ++
1 file changed, 110 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
b/Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
new file mode 100644
index ..3c583ca926ee
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
@@ -0,0 +1,110 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/tianma,nt36672a.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Tianma model NT36672A DSI Panel display driver
+
+maintainers:
+ - Sumit Semwal
+
+description: |
+ The nt36672a panel from Tianma is a FHD+ LCD display panel with a resolution
+ of 1080x2246. It is a video mode DSI panel.
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+const: tianma,nt36672a
+
+ reg:
+description: DSI virtual channel of the peripheral
+
+ reset-gpios:
+description: phandle of gpio for reset line - This should be 8mA, gpio
+ can be configured using mux, pinctrl, pinctrl-names (active high)
+
+ vddio-supply:
+description: phandle of the regulator that provides the supply voltage
+ Power IC supply
+
+ vddpos-supply:
+description: phandle of the positive boost supply regulator
+
+ vddneg-supply:
+description: phandle of the negative boost supply regulator
+
+ pinctrl-names:
+description: Pinctrl for panel active and suspend
+
+ pinctrl-0:
+description: Active pinctrls
+
+ pinctrl-1:
+description: Suspend pinctrls
+
+ ports:
+type: object
+properties:
+ port@0:
+type: object
+description: DSI input port driven by master DSI
+properties:
+ reg:
+const: 0
+
+required:
+ - reg
+
+required:
+ - compatible
+ - reg
+ - vddi0-supply
+ - vddpos-supply
+ - vddneg-supply
+ - reset-gpios
+ - pinctrl-names
+ - pinctrl-0
+ - pinctrl-1
+ - ports
+
+unevaluatedProperties: false
+
+examples:
+ - |+
+#include
+dsi0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ panel@0 {
+compatible = "tianma,nt36672a";
+reg = <0>;
+vddi0-supply = <_l14a_1p88>;
+vddpos-supply = <>;
+vddneg-supply = <>;
+
+reset-gpios = < 6 GPIO_ACTIVE_HIGH>;
+
+pinctrl-names = "panel_active", "panel_suspend";
+pinctrl-0 = <_dsi_active>;
+pinctrl-1 = <_dsi_suspend>;
+
+ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+reg = <0>;
+tianma_nt36672a_in_0: endpoint {
+ remote-endpoint = <_out>;
+};
+ };
+};
+ };
+};
+
+...
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/2] Add support for Tianma nt36672a video mode panel
Some Poco F1 phones from Xiaomi have an nt36672a video mode panel; add support for the same. Most of the panel data is taken from downstream panel dts, and is converted to drm-panel based driver by me. It has been validated with v5.8-rc5 on Poco F1 phone; my tree with other dependent patches is here [1] [1]: https://git.linaro.org/people/sumit.semwal/linux-dev.git/log/?h=dev/poco-panel-upstreaming Sumit Semwal (2): dt-bindings: display: panel: Add bindings for Tianma nt36672a panel drm: panel: Add tianma nt36672a panel driver .../display/panel/tianma,nt36672a.yaml| 110 +++ MAINTAINERS | 7 + drivers/gpu/drm/panel/Kconfig | 11 + drivers/gpu/drm/panel/Makefile| 1 + drivers/gpu/drm/panel/panel-tianma-nt36672a.c | 859 ++ 5 files changed, 988 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml create mode 100644 drivers/gpu/drm/panel/panel-tianma-nt36672a.c -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm: panel: Add tianma nt36672a panel driver
Some Poco F1 phones have an LCD panel from Tianma, model nt36672a,
with a resolution of 1080x2246 that operates in DSI video mode.
Add the drm panel driver for it.
During testing, Benni Steini helped us fix
the reset sequence timing (from 10ms to 20ms), to get the bootanimation
to work on Android.
Cc: Benni Steini
Signed-off-by: Sumit Semwal
---
MAINTAINERS | 7 +
drivers/gpu/drm/panel/Kconfig | 11 +
drivers/gpu/drm/panel/Makefile| 1 +
drivers/gpu/drm/panel/panel-tianma-nt36672a.c | 859 ++
4 files changed, 878 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-tianma-nt36672a.c
diff --git a/MAINTAINERS b/MAINTAINERS
index b4a43a9e7fbc..2d384e51353b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5544,6 +5544,13 @@ T: git git://anongit.freedesktop.org/drm/drm-misc
F: Documentation/devicetree/bindings/display/ste,mcde.txt
F: drivers/gpu/drm/mcde/
+DRM DRIVER FOR TIANMA NT36672A PANELS
+M: Sumit Semwal
+S: Maintained
+T: git git://anongit.freedesktop.org/drm/drm-misc
+F:
Documentation/devicetree/bindings/display/panel/tianma,nt36672a-panel.yaml
+F: drivers/gpu/drm/panel/panel-tianma-nt36672a.c
+
DRM DRIVER FOR TDFX VIDEO CARDS
S: Orphan / Obsolete
F: drivers/gpu/drm/tdfx/
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 39055c1f0e2f..da9d74c1ec91 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -437,6 +437,17 @@ config DRM_PANEL_TPO_TD043MTEA1
Say Y here if you want to enable support for TPO TD043MTEA1 800x480
4.3" panel (found on the OMAP3 Pandora board).
+config DRM_PANEL_TIANMA_FHD_NT36672A
+ tristate "TIANMA NT36672A panel"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y here if you want to enable support for the Tianma NT36672A
+ panel. It is seen mostly in Xiaomi Poco F1 mobile phone.
+ The panel has a 1080x2246 resolution and uses 24 bit RGB per pixel.
+ It provides a MIPI DSI interface to the host.
+
config DRM_PANEL_TPO_TPG110
tristate "TPO TPG 800x400 panel"
depends on OF && SPI && GPIOLIB
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index de74f282c433..303e44eb50fa 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -44,6 +44,7 @@ obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7701) +=
panel-sitronix-st7701.o
obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o
obj-$(CONFIG_DRM_PANEL_SONY_ACX424AKP) += panel-sony-acx424akp.o
obj-$(CONFIG_DRM_PANEL_SONY_ACX565AKM) += panel-sony-acx565akm.o
+obj-$(CONFIG_DRM_PANEL_TIANMA_FHD_NT36672A) += panel-tianma-nt36672a.o
obj-$(CONFIG_DRM_PANEL_TPO_TD028TTEC1) += panel-tpo-td028ttec1.o
obj-$(CONFIG_DRM_PANEL_TPO_TD043MTEA1) += panel-tpo-td043mtea1.o
obj-$(CONFIG_DRM_PANEL_TPO_TPG110) += panel-tpo-tpg110.o
diff --git a/drivers/gpu/drm/panel/panel-tianma-nt36672a.c
b/drivers/gpu/drm/panel/panel-tianma-nt36672a.c
new file mode 100644
index ..166773612ad2
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-tianma-nt36672a.c
@@ -0,0 +1,859 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2020 Linaro Ltd
+ * Author: Sumit Semwal
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+struct panel_cmd {
+ size_t len;
+ const char *data;
+};
+
+#define _INIT_CMD(...) { \
+ .len = sizeof((char[]){__VA_ARGS__}), \
+ .data = (char[]){__VA_ARGS__} }
+
+static const char * const regulator_names[] = {
+ "vddio",
+ "vddpos",
+ "vddneg",
+};
+
+static unsigned long const regulator_enable_loads[] = {
+ 62000,
+ 10,
+ 10
+};
+
+static unsigned long const regulator_disable_loads[] = {
+ 80,
+ 100,
+ 100
+};
+
+struct panel_desc {
+ const struct drm_display_mode *display_mode;
+ const char *panel_name;
+
+ unsigned int width_mm;
+ unsigned int height_mm;
+
+ unsigned long mode_flags;
+ enum mipi_dsi_pixel_format format;
+ unsigned int lanes;
+
+ const struct panel_cmd *on_cmds_1;
+ const struct panel_cmd *on_cmds_2;
+
+ const struct panel_cmd *off_cmds;
+};
+
+struct panel_info {
+ struct drm_panel base;
+ struct mipi_dsi_device *link;
+ const struct panel_desc *desc;
+
+ struct regulator_bulk_data supplies[ARRAY_SIZE(regulator_names)];
+
+ struct gpio_desc *reset_gpio;
+
+ struct pinctrl *pinctrl;
+ struct pinctrl_state *active;
+ struct pinctrl_state *suspend;
+
+
+ bool prepared;
+ bool enabled;
+};
+
+static inline struct panel_info
Re: [PATCH] MAINTAINERS: Add myself as DMA-buf maintainer
Thanks for all the good work here, Christian! On Wed, 1 Jul 2020 at 17:20, Daniel Vetter wrote: > > On Wed, Jul 1, 2020 at 1:26 PM Christian König > wrote: > > > > As discussed on the list. > > > > Signed-off-by: Christian König > > Acked-by: Daniel Vetter Acked-by: Sumit Semwal > > --- > > MAINTAINERS | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index 40474982a21d..5d7130f8d342 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -5089,6 +5089,7 @@ F:fs/dlm/ > > > > DMA BUFFER SHARING FRAMEWORK > > M: Sumit Semwal > > +M: Christian König > > L: linux-me...@vger.kernel.org > > L: dri-devel@lists.freedesktop.org > > L: linaro-mm-...@lists.linaro.org (moderated for non-subscribers) > > -- > > 2.20.1 > > > > ___ > > dri-devel mailing list > > dri-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch Best, Sumit ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] MAINTAINERS: Add myself as DMA-buf maintainer
Thanks for all the good work here, Christian! On Wed, 1 Jul 2020, 17:20 Daniel Vetter, wrote: > On Wed, Jul 1, 2020 at 1:26 PM Christian König > wrote: > > > > As discussed on the list. > > > > Signed-off-by: Christian König > > Acked-by: Daniel Vetter > Acked-by: Sumit Semwal > --- > > MAINTAINERS | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index 40474982a21d..5d7130f8d342 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -5089,6 +5089,7 @@ F:fs/dlm/ > > > > DMA BUFFER SHARING FRAMEWORK > > M: Sumit Semwal > > +M: Christian König > > L: linux-me...@vger.kernel.org > > L: dri-devel@lists.freedesktop.org > > L: linaro-mm-...@lists.linaro.org (moderated for non-subscribers) > > -- > > 2.20.1 > > > Best, Sumit. > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 1/2] Revert "dma-buf: Report signaled links inside dma-fence-chain"
Hi Christian, On Fri, 26 Jun 2020, 18:10 Daniel Vetter, wrote: > On Fri, Jun 26, 2020 at 9:03 AM Christian König > wrote: > > > > Am 26.06.20 um 06:43 schrieb Sumit Semwal: > > > On Fri, 26 Jun 2020 at 01:24, Daniel Vetter wrote: > > >> Ignoring everything else ... > > >> > > >> On Thu, Jun 25, 2020 at 9:28 PM Jani Nikula < > jani.nik...@linux.intel.com> wrote: > > >>> As a side note, there seem to be extra checks in place for acks when > > >>> applying non-i915 patches to drm-intel; there are no such checks for > > >>> drm-misc. > > >> One option to generalize that that I pondered is to consult > > >> get_maintainers.pl asking for git repo link, and if that returns > > >> something else, then insist that there's an ack from a relevant > > >> maintainer. It's a bit of typing, but I think the bigger problem is > > >> that there's a ton of false positives. > > > Right; for the particular patch, I wasn't even in the to: or cc: field > > > and that made it slip from my radar. I would definitely ask any one > > > sending patches for dma-buf directory to follow the get_maintainers.pl > > > religiously. > > >> But maybe that's a good thing, would give some motivation to keep > > >> MAINTAINERS updated. > > > > Should I maybe add myself as maintainer as well? I've written enough > > stuff in there to know the code quite a bit. > > I think that makes lots of sense, since defacto you already are :-) > > If you feel like bikeshed, get_maintainers.pl also supports R: for > reviewer, but given that you also push patches to drm-misc M: for > maintainer feels more accurate. > I think given you've been reviewing and changing most of the code around dma-fences, it should be ok to add you as the maintainer for those bits? -Daniel > Best, Sumit. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 1/2] Revert "dma-buf: Report signaled links inside dma-fence-chain"
On Fri, 26 Jun 2020 at 01:24, Daniel Vetter wrote: > > Ignoring everything else ... > > On Thu, Jun 25, 2020 at 9:28 PM Jani Nikula > wrote: > > As a side note, there seem to be extra checks in place for acks when > > applying non-i915 patches to drm-intel; there are no such checks for > > drm-misc. > > One option to generalize that that I pondered is to consult > get_maintainers.pl asking for git repo link, and if that returns > something else, then insist that there's an ack from a relevant > maintainer. It's a bit of typing, but I think the bigger problem is > that there's a ton of false positives. Right; for the particular patch, I wasn't even in the to: or cc: field and that made it slip from my radar. I would definitely ask any one sending patches for dma-buf directory to follow the get_maintainers.pl religiously. > > But maybe that's a good thing, would give some motivation to keep > MAINTAINERS updated. > > The other issue is though that drm-misc is plenty used to merge > patches even when the respective maintainers are absent for weeks, or > unresponsive. If we just blindly implement that rule, then the only > possible Ack for these would be Dave as subsystem maintainers, and > I don't want to be in the business of stamping approvals for all this > stuff. Much better if people just collaborate. > > So I think an ack check would be nice, but probably not practical. > > Plus in this situation here drm-misc.git actually is the main repo, > and we wont ever be able to teach a script to make a judgement call of > whether that patch has the right amount of review on it. > -Daniel Best, Sumit. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] dma-buf: Move dma_buf_release() from fops to dentry_ops
Hello Charan,
On Tue, 16 Jun 2020 at 19:13, Charan Teja Kalla wrote:
>
> Thanks Sumit for the fix.
>
> On 6/11/2020 5:14 PM, Sumit Semwal wrote:
> > Charan Teja reported a 'use-after-free' in dmabuffs_dname [1], which
> > happens if the dma_buf_release() is called while the userspace is
> > accessing the dma_buf pseudo fs's dmabuffs_dname() in another process,
> > and dma_buf_release() releases the dmabuf object when the last reference
> > to the struct file goes away.
> >
> > I discussed with Arnd Bergmann, and he suggested that rather than tying
> > the dma_buf_release() to the file_operations' release(), we can tie it to
> > the dentry_operations' d_release(), which will be called when the last ref
> > to the dentry is removed.
> >
> > The path exercised by __fput() calls f_op->release() first, and then calls
> > dput, which eventually calls d_op->d_release().
> >
> > In the 'normal' case, when no userspace access is happening via dma_buf
> > pseudo fs, there should be exactly one fd, file, dentry and inode, so
> > closing the fd will kill of everything right away.
> >
> > In the presented case, the dentry's d_release() will be called only when
> > the dentry's last ref is released.
> >
> > Therefore, lets move dma_buf_release() from fops->release() to
> > d_ops->d_release()
> >
> > Many thanks to Arnd for his FS insights :)
> >
> > [1]: https://lore.kernel.org/patchwork/patch/1238278/
> >
> > Fixes: bb2bb9030425 ("dma-buf: add DMA_BUF_SET_NAME ioctls")
> > Reported-by: syzbot+3643a18836bce555b...@syzkaller.appspotmail.com
> > Cc: [5.3+]
> > Cc: Arnd Bergmann
> > Reported-by: Charan Teja Reddy
> > Reviewed-by: Arnd Bergmann
> > Signed-off-by: Sumit Semwal
> >
>
> Tested this patch for Android running on Snapdragon hardware and see no
> issues.
> Tested-by: Charan Teja Reddy
Thanks for your tested-by, appreciate it!
Chris,
any luck with your CI to test if this also helps your
dma_buf_release() bug that you guys have seen?
If you've not been able to test, and there are no more objections by
EOD today, I will merge this to the drm-misc-fixes branch.
>
> > ---
> > v2: per Arnd: Moved dma_buf_release() above to avoid forward declaration;
> > removed dentry_ops check.
> > ---
Best,
Sumit.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] dma-buf: Move dma_buf_release() from fops to dentry_ops
Hi Chris, On Tue, 16 Jun 2020 at 18:20, Chris Wilson wrote: > > Quoting Sumit Semwal (2020-06-16 13:42:13) > > Hello, > > > > If there are no objections to this, I will plan to merge it soon. > > I was going to suggest running it against our CI, but that's unavailable > at the moment. > > There's a particularly nasty BUG_ON() in dma_buf_release that we hit > irregularly, that this might help with. Thanks for your reply; if the CI is going to be available in a couple of days, we could wait - it'd be definitely good to see a bug being splattered out! > -Chris Best, Sumit. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] dma-buf: Move dma_buf_release() from fops to dentry_ops
Hello,
If there are no objections to this, I will plan to merge it soon.
Daniel, Chris, Chenbo?
On Thu, 11 Jun 2020 at 17:14, Sumit Semwal wrote:
>
> Charan Teja reported a 'use-after-free' in dmabuffs_dname [1], which
> happens if the dma_buf_release() is called while the userspace is
> accessing the dma_buf pseudo fs's dmabuffs_dname() in another process,
> and dma_buf_release() releases the dmabuf object when the last reference
> to the struct file goes away.
>
> I discussed with Arnd Bergmann, and he suggested that rather than tying
> the dma_buf_release() to the file_operations' release(), we can tie it to
> the dentry_operations' d_release(), which will be called when the last ref
> to the dentry is removed.
>
> The path exercised by __fput() calls f_op->release() first, and then calls
> dput, which eventually calls d_op->d_release().
>
> In the 'normal' case, when no userspace access is happening via dma_buf
> pseudo fs, there should be exactly one fd, file, dentry and inode, so
> closing the fd will kill of everything right away.
>
> In the presented case, the dentry's d_release() will be called only when
> the dentry's last ref is released.
>
> Therefore, lets move dma_buf_release() from fops->release() to
> d_ops->d_release()
>
> Many thanks to Arnd for his FS insights :)
>
> [1]: https://lore.kernel.org/patchwork/patch/1238278/
>
> Fixes: bb2bb9030425 ("dma-buf: add DMA_BUF_SET_NAME ioctls")
> Reported-by: syzbot+3643a18836bce555b...@syzkaller.appspotmail.com
> Cc: [5.3+]
> Cc: Arnd Bergmann
> Reported-by: Charan Teja Reddy
> Reviewed-by: Arnd Bergmann
> Signed-off-by: Sumit Semwal
>
> ---
> v2: per Arnd: Moved dma_buf_release() above to avoid forward declaration;
> removed dentry_ops check.
> ---
> drivers/dma-buf/dma-buf.c | 54 ++-
> 1 file changed, 25 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 01ce125f8e8d..412629601ad3 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -54,37 +54,11 @@ static char *dmabuffs_dname(struct dentry *dentry, char
> *buffer, int buflen)
> dentry->d_name.name, ret > 0 ? name : "");
> }
>
> -static const struct dentry_operations dma_buf_dentry_ops = {
> - .d_dname = dmabuffs_dname,
> -};
> -
> -static struct vfsmount *dma_buf_mnt;
> -
> -static int dma_buf_fs_init_context(struct fs_context *fc)
> -{
> - struct pseudo_fs_context *ctx;
> -
> - ctx = init_pseudo(fc, DMA_BUF_MAGIC);
> - if (!ctx)
> - return -ENOMEM;
> - ctx->dops = _buf_dentry_ops;
> - return 0;
> -}
> -
> -static struct file_system_type dma_buf_fs_type = {
> - .name = "dmabuf",
> - .init_fs_context = dma_buf_fs_init_context,
> - .kill_sb = kill_anon_super,
> -};
> -
> -static int dma_buf_release(struct inode *inode, struct file *file)
> +static void dma_buf_release(struct dentry *dentry)
> {
> struct dma_buf *dmabuf;
>
> - if (!is_dma_buf_file(file))
> - return -EINVAL;
> -
> - dmabuf = file->private_data;
> + dmabuf = dentry->d_fsdata;
>
> BUG_ON(dmabuf->vmapping_counter);
>
> @@ -110,9 +84,32 @@ static int dma_buf_release(struct inode *inode, struct
> file *file)
> module_put(dmabuf->owner);
> kfree(dmabuf->name);
> kfree(dmabuf);
> +}
> +
> +static const struct dentry_operations dma_buf_dentry_ops = {
> + .d_dname = dmabuffs_dname,
> + .d_release = dma_buf_release,
> +};
> +
> +static struct vfsmount *dma_buf_mnt;
> +
> +static int dma_buf_fs_init_context(struct fs_context *fc)
> +{
> + struct pseudo_fs_context *ctx;
> +
> + ctx = init_pseudo(fc, DMA_BUF_MAGIC);
> + if (!ctx)
> + return -ENOMEM;
> + ctx->dops = _buf_dentry_ops;
> return 0;
> }
>
> +static struct file_system_type dma_buf_fs_type = {
> + .name = "dmabuf",
> + .init_fs_context = dma_buf_fs_init_context,
> + .kill_sb = kill_anon_super,
> +};
> +
> static int dma_buf_mmap_internal(struct file *file, struct vm_area_struct
> *vma)
> {
> struct dma_buf *dmabuf;
> @@ -412,7 +409,6 @@ static void dma_buf_show_fdinfo(struct seq_file *m,
> struct file *file)
> }
>
> static const struct file_operations dma_buf_fops = {
> - .release= dma_buf_release,
> .mmap = dma_buf_mmap_internal,
> .llseek = dma_buf_llseek,
> .poll = dma_buf_poll,
> --
> 2.27.0
>
Best,
Sumit.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dmabuf: use spinlock to access dmabuf->name
Hi Daniel, Chris,
On Thu, 11 Jun 2020 at 19:10, Charan Teja Kalla wrote:
>
> There exists a sleep-while-atomic bug while accessing the dmabuf->name
> under mutex in the dmabuffs_dname(). This is caused from the SELinux
> permissions checks on a process where it tries to validate the inherited
> files from fork() by traversing them through iterate_fd() (which
> traverse files under spin_lock) and call
> match_file(security/selinux/hooks.c) where the permission checks happen.
> This audit information is logged using dump_common_audit_data() where it
> calls d_path() to get the file path name. If the file check happen on
> the dmabuf's fd, then it ends up in ->dmabuffs_dname() and use mutex to
> access dmabuf->name. The flow will be like below:
> flush_unauthorized_files()
> iterate_fd()
> spin_lock() --> Start of the atomic section.
> match_file()
> file_has_perm()
> avc_has_perm()
> avc_audit()
> slow_avc_audit()
> common_lsm_audit()
> dump_common_audit_data()
> audit_log_d_path()
> d_path()
> dmabuffs_dname()
> mutex_lock()--> Sleep while atomic.
>
> Call trace captured (on 4.19 kernels) is below:
> ___might_sleep+0x204/0x208
> __might_sleep+0x50/0x88
> __mutex_lock_common+0x5c/0x1068
> __mutex_lock_common+0x5c/0x1068
> mutex_lock_nested+0x40/0x50
> dmabuffs_dname+0xa0/0x170
> d_path+0x84/0x290
> audit_log_d_path+0x74/0x130
> common_lsm_audit+0x334/0x6e8
> slow_avc_audit+0xb8/0xf8
> avc_has_perm+0x154/0x218
> file_has_perm+0x70/0x180
> match_file+0x60/0x78
> iterate_fd+0x128/0x168
> selinux_bprm_committing_creds+0x178/0x248
> security_bprm_committing_creds+0x30/0x48
> install_exec_creds+0x1c/0x68
> load_elf_binary+0x3a4/0x14e0
> search_binary_handler+0xb0/0x1e0
>
> So, use spinlock to access dmabuf->name to avoid sleep-while-atomic.
Any objections to this change? This changes protection only for
dmabuf->name field, but I'd request either of you to review it,
please?
>
> Cc: [5.3+]
> Signed-off-by: Charan Teja Reddy
> ---
> drivers/dma-buf/dma-buf.c | 13 +++--
> include/linux/dma-buf.h | 1 +
> 2 files changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 01ce125..2e0456c 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -45,10 +45,10 @@ static char *dmabuffs_dname(struct dentry *dentry, char
> *buffer, int buflen)
> size_t ret = 0;
>
> dmabuf = dentry->d_fsdata;
> - dma_resv_lock(dmabuf->resv, NULL);
> + spin_lock(>name_lock);
> if (dmabuf->name)
> ret = strlcpy(name, dmabuf->name, DMA_BUF_NAME_LEN);
> - dma_resv_unlock(dmabuf->resv);
> + spin_unlock(>name_lock);
>
> return dynamic_dname(dentry, buffer, buflen, "/%s:%s",
> dentry->d_name.name, ret > 0 ? name : "");
> @@ -335,7 +335,7 @@ static long dma_buf_set_name(struct dma_buf *dmabuf,
> const char __user *buf)
> if (IS_ERR(name))
> return PTR_ERR(name);
>
> - dma_resv_lock(dmabuf->resv, NULL);
> + spin_lock(>name_lock);
> if (!list_empty(>attachments)) {
> ret = -EBUSY;
> kfree(name);
> @@ -345,7 +345,7 @@ static long dma_buf_set_name(struct dma_buf *dmabuf,
> const char __user *buf)
> dmabuf->name = name;
>
> out_unlock:
> - dma_resv_unlock(dmabuf->resv);
> + spin_unlock(>name_lock);
> return ret;
> }
>
> @@ -405,10 +405,10 @@ static void dma_buf_show_fdinfo(struct seq_file *m,
> struct file *file)
> /* Don't count the temporary reference taken inside procfs seq_show */
> seq_printf(m, "count:\t%ld\n", file_count(dmabuf->file) - 1);
> seq_printf(m, "exp_name:\t%s\n", dmabuf->exp_name);
> - dma_resv_lock(dmabuf->resv, NULL);
> + spin_lock(>name_lock);
> if (dmabuf->name)
> seq_printf(m, "name:\t%s\n", dmabuf->name);
> - dma_resv_unlock(dmabuf->resv);
> + spin_unlock(>name_lock);
> }
>
> static const struct file_operations dma_buf_fops = {
> @@ -546,6 +546,7 @@ struct dma_buf *dma_buf_export(const struct
> dma_buf_export_info *exp_info)
> dmabuf->size = exp_info->size;
> dmabuf->exp_name = exp_info->exp_name;
> dmabuf->owner = exp_info->owner;
> + spin_lock_init(>name_lock);
> init_waitqueue_head(>poll);
> dmabuf->cb_excl.poll = dmabuf->cb_shared.poll = >poll;
> dmabuf->cb_excl.active = dmabuf->cb_shared.active = 0;
> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> index ab0c156..93108fd 100644
> --- a/include/linux/dma-buf.h
> +++ b/include/linux/dma-buf.h
> @@ -311,6 +311,7 @@ struct dma_buf {
> void *vmap_ptr;
> const char *exp_name;
> const char *name;
> + spinlock_t name_lock;
>
[PATCH v2] dma-buf: Move dma_buf_release() from fops to dentry_ops
Charan Teja reported a 'use-after-free' in dmabuffs_dname [1], which
happens if the dma_buf_release() is called while the userspace is
accessing the dma_buf pseudo fs's dmabuffs_dname() in another process,
and dma_buf_release() releases the dmabuf object when the last reference
to the struct file goes away.
I discussed with Arnd Bergmann, and he suggested that rather than tying
the dma_buf_release() to the file_operations' release(), we can tie it to
the dentry_operations' d_release(), which will be called when the last ref
to the dentry is removed.
The path exercised by __fput() calls f_op->release() first, and then calls
dput, which eventually calls d_op->d_release().
In the 'normal' case, when no userspace access is happening via dma_buf
pseudo fs, there should be exactly one fd, file, dentry and inode, so
closing the fd will kill of everything right away.
In the presented case, the dentry's d_release() will be called only when
the dentry's last ref is released.
Therefore, lets move dma_buf_release() from fops->release() to
d_ops->d_release()
Many thanks to Arnd for his FS insights :)
[1]: https://lore.kernel.org/patchwork/patch/1238278/
Fixes: bb2bb9030425 ("dma-buf: add DMA_BUF_SET_NAME ioctls")
Reported-by: syzbot+3643a18836bce555b...@syzkaller.appspotmail.com
Cc: [5.3+]
Cc: Arnd Bergmann
Reported-by: Charan Teja Reddy
Reviewed-by: Arnd Bergmann
Signed-off-by: Sumit Semwal
---
v2: per Arnd: Moved dma_buf_release() above to avoid forward declaration;
removed dentry_ops check.
---
drivers/dma-buf/dma-buf.c | 54 ++-
1 file changed, 25 insertions(+), 29 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 01ce125f8e8d..412629601ad3 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -54,37 +54,11 @@ static char *dmabuffs_dname(struct dentry *dentry, char
*buffer, int buflen)
dentry->d_name.name, ret > 0 ? name : "");
}
-static const struct dentry_operations dma_buf_dentry_ops = {
- .d_dname = dmabuffs_dname,
-};
-
-static struct vfsmount *dma_buf_mnt;
-
-static int dma_buf_fs_init_context(struct fs_context *fc)
-{
- struct pseudo_fs_context *ctx;
-
- ctx = init_pseudo(fc, DMA_BUF_MAGIC);
- if (!ctx)
- return -ENOMEM;
- ctx->dops = _buf_dentry_ops;
- return 0;
-}
-
-static struct file_system_type dma_buf_fs_type = {
- .name = "dmabuf",
- .init_fs_context = dma_buf_fs_init_context,
- .kill_sb = kill_anon_super,
-};
-
-static int dma_buf_release(struct inode *inode, struct file *file)
+static void dma_buf_release(struct dentry *dentry)
{
struct dma_buf *dmabuf;
- if (!is_dma_buf_file(file))
- return -EINVAL;
-
- dmabuf = file->private_data;
+ dmabuf = dentry->d_fsdata;
BUG_ON(dmabuf->vmapping_counter);
@@ -110,9 +84,32 @@ static int dma_buf_release(struct inode *inode, struct file
*file)
module_put(dmabuf->owner);
kfree(dmabuf->name);
kfree(dmabuf);
+}
+
+static const struct dentry_operations dma_buf_dentry_ops = {
+ .d_dname = dmabuffs_dname,
+ .d_release = dma_buf_release,
+};
+
+static struct vfsmount *dma_buf_mnt;
+
+static int dma_buf_fs_init_context(struct fs_context *fc)
+{
+ struct pseudo_fs_context *ctx;
+
+ ctx = init_pseudo(fc, DMA_BUF_MAGIC);
+ if (!ctx)
+ return -ENOMEM;
+ ctx->dops = _buf_dentry_ops;
return 0;
}
+static struct file_system_type dma_buf_fs_type = {
+ .name = "dmabuf",
+ .init_fs_context = dma_buf_fs_init_context,
+ .kill_sb = kill_anon_super,
+};
+
static int dma_buf_mmap_internal(struct file *file, struct vm_area_struct *vma)
{
struct dma_buf *dmabuf;
@@ -412,7 +409,6 @@ static void dma_buf_show_fdinfo(struct seq_file *m, struct
file *file)
}
static const struct file_operations dma_buf_fops = {
- .release= dma_buf_release,
.mmap = dma_buf_mmap_internal,
.llseek = dma_buf_llseek,
.poll = dma_buf_poll,
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: Move dma_buf_release() from fops to dentry_ops
On Wed, 10 Jun 2020 at 14:57, Arnd Bergmann wrote:
>
> On Wed, Jun 10, 2020 at 10:33 AM Sumit Semwal wrote:
> >
> > Charan Teja reported a 'use-after-free' in dmabuffs_dname [1], which
> > happens if the dma_buf_release() is called while the userspace is
> > accessing the dma_buf pseudo fs's dmabuffs_dname() in another process,
> > and dma_buf_release() releases the dmabuf object when the last reference
> > to the struct file goes away.
> >
> > I discussed with Arnd Bergmann, and he suggested that rather than tying
> > the dma_buf_release() to the file_operations' release(), we can tie it to
> > the dentry_operations' d_release(), which will be called when the last ref
> > to the dentry is removed.
> >
> > The path exercised by __fput() calls f_op->release() first, and then calls
> > dput, which eventually calls d_op->d_release().
> >
> > In the 'normal' case, when no userspace access is happening via dma_buf
> > pseudo fs, there should be exactly one fd, file, dentry and inode, so
> > closing the fd will kill of everything right away.
> >
> > In the presented case, the dentry's d_release() will be called only when
> > the dentry's last ref is released.
> >
> > Therefore, lets move dma_buf_release() from fops->release() to
> > d_ops->d_release().
> >
> > Many thanks to Arnd for his FS insights :)
> >
> > [1]: https://lore.kernel.org/patchwork/patch/1238278/
> >
> > Fixes: bb2bb9030425 ("dma-buf: add DMA_BUF_SET_NAME ioctls")
> > Reported-by: syzbot+3643a18836bce555b...@syzkaller.appspotmail.com
> > Cc: [5.3+]
> > Cc: Arnd Bergmann
> > Reported-by: Charan Teja Reddy
> > Signed-off-by: Sumit Semwal
>
> The patch looks correct to me.
>
> Reviewed-by: Arnd Bergmann
>
> Obviously this should still be verified against the original report if
> possible.
Thanks, Arnd!
>
> > drivers/dma-buf/dma-buf.c | 13 +++--
> > 1 file changed, 7 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> > index 01ce125f8e8d..92ba4b6ef3e7 100644
> > --- a/drivers/dma-buf/dma-buf.c
> > +++ b/drivers/dma-buf/dma-buf.c
> > @@ -54,8 +54,11 @@ static char *dmabuffs_dname(struct dentry *dentry, char
> > *buffer, int buflen)
> > dentry->d_name.name, ret > 0 ? name : "");
> > }
> >
> > +static void dma_buf_release(struct dentry *dentry);
> > +
> > static const struct dentry_operations dma_buf_dentry_ops = {
> > .d_dname = dmabuffs_dname,
> > + .d_release = dma_buf_release,
> > };
>
> I'd suggest rearranging the file to avoid the forward declaration, even
> if it makes it a little harder to review the change, the resulting code
> will remain organized more logically.
Got it, will update it in v2.
>
> > static struct vfsmount *dma_buf_mnt;
> > @@ -77,14 +80,14 @@ static struct file_system_type dma_buf_fs_type = {
> > .kill_sb = kill_anon_super,
> > };
> >
> > -static int dma_buf_release(struct inode *inode, struct file *file)
> > +static void dma_buf_release(struct dentry *dentry)
> > {
> > struct dma_buf *dmabuf;
> >
> > - if (!is_dma_buf_file(file))
> > - return -EINVAL;
> > + if (dentry->d_op != _buf_dentry_ops)
> > + return;
>
> I think the check here is redundant and it's clearer without it.
Ok, will remove.
>
> Arnd
Best,
Sumit.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] dma-buf: Move dma_buf_release() from fops to dentry_ops
Charan Teja reported a 'use-after-free' in dmabuffs_dname [1], which
happens if the dma_buf_release() is called while the userspace is
accessing the dma_buf pseudo fs's dmabuffs_dname() in another process,
and dma_buf_release() releases the dmabuf object when the last reference
to the struct file goes away.
I discussed with Arnd Bergmann, and he suggested that rather than tying
the dma_buf_release() to the file_operations' release(), we can tie it to
the dentry_operations' d_release(), which will be called when the last ref
to the dentry is removed.
The path exercised by __fput() calls f_op->release() first, and then calls
dput, which eventually calls d_op->d_release().
In the 'normal' case, when no userspace access is happening via dma_buf
pseudo fs, there should be exactly one fd, file, dentry and inode, so
closing the fd will kill of everything right away.
In the presented case, the dentry's d_release() will be called only when
the dentry's last ref is released.
Therefore, lets move dma_buf_release() from fops->release() to
d_ops->d_release().
Many thanks to Arnd for his FS insights :)
[1]: https://lore.kernel.org/patchwork/patch/1238278/
Fixes: bb2bb9030425 ("dma-buf: add DMA_BUF_SET_NAME ioctls")
Reported-by: syzbot+3643a18836bce555b...@syzkaller.appspotmail.com
Cc: [5.3+]
Cc: Arnd Bergmann
Reported-by: Charan Teja Reddy
Signed-off-by: Sumit Semwal
---
drivers/dma-buf/dma-buf.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 01ce125f8e8d..92ba4b6ef3e7 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -54,8 +54,11 @@ static char *dmabuffs_dname(struct dentry *dentry, char
*buffer, int buflen)
dentry->d_name.name, ret > 0 ? name : "");
}
+static void dma_buf_release(struct dentry *dentry);
+
static const struct dentry_operations dma_buf_dentry_ops = {
.d_dname = dmabuffs_dname,
+ .d_release = dma_buf_release,
};
static struct vfsmount *dma_buf_mnt;
@@ -77,14 +80,14 @@ static struct file_system_type dma_buf_fs_type = {
.kill_sb = kill_anon_super,
};
-static int dma_buf_release(struct inode *inode, struct file *file)
+static void dma_buf_release(struct dentry *dentry)
{
struct dma_buf *dmabuf;
- if (!is_dma_buf_file(file))
- return -EINVAL;
+ if (dentry->d_op != _buf_dentry_ops)
+ return;
- dmabuf = file->private_data;
+ dmabuf = dentry->d_fsdata;
BUG_ON(dmabuf->vmapping_counter);
@@ -110,7 +113,6 @@ static int dma_buf_release(struct inode *inode, struct file
*file)
module_put(dmabuf->owner);
kfree(dmabuf->name);
kfree(dmabuf);
- return 0;
}
static int dma_buf_mmap_internal(struct file *file, struct vm_area_struct *vma)
@@ -412,7 +414,6 @@ static void dma_buf_show_fdinfo(struct seq_file *m, struct
file *file)
}
static const struct file_operations dma_buf_fops = {
- .release= dma_buf_release,
.mmap = dma_buf_mmap_internal,
.llseek = dma_buf_llseek,
.poll = dma_buf_poll,
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/4] dma-buf: add support for virtio exported objects
Hello David, On Fri, 15 May 2020 at 19:33, Daniel Vetter wrote: > > On Fri, May 15, 2020 at 02:07:06PM +0900, David Stevens wrote: > > On Thu, May 14, 2020 at 9:30 PM Daniel Vetter wrote: > > > On Thu, May 14, 2020 at 05:19:40PM +0900, David Stevens wrote: > > > > Sorry for the duplicate reply, didn't notice this until now. > > > > > > > > > Just storing > > > > > the uuid should be doable (assuming this doesn't change during the > > > > > lifetime of the buffer), so no need for a callback. > > > > > > > > Directly storing the uuid doesn't work that well because of > > > > synchronization issues. The uuid needs to be shared between multiple > > > > virtio devices with independent command streams, so to prevent races > > > > between importing and exporting, the exporting driver can't share the > > > > uuid with other drivers until it knows that the device has finished > > > > registering the uuid. That requires a round trip to and then back from > > > > the device. Using a callback allows the latency from that round trip > > > > registration to be hidden. > > > > > > Uh, that means you actually do something and there's locking involved. > > > Makes stuff more complicated, invariant attributes are a lot easier > > > generally. Registering that uuid just always doesn't work, and blocking > > > when you're exporting? > > > > Registering the id at creation and blocking in gem export is feasible, > > but it doesn't work well for systems with a centralized buffer > > allocator that doesn't support batch allocations (e.g. gralloc). In > > such a system, the round trip latency would almost certainly be > > included in the buffer allocation time. At least on the system I'm > > working on, I suspect that would add 10s of milliseconds of startup > > latency to video pipelines (although I haven't benchmarked the > > difference). Doing the blocking as late as possible means most or all > > of the latency can be hidden behind other pipeline setup work. > > > > In terms of complexity, I think the synchronization would be basically > > the same in either approach, just in different locations. All it would > > do is alleviate the need for a callback to fetch the UUID. > I think I agree with Daniel there - this seems best suited for code within virtio. > Hm ok. I guess if we go with the older patch, where this all is a lot more > just code in virtio, doing an extra function to allocate the uuid sounds > fine. Then synchronization is entirely up to the virtio subsystem and not > a dma-buf problem (and hence not mine). You can use dma_resv_lock or so, > but no need to. But with callbacks potentially going both ways things > always get a bit interesting wrt locking - this is what makes peer2peer > dma-buf so painful right now. Hence I'd like to avoid that if needed, at > least at the dma-buf level. virtio code I don't mind what you do there :-) > > Cheers, Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch Best, Sumit. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] dma-buf: fix use-after-free in dmabuffs_dname
On Wed, 13 May 2020 at 21:16, Daniel Vetter wrote:
>
> On Wed, May 13, 2020 at 02:51:12PM +0200, Greg KH wrote:
> > On Wed, May 13, 2020 at 05:40:26PM +0530, Charan Teja Kalla wrote:
> > >
> > > Thank you Greg for the comments.
> > > On 5/12/2020 2:22 PM, Greg KH wrote:
> > > > On Fri, May 08, 2020 at 12:11:03PM +0530, Charan Teja Reddy wrote:
> > > >> The following race occurs while accessing the dmabuf object exported as
> > > >> file:
> > > >> P1 P2
> > > >> dma_buf_release() dmabuffs_dname()
> > > >> [say lsof reading /proc//fd/]
> > > >>
> > > >> read dmabuf stored in dentry->d_fsdata
> > > >> Free the dmabuf object
> > > >> Start accessing the dmabuf structure
> > > >>
> > > >> In the above description, the dmabuf object freed in P1 is being
> > > >> accessed from P2 which is resulting into the use-after-free. Below is
> > > >> the dump stack reported.
> > > >>
> > > >> We are reading the dmabuf object stored in the dentry->d_fsdata but
> > > >> there is no binding between the dentry and the dmabuf which means that
> > > >> the dmabuf can be freed while it is being read from ->d_fsdata and
> > > >> inuse. Reviews on the patch V1 says that protecting the dmabuf inuse
> > > >> with an extra refcount is not a viable solution as the exported dmabuf
> > > >> is already under file's refcount and keeping the multiple refcounts on
> > > >> the same object coordinated is not possible.
> > > >>
> > > >> As we are reading the dmabuf in ->d_fsdata just to get the user passed
> > > >> name, we can directly store the name in d_fsdata thus can avoid the
> > > >> reading of dmabuf altogether.
> > > >>
> > > >> Call Trace:
> > > >> kasan_report+0x12/0x20
> > > >> __asan_report_load8_noabort+0x14/0x20
> > > >> dmabuffs_dname+0x4f4/0x560
> > > >> tomoyo_realpath_from_path+0x165/0x660
> > > >> tomoyo_get_realpath
> > > >> tomoyo_check_open_permission+0x2a3/0x3e0
> > > >> tomoyo_file_open
> > > >> tomoyo_file_open+0xa9/0xd0
> > > >> security_file_open+0x71/0x300
> > > >> do_dentry_open+0x37a/0x1380
> > > >> vfs_open+0xa0/0xd0
> > > >> path_openat+0x12ee/0x3490
> > > >> do_filp_open+0x192/0x260
> > > >> do_sys_openat2+0x5eb/0x7e0
> > > >> do_sys_open+0xf2/0x180
> > > >>
> > > >> Fixes: bb2bb9030425 ("dma-buf: add DMA_BUF_SET_NAME ioctls")
> > > >> Reported-by: syzbot+3643a18836bce555b...@syzkaller.appspotmail.com
> > > >> Cc: [5.3+]
> > > >> Signed-off-by: Charan Teja Reddy
> > > >> ---
> > > >>
> > > >> Changes in v2:
> > > >>
> > > >> - Pass the user passed name in ->d_fsdata instead of dmabuf
> > > >> - Improve the commit message
> > > >>
> > > >> Changes in v1: (https://patchwork.kernel.org/patch/11514063/)
> > > >>
> > > >> drivers/dma-buf/dma-buf.c | 17 ++---
> > > >> 1 file changed, 10 insertions(+), 7 deletions(-)
> > > >>
> > > >> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> > > >> index 01ce125..0071f7d 100644
> > > >> --- a/drivers/dma-buf/dma-buf.c
> > > >> +++ b/drivers/dma-buf/dma-buf.c
> > > >> @@ -25,6 +25,7 @@
> > > >> #include
> > > >> #include
> > > >> #include
> > > >> +#include
> > > >>
> > > >> #include
> > > >> #include
> > > >> @@ -40,15 +41,13 @@ struct dma_buf_list {
> > > >>
> > > >> static char *dmabuffs_dname(struct dentry *dentry, char *buffer, int
> > > >> buflen)
> > > >> {
> > > >> -struct dma_buf *dmabuf;
> > > >> char name[DMA_BUF_NAME_LEN];
> > > >> size_t ret = 0;
> > > >>
> > > >> -dmabuf = dentry->d_fsdata;
> > > >> -dma_resv_lock(dmabuf->resv, NULL);
> > > >> -if (dmabuf->name)
> > > >> -ret = strlcpy(name, dmabuf->name, DMA_BUF_NAME_LEN);
> > > >> -dma_resv_unlock(dmabuf->resv);
> > > >> +spin_lock(>d_lock);
> > > >
> > > > Are you sure this lock always protects d_fsdata?
> > >
> > > I think yes. In the dma-buf.c, I have to make sure that d_fsdata should
> > > always be under d_lock thus it will be protected. (In this posted patch
> > > there is one place(in dma_buf_set_name) that is missed, will update this
> > > in V3).
> > >
> > > >
> > > >> +if (dentry->d_fsdata)
> > > >> +ret = strlcpy(name, dentry->d_fsdata,
> > > >> DMA_BUF_NAME_LEN);
> > > >> +spin_unlock(>d_lock);
> > > >>
> > > >> return dynamic_dname(dentry, buffer, buflen, "/%s:%s",
> > > >> dentry->d_name.name, ret > 0 ? name :
> > > >> "");
> > > >
> > > > If the above check fails the name will be what? How could d_name.name
> > > > be valid but d_fsdata not be valid?
> > >
> > > In case of check fails, empty string "" is appended to the name by the
> > > code, ret > 0 ? name : "", ret is initialized to zero. Thus the name
> > > string will be like "/dmabuf:".
> >
> > So multiple objects can have the same "name" if this happens to multiple
> > ones at once?
> >
> > > Regarding the validity of
Re: [PATCH] dma-buf: Documentation: fix: `make htmldocs` warnings
Hello Everyone, On Thu, 30 Apr 2020 at 10:07, Sam Ravnborg wrote: > > On Wed, Apr 29, 2020 at 11:27:22PM -0300, Vitor Massaru Iha wrote: > > On Wed, 2020-04-29 at 19:06 -0700, Randy Dunlap wrote: > > > On 4/29/20 6:59 PM, Vitor Massaru Iha wrote: > > > > Add missed ":" on kernel-doc function parameter. > > > > > > > > This patch fixes this warnings from `make htmldocs`: > > > > ./drivers/dma-buf/dma-buf.c:678: warning: Function parameter or > > > > member 'importer_ops' not described in 'dma_buf_dynamic_attach' > > > > ./drivers/dma-buf/dma-buf.c:678: warning: Function parameter or > > > > member 'importer_priv' not described in 'dma_buf_dynamic_attach' > > > > > > > > Signed-off-by: Vitor Massaru Iha > > > > --- > > > > drivers/dma-buf/dma-buf.c | 4 ++-- > > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > > > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c > > > > index ccc9eda1bc28..0756d2155745 100644 > > > > --- a/drivers/dma-buf/dma-buf.c > > > > +++ b/drivers/dma-buf/dma-buf.c > > > > @@ -655,8 +655,8 @@ EXPORT_SYMBOL_GPL(dma_buf_put); > > > > * calls attach() of dma_buf_ops to allow device-specific attach > > > > functionality > > > > * @dmabuf: [in]buffer to attach device to. > > > > * @dev: [in]device to be attached. > > > > - * @importer_ops [in]importer operations for the > > > > attachment > > > > - * @importer_priv[in]importer private pointer for the > > > > attachment > > > > + * @importer_ops:[in]importer operations for the > > > > attachment > > > > + * @importer_priv: [in]importer private pointer for the > > > > attachment > > > > * > > > > * Returns struct dma_buf_attachment pointer for this attachment. > > > > Attachments > > > > * must be cleaned up by calling dma_buf_detach(). > > > > > > > > > > Sumit said that he would be applying my patch from April 7: > > > https://lore.kernel.org/linux-media/7bcbe6fe-0b4b-87da-d003-b68a26eb4...@infradead.org/ > > > > > > thanks. > > > > Sorry. I didn't check if the patch has already been sent. > > Sumit - patch from Randy is neither applied to drm-misc-next nor > drm-misc-fixes. > A reminder in case it was lost somewhere. My bad: I have now applied it to drm-misc-fixes, so should be seen in -next soon. > > Sam Best, Sumit. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: Fix SET_NAME ioctl uapi
Thanks Daniel, Martin,
On Thu, 23 Apr 2020 at 20:21, Martin Liu wrote:
>
> On Thu, Apr 09, 2020 at 09:28:16AM +0530, Sumit Semwal wrote:
> > Thanks for the patch, Daniel!
> >
> >
> > On Tue, 7 Apr 2020 at 19:00, Daniel Vetter wrote:
> > >
> > > The uapi is the same on 32 and 64 bit, but the number isnt. Everyone
> > > who botched this please re-read:
> > >
> > > https://www.kernel.org/doc/html/v5.4-preprc-cpu/ioctl/botching-up-ioctls.html
> > >
> > > Also, the type argument for the ioctl macros is for the type the void
> > > __user *arg pointer points at, which in this case would be the
> > > variable-sized char[] of a 0 terminated string. So this was botched in
> > > more than just the usual ways.
> >
> > Yes, it shouldn't have passed through the cracks; my apologies!
> >
> > >
> > > Cc: Sumit Semwal
> > > Cc: Chenbo Feng
> > > Cc: Greg Hackmann
> > > Cc: Daniel Vetter
> > > Cc: linux-me...@vger.kernel.org
> > > Cc: linaro-mm-...@lists.linaro.org
> > > Cc: minc...@kernel.org
> > > Cc: sur...@google.com
> > > Cc: jenhaoc...@google.com
> > > Cc: Martin Liu
> >
> > Martin,
> > Could I request you to test this one with the 4 combinations of 32-bit
> > / 64-bit userspace and kernel, and let us know that all 4 are working
> > alright? If yes, please consider giving your tested-by here.
> >
> Hi Sumit, Daniel,
> Sorry for being late to the tests. I finished the tests on 32/64 apps
> with 64 bit kernel and they were fine. Unfortunately, I couldn't have a 32
> bit kernel to run the tests somehow. However, this should work from the
> code logic. Hope this is okay to you and thanks for Todd's help.
>
> Tested-by: Martin Liu
> Reviewed-by: Martin Liu
Applied to drm-misc-fixes.
>
> > > Signed-off-by: Daniel Vetter
> > > ---
> > > drivers/dma-buf/dma-buf.c| 3 ++-
> > > include/uapi/linux/dma-buf.h | 4
> > > 2 files changed, 6 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> > > index 570c923023e6..1d923b8e4c59 100644
> > > --- a/drivers/dma-buf/dma-buf.c
> > > +++ b/drivers/dma-buf/dma-buf.c
> > > @@ -388,7 +388,8 @@ static long dma_buf_ioctl(struct file *file,
> > >
> > > return ret;
> > >
> > > - case DMA_BUF_SET_NAME:
> > > + case DMA_BUF_SET_NAME_A:
> > > + case DMA_BUF_SET_NAME_B:
> > > return dma_buf_set_name(dmabuf, (const char __user *)arg);
> > >
> > > default:
> > > diff --git a/include/uapi/linux/dma-buf.h b/include/uapi/linux/dma-buf.h
> > > index dbc7092e04b5..21dfac815dc0 100644
> > > --- a/include/uapi/linux/dma-buf.h
> > > +++ b/include/uapi/linux/dma-buf.h
> > > @@ -39,6 +39,10 @@ struct dma_buf_sync {
> > >
> > > #define DMA_BUF_BASE 'b'
> > > #define DMA_BUF_IOCTL_SYNC _IOW(DMA_BUF_BASE, 0, struct dma_buf_sync)
> > > +/* 32/64bitness of this uapi was botched in android, there's no
> > > difference
> > > + * between them in actual uapi, they're just different numbers. */
> > > #define DMA_BUF_SET_NAME _IOW(DMA_BUF_BASE, 1, const char *)
> > > +#define DMA_BUF_SET_NAME_A _IOW(DMA_BUF_BASE, 1, u32)
> > > +#define DMA_BUF_SET_NAME_B _IOW(DMA_BUF_BASE, 1, u64)
> > >
> > > #endif
> > > --
> > > 2.25.1
> > >
> > Best,
> > Sumit.
Best,
Sumit.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH -next] dma-buf: fix documentation build warnings
Hello Randy,
On Wed, 8 Apr 2020 at 09:50, Randy Dunlap wrote:
>
> From: Randy Dunlap
>
> Fix documentation warnings in dma-buf.[hc]:
Thank you for your patch; I will apply it to drm-misc tree.
>
> ../drivers/dma-buf/dma-buf.c:678: warning: Function parameter or member
> 'importer_ops' not described in 'dma_buf_dynamic_attach'
> ../drivers/dma-buf/dma-buf.c:678: warning: Function parameter or member
> 'importer_priv' not described in 'dma_buf_dynamic_attach'
> ../include/linux/dma-buf.h:339: warning: Incorrect use of kernel-doc format:
> * @move_notify
>
> Signed-off-by: Randy Dunlap
> Cc: Sumit Semwal
> Cc: linux-me...@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: linaro-mm-...@lists.linaro.org
> ---
> drivers/dma-buf/dma-buf.c |4 ++--
> include/linux/dma-buf.h |3 +--
> 2 files changed, 3 insertions(+), 4 deletions(-)
>
> --- linux-next-20200407.orig/drivers/dma-buf/dma-buf.c
> +++ linux-next-20200407/drivers/dma-buf/dma-buf.c
> @@ -655,8 +655,8 @@ EXPORT_SYMBOL_GPL(dma_buf_put);
> * calls attach() of dma_buf_ops to allow device-specific attach
> functionality
> * @dmabuf:[in]buffer to attach device to.
> * @dev: [in]device to be attached.
> - * @importer_ops [in]importer operations for the attachment
> - * @importer_priv [in]importer private pointer for the attachment
> + * @importer_ops: [in]importer operations for the attachment
> + * @importer_priv: [in]importer private pointer for the attachment
> *
> * Returns struct dma_buf_attachment pointer for this attachment. Attachments
> * must be cleaned up by calling dma_buf_detach().
> --- linux-next-20200407.orig/include/linux/dma-buf.h
> +++ linux-next-20200407/include/linux/dma-buf.h
> @@ -329,13 +329,12 @@ struct dma_buf {
>
> /**
> * struct dma_buf_attach_ops - importer operations for an attachment
> - * @move_notify: [optional] notification that the DMA-buf is moving
> *
> * Attachment operations implemented by the importer.
> */
> struct dma_buf_attach_ops {
> /**
> -* @move_notify
> +* @move_notify: [optional] notification that the DMA-buf is moving
> *
> * If this callback is provided the framework can avoid pinning the
> * backing store while mappings exists.
>
Best,
Sumit.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: Fix SET_NAME ioctl uapi
Thanks for the patch, Daniel!
On Tue, 7 Apr 2020 at 19:00, Daniel Vetter wrote:
>
> The uapi is the same on 32 and 64 bit, but the number isnt. Everyone
> who botched this please re-read:
>
> https://www.kernel.org/doc/html/v5.4-preprc-cpu/ioctl/botching-up-ioctls.html
>
> Also, the type argument for the ioctl macros is for the type the void
> __user *arg pointer points at, which in this case would be the
> variable-sized char[] of a 0 terminated string. So this was botched in
> more than just the usual ways.
Yes, it shouldn't have passed through the cracks; my apologies!
>
> Cc: Sumit Semwal
> Cc: Chenbo Feng
> Cc: Greg Hackmann
> Cc: Daniel Vetter
> Cc: linux-me...@vger.kernel.org
> Cc: linaro-mm-...@lists.linaro.org
> Cc: minc...@kernel.org
> Cc: sur...@google.com
> Cc: jenhaoc...@google.com
> Cc: Martin Liu
Martin,
Could I request you to test this one with the 4 combinations of 32-bit
/ 64-bit userspace and kernel, and let us know that all 4 are working
alright? If yes, please consider giving your tested-by here.
> Signed-off-by: Daniel Vetter
> ---
> drivers/dma-buf/dma-buf.c| 3 ++-
> include/uapi/linux/dma-buf.h | 4
> 2 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 570c923023e6..1d923b8e4c59 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -388,7 +388,8 @@ static long dma_buf_ioctl(struct file *file,
>
> return ret;
>
> - case DMA_BUF_SET_NAME:
> + case DMA_BUF_SET_NAME_A:
> + case DMA_BUF_SET_NAME_B:
> return dma_buf_set_name(dmabuf, (const char __user *)arg);
>
> default:
> diff --git a/include/uapi/linux/dma-buf.h b/include/uapi/linux/dma-buf.h
> index dbc7092e04b5..21dfac815dc0 100644
> --- a/include/uapi/linux/dma-buf.h
> +++ b/include/uapi/linux/dma-buf.h
> @@ -39,6 +39,10 @@ struct dma_buf_sync {
>
> #define DMA_BUF_BASE 'b'
> #define DMA_BUF_IOCTL_SYNC _IOW(DMA_BUF_BASE, 0, struct dma_buf_sync)
> +/* 32/64bitness of this uapi was botched in android, there's no difference
> + * between them in actual uapi, they're just different numbers. */
> #define DMA_BUF_SET_NAME _IOW(DMA_BUF_BASE, 1, const char *)
> +#define DMA_BUF_SET_NAME_A _IOW(DMA_BUF_BASE, 1, u32)
> +#define DMA_BUF_SET_NAME_B _IOW(DMA_BUF_BASE, 1, u64)
>
> #endif
> --
> 2.25.1
>
Best,
Sumit.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
