dri-devel February 2020

dri-devel@lists.freedesktop.org

302 participants
679 discussions

[PATCH] drm/i915/dp: Add dpcd link_rate quirk for Apple 15" MBP 2017
by Mario Kleiner 05 Mar '20

05 Mar '20

This fixes a problem found on the MacBookPro 2017 Retina panel. The panel reports 10 bpc color depth in its EDID, and the firmware chooses link settings at boot which support enough bandwidth for 10 bpc (324000 kbit/sec = multiplier 0xc), but the DP_MAX_LINK_RATE dpcd register only reports 2.7 Gbps (multiplier value 0xa) as possible, in direct contradiction of what the firmware successfully set up. This restricts the panel to 8 bpc, not providing the full color depth of the panel. This patch … [View More]adds a quirk specific to the MBP 2017 15" Retina panel to add the additiional 324000 kbps link rate during edp setup. Link to previous discussion of a different attempted fix with Ville and Jani: https://patchwork.kernel.org/patch/11325935/ Signed-off-by: Mario Kleiner <mario.kleiner.de(a)gmail.com> Cc: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Cc: Jani Nikula <jani.nikula(a)intel.com> --- drivers/gpu/drm/drm_dp_helper.c | 2 ++ drivers/gpu/drm/i915/display/intel_dp.c | 7 +++++++ include/drm/drm_dp_helper.h | 7 +++++++ 3 files changed, 16 insertions(+) diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c index 5a103e9b3c86..36a371c016cb 100644 --- a/drivers/gpu/drm/drm_dp_helper.c +++ b/drivers/gpu/drm/drm_dp_helper.c @@ -1179,6 +1179,8 @@ static const struct dpcd_quirk dpcd_quirk_list[] = { { OUI(0x00, 0x00, 0x00), DEVICE_ID('C', 'H', '7', '5', '1', '1'), false, BIT(DP_DPCD_QUIRK_NO_SINK_COUNT) }, /* Synaptics DP1.4 MST hubs can support DSC without virtual DPCD */ { OUI(0x90, 0xCC, 0x24), DEVICE_ID_ANY, true, BIT(DP_DPCD_QUIRK_DSC_WITHOUT_VIRTUAL_DPCD) }, + /* Apple MacBookPro 2017 15 inch eDP Retina panel reports too low DP_MAX_LINK_RATE */ + { OUI(0x00, 0x10, 0xfa), DEVICE_ID(101, 68, 21, 101, 98, 97), false, BIT(DP_DPCD_QUIRK_CAN_DO_MAX_LINK_RATE_3_24_GBPS) }, }; #undef OUI diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c index 4074d83b1a5f..1f6bd659ad41 100644 --- a/drivers/gpu/drm/i915/display/intel_dp.c +++ b/drivers/gpu/drm/i915/display/intel_dp.c @@ -178,6 +178,13 @@ static void intel_dp_set_sink_rates(struct intel_dp *intel_dp) } intel_dp->num_sink_rates = i; + + if (drm_dp_has_quirk(&intel_dp->desc, + DP_DPCD_QUIRK_CAN_DO_MAX_LINK_RATE_3_24_GBPS)) { + /* Needed for Apple MBP 2017, 15 inch eDP Retina panel */ + intel_dp->sink_rates[i] = 324000; + intel_dp->num_sink_rates++; + } } /* Get length of rates array potentially limited by max_rate. */ diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index 262faf9e5e94..4b86a1f2a559 100644 --- a/include/drm/drm_dp_helper.h +++ b/include/drm/drm_dp_helper.h @@ -1532,6 +1532,13 @@ enum drm_dp_quirk { * The DSC caps can be read from the physical aux instead. */ DP_DPCD_QUIRK_DSC_WITHOUT_VIRTUAL_DPCD, + /** + * @DP_DPCD_QUIRK_CAN_DO_MAX_LINK_RATE_3_24_GBPS: + * + * The device supports a link rate of 3.24 Gbps (multiplier 0xc) despite + * the DP_MAX_LINK_RATE register reporting a lower max multiplier. + */ + DP_DPCD_QUIRK_CAN_DO_MAX_LINK_RATE_3_24_GBPS, }; /** -- 2.20.1 [View Less]

2 2

[PATCH] gpu/drm/v3d: Add ARCH_BCM2835 to DRM_V3D Kconfig
by Peter Robinson 05 Mar '20

05 Mar '20

On arm64 the config ARCH_BCM doesn't exist so to be able to build for platforms such as the Raspberry Pi 4 we need to add ARCH_BCM2835 similar to what has been done on vc4. Signed-off-by: Peter Robinson <pbrobinson(a)gmail.com> --- drivers/gpu/drm/v3d/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/v3d/Kconfig b/drivers/gpu/drm/v3d/Kconfig index 9a5c44606337..b0e048697964 100644 --- a/drivers/gpu/drm/v3d/Kconfig +++ b/drivers/gpu/drm/v3d/… [View More]

4 4

[PATCH] GPU: DRM: VC4/V3D Replace wait_for macros in to remove use of msleep
by James Hughes 05 Mar '20

05 Mar '20

The wait_for macro's for Broadcom VC4 and V3D drivers used msleep which is inappropriate due to its inaccuracy at low values (minimum wait time is about 30ms on the Raspberry Pi). This patch replaces the macro with the one from the Intel i915 version which uses usleep_range to provide more accurate waits. Signed-off-by: James Hughes <james.hughes(a)raspberrypi.com> --- drivers/gpu/drm/v3d/v3d_drv.h | 41 ++++++++++++++++++++++----------- drivers/gpu/drm/vc4/vc4_drv.h | 43 ++++++++++++++… [View More]+++++++-------------- 2 files changed, 54 insertions(+), 30 deletions(-) diff --git a/drivers/gpu/drm/v3d/v3d_drv.h b/drivers/gpu/drm/v3d/v3d_drv.h index 7b4f3b5a086e..069fefe16d28 100644 --- a/drivers/gpu/drm/v3d/v3d_drv.h +++ b/drivers/gpu/drm/v3d/v3d_drv.h @@ -267,27 +267,42 @@ struct v3d_csd_job { }; /** - * _wait_for - magic (register) wait macro + * __wait_for - magic wait macro * - * Does the right thing for modeset paths when run under kdgb or similar atomic - * contexts. Note that it's important that we check the condition again after - * having timed out, since the timeout could be due to preemption or similar and - * we've never had a chance to check the condition before the timeout. + * Macro to help avoid open coding check/wait/timeout patterns. Note that it's + * important that we check the condition again after having timed out, since the + * timeout could be due to preemption or similar and we've never had a chance to + * check the condition before the timeout. */ -#define wait_for(COND, MS) ({ \ - unsigned long timeout__ = jiffies + msecs_to_jiffies(MS) + 1; \ - int ret__ = 0; \ - while (!(COND)) { \ - if (time_after(jiffies, timeout__)) { \ - if (!(COND)) \ - ret__ = -ETIMEDOUT; \ +#define __wait_for(OP, COND, US, Wmin, Wmax) ({ \ + const ktime_t end__ = ktime_add_ns(ktime_get_raw(), 1000ll * (US)); \ + long wait__ = (Wmin); /* recommended min for usleep is 10 us */ \ + int ret__; \ + might_sleep(); \ + for (;;) { \ + const bool expired__ = ktime_after(ktime_get_raw(), end__); \ + OP; \ + /* Guarantee COND check prior to timeout */ \ + barrier(); \ + if (COND) { \ + ret__ = 0; \ break; \ } \ - msleep(1); \ + if (expired__) { \ + ret__ = -ETIMEDOUT; \ + break; \ + } \ + usleep_range(wait__, wait__ * 2); \ + if (wait__ < (Wmax)) \ + wait__ <<= 1; \ } \ ret__; \ }) +#define _wait_for(COND, US, Wmin, Wmax) __wait_for(, (COND), (US), (Wmin), \ + (Wmax)) +#define wait_for(COND, MS) _wait_for((COND), (MS) * 1000, 10, 1000) + static inline unsigned long nsecs_to_jiffies_timeout(const u64 n) { /* nsecs_to_jiffies64() does not guard against overflow */ diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h index 7956f6ed9b6a..c59be5e1d52b 100644 --- a/drivers/gpu/drm/vc4/vc4_drv.h +++ b/drivers/gpu/drm/vc4/vc4_drv.h @@ -629,32 +629,41 @@ struct vc4_validated_shader_info { }; /** - * _wait_for - magic (register) wait macro + * __wait_for - magic wait macro * - * Does the right thing for modeset paths when run under kdgb or similar atomic - * contexts. Note that it's important that we check the condition again after - * having timed out, since the timeout could be due to preemption or similar and - * we've never had a chance to check the condition before the timeout. + * Macro to help avoid open coding check/wait/timeout patterns. Note that it's + * important that we check the condition again after having timed out, since the + * timeout could be due to preemption or similar and we've never had a chance to + * check the condition before the timeout. */ -#define _wait_for(COND, MS, W) ({ \ - unsigned long timeout__ = jiffies + msecs_to_jiffies(MS) + 1; \ - int ret__ = 0; \ - while (!(COND)) { \ - if (time_after(jiffies, timeout__)) { \ - if (!(COND)) \ - ret__ = -ETIMEDOUT; \ +#define __wait_for(OP, COND, US, Wmin, Wmax) ({ \ + const ktime_t end__ = ktime_add_ns(ktime_get_raw(), 1000ll * (US)); \ + long wait__ = (Wmin); /* recommended min for usleep is 10 us */ \ + int ret__; \ + might_sleep(); \ + for (;;) { \ + const bool expired__ = ktime_after(ktime_get_raw(), end__); \ + OP; \ + /* Guarantee COND check prior to timeout */ \ + barrier(); \ + if (COND) { \ + ret__ = 0; \ break; \ } \ - if (W && drm_can_sleep()) { \ - msleep(W); \ - } else { \ - cpu_relax(); \ + if (expired__) { \ + ret__ = -ETIMEDOUT; \ + break; \ } \ + usleep_range(wait__, wait__ * 2); \ + if (wait__ < (Wmax)) \ + wait__ <<= 1; \ } \ ret__; \ }) -#define wait_for(COND, MS) _wait_for(COND, MS, 1) +#define _wait_for(COND, US, Wmin, Wmax) __wait_for(, (COND), (US), (Wmin), \ + (Wmax)) +#define wait_for(COND, MS) _wait_for((COND), (MS) * 1000, 10, 1000) /* vc4_bo.c */ struct drm_gem_object *vc4_create_object(struct drm_device *dev, size_t size); -- 2.17.1 [View Less]

2 3

Re: [PATCH] thinkpad_acpi: Add sysfs entry for lcdshadow feature
by Andy Shevchenko 05 Mar '20

05 Mar '20

On Thu, Feb 20, 2020 at 9:48 AM Nitin Joshi <nitjoshi(a)gmail.com> wrote: > > This feature is supported on some Thinkpad products like T490s, Thinkpad > X1 yoga 4th Gen etc . The lcdshadow feature can be enabled and disabled > when user press "Fn" + "D" key. Currently, no user feedback is given for > this action. Adding as sysfs entry allows userspace to show an On Screen > Display whenever the setting changes. > > Summary of changes is mentioned below :… [View More]

5 8

[PATCH] drm/fourcc: Add bayer formats and modifiers
by Niklas Söderlund 04 Mar '20

04 Mar '20

Bayer formats are used with cameras and contain green, red and blue components, with alternating lines of red and green, and blue and green pixels in different orders. For each block of 2x2 pixels there is one pixel with a red filter, two with a green filter, and one with a blue filter. The filters can be arranged in different patterns. Add DRM fourcc formats to describe the most common Bayer formats. Also add a modifiers to describe the custom packing layouts used by the Intel IPU3 and in the … [View More]MIPI (Mobile Industry Processor Interface) CSI-2 specification. Signed-off-by: Niklas Söderlund <niklas.soderlund(a)ragnatech.se> --- include/uapi/drm/drm_fourcc.h | 95 +++++++++++++++++++++++++++++++++++ 1 file changed, 95 insertions(+) diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h index 8bc0b31597d80737..561d5a08ffd16b69 100644 --- a/include/uapi/drm/drm_fourcc.h +++ b/include/uapi/drm/drm_fourcc.h @@ -286,6 +286,62 @@ extern "C" { #define DRM_FORMAT_YVU444 fourcc_code('Y', 'V', '2', '4') /* non-subsampled Cr (1) and Cb (2) planes */ +/* + * Bayer formats + * + * Bayer formats contain green, red and blue components, with alternating lines + * of red and green, and blue and green pixels in different orders. For each + * block of 2x2 pixels there is one pixel with a red filter, two with a green + * filter, and one with a blue filter. The filters can be arranged in different + * patterns. + * + * For example, RGGB: + * row0: RGRGRGRG... + * row1: GBGBGBGB... + * row3: RGRGRGRG... + * row4: GBGBGBGB... + * ... + * + * Vendors have different methods to pack the sampling formats to increase data + * density. For this reason the fourcc only describes pixel sample size and the + * filter pattern for each block of 2x2 pixels. A modifier is needed to + * describe the memory layout. + * + * In addition to vendor modifiers for memory layout DRM_FORMAT_MOD_LINEAR may + * be used to describe a layout where all samples are placed consecutively in + * memory. If the sample does not fit inside a single byte, the sample storage + * is extended to the minimum number of (little endian) bytes that can hold the + * sample and any unused most-significant bits are defined as padding. + * + * For example, SRGGB10: + * Each 10-bit sample is contained in 2 consecutive little endian bytes, where + * the 6 most-significant bits are unused. + */ + +/* 8-bit Bayer formats */ +#define DRM_FORMAT_SRGGB8 fourcc_code('R', 'G', 'G', 'B') +#define DRM_FORMAT_SGRBG8 fourcc_code('G', 'R', 'B', 'G') +#define DRM_FORMAT_SGBRG8 fourcc_code('G', 'B', 'R', 'G') +#define DRM_FORMAT_SBGGR8 fourcc_code('B', 'A', '8', '1') + +/* 10-bit Bayer formats */ +#define DRM_FORMAT_SRGGB10 fourcc_code('R', 'G', '1', '0') +#define DRM_FORMAT_SGRBG10 fourcc_code('B', 'A', '1', '0') +#define DRM_FORMAT_SGBRG10 fourcc_code('G', 'B', '1', '0') +#define DRM_FORMAT_SBGGR10 fourcc_code('B', 'G', '1', '0') + +/* 12-bit Bayer formats */ +#define DRM_FORMAT_SRGGB12 fourcc_code('R', 'G', '1', '2') +#define DRM_FORMAT_SGRBG12 fourcc_code('B', 'A', '1', '2') +#define DRM_FORMAT_SGBRG12 fourcc_code('G', 'B', '1', '2') +#define DRM_FORMAT_SBGGR12 fourcc_code('B', 'G', '1', '2') + +/* 14-bit Bayer formats */ +#define DRM_FORMAT_SRGGB14 fourcc_code('R', 'G', '1', '4') +#define DRM_FORMAT_SGRBG14 fourcc_code('B', 'A', '1', '4') +#define DRM_FORMAT_SGBRG14 fourcc_code('G', 'B', '1', '4') +#define DRM_FORMAT_SBGGR14 fourcc_code('B', 'G', '1', '4') + /* * Format Modifiers: * @@ -309,6 +365,7 @@ extern "C" { #define DRM_FORMAT_MOD_VENDOR_BROADCOM 0x07 #define DRM_FORMAT_MOD_VENDOR_ARM 0x08 #define DRM_FORMAT_MOD_VENDOR_ALLWINNER 0x09 +#define DRM_FORMAT_MOD_VENDOR_MIPI 0x0a /* add more to the end as needed */ @@ -434,6 +491,17 @@ extern "C" { */ #define I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS fourcc_mod_code(INTEL, 7) + +/* + * IPU3 Bayer packing layout + * + * The IPU3 raw Bayer formats use a custom packing layout where there are no + * gaps between each 10-bit sample. It packs 25 pixels into 32 bytes leaving + * the 6 most significant bits in the last byte unused. The format is little + * endian. + */ +#define IPU3_FORMAT_MOD_PACKED fourcc_mod_code(INTEL, 8) + /* * Tiled, NV12MT, grouped in 64 (pixels) x 32 (lines) -sized macroblocks * @@ -804,6 +872,33 @@ extern "C" { */ #define DRM_FORMAT_MOD_ALLWINNER_TILED fourcc_mod_code(ALLWINNER, 1) +/* Mobile Industry Processor Interface (MIPI) modifiers */ + +/* + * MIPI CSI-2 packing layout + * + * The CSI-2 RAW formats (for example Bayer) use a different packing layout + * depenindg on the sample size. + * + * - 10-bits per sample + * Every four consecutive samples are packed into 5 bytes. Each of the first 4 + * bytes contain the 8 high order bits of the pixels, and the 5th byte + * contains the 2 least-significant bits of each pixel, in the same order. + * + * - 12-bits per sample + * Every two consecutive samples are packed into three bytes. Each of the + * first two bytes contain the 8 high order bits of the pixels, and the third + * byte contains the four least-significant bits of each pixel, in the same + * order. + * + * - 14-bits per sample + * Every four consecutive samples are packed into seven bytes. Each of the + * first four bytes contain the eight high order bits of the pixels, and the + * three following bytes contains the six least-significant bits of each + * pixel, in the same order. + */ +#define MIPI_FORMAT_MOD_CSI2_PACKED fourcc_mod_code(MIPI, 1) + #if defined(__cplusplus) } #endif -- 2.25.1 [View Less]

4 3

[PATCH resend 1/2] drm/i915: panel: Use intel_panel_compute_brightness() from pwm_setup_backlight()
by Hans de Goede 04 Mar '20

04 Mar '20

Use intel_panel_compute_brightness() from pwm_setup_backlight() so that we correctly take i915_modparams.invert_brightness and/or QUIRK_INVERT_BRIGHTNESS into account when setting + getting the initial brightness value. Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> --- drivers/gpu/drm/i915/display/intel_panel.c | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_panel.c b/drivers/gpu/drm/i915/display/… [View More]

2 3

[PATCH 0/3] ti-sysc changes for probing DSS with dts data
by Tony Lindgren 04 Mar '20

04 Mar '20

Hi all, Here are some changes to start probing display susbsystem (DSS) with device tree data instead of platform data. These changes are against v5.6-rc1, and depend on the earlier series "[PATCH 0/7] ti-sysc driver fix for hdq1w and few improvments". I'll be posting the related dts changes separately. Regards, Tony Tony Lindgren (3): drm/omap: Prepare DSS for probing without legacy platform data bus: ti-sysc: Detect display subsystem related devices bus: ti-sysc: Implement … [View More]

4 17

[PATCH v2 0/5] HDCP misc
by Ramalingam C 04 Mar '20

04 Mar '20

Combined HDCP patches together. Few for DRM SRM handling and few more for hdcp2.2 compliance fix at I915. v2: minor changes in i915 related 3 patches. Ramalingam C (5): drm/hdcp: optimizing the srm handling drm/hdcp: fix DRM_HDCP_2_KSV_COUNT_2_LSBITS drm/i915: terminate reauth at stream management failure drm/i915: dont retry stream management at seq_num_m roll over drm/i915/hdcp: conversion to struct drm_device based logging macros. drivers/gpu/drm/drm_hdcp.c | … [View More]

4 14

[PATCH] drm/bochs: Remove vga write
by Alistair Francis 04 Mar '20

04 Mar '20

The QEMU model for the Bochs display has no VGA memory section at offset 0x400 [1]. By writing to this register Linux can create a write to unassigned memory which depending on machine and architecture can result in a store fault. I don't see any reference to this address at OSDev [2] or in the Bochs source code. Removing this write still allows graphics to work inside QEMU with the bochs-display. 1: https://gitlab.com/qemu-project/qemu/-/blob/master/hw/display/bochs-display… 2. https://… [View More]

3 4

[PATCH v2 0/3] drm/dp, i915: eDP DPCD backlight control detection fixes
by Lyude Paul 03 Mar '20

03 Mar '20

Unfortunately, it turned out that the DPCD is also not a reliable way of probing for DPCD backlight support as some panels will lie and say they have DPCD backlight controls when they don't actually. So, revert back to the old behavior and add a bunch of EDID-based DP quirks for the panels that we know need this. As you might have already guessed, OUI quirks didn't seem to be a very safe bet for these panels due to them not having their device IDs filled out. Lyude Paul (3): drm/dp: … [View More]

2 6

← Newer
1
...
15
16
17
18
19
20
21
...
68
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel February 2020