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-de...@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
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.
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.
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-de...@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
>
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-de...@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.
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-de...@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: [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-de...@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.
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.
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-de...@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.
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-de...@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.
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-de...@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.
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.
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);
>
[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-de...@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
[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
[PATCH v7 2/3] mm: memory: Add access_remote_vm_locked variant
This allows accessing a remote vm while the mmap_lock is already
held by the caller.
While adding support for anonymous vma naming, show_map_vma()
needs to access the remote vm to get the name of the anonymous vma.
Since show_map_vma() already holds the mmap_lock, so this _locked
variant was required.
Signed-off-by: Sumit Semwal
---
include/linux/mm.h | 2 ++
mm/memory.c| 49 --
2 files changed, 45 insertions(+), 6 deletions(-)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index ca6e6a81576b..e9212c0bb5ac 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1708,6 +1708,8 @@ extern int access_remote_vm(struct mm_struct *mm,
unsigned long addr,
void *buf, int len, unsigned int gup_flags);
extern int __access_remote_vm(struct task_struct *tsk, struct mm_struct *mm,
unsigned long addr, void *buf, int len, unsigned int gup_flags);
+extern int access_remote_vm_locked(struct mm_struct *mm, unsigned long addr,
+ void *buf, int len, unsigned int gup_flags);
long get_user_pages_remote(struct mm_struct *mm,
unsigned long start, unsigned long nr_pages,
diff --git a/mm/memory.c b/mm/memory.c
index 602f4283122f..207be99390e9 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -4726,17 +4726,17 @@ EXPORT_SYMBOL_GPL(generic_access_phys);
/*
* Access another process' address space as given in mm. If non-NULL, use the
* given task for page fault accounting.
+ * This variant assumes that the mmap_lock is already held by the caller, so
+ * doesn't take the mmap_lock.
*/
-int __access_remote_vm(struct task_struct *tsk, struct mm_struct *mm,
- unsigned long addr, void *buf, int len, unsigned int gup_flags)
+int __access_remote_vm_locked(struct task_struct *tsk, struct mm_struct *mm,
+ unsigned long addr, void *buf, int len,
+ unsigned int gup_flags)
{
struct vm_area_struct *vma;
void *old_buf = buf;
int write = gup_flags & FOLL_WRITE;
- if (mmap_read_lock_killable(mm))
- return 0;
-
/* ignore errors, just check how much was successfully transferred */
while (len) {
int bytes, ret, offset;
@@ -4785,9 +4785,46 @@ int __access_remote_vm(struct task_struct *tsk, struct
mm_struct *mm,
buf += bytes;
addr += bytes;
}
+ return buf - old_buf;
+}
+
+/*
+ * Access another process' address space as given in mm. If non-NULL, use the
+ * given task for page fault accounting.
+ */
+int __access_remote_vm(struct task_struct *tsk, struct mm_struct *mm,
+ unsigned long addr, void *buf, int len, unsigned int
gup_flags)
+{
+ int ret;
+
+ if (mmap_read_lock_killable(mm))
+ return 0;
+
+ ret = __access_remote_vm_locked(tsk, mm, addr, buf, len, gup_flags);
mmap_read_unlock(mm);
- return buf - old_buf;
+ return ret;
+}
+
+/**
+ * access_remote_vm_locked - access another process' address space, without
+ * taking the mmap_lock. This allows nested calls from callers that already
have
+ * taken the lock.
+ *
+ * @mm:the mm_struct of the target address space
+ * @addr: start address to access
+ * @buf: source or destination buffer
+ * @len: number of bytes to transfer
+ * @gup_flags: flags modifying lookup behaviour
+ *
+ * The caller must hold a reference on @mm, as well as hold the mmap_lock
+ *
+ * Return: number of bytes copied from source to destination.
+ */
+int access_remote_vm_locked(struct mm_struct *mm, unsigned long addr, void
*buf,
+ int len, unsigned int gup_flags)
+{
+ return __access_remote_vm_locked(NULL, mm, addr, buf, len, gup_flags);
}
/**
--
2.28.0
[PATCH v7 0/3] Anonymous VMA naming patches
Version v4 of these patches was sent by Colin Cross a long time ago [1] and [2]. At the time, these patches were not merged, and it looks like they just fell off the radar since. In our efforts to run Android on mainline kernels, we realised that since past some time, this patchset is needed for Android to boot, hence I am re-posting it to try and get these discussed and hopefully merged. I have rebased these for v5.9-rc3 and fixed minor updates as required. --- v6: Rebased to v5.9-rc3 and addressed review comments: - added missing callers in fs/userfaultd.c - simplified the union - use the new access_remote_vm_locked() in show_map_vma() since that already holds mmap_lock v7: fixed randconfig build failure when CONFIG_ADVISE_SYSCALLS isn't defined Colin Cross (2): mm: rearrange madvise code to allow for reuse mm: add a field to store names for private anonymous memory Sumit Semwal (1): mm: memory: Add access_remote_vm_locked variant Documentation/filesystems/proc.rst | 2 + fs/proc/task_mmu.c | 24 +- fs/userfaultfd.c | 7 +- include/linux/mm.h | 14 +- include/linux/mm_types.h | 25 +- include/uapi/linux/prctl.h | 3 + kernel/sys.c | 32 +++ mm/interval_tree.c | 2 +- mm/madvise.c | 356 + mm/memory.c| 49 +++- mm/mempolicy.c | 3 +- mm/mlock.c | 2 +- mm/mmap.c | 38 +-- mm/mprotect.c | 2 +- 14 files changed, 381 insertions(+), 178 deletions(-) -- 2.28.0
[PATCH v6 0/3] Anonymous VMA naming patches
Version v4 of these patches was sent by Colin Cross a long time ago [1] and [2]. At the time, these patches were not merged, and it looks like they just fell off the radar since. In our efforts to run Android on mainline kernels, we realised that since past some time, this patchset is needed for Android to boot, hence I am re-posting it to try and get these discussed and hopefully merged. For v5, I rebased these for v5.9-rc3 and fixed minor updates as required. --- v6: Rebased to v5.9-rc3 and addressed review comments: - added missing callers in fs/userfaultd.c - simplified the union - use the new access_remote_vm_locked() in show_map_vma() since that already holds mmap_lock [1]: https://lore.kernel.org/linux-mm/1383170047-21074-1-git-send-email-ccr...@android.com/ [2]: https://lore.kernel.org/linux-mm/1383170047-21074-2-git-send-email-ccr...@android.com/ Best, Sumit. Colin Cross (2): mm: rearrange madvise code to allow for reuse mm: add a field to store names for private anonymous memory Sumit Semwal (1): mm: memory: Add access_remote_vm_locked variant Documentation/filesystems/proc.rst | 2 + fs/proc/task_mmu.c | 24 +- fs/userfaultfd.c | 7 +- include/linux/mm.h | 7 +- include/linux/mm_types.h | 25 +- include/uapi/linux/prctl.h | 3 + kernel/sys.c | 32 +++ mm/interval_tree.c | 2 +- mm/madvise.c | 356 + mm/memory.c| 49 +++- mm/mempolicy.c | 3 +- mm/mlock.c | 2 +- mm/mmap.c | 38 +-- mm/mprotect.c | 2 +- 14 files changed, 374 insertions(+), 178 deletions(-) -- 2.28.0
[PATCH v6 2/3] mm: memory: Add access_remote_vm_locked variant
This allows accessing a remote vm while the mmap_lock is already
held by the caller.
While adding support for anonymous vma naming, show_map_vma()
needs to access the remote vm to get the name of the anonymous vma.
Since show_map_vma() already holds the mmap_lock, so this _locked
variant was required.
Signed-off-by: Sumit Semwal
---
include/linux/mm.h | 2 ++
mm/memory.c| 49 --
2 files changed, 45 insertions(+), 6 deletions(-)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index ca6e6a81576b..e9212c0bb5ac 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1708,6 +1708,8 @@ extern int access_remote_vm(struct mm_struct *mm,
unsigned long addr,
void *buf, int len, unsigned int gup_flags);
extern int __access_remote_vm(struct task_struct *tsk, struct mm_struct *mm,
unsigned long addr, void *buf, int len, unsigned int gup_flags);
+extern int access_remote_vm_locked(struct mm_struct *mm, unsigned long addr,
+ void *buf, int len, unsigned int gup_flags);
long get_user_pages_remote(struct mm_struct *mm,
unsigned long start, unsigned long nr_pages,
diff --git a/mm/memory.c b/mm/memory.c
index 602f4283122f..207be99390e9 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -4726,17 +4726,17 @@ EXPORT_SYMBOL_GPL(generic_access_phys);
/*
* Access another process' address space as given in mm. If non-NULL, use the
* given task for page fault accounting.
+ * This variant assumes that the mmap_lock is already held by the caller, so
+ * doesn't take the mmap_lock.
*/
-int __access_remote_vm(struct task_struct *tsk, struct mm_struct *mm,
- unsigned long addr, void *buf, int len, unsigned int gup_flags)
+int __access_remote_vm_locked(struct task_struct *tsk, struct mm_struct *mm,
+ unsigned long addr, void *buf, int len,
+ unsigned int gup_flags)
{
struct vm_area_struct *vma;
void *old_buf = buf;
int write = gup_flags & FOLL_WRITE;
- if (mmap_read_lock_killable(mm))
- return 0;
-
/* ignore errors, just check how much was successfully transferred */
while (len) {
int bytes, ret, offset;
@@ -4785,9 +4785,46 @@ int __access_remote_vm(struct task_struct *tsk, struct
mm_struct *mm,
buf += bytes;
addr += bytes;
}
+ return buf - old_buf;
+}
+
+/*
+ * Access another process' address space as given in mm. If non-NULL, use the
+ * given task for page fault accounting.
+ */
+int __access_remote_vm(struct task_struct *tsk, struct mm_struct *mm,
+ unsigned long addr, void *buf, int len, unsigned int
gup_flags)
+{
+ int ret;
+
+ if (mmap_read_lock_killable(mm))
+ return 0;
+
+ ret = __access_remote_vm_locked(tsk, mm, addr, buf, len, gup_flags);
mmap_read_unlock(mm);
- return buf - old_buf;
+ return ret;
+}
+
+/**
+ * access_remote_vm_locked - access another process' address space, without
+ * taking the mmap_lock. This allows nested calls from callers that already
have
+ * taken the lock.
+ *
+ * @mm:the mm_struct of the target address space
+ * @addr: start address to access
+ * @buf: source or destination buffer
+ * @len: number of bytes to transfer
+ * @gup_flags: flags modifying lookup behaviour
+ *
+ * The caller must hold a reference on @mm, as well as hold the mmap_lock
+ *
+ * Return: number of bytes copied from source to destination.
+ */
+int access_remote_vm_locked(struct mm_struct *mm, unsigned long addr, void
*buf,
+ int len, unsigned int gup_flags)
+{
+ return __access_remote_vm_locked(NULL, mm, addr, buf, len, gup_flags);
}
/**
--
2.28.0
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
[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
[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
[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 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
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
[PATCH v5 0/2] Anonymous VMA naming patches
Last version v4 of these patches was sent by Colin Cross a long time ago [1] and [2]. At the time, these patches were not merged, and it looks like they just fell off the radar since. In our efforts to run Android on mainline kernels, we realised that since past some time, this patchset is needed for Android to boot, hence I am re-posting it to try and get these discussed and hopefully merged. I have rebased these for v5.9-rc1 and fixed minor updates as required. [1]: https://lore.kernel.org/linux-mm/1383170047-21074-1-git-send-email-ccr...@android.com/ [2]: https://lore.kernel.org/linux-mm/1383170047-21074-2-git-send-email-ccr...@android.com/ Best, Sumit. Colin Cross (2): mm: rearrange madvise code to allow for reuse mm: add a field to store names for private anonymous memory Documentation/filesystems/proc.rst | 2 + fs/proc/task_mmu.c | 24 +- include/linux/mm.h | 5 +- include/linux/mm_types.h | 23 +- include/uapi/linux/prctl.h | 3 + kernel/sys.c | 32 +++ mm/interval_tree.c | 34 +-- mm/madvise.c | 356 + mm/mempolicy.c | 3 +- mm/mlock.c | 2 +- mm/mmap.c | 38 +-- mm/mprotect.c | 2 +- 12 files changed, 340 insertions(+), 184 deletions(-) -- 2.28.0
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 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
[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 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
[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
[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
[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 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
[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
[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
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.
[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
[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)];
+
[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
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.
[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
[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
[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
[RESEND: PATCH v5 1/4] regulator: Allow regulators to verify enabled during enable()
Some regulators might need to verify that they have indeed been enabled
after the enable() call is made and enable_time delay has passed.
This is implemented by repeatedly checking is_enabled() upto
poll_enabled_time, waiting for the already calculated enable delay in
each iteration.
Signed-off-by: Sumit Semwal
---
v3: addressed minor review comments, improved kernel doc
v2: Address review comments, including swapping enable_time and
poll_enabled_time.
---
drivers/regulator/core.c | 63 +++-
include/linux/regulator/driver.h | 5 +++
2 files changed, 67 insertions(+), 1 deletion(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 03154f5b939f..538a2779986a 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -2347,6 +2347,37 @@ static void _regulator_enable_delay(unsigned int delay)
udelay(us);
}
+/**
+ * _regulator_check_status_enabled
+ *
+ * A helper function to check if the regulator status can be interpreted
+ * as 'regulator is enabled'.
+ * @rdev: the regulator device to check
+ *
+ * Return:
+ * * 1 - if status shows regulator is in enabled state
+ * * 0 - if not enabled state
+ * * Error Value - as received from ops->get_status()
+ */
+static inline int _regulator_check_status_enabled(struct regulator_dev *rdev)
+{
+ int ret = rdev->desc->ops->get_status(rdev);
+
+ if (ret < 0) {
+ rdev_info(rdev, "get_status returned error: %d\n", ret);
+ return ret;
+ }
+
+ switch (ret) {
+ case REGULATOR_STATUS_OFF:
+ case REGULATOR_STATUS_ERROR:
+ case REGULATOR_STATUS_UNDEFINED:
+ return 0;
+ default:
+ return 1;
+ }
+}
+
static int _regulator_do_enable(struct regulator_dev *rdev)
{
int ret, delay;
@@ -2407,7 +2438,37 @@ static int _regulator_do_enable(struct regulator_dev
*rdev)
* together. */
trace_regulator_enable_delay(rdev_get_name(rdev));
- _regulator_enable_delay(delay);
+ /* If poll_enabled_time is set, poll upto the delay calculated
+* above, delaying poll_enabled_time uS to check if the regulator
+* actually got enabled.
+* If the regulator isn't enabled after enable_delay has
+* expired, return -ETIMEDOUT.
+*/
+ if (rdev->desc->poll_enabled_time) {
+ unsigned int time_remaining = delay;
+
+ while (time_remaining > 0) {
+ _regulator_enable_delay(rdev->desc->poll_enabled_time);
+
+ if (rdev->desc->ops->get_status) {
+ ret = _regulator_check_status_enabled(rdev);
+ if (ret < 0)
+ return ret;
+ else if (ret)
+ break;
+ } else if (rdev->desc->ops->is_enabled(rdev))
+ break;
+
+ time_remaining -= rdev->desc->poll_enabled_time;
+ }
+
+ if (time_remaining <= 0) {
+ rdev_err(rdev, "Enabled check timed out\n");
+ return -ETIMEDOUT;
+ }
+ } else {
+ _regulator_enable_delay(delay);
+ }
trace_regulator_enable_complete(rdev_get_name(rdev));
diff --git a/include/linux/regulator/driver.h b/include/linux/regulator/driver.h
index 7eb9fea8e482..436df3ba0b2a 100644
--- a/include/linux/regulator/driver.h
+++ b/include/linux/regulator/driver.h
@@ -305,6 +305,9 @@ enum regulator_type {
* @enable_time: Time taken for initial enable of regulator (in uS).
* @off_on_delay: guard time (in uS), before re-enabling a regulator
*
+ * @poll_enabled_time: The polling interval (in uS) to use while checking that
+ * the regulator was actually enabled. Max upto
enable_time.
+ *
* @of_map_mode: Maps a hardware mode defined in a DeviceTree to a standard
mode
*/
struct regulator_desc {
@@ -372,6 +375,8 @@ struct regulator_desc {
unsigned int off_on_delay;
+ unsigned int poll_enabled_time;
+
unsigned int (*of_map_mode)(unsigned int mode);
};
--
2.27.0
[RESEND PATCH v5 3/4] arm64: dts: qcom: pmi8998: Add nodes for LAB and IBB regulators
From: Nisha Kumari
This patch adds devicetree nodes for LAB and IBB regulators.
Signed-off-by: Nisha Kumari
Signed-off-by: Sumit Semwal
[sumits: Updated for better compatible strings and names]
---
v5: sumits: removed interrupt-names, since there is only one
interrupt per node
v4: sumits: removed labibb label which is not needed
v3: sumits: updated interrupt-names as per review comments
v2: sumits: updated for better compatible string and names
---
arch/arm64/boot/dts/qcom/pmi8998.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/pmi8998.dtsi
b/arch/arm64/boot/dts/qcom/pmi8998.dtsi
index 23f9146a161e..d016b12967eb 100644
--- a/arch/arm64/boot/dts/qcom/pmi8998.dtsi
+++ b/arch/arm64/boot/dts/qcom/pmi8998.dtsi
@@ -25,5 +25,17 @@ pmi8998_lsid1: pmic@3 {
reg = <0x3 SPMI_USID>;
#address-cells = <1>;
#size-cells = <0>;
+
+ labibb {
+ compatible = "qcom,pmi8998-lab-ibb";
+
+ ibb: ibb {
+ interrupts = <0x3 0xdc 0x2
IRQ_TYPE_EDGE_RISING>;
+ };
+
+ lab: lab {
+ interrupts = <0x3 0xde 0x0
IRQ_TYPE_EDGE_RISING>;
+ };
+ };
};
};
--
2.27.0
[RESEND PATCH v5 2/4] dt-bindings: regulator: Add labibb regulator
From: Nisha Kumari
Adding the devicetree binding for labibb regulator.
Signed-off-by: Nisha Kumari
Signed-off-by: Sumit Semwal
[sumits: cleanup as per review comments and update to yaml]
---
v5: Addressed review comments - removed interrupt-names, changed to
dual license, added unevaluatedProperties: false
v4: fixed dt_binding_check issues
v3: moved to yaml
v2: updated for better compatible string and names.
---
.../regulator/qcom-labibb-regulator.yaml | 70 +++
1 file changed, 70 insertions(+)
create mode 100644
Documentation/devicetree/bindings/regulator/qcom-labibb-regulator.yaml
diff --git
a/Documentation/devicetree/bindings/regulator/qcom-labibb-regulator.yaml
b/Documentation/devicetree/bindings/regulator/qcom-labibb-regulator.yaml
new file mode 100644
index ..085cbd1ad8d0
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/qcom-labibb-regulator.yaml
@@ -0,0 +1,70 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/qcom-labibb-regulator.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm's LAB(LCD AMOLED Boost)/IBB(Inverting Buck Boost) Regulator
+
+maintainers:
+ - Sumit Semwal
+
+description:
+ LAB can be used as a positive boost power supply and IBB can be used as a
+ negative boost power supply for display panels. Currently implemented for
+ pmi8998.
+
+properties:
+ compatible:
+const: qcom,pmi8998-lab-ibb
+
+ lab:
+type: object
+
+properties:
+
+ interrupts:
+maxItems: 1
+description:
+ Short-circuit interrupt for lab.
+
+required:
+- interrupts
+
+ ibb:
+type: object
+
+properties:
+
+ interrupts:
+maxItems: 1
+description:
+ Short-circuit interrupt for lab.
+
+required:
+- interrupts
+
+required:
+ - compatible
+
+unevaluatedProperties: false
+
+examples:
+ - |
+#include
+
+labibb {
+ compatible = "qcom,pmi8998-lab-ibb";
+
+ lab {
+interrupts = <0x3 0x0 IRQ_TYPE_EDGE_RISING>;
+interrupt-names = "sc-err";
+ };
+
+ ibb {
+interrupts = <0x3 0x2 IRQ_TYPE_EDGE_RISING>;
+interrupt-names = "sc-err";
+ };
+};
+
+...
--
2.27.0
[RESEND: PATCH v5 0/4] Qualcomm labibb regulator driver
This series adds a driver for LAB/IBB regulators found on some Qualcomm SoCs. These regulators provide positive and/or negative boost power supplies for LCD/LED display panels connected to the SoC. This series adds the support for pmi8998 PMIC found in SDM845 family of SoCs. Changes from v4: - v4 Review comments incorporated - simplified the driver: removed of_get_child_by_name(); use ENABLE_CTL register and switch over to use the regulator_*_regmap helpers - improved kerneldoc - From the dt-bindings, removed interrupt-names, changed to dual license, added unevaluatedProperties: false, removed interrupt-names, since there is only one interrupt per node - Since the Short Circuit handling needs more details from QC engineers, drop the SC handling patch from this series, to submit it later Changes from v3: - Handled review comments from v3 - In core, swapped the meaning of enable_time and poll_enabled_time; so we wait for total enable_time delay, and poll in-between at poll_enabled_time interval now. - fixed dt_bindings_check issues in dt-bindings patch. - Cleanup of register_labibb_regulator(), and adapted to updated meaning of poll_enabled_time. Changes from v2: - Review comments from v2 - Moved the poll-to-check-enabled functionality to regulator core. - Used more core features to simplify enable/disable functions. - Moved the devicetree binding to yaml. - Updated interrupt-names and simplified handling. Changes from v1: - Incorporated review comments from v1 - Changed from virtual-regulator based handling to individual regulator based handling. - Reworked the core to merge most of enable/disable functions, combine the regulator_ops into one and allow for future variations. - is_enabled() is now _really_ is_enabled() - Simplified the SC interrupt handling - use regmap_read_poll_timeout, REGULATOR_EVENT_OVER_CURRENT handling and notification to clients. Nisha Kumari (3): dt-bindings: regulator: Add labibb regulator arm64: dts: qcom: pmi8998: Add nodes for LAB and IBB regulators regulator: qcom: Add labibb driver Sumit Semwal (1): regulator: Allow regulators to verify enabled during enable() .../regulator/qcom-labibb-regulator.yaml | 70 +++ arch/arm64/boot/dts/qcom/pmi8998.dtsi | 12 ++ drivers/regulator/Kconfig | 10 + drivers/regulator/Makefile| 1 + drivers/regulator/core.c | 63 ++- drivers/regulator/qcom-labibb-regulator.c | 175 ++ include/linux/regulator/driver.h | 5 + 7 files changed, 335 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/regulator/qcom-labibb-regulator.yaml create mode 100644 drivers/regulator/qcom-labibb-regulator.c -- 2.27.0
[RESEND PATCH v5 4/4] regulator: qcom: Add labibb driver
From: Nisha Kumari
Qualcomm platforms have LAB(LCD AMOLED Boost)/IBB(Inverting Buck Boost)
regulators, labibb for short, which are used as power supply for
LCD Mode displays.
This patch adds labibb regulator driver for pmi8998 PMIC, found on
SDM845 platforms.
Signed-off-by: Nisha Kumari
[sumits: reworked the driver design as per upstream review]
Signed-off-by: Sumit Semwal
---
v5: sumits: review comments addressed
- removed dev_info about registering
- removed of_get_child_by_name()
- changed from using STATUS1 register to using ENABLE_CTL; this
allows us to use the regulator_*_regmap helpers and makes this
code cleaner. (In limited testing, STATUS1 seemed to report the
change faster than ENABLE_CTL, but in absence of mechanism to
validate if the regulator has indeed fully ramped when STATUS1
starts flagging, broonie suggested to use the slower ENABLE_CTL
path for safety).
v4: sumits: address review comments from v3, including cleaning up
register_labibb_regulator(), and adapted to updated meaning of
poll_enabled_time.
v3: sumits: addressed review comments from v2; moved to use core
regulator features like enable_time, off_on_delay, and the newly
added poll_enabled_time. Moved the check_enabled functionality
to core framework via poll_enabled_time.
v2: sumits: reworked the driver for more common code, and addressed
review comments from v1
---
drivers/regulator/Kconfig | 10 ++
drivers/regulator/Makefile| 1 +
drivers/regulator/qcom-labibb-regulator.c | 175 ++
3 files changed, 186 insertions(+)
create mode 100644 drivers/regulator/qcom-labibb-regulator.c
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 8f677f5d79b4..c6377df023bc 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -1178,5 +1178,15 @@ config REGULATOR_WM8994
This driver provides support for the voltage regulators on the
WM8994 CODEC.
+config REGULATOR_QCOM_LABIBB
+ tristate "QCOM LAB/IBB regulator support"
+ depends on SPMI || COMPILE_TEST
+ help
+ This driver supports Qualcomm's LAB/IBB regulators present on the
+ Qualcomm's PMIC chip pmi8998. QCOM LAB and IBB are SPMI
+ based PMIC implementations. LAB can be used as positive
+ boost regulator and IBB can be used as a negative boost regulator
+ for LCD display panel.
+
endif
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index e8f163371071..2c2b0861df76 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -88,6 +88,7 @@ obj-$(CONFIG_REGULATOR_MT6323)+= mt6323-regulator.o
obj-$(CONFIG_REGULATOR_MT6358) += mt6358-regulator.o
obj-$(CONFIG_REGULATOR_MT6380) += mt6380-regulator.o
obj-$(CONFIG_REGULATOR_MT6397) += mt6397-regulator.o
+obj-$(CONFIG_REGULATOR_QCOM_LABIBB) += qcom-labibb-regulator.o
obj-$(CONFIG_REGULATOR_QCOM_RPM) += qcom_rpm-regulator.o
obj-$(CONFIG_REGULATOR_QCOM_RPMH) += qcom-rpmh-regulator.o
obj-$(CONFIG_REGULATOR_QCOM_SMD_RPM) += qcom_smd-regulator.o
diff --git a/drivers/regulator/qcom-labibb-regulator.c
b/drivers/regulator/qcom-labibb-regulator.c
new file mode 100644
index ..8c7dd1928380
--- /dev/null
+++ b/drivers/regulator/qcom-labibb-regulator.c
@@ -0,0 +1,175 @@
+// SPDX-License-Identifier: GPL-2.0-only
+// Copyright (c) 2020, The Linux Foundation. All rights reserved.
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define REG_PERPH_TYPE 0x04
+
+#define QCOM_LAB_TYPE 0x24
+#define QCOM_IBB_TYPE 0x20
+
+#define PMI8998_LAB_REG_BASE 0xde00
+#define PMI8998_IBB_REG_BASE 0xdc00
+
+#define REG_LABIBB_STATUS1 0x08
+#define REG_LABIBB_ENABLE_CTL 0x46
+#define LABIBB_STATUS1_VREG_OK_BIT BIT(7)
+#define LABIBB_CONTROL_ENABLE BIT(7)
+
+#define LAB_ENABLE_CTL_MASKBIT(7)
+#define IBB_ENABLE_CTL_MASK(BIT(7) | BIT(6))
+
+#define LABIBB_OFF_ON_DELAY1000
+#define LAB_ENABLE_TIME(LABIBB_OFF_ON_DELAY * 2)
+#define IBB_ENABLE_TIME(LABIBB_OFF_ON_DELAY * 10)
+#define LABIBB_POLL_ENABLED_TIME 1000
+
+struct labibb_regulator {
+ struct regulator_desc desc;
+ struct device *dev;
+ struct regmap *regmap;
+ struct regulator_dev*rdev;
+ u16 base;
+ u8 type;
+};
+
+struct labibb_regulator_data {
+ const char *name;
+ u8 type;
+ u16 base;
+ struct regulator_desc *desc;
+};
+
+static struct regulator_ops qcom_labibb_ops = {
+
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-de...@lists.freedesktop.org > > L: linaro-mm-...@lists.linaro.org (moderated for non-subscribers) > > -- > > 2.20.1 > > > > ___ > > dri-devel mailing list > > dri-de...@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch Best, Sumit
[PATCH v5 1/4] regulator: Allow regulators to verify enabled during enable()
Some regulators might need to verify that they have indeed been enabled
after the enable() call is made and enable_time delay has passed.
This is implemented by repeatedly checking is_enabled() upto
poll_enabled_time, waiting for the already calculated enable delay in
each iteration.
Signed-off-by: Sumit Semwal
---
v3: addressed minor review comments, improved kernel doc
v2: Address review comments, including swapping enable_time and
poll_enabled_time.
---
drivers/regulator/core.c | 63 +++-
include/linux/regulator/driver.h | 5 +++
2 files changed, 67 insertions(+), 1 deletion(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 03154f5b939f..538a2779986a 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -2347,6 +2347,37 @@ static void _regulator_enable_delay(unsigned int delay)
udelay(us);
}
+/**
+ * _regulator_check_status_enabled
+ *
+ * A helper function to check if the regulator status can be interpreted
+ * as 'regulator is enabled'.
+ * @rdev: the regulator device to check
+ *
+ * Return:
+ * * 1 - if status shows regulator is in enabled state
+ * * 0 - if not enabled state
+ * * Error Value - as received from ops->get_status()
+ */
+static inline int _regulator_check_status_enabled(struct regulator_dev *rdev)
+{
+ int ret = rdev->desc->ops->get_status(rdev);
+
+ if (ret < 0) {
+ rdev_info(rdev, "get_status returned error: %d\n", ret);
+ return ret;
+ }
+
+ switch (ret) {
+ case REGULATOR_STATUS_OFF:
+ case REGULATOR_STATUS_ERROR:
+ case REGULATOR_STATUS_UNDEFINED:
+ return 0;
+ default:
+ return 1;
+ }
+}
+
static int _regulator_do_enable(struct regulator_dev *rdev)
{
int ret, delay;
@@ -2407,7 +2438,37 @@ static int _regulator_do_enable(struct regulator_dev
*rdev)
* together. */
trace_regulator_enable_delay(rdev_get_name(rdev));
- _regulator_enable_delay(delay);
+ /* If poll_enabled_time is set, poll upto the delay calculated
+* above, delaying poll_enabled_time uS to check if the regulator
+* actually got enabled.
+* If the regulator isn't enabled after enable_delay has
+* expired, return -ETIMEDOUT.
+*/
+ if (rdev->desc->poll_enabled_time) {
+ unsigned int time_remaining = delay;
+
+ while (time_remaining > 0) {
+ _regulator_enable_delay(rdev->desc->poll_enabled_time);
+
+ if (rdev->desc->ops->get_status) {
+ ret = _regulator_check_status_enabled(rdev);
+ if (ret < 0)
+ return ret;
+ else if (ret)
+ break;
+ } else if (rdev->desc->ops->is_enabled(rdev))
+ break;
+
+ time_remaining -= rdev->desc->poll_enabled_time;
+ }
+
+ if (time_remaining <= 0) {
+ rdev_err(rdev, "Enabled check timed out\n");
+ return -ETIMEDOUT;
+ }
+ } else {
+ _regulator_enable_delay(delay);
+ }
trace_regulator_enable_complete(rdev_get_name(rdev));
diff --git a/include/linux/regulator/driver.h b/include/linux/regulator/driver.h
index 7eb9fea8e482..436df3ba0b2a 100644
--- a/include/linux/regulator/driver.h
+++ b/include/linux/regulator/driver.h
@@ -305,6 +305,9 @@ enum regulator_type {
* @enable_time: Time taken for initial enable of regulator (in uS).
* @off_on_delay: guard time (in uS), before re-enabling a regulator
*
+ * @poll_enabled_time: The polling interval (in uS) to use while checking that
+ * the regulator was actually enabled. Max upto
enable_time.
+ *
* @of_map_mode: Maps a hardware mode defined in a DeviceTree to a standard
mode
*/
struct regulator_desc {
@@ -372,6 +375,8 @@ struct regulator_desc {
unsigned int off_on_delay;
+ unsigned int poll_enabled_time;
+
unsigned int (*of_map_mode)(unsigned int mode);
};
--
2.27.0
[PATCH v5 4/4] regulator: qcom: Add labibb driver
From: Nisha Kumari
Qualcomm platforms have LAB(LCD AMOLED Boost)/IBB(Inverting Buck Boost)
regulators, labibb for short, which are used as power supply for
LCD Mode displays.
This patch adds labibb regulator driver for pmi8998 PMIC, found on
SDM845 platforms.
Signed-off-by: Nisha Kumari
[sumits: reworked the driver design as per upstream review]
Signed-off-by: Sumit Semwal
---
v5: sumits: review comments addressed
- removed dev_info about registering
- removed of_get_child_by_name()
- changed from using STATUS1 register to using ENABLE_CTL; this
allows us to use the regulator_*_regmap helpers and makes this
code cleaner. (In limited testing, STATUS1 seemed to report the
change faster than ENABLE_CTL, but in absence of mechanism to
validate if the regulator has indeed fully ramped when STATUS1
starts flagging, broonie suggested to use the slower ENABLE_CTL
path for safety).
v4: sumits: address review comments from v3, including cleaning up
register_labibb_regulator(), and adapted to updated meaning of
poll_enabled_time.
v3: sumits: addressed review comments from v2; moved to use core
regulator features like enable_time, off_on_delay, and the newly
added poll_enabled_time. Moved the check_enabled functionality
to core framework via poll_enabled_time.
v2: sumits: reworked the driver for more common code, and addressed
review comments from v1
---
drivers/regulator/Kconfig | 10 ++
drivers/regulator/Makefile| 1 +
drivers/regulator/qcom-labibb-regulator.c | 175 ++
3 files changed, 186 insertions(+)
create mode 100644 drivers/regulator/qcom-labibb-regulator.c
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 8f677f5d79b4..c6377df023bc 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -1178,5 +1178,15 @@ config REGULATOR_WM8994
This driver provides support for the voltage regulators on the
WM8994 CODEC.
+config REGULATOR_QCOM_LABIBB
+ tristate "QCOM LAB/IBB regulator support"
+ depends on SPMI || COMPILE_TEST
+ help
+ This driver supports Qualcomm's LAB/IBB regulators present on the
+ Qualcomm's PMIC chip pmi8998. QCOM LAB and IBB are SPMI
+ based PMIC implementations. LAB can be used as positive
+ boost regulator and IBB can be used as a negative boost regulator
+ for LCD display panel.
+
endif
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index e8f163371071..2c2b0861df76 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -88,6 +88,7 @@ obj-$(CONFIG_REGULATOR_MT6323)+= mt6323-regulator.o
obj-$(CONFIG_REGULATOR_MT6358) += mt6358-regulator.o
obj-$(CONFIG_REGULATOR_MT6380) += mt6380-regulator.o
obj-$(CONFIG_REGULATOR_MT6397) += mt6397-regulator.o
+obj-$(CONFIG_REGULATOR_QCOM_LABIBB) += qcom-labibb-regulator.o
obj-$(CONFIG_REGULATOR_QCOM_RPM) += qcom_rpm-regulator.o
obj-$(CONFIG_REGULATOR_QCOM_RPMH) += qcom-rpmh-regulator.o
obj-$(CONFIG_REGULATOR_QCOM_SMD_RPM) += qcom_smd-regulator.o
diff --git a/drivers/regulator/qcom-labibb-regulator.c
b/drivers/regulator/qcom-labibb-regulator.c
new file mode 100644
index ..8c7dd1928380
--- /dev/null
+++ b/drivers/regulator/qcom-labibb-regulator.c
@@ -0,0 +1,175 @@
+// SPDX-License-Identifier: GPL-2.0-only
+// Copyright (c) 2020, The Linux Foundation. All rights reserved.
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define REG_PERPH_TYPE 0x04
+
+#define QCOM_LAB_TYPE 0x24
+#define QCOM_IBB_TYPE 0x20
+
+#define PMI8998_LAB_REG_BASE 0xde00
+#define PMI8998_IBB_REG_BASE 0xdc00
+
+#define REG_LABIBB_STATUS1 0x08
+#define REG_LABIBB_ENABLE_CTL 0x46
+#define LABIBB_STATUS1_VREG_OK_BIT BIT(7)
+#define LABIBB_CONTROL_ENABLE BIT(7)
+
+#define LAB_ENABLE_CTL_MASKBIT(7)
+#define IBB_ENABLE_CTL_MASK(BIT(7) | BIT(6))
+
+#define LABIBB_OFF_ON_DELAY1000
+#define LAB_ENABLE_TIME(LABIBB_OFF_ON_DELAY * 2)
+#define IBB_ENABLE_TIME(LABIBB_OFF_ON_DELAY * 10)
+#define LABIBB_POLL_ENABLED_TIME 1000
+
+struct labibb_regulator {
+ struct regulator_desc desc;
+ struct device *dev;
+ struct regmap *regmap;
+ struct regulator_dev*rdev;
+ u16 base;
+ u8 type;
+};
+
+struct labibb_regulator_data {
+ const char *name;
+ u8 type;
+ u16 base;
+ struct regulator_desc *desc;
+};
+
+static struct regulator_ops qcom_labibb_ops = {
+
[PATCH v5 3/4] arm64: dts: qcom: pmi8998: Add nodes for LAB and IBB regulators
From: Nisha Kumari
This patch adds devicetree nodes for LAB and IBB regulators.
Signed-off-by: Nisha Kumari
Signed-off-by: Sumit Semwal
[sumits: Updated for better compatible strings and names]
---
v5: sumits: removed interrupt-names, since there is only one
interrupt per node
v4: sumits: removed labibb label which is not needed
v3: sumits: updated interrupt-names as per review comments
v2: sumits: updated for better compatible string and names
---
arch/arm64/boot/dts/qcom/pmi8998.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/pmi8998.dtsi
b/arch/arm64/boot/dts/qcom/pmi8998.dtsi
index 23f9146a161e..d016b12967eb 100644
--- a/arch/arm64/boot/dts/qcom/pmi8998.dtsi
+++ b/arch/arm64/boot/dts/qcom/pmi8998.dtsi
@@ -25,5 +25,17 @@ pmi8998_lsid1: pmic@3 {
reg = <0x3 SPMI_USID>;
#address-cells = <1>;
#size-cells = <0>;
+
+ labibb {
+ compatible = "qcom,pmi8998-lab-ibb";
+
+ ibb: ibb {
+ interrupts = <0x3 0xdc 0x2
IRQ_TYPE_EDGE_RISING>;
+ };
+
+ lab: lab {
+ interrupts = <0x3 0xde 0x0
IRQ_TYPE_EDGE_RISING>;
+ };
+ };
};
};
--
2.27.0
[PATCH v5 2/4] dt-bindings: regulator: Add labibb regulator
From: Nisha Kumari
Adding the devicetree binding for labibb regulator.
Signed-off-by: Nisha Kumari
Signed-off-by: Sumit Semwal
[sumits: cleanup as per review comments and update to yaml]
---
v5: Addressed review comments - removed interrupt-names, changed to
dual license, added unevaluatedProperties: false
v4: fixed dt_binding_check issues
v3: moved to yaml
v2: updated for better compatible string and names.
---
.../regulator/qcom-labibb-regulator.yaml | 70 +++
1 file changed, 70 insertions(+)
create mode 100644
Documentation/devicetree/bindings/regulator/qcom-labibb-regulator.yaml
diff --git
a/Documentation/devicetree/bindings/regulator/qcom-labibb-regulator.yaml
b/Documentation/devicetree/bindings/regulator/qcom-labibb-regulator.yaml
new file mode 100644
index ..085cbd1ad8d0
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/qcom-labibb-regulator.yaml
@@ -0,0 +1,70 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/qcom-labibb-regulator.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm's LAB(LCD AMOLED Boost)/IBB(Inverting Buck Boost) Regulator
+
+maintainers:
+ - Sumit Semwal
+
+description:
+ LAB can be used as a positive boost power supply and IBB can be used as a
+ negative boost power supply for display panels. Currently implemented for
+ pmi8998.
+
+properties:
+ compatible:
+const: qcom,pmi8998-lab-ibb
+
+ lab:
+type: object
+
+properties:
+
+ interrupts:
+maxItems: 1
+description:
+ Short-circuit interrupt for lab.
+
+required:
+- interrupts
+
+ ibb:
+type: object
+
+properties:
+
+ interrupts:
+maxItems: 1
+description:
+ Short-circuit interrupt for lab.
+
+required:
+- interrupts
+
+required:
+ - compatible
+
+unevaluatedProperties: false
+
+examples:
+ - |
+#include
+
+labibb {
+ compatible = "qcom,pmi8998-lab-ibb";
+
+ lab {
+interrupts = <0x3 0x0 IRQ_TYPE_EDGE_RISING>;
+interrupt-names = "sc-err";
+ };
+
+ ibb {
+interrupts = <0x3 0x2 IRQ_TYPE_EDGE_RISING>;
+interrupt-names = "sc-err";
+ };
+};
+
+...
--
2.27.0
[PATCH v5 0/4] Qualcomm labibb regulator driver
This series adds a driver for LAB/IBB regulators found on some Qualcomm SoCs. These regulators provide positive and/or negative boost power supplies for LCD/LED display panels connected to the SoC. This series adds the support for pmi8998 PMIC found in SDM845 family of SoCs. Changes from v4: - v4 Review comments incorporated - simplified the driver: removed of_get_child_by_name(); use ENABLE_CTL register and switch over to use the regulator_*_regmap helpers - improved kerneldoc - From the dt-bindings, removed interrupt-names, changed to dual license, added unevaluatedProperties: false, removed interrupt-names, since there is only one interrupt per node - Since the Short Circuit handling needs more details from QC engineers, drop the SC handling patch from this series, to submit it later Changes from v3: - Handled review comments from v3 - In core, swapped the meaning of enable_time and poll_enabled_time; so we wait for total enable_time delay, and poll in-between at poll_enabled_time interval now. - fixed dt_bindings_check issues in dt-bindings patch. - Cleanup of register_labibb_regulator(), and adapted to updated meaning of poll_enabled_time. Changes from v2: - Review comments from v2 - Moved the poll-to-check-enabled functionality to regulator core. - Used more core features to simplify enable/disable functions. - Moved the devicetree binding to yaml. - Updated interrupt-names and simplified handling. Changes from v1: - Incorporated review comments from v1 - Changed from virtual-regulator based handling to individual regulator based handling. - Reworked the core to merge most of enable/disable functions, combine the regulator_ops into one and allow for future variations. - is_enabled() is now _really_ is_enabled() - Simplified the SC interrupt handling - use regmap_read_poll_timeout, REGULATOR_EVENT_OVER_CURRENT handling and notification to clients. Nisha Kumari (3): dt-bindings: regulator: Add labibb regulator arm64: dts: qcom: pmi8998: Add nodes for LAB and IBB regulators regulator: qcom: Add labibb driver Sumit Semwal (1): regulator: Allow regulators to verify enabled during enable() .../regulator/qcom-labibb-regulator.yaml | 70 +++ arch/arm64/boot/dts/qcom/pmi8998.dtsi | 12 ++ drivers/regulator/Kconfig | 10 + drivers/regulator/Makefile| 1 + drivers/regulator/core.c | 63 ++- drivers/regulator/qcom-labibb-regulator.c | 175 ++ include/linux/regulator/driver.h | 5 + 7 files changed, 335 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/regulator/qcom-labibb-regulator.yaml create mode 100644 drivers/regulator/qcom-labibb-regulator.c -- 2.27.0
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.
Re: [PATCH v4 4/5] regulator: qcom: Add labibb driver
On Wed, 17 Jun 2020 at 17:36, Mark Brown wrote: > > On Wed, Jun 17, 2020 at 05:27:12PM +0530, Sumit Semwal wrote: > > On Wed, 17 Jun 2020 at 17:17, Mark Brown wrote: > > > On Wed, Jun 17, 2020 at 05:12:35PM +0530, Sumit Semwal wrote: > > > > > I understand from a pure regulators' correctness point of view, > > > > ENABLE_CTL should be the one checked there, so I can change the patch > > > > as you suggested, but there seems to be some performance penalty > > > > there. > > > > I thought the goal was to have the performance penalty to ensure that > > > the regulator had actually started? > > > IMHO, with the poll_enabled_time mechanism added, we would not need to > > wait for the full enabled_time time for the regulator to get enabled, > > but we could poll (and potentially know earlier) if the regulator is > > enabled. > > The performance penalty I was talking, is about how should we check if > > the regulator is really enabled or not - via reading the STATUS1 > > register, which seems to tell the status a bit faster, or via reading > > the ENABLE_CTL register which we also use to enable/disable the > > regulator, but which seems to be slower in updating the status. > > That seems... interesting. Are you sure the regulator has fully ramped > when STATUS1 starts flagging? On a consumer device, I am not sure I have any way of checking that, but if there's some way you'd like me to validate it, I'll be happy to. > > > > > > > The WARN_ON? This was suggested by Bjorn to catch the case where the > > > > > > DT binding for a PMIC instantiates only one of the regulators. > > > > > > No, this whole loop - why this whole match and get child stuff? > > > > > This loop mechanism is what I saw in the other qcom regulators > > > > upstream, so thought it was an acceptable way. > > > > For the two children nodes, do you recommend another mechanism to get > > > > and validate both nodes? > > > > I don't understand what you mean by "two children nodes" here? > > > The two 'lab' and 'ibb' regulator nodes that are part of the labibb node. > > Use of_match and regulators_node like other regulator drivers. Ok, let me see what I can do with those; we still need to flag if some platform only instantiates one of the two lab/ibb regulators - I was given the impression they're 'both or none' case. Best, Sumit.
Re: [PATCH v4 5/5] regulator: qcom: labibb: Add SC interrupt handling
Hi Mark,
On Tue, 2 Jun 2020 at 17:52, Mark Brown wrote:
>
> On Tue, Jun 02, 2020 at 03:39:24PM +0530, Sumit Semwal wrote:
>
> > static int qcom_labibb_regulator_enable(struct regulator_dev *rdev)
> > {
> > - return regulator_enable_regmap(rdev);
> > + int ret;
> > + struct labibb_regulator *reg = rdev_get_drvdata(rdev);
> > +
> > + ret = regulator_enable_regmap(rdev);
> > + if (ret >= 0)
> > + reg->enabled = true;
>
> Can we not read the register we just wrote to here?
As I mentioned in the other patch, it seems there is a (noticeable)
delay in getting the value to reflect in this register for IBB.
Also, from the notes from the downstream driver (also copied below),
it seems like during short circuit there is another protection system
that can cause the registers to be cleared, hence the need to track
the current state in software.
>
> > + /*
> > + * The SC(short circuit) fault would trigger PBS(Portable Batch
> > + * System) to disable regulators for protection. This would
> > + * cause the SC_DETECT status being cleared so that it's not
> > + * able to get the SC fault status.
> > + * Check if the regulator is enabled in the driver but
> > + * disabled in hardware, this means a SC fault had happened
> > + * and SCP handling is completed by PBS.
> > + */
> > + if (!in_sc_err) {
> > +
> > + reg = labibb_reg->base + REG_LABIBB_ENABLE_CTL;
> > +
> > + ret = regmap_read_poll_timeout(labibb_reg->regmap,
> > + reg, val,
> > + !(val & LABIBB_CONTROL_ENABLE),
> > + POLLING_SCP_DONE_INTERVAL_US,
> > + POLLING_SCP_TIMEOUT);
>
> Why do we need a timeout here?
IMHO, This seems to be the time required by the PBS to actually
disable the regulator? If the PBS is not able to disable the
regulator, then it points to a more serious problem?
I'm sorry, that's just my understanding based on the downstream driver
:/ - not much input is available from the QC teams about it.
>
> > + NULL);
> > + regulator_unlock(labibb_reg->rdev);
> > + }
> > + return IRQ_HANDLED;
>
> This returns IRQ_HANDLED even if we didn't detect an interrupt source...
> Especially given the need to check to see if the regulator was turned
> off by the hardware it seems like there must be some false positives.
Right - I'm not sure what else can I do here.
>
> > + } else {
> > + ret = devm_request_threaded_irq(reg->dev,
> > + sc_irq,
> > + NULL, labibb_sc_err_handler,
> > + IRQF_ONESHOT,
> > + "sc-err", reg);
>
> This looks like we're requesting the interrupt before we register the
> regulator which means the interrupt might fire without the regulator
> being there. The order of registration should be reversed.
Agreed, and will update in the next version.
Best,
Sumit.
Re: [PATCH v4 4/5] regulator: qcom: Add labibb driver
On Wed, 17 Jun 2020 at 17:17, Mark Brown wrote: > > On Wed, Jun 17, 2020 at 05:12:35PM +0530, Sumit Semwal wrote: > > > I understand from a pure regulators' correctness point of view, > > ENABLE_CTL should be the one checked there, so I can change the patch > > as you suggested, but there seems to be some performance penalty > > there. > > I thought the goal was to have the performance penalty to ensure that > the regulator had actually started? IMHO, with the poll_enabled_time mechanism added, we would not need to wait for the full enabled_time time for the regulator to get enabled, but we could poll (and potentially know earlier) if the regulator is enabled. The performance penalty I was talking, is about how should we check if the regulator is really enabled or not - via reading the STATUS1 register, which seems to tell the status a bit faster, or via reading the ENABLE_CTL register which we also use to enable/disable the regulator, but which seems to be slower in updating the status. > > > > > The WARN_ON? This was suggested by Bjorn to catch the case where the > > > > DT binding for a PMIC instantiates only one of the regulators. > > > > No, this whole loop - why this whole match and get child stuff? > > > This loop mechanism is what I saw in the other qcom regulators > > upstream, so thought it was an acceptable way. > > For the two children nodes, do you recommend another mechanism to get > > and validate both nodes? > > I don't understand what you mean by "two children nodes" here? The two 'lab' and 'ibb' regulator nodes that are part of the labibb node. Best, Sumit.
Re: [PATCH v4 4/5] regulator: qcom: Add labibb driver
Hello Mark,
On Tue, 2 Jun 2020 at 17:55, Mark Brown wrote:
>
> On Tue, Jun 02, 2020 at 05:40:45PM +0530, Sumit Semwal wrote:
> > On Tue, 2 Jun 2020 at 17:02, Mark Brown wrote:
> > > On Tue, Jun 02, 2020 at 03:39:23PM +0530, Sumit Semwal wrote:
>
> > > This should be a get_status() callback...
>
> > From my (limited) understanding of downstream code, it seemed like for
> > this set of regulators, the 'enabled' check is done via the
> > 'REG_LABIBB_STATUS1 reg; for some reason, not via the same enable_reg
> > / enable_mask ones. That's why I used it as is_enabled() callback.
> > I will try and check with the QC folks to clarify this point about
> > their hardware.
>
> The way this is functioning at the minute the downstream code is just
> buggy.
Apologies for the delay in responding - I pinged the QC folks, and was
waiting for their reply but haven't got any response so far.
I tried your suggestion to use the ENABLE_CTL register for checking if
the regulator is actually enabled. In my limited testing on the Poco,
it seems like the STATUS1 register updates faster than the ENABLE_CTL
register, so on the device, I see noticeable lag when I use ENABLE_CTL
for is_enabled() check. [This is especially true for the IBB, which
takes longer to become usable than the LAB regulator.]
I understand from a pure regulators' correctness point of view,
ENABLE_CTL should be the one checked there, so I can change the patch
as you suggested, but there seems to be some performance penalty
there.
>
> > > ...is_enabled() should just be regulator_is_enabled_regmap() and these
> > > functions should just be removed entirely, you can use the regmap
> > > operations directly as the ops without the wrapper.
>
> > The 2 wrappers are a precursor to the next patch, where we keep track
> > of regulator's enable status to check during SC handling.
>
> Add the functions when they're useful, not before. TBH if the register
> is write only you're probably better off adding a register cache.
Agreed, I will remove the wrappers from here, using the regmap
functions, and add the wrappers with the SC handling patch.
>
> > > > + match = of_match_device(qcom_labibb_match, >dev);
> > > > + if (!match)
> > > > + return -ENODEV;
> > > > +
> > > > + for (reg_data = match->data; reg_data->name; reg_data++) {
> > > > + child = of_get_child_by_name(pdev->dev.of_node,
> > > > reg_data->name);
> > > > +
> > > > + if (WARN_ON(child == NULL))
> > > > + return -EINVAL;
> > >
> > > This feels like the DT bindings are confused - why do we need to search
> > > like this?
>
> > The WARN_ON? This was suggested by Bjorn to catch the case where the
> > DT binding for a PMIC instantiates only one of the regulators.
>
> No, this whole loop - why this whole match and get child stuff?
This loop mechanism is what I saw in the other qcom regulators
upstream, so thought it was an acceptable way.
For the two children nodes, do you recommend another mechanism to get
and validate both nodes?
Best,
Sumit.
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.
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.
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
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.
[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
Re: [PATCH v4 4/5] regulator: qcom: Add labibb driver
Hi Mark,
Thank you very much for reviewing.
On Tue, 2 Jun 2020 at 17:02, Mark Brown wrote:
>
> On Tue, Jun 02, 2020 at 03:39:23PM +0530, Sumit Semwal wrote:
>
> > +static int qcom_labibb_regulator_is_enabled(struct regulator_dev *rdev)
> > +{
> > + int ret;
> > + unsigned int val;
> > + struct labibb_regulator *reg = rdev_get_drvdata(rdev);
> > +
> > + ret = regmap_read(reg->regmap, reg->base + REG_LABIBB_STATUS1, );
> > + if (ret < 0) {
> > + dev_err(reg->dev, "Read register failed ret = %d\n", ret);
> > + return ret;
> > + }
> > + return !!(val & LABIBB_STATUS1_VREG_OK_BIT);
> > +}
>
> This should be a get_status() callback...
>
>From my (limited) understanding of downstream code, it seemed like for
this set of regulators, the 'enabled' check is done via the
'REG_LABIBB_STATUS1 reg; for some reason, not via the same enable_reg
/ enable_mask ones. That's why I used it as is_enabled() callback.
I will try and check with the QC folks to clarify this point about
their hardware.
> > +static int qcom_labibb_regulator_enable(struct regulator_dev *rdev)
> > +{
> > + return regulator_enable_regmap(rdev);
> > +}
> > +
> > +static int qcom_labibb_regulator_disable(struct regulator_dev *rdev)
> > +{
> > + return regulator_disable_regmap(rdev);
> > +}
>
> ...is_enabled() should just be regulator_is_enabled_regmap() and these
> functions should just be removed entirely, you can use the regmap
> operations directly as the ops without the wrapper.
The 2 wrappers are a precursor to the next patch, where we keep track
of regulator's enable status to check during SC handling.
>
> > + match = of_match_device(qcom_labibb_match, >dev);
> > + if (!match)
> > + return -ENODEV;
> > +
> > + for (reg_data = match->data; reg_data->name; reg_data++) {
> > + child = of_get_child_by_name(pdev->dev.of_node,
> > reg_data->name);
> > +
> > + if (WARN_ON(child == NULL))
> > + return -EINVAL;
>
> This feels like the DT bindings are confused - why do we need to search
> like this?
The WARN_ON? This was suggested by Bjorn to catch the case where the
DT binding for a PMIC instantiates only one of the regulators.
>
> > + dev_info(dev, "Registering %s regulator\n", child->full_name);
>
> This is noise, remove it. The regulator framework will announce new
> regulators anyway.
Agreed. will remove in the next iteration.
Best,
Sumit.
Re: [PATCH v4 1/5] regulator: Allow regulators to verify enabled during enable()
Hi Mark,
Thanks for the review!
On Tue, 2 Jun 2020 at 16:54, Mark Brown wrote:
>
> On Tue, Jun 02, 2020 at 03:39:20PM +0530, Sumit Semwal wrote:
>
> > +
> > + if (time_remaining <= 0) {
> > + rdev_err(rdev, "Enabled check failed.\n");
> > + return -ETIMEDOUT;
>
> s/failed/timed out/
Ack
>
> > + * @poll_enabled_time: Maximum time (in uS) to poll if the regulator is
> > + * actually enabled, after enable() call
> > + *
>
> This comment needs updating to reflect the new implementation.
Yes, I will update.
Best,
Sumit.
[PATCH v4 3/5] arm64: dts: qcom: pmi8998: Add nodes for LAB and IBB regulators
From: Nisha Kumari
This patch adds devicetree nodes for LAB and IBB regulators.
Signed-off-by: Nisha Kumari
Signed-off-by: Sumit Semwal
[sumits: Updated for better compatible strings and names]
--
v2: sumits: updated for better compatible string and names
v3: sumits: updated interrupt-names as per review comments
v4: sumits: removed labibb label
---
arch/arm64/boot/dts/qcom/pmi8998.dtsi | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/pmi8998.dtsi
b/arch/arm64/boot/dts/qcom/pmi8998.dtsi
index 23f9146a161e..3230b78b8048 100644
--- a/arch/arm64/boot/dts/qcom/pmi8998.dtsi
+++ b/arch/arm64/boot/dts/qcom/pmi8998.dtsi
@@ -25,5 +25,19 @@ pmi8998_lsid1: pmic@3 {
reg = <0x3 SPMI_USID>;
#address-cells = <1>;
#size-cells = <0>;
+
+ labibb {
+ compatible = "qcom,pmi8998-lab-ibb";
+
+ ibb: ibb {
+ interrupts = <0x3 0xdc 0x2
IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "sc-err";
+ };
+
+ lab: lab {
+ interrupts = <0x3 0xde 0x0
IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "sc-err";
+ };
+ };
};
};
--
2.26.2
[PATCH v4 1/5] regulator: Allow regulators to verify enabled during enable()
Some regulators might need to verify that they have indeed been enabled
after the enable() call is made and enable_time delay has passed.
This is implemented by repeatedly checking is_enabled() upto
poll_enabled_time, waiting for the already calculated enable delay in
each iteration.
Signed-off-by: Sumit Semwal
--
v2: Address review comments, including swapping enable_time and
poll_enabled_time.
---
drivers/regulator/core.c | 58 +++-
include/linux/regulator/driver.h | 5 +++
2 files changed, 62 insertions(+), 1 deletion(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 7486f6e4e613..d9ab888da95f 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -2347,6 +2347,32 @@ static void _regulator_enable_delay(unsigned int delay)
udelay(us);
}
+/* _regulator_check_status_enabled
+ *
+ * returns:
+ * 1 if status shows regulator is in enabled state
+ * 0 if not enabled state
+ * else, error value as received from ops->get_status()
+ */
+static inline int _regulator_check_status_enabled(struct regulator_dev *rdev)
+{
+ int ret = rdev->desc->ops->get_status(rdev);
+
+ if (ret < 0) {
+ rdev_info(rdev, "get_status returned error: %d\n", ret);
+ return ret;
+ }
+
+ switch (ret) {
+ case REGULATOR_STATUS_OFF:
+ case REGULATOR_STATUS_ERROR:
+ case REGULATOR_STATUS_UNDEFINED:
+ return 0;
+ default:
+ return 1;
+ }
+}
+
static int _regulator_do_enable(struct regulator_dev *rdev)
{
int ret, delay;
@@ -2407,7 +2433,37 @@ static int _regulator_do_enable(struct regulator_dev
*rdev)
* together. */
trace_regulator_enable_delay(rdev_get_name(rdev));
- _regulator_enable_delay(delay);
+ /* If poll_enabled_time is set, poll upto the delay calculated
+* above, delaying poll_enabled_time uS to check if the regulator
+* actually got enabled.
+* If the regulator isn't enabled after enable_delay has
+* expired, return -ETIMEDOUT.
+*/
+ if (rdev->desc->poll_enabled_time) {
+ unsigned int time_remaining = delay;
+
+ while (time_remaining > 0) {
+ _regulator_enable_delay(rdev->desc->poll_enabled_time);
+
+ if (rdev->desc->ops->get_status) {
+ ret = _regulator_check_status_enabled(rdev);
+ if (ret < 0)
+ return ret;
+ else if (ret)
+ break;
+ } else if (rdev->desc->ops->is_enabled(rdev))
+ break;
+
+ time_remaining -= rdev->desc->poll_enabled_time;
+ }
+
+ if (time_remaining <= 0) {
+ rdev_err(rdev, "Enabled check failed.\n");
+ return -ETIMEDOUT;
+ }
+ } else {
+ _regulator_enable_delay(delay);
+ }
trace_regulator_enable_complete(rdev_get_name(rdev));
diff --git a/include/linux/regulator/driver.h b/include/linux/regulator/driver.h
index 29d920516e0b..bb50e943010f 100644
--- a/include/linux/regulator/driver.h
+++ b/include/linux/regulator/driver.h
@@ -322,6 +322,9 @@ enum regulator_type {
* @enable_time: Time taken for initial enable of regulator (in uS).
* @off_on_delay: guard time (in uS), before re-enabling a regulator
*
+ * @poll_enabled_time: Maximum time (in uS) to poll if the regulator is
+ * actually enabled, after enable() call
+ *
* @of_map_mode: Maps a hardware mode defined in a DeviceTree to a standard
mode
*/
struct regulator_desc {
@@ -389,6 +392,8 @@ struct regulator_desc {
unsigned int off_on_delay;
+ unsigned int poll_enabled_time;
+
unsigned int (*of_map_mode)(unsigned int mode);
};
--
2.26.2
[PATCH v4 5/5] regulator: qcom: labibb: Add SC interrupt handling
From: Nisha Kumari
Add Short circuit interrupt handling and recovery for the lab and ibb
regulators on qcom platforms.
The client panel drivers need to register for REGULATOR_EVENT_OVER_CURRENT
notification which will be triggered on short circuit. They should
try to enable the regulator once, and if it doesn't get enabled,
handle shutting down the panel accordingly.
Signed-off-by: Nisha Kumari
Signed-off-by: Sumit Semwal
[sumits: updated to rework to use regmap_read_poll_timeout, handle it per
regulator, add REGULATOR_EVENT_OVER_CURRENT handling and
notification to clients and other cleanup]
--
v2: sumits: reworked handling to user regmap_read_poll_timeout, and handle it
per-regulator instead of clearing both lab and ibb errors on either irq
triggering. Also added REGULATOR_EVENT_OVER_CURRENT handling and
notification to clients.
v3: sumits: updated as per review comments of v2: removed spurious check for
irq in handler and some unused variables; inlined some of the code,
omitted IRQF_TRIGGER_RISING as it's coming from DT.
v4: sumits: updated 'int vreg_enabled' to 'boot enabled', made sc_irq a local
var
and other review comments from v3.
---
drivers/regulator/qcom-labibb-regulator.c | 102 +-
1 file changed, 99 insertions(+), 3 deletions(-)
diff --git a/drivers/regulator/qcom-labibb-regulator.c
b/drivers/regulator/qcom-labibb-regulator.c
index 33b764ac69d1..bca0308b26dd 100644
--- a/drivers/regulator/qcom-labibb-regulator.c
+++ b/drivers/regulator/qcom-labibb-regulator.c
@@ -1,6 +1,7 @@
// SPDX-License-Identifier: GPL-2.0-only
// Copyright (c) 2020, The Linux Foundation. All rights reserved.
+#include
#include
#include
#include
@@ -18,6 +19,7 @@
#define REG_LABIBB_ENABLE_CTL 0x46
#define LABIBB_STATUS1_VREG_OK_BIT BIT(7)
#define LABIBB_CONTROL_ENABLE BIT(7)
+#define LABIBB_STATUS1_SC_DETECT_BIT BIT(6)
#define LAB_ENABLE_CTL_MASKBIT(7)
#define IBB_ENABLE_CTL_MASK(BIT(7) | BIT(6))
@@ -27,12 +29,16 @@
#define IBB_ENABLE_TIME(LABIBB_OFF_ON_DELAY * 10)
#define LABIBB_POLL_ENABLED_TIME 1000
+#define POLLING_SCP_DONE_INTERVAL_US 5000
+#define POLLING_SCP_TIMEOUT16000
+
struct labibb_regulator {
struct regulator_desc desc;
struct device *dev;
struct regmap *regmap;
struct regulator_dev*rdev;
u16 base;
+ boolenabled;
u8 type;
};
@@ -59,12 +65,26 @@ static int qcom_labibb_regulator_is_enabled(struct
regulator_dev *rdev)
static int qcom_labibb_regulator_enable(struct regulator_dev *rdev)
{
- return regulator_enable_regmap(rdev);
+ int ret;
+ struct labibb_regulator *reg = rdev_get_drvdata(rdev);
+
+ ret = regulator_enable_regmap(rdev);
+ if (ret >= 0)
+ reg->enabled = true;
+
+ return ret;
}
static int qcom_labibb_regulator_disable(struct regulator_dev *rdev)
{
- return regulator_disable_regmap(rdev);
+ int ret = 0;
+ struct labibb_regulator *reg = rdev_get_drvdata(rdev);
+
+ ret = regulator_disable_regmap(rdev);
+ if (ret >= 0)
+ reg->enabled = false;
+
+ return ret;
}
static struct regulator_ops qcom_labibb_ops = {
@@ -73,12 +93,70 @@ static struct regulator_ops qcom_labibb_ops = {
.is_enabled = qcom_labibb_regulator_is_enabled,
};
+static irqreturn_t labibb_sc_err_handler(int irq, void *_reg)
+{
+ int ret;
+ u16 reg;
+ unsigned int val;
+ struct labibb_regulator *labibb_reg = _reg;
+ bool in_sc_err, scp_done = false;
+
+ ret = regmap_read(labibb_reg->regmap,
+ labibb_reg->base + REG_LABIBB_STATUS1, );
+ if (ret < 0) {
+ dev_err(labibb_reg->dev, "sc_err_irq: Read failed, ret=%d\n",
+ ret);
+ return IRQ_HANDLED;
+ }
+
+ dev_dbg(labibb_reg->dev, "%s SC error triggered! STATUS1 = %d\n",
+ labibb_reg->desc.name, val);
+
+ in_sc_err = !!(val & LABIBB_STATUS1_SC_DETECT_BIT);
+
+ /*
+* The SC(short circuit) fault would trigger PBS(Portable Batch
+* System) to disable regulators for protection. This would
+* cause the SC_DETECT status being cleared so that it's not
+* able to get the SC fault status.
+* Check if the regulator is enabled in the driver but
+* disabled in hardware, this means a SC fault had happened
+* and SCP handling is completed by PBS.
+*/
+ if (!in_sc_err) {
+
+ reg = labibb_reg->base + REG_LABIBB_ENABLE_CTL;
+
+ ret = regmap_read_poll_timeout(labibb_reg-
[PATCH v4 4/5] regulator: qcom: Add labibb driver
From: Nisha Kumari
Qualcomm platforms have LAB(LCD AMOLED Boost)/IBB(Inverting Buck Boost)
regulators, labibb for short, which are used as power supply for
LCD Mode displays.
This patch adds labibb regulator driver for pmi8998 PMIC, found on
SDM845 platforms.
Signed-off-by: Nisha Kumari
Signed-off-by: Sumit Semwal
[sumits: reworked to driver for more common code, using core regulator
features, and using newly-added poll_enabled_time functionality
from core]
--
v2: sumits: reworked the driver for more common code, and addressed
review comments from v1
v3: sumits: addressed review comments from v2; moved to use core
regulator features like enable_time, off_on_delay, and the newly
added poll_enabled_time. Moved the check_enabled functionality
to core framework via poll_enabled_time.
v4: sumits: address review comments from v3, including cleaning up
register_labibb_regulator(), and adapted to updated meaning of
poll_enabled_time.
---
drivers/regulator/Kconfig | 10 ++
drivers/regulator/Makefile| 1 +
drivers/regulator/qcom-labibb-regulator.c | 193 ++
3 files changed, 204 insertions(+)
create mode 100644 drivers/regulator/qcom-labibb-regulator.c
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index f4b72cb098ef..58704a9fd05d 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -1167,5 +1167,15 @@ config REGULATOR_WM8994
This driver provides support for the voltage regulators on the
WM8994 CODEC.
+config REGULATOR_QCOM_LABIBB
+ tristate "QCOM LAB/IBB regulator support"
+ depends on SPMI || COMPILE_TEST
+ help
+ This driver supports Qualcomm's LAB/IBB regulators present on the
+ Qualcomm's PMIC chip pmi8998. QCOM LAB and IBB are SPMI
+ based PMIC implementations. LAB can be used as positive
+ boost regulator and IBB can be used as a negative boost regulator
+ for LCD display panel.
+
endif
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 6610ee001d9a..5b313786c0e8 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -87,6 +87,7 @@ obj-$(CONFIG_REGULATOR_MT6323)+= mt6323-regulator.o
obj-$(CONFIG_REGULATOR_MT6358) += mt6358-regulator.o
obj-$(CONFIG_REGULATOR_MT6380) += mt6380-regulator.o
obj-$(CONFIG_REGULATOR_MT6397) += mt6397-regulator.o
+obj-$(CONFIG_REGULATOR_QCOM_LABIBB) += qcom-labibb-regulator.o
obj-$(CONFIG_REGULATOR_QCOM_RPM) += qcom_rpm-regulator.o
obj-$(CONFIG_REGULATOR_QCOM_RPMH) += qcom-rpmh-regulator.o
obj-$(CONFIG_REGULATOR_QCOM_SMD_RPM) += qcom_smd-regulator.o
diff --git a/drivers/regulator/qcom-labibb-regulator.c
b/drivers/regulator/qcom-labibb-regulator.c
new file mode 100644
index ..33b764ac69d1
--- /dev/null
+++ b/drivers/regulator/qcom-labibb-regulator.c
@@ -0,0 +1,194 @@
+// SPDX-License-Identifier: GPL-2.0-only
+// Copyright (c) 2020, The Linux Foundation. All rights reserved.
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define REG_PERPH_TYPE 0x04
+#define QCOM_LAB_TYPE 0x24
+#define QCOM_IBB_TYPE 0x20
+
+#define REG_LABIBB_STATUS1 0x08
+#define REG_LABIBB_ENABLE_CTL 0x46
+#define LABIBB_STATUS1_VREG_OK_BIT BIT(7)
+#define LABIBB_CONTROL_ENABLE BIT(7)
+
+#define LAB_ENABLE_CTL_MASKBIT(7)
+#define IBB_ENABLE_CTL_MASK(BIT(7) | BIT(6))
+
+#define LABIBB_OFF_ON_DELAY1000
+#define LAB_ENABLE_TIME(LABIBB_OFF_ON_DELAY * 2)
+#define IBB_ENABLE_TIME(LABIBB_OFF_ON_DELAY * 10)
+#define LABIBB_POLL_ENABLED_TIME 1000
+
+struct labibb_regulator {
+ struct regulator_desc desc;
+ struct device *dev;
+ struct regmap *regmap;
+ struct regulator_dev*rdev;
+ u16 base;
+ u8 type;
+};
+
+struct labibb_regulator_data {
+ u16 base;
+ const char *name;
+ u8 type;
+ unsigned intenable_time;
+ unsigned intenable_mask;
+};
+
+static int qcom_labibb_regulator_is_enabled(struct regulator_dev *rdev)
+{
+ int ret;
+ unsigned int val;
+ struct labibb_regulator *reg = rdev_get_drvdata(rdev);
+
+ ret = regmap_read(reg->regmap, reg->base + REG_LABIBB_STATUS1, );
+ if (ret < 0) {
+ dev_err(reg->dev, "Read register failed ret = %d\n", ret);
+ return ret;
+ }
+ return !!(val & LABIBB_STATUS1_VREG_OK_BIT);
+}
+
+static int qcom_labibb_regulator_enable(struct regulator_dev *rdev)
+{
+ return regulator_e
[PATCH v4 0/5] Qualcomm labibb regulator driver
This series adds a driver for LAB/IBB regulators found on some Qualcomm SoCs. These regulators provide positive and/or negative boost power supplies for LCD/LED display panels connected to the SoC. This series adds the support for pmi8998 PMIC found in SDM845 family of SoCs. Changes from v3: - Handled review comments from v3 - In core, swapped the meaning of enable_time and poll_enabled_time; so we wait for total enable_time delay, and poll in-between at poll_enabled_time interval now. - fixed dt_bindings_check issues in dt-bindings patch. - Cleanup of register_labibb_regulator(), and adapted to updated meaning of poll_enabled_time. Changes from v2: - Review comments from v2 - Moved the poll-to-check-enabled functionality to regulator core. - Used more core features to simplify enable/disable functions. - Moved the devicetree binding to yaml. - Updated interrupt-names and simplified handling. Changes from v1: - Incorporated review comments from v1 - Changed from virtual-regulator based handling to individual regulator based handling. - Reworked the core to merge most of enable/disable functions, combine the regulator_ops into one and allow for future variations. - is_enabled() is now _really_ is_enabled() - Simplified the SC interrupt handling - use regmap_read_poll_timeout, REGULATOR_EVENT_OVER_CURRENT handling and notification to clients. Nisha Kumari (4): dt-bindings: regulator: Add labibb regulator arm64: dts: qcom: pmi8998: Add nodes for LAB and IBB regulators regulator: qcom: Add labibb driver regulator: qcom: labibb: Add SC interrupt handling Sumit Semwal (1): regulator: Allow regulators to verify enabled during enable() .../regulator/qcom-labibb-regulator.yaml | 79 + arch/arm64/boot/dts/qcom/pmi8998.dtsi | 14 + drivers/regulator/Kconfig | 10 + drivers/regulator/Makefile| 1 + drivers/regulator/core.c | 58 +++- drivers/regulator/qcom-labibb-regulator.c | 289 ++ include/linux/regulator/driver.h | 5 + 7 files changed, 455 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/regulator/qcom-labibb-regulator.yaml create mode 100644 drivers/regulator/qcom-labibb-regulator.c -- 2.26.2
[PATCH v4 2/5] dt-bindings: regulator: Add labibb regulator
From: Nisha Kumari
Adding the devicetree binding for labibb regulator.
Signed-off-by: Nisha Kumari
Signed-off-by: Sumit Semwal
[sumits: cleanup as per review comments and update to yaml]
--
v2: updated for better compatible string and names.
v3: moved to yaml
v4: fixed dt_binding_check issues
---
.../regulator/qcom-labibb-regulator.yaml | 79 +++
1 file changed, 79 insertions(+)
create mode 100644
Documentation/devicetree/bindings/regulator/qcom-labibb-regulator.yaml
diff --git
a/Documentation/devicetree/bindings/regulator/qcom-labibb-regulator.yaml
b/Documentation/devicetree/bindings/regulator/qcom-labibb-regulator.yaml
new file mode 100644
index ..178820ec04c7
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/qcom-labibb-regulator.yaml
@@ -0,0 +1,79 @@
+# SPDX-License-Identifier: GPL-2.0-only
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/qcom-labibb-regulator.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm's LAB(LCD AMOLED Boost)/IBB(Inverting Buck Boost) Regulator
+
+maintainers:
+ - Sumit Semwal
+
+description:
+ LAB can be used as a positive boost power supply and IBB can be used as a
+ negative boost power supply for display panels. Currently implemented for
+ pmi8998.
+
+allOf:
+ - $ref: "regulator.yaml#"
+
+properties:
+ compatible:
+const: qcom,pmi8998-lab-ibb
+
+ lab:
+type: object
+
+properties:
+
+ interrupts:
+maxItems: 1
+description:
+ Short-circuit interrupt for lab.
+
+ interrupt-names:
+const: sc-err
+
+required:
+- interrupts
+- interrupt-names
+
+ ibb:
+type: object
+
+properties:
+
+ interrupts:
+maxItems: 1
+description:
+ Short-circuit interrupt for lab.
+
+ interrupt-names:
+const: sc-err
+
+required:
+- interrupts
+- interrupt-names
+
+required:
+ - compatible
+
+examples:
+ - |
+#include
+
+labibb {
+ compatible = "qcom,pmi8998-lab-ibb";
+
+ lab {
+interrupts = <0x3 0x0 IRQ_TYPE_EDGE_RISING>;
+interrupt-names = "sc-err";
+ };
+
+ ibb {
+interrupts = <0x3 0x2 IRQ_TYPE_EDGE_RISING>;
+interrupt-names = "sc-err";
+ };
+};
+
+...
--
2.26.2
[PATCH v3 4/5] regulator: qcom: Add labibb driver
From: Nisha Kumari
Qualcomm platforms have LAB(LCD AMOLED Boost)/IBB(Inverting Buck Boost)
regulators, labibb for short, which are used as power supply for
LCD Mode displays.
This patch adds labibb regulator driver for pmi8998 PMIC, found on
SDM845 platforms.
Signed-off-by: Nisha Kumari
Signed-off-by: Sumit Semwal
--
v2: sumits: reworked the driver for more common code, and addressed
review comments from v1
v3: sumits: addressed review comments from v2; moved to use core
regulator features like enable_time, off_on_delay, and the newly
added poll_enabled_time. Moved the check_enabled functionality
to core framework via poll_enabled_time.
---
drivers/regulator/Kconfig | 10 +
drivers/regulator/Makefile| 1 +
drivers/regulator/qcom-labibb-regulator.c | 224 ++
3 files changed, 235 insertions(+)
create mode 100644 drivers/regulator/qcom-labibb-regulator.c
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index f4b72cb098ef..58704a9fd05d 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -1167,5 +1167,15 @@ config REGULATOR_WM8994
This driver provides support for the voltage regulators on the
WM8994 CODEC.
+config REGULATOR_QCOM_LABIBB
+ tristate "QCOM LAB/IBB regulator support"
+ depends on SPMI || COMPILE_TEST
+ help
+ This driver supports Qualcomm's LAB/IBB regulators present on the
+ Qualcomm's PMIC chip pmi8998. QCOM LAB and IBB are SPMI
+ based PMIC implementations. LAB can be used as positive
+ boost regulator and IBB can be used as a negative boost regulator
+ for LCD display panel.
+
endif
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 6610ee001d9a..5b313786c0e8 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -87,6 +87,7 @@ obj-$(CONFIG_REGULATOR_MT6323)+= mt6323-regulator.o
obj-$(CONFIG_REGULATOR_MT6358) += mt6358-regulator.o
obj-$(CONFIG_REGULATOR_MT6380) += mt6380-regulator.o
obj-$(CONFIG_REGULATOR_MT6397) += mt6397-regulator.o
+obj-$(CONFIG_REGULATOR_QCOM_LABIBB) += qcom-labibb-regulator.o
obj-$(CONFIG_REGULATOR_QCOM_RPM) += qcom_rpm-regulator.o
obj-$(CONFIG_REGULATOR_QCOM_RPMH) += qcom-rpmh-regulator.o
obj-$(CONFIG_REGULATOR_QCOM_SMD_RPM) += qcom_smd-regulator.o
diff --git a/drivers/regulator/qcom-labibb-regulator.c
b/drivers/regulator/qcom-labibb-regulator.c
new file mode 100644
index ..634d08461c6e
--- /dev/null
+++ b/drivers/regulator/qcom-labibb-regulator.c
@@ -0,0 +1,225 @@
+// SPDX-License-Identifier: GPL-2.0-only
+// Copyright (c) 2020, The Linux Foundation. All rights reserved.
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define REG_PERPH_TYPE 0x04
+#define QCOM_LAB_TYPE 0x24
+#define QCOM_IBB_TYPE 0x20
+
+#define REG_LABIBB_STATUS1 0x08
+#define REG_LABIBB_ENABLE_CTL 0x46
+#define LABIBB_STATUS1_VREG_OK_BIT BIT(7)
+#define LABIBB_CONTROL_ENABLE BIT(7)
+
+#define LAB_ENABLE_CTL_MASKBIT(7)
+#define IBB_ENABLE_CTL_MASK(BIT(7) | BIT(6))
+
+#define LABIBB_ENABLE_TIME 1000
+#define LAB_POLL_ENABLED_TIME (LABIBB_ENABLE_TIME * 2)
+#define IBB_POLL_ENABLED_TIME (LABIBB_ENABLE_TIME * 10)
+#define LABIBB_OFF_ON_DELAY(8200)
+
+struct labibb_regulator {
+ struct regulator_desc desc;
+ struct device *dev;
+ struct regmap *regmap;
+ struct regulator_dev*rdev;
+ u16 base;
+ u8 type;
+};
+
+struct labibb_regulator_data {
+ u16 base;
+ const char *name;
+ u8 type;
+ unsigned intpoll_enabled_time;
+};
+
+static int qcom_labibb_regulator_is_enabled(struct regulator_dev *rdev)
+{
+ int ret;
+ unsigned int val;
+ struct labibb_regulator *reg = rdev_get_drvdata(rdev);
+
+ ret = regmap_read(reg->regmap, reg->base + REG_LABIBB_STATUS1, );
+ if (ret < 0) {
+ dev_err(reg->dev, "Read register failed ret = %d\n", ret);
+ return ret;
+ }
+ return !!(val & LABIBB_STATUS1_VREG_OK_BIT);
+}
+
+static int qcom_labibb_regulator_enable(struct regulator_dev *rdev)
+{
+ int ret;
+ struct labibb_regulator *reg = rdev_get_drvdata(rdev);
+
+ ret = regulator_enable_regmap(rdev);
+ if (ret < 0)
+ dev_err(reg->dev, "Write failed: enable %s regulator\n",
+ reg->desc.name);
+
+ return ret;
+}
+
+static int qcom_labibb_regulator_disable(struct regulator_dev *rdev)
+{
+ int ret = 0;
+
[PATCH v3 5/5] regulator: qcom: labibb: Add SC interrupt handling
From: Nisha Kumari
Add Short circuit interrupt handling and recovery for the lab and
ibb regulators on qcom platforms.
The client panel drivers need to register for REGULATOR_EVENT_OVER_CURRENT
notification which will be triggered on short circuit. They should
try to enable the regulator once, and if it doesn't get enabled,
handle shutting down the panel accordingly.
Signed-off-by: Nisha Kumari
Signed-off-by: Sumit Semwal
--
v2: sumits: reworked handling to user regmap_read_poll_timeout, and handle it
per-regulator instead of clearing both lab and ibb errors on either irq
triggering. Also added REGULATOR_EVENT_OVER_CURRENT handling and
notification to clients.
v3: sumits: updated as per review comments of v2: removed spurious check for
irq in handler and some unused variables; inlined some of the code,
omitted IRQF_TRIGGER_RISING as it's coming from DT.
---
drivers/regulator/qcom-labibb-regulator.c | 92 +++
1 file changed, 92 insertions(+)
diff --git a/drivers/regulator/qcom-labibb-regulator.c
b/drivers/regulator/qcom-labibb-regulator.c
index 634d08461c6e..695ffac71e81 100644
--- a/drivers/regulator/qcom-labibb-regulator.c
+++ b/drivers/regulator/qcom-labibb-regulator.c
@@ -1,6 +1,7 @@
// SPDX-License-Identifier: GPL-2.0-only
// Copyright (c) 2020, The Linux Foundation. All rights reserved.
+#include
#include
#include
#include
@@ -18,6 +19,7 @@
#define REG_LABIBB_ENABLE_CTL 0x46
#define LABIBB_STATUS1_VREG_OK_BIT BIT(7)
#define LABIBB_CONTROL_ENABLE BIT(7)
+#define LABIBB_STATUS1_SC_DETECT_BIT BIT(6)
#define LAB_ENABLE_CTL_MASKBIT(7)
#define IBB_ENABLE_CTL_MASK(BIT(7) | BIT(6))
@@ -27,12 +29,17 @@
#define IBB_POLL_ENABLED_TIME (LABIBB_ENABLE_TIME * 10)
#define LABIBB_OFF_ON_DELAY(8200)
+#define POLLING_SCP_DONE_INTERVAL_US 5000
+#define POLLING_SCP_TIMEOUT16000
+
struct labibb_regulator {
struct regulator_desc desc;
struct device *dev;
struct regmap *regmap;
struct regulator_dev*rdev;
u16 base;
+ int sc_irq;
+ int vreg_enabled;
u8 type;
};
@@ -65,6 +72,8 @@ static int qcom_labibb_regulator_enable(struct regulator_dev
*rdev)
if (ret < 0)
dev_err(reg->dev, "Write failed: enable %s regulator\n",
reg->desc.name);
+ else
+ reg->vreg_enabled = 1;
return ret;
}
@@ -78,6 +87,8 @@ static int qcom_labibb_regulator_disable(struct regulator_dev
*rdev)
if (ret < 0)
dev_err(reg->dev, "Disable failed: disable %s\n",
reg->desc.name);
+ else
+ reg->vreg_enabled = 0;
return ret;
}
@@ -88,11 +99,70 @@ static struct regulator_ops qcom_labibb_ops = {
.is_enabled = qcom_labibb_regulator_is_enabled,
};
+static irqreturn_t labibb_sc_err_handler(int irq, void *_reg)
+{
+ int ret;
+ u16 reg;
+ unsigned int val;
+ struct labibb_regulator *labibb_reg = _reg;
+ bool in_sc_err, scp_done = false;
+
+ ret = regmap_read(labibb_reg->regmap,
+ labibb_reg->base + REG_LABIBB_STATUS1, );
+ if (ret < 0) {
+ dev_err(labibb_reg->dev, "sc_err_irq: Read failed, ret=%d\n",
+ ret);
+ return IRQ_HANDLED;
+ }
+
+ dev_dbg(labibb_reg->dev, "%s SC error triggered! STATUS1 = %d\n",
+ labibb_reg->desc.name, val);
+
+ in_sc_err = !!(val & LABIBB_STATUS1_SC_DETECT_BIT);
+
+ /*
+* The SC(short circuit) fault would trigger PBS(Portable Batch
+* System) to disable regulators for protection. This would
+* cause the SC_DETECT status being cleared so that it's not
+* able to get the SC fault status.
+* Check if the regulator is enabled in the driver but
+* disabled in hardware, this means a SC fault had happened
+* and SCP handling is completed by PBS.
+*/
+ if (!in_sc_err) {
+
+ reg = labibb_reg->base + REG_LABIBB_ENABLE_CTL;
+
+ ret = regmap_read_poll_timeout(labibb_reg->regmap,
+ reg, val,
+ !(val & LABIBB_CONTROL_ENABLE),
+ POLLING_SCP_DONE_INTERVAL_US,
+ POLLING_SCP_TIMEOUT);
+
+ if (!ret && labibb_reg->vreg_enabled) {
+ dev_dbg(labibb_reg->dev,
+ "%s has been disabled by SCP\n",
+
[PATCH v3 3/5] arm64: dts: qcom: pmi8998: Add nodes for LAB and IBB regulators
From: Nisha Kumari
This patch adds devicetree nodes for LAB and IBB regulators.
Signed-off-by: Nisha Kumari
Signed-off-by: Sumit Semwal
--
v2: sumits: updated for better compatible string and names
v3: sumits: updated interrupt-names as per review comments
---
arch/arm64/boot/dts/qcom/pmi8998.dtsi | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/pmi8998.dtsi
b/arch/arm64/boot/dts/qcom/pmi8998.dtsi
index 23f9146a161e..1a72fe92f1a6 100644
--- a/arch/arm64/boot/dts/qcom/pmi8998.dtsi
+++ b/arch/arm64/boot/dts/qcom/pmi8998.dtsi
@@ -25,5 +25,19 @@ pmi8998_lsid1: pmic@3 {
reg = <0x3 SPMI_USID>;
#address-cells = <1>;
#size-cells = <0>;
+
+ labibb: labibb {
+ compatible = "qcom,pmi8998-lab-ibb";
+
+ ibb: ibb {
+ interrupts = <0x3 0xdc 0x2
IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "sc-err";
+ };
+
+ lab: lab {
+ interrupts = <0x3 0xde 0x0
IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "sc-err";
+ };
+ };
};
};
--
2.26.2
[PATCH v3 1/5] regulator: Allow regulators to verify enabled during enable()
Some regulators might need to verify that they have indeed been enabled
after the enable() call is made and enable_time delay has passed.
This is implemented by repeatedly checking is_enabled() upto
poll_enabled_time, waiting for the already calculated enable delay in
each iteration.
Signed-off-by: Sumit Semwal
---
drivers/regulator/core.c | 28
include/linux/regulator/driver.h | 5 +
2 files changed, 33 insertions(+)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 7486f6e4e613..06199f182114 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -2409,6 +2409,34 @@ static int _regulator_do_enable(struct regulator_dev
*rdev)
_regulator_enable_delay(delay);
+ /* If set, poll upto poll_enabled_time uS to see if the regulator
+* actually got enabled.
+* For each iteration, wait for the enable_time delay calculated
+* above already.
+* If the regulator isn't enabled after poll_enabled_time has
+* expired, return -ETIMEDOUT.
+*/
+ if (rdev->desc->poll_enabled_time) {
+ unsigned int time_remaining = rdev->desc->poll_enabled_time;
+
+ while (time_remaining > 0) {
+ /* We've already waited for enable_time above;
+* so we can start with immediate check of the
+* status of the regulator.
+*/
+ if (rdev->desc->ops->is_enabled(rdev))
+ break;
+
+ _regulator_enable_delay(delay);
+ time_remaining -= delay;
+ }
+
+ if (time_remaining <= 0) {
+ rdev_err(rdev, "Enabled check failed.\n");
+ return -ETIMEDOUT;
+ }
+ }
+
trace_regulator_enable_complete(rdev_get_name(rdev));
return 0;
diff --git a/include/linux/regulator/driver.h b/include/linux/regulator/driver.h
index 29d920516e0b..bb50e943010f 100644
--- a/include/linux/regulator/driver.h
+++ b/include/linux/regulator/driver.h
@@ -322,6 +322,9 @@ enum regulator_type {
* @enable_time: Time taken for initial enable of regulator (in uS).
* @off_on_delay: guard time (in uS), before re-enabling a regulator
*
+ * @poll_enabled_time: Maximum time (in uS) to poll if the regulator is
+ * actually enabled, after enable() call
+ *
* @of_map_mode: Maps a hardware mode defined in a DeviceTree to a standard
mode
*/
struct regulator_desc {
@@ -389,6 +392,8 @@ struct regulator_desc {
unsigned int off_on_delay;
+ unsigned int poll_enabled_time;
+
unsigned int (*of_map_mode)(unsigned int mode);
};
--
2.26.2
[PATCH v3 0/5] Qualcomm labibb regulator driver
This series adds a driver for LAB/IBB regulators found on some Qualcomm SoCs. These regulators provide positive and/or negative boost power supplies for LCD/LED display panels connected to the SoC. This series adds the support for pmi8998 PMIC found in SDM845 family of SoCs. Changes from v2: - Review comments from v2 - Moved the poll-to-check-enabled functionality to regulator core. - Used more core features to simplify enable/disable functions. - Moved the devicetree binding to yaml. - Updated interrupt-names and simplified handling. Changes from v1: - Incorporated review comments from v1 - Changed from virtual-regulator based handling to individual regulator based handling. - Reworked the core to merge most of enable/disable functions, combine the regulator_ops into one and allow for future variations. - is_enabled() is now _really_ is_enabled() - Simplified the SC interrupt handling - use regmap_read_poll_timeout, REGULATOR_EVENT_OVER_CURRENT handling and notification to clients. Nisha Kumari (4): dt-bindings: regulator: Add labibb regulator arm64: dts: qcom: pmi8998: Add nodes for LAB and IBB regulators regulator: qcom: Add labibb driver regulator: qcom: labibb: Add SC interrupt handling Sumit Semwal (1): regulator: Allow regulators to verify enabled during enable() .../regulator/qcom-labibb-regulator.yaml | 63 arch/arm64/boot/dts/qcom/pmi8998.dtsi | 14 + drivers/regulator/Kconfig | 10 + drivers/regulator/Makefile| 1 + drivers/regulator/core.c | 28 ++ drivers/regulator/qcom-labibb-regulator.c | 316 ++ include/linux/regulator/driver.h | 5 + 7 files changed, 437 insertions(+) create mode 100644 Documentation/devicetree/bindings/regulator/qcom-labibb-regulator.yaml create mode 100644 drivers/regulator/qcom-labibb-regulator.c -- 2.26.2
[PATCH v3 2/5] dt-bindings: regulator: Add labibb regulator
From: Nisha Kumari
Adding the devicetree binding for labibb regulator.
Signed-off-by: Nisha Kumari
Signed-off-by: Sumit Semwal
--
v2: updated for better compatible string and names.
v3: moved to yaml
---
.../regulator/qcom-labibb-regulator.yaml | 63 +++
1 file changed, 63 insertions(+)
create mode 100644
Documentation/devicetree/bindings/regulator/qcom-labibb-regulator.yaml
diff --git
a/Documentation/devicetree/bindings/regulator/qcom-labibb-regulator.yaml
b/Documentation/devicetree/bindings/regulator/qcom-labibb-regulator.yaml
new file mode 100644
index ..5406601ecd65
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/qcom-labibb-regulator.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: GPL-2.0-only
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/qcom-labibb-regulator.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm's LAB(LCD AMOLED Boost)/IBB(Inverting Buck Boost) Regulator
+
+maintainers:
+ - Sumit Semwal
+
+description:
+ LAB can be used as a positive boost power supply and IBB can be used as a
+ negative boost power supply for display panels. Currently implemented for
+ pmi8998.
+
+allOf:
+ - $ref: "regulator.yaml#"
+
+properties:
+ compatible:
+const: qcom,pmi8998-lab-ibb
+
+ lab:
+type: object
+interrupts:
+ items:
+- description: Short-circuit interrupt for lab.
+interrupt-names:
+ maxItems: 1
+ items:
+- const: sc-err
+
+ ibb:
+type: object
+interrupts:
+ items:
+- description: Short-circuit interrupt for lab.
+interrupt-names:
+ maxItems: 1
+ items:
+- const: sc-err
+
+required:
+ - compatible
+
+examples:
+ pmi8998_lsid1: pmic@3 {
+ labibb {
+ compatible = "qcom,pmi8998-lab-ibb";
+
+ lab: lab {
+ interrupts = <0x3 0xde 0x0
IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "lab-sc-err";
+ };
+
+ ibb: ibb {
+ interrupts = <0x3 0xdc 0x2
IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "ibb-sc-err";
+ };
+
+ };
+ };
--
2.26.2
Re: [v2 3/4] regulator: qcom: Add labibb driver
Hello Mark,
On Thu, 14 May 2020 at 16:57, Sumit Semwal wrote:
>
> Hello Mark,
>
> Thank you for your review comments!
> On Mon, 11 May 2020 at 16:09, Mark Brown wrote:
> >
> > On Sat, May 09, 2020 at 02:11:59AM +0530, Sumit Semwal wrote:
> >
> > > + ret = regmap_bulk_read(reg->regmap, reg->base +
> > > +REG_LABIBB_STATUS1, , 1);
> > > + if (ret < 0) {
> > > + dev_err(reg->dev, "Read register failed ret = %d\n", ret);
> > > + return ret;
> > > + }
> >
> > Why a bulk read of a single register?
> Right, will change.
> >
> > > +static int _check_enabled_with_retries(struct regulator_dev *rdev,
> > > + int retries, int enabled)
> > > +{
> >
> > This is not retrying, this is polling to see if the regulator actually
> > enabled.
> Yes, will update accordingly.
>
> >
> > > +static int qcom_labibb_regulator_enable(struct regulator_dev *rdev)
> > > +{
> >
> > > + ret = _check_enabled_with_retries(rdev, retries, 1);
> > > + if (ret < 0) {
> > > + dev_err(reg->dev, "retries exhausted: enable %s
> > > regulator\n",
> > > + reg->desc.name);
> > > + return ret;
> > > + }
> >
> > If this is useful factor it out into a helper or the core, other devices
> > also have status bits saying if the regulator is enabled. It looks like
> > this may be mainly trying to open code something like enable_time, with
> > possibly some issues where the time taken to enable varies a lot.
> >
> Makes sense; I am not terribly familiar with the regulator core and
> helpers, so let me look and refactor accordingly.
Does something like this make sense, or did I misunderstand your
suggestion completely? I'll send the updated patches accordingly.
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -2353,6 +2353,7 @@ static int _regulator_do_enable(struct
regulator_dev *rdev)
+ /* If max_time_poll_enabled is set for the regulator,
+* Poll upto max_time_poll_enabled time to see if the regulator
+* actually got enabled.
+* For each iteration, wait for the enable_time delay calculated
+* above already.
+* If the regulator isn't enabled after max_time_poll_enabled has
+* expired, return -REG_ENABLED_CHECK_FAILED.
+*/
+ if (rdev->desc->max_time_poll_enabled) {
+ unsigned int remaining_time_to_poll =
rdev->desc->max_time_poll_enabled;
+
+ while (remaining_time_to_poll > 0) {
+ /* We've already waited for enable_time above;
+* so we can start with immediate check of the
+* status of the regulator.
+*/
+ if (rdev->desc->ops->is_enabled(rdev))
+ break;
+
+ _regulator_enable_delay(delay);
+ remaining_time_to_poll -= delay;
+ }
+
+ if (remaining_time_to_poll <= 0) {
+ rdev_err(rdev, "Enabled check failed.\n");
+ return -REG_ENABLED_CHECK_FAILED;
+ }
+ }
+
Since atleast in my use case, the delay is really enable_time (time
before we could check the status register), we could reuse the
already-calculated 'delay' based on enable_time?
>
Best,
Sumit.
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.
Re: [v2 4/4] regulator: qcom: labibb: Add SC interrupt handling
Hello Bjorn,
Thanks for the review comments.
On Tue, 12 May 2020 at 10:55, Bjorn Andersson
wrote:
>
> On Fri 08 May 13:42 PDT 2020, Sumit Semwal wrote:
>
> > From: Nisha Kumari
> >
> > Add Short circuit interrupt handling and recovery for the lab and
> > ibb regulators on qcom platforms.
> >
> > The client panel drivers need to register for REGULATOR_EVENT_OVER_CURRENT
> > notification which will be triggered on short circuit. They should
> > try to enable the regulator once, and if it doesn't get enabled,
> > handle shutting down the panel accordingly.
> >
> > Signed-off-by: Nisha Kumari
> > Signed-off-by: Sumit Semwal
> >
> > --
> > v2: sumits: reworked handling to user regmap_read_poll_timeout, and handle
> > it
> > per-regulator instead of clearing both lab and ibb errors on either irq
> > triggering. Also added REGULATOR_EVENT_OVER_CURRENT handling and
> > notification to clients.
> > ---
> > drivers/regulator/qcom-labibb-regulator.c | 103 +-
> > 1 file changed, 100 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/regulator/qcom-labibb-regulator.c
> > b/drivers/regulator/qcom-labibb-regulator.c
> > index a9dc7c060375..3539631c9f96 100644
> > --- a/drivers/regulator/qcom-labibb-regulator.c
> > +++ b/drivers/regulator/qcom-labibb-regulator.c
> > @@ -1,6 +1,7 @@
> > // SPDX-License-Identifier: GPL-2.0
> > // Copyright (c) 2019, The Linux Foundation. All rights reserved.
> >
> > +#include
> > #include
> > #include
> > #include
> > @@ -18,11 +19,15 @@
> > #define REG_LABIBB_ENABLE_CTL0x46
> > #define LABIBB_STATUS1_VREG_OK_BIT BIT(7)
> > #define LABIBB_CONTROL_ENABLEBIT(7)
> > +#define LABIBB_STATUS1_SC_DETECT_BIT BIT(6)
> >
> > #define LAB_ENABLE_CTL_MASK BIT(7)
> > #define IBB_ENABLE_CTL_MASK (BIT(7) | BIT(6))
> >
> > #define POWER_DELAY 8000
> > +#define POLLING_SCP_DONE_INTERVAL_US 5000
> > +#define POLLING_SCP_TIMEOUT 16000
> > +
> >
> > struct labibb_regulator {
> > struct regulator_desc desc;
> > @@ -30,6 +35,8 @@ struct labibb_regulator {
> > struct regmap *regmap;
> > struct regulator_dev*rdev;
> > u16 base;
> > + int sc_irq;
> > + int vreg_enabled;
> > u8 type;
> > };
> >
> > @@ -112,9 +119,10 @@ static int qcom_labibb_regulator_enable(struct
> > regulator_dev *rdev)
> > return ret;
> > }
> >
> > - if (ret)
> > + if (ret) {
> > + reg->vreg_enabled = 1;
> > return 0;
> > -
> > + }
> >
> > dev_err(reg->dev, "Can't enable %s\n", reg->desc.name);
> > return -EINVAL;
> > @@ -140,8 +148,10 @@ static int qcom_labibb_regulator_disable(struct
> > regulator_dev *rdev)
> > return ret;
> > }
> >
> > - if (!ret)
> > + if (!ret) {
> > + reg->vreg_enabled = 0;
> > return 0;
> > + }
> >
> > dev_err(reg->dev, "Can't disable %s\n", reg->desc.name);
> > return -EINVAL;
> > @@ -153,6 +163,70 @@ static struct regulator_ops qcom_labibb_ops = {
> > .is_enabled = qcom_labibb_regulator_is_enabled,
> > };
> >
> > +
> > +static irqreturn_t labibb_sc_err_handler(int irq, void *_reg)
> > +{
> > + int ret, count;
> > + u16 reg;
> > + u8 sc_err_mask;
> > + unsigned int val;
> > + struct labibb_regulator *labibb_reg = (struct labibb_regulator *)_reg;
>
> No need to explicitly typecast a void *.
ok.
>
> > + bool in_sc_err, reg_en, scp_done = false;
>
> reg_en is unused.
>
Yes, will remove.
> > +
> > + if (irq == labibb_reg->sc_irq)
>
> When is this false?
Shouldn't be; will remove the check.
>
> > + reg = labibb_reg->base + REG_LABIBB_STATUS1;
> > + else
> > + return IRQ_HANDLED;
> > +
> > + sc_err_mask = LABIBB_STATUS1_SC_DETECT_BIT;
> > +
> > + ret = regmap_bulk_read(labibb_reg->regmap, reg, , 1);
>
> Just inline reg->base + REG_LABIBB_STATUS1 in this call.
Ok.
>
> > + if (ret < 0)
Re: [v2 4/4] regulator: qcom: labibb: Add SC interrupt handling
Hello Mark,
Thanks for the review comments.
On Mon, 11 May 2020 at 16:19, Mark Brown wrote:
>
> On Sat, May 09, 2020 at 02:12:00AM +0530, Sumit Semwal wrote:
>
> > +static irqreturn_t labibb_sc_err_handler(int irq, void *_reg)
> > +{
> > + int ret, count;
> > + u16 reg;
> > + u8 sc_err_mask;
> > + unsigned int val;
> > + struct labibb_regulator *labibb_reg = (struct labibb_regulator *)_reg;
> > + bool in_sc_err, reg_en, scp_done = false;
> > +
> > + if (irq == labibb_reg->sc_irq)
> > + reg = labibb_reg->base + REG_LABIBB_STATUS1;
> > + else
> > + return IRQ_HANDLED;
>
> Why would we be registering the interrupt handler when it's not valid?
Agreed, will correct.
Best,
Sumit.
Re: [v2 1/4] dt-bindings: regulator: Add labibb regulator
Hello Bjorn,
Thanks for the comments!
On Tue, 12 May 2020 at 07:15, Bjorn Andersson
wrote:
>
> On Fri 08 May 13:41 PDT 2020, Sumit Semwal wrote:
>
> > From: Nisha Kumari
> >
> > Adding the devicetree binding for labibb regulator.
> >
> > Signed-off-by: Nisha Kumari
> > Signed-off-by: Sumit Semwal
>
> Sorry, I missed this when we talked about it. But please rewrite this in
> yaml.
Sure, I will.
>
> >
> > --
> > v2: updated for better compatible string and names.
> > ---
> > .../regulator/qcom-labibb-regulator.txt | 47 +++
> > 1 file changed, 47 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/regulator/qcom-labibb-regulator.txt
> >
> > diff --git
> > a/Documentation/devicetree/bindings/regulator/qcom-labibb-regulator.txt
> > b/Documentation/devicetree/bindings/regulator/qcom-labibb-regulator.txt
> > new file mode 100644
> > index ..6e639d69f780
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/regulator/qcom-labibb-regulator.txt
> > @@ -0,0 +1,47 @@
> > +Qualcomm's LAB(LCD AMOLED Boost)/IBB(Inverting Buck Boost) Regulator
> > +
> > +LAB can be used as a positive boost power supply and IBB can be used as a
> > negative
> > +boost power supply for display panels. Currently implemented for pmi8998.
> > +
> > +Main node required properties:
> > +
> > +- compatible:Must be:
> > + "qcom,pmi8998-lab-ibb"
> > +- #address-cells:Must be 1
> > +- #size-cells: Must be 0
>
> But the children doesn't have reg properties...
Oh, right. Let me correct that.
>
> > +
> > +LAB subnode required properties:
> > +
> > +- interrupts:Specify the interrupts as per the
> > interrupt
> > + encoding.
> > +- interrupt-names: Interrupt names to match up 1-to-1 with
> > + the interrupts specified in 'interrupts'
> > + property.
>
> Do specify the expected string (and given that you already have the
> lab & ibb subnodes, you don't need to include this in the string).
Yes, agreed. Keeping it as 'sc-err' makes the code easier too.
>
> Regards,
> Bjorn
Best,
Sumit.
>
> > +
> > +IBB subnode required properties:
> > +
> > +- interrupts:Specify the interrupts as per the
> > interrupt
> > + encoding.
> > +- interrupt-names: Interrupt names to match up 1-to-1 with
> > + the interrupts specified in 'interrupts'
> > + property.
> > +
> > +Example:
> > + pmi8998_lsid1: pmic@3 {
> > + labibb {
> > + compatible = "qcom,pmi8998-lab-ibb";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + lab: lab {
> > + interrupts = <0x3 0xde 0x0
> > IRQ_TYPE_EDGE_RISING>;
> > + interrupt-names = "lab-sc-err";
> > + };
> > +
> > + ibb: ibb {
> > + interrupts = <0x3 0xdc 0x2
> > IRQ_TYPE_EDGE_RISING>;
> > + interrupt-names = "ibb-sc-err";
> > + };
> > +
> > + };
> > + };
> > --
> > 2.26.2
> >
Re: [v2 3/4] regulator: qcom: Add labibb driver
Hello Bjorn,
Thanks very much for the review.
On Tue, 12 May 2020 at 07:46, Bjorn Andersson
wrote:
>
> On Fri 08 May 13:41 PDT 2020, Sumit Semwal wrote:
>
> > From: Nisha Kumari
> >
> > Qualcomm platforms have LAB(LCD AMOLED Boost)/IBB(Inverting Buck Boost)
> > Regulators, labibb for short, which are used as power supply for
>
> lowercase Regulators
ok.
>
> > LCD Mode displays.
> >
> > This patch adds labibb regulator driver for pmi8998 pmic, found on
>
> Uppercase PMIC
>
ok.
> > SDM845 platforms.
> >
> > Signed-off-by: Nisha Kumari
> > Signed-off-by: Sumit Semwal
> >
> > --
> > v2: sumits: reworked the driver for more common code, and addressed
> > review comments from v1. This includes merging regulator_ops into
> > one, and allowing for future labibb variations.
> > ---
> > drivers/regulator/Kconfig | 10 +
> > drivers/regulator/Makefile| 1 +
> > drivers/regulator/qcom-labibb-regulator.c | 288 ++
> > 3 files changed, 299 insertions(+)
> > create mode 100644 drivers/regulator/qcom-labibb-regulator.c
> >
> > diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
> > index f4b72cb098ef..58704a9fd05d 100644
> > --- a/drivers/regulator/Kconfig
> > +++ b/drivers/regulator/Kconfig
> > @@ -1167,5 +1167,15 @@ config REGULATOR_WM8994
> > This driver provides support for the voltage regulators on the
> > WM8994 CODEC.
> >
> > +config REGULATOR_QCOM_LABIBB
> > + tristate "QCOM LAB/IBB regulator support"
> > + depends on SPMI || COMPILE_TEST
> > + help
> > + This driver supports Qualcomm's LAB/IBB regulators present on the
> > + Qualcomm's PMIC chip pmi8998. QCOM LAB and IBB are SPMI
> > + based PMIC implementations. LAB can be used as positive
> > + boost regulator and IBB can be used as a negative boost regulator
> > + for LCD display panel.
> > +
> > endif
> >
> > diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
> > index 6610ee001d9a..5b313786c0e8 100644
> > --- a/drivers/regulator/Makefile
> > +++ b/drivers/regulator/Makefile
> > @@ -87,6 +87,7 @@ obj-$(CONFIG_REGULATOR_MT6323) += mt6323-regulator.o
> > obj-$(CONFIG_REGULATOR_MT6358) += mt6358-regulator.o
> > obj-$(CONFIG_REGULATOR_MT6380) += mt6380-regulator.o
> > obj-$(CONFIG_REGULATOR_MT6397) += mt6397-regulator.o
> > +obj-$(CONFIG_REGULATOR_QCOM_LABIBB) += qcom-labibb-regulator.o
> > obj-$(CONFIG_REGULATOR_QCOM_RPM) += qcom_rpm-regulator.o
> > obj-$(CONFIG_REGULATOR_QCOM_RPMH) += qcom-rpmh-regulator.o
> > obj-$(CONFIG_REGULATOR_QCOM_SMD_RPM) += qcom_smd-regulator.o
> > diff --git a/drivers/regulator/qcom-labibb-regulator.c
> > b/drivers/regulator/qcom-labibb-regulator.c
> > new file mode 100644
> > index ..a9dc7c060375
> > --- /dev/null
> > +++ b/drivers/regulator/qcom-labibb-regulator.c
> > @@ -0,0 +1,288 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +// Copyright (c) 2019, The Linux Foundation. All rights reserved.
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#define REG_PERPH_TYPE 0x04
> > +#define QCOM_LAB_TYPE0x24
> > +#define QCOM_IBB_TYPE0x20
> > +
> > +#define REG_LABIBB_STATUS1 0x08
> > +#define REG_LABIBB_ENABLE_CTL0x46
> > +#define LABIBB_STATUS1_VREG_OK_BIT BIT(7)
> > +#define LABIBB_CONTROL_ENABLEBIT(7)
> > +
> > +#define LAB_ENABLE_CTL_MASK BIT(7)
> > +#define IBB_ENABLE_CTL_MASK (BIT(7) | BIT(6))
> > +
> > +#define POWER_DELAY 8000
> > +
> > +struct labibb_regulator {
> > + struct regulator_desc desc;
> > + struct device *dev;
> > + struct regmap *regmap;
> > + struct regulator_dev*rdev;
> > + u16 base;
> > + u8 type;
> > +};
> > +
> > +struct qcom_labibb {
>
> You pretty much use this as a local variable within probe, and then you
> use labibb_regulator in runtime. Perhaps you can just drop it?
>
Yes, you're right. It's probably a leftover from the re-design. I will drop it.
> > + struct device *dev;
> > +
Re: [v2 3/4] regulator: qcom: Add labibb driver
Hello Mark,
Thank you for your review comments!
On Mon, 11 May 2020 at 16:09, Mark Brown wrote:
>
> On Sat, May 09, 2020 at 02:11:59AM +0530, Sumit Semwal wrote:
>
> > + ret = regmap_bulk_read(reg->regmap, reg->base +
> > +REG_LABIBB_STATUS1, , 1);
> > + if (ret < 0) {
> > + dev_err(reg->dev, "Read register failed ret = %d\n", ret);
> > + return ret;
> > + }
>
> Why a bulk read of a single register?
Right, will change.
>
> > +static int _check_enabled_with_retries(struct regulator_dev *rdev,
> > + int retries, int enabled)
> > +{
>
> This is not retrying, this is polling to see if the regulator actually
> enabled.
Yes, will update accordingly.
>
> > +static int qcom_labibb_regulator_enable(struct regulator_dev *rdev)
> > +{
>
> > + ret = _check_enabled_with_retries(rdev, retries, 1);
> > + if (ret < 0) {
> > + dev_err(reg->dev, "retries exhausted: enable %s regulator\n",
> > + reg->desc.name);
> > + return ret;
> > + }
>
> If this is useful factor it out into a helper or the core, other devices
> also have status bits saying if the regulator is enabled. It looks like
> this may be mainly trying to open code something like enable_time, with
> possibly some issues where the time taken to enable varies a lot.
>
Makes sense; I am not terribly familiar with the regulator core and
helpers, so let me look and refactor accordingly.
> > + if (ret)
> > + return 0;
> > +
> > +
> > + dev_err(reg->dev, "Can't enable %s\n", reg->desc.name);
> > + return -EINVAL;
>
> Return the actual error code (the logic here is quite convoluted).
Will try to simplify.
>
> > + ret = regulator_disable_regmap(rdev);
> > +
> > + if (ret < 0) {
>
> You have lots of blank lines between operations and checking their
> return codes?
>
will correct that.
> > + ret = _check_enabled_with_retries(rdev, retries, 0);
> > + if (ret < 0) {
> > + dev_err(reg->dev, "retries exhausted: disable %s regulator\n",
> > + reg->desc.name);
> > + return ret;
> > + }
>
> Similarly to the enable path, but is this one about off_on_delay rather
> than enable_time?
Got it. Let me look deeper.
>
> > + if (reg_data->type == QCOM_LAB_TYPE) {
> > + reg = >lab;
> > + reg->desc.enable_mask = LAB_ENABLE_CTL_MASK;
> > + } else {
> > + reg = >ibb;
> > + reg->desc.enable_mask = IBB_ENABLE_CTL_MASK;
> > + }
>
> Write a switch statement so this is extensible.
I can change over to switch, though in the current set of downstream
code I've seen, it doesn't look that it would get extended. But I
guess there isn't any harm in moving over to switch. Will do.
Best,
Sumit.
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
[v2 3/4] regulator: qcom: Add labibb driver
From: Nisha Kumari
Qualcomm platforms have LAB(LCD AMOLED Boost)/IBB(Inverting Buck Boost)
Regulators, labibb for short, which are used as power supply for
LCD Mode displays.
This patch adds labibb regulator driver for pmi8998 pmic, found on
SDM845 platforms.
Signed-off-by: Nisha Kumari
Signed-off-by: Sumit Semwal
--
v2: sumits: reworked the driver for more common code, and addressed
review comments from v1. This includes merging regulator_ops into
one, and allowing for future labibb variations.
---
drivers/regulator/Kconfig | 10 +
drivers/regulator/Makefile| 1 +
drivers/regulator/qcom-labibb-regulator.c | 288 ++
3 files changed, 299 insertions(+)
create mode 100644 drivers/regulator/qcom-labibb-regulator.c
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index f4b72cb098ef..58704a9fd05d 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -1167,5 +1167,15 @@ config REGULATOR_WM8994
This driver provides support for the voltage regulators on the
WM8994 CODEC.
+config REGULATOR_QCOM_LABIBB
+ tristate "QCOM LAB/IBB regulator support"
+ depends on SPMI || COMPILE_TEST
+ help
+ This driver supports Qualcomm's LAB/IBB regulators present on the
+ Qualcomm's PMIC chip pmi8998. QCOM LAB and IBB are SPMI
+ based PMIC implementations. LAB can be used as positive
+ boost regulator and IBB can be used as a negative boost regulator
+ for LCD display panel.
+
endif
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 6610ee001d9a..5b313786c0e8 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -87,6 +87,7 @@ obj-$(CONFIG_REGULATOR_MT6323)+= mt6323-regulator.o
obj-$(CONFIG_REGULATOR_MT6358) += mt6358-regulator.o
obj-$(CONFIG_REGULATOR_MT6380) += mt6380-regulator.o
obj-$(CONFIG_REGULATOR_MT6397) += mt6397-regulator.o
+obj-$(CONFIG_REGULATOR_QCOM_LABIBB) += qcom-labibb-regulator.o
obj-$(CONFIG_REGULATOR_QCOM_RPM) += qcom_rpm-regulator.o
obj-$(CONFIG_REGULATOR_QCOM_RPMH) += qcom-rpmh-regulator.o
obj-$(CONFIG_REGULATOR_QCOM_SMD_RPM) += qcom_smd-regulator.o
diff --git a/drivers/regulator/qcom-labibb-regulator.c
b/drivers/regulator/qcom-labibb-regulator.c
new file mode 100644
index ..a9dc7c060375
--- /dev/null
+++ b/drivers/regulator/qcom-labibb-regulator.c
@@ -0,0 +1,288 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2019, The Linux Foundation. All rights reserved.
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define REG_PERPH_TYPE 0x04
+#define QCOM_LAB_TYPE 0x24
+#define QCOM_IBB_TYPE 0x20
+
+#define REG_LABIBB_STATUS1 0x08
+#define REG_LABIBB_ENABLE_CTL 0x46
+#define LABIBB_STATUS1_VREG_OK_BIT BIT(7)
+#define LABIBB_CONTROL_ENABLE BIT(7)
+
+#define LAB_ENABLE_CTL_MASKBIT(7)
+#define IBB_ENABLE_CTL_MASK(BIT(7) | BIT(6))
+
+#define POWER_DELAY8000
+
+struct labibb_regulator {
+ struct regulator_desc desc;
+ struct device *dev;
+ struct regmap *regmap;
+ struct regulator_dev*rdev;
+ u16 base;
+ u8 type;
+};
+
+struct qcom_labibb {
+ struct device *dev;
+ struct regmap *regmap;
+ struct labibb_regulator lab;
+ struct labibb_regulator ibb;
+};
+
+struct labibb_regulator_data {
+ u16 base;
+ const char *name;
+ const char *irq_name;
+ u8 type;
+};
+
+static int qcom_labibb_regulator_is_enabled(struct regulator_dev *rdev)
+{
+ int ret;
+ u8 val;
+ struct labibb_regulator *reg = rdev_get_drvdata(rdev);
+
+ ret = regmap_bulk_read(reg->regmap, reg->base +
+ REG_LABIBB_STATUS1, , 1);
+ if (ret < 0) {
+ dev_err(reg->dev, "Read register failed ret = %d\n", ret);
+ return ret;
+ }
+
+ if (val & LABIBB_STATUS1_VREG_OK_BIT)
+ return 1;
+ else
+ return 0;
+}
+
+static int _check_enabled_with_retries(struct regulator_dev *rdev,
+ int retries, int enabled)
+{
+ int ret;
+ struct labibb_regulator *reg = rdev_get_drvdata(rdev);
+
+ while (retries--) {
+ /* Wait for a small period before checking REG_LABIBB_STATUS1 */
+ usleep_range(POWER_DELAY, POWER_DELAY + 200);
+
+ ret = qcom_labibb_regulator_is_enabled(rdev);
+
+ if (ret < 0) {
+ dev_err(reg-
[v2 4/4] regulator: qcom: labibb: Add SC interrupt handling
From: Nisha Kumari
Add Short circuit interrupt handling and recovery for the lab and
ibb regulators on qcom platforms.
The client panel drivers need to register for REGULATOR_EVENT_OVER_CURRENT
notification which will be triggered on short circuit. They should
try to enable the regulator once, and if it doesn't get enabled,
handle shutting down the panel accordingly.
Signed-off-by: Nisha Kumari
Signed-off-by: Sumit Semwal
--
v2: sumits: reworked handling to user regmap_read_poll_timeout, and handle it
per-regulator instead of clearing both lab and ibb errors on either irq
triggering. Also added REGULATOR_EVENT_OVER_CURRENT handling and
notification to clients.
---
drivers/regulator/qcom-labibb-regulator.c | 103 +-
1 file changed, 100 insertions(+), 3 deletions(-)
diff --git a/drivers/regulator/qcom-labibb-regulator.c
b/drivers/regulator/qcom-labibb-regulator.c
index a9dc7c060375..3539631c9f96 100644
--- a/drivers/regulator/qcom-labibb-regulator.c
+++ b/drivers/regulator/qcom-labibb-regulator.c
@@ -1,6 +1,7 @@
// SPDX-License-Identifier: GPL-2.0
// Copyright (c) 2019, The Linux Foundation. All rights reserved.
+#include
#include
#include
#include
@@ -18,11 +19,15 @@
#define REG_LABIBB_ENABLE_CTL 0x46
#define LABIBB_STATUS1_VREG_OK_BIT BIT(7)
#define LABIBB_CONTROL_ENABLE BIT(7)
+#define LABIBB_STATUS1_SC_DETECT_BIT BIT(6)
#define LAB_ENABLE_CTL_MASKBIT(7)
#define IBB_ENABLE_CTL_MASK(BIT(7) | BIT(6))
#define POWER_DELAY8000
+#define POLLING_SCP_DONE_INTERVAL_US 5000
+#define POLLING_SCP_TIMEOUT16000
+
struct labibb_regulator {
struct regulator_desc desc;
@@ -30,6 +35,8 @@ struct labibb_regulator {
struct regmap *regmap;
struct regulator_dev*rdev;
u16 base;
+ int sc_irq;
+ int vreg_enabled;
u8 type;
};
@@ -112,9 +119,10 @@ static int qcom_labibb_regulator_enable(struct
regulator_dev *rdev)
return ret;
}
- if (ret)
+ if (ret) {
+ reg->vreg_enabled = 1;
return 0;
-
+ }
dev_err(reg->dev, "Can't enable %s\n", reg->desc.name);
return -EINVAL;
@@ -140,8 +148,10 @@ static int qcom_labibb_regulator_disable(struct
regulator_dev *rdev)
return ret;
}
- if (!ret)
+ if (!ret) {
+ reg->vreg_enabled = 0;
return 0;
+ }
dev_err(reg->dev, "Can't disable %s\n", reg->desc.name);
return -EINVAL;
@@ -153,6 +163,70 @@ static struct regulator_ops qcom_labibb_ops = {
.is_enabled = qcom_labibb_regulator_is_enabled,
};
+
+static irqreturn_t labibb_sc_err_handler(int irq, void *_reg)
+{
+ int ret, count;
+ u16 reg;
+ u8 sc_err_mask;
+ unsigned int val;
+ struct labibb_regulator *labibb_reg = (struct labibb_regulator *)_reg;
+ bool in_sc_err, reg_en, scp_done = false;
+
+ if (irq == labibb_reg->sc_irq)
+ reg = labibb_reg->base + REG_LABIBB_STATUS1;
+ else
+ return IRQ_HANDLED;
+
+ sc_err_mask = LABIBB_STATUS1_SC_DETECT_BIT;
+
+ ret = regmap_bulk_read(labibb_reg->regmap, reg, , 1);
+ if (ret < 0) {
+ dev_err(labibb_reg->dev, "Read failed, ret=%d\n", ret);
+ return IRQ_HANDLED;
+ }
+ dev_dbg(labibb_reg->dev, "%s SC error triggered! STATUS1 = %d\n",
+ labibb_reg->desc.name, val);
+
+ in_sc_err = !!(val & sc_err_mask);
+
+ /*
+* The SC(short circuit) fault would trigger PBS(Portable Batch
+* System) to disable regulators for protection. This would
+* cause the SC_DETECT status being cleared so that it's not
+* able to get the SC fault status.
+* Check if the regulator is enabled in the driver but
+* disabled in hardware, this means a SC fault had happened
+* and SCP handling is completed by PBS.
+*/
+ if (!in_sc_err) {
+
+ reg = labibb_reg->base + REG_LABIBB_ENABLE_CTL;
+
+ ret = regmap_read_poll_timeout(labibb_reg->regmap,
+ reg, val,
+ !(val & LABIBB_CONTROL_ENABLE),
+ POLLING_SCP_DONE_INTERVAL_US,
+ POLLING_SCP_TIMEOUT);
+
+ if (!ret && labibb_reg->vreg_enabled) {
+ dev_dbg(labibb_reg->dev,
+ "%s has been disabled by SCP\n",
+ labibb_reg->desc.name);
+
[v2 0/4] Qualcomm labibb regulator driver
This series adds a driver for LAB/IBB regulators found on some Qualcomm SoCs. These regulators provide positive and/or negative boost power supplies for LCD/LED display panels connected to the SoC. This series adds the support for pmi8998 PMIC found in SDM845 family of SoCs. Changes from v1: - Incorporated review comments from v1 - Changed from virtual-regulator based handling to individual regulator based handling. - Reworked the core to merge most of enable/disable functions, combine the regulator_ops into one and allow for future variations. - is_enabled() is now _really_ is_enabled() - Simplified the SC interrupt handling - use regmap_read_poll_timeout, REGULATOR_EVENT_OVER_CURRENT handling and notification to clients. Nisha Kumari (4): dt-bindings: regulator: Add labibb regulator arm64: dts: qcom: pmi8998: Add nodes for LAB and IBB regulators regulator: qcom: Add labibb driver regulator: qcom: labibb: Add SC interrupt handling .../regulator/qcom-labibb-regulator.txt | 47 +++ arch/arm64/boot/dts/qcom/pmi8998.dtsi | 16 + drivers/regulator/Kconfig | 10 + drivers/regulator/Makefile| 1 + drivers/regulator/qcom-labibb-regulator.c | 385 ++ 5 files changed, 459 insertions(+) create mode 100644 Documentation/devicetree/bindings/regulator/qcom-labibb-regulator.txt create mode 100644 drivers/regulator/qcom-labibb-regulator.c -- 2.26.2
[v2 1/4] dt-bindings: regulator: Add labibb regulator
From: Nisha Kumari
Adding the devicetree binding for labibb regulator.
Signed-off-by: Nisha Kumari
Signed-off-by: Sumit Semwal
--
v2: updated for better compatible string and names.
---
.../regulator/qcom-labibb-regulator.txt | 47 +++
1 file changed, 47 insertions(+)
create mode 100644
Documentation/devicetree/bindings/regulator/qcom-labibb-regulator.txt
diff --git
a/Documentation/devicetree/bindings/regulator/qcom-labibb-regulator.txt
b/Documentation/devicetree/bindings/regulator/qcom-labibb-regulator.txt
new file mode 100644
index ..6e639d69f780
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/qcom-labibb-regulator.txt
@@ -0,0 +1,47 @@
+Qualcomm's LAB(LCD AMOLED Boost)/IBB(Inverting Buck Boost) Regulator
+
+LAB can be used as a positive boost power supply and IBB can be used as a
negative
+boost power supply for display panels. Currently implemented for pmi8998.
+
+Main node required properties:
+
+- compatible: Must be:
+ "qcom,pmi8998-lab-ibb"
+- #address-cells: Must be 1
+- #size-cells: Must be 0
+
+LAB subnode required properties:
+
+- interrupts: Specify the interrupts as per the interrupt
+ encoding.
+- interrupt-names: Interrupt names to match up 1-to-1 with
+ the interrupts specified in 'interrupts'
+ property.
+
+IBB subnode required properties:
+
+- interrupts: Specify the interrupts as per the interrupt
+ encoding.
+- interrupt-names: Interrupt names to match up 1-to-1 with
+ the interrupts specified in 'interrupts'
+ property.
+
+Example:
+ pmi8998_lsid1: pmic@3 {
+ labibb {
+ compatible = "qcom,pmi8998-lab-ibb";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ lab: lab {
+ interrupts = <0x3 0xde 0x0
IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "lab-sc-err";
+ };
+
+ ibb: ibb {
+ interrupts = <0x3 0xdc 0x2
IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "ibb-sc-err";
+ };
+
+ };
+ };
--
2.26.2
[v2 2/4] arm64: dts: qcom: pmi8998: Add nodes for LAB and IBB regulators
From: Nisha Kumari
This patch adds devicetree nodes for LAB and IBB regulators.
Signed-off-by: Nisha Kumari
Signed-off-by: Sumit Semwal
--
v2: [sumits]: updated for better compatible string and names
---
arch/arm64/boot/dts/qcom/pmi8998.dtsi | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/pmi8998.dtsi
b/arch/arm64/boot/dts/qcom/pmi8998.dtsi
index 23f9146a161e..72dc5f0db3ca 100644
--- a/arch/arm64/boot/dts/qcom/pmi8998.dtsi
+++ b/arch/arm64/boot/dts/qcom/pmi8998.dtsi
@@ -25,5 +25,21 @@ pmi8998_lsid1: pmic@3 {
reg = <0x3 SPMI_USID>;
#address-cells = <1>;
#size-cells = <0>;
+
+ labibb: labibb {
+ compatible = "qcom,pmi8998-lab-ibb";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ibb: ibb {
+ interrupts = <0x3 0xdc 0x2
IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "ibb-sc-err";
+ };
+
+ lab: lab {
+ interrupts = <0x3 0xde 0x0
IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "lab-sc-err";
+ };
+ };
};
};
--
2.26.2
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.
