Re: [v2 2/2] drm/i915: Attach colorspace property and enable modeset
Regards Shashank On 10/31/2018 5:35 PM, Uma Shankar wrote: This patch attaches the colorspace connector property to the hdmi connector. Based on colorspace change, modeset will be triggered to switch to new colorspace. Based on colorspace property value create an infoframe with appropriate colorspace. This can be used to send an infoframe packet with proper colorspace value set which will help to enable wider color gamut like BT2020 on sink. v2: Merged the changes of creating infoframe as well to this patch as per Maarten's suggestion. Signed-off-by: Uma Shankar --- drivers/gpu/drm/i915/intel_atomic.c | 1 + drivers/gpu/drm/i915/intel_hdmi.c | 5 + 2 files changed, 6 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_atomic.c b/drivers/gpu/drm/i915/intel_atomic.c index a5a2c8f..35ef70a 100644 --- a/drivers/gpu/drm/i915/intel_atomic.c +++ b/drivers/gpu/drm/i915/intel_atomic.c @@ -125,6 +125,7 @@ int intel_digital_connector_atomic_check(struct drm_connector *conn, */ if (new_conn_state->force_audio != old_conn_state->force_audio || new_conn_state->broadcast_rgb != old_conn_state->broadcast_rgb || + new_state->colorspace != old_state->colorspace || new_conn_state->base.picture_aspect_ratio != old_conn_state->base.picture_aspect_ratio || new_conn_state->base.content_type != old_conn_state->base.content_type || new_conn_state->base.scaling_mode != old_conn_state->base.scaling_mode) diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c index 129b880..8a41fb3 100644 --- a/drivers/gpu/drm/i915/intel_hdmi.c +++ b/drivers/gpu/drm/i915/intel_hdmi.c @@ -486,6 +486,8 @@ static void intel_hdmi_set_avi_infoframe(struct intel_encoder *encoder, else frame.avi.colorspace = HDMI_COLORSPACE_RGB; + frame.avi.extended_colorimetry = conn_state->colorspace; + We must also set the date byte 2 bits C1-C0 (colorimetry part) to indicate the use of extended colorimetry bits, so that monitor will refer to extended colorimetry data, else it wont even bother looking at it: Extended Colorimetry Information Valid (colorimetry indicated in bits EC0, EC1, and EC2) Its right now set to dafault 0-0 I guess, indicating No data We should also set it to a default value now, when we have started bothering about gamut. Regards Shashank drm_hdmi_avi_infoframe_quant_range(&frame.avi, adjusted_mode, crtc_state->limited_color_range ? HDMI_QUANTIZATION_RANGE_LIMITED : @@ -2125,6 +2127,9 @@ static void intel_hdmi_destroy(struct drm_connector *connector) intel_attach_broadcast_rgb_property(connector); intel_attach_aspect_ratio_property(connector); drm_connector_attach_content_type_property(connector); + drm_object_attach_property(&connector->base, + connector->dev->mode_config.colorspace_property, + COLORIMETRY_ITU_709); connector->state->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE; } ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [v2 1/2] drm: Add colorspace property
Regards
Shashank
On 10/31/2018 5:35 PM, Uma Shankar wrote:
This patch adds a colorspace property enabling
userspace to switch to various supported colorspaces.
This will help enable BT2020 along with other colorspaces.
v2: Addressed Maarten and Ville's review comments. Enhanced
the colorspace enum to incorporate both HDMI and DP supported
colorspaces. Also, added a default option for colorspace.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/drm_atomic_uapi.c | 4
drivers/gpu/drm/drm_connector.c | 44 +++
include/drm/drm_connector.h | 7 +++
include/drm/drm_mode_config.h | 6 ++
include/uapi/drm/drm_mode.h | 24 +
5 files changed, 85 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index d5b7f31..9e1d46b 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -721,6 +721,8 @@ static int drm_atomic_connector_set_property(struct
drm_connector *connector,
state->picture_aspect_ratio = val;
} else if (property == config->content_type_property) {
state->content_type = val;
+ } else if (property == config->colorspace_property) {
+ state->colorspace = val;
} else if (property == connector->scaling_mode_property) {
state->scaling_mode = val;
} else if (property == connector->content_protection_property) {
@@ -795,6 +797,8 @@ static int drm_atomic_connector_set_property(struct
drm_connector *connector,
*val = state->picture_aspect_ratio;
} else if (property == config->content_type_property) {
*val = state->content_type;
+ } else if (property == config->colorspace_property) {
+ *val = state->colorspace;
} else if (property == connector->scaling_mode_property) {
*val = state->scaling_mode;
} else if (property == connector->content_protection_property) {
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index aa18b1d..5ad52a0 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -826,6 +826,38 @@ int drm_display_info_set_bus_formats(struct
drm_display_info *info,
};
DRM_ENUM_NAME_FN(drm_get_content_protection_name, drm_cp_enum_list)
+static const struct drm_prop_enum_list colorspace[] = {
+ /* Standard Definition Colorimetry based on CEA 861 */
+ { COLORIMETRY_ITU_601, "601" },
+ { COLORIMETRY_ITU_709, "709" },
+ /* Standard Definition Colorimetry based on IEC 61966-2-4 */
+ { COLORIMETRY_XV_YCC_601, "601" },
+ /* High Definition Colorimetry based on IEC 61966-2-4 */
+ { COLORIMETRY_XV_YCC_709, "709" },
+ /* Colorimetry based on IEC 61966-2-1/Amendment 1 */
+ { COLORIMETRY_S_YCC_601, "s601" },
+ /* Colorimetry based on IEC 61966-2-5 [33] */
+ { COLORIMETRY_ADOBE_YCC_601, "adobe601" },
+ /* Colorimetry based on IEC 61966-2-5 */
+ { COLORIMETRY_ADOBE_RGB, "adobe_rgb" },
+ /* Colorimetry based on ITU-R BT.2020 */
+ { COLORIMETRY_BT2020_RGB, "BT2020_rgb" },
+ /* Colorimetry based on ITU-R BT.2020 */
+ { COLORIMETRY_BT2020_YCC, "BT2020_ycc" },
+ /* Colorimetry based on ITU-R BT.2020 */
+ { COLORIMETRY_BT2020_CYCC, "BT2020_cycc" },
+ /* DP MSA Colorimetry */
+ { COLORIMETRY_Y_CBCR_ITU_601, "YCBCR_ITU_601" },
+ { COLORIMETRY_Y_CBCR_ITU_709, "YCBCR_ITU_709" },
+ { COLORIMETRY_SRGB, "SRGB" },
+ { COLORIMETRY_RGB_WIDE_GAMUT, "RGB Wide Gamut" },
+ { COLORIMETRY_SCRGB, "SCRGB" },
+ { COLORIMETRY_DCI_P3, "DCIP3" },
+ { COLORIMETRY_CUSTOM_COLOR_PROFILE, "Custom Proflie" },
+ /* FOR HD 720p+, Default Colorimetry is based on ITU-R BT.709 */
+ { COLORIMETRY_DEFAULT, "Default: ITU_709" },
+};
+
/**
* DOC: standard connector properties
*
@@ -972,6 +1004,12 @@ int drm_display_info_set_bus_formats(struct
drm_display_info *info,
*can also expose this property to external outputs, in which case they
*must support "None", which should be the default (since external screens
*have a built-in scaler).
+ *
+ * colorspace:
+ * This property helps select a suitable colorspace based on the sink
+ * capability. Modern sink devices support wider gamut like BT2020.
+ * This helps switch to BT2020 mode if the BT2020 encoded video stream
+ * is being played by the user, same for any other colorspace.
As commented on the previous patch, we might have to consider the HW
capability while doing this.
*/
int drm_connector_create_standard_properties(struct drm_device *dev)
@@ -1020,6 +1058,12 @@ int drm_connector_create_standard_properties(struct
drm_device *dev)
return -ENOMEM;
dev->mode_config.non_desktop_property = prop;
+ prop = drm_property_create_enum(dev, DRM_MO
Re: [v2 0/2] Add Colorspace connector property interface
Hello Uma, My comments inline. On 10/31/2018 5:35 PM, Uma Shankar wrote: This patch series creates a new connector property to program colorspace to sink devices. Modern sink devices support more than 1 type of colorspace like 601, 709, BT2020 etc. This helps to switch based on content type which is to be displayed. The decision lies with compositors as to in which scenarios, a particular colorspace will be picked. This will be helpful mostly to switch to higher gamut colorspaces like BT2020 when the media content is encoded as BT2020. Thereby giving a good visual experience to users. The expectation from userspace is that it should parse the EDID and get supported colorspaces. Use this property and switch to the one supported. Kernel will not give the supported colorspaces since this is panel dependent and our curremt property infrastructure is not supporting it. I am not very sure about this part, consider a situation where, I have connected a HDMI 2.0 monitor which supports BT2020 gamut, to a GEN9 device, running an user-space which can also support BT2020 playback / HDR playback. Now, both monitor and user-space supports BT2020 playback, but the HW doesn't, and this will create a problem during playback. So I gess we need to expose a kernel Cap or property to showcase if the HW can support BT2020/DCI-P3 gamut space or not. - Shashank Have tested this using xrandr by using below command: xrandr --output HDMI2 --set "Colorspace" "BT2020_rgb" v2: Addressed Ville and Maarten's review comments. Merged the 2nd and 3rd patch into one common logical patch. Uma Shankar (2): drm: Add colorspace property drm/i915: Attach colorspace property and enable modeset drivers/gpu/drm/drm_atomic_uapi.c | 4 drivers/gpu/drm/drm_connector.c | 44 + drivers/gpu/drm/i915/intel_atomic.c | 1 + drivers/gpu/drm/i915/intel_hdmi.c | 5 + include/drm/drm_connector.h | 7 ++ include/drm/drm_mode_config.h | 6 + include/uapi/drm/drm_mode.h | 24 7 files changed, 91 insertions(+) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 201605] New: amdgpu: RX 570 reboots the PC when stressed
https://bugzilla.kernel.org/show_bug.cgi?id=201605 Bug ID: 201605 Summary: amdgpu: RX 570 reboots the PC when stressed Product: Drivers Version: 2.5 Kernel Version: 4.19.0 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: blocking Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: fin4...@hotmail.com Regression: No When running the Unigine Heaven benchmark, the PC reboots after the 3. scene. When setting max power usage to 70 watts, the benchmark runs OK. Reboot does occur when playing Just Cause 3 with wine-staging. Reboot does occur when recording the Unigine Superposition benchmark with OBS. I did run the furmark GPU stress test in windows 10 and it is stable. My PSU is 520W total and +12V is 340W. The GPU card is ASUS Radeon RX 570 4GB Expedition OC. Nothing in logs. The computer did work OK with RX 560. The fans inside the PC sound louder when using windows 10. xfce@ryzenpc:~/Downloads$ inxi -bM System: Host: ryzenpc Kernel: 4.19.0 x86_64 bits: 64 Desktop: Xfce 4.12.4 Distro: Debian GNU/Linux buster/sid Machine: Type: Desktop Mobo: ASUSTeK model: PRIME B350M-K v: Rev X.0x serial: UEFI: American Megatrends v: 4023 date: 08/20/2018 CPU: 6-Core: AMD Ryzen 5 1600 type: MT MCP speed: 2804 MHz Graphics: Device-1: AMD Ellesmere [Radeon RX 470/480] driver: amdgpu v: kernel Display: x11 server: X.Org 1.20.3 driver: amdgpu,ati unloaded: fbdev,modesetting,vesa resolution: 1920x1080~60Hz OpenGL: renderer: Radeon RX 570 Series (POLARIS10 DRM 3.27.0 4.19.0 LLVM 7.0.0) v: 4.5 Mesa 18.3.0-devel (git-9007c0e 2018-10-29 bionic-oibaf-ppa) -- 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 v8 19/19] drm/i915/dsc: Add Per connector debugfs node for DSC support/enable
On Fri, Nov 02, 2018 at 02:31:38PM -0700, Manasi Navare wrote:
> DSC can be supported per DP connector. This patch adds a per connector
> debugfs node to expose DSC support capability by the kernel.
> The same node can be used from userspace to force DSC enable.
>
> force_dsc_en written through this debugfs node is used to force
> DSC even for lower resolutions.
>
> v3:
> * Combine Force_dsc_en with this patch (Ville)
> v2:
> * Use kstrtobool_from_user to avoid explicit error checking (Lyude)
> * Rebase on drm-tip (Manasi)
>
> Cc: Rodrigo Vivi
> Cc: Ville Syrjala
> Cc: Anusha Srivatsa
> Cc: Lyude Paul
> Signed-off-by: Manasi Navare
> Reviewed-by: Lyude Paul
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 71 -
> drivers/gpu/drm/i915/intel_dp.c | 3 +-
> drivers/gpu/drm/i915/intel_drv.h| 3 ++
> 3 files changed, 75 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 1a4d9d996fda..fe619b54b64d 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -5000,6 +5000,72 @@ static int i915_hdcp_sink_capability_show(struct
> seq_file *m, void *data)
> }
> DEFINE_SHOW_ATTRIBUTE(i915_hdcp_sink_capability);
>
> +static int i915_dsc_support_show(struct seq_file *m, void *data)
> +{
> + struct drm_connector *connector = m->private;
> + struct intel_encoder *encoder = intel_attached_encoder(connector);
> + struct intel_dp *intel_dp =
> + enc_to_intel_dp(&encoder->base);
> + struct intel_crtc *crtc;
> + struct intel_crtc_state *crtc_state;
Missed this check in the rebase or respin:
if (connector->status != connector_status_connected)
resulting into a lot of CI errors. will fix this in the next rev
> +
> + crtc = to_intel_crtc(encoder->base.crtc);
> + crtc_state = to_intel_crtc_state(crtc->base.state);
> + drm_modeset_lock(&crtc->base.mutex, NULL);
> + seq_printf(m, "Enabled: %s\n",
> +yesno(crtc_state->dsc_params.compression_enable));
> + seq_printf(m, "Supported: %s\n",
> +yesno(drm_dp_sink_supports_dsc(intel_dp->dsc_dpcd)));
> + drm_modeset_unlock(&crtc->base.mutex);
> +
> + return 0;
> +}
> +
> +static ssize_t i915_dsc_support_write(struct file *file,
> + const char __user *ubuf,
> + size_t len, loff_t *offp)
> +{
> + bool dsc_enable = false;
> + int ret;
> + struct drm_connector *connector =
> + ((struct seq_file *)file->private_data)->private;
> + struct intel_encoder *encoder = intel_attached_encoder(connector);
> + struct intel_dp *intel_dp = enc_to_intel_dp(&encoder->base);
> +
> + if (len == 0)
> + return 0;
> +
> + DRM_DEBUG_DRIVER("Copied %d bytes from user to force DSC\n",
> + (unsigned int)len);
> +
> + ret = kstrtobool_from_user(ubuf, len, &dsc_enable);
> + if (ret < 0)
> + return ret;
> +
> + DRM_DEBUG_DRIVER("Got %s for DSC Enable\n",
> + (dsc_enable) ? "true" : "false");
> + intel_dp->force_dsc_en = dsc_enable;
> +
> + *offp += len;
> + return len;
> +}
> +
> +static int i915_dsc_support_open(struct inode *inode,
> + struct file *file)
> +{
> + return single_open(file, i915_dsc_support_show,
> +inode->i_private);
> +}
> +
> +static const struct file_operations i915_dsc_support_fops = {
> + .owner = THIS_MODULE,
> + .open = i915_dsc_support_open,
> + .read = seq_read,
> + .llseek = seq_lseek,
> + .release = single_release,
> + .write = i915_dsc_support_write
> +};
> +
> /**
> * i915_debugfs_connector_add - add i915 specific connector debugfs files
> * @connector: pointer to a registered drm_connector
> @@ -5018,9 +5084,12 @@ int i915_debugfs_connector_add(struct drm_connector
> *connector)
> return -ENODEV;
>
> if (connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
> - connector->connector_type == DRM_MODE_CONNECTOR_eDP)
> + connector->connector_type == DRM_MODE_CONNECTOR_eDP) {
> debugfs_create_file("i915_dpcd", S_IRUGO, root,
> connector, &i915_dpcd_fops);
> + debugfs_create_file("i915_dsc_support", S_IRUGO, root,
> + connector, &i915_dsc_support_fops);
also since DSC only supported on GEN >= 10, should we create this node only for
higher GENs?
Manasi
> + }
>
> if (connector->connector_type == DRM_MODE_CONNECTOR_eDP) {
> debugfs_create_file("i915_panel_timings", S_IRUGO, root,
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index f8bf942c8f71..4d866d49d870 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -2158,7
Re: [PATCH v8 07/19] drm/i915/dp: Compute DSC pipe config in atomic check
On Fri, Nov 02, 2018 at 02:31:26PM -0700, Manasi Navare wrote:
> DSC params like the enable, compressed bpp, slice count and
> dsc_split are added to the intel_crtc_state. These parameters
> are set based on the requested mode and available link parameters
> during the pipe configuration in atomic check phase.
> These values are then later used to populate the remaining DSC
> and RC parameters before enbaling DSC in atomic commit.
>
> v11:
> * Const crtc_state, reject DSC on DP without FEC (Ville)
> * Dont set dsc_split to false (Ville)
> v10:
> * Add a helper for dp_dsc support (Ville)
> * Set pipe_config to max bpp, link params for DSC for now (Ville)
> * Compute bpp - use dp dsc support helper (Ville)
> v9:
> * Rebase on top of drm-tip that now uses fast_narrow config
> for edp (Manasi)
> v8:
> * Check for DSC bpc not 0 (manasi)
>
> v7:
> * Fix indentation in compute_m_n (Manasi)
>
> v6 (From Gaurav):
> * Remove function call of intel_dp_compute_dsc_params() and
> invoke intel_dp_compute_dsc_params() in the patch where
> it is defined to fix compilation warning (Gaurav)
>
> v5:
> Add drm_dsc_cfg in intel_crtc_state (Manasi)
>
> v4:
> * Rebase on refactoring of intel_dp_compute_config on tip (Manasi)
> * Add a comment why we need to check PSR while enabling DSC (Gaurav)
>
> v3:
> * Check PPR > max_cdclock to use 2 VDSC instances (Ville)
>
> v2:
> * Add if-else for eDP/DP (Gaurav)
>
> Cc: Jani Nikula
> Cc: Ville Syrjala
> Cc: Anusha Srivatsa
> Cc: Gaurav K Singh
> Signed-off-by: Manasi Navare
> Reviewed-by: Anusha Srivatsa
> Acked-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_display.c | 20 +++-
> drivers/gpu/drm/i915/intel_display.h | 3 +-
> drivers/gpu/drm/i915/intel_dp.c | 167 ---
> drivers/gpu/drm/i915/intel_dp_mst.c | 2 +-
> 4 files changed, 166 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index b219d5858160..477e53c37353 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -6442,7 +6442,7 @@ static int ironlake_fdi_compute_config(struct
> intel_crtc *intel_crtc,
>
> pipe_config->fdi_lanes = lane;
>
> - intel_link_compute_m_n(pipe_config->pipe_bpp, lane, fdi_dotclock,
> + intel_link_compute_m_n(pipe_config->pipe_bpp, 0, lane, fdi_dotclock,
> link_bw, &pipe_config->fdi_m_n, false);
>
> ret = ironlake_check_fdi_lanes(dev, intel_crtc->pipe, pipe_config);
> @@ -6679,17 +6679,25 @@ static void compute_m_n(unsigned int m, unsigned int
> n,
> }
>
> void
> -intel_link_compute_m_n(int bits_per_pixel, int nlanes,
> +intel_link_compute_m_n(int bits_per_pixel, uint16_t compressed_bpp,
> +int nlanes,
> int pixel_clock, int link_clock,
> struct intel_link_m_n *m_n,
> bool constant_n)
> {
> m_n->tu = 64;
>
> - compute_m_n(bits_per_pixel * pixel_clock,
> - link_clock * nlanes * 8,
> - &m_n->gmch_m, &m_n->gmch_n,
> - constant_n);
> + /* For DSC, Data M/N calculation uses compressed BPP */
> + if (compressed_bpp)
> + compute_m_n(compressed_bpp * pixel_clock,
> + link_clock * nlanes * 8,
> + &m_n->gmch_m, &m_n->gmch_n,
> + constant_n);
> + else
> + compute_m_n(bits_per_pixel * pixel_clock,
> + link_clock * nlanes * 8,
> + &m_n->gmch_m, &m_n->gmch_n,
> + constant_n);
>
> compute_m_n(pixel_clock, link_clock,
> &m_n->link_m, &m_n->link_n,
> diff --git a/drivers/gpu/drm/i915/intel_display.h
> b/drivers/gpu/drm/i915/intel_display.h
> index 5d50decbcbb5..b0b23e1e9392 100644
> --- a/drivers/gpu/drm/i915/intel_display.h
> +++ b/drivers/gpu/drm/i915/intel_display.h
> @@ -407,7 +407,8 @@ struct intel_link_m_n {
>(__i)++) \
> for_each_if(plane)
>
> -void intel_link_compute_m_n(int bpp, int nlanes,
> +void intel_link_compute_m_n(int bpp, uint16_t compressed_bpp,
> + int nlanes,
> int pixel_clock, int link_clock,
> struct intel_link_m_n *m_n,
> bool constant_n);
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index b39b4bda8e40..58326fc9d935 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -47,6 +47,8 @@
>
> /* DP DSC small joiner has 2 FIFOs each of 640 x 6 bytes */
> #define DP_DSC_MAX_SMALL_JOINER_RAM_BUFFER 61440
> +#define DP_DSC_MIN_SUPPORTED_BPC 8
> +#define DP_DSC_MAX_SUPPORTED_BPC 10
>
> /* DP DSC throughput values used for slice count calculations KPixels/s */
> #define DP_DSC_PEAK_PIXEL_RA
[Bug 108577] Black X laptop screen with cursor if HDMI not plugged in, bisected
https://bugs.freedesktop.org/show_bug.cgi?id=108577 --- Comment #23 from Duncan Roe --- Created attachment 142351 --> https://bugs.freedesktop.org/attachment.cgi?id=142351&action=edit possible fix 2/2 updated for Linux 19.0 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108577] Black X laptop screen with cursor if HDMI not plugged in, bisected
https://bugs.freedesktop.org/show_bug.cgi?id=108577 --- Comment #22 from Duncan Roe --- Created attachment 142350 --> https://bugs.freedesktop.org/attachment.cgi?id=142350&action=edit possible fix 1/2 updated for Linux 19.0 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108577] Black X laptop screen with cursor if HDMI not plugged in, bisected
https://bugs.freedesktop.org/show_bug.cgi?id=108577 --- Comment #21 from Duncan Roe --- Yes they fix Black X. I tested at Linux 4.19 (commit 84df9525b0c27f3ebc2ebb1864fa62a97fdedb7d) with updated patches that apply cleanly (to be attached). I wonder if an approach like yours (checking dc->fbc_compressor or some other flag in dc) could be used to resolve Bug 108139? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 5/5] drm/i915: Add short HPD IRQ storm detection for non-MST systems
Unfortunately, it seems that the HPD IRQ storm problem from the early
days of Intel GPUs was never entirely solved, only mostly. Within the
last couple of days, I got a bug report from one of our customers who
had been having issues with their machine suddenly booting up very
slowly after having updated. The amount of time it took to boot went
from around 30 seconds, to over 6 minutes consistently.
After some investigation, I discovered that i915 was reporting massive
amounts of short HPD IRQ spam on this system from the DisplayPort port,
despite there not being anything actually connected. The symptoms would
start with one "long" HPD IRQ being detected at boot:
[1.891398] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat
0x0044, dig 0x0044, pins 0x00a0
[1.891436] [drm:intel_hpd_irq_handler [i915]] digital hpd port B - long
[1.891472] [drm:intel_hpd_irq_handler [i915]] Received HPD interrupt on PIN
5 - cnt: 0
[1.891508] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - long
[1.891544] [drm:intel_hpd_irq_handler [i915]] Received HPD interrupt on PIN
7 - cnt: 0
[1.891592] [drm:intel_dp_hpd_pulse [i915]] got hpd irq on port B - long
[1.891628] [drm:intel_dp_hpd_pulse [i915]] got hpd irq on port D - long
…
followed by constant short IRQs afterwards:
[1.895091] [drm:intel_encoder_hotplug [i915]] [CONNECTOR:66:DP-1] status
updated from unknown to disconnected
[1.895129] [drm:i915_hotplug_work_func [i915]] Connector DP-3 (pin 7)
received hotplug event.
[1.895165] [drm:intel_dp_detect [i915]] [CONNECTOR:72:DP-3]
[1.895275] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat
0x0020, dig 0x0020, pins 0x0080
[1.895312] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[1.895762] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat
0x0020, dig 0x0020, pins 0x0080
[1.895799] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[1.896239] [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status
0x71450085
[1.896293] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat
0x0020, dig 0x0020, pins 0x0080
[1.896330] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[1.896781] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat
0x0020, dig 0x0020, pins 0x0080
[1.896817] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[1.897275] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat
0x0020, dig 0x0020, pins 0x0080
The customer's system in question has a GM45 GPU, which is apparently
well known for hotplugging storms.
So, workaround this impressively broken hardware by changing the default
HPD storm threshold from 5 to 50. Then, make long IRQs count for 10, and
short IRQs count for 1. This makes it so that 5 long IRQs will trigger
an HPD storm, and on systems with short HPD storm detection 50 short
IRQs will trigger an HPD storm. 50 short IRQs amounts to 100ms of
constant pulsing, which seems like a good middleground between being too
sensitive and not being sensitive enough (which would cause visible
stutters in userspace every time a storm occurs).
And just to be extra safe: we don't enable this by default on systems
with MST support. There's too high of a chance of MST support triggering
storm detection, and systems that are new enough to support MST are a
lot less likely to have issues with IRQ storms anyway.
As a note: this patch was tested using a ThinkPad T450s and a Chamelium
to simulate the short IRQ storms.
Changes since v1:
- Don't use two separate thresholds, just make long IRQs count for 10
each and short IRQs count for 1. This simplifies the code a bit
- Ville Syrjälä
Changes since v2:
- Document @long_hpd in intel_hpd_irq_storm_detect, no functional
changes
Signed-off-by: Lyude Paul
Cc: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_debugfs.c | 74
drivers/gpu/drm/i915/i915_drv.h | 5 +-
drivers/gpu/drm/i915/i915_irq.c | 7 +++
drivers/gpu/drm/i915/intel_hotplug.c | 49 ++
4 files changed, 114 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 1a4d9d996fda..b9d6e1be6052 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4658,6 +4658,79 @@ static const struct file_operations
i915_hpd_storm_ctl_fops = {
.write = i915_hpd_storm_ctl_write
};
+static int i915_hpd_short_storm_ctl_show(struct seq_file *m, void *data)
+{
+ struct drm_i915_private *dev_priv = m->private;
+
+ seq_printf(m, "Enabled: %s\n",
+ yesno(dev_priv->hotplug.hpd_short_storm_enabled));
+
+ return 0;
+}
+
+static int
+i915_hpd_short_storm_ctl_open(struct inode *inode, struct file *file)
+{
+ return single_open(file, i915_hpd_short_storm_ctl_show,
+
[PATCH v3 0/5] drm/i915: HPD IRQ storm detection fixes
This series contains a fix for a problem which is very difficult to reproduce under normal circumstances without specialized testing hardware, along with a fix that seems to be required for some especially rebellious GM45 laptops. Lyude Paul (5): drm/i915: Fix possible race in intel_dp_add_mst_connector() drm/i915: Fix NULL deref when re-enabling HPD IRQs on systems with MST drm/i915: Fix threshold check in intel_hpd_irq_storm_detect() drm/i915: Clarify flow for disabling IRQs on storms drm/i915: Add short HPD IRQ storm detection for non-MST systems drivers/gpu/drm/i915/i915_debugfs.c | 74 ++ drivers/gpu/drm/i915/i915_drv.h | 5 +- drivers/gpu/drm/i915/i915_irq.c | 7 +++ drivers/gpu/drm/i915/intel_dp_mst.c | 8 +-- drivers/gpu/drm/i915/intel_hotplug.c | 78 +--- 5 files changed, 137 insertions(+), 35 deletions(-) -- 2.19.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/5] drm/i915: Fix possible race in intel_dp_add_mst_connector()
This hasn't caused any issues yet that I'm aware of, but as Ville
Syrjälä pointed out - we need to make sure that
intel_connector->mst_port is set before initializing MST connectors,
since in theory we could potentially check intel_connector->mst_port in
i915_hpd_poll_init_work() after registering the connector but before
having written it's value.
Signed-off-by: Lyude Paul
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dp_mst.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
b/drivers/gpu/drm/i915/intel_dp_mst.c
index 8b71d64ebd9d..8cb4093f8bcc 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -441,6 +441,10 @@ static struct drm_connector
*intel_dp_add_mst_connector(struct drm_dp_mst_topolo
if (!intel_connector)
return NULL;
+ intel_connector->get_hw_state = intel_dp_mst_get_hw_state;
+ intel_connector->mst_port = intel_dp;
+ intel_connector->port = port;
+
connector = &intel_connector->base;
ret = drm_connector_init(dev, connector, &intel_dp_mst_connector_funcs,
DRM_MODE_CONNECTOR_DisplayPort);
@@ -451,10 +455,6 @@ static struct drm_connector
*intel_dp_add_mst_connector(struct drm_dp_mst_topolo
drm_connector_helper_add(connector,
&intel_dp_mst_connector_helper_funcs);
- intel_connector->get_hw_state = intel_dp_mst_get_hw_state;
- intel_connector->mst_port = intel_dp;
- intel_connector->port = port;
-
for_each_pipe(dev_priv, pipe) {
struct drm_encoder *enc =
&intel_dp->mst_encoders[pipe]->base.base;
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/5] drm/i915: Fix NULL deref when re-enabling HPD IRQs on systems with MST
Turns out that if you trigger an HPD storm on a system that has an MST
topology connected to it, you'll end up causing the kernel to eventually
hit a NULL deref:
[ 332.339041] BUG: unable to handle kernel NULL pointer dereference at
00ec
[ 332.340906] PGD 0 P4D 0
[ 332.342750] Oops: [#1] SMP PTI
[ 332.344579] CPU: 2 PID: 25 Comm: kworker/2:0 Kdump: loaded Tainted: G
O 4.18.0-rc3short-hpd-storm+ #2
[ 332.346453] Hardware name: LENOVO 20BWS1KY00/20BWS1KY00, BIOS JBET71WW (1.35
) 09/14/2018
[ 332.348361] Workqueue: events intel_hpd_irq_storm_reenable_work [i915]
[ 332.350301] RIP: 0010:intel_hpd_irq_storm_reenable_work.cold.3+0x2f/0x86
[i915]
[ 332.352213] Code: 00 00 ba e8 00 00 00 48 c7 c6 c0 aa 5f a0 48 c7 c7 d0 73
62 a0 4c 89 c1 4c 89 04 24 e8 7f f5 af e0 4c 8b 04 24 44 89 f8 29 e8 <41> 39 80
ec 00 00 00 0f 85 43 13 fc ff 41 0f b6 86 b8 04 00 00 41
[ 332.354286] RSP: 0018:c9147e48 EFLAGS: 00010006
[ 332.356344] RAX: 0005 RBX: 8802c226c9d4 RCX: 0006
[ 332.358404] RDX: RSI: 0082 RDI: 88032dc95570
[ 332.360466] RBP: 0005 R08: R09: 88031b3dc840
[ 332.362528] R10: R11: 00031a069602 R12: 8802c226ca20
[ 332.364575] R13: 8802c2268000 R14: 880310661000 R15: 000a
[ 332.366615] FS: () GS:88032dc8()
knlGS:
[ 332.368658] CS: 0010 DS: ES: CR0: 80050033
[ 332.370690] CR2: 00ec CR3: 0200a003 CR4: 003606e0
[ 332.372724] DR0: DR1: DR2:
[ 332.374773] DR3: DR6: fffe0ff0 DR7: 0400
[ 332.376798] Call Trace:
[ 332.378809] process_one_work+0x1a1/0x350
[ 332.380806] worker_thread+0x30/0x380
[ 332.382777] ? wq_update_unbound_numa+0x10/0x10
[ 332.384772] kthread+0x112/0x130
[ 332.386740] ? kthread_create_worker_on_cpu+0x70/0x70
[ 332.388706] ret_from_fork+0x35/0x40
[ 332.390651] Modules linked in: i915(O) vfat fat joydev btusb btrtl btbcm
btintel bluetooth ecdh_generic iTCO_wdt wmi_bmof i2c_algo_bit drm_kms_helper
intel_rapl syscopyarea sysfillrect x86_pkg_temp_thermal sysimgblt coretemp
fb_sys_fops crc32_pclmul drm psmouse pcspkr mei_me mei i2c_i801 lpc_ich
mfd_core i2c_core tpm_tis tpm_tis_core thinkpad_acpi wmi tpm rfkill video
crc32c_intel serio_raw ehci_pci xhci_pci ehci_hcd xhci_hcd [last unloaded: i915]
[ 332.394963] CR2: 00ec
This appears to be due to the fact that with an MST topology, not all
intel_connector structs will have ->encoder set. So, fix this by
skipping connectors without encoders in
intel_hpd_irq_storm_reenable_work().
For those wondering, this bug was found on accident while simulating HPD
storms using a Chamelium connected to a ThinkPad T450s (Broadwell).
Changes since v1:
- Check intel_connector->mst_port instead of intel_connector->encoder
Signed-off-by: Lyude Paul
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_hotplug.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_hotplug.c
b/drivers/gpu/drm/i915/intel_hotplug.c
index 648a13c6043c..8326900a311e 100644
--- a/drivers/gpu/drm/i915/intel_hotplug.c
+++ b/drivers/gpu/drm/i915/intel_hotplug.c
@@ -228,7 +228,9 @@ static void intel_hpd_irq_storm_reenable_work(struct
work_struct *work)
drm_for_each_connector_iter(connector, &conn_iter) {
struct intel_connector *intel_connector =
to_intel_connector(connector);
- if (intel_connector->encoder->hpd_pin == pin) {
+ /* Don't check MST ports, they don't have pins */
+ if (!intel_connector->mst_port &&
+ intel_connector->encoder->hpd_pin == pin) {
if (connector->polled !=
intel_connector->polled)
DRM_DEBUG_DRIVER("Reenabling HPD on
connector %s\n",
connector->name);
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 4/5] drm/i915: Clarify flow for disabling IRQs on storms
This is rather confusing to look at as-is: dev_priv->display.hpd_irq_setup(dev_priv); in intel_hpd_irq_handler() handles disabling the actual HPD IRQ, while intel_hpd_irq_storm_disable() handles moving the HPD pin state over from MARK_DISABLED to DISABLED along with enabling polling for it. Cc: Ville Syrjälä Signed-off-by: Lyude Paul --- drivers/gpu/drm/i915/intel_hotplug.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_hotplug.c b/drivers/gpu/drm/i915/intel_hotplug.c index c11d73de16f2..e5e3eeb7e482 100644 --- a/drivers/gpu/drm/i915/intel_hotplug.c +++ b/drivers/gpu/drm/i915/intel_hotplug.c @@ -351,7 +351,7 @@ static void i915_hotplug_work_func(struct work_struct *work) hpd_event_bits = dev_priv->hotplug.event_bits; dev_priv->hotplug.event_bits = 0; - /* Disable hotplug on connectors that hit an irq storm. */ + /* Enable polling for connectors which had HPD IRQ storms */ intel_hpd_irq_storm_disable(dev_priv); spin_unlock_irq(&dev_priv->irq_lock); @@ -458,6 +458,10 @@ void intel_hpd_irq_handler(struct drm_i915_private *dev_priv, } } + /* +* Disable any IRQs that storms were detected on. Polling enablement +* happens later in our hotplug work. +*/ if (storm_detected && dev_priv->display_irqs_enabled) dev_priv->display.hpd_irq_setup(dev_priv); spin_unlock(&dev_priv->irq_lock); -- 2.19.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 3/5] drm/i915: Fix threshold check in intel_hpd_irq_storm_detect()
Currently in intel_hpd_irq_storm_detect() when we detect that the last
recorded hotplug wasn't within the period defined by
HPD_STORM_DETECT_DELAY, we make the mistake of resetting the HPD count
to 0 without incrementing it. This results in us only enabling storm
detection when we go +2 above the threshold, e.g. an HPD threshold of 5
would not trigger a storm until we reach a total of 7 hotplugs.
So: rework the code a bit so we reset the HPD count when
HPD_STORM_DETECT_DELAY has passed, then increment the count afterwards.
Also, clean things up a bit to make it easier to undertand.
Cc: Ville Syrjälä
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/i915/intel_hotplug.c | 23 +--
1 file changed, 13 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_hotplug.c
b/drivers/gpu/drm/i915/intel_hotplug.c
index 8326900a311e..c11d73de16f2 100644
--- a/drivers/gpu/drm/i915/intel_hotplug.c
+++ b/drivers/gpu/drm/i915/intel_hotplug.c
@@ -135,24 +135,27 @@ enum hpd_pin intel_hpd_pin_default(struct
drm_i915_private *dev_priv,
static bool intel_hpd_irq_storm_detect(struct drm_i915_private *dev_priv,
enum hpd_pin pin)
{
- unsigned long start = dev_priv->hotplug.stats[pin].last_jiffies;
+ struct i915_hotplug *hpd = &dev_priv->hotplug;
+ unsigned long start = hpd->stats[pin].last_jiffies;
unsigned long end = start + msecs_to_jiffies(HPD_STORM_DETECT_PERIOD);
- const int threshold = dev_priv->hotplug.hpd_storm_threshold;
+ const int threshold = hpd->hpd_storm_threshold;
bool storm = false;
+ if (!threshold)
+ return false;
+
if (!time_in_range(jiffies, start, end)) {
- dev_priv->hotplug.stats[pin].last_jiffies = jiffies;
- dev_priv->hotplug.stats[pin].count = 0;
- DRM_DEBUG_KMS("Received HPD interrupt on PIN %d - cnt: 0\n",
pin);
- } else if (dev_priv->hotplug.stats[pin].count > threshold &&
- threshold) {
- dev_priv->hotplug.stats[pin].state = HPD_MARK_DISABLED;
+ hpd->stats[pin].last_jiffies = jiffies;
+ hpd->stats[pin].count = 0;
+ }
+
+ if (++hpd->stats[pin].count > threshold) {
+ hpd->stats[pin].state = HPD_MARK_DISABLED;
DRM_DEBUG_KMS("HPD interrupt storm detected on PIN %d\n", pin);
storm = true;
} else {
- dev_priv->hotplug.stats[pin].count++;
DRM_DEBUG_KMS("Received HPD interrupt on PIN %d - cnt: %d\n",
pin,
- dev_priv->hotplug.stats[pin].count);
+ hpd->stats[pin].count);
}
return storm;
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] [PATCH 2/2] drm/msm: subclass work object for vblank events
On 2018-11-01 12:18, Sean Paul wrote:
On Wed, Oct 31, 2018 at 05:19:05PM -0700, Jeykumar Sankaran wrote:
msm maintains a separate structure to define vblank
work definitions and a list to track events submitted
to the display worker thread. We can avoid these
redundant list and its protection mechanism, if we
subclass the work object to encapsulate vblank
event parameters.
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/msm_drv.c | 70
---
drivers/gpu/drm/msm/msm_drv.h | 7 -
2 files changed, 19 insertions(+), 58 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c
b/drivers/gpu/drm/msm/msm_drv.c
index 1f384b3..67a96ee 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -203,61 +203,44 @@ u32 msm_readl(const void __iomem *addr)
return val;
}
-struct vblank_event {
- struct list_head node;
+struct msm_vblank_work {
+ struct kthread_work work;
int crtc_id;
bool enable;
+ struct msm_drm_private *priv;
};
static void vblank_ctrl_worker(struct kthread_work *work)
{
- struct msm_vblank_ctrl *vbl_ctrl = container_of(work,
- struct msm_vblank_ctrl,
work);
- struct msm_drm_private *priv = container_of(vbl_ctrl,
- struct msm_drm_private,
vblank_ctrl);
+ struct msm_vblank_work *vbl_work = container_of(work,
+ struct msm_vblank_work,
work);
+ struct msm_drm_private *priv = vbl_work->priv;
struct msm_kms *kms = priv->kms;
- struct vblank_event *vbl_ev, *tmp;
- unsigned long flags;
-
- spin_lock_irqsave(&vbl_ctrl->lock, flags);
- list_for_each_entry_safe(vbl_ev, tmp, &vbl_ctrl->event_list, node)
{
- list_del(&vbl_ev->node);
- spin_unlock_irqrestore(&vbl_ctrl->lock, flags);
-
- if (vbl_ev->enable)
- kms->funcs->enable_vblank(kms,
-
priv->crtcs[vbl_ev->crtc_id]);
- else
- kms->funcs->disable_vblank(kms,
-
priv->crtcs[vbl_ev->crtc_id]);
- kfree(vbl_ev);
-
- spin_lock_irqsave(&vbl_ctrl->lock, flags);
- }
+ if (vbl_work->enable)
+ kms->funcs->enable_vblank(kms,
priv->crtcs[vbl_work->crtc_id]);
+ else
+ kms->funcs->disable_vblank(kms,
priv->crtcs[vbl_work->crtc_id]);
- spin_unlock_irqrestore(&vbl_ctrl->lock, flags);
+ kfree(vbl_work);
}
static int vblank_ctrl_queue_work(struct msm_drm_private *priv,
int crtc_id, bool enable)
{
- struct msm_vblank_ctrl *vbl_ctrl = &priv->vblank_ctrl;
- struct vblank_event *vbl_ev;
- unsigned long flags;
+ struct msm_vblank_work *vbl_work;
- vbl_ev = kzalloc(sizeof(*vbl_ev), GFP_ATOMIC);
- if (!vbl_ev)
+ vbl_work = kzalloc(sizeof(*vbl_work), GFP_ATOMIC);
+ if (!vbl_work)
return -ENOMEM;
- vbl_ev->crtc_id = crtc_id;
- vbl_ev->enable = enable;
+ kthread_init_work(&vbl_work->work, vblank_ctrl_worker);
- spin_lock_irqsave(&vbl_ctrl->lock, flags);
- list_add_tail(&vbl_ev->node, &vbl_ctrl->event_list);
- spin_unlock_irqrestore(&vbl_ctrl->lock, flags);
+ vbl_work->crtc_id = crtc_id;
+ vbl_work->enable = enable;
+ vbl_work->priv = priv;
- kthread_queue_work(&priv->disp_thread.worker, &vbl_ctrl->work);
+ kthread_queue_work(&priv->disp_thread.worker, &vbl_work->work);
So I think this can get even more simplified. In the short term, you
can
just
use the systemwq to do the enable and disable.
you mean priv->wq?
In the long term, the enable_vblank/disable_vblank functions should be
optimized so they don't sleep. I took a quick look at them perhaps this
is
all because of the crtc_lock mutex? That lock seems a bit suspicious to
me,
especially being dropped around the pm_runtime calls in
_dpu_crtc_vblank_enable_no_lock(). I think we could probably rely on
the
modeset
locks for some of these functions, and perhaps convert it to a spinlock
if
we
can't get rid of it entirely.
crtc_lock has a history of usage in the downstream driver. It was
introduced to protect
vblank variables when vblank requests were handled in the user thread
(not the display thread). When event threads were introduced to receive
encoder events, the lock was further expanded to protect few more vars.
It was
also needed to synchronize CRTC accesses between debugfs dump calls
and display thread.
Would like to deal with this cleanup bit later once we lose these extra
threads.
Thanks and Regards,
Jeykumar S.
Sean
return 0;
}
@@ -269,20 +252,8 @@ static int msm_drm_uninit(struct device *dev)
struct msm_drm_private *priv = ddev->dev_private;
struct msm_kms *kms = priv->kms;
struct msm
[Bug 201139] amdgpu: [drm] enabling link 1 failed: 15 (vega)
https://bugzilla.kernel.org/show_bug.cgi?id=201139 --- Comment #6 from Aleksandr Mezin (mezin.alexan...@gmail.com) --- On both monitors there are no "Auto" input option. DisplayPort is selected on both of them. Also, I've never seen similar problem on RX 580 with the same monitors, either on Linux or Windows. On Windows I frequently see notifications about "link failure" or something like that, but on Windows the driver/card always recovers successfully (so no other problems except the annoying notification). Also, more details, maybe it wasn't clear: 1. After dpms suspend, both monitors woke up, but one of them was showing black screen (but no "no signal" osd or anything like that). No mouse pointer too. But I was able to move the cursor away from the working monitor. xrandr and Gnome settings were showing both monitors too. 2. I turned that "non-working" monitor off. Now the previously working monitor only shows the black screen too. 3. I turned on the second monitor. Black screen moved to it, first monitor started working completely fine. 4. I thought that it's maybe a bug in compositor, so I tried switching VTs, logging out, restarting GDM. It didn't help. 5. Logged in back to Gnome. By changing settings/turning displays on and off I somehow managed to "move" the black screen to the first monitor, and the second one started working. But exactly one monitor (either first or second one) was always showing the black screen. 6. Rebooted, both monitors started working fine -- 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: [Freedreno] [PATCH 1/2] drm/msm: use common display thread for dispatching vblank events
On 2018-11-01 12:09, Sean Paul wrote:
On Wed, Oct 31, 2018 at 05:19:04PM -0700, Jeykumar Sankaran wrote:
DPU was using one thread per display to dispatch async
commits and vblank requests. Since clean up already happened
in msm to use the common thread for all the display commits,
display threads are only used to cater vblank requests. Single
thread is sufficient to do the job without any performance hits.
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 6 +---
drivers/gpu/drm/msm/msm_drv.c | 50
-
drivers/gpu/drm/msm/msm_drv.h | 2 +-
3 files changed, 23 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 82c55ef..aff20f5 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -753,11 +753,7 @@ static int dpu_encoder_resource_control(struct
drm_encoder *drm_enc,
is_vid_mode = dpu_enc->disp_info.capabilities &
MSM_DISPLAY_CAP_VID_MODE;
- if (drm_enc->crtc->index >= ARRAY_SIZE(priv->disp_thread)) {
- DPU_ERROR("invalid crtc index\n");
- return -EINVAL;
- }
- disp_thread = &priv->disp_thread[drm_enc->crtc->index];
+ disp_thread = &priv->disp_thread;
/*
* when idle_pc is not supported, process only KICKOFF, STOP and
MODESET
diff --git a/drivers/gpu/drm/msm/msm_drv.c
b/drivers/gpu/drm/msm/msm_drv.c
index 9c9f7ff..1f384b3 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -257,8 +257,7 @@ static int vblank_ctrl_queue_work(struct
msm_drm_private *priv,
list_add_tail(&vbl_ev->node, &vbl_ctrl->event_list);
spin_unlock_irqrestore(&vbl_ctrl->lock, flags);
- kthread_queue_work(&priv->disp_thread[crtc_id].worker,
- &vbl_ctrl->work);
+ kthread_queue_work(&priv->disp_thread.worker, &vbl_ctrl->work);
return 0;
}
@@ -284,14 +283,12 @@ static int msm_drm_uninit(struct device *dev)
kfree(vbl_ev);
}
+ kthread_flush_worker(&priv->disp_thread.worker);
+ kthread_stop(priv->disp_thread.thread);
I realize this is moving existing code, but is there a race here? You
can't have
work enqueued in between the flush and stop?
Yes. I see only priv->kms is checked before queuing the work.
I can move the thread cleanup after the drm_mode_config_cleanup which
releases the CRTC objects. This way no one can make any further vblank
requests.
Thanks and Regards,
Jeykumar S.
You might also want to use kthread_destroy_worker to do this work (in a
follow-up patch including the event threads too).
+ priv->disp_thread.thread = NULL;
+
/* clean up display commit/event worker threads */
This comment needs updating now
for (i = 0; i < priv->num_crtcs; i++) {
- if (priv->disp_thread[i].thread) {
-
kthread_flush_worker(&priv->disp_thread[i].worker);
- kthread_stop(priv->disp_thread[i].thread);
- priv->disp_thread[i].thread = NULL;
- }
-
if (priv->event_thread[i].thread) {
kthread_flush_worker(&priv->event_thread[i].worker);
kthread_stop(priv->event_thread[i].thread);
@@ -537,6 +534,22 @@ static int msm_drm_init(struct device *dev,
struct
drm_driver *drv)
ddev->mode_config.funcs = &mode_config_funcs;
ddev->mode_config.helper_private = &mode_config_helper_funcs;
+ /* initialize display thread */
+ kthread_init_worker(&priv->disp_thread.worker);
+ priv->disp_thread.dev = ddev;
+ priv->disp_thread.thread = kthread_run(kthread_worker_fn,
+ &priv->disp_thread.worker,
+ "disp_thread");
+ if (IS_ERR(priv->disp_thread.thread)) {
+ DRM_DEV_ERROR(dev, "failed to create crtc_commit
kthread\n");
+ priv->disp_thread.thread = NULL;
+ goto err_msm_uninit;
+ }
+
+ ret = sched_setscheduler(priv->disp_thread.thread, SCHED_FIFO,
¶m);
+ if (ret)
+ pr_warn("display thread priority update failed: %d\n",
ret);
+
/**
* this priority was found during empiric testing to have
appropriate
* realtime scheduling to process display updates and interact
with
@@ -544,27 +557,6 @@ static int msm_drm_init(struct device *dev,
struct
drm_driver *drv)
*/
param.sched_priority = 16;
for (i = 0; i < priv->num_crtcs; i++) {
-
- /* initialize display thread */
- priv->disp_thread[i].crtc_id = priv->crtcs[i]->base.id;
- kthread_init_worker(&priv->disp_thread[i].worker);
- priv->disp_thread[i].dev = ddev;
-
Re: [PATCH 2/2] uapi: fix more linux/kfd_ioctl.h userspace compilation errors
On 2018-11-01 7:03 a.m., Dmitry V. Levin wrote:
> Consistently use types provided by via
> to fix struct kfd_ioctl_get_queue_wave_state_args userspace compilation
> errors.
>
> Fixes: 5df099e8bc83f ("drm/amdkfd: Add wavefront context save state retrieval
> ioctl")
> Signed-off-by: Dmitry V. Levin
Thank you for catching this, and sorry for messing it up incrementally.
Our internal branch is already fixed, but I must have missed this when I
cherry-picked older patches.
The series is Reviewed-by: Felix Kuehling
I also applied it to our amd-staging-drm-next branch.
Regards,
Felix
> ---
> include/uapi/linux/kfd_ioctl.h | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/include/uapi/linux/kfd_ioctl.h b/include/uapi/linux/kfd_ioctl.h
> index dae897f38e59..b01eb502d49c 100644
> --- a/include/uapi/linux/kfd_ioctl.h
> +++ b/include/uapi/linux/kfd_ioctl.h
> @@ -83,11 +83,11 @@ struct kfd_ioctl_set_cu_mask_args {
> };
>
> struct kfd_ioctl_get_queue_wave_state_args {
> - uint64_t ctl_stack_address; /* to KFD */
> - uint32_t ctl_stack_used_size; /* from KFD */
> - uint32_t save_area_used_size; /* from KFD */
> - uint32_t queue_id; /* to KFD */
> - uint32_t pad;
> + __u64 ctl_stack_address;/* to KFD */
> + __u32 ctl_stack_used_size; /* from KFD */
> + __u32 save_area_used_size; /* from KFD */
> + __u32 queue_id; /* to KFD */
> + __u32 pad;
> };
>
> /* For kfd_ioctl_set_memory_policy_args.default_policy and alternate_policy
> */
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 3/3] arm64: dts: sdm845: Add display nodes to MTP dts
Add mdss, dsi, dsi_phy, dsi pinctrl and truly nt35597 panel nodes to
sdm845 MTP board dtsi.
Changes in v4:
- patch introduced in the series
- move around added nodes to preserve alphabetical order (Doug Anderson)
Signed-off-by: Jeykumar Sankaran
---
arch/arm64/boot/dts/qcom/sdm845-mtp.dts | 124
1 file changed, 124 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
b/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
index eedfaf8..eb2a05b 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
+++ b/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
@@ -7,6 +7,7 @@
/dts-v1/;
+#include
#include
#include "sdm845.dtsi"
@@ -343,11 +344,118 @@
};
};
+&dsi0 {
+ status = "okay";
+ qcom,dual-dsi-mode;
+ qcom,master-dsi;
+ qcom,sync-dual-dsi;
+
+ vdda-supply = <&vdda_mipi_dsi0_1p2>;
+
+ panel@0 {
+ compatible = "truly,nt35597-2K-display";
+ reg = <0>;
+
+ vdda-supply = <&vreg_l14a_1p88>;
+ vdispp-supply = <&lab_regulator>;
+ vdispn-supply = <&ibb_regulator>;
+
+ pinctrl-names = "default", "suspend";
+ pinctrl-0 = <&dpu_dsi_active>;
+ pinctrl-1 = <&dpu_dsi_suspend>;
+
+ reset-gpios = <&tlmm 6 GPIO_ACTIVE_HIGH>;
+ mode-gpios = <&tlmm 52 GPIO_ACTIVE_HIGH>;
+
+ display-timings {
+ timing0: timing-0 {
+ /* originally
+* 268316160 Mhz,
+* but value below fits
+* better w/ downstream
+*/
+ clock-frequency = <268316138>;
+ hactive = <1440>;
+ vactive = <2560>;
+ hfront-porch = <200>;
+ hback-porch = <64>;
+ hsync-len = <32>;
+ vfront-porch = <8>;
+ vback-porch = <7>;
+ vsync-len = <1>;
+ };
+ };
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@0 {
+ reg = <0>;
+ panel0_in: endpoint {
+ remote-endpoint = <&dsi0_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ panel1_in: endpoint {
+ remote-endpoint = <&dsi1_out>;
+ };
+ };
+ };
+ };
+
+ ports {
+ port@1 {
+ endpoint {
+ remote-endpoint = <&panel0_in>;
+ data-lanes = <0 1 2 3>;
+ };
+ };
+ };
+};
+
+&dsi0_phy {
+ status = "okay";
+ vdds-supply = <&vdda_mipi_dsi0_pll>;
+};
+
+&dsi1 {
+ status = "okay";
+
+ qcom,dual-dsi-mode;
+ qcom,sync-dual-dsi;
+
+ vdda-supply = <&vdda_mipi_dsi1_1p2>;
+
+ ports {
+ port@1 {
+ endpoint {
+ remote-endpoint = <&panel1_in>;
+ data-lanes = <0 1 2 3>;
+ };
+ };
+ };
+};
+
+&dsi1_phy {
+ status = "okay";
+ vdds-supply = <&vdda_mipi_dsi1_pll>;
+};
+
&i2c10 {
status = "okay";
clock-frequency = <40>;
};
+&mdss {
+ status = "okay";
+};
+
+&mdss_mdp {
+ status = "okay";
+};
+
&qupv3_id_1 {
status = "okay";
};
@@ -419,6 +527,22 @@
/* PINCTRL - additions to nodes defined in sdm845.dtsi */
+&dpu_dsi_active {
+ pinconf {
+ pins = "gpio6", "gpio52";
+ drive-strength = <8>;
+ bias-disable;
+ };
+};
+
+&dpu_dsi_suspend {
+ pinconf {
+ pins = "gpio6", "gpio52";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+};
+
&qup_i2c10_default {
pinconf {
pins = "gpio55", "gpio56";
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 2/3] arm64: dts: sdm845: Add dsi pinctrl nodes
Add dsi active/suspend pinctrl nodes to sdm845 SoC dts.
Changes in v4:
- patch introduced in the series
Signed-off-by: Jeykumar Sankaran
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 5728b4c..35df5d2 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -822,6 +822,20 @@
interrupt-controller;
#interrupt-cells = <2>;
+ dpu_dsi_active: dpu-dsi-active {
+ pinmux {
+ pins = "gpio6", "gpio52";
+ function = "gpio";
+ };
+ };
+
+ dpu_dsi_suspend: dpu-dsi-suspend {
+ pinmux {
+ pins = "gpio6", "gpio52";
+ function = "gpio";
+ };
+ };
+
qup_i2c0_default: qup-i2c0-default {
pinmux {
pins = "gpio0", "gpio1";
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 0/3]
Reviving the patch posted by Sean initially. This patch set adds MDSS and DSI nodes to SDM845 dtsi to enable display. The patches are tested on SDM845 MTP platform using the kernel based on [1]. Part of the dependent drivers are already posted on list. Rest of the dependencies are met using using downstream version of the driver(s) which are yet to make it to the list. References to the driver patches used for testing: display controller: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/arch/arm64/boot/dts/qcom/sdm845.dtsi?id=40019e8452fe76867bdb2e7 WLED: https://patchwork.kernel.org/project/linux-arm-msm/list/?series=11023&archive=both&state=* Panel: https://patchwork.freedesktop.org/series/50657/ iommu: https://patchwork.kernel.org/patch/10534999/ [1] https://git.linaro.org/landing-teams/working/qualcomm/kernel.git/log/?h=integration-linux-qcomlt Thanks and Regards, Jeykumar S. Changes in v4: - changes to add pinctrl nodes to SoC dts and display nodes to MTP are included in the series - clock name clean up in dsi nodes - move around added nodes to maintain naming orders Jeykumar Sankaran (3): arm64: dts: qcom: sdm845: Add dpu to sdm845 dts file arm64: dts: sdm845: Add dsi pinctrl nodes arm64: dts: sdm845: Add display nodes to MTP dts arch/arm64/boot/dts/qcom/sdm845-mtp.dts | 124 +++ arch/arm64/boot/dts/qcom/sdm845.dtsi| 205 2 files changed, 329 insertions(+) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 1/3] arm64: dts: qcom: sdm845: Add dpu to sdm845 dts file
DPU is short for the Display Processing Unit. It is the display
controller on Qualcomm SDM845 chips.
This change adds MDSS and DSI nodes to enable display on the
target device.
Changes in v2:
- Beefed up commit message
- Use SoC specific compatibles for mdss and dpu (Rob H)
- Use assigned-clocks to set initial clock frequency(Rob H)
Changes in v3:
- added IOMMU node
- Fix device naming (remove _phys)
- Use correct IRQ_TYPE in interrupt specifiers
Changes in v4:
- move mdss node to preserve the unit address sort order
- remove _clk suffix from dsi clocks
(both the comments are from Doug Anderson)
Signed-off-by: Jeykumar Sankaran
Signed-off-by: Sean Paul
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 191 +++
1 file changed, 191 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index b72bdb0..5728b4c 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -1248,6 +1248,197 @@
};
};
+ mdss: mdss@ae0 {
+ compatible = "qcom,sdm845-mdss";
+ reg = <0xae0 0x1000>;
+ reg-names = "mdss";
+
+ power-domains = <&dispcc 0>;
+
+ clocks = <&gcc GCC_DISP_AHB_CLK>,
+<&gcc GCC_DISP_AXI_CLK>,
+<&dispcc DISP_CC_MDSS_MDP_CLK>;
+ clock-names = "iface", "bus", "core";
+
+ assigned-clocks = <&dispcc DISP_CC_MDSS_MDP_CLK>;
+ assigned-clock-rates = <3>;
+
+ interrupts = ;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ iommus = <&apps_smmu 0x880 0x8>,
+<&apps_smmu 0xc80 0x8>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ mdss_mdp: mdp@ae01000 {
+ compatible = "qcom,sdm845-dpu";
+ reg = <0x0ae01000 0x8f000>,
+ <0x0aeb 0x2008>;
+ reg-names = "mdp", "vbif";
+
+ clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
+<&dispcc DISP_CC_MDSS_AXI_CLK>,
+<&dispcc DISP_CC_MDSS_MDP_CLK>,
+<&dispcc DISP_CC_MDSS_VSYNC_CLK>;
+ clock-names = "iface", "bus", "core", "vsync";
+
+ assigned-clocks = <&dispcc
DISP_CC_MDSS_MDP_CLK>,
+ <&dispcc
DISP_CC_MDSS_VSYNC_CLK>;
+ assigned-clock-rates = <3>,
+ <1920>;
+
+ interrupt-parent = <&mdss>;
+ interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dpu_intf1_out: endpoint {
+ remote-endpoint =
<&dsi0_in>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dpu_intf2_out: endpoint {
+ remote-endpoint =
<&dsi1_in>;
+ };
+ };
+ };
+ };
+
+ dsi0: dsi@ae94000 {
+ compatible = "qcom,mdss-dsi-ctrl";
+ reg = <0xae94000 0x400>;
+ reg-names = "dsi_ctrl";
+
+ interrupt-parent = <&mdss>;
+ interrupts = <4 IRQ_TYPE_LEVEL_HIGH>;
+
+ clocks = <&dispcc DISP_CC_MDSS_BYTE0_CLK>,
+<&dispcc DISP_CC_MDSS_BYTE0_INTF_CLK>,
+<&dispcc DISP_CC_MDSS_PCLK0_CLK>,
+<&dispcc DISP_CC_MDSS_ESC0_CLK>,
+<&dispcc DISP_CC_MDSS_AHB_CLK>,
+<&dispcc DISP_CC_MD
[PATCH] drm/lease: look at ->universal_planes only once
It's lockless, and userspace might chance it underneath us. That's not
really a problem, all userspace gets is a slightly dysfunctional
lease with the current code. But this might change, and gcc might
decide to reload a few too many times, and then boom. So better safe
than sorry.
v2: Remove the now unused lessor_priv argument from validate_lease()
(Keith).
Cc: Keith Packard
Cc: Dave Airlie
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_lease.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_lease.c b/drivers/gpu/drm/drm_lease.c
index 3b0342a45ae9..739d3830173f 100644
--- a/drivers/gpu/drm/drm_lease.c
+++ b/drivers/gpu/drm/drm_lease.c
@@ -353,9 +353,9 @@ void drm_lease_revoke(struct drm_master *top)
}
static int validate_lease(struct drm_device *dev,
- struct drm_file *lessor_priv,
int object_count,
- struct drm_mode_object **objects)
+ struct drm_mode_object **objects,
+ bool universal_planes)
{
int o;
int has_crtc = -1;
@@ -372,14 +372,14 @@ static int validate_lease(struct drm_device *dev,
if (objects[o]->type == DRM_MODE_OBJECT_CONNECTOR &&
has_connector == -1)
has_connector = o;
- if (lessor_priv->universal_planes) {
+ if (universal_planes) {
if (objects[o]->type == DRM_MODE_OBJECT_PLANE &&
has_plane == -1)
has_plane = o;
}
}
if (has_crtc == -1 || has_connector == -1)
return -EINVAL;
- if (lessor_priv->universal_planes && has_plane == -1)
+ if (universal_planes && has_plane == -1)
return -EINVAL;
return 0;
}
@@ -393,6 +393,8 @@ static int fill_object_idr(struct drm_device *dev,
struct drm_mode_object **objects;
u32 o;
int ret;
+ bool universal_planes = READ_ONCE(lessor_priv->universal_planes);
+
objects = kcalloc(object_count, sizeof(struct drm_mode_object *),
GFP_KERNEL);
if (!objects)
@@ -421,7 +423,8 @@ static int fill_object_idr(struct drm_device *dev,
}
}
- ret = validate_lease(dev, lessor_priv, object_count, objects);
+ ret = validate_lease(dev, lessor_priv, object_count, objects,
+universal_planes);
if (ret) {
DRM_DEBUG_LEASE("lease validation failed\n");
goto out_free_objects;
@@ -448,7 +451,7 @@ static int fill_object_idr(struct drm_device *dev,
object_id, ret);
goto out_free_objects;
}
- if (obj->type == DRM_MODE_OBJECT_CRTC &&
!lessor_priv->universal_planes) {
+ if (obj->type == DRM_MODE_OBJECT_CRTC && !universal_planes) {
struct drm_crtc *crtc = obj_to_crtc(obj);
ret = idr_alloc(leases, &drm_lease_idr_object,
crtc->primary->base.id, crtc->primary->base.id + 1, GFP_KERNEL);
if (ret < 0) {
--
2.14.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] dt-bindings: msm/dsi: Add ref clock for 10nm PHY
Allow the 10nm PHY driver to get the ref clock from the DT. Signed-off-by: Matthias Kaehlcke --- Documentation/devicetree/bindings/display/msm/dsi.txt | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/display/msm/dsi.txt b/Documentation/devicetree/bindings/display/msm/dsi.txt index dfc743219bd88..d0d2046ceff69 100644 --- a/Documentation/devicetree/bindings/display/msm/dsi.txt +++ b/Documentation/devicetree/bindings/display/msm/dsi.txt @@ -105,6 +105,10 @@ Required properties: - power-domains: Should be <&mmcc MDSS_GDSC>. - clocks: Phandles to device clocks. See [1] for details on clock bindings. - clock-names: the following clocks are required: + For 10nm PHY: + * "iface" + * "ref" + For other PHYs: * "iface" For 28nm HPM/LP, 28nm 8960 PHYs: - vddio-supply: phandle to vdd-io regulator device node -- 2.19.1.930.g4563a0d9d0-goog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/msm/dsi: Get PHY ref clock from the DT
Get the PHY ref clock from the device tree instead of hardcoding
its name and rate.
Signed-off-by: Matthias Kaehlcke
---
drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c
b/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c
index 4c03f0b7343ed..1016eb50df8f5 100644
--- a/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c
+++ b/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c
@@ -91,6 +91,8 @@ struct dsi_pll_10nm {
void __iomem *phy_cmn_mmio;
void __iomem *mmio;
+ struct clk *vco_ref_clk;
+
u64 vco_ref_clk_rate;
u64 vco_current_rate;
@@ -630,7 +632,8 @@ static int pll_10nm_register(struct dsi_pll_10nm *pll_10nm)
char clk_name[32], parent[32], vco_name[32];
char parent2[32], parent3[32], parent4[32];
struct clk_init_data vco_init = {
- .parent_names = (const char *[]){ "xo" },
+ .parent_names = (const char *[]){
+ __clk_get_name(pll_10nm->vco_ref_clk) },
.num_parents = 1,
.name = vco_name,
.flags = CLK_IGNORE_UNUSED,
@@ -786,6 +789,12 @@ struct msm_dsi_pll *msm_dsi_pll_10nm_init(struct
platform_device *pdev, int id)
pll_10nm->id = id;
pll_10nm_list[id] = pll_10nm;
+ pll_10nm->vco_ref_clk = devm_clk_get(&pdev->dev, "ref");
+ if (IS_ERR(pll_10nm->vco_ref_clk)) {
+ dev_err(&pdev->dev, "couldn't get 'ref' clock\n");
+ return (void *)pll_10nm->vco_ref_clk;
+ }
+
pll_10nm->phy_cmn_mmio = msm_ioremap(pdev, "dsi_phy", "DSI_PHY");
if (IS_ERR_OR_NULL(pll_10nm->phy_cmn_mmio)) {
dev_err(&pdev->dev, "failed to map CMN PHY base\n");
--
2.19.1.930.g4563a0d9d0-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v8 18/19] drm/i915/dsc: Enable and disable appropriate power wells for VDSC
A separate power well 2 (PG2) is required for VDSC on eDP transcoder
whereas all other transcoders use the power wells associated with the
transcoders for VDSC.
This patch adds a helper to obtain correct power domain depending on
transcoder being used and enables/disables the power wells during
VDSC enabling/disabling.
v4:
* Get VDSC power domain only if compression en is set
in crtc_state (Ville, Imre)
v3:
* Call it intel_dsc_power_domain, add to
intel_ddi_get_power_domains (Ville)
v2:
* Fix tabs, const crtc_state, fix comments (Ville)
Suggested-by: Ville Syrjala
Cc: Ville Syrjala
Cc: Imre Deak
Cc: Rodrigo Vivi
Signed-off-by: Manasi Navare
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_ddi.c | 6 ++
drivers/gpu/drm/i915/intel_drv.h | 2 ++
drivers/gpu/drm/i915/intel_vdsc.c | 25 +
3 files changed, 33 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index bba08322afb7..82d78f2727d8 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2126,6 +2126,12 @@ static u64 intel_ddi_get_power_domains(struct
intel_encoder *encoder,
intel_port_is_tc(dev_priv, encoder->port))
domains |= BIT_ULL(intel_ddi_main_link_aux_domain(dig_port));
+ /*
+* VDSC power is needed when DSC is enabled
+*/
+ if (crtc_state->dsc_params.compression_enable)
+ domains |= BIT_ULL(intel_dsc_power_domain(crtc_state));
+
return domains;
}
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index e537561b3d40..2d41dff6eed1 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1859,6 +1859,8 @@ uint8_t intel_dp_dsc_get_slice_count(struct intel_dp
*intel_dp, int mode_clock,
/* intel_vdsc.c */
int intel_dp_compute_dsc_params(struct intel_dp *intel_dp,
struct intel_crtc_state *pipe_config);
+enum intel_display_power_domain
+intel_dsc_power_domain(const struct intel_crtc_state *crtc_state);
static inline unsigned int intel_dp_unused_lane_mask(int lane_count)
{
diff --git a/drivers/gpu/drm/i915/intel_vdsc.c
b/drivers/gpu/drm/i915/intel_vdsc.c
index 02102cd275fd..a25b71ae9b1c 100644
--- a/drivers/gpu/drm/i915/intel_vdsc.c
+++ b/drivers/gpu/drm/i915/intel_vdsc.c
@@ -581,6 +581,24 @@ int intel_dp_compute_dsc_params(struct intel_dp *intel_dp,
return 0;
}
+enum intel_display_power_domain
+intel_dsc_power_domain(const struct intel_crtc_state *crtc_state)
+{
+ enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
+
+ /*
+* On ICL VDSC/joining for eDP transcoder uses a separate power well PW2
+* This requires POWER_DOMAIN_TRANSCODER_EDP_VDSC power domain.
+* For any other transcoder, VDSC/joining uses the power well associated
+* with the pipe/transcoder in use. Hence another reference on the
+* transcoder power domain will suffice.
+*/
+ if (cpu_transcoder == TRANSCODER_EDP)
+ return POWER_DOMAIN_TRANSCODER_EDP_VDSC;
+ else
+ return POWER_DOMAIN_TRANSCODER(cpu_transcoder);
+}
+
static void intel_configure_pps_for_dsc_encoder(struct intel_encoder *encoder,
const struct intel_crtc_state
*crtc_state)
{
@@ -1020,6 +1038,10 @@ void intel_dsc_enable(struct intel_encoder *encoder,
if (!crtc_state->dsc_params.compression_enable)
return;
+ /* Enable Power wells for VDSC/joining */
+ intel_display_power_get(dev_priv,
+ intel_dsc_power_domain(crtc_state));
+
intel_configure_pps_for_dsc_encoder(encoder, crtc_state);
intel_dp_write_dsc_pps_sdp(encoder, crtc_state);
@@ -1072,4 +1094,7 @@ void intel_dsc_disable(const struct intel_crtc_state
*old_crtc_state)
RIGHT_BRANCH_VDSC_ENABLE);
I915_WRITE(dss_ctl2_reg, dss_ctl2_val);
+ /* Disable Power wells for VDSC/joining */
+ intel_display_power_put(dev_priv,
+ intel_dsc_power_domain(old_crtc_state));
}
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v8 10/19] drm/i915/dsc: Compute Rate Control parameters for DSC
From: Gaurav K Singh
This computation of RC params happens in the atomic commit phase
during compute_config() to validate if display stream compression
can be enabled for the requested mode.
v7 (From Manasi):
* Use DRM_DEBUG instead of DRM_ERROR (Ville)
* Use Error numberinstead of -1 (Ville)
v6 (From Manasi):
* Use 9 instead of 0x9 for consistency (Anusha)
v5 (From Manasi):
* Fix dim checkpatch warnings/checks
v4(From Gaurav):
* No change.Rebase on drm-tip
v3 (From Gaurav):
* Rebase on top of Manasi's latest series
* Return -ve value in case of failure scenarios (Manasi)
Fix review comments from Ville:
* Remove unnecessary comments
* Remove unnecessary paranthesis
* Add comments for few RC params calculations
v2 (From Manasi):
* Rebase Gaurav's patch from intel-gfx to gfx-internal
* Use struct drm_dsc_cfg instead of struct intel_dp
as a parameter
Cc: Manasi Navare
Cc: Jani Nikula
Cc: Ville Syrjala
Signed-off-by: Gaurav K Singh
Signed-off-by: Manasi Navare
Reviewed-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/intel_vdsc.c | 127 ++
1 file changed, 127 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_vdsc.c
b/drivers/gpu/drm/i915/intel_vdsc.c
index 0a1918f2f643..a76f78b9c0ee 100644
--- a/drivers/gpu/drm/i915/intel_vdsc.c
+++ b/drivers/gpu/drm/i915/intel_vdsc.c
@@ -317,6 +317,130 @@ static int get_column_index_for_rc_params(u8
bits_per_component)
}
}
+static int intel_compute_rc_parameters(struct drm_dsc_config *vdsc_cfg)
+{
+ unsigned long groups_per_line = 0;
+ unsigned long groups_total = 0;
+ unsigned long num_extra_mux_bits = 0;
+ unsigned long slice_bits = 0;
+ unsigned long hrd_delay = 0;
+ unsigned long final_scale = 0;
+ unsigned long rbs_min = 0;
+
+ /* Number of groups used to code each line of a slice */
+ groups_per_line = DIV_ROUND_UP(vdsc_cfg->slice_width,
+ DSC_RC_PIXELS_PER_GROUP);
+
+ /* chunksize in Bytes */
+ vdsc_cfg->slice_chunk_size = DIV_ROUND_UP(vdsc_cfg->slice_width *
+ vdsc_cfg->bits_per_pixel,
+ (8 * 16));
+
+ if (vdsc_cfg->convert_rgb)
+ num_extra_mux_bits = 3 * (vdsc_cfg->mux_word_size +
+ (4 * vdsc_cfg->bits_per_component + 4)
+ - 2);
+ else
+ num_extra_mux_bits = 3 * vdsc_cfg->mux_word_size +
+ (4 * vdsc_cfg->bits_per_component + 4) +
+ 2 * (4 * vdsc_cfg->bits_per_component) - 2;
+ /* Number of bits in one Slice */
+ slice_bits = 8 * vdsc_cfg->slice_chunk_size * vdsc_cfg->slice_height;
+
+ while ((num_extra_mux_bits > 0) &&
+ ((slice_bits - num_extra_mux_bits) % vdsc_cfg->mux_word_size))
+ num_extra_mux_bits--;
+
+ if (groups_per_line < vdsc_cfg->initial_scale_value - 8)
+ vdsc_cfg->initial_scale_value = groups_per_line + 8;
+
+ /* scale_decrement_interval calculation according to DSC spec 1.11 */
+ if (vdsc_cfg->initial_scale_value > 8)
+ vdsc_cfg->scale_decrement_interval = groups_per_line /
+ (vdsc_cfg->initial_scale_value - 8);
+ else
+ vdsc_cfg->scale_decrement_interval =
DSC_SCALE_DECREMENT_INTERVAL_MAX;
+
+ vdsc_cfg->final_offset = vdsc_cfg->rc_model_size -
+ (vdsc_cfg->initial_xmit_delay *
+vdsc_cfg->bits_per_pixel + 8) / 16 + num_extra_mux_bits;
+
+ if (vdsc_cfg->final_offset >= vdsc_cfg->rc_model_size) {
+ DRM_DEBUG_KMS("FinalOfs < RcModelSze for this
InitialXmitDelay\n");
+ return -EINVAL;
+ }
+
+ final_scale = (vdsc_cfg->rc_model_size * 8) /
+ (vdsc_cfg->rc_model_size - vdsc_cfg->final_offset);
+ if (vdsc_cfg->slice_height > 1)
+ /*
+* NflBpgOffset is 16 bit value with 11 fractional bits
+* hence we multiply by 2^11 for preserving the
+* fractional part
+*/
+ vdsc_cfg->nfl_bpg_offset =
DIV_ROUND_UP((vdsc_cfg->first_line_bpg_offset << 11),
+ (vdsc_cfg->slice_height
- 1));
+ else
+ vdsc_cfg->nfl_bpg_offset = 0;
+
+ /* 2^16 - 1 */
+ if (vdsc_cfg->nfl_bpg_offset > 65535) {
+ DRM_DEBUG_KMS("NflBpgOffset is too large for this slice
height\n");
+ return -EINVAL;
+ }
+
+ /* Number of groups used to code the entire slice */
+ groups_total = groups_per_line * vdsc_cfg->slice_height;
+
+ /* slice_bpg_offset is 16 bit value with 11 fractional bits */
+ vdsc_cfg->slice_bpg_offset = DIV_ROUND_UP(((vdsc_cfg->rc_model_size -
+ vdsc_cfg->initial_off
[PATCH v8 17/19] drm/i915/dp: Disable DSC in source by disabling DSS CTL bits
1. Disable Left/right VDSC branch in DSS Ctrl reg
depending on the number of VDSC engines being used
2. Disable joiner in DSS Ctrl reg
v4:
* Remove encoder, make crtc_state const (Ville)
v3 (From Manasi):
* Add Disable PG2 for VDSC on eDP
v2 (From Manasi):
* Use old_crtc_state to find dsc params
* Add a condition to disable only if
dsc state compression is enabled
* Use correct DSS CTL regs
Cc: Jani Nikula
Cc: Ville Syrjala
Cc: Anusha Srivatsa
Signed-off-by: Manasi Navare
Signed-off-by: Gaurav K Singh
Reviewed-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_display.c | 2 ++
drivers/gpu/drm/i915/intel_vdsc.c| 32
3 files changed, 35 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f347d0d7b9eb..c80c9a1af3d1 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3487,6 +3487,7 @@ extern bool intel_set_memory_cxsr(struct drm_i915_private
*dev_priv,
bool enable);
extern void intel_dsc_enable(struct intel_encoder *encoder,
const struct intel_crtc_state *crtc_state);
+extern void intel_dsc_disable(const struct intel_crtc_state *crtc_state);
int i915_reg_read_ioctl(struct drm_device *dev, void *data,
struct drm_file *file);
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index d3aa77f4d606..cbeea906c531 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5848,6 +5848,8 @@ static void haswell_crtc_disable(struct intel_crtc_state
*old_crtc_state,
if (!transcoder_is_dsi(cpu_transcoder))
intel_ddi_disable_transcoder_func(old_crtc_state);
+ intel_dsc_disable(old_crtc_state);
+
if (INTEL_GEN(dev_priv) >= 9)
skylake_scaler_disable(intel_crtc);
else
diff --git a/drivers/gpu/drm/i915/intel_vdsc.c
b/drivers/gpu/drm/i915/intel_vdsc.c
index fae5193551d8..02102cd275fd 100644
--- a/drivers/gpu/drm/i915/intel_vdsc.c
+++ b/drivers/gpu/drm/i915/intel_vdsc.c
@@ -1041,3 +1041,35 @@ void intel_dsc_enable(struct intel_encoder *encoder,
return;
}
+
+void intel_dsc_disable(const struct intel_crtc_state *old_crtc_state)
+{
+ struct intel_crtc *crtc = to_intel_crtc(old_crtc_state->base.crtc);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ enum pipe pipe = crtc->pipe;
+ i915_reg_t dss_ctl1_reg, dss_ctl2_reg;
+ u32 dss_ctl1_val = 0, dss_ctl2_val = 0;
+
+ if (!old_crtc_state->dsc_params.compression_enable)
+ return;
+
+ if (old_crtc_state->cpu_transcoder == TRANSCODER_EDP) {
+ dss_ctl1_reg = DSS_CTL1;
+ dss_ctl2_reg = DSS_CTL2;
+ } else {
+ dss_ctl1_reg = ICL_PIPE_DSS_CTL1(pipe);
+ dss_ctl2_reg = ICL_PIPE_DSS_CTL2(pipe);
+ }
+ dss_ctl1_val = I915_READ(dss_ctl1_reg);
+ if (dss_ctl1_val & JOINER_ENABLE)
+ dss_ctl1_val &= ~JOINER_ENABLE;
+ I915_WRITE(dss_ctl1_reg, dss_ctl1_val);
+
+ dss_ctl2_val = I915_READ(dss_ctl2_reg);
+ if (dss_ctl2_val & LEFT_BRANCH_VDSC_ENABLE ||
+ dss_ctl2_val & RIGHT_BRANCH_VDSC_ENABLE)
+ dss_ctl2_val &= ~(LEFT_BRANCH_VDSC_ENABLE |
+ RIGHT_BRANCH_VDSC_ENABLE);
+ I915_WRITE(dss_ctl2_reg, dss_ctl2_val);
+
+}
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v8 01/19] drm/dsc: Define Display Stream Compression PPS infoframe
This patch defines a new header file for all the DSC 1.2 structures
and creates a structure for PPS infoframe which will be used to send
picture parameter set secondary data packet for display stream compression.
All the PPS infoframe syntax elements are taken from DSC 1.2 specification
from VESA.
v4:
* Remove redundant blankline in doc (Ville)
* use drm_dsc namespace for all structs (Ville)
* Use packed struct (Ville)
v3:
* Add the SPDX shorthand (Chris Wilson)
v2:
* Do not use bitfields in the struct (Jani Nikula)
Cc: Gaurav K Singh
Cc: dri-devel@lists.freedesktop.org
Cc: Jani Nikula
Cc: Ville Syrjala
Cc: Anusha Srivatsa
Cc: Harry Wentland
Signed-off-by: Manasi Navare
Reviewed-by: Harry Wentland
---
include/drm/drm_dsc.h | 342 ++
1 file changed, 342 insertions(+)
create mode 100644 include/drm/drm_dsc.h
diff --git a/include/drm/drm_dsc.h b/include/drm/drm_dsc.h
new file mode 100644
index ..78db4f61d01c
--- /dev/null
+++ b/include/drm/drm_dsc.h
@@ -0,0 +1,342 @@
+/* SPDX-License-Identifier: MIT
+ * Copyright (C) 2018 Intel Corp.
+ *
+ * Authors:
+ * Manasi Navare
+ */
+
+#ifndef DRM_DSC_H_
+#define DRM_DSC_H_
+
+#include
+
+/* VESA Display Stream Compression DSC 1.2 constants */
+#define DSC_NUM_BUF_RANGES 15
+
+/**
+ * struct picture_parameter_set - Represents 128 bytes of Picture Parameter Set
+ *
+ * The VESA DSC standard defines picture parameter set (PPS) which display
+ * stream compression encoders must communicate to decoders.
+ * The PPS is encapsulated in 128 bytes (PPS 0 through PPS 127). The fields in
+ * this structure are as per Table 4.1 in Vesa DSC specification v1.1/v1.2.
+ * The PPS fields that span over more than a byte should be stored in Big
Endian
+ * format.
+ */
+struct drm_dsc_picture_parameter_set {
+ /**
+* @dsc_version:
+* PPS0[3:0] - dsc_version_minor: Contains Minor version of DSC
+* PPS0[7:4] - dsc_version_major: Contains major version of DSC
+*/
+ u8 dsc_version;
+ /**
+* @pps_identifier:
+* PPS1[7:0] - Application specific identifier that can be
+* used to differentiate between different PPS tables.
+*/
+ u8 pps_identifier;
+ /**
+* @pps_reserved:
+* PPS2[7:0]- RESERVED Byte
+*/
+ u8 pps_reserved;
+ /**
+* @pps_3:
+* PPS3[3:0] - linebuf_depth: Contains linebuffer bit depth used to
+* generate the bitstream. (0x0 - 16 bits for DSC 1.2, 0x8 - 8 bits,
+* 0xA - 10 bits, 0xB - 11 bits, 0xC - 12 bits, 0xD - 13 bits,
+* 0xE - 14 bits for DSC1.2, 0xF - 14 bits for DSC 1.2.
+* PPS3[7:4] - bits_per_component: Bits per component for the original
+* pixels of the encoded picture.
+* 0x0 = 16bpc (allowed only when dsc_version_minor = 0x2)
+* 0x8 = 8bpc, 0xA = 10bpc, 0xC = 12bpc, 0xE = 14bpc (also
+* allowed only when dsc_minor_version = 0x2)
+*/
+ u8 pps_3;
+ /**
+* @pps_4:
+* PPS4[1:0] -These are the most significant 2 bits of
+* compressed BPP bits_per_pixel[9:0] syntax element.
+* PPS4[2] - vbr_enable: 0 = VBR disabled, 1 = VBR enabled
+* PPS4[3] - simple_422: Indicates if decoder drops samples to
+* reconstruct the 4:2:2 picture.
+* PPS4[4] - Convert_rgb: Indicates if DSC color space conversion is
+* active.
+* PPS4[5] - blobk_pred_enable: Indicates if BP is used to code any
+* groups in picture
+* PPS4[7:6] - Reseved bits
+*/
+ u8 pps_4;
+ /**
+* @bits_per_pixel_low:
+* PPS5[7:0] - This indicates the lower significant 8 bits of
+* the compressed BPP bits_per_pixel[9:0] element.
+*/
+ u8 bits_per_pixel_low;
+ /**
+* @pic_height:
+* PPS6[7:0], PPS7[7:0] -pic_height: Specifies the number of pixel rows
+* within the raster.
+*/
+ __be16 pic_height;
+ /**
+* @pic_width:
+* PPS8[7:0], PPS9[7:0] - pic_width: Number of pixel columns within
+* the raster.
+*/
+ __be16 pic_width;
+ /**
+* @slice_height:
+* PPS10[7:0], PPS11[7:0] - Slice height in units of pixels.
+*/
+ __be16 slice_height;
+ /**
+* @slice_width:
+* PPS12[7:0], PPS13[7:0] - Slice width in terms of pixels.
+*/
+ __be16 slice_width;
+ /**
+* @chunk_size:
+* PPS14[7:0], PPS15[7:0] - Size in units of bytes of the chunks
+* that are used for slice multiplexing.
+*/
+ __be16 chunk_size;
+ /**
+* @initial_xmit_delay_high:
+* PPS16[1:0] - Most Significant two bits of initial transmission delay.
+* It specifies the number of pixel times that the encoder waits before
+* transmitting data from its rate buffer.
+* PPS16[7:2] - Reserved
+*/
+
[PATCH v8 16/19] drm/i915/dp: Configure Display stream splitter registers during DSC enable
Display Stream Splitter registers need to be programmed to enable
the joiner if two DSC engines are used and also to enable
the left and the right DSC engines. This happens as part of
the DSC enabling routine in the source in atomic commit.
v4:
* Remove redundant comment (Ville)
v3:
* Use cpu_transcoder instead of encoder->type (Ville)
v2:
* Rebase (Manasi)
Cc: Jani Nikula
Cc: Ville Syrjala
Cc: Anusha Srivatsa
Signed-off-by: Manasi Navare
Reviewed-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/intel_vdsc.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_vdsc.c
b/drivers/gpu/drm/i915/intel_vdsc.c
index 85af5f784aad..fae5193551d8 100644
--- a/drivers/gpu/drm/i915/intel_vdsc.c
+++ b/drivers/gpu/drm/i915/intel_vdsc.c
@@ -1010,6 +1010,12 @@ static void intel_dp_write_dsc_pps_sdp(struct
intel_encoder *encoder,
void intel_dsc_enable(struct intel_encoder *encoder,
const struct intel_crtc_state *crtc_state)
{
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
+ struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+ enum pipe pipe = crtc->pipe;
+ i915_reg_t dss_ctl1_reg, dss_ctl2_reg;
+ u32 dss_ctl1_val = 0;
+ u32 dss_ctl2_val = 0;
if (!crtc_state->dsc_params.compression_enable)
return;
@@ -1018,5 +1024,20 @@ void intel_dsc_enable(struct intel_encoder *encoder,
intel_dp_write_dsc_pps_sdp(encoder, crtc_state);
+ if (crtc_state->cpu_transcoder == TRANSCODER_EDP) {
+ dss_ctl1_reg = DSS_CTL1;
+ dss_ctl2_reg = DSS_CTL2;
+ } else {
+ dss_ctl1_reg = ICL_PIPE_DSS_CTL1(pipe);
+ dss_ctl2_reg = ICL_PIPE_DSS_CTL2(pipe);
+ }
+ dss_ctl2_val |= LEFT_BRANCH_VDSC_ENABLE;
+ if (crtc_state->dsc_params.dsc_split) {
+ dss_ctl2_val |= RIGHT_BRANCH_VDSC_ENABLE;
+ dss_ctl1_val |= JOINER_ENABLE;
+ }
+ I915_WRITE(dss_ctl1_reg, dss_ctl1_val);
+ I915_WRITE(dss_ctl2_reg, dss_ctl2_val);
+
return;
}
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v8 07/19] drm/i915/dp: Compute DSC pipe config in atomic check
DSC params like the enable, compressed bpp, slice count and
dsc_split are added to the intel_crtc_state. These parameters
are set based on the requested mode and available link parameters
during the pipe configuration in atomic check phase.
These values are then later used to populate the remaining DSC
and RC parameters before enbaling DSC in atomic commit.
v11:
* Const crtc_state, reject DSC on DP without FEC (Ville)
* Dont set dsc_split to false (Ville)
v10:
* Add a helper for dp_dsc support (Ville)
* Set pipe_config to max bpp, link params for DSC for now (Ville)
* Compute bpp - use dp dsc support helper (Ville)
v9:
* Rebase on top of drm-tip that now uses fast_narrow config
for edp (Manasi)
v8:
* Check for DSC bpc not 0 (manasi)
v7:
* Fix indentation in compute_m_n (Manasi)
v6 (From Gaurav):
* Remove function call of intel_dp_compute_dsc_params() and
invoke intel_dp_compute_dsc_params() in the patch where
it is defined to fix compilation warning (Gaurav)
v5:
Add drm_dsc_cfg in intel_crtc_state (Manasi)
v4:
* Rebase on refactoring of intel_dp_compute_config on tip (Manasi)
* Add a comment why we need to check PSR while enabling DSC (Gaurav)
v3:
* Check PPR > max_cdclock to use 2 VDSC instances (Ville)
v2:
* Add if-else for eDP/DP (Gaurav)
Cc: Jani Nikula
Cc: Ville Syrjala
Cc: Anusha Srivatsa
Cc: Gaurav K Singh
Signed-off-by: Manasi Navare
Reviewed-by: Anusha Srivatsa
Acked-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_display.c | 20 +++-
drivers/gpu/drm/i915/intel_display.h | 3 +-
drivers/gpu/drm/i915/intel_dp.c | 167 ---
drivers/gpu/drm/i915/intel_dp_mst.c | 2 +-
4 files changed, 166 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index b219d5858160..477e53c37353 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6442,7 +6442,7 @@ static int ironlake_fdi_compute_config(struct intel_crtc
*intel_crtc,
pipe_config->fdi_lanes = lane;
- intel_link_compute_m_n(pipe_config->pipe_bpp, lane, fdi_dotclock,
+ intel_link_compute_m_n(pipe_config->pipe_bpp, 0, lane, fdi_dotclock,
link_bw, &pipe_config->fdi_m_n, false);
ret = ironlake_check_fdi_lanes(dev, intel_crtc->pipe, pipe_config);
@@ -6679,17 +6679,25 @@ static void compute_m_n(unsigned int m, unsigned int n,
}
void
-intel_link_compute_m_n(int bits_per_pixel, int nlanes,
+intel_link_compute_m_n(int bits_per_pixel, uint16_t compressed_bpp,
+ int nlanes,
int pixel_clock, int link_clock,
struct intel_link_m_n *m_n,
bool constant_n)
{
m_n->tu = 64;
- compute_m_n(bits_per_pixel * pixel_clock,
- link_clock * nlanes * 8,
- &m_n->gmch_m, &m_n->gmch_n,
- constant_n);
+ /* For DSC, Data M/N calculation uses compressed BPP */
+ if (compressed_bpp)
+ compute_m_n(compressed_bpp * pixel_clock,
+ link_clock * nlanes * 8,
+ &m_n->gmch_m, &m_n->gmch_n,
+ constant_n);
+ else
+ compute_m_n(bits_per_pixel * pixel_clock,
+ link_clock * nlanes * 8,
+ &m_n->gmch_m, &m_n->gmch_n,
+ constant_n);
compute_m_n(pixel_clock, link_clock,
&m_n->link_m, &m_n->link_n,
diff --git a/drivers/gpu/drm/i915/intel_display.h
b/drivers/gpu/drm/i915/intel_display.h
index 5d50decbcbb5..b0b23e1e9392 100644
--- a/drivers/gpu/drm/i915/intel_display.h
+++ b/drivers/gpu/drm/i915/intel_display.h
@@ -407,7 +407,8 @@ struct intel_link_m_n {
(__i)++) \
for_each_if(plane)
-void intel_link_compute_m_n(int bpp, int nlanes,
+void intel_link_compute_m_n(int bpp, uint16_t compressed_bpp,
+ int nlanes,
int pixel_clock, int link_clock,
struct intel_link_m_n *m_n,
bool constant_n);
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index b39b4bda8e40..58326fc9d935 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -47,6 +47,8 @@
/* DP DSC small joiner has 2 FIFOs each of 640 x 6 bytes */
#define DP_DSC_MAX_SMALL_JOINER_RAM_BUFFER 61440
+#define DP_DSC_MIN_SUPPORTED_BPC 8
+#define DP_DSC_MAX_SUPPORTED_BPC 10
/* DP DSC throughput values used for slice count calculations KPixels/s */
#define DP_DSC_PEAK_PIXEL_RATE 272
@@ -1840,6 +1842,29 @@ struct link_config_limits {
int min_bpp, max_bpp;
};
+static bool intel_dp_source_supports_dsc(struct intel_dp *intel_dp,
+const struct intel_crtc_stat
[PATCH v8 09/19] drm/i915/dsc: Define & Compute VESA DSC params
From: Gaurav K Singh
This patches does the following:
1. This patch defines all the DSC parameters as per the VESA
DSC specification. These are stored in the encoder and used
to compute the PPS parameters to be sent to the Sink.
2. Compute all the DSC parameters which are derived from DSC
state of intel_crtc_state.
3. Compute all parameters that are VESA DSC specific
This computation happens in the atomic check phase during
compute_config() to validate if display stream compression
can be enabled for the requested mode.
v8 (From Manasi):
* DEBUG_KMS instead of DRM_ERROR for user triggerable
errors (Ville)
v7: (From Manasi)
* Dont use signed int for rc_range_params (Manasi)
* Mask the range_bpg_offset to use only 6 bits
* Add SPDX identifier (Chris Wilson)
v6 (From Manasi):
* Add a check for line_buf_depth return value (Anusha)
* Remove DRM DSC constants to different patch (Manasi)
v5 (From Manasi):
* Add logic to limit the max line buf depth for DSC 1.1 to 13
as per DSC 1.1 spec
* Fix dim checkpatch warnings/checks
v4 (From Gaurav):
* Rebase on latest drm tip
* rename variable name(Manasi)
* Populate linebuf_depth variable(Manasi)
v3 (From Gaurav):
* Rebase my previous patches on top of Manasi's latest patch
series
* Using >>n rather than /2^n (Manasi)
* Change the commit message to explain what the patch is doing(Gaurav)
Fixed review comments from Ville:
* Don't use macro TWOS_COMPLEMENT
* Mention in comment about the source of RC params
* Return directly from case statements
* Using single asssignment for assigning rc_range_params
* Using <
Cc: Ville Syrjala
Cc: Anusha Srivatsa
Cc: Gaurav K Singh
Signed-off-by: Gaurav K Singh
Signed-off-by: Manasi Navare
Co-developed-by: Manasi Navare
Reviewed-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/Makefile | 3 +-
drivers/gpu/drm/i915/intel_dp.c | 7 +
drivers/gpu/drm/i915/intel_drv.h | 4 +
drivers/gpu/drm/i915/intel_vdsc.c | 455 ++
include/drm/drm_dp_helper.h | 3 +
5 files changed, 471 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/i915/intel_vdsc.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 28c7d7884e88..a51a9ae0f496 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -156,7 +156,8 @@ i915-y += dvo_ch7017.o \
intel_sdvo.o \
intel_tv.o \
vlv_dsi.o \
- vlv_dsi_pll.o
+ vlv_dsi_pll.o \
+ intel_vdsc.o
# Post-mortem debug and GPU hang state capture
i915-$(CONFIG_DRM_I915_CAPTURE_ERROR) += i915_gpu_error.o
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 58326fc9d935..3d401a4e93b8 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2072,6 +2072,13 @@ static bool intel_dp_dsc_compute_config(struct intel_dp
*intel_dp,
return false;
}
}
+ if (intel_dp_compute_dsc_params(intel_dp, pipe_config) < 0) {
+ DRM_DEBUG_KMS("Cannot compute valid DSC parameters for Input
Bpp = %d"
+ "Compressed BPP = %d\n",
+ pipe_config->pipe_bpp,
+ pipe_config->dsc_params.compressed_bpp);
+ return false;
+ }
pipe_config->dsc_params.compression_enable = true;
DRM_DEBUG_KMS("DP DSC computed with Input Bpp = %d "
"Compressed Bpp = %d Slice Count = %d\n",
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 491872353cf0..3b57146766bb 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1853,6 +1853,10 @@ uint16_t intel_dp_dsc_get_output_bpp(int link_clock,
uint8_t lane_count,
uint8_t intel_dp_dsc_get_slice_count(struct intel_dp *intel_dp, int mode_clock,
int mode_hdisplay);
+/* intel_vdsc.c */
+int intel_dp_compute_dsc_params(struct intel_dp *intel_dp,
+ struct intel_crtc_state *pipe_config);
+
static inline unsigned int intel_dp_unused_lane_mask(int lane_count)
{
return ~((1 << lane_count) - 1) & 0xf;
diff --git a/drivers/gpu/drm/i915/intel_vdsc.c
b/drivers/gpu/drm/i915/intel_vdsc.c
new file mode 100644
index ..0a1918f2f643
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_vdsc.c
@@ -0,0 +1,455 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2018 Intel Corporation
+ *
+ * Author: Gaurav K Singh
+ * Manasi Navare
+ */
+
+#include
+#include
+#include "i915_drv.h"
+#include "intel_drv.h"
+
+enum ROW_INDEX_BPP {
+ ROW_INDEX_6BPP = 0,
+ ROW_INDEX_8BPP,
+ ROW_INDEX_10BPP,
+ ROW_INDEX_12BPP,
+ ROW_INDEX_15BPP,
+ MAX_ROW_INDEX
+};
+
+enum COLUMN_INDEX_BPC {
+ COLUMN_INDEX_8BPC = 0,
+ COLUMN_INDEX_10BPC,
+ COLUMN_INDEX_12BPC,
+ COLUMN_INDEX_14BPC,
+ COLUMN_INDEX_16BPC,
+ MA
[PATCH v8 15/19] drm/i915/dp: Populate DSC PPS SDP and send PPS infoframes
DSC PPS secondary data packet infoframes are filled with
DSC picure parameter set metadata according to the DSC standard.
These infoframes are sent to the sink device and used during DSC
decoding.
v3:
* Rename to intel_dp_write_pps_sdp (Ville)
* Use const intel_crtc_state (Ville)
v2:
* Rebase ond drm-tip
Cc: Jani Nikula
Cc: Ville Syrjala
Cc: Anusha Srivatsa
Signed-off-by: Manasi Navare
Reviewed-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/intel_vdsc.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_vdsc.c
b/drivers/gpu/drm/i915/intel_vdsc.c
index 0eaa69778160..85af5f784aad 100644
--- a/drivers/gpu/drm/i915/intel_vdsc.c
+++ b/drivers/gpu/drm/i915/intel_vdsc.c
@@ -988,6 +988,25 @@ static void intel_configure_pps_for_dsc_encoder(struct
intel_encoder *encoder,
}
}
+static void intel_dp_write_dsc_pps_sdp(struct intel_encoder *encoder,
+ const struct intel_crtc_state
*crtc_state)
+{
+ struct intel_dp *intel_dp = enc_to_intel_dp(&encoder->base);
+ struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
+ const struct drm_dsc_config *vdsc_cfg = &crtc_state->dp_dsc_cfg;
+ struct drm_dsc_pps_infoframe dp_dsc_pps_sdp;
+
+ /* Prepare DP SDP PPS header as per DP 1.4 spec, Table 2-123 */
+ drm_dsc_dp_pps_header_init(&dp_dsc_pps_sdp);
+
+ /* Fill the PPS payload bytes as per DSC spec 1.2 Table 4-1 */
+ drm_dsc_pps_infoframe_pack(&dp_dsc_pps_sdp, vdsc_cfg);
+
+ intel_dig_port->write_infoframe(encoder, crtc_state,
+ DP_SDP_PPS, &dp_dsc_pps_sdp,
+ sizeof(dp_dsc_pps_sdp));
+}
+
void intel_dsc_enable(struct intel_encoder *encoder,
const struct intel_crtc_state *crtc_state)
{
@@ -997,5 +1016,7 @@ void intel_dsc_enable(struct intel_encoder *encoder,
intel_configure_pps_for_dsc_encoder(encoder, crtc_state);
+ intel_dp_write_dsc_pps_sdp(encoder, crtc_state);
+
return;
}
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v8 19/19] drm/i915/dsc: Add Per connector debugfs node for DSC support/enable
DSC can be supported per DP connector. This patch adds a per connector
debugfs node to expose DSC support capability by the kernel.
The same node can be used from userspace to force DSC enable.
force_dsc_en written through this debugfs node is used to force
DSC even for lower resolutions.
v3:
* Combine Force_dsc_en with this patch (Ville)
v2:
* Use kstrtobool_from_user to avoid explicit error checking (Lyude)
* Rebase on drm-tip (Manasi)
Cc: Rodrigo Vivi
Cc: Ville Syrjala
Cc: Anusha Srivatsa
Cc: Lyude Paul
Signed-off-by: Manasi Navare
Reviewed-by: Lyude Paul
---
drivers/gpu/drm/i915/i915_debugfs.c | 71 -
drivers/gpu/drm/i915/intel_dp.c | 3 +-
drivers/gpu/drm/i915/intel_drv.h| 3 ++
3 files changed, 75 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 1a4d9d996fda..fe619b54b64d 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -5000,6 +5000,72 @@ static int i915_hdcp_sink_capability_show(struct
seq_file *m, void *data)
}
DEFINE_SHOW_ATTRIBUTE(i915_hdcp_sink_capability);
+static int i915_dsc_support_show(struct seq_file *m, void *data)
+{
+ struct drm_connector *connector = m->private;
+ struct intel_encoder *encoder = intel_attached_encoder(connector);
+ struct intel_dp *intel_dp =
+ enc_to_intel_dp(&encoder->base);
+ struct intel_crtc *crtc;
+ struct intel_crtc_state *crtc_state;
+
+ crtc = to_intel_crtc(encoder->base.crtc);
+ crtc_state = to_intel_crtc_state(crtc->base.state);
+ drm_modeset_lock(&crtc->base.mutex, NULL);
+ seq_printf(m, "Enabled: %s\n",
+ yesno(crtc_state->dsc_params.compression_enable));
+ seq_printf(m, "Supported: %s\n",
+ yesno(drm_dp_sink_supports_dsc(intel_dp->dsc_dpcd)));
+ drm_modeset_unlock(&crtc->base.mutex);
+
+ return 0;
+}
+
+static ssize_t i915_dsc_support_write(struct file *file,
+ const char __user *ubuf,
+ size_t len, loff_t *offp)
+{
+ bool dsc_enable = false;
+ int ret;
+ struct drm_connector *connector =
+ ((struct seq_file *)file->private_data)->private;
+ struct intel_encoder *encoder = intel_attached_encoder(connector);
+ struct intel_dp *intel_dp = enc_to_intel_dp(&encoder->base);
+
+ if (len == 0)
+ return 0;
+
+ DRM_DEBUG_DRIVER("Copied %d bytes from user to force DSC\n",
+(unsigned int)len);
+
+ ret = kstrtobool_from_user(ubuf, len, &dsc_enable);
+ if (ret < 0)
+ return ret;
+
+ DRM_DEBUG_DRIVER("Got %s for DSC Enable\n",
+(dsc_enable) ? "true" : "false");
+ intel_dp->force_dsc_en = dsc_enable;
+
+ *offp += len;
+ return len;
+}
+
+static int i915_dsc_support_open(struct inode *inode,
+struct file *file)
+{
+ return single_open(file, i915_dsc_support_show,
+ inode->i_private);
+}
+
+static const struct file_operations i915_dsc_support_fops = {
+ .owner = THIS_MODULE,
+ .open = i915_dsc_support_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = single_release,
+ .write = i915_dsc_support_write
+};
+
/**
* i915_debugfs_connector_add - add i915 specific connector debugfs files
* @connector: pointer to a registered drm_connector
@@ -5018,9 +5084,12 @@ int i915_debugfs_connector_add(struct drm_connector
*connector)
return -ENODEV;
if (connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
- connector->connector_type == DRM_MODE_CONNECTOR_eDP)
+ connector->connector_type == DRM_MODE_CONNECTOR_eDP) {
debugfs_create_file("i915_dpcd", S_IRUGO, root,
connector, &i915_dpcd_fops);
+ debugfs_create_file("i915_dsc_support", S_IRUGO, root,
+ connector, &i915_dsc_support_fops);
+ }
if (connector->connector_type == DRM_MODE_CONNECTOR_eDP) {
debugfs_create_file("i915_panel_timings", S_IRUGO, root,
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index f8bf942c8f71..4d866d49d870 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2158,7 +2158,7 @@ intel_dp_compute_link_config(struct intel_encoder
*encoder,
&limits);
/* enable compression if the mode doesn't fit available BW */
- if (!ret) {
+ if (!ret || intel_dp->force_dsc_en) {
if (!intel_dp_dsc_compute_config(intel_dp, pipe_config,
&limits))
return false;
@@ -2251,6 +2251,7 @@ int
[PATCH v8 13/19] drm/i915/dp: Configure i915 Picture parameter Set registers during DSC enabling
After encoder->pre_enable() hook, after link training sequence is
completed, PPS registers for DSC encoder are configured using the
DSC state parameters in intel_crtc_state as part of DSC enabling
routine in the source. DSC enabling routine is called after
encoder->pre_enable() before enbaling the pipe and after
compression is enabled on the sink.
v6:
intel_dsc_enable to be part of pre_enable hook (Ville)
v5:
* make crtc_state const (Ville)
v4:
* Use cpu_transcoder instead of encoder->type for using EDP transcoder
DSC registers(Ville)
* Keep all PSS regs together (Anusha)
v3:
* Configure Pic_width/2 for each VDSC engine when two VDSC engines per pipe
are used (Manasi)
* Add DSC slice_row_per_frame in PPS16 (Manasi)
v2:
* Enable PG2 power well for VDSC on eDP
Cc: Jani Nikula
Cc: Ville Syrjala
Cc: Anusha Srivatsa
Signed-off-by: Manasi Navare
Reviewed-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/i915_drv.h | 2 +
drivers/gpu/drm/i915/intel_ddi.c | 6 +
drivers/gpu/drm/i915/intel_display.c | 1 +
drivers/gpu/drm/i915/intel_vdsc.c| 419 +++
4 files changed, 428 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d7797a41c648..f347d0d7b9eb 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3485,6 +3485,8 @@ extern void intel_rps_mark_interactive(struct
drm_i915_private *i915,
bool interactive);
extern bool intel_set_memory_cxsr(struct drm_i915_private *dev_priv,
bool enable);
+extern void intel_dsc_enable(struct intel_encoder *encoder,
+const struct intel_crtc_state *crtc_state);
int i915_reg_read_ioctl(struct drm_device *dev, void *data,
struct drm_file *file);
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index af12c15ed94f..bba08322afb7 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2962,6 +2962,12 @@ static void intel_ddi_pre_enable_dp(struct intel_encoder
*encoder,
if (!is_mst)
intel_ddi_enable_pipe_clock(crtc_state);
+
+ /*
+* Enable and Configure Display Stream Compression in the source
+* if enabled in intel_crtc_state.
+*/
+ intel_dsc_enable(encoder, crtc_state);
}
static void intel_ddi_pre_enable_hdmi(struct intel_encoder *encoder,
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 477e53c37353..d3aa77f4d606 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5417,6 +5417,7 @@ static void intel_encoders_pre_enable(struct drm_crtc
*crtc,
if (encoder->pre_enable)
encoder->pre_enable(encoder, crtc_state, conn_state);
+
}
}
diff --git a/drivers/gpu/drm/i915/intel_vdsc.c
b/drivers/gpu/drm/i915/intel_vdsc.c
index a76f78b9c0ee..0eaa69778160 100644
--- a/drivers/gpu/drm/i915/intel_vdsc.c
+++ b/drivers/gpu/drm/i915/intel_vdsc.c
@@ -580,3 +580,422 @@ int intel_dp_compute_dsc_params(struct intel_dp *intel_dp,
return 0;
}
+
+static void intel_configure_pps_for_dsc_encoder(struct intel_encoder *encoder,
+ const struct intel_crtc_state
*crtc_state)
+{
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
+ struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+ const struct drm_dsc_config *vdsc_cfg = &crtc_state->dp_dsc_cfg;
+ enum pipe pipe = crtc->pipe;
+ enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
+ u32 pps_val = 0;
+ u32 rc_buf_thresh_dword[4];
+ u32 rc_range_params_dword[8];
+ u8 num_vdsc_instances = (crtc_state->dsc_params.dsc_split) ? 2 : 1;
+ int i = 0;
+
+ /* Populate PICTURE_PARAMETER_SET_0 registers */
+ pps_val = DSC_VER_MAJ | vdsc_cfg->dsc_version_minor <<
+ DSC_VER_MIN_SHIFT |
+ vdsc_cfg->bits_per_component << DSC_BPC_SHIFT |
+ vdsc_cfg->line_buf_depth << DSC_LINE_BUF_DEPTH_SHIFT;
+ if (vdsc_cfg->block_pred_enable)
+ pps_val |= DSC_BLOCK_PREDICTION;
+ else
+ pps_val &= ~DSC_BLOCK_PREDICTION;
+ if (vdsc_cfg->convert_rgb)
+ pps_val |= DSC_COLOR_SPACE_CONVERSION;
+ else
+ pps_val &= ~DSC_COLOR_SPACE_CONVERSION;
+ if (vdsc_cfg->enable422)
+ pps_val |= DSC_422_ENABLE;
+ else
+ pps_val &= ~DSC_422_ENABLE;
+ if (vdsc_cfg->vbr_enable)
+ pps_val |= DSC_VBR_ENABLE;
+ else
+ pps_val &= ~DSC_VBR_ENABLE;
+
+ DRM_INFO("PPS0 = 0x%08x\n", pps_val);
+ if (cpu_transcoder == TRANSCODER_EDP) {
+ I915_WRITE(DSCA_PICTURE_PARAMETER_SET_0, pps_val);
+ /*
+* If 2
[PATCH v8 14/19] drm/i915/dp: Use the existing write_infoframe() for DSC PPS SDPs
Infoframes are used to send secondary data packets. This patch
adds support for DSC Picture parameter set secondary data packets
in the existing write_infoframe helpers.
v3:
* Unused variables cleanup (Ville)
v2:
* Rebase on drm-tip (Manasi)
Cc: Jani Nikula
Cc: Ville Syrjala
Cc: Anusha Srivatsa
Signed-off-by: Manasi Navare
Reviewed-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_hdmi.c | 21 +++--
2 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index c0e6e14fe9fa..49c3c24965eb 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4550,6 +4550,7 @@ enum {
* of the infoframe structure specified by CEA-861. */
#define VIDEO_DIP_DATA_SIZE 32
#define VIDEO_DIP_VSC_DATA_SIZE 36
+#define VIDEO_DIP_PPS_DATA_SIZE 132
#define VIDEO_DIP_CTL _MMIO(0x61170)
/* Pre HSW: */
#define VIDEO_DIP_ENABLE (1 << 31)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 0c587e4503e3..61867a6733a8 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -115,6 +115,8 @@ static u32 hsw_infoframe_enable(unsigned int type)
switch (type) {
case DP_SDP_VSC:
return VIDEO_DIP_ENABLE_VSC_HSW;
+ case DP_SDP_PPS:
+ return VDIP_ENABLE_PPS;
case HDMI_INFOFRAME_TYPE_AVI:
return VIDEO_DIP_ENABLE_AVI_HSW;
case HDMI_INFOFRAME_TYPE_SPD:
@@ -136,6 +138,8 @@ hsw_dip_data_reg(struct drm_i915_private *dev_priv,
switch (type) {
case DP_SDP_VSC:
return HSW_TVIDEO_DIP_VSC_DATA(cpu_transcoder, i);
+ case DP_SDP_PPS:
+ return ICL_VIDEO_DIP_PPS_DATA(cpu_transcoder, i);
case HDMI_INFOFRAME_TYPE_AVI:
return HSW_TVIDEO_DIP_AVI_DATA(cpu_transcoder, i);
case HDMI_INFOFRAME_TYPE_SPD:
@@ -148,6 +152,18 @@ hsw_dip_data_reg(struct drm_i915_private *dev_priv,
}
}
+static int hsw_dip_data_size(unsigned int type)
+{
+ switch (type) {
+ case DP_SDP_VSC:
+ return VIDEO_DIP_VSC_DATA_SIZE;
+ case DP_SDP_PPS:
+ return VIDEO_DIP_PPS_DATA_SIZE;
+ default:
+ return VIDEO_DIP_DATA_SIZE;
+ }
+}
+
static void g4x_write_infoframe(struct intel_encoder *encoder,
const struct intel_crtc_state *crtc_state,
unsigned int type,
@@ -382,11 +398,12 @@ static void hsw_write_infoframe(struct intel_encoder
*encoder,
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
i915_reg_t ctl_reg = HSW_TVIDEO_DIP_CTL(cpu_transcoder);
- int data_size = type == DP_SDP_VSC ?
- VIDEO_DIP_VSC_DATA_SIZE : VIDEO_DIP_DATA_SIZE;
+ int data_size;
int i;
u32 val = I915_READ(ctl_reg);
+ data_size = hsw_dip_data_size(type);
+
val &= ~hsw_infoframe_enable(type);
I915_WRITE(ctl_reg, val);
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v8 11/19] drm/i915/dp: Enable/Disable DSC in DP Sink
From: Gaurav K Singh
This patch enables decompression support in sink device
before link training and disables the same during the
DDI disabling.
v3 (From manasi):
* Pass bool state to enable/disable (Ville)
v2:(From Manasi)
* Change the enable/disable function to take crtc_state
instead of intel_dp as an argument (Manasi)
* Use the compression_enable flag as part of crtc_state (Manasi)
Cc: Jani Nikula
Cc: Ville Syrjala
Cc: Anusha Srivatsa
Cc: Gaurav K Singh
Signed-off-by: Gaurav K Singh
Signed-off-by: Manasi Navare
Reviewed-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/intel_ddi.c | 5 +
drivers/gpu/drm/i915/intel_dp.c | 16
drivers/gpu/drm/i915/intel_drv.h | 3 +++
3 files changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 3eea987e909b..af12c15ed94f 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2952,6 +2952,8 @@ static void intel_ddi_pre_enable_dp(struct intel_encoder
*encoder,
intel_ddi_init_dp_buf_reg(encoder);
if (!is_mst)
intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
+ intel_dp_sink_set_decompression_state(intel_dp, crtc_state,
+ true);
intel_dp_start_link_train(intel_dp);
if (port != PORT_A || INTEL_GEN(dev_priv) >= 9)
intel_dp_stop_link_train(intel_dp);
@@ -3291,6 +3293,9 @@ static void intel_disable_ddi_dp(struct intel_encoder
*encoder,
intel_edp_drrs_disable(intel_dp, old_crtc_state);
intel_psr_disable(intel_dp, old_crtc_state);
intel_edp_backlight_off(old_conn_state);
+ /* Disable the decompression in DP Sink */
+ intel_dp_sink_set_decompression_state(intel_dp, old_crtc_state,
+ false);
}
static void intel_disable_ddi_hdmi(struct intel_encoder *encoder,
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 3d401a4e93b8..f8bf942c8f71 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2972,6 +2972,22 @@ static bool downstream_hpd_needs_d0(struct intel_dp
*intel_dp)
intel_dp->downstream_ports[0] & DP_DS_PORT_HPD;
}
+void intel_dp_sink_set_decompression_state(struct intel_dp *intel_dp,
+ const struct intel_crtc_state
*crtc_state,
+ bool enable)
+{
+ int ret;
+
+ if (!crtc_state->dsc_params.compression_enable)
+ return;
+
+ ret = drm_dp_dpcd_writeb(&intel_dp->aux, DP_DSC_ENABLE,
+enable ? DP_DECOMPRESSION_EN : 0);
+ if (ret < 0)
+ DRM_DEBUG_KMS("Failed to %s sink decompression state\n",
+ enable ? "enable" : "disable");
+}
+
/* If the sink supports it, try to set the power state appropriately */
void intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode)
{
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 3b57146766bb..e537561b3d40 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1795,6 +1795,9 @@ void intel_dp_stop_link_train(struct intel_dp *intel_dp);
int intel_dp_retrain_link(struct intel_encoder *encoder,
struct drm_modeset_acquire_ctx *ctx);
void intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode);
+void intel_dp_sink_set_decompression_state(struct intel_dp *intel_dp,
+ const struct intel_crtc_state
*crtc_state,
+ bool enable);
void intel_dp_encoder_reset(struct drm_encoder *encoder);
void intel_dp_encoder_suspend(struct intel_encoder *intel_encoder);
void intel_dp_encoder_destroy(struct drm_encoder *encoder);
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v8 02/19] drm/dsc: Define VESA Display Stream Compression Capabilities
This defines all the DSC parameters as per the VESA DSC spec
that will be required for DSC encoder/decoder
v6: (From Manasi)
* Add a bit mask for RANGE_BPG_OFFSET for 6 bits(Manasi)
v5 (From Manasi)
* Add the RC constants as per the spec
v4 (From Manasi)
* Add the DSC_MUX_WORD_SIZE constants (Manasi)
v3 (From Manasi)
* Remove the duplicate define (Suggested By:Harry Wentland)
v2: Define this struct in DRM (From Manasi)
* Changed the data types to u8/u16 instead of unsigned longs (Manasi)
* Remove driver specific fields (Manasi)
* Move this struct definition to DRM (Manasi)
* Define DSC 1.2 parameters (Manasi)
* Use DSC_NUM_BUF_RANGES (Manasi)
* Call it drm_dsc_config (Manasi)
Cc: dri-devel@lists.freedesktop.org
Cc: Jani Nikula
Cc: Ville Syrjala
Cc: Anusha Srivatsa
Cc: Harry Wentland
Signed-off-by: Manasi Navare
Signed-off-by: Gaurav K Singh
Co-developed-by: Gaurav K Singh
Acked-by: Harry Wentland
Reviewed-by: Anusha Srivatsa
---
include/drm/drm_dsc.h | 115 +-
1 file changed, 114 insertions(+), 1 deletion(-)
diff --git a/include/drm/drm_dsc.h b/include/drm/drm_dsc.h
index 78db4f61d01c..3292dfed9d0a 100644
--- a/include/drm/drm_dsc.h
+++ b/include/drm/drm_dsc.h
@@ -11,7 +11,120 @@
#include
/* VESA Display Stream Compression DSC 1.2 constants */
-#define DSC_NUM_BUF_RANGES 15
+#define DSC_NUM_BUF_RANGES 15
+#define DSC_MUX_WORD_SIZE_8_10_BPC 48
+#define DSC_MUX_WORD_SIZE_12_BPC 64
+#define DSC_RC_PIXELS_PER_GROUP3
+#define DSC_SCALE_DECREMENT_INTERVAL_MAX 4095
+#define DSC_RANGE_BPG_OFFSET_MASK 0x3f
+
+/* Configuration for a single Rate Control model range */
+struct drm_dsc_rc_range_parameters {
+ /* Min Quantization Parameters allowed for this range */
+ u8 range_min_qp;
+ /* Max Quantization Parameters allowed for this range */
+ u8 range_max_qp;
+ /* Bits/group offset to apply to target for this group */
+ u8 range_bpg_offset;
+};
+
+struct drm_dsc_config {
+ /* Bits / component for previous reconstructed line buffer */
+ u8 line_buf_depth;
+ /* Bits per component to code (must be 8, 10, or 12) */
+ u8 bits_per_component;
+ /*
+* Flag indicating to do RGB - YCoCg conversion
+* and back (should be 1 for RGB input)
+*/
+ bool convert_rgb;
+ u8 slice_count;
+ /* Slice Width */
+ u16 slice_width;
+ /* Slice Height */
+ u16 slice_height;
+ /*
+* 4:2:2 enable mode (from PPS, 4:2:2 conversion happens
+* outside of DSC encode/decode algorithm)
+*/
+ bool enable422;
+ /* Picture Width */
+ u16 pic_width;
+ /* Picture Height */
+ u16 pic_height;
+ /* Offset to bits/group used by RC to determine QP adjustment */
+ u8 rc_tgt_offset_high;
+ /* Offset to bits/group used by RC to determine QP adjustment */
+ u8 rc_tgt_offset_low;
+ /* Bits/pixel target << 4 (ie., 4 fractional bits) */
+ u16 bits_per_pixel;
+ /*
+* Factor to determine if an edge is present based
+* on the bits produced
+*/
+ u8 rc_edge_factor;
+ /* Slow down incrementing once the range reaches this value */
+ u8 rc_quant_incr_limit1;
+ /* Slow down incrementing once the range reaches this value */
+ u8 rc_quant_incr_limit0;
+ /* Number of pixels to delay the initial transmission */
+ u16 initial_xmit_delay;
+ /* Number of pixels to delay the VLD on the decoder,not including SSM */
+ u16 initial_dec_delay;
+ /* Block prediction enable */
+ bool block_pred_enable;
+ /* Bits/group offset to use for first line of the slice */
+ u8 first_line_bpg_offset;
+ /* Value to use for RC model offset at slice start */
+ u16 initial_offset;
+ /* Thresholds defining each of the buffer ranges */
+ u16 rc_buf_thresh[DSC_NUM_BUF_RANGES - 1];
+ /* Parameters for each of the RC ranges */
+ struct drm_dsc_rc_range_parameters rc_range_params[DSC_NUM_BUF_RANGES];
+ /* Total size of RC model */
+ u16 rc_model_size;
+ /* Minimum QP where flatness information is sent */
+ u8 flatness_min_qp;
+ /* Maximum QP where flatness information is sent */
+ u8 flatness_max_qp;
+ /* Initial value for scale factor */
+ u8 initial_scale_value;
+ /* Decrement scale factor every scale_decrement_interval groups */
+ u16 scale_decrement_interval;
+ /* Increment scale factor every scale_increment_interval groups */
+ u16 scale_increment_interval;
+ /* Non-first line BPG offset to use */
+ u16 nfl_bpg_offset;
+ /* BPG offset used to enforce slice bit */
+ u16 slice_bpg_offset;
+ /* Final RC linear transformation offset value */
+ u16 final_offset;
+ /* Enable on-off VBR (ie., d
[PATCH v8 08/19] drm/i915/dp: Do not enable PSR2 if DSC is enabled
If a eDP panel supports both PSR2 and VDSC, our HW cannot
support both at a time. Give priority to PSR2 if a requested
resolution can be supported without compression else enable
VDSC and keep PSR2 disabled.
v4:
Fix the unrealted stuff removed during rebase (Ville)
v3:
* Rebase
v2:
* Add warning for DSC and PSR2 enabled together (DK)
Cc: Rodrigo Vivi
Cc: Jani Nikula
Cc: Ville Syrjälä
Signed-off-by: Manasi Navare
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_psr.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index bc2d88313ed0..08967657b742 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -75,6 +75,10 @@ static bool intel_psr2_enabled(struct drm_i915_private
*dev_priv,
if (i915_modparams.enable_psr == -1)
return false;
+ /* Cannot enable DSC and PSR2 simultaneously */
+ WARN_ON(crtc_state->dsc_params.compression_enable &&
+ crtc_state->has_psr2);
+
switch (dev_priv->psr.debug & I915_PSR_DEBUG_MODE_MASK) {
case I915_PSR_DEBUG_FORCE_PSR1:
return false;
@@ -463,6 +467,16 @@ static bool intel_psr2_config_valid(struct intel_dp
*intel_dp,
if (!dev_priv->psr.sink_psr2_support)
return false;
+ /*
+* DSC and PSR2 cannot be enabled simultaneously. If a requested
+* resolution requires DSC to be enabled, priority is given to DSC
+* over PSR2.
+*/
+ if (crtc_state->dsc_params.compression_enable) {
+ DRM_DEBUG_KMS("PSR2 cannot be enabled since DSC is enabled\n");
+ return false;
+ }
+
if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv)) {
psr_max_h = 4096;
psr_max_v = 2304;
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v8 12/19] drm/i915/dsc: Add a power domain for VDSC on eDP/MIPI DSI
On Icelake, a separate power well PG2 is created for
VDSC engine used for eDP/MIPI DSI. This patch adds a new
display power domain for Power well 2.
v3:
* Call it POWER_DOMAIN_TRANSCODER_EDP_VDSC (Ville)
* Move it around TRANSCODER power domain defs (Ville)
v2:
* Fix the power well mismatch CI error (Ville)
* Rename as VDSC_PIPE_A (Imre)
* Fix a whitespace (Anusha)
* Fix Comments (Imre)
Cc: Ville Syrjala
Cc: Rodrigo Vivi
Cc: Imre Deak
Signed-off-by: Manasi Navare
Reviewed-by: Ville Syrjala
---
drivers/gpu/drm/i915/intel_display.h| 1 +
drivers/gpu/drm/i915/intel_runtime_pm.c | 4 +++-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.h
b/drivers/gpu/drm/i915/intel_display.h
index b0b23e1e9392..4e6b824ccc8c 100644
--- a/drivers/gpu/drm/i915/intel_display.h
+++ b/drivers/gpu/drm/i915/intel_display.h
@@ -226,6 +226,7 @@ enum intel_display_power_domain {
POWER_DOMAIN_TRANSCODER_B,
POWER_DOMAIN_TRANSCODER_C,
POWER_DOMAIN_TRANSCODER_EDP,
+ POWER_DOMAIN_TRANSCODER_EDP_VDSC,
POWER_DOMAIN_TRANSCODER_DSI_A,
POWER_DOMAIN_TRANSCODER_DSI_C,
POWER_DOMAIN_PORT_DDI_A_LANES,
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 6c453366cd24..acbe52adbf16 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -76,6 +76,8 @@ intel_display_power_domain_str(enum
intel_display_power_domain domain)
return "TRANSCODER_C";
case POWER_DOMAIN_TRANSCODER_EDP:
return "TRANSCODER_EDP";
+ case POWER_DOMAIN_TRANSCODER_EDP_VDSC:
+ return "TRANSCODER_EDP_VDSC";
case POWER_DOMAIN_TRANSCODER_DSI_A:
return "TRANSCODER_DSI_A";
case POWER_DOMAIN_TRANSCODER_DSI_C:
@@ -2006,9 +2008,9 @@ void intel_display_power_put(struct drm_i915_private
*dev_priv,
*/
#define ICL_PW_2_POWER_DOMAINS ( \
ICL_PW_3_POWER_DOMAINS |\
+ BIT_ULL(POWER_DOMAIN_TRANSCODER_EDP_VDSC) | \
BIT_ULL(POWER_DOMAIN_INIT))
/*
-* - eDP/DSI VDSC
* - KVMR (HW control)
*/
#define ICL_DISPLAY_DC_OFF_POWER_DOMAINS ( \
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v8 06/19] drm/i915/dp: Add DSC params and DSC config to intel_crtc_state
Basic DSC parameters and DSC configuration data needs to be computed
for each of the requested mode during atomic check. This is
required since for certain modes, valid DSC parameters and config
data might not be computed in which case compression cannot be
enabled for that mode.
For that reason we need to add these params and config structure
to the intel_crtc_state so that if valid this state information
can directly be used while enabling DSC in atomic commit.
v2:
* Rebase on drm-tip (Manasi)
Cc: Gaurav K Singh
Cc: Jani Nikula
Cc: Ville Syrjala
Cc: Anusha Srivatsa
Signed-off-by: Manasi Navare
Reviewed-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_drv.h | 9 +
2 files changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6157f8128cc5..d7797a41c648 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -53,6 +53,7 @@
#include
#include
#include
+#include
#include "i915_params.h"
#include "i915_reg.h"
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 191c26e17f2d..491872353cf0 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -936,6 +936,15 @@ struct intel_crtc_state {
/* Output down scaling is done in LSPCON device */
bool lspcon_downsampling;
+
+ /* Display Stream compression state */
+ struct {
+ bool compression_enable;
+ bool dsc_split;
+ u16 compressed_bpp;
+ u8 slice_count;
+ } dsc_params;
+ struct drm_dsc_config dp_dsc_cfg;
};
struct intel_crtc {
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v8 03/19] drm/dsc: Define Rate Control values that do not change over configurations
From: "Srivatsa, Anusha"
DSC has some Rate Control values that remain constant
across all configurations. These are as per the DSC
standard.
v3:
* Define them in drm_dsc.h as they are
DSC constants (Manasi)
v2:
* Add DP_DSC_ prefix (Jani Nikula)
Cc: dri-devel@lists.freedesktop.org
Cc: Manasi Navare
Cc: Jani Nikula
Cc: Ville Syrjala
Cc: Gaurav K Singh
Cc: Harry Wentland
Signed-off-by: Anusha Srivatsa
Reviewed-by: Manasi Navare
---
include/drm/drm_dsc.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/include/drm/drm_dsc.h b/include/drm/drm_dsc.h
index 3292dfed9d0a..b88e31bd9da7 100644
--- a/include/drm/drm_dsc.h
+++ b/include/drm/drm_dsc.h
@@ -18,6 +18,12 @@
#define DSC_SCALE_DECREMENT_INTERVAL_MAX 4095
#define DSC_RANGE_BPG_OFFSET_MASK 0x3f
+/* DSC Rate Control Constants */
+#define DSC_RC_MODEL_SIZE_CONST8192
+#define DSC_RC_EDGE_FACTOR_CONST 6
+#define DSC_RC_TGT_OFFSET_HI_CONST 3
+#define DSC_RC_TGT_OFFSET_LO_CONST 3
+
/* Configuration for a single Rate Control model range */
struct drm_dsc_rc_range_parameters {
/* Min Quantization Parameters allowed for this range */
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v8 05/19] drm/dsc: Define the DSC 1.1 and 1.2 Line Buffer depth constants
DSC specification defines linebuf_depth which contains the
line buffer bit depth used to generate the bitstream.
These values are defined as per Table 4.1 in DSC 1.2 spec
v2 (From Manasi):
* Rename as MAX_LINEBUF_DEPTH for DSC 1.1 and DSC 1.2
Cc: dri-devel@lists.freedesktop.org
Cc: Jani Nikula
Cc: Ville Syrjälä
Signed-off-by: Gaurav K Singh
Signed-off-by: Manasi Navare
Reviewed-by: Anusha Srivatsa
---
include/drm/drm_dsc.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/drm/drm_dsc.h b/include/drm/drm_dsc.h
index 52e57ceaff80..d03f1b83421a 100644
--- a/include/drm/drm_dsc.h
+++ b/include/drm/drm_dsc.h
@@ -40,6 +40,9 @@
#define DSC_PPS_RC_RANGE_MINQP_SHIFT 11
#define DSC_PPS_RC_RANGE_MAXQP_SHIFT 6
#define DSC_PPS_NATIVE_420_SHIFT 1
+#define DSC_1_2_MAX_LINEBUF_DEPTH_BITS 16
+#define DSC_1_2_MAX_LINEBUF_DEPTH_VAL 0
+#define DSC_1_1_MAX_LINEBUF_DEPTH_BITS 13
/* Configuration for a single Rate Control model range */
struct drm_dsc_rc_range_parameters {
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v8 00/19] DSC enabling remaining patches respin
This patch series addresses following comments from the previous series: https://patchwork.freedesktop.org/series/51916/ - no FEC so should reject DSC on external DP -> Added this to intel_dp_source_supports_dsc - get_power_domains() thing wasn't right -> Fixed the logic -The potentially user triggerable DRM_ERROR()s have to be removed or explained why they can't happen (in which case a WARN() would probably be a more clear hint to the reader). -> Changed DRM_ERROR to DRM_DEBUG_KMS The intel_dsc_enable() call I definitely would like see moved into the encoder->per_enable(). No one will think to look for it in the current location. -> Moved this to intel_ddi_pre_enable_dp The i915_modparams.enable_psr change seemed unrelated, but no idea if it's intentional or not. -> Removed unintentional changes And finally there were various style nits that are optional. But I would recomment doing them since it's trivial stuff and avoids further churn in the code later. -> Fixed the nits Gaurav K Singh (3): drm/i915/dsc: Define & Compute VESA DSC params drm/i915/dsc: Compute Rate Control parameters for DSC drm/i915/dp: Enable/Disable DSC in DP Sink Manasi Navare (15): drm/dsc: Define Display Stream Compression PPS infoframe drm/dsc: Define VESA Display Stream Compression Capabilities drm/dsc: Add helpers for DSC picture parameter set infoframes drm/dsc: Define the DSC 1.1 and 1.2 Line Buffer depth constants drm/i915/dp: Add DSC params and DSC config to intel_crtc_state drm/i915/dp: Compute DSC pipe config in atomic check drm/i915/dp: Do not enable PSR2 if DSC is enabled drm/i915/dsc: Add a power domain for VDSC on eDP/MIPI DSI drm/i915/dp: Configure i915 Picture parameter Set registers during DSC enabling drm/i915/dp: Use the existing write_infoframe() for DSC PPS SDPs drm/i915/dp: Populate DSC PPS SDP and send PPS infoframes drm/i915/dp: Configure Display stream splitter registers during DSC enable drm/i915/dp: Disable DSC in source by disabling DSS CTL bits drm/i915/dsc: Enable and disable appropriate power wells for VDSC drm/i915/dsc: Add Per connector debugfs node for DSC support/enable Srivatsa, Anusha (1): drm/dsc: Define Rate Control values that do not change over configurations Documentation/gpu/drm-kms-helpers.rst | 12 + drivers/gpu/drm/Makefile|2 +- drivers/gpu/drm/drm_dsc.c | 228 + drivers/gpu/drm/i915/Makefile |3 +- drivers/gpu/drm/i915/i915_debugfs.c | 71 +- drivers/gpu/drm/i915/i915_drv.h |4 + drivers/gpu/drm/i915/i915_reg.h |1 + drivers/gpu/drm/i915/intel_ddi.c| 17 + drivers/gpu/drm/i915/intel_display.c| 23 +- drivers/gpu/drm/i915/intel_display.h|4 +- drivers/gpu/drm/i915/intel_dp.c | 191 +++- drivers/gpu/drm/i915/intel_dp_mst.c |2 +- drivers/gpu/drm/i915/intel_drv.h| 21 + drivers/gpu/drm/i915/intel_hdmi.c | 21 +- drivers/gpu/drm/i915/intel_psr.c| 14 + drivers/gpu/drm/i915/intel_runtime_pm.c |4 +- drivers/gpu/drm/i915/intel_vdsc.c | 1100 +++ include/drm/drm_dp_helper.h |3 + include/drm/drm_dsc.h | 485 ++ 19 files changed, 2174 insertions(+), 32 deletions(-) create mode 100644 drivers/gpu/drm/drm_dsc.c create mode 100644 drivers/gpu/drm/i915/intel_vdsc.c create mode 100644 include/drm/drm_dsc.h -- 2.18.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v8 04/19] drm/dsc: Add helpers for DSC picture parameter set infoframes
According to Display Stream compression spec 1.2, the picture
parameter set metadata is sent from source to sink device
using the DP Secondary data packet. An infoframe is formed
for the PPS SDP header and PPS SDP payload bytes.
This patch adds helpers to fill the PPS SDP header
and PPS SDP payload according to the DSC 1.2 specification.
v7:
* Use BUILD_BUG_ON() to protect changing struct size (Ville)
* Remove typecaseting (Ville)
* Include byteorder.h in drm_dsc.c (Ville)
v6:
* Use proper sequence points for breaking down the
assignments (Chris Wilson)
* Use SPDX identifier
v5:
Do not use bitfields for DRM structs (Jani N)
v4:
* Use DSC constants for params that dont change across
configurations
v3:
* Add reference to added kernel-docs in
Documentation/gpu/drm-kms-helpers.rst (Daniel Vetter)
v2:
* Add EXPORT_SYMBOL for the drm functions (Manasi)
Cc: dri-devel@lists.freedesktop.org
Cc: Jani Nikula
Cc: Ville Syrjala
Cc: Anusha Srivatsa
Cc: Harry Wentland
Signed-off-by: Manasi Navare
Acked-by: Harry Wentland
---
Documentation/gpu/drm-kms-helpers.rst | 12 ++
drivers/gpu/drm/Makefile | 2 +-
drivers/gpu/drm/drm_dsc.c | 228 ++
include/drm/drm_dsc.h | 21 +++
4 files changed, 262 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/drm_dsc.c
diff --git a/Documentation/gpu/drm-kms-helpers.rst
b/Documentation/gpu/drm-kms-helpers.rst
index 4b4dc236ef6f..b422eb8edf16 100644
--- a/Documentation/gpu/drm-kms-helpers.rst
+++ b/Documentation/gpu/drm-kms-helpers.rst
@@ -232,6 +232,18 @@ MIPI DSI Helper Functions Reference
.. kernel-doc:: drivers/gpu/drm/drm_mipi_dsi.c
:export:
+Display Stream Compression Helper Functions Reference
+=
+
+.. kernel-doc:: drivers/gpu/drm/drm_dsc.c
+ :doc: dsc helpers
+
+.. kernel-doc:: include/drm/drm_dsc.h
+ :internal:
+
+.. kernel-doc:: drivers/gpu/drm/drm_dsc.c
+ :export:
+
Output Probing Helper Functions Reference
=
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 576ba985e138..3a3e6fb6d476 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -32,7 +32,7 @@ drm-$(CONFIG_AGP) += drm_agpsupport.o
drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
drm-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
-drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \
+drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_dsc.o
drm_probe_helper.o \
drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o \
drm_kms_helper_common.o drm_dp_dual_mode_helper.o \
drm_simple_kms_helper.o drm_modeset_helper.o \
diff --git a/drivers/gpu/drm/drm_dsc.c b/drivers/gpu/drm/drm_dsc.c
new file mode 100644
index ..3a4942c1ae3b
--- /dev/null
+++ b/drivers/gpu/drm/drm_dsc.c
@@ -0,0 +1,228 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2018 Intel Corp
+ *
+ * Author:
+ * Manasi Navare
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/**
+ * DOC: dsc helpers
+ *
+ * These functions contain some common logic and helpers to deal with VESA
+ * Display Stream Compression standard required for DSC on Display Port/eDP or
+ * MIPI display interfaces.
+ */
+
+/**
+ * drm_dsc_dp_pps_header_init() - Initializes the PPS Header
+ * for DisplayPort as per the DP 1.4 spec.
+ * @pps_sdp: Secondary data packet for DSC Picture Parameter Set
+ */
+void drm_dsc_dp_pps_header_init(struct drm_dsc_pps_infoframe *pps_sdp)
+{
+ memset(&pps_sdp->pps_header, 0, sizeof(pps_sdp->pps_header));
+
+ pps_sdp->pps_header.HB1 = DP_SDP_PPS;
+ pps_sdp->pps_header.HB2 = DP_SDP_PPS_HEADER_PAYLOAD_BYTES_MINUS_1;
+}
+EXPORT_SYMBOL(drm_dsc_dp_pps_header_init);
+
+/**
+ * drm_dsc_pps_infoframe_pack() - Populates the DSC PPS infoframe
+ * using the DSC configuration parameters in the order expected
+ * by the DSC Display Sink device. For the DSC, the sink device
+ * expects the PPS payload in the big endian format for the fields
+ * that span more than 1 byte.
+ *
+ * @pps_sdp:
+ * Secondary data packet for DSC Picture Parameter Set
+ * @dsc_cfg:
+ * DSC Configuration data filled by driver
+ */
+void drm_dsc_pps_infoframe_pack(struct drm_dsc_pps_infoframe *pps_sdp,
+ const struct drm_dsc_config *dsc_cfg)
+{
+ int i;
+
+ /*Protect against someone accidently changing struct size */
+ BUILD_BUG_ON(sizeof(pps_sdp->pps_payload) !=
+DP_SDP_PPS_HEADER_PAYLOAD_BYTES_MINUS_1 + 1);
+
+ memset(&pps_sdp->pps_payload, 0, sizeof(pps_sdp->pps_payload));
+
+ /* PPS 0 */
+ pps_sdp->pps_payload.dsc_version =
+ dsc_cfg->dsc_version_minor |
+ dsc_cfg->dsc_version_major << DSC_PPS_VERSION_MAJOR_SHIFT;
+
+ /* PPS 1, 2 is 0 */
+
+ /* PPS 3 */
+ pps_sdp->
Re: [PATCH v7 13/19] drm/i915/dp: Configure i915 Picture parameter Set registers during DSC enabling
On Fri, Nov 02, 2018 at 07:52:53PM +0200, Ville Syrjälä wrote:
> On Thu, Nov 01, 2018 at 11:46:53PM -0700, Manasi Navare wrote:
> > After encoder->pre_enable() hook, after link training sequence is
> > completed, PPS registers for DSC encoder are configured using the
> > DSC state parameters in intel_crtc_state as part of DSC enabling
> > routine in the source. DSC enabling routine is called after
> > encoder->pre_enable() before enbaling the pipe and after
> > compression is enabled on the sink.
> >
> > v5:
> > * make crtc_state const (Ville)
> > v4:
> > * Use cpu_transcoder instead of encoder->type for using EDP transcoder
> > DSC registers(Ville)
> > * Keep all PSS regs together (Anusha)
> >
> > v3:
> > * Configure Pic_width/2 for each VDSC engine when two VDSC engines per pipe
> > are used (Manasi)
> > * Add DSC slice_row_per_frame in PPS16 (Manasi)
> >
> > v2:
> > * Enable PG2 power well for VDSC on eDP
> >
> > Cc: Jani Nikula
> > Cc: Ville Syrjala
> > Cc: Anusha Srivatsa
> > Signed-off-by: Manasi Navare
> > Reviewed-by: Anusha Srivatsa
> > ---
> > drivers/gpu/drm/i915/i915_drv.h | 2 +
> > drivers/gpu/drm/i915/intel_display.c | 6 +
> > drivers/gpu/drm/i915/intel_vdsc.c| 419 +++
> > 3 files changed, 427 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index d7797a41c648..f347d0d7b9eb 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -3485,6 +3485,8 @@ extern void intel_rps_mark_interactive(struct
> > drm_i915_private *i915,
> >bool interactive);
> > extern bool intel_set_memory_cxsr(struct drm_i915_private *dev_priv,
> > bool enable);
> > +extern void intel_dsc_enable(struct intel_encoder *encoder,
> > +const struct intel_crtc_state *crtc_state);
> >
> > int i915_reg_read_ioctl(struct drm_device *dev, void *data,
> > struct drm_file *file);
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 477e53c37353..2e96e2004831 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -5417,6 +5417,12 @@ static void intel_encoders_pre_enable(struct
> > drm_crtc *crtc,
> >
> > if (encoder->pre_enable)
> > encoder->pre_enable(encoder, crtc_state, conn_state);
> > +
> > + /*
> > +* Enable and Configure Display Stream Compression in the source
> > +* if enabled in intel_crtc_state.
> > +*/
> > + intel_dsc_enable(encoder, crtc_state);
>
> Didn't I ask for this to be moved into the pre_enable hook?
> We definitely don't want it here as it would be a very suprising place
> for stuff like this.
I will move it to intel_ddi_pre_enable_dp() at the end of the function.
Manasi
>
> > }
> > }
> >
> > diff --git a/drivers/gpu/drm/i915/intel_vdsc.c
> > b/drivers/gpu/drm/i915/intel_vdsc.c
> > index b93cb32026fa..9f80a86f95df 100644
> > --- a/drivers/gpu/drm/i915/intel_vdsc.c
> > +++ b/drivers/gpu/drm/i915/intel_vdsc.c
> > @@ -580,3 +580,422 @@ int intel_dp_compute_dsc_params(struct intel_dp
> > *intel_dp,
> >
> > return 0;
> > }
> > +
> > +static void intel_configure_pps_for_dsc_encoder(struct intel_encoder
> > *encoder,
> > + const struct intel_crtc_state
> > *crtc_state)
> > +{
> > + struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
> > + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > + const struct drm_dsc_config *vdsc_cfg = &crtc_state->dp_dsc_cfg;
> > + enum pipe pipe = crtc->pipe;
> > + enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
> > + u32 pps_val = 0;
> > + u32 rc_buf_thresh_dword[4];
> > + u32 rc_range_params_dword[8];
> > + u8 num_vdsc_instances = (crtc_state->dsc_params.dsc_split) ? 2 : 1;
> > + int i = 0;
> > +
> > + /* Populate PICTURE_PARAMETER_SET_0 registers */
> > + pps_val = DSC_VER_MAJ | vdsc_cfg->dsc_version_minor <<
> > + DSC_VER_MIN_SHIFT |
> > + vdsc_cfg->bits_per_component << DSC_BPC_SHIFT |
> > + vdsc_cfg->line_buf_depth << DSC_LINE_BUF_DEPTH_SHIFT;
> > + if (vdsc_cfg->block_pred_enable)
> > + pps_val |= DSC_BLOCK_PREDICTION;
> > + else
> > + pps_val &= ~DSC_BLOCK_PREDICTION;
> > + if (vdsc_cfg->convert_rgb)
> > + pps_val |= DSC_COLOR_SPACE_CONVERSION;
> > + else
> > + pps_val &= ~DSC_COLOR_SPACE_CONVERSION;
> > + if (vdsc_cfg->enable422)
> > + pps_val |= DSC_422_ENABLE;
> > + else
> > + pps_val &= ~DSC_422_ENABLE;
> > + if (vdsc_cfg->vbr_enable)
> > + pps_val |= DSC_VBR_ENABLE;
> > + else
> > + pps_val &= ~DSC_VBR_ENABLE;
> > +
> > + DRM_INFO("PPS0 = 0x%08x\n", pps_val);
> > +
Re: [PATCH] drm/lease: drop EXPORT_SYMBOL
On Fri, Nov 02, 2018 at 08:05:07AM -0700, Keith Packard wrote: > Daniel Vetter writes: > > > Leases are entirely implemented within drm.ko, no need to even tempt > > drivers into doing nasty things. And if there's really a need, we can > > always re-export these again. > > > > Cc: Keith Packard > > Cc: Dave Airlie > > Signed-off-by: Daniel Vetter > > Acked-by: Keith Packard Applied, thanks for taking a look. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/3] drm/i915: Fix NULL deref when re-enabling HPD IRQs on systems with MST
On Fri, Oct 26, 2018 at 06:49:08PM -0400, Lyude Paul wrote:
> Turns out that if you trigger an HPD storm on a system that has an MST
> topology connected to it, you'll end up causing the kernel to eventually
> hit a NULL deref:
>
> [ 332.339041] BUG: unable to handle kernel NULL pointer dereference at
> 00ec
> [ 332.340906] PGD 0 P4D 0
> [ 332.342750] Oops: [#1] SMP PTI
> [ 332.344579] CPU: 2 PID: 25 Comm: kworker/2:0 Kdump: loaded Tainted: G
> O 4.18.0-rc3short-hpd-storm+ #2
> [ 332.346453] Hardware name: LENOVO 20BWS1KY00/20BWS1KY00, BIOS JBET71WW
> (1.35 ) 09/14/2018
> [ 332.348361] Workqueue: events intel_hpd_irq_storm_reenable_work [i915]
> [ 332.350301] RIP: 0010:intel_hpd_irq_storm_reenable_work.cold.3+0x2f/0x86
> [i915]
> [ 332.352213] Code: 00 00 ba e8 00 00 00 48 c7 c6 c0 aa 5f a0 48 c7 c7 d0 73
> 62 a0 4c 89 c1 4c 89 04 24 e8 7f f5 af e0 4c 8b 04 24 44 89 f8 29 e8 <41> 39
> 80 ec 00 00 00 0f 85 43 13 fc ff 41 0f b6 86 b8 04 00 00 41
> [ 332.354286] RSP: 0018:c9147e48 EFLAGS: 00010006
> [ 332.356344] RAX: 0005 RBX: 8802c226c9d4 RCX:
> 0006
> [ 332.358404] RDX: RSI: 0082 RDI:
> 88032dc95570
> [ 332.360466] RBP: 0005 R08: R09:
> 88031b3dc840
> [ 332.362528] R10: R11: 00031a069602 R12:
> 8802c226ca20
> [ 332.364575] R13: 8802c2268000 R14: 880310661000 R15:
> 000a
> [ 332.366615] FS: () GS:88032dc8()
> knlGS:
> [ 332.368658] CS: 0010 DS: ES: CR0: 80050033
> [ 332.370690] CR2: 00ec CR3: 0200a003 CR4:
> 003606e0
> [ 332.372724] DR0: DR1: DR2:
>
> [ 332.374773] DR3: DR6: fffe0ff0 DR7:
> 0400
> [ 332.376798] Call Trace:
> [ 332.378809] process_one_work+0x1a1/0x350
> [ 332.380806] worker_thread+0x30/0x380
> [ 332.382777] ? wq_update_unbound_numa+0x10/0x10
> [ 332.384772] kthread+0x112/0x130
> [ 332.386740] ? kthread_create_worker_on_cpu+0x70/0x70
> [ 332.388706] ret_from_fork+0x35/0x40
> [ 332.390651] Modules linked in: i915(O) vfat fat joydev btusb btrtl btbcm
> btintel bluetooth ecdh_generic iTCO_wdt wmi_bmof i2c_algo_bit drm_kms_helper
> intel_rapl syscopyarea sysfillrect x86_pkg_temp_thermal sysimgblt coretemp
> fb_sys_fops crc32_pclmul drm psmouse pcspkr mei_me mei i2c_i801 lpc_ich
> mfd_core i2c_core tpm_tis tpm_tis_core thinkpad_acpi wmi tpm rfkill video
> crc32c_intel serio_raw ehci_pci xhci_pci ehci_hcd xhci_hcd [last unloaded:
> i915]
> [ 332.394963] CR2: 00ec
>
> This appears to be due to the fact that with an MST topology, not all
> intel_connector structs will have ->encoder set. So, fix this by
> skipping connectors without encoders in
> intel_hpd_irq_storm_reenable_work().
>
> For those wondering, this bug was found on accident while simulating HPD
> storms using a Chamelium connected to a ThinkPad T450s (Broadwell).
>
> Changes since v1:
> - Check intel_connector->mst_port instead of intel_connector->encoder
>
> Signed-off-by: Lyude Paul
> Cc: Ville Syrjälä
1 and 2 are
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_hotplug.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_hotplug.c
> b/drivers/gpu/drm/i915/intel_hotplug.c
> index 648a13c6043c..8326900a311e 100644
> --- a/drivers/gpu/drm/i915/intel_hotplug.c
> +++ b/drivers/gpu/drm/i915/intel_hotplug.c
> @@ -228,7 +228,9 @@ static void intel_hpd_irq_storm_reenable_work(struct
> work_struct *work)
> drm_for_each_connector_iter(connector, &conn_iter) {
> struct intel_connector *intel_connector =
> to_intel_connector(connector);
>
> - if (intel_connector->encoder->hpd_pin == pin) {
> + /* Don't check MST ports, they don't have pins */
> + if (!intel_connector->mst_port &&
> + intel_connector->encoder->hpd_pin == pin) {
> if (connector->polled !=
> intel_connector->polled)
> DRM_DEBUG_DRIVER("Reenabling HPD on
> connector %s\n",
>connector->name);
> --
> 2.17.2
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] arm64: dts: sdm845: Add display nodes to MTP dts
Hi,
On Fri, Nov 2, 2018 at 12:42 PM Jeykumar Sankaran wrote:
>
> Add mdss, dsi, dsi_phy, dsi pinctrl and truly nt35597 panel nodes to
> sdm845 MTP board dtsi.
>
> Signed-off-by: Jeykumar Sankaran
> ---
> arch/arm64/boot/dts/qcom/sdm845-mtp.dts | 124
>
> 1 file changed, 124 insertions(+)
A few nits below about trying to keep the sort ordering right in this
file. I'm not an expert on device tree properties for display, but
other than these nits things here look good to me.
NOTE also that I'd probably put all 3 of your recent patches in a
3-part series since they all depend on each other, don't they? AKA
I'd to see next time:
[PATCH v4 1/3] arm64: dts: qcom: sdm845: Add dpu to sdm845 dts file
[PATCH v4 2/3] arm64: dts: sdm845: Add dsi pinctrl nodes
[PATCH v4 3/3] arm64: dts: sdm845: Add display nodes to MTP dts
...you can call them all v4 just to make it easier to track...
> diff --git a/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
> b/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
> index 6d651f3..6e98ae8 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
> +++ b/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
> @@ -8,6 +8,7 @@
> /dts-v1/;
>
> #include "sdm845.dtsi"
> +#include
Generally includes should have < includes above " includes.
...also: please rebase atop Andy's tree. Then you'll have the line:
#include
..."gpio" is alphabetically before "regulator" so your include should
be _above_ that one.
>
> / {
> model = "Qualcomm Technologies, Inc. SDM845 MTP";
> @@ -22,6 +23,113 @@
> };
> };
>
> +&dsi0 {
> + status = "okay";
> + qcom,dual-dsi-mode;
> + qcom,master-dsi;
> + qcom,sync-dual-dsi;
> +
> + vdda-supply = <&vdda_mipi_dsi0_1p2>;
> +
> + panel@0 {
> + compatible = "truly,nt35597-2K-display";
> + reg = <0>;
> +
> + vdda-supply = <&vreg_l14a_1p88>;
> + vdispp-supply = <&lab_regulator>;
> + vdispn-supply = <&ibb_regulator>;
> +
> + pinctrl-names = "default", "suspend";
> + pinctrl-0 = <&dpu_dsi_active>;
> + pinctrl-1 = <&dpu_dsi_suspend>;
> +
> + reset-gpios = <&tlmm 6 GPIO_ACTIVE_HIGH>;
> + mode-gpios = <&tlmm 52 GPIO_ACTIVE_HIGH>;
> +
> + display-timings {
> + timing0: timing-0 {
> + /* originally
> +* 268316160 Mhz,
> +* but value below fits
> +* better w/ downstream
> +*/
> + clock-frequency = <268316138>;
> + hactive = <1440>;
> + vactive = <2560>;
> + hfront-porch = <200>;
> + hback-porch = <64>;
> + hsync-len = <32>;
> + vfront-porch = <8>;
> + vback-porch = <7>;
> + vsync-len = <1>;
> + };
> + };
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + port@0 {
> + reg = <0>;
> + panel0_in: endpoint {
> + remote-endpoint = <&dsi0_out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + panel1_in: endpoint {
> + remote-endpoint = <&dsi1_out>;
> + };
> + };
> + };
> + };
> +
> + ports {
> + port@1 {
> + endpoint {
> + remote-endpoint = <&panel0_in>;
> + data-lanes = <0 1 2 3>;
> + };
> + };
> + };
> +};
> +
> +&dsi0_phy {
> + status = "okay";
> + vdds-supply = <&vdda_mipi_dsi0_pll>;
> +};
> +
> +&dsi1 {
> + status = "okay";
> +
> + qcom,dual-dsi-mode;
> + qcom,sync-dual-dsi;
> +
> + vdda-supply = <&vdda_mipi_dsi1_1p2>;
> +
> + ports {
> + port@1 {
> + endpoint {
> + remote-endpoint = <&panel1_in>;
> + data-lanes = <0 1 2 3>;
> + };
> + };
> + };
> +};
> +
> +&dsi1_phy {
> + status = "okay";
> + vdds-supply = <&vdda_mipi_dsi1_pll>;
> +};
> +
> +&mdss {
> + status = "okay";
> +};
> +
> +&mdss_mdp {
> + status = "okay";
> +};
Please keep these nodes sorted alphabetically even if it means you
don't keep all the d
Re: [PATCH v7 07/19] drm/i915/dp: Do not enable PSR2 if DSC is enabled
On Fri, Nov 02, 2018 at 07:51:18PM +0200, Ville Syrjälä wrote:
> On Thu, Nov 01, 2018 at 11:46:47PM -0700, Manasi Navare wrote:
> > If a eDP panel supports both PSR2 and VDSC, our HW cannot
> > support both at a time. Give priority to PSR2 if a requested
> > resolution can be supported without compression else enable
> > VDSC and keep PSR2 disabled.
> >
> > v3:
> > * Rebase
> > v2:
> > * Add warning for DSC and PSR2 enabled together (DK)
> >
> > Cc: Rodrigo Vivi
> > Cc: Jani Nikula
> > Cc: Ville Syrjälä
> > Signed-off-by: Manasi Navare
> > Reviewed-by: Rodrigo Vivi
> > ---
> > drivers/gpu/drm/i915/intel_psr.c | 16 +---
> > 1 file changed, 13 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > b/drivers/gpu/drm/i915/intel_psr.c
> > index bc2d88313ed0..8f063e1e2fb2 100644
> > --- a/drivers/gpu/drm/i915/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > @@ -71,9 +71,9 @@ static bool psr_global_enabled(u32 debug)
> > static bool intel_psr2_enabled(struct drm_i915_private *dev_priv,
> >const struct intel_crtc_state *crtc_state)
> > {
> > - /* Disable PSR2 by default for all platforms */
> > - if (i915_modparams.enable_psr == -1)
> > - return false;
>
> That seems unrelated to DSC?
Thats a good catch, i think thsi got removed due to a rebase by mistake.
I will add it back there.
Manasi
>
> > + /* Cannot enable DSC and PSR2 simultaneously */
> > + WARN_ON(crtc_state->dsc_params.compression_enable &&
> > + crtc_state->has_psr2);
> >
> > switch (dev_priv->psr.debug & I915_PSR_DEBUG_MODE_MASK) {
> > case I915_PSR_DEBUG_FORCE_PSR1:
> > @@ -463,6 +463,16 @@ static bool intel_psr2_config_valid(struct intel_dp
> > *intel_dp,
> > if (!dev_priv->psr.sink_psr2_support)
> > return false;
> >
> > + /*
> > +* DSC and PSR2 cannot be enabled simultaneously. If a requested
> > +* resolution requires DSC to be enabled, priority is given to DSC
> > +* over PSR2.
> > +*/
> > + if (crtc_state->dsc_params.compression_enable) {
> > + DRM_DEBUG_KMS("PSR2 cannot be enabled since DSC is enabled\n");
> > + return false;
> > + }
> > +
> > if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv)) {
> > psr_max_h = 4096;
> > psr_max_v = 2304;
> > --
> > 2.18.0
>
> --
> Ville Syrjälä
> Intel
> ___
> 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 v7 00/19] DSC enabling remaining patches
Thanks Ville for this detailed review. I will spin this now with the required fixes and send it over. Manasi On Fri, Nov 02, 2018 at 08:06:04PM +0200, Ville Syrjälä wrote: > On Thu, Nov 01, 2018 at 11:46:40PM -0700, Manasi Navare wrote: > > This patch series addresses review comments on previous DSC series: > > > > https://patchwork.freedesktop.org/series/47514/ > > > > Gaurav K Singh (3): > > drm/i915/dsc: Define & Compute VESA DSC params > > drm/i915/dsc: Compute Rate Control parameters for DSC > > drm/i915/dp: Enable/Disable DSC in DP Sink > > > > Manasi Navare (15): > > drm/dsc: Define Display Stream Compression PPS infoframe > > drm/dsc: Define VESA Display Stream Compression Capabilities > > drm/dsc: Add helpers for DSC picture parameter set infoframes > > drm/i915/dp: Add DSC params and DSC config to intel_crtc_state > > drm/i915/dp: Compute DSC pipe config in atomic check > > drm/i915/dp: Do not enable PSR2 if DSC is enabled > > drm/dsc: Define the DSC 1.1 and 1.2 Line Buffer depth constants > > drm/i915/dsc: Add a power domain for VDSC on eDP/MIPI DSI > > drm/i915/dp: Configure i915 Picture parameter Set registers during DSC > > enabling > > drm/i915/dp: Use the existing write_infoframe() for DSC PPS SDPs > > drm/i915/dp: Populate DSC PPS SDP and send PPS infoframes > > drm/i915/dp: Configure Display stream splitter registers during DSC > > enable > > drm/i915/dp: Disable DSC in source by disabling DSS CTL bits > > drm/i915/dsc: Enable and disable appropriate power wells for VDSC > > drm/i915/dsc: Add Per connector debugfs node for DSC support/enable > > > > Srivatsa, Anusha (1): > > drm/dsc: Define Rate Control values that do not change over > > configurations > > I think we have these real functional issues left: > - no FEC so should reject DSC on external DP > - get_power_domains() thing wasn't right > > The potentially user triggerable DRM_ERROR()s have to be > removed or explained why they can't happen (in which case > a WARN() would probably be a more clear hint to the reader). > > The intel_dsc_enable() call I definitely would like see > moved into the encoder->per_enable(). No one will think to > look for it in the current location. > > The i915_modparams.enable_psr change seemed unrelated, but > no idea if it's intentional or not. > > And finally there were various style nits that are optional. > But I would recomment doing them since it's trivial stuff and > avoids further churn in the code later. > > I think that's about it really. > > > > > Documentation/gpu/drm-kms-helpers.rst | 12 + > > drivers/gpu/drm/Makefile|2 +- > > drivers/gpu/drm/drm_dsc.c | 228 + > > drivers/gpu/drm/i915/Makefile |3 +- > > drivers/gpu/drm/i915/i915_debugfs.c | 71 +- > > drivers/gpu/drm/i915/i915_drv.h |4 + > > drivers/gpu/drm/i915/i915_reg.h |1 + > > drivers/gpu/drm/i915/intel_ddi.c|8 +- > > drivers/gpu/drm/i915/intel_display.c| 28 +- > > drivers/gpu/drm/i915/intel_display.h|4 +- > > drivers/gpu/drm/i915/intel_dp.c | 196 +++- > > drivers/gpu/drm/i915/intel_dp_mst.c |2 +- > > drivers/gpu/drm/i915/intel_drv.h| 21 + > > drivers/gpu/drm/i915/intel_hdmi.c | 21 +- > > drivers/gpu/drm/i915/intel_psr.c| 16 +- > > drivers/gpu/drm/i915/intel_runtime_pm.c |4 +- > > drivers/gpu/drm/i915/intel_vdsc.c | 1100 +++ > > include/drm/drm_dp_helper.h |3 + > > include/drm/drm_dsc.h | 485 ++ > > 19 files changed, 2169 insertions(+), 40 deletions(-) > > create mode 100644 drivers/gpu/drm/drm_dsc.c > > create mode 100644 drivers/gpu/drm/i915/intel_vdsc.c > > create mode 100644 include/drm/drm_dsc.h > > > > -- > > 2.18.0 > > > > ___ > > dri-devel mailing list > > dri-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > -- > Ville Syrjälä > Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] arm64: dts: sdm845: Add dsi pinctrl nodes
Add dsi active/suspend pinctrl nodes to sdm845 SoC dts.
Signed-off-by: Jeykumar Sankaran
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index dd612ac..e6a64f6 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -714,6 +714,20 @@
interrupt-controller;
#interrupt-cells = <2>;
+ dpu_dsi_active: dpu-dsi-active {
+ pinmux {
+ pins = "gpio6", "gpio52";
+ function = "gpio";
+ };
+ };
+
+ dpu_dsi_suspend: dpu-dsi-suspend {
+ pinmux {
+ pins = "gpio6", "gpio52";
+ function = "gpio";
+ };
+ };
+
qup_i2c0_default: qup-i2c0-default {
pinmux {
pins = "gpio0", "gpio1";
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] arm64: dts: sdm845: Add display nodes to MTP dts
Add mdss, dsi, dsi_phy, dsi pinctrl and truly nt35597 panel nodes to
sdm845 MTP board dtsi.
Signed-off-by: Jeykumar Sankaran
---
arch/arm64/boot/dts/qcom/sdm845-mtp.dts | 124
1 file changed, 124 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
b/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
index 6d651f3..6e98ae8 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
+++ b/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
@@ -8,6 +8,7 @@
/dts-v1/;
#include "sdm845.dtsi"
+#include
/ {
model = "Qualcomm Technologies, Inc. SDM845 MTP";
@@ -22,6 +23,113 @@
};
};
+&dsi0 {
+ status = "okay";
+ qcom,dual-dsi-mode;
+ qcom,master-dsi;
+ qcom,sync-dual-dsi;
+
+ vdda-supply = <&vdda_mipi_dsi0_1p2>;
+
+ panel@0 {
+ compatible = "truly,nt35597-2K-display";
+ reg = <0>;
+
+ vdda-supply = <&vreg_l14a_1p88>;
+ vdispp-supply = <&lab_regulator>;
+ vdispn-supply = <&ibb_regulator>;
+
+ pinctrl-names = "default", "suspend";
+ pinctrl-0 = <&dpu_dsi_active>;
+ pinctrl-1 = <&dpu_dsi_suspend>;
+
+ reset-gpios = <&tlmm 6 GPIO_ACTIVE_HIGH>;
+ mode-gpios = <&tlmm 52 GPIO_ACTIVE_HIGH>;
+
+ display-timings {
+ timing0: timing-0 {
+ /* originally
+* 268316160 Mhz,
+* but value below fits
+* better w/ downstream
+*/
+ clock-frequency = <268316138>;
+ hactive = <1440>;
+ vactive = <2560>;
+ hfront-porch = <200>;
+ hback-porch = <64>;
+ hsync-len = <32>;
+ vfront-porch = <8>;
+ vback-porch = <7>;
+ vsync-len = <1>;
+ };
+ };
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@0 {
+ reg = <0>;
+ panel0_in: endpoint {
+ remote-endpoint = <&dsi0_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ panel1_in: endpoint {
+ remote-endpoint = <&dsi1_out>;
+ };
+ };
+ };
+ };
+
+ ports {
+ port@1 {
+ endpoint {
+ remote-endpoint = <&panel0_in>;
+ data-lanes = <0 1 2 3>;
+ };
+ };
+ };
+};
+
+&dsi0_phy {
+ status = "okay";
+ vdds-supply = <&vdda_mipi_dsi0_pll>;
+};
+
+&dsi1 {
+ status = "okay";
+
+ qcom,dual-dsi-mode;
+ qcom,sync-dual-dsi;
+
+ vdda-supply = <&vdda_mipi_dsi1_1p2>;
+
+ ports {
+ port@1 {
+ endpoint {
+ remote-endpoint = <&panel1_in>;
+ data-lanes = <0 1 2 3>;
+ };
+ };
+ };
+};
+
+&dsi1_phy {
+ status = "okay";
+ vdds-supply = <&vdda_mipi_dsi1_pll>;
+};
+
+&mdss {
+ status = "okay";
+};
+
+&mdss_mdp {
+ status = "okay";
+};
+
&i2c10 {
status = "okay";
clock-frequency = <40>;
@@ -58,3 +166,19 @@
bias-pull-up;
};
};
+
+&dpu_dsi_active {
+ pinconf {
+ pins = "gpio6", "gpio52";
+ drive-strength = <8>;
+ bias-disable;
+ };
+};
+
+&dpu_dsi_suspend {
+ pinconf {
+ pins = "gpio6", "gpio52";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+};
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] amdgpu/test: Disable deadlock tests for all non gfx8/9 ASICs.
On Fri, Nov 2, 2018 at 3:36 PM Andrey Grodzovsky
wrote:
>
> Since only for those ASICs gpu reset is enabled by deafult.
> Also update disable message and fix identation .
>
> Signed-off-by: Andrey Grodzovsky
> ---
> tests/amdgpu/deadlock_tests.c | 12 +++-
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/tests/amdgpu/deadlock_tests.c b/tests/amdgpu/deadlock_tests.c
> index 04600a7..00a17ca 100644
> --- a/tests/amdgpu/deadlock_tests.c
> +++ b/tests/amdgpu/deadlock_tests.c
> @@ -119,11 +119,13 @@ CU_BOOL suite_deadlock_tests_enable(void)
> &minor_version, &device_handle))
> return CU_FALSE;
>
> - if (device_handle->info.family_id == AMDGPU_FAMILY_SI ||
> - device_handle->info.family_id == AMDGPU_FAMILY_CZ ||
> - device_handle->info.family_id == AMDGPU_FAMILY_RV ||
> - device_handle->info.family_id == AMDGPU_FAMILY_KV) {
> - printf("\n\nCurrently hangs the CP on this ASIC, deadlock
> suite disabled\n");
> + /*
> +* Only enable for ASICs supporting GPU reset and for which it's
> enabled
> +* by default (currently GFX8/9 dGPUS
Missing ) in your comment. With that fixed:
Reviewed-by: Alex Deucher
> +*/
> + if (device_handle->info.family_id != AMDGPU_FAMILY_VI &&
> + device_handle->info.family_id != AMDGPU_FAMILY_AI) {
> + printf("\n\nGPU reset is not enabled for the ASIC, deadlock
> suite disabled\n");
> enable = CU_FALSE;
> }
>
> --
> 2.7.4
>
> ___
> 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
[PATCH libdrm] amdgpu/test: Disable deadlock tests for all non gfx8/9 ASICs.
Since only for those ASICs gpu reset is enabled by deafult.
Also update disable message and fix identation .
Signed-off-by: Andrey Grodzovsky
---
tests/amdgpu/deadlock_tests.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/tests/amdgpu/deadlock_tests.c b/tests/amdgpu/deadlock_tests.c
index 04600a7..00a17ca 100644
--- a/tests/amdgpu/deadlock_tests.c
+++ b/tests/amdgpu/deadlock_tests.c
@@ -119,11 +119,13 @@ CU_BOOL suite_deadlock_tests_enable(void)
&minor_version, &device_handle))
return CU_FALSE;
- if (device_handle->info.family_id == AMDGPU_FAMILY_SI ||
- device_handle->info.family_id == AMDGPU_FAMILY_CZ ||
- device_handle->info.family_id == AMDGPU_FAMILY_RV ||
- device_handle->info.family_id == AMDGPU_FAMILY_KV) {
- printf("\n\nCurrently hangs the CP on this ASIC, deadlock suite
disabled\n");
+ /*
+* Only enable for ASICs supporting GPU reset and for which it's enabled
+* by default (currently GFX8/9 dGPUS
+*/
+ if (device_handle->info.family_id != AMDGPU_FAMILY_VI &&
+ device_handle->info.family_id != AMDGPU_FAMILY_AI) {
+ printf("\n\nGPU reset is not enabled for the ASIC, deadlock
suite disabled\n");
enable = CU_FALSE;
}
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] arm64: dts: qcom: sdm845: Add dpu to sdm845 dts file
Hi,
On Thu, Nov 1, 2018 at 7:25 PM Jeykumar Sankaran wrote:
> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> @@ -978,6 +978,197 @@
> #thermal-sensor-cells = <1>;
> };
Note that your patch doesn't cleanly apply to Andy's tree. Context
here shows that you have it between the thermal sensor and the SPMI
bus but the "qcom,sdm845-aoss-cc" node is there in. It's easy enough
to resolve, but it's usually considered nice to post patches that the
maintainers can apply.
When resolving this myself, I realized that you have the node in the
wrong place anyway. Nodes with a unit address should be sorted by
unit address. As you unit address is ae0 you should be right
above 'dispcc: clock-controller@af0'.
> + mdss: mdss@ae0 {
> + compatible = "qcom,sdm845-mdss";
> + reg = <0xae0 0x1000>;
> + reg-names = "mdss";
> +
> + power-domains = <&dispcc 0>;
> +
> + clocks = <&gcc GCC_DISP_AHB_CLK>,
> +<&gcc GCC_DISP_AXI_CLK>,
> +<&dispcc DISP_CC_MDSS_MDP_CLK>;
> + clock-names = "iface", "bus", "core";
> +
> + assigned-clocks = <&dispcc DISP_CC_MDSS_MDP_CLK>;
> + assigned-clock-rates = <3>;
> +
> + interrupts = ;
> + interrupt-controller;
> + #interrupt-cells = <1>;
> +
> + iommus = <&apps_smmu 0x880 0x8>,
> +<&apps_smmu 0xc80 0x8>;
> +
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + mdss_mdp: mdp@ae01000 {
> + compatible = "qcom,sdm845-dpu";
> + reg = <0x0ae01000 0x8f000>,
> + <0x0aeb 0x2008>;
> + reg-names = "mdp", "vbif";
> +
> + clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
> +<&dispcc DISP_CC_MDSS_AXI_CLK>,
> +<&dispcc DISP_CC_MDSS_MDP_CLK>,
> +<&dispcc DISP_CC_MDSS_VSYNC_CLK>;
> + clock-names = "iface", "bus", "core", "vsync";
> +
> + assigned-clocks = <&dispcc
> DISP_CC_MDSS_MDP_CLK>,
> + <&dispcc
> DISP_CC_MDSS_VSYNC_CLK>;
> + assigned-clock-rates = <3>,
> + <1920>;
> +
> + interrupt-parent = <&mdss>;
> + interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + dpu_intf1_out: endpoint {
> + remote-endpoint =
> <&dsi0_in>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + dpu_intf2_out: endpoint {
> + remote-endpoint =
> <&dsi1_in>;
> + };
> + };
> + };
> + };
> +
> + dsi0: dsi@ae94000 {
> + compatible = "qcom,mdss-dsi-ctrl";
> + reg = <0xae94000 0x400>;
> + reg-names = "dsi_ctrl";
> +
> + interrupt-parent = <&mdss>;
> + interrupts = <4 IRQ_TYPE_LEVEL_HIGH>;
> +
> + clocks = <&dispcc DISP_CC_MDSS_BYTE0_CLK>,
> +<&dispcc
> DISP_CC_MDSS_BYTE0_INTF_CLK>,
> +<&dispcc DISP_CC_MDSS_PCLK0_CLK>,
> +<&dispcc DISP_CC_MDSS_ESC0_CLK>,
> +<&dispcc DISP_CC_MDSS_AHB_CLK>,
> +<&dispcc DISP_CC_MDSS_AXI_CLK>;
> + clock-names = "byte_clk",
> + "byte_intf_clk",
> +
Re: [PATCH v2 3/3] drm/i915: Add short HPD IRQ storm detection for non-MST systems
On Fri, Oct 26, 2018 at 06:49:09PM -0400, Lyude Paul wrote:
> Unfortunately, it seems that the HPD IRQ storm problem from the early
> days of Intel GPUs was never entirely solved, only mostly. Within the
> last couple of days, I got a bug report from one of our customers who
> had been having issues with their machine suddenly booting up very
> slowly after having updated. The amount of time it took to boot went
> from around 30 seconds, to over 6 minutes consistently.
>
> After some investigation, I discovered that i915 was reporting massive
> amounts of short HPD IRQ spam on this system from the DisplayPort port,
> despite there not being anything actually connected. The symptoms would
> start with one "long" HPD IRQ being detected at boot:
>
> [1.891398] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat
> 0x0044, dig 0x0044, pins 0x00a0
> [1.891436] [drm:intel_hpd_irq_handler [i915]] digital hpd port B - long
> [1.891472] [drm:intel_hpd_irq_handler [i915]] Received HPD interrupt on
> PIN 5 - cnt: 0
> [1.891508] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - long
> [1.891544] [drm:intel_hpd_irq_handler [i915]] Received HPD interrupt on
> PIN 7 - cnt: 0
> [1.891592] [drm:intel_dp_hpd_pulse [i915]] got hpd irq on port B - long
> [1.891628] [drm:intel_dp_hpd_pulse [i915]] got hpd irq on port D - long
> …
>
> followed by constant short IRQs afterwards:
>
> [1.895091] [drm:intel_encoder_hotplug [i915]] [CONNECTOR:66:DP-1] status
> updated from unknown to disconnected
> [1.895129] [drm:i915_hotplug_work_func [i915]] Connector DP-3 (pin 7)
> received hotplug event.
> [1.895165] [drm:intel_dp_detect [i915]] [CONNECTOR:72:DP-3]
> [1.895275] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat
> 0x0020, dig 0x0020, pins 0x0080
> [1.895312] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
> [1.895762] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat
> 0x0020, dig 0x0020, pins 0x0080
> [1.895799] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
> [1.896239] [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status
> 0x71450085
> [1.896293] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat
> 0x0020, dig 0x0020, pins 0x0080
> [1.896330] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
> [1.896781] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat
> 0x0020, dig 0x0020, pins 0x0080
> [1.896817] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
> [1.897275] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat
> 0x0020, dig 0x0020, pins 0x0080
>
> The customer's system in question has a GM45 GPU, which is apparently
> well known for hotplugging storms.
>
> So, workaround this impressively broken hardware by changing the default
> HPD storm threshold from 5 to 50. Then, make long IRQs count for 10, and
> short IRQs count for 1. This makes it so that 5 long IRQs will trigger
> an HPD storm, and on systems with short HPD storm detection 50 short
> IRQs will trigger an HPD storm. 50 short IRQs amounts to 100ms of
> constant pulsing, which seems like a good middleground between being too
> sensitive and not being sensitive enough (which would cause visible
> stutters in userspace every time a storm occurs).
>
> And just to be extra safe: we don't enable this by default on systems
> with MST support. There's too high of a chance of MST support triggering
> storm detection, and systems that are new enough to support MST are a
> lot less likely to have issues with IRQ storms anyway.
>
> As a note: this patch was tested using a ThinkPad T450s and a Chamelium
> to simulate the short IRQ storms.
>
> Changes since v1:
> - Don't use two separate thresholds, just make long IRQs count for 10
> each and short IRQs count for 1. This simplifies the code a bit
> - Ville Syrjälä
>
> Signed-off-by: Lyude Paul
> Cc: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 74
> drivers/gpu/drm/i915/i915_drv.h | 5 +-
> drivers/gpu/drm/i915/i915_irq.c | 7 +++
> drivers/gpu/drm/i915/intel_hotplug.c | 47 +++---
> 4 files changed, 113 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index b4744a68cd88..1595b8565875 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -4641,6 +4641,79 @@ static const struct file_operations
> i915_hpd_storm_ctl_fops = {
> .write = i915_hpd_storm_ctl_write
> };
>
> +static int i915_hpd_short_storm_ctl_show(struct seq_file *m, void *data)
> +{
> + struct drm_i915_private *dev_priv = m->private;
> +
> + seq_printf(m, "Enabled: %s\n",
> +yesno(dev_priv->hotplug.hpd_short_storm_enabled));
> +
> + return 0;
>
Re: [PATCH libdrm] amdgpu/test: Add illegal register and memory access test.
There is a pplib messaging related failure currently during GPU reset. I will put this issue on my TODO list for later time after handling more prioritized stuff and will disable the deadlock test suite for all non dGPU gfx8/9 ASICs until then. Andrey On 11/02/2018 02:14 PM, Grodzovsky, Andrey wrote: Have you tried enabling reset on gfx7 dGPUs? It uses pretty much the same sequence as gfx8 so it might just work. Alex I haven't but I can give it a try. Andrey ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm/dpu: Don't use devm for component devices
On Fri, Nov 02, 2018 at 10:57:46AM -0700, Jeykumar Sankaran wrote:
> On 2018-11-02 07:30, Jordan Crouse wrote:
> >Devices that are bound as components should not use devm since
> >device managed memory is not freed when the component is
> >unbound.
> >
> >In particular this is an issue if the component bind fails
> >due to an -EPROBE_DEFER. In this case the bind would try again
>
> Isn't this the only case where using devm would be a problem? Even
> in this case
> do you expect any leaks if devm_kfree is called before DEFERing due
> to errors
> and in unbounds?
Yes, defer would be the only case where the memory would be leaked because you
would re-initialize the pointer when you attempted to bind again but then
again this is the only real case you need to worry about in a stable environment
so it is worth optimizing for.
You are right that using devm_kfree would solve the problem but the whole point
of devm is that it is supposed to be fire-and-forget. If you have to go to
the effort of explicitly bounding devm_kmalloc with devm_kfree then why are you
bothering to use devm in the first place?
Jordan
> >later and any devm managed memory allocated during the former
> >aborted attempt would be leaked until the device itself was
> >destroyed. Since all the memory allocated during a bind
> >should be freed during an unbind (or bind error case) there isn't
> >any reason to use devm for resources that have a explicit
> >teardown step.
> >
> >This doesn't remove devm for all resources - in particular
> >msm_ioremap() still uses devm_ioremap() but thats a generic
> >issue that can easily be addressed as a cleanup later and the
> >unbind code already does the requisite devm calls to unmap it.
> >
> >Signed-off-by: Jordan Crouse
> >---
> > drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 4 ++--
> > drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c | 4 +---
> > drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 10 ++
> > drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c| 8 +---
> > 4 files changed, 14 insertions(+), 12 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> >b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> >index 82c55efb500f..287d4c3e58c3 100644
> >--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> >+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> >@@ -2220,14 +2220,14 @@ struct drm_encoder *dpu_encoder_init(struct
> >drm_device *dev,
> > struct dpu_encoder_virt *dpu_enc = NULL;
> > int rc = 0;
> >
> >-dpu_enc = devm_kzalloc(dev->dev, sizeof(*dpu_enc), GFP_KERNEL);
> >+dpu_enc = kzalloc(sizeof(*dpu_enc), GFP_KERNEL);
> > if (!dpu_enc)
> > return ERR_PTR(ENOMEM);
> >
> > rc = drm_encoder_init(dev, &dpu_enc->base, &dpu_encoder_funcs,
> > drm_enc_mode, NULL);
> > if (rc) {
> >-devm_kfree(dev->dev, dpu_enc);
> >+kfree(dpu_enc);
> > return ERR_PTR(rc);
> > }
> >
> >diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c
> >b/drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c
> >index 89ee4b36beff..90b53e9508f2 100644
> >--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c
> >+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c
> >@@ -155,9 +155,7 @@ int msm_dss_parse_clock(struct platform_device
> >*pdev,
> > return 0;
> > }
> >
> >-mp->clk_config = devm_kzalloc(&pdev->dev,
> >- sizeof(struct dss_clk) * num_clk,
> >- GFP_KERNEL);
> >+mp->clk_config = kcalloc(num_clk, sizeof(struct dss_clk),
> >GFP_KERNEL);
> > if (!mp->clk_config)
> > return -ENOMEM;
> >
> >diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> >b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> >index 985c855796ae..5ac3c3f3b08d 100644
> >--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> >+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> >@@ -1086,13 +1086,14 @@ static int dpu_bind(struct device *dev, struct
> >device *master, void *data)
> > struct dss_module_power *mp;
> > int ret = 0;
> >
> >-dpu_kms = devm_kzalloc(&pdev->dev, sizeof(*dpu_kms), GFP_KERNEL);
> >+dpu_kms = kzalloc(sizeof(*dpu_kms), GFP_KERNEL);
> > if (!dpu_kms)
> > return -ENOMEM;
> >
> > mp = &dpu_kms->mp;
> > ret = msm_dss_parse_clock(pdev, mp);
> > if (ret) {
> >+kfree(dpu_kms);
> > DPU_ERROR("failed to parse clocks, ret=%d\n", ret);
> > return ret;
> > }
> >@@ -1109,7 +1110,7 @@ static int dpu_bind(struct device *dev,
> >struct device
> >*master, void *data)
> > dpu_kms->rpm_enabled = true;
> >
> > priv->kms = &dpu_kms->base;
> >-return ret;
> >+return 0;
> > }
> >
> > static void dpu_unbind(struct device *dev, struct device *master, void
> >*data)
> >@@ -1120,11 +1121,12 @@ static void dpu_unbind(struct device *dev,
> >struct
> >device *master, void *data)
> >
> > dpu_power_resource_deinit(pdev, &dpu_kms->phandle);
> > msm_dss_put_clk(mp->clk_config, m
Re: [RFC PATCH v2] android: ion: How to properly clean caches for uncached allocations
On Thu, Nov 1, 2018 at 3:15 PM, Liam Mark wrote: > Based on the suggestions from Laura I created a first draft for a change > which will attempt to ensure that uncached mappings are only applied to > ION memory who's cache lines have been cleaned. > It does this by providing cached mappings (for uncached ION allocations) > until the ION buffer is dma mapped and successfully cleaned, then it drops > the userspace mappings and when pages are accessed they are faulted back > in and uncached mappings are created. > > This change has the following potential disadvantages: > - It assumes that userpace clients won't attempt to access the buffer > while it is being mapped as we are removing the userpspace mappings at > this point (though it is okay for them to have it mapped) > - It assumes that kernel clients won't hold a kernel mapping to the buffer > (ie dma_buf_kmap) while it is being dma-mapped. What should we do if there > is a kernel mapping at the time of dma mapping, fail the mapping, warn? > - There may be a performance penalty as a result of having to fault in the > pages after removing the userspace mappings. > > It passes basic testing involving reading writing and reading from > uncached system heap allocations before and after dma mapping. > > Please let me know if this is heading in the right direction and if there > are any concerns. > > Signed-off-by: Liam Mark Thanks for sending this out! I gave this a whirl on my HiKey960. Seems to work ok, but I'm not sure if the board's usage benefits much from your changes. First, ignore how crazy overall these frame values are right off, we have some cpuidle/cpufreq issues w/ 4.14 that we're still sorting out. Without your patch: default-jankview_list_view,jankbench,1,mean,0,iter_10,List View Fling,48.1333678017, default-jankview_list_view,jankbench,2,mean,0,iter_10,List View Fling,55.8407417387, default-jankview_list_view,jankbench,3,mean,0,iter_10,List View Fling,43.88160374, default-jankview_list_view,jankbench,4,mean,0,iter_10,List View Fling,42.2606222784, default-jankview_list_view,jankbench,5,mean,0,iter_10,List View Fling,44.1791721797, default-jankview_list_view,jankbench,6,mean,0,iter_10,List View Fling,39.7692731775, default-jankview_list_view,jankbench,7,mean,0,iter_10,List View Fling,48.5462154074, default-jankview_list_view,jankbench,8,mean,0,iter_10,List View Fling,40.1321166548, default-jankview_list_view,jankbench,9,mean,0,iter_10,List View Fling,48.0163174397, default-jankview_list_view,jankbench,10,mean,0,iter_10,List View Fling,51.1971686844, With your patch: default-jankview_list_view,jankbench,1,mean,0,iter_10,List View Fling,43.3983274772, default-jankview_list_view,jankbench,2,mean,0,iter_10,List View Fling,45.8456678409, default-jankview_list_view,jankbench,3,mean,0,iter_10,List View Fling,42.9609507211, default-jankview_list_view,jankbench,4,mean,0,iter_10,List View Fling,48.602186248, default-jankview_list_view,jankbench,5,mean,0,iter_10,List View Fling,47.9257658765, default-jankview_list_view,jankbench,6,mean,0,iter_10,List View Fling,47.7405384035, default-jankview_list_view,jankbench,7,mean,0,iter_10,List View Fling,52.0017667611, default-jankview_list_view,jankbench,8,mean,0,iter_10,List View Fling,43.7480812349, default-jankview_list_view,jankbench,9,mean,0,iter_10,List View Fling,44.8138758796, default-jankview_list_view,jankbench,10,mean,0,iter_10,List View Fling,46.4941804068, Just for reference, compared to my earlier patch: default-jankview_list_view,jankbench,1,mean,0,iter_10,List View Fling,33.8638094852, default-jankview_list_view,jankbench,2,mean,0,iter_10,List View Fling,34.0859500474, default-jankview_list_view,jankbench,3,mean,0,iter_10,List View Fling,35.6278973379, default-jankview_list_view,jankbench,4,mean,0,iter_10,List View Fling,31.4999822195, default-jankview_list_view,jankbench,5,mean,0,iter_10,List View Fling,40.0634874771, default-jankview_list_view,jankbench,6,mean,0,iter_10,List View Fling,28.0633472181, default-jankview_list_view,jankbench,7,mean,0,iter_10,List View Fling,36.0400585616, default-jankview_list_view,jankbench,8,mean,0,iter_10,List View Fling,38.1871234374, default-jankview_list_view,jankbench,9,mean,0,iter_10,List View Fling,37.4103602014, default-jankview_list_view,jankbench,10,mean,0,iter_10,List View Fling,40.7147881231, Though I'll spend some more time looking at it closer. thanks -john ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v2 01/14] kunit: test: add KUnit test runner core
On 10/23/2018 05:57 PM, Brendan Higgins wrote:
> Add core facilities for defining unit tests; this provides a common way
> to define test cases, functions that execute code which is under test
> and determine whether the code under test behaves as expected; this also
> provides a way to group together related test cases in test suites (here
> we call them test_modules).
>
> Just define test cases and how to execute them for now; setting
> expectations on code will be defined later.
>
> Signed-off-by: Brendan Higgins
> ---
> include/kunit/test.h | 165 ++
> kunit/Kconfig| 17 +
> kunit/Makefile | 1 +
> kunit/test.c | 168 +++
> 4 files changed, 351 insertions(+)
> create mode 100644 include/kunit/test.h
> create mode 100644 kunit/Kconfig
> create mode 100644 kunit/Makefile
> create mode 100644 kunit/test.c
>
> diff --git a/include/kunit/test.h b/include/kunit/test.h
> new file mode 100644
> index 0..e0b14b227ac44
> --- /dev/null
> +++ b/include/kunit/test.h
> @@ -0,0 +1,165 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Base unit test (KUnit) API.
> + *
> + * Copyright (C) 2018, Google LLC.
> + * Author: Brendan Higgins
> + */
> +
> +#ifndef _KUNIT_TEST_H
> +#define _KUNIT_TEST_H
> +
> +#include
> +#include
> +
> +struct test;
> +
> +/**
> + * struct test_case - represents an individual test case.
> + * @run_case: the function representing the actual test case.
> + * @name: the name of the test case.
> + *
> + * A test case is a function with the signature, ``void (*)(struct test *)``
> + * that makes expectations (see TEST_EXPECT_TRUE()) about code under test.
> Each
> + * test case is associated with a &struct test_module and will be run after
> the
> + * module's init function and followed by the module's exit function.
> + *
> + * A test case should be static and should only be created with the
> TEST_CASE()
> + * macro; additionally, every array of test cases should be terminated with
> an
> + * empty test case.
> + *
> + * Example:
> + *
> + * .. code-block:: c
> + *
> + * void add_test_basic(struct test *test)
> + * {
> + * TEST_EXPECT_EQ(test, 1, add(1, 0));
> + * TEST_EXPECT_EQ(test, 2, add(1, 1));
> + * TEST_EXPECT_EQ(test, 0, add(-1, 1));
> + * TEST_EXPECT_EQ(test, INT_MAX, add(0, INT_MAX));
> + * TEST_EXPECT_EQ(test, -1, add(INT_MAX, INT_MIN));
> + * }
> + *
> + * static struct test_case example_test_cases[] = {
> + * TEST_CASE(add_test_basic),
> + * {},
> + * };
> + *
> + */
> +struct test_case {
> + void (*run_case)(struct test *test);
> + const char name[256];
> +
> + /* private: internal use only. */
> + bool success;
> +};
> +
Introducing a prefix kunit_* might be a good idea for the API.
This comment applies to the rest of patches as well.
thanks,
-- Shuah
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108625] AMDGPU - Can't even get Xorg to start - Kernel driver hangs with ring buffer timeout on ARM64
https://bugs.freedesktop.org/show_bug.cgi?id=108625 --- Comment #7 from Alex Deucher --- Or try a newer or older version of mesa. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108625] AMDGPU - Can't even get Xorg to start - Kernel driver hangs with ring buffer timeout on ARM64
https://bugs.freedesktop.org/show_bug.cgi?id=108625 --- Comment #6 from Alex Deucher --- It looks like something submitted by mesa caused a GPU hang. You might try starting a bare X server and trying some simple OGL apps to start with. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 201599] [drm:atom_op_jump [amdgpu]] *ERROR* atombios stuck in loop for more than 5secs aborting
https://bugzilla.kernel.org/show_bug.cgi?id=201599 Alex Deucher (alexdeuc...@gmail.com) changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #1 from Alex Deucher (alexdeuc...@gmail.com) --- Please attach your full dmesg output. Is this a regression? -- 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
[PATCH v2] drm/msm/dpu: Don't use devm for component devices
Devices that are bound as components should not use devm since
device managed memory is not freed when the component is
unbound.
In particular this is an issue if the compoent bind fails
due to an -EPROBE_DEFER. In this case the bind would try again
later and any devm managed meory allocated during the former
aborted attempt would be leaked until the device itself was
destroyed. Therefore, all the memory allocated during a bind
should be freed during an unbind (or bind error case) and there
isn't any reason to use devm for resources that have a explicit
teardown step.
This doesn't remove devm for all resources - in particular
msm_ioremap() still uses devm_ioremap() but thats a more
generic condition that can easily be addressed as a cleanup
later and the unbind code already does the requisite devm
calls to unmap it.
v2: free mp->clk_config on failure
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 4 ++--
drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c | 6 +++---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 10 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c| 8 +---
4 files changed, 16 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 82c55efb500f..287d4c3e58c3 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -2220,14 +2220,14 @@ struct drm_encoder *dpu_encoder_init(struct drm_device
*dev,
struct dpu_encoder_virt *dpu_enc = NULL;
int rc = 0;
- dpu_enc = devm_kzalloc(dev->dev, sizeof(*dpu_enc), GFP_KERNEL);
+ dpu_enc = kzalloc(sizeof(*dpu_enc), GFP_KERNEL);
if (!dpu_enc)
return ERR_PTR(ENOMEM);
rc = drm_encoder_init(dev, &dpu_enc->base, &dpu_encoder_funcs,
drm_enc_mode, NULL);
if (rc) {
- devm_kfree(dev->dev, dpu_enc);
+ kfree(dpu_enc);
return ERR_PTR(rc);
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c
index 89ee4b36beff..14fecf00e032 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c
@@ -155,9 +155,7 @@ int msm_dss_parse_clock(struct platform_device *pdev,
return 0;
}
- mp->clk_config = devm_kzalloc(&pdev->dev,
- sizeof(struct dss_clk) * num_clk,
- GFP_KERNEL);
+ mp->clk_config = kcalloc(num_clk, sizeof(struct dss_clk), GFP_KERNEL);
if (!mp->clk_config)
return -ENOMEM;
@@ -201,5 +199,7 @@ int msm_dss_parse_clock(struct platform_device *pdev,
err:
msm_dss_put_clk(mp->clk_config, num_clk);
+ kfree(mp->clk_config);
+ mp->clk_config = NULL;
return rc;
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 985c855796ae..5ac3c3f3b08d 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -1086,13 +1086,14 @@ static int dpu_bind(struct device *dev, struct device
*master, void *data)
struct dss_module_power *mp;
int ret = 0;
- dpu_kms = devm_kzalloc(&pdev->dev, sizeof(*dpu_kms), GFP_KERNEL);
+ dpu_kms = kzalloc(sizeof(*dpu_kms), GFP_KERNEL);
if (!dpu_kms)
return -ENOMEM;
mp = &dpu_kms->mp;
ret = msm_dss_parse_clock(pdev, mp);
if (ret) {
+ kfree(dpu_kms);
DPU_ERROR("failed to parse clocks, ret=%d\n", ret);
return ret;
}
@@ -1109,7 +1110,7 @@ static int dpu_bind(struct device *dev, struct device
*master, void *data)
dpu_kms->rpm_enabled = true;
priv->kms = &dpu_kms->base;
- return ret;
+ return 0;
}
static void dpu_unbind(struct device *dev, struct device *master, void *data)
@@ -1120,11 +1121,12 @@ static void dpu_unbind(struct device *dev, struct
device *master, void *data)
dpu_power_resource_deinit(pdev, &dpu_kms->phandle);
msm_dss_put_clk(mp->clk_config, mp->num_clk);
- devm_kfree(&pdev->dev, mp->clk_config);
- mp->num_clk = 0;
+ kfree(mp->clk_config);
if (dpu_kms->rpm_enabled)
pm_runtime_disable(&pdev->dev);
+
+ kfree(dpu_kms);
}
static const struct component_ops dpu_ops = {
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
index 2235ef8129f4..c82347afc967 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
@@ -161,7 +161,7 @@ static void dpu_mdss_destroy(struct drm_device *dev)
free_irq(platform_get_irq(pdev, 0), dpu_mdss);
msm_dss_put_clk(mp->clk_config, mp->num_clk);
- devm_kfree(&pdev->dev, mp->clk_config);
+ kfree(mp->clk_
Re: [RFC v2 00/14] kunit: introduce KUnit, the Linux kernel unit testing framework
Hi Brendan,
On 10/23/2018 05:57 PM, Brendan Higgins wrote:
> This patch set proposes KUnit, a lightweight unit testing and mocking
> framework for the Linux kernel.
>
> Unlike Autotest and kselftest, KUnit is a true unit testing framework;
> it does not require installing the kernel on a test machine or in a VM
> and does not require tests to be written in userspace running on a host
> kernel. Additionally, KUnit is fast: From invocation to completion KUnit
> can run several dozen tests in under a second. Currently, the entire
> KUnit test suite for KUnit runs in under a second from the initial
> invocation (build time excluded).
>
> KUnit is heavily inspired by JUnit, Python's unittest.mock, and
> Googletest/Googlemock for C++. KUnit provides facilities for defining
> unit test cases, grouping related test cases into test suites, providing
> common infrastructure for running tests, mocking, spying, and much more.
>
> ## What's so special about unit testing?
>
> A unit test is supposed to test a single unit of code in isolation,
> hence the name. There should be no dependencies outside the control of
> the test; this means no external dependencies, which makes tests orders
> of magnitudes faster. Likewise, since there are no external dependencies,
> there are no hoops to jump through to run the tests. Additionally, this
> makes unit tests deterministic: a failing unit test always indicates a
> problem. Finally, because unit tests necessarily have finer granularity,
> they are able to test all code paths easily solving the classic problem
> of difficulty in exercising error handling code.
>
> ## Is KUnit trying to replace other testing frameworks for the kernel?
>
> No. Most existing tests for the Linux kernel are end-to-end tests, which
> have their place. A well tested system has lots of unit tests, a
> reasonable number of integration tests, and some end-to-end tests. KUnit
> is just trying to address the unit test space which is currently not
> being addressed.
>
> ## More information on KUnit
>
> There is a bunch of documentation near the end of this patch set that
> describes how to use KUnit and best practices for writing unit tests.
> For convenience I am hosting the compiled docs here:
> https://google.github.io/kunit-docs/third_party/kernel/docs/
>
> ## Changes Since Last Version
>
> - Updated patchset to apply cleanly on 4.19.
> - Stripped down patchset to focus on just the core features (I dropped
>mocking, spying, and the MMIO stuff for now; you can find these
>patches here: https://kunit-review.googlesource.com/c/linux/+/1132),
>as suggested by Rob.
> - Cleaned up some of the commit messages and tweaked commit order a
>bit based on suggestions.
>
Framework looks good. I think it would be helpful to include a real test
in the patch series to get a feel for how effective it is.
On one hand, KUnit stands on its own as its own and maybe it should be placed in
under tools/testing/KUnit, however I am wondering would it be beneficial for the
framework to under selftests.
I am a bit concerned about the number of test framework we have at the moment
and
are we running the risk of fragmenting the landscape. I am concerned if this
would
lead to developer confusion as to where to add tests.
That being said, I don't have a strong opinion one way or the other.
btw I started playing with kunit following the instructions and ran into
problems:
./tools/testing/kunit/kunit.py
usage: kunit.py [-h] {run,new} ...
Helps writing and running KUnit tests.
positional arguments:
{run,new}
run Runs KUnit tests.
new Prints out boilerplate for writing new tests.
optional arguments:
-h, --help show this help message and exit
./tools/testing/kunit/kunit.py run
Regenerating .config ...
ERROR:root:Provided Kconfig is not contained in validated .config!
thanks,
-- Shuah
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] amdgpu/test: Add illegal register and memory access test.
On 11/02/2018 02:12 PM, Alex Deucher wrote:
> On Fri, Nov 2, 2018 at 11:59 AM Grodzovsky, Andrey
> wrote:
>>
>>
>> On 11/02/2018 10:24 AM, Michel Dänzer wrote:
>>> On 2018-10-31 7:33 p.m., Andrey Grodzovsky wrote:
Illegal access will cause CP hang followed by job timeout and
recovery kicking in.
Also, disable the suite for all APU ASICs until GPU
reset issues for them will be resolved and GPU reset recovery
will be enabled by default.
Signed-off-by: Andrey Grodzovsky
[...]
@@ -94,7 +119,9 @@ CU_BOOL suite_deadlock_tests_enable(void)
&minor_version, &device_handle))
return CU_FALSE;
-if (device_handle->info.family_id == AMDGPU_FAMILY_SI) {
+if (device_handle->info.family_id == AMDGPU_FAMILY_SI ||
+device_handle->info.family_id == AMDGPU_FAMILY_CZ ||
+device_handle->info.family_id == AMDGPU_FAMILY_RV) {
printf("\n\nCurrently hangs the CP on this ASIC, deadlock
suite disabled\n");
enable = CU_FALSE;
}
>>> Indentation is wrong here and in other places. The libdrm tree contains
>>> configuration files for EditorConfig (https://editorconfig.org/); since
>>> you're using Eclipse, https://github.com/ncjones/editorconfig-eclipse
>>> should help.
>> I installed the eclipse plugin.
>>>
>>> I run amdgpu_test as part of my daily build/test script during lunch
>>> break; when I came back today, I was greeted by a GFX hang of the
>>> Bonaire in my development box due to this test. Please disable it for
>>> all pre-GFX8 ASICs. Ideally, it should also check at runtime that GPU
>>> recovery is actually enabled, as that still isn't the case by default
>>> except with bleeding edge amdgpu kernel code.
>> Thanks for testing - I will send a fix.
>>
> Have you tried enabling reset on gfx7 dGPUs? It uses pretty much the
> same sequence as gfx8 so it might just work.
>
> Alex
I haven't but I can give it a try.
Andrey
>
>> Andrey
>>>
>> ___
>> 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 libdrm] amdgpu/test: Add illegal register and memory access test.
On Fri, Nov 2, 2018 at 11:59 AM Grodzovsky, Andrey
wrote:
>
>
>
> On 11/02/2018 10:24 AM, Michel Dänzer wrote:
> > On 2018-10-31 7:33 p.m., Andrey Grodzovsky wrote:
> >> Illegal access will cause CP hang followed by job timeout and
> >> recovery kicking in.
> >> Also, disable the suite for all APU ASICs until GPU
> >> reset issues for them will be resolved and GPU reset recovery
> >> will be enabled by default.
> >>
> >> Signed-off-by: Andrey Grodzovsky
> >>
> >> [...]
> >>
> >> @@ -94,7 +119,9 @@ CU_BOOL suite_deadlock_tests_enable(void)
> >> &minor_version, &device_handle))
> >> return CU_FALSE;
> >>
> >> -if (device_handle->info.family_id == AMDGPU_FAMILY_SI) {
> >> +if (device_handle->info.family_id == AMDGPU_FAMILY_SI ||
> >> +device_handle->info.family_id == AMDGPU_FAMILY_CZ ||
> >> +device_handle->info.family_id == AMDGPU_FAMILY_RV) {
> >> printf("\n\nCurrently hangs the CP on this ASIC, deadlock
> >> suite disabled\n");
> >> enable = CU_FALSE;
> >> }
> > Indentation is wrong here and in other places. The libdrm tree contains
> > configuration files for EditorConfig (https://editorconfig.org/); since
> > you're using Eclipse, https://github.com/ncjones/editorconfig-eclipse
> > should help.
>
> I installed the eclipse plugin.
> >
> >
> > I run amdgpu_test as part of my daily build/test script during lunch
> > break; when I came back today, I was greeted by a GFX hang of the
> > Bonaire in my development box due to this test. Please disable it for
> > all pre-GFX8 ASICs. Ideally, it should also check at runtime that GPU
> > recovery is actually enabled, as that still isn't the case by default
> > except with bleeding edge amdgpu kernel code.
> Thanks for testing - I will send a fix.
>
Have you tried enabling reset on gfx7 dGPUs? It uses pretty much the
same sequence as gfx8 so it might just work.
Alex
> Andrey
> >
> >
>
> ___
> 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 v7 00/19] DSC enabling remaining patches
On Thu, Nov 01, 2018 at 11:46:40PM -0700, Manasi Navare wrote: > This patch series addresses review comments on previous DSC series: > > https://patchwork.freedesktop.org/series/47514/ > > Gaurav K Singh (3): > drm/i915/dsc: Define & Compute VESA DSC params > drm/i915/dsc: Compute Rate Control parameters for DSC > drm/i915/dp: Enable/Disable DSC in DP Sink > > Manasi Navare (15): > drm/dsc: Define Display Stream Compression PPS infoframe > drm/dsc: Define VESA Display Stream Compression Capabilities > drm/dsc: Add helpers for DSC picture parameter set infoframes > drm/i915/dp: Add DSC params and DSC config to intel_crtc_state > drm/i915/dp: Compute DSC pipe config in atomic check > drm/i915/dp: Do not enable PSR2 if DSC is enabled > drm/dsc: Define the DSC 1.1 and 1.2 Line Buffer depth constants > drm/i915/dsc: Add a power domain for VDSC on eDP/MIPI DSI > drm/i915/dp: Configure i915 Picture parameter Set registers during DSC > enabling > drm/i915/dp: Use the existing write_infoframe() for DSC PPS SDPs > drm/i915/dp: Populate DSC PPS SDP and send PPS infoframes > drm/i915/dp: Configure Display stream splitter registers during DSC > enable > drm/i915/dp: Disable DSC in source by disabling DSS CTL bits > drm/i915/dsc: Enable and disable appropriate power wells for VDSC > drm/i915/dsc: Add Per connector debugfs node for DSC support/enable > > Srivatsa, Anusha (1): > drm/dsc: Define Rate Control values that do not change over > configurations I think we have these real functional issues left: - no FEC so should reject DSC on external DP - get_power_domains() thing wasn't right The potentially user triggerable DRM_ERROR()s have to be removed or explained why they can't happen (in which case a WARN() would probably be a more clear hint to the reader). The intel_dsc_enable() call I definitely would like see moved into the encoder->per_enable(). No one will think to look for it in the current location. The i915_modparams.enable_psr change seemed unrelated, but no idea if it's intentional or not. And finally there were various style nits that are optional. But I would recomment doing them since it's trivial stuff and avoids further churn in the code later. I think that's about it really. > > Documentation/gpu/drm-kms-helpers.rst | 12 + > drivers/gpu/drm/Makefile|2 +- > drivers/gpu/drm/drm_dsc.c | 228 + > drivers/gpu/drm/i915/Makefile |3 +- > drivers/gpu/drm/i915/i915_debugfs.c | 71 +- > drivers/gpu/drm/i915/i915_drv.h |4 + > drivers/gpu/drm/i915/i915_reg.h |1 + > drivers/gpu/drm/i915/intel_ddi.c|8 +- > drivers/gpu/drm/i915/intel_display.c| 28 +- > drivers/gpu/drm/i915/intel_display.h|4 +- > drivers/gpu/drm/i915/intel_dp.c | 196 +++- > drivers/gpu/drm/i915/intel_dp_mst.c |2 +- > drivers/gpu/drm/i915/intel_drv.h| 21 + > drivers/gpu/drm/i915/intel_hdmi.c | 21 +- > drivers/gpu/drm/i915/intel_psr.c| 16 +- > drivers/gpu/drm/i915/intel_runtime_pm.c |4 +- > drivers/gpu/drm/i915/intel_vdsc.c | 1100 +++ > include/drm/drm_dp_helper.h |3 + > include/drm/drm_dsc.h | 485 ++ > 19 files changed, 2169 insertions(+), 40 deletions(-) > create mode 100644 drivers/gpu/drm/drm_dsc.c > create mode 100644 drivers/gpu/drm/i915/intel_vdsc.c > create mode 100644 include/drm/drm_dsc.h > > -- > 2.18.0 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Ville Syrjälä Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm next fixes for 4.20-rc1
On Thu, Nov 1, 2018 at 10:32 PM Dave Airlie wrote: > > Pretty much a normal fixes pull pre-rc1, mostly amdgpu fixes, one i915 > link training regression fix, and a couple of minor panel/bridge fixes > and a panel quirk. Pulled, Linus ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm/dpu: Don't use devm for component devices
On 2018-11-02 07:30, Jordan Crouse wrote:
Devices that are bound as components should not use devm since
device managed memory is not freed when the component is
unbound.
In particular this is an issue if the component bind fails
due to an -EPROBE_DEFER. In this case the bind would try again
Isn't this the only case where using devm would be a problem? Even in
this case
do you expect any leaks if devm_kfree is called before DEFERing due to
errors
and in unbounds?
Thanks,
Jeykumar S.
later and any devm managed memory allocated during the former
aborted attempt would be leaked until the device itself was
destroyed. Since all the memory allocated during a bind
should be freed during an unbind (or bind error case) there isn't
any reason to use devm for resources that have a explicit
teardown step.
This doesn't remove devm for all resources - in particular
msm_ioremap() still uses devm_ioremap() but thats a generic
issue that can easily be addressed as a cleanup later and the
unbind code already does the requisite devm calls to unmap it.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 4 ++--
drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c | 4 +---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 10 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c| 8 +---
4 files changed, 14 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 82c55efb500f..287d4c3e58c3 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -2220,14 +2220,14 @@ struct drm_encoder *dpu_encoder_init(struct
drm_device *dev,
struct dpu_encoder_virt *dpu_enc = NULL;
int rc = 0;
- dpu_enc = devm_kzalloc(dev->dev, sizeof(*dpu_enc), GFP_KERNEL);
+ dpu_enc = kzalloc(sizeof(*dpu_enc), GFP_KERNEL);
if (!dpu_enc)
return ERR_PTR(ENOMEM);
rc = drm_encoder_init(dev, &dpu_enc->base, &dpu_encoder_funcs,
drm_enc_mode, NULL);
if (rc) {
- devm_kfree(dev->dev, dpu_enc);
+ kfree(dpu_enc);
return ERR_PTR(rc);
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c
index 89ee4b36beff..90b53e9508f2 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c
@@ -155,9 +155,7 @@ int msm_dss_parse_clock(struct platform_device
*pdev,
return 0;
}
- mp->clk_config = devm_kzalloc(&pdev->dev,
- sizeof(struct dss_clk) * num_clk,
- GFP_KERNEL);
+ mp->clk_config = kcalloc(num_clk, sizeof(struct dss_clk),
GFP_KERNEL);
if (!mp->clk_config)
return -ENOMEM;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 985c855796ae..5ac3c3f3b08d 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -1086,13 +1086,14 @@ static int dpu_bind(struct device *dev, struct
device *master, void *data)
struct dss_module_power *mp;
int ret = 0;
- dpu_kms = devm_kzalloc(&pdev->dev, sizeof(*dpu_kms), GFP_KERNEL);
+ dpu_kms = kzalloc(sizeof(*dpu_kms), GFP_KERNEL);
if (!dpu_kms)
return -ENOMEM;
mp = &dpu_kms->mp;
ret = msm_dss_parse_clock(pdev, mp);
if (ret) {
+ kfree(dpu_kms);
DPU_ERROR("failed to parse clocks, ret=%d\n", ret);
return ret;
}
@@ -1109,7 +1110,7 @@ static int dpu_bind(struct device *dev, struct
device
*master, void *data)
dpu_kms->rpm_enabled = true;
priv->kms = &dpu_kms->base;
- return ret;
+ return 0;
}
static void dpu_unbind(struct device *dev, struct device *master, void
*data)
@@ -1120,11 +1121,12 @@ static void dpu_unbind(struct device *dev,
struct
device *master, void *data)
dpu_power_resource_deinit(pdev, &dpu_kms->phandle);
msm_dss_put_clk(mp->clk_config, mp->num_clk);
- devm_kfree(&pdev->dev, mp->clk_config);
- mp->num_clk = 0;
+ kfree(mp->clk_config);
if (dpu_kms->rpm_enabled)
pm_runtime_disable(&pdev->dev);
+
+ kfree(dpu_kms);
}
static const struct component_ops dpu_ops = {
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
index 2235ef8129f4..34ab489b1a5b 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
@@ -161,7 +161,7 @@ static void dpu_mdss_destroy(struct drm_device
*dev)
free_irq(platform_get_irq(pdev, 0), dpu_mdss);
msm_dss_put_clk(mp->clk_config, mp->num_clk);
- devm_kfree(&pdev->dev, mp->clk_config);
+ kfree(mp->clk_config);
if (dpu_mdss->mmio)
Re: [PATCH v7 18/19] drm/i915/dsc: Enable and disable appropriate power wells for VDSC
On Thu, Nov 01, 2018 at 11:46:58PM -0700, Manasi Navare wrote:
> A separate power well 2 (PG2) is required for VDSC on eDP transcoder
> whereas all other transcoders use the power wells associated with the
> transcoders for VDSC.
> This patch adds a helper to obtain correct power domain depending on
> transcoder being used and enables/disables the power wells during
> VDSC enabling/disabling.
>
> v3:
> * Call it intel_dsc_power_domain, add to
> intel_ddi_get_power_domains (Ville)
> v2:
> * Fix tabs, const crtc_state, fix comments (Ville)
>
> Suggested-by: Ville Syrjala
> Cc: Ville Syrjala
> Cc: Imre Deak
> Cc: Rodrigo Vivi
> Signed-off-by: Manasi Navare
> Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_ddi.c | 3 ++-
> drivers/gpu/drm/i915/intel_drv.h | 2 ++
> drivers/gpu/drm/i915/intel_vdsc.c | 25 +
> 3 files changed, 29 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index af12c15ed94f..c243bb3f2be9 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -2124,7 +2124,8 @@ static u64 intel_ddi_get_power_domains(struct
> intel_encoder *encoder,
>*/
> if (intel_crtc_has_dp_encoder(crtc_state) ||
> intel_port_is_tc(dev_priv, encoder->port))
> - domains |= BIT_ULL(intel_ddi_main_link_aux_domain(dig_port));
> + domains |= BIT_ULL(intel_ddi_main_link_aux_domain(dig_port)) |
> + BIT_ULL(intel_dsc_power_domain(crtc_state));
if (crtc_state->something)
domains |= ...;
>
> return domains;
> }
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index e537561b3d40..2d41dff6eed1 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1859,6 +1859,8 @@ uint8_t intel_dp_dsc_get_slice_count(struct intel_dp
> *intel_dp, int mode_clock,
> /* intel_vdsc.c */
> int intel_dp_compute_dsc_params(struct intel_dp *intel_dp,
> struct intel_crtc_state *pipe_config);
> +enum intel_display_power_domain
> +intel_dsc_power_domain(const struct intel_crtc_state *crtc_state);
>
> static inline unsigned int intel_dp_unused_lane_mask(int lane_count)
> {
> diff --git a/drivers/gpu/drm/i915/intel_vdsc.c
> b/drivers/gpu/drm/i915/intel_vdsc.c
> index 219dc1517c8a..9eae037a3b4d 100644
> --- a/drivers/gpu/drm/i915/intel_vdsc.c
> +++ b/drivers/gpu/drm/i915/intel_vdsc.c
> @@ -581,6 +581,24 @@ int intel_dp_compute_dsc_params(struct intel_dp
> *intel_dp,
> return 0;
> }
>
> +enum intel_display_power_domain
> +intel_dsc_power_domain(const struct intel_crtc_state *crtc_state)
> +{
> + enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
> +
> + /*
> + * On ICL VDSC/joining for eDP transcoder uses a separate power well PW2
> + * This requires POWER_DOMAIN_TRANSCODER_EDP_VDSC power domain.
> + * For any other transcoder, VDSC/joining uses the power well associated
> + * with the pipe/transcoder in use. Hence another reference on the
> + * transcoder power domain will suffice.
> + */
> + if (cpu_transcoder == TRANSCODER_EDP)
> + return POWER_DOMAIN_TRANSCODER_EDP_VDSC;
> + else
> + return POWER_DOMAIN_TRANSCODER(cpu_transcoder);
> +}
> +
> static void intel_configure_pps_for_dsc_encoder(struct intel_encoder
> *encoder,
> const struct intel_crtc_state
> *crtc_state)
> {
> @@ -1020,6 +1038,10 @@ void intel_dsc_enable(struct intel_encoder *encoder,
> if (!crtc_state->dsc_params.compression_enable)
> return;
>
> + /* Enable Power wells for VDSC/joining */
> + intel_display_power_get(dev_priv,
> + intel_dsc_power_domain(crtc_state));
> +
> intel_configure_pps_for_dsc_encoder(encoder, crtc_state);
>
> intel_dp_write_dsc_pps_sdp(encoder, crtc_state);
> @@ -1072,4 +1094,7 @@ void intel_dsc_disable(const struct intel_crtc_state
> *old_crtc_state)
> RIGHT_BRANCH_VDSC_ENABLE);
> I915_WRITE(dss_ctl2_reg, dss_ctl2_val);
>
> + /* Disable Power wells for VDSC/joining */
> + intel_display_power_put(dev_priv,
> + intel_dsc_power_domain(old_crtc_state));
> }
> --
> 2.18.0
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 13/19] drm/i915/dp: Configure i915 Picture parameter Set registers during DSC enabling
On Thu, Nov 01, 2018 at 11:46:53PM -0700, Manasi Navare wrote:
> After encoder->pre_enable() hook, after link training sequence is
> completed, PPS registers for DSC encoder are configured using the
> DSC state parameters in intel_crtc_state as part of DSC enabling
> routine in the source. DSC enabling routine is called after
> encoder->pre_enable() before enbaling the pipe and after
> compression is enabled on the sink.
>
> v5:
> * make crtc_state const (Ville)
> v4:
> * Use cpu_transcoder instead of encoder->type for using EDP transcoder
> DSC registers(Ville)
> * Keep all PSS regs together (Anusha)
>
> v3:
> * Configure Pic_width/2 for each VDSC engine when two VDSC engines per pipe
> are used (Manasi)
> * Add DSC slice_row_per_frame in PPS16 (Manasi)
>
> v2:
> * Enable PG2 power well for VDSC on eDP
>
> Cc: Jani Nikula
> Cc: Ville Syrjala
> Cc: Anusha Srivatsa
> Signed-off-by: Manasi Navare
> Reviewed-by: Anusha Srivatsa
> ---
> drivers/gpu/drm/i915/i915_drv.h | 2 +
> drivers/gpu/drm/i915/intel_display.c | 6 +
> drivers/gpu/drm/i915/intel_vdsc.c| 419 +++
> 3 files changed, 427 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index d7797a41c648..f347d0d7b9eb 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3485,6 +3485,8 @@ extern void intel_rps_mark_interactive(struct
> drm_i915_private *i915,
> bool interactive);
> extern bool intel_set_memory_cxsr(struct drm_i915_private *dev_priv,
> bool enable);
> +extern void intel_dsc_enable(struct intel_encoder *encoder,
> + const struct intel_crtc_state *crtc_state);
>
> int i915_reg_read_ioctl(struct drm_device *dev, void *data,
> struct drm_file *file);
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 477e53c37353..2e96e2004831 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -5417,6 +5417,12 @@ static void intel_encoders_pre_enable(struct drm_crtc
> *crtc,
>
> if (encoder->pre_enable)
> encoder->pre_enable(encoder, crtc_state, conn_state);
> +
> + /*
> + * Enable and Configure Display Stream Compression in the source
> + * if enabled in intel_crtc_state.
> + */
> + intel_dsc_enable(encoder, crtc_state);
Didn't I ask for this to be moved into the pre_enable hook?
We definitely don't want it here as it would be a very suprising place
for stuff like this.
> }
> }
>
> diff --git a/drivers/gpu/drm/i915/intel_vdsc.c
> b/drivers/gpu/drm/i915/intel_vdsc.c
> index b93cb32026fa..9f80a86f95df 100644
> --- a/drivers/gpu/drm/i915/intel_vdsc.c
> +++ b/drivers/gpu/drm/i915/intel_vdsc.c
> @@ -580,3 +580,422 @@ int intel_dp_compute_dsc_params(struct intel_dp
> *intel_dp,
>
> return 0;
> }
> +
> +static void intel_configure_pps_for_dsc_encoder(struct intel_encoder
> *encoder,
> + const struct intel_crtc_state
> *crtc_state)
> +{
> + struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> + const struct drm_dsc_config *vdsc_cfg = &crtc_state->dp_dsc_cfg;
> + enum pipe pipe = crtc->pipe;
> + enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
> + u32 pps_val = 0;
> + u32 rc_buf_thresh_dword[4];
> + u32 rc_range_params_dword[8];
> + u8 num_vdsc_instances = (crtc_state->dsc_params.dsc_split) ? 2 : 1;
> + int i = 0;
> +
> + /* Populate PICTURE_PARAMETER_SET_0 registers */
> + pps_val = DSC_VER_MAJ | vdsc_cfg->dsc_version_minor <<
> + DSC_VER_MIN_SHIFT |
> + vdsc_cfg->bits_per_component << DSC_BPC_SHIFT |
> + vdsc_cfg->line_buf_depth << DSC_LINE_BUF_DEPTH_SHIFT;
> + if (vdsc_cfg->block_pred_enable)
> + pps_val |= DSC_BLOCK_PREDICTION;
> + else
> + pps_val &= ~DSC_BLOCK_PREDICTION;
> + if (vdsc_cfg->convert_rgb)
> + pps_val |= DSC_COLOR_SPACE_CONVERSION;
> + else
> + pps_val &= ~DSC_COLOR_SPACE_CONVERSION;
> + if (vdsc_cfg->enable422)
> + pps_val |= DSC_422_ENABLE;
> + else
> + pps_val &= ~DSC_422_ENABLE;
> + if (vdsc_cfg->vbr_enable)
> + pps_val |= DSC_VBR_ENABLE;
> + else
> + pps_val &= ~DSC_VBR_ENABLE;
> +
> + DRM_INFO("PPS0 = 0x%08x\n", pps_val);
> + if (cpu_transcoder == TRANSCODER_EDP) {
> + I915_WRITE(DSCA_PICTURE_PARAMETER_SET_0, pps_val);
> + /*
> + * If 2 VDSC instances are needed, configure PPS for second
> + * VDSC
> + */
> + if (crtc_state->dsc_params.dsc_split)
Re: [PATCH v7 10/19] drm/i915/dsc: Compute Rate Control parameters for DSC
On Thu, Nov 01, 2018 at 11:46:50PM -0700, Manasi Navare wrote:
> From: Gaurav K Singh
>
> This computation of RC params happens in the atomic commit phase
> during compute_config() to validate if display stream compression
> can be enabled for the requested mode.
>
> v6 (From Manasi):
> * Use 9 instead of 0x9 for consistency (Anusha)
>
> v5 (From Manasi):
> * Fix dim checkpatch warnings/checks
> v4(From Gaurav):
> * No change.Rebase on drm-tip
>
> v3 (From Gaurav):
> * Rebase on top of Manasi's latest series
> * Return -ve value in case of failure scenarios (Manasi)
>
> Fix review comments from Ville:
> * Remove unnecessary comments
> * Remove unnecessary paranthesis
> * Add comments for few RC params calculations
>
> v2 (From Manasi):
> * Rebase Gaurav's patch from intel-gfx to gfx-internal
> * Use struct drm_dsc_cfg instead of struct intel_dp
> as a parameter
>
> Cc: Manasi Navare
> Cc: Jani Nikula
> Cc: Ville Syrjala
> Signed-off-by: Gaurav K Singh
> Signed-off-by: Manasi Navare
> Reviewed-by: Anusha Srivatsa
> ---
> drivers/gpu/drm/i915/intel_vdsc.c | 127 ++
> 1 file changed, 127 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_vdsc.c
> b/drivers/gpu/drm/i915/intel_vdsc.c
> index 0a1918f2f643..b93cb32026fa 100644
> --- a/drivers/gpu/drm/i915/intel_vdsc.c
> +++ b/drivers/gpu/drm/i915/intel_vdsc.c
> @@ -317,6 +317,130 @@ static int get_column_index_for_rc_params(u8
> bits_per_component)
> }
> }
>
> +static int intel_compute_rc_parameters(struct drm_dsc_config *vdsc_cfg)
> +{
> + unsigned long groups_per_line = 0;
> + unsigned long groups_total = 0;
> + unsigned long num_extra_mux_bits = 0;
> + unsigned long slice_bits = 0;
> + unsigned long hrd_delay = 0;
> + unsigned long final_scale = 0;
> + unsigned long rbs_min = 0;
> +
> + /* Number of groups used to code each line of a slice */
> + groups_per_line = DIV_ROUND_UP(vdsc_cfg->slice_width,
> +DSC_RC_PIXELS_PER_GROUP);
> +
> + /* chunksize in Bytes */
> + vdsc_cfg->slice_chunk_size = DIV_ROUND_UP(vdsc_cfg->slice_width *
> + vdsc_cfg->bits_per_pixel,
> + (8 * 16));
> +
> + if (vdsc_cfg->convert_rgb)
> + num_extra_mux_bits = 3 * (vdsc_cfg->mux_word_size +
> + (4 * vdsc_cfg->bits_per_component + 4)
> + - 2);
> + else
> + num_extra_mux_bits = 3 * vdsc_cfg->mux_word_size +
> + (4 * vdsc_cfg->bits_per_component + 4) +
> + 2 * (4 * vdsc_cfg->bits_per_component) - 2;
> + /* Number of bits in one Slice */
> + slice_bits = 8 * vdsc_cfg->slice_chunk_size * vdsc_cfg->slice_height;
> +
> + while ((num_extra_mux_bits > 0) &&
> +((slice_bits - num_extra_mux_bits) % vdsc_cfg->mux_word_size))
> + num_extra_mux_bits--;
> +
> + if (groups_per_line < vdsc_cfg->initial_scale_value - 8)
> + vdsc_cfg->initial_scale_value = groups_per_line + 8;
> +
> + /* scale_decrement_interval calculation according to DSC spec 1.11 */
> + if (vdsc_cfg->initial_scale_value > 8)
> + vdsc_cfg->scale_decrement_interval = groups_per_line /
> + (vdsc_cfg->initial_scale_value - 8);
> + else
> + vdsc_cfg->scale_decrement_interval =
> DSC_SCALE_DECREMENT_INTERVAL_MAX;
> +
> + vdsc_cfg->final_offset = vdsc_cfg->rc_model_size -
> + (vdsc_cfg->initial_xmit_delay *
> + vdsc_cfg->bits_per_pixel + 8) / 16 + num_extra_mux_bits;
> +
> + if (vdsc_cfg->final_offset >= vdsc_cfg->rc_model_size) {
> + DRM_ERROR("FinalOfs < RcModelSze for this InitialXmitDelay\n");
More DRM_ERROR()s. Can the user trigger these?
> + return -EINVAL;
> + }
> +
> + final_scale = (vdsc_cfg->rc_model_size * 8) /
> + (vdsc_cfg->rc_model_size - vdsc_cfg->final_offset);
> + if (vdsc_cfg->slice_height > 1)
> + /*
> + * NflBpgOffset is 16 bit value with 11 fractional bits
> + * hence we multiply by 2^11 for preserving the
> + * fractional part
> + */
> + vdsc_cfg->nfl_bpg_offset =
> DIV_ROUND_UP((vdsc_cfg->first_line_bpg_offset << 11),
> + (vdsc_cfg->slice_height
> - 1));
> + else
> + vdsc_cfg->nfl_bpg_offset = 0;
> +
> + /* 2^16 - 1 */
> + if (vdsc_cfg->nfl_bpg_offset > 65535) {
> + DRM_ERROR("NflBpgOffset is too large for this slice height\n");
> + return -EINVAL;
> + }
> +
> + /* Number of groups used to code the entire slice */
> + groups_total = groups_per_line * vdsc_cfg->slice_height;
> +
> + /* slice_bpg_offset is 16 bit value with 11 fractional bits */
> + vdsc_cfg->slice_
Re: [PATCH v7 09/19] drm/i915/dsc: Define & Compute VESA DSC params
On Thu, Nov 01, 2018 at 11:46:49PM -0700, Manasi Navare wrote:
> From: Gaurav K Singh
>
> This patches does the following:
>
> 1. This patch defines all the DSC parameters as per the VESA
> DSC specification. These are stored in the encoder and used
> to compute the PPS parameters to be sent to the Sink.
> 2. Compute all the DSC parameters which are derived from DSC
> state of intel_crtc_state.
> 3. Compute all parameters that are VESA DSC specific
>
> This computation happens in the atomic check phase during
> compute_config() to validate if display stream compression
> can be enabled for the requested mode.
>
> v7: (From Manasi)
> * Dont use signed int for rc_range_params (Manasi)
> * Mask the range_bpg_offset to use only 6 bits
> * Add SPDX identifier (Chris Wilson)
> v6 (From Manasi):
> * Add a check for line_buf_depth return value (Anusha)
> * Remove DRM DSC constants to different patch (Manasi)
> v5 (From Manasi):
> * Add logic to limit the max line buf depth for DSC 1.1 to 13
> as per DSC 1.1 spec
> * Fix dim checkpatch warnings/checks
>
> v4 (From Gaurav):
> * Rebase on latest drm tip
> * rename variable name(Manasi)
> * Populate linebuf_depth variable(Manasi)
>
> v3 (From Gaurav):
> * Rebase my previous patches on top of Manasi's latest patch
> series
> * Using >>n rather than /2^n (Manasi)
> * Change the commit message to explain what the patch is doing(Gaurav)
>
> Fixed review comments from Ville:
> * Don't use macro TWOS_COMPLEMENT
> * Mention in comment about the source of RC params
> * Return directly from case statements
> * Using single asssignment for assigning rc_range_params
> * Using < about the fixed point numbers
>
> v2 (From Manasi):
> * Update logic for minor version to consider the dpcd value
> and what supported by the HW platform
> * Use DRM DSC config struct instead of intel_dp struct
> * Move the DSC constants to DRM DSC header file
> * Use u16, u8 where bigger data types not needed
> * * Compute the DSC parameters as part of DSC compute config
> since the computation can fail (Manasi)
>
> Cc: Jani Nikula
> Cc: Ville Syrjala
> Cc: Anusha Srivatsa
> Cc: Gaurav K Singh
> Signed-off-by: Gaurav K Singh
> Signed-off-by: Manasi Navare
> Co-developed-by: Manasi Navare
> Reviewed-by: Anusha Srivatsa
> ---
> drivers/gpu/drm/i915/Makefile | 3 +-
> drivers/gpu/drm/i915/intel_dp.c | 7 +
> drivers/gpu/drm/i915/intel_drv.h | 4 +
> drivers/gpu/drm/i915/intel_vdsc.c | 455 ++
> include/drm/drm_dp_helper.h | 3 +
> 5 files changed, 471 insertions(+), 1 deletion(-)
> create mode 100644 drivers/gpu/drm/i915/intel_vdsc.c
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 28c7d7884e88..a51a9ae0f496 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -156,7 +156,8 @@ i915-y += dvo_ch7017.o \
> intel_sdvo.o \
> intel_tv.o \
> vlv_dsi.o \
> - vlv_dsi_pll.o
> + vlv_dsi_pll.o \
> + intel_vdsc.o
>
> # Post-mortem debug and GPU hang state capture
> i915-$(CONFIG_DRM_I915_CAPTURE_ERROR) += i915_gpu_error.o
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 1b10e27b3e2b..13891890d041 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -2069,6 +2069,13 @@ static bool intel_dp_dsc_compute_config(struct
> intel_dp *intel_dp,
> return false;
> }
> }
> + if (intel_dp_compute_dsc_params(intel_dp, pipe_config) < 0) {
> + DRM_ERROR("Cannot compute valid DSC parameters for Input Bpp =
> %d"
Is this something that can't happen ever? If not this needs to be
DRM_DEBUG_KMS().
> + "Compressed BPP = %d\n",
> + pipe_config->pipe_bpp,
> + pipe_config->dsc_params.compressed_bpp);
> + return false;
> + }
> pipe_config->dsc_params.compression_enable = true;
> DRM_DEBUG_KMS("DP DSC computed with Input Bpp = %d "
> "Compressed Bpp = %d Slice Count = %d\n",
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 491872353cf0..3b57146766bb 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1853,6 +1853,10 @@ uint16_t intel_dp_dsc_get_output_bpp(int link_clock,
> uint8_t lane_count,
> uint8_t intel_dp_dsc_get_slice_count(struct intel_dp *intel_dp, int
> mode_clock,
>int mode_hdisplay);
>
> +/* intel_vdsc.c */
> +int intel_dp_compute_dsc_params(struct intel_dp *intel_dp,
> + struct intel_crtc_state *pipe_config);
> +
> static inline unsigned int intel_dp_unused_lane_mask(int lane_count)
> {
> return ~((1 << lane_count) - 1) & 0xf;
> diff --git a/drivers/gpu/drm/i915/intel_vdsc.c
> b/drivers/gpu/drm/i915/intel_vdsc.c
> new file mode 100644
Re: [PATCH v7 07/19] drm/i915/dp: Do not enable PSR2 if DSC is enabled
On Thu, Nov 01, 2018 at 11:46:47PM -0700, Manasi Navare wrote:
> If a eDP panel supports both PSR2 and VDSC, our HW cannot
> support both at a time. Give priority to PSR2 if a requested
> resolution can be supported without compression else enable
> VDSC and keep PSR2 disabled.
>
> v3:
> * Rebase
> v2:
> * Add warning for DSC and PSR2 enabled together (DK)
>
> Cc: Rodrigo Vivi
> Cc: Jani Nikula
> Cc: Ville Syrjälä
> Signed-off-by: Manasi Navare
> Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/intel_psr.c | 16 +---
> 1 file changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_psr.c
> b/drivers/gpu/drm/i915/intel_psr.c
> index bc2d88313ed0..8f063e1e2fb2 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -71,9 +71,9 @@ static bool psr_global_enabled(u32 debug)
> static bool intel_psr2_enabled(struct drm_i915_private *dev_priv,
> const struct intel_crtc_state *crtc_state)
> {
> - /* Disable PSR2 by default for all platforms */
> - if (i915_modparams.enable_psr == -1)
> - return false;
That seems unrelated to DSC?
> + /* Cannot enable DSC and PSR2 simultaneously */
> + WARN_ON(crtc_state->dsc_params.compression_enable &&
> + crtc_state->has_psr2);
>
> switch (dev_priv->psr.debug & I915_PSR_DEBUG_MODE_MASK) {
> case I915_PSR_DEBUG_FORCE_PSR1:
> @@ -463,6 +463,16 @@ static bool intel_psr2_config_valid(struct intel_dp
> *intel_dp,
> if (!dev_priv->psr.sink_psr2_support)
> return false;
>
> + /*
> + * DSC and PSR2 cannot be enabled simultaneously. If a requested
> + * resolution requires DSC to be enabled, priority is given to DSC
> + * over PSR2.
> + */
> + if (crtc_state->dsc_params.compression_enable) {
> + DRM_DEBUG_KMS("PSR2 cannot be enabled since DSC is enabled\n");
> + return false;
> + }
> +
> if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv)) {
> psr_max_h = 4096;
> psr_max_v = 2304;
> --
> 2.18.0
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 06/19] drm/i915/dp: Compute DSC pipe config in atomic check
On Thu, Nov 01, 2018 at 11:46:46PM -0700, Manasi Navare wrote:
> DSC params like the enable, compressed bpp, slice count and
> dsc_split are added to the intel_crtc_state. These parameters
> are set based on the requested mode and available link parameters
> during the pipe configuration in atomic check phase.
> These values are then later used to populate the remaining DSC
> and RC parameters before enbaling DSC in atomic commit.
>
> v10:
> * Add a helper for dp_dsc support (Ville)
> * Set pipe_config to max bpp, link params for DSC for now (Ville)
> * Compute bpp - use dp dsc support helper (Ville)
> v9:
> * Rebase on top of drm-tip that now uses fast_narrow config
> for edp (Manasi)
> v8:
> * Check for DSC bpc not 0 (manasi)
>
> v7:
> * Fix indentation in compute_m_n (Manasi)
>
> v6 (From Gaurav):
> * Remove function call of intel_dp_compute_dsc_params() and
> invoke intel_dp_compute_dsc_params() in the patch where
> it is defined to fix compilation warning (Gaurav)
>
> v5:
> Add drm_dsc_cfg in intel_crtc_state (Manasi)
>
> v4:
> * Rebase on refactoring of intel_dp_compute_config on tip (Manasi)
> * Add a comment why we need to check PSR while enabling DSC (Gaurav)
>
> v3:
> * Check PPR > max_cdclock to use 2 VDSC instances (Ville)
>
> v2:
> * Add if-else for eDP/DP (Gaurav)
>
> Cc: Jani Nikula
> Cc: Ville Syrjala
> Cc: Anusha Srivatsa
> Cc: Gaurav K Singh
> Signed-off-by: Manasi Navare
> Reviewed-by: Anusha Srivatsa
> Acked-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_display.c | 20 +++-
> drivers/gpu/drm/i915/intel_display.h | 3 +-
> drivers/gpu/drm/i915/intel_dp.c | 172 +++
> drivers/gpu/drm/i915/intel_dp_mst.c | 2 +-
> 4 files changed, 167 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index b219d5858160..477e53c37353 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -6442,7 +6442,7 @@ static int ironlake_fdi_compute_config(struct
> intel_crtc *intel_crtc,
>
> pipe_config->fdi_lanes = lane;
>
> - intel_link_compute_m_n(pipe_config->pipe_bpp, lane, fdi_dotclock,
> + intel_link_compute_m_n(pipe_config->pipe_bpp, 0, lane, fdi_dotclock,
> link_bw, &pipe_config->fdi_m_n, false);
>
> ret = ironlake_check_fdi_lanes(dev, intel_crtc->pipe, pipe_config);
> @@ -6679,17 +6679,25 @@ static void compute_m_n(unsigned int m, unsigned int
> n,
> }
>
> void
> -intel_link_compute_m_n(int bits_per_pixel, int nlanes,
> +intel_link_compute_m_n(int bits_per_pixel, uint16_t compressed_bpp,
> +int nlanes,
> int pixel_clock, int link_clock,
> struct intel_link_m_n *m_n,
> bool constant_n)
> {
> m_n->tu = 64;
>
> - compute_m_n(bits_per_pixel * pixel_clock,
> - link_clock * nlanes * 8,
> - &m_n->gmch_m, &m_n->gmch_n,
> - constant_n);
> + /* For DSC, Data M/N calculation uses compressed BPP */
> + if (compressed_bpp)
> + compute_m_n(compressed_bpp * pixel_clock,
> + link_clock * nlanes * 8,
> + &m_n->gmch_m, &m_n->gmch_n,
> + constant_n);
> + else
> + compute_m_n(bits_per_pixel * pixel_clock,
> + link_clock * nlanes * 8,
> + &m_n->gmch_m, &m_n->gmch_n,
> + constant_n);
>
> compute_m_n(pixel_clock, link_clock,
> &m_n->link_m, &m_n->link_n,
> diff --git a/drivers/gpu/drm/i915/intel_display.h
> b/drivers/gpu/drm/i915/intel_display.h
> index 5d50decbcbb5..b0b23e1e9392 100644
> --- a/drivers/gpu/drm/i915/intel_display.h
> +++ b/drivers/gpu/drm/i915/intel_display.h
> @@ -407,7 +407,8 @@ struct intel_link_m_n {
>(__i)++) \
> for_each_if(plane)
>
> -void intel_link_compute_m_n(int bpp, int nlanes,
> +void intel_link_compute_m_n(int bpp, uint16_t compressed_bpp,
> + int nlanes,
> int pixel_clock, int link_clock,
> struct intel_link_m_n *m_n,
> bool constant_n);
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index b39b4bda8e40..1b10e27b3e2b 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -47,6 +47,8 @@
>
> /* DP DSC small joiner has 2 FIFOs each of 640 x 6 bytes */
> #define DP_DSC_MAX_SMALL_JOINER_RAM_BUFFER 61440
> +#define DP_DSC_MIN_SUPPORTED_BPC 8
> +#define DP_DSC_MAX_SUPPORTED_BPC 10
>
> /* DP DSC throughput values used for slice count calculations KPixels/s */
> #define DP_DSC_PEAK_PIXEL_RATE 272
> @@ -1840,6 +1842,29 @@ struct link_config_limits {
> int min_bpp,
Re: [PATCH 2/3] drm/file: Uncompact the feature flags
Quoting Daniel Vetter (2018-11-02 13:25:42) > This essentially undoes > > commit 39868bd7668bd47308b1dfd97c212757caee764f > Author: Chris Wilson > Date: Tue Oct 29 08:55:58 2013 + > > drm: Compact booleans within struct drm_file > > We do lockless access to these flags everywhere, and it's kinda not a > great idea to mix lockless and bitfields. Aside from that gcc isn't > generating great code for these. > > If this ever becomes an issue size-wise, I think we need atomic_t here > and atomic bitflag ops. (you don't need atomic_t to use atomic bitflag ops, more so since the bit ops work on unsigned long!) > Cc: Chris Wilson > Cc: David Herrmann > Cc: Dave Airlie > Signed-off-by: Daniel Vetter A bit of a nuisance since bools are not well specified in terms of alignment and size, so the growth is as bad as you would expect, and if atomic access to these individual members was strictly required we would already be up the proverbial creek. Acked-by: Chris Wilson -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108507] [rv790] Broken ground textures in World of Tanks
https://bugs.freedesktop.org/show_bug.cgi?id=108507 --- Comment #6 from Vladimir Usikov --- Hello? Is there anybody in there? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/panel: simple: Add Ampire am800480b3tmqw
Hi Adam
On Thu, Nov 01, 2018 at 07:51:38AM -0500, Adam Ford wrote:
> This adds support for the Ampire am800480b3tmqw display,
> a 7" 24-bit RGB panel wtih 800x480 resolution.
>
> Signed-off-by: Adam Ford
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c
> b/drivers/gpu/drm/panel/panel-simple.c
> index 97964f7f2ace..71e878f63c5b 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -436,6 +436,31 @@ static const struct panel_desc ampire_am800480r3tmqwa1h
> = {
> .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
> };
>
> +static const struct drm_display_mode ampire_am800480b3tmqw_mode = {
> + .clock = 3,
> + .hdisplay = 800,
> + .hsync_start = 800 + 210,
> + .hsync_end = 800 + 210 + 46,
> + .htotal = 800 + 210 + 46 + 0,
> + .vdisplay = 480,
> + .vsync_start = 480 + 22,
> + .vsync_end = 480 + 22 + 23,
> + .vtotal = 480 + 22 + 23 + 0,
> + .vrefresh = 60,
> + .flags = DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC,
> +};
+1 to see .flags specified
> +
> +static const struct panel_desc ampire_am800480b3tmqw = {
> + .modes = &ire_am800480b3tmqw_mode,
> + .num_modes = 1,
> + .bpc = 6,
> + .size = {
> + .width = 152,
> + .height = 91,
> + },
> + .bus_format = MEDIA_BUS_FMT_RBG888_1X24,
> +};
Likewise good to see .bus_format specified.
But .bus_flags are not specified.
From the header file:
#define DRM_BUS_FLAG_DE_LOW (1<<0)
#define DRM_BUS_FLAG_DE_HIGH(1<<1)
/* drive data on pos. edge */
#define DRM_BUS_FLAG_PIXDATA_POSEDGE(1<<2)
/* drive data on neg. edge */
#define DRM_BUS_FLAG_PIXDATA_NEGEDGE(1<<3)
/* data is transmitted MSB to LSB on the bus */
#define DRM_BUS_FLAG_DATA_MSB_TO_LSB(1<<4)
/* data is transmitted LSB to MSB on the bus */
#define DRM_BUS_FLAG_DATA_LSB_TO_MSB(1<<5)
/* drive sync on pos. edge */
#define DRM_BUS_FLAG_SYNC_POSEDGE (1<<6)
/* drive sync on neg. edge */
#define DRM_BUS_FLAG_SYNC_NEGEDGE (1<<7)
/**
* @bus_flags: Additional information (like pixel signal polarity) for
* the pixel data on the bus, using DRM_BUS_FLAGS\_ defines.
*/
u32 bus_flags;
<
Many panels leave out .bus_flags - and I wonder if this is
because default is OK or because most other panels does so.
I had problems with my display that the text looked blurred
when bus_flags was no specified (using defaults).
This was one issue I had when migrating from 4.4 kernel
to a recent kernel.
So therefore it would good to have .bus_flags specified too
if for nothing else then for documentation purposes.
Sam
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2 v4] drm/panel: Add a driver for the TPO TPG110
Hi Linus
On Thu, Nov 01, 2018 at 10:32:56PM +0100, Linus Walleij wrote:
> The TPO (Toppoly) TPG110 is a pretty generic display driver
> similar in vein to the Ilitek 93xx devices. It is not a panel
> per se but a driver used with several low-cost noname panels.
>
> This is used on the Nomadik NHK15 combined with a OSD
> OSD057VA01CT display for WVGA 800x480.
>
> The driver is pretty minimalistic right now but can be
> extended to handle non-default polarities, gamma correction
> etc.
>
> The driver is based on the baked-in code in
> drivers/video/fbdev/amba-clcd-nomadik.c which will be
> decomissioned once this us upstream.
>
> Signed-off-by: Linus Walleij
> ---
> ChangeLog v3->v4:
> - Tag on the SPI_3WIRE_HIZ flag to the SPI slave mode.
> ChangeLog v2->v3:
> - Rewrite as an SPI child device.
> ---
> MAINTAINERS | 7 +
> drivers/gpu/drm/panel/Kconfig| 10 +
> drivers/gpu/drm/panel/Makefile | 1 +
> drivers/gpu/drm/panel/panel-tpo-tpg110.c | 506 +++
> 4 files changed, 524 insertions(+)
> create mode 100644 drivers/gpu/drm/panel/panel-tpo-tpg110.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 690c2f68a401..c3ca56c2a7a6 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4746,6 +4746,13 @@ DRM DRIVER FOR TDFX VIDEO CARDS
> S: Orphan / Obsolete
> F: drivers/gpu/drm/tdfx/
>
> +DRM DRIVER FOR TPO TPG110 PANELS
> +M: Linus Walleij
> +T: git git://anongit.freedesktop.org/drm/drm-misc
> +S: Maintained
> +F: drivers/gpu/drm/panel/panel-tpo-tpg110.c
> +F: Documentation/devicetree/bindings/display/panel/tpo,tpg110.txt
> +
> DRM DRIVER FOR USB DISPLAYLINK VIDEO ADAPTERS
> M: Dave Airlie
> R: Sean Paul
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index 6020c30a33b3..b2c8b02894b1 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -186,4 +186,14 @@ config DRM_PANEL_SITRONIX_ST7789V
> Say Y here if you want to enable support for the Sitronix
> ST7789V controller for 240x320 LCD panels
>
> +config DRM_PANEL_TPO_TPG110
> + tristate "TPO TPG 800x400 panel"
> + depends on OF && SPI && GPIOLIB
> + depends on BACKLIGHT_CLASS_DEVICE
> + select VIDEOMODE_HELPERS
> + help
> + Say Y here if you want to enable support for TPO TPG110
> + 400CH LTPS TFT LCD Single Chip Digital Driver for up to
> + 800x400 LCD panels.
> +
> endmenu
> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> index 5ccaaa9d13af..9b3a0629d255 100644
> --- a/drivers/gpu/drm/panel/Makefile
> +++ b/drivers/gpu/drm/panel/Makefile
> @@ -19,3 +19,4 @@ obj-$(CONFIG_DRM_PANEL_SEIKO_43WVF1G) +=
> panel-seiko-43wvf1g.o
> obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
> obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
> obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o
> +obj-$(CONFIG_DRM_PANEL_TPO_TPG110) += panel-tpo-tpg110.o
> diff --git a/drivers/gpu/drm/panel/panel-tpo-tpg110.c
> b/drivers/gpu/drm/panel/panel-tpo-tpg110.c
> new file mode 100644
> index ..8e517ea5e73b
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-tpo-tpg110.c
> @@ -0,0 +1,506 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Panel driver for the TPO TPG110 400CH LTPS TFT LCD Single Chip
> + * Digital Driver.
> + *
> + * This chip drives a TFT LCD, so it does not know what kind of
> + * display is actually connected to it, so the width and height of that
> + * display needs to be supplied from the machine configuration.
> + *
> + * Author:
> + * Linus Walleij
> + */
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +
> +#define TPG110_TEST 0x00
> +#define TPG110_CHIPID0x01
> +#define TPG110_CTRL1 0x02
> +#define TPG110_RES_MASK GENMASK(2, 0)
> +#define TPG110_RES_800X480 0x07
> +#define TPG110_RES_640X480 0x06
> +#define TPG110_RES_480X272 0x05
> +#define TPG110_RES_480X640 0x04
> +#define TPG110_RES_480X272_D 0x01 /* Dual scan: outputs 800x480 */
> +#define TPG110_RES_400X240_D 0x00 /* Dual scan: outputs 800x480 */
> +#define TPG110_CTRL2 0x03
> +#define TPG110_CTRL2_PM BIT(0)
> +#define TPG110_CTRL2_RES_PM_CTRL BIT(7)
> +
> +/**
> + * struct tpg110_panel_mode - lookup struct for the supported modes
> + */
> +struct tpg110_panel_mode {
> + /**
> + * @name: the name of this panel
> + */
> + const char *name;
> + /**
> + * @magic: the magic value from the detection register
> + */
> + u32 magic;
> + /**
> + * @mode: the DRM display mode for this panel
> + */
> + struct drm_display_mode mode;
> + /**
>
RE: [RFC] drm/bridge/sii902x: Fix EDID readback
Hello Peter, Thank you for your feedback! > Subject: Re: [RFC] drm/bridge/sii902x: Fix EDID readback snip > > > > To further detail the problem, the system is vulnerable from before the > > last write > > performed by sii902x_i2c_bypass_select to after we confirm we need the > > switch > > to be closed within sii902x_i2c_bypass_deselect, that's the minimum amount > > of time > > we could keep the parent adapter locked for, I guess I am stuck with a > > parent-locking > > architecture, aren't I? > > If that problem description is correct, then yes, I think the *only* solution > is to combine the three parts "open bypass mode", "edid xfer" and "close > bypass > mode", and to keep the i2c adapter locked during the procedure so that other > xfers do not creep in and crap thing up from the side. And one way to combine > the three parts is to use a parent-locked i2c gate. And since you need to keep > the i2c adapter locked over the whole procedure, you need to use unlocked > xfers > (as you have already discovered). But how do you know that this problem > description is accurate? I basically observed what was going on on the bus (with a logic analyser) while generating traffic on the parent adapter > Why is it not ok for unrelated xfers to creep in > between opening the bypass mode and the edid xfer, and how do you know that > this is not ok? Because those transfers would come with no extra delay between STOP and START conditions while the HDMI transmitter is in passthrough mode > > > But I guess I could release it when it's not actually needed, > > How would you figure out when it's not needed? The moment you tell the HDMI transmitter you are going to talk to the monitor nothing else can flow on the bus, up until you gracefully close the pass through session, which means I wouldn't really need to hold the parent lock during the entire duration of the select callback, I would need to hold the parent lock only from before the last write as that's when we tell the HDMI transmitter to activate the passthrough mode, but I guess it would make the driver hard to maintain (as in others would need to understand this properly before making any changes), wouldn't it? > > > or is this going to be a pain to maintain? Shall I just keep going with the > > parent-locking > > but using bare i2c transactions only within select and deselect and leave > > regmap > > to deal with everything else? > > That's a possibility. Take care to not mess up any cached state in regmap > though. The original version of the driver wasn't using any caching, so I guess I would need to fallback exactly to the same implementation. So, what should I do? Should I keep the parent-locking, the unlocked flavours of rd/wr/rmw from within select/deselect, and put back regmap based rd/wr/rmw with no caching for everything else? Thank you! Fab > The registers you touch from select/deselect should probably be volatile or > something like that? > > Cheers, > Peter Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge/sii902x: Fix EDID readback
On 2018-11-02 13:13, Fabrizio Castro wrote:
> While adding SiI9022A support to the iwg23s board, it came
> up that when the HDMI transmitter is in pass through mode the
> device is not compliant with the I2C specification anymore,
> as it requires a far bigger tbuf, due to a delay the HDMI
> transmitter is adding when relaying the STOP condition on the
> monitor i2c side of things.
>
> When not providing an appropriate delay after the STOP condition
> the i2c bus would get stuck. Also, any other traffic on the bus
> while talking to the monitor may cause the transaction to fail
> or even cause issues with the i2c bus as well.
>
> I2c-gates seemed to reach consent as a possible way to address
> these issues, and as such this patch is implementing a solution
> based on that. Since others are clearly relying on the current
> implementation of the driver, this patch won't require any DT
> changes.
>
> Since we don't want any interference during the DDC Bus
> Request/Grant procedure and while talking to the monitor, we
> have to use the adapter locking primitives rather than the
> i2c-mux locking primitives.
>
> Signed-off-by: Fabrizio Castro
> ---
> RFC->PATCH:
> * Incorporated Linus Walleij, Peter Rosin, and Mark Brown comments
>
> Thank you guys
>
> drivers/gpu/drm/bridge/sii902x.c | 264
> +--
> 1 file changed, 196 insertions(+), 68 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/sii902x.c
> b/drivers/gpu/drm/bridge/sii902x.c
> index e59a135..4f9d9c7 100644
> --- a/drivers/gpu/drm/bridge/sii902x.c
> +++ b/drivers/gpu/drm/bridge/sii902x.c
> @@ -1,4 +1,6 @@
> /*
> + * Copyright (C) 2018 Renesas Electronics
> + *
> * Copyright (C) 2016 Atmel
> * Bo Shen
> *
> @@ -21,6 +23,7 @@
> */
>
> #include
> +#include
> #include
> #include
> #include
> @@ -86,8 +89,68 @@ struct sii902x {
> struct drm_bridge bridge;
> struct drm_connector connector;
> struct gpio_desc *reset_gpio;
> + struct i2c_mux_core *i2cmux;
> };
>
> +static int sii902x_read_unlocked(struct i2c_client *i2c, u8 reg, u8 *val)
> +{
> + struct i2c_msg xfer[] = {
> + {
> + .addr = i2c->addr,
> + .flags = 0,
> + .len = 1,
> + .buf = ®,
> + }, {
> + .addr = i2c->addr,
> + .flags = I2C_M_RD,
> + .len = 1,
> + .buf = val,
> + }
> + };
> + unsigned char xfers = ARRAY_SIZE(xfer);
> + int ret, retries = 5;
> +
> + do {
> + ret = __i2c_transfer(i2c->adapter, xfer, xfers);
> + if (ret < 0)
> + return ret;
> + } while (ret != xfers && --retries);
> + return ret == xfers ? 0 : -1;
> +}
> +
> +static int sii902x_write_unlocked(struct i2c_client *i2c, u8 reg, u8 val)
> +{
> + u8 data[2] = {reg, val};
> + struct i2c_msg xfer = {
> + .addr = i2c->addr,
> + .flags = 0,
> + .len = sizeof(data),
> + .buf = data,
> + };
> + int ret, retries = 5;
> +
> + do {
> + ret = __i2c_transfer(i2c->adapter, &xfer, 1);
> + if (ret < 0)
> + return ret;
> + } while (!ret && --retries);
> + return !ret ? -1 : 0;
> +}
> +
> +static int sii902x_update_bits_unlocked(struct i2c_client *i2c, u8 reg, u8
> mask,
> + u8 val)
> +{
> + int ret;
> + u8 status;
> +
> + ret = sii902x_read_unlocked(i2c, reg, &status);
> + if (ret)
> + return ret;
> + status &= ~mask;
> + status |= val & mask;
> + return sii902x_write_unlocked(i2c, reg, status);
> +}
> +
> static inline struct sii902x *bridge_to_sii902x(struct drm_bridge *bridge)
> {
> return container_of(bridge, struct sii902x, bridge);
> @@ -135,41 +198,11 @@ static const struct drm_connector_funcs
> sii902x_connector_funcs = {
> static int sii902x_get_modes(struct drm_connector *connector)
> {
> struct sii902x *sii902x = connector_to_sii902x(connector);
> - struct regmap *regmap = sii902x->regmap;
> u32 bus_format = MEDIA_BUS_FMT_RGB888_1X24;
> - struct device *dev = &sii902x->i2c->dev;
> - unsigned long timeout;
> - unsigned int retries;
> - unsigned int status;
> struct edid *edid;
> - int num = 0;
> - int ret;
> -
> - ret = regmap_update_bits(regmap, SII902X_SYS_CTRL_DATA,
> - SII902X_SYS_CTRL_DDC_BUS_REQ,
> - SII902X_SYS_CTRL_DDC_BUS_REQ);
> - if (ret)
> - return ret;
> -
> - timeout = jiffies +
> - msecs_to_jiffies(SII902X_I2C_BUS_ACQUISITION_TIMEOUT_MS);
> - do {
> - ret = regmap_read(regmap, SII902X_SYS_CTRL_DATA, &status);
> - if (ret)
> - return ret;
> - } while (!(status &
Re: [PATCH 0/3] omapdrm: Fix runtime PM issues at module load and unload time
Hi, * Laurent Pinchart [181101 12:13]: > On Thursday, 1 November 2018 13:47:40 EET Tomi Valkeinen wrote: > > We do dispc_runtime_get/put in the HDMI driver's suspend/resume too, so > > don't we need similar hack (as you add in dsi.c) there also? > > We would if we had to access HDMI registers at probe time. With these I'm still seeing the following issue with hdmi on rmmod of omapdrm related modules as hdmi->dss is NULL in hdmi_runtime_resume. Regards, Tony 8< -- Unable to handle kernel NULL pointer dereference at virtual address 0278 ... PC is at hdmi_runtime_resume+0xc/0x1c [omapdss] LR is at __rpm_callback+0x144/0x1d8 ... (hdmi_runtime_resume [omapdss]) from [] (__rpm_callback+0x144/0x1d8) (__rpm_callback) from [] (rpm_callback+0x20/0x80) (rpm_callback) from [] (rpm_resume+0x60c/0x828) (rpm_resume) from [] (__pm_runtime_resume+0x4c/0x64) (__pm_runtime_resume) from [] (device_release_driver_internal+0x130/0x234) (device_release_driver_internal) from [] (driver_detach+0x38/0x6c) (driver_detach) from [] (bus_remove_driver+0x4c/0xa4) (bus_remove_driver) from [] (platform_unregister_drivers+0x20/0x2c) (platform_unregister_drivers) from [] (sys_delete_module+0x1c0/0x230) (sys_delete_module) from [] (ret_fast_syscall+0x0/0x28) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] drm/bridge/sii902x: Fix EDID readback
On 2018-11-01 18:32, Fabrizio Castro wrote: > Hello Peter, > > Thank you for your feedback! > >> Subject: Re: [RFC] drm/bridge/sii902x: Fix EDID readback > > snip > >>> >>> To further detail the problem, the system is vulnerable from before the >>> last write >>> performed by sii902x_i2c_bypass_select to after we confirm we need the >>> switch >>> to be closed within sii902x_i2c_bypass_deselect, that's the minimum amount >>> of time >>> we could keep the parent adapter locked for, I guess I am stuck with a >>> parent-locking >>> architecture, aren't I? >> >> If that problem description is correct, then yes, I think the *only* solution >> is to combine the three parts "open bypass mode", "edid xfer" and "close >> bypass >> mode", and to keep the i2c adapter locked during the procedure so that other >> xfers do not creep in and crap thing up from the side. And one way to combine >> the three parts is to use a parent-locked i2c gate. And since you need to >> keep >> the i2c adapter locked over the whole procedure, you need to use unlocked >> xfers >> (as you have already discovered). But how do you know that this problem >> description is accurate? > > I basically observed what was going on on the bus (with a logic analyser) > while generating > traffic on the parent adapter > >> Why is it not ok for unrelated xfers to creep in >> between opening the bypass mode and the edid xfer, and how do you know that >> this is not ok? > > Because those transfers would come with no extra delay between STOP and START > conditions while the HDMI transmitter is in passthrough mode Yeah yeah, now I get it. It's not the edid eeprom that's bad, it's the passthrough mode in the hdmi transmitter that's broken. Your problem description follows naturally. >> >>> But I guess I could release it when it's not actually needed, >> >> How would you figure out when it's not needed? > > The moment you tell the HDMI transmitter you are going to talk to the monitor > nothing else can > flow on the bus, up until you gracefully close the pass through session, > which means I wouldn't > really need to hold the parent lock during the entire duration of the select > callback, I would need > to hold the parent lock only from before the last write as that's when we > tell the HDMI transmitter > to activate the passthrough mode, but I guess it would make the driver hard > to maintain (as in > others would need to understand this properly before making any changes), > wouldn't it? Yes, that would just complicate things and would probably not have all that much benefit. I don't think I'd go there... >> >>> or is this going to be a pain to maintain? Shall I just keep going with the >>> parent-locking >>> but using bare i2c transactions only within select and deselect and leave >>> regmap >>> to deal with everything else? >> >> That's a possibility. Take care to not mess up any cached state in regmap >> though. > > The original version of the driver wasn't using any caching, so I guess I > would need to fallback > exactly to the same implementation. > > So, what should I do? Should I keep the parent-locking, the unlocked flavours > of rd/wr/rmw from > within select/deselect, and put back regmap based rd/wr/rmw with no caching > for everything else? I think that sounds like a reasonable compromise, but be careful since you still might need the two implementations to interact, e.g. the two rmw variants might still need a common lock so that they don't trample on each others toes. At least if there are accesses to the same register (SII902X_SYS_CTRL_DATA in this case if I read it right). Cheers, Peter ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] drm/bridge/sii902x: Fix EDID readback
On 2018-11-01 17:04, Fabrizio Castro wrote: > Hello Peter, > > Thank you for your feedback! > >>> The "mux-locked" implementation was the one I first tried and I discovered >>> it doesn't work for me, as other traffic on the parent adapter can get in >>> the >>> way. What we need for this device is no other traffic on the bus during the >>> "select transaction deselect" procedure, that's why I went with the parent >>> locking. Also this device needs a delay between stop and start conditions >>> while addressing the monitor. >> >> Ok, I thought the problem was that a delay was needed between the STOP >> of the command opening the gate and the START of the edid eeprom xfer, and >> that everything else worked normally. Too bad this wasn't the actual problem. >> >> Hmm. If it is indeed true that other xfers must never creep into the "select >> xfer deselect" procedure then you are indeed stuck with a parent-locking. >> But is that really the case? Could it be that the extra delay between >> STOP-START is only needed after the absolutely last xfer before the >> command closing the gate? >> >> If that problem description is correct, it should be possible to go back to >> a mux-locked gate, but then in your deselect implementation grab the i2c >> adapter >> lock manually - with i2c_lock_bus(adapter, I2C_LOCK_ROOT_ADAPTER) - before >> the >> 30 us delay, then open code the command to close the gate with an unlocked >> i2c >> access, and finally release the i2c bus lock. That way you have ensured >> silence >> on the bus for the required time before closing the gate. You would still >> need >> to bypass regmap, but only in this one place (but maybe you should bypass >> regmap for opening the gate too, for symmetry). > > To further detail the problem, the system is vulnerable from before the last > write > performed by sii902x_i2c_bypass_select to after we confirm we need the switch > to be closed within sii902x_i2c_bypass_deselect, that's the minimum amount of > time > we could keep the parent adapter locked for, I guess I am stuck with a > parent-locking > architecture, aren't I? If that problem description is correct, then yes, I think the *only* solution is to combine the three parts "open bypass mode", "edid xfer" and "close bypass mode", and to keep the i2c adapter locked during the procedure so that other xfers do not creep in and crap thing up from the side. And one way to combine the three parts is to use a parent-locked i2c gate. And since you need to keep the i2c adapter locked over the whole procedure, you need to use unlocked xfers (as you have already discovered). But how do you know that this problem description is accurate? Why is it not ok for unrelated xfers to creep in between opening the bypass mode and the edid xfer, and how do you know that this is not ok? > But I guess I could release it when it's not actually needed, How would you figure out when it's not needed? > or is this going to be a pain to maintain? Shall I just keep going with the > parent-locking > but using bare i2c transactions only within select and deselect and leave > regmap > to deal with everything else? That's a possibility. Take care to not mess up any cached state in regmap though. The registers you touch from select/deselect should probably be volatile or something like that? Cheers, Peter ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [RFC] drm/bridge/sii902x: Fix EDID readback
Hello Peter,
Thank you for your feedback!
snip
> > Yeah, there is some issue with locking here, and that's coming down
> > from the fact that when we call into drm_get_edid, we implicitly call
> > i2c_transfer which ultimately locks the i2c adapter, and then calls
> > into our sii902x_i2c_bypass_select, which in turn calls into the regmap
> > functions and therefore we try and lock the same i2c adapter again,
> > driving the system into a deadlock.
> > Having the option of using "unlocked" flavours of reads and writes
> > is what we need here, but looking at drivers/base/regmap/regmap-i2c.c
> > I couldn't find anything suitable for my case, maybe Mark could advise
> > on this one? I am sure I overlooked something here, is there a better
> > way to address this?
>
> This recursive locking problem surfaces when an i2c mux is operated
> by writing commands on the same i2c bus that is muxed. When this
> happens for a typical i2c mux chip like nxp,pca9548 this can be kept
> local to that driver. However, when there are interactions with other
> parts of the kernel (e.g. if the i2c-mux is operated by gpio pins,
> and those gpio pins in turn are operated by accesses to the i2c bus
> that is muxed) this locked vs. unlocked thing would spread like
> wildfire.
>
> Since I did not like that wildfire, I came up with the "mux-locked"
> scheme. It is not appropriate everywhere, but in this case I think it
> is a perfect fit. By using it, you should be able to dodge all locking
> issues and it should be possible to keep the regmap usage as-is and the
> patch would in all likelihood be much less intrusive.
>
> For some background on "mux-locked" vs. "parent-locked" (which is what
> you have used in this RFC patch), see Documentation/i2c/i2c-topology.
The "mux-locked" implementation was the one I first tried and I discovered
it doesn't work for me, as other traffic on the parent adapter can get in the
way. What we need for this device is no other traffic on the bus during the
"select transaction deselect" procedure, that's why I went with the parent
locking. Also this device needs a delay between stop and start conditions
while addressing the monitor.
>
> There are a couple of more comments below, inline.
>
snip
> >>>
> >>> +static int sii902x_i2c_bypass_select(struct i2c_mux_core *mux, u32
> >>> chan_id)
> >>> +{
> >>> + struct sii902x *sii902x = i2c_mux_priv(mux);
> >>> + struct device *dev = &sii902x->i2c->dev;
> >>> + unsigned long timeout;
> >>> + u8 status;
> >>> + int ret;
> >>> +
> >>> + ret = __sii902x_update_bits(sii902x->i2c, SII902X_SYS_CTRL_DATA,
> >>> + SII902X_SYS_CTRL_DDC_BUS_REQ,
> >>> + SII902X_SYS_CTRL_DDC_BUS_REQ);
> >>> +
> >>> + timeout = jiffies +
> >>> +
> >>> msecs_to_jiffies(SII902X_I2C_BUS_ACQUISITION_TIMEOUT_MS);
> >>> + do {
> >>> + ret = __sii902x_read(sii902x->i2c, SII902X_SYS_CTRL_DATA,
> >>> +&status);
> >>> + if (ret)
> >>> + return ret;
> >>> + } while (!(status & SII902X_SYS_CTRL_DDC_BUS_GRTD) &&
> >>> +time_before(jiffies, timeout));
> >>> +
> >>> + if (!(status & SII902X_SYS_CTRL_DDC_BUS_GRTD)) {
> >>> + dev_err(dev, "Failed to acquire the i2c bus\n");
> >>> + return -ETIMEDOUT;
> >>> + }
> >>> +
> >>> + ret = __sii902x_write(sii902x->i2c, SII902X_SYS_CTRL_DATA,
> >>> status);
> >>> + if (ret)
> >>> + return ret;
>
> Why do I not see a delay here? I thought the whole point of adding the i2c
> gate
> was that it enabled the introduction of a delay between opening for edid
> reading
> and the actual edid reading?
The delay is needed between STOP and START condition while in passthrough mode.
__i2c_transfer gets called after the select callback (which enables the
passthrough
mode), when __i2c_transfer is done it generates a STOP condition and then we
call into
the deselect callback. We need a delay between __i2c_transfer and deselect.
>
> >>> + return 0;
> >>> +}
> >>> +
> >>> +static int sii902x_i2c_bypass_deselect(struct i2c_mux_core *mux, u32
> >>> chan_id)
> >>> +{
> >>> + struct sii902x *sii902x = i2c_mux_priv(mux);
> >>> + struct device *dev = &sii902x->i2c->dev;
> >>> + unsigned long timeout;
> >>> + unsigned int retries;
> >>> + u8 status;
> >>> + int ret;
> >>> +
> >>> + udelay(30);
Here is where we need the delay
snip
> >>> @@ -433,6 +558,22 @@ static int sii902x_probe(struct i2c_client *client,
> >>>
> >>> i2c_set_clientdata(client, sii902x);
> >>>
> >>> + sii902x->i2cmux = i2c_mux_alloc(client->adapter, dev,
> >>> + 1, 0, I2C_MUX_GATE,
>
> Just use I2C_MUX_GATE | I2C_MUX_LOCKED for the flags argument, and you should
> be
> able to make normal i2c accesses.
[[DPU PATCH]] drm/msm/dpu: Correct dpu destroy and disable order
In case of msm drm bind failure, dpu_mdss_destroy is triggered. In this function, resources are freed and pm runtime disable is called, which triggers dpu_mdss_disable. Now in dpu_mdss_disable, driver tries to access a memory which is already freed. This results in kernel panic. Fix this by ensuring proper sequence of dpu destroy and disable calls. Change-Id: Id6e01a537ae9c40789c5752dc28c397391ab7dfe Signed-off-by: Jayant Shekhar --- drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c index fd9c893..cd9a6bd 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c @@ -156,6 +156,8 @@ static void dpu_mdss_destroy(struct drm_device *dev) struct dpu_mdss *dpu_mdss = to_dpu_mdss(priv->mdss); struct dss_module_power *mp = &dpu_mdss->mp; + pm_runtime_disable(dev->dev); + _dpu_mdss_irq_domain_fini(dpu_mdss); free_irq(platform_get_irq(pdev, 0), dpu_mdss); @@ -167,7 +169,6 @@ static void dpu_mdss_destroy(struct drm_device *dev) devm_iounmap(&pdev->dev, dpu_mdss->mmio); dpu_mdss->mmio = NULL; - pm_runtime_disable(dev->dev); priv->mdss = NULL; } -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] backlight/arcxcnn user proper vendor prefix in device tree bindings
The vendor-prefixes.txt file properly refers to ArcticSand
as "arctic" while the actual backlight driver and the
device tree bindings for it improperly use "arc". The
bindings are also modified to support newer backlight chips
in the arcxcnn family
Signed-off-by: Brian Dodge
---
.../bindings/leds/backlight/arcxcnn_bl.txt | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt
b/Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt
index 230abde..dcaa239 100644
--- a/Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt
+++ b/Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt
@@ -1,8 +1,8 @@
-Binding for ArcticSand arc2c0608 LED driver
+Binding for ArcticSand arc family LED drivers
Required properties:
-- compatible: should be "arc,arc2c0608"
-- reg: slave address
+- compatible: "arctic,arc1c0608", "arctic,arc2c0608", "arctic,arc3c0845"
+- reg: slave address
Optional properties:
- default-brightness: brightness value on boot, value from: 0-4095
@@ -11,19 +11,19 @@ Optional properties:
- led-sources: List of enabled channels from 0 to 5.
See Documentation/devicetree/bindings/leds/common.txt
-- arc,led-config-0:setting for register ILED_CONFIG_0
-- arc,led-config-1:setting for register ILED_CONFIG_1
-- arc,dim-freq:PWM mode frequence setting (bits [3:0] used)
-- arc,comp-config: setting for register CONFIG_COMP
-- arc,filter-config: setting for register FILTER_CONFIG
-- arc,trim-config: setting for register IMAXTUNE
+- arctic,led-config-0: setting for register ILED_CONFIG_0
+- arctic,led-config-1: setting for register ILED_CONFIG_1
+- arctic,dim-freq: PWM mode frequence setting (bits [3:0] used)
+- arctic,comp-config: setting for register CONFIG_COMP
+- arctic,filter-config:setting for register FILTER_CONFIG
+- arctic,trim-config: setting for register IMAXTUNE
Note: Optional properties not specified will default to values in IC EPROM
Example:
arc2c0608@30 {
- compatible = "arc,arc2c0608";
+ compatible = "arctic,arc2c0608";
reg = <0x30>;
default-brightness = <500>;
label = "lcd-backlight";
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] uapi: fix more linux/kfd_ioctl.h userspace compilation errors
Consistently use types provided by via
to fix struct kfd_ioctl_get_queue_wave_state_args userspace compilation errors.
Fixes: 5df099e8bc83f ("drm/amdkfd: Add wavefront context save state retrieval
ioctl")
Signed-off-by: Dmitry V. Levin
---
include/uapi/linux/kfd_ioctl.h | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/include/uapi/linux/kfd_ioctl.h b/include/uapi/linux/kfd_ioctl.h
index dae897f38e59..b01eb502d49c 100644
--- a/include/uapi/linux/kfd_ioctl.h
+++ b/include/uapi/linux/kfd_ioctl.h
@@ -83,11 +83,11 @@ struct kfd_ioctl_set_cu_mask_args {
};
struct kfd_ioctl_get_queue_wave_state_args {
- uint64_t ctl_stack_address; /* to KFD */
- uint32_t ctl_stack_used_size; /* from KFD */
- uint32_t save_area_used_size; /* from KFD */
- uint32_t queue_id; /* to KFD */
- uint32_t pad;
+ __u64 ctl_stack_address;/* to KFD */
+ __u32 ctl_stack_used_size; /* from KFD */
+ __u32 save_area_used_size; /* from KFD */
+ __u32 queue_id; /* to KFD */
+ __u32 pad;
};
/* For kfd_ioctl_set_memory_policy_args.default_policy and alternate_policy */
--
ldv
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/panel: simple: Add Ampire am800480b3tmqw
This adds support for the Ampire am800480b3tmqw display,
a 7" 24-bit RGB panel wtih 800x480 resolution.
Signed-off-by: Adam Ford
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 97964f7f2ace..71e878f63c5b 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -436,6 +436,31 @@ static const struct panel_desc ampire_am800480r3tmqwa1h = {
.bus_format = MEDIA_BUS_FMT_RGB666_1X18,
};
+static const struct drm_display_mode ampire_am800480b3tmqw_mode = {
+ .clock = 3,
+ .hdisplay = 800,
+ .hsync_start = 800 + 210,
+ .hsync_end = 800 + 210 + 46,
+ .htotal = 800 + 210 + 46 + 0,
+ .vdisplay = 480,
+ .vsync_start = 480 + 22,
+ .vsync_end = 480 + 22 + 23,
+ .vtotal = 480 + 22 + 23 + 0,
+ .vrefresh = 60,
+ .flags = DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC,
+};
+
+static const struct panel_desc ampire_am800480b3tmqw = {
+ .modes = &ire_am800480b3tmqw_mode,
+ .num_modes = 1,
+ .bpc = 6,
+ .size = {
+ .width = 152,
+ .height = 91,
+ },
+ .bus_format = MEDIA_BUS_FMT_RBG888_1X24,
+};
+
static const struct drm_display_mode auo_b101aw03_mode = {
.clock = 51450,
.hdisplay = 1024,
@@ -2330,6 +2355,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "ampire,am800480r3tmqwa1h",
.data = &ire_am800480r3tmqwa1h,
+ }, {
+ .compatible = "ampire,am800480b3tmqw",
+ .data = &ire_am800480b3tmqw,
}, {
.compatible = "auo,b101aw03",
.data = &auo_b101aw03,
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] backlight/arcxcnn support newer chips in arcxcnn family and fix vendor prefix
Support for ArcticSand arc1 and arc3 ships is added. Some ranges
and control paths are modified based on the chip id probed via
i2c. Also updates vendor prefix to arctic from arc which was a
mistake in the original driver submission
Signed-off-by: Brian Dodge
---
.../bindings/leds/backlight/arcxcnn_bl.txt | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt
b/Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt
index dcaa239..230abde 100644
--- a/Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt
+++ b/Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt
@@ -1,8 +1,8 @@
-Binding for ArcticSand arc family LED drivers
+Binding for ArcticSand arc2c0608 LED driver
Required properties:
-- compatible: "arctic,arc1c0608", "arctic,arc2c0608", "arctic,arc3c0845"
-- reg: slave address
+- compatible: should be "arc,arc2c0608"
+- reg: slave address
Optional properties:
- default-brightness: brightness value on boot, value from: 0-4095
@@ -11,19 +11,19 @@ Optional properties:
- led-sources: List of enabled channels from 0 to 5.
See Documentation/devicetree/bindings/leds/common.txt
-- arctic,led-config-0: setting for register ILED_CONFIG_0
-- arctic,led-config-1: setting for register ILED_CONFIG_1
-- arctic,dim-freq: PWM mode frequence setting (bits [3:0] used)
-- arctic,comp-config: setting for register CONFIG_COMP
-- arctic,filter-config:setting for register FILTER_CONFIG
-- arctic,trim-config: setting for register IMAXTUNE
+- arc,led-config-0:setting for register ILED_CONFIG_0
+- arc,led-config-1:setting for register ILED_CONFIG_1
+- arc,dim-freq:PWM mode frequence setting (bits [3:0] used)
+- arc,comp-config: setting for register CONFIG_COMP
+- arc,filter-config: setting for register FILTER_CONFIG
+- arc,trim-config: setting for register IMAXTUNE
Note: Optional properties not specified will default to values in IC EPROM
Example:
arc2c0608@30 {
- compatible = "arctic,arc2c0608";
+ compatible = "arc,arc2c0608";
reg = <0x30>;
default-brightness = <500>;
label = "lcd-backlight";
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [RFC] drm/bridge/sii902x: Fix EDID readback
Hello Peter, Again, thank you very much for your precious comments. I'll send a patch out shortly addressing all of the comments I have received so far, including yours. Cheers, Fab > Subject: Re: [RFC] drm/bridge/sii902x: Fix EDID readback > > On 2018-11-01 18:32, Fabrizio Castro wrote: > > Hello Peter, > > > > Thank you for your feedback! > > > >> Subject: Re: [RFC] drm/bridge/sii902x: Fix EDID readback > > > > snip > > > >>> > >>> To further detail the problem, the system is vulnerable from before the > >>> last write > >>> performed by sii902x_i2c_bypass_select to after we confirm we need the > >>> switch > >>> to be closed within sii902x_i2c_bypass_deselect, that's the minimum > >>> amount of time > >>> we could keep the parent adapter locked for, I guess I am stuck with a > >>> parent-locking > >>> architecture, aren't I? > >> > >> If that problem description is correct, then yes, I think the *only* > >> solution > >> is to combine the three parts "open bypass mode", "edid xfer" and "close > >> bypass > >> mode", and to keep the i2c adapter locked during the procedure so that > >> other > >> xfers do not creep in and crap thing up from the side. And one way to > >> combine > >> the three parts is to use a parent-locked i2c gate. And since you need to > >> keep > >> the i2c adapter locked over the whole procedure, you need to use unlocked > >> xfers > >> (as you have already discovered). But how do you know that this problem > >> description is accurate? > > > > I basically observed what was going on on the bus (with a logic analyser) > > while generating > > traffic on the parent adapter > > > >> Why is it not ok for unrelated xfers to creep in > >> between opening the bypass mode and the edid xfer, and how do you know that > >> this is not ok? > > > > Because those transfers would come with no extra delay between STOP and > > START > > conditions while the HDMI transmitter is in passthrough mode > > Yeah yeah, now I get it. It's not the edid eeprom that's bad, it's the > passthrough mode in the hdmi transmitter that's broken. Your problem > description follows naturally. > > >> > >>> But I guess I could release it when it's not actually needed, > >> > >> How would you figure out when it's not needed? > > > > The moment you tell the HDMI transmitter you are going to talk to the > > monitor nothing else can > > flow on the bus, up until you gracefully close the pass through session, > > which means I wouldn't > > really need to hold the parent lock during the entire duration of the > > select callback, I would need > > to hold the parent lock only from before the last write as that's when we > > tell the HDMI transmitter > > to activate the passthrough mode, but I guess it would make the driver hard > > to maintain (as in > > others would need to understand this properly before making any changes), > > wouldn't it? > > Yes, that would just complicate things and would probably not have all that > much benefit. I don't think I'd go there... > > >> > >>> or is this going to be a pain to maintain? Shall I just keep going with > >>> the parent-locking > >>> but using bare i2c transactions only within select and deselect and leave > >>> regmap > >>> to deal with everything else? > >> > >> That's a possibility. Take care to not mess up any cached state in regmap > >> though. > > > > The original version of the driver wasn't using any caching, so I guess I > > would need to fallback > > exactly to the same implementation. > > > > So, what should I do? Should I keep the parent-locking, the unlocked > > flavours of rd/wr/rmw from > > within select/deselect, and put back regmap based rd/wr/rmw with no caching > > for everything else? > > I think that sounds like a reasonable compromise, but be careful since you > still > might need the two implementations to interact, e.g. the two rmw variants > might > still need a common lock so that they don't trample on each others toes. At > least if there are accesses to the same register (SII902X_SYS_CTRL_DATA in > this > case if I read it right). > > Cheers, > Peter Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH] drm/bridge/sii902x: Fix EDID readback
Hello Peter,
Thank you for your feedback!
> > +static int sii902x_i2c_bypass_select(struct i2c_mux_core *mux, u32 chan_id)
> > +{
> > +struct sii902x *sii902x = i2c_mux_priv(mux);
> > +struct device *dev = &sii902x->i2c->dev;
> > +unsigned long timeout;
> > +u8 status;
> > +int ret;
> > +
> > +ret = sii902x_update_bits_unlocked(sii902x->i2c, SII902X_SYS_CTRL_DATA,
> > + SII902X_SYS_CTRL_DDC_BUS_REQ,
> > + SII902X_SYS_CTRL_DDC_BUS_REQ);
>
> Here (and also in sii902x_i2c_bypass_deselect) you do a rmw access to the
> SII902X_SYS_CTRL_DATA register without coordinating with regmap. Regmap is
> also doing rmw accesses to that register in other parts of the driver. I
> think you need to either add comment as to why that is safe (maybe other
> things make it impossible for the two rmw accesses to cross?), or add the
> missing coordination.
>
The other two places where SII902X_SYS_CTRL_DATA is being handled are
sii902x_bridge_disable and sii902x_bridge_enable, I didn’t think there is
any chance of the modes being probed while the bridge gets enabled/disabled,
but now that you make me think about it user space may trigger the readback
of the EDID at the most inconvenient times. Anyway, this is a good point, and
since I don't think I am supposed to access regmap's lock from outside the APIs,
I could switch to the unlocked version of update_bits from within
sii902x_bridge_disable
and sii902x_bridge_enable, and manually grab the i2c adapter lock, what do you
think?
Fab
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End,
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered
No. 04586709.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915: intel_pipe_config_compare: Don't compare DSI PLL regs when adjusting
The GOP sometimes initializes the DSI pclk at a (slightly) different freq
then the pclk which we pick. intel_pipe_config_compare() allows for this
by doing a fuzzy compare on the port_clock.
But the pclk difference not only results in the port_clock and
base.adjusted_mode.crtc_clock clocks being a bit different, but also in
us picking different dsi_pll register values matching the different pclk.
This commit makes us only do the dsi_pll register compare when the adjust
parameter is false, so only from verify_crtc_state(), so that we correctly
do a fast modeset at boot avoiding the screen going black for about 1 sec.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/intel_display.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index b219d5858160..82fa85df0fba 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11759,8 +11759,10 @@ intel_pipe_config_compare(struct drm_i915_private
*dev_priv,
PIPE_CONF_CHECK_X(dpll_hw_state.mg_pll_bias);
PIPE_CONF_CHECK_X(dpll_hw_state.mg_pll_tdc_coldst_bias);
- PIPE_CONF_CHECK_X(dsi_pll.ctrl);
- PIPE_CONF_CHECK_X(dsi_pll.div);
+ if (!adjust) {
+ PIPE_CONF_CHECK_X(dsi_pll.ctrl);
+ PIPE_CONF_CHECK_X(dsi_pll.div);
+ }
if (IS_G4X(dev_priv) || INTEL_GEN(dev_priv) >= 5)
PIPE_CONF_CHECK_I(pipe_bpp);
--
2.19.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/bridge/sii902x: Fix EDID readback
While adding SiI9022A support to the iwg23s board, it came
up that when the HDMI transmitter is in pass through mode the
device is not compliant with the I2C specification anymore,
as it requires a far bigger tbuf, due to a delay the HDMI
transmitter is adding when relaying the STOP condition on the
monitor i2c side of things.
When not providing an appropriate delay after the STOP condition
the i2c bus would get stuck. Also, any other traffic on the bus
while talking to the monitor may cause the transaction to fail
or even cause issues with the i2c bus as well.
I2c-gates seemed to reach consent as a possible way to address
these issues, and as such this patch is implementing a solution
based on that. Since others are clearly relying on the current
implementation of the driver, this patch won't require any DT
changes.
Since we don't want any interference during the DDC Bus
Request/Grant procedure and while talking to the monitor, we
have to use the adapter locking primitives rather than the
i2c-mux locking primitives.
Signed-off-by: Fabrizio Castro
---
RFC->PATCH:
* Incorporated Linus Walleij, Peter Rosin, and Mark Brown comments
Thank you guys
drivers/gpu/drm/bridge/sii902x.c | 264 +--
1 file changed, 196 insertions(+), 68 deletions(-)
diff --git a/drivers/gpu/drm/bridge/sii902x.c b/drivers/gpu/drm/bridge/sii902x.c
index e59a135..4f9d9c7 100644
--- a/drivers/gpu/drm/bridge/sii902x.c
+++ b/drivers/gpu/drm/bridge/sii902x.c
@@ -1,4 +1,6 @@
/*
+ * Copyright (C) 2018 Renesas Electronics
+ *
* Copyright (C) 2016 Atmel
* Bo Shen
*
@@ -21,6 +23,7 @@
*/
#include
+#include
#include
#include
#include
@@ -86,8 +89,68 @@ struct sii902x {
struct drm_bridge bridge;
struct drm_connector connector;
struct gpio_desc *reset_gpio;
+ struct i2c_mux_core *i2cmux;
};
+static int sii902x_read_unlocked(struct i2c_client *i2c, u8 reg, u8 *val)
+{
+ struct i2c_msg xfer[] = {
+ {
+ .addr = i2c->addr,
+ .flags = 0,
+ .len = 1,
+ .buf = ®,
+ }, {
+ .addr = i2c->addr,
+ .flags = I2C_M_RD,
+ .len = 1,
+ .buf = val,
+ }
+ };
+ unsigned char xfers = ARRAY_SIZE(xfer);
+ int ret, retries = 5;
+
+ do {
+ ret = __i2c_transfer(i2c->adapter, xfer, xfers);
+ if (ret < 0)
+ return ret;
+ } while (ret != xfers && --retries);
+ return ret == xfers ? 0 : -1;
+}
+
+static int sii902x_write_unlocked(struct i2c_client *i2c, u8 reg, u8 val)
+{
+ u8 data[2] = {reg, val};
+ struct i2c_msg xfer = {
+ .addr = i2c->addr,
+ .flags = 0,
+ .len = sizeof(data),
+ .buf = data,
+ };
+ int ret, retries = 5;
+
+ do {
+ ret = __i2c_transfer(i2c->adapter, &xfer, 1);
+ if (ret < 0)
+ return ret;
+ } while (!ret && --retries);
+ return !ret ? -1 : 0;
+}
+
+static int sii902x_update_bits_unlocked(struct i2c_client *i2c, u8 reg, u8
mask,
+ u8 val)
+{
+ int ret;
+ u8 status;
+
+ ret = sii902x_read_unlocked(i2c, reg, &status);
+ if (ret)
+ return ret;
+ status &= ~mask;
+ status |= val & mask;
+ return sii902x_write_unlocked(i2c, reg, status);
+}
+
static inline struct sii902x *bridge_to_sii902x(struct drm_bridge *bridge)
{
return container_of(bridge, struct sii902x, bridge);
@@ -135,41 +198,11 @@ static const struct drm_connector_funcs
sii902x_connector_funcs = {
static int sii902x_get_modes(struct drm_connector *connector)
{
struct sii902x *sii902x = connector_to_sii902x(connector);
- struct regmap *regmap = sii902x->regmap;
u32 bus_format = MEDIA_BUS_FMT_RGB888_1X24;
- struct device *dev = &sii902x->i2c->dev;
- unsigned long timeout;
- unsigned int retries;
- unsigned int status;
struct edid *edid;
- int num = 0;
- int ret;
-
- ret = regmap_update_bits(regmap, SII902X_SYS_CTRL_DATA,
-SII902X_SYS_CTRL_DDC_BUS_REQ,
-SII902X_SYS_CTRL_DDC_BUS_REQ);
- if (ret)
- return ret;
-
- timeout = jiffies +
- msecs_to_jiffies(SII902X_I2C_BUS_ACQUISITION_TIMEOUT_MS);
- do {
- ret = regmap_read(regmap, SII902X_SYS_CTRL_DATA, &status);
- if (ret)
- return ret;
- } while (!(status & SII902X_SYS_CTRL_DDC_BUS_GRTD) &&
-time_before(jiffies, timeout));
-
- if (!(status & SII902X_SYS_CTRL_DDC_BUS_GRTD)) {
- dev_err(dev, "failed to acquire the i2c bus\n")
[PATCH v2] drm/msm/dpu: Correct dpu destroy and disable order
In case of msm drm bind failure, dpu_mdss_destroy is triggered. In this function, resources are freed and pm runtime disable is called, which triggers dpu_mdss_disable. Now in dpu_mdss_disable, driver tries to access a memory which is already freed. This results in kernel panic. Fix this by ensuring proper sequence of dpu destroy and disable calls. Changes in v2: - Removed double spacings [Jeykumar] Signed-off-by: Jayant Shekhar --- drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c index fd9c893..902bb4c 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c @@ -156,18 +156,15 @@ static void dpu_mdss_destroy(struct drm_device *dev) struct dpu_mdss *dpu_mdss = to_dpu_mdss(priv->mdss); struct dss_module_power *mp = &dpu_mdss->mp; + pm_runtime_disable(dev->dev); _dpu_mdss_irq_domain_fini(dpu_mdss); - free_irq(platform_get_irq(pdev, 0), dpu_mdss); - msm_dss_put_clk(mp->clk_config, mp->num_clk); devm_kfree(&pdev->dev, mp->clk_config); if (dpu_mdss->mmio) devm_iounmap(&pdev->dev, dpu_mdss->mmio); dpu_mdss->mmio = NULL; - - pm_runtime_disable(dev->dev); priv->mdss = NULL; } -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] drm/bridge/sii902x: Fix EDID readback
On 2018-11-01 12:04, Fabrizio Castro wrote:
> Hello Peter,
>
> Thank you for your feedback!
>
> snip
>
>>> Yeah, there is some issue with locking here, and that's coming down
>>> from the fact that when we call into drm_get_edid, we implicitly call
>>> i2c_transfer which ultimately locks the i2c adapter, and then calls
>>> into our sii902x_i2c_bypass_select, which in turn calls into the regmap
>>> functions and therefore we try and lock the same i2c adapter again,
>>> driving the system into a deadlock.
>>> Having the option of using "unlocked" flavours of reads and writes
>>> is what we need here, but looking at drivers/base/regmap/regmap-i2c.c
>>> I couldn't find anything suitable for my case, maybe Mark could advise
>>> on this one? I am sure I overlooked something here, is there a better
>>> way to address this?
>>
>> This recursive locking problem surfaces when an i2c mux is operated
>> by writing commands on the same i2c bus that is muxed. When this
>> happens for a typical i2c mux chip like nxp,pca9548 this can be kept
>> local to that driver. However, when there are interactions with other
>> parts of the kernel (e.g. if the i2c-mux is operated by gpio pins,
>> and those gpio pins in turn are operated by accesses to the i2c bus
>> that is muxed) this locked vs. unlocked thing would spread like
>> wildfire.
>>
>> Since I did not like that wildfire, I came up with the "mux-locked"
>> scheme. It is not appropriate everywhere, but in this case I think it
>> is a perfect fit. By using it, you should be able to dodge all locking
>> issues and it should be possible to keep the regmap usage as-is and the
>> patch would in all likelihood be much less intrusive.
>>
>> For some background on "mux-locked" vs. "parent-locked" (which is what
>> you have used in this RFC patch), see Documentation/i2c/i2c-topology.
>
> The "mux-locked" implementation was the one I first tried and I discovered
> it doesn't work for me, as other traffic on the parent adapter can get in the
> way. What we need for this device is no other traffic on the bus during the
> "select transaction deselect" procedure, that's why I went with the parent
> locking. Also this device needs a delay between stop and start conditions
> while addressing the monitor.
Ok, I thought the problem was that a delay was needed between the STOP
of the command opening the gate and the START of the edid eeprom xfer, and
that everything else worked normally. Too bad this wasn't the actual problem.
Hmm. If it is indeed true that other xfers must never creep into the "select
xfer deselect" procedure then you are indeed stuck with a parent-locking.
But is that really the case? Could it be that the extra delay between
STOP-START is only needed after the absolutely last xfer before the
command closing the gate?
If that problem description is correct, it should be possible to go back to
a mux-locked gate, but then in your deselect implementation grab the i2c adapter
lock manually - with i2c_lock_bus(adapter, I2C_LOCK_ROOT_ADAPTER) - before the
30 us delay, then open code the command to close the gate with an unlocked i2c
access, and finally release the i2c bus lock. That way you have ensured silence
on the bus for the required time before closing the gate. You would still need
to bypass regmap, but only in this one place (but maybe you should bypass
regmap for opening the gate too, for symmetry).
Cheers,
Peter
>>
>> There are a couple of more comments below, inline.
>>
>
> snip
>
>
> +static int sii902x_i2c_bypass_select(struct i2c_mux_core *mux, u32
> chan_id)
> +{
> + struct sii902x *sii902x = i2c_mux_priv(mux);
> + struct device *dev = &sii902x->i2c->dev;
> + unsigned long timeout;
> + u8 status;
> + int ret;
> +
> + ret = __sii902x_update_bits(sii902x->i2c, SII902X_SYS_CTRL_DATA,
> + SII902X_SYS_CTRL_DDC_BUS_REQ,
> + SII902X_SYS_CTRL_DDC_BUS_REQ);
> +
> + timeout = jiffies +
> +
> msecs_to_jiffies(SII902X_I2C_BUS_ACQUISITION_TIMEOUT_MS);
> + do {
> + ret = __sii902x_read(sii902x->i2c, SII902X_SYS_CTRL_DATA,
> +&status);
> + if (ret)
> + return ret;
> + } while (!(status & SII902X_SYS_CTRL_DDC_BUS_GRTD) &&
> +time_before(jiffies, timeout));
> +
> + if (!(status & SII902X_SYS_CTRL_DDC_BUS_GRTD)) {
> + dev_err(dev, "Failed to acquire the i2c bus\n");
> + return -ETIMEDOUT;
> + }
> +
> + ret = __sii902x_write(sii902x->i2c, SII902X_SYS_CTRL_DATA,
> status);
> + if (ret)
> + return ret;
>>
>> Why do I not see a delay here? I thought the whole point of adding the i2c
>> gate
>> was that it enabled the introduction of a dela
Re: [PATCH v3 1/1] drm/panel: Add support for Olimex LCD-OLinuXino panel
On 7/16/18 6:08 PM, Rob Herring wrote: On Thu, Jul 12, 2018 at 11:21:53AM +0300, Stefan Mavrodiev wrote: This patch adds Olimex Ltd. LCD-OLinuXino bridge panel driver. The panel is used with different LCDs (currently from 480x272 to 1280x800). Small EEPROM chip is used for identification, which holds some factory data and timing requirements. Signed-off-by: Stefan Mavrodiev --- Changes for v3: - Change module license from "GPL v2" to "GPL" - Make use of backlight_enable()/backlight_disable() helpers - Rework backlight device request - Remove drm_panel_detach() - Use module_i2c_driver() for initialization - Make the first mode preferred - If num_modes value is invalid, overwrite it with 4, which is the maximum - Some variable types optimizations Changes for v2: - Changed lcd_olinuxino_funcs to static const .../display/panel/olimex,lcd-olinuxino.txt | 42 +++ Reviewed-by: Rob Herring MAINTAINERS| 6 + drivers/gpu/drm/panel/Kconfig | 10 + drivers/gpu/drm/panel/Makefile | 1 + drivers/gpu/drm/panel/panel-olimex-lcd-olinuxino.c | 331 + 5 files changed, 390 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/olimex,lcd-olinuxino.txt create mode 100644 drivers/gpu/drm/panel/panel-olimex-lcd-olinuxino.c I would like to ask if there will be any progress on this patch? Best regards, Stefan Mavrodiev ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
