Re: [PATCH] drm/bridge: dw-mipi-dsi.c: Add VPG runtime config through debugfs
Hi Angelo,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v5.6 next-20200404]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Angelo-Ribeiro/drm-bridge-dw-mipi-dsi-c-Add-VPG-runtime-config-through-debugfs/20200405-032129
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
83eb69f3b80f7cf2ca6357fb9c23adc48632a0e3
config: arm64-defconfig (attached as .config)
compiler: aarch64-linux-gcc (GCC) 9.3.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=9.3.0 make.cross ARCH=arm64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c: In function
'dw_mipi_dsi_video_mode_config':
>> drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c:555:42: error:
>> 'VID_MODE_VPG_MODE' undeclared (first use in this function); did you mean
>> 'VID_MODE_VPG_ENABLE'?
555 | val |= dsi->vpg_defs.vpg_ber_pattern ? VID_MODE_VPG_MODE : 0;
| ^
| VID_MODE_VPG_ENABLE
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c:555:42: note: each undeclared
identifier is reported only once for each function it appears in
In file included from drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c:13:
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c: In function 'fops_x32_open':
>> drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c:1024:36: error: passing
>> argument 3 of 'simple_attr_open' from incompatible pointer type
>> [-Werror=incompatible-pointer-types]
1024 | DEFINE_DEBUGFS_ATTRIBUTE(fops_x32, dw_mipi_dsi_debugfs_show,
|^~~~
||
|ssize_t (*)(void *, u64 *) {aka
long int (*)(void *, long long unsigned int *)}
include/linux/debugfs.h:47:39: note: in definition of macro
'DEFINE_DEBUGFS_ATTRIBUTE'
47 | return simple_attr_open(inode, file, __get, __set, __fmt); \
| ^
In file included from include/linux/debugfs.h:15,
from drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c:13:
include/linux/fs.h:3529:14: note: expected 'int (*)(void *, u64 *)' {aka
'int (*)(void *, long long unsigned int *)'} but argument is of type 'ssize_t
(*)(void *, u64 *)' {aka 'long int (*)(void *, long long unsigned int *)'}
3529 |int (*get)(void *, u64 *), int (*set)(void *, u64),
|~~^~~
In file included from drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c:13:
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c:1025:5: error: passing
argument 4 of 'simple_attr_open' from incompatible pointer type
[-Werror=incompatible-pointer-types]
1025 | dw_mipi_dsi_debugfs_write, "%llu\n");
| ^
| |
| ssize_t (*)(void *, u64) {aka long int (*)(void *, long long
unsigned int)}
include/linux/debugfs.h:47:46: note: in definition of macro
'DEFINE_DEBUGFS_ATTRIBUTE'
47 | return simple_attr_open(inode, file, __get, __set, __fmt); \
| ^
In file included from include/linux/debugfs.h:15,
from drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c:13:
include/linux/fs.h:3529:41: note: expected 'int (*)(void *, u64)' {aka 'int
(*)(void *, long long unsigned int)'} but argument is of type 'ssize_t (*)(void
*, u64)' {aka 'long int (*)(void *, long long unsigned int)'}
3529 |int (*get)(void *, u64 *), int (*set)(void *, u64),
| ~~^
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c: In function
'debugfs_create_files':
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c:1033:29: error:
'VID_MODE_VPG_MODE' undeclared (first use in this function); did you mean
'VID_MODE_VPG_ENABLE'?
1033 | REGISTER(vpg_ber_pattern, VID_MODE_VPG_MODE, dsi),
| ^
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c:229:32: note: in definition of
macro 'REGISTER'
229 | { #name, VPG_DEFS(name, dsi), mask, dsi }
|^~~~
cc1: some warnings being treated as errors
vim +555 drivers/gpu/drm/brid
[Bug 201957] amdgpu: ring gfx timeout
https://bugzilla.kernel.org/show_bug.cgi?id=201957 Steven Ellis (sel...@redhat.com) changed: What|Removed |Added CC||sel...@redhat.com --- Comment #30 from Steven Ellis (sel...@redhat.com) --- I"m seeing the same issue on Ubuntu 18.04 with Upstream PPA "sudo add-apt-repository ppa:oibaf/graphics-drivers" [ 321.412530] [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed out or interrupted! [ 326.286306] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, signaled seq=4447, emitted seq=4449 [ 326.286395] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process mythfrontend.re pid 2410 thread mythfronte:cs0 pid 2880 AMDGPUPRO driver 19.50-967956 [20913.330563] [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed out! [20918.450513] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, but soft recovered [20923.570306] [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed out! [20928.690699] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, but soft recovered -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm ttm hugepages feature pull for 5.7-rc1
The pull request you sent on Fri, 3 Apr 2020 09:35:43 +1000: > git://anongit.freedesktop.org/drm/drm tags/drm-next-2020-04-03-1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/ea9448b254e253e4d95afaab071b341d86c11795 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Mesa-dev] [Intel-gfx] gitlab.fd.o financial situation and impact on services
On Sat, Apr 4, 2020 at 11:41 AM Rob Clark wrote: > > On Sat, Apr 4, 2020 at 11:16 AM Rob Clark wrote: > > > > On Sat, Apr 4, 2020 at 10:47 AM Nicolas Dufresne > > wrote: > > > > > > Le samedi 04 avril 2020 à 08:11 -0700, Rob Clark a écrit : > > > > On Fri, Apr 3, 2020 at 7:12 AM Michel Dänzer wrote: > > > > > On 2020-03-01 6:46 a.m., Marek Olšák wrote: > > > > > > For Mesa, we could run CI only when Marge pushes, so that it's a > > > > > > strictly > > > > > > pre-merge CI. > > > > > > > > > > Thanks for the suggestion! I implemented something like this for Mesa: > > > > > > > > > > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4432 > > > > > > > > > > > > > I wouldn't mind manually triggering pipelines, but unless there is > > > > some trick I'm not realizing, it is super cumbersome. Ie. you have to > > > > click first the container jobs.. then wait.. then the build jobs.. > > > > then wait some more.. and then finally the actual runners. That would > > > > be a real step back in terms of usefulness of CI.. one might call it a > > > > regression :-( > > > > > > On GStreamer side we have moved some existing pipeline to manual mode. > > > As we use needs: between jobs, we could simply set the first job to > > > manual (in our case it's a single job called manifest in your case it > > > would be the N container jobs). This way you can have a manual pipeline > > > that is triggered in single (or fewer) clicks. Here's an example: > > > > > > https://gitlab.freedesktop.org/gstreamer/gstreamer/pipelines/128292 > > > > > > That our post-merge pipelines, we only trigger then if we suspect a > > > problem. > > > > > > > I'm not sure that would work for mesa since the hierarchy of jobs > > branches out pretty far.. ie. if I just clicked the arm64 build + test > > container jobs, and everything else ran automatically after that, it > > would end up running all the CI jobs for all the arm devices (or at > > least all the 64b ones) > > update: pepp pointed out on #dri-devel that the path-based rules > should still apply to prune out hw CI jobs for hw not affected by the > MR. If that is the case, and we only need to click the container jobs > (without then doing the wait dance), then this doesn't sound as > bad as I feared. PS. I should add, that in these wfh days, I'm relying on CI to be able to test changes on some generations of hw that I don't physically have with me. It's easy to take for granted, I did until I thought about what I'd do without CI. So big thanks to all the people who are working on CI, it's more important these days than you might realize :-) BR, -R ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Mesa-dev] [Intel-gfx] gitlab.fd.o financial situation and impact on services
On Sat, Apr 4, 2020 at 11:16 AM Rob Clark wrote: > > On Sat, Apr 4, 2020 at 10:47 AM Nicolas Dufresne wrote: > > > > Le samedi 04 avril 2020 à 08:11 -0700, Rob Clark a écrit : > > > On Fri, Apr 3, 2020 at 7:12 AM Michel Dänzer wrote: > > > > On 2020-03-01 6:46 a.m., Marek Olšák wrote: > > > > > For Mesa, we could run CI only when Marge pushes, so that it's a > > > > > strictly > > > > > pre-merge CI. > > > > > > > > Thanks for the suggestion! I implemented something like this for Mesa: > > > > > > > > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4432 > > > > > > > > > > I wouldn't mind manually triggering pipelines, but unless there is > > > some trick I'm not realizing, it is super cumbersome. Ie. you have to > > > click first the container jobs.. then wait.. then the build jobs.. > > > then wait some more.. and then finally the actual runners. That would > > > be a real step back in terms of usefulness of CI.. one might call it a > > > regression :-( > > > > On GStreamer side we have moved some existing pipeline to manual mode. > > As we use needs: between jobs, we could simply set the first job to > > manual (in our case it's a single job called manifest in your case it > > would be the N container jobs). This way you can have a manual pipeline > > that is triggered in single (or fewer) clicks. Here's an example: > > > > https://gitlab.freedesktop.org/gstreamer/gstreamer/pipelines/128292 > > > > That our post-merge pipelines, we only trigger then if we suspect a > > problem. > > > > I'm not sure that would work for mesa since the hierarchy of jobs > branches out pretty far.. ie. if I just clicked the arm64 build + test > container jobs, and everything else ran automatically after that, it > would end up running all the CI jobs for all the arm devices (or at > least all the 64b ones) update: pepp pointed out on #dri-devel that the path-based rules should still apply to prune out hw CI jobs for hw not affected by the MR. If that is the case, and we only need to click the container jobs (without then doing the wait dance), then this doesn't sound as bad as I feared. BR, -R ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: plane: Verify that no or all planes have a zpos property
Hi Laurent.
On Sat, Apr 04, 2020 at 09:12:53PM +0300, Laurent Pinchart wrote:
> The zpos property is used by userspace to sort the order of planes.
> While the property is not mandatory for drivers to implement, mixing
> planes with and without zpos confuses userspace, and shall not be
> allowed. Clarify this in the documentation and warn at runtime if the
> drivers mixes planes with and without zpos properties.
>
> Signed-off-by: Laurent Pinchart
Looks good.
Acked-by: Sam Ravnborg
> ---
> drivers/gpu/drm/drm_blend.c | 10 ++
> drivers/gpu/drm/drm_plane.c | 9 +
> 2 files changed, 15 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
> index 88eedee018d3..f1dcad96f341 100644
> --- a/drivers/gpu/drm/drm_blend.c
> +++ b/drivers/gpu/drm/drm_blend.c
> @@ -135,7 +135,9 @@
> * are underneath planes with higher Z position values. Two planes with the
> * same Z position value have undefined ordering. Note that the Z position
> * value can also be immutable, to inform userspace about the hard-coded
> - * stacking of planes, see drm_plane_create_zpos_immutable_property().
> + * stacking of planes, see drm_plane_create_zpos_immutable_property(). If
> + * any plane has a zpos property (either mutable or immutable), then all
> + * planes shall have a zpos property.
> *
> * pixel blend mode:
> * Pixel blend mode is set up with drm_plane_create_blend_mode_property().
> @@ -344,10 +346,10 @@ EXPORT_SYMBOL(drm_rotation_simplify);
> * should be set to 0 and max to maximal number of planes for given crtc - 1.
> *
> * If zpos of some planes cannot be changed (like fixed background or
> - * cursor/topmost planes), driver should adjust min/max values and assign
> those
> - * planes immutable zpos property with lower or higher values (for more
> + * cursor/topmost planes), drivers shall adjust the min/max values and assign
> + * those planes immutable zpos properties with lower or higher values (for
> more
> * information, see drm_plane_create_zpos_immutable_property() function). In
> such
> - * case driver should also assign proper initial zpos values for all planes
> in
> + * case drivers shall also assign proper initial zpos values for all planes
> in
> * its plane_reset() callback, so the planes will be always sorted properly.
> *
> * See also drm_atomic_normalize_zpos().
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index d6ad60ab0d38..efb9c16ddc21 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -289,6 +289,8 @@ EXPORT_SYMBOL(drm_universal_plane_init);
>
> int drm_plane_register_all(struct drm_device *dev)
> {
> + unsigned int num_planes = 0;
> + unsigned int num_zpos = 0;
> struct drm_plane *plane;
> int ret = 0;
>
> @@ -297,8 +299,15 @@ int drm_plane_register_all(struct drm_device *dev)
> ret = plane->funcs->late_register(plane);
> if (ret)
> return ret;
> +
> + if (plane->zpos_property)
> + num_zpos++;
> + num_planes++;
> }
>
> + drm_WARN(dev, num_planes != num_zpos,
> + "Mixing planes with and without zpos property is invalid\n");
> +
> return 0;
> }
>
> --
> Regards,
>
> Laurent Pinchart
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: rcar-du: Create immutable zpos property for primary planes
Hi Geert,
On Thu, Apr 02, 2020 at 01:12:51PM +0200, Geert Uytterhoeven wrote:
> On Thu, Apr 2, 2020 at 12:42 PM Laurent Pinchart wrote:
> > The R-Car DU driver creates a zpos property, ranging from 1 to 7, for
> > all the overlay planes, but leaves the primary plane without a zpos
> > property. The DRM/KMS API doesn't clearly specify if this is acceptable,
> > of it the property is mandatory for all planes when exposed for some of
> > the planes. Nonetheless, weston v8.0 has been reported to have trouble
> > handling this situation.
> >
> > The DRM core offers support for immutable zpos properties. Creating an
> > immutable zpos property set to 0 for the primary planes seems to be a
> > good way forward, as it shouldn't introduce any regression, and can fix
> > the issue. Do so.
> >
> > Reported-by: Kuninori Morimoto
> > Signed-off-by: Laurent Pinchart
>
> Thanks for your patch!
>
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> > @@ -785,13 +785,15 @@ int rcar_du_planes_init(struct rcar_du_group *rgrp)
> >
> > drm_plane_create_alpha_property(>plane);
> >
> > - if (type == DRM_PLANE_TYPE_PRIMARY)
> > - continue;
> > -
> > - drm_object_attach_property(>plane.base,
> > - rcdu->props.colorkey,
> > - RCAR_DU_COLORKEY_NONE);
> > - drm_plane_create_zpos_property(>plane, 1, 1, 7);
> > + if (type == DRM_PLANE_TYPE_PRIMARY) {
> > +
> > drm_plane_create_zpos_immutable_property(>plane,
> > +0);
> > + } else {
> > + drm_object_attach_property(>plane.base,
> > + rcdu->props.colorkey,
> > + RCAR_DU_COLORKEY_NONE);
> > + drm_plane_create_zpos_property(>plane, 1, 1,
> > 7);
> > + }
> > }
> >
> > return 0;
>
> This is very similar to Esaki-san's patch[*] posted yesterday.
Thank you for pointing me to it, I had missed that patch.
> However, there's one big difference: your patch doesn't update
> rcar_du_vsp_init(). Isn't that needed?
>
> [*] "[PATCH] drm: rcar-du: Set primary plane zpos immutably at initializing"
>
> https://lore.kernel.org/linux-renesas-soc/20200401061100.7379-1-e...@igel.co.jp/
My bad. I've sent a v2 of Esaki-san's patch to CC the dri-devel mailing
list, and have applied it to my tree.
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm: rcar-du: Set primary plane zpos immutably at initializing
From: Tomohito Esaki
According to drm_plane_create_zpos_property() function documentation,
all planes zpos range should be set if zpos property is supported.
However, the rcar-du driver didn't set primary plane zpos range. Since
the primary plane's zpos is fixed, set it immutably.
Reported-by: Yoshihito Ogawa
Reported-by: Koji Matsuoka
Signed-off-by: Tomohito Esaki
Reviewed-by: Laurent Pinchart
Reviewed-by: Daniel Stone
[Turn continue into if ... else ...]
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_plane.c | 16 +---
drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 14 --
2 files changed, 17 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
index c6430027169f..a0021fc25b27 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
@@ -785,13 +785,15 @@ int rcar_du_planes_init(struct rcar_du_group *rgrp)
drm_plane_create_alpha_property(>plane);
- if (type == DRM_PLANE_TYPE_PRIMARY)
- continue;
-
- drm_object_attach_property(>plane.base,
- rcdu->props.colorkey,
- RCAR_DU_COLORKEY_NONE);
- drm_plane_create_zpos_property(>plane, 1, 1, 7);
+ if (type == DRM_PLANE_TYPE_PRIMARY) {
+ drm_plane_create_zpos_immutable_property(>plane,
+0);
+ } else {
+ drm_object_attach_property(>plane.base,
+ rcdu->props.colorkey,
+ RCAR_DU_COLORKEY_NONE);
+ drm_plane_create_zpos_property(>plane, 1, 1, 7);
+ }
}
return 0;
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
index 5e4faf258c31..f1a81c9b184d 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
@@ -392,12 +392,14 @@ int rcar_du_vsp_init(struct rcar_du_vsp *vsp, struct
device_node *np,
drm_plane_helper_add(>plane,
_du_vsp_plane_helper_funcs);
- if (type == DRM_PLANE_TYPE_PRIMARY)
- continue;
-
- drm_plane_create_alpha_property(>plane);
- drm_plane_create_zpos_property(>plane, 1, 1,
- vsp->num_planes - 1);
+ if (type == DRM_PLANE_TYPE_PRIMARY) {
+ drm_plane_create_zpos_immutable_property(>plane,
+0);
+ } else {
+ drm_plane_create_alpha_property(>plane);
+ drm_plane_create_zpos_property(>plane, 1, 1,
+ vsp->num_planes - 1);
+ }
}
return 0;
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Mesa-dev] [Intel-gfx] gitlab.fd.o financial situation and impact on services
On Sat, Apr 4, 2020 at 10:47 AM Nicolas Dufresne wrote: > > Le samedi 04 avril 2020 à 08:11 -0700, Rob Clark a écrit : > > On Fri, Apr 3, 2020 at 7:12 AM Michel Dänzer wrote: > > > On 2020-03-01 6:46 a.m., Marek Olšák wrote: > > > > For Mesa, we could run CI only when Marge pushes, so that it's a > > > > strictly > > > > pre-merge CI. > > > > > > Thanks for the suggestion! I implemented something like this for Mesa: > > > > > > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4432 > > > > > > > I wouldn't mind manually triggering pipelines, but unless there is > > some trick I'm not realizing, it is super cumbersome. Ie. you have to > > click first the container jobs.. then wait.. then the build jobs.. > > then wait some more.. and then finally the actual runners. That would > > be a real step back in terms of usefulness of CI.. one might call it a > > regression :-( > > On GStreamer side we have moved some existing pipeline to manual mode. > As we use needs: between jobs, we could simply set the first job to > manual (in our case it's a single job called manifest in your case it > would be the N container jobs). This way you can have a manual pipeline > that is triggered in single (or fewer) clicks. Here's an example: > > https://gitlab.freedesktop.org/gstreamer/gstreamer/pipelines/128292 > > That our post-merge pipelines, we only trigger then if we suspect a > problem. > I'm not sure that would work for mesa since the hierarchy of jobs branches out pretty far.. ie. if I just clicked the arm64 build + test container jobs, and everything else ran automatically after that, it would end up running all the CI jobs for all the arm devices (or at least all the 64b ones) I'm not sure why gitlab works this way, a more sensible approach would be to click on the last jobs you want to run and for that to automatically propagate up to run the jobs needed to run clicked job. BR, -R ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: plane: Verify that no or all planes have a zpos property
The zpos property is used by userspace to sort the order of planes.
While the property is not mandatory for drivers to implement, mixing
planes with and without zpos confuses userspace, and shall not be
allowed. Clarify this in the documentation and warn at runtime if the
drivers mixes planes with and without zpos properties.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/drm_blend.c | 10 ++
drivers/gpu/drm/drm_plane.c | 9 +
2 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
index 88eedee018d3..f1dcad96f341 100644
--- a/drivers/gpu/drm/drm_blend.c
+++ b/drivers/gpu/drm/drm_blend.c
@@ -135,7 +135,9 @@
* are underneath planes with higher Z position values. Two planes with the
* same Z position value have undefined ordering. Note that the Z position
* value can also be immutable, to inform userspace about the hard-coded
- * stacking of planes, see drm_plane_create_zpos_immutable_property().
+ * stacking of planes, see drm_plane_create_zpos_immutable_property(). If
+ * any plane has a zpos property (either mutable or immutable), then all
+ * planes shall have a zpos property.
*
* pixel blend mode:
* Pixel blend mode is set up with drm_plane_create_blend_mode_property().
@@ -344,10 +346,10 @@ EXPORT_SYMBOL(drm_rotation_simplify);
* should be set to 0 and max to maximal number of planes for given crtc - 1.
*
* If zpos of some planes cannot be changed (like fixed background or
- * cursor/topmost planes), driver should adjust min/max values and assign those
- * planes immutable zpos property with lower or higher values (for more
+ * cursor/topmost planes), drivers shall adjust the min/max values and assign
+ * those planes immutable zpos properties with lower or higher values (for more
* information, see drm_plane_create_zpos_immutable_property() function). In
such
- * case driver should also assign proper initial zpos values for all planes in
+ * case drivers shall also assign proper initial zpos values for all planes in
* its plane_reset() callback, so the planes will be always sorted properly.
*
* See also drm_atomic_normalize_zpos().
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index d6ad60ab0d38..efb9c16ddc21 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -289,6 +289,8 @@ EXPORT_SYMBOL(drm_universal_plane_init);
int drm_plane_register_all(struct drm_device *dev)
{
+ unsigned int num_planes = 0;
+ unsigned int num_zpos = 0;
struct drm_plane *plane;
int ret = 0;
@@ -297,8 +299,15 @@ int drm_plane_register_all(struct drm_device *dev)
ret = plane->funcs->late_register(plane);
if (ret)
return ret;
+
+ if (plane->zpos_property)
+ num_zpos++;
+ num_planes++;
}
+ drm_WARN(dev, num_planes != num_zpos,
+"Mixing planes with and without zpos property is invalid\n");
+
return 0;
}
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 3/4] drm/mediatek: add the mipitx driving control
Hi, Jitao:
Jitao Shi 於 2020年3月31日 週二 下午4:28寫道：
>
> Add a property in device tree to control the driving by different
> board.
Reviewed-by: Chun-Kuang Hu
>
> Reviewed-by: Matthias Brugger
> Signed-off-by: Jitao Shi
> ---
> drivers/gpu/drm/mediatek/mtk_mipi_tx.c| 14 ++
> drivers/gpu/drm/mediatek/mtk_mipi_tx.h| 1 +
> drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c | 7 +++
> 3 files changed, 22 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_mipi_tx.c
> b/drivers/gpu/drm/mediatek/mtk_mipi_tx.c
> index e4d34484ecc8..e301af64809e 100644
> --- a/drivers/gpu/drm/mediatek/mtk_mipi_tx.c
> +++ b/drivers/gpu/drm/mediatek/mtk_mipi_tx.c
> @@ -125,6 +125,20 @@ static int mtk_mipi_tx_probe(struct platform_device
> *pdev)
> return ret;
> }
>
> + ret = of_property_read_u32(dev->of_node, "drive-strength-microamp",
> + _tx->mipitx_drive);
> + /* If can't get the "mipi_tx->mipitx_drive", set it default 0x8 */
> + if (ret < 0)
> + mipi_tx->mipitx_drive = 4600;
> +
> + /* check the mipitx_drive valid */
> + if (mipi_tx->mipitx_drive > 6000 || mipi_tx->mipitx_drive < 3000) {
> + dev_warn(dev, "drive-strength-microamp is invalid %d, not in
> 3000 ~ 6000\n",
> +mipi_tx->mipitx_drive);
> + mipi_tx->mipitx_drive = clamp_val(mipi_tx->mipitx_drive, 3000,
> + 6000);
> + }
> +
> ref_clk_name = __clk_get_name(ref_clk);
>
> ret = of_property_read_string(dev->of_node, "clock-output-names",
> diff --git a/drivers/gpu/drm/mediatek/mtk_mipi_tx.h
> b/drivers/gpu/drm/mediatek/mtk_mipi_tx.h
> index 413f35d86219..eea44327fe9f 100644
> --- a/drivers/gpu/drm/mediatek/mtk_mipi_tx.h
> +++ b/drivers/gpu/drm/mediatek/mtk_mipi_tx.h
> @@ -27,6 +27,7 @@ struct mtk_mipi_tx {
> struct device *dev;
> void __iomem *regs;
> u32 data_rate;
> + u32 mipitx_drive;
> const struct mtk_mipitx_data *driver_data;
> struct clk_hw pll_hw;
> struct clk *pll;
> diff --git a/drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c
> b/drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c
> index 91f08a351fd0..e4cc967750cb 100644
> --- a/drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c
> +++ b/drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c
> @@ -17,6 +17,9 @@
> #define RG_DSI_BG_CORE_EN BIT(7)
> #define RG_DSI_PAD_TIEL_SELBIT(8)
>
> +#define MIPITX_VOLTAGE_SEL 0x0010
> +#define RG_DSI_HSTX_LDO_REF_SEL(0xf << 6)
> +
> #define MIPITX_PLL_PWR 0x0028
> #define MIPITX_PLL_CON00x002c
> #define MIPITX_PLL_CON10x0030
> @@ -123,6 +126,10 @@ static void mtk_mipi_tx_power_on_signal(struct phy *phy)
> mtk_mipi_tx_clear_bits(mipi_tx, MIPITX_D3_SW_CTL_EN, DSI_SW_CTL_EN);
> mtk_mipi_tx_clear_bits(mipi_tx, MIPITX_CK_SW_CTL_EN, DSI_SW_CTL_EN);
>
> + mtk_mipi_tx_update_bits(mipi_tx, MIPITX_VOLTAGE_SEL,
> + RG_DSI_HSTX_LDO_REF_SEL,
> + (mipi_tx->mipitx_drive - 3000) / 200 << 6);
> +
> mtk_mipi_tx_set_bits(mipi_tx, MIPITX_CK_CKMODE_EN, DSI_CK_CKMODE_EN);
> }
>
> --
> 2.21.0
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 1/4] dt-bindings: display: mediatek: add property to control mipi tx drive current
Hi, Jitao:
Jitao Shi 於 2020年3月31日 週二 下午4:28寫道：
>
> Add a property to control mipi tx drive current:
> "drive-strength-microamp"
Reviewed-by: Chun-Kuang Hu
>
> Signed-off-by: Jitao Shi
> ---
> .../devicetree/bindings/display/mediatek/mediatek,dsi.txt| 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git
> a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
> b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
> index a19a6cc375ed..d78b6d6d8fab 100644
> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
> @@ -33,6 +33,10 @@ Required properties:
> - #clock-cells: must be <0>;
> - #phy-cells: must be <0>.
>
> +Optional properties:
> +- drive-strength-microamp: adjust driving current, should be 3000 ~ 6000. And
> + the step is 200.
> +
> Example:
>
> mipi_tx0: mipi-dphy@10215000 {
> @@ -42,6 +46,7 @@ mipi_tx0: mipi-dphy@10215000 {
> clock-output-names = "mipi_tx0_pll";
> #clock-cells = <0>;
> #phy-cells = <0>;
> + drive-strength-microamp = <4600>;
> };
>
> dsi0: dsi@1401b000 {
> --
> 2.21.0
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Mesa-dev] [Intel-gfx] gitlab.fd.o financial situation and impact on services
On Fri, Apr 3, 2020 at 7:12 AM Michel Dänzer wrote: > > On 2020-03-01 6:46 a.m., Marek Olšák wrote: > > For Mesa, we could run CI only when Marge pushes, so that it's a strictly > > pre-merge CI. > > Thanks for the suggestion! I implemented something like this for Mesa: > > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4432 > I wouldn't mind manually triggering pipelines, but unless there is some trick I'm not realizing, it is super cumbersome. Ie. you have to click first the container jobs.. then wait.. then the build jobs.. then wait some more.. and then finally the actual runners. That would be a real step back in terms of usefulness of CI.. one might call it a regression :-( Is there a possible middle ground where pre-marge pipelines that touch a particular driver trigger that driver's CI jobs, but MRs that don't touch that driver but do touch shared code don't until triggered by marge? Ie. if I have a MR that only touches nir, it's probably ok to not run freedreno jobs until marge triggers it. But if I have a MR that is touching freedreno, I'd really rather not have to wait until marge triggers the freedreno CI jobs. Btw, I was under the impression (from periodically skimming the logs in #freedesktop, so I could well be missing or misunderstanding something) that caching/etc had been improved and mesa's part of the egress wasn't the bigger issue at this point? BR, -R ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 4/4] drm/mediatek: config mipitx impedance with calibration data
Hi, Jitao:
Jitao Shi 於 2020年3月31日 週二 下午4:28寫道：
>
> Read calibration data from nvmem, and config mipitx impedance with
> calibration data to make sure their impedance are 100ohm.
>
> Signed-off-by: Jitao Shi
> ---
> drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c | 57 +++
> 1 file changed, 57 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c
> b/drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c
> index e4cc967750cb..0f87cd3d1d7d 100644
> --- a/drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c
> +++ b/drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c
> @@ -5,6 +5,8 @@
> */
>
> #include "mtk_mipi_tx.h"
> +#include
> +#include
>
> #define MIPITX_LANE_CON0x000c
> #define RG_DSI_CPHY_T1DRV_EN BIT(0)
> @@ -28,6 +30,7 @@
> #define MIPITX_PLL_CON40x003c
> #define RG_DSI_PLL_IBIAS (3 << 10)
>
> +#define MIPITX_D2P_RTCODE 0x0100
> #define MIPITX_D2_SW_CTL_EN0x0144
> #define MIPITX_D0_SW_CTL_EN0x0244
> #define MIPITX_CK_CKMODE_EN0x0328
> @@ -108,6 +111,58 @@ static const struct clk_ops mtk_mipi_tx_pll_ops = {
> .recalc_rate = mtk_mipi_tx_pll_recalc_rate,
> };
>
> +static void mtk_mipi_tx_config_calibration_data(struct mtk_mipi_tx *mipi_tx)
> +{
> + u32 *buf;
> + u32 rt_code[5];
> + int i, j;
> + struct nvmem_cell *cell;
> + struct device *dev = mipi_tx->dev;
> + size_t len;
> +
> + cell = nvmem_cell_get(dev, "calibration-data");
> + if (IS_ERR(cell)) {
> + dev_info(dev, "nvmem_cell_get fail\n");
> + return;
> + }
> +
> + buf = (u32 *)nvmem_cell_read(cell, );
> +
> + nvmem_cell_put(cell);
> +
> + if (IS_ERR(buf)) {
> + dev_info(dev, "can't get data\n");
> + return;
> + }
> +
> + if (len < 3 * sizeof(u32)) {
> + dev_info(dev, "invalid calibration data\n");
> + kfree(buf);
> + return;
> + }
> +
> + rt_code[0] = ((buf[0] >> 6 & 0x1f) << 5) | (buf[0] >> 11 & 0x1f);
> + rt_code[1] = ((buf[1] >> 27 & 0x1f) << 5) | (buf[0] >> 1 & 0x1f);
> + rt_code[2] = ((buf[1] >> 17 & 0x1f) << 5) | (buf[1] >> 22 & 0x1f);
> + rt_code[3] = ((buf[1] >> 7 & 0x1f) << 5) | (buf[1] >> 12 & 0x1f);
> + rt_code[4] = ((buf[2] >> 27 & 0x1f) << 5) | (buf[1] >> 2 & 0x1f);
Why not just save rt_code in nvmem and you don't need to translate here?
If you need to do so, please add description for this.
Regards,
Chun-Kuang.
> +
> + for (i = 0; i < 5; i++) {
> + if ((rt_code[i] & 0x1f) == 0)
> + rt_code[i] |= 0x10;
> +
> + if ((rt_code[i] >> 5 & 0x1f) == 0)
> + rt_code[i] |= 0x10 << 5;
> +
> + for (j = 0; j < 10; j++)
> + mtk_mipi_tx_update_bits(mipi_tx,
> + MIPITX_D2P_RTCODE * (i + 1) + j * 4,
> + 1, rt_code[i] >> j & 1);
> + }
> +
> + kfree(buf);
> +}
> +
> static void mtk_mipi_tx_power_on_signal(struct phy *phy)
> {
> struct mtk_mipi_tx *mipi_tx = phy_get_drvdata(phy);
> @@ -130,6 +185,8 @@ static void mtk_mipi_tx_power_on_signal(struct phy *phy)
> RG_DSI_HSTX_LDO_REF_SEL,
> (mipi_tx->mipitx_drive - 3000) / 200 << 6);
>
> + mtk_mipi_tx_config_calibration_data(mipi_tx);
> +
> mtk_mipi_tx_set_bits(mipi_tx, MIPITX_CK_CKMODE_EN, DSI_CK_CKMODE_EN);
> }
>
> --
> 2.21.0
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 2/4] dt-bindings: display: mediatek: get mipitx calibration data from nvmem
Hi, Jitao:
Jitao Shi 於 2020年3月31日 週二 下午4:28寫道：
>
> Add properties to get get mipitx calibration data.
Reviewed-by: Chun-Kuang Hu
>
> Reviewed-by: Rob Herring
> Signed-off-by: Jitao Shi
> ---
> .../devicetree/bindings/display/mediatek/mediatek,dsi.txt| 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git
> a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
> b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
> index d78b6d6d8fab..8e4729de8c85 100644
> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
> @@ -36,6 +36,9 @@ Required properties:
> Optional properties:
> - drive-strength-microamp: adjust driving current, should be 3000 ~ 6000. And
>the step is 200.
> +- nvmem-cells: A phandle to the calibration data provided by a nvmem device.
> If
> + unspecified default values shall be used.
> +- nvmem-cell-names: Should be "calibration-data"
>
> Example:
>
> @@ -47,6 +50,8 @@ mipi_tx0: mipi-dphy@10215000 {
> #clock-cells = <0>;
> #phy-cells = <0>;
> drive-strength-microamp = <4600>;
> + nvmem-cells= <_tx_calibration>;
> + nvmem-cell-names = "calibration-data";
> };
>
> dsi0: dsi@1401b000 {
> --
> 2.21.0
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v14 3/3] drm/mediatek: set dpi pin mode to gpio low to avoid leakage current
Hi, Jitao:
Jitao Shi 於 2020年4月3日 週五 下午4:04寫道：
>
> Config dpi pins mode to output and pull low when dpi is disabled.
> Aovid leakage current from some dpi pins (Hsync Vsync DE ... ).
Reviewed-by: Chun-Kuang Hu
>
> Signed-off-by: Jitao Shi
> ---
> drivers/gpu/drm/mediatek/mtk_dpi.c | 31 ++
> 1 file changed, 31 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
> b/drivers/gpu/drm/mediatek/mtk_dpi.c
> index 087f5ce732e1..1e01254788d9 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dpi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
> @@ -10,7 +10,9 @@
> #include
> #include
> #include
> +#include
> #include
> +#include
> #include
> #include
>
> @@ -74,6 +76,9 @@ struct mtk_dpi {
> enum mtk_dpi_out_yc_map yc_map;
> enum mtk_dpi_out_bit_num bit_num;
> enum mtk_dpi_out_channel_swap channel_swap;
> + struct pinctrl *pinctrl;
> + struct pinctrl_state *pins_gpio;
> + struct pinctrl_state *pins_dpi;
> int refcount;
> };
>
> @@ -379,6 +384,9 @@ static void mtk_dpi_power_off(struct mtk_dpi *dpi)
> if (--dpi->refcount != 0)
> return;
>
> + if (dpi->pinctrl && dpi->pins_gpio)
> + pinctrl_select_state(dpi->pinctrl, dpi->pins_gpio);
> +
> mtk_dpi_disable(dpi);
> clk_disable_unprepare(dpi->pixel_clk);
> clk_disable_unprepare(dpi->engine_clk);
> @@ -403,6 +411,9 @@ static int mtk_dpi_power_on(struct mtk_dpi *dpi)
> goto err_pixel;
> }
>
> + if (dpi->pinctrl && dpi->pins_dpi)
> + pinctrl_select_state(dpi->pinctrl, dpi->pins_dpi);
> +
> mtk_dpi_enable(dpi);
> return 0;
>
> @@ -705,6 +716,26 @@ static int mtk_dpi_probe(struct platform_device *pdev)
> dpi->dev = dev;
> dpi->conf = (struct mtk_dpi_conf *)of_device_get_match_data(dev);
>
> + dpi->pinctrl = devm_pinctrl_get(>dev);
> + if (IS_ERR(dpi->pinctrl)) {
> + dpi->pinctrl = NULL;
> + dev_dbg(>dev, "Cannot find pinctrl!\n");
> + }
> + if (dpi->pinctrl) {
> + dpi->pins_gpio = pinctrl_lookup_state(dpi->pinctrl, "sleep");
> + if (IS_ERR(dpi->pins_gpio)) {
> + dpi->pins_gpio = NULL;
> + dev_dbg(>dev, "Cannot find pinctrl idle!\n");
> + }
> + if (dpi->pins_gpio)
> + pinctrl_select_state(dpi->pinctrl, dpi->pins_gpio);
> +
> + dpi->pins_dpi = pinctrl_lookup_state(dpi->pinctrl, "default");
> + if (IS_ERR(dpi->pins_dpi)) {
> + dpi->pins_dpi = NULL;
> + dev_dbg(>dev, "Cannot find pinctrl active!\n");
> + }
> + }
> mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> dpi->regs = devm_ioremap_resource(dev, mem);
> if (IS_ERR(dpi->regs)) {
> --
> 2.21.0
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v14 1/3] dt-bindings: display: mediatek: control dpi pins mode to avoid leakage
Hi, Jitao:
Jitao Shi 於 2020年4月3日 週五 下午4:04寫道：
>
> Add property "pinctrl-names" to swap pin mode between gpio and dpi mode. Set
> the dpi pins to gpio mode and output-low to avoid leakage current when dpi
> disabled.
>
Reviewed-by: Chun-Kuang Hu
> Signed-off-by: Jitao Shi
> ---
> .../devicetree/bindings/display/mediatek/mediatek,dpi.txt | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git
> a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt
> b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt
> index 58914cf681b8..77def4456706 100644
> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt
> @@ -17,6 +17,9 @@ Required properties:
>Documentation/devicetree/bindings/graph.txt. This port should be connected
>to the input port of an attached HDMI or LVDS encoder chip.
>
> +Optional properties:
> +- pinctrl-names: Contain "default" and "sleep".
> +
> Example:
>
> dpi0: dpi@1401d000 {
> @@ -27,6 +30,9 @@ dpi0: dpi@1401d000 {
> < CLK_MM_DPI_ENGINE>,
> < CLK_APMIXED_TVDPLL>;
> clock-names = "pixel", "engine", "pll";
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <_pin_func>;
> + pinctrl-1 = <_pin_idle>;
>
> port {
> dpi0_out: endpoint {
> --
> 2.21.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
[PULL] drm-misc-next-fixes
Hi Daniel, Dave, Here's this week round of drm-misc-next fixes. Thanks! Maxime drm-misc-next-fixes-2020-04-04: A bunch of fixes to avoid null pointer dereference in fbcon, fix a return in xen, some DT bindings fixes, a vc4 issue with 1920x1200 mode validation, and a conflicting framebuffer in vboxvideo. The following changes since commit 6afe6929964bca6847986d0507a555a041f07753: drm: Mark up racy check of drm_gem_object.handle_count (2020-03-16 10:31:35 +) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-fixes-2020-04-04 for you to fetch changes up to d8a26d8fc37c5b8b9e95f2fa194f287cf8cab3f4: drm/mm: revert "Break long searches in fragmented address spaces" (2020-03-31 17:35:56 +0200) A bunch of fixes to avoid null pointer dereference in fbcon, fix a return in xen, some DT bindings fixes, a vc4 issue with 1920x1200 mode validation, and a conflicting framebuffer in vboxvideo. Christian König (1): drm/mm: revert "Break long searches in fragmented address spaces" Ding Xiang (1): drm/xen: fix passing zero to 'PTR_ERR' warning Geert Uytterhoeven (1): dma-buf: Improve CONFIG_DMABUF_MOVE_NOTIFY help text Hans de Goede (1): drm/vboxvideo: Add missing remove_conflicting_pci_framebuffers call, v2 Mauro Carvalho Chehab (1): docs: dt: display/ti: fix typos at the devicetree/ directory name Nicolas Saenz Julienne (1): drm/vc4: Fix HDMI mode validation Qiujun Huang (1): fbcon: fix null-ptr-deref in fbcon_switch Rob Herring (1): dt-bindings: display: ti: Fix dtc unit-address warnings in examples Sam Ravnborg (2): dt-bindings: display: drop data-mapping from panel-dpi drm/panel-simple: drop use of data-mapping property .../devicetree/bindings/display/panel/panel-dpi.yaml | 10 -- .../devicetree/bindings/display/ti/ti,am65x-dss.yaml | 4 ++-- .../devicetree/bindings/display/ti/ti,j721e-dss.yaml | 4 ++-- .../devicetree/bindings/display/ti/ti,k2g-dss.yaml | 4 ++-- drivers/dma-buf/Kconfig | 11 ++- drivers/gpu/drm/drm_mm.c | 8 +--- drivers/gpu/drm/panel/panel-simple.c | 11 --- drivers/gpu/drm/vboxvideo/vbox_drv.c | 4 drivers/gpu/drm/vc4/vc4_hdmi.c | 20 drivers/gpu/drm/xen/xen_drm_front.c | 2 +- drivers/video/fbdev/core/fbcon.c | 3 +++ 11 files changed, 37 insertions(+), 44 deletions(-) signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: mainline/master bisection: baseline.login on peach-pi
Hi, On Fri, Apr 03, 2020 at 03:47:46PM +, Deucher, Alexander wrote: > [AMD Official Use Only - Internal Distribution Only] > > > -Original Message- > > From: Guillaume Tucker > > Sent: Friday, April 3, 2020 10:14 AM > > To: Michael J. Ruhl ; Shane Francis > > ; Deucher, Alexander > > > > Cc: kerne...@groups.io; dri-devel@lists.freedesktop.org; linux- > > ker...@vger.kernel.org; Tom Murphy ; Joerg Roedel > > ; David Airlie ; Maarten Lankhorst > > ; Daniel Vetter ; > > Maxime Ripard ; Enric Balletbo i Serra > > > > Subject: Re: mainline/master bisection: baseline.login on peach-pi > > > > Please see the bisection report below about a boot failure. > > > > Reports aren't automatically sent to the public while we're trialing new > > bisection features on kernelci.org but this one looks valid. > > > > This bisection was run with exynos_defconfig but the issue can also be > > reproduced with multi_v7_defconfig. It doesn't appear to be affecting any > > other platforms on kernelci.org. This looks like a DRM driver problem, the > > kernel image boots fine without the modules installed. It actually started > > failing on Tuesday in mainline. > > Fixed with this patch: > https://patchwork.freedesktop.org/patch/359081/ > > Just trying to get this into 5.7 and stable. I was waiting for a > 5.6 back merge to drm-misc-next-fixes, but I could send it as a > separate PR if Dave or Daniel prefer. You should ask us next time, we're not doing them unless asked :) I've done it, it's compiling at the moment, it should be pushed in the next 10 minutes or so. Maxime signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] dt-bindings: display: convert rockchip rk3066 hdmi bindings to yaml
Current dts files with 'hdmi' nodes for rk3066 are manually verified.
In order to automate this process rockchip,rk3066-hdmi.txt
has to be converted to yaml.
Signed-off-by: Johan Jonker
---
Changes v2:
Fix irq.h already included in arm-gic.h
---
.../display/rockchip/rockchip,rk3066-hdmi.txt | 72 ---
.../display/rockchip/rockchip,rk3066-hdmi.yaml | 140 +
2 files changed, 140 insertions(+), 72 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/display/rockchip/rockchip,rk3066-hdmi.txt
create mode 100644
Documentation/devicetree/bindings/display/rockchip/rockchip,rk3066-hdmi.yaml
diff --git
a/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3066-hdmi.txt
b/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3066-hdmi.txt
deleted file mode 100644
index d1ad31bca..0
---
a/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3066-hdmi.txt
+++ /dev/null
@@ -1,72 +0,0 @@
-Rockchip specific extensions for rk3066 HDMI
-
-
-Required properties:
-- compatible:
- "rockchip,rk3066-hdmi";
-- reg:
- Physical base address and length of the controller's registers.
-- clocks, clock-names:
- Phandle to HDMI controller clock, name should be "hclk".
-- interrupts:
- HDMI interrupt number.
-- power-domains:
- Phandle to the RK3066_PD_VIO power domain.
-- rockchip,grf:
- This soc uses GRF regs to switch the HDMI TX input between vop0 and
vop1.
-- ports:
- Contains one port node with two endpoints, numbered 0 and 1,
- connected respectively to vop0 and vop1.
- Contains one port node with one endpoint
- connected to a hdmi-connector node.
-- pinctrl-0, pinctrl-name:
- Switch the iomux for the HPD/I2C pins to HDMI function.
-
-Example:
- hdmi: hdmi@10116000 {
- compatible = "rockchip,rk3066-hdmi";
- reg = <0x10116000 0x2000>;
- interrupts = ;
- clocks = < HCLK_HDMI>;
- clock-names = "hclk";
- power-domains = < RK3066_PD_VIO>;
- rockchip,grf = <>;
- pinctrl-names = "default";
- pinctrl-0 = <_xfer>, <_hpd>;
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
- hdmi_in: port@0 {
- reg = <0>;
- #address-cells = <1>;
- #size-cells = <0>;
- hdmi_in_vop0: endpoint@0 {
- reg = <0>;
- remote-endpoint = <_out_hdmi>;
- };
- hdmi_in_vop1: endpoint@1 {
- reg = <1>;
- remote-endpoint = <_out_hdmi>;
- };
- };
- hdmi_out: port@1 {
- reg = <1>;
- hdmi_out_con: endpoint {
- remote-endpoint = <_con_in>;
- };
- };
- };
- };
-
- {
- hdmi {
- hdmi_hpd: hdmi-hpd {
- rockchip,pins = <0 RK_PA0 1 _pull_default>;
- };
- hdmii2c_xfer: hdmii2c-xfer {
- rockchip,pins = <0 RK_PA1 1 _pull_none>,
- <0 RK_PA2 1 _pull_none>;
- };
- };
-};
diff --git
a/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3066-hdmi.yaml
b/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3066-hdmi.yaml
new file mode 100644
index 0..4110d003c
--- /dev/null
+++
b/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3066-hdmi.yaml
@@ -0,0 +1,140 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/rockchip/rockchip,rk3066-hdmi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip rk3066 HDMI controller
+
+maintainers:
+ - Sandy Huang
+ - Heiko Stuebner
+
+properties:
+ compatible:
+const: rockchip,rk3066-hdmi
+
+ reg:
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+ clocks:
+maxItems: 1
+
+ clock-names:
+const: hclk
+
+ pinctrl-0:
+maxItems: 2
+
+ pinctrl-names:
+const: default
+description:
+ Switch the iomux for the HPD/I2C pins to HDMI function.
+
+ power-domains:
+maxItems: 1
+
+ rockchip,grf:
+$ref: /schemas/types.yaml#/definitions/phandle
+description:
+ This soc uses GRF regs to switch the HDMI TX input between vop0 and vop1.
+
+ ports:
+type: object
+
+properties:
+
Re: [PATCH v3] drm/i915: Synchronize active and retire callbacks
On Fri, Apr 03, 2020 at 03:35:15PM -0700, Sultan Alsawaf wrote: > + ref->retire(ref); > + mutex_unlock(>callback_lock); Ugh, this patch is still wrong because the mutex unlock after ref->retire() is a use-after-free. Fun times... Sultan ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/1] lib/vsprintf: Add support for printing V4L2 and DRM fourccs
On Fri, Apr 03, 2020 at 01:19:26PM +0200, Mauro Carvalho Chehab wrote:
> Em Fri, 3 Apr 2020 13:47:02 +0300
> Sakari Ailus escreveu:
>
> > > > +static noinline_for_stack
> > > > +char *fourcc_string(char *buf, char *end, const u32 *fourcc,
> > > > + struct printf_spec spec, const char *fmt)
> > > > +{
> > > > +#define FOURCC_STRING_BE "-BE"
> > > > + char s[sizeof(*fourcc) + sizeof(FOURCC_STRING_BE)] = { 0 };
> > > > +
> > > > + if (check_pointer(, end, fourcc, spec))
> > > > + return buf;
> > > > +
> > > > + if (fmt[1] != 'c' || fmt[2] != 'c')
> > > > + return error_string(buf, end, "(%p4?)", spec);
> > > > +
> > > > + put_unaligned_le32(*fourcc & ~BIT(31), s);
> > > > +
> > > > + if (*fourcc & BIT(31))
> > > > + strscpy(s + sizeof(*fourcc), FOURCC_STRING_BE,
> > > > + sizeof(FOURCC_STRING_BE));
> > > > +
> > > > + return string(buf, end, s, spec);
> > >
> > > Taking V4L2_PIX_FMT_Y16_BE as an example, this will print 'Y16 -BE'
> > > (without quotes). There are other 4CCs that contain spaces and would
> > > suffer from a similar issue. Even in little-endian format, it would
> > > result in additional spaces in the output string. Is this what we want ?
> > > Should the caller always enclose the 4CC in quotes or brackets for
> > > clarity ? Or should still be done here ?
> >
> > Good question. Space is indeed a valid character in a 4cc code.
> >
> > If I omit one or more spaces, it will no longer be a 4cc, but a 3cc or even
> > a 2cc. Jokes aside, there are probably fair arguments both ways.
> >
> > I presume there's no 4cc code where the location of a space would make a
> > difference but all of the spaces are trailing spaces.
>
> Yes. I guess it doesn't make any sense to allow a 4cc code with an
> space before or in the middle.
>
> Btw, on a quick search at the Internet for non-Linux definitions,
> a Fourcc code "Y8 " is actually shown at the lists as just "Y8",
> e. g. removing the leading spaces:
>
> https://www.fourcc.org/codecs.php
> http://abcavi.kibi.ru/fourcc.php
>
> https://softron.zendesk.com/hc/en-us/articles/207695697-List-of-FourCC-codes-for-video-codecs
> https://www.free-codecs.com/guides/guides.php?f=fourcc
>
> One interesting detail there is that some tables show some codes
> like "BGR(15)". While I'm not sure how this is encoded, I suspect
> that the fourcc is actually "BGR\x15".
>
> We don't do that on V4L, nor we have plans to do so. Not sure if
> DRM would accept something like that. Of so, then the logic should
> have some special handler if the code is below 32.
It is easy to achieve I think, with help of string_escape*() functions.
> > It's also worth noting that the formats printed are mostly for debugging
> > purpose and thus even getting a hypothetical case wrong is not a grave
> > issue. This would also support just printing them as-is though.
> >
> > I'm leaning slightly towards omitting any spaces if the code has them.
>
> I would just remove trailing spaces, and then use a loop from the end
> to remove trailing spaces (and optionally handle codes ending with a
> value below 32, if are there any such case with DRM fourcc codes).
>
> On the other hand, I don't mind if you prefer to use just one for()
> loop and just trip any spaces inside it.
>
> > This is something that couldn't be done by using a macro...
>
> Well, I suspect that it might be possible to write a macro
> for doing that too, for example using preprocessor concatenation
> logic that could produce the same results. If you do something
> like that, however, I suspect that te macro would face some
> portability issues, as, as far as I know, not all C compilers
> would handle string concatenation the same way.
>
> Thanks,
> Mauro
--
With Best Regards,
Andy Shevchenko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: How to handle disconnection of eDP panels due to dynamic display mux switches
On 4/3/20 2:16 AM, Daniel Vetter wrote: On Fri, Apr 3, 2020 at 8:54 AM Daniel Dadap wrote: On 4/2/20 6:39 AM, Lukas Wunner wrote: On Fri, Mar 27, 2020 at 04:25:19PM -0500, Daniel Dadap wrote: A number of hybrid GPU notebook computer designs with dual (integrated plus discrete) GPUs are equipped with multiplexers (muxes) that allow display panels to be driven by either the integrated GPU or the discrete GPU. Typically, this is a selection that can be made at boot time as a menu option in the system firmware's setup screen, and the mux selection stays fixed for as long as the system is running and persists across reboots until it is explicitly changed. However, some muxed hybrid GPU systems have dynamically switchable muxes which can be switched while the system is running. As you may be aware, there's drivers/gpu/vga/vga_switcheroo.c (of which I'm listed as a reviewer in MAINTAINERS) to support such hardware. It also supports muxed configurations, including those that support switching at runtime (and not only at boot) such as the MacBook Pro, which uses drivers/platform/x86/apple-gmux.c to interface between vga_switcheroo and the hardware mux. However, so far switching only actually works on LVDS-based MacBook Pros, i.e. all pre-retina machines introduced between Late 2008 and Mid 2012, because that hardware is capable of switching the DDC pins separately from the display, so we lock and switch them when probing the EDID. I have observed that on at least some systems, the EDID for the internal panel can be read via the ACPI _DDC method regardless of whether it's actively muxed in. I don't know whether that's true for all systems where the DDC line can't be switched independently, but maybe vga_switcheroo could also export an interface for GPU drivers to cache EDIDs so that a muxed-away GPU can read an EDID that was previously read by another GPU? I guess the utility of that would depend on how prevalent the combination of no DDC muxing + no ACPI EDID reads turns out to be. The retina machines introduced from Mid 2012 onward use eDP and run into the issues you're describing: The AUX channel cannot be switched separately from the display, so link training fails unless the entire display is switched. Nevertheless macOS can switch the panel seamlessly. So how are they doing it? Well, I don't own a retina MacBook Pro, hence never got very far with supporting them, but I did some research and experiments in the 2015/2016 time frame which a colleague, Bruno Bierbaumer, tested on his machine: First of all, there's DPCD byte 3 bit 6 (NO_AUX_HANDSHAKE_LINK_TRAINING) which is documented as follows: Does not require AUX CH handshake when the link configuration is already known. [...] The known-good drive current and pre-emphasis level (or those used in the last "full" link training with AUX CH handshake) must be used when the link training is performed without AUX CH handshake. That bit is set on the MacBook Pros in question. I'll check one of the eDP-based systems I've been experimenting on to see if setting the VGA_SWITCHER_NEEDS_EDP_CONFIG capability in the handler is sufficient to make i915 avoid poking the AUX channel when it's mux-switched away. (This would be in addition to hacking the can_switch() callback in the GPU drivers to allow switching while there are still active KMS clients for the purposes of this experiment, unless somebody can point me to a tree with the WIP per-output switching Daniel Vetter mentioned. Two things: I thought (but not sure) that for the output switching muxes we'd run vgaswitcheroo in a different mode, where it doesn't check whether whether the driver can be killed. Because it wont. On a quick search only thing I've found is the ddc-only switching done by vga_switcheroo_lock/unlock_ddc. Maybe misremembering, but I thought there was more. But been a while I last looked at this all in detail. Wrt per-output switching WIP branch. That would be something you'd need to type ofc, I was just laying out what I think would make sense as a possible path to integrate this into upstream. -Daniel Okay. I misunderstood. When you said that vga-switcheroo could switch individual outputs and do so without powering down the switched-away-from GPU, I took that to mean that this feature had already been implemented somewhere, despite appearances to the contrary upstream. I agree that adding per-output switching support to vga-switcheroo would be a sensible path. Does this sound like a sensible high-level design? * vga-switcheroo-capable GPU drivers can register muxable outputs. * Each GPU driver must register each unique muxable output with the same identifier. The outputs will be registered together with individual devices they can be muxed to, in order to support e.g. muxing between different GPU devices driven by the same vendor. (I'm not aware of any designs that actually support this, but it seems reasonable to design
Re: [PATCH] drm/amd/display: Fix a compilation warning
> When I compile the code in X86,there is a warning about > "'PixelPTEReqHeightPTES' may be used uninitialized in this function". Would you like to add the tag “Fixes” to the commit message? Regards, Markus ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/5] video: Add missing annotation for cyber2000fb_enable_ddc() and cyber2000fb_disable_ddc()
Sparse reports warnings at cyber2000fb_enable_ddc()
and cyber2000fb_disable_ddc()
warning: context imbalance in cyber2000fb_enable_ddc()
- wrong count at exit
warning: context imbalance in cyber2000fb_disable_ddc()
- unexpected unlock
The root cause is the missing annotation at cyber2000fb_enable_ddc()
and cyber2000fb_disable_ddc()
Add the missing __acquires(>reg_b0_lock) annotation
Add the missing __releases(>reg_b0_lock) annotation
Signed-off-by: Jules Irenge
---
drivers/video/fbdev/cyber2000fb.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/video/fbdev/cyber2000fb.c
b/drivers/video/fbdev/cyber2000fb.c
index 460826a7ad55..513f58f28b0f 100644
--- a/drivers/video/fbdev/cyber2000fb.c
+++ b/drivers/video/fbdev/cyber2000fb.c
@@ -1160,12 +1160,14 @@ EXPORT_SYMBOL(cyber2000fb_detach);
#define DDC_SDA_IN (1 << 6)
static void cyber2000fb_enable_ddc(struct cfb_info *cfb)
+ __acquires(>reg_b0_lock)
{
spin_lock(>reg_b0_lock);
cyber2000fb_writew(0x1bf, 0x3ce, cfb);
}
static void cyber2000fb_disable_ddc(struct cfb_info *cfb)
+ __releases(>reg_b0_lock)
{
cyber2000fb_writew(0x0bf, 0x3ce, cfb);
spin_unlock(>reg_b0_lock);
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge: dw-mipi-dsi.c: Add VPG runtime config through debugfs
Hello Angelo,
I get a compile error: error: ‘VID_MODE_VPG_MODE’ undeclared. I am
quite new to the mailing list, maybe I misapplied the patch.
Regards,
Adrian
On Fri, Apr 3, 2020 at 6:37 PM Angelo Ribeiro
wrote:
>
> Add support for the video pattern generator (VPG) BER pattern mode and
> configuration in runtime.
>
> This enables using the debugfs interface to manipulate the VPG after
> the pipeline is set.
> Also, enables the usage of the VPG BER pattern.
>
> Cc: Gustavo Pimentel
> Cc: Joao Pinto
> Cc: Jose Abreu
> Signed-off-by: Angelo Ribeiro
> ---
> drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 97
> ---
> 1 file changed, 89 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> index b18351b..512c922 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> @@ -221,6 +221,21 @@
> #define PHY_STATUS_TIMEOUT_US 1
> #define CMD_PKT_STATUS_TIMEOUT_US 2
>
> +#ifdef CONFIG_DEBUG_FS
> +#define VPG_DEFS(name, dsi) \
> + ((void __force *)&((*dsi).vpg_defs.name))
> +
> +#define REGISTER(name, mask, dsi) \
> + { #name, VPG_DEFS(name, dsi), mask, dsi }
> +
> +struct debugfs_entries {
> + const char *name;
> + bool*reg;
> + u32 mask;
> + struct dw_mipi_dsi *dsi;
> +};
> +#endif /* CONFIG_DEBUG_FS */
> +
> struct dw_mipi_dsi {
> struct drm_bridge bridge;
> struct mipi_dsi_host dsi_host;
> @@ -238,9 +253,12 @@ struct dw_mipi_dsi {
>
> #ifdef CONFIG_DEBUG_FS
> struct dentry *debugfs;
> -
> - bool vpg;
> - bool vpg_horizontal;
> + struct debugfs_entries *debugfs_vpg;
> + struct {
> + bool vpg;
> + bool vpg_horizontal;
> + bool vpg_ber_pattern;
> + } vpg_defs;
> #endif /* CONFIG_DEBUG_FS */
>
> struct dw_mipi_dsi *master; /* dual-dsi master ptr */
> @@ -530,9 +548,11 @@ static void dw_mipi_dsi_video_mode_config(struct
> dw_mipi_dsi *dsi)
> val |= VID_MODE_TYPE_NON_BURST_SYNC_EVENTS;
>
> #ifdef CONFIG_DEBUG_FS
> - if (dsi->vpg) {
> + if (dsi->vpg_defs.vpg) {
> val |= VID_MODE_VPG_ENABLE;
> - val |= dsi->vpg_horizontal ? VID_MODE_VPG_HORIZONTAL : 0;
> + val |= dsi->vpg_defs.vpg_horizontal ?
> + VID_MODE_VPG_HORIZONTAL : 0;
> + val |= dsi->vpg_defs.vpg_ber_pattern ? VID_MODE_VPG_MODE : 0;
> }
> #endif /* CONFIG_DEBUG_FS */
>
> @@ -961,6 +981,68 @@ static const struct drm_bridge_funcs
> dw_mipi_dsi_bridge_funcs = {
>
> #ifdef CONFIG_DEBUG_FS
>
> +ssize_t dw_mipi_dsi_debugfs_write(void *data, u64 val)
> +{
> + struct debugfs_entries *vpg = data;
> + struct dw_mipi_dsi *dsi;
> + u32 mode_cfg;
> +
> + if (!vpg)
> + return -ENODEV;
> +
> + dsi = vpg->dsi;
> +
> + *vpg->reg = (bool)val;
> +
> + mode_cfg = dsi_read(dsi, DSI_VID_MODE_CFG);
> +
> + if (*vpg->reg)
> + mode_cfg |= vpg->mask;
> + else
> + mode_cfg &= ~vpg->mask;
> +
> + dsi_write(dsi, DSI_VID_MODE_CFG, mode_cfg);
> +
> + return 0;
> +}
> +
> +ssize_t dw_mipi_dsi_debugfs_show(void *data, u64 *val)
> +{
> + struct debugfs_entries *vpg = data;
> +
> + if (!vpg)
> + return -ENODEV;
> +
> + *val = *vpg->reg;
> +
> + return 0;
> +}
> +
> +DEFINE_DEBUGFS_ATTRIBUTE(fops_x32, dw_mipi_dsi_debugfs_show,
> +dw_mipi_dsi_debugfs_write, "%llu\n");
> +
> +static void debugfs_create_files(void *data)
> +{
> + struct dw_mipi_dsi *dsi = data;
> + struct debugfs_entries debugfs[] = {
> + REGISTER(vpg, VID_MODE_VPG_ENABLE, dsi),
> + REGISTER(vpg_horizontal, VID_MODE_VPG_HORIZONTAL, dsi),
> + REGISTER(vpg_ber_pattern, VID_MODE_VPG_MODE, dsi),
> + };
> + int i;
> +
> + dsi->debugfs_vpg = kmalloc(sizeof(debugfs), GFP_KERNEL);
> + if (!dsi->debugfs_vpg)
> + return;
> +
> + memcpy(dsi->debugfs_vpg, debugfs, sizeof(debugfs));
> +
> + for (i = 0; i < ARRAY_SIZE(debugfs); i++)
> + debugfs_create_file(dsi->debugfs_vpg[i].name, 0644,
> + dsi->debugfs, >debugfs_vpg[i],
> + _x32);
> +}
> +
> static void dw_mipi_dsi_debugfs_init(struct dw_mipi_dsi *dsi)
> {
> dsi->debugfs = debugfs_create_dir(dev_name(dsi->dev), NULL);
> @@ -969,14 +1051,13 @@ static void dw_mipi_dsi_debugfs_init(struct
> dw_mipi_dsi *dsi)
> return;
> }
>
> - debugfs_create_bool("vpg", 0660, dsi->debugfs, >vpg);
> - debugfs_create_bool("vpg_horizontal",
[PATCH v5 1/2] dt-bindings: display: convert rockchip vop bindings to yaml
Current dts files with 'vop' nodes are manually verified.
In order to automate this process rockchip-vop.txt
has to be converted to yaml.
Signed-off-by: Johan Jonker
Reviewed-by: Rob Herring
---
Changes v5:
Add reviewed by
Fix irq.h already included in arm-gic.h
Changes v4:
Change description
Replace compatible oneOf by enum
Change interrupts description
Remove resets minItems
Changes v3:
Change description
Changes v2:
No new properties
---
.../bindings/display/rockchip/rockchip-vop.txt | 74 -
.../bindings/display/rockchip/rockchip-vop.yaml| 123 +
2 files changed, 123 insertions(+), 74 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt
create mode 100644
Documentation/devicetree/bindings/display/rockchip/rockchip-vop.yaml
diff --git
a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt
b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt
deleted file mode 100644
index 8b3a5f514..0
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt
+++ /dev/null
@@ -1,74 +0,0 @@
-device-tree bindings for rockchip soc display controller (vop)
-
-VOP (Visual Output Processor) is the Display Controller for the Rockchip
-series of SoCs which transfers the image data from a video memory
-buffer to an external LCD interface.
-
-Required properties:
-- compatible: value should be one of the following
- "rockchip,rk3036-vop";
- "rockchip,rk3126-vop";
- "rockchip,px30-vop-lit";
- "rockchip,px30-vop-big";
- "rockchip,rk3066-vop";
- "rockchip,rk3188-vop";
- "rockchip,rk3288-vop";
- "rockchip,rk3368-vop";
- "rockchip,rk3366-vop";
- "rockchip,rk3399-vop-big";
- "rockchip,rk3399-vop-lit";
- "rockchip,rk3228-vop";
- "rockchip,rk3328-vop";
-
-- reg: Must contain one entry corresponding to the base address and length
- of the register space. Can optionally contain a second entry
- corresponding to the CRTC gamma LUT address.
-
-- interrupts: should contain a list of all VOP IP block interrupts in the
-order: VSYNC, LCD_SYSTEM. The interrupt specifier
-format depends on the interrupt controller used.
-
-- clocks: must include clock specifiers corresponding to entries in the
- clock-names property.
-
-- clock-names: Must contain
- aclk_vop: for ddr buffer transfer.
- hclk_vop: for ahb bus to R/W the phy regs.
- dclk_vop: pixel clock.
-
-- resets: Must contain an entry for each entry in reset-names.
- See ../reset/reset.txt for details.
-- reset-names: Must include the following entries:
- - axi
- - ahb
- - dclk
-
-- iommus: required a iommu node
-
-- port: A port node with endpoint definitions as defined in
- Documentation/devicetree/bindings/media/video-interfaces.txt.
-
-Example:
-SoC specific DT entry:
- vopb: vopb@ff93 {
- compatible = "rockchip,rk3288-vop";
- reg = <0x0 0xff93 0x0 0x19c>, <0x0 0xff931000 0x0 0x1000>;
- interrupts = ;
- clocks = < ACLK_VOP0>, < DCLK_VOP0>, < HCLK_VOP0>;
- clock-names = "aclk_vop", "dclk_vop", "hclk_vop";
- resets = < SRST_LCDC1_AXI>, < SRST_LCDC1_AHB>, <
SRST_LCDC1_DCLK>;
- reset-names = "axi", "ahb", "dclk";
- iommus = <_mmu>;
- vopb_out: port {
- #address-cells = <1>;
- #size-cells = <0>;
- vopb_out_edp: endpoint@0 {
- reg = <0>;
- remote-endpoint=<_in_vopb>;
- };
- vopb_out_hdmi: endpoint@1 {
- reg = <1>;
- remote-endpoint=<_in_vopb>;
- };
- };
- };
diff --git
a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.yaml
b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.yaml
new file mode 100644
index 0..42ee2b5c3
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.yaml
@@ -0,0 +1,123 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/rockchip/rockchip-vop.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip SoC display controller (VOP)
+
+description:
+ VOP (Video Output Processor) is the display controller for the Rockchip
+ series of SoCs which transfers the image data from a video memory
+ buffer to an external LCD interface.
+
+maintainers:
+ - Sandy Huang
+ - Heiko Stuebner
+
+properties:
+ compatible:
+enum:
+ - rockchip,px30-vop-big
+ - rockchip,px30-vop-lit
+
Re: lima, panfrost: multiple definition of `of_devfreq_cooling_register_power'
On Thu, Apr 2, 2020 at 9:46 AM Thomas Zimmermann wrote: > > Hi Martin > > Am 02.04.20 um 09:39 schrieb Martin Blumenstingl: > > Hi Thomas, > > > > On Thu, Apr 2, 2020 at 9:26 AM Thomas Zimmermann > > wrote: > >> > >> Hi, > >> > >> building lima and panfrost drivers from drm-tip, I currently get the > >> following linker error > >> > >> > make clean > >> > make > >> [...] > >> LD vmlinux.o > >> arm-suse-linux-gnueabi-ld: drivers/gpu/drm/panfrost > >> /panfrost_devfreq.o: in function > >> `of_devfreq_cooling_register_power': > >> panfrost_devfreq.c:(.text+0x18c): multiple definition of > >> `of_devfreq_cooling_register_power'; drivers/gpu/drm/lima > >> /lima_devfreq.o:lima_devfreq.c:(.text+0x1a0): first defined here > >> make[1]: *** [/home/tzimmermann/Projekte/linux/Makefile:1078: vmlinux] > >> Error 1 > >> make[1]: Leaving directory '/home/tzimmermann/Projekte/linux/build- > >> arm' > >> make: *** [Makefile:180: sub-make] Error 2 > > can you please try building again with the attached patch? > > Yes, fixes the bug. Thanks for responding quickly. I just sent a fix to the correct mailing lists: [0] it would be awesome if you could give it your "Tested-by" Regards Martin [0] https://lore.kernel.org/patchwork/patch/1220292/ ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V4 3/4] backlight: qcom-wled: Add WLED5 bindings
On 2020-03-31 23:26, Rob Herring wrote: On Mon, Mar 23, 2020 at 11:16:57PM +0530, Kiran Gunda wrote: Add WLED5 specific bindings. More of the same comments here... Signed-off-by: Kiran Gunda Signed-off-by: Subbaraman Narayanamurthy --- .../bindings/leds/backlight/qcom-wled.yaml | 39 ++ 1 file changed, 39 insertions(+) diff --git a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml index 8a388bf..159115f 100644 --- a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml +++ b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml @@ -20,6 +20,7 @@ properties: - qcom,pm8941-wled - qcom,pmi8998-wled - qcom,pm660l-wled + - qcom,pm8150l-wled reg: maxItems: 1 @@ -28,10 +29,23 @@ properties: maxItems: 1 description: brightness value on boot, value from 0-4095. + For pm8150l this value vary from 0-4095 or 0-32767 + depending on the brightness control mode. If CABC is + enabled 0-4095 range is used. Constraints. Will address it in next post. allOf: - $ref: /schemas/types.yaml#/definitions/uint32 default: 2048 + max-brightness: +maxItems: 1 +description: + Maximum brightness level. Allowed values are, + for pmi8998 it is 0-4095. + For pm8150l, this can be either 4095 or 32767. Constraints! Will address it in next post. + If CABC is enabled, this is capped to 4095. +allOf: + - $ref: /schemas/types.yaml#/definitions/uint32 Standard property. Assume it has a type definition.' Will address it in next post. + label: maxItems: 1 description: @@ -124,6 +138,31 @@ properties: value for PM8941 from 1 to 3. Default 2 For PMI8998 from 1 to 4. + qcom,modulator-sel: +maxItems: 1 +allOf: + - $ref: /schemas/types.yaml#/definitions/uint32 +description: + Selects the modulator used for brightness modulation. + Allowed values are, + 0 - Modulator A + 1 - Modulator B + If not specified, then modulator A will be used by default. + This property is applicable only to WLED5 peripheral. + + qcom,cabc-sel: +maxItems: 1 +allOf: + - $ref: /schemas/types.yaml#/definitions/uint32 +description: + Selects the CABC pin signal used for brightness modulation. + Allowed values are, + 0 - CABC disabled + 1 - CABC 1 + 2 - CABC 2 + 3 - External signal (e.g. LPG) is used for dimming + This property is applicable only to WLED5 peripheral. + interrupts: maxItems: 2 description: -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amdgpu: Fix oops when pp_funcs is unset in ACPI event
On ARCTURUS and RENOIR, powerplay is not supported yet. When plug in or unplug power jack, ACPI event will issue. Then kernel NULL pointer BUG will be triggered. Check for NULL pointers before calling. Signed-off-by: Aaron Ma --- drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c index f197f1be0969..611de69f9d48 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c @@ -89,7 +89,8 @@ void amdgpu_pm_acpi_event_handler(struct amdgpu_device *adev) adev->pm.ac_power = true; else adev->pm.ac_power = false; - if (adev->powerplay.pp_funcs->enable_bapm) + if (adev->powerplay.pp_funcs && + adev->powerplay.pp_funcs->enable_bapm) amdgpu_dpm_enable_bapm(adev, adev->pm.ac_power); mutex_unlock(>pm.mutex); -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V4 1/4] backlight: qcom-wled: convert the wled bindings to .yaml format
On 2020-03-31 23:24, Rob Herring wrote: On Mon, Mar 23, 2020 at 11:16:55PM +0530, Kiran Gunda wrote: Convert the qcom-wled bindings from .txt to .yaml format. Signed-off-by: Kiran Gunda Signed-off-by: Subbaraman Narayanamurthy Acked-by: Daniel Thompson --- .../bindings/leds/backlight/qcom-wled.txt | 154 - .../bindings/leds/backlight/qcom-wled.yaml | 184 + 2 files changed, 184 insertions(+), 154 deletions(-) delete mode 100644 Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt create mode 100644 Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml diff --git a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml new file mode 100644 index 000..8a388bf --- /dev/null +++ b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml @@ -0,0 +1,184 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/leds/backlight/qcom-wled.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Binding for Qualcomm Technologies, Inc. WLED driver + +maintainers: + - Lee Jones Should be the h/w owner (you), not who applies patches. will address in next post. + +description: | + WLED (White Light Emitting Diode) driver is used for controlling display + backlight that is part of PMIC on Qualcomm Technologies, Inc. reference + platforms. The PMIC is connected to the host processor via SPMI bus. + +properties: + compatible : Drop the space ^ will address in next post. +enum: + - qcom,pm8941-wled + - qcom,pmi8998-wled + - qcom,pm660l-wled Wrong indent (1 space too many). will address in next post. + + reg: +maxItems: 1 + + default-brightness: +maxItems: 1 maxItems is for arrays and this is a single scalar. +description: + brightness value on boot, value from 0-4095. 0-4095 sounds like a constraint. will address in next post. +allOf: + - $ref: /schemas/types.yaml#/definitions/uint32 There should be a common definition for this. will address in next post. +default: 2048 + + label: +maxItems: 1 +description: + The name of the backlight device. +allOf: + - $ref: /schemas/types.yaml#/definitions/string Already has a type. Just 'label: true' is enough. will address in next post. + + qcom,cs-out: +description: + enable current sink output. + This property is supported only for PM8941. +type: boolean + + qcom,cabc: +description: + enable content adaptive backlight control. +type: boolean + + qcom,ext-gen: +description: + use externally generated modulator signal to dim. + This property is supported only for PM8941. +type: boolean + + qcom,current-limit: +maxItems: 1 Not an array. will address in next post. +allOf: + - $ref: /schemas/types.yaml#/definitions/uint32 +description: + mA; per-string current limit; value from 0 to 25 with 25 sounds like a constraint. will address in next post. + 1 mA step. This property is supported only for pm8941. +default: 20 + + qcom,current-limit-microamp: +maxItems: 1 +allOf: + - $ref: /schemas/types.yaml#/definitions/uint32 properties with unit suffix already have a type. will address in next post. +description: + uA; per-string current limit; value from 0 to 3 with + 2500 uA step. steps can be expressed using 'multipleOf' will address in next post. +default: 25 25 can never be a multiple of 2500 will correct in next post. + + qcom,current-boost-limit: +maxItems: 1 +allOf: + - $ref: /schemas/types.yaml#/definitions/uint32 +description: + mA; boost current limit. + For pm8941 one of 105, 385, 525, 805, 980, 1260, 1400, 1680. + Default, 805 mA. + For pmi8998 one of 105, 280, 450, 620, 970, 1150, 1300, + 1500. Default 970 mA. Constraints. will address in next post. + + qcom,switching-freq: +maxItems: 1 +allOf: + - $ref: /schemas/types.yaml#/definitions/uint32 +description: + kHz; switching frequency; one of 600, 640, 685, 738, + 800, 872, 960, 1066, 1200, 1371, 1600, 1920, 2400, 3200, + 4800, 9600. + Default for pm8941 1600 kHz + for pmi8998 800 kHz Constraints! will address in next post. + + qcom,ovp: +maxItems: 1 +allOf: + - $ref: /schemas/types.yaml#/definitions/uint32 +description: + V; Over-voltage protection limit; one of 27, 29, 32, 35. Default 29V + This property is supported only for PM8941. + + qcom,ovp-millivolt: +maxItems: 1 +allOf: + - $ref: /schemas/types.yaml#/definitions/uint32 +description: + mV; Over-voltage protection limit; + For pmi8998 one of 18100, 19600, 29600, 31100. + Default 29600 mV. + If this property is not
Re: [PATCH v2 1/1] lib/vsprintf: Add support for printing V4L2 and DRM fourccs
On 03/04/2020 11.11, Sakari Ailus wrote:
> Add a printk modifier %ppf (for pixel format) for printing V4L2 and DRM
> pixel formats denoted by 4ccs. The 4cc encoding is the same for both so
> the same implementation can be used.
This seems quite niche to me, I'm not sure that belongs in vsprintf.c.
What's wrong with having a
char *fourcc_string(char *buf, u32 x)
that formats x into buf and returns buf, so it can be used in a
char buf[8];
pr_debug("bla: %s\n", fourcc_string(buf, x))
Or, for that matter, since it's for debugging, why not just print x with
0x%08x?
At the very least, the "case '4'" in pointer() should be guarded by
appropriate CONFIG_*.
Good that Documentation/ gets updated, but test_printf needs updating as
well.
> Suggested-by: Mauro Carvalho Chehab
> Signed-off-by: Sakari Ailus
> ---
> since v1:
>
> - Improve documentation (add -BE suffix, refer to "FourCC".
>
> - Use '%p4cc' conversion specifier instead of '%ppf'.
Cute. Remember to update the commit log (which still says %ppf).
> - Fix 31st bit handling in printing FourCC codes.
>
> - Use string() correctly, to allow e.g. proper field width handling.
>
> - Remove loop, use put_unaligned_le32() instead.
>
> Documentation/core-api/printk-formats.rst | 12 +++
> lib/vsprintf.c| 25 +++
> 2 files changed, 37 insertions(+)
>
> diff --git a/Documentation/core-api/printk-formats.rst
> b/Documentation/core-api/printk-formats.rst
> index 8ebe46b1af39..550568520ab6 100644
> --- a/Documentation/core-api/printk-formats.rst
> +++ b/Documentation/core-api/printk-formats.rst
> @@ -545,6 +545,18 @@ For printing netdev_features_t.
>
> Passed by reference.
>
> +V4L2 and DRM FourCC code (pixel format)
> +---
> +
> +::
> +
> + %p4cc
> +
> +Print a FourCC code used by V4L2 or DRM. The "-BE" suffix is added on big
> endian
> +formats.
> +
> +Passed by reference.
Maybe it's obvious to anyone in that business, but perhaps make it more
clear the 4cc is stored in a u32 (and not, e.g., a __le32 or some other
integer), that obviously matters when the code treats the pointer as a u32*.
> +
> + put_unaligned_le32(*fourcc & ~BIT(31), s);
> +
> + if (*fourcc & BIT(31))
> + strscpy(s + sizeof(*fourcc), FOURCC_STRING_BE,
> + sizeof(FOURCC_STRING_BE));
put_unaligned_le32(0x0045422d, s + 4) probably generates smaller code,
and is more in line with building the first part of the string with
put_unaligned_le32().
Rasmus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 2/2] dt-bindings: display: rockchip-vop: add additional properties
In the old txt situation we add/describe only properties that are used
by the driver/hardware itself. With yaml it also filters things in a
node that are used by other drivers like 'assigned-clocks' and
'assigned-clock-rates' for rk3399 and 'power-domains' for most
Rockchip Socs in 'vop' nodes, so add them to 'rockchip-vop.yaml'.
Signed-off-by: Johan Jonker
Reviewed-by: Rob Herring
---
Changes v5:
Add reviewed by
---
.../devicetree/bindings/display/rockchip/rockchip-vop.yaml| 11 +++
1 file changed, 11 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.yaml
b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.yaml
index 42ee2b5c3..1695e3e4b 100644
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.yaml
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.yaml
@@ -75,9 +75,18 @@ properties:
A port node with endpoint definitions as defined in
Documentation/devicetree/bindings/media/video-interfaces.txt.
+ assigned-clocks:
+maxItems: 2
+
+ assigned-clock-rates:
+maxItems: 2
+
iommus:
maxItems: 1
+ power-domains:
+maxItems: 1
+
required:
- compatible
- reg
@@ -94,6 +103,7 @@ examples:
- |
#include
#include
+#include
vopb: vopb@ff93 {
compatible = "rockchip,rk3288-vop";
reg = <0x0 0xff93 0x0 0x19c>,
@@ -103,6 +113,7 @@ examples:
< DCLK_VOP0>,
< HCLK_VOP0>;
clock-names = "aclk_vop", "dclk_vop", "hclk_vop";
+ power-domains = < RK3288_PD_VIO>;
resets = < SRST_LCDC1_AXI>,
< SRST_LCDC1_AHB>,
< SRST_LCDC1_DCLK>;
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/bridge: dw-mipi-dsi.c: remove unused header file
dw-mipi-dsi does not use any definition from drm_probe_helper. Coverity output: Event unnecessary_header: Including .../include/drm/drm_probe_helper.h does not provide any needed symbols. Cc: Gustavo Pimentel Cc: Joao Pinto Cc: Jose Abreu Signed-off-by: Angelo Ribeiro --- drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c index 024acad..582635d 100644 --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c @@ -27,7 +27,6 @@ #include #include #include -#include #define HWVER_131 0x31333100 /* IP version 1.31 */ -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/1] lib/vsprintf: Add support for printing V4L2 and DRM fourccs
On Fri, Apr 03, 2020 at 12:11:56PM +0300, Sakari Ailus wrote:
> Add a printk modifier %ppf (for pixel format) for printing V4L2 and DRM
> pixel formats denoted by 4ccs. The 4cc encoding is the same for both so
> the same implementation can be used.
...
> +static noinline_for_stack
> +char *fourcc_string(char *buf, char *end, const u32 *fourcc,
> + struct printf_spec spec, const char *fmt)
> +{
> +#define FOURCC_STRING_BE "-BE"
> + char s[sizeof(*fourcc) + sizeof(FOURCC_STRING_BE)] = { 0 };
I guess it makes it too complicated.
char s[8];
> + if (check_pointer(, end, fourcc, spec))
> + return buf;
> +
> + if (fmt[1] != 'c' || fmt[2] != 'c')
> + return error_string(buf, end, "(%p4?)", spec);
> +
> + put_unaligned_le32(*fourcc & ~BIT(31), s);
Can you elaborate what the difference in output with this bit set over cleared?
I.o.w. why don't we need to put it as BE and for LE case addd "-LE"?
> + if (*fourcc & BIT(31))
> + strscpy(s + sizeof(*fourcc), FOURCC_STRING_BE,
> + sizeof(FOURCC_STRING_BE));
We know the size, and we may put '\0' as well
if (*fourcc & BIT(31))
strscpy([4], "-BE", sizeof("-BE"));
else
strscpy([4], "", sizeof(""));
> + return string(buf, end, s, spec);
> +}
--
With Best Regards,
Andy Shevchenko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Aliases for DRI connectors?
Hi Pekka, El vie., 3 abr. 2020 a las 10:14, Pekka Paalanen () escribió: > > On Wed, 1 Apr 2020 14:38:37 -0500 > Matt Hoosier wrote: > > > I'm searching for some sort of scheme that will let my DRI master query the > > set of available connectors and select the one carrying a prearranged > > designation. The problem I'm trying to solve is to allow deploying one > > standardized userspace component across a fleet of devices that have > > varying numbers of displays, with the use cases not always driven on the > > same connector topologically. > > > > I had a look around the properties available on my system's DRI connectors, > > and nothing immediate jumped out at me. Is there a standard connector > > property that (assuming I can find the right place in DeviceTree or similar > > to) that would be a good fit for this? > > Hi, > > I've never heard of a thing that could accomplish that. DRM connector > names are not even actually communicated to userspace. What userspace > sees is connector type (enum) and some counter numbers (which are not > persistent, so not reliable if you have e.g. multiple DRM drivers > racing to initialize), I may be misreading you, but does this mean that the connector names used in the [output] section of the weston.ini configuration file are not reliable? Then what is the proper way to configure one specific (physical) output in Weston? BR, Guillermo > and then userspace manufactures a connector name > from those. This has been most painful with Xorg, where the different > video DDX drivers used to use different conventions in making up the > names, meaning that if you switched DDXes (e.g. between driver-specific > driver and modesetting driver), the connector names changed > invalidating your xorg.conf. > > However, the problem of non-persistent connector names has been thought > of, see e.g.: > https://lists.freedesktop.org/archives/dri-devel/2019-June/221902.html > The thread has messages also in July and August. > > If you had reliable, persistent connector names (and used e.g. device > path from udev to reliably identify DRM devices), maybe you could build > something on top of that? > > Though I doubt if maintainers would like your config to be in DT or > kernel, maybe it needs to be handled in userspace? > > > Thanks, > pq > ___ > wayland-devel mailing list > wayland-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/bridge: dw-mipi-dsi.c: Add VPG runtime config through debugfs
Add support for the video pattern generator (VPG) BER pattern mode and
configuration in runtime.
This enables using the debugfs interface to manipulate the VPG after
the pipeline is set.
Also, enables the usage of the VPG BER pattern.
Cc: Gustavo Pimentel
Cc: Joao Pinto
Cc: Jose Abreu
Signed-off-by: Angelo Ribeiro
---
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 97 ---
1 file changed, 89 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
index b18351b..512c922 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
@@ -221,6 +221,21 @@
#define PHY_STATUS_TIMEOUT_US 1
#define CMD_PKT_STATUS_TIMEOUT_US 2
+#ifdef CONFIG_DEBUG_FS
+#define VPG_DEFS(name, dsi) \
+ ((void __force *)&((*dsi).vpg_defs.name))
+
+#define REGISTER(name, mask, dsi) \
+ { #name, VPG_DEFS(name, dsi), mask, dsi }
+
+struct debugfs_entries {
+ const char *name;
+ bool*reg;
+ u32 mask;
+ struct dw_mipi_dsi *dsi;
+};
+#endif /* CONFIG_DEBUG_FS */
+
struct dw_mipi_dsi {
struct drm_bridge bridge;
struct mipi_dsi_host dsi_host;
@@ -238,9 +253,12 @@ struct dw_mipi_dsi {
#ifdef CONFIG_DEBUG_FS
struct dentry *debugfs;
-
- bool vpg;
- bool vpg_horizontal;
+ struct debugfs_entries *debugfs_vpg;
+ struct {
+ bool vpg;
+ bool vpg_horizontal;
+ bool vpg_ber_pattern;
+ } vpg_defs;
#endif /* CONFIG_DEBUG_FS */
struct dw_mipi_dsi *master; /* dual-dsi master ptr */
@@ -530,9 +548,11 @@ static void dw_mipi_dsi_video_mode_config(struct
dw_mipi_dsi *dsi)
val |= VID_MODE_TYPE_NON_BURST_SYNC_EVENTS;
#ifdef CONFIG_DEBUG_FS
- if (dsi->vpg) {
+ if (dsi->vpg_defs.vpg) {
val |= VID_MODE_VPG_ENABLE;
- val |= dsi->vpg_horizontal ? VID_MODE_VPG_HORIZONTAL : 0;
+ val |= dsi->vpg_defs.vpg_horizontal ?
+ VID_MODE_VPG_HORIZONTAL : 0;
+ val |= dsi->vpg_defs.vpg_ber_pattern ? VID_MODE_VPG_MODE : 0;
}
#endif /* CONFIG_DEBUG_FS */
@@ -961,6 +981,68 @@ static const struct drm_bridge_funcs
dw_mipi_dsi_bridge_funcs = {
#ifdef CONFIG_DEBUG_FS
+ssize_t dw_mipi_dsi_debugfs_write(void *data, u64 val)
+{
+ struct debugfs_entries *vpg = data;
+ struct dw_mipi_dsi *dsi;
+ u32 mode_cfg;
+
+ if (!vpg)
+ return -ENODEV;
+
+ dsi = vpg->dsi;
+
+ *vpg->reg = (bool)val;
+
+ mode_cfg = dsi_read(dsi, DSI_VID_MODE_CFG);
+
+ if (*vpg->reg)
+ mode_cfg |= vpg->mask;
+ else
+ mode_cfg &= ~vpg->mask;
+
+ dsi_write(dsi, DSI_VID_MODE_CFG, mode_cfg);
+
+ return 0;
+}
+
+ssize_t dw_mipi_dsi_debugfs_show(void *data, u64 *val)
+{
+ struct debugfs_entries *vpg = data;
+
+ if (!vpg)
+ return -ENODEV;
+
+ *val = *vpg->reg;
+
+ return 0;
+}
+
+DEFINE_DEBUGFS_ATTRIBUTE(fops_x32, dw_mipi_dsi_debugfs_show,
+dw_mipi_dsi_debugfs_write, "%llu\n");
+
+static void debugfs_create_files(void *data)
+{
+ struct dw_mipi_dsi *dsi = data;
+ struct debugfs_entries debugfs[] = {
+ REGISTER(vpg, VID_MODE_VPG_ENABLE, dsi),
+ REGISTER(vpg_horizontal, VID_MODE_VPG_HORIZONTAL, dsi),
+ REGISTER(vpg_ber_pattern, VID_MODE_VPG_MODE, dsi),
+ };
+ int i;
+
+ dsi->debugfs_vpg = kmalloc(sizeof(debugfs), GFP_KERNEL);
+ if (!dsi->debugfs_vpg)
+ return;
+
+ memcpy(dsi->debugfs_vpg, debugfs, sizeof(debugfs));
+
+ for (i = 0; i < ARRAY_SIZE(debugfs); i++)
+ debugfs_create_file(dsi->debugfs_vpg[i].name, 0644,
+ dsi->debugfs, >debugfs_vpg[i],
+ _x32);
+}
+
static void dw_mipi_dsi_debugfs_init(struct dw_mipi_dsi *dsi)
{
dsi->debugfs = debugfs_create_dir(dev_name(dsi->dev), NULL);
@@ -969,14 +1051,13 @@ static void dw_mipi_dsi_debugfs_init(struct dw_mipi_dsi
*dsi)
return;
}
- debugfs_create_bool("vpg", 0660, dsi->debugfs, >vpg);
- debugfs_create_bool("vpg_horizontal", 0660, dsi->debugfs,
- >vpg_horizontal);
+ debugfs_create_files(dsi);
}
static void dw_mipi_dsi_debugfs_remove(struct dw_mipi_dsi *dsi)
{
debugfs_remove_recursive(dsi->debugfs);
+ kfree(dsi->debugfs_vpg);
}
#else
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/1] lib/vsprintf: Add support for printing V4L2 and DRM fourccs
On Fri, Apr 03, 2020 at 12:39:16PM +0300, Sakari Ailus wrote:
> On Fri, Apr 03, 2020 at 12:31:03PM +0300, Andy Shevchenko wrote:
> > On Fri, Apr 03, 2020 at 12:11:56PM +0300, Sakari Ailus wrote:
> > > Add a printk modifier %ppf (for pixel format) for printing V4L2 and DRM
> > > pixel formats denoted by 4ccs. The 4cc encoding is the same for both so
> > > the same implementation can be used.
> >
> > ...
> >
> > > +static noinline_for_stack
> > > +char *fourcc_string(char *buf, char *end, const u32 *fourcc,
> > > + struct printf_spec spec, const char *fmt)
> > > +{
> >
> > > +#define FOURCC_STRING_BE "-BE"
> > > + char s[sizeof(*fourcc) + sizeof(FOURCC_STRING_BE)] = { 0 };
> >
> > I guess it makes it too complicated.
>
> The above also clearly binds the size to the data that is expected to
> contain there. I'd prefer keeping it as-is. And yes, 8 would be correct,
> too.
OK.
> > char s[8];
> >
> > > + if (check_pointer(, end, fourcc, spec))
> > > + return buf;
> > > +
> > > + if (fmt[1] != 'c' || fmt[2] != 'c')
> > > + return error_string(buf, end, "(%p4?)", spec);
> > > +
> >
> > > + put_unaligned_le32(*fourcc & ~BIT(31), s);
> >
> > Can you elaborate what the difference in output with this bit set over
> > cleared?
> > I.o.w. why don't we need to put it as BE and for LE case addd "-LE"?
>
> The established practice is that big endian formats have "-BE" suffix
> whereas the little endian ones have nothing. (At least when it comes to
> V4L2.)
What I meant by the first part of the question is ordering of the characters.
That ordering of characters is not related to that flag, correct? So, bit
actually defines the endianess of the data in the certain fourcc.
Probably you need to put a comment to explain this.
> > > + if (*fourcc & BIT(31))
> > > + strscpy(s + sizeof(*fourcc), FOURCC_STRING_BE,
> > > + sizeof(FOURCC_STRING_BE));
> >
> > We know the size, and we may put '\0' as well
> > if (*fourcc & BIT(31))
> > strscpy([4], "-BE", sizeof("-BE"));
> > else
> > strscpy([4], "", sizeof(""));
>
> The rest of the struct memory has already been set to zero in variable
> declaration.
Which is bogus in my opinion. strscpy() or direct '\0' termination will put it
more explicit.
--
With Best Regards,
Andy Shevchenko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[drm-tip:drm-tip 9/10] drivers/staging/rtl8712/rtl8712_xmit.c:360:18: error: incompatible pointer types initializing 'struct tx_desc *' with an expression of type 'u8 *' (aka 'unsigned char *')
Hi Ville, First bad commit (maybe != root cause): tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip head: 06ddf8dd059d59bc27c24b09a6e500809e619982 commit: 02f01c7089f8aadbf676f8d8aad6e0bccac8c46a [9/10] Merge remote-tracking branch 'drm_intel_push/topic/core-for-CI' into drm-tip config: x86_64-allyesconfig (attached as .config) compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project b7397e81fe4dee8ffd4a1353bf0cf3a7d2ed267b) reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout 02f01c7089f8aadbf676f8d8aad6e0bccac8c46a # save the attached .config to linux build tree COMPILER=clang make.cross ARCH=x86_64 If you fix the issue, kindly add following tag as appropriate Reported-by: kbuild test robot All errors (new ones prefixed by >>): >> drivers/staging/rtl8712/rtl8712_xmit.c:360:18: error: incompatible pointer >> types initializing 'struct tx_desc *' with an expression of type 'u8 *' (aka >> 'unsigned char *') [-Werror,-Wincompatible-pointer-types] struct tx_desc *ptxdesc = pxmitbuf->pbuf; ^ ~~ 1 error generated. -- In file included from drivers/staging/greybus/camera.c:19: >> drivers/staging/greybus/gb-camera.h:33:27: error: field has incomplete type >> 'enum v4l2_mbus_pixelcode' enum v4l2_mbus_pixelcode pixel_code; ^ drivers/staging/greybus/gb-camera.h:33:7: note: forward declaration of 'enum v4l2_mbus_pixelcode' enum v4l2_mbus_pixelcode pixel_code; ^ >> drivers/staging/greybus/camera.c:20:10: fatal error: 'greybus_protocols.h' >> file not found #include "greybus_protocols.h" ^ 2 errors generated. -- >> drivers/staging/media/soc_camera/soc_mediabus.c:19:4: error: field >> designator 'name' does not refer to any field in type 'struct >> soc_mbus_pixelfmt' .name = "YUYV", ^ drivers/staging/media/soc_camera/soc_mediabus.c:29:4: error: field designator 'name' does not refer to any field in type 'struct soc_mbus_pixelfmt' .name = "YVYU", ^ drivers/staging/media/soc_camera/soc_mediabus.c:39:4: error: field designator 'name' does not refer to any field in type 'struct soc_mbus_pixelfmt' .name = "UYVY", ^ drivers/staging/media/soc_camera/soc_mediabus.c:49:4: error: field designator 'name' does not refer to any field in type 'struct soc_mbus_pixelfmt' .name = "VYUY", ^ drivers/staging/media/soc_camera/soc_mediabus.c:59:4: error: field designator 'name' does not refer to any field in type 'struct soc_mbus_pixelfmt' .name = "RGB555", ^ drivers/staging/media/soc_camera/soc_mediabus.c:69:4: error: field designator 'name' does not refer to any field in type 'struct soc_mbus_pixelfmt' .name = "RGB555X", ^ drivers/staging/media/soc_camera/soc_mediabus.c:79:4: error: field designator 'name' does not refer to any field in type 'struct soc_mbus_pixelfmt' .name = "RGB565", ^ drivers/staging/media/soc_camera/soc_mediabus.c:89:4: error: field designator 'name' does not refer to any field in type 'struct soc_mbus_pixelfmt' .name = "RGB565X", ^ drivers/staging/media/soc_camera/soc_mediabus.c:99:4: error: field designator 'name' does not refer to any field in type 'struct soc_mbus_pixelfmt' .name = "RGB666/32bpp", ^ drivers/staging/media/soc_camera/soc_mediabus.c:108:4: error: field designator 'name' does not refer to any field in type 'struct soc_mbus_pixelfmt' .name = "RGB888/32bpp", ^ drivers/staging/media/soc_camera/soc_mediabus.c:117:4: error: field designator 'name' does not refer to any field in type 'struct soc_mbus_pixelfmt' .name = "RGB888/32bpp", ^ drivers/staging/media/soc_camera/soc_mediabus.c:126:4: error: field designator 'name' does not refer to any field in type 'struct soc_mbus_pixelfmt' .name = "RGB888/32bpp", ^ drivers/staging/media/soc_camera/soc_mediabus.c:135:4: error: field designator 'name' does not refer to any field in type 'struct soc_mbus_pixelfmt' .name = "Bayer 8 BGGR", ^ drivers/staging/media/soc_camera/soc_mediabus.c:145:4: error: field designator 'name' does not refer to
[Bug 206987] [drm] [amdgpu] Whole system crashes when the driver is in mode_support_and_system_configuration
https://bugzilla.kernel.org/show_bug.cgi?id=206987 --- Comment #5 from Cyrax (ev...@hotmail.com) --- Oh and kernel is in 5.5.13 version. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206987] [drm] [amdgpu] Whole system crashes when the driver is in mode_support_and_system_configuration
https://bugzilla.kernel.org/show_bug.cgi?id=206987 Cyrax (ev...@hotmail.com) changed: What|Removed |Added Kernel Version|5.5.11 |5.5.13 Regression|No |Yes -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206987] [drm] [amdgpu] Whole system crashes when the driver is in mode_support_and_system_configuration
https://bugzilla.kernel.org/show_bug.cgi?id=206987 --- Comment #4 from Cyrax (ev...@hotmail.com) --- Created attachment 288203 --> https://bugzilla.kernel.org/attachment.cgi?id=288203=edit dmesg output 2 This crash happened again. In that time I have used VLC, played a game (GZDoom) and tried to listen youtube playlist by using a combination of youtube-dl, ffmpeg and mpv. I also updated motherboards BIOS/firmware to latest one. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
