[PATCH] drm: bridge/dw_hdmi: add audio sample channel status setting
From: Yakir Yang
When transmitting IEC60985 linear PCM audio, we configure the
Audio Sample Channel Status information of all the channel
status bits in the IEC60958 frame.
Refer to 60958-3 page 10 for frequency, original frequency, and
wordlength setting.
This fix the issue that audio does not come out on some monitors
(e.g. LG 22CV241)
Signed-off-by: Yakir Yang
Signed-off-by: Cheng-Yi Chiang
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 59 +++
drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 20
2 files changed, 79 insertions(+)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index bd65d0479683..34d46e25d610 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -582,6 +582,63 @@ static unsigned int hdmi_compute_n(unsigned int freq,
unsigned long pixel_clk)
return n;
}
+static void hdmi_set_schnl(struct dw_hdmi *hdmi)
+{
+ u8 aud_schnl_samplerate;
+ u8 aud_schnl_8;
+
+ /* These registers are on RK3288 using version 2.0a. */
+ if (hdmi->version != 0x200a)
+ return;
+
+ switch (hdmi->sample_rate) {
+ case 32000:
+ aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_32K;
+ break;
+ case 44100:
+ aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_44K1;
+ break;
+ case 48000:
+ aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_48K;
+ break;
+ case 88200:
+ aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_88K2;
+ break;
+ case 96000:
+ aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_96K;
+ break;
+ case 176400:
+ aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_176K4;
+ break;
+ case 192000:
+ aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_192K;
+ break;
+ case 768000:
+ aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_768K;
+ break;
+ default:
+ dev_warn(hdmi->dev, "Unsupported audio sample rate (%u)\n",
+hdmi->sample_rate);
+ return;
+ }
+
+ /* set channel status register */
+ hdmi_modb(hdmi, aud_schnl_samplerate, HDMI_FC_AUDSCHNLS7_SMPRATE_MASK,
+ HDMI_FC_AUDSCHNLS7);
+
+ /*
+* Set original frequency to be the same as frequency.
+* Use one-complement value as stated in IEC60958-3 page 13.
+*/
+ aud_schnl_8 = (~aud_schnl_samplerate) <<
+ HDMI_FC_AUDSCHNLS8_ORIGSAMPFREQ_OFFSET;
+
+ /* This means word length is 16 bit. Refer to IEC60958-3 page 12. */
+ aud_schnl_8 |= 2 << HDMI_FC_AUDSCHNLS8_WORDLEGNTH_OFFSET;
+
+ hdmi_writeb(hdmi, aud_schnl_8, HDMI_FC_AUDSCHNLS8);
+}
+
static void hdmi_set_clk_regenerator(struct dw_hdmi *hdmi,
unsigned long pixel_clk, unsigned int sample_rate)
{
@@ -620,6 +677,8 @@ static void hdmi_set_clk_regenerator(struct dw_hdmi *hdmi,
hdmi->audio_cts = cts;
hdmi_set_cts_n(hdmi, cts, hdmi->audio_enable ? n : 0);
spin_unlock_irq(>audio_lock);
+
+ hdmi_set_schnl(hdmi);
}
static void hdmi_init_clk_regenerator(struct dw_hdmi *hdmi)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h
index 6988f12d89d9..619ebc1c8354 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h
@@ -158,6 +158,17 @@
#define HDMI_FC_SPDDEVICEINF0x1062
#define HDMI_FC_AUDSCONF0x1063
#define HDMI_FC_AUDSSTAT0x1064
+#define HDMI_FC_AUDSV 0x1065
+#define HDMI_FC_AUDSU 0x1066
+#define HDMI_FC_AUDSCHNLS0 0x1067
+#define HDMI_FC_AUDSCHNLS1 0x1068
+#define HDMI_FC_AUDSCHNLS2 0x1069
+#define HDMI_FC_AUDSCHNLS3 0x106a
+#define HDMI_FC_AUDSCHNLS4 0x106b
+#define HDMI_FC_AUDSCHNLS5 0x106c
+#define HDMI_FC_AUDSCHNLS6 0x106d
+#define HDMI_FC_AUDSCHNLS7 0x106e
+#define HDMI_FC_AUDSCHNLS8 0x106f
#define HDMI_FC_DATACH0FILL 0x1070
#define HDMI_FC_DATACH1FILL 0x1071
#define HDMI_FC_DATACH2FILL 0x1072
@@ -706,6 +717,15 @@ enum {
/* HDMI_FC_AUDSCHNLS7 field values */
HDMI_FC_AUDSCHNLS7_ACCURACY_OFFSET = 4,
HDMI_FC_AUDSCHNLS7_ACCURACY_MASK = 0x30,
+ HDMI_FC_AUDSCHNLS7_SMPRATE_MASK = 0x0f,
+ HDMI_FC_AUDSCHNLS7_SMPRATE_192K = 0xe,
+ HDMI_FC_AUDSCHNLS7_SMPRATE_176K4 = 0xc,
+ HDMI_FC_AUDSCHNLS7_SMPRATE_96K = 0xa,
+ HDMI_FC_AUDSCHNLS7_SMPRATE_768K = 0x9,
+
[PATCH v3 2/7] drm/i915/dp: Add support of BT.2020 Colorimetry to DP MSA
When BT.2020 Colorimetry output is used for DP, we should program BT.2020
Colorimetry to MSA and VSC SDP. It adds output_colorspace to
intel_crtc_state struct as a place holder of pipe's output colorspace.
In order to distinguish needed colorimetry for VSC SDP, it adds
intel_dp_needs_vsc_sdp function.
If the output colorspace requires vsc sdp or output format is YCbCr 4:2:0,
it uses MSA with VSC SDP.
As per DP 1.4a spec section 2.2.4.3 [MSA Field for Indication of
Color Encoding Format and Content Color Gamut] while sending
BT.2020 Colorimetry signals we should program MSA MISC1 fields which
indicate VSC SDP for the Pixel Encoding/Colorimetry Format.
v2: Remove useless parentheses
v3: Addressed review comments from Ville
- In order to checking output format and output colorspace on
intel_dp_needs_vsc_sdp(), it passes entire intel_crtc_state stucture.
- Remove a pointless variable.
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_ddi.c | 7 +++--
.../drm/i915/display/intel_display_types.h| 3 ++
drivers/gpu/drm/i915/display/intel_dp.c | 29 ++-
drivers/gpu/drm/i915/display/intel_dp.h | 1 +
4 files changed, 36 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 49c35af583f9..87dc5a19cb7b 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -1737,11 +1737,12 @@ void intel_ddi_set_pipe_settings(const struct
intel_crtc_state *crtc_state)
/*
* As per DP 1.4a spec section 2.2.4.3 [MSA Field for Indication
* of Color Encoding Format and Content Color Gamut] while sending
-* YCBCR 420 signals we should program MSA MISC1 fields which
-* indicate VSC SDP for the Pixel Encoding/Colorimetry Format.
+* YCBCR 420, HDR BT.2020 signals we should program MSA MISC1 fields
+* which indicate VSC SDP for the Pixel Encoding/Colorimetry Format.
*/
- if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420)
+ if (intel_dp_needs_vsc_sdp(crtc_state))
temp |= TRANS_MSA_USE_VSC_SDP;
+
I915_WRITE(TRANS_MSA_MISC(cpu_transcoder), temp);
}
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 61277a87dbe7..c62bad369c8e 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -971,6 +971,9 @@ struct intel_crtc_state {
/* Output format RGB/YCBCR etc */
enum intel_output_format output_format;
+ /* Output colorspace sRGB/BT.2020 etc */
+ u32 output_colorspace;
+
/* Output down scaling is done in LSPCON device */
bool lspcon_downsampling;
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 776be3e16ac6..6b7587c71e49 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -2187,6 +2187,8 @@ intel_dp_compute_config(struct intel_encoder *encoder,
pipe_config->has_pch_encoder = true;
pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
+ pipe_config->output_colorspace = intel_conn_state->base.colorspace;
+
if (lspcon->active)
lspcon_ycbcr420_config(_connector->base, pipe_config);
else
@@ -4445,6 +4447,31 @@ u8 intel_dp_dsc_get_slice_count(struct intel_dp
*intel_dp,
return 0;
}
+bool
+intel_dp_needs_vsc_sdp(const struct intel_crtc_state *crtc_state)
+{
+ /*
+* As per DP 1.4a spec section 2.2.4.3 [MSA Field for Indication
+* of Color Encoding Format and Content Color Gamut], in order to
+* sending YCBCR 420 or HDR BT.2020 signals we should use DP VSC SDP.
+*/
+ if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420)
+ return true;
+
+ switch (crtc_state->output_colorspace) {
+ case DRM_MODE_COLORIMETRY_SYCC_601:
+ case DRM_MODE_COLORIMETRY_OPYCC_601:
+ case DRM_MODE_COLORIMETRY_BT2020_YCC:
+ case DRM_MODE_COLORIMETRY_BT2020_RGB:
+ case DRM_MODE_COLORIMETRY_BT2020_CYCC:
+ return true;
+ default:
+ break;
+ }
+
+ return false;
+}
+
static void
intel_dp_setup_vsc_sdp(struct intel_dp *intel_dp,
const struct intel_crtc_state *crtc_state,
@@ -4573,7 +4600,7 @@ void intel_dp_vsc_enable(struct intel_dp *intel_dp,
const struct intel_crtc_state *crtc_state,
const struct drm_connector_state *conn_state)
{
- if (crtc_state->output_format != INTEL_OUTPUT_FORMAT_YCBCR420)
+ if (!intel_dp_needs_vsc_sdp(crtc_state))
return;
intel_dp_setup_vsc_sdp(intel_dp, crtc_state, conn_state);
diff --git
[PATCH v3 6/7] drm/i915/dp: Program an Infoframe SDP Header and DB for HDR Static Metadata
Function intel_dp_setup_hdr_metadata_infoframe_sdp handles Infoframe SDP
header and data block setup for HDR Static Metadata. It enables writing of
HDR metadata infoframe SDP to panel. Support for HDR video was introduced
in DisplayPort 1.4. It implements the CTA-861-G standard for transport of
static HDR metadata. The HDR Metadata will be provided by userspace
compositors, based on blending policies and passed to the driver through
a blob property.
Because each of GEN11 and prior GEN11 have different register size for
HDR Metadata Infoframe SDP packet, it adds and uses different register
size.
Setup Infoframe SDP header and data block in function
intel_dp_setup_hdr_metadata_infoframe_sdp for HDR Static Metadata as per
dp 1.4 spec and CTA-861-F spec.
As per DP 1.4 spec, 2.2.2.5 SDP Formats. It enables Dynamic Range and
Mastering Infoframe for HDR content, which is defined in CTA-861-F spec.
According to DP 1.4 spec and CEA-861-F spec Table 5, in order to transmit
static HDR metadata, we have to use Non-audio INFOFRAME SDP v1.3.
++---+
| [ Packet Type Value ] | [ Packet Type ] |
++---+
| 80h + Non-audio INFOFRAME Type | CEA-861-F Non-audio INFOFRAME |
++---+
| [Transmission Timing] |
++
| As per CEA-861-F for INFOFRAME, including CEA-861.3 within |
| which Dynamic Range and Mastering INFOFRAME are defined|
++
v2: Add a missed blank line after function declaration.
v3: Remove not handled return values from
intel_dp_setup_hdr_metadata_infoframe_sdp(). [Uma]
Signed-off-by: Gwan-gyeong Mun
---
drivers/gpu/drm/i915/display/intel_ddi.c | 1 +
drivers/gpu/drm/i915/display/intel_dp.c | 89
drivers/gpu/drm/i915/display/intel_dp.h | 3 +
3 files changed, 93 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 87dc5a19cb7b..111a5c95be85 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3612,6 +3612,7 @@ static void intel_enable_ddi_dp(struct intel_encoder
*encoder,
intel_edp_backlight_on(crtc_state, conn_state);
intel_psr_enable(intel_dp, crtc_state);
intel_dp_vsc_enable(intel_dp, crtc_state, conn_state);
+ intel_dp_hdr_metadata_enable(intel_dp, crtc_state, conn_state);
intel_edp_drrs_enable(intel_dp, crtc_state);
if (crtc_state->has_audio)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 9fa107d720ee..7fcc9f28d2e7 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4596,6 +4596,83 @@ intel_dp_setup_vsc_sdp(struct intel_dp *intel_dp,
crtc_state, DP_SDP_VSC, _sdp, sizeof(vsc_sdp));
}
+static void
+intel_dp_setup_hdr_metadata_infoframe_sdp(struct intel_dp *intel_dp,
+ const struct intel_crtc_state
*crtc_state,
+ const struct drm_connector_state
*conn_state)
+{
+ struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
+ struct drm_i915_private *dev_priv =
to_i915(intel_dig_port->base.base.dev);
+ struct dp_sdp infoframe_sdp = {};
+ struct hdmi_drm_infoframe drm_infoframe = {};
+ const int infoframe_size = HDMI_INFOFRAME_HEADER_SIZE +
HDMI_DRM_INFOFRAME_SIZE;
+ unsigned char buf[HDMI_INFOFRAME_HEADER_SIZE + HDMI_DRM_INFOFRAME_SIZE];
+ ssize_t len;
+ int ret;
+
+ ret = drm_hdmi_infoframe_set_hdr_metadata(_infoframe, conn_state);
+ if (ret) {
+ DRM_DEBUG_KMS("couldn't set HDR metadata in infoframe\n");
+ return;
+ }
+
+ len = hdmi_drm_infoframe_pack_only(_infoframe, buf, sizeof(buf));
+ if (len < 0) {
+ DRM_DEBUG_KMS("buffer size is smaller than hdr metadata
infoframe\n");
+ return;
+ }
+
+ if (len != infoframe_size) {
+ DRM_DEBUG_KMS("wrong static hdr metadata size\n");
+ return;
+ }
+
+ /*
+* Set up the infoframe sdp packet for HDR static metadata.
+* Prepare VSC Header for SU as per DP 1.4a spec,
+* Table 2-100 and Table 2-101
+*/
+
+ /* Packet ID, 00h for non-Audio INFOFRAME */
+ infoframe_sdp.sdp_header.HB0 = 0;
+ /*
+* Packet Type 80h + Non-audio INFOFRAME Type value
+* HDMI_INFOFRAME_TYPE_DRM: 0x87,
+*/
+ infoframe_sdp.sdp_header.HB1 = drm_infoframe.type;
+ /*
+* Least Significant Eight Bits of (Data Byte Count – 1)
+*
[PATCH v3 5/7] drm/i915: Add new GMP register size for GEN11
According to Bspec, GEN11 and prior GEN11 have different register size for
HDR Metadata Infoframe SDP packet. It adds new VIDEO_DIP_GMP_DATA_SIZE for
GEN11. And it makes handle different register size for
HDMI_PACKET_TYPE_GAMUT_METADATA on hsw_dip_data_size() for each GEN
platforms. It addresses Uma's review comments.
Signed-off-by: Gwan-gyeong Mun
---
drivers/gpu/drm/i915/display/intel_hdmi.c | 10 --
drivers/gpu/drm/i915/i915_reg.h | 1 +
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index c500fc9154c8..287999b31217 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -189,13 +189,19 @@ hsw_dip_data_reg(struct drm_i915_private *dev_priv,
}
}
-static int hsw_dip_data_size(unsigned int type)
+static int hsw_dip_data_size(struct drm_i915_private *dev_priv,
+unsigned int type)
{
switch (type) {
case DP_SDP_VSC:
return VIDEO_DIP_VSC_DATA_SIZE;
case DP_SDP_PPS:
return VIDEO_DIP_PPS_DATA_SIZE;
+ case HDMI_PACKET_TYPE_GAMUT_METADATA:
+ if (INTEL_GEN(dev_priv) >= 11)
+ return VIDEO_DIP_GMP_DATA_SIZE;
+ else
+ return VIDEO_DIP_DATA_SIZE;
default:
return VIDEO_DIP_DATA_SIZE;
}
@@ -514,7 +520,7 @@ static void hsw_write_infoframe(struct intel_encoder
*encoder,
int i;
u32 val = I915_READ(ctl_reg);
- data_size = hsw_dip_data_size(type);
+ data_size = hsw_dip_data_size(dev_priv, type);
val &= ~hsw_infoframe_enable(type);
I915_WRITE(ctl_reg, val);
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 6c43b8c583bb..8b31ad7426d6 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4667,6 +4667,7 @@ enum {
* (Haswell and newer) to see which VIDEO_DIP_DATA byte corresponds to each
byte
* of the infoframe structure specified by CEA-861. */
#define VIDEO_DIP_DATA_SIZE 32
+#define VIDEO_DIP_GMP_DATA_SIZE 36
#define VIDEO_DIP_VSC_DATA_SIZE 36
#define VIDEO_DIP_PPS_DATA_SIZE 132
#define VIDEO_DIP_CTL _MMIO(0x61170)
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 7/7] drm/i915/dp: Attach HDR metadata property to DP connector
It attaches HDR metadata property to DP connector on GLK+.
It enables HDR metadata infoframe sdp on GLK+ to be used to send
HDR metadata to DP sink.
v2: Minor style fix
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_dp.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 7fcc9f28d2e7..2466d7aff670 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -6536,6 +6536,11 @@ intel_dp_add_properties(struct intel_dp *intel_dp,
struct drm_connector *connect
intel_attach_colorspace_property(connector);
+ if (IS_GEMINILAKE(dev_priv) || INTEL_GEN(dev_priv) >= 11)
+ drm_object_attach_property(>base,
+
connector->dev->mode_config.hdr_output_metadata_property,
+ 0);
+
if (intel_dp_is_edp(intel_dp)) {
u32 allowed_scalers;
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 4/7] drm/i915/dp: Attach colorspace property
It attaches the colorspace connector property to a DisplayPort connector.
Based on colorspace change, modeset will be triggered to switch to a new
colorspace.
Based on colorspace property value create a VSC SDP packet with appropriate
colorspace. This would help to enable wider color gamut like BT2020 on a
sink device.
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_dp.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 6b7587c71e49..9fa107d720ee 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -6445,6 +6445,8 @@ intel_dp_add_properties(struct intel_dp *intel_dp, struct
drm_connector *connect
else if (INTEL_GEN(dev_priv) >= 5)
drm_connector_attach_max_bpc_property(connector, 6, 12);
+ intel_attach_colorspace_property(connector);
+
if (intel_dp_is_edp(intel_dp)) {
u32 allowed_scalers;
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 3/7] drm: Add DisplayPort colorspace property
In order to use colorspace property to Display Port connectors, it extends
DRM_MODE_CONNECTOR_DisplayPort connector_type on
drm_mode_create_colorspace_property function.
v3: Addressed review comments from Ville
- Add new colorimetry options for DP 1.4a spec.
- Separate set of colorimetry enum values for DP.
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/drm_connector.c | 43 +
include/drm/drm_connector.h | 8 ++
2 files changed, 51 insertions(+)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 4c766624b20d..013cf96e3012 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -882,6 +882,41 @@ static const struct drm_prop_enum_list hdmi_colorspaces[]
= {
{ DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER, "DCI-P3_RGB_Theater" },
};
+/*
+ * As per DP 1.4a spec, 2.2.5.7.5 VSC SDP Payload for Pixel
Encoding/Colorimetry
+ * Format Table 2-120
+ */
+static const struct drm_prop_enum_list dp_colorspaces[] = {
+ /* For Default case, driver will set the colorspace */
+ { DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
+ /* Colorimetry based on IEC 61966-2-1 */
+ { DRM_MODE_COLORIMETRY_SRGB, "sRGB" },
+ { DRM_MODE_COLORIMETRY_WIDE_GAMUT_FIXED_POINT_RGB,
"RGB_wide_gamut_fixed_point" },
+ /* Colorimetry based on IEC 61966-2-2 */
+ { DRM_MODE_COLORIMETRY_SCRGB, "scRGB" },
+ { DRM_MODE_COLORIMETRY_ADOBE_RGB, "Adobe_RGB" },
+ /* Colorimetry based on SMPTE RP 431-2 */
+ { DRM_MODE_COLORIMETRY_DCP_P3_RGB, "DCI-P3_RGB" },
+ /* Colorimetry based on ITU-R BT.2020 */
+ { DRM_MODE_COLORIMETRY_BT2020_RGB, "BT2020_RGB" },
+ { DRM_MODE_COLORIMETRY_BT601_YCC, "BT601_YCC" },
+ { DRM_MODE_COLORIMETRY_BT709_YCC, "BT709_YCC" },
+ /* Standard Definition Colorimetry based on IEC 61966-2-4 */
+ { DRM_MODE_COLORIMETRY_XVYCC_601, "XVYCC_601" },
+ /* High Definition Colorimetry based on IEC 61966-2-4 */
+ { DRM_MODE_COLORIMETRY_XVYCC_709, "XVYCC_709" },
+ /* Colorimetry based on IEC 61966-2-1/Amendment 1 */
+ { DRM_MODE_COLORIMETRY_SYCC_601, "SYCC_601" },
+ /* Colorimetry based on IEC 61966-2-5 [33] */
+ { DRM_MODE_COLORIMETRY_OPYCC_601, "opYCC_601" },
+ /* Colorimetry based on ITU-R BT.2020 */
+ { DRM_MODE_COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" },
+ /* Colorimetry based on ITU-R BT.2020 */
+ { DRM_MODE_COLORIMETRY_BT2020_YCC, "BT2020_YCC" },
+ /* Colorumetry for Y Only */
+ { DRM_MODE_COLORIMETRY_DICOM_PART_14_GRAYSCALE,
"DICOM_Part_14_Grayscale_Display_Function" },
+};
+
/**
* DOC: standard connector properties
*
@@ -1710,6 +1745,14 @@ int drm_mode_create_colorspace_property(struct
drm_connector *connector)
ARRAY_SIZE(hdmi_colorspaces));
if (!prop)
return -ENOMEM;
+ } else if (connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort
||
+ connector->connector_type == DRM_MODE_CONNECTOR_eDP) {
+ prop = drm_property_create_enum(dev, DRM_MODE_PROP_ENUM,
+ "Colorspace",
+ dp_colorspaces,
+ ARRAY_SIZE(dp_colorspaces));
+ if (!prop)
+ return -ENOMEM;
} else {
DRM_DEBUG_KMS("Colorspace property not supported\n");
return 0;
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 681cb590f952..8848e5d6b0c4 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -281,6 +281,14 @@ enum drm_panel_orientation {
/* Additional Colorimetry extension added as part of CTA 861.G */
#define DRM_MODE_COLORIMETRY_DCI_P3_RGB_D6511
#define DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER12
+/* Additional Colorimetry Options added for DP 1.4a VSC Colorimetry Format */
+#define DRM_MODE_COLORIMETRY_SRGB 13
+#define DRM_MODE_COLORIMETRY_WIDE_GAMUT_FIXED_POINT_RGB14
+#define DRM_MODE_COLORIMETRY_SCRGB 15
+#define DRM_MODE_COLORIMETRY_ADOBE_RGB 16
+#define DRM_MODE_COLORIMETRY_DCP_P3_RGB17
+#define DRM_MODE_COLORIMETRY_BT601_YCC 18
+#define DRM_MODE_COLORIMETRY_DICOM_PART_14_GRAYSCALE 19
/**
* enum drm_bus_flags - bus_flags info for _display_info
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/7] drm/i915/dp: Extend program of VSC Header and DB for Colorimetry Format
It refactors and renames a function which handled vsc sdp header and data
block setup for supporting colorimetry format.
Function intel_dp_setup_vsc_sdp handles vsc sdp header and data block
setup for pixel encoding / colorimetry format.
In order to use colorspace information of a connector, it adds an argument
of drm_connector_state type.
Setup VSC header and data block in function intel_dp_setup_vsc_sdp for
pixel encoding / colorimetry format as per dp 1.4a spec, section 2.2.5.7.1,
table 2-119: VSC SDP Header Bytes, section 2.2.5.7.5,
table 2-120: VSC SDP Payload for DB16 through DB18.
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_ddi.c | 2 +-
drivers/gpu/drm/i915/display/intel_display.h | 2 -
drivers/gpu/drm/i915/display/intel_dp.c | 68
drivers/gpu/drm/i915/display/intel_dp.h | 3 +
4 files changed, 60 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 1fe0bf01e580..49c35af583f9 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3610,7 +3610,7 @@ static void intel_enable_ddi_dp(struct intel_encoder
*encoder,
intel_edp_backlight_on(crtc_state, conn_state);
intel_psr_enable(intel_dp, crtc_state);
- intel_dp_ycbcr_420_enable(intel_dp, crtc_state);
+ intel_dp_vsc_enable(intel_dp, crtc_state, conn_state);
intel_edp_drrs_enable(intel_dp, crtc_state);
if (crtc_state->has_audio)
diff --git a/drivers/gpu/drm/i915/display/intel_display.h
b/drivers/gpu/drm/i915/display/intel_display.h
index 33fd523c4622..8de63be75620 100644
--- a/drivers/gpu/drm/i915/display/intel_display.h
+++ b/drivers/gpu/drm/i915/display/intel_display.h
@@ -526,8 +526,6 @@ void intel_dp_get_m_n(struct intel_crtc *crtc,
struct intel_crtc_state *pipe_config);
void intel_dp_set_m_n(const struct intel_crtc_state *crtc_state,
enum link_m_n_set m_n);
-void intel_dp_ycbcr_420_enable(struct intel_dp *intel_dp,
- const struct intel_crtc_state *crtc_state);
int intel_dotclock_calculate(int link_freq, const struct intel_link_m_n *m_n);
bool bxt_find_best_dpll(struct intel_crtc_state *crtc_state,
struct dpll *best_clock);
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 5673ed75e428..776be3e16ac6 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4446,8 +4446,9 @@ u8 intel_dp_dsc_get_slice_count(struct intel_dp *intel_dp,
}
static void
-intel_pixel_encoding_setup_vsc(struct intel_dp *intel_dp,
- const struct intel_crtc_state *crtc_state)
+intel_dp_setup_vsc_sdp(struct intel_dp *intel_dp,
+ const struct intel_crtc_state *crtc_state,
+ const struct drm_connector_state *conn_state)
{
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
struct dp_sdp vsc_sdp = {};
@@ -4468,13 +4469,55 @@ intel_pixel_encoding_setup_vsc(struct intel_dp
*intel_dp,
*/
vsc_sdp.sdp_header.HB3 = 0x13;
- /*
-* YCbCr 420 = 3h DB16[7:4] ITU-R BT.601 = 0h, ITU-R BT.709 = 1h
-* DB16[3:0] DP 1.4a spec, Table 2-120
-*/
- vsc_sdp.db[16] = 0x3 << 4; /* 0x3 << 4 , YCbCr 420*/
- /* RGB->YCBCR color conversion uses the BT.709 color space. */
- vsc_sdp.db[16] |= 0x1; /* 0x1, ITU-R BT.709 */
+ /* DP 1.4a spec, Table 2-120 */
+ switch (crtc_state->output_format) {
+ case INTEL_OUTPUT_FORMAT_YCBCR444:
+ vsc_sdp.db[16] = 0x1 << 4; /* YCbCr 444 : DB16[7:4] = 1h */
+ break;
+ case INTEL_OUTPUT_FORMAT_YCBCR420:
+ vsc_sdp.db[16] = 0x3 << 4; /* YCbCr 420 : DB16[7:4] = 3h */
+ break;
+ case INTEL_OUTPUT_FORMAT_RGB:
+ default:
+ /* RGB: DB16[7:4] = 0h */
+ break;
+ }
+
+ switch (conn_state->colorspace) {
+ case DRM_MODE_COLORIMETRY_BT709_YCC:
+ vsc_sdp.db[16] |= 0x1;
+ break;
+ case DRM_MODE_COLORIMETRY_XVYCC_601:
+ vsc_sdp.db[16] |= 0x2;
+ break;
+ case DRM_MODE_COLORIMETRY_XVYCC_709:
+ vsc_sdp.db[16] |= 0x3;
+ break;
+ case DRM_MODE_COLORIMETRY_SYCC_601:
+ vsc_sdp.db[16] |= 0x4;
+ break;
+ case DRM_MODE_COLORIMETRY_OPYCC_601:
+ vsc_sdp.db[16] |= 0x5;
+ break;
+ case DRM_MODE_COLORIMETRY_BT2020_CYCC:
+ case DRM_MODE_COLORIMETRY_BT2020_RGB:
+ vsc_sdp.db[16] |= 0x6;
+ break;
+ case DRM_MODE_COLORIMETRY_BT2020_YCC:
+ vsc_sdp.db[16] |= 0x7;
+ break;
+ case
[PATCH v3 0/6] drm/i915/dp: Support for DP HDR outputs
Support for HDR10 video was introduced in DisplayPort 1.4. On GLK+ platform, in order to use DisplayPort HDR10, we need to support BT.2020 colorimetry and HDR Static metadata. It implements the CTA-861-G standard for transport of static HDR metadata. It enables writing of HDR metadata infoframe SDP to the panel. The HDR Metadata will be provided by userspace compositors, based on blending policies and passed to the driver through a blob property. And It refactors, renames and extends a function which handled vsc sdp header and data block setup for supporting colorimetry format. And It attaches the colorspace connector property and HDR metadata property to a DisplayPort connector. These patches tested on below test environment. Test Environment: - Tested System: GLK and Gen11 platform. - Monitor: Dell UP2718Q 4K HDR Monitor. - In order to test DP HDR10, test environment uses patched Kodi-gbm, patched Media driver and HDR10 video. You can find these on below. [patched Kodi-gbm] - repo: https://github.com/Kwiboo/xbmc/tree/drmprime-hdr [download 4K HDR video file] - link: https://4kmedia.org/lg-new-york-hdr-uhd-4k-demo/ [Media Driver for GLK] - repo https://gitlab.freedesktop.org/emersion/intel-vaapi-driver master branch [Media Driver for ICL] - repo: https://github.com/harishkrupo/media-driver/tree/p010_composite v2: - Add a missed blank line after function declaration. - Remove useless parentheses. - Minor style fix. v3: - Remove not handled return values from intel_dp_setup_hdr_metadata_infoframe_sdp(). [Uma] - Add handling of different register size for HDMI_PACKET_TYPE_GAMUT_METADATA on hsw_dip_data_size() for each GEN platforms [Uma] - Add new colorimetry options for DP 1.4a spec. [Ville] - Separate set of colorimetry enum values for DP. [Ville] - In order to checking output format and output colorspace on intel_dp_needs_vsc_sdp(), it passes entire intel_crtc_state stucture.[Ville] - Remove a pointless variable. [Ville] Gwan-gyeong Mun (7): drm/i915/dp: Extend program of VSC Header and DB for Colorimetry Format drm/i915/dp: Add support of BT.2020 Colorimetry to DP MSA drm: Add DisplayPort colorspace property drm/i915/dp: Attach colorspace property drm/i915: Add new GMP register size for GEN11 drm/i915/dp: Program an Infoframe SDP Header and DB for HDR Static Metadata drm/i915/dp: Attach HDR metadata property to DP connector drivers/gpu/drm/drm_connector.c | 43 drivers/gpu/drm/i915/display/intel_ddi.c | 10 +- drivers/gpu/drm/i915/display/intel_display.h | 2 - .../drm/i915/display/intel_display_types.h| 3 + drivers/gpu/drm/i915/display/intel_dp.c | 193 -- drivers/gpu/drm/i915/display/intel_dp.h | 7 + drivers/gpu/drm/i915/display/intel_hdmi.c | 10 +- drivers/gpu/drm/i915/i915_reg.h | 1 + include/drm/drm_connector.h | 8 + 9 files changed, 256 insertions(+), 21 deletions(-) -- 2.23.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 5/6] drm/i915/dp: Program an Infoframe SDP Header and DB for HDR Static Metadata
On Tue, 2019-08-27 at 01:14 +0530, Shankar, Uma wrote:
> > -Original Message-
> > From: Mun, Gwan-gyeong
> > Sent: Friday, August 23, 2019 3:23 PM
> > To: intel-...@lists.freedesktop.org
> > Cc: dri-devel@lists.freedesktop.org; Shankar, Uma <
> > uma.shan...@intel.com>;
> > Sharma, Shashank
> > Subject: [PATCH v2 5/6] drm/i915/dp: Program an Infoframe SDP
> > Header and DB for
> > HDR Static Metadata
> >
> > Function intel_dp_setup_hdr_metadata_infoframe_sdp handles
> > Infoframe SDP
> > header and data block setup for HDR Static Metadata. It enables
> > writing of HDR
> > metadata infoframe SDP to panel. Support for HDR video was
> > introduced in
> > DisplayPort 1.4. It implements the CTA-861-G standard for transport
> > of static HDR
> > metadata. The HDR Metadata will be provided by userspace
> > compositors, based on
> > blending policies and passed to the driver through a blob property.
> >
> > Because each of GEN11 and prior GEN11 have different register size
> > for HDR
> > Metadata Infoframe SDP packet, it adds and uses different register
> > size.
> >
> > Setup Infoframe SDP header and data block in function
> > intel_dp_setup_hdr_metadata_infoframe_sdp for HDR Static Metadata
> > as per dp 1.4
> > spec and CTA-861-F spec.
> > As per DP 1.4 spec, 2.2.2.5 SDP Formats. It enables Dynamic Range
> > and Mastering
> > Infoframe for HDR content, which is defined in CTA-861-F spec.
> > According to DP 1.4 spec and CEA-861-F spec Table 5, in order to
> > transmit static HDR
> > metadata, we have to use Non-audio INFOFRAME SDP v1.3.
> >
> > ++---+
> > > [ Packet Type Value ] | [ Packet Type ] |
> > ++---+
> > > 80h + Non-audio INFOFRAME Type | CEA-861-F Non-audio INFOFRAME |
> > ++---+
> > > [Transmission Timing] |
> > ++
> > > As per CEA-861-F for INFOFRAME, including CEA-861.3 within |
> > > which Dynamic Range and Mastering INFOFRAME are defined|
> > ++
> >
> > v2: Add a missed blank line after function declaration.
> >
> > Signed-off-by: Gwan-gyeong Mun
> > ---
> > drivers/gpu/drm/i915/display/intel_ddi.c | 1 +
> > drivers/gpu/drm/i915/display/intel_dp.c | 91
> >
> > drivers/gpu/drm/i915/display/intel_dp.h | 3 +
> > drivers/gpu/drm/i915/i915_reg.h | 1 +
> > 4 files changed, 96 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > index 5c42b58c1c2f..9f5bea941bcd 100644
> > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > @@ -3478,6 +3478,7 @@ static void intel_enable_ddi_dp(struct
> > intel_encoder
> > *encoder,
> > intel_edp_backlight_on(crtc_state, conn_state);
> > intel_psr_enable(intel_dp, crtc_state);
> > intel_dp_vsc_enable(intel_dp, crtc_state, conn_state);
> > + intel_dp_hdr_metadata_enable(intel_dp, crtc_state, conn_state);
> > intel_edp_drrs_enable(intel_dp, crtc_state);
> >
> > if (crtc_state->has_audio)
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index 7218e159f55d..00da8221eaba 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -4554,6 +4554,85 @@ intel_dp_setup_vsc_sdp(struct intel_dp
> > *intel_dp,
> > crtc_state, DP_SDP_VSC, _sdp,
> > sizeof(vsc_sdp)); }
> >
> > +static int
> > +intel_dp_setup_hdr_metadata_infoframe_sdp(struct intel_dp
> > *intel_dp,
> > + const struct intel_crtc_state
> > *crtc_state,
> > + const struct
> > drm_connector_state
>
> The return value is not handled, you may convert it as void.
>
Okay, I'll remove the return values which is not handled from
intel_dp_setup_hdr_metadata_infoframe_sdp().
> > *conn_state) {
> > + struct intel_digital_port *intel_dig_port =
> > dp_to_dig_port(intel_dp);
> > + struct drm_i915_private *dev_priv = to_i915(intel_dig_port-
> > >base.base.dev);
> > + struct dp_sdp infoframe_sdp = {};
> > + struct hdmi_drm_infoframe drm_infoframe = {};
> > + const int infoframe_size = HDMI_INFOFRAME_HEADER_SIZE +
> > HDMI_DRM_INFOFRAME_SIZE;
> > + unsigned char buf[HDMI_INFOFRAME_HEADER_SIZE +
> > HDMI_DRM_INFOFRAME_SIZE];
> > + ssize_t len;
> > + int ret;
> > +
> > + ret = drm_hdmi_infoframe_set_hdr_metadata(_infoframe,
> > conn_state);
> > + if (ret) {
> > + DRM_DEBUG_KMS("couldn't set HDR metadata in
> > infoframe\n");
> > + return ret;
> > + }
> > +
> > + len = hdmi_drm_infoframe_pack_only(_infoframe, buf,
Re: [Intel-gfx] [PATCH v2 3/6] drm: Add DisplayPort colorspace property
On Mon, 2019-09-02 at 17:44 +0300, Ville Syrjälä wrote:
> On Fri, Aug 23, 2019 at 12:52:29PM +0300, Gwan-gyeong Mun wrote:
> > In order to use colorspace property to Display Port connectors, it
> > extends
> > DRM_MODE_CONNECTOR_DisplayPort connector_type on
> > drm_mode_create_colorspace_property function.
> >
> > Signed-off-by: Gwan-gyeong Mun
> > ---
> > drivers/gpu/drm/drm_connector.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_connector.c
> > b/drivers/gpu/drm/drm_connector.c
> > index 4c766624b20d..655ada9d4c16 100644
> > --- a/drivers/gpu/drm/drm_connector.c
> > +++ b/drivers/gpu/drm/drm_connector.c
> > @@ -1703,7 +1703,9 @@ int
> > drm_mode_create_colorspace_property(struct drm_connector
> > *connector)
> > struct drm_property *prop;
> >
> > if (connector->connector_type == DRM_MODE_CONNECTOR_HDMIA ||
> > - connector->connector_type == DRM_MODE_CONNECTOR_HDMIB) {
> > + connector->connector_type == DRM_MODE_CONNECTOR_HDMIB ||
> > + connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort
> > ||
> > + connector->connector_type == DRM_MODE_CONNECTOR_eDP) {
>
> We don't need a separate set of enum values for DP?
>
I checked DP 1.4a spec, 2.2.5.7.5 VSC SDP Payload for Pixel
Encoding/Colorimetry again,
Followed your comments, the spec requires more new colorimetry options
for DP 1.4a colorimetry format.
I'll add missed colorimetry options and will separate set of
colorimetry enum values for DP.
> > prop = drm_property_create_enum(dev,
> > DRM_MODE_PROP_ENUM,
> > "Colorspace",
> > hdmi_colorspaces,
> > --
> > 2.22.0
> >
> > ___
> > Intel-gfx mailing list
> > intel-...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v2 2/6] drm/i915/dp: Add support of BT.2020 Colorimetry to DP MSA
On Mon, 2019-09-02 at 17:43 +0300, Ville Syrjälä wrote:
> On Fri, Aug 23, 2019 at 12:52:28PM +0300, Gwan-gyeong Mun wrote:
> > When BT.2020 Colorimetry output is used for DP, we should program
> > BT.2020
> > Colorimetry to MSA and VSC SDP. It adds output_colorspace to
> > intel_crtc_state struct as a place holder of pipe's output
> > colorspace.
> > In order to distinguish needed colorimetry for VSC SDP, it adds
> > intel_dp_needs_vsc_colorimetry function.
> > If the output colorspace requires vsc sdp or output format is YCbCr
> > 4:2:0,
> > it uses MSA with VSC SDP.
> >
> > As per DP 1.4a spec section 2.2.4.3 [MSA Field for Indication of
> > Color Encoding Format and Content Color Gamut] while sending
> > BT.2020 Colorimetry signals we should program MSA MISC1 fields
> > which
> > indicate VSC SDP for the Pixel Encoding/Colorimetry Format.
> >
> > v2: Remove useless parentheses
> >
> > Signed-off-by: Gwan-gyeong Mun
> > ---
> > drivers/gpu/drm/i915/display/intel_ddi.c | 8 +++---
> > .../drm/i915/display/intel_display_types.h| 3 +++
> > drivers/gpu/drm/i915/display/intel_dp.c | 25
> > ++-
> > drivers/gpu/drm/i915/display/intel_dp.h | 1 +
> > 4 files changed, 33 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > index 4f7ea0a35976..5c42b58c1c2f 100644
> > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > @@ -1737,11 +1737,13 @@ void intel_ddi_set_pipe_settings(const
> > struct intel_crtc_state *crtc_state)
> > /*
> > * As per DP 1.4a spec section 2.2.4.3 [MSA Field for
> > Indication
> > * of Color Encoding Format and Content Color Gamut] while
> > sending
> > -* YCBCR 420 signals we should program MSA MISC1 fields which
> > -* indicate VSC SDP for the Pixel Encoding/Colorimetry Format.
> > +* YCBCR 420, HDR BT.2020 signals we should program MSA MISC1
> > fields
> > +* which indicate VSC SDP for the Pixel Encoding/Colorimetry
> > Format.
> > */
> > - if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420)
> > + if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420
> > ||
> > + intel_dp_needs_vsc_colorimetry(crtc_state-
> > >output_colorspace))
> > temp |= TRANS_MSA_USE_VSC_SDP;
> > +
> > I915_WRITE(TRANS_MSA_MISC(cpu_transcoder), temp);
> > }
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> > b/drivers/gpu/drm/i915/display/intel_display_types.h
> > index 449abaea619f..9845abcf6f29 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> > +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> > @@ -964,6 +964,9 @@ struct intel_crtc_state {
> > /* Output format RGB/YCBCR etc */
> > enum intel_output_format output_format;
> >
> > + /* Output colorspace sRGB/BT.2020 etc */
> > + u32 output_colorspace;
> > +
> > /* Output down scaling is done in LSPCON device */
> > bool lspcon_downsampling;
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index 55d5ab97061c..295d5ed2be96 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -2164,6 +2164,8 @@ intel_dp_compute_config(struct intel_encoder
> > *encoder,
> > pipe_config->has_pch_encoder = true;
> >
> > pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
> > + pipe_config->output_colorspace = intel_conn_state-
> > >base.colorspace;
> > +
> > if (lspcon->active)
> > lspcon_ycbcr420_config(_connector->base,
> > pipe_config);
> > else
> > @@ -4408,6 +4410,26 @@ u8 intel_dp_dsc_get_slice_count(struct
> > intel_dp *intel_dp,
> > return 0;
> > }
> >
> > +bool
> > +intel_dp_needs_vsc_colorimetry(u32 colorspace)
>
> I would pass the entire crtc state here so you handle handle the
> 4:2:0
> case here as well.
>
Okay, I'll pass the entire intel_crtc_state stucture value to
intel_dp_needs_vsc_colorimetry() for checking output format (YCbCr
4:2:0) and output colorspace here. And I'll change the fuction name to
intel_dp_needs_vsc_sdp().
> > +{
> > + bool ret = false;
>
> Pointless variable.
>
I'll remove pointless variables.
> > +
> > + switch (colorspace) {
> > + case DRM_MODE_COLORIMETRY_SYCC_601:
> > + case DRM_MODE_COLORIMETRY_OPYCC_601:
> > + case DRM_MODE_COLORIMETRY_BT2020_YCC:
> > + case DRM_MODE_COLORIMETRY_BT2020_RGB:
> > + case DRM_MODE_COLORIMETRY_BT2020_CYCC:
> > + ret = true;
> > + break;
> > + default:
> > + break;
> > + }
> > +
> > + return ret;
> > +}
> > +
> > static void
> > intel_dp_setup_vsc_sdp(struct intel_dp *intel_dp,
> >const struct intel_crtc_state *crtc_state,
> > @@ -4536,7 +4558,8 @@ void intel_dp_vsc_enable(struct intel_dp
> > *intel_dp,
> > const
[PATCH] arm64: dts: mt8183: Add gce setting in display node
In order to use GCE function, we need add some informations
into display node (mboxes, mediatek,gce-client-reg, mediatek,gce-events).
Signed-off-by: Bibby Hsieh
Signed-off-by: Yongqiang Niu
---
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index 5616d158a4fa..b7d294c1c5b4 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -485,6 +485,11 @@
compatible = "mediatek,mt8183-display";
reg = <0 0x1400 0 0x1000>;
power-domains = < MT8183_POWER_DOMAIN_DISP>;
+ mboxes = < 0 CMDQ_THR_PRIO_HIGHEST 1>,
+< 1 CMDQ_THR_PRIO_HIGHEST 1>;
+ mediatek,gce-client-reg = < SUBSYS_1400 0
0x1000>;
+ mediatek,gce-events = ,
+ ;
};
ovl0: ovl@14008000 {
@@ -494,6 +499,7 @@
power-domains = < MT8183_POWER_DOMAIN_DISP>;
clocks = < CLK_MM_DISP_OVL0>;
mediatek,larb = <>;
+ mediatek,gce-client-reg = < SUBSYS_1400 0x8000
0x1000>;
};
ovl_2l0: ovl@14009000 {
@@ -503,6 +509,7 @@
power-domains = < MT8183_POWER_DOMAIN_DISP>;
clocks = < CLK_MM_DISP_OVL0_2L>;
mediatek,larb = <>;
+ mediatek,gce-client-reg = < SUBSYS_1400 0x9000
0x1000>;
};
ovl_2l1: ovl@1400a000 {
@@ -512,6 +519,7 @@
power-domains = < MT8183_POWER_DOMAIN_DISP>;
clocks = < CLK_MM_DISP_OVL1_2L>;
mediatek,larb = <>;
+ mediatek,gce-client-reg = < SUBSYS_1400 0xa000
0x1000>;
};
rdma0: rdma@1400b000 {
@@ -522,6 +530,7 @@
clocks = < CLK_MM_DISP_RDMA0>;
mediatek,larb = <>;
mediatek,rdma_fifo_size = <5>;
+ mediatek,gce-client-reg = < SUBSYS_1400 0xb000
0x1000>;
};
rdma1: rdma@1400c000 {
@@ -532,6 +541,7 @@
clocks = < CLK_MM_DISP_RDMA1>;
mediatek,larb = <>;
mediatek,rdma_fifo_size = <2>;
+ mediatek,gce-client-reg = < SUBSYS_1400 0xc000
0x1000>;
};
color0: color@1400e000 {
@@ -541,6 +551,7 @@
interrupts = ;
power-domains = < MT8183_POWER_DOMAIN_DISP>;
clocks = < CLK_MM_DISP_COLOR0>;
+ mediatek,gce-client-reg = < SUBSYS_1400 0xe000
0x1000>;
};
ccorr0: ccorr@1400f000 {
@@ -549,6 +560,7 @@
interrupts = ;
power-domains = < MT8183_POWER_DOMAIN_DISP>;
clocks = < CLK_MM_DISP_CCORR0>;
+ mediatek,gce-client-reg = < SUBSYS_1400 0xf000
0x1000>;
};
aal0: aal@1401 {
@@ -558,6 +570,7 @@
interrupts = ;
power-domains = < MT8183_POWER_DOMAIN_DISP>;
clocks = < CLK_MM_DISP_AAL0>;
+ mediatek,gce-client-reg = < SUBSYS_1401 0
0x1000>;
};
gamma0: gamma@14011000 {
@@ -567,6 +580,7 @@
interrupts = ;
power-domains = < MT8183_POWER_DOMAIN_DISP>;
clocks = < CLK_MM_DISP_GAMMA0>;
+ mediatek,gce-client-reg = < SUBSYS_1401 0x1000
0x1000>;
};
dither0: dither@14012000 {
@@ -575,6 +589,7 @@
interrupts = ;
power-domains = < MT8183_POWER_DOMAIN_DISP>;
clocks = < CLK_MM_DISP_DITHER0>;
+ mediatek,gce-client-reg = < SUBSYS_1401 0x2000
0x1000>;
};
mutex: mutex@14016000 {
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111241] Shadertoy shader causing hang
https://bugs.freedesktop.org/show_bug.cgi?id=111241 Timothy Arceri changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #13 from Timothy Arceri --- (In reply to Dieter Nützel from comment #12) > (In reply to Pierre-Eric Pelloux-Prayer from comment #11) > > (In reply to Dieter Nützel from comment #8) > > > BTW > > > > > > Pierre-Eric can you look into this > > > > > > Shadertoy shader corruption, too? > > > https://www.shadertoy.com/view/Xt3cWS > > > > > > > The "Buffer A" shader doesn't write fragColor when uv.y is < 0.1 or > 0.9. > > > > So the content is undefined and may be black on some platform or random. > > > > radeonsi is correct here, but we might want to replace undef values with 0x0 > > to get a default value instead of random. > > Cool to have you around for bug hunting...;-) > > Any hints where I shoud change 'undef values with 0x0' for testing? > > And sorry that I 'hijacked' this thread - should I open a new ticket? I don't think you need to open a bug for it at all. As its not a bug in Mesa its a shader bug. Closing this bug report as it should be fixed by: commit 47cc660d9c19572e5ef2dce7c8ae1766a2ac9885 glsl: replace 'x + (-x)' with constant 0 This fixes a hang in shadertoy for radeonsi where a buffer was initialized with: value -= value with value being undefined. In this case LLVM replace the operation with an assignment to NaN. Cc: 19.1 19.2 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111241 Reviewed-by: Marek Olšák -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Display-Port HPD handling, link status, and bandwidth checks
On 25/08/2019 23:23, Ilia Mirkin wrote: > You'll probably get a more detailed reply during the week, but for now > have a look at the "link-status" property, which was made for > precisely this situation. I think basically the idea is to ignore link > training as part of the modeset, and just return the link status > depending on the success. (And you should filter out totally > infeasible modes, i.e. outside the monitor's max lanes/bandwidth > capabilities, which I believe are available via DPCD or EDID.) > > See https://www.kernel.org/doc/html/latest/gpu/drm-kms.html for a bit > more info as well. > It looks like only i915 is really implementing the "link-status" property (e.g. setting it to something else than "GOOD"). And it only sets it in delayed work right after a failed link-training. But it looks like setting "link-status" bad and calling drm_kms_helper_hotplug_event() indeed triggers another modeset at least from fbdev console. I guess the correct way would be checking if the link is still up after receiving an HPD short pulse and setting link-status bad and calling drm_kms_helper_hotplug_event() if the link is down. I just wonder if the real user space clients like Weston or X work the same way as fbdev does. Maybe my first question is now answered, but I am still wondering about this: >> 1. When should the link training happen? >>a) In connector detect()? >> - This would enable us to do mode filtering (in mode_valid()) >> based on the established link band-width (then again >> mode_valid() documentation suggests that modes should only >> be filtered based on "configuration-invariant hardware >> constraints"). >>b) In check phase (this would currently mean mode_fixup)? >> - This is the last point where we can reject a mode that can not >> be sent over the DP-link >>c) In commit phase (e.g. bridge enable()) >> - This is bad since we should not fail any more in the commit >> phase Thanks, Jyri > Cheers, > > -ilia > > On Sun, Aug 25, 2019 at 7:12 AM Jyri Sarha wrote: >> >> Hi, >> >> I am working on a new DisplayPort bridge-driver and there is a couple of >> things that I do not know how to handle. >> >> 1. When should the link training happen? >>a) In connector detect()? >> - This would enable us to do mode filtering (in mode_valid()) >> based on the established link band-width (then again >> mode_valid() documentation suggests that modes should only >> be filtered based on "configuration-invariant hardware >> constraints"). >>b) In check phase (this would currently mean mode_fixup)? >> - This is the last point where we can reject a mode that can not >> be sent over the DP-link >>c) In commit phase (e.g. bridge enable()) >> - This is bad since we should not fail any more in the commit >> phase >> >> 2. DP-link sometimes drops after a succesful link training and DP-sink >>is supposed to send short HPD pulse about it. What are the >>recommended ways to handle the situation? >> >>a) Send hotplug event and let the DRM client deal with it? >> - This does not work too well because even if the client tries >> to restore the display by committing the same state again - >> like fbdev does - the bridge does not go trough disable-enable >> cycle, since display mode has not changed. >> - Despite it not working so well, this is what the most drivers >> appear to do. >> >>b) Driver internally re-trains the link but send a hotplug event >> always after it? >> - This is what i915 does, if I read the code right. >> - How to treat a training failure? Sending hotplug event does not >> really help (see above). >> >>c) Silently re-train the link if we were able to restore the link >> and the display mode, and send HPD only if something went wrong? >> >> Best regards, >> Jyri >> >> -- >> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. >> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki >> ___ >> dri-devel mailing list >> dri-devel@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 204725] black screen
https://bugzilla.kernel.org/show_bug.cgi?id=204725 Mike Lothian (m...@fireburn.co.uk) changed: What|Removed |Added CC||m...@fireburn.co.uk --- Comment #47 from Mike Lothian (m...@fireburn.co.uk) --- It's selected automatically if you set DRM_FBDEV_EMULATION - which is "Enable legacy fbdev support for your modesetting driver" and unset above That should get your console working -- 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
[RESEND PATCH v3 6/7] backlight: gpio: remove def_value from struct gpio_backlight
From: Bartosz Golaszewski
This field is unused outside of probe(). There's no need to store it.
We can make it into a local variable.
Signed-off-by: Bartosz Golaszewski
Reviewed-by: Andy Shevchenko
Reviewed-by: Linus Walleij
Reviewed-by: Daniel Thompson
---
drivers/video/backlight/gpio_backlight.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/video/backlight/gpio_backlight.c
b/drivers/video/backlight/gpio_backlight.c
index 70882556f047..cd6a75bca9cc 100644
--- a/drivers/video/backlight/gpio_backlight.c
+++ b/drivers/video/backlight/gpio_backlight.c
@@ -21,7 +21,6 @@
struct gpio_backlight {
struct device *fbdev;
struct gpio_desc *gpiod;
- int def_value;
};
static int gpio_backlight_update_status(struct backlight_device *bl)
@@ -61,7 +60,7 @@ static int gpio_backlight_probe(struct platform_device *pdev)
struct backlight_device *bl;
struct gpio_backlight *gbl;
enum gpiod_flags flags;
- int ret;
+ int ret, def_value;
gbl = devm_kzalloc(>dev, sizeof(*gbl), GFP_KERNEL);
if (gbl == NULL)
@@ -70,8 +69,8 @@ static int gpio_backlight_probe(struct platform_device *pdev)
if (pdata)
gbl->fbdev = pdata->fbdev;
- gbl->def_value = device_property_read_bool(>dev, "default-on");
- flags = gbl->def_value ? GPIOD_OUT_HIGH : GPIOD_OUT_LOW;
+ def_value = device_property_read_bool(>dev, "default-on");
+ flags = def_value ? GPIOD_OUT_HIGH : GPIOD_OUT_LOW;
gbl->gpiod = devm_gpiod_get(>dev, NULL, flags);
if (IS_ERR(gbl->gpiod)) {
@@ -94,7 +93,7 @@ static int gpio_backlight_probe(struct platform_device *pdev)
return PTR_ERR(bl);
}
- bl->props.brightness = gbl->def_value;
+ bl->props.brightness = def_value;
backlight_update_status(bl);
platform_set_drvdata(pdev, bl);
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amd/display: Restore backlight brightness after system resume
Laptops with AMD APU doesn't restore display backlight brightness after
system resume.
This issue started when DC was introduced.
Let's use BL_CORE_SUSPENDRESUME so the backlight core calls
update_status callback after system resume to restore the backlight
level.
Tested on Dell Inspiron 3180 (Stoney Ridge) and Dell Latitude 5495
(Raven Ridge).
Cc:
Signed-off-by: Kai-Heng Feng
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 1b0949dd7808..183ef18ac6f3 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -2111,6 +2111,7 @@ static int amdgpu_dm_backlight_get_brightness(struct
backlight_device *bd)
}
static const struct backlight_ops amdgpu_dm_backlight_ops = {
+ .options = BL_CORE_SUSPENDRESUME,
.get_brightness = amdgpu_dm_backlight_get_brightness,
.update_status = amdgpu_dm_backlight_update_status,
};
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] video/fbdev/68328fb: Remove dead code
This is dead code since 3.15. If their is no plan to
use it further, these can be removed forever.
Signed-off-by: Souptick Joarder
---
drivers/video/fbdev/68328fb.c | 12
1 file changed, 12 deletions(-)
diff --git a/drivers/video/fbdev/68328fb.c b/drivers/video/fbdev/68328fb.c
index d48e960..02d22b7 100644
--- a/drivers/video/fbdev/68328fb.c
+++ b/drivers/video/fbdev/68328fb.c
@@ -405,20 +405,8 @@ static int mc68x328fb_mmap(struct fb_info *info, struct
vm_area_struct *vma)
int __init mc68x328fb_setup(char *options)
{
-#if 0
- char *this_opt;
-#endif
-
if (!options || !*options)
return 1;
-#if 0
- while ((this_opt = strsep(, ",")) != NULL) {
- if (!*this_opt)
- continue;
- if (!strncmp(this_opt, "disable", 7))
- mc68x328fb_enable = 0;
- }
-#endif
return 1;
}
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1] backlight: lm3630a: Switch to use fwnode_property_count_uXX()
On Mon, Aug 12, 2019 at 09:04:44AM +0100, Lee Jones wrote: > On Tue, 23 Jul 2019, Andy Shevchenko wrote: > > > Use use fwnode_property_count_uXX() directly, that makes code neater. > > > > Signed-off-by: Andy Shevchenko > > --- > > drivers/video/backlight/lm3630a_bl.c | 3 +-- > > 1 file changed, 1 insertion(+), 2 deletions(-) > > Applied, thanks. Thanks. However, I haven't still noticed a trace of it in Linux next. -- With Best Regards, Andy Shevchenko ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm/edid: no CEA extension is not an error
On Mon, 2 Sep 2019 14:46:51 +0300, Ville Syrjälä wrote:
> On Fri, Aug 30, 2019 at 06:16:52PM +0200, Jean Delvare wrote:
> > It is fine for displays without audio functionality to not implement
> > CEA extension in their EDID. Do not return an error in that case,
> > instead return 0 as if there was a CEA extension with no audio or
> > speaker block.
> >
> > This fixes half of bug fdo#107825:
> > https://bugs.freedesktop.org/show_bug.cgi?id=107825
> >
> > Signed-off-by: Jean Delvare
> > Cc: Maarten Lankhorst
> > Cc: Maxime Ripard
> > Cc: Sean Paul
> > Cc: David Airlie
> > Cc: Daniel Vetter
> > ---
> > drivers/gpu/drm/drm_edid.c |4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > --- linux-5.2.orig/drivers/gpu/drm/drm_edid.c 2019-08-30
> > 17:57:38.10995 +0200
> > +++ linux-5.2/drivers/gpu/drm/drm_edid.c2019-08-30 18:04:36.840333834
> > +0200
> > @@ -4130,7 +4130,7 @@ int drm_edid_to_sad(struct edid *edid, s
> > cea = drm_find_cea_extension(edid);
> > if (!cea) {
> > DRM_DEBUG_KMS("SAD: no CEA Extension found\n");
> > - return -ENOENT;
> > + return 0;
> > }
>
> Seems reasonable. Maybe the cea_revision<3 branches should alse return 0?
I wasn't sure about that one, as I'm not familiar with this CEA
extension thing.
If revision < 3 means the data is invalid then returning an error is
fine. If on the other hand revision < 3 simply means that the block
types we are looking for were not defined back then yes returning 0
instead would be better.
I'll do whatever developers more familiar with this topic think is
better.
> Either way
> Reviewed-by: Ville Syrjälä
Thanks,
--
Jean Delvare
SUSE L3 Support
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111524] AMD A9 R5 GPU doesn't work after resume
https://bugs.freedesktop.org/show_bug.cgi?id=111524 --- Comment #5 from Samuel Sieb --- Created attachment 145236 --> https://bugs.freedesktop.org/attachment.cgi?id=145236=edit dmesg with drm.debug=4 I've seen mention elsewhere about setting the drm.debug value. If you need a different setting, let me know. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 204725] black screen
https://bugzilla.kernel.org/show_bug.cgi?id=204725 --- Comment #46 from Dmitri Seletski (drj...@gmail.com) --- (In reply to Mike Lothian from comment #37) > I think you need CONFIG_FB_SIMPLE & CONFIG_FB_BOOT_VESA_SUPPORT=y configured > > This is what I have in my .config for a Ryzen card > > CONFIG_DRM_KMS_FB_HELPER=y > CONFIG_FB_CMDLINE=y > CONFIG_FB_NOTIFY=y > CONFIG_FB_CFB_FILLRECT=y > CONFIG_FB_CFB_COPYAREA=y > CONFIG_FB_CFB_IMAGEBLIT=y > CONFIG_FB_SYS_FILLRECT=y > CONFIG_FB_SYS_COPYAREA=y > CONFIG_FB_SYS_IMAGEBLIT=y > CONFIG_FB_SYS_FOPS=y > CONFIG_FB_DEFERRED_IO=y > CONFIG_FB_MODE_HELPERS=y > CONFIG_FB_EFI=y > CONFIG_FB_SIMPLE=y > > And I'm sure I had the above issue when playing with these options before I am a little confused. CONFIG_DRM_KMS_FB_HELPER I have this in my 'make menuconfig' │ Symbol: DRM_KMS_FB_HELPER [=n] │ │ Type : bool │ │ Defined at drivers/gpu/drm/Kconfig:75 │ │ Depends on: HAS_IOMEM [=y] && DRM_KMS_HELPER [=m] I checked every option under 'drivers/gpu/drm/' I don't see one option with description of 'CONFIG_DRM_KMS_FB_HELPER'. Is this normal? I only have, under "Device Drivers > Graphics support > Direct Rendering Manager (XFree86 4.1.0 and higher DRI support)": --- Direct Rendering Manager (XFree86 4.1.0 and higher DRI support) │ │ │ │ [ ] DRM DP AUX Interface │ │ │ │ [ ] Insert extra checks and debug info into the DRM range managers │ │ │ │ < > kselftests for DRM │ │ │ │ [ ] Enable legacy fbdev support for your modesetting driver │ │ │ │ [*] Allow to specify an EDID data set instead of probing for it. I supposed I can just add CONFIG_DRM_KMS_FB_HELPER=y line to .config and compile it this way, but why is it disabled and not in config file by default? Is it even significant? -- 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: Adreno crash on i.MX53 running 5.3-rc6
Hi Robin, On Mon, Sep 2, 2019 at 11:45 AM Robin Murphy wrote: > Try 0036bc73ccbe - that looks like something that CONFIG_DMA_API_DEBUG > should have been screaming about anyway. Thanks for your suggestion. I can successfully boot after reverting the following commits: commit 141db5703c887f46957615cd6616ca28fe4691e0 (HEAD) Author: Fabio Estevam Date: Mon Sep 2 14:58:18 2019 -0300 Revert "drm/msm: stop abusing dma_map/unmap for cache" This reverts commit 0036bc73ccbe7e600a3468bf8e8879b122252274. commit fa5b1f620f2984c254877d6049214c39c24c8207 Author: Fabio Estevam Date: Mon Sep 2 14:56:01 2019 -0300 Revert "drm/msm: Use the correct dma_sync calls in msm_gem" This reverts commit 3de433c5b38af49a5fc7602721e2ab5d39f1e69c. Rob, What would be the recommended approach for fixing this? Thanks ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 201497] [amdgpu]: '*ERROR* No EDID read' is back in 4.19
https://bugzilla.kernel.org/show_bug.cgi?id=201497 --- Comment #10 from Daniel Andersson (engyw...@gmail.com) --- Is this going to get fixed? -- 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] drm/amd/display: Restore backlight brightness after system resume
Hi,
[This is an automated email]
This commit has been processed because it contains a -stable tag.
The stable tag indicates that it's relevant for the following trees: all
The bot has tested the following trees: v5.2.11, v4.19.69, v4.14.141, v4.9.190,
v4.4.190.
v5.2.11: Build OK!
v4.19.69: Build OK!
v4.14.141: Failed to apply! Possible dependencies:
1b0c0f9dc5ca ("drm/amdgpu: move userptr BOs to CPU domain during CS v2")
1ed3d2567c80 ("drm/amdgpu: keep the MMU lock until the update ends v4")
3fe89771cb0a ("drm/amdgpu: stop reserving the BO in the MMU callback v3")
4562236b3bc0 ("drm/amd/dc: Add dc display driver (v2)")
60de1c1740f3 ("drm/amdgpu: use a rw_semaphore for MMU notifiers")
9a18999640fa ("drm/amdgpu: move MMU notifier related defines to
amdgpu_mn.h")
9cca0b8e5df0 ("drm/amdgpu: move amdgpu_cs_sysvm_access_required into
find_mapping")
a216ab09955d ("drm/amdgpu: fix userptr put_page handling")
b72cf4fca2bb ("drm/amdgpu: move taking mmap_sem into get_user_pages v2")
ca666a3c298f ("drm/amdgpu: stop using BO status for user pages")
v4.9.190: Failed to apply! Possible dependencies:
1cec20f0ea0e ("dma-buf: Restart reservation_object_wait_timeout_rcu() after
writes")
3fe89771cb0a ("drm/amdgpu: stop reserving the BO in the MMU callback v3")
4562236b3bc0 ("drm/amd/dc: Add dc display driver (v2)")
4df654d293c6 ("drm/amdgpu: move amdgpu_uvd structure to uvd header")
5e5681788bef ("drm/amdgpu: move amdgpu_vce structure to vce header")
660e855813f7 ("amdgpu: use drm sync objects for shared semaphores (v6)")
78010cd9736e ("dma-buf/fence: add an lockdep_assert_held()")
95aa13f6b196 ("drm/amdgpu: move amdgpu_vcn structure to vcn header")
95d0906f8506 ("drm/amdgpu: add initial vcn support and decode tests")
9a18999640fa ("drm/amdgpu: move MMU notifier related defines to
amdgpu_mn.h")
b636922553ee ("drm/amdgpu: only move VM BOs in the LRU during validation
v2")
b72cf4fca2bb ("drm/amdgpu: move taking mmap_sem into get_user_pages v2")
f54d1867005c ("dma-buf: Rename struct fence to dma_fence")
fedf54132d24 ("dma-buf: Restart reservation_object_get_fences_rcu() after
writes")
v4.4.190: Failed to apply! Possible dependencies:
1f7371b2a5fa ("drm/amd/powerplay: add basic powerplay framework")
288912cb95d1 ("drm/amdgpu: use $(src) in Makefile (v2)")
37cd0ca204a5 ("drm/amdgpu: unify AMDGPU_CTX_MAX_CS_PENDING and
amdgpu_sched_jobs")
3c0eea6c35d9 ("drm/amdgpu: put VM page tables directly into duplicates
list")
3f99dd814a6f ("drm/amdgpu: save and restore UVD context with suspend and
resume")
4325198180e5 ("drm/amdgpu: remove GART page addr array")
4562236b3bc0 ("drm/amd/dc: Add dc display driver (v2)")
4acabfe3793e ("drm/amdgpu: fix num_ibs check")
4df654d293c6 ("drm/amdgpu: move amdgpu_uvd structure to uvd header")
50838c8cc413 ("drm/amdgpu: add proper job alloc/free functions")
56467ebfb254 ("drm/amdgpu: split VM PD and PT handling during CS")
5e5681788bef ("drm/amdgpu: move amdgpu_vce structure to vce header")
7270f8391df1 ("drm/amdgpu: add amdgpu_set_ib_value helper (v2)")
95aa13f6b196 ("drm/amdgpu: move amdgpu_vcn structure to vcn header")
9a18999640fa ("drm/amdgpu: move MMU notifier related defines to
amdgpu_mn.h")
a1d29476d666 ("drm/amdgpu: optionally enable GART debugfs file")
a8fe58cec351 ("drm/amd: add ACP driver support")
c036554170fc ("drm/amdgpu: handle more than 10 UVD sessions (v2)")
c3cca41e6249 ("drm/amdgpu: cleanup amdgpu_cs_parser structure")
cadf97b196a1 ("drm/amdgpu: clean up non-scheduler code path (v2)")
cd75dc6887f1 ("drm/amdgpu: separate pushing CS to scheduler")
d71518b5aa7c ("drm/amdgpu: cleanup in kernel job submission")
d7af97dbccf0 ("drm/amdgpu: send UVD IB tests directly to the ring again")
d8e0cae64550 ("drm/amdgpu: validate duplicates first")
f69f90a113f2 ("drm/amdgpu: fix amdgpu_cs_get_threshold_for_moves handling")
fdba11f4079e ("drm/amdgpu: move all Kconfig options to amdgpu/Kconfig")
NOTE: The patch will not be queued to stable trees until it is upstream.
How should we proceed with this patch?
--
Thanks,
Sasha
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111077] link_shader and deserialize_glsl_program suddenly consume huge amount of RAM
https://bugs.freedesktop.org/show_bug.cgi?id=111077 --- Comment #22 from rol...@rptd.ch --- Hi Marek, This is going to be complicated. The application is not yet free to use by others (working on getting it to release shape). I would have to figure out first how to break this down into a reproducible test case since I don't know myself what triggers the bug. If you can think of some corner values to narrow down in what direction to search I can fully mess with the source code over here. The faulty commit talks about UBO maximum size so this might be a start. The OpenGL Capabilities from the GPU is this: - UBO Maximum Block Size = 65536 - UBO Buffer Offset Alignment = 4 So the maximum size used by the application is 65536 bytes. UBOs are used as shared buffers so blocks of data are placed next to each other respecting alignment and updated. UBOs are created like this: glBindBuffer(GL_UNIFORM_BUFFER, pUBO) // <= done once glBufferData(GL_UNIFORM_BUFFER, bufferSize, NULL, GL_DYNAMIC_DRAW) // <= done once glMapBufferRange(GL_UNIFORM_BUFFER, stride * elementCount, elementStride, GL_WRITE_ONLY | GL_MAP_INVALIDATE_RANGE_BIT) // <= done for each data block written Data then written and unmapped In particular this means a larger UBO is created once then individual blocks are written to it using ranged mapping. Just a wield guess but could the problem be related to this kind of usage pattern? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 204725] black screen
https://bugzilla.kernel.org/show_bug.cgi?id=204725 --- Comment #45 from Dmitri Seletski (drj...@gmail.com) --- (In reply to Michel Dänzer from comment #44) > (In reply to Dmitri Seletski from comment #39) > > /usr/lib64/dri/swrast_dri.so failed (libLLVMAMDGPUCodeGen.so.8: cannot open > > shared object file: No such file or directory) > > BTW, LLVM only builds shared libraries like libLLVMAMDGPUCodeGen if > BUILD_SHARED_LIBS is enabled in its build configuration, which is bad for > performance and other reasons. Make sure you don't have any customization > which enables this, and if Gentoo enables it by default, please ask them not > to. LLVM_BUILD_LLVM_DYLIB should be enabled instead. I have send email to llvm mainteiners of Gentoo. I am just a user, in case what. -- 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 1/2] drm/panel: Add DT bindings for Sony ACX424AKP
On Mon, Sep 2, 2019 at 4:40 PM Thierry Reding wrote: > Hm... my recollection is that command mode is only supported on "smart" > panels that have an internal framebuffer. So the commands actually > instruct the panel to update their internal framebuffer, which means you > can technically switch off the display engine when there are no updates. That is my understanding as well. > Under those circumstances I think it'd make sense to default to command > mode if both the panel and the host support it and stick with video mode > if for example the host can't do command mode. Makes sense to me. Maybe we should rather have a generic setting like: dsi-enforce-video-mode; and the default always being command mode, if we have consensus that command mode should always be preferred. > Or perhaps this is something that could be set from some userspace > policy maker via a connector property? A compositor for instance would > have a pretty good idea of what kind of activity is going on, so it > could at some point decide to switch between video mode and command mode > if one of them is more appropriate for the given workload. It's probably more that userspace should be made aware of the fact that we have partial updates, and if I understand correctly that is done by dirtyrect/damage API in drm_damage_helper.c (Very nice overview doc at the top of the file!) The driver enables damage by calling drm_plane_enable_fb_damage_clips() then in the .update() callback uses drm_atomic_helper_damage_merged() to figure out damaged rectangles and update those with special commands. tinydrm/ili9225.c is a pretty clean example of a driver actually doing this. There are not many of them. > Command mode can also be used to do partial updates, if I remember > correctly, which again would make it possible for a compositor to send > only a subset of a screen update. Indeed, who needs a blitter when you can just update the dirtyrects. It is a bit terse but intuitively I feel that the damage interface is what userspace should use, then DRM should be able to infer that a damaged rectangle can be updated on the display, and the display controller need to announce that it can handle these partial updates. This requires that the display controller can generate such complex command streams in response to drm_atomic_helper_damage_merged() of course, from a DSI protocol level it is supported, but we are not writing these command sequences with software, they are generated by hardware. So the display controller DSI portions must be able to send individual rectangles as well. But this is all science fiction. What all DSI display controllers in mailine do today (I think) is to simply scan out the whole framebuffer continously with a vblank TE IRQ to avoid tearing. Andrzej knows for sure what is out there I think. Yours, Linus Walleij ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111481] AMD Navi GPU frequent freezes on both Manjaro/Ubuntu with kernel 5.3 and mesa 19.2 -git/llvm9
https://bugs.freedesktop.org/show_bug.cgi?id=111481 --- Comment #24 from Marko Popovic --- (In reply to Pierre-Eric Pelloux-Prayer from comment #22) > Yes, it's possible that there are different bugs. > > For the citra bug: I suspect an issue with Geometry Shaders + NGG but this > will require more debugging to confirm (also: using wavesize=64 didn't help, > so it's not a regression caused by a0d330bedb9e). > > I'm also testing using AMD_DEBUG=nodma system wide to see if it prevents the > sdma0 kind of hangs. Ok, I confirm that AMD_DEBUG=nodma gets rid of Rocket-League startup crash, will report about the desktop stability for the rest of the day! -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111481] AMD Navi GPU frequent freezes on both Manjaro/Ubuntu with kernel 5.3 and mesa 19.2 -git/llvm9
https://bugs.freedesktop.org/show_bug.cgi?id=111481 --- Comment #23 from Marko Popovic --- (In reply to Pierre-Eric Pelloux-Prayer from comment #22) > > Okay I just got another random hang on the desktop. even with the > > environment variable turned on the whole time. Unfortunately it seems to be > > very hardly tracable seems to be very random :( Seems that Citra hang is > > unrelated to this bug after all, it's a completely different bug. It's good > > that we discovered another (citra-related) bug on the way but probably we > > can't mark that workaround to solve anything because hangs still randomly > > occur on the desktop. > > Yes, it's possible that there are different bugs. > > For the citra bug: I suspect an issue with Geometry Shaders + NGG but this > will require more debugging to confirm (also: using wavesize=64 didn't help, > so it's not a regression caused by a0d330bedb9e). > > I'm also testing using AMD_DEBUG=nodma system wide to see if it prevents the > sdma0 kind of hangs. Yes both Rocket League and Desktop hangs seem to be the sdma0 type. I will add that parameter as well and see if there is any difference with Rocket League hang and use the desktop with both flags enabled. Well I mean actually finding multiple bugs while debugging 1 can only be a good thing, after all less bugs in the future and my personal computing seems to have quite a few corner cases it seems that otherwise go unnoticed :D which should benefit many new happy Navi users -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111481] AMD Navi GPU frequent freezes on both Manjaro/Ubuntu with kernel 5.3 and mesa 19.2 -git/llvm9
https://bugs.freedesktop.org/show_bug.cgi?id=111481 --- Comment #22 from Pierre-Eric Pelloux-Prayer --- > Okay I just got another random hang on the desktop. even with the > environment variable turned on the whole time. Unfortunately it seems to be > very hardly tracable seems to be very random :( Seems that Citra hang is > unrelated to this bug after all, it's a completely different bug. It's good > that we discovered another (citra-related) bug on the way but probably we > can't mark that workaround to solve anything because hangs still randomly > occur on the desktop. Yes, it's possible that there are different bugs. For the citra bug: I suspect an issue with Geometry Shaders + NGG but this will require more debugging to confirm (also: using wavesize=64 didn't help, so it's not a regression caused by a0d330bedb9e). I'm also testing using AMD_DEBUG=nodma system wide to see if it prevents the sdma0 kind of hangs. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111481] AMD Navi GPU frequent freezes on both Manjaro/Ubuntu with kernel 5.3 and mesa 19.2 -git/llvm9
https://bugs.freedesktop.org/show_bug.cgi?id=111481 --- Comment #21 from Marko Popovic --- (In reply to Pierre-Eric Pelloux-Prayer from comment #19) > (In reply to Marko Popovic from comment #17) > > (In reply to Pierre-Eric Pelloux-Prayer from comment #15) > > > (In reply to Marko Popovic from comment #14) > > > > > > > > Yes, always happens at the same place with Citra emulator > > > > > > Could you capture a trace of the problem (using Apitrace or Renderdoc)? > > > > > > This would be very helpful to fix it. > > > > I added reproduced Citra crash recorded by using command: > > apitrace trace ./citra-qt > > > > I hope this is correct, if you need anything else or done differently please > > just let me know! > > Thanks for the trace! > > Replaying the trace a few times is enough to reliably to reproduce the hang. > > Using AMD_DEBUG=nongg seems to prevent it so it could be a temporary > workaround until a proper fix is found. > Could you confirm this on your system? > > > > > > I am adding Rocket League crash output from apitrace. > > This trace file is very small (only one frame) and doesn't hang here. Okay I just got another random hang on the desktop. even with the environment variable turned on the whole time. Unfortunately it seems to be very hardly tracable seems to be very random :( Seems that Citra hang is unrelated to this bug after all, it's a completely different bug. It's good that we discovered another (citra-related) bug on the way but probably we can't mark that workaround to solve anything because hangs still randomly occur on the desktop. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/mcde: Some fixes to handling video mode
On Mon, Sep 02, 2019 at 09:17:14AM +0200, Linus Walleij wrote:
> The video DSI mode had not really been tested. These fixes makes
> it more likely to work on real hardware:
> - Set the HS clock to something the video mode reported by the
> panel can handle rather than the max HS rate.
> - Put the active width (x width) in the right bits and the VSA
> (vertical sync active) in the right bits (those were swapped).
> - Calculate the packet sizes in bytes as in the vendor driver,
> rather than in bits.
> - Handle negative result in front/back/sync packages and fall
> back to zero like in the vendor driver.
>
> Cc: Stephan Gerhold
> Fixes: 5fc537bfd000 ("drm/mcde: Add new driver for ST-Ericsson MCDE")
> Signed-off-by: Linus Walleij
> ---
> drivers/gpu/drm/mcde/mcde_dsi.c | 60 ++---
> 1 file changed, 41 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/mcde/mcde_dsi.c b/drivers/gpu/drm/mcde/mcde_dsi.c
> index 90659d190d78..f5079f0e24ca 100644
> --- a/drivers/gpu/drm/mcde/mcde_dsi.c
> +++ b/drivers/gpu/drm/mcde/mcde_dsi.c
> @@ -365,11 +365,12 @@ void mcde_dsi_te_request(struct mipi_dsi_device *mdsi)
> static void mcde_dsi_setup_video_mode(struct mcde_dsi *d,
> const struct drm_display_mode *mode)
> {
> - u8 bpp = mipi_dsi_pixel_format_to_bpp(d->mdsi->format);
> + /* cpp, characters per pixel, number of bytes per pixel */
> + u8 cpp = mipi_dsi_pixel_format_to_bpp(d->mdsi->format) / 8;
> u64 bpl;
> - u32 hfp;
> - u32 hbp;
> - u32 hsa;
> + int hfp;
> + int hbp;
> + int hsa;
> u32 blkline_pck, line_duration;
> u32 blkeol_pck, blkeol_duration;
> u32 val;
> @@ -420,13 +421,13 @@ static void mcde_dsi_setup_video_mode(struct mcde_dsi
> *d,
> writel(val, d->regs + DSI_VID_MAIN_CTL);
>
> /* Vertical frame parameters are pretty straight-forward */
> - val = mode->vdisplay << DSI_VID_VSIZE_VSA_LENGTH_SHIFT;
> + val = mode->vdisplay << DSI_VID_VSIZE_VACT_LENGTH_SHIFT;
> /* vertical front porch */
> val |= (mode->vsync_start - mode->vdisplay)
> << DSI_VID_VSIZE_VFP_LENGTH_SHIFT;
> /* vertical sync active */
> val |= (mode->vsync_end - mode->vsync_start)
> - << DSI_VID_VSIZE_VACT_LENGTH_SHIFT;
> + << DSI_VID_VSIZE_VSA_LENGTH_SHIFT;
> /* vertical back porch */
> val |= (mode->vtotal - mode->vsync_end)
> << DSI_VID_VSIZE_VBP_LENGTH_SHIFT;
> @@ -437,21 +438,25 @@ static void mcde_dsi_setup_video_mode(struct mcde_dsi
> *d,
>* horizontal resolution is given in pixels and must be re-calculated
>* into bytes since this is what the hardware expects.
>*
> + * hfp = horizontal front porch in bytes
> + * hbp = horizontal back porch in bytes
> + * hsa = horizontal sync active in bytes
> + *
>* 6 + 2 is HFP header + checksum
>*/
> - hfp = (mode->hsync_start - mode->hdisplay) * bpp - 6 - 2;
> + hfp = (mode->hsync_start - mode->hdisplay) * cpp - 6 - 2;
> if (d->mdsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE) {
> /*
>* 6 is HBP header + checksum
>* 4 is RGB header + checksum
>*/
> - hbp = (mode->htotal - mode->hsync_end) * bpp - 4 - 6;
> + hbp = (mode->htotal - mode->hsync_end) * cpp - 4 - 6;
> /*
>* 6 is HBP header + checksum
>* 4 is HSW packet bytes
>* 4 is RGB header + checksum
>*/
> - hsa = (mode->hsync_end - mode->hsync_start) * bpp - 4 - 4 - 6;
> + hsa = (mode->hsync_end - mode->hsync_start) * cpp - 4 - 4 - 6;
> } else {
> /*
>* HBP includes both back porch and sync
> @@ -459,11 +464,23 @@ static void mcde_dsi_setup_video_mode(struct mcde_dsi
> *d,
>* 4 is HSW packet bytes
>* 4 is RGB header + checksum
>*/
> - hbp = (mode->htotal - mode->hsync_start) * bpp - 4 - 4 - 6;
> - /* HSA is not considered in this mode and set to 0 */
> + hbp = (mode->htotal - mode->hsync_start) * cpp - 4 - 4 - 6;
> + /* HSA is not present in this mode and set to 0 */
> + hsa = 0;
> + }
> + if (hfp < 0) {
> + dev_info(d->dev, "hfp negative, set to 0\n");
> + hfp = 0;
> + }
> + if (hbp < 0) {
> + dev_info(d->dev, "hbp negative, set to 0\n");
> + hbp = 0;
> + }
> + if (hsa < 0) {
> + dev_info(d->dev, "hsa negative, set to 0\n");
> hsa = 0;
> }
> - dev_dbg(d->dev, "hfp: %u, hbp: %u, hsa: %u\n",
> + dev_dbg(d->dev, "hfp: %u, hbp: %u, hsa: %u bytes\n",
> hfp, hbp, hsa);
>
> /* Frame parameters: horizontal sync active */
> @@ -475,7 +492,7 @@ static void
Re: [PATCH 1/2] drm/panel: Add DT bindings for Sony ACX424AKP
On Mon, Sep 02, 2019 at 04:40:06PM +0200, Thierry Reding wrote: > On Mon, Sep 02, 2019 at 01:44:38PM +0200, Linus Walleij wrote: > > On Mon, Sep 2, 2019 at 11:35 AM Thierry Reding > > wrote: > > > > > > + dsi-command-mode: > > > > + type: boolean > > > > + description: > > > > + If this is specified, the panel will be used in command > > > > + mode instead of video mode. > > > > > > I'm not sure there's concensus on this one yet. I think so far the > > > driver decides which mode to use the panel in. Technically this falls > > > into the category of configuration, so it doesn't really belong in the > > > DT. > > > > The way we've used DT is for a bit of both hardware description > > and configuration I'd say, but I'm no authority on the subject. I'm okay with this if there's consensus, but it should be in a common doc. We probably need a dsi-commom schema with this, reg, ??. > > > > > I vaguely recall from discussions I've had on this subject that there's > > > usually no reason to do video mode if you can do command mode because > > > command mode is more power efficient. This was a long time ago, so I may > > > be misremembering. Perhaps you have different information on this? 30 or 60fps updates tend to be impossible because you have less b/w and it's async to the refresh. I think most panels that can do both, always need command mode too for initialization. > > No idea. I was under the impression that video mode was preferred > > but I have no idea why. > > Hm... my recollection is that command mode is only supported on "smart" > panels that have an internal framebuffer. So the commands actually > instruct the panel to update their internal framebuffer, which means you > can technically switch off the display engine when there are no updates. > > Under those circumstances I think it'd make sense to default to command > mode if both the panel and the host support it and stick with video mode > if for example the host can't do command mode. > > Or perhaps this is something that could be set from some userspace > policy maker via a connector property? A compositor for instance would > have a pretty good idea of what kind of activity is going on, so it > could at some point decide to switch between video mode and command mode > if one of them is more appropriate for the given workload. > > Command mode can also be used to do partial updates, if I remember > correctly, which again would make it possible for a compositor to send > only a subset of a screen update. All makes sense to me. Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/mcde: Fix DSI transfers
On Sat, Aug 31, 2019 at 09:50:13AM +0200, Linus Walleij wrote:
> There were bugs in the DSI transfer (read and write) function
> as it was only tested with displays ever needing a single byte
> to be written. Fixed it up and tested so we can now write
> messages of up to 16 bytes and read up to 4 bytes from the
> display.
>
> Tested with a Sony ACX424AKP display: this display now self-
> identifies and can control backlight in command mode.
>
> Cc: Stephan Gerhold
> Reported-by: kbuild test robot
> Fixes: 5fc537bfd000 ("drm/mcde: Add new driver for ST-Ericsson MCDE")
> Signed-off-by: Linus Walleij
> ---
> ChangeLog v1->v2:
> - Fix a print modifier for dev_err() found by the build robot.
> ---
> drivers/gpu/drm/mcde/mcde_dsi.c | 70 ++---
> 1 file changed, 47 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/gpu/drm/mcde/mcde_dsi.c b/drivers/gpu/drm/mcde/mcde_dsi.c
> index 07f7090d08b3..90659d190d78 100644
> --- a/drivers/gpu/drm/mcde/mcde_dsi.c
> +++ b/drivers/gpu/drm/mcde/mcde_dsi.c
> @@ -178,22 +178,26 @@ static ssize_t mcde_dsi_host_transfer(struct
> mipi_dsi_host *host,
> const u32 loop_delay_us = 10; /* us */
> const u8 *tx = msg->tx_buf;
> u32 loop_counter;
> - size_t txlen;
> + size_t txlen = msg->tx_len;
> + size_t rxlen = msg->rx_len;
> u32 val;
> int ret;
> int i;
>
> - txlen = msg->tx_len;
> - if (txlen > 12) {
> + if (txlen > 16) {
> dev_err(d->dev,
> - "dunno how to write more than 12 bytes yet\n");
> + "dunno how to write more than 16 bytes yet\n");
> + return -EIO;
> + }
> + if (rxlen > 4) {
> + dev_err(d->dev,
> + "dunno how to read more than 4 bytes yet\n");
> return -EIO;
> }
>
> dev_dbg(d->dev,
> - "message to channel %d, %zd bytes",
> - msg->channel,
> - txlen);
> + "message to channel %d, write %zd bytes read %zd bytes\n",
> + msg->channel, txlen, rxlen);
>
> /* Command "nature" */
> if (MCDE_DSI_HOST_IS_READ(msg->type))
> @@ -210,9 +214,7 @@ static ssize_t mcde_dsi_host_transfer(struct
> mipi_dsi_host *host,
> if (mipi_dsi_packet_format_is_long(msg->type))
> val |= DSI_DIRECT_CMD_MAIN_SETTINGS_CMD_LONGNOTSHORT;
> val |= 0 << DSI_DIRECT_CMD_MAIN_SETTINGS_CMD_ID_SHIFT;
> - /* Add one to the length for the MIPI DCS command */
> - val |= txlen
> - << DSI_DIRECT_CMD_MAIN_SETTINGS_CMD_SIZE_SHIFT;
> + val |= txlen << DSI_DIRECT_CMD_MAIN_SETTINGS_CMD_SIZE_SHIFT;
> val |= DSI_DIRECT_CMD_MAIN_SETTINGS_CMD_LP_EN;
> val |= msg->type << DSI_DIRECT_CMD_MAIN_SETTINGS_CMD_HEAD_SHIFT;
> writel(val, d->regs + DSI_DIRECT_CMD_MAIN_SETTINGS);
> @@ -249,17 +251,36 @@ static ssize_t mcde_dsi_host_transfer(struct
> mipi_dsi_host *host,
> writel(1, d->regs + DSI_DIRECT_CMD_SEND);
>
> loop_counter = 1000 * 1000 / loop_delay_us;
> - while (!(readl(d->regs + DSI_DIRECT_CMD_STS) &
> - DSI_DIRECT_CMD_STS_WRITE_COMPLETED)
> -&& --loop_counter)
> - usleep_range(loop_delay_us, (loop_delay_us * 3) / 2);
> -
> - if (!loop_counter) {
> - dev_err(d->dev, "DSI write timeout!\n");
> - return -ETIME;
> + if (MCDE_DSI_HOST_IS_READ(msg->type)) {
> + /* Read command */
> + while (!(readl(d->regs + DSI_DIRECT_CMD_STS) &
> + (DSI_DIRECT_CMD_STS_READ_COMPLETED |
> + DSI_DIRECT_CMD_STS_READ_COMPLETED_WITH_ERR))
> +&& --loop_counter)
> + usleep_range(loop_delay_us, (loop_delay_us * 3) / 2);
> + if (!loop_counter) {
> + dev_err(d->dev, "DSI write timeout!\n");
"DSI read timeout!" might be more apppropriate here?
> + return -ETIME;
> + }
> + } else {
> + /* Writing only */
> + while (!(readl(d->regs + DSI_DIRECT_CMD_STS) &
> + DSI_DIRECT_CMD_STS_WRITE_COMPLETED)
> +&& --loop_counter)
> + usleep_range(loop_delay_us, (loop_delay_us * 3) / 2);
> +
> + if (!loop_counter) {
> + dev_err(d->dev, "DSI write timeout!\n");
> + return -ETIME;
> + }
> }
>
> val = readl(d->regs + DSI_DIRECT_CMD_STS);
> + if (val & DSI_DIRECT_CMD_STS_READ_COMPLETED_WITH_ERR) {
> + dev_err(d->dev, "read completed with error\n");
> + writel(1, d->regs + DSI_DIRECT_CMD_RD_INIT);
> + return -EIO;
> + }
> if (val & DSI_DIRECT_CMD_STS_ACKNOWLEDGE_WITH_ERR_RECEIVED) {
> val >>= DSI_DIRECT_CMD_STS_ACK_VAL_SHIFT;
> dev_err(d->dev, "error during transmission: %04x\n",
> @@ -269,10 +290,7 @@ static
Re: [PATCH v1] backlight: lm3630a: Switch to use fwnode_property_count_uXX()
On Mon, 02 Sep 2019, Andy Shevchenko wrote: > On Mon, Aug 12, 2019 at 09:04:44AM +0100, Lee Jones wrote: > > On Tue, 23 Jul 2019, Andy Shevchenko wrote: > > > > > Use use fwnode_property_count_uXX() directly, that makes code neater. > > > > > > Signed-off-by: Andy Shevchenko > > > --- > > > drivers/video/backlight/lm3630a_bl.c | 3 +-- > > > 1 file changed, 1 insertion(+), 2 deletions(-) > > > > Applied, thanks. > > Thanks. > However, I haven't still noticed a trace of it in Linux next. Just did a big push. It should be in there by tomorrow. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Adreno crash on i.MX53 running 5.3-rc6
On 02/09/2019 14:51, Fabio Estevam wrote: Hi, I am getting the following crash when booting the adreno driver on i.MX53 running a 5.3-rc6 kernel. Such error does not happen with 5.2 though. Before I start running a bisect, I am wondering if anyone has any ideas about this issue. Try 0036bc73ccbe - that looks like something that CONFIG_DMA_API_DEBUG should have been screaming about anyway. Robin. Thanks, Fabio Estevam [2.083249] 8<--- cut here --- [2.086460] Unable to handle kernel paging request at virtual address 50001000 [2.094174] pgd = (ptrval) [2.096911] [50001000] *pgd= [2.100606] Internal error: Oops: 805 [#1] SMP ARM [2.105412] Modules linked in: [2.108487] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.3.0-rc6-00271-g9f159ae07f07 #4 [2.116411] Hardware name: Freescale i.MX53 (Device Tree Support) [2.122538] PC is at v7_dma_clean_range+0x20/0x38 [2.127254] LR is at __dma_page_cpu_to_dev+0x28/0x90 [2.132226] pc : []lr : []psr: 2013 [2.138500] sp : d80b5a88 ip : de96c000 fp : d840ce6c [2.143732] r10: r9 : 0001 r8 : d843e010 [2.148964] r7 : r6 : 8000 r5 : ddb6c000 r4 : [2.155500] r3 : 003f r2 : 0040 r1 : 50008000 r0 : 50001000 [2.162037] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none [2.169180] Control: 10c5387d Table: 70004019 DAC: 0051 [2.174934] Process swapper/0 (pid: 1, stack limit = 0x(ptrval)) [2.180949] Stack: (0xd80b5a88 to 0xd80b6000) [2.185319] 5a80: c011c7bc d8491780 d840ce6c d849b380 c011822c [2.193509] 5aa0: c0d01a18 c0118abc c0118a78 d84a0200 0008 c1308908 d838e800 d849a4a8 [2.201697] 5ac0: d8491780 c06699b4 d8491600 d80b5b20 d84a0200 [2.209886] 5ae0: d8491780 d8491600 d80b5b20 d8491600 d849a4a8 d84a0200 0003 d84a0358 [2.218077] 5b00: c1308908 d8491600 d849a4a8 d8491780 d840ce6c c066a55c c1308908 c066a104 [2.226266] 5b20: 01001000 d84a0200 10700ac6 d849a480 d84a0200 d8491600 [2.234455] 5b40: e0845000 c1308908 c066a72c d849a480 d840ce6c d840ce00 c1308908 [2.242643] 5b60: c066b584 d849a488 d849a4a8 c1308908 d840ce6c c066ff40 [2.250832] 5b80: d849a488 d849a4a8 c1308908 d81b4000 e0845000 [2.259021] 5ba0: d838e800 c1308908 d8491600 10700ac6 d80b5bc8 d840ce00 d840ce6c 0001 [2.267210] 5bc0: e0845000 d838e800 c066ece4 0100 10ff [2.275399] 5be0: c1308908 0001 d81b4000 0100 0001 10700ac6 [2.283587] 5c00: c0d6d564 d840ce00 d81b4010 0001 d81b4000 c0d6d564 c1308908 d80b5c48 [2.291777] 5c20: d838e800 c061f9cc c1029dec d80b5c48 d838e800 c13e8788 [2.299965] 5c40: c1308928 c102a234 0100 10ff [2.308154] 5c60: 0001 a013 10700ac6 c13b7658 d840ce00 d838e800 d81b4000 [2.316343] 5c80: d840ce00 c1308908 0002 d838f800 c0620514 0001 10700ac6 [2.324531] 5ca0: d8496440 d81b4010 c1aa1c00 d838e800 c061e070 [2.332720] 5cc0: c0d6c534 df56cf34 00c8 10700ac6 d81b4010 [2.340909] 5ce0: d8496440 d838e800 c103acd0 d8496280 c1380488 c06a3e10 [2.349097] 5d00: d838f800 d838e800 d843e010 d8496440 c1308908 [2.357286] 5d20: d83f9640 c1380488 c0668554 0006 0007 c13804d4 d83f9640 [2.365475] 5d40: c1380488 c017ec18 d80c c0c43e40 d843e010 d8496440 0001 c0182a94 [2.373665] 5d60: 6013 10700ac6 d843e010 d8496280 d8496400 0018 d8496440 0001 [2.381854] 5d80: c13804d4 d83f9640 c1380488 c06a4280 c1380488 c0d764f8 d8496440 [2.390044] 5da0: c1380488 d843e010 c0d764f8 c1308908 c13ef300 c06a44f0 [2.398232] 5dc0: c0d8a0dc dffcc6f0 d843e010 dffcc6f0 d843e010 c06680b8 [2.406421] 5de0: d84988c0 d83f9640 d84988c0 d84989a0 d8498230 10700ac6 0001 d843e010 [2.414610] 5e00: c137eec0 c137eec0 c13ef300 c06ac1a0 [2.422799] 5e20: d843e010 c1aa40dc c1aa40e0 c137eec0 c06aa014 d843e010 c137eec0 [2.430988] 5e40: c137eec0 c1308908 c13e9880 c13e85d4 c06aa368 c1308908 c13e9880 [2.439178] 5e60: c13e85d4 d843e010 c137eec0 c1308908 c13e9880 c13e85d4 c06aa618 [2.447367] 5e80: c137eec0 d843e010 c06aa6a4 c137eec0 c06aa620 c06a844c [2.46] 5ea0: d80888d4 d80888a4 d84914d0 10700ac6 d80888d4 c137eec0 d8494f00 c1380d28 [2.463745] 5ec0: c06a946c c105f3d4 c1308908 c137eec0 c1308908 [2.471934] 5ee0: c125fdd0 c06ab304 c1308928 c1308908 c0103178 0109 [2.480123] 5f00: dc6e dc00 c1126860 0109 0109 c014dc88 c11253ac c10607a0
Re: [Intel-gfx] [PATCH v2 3/6] drm: Add DisplayPort colorspace property
On Fri, Aug 23, 2019 at 12:52:29PM +0300, Gwan-gyeong Mun wrote:
> In order to use colorspace property to Display Port connectors, it extends
> DRM_MODE_CONNECTOR_DisplayPort connector_type on
> drm_mode_create_colorspace_property function.
>
> Signed-off-by: Gwan-gyeong Mun
> ---
> drivers/gpu/drm/drm_connector.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 4c766624b20d..655ada9d4c16 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1703,7 +1703,9 @@ int drm_mode_create_colorspace_property(struct
> drm_connector *connector)
> struct drm_property *prop;
>
> if (connector->connector_type == DRM_MODE_CONNECTOR_HDMIA ||
> - connector->connector_type == DRM_MODE_CONNECTOR_HDMIB) {
> + connector->connector_type == DRM_MODE_CONNECTOR_HDMIB ||
> + connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
> + connector->connector_type == DRM_MODE_CONNECTOR_eDP) {
We don't need a separate set of enum values for DP?
> prop = drm_property_create_enum(dev, DRM_MODE_PROP_ENUM,
> "Colorspace",
> hdmi_colorspaces,
> --
> 2.22.0
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v2 2/6] drm/i915/dp: Add support of BT.2020 Colorimetry to DP MSA
On Fri, Aug 23, 2019 at 12:52:28PM +0300, Gwan-gyeong Mun wrote:
> When BT.2020 Colorimetry output is used for DP, we should program BT.2020
> Colorimetry to MSA and VSC SDP. It adds output_colorspace to
> intel_crtc_state struct as a place holder of pipe's output colorspace.
> In order to distinguish needed colorimetry for VSC SDP, it adds
> intel_dp_needs_vsc_colorimetry function.
> If the output colorspace requires vsc sdp or output format is YCbCr 4:2:0,
> it uses MSA with VSC SDP.
>
> As per DP 1.4a spec section 2.2.4.3 [MSA Field for Indication of
> Color Encoding Format and Content Color Gamut] while sending
> BT.2020 Colorimetry signals we should program MSA MISC1 fields which
> indicate VSC SDP for the Pixel Encoding/Colorimetry Format.
>
> v2: Remove useless parentheses
>
> Signed-off-by: Gwan-gyeong Mun
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 8 +++---
> .../drm/i915/display/intel_display_types.h| 3 +++
> drivers/gpu/drm/i915/display/intel_dp.c | 25 ++-
> drivers/gpu/drm/i915/display/intel_dp.h | 1 +
> 4 files changed, 33 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 4f7ea0a35976..5c42b58c1c2f 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -1737,11 +1737,13 @@ void intel_ddi_set_pipe_settings(const struct
> intel_crtc_state *crtc_state)
> /*
>* As per DP 1.4a spec section 2.2.4.3 [MSA Field for Indication
>* of Color Encoding Format and Content Color Gamut] while sending
> - * YCBCR 420 signals we should program MSA MISC1 fields which
> - * indicate VSC SDP for the Pixel Encoding/Colorimetry Format.
> + * YCBCR 420, HDR BT.2020 signals we should program MSA MISC1 fields
> + * which indicate VSC SDP for the Pixel Encoding/Colorimetry Format.
>*/
> - if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420)
> + if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420 ||
> + intel_dp_needs_vsc_colorimetry(crtc_state->output_colorspace))
> temp |= TRANS_MSA_USE_VSC_SDP;
> +
> I915_WRITE(TRANS_MSA_MISC(cpu_transcoder), temp);
> }
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 449abaea619f..9845abcf6f29 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -964,6 +964,9 @@ struct intel_crtc_state {
> /* Output format RGB/YCBCR etc */
> enum intel_output_format output_format;
>
> + /* Output colorspace sRGB/BT.2020 etc */
> + u32 output_colorspace;
> +
> /* Output down scaling is done in LSPCON device */
> bool lspcon_downsampling;
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 55d5ab97061c..295d5ed2be96 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -2164,6 +2164,8 @@ intel_dp_compute_config(struct intel_encoder *encoder,
> pipe_config->has_pch_encoder = true;
>
> pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
> + pipe_config->output_colorspace = intel_conn_state->base.colorspace;
> +
> if (lspcon->active)
> lspcon_ycbcr420_config(_connector->base, pipe_config);
> else
> @@ -4408,6 +4410,26 @@ u8 intel_dp_dsc_get_slice_count(struct intel_dp
> *intel_dp,
> return 0;
> }
>
> +bool
> +intel_dp_needs_vsc_colorimetry(u32 colorspace)
I would pass the entire crtc state here so you handle handle the 4:2:0
case here as well.
> +{
> + bool ret = false;
Pointless variable.
> +
> + switch (colorspace) {
> + case DRM_MODE_COLORIMETRY_SYCC_601:
> + case DRM_MODE_COLORIMETRY_OPYCC_601:
> + case DRM_MODE_COLORIMETRY_BT2020_YCC:
> + case DRM_MODE_COLORIMETRY_BT2020_RGB:
> + case DRM_MODE_COLORIMETRY_BT2020_CYCC:
> + ret = true;
> + break;
> + default:
> + break;
> + }
> +
> + return ret;
> +}
> +
> static void
> intel_dp_setup_vsc_sdp(struct intel_dp *intel_dp,
> const struct intel_crtc_state *crtc_state,
> @@ -4536,7 +4558,8 @@ void intel_dp_vsc_enable(struct intel_dp *intel_dp,
>const struct intel_crtc_state *crtc_state,
>const struct drm_connector_state *conn_state)
> {
> - if (crtc_state->output_format != INTEL_OUTPUT_FORMAT_YCBCR420)
> + if (crtc_state->output_format != INTEL_OUTPUT_FORMAT_YCBCR420 &&
> + !intel_dp_needs_vsc_colorimetry(conn_state->colorspace))
> return;
>
> intel_dp_setup_vsc_sdp(intel_dp, crtc_state, conn_state);
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.h
> b/drivers/gpu/drm/i915/display/intel_dp.h
Re: [PATCH 5/5] drm/qxl: use drm_gem_ttm_print_info
Acked-by: Thomas Zimmermann
Am 02.09.19 um 14:41 schrieb Gerd Hoffmann:
> Signed-off-by: Gerd Hoffmann
> ---
> drivers/gpu/drm/qxl/qxl_drv.h| 1 +
> drivers/gpu/drm/qxl/qxl_object.c | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/qxl/qxl_drv.h b/drivers/gpu/drm/qxl/qxl_drv.h
> index 9e034c5fa87d..d4051409ce64 100644
> --- a/drivers/gpu/drm/qxl/qxl_drv.h
> +++ b/drivers/gpu/drm/qxl/qxl_drv.h
> @@ -38,6 +38,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> diff --git a/drivers/gpu/drm/qxl/qxl_object.c
> b/drivers/gpu/drm/qxl/qxl_object.c
> index 29aab7b14513..c013c516f561 100644
> --- a/drivers/gpu/drm/qxl/qxl_object.c
> +++ b/drivers/gpu/drm/qxl/qxl_object.c
> @@ -86,6 +86,7 @@ static const struct drm_gem_object_funcs qxl_object_funcs =
> {
> .get_sg_table = qxl_gem_prime_get_sg_table,
> .vmap = qxl_gem_prime_vmap,
> .vunmap = qxl_gem_prime_vunmap,
> + .print_info = drm_gem_ttm_print_info,
> };
>
> int qxl_bo_create(struct qxl_device *qdev,
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnberg)
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 1/2] drm/panel: Add DT bindings for Sony ACX424AKP
On Mon, Sep 02, 2019 at 01:44:38PM +0200, Linus Walleij wrote: > On Mon, Sep 2, 2019 at 11:35 AM Thierry Reding > wrote: > > > > + dsi-command-mode: > > > + type: boolean > > > + description: > > > + If this is specified, the panel will be used in command > > > + mode instead of video mode. > > > > I'm not sure there's concensus on this one yet. I think so far the > > driver decides which mode to use the panel in. Technically this falls > > into the category of configuration, so it doesn't really belong in the > > DT. > > The way we've used DT is for a bit of both hardware description > and configuration I'd say, but I'm no authority on the subject. > > > I vaguely recall from discussions I've had on this subject that there's > > usually no reason to do video mode if you can do command mode because > > command mode is more power efficient. This was a long time ago, so I may > > be misremembering. Perhaps you have different information on this? > > No idea. I was under the impression that video mode was preferred > but I have no idea why. Hm... my recollection is that command mode is only supported on "smart" panels that have an internal framebuffer. So the commands actually instruct the panel to update their internal framebuffer, which means you can technically switch off the display engine when there are no updates. Under those circumstances I think it'd make sense to default to command mode if both the panel and the host support it and stick with video mode if for example the host can't do command mode. Or perhaps this is something that could be set from some userspace policy maker via a connector property? A compositor for instance would have a pretty good idea of what kind of activity is going on, so it could at some point decide to switch between video mode and command mode if one of them is more appropriate for the given workload. Command mode can also be used to do partial updates, if I remember correctly, which again would make it possible for a compositor to send only a subset of a screen update. Thierry signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/5] drm/qxl: use drm_gem_object_funcs callbacks
This patch seems unrelated.
Am 02.09.19 um 14:41 schrieb Gerd Hoffmann:
> Switch qxl to use drm_gem_object_funcs callbacks
> instead of drm_driver callbacks.
>
> Signed-off-by: Gerd Hoffmann
> ---
> drivers/gpu/drm/qxl/qxl_drv.c| 8
> drivers/gpu/drm/qxl/qxl_object.c | 12
> 2 files changed, 12 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
> index 2b726a51a302..996d428fa7e6 100644
> --- a/drivers/gpu/drm/qxl/qxl_drv.c
> +++ b/drivers/gpu/drm/qxl/qxl_drv.c
> @@ -258,16 +258,8 @@ static struct drm_driver qxl_driver = {
> #endif
> .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
> .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> - .gem_prime_pin = qxl_gem_prime_pin,
> - .gem_prime_unpin = qxl_gem_prime_unpin,
> - .gem_prime_get_sg_table = qxl_gem_prime_get_sg_table,
> .gem_prime_import_sg_table = qxl_gem_prime_import_sg_table,
> - .gem_prime_vmap = qxl_gem_prime_vmap,
> - .gem_prime_vunmap = qxl_gem_prime_vunmap,
> .gem_prime_mmap = qxl_gem_prime_mmap,
> - .gem_free_object_unlocked = qxl_gem_object_free,
> - .gem_open_object = qxl_gem_object_open,
> - .gem_close_object = qxl_gem_object_close,
> .fops = _fops,
> .ioctls = qxl_ioctls,
> .irq_handler = qxl_irq_handler,
> diff --git a/drivers/gpu/drm/qxl/qxl_object.c
> b/drivers/gpu/drm/qxl/qxl_object.c
> index 548dfe6f3b26..29aab7b14513 100644
> --- a/drivers/gpu/drm/qxl/qxl_object.c
> +++ b/drivers/gpu/drm/qxl/qxl_object.c
> @@ -77,6 +77,17 @@ void qxl_ttm_placement_from_domain(struct qxl_bo *qbo, u32
> domain, bool pinned)
> }
> }
>
> +static const struct drm_gem_object_funcs qxl_object_funcs = {
> + .free = qxl_gem_object_free,
> + .open = qxl_gem_object_open,
> + .close = qxl_gem_object_close,
> + .pin = qxl_gem_prime_pin,
> + .unpin = qxl_gem_prime_unpin,
> + .get_sg_table = qxl_gem_prime_get_sg_table,
> + .vmap = qxl_gem_prime_vmap,
> + .vunmap = qxl_gem_prime_vunmap,
> +};
> +
> int qxl_bo_create(struct qxl_device *qdev,
> unsigned long size, bool kernel, bool pinned, u32 domain,
> struct qxl_surface *surf,
> @@ -100,6 +111,7 @@ int qxl_bo_create(struct qxl_device *qdev,
> kfree(bo);
> return r;
> }
> + bo->tbo.base.funcs = _object_funcs;
> bo->type = domain;
> bo->pin_count = pinned ? 1 : 0;
> bo->surface_id = 0;
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnberg)
signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/5] drm/vram: add vram-mm debugfs file
Hi
Am 02.09.19 um 14:41 schrieb Gerd Hoffmann:
> Wire up drm_mm_print() for vram helpers, using a new
> debugfs file, so one can see how vram is used:
>
># cat /sys/kernel/debug/dri/0/vram-mm
>0x-0x0300: 768: used
>0x0300-0x0600: 768: used
>0x0600-0x0900: 768: used
>0x0900-0x0c00: 768: used
>0x0c00-0x4000: 13312: free
>total: 16384, used 3072 free 13312
>
> Signed-off-by: Gerd Hoffmann
> ---
> include/drm/drm_gem_vram_helper.h| 1 +
> include/drm/drm_vram_mm_helper.h | 1 +
> drivers/gpu/drm/drm_vram_mm_helper.c | 33
> 3 files changed, 35 insertions(+)
>
> diff --git a/include/drm/drm_gem_vram_helper.h
> b/include/drm/drm_gem_vram_helper.h
> index 17f160dd6e7d..d48fdf90b254 100644
> --- a/include/drm/drm_gem_vram_helper.h
> +++ b/include/drm/drm_gem_vram_helper.h
> @@ -123,6 +123,7 @@ int drm_gem_vram_driver_dumb_mmap_offset(struct drm_file
> *file,
> * drm_driver with default functions.
> */
> #define DRM_GEM_VRAM_DRIVER \
> + .debugfs_init = drm_vram_mm_debugfs_init, \
This line seems to be the reason for putting the include statement into
the header in patch [2/5]. I suggest to merge both patches into one.
> .dumb_create = drm_gem_vram_driver_dumb_create, \
> .dumb_map_offset = drm_gem_vram_driver_dumb_mmap_offset, \
> .gem_prime_mmap = drm_gem_prime_mmap
> diff --git a/include/drm/drm_vram_mm_helper.h
> b/include/drm/drm_vram_mm_helper.h
> index 2aacfb1ccfae..9e0ac9aaac7d 100644
> --- a/include/drm/drm_vram_mm_helper.h
> +++ b/include/drm/drm_vram_mm_helper.h
> @@ -60,6 +60,7 @@ static inline struct drm_vram_mm *drm_vram_mm_of_bdev(
> return container_of(bdev, struct drm_vram_mm, bdev);
> }
>
> +int drm_vram_mm_debugfs_init(struct drm_minor *minor);
I cannot find a caller of this function. Will this be called form
drm_debugfs_init()?
> int drm_vram_mm_init(struct drm_vram_mm *vmm, struct drm_device *dev,
>uint64_t vram_base, size_t vram_size,
>const struct drm_vram_mm_funcs *funcs);
> diff --git a/drivers/gpu/drm/drm_vram_mm_helper.c
> b/drivers/gpu/drm/drm_vram_mm_helper.c
> index c911781d6728..486061b83a73 100644
> --- a/drivers/gpu/drm/drm_vram_mm_helper.c
> +++ b/drivers/gpu/drm/drm_vram_mm_helper.c
> @@ -1,7 +1,9 @@
> // SPDX-License-Identifier: GPL-2.0-or-later
>
> +#include
> #include
> #include
> +#include
> #include
>
> #include
> @@ -148,6 +150,37 @@ static struct ttm_bo_driver bo_driver = {
> * struct drm_vram_mm
> */
>
> +#if defined(CONFIG_DEBUG_FS)
> +static int drm_vram_mm_debugfs(struct seq_file *m, void *data)
> +{
> + struct drm_info_node *node = (struct drm_info_node *) m->private;
> + struct drm_vram_mm *vmm = node->minor->dev->vram_mm;
> + struct drm_mm *mm = vmm->bdev.man[TTM_PL_VRAM].priv;
> + struct ttm_bo_global *glob = vmm->bdev.glob;
> + struct drm_printer p = drm_seq_file_printer(m);
> +
> + spin_lock(>lru_lock);
> + drm_mm_print(mm, );
> + spin_unlock(>lru_lock);
> + return 0;
> +}
> +
> +static struct drm_info_list drm_vram_mm_debugfs_list[] = {
Can this be made 'static const'?
> + { "vram-mm", drm_vram_mm_debugfs, 0, NULL },
> +};
> +#endif
> +
> +int drm_vram_mm_debugfs_init(struct drm_minor *minor)
Documentation is missing.
With these points addressed
Acked-by: Thomas Zimmermann
Best regards
Thomas
> +{
> +#if defined(CONFIG_DEBUG_FS)
> + drm_debugfs_create_files(drm_vram_mm_debugfs_list,
> + ARRAY_SIZE(drm_vram_mm_debugfs_list),
> + minor->debugfs_root, minor);
> +#endif
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_vram_mm_debugfs_init);
> +
> /**
> * drm_vram_mm_init() - Initialize an instance of VRAM MM.
> * @vmm: the VRAM MM instance to initialize
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnberg)
signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/panel: Add driver for Sony ACX424AKP panel
On Mon, Sep 02, 2019 at 02:57:25PM +0200, Linus Walleij wrote:
> On Mon, Sep 2, 2019 at 12:32 PM Thierry Reding
> wrote:
> > On Mon, Sep 02, 2019 at 11:06:33AM +0200, Linus Walleij wrote:
>
> > > + /*
> > > + * This depends on the clocking HS vs LP rate, this value
> > > + * is calculated as:
> > > + * vrefresh = (clock * 1000) / (htotal*vtotal)
> > > + */
> > > + .vrefresh = 816,
> >
> > That's a bit odd. My understanding is that command mode can be done in
> > continuous mode or in non-continuous mode. In continuous mode you would
> > typically achieve a similar refresh rate as in video mode. For non-
> > continuous mode you basically have a variable refresh rate.
> >
> > For continuous mode you probably want 60 Hz here and for VRR there's
> > probably no sensible value to set this to. In the latter case, I don't
> > think it makes sense to set anything arbitrary like you have above.
> > Perhaps better to just set it to 0 as a way of signalling that this is
> > actually dependent on when the display hardware sends a new frame?
>
> I guess I should set it to 60.
Not sure, perhaps someone on the list has a good idea of what vrefresh
is set for VRR monitors. I think that'd be a good example to follow.
I'm also not sure your formula to compute the refresh rate is good for
command mode. You're assuming one pixel per clock cycle. I don't think
that's accurate. Shouldn't that at least depend also on the number of
lanes and the pixel format? 816 frames per second also seems a bit much
for any type of panel.
> > Have you actually run this is command mode?
>
> Yes that is what I am primarily using.
>
> > If so, what's the actual
> > refresh rate? Do you do on-demand updates or do you run in continuous
> > mode?
>
> I run continuous mode, so the refresh rate is essentially dependent on
> the HS frequency that the host uses. For command mode we use as
> fast as it can go which is 420MHz, backwards calculated to ~816Hz
> updates.
>
> I took some data from the system when running:
> 175608 "vblank" interrupts in 25 minutes, yielding
> 175608/(25*60) ~= 117 Hz so I guess that is the pace the
> hardware actually recieves it and triggers new updates.
That's a factor of almost 8, so I think there's something really wrong
in your refresh rate calculation, or you have an issue somewhere in the
code that computes the pixel clock and byte clock from the mode's clock
rate.
>
> > > + ret = mipi_dsi_dcs_read(dsi, 0xda, , len);
> > > + if (ret < 0) {
> > > + DRM_DEV_ERROR(acx->dev, "could not read device ID byte
> > > 1\n");
> > > + return ret;
> > > + }
> > > + ret = mipi_dsi_dcs_read(dsi, 0xdb, , len);
> > > + if (ret < 0) {
> > > + DRM_DEV_ERROR(acx->dev, "could not read device ID byte
> > > 2\n");
> > > + return ret;
> > > + }
> > > + ret = mipi_dsi_dcs_read(dsi, 0xdc, , len);
> > > + if (ret < 0) {
> > > + DRM_DEV_ERROR(acx->dev, "could not read device ID byte
> > > 3\n");
> > > + return ret;
> > > + }
> > > +
> > > + val = (id3 << 8) | id2;
> >
> > Don't you want to OR in id1 here as well? Seems a bit odd to read it but
> > then not use it.
>
> The way I have understood these "MTP IDs" is that the first byte
> should just be checked for not being 0 so I will add a check like that.
>
> The only other DSI panel doing this is panel-samsung-s6e8aa0.c function
> s6e8aa0_read_mtp_id() which also reads three bytes and ignores the
> first byte, also the second byte being version and the third ID matches
> the data this display returns.
>
> I'll try to make it a bit clearer and inspect the individual bytes since they
> seem to have individual meanings.
I vaguely recall MTP IDs. It's a little funny that both S6E8AA0 and this
new driver seem to be reading the same type of ID, but using different
DCS register offsets. I had hoped that these would be somewhat
standardized. Or perhaps these are standardized as part of a larger type
of descriptor to which an offset is read from somewhere else?
> > > + struct device *dev = >dev;
> > > + struct acx424akp *acx;
> > > + int ret;
> > > + int i;
> >
> > unsigned int?
>
> Just following the common idiom for integer enumerator i to be a
> plain int but sure, if you prefer :)
The common idiom is wrong. =)
Jokes aside, why worry about the sign if you know up front that your
values are never going to be negative? If you consistently use unsigned
types for values that can never be negative, the compiler will even be
able to point out inconsistent usage, etc.
Thierry
> > > + /* Read device ID */
> > > + i = 0;
> > > + do {
> > > + ret = acx424akp_read_id(acx);
> > > + if (ret)
> > > + continue;
> > > + } while (ret && i++ < 5);
> >
> > Seems rather redundant to have both an "if (ret) continue;" and the ret
> > check in the while's condition. A more idiomatic way
[PATCH v2] drm: Add high-precision time to vblank trace event
Store the timestamp of the current vblank in the new field 'time' of the
vblank trace event. If the timestamp is calculated by a driver that
supports high-precision vblank timing, set the field 'high-prec' to
'true'.
User space can now access actual hardware vblank times via the tracing
infrastructure. Tracing applications (such as GPUVis, see [0] for
related discussion), can use the newly added information to conduct a
more accurate analysis of display timing.
v2 Fix author name (missing last name)
[0] https://github.com/mikesart/gpuvis/issues/30
Reviewed-by: Daniel Vetter
Signed-off-by: Heinrich Fink
---
drivers/gpu/drm/drm_trace.h | 14 ++
drivers/gpu/drm/drm_vblank.c | 3 ++-
2 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_trace.h b/drivers/gpu/drm/drm_trace.h
index 471eb927474b..11c6dd577e8e 100644
--- a/drivers/gpu/drm/drm_trace.h
+++ b/drivers/gpu/drm/drm_trace.h
@@ -13,17 +13,23 @@ struct drm_file;
#define TRACE_INCLUDE_FILE drm_trace
TRACE_EVENT(drm_vblank_event,
- TP_PROTO(int crtc, unsigned int seq),
- TP_ARGS(crtc, seq),
+ TP_PROTO(int crtc, unsigned int seq, ktime_t time, bool high_prec),
+ TP_ARGS(crtc, seq, time, high_prec),
TP_STRUCT__entry(
__field(int, crtc)
__field(unsigned int, seq)
+ __field(ktime_t, time)
+ __field(bool, high_prec)
),
TP_fast_assign(
__entry->crtc = crtc;
__entry->seq = seq;
- ),
- TP_printk("crtc=%d, seq=%u", __entry->crtc, __entry->seq)
+ __entry->time = time;
+ __entry->high_prec = high_prec;
+ ),
+ TP_printk("crtc=%d, seq=%u, time=%lld, high-prec=%s",
+ __entry->crtc, __entry->seq, __entry->time,
+ __entry->high_prec ? "true" : "false")
);
TRACE_EVENT(drm_vblank_event_queued,
diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index fd1fbc77871f..c99feda25dea 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -1731,7 +1731,8 @@ static void drm_handle_vblank_events(struct drm_device
*dev, unsigned int pipe)
send_vblank_event(dev, e, seq, now);
}
- trace_drm_vblank_event(pipe, seq);
+ trace_drm_vblank_event(pipe, seq, now,
+ dev->driver->get_vblank_timestamp != NULL);
}
/**
--
2.23.0.rc1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Add high-precision time to vblank trace event
Thanks for the review, Daniel. I noticed that my last name was missing in the initial revision (my git config was messed up). I am sending v2 of this patch to fix this, including your r/b tag. Cheers, Heinrich ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/5] drm/vram: use drm_gem_ttm_print_info
Hi
Am 02.09.19 um 14:41 schrieb Gerd Hoffmann:
> Signed-off-by: Gerd Hoffmann
> ---
> include/drm/drm_gem_vram_helper.h | 1 +
> drivers/gpu/drm/drm_gem_vram_helper.c | 3 ++-
> drivers/gpu/drm/Kconfig | 1 +
> 3 files changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/include/drm/drm_gem_vram_helper.h
> b/include/drm/drm_gem_vram_helper.h
> index ac217d768456..17f160dd6e7d 100644
> --- a/include/drm/drm_gem_vram_helper.h
> +++ b/include/drm/drm_gem_vram_helper.h
> @@ -4,6 +4,7 @@
> #define DRM_GEM_VRAM_HELPER_H
>
> #include
> +#include
Why is this include statement in the header file instead of the source file?
> #include
> #include
> #include /* for container_of() */
> diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
> b/drivers/gpu/drm/drm_gem_vram_helper.c
> index fd751078bae1..b4929e1fb190 100644
> --- a/drivers/gpu/drm/drm_gem_vram_helper.c
> +++ b/drivers/gpu/drm/drm_gem_vram_helper.c
> @@ -633,5 +633,6 @@ static const struct drm_gem_object_funcs
> drm_gem_vram_object_funcs = {
> .pin= drm_gem_vram_object_pin,
> .unpin = drm_gem_vram_object_unpin,
> .vmap = drm_gem_vram_object_vmap,
> - .vunmap = drm_gem_vram_object_vunmap
> + .vunmap = drm_gem_vram_object_vunmap,
> + .print_info = drm_gem_ttm_print_info,
> };
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index f7b25519f95c..1be8ad30d8fe 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -169,6 +169,7 @@ config DRM_VRAM_HELPER
> tristate
> depends on DRM
> select DRM_TTM
> + select DRM_TTM_HELPER
I thought that VRAM helpers already depend on TTM helpers. If so, this
line should rather be a separate patch with a Fixes tag to the patch
that introduced the dependency.
With these points addressed:
Acked-by: Thomas Zimmermann
Best regards
Thomas
> help
> Helpers for VRAM memory management
>
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnberg)
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 1/5] drm/ttm: add drm_gem_ttm_print_info()
Hi
Acked-by: Thomas Zimmermann
But please see below.
Am 02.09.19 um 14:41 schrieb Gerd Hoffmann:
> Now with ttm_buffer_object being a subclass of drm_gem_object we can
> easily lookup ttm_buffer_object for a given drm_gem_object, which in
> turm allows to create common helper functions.
s/trum/trun
>
> This patch starts off with a drm_gem_ttm_print_info() helper function
> which prints adds some ttm specific lines to the debug output.
>
> Signed-off-by: Gerd Hoffmann
> ---
> include/drm/drm_gem_ttm_helper.h | 19
> drivers/gpu/drm/drm_gem_ttm_helper.c | 67
> Documentation/gpu/drm-mm.rst | 12 +
> drivers/gpu/drm/Kconfig | 7 +++
> drivers/gpu/drm/Makefile | 3 ++
> 5 files changed, 108 insertions(+)
> create mode 100644 include/drm/drm_gem_ttm_helper.h
> create mode 100644 drivers/gpu/drm/drm_gem_ttm_helper.c
>
> diff --git a/include/drm/drm_gem_ttm_helper.h
> b/include/drm/drm_gem_ttm_helper.h
> new file mode 100644
> index ..6268f89c5a48
> --- /dev/null
> +++ b/include/drm/drm_gem_ttm_helper.h
> @@ -0,0 +1,19 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
> +
> +#ifndef DRM_GEM_TTM_HELPER_H
> +#define DRM_GEM_TTM_HELPER_H
> +
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#define drm_gem_ttm_of_gem(gem_obj) \
> + container_of(gem_obj, struct ttm_buffer_object, base)
> +
> +void drm_gem_ttm_print_info(struct drm_printer *p, unsigned int indent,
> + const struct drm_gem_object *gem);
> +
> +#endif
> diff --git a/drivers/gpu/drm/drm_gem_ttm_helper.c
> b/drivers/gpu/drm/drm_gem_ttm_helper.c
> new file mode 100644
> index ..cd6ac2cc8fdd
> --- /dev/null
> +++ b/drivers/gpu/drm/drm_gem_ttm_helper.c
> @@ -0,0 +1,67 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +
> +#include
> +
> +#include
> +
> +/**
> + * DOC: overview
> + *
> + * This library provides helper functions for gem objects backed by
> + * ttm.
> + */
> +
> +/**
> + * drm_gem_ttm_print_info() - Print _buffer_object info for debugfs
> + * @p: DRM printer
> + * @indent: Tab indentation level
> + * @gem: GEM object
> + *
> + * This function can be used as the _driver->gem_print_info callback.
> + */
> +void drm_gem_ttm_print_info(struct drm_printer *p, unsigned int indent,
> + const struct drm_gem_object *gem)
> +{
> + static const char *plname[] = {
The array and the strings should be declared const. IIRC something like
static const char * const plname[] = {
> + [ TTM_PL_SYSTEM ] = "system",
> + [ TTM_PL_TT ] = "tt",
> + [ TTM_PL_VRAM ] = "vram",
> + [ TTM_PL_PRIV ] = "priv",
> +
This 'gap' in the array seems to be a problem for drivers that use these
bits. Could the print logic be moved into s separate function that also
takes the array as an argument?
Best regards
Thomas
> + [ 16 ]= "cached",
> + [ 17 ]= "uncached",
> + [ 18 ]= "wc",
> + [ 19 ]= "contig",
> +
> + [ 21 ]= "pinned", /* NO_EVICT */
> + [ 22 ]= "topdown",
> + };
> + const struct ttm_buffer_object *bo = drm_gem_ttm_of_gem(gem);
> + bool first = true;
> + unsigned int i;
> +
> + for (i = 0; i < ARRAY_SIZE(plname); i++) {
> + if (!(bo->mem.placement & (1 << i)))
> + continue;
> + if (!plname[i])
> + continue;
> + if (first) {
> + first = false;
> + drm_printf_indent(p, indent, "placement=%s", plname[i]);
> + } else
> + drm_printf(p, ",%s", plname[i]);
> + }
> + if (!first)
> + drm_printf(p, "\n");
> +
> + if (bo->mem.bus.is_iomem) {
> + drm_printf_indent(p, indent, "bus.base=%lx\n",
> + (unsigned long)bo->mem.bus.base);
> + drm_printf_indent(p, indent, "bus.offset=%lx\n",
> + (unsigned long)bo->mem.bus.offset);
> + }
> +}
> +EXPORT_SYMBOL(drm_gem_ttm_print_info);
> +
> +MODULE_DESCRIPTION("DRM gem ttm helpers");
> +MODULE_LICENSE("GPL");
> diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
> index b664f054c259..a70a1d9f30ec 100644
> --- a/Documentation/gpu/drm-mm.rst
> +++ b/Documentation/gpu/drm-mm.rst
> @@ -412,6 +412,18 @@ VRAM MM Helper Functions Reference
> .. kernel-doc:: drivers/gpu/drm/drm_vram_mm_helper.c
> :export:
>
> +GEM TTM Helper Functions Reference
> +---
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_gem_ttm_helper.c
> + :doc: overview
> +
> +.. kernel-doc:: include/drm/drm_gem_ttm_helper.h
> + :internal:
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_gem_ttm_helper.c
> + :export:
> +
> VMA Offset Manager
>
Adreno crash on i.MX53 running 5.3-rc6
Hi, I am getting the following crash when booting the adreno driver on i.MX53 running a 5.3-rc6 kernel. Such error does not happen with 5.2 though. Before I start running a bisect, I am wondering if anyone has any ideas about this issue. Thanks, Fabio Estevam [2.083249] 8<--- cut here --- [2.086460] Unable to handle kernel paging request at virtual address 50001000 [2.094174] pgd = (ptrval) [2.096911] [50001000] *pgd= [2.100606] Internal error: Oops: 805 [#1] SMP ARM [2.105412] Modules linked in: [2.108487] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.3.0-rc6-00271-g9f159ae07f07 #4 [2.116411] Hardware name: Freescale i.MX53 (Device Tree Support) [2.122538] PC is at v7_dma_clean_range+0x20/0x38 [2.127254] LR is at __dma_page_cpu_to_dev+0x28/0x90 [2.132226] pc : []lr : []psr: 2013 [2.138500] sp : d80b5a88 ip : de96c000 fp : d840ce6c [2.143732] r10: r9 : 0001 r8 : d843e010 [2.148964] r7 : r6 : 8000 r5 : ddb6c000 r4 : [2.155500] r3 : 003f r2 : 0040 r1 : 50008000 r0 : 50001000 [2.162037] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none [2.169180] Control: 10c5387d Table: 70004019 DAC: 0051 [2.174934] Process swapper/0 (pid: 1, stack limit = 0x(ptrval)) [2.180949] Stack: (0xd80b5a88 to 0xd80b6000) [2.185319] 5a80: c011c7bc d8491780 d840ce6c d849b380 c011822c [2.193509] 5aa0: c0d01a18 c0118abc c0118a78 d84a0200 0008 c1308908 d838e800 d849a4a8 [2.201697] 5ac0: d8491780 c06699b4 d8491600 d80b5b20 d84a0200 [2.209886] 5ae0: d8491780 d8491600 d80b5b20 d8491600 d849a4a8 d84a0200 0003 d84a0358 [2.218077] 5b00: c1308908 d8491600 d849a4a8 d8491780 d840ce6c c066a55c c1308908 c066a104 [2.226266] 5b20: 01001000 d84a0200 10700ac6 d849a480 d84a0200 d8491600 [2.234455] 5b40: e0845000 c1308908 c066a72c d849a480 d840ce6c d840ce00 c1308908 [2.242643] 5b60: c066b584 d849a488 d849a4a8 c1308908 d840ce6c c066ff40 [2.250832] 5b80: d849a488 d849a4a8 c1308908 d81b4000 e0845000 [2.259021] 5ba0: d838e800 c1308908 d8491600 10700ac6 d80b5bc8 d840ce00 d840ce6c 0001 [2.267210] 5bc0: e0845000 d838e800 c066ece4 0100 10ff [2.275399] 5be0: c1308908 0001 d81b4000 0100 0001 10700ac6 [2.283587] 5c00: c0d6d564 d840ce00 d81b4010 0001 d81b4000 c0d6d564 c1308908 d80b5c48 [2.291777] 5c20: d838e800 c061f9cc c1029dec d80b5c48 d838e800 c13e8788 [2.299965] 5c40: c1308928 c102a234 0100 10ff [2.308154] 5c60: 0001 a013 10700ac6 c13b7658 d840ce00 d838e800 d81b4000 [2.316343] 5c80: d840ce00 c1308908 0002 d838f800 c0620514 0001 10700ac6 [2.324531] 5ca0: d8496440 d81b4010 c1aa1c00 d838e800 c061e070 [2.332720] 5cc0: c0d6c534 df56cf34 00c8 10700ac6 d81b4010 [2.340909] 5ce0: d8496440 d838e800 c103acd0 d8496280 c1380488 c06a3e10 [2.349097] 5d00: d838f800 d838e800 d843e010 d8496440 c1308908 [2.357286] 5d20: d83f9640 c1380488 c0668554 0006 0007 c13804d4 d83f9640 [2.365475] 5d40: c1380488 c017ec18 d80c c0c43e40 d843e010 d8496440 0001 c0182a94 [2.373665] 5d60: 6013 10700ac6 d843e010 d8496280 d8496400 0018 d8496440 0001 [2.381854] 5d80: c13804d4 d83f9640 c1380488 c06a4280 c1380488 c0d764f8 d8496440 [2.390044] 5da0: c1380488 d843e010 c0d764f8 c1308908 c13ef300 c06a44f0 [2.398232] 5dc0: c0d8a0dc dffcc6f0 d843e010 dffcc6f0 d843e010 c06680b8 [2.406421] 5de0: d84988c0 d83f9640 d84988c0 d84989a0 d8498230 10700ac6 0001 d843e010 [2.414610] 5e00: c137eec0 c137eec0 c13ef300 c06ac1a0 [2.422799] 5e20: d843e010 c1aa40dc c1aa40e0 c137eec0 c06aa014 d843e010 c137eec0 [2.430988] 5e40: c137eec0 c1308908 c13e9880 c13e85d4 c06aa368 c1308908 c13e9880 [2.439178] 5e60: c13e85d4 d843e010 c137eec0 c1308908 c13e9880 c13e85d4 c06aa618 [2.447367] 5e80: c137eec0 d843e010 c06aa6a4 c137eec0 c06aa620 c06a844c [2.46] 5ea0: d80888d4 d80888a4 d84914d0 10700ac6 d80888d4 c137eec0 d8494f00 c1380d28 [2.463745] 5ec0: c06a946c c105f3d4 c1308908 c137eec0 c1308908 [2.471934] 5ee0: c125fdd0 c06ab304 c1308928 c1308908 c0103178 0109 [2.480123] 5f00: dc6e dc00 c1126860 0109 0109 c014dc88 c11253ac c10607a0 [2.488312] 5f20: 0006 0006 c12adeec dc6e 10700ac6 [2.496501] 5f40: c1308f18 10700ac6 0007 c13e9880 c13ef300 c1294850
[Bug 110659] pageflipping seems to cause jittering on mouse input when running Hitman 2 in Wine/DXVK with amdgpu.dc=1
https://bugs.freedesktop.org/show_bug.cgi?id=110659 --- Comment #62 from tempel.jul...@gmail.com --- I could reproduce the issue on a system with a Radeon RX 5700 XT Navi 10 GPU + drm-next kernel in Hitman 2. Really devastating. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 1/2] dt-bindings: display/bridge: Add binding for NWL mipi dsi host controller
On Fri, 30 Aug 2019 14:58:21 +0200, =?UTF-8?q?Guido=20G=C3=BCnther?= wrote: > The Northwest Logic MIPI DSI IP core can be found in NXPs i.MX8 SoCs. > > Signed-off-by: Guido Günther > Tested-by: Robert Chiras > --- > .../bindings/display/bridge/nwl-dsi.yaml | 176 ++ > 1 file changed, 176 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5, 05/32] dt-bindings: mediatek: add mutex description for mt8183 display
On Thu, 29 Aug 2019 22:50:27 +0800, wrote: > From: Yongqiang Niu > > This patch add mutex description for mt8183 display > > Signed-off-by: Yongqiang Niu > --- > Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt | 1 + > 1 file changed, 1 insertion(+) > Acked-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH] drm: kirin: Fix dsi probe/attach logic
On 30.08.2019 19:00, Rob Clark wrote:
> On Thu, Aug 29, 2019 at 11:52 PM Andrzej Hajda wrote:
>> On 29.08.2019 19:39, Rob Clark wrote:
>>> On Wed, Aug 28, 2019 at 11:06 PM John Stultz wrote:
Since commit 83f35bc3a852 ("drm/bridge: adv7511: Attach to DSI
host at probe time") landed in -next the HiKey board would fail
to boot, looping:
>>> No, please revert 83f35bc3a852.. that is going in the *complete* wrong
>>> direction. We actually should be moving panels to not require dsi
>>> host until attach time, similar to how bridges work, not the other way
>>> around.
>>
>> Devices of panels and bridges controlled via DSI will not appear at all
>> if DSI host is not created.
>>
>> So this is the only direction!!!
>>
> I disagree, there is really no harm in the bridge probing if there is no dsi.
>
> Furthermore, it seems that this change broke a few other drivers.
If the bridge/panel is controlled via dsi, it will not be probed at all
if DSI host/bus is not created, so it will not work at all. Upstream
device will wait forever for downstream drm_(panel|bridge).
So IMO we just do not have choice here.
If you know better alternative let us know, otherwise we should proceed
with "drm: kirin: Fix dsi probe/attach logic" patch.
>
>>> The problem is that, when dealing with bootloader enabled display, we
>>> need to be really careful not to touch the hardware until the display
>>> driver knows the bridge/panel is present. If the bridge/panel probes
>>> after the display driver, we could end up killing scanout
>>> (efifb/simplefb).. if the bridge/panel is missing some dependency and
>>> never probes, it is rather unpleasant to be stuck trying to debug what
>>> went wrong with no display.
>>
>> It has nothing to do with touching hardware, you can always (I hope)
>> postpone it till all components are present.
> Unfortunately this is harder than it sounds, since we need to read hw
> revision registers for display and dsi blocks to know which hw
> revision we are dealing with.
>
> (Also, we need to avoid
> drm_fb_helper_remove_conflicting_framebuffers() until we know we are
> ready to go.)
>
> We could possibly put more information in dt. But the less we depend
> on dt, the easier time we'll have adding support for ACPI boot on the
> windows arm laptops.
>
>> But it is just requirement of device/driver model in Linux Kernel.
> yes and no.. the way the existing bridges work with a bridge->attach()
> step seems fairly pragmatic to me.
>
>>> Sorry I didn't notice that adv7511 patch before it landed, but the
>>> right thing to do now is to revert it.
>>
>> The 1st version of the patch was posted at the end of April and final
>> version was queued 1st July, so it was quite long time for discussions
>> and tests.
> sorry I didn't notice the patch sooner, most of my bandwidth goes to mesa.
>
>> Reverting it now seems quite late, especially if the patch does right
>> thing and there is already proper fix for one encoder (kirin), moreover
>> revert will break another platforms.
> kirin isn't the only other user of adv75xx.. at least it is my
> understanding that this broke db410c as well.
>
>> Of course it seems you have different opinion what is the right thing in
>> this case, so if you convince us that your approach is better one can
>> revert the patch.
> I guess my strongest / most immediate opinion is to not break other
> existing adv75xx bridge users.
It is pity that breakage happened, and next time we should be more
strict about testing other platforms, before patch acceptance.
But reverting it now will break also platform which depend on it.
Anyway the old order was incorrect and prevented other users from adv*
driver usage, so it should be fixed anyway.
> Beyond that, I found doing mipi_dsi_attach() in bridge->attach() was
> quite convenient to get display handover from efifb work. And that
> was (previously) the way most of the bridges worked.
>
> But maybe there is another way.. perhaps somehow the bridges/panels
> could be added as sub-components using the component framework, to
> prevent the toplevel drm device from probing until they are ready?
If you mean 'probe' as in initialization from component_master::bind
callback with this patch it still works, DSI-HOST calls component_add
after drm_bridge is found.
> We'd still have the problem that the dsi component wants to be able to
> read hw revision before registering dsi host.. but I suppose if CCF
> exported a way that we could query whether the interface clk was
> already enabled, we could have the clk enable/disable cycle that would
> break efifb.
I am not familiar with efifb, if you describe the issue you have in more
detail we can try to find some solution together.
Regards
Andrzej
>
> BR,
> -R
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm/edid: no CEA extension is not an error
On Mon, Sep 02, 2019 at 01:55:21PM +0200, Jean Delvare wrote:
> On Mon, 2 Sep 2019 14:46:51 +0300, Ville Syrjälä wrote:
> > On Fri, Aug 30, 2019 at 06:16:52PM +0200, Jean Delvare wrote:
> > > It is fine for displays without audio functionality to not implement
> > > CEA extension in their EDID. Do not return an error in that case,
> > > instead return 0 as if there was a CEA extension with no audio or
> > > speaker block.
> > >
> > > This fixes half of bug fdo#107825:
> > > https://bugs.freedesktop.org/show_bug.cgi?id=107825
> > >
> > > Signed-off-by: Jean Delvare
> > > Cc: Maarten Lankhorst
> > > Cc: Maxime Ripard
> > > Cc: Sean Paul
> > > Cc: David Airlie
> > > Cc: Daniel Vetter
> > > ---
> > > drivers/gpu/drm/drm_edid.c |4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > --- linux-5.2.orig/drivers/gpu/drm/drm_edid.c 2019-08-30
> > > 17:57:38.10995 +0200
> > > +++ linux-5.2/drivers/gpu/drm/drm_edid.c 2019-08-30 18:04:36.840333834
> > > +0200
> > > @@ -4130,7 +4130,7 @@ int drm_edid_to_sad(struct edid *edid, s
> > > cea = drm_find_cea_extension(edid);
> > > if (!cea) {
> > > DRM_DEBUG_KMS("SAD: no CEA Extension found\n");
> > > - return -ENOENT;
> > > + return 0;
> > > }
> >
> > Seems reasonable. Maybe the cea_revision<3 branches should alse return 0?
>
> I wasn't sure about that one, as I'm not familiar with this CEA
> extension thing.
>
> If revision < 3 means the data is invalid then returning an error is
> fine. If on the other hand revision < 3 simply means that the block
> types we are looking for were not defined back then yes returning 0
> instead would be better.
That is indeed the case. A quick read through the code showed that
we're not 100% consistent in checing for that though. I just send
a few patches to fix that up.
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/edid: Don't look for CEA data blocks in CEA ext block rev < 3
From: Ville Syrjälä
CEA ext block revisions 1 and 2 do not contain the data block
collection. Instead that section of the extension block is
marked as reserved for 8 byte timing descriptors. Revision 3
changed it to contain the CEA data block collection instead.
Most places that iterate the data blocks already check for
revision >= 3, but drm_detect_hdmi_monitor() and
drm_detect_monitor_audio() do not. So in theory when encountering
rev 1 or 2 CEA extension block they could end up misinterpreting
whatever data is in the reserved section as CEA data blocks.
Let's have cea_db_offsets() do the revision check so that the
callers don't even have worry about it.
Cc: Jean Delvare
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 82a4ceed3fcf..7b3072fc550b 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3690,6 +3690,9 @@ cea_revision(const u8 *cea)
static int
cea_db_offsets(const u8 *cea, int *start, int *end)
{
+ if (cea_revision(cea) < 3)
+ return -ENOTSUPP;
+
/* DisplayID CTA extension blocks and top-level CEA EDID
* block header definitions differ in the following bytes:
* 1) Byte 2 of the header specifies length differently,
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/edid: Have cea_db_offsets() zero start/end when the data block collection isn't found
From: Ville Syrjälä
Let's make cea_db_offsets() a bit more convenient to use by
setting the start/end offsets to zero whenever the data block
collection isn't present. This makes it safe for the caller
to blindly iterate the data blocks even if there are none.
Cc: Jean Delvare
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 7b3072fc550b..e5905dc764c1 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3690,6 +3690,9 @@ cea_revision(const u8 *cea)
static int
cea_db_offsets(const u8 *cea, int *start, int *end)
{
+ *start = 0;
+ *end = 0;
+
if (cea_revision(cea) < 3)
return -ENOTSUPP;
@@ -4116,10 +4119,7 @@ static void drm_edid_to_eld(struct drm_connector
*connector, struct edid *edid)
if (cea_revision(cea) >= 3) {
int i, start, end;
- if (cea_db_offsets(cea, , )) {
- start = 0;
- end = 0;
- }
+ cea_db_offsets(cea, , );
for_each_cea_db(cea, i, start, end) {
db = [i];
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/sti: Include the right header
Le ven. 23 août 2019 à 09:14, Linus Walleij a écrit : > > The sti_hdmi.c file include despite not even > using any GPIOs. > > What it does use is devm_ioremap_nocache() which comes from > implicitly by including that header. > > Fix this up by including the right header instead. Applied on drm-misc-next, Thanks Benjamin > > Cc: Benjamin Gaignard > Cc: Vincent Abriou > Signed-off-by: Linus Walleij > --- > drivers/gpu/drm/sti/sti_hdmi.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c > index f03d617edc4c..4f1aaf222cb0 100644 > --- a/drivers/gpu/drm/sti/sti_hdmi.c > +++ b/drivers/gpu/drm/sti/sti_hdmi.c > @@ -9,7 +9,7 @@ > #include > #include > #include > -#include > +#include > #include > #include > > -- > 2.21.0 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 6/9] drm: sti: use cec_notifier_conn_(un)register
Le jeu. 22 août 2019 à 10:11, Hans Verkuil a écrit :
>
> Adding Benjamin Gaignard.
>
> Benjamin, can you take a look at this and Ack it (or merge it if you prefer)
> and
> ideally test it as well. This is the only patch in this series that I could
> not
> test since I don't have any hardware.
Looks good for me.
Applied on drm-misc-next,
Thanks,
Benjamin
>
> Regards,
>
> Hans
>
> On 8/14/19 12:45 PM, Dariusz Marcinkiewicz wrote:
> > Use the new cec_notifier_conn_(un)register() functions to
> > (un)register the notifier for the HDMI connector, and fill
> > in the cec_connector_info.
> >
> > Changes since v2:
> > Don't invalidate physical address before unregistering the
> > notifier.
> >
> > Signed-off-by: Dariusz Marcinkiewicz
> > ---
> > drivers/gpu/drm/sti/sti_hdmi.c | 19 ---
> > 1 file changed, 12 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c
> > index 9862c322f0c4a..bd15902b825ad 100644
> > --- a/drivers/gpu/drm/sti/sti_hdmi.c
> > +++ b/drivers/gpu/drm/sti/sti_hdmi.c
> > @@ -1256,6 +1256,7 @@ static int sti_hdmi_bind(struct device *dev, struct
> > device *master, void *data)
> > struct drm_device *drm_dev = data;
> > struct drm_encoder *encoder;
> > struct sti_hdmi_connector *connector;
> > + struct cec_connector_info conn_info;
> > struct drm_connector *drm_connector;
> > struct drm_bridge *bridge;
> > int err;
> > @@ -1318,6 +1319,14 @@ static int sti_hdmi_bind(struct device *dev, struct
> > device *master, void *data)
> > goto err_sysfs;
> > }
> >
> > + cec_fill_conn_info_from_drm(_info, drm_connector);
> > + hdmi->notifier = cec_notifier_conn_register(>dev, NULL,
> > + _info);
> > + if (!hdmi->notifier) {
> > + hdmi->drm_connector = NULL;
> > + return -ENOMEM;
> > + }
> > +
> > /* Enable default interrupts */
> > hdmi_write(hdmi, HDMI_DEFAULT_INT, HDMI_INT_EN);
> >
> > @@ -1331,6 +1340,9 @@ static int sti_hdmi_bind(struct device *dev, struct
> > device *master, void *data)
> > static void sti_hdmi_unbind(struct device *dev,
> > struct device *master, void *data)
> > {
> > + struct sti_hdmi *hdmi = dev_get_drvdata(dev);
> > +
> > + cec_notifier_conn_unregister(hdmi->notifier);
> > }
> >
> > static const struct component_ops sti_hdmi_ops = {
> > @@ -1436,10 +1448,6 @@ static int sti_hdmi_probe(struct platform_device
> > *pdev)
> > goto release_adapter;
> > }
> >
> > - hdmi->notifier = cec_notifier_get(>dev);
> > - if (!hdmi->notifier)
> > - goto release_adapter;
> > -
> > hdmi->reset = devm_reset_control_get(dev, "hdmi");
> > /* Take hdmi out of reset */
> > if (!IS_ERR(hdmi->reset))
> > @@ -1459,14 +1467,11 @@ static int sti_hdmi_remove(struct platform_device
> > *pdev)
> > {
> > struct sti_hdmi *hdmi = dev_get_drvdata(>dev);
> >
> > - cec_notifier_set_phys_addr(hdmi->notifier, CEC_PHYS_ADDR_INVALID);
> > -
> > i2c_put_adapter(hdmi->ddc_adapt);
> > if (hdmi->audio_pdev)
> > platform_device_unregister(hdmi->audio_pdev);
> > component_del(>dev, _hdmi_ops);
> >
> > - cec_notifier_put(hdmi->notifier);
> > return 0;
> > }
> >
> >
>
Re: [PATCH 5/6 v2] drm/msm/hdmi: Bring up HDMI connector OFF
On Sun, Sep 1, 2019 at 6:28 PM Rob Clark wrote: > I'm picking up the earlier patches in this series.. Thanks a lot :) > although I won't > have a good way to test on devices which use the hdmi block for a few > weeks (when I complete my move, and get back a bunch of boards that > are in boxes right now) so I'm going to wait on the last two I think. That's fine. It is just occasional drive-by coding anyway. Yours, Linus Walleij ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/panel: Add driver for Sony ACX424AKP panel
On Mon, Sep 2, 2019 at 12:32 PM Thierry Reding wrote:
> On Mon, Sep 02, 2019 at 11:06:33AM +0200, Linus Walleij wrote:
> > + /*
> > + * This depends on the clocking HS vs LP rate, this value
> > + * is calculated as:
> > + * vrefresh = (clock * 1000) / (htotal*vtotal)
> > + */
> > + .vrefresh = 816,
>
> That's a bit odd. My understanding is that command mode can be done in
> continuous mode or in non-continuous mode. In continuous mode you would
> typically achieve a similar refresh rate as in video mode. For non-
> continuous mode you basically have a variable refresh rate.
>
> For continuous mode you probably want 60 Hz here and for VRR there's
> probably no sensible value to set this to. In the latter case, I don't
> think it makes sense to set anything arbitrary like you have above.
> Perhaps better to just set it to 0 as a way of signalling that this is
> actually dependent on when the display hardware sends a new frame?
I guess I should set it to 60.
> Have you actually run this is command mode?
Yes that is what I am primarily using.
> If so, what's the actual
> refresh rate? Do you do on-demand updates or do you run in continuous
> mode?
I run continuous mode, so the refresh rate is essentially dependent on
the HS frequency that the host uses. For command mode we use as
fast as it can go which is 420MHz, backwards calculated to ~816Hz
updates.
I took some data from the system when running:
175608 "vblank" interrupts in 25 minutes, yielding
175608/(25*60) ~= 117 Hz so I guess that is the pace the
hardware actually recieves it and triggers new updates.
> > + ret = mipi_dsi_dcs_read(dsi, 0xda, , len);
> > + if (ret < 0) {
> > + DRM_DEV_ERROR(acx->dev, "could not read device ID byte 1\n");
> > + return ret;
> > + }
> > + ret = mipi_dsi_dcs_read(dsi, 0xdb, , len);
> > + if (ret < 0) {
> > + DRM_DEV_ERROR(acx->dev, "could not read device ID byte 2\n");
> > + return ret;
> > + }
> > + ret = mipi_dsi_dcs_read(dsi, 0xdc, , len);
> > + if (ret < 0) {
> > + DRM_DEV_ERROR(acx->dev, "could not read device ID byte 3\n");
> > + return ret;
> > + }
> > +
> > + val = (id3 << 8) | id2;
>
> Don't you want to OR in id1 here as well? Seems a bit odd to read it but
> then not use it.
The way I have understood these "MTP IDs" is that the first byte
should just be checked for not being 0 so I will add a check like that.
The only other DSI panel doing this is panel-samsung-s6e8aa0.c function
s6e8aa0_read_mtp_id() which also reads three bytes and ignores the
first byte, also the second byte being version and the third ID matches
the data this display returns.
I'll try to make it a bit clearer and inspect the individual bytes since they
seem to have individual meanings.
> > + struct device *dev = >dev;
> > + struct acx424akp *acx;
> > + int ret;
> > + int i;
>
> unsigned int?
Just following the common idiom for integer enumerator i to be a
plain int but sure, if you prefer :)
> > + /* Read device ID */
> > + i = 0;
> > + do {
> > + ret = acx424akp_read_id(acx);
> > + if (ret)
> > + continue;
> > + } while (ret && i++ < 5);
>
> Seems rather redundant to have both an "if (ret) continue;" and the ret
> check in the while's condition. A more idiomatic way to write this would
> be:
>
> for (i = 0; i < 5; i++) {
> ret = acx424akp_read_id(acx);
> if (!ret)
> break;
> }
OK! I fix.
Yours,
Linus Walleij
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 7/7] drm/omap: hdmi5: automatically choose limited/full range output
Currently the HDMI driver uses always limited range RGB output. This
patch improves the behavior by using limited range only if the output is
identified as a HDMI display, and VIC > 1.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/dss/hdmi5_core.c | 121 ---
1 file changed, 65 insertions(+), 56 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi5_core.c
b/drivers/gpu/drm/omapdrm/dss/hdmi5_core.c
index 4c588ec7634a..96f5cd17768c 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi5_core.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi5_core.c
@@ -23,18 +23,6 @@
#include "hdmi5_core.h"
-/* only 24 bit color depth used for now */
-static const struct csc_table csc_table_deepcolor[] = {
- /* HDMI_DEEP_COLOR_24BIT */
- [0] = { 7036, 0, 0, 32, 0, 7036, 0, 32, 0, 0, 7036, 32, },
- /* HDMI_DEEP_COLOR_30BIT */
- [1] = { 7015, 0, 0, 128, 0, 7015, 0, 128, 0, 0, 7015, 128, },
- /* HDMI_DEEP_COLOR_36BIT */
- [2] = { 7010, 0, 0, 512, 0, 7010, 0, 512, 0, 0, 7010, 512, },
- /* FULL RANGE */
- [3] = { 8192, 0, 0, 0, 0, 8192, 0, 0, 0, 0, 8192, 0, },
-};
-
static void hdmi_core_ddc_init(struct hdmi_core_data *core)
{
void __iomem *base = core->base;
@@ -397,14 +385,6 @@ static void hdmi_core_config_video_packetizer(struct
hdmi_core_data *core)
REG_FLD_MOD(base, HDMI_CORE_VP_CONF, clr_depth ? 0 : 2, 1, 0);
}
-static void hdmi_core_config_csc(struct hdmi_core_data *core)
-{
- int clr_depth = 0; /* 24 bit color depth */
-
- /* CSC_COLORDEPTH */
- REG_FLD_MOD(core->base, HDMI_CORE_CSC_SCALE, clr_depth, 7, 4);
-}
-
static void hdmi_core_config_video_sampler(struct hdmi_core_data *core)
{
int video_mapping = 1; /* for 24 bit color depth */
@@ -469,47 +449,67 @@ static void hdmi_core_write_avi_infoframe(struct
hdmi_core_data *core,
REG_FLD_MOD(base, HDMI_CORE_FC_PRCONF, pr, 3, 0);
}
-static void hdmi_core_csc_config(struct hdmi_core_data *core,
- struct csc_table csc_coeff)
+static void hdmi_core_write_csc(struct hdmi_core_data *core,
+ const struct csc_table *csc_coeff)
{
void __iomem *base = core->base;
- REG_FLD_MOD(base, HDMI_CORE_CSC_COEF_A1_MSB, csc_coeff.a1 >> 8 , 6, 0);
- REG_FLD_MOD(base, HDMI_CORE_CSC_COEF_A1_LSB, csc_coeff.a1, 7, 0);
- REG_FLD_MOD(base, HDMI_CORE_CSC_COEF_A2_MSB, csc_coeff.a2 >> 8, 6, 0);
- REG_FLD_MOD(base, HDMI_CORE_CSC_COEF_A2_LSB, csc_coeff.a2, 7, 0);
- REG_FLD_MOD(base, HDMI_CORE_CSC_COEF_A3_MSB, csc_coeff.a3 >> 8, 6, 0);
- REG_FLD_MOD(base, HDMI_CORE_CSC_COEF_A3_LSB, csc_coeff.a3, 7, 0);
- REG_FLD_MOD(base, HDMI_CORE_CSC_COEF_A4_MSB, csc_coeff.a4 >> 8, 6, 0);
- REG_FLD_MOD(base, HDMI_CORE_CSC_COEF_A4_LSB, csc_coeff.a4, 7, 0);
- REG_FLD_MOD(base, HDMI_CORE_CSC_COEF_B1_MSB, csc_coeff.b1 >> 8, 6, 0);
- REG_FLD_MOD(base, HDMI_CORE_CSC_COEF_B1_LSB, csc_coeff.b1, 7, 0);
- REG_FLD_MOD(base, HDMI_CORE_CSC_COEF_B2_MSB, csc_coeff.b2 >> 8, 6, 0);
- REG_FLD_MOD(base, HDMI_CORE_CSC_COEF_B2_LSB, csc_coeff.b2, 7, 0);
- REG_FLD_MOD(base, HDMI_CORE_CSC_COEF_B3_MSB, csc_coeff.b3 >> 8, 6, 0);
- REG_FLD_MOD(base, HDMI_CORE_CSC_COEF_B3_LSB, csc_coeff.b3, 7, 0);
- REG_FLD_MOD(base, HDMI_CORE_CSC_COEF_B4_MSB, csc_coeff.b4 >> 8, 6, 0);
- REG_FLD_MOD(base, HDMI_CORE_CSC_COEF_B4_LSB, csc_coeff.b4, 7, 0);
- REG_FLD_MOD(base, HDMI_CORE_CSC_COEF_C1_MSB, csc_coeff.c1 >> 8, 6, 0);
- REG_FLD_MOD(base, HDMI_CORE_CSC_COEF_C1_LSB, csc_coeff.c1, 7, 0);
- REG_FLD_MOD(base, HDMI_CORE_CSC_COEF_C2_MSB, csc_coeff.c2 >> 8, 6, 0);
- REG_FLD_MOD(base, HDMI_CORE_CSC_COEF_C2_LSB, csc_coeff.c2, 7, 0);
- REG_FLD_MOD(base, HDMI_CORE_CSC_COEF_C3_MSB, csc_coeff.c3 >> 8, 6, 0);
- REG_FLD_MOD(base, HDMI_CORE_CSC_COEF_C3_LSB, csc_coeff.c3, 7, 0);
- REG_FLD_MOD(base, HDMI_CORE_CSC_COEF_C4_MSB, csc_coeff.c4 >> 8, 6, 0);
- REG_FLD_MOD(base, HDMI_CORE_CSC_COEF_C4_LSB, csc_coeff.c4, 7, 0);
-
+ REG_FLD_MOD(base, HDMI_CORE_CSC_COEF_A1_MSB, csc_coeff->a1 >> 8, 6, 0);
+ REG_FLD_MOD(base, HDMI_CORE_CSC_COEF_A1_LSB, csc_coeff->a1, 7, 0);
+ REG_FLD_MOD(base, HDMI_CORE_CSC_COEF_A2_MSB, csc_coeff->a2 >> 8, 6, 0);
+ REG_FLD_MOD(base, HDMI_CORE_CSC_COEF_A2_LSB, csc_coeff->a2, 7, 0);
+ REG_FLD_MOD(base, HDMI_CORE_CSC_COEF_A3_MSB, csc_coeff->a3 >> 8, 6, 0);
+ REG_FLD_MOD(base, HDMI_CORE_CSC_COEF_A3_LSB, csc_coeff->a3, 7, 0);
+ REG_FLD_MOD(base, HDMI_CORE_CSC_COEF_A4_MSB, csc_coeff->a4 >> 8, 6, 0);
+ REG_FLD_MOD(base, HDMI_CORE_CSC_COEF_A4_LSB, csc_coeff->a4, 7, 0);
+ REG_FLD_MOD(base, HDMI_CORE_CSC_COEF_B1_MSB, csc_coeff->b1 >> 8, 6, 0);
+ REG_FLD_MOD(base, HDMI_CORE_CSC_COEF_B1_LSB, csc_coeff->b1, 7, 0);
+ REG_FLD_MOD(base, HDMI_CORE_CSC_COEF_B2_MSB, csc_coeff->b2 >> 8, 6, 0);
+ REG_FLD_MOD(base, HDMI_CORE_CSC_COEF_B2_LSB, csc_coeff->b2, 7, 0);
+ REG_FLD_MOD(base,
[PATCH 4/7] drm/omap: Implement CTM property for CRTC using OVL managers CPR matrix
From: Jyri Sarha
Implement CTM color management property for OMAP CRTC using DSS
overlay manager's Color Phase Rotation matrix. The CPR matrix does not
exactly match the CTM property documentation. On DSS the CPR matrix is
applied after gamma table look up. However, it seems stupid to add a
custom property just for that.
Signed-off-by: Jyri Sarha
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/omap_crtc.c | 39 +++--
1 file changed, 37 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index 3c5ddbf30e97..d63213dd7d83 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -391,6 +391,32 @@ static void omap_crtc_manual_display_update(struct
work_struct *data)
}
}
+static s16 omap_crtc_S31_32_to_s2_8(s64 coef)
+{
+ uint64_t sign_bit = 1ULL << 63;
+ uint64_t cbits = (uint64_t) coef;
+ s16 ret = clamp_val(((cbits & ~sign_bit) >> 24), 0, 0x1FF);
+
+ if (cbits & sign_bit)
+ ret = -ret;
+
+ return ret;
+}
+
+static void omap_crtc_cpr_coefs_from_ctm(const struct drm_color_ctm *ctm,
+struct omap_dss_cpr_coefs *cpr)
+{
+ cpr->rr = omap_crtc_S31_32_to_s2_8(ctm->matrix[0]);
+ cpr->rg = omap_crtc_S31_32_to_s2_8(ctm->matrix[1]);
+ cpr->rb = omap_crtc_S31_32_to_s2_8(ctm->matrix[2]);
+ cpr->gr = omap_crtc_S31_32_to_s2_8(ctm->matrix[3]);
+ cpr->gg = omap_crtc_S31_32_to_s2_8(ctm->matrix[4]);
+ cpr->gb = omap_crtc_S31_32_to_s2_8(ctm->matrix[5]);
+ cpr->br = omap_crtc_S31_32_to_s2_8(ctm->matrix[6]);
+ cpr->bg = omap_crtc_S31_32_to_s2_8(ctm->matrix[7]);
+ cpr->bb = omap_crtc_S31_32_to_s2_8(ctm->matrix[8]);
+}
+
static void omap_crtc_write_crtc_properties(struct drm_crtc *crtc)
{
struct omap_drm_private *priv = crtc->dev->dev_private;
@@ -402,7 +428,16 @@ static void omap_crtc_write_crtc_properties(struct
drm_crtc *crtc)
info.default_color = 0x00;
info.trans_enabled = false;
info.partial_alpha_enabled = false;
- info.cpr_enable = false;
+
+ if (crtc->state->ctm) {
+ struct drm_color_ctm *ctm =
+ (struct drm_color_ctm *) crtc->state->ctm->data;
+
+ info.cpr_enable = true;
+ omap_crtc_cpr_coefs_from_ctm(ctm, _coefs);
+ } else {
+ info.cpr_enable = false;
+ }
priv->dispc_ops->mgr_setup(priv->dispc, omap_crtc->channel, );
}
@@ -836,7 +871,7 @@ struct drm_crtc *omap_crtc_init(struct drm_device *dev,
if (priv->dispc_ops->mgr_gamma_size(priv->dispc, channel)) {
unsigned int gamma_lut_size = 256;
- drm_crtc_enable_color_mgmt(crtc, 0, false, gamma_lut_size);
+ drm_crtc_enable_color_mgmt(crtc, 0, true, gamma_lut_size);
drm_mode_crtc_set_gamma_size(crtc, gamma_lut_size);
}
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/7] drm/omap: drop unneeded locking from mgr_fld_write()
Commit d49cd15550d9d4495f6187425318c245d58cb63f ("OMAPDSS: DISPC: lock
access to DISPC_CONTROL & DISPC_CONFIG") added locking to
mgr_fld_write(). This was needed in omapfb times due to lack of good
locking, especially in the case of both V4L2 and fbdev layers using the
DSS driver.
This is not needed for omapdrm, so we can remove the locking.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/dss/dispc.c | 16 +---
1 file changed, 1 insertion(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c
b/drivers/gpu/drm/omapdrm/dss/dispc.c
index 785c5546067a..c6da33e7014f 100644
--- a/drivers/gpu/drm/omapdrm/dss/dispc.c
+++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
@@ -184,9 +184,6 @@ struct dispc_device {
struct regmap *syscon_pol;
u32 syscon_pol_offset;
-
- /* DISPC_CONTROL & DISPC_CONFIG lock*/
- spinlock_t control_lock;
};
enum omap_color_component {
@@ -377,16 +374,7 @@ static void mgr_fld_write(struct dispc_device *dispc, enum
omap_channel channel,
enum mgr_reg_fields regfld, int val)
{
const struct dispc_reg_field rfld = mgr_desc[channel].reg_desc[regfld];
- const bool need_lock = rfld.reg == DISPC_CONTROL || rfld.reg ==
DISPC_CONFIG;
- unsigned long flags;
-
- if (need_lock) {
- spin_lock_irqsave(>control_lock, flags);
- REG_FLD_MOD(dispc, rfld.reg, val, rfld.high, rfld.low);
- spin_unlock_irqrestore(>control_lock, flags);
- } else {
- REG_FLD_MOD(dispc, rfld.reg, val, rfld.high, rfld.low);
- }
+ REG_FLD_MOD(dispc, rfld.reg, val, rfld.high, rfld.low);
}
static int dispc_get_num_ovls(struct dispc_device *dispc)
@@ -4769,8 +4757,6 @@ static int dispc_bind(struct device *dev, struct device
*master, void *data)
platform_set_drvdata(pdev, dispc);
dispc->dss = dss;
- spin_lock_init(>control_lock);
-
/*
* The OMAP3-based models can't be told apart using the compatible
* string, use SoC device matching.
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/7] drm/omap: Enable COLOR_ENCODING and COLOR_RANGE properties for planes
From: Jyri Sarha
Adds support for COLOR_ENCODING and COLOR_RANGE properties to
omap_plane.c and dispc.c. The supported encodings and ranges are:
For COLOR_ENCODING:
- YCbCt BT.601 (default)
- YCbCt BT.709
For COLOR_RANGE:
- YCbCt limited range
- YCbCt full range (default)
Signed-off-by: Jyri Sarha
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/dss/dispc.c | 119 --
drivers/gpu/drm/omapdrm/dss/omapdss.h | 4 +
drivers/gpu/drm/omapdrm/omap_plane.c | 30 +++
3 files changed, 127 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c
b/drivers/gpu/drm/omapdrm/dss/dispc.c
index 7d87d60edb80..40ddb28ee7aa 100644
--- a/drivers/gpu/drm/omapdrm/dss/dispc.c
+++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
@@ -892,32 +892,91 @@ static void dispc_wb_write_color_conv_coef(struct
dispc_device *dispc,
#undef CVAL
}
-static void dispc_setup_color_conv_coef(struct dispc_device *dispc)
+/* YUV -> RGB, ITU-R BT.601, full range */
+const static struct csc_coef_yuv2rgb coefs_yuv2rgb_bt601_full = {
+ 256, 0, 358, /* ry, rcb, rcr |1.000 0.000 1.402|*/
+ 256, -88, -182, /* gy, gcb, gcr |1.000 -0.344 -0.714|*/
+ 256, 452,0, /* by, bcb, bcr |1.000 1.772 0.000|*/
+ true, /* full range */
+};
+
+/* YUV -> RGB, ITU-R BT.601, limited range */
+const static struct csc_coef_yuv2rgb coefs_yuv2rgb_bt601_lim = {
+ 298,0, 409,/* ry, rcb, rcr |1.164 0.000 1.596|*/
+ 298, -100, -208,/* gy, gcb, gcr |1.164 -0.392 -0.813|*/
+ 298, 516,0,/* by, bcb, bcr |1.164 2.017 0.000|*/
+ false, /* limited range */
+};
+
+/* YUV -> RGB, ITU-R BT.709, full range */
+const static struct csc_coef_yuv2rgb coefs_yuv2rgb_bt709_full = {
+ 256,0, 402,/* ry, rcb, rcr |1.000 0.000 1.570|*/
+ 256, -48, -120,/* gy, gcb, gcr |1.000 -0.187 -0.467|*/
+ 256, 475,0,/* by, bcb, bcr |1.000 1.856 0.000|*/
+ true, /* full range */
+};
+
+/* YUV -> RGB, ITU-R BT.709, limited range */
+const static struct csc_coef_yuv2rgb coefs_yuv2rgb_bt709_lim = {
+ 298,0, 459,/* ry, rcb, rcr |1.164 0.000 1.793|*/
+ 298, -55, -136,/* gy, gcb, gcr |1.164 -0.213 -0.533|*/
+ 298, 541,0,/* by, bcb, bcr |1.164 2.112 0.000|*/
+ false, /* limited range */
+};
+
+/* RGB -> YUV, ITU-R BT.601, limited range */
+const static struct csc_coef_rgb2yuv coefs_rgb2yuv_bt601_lim = {
+66, 129, 25, /* yr, yg, yb | 0.257 0.504 0.098|*/
+ -38, -74, 112, /* cbr, cbg, cbb |-0.148 -0.291 0.439|*/
+ 112, -94, -18, /* crr, crg, crb | 0.439 -0.368 -0.071|*/
+ false, /* limited range */
+};
+
+/* RGB -> YUV, ITU-R BT.601, full range */
+const static struct csc_coef_rgb2yuv coefs_rgb2yuv_bt601_full = {
+77, 150, 29, /* yr, yg, yb | 0.299 0.587 0.114|*/
+ -43, -85, 128, /* cbr, cbg, cbb |-0.173 -0.339 0.511|*/
+ 128, -107, -21, /* crr, crg, crb | 0.511 -0.428 -0.083|*/
+ true, /* full range */
+};
+
+/* RGB -> YUV, ITU-R BT.709, limited range */
+const static struct csc_coef_rgb2yuv coefs_rgb2yuv_bt701_lim = {
+47, 157, 16,/* yr, yg, yb | 0.1826 0.6142 0.0620|*/
+ -26, -87, 112,/* cbr, cbg, cbb |-0.1006 -0.3386 0.4392|*/
+ 112, -102, -10,/* crr, crg, crb | 0.4392 -0.3989 -0.0403|*/
+ false, /* limited range */
+};
+
+static int dispc_ovl_set_csc(struct dispc_device *dispc,
+enum omap_plane_id plane,
+enum drm_color_encoding color_encoding,
+enum drm_color_range color_range)
{
- int i;
- int num_ovl = dispc_get_num_ovls(dispc);
-
- /* YUV -> RGB, ITU-R BT.601, limited range */
- const struct csc_coef_yuv2rgb coefs_yuv2rgb_bt601_lim = {
- 298,0, 409,/* ry, rcb, rcr */
- 298, -100, -208,/* gy, gcb, gcr */
- 298, 516,0,/* by, bcb, bcr */
- false, /* limited range */
- };
+ const struct csc_coef_yuv2rgb *csc;
- /* RGB -> YUV, ITU-R BT.601, limited range */
- const struct csc_coef_rgb2yuv coefs_rgb2yuv_bt601_lim = {
-66, 129, 25, /* yr, yg, yb */
- -38, -74, 112, /* cbr, cbg, cbb */
- 112, -94, -18, /* crr, crg, crb */
- false, /* limited range */
- };
+ switch (color_encoding) {
+ case DRM_COLOR_YCBCR_BT601:
+ if (color_range == DRM_COLOR_YCBCR_FULL_RANGE)
+ csc = _yuv2rgb_bt601_full;
+ else
+
[PATCH 3/7] drm/omap: fix missing scaler pixel fmt limitations
OMAP2 and OMAP3/AM4 have limitations with the scaler:
- OMAP2 can only scale XRGB
- OMAP3/AM4 can only scale XRGB, RGB565, YUYV and UYVY
The driver doesn't check these limitations, which leads to sync-lost
floods.
This patch adds a check for the pixel formats when scaling.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/dss/dispc.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c
b/drivers/gpu/drm/omapdrm/dss/dispc.c
index c6da33e7014f..7d87d60edb80 100644
--- a/drivers/gpu/drm/omapdrm/dss/dispc.c
+++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
@@ -114,6 +114,7 @@ struct dispc_features {
const unsigned int num_reg_fields;
const enum omap_overlay_caps *overlay_caps;
const u32 **supported_color_modes;
+ const u32 *supported_scaler_color_modes;
unsigned int num_mgrs;
unsigned int num_ovls;
unsigned int buffer_size_unit;
@@ -2498,6 +2499,19 @@ static int dispc_ovl_calc_scaling(struct dispc_device
*dispc,
if (width == out_width && height == out_height)
return 0;
+ if (dispc->feat->supported_scaler_color_modes) {
+ const u32 *modes = dispc->feat->supported_scaler_color_modes;
+ int i;
+
+ for (i = 0; modes[i]; ++i) {
+ if (modes[i] == fourcc)
+ break;
+ }
+
+ if (modes[i] == 0)
+ return -EINVAL;
+ }
+
if (plane == OMAP_DSS_WB) {
switch (fourcc) {
case DRM_FORMAT_NV12:
@@ -4213,6 +4227,12 @@ static const u32 *omap4_dispc_supported_color_modes[] = {
DRM_FORMAT_RGBX),
};
+static const u32 omap3_dispc_supported_scaler_color_modes[] = {
+ DRM_FORMAT_XRGB, DRM_FORMAT_RGB565, DRM_FORMAT_YUYV,
+ DRM_FORMAT_UYVY,
+ 0,
+};
+
static const struct dispc_features omap24xx_dispc_feats = {
.sw_start = 5,
.fp_start = 15,
@@ -4241,6 +4261,7 @@ static const struct dispc_features omap24xx_dispc_feats =
{
.num_reg_fields = ARRAY_SIZE(omap2_dispc_reg_fields),
.overlay_caps = omap2_dispc_overlay_caps,
.supported_color_modes = omap2_dispc_supported_color_modes,
+ .supported_scaler_color_modes = COLOR_ARRAY(DRM_FORMAT_XRGB),
.num_mgrs = 2,
.num_ovls = 3,
.buffer_size_unit = 1,
@@ -4275,6 +4296,7 @@ static const struct dispc_features
omap34xx_rev1_0_dispc_feats = {
.num_reg_fields = ARRAY_SIZE(omap3_dispc_reg_fields),
.overlay_caps = omap3430_dispc_overlay_caps,
.supported_color_modes = omap3_dispc_supported_color_modes,
+ .supported_scaler_color_modes =
omap3_dispc_supported_scaler_color_modes,
.num_mgrs = 2,
.num_ovls = 3,
.buffer_size_unit = 1,
@@ -4309,6 +4331,7 @@ static const struct dispc_features
omap34xx_rev3_0_dispc_feats = {
.num_reg_fields = ARRAY_SIZE(omap3_dispc_reg_fields),
.overlay_caps = omap3430_dispc_overlay_caps,
.supported_color_modes = omap3_dispc_supported_color_modes,
+ .supported_scaler_color_modes =
omap3_dispc_supported_scaler_color_modes,
.num_mgrs = 2,
.num_ovls = 3,
.buffer_size_unit = 1,
@@ -4343,6 +4366,7 @@ static const struct dispc_features omap36xx_dispc_feats =
{
.num_reg_fields = ARRAY_SIZE(omap3_dispc_reg_fields),
.overlay_caps = omap3630_dispc_overlay_caps,
.supported_color_modes = omap3_dispc_supported_color_modes,
+ .supported_scaler_color_modes =
omap3_dispc_supported_scaler_color_modes,
.num_mgrs = 2,
.num_ovls = 3,
.buffer_size_unit = 1,
@@ -4377,6 +4401,7 @@ static const struct dispc_features am43xx_dispc_feats = {
.num_reg_fields = ARRAY_SIZE(omap3_dispc_reg_fields),
.overlay_caps = omap3430_dispc_overlay_caps,
.supported_color_modes = omap3_dispc_supported_color_modes,
+ .supported_scaler_color_modes =
omap3_dispc_supported_scaler_color_modes,
.num_mgrs = 1,
.num_ovls = 3,
.buffer_size_unit = 1,
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 6/7] drm/omap: dss: platform_register_drivers() to dss.c and remove core.c
From: Jyri Sarha
The core.c just for registering the drivers is kind of useless. Let's
get rid of it and register the dss drivers in dss.c.
Signed-off-by: Jyri Sarha
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/dss/Makefile | 2 +-
drivers/gpu/drm/omapdrm/dss/core.c | 55
drivers/gpu/drm/omapdrm/dss/dss.c| 37 +++
3 files changed, 38 insertions(+), 56 deletions(-)
delete mode 100644 drivers/gpu/drm/omapdrm/dss/core.c
diff --git a/drivers/gpu/drm/omapdrm/dss/Makefile
b/drivers/gpu/drm/omapdrm/dss/Makefile
index 904101c5e79d..5950c3f52c2e 100644
--- a/drivers/gpu/drm/omapdrm/dss/Makefile
+++ b/drivers/gpu/drm/omapdrm/dss/Makefile
@@ -6,7 +6,7 @@ omapdss-base-y := base.o display.o dss-of.o output.o
obj-$(CONFIG_OMAP2_DSS) += omapdss.o
# Core DSS files
-omapdss-y := core.o dss.o dispc.o dispc_coefs.o \
+omapdss-y := dss.o dispc.o dispc_coefs.o \
pll.o video-pll.o
omapdss-$(CONFIG_OMAP2_DSS_DPI) += dpi.o
omapdss-$(CONFIG_OMAP2_DSS_VENC) += venc.o
diff --git a/drivers/gpu/drm/omapdrm/dss/core.c
b/drivers/gpu/drm/omapdrm/dss/core.c
deleted file mode 100644
index 6ac497b63711..
--- a/drivers/gpu/drm/omapdrm/dss/core.c
+++ /dev/null
@@ -1,55 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-/*
- * Copyright (C) 2009 Nokia Corporation
- * Author: Tomi Valkeinen
- *
- * Some code and ideas taken from drivers/video/omap/ driver
- * by Imre Deak.
- */
-
-#define DSS_SUBSYS_NAME "CORE"
-
-#include
-#include
-#include
-
-#include "omapdss.h"
-#include "dss.h"
-
-/* INIT */
-static struct platform_driver * const omap_dss_drivers[] = {
- _dsshw_driver,
- _dispchw_driver,
-#ifdef CONFIG_OMAP2_DSS_DSI
- _dsihw_driver,
-#endif
-#ifdef CONFIG_OMAP2_DSS_VENC
- _venchw_driver,
-#endif
-#ifdef CONFIG_OMAP4_DSS_HDMI
- _hdmi4hw_driver,
-#endif
-#ifdef CONFIG_OMAP5_DSS_HDMI
- _hdmi5hw_driver,
-#endif
-};
-
-static int __init omap_dss_init(void)
-{
- return platform_register_drivers(omap_dss_drivers,
-ARRAY_SIZE(omap_dss_drivers));
-}
-
-static void __exit omap_dss_exit(void)
-{
- platform_unregister_drivers(omap_dss_drivers,
- ARRAY_SIZE(omap_dss_drivers));
-}
-
-module_init(omap_dss_init);
-module_exit(omap_dss_exit);
-
-MODULE_AUTHOR("Tomi Valkeinen ");
-MODULE_DESCRIPTION("OMAP2/3 Display Subsystem");
-MODULE_LICENSE("GPL v2");
-
diff --git a/drivers/gpu/drm/omapdrm/dss/dss.c
b/drivers/gpu/drm/omapdrm/dss/dss.c
index e226324adb69..41d495a360d8 100644
--- a/drivers/gpu/drm/omapdrm/dss/dss.c
+++ b/drivers/gpu/drm/omapdrm/dss/dss.c
@@ -1598,3 +1598,40 @@ struct platform_driver omap_dsshw_driver = {
.suppress_bind_attrs = true,
},
};
+
+/* INIT */
+static struct platform_driver * const omap_dss_drivers[] = {
+ _dsshw_driver,
+ _dispchw_driver,
+#ifdef CONFIG_OMAP2_DSS_DSI
+ _dsihw_driver,
+#endif
+#ifdef CONFIG_OMAP2_DSS_VENC
+ _venchw_driver,
+#endif
+#ifdef CONFIG_OMAP4_DSS_HDMI
+ _hdmi4hw_driver,
+#endif
+#ifdef CONFIG_OMAP5_DSS_HDMI
+ _hdmi5hw_driver,
+#endif
+};
+
+static int __init omap_dss_init(void)
+{
+ return platform_register_drivers(omap_dss_drivers,
+ARRAY_SIZE(omap_dss_drivers));
+}
+
+static void __exit omap_dss_exit(void)
+{
+ platform_unregister_drivers(omap_dss_drivers,
+ ARRAY_SIZE(omap_dss_drivers));
+}
+
+module_init(omap_dss_init);
+module_exit(omap_dss_exit);
+
+MODULE_AUTHOR("Tomi Valkeinen ");
+MODULE_DESCRIPTION("OMAP2/3/4/5 Display Subsystem");
+MODULE_LICENSE("GPL v2");
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/7] drm/omap: tweak HDMI DDC timings
From: Alejandro Hernandez
A "HDMI I2C Master Error" is sometimes reported with the current DDC SCL
timings. The current settings for a 10us SCL period (100 KHz) causes the
error with some displays. This patch increases the SCL signal period
from 10us to 10.2us, with the new settings the error is not observed
Signed-off-by: Alejandro Hernandez
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/dss/hdmi5_core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi5_core.c
b/drivers/gpu/drm/omapdrm/dss/hdmi5_core.c
index 7400fb99d453..4c588ec7634a 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi5_core.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi5_core.c
@@ -39,8 +39,8 @@ static void hdmi_core_ddc_init(struct hdmi_core_data *core)
{
void __iomem *base = core->base;
const unsigned long long iclk = 26600; /* DSS L3 ICLK */
- const unsigned int ss_scl_high = 4600; /* ns */
- const unsigned int ss_scl_low = 5400; /* ns */
+ const unsigned int ss_scl_high = 4700; /* ns */
+ const unsigned int ss_scl_low = 5500; /* ns */
const unsigned int fs_scl_high = 600; /* ns */
const unsigned int fs_scl_low = 1300; /* ns */
const unsigned int sda_hold = 1000; /* ns */
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/7] drm/omap: misc improvements
Hi, Misc improvements to omapdrm which have been lying around for a long time, and I've missed upstreaming them. And one new one, which makes the DSS5 HDMI pick up the color range automatically. Tomi Alejandro Hernandez (1): drm/omap: tweak HDMI DDC timings Jyri Sarha (3): drm/omap: Implement CTM property for CRTC using OVL managers CPR matrix drm/omap: Enable COLOR_ENCODING and COLOR_RANGE properties for planes drm/omap: dss: platform_register_drivers() to dss.c and remove core.c Tomi Valkeinen (3): drm/omap: drop unneeded locking from mgr_fld_write() drm/omap: fix missing scaler pixel fmt limitations drm/omap: hdmi5: automatically choose limited/full range output drivers/gpu/drm/omapdrm/dss/Makefile | 2 +- drivers/gpu/drm/omapdrm/dss/core.c | 55 drivers/gpu/drm/omapdrm/dss/dispc.c | 160 +-- drivers/gpu/drm/omapdrm/dss/dss.c| 37 ++ drivers/gpu/drm/omapdrm/dss/hdmi5_core.c | 125 ++ drivers/gpu/drm/omapdrm/dss/omapdss.h| 4 + drivers/gpu/drm/omapdrm/omap_crtc.c | 39 +- drivers/gpu/drm/omapdrm/omap_plane.c | 30 + 8 files changed, 295 insertions(+), 157 deletions(-) delete mode 100644 drivers/gpu/drm/omapdrm/dss/core.c -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/5] drm/ttm: add drm_gem_ttm_print_info()
Now with ttm_buffer_object being a subclass of drm_gem_object we can
easily lookup ttm_buffer_object for a given drm_gem_object, which in
turm allows to create common helper functions.
This patch starts off with a drm_gem_ttm_print_info() helper function
which prints adds some ttm specific lines to the debug output.
Signed-off-by: Gerd Hoffmann
---
include/drm/drm_gem_ttm_helper.h | 19
drivers/gpu/drm/drm_gem_ttm_helper.c | 67
Documentation/gpu/drm-mm.rst | 12 +
drivers/gpu/drm/Kconfig | 7 +++
drivers/gpu/drm/Makefile | 3 ++
5 files changed, 108 insertions(+)
create mode 100644 include/drm/drm_gem_ttm_helper.h
create mode 100644 drivers/gpu/drm/drm_gem_ttm_helper.c
diff --git a/include/drm/drm_gem_ttm_helper.h b/include/drm/drm_gem_ttm_helper.h
new file mode 100644
index ..6268f89c5a48
--- /dev/null
+++ b/include/drm/drm_gem_ttm_helper.h
@@ -0,0 +1,19 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+
+#ifndef DRM_GEM_TTM_HELPER_H
+#define DRM_GEM_TTM_HELPER_H
+
+#include
+
+#include
+#include
+#include
+#include
+
+#define drm_gem_ttm_of_gem(gem_obj) \
+ container_of(gem_obj, struct ttm_buffer_object, base)
+
+void drm_gem_ttm_print_info(struct drm_printer *p, unsigned int indent,
+ const struct drm_gem_object *gem);
+
+#endif
diff --git a/drivers/gpu/drm/drm_gem_ttm_helper.c
b/drivers/gpu/drm/drm_gem_ttm_helper.c
new file mode 100644
index ..cd6ac2cc8fdd
--- /dev/null
+++ b/drivers/gpu/drm/drm_gem_ttm_helper.c
@@ -0,0 +1,67 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+
+#include
+
+#include
+
+/**
+ * DOC: overview
+ *
+ * This library provides helper functions for gem objects backed by
+ * ttm.
+ */
+
+/**
+ * drm_gem_ttm_print_info() - Print _buffer_object info for debugfs
+ * @p: DRM printer
+ * @indent: Tab indentation level
+ * @gem: GEM object
+ *
+ * This function can be used as the _driver->gem_print_info callback.
+ */
+void drm_gem_ttm_print_info(struct drm_printer *p, unsigned int indent,
+ const struct drm_gem_object *gem)
+{
+ static const char *plname[] = {
+ [ TTM_PL_SYSTEM ] = "system",
+ [ TTM_PL_TT ] = "tt",
+ [ TTM_PL_VRAM ] = "vram",
+ [ TTM_PL_PRIV ] = "priv",
+
+ [ 16 ]= "cached",
+ [ 17 ]= "uncached",
+ [ 18 ]= "wc",
+ [ 19 ]= "contig",
+
+ [ 21 ]= "pinned", /* NO_EVICT */
+ [ 22 ]= "topdown",
+ };
+ const struct ttm_buffer_object *bo = drm_gem_ttm_of_gem(gem);
+ bool first = true;
+ unsigned int i;
+
+ for (i = 0; i < ARRAY_SIZE(plname); i++) {
+ if (!(bo->mem.placement & (1 << i)))
+ continue;
+ if (!plname[i])
+ continue;
+ if (first) {
+ first = false;
+ drm_printf_indent(p, indent, "placement=%s", plname[i]);
+ } else
+ drm_printf(p, ",%s", plname[i]);
+ }
+ if (!first)
+ drm_printf(p, "\n");
+
+ if (bo->mem.bus.is_iomem) {
+ drm_printf_indent(p, indent, "bus.base=%lx\n",
+ (unsigned long)bo->mem.bus.base);
+ drm_printf_indent(p, indent, "bus.offset=%lx\n",
+ (unsigned long)bo->mem.bus.offset);
+ }
+}
+EXPORT_SYMBOL(drm_gem_ttm_print_info);
+
+MODULE_DESCRIPTION("DRM gem ttm helpers");
+MODULE_LICENSE("GPL");
diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
index b664f054c259..a70a1d9f30ec 100644
--- a/Documentation/gpu/drm-mm.rst
+++ b/Documentation/gpu/drm-mm.rst
@@ -412,6 +412,18 @@ VRAM MM Helper Functions Reference
.. kernel-doc:: drivers/gpu/drm/drm_vram_mm_helper.c
:export:
+GEM TTM Helper Functions Reference
+---
+
+.. kernel-doc:: drivers/gpu/drm/drm_gem_ttm_helper.c
+ :doc: overview
+
+.. kernel-doc:: include/drm/drm_gem_ttm_helper.h
+ :internal:
+
+.. kernel-doc:: drivers/gpu/drm/drm_gem_ttm_helper.c
+ :export:
+
VMA Offset Manager
==
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index e6f40fb54c9a..f7b25519f95c 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -172,6 +172,13 @@ config DRM_VRAM_HELPER
help
Helpers for VRAM memory management
+config DRM_TTM_HELPER
+ tristate
+ depends on DRM
+ select DRM_TTM
+ help
+ Helpers for ttm-based gem objects
+
config DRM_GEM_CMA_HELPER
bool
depends on DRM
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 10f8329a8b71..545c61d6528b 100644
--- a/drivers/gpu/drm/Makefile
+++
[PATCH 2/5] drm/vram: use drm_gem_ttm_print_info
Signed-off-by: Gerd Hoffmann
---
include/drm/drm_gem_vram_helper.h | 1 +
drivers/gpu/drm/drm_gem_vram_helper.c | 3 ++-
drivers/gpu/drm/Kconfig | 1 +
3 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/include/drm/drm_gem_vram_helper.h
b/include/drm/drm_gem_vram_helper.h
index ac217d768456..17f160dd6e7d 100644
--- a/include/drm/drm_gem_vram_helper.h
+++ b/include/drm/drm_gem_vram_helper.h
@@ -4,6 +4,7 @@
#define DRM_GEM_VRAM_HELPER_H
#include
+#include
#include
#include
#include /* for container_of() */
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index fd751078bae1..b4929e1fb190 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -633,5 +633,6 @@ static const struct drm_gem_object_funcs
drm_gem_vram_object_funcs = {
.pin= drm_gem_vram_object_pin,
.unpin = drm_gem_vram_object_unpin,
.vmap = drm_gem_vram_object_vmap,
- .vunmap = drm_gem_vram_object_vunmap
+ .vunmap = drm_gem_vram_object_vunmap,
+ .print_info = drm_gem_ttm_print_info,
};
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index f7b25519f95c..1be8ad30d8fe 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -169,6 +169,7 @@ config DRM_VRAM_HELPER
tristate
depends on DRM
select DRM_TTM
+ select DRM_TTM_HELPER
help
Helpers for VRAM memory management
--
2.18.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/5] drm/qxl: use drm_gem_ttm_print_info
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_drv.h| 1 +
drivers/gpu/drm/qxl/qxl_object.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/qxl/qxl_drv.h b/drivers/gpu/drm/qxl/qxl_drv.h
index 9e034c5fa87d..d4051409ce64 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.h
+++ b/drivers/gpu/drm/qxl/qxl_drv.h
@@ -38,6 +38,7 @@
#include
#include
#include
+#include
#include
#include
#include
diff --git a/drivers/gpu/drm/qxl/qxl_object.c b/drivers/gpu/drm/qxl/qxl_object.c
index 29aab7b14513..c013c516f561 100644
--- a/drivers/gpu/drm/qxl/qxl_object.c
+++ b/drivers/gpu/drm/qxl/qxl_object.c
@@ -86,6 +86,7 @@ static const struct drm_gem_object_funcs qxl_object_funcs = {
.get_sg_table = qxl_gem_prime_get_sg_table,
.vmap = qxl_gem_prime_vmap,
.vunmap = qxl_gem_prime_vunmap,
+ .print_info = drm_gem_ttm_print_info,
};
int qxl_bo_create(struct qxl_device *qdev,
--
2.18.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/5] drm/qxl: use drm_gem_object_funcs callbacks
Switch qxl to use drm_gem_object_funcs callbacks
instead of drm_driver callbacks.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_drv.c| 8
drivers/gpu/drm/qxl/qxl_object.c | 12
2 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
index 2b726a51a302..996d428fa7e6 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.c
+++ b/drivers/gpu/drm/qxl/qxl_drv.c
@@ -258,16 +258,8 @@ static struct drm_driver qxl_driver = {
#endif
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
- .gem_prime_pin = qxl_gem_prime_pin,
- .gem_prime_unpin = qxl_gem_prime_unpin,
- .gem_prime_get_sg_table = qxl_gem_prime_get_sg_table,
.gem_prime_import_sg_table = qxl_gem_prime_import_sg_table,
- .gem_prime_vmap = qxl_gem_prime_vmap,
- .gem_prime_vunmap = qxl_gem_prime_vunmap,
.gem_prime_mmap = qxl_gem_prime_mmap,
- .gem_free_object_unlocked = qxl_gem_object_free,
- .gem_open_object = qxl_gem_object_open,
- .gem_close_object = qxl_gem_object_close,
.fops = _fops,
.ioctls = qxl_ioctls,
.irq_handler = qxl_irq_handler,
diff --git a/drivers/gpu/drm/qxl/qxl_object.c b/drivers/gpu/drm/qxl/qxl_object.c
index 548dfe6f3b26..29aab7b14513 100644
--- a/drivers/gpu/drm/qxl/qxl_object.c
+++ b/drivers/gpu/drm/qxl/qxl_object.c
@@ -77,6 +77,17 @@ void qxl_ttm_placement_from_domain(struct qxl_bo *qbo, u32
domain, bool pinned)
}
}
+static const struct drm_gem_object_funcs qxl_object_funcs = {
+ .free = qxl_gem_object_free,
+ .open = qxl_gem_object_open,
+ .close = qxl_gem_object_close,
+ .pin = qxl_gem_prime_pin,
+ .unpin = qxl_gem_prime_unpin,
+ .get_sg_table = qxl_gem_prime_get_sg_table,
+ .vmap = qxl_gem_prime_vmap,
+ .vunmap = qxl_gem_prime_vunmap,
+};
+
int qxl_bo_create(struct qxl_device *qdev,
unsigned long size, bool kernel, bool pinned, u32 domain,
struct qxl_surface *surf,
@@ -100,6 +111,7 @@ int qxl_bo_create(struct qxl_device *qdev,
kfree(bo);
return r;
}
+ bo->tbo.base.funcs = _object_funcs;
bo->type = domain;
bo->pin_count = pinned ? 1 : 0;
bo->surface_id = 0;
--
2.18.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/5] drm: add some ttm/vram info to debugfs
Gerd Hoffmann (5): drm/ttm: add drm_gem_ttm_print_info() drm/vram: use drm_gem_ttm_print_info drm/vram: add vram-mm debugfs file drm/qxl: use drm_gem_object_funcs callbacks drm/qxl: use drm_gem_ttm_print_info drivers/gpu/drm/qxl/qxl_drv.h | 1 + include/drm/drm_gem_ttm_helper.h | 19 include/drm/drm_gem_vram_helper.h | 2 + include/drm/drm_vram_mm_helper.h | 1 + drivers/gpu/drm/drm_gem_ttm_helper.c | 67 +++ drivers/gpu/drm/drm_gem_vram_helper.c | 3 +- drivers/gpu/drm/drm_vram_mm_helper.c | 33 + drivers/gpu/drm/qxl/qxl_drv.c | 8 drivers/gpu/drm/qxl/qxl_object.c | 13 ++ Documentation/gpu/drm-mm.rst | 12 + drivers/gpu/drm/Kconfig | 8 drivers/gpu/drm/Makefile | 3 ++ 12 files changed, 161 insertions(+), 9 deletions(-) create mode 100644 include/drm/drm_gem_ttm_helper.h create mode 100644 drivers/gpu/drm/drm_gem_ttm_helper.c -- 2.18.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/5] drm/vram: add vram-mm debugfs file
Wire up drm_mm_print() for vram helpers, using a new
debugfs file, so one can see how vram is used:
# cat /sys/kernel/debug/dri/0/vram-mm
0x-0x0300: 768: used
0x0300-0x0600: 768: used
0x0600-0x0900: 768: used
0x0900-0x0c00: 768: used
0x0c00-0x4000: 13312: free
total: 16384, used 3072 free 13312
Signed-off-by: Gerd Hoffmann
---
include/drm/drm_gem_vram_helper.h| 1 +
include/drm/drm_vram_mm_helper.h | 1 +
drivers/gpu/drm/drm_vram_mm_helper.c | 33
3 files changed, 35 insertions(+)
diff --git a/include/drm/drm_gem_vram_helper.h
b/include/drm/drm_gem_vram_helper.h
index 17f160dd6e7d..d48fdf90b254 100644
--- a/include/drm/drm_gem_vram_helper.h
+++ b/include/drm/drm_gem_vram_helper.h
@@ -123,6 +123,7 @@ int drm_gem_vram_driver_dumb_mmap_offset(struct drm_file
*file,
* drm_driver with default functions.
*/
#define DRM_GEM_VRAM_DRIVER \
+ .debugfs_init = drm_vram_mm_debugfs_init, \
.dumb_create = drm_gem_vram_driver_dumb_create, \
.dumb_map_offset = drm_gem_vram_driver_dumb_mmap_offset, \
.gem_prime_mmap = drm_gem_prime_mmap
diff --git a/include/drm/drm_vram_mm_helper.h b/include/drm/drm_vram_mm_helper.h
index 2aacfb1ccfae..9e0ac9aaac7d 100644
--- a/include/drm/drm_vram_mm_helper.h
+++ b/include/drm/drm_vram_mm_helper.h
@@ -60,6 +60,7 @@ static inline struct drm_vram_mm *drm_vram_mm_of_bdev(
return container_of(bdev, struct drm_vram_mm, bdev);
}
+int drm_vram_mm_debugfs_init(struct drm_minor *minor);
int drm_vram_mm_init(struct drm_vram_mm *vmm, struct drm_device *dev,
uint64_t vram_base, size_t vram_size,
const struct drm_vram_mm_funcs *funcs);
diff --git a/drivers/gpu/drm/drm_vram_mm_helper.c
b/drivers/gpu/drm/drm_vram_mm_helper.c
index c911781d6728..486061b83a73 100644
--- a/drivers/gpu/drm/drm_vram_mm_helper.c
+++ b/drivers/gpu/drm/drm_vram_mm_helper.c
@@ -1,7 +1,9 @@
// SPDX-License-Identifier: GPL-2.0-or-later
+#include
#include
#include
+#include
#include
#include
@@ -148,6 +150,37 @@ static struct ttm_bo_driver bo_driver = {
* struct drm_vram_mm
*/
+#if defined(CONFIG_DEBUG_FS)
+static int drm_vram_mm_debugfs(struct seq_file *m, void *data)
+{
+ struct drm_info_node *node = (struct drm_info_node *) m->private;
+ struct drm_vram_mm *vmm = node->minor->dev->vram_mm;
+ struct drm_mm *mm = vmm->bdev.man[TTM_PL_VRAM].priv;
+ struct ttm_bo_global *glob = vmm->bdev.glob;
+ struct drm_printer p = drm_seq_file_printer(m);
+
+ spin_lock(>lru_lock);
+ drm_mm_print(mm, );
+ spin_unlock(>lru_lock);
+ return 0;
+}
+
+static struct drm_info_list drm_vram_mm_debugfs_list[] = {
+ { "vram-mm", drm_vram_mm_debugfs, 0, NULL },
+};
+#endif
+
+int drm_vram_mm_debugfs_init(struct drm_minor *minor)
+{
+#if defined(CONFIG_DEBUG_FS)
+ drm_debugfs_create_files(drm_vram_mm_debugfs_list,
+ARRAY_SIZE(drm_vram_mm_debugfs_list),
+minor->debugfs_root, minor);
+#endif
+ return 0;
+}
+EXPORT_SYMBOL(drm_vram_mm_debugfs_init);
+
/**
* drm_vram_mm_init() - Initialize an instance of VRAM MM.
* @vmm: the VRAM MM instance to initialize
--
2.18.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 0/7] backlight: gpio: simplify the driver
pon., 2 wrz 2019 o 11:31 Lee Jones napisał(a): > > On Wed, 24 Jul 2019, Bartosz Golaszewski wrote: > > > From: Bartosz Golaszewski > > > > While working on my other series related to gpio-backlight[1] I noticed > > that we could simplify the driver if we made the only user of platform > > data use GPIO lookups and device properties. This series tries to do > > that. > > > > The first patch adds all necessary data structures to ecovec24. Patch > > 2/7 unifies much of the code for both pdata and non-pdata cases. Patches > > 3-4/7 remove unused platform data fields. Last three patches contain > > additional improvements for the GPIO backlight driver while we're already > > modifying it. > > > > I don't have access to this HW but hopefully this works. Only compile > > tested. > > > > [1] https://lkml.org/lkml/2019/6/25/900 > > > > v1 -> v2: > > - rebased on top of v5.3-rc1 and adjusted to the recent changes from Andy > > - added additional two patches with minor improvements > > > > v2 -> v3: > > - in patch 7/7: used initializers to set values for pdata and dev local vars > > > > Bartosz Golaszewski (7): > > sh: ecovec24: add additional properties to the backlight device > > backlight: gpio: simplify the platform data handling > > sh: ecovec24: don't set unused fields in platform data > > backlight: gpio: remove unused fields from platform data > > backlight: gpio: remove dev from struct gpio_backlight > > backlight: gpio: remove def_value from struct gpio_backlight > > backlight: gpio: use a helper variable for >dev > > > > arch/sh/boards/mach-ecovec24/setup.c | 33 ++-- > > drivers/video/backlight/gpio_backlight.c | 82 +--- > > include/linux/platform_data/gpio_backlight.h | 3 - > > 3 files changed, 44 insertions(+), 74 deletions(-) > > Can you collect all your Acks and re-submit please? > Done. Bart > -- > Lee Jones [李琼斯] > Linaro Services Technical Lead > Linaro.org │ Open source software for ARM SoCs > Follow Linaro: Facebook | Twitter | Blog
[RESEND PATCH v3 1/7] sh: ecovec24: add additional properties to the backlight device
From: Bartosz Golaszewski
Add a GPIO lookup entry and a device property for GPIO backlight to the
board file. Tie them to the platform device which is now registered using
platform_device_register_full() because of the properties. These changes
are inactive now but will be used once the gpio backlight driver is
modified.
Signed-off-by: Bartosz Golaszewski
Reviewed-by: Andy Shevchenko
Reviewed-by: Linus Walleij
---
arch/sh/boards/mach-ecovec24/setup.c | 30 +++-
1 file changed, 25 insertions(+), 5 deletions(-)
diff --git a/arch/sh/boards/mach-ecovec24/setup.c
b/arch/sh/boards/mach-ecovec24/setup.c
index f402aa741bf3..6926bb3865b9 100644
--- a/arch/sh/boards/mach-ecovec24/setup.c
+++ b/arch/sh/boards/mach-ecovec24/setup.c
@@ -371,6 +371,19 @@ static struct platform_device lcdc_device = {
},
};
+static struct gpiod_lookup_table gpio_backlight_lookup = {
+ .dev_id = "gpio-backlight.0",
+ .table = {
+ GPIO_LOOKUP("sh7724_pfc", GPIO_PTR1, NULL, GPIO_ACTIVE_HIGH),
+ { }
+ },
+};
+
+static struct property_entry gpio_backlight_props[] = {
+ PROPERTY_ENTRY_BOOL("default-on"),
+ { }
+};
+
static struct gpio_backlight_platform_data gpio_backlight_data = {
.fbdev = _device.dev,
.gpio = GPIO_PTR1,
@@ -378,13 +391,15 @@ static struct gpio_backlight_platform_data
gpio_backlight_data = {
.name = "backlight",
};
-static struct platform_device gpio_backlight_device = {
+static const struct platform_device_info gpio_backlight_device_info = {
.name = "gpio-backlight",
- .dev = {
- .platform_data = _backlight_data,
- },
+ .data = _backlight_data,
+ .size_data = sizeof(gpio_backlight_data),
+ .properties = gpio_backlight_props,
};
+static struct platform_device *gpio_backlight_device;
+
/* CEU0 */
static struct ceu_platform_data ceu0_pdata = {
.num_subdevs= 2,
@@ -1006,7 +1021,6 @@ static struct platform_device *ecovec_devices[]
__initdata = {
_common_device,
_device,
_device,
- _backlight_device,
_device,
_power,
#if defined(CONFIG_MMC_SDHI) || defined(CONFIG_MMC_SDHI_MODULE)
@@ -1464,6 +1478,12 @@ static int __init arch_setup(void)
#endif
#endif
+ gpiod_add_lookup_table(_backlight_lookup);
+ gpio_backlight_device = platform_device_register_full(
+ _backlight_device_info);
+ if (IS_ERR(gpio_backlight_device))
+ return PTR_ERR(gpio_backlight_device);
+
return platform_add_devices(ecovec_devices,
ARRAY_SIZE(ecovec_devices));
}
--
2.21.0
[RESEND PATCH v3 4/7] backlight: gpio: remove unused fields from platform data
From: Bartosz Golaszewski
Remove the platform data fields that nobody uses.
Signed-off-by: Bartosz Golaszewski
Reviewed-by: Andy Shevchenko
Reviewed-by: Linus Walleij
Reviewed-by: Daniel Thompson
---
include/linux/platform_data/gpio_backlight.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/include/linux/platform_data/gpio_backlight.h
b/include/linux/platform_data/gpio_backlight.h
index 34179d600360..1a8b5b1946fe 100644
--- a/include/linux/platform_data/gpio_backlight.h
+++ b/include/linux/platform_data/gpio_backlight.h
@@ -9,9 +9,6 @@ struct device;
struct gpio_backlight_platform_data {
struct device *fbdev;
- int gpio;
- int def_value;
- const char *name;
};
#endif
--
2.21.0
[RESEND PATCH v3 0/7] backlight: gpio: simplify the driver
From: Bartosz Golaszewski While working on my other series related to gpio-backlight[1] I noticed that we could simplify the driver if we made the only user of platform data use GPIO lookups and device properties. This series tries to do that. The first patch adds all necessary data structures to ecovec24. Patch 2/7 unifies much of the code for both pdata and non-pdata cases. Patches 3-4/7 remove unused platform data fields. Last three patches contain additional improvements for the GPIO backlight driver while we're already modifying it. I don't have access to this HW but hopefully this works. Only compile tested. [1] https://lkml.org/lkml/2019/6/25/900 v1 -> v2: - rebased on top of v5.3-rc1 and adjusted to the recent changes from Andy - added additional two patches with minor improvements v2 -> v3: - in patch 7/7: used initializers to set values for pdata and dev local vars Bartosz Golaszewski (7): sh: ecovec24: add additional properties to the backlight device backlight: gpio: simplify the platform data handling sh: ecovec24: don't set unused fields in platform data backlight: gpio: remove unused fields from platform data backlight: gpio: remove dev from struct gpio_backlight backlight: gpio: remove def_value from struct gpio_backlight backlight: gpio: use a helper variable for >dev arch/sh/boards/mach-ecovec24/setup.c | 33 ++-- drivers/video/backlight/gpio_backlight.c | 82 +--- include/linux/platform_data/gpio_backlight.h | 3 - 3 files changed, 44 insertions(+), 74 deletions(-) -- 2.21.0
[RESEND PATCH v3 3/7] sh: ecovec24: don't set unused fields in platform data
From: Bartosz Golaszewski
Platform data fields other than fbdev are no longer used by the
backlight driver. Remove them.
Signed-off-by: Bartosz Golaszewski
Reviewed-by: Andy Shevchenko
Reviewed-by: Linus Walleij
---
arch/sh/boards/mach-ecovec24/setup.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/sh/boards/mach-ecovec24/setup.c
b/arch/sh/boards/mach-ecovec24/setup.c
index 6926bb3865b9..64a5a1662b6d 100644
--- a/arch/sh/boards/mach-ecovec24/setup.c
+++ b/arch/sh/boards/mach-ecovec24/setup.c
@@ -386,9 +386,6 @@ static struct property_entry gpio_backlight_props[] = {
static struct gpio_backlight_platform_data gpio_backlight_data = {
.fbdev = _device.dev,
- .gpio = GPIO_PTR1,
- .def_value = 1,
- .name = "backlight",
};
static const struct platform_device_info gpio_backlight_device_info = {
--
2.21.0
[RESEND PATCH v3 7/7] backlight: gpio: use a helper variable for >dev
From: Bartosz Golaszewski
Instead of dereferencing pdev each time, use a helper variable for
the associated device pointer.
Signed-off-by: Bartosz Golaszewski
Reviewed-by: Linus Walleij
Reviewed-by: Daniel Thompson
Reviewed-by: Andy Shevchenko
---
drivers/video/backlight/gpio_backlight.c | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/drivers/video/backlight/gpio_backlight.c
b/drivers/video/backlight/gpio_backlight.c
index cd6a75bca9cc..7dc4f90d926b 100644
--- a/drivers/video/backlight/gpio_backlight.c
+++ b/drivers/video/backlight/gpio_backlight.c
@@ -54,29 +54,29 @@ static const struct backlight_ops gpio_backlight_ops = {
static int gpio_backlight_probe(struct platform_device *pdev)
{
- struct gpio_backlight_platform_data *pdata =
- dev_get_platdata(>dev);
+ struct device *dev = >dev;
+ struct gpio_backlight_platform_data *pdata = dev_get_platdata(dev);
struct backlight_properties props;
struct backlight_device *bl;
struct gpio_backlight *gbl;
enum gpiod_flags flags;
int ret, def_value;
- gbl = devm_kzalloc(>dev, sizeof(*gbl), GFP_KERNEL);
+ gbl = devm_kzalloc(dev, sizeof(*gbl), GFP_KERNEL);
if (gbl == NULL)
return -ENOMEM;
if (pdata)
gbl->fbdev = pdata->fbdev;
- def_value = device_property_read_bool(>dev, "default-on");
+ def_value = device_property_read_bool(dev, "default-on");
flags = def_value ? GPIOD_OUT_HIGH : GPIOD_OUT_LOW;
- gbl->gpiod = devm_gpiod_get(>dev, NULL, flags);
+ gbl->gpiod = devm_gpiod_get(dev, NULL, flags);
if (IS_ERR(gbl->gpiod)) {
ret = PTR_ERR(gbl->gpiod);
if (ret != -EPROBE_DEFER) {
- dev_err(>dev,
+ dev_err(dev,
"Error: The gpios parameter is missing or
invalid.\n");
}
return ret;
@@ -85,11 +85,10 @@ static int gpio_backlight_probe(struct platform_device
*pdev)
memset(, 0, sizeof(props));
props.type = BACKLIGHT_RAW;
props.max_brightness = 1;
- bl = devm_backlight_device_register(>dev, dev_name(>dev),
- >dev, gbl, _backlight_ops,
- );
+ bl = devm_backlight_device_register(dev, dev_name(dev), dev, gbl,
+ _backlight_ops, );
if (IS_ERR(bl)) {
- dev_err(>dev, "failed to register backlight\n");
+ dev_err(dev, "failed to register backlight\n");
return PTR_ERR(bl);
}
--
2.21.0
[RESEND PATCH v3 2/7] backlight: gpio: simplify the platform data handling
From: Bartosz Golaszewski
Now that the last user of platform data (sh ecovec24) defines a proper
GPIO lookup and sets the 'default-on' device property, we can drop the
platform_data-specific GPIO handling and unify a big chunk of code.
The only field used from the platform data is now the fbdev pointer.
Signed-off-by: Bartosz Golaszewski
Reviewed-by: Linus Walleij
Reviewed-by: Daniel Thompson
Reviewed-by: Andy Shevchenko
---
drivers/video/backlight/gpio_backlight.c | 64 +---
1 file changed, 13 insertions(+), 51 deletions(-)
diff --git a/drivers/video/backlight/gpio_backlight.c
b/drivers/video/backlight/gpio_backlight.c
index e84f3087e29f..01262186fa1e 100644
--- a/drivers/video/backlight/gpio_backlight.c
+++ b/drivers/video/backlight/gpio_backlight.c
@@ -55,30 +55,6 @@ static const struct backlight_ops gpio_backlight_ops = {
.check_fb = gpio_backlight_check_fb,
};
-static int gpio_backlight_probe_dt(struct platform_device *pdev,
- struct gpio_backlight *gbl)
-{
- struct device *dev = >dev;
- enum gpiod_flags flags;
- int ret;
-
- gbl->def_value = device_property_read_bool(dev, "default-on");
- flags = gbl->def_value ? GPIOD_OUT_HIGH : GPIOD_OUT_LOW;
-
- gbl->gpiod = devm_gpiod_get(dev, NULL, flags);
- if (IS_ERR(gbl->gpiod)) {
- ret = PTR_ERR(gbl->gpiod);
-
- if (ret != -EPROBE_DEFER) {
- dev_err(dev,
- "Error: The gpios parameter is missing or
invalid.\n");
- }
- return ret;
- }
-
- return 0;
-}
-
static int gpio_backlight_probe(struct platform_device *pdev)
{
struct gpio_backlight_platform_data *pdata =
@@ -86,6 +62,7 @@ static int gpio_backlight_probe(struct platform_device *pdev)
struct backlight_properties props;
struct backlight_device *bl;
struct gpio_backlight *gbl;
+ enum gpiod_flags flags;
int ret;
gbl = devm_kzalloc(>dev, sizeof(*gbl), GFP_KERNEL);
@@ -94,35 +71,20 @@ static int gpio_backlight_probe(struct platform_device
*pdev)
gbl->dev = >dev;
- if (pdev->dev.fwnode) {
- ret = gpio_backlight_probe_dt(pdev, gbl);
- if (ret)
- return ret;
- } else if (pdata) {
- /*
-* Legacy platform data GPIO retrieveal. Do not expand
-* the use of this code path, currently only used by one
-* SH board.
-*/
- unsigned long flags = GPIOF_DIR_OUT;
-
+ if (pdata)
gbl->fbdev = pdata->fbdev;
- gbl->def_value = pdata->def_value;
- flags |= gbl->def_value ? GPIOF_INIT_HIGH : GPIOF_INIT_LOW;
-
- ret = devm_gpio_request_one(gbl->dev, pdata->gpio, flags,
- pdata ? pdata->name : "backlight");
- if (ret < 0) {
- dev_err(>dev, "unable to request GPIO\n");
- return ret;
+
+ gbl->def_value = device_property_read_bool(>dev, "default-on");
+ flags = gbl->def_value ? GPIOD_OUT_HIGH : GPIOD_OUT_LOW;
+
+ gbl->gpiod = devm_gpiod_get(>dev, NULL, flags);
+ if (IS_ERR(gbl->gpiod)) {
+ ret = PTR_ERR(gbl->gpiod);
+ if (ret != -EPROBE_DEFER) {
+ dev_err(>dev,
+ "Error: The gpios parameter is missing or
invalid.\n");
}
- gbl->gpiod = gpio_to_desc(pdata->gpio);
- if (!gbl->gpiod)
- return -EINVAL;
- } else {
- dev_err(>dev,
- "failed to find platform data or device tree node.\n");
- return -ENODEV;
+ return ret;
}
memset(, 0, sizeof(props));
--
2.21.0
[RESEND PATCH v3 5/7] backlight: gpio: remove dev from struct gpio_backlight
From: Bartosz Golaszewski
This field is unused. Remove it.
Signed-off-by: Bartosz Golaszewski
Reviewed-by: Andy Shevchenko
Reviewed-by: Linus Walleij
Reviewed-by: Daniel Thompson
---
drivers/video/backlight/gpio_backlight.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/video/backlight/gpio_backlight.c
b/drivers/video/backlight/gpio_backlight.c
index 01262186fa1e..70882556f047 100644
--- a/drivers/video/backlight/gpio_backlight.c
+++ b/drivers/video/backlight/gpio_backlight.c
@@ -19,9 +19,7 @@
#include
struct gpio_backlight {
- struct device *dev;
struct device *fbdev;
-
struct gpio_desc *gpiod;
int def_value;
};
@@ -69,8 +67,6 @@ static int gpio_backlight_probe(struct platform_device *pdev)
if (gbl == NULL)
return -ENOMEM;
- gbl->dev = >dev;
-
if (pdata)
gbl->fbdev = pdata->fbdev;
--
2.21.0
Re: [PATCH] drm/vkms: Use alpha value to blend values.
On Sat, Aug 31, 2019 at 06:25:46PM +0100, Sidong Yang wrote:
> Use alpha value to blend source value and destination value Instead of
> just overwrite with source value.
>
> Signed-off-by: Sidong Yang
> ---
> drivers/gpu/drm/vkms/vkms_composer.c | 13 +++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
> b/drivers/gpu/drm/vkms/vkms_composer.c
> index d5585695c64d..b776185e5cb5 100644
> --- a/drivers/gpu/drm/vkms/vkms_composer.c
> +++ b/drivers/gpu/drm/vkms/vkms_composer.c
> @@ -75,6 +75,9 @@ static void blend(void *vaddr_dst, void *vaddr_src,
> int y_limit = y_src + h_dst;
> int x_limit = x_src + w_dst;
>
> + u8 *src, *dst;
> + u32 alpha, inv_alpha;
These could all live in a tighter scope.
Apart from that lgtm
Reviewed-by: Ville Syrjälä
> +
> for (i = y_src, i_dst = y_dst; i < y_limit; ++i) {
> for (j = x_src, j_dst = x_dst; j < x_limit; ++j) {
> offset_dst = dest_composer->offset
> @@ -84,8 +87,14 @@ static void blend(void *vaddr_dst, void *vaddr_src,
>+ (i * src_composer->pitch)
>+ (j * src_composer->cpp);
>
> - memcpy(vaddr_dst + offset_dst,
> -vaddr_src + offset_src, sizeof(u32));
> + src = vaddr_src + offset_src;
> + dst = vaddr_dst + offset_dst;
> + alpha = src[3] + 1;
> + inv_alpha = 256 - src[3];
> + dst[0] = (alpha * src[0] + inv_alpha * dst[0]) >> 8;
> + dst[1] = (alpha * src[1] + inv_alpha * dst[1]) >> 8;
> + dst[2] = (alpha * src[2] + inv_alpha * dst[2]) >> 8;
> + dst[3] = 0xff;
> }
> i_dst++;
> }
> --
> 2.20.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111481] AMD Navi GPU frequent freezes on both Manjaro/Ubuntu with kernel 5.3 and mesa 19.2 -git/llvm9
https://bugs.freedesktop.org/show_bug.cgi?id=111481 --- Comment #20 from Marko Popovic --- (In reply to Pierre-Eric Pelloux-Prayer from comment #19) > Thanks for the trace! > > Replaying the trace a few times is enough to reliably to reproduce the hang. > > Using AMD_DEBUG=nongg seems to prevent it so it could be a temporary > workaround until a proper fix is found. > Could you confirm this on your system? > > > > > > I am adding Rocket League crash output from apitrace. > > This trace file is very small (only one frame) and doesn't hang here. Thanks for the workaround! Here are my results: -AMD_DEBUG=nongg works to fix the Citra-related crash - It doesn't work to fix Rocket League related hang, that seems to be a completely different beast... the GPU hang happens as well but I don't know why, apparently apitrace doesn't provide any useful information as to why it happens. Now I will continue testing to see whether citra-related crash workaround also works for my desktop random freezes and hangs and will report back. I added AMD_DEBUG=nongg to my /etc/environment so it should be applied to desktop as well. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm: dw-hdmi-i2s: enable audio clock in audio_startup
On 02/09/2019 12:32, Jonas Karlman wrote:
> On 2019-09-02 11:42, Neil Armstrong wrote:
>> Hi,
>>
>> On 02/09/2019 05:54, Cheng-Yi Chiang wrote:
>>> In the designware databook, the sequence of enabling audio clock and
>>> setting format is not clearly specified.
>>> Currently, audio clock is enabled in the end of hw_param ops after
>>> setting format.
>>>
>>> On some monitors, there is a possibility that audio does not come out.
>>> Fix this by enabling audio clock in audio_startup ops
>>> before hw_param ops setting format.
>>>
>>> Signed-off-by: Cheng-Yi Chiang
>>> Reviewed-by: Douglas Anderson
>>> Reviewed-by: Jonas Karlman
>>> Tested-by: Douglas Anderson
>>> ---
>>> Changes from v1:
>>> 1. Move audio_startup to the front of audio_shutdown.
>>> 2. Fix the indentation of audio_startup equal sign using tab.
>>> 3. Rebase the patch on linux-next/master.
>>> 4. Add Reviewed-by and Tested-by fields from diand...@chromium.org.
>>> 5. Add Reviewed-by field from jo...@kwiboo.se.
>>>
>>> drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c | 9 +
>>> 1 file changed, 9 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
>>> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
>>> index 1d15cf9b6821..34d8e837555f 100644
>>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
>>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
>>> @@ -109,6 +109,14 @@ static int dw_hdmi_i2s_hw_params(struct device *dev,
>>> void *data,
>>> hdmi_write(audio, conf0, HDMI_AUD_CONF0);
>>> hdmi_write(audio, conf1, HDMI_AUD_CONF1);
>>>
>>> + return 0;
>>> +}
>>> +
>>> +static int dw_hdmi_i2s_audio_startup(struct device *dev, void *data)
>>> +{
>>> + struct dw_hdmi_i2s_audio_data *audio = data;
>>> + struct dw_hdmi *hdmi = audio->hdmi;
>>> +
>>> dw_hdmi_audio_enable(hdmi);
>>>
>>> return 0;
>>> @@ -153,6 +161,7 @@ static int dw_hdmi_i2s_get_dai_id(struct
>>> snd_soc_component *component,
>>>
>>> static struct hdmi_codec_ops dw_hdmi_i2s_ops = {
>>> .hw_params = dw_hdmi_i2s_hw_params,
>>> + .audio_startup = dw_hdmi_i2s_audio_startup,
>>> .audio_shutdown = dw_hdmi_i2s_audio_shutdown,
>>> .get_eld= dw_hdmi_i2s_get_eld,
>>> .get_dai_id = dw_hdmi_i2s_get_dai_id,
>>>
>> Looks sane, Jonas should I apply it now it's rebased ?
>
> Sure, looks sane and compiles without warnings on my build host.
Thx, Applied to drm-misc-next
Neil
>
> Regards,
> Jonas
>
>>
>> Neil
>
[PATCH] habanalabs: fix semicolon.cocci warnings
From: kbuild test robot
drivers/misc/habanalabs/device.c:552:2-3: Unneeded semicolon
Remove unneeded semicolon.
Generated by: scripts/coccinelle/misc/semicolon.cocci
Fixes: 127d20c1da61 ("habanalabs: add uapi to retrieve device utilization")
Signed-off-by: kbuild test robot
---
tree: git://people.freedesktop.org/~gabbayo/linux habanalabs-next
head: f3d40ffeb89564d31295fb01bc04929661e2bbcf
commit: 127d20c1da61045a7903c5d76afe14b3a3a097c2 [25/29] habanalabs: add uapi
to retrieve device utilization
device.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/misc/habanalabs/device.c
+++ b/drivers/misc/habanalabs/device.c
@@ -549,7 +549,7 @@ uint32_t hl_device_utilization(struct hl
ts = >idle_busy_ts_arr[last_index];
overlap_cnt++;
- };
+ }
return DIV_ROUND_UP(((total_busy_time_us / USEC_PER_MSEC) * 100),
period_ms);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[gabbayo:habanalabs-next 25/29] drivers/misc/habanalabs/device.c:552:2-3: Unneeded semicolon
tree: git://people.freedesktop.org/~gabbayo/linux habanalabs-next head: f3d40ffeb89564d31295fb01bc04929661e2bbcf commit: 127d20c1da61045a7903c5d76afe14b3a3a097c2 [25/29] habanalabs: add uapi to retrieve device utilization If you fix the issue, kindly add following tag Reported-by: kbuild test robot coccinelle warnings: (new ones prefixed by >>) >> drivers/misc/habanalabs/device.c:552:2-3: Unneeded semicolon Please review and possibly fold the followup patch. --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111481] AMD Navi GPU frequent freezes on both Manjaro/Ubuntu with kernel 5.3 and mesa 19.2 -git/llvm9
https://bugs.freedesktop.org/show_bug.cgi?id=111481 --- Comment #19 from Pierre-Eric Pelloux-Prayer --- (In reply to Marko Popovic from comment #17) > (In reply to Pierre-Eric Pelloux-Prayer from comment #15) > > (In reply to Marko Popovic from comment #14) > > > > > > Yes, always happens at the same place with Citra emulator > > > > Could you capture a trace of the problem (using Apitrace or Renderdoc)? > > > > This would be very helpful to fix it. > > I added reproduced Citra crash recorded by using command: > apitrace trace ./citra-qt > > I hope this is correct, if you need anything else or done differently please > just let me know! Thanks for the trace! Replaying the trace a few times is enough to reliably to reproduce the hang. Using AMD_DEBUG=nongg seems to prevent it so it could be a temporary workaround until a proper fix is found. Could you confirm this on your system? > > I am adding Rocket League crash output from apitrace. This trace file is very small (only one frame) and doesn't hang here. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm/edid: no CEA extension is not an error
On Fri, Aug 30, 2019 at 06:16:52PM +0200, Jean Delvare wrote:
> It is fine for displays without audio functionality to not implement
> CEA extension in their EDID. Do not return an error in that case,
> instead return 0 as if there was a CEA extension with no audio or
> speaker block.
>
> This fixes half of bug fdo#107825:
> https://bugs.freedesktop.org/show_bug.cgi?id=107825
>
> Signed-off-by: Jean Delvare
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Sean Paul
> Cc: David Airlie
> Cc: Daniel Vetter
> ---
> drivers/gpu/drm/drm_edid.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> --- linux-5.2.orig/drivers/gpu/drm/drm_edid.c 2019-08-30 17:57:38.10995
> +0200
> +++ linux-5.2/drivers/gpu/drm/drm_edid.c 2019-08-30 18:04:36.840333834
> +0200
> @@ -4130,7 +4130,7 @@ int drm_edid_to_sad(struct edid *edid, s
> cea = drm_find_cea_extension(edid);
> if (!cea) {
> DRM_DEBUG_KMS("SAD: no CEA Extension found\n");
> - return -ENOENT;
> + return 0;
> }
Seems reasonable. Maybe the cea_revision<3 branches should alse return 0?
Either way
Reviewed-by: Ville Syrjälä
>
> if (cea_revision(cea) < 3) {
> @@ -4191,7 +4191,7 @@ int drm_edid_to_speaker_allocation(struc
> cea = drm_find_cea_extension(edid);
> if (!cea) {
> DRM_DEBUG_KMS("SAD: no CEA Extension found\n");
> - return -ENOENT;
> + return 0;
> }
>
> if (cea_revision(cea) < 3) {
>
> --
> Jean Delvare
> SUSE L3 Support
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/panel: Add DT bindings for Sony ACX424AKP
On Mon, Sep 2, 2019 at 11:35 AM Thierry Reding wrote: > > + dsi-command-mode: > > + type: boolean > > + description: > > + If this is specified, the panel will be used in command > > + mode instead of video mode. > > I'm not sure there's concensus on this one yet. I think so far the > driver decides which mode to use the panel in. Technically this falls > into the category of configuration, so it doesn't really belong in the > DT. The way we've used DT is for a bit of both hardware description and configuration I'd say, but I'm no authority on the subject. > I vaguely recall from discussions I've had on this subject that there's > usually no reason to do video mode if you can do command mode because > command mode is more power efficient. This was a long time ago, so I may > be misremembering. Perhaps you have different information on this? No idea. I was under the impression that video mode was preferred but I have no idea why. Yours, Linus Walleij ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 15/21] drm/dp: Add helper to get post-cursor adjustments
From: Thierry Reding
If the transmitter supports pre-emphasis post cursor2 the sink will
request adjustments in a similar way to how it requests adjustments to
the voltage swing and pre-emphasis settings.
Add a helper to extract these adjustments on a per-lane basis from the
DPCD link status.
Reviewed-by: Philipp Zabel
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_dp_helper.c | 10 ++
include/drm/drm_dp_helper.h | 10 ++
2 files changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 1fb3c27cd012..f1f3705fade9 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -120,6 +120,16 @@ u8 drm_dp_get_adjust_request_pre_emphasis(const u8
link_status[DP_LINK_STATUS_SI
}
EXPORT_SYMBOL(drm_dp_get_adjust_request_pre_emphasis);
+u8 drm_dp_get_adjust_request_post_cursor(const u8
link_status[DP_LINK_STATUS_SIZE],
+unsigned int lane)
+{
+ unsigned int offset = DP_ADJUST_REQUEST_POST_CURSOR2;
+ u8 value = dp_link_status(link_status, offset);
+
+ return (value >> (lane << 1)) & 0x3;
+}
+EXPORT_SYMBOL(drm_dp_get_adjust_request_post_cursor);
+
void drm_dp_link_train_clock_recovery_delay(const u8
dpcd[DP_RECEIVER_CAP_SIZE])
{
unsigned int rd_interval = drm_dp_aux_rd_interval(dpcd);
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index e28b0941a8be..5d262a453878 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -566,6 +566,14 @@
# define DP_ADJUST_PRE_EMPHASIS_LANE1_SHIFT 6
#define DP_ADJUST_REQUEST_POST_CURSOR2 0x20c
+# define DP_ADJUST_POST_CURSOR2_LANE0_MASK 0x03
+# define DP_ADJUST_POST_CURSOR2_LANE0_SHIFT 0
+# define DP_ADJUST_POST_CURSOR2_LANE1_MASK 0x0c
+# define DP_ADJUST_POST_CURSOR2_LANE1_SHIFT 2
+# define DP_ADJUST_POST_CURSOR2_LANE2_MASK 0x30
+# define DP_ADJUST_POST_CURSOR2_LANE2_SHIFT 4
+# define DP_ADJUST_POST_CURSOR2_LANE3_MASK 0xc0
+# define DP_ADJUST_POST_CURSOR2_LANE3_SHIFT 6
#define DP_TEST_REQUEST0x218
# define DP_TEST_LINK_TRAINING (1 << 0)
@@ -1053,6 +1061,8 @@ u8 drm_dp_get_adjust_request_voltage(const u8
link_status[DP_LINK_STATUS_SIZE],
int lane);
u8 drm_dp_get_adjust_request_pre_emphasis(const u8
link_status[DP_LINK_STATUS_SIZE],
int lane);
+u8 drm_dp_get_adjust_request_post_cursor(const u8
link_status[DP_LINK_STATUS_SIZE],
+unsigned int lane);
#define DP_BRANCH_OUI_HEADER_SIZE 0xc
#define DP_RECEIVER_CAP_SIZE 0xf
--
2.22.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 01/21] drm/dp: Sort includes alphabetically
From: Thierry Reding Keeping the list sorted alphabetically makes it much easier to determine where to add new includes. Signed-off-by: Thierry Reding --- include/drm/drm_dp_helper.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index 8364502f92cf..114261158b73 100644 --- a/include/drm/drm_dp_helper.h +++ b/include/drm/drm_dp_helper.h @@ -23,9 +23,9 @@ #ifndef _DRM_DP_HELPER_H_ #define _DRM_DP_HELPER_H_ -#include -#include #include +#include +#include /* * Unless otherwise noted, all values are from the DP 1.1a spec. Note that -- 2.22.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 12/21] drm/dp: Read AUX read interval from DPCD
From: Thierry Reding
Store the AUX read interval from DPCD, so that it can be used to wait
for the durations given in the specification during link training.
v2: use USEC_PER_MSEC instead of MSEC_PER_SEC for clarity
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_dp_helper.c | 3 +++
include/drm/drm_dp_helper.h | 35 +
2 files changed, 38 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 5b36e8e39ca7..4112570dbe67 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -382,6 +382,7 @@ static void drm_dp_link_reset(struct drm_dp_link *link)
link->max_lanes = 0;
drm_dp_link_caps_reset(>caps);
+ link->aux_rd_interval = 0;
link->edp = 0;
link->rate = 0;
@@ -435,6 +436,8 @@ int drm_dp_link_probe(struct drm_dp_aux *aux, struct
drm_dp_link *link)
link->edp = edp_revs[value];
}
+ link->aux_rd_interval = drm_dp_aux_rd_interval(values);
+
link->rate = link->max_rate;
link->lanes = link->max_lanes;
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 13c50e905205..e28b0941a8be 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -25,8 +25,11 @@
#include
#include
+#include
#include
+#include
+
/*
* Unless otherwise noted, all values are from the DP 1.1a spec. Note that
* DP and DPCD versions are independent. Differences from 1.0 are not noted,
@@ -1229,6 +1232,36 @@ drm_dp_alternate_scrambler_reset_cap(const u8
dpcd[DP_RECEIVER_CAP_SIZE])
DP_ALTERNATE_SCRAMBLER_RESET_CAP;
}
+/**
+ * drm_dp_read_aux_interval() - read the AUX read interval from the DPCD
+ * @dpcd: receiver capacity buffer
+ *
+ * Reads the AUX read interval (in microseconds) from the DPCD. Note that the
+ * TRAINING_AUX_RD_INTERVAL stores the value in units of 4 milliseconds. If no
+ * read interval is specified and for DPCD v1.4 and later, the read interval
+ * is always 100 microseconds.
+ *
+ * Returns:
+ * The read AUX interval in microseconds.
+ */
+static inline unsigned int
+drm_dp_aux_rd_interval(const u8 dpcd[DP_RECEIVER_CAP_SIZE])
+{
+ unsigned int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
+ DP_TRAINING_AUX_RD_MASK;
+
+ if (rd_interval > 4)
+ DRM_DEBUG_KMS("AUX interval %u, out of range (max: 4)\n",
+ rd_interval);
+
+ if (rd_interval > 0 && dpcd[DP_DPCD_REV] < DP_DPCD_REV_14)
+ rd_interval *= 4 * USEC_PER_MSEC;
+ else
+ rd_interval = 100;
+
+ return rd_interval;
+}
+
/*
* DisplayPort AUX channel
*/
@@ -1405,6 +1438,7 @@ void drm_dp_link_caps_copy(struct drm_dp_link_caps *dest,
* @max_rate: maximum clock rate supported on the link
* @max_lanes: maximum number of lanes supported on the link
* @caps: capabilities supported on the link (see _dp_link_caps)
+ * @aux_rd_interval: AUX read interval to use for training (in microseconds)
* @edp: eDP revision (0x11: eDP 1.1, 0x12: eDP 1.2, ...)
* @rate: currently configured link rate
* @lanes: currently configured number of lanes
@@ -1415,6 +1449,7 @@ struct drm_dp_link {
unsigned int max_lanes;
struct drm_dp_link_caps caps;
+ unsigned int aux_rd_interval;
unsigned char edp;
unsigned int rate;
--
2.22.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 16/21] drm/dp: Set channel coding on link configuration
From: Thierry Reding
Make use of ANSI 8B/10B channel coding if the DisplayPort sink supports
it.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_dp_helper.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index f1f3705fade9..f51a5595ebc0 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -519,7 +519,7 @@ EXPORT_SYMBOL(drm_dp_link_power_down);
*/
int drm_dp_link_configure(struct drm_dp_aux *aux, struct drm_dp_link *link)
{
- u8 values[2];
+ u8 values[2], value = 0;
int err;
values[0] = drm_dp_link_rate_to_bw_code(link->rate);
@@ -532,6 +532,13 @@ int drm_dp_link_configure(struct drm_dp_aux *aux, struct
drm_dp_link *link)
if (err < 0)
return err;
+ if (link->caps.channel_coding)
+ value = DP_SET_ANSI_8B10B;
+
+ err = drm_dp_dpcd_writeb(aux, DP_MAIN_LINK_CHANNEL_CODING_SET, value);
+ if (err < 0)
+ return err;
+
return 0;
}
EXPORT_SYMBOL(drm_dp_link_configure);
--
2.22.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 02/21] drm/dp: Add missing kerneldoc for struct drm_dp_link
From: Thierry Reding
The drm_dp_link structure tracks capabilities on the DP link. Add some
kerneldoc to explain what each of its fields means.
Signed-off-by: Thierry Reding
---
include/drm/drm_dp_helper.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 114261158b73..935f331e6e72 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -1358,6 +1358,13 @@ int drm_dp_dpcd_read_link_status(struct drm_dp_aux *aux,
*/
#define DP_LINK_CAP_ENHANCED_FRAMING (1 << 0)
+/**
+ * struct drm_dp_link - DP link capabilities
+ * @revision: DP specification revision supported on the link
+ * @rate: maximum clock rate supported on the link
+ * @num_lanes: maximum number of lanes supported on the link
+ * @capabilities: bitmask of capabilities supported on the link
+ */
struct drm_dp_link {
unsigned char revision;
unsigned int rate;
--
2.22.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 04/21] drm/dp: Track link capabilities alongside settings
From: Thierry Reding
Store capabilities in max_* fields and add separate fields for the
currently selected settings.
Cc: Rob Clark
Reviewed-by: Andrzej Hajda
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/bridge/tc358767.c | 14 ++---
drivers/gpu/drm/drm_dp_helper.c| 16 ++-
drivers/gpu/drm/msm/edp/edp_ctrl.c | 8
drivers/gpu/drm/rockchip/cdn-dp-core.c | 8
drivers/gpu/drm/rockchip/cdn-dp-reg.c | 13 ++--
drivers/gpu/drm/tegra/dpaux.c | 8
drivers/gpu/drm/tegra/sor.c| 28 +-
include/drm/drm_dp_helper.h| 15 +-
8 files changed, 60 insertions(+), 50 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
b/drivers/gpu/drm/bridge/tc358767.c
index cebc8e620820..733fca7d3829 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -437,7 +437,7 @@ static u32 tc_srcctrl(struct tc_data *tc)
reg |= DP0_SRCCTRL_SCRMBLDIS; /* Scrambler Disabled */
if (tc->link.spread)
reg |= DP0_SRCCTRL_SSCG;/* Spread Spectrum Enable */
- if (tc->link.base.num_lanes == 2)
+ if (tc->link.base.lanes == 2)
reg |= DP0_SRCCTRL_LANES_2; /* Two Main Channel Lanes */
if (tc->link.base.rate != 162000)
reg |= DP0_SRCCTRL_BW27;/* 2.7 Gbps link */
@@ -674,9 +674,9 @@ static int tc_get_display_props(struct tc_data *tc)
tc->link.base.rate = 27;
}
- if (tc->link.base.num_lanes > 2) {
+ if (tc->link.base.lanes > 2) {
dev_dbg(tc->dev, "Falling to 2 lanes\n");
- tc->link.base.num_lanes = 2;
+ tc->link.base.lanes = 2;
}
ret = drm_dp_dpcd_readb(>aux, DP_MAX_DOWNSPREAD, );
@@ -698,7 +698,7 @@ static int tc_get_display_props(struct tc_data *tc)
dev_dbg(tc->dev, "DPCD rev: %d.%d, rate: %s, lanes: %d, framing: %s\n",
tc->link.base.revision >> 4, tc->link.base.revision & 0x0f,
(tc->link.base.rate == 162000) ? "1.62Gbps" : "2.7Gbps",
- tc->link.base.num_lanes,
+ tc->link.base.lanes,
(tc->link.base.capabilities & DP_LINK_CAP_ENHANCED_FRAMING) ?
"enhanced" : "non-enhanced");
dev_dbg(tc->dev, "Downspread: %s, scrambler: %s\n",
@@ -906,7 +906,7 @@ static int tc_main_link_enable(struct tc_data *tc)
/* Setup Main Link */
dp_phy_ctrl = BGREN | PWR_SW_EN | PHY_A0_EN | PHY_M0_EN;
- if (tc->link.base.num_lanes == 2)
+ if (tc->link.base.lanes == 2)
dp_phy_ctrl |= PHY_2LANE;
ret = regmap_write(tc->regmap, DP_PHY_CTRL, dp_phy_ctrl);
@@ -1094,7 +1094,7 @@ static int tc_main_link_enable(struct tc_data *tc)
ret = -ENODEV;
}
- if (tc->link.base.num_lanes == 2) {
+ if (tc->link.base.lanes == 2) {
value = (tmp[0] >> 4) & DP_CHANNEL_EQ_BITS;
if (value != DP_CHANNEL_EQ_BITS) {
@@ -1291,7 +1291,7 @@ static enum drm_mode_status tc_mode_valid(struct
drm_bridge *bridge,
return MODE_CLOCK_HIGH;
req = mode->clock * bits_per_pixel / 8;
- avail = tc->link.base.num_lanes * tc->link.base.rate;
+ avail = tc->link.base.lanes * tc->link.base.rate;
if (req > avail)
return MODE_BAD;
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index f5af71ec1b7d..365de63a02fb 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -342,9 +342,12 @@ static void drm_dp_link_reset(struct drm_dp_link *link)
return;
link->revision = 0;
- link->rate = 0;
- link->num_lanes = 0;
+ link->max_rate = 0;
+ link->max_lanes = 0;
link->capabilities = 0;
+
+ link->rate = 0;
+ link->lanes = 0;
}
/**
@@ -370,12 +373,15 @@ int drm_dp_link_probe(struct drm_dp_aux *aux, struct
drm_dp_link *link)
return err;
link->revision = values[0];
- link->rate = drm_dp_bw_code_to_link_rate(values[1]);
- link->num_lanes = values[2] & DP_MAX_LANE_COUNT_MASK;
+ link->max_rate = drm_dp_bw_code_to_link_rate(values[1]);
+ link->max_lanes = values[2] & DP_MAX_LANE_COUNT_MASK;
if (values[2] & DP_ENHANCED_FRAME_CAP)
link->capabilities |= DP_LINK_CAP_ENHANCED_FRAMING;
+ link->rate = link->max_rate;
+ link->lanes = link->max_lanes;
+
return 0;
}
EXPORT_SYMBOL(drm_dp_link_probe);
@@ -462,7 +468,7 @@ int drm_dp_link_configure(struct drm_dp_aux *aux, struct
drm_dp_link *link)
int err;
values[0] = drm_dp_link_rate_to_bw_code(link->rate);
- values[1] = link->num_lanes;
+ values[1] = link->lanes;
if (link->capabilities & DP_LINK_CAP_ENHANCED_FRAMING)
values[1] |=
[PATCH v2 06/21] drm/dp: Probe link using existing parsing helpers
From: Thierry Reding
Use existing parsing helpers to probe a DisplayPort link.
Reviewed-by: Philipp Zabel
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_dp_helper.c | 29 ++---
include/drm/drm_dp_helper.h | 2 ++
2 files changed, 24 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index bdf999bb6cfa..cdf49e8d5e3a 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -320,6 +320,22 @@ ssize_t drm_dp_dpcd_write(struct drm_dp_aux *aux, unsigned
int offset,
}
EXPORT_SYMBOL(drm_dp_dpcd_write);
+/**
+ * drm_dp_dpcd_read_link_caps() - read DPCD link capabilities
+ * @aux: DisplayPort AUX channel
+ * @caps: buffer to store the link capabilities in
+ *
+ * Returns:
+ * The number of bytes transferred on success or a negative error code on
+ * failure.
+ */
+int drm_dp_dpcd_read_link_caps(struct drm_dp_aux *aux,
+ u8 caps[DP_RECEIVER_CAP_SIZE])
+{
+ return drm_dp_dpcd_read(aux, DP_DPCD_REV, caps, DP_RECEIVER_CAP_SIZE);
+}
+EXPORT_SYMBOL(drm_dp_dpcd_read_link_caps);
+
/**
* drm_dp_dpcd_read_link_status() - read DPCD link status (bytes 0x202-0x207)
* @aux: DisplayPort AUX channel
@@ -376,21 +392,20 @@ static void drm_dp_link_reset(struct drm_dp_link *link)
*/
int drm_dp_link_probe(struct drm_dp_aux *aux, struct drm_dp_link *link)
{
- u8 values[3];
+ u8 values[DP_RECEIVER_CAP_SIZE];
int err;
drm_dp_link_reset(link);
- err = drm_dp_dpcd_read(aux, DP_DPCD_REV, values, sizeof(values));
+ err = drm_dp_dpcd_read_link_caps(aux, values);
if (err < 0)
return err;
- link->revision = values[0];
- link->max_rate = drm_dp_bw_code_to_link_rate(values[1]);
- link->max_lanes = values[2] & DP_MAX_LANE_COUNT_MASK;
+ link->revision = values[DP_DPCD_REV];
+ link->max_rate = drm_dp_max_link_rate(values);
+ link->max_lanes = drm_dp_max_lane_count(values);
- if (values[2] & DP_ENHANCED_FRAME_CAP)
- link->caps.enhanced_framing = true;
+ link->caps.enhanced_framing = drm_dp_enhanced_frame_cap(values);
link->rate = link->max_rate;
link->lanes = link->max_lanes;
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 2759f8d7e90d..60bb030c858d 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -1350,6 +1350,8 @@ static inline ssize_t drm_dp_dpcd_writeb(struct
drm_dp_aux *aux,
return drm_dp_dpcd_write(aux, offset, , 1);
}
+int drm_dp_dpcd_read_link_caps(struct drm_dp_aux *aux,
+ u8 caps[DP_RECEIVER_CAP_SIZE]);
int drm_dp_dpcd_read_link_status(struct drm_dp_aux *aux,
u8 status[DP_LINK_STATUS_SIZE]);
--
2.22.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 17/21] drm/dp: Enable alternate scrambler reset when supported
From: Thierry Reding
If the sink is eDP and supports the alternate scrambler reset, enable
it.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_dp_helper.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index f51a5595ebc0..85956f3a24e3 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -539,6 +539,13 @@ int drm_dp_link_configure(struct drm_dp_aux *aux, struct
drm_dp_link *link)
if (err < 0)
return err;
+ if (link->caps.alternate_scrambler_reset) {
+ err = drm_dp_dpcd_writeb(aux, DP_EDP_CONFIGURATION_SET,
+DP_ALTERNATE_SCRAMBLER_RESET_ENABLE);
+ if (err < 0)
+ return err;
+ }
+
return 0;
}
EXPORT_SYMBOL(drm_dp_link_configure);
--
2.22.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 09/21] drm/dp: Read channel coding capability from sink
From: Thierry Reding
Parse from the sink capabilities whether or not it supports ANSI 8B/10B
channel coding as specified in ANSI X3.230-1994, clause 11.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_dp_helper.c | 3 +++
include/drm/drm_dp_helper.h | 9 +
2 files changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index c47d78973c1e..1c238196c8b4 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -357,6 +357,7 @@ static void drm_dp_link_caps_reset(struct drm_dp_link_caps
*caps)
caps->enhanced_framing = false;
caps->tps3_supported = false;
caps->fast_training = false;
+ caps->channel_coding = false;
}
void drm_dp_link_caps_copy(struct drm_dp_link_caps *dest,
@@ -365,6 +366,7 @@ void drm_dp_link_caps_copy(struct drm_dp_link_caps *dest,
dest->enhanced_framing = src->enhanced_framing;
dest->tps3_supported = src->tps3_supported;
dest->fast_training = src->fast_training;
+ dest->channel_coding = src->channel_coding;
}
EXPORT_SYMBOL(drm_dp_link_caps_copy);
@@ -412,6 +414,7 @@ int drm_dp_link_probe(struct drm_dp_aux *aux, struct
drm_dp_link *link)
link->caps.enhanced_framing = drm_dp_enhanced_frame_cap(values);
link->caps.tps3_supported = drm_dp_tps3_supported(values);
link->caps.fast_training = drm_dp_fast_training_cap(values);
+ link->caps.channel_coding = drm_dp_channel_coding_supported(values);
link->rate = link->max_rate;
link->lanes = link->max_lanes;
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index ab98ebb302a9..d144d3a54dbc 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -95,6 +95,7 @@
# define DP_DETAILED_CAP_INFO_AVAILABLE(1 << 4) /* DPI */
#define DP_MAIN_LINK_CHANNEL_CODING 0x006
+# define DP_CAP_ANSI_8B10B (1 << 0)
#define DP_DOWN_STREAM_PORT_COUNT 0x007
# define DP_PORT_COUNT_MASK0x0f
@@ -1215,6 +1216,12 @@ drm_dp_sink_supports_fec(const u8 fec_capable)
return fec_capable & DP_FEC_CAPABLE;
}
+static inline bool
+drm_dp_channel_coding_supported(const u8 dpcd[DP_RECEIVER_CAP_SIZE])
+{
+ return dpcd[DP_MAIN_LINK_CHANNEL_CODING] & DP_CAP_ANSI_8B10B;
+}
+
/*
* DisplayPort AUX channel
*/
@@ -1371,11 +1378,13 @@ int drm_dp_dpcd_read_link_status(struct drm_dp_aux *aux,
* @enhanced_framing: enhanced framing capability (mandatory as of DP 1.2)
* @tps3_supported: training pattern sequence 3 supported for equalization
* @fast_training: AUX CH handshake not required for link training
+ * @channel_coding: ANSI 8B/10B channel coding capability
*/
struct drm_dp_link_caps {
bool enhanced_framing;
bool tps3_supported;
bool fast_training;
+ bool channel_coding;
};
void drm_dp_link_caps_copy(struct drm_dp_link_caps *dest,
--
2.22.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
