dri-devel October 2019

dri-devel@lists.freedesktop.org

359 participants
1833 discussions

[PATCH] drm/syncobj: include <drm/drm_utils.h> for drm_timeout_abs_to_jiffies
by Ben Dooks (Codethink) 15 Oct '19

15 Oct '19

Include <drm/drm_utils.h> for drm_timeout_abs_to_jiffies definiton to fix the following sparse warning: drivers/gpu/drm/drm_syncobj.c:1019:13: warning: symbol 'drm_timeout_abs_to_jiffies' was not declared. Should it be static? Signed-off-by: Ben Dooks <ben.dooks(a)codethink.co.uk> --- Cc: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> Cc: Maxime Ripard <mripard(a)kernel.org> Cc: Sean Paul <sean(a)poorly.run> Cc: David Airlie <airlied(a)linux.ie> Cc: Daniel Vetter <daniel(a)ffwll.ch> Cc: dri-devel(a)lists.freedesktop.org Cc: linux-kernel(a)vger.kernel.org --- drivers/gpu/drm/drm_syncobj.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c index 4b5c7b0ed714..9ec334663c2d 100644 --- a/drivers/gpu/drm/drm_syncobj.c +++ b/drivers/gpu/drm/drm_syncobj.c @@ -135,6 +135,7 @@ #include <drm/drm_gem.h> #include <drm/drm_print.h> #include <drm/drm_syncobj.h> +#include <drm/drm_utils.h> #include "drm_internal.h" -- 2.23.0

1 0

[PATCH] drm/nouveau/hwmon: fix use of integer as a pointer
by Ben Dooks 15 Oct '19

15 Oct '19

The special_groups[] in nouveau_hwmon_init() is an array of pointers, so use NULL instead of '0' as the initialiser. Fixes the following sparse warning: drivers/gpu/drm/nouveau/nouveau_hwmon.c:744:29: warning: Using plain integer as NULL pointer Signed-off-by: Ben Dooks <ben.dooks(a)codethink.co.uk> --- Cc: Ben Skeggs <bskeggs(a)redhat.com> Cc: David Airlie <airlied(a)linux.ie> Cc: Daniel Vetter <daniel(a)ffwll.ch> Cc: dri-devel(a)lists.freedesktop.org Cc: nouveau(a)lists.freedesktop.org Cc: linux-kernel(a)vger.kernel.org --- drivers/gpu/drm/nouveau/nouveau_hwmon.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_hwmon.c b/drivers/gpu/drm/nouveau/nouveau_hwmon.c index d445c6f3fece..1c3104d20571 100644 --- a/drivers/gpu/drm/nouveau/nouveau_hwmon.c +++ b/drivers/gpu/drm/nouveau/nouveau_hwmon.c @@ -741,7 +741,7 @@ nouveau_hwmon_init(struct drm_device *dev) special_groups[i++] = &pwm_fan_sensor_group; } - special_groups[i] = 0; + special_groups[i] = NULL; hwmon_dev = hwmon_device_register_with_info(dev->dev, "nouveau", dev, &nouveau_chip_info, special_groups); -- 2.23.0

1 0

[PATCH] drm: include <drm/drm_fb_cma_helper.h> for missing declarations
by Ben Dooks 15 Oct '19

15 Oct '19

Include <drm/drm_fb_cma_helper.h> to get the definitions of drm_fb_cma_get_gem_{addr,obj} functions to fix the following sparse warnings: drivers/gpu/drm/drm_fb_cma_helper.c:38:27: warning: symbol 'drm_fb_cma_get_gem_obj' was not declared. Should it be static? drivers/gpu/drm/drm_fb_cma_helper.c:62:12: warning: symbol 'drm_fb_cma_get_gem_addr' was not declared. Should it be static? Signed-off-by: Ben Dooks <ben.dooks(a)codethink.co.uk> --- Cc: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> Cc: Maxime Ripard <mripard(a)kernel.org> Cc: Sean Paul <sean(a)poorly.run> Cc: David Airlie <airlied(a)linux.ie> Cc: Daniel Vetter <daniel(a)ffwll.ch> Cc: dri-devel(a)lists.freedesktop.org Cc: linux-kernel(a)vger.kernel.org --- drivers/gpu/drm/drm_fb_cma_helper.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c b/drivers/gpu/drm/drm_fb_cma_helper.c index c0b0f603af63..f4967cf14f99 100644 --- a/drivers/gpu/drm/drm_fb_cma_helper.c +++ b/drivers/gpu/drm/drm_fb_cma_helper.c @@ -11,6 +11,7 @@ #include <drm/drm_fourcc.h> #include <drm/drm_framebuffer.h> +#include <drm/drm_fb_cma_helper.h> #include <drm/drm_gem_cma_helper.h> #include <drm/drm_gem_framebuffer_helper.h> #include <drm/drm_plane.h> -- 2.23.0

1 0

[PATCH] drm/nouveau/disp/gv100: make gv100_disp_core_mthd_{base, sor} static
by Ben Dooks 15 Oct '19

15 Oct '19

The gv100_disp_core_mthd_{base,sor} are not used outside of the file they are defined in, so make them static to avoid the following sparse warning: drivers/gpu/drm/nouveau/nvkm/engine/disp/coregv100.c:27:1: warning: symbol 'gv100_disp_core_mthd_base' was not declared. Should it be static? drivers/gpu/drm/nouveau/nvkm/engine/disp/coregv100.c:43:1: warning: symbol 'gv100_disp_core_mthd_sor' was not declared. Should it be static? Signed-off-by: Ben Dooks <ben.dooks(a)codethink.co.uk> --- Bad divisor in main::vcs_assign: 0 Cc: Ben Skeggs <bskeggs(a)redhat.com> Cc: David Airlie <airlied(a)linux.ie> Cc: Daniel Vetter <daniel(a)ffwll.ch> Cc: dri-devel(a)lists.freedesktop.org Cc: nouveau(a)lists.freedesktop.org Cc: linux-kernel(a)vger.kernel.org --- drivers/gpu/drm/nouveau/nvkm/engine/disp/coregv100.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/coregv100.c b/drivers/gpu/drm/nouveau/nvkm/engine/disp/coregv100.c index 4592d0e69fec..9594ba732113 100644 --- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/coregv100.c +++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/coregv100.c @@ -23,7 +23,7 @@ #include <subdev/timer.h> -const struct nv50_disp_mthd_list +static const struct nv50_disp_mthd_list gv100_disp_core_mthd_base = { .mthd = 0x0000, .addr = 0x000000, @@ -39,7 +39,7 @@ gv100_disp_core_mthd_base = { } }; -const struct nv50_disp_mthd_list +static const struct nv50_disp_mthd_list gv100_disp_core_mthd_sor = { .mthd = 0x0020, .addr = 0x000020, -- 2.23.0

1 0

[PATCH v9 0/8] drm/i915/dp: Support for DP HDR outputs
by Gwan-gyeong Mun 15 Oct '19

15 Oct '19

Support for HDR10 video was introduced in DisplayPort 1.4. On GLK+ platform, in order to use DisplayPort HDR10, we need to support BT.2020 colorimetry and HDR Static metadata. It implements the CTA-861-G standard for transport of static HDR metadata. It enables writing of HDR metadata infoframe SDP to the panel. The HDR Metadata will be provided by userspace compositors, based on blending policies and passed to the driver through a blob property. And It refactors, renames and extends a function which handled vsc sdp header and data block setup for supporting colorimetry format. And It attaches the colorspace connector property and HDR metadata property to a DisplayPort connector. These patches tested on below test environment. Test Environment: - Tested System: GLK and Gen11 platform. - Monitor: Dell UP2718Q 4K HDR Monitor. - In order to test DP HDR10, test environment uses patched Kodi-gbm, patched Media driver and HDR10 video. You can find these on below. [patched Kodi-gbm] - repo: https://github.com/Kwiboo/xbmc/tree/drmprime-hdr [download 4K HDR video file] - link: https://4kmedia.org/lg-new-york-hdr-uhd-4k-demo/ [Media Driver for GLK] - repo https://gitlab.freedesktop.org/emersion/intel-vaapi-driver master branch [Media Driver for ICL] - repo: https://github.com/harishkrupo/media-driver/tree/p010_composite v2: - Add a missed blank line after function declaration. - Remove useless parentheses. - Minor style fix. v3: - Remove not handled return values from intel_dp_setup_hdr_metadata_infoframe_sdp(). [Uma] - Add handling of different register size for HDMI_PACKET_TYPE_GAMUT_METADATA on hsw_dip_data_size() for each GEN platforms [Uma] - Add new colorimetry options for DP 1.4a spec. [Ville] - Separate set of colorimetry enum values for DP. [Ville] - In order to checking output format and output colorspace on intel_dp_needs_vsc_sdp(), it passes entire intel_crtc_state stucture.[Ville] - Remove a pointless variable. [Ville] v4: - Add additional comments to struct drm_prop_enum_list. - Polishing an enum string of struct drm_prop_enum_list. v5: - Change definitions of DRM_MODE_COLORIMETRYs to follow HDMI prefix and DP abbreviations. - Add missed variables on dp_colorspaces. - Fix typo. [Uma] v6: - Addressed review comments from Ilia and Ville Split drm_mode_create_colorspace_property() to DP and HDMI connector. Becasue between HDMI and DP have different colorspaces, it renames drm_mode_create_colorspace_property() function to drm_mode_create_hdmi_colorspace_property() function for HDMI connector. And it adds drm_mode_create_dp_colorspace_property() function for creating of DP colorspace property. In order to apply changed and added drm api, i915 driver has channged. v7: - Fix typo [Jani Saarinen] - Fix white space. v8: - Addressed review comments from Ville Drop colorimetries which have another way to distinguish or which would not be used. v9: - Addressed review comments from Ville - Remove a duplicated output color space from intel_crtc_state. - In order to handle colorspace of drm_connector_state, it moves a calling of intel_ddi_set_pipe_settings() function into intel_ddi_pre_enable_dp() - Split hunk into renaming and adding of code. - Add a handling of drm_mode_create_dp_colorspace_property() to intel_attach_colorspace_property(). - Add WARN_ON() when buffer size if larger than register size. - Add BUILD_BUG_ON to check a changing of struct dp_sdp size. - Change a passed size toward write_infoframe() for DP infoframe sdp packet for HDR static metadata. Gwan-gyeong Mun (8): drm/i915/dp: Extend program of VSC Header and DB for Colorimetry Format drm/i915/dp: Add support of BT.2020 Colorimetry to DP MSA drm: Rename HDMI colorspace property creation function drm: Add DisplayPort colorspace property creation function drm/i915/dp: Attach colorspace property drm/i915: Add new GMP register size for GEN11 drm/i915/dp: Program an Infoframe SDP Header and DB for HDR Static Metadata drm/i915/dp: Attach HDR metadata property to DP connector drivers/gpu/drm/drm_connector.c | 101 +++++++-- .../gpu/drm/i915/display/intel_connector.c | 21 +- drivers/gpu/drm/i915/display/intel_ddi.c | 17 +- drivers/gpu/drm/i915/display/intel_ddi.h | 3 +- drivers/gpu/drm/i915/display/intel_display.c | 1 - drivers/gpu/drm/i915/display/intel_display.h | 2 - drivers/gpu/drm/i915/display/intel_dp.c | 196 ++++++++++++++++-- drivers/gpu/drm/i915/display/intel_dp.h | 8 + drivers/gpu/drm/i915/display/intel_hdmi.c | 12 +- drivers/gpu/drm/i915/i915_reg.h | 1 + include/drm/drm_connector.h | 7 +- 11 files changed, 323 insertions(+), 46 deletions(-) -- 2.23.0

2 10

[PATCH 1/3 v2] drm/panel: Add generic DSI panel YAML bindings
by Linus Walleij 15 Oct '19

15 Oct '19

This adds a starting point for processing and defining generic bindings used by DSI panels. We just define one single bool property to force the panel into video mode for now. Cc: devicetree(a)vger.kernel.org Suggested-by: Rob Herring <robh(a)kernel.org> Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org> --- ChangeLog v1->v2: - New patch after feedback. --- .../display/panel/panel-dsi-common.yaml | 31 +++++++++++++++++++ 1 file changed, 31 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/panel-dsi-common.yaml diff --git a/Documentation/devicetree/bindings/display/panel/panel-dsi-common.yaml b/Documentation/devicetree/bindings/display/panel/panel-dsi-common.yaml new file mode 100644 index 000000000000..4242dc25c917 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/panel-dsi-common.yaml @@ -0,0 +1,31 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/panel-dsi-common.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Common Properties for DSI Display Panels + +maintainers: + - Linus Walleij <linus.walleij(a)linaro.org> + +description: | + This document defines device tree properties common to DSI, Display + Serial Interface panels. It doesn't constitue a device tree binding + specification by itself but is meant to be referenced by device tree + bindings. + + When referenced from panel device tree bindings the properties defined in + this document are defined as follows. The panel device tree bindings are + responsible for defining whether each property is required or optional. + +properties: + + enforce-video-mode: + type: boolean + description: + The best option is usually to run a panel in command mode, as this + gives better control over the panel hardware. However for different + reasons like broken hardware, missing features or testing, it may be + useful to be able to force a command mode-capable panel into video + mode. -- 2.21.0

2 3

[PATCH 0/7] drm/meson: add AFBC support
by Neil Armstrong 15 Oct '19

15 Oct '19

This adds support for the ARM Framebuffer Compression decoders found in the Amlogic GXM and G12A SoCs. The Amlogic GXM and G12A AFBC decoder are totally different, the GXM only handling only the AFBC v1.0 modes and the G12A decoder handling the AFBC v1.2 modes. The G12A AFBC decoder is an external IP integrated in the video pipeline, and the GXM AFBC decoder seems to the an Amlogic custom decoder more tighly integrated in the video pipeline. The GXM AFBC decoder can handle only one AFBC plane for 2 available OSD planes available in HW, and the G12A AFBC decoder can handle up to 4 AFBC planes for up to 3 OSD planes available in HW. The Amlogic GXM supports 16x16 SPARSE and 16x16 SPLIT AFBC buffers up to 4k. On the other side, for G12A SPLIT is mandatory in 16x16 block mode, but for 4k modes 32x8+SPLIT AFBC buffers is manadatory for performances reasons. The Amlogic GXM and G12A AFBC decoders are integrated very differently. The Amlogic GXM has a direct output path to the OSD1 VIU pixel input, because the GXM AFBC decoder seem to be a custom IP developed by Amlogic. On the other side, the Amlogic G12A AFBC decoder seems to be an external IP that emit pixels on an AXI master hooked to a "Mali Unpack" block feeding the OSD1 VIU pixel input. This uses a weird "0x1000000" internal HW physical address on both sides to transfer the pixels. For Amlogic GXM, the supported pixel formats are the same as the normal linear OSD1 mode. On the other side, Amlogic added support for all AFBC v1.2 formats for the G12A AFBC integration. For testing, the only available AFBC buffer generation is the Android Yukawa Dvalin Android Mali blobs found at [1]. Both SoCs has been tested using buffers generated under AOSP, but only G12A was tested using a runtime stream of AFBC buffers, GXM was only tested using static buffers loaded from files. [1] https://android.googlesource.com/device/amlogic/yukawa/+/refs/heads/master/… Neil Armstrong (7): drm/meson: add AFBC decoder registers for GXM and G12A drm/meson: store the framebuffer width for plane commit drm/meson: Add AFBCD module driver drm/meson: plane: add support for AFBC mode for OSD1 plane drm/meson: viu: add AFBC modules routing functions drm/meson: hold 32 lines after vsync to give time for AFBC start drm/meson: crtc: add OSD1 plane AFBC commit drivers/gpu/drm/meson/Makefile | 1 + drivers/gpu/drm/meson/meson_crtc.c | 81 +++++- drivers/gpu/drm/meson/meson_drv.c | 38 ++- drivers/gpu/drm/meson/meson_drv.h | 17 ++ drivers/gpu/drm/meson/meson_osd_afbcd.c | 370 ++++++++++++++++++++++++ drivers/gpu/drm/meson/meson_osd_afbcd.h | 28 ++ drivers/gpu/drm/meson/meson_plane.c | 216 ++++++++++++-- drivers/gpu/drm/meson/meson_registers.h | 61 ++++ drivers/gpu/drm/meson/meson_viu.c | 54 +++- drivers/gpu/drm/meson/meson_viu.h | 19 ++ 10 files changed, 842 insertions(+), 43 deletions(-) create mode 100644 drivers/gpu/drm/meson/meson_osd_afbcd.c create mode 100644 drivers/gpu/drm/meson/meson_osd_afbcd.h -- 2.22.0

5 21

[PATCH] drm/omapdrm: Fix trivial spelling
by Kieran Bingham 15 Oct '19

15 Oct '19

Fix trivial spelling identified while examining the code. s/supprted./supported./ Signed-off-by: Kieran Bingham <kieran.bingham+renesas(a)ideasonboard.com> --- drivers/gpu/drm/omapdrm/omap_crtc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c b/drivers/gpu/drm/omapdrm/omap_crtc.c index 3c5ddbf30e97..fce7e944a280 100644 --- a/drivers/gpu/drm/omapdrm/omap_crtc.c +++ b/drivers/gpu/drm/omapdrm/omap_crtc.c @@ -831,7 +831,7 @@ struct drm_crtc *omap_crtc_init(struct drm_device *dev, * OMAP_DSS_CHANNEL_DIGIT. X server assumes 256 element gamma * tables so lets use that. Size of HW gamma table can be * extracted with dispc_mgr_gamma_size(). If it returns 0 - * gamma table is not supprted. + * gamma table is not supported. */ if (priv->dispc_ops->mgr_gamma_size(priv->dispc, channel)) { unsigned int gamma_lut_size = 256; -- 2.20.1

1 0

[PATCH v3 0/7] DRM/MSM: Add support for MSM8956 and Adreno 510
by kholk11＠gmail.com 15 Oct '19

15 Oct '19

From: AngeloGioacchino Del Regno <kholk11(a)gmail.com> This patch series enables support for MSM8956/76 and its Adreno 510 GPU on the current DRM driver. The personal aim is to upstream MSM8956 as much as possible. This code has been tested on two Sony phones featuring the Qualcomm MSM8956 SoC. Changes in v2: - MDP5: Documented tbu and tbu_rt clocks (Jeffrey) - Adreno510: - Lower case hex where required (Jordan) - Direct register writes (Jordan) - Used gpu_rmw() where required (Jordan) - No mentioning of unsupported A5xx (Jordan) - ZAP firmware exclusions not per-model (Rob) Changes in v3: - Rebased onto linux-next 20191015 - Renamed MSM8x56 references to MSM8x76 (the reason is that I am using the 8976/8x76 name for all the other drivers. Also, the 8976 and 8956 chips are equal and the only changing part is the CPU big cores count) - Splitted dt-bindings modifications as per request (Sean) AngeloGioacchino Del Regno (4): drm/msm/mdp5: Add optional TBU and TBU_RT clocks dt-bindings: msm/mdp5: Document optional TBU and TBU_RT clocks drm/msm/mdp5: Add configuration for msm8x76 drm/msm/dsi: Add configuration for 28nm PLL on family B dt-bindings: msm/dsi: Add 28nm PLL for family B compatible drm/msm/dsi: Add configuration for 8x76 drm/msm/adreno: Add support for Adreno 510 GPU .../devicetree/bindings/display/msm/dsi.txt | 1 + .../devicetree/bindings/display/msm/mdp5.txt | 2 + drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 73 +++++++++++--- drivers/gpu/drm/msm/adreno/a5xx_power.c | 7 ++ drivers/gpu/drm/msm/adreno/adreno_device.c | 15 +++ drivers/gpu/drm/msm/adreno/adreno_gpu.h | 5 + drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c | 98 +++++++++++++++++++ drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 10 ++ drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.h | 2 + drivers/gpu/drm/msm/dsi/dsi_cfg.c | 22 +++++ drivers/gpu/drm/msm/dsi/dsi_cfg.h | 1 + drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 2 + drivers/gpu/drm/msm/dsi/phy/dsi_phy.h | 1 + drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c | 18 ++++ 14 files changed, 243 insertions(+), 14 deletions(-) -- 2.21.0

1 7

[PATCH] drm/komeda: Adds output-color format/depth support
by Lowry Li (Arm Technology China) 15 Oct '19

15 Oct '19

From: "Lowry Li (Arm Technology China)" <Lowry.Li(a)arm.com> Sets color_depth according to connector->bpc. Adds a new optional DT attribute "color-format" to represent a preferred color formats for a specific pipeline, and the select order is: YCRCB420 > YCRCB422 > YCRCB444 > RGB444 The color-format can be anyone of these 4 format, one color-format not only represent one format, but also include the lower formats, like color-format preferred_color_formats YCRCB420 YCRCB420 > YCRCB422 > YCRCB444 > RGB444 YCRCB422 YCRCB422 > YCRCB444 > RGB444 YCRCB444 YCRCB444 > RGB444 RGB444 RGB444 Then the final color_format is calculated by 3 steps: 1. calculate HW available formats. avail_formats = connector_color_formats & improc->color_formats; 2. filter out un-preferred format. avail_formats &= preferred_color_formats; 3. select the final format according to the preferred order. color_format = BIT(__fls(aval_formats)); Changes since v1: Rebased to the drm-misc-next branch. Signed-off-by: Lowry Li (Arm Technology China) <lowry.li(a)arm.com> --- .../arm/display/komeda/d71/d71_component.c | 15 ++++++++- .../gpu/drm/arm/display/komeda/komeda_crtc.c | 27 ++++++++++++++++ .../gpu/drm/arm/display/komeda/komeda_dev.c | 32 ++++++++++++++++++- .../gpu/drm/arm/display/komeda/komeda_kms.h | 2 ++ .../drm/arm/display/komeda/komeda_pipeline.h | 3 ++ .../display/komeda/komeda_pipeline_state.c | 31 ++++++++++++++++++ .../arm/display/komeda/komeda_wb_connector.c | 5 +++ 7 files changed, 113 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c index c3d29c0b051b..7b374a3b911e 100644 --- a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c +++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c @@ -944,13 +944,26 @@ static void d71_improc_update(struct komeda_component *c, { struct komeda_improc_state *st = to_improc_st(state); u32 __iomem *reg = c->reg; - u32 index; + u32 index, mask = 0, ctrl = 0; for_each_changed_input(state, index) malidp_write32(reg, BLK_INPUT_ID0 + index * 4, to_d71_input_id(state, index)); malidp_write32(reg, BLK_SIZE, HV_SIZE(st->hsize, st->vsize)); + malidp_write32(reg, IPS_DEPTH, st->color_depth); + + mask |= IPS_CTRL_YUV | IPS_CTRL_CHD422 | IPS_CTRL_CHD420; + + /* config color format */ + if (st->color_format == DRM_COLOR_FORMAT_YCRCB420) + ctrl |= IPS_CTRL_YUV | IPS_CTRL_CHD422 | IPS_CTRL_CHD420; + else if (st->color_format == DRM_COLOR_FORMAT_YCRCB422) + ctrl |= IPS_CTRL_YUV | IPS_CTRL_CHD422; + else if (st->color_format == DRM_COLOR_FORMAT_YCRCB444) + ctrl |= IPS_CTRL_YUV; + + malidp_write32_mask(reg, BLK_CONTROL, mask, ctrl); } static void d71_improc_dump(struct komeda_component *c, struct seq_file *sf) diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c index 624d257da20f..38d5cb20e908 100644 --- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c +++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c @@ -18,6 +18,33 @@ #include "komeda_dev.h" #include "komeda_kms.h" +void komeda_crtc_get_color_config(struct drm_crtc_state *crtc_st, + u32 *color_depths, u32 *color_formats) +{ + struct drm_connector *conn; + struct drm_connector_state *conn_st; + u32 conn_color_formats = ~0u; + int i, min_bpc = 31, conn_bpc = 0; + + for_each_new_connector_in_state(crtc_st->state, conn, conn_st, i) { + if (conn_st->crtc != crtc_st->crtc) + continue; + + conn_bpc = conn->display_info.bpc ? conn->display_info.bpc : 8; + conn_color_formats &= conn->display_info.color_formats; + + if (conn_bpc < min_bpc) + min_bpc = conn_bpc; + } + + /* connector doesn't config any color_format, use RGB444 as default */ + if (conn_color_formats == 0) + conn_color_formats = DRM_COLOR_FORMAT_RGB444; + + *color_depths = GENMASK(conn_bpc, 0); + *color_formats = conn_color_formats; +} + static void komeda_crtc_update_clock_ratio(struct komeda_crtc_state *kcrtc_st) { u64 pxlclk, aclk; diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c index 9cbcd56e54cd..bee4633cdd9f 100644 --- a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c +++ b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c @@ -113,12 +113,34 @@ static struct attribute_group komeda_sysfs_attr_group = { .attrs = komeda_sysfs_entries, }; +static int to_color_format(const char *str) +{ + int format; + + if (!strncmp(str, "RGB444", 7)) { + format = DRM_COLOR_FORMAT_RGB444; + } else if (!strncmp(str, "YCRCB444", 9)) { + format = DRM_COLOR_FORMAT_YCRCB444; + } else if (!strncmp(str, "YCRCB422", 9)) { + format = DRM_COLOR_FORMAT_YCRCB422; + } else if (!strncmp(str, "YCRCB420", 9)) { + format = DRM_COLOR_FORMAT_YCRCB420; + } else { + DRM_WARN("invalid color_format: %s, please set it to RGB444, YCRCB444, YCRCB422 or YCRCB420\n", + str); + format = DRM_COLOR_FORMAT_RGB444; + } + + return format; +} + static int komeda_parse_pipe_dt(struct komeda_dev *mdev, struct device_node *np) { struct komeda_pipeline *pipe; struct clk *clk; u32 pipe_id; - int ret = 0; + int ret = 0, color_format; + const char *str; ret = of_property_read_u32(np, "reg", &pipe_id); if (ret != 0 || pipe_id >= mdev->n_pipelines) @@ -133,6 +155,14 @@ static int komeda_parse_pipe_dt(struct komeda_dev *mdev, struct device_node *np) } pipe->pxlclk = clk; + /* fetch DT configured color-format, if not set, use RGB444 */ + if (!of_property_read_string(np, "color-format", &str)) + color_format = to_color_format(str); + else + color_format = DRM_COLOR_FORMAT_RGB444; + + pipe->improc->preferred_color_formats = (color_format << 1) - 1; + /* enum ports */ pipe->of_output_links[0] = of_graph_get_remote_node(np, KOMEDA_OF_PORT_OUTPUT, 0); diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.h b/drivers/gpu/drm/arm/display/komeda/komeda_kms.h index 45c498e15e7a..456f3c435719 100644 --- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.h +++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.h @@ -166,6 +166,8 @@ static inline bool has_flip_h(u32 rot) return !!(rotation & DRM_MODE_REFLECT_X); } +void komeda_crtc_get_color_config(struct drm_crtc_state *crtc_st, + u32 *color_depths, u32 *color_formats); unsigned long komeda_crtc_get_aclk(struct komeda_crtc_state *kcrtc_st); int komeda_kms_setup_crtcs(struct komeda_kms_dev *kms, struct komeda_dev *mdev); diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h index a7a84e66549d..910d279ae48d 100644 --- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h +++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h @@ -315,6 +315,8 @@ struct komeda_splitter_state { struct komeda_improc { struct komeda_component base; u32 supported_color_formats; /* DRM_RGB/YUV444/YUV420*/ + /* the preferred order is from MSB to LSB YUV420 --> RGB444 */ + u32 preferred_color_formats; u32 supported_color_depths; /* BIT(8) | BIT(10)*/ u8 supports_degamma : 1; u8 supports_csc : 1; @@ -323,6 +325,7 @@ struct komeda_improc { struct komeda_improc_state { struct komeda_component_state base; + u8 color_format, color_depth; u16 hsize, vsize; }; diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c index ea26bc9c2d00..5526731f5a33 100644 --- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c +++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c @@ -743,6 +743,7 @@ komeda_improc_validate(struct komeda_improc *improc, struct komeda_data_flow_cfg *dflow) { struct drm_crtc *crtc = kcrtc_st->base.crtc; + struct drm_crtc_state *crtc_st = &kcrtc_st->base; struct komeda_component_state *c_st; struct komeda_improc_state *st; @@ -756,6 +757,36 @@ komeda_improc_validate(struct komeda_improc *improc, st->hsize = dflow->in_w; st->vsize = dflow->in_h; + if (drm_atomic_crtc_needs_modeset(crtc_st)) { + u32 output_depths, output_formats; + u32 avail_depths, avail_formats; + + komeda_crtc_get_color_config(crtc_st, &output_depths, + &output_formats); + + avail_depths = output_depths & improc->supported_color_depths; + if (avail_depths == 0) { + DRM_DEBUG_ATOMIC("No available color depths, conn depths: 0x%x & display: 0x%x\n", + output_depths, + improc->supported_color_depths); + return -EINVAL; + } + + avail_formats = output_formats & + improc->supported_color_formats & + improc->preferred_color_formats; + if (avail_formats == 0) { + DRM_DEBUG_ATOMIC("No available color_formats, conn formats 0x%x & display: 0x%x & preferred: 0x%x\n", + output_formats, + improc->supported_color_formats, + improc->preferred_color_formats); + return -EINVAL; + } + + st->color_depth = __fls(avail_depths); + st->color_format = BIT(__fls(avail_formats)); + } + komeda_component_add_input(&st->base, &dflow->input, 0); komeda_component_set_output(&dflow->input, &improc->base, 0); diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c b/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c index 617e1f7b8472..49e5469ba48e 100644 --- a/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c +++ b/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c @@ -142,6 +142,7 @@ static int komeda_wb_connector_add(struct komeda_kms_dev *kms, struct komeda_dev *mdev = kms->base.dev_private; struct komeda_wb_connector *kwb_conn; struct drm_writeback_connector *wb_conn; + struct drm_display_info *info; u32 *formats, n_formats = 0; int err; @@ -171,6 +172,10 @@ static int komeda_wb_connector_add(struct komeda_kms_dev *kms, drm_connector_helper_add(&wb_conn->base, &komeda_wb_conn_helper_funcs); + info = &kwb_conn->base.base.display_info; + info->bpc = __fls(kcrtc->master->improc->supported_color_depths); + info->color_formats = kcrtc->master->improc->supported_color_formats; + kcrtc->wb_conn = kwb_conn; return 0; -- 2.17.1

5 10

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel October 2019