[Bug 111481] AMD Navi GPU frequent freezes on both Manjaro/Ubuntu with kernel 5.3 and mesa 19.2 -git/llvm9
https://bugs.freedesktop.org/show_bug.cgi?id=111481 --- Comment #110 from Sebastian Meyer --- Created attachment 145773 --> https://bugs.freedesktop.org/attachment.cgi?id=145773=edit umr output after sdma0 timeout Another random sdma0 timeout while using kernel drm.fixes.5.4.2019.10.16.r0.gd12c50857c6e-1 with all mentioned patches applied (one of them already included on the drm-fixes branch). This time I didn't forget about the umr debug output, but I'm not sure if it's even relevant anymore considering the number of already submitted reports. The system freeze happened after working with WebStorm and SmartGit for roughly 10 minutes on KDE Plasma while scrolling in one of the application's windows. [39816.999159] [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed out! [39816.999298] [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed out! [39821.905604] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring sdma0 timeout, signaled seq=3360854, emitted seq=3360856 [39821.905718] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process Xorg pid 717 thread Xorg:cs0 pid 718 [39821.905720] [drm] GPU recovery disabled. I would really appreciate it if AMD and the AMDGPU devs could focus on fixing these major stability issues of their now almost 4 months old mainstream consumer GPUs. I'm sorry if this sounds harsh, but the hardware has been advertised with Linux support and it's clearly unusable. This needs to be fixed as soon as possible. Thank you! -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] omapfb: reduce stack usage
On Fri, 2019-10-18 at 23:30 +0100, Sudip Mukherjee wrote: > On Fri, Oct 18, 2019 at 07:27:28PM +0200, Ladislav Michl wrote: > > On Fri, Oct 18, 2019 at 05:30:04PM +0100, Sudip Mukherjee wrote: > > > The build of xtensa allmodconfig is giving a warning of: > > > In function 'dsi_dump_dsidev_irqs': > > > warning: the frame size of 1120 bytes is larger than 1024 bytes > > > > > > Allocate the memory for 'struct dsi_irq_stats' dynamically instead > > > of assigning it in stack. > > > > So now function can fail silently, executes longer, code is sligthly > > bigger... And all that to silent warning about exceeding frame size. > > Is it really worth "fixing"? Depends if it could fail in practice due to a stack overrun. > The only point of failure is if kmalloc() fails and if kmalloc() fails then > there will be error prints in dmesg to tell the user that there is no > memory left in the system. About the size bigger, it seems > the drivers/video/fbdev/omap2/omapfb/dss/dsi.o file is smaller with the > patch. > This is without the patch: > -rw-r--r-- 1 sudip sudip 316856 Oct 18 22:27 > drivers/video/fbdev/omap2/omapfb/dss/dsi.o > And this is with the patch: > -rw-r--r-- 1 sudip sudip 316436 Oct 18 20:09 > drivers/video/fbdev/omap2/omapfb/dss/dsi.o > > And also, objdump shows me that was taking up 0xD7D > bytes, and now with the patch it is taking up 0xBED bytes, thats a saving > of 400 bytes. If it has 400 bytes of less code to execute will it not be > faster now? You should try compiling without all the debugging symbols (defconfig) > But, I may be totally wrong in my thinking, and in that case, please feel > free to reject the patch. Without your patch: $ objdump -x drivers/video/fbdev/omap2/omapfb/dss/dsi.o | grep dsi_dump_dsidev_irqs 0d20 l F .text 061c dsi_dump_dsidev_irqs With your patch: $ objdump -x drivers/video/fbdev/omap2/omapfb/dss/dsi.o | grep dsi_dump_dsidev_irqs 0d20 l F .text 0638 dsi_dump_dsidev_irqs
Re: [PATCH] omapfb: reduce stack usage
On Fri, Oct 18, 2019 at 07:27:28PM +0200, Ladislav Michl wrote: > On Fri, Oct 18, 2019 at 05:30:04PM +0100, Sudip Mukherjee wrote: > > The build of xtensa allmodconfig is giving a warning of: > > In function 'dsi_dump_dsidev_irqs': > > warning: the frame size of 1120 bytes is larger than 1024 bytes > > > > Allocate the memory for 'struct dsi_irq_stats' dynamically instead > > of assigning it in stack. > > So now function can fail silently, executes longer, code is sligthly > bigger... And all that to silent warning about exceeding frame size. > Is it really worth "fixing"? The only point of failure is if kmalloc() fails and if kmalloc() fails then there will be error prints in dmesg to tell the user that there is no memory left in the system. About the size bigger, it seems the drivers/video/fbdev/omap2/omapfb/dss/dsi.o file is smaller with the patch. This is without the patch: -rw-r--r-- 1 sudip sudip 316856 Oct 18 22:27 drivers/video/fbdev/omap2/omapfb/dss/dsi.o And this is with the patch: -rw-r--r-- 1 sudip sudip 316436 Oct 18 20:09 drivers/video/fbdev/omap2/omapfb/dss/dsi.o And also, objdump shows me that was taking up 0xD7D bytes, and now with the patch it is taking up 0xBED bytes, thats a saving of 400 bytes. If it has 400 bytes of less code to execute will it not be faster now? But, I may be totally wrong in my thinking, and in that case, please feel free to reject the patch. -- Regards Sudip ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] omapfb: reduce stack usage
On Fri, Oct 18, 2019 at 6:27 PM Ladislav Michl wrote: > On Fri, Oct 18, 2019 at 05:30:04PM +0100, Sudip Mukherjee wrote: > > The build of xtensa allmodconfig is giving a warning of: > > In function 'dsi_dump_dsidev_irqs': > > warning: the frame size of 1120 bytes is larger than 1024 bytes > > > > Allocate the memory for 'struct dsi_irq_stats' dynamically instead > > of assigning it in stack. > > So now function can fail silently, executes longer, code is sligthly > bigger... And all that to silent warning about exceeding frame size. > Is it really worth "fixing"? > The only point of failure is if kmalloc() fails and if kmalloc() fails then there will be error prints in dmesg to tell the user that there is no memory left in the system. About the size bigger, it seems the drivers/video/fbdev/omap2/omapfb/dss/dsi.o file is smaller with the patch. This is without the patch: wo_patch -rw-r--r-- 1 sudip sudip 316856 Oct 18 22:27 drivers/video/fbdev/omap2/omapfb/dss/dsi.o And this is with the patch: -rw-r--r-- 1 sudip sudip 316436 Oct 18 20:09 drivers/video/fbdev/omap2/omapfb/dss/dsi.o And also, objdump shows me that was taking up 0xD7D bytes, and now with the patch it is taking up 0xBED bytes, thats a saving of 400 bytes. If it has 400 bytes of less code to execute will it not be faster now? But, I may be totally wrong in my thinking, and in that case, please feel free to reject the patch. -- Regards Sudip ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 088/100] drm/amdgpu: fix memory leak
From: Nirmoy Das
[ Upstream commit 083164dbdb17c5ea4ad92c1782b59c9d75567790 ]
cleanup error handling code and make sure temporary info array
with the handles are freed by amdgpu_bo_list_put() on
idr_replace()'s failure.
Signed-off-by: Nirmoy Das
Reviewed-by: Christian König
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c
index b80243d3972e4..ce7f18c5ccb26 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c
@@ -264,7 +264,7 @@ int amdgpu_bo_list_ioctl(struct drm_device *dev, void *data,
r = amdgpu_bo_create_list_entry_array(>in, );
if (r)
- goto error_free;
+ return r;
switch (args->in.operation) {
case AMDGPU_BO_LIST_OP_CREATE:
@@ -277,8 +277,7 @@ int amdgpu_bo_list_ioctl(struct drm_device *dev, void *data,
r = idr_alloc(>bo_list_handles, list, 1, 0, GFP_KERNEL);
mutex_unlock(>bo_list_lock);
if (r < 0) {
- amdgpu_bo_list_put(list);
- return r;
+ goto error_put_list;
}
handle = r;
@@ -300,9 +299,8 @@ int amdgpu_bo_list_ioctl(struct drm_device *dev, void *data,
mutex_unlock(>bo_list_lock);
if (IS_ERR(old)) {
- amdgpu_bo_list_put(list);
r = PTR_ERR(old);
- goto error_free;
+ goto error_put_list;
}
amdgpu_bo_list_put(old);
@@ -319,8 +317,10 @@ int amdgpu_bo_list_ioctl(struct drm_device *dev, void
*data,
return 0;
+error_put_list:
+ amdgpu_bo_list_put(list);
+
error_free:
- if (info)
- kvfree(info);
+ kvfree(info);
return r;
}
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 048/100] drm/amd/display: fix odm combine pipe reset
From: Dmytro Laktyushkin
[ Upstream commit f25f06b67ba237b76092a6fc522b1a94e84bfa85 ]
We fail to reset the second odm combine pipe. This change fixes
odm pointer management.
Signed-off-by: Dmytro Laktyushkin
Reviewed-by: Tony Cheng
Acked-by: Bhawanpreet Lakha
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/core/dc_resource.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
index d440b28ee43fb..6896d69b8c240 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
@@ -1399,9 +1399,9 @@ bool dc_remove_plane_from_context(
* For head pipe detach surfaces from pipe for tail
* pipe just zero it out
*/
- if (!pipe_ctx->top_pipe ||
- (!pipe_ctx->top_pipe->top_pipe &&
+ if (!pipe_ctx->top_pipe ||
(!pipe_ctx->top_pipe->top_pipe &&
pipe_ctx->top_pipe->stream_res.opp !=
pipe_ctx->stream_res.opp)) {
+ pipe_ctx->top_pipe = NULL;
pipe_ctx->plane_state = NULL;
pipe_ctx->bottom_pipe = NULL;
} else {
@@ -1803,8 +1803,6 @@ enum dc_status dc_remove_stream_from_ctx(
dc->res_pool->funcs->remove_stream_from_ctx(dc,
new_ctx, stream);
memset(del_pipe, 0, sizeof(*del_pipe));
-
- break;
}
}
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 012/100] drm/msm/dpu: handle failures while initializing displays
From: Jeykumar Sankaran
[ Upstream commit a802ee99c448ca0496fa307f3e46b834ae2a46a3 ]
Bail out KMS hw init on display initialization failures with
proper error logging.
changes in v3:
- introduced in the series
changes in v4:
- avoid duplicate return on errors (Sean Paul)
- avoid spamming errors on failures (Jordon Crouse)
Signed-off-by: Jeykumar Sankaran
Signed-off-by: Sean Paul
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 31 ++---
1 file changed, 18 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 74cc204b07e80..2d9b7b5fb49c8 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -442,35 +442,38 @@ static void dpu_kms_wait_for_commit_done(struct msm_kms
*kms,
}
}
-static void _dpu_kms_initialize_dsi(struct drm_device *dev,
+static int _dpu_kms_initialize_dsi(struct drm_device *dev,
struct msm_drm_private *priv,
struct dpu_kms *dpu_kms)
{
struct drm_encoder *encoder = NULL;
- int i, rc;
+ int i, rc = 0;
+
+ if (!(priv->dsi[0] || priv->dsi[1]))
+ return rc;
/*TODO: Support two independent DSI connectors */
encoder = dpu_encoder_init(dev, DRM_MODE_ENCODER_DSI);
- if (IS_ERR_OR_NULL(encoder)) {
+ if (IS_ERR(encoder)) {
DPU_ERROR("encoder init failed for dsi display\n");
- return;
+ return PTR_ERR(encoder);
}
priv->encoders[priv->num_encoders++] = encoder;
for (i = 0; i < ARRAY_SIZE(priv->dsi); i++) {
- if (!priv->dsi[i]) {
- DPU_DEBUG("invalid msm_dsi for ctrl %d\n", i);
- return;
- }
+ if (!priv->dsi[i])
+ continue;
rc = msm_dsi_modeset_init(priv->dsi[i], dev, encoder);
if (rc) {
DPU_ERROR("modeset_init failed for dsi[%d], rc = %d\n",
i, rc);
- continue;
+ break;
}
}
+
+ return rc;
}
/**
@@ -481,16 +484,16 @@ static void _dpu_kms_initialize_dsi(struct drm_device
*dev,
* @dpu_kms:Pointer to dpu kms structure
* Returns: Zero on success
*/
-static void _dpu_kms_setup_displays(struct drm_device *dev,
+static int _dpu_kms_setup_displays(struct drm_device *dev,
struct msm_drm_private *priv,
struct dpu_kms *dpu_kms)
{
- _dpu_kms_initialize_dsi(dev, priv, dpu_kms);
-
/**
* Extend this function to initialize other
* types of displays
*/
+
+ return _dpu_kms_initialize_dsi(dev, priv, dpu_kms);
}
static void _dpu_kms_drm_obj_destroy(struct dpu_kms *dpu_kms)
@@ -552,7 +555,9 @@ static int _dpu_kms_drm_obj_init(struct dpu_kms *dpu_kms)
* Create encoder and query display drivers to create
* bridges and connectors
*/
- _dpu_kms_setup_displays(dev, priv, dpu_kms);
+ ret = _dpu_kms_setup_displays(dev, priv, dpu_kms);
+ if (ret)
+ goto fail;
max_crtc_count = min(catalog->mixer_count, priv->num_encoders);
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.3 68/89] drm/amdgpu: fix memory leak
From: Nirmoy Das
[ Upstream commit 083164dbdb17c5ea4ad92c1782b59c9d75567790 ]
cleanup error handling code and make sure temporary info array
with the handles are freed by amdgpu_bo_list_put() on
idr_replace()'s failure.
Signed-off-by: Nirmoy Das
Reviewed-by: Christian König
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c
index 7bcf86c619995..61e38e43ad1d5 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c
@@ -270,7 +270,7 @@ int amdgpu_bo_list_ioctl(struct drm_device *dev, void *data,
r = amdgpu_bo_create_list_entry_array(>in, );
if (r)
- goto error_free;
+ return r;
switch (args->in.operation) {
case AMDGPU_BO_LIST_OP_CREATE:
@@ -283,8 +283,7 @@ int amdgpu_bo_list_ioctl(struct drm_device *dev, void *data,
r = idr_alloc(>bo_list_handles, list, 1, 0, GFP_KERNEL);
mutex_unlock(>bo_list_lock);
if (r < 0) {
- amdgpu_bo_list_put(list);
- return r;
+ goto error_put_list;
}
handle = r;
@@ -306,9 +305,8 @@ int amdgpu_bo_list_ioctl(struct drm_device *dev, void *data,
mutex_unlock(>bo_list_lock);
if (IS_ERR(old)) {
- amdgpu_bo_list_put(list);
r = PTR_ERR(old);
- goto error_free;
+ goto error_put_list;
}
amdgpu_bo_list_put(old);
@@ -325,8 +323,10 @@ int amdgpu_bo_list_ioctl(struct drm_device *dev, void
*data,
return 0;
+error_put_list:
+ amdgpu_bo_list_put(list);
+
error_free:
- if (info)
- kvfree(info);
+ kvfree(info);
return r;
}
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 09/15] drm/dp: Add helper to get post-cursor adjustments
Reviewed-by: Lyude Paul
On Tue, 2019-10-15 at 16:35 +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> If the transmitter supports pre-emphasis post cursor2 the sink will
> request adjustments in a similar way to how it requests adjustments to
> the voltage swing and pre-emphasis settings.
>
> Add a helper to extract these adjustments on a per-lane basis from the
> DPCD link status.
>
> Reviewed-by: Philipp Zabel
> Signed-off-by: Thierry Reding
> ---
> drivers/gpu/drm/drm_dp_helper.c | 10 ++
> include/drm/drm_dp_helper.h | 10 ++
> 2 files changed, 20 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c
> b/drivers/gpu/drm/drm_dp_helper.c
> index 4b66010771fa..de8ff8ddb445 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -120,6 +120,16 @@ u8 drm_dp_get_adjust_request_pre_emphasis(const u8
> link_status[DP_LINK_STATUS_SI
> }
> EXPORT_SYMBOL(drm_dp_get_adjust_request_pre_emphasis);
>
> +u8 drm_dp_get_adjust_request_post_cursor(const u8
> link_status[DP_LINK_STATUS_SIZE],
> + unsigned int lane)
> +{
> + unsigned int offset = DP_ADJUST_REQUEST_POST_CURSOR2;
> + u8 value = dp_link_status(link_status, offset);
> +
> + return (value >> (lane << 1)) & 0x3;
> +}
> +EXPORT_SYMBOL(drm_dp_get_adjust_request_post_cursor);
> +
> void drm_dp_link_train_clock_recovery_delay(const u8
> dpcd[DP_RECEIVER_CAP_SIZE])
> {
> unsigned int rd_interval = drm_dp_aux_rd_interval(dpcd);
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index 6c12de6f7e46..e0b2c03f3cbb 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -608,6 +608,14 @@
> # define DP_ADJUST_PRE_EMPHASIS_LANE1_SHIFT 6
>
> #define DP_ADJUST_REQUEST_POST_CURSOR2 0x20c
> +# define DP_ADJUST_POST_CURSOR2_LANE0_MASK 0x03
> +# define DP_ADJUST_POST_CURSOR2_LANE0_SHIFT 0
> +# define DP_ADJUST_POST_CURSOR2_LANE1_MASK 0x0c
> +# define DP_ADJUST_POST_CURSOR2_LANE1_SHIFT 2
> +# define DP_ADJUST_POST_CURSOR2_LANE2_MASK 0x30
> +# define DP_ADJUST_POST_CURSOR2_LANE2_SHIFT 4
> +# define DP_ADJUST_POST_CURSOR2_LANE3_MASK 0xc0
> +# define DP_ADJUST_POST_CURSOR2_LANE3_SHIFT 6
>
> #define DP_TEST_REQUEST 0x218
> # define DP_TEST_LINK_TRAINING (1 << 0)
> @@ -1121,6 +1129,8 @@ u8 drm_dp_get_adjust_request_voltage(const u8
> link_status[DP_LINK_STATUS_SIZE],
>int lane);
> u8 drm_dp_get_adjust_request_pre_emphasis(const u8
> link_status[DP_LINK_STATUS_SIZE],
> int lane);
> +u8 drm_dp_get_adjust_request_post_cursor(const u8
> link_status[DP_LINK_STATUS_SIZE],
> + unsigned int lane);
>
> #define DP_BRANCH_OUI_HEADER_SIZE0xc
> #define DP_RECEIVER_CAP_SIZE 0xf
--
Cheers,
Lyude Paul
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 08/15] drm/dp: Use drm_dp_aux_rd_interval()
This also seems like maybe it should just go into the previous patch?
On Tue, 2019-10-15 at 16:35 +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> Make use of the newly added drm_dp_aux_rd_interval() helper in existing
> DP link training helpers.
>
> v2: drop stale sentence from commit message (Philipp Zabel)
>
> Signed-off-by: Thierry Reding
> ---
> drivers/gpu/drm/drm_dp_helper.c | 26 +++---
> 1 file changed, 3 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c
> b/drivers/gpu/drm/drm_dp_helper.c
> index ad2671d2ee8f..4b66010771fa 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -122,17 +122,7 @@ EXPORT_SYMBOL(drm_dp_get_adjust_request_pre_emphasis);
>
> void drm_dp_link_train_clock_recovery_delay(const u8
> dpcd[DP_RECEIVER_CAP_SIZE])
> {
> - unsigned int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
> - DP_TRAINING_AUX_RD_MASK;
> -
> - if (rd_interval > 4)
> - DRM_DEBUG_KMS("AUX interval %u, out of range (max 4)\n",
> - rd_interval);
> -
> - if (rd_interval == 0 || dpcd[DP_DPCD_REV] >= DP_DPCD_REV_14)
> - rd_interval = 100;
> - else
> - rd_interval *= 4 * USEC_PER_MSEC;
> + unsigned int rd_interval = drm_dp_aux_rd_interval(dpcd);
>
> usleep_range(rd_interval, rd_interval * 2);
> }
> @@ -140,19 +130,9 @@ EXPORT_SYMBOL(drm_dp_link_train_clock_recovery_delay);
>
> void drm_dp_link_train_channel_eq_delay(const u8
> dpcd[DP_RECEIVER_CAP_SIZE])
> {
> - unsigned int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
> - DP_TRAINING_AUX_RD_MASK;
> -
> - if (rd_interval > 4)
> - DRM_DEBUG_KMS("AUX interval %u, out of range (max 4)\n",
> - rd_interval);
> + unsigned int min = drm_dp_aux_rd_interval(dpcd);
>
> - if (rd_interval == 0)
> - rd_interval = 400;
> - else
> - rd_interval *= 4 * USEC_PER_MSEC;
> -
> - usleep_range(rd_interval, rd_interval * 2);
> + usleep_range(min, min * 2);
> }
> EXPORT_SYMBOL(drm_dp_link_train_channel_eq_delay);
>
--
Cheers,
Lyude Paul
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 07/15] drm/dp: Do not busy-loop during link training
On Tue, 2019-10-15 at 16:35 +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> Use microsecond sleeps for the clock recovery and channel equalization
> delays during link training. The duration of these delays can be from
> 100 us up to 16 ms. It is rude to busy-loop for that amount of time.
>
> While at it, also convert to standard coding style by putting the
> opening braces in a function definition on a new line.
>
> v2: use correct multiplier for training delays (Philipp Zabel)
>
> Signed-off-by: Thierry Reding
> ---
> drivers/gpu/drm/drm_dp_helper.c | 30 ++
> 1 file changed, 18 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c
> b/drivers/gpu/drm/drm_dp_helper.c
> index 8f2d7c4850ca..ad2671d2ee8f 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -120,33 +120,39 @@ u8 drm_dp_get_adjust_request_pre_emphasis(const u8
> link_status[DP_LINK_STATUS_SI
> }
> EXPORT_SYMBOL(drm_dp_get_adjust_request_pre_emphasis);
>
> -void drm_dp_link_train_clock_recovery_delay(const u8
> dpcd[DP_RECEIVER_CAP_SIZE]) {
> - int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
> - DP_TRAINING_AUX_RD_MASK;
> +void drm_dp_link_train_clock_recovery_delay(const u8
> dpcd[DP_RECEIVER_CAP_SIZE])
> +{
> + unsigned int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
> + DP_TRAINING_AUX_RD_MASK;
Did you mean to put this conversion from signed to unsigned in the previous
patch?
>
> if (rd_interval > 4)
> - DRM_DEBUG_KMS("AUX interval %d, out of range (max 4)\n",
> + DRM_DEBUG_KMS("AUX interval %u, out of range (max 4)\n",
> rd_interval);
>
> if (rd_interval == 0 || dpcd[DP_DPCD_REV] >= DP_DPCD_REV_14)
> - udelay(100);
> + rd_interval = 100;
> else
> - mdelay(rd_interval * 4);
> + rd_interval *= 4 * USEC_PER_MSEC;
> +
> + usleep_range(rd_interval, rd_interval * 2);
> }
> EXPORT_SYMBOL(drm_dp_link_train_clock_recovery_delay);
>
> -void drm_dp_link_train_channel_eq_delay(const u8
> dpcd[DP_RECEIVER_CAP_SIZE]) {
> - int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
> - DP_TRAINING_AUX_RD_MASK;
> +void drm_dp_link_train_channel_eq_delay(const u8
> dpcd[DP_RECEIVER_CAP_SIZE])
> +{
> + unsigned int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
> + DP_TRAINING_AUX_RD_MASK;
>
> if (rd_interval > 4)
> - DRM_DEBUG_KMS("AUX interval %d, out of range (max 4)\n",
> + DRM_DEBUG_KMS("AUX interval %u, out of range (max 4)\n",
> rd_interval);
>
> if (rd_interval == 0)
> - udelay(400);
> + rd_interval = 400;
> else
> - mdelay(rd_interval * 4);
> + rd_interval *= 4 * USEC_PER_MSEC;
> +
> + usleep_range(rd_interval, rd_interval * 2);
> }
> EXPORT_SYMBOL(drm_dp_link_train_channel_eq_delay);
>
--
Cheers,
Lyude Paul
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 06/15] drm/dp: Read AUX read interval from DPCD
On Tue, 2019-10-15 at 16:35 +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> Store the AUX read interval from DPCD, so that it can be used to wait
> for the durations given in the specification during link training.
>
> Signed-off-by: Thierry Reding
> ---
> include/drm/drm_dp_helper.h | 33 +
> 1 file changed, 33 insertions(+)
>
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index 7a537ffc2fb1..6c12de6f7e46 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -25,8 +25,11 @@
>
> #include
> #include
> +#include
> #include
>
> +#include
> +
> /*
> * Unless otherwise noted, all values are from the DP 1.1a spec. Note that
> * DP and DPCD versions are independent. Differences from 1.0 are not
> noted,
> @@ -1297,6 +1300,36 @@ drm_dp_alternate_scrambler_reset_cap(const u8
> dpcd[DP_RECEIVER_CAP_SIZE])
> DP_ALTERNATE_SCRAMBLER_RESET_CAP;
> }
>
> +/**
> + * drm_dp_read_aux_interval() - read the AUX read interval from the DPCD
> + * @dpcd: receiver capacity buffer
> + *
> + * Reads the AUX read interval (in microseconds) from the DPCD. Note that
> the
> + * TRAINING_AUX_RD_INTERVAL stores the value in units of 4 milliseconds. If
> no
> + * read interval is specified and for DPCD v1.4 and later, the read
> interval
> + * is always 100 microseconds.
> + *
> + * Returns:
> + * The read AUX interval in microseconds.
> + */
> +static inline unsigned int
> +drm_dp_aux_rd_interval(const u8 dpcd[DP_RECEIVER_CAP_SIZE])
> +{
> + unsigned int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
> + DP_TRAINING_AUX_RD_MASK;
> +
> + if (rd_interval > 4)
> + DRM_DEBUG_KMS("AUX interval %u, out of range (max: 4)\n",
> + rd_interval);
Do you think it might be worth clamping the value to 4 here?
> +
> + if (rd_interval > 0 && dpcd[DP_DPCD_REV] < DP_DPCD_REV_14)
Also small nit pick: you can just use rd_interval instead of rd_interval > 0
> + rd_interval *= 4 * USEC_PER_MSEC;
> + else
> + rd_interval = 100;
> +
> + return rd_interval;
> +}
> +
> /*
> * DisplayPort AUX channel
> */
--
Cheers,
Lyude Paul
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 05/15] drm/dp: Add drm_dp_alternate_scrambler_reset_cap() helper
Reviewed-by: Lyude Paul
On Tue, 2019-10-15 at 16:34 +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> Add a helper to check if the sink supports the eDP alternate scrambler
> reset value of 0xfffe.
>
> Signed-off-by: Thierry Reding
> ---
> include/drm/drm_dp_helper.h | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index 7ff7bf0e742d..7a537ffc2fb1 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -1290,6 +1290,13 @@ drm_dp_channel_coding_supported(const u8
> dpcd[DP_RECEIVER_CAP_SIZE])
> return dpcd[DP_MAIN_LINK_CHANNEL_CODING] & DP_CAP_ANSI_8B10B;
> }
>
> +static inline bool
> +drm_dp_alternate_scrambler_reset_cap(const u8 dpcd[DP_RECEIVER_CAP_SIZE])
> +{
> + return dpcd[DP_EDP_CONFIGURATION_CAP] &
> + DP_ALTERNATE_SCRAMBLER_RESET_CAP;
> +}
> +
> /*
> * DisplayPort AUX channel
> */
--
Cheers,
Lyude Paul
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 04/15] drm/dp: Add drm_dp_channel_coding_supported() helper
Reviewed-by: Lyude Paul
On Tue, 2019-10-15 at 16:34 +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> Add a helper to check whether the sink supports ANSI 8B/10B channel
> coding capability as specified in ANSI X3.230-1994, clause 11.
>
> Signed-off-by: Thierry Reding
> ---
> include/drm/drm_dp_helper.h | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index def3b3a543a2..7ff7bf0e742d 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -137,6 +137,7 @@
> # define DP_DETAILED_CAP_INFO_AVAILABLE (1 << 4) /* DPI */
>
> #define DP_MAIN_LINK_CHANNEL_CODING 0x006
> +# define DP_CAP_ANSI_8B10B (1 << 0)
>
> #define DP_DOWN_STREAM_PORT_COUNT0x007
> # define DP_PORT_COUNT_MASK 0x0f
> @@ -1283,6 +1284,12 @@ drm_dp_sink_supports_fec(const u8 fec_capable)
> return fec_capable & DP_FEC_CAPABLE;
> }
>
> +static inline bool
> +drm_dp_channel_coding_supported(const u8 dpcd[DP_RECEIVER_CAP_SIZE])
> +{
> + return dpcd[DP_MAIN_LINK_CHANNEL_CODING] & DP_CAP_ANSI_8B10B;
> +}
> +
> /*
> * DisplayPort AUX channel
> */
--
Cheers,
Lyude Paul
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 03/15] drm/dp: Add drm_dp_fast_training_cap() helper
Reviewed-by: Lyude Paul
On Tue, 2019-10-15 at 16:34 +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> Add a helper that checks for the fast training capability given the DPCD
> receiver capabilities blob.
>
> Signed-off-by: Thierry Reding
> ---
> include/drm/drm_dp_helper.h | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index 52ff1f24a24d..def3b3a543a2 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -1211,6 +1211,13 @@ drm_dp_enhanced_frame_cap(const u8
> dpcd[DP_RECEIVER_CAP_SIZE])
> (dpcd[DP_MAX_LANE_COUNT] & DP_ENHANCED_FRAME_CAP);
> }
>
> +static inline bool
> +drm_dp_fast_training_cap(const u8 dpcd[DP_RECEIVER_CAP_SIZE])
> +{
> + return dpcd[DP_DPCD_REV] >= 0x11 &&
> + (dpcd[DP_MAX_DOWNSPREAD] & DP_NO_AUX_HANDSHAKE_LINK_TRAINING);
> +}
> +
> static inline bool
> drm_dp_tps3_supported(const u8 dpcd[DP_RECEIVER_CAP_SIZE])
> {
--
Cheers,
Lyude Paul
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 02/15] drm/dp: Remove a gratuituous blank line
Reviewed-by: Lyude Paul
On Tue, 2019-10-15 at 16:34 +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> It's idiomatic to check the return value of a function call immediately
> after the function call, without any blank lines in between, to make it
> more obvious that the two lines belong together.
>
> v2: fix outdated commit message (Philipp Zabel)
>
> Signed-off-by: Thierry Reding
> ---
> drivers/gpu/drm/drm_dp_helper.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c
> b/drivers/gpu/drm/drm_dp_helper.c
> index f373798d82f6..8f2d7c4850ca 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -220,7 +220,6 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8
> request,
> }
>
> ret = aux->transfer(aux, );
> -
> if (ret >= 0) {
> native_reply = msg.reply & DP_AUX_NATIVE_REPLY_MASK;
> if (native_reply == DP_AUX_NATIVE_REPLY_ACK) {
--
Cheers,
Lyude Paul
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/15] drm/dp: Sort includes alphabetically
Reviewed-by: Lyude Paul On Tue, 2019-10-15 at 16:34 +0200, Thierry Reding wrote: > From: Thierry Reding > > Keeping the list sorted alphabetically makes it much easier to determine > where to add new includes. > > Signed-off-by: Thierry Reding > --- > include/drm/drm_dp_helper.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h > index bf62b43aaf2b..52ff1f24a24d 100644 > --- a/include/drm/drm_dp_helper.h > +++ b/include/drm/drm_dp_helper.h > @@ -23,9 +23,9 @@ > #ifndef _DRM_DP_HELPER_H_ > #define _DRM_DP_HELPER_H_ > > -#include > -#include > #include > +#include > +#include > > /* > * Unless otherwise noted, all values are from the DP 1.1a spec. Note that -- Cheers, Lyude Paul ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111846] Suspend to RAM cause screen to glitch on navi10
https://bugs.freedesktop.org/show_bug.cgi?id=111846 --- Comment #4 from Yuxuan Shui --- Looks like this happens after a GPU reset as well. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111481] AMD Navi GPU frequent freezes on both Manjaro/Ubuntu with kernel 5.3 and mesa 19.2 -git/llvm9
https://bugs.freedesktop.org/show_bug.cgi?id=111481 --- Comment #109 from Shmerl --- I'm not sure if it really makes any difference, but I think Firefox hang happens more commonly after I resume computer from suspend, than after a fresh boot. I'll pay attention now, testing with fresh boot, to see it happens or not. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH][next] drm/amdgpu/psp: fix spelling mistake "initliaze" -> "initialize"
On Fri, Oct 18, 2019 at 4:15 AM Colin King wrote:
>
> From: Colin Ian King
>
> There is a spelling mistake in a DRM_ERROR error message. Fix it.
>
> Signed-off-by: Colin Ian King
Applied. thanks!
Alex
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
> index b996b5bc5804..fd7a73f4fa70 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
> @@ -90,7 +90,7 @@ static int psp_sw_init(void *handle)
>
> ret = psp_mem_training_init(psp);
> if (ret) {
> - DRM_ERROR("Failed to initliaze memory training!\n");
> + DRM_ERROR("Failed to initialize memory training!\n");
> return ret;
> }
> ret = psp_mem_training(psp, PSP_MEM_TRAIN_COLD_BOOT);
> --
> 2.20.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PULL] drm-misc-next
On Fri, Oct 18, 2019 at 9:46 AM Tomi Valkeinen wrote: > > Hi Sean, > > On 17/10/2019 22:26, Sean Paul wrote: > > > concern for those. The omap OMAP_BO_MEM_* changes though I don't think have > > really reached non-TI eyes. There's no link in the commit message to a UAPI > > implementation and the only reference I could find is libkmsxx which can set > > them through the python bindings. Since this is TI-specific gunk in > > TI-specific > > headers I'm inclined to let it pass, but I would have liked to have this > > conversation upfront. I figured I'd call this out so you have final say. > > There was some discussion about that a few years back when I initially > sent the patches, but now that I look, the discussion died before really > even starting. > > This is what I said about userspace implementation: > > > Yes, unfortunately that is not going to happen. I don't see how this > > could be used in a generic system like Weston or X. It's meant for very > > specific use cases, where you know exactly the requirements of your > > application and the capabilities of the whole system, and optimize based > > on that. Thanks for the context, Tomi. Indeed it looks like the discussion died, but Laurent still brought up the u/s requirement and the patch was effectively dead until Daniel or Dave weighed in. I'd expect at least some outreach before pushing the patch directly 2+ years later. Has anything changed since then? > I know this feature is used by customers, but I don't have access to > their applications. Unfortunately, and as you know, that is insufficient/irrelevant for introducing new UAPI. So the question is if the libkmsxx bindings constitute opensource userspace, it's really thin IMO. Sean > > Tomi > > -- > Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. > Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 204965] [amdgpu]] *ERROR* ring gfx test failed (-110) upon wake from sleep, no video or frozen video
https://bugzilla.kernel.org/show_bug.cgi?id=204965 Andrey Grodzovsky (andrey.grodzov...@amd.com) changed: What|Removed |Added CC||andrey.grodzov...@amd.com --- Comment #2 from Andrey Grodzovsky (andrey.grodzov...@amd.com) --- Seems to me the same as https://bugzilla.kernel.org/show_bug.cgi?id=204241 - which is resolved already - give those patches a try. The OOPS following the resume failure is a side issue and should be handled separatly. -- 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: [RESEND][PATCH v8 0/5] DMA-BUF Heaps (destaging ION)
On Fri, Oct 18, 2019 at 11:57 AM Ayan Halder wrote: > On Fri, Oct 18, 2019 at 11:49:22AM -0700, John Stultz wrote: > > On Fri, Oct 18, 2019 at 11:41 AM Ayan Halder wrote: > > > With 'reusable', rmem_cma_setup() succeeds , but the kernel crashes as > > > follows :- > > > > > > [0.450562] WARNING: CPU: 2 PID: 1 at mm/cma.c:110 > > > cma_init_reserved_areas+0xec/0x22c > > > > Is the value 0x6000 you're using something you just guessed at? It > > seems like the warning here is saying the pfn calculated from the base > > address isn't valid. > It is a valid memory region we use to allocate framebuffers. Hrm. I guess I'd suggest digging to figure out why the kernel doesn't see it as such. Does this only happen with my patches applied? I'm sort of assuming can you trip this even without them, but maybe I'm wrong? thanks -john ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND][PATCH v8 0/5] DMA-BUF Heaps (destaging ION)
On Fri, Oct 18, 2019 at 11:49:22AM -0700, John Stultz wrote:
> On Fri, Oct 18, 2019 at 11:41 AM Ayan Halder wrote:
> > On Fri, Oct 18, 2019 at 09:55:17AM +, Brian Starkey wrote:
> > > On Thu, Oct 17, 2019 at 01:57:45PM -0700, John Stultz wrote:
> > > > On Thu, Oct 17, 2019 at 12:29 PM Andrew F. Davis wrote:
> > > > > On 10/17/19 3:14 PM, John Stultz wrote:
> > > > > > But if the objection stands, do you have a proposal for an
> > > > > > alternative
> > > > > > way to enumerate a subset of CMA heaps?
> > > > > >
> > > > > When in staging ION had to reach into the CMA framework as the other
> > > > > direction would not be allowed, so cma_for_each_area() was added. If
> > > > > DMA-BUF heaps is not in staging then we can do the opposite, and have
> > > > > the CMA framework register heaps itself using our framework. That way
> > > > > the CMA system could decide what areas to export or not (maybe based
> > > > > on
> > > > > a DT property or similar).
> > > >
> > > > Ok. Though the CMA core doesn't have much sense of DT details either,
> > > > so it would probably have to be done in the reserved_mem logic, which
> > > > doesn't feel right to me.
> > > >
> > > > I'd probably guess we should have some sort of dt binding to describe
> > > > a dmabuf cma heap and from that node link to a CMA node via a
> > > > memory-region phandle. Along with maybe the default heap as well? Not
> > > > eager to get into another binding review cycle, and I'm not sure what
> > > > non-DT systems will do yet, but I'll take a shot at it and iterate.
> > > >
> > > > > The end result is the same so we can make this change later (it has to
> > > > > come after DMA-BUF heaps is in anyway).
> > > >
> > > > Well, I'm hesitant to merge code that exposes all the CMA heaps and
> > > > then add patches that becomes more selective, should anyone depend on
> > > > the initial behavior. :/
> > >
> > > How about only auto-adding the system default CMA region (cma->name ==
> > > "reserved")?
> > >
> > > And/or the CMA auto-add could be behind a config option? It seems a
> > > shame to further delay this, and the CMA heap itself really is useful.
> > >
> > A bit of a detour, comming back to the issue why the following node
> > was not getting detected by the dma-buf heaps framework.
> >
> > reserved-memory {
> > #address-cells = <2>;
> > #size-cells = <2>;
> > ranges;
> >
> > display_reserved: framebuffer@6000 {
> > compatible = "shared-dma-pool";
> > linux,cma-default;
> > reusable; ---This was missing
> > in our
> > earlier node
> > reg = <0 0x6000 0 0x0800>;
> > };
>
> Right. It has to be a CMA region for us to expose it from the cma heap.
>
>
> > With 'reusable', rmem_cma_setup() succeeds , but the kernel crashes as
> > follows :-
> >
> > [0.450562] WARNING: CPU: 2 PID: 1 at mm/cma.c:110
> > cma_init_reserved_areas+0xec/0x22c
>
> Is the value 0x6000 you're using something you just guessed at? It
> seems like the warning here is saying the pfn calculated from the base
> address isn't valid.
It is a valid memory region we use to allocate framebuffers.
>
> thanks
> -john
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/fourcc: Fix undefined left shift in DRM_FORMAT_BIG_ENDIAN macros
On Fri, Oct 18, 2019 at 01:50:41PM -0400, Adam Jackson wrote:
> 1<<31 is undefined because it's a signed int and C is terrible.
>
> Reviewed-by: Eric Engestrom
> Signed-off-by: Adam Jackson
Thanks. Pushed to drm-misc-next.
> ---
> include/uapi/drm/drm_fourcc.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 3feeaa3f987a..c06d34559fab 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -69,7 +69,7 @@ extern "C" {
> #define fourcc_code(a, b, c, d) ((__u32)(a) | ((__u32)(b) << 8) | \
>((__u32)(c) << 16) | ((__u32)(d) << 24))
>
> -#define DRM_FORMAT_BIG_ENDIAN (1<<31) /* format is big endian instead of
> little endian */
> +#define DRM_FORMAT_BIG_ENDIAN (1U<<31) /* format is big endian instead of
> little endian */
>
> /* Reserve 0 for the invalid format specifier */
> #define DRM_FORMAT_INVALID 0
> --
> 2.23.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND][PATCH v8 0/5] DMA-BUF Heaps (destaging ION)
++ john.stu...@linaro.org (Sorry, somehow I am missing your email while
sending. :( )
On Fri, Oct 18, 2019 at 06:41:24PM +, Ayan Halder wrote:
> On Fri, Oct 18, 2019 at 09:55:17AM +, Brian Starkey wrote:
> > On Thu, Oct 17, 2019 at 01:57:45PM -0700, John Stultz wrote:
> > > On Thu, Oct 17, 2019 at 12:29 PM Andrew F. Davis wrote:
> > > > On 10/17/19 3:14 PM, John Stultz wrote:
> > > > > But if the objection stands, do you have a proposal for an alternative
> > > > > way to enumerate a subset of CMA heaps?
> > > > >
> > > > When in staging ION had to reach into the CMA framework as the other
> > > > direction would not be allowed, so cma_for_each_area() was added. If
> > > > DMA-BUF heaps is not in staging then we can do the opposite, and have
> > > > the CMA framework register heaps itself using our framework. That way
> > > > the CMA system could decide what areas to export or not (maybe based on
> > > > a DT property or similar).
> > >
> > > Ok. Though the CMA core doesn't have much sense of DT details either,
> > > so it would probably have to be done in the reserved_mem logic, which
> > > doesn't feel right to me.
> > >
> > > I'd probably guess we should have some sort of dt binding to describe
> > > a dmabuf cma heap and from that node link to a CMA node via a
> > > memory-region phandle. Along with maybe the default heap as well? Not
> > > eager to get into another binding review cycle, and I'm not sure what
> > > non-DT systems will do yet, but I'll take a shot at it and iterate.
> > >
> > > > The end result is the same so we can make this change later (it has to
> > > > come after DMA-BUF heaps is in anyway).
> > >
> > > Well, I'm hesitant to merge code that exposes all the CMA heaps and
> > > then add patches that becomes more selective, should anyone depend on
> > > the initial behavior. :/
> >
> > How about only auto-adding the system default CMA region (cma->name ==
> > "reserved")?
> >
> > And/or the CMA auto-add could be behind a config option? It seems a
> > shame to further delay this, and the CMA heap itself really is useful.
> >
> A bit of a detour, comming back to the issue why the following node
> was not getting detected by the dma-buf heaps framework.
>
> reserved-memory {
> #address-cells = <2>;
> #size-cells = <2>;
> ranges;
>
> display_reserved: framebuffer@6000 {
> compatible = "shared-dma-pool";
> linux,cma-default;
> reusable; ---This was missing in
> our
> earlier node
> reg = <0 0x6000 0 0x0800>;
> };
>
> Quoting reserved-memory.txt :-
> "The operating system can use the memory in this region with the limitation
> that
> the device driver(s) owning the region need to be able to reclaim it back"
>
> Thus as per my observation, without 'reusable', rmem_cma_setup()
> returns -EINVAL and the reserved-memory is not added as a cma region.
>
> With 'reusable', rmem_cma_setup() succeeds , but the kernel crashes as
> follows :-
>
> [0.450562] WARNING: CPU: 2 PID: 1 at mm/cma.c:110
> cma_init_reserved_areas+0xec/0x22c
> [0.458415] Modules linked in:
>
> [0.461470] CPU: 2 PID: 1 Comm: swapper/0 Not tainted
> 5.3.0-rc4-01377-g51dbcf03884c-dirty #15
>
> [0.470017] Hardware name: ARM Juno development board (r0) (DT)
>
> [0.475953] pstate: 8005 (Nzcv daif -PAN -UAO)
>
> [0.480755] pc : cma_init_reserved_areas+0xec/0x22c
> [0.485643] lr : cma_init_reserved_areas+0xe8/0x22c
>
>
> [0.600646] Unable to handle kernel paging request at virtual address
> 7d80
> [0.608591] Mem abort info:
> [0.611386] ESR = 0x9606
> <---snip uninteresting bits --->
> [0.681069] pc : cma_init_reserved_areas+0x114/0x22c
> [0.686043] lr : cma_init_reserved_areas+0xe8/0x22c
>
>
> I am looking into this now. My final objective is to get
> "/dev/dma_heap/framebuffer"
> (as a cma heap).
> Any leads?
>
> > Cheers,
> > -Brian
> >
> > >
> > > So, , I'll start on the rework for the CMA bits.
> > >
> > > That said, I'm definitely wanting to make some progress on this patch
> > > series, so maybe we can still merge the core/helpers/system heap and
> > > just hold the cma heap for a rework on the enumeration bits. That way
> > > we can at least get other folks working on switching their vendor
> > > heaps from ION.
> > >
> > > Sumit: Does that sound ok? Assuming no other objections, can you take
> > > the v11 set minus the CMA heap patch?
> > >
> > > thanks
> >
Re: [RESEND][PATCH v8 0/5] DMA-BUF Heaps (destaging ION)
On Fri, Oct 18, 2019 at 11:41 AM Ayan Halder wrote:
> On Fri, Oct 18, 2019 at 09:55:17AM +, Brian Starkey wrote:
> > On Thu, Oct 17, 2019 at 01:57:45PM -0700, John Stultz wrote:
> > > On Thu, Oct 17, 2019 at 12:29 PM Andrew F. Davis wrote:
> > > > On 10/17/19 3:14 PM, John Stultz wrote:
> > > > > But if the objection stands, do you have a proposal for an alternative
> > > > > way to enumerate a subset of CMA heaps?
> > > > >
> > > > When in staging ION had to reach into the CMA framework as the other
> > > > direction would not be allowed, so cma_for_each_area() was added. If
> > > > DMA-BUF heaps is not in staging then we can do the opposite, and have
> > > > the CMA framework register heaps itself using our framework. That way
> > > > the CMA system could decide what areas to export or not (maybe based on
> > > > a DT property or similar).
> > >
> > > Ok. Though the CMA core doesn't have much sense of DT details either,
> > > so it would probably have to be done in the reserved_mem logic, which
> > > doesn't feel right to me.
> > >
> > > I'd probably guess we should have some sort of dt binding to describe
> > > a dmabuf cma heap and from that node link to a CMA node via a
> > > memory-region phandle. Along with maybe the default heap as well? Not
> > > eager to get into another binding review cycle, and I'm not sure what
> > > non-DT systems will do yet, but I'll take a shot at it and iterate.
> > >
> > > > The end result is the same so we can make this change later (it has to
> > > > come after DMA-BUF heaps is in anyway).
> > >
> > > Well, I'm hesitant to merge code that exposes all the CMA heaps and
> > > then add patches that becomes more selective, should anyone depend on
> > > the initial behavior. :/
> >
> > How about only auto-adding the system default CMA region (cma->name ==
> > "reserved")?
> >
> > And/or the CMA auto-add could be behind a config option? It seems a
> > shame to further delay this, and the CMA heap itself really is useful.
> >
> A bit of a detour, comming back to the issue why the following node
> was not getting detected by the dma-buf heaps framework.
>
> reserved-memory {
> #address-cells = <2>;
> #size-cells = <2>;
> ranges;
>
> display_reserved: framebuffer@6000 {
> compatible = "shared-dma-pool";
> linux,cma-default;
> reusable; ---This was missing in
> our
> earlier node
> reg = <0 0x6000 0 0x0800>;
> };
Right. It has to be a CMA region for us to expose it from the cma heap.
> With 'reusable', rmem_cma_setup() succeeds , but the kernel crashes as
> follows :-
>
> [0.450562] WARNING: CPU: 2 PID: 1 at mm/cma.c:110
> cma_init_reserved_areas+0xec/0x22c
Is the value 0x6000 you're using something you just guessed at? It
seems like the warning here is saying the pfn calculated from the base
address isn't valid.
thanks
-john
[PATCH 2/7] ARM: DTS: am33xx: add sgx gpu child node
and add timer and interrupt.
Tested on BeagleBone Black.
Signed-off-by: H. Nikolaus Schaller
---
arch/arm/boot/dts/am33xx.dtsi | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index a9d848d50b20..e76a47991de3 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -480,10 +480,13 @@
#size-cells = <1>;
ranges = <0 0x5600 0x100>;
- /*
-* Closed source PowerVR driver, no child device
-* binding or driver in mainline
-*/
+ sgx: sgx@0 {
+ compatible = "img,sgx530-125", "img,sgx530",
"ti,omap-am335x-sgx530-125";
+ reg = <0x00 0x100>; /* 16 MB */
+ reg-names = "sgx";
+ interrupts = <37>;
+ timer = <>;
+ };
};
};
};
--
2.19.1
[PATCH 6/7] ARM: DTS: omap4: add sgx gpu child node
and add timer and interrupt.
Since omap4420/30/60 and omap4470 come with different SGX variants
we need to introduce a new omap4470.dtsi. If an omap4470 board
does not want to use SGX it is no problem to still include
omap4460.dtsi.
Tested on PandaBoard ES.
Signed-off-by: H. Nikolaus Schaller
---
arch/arm/boot/dts/omap4.dtsi | 11 +++
arch/arm/boot/dts/omap4470.dts | 16
2 files changed, 23 insertions(+), 4 deletions(-)
create mode 100644 arch/arm/boot/dts/omap4470.dts
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 7cc95bc1598b..4c94555ae0d0 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -347,10 +347,13 @@
#size-cells = <1>;
ranges = <0 0x5600 0x200>;
- /*
-* Closed source PowerVR driver, no child device
-* binding or driver in mainline
-*/
+ sgx: sgx@0 {
+ compatible = "img,sgx540-120", "img,sgx540",
"ti,omap-omap4-sgx540-120";
+ reg = <0x0 0x200>; /* 32MB */
+ reg-names = "sgx";
+ interrupts = ;
+ timer = <>;
+ };
};
dss: dss@5800 {
diff --git a/arch/arm/boot/dts/omap4470.dts b/arch/arm/boot/dts/omap4470.dts
new file mode 100644
index ..45b0b4b8ce32
--- /dev/null
+++ b/arch/arm/boot/dts/omap4470.dts
@@ -0,0 +1,16 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Device Tree Source for OMAP4470 SoC
+ *
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+#include "omap4460.dtsi"
+
+ {
+ compatible = "img,sgx544-112", "img,sgx544", "ti,omap-omap4-sgx544-112";
+ img,cores = <1>;
+};
--
2.19.1
[PATCH 7/7] ARM: DTS: omap5: add sgx gpu child node
and add timer and interrupt.
Teste on Pyra-Handheld.
Signed-off-by: H. Nikolaus Schaller
---
arch/arm/boot/dts/omap5.dtsi | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 1fb7937638f0..041a05b1cc4d 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -274,10 +274,14 @@
#size-cells = <1>;
ranges = <0 0x5600 0x200>;
- /*
-* Closed source PowerVR driver, no child device
-* binding or driver in mainline
-*/
+ sgx: sgx@0 {
+ compatible = "img,sgx544-116", "img,sgx544",
"ti,omap-omap5-sgx544-116";
+ reg = <0x0 0x1>;
+ reg-names = "sgx";
+ interrupts = ;
+ timer = <>;
+ img,cores = <2>;
+ };
};
dss: dss@5800 {
--
2.19.1
[PATCH 1/7] dt-bindings: gpu: pvrsgx: add initial bindings
The Imagination PVR/SGX GPU is part of several SoC from
multiple vendors, e.g. TI OMAP, Ingenic JZ4780, Intel Poulsbo
and others.
Here we describe how the SGX processor is interfaced to
the SoC (registers, interrupt etc.).
Clock, Reset and power management should be handled
by the parent node.
Signed-off-by: H. Nikolaus Schaller
---
.../devicetree/bindings/gpu/img,pvrsgx.txt| 76 +++
1 file changed, 76 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpu/img,pvrsgx.txt
diff --git a/Documentation/devicetree/bindings/gpu/img,pvrsgx.txt
b/Documentation/devicetree/bindings/gpu/img,pvrsgx.txt
new file mode 100644
index ..4ad87c075791
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpu/img,pvrsgx.txt
@@ -0,0 +1,76 @@
+Imagination PVR/SGX GPU
+
+Only the Imagination SGX530, SGX540 and SGX544 GPUs are currently covered by
this binding.
+
+Required properties:
+- compatible: Should be one of
+ "img,sgx530-121", "img,sgx530", "ti,omap-omap3-sgx530-121";
+ - BeagleBoard ABC, OpenPandora 600MHz
+ "img,sgx530-125", "img,sgx530", "ti,omap-omap3-sgx530-125";
+ - BeagleBoard XM, GTA04, OpenPandora 1GHz
+ "img,sgx530-125", "img,sgx530", "ti,omap-am3517-sgx530-125";
+ "img,sgx530-125", "img,sgx530", "ti,omap-am335x-sgx530-125";
+ - BeagleBone Black
+ "img,sgx540-120", "img,sgx540", "ti,omap-omap4-sgx540-120";
+ - Pandaboard (ES)
+ "img,sgx544-112", "img,sgx544", "ti,omap-omap4-sgx544-112";
+ "img,sgx544-116", "img,sgx544", "ti,omap-omap5-sgx544-116";
+ - OMAP5 UEVM, Pyra Handheld
+ "img,sgx544-116", "img,sgx544", "ti,omap-dra7-sgx544-116";
+
+ For further study:
+ "ti,omap-am3517-sgx530-?"
+ "ti,omap-am43xx-sgx530-?"
+ "ti,ti43xx-sgx"
+ "ti,ti81xx-sgx"
+ "img,jz4780-sgx5??-?"
+ "intel,poulsbo-sgx?"
+ "intel,cedarview-sgx?"
+ "sunxi,sgx-544-?" - Banana-Pi-M3 (Allwinner A83T)
+
+ The "ti,omap..." entries are needed temporarily to handle SoC
+ specific builds of the kernel module.
+
+ In the long run, only the "img,sgx..." entry should suffice
+ to match a generic driver for all architectures and driver
+ code can dynamically find out on which SoC it is running.
+
+
+- reg: Physical base addresses and lengths of the register areas.
+- reg-names: Names for the register areas.
+- interrupts: The interrupt numbers.
+
+Optional properties:
+- timer: the timer to be used by the driver.
+- img,cores: number of cores. Defaults to <1>.
+
+/ {
+ ocp {
+ sgx_module: target-module@5600 {
+ compatible = "ti,sysc-omap4", "ti,sysc";
+ reg = <0x5600fe00 0x4>,
+ <0x5600fe10 0x4>;
+ reg-names = "rev", "sysc";
+ ti,sysc-midle = ,
+ ,
+ ;
+ ti,sysc-sidle = ,
+ ,
+ ;
+ clocks = <_clkctrl OMAP5_GPU_CLKCTRL 0>;
+ clock-names = "fck";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x5600 0x200>;
+
+ sgx@fe00 {
+ compatible = "img,sgx544-116", "img,sgx544",
"ti,omap-omap5-sgx544-116";
+ reg = <0xfe00 0x200>;
+ reg-names = "sgx";
+ interrupts = ;
+ timer = <>;
+ img,cores = <2>;
+ };
+ };
+ };
+};
--
2.19.1
[PATCH 0/7] ARM: DTS: OMAP: add child nodes describing the PVRSGX present in some OMAP SoC
This patch set defines child nodes for the SGX5xx interface inside the OMAP SoC so that a driver can be found and probed by the compatible strings and can retrieve information about the SGX revision that is included in a specific SoC. It also defines the interrupt number and the timer to be used by the SGX driver. There is currently no mainline driver for these GPUs, but a project [1] is ongoing with the goal to get the open-source part as provided by TI/IMG into drivers/staging/pvr. The kernel modules built from this project have successfully demonstrated to work with the DTS definitions from this patch set on AM335x BeagleBone Black and OMAP5 Pyra. They partially works on DM3730 and PandaBoard ES but that is likely a problem in the kernel driver or the (non-free) user-space blobs. There is potential to extend this work to JZ4780 (CI20 board) and BananaPi-M3 (A83) and even some Intel Poulsbo and CedarView devices. [1]: https://github.com/openpvrsgx-devgroup H. Nikolaus Schaller (7): dt-bindings: gpu: pvrsgx: add initial bindings ARM: DTS: am33xx: add sgx gpu child node ARM: DTS: am3517: add sgx gpu child node ARM: DTS: omap3: add sgx gpu child node ARM: DTS: omap36xx: add sgx gpu child node ARM: DTS: omap4: add sgx gpu child node ARM: DTS: omap5: add sgx gpu child node .../devicetree/bindings/gpu/img,pvrsgx.txt| 76 +++ arch/arm/boot/dts/am33xx.dtsi | 11 ++- arch/arm/boot/dts/am3517.dtsi | 13 ++-- arch/arm/boot/dts/omap34xx.dtsi | 13 ++-- arch/arm/boot/dts/omap36xx.dtsi | 13 ++-- arch/arm/boot/dts/omap4.dtsi | 11 ++- arch/arm/boot/dts/omap4470.dts| 16 arch/arm/boot/dts/omap5.dtsi | 12 ++- 8 files changed, 138 insertions(+), 27 deletions(-) create mode 100644 Documentation/devicetree/bindings/gpu/img,pvrsgx.txt create mode 100644 arch/arm/boot/dts/omap4470.dts -- 2.19.1
[PATCH 5/7] ARM: DTS: omap36xx: add sgx gpu child node
and add timer and interrupt.
Tested on GTA04 and BeagleBoard XM.
Signed-off-by: H. Nikolaus Schaller
---
arch/arm/boot/dts/omap36xx.dtsi | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/omap36xx.dtsi b/arch/arm/boot/dts/omap36xx.dtsi
index 1e552f08f120..4d813cce8676 100644
--- a/arch/arm/boot/dts/omap36xx.dtsi
+++ b/arch/arm/boot/dts/omap36xx.dtsi
@@ -145,7 +145,7 @@
* "ti,sysc-omap4" type register with just sidle and midle bits
* available while omap34xx has "ti,sysc-omap2" type sysconfig.
*/
- sgx_module: target-module@5000 {
+ target-module@5000 {
compatible = "ti,sysc-omap4", "ti,sysc";
reg = <0x5000fe00 0x4>,
<0x5000fe10 0x4>;
@@ -162,10 +162,13 @@
#size-cells = <1>;
ranges = <0 0x5000 0x200>;
- /*
-* Closed source PowerVR driver, no child device
-* binding or driver in mainline
-*/
+ sgx: sgx@0 {
+ compatible = "img,sgx530-125", "img,sgx530",
"ti,omap-omap3-sgx530-125";
+ reg = <0x0 0x1>;/* 64kB */
+ reg-names = "sgx";
+ interrupts = <21>;
+ timer = <>;
+ };
};
};
--
2.19.1
[PATCH 4/7] ARM: DTS: omap3: add sgx gpu child node
and add timer and interrupt
Tested on OpenPandora 600 MHz.
Signed-off-by: H. Nikolaus Schaller
---
arch/arm/boot/dts/omap34xx.dtsi | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/omap34xx.dtsi b/arch/arm/boot/dts/omap34xx.dtsi
index 7b09cbee8bb8..28d5c77d6d6c 100644
--- a/arch/arm/boot/dts/omap34xx.dtsi
+++ b/arch/arm/boot/dts/omap34xx.dtsi
@@ -111,7 +111,7 @@
* are also different clocks, but we do not have any dts users
* for it.
*/
- sgx_module: target-module@5000 {
+ target-module@5000 {
compatible = "ti,sysc-omap2", "ti,sysc";
reg = <0x5014 0x4>;
reg-names = "rev";
@@ -121,10 +121,13 @@
#size-cells = <1>;
ranges = <0 0x5000 0x4000>;
- /*
-* Closed source PowerVR driver, no child device
-* binding or driver in mainline
-*/
+ sgx: sgx@0 {
+ compatible = "img,sgx530-121", "img,sgx530",
"ti,omap-omap3-sgx530-121";
+ reg = <0x0 0x4000>; /* 64kB */
+ reg-names = "sgx";
+ interrupts = <21>;
+ timer = <>;
+ };
};
};
--
2.19.1
[PATCH 3/7] ARM: DTS: am3517: add sgx gpu child node
and add timer and interrupt.
Signed-off-by: H. Nikolaus Schaller
---
arch/arm/boot/dts/am3517.dtsi | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/am3517.dtsi b/arch/arm/boot/dts/am3517.dtsi
index bf3002009b00..5716bb33d7fe 100644
--- a/arch/arm/boot/dts/am3517.dtsi
+++ b/arch/arm/boot/dts/am3517.dtsi
@@ -97,7 +97,7 @@
* revision register instead of the unreadable OCP revision
* register.
*/
- sgx_module: target-module@5000 {
+ target-module@5000 {
compatible = "ti,sysc-omap2", "ti,sysc";
reg = <0x5014 0x4>;
reg-names = "rev";
@@ -107,10 +107,13 @@
#size-cells = <1>;
ranges = <0 0x5000 0x4000>;
- /*
-* Closed source PowerVR driver, no child device
-* binding or driver in mainline
-*/
+ sgx: sgx@0 {
+ compatible = "img,sgx530-125", "img,sgx530",
"ti,omap-am3517-sgx530-125";
+ reg = <0x0 0x4000>;
+ reg-names = "sgx";
+ interrupts = <21>;
+ timer = <>;
+ };
};
};
};
--
2.19.1
Re: [PATCH] drm: include for 'drm_need_swiotlb'
On Thu, Oct 17, 2019 at 12:08:46PM +0100, Ben Dooks (Codethink) wrote: > The drm_need_swiotlb is declared in > which should be included in drivers/gpu/drm/drm_memory.c > to silence the following warning: > > drivers/gpu/drm/drm_memory.c:159:6: warning: symbol 'drm_need_swiotlb' was > not declared. Should it be static? IIRC I silenced that already, so you're probably working on some old tree. For the latest stuff use: git://anongit.freedesktop.org/drm-tip drm-tip > > Signed-off-by: Ben Dooks > --- > Cc: Maarten Lankhorst > Cc: Maxime Ripard > Cc: Sean Paul > Cc: David Airlie > Cc: Daniel Vetter > Cc: dri-devel@lists.freedesktop.org > --- > drivers/gpu/drm/drm_memory.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/drm_memory.c b/drivers/gpu/drm/drm_memory.c > index 0bec6dbb0142..2d8615baeadc 100644 > --- a/drivers/gpu/drm/drm_memory.c > +++ b/drivers/gpu/drm/drm_memory.c > @@ -41,6 +41,7 @@ > > #include > #include > +#include > > #include "drm_legacy.h" > > -- > 2.23.0 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Ville Syrjälä Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: Tree for Oct 16 (amd display)
On 10/15/19 10:17 PM, Stephen Rothwell wrote: > Hi all, > > Changes since 20191015: > on x86_64: ../drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_resource.c: In function ‘dcn20_populate_dml_pipes_from_context’: ../drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_resource.c:1913:48: error: ‘struct dc_crtc_timing_flags’ has no member named ‘DSC’ if (res_ctx->pipe_ctx[i].stream->timing.flags.DSC) ^ ../drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_resource.c:1914:73: error: ‘struct dc_crtc_timing’ has no member named ‘dsc_cfg’ pipes[pipe_cnt].dout.output_bpp = res_ctx->pipe_ctx[i].stream->timing.dsc_cfg.bits_per_pixel / 16.0; ^ Full randconfig file is attached. -- ~Randy # # Automatically generated file; DO NOT EDIT. # Linux/x86_64 5.4.0-rc3 Kernel Configuration # # # Compiler: gcc (SUSE Linux) 7.4.1 20190424 [gcc-7-branch revision 270538] # CONFIG_CC_IS_GCC=y CONFIG_GCC_VERSION=70401 CONFIG_CLANG_VERSION=0 CONFIG_CC_CAN_LINK=y CONFIG_CC_HAS_ASM_GOTO=y CONFIG_CC_HAS_ASM_INLINE=y CONFIG_CC_HAS_WARN_MAYBE_UNINITIALIZED=y CONFIG_CC_DISABLE_WARN_MAYBE_UNINITIALIZED=y CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y CONFIG_THREAD_INFO_IN_TASK=y # # General setup # CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 # CONFIG_COMPILE_TEST is not set CONFIG_HEADER_TEST=y # CONFIG_KERNEL_HEADER_TEST is not set # CONFIG_UAPI_HEADER_TEST is not set CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_BUILD_SALT="" CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_HAVE_KERNEL_LZ4=y CONFIG_KERNEL_GZIP=y # CONFIG_KERNEL_BZIP2 is not set # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set # CONFIG_KERNEL_LZ4 is not set CONFIG_DEFAULT_HOSTNAME="(none)" CONFIG_SWAP=y # CONFIG_SYSVIPC is not set # CONFIG_CROSS_MEMORY_ATTACH is not set # CONFIG_USELIB is not set CONFIG_HAVE_ARCH_AUDITSYSCALL=y # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_IRQ_DOMAIN=y CONFIG_IRQ_SIM=y CONFIG_IRQ_DOMAIN_HIERARCHY=y CONFIG_GENERIC_MSI_IRQ=y CONFIG_GENERIC_MSI_IRQ_DOMAIN=y CONFIG_IRQ_MSI_IOMMU=y CONFIG_GENERIC_IRQ_MATRIX_ALLOCATOR=y CONFIG_GENERIC_IRQ_RESERVATION_MODE=y CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y CONFIG_GENERIC_IRQ_DEBUGFS=y # end of IRQ subsystem CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_ARCH_CLOCKSOURCE_DATA=y CONFIG_ARCH_CLOCKSOURCE_INIT=y CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y CONFIG_GENERIC_CMOS_UPDATE=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ_COMMON=y # CONFIG_HZ_PERIODIC is not set CONFIG_NO_HZ_IDLE=y CONFIG_NO_HZ=y # CONFIG_HIGH_RES_TIMERS is not set # end of Timers subsystem CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set CONFIG_PREEMPT_COUNT=y # # CPU/Task time and stats accounting # CONFIG_TICK_CPU_ACCOUNTING=y # CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set CONFIG_IRQ_TIME_ACCOUNTING=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y CONFIG_PSI=y CONFIG_PSI_DEFAULT_DISABLED=y # end of CPU/Task time and stats accounting # # RCU Subsystem # CONFIG_TINY_RCU=y # CONFIG_RCU_EXPERT is not set CONFIG_SRCU=y CONFIG_TINY_SRCU=y CONFIG_TASKS_RCU=y # end of RCU Subsystem CONFIG_BUILD_BIN2C=y CONFIG_IKCONFIG=m CONFIG_IKHEADERS=m CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y # # Scheduler features # # end of Scheduler features CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y CONFIG_ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH=y CONFIG_ARCH_SUPPORTS_INT128=y CONFIG_CGROUPS=y # CONFIG_MEMCG is not set CONFIG_BLK_CGROUP=y CONFIG_CGROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y CONFIG_CFS_BANDWIDTH=y # CONFIG_RT_GROUP_SCHED is not set # CONFIG_CGROUP_PIDS is not set CONFIG_CGROUP_RDMA=y CONFIG_CGROUP_FREEZER=y # CONFIG_CGROUP_DEVICE is not set CONFIG_CGROUP_CPUACCT=y CONFIG_CGROUP_PERF=y # CONFIG_CGROUP_DEBUG is not set CONFIG_NAMESPACES=y CONFIG_UTS_NS=y # CONFIG_USER_NS is not set # CONFIG_PID_NS is not set CONFIG_CHECKPOINT_RESTORE=y CONFIG_SCHED_AUTOGROUP=y CONFIG_SYSFS_DEPRECATED=y # CONFIG_SYSFS_DEPRECATED_V2 is not set CONFIG_RELAY=y # CONFIG_BLK_DEV_INITRD is not set # CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL_EXCEPTION_TRACE=y CONFIG_HAVE_PCSPKR_PLATFORM=y CONFIG_EXPERT=y CONFIG_MULTIUSER=y # CONFIG_SGETMASK_SYSCALL is not set CONFIG_SYSFS_SYSCALL=y # CONFIG_FHANDLE is not set CONFIG_POSIX_TIMERS=y # CONFIG_PRINTK is not set # CONFIG_BUG is not set CONFIG_PCSPKR_PLATFORM=y CONFIG_BASE_FULL=y # CONFIG_FUTEX is not set CONFIG_EPOLL=y CONFIG_SIGNALFD=y # CONFIG_TIMERFD is not set # CONFIG_EVENTFD is not set CONFIG_SHMEM=y CONFIG_AIO=y # CONFIG_IO_URING is not set # CONFIG_ADVISE_SYSCALLS is not
[PATCH] drm/amdgpu/display: fix compile error
From: Chenwandun drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_resource.c:1913:48: error: struct dc_crtc_timing_flags has no member named DSC if (res_ctx->pipe_ctx[i].stream->timing.flags.DSC) ^ drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_resource.c:1914:73: error: struct dc_crtc_timing has no member named dsc_cfg pipes[pipe_cnt].dout.output_bpp = res_ctx->pipe_ctx[i].stream->timing.dsc_cfg.bits_per_pixel / 16.0; ^ Signed-off-by: Chenwandun --- drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c index 914e378..4f03318 100644 --- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c +++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c @@ -1910,8 +1910,10 @@ int dcn20_populate_dml_pipes_from_context( pipes[pipe_cnt].dout.output_bpp = output_bpc * 3; } +#ifdef CONFIG_DRM_AMD_DC_DSC_SUPPORT if (res_ctx->pipe_ctx[i].stream->timing.flags.DSC) pipes[pipe_cnt].dout.output_bpp = res_ctx->pipe_ctx[i].stream->timing.dsc_cfg.bits_per_pixel / 16.0; +#endif /* todo: default max for now, until there is logic reflecting this in dc*/ pipes[pipe_cnt].dout.output_bpc = 12; -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] omapfb: reduce stack usage
On Fri, Oct 18, 2019 at 05:30:04PM +0100, Sudip Mukherjee wrote:
> The build of xtensa allmodconfig is giving a warning of:
> In function 'dsi_dump_dsidev_irqs':
> warning: the frame size of 1120 bytes is larger than 1024 bytes
>
> Allocate the memory for 'struct dsi_irq_stats' dynamically instead
> of assigning it in stack.
So now function can fail silently, executes longer, code is sligthly
bigger... And all that to silent warning about exceeding frame size.
Is it really worth "fixing"?
> Signed-off-by: Sudip Mukherjee
> ---
> drivers/video/fbdev/omap2/omapfb/dss/dsi.c | 24 ++--
> 1 file changed, 14 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dsi.c
> b/drivers/video/fbdev/omap2/omapfb/dss/dsi.c
> index d620376216e1..43402467bf40 100644
> --- a/drivers/video/fbdev/omap2/omapfb/dss/dsi.c
> +++ b/drivers/video/fbdev/omap2/omapfb/dss/dsi.c
> @@ -1536,22 +1536,25 @@ static void dsi_dump_dsidev_irqs(struct
> platform_device *dsidev,
> {
> struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
> unsigned long flags;
> - struct dsi_irq_stats stats;
> + struct dsi_irq_stats *stats;
>
> + stats = kmalloc(sizeof(*stats), GFP_KERNEL);
> + if (!stats)
> + return;
> spin_lock_irqsave(>irq_stats_lock, flags);
>
> - stats = dsi->irq_stats;
> + memcpy(stats, >irq_stats, sizeof(*stats));
> memset(>irq_stats, 0, sizeof(dsi->irq_stats));
> dsi->irq_stats.last_reset = jiffies;
>
> spin_unlock_irqrestore(>irq_stats_lock, flags);
>
> seq_printf(s, "period %u ms\n",
> - jiffies_to_msecs(jiffies - stats.last_reset));
> + jiffies_to_msecs(jiffies - stats->last_reset));
>
> - seq_printf(s, "irqs %d\n", stats.irq_count);
> + seq_printf(s, "irqs %d\n", stats->irq_count);
> #define PIS(x) \
> - seq_printf(s, "%-20s %10d\n", #x, stats.dsi_irqs[ffs(DSI_IRQ_##x)-1]);
> + seq_printf(s, "%-20s %10d\n", #x, stats->dsi_irqs[ffs(DSI_IRQ_##x)-1]);
>
> seq_printf(s, "-- DSI%d interrupts --\n", dsi->module_id + 1);
> PIS(VC0);
> @@ -1575,10 +1578,10 @@ static void dsi_dump_dsidev_irqs(struct
> platform_device *dsidev,
>
> #define PIS(x) \
> seq_printf(s, "%-20s %10d %10d %10d %10d\n", #x, \
> - stats.vc_irqs[0][ffs(DSI_VC_IRQ_##x)-1], \
> - stats.vc_irqs[1][ffs(DSI_VC_IRQ_##x)-1], \
> - stats.vc_irqs[2][ffs(DSI_VC_IRQ_##x)-1], \
> - stats.vc_irqs[3][ffs(DSI_VC_IRQ_##x)-1]);
> + stats->vc_irqs[0][ffs(DSI_VC_IRQ_##x)-1], \
> + stats->vc_irqs[1][ffs(DSI_VC_IRQ_##x)-1], \
> + stats->vc_irqs[2][ffs(DSI_VC_IRQ_##x)-1], \
> + stats->vc_irqs[3][ffs(DSI_VC_IRQ_##x)-1]);
>
> seq_printf(s, "-- VC interrupts --\n");
> PIS(CS);
> @@ -1594,7 +1597,7 @@ static void dsi_dump_dsidev_irqs(struct platform_device
> *dsidev,
>
> #define PIS(x) \
> seq_printf(s, "%-20s %10d\n", #x, \
> - stats.cio_irqs[ffs(DSI_CIO_IRQ_##x)-1]);
> + stats->cio_irqs[ffs(DSI_CIO_IRQ_##x)-1]);
>
> seq_printf(s, "-- CIO interrupts --\n");
> PIS(ERRSYNCESC1);
> @@ -1618,6 +1621,7 @@ static void dsi_dump_dsidev_irqs(struct platform_device
> *dsidev,
> PIS(ULPSACTIVENOT_ALL0);
> PIS(ULPSACTIVENOT_ALL1);
> #undef PIS
> + kfree(stats);
> }
>
> static void dsi1_dump_irqs(struct seq_file *s)
> --
> 2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 00/46] ARM: pxa: towards multiplatform support
Hi PXA maintainers,
I'm in the process of getting the old ARM platforms to all build
in a single kernel. The largest part of that work is changing all
the device drivers to no longer require mach/*.h header files.
This series does it for arch/pxa/.
As with the omap1 and s3c24xx series I sent before, I don't
expect this all to be correct in the first version, though
a lot of the patches are fairly simple and I did exhaustive
compile-time testing on them.
Please test if you have the hardware, or review!
Arnd
Bcc: Alexandre Belloni
Bcc: alsa-de...@alsa-project.org
Bcc: Bartlomiej Zolnierkiewicz
Bcc: Brian Norris
Bcc: Daniel Thompson
Bcc: David Woodhouse
Bcc: Dmitry Torokhov
Bcc: Dominik Brodowski
Bcc: dri-devel@lists.freedesktop.org
Bcc: Felipe Balbi
Bcc: Greg Kroah-Hartman
Bcc: Guenter Roeck
Bcc: Jacek Anaszewski
Bcc: Jens Axboe
Bcc: Jingoo Han
Bcc: Jonathan Cameron
Bcc: Lee Jones
Bcc: Lubomir Rintel
Bcc: Marek Vasut
Bcc: Mark Brown
Bcc: Michael Turquette
Bcc: Miquel Raynal
Bcc: Paul Parsons
Bcc: Pavel Machek
Bcc: Philipp Zabel
Bcc: "Rafael J. Wysocki"
Bcc: Richard Weinberger
Bcc: Russell King
Bcc: Sebastian Reichel
Bcc: Sergey Lapin
Bcc: Stephen Boyd
Bcc: Tomas Cech
Bcc: Ulf Hansson
Bcc: Vignesh Raghavendra
Bcc: Viresh Kumar
Bcc: Wim Van Sebroeck
Cc: linux-...@vger.kernel.org
Cc: linux-fb...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-in...@vger.kernel.org
Cc: linux-l...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-...@lists.infradead.org
Cc: linux...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-watch...@vger.kernel.org
Arnd Bergmann (46):
ARM: pxa: split mach/generic.h
ARM: pxa: make mainstone.h private
ARM: pxa: make mach/regs-uart.h private
ARM: pxa: remove mach/dma.h
ARM: pxa: split up mach/hardware.h
ARM: pxa: stop using mach/bitfield.h
ARM: pxa: move mach/sound.h to linux/platform_data/
ARM: pxa: move regs-lcd.h into driver
watchdog: sa1100: use platform device registration
ARM: pxa: pxa2xx-ac97-lib: use IRQ resource
ARM: pxa: cmx270: use platform device for nand
ARM: pxa: make addr-map.h header local
ARM: pxa: move pcmcia board data into mach-pxa
ARM: pxa: use pdev resource for palmld mmio
ARM: pxa: maybe fix gpio lookup tables
ARM: pxa: tosa: use gpio descriptor for audio
ARM: pxa: poodle: use platform data for poodle asoc driver
ARM: pxa: corgi: use gpio descriptors for audio
ARM: pxa: hx4700: use gpio descriptors for audio
ARM: pxa: lubbock: pass udc irqs as resource
ARM: pxa: spitz: use gpio descriptors for audio
ARM: pxa: eseries: use gpio lookup for audio
ARM: pxa: z2: use gpio lookup for audio device
ARM: pxa: magician: use platform driver for audio
ARM: pxa: mainstone-wm97xx: use gpio lookup table
ARM: pxa: zylonite: use gpio lookup instead mfp header
input: touchscreen: mainstone: fix pxa2xx+pxa3xx configuration
input: touchscreen: mainstone: sync with zylonite driver
Input: touchscreen: use wrapper for pxa2xx ac97 registers
SoC: pxa: use pdev resource for FIFO regs
ASoC: pxa: ac97: use normal MMIO accessors
ASoC: pxa: i2s: use normal MMIO accessors
ARM: pxa: pcmcia: move smemc configuration back to arch
ARM: pxa: remove get_clk_frequency_khz()
cpufreq: pxa3: move clk register access to clk driver
ARM: pxa: move smemc register access from clk to platform
ARM: pxa: move clk register definitions to driver
video: backlight: tosa: use gpio lookup table
power: tosa: simplify probe function
ARM: pxa: tosa: use gpio lookup for battery
ARM: pxa: move it8152 PCI support into machine
ARM: pxa: remove unused mach/bitfield.h
ARM: pxa: pci-it8152: add platform checks
ARM: mmp: remove tavorevb board support
ARM: mmp: rename pxa_register_device
ARM: pxa: move plat-pxa to drivers/soc/
arch/arm/Kconfig | 9 -
arch/arm/Makefile | 1 -
arch/arm/common/Makefile | 1 -
arch/arm/common/locomo.c | 1 -
arch/arm/common/sa.c | 5 +-
arch/arm/include/asm/hardware/sa.h| 2 -
arch/arm/mach-mmp/Kconfig | 10 +-
arch/arm/mach-mmp/Makefile| 1 -
arch/arm/mach-mmp/devices.c | 2 +-
arch/arm/mach-mmp/devices.h | 10 +-
arch/arm/mach-mmp/mfp.h | 2 +-
arch/arm/mach-mmp/mmp2.h | 48 ++---
arch/arm/mach-mmp/pxa168.h| 60 +++---
arch/arm/mach-mmp/pxa910.h| 38 ++--
arch/arm/mach-mmp/tavorevb.c | 113 ---
arch/arm/mach-mmp/ttc_dkb.c | 6 +-
arch/arm/mach-pxa/Kconfig | 8 +-
arch/arm/mach-pxa/Makefile| 22 +-
.../mach-pxa/{include/mach => }/addr-map.h| 0
.../arm/mach-pxa/balloon3-pcmcia.c| 4 +-
Re: [RESEND][PATCH v8 0/5] DMA-BUF Heaps (destaging ION)
On Fri, Oct 18, 2019 at 09:55:17AM +, Brian Starkey wrote:
> On Thu, Oct 17, 2019 at 01:57:45PM -0700, John Stultz wrote:
> > On Thu, Oct 17, 2019 at 12:29 PM Andrew F. Davis wrote:
> > > On 10/17/19 3:14 PM, John Stultz wrote:
> > > > But if the objection stands, do you have a proposal for an alternative
> > > > way to enumerate a subset of CMA heaps?
> > > >
> > > When in staging ION had to reach into the CMA framework as the other
> > > direction would not be allowed, so cma_for_each_area() was added. If
> > > DMA-BUF heaps is not in staging then we can do the opposite, and have
> > > the CMA framework register heaps itself using our framework. That way
> > > the CMA system could decide what areas to export or not (maybe based on
> > > a DT property or similar).
> >
> > Ok. Though the CMA core doesn't have much sense of DT details either,
> > so it would probably have to be done in the reserved_mem logic, which
> > doesn't feel right to me.
> >
> > I'd probably guess we should have some sort of dt binding to describe
> > a dmabuf cma heap and from that node link to a CMA node via a
> > memory-region phandle. Along with maybe the default heap as well? Not
> > eager to get into another binding review cycle, and I'm not sure what
> > non-DT systems will do yet, but I'll take a shot at it and iterate.
> >
> > > The end result is the same so we can make this change later (it has to
> > > come after DMA-BUF heaps is in anyway).
> >
> > Well, I'm hesitant to merge code that exposes all the CMA heaps and
> > then add patches that becomes more selective, should anyone depend on
> > the initial behavior. :/
>
> How about only auto-adding the system default CMA region (cma->name ==
> "reserved")?
>
> And/or the CMA auto-add could be behind a config option? It seems a
> shame to further delay this, and the CMA heap itself really is useful.
>
A bit of a detour, comming back to the issue why the following node
was not getting detected by the dma-buf heaps framework.
reserved-memory {
#address-cells = <2>;
#size-cells = <2>;
ranges;
display_reserved: framebuffer@6000 {
compatible = "shared-dma-pool";
linux,cma-default;
reusable; ---This was missing in our
earlier node
reg = <0 0x6000 0 0x0800>;
};
Quoting reserved-memory.txt :-
"The operating system can use the memory in this region with the limitation that
the device driver(s) owning the region need to be able to reclaim it back"
Thus as per my observation, without 'reusable', rmem_cma_setup()
returns -EINVAL and the reserved-memory is not added as a cma region.
With 'reusable', rmem_cma_setup() succeeds , but the kernel crashes as follows
:-
[0.450562] WARNING: CPU: 2 PID: 1 at mm/cma.c:110
cma_init_reserved_areas+0xec/0x22c
[0.458415] Modules linked in:
[0.461470] CPU: 2 PID: 1 Comm: swapper/0 Not tainted
5.3.0-rc4-01377-g51dbcf03884c-dirty #15
[0.470017] Hardware name: ARM Juno development board (r0) (DT)
[0.475953] pstate: 8005 (Nzcv daif -PAN -UAO)
[0.480755] pc : cma_init_reserved_areas+0xec/0x22c
[0.485643] lr : cma_init_reserved_areas+0xe8/0x22c
[0.600646] Unable to handle kernel paging request at virtual address
7d80
[0.608591] Mem abort info:
[0.611386] ESR = 0x9606
<---snip uninteresting bits --->
[0.681069] pc : cma_init_reserved_areas+0x114/0x22c
[0.686043] lr : cma_init_reserved_areas+0xe8/0x22c
I am looking into this now. My final objective is to get
"/dev/dma_heap/framebuffer"
(as a cma heap).
Any leads?
> Cheers,
> -Brian
>
> >
> > So, , I'll start on the rework for the CMA bits.
> >
> > That said, I'm definitely wanting to make some progress on this patch
> > series, so maybe we can still merge the core/helpers/system heap and
> > just hold the cma heap for a rework on the enumeration bits. That way
> > we can at least get other folks working on switching their vendor
> > heaps from ION.
> >
> > Sumit: Does that sound ok? Assuming no other objections, can you take
> > the v11 set minus the CMA heap patch?
> >
> > thanks
> > -john
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH -next] drm/amd/display: Make dc_link_detect_helper static
Fix sparse warning:
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:746:6:
warning: symbol 'dc_link_detect_helper' was not declared. Should it be static?
Reported-by: Hulk Robot
Signed-off-by: YueHaibing
---
drivers/gpu/drm/amd/display/dc/core/dc_link.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
index fb18681..9350536 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
@@ -743,7 +743,8 @@ static bool wait_for_alt_mode(struct dc_link *link)
* This does not create remote sinks but will trigger DM
* to start MST detection if a branch is detected.
*/
-bool dc_link_detect_helper(struct dc_link *link, enum dc_detect_reason reason)
+static bool dc_link_detect_helper(struct dc_link *link,
+ enum dc_detect_reason reason)
{
struct dc_sink_init_data sink_init_data = { 0 };
struct display_sink_capability sink_caps = { 0 };
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: XDC allocator workshop and Wayland dmabuf hints
On Thu, 17 Oct 2019 12:09:44 +0300 Pekka Paalanen said: > On Mon, 14 Oct 2019 06:02:59 -0700 > James Jones wrote: > > > On 10/13/19 2:05 PM, Scott Anderson wrote: > > > (Sorry to CCs for spam, I made an error in my first posting) > > > > > > Hi, > > > > > > There were certainly some interesting changes discussed at the allocator > > > workshop during XDC this year, and I'd like to just summarise my > > > thoughts on it and make sure everybody is on the same page. > > Hi Scott and James, > > thanks for the write-up, it all sounds good to me FWI'mW. > > > > -As you note, this limits things to formats/layouts that can be > > composited (basically, things that can be textures). "Things that can > > be textures" is a superset of "Things that can be scanned out" for these > > purposes on our HW, so that's fine for NVIDIA. Does that hold up > > elsewhere? A secondary motivation for me was that the compositor could > > transition back to compositing from overlay compositing without > > requiring a blit or a new frame from the client in cases where that > > didn't hold up, but I don't know if that's interesting or not. > > It is interesting. > > The compositor transitioning back from overlay to compositing without > requiring a new frame from the client is a minimum requirement under > normal circumstances in Wayland architecture. If a compositor cannot do > that because of a buffer format, how could a conversion blit be > possible either? > > In Wayland architecture, having the compositor (display server) wait > for any client before it is able to update the screen is unacceptable > because it has a high risk of disturbing visual glitches. Or it has the result of a single non-responsive client holding the compositor hostage, unable to update the screen until that client responds. This also would be unacceptable. This requires there be a hardware accelerated conversion "blitter" somewhere that is able to convert between such displayable and non displayable formats, and/or that all such formats be clearly specified and documented and such conversions need to be done on the CPU as a fallback. Unless of course we're dealing with the kinds of content that are "secure" or "encrypted" etc. with some kind of DRM (digital rights management) scheme in place where the whole point is to have that buffer only ever displayable as a hardware plane. In these cases The compositor can replace such buffers with a picture of a horse to indicate that that buffer is not intended to be visible when it has to fall back to a composited path, but it needs to know that this is intended vs. a bug. > OTOH, I have heard of special use cases, where all buffers should > always go on overlays and falling back to composition would be > considered a bug. For such cases, there are some ideas towards that at > https://gitlab.freedesktop.org/wayland/weston/issues/244 . > > > Thanks, > pq -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] backlight: pwm_bl: configure pwm only once per backlight toggle
On 17. 10. 19 11:48, Michal Vokáč wrote:
On 17. 10. 19 10:10, Uwe Kleine-König wrote:
A previous change in the pwm core (namely 01ccf903edd6 ("pwm: Let
pwm_get_state() return the last implemented state")) changed the
semantic of pwm_get_state() and disclosed an (as it seems) common
problem in lowlevel PWM drivers. By not relying on the period and duty
cycle being retrievable from a disabled PWM this type of problem is
worked around.
Apart from this issue only calling the pwm_get_state/pwm_apply_state
combo once is also more effective.
Signed-off-by: Uwe Kleine-König
---
Hello,
There are now two reports about 01ccf903edd6 breaking a backlight. As
far as I understand the problem this is a combination of the backend pwm
driver yielding surprising results and the pwm-bl driver doing things
more complicated than necessary.
So I guess this patch works around these problems. Still it would be
interesting to find out the details in the imx driver that triggers the
problem. So Adam, can you please instrument the pwm-imx27 driver to
print *state at the beginning of pwm_imx27_apply() and the end of
pwm_imx27_get_state() and provide the results?
Note I only compile tested this change.
Hi Uwe,
I was just about to respond to the "pwm_bl on i.MX6Q broken on 5.4-RC1+"
thread that I have a similar problem when you submitted this patch.
So here are my few cents:
Once again with updated and more detailed debug messages.
My setup is as follows:
- imx6dl-yapp4-draco with i.MX6Solo
- backlight is controlled with inverted PWM signal
- max brightness level = 32, default brightness level set to 32 in DT.
1. Almost correct backlight behavior before 01ccf903edd6 ("pwm: Let
pwm_get_state() return the last implemented state):
- System boots to userspace and backlight is enabled all the time from
power up.
- $ dmesg | grep pwm_
[1.761546] pwm_imx27_get_state: period: 992970, duty: 0, polarity: 0,
enabled: 0
[5.012352] pwm_imx27_apply: period: 50, duty: 0, polarity: 1,
enabled: 0
[5.021143] pwm_imx27_apply: period: 50, duty: 50, polarity:
1, enabled: 0
[5.030182] pwm_imx27_apply: period: 50, duty: 50, polarity:
1, enabled: 1
- $ cat brightness
32
- $ echo 32 > brightness # nothing happens, max. brightness
- $ echo 1 > brightness # backlight goes down to lowest level
[ 93.976354] pwm_imx27_apply: period: 50, duty: 7843, polarity: 1,
enabled: 1
- $ echo 0 > brightness # backlight goes up to max. level, this is
# problem of the inverted PWM on i.MX we attempted
# to solve some time ago.
[ 115.496350] pwm_imx27_apply: period: 50, duty: 0, polarity: 1,
enabled: 0
2. Backlight behavior on v5.4-rc3:
- System boots to userspace and backlight is enabled all the time from
power up.
- $ dmesg | grep pwm_
[1.774071] pwm_imx27_get_state: period: 992970, duty: 0, polarity: 0,
enabled: 0
[5.003961] pwm_imx27_apply: period: 50, duty: 0, polarity: 1,
enabled: 0
[5.012649] pwm_imx27_get_state: period: 992970, duty: 0, polarity: 0,
enabled: 0
[5.021694] pwm_imx27_apply: period: 992970, duty: 992970, polarity:
0, enabled: 0
[5.030732] pwm_imx27_get_state: period: 992970, duty: 0, polarity: 0,
enabled: 0
[5.039643] pwm_imx27_apply: period: 992970, duty: 0, polarity: 0,
enabled: 1
[5.049605] pwm_imx27_get_state: period: 992970, duty: 0, polarity: 0,
enabled: 1
- $ cat brightness
32
- $ echo 32 > brightness # backlight goes down
[ 707.946970] pwm_imx27_apply: period: 992970, duty: 992970, polarity:
0, enabled: 1
[ 707.958551] pwm_imx27_get_state: period: 992970, duty: 992970,
polarity: 0, enabled: 1
- $ echo 1 > brightness # backlight goes up to high level
[ 757.516845] pwm_imx27_apply: period: 992970, duty: 15576, polarity: 0,
enabled: 1
[ 757.528438] pwm_imx27_get_state: period: 992970, duty: 15576,
polarity: 0, enabled: 1
- $ echo 0 > brightness # backlight goes up to highest level
[ 783.386838] pwm_imx27_apply: period: 992970, duty: 0, polarity: 0,
enabled: 0
[ 783.398025] pwm_imx27_get_state: period: 496485, duty: 0, polarity: 0,
enabled: 0
So the behavior is clearly inverted to how it worked prior to 01ccf903edd6
with the weird exception that the initial brightness level 32 is
not applied.
3. Backlight behavior on v5.4-rc3 + this patch:
- System boots with backlight enabled. In the middle of kernel boot
backlight is disabled.
- $ dmesg | grep state
[1.773099] pwm_imx27_get_state: period: 992970, duty: 0, polarity: 0,
enabled: 0
[5.002532] pwm_imx27_apply: period: 50, duty: 0, polarity: 1,
enabled: 0
[5.011263] pwm_imx27_get_state: period: 992970, duty: 0, polarity: 0,
enabled: 0
[5.020307] pwm_imx27_apply: period: 992970, duty:
Re: [PATCH 10/14] drm/tegra: Move IOMMU group into host1x client
14.10.2019 15:50, Thierry Reding пишет: > From: Thierry Reding > > Handling of the IOMMU group attachment is common to all clients, so move > the group into the client to simplify code. > > Signed-off-by: Thierry Reding > --- > drivers/gpu/drm/tegra/dc.c | 9 - > drivers/gpu/drm/tegra/dc.h | 2 -- > drivers/gpu/drm/tegra/drm.c | 22 +++--- > drivers/gpu/drm/tegra/drm.h | 6 ++ > drivers/gpu/drm/tegra/gr2d.c | 10 -- > drivers/gpu/drm/tegra/gr3d.c | 10 -- > drivers/gpu/drm/tegra/vic.c | 10 -- > include/linux/host1x.h | 2 ++ > 8 files changed, 31 insertions(+), 40 deletions(-) Hello Thierry, Is there any chance that you could pick up these patches [0] and rebase yours series on top of them? [0] https://patchwork.ozlabs.org/project/linux-tegra/list/?series=115608 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 10/14] drm/tegra: Move IOMMU group into host1x client
16.10.2019 18:33, Dmitry Osipenko пишет: > 14.10.2019 15:50, Thierry Reding пишет: >> From: Thierry Reding >> >> Handling of the IOMMU group attachment is common to all clients, so move >> the group into the client to simplify code. >> >> Signed-off-by: Thierry Reding >> --- >> drivers/gpu/drm/tegra/dc.c | 9 - >> drivers/gpu/drm/tegra/dc.h | 2 -- >> drivers/gpu/drm/tegra/drm.c | 22 +++--- >> drivers/gpu/drm/tegra/drm.h | 6 ++ >> drivers/gpu/drm/tegra/gr2d.c | 10 -- >> drivers/gpu/drm/tegra/gr3d.c | 10 -- >> drivers/gpu/drm/tegra/vic.c | 10 -- >> include/linux/host1x.h | 2 ++ >> 8 files changed, 31 insertions(+), 40 deletions(-) > > Hello Thierry, > > Is there any chance that you could pick up these patches [0] and rebase > yours series on top of them? > > [0] https://patchwork.ozlabs.org/project/linux-tegra/list/?series=115608 > I want to clarify that the reason of my request is that "Fix 2d and 3d clients detaching from IOMMU domain" patch won't be backportable if I'll rebase my patches on top this series and it looks to me that it won't be the least to fix the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3] drm/i915: Don't disable interrupts independently of the lock
The locks (active.lock and rq->lock) need to be taken with disabled
interrupts. This is done in i915_request_retire() by disabling the
interrupts independently of the locks itself.
While local_irq_disable()+spin_lock() equals spin_lock_irq() on vanilla
it does not on PREEMPT_RT.
Chris Wilson confirmed that local_irq_disable() was just introduced as
an optimisation to avoid enabling/disabling interrupts during
lock/unlock combo.
Enable/disable interrupts as part of the locking instruction.
Cc: Chris Wilson
Reviewed-by: Chris Wilson
Signed-off-by: Sebastian Andrzej Siewior
---
v2…v3: Rebase on top of drm-intel-next-queued
v1…v2: Rebase to v5.4-rc3
drivers/gpu/drm/i915/i915_request.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index f1cadad4e81ca..4575f368455d5 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -206,14 +206,14 @@ static void remove_from_engine(struct i915_request *rq)
* check that the rq still belongs to the newly locked engine.
*/
locked = READ_ONCE(rq->engine);
- spin_lock(>active.lock);
+ spin_lock_irq(>active.lock);
while (unlikely(locked != (engine = READ_ONCE(rq->engine {
spin_unlock(>active.lock);
spin_lock(>active.lock);
locked = engine;
}
list_del(>sched.link);
- spin_unlock(>active.lock);
+ spin_unlock_irq(>active.lock);
}
bool i915_request_retire(struct i915_request *rq)
@@ -242,8 +242,6 @@ bool i915_request_retire(struct i915_request *rq)
_request_timeline(rq)->requests));
rq->ring->head = rq->postfix;
- local_irq_disable();
-
/*
* We only loosely track inflight requests across preemption,
* and so we may find ourselves attempting to retire a _completed_
@@ -252,7 +250,7 @@ bool i915_request_retire(struct i915_request *rq)
*/
remove_from_engine(rq);
- spin_lock(>lock);
+ spin_lock_irq(>lock);
i915_request_mark_complete(rq);
if (!i915_request_signaled(rq))
dma_fence_signal_locked(>fence);
@@ -267,9 +265,7 @@ bool i915_request_retire(struct i915_request *rq)
__notify_execute_cb(rq);
}
GEM_BUG_ON(!list_empty(>execute_cb));
- spin_unlock(>lock);
-
- local_irq_enable();
+ spin_unlock_irq(>lock);
remove_from_client(rq);
list_del(>link);
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7] unstable/drm-lease: DRM lease protocol support
Regarding hotplugging, the Wayland compositor is probably keeping track of hotplugs itself and withdrawing/offering connectors as appropriate. Also, when the lease is issued, the compositor withdraws that connector. For the client, upon hotplug I imagine the DRM asks start to fail, and it handles that accordingly (presumably it'll close the lease, if the compositor hasn't already, and wait for it to come back, or just exit). When a hotplug of a leased connector happens on the compositor side, it can notice this and exercise its descretion in the implementation. I think the current text of the protocol supports this view. On Fri Oct 18, 2019 at 5:34 PM Pekka Paalanen wrote: > > So the rules are (if I'm not making a mistake) > > - If you're not CAP_SYS_ADMIN you can't get/drop_master. > > not able to drop, yikes. So if someone pokes the Wayland DRM leasing > interface while the display server is VT switched away (does not have > DRM master), and maybe no-one else has DRM master either (you're > hacking in VT text mode), then a new DRM fd would be master with no way > out? fwiw I have an assert(!drmIsMaster(fd)); before I send it to the client, just to be safe. But this may be misguided, since apparently if it ends up with a master node drmDropMaster(fd) won't work. I kind of find this hard to believe, if there's only ever one master, and the master cannot drop master, then why does this ioctl even exist? > So Wayland display servers should make sure they have master themselves > before sending a supposedly non-master DRM fd to anyone else. I wonder > if the Wayland protocol extension needs to consider that the compositor > might not be able to send any fd soon. Being able to defer sending the > fd should probably be mentioned in the protocol spec, so that clients > do not expect a simple roundtrip to be enough to ensure the fd has > arrived. When you VT switch away, the Wayland compositor is no longer necessarily able to lease those displays anyway - it's not the master anymore. So it should withdraw them, and in case of a race it'll reject the lease request. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] backlight: pwm_bl: configure pwm only once per backlight toggle
On 17. 10. 19 19:44, Adam Ford wrote:
On Thu, Oct 17, 2019 at 12:13 PM Thierry Reding
wrote:
On Thu, Oct 17, 2019 at 12:07:21PM -0500, Adam Ford wrote:
On Thu, Oct 17, 2019 at 10:14 AM Thierry Reding
wrote:
On Thu, Oct 17, 2019 at 03:58:25PM +0200, Michal Vokáč wrote:
On 17. 10. 19 14:59, Thierry Reding wrote:
On Thu, Oct 17, 2019 at 02:09:17PM +0200, Uwe Kleine-König wrote:
On Thu, Oct 17, 2019 at 01:11:31PM +0200, Thierry Reding wrote:
On Thu, Oct 17, 2019 at 12:11:16PM +0200, Uwe Kleine-König wrote:
On Thu, Oct 17, 2019 at 11:48:08AM +0200, Michal Vokáč wrote:
On 17. 10. 19 10:10, Uwe Kleine-König wrote:
A previous change in the pwm core (namely 01ccf903edd6 ("pwm: Let
pwm_get_state() return the last implemented state")) changed the
semantic of pwm_get_state() and disclosed an (as it seems) common
problem in lowlevel PWM drivers. By not relying on the period and duty
cycle being retrievable from a disabled PWM this type of problem is
worked around.
Apart from this issue only calling the pwm_get_state/pwm_apply_state
combo once is also more effective.
Signed-off-by: Uwe Kleine-König
---
Hello,
There are now two reports about 01ccf903edd6 breaking a backlight. As
far as I understand the problem this is a combination of the backend pwm
driver yielding surprising results and the pwm-bl driver doing things
more complicated than necessary.
So I guess this patch works around these problems. Still it would be
interesting to find out the details in the imx driver that triggers the
problem. So Adam, can you please instrument the pwm-imx27 driver to
print *state at the beginning of pwm_imx27_apply() and the end of
pwm_imx27_get_state() and provide the results?
Note I only compile tested this change.
Hi Uwe,
I was just about to respond to the "pwm_bl on i.MX6Q broken on 5.4-RC1+"
thread that I have a similar problem when you submitted this patch.
So here are my few cents:
My setup is as follows:
- imx6dl-yapp4-draco with i.MX6Solo
- backlight is controlled with inverted PWM signal
- max brightness level = 32, default brightness level set to 32 in DT.
1. Almost correct backlight behavior before 01ccf903edd6 ("pwm: Let
pwm_get_state() return the last implemented state):
- System boots to userspace and backlight is enabled all the time from
power up.
$ dmesg | grep state
[1.763381] get state end: -1811360608, enabled: 0
What is -1811360608? When I wrote "print *state" above, I thought about
something like:
pr_info("%s: period: %u, duty: %u, polarity: %d, enabled: %d",
__func__, state->period, state->duty_cycle, state->polarity,
state->enabled);
A quick look into drivers/pwm/pwm-imx27.c shows that this is another
driver that yields duty_cycle = 0 when the hardware is off.
It seems to me like the best recourse to fix this for now would be to
patch up the drivers that return 0 when the hardware is off by caching
the currently configured duty cycle.
How about the patch below?
Thierry
--- >8 ---
From 15a52a7f1b910804fabd74a5882befd3f9d6bb37 Mon Sep 17 00:00:00 2001
From: Thierry Reding
Date: Thu, 17 Oct 2019 12:56:00 +0200
Subject: [PATCH] pwm: imx27: Cache duty cycle register value
The hardware register containing the duty cycle value cannot be accessed
when the PWM is disabled. This causes the ->get_state() callback to read
back a duty cycle value of 0, which can confuse consumer drivers.
Signed-off-by: Thierry Reding
---
drivers/pwm/pwm-imx27.c | 31 ---
1 file changed, 24 insertions(+), 7 deletions(-)
diff --git a/drivers/pwm/pwm-imx27.c b/drivers/pwm/pwm-imx27.c
index ae11d8577f18..4113d5cd4c62 100644
--- a/drivers/pwm/pwm-imx27.c
+++ b/drivers/pwm/pwm-imx27.c
@@ -85,6 +85,13 @@ struct pwm_imx27_chip {
struct clk *clk_per;
void __iomem*mmio_base;
struct pwm_chip chip;
+
+ /*
+* The driver cannot read the current duty cycle from the hardware if
+* the hardware is disabled. Cache the last programmed duty cycle
+* value to return in that case.
+*/
+ unsigned int duty_cycle;
};
#define to_pwm_imx27_chip(chip) container_of(chip, struct
pwm_imx27_chip, chip)
@@ -155,14 +162,17 @@ static void pwm_imx27_get_state(struct pwm_chip *chip,
tmp = NSEC_PER_SEC * (u64)(period + 2);
state->period = DIV_ROUND_CLOSEST_ULL(tmp, pwm_clk);
- /* PWMSAR can be read only if PWM is enabled */
- if (state->enabled) {
+ /*
+* PWMSAR can be read only if PWM is enabled. If the PWM is disabled,
+* use the cached value.
+*/
+ if (state->enabled)
val = readl(imx->mmio_base + MX3_PWMSAR);
- tmp = NSEC_PER_SEC * (u64)(val);
- state->duty_cycle = DIV_ROUND_CLOSEST_ULL(tmp, pwm_clk);
- } else {
- state->duty_cycle = 0;
- }
+ else
+ val = imx->duty_cycle;
+
+ tmp =
[PATCH] drm/armada: make armada_overlay_duplicate_state static
The armada_overlay_duplicate_state is not declared outside
the unit, so make it static to avoid the following sparse
warning:
drivers/gpu/drm/armada/armada_overlay.c:328:24: warning: symbol
'armada_overlay_duplicate_state' was not declared. Should it be static?
Signed-off-by: Ben Dooks
---
Cc: Russell King
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/armada/armada_overlay.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/armada/armada_overlay.c
b/drivers/gpu/drm/armada/armada_overlay.c
index 07f0da4d9ba1..b3e942121fd7 100644
--- a/drivers/gpu/drm/armada/armada_overlay.c
+++ b/drivers/gpu/drm/armada/armada_overlay.c
@@ -325,7 +325,7 @@ static void armada_overlay_reset(struct drm_plane *plane)
}
}
-struct drm_plane_state *
+static struct drm_plane_state *
armada_overlay_duplicate_state(struct drm_plane *plane)
{
struct armada_overlay_state *state;
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7] unstable/drm-lease: DRM lease protocol support
On Fri Oct 18, 2019 at 12:21 PM Pekka Paalanen wrote: > One thing I did not know the last time was that apparently > systemd-logind may not like to give out non-master DRM fds. That might > need fixing in logind implementations. I hope someone would step up to > look into that. > > This protocol aims to deliver a harmless "read-only" DRM device file > description to a client, so that the client can enumerate all DRM > resources, fetch EDID and other properties to be able to decide which > connector it would want to lease. The client should not be able to > change any KMS state through this fd, and it should not be able to e.g. > spy on display contents. The assumption is that a non-master DRM fd > from a fresh open() would be fine for this, but is it? What I do for wlroots is call drmGetDeviceNameFromFd2, which returns the path to the device file, and then I open() it and use drmIsMaster/drmDropMaster to make sure it's not a master fd. This seems to work correctly in practice. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] backlight: pwm_bl: configure pwm only once per backlight toggle
On 17. 10. 19 14:59, Thierry Reding wrote:
On Thu, Oct 17, 2019 at 02:09:17PM +0200, Uwe Kleine-König wrote:
On Thu, Oct 17, 2019 at 01:11:31PM +0200, Thierry Reding wrote:
On Thu, Oct 17, 2019 at 12:11:16PM +0200, Uwe Kleine-König wrote:
On Thu, Oct 17, 2019 at 11:48:08AM +0200, Michal Vokáč wrote:
On 17. 10. 19 10:10, Uwe Kleine-König wrote:
A previous change in the pwm core (namely 01ccf903edd6 ("pwm: Let
pwm_get_state() return the last implemented state")) changed the
semantic of pwm_get_state() and disclosed an (as it seems) common
problem in lowlevel PWM drivers. By not relying on the period and duty
cycle being retrievable from a disabled PWM this type of problem is
worked around.
Apart from this issue only calling the pwm_get_state/pwm_apply_state
combo once is also more effective.
Signed-off-by: Uwe Kleine-König
---
Hello,
There are now two reports about 01ccf903edd6 breaking a backlight. As
far as I understand the problem this is a combination of the backend pwm
driver yielding surprising results and the pwm-bl driver doing things
more complicated than necessary.
So I guess this patch works around these problems. Still it would be
interesting to find out the details in the imx driver that triggers the
problem. So Adam, can you please instrument the pwm-imx27 driver to
print *state at the beginning of pwm_imx27_apply() and the end of
pwm_imx27_get_state() and provide the results?
Note I only compile tested this change.
Hi Uwe,
I was just about to respond to the "pwm_bl on i.MX6Q broken on 5.4-RC1+"
thread that I have a similar problem when you submitted this patch.
So here are my few cents:
My setup is as follows:
- imx6dl-yapp4-draco with i.MX6Solo
- backlight is controlled with inverted PWM signal
- max brightness level = 32, default brightness level set to 32 in DT.
1. Almost correct backlight behavior before 01ccf903edd6 ("pwm: Let
pwm_get_state() return the last implemented state):
- System boots to userspace and backlight is enabled all the time from
power up.
$ dmesg | grep state
[1.763381] get state end: -1811360608, enabled: 0
What is -1811360608? When I wrote "print *state" above, I thought about
something like:
pr_info("%s: period: %u, duty: %u, polarity: %d, enabled: %d",
__func__, state->period, state->duty_cycle, state->polarity,
state->enabled);
A quick look into drivers/pwm/pwm-imx27.c shows that this is another
driver that yields duty_cycle = 0 when the hardware is off.
It seems to me like the best recourse to fix this for now would be to
patch up the drivers that return 0 when the hardware is off by caching
the currently configured duty cycle.
How about the patch below?
Thierry
--- >8 ---
From 15a52a7f1b910804fabd74a5882befd3f9d6bb37 Mon Sep 17 00:00:00 2001
From: Thierry Reding
Date: Thu, 17 Oct 2019 12:56:00 +0200
Subject: [PATCH] pwm: imx27: Cache duty cycle register value
The hardware register containing the duty cycle value cannot be accessed
when the PWM is disabled. This causes the ->get_state() callback to read
back a duty cycle value of 0, which can confuse consumer drivers.
Signed-off-by: Thierry Reding
---
drivers/pwm/pwm-imx27.c | 31 ---
1 file changed, 24 insertions(+), 7 deletions(-)
diff --git a/drivers/pwm/pwm-imx27.c b/drivers/pwm/pwm-imx27.c
index ae11d8577f18..4113d5cd4c62 100644
--- a/drivers/pwm/pwm-imx27.c
+++ b/drivers/pwm/pwm-imx27.c
@@ -85,6 +85,13 @@ struct pwm_imx27_chip {
struct clk *clk_per;
void __iomem*mmio_base;
struct pwm_chip chip;
+
+ /*
+* The driver cannot read the current duty cycle from the hardware if
+* the hardware is disabled. Cache the last programmed duty cycle
+* value to return in that case.
+*/
+ unsigned int duty_cycle;
};
#define to_pwm_imx27_chip(chip) container_of(chip, struct pwm_imx27_chip, chip)
@@ -155,14 +162,17 @@ static void pwm_imx27_get_state(struct pwm_chip *chip,
tmp = NSEC_PER_SEC * (u64)(period + 2);
state->period = DIV_ROUND_CLOSEST_ULL(tmp, pwm_clk);
- /* PWMSAR can be read only if PWM is enabled */
- if (state->enabled) {
+ /*
+* PWMSAR can be read only if PWM is enabled. If the PWM is disabled,
+* use the cached value.
+*/
+ if (state->enabled)
val = readl(imx->mmio_base + MX3_PWMSAR);
- tmp = NSEC_PER_SEC * (u64)(val);
- state->duty_cycle = DIV_ROUND_CLOSEST_ULL(tmp, pwm_clk);
- } else {
- state->duty_cycle = 0;
- }
+ else
+ val = imx->duty_cycle;
+
+ tmp = NSEC_PER_SEC * (u64)(val);
+ state->duty_cycle = DIV_ROUND_CLOSEST_ULL(tmp, pwm_clk);
if (!state->enabled)
pwm_imx27_clk_disable_unprepare(chip);
@@ -261,6 +271,13 @@ static int pwm_imx27_apply(struct pwm_chip *chip, struct
pwm_device *pwm,
[PATCH] gpu: host1x: make 'host1x_cdma_wait_pushbuffer_space' static
The host1x_cdma_wait_pushbuffer_space function is not declared
or directly called from outside the file it is in, so make it
static.
Fixes the following sparse warnign:
drivers/gpu/host1x/cdma.c:235:5: warning: symbol
'host1x_cdma_wait_pushbuffer_space' was not declared. Should it be static?
Signed-off-by: Ben Dooks
---
Cc: Thierry Reding
Cc: dri-devel@lists.freedesktop.org
Cc: linux-te...@vger.kernel.org
---
drivers/gpu/host1x/cdma.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/host1x/cdma.c b/drivers/gpu/host1x/cdma.c
index 48c84c48299c..e8d3fda91d8a 100644
--- a/drivers/gpu/host1x/cdma.c
+++ b/drivers/gpu/host1x/cdma.c
@@ -232,9 +232,9 @@ unsigned int host1x_cdma_wait_locked(struct host1x_cdma
*cdma,
*
* Must be called with the cdma lock held.
*/
-int host1x_cdma_wait_pushbuffer_space(struct host1x *host1x,
- struct host1x_cdma *cdma,
- unsigned int needed)
+static int host1x_cdma_wait_pushbuffer_space(struct host1x *host1x,
+struct host1x_cdma *cdma,
+unsigned int needed)
{
while (true) {
struct push_buffer *pb = >push_buffer;
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] backlight: pwm_bl: configure pwm only once per backlight toggle
On 17. 10. 19 10:10, Uwe Kleine-König wrote:
A previous change in the pwm core (namely 01ccf903edd6 ("pwm: Let
pwm_get_state() return the last implemented state")) changed the
semantic of pwm_get_state() and disclosed an (as it seems) common
problem in lowlevel PWM drivers. By not relying on the period and duty
cycle being retrievable from a disabled PWM this type of problem is
worked around.
Apart from this issue only calling the pwm_get_state/pwm_apply_state
combo once is also more effective.
Signed-off-by: Uwe Kleine-König
---
Hello,
There are now two reports about 01ccf903edd6 breaking a backlight. As
far as I understand the problem this is a combination of the backend pwm
driver yielding surprising results and the pwm-bl driver doing things
more complicated than necessary.
So I guess this patch works around these problems. Still it would be
interesting to find out the details in the imx driver that triggers the
problem. So Adam, can you please instrument the pwm-imx27 driver to
print *state at the beginning of pwm_imx27_apply() and the end of
pwm_imx27_get_state() and provide the results?
Note I only compile tested this change.
Hi Uwe,
I was just about to respond to the "pwm_bl on i.MX6Q broken on 5.4-RC1+"
thread that I have a similar problem when you submitted this patch.
So here are my few cents:
My setup is as follows:
- imx6dl-yapp4-draco with i.MX6Solo
- backlight is controlled with inverted PWM signal
- max brightness level = 32, default brightness level set to 32 in DT.
1. Almost correct backlight behavior before 01ccf903edd6 ("pwm: Let
pwm_get_state() return the last implemented state):
- System boots to userspace and backlight is enabled all the time from
power up.
$ dmesg | grep state
[1.763381] get state end: -1811360608, enabled: 0
[4.939658] apply state start: -1797997308, enabled: 0
[4.946437] apply state start: -1797997436, enabled: 0
[4.952936] apply state start: -1797997420, enabled: 1
- $ cat brightness
32
- $ echo 32 > brightness # nothing happens, max. brightness
- $ echo 1 > brightness # backlight goes down to lowest level
[ 59.876561] apply state start: -1711276636, enabled: 1
- $ echo 0 > brightness # backlight goes up to max. level, this is
# problem of the inverted PWM on i.MX we attempted
# to solve some time ago.
[ 102.456582] apply state start: -1711276700, enabled: 0
2. Backlight behavior on v5.4-rc3:
- System boots to userspace and backlight is enabled all the time from
power up.
- $ dmesg | grep state
[1.773056] get state end: -1811319520, enabled: 0
[4.994003] apply state start: -1797948160, enabled: 0
[5.000617] get state end: -1811319520, enabled: 0
[5.006950] apply state start: -1797948292, enabled: 0
[5.013446] get state end: -1811319520, enabled: 0
[5.019602] apply state start: -1797948276, enabled: 1
[5.027536] get state end: -1811319520, enabled: 1
- $ cat brightness
32
- $ echo 32 > brightness # backlight goes down
[ 189.956756] apply state start: -1711923804, enabled: 1
[ 189.965907] get state end: -1811319520, enabled: 1
- $ echo 1 > brightness # backlight goes up to high level
[ 464.136633] apply state start: -1711923804, enabled: 1
[ 464.145625] get state end: -1811319520, enabled: 1
- $ echo 0 > brightness # backlight goes up to highest level
[ 527.136640] apply state start: -1711923868, enabled: 0
[ 527.145538] get state end: -1811319520, enabled: 0
So the behavior is clearly inverted to how it worked prior to 01ccf903edd6
with the weird exception that the initial brightness level 32 is
not applied.
3. Backlight behavior on v5.4-rc3 + this patch:
- System boots with backlight enabled. In the middle of kernel boot
backlight is disabled.
- $ dmesg | grep state
[1.773233] get state end: -1811319520, enabled: 0
[5.002753] apply state start: -1797948160, enabled: 0
[5.009397] get state end: -1811319520, enabled: 0
[5.015652] apply state start: -1797948276, enabled: 1
[5.026682] get state end: -1811319520, enabled: 1
- $ cat brightness
32
- $ echo 32 > brightness # nothing happens, backlight is down
- $ echo 1 > brightness # backlight goes to high level
[ 305.377274] apply state start: -1711915596, enabled: 1
[ 305.386374] get state end: -1811319520, enabled: 1
- $ echo 0 > brightness # backlight goes to max brightness
[ 362.637297] apply state start: -1711915596, enabled: 0
[ 362.646325] get state end: -1811319520, enabled: 0
Same behavior as (2) but the default state from DT is apparently applied.
I only did this experiments. I did not delve into the code to track what is
going on in there yet.
Hopefully this helps you a bit and feel free to request other experiments,
Michal
drivers/video/backlight/pwm_bl.c | 34 +++-
1 file changed, 12
[PATCH V7 4/6] backlight: qcom-wled: Add support for WLED4 peripheral.
WLED4 peripheral is present on some PMICs like pmi8998 and
pm660l. It has a different register map and configurations
are also different. Add support for it.
Signed-off-by: Kiran Gunda
Reviewed-by: Bjorn Andersson
---
drivers/video/backlight/qcom-wled.c | 263 +++-
1 file changed, 257 insertions(+), 6 deletions(-)
diff --git a/drivers/video/backlight/qcom-wled.c
b/drivers/video/backlight/qcom-wled.c
index 45eeda4..2807b4b 100644
--- a/drivers/video/backlight/qcom-wled.c
+++ b/drivers/video/backlight/qcom-wled.c
@@ -17,7 +17,7 @@
#define WLED3_SINK_REG_BRIGHT_MAX 0xFFF
-/* WLED3 control registers */
+/* WLED3/WLED4 control registers */
#define WLED3_CTRL_REG_MOD_EN 0x46
#define WLED3_CTRL_REG_MOD_EN_MASKBIT(7)
#define WLED3_CTRL_REG_MOD_EN_SHIFT 7
@@ -31,7 +31,7 @@
#define WLED3_CTRL_REG_ILIMIT 0x4e
#define WLED3_CTRL_REG_ILIMIT_MASKGENMASK(2, 0)
-/* WLED3 sink registers */
+/* WLED3/WLED4 sink registers */
#define WLED3_SINK_REG_SYNC0x47
#define WLED3_SINK_REG_SYNC_CLEAR 0x00
@@ -56,6 +56,28 @@
#define WLED3_SINK_REG_STR_CABC(n) (0x66 + (n * 0x10))
#define WLED3_SINK_REG_STR_CABC_MASK BIT(7)
+/* WLED4 specific sink registers */
+#define WLED4_SINK_REG_CURR_SINK 0x46
+#define WLED4_SINK_REG_CURR_SINK_MASK GENMASK(7, 4)
+#define WLED4_SINK_REG_CURR_SINK_SHFT 4
+
+/* WLED4 specific per-'string' registers below */
+#define WLED4_SINK_REG_STR_MOD_EN(n) (0x50 + (n * 0x10))
+#define WLED4_SINK_REG_STR_MOD_MASK BIT(7)
+
+#define WLED4_SINK_REG_STR_FULL_SCALE_CURR(n) (0x52 + (n * 0x10))
+#define WLED4_SINK_REG_STR_FULL_SCALE_CURR_MASK GENMASK(3, 0)
+
+#define WLED4_SINK_REG_STR_MOD_SRC(n) (0x53 + (n * 0x10))
+#define WLED4_SINK_REG_STR_MOD_SRC_MASK BIT(0)
+#define WLED4_SINK_REG_STR_MOD_SRC_INT0x00
+#define WLED4_SINK_REG_STR_MOD_SRC_EXT0x01
+
+#define WLED4_SINK_REG_STR_CABC(n) (0x56 + (n * 0x10))
+#define WLED4_SINK_REG_STR_CABC_MASK BIT(7)
+
+#define WLED4_SINK_REG_BRIGHT(n) (0x57 + (n * 0x10))
+
struct wled_var_cfg {
const u32 *values;
u32 (*fn)(u32);
@@ -90,6 +112,7 @@ struct wled {
struct device *dev;
struct regmap *regmap;
u16 ctrl_addr;
+ u16 sink_addr;
u16 max_string_count;
u32 brightness;
u32 max_brightness;
@@ -116,6 +139,29 @@ static int wled3_set_brightness(struct wled *wled, u16
brightness)
return 0;
}
+static int wled4_set_brightness(struct wled *wled, u16 brightness)
+{
+ int rc, i;
+ u16 low_limit = wled->max_brightness * 4 / 1000;
+ u8 v[2];
+
+ /* WLED4's lower limit of operation is 0.4% */
+ if (brightness > 0 && brightness < low_limit)
+ brightness = low_limit;
+
+ v[0] = brightness & 0xff;
+ v[1] = (brightness >> 8) & 0xf;
+
+ for (i = 0; i < wled->cfg.num_strings; ++i) {
+ rc = regmap_bulk_write(wled->regmap, wled->sink_addr +
+ WLED4_SINK_REG_BRIGHT(i), v, 2);
+ if (rc < 0)
+ return rc;
+ }
+
+ return 0;
+}
+
static int wled_module_enable(struct wled *wled, int val)
{
int rc;
@@ -267,6 +313,120 @@ static int wled3_setup(struct wled *wled)
.enabled_strings = {0, 1, 2, 3},
};
+static int wled4_setup(struct wled *wled)
+{
+ int rc, temp, i, j;
+ u16 addr;
+ u8 sink_en = 0;
+ u32 sink_cfg = 0;
+
+ rc = regmap_update_bits(wled->regmap,
+ wled->ctrl_addr + WLED3_CTRL_REG_OVP,
+ WLED3_CTRL_REG_OVP_MASK, wled->cfg.ovp);
+ if (rc < 0)
+ return rc;
+
+ rc = regmap_update_bits(wled->regmap,
+ wled->ctrl_addr + WLED3_CTRL_REG_ILIMIT,
+ WLED3_CTRL_REG_ILIMIT_MASK,
+ wled->cfg.boost_i_limit);
+ if (rc < 0)
+ return rc;
+
+ rc = regmap_update_bits(wled->regmap,
+ wled->ctrl_addr + WLED3_CTRL_REG_FREQ,
+ WLED3_CTRL_REG_FREQ_MASK,
+ wled->cfg.switch_freq);
+ if (rc < 0)
+ return rc;
+
+ rc = regmap_read(wled->regmap, wled->sink_addr +
+WLED4_SINK_REG_CURR_SINK, _cfg);
+ if (rc < 0)
+ return rc;
+
+ for (i = 0; i < wled->cfg.num_strings; i++) {
+ j = wled->cfg.enabled_strings[i];
+ temp = j +
Re: [PATCH hmm 00/15] Consolidate the mmu notifier interval_tree and locking
On Wed, Oct 16, 2019 at 10:58:02AM +0200, Christian König wrote:
> Am 15.10.19 um 20:12 schrieb Jason Gunthorpe:
> > From: Jason Gunthorpe
> >
> > 8 of the mmu_notifier using drivers (i915_gem, radeon_mn, umem_odp, hfi1,
> > scif_dma, vhost, gntdev, hmm) drivers are using a common pattern where
> > they only use invalidate_range_start/end and immediately check the
> > invalidating range against some driver data structure to tell if the
> > driver is interested. Half of them use an interval_tree, the others are
> > simple linear search lists.
> >
> > Of the ones I checked they largely seem to have various kinds of races,
> > bugs and poor implementation. This is a result of the complexity in how
> > the notifier interacts with get_user_pages(). It is extremely difficult to
> > use it correctly.
> >
> > Consolidate all of this code together into the core mmu_notifier and
> > provide a locking scheme similar to hmm_mirror that allows the user to
> > safely use get_user_pages() and reliably know if the page list still
> > matches the mm.
>
> That sounds really good, but could you outline for a moment how that is
> archived?
It uses the same basic scheme as hmm and rdma odp, outlined in the
revisions to hmm.rst later on.
Basically,
seq = mmu_range_read_begin();
// This is a speculative region
.. get_user_pages()/hmm_range_fault() ..
// Result cannot be derferenced
take_lock(driver->update);
if (mmu_range_read_retry(, range.notifier_seq) {
// collision! The results are not correct
goto again
}
// no collision, and now under lock. Now we can de-reference the pages/etc
// program HW
// Now the invalidate callback is responsible to synchronize against changes
unlock(driver->update)
Basically, anything that was using hmm_mirror correctly transisions
over fairly trivially, just with the modification to store a sequence
number to close that race described in the hmm commit.
For something like AMD gpu I expect it to transition to use dma_fence
from the notifier for coherency right before it unlocks driver->update.
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/i915: Don't disable interrupts independently of the lock
The locks (active.lock and rq->lock) need to be taken with disabled
interrupts. This is done in i915_request_retire() by disabling the
interrupts independently of the locks itself.
While local_irq_disable()+spin_lock() equals spin_lock_irq() on vanilla
it does not on PREEMPT_RT.
Chris Wilson confirmed that local_irq_disable() was just introduced as
an optimisation to avoid enabling/disabling interrupts during
lock/unlock combo.
Enable/disable interrupts as part of the locking instruction.
Cc: Chris Wilson
Signed-off-by: Sebastian Andrzej Siewior
---
v1…v2: Rebase to v5.4-rc3
drivers/gpu/drm/i915/i915_request.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 1c5506822dc72..cf10246fb01ad 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -205,14 +205,14 @@ static void remove_from_engine(struct i915_request *rq)
* check that the rq still belongs to the newly locked engine.
*/
locked = READ_ONCE(rq->engine);
- spin_lock(>active.lock);
+ spin_lock_irq(>active.lock);
while (unlikely(locked != (engine = READ_ONCE(rq->engine {
spin_unlock(>active.lock);
spin_lock(>active.lock);
locked = engine;
}
list_del(>sched.link);
- spin_unlock(>active.lock);
+ spin_unlock_irq(>active.lock);
}
static bool i915_request_retire(struct i915_request *rq)
@@ -272,8 +272,6 @@ static bool i915_request_retire(struct i915_request *rq)
active->retire(active, rq);
}
- local_irq_disable();
-
/*
* We only loosely track inflight requests across preemption,
* and so we may find ourselves attempting to retire a _completed_
@@ -282,7 +280,7 @@ static bool i915_request_retire(struct i915_request *rq)
*/
remove_from_engine(rq);
- spin_lock(>lock);
+ spin_lock_irq(>lock);
i915_request_mark_complete(rq);
if (!i915_request_signaled(rq))
dma_fence_signal_locked(>fence);
@@ -297,9 +295,7 @@ static bool i915_request_retire(struct i915_request *rq)
__notify_execute_cb(rq);
}
GEM_BUG_ON(!list_empty(>execute_cb));
- spin_unlock(>lock);
-
- local_irq_enable();
+ spin_unlock_irq(>lock);
remove_from_client(rq);
list_del(>link);
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: include for 'drm_need_swiotlb'
The drm_need_swiotlb is declared in which should be included in drivers/gpu/drm/drm_memory.c to silence the following warning: drivers/gpu/drm/drm_memory.c:159:6: warning: symbol 'drm_need_swiotlb' was not declared. Should it be static? Signed-off-by: Ben Dooks --- Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Sean Paul Cc: David Airlie Cc: Daniel Vetter Cc: dri-devel@lists.freedesktop.org --- drivers/gpu/drm/drm_memory.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/drm_memory.c b/drivers/gpu/drm/drm_memory.c index 0bec6dbb0142..2d8615baeadc 100644 --- a/drivers/gpu/drm/drm_memory.c +++ b/drivers/gpu/drm/drm_memory.c @@ -41,6 +41,7 @@ #include #include +#include #include "drm_legacy.h" -- 2.23.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 05/46] ARM: pxa: split up mach/hardware.h
On Fri, Oct 18, 2019 at 05:41:20PM +0200, Arnd Bergmann wrote: > The mach/hardware.h is included in lots of places, and it provides > three different things on pxa: > > - the cpu_is_pxa* macros > - an indirect inclusion of mach/addr-map.h > - the __REG() and io_pv2() helper macros > > Split it up into separate and mach/pxa-regs.h > headers, then change all the files that use mach/hardware.h to > include the exact set of those three headers that they actually > need, allowing for further more targeted cleanup. > > linux/soc/pxa/cpu.h can remain permanently exported and is now in > a global location along with similar headers. pxa-regs.h and > addr-map.h are only used in a very small number of drivers now > and can be moved to arch/arm/mach-pxa/ directly when those drivers > are to pass the necessary data as resources. > > Cc: Michael Turquette > Cc: Stephen Boyd > Cc: Viresh Kumar > Cc: Dmitry Torokhov > Cc: Jacek Anaszewski > Cc: Pavel Machek > Cc: Ulf Hansson > Cc: Dominik Brodowski > Cc: Alexandre Belloni > Cc: Greg Kroah-Hartman > Cc: Guenter Roeck > Cc: Mark Brown > Cc: linux-...@vger.kernel.org > Cc: linux...@vger.kernel.org > Cc: linux-in...@vger.kernel.org > Cc: linux-l...@vger.kernel.org > Cc: linux-...@vger.kernel.org > Cc: linux-...@lists.infradead.org > Cc: linux-...@vger.kernel.org > Cc: linux-...@vger.kernel.org > Cc: dri-devel@lists.freedesktop.org > Cc: linux-fb...@vger.kernel.org > Cc: linux-watch...@vger.kernel.org > Cc: alsa-de...@alsa-project.org > Signed-off-by: Arnd Bergmann For input bits: Acked-by: Dmitry Torokhov -- Dmitry
Re: [RESEND][PATCH v8 0/5] DMA-BUF Heaps (destaging ION)
On Fri, Oct 18, 2019 at 2:55 AM Brian Starkey wrote: > On Thu, Oct 17, 2019 at 01:57:45PM -0700, John Stultz wrote: > > On Thu, Oct 17, 2019 at 12:29 PM Andrew F. Davis wrote: > > > On 10/17/19 3:14 PM, John Stultz wrote: > > > > But if the objection stands, do you have a proposal for an alternative > > > > way to enumerate a subset of CMA heaps? > > > > > > > When in staging ION had to reach into the CMA framework as the other > > > direction would not be allowed, so cma_for_each_area() was added. If > > > DMA-BUF heaps is not in staging then we can do the opposite, and have > > > the CMA framework register heaps itself using our framework. That way > > > the CMA system could decide what areas to export or not (maybe based on > > > a DT property or similar). > > > > Ok. Though the CMA core doesn't have much sense of DT details either, > > so it would probably have to be done in the reserved_mem logic, which > > doesn't feel right to me. > > > > I'd probably guess we should have some sort of dt binding to describe > > a dmabuf cma heap and from that node link to a CMA node via a > > memory-region phandle. Along with maybe the default heap as well? Not > > eager to get into another binding review cycle, and I'm not sure what > > non-DT systems will do yet, but I'll take a shot at it and iterate. > > > > > The end result is the same so we can make this change later (it has to > > > come after DMA-BUF heaps is in anyway). > > > > Well, I'm hesitant to merge code that exposes all the CMA heaps and > > then add patches that becomes more selective, should anyone depend on > > the initial behavior. :/ > > How about only auto-adding the system default CMA region (cma->name == > "reserved")? Great minds... :) > And/or the CMA auto-add could be behind a config option? It seems a > shame to further delay this, and the CMA heap itself really is useful. thanks -john ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v12 4/5] dma-buf: heaps: Add CMA heap to dmabuf heaps
On Fri, Oct 18, 2019 at 5:04 AM Benjamin Gaignard wrote: > Le ven. 18 oct. 2019 à 13:21, Brian Starkey a écrit : > > > > On Fri, Oct 18, 2019 at 05:23:22AM +, John Stultz wrote: > > > This adds a CMA heap, which allows userspace to allocate > > > a dma-buf of contiguous memory out of a CMA region. > > > > > > This code is an evolution of the Android ION implementation, so > > > thanks to its original author and maintainters: > > > Benjamin Gaignard, Laura Abbott, and others! > > > > > > NOTE: This patch only adds the default CMA heap. We will enable > > > selectively adding other CMA memory regions to the dmabuf heaps > > > interface with a later patch (which requires a dt binding) > > Maybe we can use "no-map" DT property to trigger that. If set do not expose > the > cma heap. I don't think that's a good plan. See my WIP tree for the approach I'm planning: https://git.linaro.org/people/john.stultz/android-dev.git/log/?h=dev/dma-buf-heap-WIP thanks -john
Re: [PATCH v12 1/5] dma-buf: Add dma-buf heaps framework
On Fri, Oct 18, 2019 at 4:18 AM Brian Starkey wrote: > On Fri, Oct 18, 2019 at 05:23:19AM +, John Stultz wrote: > > As in v3: > > * Avoid EXPORT_SYMBOL until we finalize modules (suggested by >Brian) Heh. I guess it has been awhile. :) > Did something change in that regard? I still think letting modules > register heaps without a way to remove them is a recipe for issues. So yea, in recent months, work around Android with their GKI effort has made it necessary for ION heaps to be loadable from modules. I had some patches in WIP tree to enable this, and in the rework I did yesterday for the CMA module trivially collided with parts, and forgetting the discussion back in v3, I figured I'd just fold those bits in before I resubmitted for v12. If it's an issue, I can pull it out, but I'm going to be submitting module enablement for review as soon as the core bits are queued, as its going to be important to support for Android to switch to this from ION. thanks -john
[PATCH 3/3 v3] drm/panel: Add driver for Sony ACX424AKP panel
The Sony ACX424AKP is a command/videomode DSI panel for
mobile devices. It is used on the ST-Ericsson HREF520
reference design. We support video mode by default, but
it is possible to switch the panel into command mode
by using the bool property "dsi-command-mode".
Signed-off-by: Linus Walleij
---
ChangeLog v2->v3:
- No changes just resending with the new binding updates.
ChangeLog v1->v2:
- Fix up the ID read function to split into reading header,
version and ID, store the version in the struct.
- Get rid of a surplus semicolon found by the build robot
while rewriting the above code.
- Use unsigned int in probe() loop.
- Set vrefresh to 60Hz, as good as any, the measured vrefresh
in continous command mode is ~117 Hz.
- Use a different for() idiom while retrying to read ID
5 times.
- Drop the sync pulse setting, we are not using this, this
panel uses an event.
- Use the generic "enforce-video-mode" for video mode
enforcement.
---
drivers/gpu/drm/panel/Kconfig| 7 +
drivers/gpu/drm/panel/Makefile | 1 +
drivers/gpu/drm/panel/panel-sony-acx424akp.c | 542 +++
include/video/mipi_display.h | 1 +
4 files changed, 551 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-sony-acx424akp.c
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index f152bc4eeb53..959df5bea7d2 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -316,6 +316,13 @@ config DRM_PANEL_SITRONIX_ST7789V
Say Y here if you want to enable support for the Sitronix
ST7789V controller for 240x320 LCD panels
+config DRM_PANEL_SONY_ACX424AKP
+ tristate "Sony ACX424AKP DSI command mode panel"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ select VIDEOMODE_HELPERS
+
config DRM_PANEL_SONY_ACX565AKM
tristate "Sony ACX565AKM panel"
depends on GPIOLIB && OF && SPI
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index b6cd39fe0f20..0b51793e3b43 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -33,6 +33,7 @@ obj-$(CONFIG_DRM_PANEL_SHARP_LS037V7DW01) +=
panel-sharp-ls037v7dw01.o
obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7701) += panel-sitronix-st7701.o
obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o
+obj-$(CONFIG_DRM_PANEL_SONY_ACX424AKP) += panel-sony-acx424akp.o
obj-$(CONFIG_DRM_PANEL_SONY_ACX565AKM) += panel-sony-acx565akm.o
obj-$(CONFIG_DRM_PANEL_TPO_TD028TTEC1) += panel-tpo-td028ttec1.o
obj-$(CONFIG_DRM_PANEL_TPO_TD043MTEA1) += panel-tpo-td043mtea1.o
diff --git a/drivers/gpu/drm/panel/panel-sony-acx424akp.c
b/drivers/gpu/drm/panel/panel-sony-acx424akp.c
new file mode 100644
index ..96a1450b699e
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-sony-acx424akp.c
@@ -0,0 +1,542 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * MIPI-DSI Sony ACX424AKP panel driver. This is a 480x864
+ * AMOLED panel with a command-only DSI interface.
+ *
+ * Copyright (C) Linaro Ltd. 2019
+ * Author: Linus Walleij
+ * Based on code and know-how from Marcus Lorentzon
+ * Copyright (C) ST-Ericsson SA 2010
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define ACX424_DCS_READ_ID10xDA
+#define ACX424_DCS_READ_ID20xDB
+#define ACX424_DCS_READ_ID30xDC
+
+#define DISPLAY_SONY_ACX424AKP_ID1 0x811b
+#define DISPLAY_SONY_ACX424AKP_ID2 0x811a
+#define DISPLAY_SONY_ACX424AKP_ID3 0x8000
+
+struct acx424akp {
+ struct device *dev;
+ struct drm_panel panel;
+ struct backlight_device *bl;
+ struct regulator *supply;
+ struct gpio_desc *reset_gpio;
+ u8 version;
+ bool video_mode;
+};
+
+static const struct drm_display_mode sony_acx424akp_vid_mode = {
+ .clock = 33,
+ .hdisplay = 480,
+ .hsync_start = 480 + 15,
+ .hsync_end = 480 + 15 + 0,
+ .htotal = 480 + 15 + 0 + 15,
+ .vdisplay = 864,
+ .vsync_start = 864 + 14,
+ .vsync_end = 864 + 14 + 1,
+ .vtotal = 864 + 14 + 1 + 11,
+ .vrefresh = 60,
+ .width_mm = 48,
+ .height_mm = 84,
+ .flags = DRM_MODE_FLAG_PVSYNC,
+};
+
+/*
+ * The timings are not very helpful as the display is used in
+ * command mode using the maximum HS frequency.
+ */
+static const struct drm_display_mode sony_acx424akp_cmd_mode = {
+ .clock = 420160,
+ .hdisplay = 480,
+ .hsync_start = 480 + 154,
+ .hsync_end = 480 + 154 + 16,
+ .htotal = 480 + 154 + 16 + 32,
+ .vdisplay = 864,
+ .vsync_start = 864 + 1,
+ .vsync_end = 864 + 1 + 1,
+ .vtotal = 864 + 1 + 1 + 1,
+ /*
+* Some desired refresh rate, experiments at the maximum "pixel"
+* clock
[PATCH 2/3 v3] drm/panel: Add DT bindings for Sony ACX424AKP
This adds device tree bindings for the Sony ACX424AKP panel.
Let's use YAML.
Cc: devicet...@vger.kernel.org
Signed-off-by: Linus Walleij
---
ChangeLog v2->v3:
- Put the example inside a dsi-controller so we have a complete
example that verifies to the DSI panel generic binding.
ChangeLog v1->v2:
- Suggest a stand-alone YAML bindings file for DSI panels in
a separate patch, and use that to reference the
boolean "enforce-video-mode" attribute for DSI panels
---
.../display/panel/sony,acx424akp.yaml | 49 +++
1 file changed, 49 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/sony,acx424akp.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/sony,acx424akp.yaml
b/Documentation/devicetree/bindings/display/panel/sony,acx424akp.yaml
new file mode 100644
index ..c01eea17b08f
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/sony,acx424akp.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/sony,acx424akp.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Sony ACX424AKP 4" 480x864 AMOLED panel
+
+maintainers:
+ - Linus Walleij
+
+allOf:
+ - $ref: panel-common.yaml#
+ - $ref: panel-dsi-common.yaml#
+
+properties:
+ compatible:
+const: sony,acx424akp
+ reg: true
+ port: true
+ reset-gpios: true
+ vddi-supply:
+ description: regulator that supplies the vddi voltage
+ enforce-video-mode: true
+
+required:
+ - compatible
+ - reg
+ - port
+ - reset-gpios
+ - power-supply
+
+additionalProperties: false
+
+examples:
+ - |
+dsi-controller@0 {
+compatible = "foo";
+#address-cells = <1>;
+#size-cells = <0>;
+panel {
+compatible = "sony,acx424akp";
+reg = <0>;
+vddi-supply = <>;
+reset-gpios = <_gpio 0 GPIO_ACTIVE_LOW>;
+};
+};
+
+...
\ No newline at end of file
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3 v3] drm/panel: Add generic DSI panel YAML bindings
This adds a starting point for processing and defining generic bindings used by DSI panels. We just define one single bool property to force the panel into video mode for now. Cc: devicet...@vger.kernel.org Suggested-by: Rob Herring Signed-off-by: Linus Walleij --- ChangeLog v2->v3: - Make a more complete DSI panel binding including the controller and its address-cells and size-cells and a pattern for the panel nodes. The panel is one per DSI master, the reg property is compulsory but should always be 0 (as far as I can tell) as only one panel can be connected. The bus doesn't really have any addresses for the panel, the address/reg notation seems to be cargo-culted from the port graphs and is not necessary to parse some device trees, it is used to tell whether the node is a panel or not rather than any addressing. - I have no idea how many displays you can daisychain on a single DSI master, I just guess 15 will be enough. The MIPI-specs are memberwalled. Someone who knows can tell perhaps? ChangeLog v1->v2: - New patch after feedback. --- .../display/panel/panel-dsi-common.yaml | 58 +++ 1 file changed, 58 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/panel-dsi-common.yaml diff --git a/Documentation/devicetree/bindings/display/panel/panel-dsi-common.yaml b/Documentation/devicetree/bindings/display/panel/panel-dsi-common.yaml new file mode 100644 index ..d63f597eff9c --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/panel-dsi-common.yaml @@ -0,0 +1,58 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/panel-dsi-common.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Common Properties for DSI Display Panels + +maintainers: + - Linus Walleij + +description: | + This document defines device tree properties common to DSI, Display + Serial Interface panels. It doesn't constitute a device tree binding + specification by itself but is meant to be referenced by device tree + bindings. + + When referenced from panel device tree bindings the properties defined in + this document are defined as follows. The panel device tree bindings are + responsible for defining whether each property is required or optional. + + Notice: this binding concerns DSI panels connected directly to a master + without any intermediate port graph to the panel. Each DSI master + can control exactly one panel. They should all just have a node "panel" + for their panel with their reg-property set to 0. + +properties: + $nodename: +pattern: "^dsi-controller(@[0-9a-f]+)?$" + + "#address-cells": +const: 1 + + "#size-cells": +const: 0 + +patternProperties: + "^panel$": +type: object + +properties: + reg: +const: 0 +description: + Only one panel can be connected to each DSI controller, but for + historical reasons, the reg property must be specified, as the + DSI controller can contain other child nodes, and operating + systems will identify which child node is the panel by looking + for the reg property. It should however always be set to 0. + + enforce-video-mode: +type: boolean +description: + The best option is usually to run a panel in command mode, as this + gives better control over the panel hardware. However for different + reasons like broken hardware, missing features or testing, it may be + useful to be able to force a command mode-capable panel into video + mode. -- 2.21.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] dt-bindings: etnaviv: Add #cooling-cells
On Fr, 2019-10-18 at 15:50 +0200, Guido Günther wrote: > Hi, > On Wed, Sep 11, 2019 at 07:40:36PM -0700, Guido Günther wrote: > > Add #cooling-cells for when the gpu acts as a cooling device. > > > > Signed-off-by: Guido Günther > > --- > > .../devicetree/bindings/display/etnaviv/etnaviv-drm.txt | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git > > a/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt > > b/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt > > index 8def11b16a24..640592e8ab2e 100644 > > --- a/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt > > +++ b/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt > > @@ -21,6 +21,7 @@ Required properties: > > Optional properties: > > - power-domains: a power domain consumer specifier according to > >Documentation/devicetree/bindings/power/power_domain.txt > > +- #cooling-cells: : If used as a cooling device, must be <2> > > The other patch of the series made it into linux-next already but this > documentation fixup didn't. Anything i can do to get this applied as > well so documentation stays in sync? I've applied and pushed this to my etnaviv/next branch just now, so it should show up in linux-next pretty soon. Regards, Lucas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/fourcc: Fix undefined left shift in DRM_FORMAT_BIG_ENDIAN macros
1<<31 is undefined because it's a signed int and C is terrible.
Reviewed-by: Eric Engestrom
Signed-off-by: Adam Jackson
---
include/uapi/drm/drm_fourcc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 3feeaa3f987a..c06d34559fab 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -69,7 +69,7 @@ extern "C" {
#define fourcc_code(a, b, c, d) ((__u32)(a) | ((__u32)(b) << 8) | \
((__u32)(c) << 16) | ((__u32)(d) << 24))
-#define DRM_FORMAT_BIG_ENDIAN (1<<31) /* format is big endian instead of
little endian */
+#define DRM_FORMAT_BIG_ENDIAN (1U<<31) /* format is big endian instead of
little endian */
/* Reserve 0 for the invalid format specifier */
#define DRM_FORMAT_INVALID 0
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/fourcc: Fix undefined left shift in DRM_FORMAT_BIG_ENDIAN macros
On Fri, Oct 18, 2019 at 12:39:26PM -0400, Adam Jackson wrote:
> 1<<31 is undefined because it's a signed int and C is terrible.
>
> Reviewed-by: Eric Engestrom
Missing teh sob.
> ---
> include/uapi/drm/drm_fourcc.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 3feeaa3f987a..c06d34559fab 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -69,7 +69,7 @@ extern "C" {
> #define fourcc_code(a, b, c, d) ((__u32)(a) | ((__u32)(b) << 8) | \
>((__u32)(c) << 16) | ((__u32)(d) << 24))
>
> -#define DRM_FORMAT_BIG_ENDIAN (1<<31) /* format is big endian instead of
> little endian */
> +#define DRM_FORMAT_BIG_ENDIAN (1U<<31) /* format is big endian instead of
> little endian */
>
> /* Reserve 0 for the invalid format specifier */
> #define DRM_FORMAT_INVALID 0
> --
> 2.23.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111980] Rebbot and shutdown doesn't work on specific hardware
https://bugs.freedesktop.org/show_bug.cgi?id=111980 --- Comment #7 from Alex Deucher --- Yes. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/fourcc: Fix undefined left shift in DRM_FORMAT_BIG_ENDIAN macros
1<<31 is undefined because it's a signed int and C is terrible.
Reviewed-by: Eric Engestrom
---
include/uapi/drm/drm_fourcc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 3feeaa3f987a..c06d34559fab 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -69,7 +69,7 @@ extern "C" {
#define fourcc_code(a, b, c, d) ((__u32)(a) | ((__u32)(b) << 8) | \
((__u32)(c) << 16) | ((__u32)(d) << 24))
-#define DRM_FORMAT_BIG_ENDIAN (1<<31) /* format is big endian instead of
little endian */
+#define DRM_FORMAT_BIG_ENDIAN (1U<<31) /* format is big endian instead of
little endian */
/* Reserve 0 for the invalid format specifier */
#define DRM_FORMAT_INVALID 0
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] omapfb: reduce stack usage
The build of xtensa allmodconfig is giving a warning of:
In function 'dsi_dump_dsidev_irqs':
warning: the frame size of 1120 bytes is larger than 1024 bytes
Allocate the memory for 'struct dsi_irq_stats' dynamically instead
of assigning it in stack.
Signed-off-by: Sudip Mukherjee
---
drivers/video/fbdev/omap2/omapfb/dss/dsi.c | 24 ++--
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dsi.c
b/drivers/video/fbdev/omap2/omapfb/dss/dsi.c
index d620376216e1..43402467bf40 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/dsi.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/dsi.c
@@ -1536,22 +1536,25 @@ static void dsi_dump_dsidev_irqs(struct platform_device
*dsidev,
{
struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
unsigned long flags;
- struct dsi_irq_stats stats;
+ struct dsi_irq_stats *stats;
+ stats = kmalloc(sizeof(*stats), GFP_KERNEL);
+ if (!stats)
+ return;
spin_lock_irqsave(>irq_stats_lock, flags);
- stats = dsi->irq_stats;
+ memcpy(stats, >irq_stats, sizeof(*stats));
memset(>irq_stats, 0, sizeof(dsi->irq_stats));
dsi->irq_stats.last_reset = jiffies;
spin_unlock_irqrestore(>irq_stats_lock, flags);
seq_printf(s, "period %u ms\n",
- jiffies_to_msecs(jiffies - stats.last_reset));
+ jiffies_to_msecs(jiffies - stats->last_reset));
- seq_printf(s, "irqs %d\n", stats.irq_count);
+ seq_printf(s, "irqs %d\n", stats->irq_count);
#define PIS(x) \
- seq_printf(s, "%-20s %10d\n", #x, stats.dsi_irqs[ffs(DSI_IRQ_##x)-1]);
+ seq_printf(s, "%-20s %10d\n", #x, stats->dsi_irqs[ffs(DSI_IRQ_##x)-1]);
seq_printf(s, "-- DSI%d interrupts --\n", dsi->module_id + 1);
PIS(VC0);
@@ -1575,10 +1578,10 @@ static void dsi_dump_dsidev_irqs(struct platform_device
*dsidev,
#define PIS(x) \
seq_printf(s, "%-20s %10d %10d %10d %10d\n", #x, \
- stats.vc_irqs[0][ffs(DSI_VC_IRQ_##x)-1], \
- stats.vc_irqs[1][ffs(DSI_VC_IRQ_##x)-1], \
- stats.vc_irqs[2][ffs(DSI_VC_IRQ_##x)-1], \
- stats.vc_irqs[3][ffs(DSI_VC_IRQ_##x)-1]);
+ stats->vc_irqs[0][ffs(DSI_VC_IRQ_##x)-1], \
+ stats->vc_irqs[1][ffs(DSI_VC_IRQ_##x)-1], \
+ stats->vc_irqs[2][ffs(DSI_VC_IRQ_##x)-1], \
+ stats->vc_irqs[3][ffs(DSI_VC_IRQ_##x)-1]);
seq_printf(s, "-- VC interrupts --\n");
PIS(CS);
@@ -1594,7 +1597,7 @@ static void dsi_dump_dsidev_irqs(struct platform_device
*dsidev,
#define PIS(x) \
seq_printf(s, "%-20s %10d\n", #x, \
- stats.cio_irqs[ffs(DSI_CIO_IRQ_##x)-1]);
+ stats->cio_irqs[ffs(DSI_CIO_IRQ_##x)-1]);
seq_printf(s, "-- CIO interrupts --\n");
PIS(ERRSYNCESC1);
@@ -1618,6 +1621,7 @@ static void dsi_dump_dsidev_irqs(struct platform_device
*dsidev,
PIS(ULPSACTIVENOT_ALL0);
PIS(ULPSACTIVENOT_ALL1);
#undef PIS
+ kfree(stats);
}
static void dsi1_dump_irqs(struct seq_file *s)
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111980] Rebbot and shutdown doesn't work on specific hardware
https://bugs.freedesktop.org/show_bug.cgi?id=111980 --- Comment #6 from lei.p...@gmail.com --- (In reply to Alex Deucher from comment #5) > Reverted: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/ > ?id=8d13c187c42e110625d60094668a8f778c092879 Great, I can close this bug report now? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 0/7] backlight: gpio: simplify the driver
pt., 18 paź 2019 o 17:02 Jacopo Mondi napisał(a): > > Hi, > > On Thu, Oct 17, 2019 at 08:25:50AM +0100, Lee Jones wrote: > > On Wed, 16 Oct 2019, Jacopo Mondi wrote: > > > > > Hi, sorry for not having replied earlier > > > > > > On Wed, Oct 16, 2019 at 02:56:57PM +0200, Linus Walleij wrote: > > > > On Mon, Oct 14, 2019 at 10:12 AM Lee Jones wrote: > > > > > > > > > > arch/sh/boards/mach-ecovec24/setup.c | 33 -- > > > > > > > > > > I guess we're just waiting for the SH Acks now? > > > > > > > > The one maintainer with this board is probably overloaded. > > > > > > > > I would say just apply it, it can't hold back the entire series. > > > > > > I've been able to resurect the Ecovec, and I've also been given a copy > > > of its schematics file a few weeks ago. > > > > > > It's in my TODO list to test this series but I didn't manage to find > > > time. If I pinky promise I get back to you before end of the week, > > > could you wait for me ? :) > > Finally had some time to spend on this. > > As I've reported to Bartosz, this version does not work on Ecovec out > of the box, as the GPIO line connected to the backlight needs to be > configured to work in output mode before registering the backlight > device. > > With this simple change: > > $ git diff > diff --git a/arch/sh/boards/mach-ecovec24/setup.c > b/arch/sh/boards/mach-ecovec24/setup.c > index dd427bac5cde..eec6e805c3ed 100644 > --- a/arch/sh/boards/mach-ecovec24/setup.c > +++ b/arch/sh/boards/mach-ecovec24/setup.c > @@ -1473,6 +1473,7 @@ static int __init arch_setup(void) > #endif > #endif > > + gpio_direction_output(GPIO_PTR1, 1); This is a hack actually. The problem lies with the gpio backlight driver - it should really set the mode to output, not leave it as is. If there's no good reason to keep it as it is now, I'll add another patch to the series that moves the call to devm_gpiod_get() to where we've already determined the initial value in probe() and pass an appropriate GPIOD_OUT_HIGH/LOW flag. Bart > gpiod_add_lookup_table(_backlight_lookup); > gpio_backlight_device = platform_device_register_full( > _backlight_device_info); > > I can now control the gpio through the backlight interface. > > So please add this bit on top of next iteration and add my: > Tested-by: Jacopo Mondi > > Thanks and sorry for the long time it took! > > > > > Yes, no problem. > > > > -- > > Lee Jones [李琼斯] > > Linaro Services Technical Lead > > Linaro.org │ Open source software for ARM SoCs > > Follow Linaro: Facebook | Twitter | Blog
RE: [Intel-gfx] [PATCH 3/4] drm/edid: Fix HDMI VIC handling
>-Original Message-
>From: Intel-gfx On Behalf Of Ville
>Syrjala
>Sent: Friday, October 4, 2019 7:49 PM
>To: dri-devel@lists.freedesktop.org
>Cc: intel-...@lists.freedesktop.org; Wayne Lin
>Subject: [Intel-gfx] [PATCH 3/4] drm/edid: Fix HDMI VIC handling
>
>From: Ville Syrjälä
>
>Extract drm_mode_hdmi_vic() to correctly calculate the final HDMI VIC for us.
>Currently this is being done a bit differently between the AVI and HDMI
>infoframes.
>Let's get both to agree on this.
>
>We need to allow the case where a mode is both 3D and has a HDMI VIC. Currently
>we'll just refuse to generate the HDMI infoframe when we really should be
>setting
>HDMI VIC to 0 and instead enabling 3D stereo signalling.
>
>If the sink doesn't even support the HDMI infoframe we should not be picking
>the
>HDMI VIC in favor of the CEA VIC, because then we'll end up not sending either
>VIC in
>the end.
Looks good to me.
Reviewed-by: Uma Shankar
>Cc: Wayne Lin
>Signed-off-by: Ville Syrjälä
>---
> drivers/gpu/drm/drm_edid.c | 37 +
> 1 file changed, 21 insertions(+), 16 deletions(-)
>
>diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index
>495b7fb4d9ef..c7f9f7ca75a2 100644
>--- a/drivers/gpu/drm/drm_edid.c
>+++ b/drivers/gpu/drm/drm_edid.c
>@@ -5160,11 +5160,25 @@ drm_hdmi_infoframe_set_hdr_metadata(struct
>hdmi_drm_infoframe *frame, }
>EXPORT_SYMBOL(drm_hdmi_infoframe_set_hdr_metadata);
>
>+static u8 drm_mode_hdmi_vic(struct drm_connector *connector,
>+ const struct drm_display_mode *mode) {
>+ bool has_hdmi_infoframe = connector ?
>+ connector->display_info.has_hdmi_infoframe : false;
>+
>+ if (!has_hdmi_infoframe)
>+ return 0;
>+
>+ /* No HDMI VIC when signalling 3D video format */
>+ if (mode->flags & DRM_MODE_FLAG_3D_MASK)
>+ return 0;
>+
>+ return drm_match_hdmi_mode(mode);
>+}
>+
> static u8 drm_mode_cea_vic(struct drm_connector *connector,
> const struct drm_display_mode *mode) {
>- u8 vendor_if_vic = drm_match_hdmi_mode(mode);
>- bool is_s3d = mode->flags & DRM_MODE_FLAG_3D_MASK;
> u8 vic;
>
> /*
>@@ -5173,7 +5187,7 @@ static u8 drm_mode_cea_vic(struct drm_connector
>*connector,
>* VIC in AVI infoframes. Lets check if this mode is present in
>* HDMI 1.4b 4K modes
>*/
>- if (drm_valid_hdmi_vic(vendor_if_vic) && !is_s3d)
>+ if (drm_mode_hdmi_vic(connector, mode))
> return 0;
>
> vic = drm_match_cea_mode(mode);
>@@ -5433,8 +5447,6 @@ drm_hdmi_vendor_infoframe_from_display_mode(struct
>hdmi_vendor_infoframe *frame,
> bool has_hdmi_infoframe = connector ?
> connector->display_info.has_hdmi_infoframe : false;
> int err;
>- u32 s3d_flags;
>- u8 vic;
>
> if (!frame || !mode)
> return -EINVAL;
>@@ -5442,8 +5454,9 @@ drm_hdmi_vendor_infoframe_from_display_mode(struct
>hdmi_vendor_infoframe *frame,
> if (!has_hdmi_infoframe)
> return -EINVAL;
>
>- vic = drm_match_hdmi_mode(mode);
>- s3d_flags = mode->flags & DRM_MODE_FLAG_3D_MASK;
>+ err = hdmi_vendor_infoframe_init(frame);
>+ if (err < 0)
>+ return err;
>
> /*
>* Even if it's not absolutely necessary to send the infoframe @@
> -5454,15
>+5467,7 @@ drm_hdmi_vendor_infoframe_from_display_mode(struct
>hdmi_vendor_infoframe *frame,
>* mode if the source simply stops sending the infoframe when
>* it wants to switch from 3D to 2D.
>*/
>-
>- if (vic && s3d_flags)
>- return -EINVAL;
>-
>- err = hdmi_vendor_infoframe_init(frame);
>- if (err < 0)
>- return err;
>-
>- frame->vic = vic;
>+ frame->vic = drm_mode_hdmi_vic(connector, mode);
> frame->s3d_struct = s3d_structure_from_display_mode(mode);
>
> return 0;
>--
>2.21.0
>
>___
>Intel-gfx mailing list
>intel-...@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 06/46] ARM: pxa: stop using mach/bitfield.h
There are two identical copies of mach/bitfield.h, one for mach-sa1100 and one for mach-pxa. The pxafb driver only makes use of two macros, which can be trivially open-coded in the header. Cc: Bartlomiej Zolnierkiewicz Cc: dri-devel@lists.freedesktop.org Signed-off-by: Arnd Bergmann --- arch/arm/mach-pxa/idp.c | 1 - arch/arm/mach-pxa/include/mach/regs-lcd.h | 5 +++-- arch/arm/mach-pxa/regs-u2d.h | 2 -- drivers/video/fbdev/pxafb.c | 1 - 4 files changed, 3 insertions(+), 6 deletions(-) diff --git a/arch/arm/mach-pxa/idp.c b/arch/arm/mach-pxa/idp.c index 57c0511472bc..525d01ddfbbb 100644 --- a/arch/arm/mach-pxa/idp.c +++ b/arch/arm/mach-pxa/idp.c @@ -30,7 +30,6 @@ #include "pxa25x.h" #include "idp.h" #include -#include #include #include diff --git a/arch/arm/mach-pxa/include/mach/regs-lcd.h b/arch/arm/mach-pxa/include/mach/regs-lcd.h index e2b6e3d1f625..6a434675f84a 100644 --- a/arch/arm/mach-pxa/include/mach/regs-lcd.h +++ b/arch/arm/mach-pxa/include/mach/regs-lcd.h @@ -2,8 +2,6 @@ #ifndef __ASM_ARCH_REGS_LCD_H #define __ASM_ARCH_REGS_LCD_H -#include - /* * LCD Controller Registers and Bits Definitions */ @@ -86,6 +84,9 @@ #define LCCR0_OUC (1 << 25) /* Overlay Underlay control bit */ #define LCCR0_LDDALT (1 << 26) /* LDD alternate mapping control */ +#define Fld(Size, Shft)(((Size) << 16) + (Shft)) +#define FShft(Field) ((Field) & 0x) + #define LCCR1_PPL Fld (10, 0) /* Pixels Per Line - 1 */ #define LCCR1_DisWdth(Pixel) (((Pixel) - 1) << FShft (LCCR1_PPL)) diff --git a/arch/arm/mach-pxa/regs-u2d.h b/arch/arm/mach-pxa/regs-u2d.h index fe4c80ad87ec..ab517ba62c9a 100644 --- a/arch/arm/mach-pxa/regs-u2d.h +++ b/arch/arm/mach-pxa/regs-u2d.h @@ -2,8 +2,6 @@ #ifndef __ASM_ARCH_PXA3xx_U2D_H #define __ASM_ARCH_PXA3xx_U2D_H -#include - /* * USB2 device controller registers and bits definitions */ diff --git a/drivers/video/fbdev/pxafb.c b/drivers/video/fbdev/pxafb.c index ece691a0f18a..e68b8a69db92 100644 --- a/drivers/video/fbdev/pxafb.c +++ b/drivers/video/fbdev/pxafb.c @@ -64,7 +64,6 @@ #include #include #include -#include #include /* -- 2.20.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7] unstable/drm-lease: DRM lease protocol support
On Fri, Oct 18, 2019 at 4:34 PM Pekka Paalanen wrote: > > On Fri, 18 Oct 2019 16:19:33 +0200 > Daniel Vetter wrote: > > > On Fri, Oct 18, 2019 at 3:43 PM Pekka Paalanen wrote: > > > > > > On Fri, 18 Oct 2019 07:54:50 -0400 > > > "Drew DeVault" wrote: > > > > > > > On Fri Oct 18, 2019 at 12:21 PM Pekka Paalanen wrote: > > > > > One thing I did not know the last time was that apparently > > > > > systemd-logind may not like to give out non-master DRM fds. That might > > > > > need fixing in logind implementations. I hope someone would step up to > > > > > look into that. > > > > > > > > > > This protocol aims to deliver a harmless "read-only" DRM device file > > > > > description to a client, so that the client can enumerate all DRM > > > > > resources, fetch EDID and other properties to be able to decide which > > > > > connector it would want to lease. The client should not be able to > > > > > change any KMS state through this fd, and it should not be able to > > > > > e.g. > > > > > spy on display contents. The assumption is that a non-master DRM fd > > > > > from a fresh open() would be fine for this, but is it? > > > > > > > > What I do for wlroots is call drmGetDeviceNameFromFd2, which returns the > > > > path to the device file, and then I open() it and use > > > > drmIsMaster/drmDropMaster to make sure it's not a master fd. This seems > > > > to work correctly in practice. > > > > > > That is nice. > > > > > > Personally I'm specifically worried about a setup where the user has no > > > access permissions to open the DRM device node directly, as is (or > > > should be) the case with input devices. > > > > > > However, since DRM has the master concept which input devices do not, > > > maybe there is no reason to prevent a normal user from opening a DRM > > > device directly. That is, if our assumption that a non-master DRM fd is > > > harmless holds. > > > > > > (Wayland display servers usually run as a normal user, while logind > > > or another service runs with elevated privileges and opens input and > > > DRM devices on behalf of the display server.) > > > > So the rules are (if I'm not making a mistake) > > - If you're not CAP_SYS_ADMIN you can't get/drop_master. > > Hi, > > not able to drop, yikes. So if someone pokes the Wayland DRM leasing > interface while the display server is VT switched away (does not have > DRM master), and maybe no-one else has DRM master either (you're > hacking in VT text mode), then a new DRM fd would be master with no way > out? > > So Wayland display servers should make sure they have master themselves > before sending a supposedly non-master DRM fd to anyone else. I wonder > if the Wayland protocol extension needs to consider that the compositor > might not be able to send any fd soon. Being able to defer sending the > fd should probably be mentioned in the protocol spec, so that clients > do not expect a simple roundtrip to be enough to ensure the fd has > arrived. > > > - This is a bit awkward, since non-root can become a master, when > > there's no other master right at this point. So if you want to be able > > to do this, we should probably clarify this part of the uapi somehow > > (either de-priv drop_master or make sure non-root can't become master, > > but the latter probably will break something somewhere). Plus igts to > > lock down this behaviour. Note that if logind does a vt switch there's > > a race window where no one is master and you might be able to squeeze > > in. So perhaps we do want to stop this behaviour and require > > CAP_SYS_ADMIN to become master, even accidentally. > > That would close the loophole that Ville mentioned, too, otherwise > distributions should aim to not give permissions to open the DRM device > node. I'm kinda wondering whether we have to do this as a security fix, with maybe a module option to get the old behaviour back for those who need/want that. But I don't even know whom/where to ping for logind folks ... > > - I thought you can always re-open your own fd through proc? Which > > should be good enough for this use-case here. > > We can? And that creates a new file description the same way as open() > in the original device node? I dreamed, it's just a normal symlink, nothing fancy. > Does that avoid becoming master in the above VT-switched-away scenario? Would be a reopen like open(3), so same problem until we fix that. -Daniel > > - Non-master primary node should indeed give you all the GET* ioctls > > for kms, and nothing else useful or at least dangerous (you might be > > able to render with that thing). Just make sure you dont authenticate > > that new fd. Again maybe we should clarify our docs a bit to make this > > use case official. > > Awesome, thanks, > pq -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org
[PATCH 38/46] video: backlight: tosa: use gpio lookup table
The driver should not require a machine specific header. Change
it to pass the gpio line through a lookup table, and move the
timing generator definitions into the drivers itself.
Cc: Lee Jones
Cc: Daniel Thompson
Cc: Jingoo Han
Cc: Bartlomiej Zolnierkiewicz
Cc: dri-devel@lists.freedesktop.org
Cc: linux-fb...@vger.kernel.org
Signed-off-by: Arnd Bergmann
---
I'm not overly confident that I got the correct device names
for the lookup table, it would be good if someone could
double-check.
---
arch/arm/mach-pxa/include/mach/tosa.h | 15 --
arch/arm/mach-pxa/tosa.c | 22 +
drivers/video/backlight/tosa_bl.c | 10 +-
drivers/video/backlight/tosa_bl.h | 8
drivers/video/backlight/tosa_lcd.c| 28 ---
5 files changed, 56 insertions(+), 27 deletions(-)
create mode 100644 drivers/video/backlight/tosa_bl.h
diff --git a/arch/arm/mach-pxa/include/mach/tosa.h
b/arch/arm/mach-pxa/include/mach/tosa.h
index a499ed17931e..8bfaca3a8b64 100644
--- a/arch/arm/mach-pxa/include/mach/tosa.h
+++ b/arch/arm/mach-pxa/include/mach/tosa.h
@@ -72,18 +72,6 @@
#define TOSA_GPIO_BAT0_TH_ON (TOSA_TC6393XB_GPIO_BASE + 14)
#define TOSA_GPIO_BAT1_TH_ON (TOSA_TC6393XB_GPIO_BASE + 15)
-/*
- * Timing Generator
- */
-#define TG_PNLCTL 0x00
-#define TG_TPOSCTL 0x01
-#define TG_DUTYCTL 0x02
-#define TG_GPOSR 0x03
-#define TG_GPODR1 0x04
-#define TG_GPODR2 0x05
-#define TG_PINICTL 0x06
-#define TG_HPOSCTL 0x07
-
/*
* PXA GPIOs
*/
@@ -192,7 +180,4 @@
#define TOSA_KEY_MAIL KEY_MAIL
#endif
-struct spi_device;
-extern int tosa_bl_enable(struct spi_device *spi, int enable);
-
#endif /* _ASM_ARCH_TOSA_H_ */
diff --git a/arch/arm/mach-pxa/tosa.c b/arch/arm/mach-pxa/tosa.c
index 9a7f1e42adac..8329a2969b2b 100644
--- a/arch/arm/mach-pxa/tosa.c
+++ b/arch/arm/mach-pxa/tosa.c
@@ -813,6 +813,26 @@ static struct pxa2xx_spi_controller pxa_ssp_master_info = {
.num_chipselect = 1,
};
+static struct gpiod_lookup_table tosa_lcd_gpio_table = {
+ .dev_id = "spi2.0",
+ .table = {
+ GPIO_LOOKUP("tc6393xb",
+ TOSA_GPIO_TG_ON - TOSA_TC6393XB_GPIO_BASE,
+ "tg #pwr", GPIO_ACTIVE_HIGH),
+ { },
+ },
+};
+
+static struct gpiod_lookup_table tosa_lcd_bl_gpio_table = {
+ .dev_id = "i2c-tosa-bl",
+ .table = {
+ GPIO_LOOKUP("tc6393xb",
+ TOSA_GPIO_BL_C20MA - TOSA_TC6393XB_GPIO_BASE,
+ "backlight", GPIO_ACTIVE_HIGH),
+ { },
+ },
+};
+
static struct spi_board_info spi_board_info[] __initdata = {
{
.modalias = "tosa-lcd",
@@ -935,6 +955,8 @@ static void __init tosa_init(void)
platform_scoop_config = _pcmcia_config;
pxa2xx_set_spi_info(2, _ssp_master_info);
+ gpiod_add_lookup_table(_lcd_gpio_table);
+ gpiod_add_lookup_table(_lcd_bl_gpio_table);
spi_register_board_info(spi_board_info, ARRAY_SIZE(spi_board_info));
clk_add_alias("CLK_CK3P6MI", tc6393xb_device.name, "GPIO11_CLK", NULL);
diff --git a/drivers/video/backlight/tosa_bl.c
b/drivers/video/backlight/tosa_bl.c
index 1275e815bd86..cff5e96fd988 100644
--- a/drivers/video/backlight/tosa_bl.c
+++ b/drivers/video/backlight/tosa_bl.c
@@ -18,7 +18,7 @@
#include
-#include
+#include "tosa_bl.h"
#define COMADJ_DEFAULT 97
@@ -28,6 +28,7 @@
struct tosa_bl_data {
struct i2c_client *i2c;
struct backlight_device *bl;
+ struct gpio_desc *gpio;
int comadj;
};
@@ -42,7 +43,7 @@ static void tosa_bl_set_backlight(struct tosa_bl_data *data,
int brightness)
i2c_smbus_write_byte_data(data->i2c, DAC_CH2, (u8)(brightness & 0xff));
/* SetBacklightVR */
- gpio_set_value(TOSA_GPIO_BL_C20MA, brightness & 0x100);
+ gpiod_set_value(data->gpio, brightness & 0x100);
tosa_bl_enable(spi, brightness);
}
@@ -87,9 +88,8 @@ static int tosa_bl_probe(struct i2c_client *client,
return -ENOMEM;
data->comadj = sharpsl_param.comadj == -1 ? COMADJ_DEFAULT :
sharpsl_param.comadj;
-
- ret = devm_gpio_request_one(>dev, TOSA_GPIO_BL_C20MA,
- GPIOF_OUT_INIT_LOW, "backlight");
+ data->gpio = devm_gpiod_get(>dev, "backlight", GPIOD_OUT_LOW);
+ ret = PTR_ERR_OR_ZERO(data->gpio);
if (ret) {
dev_dbg(>bl->dev, "Unable to request gpio!\n");
return ret;
diff --git a/drivers/video/backlight/tosa_bl.h
b/drivers/video/backlight/tosa_bl.h
new file mode 100644
index ..589e17e6fdb2
--- /dev/null
+++ b/drivers/video/backlight/tosa_bl.h
@@ -0,0 +1,8 @@
+/* SPDX-License-Identifier: GPL-2.0-only
[PATCH 05/46] ARM: pxa: split up mach/hardware.h
The mach/hardware.h is included in lots of places, and it provides three different things on pxa: - the cpu_is_pxa* macros - an indirect inclusion of mach/addr-map.h - the __REG() and io_pv2() helper macros Split it up into separate and mach/pxa-regs.h headers, then change all the files that use mach/hardware.h to include the exact set of those three headers that they actually need, allowing for further more targeted cleanup. linux/soc/pxa/cpu.h can remain permanently exported and is now in a global location along with similar headers. pxa-regs.h and addr-map.h are only used in a very small number of drivers now and can be moved to arch/arm/mach-pxa/ directly when those drivers are to pass the necessary data as resources. Cc: Michael Turquette Cc: Stephen Boyd Cc: Viresh Kumar Cc: Dmitry Torokhov Cc: Jacek Anaszewski Cc: Pavel Machek Cc: Ulf Hansson Cc: Dominik Brodowski Cc: Alexandre Belloni Cc: Greg Kroah-Hartman Cc: Guenter Roeck Cc: Mark Brown Cc: linux-...@vger.kernel.org Cc: linux...@vger.kernel.org Cc: linux-in...@vger.kernel.org Cc: linux-l...@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: linux-...@lists.infradead.org Cc: linux-...@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: linux-fb...@vger.kernel.org Cc: linux-watch...@vger.kernel.org Cc: alsa-de...@alsa-project.org Signed-off-by: Arnd Bergmann --- arch/arm/common/locomo.c | 1 - arch/arm/common/sa.c | 5 +- arch/arm/mach-pxa/cm-x2xx.c | 2 + arch/arm/mach-pxa/cm-x300.c | 2 + arch/arm/mach-pxa/colibri-evalboard.c | 1 - arch/arm/mach-pxa/colibri-pxa270-income.c | 1 - arch/arm/mach-pxa/colibri-pxa300.c| 1 + arch/arm/mach-pxa/colibri-pxa3xx.c| 1 - arch/arm/mach-pxa/corgi.c | 1 - arch/arm/mach-pxa/corgi_pm.c | 1 - arch/arm/mach-pxa/csb726.c| 1 + arch/arm/mach-pxa/devices.c | 2 +- arch/arm/mach-pxa/ezx.c | 1 - arch/arm/mach-pxa/generic.c | 3 +- arch/arm/mach-pxa/gumstix.c | 1 - arch/arm/mach-pxa/hx4700.c| 2 +- arch/arm/mach-pxa/idp.c | 1 - arch/arm/mach-pxa/include/mach/pxa-regs.h | 52 arch/arm/mach-pxa/include/mach/pxa2xx-regs.h | 2 +- arch/arm/mach-pxa/include/mach/pxa3xx-regs.h | 2 +- arch/arm/mach-pxa/include/mach/regs-ac97.h| 2 +- arch/arm/mach-pxa/include/mach/regs-ost.h | 2 +- arch/arm/mach-pxa/include/mach/trizeps4.h | 1 + arch/arm/mach-pxa/irq.c | 3 +- arch/arm/mach-pxa/littleton.c | 1 - arch/arm/mach-pxa/lpd270.c| 2 +- arch/arm/mach-pxa/lubbock.c | 1 - arch/arm/mach-pxa/magician.c | 2 +- arch/arm/mach-pxa/mainstone.c | 2 +- arch/arm/mach-pxa/mfp-pxa2xx.c| 1 + arch/arm/mach-pxa/mfp-pxa3xx.c| 1 - arch/arm/mach-pxa/poodle.c| 1 - arch/arm/mach-pxa/pxa-regs.h | 1 + arch/arm/mach-pxa/pxa25x.c| 3 +- arch/arm/mach-pxa/pxa25x.h| 2 +- arch/arm/mach-pxa/pxa27x-udc.h| 2 + arch/arm/mach-pxa/pxa27x.c| 3 +- arch/arm/mach-pxa/pxa27x.h| 2 +- arch/arm/mach-pxa/pxa2xx.c| 1 - arch/arm/mach-pxa/pxa300.c| 1 + arch/arm/mach-pxa/pxa320.c| 1 + arch/arm/mach-pxa/pxa3xx-ulpi.c | 2 +- arch/arm/mach-pxa/pxa3xx.c| 3 +- arch/arm/mach-pxa/pxa3xx.h| 2 +- arch/arm/mach-pxa/pxa930.c| 1 + arch/arm/mach-pxa/regs-rtc.h | 2 +- arch/arm/mach-pxa/regs-uart.h | 2 + arch/arm/mach-pxa/sleep.S | 1 - arch/arm/mach-pxa/smemc.c | 2 +- arch/arm/mach-pxa/spitz_pm.c | 1 - arch/arm/mach-pxa/standby.S | 1 - arch/arm/mach-pxa/xcep.c | 2 +- arch/arm/mach-pxa/zylonite.c | 1 + arch/arm/mach-pxa/zylonite.h | 2 + arch/arm/mach-pxa/zylonite_pxa300.c | 1 + arch/arm/mach-pxa/zylonite_pxa320.c | 1 + drivers/clk/pxa/clk-pxa3xx.c | 1 + drivers/cpufreq/pxa2xx-cpufreq.c | 1 + drivers/cpufreq/pxa3xx-cpufreq.c | 1 + drivers/input/mouse/pxa930_trkball.c | 1 - drivers/input/touchscreen/zylonite-wm97xx.c | 2 +- drivers/leds/leds-locomo.c| 1 - drivers/mmc/host/pxamci.c | 2 +- drivers/mtd/maps/pxa2xx-flash.c | 2 - drivers/mtd/nand/raw/cmx270_nand.c| 3 +- drivers/pcmcia/pxa2xx_base.c | 2 +-
[PATCH 08/46] ARM: pxa: move regs-lcd.h into driver
Only the pxafb driver uses this header, so move it into the
same directory. The SMART_* macros are required by some
platform data definitions and can go into the
linux/platform_data/video-pxafb.h header.
Cc: Bartlomiej Zolnierkiewicz
Cc: dri-devel@lists.freedesktop.org
Cc: linux-fb...@vger.kernel.org
Signed-off-by: Arnd Bergmann
---
.../video/fbdev/pxa3xx-regs.h | 19
drivers/video/fbdev/pxafb.c | 1 +
include/linux/platform_data/video-pxafb.h | 22 ++-
3 files changed, 22 insertions(+), 20 deletions(-)
rename arch/arm/mach-pxa/include/mach/regs-lcd.h =>
drivers/video/fbdev/pxa3xx-regs.h (90%)
diff --git a/arch/arm/mach-pxa/include/mach/regs-lcd.h
b/drivers/video/fbdev/pxa3xx-regs.h
similarity index 90%
rename from arch/arm/mach-pxa/include/mach/regs-lcd.h
rename to drivers/video/fbdev/pxa3xx-regs.h
index 6a434675f84a..6a96610ef9b5 100644
--- a/arch/arm/mach-pxa/include/mach/regs-lcd.h
+++ b/drivers/video/fbdev/pxa3xx-regs.h
@@ -177,23 +177,4 @@
#define PRSR_ST_OK (1 << 9)/* Status OK */
#define PRSR_CON_NT(1 << 10) /* Continue to Next Command */
-#define SMART_CMD_A0(0x1 << 8)
-#define SMART_CMD_READ_STATUS_REG (0x0 << 9)
-#define SMART_CMD_READ_FRAME_BUFFER((0x0 << 9) | SMART_CMD_A0)
-#define SMART_CMD_WRITE_COMMAND (0x1 << 9)
-#define SMART_CMD_WRITE_DATA ((0x1 << 9) | SMART_CMD_A0)
-#define SMART_CMD_WRITE_FRAME ((0x2 << 9) | SMART_CMD_A0)
-#define SMART_CMD_WAIT_FOR_VSYNC(0x3 << 9)
-#define SMART_CMD_NOOP (0x4 << 9)
-#define SMART_CMD_INTERRUPT (0x5 << 9)
-
-#define SMART_CMD(x) (SMART_CMD_WRITE_COMMAND | ((x) & 0xff))
-#define SMART_DAT(x) (SMART_CMD_WRITE_DATA | ((x) & 0xff))
-
-/* SMART_DELAY() is introduced for software controlled delay primitive which
- * can be inserted between command sequences, unused command 0x6 is used here
- * and delay ranges from 0ms ~ 255ms
- */
-#define SMART_CMD_DELAY(0x6 << 9)
-#define SMART_DELAY(ms)(SMART_CMD_DELAY | ((ms) & 0xff))
#endif /* __ASM_ARCH_REGS_LCD_H */
diff --git a/drivers/video/fbdev/pxafb.c b/drivers/video/fbdev/pxafb.c
index e68b8a69db92..a65453c6c390 100644
--- a/drivers/video/fbdev/pxafb.c
+++ b/drivers/video/fbdev/pxafb.c
@@ -72,6 +72,7 @@
#define DEBUG_VAR 1
#include "pxafb.h"
+#include "pxa3xx-regs.h"
/* Bits which should not be set in machine configuration structures */
#define LCCR0_INVALID_CONFIG_MASK (LCCR0_OUM | LCCR0_BM | LCCR0_QDM |\
diff --git a/include/linux/platform_data/video-pxafb.h
b/include/linux/platform_data/video-pxafb.h
index b3d574778326..6333bac166a5 100644
--- a/include/linux/platform_data/video-pxafb.h
+++ b/include/linux/platform_data/video-pxafb.h
@@ -8,7 +8,6 @@
*/
#include
-#include
/*
* Supported LCD connections
@@ -153,6 +152,27 @@ struct pxafb_mach_info {
void pxa_set_fb_info(struct device *, struct pxafb_mach_info *);
unsigned long pxafb_get_hsync_time(struct device *dev);
+/* smartpanel related */
+#define SMART_CMD_A0(0x1 << 8)
+#define SMART_CMD_READ_STATUS_REG (0x0 << 9)
+#define SMART_CMD_READ_FRAME_BUFFER((0x0 << 9) | SMART_CMD_A0)
+#define SMART_CMD_WRITE_COMMAND (0x1 << 9)
+#define SMART_CMD_WRITE_DATA ((0x1 << 9) | SMART_CMD_A0)
+#define SMART_CMD_WRITE_FRAME ((0x2 << 9) | SMART_CMD_A0)
+#define SMART_CMD_WAIT_FOR_VSYNC(0x3 << 9)
+#define SMART_CMD_NOOP (0x4 << 9)
+#define SMART_CMD_INTERRUPT (0x5 << 9)
+
+#define SMART_CMD(x) (SMART_CMD_WRITE_COMMAND | ((x) & 0xff))
+#define SMART_DAT(x) (SMART_CMD_WRITE_DATA | ((x) & 0xff))
+
+/* SMART_DELAY() is introduced for software controlled delay primitive which
+ * can be inserted between command sequences, unused command 0x6 is used here
+ * and delay ranges from 0ms ~ 255ms
+ */
+#define SMART_CMD_DELAY(0x6 << 9)
+#define SMART_DELAY(ms)(SMART_CMD_DELAY | ((ms) & 0xff))
+
#ifdef CONFIG_FB_PXA_SMARTPANEL
extern int pxafb_smart_queue(struct fb_info *info, uint16_t *cmds, int);
extern int pxafb_smart_flush(struct fb_info *info);
--
2.20.0
Re: [RFC] drm: Add AMD GFX9+ format modifiers.
On Thu, Oct 17, 2019 at 9:50 PM Marek Olšák wrote: > > On Wed, Oct 16, 2019 at 9:48 AM Bas Nieuwenhuizen > wrote: >> >> This adds initial format modifiers for AMD GFX9 and newer GPUs. >> >> This is particularly useful to determine if we can use DCC, and whether >> we need an extra display compatible DCC metadata plane. >> >> Design decisions: >> - Always expose a single plane >>This way everything works correctly with images with multiple planes. >> >> - Do not add an extra memory region in DCC for putting a bit on whether >> we are in compressed state. >>A decompress on import is cheap enough if already decompressed, and >>I do think in most cases we can avoid it in advance during modifier >>negotiation. The remainder is probably not common enough to worry >>about. >> >> - Explicitly define the sizes as part of the modifier description instead >> of using whatever the current version of radeonsi does. >>This way we can avoid dedicated buffers and we can make sure we keep >>compatibility across mesa versions. I'd like to put some tests on >>this on ac_surface.c so we can learn early in the process if things >>need to be changed. Furthermore, the lack of configurable strides on >>GFX10 means things already go wrong if we do not agree, making a >>custom stride somewhat less useful. > > > The custom stride will be back for 2D images (not for 3D/Array), so Navi10-14 > will be the only hw not supporting the custom stride for 2D. It might not be > worth adding the width and height into the modifier just because of > Navi10-14, though I don't feel strongly about it. Right, I'll clarify the text. I meant standardizing how we get the surface_size/dcc_size/total_size (+ alignment of DCC metadata if bigger than surface alignment), so we get to agree about offsets. I believe we should not put in width/height in the modifier as (1) we are allowed to assume every party in negotiation puts in the same width (even though minigbm violates that currently ...) (2) this would be not workable with most enumeration APIs. > > This patch doesn't add the sizes into the description anyway. > > The rest looks good. > > Marek > >> >> >> - No usage of BO metadata at all for modifier usecases. >>To avoid the requirement of dedicated dma bufs per image. For >>non-modifier based interop we still use the BO metadata, since we >>need to keep compatibility with old mesa and this is used for >>depth/msaa/3d/CL etc. API interop. >> >> - A single FD for all planes. >>Easier in Vulkan / bindless and radeonsi is already transitioning. >> >> - Make a single modifier for DCN1 >> It defines things uniquely given bpp, which we can assume, so adding >> more modifier values do not add clarity. >> >> - Not exposing the 4K and 256B tiling modes. >> These are largely only better for something like a cursor or very long >> and/or tall images. Are they worth the added complexity to save memory? >> For context, at 32bpp, tiles are 128x128 pixels. >> >> - For multiplane images, every plane uses the same tiling. >> On GFX9/GFX10 we can, so no need to make it complicated. >> >> - We use family_id + external_rev to distinguish between incompatible GPUs. >> PCI ID is not enough, as RAVEN and RAVEN2 have the same PCI device id, >> but different tiling. We might be able to find bigger equivalence >> groups for _X, but especially for DCC I would be uncomfortable making >> it >> shared between GPUs. >> >> - For DCN1 DCC, radeonsi currently uses another texelbuffer with indices >> to reorder. This is not shared. >> Specific to current implementation and does not need to be shared. To >> pave the way to shader-based solution, lets keep this internal to each >> driver. This should reduce the modifier churn if any of the driver >> implementations change. (Especially as you'd want to support the old >> implementation for a while to stay compatible with old kernels not >> supporting a new modifier yet). >> >> - No support for rotated swizzling. >> Can be added easily later and nothing in the stack would generate it >> currently. >> >> - Add extra enum values in the definitions. >> This way we can easily switch on modifier without having to pass around >> the current GPU everywhere, assuming the modifier has been validated. >> --- >> >> Since my previous attempt for modifiers got bogged down on details for >> the GFX6-GFX8 modifiers in previous discussions, this only attempts to >> define modifiers for GFX9+, which is significantly simpler. >> >> For a final version I'd like to wait until I have written most of the >> userspace + kernelspace so we can actually test it. However, I'd >> appreciate any early feedback people are willing to give. >> >> Initial Mesa amd/common
Re: [PATCH v7] unstable/drm-lease: DRM lease protocol support
On Fri, 18 Oct 2019 10:43:16 -0400 "Drew DeVault" wrote: > Regarding hotplugging, the Wayland compositor is probably keeping track > of hotplugs itself and withdrawing/offering connectors as appropriate. > Also, when the lease is issued, the compositor withdraws that connector. > For the client, upon hotplug I imagine the DRM asks start to fail, and > it handles that accordingly (presumably it'll close the lease, if the > compositor hasn't already, and wait for it to come back, or just exit). DRM KMS operations do not fail merely because a connector becomes disconnected. You can even force on a connector that is initially disconnected. If you mean on revoking the lease or losing DRM master, yes, then I'd expect KMS ioctls start to fail. But is disconnection reason enough to revoke the lease? I guess we shall see. > When a hotplug of a leased connector happens on the compositor side, it > can notice this and exercise its descretion in the implementation. I > think the current text of the protocol supports this view. Ok, so the expectation is that a compositor does not offer disconnected connectors, and withdraws offered but then disconnected connectors, and that it sends offers for connectors that become connected while leasable. I suppose that is reasonable, I still think a sentence suggesting towards such behaviour would be in place. Btw. there is more to hotplug events than just connected/disconnected: link status changes, and HDCP status changes. I suspect more is coming, too. At some point we might need to add a hotplug event in the protocol, but I think that is easy to do even after stabilization. Thanks, pq pgp9fiHEgvl9a.pgp Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7] unstable/drm-lease: DRM lease protocol support
On Fri, 2019-10-18 at 10:43 -0400, Drew DeVault wrote: > Regarding hotplugging, the Wayland compositor is probably keeping track > of hotplugs itself and withdrawing/offering connectors as appropriate. > > Also, when the lease is issued, the compositor withdraws that connector. > For the client, upon hotplug I imagine the DRM asks start to fail, and > it handles that accordingly (presumably it'll close the lease, if the > compositor hasn't already, and wait for it to come back, or just exit). Right. Whether it waits or quits should be the decision of the client, and I'd like there to be a good way to "wait for it to come back" (or to appear, initially). If the compositor sends a new zwp_drm_lease_manager_v1.connector event after the HMD connector becomes leasable (again), that should be good enough. [...] > > So Wayland display servers should make sure they have master themselves > > before sending a supposedly non-master DRM fd to anyone else. I wonder > > if the Wayland protocol extension needs to consider that the compositor > > might not be able to send any fd soon. Being able to defer sending the > > fd should probably be mentioned in the protocol spec, so that clients > > do not expect a simple roundtrip to be enough to ensure the fd has > > arrived. > > When you VT switch away, the Wayland compositor is no longer necessarily > able to lease those displays anyway - it's not the master anymore. So it > should withdraw them, and in case of a race it'll reject the lease > request. Right. On VT switch away, revoking all leases and disabling those connectors is the only sensible thing the compositor can do. However, that is completely independent from the sending the drm_fd event. The spec currently says: "The compositor will send this event when the zwp_drm_lease_manager_v1 global is bound.". But if the client binds the global while the compositor doesn't have DRM master privilege, and if it is not possible to securely produce a non-master drm_fd to send at this time, maybe the sentence should be changed to "The compositor will send this event some time after the zwp_drm_lease_manager_v1 global is bound."? regards Philipp ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 0/7] backlight: gpio: simplify the driver
Hi, On Thu, Oct 17, 2019 at 08:25:50AM +0100, Lee Jones wrote: > On Wed, 16 Oct 2019, Jacopo Mondi wrote: > > > Hi, sorry for not having replied earlier > > > > On Wed, Oct 16, 2019 at 02:56:57PM +0200, Linus Walleij wrote: > > > On Mon, Oct 14, 2019 at 10:12 AM Lee Jones wrote: > > > > > > > > arch/sh/boards/mach-ecovec24/setup.c | 33 -- > > > > > > > > I guess we're just waiting for the SH Acks now? > > > > > > The one maintainer with this board is probably overloaded. > > > > > > I would say just apply it, it can't hold back the entire series. > > > > I've been able to resurect the Ecovec, and I've also been given a copy > > of its schematics file a few weeks ago. > > > > It's in my TODO list to test this series but I didn't manage to find > > time. If I pinky promise I get back to you before end of the week, > > could you wait for me ? :) Finally had some time to spend on this. As I've reported to Bartosz, this version does not work on Ecovec out of the box, as the GPIO line connected to the backlight needs to be configured to work in output mode before registering the backlight device. With this simple change: $ git diff diff --git a/arch/sh/boards/mach-ecovec24/setup.c b/arch/sh/boards/mach-ecovec24/setup.c index dd427bac5cde..eec6e805c3ed 100644 --- a/arch/sh/boards/mach-ecovec24/setup.c +++ b/arch/sh/boards/mach-ecovec24/setup.c @@ -1473,6 +1473,7 @@ static int __init arch_setup(void) #endif #endif + gpio_direction_output(GPIO_PTR1, 1); gpiod_add_lookup_table(_backlight_lookup); gpio_backlight_device = platform_device_register_full( _backlight_device_info); I can now control the gpio through the backlight interface. So please add this bit on top of next iteration and add my: Tested-by: Jacopo Mondi Thanks and sorry for the long time it took! > > Yes, no problem. > > -- > Lee Jones [李琼斯] > Linaro Services Technical Lead > Linaro.org │ Open source software for ARM SoCs > Follow Linaro: Facebook | Twitter | Blog signature.asc Description: PGP signature
Re: [PATCH v7] unstable/drm-lease: DRM lease protocol support
On Fri, 18 Oct 2019 16:19:33 +0200 Daniel Vetter wrote: > On Fri, Oct 18, 2019 at 3:43 PM Pekka Paalanen wrote: > > > > On Fri, 18 Oct 2019 07:54:50 -0400 > > "Drew DeVault" wrote: > > > > > On Fri Oct 18, 2019 at 12:21 PM Pekka Paalanen wrote: > > > > One thing I did not know the last time was that apparently > > > > systemd-logind may not like to give out non-master DRM fds. That might > > > > need fixing in logind implementations. I hope someone would step up to > > > > look into that. > > > > > > > > This protocol aims to deliver a harmless "read-only" DRM device file > > > > description to a client, so that the client can enumerate all DRM > > > > resources, fetch EDID and other properties to be able to decide which > > > > connector it would want to lease. The client should not be able to > > > > change any KMS state through this fd, and it should not be able to e.g. > > > > spy on display contents. The assumption is that a non-master DRM fd > > > > from a fresh open() would be fine for this, but is it? > > > > > > What I do for wlroots is call drmGetDeviceNameFromFd2, which returns the > > > path to the device file, and then I open() it and use > > > drmIsMaster/drmDropMaster to make sure it's not a master fd. This seems > > > to work correctly in practice. > > > > That is nice. > > > > Personally I'm specifically worried about a setup where the user has no > > access permissions to open the DRM device node directly, as is (or > > should be) the case with input devices. > > > > However, since DRM has the master concept which input devices do not, > > maybe there is no reason to prevent a normal user from opening a DRM > > device directly. That is, if our assumption that a non-master DRM fd is > > harmless holds. > > > > (Wayland display servers usually run as a normal user, while logind > > or another service runs with elevated privileges and opens input and > > DRM devices on behalf of the display server.) > > So the rules are (if I'm not making a mistake) > - If you're not CAP_SYS_ADMIN you can't get/drop_master. Hi, not able to drop, yikes. So if someone pokes the Wayland DRM leasing interface while the display server is VT switched away (does not have DRM master), and maybe no-one else has DRM master either (you're hacking in VT text mode), then a new DRM fd would be master with no way out? So Wayland display servers should make sure they have master themselves before sending a supposedly non-master DRM fd to anyone else. I wonder if the Wayland protocol extension needs to consider that the compositor might not be able to send any fd soon. Being able to defer sending the fd should probably be mentioned in the protocol spec, so that clients do not expect a simple roundtrip to be enough to ensure the fd has arrived. > - This is a bit awkward, since non-root can become a master, when > there's no other master right at this point. So if you want to be able > to do this, we should probably clarify this part of the uapi somehow > (either de-priv drop_master or make sure non-root can't become master, > but the latter probably will break something somewhere). Plus igts to > lock down this behaviour. Note that if logind does a vt switch there's > a race window where no one is master and you might be able to squeeze > in. So perhaps we do want to stop this behaviour and require > CAP_SYS_ADMIN to become master, even accidentally. That would close the loophole that Ville mentioned, too, otherwise distributions should aim to not give permissions to open the DRM device node. > - I thought you can always re-open your own fd through proc? Which > should be good enough for this use-case here. We can? And that creates a new file description the same way as open() in the original device node? Does that avoid becoming master in the above VT-switched-away scenario? > - Non-master primary node should indeed give you all the GET* ioctls > for kms, and nothing else useful or at least dangerous (you might be > able to render with that thing). Just make sure you dont authenticate > that new fd. Again maybe we should clarify our docs a bit to make this > use case official. Awesome, thanks, pq pgpIMcz8OpXnm.pgp Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] new uapi policy for drm
On Thu, Oct 17, 2019 at 4:12 PM Alex Deucher wrote: > > On Thu, Oct 17, 2019 at 9:58 AM Daniel Vetter wrote: > > > > On Wed, Oct 16, 2019 at 04:00:25PM -0400, Alex Deucher wrote: > > > On Mon, Oct 14, 2019 at 2:16 PM Dave Airlie wrote: > > > > > > > > I've kicked this around in my head over the past few weeks but wanted > > > > to get some feedback on whether it's a good idea or what impact it > > > > might have that I haven't considered. > > > > > > > > We are getting requests via both amdgpu/amdkfd and i915 for new user > > > > APIs for userspace drivers that throw code over the wall instead of > > > > being open source developed projects, but we are also seeing it for > > > > android drivers and kms properties, and we had that i915 crappy crtc > > > > background thing that was for Chrome but Chrome didn't want it. > > > > > > > > Now this presents a couple of issues: > > > > > > > > a) these projects don't seem to that good at following our development > > > > guidelines, avoid developing userspace features in parallel in the > > > > open and having good development implementations before submitting > > > > upstream. > > > > > > > > b) these projects don't have experienced userspace developers > > > > reviewing their kernel uapis. One big advantage of adding uapis with > > > > mesa developers is they have a lot of experience in the area as well. > > > > > > > > It's leading me to think I want to just stop all uapi submissions via > > > > driver trees, and instead mandate that all driver uapi changes are > > > > sent in separate git pull requests to dri-devel, I'd try (with some > > > > help) to catch all uapi modifications in normal trees, and refuse > > > > pulls that modified uapi. > > > > > > > > At least I'm considered writing the script and refusing and pulls that > > > > have a uapi change that doesn't contain a link to the userspace > > > > changes required for it in a public developed repo. > > > > > > > > Thoughts? > > > > > > This seems like more hassle for questionable benefits. I don't know > > > that mesa is really any better than any other driver teams with > > > respect to UAPI. This just seems like sort of a arbitrary political > > > decision. The people working on mesa have as much of an agenda as > > > those working on other projects. Moreover, especially with the > > > migration to gitlab and MRs, I feel that mesa development has gotten > > > more opaque. Say what you will about mailing lists, but at least you > > > could have a drive by view of what's going on. With MRs, you sort of > > > have to seek out what to review; if stuff is not tagged with something > > > you feel is relevant, you probably won't look at it, so the only > > > people likely to review it are the people involved in writing it in > > > the first place, which would be the same whether it's mesa or some > > > other project. I think all of the projects generally have the best > > > intentions at heart, but for better or worse they just have different > > > development models. In the case of the AMD throw it over the wall > > > stuff, it's not really an anti-open source or community engagement > > > issue, it's more of how to we support several OSes, tons of new > > > products, several custom projects, etc. while leveraging as much > > > shared code as possible. There are ways to make it work, but they are > > > usually a pretty heavy lift that not all teams can make. > > > > I think there's a difference between All Tools Sucks (tm) and the > > discussions not even being accessible at all. I do agree that generally > > everyone screws up uapi once in a while, and we seem to overall do a not > > too shoddy job. So code is probably all ok enough. > > > > But imo long term code is fungible and really doesn't matter much, the > > important stuff is the people and teams who create it, and all the shared > > knowledge. That's also were I see the benefit in upstream (for customers > > and vendors and everyone), we can learn from each another. As an example, > > I've spent lots of time recently reading amdgpu code and how it's used in > > userspace. Understanding that without having access to the discussion or > > being able to ping people on irc and mailing lists would have been > > impossible - lots of questions where I just plain guessed wrong. For the > > code-over-wall projects that stuff all simply doesn't exist. It's nigh > > impossible to figure out whether uapi makes sense or not if you can't see > > all the tradeoffs and discussions that influenced it and why. > > > > That's also why I think the separate pull won't help at all, since Dave > > will still have incomplete information. All he can do with more pulls is > > roll the die more often, that's not helping. > > > > Now short term "moar hw support" is cool and all that, but long term I do > > think it's missing the point of upstreaming. It's not that mesa (or any > > other cross vendor project, we have a bunch of those on the kms side) is > >
Re: [PATCH V4 5/6] virtio: introduce a mdev based transport
On Thu, 17 Oct 2019 18:48:35 +0800
Jason Wang wrote:
> This patch introduces a new mdev transport for virtio. This is used to
> use kernel virtio driver to drive the mediated device that is capable
> of populating virtqueue directly.
>
> A new virtio-mdev driver will be registered to the mdev bus, when a
> new virtio-mdev device is probed, it will register the device with
> mdev based config ops. This means it is a software transport between
> mdev driver and mdev device. The transport was implemented through
> device specific ops which is a part of mdev_parent_ops now.
>
> Signed-off-by: Jason Wang
> ---
> drivers/virtio/Kconfig | 7 +
> drivers/virtio/Makefile | 1 +
> drivers/virtio/virtio_mdev.c | 409 +++
> 3 files changed, 417 insertions(+)
(...)
> +static int virtio_mdev_probe(struct device *dev)
> +{
> + struct mdev_device *mdev = mdev_from_dev(dev);
> + const struct virtio_mdev_device_ops *ops = mdev_get_dev_ops(mdev);
> + struct virtio_mdev_device *vm_dev;
> + int rc;
> +
> + vm_dev = devm_kzalloc(dev, sizeof(*vm_dev), GFP_KERNEL);
> + if (!vm_dev)
> + return -ENOMEM;
> +
> + vm_dev->vdev.dev.parent = dev;
> + vm_dev->vdev.dev.release = virtio_mdev_release_dev;
> + vm_dev->vdev.config = _mdev_config_ops;
> + vm_dev->mdev = mdev;
> + INIT_LIST_HEAD(_dev->virtqueues);
> + spin_lock_init(_dev->lock);
> +
> + vm_dev->version = ops->get_mdev_features(mdev);
> + if (vm_dev->version != VIRTIO_MDEV_F_VERSION_1) {
> + dev_err(dev, "VIRTIO_MDEV_F_VERSION_1 is mandatory\n");
> + return -ENXIO;
> + }
Hm, so how is that mdev features interface supposed to work? If
VIRTIO_MDEV_F_VERSION_1 is a bit, I would expect this code to test for
its presence, and not for identity.
What will happen if we come up with a version 2? If this is backwards
compatible, will both version 2 and version 1 be set?
> +
> + vm_dev->vdev.id.device = ops->get_device_id(mdev);
> + if (vm_dev->vdev.id.device == 0)
> + return -ENODEV;
> +
> + vm_dev->vdev.id.vendor = ops->get_vendor_id(mdev);
> + rc = register_virtio_device(_dev->vdev);
> + if (rc)
> + put_device(dev);
> + else
> + dev_set_drvdata(dev, vm_dev);
> +
> + return rc;
> +}
(...)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7] unstable/drm-lease: DRM lease protocol support
On Fri, Oct 18, 2019 at 3:43 PM Pekka Paalanen wrote: > > On Fri, 18 Oct 2019 07:54:50 -0400 > "Drew DeVault" wrote: > > > On Fri Oct 18, 2019 at 12:21 PM Pekka Paalanen wrote: > > > One thing I did not know the last time was that apparently > > > systemd-logind may not like to give out non-master DRM fds. That might > > > need fixing in logind implementations. I hope someone would step up to > > > look into that. > > > > > > This protocol aims to deliver a harmless "read-only" DRM device file > > > description to a client, so that the client can enumerate all DRM > > > resources, fetch EDID and other properties to be able to decide which > > > connector it would want to lease. The client should not be able to > > > change any KMS state through this fd, and it should not be able to e.g. > > > spy on display contents. The assumption is that a non-master DRM fd > > > from a fresh open() would be fine for this, but is it? > > > > What I do for wlroots is call drmGetDeviceNameFromFd2, which returns the > > path to the device file, and then I open() it and use > > drmIsMaster/drmDropMaster to make sure it's not a master fd. This seems > > to work correctly in practice. > > That is nice. > > Personally I'm specifically worried about a setup where the user has no > access permissions to open the DRM device node directly, as is (or > should be) the case with input devices. > > However, since DRM has the master concept which input devices do not, > maybe there is no reason to prevent a normal user from opening a DRM > device directly. That is, if our assumption that a non-master DRM fd is > harmless holds. > > (Wayland display servers usually run as a normal user, while logind > or another service runs with elevated privileges and opens input and > DRM devices on behalf of the display server.) So the rules are (if I'm not making a mistake) - If you're not CAP_SYS_ADMIN you can't get/drop_master. - This is a bit awkward, since non-root can become a master, when there's no other master right at this point. So if you want to be able to do this, we should probably clarify this part of the uapi somehow (either de-priv drop_master or make sure non-root can't become master, but the latter probably will break something somewhere). Plus igts to lock down this behaviour. Note that if logind does a vt switch there's a race window where no one is master and you might be able to squeeze in. So perhaps we do want to stop this behaviour and require CAP_SYS_ADMIN to become master, even accidentally. - I thought you can always re-open your own fd through proc? Which should be good enough for this use-case here. - Non-master primary node should indeed give you all the GET* ioctls for kms, and nothing else useful or at least dangerous (you might be able to render with that thing). Just make sure you dont authenticate that new fd. Again maybe we should clarify our docs a bit to make this use case official. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7] unstable/drm-lease: DRM lease protocol support
On Fri, Oct 18, 2019 at 04:43:29PM +0300, Pekka Paalanen wrote: > On Fri, 18 Oct 2019 07:54:50 -0400 > "Drew DeVault" wrote: > > > On Fri Oct 18, 2019 at 12:21 PM Pekka Paalanen wrote: > > > One thing I did not know the last time was that apparently > > > systemd-logind may not like to give out non-master DRM fds. That might > > > need fixing in logind implementations. I hope someone would step up to > > > look into that. > > > > > > This protocol aims to deliver a harmless "read-only" DRM device file > > > description to a client, so that the client can enumerate all DRM > > > resources, fetch EDID and other properties to be able to decide which > > > connector it would want to lease. The client should not be able to > > > change any KMS state through this fd, and it should not be able to e.g. > > > spy on display contents. The assumption is that a non-master DRM fd > > > from a fresh open() would be fine for this, but is it? > > > > What I do for wlroots is call drmGetDeviceNameFromFd2, which returns the > > path to the device file, and then I open() it and use > > drmIsMaster/drmDropMaster to make sure it's not a master fd. This seems > > to work correctly in practice. > > That is nice. > > Personally I'm specifically worried about a setup where the user has no > access permissions to open the DRM device node directly, as is (or > should be) the case with input devices. > > However, since DRM has the master concept which input devices do not, > maybe there is no reason to prevent a normal user from opening a DRM > device directly. That is, if our assumption that a non-master DRM fd is > harmless holds. If there is no master then the first guy to open the device automagically becomes the master. Maybe a theoretical DoS vector if you can sneak in and open the device between dropmaster/setmaster? -- Ville Syrjälä Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v12 4/5] dma-buf: heaps: Add CMA heap to dmabuf heaps
On 10/18/19 8:03 AM, Benjamin Gaignard wrote: > Le ven. 18 oct. 2019 à 13:21, Brian Starkey a écrit : >> >> On Fri, Oct 18, 2019 at 05:23:22AM +, John Stultz wrote: >>> This adds a CMA heap, which allows userspace to allocate >>> a dma-buf of contiguous memory out of a CMA region. >>> >>> This code is an evolution of the Android ION implementation, so >>> thanks to its original author and maintainters: >>> Benjamin Gaignard, Laura Abbott, and others! >>> >>> NOTE: This patch only adds the default CMA heap. We will enable >>> selectively adding other CMA memory regions to the dmabuf heaps >>> interface with a later patch (which requires a dt binding) > > Maybe we can use "no-map" DT property to trigger that. If set do not expose > the > cma heap. "no-map" means it can't be used as a regular CMA either, we want some way to both have it as a device usable CMA but also not be exposed to userspace if needed. Andrew > > Benjamin >> >> That'll teach me for reading my email in FIFO order. >> >> This approach makes sense to me. >> >> -Brian >>
Re: [PATCH 2/3] drm/ttm: always keep BOs on the LRU
Hi, Christian, On 10/16/19 11:30 AM, Christian König wrote: Am 25.09.19 um 14:10 schrieb Christian König: Am 25.09.19 um 14:06 schrieb Thomas Hellström (VMware): On 9/25/19 12:55 PM, Christian König wrote: This allows blocking for BOs to become available in the memory management. Amdgpu is doing this for quite a while now during CS. Now apply the new behavior to all drivers using TTM. Signed-off-by: Christian König Got to test this to see that there are no regressions. Did you got time to test this or did I just missed your response? Thanks in advance, Christian. Sorry for the delay. A lot on my plate currently. I'll get around to this later today or on monday. Thanks, Thomas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] dt-bindings: etnaviv: Add #cooling-cells
Hi, On Wed, Sep 11, 2019 at 07:40:36PM -0700, Guido Günther wrote: > Add #cooling-cells for when the gpu acts as a cooling device. > > Signed-off-by: Guido Günther > --- > .../devicetree/bindings/display/etnaviv/etnaviv-drm.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git > a/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt > b/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt > index 8def11b16a24..640592e8ab2e 100644 > --- a/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt > +++ b/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt > @@ -21,6 +21,7 @@ Required properties: > Optional properties: > - power-domains: a power domain consumer specifier according to >Documentation/devicetree/bindings/power/power_domain.txt > +- #cooling-cells: : If used as a cooling device, must be <2> The other patch of the series made it into linux-next already but this documentation fixup didn't. Anything i can do to get this applied as well so documentation stays in sync? Cheers, -- Guido > > example: > > -- > 2.23.0.rc1 > > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [PULL] drm-misc-next
Hi Sean, On 17/10/2019 22:26, Sean Paul wrote: concern for those. The omap OMAP_BO_MEM_* changes though I don't think have really reached non-TI eyes. There's no link in the commit message to a UAPI implementation and the only reference I could find is libkmsxx which can set them through the python bindings. Since this is TI-specific gunk in TI-specific headers I'm inclined to let it pass, but I would have liked to have this conversation upfront. I figured I'd call this out so you have final say. There was some discussion about that a few years back when I initially sent the patches, but now that I look, the discussion died before really even starting. This is what I said about userspace implementation: Yes, unfortunately that is not going to happen. I don't see how this could be used in a generic system like Weston or X. It's meant for very specific use cases, where you know exactly the requirements of your application and the capabilities of the whole system, and optimize based on that. I know this feature is used by customers, but I don't have access to their applications. Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7] unstable/drm-lease: DRM lease protocol support
On Fri, 18 Oct 2019 07:54:50 -0400 "Drew DeVault" wrote: > On Fri Oct 18, 2019 at 12:21 PM Pekka Paalanen wrote: > > One thing I did not know the last time was that apparently > > systemd-logind may not like to give out non-master DRM fds. That might > > need fixing in logind implementations. I hope someone would step up to > > look into that. > > > > This protocol aims to deliver a harmless "read-only" DRM device file > > description to a client, so that the client can enumerate all DRM > > resources, fetch EDID and other properties to be able to decide which > > connector it would want to lease. The client should not be able to > > change any KMS state through this fd, and it should not be able to e.g. > > spy on display contents. The assumption is that a non-master DRM fd > > from a fresh open() would be fine for this, but is it? > > What I do for wlroots is call drmGetDeviceNameFromFd2, which returns the > path to the device file, and then I open() it and use > drmIsMaster/drmDropMaster to make sure it's not a master fd. This seems > to work correctly in practice. That is nice. Personally I'm specifically worried about a setup where the user has no access permissions to open the DRM device node directly, as is (or should be) the case with input devices. However, since DRM has the master concept which input devices do not, maybe there is no reason to prevent a normal user from opening a DRM device directly. That is, if our assumption that a non-master DRM fd is harmless holds. (Wayland display servers usually run as a normal user, while logind or another service runs with elevated privileges and opens input and DRM devices on behalf of the display server.) Thanks, pq pgp2W2GNY7Z5B.pgp Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 205049] garbled graphics
https://bugzilla.kernel.org/show_bug.cgi?id=205049 --- Comment #11 from Alex Deucher (alexdeuc...@gmail.com) --- Can you bisect? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V4 4/6] mdev: introduce virtio device and its device ops
On Fri, 18 Oct 2019 18:55:02 +0800 Jason Wang wrote: > On 2019/10/18 下午5:46, Cornelia Huck wrote: > > On Thu, 17 Oct 2019 18:48:34 +0800 > > Jason Wang wrote: > >> + * @get_vendor_id:Get virtio vendor id > >> + *@mdev: mediated device > >> + *Returns u32: virtio vendor id > > How is the vendor id defined? As for normal virtio-pci devices? > > > The vendor that provides this device. So something like this > > I notice that MMIO also had this so it looks to me it's not pci specific. Ok. Would be good to specify this more explicitly. > > > > > >> + * @get_status: Get the device status > >> + *@mdev: mediated device > >> + *Returns u8: virtio device status > >> + * @set_status: Set the device status > >> + *@mdev: mediated device > >> + *@status: virtio device status > >> + * @get_config: Read from device specific configuration space > >> + *@mdev: mediated device > >> + *@offset: offset from the beginning of > >> + *configuration space > >> + *@buf: buffer used to read to > >> + *@len: the length to read from > >> + *configration space > >> + * @set_config: Write to device specific configuration space > >> + *@mdev: mediated device > >> + *@offset: offset from the beginning of > >> + *configuration space > >> + *@buf: buffer used to write from > >> + *@len: the length to write to > >> + *configration space > >> + * @get_mdev_features:Get the feature of virtio mdev device > >> + *@mdev: mediated device > >> + *Returns the mdev features (API) support > >> by > >> + *the device. > > What kind of 'features' are supposed to go in there? Are these bits, > > like you defined for VIRTIO_MDEV_F_VERSION_1 above? > > > It's the API or mdev features other than virtio features. It could be > used by driver to determine the capability of the mdev device. Besides > _F_VERSION_1, we may add dirty page tracking etc which means we need new > device ops. Ok, so that's supposed to be distinct bits that can be or'ed together? Makes sense, but probably needs some more documentation somewhere. > > > > > >> + * @get_generation: Get device generaton > >> + *@mdev: mediated device > >> + *Returns u32: device generation > > Is that callback mandatory? > > > I think so, it's hard to emulate that completely in virtio-mdev transport. IIRC, the generation stuff is not mandatory in the current version of virtio, as not all transports have that concept. Generally, are any of the callbacks optional, or are all of them mandatory? From what I understand, you plan to add new things that depend on features... would that mean non-mandatory callbacks? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111980] Rebbot and shutdown doesn't work on specific hardware
https://bugs.freedesktop.org/show_bug.cgi?id=111980 Alex Deucher changed: What|Removed |Added See Also||https://bugzilla.kernel.org ||/show_bug.cgi?id=205147 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111980] Rebbot and shutdown doesn't work on specific hardware
https://bugs.freedesktop.org/show_bug.cgi?id=111980 --- Comment #5 from Alex Deucher --- Reverted: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8d13c187c42e110625d60094668a8f778c092879 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111980] Rebbot and shutdown doesn't work on specific hardware
https://bugs.freedesktop.org/show_bug.cgi?id=111980 Alex Deucher changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 205147] Unable to shut down - radeon_drv.c - radeon_suspend_kms()
https://bugzilla.kernel.org/show_bug.cgi?id=205147 --- Comment #4 from Alex Deucher (alexdeuc...@gmail.com) --- Reverted: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8d13c187c42e110625d60094668a8f778c092879 -- 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 111481] AMD Navi GPU frequent freezes on both Manjaro/Ubuntu with kernel 5.3 and mesa 19.2 -git/llvm9
https://bugs.freedesktop.org/show_bug.cgi?id=111481 --- Comment #108 from Daniel Suarez --- (In reply to Marko Popovic from comment #107) > (In reply to Daniel Suarez from comment #106) > > I do agree we should remain civilized in this, but user is correct, this is > > ridiculous. > > > > This would be somewhat understandable if this was a GPU from the business > > line and it was a GPU barely anyone owns, but this is a popular GPU and it > > is constantly recommended to others. > > Yes, Imagine if a bussiness with 100 linux workstations went for Navi cards > and faced these issues... it would be a tremendous loss for them, I really > don't think that this was fair to AMD Linux customers at all, but calling > them names won't get us anywhere. > > and just as we speak about that I had a random SDMA hang in Firefox, they > are way less frequent in FF now, but very much still present. I don't think anyone here is calling anyone anything, just that amd needs to get their shit together, which is completely true. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
