Re: [RFC 10/13] drm/dp_helper: Add support for Configuring DSC for HDMI2.1 Pcon
On 10/19/2020 4:49 AM, Shankar, Uma wrote:
-Original Message-
From: Nautiyal, Ankit K
Sent: Thursday, October 15, 2020 4:23 PM
To: intel-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org; Shankar, Uma ;
Kulkarni, Vandita ; ville.syrj...@linux.intel.com;
Sharma, Swati2
Subject: [RFC 10/13] drm/dp_helper: Add support for Configuring DSC for
HDMI2.1 Pcon
This patch adds registers for getting DSC encoder capability for a HDMI2.1 PCon.
It also addes helper functions to configure DSC between the PCON and HDMI2.1
sink.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/drm_dp_helper.c | 93 +++
include/drm/drm_dp_helper.h | 109
2 files changed, 202 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_helper.c
b/drivers/gpu/drm/drm_dp_helper.c index 33a4ac2fb225..f10a9c2d6f04 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -2929,3 +2929,96 @@ void drm_dp_pcon_hdmi_frl_link_error_count(struct
drm_dp_aux *aux,
}
}
EXPORT_SYMBOL(drm_dp_pcon_hdmi_frl_link_error_count);
+
+static
+int drm_dp_pcon_configure_dsc_enc(struct drm_dp_aux *aux, u8
+pps_buf_config) {
+u8 buf = 0;
+int ret;
+
+buf |= DP_PCON_ENABLE_DSC_ENCODER;
Directly assign it.
Alright, will change in next version.
+if (pps_buf_config <= DP_PCON_ENC_PPS_OVERRIDE_EN_BUFFER) {
+buf &= ~DP_PCON_ENCODER_PPS_OVERRIDE_MASK;
+buf |= pps_buf_config << 2;
+}
+
+ret = drm_dp_dpcd_writeb(aux,
DP_PROTOCOL_CONVERTER_CONTROL_2, buf);
+if (ret < 0)
+return ret;
+
+return 0;
+}
+
+/**
+ * drm_dp_pcon_pps_default() - Let PCON fill the default pps parameters
+ * for DSC1.2 between PCON & HDMI2.1 sink
+ * @aux: DisplayPort AUX channel
+ *
+ * Returns 0 on success, else returns negative error code.
+ * */
+int drm_dp_pcon_pps_default(struct drm_dp_aux *aux) {
+int ret;
+
+ret = drm_dp_pcon_configure_dsc_enc(aux,
DP_PCON_ENC_PPS_OVERRIDE_DISABLED);
+if (ret < 0)
+return ret;
+
+return 0;
+}
+EXPORT_SYMBOL(drm_dp_pcon_pps_default);
+
+/**
+ * drm_dp_pcon_pps_override_buf() - Configure PPS encoder override
+buffer for
+ * HDMI sink
+ * @aux: DisplayPort AUX channel
+ * @pps_buf: 128 bytes to be written into PPS buffer for HDMI sink by PCON.
+ *
+ * Returns 0 on success, else returns negative error code.
+ * */
+int drm_dp_pcon_pps_override_buf(struct drm_dp_aux *aux, u8
+pps_buf[128]) {
+int ret;
+
+ret = drm_dp_dpcd_write(aux, DP_PCON_HDMI_PPS_OVERRIDE_BASE,
&pps_buf, 128);
+if (ret < 0)
+return ret;
+
+ret = drm_dp_pcon_configure_dsc_enc(aux,
DP_PCON_ENC_PPS_OVERRIDE_EN_BUFFER);
+if (ret < 0)
+return ret;
+
+return 0;
+}
+EXPORT_SYMBOL(drm_dp_pcon_pps_override_buf);
+
+/*
+ * drm_dp_pcon_pps_override_param() - Write PPS parameters to DSC
+encoder
+ * override registers
+ * @aux: DisplayPort AUX channel
+ * @pps_param: 3 Parameters (2 Bytes each) : Slice Width, Slice Height,
+ * bits_per_pixel.
+ *
+ * Returns 0 on success, else returns negative error code.
+ * */
+int drm_dp_pcon_pps_override_param(struct drm_dp_aux *aux, u8
+pps_param[6]) {
+int ret;
+
+ret = drm_dp_dpcd_write(aux,
DP_PCON_HDMI_PPS_OVRD_SLICE_HEIGHT, &pps_param[0], 2);
+if (ret < 0)
+return ret;
+ret = drm_dp_dpcd_write(aux,
DP_PCON_HDMI_PPS_OVRD_SLICE_WIDTH, &pps_param[1], 2);
+if (ret < 0)
+return ret;
+ret = drm_dp_dpcd_write(aux, DP_PCON_HDMI_PPS_OVRD_BPP,
&pps_param[2], 2);
+if (ret < 0)
+return ret;
+
+ret = drm_dp_pcon_configure_dsc_enc(aux,
DP_PCON_ENC_PPS_OVERRIDE_EN_BUFFER);
+if (ret < 0)
+return ret;
+
+return 0;
+}
+EXPORT_SYMBOL(drm_dp_pcon_pps_override_param);
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index
eb26c86dc8ca..3de022d4a65e 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -441,6 +441,83 @@ struct drm_device;
# define DP_FEC_CORR_BLK_ERROR_COUNT_CAP(1 << 2)
# define DP_FEC_BIT_ERROR_COUNT_CAP(1 << 3)
+/* DP-HDMI2.1 PCON DSC ENCODER SUPPORT */
+#define DP_PCON_DSC_ENCODER 0x092
+# define DP_PCON_DSC_ENCODER_SUPPORTED (1 << 0)
+# define DP_PCON_DSC_PPS_ENC_OVERRIDE (1 << 1)
+
+/* DP-HDMI2.1 PCON DSC Version */
+#define DP_PCON_DSC_VERSION 0x093
+# define DP_PCON_DSC_MAJOR_MASK(0xF << 0)
+# define DP_PCON_DSC_MINOR_MASK(0xF << 4)
+# define DP_PCON_DSC_MAJOR_SHIFT0
+# define DP_PCON_DSC_MINOR_SHIFT4
+
+/* DP-HDMI2.1 PCON DSC RC Buffer block size */
+#define DP_PCON_DSC_RC_BUF_BLK_INFO0x094
+# define DP_PCON_DSC_RC_BUF_BLK_SIZE(0x3 << 0)
+# define DP_PCON_DSC_RC_BUF_BLK_1KB0
+# define DP_PCON_DSC_RC_BUF_BLK_4KB1
+# define DP_PCON_DSC_RC_BUF_BLK_16KB2
+# define DP_PCON_DSC_RC_BUF_BLK_64KB3
+
+/* DP-HDMI2.1 PCON DSC RC Buffer size */
+#define DP_PCON_DSC_RC_BUF_SIZE0x095
+
+/* DP-HDMI2.1 PCON DSC Slice capabilities-1 */
+#define DP_PCON_DSC_SLICE_CAP_10x096
+# define DP_PCON_DSC_1_PER_DSC_ENC (0x1 << 0)
+# define DP_PCON_DSC_2_PER_DSC_ENC (0x1 << 1)
+# define DP_PCON_DSC_4_PER_DSC_ENC
Re: [RFC 11/13] drm/i915: Read DSC capabilities of the HDMI2.1 PCON encoder
On 10/19/2020 5:02 AM, Shankar, Uma wrote:
-Original Message-
From: Nautiyal, Ankit K
Sent: Thursday, October 15, 2020 4:23 PM
To: intel-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org; Shankar, Uma ;
Kulkarni, Vandita ; ville.syrj...@linux.intel.com;
Sharma, Swati2
Subject: [RFC 11/13] drm/i915: Read DSC capabilities of the HDMI2.1 PCON
encoder
This patch adds a helper function to read the DSC capabilities of the
HDMI2.1 PCon encoder. It also adds a new structure to store these caps, which
can then be used to get the PPS parameters for PCON-HDMI2.1 sink pair. Which
inturn will be used to take a call to override the existing PPS-metadata, by
either
writing the entire new PPS metadata, or by writing only the PPS override
parameters.
Signed-off-by: Ankit Nautiyal
---
.../drm/i915/display/intel_display_types.h| 16 ++
drivers/gpu/drm/i915/display/intel_dp.c | 178 ++
2 files changed, 194 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 6c69922313d6..23282695a47f 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1292,6 +1292,21 @@ struct intel_dp_pcon_frl {
int trained_rate_gbps;
};
+struct intel_dp_pcon_dsc {
+bool enc_support;
+bool pps_override_support;
+bool blk_prediction_support;
+u8 version_major;
+u8 version_minor;
+u8 color_fmt_mask;
+u8 color_depth_mask;
+u8 max_slices;;
+u8 max_slice_width;
+u8 line_buf_bit_depth;
+u8 bpp_precision_incr;
+int rc_buf_size;
+};
+
struct intel_dp {
i915_reg_t output_reg;
u32 DP;
@@ -1415,6 +1430,7 @@ struct intel_dp {
bool hobl_active;
struct intel_dp_pcon_frl frl;
+struct intel_dp_pcon_dsc pcon_dsc;
};
enum lspcon_vendor {
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index e6c4cb844e37..b4f8abaea607 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -3882,6 +3882,182 @@ cpt_set_link_train(struct intel_dp *intel_dp,
intel_de_posting_read(dev_priv, intel_dp->output_reg); }
+void intel_dp_get_pcon_dsc_cap(struct intel_dp *intel_dp) {
+u8 buf;
+u8 rc_buf_blk_size;
+u8 max_slices = 0;
+
+struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+struct intel_dp_pcon_dsc *pcon_dsc = &intel_dp->pcon_dsc;
+
+if (drm_dp_dpcd_readb(&intel_dp->aux, DP_PCON_DSC_ENCODER, &buf)
< 0) {
+drm_err(&i915->drm, "Failed to read
DP_PCON_DSC_ENCODER\n");
+return;
+}
+pcon_dsc->enc_support = buf & DP_PCON_DSC_ENCODER_SUPPORTED;
+pcon_dsc->pps_override_support = buf &
DP_PCON_DSC_PPS_ENC_OVERRIDE;
+
+if (drm_dp_dpcd_readb(&intel_dp->aux, DP_PCON_DSC_VERSION, &buf)
< 0) {
+drm_err(&i915->drm, "Failed to read
DP_PCON_DSC_VERSION\n");
+return;
If we fail here or in any of the subsequent calls below shouldn't we reset the
dsc params saying DSC not
supported. Else we may return with ex.
pcon_dsc->enc_support = buf & DP_PCON_DSC_ENCODER_SUPPORTED
which would ideally not be right.
You are right, will take care in next patch. If dsc 1.2 is not supported
we will not configure PCON encode DSC DPCDs.
Also I have realized, we do not use all the information for writing PPS
parameters.
So aligning with the existing code, will read all the pcon's DSC encoder
caps and store in intel_dp structure in a u8 array.
Will have drm helper functions to retrieve values like max slices, max
slice with and bpp precision which need some processing, based on the
port caps.
+}
+pcon_dsc->version_major = (buf & DP_PCON_DSC_MAJOR_MASK) >>
+ DP_PCON_DSC_MAJOR_SHIFT;
+pcon_dsc->version_minor = (buf & DP_PCON_DSC_MINOR_MASK) >>
+ DP_PCON_DSC_MINOR_SHIFT;
+
+if (drm_dp_dpcd_readb(&intel_dp->aux,
DP_PCON_DSC_RC_BUF_BLK_INFO, &buf) < 0) {
+drm_err(&i915->drm, "Failed to read
DP_PCON_DSC_RC_BUF_BLK_INFO\n");
+return;
+}
+
+switch (buf & DP_PCON_DSC_RC_BUF_BLK_SIZE) {
+case DP_PCON_DSC_RC_BUF_BLK_1KB :
+rc_buf_blk_size = 1;
+break;
+case DP_PCON_DSC_RC_BUF_BLK_4KB :
+rc_buf_blk_size = 4;.
+break;
+case DP_PCON_DSC_RC_BUF_BLK_16KB :
+rc_buf_blk_size = 16;
+break;
+case DP_PCON_DSC_RC_BUF_BLK_64KB :
+rc_buf_blk_size = 64;
+break;
+default :
+rc_buf_blk_size = 0;
+}
It would be good if you create sub-functions for each of these aspects to make
it more readable.
Agreed. As mentioned above will have drm_helper functions for these.
+if (drm_dp_dpcd_readb(&intel_dp->aux, DP_PCON_DSC_RC_BUF_SIZE,
&buf) < 0) {
+drm_err(&i915->drm, "Failed to read
DP_PCON_DSC_RC_BUF_SIZE\n");
+return;
+}
+/* storing rc_buf_size in bytes */
+pcon_dsc->rc_buf_size = (buf + 1) * rc_buf_blk_size * 1024;
+
+if (drm_dp_dpcd_readb(&intel_dp->aux, DP_PCON_DSC_SLICE_CAP_2,
&buf) < 0) {
+drm_err(&i915->drm, "Failed to read
DP_PCON_DSC_SLICE_CAP_2\n");
+return;
+}
+if (buf & DP_PCON_DSC_24_PER_DSC_ENC)
+ max_slices = 24;
+else if (buf & DP_PCON_DSC_20_PER_DSC_ENC)
+max_slices = 20;
+else if
Re: [RFC 11/13] drm/i915: Read DSC capabilities of the HDMI2.1 PCON encoder
On 10/19/2020 5:04 AM, Shankar, Uma wrote:
-Original Message-
From: Shankar, Uma
Sent: Monday, October 19, 2020 5:02 AM
To: Nautiyal, Ankit K ; intel-
g...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org; Kulkarni, Vandita
; ville.syrj...@linux.intel.com; Sharma, Swati2
Subject: RE: [RFC 11/13] drm/i915: Read DSC capabilities of the HDMI2.1 PCON
encoder
Also it would be good to move to DRM Core.
Agreed, as mentioned in earlier patch, will move the appropriate code as
drm_helper functions.
Regards,
Ankit
-Original Message-
From: Nautiyal, Ankit K
Sent: Thursday, October 15, 2020 4:23 PM
To: intel-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org; Shankar, Uma
; Kulkarni, Vandita
; ville.syrj...@linux.intel.com; Sharma,
Swati2
Subject: [RFC 11/13] drm/i915: Read DSC capabilities of the HDMI2.1
PCON encoder
This patch adds a helper function to read the DSC capabilities of the
HDMI2.1 PCon encoder. It also adds a new structure to store these
caps, which can then be used to get the PPS parameters for
PCON-HDMI2.1 sink pair. Which inturn will be used to take a call to
override the existing PPS-metadata, by either writing the entire new
PPS metadata, or by writing only the PPS override parameters.
Signed-off-by: Ankit Nautiyal
---
.../drm/i915/display/intel_display_types.h| 16 ++
drivers/gpu/drm/i915/display/intel_dp.c | 178 ++
2 files changed, 194 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 6c69922313d6..23282695a47f 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1292,6 +1292,21 @@ struct intel_dp_pcon_frl {
int trained_rate_gbps;
};
+struct intel_dp_pcon_dsc {
+ bool enc_support;
+ bool pps_override_support;
+ bool blk_prediction_support;
+ u8 version_major;
+ u8 version_minor;
+ u8 color_fmt_mask;
+ u8 color_depth_mask;
+ u8 max_slices;;
+ u8 max_slice_width;
+ u8 line_buf_bit_depth;
+ u8 bpp_precision_incr;
+ int rc_buf_size;
+};
+
struct intel_dp {
i915_reg_t output_reg;
u32 DP;
@@ -1415,6 +1430,7 @@ struct intel_dp {
bool hobl_active;
struct intel_dp_pcon_frl frl;
+ struct intel_dp_pcon_dsc pcon_dsc;
};
enum lspcon_vendor {
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index e6c4cb844e37..b4f8abaea607 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -3882,6 +3882,182 @@ cpt_set_link_train(struct intel_dp *intel_dp,
intel_de_posting_read(dev_priv, intel_dp->output_reg); }
+void intel_dp_get_pcon_dsc_cap(struct intel_dp *intel_dp) {
+ u8 buf;
+ u8 rc_buf_blk_size;
+ u8 max_slices = 0;
+
+ struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+ struct intel_dp_pcon_dsc *pcon_dsc = &intel_dp->pcon_dsc;
+
+ if (drm_dp_dpcd_readb(&intel_dp->aux, DP_PCON_DSC_ENCODER, &buf)
< 0) {
+ drm_err(&i915->drm, "Failed to read
DP_PCON_DSC_ENCODER\n");
+ return;
+ }
+ pcon_dsc->enc_support = buf & DP_PCON_DSC_ENCODER_SUPPORTED;
+ pcon_dsc->pps_override_support = buf &
DP_PCON_DSC_PPS_ENC_OVERRIDE;
+
+ if (drm_dp_dpcd_readb(&intel_dp->aux, DP_PCON_DSC_VERSION, &buf)
< 0) {
+ drm_err(&i915->drm, "Failed to read
DP_PCON_DSC_VERSION\n");
+ return;
If we fail here or in any of the subsequent calls below shouldn't we reset the
dsc
params saying DSC not supported. Else we may return with ex.
pcon_dsc->enc_support = buf & DP_PCON_DSC_ENCODER_SUPPORTED which
would ideally not be right.
+ }
+ pcon_dsc->version_major = (buf & DP_PCON_DSC_MAJOR_MASK) >>
+ DP_PCON_DSC_MAJOR_SHIFT;
+ pcon_dsc->version_minor = (buf & DP_PCON_DSC_MINOR_MASK) >>
+ DP_PCON_DSC_MINOR_SHIFT;
+
+ if (drm_dp_dpcd_readb(&intel_dp->aux,
DP_PCON_DSC_RC_BUF_BLK_INFO, &buf) < 0) {
+ drm_err(&i915->drm, "Failed to read
DP_PCON_DSC_RC_BUF_BLK_INFO\n");
+ return;
+ }
+
+ switch (buf & DP_PCON_DSC_RC_BUF_BLK_SIZE) {
+ case DP_PCON_DSC_RC_BUF_BLK_1KB :
+ rc_buf_blk_size = 1;
+ break;
+ case DP_PCON_DSC_RC_BUF_BLK_4KB :
+ rc_buf_blk_size = 4;
+ break;
+ case DP_PCON_DSC_RC_BUF_BLK_16KB :
+ rc_buf_blk_size = 16;
+ break;
+ case DP_PCON_DSC_RC_BUF_BLK_64KB :
+ rc_buf_blk_size = 64;
+ break;
+ default :
+ rc_buf_blk_size = 0;
+ }
It would be good if you create sub-functions for each of these aspects to make
it
more readable.
+ if (drm_dp_dpcd_readb(&intel_dp->aux,
Re: [PATCH] drm/ast: Support 1600x900 with 108MHz PCLK
Hi KuoHsiang
On Fri, Oct 30, 2020 at 03:42:12PM +0800, KuoHsiang Chou wrote:
> [New] Create the setting for 1600x900 @60Hz refresh rate
> by 108MHz pixel-clock.
>
> Signed-off-by: KuoHsiang Chou
Thomas Zimmermann is listed as reviewer
in MAINTAINERS, so included him in the list of receiver.
get_maintainer.pl should have told you that.
Sam
> ---
> drivers/gpu/drm/ast/ast_tables.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/ast/ast_tables.h
> b/drivers/gpu/drm/ast/ast_tables.h
> index d665dd5af5dd..8414e543f260 100644
> --- a/drivers/gpu/drm/ast/ast_tables.h
> +++ b/drivers/gpu/drm/ast/ast_tables.h
> @@ -282,6 +282,8 @@ static const struct ast_vbios_enhtable res_1360x768[] = {
> };
>
> static const struct ast_vbios_enhtable res_1600x900[] = {
> + {1800, 1600, 24, 80,1000, 900, 1, 3, VCLK108, /* 60Hz */
> + (SyncPP | Charx8Dot | LineCompareOff | WideScreenMode | NewModeInfo),
> 60, 3, 0x3A },
> {1760, 1600, 48, 32, 926, 900, 3, 5, VCLK97_75, /* 60Hz CVT RB
> */
>(SyncNP | Charx8Dot | LineCompareOff | WideScreenMode | NewModeInfo |
> AST2500PreCatchCRT), 60, 1, 0x3A },
> --
> 2.18.4
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/panel: st7703: use DEFINE_DEBUGFS_ATTRIBUTE with debugfs_create_file_unsafe()
Hi Deepak
On Fri, Oct 30, 2020 at 09:01:50AM +0530, Deepak R Varma wrote:
> Using DEFINE_DEBUGFS_ATTRIBUTE macro with debugfs_create_file_unsafe()
> function in place of the debugfs_create_file() function will make the
> file operation struct "reset" aware of the file's lifetime. Additional
> details here: https://lists.archive.carbon60.com/linux/kernel/2369498
>
> Issue reported by Coccinelle script:
> scripts/coccinelle/api/debugfs/debugfs_simple_attr.cocci
>
> Signed-off-by: Deepak R Varma
Based on discussions triggered by other patches doing the same
replacement I will ignore this patch for now.
If the conclusions are that this is indeed the right thing to do then
please let us know so we can apply this patch.
Thanks,
Sam
> ---
> Please Note: This is a Outreachy project task patch.
>
> drivers/gpu/drm/panel/panel-sitronix-st7703.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> index c22e7c49e077..89b71d4f810d 100644
> --- a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> +++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> @@ -502,15 +502,14 @@ static int allpixelson_set(void *data, u64 val)
> return 0;
> }
>
> -DEFINE_SIMPLE_ATTRIBUTE(allpixelson_fops, NULL,
> - allpixelson_set, "%llu\n");
> +DEFINE_DEBUGFS_ATTRIBUTE(allpixelson_fops, NULL, allpixelson_set, "%llu\n");
>
> static void st7703_debugfs_init(struct st7703 *ctx)
> {
> ctx->debugfs = debugfs_create_dir(DRV_NAME, NULL);
>
> - debugfs_create_file("allpixelson", 0600, ctx->debugfs, ctx,
> - &allpixelson_fops);
> + debugfs_create_file_unsafe("allpixelson", 0600, ctx->debugfs, ctx,
> +&allpixelson_fops);
> }
>
> static void st7703_debugfs_remove(struct st7703 *ctx)
> --
> 2.25.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] fbdev/sh_mobile: Drop unused include
Hi Linus, On Fri, Oct 30, 2020 at 01:28:50AM +0100, Linus Walleij wrote: > The driver includes but doesn't use any symbols > from this file. > > Cc: Magnus Damm > Cc: Geert Uytterhoeven > Cc: linux-renesas-...@vger.kernel.org > Signed-off-by: Linus Walleij Thanks, I went ahead and applied this to drm-misc-next. And then I remembered you have commit right too :-( Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] video/fbdev/core: Mark debug-only variable as __maybe_unused
Hi Thomas. On Wed, Oct 21, 2020 at 02:15:12PM +0200, Thomas Zimmermann wrote: > Compiling fbcon.c gives > > ../drivers/video/fbdev/core/fbcon.c: In function 'fbcon_exit': > ../drivers/video/fbdev/core/fbcon.c:3358:7: warning: variable 'pending' set > but not used [-Wunused-but-set-variable] > 3358 | int pending = 0; > | ^~~ > > The variable pending is only used for fbcon debugging. It's unused > otherwise. Mark it accordingly. > > Signed-off-by: Thomas Zimmermann A better fix would be to replace the few uses of DPRINTK() with pr_dbg(). pr_info() is alread in use. ofc, the next step would be to replace all prink() with their pr_ counterparts. Peilin, maybe this is one for your nice cleanups in fbcon? Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drivers/video: Fix -Wstringop-truncation in hdmi.c
On Wed, Oct 21, 2020 at 02:12:41PM +0200, Thomas Zimmermann wrote:
> Trying to copy into the string fields with strncpy() gives a warning from
> gcc. Both fields are part of a packed HDMI header and do not require a
> terminating \0 character.
>
> ../drivers/video/hdmi.c: In function 'hdmi_spd_infoframe_init':
> ../drivers/video/hdmi.c:230:2: warning: 'strncpy' specified bound 8 equals
> destination size [-Wstringop-truncation]
> 230 | strncpy(frame->vendor, vendor, sizeof(frame->vendor));
> | ^
> ../drivers/video/hdmi.c:231:2: warning: 'strncpy' specified bound 16 equals
> destination size [-Wstringop-truncation]
> 231 | strncpy(frame->product, product, sizeof(frame->product));
> | ^~~~
>
> Just use memcpy() instead.
>
> Signed-off-by: Thomas Zimmermann
I assume vendor is guaranteed to be 0-termindated.
Reviewed-by: Sam Ravnborg
> ---
> drivers/video/hdmi.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
> index b7a1d6fae90d..1e4cb63d0d11 100644
> --- a/drivers/video/hdmi.c
> +++ b/drivers/video/hdmi.c
> @@ -221,14 +221,18 @@ EXPORT_SYMBOL(hdmi_avi_infoframe_pack);
> int hdmi_spd_infoframe_init(struct hdmi_spd_infoframe *frame,
> const char *vendor, const char *product)
> {
> + size_t len;
> +
> memset(frame, 0, sizeof(*frame));
>
> frame->type = HDMI_INFOFRAME_TYPE_SPD;
> frame->version = 1;
> frame->length = HDMI_SPD_INFOFRAME_SIZE;
>
> - strncpy(frame->vendor, vendor, sizeof(frame->vendor));
> - strncpy(frame->product, product, sizeof(frame->product));
> + len = strlen(vendor);
> + memcpy(frame->vendor, vendor, min(len, sizeof(frame->vendor)));
> + len = strlen(product);
> + memcpy(frame->product, product, min(len, sizeof(frame->product)));
>
> return 0;
> }
> --
> 2.28.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/5] drm/amdgpu: Paper over the drm_driver mangling for virt
On Sat, Oct 31, 2020 at 6:09 AM Luben Tuikov wrote:
>
> On 2020-10-30 08:04, Daniel Vetter wrote:
> > On Fri, Oct 30, 2020 at 11:41 AM Liu, Monk wrote:
> >>
> >> [AMD Official Use Only - Internal Distribution Only]
> >>
> >> What's the purpose of the patch sets
> >>
> >> e.g.: what bug can those 5 patches fix or what feature provided
> >>
> >> for this particular one (3/5) I didn't see how it helpful, could you give
> >> a background ?
> >
> > It's good to make function tables const, so that they can be write
> > protected. More resilience against exploits and all that. This patch
> > here is needed to be able to make drm_device->driver const so that all
> > other drivers can make their drm_driver structure const. Would be good
> > to fully fix up amdgpu like in the comment, but I'm not going that in
> > this series here.
> > -Daniel
>
> Hi Daniel,
>
> I feel that that's a good change.
>
> But if you can clarify this for me... Is this leading
> towards a single instance of a struct drm_driver per
> low-level driver, i.e. amdgpu?
>
> And as such, being able to be defined as const?
>
> So that we have many GPU devices driven by one
> low-level driver (amdgpu_drv), represented by one
> const drm_driver (and thus const)?
>
> Which would imply that if varied devices can be handled
> by a single low-level driver, whose struct drm_driver
> settings cannot be shared among subset of devices (say
> very old and new), then the low-level driver
> would have to create more than one "const" struct drm_driver?
This is already the case, minus the const. Which is why it's
problemantic if you change that shared drm_driver instance at runtime
from a specific driver, since you always change it for all instances.
-Daniel
>
> Regards,
> Luben
>
> >
> >>
> >> thanks
> >> _
> >> Monk Liu|GPU Virtualization Team |AMD
> >>
> >>
> >> -Original Message-
> >> From: Daniel Vetter
> >> Sent: Friday, October 30, 2020 6:11 PM
> >> To: DRI Development
> >> Cc: Intel Graphics Development ; Daniel
> >> Vetter ; Deucher, Alexander
> >> ; Koenig, Christian ;
> >> Quan, Evan ; Kuehling, Felix ;
> >> Zhang, Hawking ; Grodzovsky, Andrey
> >> ; Tuikov, Luben ; Thomas
> >> Zimmermann ; Liu, Monk ; Yintian
> >> Tao ; Li, Dennis ; Liu, Shaoyun
> >> ; Zhang, Bokun ; Yang, Stanley
> >> ; Sheng, Wenhui ; Gong, Curry
> >> ; Daniel Vetter
> >> Subject: [PATCH 3/5] drm/amdgpu: Paper over the drm_driver mangling for
> >> virt
> >>
> >> Prep work to make drm_device->driver const.
> >>
> >> Signed-off-by: Daniel Vetter
> >> Cc: Alex Deucher
> >> Cc: "Christian König"
> >> Cc: Evan Quan
> >> Cc: Felix Kuehling
> >> Cc: Hawking Zhang
> >> Cc: Andrey Grodzovsky
> >> Cc: Luben Tuikov
> >> Cc: Thomas Zimmermann
> >> Cc: Monk Liu
> >> Cc: Yintian Tao
> >> Cc: Dennis Li
> >> Cc: shaoyunl
> >> Cc: Bokun Zhang
> >> Cc: "Stanley.Yang"
> >> Cc: Wenhui Sheng
> >> Cc: chen gong
> >> Signed-off-by: Daniel Vetter
> >> ---
> >> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 8
> >> drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | 12 +++-
> >> 2 files changed, 15 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> >> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> >> index 024c3b70b1aa..3d337f13ae4e 100644
> >> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> >> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> >> @@ -1093,7 +1093,7 @@ static const struct pci_device_id pciidlist[] = {
> >>
> >> MODULE_DEVICE_TABLE(pci, pciidlist);
> >>
> >> -static struct drm_driver kms_driver;
> >> +struct drm_driver amdgpu_kms_driver;
> >>
> >> static int amdgpu_pci_probe(struct pci_dev *pdev,
> >> const struct pci_device_id *ent) @@ -1164,7 +1164,7 @@ static int
> >> amdgpu_pci_probe(struct pci_dev *pdev,
> >> if (ret)
> >> return ret;
> >>
> >> -adev = devm_drm_dev_alloc(&pdev->dev, &kms_driver, typeof(*adev), ddev);
> >> +adev = devm_drm_dev_alloc(&pdev->dev, &amdgpu_kms_driver,
> >> +typeof(*adev), ddev);
> >> if (IS_ERR(adev))
> >> return PTR_ERR(adev);
> >>
> >> @@ -1508,7 +1508,7 @@ int amdgpu_file_to_fpriv(struct file *filp, struct
> >> amdgpu_fpriv **fpriv)
> >> return 0;
> >> }
> >>
> >> -static struct drm_driver kms_driver = {
> >> +struct drm_driver amdgpu_kms_driver = {
> >> .driver_features =
> >> DRIVER_ATOMIC |
> >> DRIVER_GEM |
> >> @@ -1571,7 +1571,7 @@ static int __init amdgpu_init(void)
> >> goto error_fence;
> >>
> >> DRM_INFO("amdgpu kernel modesetting enabled.\n");
> >> -kms_driver.num_ioctls = amdgpu_max_kms_ioctl;
> >> +amdgpu_kms_driver.num_ioctls = amdgpu_max_kms_ioctl;
> >> amdgpu_register_atpx_handler();
> >>
> >> /* Ignore KFD init failures. Normal when CONFIG_HSA_AMD is not set. */
> >> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> >> b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> >> index d0aea5e39531..dde4c449c284 100644
> >> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> >> +++ b/drivers/
Re: [PATCH 3/5] drm/amdgpu: Paper over the drm_driver mangling for virt
On Sat, Oct 31, 2020 at 2:57 PM Daniel Vetter wrote:
>
> On Fri, Oct 30, 2020 at 7:47 PM Alex Deucher wrote:
> >
> > On Fri, Oct 30, 2020 at 6:11 AM Daniel Vetter
> > wrote:
> > >
> > > Prep work to make drm_device->driver const.
> > >
> > > Signed-off-by: Daniel Vetter
> > > Cc: Alex Deucher
> > > Cc: "Christian König"
> > > Cc: Evan Quan
> > > Cc: Felix Kuehling
> > > Cc: Hawking Zhang
> > > Cc: Andrey Grodzovsky
> > > Cc: Luben Tuikov
> > > Cc: Thomas Zimmermann
> > > Cc: Monk Liu
> > > Cc: Yintian Tao
> > > Cc: Dennis Li
> > > Cc: shaoyunl
> > > Cc: Bokun Zhang
> > > Cc: "Stanley.Yang"
> > > Cc: Wenhui Sheng
> > > Cc: chen gong
> > > Signed-off-by: Daniel Vetter
> > > ---
> > > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 8
> > > drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | 12 +++-
> > > 2 files changed, 15 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> > > index 024c3b70b1aa..3d337f13ae4e 100644
> > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> > > @@ -1093,7 +1093,7 @@ static const struct pci_device_id pciidlist[] = {
> > >
> > > MODULE_DEVICE_TABLE(pci, pciidlist);
> > >
> > > -static struct drm_driver kms_driver;
> > > +struct drm_driver amdgpu_kms_driver;
> > >
> > > static int amdgpu_pci_probe(struct pci_dev *pdev,
> > > const struct pci_device_id *ent)
> > > @@ -1164,7 +1164,7 @@ static int amdgpu_pci_probe(struct pci_dev *pdev,
> > > if (ret)
> > > return ret;
> > >
> > > - adev = devm_drm_dev_alloc(&pdev->dev, &kms_driver, typeof(*adev),
> > > ddev);
> > > + adev = devm_drm_dev_alloc(&pdev->dev, &amdgpu_kms_driver,
> > > typeof(*adev), ddev);
> > > if (IS_ERR(adev))
> > > return PTR_ERR(adev);
> > >
> > > @@ -1508,7 +1508,7 @@ int amdgpu_file_to_fpriv(struct file *filp, struct
> > > amdgpu_fpriv **fpriv)
> > > return 0;
> > > }
> > >
> > > -static struct drm_driver kms_driver = {
> > > +struct drm_driver amdgpu_kms_driver = {
> > > .driver_features =
> > > DRIVER_ATOMIC |
> > > DRIVER_GEM |
> > > @@ -1571,7 +1571,7 @@ static int __init amdgpu_init(void)
> > > goto error_fence;
> > >
> > > DRM_INFO("amdgpu kernel modesetting enabled.\n");
> > > - kms_driver.num_ioctls = amdgpu_max_kms_ioctl;
> > > + amdgpu_kms_driver.num_ioctls = amdgpu_max_kms_ioctl;
> > > amdgpu_register_atpx_handler();
> > >
> > > /* Ignore KFD init failures. Normal when CONFIG_HSA_AMD is not
> > > set. */
> > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> > > index d0aea5e39531..dde4c449c284 100644
> > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> > > @@ -45,13 +45,23 @@ bool amdgpu_virt_mmio_blocked(struct amdgpu_device
> > > *adev)
> > > return RREG32_NO_KIQ(0xc040) == 0x;
> > > }
> > >
> > > +extern struct drm_driver amdgpu_kms_driver;
> > > +
> > > void amdgpu_virt_init_setting(struct amdgpu_device *adev)
> > > {
> > > /* enable virtual display */
> > > if (adev->mode_info.num_crtc == 0)
> > > adev->mode_info.num_crtc = 1;
> > > adev->enable_virtual_display = true;
> > > - adev_to_drm(adev)->driver->driver_features &= ~DRIVER_ATOMIC;
> > > +
> > > + /*
> > > +* FIXME: Either make virt support atomic or make sure you have
> > > two
> > > +* drm_driver structs, these kind of tricks are only ok when
> > > there's
> > > +* guaranteed only a single device per system. This should also
> > > be done
> > > +* before struct drm_device is initialized.
> > > +*/
> > > + amdgpu_kms_driver.driver_features &= ~DRIVER_ATOMIC;
> >
> > There is additional DRIVER_ATOMIC in amdgpu_pci_probe() for older
> > chips without atomic support.
>
> That would need to be fixed for making the amdgpu drm_driver
> structures constant, but that's not what I'm doing here. I'm only
> removing the usage of the drm_device->driver pointer, to allow that to
> become constant. Untangling the flow to make the amdgpu_kms_driver
> const looked a bit more involved than just a simple patch.
On second look, this changes the drm_device->driver_features flag,
which was added to avoid having to change the drm_driver one. So
that's actually all ok (and just the virt code here is broken). But
amdgpu also updates num_ioctl and other stuff, and that's a fairly
invasive patch.
I'm also not sure whether this code here can just be switched over
from drm_driver->driver_features to drm_device->driver_features. So
given all this, ok as-is and you guys figure out how to patch this
properly, or want me to change something in this patch?
Cheers, Daniel
>
> > Alex
> >
Re: [PATCH] video/fbdev/core: Mark debug-only variable as __maybe_unused
Hi Sam, On Sun, Nov 01, 2020 at 10:47:18AM +0100, Sam Ravnborg wrote: > Hi Thomas. > > On Wed, Oct 21, 2020 at 02:15:12PM +0200, Thomas Zimmermann wrote: > > Compiling fbcon.c gives > > > > ../drivers/video/fbdev/core/fbcon.c: In function 'fbcon_exit': > > ../drivers/video/fbdev/core/fbcon.c:3358:7: warning: variable 'pending' set > > but not used [-Wunused-but-set-variable] > > 3358 | int pending = 0; > > | ^~~ > > > > The variable pending is only used for fbcon debugging. It's unused > > otherwise. Mark it accordingly. > > > > Signed-off-by: Thomas Zimmermann > > A better fix would be to replace the few uses of DPRINTK() with > pr_dbg(). pr_info() is alread in use. > > ofc, the next step would be to replace all prink() with their pr_ > counterparts. > > Peilin, maybe this is one for your nice cleanups in fbcon? Sure, I will send a patch replacing all printk() except DPRINTK(). Thank you for the suggestion! Peilin ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 02/13] drm/edid: Parse MAX_FRL field from HFVSDB block
From: Swati Sharma
This patch parses MAX_FRL field to get the MAX rate in Gbps that
the HDMI 2.1 panel can support in FRL mode. Source need this
field to determine the optimal rate between the source and sink
during FRL training.
v2: Fixed minor bugs, and removed extra wrapper function (Uma Shankar)
Signed-off-by: Sharma, Swati2
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/drm_edid.c | 44 +
include/drm/drm_connector.h | 6 +
2 files changed, 50 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 631125b46e04..26797868ea5b 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4849,6 +4849,41 @@ static void drm_parse_vcdb(struct drm_connector
*connector, const u8 *db)
info->rgb_quant_range_selectable = true;
}
+static
+void drm_get_max_frl_rate(int max_frl_rate, u8 *max_lanes, u8
*max_rate_per_lane)
+{
+ switch (max_frl_rate) {
+ case 1:
+ *max_lanes = 3;
+ *max_rate_per_lane = 3;
+ break;
+ case 2:
+ *max_lanes = 3;
+ *max_rate_per_lane = 6;
+ break;
+ case 3:
+ *max_lanes = 4;
+ *max_rate_per_lane = 6;
+ break;
+ case 4:
+ *max_lanes = 4;
+ *max_rate_per_lane = 8;
+ break;
+ case 5:
+ *max_lanes = 4;
+ *max_rate_per_lane = 10;
+ break;
+ case 6:
+ *max_lanes = 4;
+ *max_rate_per_lane = 12;
+ break;
+ case 0:
+ default:
+ *max_lanes = 0;
+ *max_rate_per_lane = 0;
+ }
+}
+
static void drm_parse_ycbcr420_deep_color_info(struct drm_connector *connector,
const u8 *db)
{
@@ -4902,6 +4937,15 @@ static void drm_parse_hdmi_forum_vsdb(struct
drm_connector *connector,
}
}
+ if (hf_vsdb[7]) {
+ u8 max_frl_rate;
+
+ DRM_DEBUG_KMS("hdmi_21 sink detected. parsing edid\n");
+ max_frl_rate = (hf_vsdb[7] & DRM_EDID_MAX_FRL_RATE_MASK) >> 4;
+ drm_get_max_frl_rate(max_frl_rate, &hdmi->max_lanes,
+ &hdmi->max_frl_rate_per_lane);
+ }
+
drm_parse_ycbcr420_deep_color_info(connector, hf_vsdb);
}
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 928136556174..f351bf10c076 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -207,6 +207,12 @@ struct drm_hdmi_info {
/** @y420_dc_modes: bitmap of deep color support index */
u8 y420_dc_modes;
+
+ /** @max_frl_rate_per_lane: support fixed rate link */
+ u8 max_frl_rate_per_lane;
+
+ /** @max_lanes: supported by sink */
+ u8 max_lanes;
};
/**
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 01/13] drm/edid: Add additional HFVSDB fields for HDMI2.1
From: Swati Sharma
The HDMI2.1 extends HFVSDB (HDMI Forum Vendor Specific
Data block) to have fields related to newly defined methods of FRL
(Fixed Rate Link) levels, number of lanes supported, DSC Color bit
depth, VRR min/max, FVA (Fast Vactive), ALLM etc.
This patch adds the new HFVSDB fields that are required for
HDMI2.1.
v2: Minor fixes + consistent naming for DPCD register masks
(Uma Shankar)
Signed-off-by: Sharma, Swati2
Signed-off-by: Ankit Nautiyal
---
include/drm/drm_edid.h | 30 ++
1 file changed, 30 insertions(+)
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index b27a0e2169c8..a6ca992e105d 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -229,6 +229,36 @@ struct detailed_timing {
DRM_EDID_YCBCR420_DC_36 | \
DRM_EDID_YCBCR420_DC_30)
+/* HDMI 2.1 additional fields */
+#define DRM_EDID_MAX_FRL_RATE_MASK 0xf0
+#define DRM_EDID_FAPA_START_LOCATION (1 << 0)
+#define DRM_EDID_ALLM (1 << 1)
+#define DRM_EDID_FVA (1 << 2)
+
+/* Deep Color specific */
+#define DRM_EDID_DC_30BIT_420 (1 << 0)
+#define DRM_EDID_DC_36BIT_420 (1 << 1)
+#define DRM_EDID_DC_48BIT_420 (1 << 2)
+
+/* VRR specific */
+#define DRM_EDID_CNMVRR(1 << 3)
+#define DRM_EDID_CINEMA_VRR(1 << 4)
+#define DRM_EDID_MDELTA(1 << 5)
+#define DRM_EDID_VRR_MAX_UPPER_MASK0xc0
+#define DRM_EDID_VRR_MAX_LOWER_MASK0xff
+#define DRM_EDID_VRR_MIN_MASK 0x3f
+
+/* DSC specific */
+#define DRM_EDID_DSC_10BPC (1 << 0)
+#define DRM_EDID_DSC_12BPC (1 << 1)
+#define DRM_EDID_DSC_16BPC (1 << 2)
+#define DRM_EDID_DSC_ALL_BPP (1 << 3)
+#define DRM_EDID_DSC_NATIVE_420(1 << 6)
+#define DRM_EDID_DSC_1P2 (1 << 7)
+#define DRM_EDID_DSC_MAX_FRL_RATE_MASK 0xf0
+#define DRM_EDID_DSC_MAX_SLICES0xf
+#define DRM_EDID_DSC_TOTAL_CHUNK_KBYTES0x3f
+
/* ELD Header Block */
#define DRM_ELD_HEADER_BLOCK_SIZE 4
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 03/13] drm/edid: Parse DSC1.2 cap fields from HFVSDB block
This patch parses HFVSDB fields for DSC1.2 capabilities of an
HDMI2.1 sink. These fields are required by a source to understand the
DSC capability of the sink, to set appropriate PPS parameters,
before transmitting compressed data stream.
v2: Addressed following issues as suggested by Uma Shankar:
-Added a new struct for hdmi dsc cap
-Fixed bugs in macros usage.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/drm_edid.c | 59 +
include/drm/drm_connector.h | 43 +++
2 files changed, 102 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 26797868ea5b..feaf2d7659a4 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4939,11 +4939,70 @@ static void drm_parse_hdmi_forum_vsdb(struct
drm_connector *connector,
if (hf_vsdb[7]) {
u8 max_frl_rate;
+ u8 dsc_max_frl_rate;
+ u8 dsc_max_slices;
+ struct drm_hdmi_dsc_cap *hdmi_dsc = &hdmi->dsc_cap;
DRM_DEBUG_KMS("hdmi_21 sink detected. parsing edid\n");
max_frl_rate = (hf_vsdb[7] & DRM_EDID_MAX_FRL_RATE_MASK) >> 4;
drm_get_max_frl_rate(max_frl_rate, &hdmi->max_lanes,
&hdmi->max_frl_rate_per_lane);
+ hdmi_dsc->v_1p2 = hf_vsdb[11] & DRM_EDID_DSC_1P2;
+
+ if (hdmi_dsc->v_1p2) {
+ hdmi_dsc->native_420 = hf_vsdb[11] &
DRM_EDID_DSC_NATIVE_420;
+ hdmi_dsc->all_bpp = hf_vsdb[11] & DRM_EDID_DSC_ALL_BPP;
+
+ if (hf_vsdb[11] & DRM_EDID_DSC_16BPC)
+ hdmi_dsc->bpc_supported = 16;
+ else if (hf_vsdb[11] & DRM_EDID_DSC_12BPC)
+ hdmi_dsc->bpc_supported = 12;
+ else if (hf_vsdb[11] & DRM_EDID_DSC_10BPC)
+ hdmi_dsc->bpc_supported = 10;
+ else
+ hdmi_dsc->bpc_supported = 0;
+
+ dsc_max_frl_rate = (hf_vsdb[12] &
DRM_EDID_DSC_MAX_FRL_RATE_MASK) >> 4;
+ drm_get_max_frl_rate(dsc_max_frl_rate,
&hdmi_dsc->max_lanes,
+ &hdmi_dsc->max_frl_rate_per_lane);
+ hdmi_dsc->total_chunk_kbytes = hf_vsdb[13] &
DRM_EDID_DSC_TOTAL_CHUNK_KBYTES;
+
+ dsc_max_slices = hf_vsdb[12] & DRM_EDID_DSC_MAX_SLICES;
+ switch (dsc_max_slices) {
+ case 1:
+ hdmi_dsc->max_slices = 1;
+ hdmi_dsc->clk_per_slice = 340;
+ break;
+ case 2:
+ hdmi_dsc->max_slices = 2;
+ hdmi_dsc->clk_per_slice = 340;
+ break;
+ case 3:
+ hdmi_dsc->max_slices = 4;
+ hdmi_dsc->clk_per_slice = 340;
+ break;
+ case 4:
+ hdmi_dsc->max_slices = 8;
+ hdmi_dsc->clk_per_slice = 340;
+ break;
+ case 5:
+ hdmi_dsc->max_slices = 8;
+ hdmi_dsc->clk_per_slice = 400;
+ break;
+ case 6:
+ hdmi_dsc->max_slices = 12;
+ hdmi_dsc->clk_per_slice = 400;
+ break;
+ case 7:
+ hdmi_dsc->max_slices = 16;
+ hdmi_dsc->clk_per_slice = 400;
+ break;
+ case 0:
+ default:
+ hdmi_dsc->max_slices = 0;
+ hdmi_dsc->clk_per_slice = 0;
+ }
+ }
}
drm_parse_ycbcr420_deep_color_info(connector, hf_vsdb);
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index f351bf10c076..06d24e36268e 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -175,6 +175,46 @@ struct drm_scdc {
struct drm_scrambling scrambling;
};
+/**
+ * struct drm_hdmi_dsc_cap - DSC capabilities of HDMI sink
+ *
+ * Describes the DSC support provided by HDMI 2.1 sink.
+ * The information is fetched fom additional HFVSDB blocks defined
+ * for HDMI 2.1.
+ */
+struct drm_hdmi_dsc_cap {
+ /** @v_1p2: flag for dsc1.2 version support by sink */
+ bool v_1p2;
+
+ /** @native_420: Does sink support DSC with 4:2:0 compression */
+ bool native_420;
+
+ /**
+* @all_bpp: Does sink support all bpp with 4:4:4: or 4:2:2
+
[PATCH v2 00/13] Add support for DP-HDMI2.1 PCON
This patch series attempts to add support for a DP-HDMI2.1 Protocol Convertor. The VESA spec for the HDMI2.1 PCON are proposed in Errata E5 to DisplayPort_v2.0: https://vesa.org/join-vesamemberships/member-downloads/?action=stamp&fileid=42299 The details are mentioned in DP to HDMI2.1 PCON Enum/Config improvement slide decks: https://groups.vesa.org/wg/DP/document/folder/1316 This series starts with adding support for FRL (Fixed Rate Link) Training between the PCON and HDMI2.1 sink. As per HDMI2.1 specification, a new data-channel or lane is added in FRL mode, by repurposing the TMDS clock Channel. Through FRL, higher bit-rate can be supported, ie. up to 12 Gbps/lane (48 Gbps over 4 lanes). With these patches, the HDMI2.1 PCON can be configured to achieve FRL training based on the maximum FRL rate supported by the panel, source and the PCON. The approach is to add the support for FRL training between PCON and HDMI2.1 sink and gradually add other blocks for supporting higher resolutions and other HDMI2.1 features, that can be supported by pcon for the sources that do not natively support HDMI2.1. This is done before the DP Link training between the source and PCON is started. In case of FRL training is not achieved, the PCON will work in the regular TMDS mode, without HDMI2.1 feature support. Any interruption in FRL training between the PCON and HDMI2.1 sink is notified through IRQ_HPD. On receiving the IRQ_HPD the concerned DPCD registers are read and FRL training is re-attempted. Currently, we have tested the FRL training and are able to enable 4K display with TGL Platform + Realtek PCON RTD2173 with HDMI2.1 supporting panel. v2: Addressed review comments and re-organized patches as suggested in comments on RFC patches. Ankit Nautiyal (9): drm/edid: Parse DSC1.2 cap fields from HFVSDB block drm/dp_helper: Add Helpers for FRL Link Training support for DP-HDMI2.1 PCON drm/dp_helper: Add support for Configuring DSC for HDMI2.1 Pcon drm/i915: Capture max frl rate for PCON in dfp cap structure drm/i915: Add support for starting FRL training for HDMI2.1 via PCON drm/i915: Check for FRL training before DP Link training drm/i915: Read DSC capabilities of the HDMI2.1 PCON encoder drm/i915: Add helper functions for calculating DSC parameters for HDMI2.1 drm/i915: Configure PCON for DSC1.1 to DSC1.2 encoding Swati Sharma (4): drm/edid: Add additional HFVSDB fields for HDMI2.1 drm/edid: Parse MAX_FRL field from HFVSDB block drm/dp_helper: Add support for link failure detection drm/i915: Add support for enabling link status and recovery drivers/gpu/drm/drm_dp_helper.c | 538 ++ drivers/gpu/drm/drm_edid.c| 103 drivers/gpu/drm/i915/display/intel_ddi.c | 3 + .../drm/i915/display/intel_display_types.h| 9 + drivers/gpu/drm/i915/display/intel_dp.c | 429 +- drivers/gpu/drm/i915/display/intel_dp.h | 4 + drivers/gpu/drm/i915/display/intel_hdmi.c | 181 ++ drivers/gpu/drm/i915/display/intel_hdmi.h | 7 + include/drm/drm_connector.h | 49 ++ include/drm/drm_dp_helper.h | 212 +++ include/drm/drm_edid.h| 30 + 11 files changed, 1560 insertions(+), 5 deletions(-) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 13/13] drm/i915: Configure PCON for DSC1.1 to DSC1.2 encoding
When a source supporting DSC1.1 is connected to DSC1.2 HDMI2.1 sink
via DP HDMI2.1 PCON, the PCON can be configured to decode the
DSC1.1 compressed stream and encode to DSC1.2. It then sends the
DSC1.2 compressed stream to the HDMI2.1 sink.
This patch configures the PCON for DSC1.1 to DSC1.2 encoding, based
on the PCON's DSC encoder capablities and HDMI2.1 sink's DSC decoder
capabilities.
v2: Rebase
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_ddi.c | 1 +
drivers/gpu/drm/i915/display/intel_dp.c | 128 ++-
drivers/gpu/drm/i915/display/intel_dp.h | 2 +
3 files changed, 129 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 3e76fb1117df..dbf28d021d08 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3493,6 +3493,7 @@ static void tgl_ddi_pre_enable_dp(struct
intel_atomic_state *state,
intel_dp_sink_set_fec_ready(intel_dp, crtc_state);
intel_dp_check_frl_training(intel_dp);
+ intel_dp_pcon_dsc_configure(intel_dp, crtc_state);
/*
* 7.i Follow DisplayPort specification training sequence (see notes for
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 2e7ddb062efe..bc1f1afc35ad 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -788,6 +788,16 @@ intel_dp_mode_valid(struct drm_connector *connector,
target_clock,
mode->hdisplay);
}
+
+ /*
+* TODO: If its a PCON with HDMI sink:
+* Assumption : Source only supports DSC1.1
+*
+* If HDMI supports DSC 1.2 but PCON does not support
+* DSC1.1->DSC1.2 encoding Then return MODE_CLOCK_HIGH.
+* Otherwise check if the mode can be applied according to
+* DSC capablities of the PCON and HDMI Sink combine.
+*/
}
if ((mode_rate > max_rate && !(dsc_max_output_bpp && dsc_slice_count))
||
@@ -3936,9 +3946,21 @@ static int intel_dp_hdmi_sink_max_frl(struct intel_dp
*intel_dp)
{
struct intel_connector *intel_connector = intel_dp->attached_connector;
struct drm_connector *connector = &intel_connector->base;
+ int max_frl_rate;
+ int max_lanes, rate_per_lane;
+ int max_dsc_lanes, dsc_rate_per_lane;
+
+ max_lanes = connector->display_info.hdmi.max_lanes;
+ rate_per_lane = connector->display_info.hdmi.max_frl_rate_per_lane;
+ max_frl_rate = max_lanes * rate_per_lane;
+
+ if (connector->display_info.hdmi.dsc_cap.v_1p2) {
+ max_dsc_lanes = connector->display_info.hdmi.dsc_cap.max_lanes;
+ dsc_rate_per_lane =
connector->display_info.hdmi.dsc_cap.max_frl_rate_per_lane;
+ max_frl_rate = min(max_frl_rate, max_dsc_lanes *
dsc_rate_per_lane);
+ }
- return (connector->display_info.hdmi.max_frl_rate_per_lane *
- connector->display_info.hdmi.max_lanes);
+ return max_frl_rate;
}
static int intel_dp_pcon_start_frl_training(struct intel_dp *intel_dp)
@@ -4071,6 +4093,106 @@ void intel_dp_check_frl_training(struct intel_dp
*intel_dp)
}
}
+static int
+intel_dp_pcon_dsc_enc_slice_height(const struct intel_crtc_state *crtc_state)
+{
+
+ int vactive = crtc_state->hw.adjusted_mode.vdisplay;
+
+ return intel_hdmi_dsc_get_slice_height(vactive);
+}
+
+static int
+intel_dp_pcon_dsc_enc_slices(struct intel_dp *intel_dp,
+const struct intel_crtc_state *crtc_state)
+{
+ struct intel_connector *intel_connector = intel_dp->attached_connector;
+ struct drm_connector *connector = &intel_connector->base;
+ int hdmi_throughput =
connector->display_info.hdmi.dsc_cap.clk_per_slice;
+ int hdmi_max_slices = connector->display_info.hdmi.dsc_cap.max_slices;
+ int pcon_max_slices =
drm_dp_pcon_dsc_max_slices(intel_dp->pcon_dsc_dpcd);
+ int pcon_max_slice_width =
drm_dp_pcon_dsc_max_slice_width(intel_dp->pcon_dsc_dpcd);
+
+
+ return intel_hdmi_dsc_get_num_slices(crtc_state, pcon_max_slices,
+pcon_max_slice_width,
+hdmi_max_slices, hdmi_throughput);
+}
+
+static int
+intel_dp_pcon_dsc_enc_bpp(struct intel_dp *intel_dp,
+ const struct intel_crtc_state *crtc_state,
+ int num_slices, int slice_width)
+{
+ struct intel_connector *intel_connector = intel_dp->attached_connector;
+ struct drm_connector *connector = &intel_connector->base;
+ int output_format = crtc_state->output_format;
+ bool hdmi_all_bpp = connector
[PATCH v2 08/13] drm/i915: Add support for starting FRL training for HDMI2.1 via PCON
This patch adds functions to start FRL training for an HDMI2.1 sink,
connected via a PCON as a DP branch device.
This patch also adds a new structure for storing frl training related
data, when FRL training is completed.
v2: As suggested by Uma Shankar:
-renamed couple of variables for better clarity
-tweaked the macros used for correct semantics for true/false
-fixed other styling issues.
Signed-off-by: Ankit Nautiyal
---
.../drm/i915/display/intel_display_types.h| 7 +
drivers/gpu/drm/i915/display/intel_dp.c | 189 ++
drivers/gpu/drm/i915/display/intel_dp.h | 2 +
3 files changed, 198 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 282c6ee76384..2c58d63928b8 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1286,6 +1286,11 @@ struct intel_dp_compliance {
u8 test_lane_count;
};
+struct intel_dp_pcon_frl {
+ bool is_trained;
+ int trained_rate_gbps;
+};
+
struct intel_dp {
i915_reg_t output_reg;
u32 DP;
@@ -1407,6 +1412,8 @@ struct intel_dp {
bool hobl_failed;
bool hobl_active;
+
+ struct intel_dp_pcon_frl frl;
};
enum lspcon_vendor {
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index caf7666f1892..7feee2adf9b2 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -2871,6 +2871,9 @@ static void intel_dp_prepare(struct intel_encoder
*encoder,
intel_dp->DP |= DP_PIPE_SEL_CHV(crtc->pipe);
else
intel_dp->DP |= DP_PIPE_SEL(crtc->pipe);
+
+ intel_dp->frl.is_trained = false;
+ intel_dp->frl.trained_rate_gbps = 0;
}
}
@@ -3769,6 +3772,8 @@ static void intel_disable_dp(struct intel_atomic_state
*state,
intel_edp_backlight_off(old_conn_state);
intel_dp_set_power(intel_dp, DP_SET_POWER_D3);
intel_edp_panel_off(intel_dp);
+ intel_dp->frl.is_trained = false;
+ intel_dp->frl.trained_rate_gbps = 0;
}
static void g4x_disable_dp(struct intel_atomic_state *state,
@@ -3864,6 +3869,190 @@ cpt_set_link_train(struct intel_dp *intel_dp,
intel_de_posting_read(dev_priv, intel_dp->output_reg);
}
+static int intel_dp_get_max_rate_gbps(struct intel_dp *intel_dp)
+{
+ int max_link_clock, max_lanes, max_rate_khz, max_rate_gbps;
+
+ max_link_clock = intel_dp_max_link_rate(intel_dp);
+ max_lanes = intel_dp_max_lane_count(intel_dp);
+ max_rate_khz = intel_dp_max_data_rate(max_link_clock, max_lanes);
+ max_rate_gbps = 8 * DIV_ROUND_UP(max_rate_khz, 100);
+
+ return max_rate_gbps;
+}
+
+static int intel_dp_pcon_get_frl_mask(u8 frl_bw_mask)
+{
+ int bw_gbps[] = {9, 18, 24, 32, 40, 48};
+ int i;
+
+ for (i = ARRAY_SIZE(bw_gbps) - 1; i >= 0; i--) {
+ if (frl_bw_mask & (1 << i))
+ return bw_gbps[i];
+ }
+ return 0;
+}
+
+static int intel_dp_pcon_set_frl_mask(int max_frl)
+{
+
+ switch (max_frl) {
+ case 48:
+ return DP_PCON_FRL_BW_MASK_48GBPS;
+ case 40:
+ return DP_PCON_FRL_BW_MASK_40GBPS;
+ case 32:
+ return DP_PCON_FRL_BW_MASK_32GBPS;
+ case 24:
+ return DP_PCON_FRL_BW_MASK_24GBPS;
+ case 18:
+ return DP_PCON_FRL_BW_MASK_18GBPS;
+ case 9:
+ return DP_PCON_FRL_BW_MASK_9GBPS;
+ }
+
+ return 0;
+}
+
+static int intel_dp_hdmi_sink_max_frl(struct intel_dp *intel_dp)
+{
+ struct intel_connector *intel_connector = intel_dp->attached_connector;
+ struct drm_connector *connector = &intel_connector->base;
+
+ return (connector->display_info.hdmi.max_frl_rate_per_lane *
+ connector->display_info.hdmi.max_lanes);
+}
+
+static int intel_dp_pcon_start_frl_training(struct intel_dp *intel_dp)
+{
+#define PCON_EXTENDED_TRAIN_MODE (1 > 0)
+#define PCON_CONCURRENT_MODE (1 > 0)
+#define PCON_SEQUENTIAL_MODE !PCON_CONCURRENT_MODE
+#define PCON_NORMAL_TRAIN_MODE !PCON_EXTENDED_TRAIN_MODE
+#define TIMEOUT_FRL_READY_MS 500
+#define TIMEOUT_HDMI_LINK_ACTIVE_MS 1000
+
+ struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+ int max_frl_bw, max_pcon_frl_bw, max_sink_frl_bw, max_rate_gbps,
max_edid_frl_bw, ret;
+ u8 max_frl_bw_mask = 0, frl_trained_mask;
+ bool is_active;
+
+ ret = drm_dp_pcon_reset_frl_config(&intel_dp->aux);
+ if (ret < 0)
+ return ret;
+
+ max_rate_gbps = intel_dp_get_max_rate_gbps(intel_dp);
+ drm_dbg(&i915->drm, "Source max rate = %d Gbps\n", max_rate_gbps);
+
+ max_pcon_frl_bw = intel_dp->dfp.pcon_max_frl_bw;
+ drm_dbg(&i915->drm, "PCON max rate = %d Gbps\n", max_pcon_frl_bw);
+
+
[PATCH v2 11/13] drm/i915: Read DSC capabilities of the HDMI2.1 PCON encoder
This patch adds support to read and store the DSC capabilities of the
HDMI2.1 PCon encoder. It also adds a new field to store these caps,
The caps are read during dfp update and can later be used to get the
PPS parameters for PCON-HDMI2.1 sink pair. Which inturn will be used
to take a call to override the existing PPS-metadata, by either
writing the entire new PPS metadata, or by writing only the
PPS override parameters.
v2: Restructured the code to read all capability DPCDs at once and store
in an array in intel_dp structure.
Signed-off-by: Ankit Nautiyal
---
.../drm/i915/display/intel_display_types.h| 1 +
drivers/gpu/drm/i915/display/intel_dp.c | 20 +++
2 files changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 2c58d63928b8..f43ded030c14 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1309,6 +1309,7 @@ struct intel_dp {
u8 lttpr_common_caps[DP_LTTPR_COMMON_CAP_SIZE];
u8 lttpr_phy_caps[DP_MAX_LTTPR_COUNT][DP_LTTPR_PHY_CAP_SIZE];
u8 fec_capable;
+ u8 pcon_dsc_dpcd[DP_PCON_DSC_ENCODER_CAP_SIZE];
/* source rates */
int num_source_rates;
const int *source_rates;
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 6177169c4401..2e7ddb062efe 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -3869,6 +3869,24 @@ cpt_set_link_train(struct intel_dp *intel_dp,
intel_de_posting_read(dev_priv, intel_dp->output_reg);
}
+static void intel_dp_get_pcon_dsc_cap(struct intel_dp *intel_dp)
+{
+ struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+
+ /* Clear the cached register set to avoid using stale values */
+
+ memset(intel_dp->pcon_dsc_dpcd, 0, sizeof(intel_dp->pcon_dsc_dpcd));
+
+ if (drm_dp_dpcd_read(&intel_dp->aux, DP_PCON_DSC_ENCODER,
+intel_dp->pcon_dsc_dpcd,
+sizeof(intel_dp->pcon_dsc_dpcd)) < 0)
+ drm_err(&i915->drm, "Failed to read DPCD register 0x%x\n",
+ DP_PCON_DSC_ENCODER);
+
+ drm_dbg_kms(&i915->drm, "PCON ENCODER DSC DPCD: %*ph\n",
+ (int)sizeof(intel_dp->pcon_dsc_dpcd),
intel_dp->pcon_dsc_dpcd);
+}
+
static int intel_dp_get_max_rate_gbps(struct intel_dp *intel_dp)
{
int max_link_clock, max_lanes, max_rate_khz, max_rate_gbps;
@@ -6645,6 +6663,8 @@ intel_dp_update_dfp(struct intel_dp *intel_dp,
intel_dp->dfp.max_tmds_clock,
intel_dp->dfp.pcon_max_frl_bw,
intel_dp->dfp.sink_max_frl_bw);
+
+ intel_dp_get_pcon_dsc_cap(intel_dp);
}
static void
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 05/13] drm/dp_helper: Add support for link failure detection
From: Swati Sharma
There are specific DPCDs defined for detecting link failures between
the PCON and HDMI sink and check the link status. In case of link
failure, PCON will communicate the same using an IRQ_HPD to source.
HDMI sink would have indicated the same to PCON using SCDC interrupt
mechanism. While source can always read final HDMI sink's status using
I2C over AUX, it is easier and faster to read the PCONs already read
HDMI sink status registers.
This patch adds the DPCDs required for link failure detection and
provide a helper function for printing error count/lane which might
help in debugging the link failure issues.
v2: Addressed comments from Uma Shankar:
-rephrased the commit message, as per the code.
-fixed styling issues
-added documentation for the helper function.
Signed-off-by: Swati Sharma
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/drm_dp_helper.c | 39 +
include/drm/drm_dp_helper.h | 17 ++
2 files changed, 56 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index b67580294c4e..05782091e7e1 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -2893,3 +2893,42 @@ int drm_dp_pcon_hdmi_link_mode(struct drm_dp_aux *aux,
u8 *frl_trained_mask)
return mode;
}
EXPORT_SYMBOL(drm_dp_pcon_hdmi_link_mode);
+
+/**
+ * drm_dp_pcon_hdmi_frl_link_error_count() - print the error count per lane
+ * during link failure between PCON and HDMI sink
+ * @aux: DisplayPort AUX channel
+ * @connector: DRM connector
+ * code.
+ **/
+
+void drm_dp_pcon_hdmi_frl_link_error_count(struct drm_dp_aux *aux,
+ struct drm_connector *connector)
+{
+ u8 buf, error_count;
+ int i, num_error;
+ struct drm_hdmi_info *hdmi = &connector->display_info.hdmi;
+
+ for (i = 0; i < hdmi->max_lanes; i++) {
+ if (drm_dp_dpcd_readb(aux, DP_PCON_HDMI_ERROR_STATUS_LN0 + i,
&buf) < 0)
+ return;
+
+ error_count = buf & DP_PCON_HDMI_ERROR_COUNT_MASK;
+ switch (error_count) {
+ case DP_PCON_HDMI_ERROR_COUNT_HUNDRED_PLUS:
+ num_error = 100;
+ break;
+ case DP_PCON_HDMI_ERROR_COUNT_TEN_PLUS:
+ num_error = 10;
+ break;
+ case DP_PCON_HDMI_ERROR_COUNT_THREE_PLUS:
+ num_error = 3;
+ break;
+ default:
+ num_error = 0;
+ }
+
+ DRM_ERROR("More than %d errors since the last read for lane
%d", num_error, i);
+ }
+}
+EXPORT_SYMBOL(drm_dp_pcon_hdmi_frl_link_error_count);
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index e2ed6bfaae89..bdbe9bbdb244 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -946,6 +946,11 @@ struct drm_device;
# define DP_CEC_IRQ (1 << 2)
#define DP_LINK_SERVICE_IRQ_VECTOR_ESI0 0x2005 /* 1.2 */
+# define RX_CAP_CHANGED (1 << 0)
+# define LINK_STATUS_CHANGED (1 << 1)
+# define STREAM_STATUS_CHANGED (1 << 2)
+# define HDMI_LINK_STATUS_CHANGED(1 << 3)
+# define CONNECTED_OFF_ENTRY_REQUESTED (1 << 4)
#define DP_PSR_ERROR_STATUS 0x2006 /* XXX 1.2? */
# define DP_PSR_LINK_CRC_ERROR (1 << 0)
@@ -1130,6 +1135,16 @@ struct drm_device;
#define DP_PROTOCOL_CONVERTER_CONTROL_20x3052 /* DP 1.3 */
# define DP_CONVERSION_TO_YCBCR422_ENABLE (1 << 0) /* DP 1.3 */
+/* PCON Downstream HDMI ERROR Status per Lane */
+#define DP_PCON_HDMI_ERROR_STATUS_LN0 0x3037
+#define DP_PCON_HDMI_ERROR_STATUS_LN1 0x3038
+#define DP_PCON_HDMI_ERROR_STATUS_LN2 0x3039
+#define DP_PCON_HDMI_ERROR_STATUS_LN3 0x303A
+# define DP_PCON_HDMI_ERROR_COUNT_MASK (0x7 << 0)
+# define DP_PCON_HDMI_ERROR_COUNT_THREE_PLUS (1 << 0)
+# define DP_PCON_HDMI_ERROR_COUNT_TEN_PLUS (1 << 1)
+# define DP_PCON_HDMI_ERROR_COUNT_HUNDRED_PLUS (1 << 2)
+
/* HDCP 1.3 and HDCP 2.2 */
#define DP_AUX_HDCP_BKSV 0x68000
#define DP_AUX_HDCP_RI_PRIME 0x68005
@@ -2047,5 +2062,7 @@ int drm_dp_pcon_frl_enable(struct drm_dp_aux *aux);
bool drm_dp_pcon_hdmi_link_active(struct drm_dp_aux *aux);
int drm_dp_pcon_hdmi_link_mode(struct drm_dp_aux *aux, u8 *frl_trained_mask);
+void drm_dp_pcon_hdmi_frl_link_error_count(struct drm_dp_aux *aux,
+ struct drm_connector *connector);
#endif /* _DRM_DP_HELPER_H_ */
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 10/13] drm/i915: Add support for enabling link status and recovery
From: Swati Sharma
In this patch enables support for detecting link failures between
PCON and HDMI sink in i915 driver. HDMI link loss indication to
upstream DP source is indicated via IRQ_HPD. This is followed by
reading of HDMI link configuration status (HDMI_TX_LINK_ACTIVE_STATUS).
If the PCON → HDMI 2.1 link status is off; reinitiate frl link
training to recover. Also, report HDMI FRL link error count range for
each individual FRL active lane is indicated by
DOWNSTREAM_HDMI_ERROR_STATUS_LN registers.
v2: Checked for dpcd read and write failures and added debug message.
(Uma Shankar)
Signed-off-by: Swati Sharma
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_dp.c | 56 +++--
1 file changed, 53 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 9047b620c0d0..6177169c4401 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5932,6 +5932,31 @@ intel_dp_check_mst_status(struct intel_dp *intel_dp)
return link_ok;
}
+static void
+intel_dp_handle_hdmi_link_status_change(struct intel_dp *intel_dp)
+{
+ bool is_active;
+ u8 buf = 0;
+
+ is_active = drm_dp_pcon_hdmi_link_active(&intel_dp->aux);
+ if (intel_dp->frl.is_trained && !is_active) {
+ if (drm_dp_dpcd_readb(&intel_dp->aux,
DP_PCON_HDMI_LINK_CONFIG_1, &buf) < 0)
+ return;
+
+ buf &= ~DP_PCON_ENABLE_HDMI_LINK;
+ if (drm_dp_dpcd_writeb(&intel_dp->aux,
DP_PCON_HDMI_LINK_CONFIG_1, buf) < 0)
+ return;
+
+ drm_dp_pcon_hdmi_frl_link_error_count(&intel_dp->aux,
&intel_dp->attached_connector->base);
+
+ intel_dp->frl.is_trained = false;
+ intel_dp->frl.trained_rate_gbps = 0;
+
+ /* Restart FRL training or fall back to TMDS mode */
+ intel_dp_check_frl_training(intel_dp);
+ }
+}
+
static bool
intel_dp_needs_link_retrain(struct intel_dp *intel_dp)
{
@@ -6297,7 +6322,7 @@ intel_dp_hotplug(struct intel_encoder *encoder,
return state;
}
-static void intel_dp_check_service_irq(struct intel_dp *intel_dp)
+static void intel_dp_check_device_service_irq(struct intel_dp *intel_dp)
{
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
u8 val;
@@ -6321,6 +6346,30 @@ static void intel_dp_check_service_irq(struct intel_dp
*intel_dp)
drm_dbg_kms(&i915->drm, "Sink specific irq unhandled\n");
}
+static void intel_dp_check_link_service_irq(struct intel_dp *intel_dp)
+{
+ struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+ u8 val;
+
+ if (intel_dp->dpcd[DP_DPCD_REV] < 0x11)
+ return;
+
+ if (drm_dp_dpcd_readb(&intel_dp->aux,
+ DP_LINK_SERVICE_IRQ_VECTOR_ESI0, &val) != 1 ||
!val) {
+ drm_dbg_kms(&i915->drm, "Error in reading link service irq
vector\n");
+ return;
+ }
+
+ if (drm_dp_dpcd_writeb(&intel_dp->aux,
+ DP_LINK_SERVICE_IRQ_VECTOR_ESI0, val) != 1) {
+ drm_dbg_kms(&i915->drm, "Error in writing link service irq
vector\n");
+ return;
+ }
+
+ if (val & HDMI_LINK_STATUS_CHANGED)
+ intel_dp_handle_hdmi_link_status_change(intel_dp);
+}
+
/*
* According to DP spec
* 5.1.2:
@@ -6360,7 +6409,8 @@ intel_dp_short_pulse(struct intel_dp *intel_dp)
return false;
}
- intel_dp_check_service_irq(intel_dp);
+ intel_dp_check_device_service_irq(intel_dp);
+ intel_dp_check_link_service_irq(intel_dp);
/* Handle CEC interrupts, if any */
drm_dp_cec_irq(&intel_dp->aux);
@@ -6794,7 +6844,7 @@ intel_dp_detect(struct drm_connector *connector,
to_intel_connector(connector)->detect_edid)
status = connector_status_connected;
- intel_dp_check_service_irq(intel_dp);
+ intel_dp_check_device_service_irq(intel_dp);
out:
if (status != connector_status_connected && !intel_dp->is_mst)
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 09/13] drm/i915: Check for FRL training before DP Link training
This patch calls functions to check FRL training requirements for an HDMI2.1 sink, when connected through PCON. The call is made before the DP link training. In case FRL is not required or failure during FRL training, the TMDS mode is selected for the pcon. v2: moved check_frl_training() just after FEC READY, before starting DP link training. Signed-off-by: Ankit Nautiyal --- drivers/gpu/drm/i915/display/intel_ddi.c | 2 ++ drivers/gpu/drm/i915/display/intel_dp.c | 2 ++ 2 files changed, 4 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c b/drivers/gpu/drm/i915/display/intel_ddi.c index 09811be08cfe..3e76fb1117df 100644 --- a/drivers/gpu/drm/i915/display/intel_ddi.c +++ b/drivers/gpu/drm/i915/display/intel_ddi.c @@ -3492,6 +3492,8 @@ static void tgl_ddi_pre_enable_dp(struct intel_atomic_state *state, */ intel_dp_sink_set_fec_ready(intel_dp, crtc_state); + intel_dp_check_frl_training(intel_dp); + /* * 7.i Follow DisplayPort specification training sequence (see notes for * failure handling) diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c index 7feee2adf9b2..9047b620c0d0 100644 --- a/drivers/gpu/drm/i915/display/intel_dp.c +++ b/drivers/gpu/drm/i915/display/intel_dp.c @@ -4183,6 +4183,7 @@ static void intel_enable_dp(struct intel_atomic_state *state, intel_dp_set_power(intel_dp, DP_SET_POWER_D0); intel_dp_configure_protocol_converter(intel_dp); + intel_dp_check_frl_training(intel_dp); intel_dp_start_link_train(intel_dp, pipe_config); intel_dp_stop_link_train(intel_dp, pipe_config); @@ -6104,6 +6105,7 @@ int intel_dp_retrain_link(struct intel_encoder *encoder, !intel_dp_mst_is_master_trans(crtc_state)) continue; + intel_dp_check_frl_training(intel_dp); intel_dp_start_link_train(intel_dp, crtc_state); intel_dp_stop_link_train(intel_dp, crtc_state); break; -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 07/13] drm/i915: Capture max frl rate for PCON in dfp cap structure
HDMI2.1 PCON advertises Max FRL bandwidth supported by the PCON and
by the sink.
This patch captures these in dfp cap structure in intel_dp and uses
these to prune connector modes that cannot be supported by the PCON
and sink FRL bandwidth.
v2: Addressed review comments from Uma Shankar:
-tweaked the comparison of target bw and pcon frl bw to avoid roundup errors.
-minor modification of field names and comments.
Signed-off-by: Ankit Nautiyal
---
.../drm/i915/display/intel_display_types.h| 1 +
drivers/gpu/drm/i915/display/intel_dp.c | 38 ++-
2 files changed, 37 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index f6f0626649e0..282c6ee76384 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1397,6 +1397,7 @@ struct intel_dp {
struct {
int min_tmds_clock, max_tmds_clock;
int max_dotclock;
+ int pcon_max_frl_bw, sink_max_frl_bw;
u8 max_bpc;
bool ycbcr_444_to_420;
} dfp;
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 818daab252f3..caf7666f1892 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -684,6 +684,29 @@ intel_dp_mode_valid_downstream(struct intel_connector
*connector,
const struct drm_display_info *info = &connector->base.display_info;
int tmds_clock;
+ /*
+* If PCON and HDMI2.1 sink both support FRL MODE, check FRL
+* bandwidth constraints.
+*/
+ if (intel_dp->dfp.pcon_max_frl_bw) {
+ int target_bw;
+ int max_frl_bw;
+ int bpp = intel_dp_mode_min_output_bpp(&connector->base, mode);
+
+ target_bw = bpp * target_clock;
+
+ max_frl_bw = min(intel_dp->dfp.pcon_max_frl_bw,
+intel_dp->dfp.sink_max_frl_bw);
+
+ /* converting bw from Gbps to Kbps*/
+ max_frl_bw = max_frl_bw * 100;
+
+ if (target_bw > max_frl_bw)
+ return MODE_CLOCK_HIGH;
+
+ return MODE_OK;
+ }
+
if (intel_dp->dfp.max_dotclock &&
target_clock > intel_dp->dfp.max_dotclock)
return MODE_CLOCK_HIGH;
@@ -6366,13 +6389,21 @@ intel_dp_update_dfp(struct intel_dp *intel_dp,
intel_dp->downstream_ports,
edid);
+ intel_dp->dfp.pcon_max_frl_bw =
+ drm_dp_get_pcon_max_frl_bw(intel_dp->dpcd,
+ intel_dp->downstream_ports);
+
+ intel_dp->dfp.sink_max_frl_bw =
drm_dp_get_hdmi_sink_max_frl_bw(&intel_dp->aux);
+
drm_dbg_kms(&i915->drm,
- "[CONNECTOR:%d:%s] DFP max bpc %d, max dotclock %d, TMDS
clock %d-%d\n",
+ "[CONNECTOR:%d:%s] DFP max bpc %d, max dotclock %d, TMDS
clock %d-%d, PCON Max FRL BW %dGbps, Sink Max FRL BW %dGbps\n",
connector->base.base.id, connector->base.name,
intel_dp->dfp.max_bpc,
intel_dp->dfp.max_dotclock,
intel_dp->dfp.min_tmds_clock,
- intel_dp->dfp.max_tmds_clock);
+ intel_dp->dfp.max_tmds_clock,
+ intel_dp->dfp.pcon_max_frl_bw,
+ intel_dp->dfp.sink_max_frl_bw);
}
static void
@@ -6464,6 +6495,9 @@ intel_dp_unset_edid(struct intel_dp *intel_dp)
intel_dp->dfp.min_tmds_clock = 0;
intel_dp->dfp.max_tmds_clock = 0;
+ intel_dp->dfp.pcon_max_frl_bw = 0;
+ intel_dp->dfp.sink_max_frl_bw = 0;
+
intel_dp->dfp.ycbcr_444_to_420 = false;
connector->base.ycbcr_420_allowed = false;
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 12/13] drm/i915: Add helper functions for calculating DSC parameters for HDMI2.1
The DP-HDMI2.1 PCON spec provides way for a source to set PPS
parameters: slice height, slice width and bits_per_pixel, based on
the HDMI2.1 sink capabilities. The DSC encoder of the PCON will
respect these parameters, while preparing the 128 byte PPS.
This patch adds helper functions to calculate these PPS paremeters as
per the HDMI2.1 specification.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_hdmi.c | 181 ++
drivers/gpu/drm/i915/display/intel_hdmi.h | 7 +
2 files changed, 188 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index f90838bc74fb..6b9b9ea7f9b0 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -3438,3 +3438,184 @@ void intel_hdmi_init(struct drm_i915_private *dev_priv,
dig_port->aux_ch = intel_bios_port_aux_ch(dev_priv, port);
intel_hdmi_init_connector(dig_port, intel_connector);
}
+
+int intel_hdmi_dsc_get_slice_height(int vactive)
+{
+ int slice_height;
+
+ /*
+* Slice Height determination : HDMI2.1 Section 7.7.5.2
+* Select smallest slice height >=96, that results in a valid PPS and
+* requires minimum padding lines required for final slice.
+*
+* Assumption : Vactive is even.
+*/
+ for (slice_height = 96; slice_height <= vactive; slice_height += 2)
+ if (vactive % slice_height == 0)
+ return slice_height;
+
+ return 0;
+}
+
+int
+intel_hdmi_dsc_get_num_slices(const struct intel_crtc_state *crtc_state,
+ int src_max_slices, int src_max_slice_width,
+ int hdmi_max_slices, int hdmi_throughput)
+{
+/* Pixel rates in KPixels/sec */
+#define HDMI_DSC_PEAK_PIXEL_RATE 272
+#define HDMI_DSC_MAX_ENC_THROUGHPUT_0 34
+#define HDMI_DSC_MAX_ENC_THROUGHPUT_1 40
+#define MAX_HDMI_SLICE_WIDTH 2720
+ int kslice_adjust;
+ int adjusted_clk_khz;
+ int min_slices;
+ int target_slices;
+ int max_throughput; /* max clock freq. in khz per slice */
+ int max_slice_width;
+ int slice_width;
+ int pixel_clock = crtc_state->hw.adjusted_mode.crtc_clock;
+
+ if (!hdmi_throughput)
+ return 0;
+
+ /*
+* Slice Width determination : HDMI2.1 Section 7.7.5.1
+* kslice_adjust factor for 4:2:0 formats is 0.5, where as
+* for 4:4:4 is 1.0. Multiplying these factors by 10 and later
+* dividing adjusted clock value by 10.
+*/
+ if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420)
+ kslice_adjust = 5;
+ else
+ kslice_adjust = 10;
+
+ adjusted_clk_khz = DIV_ROUND_UP(kslice_adjust * pixel_clock, 10);
+
+ if (adjusted_clk_khz <= HDMI_DSC_PEAK_PIXEL_RATE)
+ max_throughput = HDMI_DSC_MAX_ENC_THROUGHPUT_0;
+ else
+ max_throughput = HDMI_DSC_MAX_ENC_THROUGHPUT_1;
+
+ /*
+* Taking into account the sink's capability for maximum
+* clock per slice (in MHz) as read from HF-VSDB.
+*/
+ max_throughput = min(max_throughput, hdmi_throughput * 1000);
+
+ if (!max_throughput)
+ return 0;
+
+ min_slices = DIV_ROUND_UP(adjusted_clk_khz, max_throughput);
+ max_slice_width = min(MAX_HDMI_SLICE_WIDTH, src_max_slice_width);
+
+ /*
+* Keep on increasing the num of slices/line, starting from min_slices
+* per line till we get such a number, for which the slice_width is
+* just less than max_slice_width. The slices/line selected should be
+* less than or equal to the max horizontal slices that the combination
+* of PCON encoder and HDMI decoder can support.
+*/
+ slice_width = max_slice_width;
+
+ do {
+ if (min_slices <= 1 && src_max_slices >= 1 && hdmi_max_slices
>= 1)
+ target_slices = 1;
+ else if (min_slices <= 2 && src_max_slices >= 2 &&
hdmi_max_slices >= 2)
+ target_slices = 2;
+ else if (min_slices <= 4 && src_max_slices >= 4 &&
hdmi_max_slices >= 4)
+ target_slices = 4;
+ else if (min_slices <= 8 && src_max_slices >= 8 &&
hdmi_max_slices >= 8)
+ target_slices = 8;
+ else if (min_slices <= 12 && src_max_slices >= 12 &&
hdmi_max_slices >= 12)
+ target_slices = 12;
+ else if (min_slices <= 16 && src_max_slices >= 16 &&
hdmi_max_slices >= 16)
+ target_slices = 16;
+ else
+ return 0;
+
+ slice_width =
DIV_ROUND_UP(crtc_state->hw.adjusted_mode.hdisplay, target_slices);
+ if (slice_width >= max_slice_width)
+
[PATCH v2 06/13] drm/dp_helper: Add support for Configuring DSC for HDMI2.1 Pcon
This patch adds registers for getting DSC encoder capability for
a HDMI2.1 PCon. It also addes helper functions to configure
DSC between the PCON and HDMI2.1 sink.
v2: Corrected offset for DSC encoder bpc and minor changes.
Also added helper functions for getting pcon dsc encoder capabilities
as suggested by Uma Shankar.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/drm_dp_helper.c | 197
include/drm/drm_dp_helper.h | 114 ++
2 files changed, 311 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 05782091e7e1..8162ee856b5d 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -2932,3 +2932,200 @@ void drm_dp_pcon_hdmi_frl_link_error_count(struct
drm_dp_aux *aux,
}
}
EXPORT_SYMBOL(drm_dp_pcon_hdmi_frl_link_error_count);
+
+/*
+ * drm_dp_pcon_enc_is_dsc_1_2 - Does PCON Encoder supports DSC 1.2
+ * @pcon_dsc_dpcd: DSC capabilities of the PCON DSC Encoder
+ *
+ * Returns true is PCON encoder is DSC 1.2 else returns false.
+ */
+bool drm_dp_pcon_enc_is_dsc_1_2(const u8
pcon_dsc_dpcd[DP_PCON_DSC_ENCODER_CAP_SIZE])
+{
+ u8 buf;
+ u8 major_v, minor_v;
+
+ buf = pcon_dsc_dpcd[DP_PCON_DSC_VERSION - DP_PCON_DSC_ENCODER];
+ major_v = (buf & DP_PCON_DSC_MAJOR_MASK) >> DP_PCON_DSC_MAJOR_SHIFT;
+ minor_v = (buf & DP_PCON_DSC_MINOR_MASK) >> DP_PCON_DSC_MINOR_SHIFT;
+
+ if (major_v == 1 && minor_v == 2)
+ return true;
+
+ return false;
+}
+EXPORT_SYMBOL(drm_dp_pcon_enc_is_dsc_1_2);
+
+/*
+ * drm_dp_pcon_dsc_max_slices - Get max slices supported by PCON DSC Encoder
+ * @pcon_dsc_dpcd: DSC capabilities of the PCON DSC Encoder
+ *
+ * Returns maximum no. of slices supported by the PCON DSC Encoder.
+ */
+int drm_dp_pcon_dsc_max_slices(const u8
pcon_dsc_dpcd[DP_PCON_DSC_ENCODER_CAP_SIZE])
+{
+ u8 slice_cap1, slice_cap2;
+
+ slice_cap1 = pcon_dsc_dpcd[DP_PCON_DSC_SLICE_CAP_1 -
DP_PCON_DSC_ENCODER];
+ slice_cap2 = pcon_dsc_dpcd[DP_PCON_DSC_SLICE_CAP_2 -
DP_PCON_DSC_ENCODER];
+
+ if (slice_cap2 & DP_PCON_DSC_24_PER_DSC_ENC)
+ return 24;
+ if (slice_cap2 & DP_PCON_DSC_20_PER_DSC_ENC)
+ return 20;
+ if (slice_cap2 & DP_PCON_DSC_16_PER_DSC_ENC)
+ return 16;
+ if (slice_cap1 & DP_PCON_DSC_12_PER_DSC_ENC)
+ return 12;
+ if (slice_cap1 & DP_PCON_DSC_10_PER_DSC_ENC)
+ return 10;
+ if (slice_cap1 & DP_PCON_DSC_8_PER_DSC_ENC)
+ return 8;
+ if (slice_cap1 & DP_PCON_DSC_6_PER_DSC_ENC)
+ return 6;
+ if (slice_cap1 & DP_PCON_DSC_4_PER_DSC_ENC)
+ return 4;
+ if (slice_cap1 & DP_PCON_DSC_2_PER_DSC_ENC)
+ return 2;
+ if (slice_cap1 & DP_PCON_DSC_1_PER_DSC_ENC)
+ return 1;
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_dp_pcon_dsc_max_slices);
+
+/*
+ * drm_dp_pcon_dsc_max_slice_width() - Get max slice width for Pcon DSC encoder
+ * @pcon_dsc_dpcd: DSC capabilities of the PCON DSC Encoder
+ *
+ * Returns maximum width of the slices in pixel width i.e. no. of pixels x 320.
+ */
+int drm_dp_pcon_dsc_max_slice_width(const u8
pcon_dsc_dpcd[DP_PCON_DSC_ENCODER_CAP_SIZE])
+{
+ u8 buf;
+
+ buf = pcon_dsc_dpcd[DP_PCON_DSC_MAX_SLICE_WIDTH - DP_PCON_DSC_ENCODER];
+
+ return buf * DP_DSC_SLICE_WIDTH_MULTIPLIER;
+}
+EXPORT_SYMBOL(drm_dp_pcon_dsc_max_slice_width);
+
+/*
+ * drm_dp_pcon_dsc_bpp_incr() - Get bits per pixel increment for PCON DSC
encoder
+ * @pcon_dsc_dpcd: DSC capabilities of the PCON DSC Encoder
+ *
+ * Returns the bpp precision supported by the PCON encoder.
+ */
+int drm_dp_pcon_dsc_bpp_incr(const u8
pcon_dsc_dpcd[DP_PCON_DSC_ENCODER_CAP_SIZE])
+{
+ u8 buf;
+
+ buf = pcon_dsc_dpcd[DP_PCON_DSC_BPP_INCR - DP_PCON_DSC_ENCODER];
+
+ switch (buf & DP_PCON_DSC_BPP_INCR_MASK) {
+ case DP_PCON_DSC_ONE_16TH_BPP:
+ return 16;
+ case DP_PCON_DSC_ONE_8TH_BPP:
+ return 8;
+ case DP_PCON_DSC_ONE_4TH_BPP:
+ return 4;
+ case DP_PCON_DSC_ONE_HALF_BPP:
+ return 2;
+ case DP_PCON_DSC_ONE_BPP:
+ return 1;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_dp_pcon_dsc_bpp_incr);
+
+static
+int drm_dp_pcon_configure_dsc_enc(struct drm_dp_aux *aux, u8 pps_buf_config)
+{
+ u8 buf = DP_PCON_ENABLE_DSC_ENCODER;
+ int ret;
+
+ if (pps_buf_config <= DP_PCON_ENC_PPS_OVERRIDE_EN_BUFFER) {
+ buf &= ~DP_PCON_ENCODER_PPS_OVERRIDE_MASK;
+ buf |= pps_buf_config << 2;
+ }
+
+ ret = drm_dp_dpcd_writeb(aux, DP_PROTOCOL_CONVERTER_CONTROL_2, buf);
+ if (ret < 0)
+ return ret;
+
+ return 0;
+}
+
+/**
+ * drm_dp_pcon_pps_default() - Let PCON fill the default pps parameters
+ * for DSC1.2 between PCON & HDMI2.1 sink
+ * @aux: DisplayPort AUX chan
[PATCH v2 04/13] drm/dp_helper: Add Helpers for FRL Link Training support for DP-HDMI2.1 PCON
This patch adds support for configuring a PCON device,
connected as a DP branched device to enable FRL Link training
with a HDMI2.1 + sink.
v2: Fixed typos and addressed other review comments from Uma Shankar.
-changed the commit message for better clarity (Uma Shankar)
-removed unnecessary argument supplied to a drm helper function.
-fixed return value for max frl read from pcon.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/drm_dp_helper.c | 302
include/drm/drm_dp_helper.h | 81 +
2 files changed, 383 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 14ddf28ecac0..b67580294c4e 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -2591,3 +2591,305 @@ void drm_dp_vsc_sdp_log(const char *level, struct
device *dev,
#undef DP_SDP_LOG
}
EXPORT_SYMBOL(drm_dp_vsc_sdp_log);
+
+/**
+ * drm_dp_get_pcon_max_frl_bw() - maximum frl supported by PCON
+ * @dpcd: DisplayPort configuration data
+ * @port_cap: port capabilities
+ *
+ * Returns maximum frl bandwidth supported by PCON in GBPS,
+ * returns 0 if not supported.
+ **/
+int drm_dp_get_pcon_max_frl_bw(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
+ const u8 port_cap[4])
+{
+ int bw;
+ u8 buf;
+
+ buf = port_cap[2];
+ bw = buf & DP_PCON_MAX_FRL_BW;
+
+ switch (bw) {
+ case DP_PCON_MAX_9GBPS:
+ return 9;
+ case DP_PCON_MAX_18GBPS:
+ return 18;
+ case DP_PCON_MAX_24GBPS:
+ return 24;
+ case DP_PCON_MAX_32GBPS:
+ return 32;
+ case DP_PCON_MAX_40GBPS:
+ return 40;
+ case DP_PCON_MAX_48GBPS:
+ return 48;
+ case DP_PCON_MAX_0GBPS:
+ default:
+ return 0;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_dp_get_pcon_max_frl_bw);
+
+/**
+ * drm_dp_get_hdmi_sink_max_frl_bw() - maximum frl supported by HDMI Sink
+ * @aux: DisplayPort AUX channel
+ *
+ * Returns maximum frl bandwidth supported by HDMI in Gbps on success,
+ * returns 0, if not supported.
+ **/
+int drm_dp_get_hdmi_sink_max_frl_bw(struct drm_dp_aux *aux)
+{
+ u8 buf;
+ int bw, ret;
+
+ ret = drm_dp_dpcd_readb(aux, DP_PCON_HDMI_SINK, &buf);
+ if (ret < 0)
+ return 0;
+ bw = buf & DP_HDMI_SINK_LINK_BW;
+
+ switch (bw) {
+ case DP_HDMI_SINK_BW_9GBPS:
+ return 9;
+ case DP_HDMI_SINK_BW_18GBPS:
+ return 18;
+ case DP_HDMI_SINK_BW_24GBPS:
+ return 24;
+ case DP_HDMI_SINK_BW_32GBPS:
+ return 32;
+ case DP_HDMI_SINK_BW_40GBPS:
+ return 40;
+ case DP_HDMI_SINK_BW_48GBPS:
+ return 48;
+ case DP_HDMI_SINK_BW_0GBPS:
+ default:
+ return 0;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_dp_get_hdmi_sink_max_frl_bw);
+
+/**
+ * drm_dp_pcon_frl_prepare() - Prepare PCON for FRL.
+ * @aux: DisplayPort AUX channel
+ *
+ * Returns 0 if success, else returns negative error code.
+ **/
+int drm_dp_pcon_frl_prepare(struct drm_dp_aux *aux, bool enable_frl_ready_hpd)
+{
+ int ret;
+ u8 buf = DP_PCON_ENABLE_SOURCE_CTL_MODE |
+DP_PCON_ENABLE_LINK_FRL_MODE;
+
+ if (enable_frl_ready_hpd)
+ buf |= DP_PCON_ENABLE_HPD_READY;
+
+ ret = drm_dp_dpcd_writeb(aux, DP_PCON_HDMI_LINK_CONFIG_1, buf);
+
+ return ret;
+}
+EXPORT_SYMBOL(drm_dp_pcon_frl_prepare);
+
+/**
+ * drm_dp_pcon_is_frl_ready() - Is PCON ready for FRL
+ * @aux: DisplayPort AUX channel
+ *
+ * Returns true if success, else returns false.
+ **/
+bool drm_dp_pcon_is_frl_ready(struct drm_dp_aux *aux)
+{
+ int ret;
+ u8 buf;
+
+ ret = drm_dp_dpcd_readb(aux, DP_PCON_HDMI_TX_LINK_STATUS, &buf);
+ if (ret < 0)
+ return false;
+
+ if (buf & DP_PCON_FRL_READY)
+ return true;
+
+ return false;
+}
+EXPORT_SYMBOL(drm_dp_pcon_is_frl_ready);
+
+/**
+ * drm_dp_pcon_frl_configure_1() - Set HDMI LINK Configuration-Step1
+ * @aux: DisplayPort AUX channel
+ * @max_frl_gbps: maximum frl bw to be configured between PCON and HDMI sink
+ * @concurrent_mode: true if concurrent mode or operation is required,
+ * false otherwise.
+ *
+ * Returns 0 if success, else returns negative error code.
+ **/
+
+int drm_dp_pcon_frl_configure_1(struct drm_dp_aux *aux, int max_frl_gbps,
+ bool concurrent_mode)
+{
+ int ret;
+ u8 buf;
+
+ ret = drm_dp_dpcd_readb(aux, DP_PCON_HDMI_LINK_CONFIG_1, &buf);
+ if (ret < 0)
+ return ret;
+
+ if (concurrent_mode)
+ buf |= DP_PCON_ENABLE_CONCURRENT_LINK;
+ else
+ buf &= ~DP_PCON_ENABLE_CONCURRENT_LINK;
+
+ switch (max_frl_gbps) {
+ case 9:
+ buf |= DP_PCON_ENABLE_MAX_BW_9GBPS;
+ break;
Re: [PATCH v5 05/15] mm/frame-vector: Use FOLL_LONGTERM
On Sun, Nov 1, 2020 at 6:22 AM John Hubbard wrote: > > On 10/31/20 7:45 AM, Daniel Vetter wrote: > > On Sat, Oct 31, 2020 at 3:55 AM John Hubbard wrote: > >> On 10/30/20 3:08 AM, Daniel Vetter wrote: > ... > >> By removing this check from this location, and changing from > >> pin_user_pages_locked() to pin_user_pages_fast(), I *think* we end up > >> losing the check entirely. Is that intended? If so it could use a comment > >> somewhere to explain why. > > > > Yeah this wasn't intentional. I think I needed to drop the _locked > > version to prep for FOLL_LONGTERM, and figured _fast is always better. > > But I didn't realize that _fast doesn't have the vma checks, gup.c got > > me a bit confused. > > Actually, I thought that the change to _fast was a very nice touch, btw. > > > > > I'll remedy this in all the patches where this applies (because a > > VM_IO | VM_PFNMAP can point at struct page backed memory, and that > > exact use-case is what we want to stop with the unsafe_follow_pfn work > > since it wreaks things like cma or security). > > > > Aside: I do wonder whether the lack for that check isn't a problem. > > VM_IO | VM_PFNMAP generally means driver managed, which means the > > driver isn't going to consult the page pin count or anything like that > > (at least not necessarily) when revoking or moving that memory, since > > we're assuming it's totally under driver control. So if pup_fast can > > get into such a mapping, we might have a problem. > > -Daniel > > > > Yes. I don't know why that check is missing from the _fast path. > Probably just an oversight, seeing as how it's in the slow path. Maybe > the appropriate response here is to add a separate patch that adds the > check. > > I wonder if I'm overlooking something, but it certainly seems correct to > do that. You'll need the mmap_sem to get at the vma to be able to do this check. If you add that to _fast, you made it as fast as the slow one. Plus there's _fast_only due to locking recurion issues in fast-paths (I assume, I didn't check all the callers). I'm just wondering whether we have a bug somewhere with device drivers. For CMA regions we always check in try_grab_page, but for dax I'm not seeing where the checks in the _fast fastpaths are, and that all still leaves random device driver mappings behind which aren't backed by CMA but still point to something with a struct page behind it. I'm probably just missing something, but no idea what. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH/RFC] video: fbdev: atari: Fix TT High video mode
The horizontal resolution (640) for the TT High video mode (1280x960) is
definitely bogus. While fixing that, correct the timings to match the
TTM195 service manual.
Signed-off-by: Geert Uytterhoeven
---
Untested on actual hardware, hence the RFC.
---
drivers/video/fbdev/atafb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/atafb.c b/drivers/video/fbdev/atafb.c
index 198ed539366f21a3..5ecf3ec9f94cb720 100644
--- a/drivers/video/fbdev/atafb.c
+++ b/drivers/video/fbdev/atafb.c
@@ -495,8 +495,8 @@ static struct fb_videomode atafb_modedb[] __initdata = {
"tt-mid", 60, 640, 480, 31041, 120, 100, 8, 16, 140, 30,
0, FB_VMODE_NONINTERLACED | FB_VMODE_YWRAP
}, {
- /* 1280x960, 29 kHz, 60 Hz (TT high) */
- "tt-high", 57, 1280, 960, 31041, 120, 100, 8, 16, 140, 30,
+ /* 1280x960, 72 kHz, 72 Hz (TT high) */
+ "tt-high", 57, 1280, 960, 7761, 260, 60, 36, 4, 192, 4,
0, FB_VMODE_NONINTERLACED | FB_VMODE_YWRAP
},
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH/RFC v2] video: fbdev: atari: Fix TT High video mode
The horizontal resolution (640) for the TT High video mode (1280x960) is
definitely bogus. While fixing that, correct the timings to match the
TTM195 service manual.
Signed-off-by: Geert Uytterhoeven
---
Untested on actual hardware, hence the RFC.
v2:
- Use correct base.
---
drivers/video/fbdev/atafb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/atafb.c b/drivers/video/fbdev/atafb.c
index f253daa05d9d3872..5ecf3ec9f94cb720 100644
--- a/drivers/video/fbdev/atafb.c
+++ b/drivers/video/fbdev/atafb.c
@@ -495,8 +495,8 @@ static struct fb_videomode atafb_modedb[] __initdata = {
"tt-mid", 60, 640, 480, 31041, 120, 100, 8, 16, 140, 30,
0, FB_VMODE_NONINTERLACED | FB_VMODE_YWRAP
}, {
- /* 1280x960, 29 kHz, 60 Hz (TT high) */
- "tt-high", 57, 640, 960, 31041, 120, 100, 8, 16, 140, 30,
+ /* 1280x960, 72 kHz, 72 Hz (TT high) */
+ "tt-high", 57, 1280, 960, 7761, 260, 60, 36, 4, 192, 4,
0, FB_VMODE_NONINTERLACED | FB_VMODE_YWRAP
},
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH/RFC v2] video: fbdev: atari: Fix TT High video mode
Hi Geert.
On Sun, Nov 01, 2020 at 11:29:41AM +0100, Geert Uytterhoeven wrote:
> The horizontal resolution (640) for the TT High video mode (1280x960) is
> definitely bogus. While fixing that, correct the timings to match the
> TTM195 service manual.
>
> Signed-off-by: Geert Uytterhoeven
> ---
> Untested on actual hardware, hence the RFC.
>
> v2:
> - Use correct base.
> ---
> drivers/video/fbdev/atafb.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/fbdev/atafb.c b/drivers/video/fbdev/atafb.c
> index f253daa05d9d3872..5ecf3ec9f94cb720 100644
> --- a/drivers/video/fbdev/atafb.c
> +++ b/drivers/video/fbdev/atafb.c
> @@ -495,8 +495,8 @@ static struct fb_videomode atafb_modedb[] __initdata = {
> "tt-mid", 60, 640, 480, 31041, 120, 100, 8, 16, 140, 30,
> 0, FB_VMODE_NONINTERLACED | FB_VMODE_YWRAP
> }, {
> - /* 1280x960, 29 kHz, 60 Hz (TT high) */
> - "tt-high", 57, 640, 960, 31041, 120, 100, 8, 16, 140, 30,
> + /* 1280x960, 72 kHz, 72 Hz (TT high) */
> + "tt-high", 57, 1280, 960, 7761, 260, 60, 36, 4, 192, 4,
> 0, FB_VMODE_NONINTERLACED | FB_VMODE_YWRAP
Well-spotted. The change of 640 => 1280 is surely right.
I have a harder time understanding why the change of pixclock from 31041
to 7761 is correct. All other modes have a pixclock close to or equal
to 32000 - so it looks strange this one is off.
You know a tons more about all this than I do so it is properly right
but I was left wondering so please enlighten me.
Sam
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] drm/panel: ABT Y030XX067A panel support
Hi Paul. On Sun, Nov 01, 2020 at 09:31:46AM +, Paul Cercueil wrote: > Hi, > > This patchset is for adding support for the Asia Better Technology (aka. > ABT) Y030XX067A 3.0" 320x480 24-bit LCD IPS panel. > > While being 320x480 it is actually 4:3 with non-square pixels, and > requires a specific bus format, as the pixel ordering changes each line > (RGB on odd lines, GRB on even lines). > > Patch #1 adds the abt,* vendor prefix. > Patch #2 adds the abt,y030xx067a panel binding documentation. > Patch #3 adds the MEDIA_BUS_FMT_RGB888_3X8_DELTA media bus format. > Patch #4 adds the driver itself. Full series looks good. I asked google - but no hits for "Asia Better Technology". But I blame that the company has no public page - in english at least. Also the part with a DELTA media bus format looks correct, but not something I know much off. The driver itself utilises regmap_multi_reg_write() - very nice! Full series is: Reviewed-by: Sam Ravnborg I assume you will apply yourself - but please wait a few days after it have hit dri-devel to let others have the possibility to give feedback. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/4] dt-bindings: display: Add ABT Y030XX067A panel bindings
On Sun, Nov 01, 2020 at 09:31:48AM +, Paul Cercueil wrote:
> The Asia Better Technology (ABT) Y030XX067A panel is a 3.0" 320x480
> 24-bit IPS LCD panel. Its particularity is that it has non-square pixels
> (as it is 4:3 for a resolution of 320x480), and that it requires odd
> lines to be sent as RGB and even lines to be sent as GRB on its 8-bit
> bus.
>
> Signed-off-by: Paul Cercueil
> ---
> .../display/panel/abt,y030xx067a.yaml | 54 +++
> 1 file changed, 54 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/panel/abt,y030xx067a.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/panel/abt,y030xx067a.yaml
> b/Documentation/devicetree/bindings/display/panel/abt,y030xx067a.yaml
> new file mode 100644
> index ..6407e8bf45fa
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/abt,y030xx067a.yaml
> @@ -0,0 +1,54 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/panel/abt,y030xx067a.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Asia Better Technology 3.0" (320x480 pixels) 24-bit IPS LCD panel
> +
> +description: |
> + The panel must obey the rules for a SPI slave device as specified in
> + spi/spi-controller.yaml
> +
> +maintainers:
> + - Paul Cercueil
> +
> +allOf:
> + - $ref: panel-common.yaml#
> +
> +properties:
> + compatible:
> +const: abt,y030xx067a
> +
> + backlight: true
> + port: true
> + power-supply: true
> + reg: true
> + reset-gpios: true
The binding is missing:
required:
- compatible
- reg
- power-supply
- reset-gpios
- ...
additionalProperties: false
So r-b only with these added.
Sam
> +
> +examples:
> + - |
> +#include
> +
> +spi {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +panel@0 {
> +compatible = "abt,y030xx067a";
> +reg = <0>;
> +
> +spi-max-frequency = <3125000>;
> +
> +reset-gpios = <&gpe 2 GPIO_ACTIVE_LOW>;
> +
> +backlight = <&backlight>;
> +power-supply = <&vcc>;
> +
> +port {
> +panel_input: endpoint {
> +remote-endpoint = <&panel_output>;
> +};
> +};
> +};
> +};
> --
> 2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH/RFC v2] video: fbdev: atari: Fix TT High video mode
On Nov 01 2020, Sam Ravnborg wrote:
> Hi Geert.
>
> On Sun, Nov 01, 2020 at 11:29:41AM +0100, Geert Uytterhoeven wrote:
>> The horizontal resolution (640) for the TT High video mode (1280x960) is
>> definitely bogus. While fixing that, correct the timings to match the
>> TTM195 service manual.
>>
>> Signed-off-by: Geert Uytterhoeven
>> ---
>> Untested on actual hardware, hence the RFC.
>>
>> v2:
>> - Use correct base.
>> ---
>> drivers/video/fbdev/atafb.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/video/fbdev/atafb.c b/drivers/video/fbdev/atafb.c
>> index f253daa05d9d3872..5ecf3ec9f94cb720 100644
>> --- a/drivers/video/fbdev/atafb.c
>> +++ b/drivers/video/fbdev/atafb.c
>> @@ -495,8 +495,8 @@ static struct fb_videomode atafb_modedb[] __initdata = {
>> "tt-mid", 60, 640, 480, 31041, 120, 100, 8, 16, 140, 30,
>> 0, FB_VMODE_NONINTERLACED | FB_VMODE_YWRAP
>> }, {
>> -/* 1280x960, 29 kHz, 60 Hz (TT high) */
>> -"tt-high", 57, 640, 960, 31041, 120, 100, 8, 16, 140, 30,
>> +/* 1280x960, 72 kHz, 72 Hz (TT high) */
>> +"tt-high", 57, 1280, 960, 7761, 260, 60, 36, 4, 192, 4,
>> 0, FB_VMODE_NONINTERLACED | FB_VMODE_YWRAP
>
> Well-spotted. The change of 640 => 1280 is surely right.
> I have a harder time understanding why the change of pixclock from 31041
> to 7761 is correct. All other modes have a pixclock close to or equal
> to 32000 - so it looks strange this one is off.
According to the Profibuch the pixclock should be about 95000.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 49/52] PM / devfreq: tegra20: Convert to EMC_STAT driver, support interconnect and device-tree
Hi Dmitry,
This patch contains the three features as following:
1. Use interconnect interface for controlling the clock instead of
controlling it direclty
2. Use EMC_STAT instead of IMC_STAT
3. Change polling_interval and upthreshold for more fast responsiveness
I think you need to make the separate patches for each role.
But, if it is difficult or not proper to split out 1,2 roles, you can
make two patches for 1,2 and 3 roles.
Also, if you want to get more responsiveness, you could use delayed timer
instead of deferrable timer by editing the devfreq_dev_profile structure.
Regards,
Chanwoo Choi
On Mon, Oct 26, 2020 at 7:21 AM Dmitry Osipenko wrote:
>
> External (EMC) and Internal Memory Controllers (IMC) have a nearly
> identical statistics gathering module. This patch switches driver to use
> EMC_STAT instead of IMC_STAT and adds device-tree support which brings ICC
> support and makes driver to use bandwidth OPPs defined in device-tree.
>
> The previous tegra20-devfreq variant was depending on presence of both
> EMC and IMC drivers simultaneously because it wasn't apparent how to use
> EMC_STAT properly back in the day. Dependency on the IMC driver is gone
> after this patch.
>
> The older variant of the devfreq driver also isn't suitable anymore
> because EMC got support for interconnect framework and DVFS, hence
> tegra20-devfreq shouldn't drive the EMC clock directly, but use OPP
> API for issuing memory bandwidth requests.
>
> The polling interval is changed from 500ms to 30ms in order to improve
> responsiveness of the system in general and because EMC clock is now
> allowed to go lower than before since display driver supports ICC now
> as well.
>
> The parent EMC device is an MFD device now and tegra20-devfreq its
> sub-device. Devfreq driver uses SYSCON API for retrieving regmap of the
> EMC registers from the parent device.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/devfreq/Kconfig | 1 +
> drivers/devfreq/tegra20-devfreq.c | 174 +-
> 2 files changed, 75 insertions(+), 100 deletions(-)
>
> diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
> index 0ee36ae2fa79..1bd225e571df 100644
> --- a/drivers/devfreq/Kconfig
> +++ b/drivers/devfreq/Kconfig
> @@ -126,6 +126,7 @@ config ARM_TEGRA20_DEVFREQ
> depends on ARCH_TEGRA_2x_SOC || COMPILE_TEST
> depends on COMMON_CLK
> select DEVFREQ_GOV_SIMPLE_ONDEMAND
> + select MFD_SYSCON
> help
> This adds the DEVFREQ driver for the Tegra20 family of SoCs.
> It reads Memory Controller counters and adjusts the operating
> diff --git a/drivers/devfreq/tegra20-devfreq.c
> b/drivers/devfreq/tegra20-devfreq.c
> index fd801534771d..0a36b085d32a 100644
> --- a/drivers/devfreq/tegra20-devfreq.c
> +++ b/drivers/devfreq/tegra20-devfreq.c
> @@ -7,180 +7,148 @@
>
> #include
> #include
> -#include
> #include
> #include
> +#include
> #include
> #include
> #include
> +#include
> #include
>
> -#include
> -
> #include "governor.h"
>
> -#define MC_STAT_CONTROL0x90
> -#define MC_STAT_EMC_CLOCK_LIMIT0xa0
> -#define MC_STAT_EMC_CLOCKS 0xa4
> -#define MC_STAT_EMC_CONTROL0xa8
> -#define MC_STAT_EMC_COUNT 0xb8
> +#define EMC_STAT_CONTROL 0x160
> +#define EMC_STAT_LLMC_CONTROL 0x178
> +#define EMC_STAT_PWR_CLOCK_LIMIT 0x198
> +#define EMC_STAT_PWR_CLOCKS0x19c
> +#define EMC_STAT_PWR_COUNT 0x1a0
>
> -#define EMC_GATHER_CLEAR (1 << 8)
> -#define EMC_GATHER_ENABLE (3 << 8)
> +#define EMC_PWR_GATHER_CLEAR (1 << 8)
> +#define EMC_PWR_GATHER_DISABLE (2 << 8)
> +#define EMC_PWR_GATHER_ENABLE (3 << 8)
>
> struct tegra_devfreq {
> + struct devfreq_simple_ondemand_data ondemand_data;
> + struct opp_table *opp_table;
> struct devfreq *devfreq;
> struct clk *emc_clock;
> - void __iomem *regs;
> + struct regmap *rmap;
> };
>
> static int tegra_devfreq_target(struct device *dev, unsigned long *freq,
> u32 flags)
> {
> - struct tegra_devfreq *tegra = dev_get_drvdata(dev);
> - struct devfreq *devfreq = tegra->devfreq;
> struct dev_pm_opp *opp;
> - unsigned long rate;
> - int err;
> + int ret;
>
> opp = devfreq_recommended_opp(dev, freq, flags);
> - if (IS_ERR(opp))
> + if (IS_ERR(opp)) {
> + dev_err(dev, "failed to find opp for %lu Hz\n", *freq);
> return PTR_ERR(opp);
> + }
>
> - rate = dev_pm_opp_get_freq(opp);
> + ret = dev_pm_opp_set_bw(dev, opp);
> dev_pm_opp_put(opp);
>
> - err = clk_set_min_rate(tegra->emc_clock, rate);
> - if (err)
> - re
Re: [PATCH v6 51/52] PM / devfreq: tegra30: Support interconnect and OPPs from device-tree
Hi Dmitry,
On Mon, Oct 26, 2020 at 7:22 AM Dmitry Osipenko wrote:
>
> This patch moves ACTMON driver away from generating OPP table by itself,
> transitioning it to use the table which comes from device-tree. This
> change breaks compatibility with older device-trees in order to bring
> support for the interconnect framework to the driver. This is a mandatory
> change which needs to be done in order to implement interconnect-based
> memory DVFS. Users of legacy device-trees will get a message telling that
> theirs DT needs to be upgraded. Now ACTMON issues memory bandwidth request
> using dev_pm_opp_set_bw(), instead of driving EMC clock rate directly.
>
> Tested-by: Peter Geis
> Tested-by: Nicolas Chauvet
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/devfreq/tegra30-devfreq.c | 91 ---
> 1 file changed, 48 insertions(+), 43 deletions(-)
>
> diff --git a/drivers/devfreq/tegra30-devfreq.c
> b/drivers/devfreq/tegra30-devfreq.c
> index 3f732ab53573..1b0b91a71886 100644
> --- a/drivers/devfreq/tegra30-devfreq.c
> +++ b/drivers/devfreq/tegra30-devfreq.c
> @@ -19,6 +19,8 @@
> #include
> #include
>
> +#include
> +
> #include "governor.h"
>
> #define ACTMON_GLB_STATUS 0x0
> @@ -155,6 +157,7 @@ struct tegra_devfreq_device {
>
> struct tegra_devfreq {
> struct devfreq *devfreq;
> + struct opp_table*opp_table;
>
> struct reset_control*reset;
> struct clk *clock;
> @@ -612,34 +615,19 @@ static void tegra_actmon_stop(struct tegra_devfreq
> *tegra)
> static int tegra_devfreq_target(struct device *dev, unsigned long *freq,
> u32 flags)
> {
> - struct tegra_devfreq *tegra = dev_get_drvdata(dev);
> - struct devfreq *devfreq = tegra->devfreq;
> struct dev_pm_opp *opp;
> - unsigned long rate;
> - int err;
> + int ret;
>
> opp = devfreq_recommended_opp(dev, freq, flags);
> if (IS_ERR(opp)) {
> - dev_err(dev, "Failed to find opp for %lu Hz\n", *freq);
> + dev_err(dev, "failed to find opp for %lu Hz\n", *freq);
> return PTR_ERR(opp);
> }
> - rate = dev_pm_opp_get_freq(opp);
> - dev_pm_opp_put(opp);
> -
> - err = clk_set_min_rate(tegra->emc_clock, rate * KHZ);
> - if (err)
> - return err;
> -
> - err = clk_set_rate(tegra->emc_clock, 0);
> - if (err)
> - goto restore_min_rate;
>
> - return 0;
> -
> -restore_min_rate:
> - clk_set_min_rate(tegra->emc_clock, devfreq->previous_freq);
> + ret = dev_pm_opp_set_bw(dev, opp);
> + dev_pm_opp_put(opp);
>
> - return err;
> + return ret;
> }
>
> static int tegra_devfreq_get_dev_status(struct device *dev,
> @@ -655,7 +643,7 @@ static int tegra_devfreq_get_dev_status(struct device
> *dev,
> stat->private_data = tegra;
>
> /* The below are to be used by the other governors */
> - stat->current_frequency = cur_freq;
> + stat->current_frequency = cur_freq * KHZ;
I can't find any change related to the frequency unit on this patch.
Do you fix the previous bug of the frequency unit?
>
> actmon_dev = &tegra->devices[MCALL];
>
> @@ -705,7 +693,7 @@ static int tegra_governor_get_target(struct devfreq
> *devfreq,
> target_freq = max(target_freq, dev->target_freq);
> }
>
> - *freq = target_freq;
> + *freq = target_freq * KHZ;
ditto.
>
> return 0;
> }
> @@ -773,13 +761,22 @@ static struct devfreq_governor tegra_devfreq_governor =
> {
>
> static int tegra_devfreq_probe(struct platform_device *pdev)
> {
> + u32 hw_version = BIT(tegra_sku_info.soc_speedo_id);
> struct tegra_devfreq_device *dev;
> struct tegra_devfreq *tegra;
> + struct opp_table *opp_table;
> struct devfreq *devfreq;
> unsigned int i;
> long rate;
> int err;
>
> + /* legacy device-trees don't have OPP table and must be updated */
> + if (!device_property_present(&pdev->dev, "operating-points-v2")) {
> + dev_err(&pdev->dev, "OPP table not found, cannot continue\n");
> + dev_err(&pdev->dev, "please update your device tree\n");
> + return -ENODEV;
> + }
As you mentioned, it breaks the old dtb. I have no objection to improving
the driver. Instead, you need confirmation from the Devicetree maintainer.
And,
I recommend that you use dev_pm_opp_of_get_opp_desc_node(&pdev->dev)
to check whether a device contains opp-table or not.
> +
> tegra = devm_kzalloc(&pdev->dev, sizeof(*tegra), GFP_KERNEL);
> if (!tegra)
> return -ENOMEM;
> @@ -821,11 +818,29 @@ static int tegra_devfreq_probe(struct platform_device
> *pdev)
> return err;
> }
>
> + tegra->opp_table = dev_pm_opp_get_opp_table(&pdev->dev);
> +
Re: [PATCH v6 51/52] PM / devfreq: tegra30: Support interconnect and OPPs from device-tree
Hi Dmitry,
On Mon, Oct 26, 2020 at 7:22 AM Dmitry Osipenko wrote:
>
> This patch moves ACTMON driver away from generating OPP table by itself,
> transitioning it to use the table which comes from device-tree. This
> change breaks compatibility with older device-trees in order to bring
> support for the interconnect framework to the driver. This is a mandatory
> change which needs to be done in order to implement interconnect-based
> memory DVFS. Users of legacy device-trees will get a message telling that
> theirs DT needs to be upgraded. Now ACTMON issues memory bandwidth request
> using dev_pm_opp_set_bw(), instead of driving EMC clock rate directly.
>
> Tested-by: Peter Geis
> Tested-by: Nicolas Chauvet
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/devfreq/tegra30-devfreq.c | 91 ---
> 1 file changed, 48 insertions(+), 43 deletions(-)
>
> diff --git a/drivers/devfreq/tegra30-devfreq.c
> b/drivers/devfreq/tegra30-devfreq.c
> index 3f732ab53573..1b0b91a71886 100644
> --- a/drivers/devfreq/tegra30-devfreq.c
> +++ b/drivers/devfreq/tegra30-devfreq.c
> @@ -19,6 +19,8 @@
> #include
> #include
>
> +#include
> +
This patch touches the OPP. Is it related to this change?
> #include "governor.h"
>
> #define ACTMON_GLB_STATUS 0x0
> @@ -155,6 +157,7 @@ struct tegra_devfreq_device {
>
> struct tegra_devfreq {
> struct devfreq *devfreq;
> + struct opp_table*opp_table;
>
> struct reset_control*reset;
> struct clk *clock;
> @@ -612,34 +615,19 @@ static void tegra_actmon_stop(struct tegra_devfreq
> *tegra)
> static int tegra_devfreq_target(struct device *dev, unsigned long *freq,
> u32 flags)
> {
> - struct tegra_devfreq *tegra = dev_get_drvdata(dev);
> - struct devfreq *devfreq = tegra->devfreq;
> struct dev_pm_opp *opp;
> - unsigned long rate;
> - int err;
> + int ret;
>
> opp = devfreq_recommended_opp(dev, freq, flags);
> if (IS_ERR(opp)) {
> - dev_err(dev, "Failed to find opp for %lu Hz\n", *freq);
> + dev_err(dev, "failed to find opp for %lu Hz\n", *freq);
You used the 'Failed to' format in almost every error case.
Don't need to change it.
(snip)
Best Regards,
Chanwoo Choi
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] fbcon: Replace printk() with pr_*()
Replace printk() with pr_err(), pr_warn() and pr_info(). Do not split long
strings, for easier grepping. Use `__func__` whenever applicable.
fbcon_prepare_logo() has more than one callers, use "fbcon_prepare_logo:"
instead of "fbcon_init:", for less confusion.
Suggested-by: Sam Ravnborg
Signed-off-by: Peilin Ye
---
drivers/video/fbdev/core/fbcon.c | 42 +---
1 file changed, 17 insertions(+), 25 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index cef437817b0d..a3e87ab0e523 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -659,8 +659,7 @@ static void fbcon_prepare_logo(struct vc_data *vc, struct
fb_info *info,
if (logo_lines > vc->vc_bottom) {
logo_shown = FBCON_LOGO_CANSHOW;
- printk(KERN_INFO
- "fbcon_init: disable boot-logo (boot-logo bigger than
screen).\n");
+ pr_info("%s: disable boot-logo (boot-logo bigger than
screen).\n", __func__);
} else {
logo_shown = FBCON_LOGO_DRAW;
vc->vc_top = logo_lines;
@@ -785,9 +784,8 @@ static int con2fb_release_oldinfo(struct vc_data *vc,
struct fb_info *oldinfo,
ret = newinfo->fbops->fb_set_par(newinfo);
if (ret)
- printk(KERN_ERR "con2fb_release_oldinfo: "
- "detected unhandled fb_set_par error, "
- "error code %d\n", ret);
+ pr_err("%s: detected unhandled fb_set_par
error, error code %d\n",
+ __func__, ret);
}
}
@@ -806,9 +804,8 @@ static void con2fb_init_display(struct vc_data *vc, struct
fb_info *info,
ret = info->fbops->fb_set_par(info);
if (ret)
- printk(KERN_ERR "con2fb_init_display: detected "
- "unhandled fb_set_par error, "
- "error code %d\n", ret);
+ pr_err("%s: detected unhandled fb_set_par error, error
code %d\n",
+ __func__, ret);
}
ops->flags |= FBCON_FLAGS_INIT;
@@ -1137,9 +1134,8 @@ static void fbcon_init(struct vc_data *vc, int init)
ret = info->fbops->fb_set_par(info);
if (ret)
- printk(KERN_ERR "fbcon_init: detected "
- "unhandled fb_set_par error, "
- "error code %d\n", ret);
+ pr_err("%s: detected unhandled fb_set_par
error, error code %d\n",
+ __func__, ret);
}
ops->flags |= FBCON_FLAGS_INIT;
@@ -2126,9 +2122,8 @@ static int fbcon_switch(struct vc_data *vc)
ret = info->fbops->fb_set_par(info);
if (ret)
- printk(KERN_ERR "fbcon_switch: detected "
- "unhandled fb_set_par error, "
- "error code %d\n", ret);
+ pr_err("%s: detected unhandled fb_set_par
error, error code %d\n",
+ __func__, ret);
}
if (old_info != info)
@@ -2899,9 +2894,8 @@ void fbcon_remap_all(struct fb_info *info)
set_con2fb_map(i, idx, 0);
if (con_is_bound(&fb_con)) {
- printk(KERN_INFO "fbcon: Remapping primary device, "
- "fb%i, to tty %i-%i\n", idx,
- first_fb_vc + 1, last_fb_vc + 1);
+ pr_info("fbcon: Remapping primary device, fb%i, to tty %i-%i\n",
+ idx, first_fb_vc + 1, last_fb_vc + 1);
info_idx = idx;
}
console_unlock();
@@ -2914,17 +2908,16 @@ static void fbcon_select_primary(struct fb_info *info)
fb_is_primary_device(info)) {
int i;
- printk(KERN_INFO "fbcon: %s (fb%i) is primary device\n",
- info->fix.id, info->node);
+ pr_info("fbcon: %s (fb%i) is primary device\n",
+ info->fix.id, info->node);
primary_device = info->node;
for (i = first_fb_vc; i <= last_fb_vc; i++)
con2fb_map_boot[i] = primary_device;
if (con_is_bound(&fb_con)) {
- printk(KERN_INFO "fbcon: Remapping primary device, "
- "fb%i, to tty %i-%i\n", info->node,
- first_fb_vc + 1, last_fb_vc + 1);
+ pr_info("fbcon: Remapping primary device, fb%i, to tty
%i-%i\n",
+ info->node, first_fb_vc
Re: [PATCH v6 52/52] PM / devfreq: tegra30: Separate configurations per-SoC generation
Hi Dmitry,
I added the review about 'ARRAY_SIZE(tegra124_device_configs)'.
Except for this, it looks good to me.
On Mon, Oct 26, 2020 at 7:21 AM Dmitry Osipenko wrote:
>
> Previously we were using count-weight of the T124 for T30 in order to
> get EMC clock rate that was reasonable for T30. In fact the count-weight
> should be x2 times smaller on T30, but then devfreq was producing a bit
> too low EMC clock rate for ISO memory clients, like display controller
> for example.
>
> Now both Tegra ACTMON and Tegra DRM display drivers support interconnect
> framework and display driver tells to ICC what a minimum memory bandwidth
> is needed, preventing FIFO underflows. Thus, now we can use a proper
> count-weight value for Tegra30 and MC_ALL device config needs a bit more
> aggressive boosting.
>
> This patch adds a separate ACTMON driver configuration that is specific
> to Tegra30.
>
> Tested-by: Peter Geis
> Tested-by: Nicolas Chauvet
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/devfreq/tegra30-devfreq.c | 68 ---
> 1 file changed, 54 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/devfreq/tegra30-devfreq.c
> b/drivers/devfreq/tegra30-devfreq.c
> index 1b0b91a71886..95aba89eae88 100644
> --- a/drivers/devfreq/tegra30-devfreq.c
> +++ b/drivers/devfreq/tegra30-devfreq.c
> @@ -57,13 +57,6 @@
> #define ACTMON_BELOW_WMARK_WINDOW 3
> #define ACTMON_BOOST_FREQ_STEP 16000
>
> -/*
> - * Activity counter is incremented every 256 memory transactions, and each
> - * transaction takes 4 EMC clocks for Tegra124; So the COUNT_WEIGHT is
> - * 4 * 256 = 1024.
> - */
> -#define ACTMON_COUNT_WEIGHT0x400
> -
> /*
> * ACTMON_AVERAGE_WINDOW_LOG2: default value for @DEV_CTRL_K_VAL, which
> * translates to 2 ^ (K_VAL + 1). ex: 2 ^ (6 + 1) = 128
> @@ -111,7 +104,7 @@ enum tegra_actmon_device {
> MCCPU,
> };
>
> -static const struct tegra_devfreq_device_config actmon_device_configs[] = {
> +static const struct tegra_devfreq_device_config tegra124_device_configs[] = {
> {
> /* MCALL: All memory accesses (including from the CPUs) */
> .offset = 0x1c0,
> @@ -133,6 +126,28 @@ static const struct tegra_devfreq_device_config
> actmon_device_configs[] = {
> },
> };
>
> +static const struct tegra_devfreq_device_config tegra30_device_configs[] = {
> + {
> + /* MCALL: All memory accesses (including from the CPUs) */
> + .offset = 0x1c0,
> + .irq_mask = 1 << 26,
> + .boost_up_coeff = 200,
> + .boost_down_coeff = 50,
> + .boost_up_threshold = 20,
> + .boost_down_threshold = 10,
> + },
> + {
> + /* MCCPU: memory accesses from the CPUs */
> + .offset = 0x200,
> + .irq_mask = 1 << 25,
> + .boost_up_coeff = 800,
> + .boost_down_coeff = 40,
> + .boost_up_threshold = 27,
> + .boost_down_threshold = 10,
> + .avg_dependency_threshold = 16000, /* 16MHz in kHz units */
> + },
> +};
> +
> /**
> * struct tegra_devfreq_device - state specific to an ACTMON device
> *
> @@ -155,6 +170,12 @@ struct tegra_devfreq_device {
> unsigned long target_freq;
> };
>
> +struct tegra_devfreq_soc_data {
> + const struct tegra_devfreq_device_config *configs;
> + /* Weight value for count measurements */
> + unsigned int count_weight;
> +};
> +
> struct tegra_devfreq {
> struct devfreq *devfreq;
> struct opp_table*opp_table;
> @@ -171,11 +192,13 @@ struct tegra_devfreq {
> struct delayed_work cpufreq_update_work;
> struct notifier_block cpu_rate_change_nb;
>
> - struct tegra_devfreq_device
> devices[ARRAY_SIZE(actmon_device_configs)];
> + struct tegra_devfreq_device
> devices[ARRAY_SIZE(tegra124_device_configs)];
When there is one tegra_devfreq_device_config[] array, this style is not wrong.
But, after adding the specific config array for each device,
you better specify the correct array size for each case.
Even if there is no runtime error on tegra30 soc, it is not proper to use
ARRAY_SIZE(tegra124_device_configs). You can allocate the array
of tegra_devfreq_device[] or use fixed the array size (2).
>
> unsigned intirq;
>
> boolstarted;
> +
> + const struct tegra_devfreq_soc_data *soc;
> };
>
> struct tegra_actmon_emc_ratio {
> @@ -488,7 +511,7 @@ static void tegra_actmon_configure_device(struct
> tegra_devfreq *tegra,
> tegra_devfreq_update_avg_wmark(tegra, dev);
> tegra_devfreq_update_wmark(tegra, dev);
>
> - device_writel(dev, ACTMON_COUNT_WEIGHT, ACTMON_DEV_COUNT_WEIGHT);
> + device_writel(dev, tegra->soc->count_weight, ACTMON_DEV_COUNT_WEIGHT);
>
Re: [PATCH] fbcon: Replace printk() with pr_*()
On Sun, Nov 01, 2020 at 09:49:04AM -0500, Peilin Ye wrote:
> Replace printk() with pr_err(), pr_warn() and pr_info(). Do not split long
> strings, for easier grepping. Use `__func__` whenever applicable.
>
> fbcon_prepare_logo() has more than one callers, use "fbcon_prepare_logo:"
> instead of "fbcon_init:", for less confusion.
>
> Suggested-by: Sam Ravnborg
> Signed-off-by: Peilin Ye
> ---
> drivers/video/fbdev/core/fbcon.c | 42 +---
> 1 file changed, 17 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/video/fbdev/core/fbcon.c
> b/drivers/video/fbdev/core/fbcon.c
> index cef437817b0d..a3e87ab0e523 100644
> --- a/drivers/video/fbdev/core/fbcon.c
> +++ b/drivers/video/fbdev/core/fbcon.c
> @@ -659,8 +659,7 @@ static void fbcon_prepare_logo(struct vc_data *vc, struct
> fb_info *info,
>
> if (logo_lines > vc->vc_bottom) {
> logo_shown = FBCON_LOGO_CANSHOW;
> - printk(KERN_INFO
> -"fbcon_init: disable boot-logo (boot-logo bigger than
> screen).\n");
> + pr_info("%s: disable boot-logo (boot-logo bigger than
> screen).\n", __func__);
Shouldn't this be:
dev_info(info->dev, "...");
instead?
It's a driver, and you have access to the struct device that is being
worked on, so always try to use the dev_* versions of these calls
instead when ever possible.
thanks,
greg k-h
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 51/52] PM / devfreq: tegra30: Support interconnect and OPPs from device-tree
Hi Dmitry,
On Mon, Nov 2, 2020 at 12:23 AM Dmitry Osipenko wrote:
>
> 01.11.2020 17:39, Chanwoo Choi пишет:
> > Hi Dmitry,
> >
> > On Mon, Oct 26, 2020 at 7:22 AM Dmitry Osipenko wrote:
> >>
> >> This patch moves ACTMON driver away from generating OPP table by itself,
> >> transitioning it to use the table which comes from device-tree. This
> >> change breaks compatibility with older device-trees in order to bring
> >> support for the interconnect framework to the driver. This is a mandatory
> >> change which needs to be done in order to implement interconnect-based
> >> memory DVFS. Users of legacy device-trees will get a message telling that
> >> theirs DT needs to be upgraded. Now ACTMON issues memory bandwidth request
> >> using dev_pm_opp_set_bw(), instead of driving EMC clock rate directly.
> >>
> >> Tested-by: Peter Geis
> >> Tested-by: Nicolas Chauvet
> >> Signed-off-by: Dmitry Osipenko
> >> ---
> ...
> >> static int tegra_devfreq_get_dev_status(struct device *dev,
> >> @@ -655,7 +643,7 @@ static int tegra_devfreq_get_dev_status(struct device
> >> *dev,
> >> stat->private_data = tegra;
> >>
> >> /* The below are to be used by the other governors */
> >> - stat->current_frequency = cur_freq;
> >> + stat->current_frequency = cur_freq * KHZ;
> >
> > I can't find any change related to the frequency unit on this patch.
> > Do you fix the previous bug of the frequency unit?
>
> Previously, OPP entries that were generated by the driver used KHz
> units. Now, OPP entries are coming from a device-tree and they have Hz
> units. This driver operates with KHz internally, hence we need to
> convert the units now.
OK. Thanks.
>
> >>
> >> actmon_dev = &tegra->devices[MCALL];
> >>
> >> @@ -705,7 +693,7 @@ static int tegra_governor_get_target(struct devfreq
> >> *devfreq,
> >> target_freq = max(target_freq, dev->target_freq);
> >> }
> >>
> >> - *freq = target_freq;
> >> + *freq = target_freq * KHZ;
> >
> > ditto.
> >
> >>
> >> return 0;
> >> }
> >> @@ -773,13 +761,22 @@ static struct devfreq_governor
> >> tegra_devfreq_governor = {
> >>
> >> static int tegra_devfreq_probe(struct platform_device *pdev)
> >> {
> >> + u32 hw_version = BIT(tegra_sku_info.soc_speedo_id);
> >> struct tegra_devfreq_device *dev;
> >> struct tegra_devfreq *tegra;
> >> + struct opp_table *opp_table;
> >> struct devfreq *devfreq;
> >> unsigned int i;
> >> long rate;
> >> int err;
> >>
> >> + /* legacy device-trees don't have OPP table and must be updated */
> >> + if (!device_property_present(&pdev->dev, "operating-points-v2")) {
> >> + dev_err(&pdev->dev, "OPP table not found, cannot
> >> continue\n");
> >> + dev_err(&pdev->dev, "please update your device tree\n");
> >> + return -ENODEV;
> >> + }
> >
> > As you mentioned, it breaks the old dtb. I have no objection to improving
> > the driver. Instead, you need confirmation from the Devicetree maintainer.
>
> Older DTBs will continue to work, but devfreq driver won't. We already
> did this for other Tegra drivers before (CPUFREQ driver for example) and
> Rob Herring confirmed that there is no problem here.
OK.
>
> > And,
> > I recommend that you use dev_pm_opp_of_get_opp_desc_node(&pdev->dev)
> > to check whether a device contains opp-table or not.
>
> I'm not sure what are the benefits, this will make code less
> expressive/readable and we will need to add extra of_node_put(), which
> device_property_present() handles for us.
>
> Could you please give the rationale?
IMO, 'operating-points-v2' word was defined on OPP core. I think that
the external user
of OPP better to use the public helper function instead of using the
interval definition
or value of OPP core directly. Basically, I prefer the provided helper
function if there.
But, it is not critical and doesn't affect the operation. If you want
to keep, it is ok.
>
> >> +
> >> tegra = devm_kzalloc(&pdev->dev, sizeof(*tegra), GFP_KERNEL);
> >> if (!tegra)
> >> return -ENOMEM;
> >> @@ -821,11 +818,29 @@ static int tegra_devfreq_probe(struct
> >> platform_device *pdev)
> >> return err;
> >> }
> >>
> >> + tegra->opp_table = dev_pm_opp_get_opp_table(&pdev->dev);
> >> + if (IS_ERR(tegra->opp_table))
> >> + return dev_err_probe(&pdev->dev, PTR_ERR(tegra->opp_table),
> >> +"Failed to prepare OPP table\n");
> >
> > As I knew, each device can contain the opp_table on devicetree.
> > It means that opp_table has not depended to another device driver.
> > Did you see this exception case with EPROBE_DEFER error?
>
> OPP core will try to grab the clock reference for the table and it may
> cause EPROBE_DEFER. Although, it shouldn't happen here because we have
> devm_clk_get() before the get_opp_table(), hence seems the def
Re: [PATCH v6 51/52] PM / devfreq: tegra30: Support interconnect and OPPs from device-tree
Hi Dmitry,
On Mon, Nov 2, 2020 at 12:24 AM Dmitry Osipenko wrote:
>
> 01.11.2020 17:44, Chanwoo Choi пишет:
> > Hi Dmitry,
> >
> > On Mon, Oct 26, 2020 at 7:22 AM Dmitry Osipenko wrote:
> >>
> >> This patch moves ACTMON driver away from generating OPP table by itself,
> >> transitioning it to use the table which comes from device-tree. This
> >> change breaks compatibility with older device-trees in order to bring
> >> support for the interconnect framework to the driver. This is a mandatory
> >> change which needs to be done in order to implement interconnect-based
> >> memory DVFS. Users of legacy device-trees will get a message telling that
> >> theirs DT needs to be upgraded. Now ACTMON issues memory bandwidth request
> >> using dev_pm_opp_set_bw(), instead of driving EMC clock rate directly.
> >>
> >> Tested-by: Peter Geis
> >> Tested-by: Nicolas Chauvet
> >> Signed-off-by: Dmitry Osipenko
> >> ---
> >> drivers/devfreq/tegra30-devfreq.c | 91 ---
> >> 1 file changed, 48 insertions(+), 43 deletions(-)
> >>
> >> diff --git a/drivers/devfreq/tegra30-devfreq.c
> >> b/drivers/devfreq/tegra30-devfreq.c
> >> index 3f732ab53573..1b0b91a71886 100644
> >> --- a/drivers/devfreq/tegra30-devfreq.c
> >> +++ b/drivers/devfreq/tegra30-devfreq.c
> >> @@ -19,6 +19,8 @@
> >> #include
> >> #include
> >>
> >> +#include
> >> +
> >
> > This patch touches the OPP. Is it related to this change?
>
> Yes, this is needed for the dev_pm_opp_set_supported_hw().
OK.
>
> >> #include "governor.h"
> >>
> >> #define ACTMON_GLB_STATUS 0x0
> >> @@ -155,6 +157,7 @@ struct tegra_devfreq_device {
> >>
> >> struct tegra_devfreq {
> >> struct devfreq *devfreq;
> >> + struct opp_table*opp_table;
> >>
> >> struct reset_control*reset;
> >> struct clk *clock;
> >> @@ -612,34 +615,19 @@ static void tegra_actmon_stop(struct tegra_devfreq
> >> *tegra)
> >> static int tegra_devfreq_target(struct device *dev, unsigned long *freq,
> >> u32 flags)
> >> {
> >> - struct tegra_devfreq *tegra = dev_get_drvdata(dev);
> >> - struct devfreq *devfreq = tegra->devfreq;
> >> struct dev_pm_opp *opp;
> >> - unsigned long rate;
> >> - int err;
> >> + int ret;
> >>
> >> opp = devfreq_recommended_opp(dev, freq, flags);
> >> if (IS_ERR(opp)) {
> >> - dev_err(dev, "Failed to find opp for %lu Hz\n", *freq);
> >> + dev_err(dev, "failed to find opp for %lu Hz\n", *freq);
> >
> > You used the 'Failed to' format in almost every error case.
> > Don't need to change it.
> > (snip)
>
> Good catch, thanks.
--
Best Regards,
Chanwoo Choi
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 209129] HW related error message under Gnome important tab
https://bugzilla.kernel.org/show_bug.cgi?id=209129 Laszlo (laszlo.a.t...@googlemail.com) changed: What|Removed |Added Status|NEEDINFO|CLOSED Resolution|--- |INSUFFICIENT_DATA -- 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 v6 51/52] PM / devfreq: tegra30: Support interconnect and OPPs from device-tree
On Mon, Nov 2, 2020 at 12:49 AM Dmitry Osipenko wrote: > > 01.11.2020 18:44, Chanwoo Choi пишет: > >> OPP core will try to grab the clock reference for the table and it may > >> cause EPROBE_DEFER. Although, it shouldn't happen here because we have > >> devm_clk_get() before the get_opp_table(), hence seems the deferred > >> probe indeed shouldn't happen in this case. > > It is my missing point. If there, you're right. > > Could you provide the code point to check the clock reference on the OPP > > core? > > Please see it here: > > https://elixir.bootlin.com/linux/v5.10-rc1/source/drivers/opp/core.c#L1101 Thanks. It seems that if device tree node contains the any node, it is not EPROBE_DEFER because of just using "clk_get(dev, NULL)". The patch[1] used the 'dev_err_probe' for getting the "emc" clock. Do you need to check it more? [1] https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/commit/?h=devfreq-next&id=09d56d92ad25b58113f4ec677e9b1ac1e2c3072b -- Best Regards, Chanwoo Choi ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/panel: st7703: use DEFINE_DEBUGFS_ATTRIBUTE with debugfs_create_file_unsafe()
Hi,
On Fri, Oct 30, 2020 at 09:01:50AM +0530, Deepak R Varma wrote:
> Using DEFINE_DEBUGFS_ATTRIBUTE macro with debugfs_create_file_unsafe()
> function in place of the debugfs_create_file() function will make the
> file operation struct "reset" aware of the file's lifetime. Additional
> details here: https://lists.archive.carbon60.com/linux/kernel/2369498
>
> Issue reported by Coccinelle script:
> scripts/coccinelle/api/debugfs/debugfs_simple_attr.cocci
>
> Signed-off-by: Deepak R Varma
Reviewed-by: Guido Günther
Cheers,
-- Guido
> ---
> Please Note: This is a Outreachy project task patch.
>
> drivers/gpu/drm/panel/panel-sitronix-st7703.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> index c22e7c49e077..89b71d4f810d 100644
> --- a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> +++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> @@ -502,15 +502,14 @@ static int allpixelson_set(void *data, u64 val)
> return 0;
> }
>
> -DEFINE_SIMPLE_ATTRIBUTE(allpixelson_fops, NULL,
> - allpixelson_set, "%llu\n");
> +DEFINE_DEBUGFS_ATTRIBUTE(allpixelson_fops, NULL, allpixelson_set, "%llu\n");
>
> static void st7703_debugfs_init(struct st7703 *ctx)
> {
> ctx->debugfs = debugfs_create_dir(DRV_NAME, NULL);
>
> - debugfs_create_file("allpixelson", 0600, ctx->debugfs, ctx,
> - &allpixelson_fops);
> + debugfs_create_file_unsafe("allpixelson", 0600, ctx->debugfs, ctx,
> +&allpixelson_fops);
> }
>
> static void st7703_debugfs_remove(struct st7703 *ctx)
> --
> 2.25.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] fbcon: Replace printk() with pr_*()
On Sun, Nov 01, 2020 at 04:41:13PM +0100, Greg Kroah-Hartman wrote:
> On Sun, Nov 01, 2020 at 09:49:04AM -0500, Peilin Ye wrote:
> > Replace printk() with pr_err(), pr_warn() and pr_info(). Do not split long
> > strings, for easier grepping. Use `__func__` whenever applicable.
> >
> > fbcon_prepare_logo() has more than one callers, use "fbcon_prepare_logo:"
> > instead of "fbcon_init:", for less confusion.
> >
> > Suggested-by: Sam Ravnborg
> > Signed-off-by: Peilin Ye
> > ---
> > drivers/video/fbdev/core/fbcon.c | 42 +---
> > 1 file changed, 17 insertions(+), 25 deletions(-)
> >
> > diff --git a/drivers/video/fbdev/core/fbcon.c
> > b/drivers/video/fbdev/core/fbcon.c
> > index cef437817b0d..a3e87ab0e523 100644
> > --- a/drivers/video/fbdev/core/fbcon.c
> > +++ b/drivers/video/fbdev/core/fbcon.c
> > @@ -659,8 +659,7 @@ static void fbcon_prepare_logo(struct vc_data *vc,
> > struct fb_info *info,
> >
> > if (logo_lines > vc->vc_bottom) {
> > logo_shown = FBCON_LOGO_CANSHOW;
> > - printk(KERN_INFO
> > - "fbcon_init: disable boot-logo (boot-logo bigger than
> > screen).\n");
> > + pr_info("%s: disable boot-logo (boot-logo bigger than
> > screen).\n", __func__);
>
> Shouldn't this be:
> dev_info(info->dev, "...");
> instead?
>
> It's a driver, and you have access to the struct device that is being
> worked on, so always try to use the dev_* versions of these calls
> instead when ever possible.
Ah, I see. I'll fix them in v2, thank you!
Peilin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 0/3] PWM backlight interpolation adjustments
On Wed, 21 Oct 2020 22:04:42 -0700, Alexandru Stan wrote: > I was trying to adjust the brightness-levels for the trogdor boards: > https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2291209 > Like on a lot of panels, trogdor's low end needs to be cropped, > and now that we have the interpolation stuff I wanted to make use of it > and bake in even the curve that's customary to have on chromebooks. > > I found the current behavior of the pwm_bl driver a little unintuitive > and non-linear. See patch 1 for a suggested fix for this. > > [...] Applied, thanks! [1/1] ARM: dts: rockchip: Remove 0 point from brightness-levels on rk3288-veyron commit: 225c59b9235a421cdb219be5fbc13126a49714a6 Best regards, -- Heiko Stuebner ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 1/2] dt-bindings: display: himax,hx8837: Add Himax HX8837 bindings
Hi Lubomir,
Thank you for the patch.
On Fri, Oct 30, 2020 at 04:07:59AM +0100, Lubomir Rintel wrote:
> Himax HX8837 is a secondary display controller used to drive the panel
> on OLPC platforms.
>
> Signed-off-by: Lubomir Rintel
> Reviewed-by: Rob Herring
>
> ---
> Changes since v4:
> - Rob's Reviewed-by
>
> Changes since v3:
> - Moved to bindings/display/
> - Added the ports
> - Converted to YAML
> - Removed Pavel's Ack, because the changes are substantial
>
> Changes since v2:
> - s/betweend/between/
>
> Changes since v1:
> - s/load-gpio/load-gpios/
> - Use interrupt bindings instead of gpio for the IRQ
>
> .../bindings/display/bridge/himax,hx8837.yaml | 96 +++
> 1 file changed, 96 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/bridge/himax,hx8837.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/bridge/himax,hx8837.yaml
> b/Documentation/devicetree/bindings/display/bridge/himax,hx8837.yaml
> new file mode 100644
> index 0..f5b0a00f5089d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/himax,hx8837.yaml
> @@ -0,0 +1,96 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +# Copyright (C) 2018,2019,2020 Lubomir Rintel
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/bridge/himax,hx8837.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: HX8837 Display Controller Device Tree Bindings
> +
> +maintainers:
> + - Lubomir Rintel
> +
> +properties:
> + compatible:
> +const: himax,hx8837
> +
> + reg:
> +const: 0xd
> +
> + load-gpios:
> +maxItems: 1
> +description: GPIO specifier of DCON_LOAD pin (active high)
> +
> + stat-gpios:
> +minItems: 2
> +description: GPIO specifier of DCON_STAT0 and DCON_STAT1 pins (active
> high)
> +
> + interrupts:
> +maxItems: 1
> +description: Interrupt specifier of DCON_IRQ pin (edge falling)
> +
> + ports:
> +type: object
> +
> +properties:
> + port@0:
> +type: object
> +description: |
> + Video port for RGB input.
> +
> + port@1:
> +type: object
> +description: |
> + Video port connected to the panel.
> +
> +required:
> + - port@0
> + - port@1
No regulators ?
> +
> +required:
> + - compatible
> + - reg
> + - load-gpios
> + - stat-gpios
Do stat-gpios need to be mandatory ? The driver in patch 2/2 doesn't
seem to use them, could we have boards where those signals are not
connected to GPIOs ?
> + - interrupts
> + - ports
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +#include
> +#include
> +
> +i2c {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
Could you please avoid spaces or tabs at end of lines ? There are three
other occurrences below.
> +lcd-controller@d {
> +compatible = "himax,hx8837";
> +reg = <0x0d>;
> +stat-gpios = <&gpio 100 GPIO_ACTIVE_HIGH>,
> + <&gpio 101 GPIO_ACTIVE_HIGH>;
> +load-gpios = <&gpio 142 GPIO_ACTIVE_HIGH>;
> +interrupts = <&gpio 124 IRQ_TYPE_EDGE_FALLING>;
> +
> +ports {
> +#address-cells = <0x01>;
> +#size-cells = <0x00>;
> +
> +port@0 {
> +reg = <0x00>;
reg = <0> should be fine. Same below.
With thse small issues addressed,
> +dcon_rgb_in: endpoint {
> +remote-endpoint = <&lcd0_rgb_out>;
> +};
> +};
> +
> +port@1 {
> +reg = <0x01>;
> +dcon_gettl_out: endpoint {
> +remote-endpoint = <&panel_dettl_in>;
> +};
> +};
> +};
> +};
> +};
It's customary to end bindings with
...
(not sure why though, given that it seems to work find without)
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drivers/video: Fix -Wstringop-truncation in hdmi.c
Hi
Am 01.11.20 um 10:50 schrieb Sam Ravnborg:
> On Wed, Oct 21, 2020 at 02:12:41PM +0200, Thomas Zimmermann wrote:
>> Trying to copy into the string fields with strncpy() gives a warning from
>> gcc. Both fields are part of a packed HDMI header and do not require a
>> terminating \0 character.
>>
>> ../drivers/video/hdmi.c: In function 'hdmi_spd_infoframe_init':
>> ../drivers/video/hdmi.c:230:2: warning: 'strncpy' specified bound 8 equals
>> destination size [-Wstringop-truncation]
>> 230 | strncpy(frame->vendor, vendor, sizeof(frame->vendor));
>> | ^
>> ../drivers/video/hdmi.c:231:2: warning: 'strncpy' specified bound 16 equals
>> destination size [-Wstringop-truncation]
>> 231 | strncpy(frame->product, product, sizeof(frame->product));
>> | ^~~~
>>
>> Just use memcpy() instead.
>>
>> Signed-off-by: Thomas Zimmermann
> I assume vendor is guaranteed to be 0-termindated.
It's a fixed-length field in the protocol. There's similar code in
radeon IIRC. So it would be nice to disable the warning in these cases.
But that's probably to much fiddling.
> Reviewed-by: Sam Ravnborg
Thanks.
Best regards
Thomas
>
>> ---
>> drivers/video/hdmi.c | 8 ++--
>> 1 file changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
>> index b7a1d6fae90d..1e4cb63d0d11 100644
>> --- a/drivers/video/hdmi.c
>> +++ b/drivers/video/hdmi.c
>> @@ -221,14 +221,18 @@ EXPORT_SYMBOL(hdmi_avi_infoframe_pack);
>> int hdmi_spd_infoframe_init(struct hdmi_spd_infoframe *frame,
>> const char *vendor, const char *product)
>> {
>> +size_t len;
>> +
>> memset(frame, 0, sizeof(*frame));
>>
>> frame->type = HDMI_INFOFRAME_TYPE_SPD;
>> frame->version = 1;
>> frame->length = HDMI_SPD_INFOFRAME_SIZE;
>>
>> -strncpy(frame->vendor, vendor, sizeof(frame->vendor));
>> -strncpy(frame->product, product, sizeof(frame->product));
>> +len = strlen(vendor);
>> +memcpy(frame->vendor, vendor, min(len, sizeof(frame->vendor)));
>> +len = strlen(product);
>> +memcpy(frame->product, product, min(len, sizeof(frame->product)));
>>
>> return 0;
>> }
>> --
>> 2.28.0
>>
>> ___
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_0x680DC11D530B7A23.asc
Description: application/pgp-keys
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv7 4/7] drm/msm/a6xx: Add support for using system cache(LLC)
From: Sharat Masetty
The last level system cache can be partitioned to 32 different
slices of which GPU has two slices preallocated. One slice is
used for caching GPU buffers and the other slice is used for
caching the GPU SMMU pagetables. This talks to the core system
cache driver to acquire the slice handles, configure the SCID's
to those slices and activates and deactivates the slices upon
GPU power collapse and restore.
Some support from the IOMMU driver is also needed to make use
of the system cache to set the right TCR attributes. GPU then
has the ability to override a few cacheability parameters which
it does to override write-allocate to write-no-allocate as the
GPU hardware does not benefit much from it.
DOMAIN_ATTR_SYS_CACHE is another domain level attribute used by the
IOMMU driver to set the right attributes to cache the hardware
pagetables into the system cache.
Signed-off-by: Sharat Masetty
[saiprakash.ranjan: fix to set attr before device attach to iommu and rebase]
Signed-off-by: Sai Prakash Ranjan
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 83 +
drivers/gpu/drm/msm/adreno/a6xx_gpu.h | 4 ++
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 17 +
3 files changed, 104 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 948f3656c20c..95c98c642876 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -8,7 +8,9 @@
#include "a6xx_gpu.h"
#include "a6xx_gmu.xml.h"
+#include
#include
+#include
#define GPU_PAS_ID 13
@@ -1022,6 +1024,79 @@ static irqreturn_t a6xx_irq(struct msm_gpu *gpu)
return IRQ_HANDLED;
}
+static void a6xx_llc_rmw(struct a6xx_gpu *a6xx_gpu, u32 reg, u32 mask, u32 or)
+{
+ return msm_rmw(a6xx_gpu->llc_mmio + (reg << 2), mask, or);
+}
+
+static void a6xx_llc_write(struct a6xx_gpu *a6xx_gpu, u32 reg, u32 value)
+{
+ return msm_writel(value, a6xx_gpu->llc_mmio + (reg << 2));
+}
+
+static void a6xx_llc_deactivate(struct a6xx_gpu *a6xx_gpu)
+{
+ llcc_slice_deactivate(a6xx_gpu->llc_slice);
+ llcc_slice_deactivate(a6xx_gpu->htw_llc_slice);
+}
+
+static void a6xx_llc_activate(struct a6xx_gpu *a6xx_gpu)
+{
+ u32 cntl1_regval = 0;
+
+ if (IS_ERR(a6xx_gpu->llc_mmio))
+ return;
+
+ if (!llcc_slice_activate(a6xx_gpu->llc_slice)) {
+ u32 gpu_scid = llcc_get_slice_id(a6xx_gpu->llc_slice);
+
+ gpu_scid &= 0x1f;
+ cntl1_regval = (gpu_scid << 0) | (gpu_scid << 5) | (gpu_scid <<
10) |
+ (gpu_scid << 15) | (gpu_scid << 20);
+ }
+
+ if (!llcc_slice_activate(a6xx_gpu->htw_llc_slice)) {
+ u32 gpuhtw_scid = llcc_get_slice_id(a6xx_gpu->htw_llc_slice);
+
+ gpuhtw_scid &= 0x1f;
+ cntl1_regval |= FIELD_PREP(GENMASK(29, 25), gpuhtw_scid);
+ }
+
+ if (cntl1_regval) {
+ /*
+* Program the slice IDs for the various GPU blocks and GPU MMU
+* pagetables
+*/
+ a6xx_llc_write(a6xx_gpu, REG_A6XX_CX_MISC_SYSTEM_CACHE_CNTL_1,
cntl1_regval);
+
+ /*
+* Program cacheability overrides to not allocate cache lines on
+* a write miss
+*/
+ a6xx_llc_rmw(a6xx_gpu, REG_A6XX_CX_MISC_SYSTEM_CACHE_CNTL_0,
0xF, 0x03);
+ }
+}
+
+static void a6xx_llc_slices_destroy(struct a6xx_gpu *a6xx_gpu)
+{
+ llcc_slice_putd(a6xx_gpu->llc_slice);
+ llcc_slice_putd(a6xx_gpu->htw_llc_slice);
+}
+
+static void a6xx_llc_slices_init(struct platform_device *pdev,
+ struct a6xx_gpu *a6xx_gpu)
+{
+ a6xx_gpu->llc_mmio = msm_ioremap(pdev, "cx_mem", "gpu_cx");
+ if (IS_ERR(a6xx_gpu->llc_mmio))
+ return;
+
+ a6xx_gpu->llc_slice = llcc_slice_getd(LLCC_GPU);
+ a6xx_gpu->htw_llc_slice = llcc_slice_getd(LLCC_GPUHTW);
+
+ if (IS_ERR(a6xx_gpu->llc_slice) && IS_ERR(a6xx_gpu->htw_llc_slice))
+ a6xx_gpu->llc_mmio = ERR_PTR(-EINVAL);
+}
+
static int a6xx_pm_resume(struct msm_gpu *gpu)
{
struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
@@ -1038,6 +1113,8 @@ static int a6xx_pm_resume(struct msm_gpu *gpu)
msm_gpu_resume_devfreq(gpu);
+ a6xx_llc_activate(a6xx_gpu);
+
return 0;
}
@@ -1048,6 +1125,8 @@ static int a6xx_pm_suspend(struct msm_gpu *gpu)
trace_msm_gpu_suspend(0);
+ a6xx_llc_deactivate(a6xx_gpu);
+
devfreq_suspend_device(gpu->devfreq.devfreq);
return a6xx_gmu_stop(a6xx_gpu);
@@ -1091,6 +1170,8 @@ static void a6xx_destroy(struct msm_gpu *gpu)
drm_gem_object_put(a6xx_gpu->shadow_bo);
}
+ a6xx_llc_slices_destroy(a6xx_gpu);
+
a6xx_gmu_remove(a6xx_gpu);
adreno_gpu_cleanup(adreno_gpu);
@@ -1209,6 +1290,8 @@ struct msm_gpu *a6xx_gpu_init(struct drm_device *
[PATCH] drm/hisilicon: Remove redundant null check
drm_irq_uninstall can handle the case where dev->irq_enable is false, so Remove redundant null check. Signed-off-by: Tian Tao --- drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c index 0c1b40d..b71589b1 100644 --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c @@ -246,13 +246,13 @@ static int hibmc_unload(struct drm_device *dev) drm_atomic_helper_shutdown(dev); - if (dev->irq_enabled) - drm_irq_uninstall(dev); - + drm_irq_uninstall(dev); pci_disable_msi(dev->pdev); + hibmc_kms_fini(priv); hibmc_mm_fini(priv); dev->dev_private = NULL; + return 0; } -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge: tpd12s015: Fix irq registering in tpd12s015_probe
On 2020/10/31 15:19, Sam Ravnborg wrote:
> Hi YueHaibing
>
> Thanks for the fix. Appreciated but please update as per comments below.
>
> On Sat, Oct 31, 2020 at 11:16:48AM +0800, YueHaibing wrote:
>> gpiod_to_irq() return negative value in case of error,
>> the existing code handle negative error codes wrongly.
>>
>> Fixes: cff5e6f7e83f ("drm/bridge: Add driver for the TI TPD12S015 HDMI level
>> shifter")
>> Signed-off-by: YueHaibing
>> ---
>> drivers/gpu/drm/bridge/ti-tpd12s015.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/ti-tpd12s015.c
>> b/drivers/gpu/drm/bridge/ti-tpd12s015.c
>> index 514cbf0eac75..a18d5197c16c 100644
>> --- a/drivers/gpu/drm/bridge/ti-tpd12s015.c
>> +++ b/drivers/gpu/drm/bridge/ti-tpd12s015.c
>> @@ -160,7 +160,7 @@ static int tpd12s015_probe(struct platform_device *pdev)
>>
>> /* Register the IRQ if the HPD GPIO is IRQ-capable. */
>> tpd->hpd_irq = gpiod_to_irq(tpd->hpd_gpio);
>> -if (tpd->hpd_irq) {
>> +if (tpd->hpd_irq > 0) {
>> ret = devm_request_threaded_irq(&pdev->dev, tpd->hpd_irq, NULL,
>> tpd12s015_hpd_isr,
>> IRQF_TRIGGER_RISING |
>
> The current implmentation will skip devm_request_threaded_irq() in case
> or error - but continue with the rest of the function. So the
> driver fails to return an error code.
>
> In case of error (negative value) then return early with that error
Agree, will resubmit.
> value. If gpiod_to_irq() returns 0 assume this is a valid irq and let
> the code continue.
gpiod_to_irq() never returns 0, so no need check this.
>
> Please fix and re-submit - or tell me if I am mistaken.
>
> Sam
> .
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm/dp: skip checking LINK_STATUS_UPDATED bit
On 2020-10-20 15:15, Stephen Boyd wrote:
Quoting Kuogee Hsieh (2020-10-20 09:59:59)
No need to check LINK_STATuS_UPDATED bit before
LINK_STATUS_UPDATED?
return 6 bytes of link status during link training.
Why?
This patch also fix phy compliance test link rate
conversion error.
How?
Signed-off-by: Kuogee Hsieh
---
Any Fixes: tag?
drivers/gpu/drm/msm/dp/dp_ctrl.c | 20 ++--
drivers/gpu/drm/msm/dp/dp_link.c | 24 +++-
2 files changed, 17 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c
b/drivers/gpu/drm/msm/dp/dp_ctrl.c
index 6bdaec778c4c..76e891c91c6e 100644
--- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
+++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
@@ -1061,23 +1061,15 @@ static bool dp_ctrl_train_pattern_set(struct
dp_ctrl_private *ctrl,
static int dp_ctrl_read_link_status(struct dp_ctrl_private *ctrl,
u8 *link_status)
{
- int len = 0;
- u32 const offset = DP_LANE_ALIGN_STATUS_UPDATED -
DP_LANE0_1_STATUS;
- u32 link_status_read_max_retries = 100;
-
- while (--link_status_read_max_retries) {
- len = drm_dp_dpcd_read_link_status(ctrl->aux,
- link_status);
- if (len != DP_LINK_STATUS_SIZE) {
- DRM_ERROR("DP link status read failed, err:
%d\n", len);
- return len;
- }
+ int ret = 0, len;
- if (!(link_status[offset] & DP_LINK_STATUS_UPDATED))
- return 0;
+ len = drm_dp_dpcd_read_link_status(ctrl->aux, link_status);
+ if (len != DP_LINK_STATUS_SIZE) {
+ DRM_ERROR("DP link status read failed, err: %d\n",
len);
+ ret = len;
Could this be positive if the len is greater than 0 but not
DP_LINK_STATUS_SIZE? Maybe the check should be len < 0? We certainly
don't want to return some smaller size from this function, right?
no, it should be exactly the byte number requested to read.
otherwise, it should be failed and will re read at next run.
}
- return -ETIMEDOUT;
+ return ret;
}
static int dp_ctrl_link_train_1(struct dp_ctrl_private *ctrl,
diff --git a/drivers/gpu/drm/msm/dp/dp_link.c
b/drivers/gpu/drm/msm/dp/dp_link.c
index c811da515fb3..58d65daae3b3 100644
--- a/drivers/gpu/drm/msm/dp/dp_link.c
+++ b/drivers/gpu/drm/msm/dp/dp_link.c
@@ -773,7 +773,8 @@ static int
dp_link_process_link_training_request(struct dp_link_private *link)
link->request.test_lane_count);
link->dp_link.link_params.num_lanes =
link->request.test_lane_count;
- link->dp_link.link_params.rate = link->request.test_link_rate;
+ link->dp_link.link_params.rate =
+
drm_dp_bw_code_to_link_rate(link->request.test_link_rate);
Why are we storing bw_code in test_link_rate? This looks very
confusing.
Test_link_rate contains link rate from dpcd read. it need to be convert
to real
rate by timing 2.7Mb before start phy compliance test.
return 0;
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm/dsi: save PLL registers across first PHY reset
Hello, On 07/10/2020 03:10, benl-kernelpatc...@squareup.com wrote: From: Benjamin Li Take advantage of previously-added support for persisting PLL registers across DSI PHY disable/enable cycles (see 328e1a6 'drm/msm/dsi: Save/Restore PLL status across PHY reset') to support persisting across the very first DSI PHY enable at boot. Interesting enough, this breaks exactly on 8016. On DB410c with latest bootloader and w/o splash screen this patch causes boot freeze. Without this patch the board would successfully boot with display routed to HDMI. The bootloader may have left the PLL registers in a non-default state. For example, for dsi_pll_28nm.c on 8x16/8x39, the byte clock mux's power-on reset configuration is to bypass DIV1, but depending on bandwidth requirements[1] the bootloader may have set the DIV1 path. When the byte clock mux is registered with the generic clock framework at probe time, the framework reads & caches the value of the mux bit field (the initial clock parent). After PHY enable, when clk_set_rate is called on the byte clock, the framework assumes there is no need to reparent, and doesn't re-write the mux bit field. But PHY enable resets PLL registers, so the mux bit field actually silently reverted to the DIV1 bypass path. This causes the byte clock to be off by a factor of e.g. 2 for our tested WXGA panel. The above issue manifests as the display not working and a constant stream of FIFO/LP0 contention errors. [1] The specific requirement for triggering the DIV1 path (and thus this issue) on 28nm is a panel with pixel clock <116.7MHz (one-third the minimum VCO setting). FHD/1080p (~145MHz) is fine, WXGA/1280x800 (~75MHz) is not. Signed-off-by: Benjamin Li --- drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 16 1 file changed, 16 insertions(+) diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c index 009f5b843dd1..139b4a5aaf86 100644 --- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c +++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c @@ -621,6 +621,22 @@ static int dsi_phy_driver_probe(struct platform_device *pdev) phy->pll = NULL; } + /* +* As explained in msm_dsi_phy_enable, resetting the DSI PHY (as done +* in dsi_mgr_phy_enable) silently changes its PLL registers to power-on +* defaults, but the generic clock framework manages and caches several +* of the PLL registers. It initializes these caches at registration +* time via register read. +* +* As a result, we need to save DSI PLL registers once at probe in order +* for the first call to msm_dsi_phy_enable to successfully bring PLL +* registers back in line with what the generic clock framework expects. +* +* Subsequent PLL restores during msm_dsi_phy_enable will always be +* paired with PLL saves in msm_dsi_phy_disable. +*/ + msm_dsi_pll_save_state(phy->pll); + dsi_phy_disable_resource(phy); platform_set_drvdata(pdev, phy); -- With best wishes Dmitry ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv7 5/7] drm/msm/a6xx: Add support for using system cache on MMU500 based targets
From: Jordan Crouse
This is an extension to the series [1] to enable the System Cache (LLC) for
Adreno a6xx targets.
GPU targets with an MMU-500 attached have a slightly different process for
enabling system cache. Use the compatible string on the IOMMU phandle
to see if an MMU-500 is attached and modify the programming sequence
accordingly.
[1] https://patchwork.freedesktop.org/series/83037/
Signed-off-by: Jordan Crouse
Signed-off-by: Sai Prakash Ranjan
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 46 +--
drivers/gpu/drm/msm/adreno/a6xx_gpu.h | 1 +
2 files changed, 37 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 95c98c642876..3f8b92da8cba 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -1042,6 +1042,8 @@ static void a6xx_llc_deactivate(struct a6xx_gpu *a6xx_gpu)
static void a6xx_llc_activate(struct a6xx_gpu *a6xx_gpu)
{
+ struct adreno_gpu *adreno_gpu = &a6xx_gpu->base;
+ struct msm_gpu *gpu = &adreno_gpu->base;
u32 cntl1_regval = 0;
if (IS_ERR(a6xx_gpu->llc_mmio))
@@ -1055,11 +1057,17 @@ static void a6xx_llc_activate(struct a6xx_gpu *a6xx_gpu)
(gpu_scid << 15) | (gpu_scid << 20);
}
+ /*
+* For targets with a MMU500, activate the slice but don't program the
+* register. The XBL will take care of that.
+*/
if (!llcc_slice_activate(a6xx_gpu->htw_llc_slice)) {
- u32 gpuhtw_scid = llcc_get_slice_id(a6xx_gpu->htw_llc_slice);
+ if (!a6xx_gpu->have_mmu500) {
+ u32 gpuhtw_scid =
llcc_get_slice_id(a6xx_gpu->htw_llc_slice);
- gpuhtw_scid &= 0x1f;
- cntl1_regval |= FIELD_PREP(GENMASK(29, 25), gpuhtw_scid);
+ gpuhtw_scid &= 0x1f;
+ cntl1_regval |= FIELD_PREP(GENMASK(29, 25),
gpuhtw_scid);
+ }
}
if (cntl1_regval) {
@@ -1067,13 +1075,20 @@ static void a6xx_llc_activate(struct a6xx_gpu *a6xx_gpu)
* Program the slice IDs for the various GPU blocks and GPU MMU
* pagetables
*/
- a6xx_llc_write(a6xx_gpu, REG_A6XX_CX_MISC_SYSTEM_CACHE_CNTL_1,
cntl1_regval);
-
- /*
-* Program cacheability overrides to not allocate cache lines on
-* a write miss
-*/
- a6xx_llc_rmw(a6xx_gpu, REG_A6XX_CX_MISC_SYSTEM_CACHE_CNTL_0,
0xF, 0x03);
+ if (a6xx_gpu->have_mmu500)
+ gpu_rmw(gpu, REG_A6XX_GBIF_SCACHE_CNTL1, GENMASK(24, 0),
+ cntl1_regval);
+ else {
+ a6xx_llc_write(a6xx_gpu,
+ REG_A6XX_CX_MISC_SYSTEM_CACHE_CNTL_1,
cntl1_regval);
+
+ /*
+* Program cacheability overrides to not allocate cache
+* lines on a write miss
+*/
+ a6xx_llc_rmw(a6xx_gpu,
+ REG_A6XX_CX_MISC_SYSTEM_CACHE_CNTL_0, 0xF,
0x03);
+ }
}
}
@@ -1086,10 +1101,21 @@ static void a6xx_llc_slices_destroy(struct a6xx_gpu
*a6xx_gpu)
static void a6xx_llc_slices_init(struct platform_device *pdev,
struct a6xx_gpu *a6xx_gpu)
{
+ struct device_node *phandle;
+
a6xx_gpu->llc_mmio = msm_ioremap(pdev, "cx_mem", "gpu_cx");
if (IS_ERR(a6xx_gpu->llc_mmio))
return;
+ /*
+* There is a different programming path for targets with an mmu500
+* attached, so detect if that is the case
+*/
+ phandle = of_parse_phandle(pdev->dev.of_node, "iommus", 0);
+ a6xx_gpu->have_mmu500 = (phandle &&
+ of_device_is_compatible(phandle, "arm,mmu-500"));
+ of_node_put(phandle);
+
a6xx_gpu->llc_slice = llcc_slice_getd(LLCC_GPU);
a6xx_gpu->htw_llc_slice = llcc_slice_getd(LLCC_GPUHTW);
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
index 9e6079af679c..e793d329e77b 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
@@ -32,6 +32,7 @@ struct a6xx_gpu {
void __iomem *llc_mmio;
void *llc_slice;
void *htw_llc_slice;
+ bool have_mmu500;
};
#define to_a6xx_gpu(x) container_of(x, struct a6xx_gpu, base)
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
WARNING in vkms_vblank_simulate (2)
Hello, syzbot found the following issue on: HEAD commit:3f267ec6 Add linux-next specific files for 20201029 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=170739d250 kernel config: https://syzkaller.appspot.com/x/.config?x=7f00c6dd47ae4c2c dashboard link: https://syzkaller.appspot.com/bug?extid=4fc21a003c8332eb0bdd compiler: gcc (GCC) 10.1.0-syz 20200507 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=16e83ef250 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=159f01f250 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+4fc21a003c8332eb0...@syzkaller.appspotmail.com [ cut here ] WARNING: CPU: 0 PID: 34 at drivers/gpu/drm/vkms/vkms_crtc.c:21 vkms_vblank_simulate+0x31e/0x3b0 drivers/gpu/drm/vkms/vkms_crtc.c:21 Modules linked in: CPU: 0 PID: 34 Comm: kauditd Not tainted 5.10.0-rc1-next-20201029-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:vkms_vblank_simulate+0x31e/0x3b0 drivers/gpu/drm/vkms/vkms_crtc.c:21 Code: 85 9e 00 00 00 48 8b 95 b8 01 00 00 4c 89 e1 bf 02 00 00 00 48 c7 c6 20 e6 b3 89 e8 0c 91 ef ff e9 e5 fe ff ff e8 72 e0 34 fd <0f> 0b e9 88 fd ff ff e8 e6 7b 76 fd e9 11 fe ff ff 4c 89 ef e8 d9 RSP: 0018:c9007dc0 EFLAGS: 00010046 RAX: 00010001 RBX: 888143c91e48 RCX: 843b47c3 RDX: 888010fa RSI: 843b4a3e RDI: 0007 RBP: 0002 R08: R09: R10: 0001 R11: R12: 888143c90d40 R13: 00fe4c00 R14: 843b4720 R15: dc00 FS: () GS:8880b9e0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7fff2c859fb4 CR3: 13fee000 CR4: 001506f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: __run_hrtimer kernel/time/hrtimer.c:1519 [inline] __hrtimer_run_queues+0x693/0xea0 kernel/time/hrtimer.c:1583 hrtimer_interrupt+0x334/0x940 kernel/time/hrtimer.c:1645 local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1080 [inline] __sysvec_apic_timer_interrupt+0x146/0x540 arch/x86/kernel/apic/apic.c:1097 asm_call_irq_on_stack+0xf/0x20 __run_sysvec_on_irqstack arch/x86/include/asm/irq_stack.h:37 [inline] run_sysvec_on_irqstack_cond arch/x86/include/asm/irq_stack.h:89 [inline] sysvec_apic_timer_interrupt+0xbd/0x100 arch/x86/kernel/apic/apic.c:1091 asm_sysvec_apic_timer_interrupt+0x12/0x20 arch/x86/include/asm/idtentry.h:631 RIP: 0010:console_unlock+0x7b6/0xbb0 kernel/printk/printk.c:2509 Code: 60 8f 24 8b e8 6b 8d fd ff e8 f6 3b 00 00 31 ff 4c 89 ee e8 2c 76 17 00 4d 85 ed 0f 85 3a 02 00 00 e8 ae 7d 17 00 ff 34 24 9d <8b> 5c 24 34 31 ff 89 de e8 ed 75 17 00 85 db 0f 84 eb f9 ff ff e8 RSP: 0018:c9dcfaf0 EFLAGS: 0293 RAX: RBX: RCX: 8155b067 RDX: 888010fa RSI: 8158ad02 RDI: RBP: R08: 0001 R09: 8ebb4667 R10: fbfff1d768cc R11: R12: 84a24b90 R13: 0200 R14: dc00 R15: c9dcfb50 vprintk_emit+0x1a1/0x4c0 kernel/printk/printk.c:2028 vprintk_func+0x8d/0x1e0 kernel/printk/printk_safe.c:393 printk+0xba/0xed kernel/printk/printk.c:2076 kauditd_printk_skb kernel/audit.c:538 [inline] kauditd_hold_skb.cold+0x41/0x50 kernel/audit.c:571 kauditd_send_queue+0x19d/0x210 kernel/audit.c:734 kauditd_thread+0x7f0/0xb80 kernel/audit.c:860 kthread+0x3af/0x4a0 kernel/kthread.c:292 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:296 --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. syzbot can test patches for this issue, for details see: https://goo.gl/tpsmEJ#testing-patches ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/4] dt-bindings: display: Add ABT Y030XX067A panel bindings
The Asia Better Technology (ABT) Y030XX067A panel is a 3.0" 320x480
24-bit IPS LCD panel. Its particularity is that it has non-square pixels
(as it is 4:3 for a resolution of 320x480), and that it requires odd
lines to be sent as RGB and even lines to be sent as GRB on its 8-bit
bus.
Signed-off-by: Paul Cercueil
---
.../display/panel/abt,y030xx067a.yaml | 54 +++
1 file changed, 54 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/abt,y030xx067a.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/abt,y030xx067a.yaml
b/Documentation/devicetree/bindings/display/panel/abt,y030xx067a.yaml
new file mode 100644
index ..6407e8bf45fa
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/abt,y030xx067a.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/abt,y030xx067a.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Asia Better Technology 3.0" (320x480 pixels) 24-bit IPS LCD panel
+
+description: |
+ The panel must obey the rules for a SPI slave device as specified in
+ spi/spi-controller.yaml
+
+maintainers:
+ - Paul Cercueil
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+const: abt,y030xx067a
+
+ backlight: true
+ port: true
+ power-supply: true
+ reg: true
+ reset-gpios: true
+
+examples:
+ - |
+#include
+
+spi {
+#address-cells = <1>;
+#size-cells = <0>;
+
+panel@0 {
+compatible = "abt,y030xx067a";
+reg = <0>;
+
+spi-max-frequency = <3125000>;
+
+reset-gpios = <&gpe 2 GPIO_ACTIVE_LOW>;
+
+backlight = <&backlight>;
+power-supply = <&vcc>;
+
+port {
+panel_input: endpoint {
+remote-endpoint = <&panel_output>;
+};
+};
+};
+};
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] opp: Add devres wrapper for dev_pm_opp_set_prop_name
On Wed, Oct 28, 2020 at 10:46 PM Viresh Kumar wrote: > > On 28-10-20, 19:02, Frank Lee wrote: > > On Wed, Oct 28, 2020 at 6:29 PM Viresh Kumar > > wrote: > > > > > > On 12-10-20, 21:55, Frank Lee wrote: > > > > From: Yangtao Li > > > > > > > > Add devres wrapper for dev_pm_opp_set_prop_name() to simplify driver > > > > code. > > > > > > > > Signed-off-by: Yangtao Li > > > > Signed-off-by: Yangtao Li > > > > --- > > > > drivers/opp/core.c | 39 +++ > > > > include/linux/pm_opp.h | 6 ++ > > > > 2 files changed, 45 insertions(+) > > > > > > On a second thought I am looking at dropping this one as you haven't > > > added any users yet and I am afraid it will stay unused. > > > > Now it looks like that dev_pm_opp_set_prop_name() is used relatively less. > > Maybe we can wait until a caller, and then pick up the patch. > > I am even wondering if we should be adding any of the devm_* helpers > for now to be honest. Even for the other one we have only one user. > Them major user of the OPP core is the CPU subsystem and it is never > going to use these devm_* helpers as the CPU device doesn't get bound > to a driver, it is rather a fake platform device which gets the > cpufreq drivers probed. So the only users of these devm_* helpers is > going to be non-CPU devices. Considering that we have only one user > right now, it may be better to just fix it instead of adding any of > the devm_* helpers. GPU is also a relatively large number of opp consumers. Most of the time, the dev_pm_opp_set_* functions will only be set once. If don't need the driver to dynamically manage and release the opp, it may be OK？ Yangtao ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
KASAN: vmalloc-out-of-bounds Write in drm_fb_helper_dirty_work (3)
Hello, syzbot found the following issue on: HEAD commit:4525c878 scsi: qla2xxx: remove incorrect sparse #ifdef git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=1411f30850 kernel config: https://syzkaller.appspot.com/x/.config?x=a5c844e56cc50cdb dashboard link: https://syzkaller.appspot.com/bug?extid=58a9f453b90c4bfab018 compiler: gcc (GCC) 10.1.0-syz 20200507 Unfortunately, I don't have any reproducer for this issue yet. IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+58a9f453b90c4bfab...@syzkaller.appspotmail.com == BUG: KASAN: vmalloc-out-of-bounds in memcpy include/linux/string.h:399 [inline] BUG: KASAN: vmalloc-out-of-bounds in drm_fb_helper_dirty_blit_real drivers/gpu/drm/drm_fb_helper.c:403 [inline] BUG: KASAN: vmalloc-out-of-bounds in drm_fb_helper_dirty_work+0x42e/0x810 drivers/gpu/drm/drm_fb_helper.c:435 Write of size 4096 at addr c90009bd1000 by task kworker/2:0/23 CPU: 2 PID: 23 Comm: kworker/2:0 Not tainted 5.10.0-rc1-syzkaller #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 Workqueue: events drm_fb_helper_dirty_work Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x107/0x163 lib/dump_stack.c:118 print_address_description.constprop.0.cold+0x5/0x497 mm/kasan/report.c:385 __kasan_report mm/kasan/report.c:545 [inline] kasan_report.cold+0x1f/0x37 mm/kasan/report.c:562 check_memory_region_inline mm/kasan/generic.c:186 [inline] check_memory_region+0x13d/0x180 mm/kasan/generic.c:192 memcpy+0x39/0x60 mm/kasan/common.c:106 memcpy include/linux/string.h:399 [inline] drm_fb_helper_dirty_blit_real drivers/gpu/drm/drm_fb_helper.c:403 [inline] drm_fb_helper_dirty_work+0x42e/0x810 drivers/gpu/drm/drm_fb_helper.c:435 process_one_work+0x933/0x15a0 kernel/workqueue.c:2272 worker_thread+0x64c/0x1120 kernel/workqueue.c:2418 kthread+0x3af/0x4a0 kernel/kthread.c:292 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:296 Memory state around the buggy address: c90009bd0f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c90009bd0f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >c90009bd1000: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ c90009bd1080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 c90009bd1100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 == --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] opp: Add devres wrapper for dev_pm_opp_set_prop_name
On 30-10-20, 19:19, Frank Lee wrote: > GPU is also a relatively large number of opp consumers. I was talking about the number of files or locations from which this routine (the devm_* variant) is going to get called. And it is one right now. And I don't see if any of the other callers are going to use it for now. > Most of the time, the dev_pm_opp_set_* functions will only be set once. Right. > If don't need the driver to dynamically manage and release the opp, it > may be OK？ Every call to dev_pm_opp_set_supported_hw() increases the ref count of the OPP table and if it isn't balanced with a call to dev_pm_opp_put_supported_hw(), then the OPP table will never get freed. So if the driver is a module and ends up creating an OPP table every time, then this will lead to leakage. The best way to fix this is by calling dev_pm_opp_put_supported_hw() from the right place and then we are good. -- viresh ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/msm/dp: skip checking LINK_STATUS_UPDATED bit
Some dongle will not clear LINK_STATUS_UPDATED bit after
DPCD read which cause link training failed. This patch
just read 6 bytes of DPCD link status from sink and return
without checking LINK_STATUS_UPDATED bit.
Link rate read back from sink need to be convert into
really rate by timing 2.7Mb. For example 0x0A is equivalent
to 2.7Gb. This patch also convert link rate correctly to fix
phy compliance test link rate error.
Chanegs in V2:
-- revise commit text
Fixes: fd4a29bed29b (drm/msm/dp: DisplayPort PHY compliance tests fixup)
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_ctrl.c | 20 ++--
drivers/gpu/drm/msm/dp/dp_link.c | 24 +++-
2 files changed, 17 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c b/drivers/gpu/drm/msm/dp/dp_ctrl.c
index 904698dfc7f7..844ba756a2c6 100644
--- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
+++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
@@ -1061,23 +1061,15 @@ static bool dp_ctrl_train_pattern_set(struct
dp_ctrl_private *ctrl,
static int dp_ctrl_read_link_status(struct dp_ctrl_private *ctrl,
u8 *link_status)
{
- int len = 0;
- u32 const offset = DP_LANE_ALIGN_STATUS_UPDATED - DP_LANE0_1_STATUS;
- u32 link_status_read_max_retries = 100;
-
- while (--link_status_read_max_retries) {
- len = drm_dp_dpcd_read_link_status(ctrl->aux,
- link_status);
- if (len != DP_LINK_STATUS_SIZE) {
- DRM_ERROR("DP link status read failed, err: %d\n", len);
- return len;
- }
+ int ret = 0, len;
- if (!(link_status[offset] & DP_LINK_STATUS_UPDATED))
- return 0;
+ len = drm_dp_dpcd_read_link_status(ctrl->aux, link_status);
+ if (len != DP_LINK_STATUS_SIZE) {
+ DRM_ERROR("DP link status read failed, err: %d\n", len);
+ ret = len;
}
- return -ETIMEDOUT;
+ return ret;
}
static int dp_ctrl_link_train_1(struct dp_ctrl_private *ctrl,
diff --git a/drivers/gpu/drm/msm/dp/dp_link.c b/drivers/gpu/drm/msm/dp/dp_link.c
index 49d7fad36fc4..64a002d100c7 100644
--- a/drivers/gpu/drm/msm/dp/dp_link.c
+++ b/drivers/gpu/drm/msm/dp/dp_link.c
@@ -773,7 +773,8 @@ static int dp_link_process_link_training_request(struct
dp_link_private *link)
link->request.test_lane_count);
link->dp_link.link_params.num_lanes = link->request.test_lane_count;
- link->dp_link.link_params.rate = link->request.test_link_rate;
+ link->dp_link.link_params.rate =
+ drm_dp_bw_code_to_link_rate(link->request.test_link_rate);
return 0;
}
@@ -943,20 +944,17 @@ static u8 get_link_status(const u8
link_status[DP_LINK_STATUS_SIZE], int r)
*/
static int dp_link_process_link_status_update(struct dp_link_private *link)
{
- if (!(get_link_status(link->link_status,
- DP_LANE_ALIGN_STATUS_UPDATED) &
- DP_LINK_STATUS_UPDATED) ||
- (drm_dp_clock_recovery_ok(link->link_status,
- link->dp_link.link_params.num_lanes) &&
- drm_dp_channel_eq_ok(link->link_status,
- link->dp_link.link_params.num_lanes)))
- return -EINVAL;
+ bool channel_eq_done = drm_dp_channel_eq_ok(link->link_status,
+ link->dp_link.link_params.num_lanes);
+
+ bool clock_recovery_done = drm_dp_clock_recovery_ok(link->link_status,
+ link->dp_link.link_params.num_lanes);
DRM_DEBUG_DP("channel_eq_done = %d, clock_recovery_done = %d\n",
- drm_dp_clock_recovery_ok(link->link_status,
- link->dp_link.link_params.num_lanes),
- drm_dp_clock_recovery_ok(link->link_status,
- link->dp_link.link_params.num_lanes));
+ channel_eq_done, clock_recovery_done);
+
+ if (channel_eq_done && clock_recovery_done)
+ return -EINVAL;
return 0;
}
base-commit: 03a9adc88c206b3857ce95f4f4d3b185d429fa31
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] staging: fbtft: fb_watterott: fix usleep_range is preferred over udelay
On Sun, Nov 01, 2020 at 07:39:48AM +0100, Greg KH wrote: > On Sun, Nov 01, 2020 at 02:20:10AM +0200, Hassan Shahbazi wrote: > > Fix the checkpath.pl issue on fb_watterott.c. write_vmem and > > write_vmem_8bit functions are within non-atomic context and can > > safely use usleep_range. > > see Documentation/timers/timers-howto.txt > > > > Signed-off-by: Hassan Shahbazi > > --- > > drivers/staging/fbtft/fb_watterott.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/staging/fbtft/fb_watterott.c > > b/drivers/staging/fbtft/fb_watterott.c > > index 76b25df376b8..afcc86a17995 100644 > > --- a/drivers/staging/fbtft/fb_watterott.c > > +++ b/drivers/staging/fbtft/fb_watterott.c > > @@ -84,7 +84,7 @@ static int write_vmem(struct fbtft_par *par, size_t > > offset, size_t len) > > par->txbuf.buf, 10 + par->info->fix.line_length); > > if (ret < 0) > > return ret; > > - udelay(300); > > + usleep_range(300, 310); > > } > > > > return 0; > > @@ -124,7 +124,7 @@ static int write_vmem_8bit(struct fbtft_par *par, > > size_t offset, size_t len) > > par->txbuf.buf, 10 + par->info->var.xres); > > if (ret < 0) > > return ret; > > - udelay(700); > > + usleep_range(700, 710); > > How do you know that these ranges are ok? Are you able to test these > changes with real hardware? > > thanks, > > greg k-h No, I don't have the hardware to test with. I just used the current value as the minimum and added an epsilon to it for the maximum param. best, hassan shahbazi ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 08/52] dt-bindings: memory: tegra20: emc: Document mfd-simple compatible and statistics sub-device
28.10.2020 18:26, Rob Herring пишет:
> On Tue, Oct 27, 2020 at 11:18:34PM +0300, Dmitry Osipenko wrote:
>> 27.10.2020 22:44, Krzysztof Kozlowski пишет:
>>> On Tue, Oct 27, 2020 at 10:22:19PM +0300, Dmitry Osipenko wrote:
27.10.2020 12:02, Krzysztof Kozlowski пишет:
>> @@ -31,17 +32,34 @@ Example:
>> ...
>> };
>>
>> +emc_bw_dfs_opp_table: emc_opp_table1 {
> Hyphens for node name.
We already use underscores for the Tegra CPU OPP table.
https://elixir.bootlin.com/linux/v5.10-rc1/source/arch/arm/boot/dts/tegra20-cpu-opp.dtsi#L4
What makes you think that hyphens will be a better choice? Is it a
documented naming convention?
>>>
>>> Unfortunately that's the source of confusion also for me because
>>> Devicetree spec mentions both of them (and does not specify preferences).
>>>
>>> The choice of dashes/hyphens comes now explicitly from all dtschema
>>> files. Previously, the documentation were emails from Rob. :)
>>
>> Okay, I'll change it in v7. So far I haven't seen warnings about it from
>> the schema-checker.
>
> dtc with W=2 will warn.
>
> The bigger issue is the name should be generic.
Indeed, thanks. I'll correct the name.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 2/2] drm/bridge: hx8837: add a Himax HX8837 display controller driver
Hello Sam,
thanks for your response.
On Sat, Oct 31, 2020 at 09:01:37AM +0100, Sam Ravnborg wrote:
> Hi Lubomir.
>
> On Fri, Oct 30, 2020 at 04:08:00AM +0100, Lubomir Rintel wrote:
> > Himax HX8837 is used to drive the LCD panel on OLPC platforms.
> >
> > It controls the panel backlight and is able to refresh it when the LCD
> > controller (and the rest of the plaform) is powered off.
> >
> > It also converts regular RGB color data from the LCDC so that it looks
> > reasonable on the OLPC LCD panel with a monochromatic layer on top of a
> > layer that can either reflect light (b/w sunlight readable mode) or light
> > pattern of red, green and blue pixels.
> >
> > At this point, the driver is rather basic. The self-refresh mode is not
> > supported. There's no way of independently controlling the color swizzling,
> > antialiasing or b/w conversion, but it probably isn't too useful either.
> >
> > There's another driver for the same hardware on OLPC XO-1.5 and XO-1.75
> > in drivers/staging/olpc_dcon. The display on that hardware doesn't utilize
> > DRM, so this driver doesn't replace the other one yet.
> >
> > Signed-off-by: Lubomir Rintel
> >
> > ---
> > Changes since v5:
> > (All based on feedback from Sam Ravnborg)
> > - Fix indentation in Kconfig
> > - Sort #includes
> > - Use a constant for max brightness instead of a literal
> > - Remove struct drm_panel from priv data
> > - Use dev_err() instead of DRM_ERROR
> > - Replace direct use of backlight props.brightness with
> > backlight_get_brightness()
> > - Document sentinels with { /* sentinel */ }
> > - Remove unsetting of panel->backlight
>
> Thanks, I missed a few things during the last round, so here is a few
> more comments. Only very trivial things but lets get them fixed before
> we add the driver to drm-misc-next.
>
> Sam
>
> >
> > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> > index ef91646441b16..881780719af7c 100644
> > --- a/drivers/gpu/drm/bridge/Kconfig
> > +++ b/drivers/gpu/drm/bridge/Kconfig
> > @@ -48,6 +48,19 @@ config DRM_DISPLAY_CONNECTOR
> > on ARM-based platforms. Saying Y here when this driver is not needed
> > will not cause any issue.
> >
> > +config DRM_HIMAX_HX8837
> > + tristate "HiMax HX8837 OLPC Display Controller"
> > + depends on OF
> > + depends on OLPC || ARCH_MMP || COMPILE_TEST
> > + select DRM_KMS_HELPER
> > + select BACKLIGHT_LCD_SUPPORT
> Unknown symbol - "git grep BACKLIGHT_LCD_SUPPORT" only turned up one
> unrelated hit.
>
> > + select BACKLIGHT_CLASS_DEVICE
> Please use a depends - using select on a symbol with a prompt is always
> wrong. Yeah, I know you then need to enable backlight to see this
> driver. Sorry, but this is the best we can do now.
> Many other drivers can cope with depends here.
This results in a dependency loop:
drivers/video/fbdev/Kconfig:12:error: recursive dependency detected!
drivers/video/fbdev/Kconfig:12: symbol FB is selected by DRM_KMS_FB_HELPER
drivers/gpu/drm/Kconfig:80: symbol DRM_KMS_FB_HELPER depends on
DRM_KMS_HELPER
drivers/gpu/drm/Kconfig:74: symbol DRM_KMS_HELPER is selected by
DRM_HIMAX_HX8837
drivers/gpu/drm/bridge/Kconfig:51: symbol DRM_HIMAX_HX8837 depends on
BACKLIGHT_CLASS_DEVICE
drivers/video/backlight/Kconfig:143:symbol BACKLIGHT_CLASS_DEVICE is
selected by FB_BACKLIGHT
drivers/video/fbdev/Kconfig:187:symbol FB_BACKLIGHT depends on FB
Unfortunately I have no idea how to resolve it at the moment.
I suppose I can look further into it if necessary. Or is it okay if I
leave it at select BACKLIGHT_CLASS_DEVICE for now?
> > + help
> > + Enable support for HiMax HX8837 Display Controller as found in the
> > + OLPC XO laptops.
> > +
> > + If your laptop doesn't have green ears, say "N"
> I like this last comment :-)
>
> > +
> > config DRM_LONTIUM_LT9611
> > tristate "Lontium LT9611 DSI/HDMI bridge"
> > select SND_SOC_HDMI_CODEC if SND_SOC
> > diff --git a/drivers/gpu/drm/bridge/Makefile
> > b/drivers/gpu/drm/bridge/Makefile
> > index 2b3aff104e466..21f72df3260db 100644
> > --- a/drivers/gpu/drm/bridge/Makefile
> > +++ b/drivers/gpu/drm/bridge/Makefile
> > @@ -2,6 +2,7 @@
> > obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
> > obj-$(CONFIG_DRM_CHRONTEL_CH7033) += chrontel-ch7033.o
> > obj-$(CONFIG_DRM_DISPLAY_CONNECTOR) += display-connector.o
> > +obj-$(CONFIG_DRM_HIMAX_HX8837) += himax-hx8837.o
> > obj-$(CONFIG_DRM_LONTIUM_LT9611) += lontium-lt9611.o
> > obj-$(CONFIG_DRM_LVDS_CODEC) += lvds-codec.o
> > obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) +=
> > megachips-stdp-ge-b850v3-fw.o
> > diff --git a/drivers/gpu/drm/bridge/himax-hx8837.c
> > b/drivers/gpu/drm/bridge/himax-hx8837.c
> > new file mode 100644
> > index 0..f472e16cc331d
> > --- /dev/null
> > +++ b/drivers/gpu/drm/bridge/himax-hx8837.c
> > @@ -0,0 +1,330 @@
> > +// SPDX-License-Identifier: GPL-2.0-or-later
> > +/*
> > + * HiMax HX8837 Displa
[PATCH] drm: panel: simple: add missing platform_driver_unregister() in panel_simple_init
Add the missing platform_driver_unregister() before return
from panel_simple_init in the error handling case when failed
to register panel_simple_dsi_driver with CONFIG_DRM_MIPI_DSI
enabled.
Signed-off-by: Qinglang Miao
---
drivers/gpu/drm/panel/panel-simple.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 2be358fb4..2966ac13c 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -4644,8 +4644,10 @@ static int __init panel_simple_init(void)
if (IS_ENABLED(CONFIG_DRM_MIPI_DSI)) {
err = mipi_dsi_driver_register(&panel_simple_dsi_driver);
- if (err < 0)
+ if (err < 0) {
+
platform_driver_unregister(&panel_simple_platform_driver);
return err;
+ }
}
return 0;
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv7 7/7] iommu: arm-smmu-impl: Add a space before open parenthesis
Fix the checkpatch warning for space required before the open
parenthesis.
Signed-off-by: Sai Prakash Ranjan
---
drivers/iommu/arm/arm-smmu/arm-smmu-impl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
b/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
index ffaf3f91ba52..f16da4a21270 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
@@ -12,7 +12,7 @@
static int arm_smmu_gr0_ns(int offset)
{
- switch(offset) {
+ switch (offset) {
case ARM_SMMU_GR0_sCR0:
case ARM_SMMU_GR0_sACR:
case ARM_SMMU_GR0_sGFSR:
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH -next] drm/rockchip: cdn-dp: Mark cdn_dp_core_suspend/resume __maybe_unused
ping...
On 2020/8/11 10:12, YueHaibing wrote:
> If CONFIG_PM is not set, gcc warns:
>
> drivers/gpu/drm/rockchip/cdn-dp-core.c:1124:12:
> warning: ‘cdn_dp_resume’ defined but not used [-Wunused-function]
>
> Mark them __maybe_unused to fix this.
>
> Reported-by: Hulk Robot
> Signed-off-by: YueHaibing
> ---
> drivers/gpu/drm/rockchip/cdn-dp-core.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c
> b/drivers/gpu/drm/rockchip/cdn-dp-core.c
> index a4a45daf93f2..413b0e90f10f 100644
> --- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
> +++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
> @@ -1107,7 +1107,7 @@ static const struct component_ops cdn_dp_component_ops
> = {
> .unbind = cdn_dp_unbind,
> };
>
> -static int cdn_dp_suspend(struct device *dev)
> +static __maybe_unused int cdn_dp_suspend(struct device *dev)
> {
> struct cdn_dp_device *dp = dev_get_drvdata(dev);
> int ret = 0;
> @@ -1121,7 +1121,7 @@ static int cdn_dp_suspend(struct device *dev)
> return ret;
> }
>
> -static int cdn_dp_resume(struct device *dev)
> +static __maybe_unused int cdn_dp_resume(struct device *dev)
> {
> struct cdn_dp_device *dp = dev_get_drvdata(dev);
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 51/52] PM / devfreq: tegra30: Support interconnect and OPPs from device-tree
01.11.2020 17:44, Chanwoo Choi пишет:
> Hi Dmitry,
>
> On Mon, Oct 26, 2020 at 7:22 AM Dmitry Osipenko wrote:
>>
>> This patch moves ACTMON driver away from generating OPP table by itself,
>> transitioning it to use the table which comes from device-tree. This
>> change breaks compatibility with older device-trees in order to bring
>> support for the interconnect framework to the driver. This is a mandatory
>> change which needs to be done in order to implement interconnect-based
>> memory DVFS. Users of legacy device-trees will get a message telling that
>> theirs DT needs to be upgraded. Now ACTMON issues memory bandwidth request
>> using dev_pm_opp_set_bw(), instead of driving EMC clock rate directly.
>>
>> Tested-by: Peter Geis
>> Tested-by: Nicolas Chauvet
>> Signed-off-by: Dmitry Osipenko
>> ---
>> drivers/devfreq/tegra30-devfreq.c | 91 ---
>> 1 file changed, 48 insertions(+), 43 deletions(-)
>>
>> diff --git a/drivers/devfreq/tegra30-devfreq.c
>> b/drivers/devfreq/tegra30-devfreq.c
>> index 3f732ab53573..1b0b91a71886 100644
>> --- a/drivers/devfreq/tegra30-devfreq.c
>> +++ b/drivers/devfreq/tegra30-devfreq.c
>> @@ -19,6 +19,8 @@
>> #include
>> #include
>>
>> +#include
>> +
>
> This patch touches the OPP. Is it related to this change?
Yes, this is needed for the dev_pm_opp_set_supported_hw().
>> #include "governor.h"
>>
>> #define ACTMON_GLB_STATUS 0x0
>> @@ -155,6 +157,7 @@ struct tegra_devfreq_device {
>>
>> struct tegra_devfreq {
>> struct devfreq *devfreq;
>> + struct opp_table*opp_table;
>>
>> struct reset_control*reset;
>> struct clk *clock;
>> @@ -612,34 +615,19 @@ static void tegra_actmon_stop(struct tegra_devfreq
>> *tegra)
>> static int tegra_devfreq_target(struct device *dev, unsigned long *freq,
>> u32 flags)
>> {
>> - struct tegra_devfreq *tegra = dev_get_drvdata(dev);
>> - struct devfreq *devfreq = tegra->devfreq;
>> struct dev_pm_opp *opp;
>> - unsigned long rate;
>> - int err;
>> + int ret;
>>
>> opp = devfreq_recommended_opp(dev, freq, flags);
>> if (IS_ERR(opp)) {
>> - dev_err(dev, "Failed to find opp for %lu Hz\n", *freq);
>> + dev_err(dev, "failed to find opp for %lu Hz\n", *freq);
>
> You used the 'Failed to' format in almost every error case.
> Don't need to change it.
> (snip)
Good catch, thanks.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/msm/dp: deinitialize mainlink if link training failedo
DP compo phy have to be enable to start link training. When
link training failed phy need to be disabled so that next
link trainng can be proceed smoothly at next plug in. This
patch de initialize mainlink to disable phy if link training
failed. This prevent system crash due to
disp_cc_mdss_dp_link_intf_clk stuck at "off" state. This patch
also perform checking power_on flag at dp_display_enable() and
dp_display_disable() to avoid crashing when unplug cable while
display is off.
Fixes: fdaf9a5e3c15 (drm/msm/dp: fixes wrong connection state caused by failure
of link train
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_ctrl.c| 34 +++--
drivers/gpu/drm/msm/dp/dp_display.c | 13 +++
2 files changed, 45 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c b/drivers/gpu/drm/msm/dp/dp_ctrl.c
index cee161c8ecc6..904698dfc7f7 100644
--- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
+++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
@@ -1468,6 +1468,29 @@ static int dp_ctrl_reinitialize_mainlink(struct
dp_ctrl_private *ctrl)
return ret;
}
+static int dp_ctrl_deinitialize_mainlink(struct dp_ctrl_private *ctrl)
+{
+ struct dp_io *dp_io;
+ struct phy *phy;
+ int ret = 0;
+
+ dp_io = &ctrl->parser->io;
+ phy = dp_io->phy;
+
+ dp_catalog_ctrl_mainlink_ctrl(ctrl->catalog, false);
+
+ dp_catalog_ctrl_reset(ctrl->catalog);
+
+ ret = dp_power_clk_enable(ctrl->power, DP_CTRL_PM, false);
+ if (ret)
+ DRM_ERROR("Failed to disable link clocks. ret=%d\n", ret);
+
+ phy_power_off(phy);
+ phy_exit(phy);
+
+ return -ECONNRESET;
+}
+
static int dp_ctrl_link_maintenance(struct dp_ctrl_private *ctrl)
{
int ret = 0;
@@ -1648,8 +1671,7 @@ int dp_ctrl_on_link(struct dp_ctrl *dp_ctrl)
if (rc)
return rc;
- while (--link_train_max_retries &&
- !atomic_read(&ctrl->dp_ctrl.aborted)) {
+ while (--link_train_max_retries) {
rc = dp_ctrl_reinitialize_mainlink(ctrl);
if (rc) {
DRM_ERROR("Failed to reinitialize mainlink. rc=%d\n",
@@ -1664,6 +1686,9 @@ int dp_ctrl_on_link(struct dp_ctrl *dp_ctrl)
break;
} else if (training_step == DP_TRAINING_1) {
/* link train_1 failed */
+ if (!dp_catalog_hpd_get_state_status(ctrl->catalog))
+ break; /* link cable unplugged */
+
rc = dp_ctrl_link_rate_down_shift(ctrl);
if (rc < 0) { /* already in RBR = 1.6G */
if (cr.lane_0_1 & DP_LANE0_1_CR_DONE) {
@@ -1683,6 +1708,9 @@ int dp_ctrl_on_link(struct dp_ctrl *dp_ctrl)
}
} else if (training_step == DP_TRAINING_2) {
/* link train_2 failed, lower lane rate */
+ if (!dp_catalog_hpd_get_state_status(ctrl->catalog))
+ break; /* link cable unplugged */
+
rc = dp_ctrl_link_lane_down_shift(ctrl);
if (rc < 0) {
/* end with failure */
@@ -1703,6 +1731,8 @@ int dp_ctrl_on_link(struct dp_ctrl *dp_ctrl)
*/
if (rc == 0) /* link train successfully */
dp_ctrl_push_idle(dp_ctrl);
+ else
+ rc = dp_ctrl_deinitialize_mainlink(ctrl);
return rc;
}
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index 3eb0d428abf7..13b66266cd69 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -529,6 +529,11 @@ static int dp_hpd_plug_handle(struct dp_display_private
*dp, u32 data)
if (ret) { /* link train failed */
hpd->hpd_high = 0;
dp->hpd_state = ST_DISCONNECTED;
+
+ if (ret == -ECONNRESET) { /* cable unplugged */
+ dp->core_initialized = false;
+ }
+
} else {
/* start sentinel checking in case of missing uevent */
dp_add_event(dp, EV_CONNECT_PENDING_TIMEOUT, 0, tout);
@@ -794,6 +799,11 @@ static int dp_display_enable(struct dp_display_private
*dp, u32 data)
dp_display = g_dp_display;
+ if (dp_display->power_on) {
+ DRM_DEBUG_DP("Link already setup, return\n");
+ return 0;
+ }
+
rc = dp_ctrl_on_stream(dp->ctrl);
if (!rc)
dp_display->power_on = true;
@@ -826,6 +836,9 @@ static int dp_display_disable(struct dp_display_private
*dp, u32 data)
dp_display = g_dp_display;
+ if (!dp_display->power_on)
+ return -EINVAL;
+
/* wait only if audio was enabled */
if (dp_display->audio_enabled) {
if (!wait_for_completion_tim
[PATCHv7 2/7] iommu/arm-smmu: Add domain attribute for system cache
Add iommu domain attribute for using system cache aka last level
cache by client drivers like GPU to set right attributes for caching
the hardware pagetables into the system cache.
Signed-off-by: Sai Prakash Ranjan
---
drivers/iommu/arm/arm-smmu/arm-smmu.c | 17 +
drivers/iommu/arm/arm-smmu/arm-smmu.h | 1 +
include/linux/iommu.h | 1 +
3 files changed, 19 insertions(+)
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c
b/drivers/iommu/arm/arm-smmu/arm-smmu.c
index b1cf8f0abc29..070d13f80c7e 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
@@ -789,6 +789,9 @@ static int arm_smmu_init_domain_context(struct iommu_domain
*domain,
if (smmu_domain->non_strict)
pgtbl_cfg.quirks |= IO_PGTABLE_QUIRK_NON_STRICT;
+ if (smmu_domain->sys_cache)
+ pgtbl_cfg.quirks |= IO_PGTABLE_QUIRK_SYS_CACHE;
+
pgtbl_ops = alloc_io_pgtable_ops(fmt, &pgtbl_cfg, smmu_domain);
if (!pgtbl_ops) {
ret = -ENOMEM;
@@ -1520,6 +1523,9 @@ static int arm_smmu_domain_get_attr(struct iommu_domain
*domain,
case DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE:
*(int *)data = smmu_domain->non_strict;
return 0;
+ case DOMAIN_ATTR_SYS_CACHE:
+ *((int *)data) = smmu_domain->sys_cache;
+ return 0;
default:
return -ENODEV;
}
@@ -1551,6 +1557,17 @@ static int arm_smmu_domain_set_attr(struct iommu_domain
*domain,
else
smmu_domain->stage = ARM_SMMU_DOMAIN_S1;
break;
+ case DOMAIN_ATTR_SYS_CACHE:
+ if (smmu_domain->smmu) {
+ ret = -EPERM;
+ goto out_unlock;
+ }
+
+ if (*((int *)data))
+ smmu_domain->sys_cache = true;
+ else
+ smmu_domain->sys_cache = false;
+ break;
default:
ret = -ENODEV;
}
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.h
b/drivers/iommu/arm/arm-smmu/arm-smmu.h
index 885840f3bec8..dfc44d806671 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu.h
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu.h
@@ -373,6 +373,7 @@ struct arm_smmu_domain {
struct mutexinit_mutex; /* Protects smmu pointer */
spinlock_t cb_lock; /* Serialises ATS1* ops and
TLB syncs */
struct iommu_domain domain;
+ boolsys_cache;
};
struct arm_smmu_master_cfg {
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index b95a6f8db6ff..4f4bb9c6f8f6 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -118,6 +118,7 @@ enum iommu_attr {
DOMAIN_ATTR_FSL_PAMUV1,
DOMAIN_ATTR_NESTING,/* two stages of translation */
DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE,
+ DOMAIN_ATTR_SYS_CACHE,
DOMAIN_ATTR_MAX,
};
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Outreachy kernel] [PATCH] drm/amdgpu: use DEFINE_DEBUGFS_ATTRIBUTE with debugfs_create_file_unsafe()
On Sat, 31 Oct 2020, Joe Perches wrote: > On Fri, 2020-10-30 at 09:03 +0100, Greg KH wrote: > > On Fri, Oct 30, 2020 at 01:27:16PM +0530, Deepak R Varma wrote: > > > On Fri, Oct 30, 2020 at 08:11:20AM +0100, Greg KH wrote: > > > > On Fri, Oct 30, 2020 at 08:52:45AM +0530, Deepak R Varma wrote: > > > > > Using DEFINE_DEBUGFS_ATTRIBUTE macro with debugfs_create_file_unsafe() > > > > > function in place of the debugfs_create_file() function will make the > > > > > file operation struct "reset" aware of the file's lifetime. Additional > > > > > details here: https://lists.archive.carbon60.com/linux/kernel/2369498 > > > > > > > > > > Issue reported by Coccinelle script: > > > > > scripts/coccinelle/api/debugfs/debugfs_simple_attr.cocci > [] > > There is a reason we didn't just do a global search/replace for this in > > the kernel when the new functions were added, so I don't know why > > checkpatch is now saying it must be done. > > I think it's not a checkpatch warning here. That is correct, it's a coccinelle script. julia > > -- > You received this message because you are subscribed to the Google Groups > "outreachy-kernel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to outreachy-kernel+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/outreachy-kernel/0b818156537f354904938f437cbb9dd02e765653.camel%40perches.com. > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv7 6/7] iommu: arm-smmu-impl: Use table to list QCOM implementations
Use table and of_match_node() to match qcom implementation
instead of multiple of_device_compatible() calls for each
QCOM SMMU implementation.
Signed-off-by: Sai Prakash Ranjan
---
drivers/iommu/arm/arm-smmu/arm-smmu-impl.c | 9 +
drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 21 -
drivers/iommu/arm/arm-smmu/arm-smmu.h | 1 -
3 files changed, 17 insertions(+), 14 deletions(-)
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
b/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
index d199b4bff15d..ffaf3f91ba52 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
@@ -217,14 +217,7 @@ struct arm_smmu_device *arm_smmu_impl_init(struct
arm_smmu_device *smmu)
if (of_device_is_compatible(np, "nvidia,tegra194-smmu"))
return nvidia_smmu_impl_init(smmu);
- if (of_device_is_compatible(np, "qcom,sdm845-smmu-500") ||
- of_device_is_compatible(np, "qcom,sc7180-smmu-500") ||
- of_device_is_compatible(np, "qcom,sm8150-smmu-500") ||
- of_device_is_compatible(np, "qcom,sm8250-smmu-500"))
- return qcom_smmu_impl_init(smmu);
-
- if (of_device_is_compatible(smmu->dev->of_node, "qcom,adreno-smmu"))
- return qcom_adreno_smmu_impl_init(smmu);
+ smmu = qcom_smmu_impl_init(smmu);
if (of_device_is_compatible(np, "marvell,ap806-smmu-500"))
smmu->impl = &mrvl_mmu500_impl;
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
index 0f763d555c92..221e2a6a3231 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
@@ -314,12 +314,23 @@ static struct arm_smmu_device *qcom_smmu_create(struct
arm_smmu_device *smmu,
return &qsmmu->smmu;
}
+static const struct of_device_id __maybe_unused qcom_smmu_impl_of_match[] = {
+ { .compatible = "qcom,sc7180-smmu-500" },
+ { .compatible = "qcom,sdm845-smmu-500" },
+ { .compatible = "qcom,sm8150-smmu-500" },
+ { .compatible = "qcom,sm8250-smmu-500" },
+ { }
+};
+
struct arm_smmu_device *qcom_smmu_impl_init(struct arm_smmu_device *smmu)
{
- return qcom_smmu_create(smmu, &qcom_smmu_impl);
-}
+ const struct device_node *np = smmu->dev->of_node;
-struct arm_smmu_device *qcom_adreno_smmu_impl_init(struct arm_smmu_device
*smmu)
-{
- return qcom_smmu_create(smmu, &qcom_adreno_smmu_impl);
+ if (of_match_node(qcom_smmu_impl_of_match, np))
+ return qcom_smmu_create(smmu, &qcom_smmu_impl);
+
+ if (of_device_is_compatible(np, "qcom,adreno-smmu"))
+ return qcom_smmu_create(smmu, &qcom_adreno_smmu_impl);
+
+ return smmu;
}
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.h
b/drivers/iommu/arm/arm-smmu/arm-smmu.h
index dfc44d806671..43b2411e65cc 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu.h
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu.h
@@ -525,7 +525,6 @@ static inline void arm_smmu_writeq(struct arm_smmu_device
*smmu, int page,
struct arm_smmu_device *arm_smmu_impl_init(struct arm_smmu_device *smmu);
struct arm_smmu_device *nvidia_smmu_impl_init(struct arm_smmu_device *smmu);
struct arm_smmu_device *qcom_smmu_impl_init(struct arm_smmu_device *smmu);
-struct arm_smmu_device *qcom_adreno_smmu_impl_init(struct arm_smmu_device
*smmu);
void arm_smmu_write_context_bank(struct arm_smmu_device *smmu, int idx);
int arm_mmu500_reset(struct arm_smmu_device *smmu);
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 19/20] drm/tegra: Implement new UAPI
28.10.2020 12:54, Mikko Perttunen пишет: > On 10/27/20 9:06 PM, Dmitry Osipenko wrote: >> 26.10.2020 12:11, Mikko Perttunen пишет: The first patches should be the ones that are relevant to the existing userspace code, like support for the waits. >>> >>> Can you elaborate what you mean by this? >> >> All features that don't have an immediate real use-case should be placed >> later in the series because we may defer merging of those patches until >> we will see userspace that uses those features since we can't really >> decide whether these are decisions that we won't regret later on, only >> practical application can confirm the correctness. > > I was more referring to the "support for waits" part, should have > clarified that. The "support for waits" is support for the WAIT_SYNCPT command exposed to userspace, which we could utilize right now. Partial mappings should be a separate feature because it's a questionable feature that needs to be proved by a real userspace first. Maybe it would be even better to drop it for the starter, to ease reviewing. >>> >>> Considering that the "no-op" support for it (map the whole buffer but >>> just keep track of the starting offset) is only a couple of lines, I'd >>> like to keep it in. >> >> There is no tracking in the current code which prevents the duplicated >> mappings, will we need to care about it? This a bit too questionable >> feature for now, IMO. I'd like to see it as a separate patch. > > I don't think there is any need to special case duplicated mappings. I > think this is a pretty obvious feature to have, but I can rename them to > reserved0 and reserved1 and require that reserved0 is zero and reserved1 > is the size of the passed GEM object. I'm now concerned about the reserved fields after seeing this reply from Daniel Vetter: https://www.mail-archive.com/nouveau@lists.freedesktop.org/msg36324.html If DRM IOCTL structs are zero-extended, then perhaps we won't need to reserve anything? >> ... I'd like to see the DRM_SCHED and syncobj support. I can help you with it if it's out of yours scope for now. >>> >>> I already wrote some code for syncobj I can probably pull in. Regarding >>> DRM_SCHED, help is accepted. However, we should keep using the hardware >>> scheduler, and considering it's a bigger piece of work, let's not block >>> this series on it. >> >> I'd like to see all the custom IOCTLs to be deprecated and replaced with >> the generic DRM API wherever possible. Hence, I think it should be a >> mandatory features that we need to focus on. The current WIP userspace >> already uses and relies on DRM_SCHED. >> > > From my point of view, the ABI needs to be designed such that it can > replace what we have downstream, i.e. it needs to support the usecases > the downstream nvhost ABI supports currently. Otherwise there is no > migration path to upstream and it's not worth it for me to work on this. The downstream needs should be irrelevant for the upstream, please read this: https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements It may happen that some of the downstream features could become useful for upstream, but we don't know until we will see the full userspace code. We don't have a comprehensive userspace which could utilize all the new features and that's why upstream driver has been stagnated for many years now. The grate-drivers would greatly benefit from the updated ABI, but I think that we need at least a usable mesa driver first, that's why I haven't bothered to upstream anything from the WIP UAPI v2. In order to upstream new UAPI features we will need: 1. Hardware specs (from vendor or reverse-engineered). 2. Regression tests. 3. A non-toy opensource userspace. > Although, I don't see what this ABI is missing that your userspace would > rely on. Does it submit jobs in reverse order that would deadlock if > drm_sched didn't reorder them based on prefences, or something? It's the opposite, we don't have userspace which needs majority of the proposed ABI. This needs to be fixed before we could seriously consider merging the new features. I'm pretty sure that you was already aware about all the upstreaming requirements and we will see the usable opensource userspace at some point, correct? For now it will be good to have this series in a form of a work-in-progress patches, continuing to discuss and update it. Meanwhile we will need to work on the userspace part as well, which is a much bigger blocker. > Software-based scheduling might make sense in situations where the > channel is shared by all processes, but at least for modern chips that > are designed to use hardware scheduling, I want to use that capability. The software-based scheduling is indeed needed for the older SoCs in order not to block hardware channels and job-submission code paths. Maybe it could become useful for a newer SoCs as well once we will get closer to a usable
[PATCHv7 3/7] drm/msm: rearrange the gpu_rmw() function
From: Sharat Masetty
The register read-modify-write construct is generic enough
that it can be used by other subsystems as needed, create
a more generic rmw() function and have the gpu_rmw() use
this new function.
Signed-off-by: Sharat Masetty
Reviewed-by: Jordan Crouse
Signed-off-by: Sai Prakash Ranjan
---
drivers/gpu/drm/msm/msm_drv.c | 8
drivers/gpu/drm/msm/msm_drv.h | 1 +
drivers/gpu/drm/msm/msm_gpu.h | 5 +
3 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 49685571dc0e..a1e22b974b77 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -180,6 +180,14 @@ u32 msm_readl(const void __iomem *addr)
return val;
}
+void msm_rmw(void __iomem *addr, u32 mask, u32 or)
+{
+ u32 val = msm_readl(addr);
+
+ val &= ~mask;
+ msm_writel(val | or, addr);
+}
+
struct msm_vblank_work {
struct work_struct work;
int crtc_id;
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index b9dd8f8f4887..655b3b0424a1 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -478,6 +478,7 @@ void __iomem *msm_ioremap_quiet(struct platform_device
*pdev, const char *name,
const char *dbgname);
void msm_writel(u32 data, void __iomem *addr);
u32 msm_readl(const void __iomem *addr);
+void msm_rmw(void __iomem *addr, u32 mask, u32 or);
struct msm_gpu_submitqueue;
int msm_submitqueue_init(struct drm_device *drm, struct msm_file_private *ctx);
diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
index 6c9e1fdc1a76..b2b419277953 100644
--- a/drivers/gpu/drm/msm/msm_gpu.h
+++ b/drivers/gpu/drm/msm/msm_gpu.h
@@ -246,10 +246,7 @@ static inline u32 gpu_read(struct msm_gpu *gpu, u32 reg)
static inline void gpu_rmw(struct msm_gpu *gpu, u32 reg, u32 mask, u32 or)
{
- uint32_t val = gpu_read(gpu, reg);
-
- val &= ~mask;
- gpu_write(gpu, reg, val | or);
+ msm_rmw(gpu->mmio + (reg << 2), mask, or);
}
static inline u64 gpu_read64(struct msm_gpu *gpu, u32 lo, u32 hi)
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/4] drm/panel: Add ABT Y030XX067A 3.0" 320x480 panel
Add support for the ShenZhen Asia Better Technology Ltd. Y030XX067A 3.0" 320x480 IPS panel. This panel can be found in the YLM RG-280M, RG-300 and RG-99 handheld gaming consoles. While being 320x480, it is actually a horizontal 4:3 panel with non-square pixels. Signed-off-by: Paul Cercueil Signed-off-by: Christophe Branchereau --- drivers/gpu/drm/panel/Kconfig| 9 + drivers/gpu/drm/panel/Makefile | 1 + drivers/gpu/drm/panel/panel-abt-y030xx067a.c | 363 +++ 3 files changed, 373 insertions(+) create mode 100644 drivers/gpu/drm/panel/panel-abt-y030xx067a.c diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig index e386524b2d77..7fe22b4c8aa2 100644 --- a/drivers/gpu/drm/panel/Kconfig +++ b/drivers/gpu/drm/panel/Kconfig @@ -8,6 +8,15 @@ config DRM_PANEL menu "Display Panels" depends on DRM && DRM_PANEL +config DRM_PANEL_ABT_Y030XX067A + tristate "ABT Y030XX067A 320x480 LCD panel" + depends on OF && SPI + select REGMAP_SPI + help + Say Y here to enable support for the Asia Better Technology Ltd. + Y030XX067A 320x480 3.0" panel as found in the YLM RG-280M, RG-300 + and RG-99 handheld gaming consoles. + config DRM_PANEL_ARM_VERSATILE tristate "ARM Versatile panel driver" depends on OF diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile index d1f8cc572f37..78b77ba4d458 100644 --- a/drivers/gpu/drm/panel/Makefile +++ b/drivers/gpu/drm/panel/Makefile @@ -1,4 +1,5 @@ # SPDX-License-Identifier: GPL-2.0 +obj-$(CONFIG_DRM_PANEL_ABT_Y030XX067A) += panel-abt-y030xx067a.o obj-$(CONFIG_DRM_PANEL_ARM_VERSATILE) += panel-arm-versatile.o obj-$(CONFIG_DRM_PANEL_ASUS_Z00T_TM5P5_NT35596) += panel-asus-z00t-tm5p5-n35596.o obj-$(CONFIG_DRM_PANEL_BOE_HIMAX8279D) += panel-boe-himax8279d.o diff --git a/drivers/gpu/drm/panel/panel-abt-y030xx067a.c b/drivers/gpu/drm/panel/panel-abt-y030xx067a.c new file mode 100644 index ..2d8794d495d0 --- /dev/null +++ b/drivers/gpu/drm/panel/panel-abt-y030xx067a.c @@ -0,0 +1,363 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Asia Better Technology Ltd. Y030XX067A IPS LCD panel driver + * + * Copyright (C) 2020, Paul Cercueil + * Copyright (C) 2020, Christophe Branchereau + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include + +#define REG00_VBRT_CTRL(val) (val) + +#define REG01_COM_DC(val) (val) + +#define REG02_DA_CONTRAST(val) (val) +#define REG02_VESA_SEL(val)((val) << 5) +#define REG02_COMDC_SW BIT(7) + +#define REG03_VPOSITION(val) (val) +#define REG03_BSMOUNT BIT(5) +#define REG03_COMTST BIT(6) +#define REG03_HPOSITION1 BIT(7) + +#define REG04_HPOSITION1(val) (val) + +#define REG05_CLIP BIT(0) +#define REG05_NVM_VREFRESH BIT(1) +#define REG05_SLFR BIT(2) +#define REG05_SLBRCHARGE(val) ((val) << 3) +#define REG05_PRECHARGE_LEVEL(val) ((val) << 6) + +#define REG06_TEST5BIT(0) +#define REG06_SLDWNBIT(1) +#define REG06_SLRGTBIT(2) +#define REG06_TEST2BIT(3) +#define REG06_XPSAVE BIT(4) +#define REG06_GAMMA_SEL(val) ((val) << 5) +#define REG06_NT BIT(7) + +#define REG07_TEST1BIT(0) +#define REG07_HDVD_POL BIT(1) +#define REG07_CK_POL BIT(2) +#define REG07_TEST3BIT(3) +#define REG07_TEST4BIT(4) +#define REG07_480_LINEMASK BIT(5) +#define REG07_AMPTST(val) ((val) << 6) + +#define REG08_SLHRC(val) (val) +#define REG08_CLOCK_DIV(val) ((val) << 2) +#define REG08_PANEL(val) ((val) << 5) + +#define REG09_SUB_BRIGHT_R(val)(val) +#define REG09_NW_NBBIT(6) +#define REG09_IPCONBIT(7) + +#define REG0A_SUB_BRIGHT_B(val)(val) +#define REG0A_PAIR BIT(6) +#define REG0A_DE_SEL BIT(7) + +#define REG0B_MBK_POSITION(val)(val) +#define REG0B_HD_FREERUN BIT(4) +#define REG0B_VD_FREERUN BIT(5) +#define REG0B_YUV2BIN(val) ((val) << 6) + +#define REG0C_CONTRAST_R(val) (val) +#define REG0C_DOUBLEREAD BIT(7) + +#define REG0D_CONTRAST_G(val) (val) +#define REG0D_RGB_YUV BIT(7) + +#define REG0E_CONTRAST_B(val) (val) +#define REG0E_PIXELCOLORDRIVE BIT(7) + +#define REG0F_ASPECT BIT(0) +#define REG0F_OVERSCAN(val)((val) << 1) +#define REG0F_FRAMEWIDTH(val) ((val) << 3) + +#define REG10_BRIGHT(val) (val) + +#d
Re: [PATCH v6 51/52] PM / devfreq: tegra30: Support interconnect and OPPs from device-tree
01.11.2020 17:39, Chanwoo Choi пишет:
> Hi Dmitry,
>
> On Mon, Oct 26, 2020 at 7:22 AM Dmitry Osipenko wrote:
>>
>> This patch moves ACTMON driver away from generating OPP table by itself,
>> transitioning it to use the table which comes from device-tree. This
>> change breaks compatibility with older device-trees in order to bring
>> support for the interconnect framework to the driver. This is a mandatory
>> change which needs to be done in order to implement interconnect-based
>> memory DVFS. Users of legacy device-trees will get a message telling that
>> theirs DT needs to be upgraded. Now ACTMON issues memory bandwidth request
>> using dev_pm_opp_set_bw(), instead of driving EMC clock rate directly.
>>
>> Tested-by: Peter Geis
>> Tested-by: Nicolas Chauvet
>> Signed-off-by: Dmitry Osipenko
>> ---
...
>> static int tegra_devfreq_get_dev_status(struct device *dev,
>> @@ -655,7 +643,7 @@ static int tegra_devfreq_get_dev_status(struct device
>> *dev,
>> stat->private_data = tegra;
>>
>> /* The below are to be used by the other governors */
>> - stat->current_frequency = cur_freq;
>> + stat->current_frequency = cur_freq * KHZ;
>
> I can't find any change related to the frequency unit on this patch.
> Do you fix the previous bug of the frequency unit?
Previously, OPP entries that were generated by the driver used KHz
units. Now, OPP entries are coming from a device-tree and they have Hz
units. This driver operates with KHz internally, hence we need to
convert the units now.
>>
>> actmon_dev = &tegra->devices[MCALL];
>>
>> @@ -705,7 +693,7 @@ static int tegra_governor_get_target(struct devfreq
>> *devfreq,
>> target_freq = max(target_freq, dev->target_freq);
>> }
>>
>> - *freq = target_freq;
>> + *freq = target_freq * KHZ;
>
> ditto.
>
>>
>> return 0;
>> }
>> @@ -773,13 +761,22 @@ static struct devfreq_governor tegra_devfreq_governor
>> = {
>>
>> static int tegra_devfreq_probe(struct platform_device *pdev)
>> {
>> + u32 hw_version = BIT(tegra_sku_info.soc_speedo_id);
>> struct tegra_devfreq_device *dev;
>> struct tegra_devfreq *tegra;
>> + struct opp_table *opp_table;
>> struct devfreq *devfreq;
>> unsigned int i;
>> long rate;
>> int err;
>>
>> + /* legacy device-trees don't have OPP table and must be updated */
>> + if (!device_property_present(&pdev->dev, "operating-points-v2")) {
>> + dev_err(&pdev->dev, "OPP table not found, cannot
>> continue\n");
>> + dev_err(&pdev->dev, "please update your device tree\n");
>> + return -ENODEV;
>> + }
>
> As you mentioned, it breaks the old dtb. I have no objection to improving
> the driver. Instead, you need confirmation from the Devicetree maintainer.
Older DTBs will continue to work, but devfreq driver won't. We already
did this for other Tegra drivers before (CPUFREQ driver for example) and
Rob Herring confirmed that there is no problem here.
> And,
> I recommend that you use dev_pm_opp_of_get_opp_desc_node(&pdev->dev)
> to check whether a device contains opp-table or not.
I'm not sure what are the benefits, this will make code less
expressive/readable and we will need to add extra of_node_put(), which
device_property_present() handles for us.
Could you please give the rationale?
>> +
>> tegra = devm_kzalloc(&pdev->dev, sizeof(*tegra), GFP_KERNEL);
>> if (!tegra)
>> return -ENOMEM;
>> @@ -821,11 +818,29 @@ static int tegra_devfreq_probe(struct platform_device
>> *pdev)
>> return err;
>> }
>>
>> + tegra->opp_table = dev_pm_opp_get_opp_table(&pdev->dev);
>> + if (IS_ERR(tegra->opp_table))
>> + return dev_err_probe(&pdev->dev, PTR_ERR(tegra->opp_table),
>> +"Failed to prepare OPP table\n");
>
> As I knew, each device can contain the opp_table on devicetree.
> It means that opp_table has not depended to another device driver.
> Did you see this exception case with EPROBE_DEFER error?
OPP core will try to grab the clock reference for the table and it may
cause EPROBE_DEFER. Although, it shouldn't happen here because we have
devm_clk_get() before the get_opp_table(), hence seems the deferred
probe indeed shouldn't happen in this case.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 49/52] PM / devfreq: tegra20: Convert to EMC_STAT driver, support interconnect and device-tree
01.11.2020 16:31, Chanwoo Choi пишет: > Hi Dmitry, > > This patch contains the three features as following: > 1. Use interconnect interface for controlling the clock instead of > controlling it direclty > 2. Use EMC_STAT instead of IMC_STAT > 3. Change polling_interval and upthreshold for more fast responsiveness > > I think you need to make the separate patches for each role. > But, if it is difficult or not proper to split out 1,2 roles, you can > make two patches for 1,2 and 3 roles. Hello Chanwoo, We will probably move the Tegra20 EMC_STAT devfreq driver into the memory driver and remove the older IMC_STAT driver in v7, like it was suggested by Thierry Reding. This will be a much less invasive code change. > Also, if you want to get more responsiveness, you could use delayed timer > instead of deferrable timer by editing the devfreq_dev_profile structure. Thanks, I'll try the deferrable timer. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/msm/dp: promote irq_hpd handle to handle link trainign correctly
Some dongles, such as Apple, required link training done at irq_hpd
request instead of plugin request. This patch promote irq_hpd hanlder
to handle link training and setup hpd_state correctly.
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_display.c | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index 13b66266cd69..55627530957c 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -469,7 +469,9 @@ static int dp_display_handle_irq_hpd(struct
dp_display_private *dp)
static int dp_display_usbpd_attention_cb(struct device *dev)
{
int rc = 0;
+ u32 sink_request;
struct dp_display_private *dp;
+ struct dp_usbpd *hpd;
if (!dev) {
DRM_ERROR("invalid dev\n");
@@ -483,10 +485,24 @@ static int dp_display_usbpd_attention_cb(struct device
*dev)
return -ENODEV;
}
+ hpd = dp->usbpd;
+
/* check for any test request issued by sink */
rc = dp_link_process_request(dp->link);
- if (!rc)
- dp_display_handle_irq_hpd(dp);
+ if (!rc) {
+ sink_request = dp->link->sink_request;
+ if (sink_request & DS_PORT_STATUS_CHANGED) {
+ dp->hpd_state = ST_CONNECT_PENDING;
+ hpd->hpd_high = 1;
+ }
+
+ rc = dp_display_handle_irq_hpd(dp);
+
+ if (rc && sink_request & DS_PORT_STATUS_CHANGED) {
+ hpd->hpd_high = 0;
+ dp->hpd_state = ST_DISCONNECTED;
+ }
+ }
return rc;
}
base-commit: 0e162b10644605428cd2596c12f8ed410cf9d2d9
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 0/3] Reduce context clear batch size to avoid gpu hang
From: Randy Wright For several months, I've been experiencing GPU hangs when starting Cinnamon on an HP Pavilion Mini 300-020 if I try to run an upstream kernel. I reported this recently in https://gitlab.freedesktop.org/drm/intel/-/issues/2413 where I have attached the requested evidence including the state collected from /sys/class/drm/card0/error and debug output from dmesg. I ran a bisect to find the problem, which indicates this is the troublesome commit: [47f8253d2b8947d79fd3196bf96c1959c0f25f20] drm/i915/gen7: Clear all EU/L3 residual contexts The nature of that commit suggested to me that reducing the batch size used in the context clear operation might help this relatively low-powered system to avoid the hang and it did! I simply forced this system to take the smaller batch length that is already used for non-Haswell systems. The first two versions of this patch were posted as RFC patches to the Intel-gfx list, implementing the same algorithmic change in function batch_get_defaults, but without employing a properly constructed quirk. I've now cleaned up the patch to employ a new QUIRK_RENDERCLEAR_REDUCED. The quirk is presently set only for the aforementioned HP Pavilion Mini 300-020. The patch now touches three files to define the quirk, set it, and then check for it in function batch_get_defaults. Randy Wright (3): drm/i915: Introduce quirk QUIRK_RENDERCLEAR_REDUCED drm/i915/display: Add function quirk_renderclear_reduced drm/i915/gt: Force reduced batch size if new QUIRK_RENDERCLEAR_REDUCED is set. drivers/gpu/drm/i915/display/intel_quirks.c | 13 + drivers/gpu/drm/i915/gt/gen7_renderclear.c | 2 +- drivers/gpu/drm/i915/i915_drv.h | 1 + 3 files changed, 15 insertions(+), 1 deletion(-) -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/3] drm/panel: ABT Y030XX067A panel support
Hi, This patchset is for adding support for the Asia Better Technology (aka. ABT) Y030XX067A 3.0" 320x480 24-bit LCD IPS panel. While being 320x480 it is actually 4:3 with non-square pixels, and requires a specific bus format, as the pixel ordering changes each line (RGB on odd lines, GRB on even lines). Patch #1 adds the abt,* vendor prefix. Patch #2 adds the abt,y030xx067a panel binding documentation. Patch #3 adds the MEDIA_BUS_FMT_RGB888_3X8_DELTA media bus format. Patch #4 adds the driver itself. Cheers, -Paul Paul Cercueil (4): dt-bindings: vendor-prefixes: Add abt vendor prefix dt-bindings: display: Add ABT Y030XX067A panel bindings media: uapi: Add MEDIA_BUS_FMT_RGB888_3X8_DELTA media bus format drm/panel: Add ABT Y030XX067A 3.0" 320x480 panel .../display/panel/abt,y030xx067a.yaml | 54 +++ .../devicetree/bindings/vendor-prefixes.yaml | 2 + drivers/gpu/drm/panel/Kconfig | 9 + drivers/gpu/drm/panel/Makefile| 1 + drivers/gpu/drm/panel/panel-abt-y030xx067a.c | 363 ++ include/uapi/linux/media-bus-format.h | 3 +- 6 files changed, 431 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/display/panel/abt,y030xx067a.yaml create mode 100644 drivers/gpu/drm/panel/panel-abt-y030xx067a.c -- 2.28.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Outreachy kernel] [PATCH] drm/amdgpu: use DEFINE_DEBUGFS_ATTRIBUTE with debugfs_create_file_unsafe()
On Fri, Oct 30, 2020 at 10:24:57AM +0100, Daniel Vetter wrote: > On Fri, Oct 30, 2020 at 10:15:21AM +0100, Daniel Vetter wrote: > > On Fri, Oct 30, 2020 at 09:25:18AM +0100, Greg KH wrote: > > > On Fri, Oct 30, 2020 at 09:00:04AM +0100, Christian König wrote: > > > > Am 30.10.20 um 08:57 schrieb Deepak R Varma: > > > > > On Fri, Oct 30, 2020 at 08:11:20AM +0100, Greg KH wrote: > > > > > > On Fri, Oct 30, 2020 at 08:52:45AM +0530, Deepak R Varma wrote: > > > > > > > Using DEFINE_DEBUGFS_ATTRIBUTE macro with > > > > > > > debugfs_create_file_unsafe() > > > > > > > function in place of the debugfs_create_file() function will make > > > > > > > the > > > > > > > file operation struct "reset" aware of the file's lifetime. > > > > > > > Additional > > > > > > > details here: > > > > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.archive.carbon60.com%2Flinux%2Fkernel%2F2369498&data=04%7C01%7Cchristian.koenig%40amd.com%7Cddd7a6ac8164415a639708d87ca97004%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637396414464384011%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=o6GOHvMxNMuOPlC4nhDyURCHBLqfQZhYQq%2BiIMt3D3s%3D&reserved=0 > > > > > > > > > > > > > > Issue reported by Coccinelle script: > > > > > > > scripts/coccinelle/api/debugfs/debugfs_simple_attr.cocci > > > > > > > > > > > > > > Signed-off-by: Deepak R Varma > > > > > > > --- > > > > > > > Please Note: This is a Outreachy project task patch. > > > > > > > > > > > > > > drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 20 > > > > > > > ++-- > > > > > > > 1 file changed, 10 insertions(+), 10 deletions(-) > > > > > > > > > > > > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c > > > > > > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c > > > > > > > index 2d125b8b15ee..f076b1ba7319 100644 > > > > > > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c > > > > > > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c > > > > > > > @@ -1551,29 +1551,29 @@ static int amdgpu_debugfs_sclk_set(void > > > > > > > *data, u64 val) > > > > > > > return 0; > > > > > > > } > > > > > > > -DEFINE_SIMPLE_ATTRIBUTE(fops_ib_preempt, NULL, > > > > > > > - amdgpu_debugfs_ib_preempt, "%llu\n"); > > > > > > > +DEFINE_DEBUGFS_ATTRIBUTE(fops_ib_preempt, NULL, > > > > > > > + amdgpu_debugfs_ib_preempt, "%llu\n"); > > > > > > Are you sure this is ok? Do these devices need this additional > > > > > > "protection"? Do they have the problem that these macros were > > > > > > written > > > > > > for? > > > > > > > > > > > > Same for the other patches you just submitted here, I think you > > > > > > need to > > > > > > somehow "prove" that these changes are necessary, checkpatch isn't > > > > > > able > > > > > > to determine this all the time. > > > > > Hi Greg, > > > > > Based on my understanding, the current function debugfs_create_file() > > > > > adds an overhead of lifetime managing proxy for such fop structs. This > > > > > should be applicable to these set of drivers as well. Hence I think > > > > > this > > > > > change will be useful. > > > > > > > > Well since this is only created once per device instance I don't really > > > > care > > > > about this little overhead. > > > > > > > > But what exactly is debugfs doing or not doing here? > > > > > > It is trying to save drivers from having debugfs files open that point > > > to memory that can go away at any time. For graphics devices, I doubt > > > that is the case. > > > > So for anything we add/remove we have two-stage cleanup > > > > 1. drm_dev_unregister (or drm_connector_unregisters, those are the only > > two hotunpluggable things we have) unregister all the uapi interfaces. > > This deletes all the sysfs and debugfs files. > > > > 2. Once all the references to the underlying object disappear from the > > kernel, we free up the data structure. > > > > Now for chardev and similar uapi, we hold full references for open files. > > But for sysfs and debugfs we assume that those uapi layers will make sure > > that after we deleted the files in step 1 all access through these > > functions are guaranteed to have finished. If that's not the case, then we > > need to rework our refcounting and also refcount the underlying drm > > structure (drm_device or drm_connector) from sysfs/debugfs files. > > > > Now I tried to look at the patch Deepak references, and I'm not really > > clear what changes. Or whether we made a wrong assumption previously about > > what debugfs/sysfs guarantee when we delete the files. > > I read some more code and kerneldoc, and I still have no idea what this > new _unsafe variant is used for. Only ones I've found seem to use > debugfs_file_get/put like the normal variant, to protect against > concurrently removed files due to hotunplug. Which is kinda what we've > been expecting debugfs to do for us. > > What's a use-case for
Re: [Outreachy kernel] [PATCH] drm/amdgpu: use DEFINE_DEBUGFS_ATTRIBUTE with debugfs_create_file_unsafe()
On Fri, 30 Oct 2020, Greg KH wrote: > On Fri, Oct 30, 2020 at 01:47:05PM +0530, Sumera Priyadarsini wrote: > > On Fri, 30 Oct, 2020, 1:32 PM Greg KH, wrote: > > > > > On Fri, Oct 30, 2020 at 01:27:16PM +0530, Deepak R Varma wrote: > > > > On Fri, Oct 30, 2020 at 08:11:20AM +0100, Greg KH wrote: > > > > > On Fri, Oct 30, 2020 at 08:52:45AM +0530, Deepak R Varma wrote: > > > > > > Using DEFINE_DEBUGFS_ATTRIBUTE macro with > > > debugfs_create_file_unsafe() > > > > > > function in place of the debugfs_create_file() function will make > > > > > > the > > > > > > file operation struct "reset" aware of the file's lifetime. > > > Additional > > > > > > details here: > > > https://lists.archive.carbon60.com/linux/kernel/2369498 > > > > > > > > > > > > Issue reported by Coccinelle script: > > > > > > scripts/coccinelle/api/debugfs/debugfs_simple_attr.cocci > > > > > > > > > > > > Signed-off-by: Deepak R Varma > > > > > > --- > > > > > > Please Note: This is a Outreachy project task patch. > > > > > > > > > > > > drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 20 > > > ++-- > > > > > > 1 file changed, 10 insertions(+), 10 deletions(-) > > > > > > > > > > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c > > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c > > > > > > index 2d125b8b15ee..f076b1ba7319 100644 > > > > > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c > > > > > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c > > > > > > @@ -1551,29 +1551,29 @@ static int amdgpu_debugfs_sclk_set(void > > > *data, u64 val) > > > > > > return 0; > > > > > > } > > > > > > > > > > > > -DEFINE_SIMPLE_ATTRIBUTE(fops_ib_preempt, NULL, > > > > > > - amdgpu_debugfs_ib_preempt, "%llu\n"); > > > > > > +DEFINE_DEBUGFS_ATTRIBUTE(fops_ib_preempt, NULL, > > > > > > + amdgpu_debugfs_ib_preempt, "%llu\n"); > > > > > > > > > > Are you sure this is ok? Do these devices need this additional > > > > > "protection"? Do they have the problem that these macros were written > > > > > for? > > > > > > > > > > Same for the other patches you just submitted here, I think you need > > > > > to > > > > > somehow "prove" that these changes are necessary, checkpatch isn't > > > > > able > > > > > to determine this all the time. > > > > > > > > Hi Greg, > > > > Based on my understanding, the current function debugfs_create_file() > > > > adds an overhead of lifetime managing proxy for such fop structs. This > > > > should be applicable to these set of drivers as well. Hence I think this > > > > change will be useful. > > > > > > Why do these drivers need these changes? Are these files dynamically > > > removed from the system at random times? > > > > > > There is a reason we didn't just do a global search/replace for this in > > > the kernel when the new functions were added, so I don't know why > > > checkpatch is now saying it must be done. > > > > > > > Hi, > > > > Sorry to jump in on the thread this way, but what exactly does a 'lifetime > > managing proxy' for file operations mean? I am trying to understand how > > DEFINE_DEBUGFS_ATTRIBUTE changes things wrt debug_ fs file operations but > > can't find many resources. :( > > It means that the debugfs core can handle debugfs files being removed > from the system while they are still open when they were created by a > driver/module that is now unloaded from memory. > > This is only an issue for drivers that manage devices that have unknown > lifespans (i.e. they can be yanked out of the system at any time, and > the memory for those debugfs files can be freed). > > For the entire DRM/GPU subsystem, I strongly doubt this is the case. > > > Please let me know if I should be asking this in a different mailing > > list/irc instead. > > > > The change seems to be suggested by a coccinelle script. > > I know, and I don't think that script knows the nuances behind this, as, > again, we would have just done a global search/replace for this when the > debugfs fixes went into the kernel. The script comes from Nicolai Stange . If there are some precise considerations that make the change likely to be useful, then the script can be changed. If the script is not helpful, then it can be removed. julia > > thanks, > > greg k-h > > -- > You received this message because you are subscribed to the Google Groups > "outreachy-kernel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to outreachy-kernel+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/outreachy-kernel/20201030082425.GA1619669%40kroah.com. > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/3] drm/i915: Introduce quirk QUIRK_RENDERCLEAR_REDUCED
From: Randy Wright
Introduce quirk QUIRK_RENDERCLEAR_REDUCED, which will be used
to force a limited batch buffer size for clearing
residual contexts in gen7_renderclear.c.
Signed-off-by: Randy Wright
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e4f7f6518945..e8873462eb2c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -525,6 +525,7 @@ struct i915_psr {
#define QUIRK_PIN_SWIZZLED_PAGES (1<<5)
#define QUIRK_INCREASE_T12_DELAY (1<<6)
#define QUIRK_INCREASE_DDI_DISABLED_TIME (1<<7)
+#define QUIRK_RENDERCLEAR_REDUCED (1<<8)
struct intel_fbdev;
struct intel_fbc_work;
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Outreachy kernel] [PATCH] drm/amdgpu: use DEFINE_DEBUGFS_ATTRIBUTE with debugfs_create_file_unsafe()
On Fri, 30 Oct, 2020, 1:32 PM Greg KH, wrote: > On Fri, Oct 30, 2020 at 01:27:16PM +0530, Deepak R Varma wrote: > > On Fri, Oct 30, 2020 at 08:11:20AM +0100, Greg KH wrote: > > > On Fri, Oct 30, 2020 at 08:52:45AM +0530, Deepak R Varma wrote: > > > > Using DEFINE_DEBUGFS_ATTRIBUTE macro with > debugfs_create_file_unsafe() > > > > function in place of the debugfs_create_file() function will make the > > > > file operation struct "reset" aware of the file's lifetime. > Additional > > > > details here: > https://lists.archive.carbon60.com/linux/kernel/2369498 > > > > > > > > Issue reported by Coccinelle script: > > > > scripts/coccinelle/api/debugfs/debugfs_simple_attr.cocci > > > > > > > > Signed-off-by: Deepak R Varma > > > > --- > > > > Please Note: This is a Outreachy project task patch. > > > > > > > > drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 20 > ++-- > > > > 1 file changed, 10 insertions(+), 10 deletions(-) > > > > > > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c > > > > index 2d125b8b15ee..f076b1ba7319 100644 > > > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c > > > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c > > > > @@ -1551,29 +1551,29 @@ static int amdgpu_debugfs_sclk_set(void > *data, u64 val) > > > > return 0; > > > > } > > > > > > > > -DEFINE_SIMPLE_ATTRIBUTE(fops_ib_preempt, NULL, > > > > - amdgpu_debugfs_ib_preempt, "%llu\n"); > > > > +DEFINE_DEBUGFS_ATTRIBUTE(fops_ib_preempt, NULL, > > > > + amdgpu_debugfs_ib_preempt, "%llu\n"); > > > > > > Are you sure this is ok? Do these devices need this additional > > > "protection"? Do they have the problem that these macros were written > > > for? > > > > > > Same for the other patches you just submitted here, I think you need to > > > somehow "prove" that these changes are necessary, checkpatch isn't able > > > to determine this all the time. > > > > Hi Greg, > > Based on my understanding, the current function debugfs_create_file() > > adds an overhead of lifetime managing proxy for such fop structs. This > > should be applicable to these set of drivers as well. Hence I think this > > change will be useful. > > Why do these drivers need these changes? Are these files dynamically > removed from the system at random times? > > There is a reason we didn't just do a global search/replace for this in > the kernel when the new functions were added, so I don't know why > checkpatch is now saying it must be done. > Hi, Sorry to jump in on the thread this way, but what exactly does a 'lifetime managing proxy' for file operations mean? I am trying to understand how DEFINE_DEBUGFS_ATTRIBUTE changes things wrt debug_ fs file operations but can't find many resources. :( Please let me know if I should be asking this in a different mailing list/irc instead. The change seems to be suggested by a coccinelle script. Regards, Sumera thanks, > > greg k-h > > -- > You received this message because you are subscribed to the Google Groups > "outreachy-kernel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to outreachy-kernel+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/outreachy-kernel/20201030080316.GA1612206%40kroah.com > . > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/msm/dsi: do not try reading 28nm vco rate if it's not enabled
Reading VCO rate for this PLL can cause boot stalls, if it is not enabled. Guard clk_hw_get_rate with a call to dsi_pll_28nm_clk_is_enabled(). Signed-off-by: Dmitry Baryshkov --- drivers/gpu/drm/msm/dsi/pll/dsi_pll_28nm.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/dsi/pll/dsi_pll_28nm.c b/drivers/gpu/drm/msm/dsi/pll/dsi_pll_28nm.c index 6dffd7f4a99b..37a1f996a588 100644 --- a/drivers/gpu/drm/msm/dsi/pll/dsi_pll_28nm.c +++ b/drivers/gpu/drm/msm/dsi/pll/dsi_pll_28nm.c @@ -447,7 +447,10 @@ static void dsi_pll_28nm_save_state(struct msm_dsi_pll *pll) cached_state->postdiv1 = pll_read(base + REG_DSI_28nm_PHY_PLL_POSTDIV1_CFG); cached_state->byte_mux = pll_read(base + REG_DSI_28nm_PHY_PLL_VREG_CFG); - cached_state->vco_rate = clk_hw_get_rate(&pll->clk_hw); + if (dsi_pll_28nm_clk_is_enabled(&pll->clk_hw)) + cached_state->vco_rate = clk_hw_get_rate(&pll->clk_hw); + else + cached_state->vco_rate = 0; } static int dsi_pll_28nm_restore_state(struct msm_dsi_pll *pll) -- 2.28.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/atomic: Pass the full state to CRTC atomic begin and flush
On Thu, Oct 29, 2020 at 03:55:37PM +0200, Ville Syrjälä wrote:
> On Wed, Oct 28, 2020 at 01:32:22PM +0100, Maxime Ripard wrote:
> > The current atomic helpers have either their object state being passed as
> > an argument or the full atomic state.
> >
> > The former is the pattern that was done at first, before switching to the
> > latter for new hooks or when it was needed.
> >
> > Let's start convert all the remaining helpers to provide a consistent
> > interface, starting with the CRTC's atomic_begin and atomic_flush.
> >
> > The conversion was done using the coccinelle script below, built tested on
> > all the drivers and actually tested on vc4.
> >
>
> > @@ -323,26 +323,27 @@ static void ingenic_drm_crtc_atomic_begin(struct
> > drm_crtc *crtc,
> > }
> >
> > static void ingenic_drm_crtc_atomic_flush(struct drm_crtc *crtc,
> > - struct drm_crtc_state *oldstate)
> > + struct drm_atomic_state *state)
> > {
> > struct ingenic_drm *priv = drm_crtc_get_priv(crtc);
> > - struct drm_crtc_state *state = crtc->state;
> > - struct drm_pending_vblank_event *event = state->event;
> > + struct drm_crtc_state *crtc_state = crtc->state;
>
> Looks like quite a few places could use a followup to
> switch to get_{old,new}_crtc_state().
That one is not entirely clear to me. crtc->state is documented as the
current CRTC state, but in atomic_begin / atomic_flush, does that mean
that it's the old state that we're going to replace, or the new state
that is going to replace the current state?
> Patch lgtm
> Reviewed-by: Ville Syrjälä
Thanks!
Maxime
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] staging: fbtft: fb_watterott: fix usleep_range is preferred over udelay
Fix the checkpath.pl issue on fb_watterott.c. write_vmem and write_vmem_8bit functions are within non-atomic context and can safely use usleep_range. see Documentation/timers/timers-howto.txt Signed-off-by: Hassan Shahbazi --- drivers/staging/fbtft/fb_watterott.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/fbtft/fb_watterott.c b/drivers/staging/fbtft/fb_watterott.c index 76b25df376b8..afcc86a17995 100644 --- a/drivers/staging/fbtft/fb_watterott.c +++ b/drivers/staging/fbtft/fb_watterott.c @@ -84,7 +84,7 @@ static int write_vmem(struct fbtft_par *par, size_t offset, size_t len) par->txbuf.buf, 10 + par->info->fix.line_length); if (ret < 0) return ret; - udelay(300); + usleep_range(300, 310); } return 0; @@ -124,7 +124,7 @@ static int write_vmem_8bit(struct fbtft_par *par, size_t offset, size_t len) par->txbuf.buf, 10 + par->info->var.xres); if (ret < 0) return ret; - udelay(700); + usleep_range(700, 710); } return 0; -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 51/52] PM / devfreq: tegra30: Support interconnect and OPPs from device-tree
01.11.2020 18:44, Chanwoo Choi пишет: >> OPP core will try to grab the clock reference for the table and it may >> cause EPROBE_DEFER. Although, it shouldn't happen here because we have >> devm_clk_get() before the get_opp_table(), hence seems the deferred >> probe indeed shouldn't happen in this case. > It is my missing point. If there, you're right. > Could you provide the code point to check the clock reference on the OPP core? Please see it here: https://elixir.bootlin.com/linux/v5.10-rc1/source/drivers/opp/core.c#L1101 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Introduce devm_pm_opp_set_* API
On 28-10-20, 11:36, Viresh Kumar wrote: > On 12-10-20, 21:55, Frank Lee wrote: > > Hi, this patchset introduce devm_pm_opp_set_prop_name() and > > devm_pm_opp_set_supported_hw(). > > > > Yangtao Li (3): > > opp: Add devres wrapper for dev_pm_opp_set_supported_hw > > opp: Add devres wrapper for dev_pm_opp_set_prop_name > > drm/msm: Convert to devm_pm_opp_set_supported_hw > > > > drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 2 +- > > drivers/opp/core.c| 80 +++ > > include/linux/pm_opp.h| 14 + > > 3 files changed, 95 insertions(+), 1 deletion(-) > > Applied. Thanks. And I have dropped all of them based on the discussion we are having. Thanks. -- viresh ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/3] drm/i915/display: Add function quirk_renderclear_reduced
From: Randy Wright
Added function quirk_renderclear_reduced to set QUIRK_RENDERCLEAR_REDUCED
for designated platforms. Applying QUIRK_RENDERCLEAR_REDUCED for
the HP Pavilion Mini 300-020 prevents a GPU hang.
Signed-off-by: Randy Wright
---
drivers/gpu/drm/i915/display/intel_quirks.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_quirks.c
b/drivers/gpu/drm/i915/display/intel_quirks.c
index 46beb155d835..630b984ba49c 100644
--- a/drivers/gpu/drm/i915/display/intel_quirks.c
+++ b/drivers/gpu/drm/i915/display/intel_quirks.c
@@ -53,6 +53,16 @@ static void quirk_increase_ddi_disabled_time(struct
drm_i915_private *i915)
drm_info(&i915->drm, "Applying Increase DDI Disabled quirk\n");
}
+/*
+ * Force use of smaller batch size in gen7_renderclear.c
+ * Needed on (at least) HP Pavilion Mini 300-020 to avoid GPU hang.
+ */
+static void quirk_renderclear_reduced(struct drm_i915_private *i915)
+{
+ i915->quirks |= QUIRK_RENDERCLEAR_REDUCED;
+ drm_info(&i915->drm, "Applying Renderclear Reduced quirk\n");
+}
+
struct intel_quirk {
int device;
int subsystem_vendor;
@@ -141,6 +151,9 @@ static struct intel_quirk intel_quirks[] = {
/* HP Chromebook 14 (Celeron 2955U) */
{ 0x0a06, 0x103c, 0x21ed, quirk_backlight_present },
+ /* HP Mini 300-020 */
+ { 0x0a06, 0x103c, 0x2b38, quirk_renderclear_reduced },
+
/* Dell Chromebook 11 */
{ 0x0a06, 0x1028, 0x0a35, quirk_backlight_present },
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/4] drm/bridge: ti-sn65dsi86: Support EDID reading
Hi Stephen. On Thu, Oct 29, 2020 at 06:17:34PM -0700, Stephen Boyd wrote: > This patch series cleans up the DDC code a little bit so that > it is more efficient time wise and supports grabbing the EDID > of the eDP panel over the aux channel. I timed this on a board > I have on my desk and it takes about 20ms to grab the EDID out > of the panel and make sure it is valid. > > The first two patches seem less controversial so I stuck them at > the beginning. The third patch does the EDID reading and caches > it so we don't have to keep grabbing it over and over again. And > finally the last patch updates the reply field so that short > reads and nacks over the channel are reflected properly instead of > treating them as some sort of error that can't be discerned. > > Stephen Boyd (4): > drm/bridge: ti-sn65dsi86: Combine register accesses in > ti_sn_aux_transfer() > drm/bridge: ti-sn65dsi86: Make polling a busy loop > drm/bridge: ti-sn65dsi86: Read EDID blob over DDC > drm/bridge: ti-sn65dsi86: Update reply on aux failures Series looks good. You can add my a-b on the full series. Acked-by: Sam Ravnborg I can apply after Douglas have had a look at the patches he did not r-b yet. Any chance we can convince you to prepare this bridge driver for use in a chained bridge setup where the connector is created by the display driver and uses drm_bridge_funcs? First step wuld be to introduce the use of a panel_bridge. Then add get_edid to drm_bridge_funcs and maybe more helpers. Then natural final step would be to move connector creation to the display driver - see how other uses drm_bridge_connector_init() to do so - it is relatively simple. Should be doable - and reach out if you need some help. Sam > > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 108 ++ > 1 file changed, 75 insertions(+), 33 deletions(-) > > Cc: Douglas Anderson > Cc: Laurent Pinchart > Cc: Jonas Karlman > Cc: Jernej Skrabec > Cc: Sean Paul > > base-commit: 3650b228f83adda7e5ee532e2b90429c03f7b9ec > -- > Sent by a computer, using git, on the internet > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/panfrost: Remove unused variables in panfrost_job_close()
Commit a17d609e3e21 ("drm/panfrost: Don't corrupt the queue mutex on
open/close") left unused variables behind, thus generating a warning
at compilation time. Remove those variables.
Fixes: a17d609e3e21 ("drm/panfrost: Don't corrupt the queue mutex on
open/close")
Signed-off-by: Boris Brezillon
---
My bad, I didn't notice this warning when rebasing Steven's patch on
top of drm-misc-next :-/
---
drivers/gpu/drm/panfrost/panfrost_job.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c
b/drivers/gpu/drm/panfrost/panfrost_job.c
index 14c11293791e..d58e5fe12cab 100644
--- a/drivers/gpu/drm/panfrost/panfrost_job.c
+++ b/drivers/gpu/drm/panfrost/panfrost_job.c
@@ -634,8 +634,6 @@ int panfrost_job_open(struct panfrost_file_priv
*panfrost_priv)
void panfrost_job_close(struct panfrost_file_priv *panfrost_priv)
{
- struct panfrost_device *pfdev = panfrost_priv->pfdev;
- struct panfrost_job_slot *js = pfdev->js;
int i;
for (i = 0; i < NUM_JOB_SLOTS; i++)
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv7 1/7] iommu/io-pgtable-arm: Add support to use system cache
Add a quirk IO_PGTABLE_QUIRK_SYS_CACHE to override the
attributes set in TCR for the page table walker when
using system cache.
Signed-off-by: Sai Prakash Ranjan
---
drivers/iommu/io-pgtable-arm.c | 7 ++-
include/linux/io-pgtable.h | 4
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
index a7a9bc08dcd1..a356caf1683a 100644
--- a/drivers/iommu/io-pgtable-arm.c
+++ b/drivers/iommu/io-pgtable-arm.c
@@ -761,7 +761,8 @@ arm_64_lpae_alloc_pgtable_s1(struct io_pgtable_cfg *cfg,
void *cookie)
if (cfg->quirks & ~(IO_PGTABLE_QUIRK_ARM_NS |
IO_PGTABLE_QUIRK_NON_STRICT |
- IO_PGTABLE_QUIRK_ARM_TTBR1))
+ IO_PGTABLE_QUIRK_ARM_TTBR1 |
+ IO_PGTABLE_QUIRK_SYS_CACHE))
return NULL;
data = arm_lpae_alloc_pgtable(cfg);
@@ -773,6 +774,10 @@ arm_64_lpae_alloc_pgtable_s1(struct io_pgtable_cfg *cfg,
void *cookie)
tcr->sh = ARM_LPAE_TCR_SH_IS;
tcr->irgn = ARM_LPAE_TCR_RGN_WBWA;
tcr->orgn = ARM_LPAE_TCR_RGN_WBWA;
+ } else if (cfg->quirks & IO_PGTABLE_QUIRK_SYS_CACHE) {
+ tcr->sh = ARM_LPAE_TCR_SH_OS;
+ tcr->irgn = ARM_LPAE_TCR_RGN_NC;
+ tcr->orgn = ARM_LPAE_TCR_RGN_WBWA;
} else {
tcr->sh = ARM_LPAE_TCR_SH_OS;
tcr->irgn = ARM_LPAE_TCR_RGN_NC;
diff --git a/include/linux/io-pgtable.h b/include/linux/io-pgtable.h
index 4cde111e425b..86631f711e05 100644
--- a/include/linux/io-pgtable.h
+++ b/include/linux/io-pgtable.h
@@ -86,6 +86,9 @@ struct io_pgtable_cfg {
*
* IO_PGTABLE_QUIRK_ARM_TTBR1: (ARM LPAE format) Configure the table
* for use in the upper half of a split address space.
+*
+* IO_PGTABLE_QUIRK_SYS_CACHE: Override the attributes set in TCR for
+* the page table walker when using system cache.
*/
#define IO_PGTABLE_QUIRK_ARM_NS BIT(0)
#define IO_PGTABLE_QUIRK_NO_PERMS BIT(1)
@@ -93,6 +96,7 @@ struct io_pgtable_cfg {
#define IO_PGTABLE_QUIRK_ARM_MTK_EXTBIT(3)
#define IO_PGTABLE_QUIRK_NON_STRICT BIT(4)
#define IO_PGTABLE_QUIRK_ARM_TTBR1 BIT(5)
+ #define IO_PGTABLE_QUIRK_SYS_CACHE BIT(6)
unsigned long quirks;
unsigned long pgsize_bitmap;
unsigned intias;
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv7 0/7] System Cache support for GPU and required SMMU support
Some hardware variants contain a system cache or the last level cache(llc). This cache is typically a large block which is shared by multiple clients on the SOC. GPU uses the system cache to cache both the GPU data buffers(like textures) as well the SMMU pagetables. This helps with improved render performance as well as lower power consumption by reducing the bus traffic to the system memory. The system cache architecture allows the cache to be split into slices which then be used by multiple SOC clients. This patch series is an effort to enable and use two of those slices preallocated for the GPU, one for the GPU data buffers and another for the GPU SMMU hardware pagetables. Patch 1 - Patch 5 adds system cache support in SMMU and GPU driver. Patch 6 and 7 are minor cleanups for arm-smmu impl. Changes in v7: * Squash Jordan's patch to support MMU500 targets * Rebase on top of for-joerg/arm-smmu/updates and Jordan's short series for adreno-smmu impl Changes in v6: * Move table to arm-smmu-qcom (Robin) Changes in v5: * Drop cleanup of blank lines since it was intentional (Robin) * Rebase again on top of msm-next-pgtables as it moves pretty fast Changes in v4: * Drop IOMMU_SYS_CACHE prot flag * Rebase on top of https://gitlab.freedesktop.org/drm/msm/-/tree/msm-next-pgtables Changes in v3: * Fix domain attribute setting to before iommu_attach_device() * Fix few code style and checkpatch warnings * Rebase on top of Jordan's latest split pagetables and per-instance pagetables support Changes in v2: * Addressed review comments and rebased on top of Jordan's split pagetables series Jordan Crouse (1): drm/msm/a6xx: Add support for using system cache on MMU500 based targets Sai Prakash Ranjan (4): iommu/io-pgtable-arm: Add support to use system cache iommu/arm-smmu: Add domain attribute for system cache iommu: arm-smmu-impl: Use table to list QCOM implementations iommu: arm-smmu-impl: Add a space before open parenthesis Sharat Masetty (2): drm/msm: rearrange the gpu_rmw() function drm/msm/a6xx: Add support for using system cache(LLC) drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 109 + drivers/gpu/drm/msm/adreno/a6xx_gpu.h | 5 + drivers/gpu/drm/msm/adreno/adreno_gpu.c| 17 drivers/gpu/drm/msm/msm_drv.c | 8 ++ drivers/gpu/drm/msm/msm_drv.h | 1 + drivers/gpu/drm/msm/msm_gpu.h | 5 +- drivers/iommu/arm/arm-smmu/arm-smmu-impl.c | 11 +-- drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 21 +++- drivers/iommu/arm/arm-smmu/arm-smmu.c | 17 drivers/iommu/arm/arm-smmu/arm-smmu.h | 2 +- drivers/iommu/io-pgtable-arm.c | 7 +- include/linux/io-pgtable.h | 4 + include/linux/iommu.h | 1 + 13 files changed, 188 insertions(+), 20 deletions(-) base-commit: f9081b8ff5934b8d69c748d0200e844cadd2c667 prerequisite-patch-id: db09851f375ca5efde35f2e5c21b3959eed7d8a8 prerequisite-patch-id: 55c6af17808c2047b67cdbd04af5541156ef496e prerequisite-patch-id: e82c1e678da701e112ac255ea966c6797d975692 prerequisite-patch-id: f7978f5f2fb06528b7a1f75fa4255e386a30b91a -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: WARNING in dma_map_page_attrs
> From: h...@lst.de > Sent: Wednesday, October 28, 2020 11:01 PM > > On Tue, Oct 27, 2020 at 12:52:30PM +, Parav Pandit wrote: > > > > > From: h...@lst.de > > > Sent: Tuesday, October 27, 2020 1:41 PM > > > > > > On Mon, Oct 26, 2020 at 05:23:48AM +, Parav Pandit wrote: > > > > Hi Christoph, > > > > > > > > > From: Jakub Kicinski > > > > > Sent: Saturday, October 24, 2020 11:45 PM > > > > > > > > > > CC: rdma, looks like rdma from the stack trace > > > > > > > > > > On Fri, 23 Oct 2020 20:07:17 -0700 syzbot wrote: > > > > > > syzbot has found a reproducer for the following issue on: > > > > > > > > > > > > HEAD commit:3cb12d27 Merge tag 'net-5.10-rc1' of > > > git://git.kernel.org/.. > > > > > > > > In [1] you mentioned that dma_mask should not be set for > dma_virt_ops. > > > > So patch [2] removed it. > > > > > > > > But check to validate the dma mask for all dma_ops was added in [3]. > > > > > > > > What is the right way? Did I misunderstood your comment about > > > dma_mask in [1]? > > > > > > No, I did not say we don't need the mask. I said copying over the > > > various dma-related fields from the parent is bogus. > > > > > > I think rxe (and ther other drivers/infiniband/sw drivers) need a > > > simple dma_coerce_mask_and_coherent and nothing else. > > > > I see. Does below fix make sense? > > Is DMA_MASK_NONE correct? > > DMA_MASK_NONE is gone in 5.10. I think you want DMA_BIT_MASK(64). > That isn't actually correct for 32-bit platforms, but good enough. Ok. thanks for the input. Sending updated fix to set 64-bit mask for 64-bit platform and 32-bit mask otherwise. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/bridge: tpd12s015: Fix irq registering in tpd12s015_probe
gpiod_to_irq() return negative value in case of error,
the existing code handle negative error codes wrongly.
Fixes: cff5e6f7e83f ("drm/bridge: Add driver for the TI TPD12S015 HDMI level
shifter")
Signed-off-by: YueHaibing
---
drivers/gpu/drm/bridge/ti-tpd12s015.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/ti-tpd12s015.c
b/drivers/gpu/drm/bridge/ti-tpd12s015.c
index 514cbf0eac75..a18d5197c16c 100644
--- a/drivers/gpu/drm/bridge/ti-tpd12s015.c
+++ b/drivers/gpu/drm/bridge/ti-tpd12s015.c
@@ -160,7 +160,7 @@ static int tpd12s015_probe(struct platform_device *pdev)
/* Register the IRQ if the HPD GPIO is IRQ-capable. */
tpd->hpd_irq = gpiod_to_irq(tpd->hpd_gpio);
- if (tpd->hpd_irq) {
+ if (tpd->hpd_irq > 0) {
ret = devm_request_threaded_irq(&pdev->dev, tpd->hpd_irq, NULL,
tpd12s015_hpd_isr,
IRQF_TRIGGER_RISING |
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/atomic: Pass the full state to CRTC atomic_check
Hi!
Thanks for reviewing those patches
On Thu, Oct 29, 2020 at 03:50:41PM +0200, Ville Syrjälä wrote:
> On Wed, Oct 28, 2020 at 01:32:21PM +0100, Maxime Ripard wrote:
> > The current atomic helpers have either their object state being passed as
> > an argument or the full atomic state.
> >
> > The former is the pattern that was done at first, before switching to the
> > latter for new hooks or when it was needed.
> >
> > Let's start convert all the remaining helpers to provide a consistent
> > interface, starting with the CRTC's atomic_check.
> >
> > The conversion was done using the coccinelle script below,
> > built tested on all the drivers and actually tested on vc4.
> >
> > virtual report
>
> ?
>
>
> > @ depends on crtc_atomic_func @
> > identifier crtc_atomic_func.func;
> > expression E;
> > type T;
> > @@
> >
> > int func(...)
> > {
> > ...
> > - T state = E;
> > + T crtc_state = E;
> > <+...
> > - state
> > + crtc_state
> > ...+>
>
> > }
> >
> > @ depends on crtc_atomic_func @
> > identifier crtc_atomic_func.func;
> > type T;
> > @@
> >
> > int func(...)
> > {
> > ...
> > - T state;
> > + T crtc_state;
> > <+...
> > - state
> > + crtc_state
> > ...+>
> > }
>
> These two seem a bit fuzzy. AFAICS 'state' could be any
> kind of state given the constrainsts. Though I guess
> the fact that this is the crtc .atomic_check() it's most
> likely to either the crtc state or the whole atomic state.
>
> Not sure what would be the best way to tighten this up.
> Maybe a regex thing on the assignment? But I'm not sure
> you can even do that on an expression.
That would be a bit above my current coccinelle skills :)
I guess we could replace T by struct drm_crtc_state, that would catch
most cases like you pointed out, even though it's still not completely
accurate.
> Anyways, doesn't look like this went wrong anywhere, so
> seems good enough for a onetime job.
>
>
> > diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
> > b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
> > index 956f631997f2..b0757f84a979 100644
> > --- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
> > +++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
> > @@ -269,17 +269,19 @@ static void mxsfb_crtc_mode_set_nofb(struct
> > mxsfb_drm_private *mxsfb)
> > }
> >
> > static int mxsfb_crtc_atomic_check(struct drm_crtc *crtc,
> > - struct drm_crtc_state *state)
> > + struct drm_atomic_state *state)
> > {
> > - bool has_primary = state->plane_mask &
> > + struct drm_crtc_state *crtc_state = drm_atomic_get_new_crtc_state(state,
> > + crtc);
> > + bool has_primary = crtc_state->plane_mask &
> >drm_plane_mask(crtc->primary);
> >
> > /* The primary plane has to be enabled when the CRTC is active. */
> > - if (state->active && !has_primary)
> > + if (crtc_state->active && !has_primary)
> > return -EINVAL;
> >
> > /* TODO: Is this needed ? */
> > - return drm_atomic_add_affected_planes(state->state, crtc);
> > + return drm_atomic_add_affected_planes(crtc_state->state, crtc);
>
> Could also s/crtc_state->state/state/ in various places.
>
> But that could done as a followup as well.
I'll send a subsequent patch for that one
> Didn't spot any mistakes:
> Reviewed-by: Ville Syrjälä
Thanks!
Maxime
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/4] dt-bindings: vendor-prefixes: Add abt vendor prefix
Add prefix for ShenZhen Asia Better Technology Ltd. Signed-off-by: Paul Cercueil --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 0e384959e870..2040f46396de 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -29,6 +29,8 @@ patternProperties: description: Abilis Systems "^abracon,.*": description: Abracon Corporation + "^abt,.*": +description: ShenZhen Asia Better Technology Ltd. "^acer,.*": description: Acer Inc. "^acme,.*": -- 2.28.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: bridge: dw-hdmi: Avoid resetting force in the detect function
It has been observed that resetting force in the detect function can
result in the PHY being powered down in response to hot-plug detect
being asserted, even when the HDMI connector is forced on.
Enabling debug messages and adding a call to dump_stack() in
dw_hdmi_phy_power_off() shows the following in dmesg:
[ 160.637413] dwhdmi-rockchip ff94.hdmi: EVENT=plugin
[ 160.637433] dwhdmi-rockchip ff94.hdmi: PHY powered down in 0 iterations
Call trace:
dw_hdmi_phy_power_off
dw_hdmi_phy_disable
dw_hdmi_update_power
dw_hdmi_detect
dw_hdmi_connector_detect
drm_helper_probe_detect_ctx
drm_helper_hpd_irq_event
dw_hdmi_irq
irq_thread_fn
irq_thread
kthread
ret_from_fork
Fixes: 381f05a7a842 ("drm: bridge/dw_hdmi: add connector mode forcing")
Signed-off-by: Jonathan Liu
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 748df1cacd2b..0c79a9ba48bb 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -2327,12 +2327,6 @@ static enum drm_connector_status dw_hdmi_detect(struct
dw_hdmi *hdmi)
{
enum drm_connector_status result;
- mutex_lock(&hdmi->mutex);
- hdmi->force = DRM_FORCE_UNSPECIFIED;
- dw_hdmi_update_power(hdmi);
- dw_hdmi_update_phy_mask(hdmi);
- mutex_unlock(&hdmi->mutex);
-
result = hdmi->phy.ops->read_hpd(hdmi, hdmi->phy.data);
mutex_lock(&hdmi->mutex);
--
2.29.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/4] media: uapi: Add MEDIA_BUS_FMT_RGB888_3X8_DELTA media bus format
Add media bus format for 24-bit panels that expect their pixel data to be sent serially on a 8-bit bus, in RGB ordering on odd lines, and in GBR ordering on even lines (aka delta-RGB). Signed-off-by: Paul Cercueil --- include/uapi/linux/media-bus-format.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/include/uapi/linux/media-bus-format.h b/include/uapi/linux/media-bus-format.h index 84fa53ffb13f..5d905ad6dbb2 100644 --- a/include/uapi/linux/media-bus-format.h +++ b/include/uapi/linux/media-bus-format.h @@ -34,7 +34,7 @@ #define MEDIA_BUS_FMT_FIXED0x0001 -/* RGB - next is 0x101d */ +/* RGB - next is 0x101e */ #define MEDIA_BUS_FMT_RGB444_1X12 0x1016 #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_BE 0x1001 #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_LE 0x1002 @@ -56,6 +56,7 @@ #define MEDIA_BUS_FMT_RGB888_2X12_BE 0x100b #define MEDIA_BUS_FMT_RGB888_2X12_LE 0x100c #define MEDIA_BUS_FMT_RGB888_3X8 0x101c +#define MEDIA_BUS_FMT_RGB888_3X8_DELTA 0x101d #define MEDIA_BUS_FMT_RGB888_1X7X4_SPWG0x1011 #define MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA 0x1012 #define MEDIA_BUS_FMT_ARGB_1X320x100d -- 2.28.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/panfrost: Fix a deadlock between the shrinker and madvise path
panfrost_ioctl_madvise() and panfrost_gem_purge() acquire the mappings
and shmem locks in different orders, thus leading to a potential
the mappings lock first.
Fixes: bdefca2d8dc0 ("drm/panfrost: Add the panfrost_gem_mapping concept")
Cc:
Cc: Christian Hewitt
Reported-by: Christian Hewitt
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/panfrost/panfrost_gem.c | 4 +---
drivers/gpu/drm/panfrost/panfrost_gem.h | 2 +-
drivers/gpu/drm/panfrost/panfrost_gem_shrinker.c | 14 +++---
3 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_gem.c
b/drivers/gpu/drm/panfrost/panfrost_gem.c
index cdf1a8754eba..0c0243eaee81 100644
--- a/drivers/gpu/drm/panfrost/panfrost_gem.c
+++ b/drivers/gpu/drm/panfrost/panfrost_gem.c
@@ -105,14 +105,12 @@ void panfrost_gem_mapping_put(struct panfrost_gem_mapping
*mapping)
kref_put(&mapping->refcount, panfrost_gem_mapping_release);
}
-void panfrost_gem_teardown_mappings(struct panfrost_gem_object *bo)
+void panfrost_gem_teardown_mappings_locked(struct panfrost_gem_object *bo)
{
struct panfrost_gem_mapping *mapping;
- mutex_lock(&bo->mappings.lock);
list_for_each_entry(mapping, &bo->mappings.list, node)
panfrost_gem_teardown_mapping(mapping);
- mutex_unlock(&bo->mappings.lock);
}
int panfrost_gem_open(struct drm_gem_object *obj, struct drm_file *file_priv)
diff --git a/drivers/gpu/drm/panfrost/panfrost_gem.h
b/drivers/gpu/drm/panfrost/panfrost_gem.h
index b3517ff9630c..8088d5fd8480 100644
--- a/drivers/gpu/drm/panfrost/panfrost_gem.h
+++ b/drivers/gpu/drm/panfrost/panfrost_gem.h
@@ -82,7 +82,7 @@ struct panfrost_gem_mapping *
panfrost_gem_mapping_get(struct panfrost_gem_object *bo,
struct panfrost_file_priv *priv);
void panfrost_gem_mapping_put(struct panfrost_gem_mapping *mapping);
-void panfrost_gem_teardown_mappings(struct panfrost_gem_object *bo);
+void panfrost_gem_teardown_mappings_locked(struct panfrost_gem_object *bo);
void panfrost_gem_shrinker_init(struct drm_device *dev);
void panfrost_gem_shrinker_cleanup(struct drm_device *dev);
diff --git a/drivers/gpu/drm/panfrost/panfrost_gem_shrinker.c
b/drivers/gpu/drm/panfrost/panfrost_gem_shrinker.c
index 288e46c40673..1b9f68d8e9aa 100644
--- a/drivers/gpu/drm/panfrost/panfrost_gem_shrinker.c
+++ b/drivers/gpu/drm/panfrost/panfrost_gem_shrinker.c
@@ -40,18 +40,26 @@ static bool panfrost_gem_purge(struct drm_gem_object *obj)
{
struct drm_gem_shmem_object *shmem = to_drm_gem_shmem_obj(obj);
struct panfrost_gem_object *bo = to_panfrost_bo(obj);
+ bool ret = false;
if (atomic_read(&bo->gpu_usecount))
return false;
- if (!mutex_trylock(&shmem->pages_lock))
+ if (!mutex_trylock(&bo->mappings.lock))
return false;
- panfrost_gem_teardown_mappings(bo);
+ if (!mutex_trylock(&shmem->pages_lock))
+ goto unlock_mappings;
+
+ panfrost_gem_teardown_mappings_locked(bo);
drm_gem_shmem_purge_locked(obj);
+ ret = true;
mutex_unlock(&shmem->pages_lock);
- return true;
+
+unlock_mappings:
+ mutex_unlock(&bo->mappings.lock);
+ return ret;
}
static unsigned long
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/4] drm/bridge: ti-sn65dsi86: Read EDID blob over DDC
Hi Stephen,
Thank you for the patch.
On Thu, Oct 29, 2020 at 06:17:37PM -0700, Stephen Boyd wrote:
> Use the DDC connection to read the EDID from the eDP panel instead of
> relying on the panel to tell us the modes.
>
> Reviewed-by: Douglas Anderson
> Cc: Laurent Pinchart
> Cc: Jonas Karlman
> Cc: Jernej Skrabec
> Cc: Sean Paul
> Signed-off-by: Stephen Boyd
> ---
> drivers/gpu/drm/bridge/ti-sn65dsi86.c | 20
> 1 file changed, 20 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> index c77f46a21aae..f86934fd6cc8 100644
> --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> @@ -119,6 +119,7 @@
> * @debugfs: Used for managing our debugfs.
> * @host_node:Remote DSI node.
> * @dsi: Our MIPI DSI source.
> + * @edid: Detected EDID of eDP panel.
> * @refclk: Our reference clock.
> * @panel:Our panel.
> * @enable_gpio: The GPIO we toggle to enable the bridge.
> @@ -144,6 +145,7 @@ struct ti_sn_bridge {
> struct drm_bridge bridge;
> struct drm_connectorconnector;
> struct dentry *debugfs;
> + struct edid *edid;
> struct device_node *host_node;
> struct mipi_dsi_device *dsi;
> struct clk *refclk;
> @@ -265,6 +267,23 @@ connector_to_ti_sn_bridge(struct drm_connector
> *connector)
> static int ti_sn_bridge_connector_get_modes(struct drm_connector *connector)
> {
> struct ti_sn_bridge *pdata = connector_to_ti_sn_bridge(connector);
> + struct edid *edid = pdata->edid;
> + int num, ret;
> +
> + if (!edid) {
> + pm_runtime_get_sync(pdata->dev);
> + edid = pdata->edid = drm_get_edid(connector, &pdata->aux.ddc);
> + pm_runtime_put(pdata->dev);
> + }
Do we need to cache the EDID ? It seems like something that should be
done by the DRM core (well, caching modes in that case), not by
individual bridge drivers.
Apart from that,
Reviewed-by: Laurent Pinchart
> +
> + if (edid && drm_edid_is_valid(edid)) {
> + ret = drm_connector_update_edid_property(connector, edid);
> + if (!ret) {
> + num = drm_add_edid_modes(connector, edid);
> + if (num)
> + return num;
> + }
> + }
>
> return drm_panel_get_modes(pdata->panel, connector);
> }
> @@ -1245,6 +1264,7 @@ static int ti_sn_bridge_remove(struct i2c_client
> *client)
> if (!pdata)
> return -EINVAL;
>
> + kfree(pdata->edid);
> ti_sn_debugfs_remove(pdata);
>
> of_node_put(pdata->host_node);
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
