[v5 1/6] i915/dp/fec: Cache the FEC_CAPABLE DPCD register
Similar to DSC DPCD registers, let us cache
FEC_CAPABLE register to avoid using stale
values. With this we can avoid aux reads
everytime and instead read the cached values.
v2: Avoid using memset and array for a single
field. (Manasi,Jani)
v3: Print FEC CAPABILITY value. (Manasi)
Suggested-by: Jani Nikula
Cc: dri-devel@lists.freedesktop.org
Cc: Jani Nikula
Cc: Ville Syrjala
Cc: Manasi Navare
Signed-off-by: Anusha Srivatsa
Reviewed-by: Manasi Navare
---
drivers/gpu/drm/i915/intel_dp.c | 12
drivers/gpu/drm/i915/intel_drv.h | 1 +
2 files changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 5a638503e36a..253e063e23b0 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4201,6 +4201,9 @@ static void intel_dp_get_dsc_sink_cap(struct intel_dp
*intel_dp)
*/
memset(intel_dp->dsc_dpcd, 0, sizeof(intel_dp->dsc_dpcd));
+ /* Clear fec_capable to avoid using stale values */
+ intel_dp->fec_capable = 0;
+
/* Cache the DSC DPCD if eDP or DP rev >= 1.4 */
if (intel_dp->dpcd[DP_DPCD_REV] >= 0x14 ||
intel_dp->edp_dpcd[0] >= DP_EDP_14) {
@@ -4213,6 +4216,15 @@ static void intel_dp_get_dsc_sink_cap(struct intel_dp
*intel_dp)
DRM_DEBUG_KMS("DSC DPCD: %*ph\n",
(int)sizeof(intel_dp->dsc_dpcd),
intel_dp->dsc_dpcd);
+ /* FEC is supported only on DP 1.4 */
+ if (!intel_dp_is_edp(intel_dp)) {
+ if (drm_dp_dpcd_readb(_dp->aux, DP_FEC_CAPABILITY,
+ _dp->fec_capable) < 0)
+ DRM_ERROR("Failed to read FEC DPCD register\n");
+
+ DRM_DEBUG_KMS("FEC CAPABILITY: %x\n",
+ intel_dp->fec_capable);
+ }
}
}
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 16bbc3768e02..9a94c6544bf5 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1119,6 +1119,7 @@ struct intel_dp {
uint8_t downstream_ports[DP_MAX_DOWNSTREAM_PORTS];
uint8_t edp_dpcd[EDP_DISPLAY_CTL_CAP_SIZE];
u8 dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE];
+ u8 fec_capable;
/* source rates */
int num_source_rates;
const int *source_rates;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[v5 3/6] i915/dp/fec: Add fec_enable to the crtc state.
For DP 1.4 and above, Display Stream compression can be
enabled only if Forward Error Correctin can be performed.
Add a crtc state for FEC. Currently, the state
is determined by platform, DP and DSC being
enabled. Moving forward we can use the state
to have error correction on other scenarios too
if needed.
v2:
- Control compression_enable with the fec_enable
parameter in crtc state and with intel_dp_supports_fec()
(Ville)
- intel_dp_can_fec()/intel_dp_supports_fec()(manasi)
v3: Check for FEC support along with setting crtc state.
Suggested-by: Ville Syrjala
Cc: dri-devel@lists.freedesktop.org
Cc: Ville Syrjala
Cc: Jani Nikula
Cc: Manasi Navare
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/intel_dp.c | 26 +-
drivers/gpu/drm/i915/intel_drv.h | 3 +++
2 files changed, 28 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 253e063e23b0..6f73923b229f 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -680,7 +680,7 @@ intel_dp_mode_valid(struct drm_connector *connector,
dsc_slice_count =
drm_dp_dsc_sink_max_slice_count(intel_dp->dsc_dpcd,
true);
- } else {
+ } else if (drm_dp_sink_supports_fec(intel_dp->fec_capable)) {
dsc_max_output_bpp =
intel_dp_dsc_get_output_bpp(max_link_clock,
max_lanes,
@@ -2044,6 +2044,21 @@ intel_dp_compute_link_config_fast(struct intel_dp
*intel_dp,
return false;
}
+static bool intel_dp_source_supports_fec(struct intel_dp *intel_dp)
+{
+ struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
+ struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
+ enum port port = dig_port->base.port;
+
+ return INTEL_GEN(dev_priv) >= 11 && port != PORT_A;
+}
+
+static bool intel_dp_supports_fec(struct intel_dp *intel_dp,
+ struct intel_crtc_state *pipe_config)
+{
+ return intel_dp_source_supports_fec(intel_dp) &&
+ drm_dp_sink_supports_fec(intel_dp->fec_capable);
+}
static bool intel_dp_dsc_compute_config(struct intel_dp *intel_dp,
struct intel_crtc_state *pipe_config,
struct link_config_limits *limits)
@@ -2055,6 +2070,8 @@ static bool intel_dp_dsc_compute_config(struct intel_dp
*intel_dp,
u16 dsc_max_output_bpp = 0;
u8 dsc_dp_slice_count = 0;
+ pipe_config->fec_enable = !intel_dp_is_edp(intel_dp);
+
if (INTEL_GEN(dev_priv) < 10 ||
!drm_dp_sink_supports_dsc(intel_dp->dsc_dpcd))
return false;
@@ -2063,6 +2080,13 @@ static bool intel_dp_dsc_compute_config(struct intel_dp
*intel_dp,
if (pipe == PIPE_A && !intel_dp_is_edp(intel_dp))
return false;
+ /* DSC not supported if external DP sink does not support FEC */
+ if (pipe_config->fec_enable && !intel_dp_supports_fec(intel_dp,
pipe_config)) {
+ DRM_DEBUG_KMS("Sink does not support Forward Error Correction,
disabling Display Compression\n");
+ pipe_config->dsc_params.compression_enable = false;
+ return false;
+ }
+
/* DSC not supported for DSC sink BPC < 8 */
if (limits->max_bpp < 3 * DP_DSC_MIN_SUPPORTED_BPC) {
DRM_DEBUG_KMS("No DSC support for less than 8bpc\n");
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 9a94c6544bf5..9f701463219b 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -940,6 +940,9 @@ struct intel_crtc_state {
u8 slice_count;
} dsc_params;
struct drm_dsc_config dp_dsc_cfg;
+
+ /* Forward Error correction State */
+ bool fec_enable;
};
struct intel_crtc {
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[v5 6/6] drm/i915/fec: Disable FEC state.
Set the suitable bits in DP_TP_CTL to stop
bit correction when DSC is disabled.
v2:
- rebased.
- Add additional check for compression state. (Gaurav)
v3: rebased.
v4:
- Move the code to the proper spot according to spec (Ville)
- Use proper checks (manasi)
v5: Remove unnecessary checks (Ville)
Cc: dri-devel@lists.freedesktop.org
Cc: Gaurav K Singh
Cc: Jani Nikula
Cc: Ville Syrjala
Cc: Manasi Navare
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/intel_ddi.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 807edba4cd6f..5e915c771953 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2925,6 +2925,22 @@ static void intel_ddi_enable_fec(struct intel_encoder
*encoder,
DRM_ERROR("Timed out waiting for FEC Enable Status\n");
}
+static void intel_ddi_disable_fec_state(struct intel_encoder *encoder,
+ const struct intel_crtc_state
*crtc_state)
+{
+ struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+ enum port port = encoder->port;
+ u32 val;
+
+ if (!crtc_state->fec_enable)
+ return;
+
+ val = I915_READ(DP_TP_CTL(port));
+ val &= ~DP_TP_CTL_FEC_ENABLE;
+ I915_WRITE(DP_TP_CTL(port), val);
+ POSTING_READ(DP_TP_CTL(port));
+}
+
static void intel_ddi_pre_enable_dp(struct intel_encoder *encoder,
const struct intel_crtc_state *crtc_state,
const struct drm_connector_state
*conn_state)
@@ -3063,7 +3079,9 @@ static void intel_ddi_pre_enable(struct intel_encoder
*encoder,
static void intel_disable_ddi_buf(struct intel_encoder *encoder)
{
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+ struct intel_crtc_state *crtc_state;
enum port port = encoder->port;
+
bool wait = false;
u32 val;
@@ -3079,6 +3097,9 @@ static void intel_disable_ddi_buf(struct intel_encoder
*encoder)
val |= DP_TP_CTL_LINK_TRAIN_PAT1;
I915_WRITE(DP_TP_CTL(port), val);
+ /* Disable FEC in DP Sink */
+ intel_ddi_disable_fec_state(encoder, crtc_state);
+
if (wait)
intel_wait_ddi_buf_idle(dev_priv, port);
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[v5 5/6] i915/dp/fec: Configure the Forward Error Correction bits.
If FEC is supported, the corresponding
DP_TP_CTL register bits have to be configured.
The driver has to program the FEC_ENABLE in DP_TP_CTL[30] register
and wait till FEC_STATUS in DP_TP_CTL[28] is 1.
Also add the warn message to make sure that the control
register is already active while enabling FEC.
v2:
- Change commit message. Configure fec state after
link training (Manasi, Gaurav)
- Remove redundent checks (Manasi)
- Remove the registers that get added automagically (Anusha)
v3: s/intel_dp_set_fec_state()/intel_dp_enable_fec_state() (Gaurav)
v4: rebased.
v5:
- Move the code to the proper spot, according to spec.(Ville)
- Use fec state as a check too.
v6: Pass intel_encoder, instead of intel_dp. (Ville)
Cc: dri-devel@lists.freedesktop.org
Cc: Gaurav K Singh
Cc: Jani Nikula
Cc: Ville Syrjala
Cc: Manasi Navare
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/i915_reg.h | 2 ++
drivers/gpu/drm/i915/intel_ddi.c | 24
2 files changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index e85f53cb9cdd..8b1753939299 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -9134,6 +9134,7 @@ enum skl_power_gate {
#define _DP_TP_CTL_B 0x64140
#define DP_TP_CTL(port) _MMIO_PORT(port, _DP_TP_CTL_A, _DP_TP_CTL_B)
#define DP_TP_CTL_ENABLE (1 << 31)
+#define DP_TP_CTL_FEC_ENABLE (1 << 30)
#define DP_TP_CTL_MODE_SST(0 << 27)
#define DP_TP_CTL_MODE_MST(1 << 27)
#define DP_TP_CTL_FORCE_ACT (1 << 25)
@@ -9152,6 +9153,7 @@ enum skl_power_gate {
#define _DP_TP_STATUS_A0x64044
#define _DP_TP_STATUS_B0x64144
#define DP_TP_STATUS(port) _MMIO_PORT(port, _DP_TP_STATUS_A, _DP_TP_STATUS_B)
+#define DP_TP_STATUS_FEC_ENABLE_LIVE (1 << 28)
#define DP_TP_STATUS_IDLE_DONE(1 << 25)
#define DP_TP_STATUS_ACT_SENT (1 << 24)
#define DP_TP_STATUS_MODE_STATUS_MST (1 << 23)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 05b6ffeb13be..807edba4cd6f 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2903,6 +2903,28 @@ static void intel_dp_sink_set_fec_ready(struct intel_dp
*intel_dp,
DRM_DEBUG_KMS("Failed to get FEC enabled in sink\n");
}
+static void intel_ddi_enable_fec(struct intel_encoder *encoder,
+const struct intel_crtc_state *crtc_state)
+{
+ struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+ enum port port = encoder->port;
+ u32 val;
+
+ /* FEC support exists for DP 1.4 only */
+ if (!crtc_state->fec_enable)
+ return;
+
+ val = I915_READ(DP_TP_CTL(port));
+ val |= DP_TP_CTL_FEC_ENABLE;
+ I915_WRITE(DP_TP_CTL(port), val);
+
+ if (intel_wait_for_register(dev_priv, DP_TP_STATUS(port),
+ DP_TP_STATUS_FEC_ENABLE_LIVE,
+ DP_TP_STATUS_FEC_ENABLE_LIVE,
+ 1))
+ DRM_ERROR("Timed out waiting for FEC Enable Status\n");
+}
+
static void intel_ddi_pre_enable_dp(struct intel_encoder *encoder,
const struct intel_crtc_state *crtc_state,
const struct drm_connector_state
*conn_state)
@@ -2951,6 +2973,8 @@ static void intel_ddi_pre_enable_dp(struct intel_encoder
*encoder,
if (port != PORT_A || INTEL_GEN(dev_priv) >= 9)
intel_dp_stop_link_train(intel_dp);
+ intel_ddi_enable_fec(encoder, crtc_state);
+
icl_enable_phy_clock_gating(dig_port);
if (!is_mst)
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[v5 4/6] drm/i915/fec: Set FEC_READY in FEC_CONFIGURATION
If the panel supports FEC, the driver has to
set the FEC_READY bit in the dpcd register:
FEC_CONFIGURATION.
This has to happen before link training.
v2: s/intel_dp_set_fec_ready/intel_dp_sink_set_fec_ready
- change commit message. (Gaurav)
v3: rebased. (r-b Manasi)
v4: Use fec crtc state, before setting FEC_READY
bit. (Anusha)
v5: Move to intel_ddi.c
- Make the function static (Anusha)
Cc: dri-devel@lists.freedesktop.org
Cc: Gaurav K Singh
Cc: Jani Nikula
Cc: Ville Syrjala
Cc: Manasi Navare
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/intel_ddi.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 1de0a3917d7f..05b6ffeb13be 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2889,6 +2889,20 @@ static void intel_ddi_clk_disable(struct intel_encoder
*encoder)
}
}
+static void intel_dp_sink_set_fec_ready(struct intel_dp *intel_dp,
+ const struct intel_crtc_state
*crtc_state,
+ int state)
+{
+ int ret;
+
+ if (!crtc_state->fec_enable)
+ return;
+
+ ret = drm_dp_dpcd_writeb(_dp->aux, DP_FEC_CONFIGURATION, state);
+ if (ret < 0)
+ DRM_DEBUG_KMS("Failed to get FEC enabled in sink\n");
+}
+
static void intel_ddi_pre_enable_dp(struct intel_encoder *encoder,
const struct intel_crtc_state *crtc_state,
const struct drm_connector_state
*conn_state)
@@ -2932,6 +2946,7 @@ static void intel_ddi_pre_enable_dp(struct intel_encoder
*encoder,
intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
intel_dp_sink_set_decompression_state(intel_dp, crtc_state,
DP_DECOMPRESSION_EN);
+ intel_dp_sink_set_fec_ready(intel_dp, crtc_state, DP_FEC_READY);
intel_dp_start_link_train(intel_dp);
if (port != PORT_A || INTEL_GEN(dev_priv) >= 9)
intel_dp_stop_link_train(intel_dp);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[v5 2/6] drm/dp/fec: DRM helper for Forward Error Correction
DP 1.4 has Forward Error Correction Support(FEC).
Add helper function to check if the sink device
supports FEC.
v2: Separate the helper and the code that uses the helper into
two separate patches. (Manasi)
v3:
- Move the code to drm_dp_helper.c (Manasi)
- change the return type, code style changes (Gaurav)
- Use drm_dp_dpcd_readb instead of drm_dp_dpcd_read. (Jani)
v4:
- Avoid aux reads everytime, instead read cached
values of dpcd register (jani)
- Move helper to drm_dp_helper.h like other dsc
helpers.(Anusha)
v5: rebased. Change the helper parameter suitably.
Cc: dri-devel@lists.freedesktop.org
Cc: Ville Syrjala
Cc: Jani Nikula
Cc: Manasi Navare
Signed-off-by: Anusha Srivatsa
Reviewed-by: Manasi Navare
---
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 2649529d0d8f..b08f50b852f5 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -1101,6 +1101,13 @@ drm_dp_dsc_sink_max_slice_width(const u8
dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE])
DP_DSC_SLICE_WIDTH_MULTIPLIER;
}
+/* Forward Error Correction Support on DP 1.4 */
+static inline bool
+drm_dp_sink_supports_fec(const u8 fec_capable)
+{
+ return fec_capable & DP_FEC_CAPABLE;
+}
+
/*
* DisplayPort AUX channel
*/
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[git pull] drm next fixes for 4.20-rc1
Hi Linus, Pretty much a normal fixes pull pre-rc1, mostly amdgpu fixes, one i915 link training regression fix, and a couple of minor panel/bridge fixes and a panel quirk. Thanks, Dave. drm-next-2018-11-02: drm, i915, amdgpu, bridge + core quirk The following changes since commit f2bfc71aee75feff33ca659322b72ffeed5a243d: Merge tag 'drm-intel-next-fixes-2018-10-18' of git://anongit.freedesktop.org/drm/drm-intel into drm-next (2018-10-19 14:28:11 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-next-2018-11-02 for you to fetch changes up to f9885ef875e9160454392f85159163674159c51f: Merge tag 'drm-intel-next-fixes-2018-10-25' of git://anongit.freedesktop.org/drm/drm-intel into drm-next (2018-11-02 15:17:57 +1000) drm, i915, amdgpu, bridge + core quirk Andrey Grodzovsky (2): drm/amdgpu: Fix compute ring 1.0.0 failure after reset drm/amdgpu: Fix skipping hangged job reset during gpu recover. Christian König (3): drm/amdgpu: fix amdgpu_vm_fini drm/amdgpu: fix VM leaf walking drm/amdgpu: revert "enable gfxoff in non-sriov and stutter mode by default" Dave Airlie (3): Merge tag 'drm-misc-next-fixes-2018-10-31' of git://anongit.freedesktop.org/drm/drm-misc into drm-next Merge branch 'drm-next-4.20' of git://people.freedesktop.org/~agd5f/linux into drm-next Merge tag 'drm-intel-next-fixes-2018-10-25' of git://anongit.freedesktop.org/drm/drm-intel into drm-next David Francis (2): powerplay: Respect units on max dcfclk watermark drm/amd/display: Disable 4k 60 HDMI on DCE11 Dhinakaran Pandiyan (2): drm/i915/dp: Fix link retraining comment in intel_dp_long_pulse() drm/i915/dp: Restrict link retrain workaround to external monitors Douglas Anderson (6): dt-bindings: drm/panel: simple: Add no-hpd property drm/panel: simple: Support panels with HPD where HPD isn't connected drm/panel: simple: Add "no-hpd" delay for Innolux TV123WAM drm/bridge: ti-sn65dsi86: Remove the mystery delay dt-bindings: drm/panel: simple: Innolux TV123WAM is actually P120ZDG-BF1 drm/panel: simple: Innolux TV123WAM is actually P120ZDG-BF1 Emily Deng (1): drm/amdgpu: Fix null pointer amdgpu_device_fw_loading Evan Quan (8): drm/amd/powerplay: error out when force clock level under auto dpm mode V2 drm/amd/powerplay: drop highest UCLK setting after display configuration change drm/amd/powerplay: bump the PPtable version supported drm/amd/powerplay: commit get_performance_level API as DAL needed drm/amd/powerplay: correct the clocks for DAL to be Khz unit drm/amd/powerplay: commonize the API for retrieving current clocks drm/amd/powerplay: revise Vega20 pptable version check drm/amd/powerplay: no MGPU fan boost enablement on DPM disabled Guttula, Suresh (1): drm/amd/display: set backlight level limit to 1 Joseph Greathouse (1): drm/amd/pp: enable power limit increase in OD mode Lee, Shawn C (1): drm/edid: Add 6 bpc quirk for BOE panel. Lyude Paul (4): drm/atomic_helper: Disallow new modesets on unregistered connectors drm/atomic_helper: Allow DPMS On<->Off changes for unregistered connectors drm/atomic_helper: Stop modesets on unregistered connectors harder drm/nouveau: Fix nv50_mstc->best_encoder() Rex Zhu (5): drm/amd/display: Fix Null point error if smu ip was disabled drm/amdgpu: Fix null point error drm/amd/pp: Fix pp_sclk/mclk_od not work on smu7 drm/amd/pp: Fix pp_sclk/mclk_od not work on Vega10 drm/amd/pp: Print warning if od_sclk/mclk out of range Shirish S (1): drm/amdgpu: fix reporting of failed msg sent to SMU (v2) ...nnolux,tv123wam.txt => innolux,p120zdg-bf1.txt} | 8 +- .../bindings/display/panel/simple-panel.txt| 3 + drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c| 6 +- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 6 +- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 4 +- drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c| 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 15 +++- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 7 +- drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 6 +- drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.c| 2 +- drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c | 6 +- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 7 ++ .../drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c | 16 ++-- .../drm/amd/display/dc/dce110/dce110_resource.c| 2 +- drivers/gpu/drm/amd/powerplay/amd_powerplay.c | 33 ++--- drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 10 ++- drivers/gpu/drm/amd/powerplay/hwmgr/smu_helper.c | 2 +- drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 43 ++-
[Bug 201599] New: [drm:atom_op_jump [amdgpu]] *ERROR* atombios stuck in loop for more than 5secs aborting
https://bugzilla.kernel.org/show_bug.cgi?id=201599 Bug ID: 201599 Summary: [drm:atom_op_jump [amdgpu]] *ERROR* atombios stuck in loop for more than 5secs aborting Product: Drivers Version: 2.5 Kernel Version: 4.18.14-300.fc29.x86_64 Hardware: x86-64 OS: Linux Tree: Fedora Status: NEW Severity: blocking Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: fruitboy1...@gmail.com Regression: No Hi, Now I met one amdgpu load failed issue on my machine. Could you help to look this issue? and give any suggestions? thanks in advance. the system: Ferdora 29 video cards: Intel gfx card and amd gfx card. the issue: OS boots up with Intel GPU , and when trying to initialize AMD GPU it fails. error logs: [2.983139] [drm] Replacing VGA console driver [2.994731] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [2.994732] [drm] Driver supports precise vblank timestamp query. [2.995525] i915 :00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=none:owns=io+mem [2.995917] [drm] Finished loading DMC firmware i915/kbl_dmc_ver1_04.bin (v1.4) [3.032676] [drm] amdgpu kernel modesetting enabled. [3.032685] vga_switcheroo: detected switching method \_SB_.PCI0.GFX0.ATPX handle [3.032786] ATPX version 1, functions 0x0033 [3.032908] ATPX Hybrid Graphics [3.035211] AMD IOMMUv2 driver by Joerg Roedel [3.035212] AMD IOMMUv2 functionality not available on this system [3.047357] CRAT table not found [3.047359] Virtual CRAT table created for CPU [3.047359] Parsing CRAT table with 1 nodes [3.047360] Creating topology SYSFS entries [3.047370] Topology: Add CPU node [3.047371] Finished initializing topology [3.047419] kfd kfd: Initialized module [3.047729] [drm] initializing kernel modesetting (VEGAM 0x1002:0x694E 0x8086:0x2112 0xC0). [3.047736] [drm] register mmio base: 0xA700 [3.047736] [drm] register mmio size: 262144 [3.047742] [drm] probing gen 2 caps for device 8086:1901 = 261ac83/e [3.047743] [drm] probing mlw for device 8086:1901 = 261ac83 [3.047744] [drm] add ip block number 0 [3.047745] [drm] add ip block number 1 [3.047745] [drm] add ip block number 2 [3.047746] [drm] add ip block number 3 [3.047746] [drm] add ip block number 4 [3.047747] [drm] add ip block number 5 [3.047747] [drm] add ip block number 6 [3.047748] [drm] add ip block number 7 [3.047748] [drm] add ip block number 8 [3.047750] amdgpu :01:00.0: kfd not supported on this ASIC [3.047758] [drm] UVD is enabled in VM mode [3.047759] [drm] UVD ENC is enabled in VM mode [3.047761] [drm] VCE enabled in VM mode [3.047762] vga_switcheroo: enabled [3.051899] [drm] BIOS signature incorrect 0 0 [3.816165] (:02:00.0): E-Switch: Total vports 1, per vport: max uc(1024) max mc(16384) [3.846630] mlx5_core :02:00.0: Port module event: module 0, Cable plugged [3.852016] mlx5_core :02:00.1: firmware version: 14.21.1000 [3.852076] mlx5_core :02:00.1: 15.752 Gb/s available PCIe bandwidth (8 GT/s x2 link) [3.873436] scsi 3:0:0:0: CD-ROMAMI Virtual CDROM0 1.00 PQ: 0 ANSI: 0 CCS [3.873723] scsi 4:0:0:0: Direct-Access AMI Virtual HDisk0 1.00 PQ: 0 ANSI: 0 CCS [3.874773] sr 3:0:0:0: [sr0] scsi-1 drive [3.874774] cdrom: Uniform CD-ROM driver Revision: 3.20 [3.874857] sr 3:0:0:0: Attached scsi CD-ROM sr0 [3.874920] sr 3:0:0:0: Attached scsi generic sg2 type 5 [3.875072] sd 4:0:0:0: Attached scsi generic sg3 type 0 [3.875969] sd 4:0:0:0: [sdc] Attached SCSI removable disk [3.988208] ATOM BIOS: 408436.180301.04s [3.988218] [drm] GPU posting now... [4.099892] [drm] failed to retrieve link info, disabling eDP [4.800159] (:02:00.1): E-Switch: Total vports 1, per vport: max uc(1024) max mc(16384) [4.836117] mlx5_core :02:00.0: MLX5E: StrdRq(0) RqSz(1024) StrdSz(64) RxCqeCmprss(0) [5.015662] mlx5_core :02:00.1: MLX5E: StrdRq(0) RqSz(1024) StrdSz(64) RxCqeCmprss(0) [5.222643] mlx5_core :02:00.0 enp2s0f0: renamed from eth0 [7.800157] fbcon: Taking over console [8.990049] [drm:atom_op_jump [amdgpu]] *ERROR* atombios stuck in loop for more than 5secs aborting [8.990082] [drm:amdgpu_atom_execute_table_locked [amdgpu]] *ERROR* atombios stuck executing E8D2 (len 281, WS 4, PS 4) @ 0xE9D2 [8.990112] [drm:amdgpu_atom_execute_table_locked [amdgpu]] *ERROR* atombios stuck executing C57A (len 114, WS 0, PS 8) @ 0xC5C6 [8.990114] amdgpu :01:00.0: gpu post error! [8.990116] amdgpu :01:00.0: Fatal error during GPU init [8.990125] [drm] amdgpu: finishing device. [8.990133] vga_switcheroo: disabled [8.990374]
[Bug 108533] [Polaris 20] 4.19.0 final unusable with RX580 - SDDM screen corruption, regression
https://bugs.freedesktop.org/show_bug.cgi?id=108533 Dieter Nützel changed: What|Removed |Added Status|RESOLVED|CLOSED -- 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 108577] Black X laptop screen with cursor if HDMI not plugged in, bisected
https://bugs.freedesktop.org/show_bug.cgi?id=108577 --- Comment #18 from Duncan Roe --- Created attachment 142334 --> https://bugs.freedesktop.org/attachment.cgi?id=142334=edit Patch for Linux-19.0 to revert 5099114 & reinstate DRM_AMD_DC_FBC kconfig option -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3] Add display nodes to SDM845 dtsi
Reviving the patch posted by Sean initially. This patch set adds MDSS and DSI nodes to SDM845 dtsi to enable display. The patches are tested on SDM845 MTP platform using the kernel based on [1]. Part of the dependent drivers are already posted on list. Rest of the dependencies are met using using downstream version of the driver(s) which are yet to make it to the list. References to the driver patches used for testing: display controller: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/arch/arm64/boot/dts/qcom/sdm845.dtsi?id=40019e8452fe76867bdb2e7 WLED: https://patchwork.kernel.org/project/linux-arm-msm/list/?series=11023=both=* Panel: https://patchwork.freedesktop.org/series/50657/ iommu: https://patchwork.kernel.org/patch/10534999/ [1] https://git.linaro.org/landing-teams/working/qualcomm/kernel.git/log/?h=integration-linux-qcomlt Thanks and Regards, Jeykumar S. Jeykumar Sankaran (1): arm64: dts: qcom: sdm845: Add dpu to sdm845 dts file arch/arm64/boot/dts/qcom/sdm845.dtsi | 191 +++ 1 file changed, 191 insertions(+) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3] arm64: dts: qcom: sdm845: Add dpu to sdm845 dts file
DPU is short for the Display Processing Unit. It is the display
controller on Qualcomm SDM845 chips.
This change adds MDSS and DSI nodes to enable display on the
target device.
Changes in v2:
- Beefed up commit message
- Use SoC specific compatibles for mdss and dpu (Rob H)
- Use assigned-clocks to set initial clock frequency(Rob H)
Changes in v3:
- added IOMMU node
- Fix device naming (remove _phys)
- Use correct IRQ_TYPE in interrupt specifiers
Signed-off-by: Jeykumar Sankaran
Signed-off-by: Sean Paul
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 191 +++
1 file changed, 191 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 0c9a2aa..dd612ac 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -978,6 +978,197 @@
#thermal-sensor-cells = <1>;
};
+ mdss: mdss@ae0 {
+ compatible = "qcom,sdm845-mdss";
+ reg = <0xae0 0x1000>;
+ reg-names = "mdss";
+
+ power-domains = < 0>;
+
+ clocks = < GCC_DISP_AHB_CLK>,
+< GCC_DISP_AXI_CLK>,
+< DISP_CC_MDSS_MDP_CLK>;
+ clock-names = "iface", "bus", "core";
+
+ assigned-clocks = < DISP_CC_MDSS_MDP_CLK>;
+ assigned-clock-rates = <3>;
+
+ interrupts = ;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ iommus = <_smmu 0x880 0x8>,
+<_smmu 0xc80 0x8>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ mdss_mdp: mdp@ae01000 {
+ compatible = "qcom,sdm845-dpu";
+ reg = <0x0ae01000 0x8f000>,
+ <0x0aeb 0x2008>;
+ reg-names = "mdp", "vbif";
+
+ clocks = < DISP_CC_MDSS_AHB_CLK>,
+< DISP_CC_MDSS_AXI_CLK>,
+< DISP_CC_MDSS_MDP_CLK>,
+< DISP_CC_MDSS_VSYNC_CLK>;
+ clock-names = "iface", "bus", "core", "vsync";
+
+ assigned-clocks = <
DISP_CC_MDSS_MDP_CLK>,
+ <
DISP_CC_MDSS_VSYNC_CLK>;
+ assigned-clock-rates = <3>,
+ <1920>;
+
+ interrupt-parent = <>;
+ interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dpu_intf1_out: endpoint {
+ remote-endpoint =
<_in>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dpu_intf2_out: endpoint {
+ remote-endpoint =
<_in>;
+ };
+ };
+ };
+ };
+
+ dsi0: dsi@ae94000 {
+ compatible = "qcom,mdss-dsi-ctrl";
+ reg = <0xae94000 0x400>;
+ reg-names = "dsi_ctrl";
+
+ interrupt-parent = <>;
+ interrupts = <4 IRQ_TYPE_LEVEL_HIGH>;
+
+ clocks = < DISP_CC_MDSS_BYTE0_CLK>,
+< DISP_CC_MDSS_BYTE0_INTF_CLK>,
+< DISP_CC_MDSS_PCLK0_CLK>,
+< DISP_CC_MDSS_ESC0_CLK>,
+< DISP_CC_MDSS_AHB_CLK>,
+< DISP_CC_MDSS_AXI_CLK>;
+ clock-names = "byte_clk",
+ "byte_intf_clk",
+ "pixel_clk",
+ "core_clk",
+
[PATCH] drm/amd/amdgpu/dm: Fix dm_dp_create_fake_mst_encoder()
[why]
Removing connector reusage from DM to match the rest of the tree ended
up revealing an issue that was surprisingly subtle. The original amdgpu
code for DC that was submitted appears to have left a chunk in
dm_dp_create_fake_mst_encoder() that tries to find a "master encoder",
the likes of which isn't actually used or stored anywhere. It does so at
the wrong time as well by trying to access parts of the drm_connector
from the encoder init before it's actually been initialized. This
results in a NULL pointer deref on MST hotplugs:
[ 160.696613] BUG: unable to handle kernel NULL pointer dereference at
[ 160.697234] PGD 0 P4D 0
[ 160.697814] Oops: 0010 [#1] SMP PTI
[ 160.698430] CPU: 2 PID: 64 Comm: kworker/2:1 Kdump: loaded Tainted: G
O 4.19.0Lyude-Test+ #2
[ 160.699020] Hardware name: HP HP ZBook 15 G4/8275, BIOS P70 Ver. 01.22
05/17/2018
[ 160.699672] Workqueue: events_long drm_dp_mst_link_probe_work
[drm_kms_helper]
[ 160.700322] RIP: 0010: (null)
[ 160.700920] Code: Bad RIP value.
[ 160.701541] RSP: 0018:c929fc78 EFLAGS: 00010206
[ 160.702183] RAX: RBX: 8804440ed468 RCX: 8804440e9158
[ 160.702778] RDX: RSI: 8804556c5700 RDI: 8804440ed000
[ 160.703408] RBP: 880458e21800 R08: 0002 R09: 5fca0a25
[ 160.704002] R10: 88045a077a3d R11: 88045a077a3c R12: 8804440ed000
[ 160.704614] R13: 880458e21800 R14: 8804440e9000 R15: 8804440e9000
[ 160.705260] FS: () GS:88045f28()
knlGS:
[ 160.705854] CS: 0010 DS: ES: CR0: 80050033
[ 160.706478] CR2: ffd6 CR3: 0200a001 CR4: 003606e0
[ 160.707124] DR0: DR1: DR2:
[ 160.707724] DR3: DR6: fffe0ff0 DR7: 0400
[ 160.708372] Call Trace:
[ 160.708998] ? dm_dp_add_mst_connector+0xed/0x1d0 [amdgpu]
[ 160.709625] ? drm_dp_add_port+0x2fa/0x470 [drm_kms_helper]
[ 160.710284] ? wake_up_q+0x54/0x70
[ 160.710877] ? __mutex_unlock_slowpath.isra.18+0xb3/0x110
[ 160.711512] ? drm_dp_dpcd_access+0xe7/0x110 [drm_kms_helper]
[ 160.712161] ? drm_dp_send_link_address+0x155/0x1e0 [drm_kms_helper]
[ 160.712762] ? drm_dp_check_and_send_link_address+0xa3/0xd0 [drm_kms_helper]
[ 160.713408] ? drm_dp_mst_link_probe_work+0x4b/0x80 [drm_kms_helper]
[ 160.714013] ? process_one_work+0x1a1/0x3a0
[ 160.714667] ? worker_thread+0x30/0x380
[ 160.715326] ? wq_update_unbound_numa+0x10/0x10
[ 160.715939] ? kthread+0x112/0x130
[ 160.716591] ? kthread_create_worker_on_cpu+0x70/0x70
[ 160.717262] ? ret_from_fork+0x35/0x40
[ 160.717886] Modules linked in: amdgpu(O) vfat fat snd_hda_codec_generic
joydev i915 chash gpu_sched ttm i2c_algo_bit drm_kms_helper snd_hda_codec_hdmi
hp_wmi syscopyarea iTCO_wdt sysfillrect sparse_keymap sysimgblt fb_sys_fops
snd_hda_intel usbhid wmi_bmof drm snd_hda_codec btusb snd_hda_core intel_rapl
btrtl x86_pkg_temp_thermal btbcm btintel coretemp snd_pcm crc32_pclmul
bluetooth psmouse snd_timer snd pcspkr i2c_i801 mei_me i2c_core soundcore mei
tpm_tis wmi tpm_tis_core hp_accel ecdh_generic lis3lv02d tpm video rfkill
acpi_pad input_polldev hp_wireless pcc_cpufreq crc32c_intel serio_raw tg3
xhci_pci xhci_hcd [last unloaded: amdgpu]
[ 160.720141] CR2:
Somehow the connector reusage DM was using for MST connectors managed to
paper over this issue entirely; hence why this was never caught until
now.
[how]
Since this code isn't used anywhere and seems useless anyway, we can
just drop it entirely. This appears to fix the issue on my HP ZBook with
an AMD WX4150.
Signed-off-by: Lyude Paul
---
Hey! This is the patch that I was talking about, feel free to review
it-we should make sure this goes in with the rest of the patches you've
got so far.
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 6aa7359d61a3..5432a1862b41 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -285,12 +285,7 @@ dm_dp_create_fake_mst_encoder(struct amdgpu_dm_connector
*connector)
struct amdgpu_device *adev = dev->dev_private;
struct amdgpu_encoder *amdgpu_encoder;
struct drm_encoder *encoder;
- const struct drm_connector_helper_funcs *connector_funcs =
- connector->base.helper_private;
- struct drm_encoder *enc_master =
- connector_funcs->best_encoder(>base);
- DRM_DEBUG_KMS("enc master is %p\n", enc_master);
amdgpu_encoder = kzalloc(sizeof(*amdgpu_encoder), GFP_KERNEL);
if (!amdgpu_encoder)
return NULL;
--
2.19.1
[Bug 106175] amdgpu.dc=1 shows performance issues with Xorg compositors when moving windows
https://bugs.freedesktop.org/show_bug.cgi?id=106175 --- Comment #39 from gr...@sub.red --- (In reply to Michel Dänzer from comment #34) > > Right, you'd have to disable TearFree as well. Then I think the logs should represent that, even when the manpage tells me that tearfree is using page flipping. If i set explicitly to off, and the log says so, I expect it to be off. And yes, disabling page flipping "resolves" the issue, but that's not new knowledge. -- 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 v6 11/28] drm/dsc: Add helpers for DSC picture parameter set infoframes
On Thu, Nov 01, 2018 at 04:54:14PM -0700, Manasi Navare wrote:
> Thanks for reviewing this patch. Find some comments inline
>
> On Thu, Nov 01, 2018 at 06:46:28PM +0200, Ville Syrjälä wrote:
> > On Wed, Oct 24, 2018 at 03:28:23PM -0700, Manasi Navare wrote:
> > > According to Display Stream compression spec 1.2, the picture
> > > parameter set metadata is sent from source to sink device
> > > using the DP Secondary data packet. An infoframe is formed
> > > for the PPS SDP header and PPS SDP payload bytes.
> > > This patch adds helpers to fill the PPS SDP header
> > > and PPS SDP payload according to the DSC 1.2 specification.
> > >
> > > v6:
> > > * Use proper sequence points for breaking down the
> > > assignments (Chris Wilson)
> > > * Use SPDX identifier
> > > v5:
> > > Do not use bitfields for DRM structs (Jani N)
> > > v4:
> > > * Use DSC constants for params that dont change across
> > > configurations
> > > v3:
> > > * Add reference to added kernel-docs in
> > > Documentation/gpu/drm-kms-helpers.rst
> > > (Daniel Vetter)
> > >
> > > v2:
> > > * Add EXPORT_SYMBOL for the drm functions (Manasi)
> > >
> > > Cc: dri-devel@lists.freedesktop.org
> > > Cc: Jani Nikula
> > > Cc: Ville Syrjala
> > > Cc: Anusha Srivatsa
> > > Cc: Harry Wentland
> > > Signed-off-by: Manasi Navare
> > > Acked-by: Harry Wentland
> > > ---
> > > Documentation/gpu/drm-kms-helpers.rst | 12 ++
> > > drivers/gpu/drm/Makefile | 2 +-
> > > drivers/gpu/drm/drm_dsc.c | 223 ++
> > > include/drm/drm_dsc.h | 22 +++
> > > 4 files changed, 258 insertions(+), 1 deletion(-)
> > > create mode 100644 drivers/gpu/drm/drm_dsc.c
> > >
> > > diff --git a/Documentation/gpu/drm-kms-helpers.rst
> > > b/Documentation/gpu/drm-kms-helpers.rst
> > > index 4b4dc236ef6f..b422eb8edf16 100644
> > > --- a/Documentation/gpu/drm-kms-helpers.rst
> > > +++ b/Documentation/gpu/drm-kms-helpers.rst
> > > @@ -232,6 +232,18 @@ MIPI DSI Helper Functions Reference
> > > .. kernel-doc:: drivers/gpu/drm/drm_mipi_dsi.c
> > > :export:
> > >
> > > +Display Stream Compression Helper Functions Reference
> > > +=
> > > +
> > > +.. kernel-doc:: drivers/gpu/drm/drm_dsc.c
> > > + :doc: dsc helpers
> > > +
> > > +.. kernel-doc:: include/drm/drm_dsc.h
> > > + :internal:
> > > +
> > > +.. kernel-doc:: drivers/gpu/drm/drm_dsc.c
> > > + :export:
> > > +
> > > Output Probing Helper Functions Reference
> > > =
> > >
> > > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> > > index 576ba985e138..3a3e6fb6d476 100644
> > > --- a/drivers/gpu/drm/Makefile
> > > +++ b/drivers/gpu/drm/Makefile
> > > @@ -32,7 +32,7 @@ drm-$(CONFIG_AGP) += drm_agpsupport.o
> > > drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
> > > drm-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
> > >
> > > -drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o
> > > \
> > > +drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_dsc.o
> > > drm_probe_helper.o \
> > > drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o \
> > > drm_kms_helper_common.o drm_dp_dual_mode_helper.o \
> > > drm_simple_kms_helper.o drm_modeset_helper.o \
> > > diff --git a/drivers/gpu/drm/drm_dsc.c b/drivers/gpu/drm/drm_dsc.c
> > > new file mode 100644
> > > index ..21ae8d015afd
> > > --- /dev/null
> > > +++ b/drivers/gpu/drm/drm_dsc.c
> > > @@ -0,0 +1,223 @@
> > > +// SPDX-License-Identifier: MIT
> > > +/*
> > > + * Copyright © 2018 Intel Corp
> > > + *
> > > + * Author:
> > > + * Manasi Navare
> > > + */
> > > +
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +
> > > +/**
> > > + * DOC: dsc helpers
> > > + *
> > > + * These functions contain some common logic and helpers to deal with
> > > VESA
> > > + * Display Stream Compression standard required for DSC on Display
> > > Port/eDP or
> > > + * MIPI display interfaces.
> > > + */
> > > +
> > > +/**
> > > + * drm_dsc_dp_pps_header_init() - Initializes the PPS Header
> > > + * for DisplayPort as per the DP 1.4 spec.
> > > + * @pps_sdp: Secondary data packet for DSC Picture Parameter Set
> > > + */
> > > +void drm_dsc_dp_pps_header_init(struct drm_dsc_pps_infoframe *pps_sdp)
> > > +{
> > > + memset(_sdp->pps_header, 0, sizeof(pps_sdp->pps_header));
> > > +
> > > + pps_sdp->pps_header.HB1 = DP_SDP_PPS;
> > > + pps_sdp->pps_header.HB2 = DP_SDP_PPS_HEADER_PAYLOAD_BYTES_MINUS_1;
> > > +}
> > > +EXPORT_SYMBOL(drm_dsc_dp_pps_header_init);
> > > +
> > > +/**
> > > + * drm_dsc_pps_infoframe_pack() - Populates the DSC PPS infoframe
> > > + * using the DSC configuration parameters in the order expected
> > > + * by the DSC Display Sink device. For the DSC, the sink device
> > > + * expects the PPS payload in the big endian format for the fields
> > >
[Bug 93829] [Wine] Lockup with MotoGP 2
https://bugs.freedesktop.org/show_bug.cgi?id=93829 Timothy Arceri changed: What|Removed |Added Resolution|--- |FIXED Status|NEEDINFO|RESOLVED --- Comment #4 from Timothy Arceri --- I'm going to just assume this has been fixed and close. Please reopen if that is not the case. -- 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 v6 11/28] drm/dsc: Add helpers for DSC picture parameter set infoframes
Thanks for reviewing this patch. Find some comments inline
On Thu, Nov 01, 2018 at 06:46:28PM +0200, Ville Syrjälä wrote:
> On Wed, Oct 24, 2018 at 03:28:23PM -0700, Manasi Navare wrote:
> > According to Display Stream compression spec 1.2, the picture
> > parameter set metadata is sent from source to sink device
> > using the DP Secondary data packet. An infoframe is formed
> > for the PPS SDP header and PPS SDP payload bytes.
> > This patch adds helpers to fill the PPS SDP header
> > and PPS SDP payload according to the DSC 1.2 specification.
> >
> > v6:
> > * Use proper sequence points for breaking down the
> > assignments (Chris Wilson)
> > * Use SPDX identifier
> > v5:
> > Do not use bitfields for DRM structs (Jani N)
> > v4:
> > * Use DSC constants for params that dont change across
> > configurations
> > v3:
> > * Add reference to added kernel-docs in
> > Documentation/gpu/drm-kms-helpers.rst
> > (Daniel Vetter)
> >
> > v2:
> > * Add EXPORT_SYMBOL for the drm functions (Manasi)
> >
> > Cc: dri-devel@lists.freedesktop.org
> > Cc: Jani Nikula
> > Cc: Ville Syrjala
> > Cc: Anusha Srivatsa
> > Cc: Harry Wentland
> > Signed-off-by: Manasi Navare
> > Acked-by: Harry Wentland
> > ---
> > Documentation/gpu/drm-kms-helpers.rst | 12 ++
> > drivers/gpu/drm/Makefile | 2 +-
> > drivers/gpu/drm/drm_dsc.c | 223 ++
> > include/drm/drm_dsc.h | 22 +++
> > 4 files changed, 258 insertions(+), 1 deletion(-)
> > create mode 100644 drivers/gpu/drm/drm_dsc.c
> >
> > diff --git a/Documentation/gpu/drm-kms-helpers.rst
> > b/Documentation/gpu/drm-kms-helpers.rst
> > index 4b4dc236ef6f..b422eb8edf16 100644
> > --- a/Documentation/gpu/drm-kms-helpers.rst
> > +++ b/Documentation/gpu/drm-kms-helpers.rst
> > @@ -232,6 +232,18 @@ MIPI DSI Helper Functions Reference
> > .. kernel-doc:: drivers/gpu/drm/drm_mipi_dsi.c
> > :export:
> >
> > +Display Stream Compression Helper Functions Reference
> > +=
> > +
> > +.. kernel-doc:: drivers/gpu/drm/drm_dsc.c
> > + :doc: dsc helpers
> > +
> > +.. kernel-doc:: include/drm/drm_dsc.h
> > + :internal:
> > +
> > +.. kernel-doc:: drivers/gpu/drm/drm_dsc.c
> > + :export:
> > +
> > Output Probing Helper Functions Reference
> > =
> >
> > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> > index 576ba985e138..3a3e6fb6d476 100644
> > --- a/drivers/gpu/drm/Makefile
> > +++ b/drivers/gpu/drm/Makefile
> > @@ -32,7 +32,7 @@ drm-$(CONFIG_AGP) += drm_agpsupport.o
> > drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
> > drm-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
> >
> > -drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \
> > +drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_dsc.o
> > drm_probe_helper.o \
> > drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o \
> > drm_kms_helper_common.o drm_dp_dual_mode_helper.o \
> > drm_simple_kms_helper.o drm_modeset_helper.o \
> > diff --git a/drivers/gpu/drm/drm_dsc.c b/drivers/gpu/drm/drm_dsc.c
> > new file mode 100644
> > index ..21ae8d015afd
> > --- /dev/null
> > +++ b/drivers/gpu/drm/drm_dsc.c
> > @@ -0,0 +1,223 @@
> > +// SPDX-License-Identifier: MIT
> > +/*
> > + * Copyright © 2018 Intel Corp
> > + *
> > + * Author:
> > + * Manasi Navare
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +/**
> > + * DOC: dsc helpers
> > + *
> > + * These functions contain some common logic and helpers to deal with VESA
> > + * Display Stream Compression standard required for DSC on Display
> > Port/eDP or
> > + * MIPI display interfaces.
> > + */
> > +
> > +/**
> > + * drm_dsc_dp_pps_header_init() - Initializes the PPS Header
> > + * for DisplayPort as per the DP 1.4 spec.
> > + * @pps_sdp: Secondary data packet for DSC Picture Parameter Set
> > + */
> > +void drm_dsc_dp_pps_header_init(struct drm_dsc_pps_infoframe *pps_sdp)
> > +{
> > + memset(_sdp->pps_header, 0, sizeof(pps_sdp->pps_header));
> > +
> > + pps_sdp->pps_header.HB1 = DP_SDP_PPS;
> > + pps_sdp->pps_header.HB2 = DP_SDP_PPS_HEADER_PAYLOAD_BYTES_MINUS_1;
> > +}
> > +EXPORT_SYMBOL(drm_dsc_dp_pps_header_init);
> > +
> > +/**
> > + * drm_dsc_pps_infoframe_pack() - Populates the DSC PPS infoframe
> > + * using the DSC configuration parameters in the order expected
> > + * by the DSC Display Sink device. For the DSC, the sink device
> > + * expects the PPS payload in the big endian format for the fields
> > + * that span more than 1 byte.
> > + *
> > + * @pps_sdp:
> > + * Secondary data packet for DSC Picture Parameter Set
> > + * @dsc_cfg:
> > + * DSC Configuration data filled by driver
> > + */
> > +void drm_dsc_pps_infoframe_pack(struct drm_dsc_pps_infoframe *pps_sdp,
> > + struct drm_dsc_config
Re: [RFC] Generic cgroup controller for the gpu/drm subsystem
+dri-devel list since a lot of the relevant audience is on that list. On Mon, Oct 29, 2018 at 07:49:13PM -0400, Kenny Ho wrote: > (Resending in plain text) > > Hi, > > We are thinking of using cgroup to manage resources in GPUs. I > believe Matt Roper from Intel has been trying to do something similar. > From previous discussions > (https://www.spinics.net/lists/cgroups/msg18687.html), the cgroup > framework appears to not want to have a full-fledged cgroup controller > for Matt's use case but I am not sure if I understood the rationale. > It's also unclear to me if our use case matches Matt's. We are hoping > to have a better understanding of the situation before embarking on a > path that may ultimately be unacceptable to upstream. To that end, I > will outline our (AMD) use case at a high level and perhaps folks on > this list can give some suggestions? > > Our use case comes from the world of data center and cluster. > Currently we have a rudimentary mechanism to expose GPUs to a > container cluster running Kubernetes > (https://github.com/RadeonOpenCompute/k8s-device-plugin) but it only > exposes GPUs in whole. That means multiple container cannot share the > same GPU. A well established way to share a GPU is to use > SRIOV/virtualization but it shares the GPU in time slices. > > An alternative is to share the GPU by its constituents. Perhaps a > good way to think about this is to treat the GPU like a mini-computer. > A GPU has memory (VRAM) and it also has compute units (but instead 10s > of cores, it has 100~1000 of shaders/CUs.) So we can potentially > share a GPU by those two dimensions. Similar to a computer, a GPU > also has specialized hardware so we can potentially share those > separately as well. > > Unlike a computer, however, GPUs are not as well "standardized" as a > desktop or a server. For the gpu/drm subsystem, there are something > that are common (such as buffer sharing and buffer lifetime > management), something that are shared by some vendors (software > scheduler) and something that are very much vendor specific. Due to > this, a generic cgroup controller for drm may need to be more > pluggable than other cgroup controller. We took a look at the rdma > cgroup as part of our research but rdma appears to have resources that > are more abstracted and standardized. > > What do you think? Does drm/gpu warrant its own full-fledged cgroup > controller? > > Regards, > Kenny Ho Hi Kenny. My drm+cgroups work from earlier this year has been on pause at the moment since I got pulled away to focus on some other higher priority tasks. What I was working on previously still has value to various parts of Intel, so I do plan to return to it eventually if nobody else jumps in first; I'm just not sure exactly when I'll have time to get back to it. In general, there are several areas where gpu and drm subsystem behavior could interact in some way with cgroup membership. Some aspects of graphics behavior would be a good match for controlling via a true cgroup controller, whereas others probably make more sense to add as driver or drm core interfaces that just pay attention to the cgroup membership of a process. A real cgroup controller is probably what we'd want to use for concepts that map well to the hierarchical structure of cgroups and that can be handled via one of the four models described in the "Resource Distribution Models" section of Documentation/admin-guide/cgroup-v2.rst. Off the top of my head, the graphics concepts that seem like a good match for this are: * GPU memory management - At a high level, memory management fits into cgroup controller model well, but there are a lot of implementation details that would need to be agreed upon before someone starts writing a controller for this. The way GPU memory gets allocated and shared between processes adds complexity to how you do the accounting, as does the diversity in types and levels of GPU memory supported by different vendors' GPU's (especially differences between what "GPU memory" even means on discrete vs integrated graphics). * GPU time (fair scheduler) - If you want to partition execution time on a GPU, a cgroup controller is a good match for that. * GPU engine/EU partitioning - I'm not familiar with the details of the specific hardware you're focusing on, but based on your description above, it sounds like it gives you a lot of flexibility to slice up your GPU execution units and submit independent workloads to arbitrary subsets of them? If that's true, a cgroup controller could be used to balance how many EU's various cgroups have access to or to reserve dedicated subsets of EU's for the processes in specific cgroups to help provide QoS guarantees. I don't think most of the hardware I work with is nearly that flexible at the EU level, but even on simpler hardware designs, a cgroup controller could probably partition access to the
[Bug 108613] amdgpu.dc=1 + xf86-video-amdgpu: changing to a GPU upscaling resolution resets pp_dpm_mclk
https://bugs.freedesktop.org/show_bug.cgi?id=108613 --- Comment #5 from tempel.jul...@gmail.com --- Yeah, looks like that. It also happens when changing ttys. -- 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 v6 08/28] drm/dsc: Define Display Stream Compression PPS infoframe
On Thu, Nov 01, 2018 at 06:42:17PM +0200, Ville Syrjälä wrote:
> On Wed, Oct 24, 2018 at 03:28:20PM -0700, Manasi Navare wrote:
> > This patch defines a new header file for all the DSC 1.2 structures
> > and creates a structure for PPS infoframe which will be used to send
> > picture parameter set secondary data packet for display stream compression.
> > All the PPS infoframe syntax elements are taken from DSC 1.2 specification
> > from VESA.
> >
> > v3:
> > * Add the SPDX shorthand (Chris Wilson)
> > v2:
> > * Do not use bitfields in the struct (Jani Nikula)
> >
> > Cc: Gaurav K Singh
> > Cc: dri-devel@lists.freedesktop.org
> > Cc: Jani Nikula
> > Cc: Ville Syrjala
> > Cc: Anusha Srivatsa
> > Cc: Harry Wentland
> > Signed-off-by: Manasi Navare
> > Reviewed-by: Harry Wentland
> > ---
> > include/drm/drm_dsc.h | 347 ++
> > 1 file changed, 347 insertions(+)
> > create mode 100644 include/drm/drm_dsc.h
> >
> > diff --git a/include/drm/drm_dsc.h b/include/drm/drm_dsc.h
> > new file mode 100644
> > index ..1d8a03983b90
> > --- /dev/null
> > +++ b/include/drm/drm_dsc.h
> > @@ -0,0 +1,347 @@
> > +/* SPDX-License-Identifier: MIT
> > + * Copyright (C) 2018 Intel Corp.
> > + *
> > + * Authors:
> > + * Manasi Navare
> > + */
> > +
> > +#ifndef DRM_DSC_H_
> > +#define DRM_DSC_H_
> > +
> > +#include
> > +
> > +/* VESA Display Stream Compression DSC 1.2 constants */
> > +#define DSC_NUM_BUF_RANGES 15
>
> DRM_DSC_... perhasp?
>
> > +
> > +/**
> > + * struct picture_parameter_set - Represents 128 bytes of Picture
> > Parameter Set
> > + *
> > + * The VESA DSC standard defines picture parameter set (PPS) which display
> > + * stream compression encoders must communicate to decoders.
> > + * The PPS is encapsulated in 128 bytes (PPS 0 through PPS 127). The
> > fields in
> > + * this structure are as per Table 4.1 in Vesa DSC specification v1.1/v1.2.
> > + * The PPS fields that span over more than a byte should be stored in Big
> > Endian
> > + * format.
> > + */
> > +struct picture_parameter_set {
>
> Needs a namespace too. Probably best make this struct packed. A
> BUILD_BUG_ON() somewhere to verify the size might also be nice.
>
By namespace you mean renaming this struct as dsc_picture_parameter_set?
And yes will make this struct packed.
BUILD_BUG_ON() before using it to make sure the size is still 128 bytes?
> > + /**
> > +* @dsc_version:
> > +* PPS0[3:0] - dsc_version_minor: Contains Minor version of DSC
> > +* PPS0[7:4] - dsc_version_major: Contains major version of DSC
> > +*/
> > + u8 dsc_version;
> > + /**
> > +* @pps_identifier:
> > +* PPS1[7:0] - Application specific identifier that can be
> > +* used to differentiate between different PPS tables.
> > +*/
> > + u8 pps_identifier;
> > + /**
> > +* @pps_reserved:
> > +* PPS2[7:0]- RESERVED Byte
> > +*/
> > + u8 pps_reserved;
> > + /**
> > +* @pps_3:
> > +* PPS3[3:0] - linebuf_depth: Contains linebuffer bit depth used to
> > +* generate the bitstream. (0x0 - 16 bits for DSC 1.2, 0x8 - 8 bits,
> > +* 0xA - 10 bits, 0xB - 11 bits, 0xC - 12 bits, 0xD - 13 bits,
> > +* 0xE - 14 bits for DSC1.2, 0xF - 14 bits for DSC 1.2.
> > +* PPS3[7:4] - bits_per_component: Bits per component for the original
> > +* pixels of the encoded picture.
> > +* 0x0 = 16bpc (allowed only when dsc_version_minor = 0x2)
> > +* 0x8 = 8bpc, 0xA = 10bpc, 0xC = 12bpc, 0xE = 14bpc (also
> > +* allowed only when dsc_minor_version = 0x2)
> > +*/
> > + u8 pps_3;
> > + /**
> > +* @pps_4:
> > +* PPS4[1:0] -These are the most significant 2 bits of
> > +* compressed BPP bits_per_pixel[9:0] syntax element.
> > +* PPS4[2] - vbr_enable: 0 = VBR disabled, 1 = VBR enabled
> > +* PPS4[3] - simple_422: Indicates if decoder drops samples to
> > +* reconstruct the 4:2:2 picture.
> > +* PPS4[4] - Convert_rgb: Indicates if DSC color space conversion is
> > +* active.
> > +* PPS4[5] - blobk_pred_enable: Indicates if BP is used to code any
> > +* groups in picture
> > +* PPS4[7:6] - Reseved bits
> > +*/
> > + u8 pps_4;
> > + /**
> > +* @bits_per_pixel_low:
> > +* PPS5[7:0] - This indicates the lower significant 8 bits of
> > +* the compressed BPP bits_per_pixel[9:0] element.
> > +*/
> > + u8 bits_per_pixel_low;
> > + /**
> > +* @pic_height:
> > +* PPS6[7:0], PPS7[7:0] -pic_height: Specifies the number of pixel rows
> > +* within the raster.
> > +*/
> > + __be16 pic_height;
> > + /**
> > +* @pic_width:
> > +* PPS8[7:0], PPS9[7:0] - pic_width: Number of pixel columns within
> > +* the raster.
> > +*/
> > + __be16 pic_width;
> > + /**
> > +* @slice_height:
> > +* PPS10[7:0], PPS11[7:0] - Slice height in units of pixels.
> > +*/
> > + __be16 slice_height;
> > + /**
> > +* @slice_width:
> > +* PPS12[7:0],
[PATCH 2/2 v4] drm/panel: Add a driver for the TPO TPG110
The TPO (Toppoly) TPG110 is a pretty generic display driver
similar in vein to the Ilitek 93xx devices. It is not a panel
per se but a driver used with several low-cost noname panels.
This is used on the Nomadik NHK15 combined with a OSD
OSD057VA01CT display for WVGA 800x480.
The driver is pretty minimalistic right now but can be
extended to handle non-default polarities, gamma correction
etc.
The driver is based on the baked-in code in
drivers/video/fbdev/amba-clcd-nomadik.c which will be
decomissioned once this us upstream.
Signed-off-by: Linus Walleij
---
ChangeLog v3->v4:
- Tag on the SPI_3WIRE_HIZ flag to the SPI slave mode.
ChangeLog v2->v3:
- Rewrite as an SPI child device.
---
MAINTAINERS | 7 +
drivers/gpu/drm/panel/Kconfig| 10 +
drivers/gpu/drm/panel/Makefile | 1 +
drivers/gpu/drm/panel/panel-tpo-tpg110.c | 506 +++
4 files changed, 524 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-tpo-tpg110.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 690c2f68a401..c3ca56c2a7a6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4746,6 +4746,13 @@ DRM DRIVER FOR TDFX VIDEO CARDS
S: Orphan / Obsolete
F: drivers/gpu/drm/tdfx/
+DRM DRIVER FOR TPO TPG110 PANELS
+M: Linus Walleij
+T: git git://anongit.freedesktop.org/drm/drm-misc
+S: Maintained
+F: drivers/gpu/drm/panel/panel-tpo-tpg110.c
+F: Documentation/devicetree/bindings/display/panel/tpo,tpg110.txt
+
DRM DRIVER FOR USB DISPLAYLINK VIDEO ADAPTERS
M: Dave Airlie
R: Sean Paul
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 6020c30a33b3..b2c8b02894b1 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -186,4 +186,14 @@ config DRM_PANEL_SITRONIX_ST7789V
Say Y here if you want to enable support for the Sitronix
ST7789V controller for 240x320 LCD panels
+config DRM_PANEL_TPO_TPG110
+ tristate "TPO TPG 800x400 panel"
+ depends on OF && SPI && GPIOLIB
+ depends on BACKLIGHT_CLASS_DEVICE
+ select VIDEOMODE_HELPERS
+ help
+ Say Y here if you want to enable support for TPO TPG110
+ 400CH LTPS TFT LCD Single Chip Digital Driver for up to
+ 800x400 LCD panels.
+
endmenu
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 5ccaaa9d13af..9b3a0629d255 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -19,3 +19,4 @@ obj-$(CONFIG_DRM_PANEL_SEIKO_43WVF1G) += panel-seiko-43wvf1g.o
obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o
+obj-$(CONFIG_DRM_PANEL_TPO_TPG110) += panel-tpo-tpg110.o
diff --git a/drivers/gpu/drm/panel/panel-tpo-tpg110.c
b/drivers/gpu/drm/panel/panel-tpo-tpg110.c
new file mode 100644
index ..8e517ea5e73b
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-tpo-tpg110.c
@@ -0,0 +1,506 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Panel driver for the TPO TPG110 400CH LTPS TFT LCD Single Chip
+ * Digital Driver.
+ *
+ * This chip drives a TFT LCD, so it does not know what kind of
+ * display is actually connected to it, so the width and height of that
+ * display needs to be supplied from the machine configuration.
+ *
+ * Author:
+ * Linus Walleij
+ */
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#define TPG110_TEST0x00
+#define TPG110_CHIPID 0x01
+#define TPG110_CTRL1 0x02
+#define TPG110_RES_MASKGENMASK(2, 0)
+#define TPG110_RES_800X480 0x07
+#define TPG110_RES_640X480 0x06
+#define TPG110_RES_480X272 0x05
+#define TPG110_RES_480X640 0x04
+#define TPG110_RES_480X272_D 0x01 /* Dual scan: outputs 800x480 */
+#define TPG110_RES_400X240_D 0x00 /* Dual scan: outputs 800x480 */
+#define TPG110_CTRL2 0x03
+#define TPG110_CTRL2_PMBIT(0)
+#define TPG110_CTRL2_RES_PM_CTRL BIT(7)
+
+/**
+ * struct tpg110_panel_mode - lookup struct for the supported modes
+ */
+struct tpg110_panel_mode {
+ /**
+* @name: the name of this panel
+*/
+ const char *name;
+ /**
+* @magic: the magic value from the detection register
+*/
+ u32 magic;
+ /**
+* @mode: the DRM display mode for this panel
+*/
+ struct drm_display_mode mode;
+ /**
+* @bus_flags: the DRM bus flags for this panel e.g. inverted clock
+*/
+ u32 bus_flags;
+};
+
+/**
+ * struct tpg110 - state container for the TPG110 panel
+ */
+struct tpg110 {
+ /**
+* @dev: the container device
+*/
+
Re: [Freedreno] [DPU PATCH 3/3] drm/msm/dp: add support for DP PLL driver
On Thu, Nov 01, 2018 at 05:03:15PM -0400, Sean Paul wrote:
> On Wed, Oct 10, 2018 at 10:15:59AM -0700, Chandan Uddaraju wrote:
> > Add the needed DP PLL specific files to support
> > display port interface on msm targets.
> >
> > The DP driver calls the DP PLL driver registration.
> > The DP driver sets the link and pixel clock sources.
> >
> > Signed-off-by: Chandan Uddaraju
> > ---
> > drivers/gpu/drm/msm/Kconfig | 16 +
> > drivers/gpu/drm/msm/Makefile | 6 +
> > drivers/gpu/drm/msm/dp/dp_ctrl.c | 1 +
> > drivers/gpu/drm/msm/dp/dp_display.c | 50 +++
> > drivers/gpu/drm/msm/dp/dp_display.h | 3 +
> > drivers/gpu/drm/msm/dp/dp_parser.h| 3 +
> > drivers/gpu/drm/msm/dp/dp_power.c | 77 +++-
> > drivers/gpu/drm/msm/dp/dp_power.h | 2 +
> > drivers/gpu/drm/msm/dp/pll/dp_pll.c | 153
> > drivers/gpu/drm/msm/dp/pll/dp_pll.h | 64
> > drivers/gpu/drm/msm/dp/pll/dp_pll_10nm.c | 401 +++
> > drivers/gpu/drm/msm/dp/pll/dp_pll_10nm.h | 94 +
> > drivers/gpu/drm/msm/dp/pll/dp_pll_10nm_util.c | 531
> > ++
> > 13 files changed, 1389 insertions(+), 12 deletions(-)
> > create mode 100644 drivers/gpu/drm/msm/dp/pll/dp_pll.c
> > create mode 100644 drivers/gpu/drm/msm/dp/pll/dp_pll.h
> > create mode 100644 drivers/gpu/drm/msm/dp/pll/dp_pll_10nm.c
> > create mode 100644 drivers/gpu/drm/msm/dp/pll/dp_pll_10nm.h
> > create mode 100644 drivers/gpu/drm/msm/dp/pll/dp_pll_10nm_util.c
> > +struct msm_dp_pll *msm_dp_pll_10nm_init(struct platform_device *pdev, int
> > id)
> > +{
> > + struct dp_pll_10nm *dp_10nm_pll;
> > + struct msm_dp_pll *pll;
> > + int ret;
> > +
> > + if (!pdev)
> > + return ERR_PTR(-ENODEV);
> > +
> > + dp_10nm_pll = devm_kzalloc(>dev, sizeof(*dp_10nm_pll),
> > GFP_KERNEL);
> > + if (!dp_10nm_pll)
> > + return ERR_PTR(-ENOMEM);
> > +
> > + DBG("DP PLL%d", id);
>
> Please remove (or convert to DRM_DEV_DEBUG)
>
> > +
> > + dp_10nm_pll->pdev = pdev;
> > + dp_10nm_pll->id = id;
> > + dp_pdb = dp_10nm_pll;
> > +
> > + dp_10nm_pll->pll_base = msm_ioremap(pdev, "pll_base", "DP_PLL");
> > + if (IS_ERR_OR_NULL(dp_10nm_pll->pll_base)) {
> > + dev_err(>dev, "failed to map CMN PLL base\n");
>
> Print the error if pll_base is ERR_PTR, same for below.
FWIW the return value from msm_ioremap is always ERR_PTR never NULL. And
msm_ioremap prints error messages on all failures so all you need is:
if (IS_ERR(ptr))
return ERR_CAST(ptr);
> > + return ERR_PTR(-ENOMEM);
>
> You should preserve the error if pll_base is an ERR_PTR, same for below.
>
> > + }
> > +
> > + dp_10nm_pll->phy_base = msm_ioremap(pdev, "phy_base", "DP_PHY");
> > + if (IS_ERR_OR_NULL(dp_10nm_pll->phy_base)) {
> > + dev_err(>dev, "failed to map CMN PHY base\n");
> > + return ERR_PTR(-ENOMEM);
> > + }
> > +
> > + dp_10nm_pll->ln_tx0_base = msm_ioremap(pdev, "ln_tx0_base",
> > "DP_LN_TX0");
> > + if (IS_ERR_OR_NULL(dp_10nm_pll->ln_tx0_base)) {
> > + dev_err(>dev, "failed to map CMN LN_TX0 base\n");
> > + return ERR_PTR(-ENOMEM);
> > + }
> > +
> > + dp_10nm_pll->ln_tx1_base = msm_ioremap(pdev, "ln_tx1_base",
> > "DP_LN_TX1");
> > + if (IS_ERR_OR_NULL(dp_10nm_pll->ln_tx1_base)) {
> > + dev_err(>dev, "failed to map CMN LN_TX1 base\n");
> > + return ERR_PTR(-ENOMEM);
> > + }
Jordan
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2 v4] drm/panel: Augment the TPO TPG110 bindings
The TPO TPG110 bindings were using the DPI bindings (popular
in the fbdev subsystem) but this misses the finer points
learned in the DRM subsystem.
We need to augment the bindings for proper DRM integration:
the timings are expressed by the hardware, not put into the
device tree. I.e. this hardware is self-describing and can
report the resolutions and timings needed. It should not
be described in the device tree.
Further the device was incorrectly modeled with GPIO lines
instead of an SPI child, even though the device was using
SPI.
No known deployments of the device using device tree
exist, so it should be fine to augment the bindings.
Cc: devicet...@vger.kernel.org
Reviewed-by: Rob Herring
Signed-off-by: Linus Walleij
---
ChangeLog v3->v4:
- Drop the high-impedance turn-around flag: this should be
a characteristic of the device driver not a DT property.
- Collect Rob's review tag. (Presumably OK since I just
dropped a property and added nothing.)
ChangeLog v2->v3:
- Rewrite to reflect the fact that the display should be
an SPI child device using 3WIRE SPI.
ChangeLog v1->v2:
- Expand some sections to make it clear what kind of device
this is and that the serial protocol it uses is not
I2C.
---
.../bindings/display/panel/tpo,tpg110.txt | 81 ---
1 file changed, 52 insertions(+), 29 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/panel/tpo,tpg110.txt
b/Documentation/devicetree/bindings/display/panel/tpo,tpg110.txt
index f5e3c6f2095a..40f3d7c713bb 100644
--- a/Documentation/devicetree/bindings/display/panel/tpo,tpg110.txt
+++ b/Documentation/devicetree/bindings/display/panel/tpo,tpg110.txt
@@ -1,47 +1,70 @@
TPO TPG110 Panel
-This binding builds on the DPI bindings, adding a few properties
-as a superset of a DPI. See panel-dpi.txt for the required DPI
-bindings.
+This panel driver is a component that acts as an intermediary
+between an RGB output and a variety of panels. The panel
+driver is strapped up in electronics to the desired resolution
+and other properties, and has a control interface over 3WIRE
+SPI. By talking to the TPG110 over SPI, the strapped properties
+can be discovered and the hardware is therefore mostly
+self-describing.
+
+ ++
+SPI -> | TPO | -> physical display
+RGB -> | TPG110 |
+ ++
+
+If some electrical strap or alternate resolution is desired,
+this can be set up by taking software control of the display
+over the SPI interface. The interface can also adjust
+for properties of the display such as gamma correction and
+certain electrical driving levels.
+
+The TPG110 does not know the physical dimensions of the panel
+connected, so this needs to be specified in the device tree.
+
+It requires a GPIO line for control of its reset line.
+
+The serial protocol has line names that resemble I2C but the
+protocol is not I2C but 3WIRE SPI.
Required properties:
-- compatible : "tpo,tpg110"
+- compatible : one of:
+ "ste,nomadik-nhk15-display", "tpo,tpg110"
+ "tpo,tpg110"
- grestb-gpios : panel reset GPIO
-- scen-gpios : serial control enable GPIO
-- scl-gpios : serial control clock line GPIO
-- sda-gpios : serial control data line GPIO
+- width-mm : see display/panel/panel-common.txt
+- height-mm : see display/panel/panel-common.txt
+
+The device needs to be a child of an SPI bus, see
+spi/spi-bus.txt. The SPI child must set the following
+properties:
+- spi-3wire
+- spi-max-frequency = <300>;
+as these are characteristics of this device.
-Required nodes:
-- Video port for DPI input, see panel-dpi.txt
-- Panel timing for DPI setup, see panel-dpi.txt
+The device node can contain one 'port' child node with one child
+'endpoint' node, according to the bindings defined in
+media/video-interfaces.txt. This node should describe panel's video bus.
Example
---
-panel {
- compatible = "tpo,tpg110", "panel-dpi";
- grestb-gpios = <_gpio44 5 GPIO_ACTIVE_LOW>;
- scen-gpios = < 6 GPIO_ACTIVE_LOW>;
- scl-gpios = < 5 GPIO_ACTIVE_HIGH>;
- sda-gpios = < 4 GPIO_ACTIVE_HIGH>;
+panel: display@0 {
+ compatible = "tpo,tpg110";
+ reg = <0>;
+ spi-3wire;
+ /* 320 ns min period ~= 3 MHz */
+ spi-max-frequency = <300>;
+ /* Width and height from data sheet */
+ width-mm = <116>;
+ height-mm = <87>;
+ grestb-gpios = <_gpio 5 GPIO_ACTIVE_LOW>;
backlight = <>;
port {
nomadik_clcd_panel: endpoint {
- remote-endpoint = <_clcd_pads>;
+ remote-endpoint = <>;
};
};
-
- panel-timing {
- clock-frequency = <3320>;
- hactive = <800>;
- hback-porch = <216>;
- hfront-porch = <40>;
- hsync-len = <1>;
- vactive = <480>;
- vback-porch = <35>;
- vfront-porch = <10>;
- vsync-len = <1>;
[Bug 108613] amdgpu.dc=1 + xf86-video-amdgpu: changing to a GPU upscaling resolution resets pp_dpm_mclk
https://bugs.freedesktop.org/show_bug.cgi?id=108613 --- Comment #4 from dwagner --- This is most certainly a duplicate of bug https://bugs.freedesktop.org/show_bug.cgi?id=107141 (which I would really really like to be fixed one 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
Re: [DPU PATCH 3/3] drm/msm/dp: add support for DP PLL driver
On Wed, Oct 10, 2018 at 10:15:59AM -0700, Chandan Uddaraju wrote:
> Add the needed DP PLL specific files to support
> display port interface on msm targets.
>
> The DP driver calls the DP PLL driver registration.
> The DP driver sets the link and pixel clock sources.
>
> Signed-off-by: Chandan Uddaraju
> ---
> drivers/gpu/drm/msm/Kconfig | 16 +
> drivers/gpu/drm/msm/Makefile | 6 +
> drivers/gpu/drm/msm/dp/dp_ctrl.c | 1 +
> drivers/gpu/drm/msm/dp/dp_display.c | 50 +++
> drivers/gpu/drm/msm/dp/dp_display.h | 3 +
> drivers/gpu/drm/msm/dp/dp_parser.h| 3 +
> drivers/gpu/drm/msm/dp/dp_power.c | 77 +++-
> drivers/gpu/drm/msm/dp/dp_power.h | 2 +
> drivers/gpu/drm/msm/dp/pll/dp_pll.c | 153
> drivers/gpu/drm/msm/dp/pll/dp_pll.h | 64
> drivers/gpu/drm/msm/dp/pll/dp_pll_10nm.c | 401 +++
> drivers/gpu/drm/msm/dp/pll/dp_pll_10nm.h | 94 +
> drivers/gpu/drm/msm/dp/pll/dp_pll_10nm_util.c | 531
> ++
> 13 files changed, 1389 insertions(+), 12 deletions(-)
> create mode 100644 drivers/gpu/drm/msm/dp/pll/dp_pll.c
> create mode 100644 drivers/gpu/drm/msm/dp/pll/dp_pll.h
> create mode 100644 drivers/gpu/drm/msm/dp/pll/dp_pll_10nm.c
> create mode 100644 drivers/gpu/drm/msm/dp/pll/dp_pll_10nm.h
> create mode 100644 drivers/gpu/drm/msm/dp/pll/dp_pll_10nm_util.c
>
> diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig
> index c363f24..1e0b9158 100644
> --- a/drivers/gpu/drm/msm/Kconfig
> +++ b/drivers/gpu/drm/msm/Kconfig
> @@ -58,6 +58,22 @@ config DRM_MSM_DP
> driver. DP external display support is enabled
> through this config option. It can be primary or
> secondary display on device.
> +
> +config DRM_MSM_DP_PLL
> + bool "Enable DP PLL driver in MSM DRM"
> + depends on DRM_MSM_DP && COMMON_CLK
> + default y
The default should be n
> + help
> + Choose this option to enable DP PLL driver which provides DP
> + source clocks under common clock framework.
> +
> +config DRM_MSM_DP_10NM_PLL
> + bool "Enable DP 10nm PLL driver in MSM DRM (used by SDM845)"
> + depends on DRM_MSM_DP
Should this be DRM_MSM_DP_PLL instead?
> + default y
The default should be n
> + help
> + Choose this option if DP PLL on SDM845 is used on the platform.
> +
> config DRM_MSM_DSI
> bool "Enable DSI support in MSM DRM driver"
> depends on DRM_MSM
> diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
> index 765a8d8..8d18353 100644
> --- a/drivers/gpu/drm/msm/Makefile
> +++ b/drivers/gpu/drm/msm/Makefile
> @@ -137,4 +137,10 @@ msm-$(CONFIG_DRM_MSM_DSI_14NM_PHY) +=
> dsi/pll/dsi_pll_14nm.o
> msm-$(CONFIG_DRM_MSM_DSI_10NM_PHY) += dsi/pll/dsi_pll_10nm.o
> endif
>
> +ifeq ($(CONFIG_DRM_MSM_DP_PLL),y)
> +msm-y += dp/pll/dp_pll.o
> +msm-y += dp/pll/dp_pll_10nm.o
> +msm-y += dp/pll/dp_pll_10nm_util.o
Instead of the ifeq, these should follow the form:
msm-$(CONFIG_BLAH) +=
> +endif
> +
> obj-$(CONFIG_DRM_MSM)+= msm.o
> diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c
> b/drivers/gpu/drm/msm/dp/dp_ctrl.c
> index 08a52f5..e23beee 100644
> --- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
> +++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
> @@ -1051,6 +1051,7 @@ static int dp_ctrl_enable_mainlink_clocks(struct
> dp_ctrl_private *ctrl)
> {
> int ret = 0;
>
> + ctrl->power->set_link_clk_parent(ctrl->power);
> ctrl->power->set_pixel_clk_parent(ctrl->power);
>
> dp_ctrl_set_clock_rate(ctrl, "ctrl_link_clk",
> diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
> b/drivers/gpu/drm/msm/dp/dp_display.c
> index 8c98399..2bf6635 100644
> --- a/drivers/gpu/drm/msm/dp/dp_display.c
> +++ b/drivers/gpu/drm/msm/dp/dp_display.c
> @@ -72,6 +72,48 @@ struct dp_display_private {
> {}
> };
>
> +static int dp_get_pll(struct dp_display_private *dp_priv)
> +{
> + struct platform_device *pdev = NULL;
> + struct platform_device *pll_pdev;
> + struct device_node *pll_node;
> + struct dp_parser *dp_parser = NULL;
> +
> + if (!dp_priv) {
> + pr_err("Invalid Arguments\n");
> + return -EINVAL;
> + }
> +
> + pdev = dp_priv->pdev;
> + dp_parser = dp_priv->parser;
> +
> + if (!dp_parser) {
> + pr_err("Parser not initialized.\n");
> + return -EINVAL;
> + }
Can we please remove the unnecessary null checks from this patch too?
> +
> + pll_node = of_parse_phandle(pdev->dev.of_node, "pll-node", 0);
> + if (!pll_node) {
> + dev_err(>dev, "cannot find pll device\n");
> + return -ENXIO;
> + }
> +
> + pll_pdev = of_find_device_by_node(pll_node);
> + if (pll_pdev)
> + dp_parser->pll = platform_get_drvdata(pll_pdev);
What if the pll driver goes away before the dp driver?
> +
> +
Re: [PATCH v2 0/7] BL035-RGB-002 3.5" LCD sunxi DRM support
Hi, Le jeudi 01 novembre 2018 à 21:00 +0100, Paul Kocialkowski a écrit : > The series adds support for the BL035-RGB-002 LCD panel and the required > device-tree bindings for using it on the BananaPi M1. > > Only the changes related to the DRM driver and the panel are submitted > for merge, which does not include the two final commits. > > Changes since v1: > * Used the full name of the panel for dt bindings; > * Removed helper to match flags in order to only retrieve the connector > once, as it was already done. > * Made the bus flags checking possible without a panel; I forgot to mention that the last patch (not for merge) was untested. > Paul Kocialkowski (7): > drm/sun4i: tcon: Pass encoder instead of using panel for RGB setup > drm/sun4i: tcon: Support an active-low DE signal with RGB interface > dt-bindings: Add vendor prefix for LeMaker > dt-bindings: Add bindings for the LeMaker BL035-RGB-002 LCD panel > drm/panel: simple: Add support for the LeMaker BL035-RGB-002 3.5" LCD > ARM: dts: sun7i: Add pinmux configuration for LCD0 RGB888 pins > ARM: dts: sun7i-a20-bananapi: Add bindings for the LeMaker 3.5" LCD > > .../display/panel/lemaker,bl035-rgb-002.txt | 7 ++ > .../devicetree/bindings/vendor-prefixes.txt | 1 + > arch/arm/boot/dts/sun7i-a20-bananapi.dts | 89 +++ > arch/arm/boot/dts/sun7i-a20.dtsi | 11 +++ > drivers/gpu/drm/panel/panel-simple.c | 27 ++ > drivers/gpu/drm/sun4i/sun4i_tcon.c| 29 +++--- > drivers/gpu/drm/sun4i/sun4i_tcon.h| 1 + > 7 files changed, 151 insertions(+), 14 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/display/panel/lemaker,bl035-rgb-002.txt > -- Developer of free digital technology and hardware support. Website: https://www.paulk.fr/ Coding blog: https://code.paulk.fr/ Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/ signature.asc Description: This is a digitally signed message part ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] Add RGBA64 texture cpp for vc4 driver.
Nick Kreeger writes: > This patch is needed to help implement half-float texturing and > rendering for the vc4 driver in mesa. This small patch introduces the > cpp value for the RGBA64 texture. A future patch will include updates to > vc4_render_cl.c to handle HDR color stores. We'll need a GET_PARAM ioctl param to say "we support RGBA64 textures" and use that from vc4_screen.c's format checking, otherwise new Mesa on old kernels will try to expose RGBA64 textures and fail at rendering time. If we're introducing a GET_PARAM, we probably want to just do half float rendering and texturing at the same time. signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH NOT FOR MERGE v2 7/7] ARM: dts: sun7i-a20-bananapi: Add bindings for the LeMaker 3.5" LCD
This adds the backlight panel, power, pwm and tcon0 device-tree bindings
required for supporting the 3.5" LCD from LeMaker on the BananaPi M1.
Signed-off-by: Paul Kocialkowski
---
arch/arm/boot/dts/sun7i-a20-bananapi.dts | 89
1 file changed, 89 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20-bananapi.dts
b/arch/arm/boot/dts/sun7i-a20-bananapi.dts
index 70dfc4ac0bb5..dd2f8bc41fae 100644
--- a/arch/arm/boot/dts/sun7i-a20-bananapi.dts
+++ b/arch/arm/boot/dts/sun7i-a20-bananapi.dts
@@ -48,6 +48,7 @@
#include
#include
+#include
/ {
model = "LeMaker Banana Pi";
@@ -63,6 +64,75 @@
stdout-path = "serial0:115200n8";
};
+
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = < 0 5 0>;
+ brightness-levels = < 0 1 1 1 1 2 2 2
+ 2 3 3 3 3 4 4 4
+ 5 5 5 6 6 6 7 7
+ 8 8 8 9 9 9 10 10
+ 10 11 11 12 12 12 13 13
+ 14 14 14 15 15 16 16 17
+ 17 17 18 18 19 19 20 20
+ 21 21 21 22 22 23 23 24
+ 24 25 25 26 26 27 27 28
+ 28 29 30 30 31 31 32 32
+ 33 33 34 35 35 36 36 37
+ 38 38 39 39 40 41 41 42
+ 43 43 44 44 45 46 47 47
+ 48 49 49 50 51 51 52 53
+ 54 54 55 56 57 57 58 59
+ 60 61 61 62 63 64 65 65
+ 66 67 68 69 70 71 71 72
+ 73 74 75 76 77 78 79 80
+ 81 82 83 84 85 86 87 88
+ 89 90 91 92 93 94 95 96
+ 97 98 99 101 102 103 104 105
+106 108 109 110 111 112 114 115
+116 117 119 120 121 123 124 125
+127 128 129 131 132 133 135 136
+138 139 141 142 144 145 147 148
+150 151 153 154 156 157 159 161
+162 164 166 167 169 171 173 174
+176 178 180 181 183 185 187 189
+191 192 194 196 198 200 202 204
+206 208 210 212 214 216 219 221
+223 225 227 229 232 234 236 238
+241 242 244 246 248 250 253 255>;
+ default-brightness-level = <128>;
+ enable-gpios = < 7 8 GPIO_ACTIVE_HIGH>; /* PH8 */
+ };
+
+ panel: panel {
+ compatible = "lemaker,bl035";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ power-supply = <_power>;
+ backlight = <>;
+
+ port@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ panel_input: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <_out_panel>;
+ };
+ };
+ };
+
+ panel_power: panel_power {
+ compatible = "regulator-fixed";
+ regulator-name = "panel-power";
+ regulator-min-microvolt = <1040>;
+ regulator-max-microvolt = <1040>;
+ gpio = < 7 12 GPIO_ACTIVE_HIGH>; /* PH12 */
+ enable-active-high;
+ regulator-boot-on;
+ };
+
hdmi-connector {
compatible = "hdmi-connector";
type = "a";
@@ -275,6 +345,12 @@
};
};
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins_a>;
+ status = "okay";
+};
+
#include "axp209.dtsi"
_dcdc2 {
@@ -322,6 +398,19 @@
status = "okay";
};
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_rgb888_pins>;
+ status = "okay";
+};
+
+_out {
+ tcon0_out_panel: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <_input>;
+ };
+};
+
{
pinctrl-names = "default";
pinctrl-0 = <_pins_a>;
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 5/7] drm/panel: simple: Add support for the LeMaker BL035-RGB-002 3.5" LCD
This adds support for the 3.5" LCD panel from LeMaker, sold for use with
BananaPi boards. It comes with a 24-bit RGB888 parallel interface and
requires an active-low DE signal
Signed-off-by: Paul Kocialkowski
---
drivers/gpu/drm/panel/panel-simple.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 90296090340e..8e147cfa7b88 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1562,6 +1562,30 @@ static const struct panel_desc kyo_tcg121xglp = {
.bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
};
+static const struct drm_display_mode lemaker_bl035_rgb_002_mode = {
+ .clock = 7000,
+ .hdisplay = 320,
+ .hsync_start = 320 + 20,
+ .hsync_end = 320 + 20 + 30,
+ .htotal = 320 + 20 + 30 + 38,
+ .vdisplay = 240,
+ .vsync_start = 240 + 4,
+ .vsync_end = 240 + 4 + 3,
+ .vtotal = 240 + 4 + 3 + 15,
+ .vrefresh = 60,
+};
+
+static const struct panel_desc lemaker_bl035_rgb_002 = {
+ .modes = _bl035_rgb_002_mode,
+ .num_modes = 1,
+ .size = {
+ .width = 70,
+ .height = 52,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
+ .bus_flags = DRM_BUS_FLAG_DE_LOW,
+};
+
static const struct drm_display_mode lg_lb070wv8_mode = {
.clock = 33246,
.hdisplay = 800,
@@ -2569,6 +2593,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "kyo,tcg121xglp",
.data = _tcg121xglp,
+ }, {
+ .compatible = "lemaker,bl035-rgb-002",
+ .data = _bl035_rgb_002,
}, {
.compatible = "lg,lb070wv8",
.data = _lb070wv8,
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH NOT FOR MERGE v2 6/7] ARM: dts: sun7i: Add pinmux configuration for LCD0 RGB888 pins
This adds the pin muxing definition for configuring the PD pins in LCD0
mode for a RGB888 format to the sun7i device-tree.
Signed-off-by: Paul Kocialkowski
---
arch/arm/boot/dts/sun7i-a20.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index 9c52712af241..26f3714eaad0 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -811,6 +811,17 @@
function = "ir1";
};
+ lcd0_rgb888_pins: lcd0-rgb888 {
+ pins = "PD0", "PD1", "PD2", "PD3",
+ "PD4", "PD5", "PD6", "PD7",
+ "PD8", "PD9", "PD10", "PD11",
+ "PD12", "PD13", "PD14", "PD15",
+ "PD16", "PD17", "PD18", "PD19",
+ "PD20", "PD21", "PD22", "PD23",
+ "PD24", "PD25", "PD26", "PD27";
+ function = "lcd0";
+ };
+
mmc0_pins_a: mmc0@0 {
pins = "PF0", "PF1", "PF2",
"PF3", "PF4", "PF5";
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 4/7] dt-bindings: Add bindings for the LeMaker BL035-RGB-002 LCD panel
This adds the device-tree bindings for the LeMaker BL035-RGB-002 3.5" QVGA TFT LCD panel, compatible with simple-panel. Signed-off-by: Paul Kocialkowski --- .../bindings/display/panel/lemaker,bl035-rgb-002.txt | 7 +++ 1 file changed, 7 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/lemaker,bl035-rgb-002.txt diff --git a/Documentation/devicetree/bindings/display/panel/lemaker,bl035-rgb-002.txt b/Documentation/devicetree/bindings/display/panel/lemaker,bl035-rgb-002.txt new file mode 100644 index ..22cff3eb1b8f --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/lemaker,bl035-rgb-002.txt @@ -0,0 +1,7 @@ +LeMaker BL035-RGB-002 3.5" QVGA TFT LCD panel + +Required properties: +- compatible: should be "lemaker,bl035-rgb-002" + +This binding is compatible with the simple-panel binding, which is specified +in simple-panel.txt in this directory. -- 2.19.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/7] dt-bindings: Add vendor prefix for LeMaker
This introduces a new device-tree binding vendor prefix for Shenzhen LeMaker Technology Co., Ltd. Signed-off-by: Paul Kocialkowski --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 0f5453d1823c..4eecfbf866a4 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -206,6 +206,7 @@ laird Laird PLC lantiq Lantiq Semiconductor latticeLattice Semiconductor lego LEGO Systems A/S +lemakerShenzhen LeMaker Technology Co., Ltd. lenovo Lenovo Group Ltd. lg LG Corporation libretech Shenzhen Libre Technology Co., Ltd -- 2.19.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/7] drm/sun4i: tcon: Support an active-low DE signal with RGB interface
Some panels need an active-low data enable (DE) signal for the RGB interface. This requires flipping a bit in the TCON0 polarity register when setting up the mode for the RGB interface. Match the associated bus flag and use it to set the polarity inversion bit for the DE signal when required. Signed-off-by: Paul Kocialkowski --- drivers/gpu/drm/sun4i/sun4i_tcon.c | 7 ++- drivers/gpu/drm/sun4i/sun4i_tcon.h | 1 + 2 files changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/sun4i_tcon.c index 262ffb6b0f82..0420f5c978b9 100644 --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c @@ -543,6 +543,9 @@ static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon *tcon, if (mode->flags & DRM_MODE_FLAG_PVSYNC) val |= SUN4I_TCON0_IO_POL_VSYNC_POSITIVE; + if (display_info.bus_flags & DRM_BUS_FLAG_DE_LOW) + val |= SUN4I_TCON0_IO_POL_DE_NEGATIVE; + /* * On A20 and similar SoCs, the only way to achieve Positive Edge * (Rising Edge), is setting dclk clock phase to 2/3(240°). @@ -565,7 +568,9 @@ static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon *tcon, clk_set_phase(tcon->dclk, 0); regmap_update_bits(tcon->regs, SUN4I_TCON0_IO_POL_REG, - SUN4I_TCON0_IO_POL_HSYNC_POSITIVE | SUN4I_TCON0_IO_POL_VSYNC_POSITIVE, + SUN4I_TCON0_IO_POL_HSYNC_POSITIVE | + SUN4I_TCON0_IO_POL_VSYNC_POSITIVE | + SUN4I_TCON0_IO_POL_DE_NEGATIVE, val); /* Map output pins to channel 0 */ diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.h b/drivers/gpu/drm/sun4i/sun4i_tcon.h index 3d492c8be1fc..b5214d71610f 100644 --- a/drivers/gpu/drm/sun4i/sun4i_tcon.h +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.h @@ -116,6 +116,7 @@ #define SUN4I_TCON0_IO_POL_REG 0x88 #define SUN4I_TCON0_IO_POL_DCLK_PHASE(phase) ((phase & 3) << 28) +#define SUN4I_TCON0_IO_POL_DE_NEGATIVE BIT(27) #define SUN4I_TCON0_IO_POL_HSYNC_POSITIVE BIT(25) #define SUN4I_TCON0_IO_POL_VSYNC_POSITIVE BIT(24) -- 2.19.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/7] BL035-RGB-002 3.5" LCD sunxi DRM support
The series adds support for the BL035-RGB-002 LCD panel and the required device-tree bindings for using it on the BananaPi M1. Only the changes related to the DRM driver and the panel are submitted for merge, which does not include the two final commits. Changes since v1: * Used the full name of the panel for dt bindings; * Removed helper to match flags in order to only retrieve the connector once, as it was already done. * Made the bus flags checking possible without a panel; Paul Kocialkowski (7): drm/sun4i: tcon: Pass encoder instead of using panel for RGB setup drm/sun4i: tcon: Support an active-low DE signal with RGB interface dt-bindings: Add vendor prefix for LeMaker dt-bindings: Add bindings for the LeMaker BL035-RGB-002 LCD panel drm/panel: simple: Add support for the LeMaker BL035-RGB-002 3.5" LCD ARM: dts: sun7i: Add pinmux configuration for LCD0 RGB888 pins ARM: dts: sun7i-a20-bananapi: Add bindings for the LeMaker 3.5" LCD .../display/panel/lemaker,bl035-rgb-002.txt | 7 ++ .../devicetree/bindings/vendor-prefixes.txt | 1 + arch/arm/boot/dts/sun7i-a20-bananapi.dts | 89 +++ arch/arm/boot/dts/sun7i-a20.dtsi | 11 +++ drivers/gpu/drm/panel/panel-simple.c | 27 ++ drivers/gpu/drm/sun4i/sun4i_tcon.c| 29 +++--- drivers/gpu/drm/sun4i/sun4i_tcon.h| 1 + 7 files changed, 151 insertions(+), 14 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/panel/lemaker,bl035-rgb-002.txt -- 2.19.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/7] drm/sun4i: tcon: Pass encoder instead of using panel for RGB setup
Features such as dithering and pixel data edge configuration currently
rely on the panel registered with the TCON driver. However, bridges are
also supported in addition panels.
Instead of retrieving the connector from the panel, pass the encoder
from the calling function, as is done for other interfaces.
The connector is then retrieved from the encoder with the dedicated
helper. Even in the case of bridges, the connector is registered with
the encoder from our driver and is accessible when iterating connectors.
Signed-off-by: Paul Kocialkowski
---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 22 +-
1 file changed, 9 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index f949287d926c..262ffb6b0f82 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -478,8 +478,11 @@ static void sun4i_tcon0_mode_set_lvds(struct sun4i_tcon
*tcon,
}
static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon *tcon,
+const struct drm_encoder *encoder,
const struct drm_display_mode *mode)
{
+ struct drm_connector *connector = sun4i_tcon_get_connector(encoder);
+ struct drm_display_info display_info = connector->display_info;
unsigned int bp, hsync, vsync;
u8 clk_delay;
u32 val = 0;
@@ -491,8 +494,7 @@ static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon
*tcon,
sun4i_tcon0_mode_set_common(tcon, mode);
/* Set dithering if needed */
- if (tcon->panel)
- sun4i_tcon0_mode_set_dithering(tcon, tcon->panel->connector);
+ sun4i_tcon0_mode_set_dithering(tcon, connector);
/* Adjust clock delay */
clk_delay = sun4i_tcon_get_clk_delay(mode, 0);
@@ -556,17 +558,11 @@ static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon
*tcon,
* Following code is a way to avoid quirks all around TCON
* and DOTCLOCK drivers.
*/
- if (tcon->panel) {
- struct drm_panel *panel = tcon->panel;
- struct drm_connector *connector = panel->connector;
- struct drm_display_info display_info = connector->display_info;
-
- if (display_info.bus_flags & DRM_BUS_FLAG_PIXDATA_POSEDGE)
- clk_set_phase(tcon->dclk, 240);
+ if (display_info.bus_flags & DRM_BUS_FLAG_PIXDATA_POSEDGE)
+ clk_set_phase(tcon->dclk, 240);
- if (display_info.bus_flags & DRM_BUS_FLAG_PIXDATA_NEGEDGE)
- clk_set_phase(tcon->dclk, 0);
- }
+ if (display_info.bus_flags & DRM_BUS_FLAG_PIXDATA_NEGEDGE)
+ clk_set_phase(tcon->dclk, 0);
regmap_update_bits(tcon->regs, SUN4I_TCON0_IO_POL_REG,
SUN4I_TCON0_IO_POL_HSYNC_POSITIVE |
SUN4I_TCON0_IO_POL_VSYNC_POSITIVE,
@@ -684,7 +680,7 @@ void sun4i_tcon_mode_set(struct sun4i_tcon *tcon,
sun4i_tcon0_mode_set_lvds(tcon, encoder, mode);
break;
case DRM_MODE_ENCODER_NONE:
- sun4i_tcon0_mode_set_rgb(tcon, mode);
+ sun4i_tcon0_mode_set_rgb(tcon, encoder, mode);
sun4i_tcon_set_mux(tcon, 0, encoder);
break;
case DRM_MODE_ENCODER_TVDAC:
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108628] Middle-Earth: Shadow of Mordor: artifacts in benchmark mode
https://bugs.freedesktop.org/show_bug.cgi?id=108628 Bug ID: 108628 Summary: Middle-Earth: Shadow of Mordor: artifacts in benchmark mode Product: Mesa Version: 18.2 Hardware: Other OS: Linux (All) Status: NEW Severity: major Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel@lists.freedesktop.org Reporter: jo...@lunarg.com QA Contact: dri-devel@lists.freedesktop.org [Game] Middle-Earth: Shadow of Mordor [Hardware] AMD R9280, R9270 [Mesa Version] 18.2.4 and 18.2.0 (possibly the entire 18.2 branch) [Summary of Problem] The benchmark mode of Middle-Earth: Shadow of Mordor has artifacts in gameplay. I think this might be related to the rain and I can't find a place in the game with rain currently but the problem is reproducible in benchmark mode. [links to images] Here is a link to some picture of the game in our test suite, the left picture is the bad one and right is the good: https://share.lunarg.com/opengl/report/2404#images/two-up/614953 https://share.lunarg.com/opengl/report/2404#images/two-up/614954 -- 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: [Freedreno] [PATCH 1/2] drm/msm: use common display thread for dispatching vblank events
On Wed, Oct 31, 2018 at 05:19:04PM -0700, Jeykumar Sankaran wrote:
> DPU was using one thread per display to dispatch async
> commits and vblank requests. Since clean up already happened
> in msm to use the common thread for all the display commits,
> display threads are only used to cater vblank requests. Single
> thread is sufficient to do the job without any performance hits.
>
> Signed-off-by: Jeykumar Sankaran
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 6 +---
> drivers/gpu/drm/msm/msm_drv.c | 50
> -
> drivers/gpu/drm/msm/msm_drv.h | 2 +-
> 3 files changed, 23 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> index 82c55ef..aff20f5 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> @@ -753,11 +753,7 @@ static int dpu_encoder_resource_control(struct
> drm_encoder *drm_enc,
> is_vid_mode = dpu_enc->disp_info.capabilities &
> MSM_DISPLAY_CAP_VID_MODE;
>
> - if (drm_enc->crtc->index >= ARRAY_SIZE(priv->disp_thread)) {
> - DPU_ERROR("invalid crtc index\n");
> - return -EINVAL;
> - }
> - disp_thread = >disp_thread[drm_enc->crtc->index];
> + disp_thread = >disp_thread;
>
> /*
>* when idle_pc is not supported, process only KICKOFF, STOP and MODESET
> diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
> index 9c9f7ff..1f384b3 100644
> --- a/drivers/gpu/drm/msm/msm_drv.c
> +++ b/drivers/gpu/drm/msm/msm_drv.c
> @@ -257,8 +257,7 @@ static int vblank_ctrl_queue_work(struct msm_drm_private
> *priv,
> list_add_tail(_ev->node, _ctrl->event_list);
> spin_unlock_irqrestore(_ctrl->lock, flags);
>
> - kthread_queue_work(>disp_thread[crtc_id].worker,
> - _ctrl->work);
> + kthread_queue_work(>disp_thread.worker, _ctrl->work);
>
> return 0;
> }
> @@ -284,14 +283,12 @@ static int msm_drm_uninit(struct device *dev)
> kfree(vbl_ev);
> }
>
> + kthread_flush_worker(>disp_thread.worker);
> + kthread_stop(priv->disp_thread.thread);
> + priv->disp_thread.thread = NULL;
> +
kthread doesn't check for NULL or error - you'll want a
if (!IS_ERR(priv->disp_thread.worker)) check for this block.
> /* clean up display commit/event worker threads */
> for (i = 0; i < priv->num_crtcs; i++) {
> - if (priv->disp_thread[i].thread) {
> - kthread_flush_worker(>disp_thread[i].worker);
> - kthread_stop(priv->disp_thread[i].thread);
> - priv->disp_thread[i].thread = NULL;
> - }
> -
> if (priv->event_thread[i].thread) {
> kthread_flush_worker(>event_thread[i].worker);
> kthread_stop(priv->event_thread[i].thread);
> @@ -537,6 +534,22 @@ static int msm_drm_init(struct device *dev, struct
> drm_driver *drv)
> ddev->mode_config.funcs = _config_funcs;
> ddev->mode_config.helper_private = _config_helper_funcs;
>
> + /* initialize display thread */
> + kthread_init_worker(>disp_thread.worker);
> + priv->disp_thread.dev = ddev;
> + priv->disp_thread.thread = kthread_run(kthread_worker_fn,
> +>disp_thread.worker,
> +"disp_thread");
This name should be more descriptive for the driver - disp_thread is a bit
generic.
> + if (IS_ERR(priv->disp_thread.thread)) {
> + DRM_DEV_ERROR(dev, "failed to create crtc_commit kthread\n");
> + priv->disp_thread.thread = NULL;
You don't need this if you check for !IS_ERR in msm_drm_uninit.
> + goto err_msm_uninit;
> + }
> +
> + ret = sched_setscheduler(priv->disp_thread.thread, SCHED_FIFO, );
> + if (ret)
> + pr_warn("display thread priority update failed: %d\n", ret);
> +
Jordan
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108627] [CI][BAT] igt@pm_rpm@module-reload - timeout - pm_rpm: executing$
https://bugs.freedesktop.org/show_bug.cgi?id=108627 Martin Peres changed: What|Removed |Added Status|RESOLVED|CLOSED -- 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: [Freedreno] [PATCH 2/2] drm/msm: subclass work object for vblank events
On Wed, Oct 31, 2018 at 05:19:05PM -0700, Jeykumar Sankaran wrote:
> msm maintains a separate structure to define vblank
> work definitions and a list to track events submitted
> to the display worker thread. We can avoid these
> redundant list and its protection mechanism, if we
> subclass the work object to encapsulate vblank
> event parameters.
>
> Signed-off-by: Jeykumar Sankaran
> ---
> drivers/gpu/drm/msm/msm_drv.c | 70
> ---
> drivers/gpu/drm/msm/msm_drv.h | 7 -
> 2 files changed, 19 insertions(+), 58 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
> index 1f384b3..67a96ee 100644
> --- a/drivers/gpu/drm/msm/msm_drv.c
> +++ b/drivers/gpu/drm/msm/msm_drv.c
> @@ -203,61 +203,44 @@ u32 msm_readl(const void __iomem *addr)
> return val;
> }
>
> -struct vblank_event {
> - struct list_head node;
> +struct msm_vblank_work {
> + struct kthread_work work;
> int crtc_id;
> bool enable;
> + struct msm_drm_private *priv;
> };
>
> static void vblank_ctrl_worker(struct kthread_work *work)
> {
> - struct msm_vblank_ctrl *vbl_ctrl = container_of(work,
> - struct msm_vblank_ctrl, work);
> - struct msm_drm_private *priv = container_of(vbl_ctrl,
> - struct msm_drm_private, vblank_ctrl);
> + struct msm_vblank_work *vbl_work = container_of(work,
> + struct msm_vblank_work, work);
> + struct msm_drm_private *priv = vbl_work->priv;
> struct msm_kms *kms = priv->kms;
> - struct vblank_event *vbl_ev, *tmp;
> - unsigned long flags;
> -
> - spin_lock_irqsave(_ctrl->lock, flags);
> - list_for_each_entry_safe(vbl_ev, tmp, _ctrl->event_list, node) {
> - list_del(_ev->node);
> - spin_unlock_irqrestore(_ctrl->lock, flags);
> -
> - if (vbl_ev->enable)
> - kms->funcs->enable_vblank(kms,
> - priv->crtcs[vbl_ev->crtc_id]);
> - else
> - kms->funcs->disable_vblank(kms,
> - priv->crtcs[vbl_ev->crtc_id]);
>
> - kfree(vbl_ev);
> -
> - spin_lock_irqsave(_ctrl->lock, flags);
> - }
> + if (vbl_work->enable)
> + kms->funcs->enable_vblank(kms, priv->crtcs[vbl_work->crtc_id]);
> + else
> + kms->funcs->disable_vblank(kms, priv->crtcs[vbl_work->crtc_id]);
>
> - spin_unlock_irqrestore(_ctrl->lock, flags);
> + kfree(vbl_work);
> }
>
> static int vblank_ctrl_queue_work(struct msm_drm_private *priv,
> int crtc_id, bool enable)
> {
> - struct msm_vblank_ctrl *vbl_ctrl = >vblank_ctrl;
> - struct vblank_event *vbl_ev;
> - unsigned long flags;
> + struct msm_vblank_work *vbl_work;
>
> - vbl_ev = kzalloc(sizeof(*vbl_ev), GFP_ATOMIC);
> - if (!vbl_ev)
> + vbl_work = kzalloc(sizeof(*vbl_work), GFP_ATOMIC);
> + if (!vbl_work)
> return -ENOMEM;
>
> - vbl_ev->crtc_id = crtc_id;
> - vbl_ev->enable = enable;
> + kthread_init_work(_work->work, vblank_ctrl_worker);
>
> - spin_lock_irqsave(_ctrl->lock, flags);
> - list_add_tail(_ev->node, _ctrl->event_list);
> - spin_unlock_irqrestore(_ctrl->lock, flags);
> + vbl_work->crtc_id = crtc_id;
> + vbl_work->enable = enable;
> + vbl_work->priv = priv;
>
> - kthread_queue_work(>disp_thread.worker, _ctrl->work);
> + kthread_queue_work(>disp_thread.worker, _work->work);
So I think this can get even more simplified. In the short term, you can just
use the systemwq to do the enable and disable.
In the long term, the enable_vblank/disable_vblank functions should be
optimized so they don't sleep. I took a quick look at them perhaps this is
all because of the crtc_lock mutex? That lock seems a bit suspicious to me,
especially being dropped around the pm_runtime calls in
_dpu_crtc_vblank_enable_no_lock(). I think we could probably rely on the modeset
locks for some of these functions, and perhaps convert it to a spinlock if we
can't get rid of it entirely.
Sean
>
> return 0;
> }
> @@ -269,20 +252,8 @@ static int msm_drm_uninit(struct device *dev)
> struct msm_drm_private *priv = ddev->dev_private;
> struct msm_kms *kms = priv->kms;
> struct msm_mdss *mdss = priv->mdss;
> - struct msm_vblank_ctrl *vbl_ctrl = >vblank_ctrl;
> - struct vblank_event *vbl_ev, *tmp;
> int i;
>
> - /* We must cancel and cleanup any pending vblank enable/disable
> - * work before drm_irq_uninstall() to avoid work re-enabling an
> - * irq after uninstall has disabled it.
> - */
> - kthread_flush_work(_ctrl->work);
> - list_for_each_entry_safe(vbl_ev, tmp, _ctrl->event_list, node) {
> -
Re: [Freedreno] [PATCH 1/2] drm/msm: use common display thread for dispatching vblank events
On Wed, Oct 31, 2018 at 05:19:04PM -0700, Jeykumar Sankaran wrote:
> DPU was using one thread per display to dispatch async
> commits and vblank requests. Since clean up already happened
> in msm to use the common thread for all the display commits,
> display threads are only used to cater vblank requests. Single
> thread is sufficient to do the job without any performance hits.
>
> Signed-off-by: Jeykumar Sankaran
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 6 +---
> drivers/gpu/drm/msm/msm_drv.c | 50
> -
> drivers/gpu/drm/msm/msm_drv.h | 2 +-
> 3 files changed, 23 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> index 82c55ef..aff20f5 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> @@ -753,11 +753,7 @@ static int dpu_encoder_resource_control(struct
> drm_encoder *drm_enc,
> is_vid_mode = dpu_enc->disp_info.capabilities &
> MSM_DISPLAY_CAP_VID_MODE;
>
> - if (drm_enc->crtc->index >= ARRAY_SIZE(priv->disp_thread)) {
> - DPU_ERROR("invalid crtc index\n");
> - return -EINVAL;
> - }
> - disp_thread = >disp_thread[drm_enc->crtc->index];
> + disp_thread = >disp_thread;
>
> /*
>* when idle_pc is not supported, process only KICKOFF, STOP and MODESET
> diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
> index 9c9f7ff..1f384b3 100644
> --- a/drivers/gpu/drm/msm/msm_drv.c
> +++ b/drivers/gpu/drm/msm/msm_drv.c
> @@ -257,8 +257,7 @@ static int vblank_ctrl_queue_work(struct msm_drm_private
> *priv,
> list_add_tail(_ev->node, _ctrl->event_list);
> spin_unlock_irqrestore(_ctrl->lock, flags);
>
> - kthread_queue_work(>disp_thread[crtc_id].worker,
> - _ctrl->work);
> + kthread_queue_work(>disp_thread.worker, _ctrl->work);
>
> return 0;
> }
> @@ -284,14 +283,12 @@ static int msm_drm_uninit(struct device *dev)
> kfree(vbl_ev);
> }
>
> + kthread_flush_worker(>disp_thread.worker);
> + kthread_stop(priv->disp_thread.thread);
I realize this is moving existing code, but is there a race here? You can't have
work enqueued in between the flush and stop?
You might also want to use kthread_destroy_worker to do this work (in a
follow-up patch including the event threads too).
> + priv->disp_thread.thread = NULL;
> +
> /* clean up display commit/event worker threads */
This comment needs updating now
> for (i = 0; i < priv->num_crtcs; i++) {
> - if (priv->disp_thread[i].thread) {
> - kthread_flush_worker(>disp_thread[i].worker);
> - kthread_stop(priv->disp_thread[i].thread);
> - priv->disp_thread[i].thread = NULL;
> - }
> -
> if (priv->event_thread[i].thread) {
> kthread_flush_worker(>event_thread[i].worker);
> kthread_stop(priv->event_thread[i].thread);
> @@ -537,6 +534,22 @@ static int msm_drm_init(struct device *dev, struct
> drm_driver *drv)
> ddev->mode_config.funcs = _config_funcs;
> ddev->mode_config.helper_private = _config_helper_funcs;
>
> + /* initialize display thread */
> + kthread_init_worker(>disp_thread.worker);
> + priv->disp_thread.dev = ddev;
> + priv->disp_thread.thread = kthread_run(kthread_worker_fn,
> +>disp_thread.worker,
> +"disp_thread");
> + if (IS_ERR(priv->disp_thread.thread)) {
> + DRM_DEV_ERROR(dev, "failed to create crtc_commit kthread\n");
> + priv->disp_thread.thread = NULL;
> + goto err_msm_uninit;
> + }
> +
> + ret = sched_setscheduler(priv->disp_thread.thread, SCHED_FIFO, );
> + if (ret)
> + pr_warn("display thread priority update failed: %d\n", ret);
> +
> /**
>* this priority was found during empiric testing to have appropriate
>* realtime scheduling to process display updates and interact with
> @@ -544,27 +557,6 @@ static int msm_drm_init(struct device *dev, struct
> drm_driver *drv)
>*/
> param.sched_priority = 16;
> for (i = 0; i < priv->num_crtcs; i++) {
> -
> - /* initialize display thread */
> - priv->disp_thread[i].crtc_id = priv->crtcs[i]->base.id;
> - kthread_init_worker(>disp_thread[i].worker);
> - priv->disp_thread[i].dev = ddev;
> - priv->disp_thread[i].thread =
> - kthread_run(kthread_worker_fn,
> - >disp_thread[i].worker,
> - "crtc_commit:%d", priv->disp_thread[i].crtc_id);
> - if
[PATCH 3/3] drm/atomic: Use explicit old/new state in drm_atomic_plane_check()
From: Ville Syrjälä
Convert drm_atomic_plane_check() over to using explicit old vs. new
plane states. Avoids the confusion of "what does plane->state mean
again?".
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_atomic.c | 90 ++--
1 file changed, 46 insertions(+), 44 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index dde696181efe..46f8d798efaf 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -492,108 +492,109 @@ drm_atomic_get_plane_state(struct drm_atomic_state
*state,
EXPORT_SYMBOL(drm_atomic_get_plane_state);
static bool
-plane_switching_crtc(struct drm_atomic_state *state,
-struct drm_plane *plane,
-struct drm_plane_state *plane_state)
+plane_switching_crtc(const struct drm_plane_state *old_plane_state,
+const struct drm_plane_state *new_plane_state)
{
- if (!plane->state->crtc || !plane_state->crtc)
- return false;
-
- if (plane->state->crtc == plane_state->crtc)
- return false;
-
/* This could be refined, but currently there's no helper or driver code
* to implement direct switching of active planes nor userspace to take
* advantage of more direct plane switching without the intermediate
* full OFF state.
*/
- return true;
+ return old_plane_state->crtc && new_plane_state->crtc &&
+ old_plane_state->crtc != new_plane_state->crtc;
}
/**
* drm_atomic_plane_check - check plane state
- * @plane: plane to check
- * @state: plane state to check
+ * @old_plane_state: old plane state to check
+ * @new_plane_state: new plane state to check
*
* Provides core sanity checks for plane state.
*
* RETURNS:
* Zero on success, error code on failure
*/
-static int drm_atomic_plane_check(struct drm_plane *plane,
- struct drm_plane_state *state)
+static int drm_atomic_plane_check(const struct drm_plane_state
*old_plane_state,
+ const struct drm_plane_state *new_plane_state)
{
+ struct drm_plane *plane = new_plane_state->plane;
+ struct drm_crtc *crtc = new_plane_state->crtc;
+ const struct drm_framebuffer *fb = new_plane_state->fb;
unsigned int fb_width, fb_height;
int ret;
/* either *both* CRTC and FB must be set, or neither */
- if (state->crtc && !state->fb) {
+ if (crtc && !fb) {
DRM_DEBUG_ATOMIC("[PLANE:%d:%s] CRTC set but no FB\n",
plane->base.id, plane->name);
return -EINVAL;
- } else if (state->fb && !state->crtc) {
+ } else if (fb && !crtc) {
DRM_DEBUG_ATOMIC("[PLANE:%d:%s] FB set but no CRTC\n",
plane->base.id, plane->name);
return -EINVAL;
}
/* if disabled, we don't care about the rest of the state: */
- if (!state->crtc)
+ if (!crtc)
return 0;
/* Check whether this plane is usable on this CRTC */
- if (!(plane->possible_crtcs & drm_crtc_mask(state->crtc))) {
+ if (!(plane->possible_crtcs & drm_crtc_mask(crtc))) {
DRM_DEBUG_ATOMIC("Invalid [CRTC:%d:%s] for [PLANE:%d:%s]\n",
-state->crtc->base.id, state->crtc->name,
+crtc->base.id, crtc->name,
plane->base.id, plane->name);
return -EINVAL;
}
/* Check whether this plane supports the fb pixel format. */
- ret = drm_plane_check_pixel_format(plane, state->fb->format->format,
- state->fb->modifier);
+ ret = drm_plane_check_pixel_format(plane, fb->format->format,
+ fb->modifier);
if (ret) {
struct drm_format_name_buf format_name;
DRM_DEBUG_ATOMIC("[PLANE:%d:%s] invalid pixel format %s,
modifier 0x%llx\n",
plane->base.id, plane->name,
-drm_get_format_name(state->fb->format->format,
+drm_get_format_name(fb->format->format,
_name),
-state->fb->modifier);
+fb->modifier);
return ret;
}
/* Give drivers some help against integer overflows */
- if (state->crtc_w > INT_MAX ||
- state->crtc_x > INT_MAX - (int32_t) state->crtc_w ||
- state->crtc_h > INT_MAX ||
- state->crtc_y > INT_MAX - (int32_t) state->crtc_h) {
+ if (new_plane_state->crtc_w > INT_MAX ||
+ new_plane_state->crtc_x > INT_MAX - (int32_t)
new_plane_state->crtc_w ||
+ new_plane_state->crtc_h > INT_MAX ||
+
[PATCH 2/3] drm/atomic: Use explicit old/new state in drm_atomic_crtc_check()
From: Ville Syrjälä
Convert drm_atomic_crtc_check() over to using explicit old vs. new
crtc states. Avoids the confusion of "what does crtc->state mean
again?".
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_atomic.c | 26 +++---
1 file changed, 15 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 064c48075917..dde696181efe 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -315,9 +315,11 @@ drm_atomic_get_crtc_state(struct drm_atomic_state *state,
}
EXPORT_SYMBOL(drm_atomic_get_crtc_state);
-static int drm_atomic_crtc_check(struct drm_crtc *crtc,
- struct drm_crtc_state *state)
+static int drm_atomic_crtc_check(const struct drm_crtc_state *old_crtc_state,
+const struct drm_crtc_state *new_crtc_state)
{
+ struct drm_crtc *crtc = new_crtc_state->crtc;
+
/* NOTE: we explicitly don't enforce constraints such as primary
* layer covering entire screen, since that is something we want
* to allow (on hw that supports it). For hw that does not, it
@@ -326,7 +328,7 @@ static int drm_atomic_crtc_check(struct drm_crtc *crtc,
* TODO: Add generic modeset state checks once we support those.
*/
- if (state->active && !state->enable) {
+ if (new_crtc_state->active && !new_crtc_state->enable) {
DRM_DEBUG_ATOMIC("[CRTC:%d:%s] active without enabled\n",
crtc->base.id, crtc->name);
return -EINVAL;
@@ -336,14 +338,14 @@ static int drm_atomic_crtc_check(struct drm_crtc *crtc,
* as this is a kernel-internal detail that userspace should never
* be able to trigger. */
if (drm_core_check_feature(crtc->dev, DRIVER_ATOMIC) &&
- WARN_ON(state->enable && !state->mode_blob)) {
+ WARN_ON(new_crtc_state->enable && !new_crtc_state->mode_blob)) {
DRM_DEBUG_ATOMIC("[CRTC:%d:%s] enabled without mode blob\n",
crtc->base.id, crtc->name);
return -EINVAL;
}
if (drm_core_check_feature(crtc->dev, DRIVER_ATOMIC) &&
- WARN_ON(!state->enable && state->mode_blob)) {
+ WARN_ON(!new_crtc_state->enable && new_crtc_state->mode_blob)) {
DRM_DEBUG_ATOMIC("[CRTC:%d:%s] disabled with mode blob\n",
crtc->base.id, crtc->name);
return -EINVAL;
@@ -359,7 +361,8 @@ static int drm_atomic_crtc_check(struct drm_crtc *crtc,
* and legacy page_flip IOCTL which also reject service on a disabled
* pipe.
*/
- if (state->event && !state->active && !crtc->state->active) {
+ if (new_crtc_state->event &&
+ !new_crtc_state->active && !old_crtc_state->active) {
DRM_DEBUG_ATOMIC("[CRTC:%d:%s] requesting event but off\n",
crtc->base.id, crtc->name);
return -EINVAL;
@@ -965,7 +968,8 @@ int drm_atomic_check_only(struct drm_atomic_state *state)
struct drm_plane *plane;
struct drm_plane_state *plane_state;
struct drm_crtc *crtc;
- struct drm_crtc_state *crtc_state;
+ struct drm_crtc_state *old_crtc_state;
+ struct drm_crtc_state *new_crtc_state;
struct drm_connector *conn;
struct drm_connector_state *conn_state;
int i, ret = 0;
@@ -981,8 +985,8 @@ int drm_atomic_check_only(struct drm_atomic_state *state)
}
}
- for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
- ret = drm_atomic_crtc_check(crtc, crtc_state);
+ for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state,
new_crtc_state, i) {
+ ret = drm_atomic_crtc_check(old_crtc_state, new_crtc_state);
if (ret) {
DRM_DEBUG_ATOMIC("[CRTC:%d:%s] atomic core check
failed\n",
crtc->base.id, crtc->name);
@@ -1010,8 +1014,8 @@ int drm_atomic_check_only(struct drm_atomic_state *state)
}
if (!state->allow_modeset) {
- for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
- if (drm_atomic_crtc_needs_modeset(crtc_state)) {
+ for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) {
+ if (drm_atomic_crtc_needs_modeset(new_crtc_state)) {
DRM_DEBUG_ATOMIC("[CRTC:%d:%s] requires full
modeset\n",
crtc->base.id, crtc->name);
return -EINVAL;
--
2.18.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] drm/atomic: Use explicit old crtc state in drm_atomic_add_affected_planes()
From: Ville Syrjälä
Replace 'crtc->state' with the explicit old crtc state.
Actually it shouldn't matter whether we use the old or the new
crtc state here since any plane that has been removed from the
crtc since the crtc state was duplicated will have been added
to the atomic state already. That is, you can't call
drm_atomic_set_crtc_for_plane() without having the new
plane state already in hand.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_atomic.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 3dbfbddae7e6..064c48075917 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -927,6 +927,8 @@ int
drm_atomic_add_affected_planes(struct drm_atomic_state *state,
struct drm_crtc *crtc)
{
+ const struct drm_crtc_state *old_crtc_state =
+ drm_atomic_get_old_crtc_state(state, crtc);
struct drm_plane *plane;
WARN_ON(!drm_atomic_get_new_crtc_state(state, crtc));
@@ -934,7 +936,7 @@ drm_atomic_add_affected_planes(struct drm_atomic_state
*state,
DRM_DEBUG_ATOMIC("Adding all current planes for [CRTC:%d:%s] to %p\n",
crtc->base.id, crtc->name, state);
- drm_for_each_plane_mask(plane, state->dev, crtc->state->plane_mask) {
+ drm_for_each_plane_mask(plane, state->dev, old_crtc_state->plane_mask) {
struct drm_plane_state *plane_state =
drm_atomic_get_plane_state(state, plane);
--
2.18.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106175] amdgpu.dc=1 shows performance issues with Xorg compositors when moving windows
https://bugs.freedesktop.org/show_bug.cgi?id=106175 --- Comment #38 from bmil...@gmail.com --- (In reply to tempel.julian from comment #37) > I think software cursor would also be unusable even if it left pageflipping > on. It causes nasty issues like flickering cursor or other visual corruption. Yes I also noticed those, I think we can open another issue for that. -- 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 108627] [CI][BAT] igt@pm_rpm@module-reload - timeout - pm_rpm: executing$
https://bugs.freedesktop.org/show_bug.cgi?id=108627 Martin Peres changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Martin Peres --- *** This bug has been marked as a duplicate of bug 108075 *** -- 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 108075] [CI][BAT] igt@amdgpu/amd_prime@(amd-to-i915|i915-to-amd) - timeout - last line in dmesg "[IGT] amd_prime: executing"
https://bugs.freedesktop.org/show_bug.cgi?id=108075 --- Comment #2 from Martin Peres --- *** Bug 108627 has been marked as a duplicate of this bug. *** -- 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 108075] [CI][BAT] igt@amdgpu/amd_prime@(amd-to-i915|i915-to-amd) - timeout - last line in dmesg "[IGT] amd_prime: executing"
https://bugs.freedesktop.org/show_bug.cgi?id=108075 Martin Peres changed: What|Removed |Added Component|DRM/Intel |IGT QA Contact|intel-gfx-bugs@lists.freede | |sktop.org | Assignee|intel-gfx-bugs@lists.freede |dri-devel@lists.freedesktop |sktop.org |.org -- 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 108627] [CI][BAT] igt@pm_rpm@module-reload - timeout - pm_rpm: executing$
https://bugs.freedesktop.org/show_bug.cgi?id=108627 Martin Peres changed: What|Removed |Added Component|DRM/Intel |IGT QA Contact|intel-gfx-bugs@lists.freede | |sktop.org | Assignee|intel-gfx-bugs@lists.freede |dri-devel@lists.freedesktop |sktop.org |.org --- Comment #2 from Martin Peres --- (In reply to Chris Wilson from comment #1) > Nothing much we expect the test to do here; the expectation is that CI > runner reads the fatal kernel taint (from the earlier test hitting a GPF in > video/) and reboots. Thanks, moving to IGT! -- 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 106175] amdgpu.dc=1 shows performance issues with Xorg compositors when moving windows
https://bugs.freedesktop.org/show_bug.cgi?id=106175 --- Comment #37 from tempel.jul...@gmail.com --- I think software cursor would also be unusable even if it left pageflipping on. It causes nasty issues like flickering cursor or other visual corruption. -- 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 106175] amdgpu.dc=1 shows performance issues with Xorg compositors when moving windows
https://bugs.freedesktop.org/show_bug.cgi?id=106175 --- Comment #36 from bmil...@gmail.com --- So, to help find the origin of the issue, there are a few options that get rid of stutter when compositing: 1 - amdgpu.dc=0 - The old DC seems unaffected by the bug. 2 - SWcursor on - Unaffected by bug because it disables pageflipping 3 - Pageflipping off -- 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 108625] AMDGPU - Can't even get Xorg to start - Kernel driver hangs with ring buffer timeout on ARM64
https://bugs.freedesktop.org/show_bug.cgi?id=108625 --- Comment #1 from Alex Deucher --- Please attach your full dmesg output and xorg log if using X. -- 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 106175] amdgpu.dc=1 shows performance issues with Xorg compositors when moving windows
https://bugs.freedesktop.org/show_bug.cgi?id=106175 --- Comment #35 from bmil...@gmail.com --- (In reply to Michel Dänzer from comment #31) > Note that SWcursor completely disables page flipping, at least with > xf86-video-amdgpu, because the two things are fundamentally incompatible > with each other. Does only disabling page flipping also avoid the problem? Justed tested it and yes, disabling pageflip also gets rid of stutter for me. -- 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 108606] Raven Ridge: constant lockups since latest pull from Linus
https://bugs.freedesktop.org/show_bug.cgi?id=108606 --- Comment #16 from Samantha McVey --- Created attachment 142330 --> https://bugs.freedesktop.org/attachment.cgi?id=142330=edit amdgpu.ppfeaturemask=0xfffdbfff lockup during normal usage I did more testing on amdgpu.ppfeaturemask=0xfffdbfff, and I just got the gpu lockup while browsing the web. I am going to do further testing of the other command line option to see if that will trigger any freezes during more extended usage. But it looks like 0xfffdbfff is confirmed as triggering the bug. -- 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 201585] 144Hz 2560x1440 no longer works (caps at 120Hz)
https://bugzilla.kernel.org/show_bug.cgi?id=201585 --- Comment #8 from Dan Acristinii (d...@acristinii.com) --- Created attachment 279289 --> https://bugzilla.kernel.org/attachment.cgi?id=279289=edit 4.18 with drm.debug=4 I think I added it in the right way -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 3/4] drm: Document variable refresh properties
On 11/1/18 1:05 PM, Michel Dänzer wrote: > On 2018-11-01 3:58 p.m., Kazlauskas, Nicholas wrote: >> On 11/1/18 6:58 AM, Michel Dänzer wrote: >>> On 2018-10-31 6:54 p.m., Kazlauskas, Nicholas wrote: On 10/31/18 12:20 PM, Michel Dänzer wrote: > On 2018-10-31 3:41 p.m., Kazlauskas, Nicholas wrote: >> On 10/31/18 10:12 AM, Michel Dänzer wrote: >>> On 2018-10-31 2:38 p.m., Kazlauskas, Nicholas wrote: I did some more investigation into when amdgpu gets the scanout position and what values we get back out of it. The timestamp is updated shortly after the crtc irq vblank which is typically within a few lines of vbl_start. This makes sense, since we can provide the prediction timestamp early. Waiting for the vblank to wrap around to 0 doesn't really make sense here since that would mean we already hit timeout or the flip occurred >>> >>> Sounds like you're mixing up the two cases of "actual" vblank events >>> (triggered by the "vblank" interrupt => drm_(crtc_)handle_vblank) and >>> flip completion events (triggered by the PFLIP interrupt with our >>> hardware => drm_crtc_send_vblank_event). >>> >>> Actual vblank events need to be delivered to userspace at the start of >>> vblank, so we indeed can't wait until the timestamp is accurate for >>> them. We just need to document the exact semantics of their timestamp >>> with VRR. >>> >>> For page flip completion events though, the timestamp needs to be >>> accurate and correspond to when the flipped frame starts being scanned >>> out, otherwise we'll surely break at least some userspace relying on >>> this information. >>> >> Yeah, I was. I guess what's sent is the estimated vblank timestamp >> calculated at the start of the interrupt. > > s/interrupt/vblank/, yeah. > > >> And since that's just a guess rather than what's actually going to >> happen it's going to be wrong in a lot of cases. >> >> I could see the wrap-around method working if the vblank timestamp was >> somehow updated in amdgpu or in drm_crtc_send_vblank_event. > > DC already calls drm_crtc_accurate_vblank_count before > drm_crtc_send_vblank_event, we "just" need to make sure that results in > an accurate timestamp. > > >> This would be a relatively simple fix but would break anything in >> userspace that relied on the timestamp for vblank interrupt and the >> flip completion being the same value. > > Hmm, that's a good point. So while VRR is enabled, maybe it is safer to > defer delivery of vblank events until the accurate timestamp is known as > well, at least by default. If there is userspace which needs the events > earlier even with VRR but can live with the guessed timestamp, a flag or > something could be added for that. I was under the impression that the vblank timestamp was reused but it's already going to differ since we call drm_crtc_accurate_vblank_count before drm_crtc_send_vblank_event. Thanks for pointing that out. Since that works for updating timestamp what's left is making sure that it waits for the wrap around if it's above crtc_vtotal. It might make sense to add a new flag for this that's only used within amdgpu_get_crtc_scanout_position so the other call sites aren't affected. There isn't a way to get an accurate timestamp with VRR enabled until after the flip happens. So deferring it kind of defeats the purpose of a client using it to make predictions before the flip for displaying their content. >>> >>> That's generally not a valid use-case. The KMS API is defined such that >>> if userspace receives the vblank event for vblank period N and then >>> submits a page flip, the page flip cannot (normally[0]) take effect >>> before vblank period N+1. >>> >>> >>> There are mainly two valid use-cases for waiting for vblank: >>> >>> 1. Wait for vblank N, then submit page flip for vblank N+1. >>> >>> 2. Wait for vblank N, then try to do something before vblank N ends, >>> e.g. draw directly to the front buffer, as a poor man's way of avoiding >>> tearing or similar artifacts. >>> >>> >>> Use-case 1 is used by Xorg (both for Present and DRI2) and at least >>> Weston, but presumably most if not all Wayland compositors. From Pekka's >>> description of how Weston uses it (thanks!), it's clear that the >>> timestamp of vblank events does need to accurately correspond to the end >>> of the vblank period. >>> >>> Use-case 2 is also used by Xorg, but only when not flipping, which rules >>> out VRR. Also, I'd argue that blocking waits for vblank are more >>> suitable for this use-case than vblank events. >>> >>> Therefore, in summary I propose this is how it could work: >>> >>> * Without VRR, timestamps continue to work the same way they do now. >>> >>> * With VRR,
Re: [PATCH v1] drm/msm: Move fence put to where failure occurs
Hey Chris,
On 2018-11-01 17:26, Chris Wilson wrote:
Quoting Robert Foss (2018-11-01 16:12:28)
If dma_fence_wait fails to wait for a supplied in-fence in
msm_ioctl_gem_submit, make sure we release that in-fence.
Also remove this dma_fence_put() from the 'out' label.
Signed-off-by: Robert Foss
---
drivers/gpu/drm/msm/msm_gem_submit.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c
b/drivers/gpu/drm/msm/msm_gem_submit.c
index a90aedd6883a..3e7704af5b24 100644
--- a/drivers/gpu/drm/msm/msm_gem_submit.c
+++ b/drivers/gpu/drm/msm/msm_gem_submit.c
@@ -411,7 +411,6 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void *data,
struct msm_file_private *ctx = file->driver_priv;
struct msm_gem_submit *submit;
struct msm_gpu *gpu = priv->gpu;
- struct dma_fence *in_fence = NULL;
struct sync_file *sync_file = NULL;
struct msm_gpu_submitqueue *queue;
struct msm_ringbuffer *ring;
@@ -444,7 +443,8 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void *data,
ring = gpu->rb[queue->prio];
if (args->flags & MSM_SUBMIT_FENCE_FD_IN) {
- in_fence = sync_file_get_fence(args->fence_fd);
+ struct dma_fence *in_fence = sync_file_get_fence(
+ args->fence_fd);
if (!in_fence)
return -EINVAL;
@@ -455,8 +455,10 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void
*data,
*/
if (!dma_fence_match_context(in_fence, ring->fctx->context)) {
ret = dma_fence_wait(in_fence, true);
- if (ret)
+ if (ret) {
+ dma_fence_put(in_fence);
return ret;
+ }
}
Careful, we need to keep the put for the normal path. Maybe,
Good catch, I'll send out a fixed version tomorrow.
if (args->flags & MSM_SUBMIT_FENCE_FD_IN) {
struct dma_fence *in_fence;
in_fence = sync_file_get_fence(args->fence_fd); // keep line breaks
natural
if (!in_fence)
return -EINVAL;
ret = 0;
if (!dma_fence_match_match_context(in_fence, ring->fctx->context)
ret = dma_fence_wait(in_fence, true);
dma_fence_put(in_fence);
if (ret)
return ret;
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 3/4] drm: Document variable refresh properties
On 2018-11-01 3:58 p.m., Kazlauskas, Nicholas wrote: > On 11/1/18 6:58 AM, Michel Dänzer wrote: >> On 2018-10-31 6:54 p.m., Kazlauskas, Nicholas wrote: >>> On 10/31/18 12:20 PM, Michel Dänzer wrote: On 2018-10-31 3:41 p.m., Kazlauskas, Nicholas wrote: > On 10/31/18 10:12 AM, Michel Dänzer wrote: >> On 2018-10-31 2:38 p.m., Kazlauskas, Nicholas wrote: >>> >>> I did some more investigation into when amdgpu gets the scanout position >>> and what values we get back out of it. The timestamp is updated shortly >>> after the crtc irq vblank which is typically within a few lines of >>> vbl_start. This makes sense, since we can provide the prediction >>> timestamp early. Waiting for the vblank to wrap around to 0 doesn't >>> really make sense here since that would mean we already hit timeout or >>> the flip occurred >> >> Sounds like you're mixing up the two cases of "actual" vblank events >> (triggered by the "vblank" interrupt => drm_(crtc_)handle_vblank) and >> flip completion events (triggered by the PFLIP interrupt with our >> hardware => drm_crtc_send_vblank_event). >> >> Actual vblank events need to be delivered to userspace at the start of >> vblank, so we indeed can't wait until the timestamp is accurate for >> them. We just need to document the exact semantics of their timestamp >> with VRR. >> >> For page flip completion events though, the timestamp needs to be >> accurate and correspond to when the flipped frame starts being scanned >> out, otherwise we'll surely break at least some userspace relying on >> this information. >> > Yeah, I was. I guess what's sent is the estimated vblank timestamp > calculated at the start of the interrupt. s/interrupt/vblank/, yeah. > And since that's just a guess rather than what's actually going to > happen it's going to be wrong in a lot of cases. > > I could see the wrap-around method working if the vblank timestamp was > somehow updated in amdgpu or in drm_crtc_send_vblank_event. DC already calls drm_crtc_accurate_vblank_count before drm_crtc_send_vblank_event, we "just" need to make sure that results in an accurate timestamp. > This would be a relatively simple fix but would break anything in > userspace that relied on the timestamp for vblank interrupt and the > flip completion being the same value. Hmm, that's a good point. So while VRR is enabled, maybe it is safer to defer delivery of vblank events until the accurate timestamp is known as well, at least by default. If there is userspace which needs the events earlier even with VRR but can live with the guessed timestamp, a flag or something could be added for that. >>> >>> I was under the impression that the vblank timestamp was reused but it's >>> already going to differ since we call drm_crtc_accurate_vblank_count >>> before drm_crtc_send_vblank_event. Thanks for pointing that out. >>> >>> Since that works for updating timestamp what's left is making sure that >>> it waits for the wrap around if it's above crtc_vtotal. It might make >>> sense to add a new flag for this that's only used within >>> amdgpu_get_crtc_scanout_position so the other call sites aren't affected. >>> >>> There isn't a way to get an accurate timestamp with VRR enabled until >>> after the flip happens. So deferring it kind of defeats the purpose of a >>> client using it to make predictions before the flip for displaying their >>> content. >> >> That's generally not a valid use-case. The KMS API is defined such that >> if userspace receives the vblank event for vblank period N and then >> submits a page flip, the page flip cannot (normally[0]) take effect >> before vblank period N+1. >> >> >> There are mainly two valid use-cases for waiting for vblank: >> >> 1. Wait for vblank N, then submit page flip for vblank N+1. >> >> 2. Wait for vblank N, then try to do something before vblank N ends, >> e.g. draw directly to the front buffer, as a poor man's way of avoiding >> tearing or similar artifacts. >> >> >> Use-case 1 is used by Xorg (both for Present and DRI2) and at least >> Weston, but presumably most if not all Wayland compositors. From Pekka's >> description of how Weston uses it (thanks!), it's clear that the >> timestamp of vblank events does need to accurately correspond to the end >> of the vblank period. >> >> Use-case 2 is also used by Xorg, but only when not flipping, which rules >> out VRR. Also, I'd argue that blocking waits for vblank are more >> suitable for this use-case than vblank events. >> >> Therefore, in summary I propose this is how it could work: >> >> * Without VRR, timestamps continue to work the same way they do now. >> >> * With VRR, delivery of both vblank and page flip completion events must >> be deferred until the timestamp accurately corresponds to the actual end >> of vblank. For
[PATCH v8] drm/fourcc: Add char_per_block, block_w and block_h in drm_format_info
For some pixel formats .cpp structure in drm_format info it's not
enough to describe the peculiarities of the pixel layout, for example
tiled formats or packed formats at bit level.
What's implemented here is to add three new members to drm_format_info
that could describe such formats:
- char_per_block[3]
- block_w[3]
- block_h[3]
char_per_block will be put in a union alongside cpp, for transparent
compatibility with the existing format descriptions.
Regarding, block_w and block_h they are intended to be used through
their equivalent getters drm_format_info_block_width /
drm_format_info_block_height, the reason of the getters is to abstract
the fact that for normal formats block_w and block_h will be unset/0,
but the methods will be returning 1.
Additionally, convenience function drm_format_info_min_pitch had been
added that computes the minimum required pitch for a given pixel
format and buffer width.
Using that the following drm core functions had been updated to
generically handle both block and non-block formats:
- drm_fb_cma_get_gem_addr: for block formats it will just return the
beginning of the block.
- framebuffer_check: Use the newly added drm_format_info_min_pitch.
- drm_gem_fb_create_with_funcs: Use the newly added
drm_format_info_min_pitch.
- In places where is not expecting to handle block formats, like fbdev
helpers I just added some warnings in case the block width/height
are greater than 1.
Changes since v3:
- Add helper function for computing the minimum required pitch.
- Improve/cleanup documentation
Changes since v8:
- Fixed build on 32bits arm architectures, with:
- return DIV_ROUND_UP((u64)buffer_width * info->char_per_block[plane],
+ return DIV_ROUND_UP_ULL((u64)buffer_width * info->char_per_block[plane],
Reviewed-by: Brian Starkey
Signed-off-by: Alexandru Gheorghe
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_fb_cma_helper.c | 20 ++-
drivers/gpu/drm/drm_fb_helper.c | 6 ++
drivers/gpu/drm/drm_fourcc.c | 62
drivers/gpu/drm/drm_framebuffer.c| 6 +-
drivers/gpu/drm/drm_gem_framebuffer_helper.c | 2 +-
include/drm/drm_fourcc.h | 61 ++-
6 files changed, 148 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
b/drivers/gpu/drm/drm_fb_cma_helper.c
index fc2b42dd3dc6..b07ab3f613e0 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -72,7 +72,9 @@ struct drm_gem_cma_object *drm_fb_cma_get_gem_obj(struct
drm_framebuffer *fb,
EXPORT_SYMBOL_GPL(drm_fb_cma_get_gem_obj);
/**
- * drm_fb_cma_get_gem_addr() - Get physical address for framebuffer
+ * drm_fb_cma_get_gem_addr() - Get physical address for framebuffer, for pixel
+ * formats where values are grouped in blocks this will get you the beginning
of
+ * the block
* @fb: The framebuffer
* @state: Which state of drm plane
* @plane: Which plane
@@ -87,6 +89,13 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct drm_framebuffer
*fb,
struct drm_gem_cma_object *obj;
dma_addr_t paddr;
u8 h_div = 1, v_div = 1;
+ u32 block_w = drm_format_info_block_width(fb->format, plane);
+ u32 block_h = drm_format_info_block_height(fb->format, plane);
+ u32 block_size = fb->format->char_per_block[plane];
+ u32 sample_x;
+ u32 sample_y;
+ u32 block_start_y;
+ u32 num_hblocks;
obj = drm_fb_cma_get_gem_obj(fb, plane);
if (!obj)
@@ -99,8 +108,13 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct drm_framebuffer
*fb,
v_div = fb->format->vsub;
}
- paddr += (fb->format->cpp[plane] * (state->src_x >> 16)) / h_div;
- paddr += (fb->pitches[plane] * (state->src_y >> 16)) / v_div;
+ sample_x = (state->src_x >> 16) / h_div;
+ sample_y = (state->src_y >> 16) / v_div;
+ block_start_y = (sample_y / block_h) * block_h;
+ num_hblocks = sample_x / block_w;
+
+ paddr += fb->pitches[plane] * block_start_y;
+ paddr += block_size * num_hblocks;
return paddr;
}
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 9b111e846847..8024524f0547 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1614,6 +1614,10 @@ int drm_fb_helper_check_var(struct fb_var_screeninfo
*var,
if (var->pixclock != 0 || in_dbg_master())
return -EINVAL;
+ if ((drm_format_info_block_width(fb->format, 0) > 1) ||
+ (drm_format_info_block_height(fb->format, 0) > 1))
+ return -EINVAL;
+
/*
* Changes struct fb_var_screeninfo are currently not pushed back
* to KMS, hence fail if different settings are requested.
@@ -1988,6 +1992,8 @@ void drm_fb_helper_fill_var(struct fb_info *info, struct
drm_fb_helper *fb_helpe
{
struct drm_framebuffer *fb = fb_helper->fb;
+
[Bug 107402] [Intel GFX CI][BAT] igt@amdgpu_amd_basic@userptr - incomplete - general protection fault: 0000 [#1] PREEMPT SMP PTI, __mmu_notifier_release
https://bugs.freedesktop.org/show_bug.cgi?id=107402 Martin Peres changed: What|Removed |Added Status|RESOLVED|CLOSED -- 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 107402] [Intel GFX CI][BAT] igt@amdgpu_amd_basic@userptr - incomplete - general protection fault: 0000 [#1] PREEMPT SMP PTI, __mmu_notifier_release
https://bugs.freedesktop.org/show_bug.cgi?id=107402 Martin Peres changed: What|Removed |Added Resolution|--- |WORKSFORME Status|NEW |RESOLVED --- Comment #7 from Martin Peres --- Used to happen at least every week, but nothing since IGT_4640 (1 month, 2 weeks / 660 runs ago). Closing! -- 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: [Intel-gfx] [PATCH v6 08/28] drm/dsc: Define Display Stream Compression PPS infoframe
On Thu, Nov 01, 2018 at 06:42:17PM +0200, Ville Syrjälä wrote:
> On Wed, Oct 24, 2018 at 03:28:20PM -0700, Manasi Navare wrote:
> > This patch defines a new header file for all the DSC 1.2 structures
> > and creates a structure for PPS infoframe which will be used to send
> > picture parameter set secondary data packet for display stream compression.
> > All the PPS infoframe syntax elements are taken from DSC 1.2 specification
> > from VESA.
> >
> > v3:
> > * Add the SPDX shorthand (Chris Wilson)
> > v2:
> > * Do not use bitfields in the struct (Jani Nikula)
> >
> > Cc: Gaurav K Singh
> > Cc: dri-devel@lists.freedesktop.org
> > Cc: Jani Nikula
> > Cc: Ville Syrjala
> > Cc: Anusha Srivatsa
> > Cc: Harry Wentland
> > Signed-off-by: Manasi Navare
> > Reviewed-by: Harry Wentland
> > ---
> > include/drm/drm_dsc.h | 347 ++
> > 1 file changed, 347 insertions(+)
> > create mode 100644 include/drm/drm_dsc.h
> >
> > diff --git a/include/drm/drm_dsc.h b/include/drm/drm_dsc.h
> > new file mode 100644
> > index ..1d8a03983b90
> > --- /dev/null
> > +++ b/include/drm/drm_dsc.h
> > @@ -0,0 +1,347 @@
> > +/* SPDX-License-Identifier: MIT
> > + * Copyright (C) 2018 Intel Corp.
> > + *
> > + * Authors:
> > + * Manasi Navare
> > + */
> > +
> > +#ifndef DRM_DSC_H_
> > +#define DRM_DSC_H_
> > +
> > +#include
> > +
> > +/* VESA Display Stream Compression DSC 1.2 constants */
> > +#define DSC_NUM_BUF_RANGES 15
>
> DRM_DSC_... perhasp?
I guess DSC_ is a good enough namespace for this stuff.
drm_dp_helper.h uses only DP_ as the namespace for the spec stuff
as well.
>
> > +
> > +/**
> > + * struct picture_parameter_set - Represents 128 bytes of Picture
> > Parameter Set
> > + *
> > + * The VESA DSC standard defines picture parameter set (PPS) which display
> > + * stream compression encoders must communicate to decoders.
> > + * The PPS is encapsulated in 128 bytes (PPS 0 through PPS 127). The
> > fields in
> > + * this structure are as per Table 4.1 in Vesa DSC specification v1.1/v1.2.
> > + * The PPS fields that span over more than a byte should be stored in Big
> > Endian
> > + * format.
> > + */
> > +struct picture_parameter_set {
>
> Needs a namespace too. Probably best make this struct packed. A
> BUILD_BUG_ON() somewhere to verify the size might also be nice.
>
> > + /**
> > +* @dsc_version:
> > +* PPS0[3:0] - dsc_version_minor: Contains Minor version of DSC
> > +* PPS0[7:4] - dsc_version_major: Contains major version of DSC
> > +*/
> > + u8 dsc_version;
> > + /**
> > +* @pps_identifier:
> > +* PPS1[7:0] - Application specific identifier that can be
> > +* used to differentiate between different PPS tables.
> > +*/
> > + u8 pps_identifier;
> > + /**
> > +* @pps_reserved:
> > +* PPS2[7:0]- RESERVED Byte
> > +*/
> > + u8 pps_reserved;
> > + /**
> > +* @pps_3:
> > +* PPS3[3:0] - linebuf_depth: Contains linebuffer bit depth used to
> > +* generate the bitstream. (0x0 - 16 bits for DSC 1.2, 0x8 - 8 bits,
> > +* 0xA - 10 bits, 0xB - 11 bits, 0xC - 12 bits, 0xD - 13 bits,
> > +* 0xE - 14 bits for DSC1.2, 0xF - 14 bits for DSC 1.2.
> > +* PPS3[7:4] - bits_per_component: Bits per component for the original
> > +* pixels of the encoded picture.
> > +* 0x0 = 16bpc (allowed only when dsc_version_minor = 0x2)
> > +* 0x8 = 8bpc, 0xA = 10bpc, 0xC = 12bpc, 0xE = 14bpc (also
> > +* allowed only when dsc_minor_version = 0x2)
> > +*/
> > + u8 pps_3;
> > + /**
> > +* @pps_4:
> > +* PPS4[1:0] -These are the most significant 2 bits of
> > +* compressed BPP bits_per_pixel[9:0] syntax element.
> > +* PPS4[2] - vbr_enable: 0 = VBR disabled, 1 = VBR enabled
> > +* PPS4[3] - simple_422: Indicates if decoder drops samples to
> > +* reconstruct the 4:2:2 picture.
> > +* PPS4[4] - Convert_rgb: Indicates if DSC color space conversion is
> > +* active.
> > +* PPS4[5] - blobk_pred_enable: Indicates if BP is used to code any
> > +* groups in picture
> > +* PPS4[7:6] - Reseved bits
> > +*/
> > + u8 pps_4;
> > + /**
> > +* @bits_per_pixel_low:
> > +* PPS5[7:0] - This indicates the lower significant 8 bits of
> > +* the compressed BPP bits_per_pixel[9:0] element.
> > +*/
> > + u8 bits_per_pixel_low;
> > + /**
> > +* @pic_height:
> > +* PPS6[7:0], PPS7[7:0] -pic_height: Specifies the number of pixel rows
> > +* within the raster.
> > +*/
> > + __be16 pic_height;
> > + /**
> > +* @pic_width:
> > +* PPS8[7:0], PPS9[7:0] - pic_width: Number of pixel columns within
> > +* the raster.
> > +*/
> > + __be16 pic_width;
> > + /**
> > +* @slice_height:
> > +* PPS10[7:0], PPS11[7:0] - Slice height in units of pixels.
> > +*/
> > + __be16 slice_height;
> > + /**
> > +* @slice_width:
> > +* PPS12[7:0], PPS13[7:0] - Slice width in terms of pixels.
> > +*/
> >
[Bug 108606] Raven Ridge: constant lockups since latest pull from Linus
https://bugs.freedesktop.org/show_bug.cgi?id=108606
--- Comment #15 from Samantha McVey ---
Alex,
The conditions in your patch never get triggered. I added some print statements
in there, and gfx_v9_0_init_rlc_ext_microcode(adev) runs, but
`adev->powerplay.pp_feature &= ~PP_GFXOFF_MASK` never runs, because my
rlc_firmware_version is 531 but rlc_feature_version is 1, so
`((adev->gfx.rlc_fw_version == 531) && (adev->gfx.rlc_feature_version < 1)) {`
is false.
--
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 102646] Screen flickering under amdgpu-experimental [buggy auto power profile]
https://bugs.freedesktop.org/show_bug.cgi?id=102646 --- Comment #39 from bmil...@gmail.com --- Another interesting info, even with amdgpu.dc=0 I get flickering @75hz. Difference is the flickering immediatly stops when I switch back to 60hz (no need to reboot or switch monitor off/on) -- 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 v6 11/28] drm/dsc: Add helpers for DSC picture parameter set infoframes
On Wed, Oct 24, 2018 at 03:28:23PM -0700, Manasi Navare wrote:
> According to Display Stream compression spec 1.2, the picture
> parameter set metadata is sent from source to sink device
> using the DP Secondary data packet. An infoframe is formed
> for the PPS SDP header and PPS SDP payload bytes.
> This patch adds helpers to fill the PPS SDP header
> and PPS SDP payload according to the DSC 1.2 specification.
>
> v6:
> * Use proper sequence points for breaking down the
> assignments (Chris Wilson)
> * Use SPDX identifier
> v5:
> Do not use bitfields for DRM structs (Jani N)
> v4:
> * Use DSC constants for params that dont change across
> configurations
> v3:
> * Add reference to added kernel-docs in Documentation/gpu/drm-kms-helpers.rst
> (Daniel Vetter)
>
> v2:
> * Add EXPORT_SYMBOL for the drm functions (Manasi)
>
> Cc: dri-devel@lists.freedesktop.org
> Cc: Jani Nikula
> Cc: Ville Syrjala
> Cc: Anusha Srivatsa
> Cc: Harry Wentland
> Signed-off-by: Manasi Navare
> Acked-by: Harry Wentland
> ---
> Documentation/gpu/drm-kms-helpers.rst | 12 ++
> drivers/gpu/drm/Makefile | 2 +-
> drivers/gpu/drm/drm_dsc.c | 223 ++
> include/drm/drm_dsc.h | 22 +++
> 4 files changed, 258 insertions(+), 1 deletion(-)
> create mode 100644 drivers/gpu/drm/drm_dsc.c
>
> diff --git a/Documentation/gpu/drm-kms-helpers.rst
> b/Documentation/gpu/drm-kms-helpers.rst
> index 4b4dc236ef6f..b422eb8edf16 100644
> --- a/Documentation/gpu/drm-kms-helpers.rst
> +++ b/Documentation/gpu/drm-kms-helpers.rst
> @@ -232,6 +232,18 @@ MIPI DSI Helper Functions Reference
> .. kernel-doc:: drivers/gpu/drm/drm_mipi_dsi.c
> :export:
>
> +Display Stream Compression Helper Functions Reference
> +=
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_dsc.c
> + :doc: dsc helpers
> +
> +.. kernel-doc:: include/drm/drm_dsc.h
> + :internal:
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_dsc.c
> + :export:
> +
> Output Probing Helper Functions Reference
> =
>
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 576ba985e138..3a3e6fb6d476 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -32,7 +32,7 @@ drm-$(CONFIG_AGP) += drm_agpsupport.o
> drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
> drm-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
>
> -drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \
> +drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_dsc.o
> drm_probe_helper.o \
> drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o \
> drm_kms_helper_common.o drm_dp_dual_mode_helper.o \
> drm_simple_kms_helper.o drm_modeset_helper.o \
> diff --git a/drivers/gpu/drm/drm_dsc.c b/drivers/gpu/drm/drm_dsc.c
> new file mode 100644
> index ..21ae8d015afd
> --- /dev/null
> +++ b/drivers/gpu/drm/drm_dsc.c
> @@ -0,0 +1,223 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright © 2018 Intel Corp
> + *
> + * Author:
> + * Manasi Navare
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/**
> + * DOC: dsc helpers
> + *
> + * These functions contain some common logic and helpers to deal with VESA
> + * Display Stream Compression standard required for DSC on Display Port/eDP
> or
> + * MIPI display interfaces.
> + */
> +
> +/**
> + * drm_dsc_dp_pps_header_init() - Initializes the PPS Header
> + * for DisplayPort as per the DP 1.4 spec.
> + * @pps_sdp: Secondary data packet for DSC Picture Parameter Set
> + */
> +void drm_dsc_dp_pps_header_init(struct drm_dsc_pps_infoframe *pps_sdp)
> +{
> + memset(_sdp->pps_header, 0, sizeof(pps_sdp->pps_header));
> +
> + pps_sdp->pps_header.HB1 = DP_SDP_PPS;
> + pps_sdp->pps_header.HB2 = DP_SDP_PPS_HEADER_PAYLOAD_BYTES_MINUS_1;
> +}
> +EXPORT_SYMBOL(drm_dsc_dp_pps_header_init);
> +
> +/**
> + * drm_dsc_pps_infoframe_pack() - Populates the DSC PPS infoframe
> + * using the DSC configuration parameters in the order expected
> + * by the DSC Display Sink device. For the DSC, the sink device
> + * expects the PPS payload in the big endian format for the fields
> + * that span more than 1 byte.
> + *
> + * @pps_sdp:
> + * Secondary data packet for DSC Picture Parameter Set
> + * @dsc_cfg:
> + * DSC Configuration data filled by driver
> + */
> +void drm_dsc_pps_infoframe_pack(struct drm_dsc_pps_infoframe *pps_sdp,
> + struct drm_dsc_config *dsc_cfg)
> +{
> + u8 i = 0;
int i;
> +
> + memset(_sdp->pps_payload, 0, sizeof(pps_sdp->pps_payload));
> +
> + /* PPS 0 */
> + pps_sdp->pps_payload.dsc_version =
> + dsc_cfg->dsc_version_minor |
> + dsc_cfg->dsc_version_major << DSC_PPS_VERSION_MAJOR_SHIFT;
> +
> + /* PPS 1, 2 is 0 */
> +
> + /* PPS 3 */
> +
Re: [PATCH v6 08/28] drm/dsc: Define Display Stream Compression PPS infoframe
On Wed, Oct 24, 2018 at 03:28:20PM -0700, Manasi Navare wrote:
> This patch defines a new header file for all the DSC 1.2 structures
> and creates a structure for PPS infoframe which will be used to send
> picture parameter set secondary data packet for display stream compression.
> All the PPS infoframe syntax elements are taken from DSC 1.2 specification
> from VESA.
>
> v3:
> * Add the SPDX shorthand (Chris Wilson)
> v2:
> * Do not use bitfields in the struct (Jani Nikula)
>
> Cc: Gaurav K Singh
> Cc: dri-devel@lists.freedesktop.org
> Cc: Jani Nikula
> Cc: Ville Syrjala
> Cc: Anusha Srivatsa
> Cc: Harry Wentland
> Signed-off-by: Manasi Navare
> Reviewed-by: Harry Wentland
> ---
> include/drm/drm_dsc.h | 347 ++
> 1 file changed, 347 insertions(+)
> create mode 100644 include/drm/drm_dsc.h
>
> diff --git a/include/drm/drm_dsc.h b/include/drm/drm_dsc.h
> new file mode 100644
> index ..1d8a03983b90
> --- /dev/null
> +++ b/include/drm/drm_dsc.h
> @@ -0,0 +1,347 @@
> +/* SPDX-License-Identifier: MIT
> + * Copyright (C) 2018 Intel Corp.
> + *
> + * Authors:
> + * Manasi Navare
> + */
> +
> +#ifndef DRM_DSC_H_
> +#define DRM_DSC_H_
> +
> +#include
> +
> +/* VESA Display Stream Compression DSC 1.2 constants */
> +#define DSC_NUM_BUF_RANGES 15
DRM_DSC_... perhasp?
> +
> +/**
> + * struct picture_parameter_set - Represents 128 bytes of Picture Parameter
> Set
> + *
> + * The VESA DSC standard defines picture parameter set (PPS) which display
> + * stream compression encoders must communicate to decoders.
> + * The PPS is encapsulated in 128 bytes (PPS 0 through PPS 127). The fields
> in
> + * this structure are as per Table 4.1 in Vesa DSC specification v1.1/v1.2.
> + * The PPS fields that span over more than a byte should be stored in Big
> Endian
> + * format.
> + */
> +struct picture_parameter_set {
Needs a namespace too. Probably best make this struct packed. A
BUILD_BUG_ON() somewhere to verify the size might also be nice.
> + /**
> + * @dsc_version:
> + * PPS0[3:0] - dsc_version_minor: Contains Minor version of DSC
> + * PPS0[7:4] - dsc_version_major: Contains major version of DSC
> + */
> + u8 dsc_version;
> + /**
> + * @pps_identifier:
> + * PPS1[7:0] - Application specific identifier that can be
> + * used to differentiate between different PPS tables.
> + */
> + u8 pps_identifier;
> + /**
> + * @pps_reserved:
> + * PPS2[7:0]- RESERVED Byte
> + */
> + u8 pps_reserved;
> + /**
> + * @pps_3:
> + * PPS3[3:0] - linebuf_depth: Contains linebuffer bit depth used to
> + * generate the bitstream. (0x0 - 16 bits for DSC 1.2, 0x8 - 8 bits,
> + * 0xA - 10 bits, 0xB - 11 bits, 0xC - 12 bits, 0xD - 13 bits,
> + * 0xE - 14 bits for DSC1.2, 0xF - 14 bits for DSC 1.2.
> + * PPS3[7:4] - bits_per_component: Bits per component for the original
> + * pixels of the encoded picture.
> + * 0x0 = 16bpc (allowed only when dsc_version_minor = 0x2)
> + * 0x8 = 8bpc, 0xA = 10bpc, 0xC = 12bpc, 0xE = 14bpc (also
> + * allowed only when dsc_minor_version = 0x2)
> + */
> + u8 pps_3;
> + /**
> + * @pps_4:
> + * PPS4[1:0] -These are the most significant 2 bits of
> + * compressed BPP bits_per_pixel[9:0] syntax element.
> + * PPS4[2] - vbr_enable: 0 = VBR disabled, 1 = VBR enabled
> + * PPS4[3] - simple_422: Indicates if decoder drops samples to
> + * reconstruct the 4:2:2 picture.
> + * PPS4[4] - Convert_rgb: Indicates if DSC color space conversion is
> + * active.
> + * PPS4[5] - blobk_pred_enable: Indicates if BP is used to code any
> + * groups in picture
> + * PPS4[7:6] - Reseved bits
> + */
> + u8 pps_4;
> + /**
> + * @bits_per_pixel_low:
> + * PPS5[7:0] - This indicates the lower significant 8 bits of
> + * the compressed BPP bits_per_pixel[9:0] element.
> + */
> + u8 bits_per_pixel_low;
> + /**
> + * @pic_height:
> + * PPS6[7:0], PPS7[7:0] -pic_height: Specifies the number of pixel rows
> + * within the raster.
> + */
> + __be16 pic_height;
> + /**
> + * @pic_width:
> + * PPS8[7:0], PPS9[7:0] - pic_width: Number of pixel columns within
> + * the raster.
> + */
> + __be16 pic_width;
> + /**
> + * @slice_height:
> + * PPS10[7:0], PPS11[7:0] - Slice height in units of pixels.
> + */
> + __be16 slice_height;
> + /**
> + * @slice_width:
> + * PPS12[7:0], PPS13[7:0] - Slice width in terms of pixels.
> + */
> + __be16 slice_width;
> + /**
> + * @chunk_size:
> + * PPS14[7:0], PPS15[7:0] - Size in units of bytes of the chunks
> + * that are used for slice multiplexing.
> + */
> + __be16 chunk_size;
> + /**
> + * @initial_xmit_delay_high:
> + * PPS16[1:0] - Most Significant two bits of
[Bug 107222] [Intel GFX CI] Many "*ERROR* amdgpu: IB test timed out." messages in dmesg
https://bugs.freedesktop.org/show_bug.cgi?id=107222 Martin Peres changed: What|Removed |Added Resolution|--- |WORKSFORME Status|NEW |RESOLVED --- Comment #1 from Martin Peres --- This happened consistently until drmtip_89 (3 months, 2 weeks / 1389 runs ago). Closing! -- 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 107222] [Intel GFX CI] Many "*ERROR* amdgpu: IB test timed out." messages in dmesg
https://bugs.freedesktop.org/show_bug.cgi?id=107222 Martin Peres changed: What|Removed |Added Status|RESOLVED|CLOSED -- 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 107221] [Intel GFX CI] Plenty of "*ERROR* VCE not responding, trying to reset the ECPU!!!" in dmesg
https://bugs.freedesktop.org/show_bug.cgi?id=107221 Martin Peres changed: What|Removed |Added Status|RESOLVED|CLOSED -- 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 107221] [Intel GFX CI] Plenty of "*ERROR* VCE not responding, trying to reset the ECPU!!!" in dmesg
https://bugs.freedesktop.org/show_bug.cgi?id=107221 Martin Peres changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #1 from Martin Peres --- This issue happened about 50 times in a month, then nothing since CI_DRM_4515 (3 months, 2 weeks / 1469 runs ago). Closing! -- 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 v1] drm/msm: Move fence put to where failure occurs
Quoting Robert Foss (2018-11-01 16:12:28)
> If dma_fence_wait fails to wait for a supplied in-fence in
> msm_ioctl_gem_submit, make sure we release that in-fence.
>
> Also remove this dma_fence_put() from the 'out' label.
>
> Signed-off-by: Robert Foss
> ---
> drivers/gpu/drm/msm/msm_gem_submit.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c
> b/drivers/gpu/drm/msm/msm_gem_submit.c
> index a90aedd6883a..3e7704af5b24 100644
> --- a/drivers/gpu/drm/msm/msm_gem_submit.c
> +++ b/drivers/gpu/drm/msm/msm_gem_submit.c
> @@ -411,7 +411,6 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void
> *data,
> struct msm_file_private *ctx = file->driver_priv;
> struct msm_gem_submit *submit;
> struct msm_gpu *gpu = priv->gpu;
> - struct dma_fence *in_fence = NULL;
> struct sync_file *sync_file = NULL;
> struct msm_gpu_submitqueue *queue;
> struct msm_ringbuffer *ring;
> @@ -444,7 +443,8 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void
> *data,
> ring = gpu->rb[queue->prio];
>
> if (args->flags & MSM_SUBMIT_FENCE_FD_IN) {
> - in_fence = sync_file_get_fence(args->fence_fd);
> + struct dma_fence *in_fence = sync_file_get_fence(
> + args->fence_fd);
>
> if (!in_fence)
> return -EINVAL;
> @@ -455,8 +455,10 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void
> *data,
> */
> if (!dma_fence_match_context(in_fence, ring->fctx->context)) {
> ret = dma_fence_wait(in_fence, true);
> - if (ret)
> + if (ret) {
> + dma_fence_put(in_fence);
> return ret;
> + }
> }
Careful, we need to keep the put for the normal path. Maybe,
if (args->flags & MSM_SUBMIT_FENCE_FD_IN) {
struct dma_fence *in_fence;
in_fence = sync_file_get_fence(args->fence_fd); // keep line breaks
natural
if (!in_fence)
return -EINVAL;
ret = 0;
if (!dma_fence_match_match_context(in_fence, ring->fctx->context)
ret = dma_fence_wait(in_fence, true);
dma_fence_put(in_fence);
if (ret)
return ret;
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] omapdrm: Fix runtime PM issues at module load and unload time
Hi Tony, On Thursday, 1 November 2018 17:58:56 EET Tony Lindgren wrote: > * Laurent Pinchart [181101 12:13]: > > On Thursday, 1 November 2018 13:47:40 EET Tomi Valkeinen wrote: > > > We do dispc_runtime_get/put in the HDMI driver's suspend/resume too, so > > > don't we need similar hack (as you add in dsi.c) there also? > > > > We would if we had to access HDMI registers at probe time. > > With these I'm still seeing the following issue with hdmi on rmmod > of omapdrm related modules as hdmi->dss is NULL in hdmi_runtime_resume. This is actually what I expected, but to my surprise the problem didn't occur on my system, I don't know why. I'll try to investigate. > Regards, > > Tony > > 8< -- > Unable to handle kernel NULL pointer dereference at virtual address 0278 > ... > PC is at hdmi_runtime_resume+0xc/0x1c [omapdss] > LR is at __rpm_callback+0x144/0x1d8 > ... > (hdmi_runtime_resume [omapdss]) from [] > (__rpm_callback+0x144/0x1d8) (__rpm_callback) from [] > (rpm_callback+0x20/0x80) > (rpm_callback) from [] (rpm_resume+0x60c/0x828) > (rpm_resume) from [] (__pm_runtime_resume+0x4c/0x64) > (__pm_runtime_resume) from [] > (device_release_driver_internal+0x130/0x234) > (device_release_driver_internal) from [] > (driver_detach+0x38/0x6c) (driver_detach) from [] > (bus_remove_driver+0x4c/0xa4) > (bus_remove_driver) from [] > (platform_unregister_drivers+0x20/0x2c) (platform_unregister_drivers) from > [] (sys_delete_module+0x1c0/0x230) (sys_delete_module) from > [] (ret_fast_syscall+0x0/0x28) -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1] drm/msm: Move fence put to where failure occurs
If dma_fence_wait fails to wait for a supplied in-fence in
msm_ioctl_gem_submit, make sure we release that in-fence.
Also remove this dma_fence_put() from the 'out' label.
Signed-off-by: Robert Foss
---
drivers/gpu/drm/msm/msm_gem_submit.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c
b/drivers/gpu/drm/msm/msm_gem_submit.c
index a90aedd6883a..3e7704af5b24 100644
--- a/drivers/gpu/drm/msm/msm_gem_submit.c
+++ b/drivers/gpu/drm/msm/msm_gem_submit.c
@@ -411,7 +411,6 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void *data,
struct msm_file_private *ctx = file->driver_priv;
struct msm_gem_submit *submit;
struct msm_gpu *gpu = priv->gpu;
- struct dma_fence *in_fence = NULL;
struct sync_file *sync_file = NULL;
struct msm_gpu_submitqueue *queue;
struct msm_ringbuffer *ring;
@@ -444,7 +443,8 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void *data,
ring = gpu->rb[queue->prio];
if (args->flags & MSM_SUBMIT_FENCE_FD_IN) {
- in_fence = sync_file_get_fence(args->fence_fd);
+ struct dma_fence *in_fence = sync_file_get_fence(
+ args->fence_fd);
if (!in_fence)
return -EINVAL;
@@ -455,8 +455,10 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void
*data,
*/
if (!dma_fence_match_context(in_fence, ring->fctx->context)) {
ret = dma_fence_wait(in_fence, true);
- if (ret)
+ if (ret) {
+ dma_fence_put(in_fence);
return ret;
+ }
}
}
@@ -583,8 +585,6 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void *data,
}
out:
- if (in_fence)
- dma_fence_put(in_fence);
submit_cleanup(submit);
if (ret)
msm_gem_submit_free(submit);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108625] AMDGPU - Can't even get Xorg to start - Kernel driver hangs with ring buffer timeout on ARM64
https://bugs.freedesktop.org/show_bug.cgi?id=108625 Bug ID: 108625 Summary: AMDGPU - Can't even get Xorg to start - Kernel driver hangs with ring buffer timeout on ARM64 Product: DRI Version: unspecified Hardware: ARM OS: Linux (All) Status: NEW Severity: blocker Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: ras...@rasterman.com So we're going to have fun with this one... Start Xorg. It hangs in screen setup: #0 ioctl () at ../sysdeps/unix/sysv/linux/aarch64/ioctl.S:25 #1 0xbb149334 in drmIoctl () from /lib/aarch64-linux-gnu/libdrm.so.2 #2 0xba5166b4 in amdgpu_cs_query_fence_status () from /lib/aarch64-linux-gnu/libdrm_amdgpu.so.1 #3 0xb9ef37f8 in ?? () from /usr/lib/aarch64-linux-gnu/dri/radeonsi_dri.so #4 0xb9dd148c in ?? () from /usr/lib/aarch64-linux-gnu/dri/radeonsi_dri.so #5 0xb993d448 in ?? () from /usr/lib/aarch64-linux-gnu/dri/radeonsi_dri.so #6 0xb993d4ac in ?? () from /usr/lib/aarch64-linux-gnu/dri/radeonsi_dri.so #7 0xba54425c in ?? () from /usr/lib/xorg/modules/drivers/amdgpu_drv.so #8 0xba537ca8 in ?? () from /usr/lib/xorg/modules/drivers/amdgpu_drv.so #9 0xe7133348 in MapWindow () #10 0xe710c820 in ?? () #11 0xbad52720 in __libc_start_main (main=0x0, argc=0, argv=0x0, init=, fini=, rtld_fini=, stack_end=) at ../csu/libc-start.c:310 And that ioctl hangs because of: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, last signaled seq=10, last emitted seq=11 [drm] GPU recovery disabled. The amdgpu kernel driver reports: [drm] amdgpu kernel modesetting enabled. amdgpu :89:00.0: enabling device (0100 -> 0102) amdgpu :89:00.0: firmware: direct-loading firmware amdgpu/polaris11_mc.bin amdgpu :89:00.0: BAR 2: releasing [mem 0x1401000-0x140101f 64bit pref] amdgpu :89:00.0: BAR 0: releasing [mem 0x140-0x1400fff 64bit pref] amdgpu :89:00.0: BAR 0: assigned [mem 0x140-0x140 64bit pref] amdgpu :89:00.0: BAR 2: assigned [mem 0x141-0x141001f 64bit pref] amdgpu :89:00.0: VRAM: 4096M 0x00F4 - 0x00F4 (4096M used) amdgpu :89:00.0: GTT: 256M 0x - 0x0FFF [drm] amdgpu: 4096M of VRAM memory ready [drm] amdgpu: 4096M of GTT memory ready. amdgpu :89:00.0: firmware: direct-loading firmware amdgpu/polaris11_pfp_2.bin amdgpu :89:00.0: firmware: direct-loading firmware amdgpu/polaris11_me_2.bin amdgpu :89:00.0: firmware: direct-loading firmware amdgpu/polaris11_ce_2.bin amdgpu :89:00.0: firmware: direct-loading firmware amdgpu/polaris11_rlc.bin amdgpu :89:00.0: firmware: direct-loading firmware amdgpu/polaris11_mec_2.bin amdgpu :89:00.0: firmware: direct-loading firmware amdgpu/polaris11_mec2_2.bin amdgpu :89:00.0: firmware: direct-loading firmware amdgpu/polaris11_sdma.bin amdgpu :89:00.0: firmware: direct-loading firmware amdgpu/polaris11_sdma1.bin amdgpu :89:00.0: firmware: direct-loading firmware amdgpu/polaris11_uvd.bin amdgpu :89:00.0: firmware: direct-loading firmware amdgpu/polaris11_vce.bin amdgpu :89:00.0: firmware: direct-loading firmware amdgpu/polaris11_k_smc.bin [drm] Initialized amdgpu 3.26.0 20150101 for :89:00.0 on minor 1 amdgpu :89:00.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=none:owns=none So here is where the fun begins. Kernel is: Linux noisy 4.18.0-2-arm64 #1 SMP Debian 4.18.10-2 (2018-10-07) aarch64 GNU/Linux It's Debian unstable on a Cavium Thunder-X2 64bit ARM system (2 CPUs with 32 cores each, 256 cores total with 4 way SMT enabled) with a bunch of PCIE slots. There is an Nvidia card that works to a decent degree and an on-board PCIE dumb framebuffer display device (ASPEED), but I'd rather a more open stack etc. - I've fiddled with xorg configs to get it to ignore other devices other than the AMD one like with: Section "ServerFlags" Option "AutoAddGPU" "false" EndSection Section "Device" Identifier "amdgpu" Driver "amdgpu" BusID "PCI:137:0:0" Option "DRI" "2" Option "TearFree" "on" EndSection I've even put the AMD card in the same slot as the Nvidia one with the same results, so it's not a slot specific issue it seems. So where should I start poking to see where this very early stage ring gfx timeout is originating from specifically... I'm willing to start the fun of compiling kernels etc. to dig through this. So how can I help solve this and make AMD cards portable and usable? :) -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list
[Bug 108613] amdgpu.dc=1 + xf86-video-amdgpu: changing to a GPU upscaling resolution resets pp_dpm_mclk
https://bugs.freedesktop.org/show_bug.cgi?id=108613 Michel Dänzer changed: What|Removed |Added Attachment #142328|text/x-log |text/plain mime type|| -- 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 108613] amdgpu.dc=1 + xf86-video-amdgpu: changing to a GPU upscaling resolution resets pp_dpm_mclk
https://bugs.freedesktop.org/show_bug.cgi?id=108613 Michel Dänzer changed: What|Removed |Added Attachment #142327|text/x-log |text/plain mime type|| -- 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 106175] amdgpu.dc=1 shows performance issues with Xorg compositors when moving windows
https://bugs.freedesktop.org/show_bug.cgi?id=106175 --- Comment #34 from Michel Dänzer --- (In reply to tempel.julian from comment #33) > I suppose TearFree forces pageflipping regardless, as we don't see any > tearing with that configuration. Right, you'd have to disable TearFree as well. Can be done at runtime with xrandr --output --set TearFree off -- 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 108098] Ryzen 7 2700U, amdgpu, graphics freezes on 4.19.0-041900-generic
https://bugs.freedesktop.org/show_bug.cgi?id=108098 --- Comment #7 from Michel Dänzer --- FWIW, I advise against paying too much attention to fin4478. They are not involved in driver development and known for making rather questionable suggestions which are definitely not suitable for everyone. -- 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 v6 3/9] drm: mali-dp: Enable Mali-DP tiled buffer formats
On Thu, Nov 01, 2018 at 01:31:06PM +, Alexandru-Cosmin Gheorghe wrote:
> Hi,
>
> Liviu, can I merge this through drm-misc-next.
Yeah, that is fine with me.
Best regards,
Liviu
>
> On Mon, Oct 29, 2018 at 05:14:38PM +, Alexandru-Cosmin Gheorghe wrote:
> > Enable the following formats
> > - DRM_FORMAT_X0L0: DP650
> > - DRM_FORMAT_X0L2: DP550, DP650
> >
> > Reviewed-by: Brian Starkey
> > Signed-off-by: Alexandru Gheorghe
> > ---
> > drivers/gpu/drm/arm/malidp_hw.c | 14 +++---
> > drivers/gpu/drm/arm/malidp_planes.c | 28 +---
> > 2 files changed, 36 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/arm/malidp_hw.c
> > b/drivers/gpu/drm/arm/malidp_hw.c
> > index 7aad7dd80d8c..b9bed1138fa3 100644
> > --- a/drivers/gpu/drm/arm/malidp_hw.c
> > +++ b/drivers/gpu/drm/arm/malidp_hw.c
> > @@ -77,12 +77,18 @@ static const struct malidp_format_id
> > malidp500_de_formats[] = {
> > { DRM_FORMAT_YUYV, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 2) },\
> > { DRM_FORMAT_UYVY, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 3) },\
> > { DRM_FORMAT_NV12, DE_VIDEO1 | DE_VIDEO2 | SE_MEMWRITE, MALIDP_ID(5, 6)
> > }, \
> > - { DRM_FORMAT_YUV420, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 7) }
> > + { DRM_FORMAT_YUV420, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 7) }, \
> > + { DRM_FORMAT_X0L2, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(6, 6)}
> >
> > static const struct malidp_format_id malidp550_de_formats[] = {
> > MALIDP_COMMON_FORMATS,
> > };
> >
> > +static const struct malidp_format_id malidp650_de_formats[] = {
> > + MALIDP_COMMON_FORMATS,
> > + { DRM_FORMAT_X0L0, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 4)},
> > +};
> > +
> > static const struct malidp_layer malidp500_layers[] = {
> > /* id, base address, fb pointer address base, stride offset,
> > * yuv2rgb matrix offset, mmu control register offset,
> > rotation_features
> > @@ -630,6 +636,8 @@ static int malidp550_rotmem_required(struct
> > malidp_hw_device *hwdev, u16 w, u16
> > case DRM_FORMAT_BGR565:
> > case DRM_FORMAT_UYVY:
> > case DRM_FORMAT_YUYV:
> > + case DRM_FORMAT_X0L0:
> > + case DRM_FORMAT_X0L2:
> > bytes_per_col = 32;
> > break;
> > /* 16 lines at 1.5 bytes per pixel */
> > @@ -905,8 +913,8 @@ const struct malidp_hw
> > malidp_device[MALIDP_MAX_DEVICES] = {
> > MALIDP550_DC_IRQ_SE,
> > .vsync_irq = MALIDP550_DC_IRQ_CONF_VALID,
> > },
> > - .pixel_formats = malidp550_de_formats,
> > - .n_pixel_formats = ARRAY_SIZE(malidp550_de_formats),
> > + .pixel_formats = malidp650_de_formats,
> > + .n_pixel_formats = ARRAY_SIZE(malidp650_de_formats),
> > .bus_align_bytes = 16,
> > },
> > .query_hw = malidp650_query_hw,
> > diff --git a/drivers/gpu/drm/arm/malidp_planes.c
> > b/drivers/gpu/drm/arm/malidp_planes.c
> > index 837a24d56675..c9a6d3e0cada 100644
> > --- a/drivers/gpu/drm/arm/malidp_planes.c
> > +++ b/drivers/gpu/drm/arm/malidp_planes.c
> > @@ -398,6 +398,7 @@ static int malidp_de_plane_check(struct drm_plane
> > *plane,
> > struct drm_framebuffer *fb;
> > u16 pixel_alpha = state->pixel_blend_mode;
> > int i, ret;
> > + unsigned int block_w, block_h;
> >
> > if (!state->crtc || !state->fb)
> > return 0;
> > @@ -413,13 +414,26 @@ static int malidp_de_plane_check(struct drm_plane
> > *plane,
> > ms->n_planes = fb->format->num_planes;
> > for (i = 0; i < ms->n_planes; i++) {
> > u8 alignment = malidp_hw_get_pitch_align(mp->hwdev, rotated);
> > - if (fb->pitches[i] & (alignment - 1)) {
> > +
> > + if ((fb->pitches[i] * drm_format_info_block_height(fb->format,
> > i))
> > + & (alignment - 1)) {
> > DRM_DEBUG_KMS("Invalid pitch %u for plane %d\n",
> > fb->pitches[i], i);
> > return -EINVAL;
> > }
> > }
> >
> > + block_w = drm_format_info_block_width(fb->format, 0);
> > + block_h = drm_format_info_block_height(fb->format, 0);
> > + if (fb->width % block_w || fb->height % block_h) {
> > + DRM_DEBUG_KMS("Buffer width/height needs to be a multiple of
> > tile sizes");
> > + return -EINVAL;
> > + }
> > + if ((state->src_x >> 16) % block_w || (state->src_y >> 16) % block_h) {
> > + DRM_DEBUG_KMS("Plane src_x/src_y needs to be a multiple of tile
> > sizes");
> > + return -EINVAL;
> > + }
> > +
> > if ((state->crtc_w > mp->hwdev->max_line_size) ||
> > (state->crtc_h > mp->hwdev->max_line_size) ||
> > (state->crtc_w < mp->hwdev->min_line_size) ||
> > @@ -492,10 +506,18 @@ static void malidp_de_set_plane_pitches(struct
> > malidp_plane *mp,
> > num_strides =
[pull] amdgpu drm-next-4.20
Hi Dave, Fixes for 4.20. Highlights: - Fix flickering at low backlight levels on some systems - Fix some overclocking regressions - Vega20 updates for - GPU recovery fixes - Disable gfxoff on RV as some sbios/fw combinations are not stable yet The following changes since commit 0af5c656fdb797f74ee57414e0c07cd57406d0c3: drm/amdgpu: fix amdgpu_vm_fini (2018-10-25 14:04:40 -0500) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-next-4.20 for you to fetch changes up to 9d064be1e6a195eaaa3762af5c7c6cd3f66aa6cc: drm/amdgpu: revert "enable gfxoff in non-sriov and stutter mode by default" (2018-11-01 09:56:56 -0500) Andrey Grodzovsky (2): drm/amdgpu: Fix compute ring 1.0.0 failure after reset drm/amdgpu: Fix skipping hangged job reset during gpu recover. Christian König (2): drm/amdgpu: fix VM leaf walking drm/amdgpu: revert "enable gfxoff in non-sriov and stutter mode by default" Evan Quan (2): drm/amd/powerplay: revise Vega20 pptable version check drm/amd/powerplay: no MGPU fan boost enablement on DPM disabled Guttula, Suresh (1): drm/amd/display: set backlight level limit to 1 Rex Zhu (3): drm/amd/pp: Fix pp_sclk/mclk_od not work on smu7 drm/amd/pp: Fix pp_sclk/mclk_od not work on Vega10 drm/amd/pp: Print warning if od_sclk/mclk out of range Shirish S (1): drm/amdgpu: fix reporting of failed msg sent to SMU (v2) drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 +- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 4 +- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 3 +- drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 6 ++- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 7 drivers/gpu/drm/amd/powerplay/amd_powerplay.c | 6 +-- drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 10 +++-- drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 43 -- .../amd/powerplay/hwmgr/vega20_processpptables.c | 10 - drivers/gpu/drm/amd/powerplay/smumgr/smu8_smumgr.c | 4 ++ 10 files changed, 76 insertions(+), 21 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND v7 7/7] drm/selftests: Add tests for drm_internal_framebuffer_create
Add tests that verify that drm_internal_framebuffer_create creates
buffers correctly by creating a dummy drm_device with a mock function
for the fb_create callback.
To decide if a buffer has been created or not it just checks if
fb_create callback has been called for the particular drm_mode_fb_cmd2
that's being tested.
Signed-off-by: Alexandru Gheorghe
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/selftests/Makefile| 2 +-
.../gpu/drm/selftests/drm_modeset_selftests.h | 1 +
.../gpu/drm/selftests/test-drm_framebuffer.c | 344 ++
.../drm/selftests/test-drm_modeset_common.h | 1 +
4 files changed, 347 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/selftests/test-drm_framebuffer.c
diff --git a/drivers/gpu/drm/selftests/Makefile
b/drivers/gpu/drm/selftests/Makefile
index 07b4f88b422a..383d8d6c5847 100644
--- a/drivers/gpu/drm/selftests/Makefile
+++ b/drivers/gpu/drm/selftests/Makefile
@@ -1,4 +1,4 @@
test-drm_modeset-y := test-drm_modeset_common.o test-drm_plane_helper.o \
- test-drm_format.o
+ test-drm_format.o test-drm_framebuffer.o
obj-$(CONFIG_DRM_DEBUG_SELFTEST) += test-drm_mm.o test-drm_modeset.o
diff --git a/drivers/gpu/drm/selftests/drm_modeset_selftests.h
b/drivers/gpu/drm/selftests/drm_modeset_selftests.h
index 4e203ac8c134..92601defd8f6 100644
--- a/drivers/gpu/drm/selftests/drm_modeset_selftests.h
+++ b/drivers/gpu/drm/selftests/drm_modeset_selftests.h
@@ -10,3 +10,4 @@ selftest(check_plane_state, igt_check_plane_state)
selftest(check_drm_format_block_width, igt_check_drm_format_block_width)
selftest(check_drm_format_block_height, igt_check_drm_format_block_height)
selftest(check_drm_format_min_pitch, igt_check_drm_format_min_pitch)
+selftest(check_drm_framebuffer_create, igt_check_drm_framebuffer_create)
diff --git a/drivers/gpu/drm/selftests/test-drm_framebuffer.c
b/drivers/gpu/drm/selftests/test-drm_framebuffer.c
new file mode 100644
index ..3098435678af
--- /dev/null
+++ b/drivers/gpu/drm/selftests/test-drm_framebuffer.c
@@ -0,0 +1,344 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Test cases for the drm_framebuffer functions
+ */
+
+#include
+#include "../drm_crtc_internal.h"
+
+#include "test-drm_modeset_common.h"
+
+#define MIN_WIDTH 4
+#define MAX_WIDTH 4096
+#define MIN_HEIGHT 4
+#define MAX_HEIGHT 4096
+
+struct drm_framebuffer_test {
+ int buffer_created;
+ struct drm_mode_fb_cmd2 cmd;
+ const char *name;
+};
+
+static struct drm_framebuffer_test createbuffer_tests[] = {
+{ .buffer_created = 1, .name = "ABGR normal sizes",
+ .cmd = { .width = 600, .height = 600, .pixel_format =
DRM_FORMAT_ABGR,
+.handles = { 1, 0, 0 }, .pitches = { 4 * 600, 0, 0 },
+ }
+},
+{ .buffer_created = 1, .name = "ABGR max sizes",
+ .cmd = { .width = MAX_WIDTH, .height = MAX_HEIGHT, .pixel_format =
DRM_FORMAT_ABGR,
+.handles = { 1, 0, 0 }, .pitches = { 4 * MAX_WIDTH, 0, 0 },
+ }
+},
+{ .buffer_created = 1, .name = "ABGR pitch greater than min required",
+ .cmd = { .width = MAX_WIDTH, .height = MAX_HEIGHT, .pixel_format =
DRM_FORMAT_ABGR,
+.handles = { 1, 0, 0 }, .pitches = { 4 * MAX_WIDTH + 1, 0, 0 },
+ }
+},
+{ .buffer_created = 0, .name = "ABGR pitch less than min required",
+ .cmd = { .width = MAX_WIDTH, .height = MAX_HEIGHT, .pixel_format =
DRM_FORMAT_ABGR,
+.handles = { 1, 0, 0 }, .pitches = { 4 * MAX_WIDTH - 1, 0, 0 },
+ }
+},
+{ .buffer_created = 0, .name = "ABGR Invalid width",
+ .cmd = { .width = MAX_WIDTH + 1, .height = MAX_HEIGHT, .pixel_format =
DRM_FORMAT_ABGR,
+.handles = { 1, 0, 0 }, .pitches = { 4 * (MAX_WIDTH + 1), 0, 0
},
+ }
+},
+{ .buffer_created = 0, .name = "ABGR Invalid buffer handle",
+ .cmd = { .width = MAX_WIDTH, .height = MAX_HEIGHT, .pixel_format =
DRM_FORMAT_ABGR,
+.handles = { 0, 0, 0 }, .pitches = { 4 * MAX_WIDTH, 0, 0 },
+ }
+},
+{ .buffer_created = 0, .name = "No pixel format",
+ .cmd = { .width = MAX_WIDTH, .height = MAX_HEIGHT, .pixel_format = 0,
+.handles = { 1, 0, 0 }, .pitches = { 4 * MAX_WIDTH, 0, 0 },
+ }
+},
+{ .buffer_created = 0, .name = "ABGR Width 0",
+ .cmd = { .width = 0, .height = MAX_HEIGHT, .pixel_format =
DRM_FORMAT_ABGR,
+.handles = { 1, 0, 0 }, .pitches = { 4 * MAX_WIDTH, 0, 0 },
+ }
+},
+{ .buffer_created = 0, .name = "ABGR Height 0",
+ .cmd = { .width = MAX_WIDTH, .height = 0, .pixel_format =
DRM_FORMAT_ABGR,
+.handles = { 1, 0, 0 }, .pitches = { 4 * MAX_WIDTH, 0, 0 },
+ }
+},
+{ .buffer_created = 0, .name = "ABGR Out of bound height * pitch
combination",
+ .cmd = { .width = MAX_WIDTH, .height = MAX_HEIGHT, .pixel_format =
DRM_FORMAT_ABGR,
+.handles = { 1, 0, 0 },
[RESEND v7 3/7] drm: mali-dp: Enable Mali-DP tiled buffer formats
Enable the following formats
- DRM_FORMAT_X0L0: DP650
- DRM_FORMAT_X0L2: DP550, DP650
Reviewed-by: Brian Starkey
Signed-off-by: Alexandru Gheorghe
---
drivers/gpu/drm/arm/malidp_hw.c | 14 +++---
drivers/gpu/drm/arm/malidp_planes.c | 28 +---
2 files changed, 36 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
index 7aad7dd80d8c..b9bed1138fa3 100644
--- a/drivers/gpu/drm/arm/malidp_hw.c
+++ b/drivers/gpu/drm/arm/malidp_hw.c
@@ -77,12 +77,18 @@ static const struct malidp_format_id malidp500_de_formats[]
= {
{ DRM_FORMAT_YUYV, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 2) },\
{ DRM_FORMAT_UYVY, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 3) },\
{ DRM_FORMAT_NV12, DE_VIDEO1 | DE_VIDEO2 | SE_MEMWRITE, MALIDP_ID(5, 6)
}, \
- { DRM_FORMAT_YUV420, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 7) }
+ { DRM_FORMAT_YUV420, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 7) }, \
+ { DRM_FORMAT_X0L2, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(6, 6)}
static const struct malidp_format_id malidp550_de_formats[] = {
MALIDP_COMMON_FORMATS,
};
+static const struct malidp_format_id malidp650_de_formats[] = {
+ MALIDP_COMMON_FORMATS,
+ { DRM_FORMAT_X0L0, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 4)},
+};
+
static const struct malidp_layer malidp500_layers[] = {
/* id, base address, fb pointer address base, stride offset,
* yuv2rgb matrix offset, mmu control register offset,
rotation_features
@@ -630,6 +636,8 @@ static int malidp550_rotmem_required(struct
malidp_hw_device *hwdev, u16 w, u16
case DRM_FORMAT_BGR565:
case DRM_FORMAT_UYVY:
case DRM_FORMAT_YUYV:
+ case DRM_FORMAT_X0L0:
+ case DRM_FORMAT_X0L2:
bytes_per_col = 32;
break;
/* 16 lines at 1.5 bytes per pixel */
@@ -905,8 +913,8 @@ const struct malidp_hw malidp_device[MALIDP_MAX_DEVICES] = {
MALIDP550_DC_IRQ_SE,
.vsync_irq = MALIDP550_DC_IRQ_CONF_VALID,
},
- .pixel_formats = malidp550_de_formats,
- .n_pixel_formats = ARRAY_SIZE(malidp550_de_formats),
+ .pixel_formats = malidp650_de_formats,
+ .n_pixel_formats = ARRAY_SIZE(malidp650_de_formats),
.bus_align_bytes = 16,
},
.query_hw = malidp650_query_hw,
diff --git a/drivers/gpu/drm/arm/malidp_planes.c
b/drivers/gpu/drm/arm/malidp_planes.c
index 837a24d56675..c9a6d3e0cada 100644
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -398,6 +398,7 @@ static int malidp_de_plane_check(struct drm_plane *plane,
struct drm_framebuffer *fb;
u16 pixel_alpha = state->pixel_blend_mode;
int i, ret;
+ unsigned int block_w, block_h;
if (!state->crtc || !state->fb)
return 0;
@@ -413,13 +414,26 @@ static int malidp_de_plane_check(struct drm_plane *plane,
ms->n_planes = fb->format->num_planes;
for (i = 0; i < ms->n_planes; i++) {
u8 alignment = malidp_hw_get_pitch_align(mp->hwdev, rotated);
- if (fb->pitches[i] & (alignment - 1)) {
+
+ if ((fb->pitches[i] * drm_format_info_block_height(fb->format,
i))
+ & (alignment - 1)) {
DRM_DEBUG_KMS("Invalid pitch %u for plane %d\n",
fb->pitches[i], i);
return -EINVAL;
}
}
+ block_w = drm_format_info_block_width(fb->format, 0);
+ block_h = drm_format_info_block_height(fb->format, 0);
+ if (fb->width % block_w || fb->height % block_h) {
+ DRM_DEBUG_KMS("Buffer width/height needs to be a multiple of
tile sizes");
+ return -EINVAL;
+ }
+ if ((state->src_x >> 16) % block_w || (state->src_y >> 16) % block_h) {
+ DRM_DEBUG_KMS("Plane src_x/src_y needs to be a multiple of tile
sizes");
+ return -EINVAL;
+ }
+
if ((state->crtc_w > mp->hwdev->max_line_size) ||
(state->crtc_h > mp->hwdev->max_line_size) ||
(state->crtc_w < mp->hwdev->min_line_size) ||
@@ -492,10 +506,18 @@ static void malidp_de_set_plane_pitches(struct
malidp_plane *mp,
num_strides = (mp->hwdev->hw->features &
MALIDP_DEVICE_LV_HAS_3_STRIDES) ? 3 : 2;
- for (i = 0; i < num_strides; ++i)
- malidp_hw_write(mp->hwdev, pitches[i],
+ /*
+* The drm convention for pitch is that it needs to cover width * cpp,
+* but our hardware wants the pitch/stride to cover all rows included
+* in a tile.
+*/
+ for (i = 0; i < num_strides; ++i) {
+ unsigned int
[RESEND v7 6/7] drm: Add macro to export functions only when CONFIG_DRM_DEBUG_SELFTEST is enabled
If we want to be able to write drmselftests for non-static core functions that are not intended to be used by drivers we need this functions to be exported. This adds a macro that is tied of CONFIG_DRM_DEBUG_SELFTEST, and uses that to export drm_internal_framebuffer_create, in order for subsequent patches to be able to test it. Signed-off-by: Alexandru Gheorghe Reviewed-by: Daniel Vetter --- drivers/gpu/drm/drm_framebuffer.c | 1 + include/drm/drmP.h| 6 ++ 2 files changed, 7 insertions(+) diff --git a/drivers/gpu/drm/drm_framebuffer.c b/drivers/gpu/drm/drm_framebuffer.c index 167c1c4544af..fcaea8f50513 100644 --- a/drivers/gpu/drm/drm_framebuffer.c +++ b/drivers/gpu/drm/drm_framebuffer.c @@ -323,6 +323,7 @@ drm_internal_framebuffer_create(struct drm_device *dev, return fb; } +EXPORT_SYMBOL_FOR_TESTS_ONLY(drm_internal_framebuffer_create); /** * drm_mode_addfb2 - add an FB to the graphics configuration diff --git a/include/drm/drmP.h b/include/drm/drmP.h index 05350424a4d3..514beb2d483a 100644 --- a/include/drm/drmP.h +++ b/include/drm/drmP.h @@ -110,4 +110,10 @@ static inline bool drm_can_sleep(void) return true; } +#if defined(CONFIG_DRM_DEBUG_SELFTEST_MODULE) +#define EXPORT_SYMBOL_FOR_TESTS_ONLY(x) EXPORT_SYMBOL(x) +#else +#define EXPORT_SYMBOL_FOR_TESTS_ONLY(x) +#endif + #endif -- 2.19.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND v7 4/7] drm: Extend framebuffer_check to handle formats with cpp/char_per_block 0
For formats that are supported only with non-linear modifiers it
doesn't make to much sense to define cpp or char_per_block, so that
will be set to 0.
This patch adds a restriction to force having a modifier attached when
cpp/char_per_block is 0, and to bypass checking the pitch restriction.
This had been discussed here.
[1]
https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel_names==2018-09-13_html=true
Reviewed-by: Brian Starkey
Signed-off-by: Alexandru Gheorghe
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_framebuffer.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_framebuffer.c
b/drivers/gpu/drm/drm_framebuffer.c
index 6aca8a1ccdb6..167c1c4544af 100644
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -195,8 +195,14 @@ static int framebuffer_check(struct drm_device *dev,
for (i = 0; i < info->num_planes; i++) {
unsigned int width = fb_plane_width(r->width, info, i);
unsigned int height = fb_plane_height(r->height, info, i);
+ unsigned int block_size = info->char_per_block[i];
u64 min_pitch = drm_format_info_min_pitch(info, i, width);
+ if (!block_size && (r->modifier[i] == DRM_FORMAT_MOD_LINEAR)) {
+ DRM_DEBUG_KMS("Format requires non-linear modifier for
plane %d\n", i);
+ return -EINVAL;
+ }
+
if (!r->handles[i]) {
DRM_DEBUG_KMS("no buffer object handle for plane %d\n",
i);
return -EINVAL;
@@ -208,7 +214,7 @@ static int framebuffer_check(struct drm_device *dev,
if ((uint64_t) height * r->pitches[i] + r->offsets[i] >
UINT_MAX)
return -ERANGE;
- if (r->pitches[i] < min_pitch) {
+ if (block_size && r->pitches[i] < min_pitch) {
DRM_DEBUG_KMS("bad pitch %u for plane %d\n",
r->pitches[i], i);
return -EINVAL;
}
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND v7 5/7] drm/selftests: Add tests for drm_format_info* helpers
Add selftests for the following newly added functions:
- drm_format_info_block_width
- drm_format_info_block_height
- drm_format_info_min_pitch
Signed-off-by: Alexandru Gheorghe
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/selftests/Makefile| 3 +-
.../gpu/drm/selftests/drm_modeset_selftests.h | 3 +
drivers/gpu/drm/selftests/test-drm_format.c | 280 ++
.../drm/selftests/test-drm_modeset_common.h | 3 +
4 files changed, 288 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/selftests/test-drm_format.c
diff --git a/drivers/gpu/drm/selftests/Makefile
b/drivers/gpu/drm/selftests/Makefile
index 7e6581921da0..07b4f88b422a 100644
--- a/drivers/gpu/drm/selftests/Makefile
+++ b/drivers/gpu/drm/selftests/Makefile
@@ -1,3 +1,4 @@
-test-drm_modeset-y := test-drm_modeset_common.o test-drm_plane_helper.o
+test-drm_modeset-y := test-drm_modeset_common.o test-drm_plane_helper.o \
+ test-drm_format.o
obj-$(CONFIG_DRM_DEBUG_SELFTEST) += test-drm_mm.o test-drm_modeset.o
diff --git a/drivers/gpu/drm/selftests/drm_modeset_selftests.h
b/drivers/gpu/drm/selftests/drm_modeset_selftests.h
index 9771290ed228..4e203ac8c134 100644
--- a/drivers/gpu/drm/selftests/drm_modeset_selftests.h
+++ b/drivers/gpu/drm/selftests/drm_modeset_selftests.h
@@ -7,3 +7,6 @@
* Tests are executed in order by igt/drm_selftests_helper
*/
selftest(check_plane_state, igt_check_plane_state)
+selftest(check_drm_format_block_width, igt_check_drm_format_block_width)
+selftest(check_drm_format_block_height, igt_check_drm_format_block_height)
+selftest(check_drm_format_min_pitch, igt_check_drm_format_min_pitch)
diff --git a/drivers/gpu/drm/selftests/test-drm_format.c
b/drivers/gpu/drm/selftests/test-drm_format.c
new file mode 100644
index ..c5e212afa27a
--- /dev/null
+++ b/drivers/gpu/drm/selftests/test-drm_format.c
@@ -0,0 +1,280 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Test cases for the drm_format functions
+ */
+
+#define pr_fmt(fmt) "drm_format: " fmt
+
+#include
+#include
+
+#include
+
+#include "test-drm_modeset_common.h"
+
+int igt_check_drm_format_block_width(void *ignored)
+{
+ const struct drm_format_info *info = NULL;
+
+ /* Test invalid arguments */
+ FAIL_ON(drm_format_info_block_width(info, 0) != 0);
+ FAIL_ON(drm_format_info_block_width(info, -1) != 0);
+ FAIL_ON(drm_format_info_block_width(info, 1) != 0);
+
+ /* Test 1 plane format */
+ info = drm_format_info(DRM_FORMAT_XRGB);
+ FAIL_ON(!info);
+ FAIL_ON(drm_format_info_block_width(info, 0) != 1);
+ FAIL_ON(drm_format_info_block_width(info, 1) != 0);
+ FAIL_ON(drm_format_info_block_width(info, -1) != 0);
+
+ /* Test 2 planes format */
+ info = drm_format_info(DRM_FORMAT_NV12);
+ FAIL_ON(!info);
+ FAIL_ON(drm_format_info_block_width(info, 0) != 1);
+ FAIL_ON(drm_format_info_block_width(info, 1) != 1);
+ FAIL_ON(drm_format_info_block_width(info, 2) != 0);
+ FAIL_ON(drm_format_info_block_width(info, -1) != 0);
+
+ /* Test 3 planes format */
+ info = drm_format_info(DRM_FORMAT_YUV422);
+ FAIL_ON(!info);
+ FAIL_ON(drm_format_info_block_width(info, 0) != 1);
+ FAIL_ON(drm_format_info_block_width(info, 1) != 1);
+ FAIL_ON(drm_format_info_block_width(info, 2) != 1);
+ FAIL_ON(drm_format_info_block_width(info, 3) != 0);
+ FAIL_ON(drm_format_info_block_width(info, -1) != 0);
+
+ /* Test a tiled format */
+ info = drm_format_info(DRM_FORMAT_X0L0);
+ FAIL_ON(!info);
+ FAIL_ON(drm_format_info_block_width(info, 0) != 2);
+ FAIL_ON(drm_format_info_block_width(info, 1) != 0);
+ FAIL_ON(drm_format_info_block_width(info, -1) != 0);
+
+ return 0;
+}
+
+int igt_check_drm_format_block_height(void *ignored)
+{
+ const struct drm_format_info *info = NULL;
+
+ /* Test invalid arguments */
+ FAIL_ON(drm_format_info_block_height(info, 0) != 0);
+ FAIL_ON(drm_format_info_block_height(info, -1) != 0);
+ FAIL_ON(drm_format_info_block_height(info, 1) != 0);
+
+ /* Test 1 plane format */
+ info = drm_format_info(DRM_FORMAT_XRGB);
+ FAIL_ON(!info);
+ FAIL_ON(drm_format_info_block_height(info, 0) != 1);
+ FAIL_ON(drm_format_info_block_height(info, 1) != 0);
+ FAIL_ON(drm_format_info_block_height(info, -1) != 0);
+
+ /* Test 2 planes format */
+ info = drm_format_info(DRM_FORMAT_NV12);
+ FAIL_ON(!info);
+ FAIL_ON(drm_format_info_block_height(info, 0) != 1);
+ FAIL_ON(drm_format_info_block_height(info, 1) != 1);
+ FAIL_ON(drm_format_info_block_height(info, 2) != 0);
+ FAIL_ON(drm_format_info_block_height(info, -1) != 0);
+
+ /* Test 3 planes format */
+ info = drm_format_info(DRM_FORMAT_YUV422);
+ FAIL_ON(!info);
+ FAIL_ON(drm_format_info_block_height(info, 0) != 1);
+
[RESEND v7 1/7] drm/fourcc: Add char_per_block, block_w and block_h in drm_format_info
For some pixel formats .cpp structure in drm_format info it's not
enough to describe the peculiarities of the pixel layout, for example
tiled formats or packed formats at bit level.
What's implemented here is to add three new members to drm_format_info
that could describe such formats:
- char_per_block[3]
- block_w[3]
- block_h[3]
char_per_block will be put in a union alongside cpp, for transparent
compatibility with the existing format descriptions.
Regarding, block_w and block_h they are intended to be used through
their equivalent getters drm_format_info_block_width /
drm_format_info_block_height, the reason of the getters is to abstract
the fact that for normal formats block_w and block_h will be unset/0,
but the methods will be returning 1.
Additionally, convenience function drm_format_info_min_pitch had been
added that computes the minimum required pitch for a given pixel
format and buffer width.
Using that the following drm core functions had been updated to
generically handle both block and non-block formats:
- drm_fb_cma_get_gem_addr: for block formats it will just return the
beginning of the block.
- framebuffer_check: Use the newly added drm_format_info_min_pitch.
- drm_gem_fb_create_with_funcs: Use the newly added
drm_format_info_min_pitch.
- In places where is not expecting to handle block formats, like fbdev
helpers I just added some warnings in case the block width/height
are greater than 1.
Changes since v3:
- Add helper function for computing the minimum required pitch.
- Improve/cleanup documentation
Reviewed-by: Brian Starkey
Signed-off-by: Alexandru Gheorghe
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_fb_cma_helper.c | 20 ++-
drivers/gpu/drm/drm_fb_helper.c | 6 ++
drivers/gpu/drm/drm_fourcc.c | 62
drivers/gpu/drm/drm_framebuffer.c| 6 +-
drivers/gpu/drm/drm_gem_framebuffer_helper.c | 2 +-
include/drm/drm_fourcc.h | 61 ++-
6 files changed, 148 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
b/drivers/gpu/drm/drm_fb_cma_helper.c
index fc2b42dd3dc6..b07ab3f613e0 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -72,7 +72,9 @@ struct drm_gem_cma_object *drm_fb_cma_get_gem_obj(struct
drm_framebuffer *fb,
EXPORT_SYMBOL_GPL(drm_fb_cma_get_gem_obj);
/**
- * drm_fb_cma_get_gem_addr() - Get physical address for framebuffer
+ * drm_fb_cma_get_gem_addr() - Get physical address for framebuffer, for pixel
+ * formats where values are grouped in blocks this will get you the beginning
of
+ * the block
* @fb: The framebuffer
* @state: Which state of drm plane
* @plane: Which plane
@@ -87,6 +89,13 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct drm_framebuffer
*fb,
struct drm_gem_cma_object *obj;
dma_addr_t paddr;
u8 h_div = 1, v_div = 1;
+ u32 block_w = drm_format_info_block_width(fb->format, plane);
+ u32 block_h = drm_format_info_block_height(fb->format, plane);
+ u32 block_size = fb->format->char_per_block[plane];
+ u32 sample_x;
+ u32 sample_y;
+ u32 block_start_y;
+ u32 num_hblocks;
obj = drm_fb_cma_get_gem_obj(fb, plane);
if (!obj)
@@ -99,8 +108,13 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct drm_framebuffer
*fb,
v_div = fb->format->vsub;
}
- paddr += (fb->format->cpp[plane] * (state->src_x >> 16)) / h_div;
- paddr += (fb->pitches[plane] * (state->src_y >> 16)) / v_div;
+ sample_x = (state->src_x >> 16) / h_div;
+ sample_y = (state->src_y >> 16) / v_div;
+ block_start_y = (sample_y / block_h) * block_h;
+ num_hblocks = sample_x / block_w;
+
+ paddr += fb->pitches[plane] * block_start_y;
+ paddr += block_size * num_hblocks;
return paddr;
}
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 9b111e846847..8024524f0547 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1614,6 +1614,10 @@ int drm_fb_helper_check_var(struct fb_var_screeninfo
*var,
if (var->pixclock != 0 || in_dbg_master())
return -EINVAL;
+ if ((drm_format_info_block_width(fb->format, 0) > 1) ||
+ (drm_format_info_block_height(fb->format, 0) > 1))
+ return -EINVAL;
+
/*
* Changes struct fb_var_screeninfo are currently not pushed back
* to KMS, hence fail if different settings are requested.
@@ -1988,6 +1992,8 @@ void drm_fb_helper_fill_var(struct fb_info *info, struct
drm_fb_helper *fb_helpe
{
struct drm_framebuffer *fb = fb_helper->fb;
+ WARN_ON((drm_format_info_block_width(fb->format, 0) > 1) ||
+ (drm_format_info_block_height(fb->format, 0) > 1));
info->pseudo_palette = fb_helper->pseudo_palette;
info->var.xres_virtual = fb->width;
[RESEND v7 2/7] drm/fourcc: Add fourcc for Mali linear tiled formats
Mali-DP implements a number of tiled yuv formats which are not
currently described in drm_fourcc.h.
This adds those definitions and describes their memory layout by
using the newly added char_per_block, block_w, block_h.
Reviewed-by: Brian Starkey
Reviewed-by: Daniel Vetter
Signed-off-by: Alexandru Gheorghe
---
drivers/gpu/drm/drm_fourcc.c | 12
include/uapi/drm/drm_fourcc.h | 14 ++
2 files changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 00c96dbdcad5..aaae6152ee5e 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -225,6 +225,18 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_UYVY,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_VYUY,.depth = 0,
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_AYUV,.depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true,
.is_yuv = true },
+ { .format = DRM_FORMAT_Y0L0,.depth = 0,
.num_planes = 1,
+ .char_per_block = { 8, 0, 0 }, .block_w = { 2, 0, 0 },
.block_h = { 2, 0, 0 },
+ .hsub = 2, .vsub = 2, .has_alpha = true, .is_yuv = true },
+ { .format = DRM_FORMAT_X0L0,.depth = 0,
.num_planes = 1,
+ .char_per_block = { 8, 0, 0 }, .block_w = { 2, 0, 0 },
.block_h = { 2, 0, 0 },
+ .hsub = 2, .vsub = 2, .is_yuv = true },
+ { .format = DRM_FORMAT_Y0L2,.depth = 0,
.num_planes = 1,
+ .char_per_block = { 8, 0, 0 }, .block_w = { 2, 0, 0 },
.block_h = { 2, 0, 0 },
+ .hsub = 2, .vsub = 2, .has_alpha = true, .is_yuv = true },
+ { .format = DRM_FORMAT_X0L2,.depth = 0,
.num_planes = 1,
+ .char_per_block = { 8, 0, 0 }, .block_w = { 2, 0, 0 },
.block_h = { 2, 0, 0 },
+ .hsub = 2, .vsub = 2, .is_yuv = true },
};
unsigned int i;
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 0cd40ebfa1b1..e7e48f1f4a74 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -152,6 +152,20 @@ extern "C" {
#define DRM_FORMAT_AYUVfourcc_code('A', 'Y', 'U', 'V') /*
[31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
+/*
+ * packed YCbCr420 2x2 tiled formats
+ * first 64 bits will contain Y,Cb,Cr components for a 2x2 tile
+ */
+/* [63:0] A3:A2:Y3:0:Cr0:0:Y2:0:A1:A0:Y1:0:Cb0:0:Y0:0
1:1:8:2:8:2:8:2:1:1:8:2:8:2:8:2 little endian */
+#define DRM_FORMAT_Y0L0fourcc_code('Y', '0', 'L', '0')
+/* [63:0] X3:X2:Y3:0:Cr0:0:Y2:0:X1:X0:Y1:0:Cb0:0:Y0:0
1:1:8:2:8:2:8:2:1:1:8:2:8:2:8:2 little endian */
+#define DRM_FORMAT_X0L0fourcc_code('X', '0', 'L', '0')
+
+/* [63:0] A3:A2:Y3:Cr0:Y2:A1:A0:Y1:Cb0:Y0 1:1:10:10:10:1:1:10:10:10 little
endian */
+#define DRM_FORMAT_Y0L2fourcc_code('Y', '0', 'L', '2')
+/* [63:0] X3:X2:Y3:Cr0:Y2:X1:X0:Y1:Cb0:Y0 1:1:10:10:10:1:1:10:10:10 little
endian */
+#define DRM_FORMAT_X0L2fourcc_code('X', '0', 'L', '2')
+
/*
* 2 plane RGB + A
* index 0 = RGB plane, same format as the corresponding non _A8 format has
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND v7 0/7] Add method to describe tile/bit_level_packed formats
Basically, just a resend before I merge these patches in drm-misc-next. Changes since v6: - Collected Reviewed-by. - Fixed author, seems dim it's not smart enough to know "Alexandru Gheorghe" is the same with Alexandru-Cosmin Gheorghe :). - Fixed conflicts against latest drm-misc-next. - Dropped the patches that added the fourccs for AFBC only, that should be merged when driver implementation is ready. Alexandru Gheorghe (7): drm/fourcc: Add char_per_block, block_w and block_h in drm_format_info drm/fourcc: Add fourcc for Mali linear tiled formats drm: mali-dp: Enable Mali-DP tiled buffer formats drm: Extend framebuffer_check to handle formats with cpp/char_per_block 0 drm/selftests: Add tests for drm_format_info* helpers drm: Add macro to export functions only when CONFIG_DRM_DEBUG_SELFTEST is enabled drm/selftests: Add tests for drm_internal_framebuffer_create drivers/gpu/drm/arm/malidp_hw.c | 14 +- drivers/gpu/drm/arm/malidp_planes.c | 28 +- drivers/gpu/drm/drm_fb_cma_helper.c | 20 +- drivers/gpu/drm/drm_fb_helper.c | 6 + drivers/gpu/drm/drm_fourcc.c | 74 drivers/gpu/drm/drm_framebuffer.c | 13 +- drivers/gpu/drm/drm_gem_framebuffer_helper.c | 2 +- drivers/gpu/drm/selftests/Makefile| 3 +- .../gpu/drm/selftests/drm_modeset_selftests.h | 4 + drivers/gpu/drm/selftests/test-drm_format.c | 280 ++ .../gpu/drm/selftests/test-drm_framebuffer.c | 344 ++ .../drm/selftests/test-drm_modeset_common.h | 4 + include/drm/drmP.h| 6 + include/drm/drm_fourcc.h | 61 +++- include/uapi/drm/drm_fourcc.h | 14 + 15 files changed, 857 insertions(+), 16 deletions(-) create mode 100644 drivers/gpu/drm/selftests/test-drm_format.c create mode 100644 drivers/gpu/drm/selftests/test-drm_framebuffer.c -- 2.19.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm: Optimize GPU crashstate capture read path
On Thu, Nov 01, 2018 at 02:05:41PM +0530, Sharat Masetty wrote:
> When the userspace tries to read the crashstate dump, the read side
> implementation in the driver currently ascii85 encodes all the binary
> buffers and it does this each time the read system call is called.
> A userspace tool like cat typically does a page by page read and the
> number of read calls depends on the size of the data captured by the
> driver. This is certainly not desirable and does not scale well with
> large captures.
>
> This patch starts off with moving the encoding part to the capture time,
> that is when the GPU tries to recover after a hang. Now we only encode
> once per buffer object and not per page read. With this there is an
> immediate >10X speed improvement in crashstate save time.
>
> The flip side however is that the GPU recovery time increases and this
> negatively impacts the user experience, so this is handled by moving the
> encoding part to a worker thread and only register with the dev_coredump
> once the encoding of the buffers is complete.
Does your tree have https://patchwork.freedesktop.org/patch/257181/ ? That will
help with a lot of the problems you have described.
> Signed-off-by: Sharat Masetty
> ---
> drivers/gpu/drm/msm/adreno/adreno_gpu.c | 35 +++--
> drivers/gpu/drm/msm/msm_gpu.c | 93
> +++--
> drivers/gpu/drm/msm/msm_gpu.h | 1 +
> 3 files changed, 98 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> index 141062f..7441571 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> @@ -406,7 +406,7 @@ int adreno_gpu_state_get(struct msm_gpu *gpu, struct
> msm_gpu_state *state)
> size = j + 1;
>
> if (size) {
> - state->ring[i].data = kmalloc(size << 2, GFP_KERNEL);
> + state->ring[i].data = kvmalloc(size << 2, GFP_KERNEL);
> if (state->ring[i].data) {
> memcpy(state->ring[i].data, gpu->rb[i]->start,
> size << 2);
> state->ring[i].data_size = size << 2;
This is a good fix, but unrelated to this change as detailed above. Should be
separate.
> @@ -445,7 +445,7 @@ void adreno_gpu_state_destroy(struct msm_gpu_state *state)
> int i;
>
> for (i = 0; i < ARRAY_SIZE(state->ring); i++)
> - kfree(state->ring[i].data);
> + kvfree(state->ring[i].data);
As above.
>
> for (i = 0; state->bos && i < state->nr_bos; i++)
> kvfree(state->bos[i].data);
> @@ -475,34 +475,15 @@ int adreno_gpu_state_put(struct msm_gpu_state *state)
>
> #if defined(CONFIG_DEBUG_FS) || defined(CONFIG_DEV_COREDUMP)
>
> -static void adreno_show_object(struct drm_printer *p, u32 *ptr, int len)
> +static void adreno_show_object(struct drm_printer *p, void *ptr)
> {
> - char out[ASCII85_BUFSZ];
> - long l, datalen, i;
> -
> - if (!ptr || !len)
> - return;
> -
> - /*
> - * Only dump the non-zero part of the buffer - rarely will any data
> - * completely fill the entire allocated size of the buffer
> - */
> - for (datalen = 0, i = 0; i < len >> 2; i++) {
> - if (ptr[i])
> - datalen = (i << 2) + 1;
> - }
> -
> - /* Skip printing the object if it is empty */
> - if (datalen == 0)
> + if (!ptr)
> return;
>
> - l = ascii85_encode_len(datalen);
> -
> drm_puts(p, "data: !!ascii85 |\n");
> drm_puts(p, " ");
>
> - for (i = 0; i < l; i++)
> - drm_puts(p, ascii85_encode(ptr[i], out));
> + drm_puts(p, ptr);
>
> drm_puts(p, "\n");
> }
> @@ -534,8 +515,7 @@ void adreno_show(struct msm_gpu *gpu, struct
> msm_gpu_state *state,
> drm_printf(p, "wptr: %d\n", state->ring[i].wptr);
> drm_printf(p, "size: %d\n", MSM_GPU_RINGBUFFER_SZ);
>
> - adreno_show_object(p, state->ring[i].data,
> - state->ring[i].data_size);
> + adreno_show_object(p, state->ring[i].data);
> }
>
> if (state->bos) {
> @@ -546,8 +526,7 @@ void adreno_show(struct msm_gpu *gpu, struct
> msm_gpu_state *state,
> state->bos[i].iova);
> drm_printf(p, "size: %zd\n", state->bos[i].size);
>
> - adreno_show_object(p, state->bos[i].data,
> - state->bos[i].size);
> + adreno_show_object(p, state->bos[i].data);
> }
> }
>
> diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
> index ff95848..d5533f1 100644
> --- a/drivers/gpu/drm/msm/msm_gpu.c
> +++ b/drivers/gpu/drm/msm/msm_gpu.c
> @@ -21,6 +21,7 @@
> #include "msm_fence.h"
>
> #include
>
Re: [PATCH v4 3/4] drm: Document variable refresh properties
On 11/1/18 6:58 AM, Michel Dänzer wrote: > On 2018-10-31 6:54 p.m., Kazlauskas, Nicholas wrote: >> On 10/31/18 12:20 PM, Michel Dänzer wrote: >>> On 2018-10-31 3:41 p.m., Kazlauskas, Nicholas wrote: On 10/31/18 10:12 AM, Michel Dänzer wrote: > On 2018-10-31 2:38 p.m., Kazlauskas, Nicholas wrote: >> On 10/30/18 11:34 AM, Kazlauskas, Nicholas wrote: >>> >>> I understand the issue you're describing now. The timestamp is supposed >>> to signify the end of the current vblank. The call to get scanout >>> position is supposed to return the number of lines until scanout (a >>> negative value) or the number of lines since the next scanout began (a >>> positive value). >>> >>> The amdgpu driver calculates the number of lines based on a hardware >>> register status position which returns an increasing value from 0 that >>> indicates the current vpos/hpos for the display. >>> >>> For any vpos below vbl_start we know the value is correct since the next >>> vblank hasn't begun yet. But for anythign about vbl_start it's probably >>> wrong since it applies a corrective offset based on the fixed value of >>> crtc_vtotal. It's even worse when the value is above crtc_vtotal since >>> it'll be calculating the number of lines since the last scanout since >>> it'll be a positive value. >>> >>> So the issue becomes determining when the vfront porch will end. >>> >>> When the flip address gets written the vfront porch will end at the >>> start of the next line leaving only the back porch plus part of the >>> line. But we don't know when the flip will occur, if at all. It hasn't >>> occurred yet in this case. >>> >>> Waiting for the wrap around to 0 might be the best choice here since >>> there's no guarantee the flip will occur. >> >> I put some more thought into this and I don't think this is as bad as I >> had originally thought. >> >> I think the vblank timestamp is supposed to be for the first active >> pixel of the next scanout. The usage of which is for clients to time >> their content/animation/etc. >> >> The client likely doesn't care when they issue their flip, just that >> their content is matched for that vblank timestamp. The fixed refresh >> model works really well for that kind of application. >> >> Utilizing variable refresh rate would be a mistake in that case since >> the client would then have to time based on when they flip which is a >> lot harder to "predict" precisely. > > It's only a "mistake" as long as the timestamps are misleading. :) As > discussed before, accurate presentation timestamps are one requirement > for achieving perfectly smooth animation. For most 3D games the game world/rendering can advance by an arbitrary timestep - and faster will be smoother, which is what the native mode would give you. For fixed interval content/animation where you can't do that variable refresh rate could vastly improve the output. But like discussed before that would need a way to specify the interval/presentation timestamp to control that front porch duration. The timestamp will be misleading in any other case. >>> >>> I don't agree that an accurate timestamp can ever be more "misleading" >>> than an inaccurate one. But yeah, accurate timestamps and time-based >>> presentation are two sides of the same coin which can buy the holy grail >>> of perfectly smooth animation. :) >>> >>> >> I did some more investigation into when amdgpu gets the scanout position >> and what values we get back out of it. The timestamp is updated shortly >> after the crtc irq vblank which is typically within a few lines of >> vbl_start. This makes sense, since we can provide the prediction >> timestamp early. Waiting for the vblank to wrap around to 0 doesn't >> really make sense here since that would mean we already hit timeout or >> the flip occurred > > Sounds like you're mixing up the two cases of "actual" vblank events > (triggered by the "vblank" interrupt => drm_(crtc_)handle_vblank) and > flip completion events (triggered by the PFLIP interrupt with our > hardware => drm_crtc_send_vblank_event). > > Actual vblank events need to be delivered to userspace at the start of > vblank, so we indeed can't wait until the timestamp is accurate for > them. We just need to document the exact semantics of their timestamp > with VRR. > > For page flip completion events though, the timestamp needs to be > accurate and correspond to when the flipped frame starts being scanned > out, otherwise we'll surely break at least some userspace relying on > this information. > Yeah, I was. I guess what's sent is the estimated vblank timestamp calculated at the start of the interrupt. >>> >>> s/interrupt/vblank/,
[PATCH] drm/msm: Optimize adreno_show_object()
When the userspace tries to read the crashstate dump, the read side
implementation in the driver currently ascii85 encodes all the binary
buffers and it does this each time the read system call is called.
A userspace tool like cat typically does a page by page read and the
number of read calls depends on the size of the data captured by the
driver. This is certainly not desirable and does not scale well with
large captures.
This patch encodes the buffer only once in the read path. With this there
is an immediate >10X speed improvement in crashstate save time.
Signed-off-by: Sharat Masetty
---
This is a different and a simpler version of [1]. We move the encode back to
read time and make sure each buffer is encoded just once. This is showing
similar performance numbers as [1] for similar capture sizes.
1) https://patchwork.freedesktop.org/patch/259627/
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 82 -
drivers/gpu/drm/msm/msm_gpu.h | 2 +
2 files changed, 63 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index 141062f..6251e76 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -406,7 +406,7 @@ int adreno_gpu_state_get(struct msm_gpu *gpu, struct
msm_gpu_state *state)
size = j + 1;
if (size) {
- state->ring[i].data = kmalloc(size << 2, GFP_KERNEL);
+ state->ring[i].data = kvmalloc(size << 2, GFP_KERNEL);
if (state->ring[i].data) {
memcpy(state->ring[i].data, gpu->rb[i]->start,
size << 2);
state->ring[i].data_size = size << 2;
@@ -445,7 +445,7 @@ void adreno_gpu_state_destroy(struct msm_gpu_state *state)
int i;
for (i = 0; i < ARRAY_SIZE(state->ring); i++)
- kfree(state->ring[i].data);
+ kvfree(state->ring[i].data);
for (i = 0; state->bos && i < state->nr_bos; i++)
kvfree(state->bos[i].data);
@@ -475,34 +475,74 @@ int adreno_gpu_state_put(struct msm_gpu_state *state)
#if defined(CONFIG_DEBUG_FS) || defined(CONFIG_DEV_COREDUMP)
-static void adreno_show_object(struct drm_printer *p, u32 *ptr, int len)
+static char *adreno_gpu_ascii85_encode(u32 *src, size_t len)
{
+ void *buf;
+ size_t buf_itr = 0, buffer_size;
char out[ASCII85_BUFSZ];
- long l, datalen, i;
+ long l;
+ int i;
- if (!ptr || !len)
- return;
+ if (!src || !len)
+ return NULL;
+
+ l = ascii85_encode_len(len);
/*
-* Only dump the non-zero part of the buffer - rarely will any data
-* completely fill the entire allocated size of the buffer
+* Ascii85 outputs either a 5 byte string or a 1 byte string. So we
+* account for the worst case of 5 bytes per dword plus the 1 for '\0'
*/
- for (datalen = 0, i = 0; i < len >> 2; i++) {
- if (ptr[i])
- datalen = (i << 2) + 1;
- }
+ buffer_size = (l * 5) + 1;
+
+ buf = kvmalloc(buffer_size, GFP_KERNEL);
+ if (!buf)
+ return NULL;
- /* Skip printing the object if it is empty */
- if (datalen == 0)
+ for (i = 0; i < l; i++)
+ buf_itr += snprintf(buf + buf_itr, buffer_size - buf_itr, "%s",
+ ascii85_encode(src[i], out));
+
+ return buf;
+}
+
+/* len is expected to be in bytes */
+static void adreno_show_object(struct drm_printer *p, void **ptr, int len,
+ bool *encoded)
+{
+ if (!*ptr || !len)
return;
- l = ascii85_encode_len(datalen);
+ if (!*encoded) {
+ long datalen, i;
+ u32 *buf = *ptr;
+
+ /*
+* Only dump the non-zero part of the buffer - rarely will
+* any data completely fill the entire allocated size of
+* the buffer.
+*/
+ for (datalen = 0, i = 0; i < len >> 2; i++)
+ if (buf[i])
+ datalen = ((i + 1) << 2);
+
+ /*
+* If we reach here, then the originally captured binary buffer
+* will be replaced with the ascii85 encoded string
+*/
+ *ptr = adreno_gpu_ascii85_encode(buf, datalen);
+
+ kvfree(buf);
+
+ *encoded = true;
+ }
+
+ if (!*ptr)
+ return;
drm_puts(p, "data: !!ascii85 |\n");
drm_puts(p, " ");
- for (i = 0; i < l; i++)
- drm_puts(p, ascii85_encode(ptr[i], out));
+ drm_puts(p, *ptr);
drm_puts(p, "\n");
}
@@ -534,8 +574,8 @@ void adreno_show(struct msm_gpu *gpu, struct msm_gpu_state
*state,
Re: [PATCH v2 8/9] drm/tilcdc: Use drm_fbdev_generic_setup()
Den 29.10.2018 16.55, skrev Jyri Sarha: On 25/10/18 23:13, Noralf Trønnes wrote: The CMA helper is already using the drm_fb_helper_generic_probe part of the generic fbdev emulation. This patch makes full use of the generic fbdev emulation by using its drm_client callbacks. This means that drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are now handled by the emulation code. Additionally fbdev unregister happens automatically on drm_dev_unregister(). The drm_fbdev_generic_setup() call is put after drm_dev_register() in the driver. This is done to highlight the fact that fbdev emulation is an internal client that makes use of the driver, it is not part of the driver as such. If fbdev setup fails, an error is printed, but the driver succeeds probing. Cc: Jyri Sarha Cc: Tomi Valkeinen Signed-off-by: Noralf Trønnes Acked-by: Sam Ravnborg Thanks! Acked-by: Jyri Sarha Applied to drm-misc-next. Noralf. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 7/9] drm/sun4i: Use drm_fbdev_generic_setup()
Den 26.10.2018 10.27, skrev Maxime Ripard: On Thu, Oct 25, 2018 at 10:13:38PM +0200, Noralf Trønnes wrote: The CMA helper is already using the drm_fb_helper_generic_probe part of the generic fbdev emulation. This patch makes full use of the generic fbdev emulation by using its drm_client callbacks. This means that drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are now handled by the emulation code. Additionally fbdev unregister happens automatically on drm_dev_unregister(). The drm_fbdev_generic_setup() call is put after drm_dev_register() in the driver. This is done to highlight the fact that fbdev emulation is an internal client that makes use of the driver, it is not part of the driver as such. If fbdev setup fails, an error is printed, but the driver succeeds probing. Cc: Maxime Ripard Signed-off-by: Noralf Trønnes Acked-by: Sam Ravnborg Acked-by: Maxime Ripard Applied to drm-misc-next. Noralf. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 6/9] drm/atmel-hlcdc: Use drm_fbdev_generic_setup()
Den 25.10.2018 22.25, skrev Boris Brezillon: On Thu, 25 Oct 2018 22:13:37 +0200 Noralf Trønnes wrote: The CMA helper is already using the drm_fb_helper_generic_probe part of the generic fbdev emulation. This patch makes full use of the generic fbdev emulation by using its drm_client callbacks. This means that drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are now handled by the emulation code. Additionally fbdev unregister happens automatically on drm_dev_unregister(). The drm_fbdev_generic_setup() call is put after drm_dev_register() in the driver. This is done to highlight the fact that fbdev emulation is an internal client that makes use of the driver, it is not part of the driver as such. If fbdev setup fails, an error is printed, but the driver succeeds probing. Cc: Boris Brezillon Signed-off-by: Noralf Trønnes Acked-by: Sam Ravnborg Acked-by: Boris Brezillon Applied to drm-misc-next. Noralf. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/9] drm/fsl-dcu: Use drm_fbdev_generic_setup()
Den 25.10.2018 22.13, skrev Noralf Trønnes: The CMA helper is already using the drm_fb_helper_generic_probe part of the generic fbdev emulation. This patch makes full use of the generic fbdev emulation by using its drm_client callbacks. This means that drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are now handled by the emulation code. Additionally fbdev unregister happens automatically on drm_dev_unregister(). The drm_fbdev_generic_setup() call is put after drm_dev_register() in the driver. This is done to highlight the fact that fbdev emulation is an internal client that makes use of the driver, it is not part of the driver as such. If fbdev setup fails, an error is printed, but the driver succeeds probing. Cc: Stefan Agner Cc: Alison Wang Signed-off-by: Noralf Trønnes Acked-by: Sam Ravnborg Acked-by: Stefan Agner --- Applied to drm-misc-next. Noralf. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/9] drm/arc: Use drm_fbdev_generic_setup()
Den 25.10.2018 22.13, skrev Noralf Trønnes: The CMA helper is already using the drm_fb_helper_generic_probe part of the generic fbdev emulation. This patch makes full use of the generic fbdev emulation by using its drm_client callbacks. This means that drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are now handled by the emulation code. Additionally fbdev unregister happens automatically on drm_dev_unregister(). The drm_fbdev_generic_setup() call is put after drm_dev_register() in the driver. This is done to highlight the fact that fbdev emulation is an internal client that makes use of the driver, it is not part of the driver as such. If fbdev setup fails, an error is printed, but the driver succeeds probing. Cc: Alexey Brodkin Signed-off-by: Noralf Trønnes Acked-by: Sam Ravnborg Acked-by: Alexey Brodkin --- Applied to drm-misc-next. Noralf. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108096] [amd-staging-drm-next] SDDM screen corruption (not usable) with RX580, amdgpu, dc=1 (of course), regression - [bisected]
https://bugs.freedesktop.org/show_bug.cgi?id=108096 --- Comment #25 from Andrey Grodzovsky --- (In reply to Dieter Nützel from comment #24) > (In reply to Andrey Grodzovsky from comment #22) > > (In reply to Andrey Grodzovsky from comment #21) > > > Please load the driver in debug mode so I can see the error code value in > > > dmesg - > > > when loading the kernel add drm.debug=0xff > > > > > > Also to trace where exactly the error originated from please install > > > trace-cmd and beore starting X (assuming you get the failure and the dmesg > > > error right on start) > > > sudo trace-cmd start -p function_graph -l amdgpu_cs_ioctl > > > and get the output from /sys/kernel/debug/tracing/trace > > > > My bad, the correct command is > > sudo trace-cmd start -p function_graph -g amdgpu_cs_ioctl > > Andrey, do you need these logs even after my commit #23? If everything is working fine after whatever you did then no. -- 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 201585] 144Hz 2560x1440 no longer works (caps at 120Hz)
https://bugzilla.kernel.org/show_bug.cgi?id=201585 --- Comment #7 from Nicholas Kazlauskas (nicholas.kazlaus...@amd.com) --- It may also help to have a dmesg log for 4.18 with drm.debug=4 as part of your bootline. Thanks for all the logs. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 201585] 144Hz 2560x1440 no longer works (caps at 120Hz)
https://bugzilla.kernel.org/show_bug.cgi?id=201585 --- Comment #6 from Dan Acristinii (d...@acristinii.com) --- Created attachment 279287 --> https://bugzilla.kernel.org/attachment.cgi?id=279287=edit 144Hz working dmesg on 4.17.19 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 201585] 144Hz 2560x1440 no longer works (caps at 120Hz)
https://bugzilla.kernel.org/show_bug.cgi?id=201585 --- Comment #5 from Dan Acristinii (d...@acristinii.com) --- The issue persists on 4.19 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 201585] 144Hz 2560x1440 no longer works (caps at 120Hz)
https://bugzilla.kernel.org/show_bug.cgi?id=201585 --- Comment #4 from Dan Acristinii (d...@acristinii.com) --- Created attachment 279285 --> https://bugzilla.kernel.org/attachment.cgi?id=279285=edit dmesg.log on 4.18 -- 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
