Re: [PATCH v2 09/20] drm/i915: Remove references to struct drm_device.pdev
ping for a review of the i915 patches
Am 01.12.20 um 11:35 schrieb Thomas Zimmermann:
Using struct drm_device.pdev is deprecated. Convert i915 to struct
drm_device.dev. No functional changes.
v2:
* move gt/ and gvt/ changes into separate patches
Signed-off-by: Thomas Zimmermann
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
---
drivers/gpu/drm/i915/display/intel_bios.c | 2 +-
drivers/gpu/drm/i915/display/intel_cdclk.c| 14 ++---
drivers/gpu/drm/i915/display/intel_csr.c | 2 +-
drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 2 +-
drivers/gpu/drm/i915/display/intel_fbdev.c| 2 +-
drivers/gpu/drm/i915/display/intel_gmbus.c| 2 +-
.../gpu/drm/i915/display/intel_lpe_audio.c| 5 +++--
drivers/gpu/drm/i915/display/intel_opregion.c | 6 +++---
drivers/gpu/drm/i915/display/intel_overlay.c | 2 +-
drivers/gpu/drm/i915/display/intel_panel.c| 4 ++--
drivers/gpu/drm/i915/display/intel_quirks.c | 2 +-
drivers/gpu/drm/i915/display/intel_sdvo.c | 2 +-
drivers/gpu/drm/i915/display/intel_vga.c | 8
drivers/gpu/drm/i915/gem/i915_gem_phys.c | 6 +++---
drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 2 +-
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
drivers/gpu/drm/i915/i915_drv.c | 20 +--
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/i915_gem_gtt.c | 4 ++--
drivers/gpu/drm/i915/i915_getparam.c | 5 +++--
drivers/gpu/drm/i915/i915_gpu_error.c | 2 +-
drivers/gpu/drm/i915/i915_irq.c | 6 +++---
drivers/gpu/drm/i915/i915_pmu.c | 5 +++--
drivers/gpu/drm/i915/i915_suspend.c | 4 ++--
drivers/gpu/drm/i915/i915_switcheroo.c| 4 ++--
drivers/gpu/drm/i915/i915_vgpu.c | 2 +-
drivers/gpu/drm/i915/intel_device_info.c | 2 +-
drivers/gpu/drm/i915/intel_region_lmem.c | 8
drivers/gpu/drm/i915/intel_runtime_pm.c | 2 +-
drivers/gpu/drm/i915/intel_uncore.c | 4 ++--
.../gpu/drm/i915/selftests/mock_gem_device.c | 1 -
drivers/gpu/drm/i915/selftests/mock_gtt.c | 2 +-
32 files changed, 68 insertions(+), 68 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
b/drivers/gpu/drm/i915/display/intel_bios.c
index 4cc949b228f2..8879676372a3 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -2088,7 +2088,7 @@ bool intel_bios_is_valid_vbt(const void *buf, size_t size)
static struct vbt_header *oprom_get_vbt(struct drm_i915_private *dev_priv)
{
- struct pci_dev *pdev = dev_priv->drm.pdev;
+ struct pci_dev *pdev = to_pci_dev(dev_priv->drm.dev);
void __iomem *p = NULL, *oprom;
struct vbt_header *vbt;
u16 vbt_size;
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index c449d28d0560..a6e13208dc50 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -96,7 +96,7 @@ static void fixed_450mhz_get_cdclk(struct drm_i915_private
*dev_priv,
static void i85x_get_cdclk(struct drm_i915_private *dev_priv,
struct intel_cdclk_config *cdclk_config)
{
- struct pci_dev *pdev = dev_priv->drm.pdev;
+ struct pci_dev *pdev = to_pci_dev(dev_priv->drm.dev);
u16 hpllcc = 0;
/*
@@ -138,7 +138,7 @@ static void i85x_get_cdclk(struct drm_i915_private
*dev_priv,
static void i915gm_get_cdclk(struct drm_i915_private *dev_priv,
struct intel_cdclk_config *cdclk_config)
{
- struct pci_dev *pdev = dev_priv->drm.pdev;
+ struct pci_dev *pdev = to_pci_dev(dev_priv->drm.dev);
u16 gcfgc = 0;
pci_read_config_word(pdev, GCFGC, &gcfgc);
@@ -162,7 +162,7 @@ static void i915gm_get_cdclk(struct drm_i915_private
*dev_priv,
static void i945gm_get_cdclk(struct drm_i915_private *dev_priv,
struct intel_cdclk_config *cdclk_config)
{
- struct pci_dev *pdev = dev_priv->drm.pdev;
+ struct pci_dev *pdev = to_pci_dev(dev_priv->drm.dev);
u16 gcfgc = 0;
pci_read_config_word(pdev, GCFGC, &gcfgc);
@@ -256,7 +256,7 @@ static unsigned int intel_hpll_vco(struct drm_i915_private
*dev_priv)
static void g33_get_cdclk(struct drm_i915_private *dev_priv,
struct intel_cdclk_config *cdclk_config)
{
- struct pci_dev *pdev = dev_priv->drm.pdev;
+ struct pci_dev *pdev = to_pci_dev(dev_priv->drm.dev);
static const u8 div_3200[] = { 12, 10, 8, 7, 5, 16 };
static const u8 div_4000[] = { 14, 12, 10, 8, 6, 20 };
static const u8 div_4800[] = { 20, 14, 12, 10, 8, 24 };
@@ -305,7 +305,7 @@ static void g33_get_cdclk(struct drm_i915_private *dev_priv,
static void pnv_get_cdclk(struct drm_i915_private *dev_priv,
[PATCH v4 16/16] drm/i915: Enable PCON configuration for Color Conversion for TGL
This patch enables PCON configuration for color space conversion for TGL+ platfrom. This will help in supporting 8k@60 YUV420 modes common in HDMI 8k panels, through a capable PCON. Also allow 8k@60 YUV420 modes, only if PCON claims to support the color space conversion. Signed-off-by: Ankit Nautiyal --- drivers/gpu/drm/i915/display/intel_ddi.c | 1 + drivers/gpu/drm/i915/display/intel_dp.c | 5 + 2 files changed, 6 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c b/drivers/gpu/drm/i915/display/intel_ddi.c index 721a47bbc009..ed6b8ea85408 100644 --- a/drivers/gpu/drm/i915/display/intel_ddi.c +++ b/drivers/gpu/drm/i915/display/intel_ddi.c @@ -3644,6 +3644,7 @@ static void tgl_ddi_pre_enable_dp(struct intel_atomic_state *state, if (!is_mst) intel_dp_set_power(intel_dp, DP_SET_POWER_D0); + intel_dp_configure_protocol_converter(intel_dp); intel_dp_sink_set_decompression_state(intel_dp, crtc_state, true); /* * DDI FEC: "anticipates enabling FEC encoding sets the FEC_READY bit diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c index b3f1190d8150..86289c925612 100644 --- a/drivers/gpu/drm/i915/display/intel_dp.c +++ b/drivers/gpu/drm/i915/display/intel_dp.c @@ -720,6 +720,11 @@ intel_dp_mode_valid_downstream(struct intel_connector *connector, const struct drm_display_info *info = &connector->base.display_info; int tmds_clock; + /* Allow 8k YUV420 modes, only if PCON supports RGB->YUV conversion */ + if (mode->hdisplay == 7680 && drm_mode_is_420_only(info, mode) && + !intel_dp->dfp.rgb_to_ycbcr) + return MODE_NO_420; + /* * If PCON and HDMI2.1 sink both support FRL MODE, check FRL * bandwidth constraints. -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 15/16] drm/i915: Let PCON convert from RGB to YUV if it can
If PCON has capability to convert RGB->YUV colorspace and also
to 444->420 downsampling then for any YUV420 only mode, we can
let the PCON do all the conversion.
Signed-off-by: Ankit Nautiyal
---
.../drm/i915/display/intel_display_types.h| 1 +
drivers/gpu/drm/i915/display/intel_dp.c | 37 +--
2 files changed, 26 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index b41de41759a0..4150108bdc6d 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1460,6 +1460,7 @@ struct intel_dp {
int pcon_max_frl_bw, sink_max_frl_bw;
u8 max_bpc;
bool ycbcr_444_to_420;
+ bool rgb_to_ycbcr;
} dfp;
/* Display stream compression testing */
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 30c76ba63232..b3f1190d8150 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -651,6 +651,10 @@ intel_dp_output_format(struct drm_connector *connector,
!drm_mode_is_420_only(info, mode))
return INTEL_OUTPUT_FORMAT_RGB;
+ if (intel_dp->dfp.rgb_to_ycbcr &&
+ intel_dp->dfp.ycbcr_444_to_420)
+ return INTEL_OUTPUT_FORMAT_RGB;
+
if (intel_dp->dfp.ycbcr_444_to_420)
return INTEL_OUTPUT_FORMAT_YCBCR444;
else
@@ -4365,13 +4369,12 @@ void intel_dp_configure_protocol_converter(struct
intel_dp *intel_dp)
"Failed to set protocol converter YCbCr 4:2:0
conversion mode to %s\n",
enableddisabled(intel_dp->dfp.ycbcr_444_to_420));
- tmp = 0;
-
- if (drm_dp_dpcd_writeb(&intel_dp->aux,
- DP_PROTOCOL_CONVERTER_CONTROL_2, tmp) <= 0)
+ tmp = intel_dp->dfp.rgb_to_ycbcr ?
+ DP_CONVERSION_BT601_RGB_YCBCR_ENABLE : 0;
+ if (drm_dp_pcon_convert_rgb_to_ycbcr(&intel_dp->aux, tmp) <= 0)
drm_dbg_kms(&i915->drm,
- "Failed to set protocol converter YCbCr 4:2:2
conversion mode to %s\n",
- enableddisabled(false));
+ "Failed to set protocol converter RGB->YCbCr
conversion mode to %s\n",
+ enableddisabled(intel_dp->dfp.rgb_to_ycbcr));
}
static void intel_enable_dp(struct intel_atomic_state *state,
@@ -6897,7 +6900,7 @@ intel_dp_update_420(struct intel_dp *intel_dp)
{
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
struct intel_connector *connector = intel_dp->attached_connector;
- bool is_branch, ycbcr_420_passthrough, ycbcr_444_to_420;
+ bool is_branch, ycbcr_420_passthrough, ycbcr_444_to_420, rgb_to_ycbcr;
/* No YCbCr output support on gmch platforms */
if (HAS_GMCH(i915))
@@ -6919,14 +6922,23 @@ intel_dp_update_420(struct intel_dp *intel_dp)
dp_to_dig_port(intel_dp)->lspcon.active ||
drm_dp_downstream_444_to_420_conversion(intel_dp->dpcd,
intel_dp->downstream_ports);
+ rgb_to_ycbcr = drm_dp_downstream_rgb_to_ycbcr_conversion(intel_dp->dpcd,
+
intel_dp->downstream_ports);
if (INTEL_GEN(i915) >= 11) {
+ /* Let PCON convert from RGB->YCbCr if possible */
+ if (is_branch && rgb_to_ycbcr && ycbcr_444_to_420) {
+ intel_dp->dfp.rgb_to_ycbcr = true;
+ intel_dp->dfp.ycbcr_444_to_420 = true;
+ connector->base.ycbcr_420_allowed = true;
+ } else {
/* Prefer 4:2:0 passthrough over 4:4:4->4:2:0 conversion */
- intel_dp->dfp.ycbcr_444_to_420 =
- ycbcr_444_to_420 && !ycbcr_420_passthrough;
+ intel_dp->dfp.ycbcr_444_to_420 =
+ ycbcr_444_to_420 && !ycbcr_420_passthrough;
- connector->base.ycbcr_420_allowed =
- !is_branch || ycbcr_444_to_420 || ycbcr_420_passthrough;
+ connector->base.ycbcr_420_allowed =
+ !is_branch || ycbcr_444_to_420 ||
ycbcr_420_passthrough;
+ }
} else {
/* 4:4:4->4:2:0 conversion is the only way */
intel_dp->dfp.ycbcr_444_to_420 = ycbcr_444_to_420;
@@ -6935,8 +6947,9 @@ intel_dp_update_420(struct intel_dp *intel_dp)
}
drm_dbg_kms(&i915->drm,
- "[CONNECTOR:%d:%s] YCbCr 4:2:0 allowed? %s, YCbCr
4:4:4->4:2:0 conversion? %s\n",
+ "[CONNECTOR:%d:%s] RGB->YcbCr conversion? %s, YCbCr 4:2:0
allowed? %s, YCbCr 4:4:4->4:2:0 conversion? %s\n",
[PATCH v4 14/16] drm/i915/display: Configure PCON for DSC1.1 to DSC1.2 encoding
When a source supporting DSC1.1 is connected to DSC1.2 HDMI2.1 sink
via DP HDMI2.1 PCON, the PCON can be configured to decode the
DSC1.1 compressed stream and encode to DSC1.2. It then sends the
DSC1.2 compressed stream to the HDMI2.1 sink.
This patch configures the PCON for DSC1.1 to DSC1.2 encoding, based
on the PCON's DSC encoder capablities and HDMI2.1 sink's DSC decoder
capabilities.
v2: Addressed review comments from Uma Shankar:
-fixed the error in packing pps parameter values
-added check for pcon in the pcon related function
-appended display in commit message
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_ddi.c | 1 +
drivers/gpu/drm/i915/display/intel_dp.c | 117 ++-
drivers/gpu/drm/i915/display/intel_dp.h | 2 +
3 files changed, 118 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 3ff8b18f1997..721a47bbc009 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3653,6 +3653,7 @@ static void tgl_ddi_pre_enable_dp(struct
intel_atomic_state *state,
intel_dp_sink_set_fec_ready(intel_dp, crtc_state);
intel_dp_check_frl_training(intel_dp, crtc_state);
+ intel_dp_pcon_dsc_configure(intel_dp, crtc_state);
/*
* 7.i Follow DisplayPort specification training sequence (see notes for
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 4dd272a34ee8..30c76ba63232 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4039,9 +4039,21 @@ static int intel_dp_hdmi_sink_max_frl(struct intel_dp
*intel_dp)
{
struct intel_connector *intel_connector = intel_dp->attached_connector;
struct drm_connector *connector = &intel_connector->base;
+ int max_frl_rate;
+ int max_lanes, rate_per_lane;
+ int max_dsc_lanes, dsc_rate_per_lane;
- return (connector->display_info.hdmi.max_frl_rate_per_lane *
- connector->display_info.hdmi.max_lanes);
+ max_lanes = connector->display_info.hdmi.max_lanes;
+ rate_per_lane = connector->display_info.hdmi.max_frl_rate_per_lane;
+ max_frl_rate = max_lanes * rate_per_lane;
+
+ if (connector->display_info.hdmi.dsc_cap.v_1p2) {
+ max_dsc_lanes = connector->display_info.hdmi.dsc_cap.max_lanes;
+ dsc_rate_per_lane =
connector->display_info.hdmi.dsc_cap.max_frl_rate_per_lane;
+ max_frl_rate = min(max_frl_rate, max_dsc_lanes *
dsc_rate_per_lane);
+ }
+
+ return max_frl_rate;
}
static int intel_dp_pcon_start_frl_training(struct intel_dp *intel_dp)
@@ -4171,6 +4183,105 @@ void intel_dp_check_frl_training(struct intel_dp
*intel_dp,
}
}
+static int
+intel_dp_pcon_dsc_enc_slice_height(const struct intel_crtc_state *crtc_state)
+{
+
+ int vactive = crtc_state->hw.adjusted_mode.vdisplay;
+
+ return intel_hdmi_dsc_get_slice_height(vactive);
+}
+
+static int
+intel_dp_pcon_dsc_enc_slices(struct intel_dp *intel_dp,
+const struct intel_crtc_state *crtc_state)
+{
+ struct intel_connector *intel_connector = intel_dp->attached_connector;
+ struct drm_connector *connector = &intel_connector->base;
+ int hdmi_throughput =
connector->display_info.hdmi.dsc_cap.clk_per_slice;
+ int hdmi_max_slices = connector->display_info.hdmi.dsc_cap.max_slices;
+ int pcon_max_slices =
drm_dp_pcon_dsc_max_slices(intel_dp->pcon_dsc_dpcd);
+ int pcon_max_slice_width =
drm_dp_pcon_dsc_max_slice_width(intel_dp->pcon_dsc_dpcd);
+
+
+ return intel_hdmi_dsc_get_num_slices(crtc_state, pcon_max_slices,
+pcon_max_slice_width,
+hdmi_max_slices, hdmi_throughput);
+}
+
+static int
+intel_dp_pcon_dsc_enc_bpp(struct intel_dp *intel_dp,
+ const struct intel_crtc_state *crtc_state,
+ int num_slices, int slice_width)
+{
+ struct intel_connector *intel_connector = intel_dp->attached_connector;
+ struct drm_connector *connector = &intel_connector->base;
+ int output_format = crtc_state->output_format;
+ bool hdmi_all_bpp = connector->display_info.hdmi.dsc_cap.all_bpp;
+ int pcon_fractional_bpp =
drm_dp_pcon_dsc_bpp_incr(intel_dp->pcon_dsc_dpcd);
+ int hdmi_max_chunk_bytes =
+ connector->display_info.hdmi.dsc_cap.total_chunk_kbytes * 1024;
+
+ return intel_hdmi_dsc_get_bpp(pcon_fractional_bpp, slice_width,
+ num_slices, output_format, hdmi_all_bpp,
+ hdmi_max_chunk_bytes);
+}
+
+void
+intel_dp_pcon_dsc_configure(struct intel_dp *intel_dp,
+ const struct intel_crtc_state *crtc_state)
+{
+ u8 pps_param[6];
[PATCH v4 13/16] drm/i915: Add helper functions for calculating DSC parameters for HDMI2.1
The DP-HDMI2.1 PCON spec provides way for a source to set PPS
parameters: slice height, slice width and bits_per_pixel, based on
the HDMI2.1 sink capabilities. The DSC encoder of the PCON will
respect these parameters, while preparing the 128 byte PPS.
This patch adds helper functions to calculate these PPS paremeters as
per the HDMI2.1 specification.
v2: Addressed review comments given by Uma Shankar:
-added documentation for functions
-fixed typos and errors
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_hdmi.c | 233 ++
drivers/gpu/drm/i915/display/intel_hdmi.h | 7 +
2 files changed, 240 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index e10fdb369daa..41eb1c175a0e 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -3428,3 +3428,236 @@ void intel_hdmi_init(struct drm_i915_private *dev_priv,
dig_port->aux_ch = intel_bios_port_aux_ch(dev_priv, port);
intel_hdmi_init_connector(dig_port, intel_connector);
}
+
+/*
+ * intel_hdmi_dsc_get_slice_height - get the dsc slice_height
+ * @vactive: Vactive of a display mode
+ *
+ * @return: appropriate dsc slice height for a given mode.
+ */
+int intel_hdmi_dsc_get_slice_height(int vactive)
+{
+ int slice_height;
+
+ /*
+* Slice Height determination : HDMI2.1 Section 7.7.5.2
+* Select smallest slice height >=96, that results in a valid PPS and
+* requires minimum padding lines required for final slice.
+*
+* Assumption : Vactive is even.
+*/
+ for (slice_height = 96; slice_height <= vactive; slice_height += 2)
+ if (vactive % slice_height == 0)
+ return slice_height;
+
+ return 0;
+}
+
+/*
+ * intel_hdmi_dsc_get_num_slices - get no. of dsc slices based on dsc encoder
+ * and dsc decoder capabilites
+ *
+ * @crtc_state: intel crtc_state
+ * @src_max_slices: maximum slices supported by the DSC encoder
+ * @src_max_slice_width: maximum slice width supported by DSC encoder
+ * @hdmi_max_slices: maximum slices supported by sink DSC decoder
+ * @hdmi_throughput: maximum clock per slice (MHz) supported by HDMI sink
+ *
+ * @return: num of dsc slices that can be supported by the dsc encoder
+ * and decoder.
+ */
+int
+intel_hdmi_dsc_get_num_slices(const struct intel_crtc_state *crtc_state,
+ int src_max_slices, int src_max_slice_width,
+ int hdmi_max_slices, int hdmi_throughput)
+{
+/* Pixel rates in KPixels/sec */
+#define HDMI_DSC_PEAK_PIXEL_RATE 272
+/*
+ * Rates at which the source and sink are required to process pixels in each
+ * slice, can be two levels: either atleast 34KHz or atleast 4KHz.
+ */
+#define HDMI_DSC_MAX_ENC_THROUGHPUT_0 34
+#define HDMI_DSC_MAX_ENC_THROUGHPUT_1 40
+
+/* Spec limits the slice width to 2720 pixels */
+#define MAX_HDMI_SLICE_WIDTH 2720
+ int kslice_adjust;
+ int adjusted_clk_khz;
+ int min_slices;
+ int target_slices;
+ int max_throughput; /* max clock freq. in khz per slice */
+ int max_slice_width;
+ int slice_width;
+ int pixel_clock = crtc_state->hw.adjusted_mode.crtc_clock;
+
+ if (!hdmi_throughput)
+ return 0;
+
+ /*
+* Slice Width determination : HDMI2.1 Section 7.7.5.1
+* kslice_adjust factor for 4:2:0, and 4:2:2 formats is 0.5, where as
+* for 4:4:4 is 1.0. Multiplying these factors by 10 and later
+* dividing adjusted clock value by 10.
+*/
+ if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR444 ||
+ crtc_state->output_format == INTEL_OUTPUT_FORMAT_RGB)
+ kslice_adjust = 10;
+ else
+ kslice_adjust = 5;
+
+ /*
+* As per spec, the rate at which the source and the sink process
+* the pixels per slice are at two levels: atleast 340Mhz or 400Mhz.
+* This depends upon the pixel clock rate and output formats
+* (kslice adjust).
+* If pixel clock * kslice adjust >= 2720MHz slices can be processed
+* at max 340MHz, otherwise they can be processed at max 400MHz.
+*/
+
+ adjusted_clk_khz = DIV_ROUND_UP(kslice_adjust * pixel_clock, 10);
+
+ if (adjusted_clk_khz <= HDMI_DSC_PEAK_PIXEL_RATE)
+ max_throughput = HDMI_DSC_MAX_ENC_THROUGHPUT_0;
+ else
+ max_throughput = HDMI_DSC_MAX_ENC_THROUGHPUT_1;
+
+ /*
+* Taking into account the sink's capability for maximum
+* clock per slice (in MHz) as read from HF-VSDB.
+*/
+ max_throughput = min(max_throughput, hdmi_throughput * 1000);
+
+ min_slices = DIV_ROUND_UP(adjusted_clk_khz, max_throughput);
+ max_slice_width = min(MAX_HDMI_SLICE_WIDTH, src_max_slice_width)
Re: [PATCH] drm/drv: switch to using devm_add_action_or_reset()
Am 07.12.20 um 02:04 schrieb Tian Tao: switch to using devm_add_action_or_reset() instead of devm_add_action. Signed-off-by: Tian Tao I'm surprised that devm_drm_dev_init() didn't already use devm_add_action_or_reset(). But it doesn't look special, so Acked-by: Thomas Zimmermann --- drivers/gpu/drm/drm_drv.c | 7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c index 7343038..b92f7fd 100644 --- a/drivers/gpu/drm/drm_drv.c +++ b/drivers/gpu/drm/drm_drv.c @@ -675,11 +675,8 @@ static int devm_drm_dev_init(struct device *parent, if (ret) return ret; - ret = devm_add_action(parent, devm_drm_dev_init_release, dev); - if (ret) - devm_drm_dev_init_release(dev); - - return ret; + return devm_add_action_or_reset(parent, + devm_drm_dev_init_release, dev); } void *__devm_drm_dev_alloc(struct device *parent, -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer OpenPGP_signature Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 12/16] drm/i915: Read DSC capabilities of the HDMI2.1 PCON encoder
This patch adds support to read and store the DSC capabilities of the
HDMI2.1 PCon encoder. It also adds a new field to store these caps,
The caps are read during dfp update and can later be used to get the
PPS parameters for PCON-HDMI2.1 sink pair. Which inturn will be used
to take a call to override the existing PPS-metadata, by either
writing the entire new PPS metadata, or by writing only the
PPS override parameters.
v2: Restructured the code to read all capability DPCDs at once and store
in an array in intel_dp structure.
v3: rebase
Signed-off-by: Ankit Nautiyal
Reviewed-by: Uma Shankar
---
.../drm/i915/display/intel_display_types.h| 1 +
drivers/gpu/drm/i915/display/intel_dp.c | 20 +++
2 files changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index c624c2f9b624..b41de41759a0 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1362,6 +1362,7 @@ struct intel_dp {
u8 lttpr_common_caps[DP_LTTPR_COMMON_CAP_SIZE];
u8 lttpr_phy_caps[DP_MAX_LTTPR_COUNT][DP_LTTPR_PHY_CAP_SIZE];
u8 fec_capable;
+ u8 pcon_dsc_dpcd[DP_PCON_DSC_ENCODER_CAP_SIZE];
/* source rates */
int num_source_rates;
const int *source_rates;
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 0616779d858e..4dd272a34ee8 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -3984,6 +3984,24 @@ cpt_set_link_train(struct intel_dp *intel_dp,
intel_de_posting_read(dev_priv, intel_dp->output_reg);
}
+static void intel_dp_get_pcon_dsc_cap(struct intel_dp *intel_dp)
+{
+ struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+
+ /* Clear the cached register set to avoid using stale values */
+
+ memset(intel_dp->pcon_dsc_dpcd, 0, sizeof(intel_dp->pcon_dsc_dpcd));
+
+ if (drm_dp_dpcd_read(&intel_dp->aux, DP_PCON_DSC_ENCODER,
+intel_dp->pcon_dsc_dpcd,
+sizeof(intel_dp->pcon_dsc_dpcd)) < 0)
+ drm_err(&i915->drm, "Failed to read DPCD register 0x%x\n",
+ DP_PCON_DSC_ENCODER);
+
+ drm_dbg_kms(&i915->drm, "PCON ENCODER DSC DPCD: %*ph\n",
+ (int)sizeof(intel_dp->pcon_dsc_dpcd),
intel_dp->pcon_dsc_dpcd);
+}
+
static int intel_dp_pcon_get_frl_mask(u8 frl_bw_mask)
{
int bw_gbps[] = {9, 18, 24, 32, 40, 48};
@@ -6757,6 +6775,8 @@ intel_dp_update_dfp(struct intel_dp *intel_dp,
intel_dp->dfp.max_tmds_clock,
intel_dp->dfp.pcon_max_frl_bw,
intel_dp->dfp.sink_max_frl_bw);
+
+ intel_dp_get_pcon_dsc_cap(intel_dp);
}
static void
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 10/16] drm/i915: Check for FRL training before DP Link training
This patch calls functions to check FRL training requirements for an HDMI2.1 sink, when connected through PCON. The call is made before the DP link training. In case FRL is not required or failure during FRL training, the TMDS mode is selected for the pcon. v2: moved check_frl_training() just after FEC READY, before starting DP link training. v3: rebase Signed-off-by: Ankit Nautiyal Reviewed-by: Uma Shankar --- drivers/gpu/drm/i915/display/intel_ddi.c | 2 ++ drivers/gpu/drm/i915/display/intel_dp.c | 2 ++ 2 files changed, 4 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c b/drivers/gpu/drm/i915/display/intel_ddi.c index 6863236df1d0..3ff8b18f1997 100644 --- a/drivers/gpu/drm/i915/display/intel_ddi.c +++ b/drivers/gpu/drm/i915/display/intel_ddi.c @@ -3652,6 +3652,8 @@ static void tgl_ddi_pre_enable_dp(struct intel_atomic_state *state, */ intel_dp_sink_set_fec_ready(intel_dp, crtc_state); + intel_dp_check_frl_training(intel_dp, crtc_state); + /* * 7.i Follow DisplayPort specification training sequence (see notes for * failure handling) diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c index 2aa07d82bc97..f8f82fe8c52a 100644 --- a/drivers/gpu/drm/i915/display/intel_dp.c +++ b/drivers/gpu/drm/i915/display/intel_dp.c @@ -4283,6 +4283,7 @@ static void intel_enable_dp(struct intel_atomic_state *state, intel_dp_set_power(intel_dp, DP_SET_POWER_D0); intel_dp_configure_protocol_converter(intel_dp); + intel_dp_check_frl_training(intel_dp, pipe_config); intel_dp_start_link_train(intel_dp, pipe_config); intel_dp_stop_link_train(intel_dp, pipe_config); @@ -6204,6 +6205,7 @@ int intel_dp_retrain_link(struct intel_encoder *encoder, !intel_dp_mst_is_master_trans(crtc_state)) continue; + intel_dp_check_frl_training(intel_dp, crtc_state); intel_dp_start_link_train(intel_dp, crtc_state); intel_dp_stop_link_train(intel_dp, crtc_state); break; -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 11/16] drm/i915: Add support for enabling link status and recovery
From: Swati Sharma
In this patch enables support for detecting link failures between
PCON and HDMI sink in i915 driver. HDMI link loss indication to
upstream DP source is indicated via IRQ_HPD. This is followed by
reading of HDMI link configuration status (HDMI_TX_LINK_ACTIVE_STATUS).
If the PCON → HDMI 2.1 link status is off; reinitiate frl link
training to recover. Also, report HDMI FRL link error count range for
each individual FRL active lane is indicated by
DOWNSTREAM_HDMI_ERROR_STATUS_LN registers.
v2: Checked for dpcd read and write failures and added debug message.
(Uma Shankar)
v3: rearranged code to re-start FRL link training or fall back to
TMDS mode.
Signed-off-by: Swati Sharma
Signed-off-by: Ankit Nautiyal
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_dp.c | 68 +++--
1 file changed, 65 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index f8f82fe8c52a..0616779d858e 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -6032,6 +6032,43 @@ intel_dp_check_mst_status(struct intel_dp *intel_dp)
return link_ok;
}
+static void
+intel_dp_handle_hdmi_link_status_change(struct intel_dp *intel_dp)
+{
+ bool is_active;
+ u8 buf = 0;
+ struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
+
+ is_active = drm_dp_pcon_hdmi_link_active(&intel_dp->aux);
+ if (intel_dp->frl.is_trained && !is_active) {
+ if (drm_dp_dpcd_readb(&intel_dp->aux,
DP_PCON_HDMI_LINK_CONFIG_1, &buf) < 0)
+ return;
+
+ buf &= ~DP_PCON_ENABLE_HDMI_LINK;
+ if (drm_dp_dpcd_writeb(&intel_dp->aux,
DP_PCON_HDMI_LINK_CONFIG_1, buf) < 0)
+ return;
+
+ drm_dp_pcon_hdmi_frl_link_error_count(&intel_dp->aux,
&intel_dp->attached_connector->base);
+
+ intel_dp->frl.is_trained = false;
+ intel_dp->frl.trained_rate_gbps = 0;
+
+ /* Restart FRL training or fall back to TMDS mode */
+ if (intel_dp_pcon_start_frl_training(intel_dp) < 0) {
+ int ret, mode;
+
+ drm_dbg(&dev_priv->drm, "Couldnt restart FRL,
continuing with TMDS mode\n");
+ ret = drm_dp_pcon_reset_frl_config(&intel_dp->aux);
+ mode = drm_dp_pcon_hdmi_link_mode(&intel_dp->aux, NULL);
+
+ if (ret < 0 || mode != DP_PCON_HDMI_MODE_TMDS)
+ drm_dbg(&dev_priv->drm, "Issue with PCON, cannot set
TMDS mode\n");
+ } else {
+ drm_dbg(&dev_priv->drm, "FRL Re-training Completed\n");
+ }
+ }
+}
+
static bool
intel_dp_needs_link_retrain(struct intel_dp *intel_dp)
{
@@ -6397,7 +6434,7 @@ intel_dp_hotplug(struct intel_encoder *encoder,
return state;
}
-static void intel_dp_check_service_irq(struct intel_dp *intel_dp)
+static void intel_dp_check_device_service_irq(struct intel_dp *intel_dp)
{
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
u8 val;
@@ -6421,6 +6458,30 @@ static void intel_dp_check_service_irq(struct intel_dp
*intel_dp)
drm_dbg_kms(&i915->drm, "Sink specific irq unhandled\n");
}
+static void intel_dp_check_link_service_irq(struct intel_dp *intel_dp)
+{
+ struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+ u8 val;
+
+ if (intel_dp->dpcd[DP_DPCD_REV] < 0x11)
+ return;
+
+ if (drm_dp_dpcd_readb(&intel_dp->aux,
+ DP_LINK_SERVICE_IRQ_VECTOR_ESI0, &val) != 1 ||
!val) {
+ drm_dbg_kms(&i915->drm, "Error in reading link service irq
vector\n");
+ return;
+ }
+
+ if (drm_dp_dpcd_writeb(&intel_dp->aux,
+ DP_LINK_SERVICE_IRQ_VECTOR_ESI0, val) != 1) {
+ drm_dbg_kms(&i915->drm, "Error in writing link service irq
vector\n");
+ return;
+ }
+
+ if (val & HDMI_LINK_STATUS_CHANGED)
+ intel_dp_handle_hdmi_link_status_change(intel_dp);
+}
+
/*
* According to DP spec
* 5.1.2:
@@ -6460,7 +6521,8 @@ intel_dp_short_pulse(struct intel_dp *intel_dp)
return false;
}
- intel_dp_check_service_irq(intel_dp);
+ intel_dp_check_device_service_irq(intel_dp);
+ intel_dp_check_link_service_irq(intel_dp);
/* Handle CEC interrupts, if any */
drm_dp_cec_irq(&intel_dp->aux);
@@ -6894,7 +6956,7 @@ intel_dp_detect(struct drm_connector *connector,
to_intel_connector(connector)->detect_edid)
status = connector_status_connected;
- intel_dp_check_service_irq(intel_dp);
+ intel_dp_check_device_service_irq(intel_dp);
out:
if (status != connector_status_connected && !intel_dp->is_mst)
--
2.17.1
___
[PATCH v4 09/16] drm/i915: Add support for starting FRL training for HDMI2.1 via PCON
This patch adds functions to start FRL training for an HDMI2.1 sink,
connected via a PCON as a DP branch device.
This patch also adds a new structure for storing frl training related
data, when FRL training is completed.
v2: As suggested by Uma Shankar:
-renamed couple of variables for better clarity
-tweaked the macros used for correct semantics for true/false
-fixed other styling issues.
v3: Completed the TODO for condition for going to FRL mode.
Modified the condition to determine the required FRL b/w
based only on the Pcon and Sink's max FRL values.
Moved the frl structure initialization to intel_dp_init_connector().
v4: Fixed typo in initialization of frl structure.
Signed-off-by: Ankit Nautiyal
Reviewed-by: Uma Shankar (v2)
---
.../drm/i915/display/intel_display_types.h| 7 +
drivers/gpu/drm/i915/display/intel_dp.c | 174 ++
drivers/gpu/drm/i915/display/intel_dp.h | 3 +
3 files changed, 184 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index f77a15303223..c624c2f9b624 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1339,6 +1339,11 @@ struct intel_dp_compliance {
u8 test_lane_count;
};
+struct intel_dp_pcon_frl {
+ bool is_trained;
+ int trained_rate_gbps;
+};
+
struct intel_dp {
i915_reg_t output_reg;
u32 DP;
@@ -1461,6 +1466,8 @@ struct intel_dp {
bool hobl_failed;
bool hobl_active;
+
+ struct intel_dp_pcon_frl frl;
};
enum lspcon_vendor {
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 2c3572891596..2aa07d82bc97 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -3887,6 +3887,8 @@ static void intel_disable_dp(struct intel_atomic_state
*state,
intel_edp_backlight_off(old_conn_state);
intel_dp_set_power(intel_dp, DP_SET_POWER_D3);
intel_edp_panel_off(intel_dp);
+ intel_dp->frl.is_trained = false;
+ intel_dp->frl.trained_rate_gbps = 0;
}
static void g4x_disable_dp(struct intel_atomic_state *state,
@@ -3982,6 +3984,175 @@ cpt_set_link_train(struct intel_dp *intel_dp,
intel_de_posting_read(dev_priv, intel_dp->output_reg);
}
+static int intel_dp_pcon_get_frl_mask(u8 frl_bw_mask)
+{
+ int bw_gbps[] = {9, 18, 24, 32, 40, 48};
+ int i;
+
+ for (i = ARRAY_SIZE(bw_gbps) - 1; i >= 0; i--) {
+ if (frl_bw_mask & (1 << i))
+ return bw_gbps[i];
+ }
+ return 0;
+}
+
+static int intel_dp_pcon_set_frl_mask(int max_frl)
+{
+
+ switch (max_frl) {
+ case 48:
+ return DP_PCON_FRL_BW_MASK_48GBPS;
+ case 40:
+ return DP_PCON_FRL_BW_MASK_40GBPS;
+ case 32:
+ return DP_PCON_FRL_BW_MASK_32GBPS;
+ case 24:
+ return DP_PCON_FRL_BW_MASK_24GBPS;
+ case 18:
+ return DP_PCON_FRL_BW_MASK_18GBPS;
+ case 9:
+ return DP_PCON_FRL_BW_MASK_9GBPS;
+ }
+
+ return 0;
+}
+
+static int intel_dp_hdmi_sink_max_frl(struct intel_dp *intel_dp)
+{
+ struct intel_connector *intel_connector = intel_dp->attached_connector;
+ struct drm_connector *connector = &intel_connector->base;
+
+ return (connector->display_info.hdmi.max_frl_rate_per_lane *
+ connector->display_info.hdmi.max_lanes);
+}
+
+static int intel_dp_pcon_start_frl_training(struct intel_dp *intel_dp)
+{
+#define PCON_EXTENDED_TRAIN_MODE (1 > 0)
+#define PCON_CONCURRENT_MODE (1 > 0)
+#define PCON_SEQUENTIAL_MODE !PCON_CONCURRENT_MODE
+#define PCON_NORMAL_TRAIN_MODE !PCON_EXTENDED_TRAIN_MODE
+#define TIMEOUT_FRL_READY_MS 500
+#define TIMEOUT_HDMI_LINK_ACTIVE_MS 1000
+
+ struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+ int max_frl_bw, max_pcon_frl_bw, max_edid_frl_bw, ret;
+ u8 max_frl_bw_mask = 0, frl_trained_mask;
+ bool is_active;
+
+ ret = drm_dp_pcon_reset_frl_config(&intel_dp->aux);
+ if (ret < 0)
+ return ret;
+
+ max_pcon_frl_bw = intel_dp->dfp.pcon_max_frl_bw;
+ drm_dbg(&i915->drm, "PCON max rate = %d Gbps\n", max_pcon_frl_bw);
+
+ max_edid_frl_bw = intel_dp_hdmi_sink_max_frl(intel_dp);
+ drm_dbg(&i915->drm, "Sink max rate from EDID = %d Gbps\n",
max_edid_frl_bw);
+
+ max_frl_bw = min(max_edid_frl_bw, max_pcon_frl_bw);
+
+ if (max_frl_bw <= 0)
+ return -EINVAL;
+
+ ret = drm_dp_pcon_frl_prepare(&intel_dp->aux, false);
+ if (ret < 0)
+ return ret;
+ /* Wait for PCON to be FRL Ready */
+ wait_for(is_active = drm_dp_pcon_is_frl_ready(&intel_dp->aux) == true,
TIMEOUT_FRL_READY_MS);
+
+ if (!is_active)
+ return -ETIMEDOUT;
+
+ max_frl_bw_mask = intel_dp_pcon_set_
[PATCH v4 08/16] drm/i915: Capture max frl rate for PCON in dfp cap structure
HDMI2.1 PCON advertises Max FRL bandwidth supported by the PCON and
by the sink.
This patch captures these in dfp cap structure in intel_dp and uses
these to prune connector modes that cannot be supported by the PCON
and sink FRL bandwidth.
v2: Addressed review comments from Uma Shankar:
-tweaked the comparison of target bw and pcon frl bw to avoid roundup errors.
-minor modification of field names and comments.
Signed-off-by: Ankit Nautiyal
Reviewed-by: Uma Shankar
---
.../drm/i915/display/intel_display_types.h| 1 +
drivers/gpu/drm/i915/display/intel_dp.c | 38 ++-
2 files changed, 37 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 5bc5bfbc4551..f77a15303223 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1451,6 +1451,7 @@ struct intel_dp {
struct {
int min_tmds_clock, max_tmds_clock;
int max_dotclock;
+ int pcon_max_frl_bw, sink_max_frl_bw;
u8 max_bpc;
bool ycbcr_444_to_420;
} dfp;
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index cb5e42c3ecd5..2c3572891596 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -716,6 +716,29 @@ intel_dp_mode_valid_downstream(struct intel_connector
*connector,
const struct drm_display_info *info = &connector->base.display_info;
int tmds_clock;
+ /*
+* If PCON and HDMI2.1 sink both support FRL MODE, check FRL
+* bandwidth constraints.
+*/
+ if (intel_dp->dfp.pcon_max_frl_bw) {
+ int target_bw;
+ int max_frl_bw;
+ int bpp = intel_dp_mode_min_output_bpp(&connector->base, mode);
+
+ target_bw = bpp * target_clock;
+
+ max_frl_bw = min(intel_dp->dfp.pcon_max_frl_bw,
+intel_dp->dfp.sink_max_frl_bw);
+
+ /* converting bw from Gbps to Kbps*/
+ max_frl_bw = max_frl_bw * 100;
+
+ if (target_bw > max_frl_bw)
+ return MODE_CLOCK_HIGH;
+
+ return MODE_OK;
+ }
+
if (intel_dp->dfp.max_dotclock &&
target_clock > intel_dp->dfp.max_dotclock)
return MODE_CLOCK_HIGH;
@@ -6484,13 +6507,21 @@ intel_dp_update_dfp(struct intel_dp *intel_dp,
intel_dp->downstream_ports,
edid);
+ intel_dp->dfp.pcon_max_frl_bw =
+ drm_dp_get_pcon_max_frl_bw(intel_dp->dpcd,
+ intel_dp->downstream_ports);
+
+ intel_dp->dfp.sink_max_frl_bw =
drm_dp_get_hdmi_sink_max_frl_bw(&intel_dp->aux);
+
drm_dbg_kms(&i915->drm,
- "[CONNECTOR:%d:%s] DFP max bpc %d, max dotclock %d, TMDS
clock %d-%d\n",
+ "[CONNECTOR:%d:%s] DFP max bpc %d, max dotclock %d, TMDS
clock %d-%d, PCON Max FRL BW %dGbps, Sink Max FRL BW %dGbps\n",
connector->base.base.id, connector->base.name,
intel_dp->dfp.max_bpc,
intel_dp->dfp.max_dotclock,
intel_dp->dfp.min_tmds_clock,
- intel_dp->dfp.max_tmds_clock);
+ intel_dp->dfp.max_tmds_clock,
+ intel_dp->dfp.pcon_max_frl_bw,
+ intel_dp->dfp.sink_max_frl_bw);
}
static void
@@ -6582,6 +6613,9 @@ intel_dp_unset_edid(struct intel_dp *intel_dp)
intel_dp->dfp.min_tmds_clock = 0;
intel_dp->dfp.max_tmds_clock = 0;
+ intel_dp->dfp.pcon_max_frl_bw = 0;
+ intel_dp->dfp.sink_max_frl_bw = 0;
+
intel_dp->dfp.ycbcr_444_to_420 = false;
connector->base.ycbcr_420_allowed = false;
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 07/16] drm/dp_helper: Add helpers to configure PCONs RGB-YCbCr Conversion
DP Specification for DP2.0 to HDMI2.1 Pcon specifies support for conversion
of colorspace from RGB to YCbCr.
https://groups.vesa.org/wg/DP/document/previewpdf/15651
This patch adds the relavant registers and helper functions to
get the capability and set the color conversion bits for rgb->ycbcr
conversion through PCON.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/drm_dp_helper.c | 59 +
include/drm/drm_dp_helper.h | 10 +-
2 files changed, 68 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index d0626f57f99c..344662d5c295 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -949,6 +949,35 @@ bool drm_dp_downstream_444_to_420_conversion(const u8
dpcd[DP_RECEIVER_CAP_SIZE]
}
EXPORT_SYMBOL(drm_dp_downstream_444_to_420_conversion);
+/**
+ * drm_dp_downstream_rgb_to_ycbcr_conversion() - determine downstream facing
port
+ * RGB->YCbCr conversion
capability
+ * @dpcd: DisplayPort configuration data
+ * @port_cap: downstream facing port capabilities
+ *
+ * Returns: whether the downstream facing port can convert RGB->YCbCr
+ */
+bool drm_dp_downstream_rgb_to_ycbcr_conversion(const u8
dpcd[DP_RECEIVER_CAP_SIZE],
+ const u8 port_cap[4])
+{
+ if (!drm_dp_is_branch(dpcd))
+ return false;
+
+ if (dpcd[DP_DPCD_REV] < 0x13)
+ return false;
+
+ switch (port_cap[0] & DP_DS_PORT_TYPE_MASK) {
+ case DP_DS_PORT_TYPE_HDMI:
+ if ((dpcd[DP_DOWNSTREAMPORT_PRESENT] &
DP_DETAILED_CAP_INFO_AVAILABLE) == 0)
+ return false;
+
+ return port_cap[3] & DP_DS_HDMI_BT601_RGB_YCBCR_CONV;
+ default:
+ return false;
+ }
+}
+EXPORT_SYMBOL(drm_dp_downstream_rgb_to_ycbcr_conversion);
+
/**
* drm_dp_downstream_mode() - return a mode for downstream facing port
* @dev: DRM device
@@ -3140,3 +3169,33 @@ int drm_dp_pcon_pps_override_param(struct drm_dp_aux
*aux, u8 pps_param[6])
return 0;
}
EXPORT_SYMBOL(drm_dp_pcon_pps_override_param);
+
+/*
+ * drm_dp_pcon_convert_rgb_to_ycbcr() - Configure the PCon to convert RGB to
Ycbcr
+ * @aux: displayPort AUX channel
+ * @color_spc: Color space conversion type
+ *
+ * Returns 0 on success, else returns negative error code.
+ */
+int drm_dp_pcon_convert_rgb_to_ycbcr(struct drm_dp_aux *aux, u8 color_spc)
+{
+ int ret;
+ u8 buf;
+
+ if (color_spc != DP_CONVERSION_BT601_RGB_YCBCR_ENABLE ||
+ color_spc != DP_CONVERSION_BT709_RGB_YCBCR_ENABLE ||
+ color_spc != DP_CONVERSION_BT2020_RGB_YCBCR_ENABLE)
+ return -EINVAL;
+
+ ret = drm_dp_dpcd_readb(aux, DP_PROTOCOL_CONVERTER_CONTROL_2, &buf);
+ if (ret < 0)
+ return ret;
+
+ buf |= color_spc;
+ ret = drm_dp_dpcd_writeb(aux, DP_PROTOCOL_CONVERTER_CONTROL_2, buf);
+ if (ret < 0)
+ return ret;
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_dp_pcon_convert_rgb_to_ycbcr);
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 347b4e1a55b4..1b3d54ed7a78 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -431,6 +431,9 @@ struct drm_device;
# define DP_DS_HDMI_YCBCR420_PASS_THROUGH (1 << 2)
# define DP_DS_HDMI_YCBCR444_TO_422_CONV(1 << 3)
# define DP_DS_HDMI_YCBCR444_TO_420_CONV(1 << 4)
+# define DP_DS_HDMI_BT601_RGB_YCBCR_CONV(1 << 5)
+# define DP_DS_HDMI_BT709_RGB_YCBCR_CONV(1 << 6)
+# define DP_DS_HDMI_BT2020_RGB_YCBCR_CONV (1 << 7)
#define DP_MAX_DOWNSTREAM_PORTS0x10
@@ -1217,7 +1220,9 @@ struct drm_device;
# define DP_PCON_ENC_PPS_OVERRIDE_DISABLED 0
# define DP_PCON_ENC_PPS_OVERRIDE_EN_PARAMS 1
# define DP_PCON_ENC_PPS_OVERRIDE_EN_BUFFER 2
-
+# define DP_CONVERSION_BT601_RGB_YCBCR_ENABLE (1 << 4)
+# define DP_CONVERSION_BT709_RGB_YCBCR_ENABLE (1 << 5)
+# define DP_CONVERSION_BT2020_RGB_YCBCR_ENABLE (1 << 6)
/* PCON Downstream HDMI ERROR Status per Lane */
#define DP_PCON_HDMI_ERROR_STATUS_LN0 0x3037
@@ -2178,5 +2183,8 @@ int drm_dp_pcon_dsc_bpp_incr(const u8
pcon_dsc_dpcd[DP_PCON_DSC_ENCODER_CAP_SIZE
int drm_dp_pcon_pps_default(struct drm_dp_aux *aux);
int drm_dp_pcon_pps_override_buf(struct drm_dp_aux *aux, u8 pps_buf[128]);
int drm_dp_pcon_pps_override_param(struct drm_dp_aux *aux, u8 pps_param[6]);
+bool drm_dp_downstream_rgb_to_ycbcr_conversion(const u8
dpcd[DP_RECEIVER_CAP_SIZE],
+ const u8 port_cap[4]);
+int drm_dp_pcon_convert_rgb_to_ycbcr(struct drm_dp_aux *aux, u8 color_spc);
#endif /* _DRM_DP_HELPER_H_ */
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 06/16] drm/dp_helper: Add support for Configuring DSC for HDMI2.1 Pcon
This patch adds registers for getting DSC encoder capability for
a HDMI2.1 PCon. It also addes helper functions to configure
DSC between the PCON and HDMI2.1 sink.
v2: Corrected offset for DSC encoder bpc and minor changes.
Also added helper functions for getting pcon dsc encoder capabilities
as suggested by Uma Shankar.
v3: Only setting the DSC bits for the Protocol Convertor control
registers, avoiding overwritining color conversion bits.
Signed-off-by: Ankit Nautiyal
Reviewed-by: Uma Shankar (v2)
---
drivers/gpu/drm/drm_dp_helper.c | 203
include/drm/drm_dp_helper.h | 114 ++
2 files changed, 317 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 5a9303de9ac2..d0626f57f99c 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -2937,3 +2937,206 @@ void drm_dp_pcon_hdmi_frl_link_error_count(struct
drm_dp_aux *aux,
}
}
EXPORT_SYMBOL(drm_dp_pcon_hdmi_frl_link_error_count);
+
+/*
+ * drm_dp_pcon_enc_is_dsc_1_2 - Does PCON Encoder supports DSC 1.2
+ * @pcon_dsc_dpcd: DSC capabilities of the PCON DSC Encoder
+ *
+ * Returns true is PCON encoder is DSC 1.2 else returns false.
+ */
+bool drm_dp_pcon_enc_is_dsc_1_2(const u8
pcon_dsc_dpcd[DP_PCON_DSC_ENCODER_CAP_SIZE])
+{
+ u8 buf;
+ u8 major_v, minor_v;
+
+ buf = pcon_dsc_dpcd[DP_PCON_DSC_VERSION - DP_PCON_DSC_ENCODER];
+ major_v = (buf & DP_PCON_DSC_MAJOR_MASK) >> DP_PCON_DSC_MAJOR_SHIFT;
+ minor_v = (buf & DP_PCON_DSC_MINOR_MASK) >> DP_PCON_DSC_MINOR_SHIFT;
+
+ if (major_v == 1 && minor_v == 2)
+ return true;
+
+ return false;
+}
+EXPORT_SYMBOL(drm_dp_pcon_enc_is_dsc_1_2);
+
+/*
+ * drm_dp_pcon_dsc_max_slices - Get max slices supported by PCON DSC Encoder
+ * @pcon_dsc_dpcd: DSC capabilities of the PCON DSC Encoder
+ *
+ * Returns maximum no. of slices supported by the PCON DSC Encoder.
+ */
+int drm_dp_pcon_dsc_max_slices(const u8
pcon_dsc_dpcd[DP_PCON_DSC_ENCODER_CAP_SIZE])
+{
+ u8 slice_cap1, slice_cap2;
+
+ slice_cap1 = pcon_dsc_dpcd[DP_PCON_DSC_SLICE_CAP_1 -
DP_PCON_DSC_ENCODER];
+ slice_cap2 = pcon_dsc_dpcd[DP_PCON_DSC_SLICE_CAP_2 -
DP_PCON_DSC_ENCODER];
+
+ if (slice_cap2 & DP_PCON_DSC_24_PER_DSC_ENC)
+ return 24;
+ if (slice_cap2 & DP_PCON_DSC_20_PER_DSC_ENC)
+ return 20;
+ if (slice_cap2 & DP_PCON_DSC_16_PER_DSC_ENC)
+ return 16;
+ if (slice_cap1 & DP_PCON_DSC_12_PER_DSC_ENC)
+ return 12;
+ if (slice_cap1 & DP_PCON_DSC_10_PER_DSC_ENC)
+ return 10;
+ if (slice_cap1 & DP_PCON_DSC_8_PER_DSC_ENC)
+ return 8;
+ if (slice_cap1 & DP_PCON_DSC_6_PER_DSC_ENC)
+ return 6;
+ if (slice_cap1 & DP_PCON_DSC_4_PER_DSC_ENC)
+ return 4;
+ if (slice_cap1 & DP_PCON_DSC_2_PER_DSC_ENC)
+ return 2;
+ if (slice_cap1 & DP_PCON_DSC_1_PER_DSC_ENC)
+ return 1;
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_dp_pcon_dsc_max_slices);
+
+/*
+ * drm_dp_pcon_dsc_max_slice_width() - Get max slice width for Pcon DSC encoder
+ * @pcon_dsc_dpcd: DSC capabilities of the PCON DSC Encoder
+ *
+ * Returns maximum width of the slices in pixel width i.e. no. of pixels x 320.
+ */
+int drm_dp_pcon_dsc_max_slice_width(const u8
pcon_dsc_dpcd[DP_PCON_DSC_ENCODER_CAP_SIZE])
+{
+ u8 buf;
+
+ buf = pcon_dsc_dpcd[DP_PCON_DSC_MAX_SLICE_WIDTH - DP_PCON_DSC_ENCODER];
+
+ return buf * DP_DSC_SLICE_WIDTH_MULTIPLIER;
+}
+EXPORT_SYMBOL(drm_dp_pcon_dsc_max_slice_width);
+
+/*
+ * drm_dp_pcon_dsc_bpp_incr() - Get bits per pixel increment for PCON DSC
encoder
+ * @pcon_dsc_dpcd: DSC capabilities of the PCON DSC Encoder
+ *
+ * Returns the bpp precision supported by the PCON encoder.
+ */
+int drm_dp_pcon_dsc_bpp_incr(const u8
pcon_dsc_dpcd[DP_PCON_DSC_ENCODER_CAP_SIZE])
+{
+ u8 buf;
+
+ buf = pcon_dsc_dpcd[DP_PCON_DSC_BPP_INCR - DP_PCON_DSC_ENCODER];
+
+ switch (buf & DP_PCON_DSC_BPP_INCR_MASK) {
+ case DP_PCON_DSC_ONE_16TH_BPP:
+ return 16;
+ case DP_PCON_DSC_ONE_8TH_BPP:
+ return 8;
+ case DP_PCON_DSC_ONE_4TH_BPP:
+ return 4;
+ case DP_PCON_DSC_ONE_HALF_BPP:
+ return 2;
+ case DP_PCON_DSC_ONE_BPP:
+ return 1;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_dp_pcon_dsc_bpp_incr);
+
+static
+int drm_dp_pcon_configure_dsc_enc(struct drm_dp_aux *aux, u8 pps_buf_config)
+{
+ u8 buf;
+ int ret;
+
+ ret = drm_dp_dpcd_readb(aux, DP_PROTOCOL_CONVERTER_CONTROL_2, &buf);
+ if (ret < 0)
+ return ret;
+
+ buf |= DP_PCON_ENABLE_DSC_ENCODER;
+
+ if (pps_buf_config <= DP_PCON_ENC_PPS_OVERRIDE_EN_BUFFER) {
+ buf &= ~DP_PCON_ENCODER_PPS_OVERRIDE_MASK;
+ buf |= pps_buf_config << 2;
+ }
+
+
[PATCH v4 05/16] drm/dp_helper: Add support for link failure detection
From: Swati Sharma
There are specific DPCDs defined for detecting link failures between
the PCON and HDMI sink and check the link status. In case of link
failure, PCON will communicate the same using an IRQ_HPD to source.
HDMI sink would have indicated the same to PCON using SCDC interrupt
mechanism. While source can always read final HDMI sink's status using
I2C over AUX, it is easier and faster to read the PCONs already read
HDMI sink status registers.
This patch adds the DPCDs required for link failure detection and
provide a helper function for printing error count/lane which might
help in debugging the link failure issues.
v2: Addressed comments from Uma Shankar:
-rephrased the commit message, as per the code.
-fixed styling issues
-added documentation for the helper function.
Signed-off-by: Swati Sharma
Signed-off-by: Ankit Nautiyal
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/drm_dp_helper.c | 39 +
include/drm/drm_dp_helper.h | 17 ++
2 files changed, 56 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 0aba865ff6be..5a9303de9ac2 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -2898,3 +2898,42 @@ int drm_dp_pcon_hdmi_link_mode(struct drm_dp_aux *aux,
u8 *frl_trained_mask)
return mode;
}
EXPORT_SYMBOL(drm_dp_pcon_hdmi_link_mode);
+
+/**
+ * drm_dp_pcon_hdmi_frl_link_error_count() - print the error count per lane
+ * during link failure between PCON and HDMI sink
+ * @aux: DisplayPort AUX channel
+ * @connector: DRM connector
+ * code.
+ **/
+
+void drm_dp_pcon_hdmi_frl_link_error_count(struct drm_dp_aux *aux,
+ struct drm_connector *connector)
+{
+ u8 buf, error_count;
+ int i, num_error;
+ struct drm_hdmi_info *hdmi = &connector->display_info.hdmi;
+
+ for (i = 0; i < hdmi->max_lanes; i++) {
+ if (drm_dp_dpcd_readb(aux, DP_PCON_HDMI_ERROR_STATUS_LN0 + i,
&buf) < 0)
+ return;
+
+ error_count = buf & DP_PCON_HDMI_ERROR_COUNT_MASK;
+ switch (error_count) {
+ case DP_PCON_HDMI_ERROR_COUNT_HUNDRED_PLUS:
+ num_error = 100;
+ break;
+ case DP_PCON_HDMI_ERROR_COUNT_TEN_PLUS:
+ num_error = 10;
+ break;
+ case DP_PCON_HDMI_ERROR_COUNT_THREE_PLUS:
+ num_error = 3;
+ break;
+ default:
+ num_error = 0;
+ }
+
+ DRM_ERROR("More than %d errors since the last read for lane
%d", num_error, i);
+ }
+}
+EXPORT_SYMBOL(drm_dp_pcon_hdmi_frl_link_error_count);
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 6afd314a33b8..ab6b7e4fb9ff 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -946,6 +946,11 @@ struct drm_device;
# define DP_CEC_IRQ (1 << 2)
#define DP_LINK_SERVICE_IRQ_VECTOR_ESI0 0x2005 /* 1.2 */
+# define RX_CAP_CHANGED (1 << 0)
+# define LINK_STATUS_CHANGED (1 << 1)
+# define STREAM_STATUS_CHANGED (1 << 2)
+# define HDMI_LINK_STATUS_CHANGED(1 << 3)
+# define CONNECTED_OFF_ENTRY_REQUESTED (1 << 4)
#define DP_PSR_ERROR_STATUS 0x2006 /* XXX 1.2? */
# define DP_PSR_LINK_CRC_ERROR (1 << 0)
@@ -1130,6 +1135,16 @@ struct drm_device;
#define DP_PROTOCOL_CONVERTER_CONTROL_20x3052 /* DP 1.3 */
# define DP_CONVERSION_TO_YCBCR422_ENABLE (1 << 0) /* DP 1.3 */
+/* PCON Downstream HDMI ERROR Status per Lane */
+#define DP_PCON_HDMI_ERROR_STATUS_LN0 0x3037
+#define DP_PCON_HDMI_ERROR_STATUS_LN1 0x3038
+#define DP_PCON_HDMI_ERROR_STATUS_LN2 0x3039
+#define DP_PCON_HDMI_ERROR_STATUS_LN3 0x303A
+# define DP_PCON_HDMI_ERROR_COUNT_MASK (0x7 << 0)
+# define DP_PCON_HDMI_ERROR_COUNT_THREE_PLUS (1 << 0)
+# define DP_PCON_HDMI_ERROR_COUNT_TEN_PLUS (1 << 1)
+# define DP_PCON_HDMI_ERROR_COUNT_HUNDRED_PLUS (1 << 2)
+
/* HDCP 1.3 and HDCP 2.2 */
#define DP_AUX_HDCP_BKSV 0x68000
#define DP_AUX_HDCP_RI_PRIME 0x68005
@@ -2047,5 +2062,7 @@ int drm_dp_pcon_frl_enable(struct drm_dp_aux *aux);
bool drm_dp_pcon_hdmi_link_active(struct drm_dp_aux *aux);
int drm_dp_pcon_hdmi_link_mode(struct drm_dp_aux *aux, u8 *frl_trained_mask);
+void drm_dp_pcon_hdmi_frl_link_error_count(struct drm_dp_aux *aux,
+ struct drm_connector *connector);
#endif /* _DRM_DP_HELPER_H_ */
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 04/16] drm/dp_helper: Add Helpers for FRL Link Training support for DP-HDMI2.1 PCON
This patch adds support for configuring a PCON device,
connected as a DP branched device to enable FRL Link training
with a HDMI2.1 + sink.
v2: Fixed typos and addressed other review comments from Uma Shankar.
-changed the commit message for better clarity (Uma Shankar)
-removed unnecessary argument supplied to a drm helper function.
-fixed return value for max frl read from pcon.
Signed-off-by: Ankit Nautiyal
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/drm_dp_helper.c | 302
include/drm/drm_dp_helper.h | 81 +
2 files changed, 383 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 5bd0934004e3..0aba865ff6be 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -2596,3 +2596,305 @@ void drm_dp_vsc_sdp_log(const char *level, struct
device *dev,
#undef DP_SDP_LOG
}
EXPORT_SYMBOL(drm_dp_vsc_sdp_log);
+
+/**
+ * drm_dp_get_pcon_max_frl_bw() - maximum frl supported by PCON
+ * @dpcd: DisplayPort configuration data
+ * @port_cap: port capabilities
+ *
+ * Returns maximum frl bandwidth supported by PCON in GBPS,
+ * returns 0 if not supported.
+ **/
+int drm_dp_get_pcon_max_frl_bw(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
+ const u8 port_cap[4])
+{
+ int bw;
+ u8 buf;
+
+ buf = port_cap[2];
+ bw = buf & DP_PCON_MAX_FRL_BW;
+
+ switch (bw) {
+ case DP_PCON_MAX_9GBPS:
+ return 9;
+ case DP_PCON_MAX_18GBPS:
+ return 18;
+ case DP_PCON_MAX_24GBPS:
+ return 24;
+ case DP_PCON_MAX_32GBPS:
+ return 32;
+ case DP_PCON_MAX_40GBPS:
+ return 40;
+ case DP_PCON_MAX_48GBPS:
+ return 48;
+ case DP_PCON_MAX_0GBPS:
+ default:
+ return 0;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_dp_get_pcon_max_frl_bw);
+
+/**
+ * drm_dp_get_hdmi_sink_max_frl_bw() - maximum frl supported by HDMI Sink
+ * @aux: DisplayPort AUX channel
+ *
+ * Returns maximum frl bandwidth supported by HDMI in Gbps on success,
+ * returns 0, if not supported.
+ **/
+int drm_dp_get_hdmi_sink_max_frl_bw(struct drm_dp_aux *aux)
+{
+ u8 buf;
+ int bw, ret;
+
+ ret = drm_dp_dpcd_readb(aux, DP_PCON_HDMI_SINK, &buf);
+ if (ret < 0)
+ return 0;
+ bw = buf & DP_HDMI_SINK_LINK_BW;
+
+ switch (bw) {
+ case DP_HDMI_SINK_BW_9GBPS:
+ return 9;
+ case DP_HDMI_SINK_BW_18GBPS:
+ return 18;
+ case DP_HDMI_SINK_BW_24GBPS:
+ return 24;
+ case DP_HDMI_SINK_BW_32GBPS:
+ return 32;
+ case DP_HDMI_SINK_BW_40GBPS:
+ return 40;
+ case DP_HDMI_SINK_BW_48GBPS:
+ return 48;
+ case DP_HDMI_SINK_BW_0GBPS:
+ default:
+ return 0;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_dp_get_hdmi_sink_max_frl_bw);
+
+/**
+ * drm_dp_pcon_frl_prepare() - Prepare PCON for FRL.
+ * @aux: DisplayPort AUX channel
+ *
+ * Returns 0 if success, else returns negative error code.
+ **/
+int drm_dp_pcon_frl_prepare(struct drm_dp_aux *aux, bool enable_frl_ready_hpd)
+{
+ int ret;
+ u8 buf = DP_PCON_ENABLE_SOURCE_CTL_MODE |
+DP_PCON_ENABLE_LINK_FRL_MODE;
+
+ if (enable_frl_ready_hpd)
+ buf |= DP_PCON_ENABLE_HPD_READY;
+
+ ret = drm_dp_dpcd_writeb(aux, DP_PCON_HDMI_LINK_CONFIG_1, buf);
+
+ return ret;
+}
+EXPORT_SYMBOL(drm_dp_pcon_frl_prepare);
+
+/**
+ * drm_dp_pcon_is_frl_ready() - Is PCON ready for FRL
+ * @aux: DisplayPort AUX channel
+ *
+ * Returns true if success, else returns false.
+ **/
+bool drm_dp_pcon_is_frl_ready(struct drm_dp_aux *aux)
+{
+ int ret;
+ u8 buf;
+
+ ret = drm_dp_dpcd_readb(aux, DP_PCON_HDMI_TX_LINK_STATUS, &buf);
+ if (ret < 0)
+ return false;
+
+ if (buf & DP_PCON_FRL_READY)
+ return true;
+
+ return false;
+}
+EXPORT_SYMBOL(drm_dp_pcon_is_frl_ready);
+
+/**
+ * drm_dp_pcon_frl_configure_1() - Set HDMI LINK Configuration-Step1
+ * @aux: DisplayPort AUX channel
+ * @max_frl_gbps: maximum frl bw to be configured between PCON and HDMI sink
+ * @concurrent_mode: true if concurrent mode or operation is required,
+ * false otherwise.
+ *
+ * Returns 0 if success, else returns negative error code.
+ **/
+
+int drm_dp_pcon_frl_configure_1(struct drm_dp_aux *aux, int max_frl_gbps,
+ bool concurrent_mode)
+{
+ int ret;
+ u8 buf;
+
+ ret = drm_dp_dpcd_readb(aux, DP_PCON_HDMI_LINK_CONFIG_1, &buf);
+ if (ret < 0)
+ return ret;
+
+ if (concurrent_mode)
+ buf |= DP_PCON_ENABLE_CONCURRENT_LINK;
+ else
+ buf &= ~DP_PCON_ENABLE_CONCURRENT_LINK;
+
+ switch (max_frl_gbps) {
+ case 9:
+ buf |= DP_PCON_ENABLE_MAX_BW_9GB
[PATCH v4 03/16] drm/edid: Parse DSC1.2 cap fields from HFVSDB block
This patch parses HFVSDB fields for DSC1.2 capabilities of an
HDMI2.1 sink. These fields are required by a source to understand the
DSC capability of the sink, to set appropriate PPS parameters,
before transmitting compressed data stream.
v2: Addressed following issues as suggested by Uma Shankar:
-Added a new struct for hdmi dsc cap
-Fixed bugs in macros usage.
Signed-off-by: Ankit Nautiyal
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/drm_edid.c | 59 +
include/drm/drm_connector.h | 43 +++
2 files changed, 102 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index e657c321d9e4..ca368df2e5ac 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4941,11 +4941,70 @@ static void drm_parse_hdmi_forum_vsdb(struct
drm_connector *connector,
if (hf_vsdb[7]) {
u8 max_frl_rate;
+ u8 dsc_max_frl_rate;
+ u8 dsc_max_slices;
+ struct drm_hdmi_dsc_cap *hdmi_dsc = &hdmi->dsc_cap;
DRM_DEBUG_KMS("hdmi_21 sink detected. parsing edid\n");
max_frl_rate = (hf_vsdb[7] & DRM_EDID_MAX_FRL_RATE_MASK) >> 4;
drm_get_max_frl_rate(max_frl_rate, &hdmi->max_lanes,
&hdmi->max_frl_rate_per_lane);
+ hdmi_dsc->v_1p2 = hf_vsdb[11] & DRM_EDID_DSC_1P2;
+
+ if (hdmi_dsc->v_1p2) {
+ hdmi_dsc->native_420 = hf_vsdb[11] &
DRM_EDID_DSC_NATIVE_420;
+ hdmi_dsc->all_bpp = hf_vsdb[11] & DRM_EDID_DSC_ALL_BPP;
+
+ if (hf_vsdb[11] & DRM_EDID_DSC_16BPC)
+ hdmi_dsc->bpc_supported = 16;
+ else if (hf_vsdb[11] & DRM_EDID_DSC_12BPC)
+ hdmi_dsc->bpc_supported = 12;
+ else if (hf_vsdb[11] & DRM_EDID_DSC_10BPC)
+ hdmi_dsc->bpc_supported = 10;
+ else
+ hdmi_dsc->bpc_supported = 0;
+
+ dsc_max_frl_rate = (hf_vsdb[12] &
DRM_EDID_DSC_MAX_FRL_RATE_MASK) >> 4;
+ drm_get_max_frl_rate(dsc_max_frl_rate,
&hdmi_dsc->max_lanes,
+ &hdmi_dsc->max_frl_rate_per_lane);
+ hdmi_dsc->total_chunk_kbytes = hf_vsdb[13] &
DRM_EDID_DSC_TOTAL_CHUNK_KBYTES;
+
+ dsc_max_slices = hf_vsdb[12] & DRM_EDID_DSC_MAX_SLICES;
+ switch (dsc_max_slices) {
+ case 1:
+ hdmi_dsc->max_slices = 1;
+ hdmi_dsc->clk_per_slice = 340;
+ break;
+ case 2:
+ hdmi_dsc->max_slices = 2;
+ hdmi_dsc->clk_per_slice = 340;
+ break;
+ case 3:
+ hdmi_dsc->max_slices = 4;
+ hdmi_dsc->clk_per_slice = 340;
+ break;
+ case 4:
+ hdmi_dsc->max_slices = 8;
+ hdmi_dsc->clk_per_slice = 340;
+ break;
+ case 5:
+ hdmi_dsc->max_slices = 8;
+ hdmi_dsc->clk_per_slice = 400;
+ break;
+ case 6:
+ hdmi_dsc->max_slices = 12;
+ hdmi_dsc->clk_per_slice = 400;
+ break;
+ case 7:
+ hdmi_dsc->max_slices = 16;
+ hdmi_dsc->clk_per_slice = 400;
+ break;
+ case 0:
+ default:
+ hdmi_dsc->max_slices = 0;
+ hdmi_dsc->clk_per_slice = 0;
+ }
+ }
}
drm_parse_ycbcr420_deep_color_info(connector, hf_vsdb);
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 1a3b4776b458..1922b278ffad 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -175,6 +175,46 @@ struct drm_scdc {
struct drm_scrambling scrambling;
};
+/**
+ * struct drm_hdmi_dsc_cap - DSC capabilities of HDMI sink
+ *
+ * Describes the DSC support provided by HDMI 2.1 sink.
+ * The information is fetched fom additional HFVSDB blocks defined
+ * for HDMI 2.1.
+ */
+struct drm_hdmi_dsc_cap {
+ /** @v_1p2: flag for dsc1.2 version support by sink */
+ bool v_1p2;
+
+ /** @native_420: Does sink support DSC with 4:2:0 compression */
+ bool native_420;
+
+ /**
+* @all_bpp: Does sink support all
[PATCH v4 02/16] drm/edid: Parse MAX_FRL field from HFVSDB block
From: Swati Sharma
This patch parses MAX_FRL field to get the MAX rate in Gbps that
the HDMI 2.1 panel can support in FRL mode. Source need this
field to determine the optimal rate between the source and sink
during FRL training.
v2: Fixed minor bugs, and removed extra wrapper function (Uma Shankar)
Signed-off-by: Sharma, Swati2
Signed-off-by: Ankit Nautiyal
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/drm_edid.c | 44 +
include/drm/drm_connector.h | 6 +
2 files changed, 50 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 74f5a3197214..e657c321d9e4 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4851,6 +4851,41 @@ static void drm_parse_vcdb(struct drm_connector
*connector, const u8 *db)
info->rgb_quant_range_selectable = true;
}
+static
+void drm_get_max_frl_rate(int max_frl_rate, u8 *max_lanes, u8
*max_rate_per_lane)
+{
+ switch (max_frl_rate) {
+ case 1:
+ *max_lanes = 3;
+ *max_rate_per_lane = 3;
+ break;
+ case 2:
+ *max_lanes = 3;
+ *max_rate_per_lane = 6;
+ break;
+ case 3:
+ *max_lanes = 4;
+ *max_rate_per_lane = 6;
+ break;
+ case 4:
+ *max_lanes = 4;
+ *max_rate_per_lane = 8;
+ break;
+ case 5:
+ *max_lanes = 4;
+ *max_rate_per_lane = 10;
+ break;
+ case 6:
+ *max_lanes = 4;
+ *max_rate_per_lane = 12;
+ break;
+ case 0:
+ default:
+ *max_lanes = 0;
+ *max_rate_per_lane = 0;
+ }
+}
+
static void drm_parse_ycbcr420_deep_color_info(struct drm_connector *connector,
const u8 *db)
{
@@ -4904,6 +4939,15 @@ static void drm_parse_hdmi_forum_vsdb(struct
drm_connector *connector,
}
}
+ if (hf_vsdb[7]) {
+ u8 max_frl_rate;
+
+ DRM_DEBUG_KMS("hdmi_21 sink detected. parsing edid\n");
+ max_frl_rate = (hf_vsdb[7] & DRM_EDID_MAX_FRL_RATE_MASK) >> 4;
+ drm_get_max_frl_rate(max_frl_rate, &hdmi->max_lanes,
+ &hdmi->max_frl_rate_per_lane);
+ }
+
drm_parse_ycbcr420_deep_color_info(connector, hf_vsdb);
}
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index fcdc58d8b88b..1a3b4776b458 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -207,6 +207,12 @@ struct drm_hdmi_info {
/** @y420_dc_modes: bitmap of deep color support index */
u8 y420_dc_modes;
+
+ /** @max_frl_rate_per_lane: support fixed rate link */
+ u8 max_frl_rate_per_lane;
+
+ /** @max_lanes: supported by sink */
+ u8 max_lanes;
};
/**
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 01/16] drm/edid: Add additional HFVSDB fields for HDMI2.1
From: Swati Sharma
The HDMI2.1 extends HFVSDB (HDMI Forum Vendor Specific
Data block) to have fields related to newly defined methods of FRL
(Fixed Rate Link) levels, number of lanes supported, DSC Color bit
depth, VRR min/max, FVA (Fast Vactive), ALLM etc.
This patch adds the new HFVSDB fields that are required for
HDMI2.1.
v2: Minor fixes + consistent naming for DPCD register masks
(Uma Shankar)
Signed-off-by: Sharma, Swati2
Signed-off-by: Ankit Nautiyal
Reviewed-by: Uma Shankar
---
include/drm/drm_edid.h | 30 ++
1 file changed, 30 insertions(+)
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index e97daf6ffbb1..a158f585f658 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -229,6 +229,36 @@ struct detailed_timing {
DRM_EDID_YCBCR420_DC_36 | \
DRM_EDID_YCBCR420_DC_30)
+/* HDMI 2.1 additional fields */
+#define DRM_EDID_MAX_FRL_RATE_MASK 0xf0
+#define DRM_EDID_FAPA_START_LOCATION (1 << 0)
+#define DRM_EDID_ALLM (1 << 1)
+#define DRM_EDID_FVA (1 << 2)
+
+/* Deep Color specific */
+#define DRM_EDID_DC_30BIT_420 (1 << 0)
+#define DRM_EDID_DC_36BIT_420 (1 << 1)
+#define DRM_EDID_DC_48BIT_420 (1 << 2)
+
+/* VRR specific */
+#define DRM_EDID_CNMVRR(1 << 3)
+#define DRM_EDID_CINEMA_VRR(1 << 4)
+#define DRM_EDID_MDELTA(1 << 5)
+#define DRM_EDID_VRR_MAX_UPPER_MASK0xc0
+#define DRM_EDID_VRR_MAX_LOWER_MASK0xff
+#define DRM_EDID_VRR_MIN_MASK 0x3f
+
+/* DSC specific */
+#define DRM_EDID_DSC_10BPC (1 << 0)
+#define DRM_EDID_DSC_12BPC (1 << 1)
+#define DRM_EDID_DSC_16BPC (1 << 2)
+#define DRM_EDID_DSC_ALL_BPP (1 << 3)
+#define DRM_EDID_DSC_NATIVE_420(1 << 6)
+#define DRM_EDID_DSC_1P2 (1 << 7)
+#define DRM_EDID_DSC_MAX_FRL_RATE_MASK 0xf0
+#define DRM_EDID_DSC_MAX_SLICES0xf
+#define DRM_EDID_DSC_TOTAL_CHUNK_KBYTES0x3f
+
/* ELD Header Block */
#define DRM_ELD_HEADER_BLOCK_SIZE 4
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 00/16] Add support for DP-HDMI2.1 PCON
This patch series attempts to add support for a DP-HDMI2.1 Protocol Convertor. The VESA spec for the HDMI2.1 PCON are proposed in Errata E5 to DisplayPort_v2.0: https://vesa.org/join-vesamemberships/member-downloads/?action=stamp&fileid=42299 The details are mentioned in: VESA DP-to-HDMI PCON Specification Standalone Document https://groups.vesa.org/wg/DP/document/15651 This series starts with adding support for FRL (Fixed Rate Link) Training between the PCON and HDMI2.1 sink. As per HDMI2.1 specification, a new data-channel or lane is added in FRL mode, by repurposing the TMDS clock Channel. Through FRL, higher bit-rate can be supported, ie. up to 12 Gbps/lane (48 Gbps over 4 lanes). With these patches, the HDMI2.1 PCON can be configured to achieve FRL training based on the maximum FRL rate supported by the panel, source and the PCON. The approach is to add the support for FRL training between PCON and HDMI2.1 sink and gradually add other blocks for supporting higher resolutions and other HDMI2.1 features, that can be supported by pcon for the sources that do not natively support HDMI2.1. This is done before the DP Link training between the source and PCON is started. In case of FRL training is not achieved, the PCON will work in the regular TMDS mode, without HDMI2.1 feature support. Any interruption in FRL training between the PCON and HDMI2.1 sink is notified through IRQ_HPD. On receiving the IRQ_HPD the concerned DPCD registers are read and FRL training is re-attempted. Currently, we have tested the FRL training and are able to enable 4K display with TGL Platform + Realtek PCON RTD2173 with HDMI2.1 supporting panel. v2: Addressed review comments and re-organized patches as suggested in comments on RFC patches. v3: Addressed review comments on previous version. v4: Added support for RGB->YCBCR conversion through PCON Ankit Nautiyal (12): drm/edid: Parse DSC1.2 cap fields from HFVSDB block drm/dp_helper: Add Helpers for FRL Link Training support for DP-HDMI2.1 PCON drm/dp_helper: Add support for Configuring DSC for HDMI2.1 Pcon drm/dp_helper: Add helpers to configure PCONs RGB-YCbCr Conversion drm/i915: Capture max frl rate for PCON in dfp cap structure drm/i915: Add support for starting FRL training for HDMI2.1 via PCON drm/i915: Check for FRL training before DP Link training drm/i915: Read DSC capabilities of the HDMI2.1 PCON encoder drm/i915: Add helper functions for calculating DSC parameters for HDMI2.1 drm/i915/display: Configure PCON for DSC1.1 to DSC1.2 encoding drm/i915: Let PCON convert from RGB to YUV if it can drm/i915: Enable PCON configuration for Color Conversion for TGL Swati Sharma (4): drm/edid: Add additional HFVSDB fields for HDMI2.1 drm/edid: Parse MAX_FRL field from HFVSDB block drm/dp_helper: Add support for link failure detection drm/i915: Add support for enabling link status and recovery drivers/gpu/drm/drm_dp_helper.c | 603 ++ drivers/gpu/drm/drm_edid.c| 103 +++ drivers/gpu/drm/i915/display/intel_ddi.c | 4 + .../drm/i915/display/intel_display_types.h| 10 + drivers/gpu/drm/i915/display/intel_dp.c | 457 - drivers/gpu/drm/i915/display/intel_dp.h | 5 + drivers/gpu/drm/i915/display/intel_hdmi.c | 233 +++ drivers/gpu/drm/i915/display/intel_hdmi.h | 7 + include/drm/drm_connector.h | 49 ++ include/drm/drm_dp_helper.h | 220 +++ include/drm/drm_edid.h| 30 + 11 files changed, 1704 insertions(+), 17 deletions(-) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 6/9] drm/vc4: hdmi: Store pixel frequency in the connector state
Am 07.12.20 um 16:57 schrieb Maxime Ripard:
The pixel rate is for now quite simple to compute, but with more features
(30 and 36 bits output, YUV output, etc.) will depend on a bunch of
connectors properties.
Let's store the rate we have to run the pixel clock at in our custom
connector state, and compute it in atomic_check.
Signed-off-by: Maxime Ripard
Acked-by: Thomas Zimmermann
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 26 +-
drivers/gpu/drm/vc4/vc4_hdmi.h | 1 +
2 files changed, 26 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 744396c8dcb9..83699105c7a5 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -194,6 +194,7 @@ vc4_hdmi_connector_duplicate_state(struct drm_connector
*connector)
if (!new_state)
return NULL;
+ new_state->pixel_rate = vc4_state->pixel_rate;
__drm_atomic_helper_connector_duplicate_state(connector,
&new_state->base);
return &new_state->base;
@@ -611,9 +612,29 @@ static void vc4_hdmi_recenter_fifo(struct vc4_hdmi
*vc4_hdmi)
"VC4_HDMI_FIFO_CTL_RECENTER_DONE");
}
+static struct drm_connector_state *
+vc4_hdmi_encoder_get_connector_state(struct drm_encoder *encoder,
+struct drm_atomic_state *state)
+{
+ struct drm_connector_state *conn_state;
+ struct drm_connector *connector;
+ unsigned int i;
+
+ for_each_new_connector_in_state(state, connector, conn_state, i) {
+ if (conn_state->best_encoder == encoder)
+ return conn_state;
+ }
+
+ return NULL;
+}
+
static void vc4_hdmi_encoder_pre_crtc_configure(struct drm_encoder *encoder,
struct drm_atomic_state *state)
{
+ struct drm_connector_state *conn_state =
+ vc4_hdmi_encoder_get_connector_state(encoder, state);
+ struct vc4_hdmi_connector_state *vc4_conn_state =
+ conn_state_to_vc4_hdmi_conn_state(conn_state);
struct drm_display_mode *mode = &encoder->crtc->state->adjusted_mode;
struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
unsigned long pixel_rate, hsm_rate;
@@ -625,7 +646,7 @@ static void vc4_hdmi_encoder_pre_crtc_configure(struct
drm_encoder *encoder,
return;
}
- pixel_rate = mode->clock * 1000 * ((mode->flags & DRM_MODE_FLAG_DBLCLK) ? 2 : 1);
+ pixel_rate = vc4_conn_state->pixel_rate;
ret = clk_set_rate(vc4_hdmi->pixel_clock, pixel_rate);
if (ret) {
DRM_ERROR("Failed to set pixel clock rate: %d\n", ret);
@@ -797,6 +818,7 @@ static int vc4_hdmi_encoder_atomic_check(struct drm_encoder
*encoder,
struct drm_crtc_state *crtc_state,
struct drm_connector_state *conn_state)
{
+ struct vc4_hdmi_connector_state *vc4_state =
conn_state_to_vc4_hdmi_conn_state(conn_state);
struct drm_display_mode *mode = &crtc_state->adjusted_mode;
struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
unsigned long long pixel_rate = mode->clock * 1000;
@@ -827,6 +849,8 @@ static int vc4_hdmi_encoder_atomic_check(struct drm_encoder
*encoder,
if (pixel_rate > vc4_hdmi->variant->max_pixel_clock)
return -EINVAL;
+ vc4_state->pixel_rate = pixel_rate;
+
return 0;
}
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
index 2cf5362052e2..bca6943de884 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.h
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
@@ -182,6 +182,7 @@ encoder_to_vc4_hdmi(struct drm_encoder *encoder)
struct vc4_hdmi_connector_state {
struct drm_connector_state base;
+ unsigned long long pixel_rate;
};
static inline struct vc4_hdmi_connector_state *
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 3/9] drm/vc4: hdmi: Take into account the clock doubling flag in atomic_check
Am 07.12.20 um 16:57 schrieb Maxime Ripard:
Reported-by: Thomas Zimmermann
Fixes: 63495f6b4aed ("drm/vc4: hdmi: Make sure our clock rate is within limits")
Signed-off-by: Maxime Ripard
Acked-by: Thomas Zimmermann
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 5a608ed1d75e..a88aa20beeb6 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -796,6 +796,9 @@ static int vc4_hdmi_encoder_atomic_check(struct drm_encoder
*encoder,
pixel_rate = mode->clock * 1000;
}
+ if (mode->flags & DRM_MODE_FLAG_DBLCLK)
+ pixel_rate = pixel_rate * 2;
+
if (pixel_rate > vc4_hdmi->variant->max_pixel_clock)
return -EINVAL;
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 2/9] drm/vc4: Pass the atomic state to encoder hooks
Am 07.12.20 um 16:57 schrieb Maxime Ripard:
We'll need to access the connector state in our encoder setup, so let's
just pass the whole DRM state to our private encoder hooks.
Signed-off-by: Maxime Ripard
Acked-by: Thomas Zimmermann
---
drivers/gpu/drm/vc4/vc4_crtc.c | 18 ++
drivers/gpu/drm/vc4/vc4_drv.h | 10 +-
drivers/gpu/drm/vc4/vc4_hdmi.c | 15 ++-
3 files changed, 25 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index e02e499885ed..a3439756594c 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -403,7 +403,9 @@ static void require_hvs_enabled(struct drm_device *dev)
SCALER_DISPCTRL_ENABLE);
}
-static int vc4_crtc_disable(struct drm_crtc *crtc, unsigned int channel)
+static int vc4_crtc_disable(struct drm_crtc *crtc,
+ struct drm_atomic_state *state,
+ unsigned int channel)
{
struct drm_encoder *encoder = vc4_get_crtc_encoder(crtc);
struct vc4_encoder *vc4_encoder = to_vc4_encoder(encoder);
@@ -435,13 +437,13 @@ static int vc4_crtc_disable(struct drm_crtc *crtc,
unsigned int channel)
mdelay(20);
if (vc4_encoder && vc4_encoder->post_crtc_disable)
- vc4_encoder->post_crtc_disable(encoder);
+ vc4_encoder->post_crtc_disable(encoder, state);
vc4_crtc_pixelvalve_reset(crtc);
vc4_hvs_stop_channel(dev, channel);
if (vc4_encoder && vc4_encoder->post_crtc_powerdown)
- vc4_encoder->post_crtc_powerdown(encoder);
+ vc4_encoder->post_crtc_powerdown(encoder, state);
return 0;
}
@@ -468,7 +470,7 @@ int vc4_crtc_disable_at_boot(struct drm_crtc *crtc)
if (channel < 0)
return 0;
- return vc4_crtc_disable(crtc, channel);
+ return vc4_crtc_disable(crtc, NULL, channel);
}
static void vc4_crtc_atomic_disable(struct drm_crtc *crtc,
@@ -484,7 +486,7 @@ static void vc4_crtc_atomic_disable(struct drm_crtc *crtc,
/* Disable vblank irq handling before crtc is disabled. */
drm_crtc_vblank_off(crtc);
- vc4_crtc_disable(crtc, old_vc4_state->assigned_channel);
+ vc4_crtc_disable(crtc, state, old_vc4_state->assigned_channel);
/*
* Make sure we issue a vblank event after disabling the CRTC if
@@ -518,14 +520,14 @@ static void vc4_crtc_atomic_enable(struct drm_crtc *crtc,
vc4_hvs_atomic_enable(crtc, state);
if (vc4_encoder->pre_crtc_configure)
- vc4_encoder->pre_crtc_configure(encoder);
+ vc4_encoder->pre_crtc_configure(encoder, state);
vc4_crtc_config_pv(crtc);
CRTC_WRITE(PV_CONTROL, CRTC_READ(PV_CONTROL) | PV_CONTROL_EN);
if (vc4_encoder->pre_crtc_enable)
- vc4_encoder->pre_crtc_enable(encoder);
+ vc4_encoder->pre_crtc_enable(encoder, state);
/* When feeding the transposer block the pixelvalve is unneeded and
* should not be enabled.
@@ -534,7 +536,7 @@ static void vc4_crtc_atomic_enable(struct drm_crtc *crtc,
CRTC_READ(PV_V_CONTROL) | PV_VCONTROL_VIDEN);
if (vc4_encoder->post_crtc_enable)
- vc4_encoder->post_crtc_enable(encoder);
+ vc4_encoder->post_crtc_enable(encoder, state);
}
static enum drm_mode_status vc4_crtc_mode_valid(struct drm_crtc *crtc,
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index c47c85533805..b404cd3ab0d8 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -444,12 +444,12 @@ struct vc4_encoder {
enum vc4_encoder_type type;
u32 clock_select;
- void (*pre_crtc_configure)(struct drm_encoder *encoder);
- void (*pre_crtc_enable)(struct drm_encoder *encoder);
- void (*post_crtc_enable)(struct drm_encoder *encoder);
+ void (*pre_crtc_configure)(struct drm_encoder *encoder, struct
drm_atomic_state *state);
+ void (*pre_crtc_enable)(struct drm_encoder *encoder, struct
drm_atomic_state *state);
+ void (*post_crtc_enable)(struct drm_encoder *encoder, struct
drm_atomic_state *state);
- void (*post_crtc_disable)(struct drm_encoder *encoder);
- void (*post_crtc_powerdown)(struct drm_encoder *encoder);
+ void (*post_crtc_disable)(struct drm_encoder *encoder, struct
drm_atomic_state *state);
+ void (*post_crtc_powerdown)(struct drm_encoder *encoder, struct
drm_atomic_state *state);
};
static inline struct vc4_encoder *
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index afc178b0d89f..5a608ed1d75e 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -357,7 +357,8 @@ static void vc4_hdmi_set_infoframes(struct drm_encoder
*encoder)
vc4_hdmi_set_audio_infoframe(encoder);
}
-static void vc4_hdmi_encoder_post_crtc_disab
Re: [PATCH v13 2/4] RDMA/core: Add device method for registering dma-buf based memory region
On Mon, Dec 07, 2020 at 02:15:51PM -0800, Jianxin Xiong wrote: > Dma-buf based memory region requires one extra parameter and is processed > quite differently. Adding a separate method allows clean separation from > regular memory regions. > > Signed-off-by: Jianxin Xiong > Reviewed-by: Sean Hefty > Acked-by: Michael J. Ruhl > Acked-by: Christian Koenig > Acked-by: Daniel Vetter > --- > drivers/infiniband/core/device.c | 1 + > include/rdma/ib_verbs.h | 6 +- > 2 files changed, 6 insertions(+), 1 deletion(-) > Thanks, Reviewed-by: Leon Romanovsky ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v13 1/4] RDMA/umem: Support importing dma-buf as user memory region
> -Original Message-
> From: Leon Romanovsky
> Sent: Monday, December 07, 2020 11:06 PM
> To: Xiong, Jianxin
> Cc: linux-r...@vger.kernel.org; dri-devel@lists.freedesktop.org; Doug Ledford
> ; Jason Gunthorpe ;
> Sumit Semwal ; Christian Koenig
> ; Vetter, Daniel
> Subject: Re: [PATCH v13 1/4] RDMA/umem: Support importing dma-buf as user
> memory region
>
> On Mon, Dec 07, 2020 at 02:15:50PM -0800, Jianxin Xiong wrote:
> > Dma-buf is a standard cross-driver buffer sharing mechanism that can
> > be used to support peer-to-peer access from RDMA devices.
> >
> > Device memory exported via dma-buf is associated with a file descriptor.
> > This is passed to the user space as a property associated with the
> > buffer allocation. When the buffer is registered as a memory region,
> > the file descriptor is passed to the RDMA driver along with other
> > parameters.
> >
> > Implement the common code for importing dma-buf object and mapping
> > dma-buf pages.
> >
> > Signed-off-by: Jianxin Xiong
> > Reviewed-by: Sean Hefty
> > Acked-by: Michael J. Ruhl
> > Acked-by: Christian Koenig
> > Acked-by: Daniel Vetter
> >
> > Conflicts:
> > include/rdma/ib_umem.h
>
> This probably leftover from rebase, am I right?
Right. Should have removed it.
>
> > ---
> > drivers/infiniband/core/Makefile | 2 +-
> > drivers/infiniband/core/umem.c| 3 +
> > drivers/infiniband/core/umem_dmabuf.c | 173
> > ++
> > include/rdma/ib_umem.h| 43 -
> > 4 files changed, 219 insertions(+), 2 deletions(-) create mode
> > 100644 drivers/infiniband/core/umem_dmabuf.c
> >
> > diff --git a/drivers/infiniband/core/Makefile
> > b/drivers/infiniband/core/Makefile
> > index ccf2670..8ab4eea 100644
> > --- a/drivers/infiniband/core/Makefile
> > +++ b/drivers/infiniband/core/Makefile
> > @@ -40,5 +40,5 @@ ib_uverbs-y :=uverbs_main.o
> > uverbs_cmd.o uverbs_marshall.o \
> > uverbs_std_types_srq.o \
> > uverbs_std_types_wq.o \
> > uverbs_std_types_qp.o
> > -ib_uverbs-$(CONFIG_INFINIBAND_USER_MEM) += umem.o
> > +ib_uverbs-$(CONFIG_INFINIBAND_USER_MEM) += umem.o umem_dmabuf.o
> > ib_uverbs-$(CONFIG_INFINIBAND_ON_DEMAND_PAGING) += umem_odp.o diff
> > --git a/drivers/infiniband/core/umem.c
> > b/drivers/infiniband/core/umem.c index 7ca4112..cc131f8 100644
> > --- a/drivers/infiniband/core/umem.c
> > +++ b/drivers/infiniband/core/umem.c
> > @@ -2,6 +2,7 @@
> > * Copyright (c) 2005 Topspin Communications. All rights reserved.
> > * Copyright (c) 2005 Cisco Systems. All rights reserved.
> > * Copyright (c) 2005 Mellanox Technologies. All rights reserved.
> > + * Copyright (c) 2020 Intel Corporation. All rights reserved.
> > *
> > * This software is available to you under a choice of one of two
> > * licenses. You may choose to be licensed under the terms of the
> > GNU @@ -278,6 +279,8 @@ void ib_umem_release(struct ib_umem *umem) {
> > if (!umem)
> > return;
> > + if (umem->is_dmabuf)
> > + return ib_umem_dmabuf_release(to_ib_umem_dmabuf(umem));
> > if (umem->is_odp)
> > return ib_umem_odp_release(to_ib_umem_odp(umem));
> >
> > diff --git a/drivers/infiniband/core/umem_dmabuf.c
> > b/drivers/infiniband/core/umem_dmabuf.c
> > new file mode 100644
> > index 000..e50b955
> > --- /dev/null
> > +++ b/drivers/infiniband/core/umem_dmabuf.c
> > @@ -0,0 +1,173 @@
> > +// SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause)
> > +/*
> > + * Copyright (c) 2020 Intel Corporation. All rights reserved.
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +
> > +#include "uverbs.h"
> > +
> > +int ib_umem_dmabuf_map_pages(struct ib_umem_dmabuf *umem_dmabuf) {
> > + struct sg_table *sgt;
> > + struct scatterlist *sg;
> > + struct dma_fence *fence;
> > + unsigned long start, end, cur;
> > + unsigned int nmap;
> > + int i;
> > +
> > + dma_resv_assert_held(umem_dmabuf->attach->dmabuf->resv);
> > +
> > + if (umem_dmabuf->sgt)
> > + return 0;
> > +
> > + sgt = dma_buf_map_attachment(umem_dmabuf->attach, DMA_BIDIRECTIONAL);
> > + if (IS_ERR(sgt))
> > + return PTR_ERR(sgt);
> > +
> > + /* modify the sg list in-place to match umem address and length */
> > +
> > + start = ALIGN_DOWN(umem_dmabuf->umem.address, PAGE_SIZE);
> > + end = ALIGN(umem_dmabuf->umem.address + umem_dmabuf->umem.length,
> > + PAGE_SIZE);
> > + cur = 0;
> > + nmap = 0;
>
> Better to put as part of variable initialization.
>
> > + for_each_sgtable_dma_sg(sgt, sg, i) {
> > + if (start < cur + sg_dma_len(sg) && cur < end)
> > + nmap++;
> > + if (cur <= start && start < cur + sg_dma_len(sg)) {
> > + unsigned long offset = start - cur;
> > +
> > + umem_dmabuf->first_sg = sg;
> > + umem_dmabu
Re: [PATCH v13 3/4] RDMA/uverbs: Add uverbs command for dma-buf based MR registration
On Mon, Dec 07, 2020 at 02:15:52PM -0800, Jianxin Xiong wrote: > Implement a new uverbs ioctl method for memory registration with file > descriptor as an extra parameter. > > Signed-off-by: Jianxin Xiong > Reviewed-by: Sean Hefty > Acked-by: Michael J. Ruhl > Acked-by: Christian Koenig > Acked-by: Daniel Vetter > --- > drivers/infiniband/core/uverbs_std_types_mr.c | 117 > +- > include/uapi/rdma/ib_user_ioctl_cmds.h| 14 +++ > 2 files changed, 129 insertions(+), 2 deletions(-) > Thanks, Reviewed-by: Leon Romanovsky ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v13 1/4] RDMA/umem: Support importing dma-buf as user memory region
On Mon, Dec 07, 2020 at 02:15:50PM -0800, Jianxin Xiong wrote:
> Dma-buf is a standard cross-driver buffer sharing mechanism that can be
> used to support peer-to-peer access from RDMA devices.
>
> Device memory exported via dma-buf is associated with a file descriptor.
> This is passed to the user space as a property associated with the
> buffer allocation. When the buffer is registered as a memory region,
> the file descriptor is passed to the RDMA driver along with other
> parameters.
>
> Implement the common code for importing dma-buf object and mapping
> dma-buf pages.
>
> Signed-off-by: Jianxin Xiong
> Reviewed-by: Sean Hefty
> Acked-by: Michael J. Ruhl
> Acked-by: Christian Koenig
> Acked-by: Daniel Vetter
>
> Conflicts:
> include/rdma/ib_umem.h
This probably leftover from rebase, am I right?
> ---
> drivers/infiniband/core/Makefile | 2 +-
> drivers/infiniband/core/umem.c| 3 +
> drivers/infiniband/core/umem_dmabuf.c | 173
> ++
> include/rdma/ib_umem.h| 43 -
> 4 files changed, 219 insertions(+), 2 deletions(-)
> create mode 100644 drivers/infiniband/core/umem_dmabuf.c
>
> diff --git a/drivers/infiniband/core/Makefile
> b/drivers/infiniband/core/Makefile
> index ccf2670..8ab4eea 100644
> --- a/drivers/infiniband/core/Makefile
> +++ b/drivers/infiniband/core/Makefile
> @@ -40,5 +40,5 @@ ib_uverbs-y := uverbs_main.o
> uverbs_cmd.o uverbs_marshall.o \
> uverbs_std_types_srq.o \
> uverbs_std_types_wq.o \
> uverbs_std_types_qp.o
> -ib_uverbs-$(CONFIG_INFINIBAND_USER_MEM) += umem.o
> +ib_uverbs-$(CONFIG_INFINIBAND_USER_MEM) += umem.o umem_dmabuf.o
> ib_uverbs-$(CONFIG_INFINIBAND_ON_DEMAND_PAGING) += umem_odp.o
> diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c
> index 7ca4112..cc131f8 100644
> --- a/drivers/infiniband/core/umem.c
> +++ b/drivers/infiniband/core/umem.c
> @@ -2,6 +2,7 @@
> * Copyright (c) 2005 Topspin Communications. All rights reserved.
> * Copyright (c) 2005 Cisco Systems. All rights reserved.
> * Copyright (c) 2005 Mellanox Technologies. All rights reserved.
> + * Copyright (c) 2020 Intel Corporation. All rights reserved.
> *
> * This software is available to you under a choice of one of two
> * licenses. You may choose to be licensed under the terms of the GNU
> @@ -278,6 +279,8 @@ void ib_umem_release(struct ib_umem *umem)
> {
> if (!umem)
> return;
> + if (umem->is_dmabuf)
> + return ib_umem_dmabuf_release(to_ib_umem_dmabuf(umem));
> if (umem->is_odp)
> return ib_umem_odp_release(to_ib_umem_odp(umem));
>
> diff --git a/drivers/infiniband/core/umem_dmabuf.c
> b/drivers/infiniband/core/umem_dmabuf.c
> new file mode 100644
> index 000..e50b955
> --- /dev/null
> +++ b/drivers/infiniband/core/umem_dmabuf.c
> @@ -0,0 +1,173 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause)
> +/*
> + * Copyright (c) 2020 Intel Corporation. All rights reserved.
> + */
> +
> +#include
> +#include
> +#include
> +
> +#include "uverbs.h"
> +
> +int ib_umem_dmabuf_map_pages(struct ib_umem_dmabuf *umem_dmabuf)
> +{
> + struct sg_table *sgt;
> + struct scatterlist *sg;
> + struct dma_fence *fence;
> + unsigned long start, end, cur;
> + unsigned int nmap;
> + int i;
> +
> + dma_resv_assert_held(umem_dmabuf->attach->dmabuf->resv);
> +
> + if (umem_dmabuf->sgt)
> + return 0;
> +
> + sgt = dma_buf_map_attachment(umem_dmabuf->attach, DMA_BIDIRECTIONAL);
> + if (IS_ERR(sgt))
> + return PTR_ERR(sgt);
> +
> + /* modify the sg list in-place to match umem address and length */
> +
> + start = ALIGN_DOWN(umem_dmabuf->umem.address, PAGE_SIZE);
> + end = ALIGN(umem_dmabuf->umem.address + umem_dmabuf->umem.length,
> + PAGE_SIZE);
> + cur = 0;
> + nmap = 0;
Better to put as part of variable initialization.
> + for_each_sgtable_dma_sg(sgt, sg, i) {
> + if (start < cur + sg_dma_len(sg) && cur < end)
> + nmap++;
> + if (cur <= start && start < cur + sg_dma_len(sg)) {
> + unsigned long offset = start - cur;
> +
> + umem_dmabuf->first_sg = sg;
> + umem_dmabuf->first_sg_offset = offset;
> + sg_dma_address(sg) += offset;
> + sg_dma_len(sg) -= offset;
> + cur += offset;
> + }
> + if (cur < end && end <= cur + sg_dma_len(sg)) {
> + unsigned long trim = cur + sg_dma_len(sg) - end;
> +
> + umem_dmabuf->last_sg = sg;
> + umem_dmabuf->last_sg_trim = trim;
> + sg_dma_len(sg) -= trim;
> + break;
> + }
> + cur += sg_dm
Re: [RFC PATCH] drm/panel: Make backlight attachment lazy
Hi Bjorn,
On Mon, Dec 07, 2020 at 10:44:46PM -0600, Bjorn Andersson wrote:
> Some bridge chips, such as the TI SN65DSI86 DSI/eDP bridge, provides
> means of generating a PWM signal for backlight control of the attached
> panel. The provided PWM chip is typically controlled by the
> pwm-backlight driver, which if tied to the panel will provide DPMS.
>
> But with the current implementation the panel will refuse to probe
> because the bridge driver has yet to probe and register the PWM chip,
> and the bridge driver will refuse to probe because it's unable to find
> the panel.
>
> Mitigate this catch-22 situation by allowing the panel driver to probe
> and retry the attachment of the backlight as the panel is turned on or
> off.
>
> Signed-off-by: Bjorn Andersson
> ---
> drivers/gpu/drm/drm_panel.c | 47 +++--
> include/drm/drm_panel.h | 8 +++
> 2 files changed, 43 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
> index f634371c717a..7487329bd22d 100644
> --- a/drivers/gpu/drm/drm_panel.c
> +++ b/drivers/gpu/drm/drm_panel.c
> @@ -43,6 +43,34 @@ static LIST_HEAD(panel_list);
> * take look at drm_panel_bridge_add() and devm_drm_panel_bridge_add().
> */
>
> +#if IS_REACHABLE(CONFIG_BACKLIGHT_CLASS_DEVICE)
> +static int drm_panel_of_backlight_lazy(struct drm_panel *panel)
> +{
> + struct backlight_device *backlight;
> +
> + if (!panel || !panel->dev)
> + return -EINVAL;
> +
> + backlight = devm_of_find_backlight(panel->dev);
> +
> + if (IS_ERR(backlight)) {
> + if (PTR_ERR(backlight) == -EPROBE_DEFER) {
> + panel->backlight_init_pending = true;
> + return 0;
> + }
> +
> + return PTR_ERR(backlight);
Use dev_err_probe()
> + }
> +
> + panel->backlight = backlight;
> + panel->backlight_init_pending = false;
> +
> + return 0;
> +}
> +#else
> +static int drm_panel_of_backlight_lazy(struct drm_panel *panel) { return 0; }
> +#endif
> +
> /**
> * drm_panel_init - initialize a panel
> * @panel: DRM panel
> @@ -161,6 +189,9 @@ int drm_panel_enable(struct drm_panel *panel)
> return ret;
> }
>
> + if (panel->backlight_init_pending)
> + drm_panel_of_backlight_lazy(panel);
> +
> ret = backlight_enable(panel->backlight);
> if (ret < 0)
> DRM_DEV_INFO(panel->dev, "failed to enable backlight: %d\n",
> @@ -187,6 +218,9 @@ int drm_panel_disable(struct drm_panel *panel)
> if (!panel)
> return -EINVAL;
>
> + if (panel->backlight_init_pending)
> + drm_panel_of_backlight_lazy(panel);
> +
> ret = backlight_disable(panel->backlight);
> if (ret < 0)
> DRM_DEV_INFO(panel->dev, "failed to disable backlight: %d\n",
> @@ -328,18 +362,7 @@ EXPORT_SYMBOL(of_drm_get_panel_orientation);
> */
> int drm_panel_of_backlight(struct drm_panel *panel)
> {
> - struct backlight_device *backlight;
> -
> - if (!panel || !panel->dev)
> - return -EINVAL;
> -
> - backlight = devm_of_find_backlight(panel->dev);
> -
> - if (IS_ERR(backlight))
> - return PTR_ERR(backlight);
> -
> - panel->backlight = backlight;
> - return 0;
> + return drm_panel_of_backlight_lazy(panel);
Could you update the drm_panel_of_backlight() implementation (and
do not forget the documentation) and avoid drm_panel_of_backlight_lazy()?
Sam
> }
> EXPORT_SYMBOL(drm_panel_of_backlight);
> #endif
> diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
> index 33605c3f0eba..b126abebb2f3 100644
> --- a/include/drm/drm_panel.h
> +++ b/include/drm/drm_panel.h
> @@ -149,6 +149,14 @@ struct drm_panel {
>*/
> struct backlight_device *backlight;
>
> + /**
> + * @backlight_init_pending
> + *
> + * Backlight driver is not yet available so further attempts to
> + * initialize @backlight is necessary.
> + */
> + bool backlight_init_pending;
> +
We have not done so today for other fields, but it would be good
to document this is for drm_panel use only and drivers shall not touch.
Sam
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
linux-next: manual merge of the drm tree with the pci tree
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/vga/vga_switcheroo.c
between commit:
99efde6c9bb7 ("PCI/PM: Rename pci_wakeup_bus() to pci_resume_bus()")
from the pci tree and commit:
9572e6693cd7 ("vga_switcheroo: simplify the return expression of
vga_switcheroo_runtime_resume")
from the drm tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/gpu/vga/vga_switcheroo.c
index 8843b078ad4e,1401fd52f37a..
--- a/drivers/gpu/vga/vga_switcheroo.c
+++ b/drivers/gpu/vga/vga_switcheroo.c
@@@ -1039,12 -1038,8 +1038,8 @@@ static int vga_switcheroo_runtime_resum
mutex_lock(&vgasr_mutex);
vga_switcheroo_power_switch(pdev, VGA_SWITCHEROO_ON);
mutex_unlock(&vgasr_mutex);
- pci_wakeup_bus(pdev->bus);
+ pci_resume_bus(pdev->bus);
- ret = dev->bus->pm->runtime_resume(dev);
- if (ret)
- return ret;
-
- return 0;
+ return dev->bus->pm->runtime_resume(dev);
}
/**
pgpPyJjYt2EAT.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/9] drm: rcar-du: Fix crash when using LVDS1 clock for CRTC
Geert, On Mon, Dec 07, 2020 at 09:15:11AM +0100, Geert Uytterhoeven wrote: > On Fri, Dec 4, 2020 at 11:02 PM Laurent Pinchart wrote: > > On D3 and E3 platforms, the LVDS encoder includes a PLL that can > > generate a clock for the corresponding CRTC, used even when the CRTC > > output to a non-LVDS port. This mechanism is supported by the driver, > > but the implementation is broken in dual-link LVDS mode. In that case, > > the LVDS1 drm_encoder is skipped, which causes a crash when trying to > > access its bridge later on. > > > > Fix this by storing bridge pointers internally instead of retrieving > > them from the encoder. > > > > Signed-off-by: Laurent Pinchart > > Thanks for your patch! > > I think this warrants a Fixes tag, to assist the stable team in backporting > this fix. I'll add one. -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 210543] New: amdgpu Kernel panic：__ttm_dma_free_page.isra.0+0xac/0xe8 [ttm]
https://bugzilla.kernel.org/show_bug.cgi?id=210543 Bug ID: 210543 Summary: amdgpu Kernel panic：__ttm_dma_free_page.isra.0+0xac/0xe8 [ttm] Product: Drivers Version: 2.5 Kernel Version: 4.19 Hardware: ARM OS: Linux Tree: Mainline Status: NEW Severity: blocking Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: acyel...@gmail.com Regression: No When start 16 Android VM to do Android App Monkey test, Linux kernel panic happens which causes the computer restart. It seems AMDGPU related issue. GPU device： 0007:01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Device 67c7 2020-11-19 17:23:35 [ 1483.496680] pstate: 4049 (nZcv daif +PAN -UAO) 2020-11-19 17:23:35 [ 1483.496687] pc : kfree+0x78/0x1a8 2020-11-19 17:23:35 [ 1483.496697] lr : __ttm_dma_free_page.isra.0+0xac/0xe8 [ttm] 2020-11-19 17:23:35 [ 1483.496697] sp : 1f9138d0 2020-11-19 17:23:35 [ 1483.496698] x29: 1f9138d0 x28: 0008 2020-11-19 17:23:35 [ 1483.496699] x27: x26: c003e1d69d48 2020-11-19 17:23:35 [ 1483.496700] x25: 0001 x24: 1000 2020-11-19 17:23:35 [ 1483.496701] x23: 8000398340b0 x22: 635f8000 2020-11-19 17:23:35 [ 1483.496702] x21: 026c9c94 x20: 000156085000 2020-11-19 17:23:35 [ 1483.496703] x19: 87ff8433fb80 x18: 2020-11-19 17:23:35 [ 1483.496703] x17: x16: 2020-11-19 17:23:35 [ 1483.496704] x15: x14: 2020-11-19 17:23:35 [ 1483.496704] x13: x12: 2020-11-19 17:23:35 [ 1483.496705] x11: 0040 x10: c00359470638 2020-11-19 17:23:35 [ 1483.496705] x9 : 026c9c94 x8 : 00210d00 2020-11-19 17:23:35 [ 1483.496706] x7 : c004e28d4fe0 x6 : 7e1ffe10cfc0 2020-11-19 17:23:35 [ 1483.496707] x5 : 0019 x4 : 7e20029703c0 2020-11-19 17:23:35 [ 1483.496708] x3 : 88046b5f8d78 x2 : 1f9138d0 2020-11-19 17:23:35 [ 1483.496709] x1 : 88046286b000 x0 : c004e28d4e78 2020-11-19 17:23:35 [ 1483.496710] Call trace: 2020-11-19 17:23:35 [ 1483.496712] kfree+0x78/0x1a8 2020-11-19 17:23:35 [ 1483.496715] __ttm_dma_free_page.isra.0+0xac/0xe8 [ttm] 2020-11-19 17:23:35 [ 1483.496719] ttm_dma_page_put+0x5c/0x68 [ttm] 2020-11-19 17:23:35 [ 1483.496722] ttm_dma_unpopulate+0x1f8/0x400 [ttm] 2020-11-19 17:23:35 [ 1483.496804] amdgpu_ttm_tt_unpopulate+0x70/0xa0 [amdgpu] 2020-11-19 17:23:35 [ 1483.496814] ttm_tt_unpopulate+0x6c/0x88 [ttm] 2020-11-19 17:23:35 [ 1483.909262] ttm_tt_destroy.part.0+0x64/0x68 [ttm] 2020-11-19 17:23:35 [ 1483.909266] ttm_tt_destroy+0x18/0x28 [ttm] 2020-11-19 17:23:35 [ 1483.909269] ttm_bo_cleanup_memtype_use+0x3c/0x90 [ttm] 2020-11-19 17:23:35 [ 1483.909272] ttm_bo_cleanup_refs_or_queue+0x1c8/0x200 [ttm] 2020-11-19 17:23:35 [ 1483.909275] ttm_bo_put+0x80/0xb8 [ttm] 2020-11-19 17:23:35 [ 1483.909345] amdgpu_bo_unref+0x28/0x38 [amdgpu] 2020-11-19 17:23:35 [ 1483.909406] amdgpu_gem_object_free+0x3c/0x60 [amdgpu] -- 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 v2 1/1] dt-bindings: display: eliminate yamllint warnings
On Mon, 07 Dec 2020 12:48:30 +0800, Zhen Lei wrote: > Eliminate the following yamllint warnings: > ./Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml > :52:9: [warning] wrong indentation: expected 6 but found 8 (indentation) > > ./Documentation/devicetree/bindings/display/bridge/intel,keembay-dsi.yaml > :42:8: [warning] wrong indentation: expected 8 but found 7 (indentation) > :45:8: [warning] wrong indentation: expected 8 but found 7 (indentation) > > ./Documentation/devicetree/bindings/display/intel,keembay-msscam.yaml > :21:6: [warning] wrong indentation: expected 6 but found 5 (indentation) > > ./Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml > :25:10: [warning] wrong indentation: expected 10 but found 9 (indentation) > > Signed-off-by: Zhen Lei > Acked-by: Sam Ravnborg > --- > .../devicetree/bindings/display/bridge/analogix,anx7625.yaml | 4 > ++-- > .../devicetree/bindings/display/bridge/intel,keembay-dsi.yaml | 4 > ++-- > Documentation/devicetree/bindings/display/intel,keembay-msscam.yaml | 4 > ++-- > Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml | 2 +- > 4 files changed, 7 insertions(+), 7 deletions(-) > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/2] dt-bindings: drm/bridge: anx7625: Add power supplies
On Mon, 23 Nov 2020 11:46:52 +0800, Hsin-Yi Wang wrote: > anx7625 requires 3 power supply regulators. > > Signed-off-by: Hsin-Yi Wang > --- > Change: > v2: remove maxItems for supplies > --- > .../bindings/display/bridge/analogix,anx7625.yaml | 15 +++ > 1 file changed, 15 insertions(+) > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amdgpu: make DRM_AMD_DC x86-only again
On Mon, Dec 7, 2020 at 11:08 PM 'Nick Desaulniers' via Clang Built Linux wrote: > > On Mon, Dec 7, 2020 at 1:57 PM Arnd Bergmann wrote: > > > > Right, looking at my latest randconfig logs, I see the same problem on x86 > > builds with clang as well, though I'm not entirely sure which other > > configuration > > options are needed to trigger it. > > > > So my patch can be disregarded, but I agree this needs a better fix, > > either in clang or in the dcn driver. > > If you could give https://github.com/ClangBuiltLinux/frame-larger-than > a spin again, I would appreciate any feedback. I've already tried it, but the tool doesn't seem to like me, I never get the information out of it that I want. This time it failed because it could not parse the .o file correctly. Arnd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v13 3/4] RDMA/uverbs: Add uverbs command for dma-buf based MR registration
Implement a new uverbs ioctl method for memory registration with file
descriptor as an extra parameter.
Signed-off-by: Jianxin Xiong
Reviewed-by: Sean Hefty
Acked-by: Michael J. Ruhl
Acked-by: Christian Koenig
Acked-by: Daniel Vetter
---
drivers/infiniband/core/uverbs_std_types_mr.c | 117 +-
include/uapi/rdma/ib_user_ioctl_cmds.h| 14 +++
2 files changed, 129 insertions(+), 2 deletions(-)
diff --git a/drivers/infiniband/core/uverbs_std_types_mr.c
b/drivers/infiniband/core/uverbs_std_types_mr.c
index dc58564..4660c76 100644
--- a/drivers/infiniband/core/uverbs_std_types_mr.c
+++ b/drivers/infiniband/core/uverbs_std_types_mr.c
@@ -1,5 +1,6 @@
/*
* Copyright (c) 2018, Mellanox Technologies inc. All rights reserved.
+ * Copyright (c) 2020, Intel Corporation. All rights reserved.
*
* This software is available to you under a choice of one of two
* licenses. You may choose to be licensed under the terms of the GNU
@@ -182,6 +183,86 @@ static int UVERBS_HANDLER(UVERBS_METHOD_QUERY_MR)(
return IS_UVERBS_COPY_ERR(ret) ? ret : 0;
}
+static int UVERBS_HANDLER(UVERBS_METHOD_REG_DMABUF_MR)(
+ struct uverbs_attr_bundle *attrs)
+{
+ struct ib_uobject *uobj =
+ uverbs_attr_get_uobject(attrs,
UVERBS_ATTR_REG_DMABUF_MR_HANDLE);
+ struct ib_pd *pd =
+ uverbs_attr_get_obj(attrs, UVERBS_ATTR_REG_DMABUF_MR_PD_HANDLE);
+ struct ib_device *ib_dev = pd->device;
+
+ u64 offset, length, virt_addr;
+ u32 fd, access_flags;
+ struct ib_mr *mr;
+ int ret;
+
+ if (!ib_dev->ops.reg_user_mr_dmabuf)
+ return -EOPNOTSUPP;
+
+ if (!(pd->device->attrs.device_cap_flags & IB_DEVICE_ON_DEMAND_PAGING))
+ return -EOPNOTSUPP;
+
+ ret = uverbs_copy_from(&offset, attrs,
+ UVERBS_ATTR_REG_DMABUF_MR_OFFSET);
+ if (ret)
+ return ret;
+
+ ret = uverbs_copy_from(&length, attrs,
+ UVERBS_ATTR_REG_DMABUF_MR_LENGTH);
+ if (ret)
+ return ret;
+
+ ret = uverbs_copy_from(&virt_addr, attrs,
+ UVERBS_ATTR_REG_DMABUF_MR_IOVA);
+ if (ret)
+ return ret;
+
+ ret = uverbs_copy_from(&fd, attrs,
+ UVERBS_ATTR_REG_DMABUF_MR_FD);
+ if (ret)
+ return ret;
+
+ ret = uverbs_get_flags32(&access_flags, attrs,
+UVERBS_ATTR_REG_DMABUF_MR_ACCESS_FLAGS,
+IB_ACCESS_LOCAL_WRITE |
+IB_ACCESS_REMOTE_READ |
+IB_ACCESS_REMOTE_WRITE |
+IB_ACCESS_REMOTE_ATOMIC |
+IB_ACCESS_RELAXED_ORDERING);
+ if (ret)
+ return ret;
+
+ ret = ib_check_mr_access(access_flags);
+ if (ret)
+ return ret;
+
+ mr = pd->device->ops.reg_user_mr_dmabuf(pd, offset, length, virt_addr,
+ fd, access_flags,
+ &attrs->driver_udata);
+ if (IS_ERR(mr))
+ return PTR_ERR(mr);
+
+ mr->device = pd->device;
+ mr->pd = pd;
+ mr->type = IB_MR_TYPE_USER;
+ mr->uobject = uobj;
+ atomic_inc(&pd->usecnt);
+
+ uobj->object = mr;
+
+ uverbs_finalize_uobj_create(attrs, UVERBS_ATTR_REG_DMABUF_MR_HANDLE);
+
+ ret = uverbs_copy_to(attrs, UVERBS_ATTR_REG_DMABUF_MR_RESP_LKEY,
+&mr->lkey, sizeof(mr->lkey));
+ if (ret)
+ return ret;
+
+ ret = uverbs_copy_to(attrs, UVERBS_ATTR_REG_DMABUF_MR_RESP_RKEY,
+&mr->rkey, sizeof(mr->rkey));
+ return ret;
+}
+
DECLARE_UVERBS_NAMED_METHOD(
UVERBS_METHOD_ADVISE_MR,
UVERBS_ATTR_IDR(UVERBS_ATTR_ADVISE_MR_PD_HANDLE,
@@ -247,6 +328,37 @@ static int UVERBS_HANDLER(UVERBS_METHOD_QUERY_MR)(
UVERBS_ATTR_TYPE(u32),
UA_MANDATORY));
+DECLARE_UVERBS_NAMED_METHOD(
+ UVERBS_METHOD_REG_DMABUF_MR,
+ UVERBS_ATTR_IDR(UVERBS_ATTR_REG_DMABUF_MR_HANDLE,
+ UVERBS_OBJECT_MR,
+ UVERBS_ACCESS_NEW,
+ UA_MANDATORY),
+ UVERBS_ATTR_IDR(UVERBS_ATTR_REG_DMABUF_MR_PD_HANDLE,
+ UVERBS_OBJECT_PD,
+ UVERBS_ACCESS_READ,
+ UA_MANDATORY),
+ UVERBS_ATTR_PTR_IN(UVERBS_ATTR_REG_DMABUF_MR_OFFSET,
+ UVERBS_ATTR_TYPE(u64),
+ UA_MANDATORY),
+ UVERBS_ATTR_PTR_IN(UVERBS_ATTR_REG_DMABUF_MR_LENGTH,
+ UVERBS_ATTR_TYPE(u64),
+ UA_MANDATORY),
+ UVERBS_ATTR_PTR_IN(UVERBS_ATTR_REG_DMABUF_MR_IOVA,
+ UVERBS_ATTR_TYPE
[PATCH v13 0/4] RDMA: Add dma-buf support
This is the thirteenth version of the patch set. Changelog: v13: * Rebase to the latest linux-rdma 'for-next' branch (5.10.0-rc6+) * Check for device on-demand paging capability at the entry point of the new verbs command to avoid calling device's reg_user_mr_dmabuf() method when CONFIG_INFINIBAND_ON_DEMAND_PAGING is diabled. v12: https://www.spinics.net/lists/linux-rdma/msg97943.html * Move the prototype of function ib_umem_dmabuf_release() to ib_umem.h and remove umem_dmabuf.h * Break a line that is too long v11: https://www.spinics.net/lists/linux-rdma/msg97860.html * Rework the parameter checking code inside ib_umem_dmabuf_get() * Fix incorrect error handling in the new verbs command handler * Put a duplicated code sequence for checking iova and setting page size into a function * In the invalidation callback, check for if the buffer has been mapped and thus the presence of a valid driver mr is ensured * The patch that checks for dma_virt_ops is dropped because it is no longer needed * The patch that documents that dma-buf size is fixed has landed at: https://cgit.freedesktop.org/drm/drm-misc/commit/?id=476b485be03c and thus is no longer included here * The matching user space patch set is sent separately v10: https://www.spinics.net/lists/linux-rdma/msg97483.html * Don't map the pages in ib_umem_dmabuf_get(); use the size information of the dma-buf object to validate the umem size instead * Use PAGE_SIZE directly instead of use ib_umem_find_best_pgsz() when the MR is created since the pages have not been mapped yet and dma-buf requires PAGE_SIZE anyway * Always call mlx5_umem_find_best_pgsz() after mapping the pages to verify that the page size requirement is satisfied * Add a patch to document that dma-buf size is fixed v9: https://www.spinics.net/lists/linux-rdma/msg97432.html * Clean up the code for sg list in-place modification * Prevent dma-buf pages from being mapped multiple times * Map the pages in ib_umem_dmabuf_get() so that inproper values of address/length/iova can be caught early * Check for unsupported flags in the new uverbs command * Add missing uverbs_finalize_uobj_create() * Sort uverbs objects by name * Fix formating issue -- unnecessary alignment of '=' * Unmap pages in mlx5_ib_fence_dmabuf_mr() * Remove address range checking from pagefault_dmabuf_mr() v8: https://www.spinics.net/lists/linux-rdma/msg97370.html * Modify the dma-buf sg list in place to get a proper umem sg list and restore it before calling dma_buf_unmap_attachment() * Validate the umem sg list with ib_umem_find_best_pgsz() * Remove the logic for slicing the sg list at runtime v7: https://www.spinics.net/lists/linux-rdma/msg97297.html * Rebase on top of latest mlx5 MR patch series * Slice dma-buf sg list at runtime instead of creating a new list * Preload the buffer page mapping when the MR is created * Move the 'dma_virt_ops' check into dma_buf_dynamic_attach() v6: https://www.spinics.net/lists/linux-rdma/msg96923.html * Move the dma-buf invalidation callback from the core to the device driver * Move mapping update from work queue to pagefault handler * Add dma-buf based MRs to the xarray of mmkeys so that the pagefault handler can be reached * Update the new driver method and uverbs command signature by changing the paramter 'addr' to 'offset' * Modify the sg list returned from dma_buf_map_attachment() based on the parameters 'offset' and 'length' * Don't import dma-buf if 'dma_virt_ops' is used by the dma device * The patch that clarifies dma-buf sg lists alignment has landed at https://cgit.freedesktop.org/drm/drm-misc/commit/?id=ac80cd17a615 and thus is no longer included with this set v5: https://www.spinics.net/lists/linux-rdma/msg96786.html * Fix a few warnings reported by kernel test robot: - no previous prototype for function 'ib_umem_dmabuf_release' - no previous prototype for function 'ib_umem_dmabuf_map_pages' - comparison of distinct pointer types in 'check_add_overflow' * Add comment for the wait between getting the dma-buf sg tagle and updating the NIC page table v4: https://www.spinics.net/lists/linux-rdma/msg96767.html * Add a new ib_device method reg_user_mr_dmabuf() instead of expanding the existing method reg_user_mr() * Use a separate code flow for dma-buf instead of adding special cases to the ODP memory region code path * In invalidation callback, new mapping is updated as whole using work queue instead of being updated in page granularity in the page fault handler * Use dma_resv_get_excl() and dma_fence_wait() to ensure the content of the pages have been moved to the new location before the new mapping is programmed into the NIC * Add code to the ODP page fault handler to check the mapping status * The new access flag added in v3 is removed. * The checking for on-demand paging support in the new uverbs command is removed because it is implied by implementing the new ib_device method * Clarify that dma-buf sg li
[PATCH v13 2/4] RDMA/core: Add device method for registering dma-buf based memory region
Dma-buf based memory region requires one extra parameter and is processed
quite differently. Adding a separate method allows clean separation from
regular memory regions.
Signed-off-by: Jianxin Xiong
Reviewed-by: Sean Hefty
Acked-by: Michael J. Ruhl
Acked-by: Christian Koenig
Acked-by: Daniel Vetter
---
drivers/infiniband/core/device.c | 1 +
include/rdma/ib_verbs.h | 6 +-
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/infiniband/core/device.c b/drivers/infiniband/core/device.c
index 3ab1ede..23f7440 100644
--- a/drivers/infiniband/core/device.c
+++ b/drivers/infiniband/core/device.c
@@ -2677,6 +2677,7 @@ void ib_set_device_ops(struct ib_device *dev, const
struct ib_device_ops *ops)
SET_DEVICE_OP(dev_ops, read_counters);
SET_DEVICE_OP(dev_ops, reg_dm_mr);
SET_DEVICE_OP(dev_ops, reg_user_mr);
+ SET_DEVICE_OP(dev_ops, reg_user_mr_dmabuf);
SET_DEVICE_OP(dev_ops, req_ncomp_notif);
SET_DEVICE_OP(dev_ops, req_notify_cq);
SET_DEVICE_OP(dev_ops, rereg_user_mr);
diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
index 7bee8ab..fa3882b 100644
--- a/include/rdma/ib_verbs.h
+++ b/include/rdma/ib_verbs.h
@@ -2,7 +2,7 @@
/*
* Copyright (c) 2004 Mellanox Technologies Ltd. All rights reserved.
* Copyright (c) 2004 Infinicon Corporation. All rights reserved.
- * Copyright (c) 2004 Intel Corporation. All rights reserved.
+ * Copyright (c) 2004, 2020 Intel Corporation. All rights reserved.
* Copyright (c) 2004 Topspin Corporation. All rights reserved.
* Copyright (c) 2004 Voltaire Corporation. All rights reserved.
* Copyright (c) 2005 Sun Microsystems, Inc. All rights reserved.
@@ -2433,6 +2433,10 @@ struct ib_device_ops {
struct ib_mr *(*reg_user_mr)(struct ib_pd *pd, u64 start, u64 length,
u64 virt_addr, int mr_access_flags,
struct ib_udata *udata);
+ struct ib_mr *(*reg_user_mr_dmabuf)(struct ib_pd *pd, u64 offset,
+u64 length, u64 virt_addr, int fd,
+int mr_access_flags,
+struct ib_udata *udata);
int (*rereg_user_mr)(struct ib_mr *mr, int flags, u64 start, u64 length,
u64 virt_addr, int mr_access_flags,
struct ib_pd *pd, struct ib_udata *udata);
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v13 1/4] RDMA/umem: Support importing dma-buf as user memory region
Dma-buf is a standard cross-driver buffer sharing mechanism that can be
used to support peer-to-peer access from RDMA devices.
Device memory exported via dma-buf is associated with a file descriptor.
This is passed to the user space as a property associated with the
buffer allocation. When the buffer is registered as a memory region,
the file descriptor is passed to the RDMA driver along with other
parameters.
Implement the common code for importing dma-buf object and mapping
dma-buf pages.
Signed-off-by: Jianxin Xiong
Reviewed-by: Sean Hefty
Acked-by: Michael J. Ruhl
Acked-by: Christian Koenig
Acked-by: Daniel Vetter
Conflicts:
include/rdma/ib_umem.h
---
drivers/infiniband/core/Makefile | 2 +-
drivers/infiniband/core/umem.c| 3 +
drivers/infiniband/core/umem_dmabuf.c | 173 ++
include/rdma/ib_umem.h| 43 -
4 files changed, 219 insertions(+), 2 deletions(-)
create mode 100644 drivers/infiniband/core/umem_dmabuf.c
diff --git a/drivers/infiniband/core/Makefile b/drivers/infiniband/core/Makefile
index ccf2670..8ab4eea 100644
--- a/drivers/infiniband/core/Makefile
+++ b/drivers/infiniband/core/Makefile
@@ -40,5 +40,5 @@ ib_uverbs-y :=uverbs_main.o
uverbs_cmd.o uverbs_marshall.o \
uverbs_std_types_srq.o \
uverbs_std_types_wq.o \
uverbs_std_types_qp.o
-ib_uverbs-$(CONFIG_INFINIBAND_USER_MEM) += umem.o
+ib_uverbs-$(CONFIG_INFINIBAND_USER_MEM) += umem.o umem_dmabuf.o
ib_uverbs-$(CONFIG_INFINIBAND_ON_DEMAND_PAGING) += umem_odp.o
diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c
index 7ca4112..cc131f8 100644
--- a/drivers/infiniband/core/umem.c
+++ b/drivers/infiniband/core/umem.c
@@ -2,6 +2,7 @@
* Copyright (c) 2005 Topspin Communications. All rights reserved.
* Copyright (c) 2005 Cisco Systems. All rights reserved.
* Copyright (c) 2005 Mellanox Technologies. All rights reserved.
+ * Copyright (c) 2020 Intel Corporation. All rights reserved.
*
* This software is available to you under a choice of one of two
* licenses. You may choose to be licensed under the terms of the GNU
@@ -278,6 +279,8 @@ void ib_umem_release(struct ib_umem *umem)
{
if (!umem)
return;
+ if (umem->is_dmabuf)
+ return ib_umem_dmabuf_release(to_ib_umem_dmabuf(umem));
if (umem->is_odp)
return ib_umem_odp_release(to_ib_umem_odp(umem));
diff --git a/drivers/infiniband/core/umem_dmabuf.c
b/drivers/infiniband/core/umem_dmabuf.c
new file mode 100644
index 000..e50b955
--- /dev/null
+++ b/drivers/infiniband/core/umem_dmabuf.c
@@ -0,0 +1,173 @@
+// SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause)
+/*
+ * Copyright (c) 2020 Intel Corporation. All rights reserved.
+ */
+
+#include
+#include
+#include
+
+#include "uverbs.h"
+
+int ib_umem_dmabuf_map_pages(struct ib_umem_dmabuf *umem_dmabuf)
+{
+ struct sg_table *sgt;
+ struct scatterlist *sg;
+ struct dma_fence *fence;
+ unsigned long start, end, cur;
+ unsigned int nmap;
+ int i;
+
+ dma_resv_assert_held(umem_dmabuf->attach->dmabuf->resv);
+
+ if (umem_dmabuf->sgt)
+ return 0;
+
+ sgt = dma_buf_map_attachment(umem_dmabuf->attach, DMA_BIDIRECTIONAL);
+ if (IS_ERR(sgt))
+ return PTR_ERR(sgt);
+
+ /* modify the sg list in-place to match umem address and length */
+
+ start = ALIGN_DOWN(umem_dmabuf->umem.address, PAGE_SIZE);
+ end = ALIGN(umem_dmabuf->umem.address + umem_dmabuf->umem.length,
+ PAGE_SIZE);
+ cur = 0;
+ nmap = 0;
+ for_each_sgtable_dma_sg(sgt, sg, i) {
+ if (start < cur + sg_dma_len(sg) && cur < end)
+ nmap++;
+ if (cur <= start && start < cur + sg_dma_len(sg)) {
+ unsigned long offset = start - cur;
+
+ umem_dmabuf->first_sg = sg;
+ umem_dmabuf->first_sg_offset = offset;
+ sg_dma_address(sg) += offset;
+ sg_dma_len(sg) -= offset;
+ cur += offset;
+ }
+ if (cur < end && end <= cur + sg_dma_len(sg)) {
+ unsigned long trim = cur + sg_dma_len(sg) - end;
+
+ umem_dmabuf->last_sg = sg;
+ umem_dmabuf->last_sg_trim = trim;
+ sg_dma_len(sg) -= trim;
+ break;
+ }
+ cur += sg_dma_len(sg);
+ }
+
+ umem_dmabuf->umem.sg_head.sgl = umem_dmabuf->first_sg;
+ umem_dmabuf->umem.sg_head.nents = nmap;
+ umem_dmabuf->umem.nmap = nmap;
+ umem_dmabuf->sgt = sgt;
+
+ /*
+* Although the sg list is valid now, the content of the pages
+* may be not up-to-d
[PATCH v13 4/4] RDMA/mlx5: Support dma-buf based userspace memory region
Implement the new driver method 'reg_user_mr_dmabuf'. Utilize the core
functions to import dma-buf based memory region and update the mappings.
Add code to handle dma-buf related page fault.
Signed-off-by: Jianxin Xiong
Reviewed-by: Sean Hefty
Acked-by: Michael J. Ruhl
Acked-by: Christian Koenig
Acked-by: Daniel Vetter
---
drivers/infiniband/hw/mlx5/main.c| 2 +
drivers/infiniband/hw/mlx5/mlx5_ib.h | 18 +
drivers/infiniband/hw/mlx5/mr.c | 128 +--
drivers/infiniband/hw/mlx5/odp.c | 86 +--
4 files changed, 225 insertions(+), 9 deletions(-)
diff --git a/drivers/infiniband/hw/mlx5/main.c
b/drivers/infiniband/hw/mlx5/main.c
index 4a054eb..c025746 100644
--- a/drivers/infiniband/hw/mlx5/main.c
+++ b/drivers/infiniband/hw/mlx5/main.c
@@ -1,6 +1,7 @@
// SPDX-License-Identifier: GPL-2.0 OR Linux-OpenIB
/*
* Copyright (c) 2013-2020, Mellanox Technologies inc. All rights reserved.
+ * Copyright (c) 2020, Intel Corporation. All rights reserved.
*/
#include
@@ -4069,6 +4070,7 @@ static int mlx5_ib_enable_driver(struct ib_device *dev)
.query_srq = mlx5_ib_query_srq,
.query_ucontext = mlx5_ib_query_ucontext,
.reg_user_mr = mlx5_ib_reg_user_mr,
+ .reg_user_mr_dmabuf = mlx5_ib_reg_user_mr_dmabuf,
.req_notify_cq = mlx5_ib_arm_cq,
.rereg_user_mr = mlx5_ib_rereg_user_mr,
.resize_cq = mlx5_ib_resize_cq,
diff --git a/drivers/infiniband/hw/mlx5/mlx5_ib.h
b/drivers/infiniband/hw/mlx5/mlx5_ib.h
index 718e59f..6f4d1b4 100644
--- a/drivers/infiniband/hw/mlx5/mlx5_ib.h
+++ b/drivers/infiniband/hw/mlx5/mlx5_ib.h
@@ -1,6 +1,7 @@
/* SPDX-License-Identifier: GPL-2.0 OR Linux-OpenIB */
/*
* Copyright (c) 2013-2020, Mellanox Technologies inc. All rights reserved.
+ * Copyright (c) 2020, Intel Corporation. All rights reserved.
*/
#ifndef MLX5_IB_H
@@ -704,6 +705,12 @@ static inline bool is_odp_mr(struct mlx5_ib_mr *mr)
mr->umem->is_odp;
}
+static inline bool is_dmabuf_mr(struct mlx5_ib_mr *mr)
+{
+ return IS_ENABLED(CONFIG_INFINIBAND_ON_DEMAND_PAGING) && mr->umem &&
+ mr->umem->is_dmabuf;
+}
+
struct mlx5_ib_mw {
struct ib_mwibmw;
struct mlx5_core_mkey mmkey;
@@ -1239,6 +1246,10 @@ int mlx5_ib_create_cq(struct ib_cq *ibcq, const struct
ib_cq_init_attr *attr,
struct ib_mr *mlx5_ib_reg_user_mr(struct ib_pd *pd, u64 start, u64 length,
u64 virt_addr, int access_flags,
struct ib_udata *udata);
+struct ib_mr *mlx5_ib_reg_user_mr_dmabuf(struct ib_pd *pd, u64 start,
+u64 length, u64 virt_addr,
+int fd, int access_flags,
+struct ib_udata *udata);
int mlx5_ib_advise_mr(struct ib_pd *pd,
enum ib_uverbs_advise_mr_advice advice,
u32 flags,
@@ -1249,11 +1260,13 @@ int mlx5_ib_advise_mr(struct ib_pd *pd,
int mlx5_ib_dealloc_mw(struct ib_mw *mw);
int mlx5_ib_update_xlt(struct mlx5_ib_mr *mr, u64 idx, int npages,
int page_shift, int flags);
+int mlx5_ib_update_mr_pas(struct mlx5_ib_mr *mr, unsigned int flags);
struct mlx5_ib_mr *mlx5_ib_alloc_implicit_mr(struct mlx5_ib_pd *pd,
struct ib_udata *udata,
int access_flags);
void mlx5_ib_free_implicit_mr(struct mlx5_ib_mr *mr);
void mlx5_ib_fence_odp_mr(struct mlx5_ib_mr *mr);
+void mlx5_ib_fence_dmabuf_mr(struct mlx5_ib_mr *mr);
int mlx5_ib_rereg_user_mr(struct ib_mr *ib_mr, int flags, u64 start,
u64 length, u64 virt_addr, int access_flags,
struct ib_pd *pd, struct ib_udata *udata);
@@ -1341,6 +1354,7 @@ int mlx5_ib_advise_mr_prefetch(struct ib_pd *pd,
enum ib_uverbs_advise_mr_advice advice,
u32 flags, struct ib_sge *sg_list, u32 num_sge);
int mlx5_ib_init_odp_mr(struct mlx5_ib_mr *mr, bool enable);
+int mlx5_ib_init_dmabuf_mr(struct mlx5_ib_mr *mr);
#else /* CONFIG_INFINIBAND_ON_DEMAND_PAGING */
static inline void mlx5_ib_internal_fill_odp_caps(struct mlx5_ib_dev *dev)
{
@@ -1366,6 +1380,10 @@ static inline int mlx5_ib_init_odp_mr(struct mlx5_ib_mr
*mr, bool enable)
{
return -EOPNOTSUPP;
}
+static inline int mlx5_ib_init_dmabuf_mr(struct mlx5_ib_mr *mr)
+{
+ return -EOPNOTSUPP;
+}
#endif /* CONFIG_INFINIBAND_ON_DEMAND_PAGING */
extern const struct mmu_interval_notifier_ops mlx5_mn_ops;
diff --git a/drivers/infiniband/hw/mlx5/mr.c b/drivers/infiniband/hw/mlx5/mr.c
index b6116f6..e3be1f5 100644
--- a/drivers/infiniband/hw/mlx5/mr.c
+++ b/drivers/infiniband/hw/mlx5/mr.c
@@ -1,5 +1,6 @@
/*
* Copyright (c) 2013-2015, Mellanox Technologies. All rights reserved.
+ * Copyright (c) 2020, Intel Corporation. Al
Re: [PATCH] drm/amdgpu: make DRM_AMD_DC x86-only again
On Mon, Dec 7, 2020 at 9:50 PM Christian König wrote: > Am 07.12.20 um 21:47 schrieb Alex Deucher: > > On Fri, Dec 4, 2020 at 3:13 AM Arnd Bergmann wrote: > >> From: Arnd Bergmann > >> > >> As the DRM_AMD_DC_DCN3_0 code was x86-only and fails to build on > >> arm64, merging it into DRM_AMD_DC means that the top-level symbol > >> is now x86-only as well. > >> > >> Compilation fails on arm64 with clang-12 with > >> > >> drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn30/display_mode_vba_30.c:3641:6: > >> error: stack frame size of 2416 bytes in function > >> 'dml30_ModeSupportAndSystemConfigurationFull' > >> [-Werror,-Wframe-larger-than=] > >> void dml30_ModeSupportAndSystemConfigurationFull(struct display_mode_lib > >> *mode_lib) > >> > >> I tried to see if the stack usage can be reduced, but this is code > >> that is described as "This file is gcc-parsable HW gospel, coming > >> straight from HW engineers." and is written in a way that is inherently > >> nonportable and not meant to be understood by humans. > >> > >> There are probably no non-x86 users of this code, so simplify > >> the dependency list accordingly. > > + Daniel, Timothy > > > > Others contributed code to enable this on PPC64 and ARM64. > > Unfortunately, we don't have these platforms to test with within AMD. > > Does PPC64 have the same stack limitations as ARM64? Harry, Leo, can > > you take a look at fixing the stack usage? > > This reminds me that I wanted to reply on this. > > 2416 is even to much on x86 if you add -Werror :) > > So this needs to be fixed anyway. Right, looking at my latest randconfig logs, I see the same problem on x86 builds with clang as well, though I'm not entirely sure which other configuration options are needed to trigger it. So my patch can be disregarded, but I agree this needs a better fix, either in clang or in the dcn driver. Arnd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH] dma-buf: Fix kerneldoc formatting
>-Original Message-
>From: dri-devel On Behalf Of
>Daniel Vetter
>Sent: Friday, December 4, 2020 3:03 PM
>To: DRI Development
>Cc: Daniel Vetter ; Vetter, Daniel
>
>Subject: [PATCH] dma-buf: Fix kerneldoc formatting
>
>I wanted to look up something and noticed the hyperlink doesn't work.
>While fixing that also noticed a trivial kerneldoc comment typo in the
>same section, fix that too.
>
>Signed-off-by: Daniel Vetter
>---
> Documentation/driver-api/dma-buf.rst | 2 +-
> include/linux/dma-buf-map.h | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
>diff --git a/Documentation/driver-api/dma-buf.rst b/Documentation/driver-
>api/dma-buf.rst
>index d6b2a195dbed..a2133d69872c 100644
>--- a/Documentation/driver-api/dma-buf.rst
>+++ b/Documentation/driver-api/dma-buf.rst
>@@ -190,7 +190,7 @@ DMA Fence uABI/Sync File
> Indefinite DMA Fences
> ~
>
>-At various times &dma_fence with an indefinite time until dma_fence_wait()
>+At various times struct dma_fence with an indefinite time until
>dma_fence_wait()
> finishes have been proposed. Examples include:
>
> * Future fences, used in HWC1 to signal when a buffer isn't used by the
>display
>diff --git a/include/linux/dma-buf-map.h b/include/linux/dma-buf-map.h
Ahh, something to do while compiling...
Both changes look good to me.
Reviewed-by: Michael J. Ruhl
M
>index 583a3a1f9447..278d489e4bdd 100644
>--- a/include/linux/dma-buf-map.h
>+++ b/include/linux/dma-buf-map.h
>@@ -122,7 +122,7 @@ struct dma_buf_map {
>
> /**
> * DMA_BUF_MAP_INIT_VADDR - Initializes struct dma_buf_map to an
>address in system memory
>- * @vaddr:A system-memory address
>+ * @vaddr_: A system-memory address
> */
> #define DMA_BUF_MAP_INIT_VADDR(vaddr_) \
> { \
>--
>2.29.2
>
>___
>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 4/5] drm/scheduler: Job timeout handler returns status (v2)
On 2020-12-04 3:13 a.m., Christian König wrote:
> Thinking more about that I came to the conclusion that the whole
> approach here isn't correct.
>
> See even when the job has been completed or canceled we still want to
> restart the timer.
>
> The reason for this is that the timer is then not restarted for the
> current job, but for the next job in the queue.
Got it. I'll make that change in patch 5/5 as this patch, 4/5,
only changes the timer timeout function from void to enum, and
doesn't affect behaviour.
> The only valid reason to not restart the timer is that the whole device
> was hot plugged and we return -ENODEV here. E.g. what Andrey has been
> working on.
Yes, perhaps something like DRM_TASK_STATUS_ENODEV.
We can add it now or later when Andrey adds his
hotplug/unplug patches.
Regards,
Luben
>
> Regards,
> Christian.
>
> Am 04.12.20 um 04:17 schrieb Luben Tuikov:
>> The driver's job timeout handler now returns
>> status indicating back to the DRM layer whether
>> the task (job) was successfully aborted or whether
>> more time should be given to the task to complete.
>>
>> Default behaviour as of this patch, is preserved,
>> except in obvious-by-comment case in the Panfrost
>> driver, as documented below.
>>
>> All drivers which make use of the
>> drm_sched_backend_ops' .timedout_job() callback
>> have been accordingly renamed and return the
>> would've-been default value of
>> DRM_TASK_STATUS_ALIVE to restart the task's
>> timeout timer--this is the old behaviour, and
>> is preserved by this patch.
>>
>> In the case of the Panfrost driver, its timedout
>> callback correctly first checks if the job had
>> completed in due time and if so, it now returns
>> DRM_TASK_STATUS_COMPLETE to notify the DRM layer
>> that the task can be moved to the done list, to be
>> freed later. In the other two subsequent checks,
>> the value of DRM_TASK_STATUS_ALIVE is returned, as
>> per the default behaviour.
>>
>> A more involved driver's solutions can be had
>> in subequent patches.
>>
>> Signed-off-by: Luben Tuikov
>> Reported-by: kernel test robot
>>
>> Cc: Alexander Deucher
>> Cc: Andrey Grodzovsky
>> Cc: Christian König
>> Cc: Daniel Vetter
>> Cc: Lucas Stach
>> Cc: Russell King
>> Cc: Christian Gmeiner
>> Cc: Qiang Yu
>> Cc: Rob Herring
>> Cc: Tomeu Vizoso
>> Cc: Steven Price
>> Cc: Alyssa Rosenzweig
>> Cc: Eric Anholt
>>
>> v2: Use enum as the status of a driver's job
>> timeout callback method.
>> ---
>> drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 6 +++--
>> drivers/gpu/drm/etnaviv/etnaviv_sched.c | 10 +++-
>> drivers/gpu/drm/lima/lima_sched.c | 4 +++-
>> drivers/gpu/drm/panfrost/panfrost_job.c | 9 ---
>> drivers/gpu/drm/scheduler/sched_main.c | 4 +---
>> drivers/gpu/drm/v3d/v3d_sched.c | 32 +
>> include/drm/gpu_scheduler.h | 20 +---
>> 7 files changed, 57 insertions(+), 28 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
>> index ff48101bab55..a111326cbdde 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
>> @@ -28,7 +28,7 @@
>> #include "amdgpu.h"
>> #include "amdgpu_trace.h"
>>
>> -static void amdgpu_job_timedout(struct drm_sched_job *s_job)
>> +static enum drm_task_status amdgpu_job_timedout(struct drm_sched_job *s_job)
>> {
>> struct amdgpu_ring *ring = to_amdgpu_ring(s_job->sched);
>> struct amdgpu_job *job = to_amdgpu_job(s_job);
>> @@ -41,7 +41,7 @@ static void amdgpu_job_timedout(struct drm_sched_job
>> *s_job)
>> amdgpu_ring_soft_recovery(ring, job->vmid, s_job->s_fence->parent))
>> {
>> DRM_ERROR("ring %s timeout, but soft recovered\n",
>>s_job->sched->name);
>> -return;
>> +return DRM_TASK_STATUS_ALIVE;
>> }
>>
>> amdgpu_vm_get_task_info(ring->adev, job->pasid, &ti);
>> @@ -53,10 +53,12 @@ static void amdgpu_job_timedout(struct drm_sched_job
>> *s_job)
>>
>> if (amdgpu_device_should_recover_gpu(ring->adev)) {
>> amdgpu_device_gpu_recover(ring->adev, job);
>> +return DRM_TASK_STATUS_ALIVE;
>> } else {
>> drm_sched_suspend_timeout(&ring->sched);
>> if (amdgpu_sriov_vf(adev))
>> adev->virt.tdr_debug = true;
>> +return DRM_TASK_STATUS_ALIVE;
>> }
>> }
>>
>> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
>> b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
>> index cd46c882269c..c49516942328 100644
>> --- a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
>> +++ b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
>> @@ -82,7 +82,8 @@ static struct dma_fence *etnaviv_sched_run_job(struct
>> drm_sched_job *sched_job)
>> return fence;
>> }
>>
>> -static void etnaviv_sched_timedout_job(struct drm_sched_job *sched_job)
>> +static enum drm_task_status etnaviv_sched
[pull] drm/msm: msm-next for 5.11
Hi Dave,
This time around:
* Shutdown hook for GPU (to ensure GPU is idle before iommu goes away)
* GPU cooling device support
* DSI 7nm and 10nm phy/pll updates
* Additional sm8150/sm8250 DPU support (merge_3d and DSPP color
processing)
* Various DP fixes
* A whole bunch of W=1 fixes from Lee Jones
* GEM locking re-work (no more trylock_recursive in shrinker!)
* LLCC (system cache) support
* Various other fixes/cleanups
Note that there is a merge commit for branch also based on v5.10-rc1 that
was also merged into arm-smmu tree for v5.11 to handle a shared dependency
for LLCC support.
The following changes since commit 3650b228f83adda7e5ee532e2b90429c03f7b9ec:
Linux 5.10-rc1 (2020-10-25 15:14:11 -0700)
are available in the Git repository at:
https://gitlab.freedesktop.org/drm/msm.git tags/drm-msm-next-2020-12-07
for you to fetch changes up to e319a1b956f785f618611857cd946dca2bb68542:
drm/msm: add IOMMU_SUPPORT dependency (2020-12-05 08:25:52 -0800)
Abhinav Kumar (2):
drm/msm/dp: do not notify audio subsystem if sink doesn't support audio
drm/msm/dpu: update the qos remap only if the client type changes
Akhil P Oommen (4):
drm/msm: Implement shutdown callback for adreno
drm/msm: Fix duplicate gpu node in icc summary
drm/msm: Add support for GPU cooling
dt-bindings: drm/msm/gpu: Add cooling device support
Arnd Bergmann (1):
drm/msm: add IOMMU_SUPPORT dependency
Dmitry Baryshkov (12):
drm/msm/dsi_pll_7nm: restore VCO rate during restore_state
drm/msm/dsi_pll_10nm: restore VCO rate during restore_state
drm/msm/dsi_phy_7nm: implement PHY disabling
drm/msm/dsi_phy_10nm: implement PHY disabling
drm/msm/dpu: simplify interface flush handling
drm/msm/dpu: initial support for merge3D hardware block
drm/msm/dpu: handle merge_3d configuration in hw_ctl block
drm/msm/dpu: setup merge modes in merge_3d block
drm/msm/dpu: enable merge_3d support on sm8150/sm8250
drm/msm/dpu: fix clock scaling on non-sc7180 board
drm/msm/dsi: do not try reading 28nm vco rate if it's not enabled
drm/msm/dpu: enable DSPP support on SM8[12]50
Iskren Chernev (1):
drm/msm: Fix use-after-free in msm_gem with carveout
Jordan Crouse (1):
drm/msm/a6xx: Add support for using system cache on MMU500 based targets
Kalyan Thota (1):
drm/msm/dpu: consider vertical front porch in the prefill bw calculation
Krishna Manikandan (1):
drm/msm: Fix race condition in msm driver with async layer updates
Kuogee Hsieh (7):
drm/msm/dp: add opp_table corner voting support base on dp_ink_clk rate
drm/msm/dp: return correct connection status after suspend
drm/msm/dp: fixes wrong connection state caused by failure of link train
drm/msm/dp: deinitialize mainlink if link training failed
drm/msm/dp: skip checking LINK_STATUS_UPDATED bit
drm/msm/dp: promote irq_hpd handle to handle link training correctly
drm/msm/dp: fix connect/disconnect handled at irq_hpd
Lee Jones (21):
drm/msm/adreno/a6xx_gpu: Staticise local function 'a6xx_idle'
drm/msm/disp/mdp5/mdp5_crtc: Make local function
'mdp5_crtc_setup_pipeline()' static
drm/msm/disp/mdp5/mdp5_kms: Make local functions 'mdp5_{en,
dis}able()' static
drm/msm/disp/dpu1/dpu_core_perf: Remove set but unused variable
'dpu_cstate'
drm/msm/disp/dpu1/dpu_encoder: Remove a bunch of unused variables
drm/msm/disp/dpu1/dpu_core_perf: Fix kernel-doc formatting issues
drm/msm/disp/dpu1/dpu_hw_blk: Add one missing and remove an
extra param description
drm/msm/disp/dpu1/dpu_formats: Demote non-conformant kernel-doc header
drm/msm/disp/dpu1/dpu_hw_catalog: Remove duplicated
initialisation of 'max_linewidth'
drm/msm/disp/dpu1/dpu_hw_catalog: Move definitions to the only
place they are used
drm/msm/disp/dpu1/dpu_encoder: Fix a few parameter/member
formatting issues
drm/msm/disp/dpu1/dpu_hw_lm: Fix misnaming of parameter 'ctx'
drm/msm/disp/dpu1/dpu_hw_sspp: Fix kernel-doc formatting abuse
drm/msm/disp/dpu1/dpu_rm: Fix formatting issues and supply
'global_state' description
drm/msm/disp/dpu1/dpu_vbif: Fix a couple of function param descriptions
drm/msm/disp/dpu1/dpu_plane: Fix some spelling and missing
function param descriptions
drm/msm/msm_drv: Make '_msm_ioremap()' static
drm/msm/msm_gem_shrinker: Fix descriptions for 'drm_device'
drm/msm/adreno/a6xx_gpu_state: Make some local functions static
drm/msm/dp/dp_ctrl: Move 'tu' from the stack to the heap
drm/msm/disp/dpu1/dpu_hw_interrupts: Demote kernel-doc formatting misuse
Marijn Suijten (1):
drm/msm: a5xx: Make preemption reset case reentrant
Rikard Falkeborn (1):
drm/msm: dsi: Constify dsi_host_ops
Rob Clark (33):
drm/msm/atomic: Drop per-CRTC locks in reverse order
d
Re: [PATCH v2 6/6] dt-binding: display: mantix: Add compatible for panel from YS
On Wed, 18 Nov 2020 09:29:53 +0100, Guido Günther wrote: > This panel from Shenzhen Yashi Changhua Intelligent Technology Co > uses the same driver IC but a different LCD. > > Signed-off-by: Guido Günther > Reviewed-by: Linus Walleij > --- > .../devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml | 1 + > 1 file changed, 1 insertion(+) > Acked-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 5/6] dt-bindings: vendor-prefixes: Add ys vendor prefix
On Wed, Nov 18, 2020 at 09:29:52AM +0100, Guido Günther wrote: > Add prefix for Shenzhen Yashi Changhua Intelligent Technology Co., Ltd. > > Signed-off-by: Guido Günther > --- > Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ > 1 file changed, 2 insertions(+) Acked-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vboxvideo: Used the vram helper
Hi Tian,
I love your patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v5.10-rc7 next-20201207]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Tian-Tao/drm-vboxvideo-Used-the-vram-helper/20201127-112000
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
85a2c56cb4454c73f56d3099d96942e7919b292f
config: i386-randconfig-r031-20201207 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce (this is a W=1 build):
#
https://github.com/0day-ci/linux/commit/f3abc53a9794f39d04b604a243d28be17a88571f
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Tian-Tao/drm-vboxvideo-Used-the-vram-helper/20201127-112000
git checkout f3abc53a9794f39d04b604a243d28be17a88571f
# save the attached .config to linux build tree
make W=1 ARCH=i386
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
drivers/gpu/drm/vboxvideo/vbox_ttm.c: In function 'vbox_mm_init':
>> drivers/gpu/drm/vboxvideo/vbox_ttm.c:19:6: warning: assignment to 'struct
>> drm_vram_mm *' from 'int' makes pointer from integer without a cast
>> [-Wint-conversion]
19 | vmm = drmm_vram_helper_init(dev, pci_resource_start(dev->pdev, 0),
| ^
vim +19 drivers/gpu/drm/vboxvideo/vbox_ttm.c
12
13 int vbox_mm_init(struct vbox_private *vbox)
14 {
15 struct drm_vram_mm *vmm;
16 int ret;
17 struct drm_device *dev = &vbox->ddev;
18
> 19 vmm = drmm_vram_helper_init(dev, pci_resource_start(dev->pdev,
0),
20 vbox->available_vram_size);
21 if (IS_ERR(vmm)) {
22 ret = PTR_ERR(vmm);
23 DRM_ERROR("Error initializing VRAM MM; %d\n", ret);
24 return ret;
25 }
26
27 vbox->fb_mtrr = arch_phys_wc_add(pci_resource_start(dev->pdev,
0),
28 pci_resource_len(dev->pdev,
0));
29 return 0;
30 }
31
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 10/11] dt-bindings: usb: convert mediatek,mtu3.txt to YAML schema
On Wed, Nov 18, 2020 at 04:21:25PM +0800, Chunfeng Yun wrote:
> Convert mediatek,mtu3.txt to YAML schema mediatek,mtu3.yaml
>
> Signed-off-by: Chunfeng Yun
> ---
> v3:
> 1. fix yamllint warning
> 2. remove pinctrl* properties
> 3. remove unnecessary '|'
> 4. drop unused labels in example
>
> v2: new patch
> ---
> .../devicetree/bindings/usb/mediatek,mtu3.txt | 108 -
> .../bindings/usb/mediatek,mtu3.yaml | 218 ++
> 2 files changed, 218 insertions(+), 108 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/usb/mediatek,mtu3.txt
> create mode 100644 Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml
>
> diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt
> b/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt
> deleted file mode 100644
> index a82ca438aec1..
> --- a/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt
> +++ /dev/null
> @@ -1,108 +0,0 @@
> -The device node for Mediatek USB3.0 DRD controller
> -
> -Required properties:
> - - compatible : should be "mediatek,-mtu3", "mediatek,mtu3",
> - soc-model is the name of SoC, such as mt8173, mt2712 etc,
> - when using "mediatek,mtu3" compatible string, you need SoC specific
> - ones in addition, one of:
> - - "mediatek,mt8173-mtu3"
> - - reg : specifies physical base address and size of the registers
> - - reg-names: should be "mac" for device IP and "ippc" for IP port control
> - - interrupts : interrupt used by the device IP
> - - power-domains : a phandle to USB power domain node to control USB's
> - mtcmos
> - - vusb33-supply : regulator of USB avdd3.3v
> - - clocks : a list of phandle + clock-specifier pairs, one for each
> - entry in clock-names
> - - clock-names : must contain "sys_ck" for clock of controller,
> - the following clocks are optional:
> - "ref_ck", "mcu_ck" and "dma_ck";
> - - phys : see usb-hcd.yaml in the current directory
> - - dr_mode : should be one of "host", "peripheral" or "otg",
> - refer to usb/generic.txt
> -
> -Optional properties:
> - - #address-cells, #size-cells : should be '2' if the device has sub-nodes
> - with 'reg' property
> - - ranges : allows valid 1:1 translation between child's address space and
> - parent's address space
> - - extcon : external connector for vbus and idpin changes detection, needed
> - when supports dual-role mode.
> - it's considered valid for compatibility reasons, not allowed for
> - new bindings, and use "usb-role-switch" property instead.
> - - vbus-supply : reference to the VBUS regulator, needed when supports
> - dual-role mode.
> - it's considered valid for compatibility reasons, not allowed for
> - new bindings, and put into a usb-connector node.
> - see connector/usb-connector.yaml.
> - - pinctrl-names : a pinctrl state named "default" is optional, and need be
> - defined if auto drd switch is enabled, that means the property dr_mode
> - is set as "otg", and meanwhile the property "mediatek,enable-manual-drd"
> - is not set.
> - - pinctrl-0 : pin control group
> - See: Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
> -
> - - maximum-speed : valid arguments are "super-speed", "high-speed" and
> - "full-speed"; refer to usb/generic.txt
> - - usb-role-switch : use USB Role Switch to support dual-role switch, but
> - not extcon; see usb/generic.txt.
> - - enable-manual-drd : supports manual dual-role switch via debugfs; usually
> - used when receptacle is TYPE-A and also wants to support dual-role
> - mode.
> - - wakeup-source: enable USB remote wakeup of host mode.
> - - mediatek,syscon-wakeup : phandle to syscon used to access the register
> - of the USB wakeup glue layer between SSUSB and SPM; it depends on
> - "wakeup-source", and has two arguments:
> - - the first one : register base address of the glue layer in syscon;
> - - the second one : hardware version of the glue layer
> - - 1 : used by mt8173 etc
> - - 2 : used by mt2712 etc
> - - mediatek,u3p-dis-msk : mask to disable u3ports, bit0 for u3port0,
> - bit1 for u3port1, ... etc;
> -
> -additionally the properties from usb-hcd.yaml (in the current directory) are
> -supported.
> -
> -Sub-nodes:
> -The xhci should be added as subnode to mtu3 as shown in the following example
> -if host mode is enabled. The DT binding details of xhci can be found in:
> -Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt
> -
> -The port would be added as subnode if use "usb-role-switch" property.
> - see graph.txt
> -
> -Example:
> -ssusb: usb@11271000 {
> - compatible = "mediatek,mt8173-mtu3";
> - reg = <0 0x11271000 0 0x3000>,
> - <0 0x11280700 0 0x0100>;
> - reg-names = "mac", "ippc";
> - interrupts = ;
> - phys = <&phy_port0 PHY_TYPE_USB3>,
> -<&phy_port1 PHY_TYPE_USB2>;
> - power-domains = <&scpsys MT8173_POWER_DOMA
Re: [PATCH v3 09/11] dt-bindings: usb: convert mediatek, mtk-xhci.txt to YAML schema
On Wed, Nov 18, 2020 at 04:21:24PM +0800, Chunfeng Yun wrote:
> Convert mediatek,mtk-xhci.txt to YAML schema mediatek,mtk-xhci.yaml
>
> Signed-off-by: Chunfeng Yun
> ---
> v3:
> 1. fix yamllint warning
> 2. remove pinctrl* properties supported by default suggested by Rob
> 3. drop unused labels
> 4. modify description of mediatek,syscon-wakeup
> 5. remove type of imod-interval-ns
>
> v2: new patch
> ---
> .../bindings/usb/mediatek,mtk-xhci.txt| 121 -
> .../bindings/usb/mediatek,mtk-xhci.yaml | 171 ++
> 2 files changed, 171 insertions(+), 121 deletions(-)
> delete mode 100644
> Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt
> create mode 100644
> Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml
>
> diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt
> b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt
> deleted file mode 100644
> index 42d8814f903a..
> --- a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt
> +++ /dev/null
> @@ -1,121 +0,0 @@
> -MT8173 xHCI
> -
> -The device node for Mediatek SOC USB3.0 host controller
> -
> -There are two scenarios: the first one only supports xHCI driver;
> -the second one supports dual-role mode, and the host is based on xHCI
> -driver. Take account of backward compatibility, we divide bindings
> -into two parts.
> -
> -1st: only supports xHCI driver
> -
> -
> -Required properties:
> - - compatible : should be "mediatek,-xhci", "mediatek,mtk-xhci",
> - soc-model is the name of SoC, such as mt8173, mt2712 etc, when using
> - "mediatek,mtk-xhci" compatible string, you need SoC specific ones in
> - addition, one of:
> - - "mediatek,mt8173-xhci"
> - - reg : specifies physical base address and size of the registers
> - - reg-names: should be "mac" for xHCI MAC and "ippc" for IP port control
> - - interrupts : interrupt used by the controller
> - - power-domains : a phandle to USB power domain node to control USB's
> - mtcmos
> - - vusb33-supply : regulator of USB avdd3.3v
> -
> - - clocks : a list of phandle + clock-specifier pairs, one for each
> - entry in clock-names
> - - clock-names : must contain
> - "sys_ck": controller clock used by normal mode,
> - the following ones are optional:
> - "ref_ck": reference clock used by low power mode etc,
> - "mcu_ck": mcu_bus clock for register access,
> - "dma_ck": dma_bus clock for data transfer by DMA,
> - "xhci_ck": controller clock
> -
> - - phys : see usb-hcd.yaml in the current directory
> -
> -Optional properties:
> - - wakeup-source : enable USB remote wakeup;
> - - mediatek,syscon-wakeup : phandle to syscon used to access the register
> - of the USB wakeup glue layer between xHCI and SPM; it depends on
> - "wakeup-source", and has two arguments:
> - - the first one : register base address of the glue layer in syscon;
> - - the second one : hardware version of the glue layer
> - - 1 : used by mt8173 etc
> - - 2 : used by mt2712 etc
> - - mediatek,u3p-dis-msk : mask to disable u3ports, bit0 for u3port0,
> - bit1 for u3port1, ... etc;
> - - vbus-supply : reference to the VBUS regulator;
> - - usb3-lpm-capable : supports USB3.0 LPM
> - - pinctrl-names : a pinctrl state named "default" must be defined
> - - pinctrl-0 : pin control group
> - See: Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
> - - imod-interval-ns: default interrupt moderation interval is 5000ns
> -
> -additionally the properties from usb-hcd.yaml (in the current directory) are
> -supported.
> -
> -Example:
> -usb30: usb@1127 {
> - compatible = "mediatek,mt8173-xhci";
> - reg = <0 0x1127 0 0x1000>,
> - <0 0x11280700 0 0x0100>;
> - reg-names = "mac", "ippc";
> - interrupts = ;
> - power-domains = <&scpsys MT8173_POWER_DOMAIN_USB>;
> - clocks = <&topckgen CLK_TOP_USB30_SEL>, <&clk26m>,
> - <&pericfg CLK_PERI_USB0>,
> - <&pericfg CLK_PERI_USB1>;
> - clock-names = "sys_ck", "ref_ck";
> - phys = <&phy_port0 PHY_TYPE_USB3>,
> -<&phy_port1 PHY_TYPE_USB2>;
> - vusb33-supply = <&mt6397_vusb_reg>;
> - vbus-supply = <&usb_p1_vbus>;
> - usb3-lpm-capable;
> - mediatek,syscon-wakeup = <&pericfg 0x400 1>;
> - wakeup-source;
> - imod-interval-ns = <1>;
> -};
> -
> -2nd: dual-role mode with xHCI driver
> -
> -
> -In the case, xhci is added as subnode to mtu3. An example and the DT binding
> -details of mtu3 can be found in:
> -Documentation/devicetree/bindings/usb/mediatek,mtu3.txt
> -
> -Required properties:
> - - compatible : should be "mediatek,-xhci", "mediatek,mtk-xhci",
> - soc-model is the name of SoC, such as mt8173, mt2712 etc, when using
> - "mediatek,mtk-
Re: [PATCH v3 07/11] dt-bindings: phy: convert MIP DSI PHY binding to YAML schema
On Wed, Nov 18, 2020 at 04:21:22PM +0800, Chunfeng Yun wrote:
> Convert MIPI DSI PHY binding to YAML schema mediatek,dsi-phy.yaml
>
> Cc: Chun-Kuang Hu
> Signed-off-by: Chunfeng Yun
> ---
> v3: new patch
> ---
> .../display/mediatek/mediatek,dsi.txt | 18 +---
> .../bindings/phy/mediatek,dsi-phy.yaml| 83 +++
> 2 files changed, 84 insertions(+), 17 deletions(-)
> create mode 100644
> Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
> b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
> index f06f24d405a5..8238a86686be 100644
> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
> @@ -22,23 +22,7 @@ Required properties:
> MIPI TX Configuration Module
>
>
> -The MIPI TX configuration module controls the MIPI D-PHY.
> -
> -Required properties:
> -- compatible: "mediatek,-mipi-tx"
> -- the supported chips are mt2701, 7623, mt8173 and mt8183.
> -- reg: Physical base address and length of the controller's registers
> -- clocks: PLL reference clock
> -- clock-output-names: name of the output clock line to the DSI encoder
> -- #clock-cells: must be <0>;
> -- #phy-cells: must be <0>.
> -
> -Optional properties:
> -- drive-strength-microamp: adjust driving current, should be 3000 ~ 6000. And
> -the step is 200.
> -- nvmem-cells: A phandle to the calibration data provided by a nvmem device.
> If
> - unspecified default values shall be used.
> -- nvmem-cell-names: Should be "calibration-data"
> +See phy/mediatek,dsi-phy.yaml
>
> Example:
>
> diff --git a/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml
> b/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml
> new file mode 100644
> index ..87f8df251ab0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml
> @@ -0,0 +1,83 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +# Copyright (c) 2020 MediaTek
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/phy/mediatek,dsi-phy.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: MediaTek MIPI Display Serial Interface (DSI) PHY binding
> +
> +maintainers:
> + - Chun-Kuang Hu
> + - Chunfeng Yun
> +
> +description: The MIPI DSI PHY supports up to 4-lane output.
> +
> +properties:
> + $nodename:
> +pattern: "^dsi-phy@[0-9a-f]+$"
> +
> + compatible:
> +enum:
> + - mediatek,mt2701-mipi-tx
> + - mediatek,mt7623-mipi-tx
> + - mediatek,mt8173-mipi-tx
> +
> + reg:
> +maxItems: 1
> +
> + clocks:
> +items:
> + - description: PLL reference clock
> +
> + clock-output-names:
> +maxItems: 1
> +
> + "#phy-cells":
> +const: 0
> +
> + "#clock-cells":
> +const: 0
> +
> + nvmem-cells:
> +maxItems: 1
> +description: A phandle to the calibration data provided by a nvmem
> device,
> + if unspecified, default values shall be used.
> +
> + nvmem-cell-names:
> +items:
> + - const: calibration-data
> +
> + drive-strength-microamp:
> +description: adjust driving current, the step is 200.
multipleOf: 200
> +$ref: /schemas/types.yaml#/definitions/uint32
Can drop. Standard unit suffixes have a type already.
> +minimum: 2000
> +maximum: 6000
> +default: 4600
> +
> +required:
> + - compatible
> + - reg
> + - clocks
> + - clock-output-names
> + - "#phy-cells"
> + - "#clock-cells"
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +#include
> +dsi-phy@10215000 {
> +compatible = "mediatek,mt8173-mipi-tx";
> +reg = <0x10215000 0x1000>;
> +clocks = <&clk26m>;
> +clock-output-names = "mipi_tx0_pll";
> +drive-strength-microamp = <4000>;
> +nvmem-cells= <&mipi_tx_calibration>;
> +nvmem-cell-names = "calibration-data";
> +#clock-cells = <0>;
> +#phy-cells = <0>;
> +};
> +
> +...
> --
> 2.18.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 04/11] dt-bindings: phy: convert phy-mtk-tphy.txt to YAML schema
On Wed, 18 Nov 2020 16:21:19 +0800, Chunfeng Yun wrote: > Convert phy-mtk-tphy.txt to YAML schema mediatek,tphy.yaml > > Signed-off-by: Chunfeng Yun > --- > v3: > 1. fix dt_binding_check error in example after add mtu3.yaml > Changes suggested by Rob: > 2. fix wrong indentation > 3. remove '|' due to no formatting to preserve > 4. add a space after '#' > 5. drop unused labels and status in examples > 6. modify file mode > > v2: > 1. modify description and compatible > --- > .../bindings/phy/mediatek,tphy.yaml | 260 ++ > .../devicetree/bindings/phy/phy-mtk-tphy.txt | 162 --- > 2 files changed, 260 insertions(+), 162 deletions(-) > create mode 100644 Documentation/devicetree/bindings/phy/mediatek,tphy.yaml > delete mode 100644 Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 03/11] dt-bindings: phy: convert phy-mtk-xsphy.txt to YAML schema
On Wed, 18 Nov 2020 16:21:18 +0800, Chunfeng Yun wrote: > Convert phy-mtk-xsphy.txt to YAML schema mediatek,xsphy.yaml > > Signed-off-by: Chunfeng Yun > --- > v3: > 1. remove type for property with standard unit suffix suggested by Rob > 2. remove '|' for descritpion > 3. fix yamllint warning > > v2: > 1. modify description and compatible definition suggested by Rob > --- > .../bindings/phy/mediatek,xsphy.yaml | 199 ++ > .../devicetree/bindings/phy/phy-mtk-xsphy.txt | 109 -- > 2 files changed, 199 insertions(+), 109 deletions(-) > create mode 100644 Documentation/devicetree/bindings/phy/mediatek,xsphy.yaml > delete mode 100644 Documentation/devicetree/bindings/phy/phy-mtk-xsphy.txt > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amdgpu: make DRM_AMD_DC x86-only again
Am 07.12.20 um 21:47 schrieb Alex Deucher:
On Fri, Dec 4, 2020 at 3:13 AM Arnd Bergmann wrote:
From: Arnd Bergmann
As the DRM_AMD_DC_DCN3_0 code was x86-only and fails to build on
arm64, merging it into DRM_AMD_DC means that the top-level symbol
is now x86-only as well.
Compilation fails on arm64 with clang-12 with
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn30/display_mode_vba_30.c:3641:6:
error: stack frame size of 2416 bytes in function
'dml30_ModeSupportAndSystemConfigurationFull' [-Werror,-Wframe-larger-than=]
void dml30_ModeSupportAndSystemConfigurationFull(struct display_mode_lib
*mode_lib)
I tried to see if the stack usage can be reduced, but this is code
that is described as "This file is gcc-parsable HW gospel, coming
straight from HW engineers." and is written in a way that is inherently
nonportable and not meant to be understood by humans.
There are probably no non-x86 users of this code, so simplify
the dependency list accordingly.
+ Daniel, Timothy
Others contributed code to enable this on PPC64 and ARM64.
Unfortunately, we don't have these platforms to test with within AMD.
Does PPC64 have the same stack limitations as ARM64? Harry, Leo, can
you take a look at fixing the stack usage?
This reminds me that I wanted to reply on this.
2416 is even to much on x86 if you add -Werror :)
So this needs to be fixed anyway.
Christian.
Thanks,
Alex
Fixes: 20f2ffe50472 ("drm/amdgpu: fold CONFIG_DRM_AMD_DC_DCN3* into
CONFIG_DRM_AMD_DC_DCN (v3)")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/amd/display/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/Kconfig
b/drivers/gpu/drm/amd/display/Kconfig
index 797b5d4b43e5..54aa50d4deba 100644
--- a/drivers/gpu/drm/amd/display/Kconfig
+++ b/drivers/gpu/drm/amd/display/Kconfig
@@ -6,7 +6,7 @@ config DRM_AMD_DC
bool "AMD DC - Enable new display engine"
default y
select SND_HDA_COMPONENT if SND_HDA_CORE
- select DRM_AMD_DC_DCN if (X86 || PPC64 || (ARM64 && KERNEL_MODE_NEON)) &&
!(KCOV_INSTRUMENT_ALL && KCOV_ENABLE_COMPARISONS)
+ select DRM_AMD_DC_DCN if X86 && !(KCOV_INSTRUMENT_ALL &&
KCOV_ENABLE_COMPARISONS)
help
Choose this option if you want to use the new display engine
support for AMDGPU. This adds required support for Vega and
--
2.27.0
___
amd-gfx mailing list
amd-...@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=04%7C01%7Cchristian.koenig%40amd.com%7Cba72f82a98a4443b0dd108d89af15c1e%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C1%7C637429708726258711%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=EU1LuB3uxSCrtAw%2BgwD%2FFWsYpZMp1FbffZvkerQ7WVs%3D&reserved=0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amdgpu: make DRM_AMD_DC x86-only again
On Fri, Dec 4, 2020 at 3:13 AM Arnd Bergmann wrote:
>
> From: Arnd Bergmann
>
> As the DRM_AMD_DC_DCN3_0 code was x86-only and fails to build on
> arm64, merging it into DRM_AMD_DC means that the top-level symbol
> is now x86-only as well.
>
> Compilation fails on arm64 with clang-12 with
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn30/display_mode_vba_30.c:3641:6:
> error: stack frame size of 2416 bytes in function
> 'dml30_ModeSupportAndSystemConfigurationFull' [-Werror,-Wframe-larger-than=]
> void dml30_ModeSupportAndSystemConfigurationFull(struct display_mode_lib
> *mode_lib)
>
> I tried to see if the stack usage can be reduced, but this is code
> that is described as "This file is gcc-parsable HW gospel, coming
> straight from HW engineers." and is written in a way that is inherently
> nonportable and not meant to be understood by humans.
>
> There are probably no non-x86 users of this code, so simplify
> the dependency list accordingly.
+ Daniel, Timothy
Others contributed code to enable this on PPC64 and ARM64.
Unfortunately, we don't have these platforms to test with within AMD.
Does PPC64 have the same stack limitations as ARM64? Harry, Leo, can
you take a look at fixing the stack usage?
Thanks,
Alex
>
> Fixes: 20f2ffe50472 ("drm/amdgpu: fold CONFIG_DRM_AMD_DC_DCN3* into
> CONFIG_DRM_AMD_DC_DCN (v3)")
> Signed-off-by: Arnd Bergmann
> ---
> drivers/gpu/drm/amd/display/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/Kconfig
> b/drivers/gpu/drm/amd/display/Kconfig
> index 797b5d4b43e5..54aa50d4deba 100644
> --- a/drivers/gpu/drm/amd/display/Kconfig
> +++ b/drivers/gpu/drm/amd/display/Kconfig
> @@ -6,7 +6,7 @@ config DRM_AMD_DC
> bool "AMD DC - Enable new display engine"
> default y
> select SND_HDA_COMPONENT if SND_HDA_CORE
> - select DRM_AMD_DC_DCN if (X86 || PPC64 || (ARM64 &&
> KERNEL_MODE_NEON)) && !(KCOV_INSTRUMENT_ALL && KCOV_ENABLE_COMPARISONS)
> + select DRM_AMD_DC_DCN if X86 && !(KCOV_INSTRUMENT_ALL &&
> KCOV_ENABLE_COMPARISONS)
> help
> Choose this option if you want to use the new display engine
> support for AMDGPU. This adds required support for Vega and
> --
> 2.27.0
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 210467] amdgpu Vega 3 lock MCLK on 1200mhz
https://bugzilla.kernel.org/show_bug.cgi?id=210467 --- Comment #10 from Alexey (intervio...@gmail.com) --- Created attachment 294029 --> https://bugzilla.kernel.org/attachment.cgi?id=294029&action=edit modules info (workly) -- 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 210467] amdgpu Vega 3 lock MCLK on 1200mhz
https://bugzilla.kernel.org/show_bug.cgi?id=210467 --- Comment #9 from Alexey (intervio...@gmail.com) --- Created attachment 294027 --> https://bugzilla.kernel.org/attachment.cgi?id=294027&action=edit modinfo amdgpu (workly) (In reply to Alex Deucher from comment #8) > Can you narrow down which specific firmware? Also what what versions did > you try? workly: linux-firmware 20201023.dae4b4c-1 All new versions is bugged. Cant do build per single commits (expensive traffic). -- 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 v3 3/4] tpm_tis: Disable interrupts if interrupt storm detected
On Mon, 2020-12-07 at 15:28 -0400, Jason Gunthorpe wrote: > On Sun, Dec 06, 2020 at 08:26:16PM +0100, Thomas Gleixner wrote: > > Just as a side note. I was looking at tpm_tis_probe_irq_single() > > and that function is leaking the interrupt request if any of the > > checks afterwards fails, except for the final interrupt probe check > > which does a cleanup. That means on fail before that the interrupt > > handler stays requested up to the point where the module is > > removed. If that's a shared interrupt and some other device is > > active on the same line, then each interrupt from that device will > > call into the TPM code. Something like the below is needed. > > > > Also the X86 autoprobe mechanism is interesting: > > > > if (IS_ENABLED(CONFIG_X86)) > > for (i = 3; i <= 15; i++) > > if (!tpm_tis_probe_irq_single(chip, intmask, 0, > > i)) > > return; > > > > The third argument is 'flags' which is handed to request_irq(). So > > that won't ever be able to probe a shared interrupt. But if an > > interrupt number > 0 is handed to tpm_tis_core_init() the interrupt > > is requested with IRQF_SHARED. Same issue when the chip has an > > interrupt number in the register. It's also requested exclusive > > which is pretty likely to fail on ancient x86 machines. > > It is very likely none of this works any more, it has been repeatedly > reworked over the years and just left behind out of fear someone > needs it. I've thought it should be deleted for a while now. > > I suppose the original logic was to try and probe without SHARED > because a probe would need exclusive access to the interrupt to tell > if the TPM was actually the source, not some other device. > > It is all very old and very out of step with current thinking, IMHO. > I skeptical that TPM interrupts were ever valuable enough to deserve > this in the first place. For what it's worth, I agree. Trying to probe all 15 ISA interrupts is last millennium thinking we should completely avoid. If it's not described in ACPI then you don't get an interrupt full stop. James ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/5] drm/sched: Make use of a "done" list (v2)
On 2020-12-04 3:16 a.m., Christian König wrote:
> Am 04.12.20 um 04:17 schrieb Luben Tuikov:
>> The drm_sched_job_done() callback now moves done
>> jobs from the pending list to a "done" list.
>>
>> In drm_sched_job_timeout, make use of the status
>> returned by a GPU driver job timeout handler to
>> decide whether to leave the oldest job in the
>> pending list, or to send it off to the done list.
>> If a driver's job timeout callback returns a
>> status that that job is done, it is added to the
>> done list and the done thread woken up. If that
>> job needs more time, it is left on the pending
>> list and the timeout timer restarted.
>>
>> The idea is that a GPU driver can check the IP to
>> which the passed-in job belongs to and determine
>> whether the IP is alive and well, or if it needs
>> more time to complete this job and perhaps others
>> also executing on it.
>>
>> In drm_sched_job_timeout(), the main scheduler
>> thread is now parked, before calling a driver's
>> timeout_job callback, so as to not compete pushing
>> jobs down to the GPU while the recovery method is
>> taking place.
>>
>> Eliminate the polling mechanism of picking out done
>> jobs from the pending list, i.e. eliminate
>> drm_sched_get_cleanup_job().
>>
>> This also eliminates the eldest job disappearing
>> from the pending list, while the driver timeout
>> handler is called.
>>
>> Various other optimizations to the GPU scheduler
>> and job recovery are possible with this format.
>>
>> Signed-off-by: Luben Tuikov
>>
>> Cc: Alexander Deucher
>> Cc: Andrey Grodzovsky
>> Cc: Christian König
>> Cc: Daniel Vetter
>> Cc: Lucas Stach
>> Cc: Russell King
>> Cc: Christian Gmeiner
>> Cc: Qiang Yu
>> Cc: Rob Herring
>> Cc: Tomeu Vizoso
>> Cc: Steven Price
>> Cc: Alyssa Rosenzweig
>> Cc: Eric Anholt
>>
>> v2: Dispell using a done thread, so as to keep
>> the cache hot on the same processor.
>> ---
>> drivers/gpu/drm/scheduler/sched_main.c | 247 +
>> include/drm/gpu_scheduler.h| 4 +
>> 2 files changed, 134 insertions(+), 117 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/scheduler/sched_main.c
>> b/drivers/gpu/drm/scheduler/sched_main.c
>> index b9876cad94f2..d77180b44998 100644
>> --- a/drivers/gpu/drm/scheduler/sched_main.c
>> +++ b/drivers/gpu/drm/scheduler/sched_main.c
>> @@ -164,7 +164,9 @@ drm_sched_rq_select_entity(struct drm_sched_rq *rq)
>>* drm_sched_job_done - complete a job
>>* @s_job: pointer to the job which is done
>>*
>> - * Finish the job's fence and wake up the worker thread.
>> + * Move the completed task to the done list,
>> + * signal the its fence to mark it finished,
>> + * and wake up the worker thread.
>>*/
>> static void drm_sched_job_done(struct drm_sched_job *s_job)
>> {
>> @@ -176,9 +178,14 @@ static void drm_sched_job_done(struct drm_sched_job
>> *s_job)
>>
>> trace_drm_sched_process_job(s_fence);
>>
>> +spin_lock(&sched->job_list_lock);
>> +list_move(&s_job->list, &sched->done_list);
>> +spin_unlock(&sched->job_list_lock);
>> +
>
> That is racy, as soon as the spinlock is dropped the job and with it the
> s_fence might haven been destroyed.
Yeah, I had it the other way around, (the correct way),
and changed it--not sure why. I revert it back. Thanks
for catching this.
Regards,
Luben
>
>> dma_fence_get(&s_fence->finished);
>> drm_sched_fence_finished(s_fence);
>> dma_fence_put(&s_fence->finished);
>
> In other words this here needs to come first.
>
> Regards,
> Christian.
>
>> +
>> wake_up_interruptible(&sched->wake_up_worker);
>> }
>>
>> @@ -309,6 +316,37 @@ static void drm_sched_job_begin(struct drm_sched_job
>> *s_job)
>> spin_unlock(&sched->job_list_lock);
>> }
>>
>> +/** drm_sched_job_timeout -- a timer timeout occurred
>> + * @work: pointer to work_struct
>> + *
>> + * First, park the scheduler thread whose IP timed out,
>> + * so that we don't race with the scheduler thread pushing
>> + * jobs down the IP as we try to investigate what
>> + * happened and give drivers a chance to recover.
>> + *
>> + * Second, take the fist job in the pending list
>> + * (oldest), leave it in the pending list and call the
>> + * driver's timer timeout callback to find out what
>> + * happened, passing this job as the suspect one.
>> + *
>> + * The driver may return DRM_TASK_STATUS COMPLETE,
>> + * which means the task is not in the IP(*) and we move
>> + * it to the done list to free it.
>> + *
>> + * (*) A reason for this would be, say, that the job
>> + * completed in due time, or the driver has aborted
>> + * this job using driver specific methods in the
>> + * timedout_job callback and has now removed it from
>> + * the hardware.
>> + *
>> + * Or, the driver may return DRM_TASK_STATUS_ALIVE, to
>> + * indicate that it had inquired about this job, and it
>> + * has verified that this job is alive and well, and
>> + * that the DRM layer should give this task more time
>> +
Re: [PATCH 1/2] drm: add legacy support for using degamma for gamma
On 07/12/2020 17:31, Ville Syrjälä wrote:
> On Sat, Dec 05, 2020 at 12:35:25AM +0200, Laurent Pinchart wrote:
>> Hi Tomi,
>>
>> Thank you for the patch.
>>
>> On Thu, Dec 03, 2020 at 01:48:44PM +0200, Tomi Valkeinen wrote:
>>> We currently have drm_atomic_helper_legacy_gamma_set() helper which can
>>> be used to handle legacy gamma-set ioctl.
>>> drm_atomic_helper_legacy_gamma_set() sets GAMMA_LUT, and clears
>>> CTM and DEGAMMA_LUT. This works fine on HW where we have either:
>>>
>>> degamma -> ctm -> gamma -> out
>>>
>>> or
>>>
>>> ctm -> gamma -> out
>>>
>>> However, if the HW has gamma table before ctm, the atomic property
>>> should be DEGAMMA_LUT, and thus we have:
>>>
>>> degamma -> ctm -> out
>>>
>>> This is fine for userspace which sets gamma table using the properties,
>>> as the userspace can check for the existence of gamma & degamma, but the
>>> legacy gamma-set ioctl does not work.
>>>
>>> This patch fixes the issue by changing
>>> drm_atomic_helper_legacy_gamma_set() so that GAMMA_LUT will be used if
>>> it exists, and DEGAMMA_LUT will be used as a fallback.
>>>
>>> Signed-off-by: Tomi Valkeinen
>>> ---
>>> drivers/gpu/drm/drm_atomic_helper.c | 18 +++---
>>> drivers/gpu/drm/drm_color_mgmt.c| 4
>>> include/drm/drm_crtc.h | 3 +++
>>> 3 files changed, 22 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
>>> b/drivers/gpu/drm/drm_atomic_helper.c
>>> index ba1507036f26..fe59c8ea42a9 100644
>>> --- a/drivers/gpu/drm/drm_atomic_helper.c
>>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
>>> @@ -3512,6 +3512,10 @@ EXPORT_SYMBOL(drm_atomic_helper_page_flip_target);
>>> * that support color management through the DEGAMMA_LUT/GAMMA_LUT
>>> * properties. See drm_crtc_enable_color_mgmt() and the containing chapter
>>> for
>>> * how the atomic color management and gamma tables work.
>>> + *
>>> + * This function uses the GAMMA_LUT or DEGAMMA_LUT property for the gamma
>>> table.
>>> + * GAMMA_LUT property is used if it exists, and DEGAMMA_LUT property is
>>> used as
>>> + * a fallback.
>>> */
>>> int drm_atomic_helper_legacy_gamma_set(struct drm_crtc *crtc,
>>>u16 *red, u16 *green, u16 *blue,
>>> @@ -3525,6 +3529,12 @@ int drm_atomic_helper_legacy_gamma_set(struct
>>> drm_crtc *crtc,
>>> struct drm_color_lut *blob_data;
>>> int i, ret = 0;
>>> bool replaced;
>>> + bool use_degamma;
>>> +
>>> + if (!crtc->has_gamma_prop && !crtc->has_degamma_prop)
>>> + return -ENODEV;
>>> +
>>> + use_degamma = !crtc->has_gamma_prop;
>>>
>>> state = drm_atomic_state_alloc(crtc->dev);
>>> if (!state)
>>> @@ -3554,10 +3564,12 @@ int drm_atomic_helper_legacy_gamma_set(struct
>>> drm_crtc *crtc,
>>> goto fail;
>>> }
>>>
>>> - /* Reset DEGAMMA_LUT and CTM properties. */
>>> - replaced = drm_property_replace_blob(&crtc_state->degamma_lut, NULL);
>>> + /* Set GAMMA/DEGAMMA_LUT and reset DEGAMMA/GAMMA_LUT and CTM */
>>> + replaced = drm_property_replace_blob(&crtc_state->degamma_lut,
>>> + use_degamma ? blob : NULL);
>>> replaced |= drm_property_replace_blob(&crtc_state->ctm, NULL);
>>> - replaced |= drm_property_replace_blob(&crtc_state->gamma_lut, blob);
>>> + replaced |= drm_property_replace_blob(&crtc_state->gamma_lut,
>>> + use_degamma ? NULL : blob);
>>> crtc_state->color_mgmt_changed |= replaced;
>>>
>>> ret = drm_atomic_commit(state);
>>> diff --git a/drivers/gpu/drm/drm_color_mgmt.c
>>> b/drivers/gpu/drm/drm_color_mgmt.c
>>> index 3bcabc2f6e0e..956e59d5f6a7 100644
>>> --- a/drivers/gpu/drm/drm_color_mgmt.c
>>> +++ b/drivers/gpu/drm/drm_color_mgmt.c
>>> @@ -176,6 +176,8 @@ void drm_crtc_enable_color_mgmt(struct drm_crtc *crtc,
>>>degamma_lut_size);
>>> }
>>>
>>> + crtc->has_degamma_prop = !!degamma_lut_size;
>>> +
>>> if (has_ctm)
>>> drm_object_attach_property(&crtc->base,
>>>config->ctm_property, 0);
>>> @@ -187,6 +189,8 @@ void drm_crtc_enable_color_mgmt(struct drm_crtc *crtc,
>>>config->gamma_lut_size_property,
>>>gamma_lut_size);
>>> }
>>> +
>>> + crtc->has_gamma_prop = !!gamma_lut_size;
>>> }
>>> EXPORT_SYMBOL(drm_crtc_enable_color_mgmt);
>>>
>>> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
>>> index ba839e5e357d..9e1f06047e3d 100644
>>> --- a/include/drm/drm_crtc.h
>>> +++ b/include/drm/drm_crtc.h
>>> @@ -1084,6 +1084,9 @@ struct drm_crtc {
>>> */
>>> uint16_t *gamma_store;
>>>
>>> + bool has_gamma_prop;
>>> + bool has_degamma_prop;
>>
>> We could use a bitfield to save a bit of memory. Apart from that, the
>> patch looks good to me.
>
> Or we could just check if the crtc has the relevant prop or not.
That's w
Re: [PATCH 4/5] drm/scheduler: Job timeout handler returns status (v2)
On 12/7/20 2:19 PM, Christian König wrote: Am 07.12.20 um 20:09 schrieb Andrey Grodzovsky: On 12/7/20 1:04 PM, Christian König wrote: Am 07.12.20 um 17:00 schrieb Andrey Grodzovsky: On 12/7/20 6:13 AM, Christian König wrote: Am 04.12.20 um 16:10 schrieb Andrey Grodzovsky: On 12/4/20 3:13 AM, Christian König wrote: Thinking more about that I came to the conclusion that the whole approach here isn't correct. See even when the job has been completed or canceled we still want to restart the timer. The reason for this is that the timer is then not restarted for the current job, but for the next job in the queue. The only valid reason to not restart the timer is that the whole device was hot plugged and we return -ENODEV here. E.g. what Andrey has been working on. We discussed this with Luben off line a few days ago but came to a conclusion that for the next job the timer restart in drm_sched_job_begin should do the work, no ? Nope, drm_sched_job_begin() pushes the job to the hardware and starts the timeout in case the hardware was idle before. drm_sched_job_begin only adds the job to ring mirror list and rearms the timer, I don't see how it is related to whether the HW was idle before ? It doesn't rearm the timer. It initially starts the timer when the hardware is idle. It schedules delayed work for the timer task if ring mirror list not empty. Am i missing something ? Ok, let me explain from the beginning. drm_sched_start_timeout() initially starts the timer, it does NOT rearms it! When the timer is already running it doesn't has any effect at all. In a sense that delayed work cannot be enqueued while another instance is still in the queue I agree. I forgot about this in the context of drm_sched_start_timeout. When a job completes drm_sched_get_cleanup_job() cancels the timer, frees the job and then starts a new timer for the engine. When a timeout happens the job is either canceled or give some extra time by putting it back on the pending list. When the job is canceled the timer must be restarted for the next job, because drm_sched_job_begin() was already called long ago. Now i get it. Next job might have called (and probably did) drm_sched_job_begin while previous timer work (currently executing one) was still in the workqueue and so we cannot count on it to actually have restarted the timer and so we must do it. When the job gets some extra time we should also restart the timer. Same as above. Thanks for clarifying this. Andrey The only case when the timer should not be restarted is when the device was hotplugged and is completely gone now. I think the right approach to stop this messing with the ring mirror list is to avoid using the job altogether for recovery. What we should do instead is to put the recovery information on the scheduler fence, because that is the object which stays alive after pushing the job to the hardware. Christian. Andrey Christian. Andrey The function should probably be renamed to drm_sched_job_pushed() because it doesn't begin the execution in any way. Christian. Andrey Regards, Christian. Am 04.12.20 um 04:17 schrieb Luben Tuikov: The driver's job timeout handler now returns status indicating back to the DRM layer whether the task (job) was successfully aborted or whether more time should be given to the task to complete. Default behaviour as of this patch, is preserved, except in obvious-by-comment case in the Panfrost driver, as documented below. All drivers which make use of the drm_sched_backend_ops' .timedout_job() callback have been accordingly renamed and return the would've-been default value of DRM_TASK_STATUS_ALIVE to restart the task's timeout timer--this is the old behaviour, and is preserved by this patch. In the case of the Panfrost driver, its timedout callback correctly first checks if the job had completed in due time and if so, it now returns DRM_TASK_STATUS_COMPLETE to notify the DRM layer that the task can be moved to the done list, to be freed later. In the other two subsequent checks, the value of DRM_TASK_STATUS_ALIVE is returned, as per the default behaviour. A more involved driver's solutions can be had in subequent patches. Signed-off-by: Luben Tuikov Reported-by: kernel test robot Cc: Alexander Deucher Cc: Andrey Grodzovsky Cc: Christian König Cc: Daniel Vetter Cc: Lucas Stach Cc: Russell King Cc: Christian Gmeiner Cc: Qiang Yu Cc: Rob Herring Cc: Tomeu Vizoso Cc: Steven Price Cc: Alyssa Rosenzweig Cc: Eric Anholt v2: Use enum as the status of a driver's job timeout callback method. --- drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 6 +++-- drivers/gpu/drm/etnaviv/etnaviv_sched.c | 10 +++- drivers/gpu/drm/lima/lima_sched.c | 4 +++- drivers/gpu/drm/panfrost/panfrost_job.c | 9 --- drivers/gpu/drm/scheduler/sched_main.c | 4 +--- drivers/gpu/drm/v3d/v3d_sched.c | 32 +++
Re: [PATCH] drm/ttm: cleanup BO size handling
Am 07.12.20 um 20:33 schrieb Daniel Vetter:
On Mon, Dec 7, 2020 at 5:33 PM Christian König
wrote:
Based on an idea from Dave, but cleaned up a bit.
We had multiple fields for essentially the same thing.
Now bo->size is the original size of the BO in arbitrary
units, usually bytes.
bo->mem.num_pages is the size in number of pages in the
resource domain of bo->mem.mem_type.
Signed-off-by: Christian König
We also have ttm_bo.base.size, do we want to reuse that one like we've
done for the reservation object? I'd have said "follow up patch" but
it's going to be exactly the same churn once more.
Oh, good point. I haven't noticed that.
Thanks,
Christian.
-Daniel
---
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c| 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h| 4 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 6 ++--
drivers/gpu/drm/amd/amdgpu/mes_v10_1.c| 2 +-
drivers/gpu/drm/nouveau/nouveau_bo.c | 10 +++---
drivers/gpu/drm/nouveau/nouveau_display.c | 8 ++---
drivers/gpu/drm/nouveau/nouveau_prime.c | 4 +--
drivers/gpu/drm/nouveau/nv17_fence.c | 2 +-
drivers/gpu/drm/nouveau/nv50_fence.c | 2 +-
drivers/gpu/drm/qxl/qxl_object.h | 2 +-
drivers/gpu/drm/radeon/radeon_cs.c| 3 +-
drivers/gpu/drm/radeon/radeon_object.c| 13
drivers/gpu/drm/radeon/radeon_object.h| 4 +--
drivers/gpu/drm/radeon/radeon_prime.c | 4 +--
drivers/gpu/drm/radeon/radeon_trace.h | 2 +-
drivers/gpu/drm/radeon/radeon_ttm.c | 2 +-
drivers/gpu/drm/ttm/ttm_bo.c | 33 ++-
drivers/gpu/drm/ttm/ttm_bo_util.c | 11 +++
drivers/gpu/drm/ttm/ttm_bo_vm.c | 6 ++--
drivers/gpu/drm/ttm/ttm_tt.c | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_blit.c | 4 +--
drivers/gpu/drm/vmwgfx/vmwgfx_bo.c| 6 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 4 +--
drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c | 5 ++-
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c| 8 ++---
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_shader.c| 3 +-
drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 4 +--
drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 7 ++--
include/drm/ttm/ttm_bo_api.h | 6 ++--
include/drm/ttm/ttm_resource.h| 1 -
36 files changed, 82 insertions(+), 100 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
index e5919efca870..c4c93f19d273 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
@@ -269,7 +269,7 @@ static struct sg_table *amdgpu_dma_buf_map(struct
dma_buf_attachment *attach,
case TTM_PL_TT:
sgt = drm_prime_pages_to_sg(obj->dev,
bo->tbo.ttm->pages,
- bo->tbo.num_pages);
+ bo->tbo.ttm->num_pages);
if (IS_ERR(sgt))
return sgt;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
index 056cb87d09ea..52bcd1b5582f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
@@ -121,7 +121,7 @@ uint64_t amdgpu_gmc_agp_addr(struct ttm_buffer_object *bo)
{
struct amdgpu_device *adev = amdgpu_ttm_adev(bo->bdev);
- if (bo->num_pages != 1 || bo->ttm->caching == ttm_cached)
+ if (bo->ttm->num_pages != 1 || bo->ttm->caching == ttm_cached)
return AMDGPU_BO_INVALID_OFFSET;
if (bo->ttm->dma_address[0] + PAGE_SIZE >= adev->gmc.agp_size)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index c6c9723d3d8a..381ecc4788d5 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -787,7 +787,7 @@ int amdgpu_bo_kmap(struct amdgpu_bo *bo, void **ptr)
if (r < 0)
return r;
- r = ttm_bo_kmap(&bo->tbo, 0, bo->tbo.num_pages, &bo->kmap);
+ r = ttm_bo_kmap(&bo->tbo, 0, bo->tbo.mem.num_pages, &bo->kmap);
if (r)
return r;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
index ed47cbac4f75..176ed3615151 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
@@ -174,12 +174,12 @@ static inline void amdgpu_bo_unreserve(struct amdg
Re: [PATCH] drm/ttm: cleanup BO size handling
On Mon, Dec 7, 2020 at 5:33 PM Christian König
wrote:
>
> Based on an idea from Dave, but cleaned up a bit.
>
> We had multiple fields for essentially the same thing.
>
> Now bo->size is the original size of the BO in arbitrary
> units, usually bytes.
>
> bo->mem.num_pages is the size in number of pages in the
> resource domain of bo->mem.mem_type.
>
> Signed-off-by: Christian König
We also have ttm_bo.base.size, do we want to reuse that one like we've
done for the reservation object? I'd have said "follow up patch" but
it's going to be exactly the same churn once more.
-Daniel
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 2 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 2 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_object.c| 2 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_object.h| 4 +--
> drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 2 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 6 ++--
> drivers/gpu/drm/amd/amdgpu/mes_v10_1.c| 2 +-
> drivers/gpu/drm/nouveau/nouveau_bo.c | 10 +++---
> drivers/gpu/drm/nouveau/nouveau_display.c | 8 ++---
> drivers/gpu/drm/nouveau/nouveau_prime.c | 4 +--
> drivers/gpu/drm/nouveau/nv17_fence.c | 2 +-
> drivers/gpu/drm/nouveau/nv50_fence.c | 2 +-
> drivers/gpu/drm/qxl/qxl_object.h | 2 +-
> drivers/gpu/drm/radeon/radeon_cs.c| 3 +-
> drivers/gpu/drm/radeon/radeon_object.c| 13
> drivers/gpu/drm/radeon/radeon_object.h| 4 +--
> drivers/gpu/drm/radeon/radeon_prime.c | 4 +--
> drivers/gpu/drm/radeon/radeon_trace.h | 2 +-
> drivers/gpu/drm/radeon/radeon_ttm.c | 2 +-
> drivers/gpu/drm/ttm/ttm_bo.c | 33 ++-
> drivers/gpu/drm/ttm/ttm_bo_util.c | 11 +++
> drivers/gpu/drm/ttm/ttm_bo_vm.c | 6 ++--
> drivers/gpu/drm/ttm/ttm_tt.c | 2 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_blit.c | 4 +--
> drivers/gpu/drm/vmwgfx/vmwgfx_bo.c| 6 ++--
> drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c | 2 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 4 +--
> drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c | 5 ++-
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 2 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c| 8 ++---
> drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 2 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_shader.c| 3 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 4 +--
> drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 7 ++--
> include/drm/ttm/ttm_bo_api.h | 6 ++--
> include/drm/ttm/ttm_resource.h| 1 -
> 36 files changed, 82 insertions(+), 100 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> index e5919efca870..c4c93f19d273 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> @@ -269,7 +269,7 @@ static struct sg_table *amdgpu_dma_buf_map(struct
> dma_buf_attachment *attach,
> case TTM_PL_TT:
> sgt = drm_prime_pages_to_sg(obj->dev,
> bo->tbo.ttm->pages,
> - bo->tbo.num_pages);
> + bo->tbo.ttm->num_pages);
> if (IS_ERR(sgt))
> return sgt;
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
> index 056cb87d09ea..52bcd1b5582f 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
> @@ -121,7 +121,7 @@ uint64_t amdgpu_gmc_agp_addr(struct ttm_buffer_object *bo)
> {
> struct amdgpu_device *adev = amdgpu_ttm_adev(bo->bdev);
>
> - if (bo->num_pages != 1 || bo->ttm->caching == ttm_cached)
> + if (bo->ttm->num_pages != 1 || bo->ttm->caching == ttm_cached)
> return AMDGPU_BO_INVALID_OFFSET;
>
> if (bo->ttm->dma_address[0] + PAGE_SIZE >= adev->gmc.agp_size)
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> index c6c9723d3d8a..381ecc4788d5 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> @@ -787,7 +787,7 @@ int amdgpu_bo_kmap(struct amdgpu_bo *bo, void **ptr)
> if (r < 0)
> return r;
>
> - r = ttm_bo_kmap(&bo->tbo, 0, bo->tbo.num_pages, &bo->kmap);
> + r = ttm_bo_kmap(&bo->tbo, 0, bo->tbo.mem.num_pages, &bo->kmap);
> if (r)
> return r;
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
> index ed47cbac4f75..176ed3615151 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
> @@ -174,12 +174,12 @@ static inline void amd
[Bug 210467] amdgpu Vega 3 lock MCLK on 1200mhz
https://bugzilla.kernel.org/show_bug.cgi?id=210467 --- Comment #8 from Alex Deucher (alexdeuc...@gmail.com) --- Can you narrow down which specific firmware? Also what what versions did you try? -- 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 4/5] drm/scheduler: Job timeout handler returns status (v2)
Am 07.12.20 um 20:09 schrieb Andrey Grodzovsky: On 12/7/20 1:04 PM, Christian König wrote: Am 07.12.20 um 17:00 schrieb Andrey Grodzovsky: On 12/7/20 6:13 AM, Christian König wrote: Am 04.12.20 um 16:10 schrieb Andrey Grodzovsky: On 12/4/20 3:13 AM, Christian König wrote: Thinking more about that I came to the conclusion that the whole approach here isn't correct. See even when the job has been completed or canceled we still want to restart the timer. The reason for this is that the timer is then not restarted for the current job, but for the next job in the queue. The only valid reason to not restart the timer is that the whole device was hot plugged and we return -ENODEV here. E.g. what Andrey has been working on. We discussed this with Luben off line a few days ago but came to a conclusion that for the next job the timer restart in drm_sched_job_begin should do the work, no ? Nope, drm_sched_job_begin() pushes the job to the hardware and starts the timeout in case the hardware was idle before. drm_sched_job_begin only adds the job to ring mirror list and rearms the timer, I don't see how it is related to whether the HW was idle before ? It doesn't rearm the timer. It initially starts the timer when the hardware is idle. It schedules delayed work for the timer task if ring mirror list not empty. Am i missing something ? Ok, let me explain from the beginning. drm_sched_start_timeout() initially starts the timer, it does NOT rearms it! When the timer is already running it doesn't has any effect at all. When a job completes drm_sched_get_cleanup_job() cancels the timer, frees the job and then starts a new timer for the engine. When a timeout happens the job is either canceled or give some extra time by putting it back on the pending list. When the job is canceled the timer must be restarted for the next job, because drm_sched_job_begin() was already called long ago. When the job gets some extra time we should also restart the timer. The only case when the timer should not be restarted is when the device was hotplugged and is completely gone now. I think the right approach to stop this messing with the ring mirror list is to avoid using the job altogether for recovery. What we should do instead is to put the recovery information on the scheduler fence, because that is the object which stays alive after pushing the job to the hardware. Christian. Andrey Christian. Andrey The function should probably be renamed to drm_sched_job_pushed() because it doesn't begin the execution in any way. Christian. Andrey Regards, Christian. Am 04.12.20 um 04:17 schrieb Luben Tuikov: The driver's job timeout handler now returns status indicating back to the DRM layer whether the task (job) was successfully aborted or whether more time should be given to the task to complete. Default behaviour as of this patch, is preserved, except in obvious-by-comment case in the Panfrost driver, as documented below. All drivers which make use of the drm_sched_backend_ops' .timedout_job() callback have been accordingly renamed and return the would've-been default value of DRM_TASK_STATUS_ALIVE to restart the task's timeout timer--this is the old behaviour, and is preserved by this patch. In the case of the Panfrost driver, its timedout callback correctly first checks if the job had completed in due time and if so, it now returns DRM_TASK_STATUS_COMPLETE to notify the DRM layer that the task can be moved to the done list, to be freed later. In the other two subsequent checks, the value of DRM_TASK_STATUS_ALIVE is returned, as per the default behaviour. A more involved driver's solutions can be had in subequent patches. Signed-off-by: Luben Tuikov Reported-by: kernel test robot Cc: Alexander Deucher Cc: Andrey Grodzovsky Cc: Christian König Cc: Daniel Vetter Cc: Lucas Stach Cc: Russell King Cc: Christian Gmeiner Cc: Qiang Yu Cc: Rob Herring Cc: Tomeu Vizoso Cc: Steven Price Cc: Alyssa Rosenzweig Cc: Eric Anholt v2: Use enum as the status of a driver's job timeout callback method. --- drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 6 +++-- drivers/gpu/drm/etnaviv/etnaviv_sched.c | 10 +++- drivers/gpu/drm/lima/lima_sched.c | 4 +++- drivers/gpu/drm/panfrost/panfrost_job.c | 9 --- drivers/gpu/drm/scheduler/sched_main.c | 4 +--- drivers/gpu/drm/v3d/v3d_sched.c | 32 + include/drm/gpu_scheduler.h | 20 +--- 7 files changed, 57 insertions(+), 28 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c index ff48101bab55..a111326cbdde 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c @@ -28,7 +28,7 @@ #include "amdgpu.h" #include "amdgpu_trace.h" -static void amdgpu_job_timedout(struct drm_sched_job *s_job) +static enum drm_task_status amdg
Re: [PATCH 4/5] drm/scheduler: Job timeout handler returns status (v2)
On 12/7/20 1:04 PM, Christian König wrote:
Am 07.12.20 um 17:00 schrieb Andrey Grodzovsky:
On 12/7/20 6:13 AM, Christian König wrote:
Am 04.12.20 um 16:10 schrieb Andrey Grodzovsky:
On 12/4/20 3:13 AM, Christian König wrote:
Thinking more about that I came to the conclusion that the whole approach
here isn't correct.
See even when the job has been completed or canceled we still want to
restart the timer.
The reason for this is that the timer is then not restarted for the
current job, but for the next job in the queue.
The only valid reason to not restart the timer is that the whole device
was hot plugged and we return -ENODEV here. E.g. what Andrey has been
working on.
We discussed this with Luben off line a few days ago but came to a
conclusion that for the next job the timer restart in drm_sched_job_begin
should do the work, no ?
Nope, drm_sched_job_begin() pushes the job to the hardware and starts the
timeout in case the hardware was idle before.
drm_sched_job_begin only adds the job to ring mirror list and rearms the
timer, I don't see how it is related to whether the HW was idle before ?
It doesn't rearm the timer. It initially starts the timer when the hardware is
idle.
It schedules delayed work for the timer task if ring mirror list not empty. Am i
missing something ?
Andrey
Christian.
Andrey
The function should probably be renamed to drm_sched_job_pushed() because it
doesn't begin the execution in any way.
Christian.
Andrey
Regards,
Christian.
Am 04.12.20 um 04:17 schrieb Luben Tuikov:
The driver's job timeout handler now returns
status indicating back to the DRM layer whether
the task (job) was successfully aborted or whether
more time should be given to the task to complete.
Default behaviour as of this patch, is preserved,
except in obvious-by-comment case in the Panfrost
driver, as documented below.
All drivers which make use of the
drm_sched_backend_ops' .timedout_job() callback
have been accordingly renamed and return the
would've-been default value of
DRM_TASK_STATUS_ALIVE to restart the task's
timeout timer--this is the old behaviour, and
is preserved by this patch.
In the case of the Panfrost driver, its timedout
callback correctly first checks if the job had
completed in due time and if so, it now returns
DRM_TASK_STATUS_COMPLETE to notify the DRM layer
that the task can be moved to the done list, to be
freed later. In the other two subsequent checks,
the value of DRM_TASK_STATUS_ALIVE is returned, as
per the default behaviour.
A more involved driver's solutions can be had
in subequent patches.
Signed-off-by: Luben Tuikov
Reported-by: kernel test robot
Cc: Alexander Deucher
Cc: Andrey Grodzovsky
Cc: Christian König
Cc: Daniel Vetter
Cc: Lucas Stach
Cc: Russell King
Cc: Christian Gmeiner
Cc: Qiang Yu
Cc: Rob Herring
Cc: Tomeu Vizoso
Cc: Steven Price
Cc: Alyssa Rosenzweig
Cc: Eric Anholt
v2: Use enum as the status of a driver's job
timeout callback method.
---
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 6 +++--
drivers/gpu/drm/etnaviv/etnaviv_sched.c | 10 +++-
drivers/gpu/drm/lima/lima_sched.c | 4 +++-
drivers/gpu/drm/panfrost/panfrost_job.c | 9 ---
drivers/gpu/drm/scheduler/sched_main.c | 4 +---
drivers/gpu/drm/v3d/v3d_sched.c | 32 +
include/drm/gpu_scheduler.h | 20 +---
7 files changed, 57 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
index ff48101bab55..a111326cbdde 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
@@ -28,7 +28,7 @@
#include "amdgpu.h"
#include "amdgpu_trace.h"
-static void amdgpu_job_timedout(struct drm_sched_job *s_job)
+static enum drm_task_status amdgpu_job_timedout(struct drm_sched_job
*s_job)
{
struct amdgpu_ring *ring = to_amdgpu_ring(s_job->sched);
struct amdgpu_job *job = to_amdgpu_job(s_job);
@@ -41,7 +41,7 @@ static void amdgpu_job_timedout(struct drm_sched_job
*s_job)
amdgpu_ring_soft_recovery(ring, job->vmid,
s_job->s_fence->parent)) {
DRM_ERROR("ring %s timeout, but soft recovered\n",
s_job->sched->name);
- return;
+ return DRM_TASK_STATUS_ALIVE;
}
amdgpu_vm_get_task_info(ring->adev, job->pasid, &ti);
@@ -53,10 +53,12 @@ static void amdgpu_job_timedout(struct drm_sched_job
*s_job)
if (amdgpu_device_should_recover_gpu(ring->adev)) {
amdgpu_device_gpu_recover(ring->adev, job);
+ return DRM_TASK_STATUS_ALIVE;
} else {
drm_sched_suspend_timeout(&ring->sched);
if (amdgpu_sriov_vf(adev))
adev->virt.tdr_debug = true;
+ return DRM_TASK_STATUS_ALIVE;
}
}
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
index cd46c882269c..c49516942328 100644
--- a/d
Re: [PATCH 4/5] drm/scheduler: Job timeout handler returns status (v2)
Am 07.12.20 um 17:00 schrieb Andrey Grodzovsky:
On 12/7/20 6:13 AM, Christian König wrote:
Am 04.12.20 um 16:10 schrieb Andrey Grodzovsky:
On 12/4/20 3:13 AM, Christian König wrote:
Thinking more about that I came to the conclusion that the whole
approach here isn't correct.
See even when the job has been completed or canceled we still want
to restart the timer.
The reason for this is that the timer is then not restarted for the
current job, but for the next job in the queue.
The only valid reason to not restart the timer is that the whole
device was hot plugged and we return -ENODEV here. E.g. what Andrey
has been working on.
We discussed this with Luben off line a few days ago but came to a
conclusion that for the next job the timer restart in
drm_sched_job_begin should do the work, no ?
Nope, drm_sched_job_begin() pushes the job to the hardware and starts
the timeout in case the hardware was idle before.
drm_sched_job_begin only adds the job to ring mirror list and rearms
the timer, I don't see how it is related to whether the HW was idle
before ?
It doesn't rearm the timer. It initially starts the timer when the
hardware is idle.
Christian.
Andrey
The function should probably be renamed to drm_sched_job_pushed()
because it doesn't begin the execution in any way.
Christian.
Andrey
Regards,
Christian.
Am 04.12.20 um 04:17 schrieb Luben Tuikov:
The driver's job timeout handler now returns
status indicating back to the DRM layer whether
the task (job) was successfully aborted or whether
more time should be given to the task to complete.
Default behaviour as of this patch, is preserved,
except in obvious-by-comment case in the Panfrost
driver, as documented below.
All drivers which make use of the
drm_sched_backend_ops' .timedout_job() callback
have been accordingly renamed and return the
would've-been default value of
DRM_TASK_STATUS_ALIVE to restart the task's
timeout timer--this is the old behaviour, and
is preserved by this patch.
In the case of the Panfrost driver, its timedout
callback correctly first checks if the job had
completed in due time and if so, it now returns
DRM_TASK_STATUS_COMPLETE to notify the DRM layer
that the task can be moved to the done list, to be
freed later. In the other two subsequent checks,
the value of DRM_TASK_STATUS_ALIVE is returned, as
per the default behaviour.
A more involved driver's solutions can be had
in subequent patches.
Signed-off-by: Luben Tuikov
Reported-by: kernel test robot
Cc: Alexander Deucher
Cc: Andrey Grodzovsky
Cc: Christian König
Cc: Daniel Vetter
Cc: Lucas Stach
Cc: Russell King
Cc: Christian Gmeiner
Cc: Qiang Yu
Cc: Rob Herring
Cc: Tomeu Vizoso
Cc: Steven Price
Cc: Alyssa Rosenzweig
Cc: Eric Anholt
v2: Use enum as the status of a driver's job
timeout callback method.
---
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 6 +++--
drivers/gpu/drm/etnaviv/etnaviv_sched.c | 10 +++-
drivers/gpu/drm/lima/lima_sched.c | 4 +++-
drivers/gpu/drm/panfrost/panfrost_job.c | 9 ---
drivers/gpu/drm/scheduler/sched_main.c | 4 +---
drivers/gpu/drm/v3d/v3d_sched.c | 32
+
include/drm/gpu_scheduler.h | 20 +---
7 files changed, 57 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
index ff48101bab55..a111326cbdde 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
@@ -28,7 +28,7 @@
#include "amdgpu.h"
#include "amdgpu_trace.h"
-static void amdgpu_job_timedout(struct drm_sched_job *s_job)
+static enum drm_task_status amdgpu_job_timedout(struct
drm_sched_job *s_job)
{
struct amdgpu_ring *ring = to_amdgpu_ring(s_job->sched);
struct amdgpu_job *job = to_amdgpu_job(s_job);
@@ -41,7 +41,7 @@ static void amdgpu_job_timedout(struct
drm_sched_job *s_job)
amdgpu_ring_soft_recovery(ring, job->vmid,
s_job->s_fence->parent)) {
DRM_ERROR("ring %s timeout, but soft recovered\n",
s_job->sched->name);
- return;
+ return DRM_TASK_STATUS_ALIVE;
}
amdgpu_vm_get_task_info(ring->adev, job->pasid, &ti);
@@ -53,10 +53,12 @@ static void amdgpu_job_timedout(struct
drm_sched_job *s_job)
if (amdgpu_device_should_recover_gpu(ring->adev)) {
amdgpu_device_gpu_recover(ring->adev, job);
+ return DRM_TASK_STATUS_ALIVE;
} else {
drm_sched_suspend_timeout(&ring->sched);
if (amdgpu_sriov_vf(adev))
adev->virt.tdr_debug = true;
+ return DRM_TASK_STATUS_ALIVE;
}
}
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
index cd46c882269c..c49516942328 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
@@ -82,7 +82,8 @@ static struct dma_fence
*etnaviv_sched_run_j
[Bug 210467] amdgpu Vega 3 lock MCLK on 1200mhz
https://bugzilla.kernel.org/show_bug.cgi?id=210467 --- Comment #7 from Alexey (intervio...@gmail.com) --- Problem in firmware. I downgrade linux-firmware package, pp_dpm_mclk now "0: 400Mhz" at start. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: drm_basic_types.h, DRM_FOURCC_STANDALONE
Hi James,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on drm-exynos/exynos-drm-next
tegra-drm/drm/tegra/for-next drm-tip/drm-tip linus/master drm/drm-next
v5.10-rc7 next-20201207]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/James-Park/drm-drm_basic_types-h-DRM_FOURCC_STANDALONE/20201207-165922
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-allyesconfig (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce (this is a W=1 build):
#
https://github.com/0day-ci/linux/commit/c614dbde0c1dc422490fb22281d3e6dcc6355f66
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
James-Park/drm-drm_basic_types-h-DRM_FOURCC_STANDALONE/20201207-165922
git checkout c614dbde0c1dc422490fb22281d3e6dcc6355f66
# save the attached .config to linux build tree
make W=1 ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> usr/include/linux/kfd_ioctl.h:37: found __[us]{8,16,32,64} type without
>> #include
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 4/7] drm/bridge: mhdp8546: Set input_bus_flags from atomic_check
On 11:42-20201204, Boris Brezillon wrote: > On Tue, 1 Dec 2020 17:48:27 +0530 > Nikhil Devshatwar wrote: > > > input_bus_flags are specified in drm_bridge_timings (legacy) as well > > as drm_bridge_state->input_bus_cfg.flags > > > > The flags from the timings will be deprecated. Bridges are supposed > > to validate and set the bridge state flags from atomic_check. > > > > Signed-off-by: Nikhil Devshatwar > > --- > > drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c | 6 ++ > > drivers/gpu/drm/bridge/ti-tfp410.c | 1 + > > 2 files changed, 7 insertions(+) > > > > diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c > > b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c > > index 2cd809eed827..9c17e4bb517e 100644 > > --- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c > > +++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c > > @@ -2121,6 +2121,12 @@ static int cdns_mhdp_atomic_check(struct drm_bridge > > *bridge, > > return -EINVAL; > > } > > > > + /* > > +* There might be flags negotiation supported in future > > +* Set the bus flags in atomic_check statically for now > > +*/ > > + bridge_state->input_bus_cfg.flags = bridge->timings->input_bus_flags; > > I'd go even further and replace the timings field in > cdns_mhdp_platform_info by an input_bus_flags field, you'll then > have the following assignment here. > > if (mhdp->info) > bridge_state->input_bus_cfg.flags = mhdp->info->input_bus_flags; > > This way you no rely on the bridge->timings presence and can > get rid of the mhdp->bridge.timings assignment in the probe path. > Okay, I'll update this patch > > > + > > mutex_unlock(&mhdp->link_mutex); > > return 0; > > } > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 4/7] drm/bridge: mhdp8546: Set input_bus_flags from atomic_check
On 11:32-20201204, Boris Brezillon wrote:
> On Tue, 1 Dec 2020 17:48:27 +0530
> Nikhil Devshatwar wrote:
>
> > input_bus_flags are specified in drm_bridge_timings (legacy) as well
> > as drm_bridge_state->input_bus_cfg.flags
> >
> > The flags from the timings will be deprecated. Bridges are supposed
> > to validate and set the bridge state flags from atomic_check.
> >
> > Signed-off-by: Nikhil Devshatwar
> > ---
> > drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c | 6 ++
> > drivers/gpu/drm/bridge/ti-tfp410.c | 1 +
> > 2 files changed, 7 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
> > b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
> > index 2cd809eed827..9c17e4bb517e 100644
> > --- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
> > +++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
> > @@ -2121,6 +2121,12 @@ static int cdns_mhdp_atomic_check(struct drm_bridge
> > *bridge,
> > return -EINVAL;
> > }
> >
> > + /*
> > +* There might be flags negotiation supported in future
> > +* Set the bus flags in atomic_check statically for now
> > +*/
> > + bridge_state->input_bus_cfg.flags = bridge->timings->input_bus_flags;
> > +
> > mutex_unlock(&mhdp->link_mutex);
> > return 0;
> > }
> > diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c
> > b/drivers/gpu/drm/bridge/ti-tfp410.c
> > index 4c536df003c8..9035d2145a28 100644
> > --- a/drivers/gpu/drm/bridge/ti-tfp410.c
> > +++ b/drivers/gpu/drm/bridge/ti-tfp410.c
> > @@ -245,6 +245,7 @@ int tfp410_atomic_check(struct drm_bridge *bridge,
> > * Set the bus flags in atomic_check statically for now
> > */
> > bridge_state->input_bus_cfg.flags = dvi->timings.input_bus_flags;
> > + return 0;
>
> And here is the return statement that was missing in patch 2 :-).
Sorry. I guess I messed up while rebasing. Will fix this
Nikhil D
>
> > }
> >
> > static const struct drm_bridge_funcs tfp410_bridge_funcs = {
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 02/13] video: fbdev: core: Fix kernel-doc warnings in fbmon + fb_notify
Hi Randy, > >> > >> Yes, RETURNS: will work. It just looks like any kernel-doc section name, > >> such as Context: or Note:. > >> However, the documented format for return info is "Return:". > >> (see Documentation/doc-guide/kernel-doc.rst) > > > > Thanks for the note. I asked for RETURNS: because the rest of the file > > appears to be using it. Returns: is certainly the better alternative. I > > didn't know there was a difference. > > > > Best regards > > Thomas > > > > I'm not insisting on using Return: > It can stay the same as the rest of the file IMO. fb_notify.c contains only the three functions modified in this patch. So it is consistent within this file, but other fbdev/core/ files uses RETURNS. git grep shows 5 hits only. So we will stick with the documented practice here. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 3/6] dt-bindings: display: imx: Add i.MX8qxp/qm DPR channel binding
On Mon, Dec 07, 2020 at 11:20:57AM +0800, Liu Ying wrote:
> This patch adds bindings for i.MX8qxp/qm Display Prefetch Resolve Channel.
>
> Signed-off-by: Liu Ying
> ---
> Note that this depends on the 'two cell binding' clock patch set which has
> already landed in Shawn's i.MX clk/imx git branch. Otherwise, imx8-lpcg.h
> won't be found.
>
> v2->v3:
> * No change.
>
> v1->v2:
> * Use new dt binding way to add clocks in the example.
>
> .../bindings/display/imx/fsl,imx8qxp-dprc.yaml | 87
> ++
> 1 file changed, 87 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dprc.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dprc.yaml
> b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dprc.yaml
> new file mode 100644
> index ..91e9472
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dprc.yaml
> @@ -0,0 +1,87 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/imx/fsl,imx8qxp-dprc.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Freescale i.MX8qm/qxp Display Prefetch Resolve Channel
> +
> +maintainers:
> + - Liu Ying
> +
> +description: |
> + The i.MX8qm/qxp Display Prefetch Resolve Channel(DPRC) is an engine which
> + fetches display data before the display pipeline needs the data to drive
> + pixels in the active display region. This data is transformed, or
> resolved,
> + from a variety of tiled buffer formats into linear format, if needed.
> + The DPR works with a double bank memory structure. This memory structure
> is
> + implemented in the Resolve Tile Memory(RTRAM) and the banks are referred to
> + as A and B. Each bank is either 4 or 8 lines high depending on the source
> + frame buffer format.
> +
> +properties:
> + compatible:
> +oneOf:
> + - const: fsl,imx8qxp-dpr-channel
> + - const: fsl,imx8qm-dpr-channel
enum instead of oneOf+const.
With that,
Reviewed-by: Rob Herring
> +
> + reg:
> +maxItems: 1
> +
> + interrupts:
> +maxItems: 1
> +
> + clocks:
> +items:
> + - description: apb clock
> + - description: b clock
> + - description: rtram clock
> +
> + clock-names:
> +items:
> + - const: apb
> + - const: b
> + - const: rtram
> +
> + fsl,sc-resource:
> +$ref: /schemas/types.yaml#/definitions/uint32
> +description: The SCU resource ID associated with this DPRC instance.
> +
> + fsl,prgs:
> +$ref: /schemas/types.yaml#/definitions/phandle-array
> +description: |
> + List of phandle which points to Prefetch Resolve Gaskets(PRGs)
> + associated with this DPRC instance.
> +
> + power-domains:
> +maxItems: 1
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - clocks
> + - clock-names
> + - fsl,sc-resource
> + - fsl,prgs
> + - power-domains
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +#include
> +#include
> +#include
> +dpr-channel@5610 {
> +compatible = "fsl,imx8qxp-dpr-channel";
> +reg = <0x5610 0x1>;
> +interrupts = ;
> +clocks = <&dc0_dpr1_lpcg IMX_LPCG_CLK_4>,
> + <&dc0_dpr1_lpcg IMX_LPCG_CLK_5>,
> + <&dc0_rtram1_lpcg IMX_LPCG_CLK_0>;
> +clock-names = "apb", "b", "rtram";
> +fsl,sc-resource = ;
> +fsl,prgs = <&dc0_prg4>, <&dc0_prg5>;
> +power-domains = <&pd IMX_SC_R_DC_0>;
> +};
> --
> 2.7.4
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/6] dt-bindings: display: imx: Add i.MX8qxp/qm PRG binding
On Mon, Dec 07, 2020 at 11:20:56AM +0800, Liu Ying wrote:
> This patch adds bindings for i.MX8qxp/qm Display Prefetch Resolve Gasket.
>
> Signed-off-by: Liu Ying
> ---
> Note that this depends on the 'two cell binding' clock patch set which has
> already landed in Shawn's i.MX clk/imx git branch. Otherwise, imx8-lpcg.h
> won't be found.
>
> v2->v3:
> * No change.
>
> v1->v2:
> * Use new dt binding way to add clocks in the example.
>
> .../bindings/display/imx/fsl,imx8qxp-prg.yaml | 60
> ++
> 1 file changed, 60 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-prg.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-prg.yaml
> b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-prg.yaml
> new file mode 100644
> index ..d59e2db
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-prg.yaml
> @@ -0,0 +1,60 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/imx/fsl,imx8qxp-prg.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Freescale i.MX8qm/qxp Display Prefetch Resolve Gasket
> +
> +maintainers:
> + - Liu Ying
> +
> +description: |
> + The i.MX8qm/qxp Prefetch Resolve Gasket (PRG) is a gasket interface between
> + RTRAM controller and Display Controller. The main function is to convert
> + the AXI interface to the RTRAM interface, which includes re-mapping the
> + ARADDR to a RTRAM address.
> +
> +properties:
> + compatible:
> +oneOf:
> + - const: fsl,imx8qxp-prg
> + - const: fsl,imx8qm-prg
Use enum instead of oneOf+const.
With that,
Reviewed-by: Rob Herring
> +
> + reg:
> +maxItems: 1
> +
> + clocks:
> +items:
> + - description: rtram clock
> + - description: apb clock
> +
> + clock-names:
> +items:
> + - const: rtram
> + - const: apb
> +
> + power-domains:
> +maxItems: 1
> +
> +required:
> + - compatible
> + - reg
> + - clocks
> + - clock-names
> + - power-domains
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +#include
> +#include
> +prg@5604 {
> +compatible = "fsl,imx8qxp-prg";
> +reg = <0x5604 0x1>;
> +clocks = <&dc0_prg0_lpcg IMX_LPCG_CLK_0>,
> + <&dc0_prg0_lpcg IMX_LPCG_CLK_4>;
> +clock-names = "rtram", "apb";
> +power-domains = <&pd IMX_SC_R_DC_0>;
> +};
> --
> 2.7.4
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/6] dt-bindings: display: imx: Add i.MX8qxp/qm DPU binding
On Mon, 07 Dec 2020 11:20:55 +0800, Liu Ying wrote: > This patch adds bindings for i.MX8qxp/qm Display Processing Unit. > > Signed-off-by: Liu Ying > --- > Note that this depends on the 'two cell binding' clock patch set which has > already landed in Shawn's i.MX clk/imx git branch. Otherwise, imx8-lpcg.h > won't be found. > > v2->v3: > * No change. > > v1->v2: > * Fix yamllint warnings. > * Require bypass0 and bypass1 clocks for both i.MX8qxp and i.MX8qm, as the > display controller subsystem spec does say that they exist. > * Use new dt binding way to add clocks in the example. > * Trivial tweaks for the example. > > .../bindings/display/imx/fsl,imx8qxp-dpu.yaml | 416 > + > 1 file changed, 416 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dpu.yaml > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/ttm: cleanup BO size handling
Based on an idea from Dave, but cleaned up a bit.
We had multiple fields for essentially the same thing.
Now bo->size is the original size of the BO in arbitrary
units, usually bytes.
bo->mem.num_pages is the size in number of pages in the
resource domain of bo->mem.mem_type.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c| 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h| 4 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 6 ++--
drivers/gpu/drm/amd/amdgpu/mes_v10_1.c| 2 +-
drivers/gpu/drm/nouveau/nouveau_bo.c | 10 +++---
drivers/gpu/drm/nouveau/nouveau_display.c | 8 ++---
drivers/gpu/drm/nouveau/nouveau_prime.c | 4 +--
drivers/gpu/drm/nouveau/nv17_fence.c | 2 +-
drivers/gpu/drm/nouveau/nv50_fence.c | 2 +-
drivers/gpu/drm/qxl/qxl_object.h | 2 +-
drivers/gpu/drm/radeon/radeon_cs.c| 3 +-
drivers/gpu/drm/radeon/radeon_object.c| 13
drivers/gpu/drm/radeon/radeon_object.h| 4 +--
drivers/gpu/drm/radeon/radeon_prime.c | 4 +--
drivers/gpu/drm/radeon/radeon_trace.h | 2 +-
drivers/gpu/drm/radeon/radeon_ttm.c | 2 +-
drivers/gpu/drm/ttm/ttm_bo.c | 33 ++-
drivers/gpu/drm/ttm/ttm_bo_util.c | 11 +++
drivers/gpu/drm/ttm/ttm_bo_vm.c | 6 ++--
drivers/gpu/drm/ttm/ttm_tt.c | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_blit.c | 4 +--
drivers/gpu/drm/vmwgfx/vmwgfx_bo.c| 6 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 4 +--
drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c | 5 ++-
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c| 8 ++---
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_shader.c| 3 +-
drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 4 +--
drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 7 ++--
include/drm/ttm/ttm_bo_api.h | 6 ++--
include/drm/ttm/ttm_resource.h| 1 -
36 files changed, 82 insertions(+), 100 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
index e5919efca870..c4c93f19d273 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
@@ -269,7 +269,7 @@ static struct sg_table *amdgpu_dma_buf_map(struct
dma_buf_attachment *attach,
case TTM_PL_TT:
sgt = drm_prime_pages_to_sg(obj->dev,
bo->tbo.ttm->pages,
- bo->tbo.num_pages);
+ bo->tbo.ttm->num_pages);
if (IS_ERR(sgt))
return sgt;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
index 056cb87d09ea..52bcd1b5582f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
@@ -121,7 +121,7 @@ uint64_t amdgpu_gmc_agp_addr(struct ttm_buffer_object *bo)
{
struct amdgpu_device *adev = amdgpu_ttm_adev(bo->bdev);
- if (bo->num_pages != 1 || bo->ttm->caching == ttm_cached)
+ if (bo->ttm->num_pages != 1 || bo->ttm->caching == ttm_cached)
return AMDGPU_BO_INVALID_OFFSET;
if (bo->ttm->dma_address[0] + PAGE_SIZE >= adev->gmc.agp_size)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index c6c9723d3d8a..381ecc4788d5 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -787,7 +787,7 @@ int amdgpu_bo_kmap(struct amdgpu_bo *bo, void **ptr)
if (r < 0)
return r;
- r = ttm_bo_kmap(&bo->tbo, 0, bo->tbo.num_pages, &bo->kmap);
+ r = ttm_bo_kmap(&bo->tbo, 0, bo->tbo.mem.num_pages, &bo->kmap);
if (r)
return r;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
index ed47cbac4f75..176ed3615151 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
@@ -174,12 +174,12 @@ static inline void amdgpu_bo_unreserve(struct amdgpu_bo
*bo)
static inline unsigned long amdgpu_bo_size(struct amdgpu_bo *bo)
{
- return bo->tbo.num_pages << PAGE_SHIFT;
+ return bo->tbo.size;
}
static inline unsigned amdgpu_bo_ngpu_pages(struct amdgpu_bo *bo)
{
- return (bo->tbo.num_pages << PAGE_SHIFT) / AMDGPU_GPU_PAGE_SIZE;
+ return bo->tbo.size / AMDGPU_GPU_PAGE_SIZE;
}
static inline unsigned amdgpu_bo_gpu_page_align
Re: [PATCH 4/5] drm/scheduler: Job timeout handler returns status (v2)
On 12/7/20 6:13 AM, Christian König wrote:
Am 04.12.20 um 16:10 schrieb Andrey Grodzovsky:
On 12/4/20 3:13 AM, Christian König wrote:
Thinking more about that I came to the conclusion that the whole approach
here isn't correct.
See even when the job has been completed or canceled we still want to
restart the timer.
The reason for this is that the timer is then not restarted for the current
job, but for the next job in the queue.
The only valid reason to not restart the timer is that the whole device was
hot plugged and we return -ENODEV here. E.g. what Andrey has been working on.
We discussed this with Luben off line a few days ago but came to a conclusion
that for the next job the timer restart in drm_sched_job_begin should do the
work, no ?
Nope, drm_sched_job_begin() pushes the job to the hardware and starts the
timeout in case the hardware was idle before.
drm_sched_job_begin only adds the job to ring mirror list and rearms the timer,
I don't see how it is related to whether the HW was idle before ?
Andrey
The function should probably be renamed to drm_sched_job_pushed() because it
doesn't begin the execution in any way.
Christian.
Andrey
Regards,
Christian.
Am 04.12.20 um 04:17 schrieb Luben Tuikov:
The driver's job timeout handler now returns
status indicating back to the DRM layer whether
the task (job) was successfully aborted or whether
more time should be given to the task to complete.
Default behaviour as of this patch, is preserved,
except in obvious-by-comment case in the Panfrost
driver, as documented below.
All drivers which make use of the
drm_sched_backend_ops' .timedout_job() callback
have been accordingly renamed and return the
would've-been default value of
DRM_TASK_STATUS_ALIVE to restart the task's
timeout timer--this is the old behaviour, and
is preserved by this patch.
In the case of the Panfrost driver, its timedout
callback correctly first checks if the job had
completed in due time and if so, it now returns
DRM_TASK_STATUS_COMPLETE to notify the DRM layer
that the task can be moved to the done list, to be
freed later. In the other two subsequent checks,
the value of DRM_TASK_STATUS_ALIVE is returned, as
per the default behaviour.
A more involved driver's solutions can be had
in subequent patches.
Signed-off-by: Luben Tuikov
Reported-by: kernel test robot
Cc: Alexander Deucher
Cc: Andrey Grodzovsky
Cc: Christian König
Cc: Daniel Vetter
Cc: Lucas Stach
Cc: Russell King
Cc: Christian Gmeiner
Cc: Qiang Yu
Cc: Rob Herring
Cc: Tomeu Vizoso
Cc: Steven Price
Cc: Alyssa Rosenzweig
Cc: Eric Anholt
v2: Use enum as the status of a driver's job
timeout callback method.
---
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 6 +++--
drivers/gpu/drm/etnaviv/etnaviv_sched.c | 10 +++-
drivers/gpu/drm/lima/lima_sched.c | 4 +++-
drivers/gpu/drm/panfrost/panfrost_job.c | 9 ---
drivers/gpu/drm/scheduler/sched_main.c | 4 +---
drivers/gpu/drm/v3d/v3d_sched.c | 32 +
include/drm/gpu_scheduler.h | 20 +---
7 files changed, 57 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
index ff48101bab55..a111326cbdde 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
@@ -28,7 +28,7 @@
#include "amdgpu.h"
#include "amdgpu_trace.h"
-static void amdgpu_job_timedout(struct drm_sched_job *s_job)
+static enum drm_task_status amdgpu_job_timedout(struct drm_sched_job *s_job)
{
struct amdgpu_ring *ring = to_amdgpu_ring(s_job->sched);
struct amdgpu_job *job = to_amdgpu_job(s_job);
@@ -41,7 +41,7 @@ static void amdgpu_job_timedout(struct drm_sched_job *s_job)
amdgpu_ring_soft_recovery(ring, job->vmid,
s_job->s_fence->parent)) {
DRM_ERROR("ring %s timeout, but soft recovered\n",
s_job->sched->name);
- return;
+ return DRM_TASK_STATUS_ALIVE;
}
amdgpu_vm_get_task_info(ring->adev, job->pasid, &ti);
@@ -53,10 +53,12 @@ static void amdgpu_job_timedout(struct drm_sched_job
*s_job)
if (amdgpu_device_should_recover_gpu(ring->adev)) {
amdgpu_device_gpu_recover(ring->adev, job);
+ return DRM_TASK_STATUS_ALIVE;
} else {
drm_sched_suspend_timeout(&ring->sched);
if (amdgpu_sriov_vf(adev))
adev->virt.tdr_debug = true;
+ return DRM_TASK_STATUS_ALIVE;
}
}
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
index cd46c882269c..c49516942328 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
@@ -82,7 +82,8 @@ static struct dma_fence *etnaviv_sched_run_job(struct
drm_sched_job *sched_job)
return fence;
}
-static void etnaviv_sched_timedout_job(struct drm_sched_job *sched_job)
+static enum drm_task_
Re: [PATCH 1/2] drm: add legacy support for using degamma for gamma
On Sat, Dec 05, 2020 at 12:35:25AM +0200, Laurent Pinchart wrote:
> Hi Tomi,
>
> Thank you for the patch.
>
> On Thu, Dec 03, 2020 at 01:48:44PM +0200, Tomi Valkeinen wrote:
> > We currently have drm_atomic_helper_legacy_gamma_set() helper which can
> > be used to handle legacy gamma-set ioctl.
> > drm_atomic_helper_legacy_gamma_set() sets GAMMA_LUT, and clears
> > CTM and DEGAMMA_LUT. This works fine on HW where we have either:
> >
> > degamma -> ctm -> gamma -> out
> >
> > or
> >
> > ctm -> gamma -> out
> >
> > However, if the HW has gamma table before ctm, the atomic property
> > should be DEGAMMA_LUT, and thus we have:
> >
> > degamma -> ctm -> out
> >
> > This is fine for userspace which sets gamma table using the properties,
> > as the userspace can check for the existence of gamma & degamma, but the
> > legacy gamma-set ioctl does not work.
> >
> > This patch fixes the issue by changing
> > drm_atomic_helper_legacy_gamma_set() so that GAMMA_LUT will be used if
> > it exists, and DEGAMMA_LUT will be used as a fallback.
> >
> > Signed-off-by: Tomi Valkeinen
> > ---
> > drivers/gpu/drm/drm_atomic_helper.c | 18 +++---
> > drivers/gpu/drm/drm_color_mgmt.c| 4
> > include/drm/drm_crtc.h | 3 +++
> > 3 files changed, 22 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > index ba1507036f26..fe59c8ea42a9 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -3512,6 +3512,10 @@ EXPORT_SYMBOL(drm_atomic_helper_page_flip_target);
> > * that support color management through the DEGAMMA_LUT/GAMMA_LUT
> > * properties. See drm_crtc_enable_color_mgmt() and the containing chapter
> > for
> > * how the atomic color management and gamma tables work.
> > + *
> > + * This function uses the GAMMA_LUT or DEGAMMA_LUT property for the gamma
> > table.
> > + * GAMMA_LUT property is used if it exists, and DEGAMMA_LUT property is
> > used as
> > + * a fallback.
> > */
> > int drm_atomic_helper_legacy_gamma_set(struct drm_crtc *crtc,
> >u16 *red, u16 *green, u16 *blue,
> > @@ -3525,6 +3529,12 @@ int drm_atomic_helper_legacy_gamma_set(struct
> > drm_crtc *crtc,
> > struct drm_color_lut *blob_data;
> > int i, ret = 0;
> > bool replaced;
> > + bool use_degamma;
> > +
> > + if (!crtc->has_gamma_prop && !crtc->has_degamma_prop)
> > + return -ENODEV;
> > +
> > + use_degamma = !crtc->has_gamma_prop;
> >
> > state = drm_atomic_state_alloc(crtc->dev);
> > if (!state)
> > @@ -3554,10 +3564,12 @@ int drm_atomic_helper_legacy_gamma_set(struct
> > drm_crtc *crtc,
> > goto fail;
> > }
> >
> > - /* Reset DEGAMMA_LUT and CTM properties. */
> > - replaced = drm_property_replace_blob(&crtc_state->degamma_lut, NULL);
> > + /* Set GAMMA/DEGAMMA_LUT and reset DEGAMMA/GAMMA_LUT and CTM */
> > + replaced = drm_property_replace_blob(&crtc_state->degamma_lut,
> > + use_degamma ? blob : NULL);
> > replaced |= drm_property_replace_blob(&crtc_state->ctm, NULL);
> > - replaced |= drm_property_replace_blob(&crtc_state->gamma_lut, blob);
> > + replaced |= drm_property_replace_blob(&crtc_state->gamma_lut,
> > + use_degamma ? NULL : blob);
> > crtc_state->color_mgmt_changed |= replaced;
> >
> > ret = drm_atomic_commit(state);
> > diff --git a/drivers/gpu/drm/drm_color_mgmt.c
> > b/drivers/gpu/drm/drm_color_mgmt.c
> > index 3bcabc2f6e0e..956e59d5f6a7 100644
> > --- a/drivers/gpu/drm/drm_color_mgmt.c
> > +++ b/drivers/gpu/drm/drm_color_mgmt.c
> > @@ -176,6 +176,8 @@ void drm_crtc_enable_color_mgmt(struct drm_crtc *crtc,
> >degamma_lut_size);
> > }
> >
> > + crtc->has_degamma_prop = !!degamma_lut_size;
> > +
> > if (has_ctm)
> > drm_object_attach_property(&crtc->base,
> >config->ctm_property, 0);
> > @@ -187,6 +189,8 @@ void drm_crtc_enable_color_mgmt(struct drm_crtc *crtc,
> >config->gamma_lut_size_property,
> >gamma_lut_size);
> > }
> > +
> > + crtc->has_gamma_prop = !!gamma_lut_size;
> > }
> > EXPORT_SYMBOL(drm_crtc_enable_color_mgmt);
> >
> > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> > index ba839e5e357d..9e1f06047e3d 100644
> > --- a/include/drm/drm_crtc.h
> > +++ b/include/drm/drm_crtc.h
> > @@ -1084,6 +1084,9 @@ struct drm_crtc {
> > */
> > uint16_t *gamma_store;
> >
> > + bool has_gamma_prop;
> > + bool has_degamma_prop;
>
> We could use a bitfield to save a bit of memory. Apart from that, the
> patch looks good to me.
Or we could just check if the crtc has the relevant prop or not.
>
> Reviewed-by: Laurent Pinchart
>
> > +
> >
[PATCH][next] drm/mediatek: avoid dereferencing a null hdmi_phy on an error message
From: Colin Ian King
Currently there is a null pointer check for hdmi_phy that implies it
may be null, however a dev_err messages dereferences this potential null
pointer. Avoid a null pointer dereference by only emitting the dev_err
message if hdmi_phy is non-null. It is a moot point if the error message
needs to be printed at all, but since this is a relatively new piece of
code it may be useful to keep the message in for the moment in case there
are unforseen errors that need to be reported.
Addresses-Coverity: ("Dereference after null check")
Fixes: be28b6507c46 ("drm/mediatek: separate hdmi phy to different file")
Signed-off-by: Colin Ian King
---
drivers/phy/mediatek/phy-mtk-hdmi.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/phy/mediatek/phy-mtk-hdmi.c
b/drivers/phy/mediatek/phy-mtk-hdmi.c
index c5c61f5a9ea0..5184054783c7 100644
--- a/drivers/phy/mediatek/phy-mtk-hdmi.c
+++ b/drivers/phy/mediatek/phy-mtk-hdmi.c
@@ -84,8 +84,9 @@ mtk_hdmi_phy_dev_get_ops(const struct mtk_hdmi_phy *hdmi_phy)
hdmi_phy->conf->hdmi_phy_disable_tmds)
return &mtk_hdmi_phy_dev_ops;
- dev_err(hdmi_phy->dev, "Failed to get dev ops of phy\n");
- return NULL;
+ if (hdmi_phy)
+ dev_err(hdmi_phy->dev, "Failed to get dev ops of phy\n");
+ return NULL;
}
static void mtk_hdmi_phy_clk_get_data(struct mtk_hdmi_phy *hdmi_phy,
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 6/8] drm/vc4: hdmi: Use the connector state pixel rate for the PHY
Am 07.12.20 um 14:39 schrieb Maxime Ripard:
The PHY initialisation parameters are not based on the pixel clock but
the TMDS clock rate which can be the pixel clock in the standard case,
but could be adjusted based on some parameters like the bits per color.
Since the TMDS clock rate is stored in our custom connector state
already, let's reuse it from there instead of computing it again.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 2 +-
drivers/gpu/drm/vc4/vc4_hdmi.h | 9 -
drivers/gpu/drm/vc4/vc4_hdmi_phy.c | 8 +---
3 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index c1667cfe37db..795fd23c8f58 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -714,7 +714,7 @@ static void vc4_hdmi_encoder_pre_crtc_configure(struct
drm_encoder *encoder,
vc4_hdmi->variant->reset(vc4_hdmi);
if (vc4_hdmi->variant->phy_init)
- vc4_hdmi->variant->phy_init(vc4_hdmi, mode);
+ vc4_hdmi->variant->phy_init(vc4_hdmi, vc4_conn_state);
HDMI_WRITE(HDMI_SCHEDULER_CONTROL,
HDMI_READ(HDMI_SCHEDULER_CONTROL) |
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
index bca6943de884..6cc5b6652cca 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.h
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
@@ -21,10 +21,9 @@ to_vc4_hdmi_encoder(struct drm_encoder *encoder)
return container_of(encoder, struct vc4_hdmi_encoder, base.base);
}
-struct drm_display_mode;
-
struct vc4_hdmi;
struct vc4_hdmi_register;
+struct vc4_hdmi_connector_state;
enum vc4_hdmi_phy_channel {
PHY_LANE_0 = 0,
@@ -82,7 +81,7 @@ struct vc4_hdmi_variant {
/* Callback to initialize the PHY according to the mode */
Rather 'according to the connector state'? OTOH these comments don't
seem to add any information. They might just be removed. :)
The patch in general is
Acked-by: Thomas Zimmermann
void (*phy_init)(struct vc4_hdmi *vc4_hdmi,
-struct drm_display_mode *mode);
+struct vc4_hdmi_connector_state *vc4_conn_state);
/* Callback to disable the PHY */
void (*phy_disable)(struct vc4_hdmi *vc4_hdmi);
@@ -192,13 +191,13 @@ conn_state_to_vc4_hdmi_conn_state(struct
drm_connector_state *conn_state)
}
void vc4_hdmi_phy_init(struct vc4_hdmi *vc4_hdmi,
- struct drm_display_mode *mode);
+ struct vc4_hdmi_connector_state *vc4_conn_state);
void vc4_hdmi_phy_disable(struct vc4_hdmi *vc4_hdmi);
void vc4_hdmi_phy_rng_enable(struct vc4_hdmi *vc4_hdmi);
void vc4_hdmi_phy_rng_disable(struct vc4_hdmi *vc4_hdmi);
void vc5_hdmi_phy_init(struct vc4_hdmi *vc4_hdmi,
- struct drm_display_mode *mode);
+ struct vc4_hdmi_connector_state *vc4_conn_state);
void vc5_hdmi_phy_disable(struct vc4_hdmi *vc4_hdmi);
void vc5_hdmi_phy_rng_enable(struct vc4_hdmi *vc4_hdmi);
void vc5_hdmi_phy_rng_disable(struct vc4_hdmi *vc4_hdmi);
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi_phy.c
b/drivers/gpu/drm/vc4/vc4_hdmi_phy.c
index 057796b54c51..36535480f8e2 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi_phy.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi_phy.c
@@ -127,7 +127,8 @@
#define OSCILLATOR_FREQUENCY 5400
-void vc4_hdmi_phy_init(struct vc4_hdmi *vc4_hdmi, struct drm_display_mode *mode)
+void vc4_hdmi_phy_init(struct vc4_hdmi *vc4_hdmi,
+ struct vc4_hdmi_connector_state *conn_state)
{
/* PHY should be in reset, like
* vc4_hdmi_encoder_disable() does.
@@ -339,11 +340,12 @@ static void vc5_hdmi_reset_phy(struct vc4_hdmi *vc4_hdmi)
HDMI_WRITE(HDMI_TX_PHY_POWERDOWN_CTL, BIT(10));
}
-void vc5_hdmi_phy_init(struct vc4_hdmi *vc4_hdmi, struct drm_display_mode *mode)
+void vc5_hdmi_phy_init(struct vc4_hdmi *vc4_hdmi,
+ struct vc4_hdmi_connector_state *conn_state)
{
const struct phy_lane_settings *chan0_settings, *chan1_settings,
*chan2_settings, *clock_settings;
const struct vc4_hdmi_variant *variant = vc4_hdmi->variant;
- unsigned long long pixel_freq = mode->clock * 1000;
+ unsigned long long pixel_freq = conn_state->pixel_rate;
unsigned long long vco_freq;
unsigned char word_sel;
u8 vco_sel, vco_div;
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 2/8] drm/vc4: Pass the atomic state to encoder hooks
Am 07.12.20 um 14:39 schrieb Maxime Ripard:
We'll need to access the connector state in our encoder setup, so let's
just pass the whole DRM state to our private encoder hooks.
Signed-off-by: Maxime Ripard
This becomes relevant in patch 5, I guess? If so
Acked-by: Thomas Zimmermann
---
drivers/gpu/drm/vc4/vc4_crtc.c | 18 ++
drivers/gpu/drm/vc4/vc4_drv.h | 10 +-
drivers/gpu/drm/vc4/vc4_hdmi.c | 15 ++-
3 files changed, 25 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index e02e499885ed..a3439756594c 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -403,7 +403,9 @@ static void require_hvs_enabled(struct drm_device *dev)
SCALER_DISPCTRL_ENABLE);
}
-static int vc4_crtc_disable(struct drm_crtc *crtc, unsigned int channel)
+static int vc4_crtc_disable(struct drm_crtc *crtc,
+ struct drm_atomic_state *state,
+ unsigned int channel)
{
struct drm_encoder *encoder = vc4_get_crtc_encoder(crtc);
struct vc4_encoder *vc4_encoder = to_vc4_encoder(encoder);
@@ -435,13 +437,13 @@ static int vc4_crtc_disable(struct drm_crtc *crtc,
unsigned int channel)
mdelay(20);
if (vc4_encoder && vc4_encoder->post_crtc_disable)
- vc4_encoder->post_crtc_disable(encoder);
+ vc4_encoder->post_crtc_disable(encoder, state);
vc4_crtc_pixelvalve_reset(crtc);
vc4_hvs_stop_channel(dev, channel);
if (vc4_encoder && vc4_encoder->post_crtc_powerdown)
- vc4_encoder->post_crtc_powerdown(encoder);
+ vc4_encoder->post_crtc_powerdown(encoder, state);
return 0;
}
@@ -468,7 +470,7 @@ int vc4_crtc_disable_at_boot(struct drm_crtc *crtc)
if (channel < 0)
return 0;
- return vc4_crtc_disable(crtc, channel);
+ return vc4_crtc_disable(crtc, NULL, channel);
}
static void vc4_crtc_atomic_disable(struct drm_crtc *crtc,
@@ -484,7 +486,7 @@ static void vc4_crtc_atomic_disable(struct drm_crtc *crtc,
/* Disable vblank irq handling before crtc is disabled. */
drm_crtc_vblank_off(crtc);
- vc4_crtc_disable(crtc, old_vc4_state->assigned_channel);
+ vc4_crtc_disable(crtc, state, old_vc4_state->assigned_channel);
/*
* Make sure we issue a vblank event after disabling the CRTC if
@@ -518,14 +520,14 @@ static void vc4_crtc_atomic_enable(struct drm_crtc *crtc,
vc4_hvs_atomic_enable(crtc, state);
if (vc4_encoder->pre_crtc_configure)
- vc4_encoder->pre_crtc_configure(encoder);
+ vc4_encoder->pre_crtc_configure(encoder, state);
vc4_crtc_config_pv(crtc);
CRTC_WRITE(PV_CONTROL, CRTC_READ(PV_CONTROL) | PV_CONTROL_EN);
if (vc4_encoder->pre_crtc_enable)
- vc4_encoder->pre_crtc_enable(encoder);
+ vc4_encoder->pre_crtc_enable(encoder, state);
/* When feeding the transposer block the pixelvalve is unneeded and
* should not be enabled.
@@ -534,7 +536,7 @@ static void vc4_crtc_atomic_enable(struct drm_crtc *crtc,
CRTC_READ(PV_V_CONTROL) | PV_VCONTROL_VIDEN);
if (vc4_encoder->post_crtc_enable)
- vc4_encoder->post_crtc_enable(encoder);
+ vc4_encoder->post_crtc_enable(encoder, state);
}
static enum drm_mode_status vc4_crtc_mode_valid(struct drm_crtc *crtc,
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index c47c85533805..b404cd3ab0d8 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -444,12 +444,12 @@ struct vc4_encoder {
enum vc4_encoder_type type;
u32 clock_select;
- void (*pre_crtc_configure)(struct drm_encoder *encoder);
- void (*pre_crtc_enable)(struct drm_encoder *encoder);
- void (*post_crtc_enable)(struct drm_encoder *encoder);
+ void (*pre_crtc_configure)(struct drm_encoder *encoder, struct
drm_atomic_state *state);
+ void (*pre_crtc_enable)(struct drm_encoder *encoder, struct
drm_atomic_state *state);
+ void (*post_crtc_enable)(struct drm_encoder *encoder, struct
drm_atomic_state *state);
- void (*post_crtc_disable)(struct drm_encoder *encoder);
- void (*post_crtc_powerdown)(struct drm_encoder *encoder);
+ void (*post_crtc_disable)(struct drm_encoder *encoder, struct
drm_atomic_state *state);
+ void (*post_crtc_powerdown)(struct drm_encoder *encoder, struct
drm_atomic_state *state);
};
static inline struct vc4_encoder *
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index afc178b0d89f..5a608ed1d75e 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -357,7 +357,8 @@ static void vc4_hdmi_set_infoframes(struct drm_encoder
*encoder)
vc4_hdmi_set_audio_infoframe(encoder);
Re: [PATCH v4 5/8] drm/vc4: hdmi: Store pixel frequency in the connector state
Hi
Am 07.12.20 um 14:39 schrieb Maxime Ripard:
The pixel rate is for now quite simple to compute, but with more features
(30 and 36 bits output, YUV output, etc.) will depend on a bunch of
connectors properties.
Let's store the rate we have to run the pixel clock at in our custom
connector state, and compute it in atomic_check.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 26 +-
drivers/gpu/drm/vc4/vc4_hdmi.h | 1 +
2 files changed, 26 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 862c93708e9a..c1667cfe37db 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -194,6 +194,7 @@ vc4_hdmi_connector_duplicate_state(struct drm_connector
*connector)
if (!new_state)
return NULL;
+ new_state->pixel_rate = vc4_state->pixel_rate;
__drm_atomic_helper_connector_duplicate_state(connector,
&new_state->base);
return &new_state->base;
@@ -611,9 +612,29 @@ static void vc4_hdmi_recenter_fifo(struct vc4_hdmi
*vc4_hdmi)
"VC4_HDMI_FIFO_CTL_RECENTER_DONE");
}
+static struct drm_connector_state *
+vc4_hdmi_encoder_get_connector_state(struct drm_encoder *encoder,
+struct drm_atomic_state *state)
+{
+ struct drm_connector_state *conn_state;
+ struct drm_connector *connector;
+ unsigned int i;
+
+ for_each_new_connector_in_state(state, connector, conn_state, i) {
+ if (conn_state->best_encoder == encoder)
+ return conn_state;
+ }
+
+ return NULL;
+}
+
static void vc4_hdmi_encoder_pre_crtc_configure(struct drm_encoder *encoder,
struct drm_atomic_state *state)
{
+ struct drm_connector_state *conn_state =
+ vc4_hdmi_encoder_get_connector_state(encoder, state);
+ struct vc4_hdmi_connector_state *vc4_conn_state =
+ conn_state_to_vc4_hdmi_conn_state(conn_state);
struct drm_display_mode *mode = &encoder->crtc->state->adjusted_mode;
struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
unsigned long pixel_rate, hsm_rate;
@@ -625,7 +646,7 @@ static void vc4_hdmi_encoder_pre_crtc_configure(struct
drm_encoder *encoder,
return;
}
- pixel_rate = mode->clock * 1000 * ((mode->flags & DRM_MODE_FLAG_DBLCLK) ? 2 : 1);
Has (mode->flags & DRM_MODE_FLAG_DBLCLK) been lost? I cannot find it any
longer. The code in atomic_check() looks significantly different.
Best regards
Thomas
+ pixel_rate = vc4_conn_state->pixel_rate;
ret = clk_set_rate(vc4_hdmi->pixel_clock, pixel_rate);
if (ret) {
DRM_ERROR("Failed to set pixel clock rate: %d\n", ret);
@@ -797,6 +818,7 @@ static int vc4_hdmi_encoder_atomic_check(struct drm_encoder
*encoder,
struct drm_crtc_state *crtc_state,
struct drm_connector_state *conn_state)
{
+ struct vc4_hdmi_connector_state *vc4_state =
conn_state_to_vc4_hdmi_conn_state(conn_state);
struct drm_display_mode *mode = &crtc_state->adjusted_mode;
struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
unsigned long long pixel_rate = mode->clock * 1000;
@@ -824,6 +846,8 @@ static int vc4_hdmi_encoder_atomic_check(struct drm_encoder
*encoder,
if (pixel_rate > vc4_hdmi->variant->max_pixel_clock)
return -EINVAL;
+ vc4_state->pixel_rate = pixel_rate;
+
return 0;
}
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
index 2cf5362052e2..bca6943de884 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.h
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
@@ -182,6 +182,7 @@ encoder_to_vc4_hdmi(struct drm_encoder *encoder)
struct vc4_hdmi_connector_state {
struct drm_connector_state base;
+ unsigned long long pixel_rate;
};
static inline struct vc4_hdmi_connector_state *
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 4/8] drm/vc4: hdmi: Create a custom connector state
Am 07.12.20 um 14:39 schrieb Maxime Ripard:
When run with a higher bpc than 8, the clock of the HDMI controller needs
to be adjusted. Let's create a connector state that will be used at
atomic_check and atomic_enable to compute and store the clock rate
associated to the state.
Signed-off-by: Maxime Ripard
Acked-by: Thomas Zimmermann
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 27 +--
drivers/gpu/drm/vc4/vc4_hdmi.h | 10 ++
2 files changed, 35 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 112c09873eb4..862c93708e9a 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -170,18 +170,41 @@ static int vc4_hdmi_connector_get_modes(struct
drm_connector *connector)
static void vc4_hdmi_connector_reset(struct drm_connector *connector)
{
- drm_atomic_helper_connector_reset(connector);
+ struct vc4_hdmi_connector_state *conn_state =
kzalloc(sizeof(*conn_state), GFP_KERNEL);
+
+ if (connector->state)
+ __drm_atomic_helper_connector_destroy_state(connector->state);
+
+ kfree(connector->state);
+
+ __drm_atomic_helper_connector_reset(connector, &conn_state->base);
if (connector->state)
drm_atomic_helper_connector_tv_reset(connector);
}
+static struct drm_connector_state *
+vc4_hdmi_connector_duplicate_state(struct drm_connector *connector)
+{
+ struct drm_connector_state *conn_state = connector->state;
+ struct vc4_hdmi_connector_state *vc4_state =
conn_state_to_vc4_hdmi_conn_state(conn_state);
+ struct vc4_hdmi_connector_state *new_state;
+
+ new_state = kzalloc(sizeof(*new_state), GFP_KERNEL);
+ if (!new_state)
+ return NULL;
+
+ __drm_atomic_helper_connector_duplicate_state(connector,
&new_state->base);
+
+ return &new_state->base;
+}
+
static const struct drm_connector_funcs vc4_hdmi_connector_funcs = {
.detect = vc4_hdmi_connector_detect,
.fill_modes = drm_helper_probe_single_connector_modes,
.destroy = vc4_hdmi_connector_destroy,
.reset = vc4_hdmi_connector_reset,
- .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+ .atomic_duplicate_state = vc4_hdmi_connector_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
};
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
index 0526a9cf608a..2cf5362052e2 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.h
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
@@ -180,6 +180,16 @@ encoder_to_vc4_hdmi(struct drm_encoder *encoder)
return container_of(_encoder, struct vc4_hdmi, encoder);
}
+struct vc4_hdmi_connector_state {
+ struct drm_connector_state base;
+};
+
+static inline struct vc4_hdmi_connector_state *
+conn_state_to_vc4_hdmi_conn_state(struct drm_connector_state *conn_state)
+{
+ return container_of(conn_state, struct vc4_hdmi_connector_state, base);
+}
+
void vc4_hdmi_phy_init(struct vc4_hdmi *vc4_hdmi,
struct drm_display_mode *mode);
void vc4_hdmi_phy_disable(struct vc4_hdmi *vc4_hdmi);
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 3/8] drm/vc4: hdmi: Don't access the connector state in reset if kmalloc fails
Am 07.12.20 um 14:39 schrieb Maxime Ripard:
drm_atomic_helper_connector_reset uses kmalloc which, from an API
standpoint, can fail, and thus setting connector->state to NULL.
However, our reset hook then calls drm_atomic_helper_connector_tv_reset
that will access connector->state without checking if it's a valid
pointer or not.
Make sure we don't end up accessing a NULL pointer.
Suggested-by: Dave Stevenson
Signed-off-by: Maxime Ripard
Acked-by: Thomas Zimmermann
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 5a608ed1d75e..112c09873eb4 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -171,7 +171,9 @@ static int vc4_hdmi_connector_get_modes(struct
drm_connector *connector)
static void vc4_hdmi_connector_reset(struct drm_connector *connector)
{
drm_atomic_helper_connector_reset(connector);
- drm_atomic_helper_connector_tv_reset(connector);
+
+ if (connector->state)
+ drm_atomic_helper_connector_tv_reset(connector);
}
static const struct drm_connector_funcs vc4_hdmi_connector_funcs = {
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 13/13] video: fbdev: sis: Drop useless call to SiS_GetResInfo()
Am 06.12.20 um 20:02 schrieb Sam Ravnborg:
Coverity reported:
Useless call (USELESS_CALL) side_effect_free: Calling
SiS_GetResInfo(SiS_Pr, ModeNo, ModeIdIndex) is only useful for its
return value, which is ignored.
And this is correct - so drop the call.
Signed-off-by: Sam Ravnborg
Reported-by: Colin Ian King
Addresses-Coverity: ("Useless call")
Cc: Colin Ian King
Cc: Thomas Winischhofer
Acked-by: Thomas Zimmermann
---
drivers/video/fbdev/sis/init.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/video/fbdev/sis/init.c b/drivers/video/fbdev/sis/init.c
index b77ea1a8825a..b568c646a76c 100644
--- a/drivers/video/fbdev/sis/init.c
+++ b/drivers/video/fbdev/sis/init.c
@@ -2659,7 +2659,6 @@ SiS_SetCRT1ModeRegs(struct SiS_Private *SiS_Pr, unsigned
short ModeNo,
if(SiS_Pr->UseCustomMode) {
infoflag = SiS_Pr->CInfoFlag;
} else {
- SiS_GetResInfo(SiS_Pr, ModeNo, ModeIdIndex);
if(ModeNo > 0x13) {
infoflag = SiS_Pr->SiS_RefIndex[RRTI].Ext_InfoFlag;
}
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 12/13] video: fbdev: controlfb: Fix set but not used warnings
Am 06.12.20 um 20:02 schrieb Sam Ravnborg:
The controlfb driver has a number of dummy defines for IO operations.
They were introduced in commit a07a63b0e24d
("video: fbdev: controlfb: add COMPILE_TEST support").
The write variants did not use their value parameter in the
dummy versions, resulting in set but not used warnings.
Fix this by adding "(void)val" to silence the compiler.
Signed-off-by: Sam Ravnborg
Cc: Sam Ravnborg
Cc: Bartlomiej Zolnierkiewicz
Cc: "Gustavo A. R. Silva"
Cc: Michael Ellerman
Acked-by: Thomas Zimmermann
---
drivers/video/fbdev/controlfb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/controlfb.c b/drivers/video/fbdev/controlfb.c
index 2df56bd303d2..509311471d51 100644
--- a/drivers/video/fbdev/controlfb.c
+++ b/drivers/video/fbdev/controlfb.c
@@ -64,9 +64,9 @@
#undef in_le32
#undef out_le32
#define in_8(addr)0
-#define out_8(addr, val)
+#define out_8(addr, val) (void)(val)
#define in_le32(addr) 0
-#define out_le32(addr, val)
+#define out_le32(addr, val)(void)(val)
#define pgprot_cached_wthru(prot) (prot)
#else
static void invalid_vram_cache(void __force *addr)
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 11/13] video: fbdev: efifb: Fix set but not used warning for screen_pitch
Am 06.12.20 um 20:02 schrieb Sam Ravnborg:
screen_pitch was asssigned a value which was never used.
Drop it to fix the warning
Signed-off-by: Sam Ravnborg
Cc: Peter Jones
Cc: linux-fb...@vger.kernel.org
Acked-by: Thomas Zimmermann
---
drivers/video/fbdev/efifb.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
index e57c00824965..b80ba3d2a9b8 100644
--- a/drivers/video/fbdev/efifb.c
+++ b/drivers/video/fbdev/efifb.c
@@ -139,7 +139,7 @@ static bool efifb_bgrt_sanity_check(struct screen_info *si,
u32 bmp_width)
static void efifb_show_boot_graphics(struct fb_info *info)
{
- u32 bmp_width, bmp_height, bmp_pitch, screen_pitch, dst_x, y, src_y;
+ u32 bmp_width, bmp_height, bmp_pitch, dst_x, y, src_y;
struct screen_info *si = &screen_info;
struct bmp_file_header *file_header;
struct bmp_dib_header *dib_header;
@@ -193,7 +193,6 @@ static void efifb_show_boot_graphics(struct fb_info *info)
bmp_width = dib_header->width;
bmp_height = abs(dib_header->height);
bmp_pitch = round_up(3 * bmp_width, 4);
- screen_pitch = si->lfb_linelength;
if ((file_header->bitmap_offset + bmp_pitch * bmp_height) >
bgrt_image_size)
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 10/13] video: fbdev: gbefb: Fix set but not used warning
Am 06.12.20 um 20:02 schrieb Sam Ravnborg:
The variable "x" was set but never used.
Drop the redundant assignments.
Signed-off-by: Sam Ravnborg
Cc: Sam Ravnborg
Acked-by: Thomas Zimmermann
---
drivers/video/fbdev/gbefb.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/video/fbdev/gbefb.c b/drivers/video/fbdev/gbefb.c
index 31270a8986e8..c5b99a4861e8 100644
--- a/drivers/video/fbdev/gbefb.c
+++ b/drivers/video/fbdev/gbefb.c
@@ -198,7 +198,7 @@ static void gbe_reset(void)
static void gbe_turn_off(void)
{
int i;
- unsigned int val, x, y, vpixen_off;
+ unsigned int val, y, vpixen_off;
gbe_turned_on = 0;
@@ -249,7 +249,6 @@ static void gbe_turn_off(void)
for (i = 0; i < 10; i++) {
val = gbe->vt_xy;
- x = GET_GBE_FIELD(VT_XY, X, val);
y = GET_GBE_FIELD(VT_XY, Y, val);
if (y < vpixen_off)
break;
@@ -260,7 +259,6 @@ static void gbe_turn_off(void)
"gbefb: wait for vpixen_off timed out\n");
for (i = 0; i < 1; i++) {
val = gbe->vt_xy;
- x = GET_GBE_FIELD(VT_XY, X, val);
y = GET_GBE_FIELD(VT_XY, Y, val);
if (y > vpixen_off)
break;
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] drm: panel: add Khadas TS050 panel driver
Hi,
On 05/12/2020 20:15, Sam Ravnborg wrote:
> Hi Neil,
>
>> +
>> +static int khadas_ts050_panel_probe(struct mipi_dsi_device *dsi)
>> +{
>> +struct khadas_ts050_panel *khadas_ts050;
>> +int err;
>> +
>> +dsi->lanes = 4;
>> +dsi->format = MIPI_DSI_FMT_RGB888;
>> +dsi->mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
>> + MIPI_DSI_MODE_LPM | MIPI_DSI_MODE_EOT_PACKET;
>> +
>> +khadas_ts050 = devm_kzalloc(&dsi->dev, sizeof(*khadas_ts050),
>> +GFP_KERNEL);
>> +if (!khadas_ts050)
>> +return -ENOMEM;
>> +
>> +mipi_dsi_set_drvdata(dsi, khadas_ts050);
>> +khadas_ts050->link = dsi;
>> +
>> +err = khadas_ts050_panel_add(khadas_ts050);
>> +if (err < 0)
>> +return err;
>> +
>> +return mipi_dsi_attach(dsi);
>> +}
>
> If mipi_dsi_attach() failes then da a drm_panel_remove() like this:
>
> ret = mipi_dsi_attach(dsi);
> if (ret)
> drm_panel_remove(&khadas_ts050->base);
>
> return ret;
>
> This is again something several panels gets wrong.
>
> With this fixed:
> Reviewed-by: Sam Ravnborg
>
> I assume you will fix it while applying.
Sure, thanks !
Neil
>
> Sam
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 09/13] video: fbdev: goldfishfb: Fix defined but not used warning
Am 06.12.20 um 20:02 schrieb Sam Ravnborg:
The goldfish_fb_acpi_match table is only used with ACPI enabled.
Ifdef it out unless it is needed.
This is a similar fix to what other acpi drivers do.
Signed-off-by: Sam Ravnborg
Cc: Sam Ravnborg
Acked-by: Thomas Zimmermann
---
drivers/video/fbdev/goldfishfb.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/video/fbdev/goldfishfb.c b/drivers/video/fbdev/goldfishfb.c
index 9c83ec3f8e1f..2b885cd046fe 100644
--- a/drivers/video/fbdev/goldfishfb.c
+++ b/drivers/video/fbdev/goldfishfb.c
@@ -305,11 +305,13 @@ static const struct of_device_id goldfish_fb_of_match[] =
{
};
MODULE_DEVICE_TABLE(of, goldfish_fb_of_match);
+#ifdef CONFIG_ACPI
static const struct acpi_device_id goldfish_fb_acpi_match[] = {
{ "GFSH0004", 0 },
{ },
};
MODULE_DEVICE_TABLE(acpi, goldfish_fb_acpi_match);
+#endif
static struct platform_driver goldfish_fb_driver = {
.probe = goldfish_fb_probe,
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 08/13] video: fbdev: wmt_ge_rops: Fix function not declared warnings
Am 06.12.20 um 20:02 schrieb Sam Ravnborg: Include own header to fix "function not declared" warnings. Signed-off-by: Sam Ravnborg Cc: Tony Prisk Cc: linux-arm-ker...@lists.infradead.org Acked-by: Thomas Zimmermann --- drivers/video/fbdev/wmt_ge_rops.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/video/fbdev/wmt_ge_rops.c b/drivers/video/fbdev/wmt_ge_rops.c index 2445cfe617a9..42255d27a1db 100644 --- a/drivers/video/fbdev/wmt_ge_rops.c +++ b/drivers/video/fbdev/wmt_ge_rops.c @@ -11,6 +11,7 @@ #include #include #include "core/fb_draw.h" +#include "wmt_ge_rops.h" #define GE_COMMAND_OFF 0x00 #define GE_DEPTH_OFF 0x04 -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer OpenPGP_signature Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 07/13] video: fbdev: mmp: Fix kernel-doc warning for lcd_spi_write
Am 06.12.20 um 20:02 schrieb Sam Ravnborg: Add missing parameter and drop parameter that is not present Signed-off-by: Sam Ravnborg Cc: Sam Ravnborg Cc: Andrzej Hajda Cc: Bartlomiej Zolnierkiewicz Acked-by: Thomas Zimmermann --- drivers/video/fbdev/mmp/hw/mmp_spi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/fbdev/mmp/hw/mmp_spi.c b/drivers/video/fbdev/mmp/hw/mmp_spi.c index 1911a47769b6..16401eb95c6c 100644 --- a/drivers/video/fbdev/mmp/hw/mmp_spi.c +++ b/drivers/video/fbdev/mmp/hw/mmp_spi.c @@ -17,8 +17,8 @@ /** * spi_write - write command to the SPI port + * @spi: the SPI device. * @data: can be 8/16/32-bit, MSB justified data to write. - * @len: data length. * * Wait bus transfer complete IRQ. * The caller is expected to perform the necessary locking. -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer OpenPGP_signature Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drivers: gpu: drm: virtio: fix dependency of DRM_VIRTIO_GPU on VIRTIO
On Fri, Dec 04, 2020 at 02:12:21PM +0100, Enrico Weigelt, metux IT consult wrote: VIRTIO itself has no dependencies and therefore can easily be just select'ed, instead of depending on it. The current depends on causes any others trying to select VIRTIO to fail like this: drivers/gpu/drm/Kconfig:74:error: recursive dependency detected! drivers/gpu/drm/Kconfig:74: symbol DRM_KMS_HELPER is selected by DRM_VIRTIO_GPU drivers/gpu/drm/virtio/Kconfig:2: symbol DRM_VIRTIO_GPU depends on VIRTIO drivers/virtio/Kconfig:2: symbol VIRTIO is selected by GPIO_VIRTIO drivers/gpio/Kconfig:1618:symbol GPIO_VIRTIO depends on GPIOLIB drivers/gpio/Kconfig:14: symbol GPIOLIB is selected by I2C_MUX_LTC4306 drivers/i2c/muxes/Kconfig:47: symbol I2C_MUX_LTC4306 depends on I2C drivers/i2c/Kconfig:8:symbol I2C is selected by FB_DDC drivers/video/fbdev/Kconfig:63: symbol FB_DDC depends on FB drivers/video/fbdev/Kconfig:12: symbol FB is selected by DRM_KMS_FB_HELPER drivers/gpu/drm/Kconfig:80: symbol DRM_KMS_FB_HELPER depends on DRM_KMS_HELPER It seems that having both 'depends on' as well as 'select' on the same symbol sends us into big trouble, and Kconfig can't break up the circular dependency (note that in the tested configuration, neither I2C, FB or DRM are enabled at all). Perhaps we could consider this a bug in Kconfig, but the trouble can easily be circumvented by changing 'depends on' into 'select'. DRM_VIRTIO_GPU also depends on VIRTIO_MENU, so even after this change, that option will only show up if the user already enabled virtio in the config. This change didn't cause any changes in the .config after menuconfig run, so we should be completely safe here. Signed-off-by: Enrico Weigelt, metux IT consult Ok for me. Thank you. Reviewed-by: Anthoine Bourgeois --- drivers/gpu/drm/virtio/Kconfig | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/virtio/Kconfig b/drivers/gpu/drm/virtio/Kconfig index b925b8b1da16..51ec7c3240c9 100644 --- a/drivers/gpu/drm/virtio/Kconfig +++ b/drivers/gpu/drm/virtio/Kconfig @@ -1,7 +1,8 @@ # SPDX-License-Identifier: GPL-2.0-only config DRM_VIRTIO_GPU tristate "Virtio GPU driver" - depends on DRM && VIRTIO && VIRTIO_MENU && MMU + depends on DRM && VIRTIO_MENU && MMU + select VIRTIO select DRM_KMS_HELPER select DRM_GEM_SHMEM_HELPER select VIRTIO_DMA_SHARED_BUFFER -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [RFC PATCH 113/162] drm/i915: Create stolen memory region from local memory
On Fri, 27 Nov 2020, Matthew Auld wrote:
> From: CQ Tang
>
> Add "REGION_STOLEN" device info to dg1, create stolen memory
> region from upper portion of local device memory, starting
> from DSMBASE.
>
> The memory region is marked with "is_devmem=true".
>
> Cc: Joonas Lahtinen
> Cc: Matthew Auld
> Cc: Abdiel Janulgue
> Cc: Chris P Wilson
> Cc: Balestrieri, Francesco
> Cc: Niranjana Vishwanathapura
> Cc: Venkata S Dhanalakota
> Cc: Neel Desai
> Cc: Matthew Brost
> Cc: Sudeep Dutt
> Signed-off-by: CQ Tang
> Cc: Lucas De Marchi
> ---
> drivers/gpu/drm/i915/gem/i915_gem_lmem.c | 4 +-
> drivers/gpu/drm/i915/gem/i915_gem_lmem.h | 7 +++
> drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 56 +-
> drivers/gpu/drm/i915/i915_pci.c| 2 +-
> drivers/gpu/drm/i915/i915_reg.h| 1 +
> drivers/gpu/drm/i915/intel_memory_region.c | 5 ++
> drivers/gpu/drm/i915/intel_memory_region.h | 2 +-
> 7 files changed, 71 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
> b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
> index 71c07e1f6f26..b2fd2bc862c0 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
> @@ -111,8 +111,8 @@ int i915_gem_object_lmem_pread(struct drm_i915_gem_object
> *obj,
> return ret;
> }
>
> -static int i915_gem_object_lmem_pwrite(struct drm_i915_gem_object *obj,
> -const struct drm_i915_gem_pwrite *arg)
> +int i915_gem_object_lmem_pwrite(struct drm_i915_gem_object *obj,
> + const struct drm_i915_gem_pwrite *arg)
> {
> struct drm_i915_private *i915 = to_i915(obj->base.dev);
> struct intel_runtime_pm *rpm = &i915->runtime_pm;
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_lmem.h
> b/drivers/gpu/drm/i915/gem/i915_gem_lmem.h
> index e11e0545e39c..c59aa6c014c7 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_lmem.h
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_lmem.h
> @@ -11,9 +11,16 @@
> struct drm_i915_private;
> struct drm_i915_gem_object;
> struct intel_memory_region;
> +struct drm_i915_gem_pread;
> +struct drm_i915_gem_pwrite;
>
> extern const struct drm_i915_gem_object_ops i915_gem_lmem_obj_ops;
>
> +int i915_gem_object_lmem_pread(struct drm_i915_gem_object *obj,
> +const struct drm_i915_gem_pread *args);
> +int i915_gem_object_lmem_pwrite(struct drm_i915_gem_object *obj,
> + const struct drm_i915_gem_pwrite *args);
> +
> void __iomem *
> i915_gem_object_lmem_io_map(struct drm_i915_gem_object *obj,
> unsigned long n,
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> index 0ddf48e472a0..633745336f40 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> @@ -10,6 +10,7 @@
> #include
> #include
>
> +#include "gem/i915_gem_lmem.h"
> #include "gem/i915_gem_region.h"
> #include "i915_drv.h"
> #include "i915_gem_stolen.h"
> @@ -121,6 +122,14 @@ static int i915_adjust_stolen(struct drm_i915_private
> *i915,
> }
> }
>
> + /*
> + * With device local memory, we don't need to check the address range,
> + * this is device memory physical address, could overlap with system
> + * memory.
> + */
> + if (HAS_LMEM(i915))
> + return 0;
> +
> /*
>* Verify that nothing else uses this physical address. Stolen
>* memory should be reserved by the BIOS and hidden from the
> @@ -607,7 +616,7 @@ static void i915_gem_object_put_pages_stolen(struct
> drm_i915_gem_object *obj,
> kfree(pages);
> }
>
> -static const struct drm_i915_gem_object_ops i915_gem_object_stolen_ops = {
> +static struct drm_i915_gem_object_ops i915_gem_object_stolen_ops = {
Making driver specific ops non-const seems suspicious...
> .name = "i915_gem_object_stolen",
> .get_pages = i915_gem_object_get_pages_stolen,
> .put_pages = i915_gem_object_put_pages_stolen,
> @@ -716,7 +725,19 @@ i915_gem_object_create_stolen(struct drm_i915_private
> *i915,
>
> static int init_stolen(struct intel_memory_region *mem)
> {
> - intel_memory_region_set_name(mem, "stolen");
> + if (mem->type == INTEL_MEMORY_STOLEN_SYSTEM)
> + intel_memory_region_set_name(mem, "stolen-system");
> + else
> + intel_memory_region_set_name(mem, "stolen-local");
> +
> + if (HAS_LMEM(mem->i915)) {
> + i915_gem_object_stolen_ops.pread = i915_gem_object_lmem_pread;
> + i915_gem_object_stolen_ops.pwrite = i915_gem_object_lmem_pwrite;
...and AFAICT this modifies the ops for all devices, including the
integrated GPU, if any of the devices HAS_LMEM().
BR,
Jani.
> + if (!io_mapping_init_wc(&mem->iomap,
> + mem->io_start,
> +
Re: [PATCH] drm: Fix drm.h uapi header for Windows
On Mon, 07 Dec 2020 10:53:49 +
Simon Ser wrote:
> On Monday, December 7th, 2020 at 11:49 AM, James Park
> wrote:
>
> > That would work, but that's kind of an annoying requirement. I would
> > prefer the header to be self-sufficient.
>
> I don't want to make it more confusing than before, but here Pekka (I
> think) suggests to replace this:
>
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 82f3278..5eb07a5 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -24,7 +24,11 @@
> #ifndef DRM_FOURCC_H
> #define DRM_FOURCC_H
>
> +#ifdef DRM_FOURCC_STANDALONE
> +#include "drm_basic_types.h"
> +#else
> #include "drm.h"
> +#endif
>
> #if defined(__cplusplus)
> extern "C" {
>
> With this:
>
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 82f3278..5eb07a5 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -24,7 +24,11 @@
> #ifndef DRM_FOURCC_H
> #define DRM_FOURCC_H
>
> +#include "drm_basic_types.h"
> +
> +#ifndef DRM_FOURCC_STANDALONE
> #include "drm.h"
> +#endif
>
> #if defined(__cplusplus)
> extern "C" {
>
> That wouldn't change whether the header is self-sufficient or not,
> would it?
Exactly this.
This communicates properly that DRM_FOURCC_STANDALONE only affects
whether drm.h gets pulled in or not, and there are no other effects.
This also makes testing better: when you unconditionally include
drm_basic_types.h, you are more likely to catch breakage there.
For functionality, it makes no difference. Whether userspace does
#include "drm.h"
#define DRM_FOURCC_STANDALONE
#include "drm_fourcc.h"
or
#define DRM_FOURCC_STANDALONE
#include "drm_fourcc.h"
#include "drm.h"
the result must always be good.
Thanks,
pq
pgphVJGEKyyFU.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/5] drm/scheduler: Job timeout handler returns status (v2)
Am 04.12.20 um 16:10 schrieb Andrey Grodzovsky:
On 12/4/20 3:13 AM, Christian König wrote:
Thinking more about that I came to the conclusion that the whole
approach here isn't correct.
See even when the job has been completed or canceled we still want to
restart the timer.
The reason for this is that the timer is then not restarted for the
current job, but for the next job in the queue.
The only valid reason to not restart the timer is that the whole
device was hot plugged and we return -ENODEV here. E.g. what Andrey
has been working on.
We discussed this with Luben off line a few days ago but came to a
conclusion that for the next job the timer restart in
drm_sched_job_begin should do the work, no ?
Nope, drm_sched_job_begin() pushes the job to the hardware and starts
the timeout in case the hardware was idle before.
The function should probably be renamed to drm_sched_job_pushed()
because it doesn't begin the execution in any way.
Christian.
Andrey
Regards,
Christian.
Am 04.12.20 um 04:17 schrieb Luben Tuikov:
The driver's job timeout handler now returns
status indicating back to the DRM layer whether
the task (job) was successfully aborted or whether
more time should be given to the task to complete.
Default behaviour as of this patch, is preserved,
except in obvious-by-comment case in the Panfrost
driver, as documented below.
All drivers which make use of the
drm_sched_backend_ops' .timedout_job() callback
have been accordingly renamed and return the
would've-been default value of
DRM_TASK_STATUS_ALIVE to restart the task's
timeout timer--this is the old behaviour, and
is preserved by this patch.
In the case of the Panfrost driver, its timedout
callback correctly first checks if the job had
completed in due time and if so, it now returns
DRM_TASK_STATUS_COMPLETE to notify the DRM layer
that the task can be moved to the done list, to be
freed later. In the other two subsequent checks,
the value of DRM_TASK_STATUS_ALIVE is returned, as
per the default behaviour.
A more involved driver's solutions can be had
in subequent patches.
Signed-off-by: Luben Tuikov
Reported-by: kernel test robot
Cc: Alexander Deucher
Cc: Andrey Grodzovsky
Cc: Christian König
Cc: Daniel Vetter
Cc: Lucas Stach
Cc: Russell King
Cc: Christian Gmeiner
Cc: Qiang Yu
Cc: Rob Herring
Cc: Tomeu Vizoso
Cc: Steven Price
Cc: Alyssa Rosenzweig
Cc: Eric Anholt
v2: Use enum as the status of a driver's job
timeout callback method.
---
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 6 +++--
drivers/gpu/drm/etnaviv/etnaviv_sched.c | 10 +++-
drivers/gpu/drm/lima/lima_sched.c | 4 +++-
drivers/gpu/drm/panfrost/panfrost_job.c | 9 ---
drivers/gpu/drm/scheduler/sched_main.c | 4 +---
drivers/gpu/drm/v3d/v3d_sched.c | 32
+
include/drm/gpu_scheduler.h | 20 +---
7 files changed, 57 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
index ff48101bab55..a111326cbdde 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
@@ -28,7 +28,7 @@
#include "amdgpu.h"
#include "amdgpu_trace.h"
-static void amdgpu_job_timedout(struct drm_sched_job *s_job)
+static enum drm_task_status amdgpu_job_timedout(struct
drm_sched_job *s_job)
{
struct amdgpu_ring *ring = to_amdgpu_ring(s_job->sched);
struct amdgpu_job *job = to_amdgpu_job(s_job);
@@ -41,7 +41,7 @@ static void amdgpu_job_timedout(struct
drm_sched_job *s_job)
amdgpu_ring_soft_recovery(ring, job->vmid,
s_job->s_fence->parent)) {
DRM_ERROR("ring %s timeout, but soft recovered\n",
s_job->sched->name);
- return;
+ return DRM_TASK_STATUS_ALIVE;
}
amdgpu_vm_get_task_info(ring->adev, job->pasid, &ti);
@@ -53,10 +53,12 @@ static void amdgpu_job_timedout(struct
drm_sched_job *s_job)
if (amdgpu_device_should_recover_gpu(ring->adev)) {
amdgpu_device_gpu_recover(ring->adev, job);
+ return DRM_TASK_STATUS_ALIVE;
} else {
drm_sched_suspend_timeout(&ring->sched);
if (amdgpu_sriov_vf(adev))
adev->virt.tdr_debug = true;
+ return DRM_TASK_STATUS_ALIVE;
}
}
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
index cd46c882269c..c49516942328 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
@@ -82,7 +82,8 @@ static struct dma_fence
*etnaviv_sched_run_job(struct drm_sched_job *sched_job)
return fence;
}
-static void etnaviv_sched_timedout_job(struct drm_sched_job
*sched_job)
+static enum drm_task_status etnaviv_sched_timedout_job(struct
drm_sched_job
+ *sched_job)
{
struct etnaviv_gem_submit *submit = to_etnaviv_submit(sched_job);
struct etnaviv_gpu *g
Re: [PATCH] drm: Fix drm.h uapi header for Windows
On Monday, December 7th, 2020 at 11:49 AM, James Park
wrote:
> That would work, but that's kind of an annoying requirement. I would
> prefer the header to be self-sufficient.
I don't want to make it more confusing than before, but here Pekka (I
think) suggests to replace this:
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 82f3278..5eb07a5 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -24,7 +24,11 @@
#ifndef DRM_FOURCC_H
#define DRM_FOURCC_H
+#ifdef DRM_FOURCC_STANDALONE
+#include "drm_basic_types.h"
+#else
#include "drm.h"
+#endif
#if defined(__cplusplus)
extern "C" {
With this:
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 82f3278..5eb07a5 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -24,7 +24,11 @@
#ifndef DRM_FOURCC_H
#define DRM_FOURCC_H
+#include "drm_basic_types.h"
+
+#ifndef DRM_FOURCC_STANDALONE
#include "drm.h"
+#endif
#if defined(__cplusplus)
extern "C" {
That wouldn't change whether the header is self-sufficient or not,
would it?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Fix drm.h uapi header for Windows
On Monday, December 7th, 2020 at 11:44 AM, Pekka Paalanen wrote: > But then, the code in the header should be literally > > #ifndef DRM_FOURCC_STANDALONE > #include "drm.h" > #endif > > without an #else branch. As long as there is a #include "drm_basic_types.h" right before (drm_fourcc.h needs __u32 and __u64), I believe this can work too indeed. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Fix drm.h uapi header for Windows
On Mon, 7 Dec 2020 12:35:14 +0200 Pekka Paalanen wrote: > On Mon, 7 Dec 2020 01:08:58 -0800 > James Park wrote: > > > I'm not completely sure what you're saying, but doesn't drm_base_types.h > > (now drm_basic_types.h) make things robust to header order? The patch is in > > another email. You can also see it here: > > https://github.com/jpark37/linux/commit/0cc8ae750bfd9eab7e31c7de6aa84f24682f4f18 > > > > If that is robust (I don't know if it is, I haven't checked), then why > do you have #ifdef DRM_FOURCC_STANDALONE in it at all? > > Like Simon said: > > On Mon, 07 Dec 2020 10:02:36 + > Simon Ser wrote: > > > In my compositors I'd like to globally define DRM_FOURCC_STANDALONE > > (to make sure I don't miss any #define) but I still may include drm.h > > in the same files as well. > > If any project #defines it globally, then what good does checking for > it do? Why not assume that everyone will always want what > DRM_FOURCC_STANDALONE would bring? Sorry! Now I got it. DRM_FOURCC_STANDALONE is a promise that the user is not relying on drm_foucc.h to pull in drm.h. Nothing else. That's fine. But then, the code in the header should be literally #ifndef DRM_FOURCC_STANDALONE #include "drm.h" #endif without an #else branch. Thanks, pq pgpp2cgFtEs0v.pgp Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/2] drm/msm: Add speed-bin support to a618 gpu
Some GPUs support different max frequencies depending on the platform.
To identify the correct variant, we should check the gpu speedbin
fuse value. Add support for this speedbin detection to a6xx family
along with the required fuse details for a618 gpu.
Signed-off-by: Akhil P Oommen
---
Changes from v2:
1. Made the changes a6xx specific to save space.
Changes from v1:
1. Added the changes to support a618 sku to the series.
2. Avoid failing probe in case of an unsupported sku. (Rob)
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 74 +++
drivers/gpu/drm/msm/adreno/a6xx_gpu.h | 2 +
2 files changed, 76 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 1306618..6304578 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -10,10 +10,13 @@
#include
#include
+#include
#include
#define GPU_PAS_ID 13
+const u32 a618_speedbins[] = {0, 169, 174};
+
static inline bool _a6xx_check_idle(struct msm_gpu *gpu)
{
struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
@@ -1208,6 +1211,10 @@ static void a6xx_destroy(struct msm_gpu *gpu)
a6xx_gmu_remove(a6xx_gpu);
adreno_gpu_cleanup(adreno_gpu);
+
+ if (a6xx_gpu->opp_table)
+ dev_pm_opp_put_supported_hw(a6xx_gpu->opp_table);
+
kfree(a6xx_gpu);
}
@@ -1264,6 +1271,67 @@ static uint32_t a6xx_get_rptr(struct msm_gpu *gpu,
struct msm_ringbuffer *ring)
return ring->memptrs->rptr = gpu_read(gpu, REG_A6XX_CP_RB_RPTR);
}
+static u32 fuse_to_supp_hw(struct device *dev, u32 revn, u32 fuse)
+{
+ int i;
+
+ if (revn == 618) {
+ for (i = 0; i < ARRAY_SIZE(a618_speedbins); i++) {
+ if (fuse == a618_speedbins[i])
+ return (1 << i);
+ }
+ }
+
+ DRM_DEV_ERROR(dev,
+ "missing support for speed-bin: %u. Some OPPs may not
be supported by hardware",
+ fuse);
+ return ~0U;
+}
+
+static int a6xx_set_supported_hw(struct device *dev, struct a6xx_gpu *a6xx_gpu,
+ u32 revn)
+{
+
+ struct opp_table *opp_table;
+ struct nvmem_cell *cell;
+ u32 supp_hw = ~0U;
+ void *buf;
+
+ cell = nvmem_cell_get(dev, "speed_bin");
+ /*
+* -ENOENT means that the platform doesn't support speedbin which is
+* fine
+*/
+ if (PTR_ERR(cell) == -ENOENT)
+ return 0;
+ else if (IS_ERR(cell)) {
+ DRM_DEV_ERROR(dev,
+ "failed to read speed-bin. Some OPPs may not be
supported by hardware");
+ goto done;
+ }
+
+ buf = nvmem_cell_read(cell, NULL);
+ if (IS_ERR(buf)) {
+ nvmem_cell_put(cell);
+ DRM_DEV_ERROR(dev,
+ "failed to read speed-bin. Some OPPs may not be
supported by hardware");
+ goto done;
+ }
+
+ supp_hw = fuse_to_supp_hw(dev, revn, *((u32 *) buf));
+
+ kfree(buf);
+ nvmem_cell_put(cell);
+
+done:
+ opp_table = dev_pm_opp_set_supported_hw(dev, &supp_hw, 1);
+ if (IS_ERR(opp_table))
+ return PTR_ERR(opp_table);
+
+ a6xx_gpu->opp_table = opp_table;
+ return 0;
+}
+
static const struct adreno_gpu_funcs funcs = {
.base = {
.get_param = adreno_get_param,
@@ -1325,6 +1393,12 @@ struct msm_gpu *a6xx_gpu_init(struct drm_device *dev)
a6xx_llc_slices_init(pdev, a6xx_gpu);
+ ret = a6xx_set_supported_hw(&pdev->dev, a6xx_gpu, info->revn);
+ if (ret) {
+ a6xx_destroy(&(a6xx_gpu->base.base));
+ return ERR_PTR(ret);
+ }
+
ret = adreno_gpu_init(dev, pdev, adreno_gpu, &funcs, 1);
if (ret) {
a6xx_destroy(&(a6xx_gpu->base.base));
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
index e793d32..ce0610c 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
@@ -33,6 +33,8 @@ struct a6xx_gpu {
void *llc_slice;
void *htw_llc_slice;
bool have_mmu500;
+
+ struct opp_table *opp_table;
};
#define to_a6xx_gpu(x) container_of(x, struct a6xx_gpu, base)
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/2] arm: dts: sc7180: Add support for gpu fuse
Add support for gpu fuse to help identify the supported opps.
Signed-off-by: Akhil P Oommen
---
arch/arm64/boot/dts/qcom/sc7180.dtsi | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi
b/arch/arm64/boot/dts/qcom/sc7180.dtsi
index 6678f1e..8cae3eb 100644
--- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
@@ -675,6 +675,11 @@
reg = <0x25b 0x1>;
bits = <1 3>;
};
+
+ gpu_speed_bin: gpu_speed_bin@1d2 {
+ reg = <0x1d2 0x2>;
+ bits = <5 8>;
+ };
};
sdhc_1: sdhci@7c4000 {
@@ -1907,52 +1912,69 @@
operating-points-v2 = <&gpu_opp_table>;
qcom,gmu = <&gmu>;
+ nvmem-cells = <&gpu_speed_bin>;
+ nvmem-cell-names = "speed_bin";
+
interconnects = <&gem_noc MASTER_GFX3D 0 &mc_virt
SLAVE_EBI1 0>;
interconnect-names = "gfx-mem";
gpu_opp_table: opp-table {
compatible = "operating-points-v2";
+ opp-82500 {
+ opp-hz = /bits/ 64 <82500>;
+ opp-level =
;
+ opp-peak-kBps = <8532000>;
+ opp-supported-hw = <0x04>;
+ };
+
opp-8 {
opp-hz = /bits/ 64 <8>;
opp-level =
;
opp-peak-kBps = <8532000>;
+ opp-supported-hw = <0x07>;
};
opp-65000 {
opp-hz = /bits/ 64 <65000>;
opp-level =
;
opp-peak-kBps = <7216000>;
+ opp-supported-hw = <0x07>;
};
opp-56500 {
opp-hz = /bits/ 64 <56500>;
opp-level = ;
opp-peak-kBps = <5412000>;
+ opp-supported-hw = <0x07>;
};
opp-43000 {
opp-hz = /bits/ 64 <43000>;
opp-level =
;
opp-peak-kBps = <5412000>;
+ opp-supported-hw = <0x07>;
};
opp-35500 {
opp-hz = /bits/ 64 <35500>;
opp-level = ;
opp-peak-kBps = <3072000>;
+ opp-supported-hw = <0x07>;
};
opp-26700 {
opp-hz = /bits/ 64 <26700>;
opp-level =
;
opp-peak-kBps = <3072000>;
+ opp-supported-hw = <0x07>;
};
opp-18000 {
opp-hz = /bits/ 64 <18000>;
opp-level =
;
opp-peak-kBps = <1804000>;
+ opp-supported-hw = <0x07>;
};
};
};
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Fix drm.h uapi header for Windows
On Mon, 7 Dec 2020 01:08:58 -0800 James Park wrote: > I'm not completely sure what you're saying, but doesn't drm_base_types.h > (now drm_basic_types.h) make things robust to header order? The patch is in > another email. You can also see it here: > https://github.com/jpark37/linux/commit/0cc8ae750bfd9eab7e31c7de6aa84f24682f4f18 If that is robust (I don't know if it is, I haven't checked), then why do you have #ifdef DRM_FOURCC_STANDALONE in it at all? Like Simon said: On Mon, 07 Dec 2020 10:02:36 + Simon Ser wrote: > In my compositors I'd like to globally define DRM_FOURCC_STANDALONE > (to make sure I don't miss any #define) but I still may include drm.h > in the same files as well. If any project #defines it globally, then what good does checking for it do? Why not assume that everyone will always want what DRM_FOURCC_STANDALONE would bring? Thanks, pq > > Thanks, > James > > On Mon, Dec 7, 2020 at 12:51 AM Pekka Paalanen wrote: > > > On Fri, 4 Dec 2020 11:07:41 -0800 > > James Park wrote: > > > > > I could adjust the block to look like this: > > > > > > #ifdef DRM_FOURCC_STANDALONE > > > #if defined(__linux__) > > > #include > > > #else > > > #include > > > typedef uint32_t __u32; > > > typedef uint64_t __u64; > > > #endif > > > #else > > > #include "drm.h" > > > #endif > > > > > > Alternatively, I could create a new common header to be included from > > both > > > drm.h and drm_fourcc.h, drm_base_types.h or something like that: > > > > > > #ifdef DRM_FOURCC_STANDALONE > > > #include "drm_base_types.h" > > > #else > > > #include "drm.h" > > > #endif > > > > Hi, > > > > my point is, any solution relying on DRM_FOURCC_STANDALONE will fail > > sometimes, because there is no reason why userspace would *not* #define > > DRM_FOURCC_STANDALONE. Hence, #ifdef DRM_FOURCC_STANDALONE is > > completely moot, you have to make the headers work in any include > > order when DRM_FOURCC_STANDALONE is defined anyway. > > > > > > Thanks. > > pq > > > > > On Fri, Dec 4, 2020 at 7:58 AM Daniel Vetter wrote: > > > > > > > On Fri, Dec 4, 2020 at 9:12 AM Pekka Paalanen > > wrote: > > > > > > > > > > On Thu, 3 Dec 2020 21:45:14 +0100 > > > > > Daniel Vetter wrote: > > > > > > > > > > > On Thu, Dec 3, 2020 at 7:55 PM James Park < > > james.p...@lagfreegames.com> > > > > wrote: > > > > > > > > > > > > > > The trailing underscore for DRM_FOURCC_STANDALONE_ isn't > > > > > > > intentional, right? Should I put all the integer types, or just > > the > > > > > > > ones that are used in that file? > > > > > > > > > > > > Yeah that trailing _ just slipped in. And I'd just do the types > > > > > > already used. I don't think anything else than __u32 (for drm > > fourcc) > > > > > > and __u64 (for drm modifier) is needed. > > > > > > > > > > Hi, > > > > > > > > > > can that create conflicts if userspace first includes drm_fourcc.h > > and > > > > > then drm.h? > > > > > > > > > > I would find it natural to userspace have generic headers including > > > > > drm_fourcc.h and then DRM-specific C-files including drm.h as well > > > > > (through libdrm headers). I think Weston might already do this. > > > > > > > > > > The generic userspace (weston) header would obviously #define > > > > > DRM_FOURCC_STANDALONE, because it is used by non-DRM C-files as > > well. > > > > > > > > Hm yes that would break. I guess we could just include the linux types > > > > header for this. And I guess on windows you'd need to have that from > > > > somewhere. Or we just require that users of the standalone header pull > > > > the right header or defines in first? > > > > -Daniel > > > > -- > > > > Daniel Vetter > > > > Software Engineer, Intel Corporation > > > > http://blog.ffwll.ch > > > > > > > > pgpn8FF_3CXto.pgp Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: drm_basic_types.h, DRM_FOURCC_STANDALONE
On Monday, December 7th, 2020 at 11:05 AM, James Park
wrote:
> The original code blocks in drm.h look identical to me. I see:
>
> #include
> #include
> typedef unsigned int drm_handle_t;
Hmm. Actually you're completely right, it turns out it's necessary to
duplicate the branches like this to make `make headers_install` work
properly. See 00c9672606f7 ("drm: Untangle __KERNEL__ guards").
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
