[PATCH v1 5/6] dt-bindings: vendor-prefixes: Add ys vendor prefix
Add prefix for Shenzhen Yashi Changhua Intelligent Technology Co., Ltd. Signed-off-by: Guido Günther --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index e40ee369f808..d0f3abf2f12c 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -1220,6 +1220,8 @@ patternProperties: description: Shenzhen Yangliming Electronic Technology Co., Ltd. "^yna,.*": description: YSH & ATIL + "^ys,.*": +description: Shenzhen Yashi Changhua Intelligent Technology Co., Ltd. "^yones-toptech,.*": description: Yones Toptech Co., Ltd. "^ysoft,.*": -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 0/6] drm/panel: mantix and st7703 fixes and additions
This adds new panel type to the mantix driver as found on the Librem 5 and fixes a glitch in the init sequence (affecting both panels). The fix is at the start of the series to make backporting simpler. It also adds a patch to make st7703 use dev_err_probe(). Guido Günther (6): drm/panel: st7703: Use dev_err_probe drm/panel: mantix: Tweak init sequence drm/panel: mantix: Allow to specify default mode for different panels drm/panel: mantix: Support panel from Shenzhen Yashi Changhua Intelligent Technology Co dt-bindings: vendor-prefixes: Add ys vendor prefix dt-binding: display: mantix: Add compatible for panel from YS .../display/panel/mantix,mlaf057we51-x.yaml | 1 + .../devicetree/bindings/vendor-prefixes.yaml | 2 + .../gpu/drm/panel/panel-mantix-mlaf057we51.c | 39 +++ drivers/gpu/drm/panel/panel-sitronix-st7703.c | 24 4 files changed, 43 insertions(+), 23 deletions(-) -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/panel: st7703: use DEFINE_DEBUGFS_ATTRIBUTE with debugfs_create_file_unsafe()
Hi,
On Fri, Oct 30, 2020 at 09:01:50AM +0530, Deepak R Varma wrote:
> Using DEFINE_DEBUGFS_ATTRIBUTE macro with debugfs_create_file_unsafe()
> function in place of the debugfs_create_file() function will make the
> file operation struct "reset" aware of the file's lifetime. Additional
> details here: https://lists.archive.carbon60.com/linux/kernel/2369498
>
> Issue reported by Coccinelle script:
> scripts/coccinelle/api/debugfs/debugfs_simple_attr.cocci
>
> Signed-off-by: Deepak R Varma
Reviewed-by: Guido Günther
Cheers,
-- Guido
> ---
> Please Note: This is a Outreachy project task patch.
>
> drivers/gpu/drm/panel/panel-sitronix-st7703.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> index c22e7c49e077..89b71d4f810d 100644
> --- a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> +++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> @@ -502,15 +502,14 @@ static int allpixelson_set(void *data, u64 val)
> return 0;
> }
>
> -DEFINE_SIMPLE_ATTRIBUTE(allpixelson_fops, NULL,
> - allpixelson_set, "%llu\n");
> +DEFINE_DEBUGFS_ATTRIBUTE(allpixelson_fops, NULL, allpixelson_set, "%llu\n");
>
> static void st7703_debugfs_init(struct st7703 *ctx)
> {
> ctx->debugfs = debugfs_create_dir(DRV_NAME, NULL);
>
> - debugfs_create_file("allpixelson", 0600, ctx->debugfs, ctx,
> - _fops);
> + debugfs_create_file_unsafe("allpixelson", 0600, ctx->debugfs, ctx,
> +_fops);
> }
>
> static void st7703_debugfs_remove(struct st7703 *ctx)
> --
> 2.25.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 2/2] drm: etnaviv: Unmap gems on gem_close
Hi,
On Fri, Oct 30, 2020 at 10:19:54AM +0100, Lucas Stach wrote:
> Am Donnerstag, den 29.10.2020, 19:20 +0100 schrieb Daniel Vetter:
> > On Thu, Oct 29, 2020 at 03:38:21PM +0100, Lucas Stach wrote:
> > > Hi Guido,
> > >
> > > Am Donnerstag, den 29.10.2020, 15:20 +0100 schrieb Guido Günther:
> > > > So far the unmap from gpu address space only happened when dropping the
> > > > last ref in gem_free_object_unlocked, however that is skipped if there's
> > > > still multiple handles to the same GEM object.
> > > >
> > > > Since userspace (here mesa) in the case of softpin hands back the memory
> > > > region to the pool of available GPU virtual memory closing the handle
> > > > via DRM_IOCTL_GEM_CLOSE this can lead to etnaviv_iommu_insert_exact
> > > > failing later since userspace thinks the vaddr is available while the
> > > > kernel thinks it isn't making the submit fail like
> > > >
> > > > [E] submit failed: -14 (No space left on device)
> > > > (etna_cmd_stream_flush:244)
> > > >
> > > > Fix this by unmapping the memory via the .gem_close_object callback.
> > > >
> > > > Signed-off-by: Guido Günther
> > > > ---
> > > > drivers/gpu/drm/etnaviv/etnaviv_drv.c | 1 +
> > > > drivers/gpu/drm/etnaviv/etnaviv_drv.h | 1 +
> > > > drivers/gpu/drm/etnaviv/etnaviv_gem.c | 32 +++
> > > > 3 files changed, 34 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> > > > b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> > > > index a9a3afaef9a1..fdcc6405068c 100644
> > > > --- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> > > > +++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> > > > @@ -491,6 +491,7 @@ static struct drm_driver etnaviv_drm_driver = {
> > > > .open = etnaviv_open,
> > > > .postclose = etnaviv_postclose,
> > > > .gem_free_object_unlocked = etnaviv_gem_free_object,
> > > > + .gem_close_object = etnaviv_gem_close_object,
> > > > .gem_vm_ops = _ops,
> > > > .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
> > > > .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> > > > diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.h
> > > > b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
> > > > index 4d8dc9236e5f..2226a9af0d63 100644
> > > > --- a/drivers/gpu/drm/etnaviv/etnaviv_drv.h
> > > > +++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
> > > > @@ -65,6 +65,7 @@ int etnaviv_gem_cpu_prep(struct drm_gem_object *obj,
> > > > u32 op,
> > > > struct drm_etnaviv_timespec *timeout);
> > > > int etnaviv_gem_cpu_fini(struct drm_gem_object *obj);
> > > > void etnaviv_gem_free_object(struct drm_gem_object *obj);
> > > > +void etnaviv_gem_close_object(struct drm_gem_object *obj, struct
> > > > drm_file *file);
> > > > int etnaviv_gem_new_handle(struct drm_device *dev, struct drm_file
> > > > *file,
> > > > u32 size, u32 flags, u32 *handle);
> > > > int etnaviv_gem_new_userptr(struct drm_device *dev, struct drm_file
> > > > *file,
> > > > diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> > > > b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> > > > index f06e19e7be04..5aec4a23c77e 100644
> > > > --- a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> > > > +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> > > > @@ -515,6 +515,38 @@ static const struct etnaviv_gem_ops
> > > > etnaviv_gem_shmem_ops = {
> > > > .mmap = etnaviv_gem_mmap_obj,
> > > > };
> > > >
> > > > +void etnaviv_gem_close_object(struct drm_gem_object *obj, struct
> > > > drm_file *unused)
> > > > +{
> > > > + struct etnaviv_gem_object *etnaviv_obj = to_etnaviv_bo(obj);
> > > > + struct etnaviv_vram_mapping *mapping, *tmp;
> > > > +
> > > > + /* Handle this via etnaviv_gem_free_object */
> > > > + if (obj->handle_count == 1)
> > > > + return;
> > > > +
> > > > + WARN_ON(is_active(etnaviv_obj));
> > > > +
> > > > + /*
> > > > +* userspace wants to release the handle so we need to remove
> > > > +
[RFC PATCH 2/2] drm: etnaviv: Unmap gems on gem_close
So far the unmap from gpu address space only happened when dropping the
last ref in gem_free_object_unlocked, however that is skipped if there's
still multiple handles to the same GEM object.
Since userspace (here mesa) in the case of softpin hands back the memory
region to the pool of available GPU virtual memory closing the handle
via DRM_IOCTL_GEM_CLOSE this can lead to etnaviv_iommu_insert_exact
failing later since userspace thinks the vaddr is available while the
kernel thinks it isn't making the submit fail like
[E] submit failed: -14 (No space left on device) (etna_cmd_stream_flush:244)
Fix this by unmapping the memory via the .gem_close_object callback.
Signed-off-by: Guido Günther
---
drivers/gpu/drm/etnaviv/etnaviv_drv.c | 1 +
drivers/gpu/drm/etnaviv/etnaviv_drv.h | 1 +
drivers/gpu/drm/etnaviv/etnaviv_gem.c | 32 +++
3 files changed, 34 insertions(+)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
index a9a3afaef9a1..fdcc6405068c 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
@@ -491,6 +491,7 @@ static struct drm_driver etnaviv_drm_driver = {
.open = etnaviv_open,
.postclose = etnaviv_postclose,
.gem_free_object_unlocked = etnaviv_gem_free_object,
+ .gem_close_object = etnaviv_gem_close_object,
.gem_vm_ops = _ops,
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.h
b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
index 4d8dc9236e5f..2226a9af0d63 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.h
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
@@ -65,6 +65,7 @@ int etnaviv_gem_cpu_prep(struct drm_gem_object *obj, u32 op,
struct drm_etnaviv_timespec *timeout);
int etnaviv_gem_cpu_fini(struct drm_gem_object *obj);
void etnaviv_gem_free_object(struct drm_gem_object *obj);
+void etnaviv_gem_close_object(struct drm_gem_object *obj, struct drm_file
*file);
int etnaviv_gem_new_handle(struct drm_device *dev, struct drm_file *file,
u32 size, u32 flags, u32 *handle);
int etnaviv_gem_new_userptr(struct drm_device *dev, struct drm_file *file,
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
index f06e19e7be04..5aec4a23c77e 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
@@ -515,6 +515,38 @@ static const struct etnaviv_gem_ops etnaviv_gem_shmem_ops
= {
.mmap = etnaviv_gem_mmap_obj,
};
+void etnaviv_gem_close_object(struct drm_gem_object *obj, struct drm_file
*unused)
+{
+ struct etnaviv_gem_object *etnaviv_obj = to_etnaviv_bo(obj);
+ struct etnaviv_vram_mapping *mapping, *tmp;
+
+ /* Handle this via etnaviv_gem_free_object */
+ if (obj->handle_count == 1)
+ return;
+
+ WARN_ON(is_active(etnaviv_obj));
+
+ /*
+* userspace wants to release the handle so we need to remove
+* the mapping from the gpu's virtual address space to stay
+* in sync.
+*/
+ list_for_each_entry_safe(mapping, tmp, _obj->vram_list,
+obj_node) {
+ struct etnaviv_iommu_context *context = mapping->context;
+
+ WARN_ON(mapping->use);
+
+ if (context) {
+ etnaviv_iommu_unmap_gem(context, mapping);
+ etnaviv_iommu_context_put(context);
+ }
+
+ list_del(>obj_node);
+ kfree(mapping);
+ }
+}
+
void etnaviv_gem_free_object(struct drm_gem_object *obj)
{
struct etnaviv_gem_object *etnaviv_obj = to_etnaviv_bo(obj);
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH 0/2] drm: etnaviv: Unmap gems on gem_close
This is meant as a RFC since i'm not sure if this is the right way to fix the problem: So far the unmap from gpu address space only happened when dropping the last ref in gem_free_object_unlocked, however that is skipped if there's still multiple handles to the same GEM object. Since userspace (here mesa) in the case of softpin hands back the memory region to the pool of available GPU virtual memory closing the handle via DRM_IOCTL_GEM_CLOSE this can lead to etnaviv_iommu_insert_exact failing later since userspace thinks the vaddr is available while the kernel thinks it isn't making the submit fail like [E] submit failed: -14 (No space left on device) (etna_cmd_stream_flush:244) Fix this by unmapping the memory via the .gem_close_object callback. The patch is against 5.9 and will need to be redone for drm-misc-next due to the conversion to GEM object functions but i'm happy to do that it looks like the right approach. I can trigger the problem when plugging/unplugging a DP screen driven by DCSS while DSI is driven by mxsfb. It preferably happens with 4k since this allocates bigger chunks. I also folded in a commit checking for the context->lock in etnaviv_iommu_insert_exact and etnaviv_iommu_remove_mapping too to make it match etnaviv_iommu_find_iova. To: Lucas Stach ,Russell King ,Christian Gmeiner ,David Airlie ,Daniel Vetter ,etna...@lists.freedesktop.org, dri-devel@lists.freedesktop.org Guido Günther (2): drm: etnaviv: Add lockdep annotations for context lock drm: etnaviv: Unmap gems on gem_close drivers/gpu/drm/etnaviv/etnaviv_drv.c | 1 + drivers/gpu/drm/etnaviv/etnaviv_drv.h | 1 + drivers/gpu/drm/etnaviv/etnaviv_gem.c | 32 +++ drivers/gpu/drm/etnaviv/etnaviv_mmu.c | 4 4 files changed, 38 insertions(+) -- 2.28.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH 1/2] drm: etnaviv: Add lockdep annotations for context lock
etnaviv_iommu_find_iova has it so etnaviv_iommu_insert_exact and
lockdep_assert_held should have it as well.
Signed-off-by: Guido Günther
---
drivers/gpu/drm/etnaviv/etnaviv_mmu.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
b/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
index 3607d348c298..cd599ac04663 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
@@ -131,6 +131,8 @@ static void etnaviv_iommu_remove_mapping(struct
etnaviv_iommu_context *context,
{
struct etnaviv_gem_object *etnaviv_obj = mapping->object;
+ lockdep_assert_held(>lock);
+
etnaviv_iommu_unmap(context, mapping->vram_node.start,
etnaviv_obj->sgt, etnaviv_obj->base.size);
drm_mm_remove_node(>vram_node);
@@ -223,6 +225,8 @@ static int etnaviv_iommu_find_iova(struct
etnaviv_iommu_context *context,
static int etnaviv_iommu_insert_exact(struct etnaviv_iommu_context *context,
struct drm_mm_node *node, size_t size, u64 va)
{
+ lockdep_assert_held(>lock);
+
return drm_mm_insert_node_in_range(>mm, node, size, 0, 0, va,
va + size, DRM_MM_INSERT_LOWEST);
}
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] Implement .format_mod_supported in mxsfb
Hi Daniel,
On Sat, Oct 24, 2020 at 04:59:16PM +, Daniel Abrecht wrote:
> This will make sure applications which use the IN_FORMATS blob
> to figure out which modifiers they can use will pick up the
> linear modifier which is needed by mxsfb. Such applications
> will not work otherwise if an incompatible implicit modifier
> ends up being selected.
Since this got broken by the switch away for the simple display
pipeline helper (ae1ed0093281939b80664a687689f12436c0e874) could
you add a fixes tag?
Cheers,
-- Guido
>
> Signed-off-by: Daniel Abrecht
> ---
> drivers/gpu/drm/mxsfb/mxsfb_kms.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
> b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
> index 956f631997f2..fc4b1626261b 100644
> --- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
> +++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
> @@ -484,6 +484,13 @@ static void mxsfb_plane_overlay_atomic_update(struct
> drm_plane *plane,
> writel(ctrl, mxsfb->base + LCDC_AS_CTRL);
> }
>
> +static bool mxsfb_format_mod_supported(struct drm_plane *plane,
> +uint32_t format,
> +uint64_t modifier)
> +{
> + return modifier == DRM_FORMAT_MOD_LINEAR;
> +}
> +
> static const struct drm_plane_helper_funcs mxsfb_plane_primary_helper_funcs
> = {
> .atomic_check = mxsfb_plane_atomic_check,
> .atomic_update = mxsfb_plane_primary_atomic_update,
> @@ -495,6 +502,7 @@ static const struct drm_plane_helper_funcs
> mxsfb_plane_overlay_helper_funcs = {
> };
>
> static const struct drm_plane_funcs mxsfb_plane_funcs = {
> + .format_mod_supported = mxsfb_format_mod_supported,
> .update_plane = drm_atomic_helper_update_plane,
> .disable_plane = drm_atomic_helper_disable_plane,
> .destroy= drm_plane_cleanup,
> --
> 2.20.1
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/3] drm/panel: mantix panel reset fixes
Hi Sam,
On Thu, Oct 22, 2020 at 06:59:29AM +0200, Sam Ravnborg wrote:
> Hi Guido.
>
> On Tue, Oct 20, 2020 at 01:57:11PM +0200, Guido Günther wrote:
> > Hi Daniel, Sam,
> > On Mon, Oct 19, 2020 at 05:44:37PM +0200, Daniel Vetter wrote:
> > > On Sat, Oct 17, 2020 at 12:47:36PM +0200, Sam Ravnborg wrote:
> > > > Hi Guido.
> > > >
> > > > On Sat, Oct 17, 2020 at 11:13:07AM +0200, Guido Günther wrote:
> > > > > Hi Sam,
> > > > > On Fri, Oct 16, 2020 at 04:29:16PM +0200, Sam Ravnborg wrote:
> > > > > > Hi Guido.
> > > > > > On Tue, Oct 13, 2020 at 12:32:45PM +0200, Guido Günther wrote:
> > > > > [..snip..]
> > > > > > >
> > > > > > > Changes from v1:
> > > > > > > - As per review comments by Fabio Estevam
> > > > > > >
> > > > > > > https://lore.kernel.org/dri-devel/CAOMZO5B5ECcConvKej=rcaf8wvoxgq7nuzkj-ad0asaozuq...@mail.gmail.com/
> > > > > > > - Fix typo in commit messages
> > > > > > > - As per review comments by Rob Herring
> > > > > > >
> > > > > > > https://lore.kernel.org/dri-devel/20200929174624.GA832332@bogus/
> > > > > > >- Don't use an array of reset lines
> > > > > > >
> > > > > > > Guido Günther (3):
> > > > > > > drm/panel: mantix: Don't dereference NULL mode
> > > > > > > drm/panel: mantix: Fix panel reset
> > > > > > > dt-binding: display: Require two resets on mantix panel
> > > > > >
> > > > > > All applied to drm-misc-next and pushed out.
> > > > > > And then I remembered you had commit right - sigh.
> > > > >
> > > > > Thanks! Is there any special care needed to get that into 5.10? The
> > > > > driver landed there in 72967d5616d3f0c714f8eb6c4e258179a9031c45.
> > > >
> > > > As the patches was applied to drm-misc-next the easiet path would
> > > > be to cherry-pick them and apply to drm-misc-fixes.
> > > > dim has cherry-pick support - try to use it rahter than doing it by
> > > > hand.
> > >
> > > drm-misc-next-fixes while we're between freeze and merge window end:
> > >
> > > https://drm.pages.freedesktop.org/maintainer-tools/committer-drm-misc.html#where-do-i-apply-my-patch
> >
> > Great. Thanks for the pointer, that works. Now i get:
> >
> > $ ../maintainer-tools/dim push --dry-run
> > dim: 3532f0117258 ("dt-binding: display: Require two resets on mantix
> > panel"): mandatory review missing.
> > dim: c90f95ad6d05 ("drm/panel: mantix: Fix panel reset"): mandatory
> > review missing.
> > dim: 8b557f793e69 ("drm/panel: mantix: Don't dereference NULL mode"):
> > mandatory review missing.
> > dim: ERROR: issues in commits detected, aborting
> >
> > and in fact there's only Signed-off-by's on it:
> >
> > Fixes: 72967d5616d3 ("drm/panel: Add panel driver for the Mantix
> > MLAF057WE51-X DSI panel")
> > Signed-off-by: Guido Günther
> > Signed-off-by: Sam Ravnborg
> > Link:
> > https://patchwork.freedesktop.org/patch/msgid/ba71a8ab010d263a8058dd4f711e3bcd95877bf2.1602584953.git@sigxcpu.org
> >
> > Sam, I assume your Signed-off-by's should have been Reviewed-by ?
> > O.k. to fix that up in the commit message before pushing to
> > drm-misc-next?
> Fine to add my r-b.
>
> For patches I push I always read the patch - but seldom claim that I
> review them. It seems a bit implicit I think - but maybe this is just
> bad practice on my side.
I don't know but for fixes i seems fine for dim to complain if they show
up without a r-b.
>
> Then I also avoid the endless discussion with myself it what I did
> warrant an a-b or r-b.
Pushed out now, thanks a lot for the help!
Cheers,
-- Guido
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/3] drm/panel: mantix panel reset fixes
Hi Daniel, Sam,
On Mon, Oct 19, 2020 at 05:44:37PM +0200, Daniel Vetter wrote:
> On Sat, Oct 17, 2020 at 12:47:36PM +0200, Sam Ravnborg wrote:
> > Hi Guido.
> >
> > On Sat, Oct 17, 2020 at 11:13:07AM +0200, Guido Günther wrote:
> > > Hi Sam,
> > > On Fri, Oct 16, 2020 at 04:29:16PM +0200, Sam Ravnborg wrote:
> > > > Hi Guido.
> > > > On Tue, Oct 13, 2020 at 12:32:45PM +0200, Guido Günther wrote:
> > > [..snip..]
> > > > >
> > > > > Changes from v1:
> > > > > - As per review comments by Fabio Estevam
> > > > >
> > > > > https://lore.kernel.org/dri-devel/CAOMZO5B5ECcConvKej=rcaf8wvoxgq7nuzkj-ad0asaozuq...@mail.gmail.com/
> > > > >- Fix typo in commit messages
> > > > > - As per review comments by Rob Herring
> > > > >https://lore.kernel.org/dri-devel/20200929174624.GA832332@bogus/
> > > > >- Don't use an array of reset lines
> > > > >
> > > > > Guido Günther (3):
> > > > > drm/panel: mantix: Don't dereference NULL mode
> > > > > drm/panel: mantix: Fix panel reset
> > > > > dt-binding: display: Require two resets on mantix panel
> > > >
> > > > All applied to drm-misc-next and pushed out.
> > > > And then I remembered you had commit right - sigh.
> > >
> > > Thanks! Is there any special care needed to get that into 5.10? The
> > > driver landed there in 72967d5616d3f0c714f8eb6c4e258179a9031c45.
> >
> > As the patches was applied to drm-misc-next the easiet path would
> > be to cherry-pick them and apply to drm-misc-fixes.
> > dim has cherry-pick support - try to use it rahter than doing it by
> > hand.
>
> drm-misc-next-fixes while we're between freeze and merge window end:
>
> https://drm.pages.freedesktop.org/maintainer-tools/committer-drm-misc.html#where-do-i-apply-my-patch
Great. Thanks for the pointer, that works. Now i get:
$ ../maintainer-tools/dim push --dry-run
dim: 3532f0117258 ("dt-binding: display: Require two resets on mantix
panel"): mandatory review missing.
dim: c90f95ad6d05 ("drm/panel: mantix: Fix panel reset"): mandatory review
missing.
dim: 8b557f793e69 ("drm/panel: mantix: Don't dereference NULL mode"):
mandatory review missing.
dim: ERROR: issues in commits detected, aborting
and in fact there's only Signed-off-by's on it:
Fixes: 72967d5616d3 ("drm/panel: Add panel driver for the Mantix
MLAF057WE51-X DSI panel")
Signed-off-by: Guido Günther
Signed-off-by: Sam Ravnborg
Link:
https://patchwork.freedesktop.org/patch/msgid/ba71a8ab010d263a8058dd4f711e3bcd95877bf2.1602584953.git@sigxcpu.org
Sam, I assume your Signed-off-by's should have been Reviewed-by ?
O.k. to fix that up in the commit message before pushing to
drm-misc-next?
Cheers,
-- Guido
>
> Cheers, Daniel
>
> >
>
> > When you apply to drm-misc-fixes include a Fixes: tag so the tooling
> > will pick the patches automagically.
> >
> > In hindsight the patches should have carried a Fixes: tag from a start
> > and should have been applied to drm-misc-fixes from a start too.
> >
> > I have done something like above once or twice but anyway reach out if
> > you have questions. Or ask at #dri-devel.
> >
> > Sam
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/3] drm/panel: mantix panel reset fixes
Hi, On Sun, Oct 18, 2020 at 03:38:45PM +0200, Sam Ravnborg wrote: > Hi Guido > > On Sun, Oct 18, 2020 at 03:01:22PM +0200, Guido Günther wrote: > > Hi Sam, > > On Sat, Oct 17, 2020 at 12:47:36PM +0200, Sam Ravnborg wrote: > > > Hi Guido. > > > > > > On Sat, Oct 17, 2020 at 11:13:07AM +0200, Guido Günther wrote: > > > > Hi Sam, > > > > On Fri, Oct 16, 2020 at 04:29:16PM +0200, Sam Ravnborg wrote: > > > > > Hi Guido. > > > > > On Tue, Oct 13, 2020 at 12:32:45PM +0200, Guido Günther wrote: > > > > [..snip..] > > > > > > > > > > > > Changes from v1: > > > > > > - As per review comments by Fabio Estevam > > > > > > > > > > > > https://lore.kernel.org/dri-devel/CAOMZO5B5ECcConvKej=rcaf8wvoxgq7nuzkj-ad0asaozuq...@mail.gmail.com/ > > > > > >- Fix typo in commit messages > > > > > > - As per review comments by Rob Herring > > > > > >https://lore.kernel.org/dri-devel/20200929174624.GA832332@bogus/ > > > > > >- Don't use an array of reset lines > > > > > > > > > > > > Guido Günther (3): > > > > > > drm/panel: mantix: Don't dereference NULL mode > > > > > > drm/panel: mantix: Fix panel reset > > > > > > dt-binding: display: Require two resets on mantix panel > > > > > > > > > > All applied to drm-misc-next and pushed out. > > > > > And then I remembered you had commit right - sigh. > > > > > > > > Thanks! Is there any special care needed to get that into 5.10? The > > > > driver landed there in 72967d5616d3f0c714f8eb6c4e258179a9031c45. > > > > > > As the patches was applied to drm-misc-next the easiet path would > > > be to cherry-pick them and apply to drm-misc-fixes. > > > dim has cherry-pick support - try to use it rahter than doing it by > > > hand. > > > > Does that require any further ACKs or just cherry-pick and push out? > To the best of my knowledge just cherry-pick, test and push out. drm-misc-fixes does not yet have the corresponding code so i assume i have to wait for back merge of 5.10-rc1 ? At least https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html seems to indicate that. Cheers, -- Guido > > Sam > > > > > > When you apply to drm-misc-fixes include a Fixes: tag so the tooling > > > will pick the patches automagically. > > > > Will do. It was unfortunate that the initial ones didn't get them but > > i think the drm merge happened while v2 was out on the list. I'll try > > add that relevant information to the cover letter in the future. > > > > Cheers, > > -- Guido > > > > > > > > In hindsight the patches should have carried a Fixes: tag from a start > > > and should have been applied to drm-misc-fixes from a start too. > > > > > > I have done something like above once or twice but anyway reach out if > > > you have questions. Or ask at #dri-devel. > > > > > > Sam > > > > > ___ > > dri-devel mailing list > > dri-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/3] drm/panel: mantix panel reset fixes
Hi Sam, On Sat, Oct 17, 2020 at 12:47:36PM +0200, Sam Ravnborg wrote: > Hi Guido. > > On Sat, Oct 17, 2020 at 11:13:07AM +0200, Guido Günther wrote: > > Hi Sam, > > On Fri, Oct 16, 2020 at 04:29:16PM +0200, Sam Ravnborg wrote: > > > Hi Guido. > > > On Tue, Oct 13, 2020 at 12:32:45PM +0200, Guido Günther wrote: > > [..snip..] > > > > > > > > Changes from v1: > > > > - As per review comments by Fabio Estevam > > > > > > > > https://lore.kernel.org/dri-devel/CAOMZO5B5ECcConvKej=rcaf8wvoxgq7nuzkj-ad0asaozuq...@mail.gmail.com/ > > > >- Fix typo in commit messages > > > > - As per review comments by Rob Herring > > > >https://lore.kernel.org/dri-devel/20200929174624.GA832332@bogus/ > > > >- Don't use an array of reset lines > > > > > > > > Guido Günther (3): > > > > drm/panel: mantix: Don't dereference NULL mode > > > > drm/panel: mantix: Fix panel reset > > > > dt-binding: display: Require two resets on mantix panel > > > > > > All applied to drm-misc-next and pushed out. > > > And then I remembered you had commit right - sigh. > > > > Thanks! Is there any special care needed to get that into 5.10? The > > driver landed there in 72967d5616d3f0c714f8eb6c4e258179a9031c45. > > As the patches was applied to drm-misc-next the easiet path would > be to cherry-pick them and apply to drm-misc-fixes. > dim has cherry-pick support - try to use it rahter than doing it by > hand. Does that require any further ACKs or just cherry-pick and push out? > When you apply to drm-misc-fixes include a Fixes: tag so the tooling > will pick the patches automagically. Will do. It was unfortunate that the initial ones didn't get them but i think the drm merge happened while v2 was out on the list. I'll try add that relevant information to the cover letter in the future. Cheers, -- Guido > > In hindsight the patches should have carried a Fixes: tag from a start > and should have been applied to drm-misc-fixes from a start too. > > I have done something like above once or twice but anyway reach out if > you have questions. Or ask at #dri-devel. > > Sam > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/3] drm/panel: mantix panel reset fixes
Hi Sam, On Fri, Oct 16, 2020 at 04:29:16PM +0200, Sam Ravnborg wrote: > Hi Guido. > On Tue, Oct 13, 2020 at 12:32:45PM +0200, Guido Günther wrote: [..snip..] > > > > Changes from v1: > > - As per review comments by Fabio Estevam > > > > https://lore.kernel.org/dri-devel/CAOMZO5B5ECcConvKej=rcaf8wvoxgq7nuzkj-ad0asaozuq...@mail.gmail.com/ > >- Fix typo in commit messages > > - As per review comments by Rob Herring > >https://lore.kernel.org/dri-devel/20200929174624.GA832332@bogus/ > > - Don't use an array of reset lines > > > > Guido Günther (3): > > drm/panel: mantix: Don't dereference NULL mode > > drm/panel: mantix: Fix panel reset > > dt-binding: display: Require two resets on mantix panel > > All applied to drm-misc-next and pushed out. > And then I remembered you had commit right - sigh. Thanks! Is there any special care needed to get that into 5.10? The driver landed there in 72967d5616d3f0c714f8eb6c4e258179a9031c45. Cheers, -- Guido > > Sam > > > > > .../display/panel/mantix,mlaf057we51-x.yaml | 4 +++ > > .../gpu/drm/panel/panel-mantix-mlaf057we51.c | 25 +-- > > 2 files changed, 21 insertions(+), 8 deletions(-) > > > > -- > > 2.28.0 > > > > ___ > > dri-devel mailing list > > dri-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/3] dt-binding: display: Require two resets on mantix panel
We need to reset both for the panel to show an image. Signed-off-by: Guido Günther --- .../bindings/display/panel/mantix,mlaf057we51-x.yaml | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml b/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml index 937323cc9aaa..51f423297ec8 100644 --- a/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml +++ b/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml @@ -37,6 +37,9 @@ properties: reset-gpios: true + 'mantix,tp-rstn-gpios': +description: second reset line that triggers DSI config load + backlight: true required: @@ -63,6 +66,7 @@ examples: avee-supply = <_avee>; vddi-supply = <_1v8_p>; reset-gpios = < 29 GPIO_ACTIVE_LOW>; +mantix,tp-rstn-gpios = < 24 GPIO_ACTIVE_LOW>; backlight = <>; }; }; -- 2.28.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/3] drm/panel: mantix: Don't dereference NULL mode
Don't dereference mode which was just NULL checked.
Signed-off-by: Guido Günther
Reported-by: Dan Carpenter
---
drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
b/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
index 3482e28e30fc..4a7fbf64bb7a 100644
--- a/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
+++ b/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
@@ -204,7 +204,7 @@ static int mantix_get_modes(struct drm_panel *panel,
if (!mode) {
dev_err(ctx->dev, "Failed to add mode %ux%u@%u\n",
default_mode.hdisplay, default_mode.vdisplay,
- drm_mode_vrefresh(mode));
+ drm_mode_vrefresh(_mode));
return -ENOMEM;
}
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/3] drm/panel: mantix: Fix panel reset
The mantix panel needs two reset lines (RESX and TP_RSTN) deasserted to
output an image. Only deasserting RESX is not enough and the display
will stay blank. Deassert in prepare() and assert in unprepare() to keep
device held in reset when off.
Signed-off-by: Guido Günther
---
.../gpu/drm/panel/panel-mantix-mlaf057we51.c | 23 +--
1 file changed, 16 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
b/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
index 4a7fbf64bb7a..0c5f22e95c2d 100644
--- a/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
+++ b/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
@@ -26,7 +26,9 @@
struct mantix {
struct device *dev;
struct drm_panel panel;
+
struct gpio_desc *reset_gpio;
+ struct gpio_desc *tp_rstn_gpio;
struct regulator *avdd;
struct regulator *avee;
@@ -124,6 +126,10 @@ static int mantix_unprepare(struct drm_panel *panel)
{
struct mantix *ctx = panel_to_mantix(panel);
+ gpiod_set_value_cansleep(ctx->tp_rstn_gpio, 1);
+ usleep_range(5000, 6000);
+ gpiod_set_value_cansleep(ctx->reset_gpio, 1);
+
regulator_disable(ctx->avee);
regulator_disable(ctx->avdd);
/* T11 */
@@ -165,13 +171,10 @@ static int mantix_prepare(struct drm_panel *panel)
return ret;
}
- /* T3+T5 */
- usleep_range(1, 12000);
-
- gpiod_set_value_cansleep(ctx->reset_gpio, 1);
- usleep_range(5150, 7000);
-
+ /* T3 + T4 + time for voltage to become stable: */
+ usleep_range(6000, 7000);
gpiod_set_value_cansleep(ctx->reset_gpio, 0);
+ gpiod_set_value_cansleep(ctx->tp_rstn_gpio, 0);
/* T6 */
msleep(50);
@@ -236,12 +239,18 @@ static int mantix_probe(struct mipi_dsi_device *dsi)
if (!ctx)
return -ENOMEM;
- ctx->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
+ ctx->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH);
if (IS_ERR(ctx->reset_gpio)) {
dev_err(dev, "cannot get reset gpio\n");
return PTR_ERR(ctx->reset_gpio);
}
+ ctx->tp_rstn_gpio = devm_gpiod_get(dev, "mantix,tp-rstn",
GPIOD_OUT_HIGH);
+ if (IS_ERR(ctx->tp_rstn_gpio)) {
+ dev_err(dev, "cannot get tp-rstn gpio\n");
+ return PTR_ERR(ctx->tp_rstn_gpio);
+ }
+
mipi_dsi_set_drvdata(dsi, ctx);
ctx->dev = dev;
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/3] drm/panel: mantix panel reset fixes
The first patch in this series fixes dereferencing a NULL mode in the error path. The second one extends the resets to not only reset RESX but also TP_RSTN since otherwise the display will stay completely blank. I didn't spot that before initial submission since the reset line was bound to the touch controller and although that failed to probe it came far enough to deassert the reset line (at an arbitrary point in time during boot) and hence we got a picture. Since touch and panel are on the same IC they're not completely independent and i might have to turn the whole thing into an MFD at some point but this series gets the panel to a reliably working state on boot and on fb blank/unblank. Since the reset-gpios are active low we can deassert in prepare and assert in unprepare simplifying the code making sure lines are kept low when the panel is off. The binding were not part of a stable kernel so I hope it's okay to not worry about backward compatibility. Changes from v1: - As per review comments by Fabio Estevam https://lore.kernel.org/dri-devel/CAOMZO5B5ECcConvKej=rcaf8wvoxgq7nuzkj-ad0asaozuq...@mail.gmail.com/ - Fix typo in commit messages - As per review comments by Rob Herring https://lore.kernel.org/dri-devel/20200929174624.GA832332@bogus/ - Don't use an array of reset lines Guido Günther (3): drm/panel: mantix: Don't dereference NULL mode drm/panel: mantix: Fix panel reset dt-binding: display: Require two resets on mantix panel .../display/panel/mantix,mlaf057we51-x.yaml | 4 +++ .../gpu/drm/panel/panel-mantix-mlaf057we51.c | 25 +-- 2 files changed, 21 insertions(+), 8 deletions(-) -- 2.28.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dt-bindings: display: Add dsi-controller.yaml in DSI controller schemas
Hi,
On Fri, Oct 02, 2020 at 05:59:24PM -0500, Rob Herring wrote:
> Some DSI controllers are missing a reference to the recently added
> dsi-controller.yaml schema. Add it and we can drop the duplicate
> parts.
For the NWL part:
Reviewed-by: Guido Günther
>
> Cc: Maxime Ripard
> Cc: Chen-Yu Tsai
> Cc: Eric Anholt
> Cc: Nicolas Saenz Julienne
> Cc: Florian Fainelli
> Cc: Ray Jui
> Cc: Scott Branden
> Cc: bcm-kernel-feedback-l...@broadcom.com
> Cc: Maxime Coquelin
> Cc: Alexandre Torgue
> Cc: "Guido Gúnther"
> Cc: Robert Chiras
> Cc: Philippe Cornu
> Cc: Yannick Fertre
> Signed-off-by: Rob Herring
> ---
> .../display/allwinner,sun6i-a31-mipi-dsi.yaml | 11 ++---
> .../bindings/display/brcm,bcm2835-dsi0.yaml | 3 +++
> .../bindings/display/bridge/nwl-dsi.yaml | 11 -
> .../bindings/display/st,stm32-dsi.yaml| 23 ---
> 4 files changed, 14 insertions(+), 34 deletions(-)
>
> diff --git
> a/Documentation/devicetree/bindings/display/allwinner,sun6i-a31-mipi-dsi.yaml
> b/Documentation/devicetree/bindings/display/allwinner,sun6i-a31-mipi-dsi.yaml
> index 63f948175239..7aa330dabc44 100644
> ---
> a/Documentation/devicetree/bindings/display/allwinner,sun6i-a31-mipi-dsi.yaml
> +++
> b/Documentation/devicetree/bindings/display/allwinner,sun6i-a31-mipi-dsi.yaml
> @@ -11,9 +11,6 @@ maintainers:
>- Maxime Ripard
>
> properties:
> - "#address-cells": true
> - "#size-cells": true
> -
>compatible:
> enum:
>- allwinner,sun6i-a31-mipi-dsi
> @@ -57,12 +54,7 @@ properties:
>port should be the input endpoint, usually coming from the
>associated TCON.
>
> -patternProperties:
> - "^panel@[0-9]+$": true
> -
> required:
> - - "#address-cells"
> - - "#size-cells"
>- compatible
>- reg
>- interrupts
> @@ -74,6 +66,7 @@ required:
>- port
>
> allOf:
> + - $ref: dsi-controller.yaml#
>- if:
>properties:
> compatible:
> @@ -99,7 +92,7 @@ allOf:
> clocks:
>minItems: 1
>
> -additionalProperties: false
> +unevaluatedProperties: false
>
> examples:
>- |
> diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2835-dsi0.yaml
> b/Documentation/devicetree/bindings/display/brcm,bcm2835-dsi0.yaml
> index 3c643b227a70..eb44e072b6e5 100644
> --- a/Documentation/devicetree/bindings/display/brcm,bcm2835-dsi0.yaml
> +++ b/Documentation/devicetree/bindings/display/brcm,bcm2835-dsi0.yaml
> @@ -9,6 +9,9 @@ title: Broadcom VC4 (VideoCore4) DSI Controller
> maintainers:
>- Eric Anholt
>
> +allOf:
> + - $ref: dsi-controller.yaml#
> +
> properties:
>"#clock-cells":
> const: 1
> diff --git a/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
> b/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
> index b8ba6eb482a1..a125b2dd3a2f 100644
> --- a/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
> +++ b/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
> @@ -14,6 +14,9 @@ description: |
>NWL MIPI-DSI host controller found on i.MX8 platforms. This is a dsi
> bridge for
>the SOCs NWL MIPI-DSI host controller.
>
> +allOf:
> + - $ref: ../dsi-controller.yaml#
> +
> properties:
>compatible:
> const: fsl,imx8mq-nwl-dsi
> @@ -144,10 +147,6 @@ properties:
>
> additionalProperties: false
>
> -patternProperties:
> - "^panel@[0-9]+$":
> -type: object
> -
> required:
>- '#address-cells'
>- '#size-cells'
> @@ -163,7 +162,7 @@ required:
>- reset-names
>- resets
>
> -additionalProperties: false
> +unevaluatedProperties: false
>
> examples:
>- |
> @@ -172,7 +171,7 @@ examples:
> #include
> #include
>
> -mipi_dsi: mipi_dsi@30a0 {
> +dsi@30a0 {
>#address-cells = <1>;
>#size-cells = <0>;
>compatible = "fsl,imx8mq-nwl-dsi";
> diff --git a/Documentation/devicetree/bindings/display/st,stm32-dsi.yaml
> b/Documentation/devicetree/bindings/display/st,stm32-dsi.yaml
> index 69cc7e8bf15a..327a14d85df8 100644
> --- a/Documentation/devicetree/bindings/display/st,stm32-dsi.yaml
> +++ b/Documentation/devicetree/bindings/display/st,stm32-dsi.yaml
> @@ -13,6 +13,9 @@ maintainers:
> description:
>The STMicroelectronics STM32 DSI controller uses the Synopsys DesignWare
> MIPI-DSI host controller.
>
> +allOf:
> + - $ref: dsi-controller.yaml#
> +
> properties:
Re: [RFC PATCH v1 3/3] dt-binding: display: Require two rests on mantix panel
Hi Thierry, On Mon, Sep 28, 2020 at 08:50:39AM +0200, Thierry Reding wrote: > On Thu, Sep 24, 2020 at 09:38:07PM +0200, Sam Ravnborg wrote: > > Hi Guido. > > > > On Mon, Sep 21, 2020 at 06:55:52PM +0200, Guido Günther wrote: > > > We need to reset both for the panel to show an image. > > > > > > Signed-off-by: Guido Günther > > > --- > > > .../bindings/display/panel/mantix,mlaf057we51-x.yaml | 7 +-- > > > 1 file changed, 5 insertions(+), 2 deletions(-) > > > > > > diff --git > > > a/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml > > > > > > b/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml > > > index 937323cc9aaa..ba5a18fac9f9 100644 > > > --- > > > a/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml > > > +++ > > > b/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml > > > @@ -35,7 +35,9 @@ properties: > > >vddi-supply: > > > description: 1.8V I/O voltage supply > > > > > > - reset-gpios: true > > > + reset-gpios: > > > +minItems: 2 > > > +maxItems: 2 > > > > reset-gpios is, as you already wrote, defined in panel-common.yaml. > > Do not try to change it here. > > It would be much better, I think, to introduce a mantix,reset-gpios > > property. > > > > This would avoid that we had two different reset-gpios definitions. > > My understanding is that this will only override the defaults defined in > panel-common.yaml. So everything else about the > panel-common.yaml#/properties/reset-gpios definition remains valid and > all this does is say that when this matched on "mantix,mlaf057we51-x", > then the "reset-gpios" property is expected to contain two entries as > opposed to the single entry that is expected by default. I thought so too but I get: linux/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.example.dt.yaml: panel@0: reset-gpios: [[4294967295, 29, 1], [4294967295, 24, 1]] is too long From schema: /.../linux/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml It seems to bepossible to *extend* reset-gpios though because when i use an example like: reset-gpios = < 29 GPIO_ACTIVE_LOW>, < 24 GPIO_ACTIVE_LOW>; i correctly get linux/linux/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.example.dt.yaml: panel@0: reset-gpios: [[4294967295, 29, 1]] is too short From schema: /.../linux/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml so the `minItems: 2` is being picked up. This mens i can add properties but i can't overwrite the existing `maxItems: 2` - that's why i was wondering how that is supposed to work (if properties should be overrideable from common files or not). Cheers, -- Guido > > Thierry ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v1 3/3] dt-binding: display: Require two rests on mantix panel
Hi, On Mon, Sep 21, 2020 at 02:05:55PM -0300, Fabio Estevam wrote: > Hi Guido, > > On Mon, Sep 21, 2020 at 1:56 PM Guido Günther wrote: > > > > We need to reset both for the panel to show an image. > > There is a typo in "resets" in the Subject line. Fix queued for v2. Thanks! -- Guido ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH v1 1/3] drm/panel: mantix: Don't dereference NULL mode
Don't dereference mode which was just NULL checked.
Signed-off-by: Guido Günther
Reported-by: Dan Carpenter
---
drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
b/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
index 3482e28e30fc..4a7fbf64bb7a 100644
--- a/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
+++ b/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
@@ -204,7 +204,7 @@ static int mantix_get_modes(struct drm_panel *panel,
if (!mode) {
dev_err(ctx->dev, "Failed to add mode %ux%u@%u\n",
default_mode.hdisplay, default_mode.vdisplay,
- drm_mode_vrefresh(mode));
+ drm_mode_vrefresh(_mode));
return -ENOMEM;
}
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH v1 3/3] dt-binding: display: Require two rests on mantix panel
We need to reset both for the panel to show an image. Signed-off-by: Guido Günther --- .../bindings/display/panel/mantix,mlaf057we51-x.yaml | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml b/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml index 937323cc9aaa..ba5a18fac9f9 100644 --- a/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml +++ b/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml @@ -35,7 +35,9 @@ properties: vddi-supply: description: 1.8V I/O voltage supply - reset-gpios: true + reset-gpios: +minItems: 2 +maxItems: 2 backlight: true @@ -62,7 +64,8 @@ examples: avdd-supply = <_avdd>; avee-supply = <_avee>; vddi-supply = <_1v8_p>; -reset-gpios = < 29 GPIO_ACTIVE_LOW>; +reset-gpios = < 29 GPIO_ACTIVE_LOW>, + < 24 GPIO_ACTIVE_LOW>; backlight = <>; }; }; -- 2.26.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH v1 2/3] drm/panel: mantix: Fix panel reset
The mantix panel needs two reset lines (RESX and TP_RSTN) deasserted to
output an image. Only deasserting RESX is not enough and the display
will stay blank. Deassert in prepare() and assert in unprepare() to keep
device held in reset when off.
Signed-off-by: Guido Günther
---
.../gpu/drm/panel/panel-mantix-mlaf057we51.c | 37 ---
1 file changed, 24 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
b/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
index 4a7fbf64bb7a..29d28c63bb72 100644
--- a/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
+++ b/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
@@ -23,10 +23,13 @@
#define MANTIX_CMD_OTP_STOP_RELOAD_MIPI 0x41
#define MANTIX_CMD_INT_CANCEL 0x4C
+#define MANTIX_NUM_RESETS 2
+
struct mantix {
struct device *dev;
struct drm_panel panel;
- struct gpio_desc *reset_gpio;
+ /* RESX and TP_RSTN */
+ struct gpio_descs *reset_gpios;
struct regulator *avdd;
struct regulator *avee;
@@ -122,8 +125,13 @@ static int mantix_disable(struct drm_panel *panel)
static int mantix_unprepare(struct drm_panel *panel)
{
+ DECLARE_BITMAP(asserted_values, BITS_PER_TYPE(1));
struct mantix *ctx = panel_to_mantix(panel);
+ gpiod_set_array_value_cansleep(ctx->reset_gpios->ndescs,
+ ctx->reset_gpios->desc,
+ ctx->reset_gpios->info, asserted_values);
+
regulator_disable(ctx->avee);
regulator_disable(ctx->avdd);
/* T11 */
@@ -137,6 +145,7 @@ static int mantix_unprepare(struct drm_panel *panel)
static int mantix_prepare(struct drm_panel *panel)
{
+ DECLARE_BITMAP(deasserted_values, BITS_PER_TYPE(0));
struct mantix *ctx = panel_to_mantix(panel);
int ret;
@@ -165,14 +174,11 @@ static int mantix_prepare(struct drm_panel *panel)
return ret;
}
- /* T3+T5 */
- usleep_range(1, 12000);
-
- gpiod_set_value_cansleep(ctx->reset_gpio, 1);
- usleep_range(5150, 7000);
-
- gpiod_set_value_cansleep(ctx->reset_gpio, 0);
-
+ /* T3 + T4 + time for voltage to become stable: */
+ usleep_range(6000, 7000);
+ gpiod_set_array_value_cansleep(ctx->reset_gpios->ndescs,
+ ctx->reset_gpios->desc,
+ ctx->reset_gpios->info,
deasserted_values);
/* T6 */
msleep(50);
@@ -236,10 +242,15 @@ static int mantix_probe(struct mipi_dsi_device *dsi)
if (!ctx)
return -ENOMEM;
- ctx->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
- if (IS_ERR(ctx->reset_gpio)) {
- dev_err(dev, "cannot get reset gpio\n");
- return PTR_ERR(ctx->reset_gpio);
+ ctx->reset_gpios = devm_gpiod_get_array(dev, "reset", GPIOD_OUT_HIGH);
+ if (IS_ERR(ctx->reset_gpios)) {
+ dev_err(dev, "cannot get reset gpios\n");
+ return PTR_ERR(ctx->reset_gpios);
+ }
+
+ if (ctx->reset_gpios->ndescs != MANTIX_NUM_RESETS) {
+ dev_err(dev, "Need exactly %d reset-gpios\n",
MANTIX_NUM_RESETS);
+ return -EINVAL;
}
mipi_dsi_set_drvdata(dsi, ctx);
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH v1 0/3] drm/panel: mantix panel reset fixes
Posting as RFC since I'm not sure how to handle the bindings, please see below. The first patch in this series fixes dereferencing a NULL mode in the error path. The second one extends the resets to not only reset RESX but also TP_RSTN since otherwise the display will stay completely blank. I didn't spot that before initial submission since the reset line was bound to the touch controller and although that failed to probe it came far enough to deassert the reset line (at an arbitrary point in time during boot) and hence we got a picture. Since touch and panel are on the same IC they're not completely independent and i might have to turn the whole thing into an MFD at some point but this series gets the panel to a reliably working state on boot and on fb blank/unblank. Since the reset-gpios are active low we can deassert in prepare and assert in unprepare simplifying the code making sure lines are kept low when the panel is off. As for the bindings it seems I can't override the maxItems of reset-gpios since that is already set in bindings/display/panel/panel-common.yaml to maxItems: 1`. Is there a way to do that instead of side stepping the issue and using a different name or using enable-gpios for one of them or forcing everyone else to set `maxItems: 1`? The binding were not part of a stable kernel so I hope it's okay to not worry about backward compatibility. Guido Günther (3): drm/panel: mantix: Don't dereference NULL mode drm/panel: mantix: Fix panel reset dt-binding: display: Require two rests on mantix panel .../display/panel/mantix,mlaf057we51-x.yaml | 7 +++- .../gpu/drm/panel/panel-mantix-mlaf057we51.c | 39 --- 2 files changed, 30 insertions(+), 16 deletions(-) -- 2.26.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH][next] drm/panel: fix null pointer dereference on pointer mode
Hi,
On Fri, Sep 18, 2020 at 04:51:36PM +0100, Colin King wrote:
> From: Colin Ian King
>
> Currently a null pointer check on pointer mode is passing mode to
> function drm_mode_vrefresh and this causes a null pointer dereference
> on mode. Fix this by not calling drm_mode_vrefresh since the call
> is only required for error reporting.
>
> Addresses-Coverity: ("Dereference after null check")
> Fixes: 72967d5616d3 ("drm/panel: Add panel driver for the Mantix
> MLAF057WE51-X DSI panel")
> Signed-off-by: Colin Ian King
> ---
> drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
> b/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
> index 3482e28e30fc..be4761a643f9 100644
> --- a/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
> +++ b/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
> @@ -202,9 +202,8 @@ static int mantix_get_modes(struct drm_panel *panel,
>
> mode = drm_mode_duplicate(connector->dev, _mode);
> if (!mode) {
> - dev_err(ctx->dev, "Failed to add mode %ux%u@%u\n",
> - default_mode.hdisplay, default_mode.vdisplay,
> - drm_mode_vrefresh(mode));
> + dev_err(ctx->dev, "Failed to add mode %ux%u\n",
> + default_mode.hdisplay, default_mode.vdisplay);
> return -ENOMEM;
> }
drm_mode_vrefresh(_mode) gives some more clue what's going on -
I have had a fix queued up in my tree already but if you send a v2
that's fine.
Thanks!
-- Guido
>
> --
> 2.27.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/panel: st7703: Make jh057n00900_panel_desc static
Hi,
On Sat, Sep 12, 2020 at 11:38:09AM +0800, Jason Yan wrote:
> This eliminates the following sparse warning:
>
> drivers/gpu/drm/panel/panel-sitronix-st7703.c:156:26: warning: symbol
> 'jh057n00900_panel_desc' was not declared. Should it be static?
>
> Reported-by: Hulk Robot
> Signed-off-by: Jason Yan
> ---
> drivers/gpu/drm/panel/panel-sitronix-st7703.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> index c22e7c49e077..7c07a8fc8506 100644
> --- a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> +++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> @@ -153,7 +153,7 @@ static const struct drm_display_mode jh057n00900_mode = {
> .height_mm = 130,
> };
>
> -struct st7703_panel_desc jh057n00900_panel_desc = {
> +static struct st7703_panel_desc jh057n00900_panel_desc = {
Can we even make it `static const`? With that
Reviewed-by: Guido Günther
Cheers,
-- Guido
> .mode = _mode,
> .lanes = 4,
> .mode_flags = MIPI_DSI_MODE_VIDEO |
> --
> 2.25.4
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/5] drm/bridge: nwl-dsi: Add support for clock-drop-level
Hi Robert,
On Fri, Aug 28, 2020 at 02:13:30PM +0300, Robert Chiras (OSS) wrote:
> From: Robert Chiras
>
> The clock-drop-level is needed in order to add more blanking space needed
> by DSI panels when sending DSI commands. One level is the equivalent of
> phy_ref rate from the PLL rate. Since the PLL rate is targeted as highest
> possible, each level should not get the crtc_clock too low, compared to
> the actual clock.
Did you check whether this is only needed during panel prepare (when the
image sequence is being sent)? I wonder if this is an artifact of the
driver sending pixel data too early - and if it's not whether we have
something else wrong so that we need to have a longer blanking period
with some panels?
Cheers,
-- Guido
>
> Example for a clock of 132M, with "clock-drop-level = <1>" in dts file
> will result in a crtc_clock of 129M, using the following logic:
> - video_pll rate to provide both phy_ref rate of 24M and pixel-clock
> of 132M is 1056M (divisor /43 for phy_ref and /8 for pixel-clock)
> - from this rate, we subtract the equivalent of phy_ref (24M) but
> keep the same divisor. This way, the video_pll rate will be 1056 - 24
> = 1032M.
> - new pixel-clock will be: 1032 / 8 = 129M
>
> For a "clock-drop-level = <2>", new pixel-clock will be:
> (1056 - (24 * 2)) / 8 = 1008 / 8 = 126M
>
> Signed-off-by: Robert Chiras
> ---
> drivers/gpu/drm/bridge/nwl-dsi.c | 12
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/nwl-dsi.c
> b/drivers/gpu/drm/bridge/nwl-dsi.c
> index 1228466..ac4aa0a 100644
> --- a/drivers/gpu/drm/bridge/nwl-dsi.c
> +++ b/drivers/gpu/drm/bridge/nwl-dsi.c
> @@ -142,6 +142,7 @@ struct nwl_dsi {
>
> struct nwl_dsi_transfer *xfer;
> struct list_head valid_modes;
> + u32 clk_drop_lvl;
> };
>
> static const struct regmap_config nwl_dsi_regmap_config = {
> @@ -842,13 +843,14 @@ static unsigned long nwl_dsi_get_lcm(unsigned long a,
> unsigned long b)
>
> return ((unsigned long long)a * b) / gcf;
> }
> -
> /*
> * This function tries to adjust the crtc_clock for a DSI device in such a
> way
> * that the video pll will be able to satisfy both Display Controller pixel
> * clock (feeding out DPI interface) and our input phy_ref clock.
> + * Also, the DC pixel clock must be lower than the actual clock in order to
> + * have enough blanking space to send DSI commands, if the device is a panel.
> */
> -static void nwl_dsi_setup_pll_config(struct mode_config *config)
> +static void nwl_dsi_setup_pll_config(struct mode_config *config, u32 lvl)
> {
> unsigned long pll_rate;
> int div;
> @@ -908,7 +910,6 @@ static void nwl_dsi_setup_pll_config(struct mode_config
> *config)
> }
> }
>
> -
> /*
> * This function will try the required phy speed for current mode
> * If the phy speed can be achieved, the phy will save the speed
> @@ -1103,7 +1104,7 @@ nwl_dsi_bridge_mode_valid(struct drm_bridge *bridge,
>
> pll_rate = config->pll_rates[config->phy_rate_idx];
> if (dsi->pll_clk && !pll_rate)
> - nwl_dsi_setup_pll_config(config);
> + nwl_dsi_setup_pll_config(config, dsi->clk_drop_lvl);
>
> return MODE_OK;
> }
> @@ -1248,6 +1249,7 @@ static const struct drm_bridge_funcs
> nwl_dsi_bridge_funcs = {
> static int nwl_dsi_parse_dt(struct nwl_dsi *dsi)
> {
> struct platform_device *pdev = to_platform_device(dsi->dev);
> + struct device_node *np = dsi->dev->of_node;
> struct clk *clk;
> void __iomem *base;
> int ret;
> @@ -1364,6 +1366,8 @@ static int nwl_dsi_parse_dt(struct nwl_dsi *dsi)
> return PTR_ERR(dsi->rst_dpi);
> }
>
> + of_property_read_u32(np, "fsl,clock-drop-level", >clk_drop_lvl);
> +
> INIT_LIST_HEAD(>valid_modes);
>
> return 0;
> --
> 2.7.4
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 0/5] Add support for iMX8MQ Display Controller Subsystem
Hi Laurentiu, On Fri, Jul 31, 2020 at 10:54:29AM +0200, Guido Günther wrote: > Hi, > On Fri, Jul 31, 2020 at 11:18:28AM +0300, Laurentiu Palcu wrote: > > From: Laurentiu Palcu > > > > Hi, > > > > This patchset adds initial DCSS support for iMX8MQ chip. Initial support > > includes only graphics plane support (no video planes), no HDR10 > > capabilities, > > no graphics decompression (only linear, tiled and super-tiled buffers > > allowed). > > > > Support for the rest of the features will be added incrementally, in > > subsequent > > patches. > > > > The patchset was tested with both HDP driver (in the downstream tree) and > > the upstream > > MIPI-DSI driver (with a couple of patches on top, to make it work correctly > > with DCSS). > > > > Thanks, > > Laurentiu > > > > Changes in v9: > > * Fixed a compilation issue found by Guido in his setup: 'select > >VIDEOMODE_HELPERS' was missing from Kconfig; > > * Use imx8mq-clock.h in the bindings file so one can understand what > >those clock values mean; > > * no other changes done. Couldn't address the hang Guido reported as > >it's not happening in my setup. However, in my tree, there are some > >extra NWL and ADV patches applied on top of upstream ones... Also, > >removing them and testing only with upstream, even if there's no > >image out, does not produce a hang... :/ > > I don't think this should hold up merging. And i retested your v9 series on next-20200903 on a librem5 devkit and it works. Looking back I spotted an error in my clock configuration, so Tested-by: Guido Günther Cheers, -- Guido > Cheers, > -- Guido > > > > > Changes in v8: > > * Removed 'select RESET_CONTROLLER" from Kconfig as Philipp pointed > >out. SRC is not used in DCSS driver; > > * Nothing else changed; > > > > Changes in v7: > > * Added a patch to initialize the connector using the drm_bridge_connector > >API as Sam suggested. Tested it using NWL_DSI and ADV7535 with > >Guido's patch [1] applied and one fix for ADV [2]. Also, some extra > >patches for ADV and NWL were needed, from our downstream tree, which > >will be upstreamed soon by their author; > > * Rest of the patches are untouched; > > > > [1] https://lists.freedesktop.org/archives/dri-devel/2020-July/273025.html > > [2] https://lists.freedesktop.org/archives/dri-devel/2020-July/273132.html > > > > Changes in v6: > > * Addressed Rob's comment and added "additionalProperties: false" at > >the end of the bindings' properties. However, this change surfaced > >an issue with the assigned-clock* properties not being documented in > >the properties section. Added the descriptions and the bindings patch > >will need another review; > > * Added an entry for DCSS driver in the MAINTAINERS file; > > * Removed the component framework patch altogether; > > > > Changes in v5: > > * Rebased to latest; > > * Took out component framework support and made it a separate patch so > >that people can still test with HDP driver, which makes use of it. > >But the idea is to get rid of it once HDP driver's next versions > >will remove component framework as well; > > * Slight improvement to modesetting: avoid cutting off the pixel clock > >if the new mode and the old one are equal. Also, in this case, is > >not necessary to wait for DTG to shut off. This would allow to switch > >from 8b RGB to 12b YUV422, for example, with no interruptions (at least > >from DCSS point of view); > > * Do not fire off CTXLD when going to suspend, unless it still has > >entries that need to be committed to DCSS; > > * Addressed Rob's comments on bindings; > > > > Changes in v4: > > * Addressed Lucas and Philipp's comments: > >* Added DRM_KMS_CMA_HELPER dependency in Kconfig; > >* Removed usage of devm_ functions since I'm already doing all the > > clean-up in the submodules_deinit(); > >* Moved the drm_crtc_arm_vblank_event() in dcss_crtc_atomic_flush(); > >* Removed en_completion variable from dcss_crtc since this was > > introduced mainly to avoid vblank timeout warnings which were fixed > > by arming the vblank event in flush() instead of begin(); > >* Removed clks_on and irq_enabled flags since all the calls to > > enabling/disabling clocks and interrupts were balanced; > >* Removed the custom atomic_commit callback and used the DRM core >
Re: [PATCH 0/5] Add new features to nwl-dsi driver
Hi Robert, On Fri, Aug 28, 2020 at 02:13:27PM +0300, Robert Chiras (OSS) wrote: > From: Robert Chiras > > This patch-set adds the new following features to the nwl-dsi bridge driver: > > 1. Control Video PLL from nwl-dsi driver > > Add support for the Video PLL into the nwl-dsi driver, in order > to better control it's rate, depending on the requested video mode. > Controlling the Video PLL from nwl-dsi is usefull, since it both drives the DC > pixel-clock and DPHY phy_ref clock. > On i.MX8MQ, the DC can be either DCSS or LCDIF. > > 2. Add new property to nwl-dsi: clock-drop-level > > This new property is usefull in order to use DSI panels with the nwl-dsi > driver which require a higher overhead to the pixel-clock. > For example, the Raydium RM67191 DSI Panel works with 132M pixel-clock, > but it needs an overhead in order to work properly. So, the actual pixel-clock > fed into the DSI DPI interface needs to be lower than the one used ad DSI > output. > This new property addresses this matter. > > 3. Add support to handle both inputs for nwl-dsi: DCSS and LCDIF Thanks. I've tested the drop-clock-level part with mxsfb on a Librem 5 devkit and it removes the slight flickering we've seen before (and which could be worked around by reducing the input pixel clock so 1 and 3 are Tested-by: Guido Günther I've have added some comments to the individual patches and try to get around to check out the DCSS part too. Cheers, -- Guido > > Laurentiu Palcu (1): > drm/bridge: nwl-dsi: add support for DCSS > > Robert Chiras (4): > drm/bridge: nwl-dsi: Add support for video_pll > dt-bindings: display/bridge: nwl-dsi: Document video_pll clock > drm/bridge: nwl-dsi: Add support for clock-drop-level > dt-bindings: display/bridge: nwl-dsi: Document fsl,clock-drop-level > property > > .../bindings/display/bridge/nwl-dsi.yaml | 7 + > drivers/gpu/drm/bridge/nwl-dsi.c | 338 > - > 2 files changed, 336 insertions(+), 9 deletions(-) > > -- > 2.7.4 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/5] dt-bindings: display/bridge: nwl-dsi: Document fsl,clock-drop-level property
Hi, On Fri, Aug 28, 2020 at 02:13:31PM +0300, Robert Chiras (OSS) wrote: > From: Robert Chiras > > Add documentation for a new property: 'fsl,clock-drop-level'. > > Signed-off-by: Robert Chiras > --- > Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml | 4 > 1 file changed, 4 insertions(+) > > diff --git a/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml > b/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml > index 8b5741b..b415f4e 100644 > --- a/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml > +++ b/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml > @@ -143,6 +143,10 @@ properties: > > additionalProperties: false > > + clock-drop-level: Property is called fsl,clock-drop-level. > +description: > + Specifies the level at wich the crtc_clock should be dropped > + > patternProperties: >"^panel@[0-9]+$": > type: object > -- > 2.7.4 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/5] drm/bridge: nwl-dsi: Add support for video_pll
Hi Robert,
On Fri, Aug 28, 2020 at 02:13:28PM +0300, Robert Chiras (OSS) wrote:
> From: Robert Chiras
>
> This patch adds support for a new clock 'video_pll' in order to better
> set the video_pll clock to a clock-rate that satisfies a mode's clock.
> The video PLL, on i.MX8MQ, can drive both DC pixel-clock and DSI phy_ref
> clock. When used with a bridge that can drive multiple modes, like a DSI
> to HDMI bridge, the DSI can't be statically configured for a specific
> mode in the DTS file.
> So, this patch adds access to the video PLL inside the DSI driver, so
> that modes can be filtered-out if the required combination of phy_ref
> and pixel-clock can't be achieved using the video PLL.
>
> Signed-off-by: Robert Chiras
> ---
> drivers/gpu/drm/bridge/nwl-dsi.c | 318
> ++-
> 1 file changed, 313 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/nwl-dsi.c
> b/drivers/gpu/drm/bridge/nwl-dsi.c
> index ce94f79..1228466 100644
> --- a/drivers/gpu/drm/bridge/nwl-dsi.c
> +++ b/drivers/gpu/drm/bridge/nwl-dsi.c
> @@ -39,6 +39,20 @@
>
> #define NWL_DSI_MIPI_FIFO_TIMEOUT msecs_to_jiffies(500)
>
> +/* Maximum Video PLL frequency: 1.2GHz */
> +#define MAX_PLL_FREQ 12
> +
> +#define MBPS(x) ((x) * 100)
> +#define MIN_PHY_RATE MBPS(24)
> +#define MAX_PHY_RATE MBPS(30)
> +
> +/* Possible valid PHY reference clock rates*/
nitpick: missing ' ' at end of comment.
> +static u32 phyref_rates[] = {
> + 2700,
> + 2500,
> + 2400,
> +};
> +
> enum transfer_direction {
> DSI_PACKET_SEND,
> DSI_PACKET_RECEIVE,
> @@ -67,6 +81,17 @@ struct nwl_dsi_transfer {
> size_t rx_len; /* in bytes */
> };
>
> +struct mode_config {
Maybe use nwl_mode_config ? There's so much other mode_config around an
this makes it obvious it's driver specific.
> + int clock;
> + int crtc_clock;
> + unsigned intlanes;
> + unsigned long bitclock;
> + unsigned long phy_rates[3];
> + unsigned long pll_rates[3];
> + int phy_rate_idx;
> + struct list_headlist;
> +};
> +
> struct nwl_dsi {
> struct drm_bridge bridge;
> struct mipi_dsi_host dsi_host;
> @@ -101,6 +126,7 @@ struct nwl_dsi {
> struct clk *rx_esc_clk;
> struct clk *tx_esc_clk;
> struct clk *core_clk;
> + struct clk *pll_clk;
> /*
>* hardware bug: the i.MX8MQ needs this clock on during reset
>* even when not using LCDIF.
> @@ -115,6 +141,7 @@ struct nwl_dsi {
> int error;
>
> struct nwl_dsi_transfer *xfer;
> + struct list_head valid_modes;
> };
>
> static const struct regmap_config nwl_dsi_regmap_config = {
> @@ -778,6 +805,207 @@ static void nwl_dsi_bridge_disable(struct drm_bridge
> *bridge)
> pm_runtime_put(dsi->dev);
> }
>
> +static unsigned long nwl_dsi_get_bit_clock(struct nwl_dsi *dsi,
> + unsigned long pixclock, u32 lanes)
> +{
> + int bpp;
> +
> + if (lanes < 1 || lanes > 4)
> + return 0;
> +
> + bpp = mipi_dsi_pixel_format_to_bpp(dsi->format);
> +
> + return (pixclock * bpp) / lanes;
> +}
> +
> +/*
> + * Utility function to calculate least commom multiple, using an
> improved
s/commom/common/
> + * version of the Euclidean algorithm for greatest common factor.
> + */
> +static unsigned long nwl_dsi_get_lcm(unsigned long a, unsigned long b)
> +{
> + u32 gcf = 0; /* greatest common factor */
> + unsigned long tmp_a = a;
> + unsigned long tmp_b = b;
> +
> + if (!a || !b)
> + return 0;
> +
> + while (tmp_a % tmp_b) {
> + gcf = tmp_a % tmp_b;
> + tmp_a = tmp_b;
> + tmp_b = gcf;
> + }
> +
> + if (!gcf)
> + return a;
> +
> + return ((unsigned long long)a * b) / gcf;
> +}
> +
> +/*
> + * This function tries to adjust the crtc_clock for a DSI device in such a
> way
> + * that the video pll will be able to satisfy both Display Controller pixel
> + * clock (feeding out DPI interface) and our input phy_ref clock.
> + */
> +static void nwl_dsi_setup_pll_config(struct mode_config *config)
> +{
> + unsigned long pll_rate;
> + int div;
> + size_t i, num_rates = ARRAY_SIZE(config->phy_rates);
> +
> + config->crtc_clock = 0;
> +
> + for (i = 0; i < num_rates; i++) {
> + int crtc_clock;
> +
> + if (!config->phy_rates[i])
> + break;
> + /*
> + * First, we need to check if phy_ref can actually be obtained
> + * from pixel clock. To do this, we check their lowest common
> + * multiple, which has to be in PLL range.
> + */
> + pll_rate = nwl_dsi_get_lcm(config->clock, config->phy_rates[i]);
> + if (pll_rate >
Re: [PATCH 5/5] drm/bridge: nwl-dsi: add support for DCSS
Hi,
On Fri, Aug 28, 2020 at 02:13:32PM +0300, Robert Chiras (OSS) wrote:
> From: Laurentiu Palcu
>
> DCSS needs active low VSYNC and HSYNC. Also, move the input selection in
> the probe function, as this will not change at runtime.
>
> Signed-off-by: Laurentiu Palcu
> Signed-off-by: Robert Chiras
> ---
> drivers/gpu/drm/bridge/nwl-dsi.c | 24
> 1 file changed, 16 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/nwl-dsi.c
> b/drivers/gpu/drm/bridge/nwl-dsi.c
> index ac4aa0a..c30f7a8 100644
> --- a/drivers/gpu/drm/bridge/nwl-dsi.c
> +++ b/drivers/gpu/drm/bridge/nwl-dsi.c
> @@ -143,6 +143,7 @@ struct nwl_dsi {
> struct nwl_dsi_transfer *xfer;
> struct list_head valid_modes;
> u32 clk_drop_lvl;
> + bool use_dcss;
> };
>
> static const struct regmap_config nwl_dsi_regmap_config = {
> @@ -1036,16 +1037,16 @@ static int nwl_dsi_get_dphy_params(struct nwl_dsi
> *dsi,
>
> static bool nwl_dsi_bridge_mode_fixup(struct drm_bridge *bridge,
> const struct drm_display_mode *mode,
> - struct drm_display_mode *adjusted_mode)
> + struct drm_display_mode *adjusted)
why the rename?
> {
> struct nwl_dsi *dsi = bridge_to_dsi(bridge);
> struct mode_config *config;
> unsigned long pll_rate;
>
> DRM_DEV_DEBUG_DRIVER(dsi->dev, "Fixup mode:\n");
> - drm_mode_debug_printmodeline(adjusted_mode);
> + drm_mode_debug_printmodeline(adjusted);
>
> - config = nwl_dsi_mode_probe(dsi, adjusted_mode);
> + config = nwl_dsi_mode_probe(dsi, adjusted);
> if (!config)
> return false;
>
> @@ -1067,12 +1068,16 @@ static bool nwl_dsi_bridge_mode_fixup(struct
> drm_bridge *bridge,
> }
> /* Update the crtc_clock to be used by display controller */
> if (config->crtc_clock)
> - adjusted_mode->crtc_clock = config->crtc_clock / 1000;
> + adjusted->crtc_clock = config->crtc_clock / 1000;
>
> -
> - /* At least LCDIF + NWL needs active high sync */
> - adjusted_mode->flags |= (DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC);
> - adjusted_mode->flags &= ~(DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC);
> + if (!dsi->use_dcss) {
> + /* At least LCDIF + NWL needs active high sync */
> + adjusted->flags |= (DRM_MODE_FLAG_PHSYNC |
> DRM_MODE_FLAG_PVSYNC);
> + adjusted->flags &= ~(DRM_MODE_FLAG_NHSYNC |
> DRM_MODE_FLAG_NVSYNC);
> + } else {
> + adjusted->flags &= ~(DRM_MODE_FLAG_PHSYNC |
> DRM_MODE_FLAG_PVSYNC);
> + adjusted->flags |= (DRM_MODE_FLAG_NHSYNC |
> DRM_MODE_FLAG_NVSYNC);
> + }
>
> return true;
> }
> @@ -1400,6 +1405,9 @@ static int nwl_dsi_select_input(struct nwl_dsi *dsi)
> DRM_DEV_ERROR(dsi->dev, "Failed to select input: %d\n", ret);
>
> of_node_put(remote);
> +
> + dsi->use_dcss = use_dcss;
If we need to preserve it we can assign `dsi->use_dcss` directly and
drop `use_dcss`.
Cheers,
-- Guido
> +
> return ret;
> }
>
> --
> 2.7.4
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [bug report] drm/panel: Add panel driver for the Mantix MLAF057WE51-X DSI panel
Hi,
On Mon, Aug 31, 2020 at 02:29:24PM +0300, Dan Carpenter wrote:
> Hello Guido Günther,
>
> The patch 72967d5616d3: "drm/panel: Add panel driver for the Mantix
> MLAF057WE51-X DSI panel" from Aug 17, 2020, leads to the following
> static checker warning:
>
> drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c:205 mantix_get_modes()
> error: we previously assumed 'mode' could be null (see line 204)
>
> drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
>197 static int mantix_get_modes(struct drm_panel *panel,
>198 struct drm_connector *connector)
>199 {
>200 struct mantix *ctx = panel_to_mantix(panel);
>201 struct drm_display_mode *mode;
>202
>203 mode = drm_mode_duplicate(connector->dev, _mode);
>204 if (!mode) {
>205 dev_err(ctx->dev, "Failed to add mode %ux%u@%u\n",
>206 default_mode.hdisplay, default_mode.vdisplay,
>207 drm_mode_vrefresh(mode));
>
> This will lead to a NULL dereference.
Thanks, i'll fold a fix for this into some other upcoming changes to
this driver.
Cheers,
-- Guido
>
>208 return -ENOMEM;
>209 }
>210
>211 drm_mode_set_name(mode);
>212
>213 mode->type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED;
>214 connector->display_info.width_mm = mode->width_mm;
>215 connector->display_info.height_mm = mode->height_mm;
>216 drm_mode_probed_add(connector, mode);
>217
>218 return 1;
>219 }
>
> regards,
> dan carpenter
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 0/3] drm: Add support for Cadence MHDP DPI/DP bridge and J721E wrapper.
Hi Swapnil, On Mon, Aug 24, 2020 at 07:16:31AM +, Swapnil Kashinath Jakhade wrote: [..snip..] > Following are the differences between MHDP IPs from Cadence for Rockchip, TI > and NxP: > > The Rockchip and NXP MHDP Core shares the same part (IP8501) which is DP v1.3 > SST > Controller with HDCP 2.2/1.x. NXP's version additionally supports HDMI. > TI uses a different part (IP8546A), which is DP v1.4 with HDCP 2.2/1.x. > TI DP Controller adds support for additional features such as Multi Stream > Support (MST), > Forward Error Correction (FEC) and Compression (DSC). > > Also, FW used for TI has significant differences than FW used for Rockchip or > NXP. > NxP and TI firmware are developed and maintained separately by Cadence and > are in > active support. > > From the Linux driver perspective, given the differences, it would make sense > to have > TI driver maintained separately. Thanks for the clarification, that indeed helps a lot. So the rockchip and nxp drivers can be merged while the ti one should stay separate. Cheers, -- Guido > > Thanks, > Swapnil > > > > > > I'm worried that if there are IP differences, even if not great ones, > > > and if the FWs are different and developed separately, it'll be a > > > constant "fix X for SoC A, and accidentally break Y for SoC B and C", > > especially if too much code is shared. > > > > > > In the long run I'm all for a single driver (or large shared parts), > > > but I'm not sure if we should start with that approach. > > > > > > > > > > > > > > Tomi > > > > > > -- > > > Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. > > > Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki > > > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 0/3] drm/panel: Add panel driver for the Mantix MLAF057WE51-X DSI panel
Hi Sam,
On Tue, Aug 18, 2020 at 07:05:56PM +0200, Sam Ravnborg wrote:
> Hi Guido.
>
> On Mon, Aug 17, 2020 at 10:14:33AM +0200, Guido Günther wrote:
> >
> > The panel uses a Focaltech FT8006p, the touch part is handled by the already
> > existing edt-ft5x06. It can be found in e.g. the Librem 5.
> >
> > Changes from v2:
> > - Due to review comments by Sam Ravnborg, thanks!
> > https://lore.kernel.org/lkml/20200815212727.ga1244...@ravnborg.org/
> > - Drop unused header
> > - Use newline before comment
> > - Add Reviewed/Acked-by by Sam Ravnborg, thanks!
> > https://lore.kernel.org/lkml/20200815212727.ga1244...@ravnborg.org/
> > https://lore.kernel.org/lkml/20200815212750.gb1244...@ravnborg.org/
> > https://lore.kernel.org/lkml/20200815212840.gc1244...@ravnborg.org/
> >
> > Changes from v1:
> > - Due to review comments by Sam Ravnborg, thanks!
> > https://lore.kernel.org/dri-devel/20200815083917.ga993...@ravnborg.org/
> > - Don't preserve newlines with '|' in description
> > - Use reset-gpios and backlight from panel-common.yaml
> > - Reindent example
> > https://lore.kernel.org/dri-devel/20200815093226.gb993...@ravnborg.org/
> > - Drop unused includes
> > - Use dev_* instead of DRM_* for printing
> > - Turn off regulators in reverse order from enable
> > - Silence errors in mantix_{shutdown,remove}
> > - Drop duplicate mipi_dsi_dcs_enter_sleep_mode()
> > https://lore.kernel.org/dri-devel/20200815100230.ga1002...@ravnborg.org/
> > - Use dev_err_probe()
> > - Add delays when turning off panel as suggested by the data sheet
> >
> > This series is against next-20200814.
> >
> > Guido Günther (3):
> > dt-bindings: vendor-prefixes: Add mantix vendor prefix
> > dt-bindings: Add Mantix MLAF057WE51-X panel bindings
> > drm/panel: Add panel driver for the Mantix MLAF057WE51-X DSI panel
>
> Maxime Ripard backmerged -rc1 to drm-misc-next so I went ahead and applied
> this series to drm-misc-next, forgetting you got commit rights. As they are
> already pushed out too late for you to do push them - sorry!
On the contrary: Thanks a lot for handling this so promptly!
-- Guido
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/3] drm/panel: Add panel driver for the Mantix MLAF057WE51-X DSI panel
Hi Sam, On Sun, Aug 16, 2020 at 09:04:17PM +0200, Sam Ravnborg wrote: > On Sun, Aug 16, 2020 at 07:55:21PM +0200, Guido Günther wrote: > > Hi Sam, > > thanks for having a look! > > > > On Sat, Aug 15, 2020 at 11:27:27PM +0200, Sam Ravnborg wrote: > > > Hi Guido. > > > > > > On Sat, Aug 15, 2020 at 11:16:22PM +0200, Guido Günther wrote: > > > > The panel uses a Focaltech FT8006p, the touch part is handled by the > > > > already existing edt-ft5x06. > > > > > > > > Signed-off-by: Guido Günther > > > > > > Two small nits - otherwise looks good. > > > Reviewed-by: Sam Ravnborg > > > > > > I can fix while applying or you can send a new revision, > > > but I cannot apply until drm-misc-next have seen a backmerge > > > due to dev_err_probe() usage. > > > > I'll send out a v3 with this fixed. > > > > > Did you have commit rights yet? > > > If yes, then please apply yourself. > > > > No commit rights here. So it would be great if you could apply the > > patches. Should I look for commit rights? I assume that means following > > > > > > https://drm.pages.freedesktop.org/maintainer-tools/commit-access.html#drm-misc > > > I recall we discussed this before for some other driver. > For a single panel it is not needed, but if you continue to be active > on other parts it makes sense. I think st7703, mantix and nwl all go in via drm-misc so it might make sense. Thanks for the suggestion! > I will apply v3 when drm-misc-next is backmeged unless you tell me > otherwise. And ping me if I forgets. Thanks! -- Guido ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/2] Modernize rocktech,jh057n00900 bindings a bit
Hi, On Sun, Aug 16, 2020 at 05:25:34PM +0200, Sam Ravnborg wrote: > Hi Guido. > > On Sun, Aug 16, 2020 at 09:13:41AM +0200, Guido Günther wrote: > > This was prompted by Sam's review in > > https://lore.kernel.org/dri-devel/20200815210802.ga1242...@ravnborg.org/ > > and yamllint. I also added myself as maintainer, hope that's o.k. > > > > Guido Günther (2): > > dt-bindings: panel: rocktech,jh057n00900: Modernize > > dt-bindings: panel: rocktech,jh057n00900: Add myself as maintainer > > Thanks for this nice clean-up, and always good with an extra person > caring for something. > Applied to drm-misc-next Thanks! -- Guido > > Sam > > > > > .../display/panel/rocktech,jh057n00900.yaml | 40 +-- > > 1 file changed, 19 insertions(+), 21 deletions(-) > > > > -- > > 2.26.2 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/3] dt-bindings: Add Mantix MLAF057WE51-X panel bindings
The panel uses a Focaltech FT8006p, the touch part is handled by the
already existing edt-ft5x06.
Signed-off-by: Guido Günther
Reviewed-by: Sam Ravnborg
---
.../display/panel/mantix,mlaf057we51-x.yaml | 70 +++
1 file changed, 70 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml
b/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml
new file mode 100644
index 0..937323cc9aaac
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml
@@ -0,0 +1,70 @@
+# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/mantix,mlaf057we51-x.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mantix MLAF057WE51-X 5.7" 720x1440 TFT LCD panel
+
+maintainers:
+ - Guido Günther
+
+description:
+ Mantix MLAF057WE51 X is a 720x1440 TFT LCD panel connected using
+ a MIPI-DSI video interface.
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+enum:
+ - mantix,mlaf057we51-x
+
+ port: true
+ reg:
+maxItems: 1
+description: DSI virtual channel
+
+ avdd-supply:
+description: Positive analog power supply
+
+ avee-supply:
+description: Negative analog power supply
+
+ vddi-supply:
+description: 1.8V I/O voltage supply
+
+ reset-gpios: true
+
+ backlight: true
+
+required:
+ - compatible
+ - reg
+ - avdd-supply
+ - avee-supply
+ - vddi-supply
+ - reset-gpios
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+
+dsi {
+#address-cells = <1>;
+#size-cells = <0>;
+panel@0 {
+compatible = "mantix,mlaf057we51-x";
+reg = <0>;
+avdd-supply = <_avdd>;
+avee-supply = <_avee>;
+vddi-supply = <_1v8_p>;
+reset-gpios = < 29 GPIO_ACTIVE_LOW>;
+backlight = <>;
+};
+};
+
+...
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/3] dt-bindings: vendor-prefixes: Add mantix vendor prefix
Add prefix for Mantix Display Technology Co.,Ltd. Signed-off-by: Guido Günther Acked-by: Sam Ravnborg --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 2baee2c817c1a..59d4c8b068c4d 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -611,6 +611,8 @@ patternProperties: description: Linux Automation GmbH "^macnica,.*": description: Macnica Americas + "^mantix,.*": +description: Mantix Display Technology Co.,Ltd. "^mapleboard,.*": description: Mapleboard.org "^marvell,.*": -- 2.26.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 3/3] drm/panel: Add panel driver for the Mantix MLAF057WE51-X DSI panel
The panel uses a Focaltech FT8006p, the touch part is handled by the
already existing edt-ft5x06.
Signed-off-by: Guido Günther
Reviewed-by: Sam Ravnborg
---
MAINTAINERS | 7 +
drivers/gpu/drm/panel/Kconfig | 11 +
drivers/gpu/drm/panel/Makefile| 1 +
.../gpu/drm/panel/panel-mantix-mlaf057we51.c | 328 ++
4 files changed, 347 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 83ba7b62651f7..7dfe4cc3d4ec8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5474,6 +5474,13 @@ S: Maintained
F: drivers/gpu/drm/panel/panel-lvds.c
F: Documentation/devicetree/bindings/display/panel/lvds.yaml
+DRM DRIVER FOR MANTIX MLAF057WE51 PANELS
+M: Guido Günther
+R: Purism Kernel Team
+S: Maintained
+F:
Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml
+F: drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
+
DRM DRIVER FOR MATROX G200/G400 GRAPHICS CARDS
S: Orphan / Obsolete
F: drivers/gpu/drm/mga/
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index de2f2a452be55..8d97d07c58713 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -217,6 +217,17 @@ config DRM_PANEL_NOVATEK_NT39016
Say Y here if you want to enable support for the panels built
around the Novatek NT39016 display controller.
+config DRM_PANEL_MANTIX_MLAF057WE51
+ tristate "Mantix MLAF057WE51-X MIPI-DSI LCD 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 Mantix
+ MLAF057WE51-X MIPI DSI panel as e.g. used in the Librem 5. It
+ has a resolution of 720x1440 pixels, a built in backlight and touch
+ controller.
+
config DRM_PANEL_OLIMEX_LCD_OLINUXINO
tristate "Olimex LCD-OLinuXino panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index e45ceac6286fd..15a4e77529514 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -20,6 +20,7 @@ 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_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
obj-$(CONFIG_DRM_PANEL_ORISETECH_OTM8009A) += panel-orisetech-otm8009a.o
obj-$(CONFIG_DRM_PANEL_OSD_OSD101T2587_53TS) += panel-osd-osd101t2587-53ts.o
diff --git a/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
b/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
new file mode 100644
index 0..3482e28e30fc9
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
@@ -0,0 +1,328 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Mantix MLAF057WE51 5.7" MIPI-DSI panel driver
+ *
+ * Copyright (C) Purism SPC 2020
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include
+#include
+#include
+
+#define DRV_NAME "panel-mantix-mlaf057we51"
+
+/* Manufacturer specific Commands send via DSI */
+#define MANTIX_CMD_OTP_STOP_RELOAD_MIPI 0x41
+#define MANTIX_CMD_INT_CANCEL 0x4C
+
+struct mantix {
+ struct device *dev;
+ struct drm_panel panel;
+ struct gpio_desc *reset_gpio;
+
+ struct regulator *avdd;
+ struct regulator *avee;
+ struct regulator *vddi;
+};
+
+static inline struct mantix *panel_to_mantix(struct drm_panel *panel)
+{
+ return container_of(panel, struct mantix, panel);
+}
+
+#define dsi_generic_write_seq(dsi, seq...) do {
\
+ static const u8 d[] = { seq }; \
+ int ret;\
+ ret = mipi_dsi_generic_write(dsi, d, ARRAY_SIZE(d));\
+ if (ret < 0)\
+ return ret; \
+ } while (0)
+
+static int mantix_init_sequence(struct mantix *ctx)
+{
+ struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
+ struct device *dev = ctx->dev;
+
+ /*
+* Init sequence was supplied by the panel vendor.
+*/
+ dsi_generic_write_seq(dsi, MANTIX_CMD_OTP_STOP_RELOAD_MIPI, 0x5A);
+
+ dsi_generic_write_seq(dsi, MANTIX_CMD_INT_CANCEL, 0x03);
+ dsi_generic_write_seq(dsi, MANTIX_CMD_OTP_STOP_RELOAD_MIPI, 0x5A, 0x03);
+ dsi_generic_write_seq(dsi, 0x80, 0xA9, 0x00);
+
+ dsi_generic_write_seq(dsi, MANTIX_CMD_OTP_STOP_RELOAD_MIPI, 0x5A, 0x
[PATCH v3 0/3] drm/panel: Add panel driver for the Mantix MLAF057WE51-X DSI panel
The panel uses a Focaltech FT8006p, the touch part is handled by the already
existing edt-ft5x06. It can be found in e.g. the Librem 5.
Changes from v2:
- Due to review comments by Sam Ravnborg, thanks!
https://lore.kernel.org/lkml/20200815212727.ga1244...@ravnborg.org/
- Drop unused header
- Use newline before comment
- Add Reviewed/Acked-by by Sam Ravnborg, thanks!
https://lore.kernel.org/lkml/20200815212727.ga1244...@ravnborg.org/
https://lore.kernel.org/lkml/20200815212750.gb1244...@ravnborg.org/
https://lore.kernel.org/lkml/20200815212840.gc1244...@ravnborg.org/
Changes from v1:
- Due to review comments by Sam Ravnborg, thanks!
https://lore.kernel.org/dri-devel/20200815083917.ga993...@ravnborg.org/
- Don't preserve newlines with '|' in description
- Use reset-gpios and backlight from panel-common.yaml
- Reindent example
https://lore.kernel.org/dri-devel/20200815093226.gb993...@ravnborg.org/
- Drop unused includes
- Use dev_* instead of DRM_* for printing
- Turn off regulators in reverse order from enable
- Silence errors in mantix_{shutdown,remove}
- Drop duplicate mipi_dsi_dcs_enter_sleep_mode()
https://lore.kernel.org/dri-devel/20200815100230.ga1002...@ravnborg.org/
- Use dev_err_probe()
- Add delays when turning off panel as suggested by the data sheet
This series is against next-20200814.
Guido Günther (3):
dt-bindings: vendor-prefixes: Add mantix vendor prefix
dt-bindings: Add Mantix MLAF057WE51-X panel bindings
drm/panel: Add panel driver for the Mantix MLAF057WE51-X DSI panel
.../display/panel/mantix,mlaf057we51-x.yaml | 70
.../devicetree/bindings/vendor-prefixes.yaml | 2 +
MAINTAINERS | 7 +
drivers/gpu/drm/panel/Kconfig | 11 +
drivers/gpu/drm/panel/Makefile| 1 +
.../gpu/drm/panel/panel-mantix-mlaf057we51.c | 328 ++
6 files changed, 419 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml
create mode 100644 drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/3] drm/panel: Add panel driver for the Mantix MLAF057WE51-X DSI panel
Hi Sam, thanks for having a look! On Sat, Aug 15, 2020 at 11:27:27PM +0200, Sam Ravnborg wrote: > Hi Guido. > > On Sat, Aug 15, 2020 at 11:16:22PM +0200, Guido Günther wrote: > > The panel uses a Focaltech FT8006p, the touch part is handled by the > > already existing edt-ft5x06. > > > > Signed-off-by: Guido Günther > > Two small nits - otherwise looks good. > Reviewed-by: Sam Ravnborg > > I can fix while applying or you can send a new revision, > but I cannot apply until drm-misc-next have seen a backmerge > due to dev_err_probe() usage. I'll send out a v3 with this fixed. > Did you have commit rights yet? > If yes, then please apply yourself. No commit rights here. So it would be great if you could apply the patches. Should I look for commit rights? I assume that means following https://drm.pages.freedesktop.org/maintainer-tools/commit-access.html#drm-misc Cheers, -- Guido > > Sam > > > --- > > MAINTAINERS | 7 + > > drivers/gpu/drm/panel/Kconfig | 11 + > > drivers/gpu/drm/panel/Makefile| 1 + > > .../gpu/drm/panel/panel-mantix-mlaf057we51.c | 328 ++ > > 4 files changed, 347 insertions(+) > > create mode 100644 drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index 83ba7b62651f7..7dfe4cc3d4ec8 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -5474,6 +5474,13 @@ S: Maintained > > F: drivers/gpu/drm/panel/panel-lvds.c > > F: Documentation/devicetree/bindings/display/panel/lvds.yaml > > > > +DRM DRIVER FOR MANTIX MLAF057WE51 PANELS > > +M: Guido Günther > > +R: Purism Kernel Team > > +S: Maintained > > +F: > > Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml > > +F: drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c > > + > > DRM DRIVER FOR MATROX G200/G400 GRAPHICS CARDS > > S: Orphan / Obsolete > > F: drivers/gpu/drm/mga/ > > diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig > > index de2f2a452be55..8d97d07c58713 100644 > > --- a/drivers/gpu/drm/panel/Kconfig > > +++ b/drivers/gpu/drm/panel/Kconfig > > @@ -217,6 +217,17 @@ config DRM_PANEL_NOVATEK_NT39016 > > Say Y here if you want to enable support for the panels built > > around the Novatek NT39016 display controller. > > > > +config DRM_PANEL_MANTIX_MLAF057WE51 > > + tristate "Mantix MLAF057WE51-X MIPI-DSI LCD 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 Mantix > > + MLAF057WE51-X MIPI DSI panel as e.g. used in the Librem 5. It > > + has a resolution of 720x1440 pixels, a built in backlight and touch > > + controller. > > + > > config DRM_PANEL_OLIMEX_LCD_OLINUXINO > > tristate "Olimex LCD-OLinuXino panel" > > depends on OF > > diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile > > index e45ceac6286fd..15a4e77529514 100644 > > --- a/drivers/gpu/drm/panel/Makefile > > +++ b/drivers/gpu/drm/panel/Makefile > > @@ -20,6 +20,7 @@ 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_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 > > obj-$(CONFIG_DRM_PANEL_ORISETECH_OTM8009A) += panel-orisetech-otm8009a.o > > obj-$(CONFIG_DRM_PANEL_OSD_OSD101T2587_53TS) += > > panel-osd-osd101t2587-53ts.o > > diff --git a/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c > > b/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c > > new file mode 100644 > > index 0..cd5424d5bdb63 > > --- /dev/null > > +++ b/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c > > @@ -0,0 +1,328 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > +/* > > + * Mantix MLAF057WE51 5.7" MIPI-DSI panel driver > > + * > > + * Copyright (C) Purism SPC 2020 > > + */ > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +#include > > + > > +#include > > +#include > > +#include > >
[PATCH 0/2] Modernize rocktech,jh057n00900 bindings a bit
This was prompted by Sam's review in https://lore.kernel.org/dri-devel/20200815210802.ga1242...@ravnborg.org/ and yamllint. I also added myself as maintainer, hope that's o.k. Guido Günther (2): dt-bindings: panel: rocktech,jh057n00900: Modernize dt-bindings: panel: rocktech,jh057n00900: Add myself as maintainer .../display/panel/rocktech,jh057n00900.yaml | 40 +-- 1 file changed, 19 insertions(+), 21 deletions(-) -- 2.26.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] dt-bindings: panel: rocktech, jh057n00900: Add myself as maintainer
I maintained the txt based bindings before yaml conversion and care about the driver. Signed-off-by: Guido Günther --- .../devicetree/bindings/display/panel/rocktech,jh057n00900.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml b/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml index c97e89707342e..09b5eb7542f8a 100644 --- a/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml +++ b/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml @@ -8,6 +8,7 @@ title: Rocktech JH057N00900 5.5" 720x1440 TFT LCD panel maintainers: - Ondrej Jirman + - Guido Gŭnther description: Rocktech JH057N00900 is a 720x1440 TFT LCD panel -- 2.26.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] dt-bindings: panel: rocktech,jh057n00900: Modernize
- Use common properties from panel-common.yaml
- Indent comment like content
- Don't preserve newlines in description
- Indent example by four spaces
Signed-off-by: Guido Günther
---
.../display/panel/rocktech,jh057n00900.yaml | 39 +--
1 file changed, 18 insertions(+), 21 deletions(-)
diff --git
a/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml
b/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml
index d5733ef309549..c97e89707342e 100644
--- a/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml
+++ b/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml
@@ -9,9 +9,9 @@ title: Rocktech JH057N00900 5.5" 720x1440 TFT LCD panel
maintainers:
- Ondrej Jirman
-description: |
- Rocktech JH057N00900 is a 720x1440 TFT LCD panel
- connected using a MIPI-DSI video interface.
+description:
+ Rocktech JH057N00900 is a 720x1440 TFT LCD panel
+ connected using a MIPI-DSI video interface.
allOf:
- $ref: panel-common.yaml#
@@ -19,9 +19,9 @@ allOf:
properties:
compatible:
enum:
-# Rocktech JH057N00900 5.5" 720x1440 TFT LCD panel
+ # Rocktech JH057N00900 5.5" 720x1440 TFT LCD panel
- rocktech,jh057n00900
-# Xingbangda XBD599 5.99" 720x1440 TFT LCD panel
+ # Xingbangda XBD599 5.99" 720x1440 TFT LCD panel
- xingbangda,xbd599
port: true
@@ -35,13 +35,9 @@ properties:
iovcc-supply:
description: I/O voltage supply
- reset-gpios:
-description: GPIO used for the reset pin
-maxItems: 1
+ reset-gpios: true
- backlight:
-description: Backlight used by the panel
-$ref: "/schemas/types.yaml#/definitions/phandle"
+ backlight: true
required:
- compatible
@@ -57,15 +53,16 @@ examples:
#include
dsi {
- #address-cells = <1>;
- #size-cells = <0>;
- panel@0 {
-compatible = "rocktech,jh057n00900";
-reg = <0>;
-vcc-supply = <_2v8_p>;
-iovcc-supply = <_1v8_p>;
-reset-gpios = < 13 GPIO_ACTIVE_LOW>;
-backlight = <>;
- };
+#address-cells = <1>;
+#size-cells = <0>;
+panel@0 {
+compatible = "rocktech,jh057n00900";
+reg = <0>;
+vcc-supply = <_2v8_p>;
+iovcc-supply = <_1v8_p>;
+reset-gpios = < 13 GPIO_ACTIVE_LOW>;
+backlight = <>;
+};
};
+
...
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm/panel: Add panel driver for the Mantix MLAF057WE51-X DSI panel
Hi Sam,
On Sat, Aug 15, 2020 at 11:32:26AM +0200, Sam Ravnborg wrote:
> Hi Guido.
>
> On Fri, Aug 14, 2020 at 03:36:23PM +0200, Guido Günther wrote:
> > The panel uses a Focaltech FT8006p, the touch part is handled by the
> > already existing edt-ft5x06.
> >
> > Signed-off-by: Guido Günther
>
> Looks good.
> A few notes in the following, nothing major.
Thanks. I've added your suggestions to v2.
-- Guido
>
> Sam
>
> > ---
> > MAINTAINERS | 7 +
> > drivers/gpu/drm/panel/Kconfig | 11 +
> > drivers/gpu/drm/panel/Makefile| 1 +
> > .../gpu/drm/panel/panel-mantix-mlaf057we51.c | 362 ++
> > 4 files changed, 381 insertions(+)
> > create mode 100644 drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 83ba7b62651f7..7dfe4cc3d4ec8 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -5474,6 +5474,13 @@ S: Maintained
> > F: drivers/gpu/drm/panel/panel-lvds.c
> > F: Documentation/devicetree/bindings/display/panel/lvds.yaml
> >
> > +DRM DRIVER FOR MANTIX MLAF057WE51 PANELS
> > +M: Guido Günther
> > +R: Purism Kernel Team
> > +S: Maintained
> > +F:
> > Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml
> > +F: drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
> > +
> > DRM DRIVER FOR MATROX G200/G400 GRAPHICS CARDS
> > S: Orphan / Obsolete
> > F: drivers/gpu/drm/mga/
> > diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> > index de2f2a452be55..8d97d07c58713 100644
> > --- a/drivers/gpu/drm/panel/Kconfig
> > +++ b/drivers/gpu/drm/panel/Kconfig
> > @@ -217,6 +217,17 @@ config DRM_PANEL_NOVATEK_NT39016
> > Say Y here if you want to enable support for the panels built
> > around the Novatek NT39016 display controller.
> >
> > +config DRM_PANEL_MANTIX_MLAF057WE51
> > + tristate "Mantix MLAF057WE51-X MIPI-DSI LCD 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 Mantix
> > + MLAF057WE51-X MIPI DSI panel as e.g. used in the Librem 5. It
> > + has a resolution of 720x1440 pixels, a built in backlight and touch
> > + controller.
> > +
> > config DRM_PANEL_OLIMEX_LCD_OLINUXINO
> > tristate "Olimex LCD-OLinuXino panel"
> > depends on OF
> > diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> > index e45ceac6286fd..15a4e77529514 100644
> > --- a/drivers/gpu/drm/panel/Makefile
> > +++ b/drivers/gpu/drm/panel/Makefile
> > @@ -20,6 +20,7 @@ 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_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
> > obj-$(CONFIG_DRM_PANEL_ORISETECH_OTM8009A) += panel-orisetech-otm8009a.o
> > obj-$(CONFIG_DRM_PANEL_OSD_OSD101T2587_53TS) +=
> > panel-osd-osd101t2587-53ts.o
> > diff --git a/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
> > b/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
> > new file mode 100644
> > index 0..6c07bcdb75937
> > --- /dev/null
> > +++ b/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
> > @@ -0,0 +1,362 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Mantix MLAF057WE51 5.7" MIPI-DSI panel driver
> > + *
> > + * Copyright (C) Purism SPC 2020
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> Include not needed.
>
> > +#include
> > +#include
> > +
> > +#include
> I do not think this include is needed
>
> > +#include
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#define DRV_NAME "panel-mantix-mlaf057we51"
> > +
> > +/* Manufacturer specific Commands send via DSI */
> > +#define MANTIX_CMD_OTP_STOP_RELOAD_MIPI 0x41
> > +#define MANTIX_CMD_INT_CANCEL 0x4C
> > +
> > +struct mantix {
> > + struct device *dev;
> > + struct drm_panel panel;
> > + st
Re: [PATCH 3/8] dt-bindings: display: mxsfb: Add a bus-width endpoint property
Hi Laurent, On Thu, Aug 13, 2020 at 04:29:05AM +0300, Laurent Pinchart wrote: > When the PCB routes the display data signals in an unconventional way, > the output bus width may differ from the bus width of the connected > panel or encoder. For instance, when a 18-bit RGB panel has its R[5:0], > G[5:0] and B[5:0] signals connected to LCD_DATA[7:2], LCD_DATA[15:10] > and LCD_DATA[23:18], the output bus width is 24 instead of 18 when the > signals are routed to LCD_DATA[5:0], LCD_DATA[11:6] and LCD_DATA[17:12]. > > Add a bus-width property to describe this data routing. > > Signed-off-by: Laurent Pinchart > --- > Documentation/devicetree/bindings/display/mxsfb.yaml | 12 > 1 file changed, 12 insertions(+) > > diff --git a/Documentation/devicetree/bindings/display/mxsfb.yaml > b/Documentation/devicetree/bindings/display/mxsfb.yaml > index ec6533b1d4a3..d15bb8edc29f 100644 > --- a/Documentation/devicetree/bindings/display/mxsfb.yaml > +++ b/Documentation/devicetree/bindings/display/mxsfb.yaml > @@ -58,6 +58,18 @@ properties: > type: object > > properties: > + data-shift: Shouldn't that be bus-width ? -- Guido > +enum: [16, 18, 24] > +description: | > + The output bus width. This value overrides the configuration > + derived from the connected device (encoder or panel). It should > + only be specified when PCB routing of the data signals require > a > + different bus width on the LCDIF and the connected device. For > + instance, when a 18-bit RGB panel has its R[5:0], G[5:0] and > + B[5:0] signals connected to LCD_DATA[7:2], LCD_DATA[15:10] and > + LCD_DATA[23:18] instead of LCD_DATA[5:0], LCD_DATA[11:6] and > + LCD_DATA[17:12], bus-width should be set to 24. > + >remote-endpoint: > $ref: /schemas/types.yaml#/definitions/phandle > > -- > Regards, > > Laurent Pinchart > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 0/5] drm/panel: Use dev_ based logging
Hi, On Sat, Aug 15, 2020 at 02:54:01PM +0200, Sam Ravnborg wrote: > The drm/panel drivers uses a mixture of DRM_ and dev_ based logging. > With this patchset all panel drivers are migrated to use dev_ based > logging as the DRM_ based logging did not add any extra info. > > Drop the now unused include of drm_print.h. > > With this change new panel drivers will be requires to change to dev_ > based logging - so some of the in-flight panel drivers will need trivial > updates before they are accepted. > > Patch divided in smaller bites to ease review. There is no dependencies > between the patches. > > Copied a few people that may have input to the move away from DRM_ based > logging (Daniel (presumeably on vacation), Jani). Looks good to me and after applying to next-20200824 i couldn't spot any DRM_ style logging leftovers: Reviewed-by: Guido Günther Cheers, -- Guido > > Sam > > Sam Ravnborg (5): > drm/panel: samsung: Use dev_ based logging > drm/panel: leadtek: Use dev_ based logging > drm/panel: raydium: Use dev_ based logging > drm/panel: sitronix: Use dev_ based logging > drm/panel: Use dev_ based logging > > drivers/gpu/drm/panel/panel-boe-himax8279d.c | 44 > drivers/gpu/drm/panel/panel-elida-kd35t133.c | 51 +- > drivers/gpu/drm/panel/panel-feixin-k101-im2ba02.c | 19 +++-- > .../gpu/drm/panel/panel-feiyang-fy07024di26a30d.c | 21 +++--- > drivers/gpu/drm/panel/panel-ilitek-ili9322.c | 3 +- > drivers/gpu/drm/panel/panel-innolux-p079zca.c | 31 +++-- > drivers/gpu/drm/panel/panel-kingdisplay-kd097d04.c | 33 - > drivers/gpu/drm/panel/panel-leadtek-ltk050h3146w.c | 58 ++-- > drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c | 49 + > drivers/gpu/drm/panel/panel-novatek-nt35510.c | 40 --- > drivers/gpu/drm/panel/panel-orisetech-otm8009a.c | 13 ++-- > drivers/gpu/drm/panel/panel-raydium-rm67191.c | 33 - > drivers/gpu/drm/panel/panel-raydium-rm68200.c | 18 +++-- > drivers/gpu/drm/panel/panel-ronbo-rb070d30.c | 16 ++--- > drivers/gpu/drm/panel/panel-samsung-ld9040.c | 3 +- > drivers/gpu/drm/panel/panel-samsung-s6d16d0.c | 23 +++--- > drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c | 3 +- > drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c | 3 +- > drivers/gpu/drm/panel/panel-samsung-s6e63m0.c | 22 +++--- > drivers/gpu/drm/panel/panel-samsung-s6e8aa0.c | 3 +- > drivers/gpu/drm/panel/panel-sitronix-st7701.c | 10 ++- > drivers/gpu/drm/panel/panel-sitronix-st7703.c | 61 ++-- > drivers/gpu/drm/panel/panel-sony-acx424akp.c | 81 > -- > drivers/gpu/drm/panel/panel-tpo-tpg110.c | 38 +- > drivers/gpu/drm/panel/panel-truly-nt35597.c| 63 ++--- > drivers/gpu/drm/panel/panel-visionox-rm69299.c | 41 --- > drivers/gpu/drm/panel/panel-xinpeng-xpp055c272.c | 51 +- > 27 files changed, 308 insertions(+), 523 deletions(-) > > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/3] dt-bindings: Add Mantix MLAF057WE51-X panel bindings
The panel uses a Focaltech FT8006p, the touch part is handled by the
already existing edt-ft5x06.
Signed-off-by: Guido Günther
---
.../display/panel/mantix,mlaf057we51-x.yaml | 70 +++
1 file changed, 70 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml
b/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml
new file mode 100644
index 0..937323cc9aaac
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml
@@ -0,0 +1,70 @@
+# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/mantix,mlaf057we51-x.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mantix MLAF057WE51-X 5.7" 720x1440 TFT LCD panel
+
+maintainers:
+ - Guido Günther
+
+description:
+ Mantix MLAF057WE51 X is a 720x1440 TFT LCD panel connected using
+ a MIPI-DSI video interface.
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+enum:
+ - mantix,mlaf057we51-x
+
+ port: true
+ reg:
+maxItems: 1
+description: DSI virtual channel
+
+ avdd-supply:
+description: Positive analog power supply
+
+ avee-supply:
+description: Negative analog power supply
+
+ vddi-supply:
+description: 1.8V I/O voltage supply
+
+ reset-gpios: true
+
+ backlight: true
+
+required:
+ - compatible
+ - reg
+ - avdd-supply
+ - avee-supply
+ - vddi-supply
+ - reset-gpios
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+
+dsi {
+#address-cells = <1>;
+#size-cells = <0>;
+panel@0 {
+compatible = "mantix,mlaf057we51-x";
+reg = <0>;
+avdd-supply = <_avdd>;
+avee-supply = <_avee>;
+vddi-supply = <_1v8_p>;
+reset-gpios = < 29 GPIO_ACTIVE_LOW>;
+backlight = <>;
+};
+};
+
+...
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/3] dt-bindings: vendor-prefixes: Add mantix vendor prefix
Add prefix for Mantix Display Technology Co.,Ltd. Signed-off-by: Guido Günther --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 2baee2c817c1a..59d4c8b068c4d 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -611,6 +611,8 @@ patternProperties: description: Linux Automation GmbH "^macnica,.*": description: Macnica Americas + "^mantix,.*": +description: Mantix Display Technology Co.,Ltd. "^mapleboard,.*": description: Mapleboard.org "^marvell,.*": -- 2.26.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/3] drm/panel: Add panel driver for the Mantix MLAF057WE51-X DSI panel
The panel uses a Focaltech FT8006p, the touch part is handled by the already
existing edt-ft5x06. It can be found in e.g. the Librem 5.
Changes from v1:
- Due to review comments by Sam Ravnborg, thanks!
https://lore.kernel.org/dri-devel/20200815083917.ga993...@ravnborg.org/
- Don't preserve newlines with '|' in description
- Use reset-gpios and backlight from panel-common.yaml
- Reindent example
https://lore.kernel.org/dri-devel/20200815093226.gb993...@ravnborg.org/
- Drop unused includes
- Use dev_* instead of DRM_* for printing
- Turn off regulators in reverse order from enable
- Silence errors in mantix_{shutdown,remove}
- Drop duplicate mipi_dsi_dcs_enter_sleep_mode()
https://lore.kernel.org/dri-devel/20200815100230.ga1002...@ravnborg.org/
- Use dev_err_probe()
- Add delays when turning off panel as suggested by the data sheet
This series is against next-20200814.
Guido Günther (3):
dt-bindings: vendor-prefixes: Add mantix vendor prefix
dt-bindings: Add Mantix MLAF057WE51-X panel bindings
drm/panel: Add panel driver for the Mantix MLAF057WE51-X DSI panel
.../display/panel/mantix,mlaf057we51-x.yaml | 70
.../devicetree/bindings/vendor-prefixes.yaml | 2 +
MAINTAINERS | 7 +
drivers/gpu/drm/panel/Kconfig | 11 +
drivers/gpu/drm/panel/Makefile| 1 +
.../gpu/drm/panel/panel-mantix-mlaf057we51.c | 328 ++
6 files changed, 419 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml
create mode 100644 drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/3] drm/panel: Add panel driver for the Mantix MLAF057WE51-X DSI panel
The panel uses a Focaltech FT8006p, the touch part is handled by the
already existing edt-ft5x06.
Signed-off-by: Guido Günther
---
MAINTAINERS | 7 +
drivers/gpu/drm/panel/Kconfig | 11 +
drivers/gpu/drm/panel/Makefile| 1 +
.../gpu/drm/panel/panel-mantix-mlaf057we51.c | 328 ++
4 files changed, 347 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 83ba7b62651f7..7dfe4cc3d4ec8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5474,6 +5474,13 @@ S: Maintained
F: drivers/gpu/drm/panel/panel-lvds.c
F: Documentation/devicetree/bindings/display/panel/lvds.yaml
+DRM DRIVER FOR MANTIX MLAF057WE51 PANELS
+M: Guido Günther
+R: Purism Kernel Team
+S: Maintained
+F:
Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml
+F: drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
+
DRM DRIVER FOR MATROX G200/G400 GRAPHICS CARDS
S: Orphan / Obsolete
F: drivers/gpu/drm/mga/
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index de2f2a452be55..8d97d07c58713 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -217,6 +217,17 @@ config DRM_PANEL_NOVATEK_NT39016
Say Y here if you want to enable support for the panels built
around the Novatek NT39016 display controller.
+config DRM_PANEL_MANTIX_MLAF057WE51
+ tristate "Mantix MLAF057WE51-X MIPI-DSI LCD 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 Mantix
+ MLAF057WE51-X MIPI DSI panel as e.g. used in the Librem 5. It
+ has a resolution of 720x1440 pixels, a built in backlight and touch
+ controller.
+
config DRM_PANEL_OLIMEX_LCD_OLINUXINO
tristate "Olimex LCD-OLinuXino panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index e45ceac6286fd..15a4e77529514 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -20,6 +20,7 @@ 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_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
obj-$(CONFIG_DRM_PANEL_ORISETECH_OTM8009A) += panel-orisetech-otm8009a.o
obj-$(CONFIG_DRM_PANEL_OSD_OSD101T2587_53TS) += panel-osd-osd101t2587-53ts.o
diff --git a/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
b/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
new file mode 100644
index 0..cd5424d5bdb63
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
@@ -0,0 +1,328 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Mantix MLAF057WE51 5.7" MIPI-DSI panel driver
+ *
+ * Copyright (C) Purism SPC 2020
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include
+#include
+#include
+#include
+
+#define DRV_NAME "panel-mantix-mlaf057we51"
+
+/* Manufacturer specific Commands send via DSI */
+#define MANTIX_CMD_OTP_STOP_RELOAD_MIPI 0x41
+#define MANTIX_CMD_INT_CANCEL 0x4C
+
+struct mantix {
+ struct device *dev;
+ struct drm_panel panel;
+ struct gpio_desc *reset_gpio;
+
+ struct regulator *avdd;
+ struct regulator *avee;
+ struct regulator *vddi;
+};
+
+static inline struct mantix *panel_to_mantix(struct drm_panel *panel)
+{
+ return container_of(panel, struct mantix, panel);
+}
+
+#define dsi_generic_write_seq(dsi, seq...) do {
\
+ static const u8 d[] = { seq }; \
+ int ret;\
+ ret = mipi_dsi_generic_write(dsi, d, ARRAY_SIZE(d));\
+ if (ret < 0)\
+ return ret; \
+ } while (0)
+
+static int mantix_init_sequence(struct mantix *ctx)
+{
+ struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
+ struct device *dev = ctx->dev;
+
+ /*
+* Init sequence was supplied by the panel vendor.
+*/
+ dsi_generic_write_seq(dsi, MANTIX_CMD_OTP_STOP_RELOAD_MIPI, 0x5A);
+
+ dsi_generic_write_seq(dsi, MANTIX_CMD_INT_CANCEL, 0x03);
+ dsi_generic_write_seq(dsi, MANTIX_CMD_OTP_STOP_RELOAD_MIPI, 0x5A, 0x03);
+ dsi_generic_write_seq(dsi, 0x80, 0xA9, 0x00);
+
+ dsi_generic_write_seq(dsi, MANTIX_CMD_OTP_STOP_RELOAD_MIPI, 0x5A, 0x09);
+ dsi_g
Re: [PATCH 2/3] dt-bindings: Add Mantix MLAF057WE51-X panel bindings
Hi Sam,
On Sat, Aug 15, 2020 at 10:39:17AM +0200, Sam Ravnborg wrote:
> Hi Guido.
>
> On Fri, Aug 14, 2020 at 03:36:22PM +0200, Guido Günther wrote:
> > The panel uses a Focaltech FT8006p, the touch part is handled by the
> > already existing edt-ft5x06.
> >
> > Signed-off-by: Guido Günther
>
> A few trivialities.
Thanks for having a look. One remark inline:
>
> > ---
> > .../display/panel/mantix,mlaf057we51-x.yaml | 73 +++
> > 1 file changed, 73 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml
> > b/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml
> > new file mode 100644
> > index 0..349f3380ac940
> > --- /dev/null
> > +++
> > b/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml
> > @@ -0,0 +1,73 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/display/panel/mantix,mlaf057we51-x.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Mantix MLAF057WE51-X 5.7" 720x1440 TFT LCD panel
> > +
> > +maintainers:
> > + - Guido Günther
> > +
> > +description: |
> > + Mantix MLAF057WE51 X is a 720x1440 TFT LCD panel
> > + connected using a MIPI-DSI video interface.
> Indent text with two spaces only.
> And I have learned that '|' is only needed to preserve formatting - so
> it can be dropped.
>
> > +
> > +allOf:
> > + - $ref: panel-common.yaml#
> > +
> > +properties:
> > + compatible:
> > +enum:
> > + - mantix,mlaf057we51-x
> This is a list - so needs an extra 2 spaces indent.
> See
> https://lore.kernel.org/linux-devicetree/f1963eb9-283f-e903-2a3a-4f324d71d...@lucaceresoli.net/T/#m65900317fb948f6c40e8fb521f2201fba3c301a7
> for examples where Rob fixes this.
Doesn't this only apply if the 'outer element' is a list too so e.g.:
- enum
- foo
trips up yamllint but
enum
- foo
doesn't. Since yamllint was happy i kept it as is (looking at your
reference suggests that too).
All the rest made sense and i fixed that for the upcoming v2.
Thanks for having a look!
-- Guido
>
> > +
> > + port: true
> > + reg:
> > +maxItems: 1
> > +description: DSI virtual channel
> > +
> > + avdd-supply:
> > +description: Positive analog power supply
> > +
> > + avee-supply:
> > +description: Negative analog power supply
> > +
> > + vddi-supply:
> > +description: 1.8V I/O voltage supply
> > +
> > + reset-gpios:
> > +description: GPIO used for the reset pin
> > +maxItems: 1
> Use reset-gpios: true as we already have it in panel-common.yaml
>
> > +
> > + backlight:
> > +description: Backlight used by the panel
> > +$ref: "/schemas/types.yaml#/definitions/phandle"
> Use backlight from panel-common.yaml.
>
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - avdd-supply
> > + - avee-supply
> > + - vddi-supply
> > + - reset-gpios
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > +#include
> > +
> > +dsi {
> My personal preference is indent with 4 spaces in examples but there are
> no rules so feel free to ignore.
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + panel@0 {
> > +compatible = "mantix,mlaf057we51-x";
> > +reg = <0>;
> > +avdd-supply = <_avdd>;
> > +avee-supply = <_avee>;
> > +vddi-supply = <_1v8_p>;
> > +reset-gpios = < 29 GPIO_ACTIVE_LOW>;
> > +backlight = <>;
> > + };
> > +};
> I think we need an ampty line here.
> > +...
> > --
> > 2.26.2
> >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm/panel: Add panel driver for the Mantix MLAF057WE51-X DSI panel
Hi,
On Sat, Aug 15, 2020 at 12:46:51PM +0200, Sam Ravnborg wrote:
> On Sat, Aug 15, 2020 at 12:40:22PM +0200, Guido Günther wrote:
> > Hi Sam,
> > On Sat, Aug 15, 2020 at 12:02:30PM +0200, Sam Ravnborg wrote:
> > > Hi Guido.
> > >
> > > > +static int mantix_probe(struct mipi_dsi_device *dsi)
> > > > +{
> > > > + struct device *dev = >dev;
> > > > + struct mantix *ctx;
> > > > + int ret;
> > > > +
> > > > + ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
> > > > + if (!ctx)
> > > > + return -ENOMEM;
> > > > +
> > > > + ctx->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
> > > > + if (IS_ERR(ctx->reset_gpio)) {
> > > > + DRM_DEV_ERROR(dev, "cannot get reset gpio\n");
> > > > + return PTR_ERR(ctx->reset_gpio);
> > > > + }
> > > > +
> > > > + mipi_dsi_set_drvdata(dsi, ctx);
> > > > + ctx->dev = dev;
> > > > +
> > > > + dsi->lanes = 4;
> > > > + dsi->format = MIPI_DSI_FMT_RGB888;
> > > > + dsi->mode_flags = MIPI_DSI_MODE_VIDEO |
> > > > + MIPI_DSI_MODE_VIDEO_BURST |
> > > > MIPI_DSI_MODE_VIDEO_SYNC_PULSE;
> > > > +
> > > > + ctx->avdd = devm_regulator_get(dev, "avdd");
> > > > + if (IS_ERR(ctx->avdd)) {
> > > > + ret = PTR_ERR(ctx->avdd);
> > > > + if (ret != -EPROBE_DEFER)
> > > > + DRM_DEV_ERROR(dev,
> > > > + "Failed to request avdd
> > > > regulator: %d\n",
> > > > + ret);
> > > > + return ret;
> > > > + }
> > >
> > > Consider to use the recently added dev_err_probe() here and below.
> > > Note: Not part of drm-misc-next yet - but hopefully after -rc1
> > > when a backmerge is done.
> >
> > In fact I did decided against it since i was told that missing dev_* and
> > DRM_* logging shouldn't be done. So is that o.k. nowadays?
> s/missing/mixing/
>
> I often request that logging is consistent - so I recognize the
> argument.
>
> For panel/* I have not made up my mind what I think is the best
> approach. The DRM_DEV_* and DRM_* logging do not add much value.
> So I have been tempted several times to convert all logging in
> panel/ to dev_* and pr_* (when no struct device * is available).
> That would also avoid that we mix up logging.
>
> We have drm_* logging - but they require a valid drm_device * which we
> do not have in the the panel drivers. So they are ruled out here.
>
> Do you have any opinions/comments on this?
I think for panel drivers DRM_* does not give any bonus so moving to
{dev,pr}_* sounds good. I just wonder if other drm parts don't need
`dev_drm_err_probe()` (or similar) anyway. But then maybe dyn_debug
is enough nowadays to not need DRM_DEV_DEBUG_* either?
Cheers,
-- Guido
>
> Sam
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm/panel: Add panel driver for the Mantix MLAF057WE51-X DSI panel
Hi Sam,
On Sat, Aug 15, 2020 at 12:02:30PM +0200, Sam Ravnborg wrote:
> Hi Guido.
>
> > +static int mantix_probe(struct mipi_dsi_device *dsi)
> > +{
> > + struct device *dev = >dev;
> > + struct mantix *ctx;
> > + int ret;
> > +
> > + ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
> > + if (!ctx)
> > + return -ENOMEM;
> > +
> > + ctx->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
> > + if (IS_ERR(ctx->reset_gpio)) {
> > + DRM_DEV_ERROR(dev, "cannot get reset gpio\n");
> > + return PTR_ERR(ctx->reset_gpio);
> > + }
> > +
> > + mipi_dsi_set_drvdata(dsi, ctx);
> > + ctx->dev = dev;
> > +
> > + dsi->lanes = 4;
> > + dsi->format = MIPI_DSI_FMT_RGB888;
> > + dsi->mode_flags = MIPI_DSI_MODE_VIDEO |
> > + MIPI_DSI_MODE_VIDEO_BURST | MIPI_DSI_MODE_VIDEO_SYNC_PULSE;
> > +
> > + ctx->avdd = devm_regulator_get(dev, "avdd");
> > + if (IS_ERR(ctx->avdd)) {
> > + ret = PTR_ERR(ctx->avdd);
> > + if (ret != -EPROBE_DEFER)
> > + DRM_DEV_ERROR(dev,
> > + "Failed to request avdd regulator: %d\n",
> > + ret);
> > + return ret;
> > + }
>
> Consider to use the recently added dev_err_probe() here and below.
> Note: Not part of drm-misc-next yet - but hopefully after -rc1
> when a backmerge is done.
In fact I did decided against it since i was told that missing dev_* and
DRM_* logging shouldn't be done. So is that o.k. nowadays?
Cheers,
-- Guido
>
> Sam
>
> > + ctx->avee = devm_regulator_get(dev, "avee");
> > + if (IS_ERR(ctx->avee)) {
> > + ret = PTR_ERR(ctx->avee);
> > + if (ret != -EPROBE_DEFER)
> > + DRM_DEV_ERROR(dev,
> > + "Failed to request avee regulator: %d\n",
> > + ret);
> > + return ret;
> > + }
> > + ctx->vddi = devm_regulator_get(dev, "vddi");
> > + if (IS_ERR(ctx->vddi)) {
> > + ret = PTR_ERR(ctx->vddi);
> > + if (ret != -EPROBE_DEFER)
> > + DRM_DEV_ERROR(dev,
> > + "Failed to request vddi regulator: %d\n",
> > + ret);
> > + return ret;
> > + }
> > +
> > + drm_panel_init(>panel, dev, _drm_funcs,
> > + DRM_MODE_CONNECTOR_DSI);
> > +
> > + ret = drm_panel_of_backlight(>panel);
> > + if (ret)
> > + return ret;
> > + drm_panel_add(>panel);
> > +
> > + ret = mipi_dsi_attach(dsi);
> > + if (ret < 0) {
> > + DRM_DEV_ERROR(dev,
> > + "mipi_dsi_attach failed (%d). Is host ready?\n",
> > + ret);
> > + drm_panel_remove(>panel);
> > + return ret;
> > + }
> > +
> > + DRM_DEV_INFO(dev, "%ux%u@%u %ubpp dsi %udl - ready\n",
> > +default_mode.hdisplay, default_mode.vdisplay,
> > +drm_mode_vrefresh(_mode),
> > +mipi_dsi_pixel_format_to_bpp(dsi->format), dsi->lanes);
> > +
> > + return 0;
> > +}
> > +
> > +static void mantix_shutdown(struct mipi_dsi_device *dsi)
> > +{
> > + struct mantix *ctx = mipi_dsi_get_drvdata(dsi);
> > + int ret;
> > +
> > + ret = drm_panel_unprepare(>panel);
> > + if (ret < 0)
> > + DRM_DEV_ERROR(>dev, "Failed to unprepare panel: %d\n",
> > + ret);
> > +
> > + ret = drm_panel_disable(>panel);
> > + if (ret < 0)
> > + DRM_DEV_ERROR(>dev, "Failed to disable panel: %d\n",
> > + ret);
> > +}
> > +
> > +static int mantix_remove(struct mipi_dsi_device *dsi)
> > +{
> > + struct mantix *ctx = mipi_dsi_get_drvdata(dsi);
> > + int ret;
> > +
> > + mantix_shutdown(dsi);
> > +
> > + ret = mipi_dsi_detach(dsi);
> > + if (ret < 0)
> > + DRM_DEV_ERROR(>dev, "Failed to detach from DSI host: %d\n",
> > + ret);
> > +
> > + drm_panel_remove(>panel);
> > +
> &g
[PATCH 0/3] drm/panel: Add panel driver for the Mantix MLAF057WE51-X DSI panel
The panel uses a Focaltech FT8006p, the touch part is handled by the already existing edt-ft5x06. It can be found in e.g. the Librem 5. This series is against next-20200814. Guido Günther (3): dt-bindings: vendor-prefixes: Add mantix vendor prefix dt-bindings: Add Mantix MLAF057WE51-X panel bindings drm/panel: Add panel driver for the Mantix MLAF057WE51-X DSI panel .../display/panel/mantix,mlaf057we51-x.yaml | 73 .../devicetree/bindings/vendor-prefixes.yaml | 2 + MAINTAINERS | 7 + drivers/gpu/drm/panel/Kconfig | 11 + drivers/gpu/drm/panel/Makefile| 1 + .../gpu/drm/panel/panel-mantix-mlaf057we51.c | 362 ++ 6 files changed, 456 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml create mode 100644 drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c -- 2.26.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm/panel: Add panel driver for the Mantix MLAF057WE51-X DSI panel
The panel uses a Focaltech FT8006p, the touch part is handled by the
already existing edt-ft5x06.
Signed-off-by: Guido Günther
---
MAINTAINERS | 7 +
drivers/gpu/drm/panel/Kconfig | 11 +
drivers/gpu/drm/panel/Makefile| 1 +
.../gpu/drm/panel/panel-mantix-mlaf057we51.c | 362 ++
4 files changed, 381 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 83ba7b62651f7..7dfe4cc3d4ec8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5474,6 +5474,13 @@ S: Maintained
F: drivers/gpu/drm/panel/panel-lvds.c
F: Documentation/devicetree/bindings/display/panel/lvds.yaml
+DRM DRIVER FOR MANTIX MLAF057WE51 PANELS
+M: Guido Günther
+R: Purism Kernel Team
+S: Maintained
+F:
Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml
+F: drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
+
DRM DRIVER FOR MATROX G200/G400 GRAPHICS CARDS
S: Orphan / Obsolete
F: drivers/gpu/drm/mga/
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index de2f2a452be55..8d97d07c58713 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -217,6 +217,17 @@ config DRM_PANEL_NOVATEK_NT39016
Say Y here if you want to enable support for the panels built
around the Novatek NT39016 display controller.
+config DRM_PANEL_MANTIX_MLAF057WE51
+ tristate "Mantix MLAF057WE51-X MIPI-DSI LCD 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 Mantix
+ MLAF057WE51-X MIPI DSI panel as e.g. used in the Librem 5. It
+ has a resolution of 720x1440 pixels, a built in backlight and touch
+ controller.
+
config DRM_PANEL_OLIMEX_LCD_OLINUXINO
tristate "Olimex LCD-OLinuXino panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index e45ceac6286fd..15a4e77529514 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -20,6 +20,7 @@ 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_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
obj-$(CONFIG_DRM_PANEL_ORISETECH_OTM8009A) += panel-orisetech-otm8009a.o
obj-$(CONFIG_DRM_PANEL_OSD_OSD101T2587_53TS) += panel-osd-osd101t2587-53ts.o
diff --git a/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
b/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
new file mode 100644
index 0..6c07bcdb75937
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
@@ -0,0 +1,362 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Mantix MLAF057WE51 5.7" MIPI-DSI panel driver
+ *
+ * Copyright (C) Purism SPC 2020
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#define DRV_NAME "panel-mantix-mlaf057we51"
+
+/* Manufacturer specific Commands send via DSI */
+#define MANTIX_CMD_OTP_STOP_RELOAD_MIPI 0x41
+#define MANTIX_CMD_INT_CANCEL 0x4C
+
+struct mantix {
+ struct device *dev;
+ struct drm_panel panel;
+ struct gpio_desc *reset_gpio;
+
+ struct regulator *avdd;
+ struct regulator *avee;
+ struct regulator *vddi;
+};
+
+static inline struct mantix *panel_to_mantix(struct drm_panel *panel)
+{
+ return container_of(panel, struct mantix, panel);
+}
+
+#define dsi_generic_write_seq(dsi, seq...) do {
\
+ static const u8 d[] = { seq }; \
+ int ret;\
+ ret = mipi_dsi_generic_write(dsi, d, ARRAY_SIZE(d));\
+ if (ret < 0)\
+ return ret; \
+ } while (0)
+
+static int mantix_init_sequence(struct mantix *ctx)
+{
+ struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
+ struct device *dev = ctx->dev;
+
+ /*
+* Init sequence was supplied by the panel vendor.
+*/
+ dsi_generic_write_seq(dsi, MANTIX_CMD_OTP_STOP_RELOAD_MIPI, 0x5A);
+
+ dsi_generic_write_seq(dsi, MANTIX_CMD_INT_CANCEL, 0x03);
+ dsi_generic_write_seq(dsi, MANTIX_CMD_OTP_STOP_RELOAD_MIPI, 0x5A, 0x03);
+ dsi_generic_write_seq(dsi, 0x80, 0xA9, 0x00);
+
+ dsi_generic_write_seq(dsi, MANTIX_CMD_OTP_STOP_RELOAD_MIPI, 0x
[PATCH 1/3] dt-bindings: vendor-prefixes: Add mantix vendor prefix
Add prefix for Mantix Display Technology Co.,Ltd. Signed-off-by: Guido Günther --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 2baee2c817c1a..59d4c8b068c4d 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -611,6 +611,8 @@ patternProperties: description: Linux Automation GmbH "^macnica,.*": description: Macnica Americas + "^mantix,.*": +description: Mantix Display Technology Co.,Ltd. "^mapleboard,.*": description: Mapleboard.org "^marvell,.*": -- 2.26.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] dt-bindings: Add Mantix MLAF057WE51-X panel bindings
The panel uses a Focaltech FT8006p, the touch part is handled by the
already existing edt-ft5x06.
Signed-off-by: Guido Günther
---
.../display/panel/mantix,mlaf057we51-x.yaml | 73 +++
1 file changed, 73 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml
b/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml
new file mode 100644
index 0..349f3380ac940
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml
@@ -0,0 +1,73 @@
+# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/mantix,mlaf057we51-x.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mantix MLAF057WE51-X 5.7" 720x1440 TFT LCD panel
+
+maintainers:
+ - Guido Günther
+
+description: |
+ Mantix MLAF057WE51 X is a 720x1440 TFT LCD panel
+ connected using a MIPI-DSI video interface.
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+enum:
+ - mantix,mlaf057we51-x
+
+ port: true
+ reg:
+maxItems: 1
+description: DSI virtual channel
+
+ avdd-supply:
+description: Positive analog power supply
+
+ avee-supply:
+description: Negative analog power supply
+
+ vddi-supply:
+description: 1.8V I/O voltage supply
+
+ reset-gpios:
+description: GPIO used for the reset pin
+maxItems: 1
+
+ backlight:
+description: Backlight used by the panel
+$ref: "/schemas/types.yaml#/definitions/phandle"
+
+required:
+ - compatible
+ - reg
+ - avdd-supply
+ - avee-supply
+ - vddi-supply
+ - reset-gpios
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+
+dsi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ panel@0 {
+compatible = "mantix,mlaf057we51-x";
+reg = <0>;
+avdd-supply = <_avdd>;
+avee-supply = <_avee>;
+vddi-supply = <_1v8_p>;
+reset-gpios = < 29 GPIO_ACTIVE_LOW>;
+backlight = <>;
+ };
+};
+...
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 0/3] drm: Add support for Cadence MHDP DPI/DP bridge and J721E wrapper.
Hi,
On Wed, Aug 12, 2020 at 01:47:42PM +0300, Tomi Valkeinen wrote:
> Hi Guido,
>
> On 12/08/2020 11:39, Guido Günther wrote:
> > Hi,
> > On Thu, Aug 06, 2020 at 01:34:29PM +0200, Swapnil Jakhade wrote:
> >> This patch series adds new DRM bridge driver for Cadence MHDP DPI/DP
> >> bridge. The Cadence Display Port IP is also referred as MHDP (Mobile High
> >> Definition Link, High-Definition Multimedia Interface, Display Port).
> >> Cadence Display Port complies with VESA DisplayPort (DP) and embedded
> >> Display Port (eDP) standards.
> >
> > Is there any relation to the cadence mhdp ip core used inthe imx8mq:
> >
> >
> > https://lore.kernel.org/dri-devel/cover.1590982881.git.sandor...@nxp.com/
> >
> > It looks very similar in several places so should that use the same driver?
> > Cheers,
> > -- Guido
>
> Interesting.
>
> So the original Cadence DP patches for TI SoCs did create a common driver
> with Rockchip's older mhdp
> driver. And looks like the IMX series points to an early version of that
> patch ("drm/rockchip:
> prepare common code for cdns and rk dpi/dp driver").
>
> We gave up on that as the IPs did have differences and the firmwares used
> were apparently quite
> different. The end result was very difficult to maintain, especially as
> (afaik) none of the people
> involved had relevant Rockchip HW.
Is the `struct mhdp_platform_ops` a leftover from that? Can that be dropped?
> The idea was to get a stable DP driver for TI SoCs ready and upstream, and
> then carefully try to
> create common parts with Rockchip's driver in small pieces.
I wonder how imx8 would best blend into this? First thing will likely be
to upstream the phy code in driveres/phy/ so a modified version of this bridge
driver could call into that, then go and look for common patterns.
> If the Rockchip and IMX mhdp have the same IP and same firmware, then they
> obviously should share
> code as done in the series you point to.
I'm pretty sure they use different firmware though - the imx8mq
additionally supports HDMI with a different firmware on the same IP core
(13.4 and 13.5 in the imx8mq ref manual).
> Perhaps Cadence can clarify the differences between IMX, TI and
> Rockchip IPs and FWs?
That would be great!
-- Guido
> I'm worried that if there are IP differences, even if not great ones, and if
> the FWs are different
> and developed separately, it'll be a constant "fix X for SoC A, and
> accidentally break Y for SoC B
> and C", especially if too much code is shared.
>
> In the long run I'm all for a single driver (or large shared parts), but I'm
> not sure if we should
> start with that approach.
>
> Tomi
>
> --
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 0/3] drm: Add support for Cadence MHDP DPI/DP bridge and J721E wrapper.
Hi, On Thu, Aug 06, 2020 at 01:34:29PM +0200, Swapnil Jakhade wrote: > This patch series adds new DRM bridge driver for Cadence MHDP DPI/DP > bridge. The Cadence Display Port IP is also referred as MHDP (Mobile High > Definition Link, High-Definition Multimedia Interface, Display Port). > Cadence Display Port complies with VESA DisplayPort (DP) and embedded > Display Port (eDP) standards. Is there any relation to the cadence mhdp ip core used inthe imx8mq: https://lore.kernel.org/dri-devel/cover.1590982881.git.sandor...@nxp.com/ It looks very similar in several places so should that use the same driver? Cheers, -- Guido > > The MHDP bridge driver currently implements Single Stream Transport (SST) > mode. It also adds Texas Instruments j721e SoC specific wrapper and adds > the device tree bindings in YAML format. > > Some of the features that will be added later on include (but are not > limited to): > - Power Management (PM) support: We will implement the PM functions in > next stage once there will be a stable driver in upstream > - Audio and MST support > > The patch series has three patches in the below sequence: > 1. 0001-dt-bindings-drm-bridge-Document-Cadence-MHDP-brid.patch > Documents the bindings in yaml format. > 2. 0002-drm-bridge-Add-support-for-Cadence-MHDP-DPI-DP-br.patch > This patch adds new DRM bridge driver for Cadence MHDP Display Port. > The patch implements support for single stream transport mode. > 3. 0003-drm-bridge-cdns-mhdp-Add-j721e-wrapper.patch > Adds Texas Instruments (TI) j721e wrapper for MHDP. The wrapper configures > MHDP clocks and muxes as required by SoC. > > This patch series is dependent on PHY patch series [1] to add new PHY APIs > to get/set PHY attributes which is under review and not merged yet. > > [1] https://lkml.org/lkml/2020/7/17/158 > > Version History: > > v8: > > In 1/3 > - Fix error reported by dt_binding_check > - Fix indent in the example > - Fix other comments given for v7 patches. > > In 2/3: > - Implement bridge connector operations .get_edid() and .detect(). > - Make connector creation optional based on DRM_BRIDGE_ATTACH_NO_CONNECTOR > flag. > - Fix other comments given for v7 patches. > > In 3/3 > - Fix comments given for v7 patches. > > v7: > > In 1/3 > - No change > > In 2/3 > - Switch to atomic versions of bridge operations > - Implement atomic_check() handler to perform all validation checks > - Add struct cdns_mhdp_bridge_state with subclassed bridge state > - Use PHY API[1] to get PHY attributes instead of reading from PHY DT node > - Updated HPD handling and link configuration in IRQ handler > - Add "link_mutex" protecting the access to all the link parameters > - Add support to check and print FW version information > - Add separate function to initialize host parameters to simplify probe > - Use waitqueue instead of manual loop in cdns_mhdp_remove > - Add forward declarations and header files in cdns-mhdp-core.h file > - Use bool instead of single bit values in struct cdns_mhdp_device > - Fix for other minor comments given for v6 patches > > In 3/3 > - Use of_device_is_compatible() to set compatible string specific values > - Move mhdp_ti_j721e_ops structure to cdns-mhdp-j721e.c > - Remove duplicate Copyright message > - Remove CONFIG_DRM_CDNS_MHDP_J721E check > - Add Reviewed-by: Laurent Pinchart > > v6: > - Added minor fixes in YAML file. > - Added Reviewed-by: Laurent Pinchart > to the YAML patch. > - Removed all the FIXME comments which are invalid in drm driver. > - Reduced the mailbox timeout from 5s to 2s. > - Added Reviewed-by: Tomi Valkeinen > to the 003-drm-mhdp-add-j721e-wrapper patch. > - Added Signed-off all the module authors. > - Fixed the compiler error Reported-by: kbuild test robot . > > v5: > - Added Signed-off-by: Jyri Sarha tag to > the code patches. > > v4: > - Added SPDX dual license tag to YAML bindings. > - Corrected indentation of the child node properties. > - Removed the maxItems in the conditional statement. > - Add Reviewed-by: Rob Herring tag to the > Document Cadence MHDP bridge bindings patch. > - Renamed the DRM driver executable name from mhdp8546 to cdns-mhdp in > Makefile. > - Renamed the DRM driver and header file from cdns-mhdp to cdns-mhdp-core. > > v3: > - Added if / then clause to validate that the reg length is proper > based on the value of the compatible property. > - Updated phy property description in YAML to a generic one. > - Renamed num_lanes and max_bit_rate property strings to cdns,num-lanes > and cdns,max-bit-rate. > > v2: > - Use enum in compatible property of YAML file. > - Add reg-names property to YAML file > - Add minItems and maxItems to reg property in YAML. > - Remove cdns_mhdp_link_probe function to remove > duplication of reading dpcd capabilities. > > Swapnil Jakhade (2): > drm: bridge: Add support for Cadence MHDP DPI/DP bridge > drm: bridge: cdns-mhdp: Add j721e wrapper > > Yuti Amonkar (1): > dt-bindings:
Re: [PATCH 0/2] Fix st7703 panel initialization failures
Hi Ondřej, On Thu, Jul 30, 2020 at 03:41:11PM +0200, Ondřej Jirman wrote: > Hello, > > On Wed, Jul 29, 2020 at 05:48:09PM +0200, Guido Günther wrote: > > Hi, > > On Sat, Jul 18, 2020 at 07:42:15PM +0200, Ondřej Jirman wrote: > > > Hello, > > > > > > On Sat, Jul 18, 2020 at 07:31:24PM +0200, Guido Günther wrote: > > > > Hi, > > > > On Thu, Jul 16, 2020 at 04:32:09PM +0200, Ondřej Jirman wrote: > > > > > Hi Guido, > > > > > > > > > > On Thu, Jul 16, 2020 at 04:08:43PM +0200, Guido Günther wrote: > > > > > > Hi Ondrej, > > > > > > On Thu, Jul 16, 2020 at 02:37:51PM +0200, Ondrej Jirman wrote: > > > > > > > When extending the driver for xbd599 panel support I tried to do > > > > > > > minimal > > > > > > > changes and keep the existing initialization timing. > > > > > > > > > > > > > > It turned out that it's not good enough and the existing init > > > > > > > sequence > > > > > > > is too aggressive and doesn't follow the specification. On > > > > > > > PinePhone > > > > > > > panel is being powered down/up during suspend/resume and with > > > > > > > current > > > > > > > timings this frequently leads to corrupted display. > > > > > > > > > > > > Given the amount of ST7703 look alikes i don't think you can go by > > > > > > the > > > > > > datasheet and hope not to break other panels. The current sleeps > > > > > > cater > > > > > > for the rocktech panel (which suffered from similar issues you > > > > > > describe > > > > > > when we took other parameters) so you need to make those panel > > > > > > specific. > > > > > > > > > > It should work on rocktech too. The patch mostly increases/reorders > > > > > the delays > > > > > slightly, to match the controller documentation. I don't see a reason > > > > > to > > > > > complicate the driver with per panel special delays, unless these > > > > > patches don't > > > > > work on your panel. > > > > > > > > That's why i brought it up. It breaks the rocktech panel on > > > > blank/unblank loops where it just stays blank and then starts hitting > > > > DSI command timeouts. > > > > > > Good to know. Does keeping the msleep(20); after init sequence and before > > > sleep > > > exit make it work? > > > > We need both sleeps to make this work reliably so basically > > reverting your 'drm/panel: st7703: Make the sleep exit timing match the > > spec' makes things stable again. > > > > We don't need to sleep 120ms after sleep out though since our panel only > > requires 15ms as per data sheet there so it really makes sense to make > > these configurable. > > Thank you for checking it. > > I'd be happy with just the other patch being applied. That would be enough > to fix issues with xingbangda panel too. That's fine since that case works here too. The commit message should be adjusted though since the ST7703 data sheet i'm looking at says there's no restriction about applying IOVCC and VCI (tRPW= +/- no limit). You're basically also switching to another reset pattern (the data sheet describes two). So instead of saying: "Fix the power up sequence of the panel" i'd rather say "Pick a reset sequence that works for ingbangda,xbd599 panel too" and then describe the changes since that helps us to identify later on why we made that change. With that and 1/2 dropped that looks good to me. Cheers, -- Guido > > In my tests xbd panel doesn't need 120ms either, despite the datasheet. > What breaks xbd panel is the lack of post-powerup delay before deasserting > reset line. > > regards, > o. > > > Cheers, > > -- Guido > > > > > > > > thank you and regards, > > > o. > > > > > > > Cheers, > > > > -- Guido > > > > > > > > > > > > > > The init sequence is still suboptimal, and doesn't follow the kernel > > > > > docs > > > > > completely, even after these patches. Controller spec also talks > > > > > about adding > > > > > some delay before enabling the backlight to avoid visual glitches. > > >
Re: [PATCH v9 2/5] drm/imx: Add initial support for DCSS on iMX8MQ
Hi, On Fri, Jul 31, 2020 at 11:18:30AM +0300, Laurentiu Palcu wrote: > From: Laurentiu Palcu > > This adds initial support for iMX8MQ's Display Controller Subsystem (DCSS). > Some of its capabilities include: > * 4K@60fps; > * HDR10; > * one graphics and 2 video pipelines; > * on-the-fly decompression of compressed video and graphics; > > The reference manual can be found here: > https://www.nxp.com/webapp/Download?colCode=IMX8MDQLQRM > > The current patch adds only basic functionality: one primary plane for > graphics, linear, tiled and super-tiled buffers support (no graphics > decompression yet), no HDR10 and no video planes. > > Video planes support and HDR10 will be added in subsequent patches once > per-plane de-gamma/CSC/gamma support is in. > > Signed-off-by: Laurentiu Palcu > Reviewed-by: Lucas Stach I'm putting a Acked-by: Guido Günther since it fixes the build for me and it looks good to me from what i know about DCSS. Cheers, -- Guido > --- > drivers/gpu/drm/imx/Kconfig| 2 + > drivers/gpu/drm/imx/Makefile | 1 + > drivers/gpu/drm/imx/dcss/Kconfig | 9 + > drivers/gpu/drm/imx/dcss/Makefile | 6 + > drivers/gpu/drm/imx/dcss/dcss-blkctl.c | 70 +++ > drivers/gpu/drm/imx/dcss/dcss-crtc.c | 219 +++ > drivers/gpu/drm/imx/dcss/dcss-ctxld.c | 424 + > drivers/gpu/drm/imx/dcss/dcss-dev.c| 314 ++ > drivers/gpu/drm/imx/dcss/dcss-dev.h| 177 ++ > drivers/gpu/drm/imx/dcss/dcss-dpr.c| 562 + > drivers/gpu/drm/imx/dcss/dcss-drv.c| 138 + > drivers/gpu/drm/imx/dcss/dcss-dtg.c| 409 > drivers/gpu/drm/imx/dcss/dcss-kms.c| 177 ++ > drivers/gpu/drm/imx/dcss/dcss-kms.h| 43 ++ > drivers/gpu/drm/imx/dcss/dcss-plane.c | 405 > drivers/gpu/drm/imx/dcss/dcss-scaler.c | 826 + > drivers/gpu/drm/imx/dcss/dcss-ss.c | 180 ++ > 17 files changed, 3962 insertions(+) > create mode 100644 drivers/gpu/drm/imx/dcss/Kconfig > create mode 100644 drivers/gpu/drm/imx/dcss/Makefile > create mode 100644 drivers/gpu/drm/imx/dcss/dcss-blkctl.c > create mode 100644 drivers/gpu/drm/imx/dcss/dcss-crtc.c > create mode 100644 drivers/gpu/drm/imx/dcss/dcss-ctxld.c > create mode 100644 drivers/gpu/drm/imx/dcss/dcss-dev.c > create mode 100644 drivers/gpu/drm/imx/dcss/dcss-dev.h > create mode 100644 drivers/gpu/drm/imx/dcss/dcss-dpr.c > create mode 100644 drivers/gpu/drm/imx/dcss/dcss-drv.c > create mode 100644 drivers/gpu/drm/imx/dcss/dcss-dtg.c > create mode 100644 drivers/gpu/drm/imx/dcss/dcss-kms.c > create mode 100644 drivers/gpu/drm/imx/dcss/dcss-kms.h > create mode 100644 drivers/gpu/drm/imx/dcss/dcss-plane.c > create mode 100644 drivers/gpu/drm/imx/dcss/dcss-scaler.c > create mode 100644 drivers/gpu/drm/imx/dcss/dcss-ss.c > > diff --git a/drivers/gpu/drm/imx/Kconfig b/drivers/gpu/drm/imx/Kconfig > index 207bf7409dfb..6231048aa5aa 100644 > --- a/drivers/gpu/drm/imx/Kconfig > +++ b/drivers/gpu/drm/imx/Kconfig > @@ -39,3 +39,5 @@ config DRM_IMX_HDMI > depends on DRM_IMX > help > Choose this if you want to use HDMI on i.MX6. > + > +source "drivers/gpu/drm/imx/dcss/Kconfig" > diff --git a/drivers/gpu/drm/imx/Makefile b/drivers/gpu/drm/imx/Makefile > index 21cdcc2faabc..b644deffe948 100644 > --- a/drivers/gpu/drm/imx/Makefile > +++ b/drivers/gpu/drm/imx/Makefile > @@ -9,3 +9,4 @@ obj-$(CONFIG_DRM_IMX_TVE) += imx-tve.o > obj-$(CONFIG_DRM_IMX_LDB) += imx-ldb.o > > obj-$(CONFIG_DRM_IMX_HDMI) += dw_hdmi-imx.o > +obj-$(CONFIG_DRM_IMX_DCSS) += dcss/ > diff --git a/drivers/gpu/drm/imx/dcss/Kconfig > b/drivers/gpu/drm/imx/dcss/Kconfig > new file mode 100644 > index ..69860de8861f > --- /dev/null > +++ b/drivers/gpu/drm/imx/dcss/Kconfig > @@ -0,0 +1,9 @@ > +config DRM_IMX_DCSS > + tristate "i.MX8MQ DCSS" > + select IMX_IRQSTEER > + select DRM_KMS_CMA_HELPER > + select VIDEOMODE_HELPERS > + depends on DRM && ARCH_MXC > + help > + Choose this if you have a NXP i.MX8MQ based system and want to use the > + Display Controller Subsystem. This option enables DCSS support. > diff --git a/drivers/gpu/drm/imx/dcss/Makefile > b/drivers/gpu/drm/imx/dcss/Makefile > new file mode 100644 > index ..8c7c8da42792 > --- /dev/null > +++ b/drivers/gpu/drm/imx/dcss/Makefile > @@ -0,0 +1,6 @@ > +imx-dcss-objs := dcss-drv.o dcss-dev.o dcss-blkctl.o dcss-ctxld.o dcss-dtg.o > \ > + dcss-ss.o dcss-dpr.o dcss-scaler.o dcss-kms.o > dcss-crtc.o \ > + dcss-plane.o > + > +obj-$(CON
Re: [PATCH v9 0/5] Add support for iMX8MQ Display Controller Subsystem
Hi, On Fri, Jul 31, 2020 at 11:18:28AM +0300, Laurentiu Palcu wrote: > From: Laurentiu Palcu > > Hi, > > This patchset adds initial DCSS support for iMX8MQ chip. Initial support > includes only graphics plane support (no video planes), no HDR10 capabilities, > no graphics decompression (only linear, tiled and super-tiled buffers > allowed). > > Support for the rest of the features will be added incrementally, in > subsequent > patches. > > The patchset was tested with both HDP driver (in the downstream tree) and the > upstream > MIPI-DSI driver (with a couple of patches on top, to make it work correctly > with DCSS). > > Thanks, > Laurentiu > > Changes in v9: > * Fixed a compilation issue found by Guido in his setup: 'select >VIDEOMODE_HELPERS' was missing from Kconfig; > * Use imx8mq-clock.h in the bindings file so one can understand what >those clock values mean; > * no other changes done. Couldn't address the hang Guido reported as >it's not happening in my setup. However, in my tree, there are some >extra NWL and ADV patches applied on top of upstream ones... Also, >removing them and testing only with upstream, even if there's no >image out, does not produce a hang... :/ I don't think this should hold up merging. Cheers, -- Guido > > Changes in v8: > * Removed 'select RESET_CONTROLLER" from Kconfig as Philipp pointed >out. SRC is not used in DCSS driver; > * Nothing else changed; > > Changes in v7: > * Added a patch to initialize the connector using the drm_bridge_connector >API as Sam suggested. Tested it using NWL_DSI and ADV7535 with >Guido's patch [1] applied and one fix for ADV [2]. Also, some extra >patches for ADV and NWL were needed, from our downstream tree, which >will be upstreamed soon by their author; > * Rest of the patches are untouched; > > [1] https://lists.freedesktop.org/archives/dri-devel/2020-July/273025.html > [2] https://lists.freedesktop.org/archives/dri-devel/2020-July/273132.html > > Changes in v6: > * Addressed Rob's comment and added "additionalProperties: false" at >the end of the bindings' properties. However, this change surfaced >an issue with the assigned-clock* properties not being documented in >the properties section. Added the descriptions and the bindings patch >will need another review; > * Added an entry for DCSS driver in the MAINTAINERS file; > * Removed the component framework patch altogether; > > Changes in v5: > * Rebased to latest; > * Took out component framework support and made it a separate patch so >that people can still test with HDP driver, which makes use of it. >But the idea is to get rid of it once HDP driver's next versions >will remove component framework as well; > * Slight improvement to modesetting: avoid cutting off the pixel clock >if the new mode and the old one are equal. Also, in this case, is >not necessary to wait for DTG to shut off. This would allow to switch >from 8b RGB to 12b YUV422, for example, with no interruptions (at least >from DCSS point of view); > * Do not fire off CTXLD when going to suspend, unless it still has >entries that need to be committed to DCSS; > * Addressed Rob's comments on bindings; > > Changes in v4: > * Addressed Lucas and Philipp's comments: >* Added DRM_KMS_CMA_HELPER dependency in Kconfig; >* Removed usage of devm_ functions since I'm already doing all the > clean-up in the submodules_deinit(); >* Moved the drm_crtc_arm_vblank_event() in dcss_crtc_atomic_flush(); >* Removed en_completion variable from dcss_crtc since this was > introduced mainly to avoid vblank timeout warnings which were fixed > by arming the vblank event in flush() instead of begin(); >* Removed clks_on and irq_enabled flags since all the calls to > enabling/disabling clocks and interrupts were balanced; >* Removed the custom atomic_commit callback and used the DRM core > helper and, in the process, got rid of a workqueue that wasn't > necessary anymore; >* Fixed some minor DT binding issues flagged by Philipp; >* Some other minor changes suggested by Lucas; > * Removed YUV formats from the supported formats as these cannot work >without the HDR10 module CSCs and LUTs. Will add them back when I >will add support for video planes; > > Changes in v3: > * rebased to latest linux-next and made it compile as drmP.h was >removed; > * removed the patch adding the VIDEO2_PLL clock. It's already applied; > * removed an unnecessary 50ms sleep in the dcss_dtg_sync_set(); > * fixed a a spurious hang reported by Lukas Hartmann and encountered >by me several times; > * mask DPR and DTG interrupts by default, as they may come enabled from >U-boot; > > Changes in v2: > * Removed '0x' in node's unit-address both in DT and yaml; > * Made the address region size lowercase, to be consistent; > * Removed some left-over references to
Re: [PATCH v9 5/5] dt-bindings: display: imx: add bindings for DCSS
Hi,
On Fri, Jul 31, 2020 at 11:18:33AM +0300, Laurentiu Palcu wrote:
> From: Laurentiu Palcu
>
> Add bindings for iMX8MQ Display Controller Subsystem.
>
> Signed-off-by: Laurentiu Palcu
> ---
> Changes in v9:
> * Include imx8mq-clock.h in the example so we can use clock names
>instead of their values;
Reviewed-by: Guido Günther
(and passed DT bindings check for me)
-- Guido
>
> .../bindings/display/imx/nxp,imx8mq-dcss.yaml | 108 ++
> 1 file changed, 108 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/imx/nxp,imx8mq-dcss.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/imx/nxp,imx8mq-dcss.yaml
> b/Documentation/devicetree/bindings/display/imx/nxp,imx8mq-dcss.yaml
> new file mode 100644
> index ..f1f25aa794d9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/imx/nxp,imx8mq-dcss.yaml
> @@ -0,0 +1,108 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +# Copyright 2019 NXP
> +%YAML 1.2
> +---
> +$id: "http://devicetree.org/schemas/display/imx/nxp,imx8mq-dcss.yaml#;
> +$schema: "http://devicetree.org/meta-schemas/core.yaml#;
> +
> +title: iMX8MQ Display Controller Subsystem (DCSS)
> +
> +maintainers:
> + - Laurentiu Palcu
> +
> +description:
> +
> + The DCSS (display controller sub system) is used to source up to three
> + display buffers, compose them, and drive a display using HDMI 2.0a(with
> HDCP
> + 2.2) or MIPI-DSI. The DCSS is intended to support up to 4kp60 displays.
> HDR10
> + image processing capabilities are included to provide a solution capable of
> + driving next generation high dynamic range displays.
> +
> +properties:
> + compatible:
> +const: nxp,imx8mq-dcss
> +
> + reg:
> +items:
> + - description: DCSS base address and size, up to IRQ steer start
> + - description: DCSS BLKCTL base address and size
> +
> + interrupts:
> +items:
> + - description: Context loader completion and error interrupt
> + - description: DTG interrupt used to signal context loader trigger time
> + - description: DTG interrupt for Vblank
> +
> + interrupt-names:
> +items:
> + - const: ctxld
> + - const: ctxld_kick
> + - const: vblank
> +
> + clocks:
> +items:
> + - description: Display APB clock for all peripheral PIO access
> interfaces
> + - description: Display AXI clock needed by DPR, Scaler, RTRAM_CTRL
> + - description: RTRAM clock
> + - description: Pixel clock, can be driven either by HDMI phy clock or
> MIPI
> + - description: DTRC clock, needed by video decompressor
> +
> + clock-names:
> +items:
> + - const: apb
> + - const: axi
> + - const: rtrm
> + - const: pix
> + - const: dtrc
> +
> + assigned-clocks:
> +items:
> + - description: Phandle and clock specifier of IMX8MQ_CLK_DISP_AXI_ROOT
> + - description: Phandle and clock specifier of IMX8MQ_CLK_DISP_RTRM
> + - description: Phandle and clock specifier of either
> IMX8MQ_VIDEO2_PLL1_REF_SEL or
> + IMX8MQ_VIDEO_PLL1_REF_SEL
> +
> + assigned-clock-parents:
> +items:
> + - description: Phandle and clock specifier of IMX8MQ_SYS1_PLL_800M
> + - description: Phandle and clock specifier of IMX8MQ_SYS1_PLL_800M
> + - description: Phandle and clock specifier of IMX8MQ_CLK_27M
> +
> + assigned-clock-rates:
> +items:
> + - description: Must be 800 MHz
> + - description: Must be 400 MHz
> +
> + port:
> +type: object
> +description:
> + A port node pointing to the input port of a HDMI/DP or MIPI display
> bridge.
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +#include
> +dcss: display-controller@32e0 {
> +compatible = "nxp,imx8mq-dcss";
> +reg = <0x32e0 0x2d000>, <0x32e2f000 0x1000>;
> +interrupts = <6>, <8>, <9>;
> +interrupt-names = "ctxld", "ctxld_kick", "vblank";
> +interrupt-parent = <>;
> +clocks = < IMX8MQ_CLK_DISP_APB_ROOT>, <
> IMX8MQ_CLK_DISP_AXI_ROOT>,
> + < IMX8MQ_CLK_DISP_RTRM_ROOT>, <
> IMX8MQ_VIDEO2_PLL_OUT>,
> + < IMX8MQ_CLK_DISP_DTRC>;
> +clock-names = "apb", "axi", "rtrm", "pix", "dtrc";
> +assigned-clocks = < IMX8MQ_CLK_DISP_AXI>, <
> IMX8MQ_CLK_DISP_RTRM>,
> + < IMX8MQ_VIDEO2_PLL1_REF_SEL>;
> +assigned-clock-parents = < IMX8MQ_SYS1_PLL_800M>, <
> IMX8MQ_SYS1_PLL_800M>,
> + < IMX8MQ_CLK_27M>;
> +assigned-clock-rates = <8>,
> + <4>;
> +port {
> +dcss_out: endpoint {
> +remote-endpoint = <_in>;
> +};
> +};
> +};
> +
> --
> 2.23.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 4/5] MAINTAINERS: Add entry for i.MX 8MQ DCSS driver
Hi, On Fri, Jul 31, 2020 at 11:18:32AM +0300, Laurentiu Palcu wrote: > From: Laurentiu Palcu > > The driver is part of DRM subsystem and is located in > drivers/gpu/drm/imx/dcss. > > Signed-off-by: Laurentiu Palcu Reviewed-by: Guido Günther > --- > MAINTAINERS | 8 > 1 file changed, 8 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 2c669c07fa35..1a22038f2869 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -12281,6 +12281,14 @@ F: drivers/iio/gyro/fxas21002c_core.c > F: drivers/iio/gyro/fxas21002c_i2c.c > F: drivers/iio/gyro/fxas21002c_spi.c > > +NXP i.MX 8MQ DCSS DRIVER > +M: Laurentiu Palcu > +R: Lucas Stach > +L: dri-devel@lists.freedesktop.org > +S: Maintained > +F: Documentation/devicetree/bindings/display/imx/nxp,imx8mq-dcss.yaml > +F: drivers/gpu/drm/imx/dcss/ > + > NXP SGTL5000 DRIVER > M: Fabio Estevam > L: alsa-de...@alsa-project.org (moderated for non-subscribers) > -- > 2.23.0 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 1/5] drm/imx: compile imx directory by default
Hi, On Fri, Jul 31, 2020 at 11:18:29AM +0300, Laurentiu Palcu wrote: > From: Laurentiu Palcu > > Currently the drm/imx/ directory is compiled only if DRM_IMX is set. Adding a > new IMX related IP in the same directory would need DRM_IMX to be set, which > would > bring in also IPUv3 core driver... > > The current patch would allow adding new IPs in the imx/ directory without > needing > to set DRM_IMX. Reviewed-by: Guido Günther > > Signed-off-by: Laurentiu Palcu > Reviewed-by: Lucas Stach > --- > drivers/gpu/drm/Makefile | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile > index 2f31579f91d4..81569009f884 100644 > --- a/drivers/gpu/drm/Makefile > +++ b/drivers/gpu/drm/Makefile > @@ -100,7 +100,7 @@ obj-$(CONFIG_DRM_MSM) += msm/ > obj-$(CONFIG_DRM_TEGRA) += tegra/ > obj-$(CONFIG_DRM_STM) += stm/ > obj-$(CONFIG_DRM_STI) += sti/ > -obj-$(CONFIG_DRM_IMX) += imx/ > +obj-y+= imx/ > obj-$(CONFIG_DRM_INGENIC) += ingenic/ > obj-$(CONFIG_DRM_MEDIATEK) += mediatek/ > obj-$(CONFIG_DRM_MESON) += meson/ > -- > 2.23.0 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 0/5] Add support for iMX8MQ Display Controller Subsystem
Hi Laurentiu, On Thu, Jul 30, 2020 at 12:10:55PM +0300, Laurentiu Palcu wrote: > Hi Guido, > > On Wed, Jul 29, 2020 at 05:09:52PM +0200, Guido Günther wrote: > > Hi, > > On Wed, Jul 29, 2020 at 05:16:47PM +0300, Laurentiu Palcu wrote: > > > Hi Guido, > > > > > > On Wed, Jul 29, 2020 at 03:59:48PM +0200, Guido Günther wrote: > > > > Hi, > > > > On Fri, Jul 24, 2020 at 12:07:29PM +0300, Laurentiu Palcu wrote: > > > > > From: Laurentiu Palcu > > > > > > > > > > Hi, > > > > > > > > > > This patchset adds initial DCSS support for iMX8MQ chip. Initial > > > > > support > > > > > includes only graphics plane support (no video planes), no HDR10 > > > > > capabilities, > > > > > no graphics decompression (only linear, tiled and super-tiled buffers > > > > > allowed). > > > > > > > > > > Support for the rest of the features will be added incrementally, in > > > > > subsequent > > > > > patches. > > > > > > > > > > The patchset was tested with both HDP driver (in the downstream tree) > > > > > and the upstream > > > > > MIPI-DSI driver (with a couple of patches on top, to make it work > > > > > correctly with DCSS). > > > > > > > > While i could run earlier versions of this series with NWL I'm seeing > > > > only a brief image that then turns black (backlight still on) with this > > > > current version and > > > > the board hangs soon after.(for reference using mxsfb works nicely with > > > > the very same DT on next-20200727). If I do a drm.debug=0x3f i can see > > > > that display output stops around: > > > > > > > > [ 15.394473] imx-dcss 32e0.display-controller: > > > > [drm:drm_update_vblank_count] updating vblank count on crtc 0: > > > > current=22, diff=1, hw=0 hw_last=0 > > > > [ 15.397575] device: 'input1': device_add > > > > [ 15.444658] imx-dcss 32e0.display-controller: > > > > [drm:drm_update_vblank_count] updating vblank count on crtc 0: > > > > current=23, diff=1, hw=0 hw_last=0 > > > > [ 15.465946] PM: Adding info for No Bus:input1 > > > > [ 15.494842] imx-dcss 32e0.display-controller: > > > > [drm:drm_update_vblank_count] updating vblank count on crtc 0: > > > > current=24, diff=1, hw=0 hw_last=0 > > > > [ 15.511694] input: gpio-keys as > > > > /devices/platform/gpio-keys/input/input1 > > > > [ 15.545025] imx-dcss 32e0.display-controller: > > > > [drm:drm_update_vblank_count] updating vblank count on crtc 0: > > > > current=25, diff=1, hw=0 hw_last=0 > > > > [ 15.557869] device: 'event1': device_add > > > > [ 15.595209] imx-dcss 32e0.display-controller: > > > > [drm:drm_update_vblank_count] updating vblank count on crtc 0: > > > > current=26, diff=1, hw=0 hw_last=0 > > > > [ 15.605363] PM: Adding info for No Bus:event1 > > > > [ 15.645394] imx-dcss 32e0.display-controller: > > > > [drm:drm_update_vblank_count] updating vblank count on crtc 0: > > > > current=27, diff=1, hw=0 hw_last=0 > > > > [ 19.427039] imx-dcss 32e0.display-controller: > > > > [drm:vblank_disable_fn] disabling vblank on crtc 0 > > > > [ 19.436135] device: 'wakeup6': device_add > > > > [ 19.448202] imx-dcss 32e0.display-controller: > > > > [drm:drm_update_vblank_count] updating vblank count on crtc 0: > > > > current=28, diff=0, hw=0 hw_last=0 > > > > > > > > (and there's no further logging from drm from there on). > > > > > > > > Would any the above mentioned patches do anything in that area? > > > > > > The NWL driver is missing at least one fix that is needed for DCSS to > > > work nicely with it. One thing that needs fixed is the polarity. I added > > > a patch for that in our tree... :/ > > > > > > Currently, in NWL upstream, we have > > > > > > adjusted_mode->flags |= (DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC); > > > adjusted_mode->flags &= ~(DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC); > > > > > > However DCSS works with: > > > > > > adjusted->flags &= ~(DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC); > > > adjusted->fl
Re: [PATCH 0/2] Fix st7703 panel initialization failures
Hi, On Sat, Jul 18, 2020 at 07:42:15PM +0200, Ondřej Jirman wrote: > Hello, > > On Sat, Jul 18, 2020 at 07:31:24PM +0200, Guido Günther wrote: > > Hi, > > On Thu, Jul 16, 2020 at 04:32:09PM +0200, Ondřej Jirman wrote: > > > Hi Guido, > > > > > > On Thu, Jul 16, 2020 at 04:08:43PM +0200, Guido Günther wrote: > > > > Hi Ondrej, > > > > On Thu, Jul 16, 2020 at 02:37:51PM +0200, Ondrej Jirman wrote: > > > > > When extending the driver for xbd599 panel support I tried to do > > > > > minimal > > > > > changes and keep the existing initialization timing. > > > > > > > > > > It turned out that it's not good enough and the existing init sequence > > > > > is too aggressive and doesn't follow the specification. On PinePhone > > > > > panel is being powered down/up during suspend/resume and with current > > > > > timings this frequently leads to corrupted display. > > > > > > > > Given the amount of ST7703 look alikes i don't think you can go by the > > > > datasheet and hope not to break other panels. The current sleeps cater > > > > for the rocktech panel (which suffered from similar issues you describe > > > > when we took other parameters) so you need to make those panel specific. > > > > > > It should work on rocktech too. The patch mostly increases/reorders the > > > delays > > > slightly, to match the controller documentation. I don't see a reason to > > > complicate the driver with per panel special delays, unless these patches > > > don't > > > work on your panel. > > > > That's why i brought it up. It breaks the rocktech panel on > > blank/unblank loops where it just stays blank and then starts hitting > > DSI command timeouts. > > Good to know. Does keeping the msleep(20); after init sequence and before > sleep > exit make it work? We need both sleeps to make this work reliably so basically reverting your 'drm/panel: st7703: Make the sleep exit timing match the spec' makes things stable again. We don't need to sleep 120ms after sleep out though since our panel only requires 15ms as per data sheet there so it really makes sense to make these configurable. Cheers, -- Guido > > thank you and regards, > o. > > > Cheers, > > -- Guido > > > > > > > > The init sequence is still suboptimal, and doesn't follow the kernel docs > > > completely, even after these patches. Controller spec also talks about > > > adding > > > some delay before enabling the backlight to avoid visual glitches. > > > > > > Which is what enable callback is documented to be for. Currently part of > > > the > > > initialization that belongs to prepare callback is also done in enable > > > callback. > > > > > > I see the glitch (small vertical shift of the image on powerup), but > > > personally > > > don't care much to introduce even more delays to the driver, just for the > > > cosmetic issue. > > > > > > regards, > > > o. > > > > > > > Cheers, > > > > -- Guido > > > > > > > > > > > > > > This patch series fixes the problems. > > > > > > > > > > The issue was reported by Samuel Holland. > > > > > > > > > > Relevant screenshots from the datasheet: > > > > > > > > > > Power on timing: https://megous.com/dl/tmp/35b72e674ce0ca27.png > > > > > Power off timing: https://megous.com/dl/tmp/dea195517106ff17.png > > > > > More optimal reset on poweron: > > > > > https://megous.com/dl/tmp/a9e5caf14e1b0dc6.png > > > > > Less optimal reset on poweron: > > > > > https://megous.com/dl/tmp/246761039283c4cf.png > > > > > Datasheet: https://megous.com/dl/tmp/ST7703_DS_v01_20160128.pdf > > > > > > > > > > Please take a look. > > > > > > > > > > thank you and regards, > > > > > Ondrej Jirman > > > > > > > > > > Ondrej Jirman (2): > > > > > drm/panel: st7703: Make the sleep exit timing match the spec > > > > > drm/panel: st7703: Fix the power up sequence of the panel > > > > > > > > > > drivers/gpu/drm/panel/panel-sitronix-st7703.c | 29 > > > > > ++- > > > > > 1 file changed, 15 insertions(+), 14 deletions(-) > > > > > > > > > > -- > > > > > 2.27.0 > > > > > > > > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 0/5] Add support for iMX8MQ Display Controller Subsystem
Hi, On Wed, Jul 29, 2020 at 05:16:47PM +0300, Laurentiu Palcu wrote: > Hi Guido, > > On Wed, Jul 29, 2020 at 03:59:48PM +0200, Guido Günther wrote: > > Hi, > > On Fri, Jul 24, 2020 at 12:07:29PM +0300, Laurentiu Palcu wrote: > > > From: Laurentiu Palcu > > > > > > Hi, > > > > > > This patchset adds initial DCSS support for iMX8MQ chip. Initial support > > > includes only graphics plane support (no video planes), no HDR10 > > > capabilities, > > > no graphics decompression (only linear, tiled and super-tiled buffers > > > allowed). > > > > > > Support for the rest of the features will be added incrementally, in > > > subsequent > > > patches. > > > > > > The patchset was tested with both HDP driver (in the downstream tree) and > > > the upstream > > > MIPI-DSI driver (with a couple of patches on top, to make it work > > > correctly with DCSS). > > > > While i could run earlier versions of this series with NWL I'm seeing > > only a brief image that then turns black (backlight still on) with this > > current version and > > the board hangs soon after.(for reference using mxsfb works nicely with > > the very same DT on next-20200727). If I do a drm.debug=0x3f i can see > > that display output stops around: > > > > [ 15.394473] imx-dcss 32e0.display-controller: > > [drm:drm_update_vblank_count] updating vblank count on crtc 0: current=22, > > diff=1, hw=0 hw_last=0 > > [ 15.397575] device: 'input1': device_add > > [ 15.444658] imx-dcss 32e0.display-controller: > > [drm:drm_update_vblank_count] updating vblank count on crtc 0: current=23, > > diff=1, hw=0 hw_last=0 > > [ 15.465946] PM: Adding info for No Bus:input1 > > [ 15.494842] imx-dcss 32e0.display-controller: > > [drm:drm_update_vblank_count] updating vblank count on crtc 0: current=24, > > diff=1, hw=0 hw_last=0 > > [ 15.511694] input: gpio-keys as /devices/platform/gpio-keys/input/input1 > > [ 15.545025] imx-dcss 32e0.display-controller: > > [drm:drm_update_vblank_count] updating vblank count on crtc 0: current=25, > > diff=1, hw=0 hw_last=0 > > [ 15.557869] device: 'event1': device_add > > [ 15.595209] imx-dcss 32e0.display-controller: > > [drm:drm_update_vblank_count] updating vblank count on crtc 0: current=26, > > diff=1, hw=0 hw_last=0 > > [ 15.605363] PM: Adding info for No Bus:event1 > > [ 15.645394] imx-dcss 32e0.display-controller: > > [drm:drm_update_vblank_count] updating vblank count on crtc 0: current=27, > > diff=1, hw=0 hw_last=0 > > [ 19.427039] imx-dcss 32e0.display-controller: > > [drm:vblank_disable_fn] disabling vblank on crtc 0 > > [ 19.436135] device: 'wakeup6': device_add > > [ 19.448202] imx-dcss 32e0.display-controller: > > [drm:drm_update_vblank_count] updating vblank count on crtc 0: current=28, > > diff=0, hw=0 hw_last=0 > > > > (and there's no further logging from drm from there on). > > > > Would any the above mentioned patches do anything in that area? > > The NWL driver is missing at least one fix that is needed for DCSS to > work nicely with it. One thing that needs fixed is the polarity. I added > a patch for that in our tree... :/ > > Currently, in NWL upstream, we have > > adjusted_mode->flags |= (DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC); > adjusted_mode->flags &= ~(DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC); > > However DCSS works with: > > adjusted->flags &= ~(DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC); > adjusted->flags |= (DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC); Thanks! I remember not getting any output at all with DCSS without what you suggest above but now i get some output and then a hang so there seems to be something else off. Cheers, -- Guido > > I CCed Robert. He'll work on upstreaming these NWL changes in the following > period of time. > > Thanks, > laurentiu > > > > > Cheers, > > -- Guido > > > > > > > > Thanks, > > > Laurentiu > > > > > > Changes in v8: > > > * Removed 'select RESET_CONTROLLER" from Kconfig as Philipp pointed > > >out. SRC is not used in DCSS driver; > > > * Nothing else changed; > > > > > > Changes in v7: > > > * Added a patch to initialize the connector using the > > > drm_bridge_connector > > >API as Sam suggested. Tested it using NWL_DSI and ADV7535 with > > >Guido's patch [1] applied and o
Re: [PATCH v8 0/5] Add support for iMX8MQ Display Controller Subsystem
Hi, On Fri, Jul 24, 2020 at 12:07:29PM +0300, Laurentiu Palcu wrote: > From: Laurentiu Palcu > > Hi, > > This patchset adds initial DCSS support for iMX8MQ chip. Initial support > includes only graphics plane support (no video planes), no HDR10 capabilities, > no graphics decompression (only linear, tiled and super-tiled buffers > allowed). > > Support for the rest of the features will be added incrementally, in > subsequent > patches. > > The patchset was tested with both HDP driver (in the downstream tree) and the > upstream > MIPI-DSI driver (with a couple of patches on top, to make it work > correctly with DCSS). While i could run earlier versions of this series with NWL I'm seeing only a brief image that then turns black (backlight still on) with this current version and the board hangs soon after.(for reference using mxsfb works nicely with the very same DT on next-20200727). If I do a drm.debug=0x3f i can see that display output stops around: [ 15.394473] imx-dcss 32e0.display-controller: [drm:drm_update_vblank_count] updating vblank count on crtc 0: current=22, diff=1, hw=0 hw_last=0 [ 15.397575] device: 'input1': device_add [ 15.444658] imx-dcss 32e0.display-controller: [drm:drm_update_vblank_count] updating vblank count on crtc 0: current=23, diff=1, hw=0 hw_last=0 [ 15.465946] PM: Adding info for No Bus:input1 [ 15.494842] imx-dcss 32e0.display-controller: [drm:drm_update_vblank_count] updating vblank count on crtc 0: current=24, diff=1, hw=0 hw_last=0 [ 15.511694] input: gpio-keys as /devices/platform/gpio-keys/input/input1 [ 15.545025] imx-dcss 32e0.display-controller: [drm:drm_update_vblank_count] updating vblank count on crtc 0: current=25, diff=1, hw=0 hw_last=0 [ 15.557869] device: 'event1': device_add [ 15.595209] imx-dcss 32e0.display-controller: [drm:drm_update_vblank_count] updating vblank count on crtc 0: current=26, diff=1, hw=0 hw_last=0 [ 15.605363] PM: Adding info for No Bus:event1 [ 15.645394] imx-dcss 32e0.display-controller: [drm:drm_update_vblank_count] updating vblank count on crtc 0: current=27, diff=1, hw=0 hw_last=0 [ 19.427039] imx-dcss 32e0.display-controller: [drm:vblank_disable_fn] disabling vblank on crtc 0 [ 19.436135] device: 'wakeup6': device_add [ 19.448202] imx-dcss 32e0.display-controller: [drm:drm_update_vblank_count] updating vblank count on crtc 0: current=28, diff=0, hw=0 hw_last=0 (and there's no further logging from drm from there on). Would any the above mentioned patches do anything in that area? Cheers, -- Guido > > Thanks, > Laurentiu > > Changes in v8: > * Removed 'select RESET_CONTROLLER" from Kconfig as Philipp pointed >out. SRC is not used in DCSS driver; > * Nothing else changed; > > Changes in v7: > * Added a patch to initialize the connector using the drm_bridge_connector >API as Sam suggested. Tested it using NWL_DSI and ADV7535 with >Guido's patch [1] applied and one fix for ADV [2]. Also, some extra >patches for ADV and NWL were needed, from our downstream tree, which >will be upstreamed soon by their author; > * Rest of the patches are untouched; > > [1] https://lists.freedesktop.org/archives/dri-devel/2020-July/273025.html > [2] https://lists.freedesktop.org/archives/dri-devel/2020-July/273132.html > > Changes in v6: > * Addressed Rob's comment and added "additionalProperties: false" at >the end of the bindings' properties. However, this change surfaced >an issue with the assigned-clock* properties not being documented in >the properties section. Added the descriptions and the bindings patch >will need another review; > * Added an entry for DCSS driver in the MAINTAINERS file; > * Removed the component framework patch altogether; > > Changes in v5: > * Rebased to latest; > * Took out component framework support and made it a separate patch so >that people can still test with HDP driver, which makes use of it. >But the idea is to get rid of it once HDP driver's next versions >will remove component framework as well; > * Slight improvement to modesetting: avoid cutting off the pixel clock >if the new mode and the old one are equal. Also, in this case, is >not necessary to wait for DTG to shut off. This would allow to switch >from 8b RGB to 12b YUV422, for example, with no interruptions (at least >from DCSS point of view); > * Do not fire off CTXLD when going to suspend, unless it still has >entries that need to be committed to DCSS; > * Addressed Rob's comments on bindings; > > Changes in v4: > * Addressed Lucas and Philipp's comments: >* Added DRM_KMS_CMA_HELPER dependency in Kconfig; >* Removed usage of devm_ functions since I'm already doing all the > clean-up in the submodules_deinit(); >* Moved the drm_crtc_arm_vblank_event() in dcss_crtc_atomic_flush(); >* Removed en_completion variable from dcss_crtc since this was > introduced
Re: [PATCH v8 5/5] dt-bindings: display: imx: add bindings for DCSS
Hi,
On Fri, Jul 24, 2020 at 12:07:34PM +0300, Laurentiu Palcu wrote:
> From: Laurentiu Palcu
>
> Add bindings for iMX8MQ Display Controller Subsystem.
>
> Signed-off-by: Laurentiu Palcu
> Reviewed-by: Rob Herring
> ---
> .../bindings/display/imx/nxp,imx8mq-dcss.yaml | 104 ++
> 1 file changed, 104 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/imx/nxp,imx8mq-dcss.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/imx/nxp,imx8mq-dcss.yaml
> b/Documentation/devicetree/bindings/display/imx/nxp,imx8mq-dcss.yaml
> new file mode 100644
> index ..68e4635e4874
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/imx/nxp,imx8mq-dcss.yaml
> @@ -0,0 +1,104 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +# Copyright 2019 NXP
> +%YAML 1.2
> +---
> +$id: "http://devicetree.org/schemas/display/imx/nxp,imx8mq-dcss.yaml#;
> +$schema: "http://devicetree.org/meta-schemas/core.yaml#;
> +
> +title: iMX8MQ Display Controller Subsystem (DCSS)
> +
> +maintainers:
> + - Laurentiu Palcu
> +
> +description:
> +
> + The DCSS (display controller sub system) is used to source up to three
> + display buffers, compose them, and drive a display using HDMI 2.0a(with
> HDCP
> + 2.2) or MIPI-DSI. The DCSS is intended to support up to 4kp60 displays.
> HDR10
> + image processing capabilities are included to provide a solution capable of
> + driving next generation high dynamic range displays.
> +
> +properties:
> + compatible:
> +const: nxp,imx8mq-dcss
> +
> + reg:
> +items:
> + - description: DCSS base address and size, up to IRQ steer start
> + - description: DCSS BLKCTL base address and size
> +
> + interrupts:
> +items:
> + - description: Context loader completion and error interrupt
> + - description: DTG interrupt used to signal context loader trigger time
> + - description: DTG interrupt for Vblank
> +
> + interrupt-names:
> +items:
> + - const: ctxld
> + - const: ctxld_kick
> + - const: vblank
> +
> + clocks:
> +items:
> + - description: Display APB clock for all peripheral PIO access
> interfaces
> + - description: Display AXI clock needed by DPR, Scaler, RTRAM_CTRL
> + - description: RTRAM clock
> + - description: Pixel clock, can be driven either by HDMI phy clock or
> MIPI
> + - description: DTRC clock, needed by video decompressor
> +
> + clock-names:
> +items:
> + - const: apb
> + - const: axi
> + - const: rtrm
> + - const: pix
> + - const: dtrc
> +
> + assigned-clocks:
> +items:
> + - description: Phandle and clock specifier of IMX8MQ_CLK_DISP_AXI_ROOT
> + - description: Phandle and clock specifier of IMX8MQ_CLK_DISP_RTRM
> + - description: Phandle and clock specifier of either
> IMX8MQ_VIDEO2_PLL1_REF_SEL or
> + IMX8MQ_VIDEO_PLL1_REF_SEL
> +
> + assigned-clock-parents:
> +items:
> + - description: Phandle and clock specifier of IMX8MQ_SYS1_PLL_800M
> + - description: Phandle and clock specifier of IMX8MQ_SYS1_PLL_800M
> + - description: Phandle and clock specifier of IMX8MQ_CLK_27M
> +
> + assigned-clock-rates:
> +items:
> + - description: Must be 800 MHz
> + - description: Must be 400 MHz
> +
> + port:
> +type: object
> +description:
> + A port node pointing to the input port of a HDMI/DP or MIPI display
> bridge.
> +
> +additionalProperties: false
> +
> +examples:
> + - |
it would be nice to
#include
here...
> +dcss: display-controller@32e0 {
> +compatible = "nxp,imx8mq-dcss";
> +reg = <0x32e0 0x2d000>, <0x32e2f000 0x1000>;
> +interrupts = <6>, <8>, <9>;
> +interrupt-names = "ctxld", "ctxld_kick", "vblank";
> +interrupt-parent = <>;
> +clocks = < 248>, < 247>, < 249>,
> + < 254>,< 122>;
> +clock-names = "apb", "axi", "rtrm", "pix", "dtrc";
> +assigned-clocks = < 107>, < 109>, < 266>;
> +assigned-clock-parents = < 78>, < 78>, < 3>;
so that clock names like IMX8MQ_CLK_DISP_AXI could be used to make this
even more useful.
Cheers,
-- Guido
> +assigned-clock-rates = <8>,
> + <4>;
> +port {
> +dcss_out: endpoint {
> +remote-endpoint = <_in>;
> +};
> +};
> +};
> +
> --
> 2.23.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 2/5] drm/imx: Add initial support for DCSS on iMX8MQ
Hi Laurentiu, On Fri, Jul 24, 2020 at 12:07:31PM +0300, Laurentiu Palcu wrote: > From: Laurentiu Palcu > > This adds initial support for iMX8MQ's Display Controller Subsystem (DCSS). > Some of its capabilities include: > * 4K@60fps; > * HDR10; > * one graphics and 2 video pipelines; > * on-the-fly decompression of compressed video and graphics; > > The reference manual can be found here: > https://www.nxp.com/webapp/Download?colCode=IMX8MDQLQRM > > The current patch adds only basic functionality: one primary plane for > graphics, linear, tiled and super-tiled buffers support (no graphics > decompression yet), no HDR10 and no video planes. > > Video planes support and HDR10 will be added in subsequent patches once > per-plane de-gamma/CSC/gamma support is in. > > Signed-off-by: Laurentiu Palcu > Reviewed-by: Lucas Stach > --- > drivers/gpu/drm/imx/Kconfig| 2 + > drivers/gpu/drm/imx/Makefile | 1 + > drivers/gpu/drm/imx/dcss/Kconfig | 8 + > drivers/gpu/drm/imx/dcss/Makefile | 6 + > drivers/gpu/drm/imx/dcss/dcss-blkctl.c | 70 +++ > drivers/gpu/drm/imx/dcss/dcss-crtc.c | 219 +++ > drivers/gpu/drm/imx/dcss/dcss-ctxld.c | 424 + > drivers/gpu/drm/imx/dcss/dcss-dev.c| 314 ++ > drivers/gpu/drm/imx/dcss/dcss-dev.h| 177 ++ > drivers/gpu/drm/imx/dcss/dcss-dpr.c| 562 + > drivers/gpu/drm/imx/dcss/dcss-drv.c| 138 + > drivers/gpu/drm/imx/dcss/dcss-dtg.c| 409 > drivers/gpu/drm/imx/dcss/dcss-kms.c| 177 ++ > drivers/gpu/drm/imx/dcss/dcss-kms.h| 43 ++ > drivers/gpu/drm/imx/dcss/dcss-plane.c | 405 > drivers/gpu/drm/imx/dcss/dcss-scaler.c | 826 + > drivers/gpu/drm/imx/dcss/dcss-ss.c | 180 ++ > 17 files changed, 3961 insertions(+) > create mode 100644 drivers/gpu/drm/imx/dcss/Kconfig > create mode 100644 drivers/gpu/drm/imx/dcss/Makefile > create mode 100644 drivers/gpu/drm/imx/dcss/dcss-blkctl.c > create mode 100644 drivers/gpu/drm/imx/dcss/dcss-crtc.c > create mode 100644 drivers/gpu/drm/imx/dcss/dcss-ctxld.c > create mode 100644 drivers/gpu/drm/imx/dcss/dcss-dev.c > create mode 100644 drivers/gpu/drm/imx/dcss/dcss-dev.h > create mode 100644 drivers/gpu/drm/imx/dcss/dcss-dpr.c > create mode 100644 drivers/gpu/drm/imx/dcss/dcss-drv.c > create mode 100644 drivers/gpu/drm/imx/dcss/dcss-dtg.c > create mode 100644 drivers/gpu/drm/imx/dcss/dcss-kms.c > create mode 100644 drivers/gpu/drm/imx/dcss/dcss-kms.h > create mode 100644 drivers/gpu/drm/imx/dcss/dcss-plane.c > create mode 100644 drivers/gpu/drm/imx/dcss/dcss-scaler.c > create mode 100644 drivers/gpu/drm/imx/dcss/dcss-ss.c > > diff --git a/drivers/gpu/drm/imx/Kconfig b/drivers/gpu/drm/imx/Kconfig > index 207bf7409dfb..6231048aa5aa 100644 > --- a/drivers/gpu/drm/imx/Kconfig > +++ b/drivers/gpu/drm/imx/Kconfig > @@ -39,3 +39,5 @@ config DRM_IMX_HDMI > depends on DRM_IMX > help > Choose this if you want to use HDMI on i.MX6. > + > +source "drivers/gpu/drm/imx/dcss/Kconfig" > diff --git a/drivers/gpu/drm/imx/Makefile b/drivers/gpu/drm/imx/Makefile > index 21cdcc2faabc..b644deffe948 100644 > --- a/drivers/gpu/drm/imx/Makefile > +++ b/drivers/gpu/drm/imx/Makefile > @@ -9,3 +9,4 @@ obj-$(CONFIG_DRM_IMX_TVE) += imx-tve.o > obj-$(CONFIG_DRM_IMX_LDB) += imx-ldb.o > > obj-$(CONFIG_DRM_IMX_HDMI) += dw_hdmi-imx.o > +obj-$(CONFIG_DRM_IMX_DCSS) += dcss/ > diff --git a/drivers/gpu/drm/imx/dcss/Kconfig > b/drivers/gpu/drm/imx/dcss/Kconfig > new file mode 100644 > index ..a76435924b6a > --- /dev/null > +++ b/drivers/gpu/drm/imx/dcss/Kconfig > @@ -0,0 +1,8 @@ > +config DRM_IMX_DCSS > + tristate "i.MX8MQ DCSS" > + select IMX_IRQSTEER > + select DRM_KMS_CMA_HELPER > + depends on DRM && ARCH_MXC I need a select VIDEOMODE_HELPERS here otherwise the build fails like LD .tmp_vmlinux.kallsyms1 aarch64-linux-gnu-ld: warning: -z norelro ignored aarch64-linux-gnu-ld: drivers/gpu/drm/imx/dcss/dcss-crtc.o: in function `dcss_crtc_atomic_enable': dcss-crtc.c:(.text+0x2a8): undefined reference to `drm_display_mode_to_videomode' make: *** [Makefile:1157: vmlinux] Error 1 on next-20200727. Cheers, -- Guido > + help > + Choose this if you have a NXP i.MX8MQ based system and want to use the > + Display Controller Subsystem. This option enables DCSS support. > diff --git a/drivers/gpu/drm/imx/dcss/Makefile > b/drivers/gpu/drm/imx/dcss/Makefile > new file mode 100644 > index ..8c7c8da42792 > --- /dev/null > +++ b/drivers/gpu/drm/imx/dcss/Makefile > @@ -0,0 +1,6 @@ > +imx-dcss-objs := dcss-drv.o dcss-dev.o dcss-blkctl.o dcss-ctxld.o dcss-dtg.o > \ > + dcss-ss.o dcss-dpr.o dcss-scaler.o dcss-kms.o > dcss-crtc.o \ > + dcss-plane.o > + > +obj-$(CONFIG_DRM_IMX_DCSS) += imx-dcss.o > + > diff --git
Re: [PATCH] drm/mxsfb: Make supported modifiers explicit
Hi,
On Mon, Jul 20, 2020 at 11:03:04AM +0200, Stefan Agner wrote:
> On 2020-07-18 19:14, Guido Günther wrote:
> > Hi,
> > On Mon, Mar 23, 2020 at 04:51:05PM +0100, Lucas Stach wrote:
> >> Am Montag, den 23.03.2020, 15:52 +0100 schrieb Guido Günther:
> >> > In contrast to other display controllers on imx like DCSS and ipuv3
> >> > lcdif/mxsfb does not support detiling e.g. vivante tiled layouts.
> >> > Since mesa might assume otherwise make it explicit that only
> >> > DRM_FORMAT_MOD_LINEAR is supported.
> >> >
> >> > Signed-off-by: Guido Günther
> >>
> >> Reviewed-by: Lucas Stach
> >
> > Can i do anything to get this applied?
> > Cheers,
> > -- Guido
>
> Sorry about the delay, I was thinking to apply it with another patchset
> which is not ready though.
>
> Pushed this patch to drm-misc-next just now.
Thanks!
-- Guido
>
> --
> Stefan
>
> >
> >>
> >> > ---
> >> > drivers/gpu/drm/mxsfb/mxsfb_drv.c | 9 +++--
> >> > 1 file changed, 7 insertions(+), 2 deletions(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> >> > b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> >> > index 762379530928..fc71e7a7a02e 100644
> >> > --- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> >> > +++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> >> > @@ -73,6 +73,11 @@ static const uint32_t mxsfb_formats[] = {
> >> > DRM_FORMAT_RGB565
> >> > };
> >> >
> >> > +static const uint64_t mxsfb_modifiers[] = {
> >> > +DRM_FORMAT_MOD_LINEAR,
> >> > +DRM_FORMAT_MOD_INVALID
> >> > +};
> >> > +
> >> > static struct mxsfb_drm_private *
> >> > drm_pipe_to_mxsfb_drm_private(struct drm_simple_display_pipe *pipe)
> >> > {
> >> > @@ -334,8 +339,8 @@ static int mxsfb_load(struct drm_device *drm,
> >> > unsigned long flags)
> >> > }
> >> >
> >> > ret = drm_simple_display_pipe_init(drm, >pipe,
> >> > _funcs,
> >> > -mxsfb_formats, ARRAY_SIZE(mxsfb_formats), NULL,
> >> > -mxsfb->connector);
> >> > +mxsfb_formats, ARRAY_SIZE(mxsfb_formats),
> >> > +mxsfb_modifiers, mxsfb->connector);
> >> > if (ret < 0) {
> >> > dev_err(drm->dev, "Cannot setup simple display pipe\n");
> >> > goto err_vblank;
> >>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 0/1] drm/bridge: nwl-dsi: Drop DRM_BRIDGE_ATTACH_NO_CONNECTOR check.
We don't create a connector but let panel_bridge handle that so there's no point in rejecting DRM_BRIDGE_ATTACH_NO_CONNECTOR. This was prompted by Sam in https://lore.kernel.org/dri-devel/20200718115734.ga2989...@ravnborg.org/ Signed-off-by: Guido Günther Guido Günther (1): drm/bridge: nwl-dsi: Drop DRM_BRIDGE_ATTACH_NO_CONNECTOR check. drivers/gpu/drm/bridge/nwl-dsi.c | 5 - 1 file changed, 5 deletions(-) -- 2.26.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 1/1] drm/bridge: nwl-dsi: Drop DRM_BRIDGE_ATTACH_NO_CONNECTOR check.
We don't create a connector but let panel_bridge handle that so there's
no point in rejecting DRM_BRIDGE_ATTACH_NO_CONNECTOR.
Signed-off-by: Guido Günther
---
drivers/gpu/drm/bridge/nwl-dsi.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/bridge/nwl-dsi.c b/drivers/gpu/drm/bridge/nwl-dsi.c
index 77a79af70914..ce94f797d090 100644
--- a/drivers/gpu/drm/bridge/nwl-dsi.c
+++ b/drivers/gpu/drm/bridge/nwl-dsi.c
@@ -918,11 +918,6 @@ static int nwl_dsi_bridge_attach(struct drm_bridge *bridge,
struct drm_panel *panel;
int ret;
- if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR) {
- DRM_ERROR("Fix bridge driver to make connector optional!");
- return -EINVAL;
- }
-
ret = drm_of_find_panel_or_bridge(dsi->dev->of_node, 1, 0, ,
_bridge);
if (ret)
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/2] Fix st7703 panel initialization failures
Hi, On Thu, Jul 16, 2020 at 04:32:09PM +0200, Ondřej Jirman wrote: > Hi Guido, > > On Thu, Jul 16, 2020 at 04:08:43PM +0200, Guido Günther wrote: > > Hi Ondrej, > > On Thu, Jul 16, 2020 at 02:37:51PM +0200, Ondrej Jirman wrote: > > > When extending the driver for xbd599 panel support I tried to do minimal > > > changes and keep the existing initialization timing. > > > > > > It turned out that it's not good enough and the existing init sequence > > > is too aggressive and doesn't follow the specification. On PinePhone > > > panel is being powered down/up during suspend/resume and with current > > > timings this frequently leads to corrupted display. > > > > Given the amount of ST7703 look alikes i don't think you can go by the > > datasheet and hope not to break other panels. The current sleeps cater > > for the rocktech panel (which suffered from similar issues you describe > > when we took other parameters) so you need to make those panel specific. > > It should work on rocktech too. The patch mostly increases/reorders the delays > slightly, to match the controller documentation. I don't see a reason to > complicate the driver with per panel special delays, unless these patches > don't > work on your panel. That's why i brought it up. It breaks the rocktech panel on blank/unblank loops where it just stays blank and then starts hitting DSI command timeouts. Cheers, -- Guido > > The init sequence is still suboptimal, and doesn't follow the kernel docs > completely, even after these patches. Controller spec also talks about adding > some delay before enabling the backlight to avoid visual glitches. > > Which is what enable callback is documented to be for. Currently part of the > initialization that belongs to prepare callback is also done in enable > callback. > > I see the glitch (small vertical shift of the image on powerup), but > personally > don't care much to introduce even more delays to the driver, just for the > cosmetic issue. > > regards, > o. > > > Cheers, > > -- Guido > > > > > > > > This patch series fixes the problems. > > > > > > The issue was reported by Samuel Holland. > > > > > > Relevant screenshots from the datasheet: > > > > > > Power on timing: https://megous.com/dl/tmp/35b72e674ce0ca27.png > > > Power off timing: https://megous.com/dl/tmp/dea195517106ff17.png > > > More optimal reset on poweron: > > > https://megous.com/dl/tmp/a9e5caf14e1b0dc6.png > > > Less optimal reset on poweron: > > > https://megous.com/dl/tmp/246761039283c4cf.png > > > Datasheet: https://megous.com/dl/tmp/ST7703_DS_v01_20160128.pdf > > > > > > Please take a look. > > > > > > thank you and regards, > > > Ondrej Jirman > > > > > > Ondrej Jirman (2): > > > drm/panel: st7703: Make the sleep exit timing match the spec > > > drm/panel: st7703: Fix the power up sequence of the panel > > > > > > drivers/gpu/drm/panel/panel-sitronix-st7703.c | 29 ++- > > > 1 file changed, 15 insertions(+), 14 deletions(-) > > > > > > -- > > > 2.27.0 > > > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/mxsfb: Make supported modifiers explicit
Hi,
On Mon, Mar 23, 2020 at 04:51:05PM +0100, Lucas Stach wrote:
> Am Montag, den 23.03.2020, 15:52 +0100 schrieb Guido Günther:
> > In contrast to other display controllers on imx like DCSS and ipuv3
> > lcdif/mxsfb does not support detiling e.g. vivante tiled layouts.
> > Since mesa might assume otherwise make it explicit that only
> > DRM_FORMAT_MOD_LINEAR is supported.
> >
> > Signed-off-by: Guido Günther
>
> Reviewed-by: Lucas Stach
Can i do anything to get this applied?
Cheers,
-- Guido
>
> > ---
> > drivers/gpu/drm/mxsfb/mxsfb_drv.c | 9 +++--
> > 1 file changed, 7 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> > b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> > index 762379530928..fc71e7a7a02e 100644
> > --- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> > +++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> > @@ -73,6 +73,11 @@ static const uint32_t mxsfb_formats[] = {
> > DRM_FORMAT_RGB565
> > };
> >
> > +static const uint64_t mxsfb_modifiers[] = {
> > + DRM_FORMAT_MOD_LINEAR,
> > + DRM_FORMAT_MOD_INVALID
> > +};
> > +
> > static struct mxsfb_drm_private *
> > drm_pipe_to_mxsfb_drm_private(struct drm_simple_display_pipe *pipe)
> > {
> > @@ -334,8 +339,8 @@ static int mxsfb_load(struct drm_device *drm, unsigned
> > long flags)
> > }
> >
> > ret = drm_simple_display_pipe_init(drm, >pipe, _funcs,
> > - mxsfb_formats, ARRAY_SIZE(mxsfb_formats), NULL,
> > - mxsfb->connector);
> > + mxsfb_formats, ARRAY_SIZE(mxsfb_formats),
> > + mxsfb_modifiers, mxsfb->connector);
> > if (ret < 0) {
> > dev_err(drm->dev, "Cannot setup simple display pipe\n");
> > goto err_vblank;
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] dt-binding: display: Allow a single port node on rocktech,jh057n00900
Hi, On Fri, Jul 03, 2020 at 01:47:17PM +0200, Ondrej Jirman wrote: > The display has one port. Allow it in the binding. > > Signed-off-by: Ondrej Jirman > --- > .../devicetree/bindings/display/panel/rocktech,jh057n00900.yaml | 1 + > 1 file changed, 1 insertion(+) > > diff --git > a/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml > b/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml > index a6985cd947fb..d5733ef30954 100644 > --- > a/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml > +++ > b/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml > @@ -24,6 +24,7 @@ properties: > # Xingbangda XBD599 5.99" 720x1440 TFT LCD panel >- xingbangda,xbd599 > > + port: true >reg: > maxItems: 1 > description: DSI virtual channel Reviewed-by: Guido Günther -- Guido > -- > 2.27.0 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] dt-bindings: display: Fix example in nwl-dsi.yaml
Hi,
On Fri, Jul 03, 2020 at 01:47:16PM +0200, Ondrej Jirman wrote:
> The example is now validated against rocktech,jh057n00900 schema
> that was ported to yaml, and didn't validate with:
>
> - '#address-cells', '#size-cells', 'port@0' do not match any of
> the regexes: 'pinctrl-[0-9]+'
> - 'vcc-supply' is a required property
> - 'iovcc-supply' is a required property
> - 'reset-gpios' is a required property
>
> Fix it.
>
> Signed-off-by: Ondrej Jirman
> ---
> .../devicetree/bindings/display/bridge/nwl-dsi.yaml | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
> b/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
> index 8aff2d68fc33..2c4c34e3bc29 100644
> --- a/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
> +++ b/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
> @@ -165,6 +165,7 @@ examples:
> - |
>
> #include
> + #include
> #include
> #include
>
> @@ -191,12 +192,12 @@ examples:
>phy-names = "dphy";
>
>panel@0 {
> - #address-cells = <1>;
> - #size-cells = <0>;
>compatible = "rocktech,jh057n00900";
>reg = <0>;
> - port@0 {
> - reg = <0>;
> + vcc-supply = <_2v8_p>;
> + iovcc-supply = <_1v8_p>;
> + reset-gpios = < 13 GPIO_ACTIVE_LOW>;
> + port {
> panel_in: endpoint {
> remote-endpoint = <_dsi_out>;
> };
Reviewed-by: Guido Günther
-- Guido
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 2/4] drm/imx: Add initial support for DCSS on iMX8MQ
Hi, On Fri, Jul 17, 2020 at 09:48:49PM +0200, Sam Ravnborg wrote: > Hi Laurentiu. > > On Fri, Jul 17, 2020 at 05:41:27PM +0300, Laurentiu Palcu wrote: > > From: Laurentiu Palcu > > > > This adds initial support for iMX8MQ's Display Controller Subsystem (DCSS). > > Some of its capabilities include: > > * 4K@60fps; > > * HDR10; > > * one graphics and 2 video pipelines; > > * on-the-fly decompression of compressed video and graphics; > > > > The reference manual can be found here: > > https://www.nxp.com/webapp/Download?colCode=IMX8MDQLQRM > > > > The current patch adds only basic functionality: one primary plane for > > graphics, linear, tiled and super-tiled buffers support (no graphics > > decompression yet), no HDR10 and no video planes. > > > > Video planes support and HDR10 will be added in subsequent patches once > > per-plane de-gamma/CSC/gamma support is in. > > > > Signed-off-by: Laurentiu Palcu > > Reviewed-by: Lucas Stach > > --- > > > return drm_bridge_attach(encoder, bridge, NULL, 0); > > > The above code-snippet tells that the display-driver rely on the bridge > to create the connector. > Could this by any chance be updated to the new way where the display > driver creates the connector - and thus passing DRM_BRIDGE_ATTACH_NO_CONNECTOR > as the flags argument? > > What bridges would be relevant? > To check that the reelvant bridges are already ported. I think that's mostly NWL atm since MHDP isn't mainline yet. Can you recommend a bridge driver to look at that does this right? Cheers, -- Guido ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/2] Fix st7703 panel initialization failures
Hi Ondrej, On Thu, Jul 16, 2020 at 02:37:51PM +0200, Ondrej Jirman wrote: > When extending the driver for xbd599 panel support I tried to do minimal > changes and keep the existing initialization timing. > > It turned out that it's not good enough and the existing init sequence > is too aggressive and doesn't follow the specification. On PinePhone > panel is being powered down/up during suspend/resume and with current > timings this frequently leads to corrupted display. Given the amount of ST7703 look alikes i don't think you can go by the datasheet and hope not to break other panels. The current sleeps cater for the rocktech panel (which suffered from similar issues you describe when we took other parameters) so you need to make those panel specific. Cheers, -- Guido > > This patch series fixes the problems. > > The issue was reported by Samuel Holland. > > Relevant screenshots from the datasheet: > > Power on timing: https://megous.com/dl/tmp/35b72e674ce0ca27.png > Power off timing: https://megous.com/dl/tmp/dea195517106ff17.png > More optimal reset on poweron: > https://megous.com/dl/tmp/a9e5caf14e1b0dc6.png > Less optimal reset on poweron: > https://megous.com/dl/tmp/246761039283c4cf.png > Datasheet: https://megous.com/dl/tmp/ST7703_DS_v01_20160128.pdf > > Please take a look. > > thank you and regards, > Ondrej Jirman > > Ondrej Jirman (2): > drm/panel: st7703: Make the sleep exit timing match the spec > drm/panel: st7703: Fix the power up sequence of the panel > > drivers/gpu/drm/panel/panel-sitronix-st7703.c | 29 ++- > 1 file changed, 15 insertions(+), 14 deletions(-) > > -- > 2.27.0 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] MAINTAINERS: Update entry for st7703 driver after the rename
Hi Ondrej, On Wed, Jul 01, 2020 at 08:46:40PM +0200, Ondrej Jirman wrote: > The driver was renamed, change the path in the MAINTAINERS file. > > Signed-off-by: Ondrej Jirman > --- > MAINTAINERS | 7 --- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 5f186a661a9b..f5183eae08df 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -5487,12 +5487,13 @@ S:Maintained > F: Documentation/devicetree/bindings/display/panel/raydium,rm67191.yaml > F: drivers/gpu/drm/panel/panel-raydium-rm67191.c > > -DRM DRIVER FOR ROCKTECH JH057N00900 PANELS > +DRM DRIVER FOR SITRONIX ST7703 PANELS > M: Guido Günther > R: Purism Kernel Team > +R: Ondrej Jirman > S: Maintained > -F: Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.txt > -F: drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c > +F: > Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml > +F: drivers/gpu/drm/panel/panel-sitronix-st7703.c Reviewed-by: Guido Günther Thanks, -- Guido > > DRM DRIVER FOR SAVAGE VIDEO CARDS > S: Orphan / Obsolete > -- > 2.27.0 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 10/13] drm/panel: st7703: Enter sleep after display off
Hi,
On Wed, Jul 01, 2020 at 12:31:23PM +0200, Ondrej Jirman wrote:
> The datasheet suggests to issue sleep in after display off
> as a part of the panel's shutdown sequence.
Out of curiosity: which exact datasheet did you use?
Reviewed-by: Guido Günther
>
> Signed-off-by: Ondrej Jirman
> Reviewed-by: Linus Walleij
> ---
> drivers/gpu/drm/panel/panel-sitronix-st7703.c | 13 -
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> index 5cd5503f894f..0c4167994d01 100644
> --- a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> +++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> @@ -395,8 +395,19 @@ static int st7703_disable(struct drm_panel *panel)
> {
> struct st7703 *ctx = panel_to_st7703(panel);
> struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
> + int ret;
> +
> + ret = mipi_dsi_dcs_set_display_off(dsi);
> + if (ret < 0)
> + DRM_DEV_ERROR(ctx->dev,
> + "Failed to turn off the display: %d\n", ret);
>
> - return mipi_dsi_dcs_set_display_off(dsi);
> + ret = mipi_dsi_dcs_enter_sleep_mode(dsi);
> + if (ret < 0)
> + DRM_DEV_ERROR(ctx->dev,
> + "Failed to enter sleep mode: %d\n", ret);
> +
> + return 0;
> }
>
> static int st7703_unprepare(struct drm_panel *panel)
> --
> 2.27.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 11/13] drm/panel: st7703: Assert reset prior to powering down the regulators
Hi, On Wed, Jul 01, 2020 at 12:31:24PM +0200, Ondrej Jirman wrote: > The reset pin is inverted, so if we don't assert reset, the actual gpio > will be high and may keep driving the IO port of the panel. Reviewed-by: Guido Günther > > Signed-off-by: Ondrej Jirman > Reviewed-by: Linus Walleij > --- > drivers/gpu/drm/panel/panel-sitronix-st7703.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c > b/drivers/gpu/drm/panel/panel-sitronix-st7703.c > index 0c4167994d01..e303b7b1a215 100644 > --- a/drivers/gpu/drm/panel/panel-sitronix-st7703.c > +++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c > @@ -417,6 +417,7 @@ static int st7703_unprepare(struct drm_panel *panel) > if (!ctx->prepared) > return 0; > > + gpiod_set_value_cansleep(ctx->reset_gpio, 1); > regulator_disable(ctx->iovcc); > regulator_disable(ctx->vcc); > ctx->prepared = false; > -- > 2.27.0 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 09/13] drm/panel: st7703: Add support for Xingbangda XBD599
Hi,
On Wed, Jul 01, 2020 at 12:31:22PM +0200, Ondrej Jirman wrote:
> Xingbangda XBD599 is a 5.99" 720x1440 MIPI-DSI LCD panel used in
> PinePhone. Add support for it.
Reviewed-by: Guido Günther
>
> Signed-off-by: Icenowy Zheng
> Signed-off-by: Ondrej Jirman
> Reviewed-by: Linus Walleij
> ---
> drivers/gpu/drm/panel/panel-sitronix-st7703.c | 200 +-
> 1 file changed, 198 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> index cdbf7dfb4dd4..5cd5503f894f 100644
> --- a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> +++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> @@ -39,10 +39,11 @@
> #define ST7703_CMD_SETEXTC0xB9
> #define ST7703_CMD_SETMIPI0xBA
> #define ST7703_CMD_SETVDC 0xBC
> -#define ST7703_CMD_UNKNOWN0 0xBF
> +#define ST7703_CMD_UNKNOWN_BF 0xBF
> #define ST7703_CMD_SETSCR 0xC0
> #define ST7703_CMD_SETPOWER 0xC1
> #define ST7703_CMD_SETPANEL 0xCC
> +#define ST7703_CMD_UNKNOWN_C6 0xC6
> #define ST7703_CMD_SETGAMMA 0xE0
> #define ST7703_CMD_SETEQ 0xE3
> #define ST7703_CMD_SETGIP10xE9
> @@ -109,7 +110,7 @@ static int jh057n_init_sequence(struct st7703 *ctx)
> msleep(20);
>
> dsi_generic_write_seq(dsi, ST7703_CMD_SETVCOM, 0x3F, 0x3F);
> - dsi_generic_write_seq(dsi, ST7703_CMD_UNKNOWN0, 0x02, 0x11, 0x00);
> + dsi_generic_write_seq(dsi, ST7703_CMD_UNKNOWN_BF, 0x02, 0x11, 0x00);
> dsi_generic_write_seq(dsi, ST7703_CMD_SETGIP1,
> 0x82, 0x10, 0x06, 0x05, 0x9E, 0x0A, 0xA5, 0x12,
> 0x31, 0x23, 0x37, 0x83, 0x04, 0xBC, 0x27, 0x38,
> @@ -163,6 +164,200 @@ struct st7703_panel_desc jh057n00900_panel_desc = {
> .init_sequence = jh057n_init_sequence,
> };
>
> +#define dsi_dcs_write_seq(dsi, cmd, seq...) do { \
> + static const u8 d[] = { seq }; \
> + int ret;\
> + ret = mipi_dsi_dcs_write(dsi, cmd, d, ARRAY_SIZE(d)); \
> + if (ret < 0)\
> + return ret; \
> + } while (0)
> +
> +
> +static int xbd599_init_sequence(struct st7703 *ctx)
> +{
> + struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
> +
> + /*
> + * Init sequence was supplied by the panel vendor.
> + */
> +
> + /* Magic sequence to unlock user commands below. */
> + dsi_dcs_write_seq(dsi, ST7703_CMD_SETEXTC, 0xF1, 0x12, 0x83);
> +
> + dsi_dcs_write_seq(dsi, ST7703_CMD_SETMIPI,
> + 0x33, /* VC_main = 0, Lane_Number = 3 (4 lanes) */
> + 0x81, /* DSI_LDO_SEL = 1.7V, RTERM = 90 Ohm */
> + 0x05, /* IHSRX = x6 (Low High Speed driving ability)
> */
> + 0xF9, /* TX_CLK_SEL = fDSICLK/16 */
> + 0x0E, /* HFP_OSC (min. HFP number in DSI mode) */
> + 0x0E, /* HBP_OSC (min. HBP number in DSI mode) */
> + /* The rest is undocumented in ST7703 datasheet */
> + 0x20, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> + 0x44, 0x25, 0x00, 0x91, 0x0a, 0x00, 0x00, 0x02,
> + 0x4F, 0x11, 0x00, 0x00, 0x37);
> +
> + dsi_dcs_write_seq(dsi, ST7703_CMD_SETPOWER_EXT,
> + 0x25, /* PCCS = 2, ECP_DC_DIV = 1/4 HSYNC */
> + 0x22, /* DT = 15ms XDK_ECP = x2 */
> + 0x20, /* PFM_DC_DIV = /1 */
> + 0x03 /* ECP_SYNC_EN = 1, VGX_SYNC_EN = 1 */);
> +
> + /* RGB I/F porch timing */
> + dsi_dcs_write_seq(dsi, ST7703_CMD_SETRGBIF,
> + 0x10, /* VBP_RGB_GEN */
> + 0x10, /* VFP_RGB_GEN */
> + 0x05, /* DE_BP_RGB_GEN */
> + 0x05, /* DE_FP_RGB_GEN */
> + /* The rest is undocumented in ST7703 datasheet */
> + 0x03, 0xFF,
> + 0x00, 0x00,
> + 0x00, 0x00);
> +
> + /* Source driving settings. */
> + dsi_dcs_write_seq(dsi, ST7703_CMD_SETSCR,
> + 0x73, /* N_POPON */
> + 0x73, /* N_NOPON */
> + 0x50, /* I_POPON */
> + 0x50, /* I_NOPON */
> + 0x00, /* SCR[31,24] */
> + 0xC0, /* SCR[23,16] */
> + 0x08, /* SCR[15,8] */
Re: [PATCH v6 08/13] drm/panel: st7703: Move generic part of init sequence to enable callback
Hi,
On Wed, Jul 01, 2020 at 12:31:21PM +0200, Ondrej Jirman wrote:
> Calling sleep out and display on is a controller specific part
> of the initialization process. Move it out of the panel specific
> initialization function to the enable callback.
Reviewed-by: Guido Günther
>
> Signed-off-by: Ondrej Jirman
> Reviewed-by: Linus Walleij
> ---
> drivers/gpu/drm/panel/panel-sitronix-st7703.c | 33 ++-
> 1 file changed, 18 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> index d03aab10cfef..cdbf7dfb4dd4 100644
> --- a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> +++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> @@ -84,8 +84,6 @@ static inline struct st7703 *panel_to_st7703(struct
> drm_panel *panel)
> static int jh057n_init_sequence(struct st7703 *ctx)
> {
> struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
> - struct device *dev = ctx->dev;
> - int ret;
>
> /*
>* Init sequence was supplied by the panel vendor. Most of the commands
> @@ -136,20 +134,7 @@ static int jh057n_init_sequence(struct st7703 *ctx)
> 0x18, 0x00, 0x09, 0x0E, 0x29, 0x2D, 0x3C, 0x41,
> 0x37, 0x07, 0x0B, 0x0D, 0x10, 0x11, 0x0F, 0x10,
> 0x11, 0x18);
> - msleep(20);
> -
> - ret = mipi_dsi_dcs_exit_sleep_mode(dsi);
> - if (ret < 0) {
> - DRM_DEV_ERROR(dev, "Failed to exit sleep mode: %d\n", ret);
> - return ret;
> - }
> - /* Panel is operational 120 msec after reset */
> - msleep(60);
> - ret = mipi_dsi_dcs_set_display_on(dsi);
> - if (ret)
> - return ret;
>
> - DRM_DEV_DEBUG_DRIVER(dev, "Panel init sequence done\n");
> return 0;
> }
>
> @@ -181,6 +166,7 @@ struct st7703_panel_desc jh057n00900_panel_desc = {
> static int st7703_enable(struct drm_panel *panel)
> {
> struct st7703 *ctx = panel_to_st7703(panel);
> + struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
> int ret;
>
> ret = ctx->desc->init_sequence(ctx);
> @@ -190,6 +176,23 @@ static int st7703_enable(struct drm_panel *panel)
> return ret;
> }
>
> + msleep(20);
> +
> + ret = mipi_dsi_dcs_exit_sleep_mode(dsi);
> + if (ret < 0) {
> + DRM_DEV_ERROR(ctx->dev, "Failed to exit sleep mode: %d\n", ret);
> + return ret;
> + }
> +
> + /* Panel is operational 120 msec after reset */
> + msleep(60);
> +
> + ret = mipi_dsi_dcs_set_display_on(dsi);
> + if (ret)
> + return ret;
> +
> + DRM_DEV_DEBUG_DRIVER(ctx->dev, "Panel init sequence done\n");
> +
> return 0;
> }
>
> --
> 2.27.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 07/13] drm/panel: st7703: Move code specific to jh057n closer together
Hi,
On Wed, Jul 01, 2020 at 12:31:20PM +0200, Ondrej Jirman wrote:
> It's better than having it spread around the driver.
Reviewed-by: Guido Günther
>
> Signed-off-by: Ondrej Jirman
> Reviewed-by: Linus Walleij
> ---
> drivers/gpu/drm/panel/panel-sitronix-st7703.c | 50 +--
> 1 file changed, 25 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> index 08cbc316266c..d03aab10cfef 100644
> --- a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> +++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> @@ -153,6 +153,31 @@ static int jh057n_init_sequence(struct st7703 *ctx)
> return 0;
> }
>
> +static const struct drm_display_mode jh057n00900_mode = {
> + .hdisplay= 720,
> + .hsync_start = 720 + 90,
> + .hsync_end = 720 + 90 + 20,
> + .htotal = 720 + 90 + 20 + 20,
> + .vdisplay= 1440,
> + .vsync_start = 1440 + 20,
> + .vsync_end = 1440 + 20 + 4,
> + .vtotal = 1440 + 20 + 4 + 12,
> + .vrefresh= 60,
> + .clock = 75276,
> + .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
> + .width_mm= 65,
> + .height_mm = 130,
> +};
> +
> +struct st7703_panel_desc jh057n00900_panel_desc = {
> + .mode = _mode,
> + .lanes = 4,
> + .mode_flags = MIPI_DSI_MODE_VIDEO |
> + MIPI_DSI_MODE_VIDEO_BURST | MIPI_DSI_MODE_VIDEO_SYNC_PULSE,
> + .format = MIPI_DSI_FMT_RGB888,
> + .init_sequence = jh057n_init_sequence,
> +};
> +
> static int st7703_enable(struct drm_panel *panel)
> {
> struct st7703 *ctx = panel_to_st7703(panel);
> @@ -226,31 +251,6 @@ static int st7703_prepare(struct drm_panel *panel)
> return ret;
> }
>
> -static const struct drm_display_mode jh057n00900_mode = {
> - .hdisplay= 720,
> - .hsync_start = 720 + 90,
> - .hsync_end = 720 + 90 + 20,
> - .htotal = 720 + 90 + 20 + 20,
> - .vdisplay= 1440,
> - .vsync_start = 1440 + 20,
> - .vsync_end = 1440 + 20 + 4,
> - .vtotal = 1440 + 20 + 4 + 12,
> - .vrefresh= 60,
> - .clock = 75276,
> - .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
> - .width_mm= 65,
> - .height_mm = 130,
> -};
> -
> -struct st7703_panel_desc jh057n00900_panel_desc = {
> - .mode = _mode,
> - .lanes = 4,
> - .mode_flags = MIPI_DSI_MODE_VIDEO |
> - MIPI_DSI_MODE_VIDEO_BURST | MIPI_DSI_MODE_VIDEO_SYNC_PULSE,
> - .format = MIPI_DSI_FMT_RGB888,
> - .init_sequence = jh057n_init_sequence,
> -};
> -
> static int st7703_get_modes(struct drm_panel *panel,
> struct drm_connector *connector)
> {
> --
> 2.27.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 06/13] drm/panel: st7703: Prepare for supporting multiple panels
Hi,
On Wed, Jul 01, 2020 at 12:31:19PM +0200, Ondrej Jirman wrote:
> Parametrize the driver so that it can support more panels based
> on st7703 controller.
Reviewed-by: Guido Günther
>
> Signed-off-by: Ondrej Jirman
> Reviewed-by: Linus Walleij
> ---
> drivers/gpu/drm/panel/panel-sitronix-st7703.c | 43 +--
> 1 file changed, 31 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> index 511af659f273..08cbc316266c 100644
> --- a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> +++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> @@ -13,6 +13,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include
> @@ -56,6 +57,15 @@ struct st7703 {
> bool prepared;
>
> struct dentry *debugfs;
> + const struct st7703_panel_desc *desc;
> +};
> +
> +struct st7703_panel_desc {
> + const struct drm_display_mode *mode;
> + unsigned int lanes;
> + unsigned long mode_flags;
> + enum mipi_dsi_pixel_format format;
> + int (*init_sequence)(struct st7703 *ctx);
> };
>
> static inline struct st7703 *panel_to_st7703(struct drm_panel *panel)
> @@ -148,7 +158,7 @@ static int st7703_enable(struct drm_panel *panel)
> struct st7703 *ctx = panel_to_st7703(panel);
> int ret;
>
> - ret = jh057n_init_sequence(ctx);
> + ret = ctx->desc->init_sequence(ctx);
> if (ret < 0) {
> DRM_DEV_ERROR(ctx->dev, "Panel init sequence failed: %d\n",
> ret);
> @@ -216,7 +226,7 @@ static int st7703_prepare(struct drm_panel *panel)
> return ret;
> }
>
> -static const struct drm_display_mode default_mode = {
> +static const struct drm_display_mode jh057n00900_mode = {
> .hdisplay= 720,
> .hsync_start = 720 + 90,
> .hsync_end = 720 + 90 + 20,
> @@ -232,17 +242,26 @@ static const struct drm_display_mode default_mode = {
> .height_mm = 130,
> };
>
> +struct st7703_panel_desc jh057n00900_panel_desc = {
> + .mode = _mode,
> + .lanes = 4,
> + .mode_flags = MIPI_DSI_MODE_VIDEO |
> + MIPI_DSI_MODE_VIDEO_BURST | MIPI_DSI_MODE_VIDEO_SYNC_PULSE,
> + .format = MIPI_DSI_FMT_RGB888,
> + .init_sequence = jh057n_init_sequence,
> +};
> +
> static int st7703_get_modes(struct drm_panel *panel,
> struct drm_connector *connector)
> {
> struct st7703 *ctx = panel_to_st7703(panel);
> struct drm_display_mode *mode;
>
> - mode = drm_mode_duplicate(connector->dev, _mode);
> + mode = drm_mode_duplicate(connector->dev, ctx->desc->mode);
> if (!mode) {
> DRM_DEV_ERROR(ctx->dev, "Failed to add mode %ux%u@%u\n",
> - default_mode.hdisplay, default_mode.vdisplay,
> - default_mode.vrefresh);
> + ctx->desc->mode->hdisplay,
> ctx->desc->mode->vdisplay,
> + ctx->desc->mode->vrefresh);
> return -ENOMEM;
> }
>
> @@ -317,11 +336,11 @@ static int st7703_probe(struct mipi_dsi_device *dsi)
> mipi_dsi_set_drvdata(dsi, ctx);
>
> ctx->dev = dev;
> + ctx->desc = of_device_get_match_data(dev);
>
> - dsi->lanes = 4;
> - dsi->format = MIPI_DSI_FMT_RGB888;
> - dsi->mode_flags = MIPI_DSI_MODE_VIDEO |
> - MIPI_DSI_MODE_VIDEO_BURST | MIPI_DSI_MODE_VIDEO_SYNC_PULSE;
> + dsi->mode_flags = ctx->desc->mode_flags;
> + dsi->format = ctx->desc->format;
> + dsi->lanes = ctx->desc->lanes;
>
> ctx->vcc = devm_regulator_get(dev, "vcc");
> if (IS_ERR(ctx->vcc)) {
> @@ -361,8 +380,8 @@ static int st7703_probe(struct mipi_dsi_device *dsi)
> }
>
> DRM_DEV_INFO(dev, "%ux%u@%u %ubpp dsi %udl - ready\n",
> - default_mode.hdisplay, default_mode.vdisplay,
> - default_mode.vrefresh,
> + ctx->desc->mode->hdisplay, ctx->desc->mode->vdisplay,
> + ctx->desc->mode->vrefresh,
>mipi_dsi_pixel_format_to_bpp(dsi->format), dsi->lanes);
>
> st7703_debugfs_init(ctx);
> @@ -405,7 +424,7 @@ static int st7703_remove(struct mipi_dsi_device *dsi)
> }
>
> static const struct of_device_id st7703_of_match[] = {
> - { .compatible = "rocktech,jh057n00900" },
> + { .compatible = "rocktech,jh057n00900", .data = _panel_desc
> },
> { /* sentinel */ }
> };
> MODULE_DEVICE_TABLE(of, st7703_of_match);
> --
> 2.27.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 05/13] drm/panel: st7703: Rename functions from jh057n prefix to st7703
Hi,
On Wed, Jul 01, 2020 at 12:31:18PM +0200, Ondrej Jirman wrote:
> This is done so that code that's not specific to a particular
> jh057n panel is named after the controller. Functions specific
> to the panel are kept named after the panel.
Reviewed-by: Guido Günther
>
> Signed-off-by: Ondrej Jirman
> Reviewed-by: Linus Walleij
> ---
> drivers/gpu/drm/panel/panel-sitronix-st7703.c | 90 ++-
> 1 file changed, 46 insertions(+), 44 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> index 38ff742bc120..511af659f273 100644
> --- a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> +++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> @@ -1,6 +1,8 @@
> // SPDX-License-Identifier: GPL-2.0
> /*
> - * Rockteck jh057n00900 5.5" MIPI-DSI panel driver
> + * Driver for panels based on Sitronix ST7703 controller, souch as:
> + *
> + * - Rocktech jh057n00900 5.5" MIPI-DSI panel
> *
> * Copyright (C) Purism SPC 2019
> */
> @@ -21,7 +23,7 @@
> #include
> #include
>
> -#define DRV_NAME "panel-rocktech-jh057n00900"
> +#define DRV_NAME "panel-sitronix-st7703"
>
> /* Manufacturer specific Commands send via DSI */
> #define ST7703_CMD_ALL_PIXEL_OFF 0x22
> @@ -45,7 +47,7 @@
> #define ST7703_CMD_SETGIP10xE9
> #define ST7703_CMD_SETGIP20xEA
>
> -struct jh057n {
> +struct st7703 {
> struct device *dev;
> struct drm_panel panel;
> struct gpio_desc *reset_gpio;
> @@ -56,9 +58,9 @@ struct jh057n {
> struct dentry *debugfs;
> };
>
> -static inline struct jh057n *panel_to_jh057n(struct drm_panel *panel)
> +static inline struct st7703 *panel_to_st7703(struct drm_panel *panel)
> {
> - return container_of(panel, struct jh057n, panel);
> + return container_of(panel, struct st7703, panel);
> }
>
> #define dsi_generic_write_seq(dsi, seq...) do {
> \
> @@ -69,7 +71,7 @@ static inline struct jh057n *panel_to_jh057n(struct
> drm_panel *panel)
> return ret; \
> } while (0)
>
> -static int jh057n_init_sequence(struct jh057n *ctx)
> +static int jh057n_init_sequence(struct st7703 *ctx)
> {
> struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
> struct device *dev = ctx->dev;
> @@ -141,9 +143,9 @@ static int jh057n_init_sequence(struct jh057n *ctx)
> return 0;
> }
>
> -static int jh057n_enable(struct drm_panel *panel)
> +static int st7703_enable(struct drm_panel *panel)
> {
> - struct jh057n *ctx = panel_to_jh057n(panel);
> + struct st7703 *ctx = panel_to_st7703(panel);
> int ret;
>
> ret = jh057n_init_sequence(ctx);
> @@ -156,17 +158,17 @@ static int jh057n_enable(struct drm_panel *panel)
> return 0;
> }
>
> -static int jh057n_disable(struct drm_panel *panel)
> +static int st7703_disable(struct drm_panel *panel)
> {
> - struct jh057n *ctx = panel_to_jh057n(panel);
> + struct st7703 *ctx = panel_to_st7703(panel);
> struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
>
> return mipi_dsi_dcs_set_display_off(dsi);
> }
>
> -static int jh057n_unprepare(struct drm_panel *panel)
> +static int st7703_unprepare(struct drm_panel *panel)
> {
> - struct jh057n *ctx = panel_to_jh057n(panel);
> + struct st7703 *ctx = panel_to_st7703(panel);
>
> if (!ctx->prepared)
> return 0;
> @@ -178,9 +180,9 @@ static int jh057n_unprepare(struct drm_panel *panel)
> return 0;
> }
>
> -static int jh057n_prepare(struct drm_panel *panel)
> +static int st7703_prepare(struct drm_panel *panel)
> {
> - struct jh057n *ctx = panel_to_jh057n(panel);
> + struct st7703 *ctx = panel_to_st7703(panel);
> int ret;
>
> if (ctx->prepared)
> @@ -230,10 +232,10 @@ static const struct drm_display_mode default_mode = {
> .height_mm = 130,
> };
>
> -static int jh057n_get_modes(struct drm_panel *panel,
> +static int st7703_get_modes(struct drm_panel *panel,
> struct drm_connector *connector)
> {
> - struct jh057n *ctx = panel_to_jh057n(panel);
> + struct st7703 *ctx = panel_to_st7703(panel);
> struct drm_display_mode *mode;
>
> mode = drm_mode_duplicate(connector->dev, _mode);
> @@ -254,17 +256,17 @@ static int jh057n_get_modes(struct drm_panel *panel,
> return 1;
> }
>
> -static const struct drm_panel_funcs jh057n_drm_funcs = {
> - .disable = jh057n_disable,
> - .u
Re: [PATCH v6 04/13] drm/panel: rocktech-jh057n00900: Rename the driver to st7703
Hi,
On Wed, Jul 01, 2020 at 12:31:17PM +0200, Ondrej Jirman wrote:
> This rename is done so that the driver matches the name of the
> display controller and in preparation for adding support for more
> panels to the driver.
>
> This is just a basic file rename, with no code changes.
Reviewed-by: Guido Günther
>
> Signed-off-by: Ondrej Jirman
> Reviewed-by: Linus Walleij
> ---
> drivers/gpu/drm/panel/Kconfig | 26 +--
> drivers/gpu/drm/panel/Makefile| 2 +-
> ...-jh057n00900.c => panel-sitronix-st7703.c} | 0
> 3 files changed, 14 insertions(+), 14 deletions(-)
> rename drivers/gpu/drm/panel/{panel-rocktech-jh057n00900.c =>
> panel-sitronix-st7703.c} (100%)
>
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index 39055c1f0e2f..de2f2a452be5 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -283,19 +283,6 @@ config DRM_PANEL_RAYDIUM_RM68200
> Say Y here if you want to enable support for Raydium RM68200
> 720x1280 DSI video mode panel.
>
> -config DRM_PANEL_ROCKTECH_JH057N00900
> - tristate "Rocktech JH057N00900 MIPI touchscreen 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 Rocktech JH057N00900
> - MIPI DSI panel as e.g. used in the Librem 5 devkit. It has a
> - resolution of 720x1440 pixels, a built in backlight and touch
> - controller.
> - Touch input support is provided by the goodix driver and needs to be
> - selected separately.
> -
> config DRM_PANEL_RONBO_RB070D30
> tristate "Ronbo Electronics RB070D30 panel"
> depends on OF
> @@ -395,6 +382,19 @@ config DRM_PANEL_SITRONIX_ST7701
> ST7701 controller for 480X864 LCD panels with MIPI/RGB/SPI
> system interfaces.
>
> +config DRM_PANEL_SITRONIX_ST7703
> + tristate "Sitronix ST7703 based MIPI touchscreen panels"
> + depends on OF
> + depends on DRM_MIPI_DSI
> + depends on BACKLIGHT_CLASS_DEVICE
> + help
> + Say Y here if you want to enable support for Sitronix ST7703 based
> + panels, souch as Rocktech JH057N00900 MIPI DSI panel as e.g. used in
> + the Librem 5 devkit. It has a resolution of 720x1440 pixels, a built
> + in backlight and touch controller.
> + Touch input support is provided by the goodix driver and needs to be
> + selected separately.
> +
> config DRM_PANEL_SITRONIX_ST7789V
> tristate "Sitronix ST7789V panel"
> depends on OF && SPI
> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> index de74f282c433..e45ceac6286f 100644
> --- a/drivers/gpu/drm/panel/Makefile
> +++ b/drivers/gpu/drm/panel/Makefile
> @@ -27,7 +27,6 @@ obj-$(CONFIG_DRM_PANEL_PANASONIC_VVX10F034N00) +=
> panel-panasonic-vvx10f034n00.o
> obj-$(CONFIG_DRM_PANEL_RASPBERRYPI_TOUCHSCREEN) +=
> panel-raspberrypi-touchscreen.o
> obj-$(CONFIG_DRM_PANEL_RAYDIUM_RM67191) += panel-raydium-rm67191.o
> obj-$(CONFIG_DRM_PANEL_RAYDIUM_RM68200) += panel-raydium-rm68200.o
> -obj-$(CONFIG_DRM_PANEL_ROCKTECH_JH057N00900) += panel-rocktech-jh057n00900.o
> obj-$(CONFIG_DRM_PANEL_RONBO_RB070D30) += panel-ronbo-rb070d30.o
> obj-$(CONFIG_DRM_PANEL_SAMSUNG_LD9040) += panel-samsung-ld9040.o
> obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6D16D0) += panel-samsung-s6d16d0.o
> @@ -41,6 +40,7 @@ obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) +=
> panel-sharp-lq101r1sx01.o
> obj-$(CONFIG_DRM_PANEL_SHARP_LS037V7DW01) += panel-sharp-ls037v7dw01.o
> obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
> obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7701) += panel-sitronix-st7701.o
> +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
> diff --git a/drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c
> b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> similarity index 100%
> rename from drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c
> rename to drivers/gpu/drm/panel/panel-sitronix-st7703.c
> --
> 2.27.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 02/13] dt-bindings: panel: Convert rocktech,jh057n00900 to yaml
Hi Ondrej,
On Wed, Jul 01, 2020 at 12:31:15PM +0200, Ondrej Jirman wrote:
> Convert Rocktech MIPI DSI panel driver from txt to yaml bindings.
>
> Signed-off-by: Ondrej Jirman
> ---
> .../display/panel/rocktech,jh057n00900.txt| 23 ---
> .../display/panel/rocktech,jh057n00900.yaml | 66 +++
> 2 files changed, 66 insertions(+), 23 deletions(-)
> delete mode 100644
> Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.txt
> create mode 100644
> Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml
Thanks for the conversion! Shouldn't we switch to `sitronix-st7703.yaml`
as well in this patch?
Cheers,
-- Guido
>
> diff --git
> a/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.txt
> b/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.txt
> deleted file mode 100644
> index a372c5d84695..
> --- a/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.txt
> +++ /dev/null
> @@ -1,23 +0,0 @@
> -Rocktech jh057n00900 5.5" 720x1440 TFT LCD panel
> -
> -Required properties:
> -- compatible: should be "rocktech,jh057n00900"
> -- reg: DSI virtual channel of the peripheral
> -- reset-gpios: panel reset gpio
> -- backlight: phandle of the backlight device attached to the panel
> -- vcc-supply: phandle of the regulator that provides the vcc supply voltage.
> -- iovcc-supply: phandle of the regulator that provides the iovcc supply
> - voltage.
> -
> -Example:
> -
> - _dsi {
> - panel@0 {
> - compatible = "rocktech,jh057n00900";
> - reg = <0>;
> - backlight = <>;
> - reset-gpios = < 13 GPIO_ACTIVE_LOW>;
> - vcc-supply = <_2v8_p>;
> - iovcc-supply = <_1v8_p>;
> - };
> - };
> diff --git
> a/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml
> b/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml
> new file mode 100644
> index ..928ba42e7f8d
> --- /dev/null
> +++
> b/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml
> @@ -0,0 +1,66 @@
> +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/panel/rocktech,jh057n00900.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Rocktech JH057N00900 5.5" 720x1440 TFT LCD panel
> +
> +maintainers:
> + - Ondrej Jirman
> +
> +description: |
> + Rocktech JH057N00900 is a 720x1440 TFT LCD panel
> + connected using a MIPI-DSI video interface.
> +
> +allOf:
> + - $ref: panel-common.yaml#
> +
> +properties:
> + compatible:
> +const: rocktech,jh057n00900
> +
> + reg:
> +maxItems: 1
> +description: DSI virtual channel
> +
> + vcc-supply:
> +description: Panel power supply
> +
> + iovcc-supply:
> +description: I/O voltage supply
> +
> + reset-gpios:
> +description: GPIO used for the reset pin
> +maxItems: 1
> +
> + backlight:
> +description: Backlight used by the panel
> +$ref: "/schemas/types.yaml#/definitions/phandle"
> +
> +required:
> + - compatible
> + - reg
> + - vcc-supply
> + - iovcc-supply
> + - reset-gpios
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +#include
> +
> +dsi {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + panel@0 {
> +compatible = "rocktech,jh057n00900";
> +reg = <0>;
> +vcc-supply = <_2v8_p>;
> +iovcc-supply = <_1v8_p>;
> +reset-gpios = < 13 GPIO_ACTIVE_LOW>;
> +backlight = <>;
> + };
> +};
> +...
> --
> 2.27.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 00/13] Add support for PinePhone LCD panel
Hi, On Wed, Jul 01, 2020 at 12:31:13PM +0200, Ondrej Jirman wrote: > This patchset adds support for the LCD panel of PinePhone. I gave this a quick spin on the Librem5 devkit so Tested-by: Guido Günther but please also adjust MAINTAINERS so we stay in the loop on driver changes. Cheers, -- Guido > > I've tested this on PinePhone 1.0 and 1.2. > > Please take a look. > > thank you and regards, > Ondrej Jirman > > Changes in v6: > - Fixed spacing in yaml > - Fixed wrong vccio->iovcc supply name in the bindings doc > - I noticed that the original driver uses a delay of 20ms in the init > function to achieve a combined total of 120ms required from post-reset > to display_on. I've added a similar delay to xbd599_init, so that > xbd599 panel also has the right timing. (patch 9) > - v5->v6 diff: https://megous.com/dl/tmp/v5-v6.patch > - Added review/ack tags > - Learned to run dt_binding_check by myself ;) > > Changes in v5: > - rewritten on top of rocktech-jh057n00900 driver > - rocktech-jh057n00900 renamed to st7703 (controller name) > - converted rocktech-jh057n00900 bindings to yaml and extended for xbd599 > > Changes in v4: > - use ->type from the mode instead of hardcoding (Samuel) > - move init_sequence to ->prepare (Samuel) > - move anti-flicker delay to ->enable, explain it (Samuel) > - add enter_sleep after display_off (Samuel) > - drop ->disable (move code to ->unprepare) > - add ID bytes dumping (Linus) > (I can't test it since allwinner DSI driver has a broken >dcs_read function, and I didn't manage to fix it.) > - document magic bytes (Linus) > - assert reset during powerup > - cleanup powerup timings according to the datasheet > > Changes in v3: > - Panel driver renamed to the name of the LCD controller > - Re-organize the driver slightly to more easily support more panels > based on the same controller. > - Add patch to enable the touchscreen to complete the LCD support > on PinePhone. > - Dropped the "DSI fix" patch (the driver seems to work for me without it) > - Improved brightness levels handling: > - PinePhone 1.0 uses default levels generated by the driver > - On PinePhone 1.1 duty cycles < 20% lead to black screen, so > default levels can't be used. Martijn Braam came up with a > list of duty cycle values that lead to perception of linear > brigtness level <-> light intensity on PinePhone 1.1 > - There was some feedback on v2 about this being similar to st7701. > It's only similar in name. Most of the "user commands" are different, > so I opted to keep this in a new driver instead of creating st770x. > > Anyone who likes to check the differences, here are datasheets: > > - https://megous.com/dl/tmp/ST7703_DS_v01_20160128.pdf > - https://megous.com/dl/tmp/ST7701.pdf > > Changes in v2: > - DT Example fix. > - DT Format fix. > - Raised copyright info to 2020. > - Sort panel operation functions. > - Sort inclusion. > > > -- For phone owners: -- > > There's an open question on how to set the backlight brightness values > on post 1.0 revision phone, since lower duty cycles (< 10-20%) lead > to backlight being black. It would be nice if more people can test > the various backlight levels on 1.1 and 1.2 revision with this change > in dts: > >brightness-levels = <0 1000>; >num-interpolated-steps = <1000>; > > and report at what brightness level the backlight turns on. So far it > seems this has a wide range. Lowest useable duty cycle for me is ~7% > on 1.2 and for Martijn ~20% on 1.1. > > Icenowy Zheng (2): > dt-bindings: vendor-prefixes: Add Xingbangda > arm64: dts: sun50i-a64-pinephone: Enable LCD support on PinePhone > > Ondrej Jirman (11): > dt-bindings: panel: Convert rocktech,jh057n00900 to yaml > dt-bindings: panel: Add compatible for Xingbangda XBD599 panel > drm/panel: rocktech-jh057n00900: Rename the driver to st7703 > drm/panel: st7703: Rename functions from jh057n prefix to st7703 > drm/panel: st7703: Prepare for supporting multiple panels > drm/panel: st7703: Move code specific to jh057n closer together > drm/panel: st7703: Move generic part of init sequence to enable > callback > drm/panel: st7703: Add support for Xingbangda XBD599 > drm/panel: st7703: Enter sleep after display off > drm/panel: st7703: Assert reset prior to powering down the regulators > arm64: dts: sun50i-a64-pinephone: Add touchscreen support > > .../display/panel/rocktech,jh057n00900.txt| 23 - > .../display/panel/rocktech,jh057n00900.yaml | 70 ++ > .../devicetree/bindings/vendor-prefixes.yaml | 2 + > .../allwinne
Re: [PATCH 0/5] drm/etnaviv: Ignore MC bit when checking for runtime suspend
Hi, On Tue, Mar 03, 2020 at 12:55:04PM +0100, Lucas Stach wrote: > On Mo, 2020-03-02 at 20:13 +0100, Guido Günther wrote: > > At least GC7000 fails to enter runtime suspend for long periods of time > > since > > the MC becomes busy again even when the FE is idle. The rest of the series > > makes detecting similar issues easier to debug in the future by checking > > all known bits in debugfs and also warning in the EBUSY case. > > Thanks, series applied to etnaviv/next. > > > Tested on GC7000 with a reduced runtime delay of 50ms. Patches are > > against next-20200226. > > I've already wondered if 200ms is too long, 50ms sounds more > reasonable. Do you have any numbers on the power draw on the i.MX8M > with idle GPU, vs. being fully power gated? The difference is at least 250mW. It makes a huge difference over here. We hit https://lore.kernel.org/dri-devel/20200614064601.7872-1-navid.emamdo...@gmail.com/ recently and you notice instantly when that happens when looking at the SoC temperature. Cheers, -- Guido > > Regards, > Lucas > > > Thanks to Lucas Stach for pointing me in the right direction. > > > > Guido Günther (5): > > drm/etnaviv: Fix typo in comment > > drm/etnaviv: Update idle bits > > drm/etnaviv: Consider all kwnown idle bits in debugfs > > drm/etnaviv: Ignore MC when checking runtime suspend idleness > > drm/etnaviv: Warn when GPU doesn't idle fast enough > > > > drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 26 ++ > > drivers/gpu/drm/etnaviv/state_hi.xml.h | 7 +++ > > 2 files changed, 29 insertions(+), 4 deletions(-) > > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 1/6] dt-bindings: display/bridge: Add binding for input mux bridge
Hi Rob, On Thu, May 28, 2020 at 01:48:04PM -0600, Rob Herring wrote: > On Fri, May 15, 2020 at 03:12:10PM +0200, Guido Günther wrote: > > The bridge allows to select the input source via a mux controller. > > > > Signed-off-by: Guido Günther > > --- > > .../display/bridge/mux-input-bridge.yaml | 123 ++ > > 1 file changed, 123 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/display/bridge/mux-input-bridge.yaml > > > > diff --git > > a/Documentation/devicetree/bindings/display/bridge/mux-input-bridge.yaml > > b/Documentation/devicetree/bindings/display/bridge/mux-input-bridge.yaml > > new file mode 100644 > > index ..4029cf63ee5c > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/display/bridge/mux-input-bridge.yaml > > @@ -0,0 +1,123 @@ > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/display/bridge/mux-input-bridge.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: DRM input source selection via multiplexer > > DRM is not a hardware thing. I thought about naming the mux pixel-input-mux (input-mux sounding too generic) but then i hit rockchip-drm and went for that name. The binding itself is not a drm thing in itself it really aims to model how the mux is placed in the 'display pipeline' of the SoC (as Laurent explained). Should I go with pixel-input-mux? > The graph binding is already designed to support muxing. Generally, > multiple endpoints on an input node is a mux. So either the device with > the input ports knows how to select the input, or you just need a > mux-control property for the port to have some other device implement > the control. A mux control property is how it's modeled at the moment but that is very SoC specific. > You could do it like you have below. That would be appropriate if > there's a separate h/w device controlling the muxing. Say for example > some board level device controlled by i2c. It's a different part of the SoC that lives in a register range very separate (iomuxc_gpr) from MIPI/DSI (nwl). Does that qualify? Cheers, -- Guido > > Rob > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 3/6] dt-bindings: display/bridge/nwl-dsi: Drop mux handling
Hi Rob, On Thu, May 28, 2020 at 01:59:14PM -0600, Rob Herring wrote: > On Fri, May 15, 2020 at 03:12:12PM +0200, Guido Günther wrote: > > No need to encode the SoC specifics in the bridge driver. For the > > imx8mq we can use the mux-input-bridge. > > You can't just change bindings like this. You'd still have to support > the "old" way. But IMO, this way is the right way. My understanding is that binding stability only applies to released kernels and this binding never was in released kernel yet. Does it still apply in this case? Cheers, -- Guido > > > > > Signed-off-by: Guido Günther > > --- > > .../devicetree/bindings/display/bridge/nwl-dsi.yaml | 6 -- > > 1 file changed, 6 deletions(-) > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 10/27] drm: bridge: Pass drm_display_info to drm_bridge_funcs .mode_valid()
/omapdrm/dss/dpi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dpi.c
> @@ -434,6 +434,7 @@ static int dpi_bridge_attach(struct drm_bridge *bridge,
>
> static enum drm_mode_status
> dpi_bridge_mode_valid(struct drm_bridge *bridge,
> +const struct drm_display_info *info,
> const struct drm_display_mode *mode)
> {
> struct dpi_data *dpi = drm_bridge_to_dpi(bridge);
> diff --git a/drivers/gpu/drm/omapdrm/dss/sdi.c
> b/drivers/gpu/drm/omapdrm/dss/sdi.c
> index 417a8740ad0a..033fd30074b0 100644
> --- a/drivers/gpu/drm/omapdrm/dss/sdi.c
> +++ b/drivers/gpu/drm/omapdrm/dss/sdi.c
> @@ -140,6 +140,7 @@ static int sdi_bridge_attach(struct drm_bridge *bridge,
>
> static enum drm_mode_status
> sdi_bridge_mode_valid(struct drm_bridge *bridge,
> + const struct drm_display_info *info,
> const struct drm_display_mode *mode)
> {
> struct sdi_device *sdi = drm_bridge_to_sdi(bridge);
> diff --git a/drivers/gpu/drm/omapdrm/dss/venc.c
> b/drivers/gpu/drm/omapdrm/dss/venc.c
> index 9701843ccf09..4406ce2a08b4 100644
> --- a/drivers/gpu/drm/omapdrm/dss/venc.c
> +++ b/drivers/gpu/drm/omapdrm/dss/venc.c
> @@ -548,6 +548,7 @@ static int venc_bridge_attach(struct drm_bridge *bridge,
>
> static enum drm_mode_status
> venc_bridge_mode_valid(struct drm_bridge *bridge,
> +const struct drm_display_info *info,
> const struct drm_display_mode *mode)
> {
> switch (venc_get_videomode(mode)) {
> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> index ea2aa5ebae34..e3d7f36d8c39 100644
> --- a/include/drm/drm_bridge.h
> +++ b/include/drm/drm_bridge.h
> @@ -35,6 +35,7 @@
> struct drm_bridge;
> struct drm_bridge_timings;
> struct drm_connector;
> +struct drm_display_info;
> struct drm_panel;
> struct edid;
> struct i2c_adapter;
> @@ -112,6 +113,7 @@ struct drm_bridge_funcs {
>* drm_mode_status Enum
>*/
> enum drm_mode_status (*mode_valid)(struct drm_bridge *bridge,
> +const struct drm_display_info *info,
> const struct drm_display_mode *mode);
>
> /**
> @@ -836,6 +838,7 @@ bool drm_bridge_chain_mode_fixup(struct drm_bridge
> *bridge,
>struct drm_display_mode *adjusted_mode);
> enum drm_mode_status
> drm_bridge_chain_mode_valid(struct drm_bridge *bridge,
> + const struct drm_display_info *info,
> const struct drm_display_mode *mode);
> void drm_bridge_chain_disable(struct drm_bridge *bridge);
> void drm_bridge_chain_post_disable(struct drm_bridge *bridge);
> --
> Regards,
>
> Laurent Pinchart
>
for the nwl-dsi part:
Reviewed-by: Guido Günther
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH 4/6] drm/bridge/nwl-dsi: Drop mux handling
This will be handled via the mux-input-bridge.
Signed-off-by: Guido Günther
---
drivers/gpu/drm/bridge/Kconfig | 1 -
drivers/gpu/drm/bridge/nwl-dsi.c | 61
2 files changed, 62 deletions(-)
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 3886c0f41bdd..11444f841e35 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -78,7 +78,6 @@ config DRM_NWL_MIPI_DSI
select DRM_PANEL_BRIDGE
select GENERIC_PHY_MIPI_DPHY
select MFD_SYSCON
- select MULTIPLEXER
select REGMAP_MMIO
help
This enables the Northwest Logic MIPI DSI Host controller as
diff --git a/drivers/gpu/drm/bridge/nwl-dsi.c b/drivers/gpu/drm/bridge/nwl-dsi.c
index b14d725bf609..8839f333f39c 100644
--- a/drivers/gpu/drm/bridge/nwl-dsi.c
+++ b/drivers/gpu/drm/bridge/nwl-dsi.c
@@ -12,7 +12,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -44,9 +43,6 @@ enum transfer_direction {
DSI_PACKET_RECEIVE,
};
-#define NWL_DSI_ENDPOINT_LCDIF 0
-#define NWL_DSI_ENDPOINT_DCSS 1
-
struct nwl_dsi_plat_clk_config {
const char *id;
struct clk *clk;
@@ -94,7 +90,6 @@ struct nwl_dsi {
struct reset_control *rst_esc;
struct reset_control *rst_dpi;
struct reset_control *rst_pclk;
- struct mux_control *mux;
/* DSI clocks */
struct clk *phy_ref_clk;
@@ -1018,14 +1013,6 @@ static int nwl_dsi_parse_dt(struct nwl_dsi *dsi)
}
dsi->tx_esc_clk = clk;
- dsi->mux = devm_mux_control_get(dsi->dev, NULL);
- if (IS_ERR(dsi->mux)) {
- ret = PTR_ERR(dsi->mux);
- if (ret != -EPROBE_DEFER)
- DRM_DEV_ERROR(dsi->dev, "Failed to get mux: %d\n", ret);
- return ret;
- }
-
base = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(base))
return PTR_ERR(base);
@@ -1073,47 +1060,6 @@ static int nwl_dsi_parse_dt(struct nwl_dsi *dsi)
return 0;
}
-static int nwl_dsi_select_input(struct nwl_dsi *dsi)
-{
- struct device_node *remote;
- u32 use_dcss = 1;
- int ret;
-
- remote = of_graph_get_remote_node(dsi->dev->of_node, 0,
- NWL_DSI_ENDPOINT_LCDIF);
- if (remote) {
- use_dcss = 0;
- } else {
- remote = of_graph_get_remote_node(dsi->dev->of_node, 0,
- NWL_DSI_ENDPOINT_DCSS);
- if (!remote) {
- DRM_DEV_ERROR(dsi->dev,
- "No valid input endpoint found\n");
- return -EINVAL;
- }
- }
-
- DRM_DEV_INFO(dsi->dev, "Using %s as input source\n",
-(use_dcss) ? "DCSS" : "LCDIF");
- ret = mux_control_try_select(dsi->mux, use_dcss);
- if (ret < 0)
- DRM_DEV_ERROR(dsi->dev, "Failed to select input: %d\n", ret);
-
- of_node_put(remote);
- return ret;
-}
-
-static int nwl_dsi_deselect_input(struct nwl_dsi *dsi)
-{
- int ret;
-
- ret = mux_control_deselect(dsi->mux);
- if (ret < 0)
- DRM_DEV_ERROR(dsi->dev, "Failed to deselect input: %d\n", ret);
-
- return ret;
-}
-
static const struct drm_bridge_timings nwl_dsi_timings = {
.input_bus_flags = DRM_BUS_FLAG_DE_LOW,
};
@@ -1175,12 +1121,6 @@ static int nwl_dsi_probe(struct platform_device *pdev)
dev_set_drvdata(dev, dsi);
pm_runtime_enable(dev);
- ret = nwl_dsi_select_input(dsi);
- if (ret < 0) {
- mipi_dsi_host_unregister(>dsi_host);
- return ret;
- }
-
drm_bridge_add(>bridge);
return 0;
}
@@ -1189,7 +1129,6 @@ static int nwl_dsi_remove(struct platform_device *pdev)
{
struct nwl_dsi *dsi = platform_get_drvdata(pdev);
- nwl_dsi_deselect_input(dsi);
mipi_dsi_host_unregister(>dsi_host);
drm_bridge_remove(>bridge);
pm_runtime_disable(>dev);
--
2.26.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH 2/6] drm/bridge: Add mux-input bridge
This bridge allows to select the input source
via a mux controller. The input source is
determined via DT but it could become rutime
selectable in the future.
Signed-off-by: Guido Günther
---
drivers/gpu/drm/bridge/Kconfig | 9 ++
drivers/gpu/drm/bridge/Makefile| 1 +
drivers/gpu/drm/bridge/mux-input.c | 238 +
3 files changed, 248 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/mux-input.c
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 04f876e985de..3886c0f41bdd 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -206,6 +206,15 @@ config DRM_TI_TPD12S015
Texas Instruments TPD12S015 HDMI level shifter and ESD protection
driver.
+config DRM_MUX_INPUT
+ tristate "Bridge to select a video input source"
+ depends on OF
+ depends on DRM_BRIDGE
+ select MULTIPLEXER
+ help
+ Select this option if you want to select the input source to
+ a DRM bridge or panel via a separate mux chip.
+
source "drivers/gpu/drm/bridge/analogix/Kconfig"
source "drivers/gpu/drm/bridge/adv7511/Kconfig"
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index d63d4b7e4347..9f3370ce7e07 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -4,6 +4,7 @@ obj-$(CONFIG_DRM_CHRONTEL_CH7033) += chrontel-ch7033.o
obj-$(CONFIG_DRM_DISPLAY_CONNECTOR) += display-connector.o
obj-$(CONFIG_DRM_LVDS_CODEC) += lvds-codec.o
obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) +=
megachips-stdp-ge-b850v3-fw.o
+obj-$(CONFIG_DRM_MUX_INPUT) += mux-input.o
obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
obj-$(CONFIG_DRM_PARADE_PS8640) += parade-ps8640.o
diff --git a/drivers/gpu/drm/bridge/mux-input.c
b/drivers/gpu/drm/bridge/mux-input.c
new file mode 100644
index ..24961d41ac30
--- /dev/null
+++ b/drivers/gpu/drm/bridge/mux-input.c
@@ -0,0 +1,238 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2020 Purism SPC
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#define DRV_NAME "mux-input-bridge"
+
+struct mux_input {
+ struct drm_bridge bridge;
+ struct drm_bridge *out;
+ struct device *dev;
+ struct mux_control *mux;
+ unsigned int n_inputs;
+ unsigned int input;
+ struct drm_bridge_timings timings;
+};
+
+static inline struct mux_input *bridge_to_mux_input(struct drm_bridge *bridge)
+{
+ return container_of(bridge, struct mux_input, bridge);
+}
+
+static void mux_input_bridge_disable(struct drm_bridge *bridge)
+{
+ struct mux_input *mux_input = bridge_to_mux_input(bridge);
+
+ pm_runtime_put(mux_input->dev);
+}
+
+static void mux_input_bridge_pre_enable(struct drm_bridge *bridge)
+{
+ struct mux_input *mux_input = bridge_to_mux_input(bridge);
+
+ pm_runtime_get(mux_input->dev);
+}
+
+static int mux_input_bridge_attach(struct drm_bridge *bridge,
+ enum drm_bridge_attach_flags flags)
+{
+ struct mux_input *mux_input = bridge_to_mux_input(bridge);
+ struct drm_bridge *panel_bridge;
+ struct drm_panel *panel;
+ struct device *dev;
+ struct device_node *remote;
+ int ret;
+
+ /* Only attach to the selected input */
+ remote = of_graph_get_remote_node(mux_input->dev->of_node,
+ mux_input->input,
+ 0);
+ if (!remote)
+ return -EINVAL;
+
+ if (bridge->dev) {
+ dev = bridge->dev->dev;
+ if (dev->of_node != remote) {
+ DRM_DEV_DEBUG(mux_input->dev,
+ "Not attaching to endpoint %s",
+ dev->of_node->name);
+ return -EINVAL;
+ }
+ }
+ of_node_put(remote);
+
+ ret = drm_of_find_panel_or_bridge(mux_input->dev->of_node,
+ mux_input->n_inputs - 1, 0, ,
+ _bridge);
+ if (ret)
+ return ret;
+
+ if (panel) {
+ panel_bridge = drm_panel_bridge_add(panel);
+ if (IS_ERR(panel_bridge))
+ return PTR_ERR(panel_bridge);
+ }
+ mux_input->out = panel_bridge;
+
+ if (!mux_input->out)
+ return -EPROBE_DEFER;
+
+ /* Bubble downstream bridge timings upwards */
+ memcpy(_input->timings, mux_input->out->timings,
+ sizeof(mux_input->timings));
+ mux_input->bridge.timings = _input->timings;
+ return drm_bridge_attach(bridge->
[RFC PATCH 1/6] dt-bindings: display/bridge: Add binding for input mux bridge
The bridge allows to select the input source via a mux controller.
Signed-off-by: Guido Günther
---
.../display/bridge/mux-input-bridge.yaml | 123 ++
1 file changed, 123 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/mux-input-bridge.yaml
diff --git
a/Documentation/devicetree/bindings/display/bridge/mux-input-bridge.yaml
b/Documentation/devicetree/bindings/display/bridge/mux-input-bridge.yaml
new file mode 100644
index ..4029cf63ee5c
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/mux-input-bridge.yaml
@@ -0,0 +1,123 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/mux-input-bridge.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: DRM input source selection via multiplexer
+
+maintainers:
+ - Guido Gúnther
+
+description: |
+ The input multiplexer bridge allows to select an input source
+ via an associated mux controller.
+
+properties:
+ compatible:
+const: mux-input-bridge
+
+ '#address-cells':
+const: 1
+
+ '#size-cells':
+const: 0
+
+ default-input:
+description: The default input to use
+
+ mux-controls:
+description:
+ mux controller node to use for operating the input mux
+
+ ports:
+type: object
+properties:
+ '#address-cells':
+const: 1
+ '#size-cells':
+const: 0
+
+patternProperties:
+ "^port@[0-9]+":
+type: object
+description:
+ At least three nodes containing endpoints connecting to the
+ pixel data inputs and outputs. The last port is always the
+ output port.
+
+properties:
+ reg:
+maxItems: 1
+
+ endpoint:
+description: sub-node describing the input
+type: object
+
+required:
+ - reg
+
+additionalProperties: false
+
+required:
+ - port@0
+ - port@1
+ - port@2
+
+additionalProperties: false
+
+required:
+ - '#address-cells'
+ - '#size-cells'
+ - mux-controls
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+ #include
+
+ mux: mux-controller {
+ compatible = "gpio-mux";
+ #mux-control-cells = <0>;
+
+ mux-gpios = < 15 GPIO_ACTIVE_HIGH>;
+ };
+
+ mipi-mux {
+ compatible = "mux-input-bridge";
+ default-input = <0>;
+ mux-controls = < 0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ dpi_mux_from_lcdif: endpoint {
+ remote-endpoint = <_dpi_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ dpi_mux_from_dccss: endpoint {
+ remote-endpoint = <_dpi_out>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+
+ dpi_mux_out: endpoint {
+ remote-endpoint = <_dpi_in>;
+ };
+ };
+ };
+ };
--
2.26.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
