dri-devel April 2021

dri-devel@lists.freedesktop.org

317 participants
715 discussions

linux-next: build warnings after merge of the drm tree
by Stephen Rothwell 21 Apr '21

21 Apr '21

Hi all, After merging the drm tree, today's linux-next build (htmldocs) produced these warnings: drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Excess function parameter 'trampoline' description in 'intel_engine_cmd_parser' drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Function parameter or member 'jump_whitelist' not described in 'intel_engine_cmd_parser' drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Function parameter or member 'shadow_map' not described in 'intel_engine_cmd_parser' drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Function parameter or member 'batch_map' not described in 'intel_engine_cmd_parser' drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Excess function parameter 'trampoline' description in 'intel_engine_cmd_parser' Introduced by commit 0edbb9ba1bfe ("drm/i915: Move cmd parser pinning to execbuffer") -- Cheers, Stephen Rothwell

1 1

linux-next: build warning after merge of the drm tree
by Stephen Rothwell 21 Apr '21

21 Apr '21

Hi all, After merging the drm tree, today's linux-next build (htmldocs) produced this warning: drivers/gpu/drm/i915/gem/i915_gem_shrinker.c:102: warning: Function parameter or member 'ww' not described in 'i915_gem_shrink' Introduced by commit cf41a8f1dc1e ("drm/i915: Finally remove obj->mm.lock.") -- Cheers, Stephen Rothwell

1 1

Re: linux-next: build warning after merge of the amdgpu tree
by Stephen Rothwell 21 Apr '21

21 Apr '21

Hi all, On Mon, 22 Mar 2021 17:00:14 +1100 Stephen Rothwell <sfr(a)canb.auug.org.au> wrote: > > After merging the amdgpu tree, today's linux-next build (htmldocs) > produced this warning: > > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h:405: warning: Function parameter or member 'dmcub_trace_event_en' not described in 'amdgpu_display_manager' > > Introduced by commit > > 4057828a1283 ("drm/amd/display: Add debugfs to control DMUB trace buffer events") I am still seeing this warning (as of next-20210420). That is now commit 46a83eba276c ("drm/amd/display: Add debugfs to control DMUB trace buffer events") in the drm tree. -- Cheers, Stephen Rothwell

1 0

Re: linux-next: build warning after merge of the amdgpu tree
by Stephen Rothwell 21 Apr '21

21 Apr '21

Hi all, On Thu, 11 Mar 2021 22:00:33 +1100 Stephen Rothwell <sfr(a)canb.auug.org.au> wrote: > > After merging the amdgpu tree, today's linux-next build (htmldocs) > produced this warning: > > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h:143: warning: Function parameter or member 'list' not described in 'dal_allocation' > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h:143: warning: Function parameter or member 'bo' not described in 'dal_allocation' > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h:143: warning: Function parameter or member 'cpu_ptr' not described in 'dal_allocation' > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h:143: warning: Function parameter or member 'gpu_addr' not described in 'dal_allocation' > > Introduced by commit > > 1ace37b873c2 ("drm/amdgpu/display: Implement functions to let DC allocate GPU memory") I am still seeing these warnings (as of next-20210420). That is now commit 0dd795323405 ("drm/amdgpu/display: Implement functions to let DC allocate GPU memory") in the drm tree. -- Cheers, Stephen Rothwell

1 0

[PATCH v12 0/4] drm/panfrost: Add support for mt8183 GPU
by Nicolas Boichat 21 Apr '21

21 Apr '21

Hi! This is just a rebase of the v11, untested (but it seems like Neil Armstrong recently tested it), with small changes in binding and dts. v11 cover follows: Follow-up on the v5 [1], things have gotten significantly better in the last year, thanks to the efforts on Bifrost support by the Collabora team (and probably others I'm not aware of). I've been testing this series on a MT8183/kukui device, with a chromeos-5.10 kernel [2], and got basic Chromium OS UI up with mesa 20.3.2 (lots of artifacts though). devfreq is currently not supported, as we'll need: - Clock core support for switching the GPU core clock (see 2/4). - Platform-specific handling of the 2-regulator (see 3/4). Since the latter is easy to detect, patch 3/4 just disables devfreq if the more than one regulator is specified in the compatible matching table. [1] https://patchwork.kernel.org/project/linux-mediatek/cover/20200306041345.25… [2] https://crrev.com/c/2608070 Changes in v12: - binding: Fix min/maxItems logic (Rob Herring) - Add gpu node to mt8183-pumpkin.dts as well (Neil Armstrong). Changes in v11: - binding: power-domain-names not power-domainS-names - mt8183*.dts: remove incorrect supply-names Changes in v10: - Fix the binding to make sure sram-supply property can be provided. Changes in v9: - Explain why devfreq needs to be disabled for GPUs with >1 regulators. Changes in v8: - Use DRM_DEV_INFO instead of ERROR Changes in v7: - Fix GPU ID in commit message - Fix GPU ID in commit message Changes in v6: - Rebased, actually tested with recent mesa driver. - Add gpu regulators to kukui dtsi as well. - Power domains are now attached to spm, not scpsys - Drop R-B. - devfreq: New change - Context conflicts, reflow the code. - Use ARRAY_SIZE for power domains too. Changes in v5: - Rename "2d" power domain to "core2" - Rename "2d" power domain to "core2" (keep R-B again). - Change power domain name from 2d to core2. Changes in v4: - Add power-domain-names description (kept Alyssa's reviewed-by as the change is minor) - Add power-domain-names to describe the 3 domains. (kept Alyssa's reviewed-by as the change is minor) - Add power domain names. Changes in v3: - Match mt8183-mali instead of bifrost, as we require special handling for the 2 regulators and 3 power domains. Changes in v2: - Use sram instead of mali_sram as SRAM supply name. - Rename mali@ to gpu@. Nicolas Boichat (4): dt-bindings: gpu: mali-bifrost: Add Mediatek MT8183 arm64: dts: mt8183: Add node for the Mali GPU drm/panfrost: devfreq: Disable devfreq when num_supplies > 1 drm/panfrost: Add mt8183-mali compatible string .../bindings/gpu/arm,mali-bifrost.yaml | 30 ++++- arch/arm64/boot/dts/mediatek/mt8183-evb.dts | 5 + .../arm64/boot/dts/mediatek/mt8183-kukui.dtsi | 5 + .../boot/dts/mediatek/mt8183-pumpkin.dts | 5 + arch/arm64/boot/dts/mediatek/mt8183.dtsi | 105 ++++++++++++++++++ drivers/gpu/drm/panfrost/panfrost_devfreq.c | 16 ++- drivers/gpu/drm/panfrost/panfrost_drv.c | 10 ++ 7 files changed, 172 insertions(+), 4 deletions(-) -- 2.31.1.368.gbe11c130af-goog

1 4

[PATCH v11 0/4] drm/panfrost: Add support for mt8183 GPU
by Nicolas Boichat 21 Apr '21

21 Apr '21

Hi! Follow-up on the v5 [1], things have gotten significantly better in the last 9 months, thanks to the efforts on Bifrost support by the Collabora team (and probably others I'm not aware of). I've been testing this series on a MT8183/kukui device, with a chromeos-5.10 kernel [2], and got basic Chromium OS UI up with mesa 20.3.2 (lots of artifacts though). devfreq is currently not supported, as we'll need: - Clock core support for switching the GPU core clock (see 2/4). - Platform-specific handling of the 2-regulator (see 3/4). Since the latter is easy to detect, patch 3/4 just disables devfreq if the more than one regulator is specified in the compatible matching table. [1] https://patchwork.kernel.org/project/linux-mediatek/cover/20200306041345.25… [2] https://crrev.com/c/2608070 Changes in v11: - binding: power-domain-names not power-domainS-names - mt8183*.dts: remove incorrect supply-names Changes in v10: - Fix the binding to make sure sram-supply property can be provided. Changes in v9: - Explain why devfreq needs to be disabled for GPUs with >1 regulators. Changes in v8: - Use DRM_DEV_INFO instead of ERROR Changes in v7: - Fix GPU ID in commit message - Fix GPU ID in commit message Changes in v6: - Rebased, actually tested with recent mesa driver. - Add gpu regulators to kukui dtsi as well. - Power domains are now attached to spm, not scpsys - Drop R-B. - devfreq: New change - Context conflicts, reflow the code. - Use ARRAY_SIZE for power domains too. Changes in v5: - Rename "2d" power domain to "core2" - Rename "2d" power domain to "core2" (keep R-B again). - Change power domain name from 2d to core2. Changes in v4: - Add power-domain-names description (kept Alyssa's reviewed-by as the change is minor) - Add power-domain-names to describe the 3 domains. (kept Alyssa's reviewed-by as the change is minor) - Add power domain names. Changes in v3: - Match mt8183-mali instead of bifrost, as we require special handling for the 2 regulators and 3 power domains. Changes in v2: - Use sram instead of mali_sram as SRAM supply name. - Rename mali@ to gpu@. Nicolas Boichat (4): dt-bindings: gpu: mali-bifrost: Add Mediatek MT8183 arm64: dts: mt8183: Add node for the Mali GPU drm/panfrost: devfreq: Disable devfreq when num_supplies > 1 drm/panfrost: Add mt8183-mali compatible string .../bindings/gpu/arm,mali-bifrost.yaml | 28 +++++ arch/arm64/boot/dts/mediatek/mt8183-evb.dts | 5 + .../arm64/boot/dts/mediatek/mt8183-kukui.dtsi | 5 + arch/arm64/boot/dts/mediatek/mt8183.dtsi | 105 ++++++++++++++++++ drivers/gpu/drm/panfrost/panfrost_devfreq.c | 9 ++ drivers/gpu/drm/panfrost/panfrost_drv.c | 10 ++ 6 files changed, 162 insertions(+) -- 2.30.0.280.ga3ce27912f-goog

2 8

[PATCH 0/2] drm/bridge: dw-hdmi: disable loading of DW-HDMI CEC sub-driver
by Neil Armstrong 20 Apr '21

20 Apr '21

This adds DW-HDMI driver a glue option to disable loading of the CEC sub-driver. On some SoCs, the CEC functionality is enabled in the IP config bits, but the CEC bus is non-functional like on Amlogic SoCs, where the CEC config bit is set but the DW-HDMI CEC signal is not connected to a physical pin, leading to some confusion when the DW-HDMI CEC controller can't communicate on the bus. Jernej Skrabec (1): drm/bridge/synopsys: dw-hdmi: Add an option to suppress loading CEC driver Neil Armstrong (1): drm/meson: dw-hdmi: disable DW-HDMI CEC sub-driver drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +- drivers/gpu/drm/meson/meson_dw_hdmi.c | 1 + include/drm/bridge/dw_hdmi.h | 2 ++ 3 files changed, 4 insertions(+), 1 deletion(-) -- 2.25.1

4 8

[PATCH v2 0/2] Replace drm_modeset_*_all with DRM_MODESET_LOCK_ALL_*
by Fabio M. De Francesco 20 Apr '21

20 Apr '21

Replace the deprecated API with new helpers, according to the TODO list of the DRM subsystem. The new API has been introduced with commit b7ea04d299c7: DRM_MODESET_LOCK_ALL_BEGIN() simplifies grabbing all modeset locks using a local context. This has the advantage of reducing boilerplate. Changes from v1: Added further information to the commit message. Fabio M. De Francesco (2): drm/amd/amdgpu/amdgpu_device.c: Replace drm_modeset_*_all with DRM_MODESET_LOCK_ALL_* drm/amd/amdgpu/amdgpu_drv.c: Replace drm_modeset_*_all with DRM_MODESET_LOCK_ALL_* drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 18 ++++++++++++------ drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 6 ++++-- 2 files changed, 16 insertions(+), 8 deletions(-) -- 2.31.1

2 4

[PATCH] drm/connector: demote connector force-probes for non-master clients
by Simon Ser 20 Apr '21

20 Apr '21

Force-probing a connector can be slow and cause flickering. As this affects the global KMS state, let's make it so only the DRM master can force-probe a connector. Non-master DRM clients won't be able to force-probe a connector anymore. Instead, KMS will perform a regular read-only connector query. Signed-off-by: Simon Ser <contact(a)emersion.fr> Cc: Daniel Vetter <daniel(a)ffwll.ch> Cc: Pekka Paalanen <ppaalanen(a)gmail.com> --- drivers/gpu/drm/drm_connector.c | 11 ++++++++--- include/uapi/drm/drm_mode.h | 7 ++++--- 2 files changed, 12 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c index 7631f76e7f34..2f70a52a892b 100644 --- a/drivers/gpu/drm/drm_connector.c +++ b/drivers/gpu/drm/drm_connector.c @@ -20,6 +20,7 @@ * OF THIS SOFTWARE. */ +#include <drm/drm_auth.h> #include <drm/drm_connector.h> #include <drm/drm_edid.h> #include <drm/drm_encoder.h> @@ -2374,9 +2375,13 @@ int drm_mode_getconnector(struct drm_device *dev, void *data, mutex_lock(&dev->mode_config.mutex); if (out_resp->count_modes == 0) { - connector->funcs->fill_modes(connector, - dev->mode_config.max_width, - dev->mode_config.max_height); + if (drm_is_current_master(file_priv)) + connector->funcs->fill_modes(connector, + dev->mode_config.max_width, + dev->mode_config.max_height); + else + drm_dbg_kms(dev, "User-space requested a forced probe on [CONNECTOR:%d:%s] but is not the DRM master, demoting to read-only probe", + connector->base.id, connector->name); } out_resp->mm_width = connector->display_info.width_mm; diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h index a5e76aa06ad5..3efa2e38d89b 100644 --- a/include/uapi/drm/drm_mode.h +++ b/include/uapi/drm/drm_mode.h @@ -413,9 +413,10 @@ enum drm_mode_subconnector { * * **Force-probing a connector** * - * If the @count_modes field is set to zero, the kernel will perform a forced - * probe on the connector to refresh the connector status, modes and EDID. - * A forced-probe can be slow, might cause flickering and the ioctl will block. + * If the @count_modes field is set to zero and the DRM client is the DRM + * master, the kernel will perform a forced probe on the connector to refresh + * the connector status, modes and EDID. A forced-probe can be slow, might + * cause flickering and the ioctl will block. * * User-space needs to force-probe connectors to ensure their metadata is * up-to-date at startup and after receiving a hot-plug event. User-space -- 2.31.1

3 6

[PATCH] freedreno/a6xx: Add a few registers
by Akhil P Oommen 20 Apr '21

20 Apr '21

Add a few new registers for a6xx gpu. Signed-off-by: Akhil P Oommen <akhilpo(a)codeaurora.org> --- registers/adreno/a6xx.xml | 2 ++ registers/adreno/a6xx_gmu.xml | 2 ++ 2 files changed, 4 insertions(+) diff --git a/registers/adreno/a6xx.xml b/registers/adreno/a6xx.xml index 15314fb..3b04565 100644 --- a/registers/adreno/a6xx.xml +++ b/registers/adreno/a6xx.xml @@ -1107,6 +1107,7 @@ to upconvert to 32b float internally? <reg32 offset="0x098D" name="CP_AHB_CNTL"/> <reg32 offset="0x0A00" name="CP_APERTURE_CNTL_HOST"/> <reg32 offset="0x0A03" name="CP_APERTURE_CNTL_CD"/> + <reg32 offset="0x0B34" name="CP_LPAC_PROG_FIFO_SIZE"/> <reg32 offset="0x0C01" name="VSC_ADDR_MODE_CNTL" type="a5xx_address_mode"/> <reg32 offset="0x0201" name="RBBM_INT_0_STATUS" type="A6XX_RBBM_INT_0_MASK"/> <reg32 offset="0x0210" name="RBBM_STATUS"> @@ -1740,6 +1741,7 @@ to upconvert to 32b float internally? <reg32 offset="0x3119" name="VBIF_PERF_PWR_CNT_HIGH1"/> <reg32 offset="0x311a" name="VBIF_PERF_PWR_CNT_HIGH2"/> + <reg32 offset="0x3c01" name="GBIF_SCACHE_CNTL0"/> <reg32 offset="0x3c02" name="GBIF_SCACHE_CNTL1"/> <reg32 offset="0x3c03" name="GBIF_QSB_SIDE0"/> <reg32 offset="0x3c04" name="GBIF_QSB_SIDE1"/> diff --git a/registers/adreno/a6xx_gmu.xml b/registers/adreno/a6xx_gmu.xml index dbefd0c..f8bf1fd 100644 --- a/registers/adreno/a6xx_gmu.xml +++ b/registers/adreno/a6xx_gmu.xml @@ -112,6 +112,7 @@ xsi:schemaLocation="http://nouveau.freedesktop.org/ rules-ng.xsd"> <reg32 offset="0x50e9" name="GMU_RPMH_HYST_CTRL"/> <reg32 offset="0x50ec" name="GPU_GMU_CX_GMU_RPMH_POWER_STATE"/> <reg32 offset="0x50f0" name="GPU_GMU_CX_GMU_CX_FAL_INTF"/> + <reg32 offset="0x50f1" name="GPU_GMU_CX_GMU_CX_FALNEXT_INTF"/> <reg32 offset="0x5100" name="GPU_GMU_CX_GMU_PWR_COL_CP_MSG"/> <reg32 offset="0x5101" name="GPU_GMU_CX_GMU_PWR_COL_CP_RESP"/> <reg32 offset="0x51f0" name="GMU_BOOT_KMD_LM_HANDSHAKE"/> @@ -193,6 +194,7 @@ xsi:schemaLocation="http://nouveau.freedesktop.org/ rules-ng.xsd"> <reg32 offset="0x9312" name="GMU_AHB_FENCE_RANGE_1"/> <reg32 offset="0x9c03" name="GPU_CC_GX_GDSCR"/> <reg32 offset="0x9d42" name="GPU_CC_GX_DOMAIN_MISC"/> + <reg32 offset="0xc001" name="GPU_CPR_FSM_CTL"/>  <reg32 offset="0x0004" name="GPU_RSCC_RSC_STATUS0_DRV0"/> -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation.

1 0

← Newer
1
...
35
36
37
38
39
40
41
...
72
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel April 2021