dri-devel March 2020

dri-devel@lists.freedesktop.org

328 participants
771 discussions

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 : > > - Added TP_HKEY_EV_LCDSHADOW_CHANGED for consistency inside the driver > - Added unmapped LCDSHADOW to keymap > - Added lcdshadow_get function to read value using ACPI > - Added lcdshadow_refresh function to re-read value and send notification > - Added sysfs group creation to tpaci_lcdshadow_init > - Added lcdshadow_exit to remove sysfs group again > - Implemented lcdshadow_enable_show/lcdshadow_enable_store > - Added handler to tpacpi_driver_event to update refresh lcdshadow > - Explicitly call tpacpi_driver_event for extended keyset Adding custom PrivacyGuard support to this driver was my mistake, There is a discussion [1] how to do this in generic way to cover other possible users. I Cc this to people from that discussion. [1]: https://lore.kernel.org/dri-devel/CAL_quvRknSSVvXN3q_Se0hrziw2oTNS3ENNoeHYh… -- With Best Regards, Andy Shevchenko

5 8

[PATCH v4 00/13] support gce on mt6779 platform
by Dennis YC Hsieh 05 Mar '20

05 Mar '20

This patch support gce on mt6779 platform. Change since v3: - refine code for local variable usage - use cmdq error code to consistent with current design - return error directly after send if error code return - also modify drm driver which uses cmdq_pkt_wfe api - add finalize in drm driver Change since v2: - rebase onto 5.6-rc1 - remove unnecessary definition - add clear parameter in wfe api - separate assign and write_s api - add jump api instead of finalize in loop [... snip ...] Dennis YC Hsieh (13): dt-binding: gce: add gce header file for mt6779 mailbox: cmdq: variablize address shift in platform mailbox: cmdq: support mt6779 gce platform definition mailbox: mediatek: cmdq: clear task in channel before shutdown soc: mediatek: cmdq: return send msg error code soc: mediatek: cmdq: add assign function soc: mediatek: cmdq: add write_s function soc: mediatek: cmdq: add read_s function soc: mediatek: cmdq: add write_s value function soc: mediatek: cmdq: export finalize function soc: mediatek: cmdq: add jump function soc: mediatek: cmdq: add clear option in cmdq_pkt_wfe api soc: mediatek: cmdq: add set event function .../devicetree/bindings/mailbox/mtk-gce.txt | 8 +- drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 3 +- drivers/mailbox/mtk-cmdq-mailbox.c | 101 ++++++-- drivers/soc/mediatek/mtk-cmdq-helper.c | 143 ++++++++++- include/dt-bindings/gce/mt6779-gce.h | 222 ++++++++++++++++++ include/linux/mailbox/mtk-cmdq-mailbox.h | 10 +- include/linux/soc/mediatek/mtk-cmdq.h | 94 +++++++- 7 files changed, 548 insertions(+), 33 deletions(-) create mode 100644 include/dt-bindings/gce/mt6779-gce.h -- 2.18.0

4 23

[PATCH] Make drm_dp_mst_dsc_aux_for_port() safe for old compilers
by Paul E. McKenney 04 Mar '20

04 Mar '20

Older compilers either want two extra pairs of curly braces around the initializer for local variable "desc", or they want a single pair of curly braces with nothing inside. Current Linux-kernel practice favors the latter, so this commit makes it so. This is a fix for a regression introduced into v5.6-rc1. Fixes: 5b03f9d86880 ("drm/dp_mst: Add new quirk for Synaptics MST hubs") Suggested-by: Chris Wilson <chris(a)chris-wilson.co.uk> Suggested-by: Joe Perches <joe(a)perches.com> Suggested-by: Christoph Hellwig <hch(a)infradead.org> Signed-off-by: Paul E. McKenney <paulmck(a)kernel.org> Cc: Maxime Ripard <mripard(a)kernel.org> Cc: David Airlie <airlied(a)linux.ie> Cc: Daniel Vetter <daniel(a)ffwll.ch> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c b/drivers/gpu/drm/drm_dp_mst_topology.c index 20cdaf3..b123f60 100644 --- a/drivers/gpu/drm/drm_dp_mst_topology.c +++ b/drivers/gpu/drm/drm_dp_mst_topology.c @@ -5396,7 +5396,7 @@ struct drm_dp_aux *drm_dp_mst_dsc_aux_for_port(struct drm_dp_mst_port *port) { struct drm_dp_mst_port *immediate_upstream_port; struct drm_dp_mst_port *fec_port; - struct drm_dp_desc desc = { 0 }; + struct drm_dp_desc desc = { }; u8 endpoint_fec; u8 endpoint_dsc;

1 0

[PATCH] drm/amd/display: Remove pointless NULL checks in dmub_psr_copy_settings
by Nathan Chancellor 04 Mar '20

04 Mar '20

Clang warns: drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dmub_psr.c:147:31: warning: address of 'pipe_ctx->plane_res' will always evaluate to 'true' [-Wpointer-bool-conversion] if (!pipe_ctx || !&pipe_ctx->plane_res || !&pipe_ctx->stream_res) ~ ~~~~~~~~~~^~~~~~~~~ drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dmub_psr.c:147:56: warning: address of 'pipe_ctx->stream_res' will always evaluate to 'true' [-Wpointer-bool-conversion] if (!pipe_ctx || !&pipe_ctx->plane_res || !&pipe_ctx->stream_res) ~ ~~~~~~~~~~^~~~~~~~~~ 2 warnings generated. As long as pipe_ctx is not NULL, the address of members in this struct cannot be NULL, which means these checks will always evaluate to false. Fixes: 4c1a1335dfe0 ("drm/amd/display: Driverside changes to support PSR in DMCUB") Link: https://github.com/ClangBuiltLinux/linux/issues/915 Signed-off-by: Nathan Chancellor <natechancellor(a)gmail.com> --- drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c b/drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c index 2c932c29f1f9..a9e1c01e9d9b 100644 --- a/drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c +++ b/drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c @@ -144,7 +144,7 @@ static bool dmub_psr_copy_settings(struct dmub_psr *dmub, } } - if (!pipe_ctx || !&pipe_ctx->plane_res || !&pipe_ctx->stream_res) + if (!pipe_ctx) return false; // First, set the psr version -- 2.25.1

3 2

[PATCH v3] drm/dp: Add function to parse EDID descriptors for adaptive sync limits
by Manasi Navare 04 Mar '20

04 Mar '20

Adaptive Sync is a VESA feature so add a DRM core helper to parse the EDID's detailed descritors to obtain the adaptive sync monitor range. Store this info as part fo drm_display_info so it can be used across all drivers. This part of the code is stripped out of amdgpu's function amdgpu_dm_update_freesync_caps() to make it generic and be used across all DRM drivers v3: * Remove the edid parsing restriction for just DP (Nicholas) * Use drm_for_each_detailed_block (Ville) * Make the drm_get_adaptive_sync_range function static (Harry, Jani) v2: * Change vmin and vmax to use u8 (Ville) * Dont store pixel clock since that is just a max dotclock and not related to VRR mode (Manasi) Cc: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Cc: Harry Wentland <harry.wentland(a)amd.com> Cc: Clinton A Taylor <clinton.a.taylor(a)intel.com> Cc: Kazlauskas, Nicholas <Nicholas.Kazlauskas(a)amd.com> Signed-off-by: Manasi Navare <manasi.d.navare(a)intel.com> --- drivers/gpu/drm/drm_edid.c | 44 +++++++++++++++++++++++++++++++++++++ include/drm/drm_connector.h | 22 +++++++++++++++++++ 2 files changed, 66 insertions(+) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index ad41764a4ebe..e3f152180b6b 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -4938,6 +4938,47 @@ static void drm_parse_cea_ext(struct drm_connector *connector, } } +static +void get_adaptive_sync_range(struct detailed_timing *timing, + void *info_adaptive_sync) +{ + struct drm_adaptive_sync_info *adaptive_sync = info_adaptive_sync; + const struct detailed_non_pixel *data = &timing->data.other_data; + const struct detailed_data_monitor_range *range = &data->data.range; + + if (data->type != EDID_DETAIL_MONITOR_RANGE) + return; + + /* + * Check for flag range limits only. If flag == 1 then + * no additional timing information provided. + * Default GTF, GTF Secondary curve and CVT are not + * supported + */ + if (range->flags != 1) + return; + + adaptive_sync->min_vfreq = range->min_vfreq; + adaptive_sync->max_vfreq = range->max_vfreq; +} + +static +void drm_get_adaptive_sync_range(struct drm_connector *connector, + const struct edid *edid) +{ + struct drm_display_info *info = &connector->display_info; + + if (!version_greater(edid, 1, 1)) + return; + + drm_for_each_detailed_block((u8 *)edid, get_adaptive_sync_range, + &info->adaptive_sync); + + DRM_DEBUG_KMS("Adaptive Sync refresh rate range is %d Hz - %d Hz\n", + info->adaptive_sync.min_vfreq, + info->adaptive_sync.max_vfreq); +} + /* A connector has no EDID information, so we've got no EDID to compute quirks from. Reset * all of the values which would have been set from EDID */ @@ -4960,6 +5001,7 @@ drm_reset_display_info(struct drm_connector *connector) memset(&info->hdmi, 0, sizeof(info->hdmi)); info->non_desktop = 0; + memset(&info->adaptive_sync, 0, sizeof(info->adaptive_sync)); } u32 drm_add_display_info(struct drm_connector *connector, const struct edid *edid) @@ -4975,6 +5017,8 @@ u32 drm_add_display_info(struct drm_connector *connector, const struct edid *edi info->non_desktop = !!(quirks & EDID_QUIRK_NON_DESKTOP); + drm_get_adaptive_sync_range(connector, edid); + DRM_DEBUG_KMS("non_desktop set to %d\n", info->non_desktop); if (edid->revision < 3) diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h index 0df7a95ca5d9..2b22c0fa42c4 100644 --- a/include/drm/drm_connector.h +++ b/include/drm/drm_connector.h @@ -254,6 +254,23 @@ enum drm_panel_orientation { DRM_MODE_PANEL_ORIENTATION_RIGHT_UP, }; +/** + * struct drm_adaptive_sync_info - Panel's Adaptive Sync capabilities for + * &drm_display_info + * + * This struct is used to store a Panel's Adaptive Sync capabilities + * as parsed from EDID's detailed monitor range descriptor block. + * + * @min_vfreq: This is the min supported refresh rate in Hz from + * EDID's detailed monitor range. + * @max_vfreq: This is the max supported refresh rate in Hz from + * EDID's detailed monitor range + */ +struct drm_adaptive_sync_info { + u8 min_vfreq; + u8 max_vfreq; +}; + /* * This is a consolidated colorimetry list supported by HDMI and * DP protocol standard. The respective connectors will register @@ -473,6 +490,11 @@ struct drm_display_info { * @non_desktop: Non desktop display (HMD). */ bool non_desktop; + + /** + * @adaptive_sync: Adaptive Sync capabilities of the DP/eDP sink + */ + struct drm_adaptive_sync_info adaptive_sync; }; int drm_display_info_set_bus_formats(struct drm_display_info *info, -- 2.19.1

2 3

[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 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

4 3

[PATCH v12 0/6] mt8183 dpi supports dual edge and pin mode swap
by Jitao Shi 04 Mar '20

04 Mar '20

Change since v11: - fine tune mediatek,dpi.yaml. - add Acked-by: Rob Herring <robh(a)kernel.org>. Change since v10: - convert the Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt to yaml format. - read the pclk-sample in endpoint. Changes since v9: - rename pinctrl-names = "gpiomode", "dpimode" to "active", "idle". - fix some typo. Changes since v8: - drop pclk-sample redefine in mediatek,dpi.txt - only get the gpiomode and dpimode when dpi->pinctrl is successful. Changes since v7: - separate dt-bindings to independent patches. - move dpi dual edge to one patch. Changes since v6: - change dual_edge to pclk-sample - remove dpi_pin_mode_swap and Changes since v5: - fine tune the dt-bindings commit message. Changes since v4: - move pin mode control and dual edge control to deveice tree. - update dt-bindings document for pin mode swap and dual edge control. Changes since v3: - add dpi pin mode control when dpi on or off. - update dpi dual edge comment. Changes since v2: - update dt-bindings document for mt8183 dpi. - separate dual edge modfication as independent patch. Jitao Shi (6): dt-bindings: media: add pclk-sample dual edge property dt-bindings: display: mediatek: control dpi pins mode to avoid leakage dt-bindings: display: mediatek: dpi sample data in dual edge support dt-bindings: display: mediatek: convert the document format from txt to yaml drm/mediatek: dpi sample mode support drm/mediatek: set dpi pin mode to gpio low to avoid leakage current .../display/mediatek/mediatek,dpi.txt | 36 -------- .../display/mediatek/mediatek,dpi.yaml | 92 +++++++++++++++++++ .../bindings/media/video-interfaces.txt | 4 +- drivers/gpu/drm/mediatek/mtk_dpi.c | 58 +++++++++++- 4 files changed, 150 insertions(+), 40 deletions(-) delete mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml -- 2.21.0

2 8

[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/intel_panel.c index 7b3ec6eb3382..9ebee7d93414 100644 --- a/drivers/gpu/drm/i915/display/intel_panel.c +++ b/drivers/gpu/drm/i915/display/intel_panel.c @@ -1843,6 +1843,7 @@ static int pwm_setup_backlight(struct intel_connector *connector, struct drm_i915_private *dev_priv = to_i915(dev); struct intel_panel *panel = &connector->panel; const char *desc; + u32 level, ns; int retval; /* Get the right PWM chip for DSI backlight according to VBT */ @@ -1866,8 +1867,12 @@ static int pwm_setup_backlight(struct intel_connector *connector, */ pwm_apply_args(panel->backlight.pwm); - retval = pwm_config(panel->backlight.pwm, CRC_PMIC_PWM_PERIOD_NS, - CRC_PMIC_PWM_PERIOD_NS); + panel->backlight.min = 0; /* 0% */ + panel->backlight.max = 100; /* 100% */ + level = intel_panel_compute_brightness(connector, 100); + ns = DIV_ROUND_UP(level * CRC_PMIC_PWM_PERIOD_NS, 100); + + retval = pwm_config(panel->backlight.pwm, ns, CRC_PMIC_PWM_PERIOD_NS); if (retval < 0) { DRM_ERROR("Failed to configure the pwm chip\n"); pwm_put(panel->backlight.pwm); @@ -1875,11 +1880,10 @@ static int pwm_setup_backlight(struct intel_connector *connector, return retval; } - panel->backlight.min = 0; /* 0% */ - panel->backlight.max = 100; /* 100% */ - panel->backlight.level = DIV_ROUND_UP( - pwm_get_duty_cycle(panel->backlight.pwm) * 100, - CRC_PMIC_PWM_PERIOD_NS); + level = DIV_ROUND_UP(pwm_get_duty_cycle(panel->backlight.pwm) * 100, + CRC_PMIC_PWM_PERIOD_NS); + panel->backlight.level = + intel_panel_compute_brightness(connector, level); panel->backlight.enabled = panel->backlight.level != 0; DRM_INFO("Using %s PWM for LCD backlight control\n", desc); -- 2.25.0

2 3

[PATCH v2] drm/simple-kms: Fix documentation for drm_simple_encoder_init()
by Thomas Zimmermann 04 Mar '20

04 Mar '20

Brings the documentation of drm_simple_encoder_init() in sync with the function's signature. Also add a paragraph clarifying the management of the encoder's memory. v2: * document memory management Signed-off-by: Thomas Zimmermann <tzimmermann(a)suse.de> Reviewed-by: Daniel Vetter <daniel.vetter(a)ffwll.ch> Fixes: 63170ac6f2e8 ("drm/simple-kms: Add drm_simple_encoder_{init,create}()") Cc: Sam Ravnborg <sam(a)ravnborg.org> Cc: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> Cc: Maxime Ripard <mripard(a)kernel.org> Cc: David Airlie <airlied(a)linux.ie> Cc: Daniel Vetter <daniel(a)ffwll.ch> Cc: dri-devel(a)lists.freedesktop.org --- drivers/gpu/drm/drm_simple_kms_helper.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c b/drivers/gpu/drm/drm_simple_kms_helper.c index 5a2abe2dea3e..74946690aba4 100644 --- a/drivers/gpu/drm/drm_simple_kms_helper.c +++ b/drivers/gpu/drm/drm_simple_kms_helper.c @@ -38,9 +38,10 @@ static const struct drm_encoder_funcs drm_simple_encoder_funcs_cleanup = { }; /** - * drm_simple_encoder_init - Initialize a preallocated encoder + * drm_simple_encoder_init - Initialize a preallocated encoder with + * basic functionality. * @dev: drm device - * @funcs: callbacks for this encoder + * @encoder: the encoder to initialize * @encoder_type: user visible type of the encoder * * Initialises a preallocated encoder that has no further functionality. @@ -48,6 +49,15 @@ static const struct drm_encoder_funcs drm_simple_encoder_funcs_cleanup = { * The encoder will be cleaned up automatically as part of the mode-setting * cleanup. * + * The caller of drm_simple_encoder_init() is responsible for freeing + * the encoder's memory after the encoder has been cleaned up. At the + * moment this only works reliably if the encoder data structure is + * stored in the device structure. Free the encoder's memory as part of + * the device release function. + * + * FIXME: Later improvements to DRM's resource management may allow for + * an automated kfree() of the encoder's memory. + * * Returns: * Zero on success, error code on failure. */ -- 2.25.1

1 0

[PATCH V2 0/2] Add support for WLED5
by Kiran Gunda 04 Mar '20

04 Mar '20

Currently, WLED driver supports only WLED4 peripherals that is present on pmi8998 and pm660L. This patch series converts the existing WLED4 bindings from .txt to .yaml format and adds the support for WLED5 peripheral that is present on PM8150L. PM8150L WLED supports the following. - Two modulators and each sink can use any of the modulator - Multiple CABC selection options - Multiple brightness width selection (12 bits to 15 bits) Changes from V1: - Rebased on top of the below commit. backlight: qcom-wled: Fix unsigned comparison to zero Kiran Gunda (2): backlight: qcom-wled: convert the wled bindings to .yaml format backlight: qcom-wled: Add support for WLED5 peripheral in PM8150L .../bindings/leds/backlight/qcom-wled.txt | 154 ------- .../bindings/leds/backlight/qcom-wled.yaml | 223 ++++++++++ drivers/video/backlight/qcom-wled.c | 459 ++++++++++++++++++--- 3 files changed, 634 insertions(+), 202 deletions(-) delete mode 100644 Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt create mode 100644 Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project

1 2

← Newer
1
...
65
66
67
68
69
70
71
...
78
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel March 2020