Re: [PATCH] drm/msm: fix the `CRASHDUMP_READ` target of `a6xx_get_shader_block()`
On Sat, 30 Mar 2024 at 04:39, Abhinav Kumar wrote:
>
>
>
> On 3/26/2024 2:23 PM, Miguel Ojeda wrote:
> > Clang 14 in an (essentially) defconfig arm64 build for next-20240326
> > reports [1]:
> >
> > drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c:843:6: error:
> > variable 'out' set but not used [-Werror,-Wunused-but-set-variable]
> >
> > The variable `out` in these functions is meant to compute the `target` of
> > `CRASHDUMP_READ()`, but in this case only the initial value (`dumper->iova
> > + A6XX_CD_DATA_OFFSET`) was being passed.
> >
> > Thus use `out` as it was intended by Connor [2].
> >
> > There was an alternative patch at [3] that removed the variable
> > altogether, but that would only use the initial value.
> >
> > Fixes: 64d6255650d4 ("drm/msm: More fully implement devcoredump for a7xx")
> > Closes:
> > https://lore.kernel.org/lkml/caniq72mjc5t4n25sqvysroehxxpxypz4ppznesjhenc3qap...@mail.gmail.com/
> > [1]
> > Link:
> > https://lore.kernel.org/lkml/cacu1e7hhckmjd6fixzspinaz6ekoznkmthtclfvmbz-9vol...@mail.gmail.com/
> > [2]
> > Link:
> > https://lore.kernel.org/lkml/20240307093727.1978126-1-colin.i.k...@gmail.com/
> > [3]
> > Signed-off-by: Miguel Ojeda
> > ---
>
>
> LGTM,
>
> Reviewed-by: Abhinav Kumar
I'm seeing this on my drm-next tree, where is this fix landing?
Dave.
RE: [PATCH 00/11] drm/exynos: drop driver owner initialization
Hi Krzysztof, > -Original Message- > From: Krzysztof Kozlowski > Sent: Sunday, March 31, 2024 5:33 AM > To: Inki Dae ; Seung-Woo Kim > ; Kyungmin Park ; David > Airlie ; Daniel Vetter ; Krzysztof > Kozlowski ; Alim Akhtar > > Cc: dri-devel@lists.freedesktop.org; linux-arm-ker...@lists.infradead.org; > linux-samsung-...@vger.kernel.org; linux-ker...@vger.kernel.org > Subject: [PATCH 00/11] drm/exynos: drop driver owner initialization > > Simplify the code by dropping unnecessary .owner initialization in the > driver. Applied. Thanks. :) Inki Dae > > Best regards, > Krzysztof > > --- > Krzysztof Kozlowski (11): > drm/exynos: fimc: drop driver owner initialization > drm/exynos: fimd: drop driver owner initialization > drm/exynos: dsi: drop driver owner initialization > drm/exynos: g2d: drop driver owner initialization > drm/exynos: gsc: drop driver owner initialization > drm/exynos: mic: drop driver owner initialization > drm/exynos: rotator: drop driver owner initialization > drm/exynos: scaler: drop driver owner initialization > drm/exynos: vidi: drop driver owner initialization > drm/exynos: hdmi: drop driver owner initialization > drm/exynos: mixer: drop driver owner initialization > > drivers/gpu/drm/exynos/exynos_drm_dsi.c | 1 - > drivers/gpu/drm/exynos/exynos_drm_fimc.c| 1 - > drivers/gpu/drm/exynos/exynos_drm_fimd.c| 1 - > drivers/gpu/drm/exynos/exynos_drm_g2d.c | 1 - > drivers/gpu/drm/exynos/exynos_drm_gsc.c | 1 - > drivers/gpu/drm/exynos/exynos_drm_mic.c | 1 - > drivers/gpu/drm/exynos/exynos_drm_rotator.c | 1 - > drivers/gpu/drm/exynos/exynos_drm_scaler.c | 1 - > drivers/gpu/drm/exynos/exynos_drm_vidi.c| 1 - > drivers/gpu/drm/exynos/exynos_hdmi.c| 1 - > drivers/gpu/drm/exynos/exynos_mixer.c | 1 - > 11 files changed, 11 deletions(-) > --- > base-commit: 7fdcff3312e16ba8d1419f8a18f465c5cc235ecf > change-id: 20240330-b4-module-owner-drm-exynos-d2f1b2d48af3 > > Best regards, > -- > Krzysztof Kozlowski >
Re: [PATCH v2 0/4] drm/xe: Support PCIe FLR
On 05/04/24 03:55, Rodrigo Vivi wrote: > On Tue, Apr 02, 2024 at 02:28:55PM +0530, Aravind Iddamsetty wrote: >> PCI subsystem provides callbacks to inform the driver about a request to >> do function level reset by user, initiated by writing to sysfs entry >> /sys/bus/pci/devices/.../reset. This will allow the driver to handle FLR >> without the need to do unbind and rebind as the driver needs to >> reinitialize the device afresh post FLR. >> >> v2: > all the patches looks good to me here. feel free to use > > Reviewed-by: Rodrigo Vivi > > on them. Thank you! > > but I do have some concerns (below) > >> 1. Directly expose the devm_drm_dev_release_action instead of introducing >> a helper (Rodrigo) >> 2. separate out gt idle and pci save/restore to a separate patch (Lucas) >> 3. Fixed the warnings seen around xe_guc_submit_stop, xe_guc_puc_fini > On this I also had to fight to get something working on the wedged_mode=2: > lore.kernel.org/all/20240403150732.102678-4-rodrigo.v...@intel.com > > perhaps we can unify things here. I guess we dealing with different scenarios, in this the warning in xe_guc_submit_stop was because not invoking xe_uc_reset_prepare before. and we needn't invoke xe_guc_pc_fini as guc is already in stopped. > >> Cc: Rodrigo Vivi >> Cc: Lucas De Marchi >> >> dmesg snip showing FLR recovery: > things came different at my DG2 here with display working and all: after you mentioned this i tested on DG2 i got warnings but no segmentation fault and NPD, i have tested my branch which might not be update to date, will re test with the latest branch. Thanks, Aravnd. > > root@rdvivi-desk:/sys/module/xe/drivers/pci:xe/:03:00.0# echo 1 > reset > Segmentation fault > > and many kernel warnings > WARNING: CPU: 8 PID: 2389 at > drivers/gpu/drm/i915/display/intel_display_power_well.c:281 > hsw_wait_for_power_well_enable+0x3e7/0x570 [xe] > WARNING: CPU: 9 PID: 1700 at drivers/gpu/drm/drm_mm.c:999 > drm_mm_takedown+0x41/0x60 > > [ 117.128330] KASAN: null-ptr-deref in range > [0x04e8-0x04ef] > [ 117.128332] CPU: 13 PID: 2389 Comm: bash Tainted: GW > 6.9.0-rc1+ #9 > [ 117.135501] ? exc_invalid_op+0x13/0x40 > [ 117.143626] Hardware name: iBUYPOWER INTEL/B660 DS3H AC DDR4-Y1, BIOS F5 > 12/17/2021 > [ 117.143627] RIP: 0010:__mutex_lock+0x124/0x14a0 > [ 117.143631] Code: d0 7c 08 84 d2 0f 85 62 0f 00 00 8b 0d 85 c8 8f 04 85 c9 > 75 29 48 b8 00 00 00 00 00 fc ff df 49 8d 7f 68 48 89 fa 48 c1 ea 03 <80> 3c > 02 00 0f 85 46 0f 00 00 4d 3b 7f 68 0f 85 aa 0e 00 00 bf 01 > [ 117.150630] ? asm_exc_invalid_op+0x16/0x20 > [ 117.156401] RSP: 0018:c90005a37690 EFLAGS: 00010202 > [ 117.156403] RAX: dc00 RBX: RCX: > > [ 117.163571] ? drm_buddy_fini+0x181/0x220 > > > and more issues. > > so it looks like we are still missing some parts of the puzzle here... > > >> [ 590.486336] xe :4d:00.0: enabling device (0140 -> 0142) >> [ 590.506933] xe :4d:00.0: [drm] Using GuC firmware from >> xe/pvc_guc_70.20.0.bin version 70.20.0 >> [ 590.542355] xe :4d:00.0: [drm] Using GuC firmware from >> xe/pvc_guc_70.20.0.bin version 70.20.0 >> [ 590.578532] xe :4d:00.0: [drm] VISIBLE VRAM: 0x2020, >> 0x0020 >> [ 590.578556] xe :4d:00.0: [drm] VRAM[0, 0]: Actual physical size >> 0x0010, usable size exclude stolen 0x000fff00, CPU >> accessible size 0x000fff00 >> [ 590.578560] xe :4d:00.0: [drm] VRAM[0, 0]: DPA range: >> [0x-10], io range: >> [0x2020-202fff00] >> [ 590.578585] xe :4d:00.0: [drm] VRAM[1, 1]: Actual physical size >> 0x0010, usable size exclude stolen 0x000fff00, CPU >> accessible size 0x000fff00 >> [ 590.578589] xe :4d:00.0: [drm] VRAM[1, 1]: DPA range: >> [0x0010-20], io range: >> [0x2030-203fff00] >> [ 590.578592] xe :4d:00.0: [drm] Total VRAM: 0x2020, >> 0x0020 >> [ 590.578594] xe :4d:00.0: [drm] Available VRAM: >> 0x2020, 0x001ffe00 >> [ 590.738899] xe :4d:00.0: [drm] GT0: CCS_MODE=0 config:0040, >> num_engines:1, num_slices:4 >> [ 590.889991] xe :4d:00.0: [drm] GT1: CCS_MODE=0 config:0040, >> num_engines:1, num_slices:4 >> [ 590.892835] [drm] Initialized xe 1.1.0 20201103 for :4d:00.0 on >> minor 1 >> [ 590.900215] xe :9a:00.0: enabling device (0140 -> 0142) >> [ 590.915991] xe :9a:00.0: [drm] Using GuC firmware from >> xe/pvc_guc_70.20.0.bin version 70.20.0 >> [ 590.957450] xe :9a:00.0: [drm] Using GuC firmware from >> xe/pvc_guc_70.20.0.bin version 70.20.0 >> [ 590.989863] xe :9a:00.0: [drm] VISIBLE VRAM: 0x20e0, >> 0x0020 >> [ 590.989888] xe :9a:00.0: [drm] VRAM[0, 0]: Actual physical size >> 0x0010, usable size exclude stolen 0x000fff00, CPU >> accessible
[PATCH v5 4/4] ARM: configs: at91: Enable LVDS serializer support
Enable LVDS serializer support for display pipeline. Signed-off-by: Dharma Balasubiramani Acked-by: Hari Prasath Gujulan Elango Acked-by: Nicolas Ferre --- Changelog v4 -> v5 v3 -> v4 v2 -> v3 - No Changes. --- arch/arm/configs/at91_dt_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/at91_dt_defconfig b/arch/arm/configs/at91_dt_defconfig index 1d53aec4c836..6eabe2313c9a 100644 --- a/arch/arm/configs/at91_dt_defconfig +++ b/arch/arm/configs/at91_dt_defconfig @@ -143,6 +143,7 @@ CONFIG_VIDEO_OV2640=m CONFIG_VIDEO_OV7740=m CONFIG_DRM=y CONFIG_DRM_ATMEL_HLCDC=y +CONFIG_DRM_MICROCHIP_LVDS_SERIALIZER=y CONFIG_DRM_PANEL_SIMPLE=y CONFIG_DRM_PANEL_EDP=y CONFIG_FB_ATMEL=y -- 2.25.1
Re: [PATCH v2 1/1] Revert "drm/qxl: simplify qxl_fence_wait"
On Thu, Apr 04, 2024 at 07:14:48PM +0100, Alex Constantino wrote:
> This reverts commit 5a838e5d5825c85556011478abde708251cc0776.
>
> Changes from commit 5a838e5d5825 ("drm/qxl: simplify qxl_fence_wait") would
> result in a '[TTM] Buffer eviction failed' exception whenever it reached a
> timeout.
> Due to a dependency to DMA_FENCE_WARN this also restores some code deleted
> by commit d72277b6c37d ("dma-buf: nuke DMA_FENCE_TRACE macros v2").
>
> Fixes: 5a838e5d5825 ("drm/qxl: simplify qxl_fence_wait")
> Link: https://lore.kernel.org/regressions/ztgydqrlk6wx_...@eldamar.lan/
> Reported-by: Timo Lindfors
> Closes: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1054514
> Signed-off-by: Alex Constantino
> ---
> drivers/gpu/drm/qxl/qxl_release.c | 50 +++
> include/linux/dma-fence.h | 7 +
> 2 files changed, 52 insertions(+), 5 deletions(-)
Hi,
This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him
a patch that has triggered this response. He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created. Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.
You are receiving this message because of the following common error(s)
as indicated below:
- You have marked a patch with a "Fixes:" tag for a commit that is in an
older released kernel, yet you do not have a cc: stable line in the
signed-off-by area at all, which means that the patch will not be
applied to any older kernel releases. To properly fix this, please
follow the documented rules in the
Documentation/process/stable-kernel-rules.rst file for how to resolve
this.
If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.
thanks,
greg k-h's patch email bot
[PATCH v5 3/4] MAINTAINERS: add SAM9X7 SoC's LVDS controller
Add the newly added LVDS controller for the SAM9X7 SoC to the existing MAINTAINERS entry. Signed-off-by: Dharma Balasubiramani Reviewed-by: Neil Armstrong Acked-by: Nicolas Ferre --- Changelog v4 -> v5 v3 -> v4 - No changes. v2 -> v3 - Move the entry before "MICROCHIP SAMA5D2-COMPATIBLE ADC DRIVER". v1 -> v2 - No Changes. --- MAINTAINERS | 8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index aa3b947fb080..3dd93dbe9542 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -14562,6 +14562,14 @@ S: Supported F: Documentation/devicetree/bindings/pwm/atmel,at91sam-pwm.yaml F: drivers/pwm/pwm-atmel.c +MICROCHIP SAM9x7-COMPATIBLE LVDS CONTROLLER +M: Manikandan Muralidharan +M: Dharma Balasubiramani +L: dri-devel@lists.freedesktop.org +S: Supported +F: Documentation/devicetree/bindings/display/bridge/microchip,sam9x7-lvds.yaml +F: drivers/gpu/drm/bridge/microchip-lvds.c + MICROCHIP SAMA5D2-COMPATIBLE ADC DRIVER M: Eugen Hristev L: linux-...@vger.kernel.org -- 2.25.1
[PATCH v5 1/4] dt-bindings: display: bridge: add sam9x75-lvds binding
Add the 'sam9x75-lvds' compatible binding, which describes the Low Voltage
Differential Signaling (LVDS) Controller found on some Microchip's sam9x7
series System-on-Chip (SoC) devices. This binding will be used to define
the properties and configuration for the LVDS Controller in DT.
Signed-off-by: Dharma Balasubiramani
Reviewed-by: Rob Herring
---
Changelog
v4 -> v5
- No changes.
v3 -> v4
- Rephrase the commit subject.
v2 -> v3
- No changes.
v1 -> v2
- Remove '|' in description, as there is no formatting to preserve.
- Remove 'gclk' from clock-names as there is only one clock(pclk).
- Remove the unused headers and include only used ones.
- Change the compatible name specific to SoC (sam9x75) instead of entire series.
- Change file name to match the compatible name.
---
.../bridge/microchip,sam9x75-lvds.yaml| 55 +++
1 file changed, 55 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/microchip,sam9x75-lvds.yaml
diff --git
a/Documentation/devicetree/bindings/display/bridge/microchip,sam9x75-lvds.yaml
b/Documentation/devicetree/bindings/display/bridge/microchip,sam9x75-lvds.yaml
new file mode 100644
index ..862ef441ac9f
--- /dev/null
+++
b/Documentation/devicetree/bindings/display/bridge/microchip,sam9x75-lvds.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/microchip,sam9x75-lvds.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip SAM9X75 LVDS Controller
+
+maintainers:
+ - Dharma Balasubiramani
+
+description:
+ The Low Voltage Differential Signaling Controller (LVDSC) manages data
+ format conversion from the LCD Controller internal DPI bus to OpenLDI
+ LVDS output signals. LVDSC functions include bit mapping, balanced mode
+ management, and serializer.
+
+properties:
+ compatible:
+const: microchip,sam9x75-lvds
+
+ reg:
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+ clocks:
+items:
+ - description: Peripheral Bus Clock
+
+ clock-names:
+items:
+ - const: pclk
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+lvds-controller@f806 {
+ compatible = "microchip,sam9x75-lvds";
+ reg = <0xf806 0x100>;
+ interrupts = <56 IRQ_TYPE_LEVEL_HIGH 0>;
+ clocks = < PMC_TYPE_PERIPHERAL 56>;
+ clock-names = "pclk";
+};
--
2.25.1
[PATCH v5 2/4] drm/bridge: add lvds controller support for sam9x7
Add a new LVDS controller driver for sam9x7 which does the following:
- Prepares and enables the LVDS Peripheral clock
- Defines its connector type as DRM_MODE_CONNECTOR_LVDS and adds itself
to the global bridge list.
- Identifies its output endpoint as panel and adds it to the encoder
display pipeline
- Enables the LVDS serializer
Signed-off-by: Manikandan Muralidharan
Signed-off-by: Dharma Balasubiramani
---
Changelog
v4 -> v5
- Drop the unused variable 'format'.
- Use DRM wrapper for dev_err() to maintain uniformity.
- return -ENODEV instead of -EINVAL to maintain consistency with other DRM
bridge drivers.
v3 -> v4
- No changes.
v2 ->v3
- Correct Typo error "serializer".
- Consolidate get() and prepare() functions and use devm_clk_get_prepared().
- Remove unused variable 'ret' in probe().
- Use devm_pm_runtime_enable() and drop the mchp_lvds_remove().
v1 -> v2
- Drop 'res' variable and combine two lines into one.
- Handle deferred probe properly, use dev_err_probe().
- Don't print anything on deferred probe. Dropped print.
- Remove the MODULE_ALIAS and add MODULE_DEVICE_TABLE().
- symbol 'mchp_lvds_driver' was not declared. It should be static.
---
drivers/gpu/drm/bridge/Kconfig | 7 +
drivers/gpu/drm/bridge/Makefile | 1 +
drivers/gpu/drm/bridge/microchip-lvds.c | 228
3 files changed, 236 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/microchip-lvds.c
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index efd996f6c138..889098e2d65f 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -190,6 +190,13 @@ config DRM_MEGACHIPS_STDP_GE_B850V3_FW
to DP++. This is used with the i.MX6 imx-ldb
driver. You are likely to say N here.
+config DRM_MICROCHIP_LVDS_SERIALIZER
+ tristate "Microchip LVDS serializer support"
+ depends on OF
+ depends on DRM_ATMEL_HLCDC
+ help
+ Support for Microchip's LVDS serializer.
+
config DRM_NWL_MIPI_DSI
tristate "Northwest Logic MIPI DSI Host controller"
depends on DRM
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 017b5832733b..7df87b582dca 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_DRM_LONTIUM_LT9611) += lontium-lt9611.o
obj-$(CONFIG_DRM_LONTIUM_LT9611UXC) += lontium-lt9611uxc.o
obj-$(CONFIG_DRM_LVDS_CODEC) += lvds-codec.o
obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) +=
megachips-stdp-ge-b850v3-fw.o
+obj-$(CONFIG_DRM_MICROCHIP_LVDS_SERIALIZER) += microchip-lvds.o
obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
obj-$(CONFIG_DRM_PARADE_PS8640) += parade-ps8640.o
diff --git a/drivers/gpu/drm/bridge/microchip-lvds.c
b/drivers/gpu/drm/bridge/microchip-lvds.c
new file mode 100644
index ..149704f498a6
--- /dev/null
+++ b/drivers/gpu/drm/bridge/microchip-lvds.c
@@ -0,0 +1,228 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2023 Microchip Technology Inc. and its subsidiaries
+ *
+ * Author: Manikandan Muralidharan
+ * Author: Dharma Balasubiramani
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define LVDS_POLL_TIMEOUT_MS 1000
+
+/* LVDSC register offsets */
+#define LVDSC_CR 0x00
+#define LVDSC_CFGR 0x04
+#define LVDSC_SR 0x0C
+#define LVDSC_WPMR 0xE4
+
+/* Bitfields in LVDSC_CR (Control Register) */
+#define LVDSC_CR_SER_ENBIT(0)
+
+/* Bitfields in LVDSC_CFGR (Configuration Register) */
+#define LVDSC_CFGR_PIXSIZE_24BITS 0
+#define LVDSC_CFGR_DEN_POL_HIGH0
+#define LVDSC_CFGR_DC_UNBALANCED 0
+#define LVDSC_CFGR_MAPPING_JEIDA BIT(6)
+
+/*Bitfields in LVDSC_SR */
+#define LVDSC_SR_CSBIT(0)
+
+/* Bitfields in LVDSC_WPMR (Write Protection Mode Register) */
+#define LVDSC_WPMR_WPKEY_MASK GENMASK(31, 8)
+#define LVDSC_WPMR_WPKEY_PSSWD 0x4C5644
+
+struct mchp_lvds {
+ struct device *dev;
+ void __iomem *regs;
+ struct clk *pclk;
+ struct drm_panel *panel;
+ struct drm_bridge bridge;
+ struct drm_bridge *panel_bridge;
+};
+
+static inline struct mchp_lvds *bridge_to_lvds(struct drm_bridge *bridge)
+{
+ return container_of(bridge, struct mchp_lvds, bridge);
+}
+
+static inline u32 lvds_readl(struct mchp_lvds *lvds, u32 offset)
+{
+ return readl_relaxed(lvds->regs + offset);
+}
+
+static inline void lvds_writel(struct mchp_lvds *lvds, u32 offset, u32 val)
+{
+ writel_relaxed(val, lvds->regs + offset);
+}
+
+static void lvds_serialiser_on(struct mchp_lvds *lvds)
+{
+ unsigned long timeout = jiffies +
msecs_to_jiffies(LVDS_POLL_TIMEOUT_MS);
+
+ /* The LVDSC registers can only be written if WPEN
[PATCH v5 0/4] LVDS Controller Support for SAM9X75 SoC
This patch series introduces LVDS controller support for the SAM9X75 SoC. The LVDS controller is designed to work with Microchip's sam9x7 series System-on-Chip (SoC) devices, providing Low Voltage Differential Signaling capabilities. Patch series Changelog: - Include configs: at91: Enable LVDS serializer - include all necessary To/Cc entries. The Individual Changelogs are available on the respective patches. Dharma Balasubiramani (4): dt-bindings: display: bridge: add sam9x75-lvds binding drm/bridge: add lvds controller support for sam9x7 MAINTAINERS: add SAM9X7 SoC's LVDS controller ARM: configs: at91: Enable LVDS serializer support .../bridge/microchip,sam9x75-lvds.yaml| 55 + MAINTAINERS | 8 + arch/arm/configs/at91_dt_defconfig| 1 + drivers/gpu/drm/bridge/Kconfig| 7 + drivers/gpu/drm/bridge/Makefile | 1 + drivers/gpu/drm/bridge/microchip-lvds.c | 228 ++ 6 files changed, 300 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/bridge/microchip,sam9x75-lvds.yaml create mode 100644 drivers/gpu/drm/bridge/microchip-lvds.c -- 2.25.1
[git pull] drm fixes for 6.9-rc3
Hi Linus, Weekly fixes, mostly xe and i915, amdgpu on a week off, otherwise a nouveau fix for a crash with new vulkan cts tests, and a couple of cleanups and misc fixes. Dave. drm-fixes-2024-04-05: drm fixes for v6.9-rc3 display: - fix typos in kerneldoc prime: - unbreak dma-buf export for virt-gpu nouveau: - uvmm: fix remap address calculation - minor cleanups panfrost: - fix power-transition timeouts xe: - Stop using system_unbound_wq for preempt fences, - Fix saving unordered rebinding fences by attaching them as kernel feces to the vm's resv - Fix TLB invalidation fences completing out of order - Move rebind TLB invalidation to the ring ops to reduce the latency i915: - A few DisplayPort related fixes - eDP PSR fixes - Remove some VM space restrictions on older platforms - Disable automatic load CCS load balancing The following changes since commit 39cd87c4eb2b893354f3b850f916353f2658ae6f: Linux 6.9-rc2 (2024-03-31 14:32:39 -0700) are available in the Git repository at: https://gitlab.freedesktop.org/drm/kernel.git tags/drm-fixes-2024-04-05 for you to fetch changes up to 4c8595741b5dd3268d6710545461ee9a7bbde891: Merge tag 'drm-intel-fixes-2024-04-04' of https://anongit.freedesktop.org/git/drm/drm-intel into drm-fixes (2024-04-05 12:32:14 +1000) drm fixes for v6.9-rc3 display: - fix typos in kerneldoc prime: - unbreak dma-buf export for virt-gpu nouveau: - uvmm: fix remap address calculation - minor cleanups panfrost: - fix power-transition timeouts xe: - Stop using system_unbound_wq for preempt fences, - Fix saving unordered rebinding fences by attaching them as kernel feces to the vm's resv - Fix TLB invalidation fences completing out of order - Move rebind TLB invalidation to the ring ops to reduce the latency i915: - A few DisplayPort related fixes - eDP PSR fixes - Remove some VM space restrictions on older platforms - Disable automatic load CCS load balancing Andi Shyti (4): drm/i915/gt: Limit the reserved VM space to only the platforms that need it drm/i915/gt: Disable HW load balancing for CCS drm/i915/gt: Do not generate the command streamer for all the CCS drm/i915/gt: Enable only one CCS for compute workload Ankit Nautiyal (1): drm/i915/dp: Fix the computation for compressed_bpp for DISPLAY < 13 Arun R Murthy (1): drm/i915/dp: Remove support for UHBR13.5 Christian Hewitt (1): drm/panfrost: fix power transition timeout warnings Colin Ian King (1): drm/nouveau/gr/gf100: Remove second semicolon Dave Airlie (4): nouveau/uvmm: fix addr/range calcs for remap operations Merge tag 'drm-misc-fixes-2024-04-04' of https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes Merge tag 'drm-xe-fixes-2024-04-04' of https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes Merge tag 'drm-intel-fixes-2024-04-04' of https://anongit.freedesktop.org/git/drm/drm-intel into drm-fixes Imre Deak (1): drm/i915/dp: Fix DSC state HW readout for SST connectors Jouni Högander (3): drm/i915/psr: Calculate PIPE_SRCSZ_ERLY_TPT value drm/i915/psr: Move writing early transport pipe src drm/i915/psr: Fix intel_psr2_sel_fetch_et_alignment usage Matthew Brost (1): drm/xe: Use ordered wq for preempt fence waiting Oleksandr Natalenko (1): drm/display: fix typo Rob Clark (1): drm/prime: Unbreak virtgpu dma-buf export Thomas Hellström (4): drm/xe: Use ring ops TLB invalidation for rebinds drm/xe: Rework rebinding drm/xe: Make TLB invalidation fences unordered drm/xe: Move vma rebinding to the drm_exec locking loop Ville Syrjälä (2): drm/i915/mst: Limit MST+DSC to TGL+ drm/i915/mst: Reject FEC+MST on ICL drivers/gpu/drm/display/drm_dp_dual_mode_helper.c | 4 +- drivers/gpu/drm/drm_prime.c| 7 +- drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/display/intel_display.c | 9 -- .../gpu/drm/i915/display/intel_display_device.h| 1 + drivers/gpu/drm/i915/display/intel_display_types.h | 2 + drivers/gpu/drm/i915/display/intel_dp.c| 11 ++- drivers/gpu/drm/i915/display/intel_dp_mst.c| 2 +- drivers/gpu/drm/i915/display/intel_psr.c | 78 ++- drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 3 + drivers/gpu/drm/i915/gt/intel_engine_cs.c | 17 drivers/gpu/drm/i915/gt/intel_gt.c | 6 ++ drivers/gpu/drm/i915/gt/intel_gt.h | 9 +- drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.c| 39 drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.h| 13 +++ drivers/gpu/drm/i915/gt/intel_gt_regs.h| 6 ++ drivers/gpu/drm/i915/gt/intel_workarounds.c| 30 +- drivers/gpu/drm/nouveau/nouveau_uvmm.c | 6 +-
Re: [PATCH 05/12] drm/client: Nuke outdated fastboot comment
On Thu, Apr 04, 2024 at 11:33:29PM +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > Remove the tall tale about fastboot vs. user mode vs. > adjusted mode. crtc->mode == crtc->state->mode, so none > of this makes any sense. I suppose it may have been true > long ago in the past. > > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/drm_client_modeset.c | 10 -- > 1 file changed, 10 deletions(-) > Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
RE: [PATCH 06/23] drm/xe/svm: Introduce a helper to build sg table from hmm range
Hi Jason,
> -Original Message-
> From: Jason Gunthorpe
> Sent: Thursday, April 4, 2024 8:39 PM
> To: Zeng, Oak
> Cc: dri-devel@lists.freedesktop.org; intel...@lists.freedesktop.org; Brost,
> Matthew ; thomas.hellst...@linux.intel.com;
> Welty, Brian ; Ghimiray, Himal Prasad
> ; Bommu, Krishnaiah
> ; Vishwanathapura, Niranjana
> ; Leon Romanovsky
> Subject: Re: [PATCH 06/23] drm/xe/svm: Introduce a helper to build sg table
> from
> hmm range
>
> On Wed, Jan 17, 2024 at 05:12:06PM -0500, Oak Zeng wrote:
> > +/**
> > + * xe_svm_build_sg() - build a scatter gather table for all the physical
> pages/pfn
> > + * in a hmm_range.
> > + *
> > + * @range: the hmm range that we build the sg table from. range-
> >hmm_pfns[]
> > + * has the pfn numbers of pages that back up this hmm address range.
> > + * @st: pointer to the sg table.
> > + *
> > + * All the contiguous pfns will be collapsed into one entry in
> > + * the scatter gather table. This is for the convenience of
> > + * later on operations to bind address range to GPU page table.
> > + *
> > + * This function allocates the storage of the sg table. It is
> > + * caller's responsibility to free it calling sg_free_table.
> > + *
> > + * Returns 0 if successful; -ENOMEM if fails to allocate memory
> > + */
> > +int xe_svm_build_sg(struct hmm_range *range,
> > +struct sg_table *st)
> > +{
> > + struct scatterlist *sg;
> > + u64 i, npages;
> > +
> > + sg = NULL;
> > + st->nents = 0;
> > + npages = ((range->end - 1) >> PAGE_SHIFT) - (range->start >>
> PAGE_SHIFT) + 1;
> > +
> > + if (unlikely(sg_alloc_table(st, npages, GFP_KERNEL)))
> > + return -ENOMEM;
> > +
> > + for (i = 0; i < npages; i++) {
> > + unsigned long addr = range->hmm_pfns[i];
> > +
> > + if (sg && (addr == (sg_dma_address(sg) + sg->length))) {
> > + sg->length += PAGE_SIZE;
> > + sg_dma_len(sg) += PAGE_SIZE;
> > + continue;
> > + }
> > +
> > + sg = sg ? sg_next(sg) : st->sgl;
> > + sg_dma_address(sg) = addr;
> > + sg_dma_len(sg) = PAGE_SIZE;
> > + sg->length = PAGE_SIZE;
> > + st->nents++;
> > + }
> > +
> > + sg_mark_end(sg);
> > + return 0;
> > +}
>
> I didn't look at this series a lot but I wanted to make a few
> remarks.. This I don't like quite a lot. Yes, the DMA API interaction
> with hmm_range_fault is pretty bad, but it should not be hacked
> around like this. Leon is working on a series to improve it:
>
> https://lore.kernel.org/linux-rdma/cover.1709635535.git.l...@kernel.org/
I completely agree above codes are really ugly. We definitely want to adapt to
a better way. I will spend some time on above series.
>
> Please participate there too. In the mean time you should just call
> dma_map_page for every single page like ODP does.
Above codes deal with a case where dma map is not needed. As I understand it,
whether we need a dma map depends on the devices topology. For example, when
device access host memory or another device's memory through pcie, we need dma
mapping; if the connection b/t devices is xelink (similar to nvidia's nvlink),
all device's memory can be in same address space, so no dma mapping is needed.
>
> Also, I tried to follow the large discussion in the end but it was
> quite hard to read the text in Lore for some reason.
Did you mean this discussion:
https://lore.kernel.org/dri-devel/?q=Making+drm_gpuvm+work+across+gpu+devices?
This link works good for me with chrome browser.
>
> I would just opine some general points on how I see hmm_range_fault
> being used by drivers.
>
> First of all, the device should have a private page table. At least
> one, but ideally many. Obviously it should work, so I found it a bit
> puzzling the talk about problems with virtualization. Either the
> private page table works virtualized, including faults, or it should
> not be available..
To be very honest, I was also very confused. In this series, I had one very
fundamental assumption that with hmm any valid cpu virtual address is also a
valid gpu virtual address. But Christian had a very strong opinion that the gpu
va can have an offset to cpu va. He mentioned a failed use case with amdkfd and
claimed an offset can solve their problem.
For all our known use cases, gpu va == cpu va. But we had agreed to make the
uAPI to be flexible so we can introduce a offset if a use case come out in the
future.
>
> Second, I see hmm_range_fault as having two main design patterns
> interactions. Either it is the entire exclusive owner of a single
> device private page table and fully mirrors the mm page table into the
> device table.
>
> Or it is a selective mirror where it copies part of the mm page table
> into a "vma" of a possibly shared device page table. The
> hmm_range_fault bit would exclusively own it's bit of VMA.
Can you explain what is "hmm_range_fault bit"?
The
Re: [PATCH 04/12] drm/client: Add a FIXME around crtc->mode usage
On Thu, Apr 04, 2024 at 11:33:28PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> crtc->mode is legacy junk and shouldn't really be used with
> atomic drivers.
>
> Most (all?) atomic drivers do end up still calling
> drm_atomic_helper_update_legacy_modeset_state() at some
> point, so crtc->mode does still get populated, and this
> does work for now. But eventually would be nice to eliminate
> all the legacy stuff from atomic drivers.
>
> Switching to crtc->state->mode would require some bigger
> changes however, as we currently drop the crtc->mutex
> before we're done using the mode. So leave the junk in
> for now and just add a FIXME to remind us that this
> needs fixing.
What about using allocated duplicate modes to fill modes[] array? This
requires additional allocations, but it will solve most if not all modes
lifetime issues.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_client_modeset.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_client_modeset.c
> b/drivers/gpu/drm/drm_client_modeset.c
> index 2b7d0be04911..8ef03608b424 100644
> --- a/drivers/gpu/drm/drm_client_modeset.c
> +++ b/drivers/gpu/drm/drm_client_modeset.c
> @@ -699,6 +699,10 @@ static bool drm_client_firmware_config(struct
> drm_client_dev *client,
>*
>* This is crtc->mode and not crtc->state->mode for the
>* fastboot check to work correctly.
> + *
> + * FIXME using legacy crtc->mode with atomic drivers
> + * is dodgy. Switch to crtc->state->mode, after taking
> + * care of the resulting locking/lifetime issues.
>*/
> DRM_DEBUG_KMS("looking for current mode on connector
> %s\n",
> connector->name);
> --
> 2.43.2
>
--
With best wishes
Dmitry
Re: [PATCH 03/12] drm/client: Use drm_mode_destroy()
On Thu, Apr 04, 2024 at 11:33:27PM +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > Prefer drm_mode_destroy() over bare kfree(), for consistency > and setting a good example. > > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/drm_client_modeset.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: [PATCH 02/12] drm/client: s/drm_connector_has_preferred_mode/drm_connector_preferred_mode/
On Thu, Apr 04, 2024 at 11:33:26PM +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > Drop the "has" from drm_connector_has_preferred_mode() to better > describe what it does. > > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/drm_client_modeset.c | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: [PATCH 01/12] drm/client: Fully protect modes[] with dev->mode_config.mutex
On Thu, Apr 04, 2024 at 11:33:25PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The modes[] array contains pointers to modes on the connectors'
> mode lists, which are protected by dev->mode_config.mutex.
> Thus we need to extend modes[] the same protection or by the
> time we use it the elements may already be pointing to
> freed/reused memory.
>
> Cc: sta...@vger.kernel.org
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10583
> Signed-off-by: Ville Syrjälä
Reviewed-by: Dmitry Baryshkov
I tried looking for the proper Fixes tag, but it looks like it might be
something like 386516744ba4 ("drm/fb: fix fbdev object model + cleanup
properly.")
> ---
> drivers/gpu/drm/drm_client_modeset.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_client_modeset.c
> b/drivers/gpu/drm/drm_client_modeset.c
> index 871e4e2129d6..0683a129b362 100644
> --- a/drivers/gpu/drm/drm_client_modeset.c
> +++ b/drivers/gpu/drm/drm_client_modeset.c
> @@ -777,6 +777,7 @@ int drm_client_modeset_probe(struct drm_client_dev
> *client, unsigned int width,
> unsigned int total_modes_count = 0;
> struct drm_client_offset *offsets;
> unsigned int connector_count = 0;
> + /* points to modes protected by mode_config.mutex */
> struct drm_display_mode **modes;
> struct drm_crtc **crtcs;
> int i, ret = 0;
> @@ -845,7 +846,6 @@ int drm_client_modeset_probe(struct drm_client_dev
> *client, unsigned int width,
> drm_client_pick_crtcs(client, connectors, connector_count,
> crtcs, modes, 0, width, height);
> }
> - mutex_unlock(>mode_config.mutex);
>
> drm_client_modeset_release(client);
>
> @@ -875,6 +875,7 @@ int drm_client_modeset_probe(struct drm_client_dev
> *client, unsigned int width,
> modeset->y = offset->y;
> }
> }
> + mutex_unlock(>mode_config.mutex);
>
> mutex_unlock(>modeset_mutex);
> out:
> --
> 2.43.2
>
--
With best wishes
Dmitry
linux-next: build warnings after merge of the drm-intel tree
Hi all,
After merging the drm-intel tree, today's linux-next build (htmldocs)
produced these warnings:
include/drm/display/drm_dp_helper.h:126: warning: Function parameter or struct
member 'mode' not described in 'drm_dp_as_sdp'
include/drm/display/drm_dp_helper.h:126: warning: Excess struct member
'operation_mode' description in 'drm_dp_as_sdp'
Introduced by commit
0bbb8f594e33 ("drm/dp: Add Adaptive Sync SDP logging")
--
Cheers,
Stephen Rothwell
pgprg2okAyDxg.pgp
Description: OpenPGP digital signature
Re: [PATCH 06/23] drm/xe/svm: Introduce a helper to build sg table from hmm range
On Wed, Jan 17, 2024 at 05:12:06PM -0500, Oak Zeng wrote:
> +/**
> + * xe_svm_build_sg() - build a scatter gather table for all the physical
> pages/pfn
> + * in a hmm_range.
> + *
> + * @range: the hmm range that we build the sg table from. range->hmm_pfns[]
> + * has the pfn numbers of pages that back up this hmm address range.
> + * @st: pointer to the sg table.
> + *
> + * All the contiguous pfns will be collapsed into one entry in
> + * the scatter gather table. This is for the convenience of
> + * later on operations to bind address range to GPU page table.
> + *
> + * This function allocates the storage of the sg table. It is
> + * caller's responsibility to free it calling sg_free_table.
> + *
> + * Returns 0 if successful; -ENOMEM if fails to allocate memory
> + */
> +int xe_svm_build_sg(struct hmm_range *range,
> + struct sg_table *st)
> +{
> + struct scatterlist *sg;
> + u64 i, npages;
> +
> + sg = NULL;
> + st->nents = 0;
> + npages = ((range->end - 1) >> PAGE_SHIFT) - (range->start >>
> PAGE_SHIFT) + 1;
> +
> + if (unlikely(sg_alloc_table(st, npages, GFP_KERNEL)))
> + return -ENOMEM;
> +
> + for (i = 0; i < npages; i++) {
> + unsigned long addr = range->hmm_pfns[i];
> +
> + if (sg && (addr == (sg_dma_address(sg) + sg->length))) {
> + sg->length += PAGE_SIZE;
> + sg_dma_len(sg) += PAGE_SIZE;
> + continue;
> + }
> +
> + sg = sg ? sg_next(sg) : st->sgl;
> + sg_dma_address(sg) = addr;
> + sg_dma_len(sg) = PAGE_SIZE;
> + sg->length = PAGE_SIZE;
> + st->nents++;
> + }
> +
> + sg_mark_end(sg);
> + return 0;
> +}
I didn't look at this series a lot but I wanted to make a few
remarks.. This I don't like quite a lot. Yes, the DMA API interaction
with hmm_range_fault is pretty bad, but it should not be hacked
around like this. Leon is working on a series to improve it:
https://lore.kernel.org/linux-rdma/cover.1709635535.git.l...@kernel.org/
Please participate there too. In the mean time you should just call
dma_map_page for every single page like ODP does.
Also, I tried to follow the large discussion in the end but it was
quite hard to read the text in Lore for some reason.
I would just opine some general points on how I see hmm_range_fault
being used by drivers.
First of all, the device should have a private page table. At least
one, but ideally many. Obviously it should work, so I found it a bit
puzzling the talk about problems with virtualization. Either the
private page table works virtualized, including faults, or it should
not be available..
Second, I see hmm_range_fault as having two main design patterns
interactions. Either it is the entire exclusive owner of a single
device private page table and fully mirrors the mm page table into the
device table.
Or it is a selective mirror where it copies part of the mm page table
into a "vma" of a possibly shared device page table. The
hmm_range_fault bit would exclusively own it's bit of VMA.
So I find it a quite strange that this RFC is creating VMA's,
notifiers and ranges on the fly. That should happen when userspace
indicates it wants some/all of the MM to be bound to a specific device
private pagetable/address space.
I also agree with the general spirit of the remarks that there should
not be a process binding or any kind of "global" character
device. Device private page tables are by their very nature private to
the device and should be created through a device specific char
dev. If you have a VMA concept for these page tables then a HMM
mirroring one is simply a different type of VMA along with all the
others.
I was also looking at the mmu notifier register/unregister with some
suspicion, it seems wrong to have a patch talking about "process
exit". Notifiers should be destroyed when the device private page
table is destroyed, or the VMA is destroyed. Attempting to connect it
to a process beyond tying the lifetime of a page table to a FD is
nonsensical.
Jason
[PATCH 2/2] drm/nouveau/dp: Don't probe eDP ports twice harder
I didn't pay close enough attention the last time I tried to fix this
problem - while we currently do correctly take care to make sure we don't
probe a connected eDP port more then once, we don't do the same thing for
eDP ports we found to be disconnected.
So, fix this and make sure we only ever probe eDP ports once and then leave
them at that connector state forever (since without HPD, it's not going to
change on its own anyway). This should get rid of the last few GSP errors
getting spit out during runtime suspend and resume on some machines, as we
tried to reprobe eDP ports in response to ACPI hotplug probe events.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/nouveau_dp.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
b/drivers/gpu/drm/nouveau/nouveau_dp.c
index 8b1be7dd64ebe..8b27d372e86da 100644
--- a/drivers/gpu/drm/nouveau/nouveau_dp.c
+++ b/drivers/gpu/drm/nouveau/nouveau_dp.c
@@ -225,12 +225,16 @@ nouveau_dp_detect(struct nouveau_connector *nv_connector,
u8 *dpcd = nv_encoder->dp.dpcd;
int ret = NOUVEAU_DP_NONE, hpd;
- /* If we've already read the DPCD on an eDP device, we don't need to
-* reread it as it won't change
+ /* eDP ports don't support hotplugging - so there's no point in probing
eDP ports unless we
+* haven't probed them once before.
*/
- if (connector->connector_type == DRM_MODE_CONNECTOR_eDP &&
- dpcd[DP_DPCD_REV] != 0)
- return NOUVEAU_DP_SST;
+ if (connector->connector_type == DRM_MODE_CONNECTOR_eDP) {
+ if (connector->status == connector_status_connected) {
+ return NOUVEAU_DP_SST;
+ } else if (connector->status == connector_status_disconnected) {
+ return NOUVEAU_DP_NONE;
+ }
+ }
// Ensure that the aux bus is enabled for probing
drm_dp_dpcd_set_powered(_connector->aux, true);
--
2.44.0
[PATCH 1/2] drm/nouveau/kms/nv50-: Disable AUX bus for disconnected DP ports
GSP has its own state for keeping track of whether or not a given display
connector is plugged in or not, and enforces this state on the driver. In
particular, AUX transactions on a DisplayPort connector which GSP says is
disconnected can never succeed - and can in some cases even cause
unexpected timeouts, which can trickle up to cause other problems. A good
example of this is runtime power management: where we can actually get
stuck trying to resume the GPU if a userspace application like fwupd tries
accessing a drm_aux_dev for a disconnected port. This was an issue I hit a
few times with my Slimbook Executive 16 - where trying to offload something
to the discrete GPU would wake it up, and then potentially cause it to
timeout as fwupd tried to immediately access the dp_aux_dev nodes for
nouveau.
Likewise: we don't really have any cases I know of where we'd want to
ignore this state and try an aux transaction anyway - and failing pointless
aux transactions immediately can even speed things up. So - let's start
enabling/disabling the aux bus in nouveau_dp_detect() to fix this. We
enable the aux bus during connector probing, and leave it enabled if we
discover something is actually on the connector. Otherwise, we just shut it
off.
This should fix some people's runtime PM issues (like myself), and also get
rid of quite of a lot of GSP error spam in dmesg.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/nouveau_dp.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
b/drivers/gpu/drm/nouveau/nouveau_dp.c
index fb06ee17d9e54..8b1be7dd64ebe 100644
--- a/drivers/gpu/drm/nouveau/nouveau_dp.c
+++ b/drivers/gpu/drm/nouveau/nouveau_dp.c
@@ -232,6 +232,9 @@ nouveau_dp_detect(struct nouveau_connector *nv_connector,
dpcd[DP_DPCD_REV] != 0)
return NOUVEAU_DP_SST;
+ // Ensure that the aux bus is enabled for probing
+ drm_dp_dpcd_set_powered(_connector->aux, true);
+
mutex_lock(_encoder->dp.hpd_irq_lock);
if (mstm) {
/* If we're not ready to handle MST state changes yet, just
@@ -293,6 +296,13 @@ nouveau_dp_detect(struct nouveau_connector *nv_connector,
if (mstm && !mstm->suspended && ret != NOUVEAU_DP_MST)
nv50_mstm_remove(mstm);
+ /* GSP doesn't like when we try to do aux transactions on a port it
considers disconnected,
+* and since we don't really have a usecase for that anyway - just
disable the aux bus here
+* if we've decided the connector is disconnected
+*/
+ if (ret == NOUVEAU_DP_NONE)
+ drm_dp_dpcd_set_powered(_connector->aux, false);
+
mutex_unlock(_encoder->dp.hpd_irq_lock);
return ret;
}
--
2.44.0
[PATCH 0/2] nouveau: GSP DP aux fixes
Fixes for a few issues I've been seeing around regarding DP aux transactions with nouveau and GSP support - mainly stemming from the fact that GSP returns an error for aux transactions that are attempted on disconnected ports. Some of these issues somehow manage to make runtime PM fail on my Slimbook Executive 16! Lyude Paul (2): drm/nouveau/kms/nv50-: Disable AUX bus for disconnected DP ports drm/nouveau/dp: Don't probe eDP ports twice harder drivers/gpu/drm/nouveau/nouveau_dp.c | 24 +++- 1 file changed, 19 insertions(+), 5 deletions(-) -- 2.44.0
Re: [PATCH v7 0/7] VMware hypercalls enhancements
Peter, can you please review version 7 of "x86/vmware: Add TDX hypercall support" patch. It addresses the concern you had in previous version. Thanks.
Re: [PATCH v2 0/4] drm/xe: Support PCIe FLR
On Tue, Apr 02, 2024 at 02:28:55PM +0530, Aravind Iddamsetty wrote: > PCI subsystem provides callbacks to inform the driver about a request to > do function level reset by user, initiated by writing to sysfs entry > /sys/bus/pci/devices/.../reset. This will allow the driver to handle FLR > without the need to do unbind and rebind as the driver needs to > reinitialize the device afresh post FLR. > > v2: all the patches looks good to me here. feel free to use Reviewed-by: Rodrigo Vivi on them. but I do have some concerns (below) > 1. Directly expose the devm_drm_dev_release_action instead of introducing > a helper (Rodrigo) > 2. separate out gt idle and pci save/restore to a separate patch (Lucas) > 3. Fixed the warnings seen around xe_guc_submit_stop, xe_guc_puc_fini On this I also had to fight to get something working on the wedged_mode=2: lore.kernel.org/all/20240403150732.102678-4-rodrigo.v...@intel.com perhaps we can unify things here. > > Cc: Rodrigo Vivi > Cc: Lucas De Marchi > > dmesg snip showing FLR recovery: things came different at my DG2 here with display working and all: root@rdvivi-desk:/sys/module/xe/drivers/pci:xe/:03:00.0# echo 1 > reset Segmentation fault and many kernel warnings WARNING: CPU: 8 PID: 2389 at drivers/gpu/drm/i915/display/intel_display_power_well.c:281 hsw_wait_for_power_well_enable+0x3e7/0x570 [xe] WARNING: CPU: 9 PID: 1700 at drivers/gpu/drm/drm_mm.c:999 drm_mm_takedown+0x41/0x60 [ 117.128330] KASAN: null-ptr-deref in range [0x04e8-0x04ef] [ 117.128332] CPU: 13 PID: 2389 Comm: bash Tainted: GW 6.9.0-rc1+ #9 [ 117.135501] ? exc_invalid_op+0x13/0x40 [ 117.143626] Hardware name: iBUYPOWER INTEL/B660 DS3H AC DDR4-Y1, BIOS F5 12/17/2021 [ 117.143627] RIP: 0010:__mutex_lock+0x124/0x14a0 [ 117.143631] Code: d0 7c 08 84 d2 0f 85 62 0f 00 00 8b 0d 85 c8 8f 04 85 c9 75 29 48 b8 00 00 00 00 00 fc ff df 49 8d 7f 68 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 46 0f 00 00 4d 3b 7f 68 0f 85 aa 0e 00 00 bf 01 [ 117.150630] ? asm_exc_invalid_op+0x16/0x20 [ 117.156401] RSP: 0018:c90005a37690 EFLAGS: 00010202 [ 117.156403] RAX: dc00 RBX: RCX: [ 117.163571] ? drm_buddy_fini+0x181/0x220 and more issues. so it looks like we are still missing some parts of the puzzle here... > > [ 590.486336] xe :4d:00.0: enabling device (0140 -> 0142) > [ 590.506933] xe :4d:00.0: [drm] Using GuC firmware from > xe/pvc_guc_70.20.0.bin version 70.20.0 > [ 590.542355] xe :4d:00.0: [drm] Using GuC firmware from > xe/pvc_guc_70.20.0.bin version 70.20.0 > [ 590.578532] xe :4d:00.0: [drm] VISIBLE VRAM: 0x2020, > 0x0020 > [ 590.578556] xe :4d:00.0: [drm] VRAM[0, 0]: Actual physical size > 0x0010, usable size exclude stolen 0x000fff00, CPU > accessible size 0x000fff00 > [ 590.578560] xe :4d:00.0: [drm] VRAM[0, 0]: DPA range: > [0x-10], io range: > [0x2020-202fff00] > [ 590.578585] xe :4d:00.0: [drm] VRAM[1, 1]: Actual physical size > 0x0010, usable size exclude stolen 0x000fff00, CPU > accessible size 0x000fff00 > [ 590.578589] xe :4d:00.0: [drm] VRAM[1, 1]: DPA range: > [0x0010-20], io range: > [0x2030-203fff00] > [ 590.578592] xe :4d:00.0: [drm] Total VRAM: 0x2020, > 0x0020 > [ 590.578594] xe :4d:00.0: [drm] Available VRAM: > 0x2020, 0x001ffe00 > [ 590.738899] xe :4d:00.0: [drm] GT0: CCS_MODE=0 config:0040, > num_engines:1, num_slices:4 > [ 590.889991] xe :4d:00.0: [drm] GT1: CCS_MODE=0 config:0040, > num_engines:1, num_slices:4 > [ 590.892835] [drm] Initialized xe 1.1.0 20201103 for :4d:00.0 on > minor 1 > [ 590.900215] xe :9a:00.0: enabling device (0140 -> 0142) > [ 590.915991] xe :9a:00.0: [drm] Using GuC firmware from > xe/pvc_guc_70.20.0.bin version 70.20.0 > [ 590.957450] xe :9a:00.0: [drm] Using GuC firmware from > xe/pvc_guc_70.20.0.bin version 70.20.0 > [ 590.989863] xe :9a:00.0: [drm] VISIBLE VRAM: 0x20e0, > 0x0020 > [ 590.989888] xe :9a:00.0: [drm] VRAM[0, 0]: Actual physical size > 0x0010, usable size exclude stolen 0x000fff00, CPU > accessible size 0x000fff00 > [ 590.989893] xe :9a:00.0: [drm] VRAM[0, 0]: DPA range: > [0x-10], io range: > [0x20e0-20efff00] > [ 590.989918] xe :9a:00.0: [drm] VRAM[1, 1]: Actual physical size > 0x0010, usable size exclude stolen 0x000fff00, CPU > accessible size 0x000fff00 > [ 590.989921] xe :9a:00.0: [drm] VRAM[1, 1]: DPA range: > [0x0010-20], io range: > [0x20f0-2000] > [ 590.989924] xe :9a:00.0: [drm] Total VRAM: 0x20e0, > 0x0020 > [
Re: [PATCH] drm/panfrost: Show overall GPU usage stats through sysfs knob
On 04.04.2024 11:31, Maíra Canal wrote:
> On 4/4/24 11:00, Adrián Larumbe wrote:
> > This changeset is heavily inspired by commit 509433d8146c ("drm/v3d: Expose
> > the total GPU usage stats on sysfs"). The point is making broader GPU
> > occupancy numbers available through the sysfs interface, so that for every
> > job slot, its number of processed jobs and total processing time are
> > displayed.
>
> Shouldn't we make this sysfs interface a generic DRM interface?
> Something that would be standard for all drivers and that we could
> integrate into gputop in the future.
I think the best way to generalise this sysfs knob would be to create a DRM
class attribute somewhere in drivers/gpu/drm/drm_sysfs.c and then adding a new
function to 'struct drm_driver' that would return a structure with the relevant
information (execution units and their names, number of processed jobs, etc).
What that information would exactly be is up to debate, I guess, since different
drivers might be interested in showing different bits of information.
Laying that down is important because the sysfs file would become part of the
device class API.
I might come up with a new RFC patch series that does precisely that, at least
for v3d and Panfrost, and maybe other people could pitch in with the sort of
things they'd like to see for other drivers?
Cheers,
Adrian
> Best Regards,
> - Maíra
>
> >
> > Cc: Boris Brezillon
> > Cc: Christopher Healy
> > Signed-off-by: Adrián Larumbe
> > ---
> > drivers/gpu/drm/panfrost/panfrost_device.h | 5 +++
> > drivers/gpu/drm/panfrost/panfrost_drv.c| 49 --
> > drivers/gpu/drm/panfrost/panfrost_job.c| 17 +++-
> > drivers/gpu/drm/panfrost/panfrost_job.h| 3 ++
> > 4 files changed, 68 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/panfrost/panfrost_device.h
> > b/drivers/gpu/drm/panfrost/panfrost_device.h
> > index cffcb0ac7c11..1d343351c634 100644
> > --- a/drivers/gpu/drm/panfrost/panfrost_device.h
> > +++ b/drivers/gpu/drm/panfrost/panfrost_device.h
> > @@ -169,6 +169,11 @@ struct panfrost_engine_usage {
> > unsigned long long cycles[NUM_JOB_SLOTS];
> > };
> > +struct panfrost_slot_usage {
> > + u64 enabled_ns;
> > + u64 jobs_sent;
> > +};
> > +
> > struct panfrost_file_priv {
> > struct panfrost_device *pfdev;
> > diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
> > b/drivers/gpu/drm/panfrost/panfrost_drv.c
> > index ef9f6c0716d5..6afcde66270f 100644
> > --- a/drivers/gpu/drm/panfrost/panfrost_drv.c
> > +++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
> > @@ -8,6 +8,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -524,6 +525,10 @@ static const struct drm_ioctl_desc
> > panfrost_drm_driver_ioctls[] = {
> > PANFROST_IOCTL(MADVISE, madvise,DRM_RENDER_ALLOW),
> > };
> > +static const char * const engine_names[] = {
> > + "fragment", "vertex-tiler", "compute-only"
> > +};
> > +
> > static void panfrost_gpu_show_fdinfo(struct panfrost_device *pfdev,
> > struct panfrost_file_priv *panfrost_priv,
> > struct drm_printer *p)
> > @@ -543,10 +548,6 @@ static void panfrost_gpu_show_fdinfo(struct
> > panfrost_device *pfdev,
> > * job spent on the GPU.
> > */
> > - static const char * const engine_names[] = {
> > - "fragment", "vertex-tiler", "compute-only"
> > - };
> > -
> > BUILD_BUG_ON(ARRAY_SIZE(engine_names) != NUM_JOB_SLOTS);
> > for (i = 0; i < NUM_JOB_SLOTS - 1; i++) {
> > @@ -716,8 +717,48 @@ static ssize_t profiling_store(struct device *dev,
> > static DEVICE_ATTR_RW(profiling);
> > +static ssize_t
> > +gpu_stats_show(struct device *dev, struct device_attribute *attr, char
> > *buf)
> > +{
> > + struct panfrost_device *pfdev = dev_get_drvdata(dev);
> > + struct panfrost_slot_usage stats;
> > + u64 timestamp = local_clock();
> > + ssize_t len = 0;
> > + unsigned int i;
> > +
> > + BUILD_BUG_ON(ARRAY_SIZE(engine_names) != NUM_JOB_SLOTS);
> > +
> > + len += sysfs_emit(buf, "queuetimestampjobs
> > runtime\n");
> > + len += sysfs_emit_at(buf, len,
> > "-\n");
> > +
> > + for (i = 0; i < NUM_JOB_SLOTS - 1; i++) {
> > +
> > + stats = get_slot_stats(pfdev, i);
> > +
> > + /*
> > +* Each line will display the slot name, timestamp, the number
> > +* of jobs handled by that engine and runtime, as shown below:
> > +*
> > +* queuetimestampjobsruntime
> > +* -
> > +* fragment 12252943467507 638 1184747640
> > +* vertex-tiler 12252943467507 636 121663838
> > +*
> > +*/
> > + len += sysfs_emit_at(buf, len,
Re: (subset) [PATCH v3 0/4] arm64: dts: fix several display-related schema warnings
On Tue, 02 Apr 2024 05:57:14 +0300, Dmitry Baryshkov wrote: > Fix several warnings produced by the display nodes. > > Please excuse me for the spam for sending v3 soon after v2. > > Applied, thanks! [2/4] arm64: dts: qcom: sc8180x: drop legacy property #stream-id-cells commit: 7fb5680b589d5eae64ada1d917b6ff2dab82f5ae [3/4] arm64: dts: qcom: sc8180x: Drop flags for mdss irqs commit: 580701ec27f61e0996dd5fcd23b091b6bf6933e3 [4/4] arm64: dts: qcom: sc8180x: add dp_p1 register blocks to DP nodes commit: 1106ea2266d11ebd97c3493a0c36a45272bfb67a Best regards, -- Bjorn Andersson
Re: [PATCH v13 8/8] selftests/udmabuf: Add tests to verify data after page migration
On 4/4/24 01:26, Vivek Kasireddy wrote:
Since the memfd pages associated with a udmabuf may be migrated
as part of udmabuf create, we need to verify the data coherency
after successful migration. The new tests added in this patch try
to do just that using 4k sized pages and also 2 MB sized huge
pages for the memfd.
Successful completion of the tests would mean that there is no
disconnect between the memfd pages and the ones associated with
a udmabuf. And, these tests can also be augmented in the future
to test newer udmabuf features (such as handling memfd hole punch).
The idea for these tests comes from a patch by Mike Kravetz.
Add Suggested-by for Mike Kravetz
Cc: Shuah Khan
Cc: David Hildenbrand
Cc: Daniel Vetter
Cc: Mike Kravetz
Cc: Hugh Dickins
Cc: Peter Xu
Cc: Jason Gunthorpe
Cc: Gerd Hoffmann
Cc: Dongwon Kim
Cc: Junxiao Chang
Signed-off-by: Vivek Kasireddy
---
.../selftests/drivers/dma-buf/udmabuf.c | 151 +-
1 file changed, 147 insertions(+), 4 deletions(-)
diff --git a/tools/testing/selftests/drivers/dma-buf/udmabuf.c
b/tools/testing/selftests/drivers/dma-buf/udmabuf.c
index c812080e304e..d76c813fe652 100644
--- a/tools/testing/selftests/drivers/dma-buf/udmabuf.c
+++ b/tools/testing/selftests/drivers/dma-buf/udmabuf.c
@@ -9,26 +9,132 @@
#include
#include
#include
+#include
#include
#include
+#include
#include
#include
#define TEST_PREFIX "drivers/dma-buf/udmabuf"
#define NUM_PAGES 4
+#define NUM_ENTRIES 4
+#define MEMFD_SIZE 1024 /* in pages */
-static int memfd_create(const char *name, unsigned int flags)
+static unsigned int page_size;
+
+static int create_memfd_with_seals(off64_t size, bool hpage)
+{
+ int memfd, ret;
+ unsigned int flags = MFD_ALLOW_SEALING;
+
+ if (hpage)
+ flags |= MFD_HUGETLB;
+
+ memfd = memfd_create("udmabuf-test", flags);
+ if (memfd < 0) {
+ printf("%s: [skip,no-memfd]\n", TEST_PREFIX);
+ exit(77);
+ }
+
+ ret = fcntl(memfd, F_ADD_SEALS, F_SEAL_SHRINK);
+ if (ret < 0) {
+ printf("%s: [skip,fcntl-add-seals]\n", TEST_PREFIX);
Use the kselftest skip code here. Also use kselftest_* functions
to print results and exit messages for KTAP format.
+ exit(77);
This should be KSFT_SKIP
+ }
+
+ ret = ftruncate(memfd, size);
+ if (ret == -1) {
+ printf("%s: [FAIL,memfd-truncate]\n", TEST_PREFIX);
+ exit(1);
Use KSFT_FAIL
+ }
+
+ return memfd;
+}
+
+static int create_udmabuf_list(int devfd, int memfd, off64_t memfd_size)
+{
+ struct udmabuf_create_list *list;
+ int ubuf_fd, i;
+
+ list = malloc(sizeof(struct udmabuf_create_list) +
+ sizeof(struct udmabuf_create_item) * NUM_ENTRIES);
+ if (!list) {
+ printf("%s: [FAIL, udmabuf-malloc]\n", TEST_PREFIX);
+ exit(1);
+ }
+
+ for (i = 0; i < NUM_ENTRIES; i++) {
+ list->list[i].memfd = memfd;
+ list->list[i].offset = i * (memfd_size / NUM_ENTRIES);
+ list->list[i].size = getpagesize() * NUM_PAGES;
+ }
+
+ list->count = NUM_ENTRIES;
+ list->flags = UDMABUF_FLAGS_CLOEXEC;
+ ubuf_fd = ioctl(devfd, UDMABUF_CREATE_LIST, list);
+ free(list);
+ if (ubuf_fd < 0) {
+ printf("%s: [FAIL, udmabuf-create]\n", TEST_PREFIX);
+ exit(1);
Same as before.
+ }
+
+ return ubuf_fd;
+}
+
+static void write_to_memfd(void *addr, off64_t size, char chr)
+{
+ int i;
+
+ for (i = 0; i < size / page_size; i++) {
+ *((char *)addr + (i * page_size)) = chr;
+ }
+}
+
+static void *mmap_fd(int fd, off64_t size)
{
- return syscall(__NR_memfd_create, name, flags);
+ void *addr;
+
+ addr = mmap(NULL, size, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
+ if (addr == MAP_FAILED) {
+ printf("%s: ubuf_fd mmap fail\n", TEST_PREFIX);
+ exit(1);
+ }
+
+ return addr;
+}
+
+static int compare_chunks(void *addr1, void *addr2, off64_t memfd_size)
+{
+ off64_t off;
+ int i = 0, j, k = 0, ret = 0;
+ char char1, char2;
+
+ while (i < NUM_ENTRIES) {
+ off = i * (memfd_size / NUM_ENTRIES);
+ for (j = 0; j < NUM_PAGES; j++, k++) {
+ char1 = *((char *)addr1 + off + (j * getpagesize()));
+ char2 = *((char *)addr2 + (k * getpagesize()));
+ if (char1 != char2) {
+ ret = -1;
+ goto err;
+ }
+ }
+ i++;
+ }
+err:
+ munmap(addr1, memfd_size);
+ munmap(addr2, NUM_ENTRIES * NUM_PAGES * getpagesize());
+ return ret;
}
int main(int argc, char *argv[])
{
[PATCH 10/12] drm/client: Use [CONNECTOR:%d:%s] formatting
From: Ville Syrjälä
Switch to the canonical [CONNECTOR:%d:%s] etc. format for
printing out kms objects.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_client_modeset.c | 65 +++-
1 file changed, 35 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/drm_client_modeset.c
b/drivers/gpu/drm/drm_client_modeset.c
index 1751162b7d5c..415d1799337b 100644
--- a/drivers/gpu/drm/drm_client_modeset.c
+++ b/drivers/gpu/drm/drm_client_modeset.c
@@ -251,8 +251,10 @@ static void drm_client_connectors_enabled(struct
drm_device *dev,
for (i = 0; i < connector_count; i++) {
connector = connectors[i];
enabled[i] = drm_connector_enabled(connector, true);
- drm_dbg_kms(dev, "connector %d enabled? %s\n",
connector->base.id,
- connector->display_info.non_desktop ? "non desktop"
: str_yes_no(enabled[i]));
+ drm_dbg_kms(dev, "[CONNECTOR:%d:%s] enabled? %s\n",
+ connector->base.id, connector->name,
+ connector->display_info.non_desktop ?
+ "non desktop" : str_yes_no(enabled[i]));
any_enabled |= enabled[i];
}
@@ -368,8 +370,8 @@ static int drm_client_get_tile_offsets(struct drm_device
*dev,
continue;
if (!modes[i] && (h_idx || v_idx)) {
- drm_dbg_kms(dev, "no modes for connector tiled %d %d\n",
- i, connector->base.id);
+ drm_dbg_kms(dev, "no modes for tiled
[CONNECTOR:%d:%s]\n",
+ connector->base.id, connector->name);
continue;
}
if (connector->tile_h_loc < h_idx)
@@ -438,14 +440,15 @@ static bool drm_client_target_preferred(struct drm_device
*dev,
drm_client_get_tile_offsets(dev, connectors,
connector_count, modes, offsets, i,
connector->tile_h_loc,
connector->tile_v_loc);
}
- drm_dbg_kms(dev, "looking for cmdline mode on connector %d\n",
- connector->base.id);
+ drm_dbg_kms(dev, "looking for cmdline mode on
[CONNECTOR:%d:%s]\n",
+ connector->base.id, connector->name);
/* got for command line mode first */
modes[i] = drm_connector_pick_cmdline_mode(connector);
if (!modes[i]) {
- drm_dbg_kms(dev, "looking for preferred mode on
connector %d %d\n",
- connector->base.id, connector->tile_group ?
connector->tile_group->id : 0);
+ drm_dbg_kms(dev, "looking for preferred mode on
[CONNECTOR:%d:%s] (tile group: %d)\n",
+ connector->base.id, connector->name,
+ connector->tile_group ?
connector->tile_group->id : 0);
modes[i] = drm_connector_preferred_mode(connector,
width, height);
}
/* No preferred modes, pick one off the list */
@@ -465,8 +468,8 @@ static bool drm_client_target_preferred(struct drm_device
*dev,
(connector->tile_h_loc == 0 &&
connector->tile_v_loc == 0 &&
!drm_connector_get_tiled_mode(connector))) {
- drm_dbg_kms(dev, "Falling back to non tiled
mode on Connector %d\n",
- connector->base.id);
+ drm_dbg_kms(dev, "Falling back to non tiled
mode on [CONNECTOR:%d:%s]\n",
+ connector->base.id,
connector->name);
modes[i] =
drm_connector_fallback_non_tiled_mode(connector);
} else {
modes[i] =
drm_connector_get_tiled_mode(connector);
@@ -634,15 +637,15 @@ static bool drm_client_firmware_config(struct
drm_client_dev *client,
num_connectors_detected++;
if (!enabled[i]) {
- drm_dbg_kms(dev, "connector %s not enabled, skipping\n",
- connector->name);
+ drm_dbg_kms(dev, "[CONNECTOR:%d:%s] not enabled,
skipping\n",
+ connector->base.id, connector->name);
conn_configured |= BIT(i);
continue;
}
if (connector->force == DRM_FORCE_OFF) {
- drm_dbg_kms(dev, "connector %s is disabled by user,
skipping\n",
- connector->name);
+ drm_dbg_kms(dev, "[CONNECTOR:%d:%s] is disabled by
user, skipping\n",
+
[PATCH 08/12] drm/client: Extract drm_connector_first_mode()
From: Ville Syrjälä
Use a consistent method for picking the first mode from the
connnector's mode list.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_client_modeset.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_client_modeset.c
b/drivers/gpu/drm/drm_client_modeset.c
index 08fc896885dd..1fba6cd8d761 100644
--- a/drivers/gpu/drm/drm_client_modeset.c
+++ b/drivers/gpu/drm/drm_client_modeset.c
@@ -159,6 +159,13 @@ drm_connector_preferred_mode(struct drm_connector
*connector, int width, int hei
return NULL;
}
+static const struct drm_display_mode *
+drm_connector_first_mode(struct drm_connector *connector)
+{
+ return list_first_entry_or_null(>modes,
+ struct drm_display_mode, head);
+}
+
static const struct drm_display_mode *
drm_connector_pick_cmdline_mode(struct drm_connector *connector)
{
@@ -439,10 +446,8 @@ static bool drm_client_target_preferred(struct
drm_connector *connectors[],
modes[i] = drm_connector_preferred_mode(connector,
width, height);
}
/* No preferred modes, pick one off the list */
- if (!modes[i] && !list_empty(>modes)) {
- list_for_each_entry(modes[i], >modes, head)
- break;
- }
+ if (!modes[i])
+ modes[i] = drm_connector_first_mode(connector);
/*
* In case of tiled mode if all tiles not present fallback to
* first available non tiled mode.
@@ -684,9 +689,7 @@ static bool drm_client_firmware_config(struct
drm_client_dev *client,
if (!modes[i] && !list_empty(>modes)) {
DRM_DEBUG_KMS("using first mode listed on connector
%s\n",
connector->name);
- modes[i] = list_first_entry(>modes,
- struct drm_display_mode,
- head);
+ modes[i] = drm_connector_first_mode(connector);
}
/* last resort: use current mode */
--
2.43.2
[PATCH 07/12] drm/client: Use array notation for function arguments
From: Ville Syrjälä
Use the array notation rather that the pointer notation for
function arguments. This makes it clear to the reader that
we are in fact dealing with an array rather than a single
pointer. Functionally the two are equivalent.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_client_modeset.c | 42 ++--
1 file changed, 21 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/drm_client_modeset.c
b/drivers/gpu/drm/drm_client_modeset.c
index 384a9f8227a0..08fc896885dd 100644
--- a/drivers/gpu/drm/drm_client_modeset.c
+++ b/drivers/gpu/drm/drm_client_modeset.c
@@ -232,9 +232,9 @@ static bool drm_connector_enabled(struct drm_connector
*connector, bool strict)
return enable;
}
-static void drm_client_connectors_enabled(struct drm_connector **connectors,
+static void drm_client_connectors_enabled(struct drm_connector *connectors[],
unsigned int connector_count,
- bool *enabled)
+ bool enabled[])
{
bool any_enabled = false;
struct drm_connector *connector;
@@ -257,11 +257,11 @@ static void drm_client_connectors_enabled(struct
drm_connector **connectors,
}
static bool drm_client_target_cloned(struct drm_device *dev,
-struct drm_connector **connectors,
+struct drm_connector *connectors[],
unsigned int connector_count,
-const struct drm_display_mode **modes,
-struct drm_client_offset *offsets,
-bool *enabled, int width, int height)
+const struct drm_display_mode *modes[],
+struct drm_client_offset offsets[],
+bool enabled[], int width, int height)
{
int count, i, j;
bool can_clone = false;
@@ -342,10 +342,10 @@ static bool drm_client_target_cloned(struct drm_device
*dev,
return false;
}
-static int drm_client_get_tile_offsets(struct drm_connector **connectors,
+static int drm_client_get_tile_offsets(struct drm_connector *connectors[],
unsigned int connector_count,
- const struct drm_display_mode **modes,
- struct drm_client_offset *offsets,
+ const struct drm_display_mode *modes[],
+ struct drm_client_offset offsets[],
int idx,
int h_idx, int v_idx)
{
@@ -375,11 +375,11 @@ static int drm_client_get_tile_offsets(struct
drm_connector **connectors,
return 0;
}
-static bool drm_client_target_preferred(struct drm_connector **connectors,
+static bool drm_client_target_preferred(struct drm_connector *connectors[],
unsigned int connector_count,
- const struct drm_display_mode **modes,
- struct drm_client_offset *offsets,
- bool *enabled, int width, int height)
+ const struct drm_display_mode *modes[],
+ struct drm_client_offset offsets[],
+ bool enabled[], int width, int height)
{
const u64 mask = BIT_ULL(connector_count) - 1;
struct drm_connector *connector;
@@ -491,10 +491,10 @@ static bool connector_has_possible_crtc(struct
drm_connector *connector,
}
static int drm_client_pick_crtcs(struct drm_client_dev *client,
-struct drm_connector **connectors,
+struct drm_connector *connectors[],
unsigned int connector_count,
-struct drm_crtc **best_crtcs,
-const struct drm_display_mode **modes,
+struct drm_crtc *best_crtcs[],
+const struct drm_display_mode *modes[],
int n, int width, int height)
{
struct drm_device *dev = client->dev;
@@ -566,12 +566,12 @@ static int drm_client_pick_crtcs(struct drm_client_dev
*client,
/* Try to read the BIOS display configuration and use it for the initial
config */
static bool drm_client_firmware_config(struct drm_client_dev *client,
- struct drm_connector **connectors,
+ struct drm_connector *connectors[],
unsigned int connector_count,
- struct drm_crtc **crtcs,
-
[PATCH 12/12] drm/probe-helper: Switch to per-device debugs
From: Ville Syrjälä
Switch to per-device debugs so that we know which
device we're dealing with.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_probe_helper.c | 35 ++
1 file changed, 16 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/drm_probe_helper.c
b/drivers/gpu/drm/drm_probe_helper.c
index 968a3ee66b1e..0860f7367511 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -567,8 +567,8 @@ int drm_helper_probe_single_connector_modes(struct
drm_connector *connector,
drm_modeset_acquire_init(, 0);
- DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n", connector->base.id,
- connector->name);
+ drm_dbg_kms(dev, "[CONNECTOR:%d:%s]\n",
+ connector->base.id, connector->name);
retry:
ret = drm_modeset_lock(>mode_config.connection_mutex, );
@@ -611,11 +611,10 @@ int drm_helper_probe_single_connector_modes(struct
drm_connector *connector,
* check here, and if anything changed start the hotplug code.
*/
if (old_status != connector->status) {
- DRM_DEBUG_KMS("[CONNECTOR:%d:%s] status updated from %s to
%s\n",
- connector->base.id,
- connector->name,
- drm_get_connector_status_name(old_status),
- drm_get_connector_status_name(connector->status));
+ drm_dbg_kms(dev, "[CONNECTOR:%d:%s] status updated from %s to
%s\n",
+ connector->base.id, connector->name,
+ drm_get_connector_status_name(old_status),
+ drm_get_connector_status_name(connector->status));
/*
* The hotplug event code might call into the fb
@@ -638,8 +637,8 @@ int drm_helper_probe_single_connector_modes(struct
drm_connector *connector,
drm_kms_helper_poll_enable(dev);
if (connector->status == connector_status_disconnected) {
- DRM_DEBUG_KMS("[CONNECTOR:%d:%s] disconnected\n",
- connector->base.id, connector->name);
+ drm_dbg_kms(dev, "[CONNECTOR:%d:%s] disconnected\n",
+ connector->base.id, connector->name);
drm_connector_update_edid_property(connector, NULL);
drm_mode_prune_invalid(dev, >modes, false);
goto exit;
@@ -697,8 +696,8 @@ int drm_helper_probe_single_connector_modes(struct
drm_connector *connector,
drm_mode_sort(>modes);
- DRM_DEBUG_KMS("[CONNECTOR:%d:%s] probed modes :\n", connector->base.id,
- connector->name);
+ drm_dbg_kms(dev, "[CONNECTOR:%d:%s] probed modes :\n",
+ connector->base.id, connector->name);
list_for_each_entry(mode, >modes, head) {
drm_mode_set_crtcinfo(mode, CRTC_INTERLACE_HALVE_V);
drm_mode_debug_printmodeline(mode);
@@ -834,14 +833,12 @@ static void output_poll_execute(struct work_struct *work)
old = drm_get_connector_status_name(old_status);
new = drm_get_connector_status_name(connector->status);
- DRM_DEBUG_KMS("[CONNECTOR:%d:%s] "
- "status updated from %s to %s\n",
- connector->base.id,
- connector->name,
- old, new);
- DRM_DEBUG_KMS("[CONNECTOR:%d:%s] epoch counter %llu ->
%llu\n",
- connector->base.id, connector->name,
- old_epoch_counter,
connector->epoch_counter);
+ drm_dbg_kms(dev, "[CONNECTOR:%d:%s] status updated from
%s to %s\n",
+ connector->base.id, connector->name,
+ old, new);
+ drm_dbg_kms(dev, "[CONNECTOR:%d:%s] epoch counter %llu
-> %llu\n",
+ connector->base.id, connector->name,
+ old_epoch_counter,
connector->epoch_counter);
changed = true;
}
--
2.43.2
[PATCH 09/12] drm/client: Switch to per-device debugs
From: Ville Syrjälä
Use drm_dev_dbg() & co. so that we know which device we're
dealing with.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_client_modeset.c | 117 ++-
1 file changed, 60 insertions(+), 57 deletions(-)
diff --git a/drivers/gpu/drm/drm_client_modeset.c
b/drivers/gpu/drm/drm_client_modeset.c
index 1fba6cd8d761..1751162b7d5c 100644
--- a/drivers/gpu/drm/drm_client_modeset.c
+++ b/drivers/gpu/drm/drm_client_modeset.c
@@ -239,7 +239,8 @@ static bool drm_connector_enabled(struct drm_connector
*connector, bool strict)
return enable;
}
-static void drm_client_connectors_enabled(struct drm_connector *connectors[],
+static void drm_client_connectors_enabled(struct drm_device *dev,
+ struct drm_connector *connectors[],
unsigned int connector_count,
bool enabled[])
{
@@ -250,8 +251,8 @@ static void drm_client_connectors_enabled(struct
drm_connector *connectors[],
for (i = 0; i < connector_count; i++) {
connector = connectors[i];
enabled[i] = drm_connector_enabled(connector, true);
- DRM_DEBUG_KMS("connector %d enabled? %s\n", connector->base.id,
- connector->display_info.non_desktop ? "non
desktop" : str_yes_no(enabled[i]));
+ drm_dbg_kms(dev, "connector %d enabled? %s\n",
connector->base.id,
+ connector->display_info.non_desktop ? "non desktop"
: str_yes_no(enabled[i]));
any_enabled |= enabled[i];
}
@@ -312,7 +313,7 @@ static bool drm_client_target_cloned(struct drm_device *dev,
}
if (can_clone) {
- DRM_DEBUG_KMS("can clone using command line\n");
+ drm_dbg_kms(dev, "can clone using command line\n");
return true;
}
@@ -341,15 +342,16 @@ static bool drm_client_target_cloned(struct drm_device
*dev,
drm_mode_destroy(dev, dmt_mode);
if (can_clone) {
- DRM_DEBUG_KMS("can clone using 1024x768\n");
+ drm_dbg_kms(dev, "can clone using 1024x768\n");
return true;
}
fail:
- DRM_INFO("kms: can't enable cloning when we probably wanted to.\n");
+ drm_info(dev, "kms: can't enable cloning when we probably wanted
to.\n");
return false;
}
-static int drm_client_get_tile_offsets(struct drm_connector *connectors[],
+static int drm_client_get_tile_offsets(struct drm_device *dev,
+ struct drm_connector *connectors[],
unsigned int connector_count,
const struct drm_display_mode *modes[],
struct drm_client_offset offsets[],
@@ -366,8 +368,8 @@ static int drm_client_get_tile_offsets(struct drm_connector
*connectors[],
continue;
if (!modes[i] && (h_idx || v_idx)) {
- DRM_DEBUG_KMS("no modes for connector tiled %d %d\n", i,
- connector->base.id);
+ drm_dbg_kms(dev, "no modes for connector tiled %d %d\n",
+ i, connector->base.id);
continue;
}
if (connector->tile_h_loc < h_idx)
@@ -378,11 +380,12 @@ static int drm_client_get_tile_offsets(struct
drm_connector *connectors[],
}
offsets[idx].x = hoffset;
offsets[idx].y = voffset;
- DRM_DEBUG_KMS("returned %d %d for %d %d\n", hoffset, voffset, h_idx,
v_idx);
+ drm_dbg_kms(dev, "returned %d %d for %d %d\n", hoffset, voffset, h_idx,
v_idx);
return 0;
}
-static bool drm_client_target_preferred(struct drm_connector *connectors[],
+static bool drm_client_target_preferred(struct drm_device *dev,
+ struct drm_connector *connectors[],
unsigned int connector_count,
const struct drm_display_mode *modes[],
struct drm_client_offset offsets[],
@@ -432,17 +435,17 @@ static bool drm_client_target_preferred(struct
drm_connector *connectors[],
* find the tile offsets for this pass - need to find
* all tiles left and above
*/
- drm_client_get_tile_offsets(connectors,
connector_count, modes, offsets, i,
+ drm_client_get_tile_offsets(dev, connectors,
connector_count, modes, offsets, i,
connector->tile_h_loc,
connector->tile_v_loc);
}
- DRM_DEBUG_KMS("looking for cmdline mode on connector %d\n",
- connector->base.id);
+
[PATCH 06/12] drm/client: Constify modes
From: Ville Syrjälä
The modes used by the client code live on the connectors' mode
lists, which are not owned by the client code, and thus it has
no business modifying the modes. Mark the modes const to make
that fact abundantly clear.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_client_modeset.c | 36 +++-
1 file changed, 19 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/drm_client_modeset.c
b/drivers/gpu/drm/drm_client_modeset.c
index cf1de06f99aa..384a9f8227a0 100644
--- a/drivers/gpu/drm/drm_client_modeset.c
+++ b/drivers/gpu/drm/drm_client_modeset.c
@@ -117,10 +117,10 @@ drm_client_find_modeset(struct drm_client_dev *client,
struct drm_crtc *crtc)
return NULL;
}
-static struct drm_display_mode *
+static const struct drm_display_mode *
drm_connector_get_tiled_mode(struct drm_connector *connector)
{
- struct drm_display_mode *mode;
+ const struct drm_display_mode *mode;
list_for_each_entry(mode, >modes, head) {
if (mode->hdisplay == connector->tile_h_size &&
@@ -130,10 +130,10 @@ drm_connector_get_tiled_mode(struct drm_connector
*connector)
return NULL;
}
-static struct drm_display_mode *
+static const struct drm_display_mode *
drm_connector_fallback_non_tiled_mode(struct drm_connector *connector)
{
- struct drm_display_mode *mode;
+ const struct drm_display_mode *mode;
list_for_each_entry(mode, >modes, head) {
if (mode->hdisplay == connector->tile_h_size &&
@@ -144,10 +144,10 @@ drm_connector_fallback_non_tiled_mode(struct
drm_connector *connector)
return NULL;
}
-static struct drm_display_mode *
+static const struct drm_display_mode *
drm_connector_preferred_mode(struct drm_connector *connector, int width, int
height)
{
- struct drm_display_mode *mode;
+ const struct drm_display_mode *mode;
list_for_each_entry(mode, >modes, head) {
if (mode->hdisplay > width ||
@@ -159,10 +159,11 @@ drm_connector_preferred_mode(struct drm_connector
*connector, int width, int hei
return NULL;
}
-static struct drm_display_mode *drm_connector_pick_cmdline_mode(struct
drm_connector *connector)
+static const struct drm_display_mode *
+drm_connector_pick_cmdline_mode(struct drm_connector *connector)
{
- struct drm_cmdline_mode *cmdline_mode;
- struct drm_display_mode *mode;
+ const struct drm_cmdline_mode *cmdline_mode;
+ const struct drm_display_mode *mode;
bool prefer_non_interlace;
/*
@@ -258,13 +259,14 @@ static void drm_client_connectors_enabled(struct
drm_connector **connectors,
static bool drm_client_target_cloned(struct drm_device *dev,
struct drm_connector **connectors,
unsigned int connector_count,
-struct drm_display_mode **modes,
+const struct drm_display_mode **modes,
struct drm_client_offset *offsets,
bool *enabled, int width, int height)
{
int count, i, j;
bool can_clone = false;
- struct drm_display_mode *dmt_mode, *mode;
+ const struct drm_display_mode *mode;
+ struct drm_display_mode *dmt_mode;
/* only contemplate cloning in the single crtc case */
if (dev->mode_config.num_crtc > 1)
@@ -342,7 +344,7 @@ static bool drm_client_target_cloned(struct drm_device *dev,
static int drm_client_get_tile_offsets(struct drm_connector **connectors,
unsigned int connector_count,
- struct drm_display_mode **modes,
+ const struct drm_display_mode **modes,
struct drm_client_offset *offsets,
int idx,
int h_idx, int v_idx)
@@ -375,7 +377,7 @@ static int drm_client_get_tile_offsets(struct drm_connector
**connectors,
static bool drm_client_target_preferred(struct drm_connector **connectors,
unsigned int connector_count,
- struct drm_display_mode **modes,
+ const struct drm_display_mode **modes,
struct drm_client_offset *offsets,
bool *enabled, int width, int height)
{
@@ -492,7 +494,7 @@ static int drm_client_pick_crtcs(struct drm_client_dev
*client,
struct drm_connector **connectors,
unsigned int connector_count,
struct drm_crtc **best_crtcs,
-struct drm_display_mode **modes,
+const struct drm_display_mode
[PATCH 11/12] drm/client: Streamline mode selection debugs
From: Ville Syrjälä
Get rid of all the redundant debugs and just wait until the end
to print which mode (and of which type) we picked.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_client_modeset.c | 65 +---
1 file changed, 31 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/drm_client_modeset.c
b/drivers/gpu/drm/drm_client_modeset.c
index 415d1799337b..ad88c11037d8 100644
--- a/drivers/gpu/drm/drm_client_modeset.c
+++ b/drivers/gpu/drm/drm_client_modeset.c
@@ -408,6 +408,8 @@ static bool drm_client_target_preferred(struct drm_device
*dev,
retry:
for (i = 0; i < connector_count; i++) {
+ const char *mode_type;
+
connector = connectors[i];
if (conn_configured & BIT_ULL(i))
@@ -440,20 +442,20 @@ static bool drm_client_target_preferred(struct drm_device
*dev,
drm_client_get_tile_offsets(dev, connectors,
connector_count, modes, offsets, i,
connector->tile_h_loc,
connector->tile_v_loc);
}
- drm_dbg_kms(dev, "looking for cmdline mode on
[CONNECTOR:%d:%s]\n",
- connector->base.id, connector->name);
- /* got for command line mode first */
+ mode_type = "cmdline";
modes[i] = drm_connector_pick_cmdline_mode(connector);
+
if (!modes[i]) {
- drm_dbg_kms(dev, "looking for preferred mode on
[CONNECTOR:%d:%s] (tile group: %d)\n",
- connector->base.id, connector->name,
- connector->tile_group ?
connector->tile_group->id : 0);
+ mode_type = "preferred";
modes[i] = drm_connector_preferred_mode(connector,
width, height);
}
- /* No preferred modes, pick one off the list */
- if (!modes[i])
+
+ if (!modes[i]) {
+ mode_type = "first";
modes[i] = drm_connector_first_mode(connector);
+ }
+
/*
* In case of tiled mode if all tiles not present fallback to
* first available non tiled mode.
@@ -468,16 +470,20 @@ static bool drm_client_target_preferred(struct drm_device
*dev,
(connector->tile_h_loc == 0 &&
connector->tile_v_loc == 0 &&
!drm_connector_get_tiled_mode(connector))) {
- drm_dbg_kms(dev, "Falling back to non tiled
mode on [CONNECTOR:%d:%s]\n",
- connector->base.id,
connector->name);
+ mode_type = "non tiled";
modes[i] =
drm_connector_fallback_non_tiled_mode(connector);
} else {
+ mode_type = "tiled";
modes[i] =
drm_connector_get_tiled_mode(connector);
}
}
- drm_dbg_kms(dev, "found mode %s\n",
- modes[i] ? modes[i]->name : "none");
+ if (!modes[i])
+ mode_type = "no";
+
+ drm_dbg_kms(dev, "[CONNECTOR:%d:%s] found %s mode: %s\n",
+ connector->base.id, connector->name,
+ mode_type, modes[i] ? modes[i]->name : "none");
conn_configured |= BIT_ULL(i);
}
@@ -624,6 +630,7 @@ static bool drm_client_firmware_config(struct
drm_client_dev *client,
struct drm_connector *connector;
struct drm_encoder *encoder;
struct drm_crtc *new_crtc;
+ const char *mode_type;
connector = connectors[i];
@@ -673,29 +680,22 @@ static bool drm_client_firmware_config(struct
drm_client_dev *client,
*/
for (j = 0; j < count; j++) {
if (crtcs[j] == new_crtc) {
- drm_dbg_kms(dev, "fallback: cloned
configuration\n");
+ drm_dbg_kms(dev, "[CONNECTOR:%d:%s] fallback:
cloned configuration\n",
+ connector->base.id,
connector->name);
goto bail;
}
}
- drm_dbg_kms(dev, "looking for cmdline mode on
[CONNECTOR:%d:%s]\n",
- connector->base.id, connector->name);
-
- /* go for command line mode first */
+ mode_type = "cmdline";
modes[i] = drm_connector_pick_cmdline_mode(connector);
- /* try for preferred next */
if (!modes[i]) {
- drm_dbg_kms(dev, "looking for preferred mode on
[CONNECTOR:%d:%s] (tiled?
[PATCH 05/12] drm/client: Nuke outdated fastboot comment
From: Ville Syrjälä
Remove the tall tale about fastboot vs. user mode vs.
adjusted mode. crtc->mode == crtc->state->mode, so none
of this makes any sense. I suppose it may have been true
long ago in the past.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_client_modeset.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/gpu/drm/drm_client_modeset.c
b/drivers/gpu/drm/drm_client_modeset.c
index 8ef03608b424..cf1de06f99aa 100644
--- a/drivers/gpu/drm/drm_client_modeset.c
+++ b/drivers/gpu/drm/drm_client_modeset.c
@@ -690,16 +690,6 @@ static bool drm_client_firmware_config(struct
drm_client_dev *client,
/* last resort: use current mode */
if (!modes[i]) {
/*
-* IMPORTANT: We want to use the adjusted mode (i.e.
-* after the panel fitter upscaling) as the initial
-* config, not the input mode, which is what crtc->mode
-* usually contains. But since our current
-* code puts a mode derived from the post-pfit timings
-* into crtc->mode this works out correctly.
-*
-* This is crtc->mode and not crtc->state->mode for the
-* fastboot check to work correctly.
-*
* FIXME using legacy crtc->mode with atomic drivers
* is dodgy. Switch to crtc->state->mode, after taking
* care of the resulting locking/lifetime issues.
--
2.43.2
[PATCH 04/12] drm/client: Add a FIXME around crtc->mode usage
From: Ville Syrjälä
crtc->mode is legacy junk and shouldn't really be used with
atomic drivers.
Most (all?) atomic drivers do end up still calling
drm_atomic_helper_update_legacy_modeset_state() at some
point, so crtc->mode does still get populated, and this
does work for now. But eventually would be nice to eliminate
all the legacy stuff from atomic drivers.
Switching to crtc->state->mode would require some bigger
changes however, as we currently drop the crtc->mutex
before we're done using the mode. So leave the junk in
for now and just add a FIXME to remind us that this
needs fixing.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_client_modeset.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/drm_client_modeset.c
b/drivers/gpu/drm/drm_client_modeset.c
index 2b7d0be04911..8ef03608b424 100644
--- a/drivers/gpu/drm/drm_client_modeset.c
+++ b/drivers/gpu/drm/drm_client_modeset.c
@@ -699,6 +699,10 @@ static bool drm_client_firmware_config(struct
drm_client_dev *client,
*
* This is crtc->mode and not crtc->state->mode for the
* fastboot check to work correctly.
+*
+* FIXME using legacy crtc->mode with atomic drivers
+* is dodgy. Switch to crtc->state->mode, after taking
+* care of the resulting locking/lifetime issues.
*/
DRM_DEBUG_KMS("looking for current mode on connector
%s\n",
connector->name);
--
2.43.2
[PATCH 03/12] drm/client: Use drm_mode_destroy()
From: Ville Syrjälä
Prefer drm_mode_destroy() over bare kfree(), for consistency
and setting a good example.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_client_modeset.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_client_modeset.c
b/drivers/gpu/drm/drm_client_modeset.c
index 1c3aeb2dfa57..2b7d0be04911 100644
--- a/drivers/gpu/drm/drm_client_modeset.c
+++ b/drivers/gpu/drm/drm_client_modeset.c
@@ -329,7 +329,7 @@ static bool drm_client_target_cloned(struct drm_device *dev,
if (!modes[i])
can_clone = false;
}
- kfree(dmt_mode);
+ drm_mode_destroy(dev, dmt_mode);
if (can_clone) {
DRM_DEBUG_KMS("can clone using 1024x768\n");
@@ -867,7 +867,7 @@ int drm_client_modeset_probe(struct drm_client_dev *client,
unsigned int width,
break;
}
- kfree(modeset->mode);
+ drm_mode_destroy(dev, modeset->mode);
modeset->mode = drm_mode_duplicate(dev, mode);
drm_connector_get(connector);
modeset->connectors[modeset->num_connectors++] =
connector;
--
2.43.2
[PATCH 02/12] drm/client: s/drm_connector_has_preferred_mode/drm_connector_preferred_mode/
From: Ville Syrjälä
Drop the "has" from drm_connector_has_preferred_mode() to better
describe what it does.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_client_modeset.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_client_modeset.c
b/drivers/gpu/drm/drm_client_modeset.c
index 0683a129b362..1c3aeb2dfa57 100644
--- a/drivers/gpu/drm/drm_client_modeset.c
+++ b/drivers/gpu/drm/drm_client_modeset.c
@@ -145,7 +145,7 @@ drm_connector_fallback_non_tiled_mode(struct drm_connector
*connector)
}
static struct drm_display_mode *
-drm_connector_has_preferred_mode(struct drm_connector *connector, int width,
int height)
+drm_connector_preferred_mode(struct drm_connector *connector, int width, int
height)
{
struct drm_display_mode *mode;
@@ -434,7 +434,7 @@ static bool drm_client_target_preferred(struct
drm_connector **connectors,
if (!modes[i]) {
DRM_DEBUG_KMS("looking for preferred mode on connector
%d %d\n",
connector->base.id, connector->tile_group
? connector->tile_group->id : 0);
- modes[i] = drm_connector_has_preferred_mode(connector,
width, height);
+ modes[i] = drm_connector_preferred_mode(connector,
width, height);
}
/* No preferred modes, pick one off the list */
if (!modes[i] && !list_empty(>modes)) {
@@ -522,7 +522,7 @@ static int drm_client_pick_crtcs(struct drm_client_dev
*client,
my_score++;
if (connector->cmdline_mode.specified)
my_score++;
- if (drm_connector_has_preferred_mode(connector, width, height))
+ if (drm_connector_preferred_mode(connector, width, height))
my_score++;
/*
@@ -675,7 +675,7 @@ static bool drm_client_firmware_config(struct
drm_client_dev *client,
if (!modes[i]) {
DRM_DEBUG_KMS("looking for preferred mode on connector
%s %d\n",
connector->name, connector->has_tile);
- modes[i] = drm_connector_has_preferred_mode(connector,
width, height);
+ modes[i] = drm_connector_preferred_mode(connector,
width, height);
}
/* No preferred mode marked by the EDID? Are there any modes? */
--
2.43.2
[PATCH 01/12] drm/client: Fully protect modes[] with dev->mode_config.mutex
From: Ville Syrjälä The modes[] array contains pointers to modes on the connectors' mode lists, which are protected by dev->mode_config.mutex. Thus we need to extend modes[] the same protection or by the time we use it the elements may already be pointing to freed/reused memory. Cc: sta...@vger.kernel.org Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10583 Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_client_modeset.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_client_modeset.c b/drivers/gpu/drm/drm_client_modeset.c index 871e4e2129d6..0683a129b362 100644 --- a/drivers/gpu/drm/drm_client_modeset.c +++ b/drivers/gpu/drm/drm_client_modeset.c @@ -777,6 +777,7 @@ int drm_client_modeset_probe(struct drm_client_dev *client, unsigned int width, unsigned int total_modes_count = 0; struct drm_client_offset *offsets; unsigned int connector_count = 0; + /* points to modes protected by mode_config.mutex */ struct drm_display_mode **modes; struct drm_crtc **crtcs; int i, ret = 0; @@ -845,7 +846,6 @@ int drm_client_modeset_probe(struct drm_client_dev *client, unsigned int width, drm_client_pick_crtcs(client, connectors, connector_count, crtcs, modes, 0, width, height); } - mutex_unlock(>mode_config.mutex); drm_client_modeset_release(client); @@ -875,6 +875,7 @@ int drm_client_modeset_probe(struct drm_client_dev *client, unsigned int width, modeset->y = offset->y; } } + mutex_unlock(>mode_config.mutex); mutex_unlock(>modeset_mutex); out: -- 2.43.2
[PATCH 00/12] drm/client: Use after free and debug improvements
From: Ville Syrjälä Various improvements to the drm/client code: - Fix a use after free (fairly routinely hit by i915 CI) - Debug print improvements - Cleanups/etc. Ville Syrjälä (12): drm/client: Fully protect modes[] with dev->mode_config.mutex drm/client: s/drm_connector_has_preferred_mode/drm_connector_preferred_mode/ drm/client: Use drm_mode_destroy() drm/client: Add a FIXME around crtc->mode usage drm/client: Nuke outdated fastboot comment drm/client: Constify modes drm/client: Use array notation for function arguments drm/client: Extract drm_connector_first_mode() drm/client: Switch to per-device debugs drm/client: Use [CONNECTOR:%d:%s] formatting drm/client: Streamline mode selection debugs drm/probe-helper: Switch to per-device debugs drivers/gpu/drm/drm_client_modeset.c | 237 ++- drivers/gpu/drm/drm_probe_helper.c | 35 ++-- 2 files changed, 137 insertions(+), 135 deletions(-) -- 2.43.2
Re: [PATCH v1 2/3] dt-bindings: arm: mediatek: mmsys: Add OF graph support for board path
Hi AngeloGioacchino,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on robh/for-next pza/reset/next linus/master v6.9-rc2
next-20240404]
[cannot apply to pza/imx-drm/next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/AngeloGioacchino-Del-Regno/dt-bindings-display-mediatek-Add-OF-graph-support-for-board-path/20240404-161930
base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link:
https://lore.kernel.org/r/20240404081635.91412-3-angelogioacchino.delregno%40collabora.com
patch subject: [PATCH v1 2/3] dt-bindings: arm: mediatek: mmsys: Add OF graph
support for board path
compiler: loongarch64-linux-gcc (GCC) 13.2.0
reproduce:
(https://download.01.org/0day-ci/archive/20240405/202404050315.7wbdw2e8-...@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot
| Closes:
https://lore.kernel.org/oe-kbuild-all/202404050315.7wbdw2e8-...@intel.com/
dtcheck warnings: (new ones prefixed by >>)
>> Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml:
>> properties:port:properties:required: ['endpoint@0'] is not of type 'object',
>> 'boolean'
from schema $id: http://json-schema.org/draft-07/schema#
>> Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml:
>> properties:port:properties: 'required' should not be valid under {'$ref':
>> '#/definitions/json-schema-prop-names'}
hint: A json-schema keyword was found instead of a DT property name.
from schema $id: http://devicetree.org/meta-schemas/keywords.yaml#
>> Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml:
>> properties:port:properties:required: ['endpoint@0'] is not of type 'object',
>> 'boolean'
from schema $id: http://devicetree.org/meta-schemas/keywords.yaml#
--
>> Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml:
>> ignoring, error in schema: properties: port: properties: required
Documentation/devicetree/bindings/net/snps,dwmac.yaml: mac-mode: missing
type definition
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
Re: [PATCH v0 10/14] sfc: falcon: Make I2C terminology more inclusive
On 4/2/2024 2:00 AM, Martin Habets wrote: > On Fri, Mar 29, 2024 at 05:00:34PM +, Easwar Hariharan wrote: >> I2C v7, SMBus 3.2, and I3C specifications have replaced "master/slave" >> with more appropriate terms. Inspired by and following on to Wolfram's >> series to fix drivers/i2c/[1], fix the terminology for users of >> I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists >> in the specification. >> >> Compile tested, no functionality changes intended >> >> [1]: >> https://lore.kernel.org/all/20240322132619.6389-1-wsa+rene...@sang-engineering.com/ >> >> Signed-off-by: Easwar Hariharan > > Reviewed-by: Martin Habets > Thank you, Martin, for reviewing. I believe that we are settling on controller/target terminology from feedback on the other drivers in this series. Would you want to re-review v1 with that change, or should I add your R-B in v1 despite the change? Thanks, Easwar
Re: [PATCH v0 10/14] sfc: falcon: Make I2C terminology more inclusive
On 4/2/2024 1:29 AM, Simon Horman wrote: > On Fri, Mar 29, 2024 at 05:00:34PM +, Easwar Hariharan wrote: >> I2C v7, SMBus 3.2, and I3C specifications have replaced "master/slave" >> with more appropriate terms. Inspired by and following on to Wolfram's >> series to fix drivers/i2c/[1], fix the terminology for users of >> I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists >> in the specification. >> >> Compile tested, no functionality changes intended >> >> [1]: >> https://lore.kernel.org/all/20240322132619.6389-1-wsa+rene...@sang-engineering.com/ >> >> Signed-off-by: Easwar Hariharan > > Reviewed-by: Simon Horman Thank you, Simon, for reviewing. I believe that we are settling on controller/target terminology from feedback on the other drivers in this series. Would you want to re-review v1 with that change, or should I add you R-B in v1 despite the change? Thanks, Easwar
[PATCH v2 1/1] Revert "drm/qxl: simplify qxl_fence_wait"
This reverts commit 5a838e5d5825c85556011478abde708251cc0776.
Changes from commit 5a838e5d5825 ("drm/qxl: simplify qxl_fence_wait") would
result in a '[TTM] Buffer eviction failed' exception whenever it reached a
timeout.
Due to a dependency to DMA_FENCE_WARN this also restores some code deleted
by commit d72277b6c37d ("dma-buf: nuke DMA_FENCE_TRACE macros v2").
Fixes: 5a838e5d5825 ("drm/qxl: simplify qxl_fence_wait")
Link: https://lore.kernel.org/regressions/ztgydqrlk6wx_...@eldamar.lan/
Reported-by: Timo Lindfors
Closes: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1054514
Signed-off-by: Alex Constantino
---
drivers/gpu/drm/qxl/qxl_release.c | 50 +++
include/linux/dma-fence.h | 7 +
2 files changed, 52 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_release.c
b/drivers/gpu/drm/qxl/qxl_release.c
index 368d26da0d6a..9febc8b73f09 100644
--- a/drivers/gpu/drm/qxl/qxl_release.c
+++ b/drivers/gpu/drm/qxl/qxl_release.c
@@ -58,16 +58,56 @@ static long qxl_fence_wait(struct dma_fence *fence, bool
intr,
signed long timeout)
{
struct qxl_device *qdev;
+ struct qxl_release *release;
+ int count = 0, sc = 0;
+ bool have_drawable_releases;
unsigned long cur, end = jiffies + timeout;
qdev = container_of(fence->lock, struct qxl_device, release_lock);
+ release = container_of(fence, struct qxl_release, base);
+ have_drawable_releases = release->type == QXL_RELEASE_DRAWABLE;
- if (!wait_event_timeout(qdev->release_event,
- (dma_fence_is_signaled(fence) ||
-(qxl_io_notify_oom(qdev), 0)),
- timeout))
- return 0;
+retry:
+ sc++;
+
+ if (dma_fence_is_signaled(fence))
+ goto signaled;
+
+ qxl_io_notify_oom(qdev);
+
+ for (count = 0; count < 11; count++) {
+ if (!qxl_queue_garbage_collect(qdev, true))
+ break;
+
+ if (dma_fence_is_signaled(fence))
+ goto signaled;
+ }
+
+ if (dma_fence_is_signaled(fence))
+ goto signaled;
+
+ if (have_drawable_releases || sc < 4) {
+ if (sc > 2)
+ /* back off */
+ usleep_range(500, 1000);
+
+ if (time_after(jiffies, end))
+ return 0;
+
+ if (have_drawable_releases && sc > 300) {
+ DMA_FENCE_WARN(fence,
+ "failed to wait on release %llu after
spincount %d\n",
+ fence->context & ~0xf000, sc);
+ goto signaled;
+ }
+ goto retry;
+ }
+ /*
+* yeah, original sync_obj_wait gave up after 3 spins when
+* have_drawable_releases is not set.
+*/
+signaled:
cur = jiffies;
if (time_after(cur, end))
return 0;
diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
index e06bad467f55..c3f9bb6602ba 100644
--- a/include/linux/dma-fence.h
+++ b/include/linux/dma-fence.h
@@ -682,4 +682,11 @@ static inline bool dma_fence_is_container(struct dma_fence
*fence)
return dma_fence_is_array(fence) || dma_fence_is_chain(fence);
}
+#define DMA_FENCE_WARN(f, fmt, args...) \
+ do {\
+ struct dma_fence *__ff = (f); \
+ pr_warn("f %llu#%llu: " fmt, __ff->context, __ff->seqno,\
+##args); \
+ } while (0)
+
#endif /* __LINUX_DMA_FENCE_H */
--
2.39.2
[PATCH v2 0/1] Revert "drm/qxl: simplify qxl_fence_wait"
Changes since v1:
- replace new code logic in v1 with past code version by reverting
commit 5a838e5d5825 ("drm/qxl: simplify qxl_fence_wait")
- add missing code dependency from
commit d72277b6c37d ("dma-buf: nuke DMA_FENCE_TRACE macros v2")
---
Hi,
To clarify, the reason for my original patch, as explained in more detail
in my previous email, was that it fixed the issue while keeping the code
simpler (which was the original reason for the commit being reverted here).
But I perfectly understand opting for previously battle tested code. Makes
sense.
As requested I've reverted commit 5a838e5d5825 ("drm/qxl: simplify
qxl_fence_wait")
and then executed both Timo's and my test cases, and 1h video playback.
I was unable to reproduce the bug with any of those cases. So the revert
seems to fix the bug.
Please note, and as stated in the commit message, due to a dependency to
DMA_FENCE_WARN this patch also restores the relevant code deleted
by commit d72277b6c37d ("dma-buf: nuke DMA_FENCE_TRACE macros v2").
A couple of things I've observed from dmesg:
- (1) it always triggers a single warning at boot, this is issued by
`WARN_ON(list_empty(>bos));` @ qxl_release_free @ qxl_release.c
Maybe better for this to be addressed separately from this patch?
- (2) there are quite a few `failed to wait on release xx after spincount
301` messages as printed by the patch v2 code when the test case shell
scripts are being executed.
- (3) there can be a single error message `[drm:qxl_release_from_id_locked
[qxl]] *ERROR* failed to find id in release_idr`
- (4) occasional error messages about `[drm:drm_atomic_helper_commit_planes
[drm_kms_helper]] *ERROR* head 9 wrong:`.
Issue (1) relates to this patch v2 and also happened with kernel from
base-commit 1870cdc0e8de (March 1st).
Issue (2) also relates to this patch v2 but only happens with kernel from
base-commit a6bd6c99 (March 30th).
Both (3) and (4) are unrelated to this patch as they can occur
independently of it and I'm guessing these may be related to the recent
changes discussed in
https://lore.kernel.org/dri-devel/38d38331-3848-4995-b78e-a87ecae72...@linux.intel.com/T/#u
For reference here is the output of (1):
```
[ 20.779514] [ cut here ]
[ 20.779525] workqueue: WQ_MEM_RECLAIM ttm:ttm_bo_delayed_delete [ttm] is
flushing !WQ_MEM_RECLAIM events:qxl_gc_work [qxl]
[ 20.779666] WARNING: CPU: 1 PID: 601 at kernel/workqueue.c:3692
check_flush_dependency+0xfa/0x110
[ 20.779683] Modules linked in: nfsv3 nfs_acl nfs lockd grace intel_rapl_msr
intel_rapl_common intel_pmc_core intel_vsec pmt_telemetry pmt_class kvm_intel
rfkill kvm snd_hda_codec_generic crct10dif_pclmul crct10dif_common crc32_pclmul
ghash_clmulni_intel snd_hda_intel snd_intel_dspcfg sha512_ssse3 sha512_generic
snd_hda_codec sha256_ssse3 snd_hwdep sha1_ssse3 snd_hda_core sunrpc binfmt_misc
snd_pcm aesni_intel qxl drm_ttm_helper ttm crypto_simd snd_timer cryptd rapl
snd virtio_balloon virtio_console drm_kms_helper pcspkr soundcore button evdev
joydev serio_raw drm loop fuse efi_pstore dm_mod configfs qemu_fw_cfg
virtio_rng autofs4 ext4 crc32c_generic crc16 mbcache jbd2 virtio_net
ata_generic net_failover virtio_blk failover uhci_hcd ata_piix ehci_hcd libata
scsi_mod usbcore crc32c_intel i2c_piix4 virtio_pci virtio psmouse
virtio_pci_legacy_dev virtio_pci_modern_dev virtio_ring floppy scsi_common
usb_common
[ 20.779825] CPU: 1 PID: 601 Comm: kworker/u13:1 Not tainted
6.9.0-rc1-next-20240328-amd64-1-g756220c4615c #81
[ 20.779833] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.14.0-2 04/01/2014
[ 20.779837] Workqueue: ttm ttm_bo_delayed_delete [ttm]
[ 20.779862] RIP: 0010:check_flush_dependency+0xfa/0x110
[ 20.779869] Code: ff ff 49 8b 55 18 48 8d 8b c0 00 00 00 49 89 e8 48 81 c6
c0 00 00 00 48 c7 c7 c0 16 44 8d c6 05 e7 75 b3 01 01 e8 86 97 fd ff <0f> 0b e9
21 ff ff ff 80 3d d5 75 b3 01 00 75 96 e9 4d ff ff ff 90
[ 20.779875] RSP: :b59600dd7cc8 EFLAGS: 00010082
[ 20.779880] RAX: RBX: 9af88104ee00 RCX: 0027
[ 20.779902] RDX: 9af8fdd21708 RSI: 0001 RDI: 9af8fdd21700
[ 20.779906] RBP: c0882570 R08: R09: 0003
[ 20.779910] R10: b59600dd7b58 R11: 8dcc83e8 R12: 9af894498000
[ 20.779914] R13: 9af89558d780 R14: b59600dd7cf8 R15: 0001
[ 20.779918] FS: () GS:9af8fdd0()
knlGS:
[ 20.779924] CS: 0010 DS: ES: CR0: 80050033
[ 20.779928] CR2: 5574b0bd4148 CR3: 1fb40002 CR4: 00370ef0
[ 20.779994] DR0: DR1: DR2:
[ 20.77] DR3: DR6: fffe0ff0 DR7: 0400
[ 20.780003] Call Trace:
[ 20.780135]
[ 20.780144] ? __warn+0x7c/0x120
[ 20.780153] ? check_flush_dependency+0xfa/0x110
[ 20.780161] ?
Re: [PATCH] drivers: video: logo: Don't mention the full path of the input in output
On 4/4/24 18:44, Lucas Stach wrote:
Am Donnerstag, dem 04.04.2024 um 15:15 +0200 schrieb Helge Deller:
On 4/4/24 14:18, Lucas Stach wrote:
This change strips $abs_srctree of the input file containing the
PNM data in the generated output. The motivation for this change
is Yocto emitting a build warning
WARNING: linux-foo-6.8-r0 do_package_qa: QA Issue:
File
/usr/src/debug/linux-foo/6.8-r0/drivers/video/logo/logo_linux_clut224.c
in package linux-foo-src contains reference to TMPDIR
So this change brings us one step closer to make the build result
reproducible independent of the build path.
Signed-off-by: Lucas Stach
---
drivers/video/logo/pnmtologo.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/video/logo/pnmtologo.c b/drivers/video/logo/pnmtologo.c
index 2434a25afb64..59ccd721e8af 100644
--- a/drivers/video/logo/pnmtologo.c
+++ b/drivers/video/logo/pnmtologo.c
@@ -223,6 +223,18 @@ static inline int is_equal(struct color c1, struct color
c2)
static void write_header(void)
{
+ const char *abs_srctree = getenv("abs_srctree");
+ const char *rel_filename;
+
+ if (abs_srctree &&
+ !strncmp(abs_srctree, filename, strlen(abs_srctree))) {
+ rel_filename = filename + strlen(abs_srctree);
+ while (*rel_filename == '/')
+ ++rel_filename;
+ } else {
+ rel_filename = filename;
+ }
+
/* open logo file */
if (outputname) {
out = fopen(outputname, "w");
@@ -235,7 +247,7 @@ static void write_header(void)
fputs("/*\n", out);
fputs(" * DO NOT EDIT THIS FILE!\n", out);
fputs(" *\n", out);
- fprintf(out, " * It was automatically generated from %s\n", filename);
+ fprintf(out, " * It was automatically generated from %s\n",
rel_filename);
can't you use instead: ?
+ fprintf(out, " * It was automatically generated from %s\n",
basename(filename));
The difference to basename is that this keeps the path in the source
tree intact, e.g. it shortens the absolute path to
"drivers/video/logo/logo_linux_clut224.c", so the comment in the
generated file still has a full reference to the file location in the
source tree. It only strips out the part of the path that is host
dependent.
That's true, but
a) it's just a comment which is generated, and
b) all source and generated logo files are in the
[src|build]/drivers/video/logo/ directory anyway, and
c) the file name already suggests where it is generated from.
So, IMHO basically we could simply drop the whole comment line alltogether as
well.
Helge
[PULL] drm-intel-fixes
Hi Dave and Sima, Here goes drm-intel-fixes-2024-04-04: Display fixes: - A few DisplayPort related fixes (Imre, Arun, Ankit, Ville) - eDP PSR fixes (Jouni) Core/GT fixes: - Remove some VM space restrictions on older platforms (Andi) - Disable automatic load CCS load balancing (Andi) Thanks, Rodrigo. The following changes since commit 39cd87c4eb2b893354f3b850f916353f2658ae6f: Linux 6.9-rc2 (2024-03-31 14:32:39 -0700) are available in the Git repository at: https://anongit.freedesktop.org/git/drm/drm-intel tags/drm-intel-fixes-2024-04-04 for you to fetch changes up to 99f855082f228cdcecd6ab768d3b8b505e0eb028: drm/i915/mst: Reject FEC+MST on ICL (2024-04-03 14:26:11 -0400) Display fixes: - A few DisplayPort related fixes (Imre, Arun, Ankit, Ville) - eDP PSR fixes (Jouni) Core/GT fixes: - Remove some VM space restrictions on older platforms (Andi) - Disable automatic load CCS load balancing (Andi) Andi Shyti (4): drm/i915/gt: Limit the reserved VM space to only the platforms that need it drm/i915/gt: Disable HW load balancing for CCS drm/i915/gt: Do not generate the command streamer for all the CCS drm/i915/gt: Enable only one CCS for compute workload Ankit Nautiyal (1): drm/i915/dp: Fix the computation for compressed_bpp for DISPLAY < 13 Arun R Murthy (1): drm/i915/dp: Remove support for UHBR13.5 Imre Deak (1): drm/i915/dp: Fix DSC state HW readout for SST connectors Jouni Högander (3): drm/i915/psr: Calculate PIPE_SRCSZ_ERLY_TPT value drm/i915/psr: Move writing early transport pipe src drm/i915/psr: Fix intel_psr2_sel_fetch_et_alignment usage Ville Syrjälä (2): drm/i915/mst: Limit MST+DSC to TGL+ drm/i915/mst: Reject FEC+MST on ICL drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/display/intel_display.c | 9 --- .../gpu/drm/i915/display/intel_display_device.h| 1 + drivers/gpu/drm/i915/display/intel_display_types.h | 2 + drivers/gpu/drm/i915/display/intel_dp.c| 11 +-- drivers/gpu/drm/i915/display/intel_dp_mst.c| 2 +- drivers/gpu/drm/i915/display/intel_psr.c | 78 -- drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 3 + drivers/gpu/drm/i915/gt/intel_engine_cs.c | 17 + drivers/gpu/drm/i915/gt/intel_gt.c | 6 ++ drivers/gpu/drm/i915/gt/intel_gt.h | 9 +-- drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.c| 39 +++ drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.h| 13 drivers/gpu/drm/i915/gt/intel_gt_regs.h| 6 ++ drivers/gpu/drm/i915/gt/intel_workarounds.c| 30 - 15 files changed, 185 insertions(+), 42 deletions(-) create mode 100644 drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.c create mode 100644 drivers/gpu/drm/i915/gt/intel_gt_ccs_mode.h
[linux-next:master] BUILD REGRESSION 2b3d5988ae2cb5cd945ddbc653f0a71706231fdd
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 2b3d5988ae2cb5cd945ddbc653f0a71706231fdd Add linux-next specific
files for 20240404
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202404041707.4bl4ifti-...@intel.com
https://lore.kernel.org/oe-kbuild-all/202404041832.tmsatkyb-...@intel.com
https://lore.kernel.org/oe-kbuild-all/202404042206.mjaqc32x-...@intel.com
https://lore.kernel.org/oe-kbuild-all/202404042327.jrpt81kp-...@intel.com
Error/Warning: (recently discovered and may have been fixed)
ERROR: modpost: "__aeabi_d2ulz" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko]
undefined!
ERROR: modpost: "__aeabi_l2d" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
drivers/input/serio/parkbd.c:168:10: error: '__section__' attribute only
applies to functions, global variables, Objective-C methods, and Objective-C
properties
drivers/input/serio/parkbd.c:168:10: error: 'section' attribute only applies to
functions, global variables, Objective-C methods, and Objective-C properties
drivers/input/serio/parkbd.c:168:10: error: non-extern declaration of
'__pcpu_unique__alloc_tag_cntr' follows extern declaration
drivers/input/serio/ps2-gpio.c:408:10: error: '__section__' attribute only
applies to functions, global variables, Objective-C methods, and Objective-C
properties
drivers/input/serio/ps2-gpio.c:408:10: error: 'section' attribute only applies
to functions, global variables, Objective-C methods, and Objective-C properties
drivers/input/serio/ps2-gpio.c:408:10: error: non-extern declaration of
'__pcpu_unique__alloc_tag_cntr' follows extern declaration
drivers/input/serio/ps2mult.c:130:10: error: '__section__' attribute only
applies to functions, global variables, Objective-C methods, and Objective-C
properties
drivers/input/serio/ps2mult.c:130:10: error: 'section' attribute only applies
to functions, global variables, Objective-C methods, and Objective-C properties
drivers/input/serio/ps2mult.c:130:10: error: non-extern declaration of
'__pcpu_unique__alloc_tag_cntr' follows extern declaration
drivers/input/serio/serio_raw.c:95:11: error: '__section__' attribute only
applies to functions, global variables, Objective-C methods, and Objective-C
properties
drivers/input/serio/serio_raw.c:95:11: error: 'section' attribute only applies
to functions, global variables, Objective-C methods, and Objective-C properties
drivers/input/serio/serio_raw.c:95:11: error: non-extern declaration of
'__pcpu_unique__alloc_tag_cntr' follows extern declaration
include/linux/mempool.h:105:9: error: '__section__' attribute only applies to
functions, global variables, Objective-C methods, and Objective-C properties
include/linux/mempool.h:105:9: error: 'section' attribute only applies to
functions, global variables, Objective-C methods, and Objective-C properties
include/linux/mempool.h:105:9: error: non-extern declaration of
'__pcpu_unique__alloc_tag_cntr' follows extern declaration
include/linux/mempool.h:105:9: error: non-extern declaration of
'_alloc_tag_cntr' follows extern declaration
include/linux/mempool.h:105:9: error: weak declaration cannot have internal
linkage
ld.lld: error: undefined symbol: i2c_root_adapter
powerpc64-linux-ld: warning: orphan section `.bss..Lubsan_data249' from
`kernel/ptrace.o' being placed in section `.bss..Lubsan_data249'
Unverified Error/Warning (likely false positive, please contact us if
interested):
include/linux/mm_types.h:1175:17: error: '__section__' attribute only applies
to functions, global variables, Objective-C methods, and Objective-C properties
include/linux/mm_types.h:1175:17: error: 'section' attribute only applies to
functions, global variables, Objective-C methods, and Objective-C properties
include/linux/mm_types.h:1175:17: error: non-extern declaration of
'__pcpu_unique__alloc_tag_cntr' follows extern declaration
include/linux/mm_types.h:1175:17: error: non-extern declaration of
'_alloc_tag_cntr' follows extern declaration
include/linux/mm_types.h:1175:17: error: weak declaration cannot have internal
linkage
{standard input}:722: Warning: overflow in branch to .L153; converted into
longer instruction sequence
{standard input}:733: Warning: overflow in branch to .L155; converted into
longer instruction sequence
Error/Warning ids grouped by kconfigs:
gcc_recent_errors
|-- alpha-allnoconfig
| |--
mm-mempool.c:warning:Function-parameter-or-struct-member-gfp_mask-not-described-in-mempool_create_node
| `--
mm-mempool.c:warning:Function-parameter-or-struct-member-node_id-not-described-in-mempool_create_node
|-- alpha-allyesconfig
| |--
drivers-gpu-drm-imx-ipuv3-imx-ldb.c:error:_sel-directive-output-may-be-truncated-writing-bytes-into-a-region-of-size-between-and
| |--
drivers-gpu-drm-nouveau-nouveau_backlight.c:error:d-directive-output-may-be-truncated-writing-between-and-bytes-into-a-region-of-size
| |--
mm-mempool.c:warning:Function-parameter-or-st
Re: [PATCH v12 2/7] clk: meson: add vclk driver
On 04/04/2024 10:13, Jerome Brunet wrote:
On Wed 03 Apr 2024 at 09:46, Neil Armstrong wrote:
The VCLK and VCLK_DIV clocks have supplementary bits.
The VCLK gate has a "SOFT RESET" bit to toggle after the whole
VCLK sub-tree rate has been set, this is implemented in
the gate enable callback.
The VCLK_DIV clocks as enable and reset bits used to disable
and reset the divider, associated with CLK_SET_RATE_GATE it ensures
the rate is set while the divider is disabled and in reset mode.
The VCLK_DIV enable bit isn't implemented as a gate since it's part
of the divider logic and vendor does this exact sequence to ensure
the divider is correctly set.
The checkpatch warning is still there. Is it a choice or a mistake ?
Documentation says "GPL v2" exists for historic reason which seems to
hint "GPL" is preferred, and I suppose this is why checkpatch warns for
it.
Well I didn't see this warning, this is what I fixed:
$ scripts/checkpatch.pl --strict drivers/clk/meson/vclk.c
CHECK: Alignment should match open parenthesis
#63: FILE: drivers/clk/meson/vclk.c:63:
+static unsigned long meson_vclk_div_recalc_rate(struct clk_hw *hw,
+unsigned long prate)
CHECK: Alignment should match open parenthesis
#73: FILE: drivers/clk/meson/vclk.c:73:
+static int meson_vclk_div_determine_rate(struct clk_hw *hw,
+ struct clk_rate_request *req)
CHECK: Alignment should match open parenthesis
#83: FILE: drivers/clk/meson/vclk.c:83:
+static int meson_vclk_div_set_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long parent_rate)
It seems that checking a commit triggers an extra check
$ scripts/checkpatch.pl --strict -G 1bac9f6aa3c3
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#58:
new file mode 100644
WARNING: Prefer "GPL" over "GPL v2" - see commit bf7fbeeae6db ("module: Cure the MODULE_LICENSE
"GPL" vs. "GPL v2" bogosity")
#203: FILE: drivers/clk/meson/vclk.c:141:
+MODULE_LICENSE("GPL v2");
Neil
Signed-off-by: Neil Armstrong
---
drivers/clk/meson/Kconfig | 4 ++
drivers/clk/meson/Makefile | 1 +
drivers/clk/meson/vclk.c | 141 +
drivers/clk/meson/vclk.h | 51
4 files changed, 197 insertions(+)
diff --git a/drivers/clk/meson/Kconfig b/drivers/clk/meson/Kconfig
index 29ffd14d267b..8a9823789fa3 100644
--- a/drivers/clk/meson/Kconfig
+++ b/drivers/clk/meson/Kconfig
@@ -30,6 +30,10 @@ config COMMON_CLK_MESON_VID_PLL_DIV
tristate
select COMMON_CLK_MESON_REGMAP
+config COMMON_CLK_MESON_VCLK
+ tristate
+ select COMMON_CLK_MESON_REGMAP
+
config COMMON_CLK_MESON_CLKC_UTILS
tristate
diff --git a/drivers/clk/meson/Makefile b/drivers/clk/meson/Makefile
index 9ee4b954c896..9ba43fe7a07a 100644
--- a/drivers/clk/meson/Makefile
+++ b/drivers/clk/meson/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_COMMON_CLK_MESON_PLL) += clk-pll.o
obj-$(CONFIG_COMMON_CLK_MESON_REGMAP) += clk-regmap.o
obj-$(CONFIG_COMMON_CLK_MESON_SCLK_DIV) += sclk-div.o
obj-$(CONFIG_COMMON_CLK_MESON_VID_PLL_DIV) += vid-pll-div.o
+obj-$(CONFIG_COMMON_CLK_MESON_VCLK) += vclk.o
# Amlogic Clock controllers
diff --git a/drivers/clk/meson/vclk.c b/drivers/clk/meson/vclk.c
new file mode 100644
index ..45dc216941ea
--- /dev/null
+++ b/drivers/clk/meson/vclk.c
@@ -0,0 +1,141 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2024 Neil Armstrong
+ */
+
+#include
+#include "vclk.h"
+
+/* The VCLK gate has a supplementary reset bit to pulse after ungating */
+
+static inline struct meson_vclk_gate_data *
+clk_get_meson_vclk_gate_data(struct clk_regmap *clk)
+{
+ return (struct meson_vclk_gate_data *)clk->data;
+}
+
+static int meson_vclk_gate_enable(struct clk_hw *hw)
+{
+ struct clk_regmap *clk = to_clk_regmap(hw);
+ struct meson_vclk_gate_data *vclk = clk_get_meson_vclk_gate_data(clk);
+
+ meson_parm_write(clk->map, >enable, 1);
+
+ /* Do a reset pulse */
+ meson_parm_write(clk->map, >reset, 1);
+ meson_parm_write(clk->map, >reset, 0);
+
+ return 0;
+}
+
+static void meson_vclk_gate_disable(struct clk_hw *hw)
+{
+ struct clk_regmap *clk = to_clk_regmap(hw);
+ struct meson_vclk_gate_data *vclk = clk_get_meson_vclk_gate_data(clk);
+
+ meson_parm_write(clk->map, >enable, 0);
+}
+
+static int meson_vclk_gate_is_enabled(struct clk_hw *hw)
+{
+ struct clk_regmap *clk = to_clk_regmap(hw);
+ struct meson_vclk_gate_data *vclk = clk_get_meson_vclk_gate_data(clk);
+
+ return meson_parm_read(clk->map, >enable);
+}
+
+const struct clk_ops meson_vclk_gate_ops = {
+ .enable = meson_vclk_gate_enable,
+ .disable = meson_vclk_gate_disable,
+ .is_enabled = meson_vclk_gate_is_enabled,
+};
+EXPORT_SYMBOL_GPL(meson_vclk_gate_ops);
+
+/* The VCLK Divider has
Re: [RESEND v7 06/37] sh: kernel/setup Update DT support.
On Thu, Apr 4, 2024 at 12:15 AM Yoshinori Sato wrote: > > Fix extrnal fdt initialize and bootargs. What is the problem you are trying to solve? And a typo. > > Signed-off-by: Yoshinori Sato > --- > arch/sh/Kconfig | 23 +++ > arch/sh/include/asm/setup.h | 1 + > arch/sh/kernel/setup.c | 36 +++- > 3 files changed, 35 insertions(+), 25 deletions(-) > > diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig > index 6711cde0d973..242cf30e704d 100644 > --- a/arch/sh/Kconfig > +++ b/arch/sh/Kconfig > @@ -708,17 +708,22 @@ config ROMIMAGE_MMCIF > first part of the romImage which in turn loads the rest the kernel > image to RAM using the MMCIF hardware block. > > +config CMDLINE > + string "Kernel command line arguments string" > + default "console=ttySC1,115200" > + > choice > prompt "Kernel command line" > - optional > - default CMDLINE_OVERWRITE > - depends on !OF || USE_BUILTIN_DTB > + default CMDLINE_BOOTLOADER > + > +config CMDLINE_BOOTLOADER > + bool "Use bootloader kernel arguments" This should be the preferred, normal, default way. So why is it a user visible option? > help > - Setting this option allows the kernel command line arguments > - to be set. > + Uses the command-line options passed by the boot loader. > + If boot loader dosen't provide kernel argments, Use built-in > argments. typos bootloader in some spots, "boot loader" in others. Go with the former. > > config CMDLINE_OVERWRITE > - bool "Overwrite bootloader kernel arguments" > + bool "Overwrite built-in kernel arguments" The original made more sense to me. The default should be to use bootloader args. Any built-in kernel command line should be prepend, append (extend), or overwrite/replace. Rob
Re: [PATCH] drivers: video: logo: Don't mention the full path of the input in output
Am Donnerstag, dem 04.04.2024 um 15:15 +0200 schrieb Helge Deller:
> On 4/4/24 14:18, Lucas Stach wrote:
> > This change strips $abs_srctree of the input file containing the
> > PNM data in the generated output. The motivation for this change
> > is Yocto emitting a build warning
> >
> > WARNING: linux-foo-6.8-r0 do_package_qa: QA Issue:
> > File
> > /usr/src/debug/linux-foo/6.8-r0/drivers/video/logo/logo_linux_clut224.c
> > in package linux-foo-src contains reference to TMPDIR
> >
> > So this change brings us one step closer to make the build result
> > reproducible independent of the build path.
> >
> > Signed-off-by: Lucas Stach
> > ---
> > drivers/video/logo/pnmtologo.c | 14 +-
> > 1 file changed, 13 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/video/logo/pnmtologo.c b/drivers/video/logo/pnmtologo.c
> > index 2434a25afb64..59ccd721e8af 100644
> > --- a/drivers/video/logo/pnmtologo.c
> > +++ b/drivers/video/logo/pnmtologo.c
> > @@ -223,6 +223,18 @@ static inline int is_equal(struct color c1, struct
> > color c2)
> >
> > static void write_header(void)
> > {
> > + const char *abs_srctree = getenv("abs_srctree");
> > + const char *rel_filename;
> > +
> > + if (abs_srctree &&
> > + !strncmp(abs_srctree, filename, strlen(abs_srctree))) {
> > + rel_filename = filename + strlen(abs_srctree);
> > + while (*rel_filename == '/')
> > + ++rel_filename;
> > + } else {
> > + rel_filename = filename;
> > + }
> > +
> > /* open logo file */
> > if (outputname) {
> > out = fopen(outputname, "w");
> > @@ -235,7 +247,7 @@ static void write_header(void)
> > fputs("/*\n", out);
> > fputs(" * DO NOT EDIT THIS FILE!\n", out);
> > fputs(" *\n", out);
> > - fprintf(out, " * It was automatically generated from %s\n", filename);
> > + fprintf(out, " * It was automatically generated from %s\n",
> > rel_filename);
>
> can't you use instead: ?
> > + fprintf(out, " * It was automatically generated from %s\n",
> > basename(filename));
>
The difference to basename is that this keeps the path in the source
tree intact, e.g. it shortens the absolute path to
"drivers/video/logo/logo_linux_clut224.c", so the comment in the
generated file still has a full reference to the file location in the
source tree. It only strips out the part of the path that is host
dependent.
Regards,
Lucas
> Helge
>
>
> > fputs(" *\n", out);
> > fprintf(out, " * Linux logo %s\n", logoname);
> > fputs(" */\n\n", out);
>
Re: [PATCH] staging: fbtft: core: fix potential memory leak in fbtft_probe_common()
On Wed, Sep 28, 2022 at 02:23:01PM +0800, Jianglei Nie wrote:
> fbtft_probe_common() allocates a memory chunk for "info" with
> fbtft_framebuffer_alloc(). When "display->buswidth == 0" is true, the
> function returns without releasing the "info", which will lead to a
> memory leak.
>
> Fix it by calling fbtft_framebuffer_release() when "display->buswidth
> == 0" is true.
Fixes tag?
...
> if (display->buswidth == 0) {
> dev_err(dev, "buswidth is not set\n");
> + fbtft_framebuffer_release(info);
> return -EINVAL;
ret = dev_err_probe(dev, -EINVAL, "buswidth is not set\n");
goto out_release;
> }
--
With Best Regards,
Andy Shevchenko
[PATCH] [v2] nouveau: fix function cast warning
From: Arnd Bergmann
Calling a function through an incompatible pointer type causes breaks
kcfi, so clang warns about the assignment:
drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowof.c:73:10: error: cast from
'void (*)(const void *)' to 'void (*)(void *)' converts to incompatible
function type [-Werror,-Wcast-function-type-strict]
73 | .fini = (void(*)(void *))kfree,
Avoid this with a trivial wrapper.
Fixes: c39f472e9f14 ("drm/nouveau: remove symlinks, move core/ to nvkm/ (no
code changes)")
Signed-off-by: Arnd Bergmann
---
v2: avoid 'return kfree()' expression returning a void
---
drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowof.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowof.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowof.c
index 4bf486b57101..cb05f7f48a98 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowof.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowof.c
@@ -66,11 +66,16 @@ of_init(struct nvkm_bios *bios, const char *name)
return ERR_PTR(-EINVAL);
}
+static void of_fini(void *p)
+{
+ kfree(p);
+}
+
const struct nvbios_source
nvbios_of = {
.name = "OpenFirmware",
.init = of_init,
- .fini = (void(*)(void *))kfree,
+ .fini = of_fini,
.read = of_read,
.size = of_size,
.rw = false,
--
2.39.2
Re: [PATCH v19 17/30] drm/panfrost: Fix the error path in panfrost_mmu_map_fault_addr()
On 1/5/24 21:46, Dmitry Osipenko wrote:
> From: Boris Brezillon
>
> If some the pages or sgt allocation failed, we shouldn't release the
> pages ref we got earlier, otherwise we will end up with unbalanced
> get/put_pages() calls. We should instead leave everything in place
> and let the BO release function deal with extra cleanup when the object
> is destroyed, or let the fault handler try again next time it's called.
>
> Fixes: 187d2929206e ("drm/panfrost: Add support for GPU heap allocations")
> Cc:
> Signed-off-by: Boris Brezillon
> Co-developed-by: Dmitry Osipenko
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/gpu/drm/panfrost/panfrost_mmu.c | 13 +
> 1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.c
> b/drivers/gpu/drm/panfrost/panfrost_mmu.c
> index bd5a0073009d..4a0b4bf03f1a 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_mmu.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_mmu.c
> @@ -502,11 +502,18 @@ static int panfrost_mmu_map_fault_addr(struct
> panfrost_device *pfdev, int as,
> mapping_set_unevictable(mapping);
>
> for (i = page_offset; i < page_offset + NUM_FAULT_PAGES; i++) {
> + /* Can happen if the last fault only partially filled this
> + * section of the pages array before failing. In that case
> + * we skip already filled pages.
> + */
> + if (pages[i])
> + continue;
> +
> pages[i] = shmem_read_mapping_page(mapping, i);
> if (IS_ERR(pages[i])) {
> ret = PTR_ERR(pages[i]);
> pages[i] = NULL;
> - goto err_pages;
> + goto err_unlock;
> }
> }
>
> @@ -514,7 +521,7 @@ static int panfrost_mmu_map_fault_addr(struct
> panfrost_device *pfdev, int as,
> ret = sg_alloc_table_from_pages(sgt, pages + page_offset,
> NUM_FAULT_PAGES, 0, SZ_2M, GFP_KERNEL);
> if (ret)
> - goto err_pages;
> + goto err_unlock;
>
> ret = dma_map_sgtable(pfdev->dev, sgt, DMA_BIDIRECTIONAL, 0);
> if (ret)
> @@ -537,8 +544,6 @@ static int panfrost_mmu_map_fault_addr(struct
> panfrost_device *pfdev, int as,
>
> err_map:
> sg_free_table(sgt);
> -err_pages:
> - drm_gem_shmem_put_pages_locked(>base);
> err_unlock:
> dma_resv_unlock(obj->resv);
> err_bo:
Applied to misc-fixes
Forgot that this patch doesn't depend on others in this series, sorry
for not doing it earlier
--
Best regards,
Dmitry
Re: [PATCH 0/6] drm: enable W=1 warnings by default across the subsystem
On 10/01/2024 17:39, Jani Nikula wrote:
> This is v2 of [1] to enable most W=1 warnings across the drm
> subsystem. Some fixes first, and a CONFIG_DRM_WERROR on top.
>
> I build tested this for x86 (both gcc and clang), arm and arm64.
>
> BR,
> Jani.
>
>
> [1] https://lore.kernel.org/r/20231129181219.1237887-1-jani.nik...@intel.com
>
>
>
>
> Jani Nikula (6):
> drm/nouveau/acr/ga102: remove unused but set variable
> drm/nouveau/svm: remove unused but set variables
> drm/amdgpu: prefer snprintf over sprintf
> drm/imx: prefer snprintf over sprintf
> drm: enable (most) W=1 warnings by default across the subsystem
> drm: Add CONFIG_DRM_WERROR
>
> drivers/gpu/drm/Kconfig | 18 +++
> drivers/gpu/drm/Makefile | 30 +++
> drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c | 3 +-
> drivers/gpu/drm/imx/ipuv3/imx-ldb.c | 2 +-
> drivers/gpu/drm/nouveau/nouveau_svm.c | 10 ++-
> .../gpu/drm/nouveau/nvkm/subdev/acr/lsfw.c| 3 +-
> 6 files changed, 55 insertions(+), 11 deletions(-)
>
Hi Jani,
Observed warning "include/drm/drm_print.h:536:35: warning: '%4.4s'
directive argument is null [-Wformat-overflow=]" when building the
modules with "defconfig+kselftest-ftrace"(
https://github.com/torvalds/linux/blob/master/tools/testing/selftests/ftrace/config
) against next-master(next-20240404) kernel with Arm64 in our CI.
A bisect identified a61ddb4393ad1be61d2ffd92576d42707b05be17 as the
first bad commit. Bisected it on the tag "next-20240326" at repo
"https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git;.
I understand that you are turning on the warning here, thought worth
mentioning about the observation.
Build log:
---
In file included from ../include/drm/drm_mm.h:51,
from ../include/drm/drm_vma_manager.h:26,
from ../include/drm/drm_gem.h:42,
from ../drivers/gpu/drm/msm/msm_drv.h:34,
from ../drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c:20:
In function '_dpu_plane_set_qos_lut',
inlined from 'dpu_plane_sspp_update_pipe' at
../drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c:1078:2:
../include/drm/drm_print.h:536:35: warning: '%4.4s' directive argument
is null [-Wformat-overflow=]
536 | #define __drm_dbg(cat, fmt, ...) ___drm_dbg(NULL, cat, fmt,
##__VA_ARGS__)
|
^
../include/drm/drm_print.h:594:2: note: in expansion of macro '__drm_dbg'
594 | __drm_dbg(DRM_UT_ATOMIC, fmt, ##__VA_ARGS__)
| ^
../drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c:30:39: note: in expansion
of macro 'DRM_DEBUG_ATOMIC'
30 | #define DPU_DEBUG_PLANE(pl, fmt, ...) DRM_DEBUG_ATOMIC("plane%d
" fmt,\
| ^~~~
../drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c:290:2: note: in expansion
of macro 'DPU_DEBUG_PLANE'
290 | DPU_DEBUG_PLANE(pdpu, "pnum:%d fmt: %4.4s rt:%d fl:%u
lut:0x%llx\n",
| ^~~
CC [M] drivers/net/can/spi/mcp251xfd/mcp251xfd-ethtool.o
Bisect log:
git bisect start
# good: [4cece764965020c22cff7665b18a012006359095] Linux 6.9-rc1
git bisect good 4cece764965020c22cff7665b18a012006359095
# bad: [084c8e315db34b59d38d06e684b1a0dd07d30287] Add linux-next
specific files for 20240326
git bisect bad 084c8e315db34b59d38d06e684b1a0dd07d30287
# good: [1cc931629f2b3de04b7608b8d26692c6f6a52aeb] Merge branch
'nand/next' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git
git bisect good 1cc931629f2b3de04b7608b8d26692c6f6a52aeb
# bad: [4f5a3415aaf8fdf945e4cb67b847254ddda2f583] Merge branch
'drm-xe-next' of https://gitlab.freedesktop.org/drm/xe/kernel
git bisect bad 4f5a3415aaf8fdf945e4cb67b847254ddda2f583
# bad: [a13305486485d0657fbf09cee72fca9553d7d6cd] Merge branch
'drm-next' of https://gitlab.freedesktop.org/agd5f/linux
git bisect bad a13305486485d0657fbf09cee72fca9553d7d6cd
# good: [417f78a2a1c8c2d517db8b2e04785c1c94a563b4] drm/amdkfd: Cleanup
workqueue during module unload
git bisect good 417f78a2a1c8c2d517db8b2e04785c1c94a563b4
# bad: [57a4e3a94caee6cfda41700da877bee77eab939c] Revert "drm/panthor:
Fix undefined panthor_device_suspend/resume symbol issue"
git bisect bad 57a4e3a94caee6cfda41700da877bee77eab939c
# bad: [2cddf770be0cebb663af3d72c049b9e24928f335] drm/kunit: fix
drm_kunit_helpers.h kernel-doc
git bisect bad 2cddf770be0cebb663af3d72c049b9e24928f335
# good: [d72f049087d4f973f6332b599c92177e718107de] drm/panthor: Allow
driver compilation
git bisect good d72f049087d4f973f6332b599c92177e718107de
# good: [e18aeeda0b6905c333df5a0566b99f5c84426098] drm/bridge: Fix
improper bridge init order with pre_enable_prev_first
git bisect good e18aeeda0b6905c333df5a0566b99f5c84426098
# bad: [f89632a9e5fa6c4787c14458cd42a9ef42025434] drm: Add
[PATCH 0/7] drm/udl: Convert to struct drm_edid
Convert udl to use struct drm_edid and its helpers. Also clean up
a few things in the process.
Patches 1 and 2 add a custom EDID probe function similar to the
existing drm_probe_ddc(). The seconds patch is necessary to make
it useful for udl.
Patch 3 fixes a bug.
Patches 4 to 6 convert the current EDID handling to struct drm_edid
and its helpers. Patch 6 also separates the helpers for .get_modes()
and .detect_ctx() from each other.
Patch 7 removes the obsolete struct udl_connector.
Thomas Zimmermann (7):
drm/edid: Implement drm_probe_ddc() with drm_edid_probe_custom()
drm/edid: Test for EDID header in drm_edit_probe_custom()
drm/udl: Remove DRM_CONNECTOR_POLL_HPD
drm/udl: Move drm_dev_{enter,exit}() into udl_get_edid_block()
drm/udl: Clean up Makefile
drm/udl: Untangle .get_modes() and .detect_ctx()
drm/udl: Remove struct udl_connector
drivers/gpu/drm/drm_edid.c| 62 +++---
drivers/gpu/drm/udl/Makefile | 8 +-
drivers/gpu/drm/udl/udl_drv.h | 12 +--
drivers/gpu/drm/udl/udl_edid.c| 67 +++
drivers/gpu/drm/udl/udl_edid.h| 15
drivers/gpu/drm/udl/udl_modeset.c | 136 ++
include/drm/drm_edid.h| 3 +
7 files changed, 173 insertions(+), 130 deletions(-)
create mode 100644 drivers/gpu/drm/udl/udl_edid.c
create mode 100644 drivers/gpu/drm/udl/udl_edid.h
--
2.44.0
[PATCH 4/7] drm/udl: Move drm_dev_{enter, exit}() into udl_get_edid_block()
Protect the code in udl_get_edid_block() with drm_dev_enter() and
drm_dev_exit(), so that all callers automatically invoke it. The
function uses hardware resources, which can be hot-unplugged at
any time. The other code in udl_connector_detect() does not use the
resources of the hardware device and therefore does not require
protection.
This change will allow to use udl_get_edid_block() in various
contexts easily.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/udl/udl_modeset.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/udl/udl_modeset.c
b/drivers/gpu/drm/udl/udl_modeset.c
index 751da3a294c44..3df9fc38388b4 100644
--- a/drivers/gpu/drm/udl/udl_modeset.c
+++ b/drivers/gpu/drm/udl/udl_modeset.c
@@ -434,13 +434,18 @@ static int udl_get_edid_block(void *data, u8 *buf,
unsigned int block, size_t le
struct drm_device *dev = >drm;
struct usb_device *udev = udl_to_usb_device(udl);
u8 *read_buff;
- int ret;
+ int idx, ret;
size_t i;
read_buff = kmalloc(2, GFP_KERNEL);
if (!read_buff)
return -ENOMEM;
+ if (!drm_dev_enter(dev, )) {
+ ret = -ENODEV;
+ goto err_kfree;
+ }
+
for (i = 0; i < len; i++) {
int bval = (i + block * EDID_LENGTH) << 8;
@@ -449,20 +454,23 @@ static int udl_get_edid_block(void *data, u8 *buf,
unsigned int block, size_t le
0xA1, read_buff, 2, USB_CTRL_GET_TIMEOUT);
if (ret < 0) {
drm_err(dev, "Read EDID byte %zu failed err %x\n", i,
ret);
- goto err_kfree;
+ goto err_drm_dev_exit;
} else if (ret < 1) {
ret = -EIO;
drm_err(dev, "Read EDID byte %zu failed\n", i);
- goto err_kfree;
+ goto err_drm_dev_exit;
}
buf[i] = read_buff[1];
}
+ drm_dev_exit(idx);
kfree(read_buff);
return 0;
+err_drm_dev_exit:
+ drm_dev_exit(idx);
err_kfree:
kfree(read_buff);
return ret;
@@ -474,21 +482,15 @@ static enum drm_connector_status
udl_connector_detect(struct drm_connector *conn
struct udl_device *udl = to_udl(dev);
struct udl_connector *udl_connector = to_udl_connector(connector);
enum drm_connector_status status = connector_status_disconnected;
- int idx;
/* cleanup previous EDID */
kfree(udl_connector->edid);
udl_connector->edid = NULL;
- if (!drm_dev_enter(dev, ))
- return connector_status_disconnected;
-
udl_connector->edid = drm_do_get_edid(connector, udl_get_edid_block,
udl);
if (udl_connector->edid)
status = connector_status_connected;
- drm_dev_exit(idx);
-
return status;
}
--
2.44.0
[PATCH 7/7] drm/udl: Remove struct udl_connector
Udl's struct udl_connector is an empty wrapper around struct
drm_connector. Remove it. Allocate the connector as part of struct
udl_device and inline the init function into its only caller.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/udl/udl_drv.h | 10 +--
drivers/gpu/drm/udl/udl_modeset.c | 47 ++-
2 files changed, 10 insertions(+), 47 deletions(-)
diff --git a/drivers/gpu/drm/udl/udl_drv.h b/drivers/gpu/drm/udl/udl_drv.h
index f112cfb270f31..1eb716d9dad57 100644
--- a/drivers/gpu/drm/udl/udl_drv.h
+++ b/drivers/gpu/drm/udl/udl_drv.h
@@ -49,15 +49,6 @@ struct urb_list {
size_t size;
};
-struct udl_connector {
- struct drm_connector connector;
-};
-
-static inline struct udl_connector *to_udl_connector(struct drm_connector
*connector)
-{
- return container_of(connector, struct udl_connector, connector);
-}
-
struct udl_device {
struct drm_device drm;
struct device *dev;
@@ -66,6 +57,7 @@ struct udl_device {
struct drm_plane primary_plane;
struct drm_crtc crtc;
struct drm_encoder encoder;
+ struct drm_connector connector;
struct mutex gem_lock;
diff --git a/drivers/gpu/drm/udl/udl_modeset.c
b/drivers/gpu/drm/udl/udl_modeset.c
index 4236ce57f5945..ce82382b7a423 100644
--- a/drivers/gpu/drm/udl/udl_modeset.c
+++ b/drivers/gpu/drm/udl/udl_modeset.c
@@ -444,49 +444,14 @@ static const struct drm_connector_helper_funcs
udl_connector_helper_funcs = {
.detect_ctx = udl_connector_helper_detect_ctx,
};
-static void udl_connector_destroy(struct drm_connector *connector)
-{
- struct udl_connector *udl_connector = to_udl_connector(connector);
-
- drm_connector_cleanup(connector);
- kfree(udl_connector);
-}
-
static const struct drm_connector_funcs udl_connector_funcs = {
.reset = drm_atomic_helper_connector_reset,
.fill_modes = drm_helper_probe_single_connector_modes,
- .destroy = udl_connector_destroy,
+ .destroy = drm_connector_cleanup,
.atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
};
-struct drm_connector *udl_connector_init(struct drm_device *dev)
-{
- struct udl_connector *udl_connector;
- struct drm_connector *connector;
- int ret;
-
- udl_connector = kzalloc(sizeof(*udl_connector), GFP_KERNEL);
- if (!udl_connector)
- return ERR_PTR(-ENOMEM);
-
- connector = _connector->connector;
- ret = drm_connector_init(dev, connector, _connector_funcs,
DRM_MODE_CONNECTOR_VGA);
- if (ret)
- goto err_kfree;
-
- drm_connector_helper_add(connector, _connector_helper_funcs);
-
- connector->polled = DRM_CONNECTOR_POLL_CONNECT |
- DRM_CONNECTOR_POLL_DISCONNECT;
-
- return connector;
-
-err_kfree:
- kfree(udl_connector);
- return ERR_PTR(ret);
-}
-
/*
* Modesetting
*/
@@ -556,9 +521,15 @@ int udl_modeset_init(struct drm_device *dev)
return ret;
encoder->possible_crtcs = drm_crtc_mask(crtc);
- connector = udl_connector_init(dev);
- if (IS_ERR(connector))
+ connector = >connector;
+ ret = drm_connector_init(dev, connector, _connector_funcs,
DRM_MODE_CONNECTOR_VGA);
+ if (ret)
return PTR_ERR(connector);
+ drm_connector_helper_add(connector, _connector_helper_funcs);
+
+ connector->polled = DRM_CONNECTOR_POLL_CONNECT |
+ DRM_CONNECTOR_POLL_DISCONNECT;
+
ret = drm_connector_attach_encoder(connector, encoder);
if (ret)
return ret;
--
2.44.0
[PATCH 3/7] drm/udl: Remove DRM_CONNECTOR_POLL_HPD
DisplayLink devices do not generate hotplug events. Remove the poll
flag DRM_CONNECTOR_POLL_HPD, as it may not be specified together with
DRM_CONNECTOR_POLL_CONNECT or DRM_CONNECTOR_POLL_DISCONNECT.
Signed-off-by: Thomas Zimmermann
Fixes: afdfc4c6f55f ("drm/udl: Fixed problem with UDL adpater reconnection")
Cc: Robert Tarasov
Cc: Alex Deucher
Cc: Dave Airlie
Cc: Sean Paul
Cc: Thomas Zimmermann
Cc: dri-devel@lists.freedesktop.org
Cc: # v4.15+
---
drivers/gpu/drm/udl/udl_modeset.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/udl/udl_modeset.c
b/drivers/gpu/drm/udl/udl_modeset.c
index 7702359c90c22..751da3a294c44 100644
--- a/drivers/gpu/drm/udl/udl_modeset.c
+++ b/drivers/gpu/drm/udl/udl_modeset.c
@@ -527,8 +527,7 @@ struct drm_connector *udl_connector_init(struct drm_device
*dev)
drm_connector_helper_add(connector, _connector_helper_funcs);
- connector->polled = DRM_CONNECTOR_POLL_HPD |
- DRM_CONNECTOR_POLL_CONNECT |
+ connector->polled = DRM_CONNECTOR_POLL_CONNECT |
DRM_CONNECTOR_POLL_DISCONNECT;
return connector;
--
2.44.0
[PATCH 6/7] drm/udl: Untangle .get_modes() and .detect_ctx()
Provide separate implementations of .get_modes() and .detect_ctx()
from struct drm_connector. Switch to struct drm_edid.
Udl's .detect() helper used to fetch the EDID from the adapter and the
.get_modes() helper provided display modes from the data. Switching to
the new helpers around struct drm_edid separates both from each other. The
.get_modes() helper now fetches the EDID by itself and the .detect_ctx()
helper only tests for its presence.
The patch does a number of things to implement this.
- Move udl_get_edid_block() to udl_edid.c and rename it to
udl_read_edid_block(). Then use the helper to implement probing in
udl_probe_edid() and reading in udl_edid_read(). Both udl helpers
are build on top of DRM helpers.
- Replace the existing code in .get_modes() and .detect() with udl's
new EDID helpers. The new code behaves like DRM's similar DDC-based
helpers. Instead of .detect(), udl now implements .detect_ctx().
- Remove the edid data from struct udl_connector. The field cached
the EDID data between calls to .detect() and .get_modes(), but is now
unused.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/udl/Makefile | 1 +
drivers/gpu/drm/udl/udl_drv.h | 2 -
drivers/gpu/drm/udl/udl_edid.c| 67 +++
drivers/gpu/drm/udl/udl_edid.h| 15 ++
drivers/gpu/drm/udl/udl_modeset.c | 90 +++
5 files changed, 102 insertions(+), 73 deletions(-)
create mode 100644 drivers/gpu/drm/udl/udl_edid.c
create mode 100644 drivers/gpu/drm/udl/udl_edid.h
diff --git a/drivers/gpu/drm/udl/Makefile b/drivers/gpu/drm/udl/Makefile
index 00690741db376..43d69a16af183 100644
--- a/drivers/gpu/drm/udl/Makefile
+++ b/drivers/gpu/drm/udl/Makefile
@@ -2,6 +2,7 @@
udl-y := \
udl_drv.o \
+ udl_edid.o \
udl_main.o \
udl_modeset.o \
udl_transfer.o
diff --git a/drivers/gpu/drm/udl/udl_drv.h b/drivers/gpu/drm/udl/udl_drv.h
index 282ebd6c02fda..f112cfb270f31 100644
--- a/drivers/gpu/drm/udl/udl_drv.h
+++ b/drivers/gpu/drm/udl/udl_drv.h
@@ -51,8 +51,6 @@ struct urb_list {
struct udl_connector {
struct drm_connector connector;
- /* last udl_detect edid */
- struct edid *edid;
};
static inline struct udl_connector *to_udl_connector(struct drm_connector
*connector)
diff --git a/drivers/gpu/drm/udl/udl_edid.c b/drivers/gpu/drm/udl/udl_edid.c
new file mode 100644
index 0..caa9641996e92
--- /dev/null
+++ b/drivers/gpu/drm/udl/udl_edid.c
@@ -0,0 +1,67 @@
+// SPDX-License-Identifier: GPL-2.0-only
+
+#include
+#include
+
+#include "udl_drv.h"
+#include "udl_edid.h"
+
+static int udl_read_edid_block(void *data, u8 *buf, unsigned int block, size_t
len)
+{
+ struct udl_device *udl = data;
+ struct drm_device *dev = >drm;
+ struct usb_device *udev = udl_to_usb_device(udl);
+ u8 *read_buff;
+ int idx, ret;
+ size_t i;
+
+ read_buff = kmalloc(2, GFP_KERNEL);
+ if (!read_buff)
+ return -ENOMEM;
+
+ if (!drm_dev_enter(dev, )) {
+ ret = -ENODEV;
+ goto err_kfree;
+ }
+
+ for (i = 0; i < len; i++) {
+ int bval = (i + block * EDID_LENGTH) << 8;
+
+ ret = usb_control_msg(udev, usb_rcvctrlpipe(udev, 0),
+ 0x02, (0x80 | (0x02 << 5)), bval,
+ 0xA1, read_buff, 2, USB_CTRL_GET_TIMEOUT);
+ if (ret < 0) {
+ drm_err(dev, "Read EDID byte %zu failed err %x\n", i,
ret);
+ goto err_drm_dev_exit;
+ } else if (ret < 1) {
+ ret = -EIO;
+ drm_err(dev, "Read EDID byte %zu failed\n", i);
+ goto err_drm_dev_exit;
+ }
+
+ buf[i] = read_buff[1];
+ }
+
+ drm_dev_exit(idx);
+ kfree(read_buff);
+
+ return 0;
+
+err_drm_dev_exit:
+ drm_dev_exit(idx);
+err_kfree:
+ kfree(read_buff);
+ return ret;
+}
+
+bool udl_probe_edid(struct udl_device *udl)
+{
+ return drm_edid_probe_custom(udl_read_edid_block, udl, true);
+}
+
+const struct drm_edid *udl_edid_read(struct drm_connector *connector)
+{
+ struct udl_device *udl = to_udl(connector->dev);
+
+ return drm_edid_read_custom(connector, udl_read_edid_block, udl);
+}
diff --git a/drivers/gpu/drm/udl/udl_edid.h b/drivers/gpu/drm/udl/udl_edid.h
new file mode 100644
index 0..fe15ff3752b7d
--- /dev/null
+++ b/drivers/gpu/drm/udl/udl_edid.h
@@ -0,0 +1,15 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#ifndef UDL_EDID_H
+#define UDL_EDID_H
+
+#include
+
+struct drm_connector;
+struct drm_edid;
+struct udl_device;
+
+bool udl_probe_edid(struct udl_device *udl);
+const struct drm_edid *udl_edid_read(struct drm_connector *connector);
+
+#endif
diff --git a/drivers/gpu/drm/udl/udl_modeset.c
b/drivers/gpu/drm/udl/udl_modeset.c
index
[PATCH 5/7] drm/udl: Clean up Makefile
Clean up Makefile before listing new object files. No functional changes. Signed-off-by: Thomas Zimmermann --- drivers/gpu/drm/udl/Makefile | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/udl/Makefile b/drivers/gpu/drm/udl/Makefile index 3f6db179455d1..00690741db376 100644 --- a/drivers/gpu/drm/udl/Makefile +++ b/drivers/gpu/drm/udl/Makefile @@ -1,4 +1,9 @@ # SPDX-License-Identifier: GPL-2.0-only -udl-y := udl_drv.o udl_modeset.o udl_main.o udl_transfer.o + +udl-y := \ + udl_drv.o \ + udl_main.o \ + udl_modeset.o \ + udl_transfer.o obj-$(CONFIG_DRM_UDL) := udl.o -- 2.44.0
[PATCH 2/7] drm/edid: Test for EDID header in drm_edit_probe_custom()
EDID read functions do not validate their return data. So they might
return the required number of bytes of probing, but with invalid
data. Therefore test for the presence of an EDID header similar to
the code in edid_block_check().
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_edid.c | 50 +-
include/drm/drm_edid.h | 2 +-
2 files changed, 39 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index a3e9333f9177a..4e12d4b83a720 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1758,6 +1758,18 @@ static void edid_header_fix(void *edid)
memcpy(edid, edid_header, sizeof(edid_header));
}
+static int edid_header_score(const u8 *header)
+{
+ int i, score = 0;
+
+ for (i = 0; i < sizeof(edid_header); i++) {
+ if (header[i] == edid_header[i])
+ score++;
+ }
+
+ return score;
+}
+
/**
* drm_edid_header_is_valid - sanity check the header of the base EDID block
* @_edid: pointer to raw base EDID block
@@ -1769,14 +1781,8 @@ static void edid_header_fix(void *edid)
int drm_edid_header_is_valid(const void *_edid)
{
const struct edid *edid = _edid;
- int i, score = 0;
- for (i = 0; i < sizeof(edid_header); i++) {
- if (edid->header[i] == edid_header[i])
- score++;
- }
-
- return score;
+ return edid_header_score(edid->header);
}
EXPORT_SYMBOL(drm_edid_header_is_valid);
@@ -2612,17 +2618,37 @@ EXPORT_SYMBOL(drm_edid_free);
* drm_edid_probe_custom() - probe DDC presence
* @read_block: EDID block read function
* @context: Private data passed to the block read function
+ * @validate: True to validate the EDID header
*
* Probes for EDID data. Only reads enough data to detect the presence
- * of the EDID channel.
+ * of the EDID channel. Some EDID block read functions do not fail,
+ * but return invalid data if no EDID data is available. If @validate
+ * has been specified, drm_edid_probe_custom() validates the retrieved
+ * EDID header before signalling success.
*
* Return: True on success, false on failure.
*/
-bool drm_edid_probe_custom(read_block_fn read_block, void *context)
+bool drm_edid_probe_custom(read_block_fn read_block, void *context, bool
validate)
{
- unsigned char out;
+ u8 header[8] = {0, 0, 0, 0, 0, 0, 0, 0};
+ int ret;
+ size_t len = 1;
+
+ if (validate)
+ len = sizeof(header); // read full header
+
+ ret = read_block(context, header, 0, len);
+ if (ret)
+ return false;
+
+ if (validate) {
+ int score = edid_header_score(header);
+
+ if (score < clamp(edid_fixup, 0, 8))
+ return false;
+ }
- return (read_block(context, , 0, 1) == 0);
+ return true;
}
EXPORT_SYMBOL(drm_edid_probe_custom);
@@ -2635,7 +2661,7 @@ EXPORT_SYMBOL(drm_edid_probe_custom);
bool
drm_probe_ddc(struct i2c_adapter *adapter)
{
- return drm_edid_probe_custom(drm_do_probe_ddc_edid, adapter);
+ return drm_edid_probe_custom(drm_do_probe_ddc_edid, adapter, false);
}
EXPORT_SYMBOL(drm_probe_ddc);
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index 4d1797ade5f1d..299278c7ee1c2 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -412,7 +412,7 @@ static inline void drm_edid_decode_panel_id(u32 panel_id,
char vend[4], u16 *pro
bool
drm_edid_probe_custom(int (*read_block)(void *context, u8 *buf, unsigned int
block, size_t len),
- void *context);
+ void *context, bool validate);
bool drm_probe_ddc(struct i2c_adapter *adapter);
struct edid *drm_do_get_edid(struct drm_connector *connector,
int (*get_edid_block)(void *data, u8 *buf, unsigned int block,
--
2.44.0
[PATCH 1/7] drm/edid: Implement drm_probe_ddc() with drm_edid_probe_custom()
Move the logic from drm_probe_ddc() into drm_edid_probe_custom(),
which receives the EDID read function as argument. Allows drivers
without DDC to implement similar functionality without duplicating
the code.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_edid.c | 22 +++---
include/drm/drm_edid.h | 3 +++
2 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index ea77577a37864..a3e9333f9177a 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2608,6 +2608,24 @@ void drm_edid_free(const struct drm_edid *drm_edid)
}
EXPORT_SYMBOL(drm_edid_free);
+/**
+ * drm_edid_probe_custom() - probe DDC presence
+ * @read_block: EDID block read function
+ * @context: Private data passed to the block read function
+ *
+ * Probes for EDID data. Only reads enough data to detect the presence
+ * of the EDID channel.
+ *
+ * Return: True on success, false on failure.
+ */
+bool drm_edid_probe_custom(read_block_fn read_block, void *context)
+{
+ unsigned char out;
+
+ return (read_block(context, , 0, 1) == 0);
+}
+EXPORT_SYMBOL(drm_edid_probe_custom);
+
/**
* drm_probe_ddc() - probe DDC presence
* @adapter: I2C adapter to probe
@@ -2617,9 +2635,7 @@ EXPORT_SYMBOL(drm_edid_free);
bool
drm_probe_ddc(struct i2c_adapter *adapter)
{
- unsigned char out;
-
- return (drm_do_probe_ddc_edid(adapter, , 0, 1) == 0);
+ return drm_edid_probe_custom(drm_do_probe_ddc_edid, adapter);
}
EXPORT_SYMBOL(drm_probe_ddc);
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index 6f65bbf655a1f..4d1797ade5f1d 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -410,6 +410,9 @@ static inline void drm_edid_decode_panel_id(u32 panel_id,
char vend[4], u16 *pro
drm_edid_decode_mfg_id(panel_id >> 16, vend);
}
+bool
+drm_edid_probe_custom(int (*read_block)(void *context, u8 *buf, unsigned int
block, size_t len),
+ void *context);
bool drm_probe_ddc(struct i2c_adapter *adapter);
struct edid *drm_do_get_edid(struct drm_connector *connector,
int (*get_edid_block)(void *data, u8 *buf, unsigned int block,
--
2.44.0
Re: [PATCH v17 0/9] Enable Adaptive Sync SDP Support for DP
On 3/19/2024 3:16 PM, Maxime Ripard wrote: On Mon, Mar 18, 2024 at 04:37:58PM +0200, Jani Nikula wrote: On Mon, 11 Mar 2024, Mitul Golani wrote: An Adaptive-Sync-capable DP protocol converter indicates its support by setting the related bit in the DPCD register. This is valid for DP and edp as well. Computes AS SDP values based on the display configuration, ensuring proper handling of Variable Refresh Rate (VRR) in the context of Adaptive Sync. [snip] Mitul Golani (9): drm/dp: Add support to indicate if sink supports AS SDP drm: Add Adaptive Sync SDP logging Maarten, Maxime, Thomas, ack for merging these two patches via drm-intel-next? Ack Maxime Thanks for the patch, ack and reviews, pushed to drm-intel-next. Regards, Ankit
[PULL] drm-xe-fixes
Hi Dave and Sima, Please pull the drm-xe-fixes for this week targeting v6.9-rc3. This is a little late in the week as I was waiting a critical fix to be applied to get our CI back. This is mainly due to some stress tests creating hundreds of exec queues and that not playing nice with the workqueue changes introduced in v6.9. That shouldn't be the normal use case but was causing CI to abort further tests. Other changes include fixes around rebinding and TLB invalidation. thanks Lucas De Marchi drm-xe-fixes-2024-04-04: - Stop using system_unbound_wq for preempt fences, as this can cause starvation when reaching more than max_active defined by workqueue - Fix saving unordered rebinding fences by attaching them as kernel feces to the vm's resv - Fix TLB invalidation fences completing out of order - Move rebind TLB invalidation to the ring ops to reduce the latency The following changes since commit 39cd87c4eb2b893354f3b850f916353f2658ae6f: Linux 6.9-rc2 (2024-03-31 14:32:39 -0700) are available in the Git repository at: https://gitlab.freedesktop.org/drm/xe/kernel.git tags/drm-xe-fixes-2024-04-04 for you to fetch changes up to 77a011012d7d8b98368a763bf74317c6d5ce00f1: drm/xe: Use ordered wq for preempt fence waiting (2024-04-04 08:32:34 -0500) - Stop using system_unbound_wq for preempt fences, as this can cause starvation when reaching more than max_active defined by workqueue - Fix saving unordered rebinding fences by attaching them as kernel feces to the vm's resv - Fix TLB invalidation fences completing out of order - Move rebind TLB invalidation to the ring ops to reduce the latency Matthew Brost (1): drm/xe: Use ordered wq for preempt fence waiting Thomas Hellström (4): drm/xe: Use ring ops TLB invalidation for rebinds drm/xe: Rework rebinding drm/xe: Make TLB invalidation fences unordered drm/xe: Move vma rebinding to the drm_exec locking loop drivers/gpu/drm/xe/xe_device.c | 11 ++- drivers/gpu/drm/xe/xe_device_types.h| 3 + drivers/gpu/drm/xe/xe_exec.c| 79 ++-- drivers/gpu/drm/xe/xe_exec_queue_types.h| 5 ++ drivers/gpu/drm/xe/xe_gt_pagefault.c| 3 +- drivers/gpu/drm/xe/xe_gt_tlb_invalidation.c | 1 - drivers/gpu/drm/xe/xe_gt_types.h| 7 -- drivers/gpu/drm/xe/xe_preempt_fence.c | 2 +- drivers/gpu/drm/xe/xe_pt.c | 25 +-- drivers/gpu/drm/xe/xe_ring_ops.c| 11 +-- drivers/gpu/drm/xe/xe_sched_job.c | 10 +++ drivers/gpu/drm/xe/xe_sched_job_types.h | 2 + drivers/gpu/drm/xe/xe_vm.c | 110 +--- drivers/gpu/drm/xe/xe_vm.h | 8 +- drivers/gpu/drm/xe/xe_vm_types.h| 8 +- 15 files changed, 140 insertions(+), 145 deletions(-)
Re: [PATCH] drm/panfrost: Show overall GPU usage stats through sysfs knob
On 4/4/24 11:00, Adrián Larumbe wrote:
This changeset is heavily inspired by commit 509433d8146c ("drm/v3d: Expose
the total GPU usage stats on sysfs"). The point is making broader GPU
occupancy numbers available through the sysfs interface, so that for every
job slot, its number of processed jobs and total processing time are
displayed.
Shouldn't we make this sysfs interface a generic DRM interface?
Something that would be standard for all drivers and that we could
integrate into gputop in the future.
Best Regards,
- Maíra
Cc: Boris Brezillon
Cc: Christopher Healy
Signed-off-by: Adrián Larumbe
---
drivers/gpu/drm/panfrost/panfrost_device.h | 5 +++
drivers/gpu/drm/panfrost/panfrost_drv.c| 49 --
drivers/gpu/drm/panfrost/panfrost_job.c| 17 +++-
drivers/gpu/drm/panfrost/panfrost_job.h| 3 ++
4 files changed, 68 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_device.h
b/drivers/gpu/drm/panfrost/panfrost_device.h
index cffcb0ac7c11..1d343351c634 100644
--- a/drivers/gpu/drm/panfrost/panfrost_device.h
+++ b/drivers/gpu/drm/panfrost/panfrost_device.h
@@ -169,6 +169,11 @@ struct panfrost_engine_usage {
unsigned long long cycles[NUM_JOB_SLOTS];
};
+struct panfrost_slot_usage {
+ u64 enabled_ns;
+ u64 jobs_sent;
+};
+
struct panfrost_file_priv {
struct panfrost_device *pfdev;
diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c b/drivers/gpu/drm/panfrost/panfrost_drv.c
index ef9f6c0716d5..6afcde66270f 100644
--- a/drivers/gpu/drm/panfrost/panfrost_drv.c
+++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -524,6 +525,10 @@ static const struct drm_ioctl_desc
panfrost_drm_driver_ioctls[] = {
PANFROST_IOCTL(MADVISE, madvise,DRM_RENDER_ALLOW),
};
+static const char * const engine_names[] = {
+ "fragment", "vertex-tiler", "compute-only"
+};
+
static void panfrost_gpu_show_fdinfo(struct panfrost_device *pfdev,
struct panfrost_file_priv *panfrost_priv,
struct drm_printer *p)
@@ -543,10 +548,6 @@ static void panfrost_gpu_show_fdinfo(struct
panfrost_device *pfdev,
* job spent on the GPU.
*/
- static const char * const engine_names[] = {
- "fragment", "vertex-tiler", "compute-only"
- };
-
BUILD_BUG_ON(ARRAY_SIZE(engine_names) != NUM_JOB_SLOTS);
for (i = 0; i < NUM_JOB_SLOTS - 1; i++) {
@@ -716,8 +717,48 @@ static ssize_t profiling_store(struct device *dev,
static DEVICE_ATTR_RW(profiling);
+static ssize_t
+gpu_stats_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+ struct panfrost_device *pfdev = dev_get_drvdata(dev);
+ struct panfrost_slot_usage stats;
+ u64 timestamp = local_clock();
+ ssize_t len = 0;
+ unsigned int i;
+
+ BUILD_BUG_ON(ARRAY_SIZE(engine_names) != NUM_JOB_SLOTS);
+
+ len += sysfs_emit(buf, "queuetimestampjobs
runtime\n");
+ len += sysfs_emit_at(buf, len,
"-\n");
+
+ for (i = 0; i < NUM_JOB_SLOTS - 1; i++) {
+
+ stats = get_slot_stats(pfdev, i);
+
+ /*
+* Each line will display the slot name, timestamp, the number
+* of jobs handled by that engine and runtime, as shown below:
+*
+* queuetimestampjobsruntime
+* -
+* fragment 12252943467507 638 1184747640
+* vertex-tiler 12252943467507 636 121663838
+*
+*/
+ len += sysfs_emit_at(buf, len, "%-13s%-17llu%-12llu%llu\n",
+engine_names[i],
+timestamp,
+stats.jobs_sent,
+stats.enabled_ns);
+ }
+
+ return len;
+}
+static DEVICE_ATTR_RO(gpu_stats);
+
static struct attribute *panfrost_attrs[] = {
_attr_profiling.attr,
+ _attr_gpu_stats.attr,
NULL,
};
diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c b/drivers/gpu/drm/panfrost/panfrost_job.c
index a61ef0af9a4e..4c779e6f4cb0 100644
--- a/drivers/gpu/drm/panfrost/panfrost_job.c
+++ b/drivers/gpu/drm/panfrost/panfrost_job.c
@@ -31,6 +31,8 @@ struct panfrost_queue_state {
struct drm_gpu_scheduler sched;
u64 fence_context;
u64 emit_seqno;
+
+ struct panfrost_slot_usage stats;
};
struct panfrost_job_slot {
@@ -160,15 +162,20 @@ panfrost_dequeue_job(struct panfrost_device *pfdev, int
slot)
WARN_ON(!job);
if (job->is_profiled) {
+ u64 job_time =
Re: [PATCH] drm: fix DRM_DISPLAY_DP_HELPER dependencies
On Thu, 04 Apr 2024 14:40:51 +0200, Arnd Bergmann wrote: > Both the exynos and rockchip drivers ran into link failures after > a Kconfig cleanup: > > aarch64-linux-ld: drivers/gpu/drm/exynos/exynos_dp.o: in function > `exynos_dp_resume': > exynos_dp.c:(.text+0xc0): undefined reference to `analogix_dp_resume' > aarch64-linux-ld: drivers/gpu/drm/exynos/exynos_dp.o: in function > `exynos_dp_suspend': > exynos_dp.c:(.text+0xf4): undefined reference to `analogix_dp_suspend' > > [...] Applied to misc/kernel.git (drm-misc-next). Thanks! Maxime
Re: [PATCH 0/2] drm/amdgpu/display: Make multi-plane configurations more flexible
On Thu, Apr 04, 2024 at 09:59:03AM -0400, Harry Wentland wrote: > Hi all, > > On 2024-04-04 06:24, Pekka Paalanen wrote: > > On Wed, 3 Apr 2024 17:32:46 -0400 > > Leo Li wrote: > > > >> On 2024-03-28 10:33, Pekka Paalanen wrote: > >>> On Fri, 15 Mar 2024 13:09:56 -0400 > >>> wrote: > >>> > From: Leo Li > > These patches aim to make the amdgpgu KMS driver play nicer with > compositors > when building multi-plane scanout configurations. They do so by: > > 1. Making cursor behavior more sensible. > 2. Allowing placement of DRM OVERLAY planes underneath the PRIMARY plane > for > 'underlay' configurations (perhaps more of a RFC, see below). > > Please see the commit messages for details. > > > For #2, the simplest way to accomplish this was to increase the value of > the > immutable zpos property for the PRIMARY plane. This allowed OVERLAY > planes with > a mutable zpos range of (0-254) to be positioned underneath the PRIMARY > for an > underlay scanout configuration. > > Technically speaking, DCN hardware does not have a concept of primary or > overlay > planes - there are simply 4 general purpose hardware pipes that can be > maped in > any configuration. So the immutable zpos restriction on the PRIMARY > plane is > kind of arbitrary; it can have a mutable range of (0-254) just like the > OVERLAYs. The distinction between PRIMARY and OVERLAY planes is also > somewhat > arbitrary. We can interpret PRIMARY as the first plane that should be > enabled on > a CRTC, but beyond that, it doesn't mean much for amdgpu. > > Therefore, I'm curious about how compositors devs understand KMS planes > and > their zpos properties, and how we would like to use them. It isn't clear > to me > how compositors wish to interpret and use the DRM zpos property, or > differentiate between OVERLAY and PRIMARY planes, when it comes to > setting up > multi-plane scanout. > >>> > >>> You already quoted me on the Weston link, so I don't think I have > >>> anything to add. Sounds fine to me, and we don't have a standard plane > >>> arrangement algorithm that the kernel could optimize zpos ranges > >>> against, yet. > >>> > Ultimately, what I'd like to answer is "What can we do on the KMS driver > and DRM > plane API side, that can make building multi-plane scanout > configurations easier > for compositors?" I'm hoping we can converge on something, whether that > be > updating the existing documentation to better define the usage, or > update the > API to provide support for something that is lacking. > >>> > >>> I think there probably should be a standardised plane arrangement > >>> algorithm in userspace, because the search space suffers from > >>> permutational explosion. Either there needs to be very few planes (max > >>> 4 or 5 at-all-possible per CRTC, including shareable ones) for an > >>> exhaustive search to be feasible, or all planes should be more or less > >>> equal in capabilities and userspace employs some simplified or > >>> heuristic search. > >>> > >>> If the search algorithm is fixed, then drivers could optimize zpos > >>> ranges to have the algorithm find a solution faster. > >>> > >>> My worry is that userspace already has heuristic search algorithms that > >>> may start failing if drivers later change their zpos ranges to be more > >>> optimal for another algorithm. > >>> > >>> OTOH, as long as exhaustive search is feasible, then it does not matter > >>> how DRM drivers set up the zpos ranges. > >>> > >>> In any case, the zpos ranges should try to allow all possible plane > >>> arrangements while minimizing the number of arrangements that won't > >>> work. The absolute values of zpos are pretty much irrelevant, so I > >>> think setting one plane to have an immutable zpos is a good idea, even > >>> if it's not necessary by the driver. That is one less moving part, and > >>> only the relative ordering between the planes matters. > >>> > >>> > >>> Thanks, > >>> pq > >> > >> Right, thanks for your thoughts! I agree that there should be a common > >> plane > >> arrangement algorithm. I think libliftoff is the most obvious candidate > >> here. It > >> only handles overlay arrangements currently, but mixed-mode arrangements is > >> something I've been trying to look at. > >> > >> Taking the driver's reported zpos into account could narrow down the search > >> space for mixed arrangements. We could tell whether underlay, or overlay, > >> or > >> both, is supported by looking at the allowed zpos ranges. > >> > >> I also wonder if it'll make underlay assignments easier. libliftoff has an > >> assumption that the PRIMARY plane has the lowest zpos (which now I > >> realize, is > >> not always true). Therefore, the underlay buffer has
[PATCH] drm/panfrost: Show overall GPU usage stats through sysfs knob
This changeset is heavily inspired by commit 509433d8146c ("drm/v3d: Expose
the total GPU usage stats on sysfs"). The point is making broader GPU
occupancy numbers available through the sysfs interface, so that for every
job slot, its number of processed jobs and total processing time are
displayed.
Cc: Boris Brezillon
Cc: Christopher Healy
Signed-off-by: Adrián Larumbe
---
drivers/gpu/drm/panfrost/panfrost_device.h | 5 +++
drivers/gpu/drm/panfrost/panfrost_drv.c| 49 --
drivers/gpu/drm/panfrost/panfrost_job.c| 17 +++-
drivers/gpu/drm/panfrost/panfrost_job.h| 3 ++
4 files changed, 68 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_device.h
b/drivers/gpu/drm/panfrost/panfrost_device.h
index cffcb0ac7c11..1d343351c634 100644
--- a/drivers/gpu/drm/panfrost/panfrost_device.h
+++ b/drivers/gpu/drm/panfrost/panfrost_device.h
@@ -169,6 +169,11 @@ struct panfrost_engine_usage {
unsigned long long cycles[NUM_JOB_SLOTS];
};
+struct panfrost_slot_usage {
+ u64 enabled_ns;
+ u64 jobs_sent;
+};
+
struct panfrost_file_priv {
struct panfrost_device *pfdev;
diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
b/drivers/gpu/drm/panfrost/panfrost_drv.c
index ef9f6c0716d5..6afcde66270f 100644
--- a/drivers/gpu/drm/panfrost/panfrost_drv.c
+++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -524,6 +525,10 @@ static const struct drm_ioctl_desc
panfrost_drm_driver_ioctls[] = {
PANFROST_IOCTL(MADVISE, madvise,DRM_RENDER_ALLOW),
};
+static const char * const engine_names[] = {
+ "fragment", "vertex-tiler", "compute-only"
+};
+
static void panfrost_gpu_show_fdinfo(struct panfrost_device *pfdev,
struct panfrost_file_priv *panfrost_priv,
struct drm_printer *p)
@@ -543,10 +548,6 @@ static void panfrost_gpu_show_fdinfo(struct
panfrost_device *pfdev,
* job spent on the GPU.
*/
- static const char * const engine_names[] = {
- "fragment", "vertex-tiler", "compute-only"
- };
-
BUILD_BUG_ON(ARRAY_SIZE(engine_names) != NUM_JOB_SLOTS);
for (i = 0; i < NUM_JOB_SLOTS - 1; i++) {
@@ -716,8 +717,48 @@ static ssize_t profiling_store(struct device *dev,
static DEVICE_ATTR_RW(profiling);
+static ssize_t
+gpu_stats_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+ struct panfrost_device *pfdev = dev_get_drvdata(dev);
+ struct panfrost_slot_usage stats;
+ u64 timestamp = local_clock();
+ ssize_t len = 0;
+ unsigned int i;
+
+ BUILD_BUG_ON(ARRAY_SIZE(engine_names) != NUM_JOB_SLOTS);
+
+ len += sysfs_emit(buf, "queuetimestampjobs
runtime\n");
+ len += sysfs_emit_at(buf, len,
"-\n");
+
+ for (i = 0; i < NUM_JOB_SLOTS - 1; i++) {
+
+ stats = get_slot_stats(pfdev, i);
+
+ /*
+* Each line will display the slot name, timestamp, the number
+* of jobs handled by that engine and runtime, as shown below:
+*
+* queuetimestampjobsruntime
+* -
+* fragment 12252943467507 638 1184747640
+* vertex-tiler 12252943467507 636 121663838
+*
+*/
+ len += sysfs_emit_at(buf, len, "%-13s%-17llu%-12llu%llu\n",
+engine_names[i],
+timestamp,
+stats.jobs_sent,
+stats.enabled_ns);
+ }
+
+ return len;
+}
+static DEVICE_ATTR_RO(gpu_stats);
+
static struct attribute *panfrost_attrs[] = {
_attr_profiling.attr,
+ _attr_gpu_stats.attr,
NULL,
};
diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c
b/drivers/gpu/drm/panfrost/panfrost_job.c
index a61ef0af9a4e..4c779e6f4cb0 100644
--- a/drivers/gpu/drm/panfrost/panfrost_job.c
+++ b/drivers/gpu/drm/panfrost/panfrost_job.c
@@ -31,6 +31,8 @@ struct panfrost_queue_state {
struct drm_gpu_scheduler sched;
u64 fence_context;
u64 emit_seqno;
+
+ struct panfrost_slot_usage stats;
};
struct panfrost_job_slot {
@@ -160,15 +162,20 @@ panfrost_dequeue_job(struct panfrost_device *pfdev, int
slot)
WARN_ON(!job);
if (job->is_profiled) {
+ u64 job_time = ktime_to_ns(ktime_sub(ktime_get(),
job->start_time));
+
if (job->engine_usage) {
- job->engine_usage->elapsed_ns[slot] +=
- ktime_to_ns(ktime_sub(ktime_get(),
job->start_time));
+
Re: [PATCH 0/2] drm/amdgpu/display: Make multi-plane configurations more flexible
On 2024-04-04 06:24, Pekka Paalanen wrote: > On Wed, 3 Apr 2024 17:32:46 -0400 > Leo Li wrote: > >> On 2024-03-28 10:33, Pekka Paalanen wrote: >>> On Fri, 15 Mar 2024 13:09:56 -0400 >>> wrote: >>> From: Leo Li These patches aim to make the amdgpgu KMS driver play nicer with compositors when building multi-plane scanout configurations. They do so by: 1. Making cursor behavior more sensible. 2. Allowing placement of DRM OVERLAY planes underneath the PRIMARY plane for 'underlay' configurations (perhaps more of a RFC, see below). Please see the commit messages for details. For #2, the simplest way to accomplish this was to increase the value of the immutable zpos property for the PRIMARY plane. This allowed OVERLAY planes with a mutable zpos range of (0-254) to be positioned underneath the PRIMARY for an underlay scanout configuration. Technically speaking, DCN hardware does not have a concept of primary or overlay planes - there are simply 4 general purpose hardware pipes that can be maped in any configuration. So the immutable zpos restriction on the PRIMARY plane is kind of arbitrary; it can have a mutable range of (0-254) just like the OVERLAYs. The distinction between PRIMARY and OVERLAY planes is also somewhat arbitrary. We can interpret PRIMARY as the first plane that should be enabled on a CRTC, but beyond that, it doesn't mean much for amdgpu. Therefore, I'm curious about how compositors devs understand KMS planes and their zpos properties, and how we would like to use them. It isn't clear to me how compositors wish to interpret and use the DRM zpos property, or differentiate between OVERLAY and PRIMARY planes, when it comes to setting up multi-plane scanout. >>> >>> You already quoted me on the Weston link, so I don't think I have >>> anything to add. Sounds fine to me, and we don't have a standard plane >>> arrangement algorithm that the kernel could optimize zpos ranges >>> against, yet. >>> Ultimately, what I'd like to answer is "What can we do on the KMS driver and DRM plane API side, that can make building multi-plane scanout configurations easier for compositors?" I'm hoping we can converge on something, whether that be updating the existing documentation to better define the usage, or update the API to provide support for something that is lacking. >>> >>> I think there probably should be a standardised plane arrangement >>> algorithm in userspace, because the search space suffers from >>> permutational explosion. Either there needs to be very few planes (max >>> 4 or 5 at-all-possible per CRTC, including shareable ones) for an >>> exhaustive search to be feasible, or all planes should be more or less >>> equal in capabilities and userspace employs some simplified or >>> heuristic search. >>> >>> If the search algorithm is fixed, then drivers could optimize zpos >>> ranges to have the algorithm find a solution faster. >>> >>> My worry is that userspace already has heuristic search algorithms that >>> may start failing if drivers later change their zpos ranges to be more >>> optimal for another algorithm. >>> >>> OTOH, as long as exhaustive search is feasible, then it does not matter >>> how DRM drivers set up the zpos ranges. >>> >>> In any case, the zpos ranges should try to allow all possible plane >>> arrangements while minimizing the number of arrangements that won't >>> work. The absolute values of zpos are pretty much irrelevant, so I >>> think setting one plane to have an immutable zpos is a good idea, even >>> if it's not necessary by the driver. That is one less moving part, and >>> only the relative ordering between the planes matters. >>> >>> >>> Thanks, >>> pq >> >> Right, thanks for your thoughts! I agree that there should be a common plane >> arrangement algorithm. I think libliftoff is the most obvious candidate >> here. It >> only handles overlay arrangements currently, but mixed-mode arrangements is >> something I've been trying to look at. >> >> Taking the driver's reported zpos into account could narrow down the search >> space for mixed arrangements. We could tell whether underlay, or overlay, or >> both, is supported by looking at the allowed zpos ranges. >> >> I also wonder if it'll make underlay assignments easier. libliftoff has an >> assumption that the PRIMARY plane has the lowest zpos (which now I realize, >> is >> not always true). Therefore, the underlay buffer has to be placed on the >> PRIMARY, with the render buffer on a higher OVERLAY. Swapping buffers between >> planes when testing mixed-arrangements is kind of awkward, and simply setting >> the OVERLAY's zpos to be lower or higher than the PRIMARY's sounds simpler. >> >> Currently only gamescope makes use of libliftoff, but
Re: [PATCH v7 00/37] Device Tree support for SH7751 based board
On Thu, Apr 04, 2024 at 01:59:25PM +0900, Yoshinori Sato wrote: > This is an updated version of something I wrote about 7 years ago. > Minimum support for R2D-plus and LANDISK. > I think R2D-1 will work if you add AX88796 to dts. > And board-specific functions and SCI's SPI functions are not supported. My comments/questions from https://lore.kernel.org/r/20231120181600.GA205977@bhelgaas https://lore.kernel.org/r/20231016172742.GA1215127@bhelgaas still apply.
Re: [PATCH] drivers: video: logo: Don't mention the full path of the input in output
On 4/4/24 14:18, Lucas Stach wrote:
This change strips $abs_srctree of the input file containing the
PNM data in the generated output. The motivation for this change
is Yocto emitting a build warning
WARNING: linux-foo-6.8-r0 do_package_qa: QA Issue:
File
/usr/src/debug/linux-foo/6.8-r0/drivers/video/logo/logo_linux_clut224.c
in package linux-foo-src contains reference to TMPDIR
So this change brings us one step closer to make the build result
reproducible independent of the build path.
Signed-off-by: Lucas Stach
---
drivers/video/logo/pnmtologo.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/video/logo/pnmtologo.c b/drivers/video/logo/pnmtologo.c
index 2434a25afb64..59ccd721e8af 100644
--- a/drivers/video/logo/pnmtologo.c
+++ b/drivers/video/logo/pnmtologo.c
@@ -223,6 +223,18 @@ static inline int is_equal(struct color c1, struct color
c2)
static void write_header(void)
{
+ const char *abs_srctree = getenv("abs_srctree");
+ const char *rel_filename;
+
+ if (abs_srctree &&
+ !strncmp(abs_srctree, filename, strlen(abs_srctree))) {
+ rel_filename = filename + strlen(abs_srctree);
+ while (*rel_filename == '/')
+ ++rel_filename;
+ } else {
+ rel_filename = filename;
+ }
+
/* open logo file */
if (outputname) {
out = fopen(outputname, "w");
@@ -235,7 +247,7 @@ static void write_header(void)
fputs("/*\n", out);
fputs(" * DO NOT EDIT THIS FILE!\n", out);
fputs(" *\n", out);
- fprintf(out, " * It was automatically generated from %s\n", filename);
+ fprintf(out, " * It was automatically generated from %s\n",
rel_filename);
can't you use instead: ?
+ fprintf(out, " * It was automatically generated from %s\n",
basename(filename));
Helge
fputs(" *\n", out);
fprintf(out, " * Linux logo %s\n", logoname);
fputs(" */\n\n", out);
Re: [PATCH 0/2] drm/lima: two driver cleanups
Serial is Reviewed-by: Qiang Yu On Tue, Apr 2, 2024 at 6:43 AM Erico Nunes wrote: > > Patch 1 is a fix for a crash which triggers on removing the module on > kernels with CONFIG_DEBUG_SHIRQ enabled, such as the Fedora kernel. > > Patch 2 is a fix to this warning: > drivers/gpu/drm/lima/lima_drv.c:387:13: error: cast to smaller integer > type 'enum lima_gpu_id' from 'const void *' > [-Werror,-Wvoid-pointer-to-enum-cast] > which we have received as a repeated report from the kernel test bot to > the lima mailing list. > The warning only reproduces with recent clang on aarch64, but the patch > does get rid of it and there seem to be no more warnings for W=1. > > Erico Nunes (2): > drm/lima: fix shared irq handling on driver remove > drm/lima: fix void pointer to enum lima_gpu_id cast warning > > drivers/gpu/drm/lima/lima_drv.c | 21 ++--- > drivers/gpu/drm/lima/lima_drv.h | 5 + > drivers/gpu/drm/lima/lima_gp.c | 2 ++ > drivers/gpu/drm/lima/lima_mmu.c | 5 + > drivers/gpu/drm/lima/lima_pp.c | 4 > 5 files changed, 34 insertions(+), 3 deletions(-) > > -- > 2.44.0 >
[PATCH] drm: fix DRM_DISPLAY_DP_HELPER dependencies
From: Arnd Bergmann
Both the exynos and rockchip drivers ran into link failures after
a Kconfig cleanup:
aarch64-linux-ld: drivers/gpu/drm/exynos/exynos_dp.o: in function
`exynos_dp_resume':
exynos_dp.c:(.text+0xc0): undefined reference to `analogix_dp_resume'
aarch64-linux-ld: drivers/gpu/drm/exynos/exynos_dp.o: in function
`exynos_dp_suspend':
exynos_dp.c:(.text+0xf4): undefined reference to `analogix_dp_suspend'
x86_64-linux-ld: drivers/gpu/drm/rockchip/cdn-dp-core.o: in function
`cdn_dp_connector_mode_valid':
cdn-dp-core.c:(.text+0x13a): undefined reference to
`drm_dp_bw_code_to_link_rate'
x86_64-linux-ld: cdn-dp-core.c:(.text+0x148): undefined reference to
`drm_dp_bw_code_to_link_rate'
x86_64-linux-ld: drivers/gpu/drm/rockchip/cdn-dp-core.o: in function
`cdn_dp_check_link_status':
cdn-dp-core.c:(.text+0x1396): undefined reference to `drm_dp_channel_eq_ok'
In both cases, the problem is that ROCKCHIP_CDN_DP and DRM_EXYNOS_DP
are 'bool' symbols that depend on the the 'tristate' DRM_DISPLAY_HELPER
symbol, but end up not working when the SoC specific part is built-in
but the helper is in a loadable module.
Use the same trick that DRM_ROCKCHIP already uses for the EXTCON
dependency and disallow DP support when it would not work.
Fixes: 0323287de87d ("drm: Switch DRM_DISPLAY_DP_HELPER to depends on")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/exynos/Kconfig | 2 +-
drivers/gpu/drm/rockchip/Kconfig | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 6a26a0b8eff2..58cd77220741 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -68,7 +68,7 @@ config DRM_EXYNOS_DP
bool "Exynos specific extensions for Analogix DP driver"
depends on DRM_EXYNOS_FIMD || DRM_EXYNOS7_DECON
depends on DRM_DISPLAY_DP_HELPER
- depends on DRM_DISPLAY_HELPER
+ depends on DRM_DISPLAY_HELPER=y || (DRM_DISPLAY_HELPER=m &&
DRM_EXYNOS=m)
select DRM_ANALOGIX_DP
default DRM_EXYNOS
select DRM_PANEL
diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index 4b49a14758fe..4b4ad75032fd 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -46,7 +46,7 @@ config ROCKCHIP_ANALOGIX_DP
config ROCKCHIP_CDN_DP
bool "Rockchip cdn DP"
depends on DRM_DISPLAY_DP_HELPER
- depends on DRM_DISPLAY_HELPER
+ depends on DRM_DISPLAY_HELPER=y || (DRM_DISPLAY_HELPER=m &&
DRM_ROCKCHIP=m)
depends on EXTCON=y || (EXTCON=m && DRM_ROCKCHIP=m)
help
This selects support for Rockchip SoC specific extensions
--
2.39.2
Re: [PATCH 2/2] drm/lima: mask irqs in timeout path before hard reset
Reviewed-by: Qiang Yu
On Tue, Apr 2, 2024 at 5:20 AM Erico Nunes wrote:
>
> There is a race condition in which a rendering job might take just long
> enough to trigger the drm sched job timeout handler but also still
> complete before the hard reset is done by the timeout handler.
> This runs into race conditions not expected by the timeout handler.
> In some very specific cases it currently may result in a refcount
> imbalance on lima_pm_idle, with a stack dump such as:
>
> [10136.669170] WARNING: CPU: 0 PID: 0 at
> drivers/gpu/drm/lima/lima_devfreq.c:205 lima_devfreq_record_idle+0xa0/0xb0
> ...
> [10136.669459] pc : lima_devfreq_record_idle+0xa0/0xb0
> ...
> [10136.669628] Call trace:
> [10136.669634] lima_devfreq_record_idle+0xa0/0xb0
> [10136.669646] lima_sched_pipe_task_done+0x5c/0xb0
> [10136.669656] lima_gp_irq_handler+0xa8/0x120
> [10136.669666] __handle_irq_event_percpu+0x48/0x160
> [10136.669679] handle_irq_event+0x4c/0xc0
>
> We can prevent that race condition entirely by masking the irqs at the
> beginning of the timeout handler, at which point we give up on waiting
> for that job entirely.
> The irqs will be enabled again at the next hard reset which is already
> done as a recovery by the timeout handler.
>
> Signed-off-by: Erico Nunes
> ---
> drivers/gpu/drm/lima/lima_sched.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/lima/lima_sched.c
> b/drivers/gpu/drm/lima/lima_sched.c
> index 66841503a618..bbf3f8feab94 100644
> --- a/drivers/gpu/drm/lima/lima_sched.c
> +++ b/drivers/gpu/drm/lima/lima_sched.c
> @@ -430,6 +430,13 @@ static enum drm_gpu_sched_stat
> lima_sched_timedout_job(struct drm_sched_job *job
> return DRM_GPU_SCHED_STAT_NOMINAL;
> }
>
> + /*
> +* The task might still finish while this timeout handler runs.
> +* To prevent a race condition on its completion, mask all irqs
> +* on the running core until the next hard reset completes.
> +*/
> + pipe->task_mask_irq(pipe);
> +
> if (!pipe->error)
> DRM_ERROR("%s job timeout\n", lima_ip_name(ip));
>
> --
> 2.44.0
>
Re: [PATCH 1/2] drm/lima: add mask irq callback to gp and pp
On Tue, Apr 2, 2024 at 5:20 AM Erico Nunes wrote:
>
> This is needed because we want to reset those devices in device-agnostic
> code such as lima_sched.
> In particular, masking irqs will be useful before a hard reset to
> prevent race conditions.
>
> Signed-off-by: Erico Nunes
> ---
> drivers/gpu/drm/lima/lima_bcast.c | 12
> drivers/gpu/drm/lima/lima_bcast.h | 3 +++
> drivers/gpu/drm/lima/lima_gp.c| 8
> drivers/gpu/drm/lima/lima_pp.c| 18 ++
> drivers/gpu/drm/lima/lima_sched.c | 2 ++
> drivers/gpu/drm/lima/lima_sched.h | 1 +
> 6 files changed, 44 insertions(+)
>
> diff --git a/drivers/gpu/drm/lima/lima_bcast.c
> b/drivers/gpu/drm/lima/lima_bcast.c
> index fbc43f243c54..6d000504e1a4 100644
> --- a/drivers/gpu/drm/lima/lima_bcast.c
> +++ b/drivers/gpu/drm/lima/lima_bcast.c
> @@ -43,6 +43,18 @@ void lima_bcast_suspend(struct lima_ip *ip)
>
> }
>
> +int lima_bcast_mask_irq(struct lima_ip *ip)
> +{
> + bcast_write(LIMA_BCAST_BROADCAST_MASK, 0);
> + bcast_write(LIMA_BCAST_INTERRUPT_MASK, 0);
> + return 0;
> +}
> +
> +int lima_bcast_reset(struct lima_ip *ip)
> +{
> + return lima_bcast_hw_init(ip);
> +}
> +
> int lima_bcast_init(struct lima_ip *ip)
> {
> int i;
> diff --git a/drivers/gpu/drm/lima/lima_bcast.h
> b/drivers/gpu/drm/lima/lima_bcast.h
> index 465ee587bceb..cd08841e4787 100644
> --- a/drivers/gpu/drm/lima/lima_bcast.h
> +++ b/drivers/gpu/drm/lima/lima_bcast.h
> @@ -13,4 +13,7 @@ void lima_bcast_fini(struct lima_ip *ip);
>
> void lima_bcast_enable(struct lima_device *dev, int num_pp);
>
> +int lima_bcast_mask_irq(struct lima_ip *ip);
> +int lima_bcast_reset(struct lima_ip *ip);
> +
> #endif
> diff --git a/drivers/gpu/drm/lima/lima_gp.c b/drivers/gpu/drm/lima/lima_gp.c
> index 6b354e2fb61d..e15295071533 100644
> --- a/drivers/gpu/drm/lima/lima_gp.c
> +++ b/drivers/gpu/drm/lima/lima_gp.c
> @@ -233,6 +233,13 @@ static void lima_gp_task_mmu_error(struct
> lima_sched_pipe *pipe)
> lima_sched_pipe_task_done(pipe);
> }
>
> +static void lima_gp_task_mask_irq(struct lima_sched_pipe *pipe)
> +{
> + struct lima_ip *ip = pipe->processor[0];
> +
> + gp_write(LIMA_GP_INT_MASK, 0);
> +}
> +
> static int lima_gp_task_recover(struct lima_sched_pipe *pipe)
> {
> struct lima_ip *ip = pipe->processor[0];
> @@ -365,6 +372,7 @@ int lima_gp_pipe_init(struct lima_device *dev)
> pipe->task_error = lima_gp_task_error;
> pipe->task_mmu_error = lima_gp_task_mmu_error;
> pipe->task_recover = lima_gp_task_recover;
> + pipe->task_mask_irq = lima_gp_task_mask_irq;
>
> return 0;
> }
> diff --git a/drivers/gpu/drm/lima/lima_pp.c b/drivers/gpu/drm/lima/lima_pp.c
> index d0d2db0ef1ce..a4a2ffe6527c 100644
> --- a/drivers/gpu/drm/lima/lima_pp.c
> +++ b/drivers/gpu/drm/lima/lima_pp.c
> @@ -429,6 +429,9 @@ static void lima_pp_task_error(struct lima_sched_pipe
> *pipe)
>
> lima_pp_hard_reset(ip);
> }
> +
> + if (pipe->bcast_processor)
> + lima_bcast_reset(pipe->bcast_processor);
> }
>
> static void lima_pp_task_mmu_error(struct lima_sched_pipe *pipe)
> @@ -437,6 +440,20 @@ static void lima_pp_task_mmu_error(struct
> lima_sched_pipe *pipe)
> lima_sched_pipe_task_done(pipe);
> }
>
> +static void lima_pp_task_mask_irq(struct lima_sched_pipe *pipe)
> +{
> + int i;
> +
> + for (i = 0; i < pipe->num_processor; i++) {
> + struct lima_ip *ip = pipe->processor[i];
> +
> + pp_write(LIMA_PP_INT_MASK, 0);
> + }
> +
> + if (pipe->bcast_processor)
> + lima_bcast_mask_irq(pipe->bcast_processor);
> +}
> +
> static struct kmem_cache *lima_pp_task_slab;
> static int lima_pp_task_slab_refcnt;
>
> @@ -468,6 +485,7 @@ int lima_pp_pipe_init(struct lima_device *dev)
> pipe->task_fini = lima_pp_task_fini;
> pipe->task_error = lima_pp_task_error;
> pipe->task_mmu_error = lima_pp_task_mmu_error;
> + pipe->task_mask_irq = lima_pp_task_mask_irq;
>
> return 0;
> }
> diff --git a/drivers/gpu/drm/lima/lima_sched.c
> b/drivers/gpu/drm/lima/lima_sched.c
> index 00b19adfc888..66841503a618 100644
> --- a/drivers/gpu/drm/lima/lima_sched.c
> +++ b/drivers/gpu/drm/lima/lima_sched.c
> @@ -422,6 +422,8 @@ static enum drm_gpu_sched_stat
> lima_sched_timedout_job(struct drm_sched_job *job
> */
> for (i = 0; i < pipe->num_processor; i++)
> synchronize_irq(pipe->processor[i]->irq);
> + if (pipe->bcast_processor)
> + synchronize_irq(pipe->bcast_processor->irq);
Better split this into another patch as it does not match the commit comment.
>
> if (dma_fence_is_signaled(task->fence)) {
> DRM_WARN("%s unexpectedly high interrupt latency\n",
> lima_ip_name(ip));
> diff --git a/drivers/gpu/drm/lima/lima_sched.h
> b/drivers/gpu/drm/lima/lima_sched.h
> index
Re: (subset) [PATCH V2 1/2] drm/bridge: adv7511: Allow IRQ to share GPIO pins
On Mon, 04 Mar 2024 18:48:57 -0600, Adam Ford wrote: > The IRQ registration currently assumes that the GPIO is dedicated > to it, but that may not necessarily be the case. If the board has > another device sharing the GPIO, it won't be registered and the > hot-plug detect fails to function. > > Currently, the handler reads two registers and blindly > assumes one of them caused the interrupt and returns IRQ_HANDLED > unless there is an error. In order to properly do this, the IRQ > handler needs to check if it needs to handle the IRQ and return > IRQ_NONE if there is nothing to handle. With the check added > and the return code properly indicating whether or not it there > was an IRQ, the IRQF_SHARED can be set to share a GPIO IRQ. > > [...] Applied to drm-misc-next, thanks! [1/2] drm/bridge: adv7511: Allow IRQ to share GPIO pins commit: f3d9683346d6b1d6e24f57e954385995601594d4 Best regards, -- With best wishes Dmitry
Re: [PATCH V2 1/2] drm/bridge: adv7511: Allow IRQ to share GPIO pins
On Mon, Mar 04, 2024 at 06:48:57PM -0600, Adam Ford wrote: > The IRQ registration currently assumes that the GPIO is dedicated > to it, but that may not necessarily be the case. If the board has > another device sharing the GPIO, it won't be registered and the > hot-plug detect fails to function. > > Currently, the handler reads two registers and blindly > assumes one of them caused the interrupt and returns IRQ_HANDLED > unless there is an error. In order to properly do this, the IRQ > handler needs to check if it needs to handle the IRQ and return > IRQ_NONE if there is nothing to handle. With the check added > and the return code properly indicating whether or not it there > was an IRQ, the IRQF_SHARED can be set to share a GPIO IRQ. > > Signed-off-by: Adam Ford > --- > V2: Add check to see if there is IRQ data to handle > Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
[PATCH] drivers: video: logo: Don't mention the full path of the input in output
This change strips $abs_srctree of the input file containing the
PNM data in the generated output. The motivation for this change
is Yocto emitting a build warning
WARNING: linux-foo-6.8-r0 do_package_qa: QA Issue:
File /usr/src/debug/linux-foo/6.8-r0/drivers/video/logo/logo_linux_clut224.c
in package linux-foo-src contains reference to TMPDIR
So this change brings us one step closer to make the build result
reproducible independent of the build path.
Signed-off-by: Lucas Stach
---
drivers/video/logo/pnmtologo.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/video/logo/pnmtologo.c b/drivers/video/logo/pnmtologo.c
index 2434a25afb64..59ccd721e8af 100644
--- a/drivers/video/logo/pnmtologo.c
+++ b/drivers/video/logo/pnmtologo.c
@@ -223,6 +223,18 @@ static inline int is_equal(struct color c1, struct color
c2)
static void write_header(void)
{
+ const char *abs_srctree = getenv("abs_srctree");
+ const char *rel_filename;
+
+ if (abs_srctree &&
+ !strncmp(abs_srctree, filename, strlen(abs_srctree))) {
+ rel_filename = filename + strlen(abs_srctree);
+ while (*rel_filename == '/')
+ ++rel_filename;
+ } else {
+ rel_filename = filename;
+ }
+
/* open logo file */
if (outputname) {
out = fopen(outputname, "w");
@@ -235,7 +247,7 @@ static void write_header(void)
fputs("/*\n", out);
fputs(" * DO NOT EDIT THIS FILE!\n", out);
fputs(" *\n", out);
- fprintf(out, " * It was automatically generated from %s\n", filename);
+ fprintf(out, " * It was automatically generated from %s\n",
rel_filename);
fputs(" *\n", out);
fprintf(out, " * Linux logo %s\n", logoname);
fputs(" */\n\n", out);
--
2.39.2
Re: [PATCH V2 1/2] drm/bridge: adv7511: Allow IRQ to share GPIO pins
On Tue, Mar 5, 2024 at 2:18 AM Laurent Pinchart wrote: > > Hello Adam, > > Thank you for the patch. > > On Mon, Mar 04, 2024 at 06:48:57PM -0600, Adam Ford wrote: > > The IRQ registration currently assumes that the GPIO is dedicated > > to it, but that may not necessarily be the case. If the board has > > another device sharing the GPIO, it won't be registered and the > > hot-plug detect fails to function. > > > > Currently, the handler reads two registers and blindly > > assumes one of them caused the interrupt and returns IRQ_HANDLED > > unless there is an error. In order to properly do this, the IRQ > > handler needs to check if it needs to handle the IRQ and return > > IRQ_NONE if there is nothing to handle. With the check added > > and the return code properly indicating whether or not it there > > was an IRQ, the IRQF_SHARED can be set to share a GPIO IRQ. > > > > Signed-off-by: Adam Ford > > Reviewed-by: Laurent Pinchart Gentle nudge on this one. It's been about a month, and without it, it is preventing hot-plug detection on one board for me. Thanks adam > > > --- > > V2: Add check to see if there is IRQ data to handle > > > > diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c > > b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c > > index b5518ff97165..f3b4616a8fb6 100644 > > --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c > > +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c > > @@ -477,6 +477,11 @@ static int adv7511_irq_process(struct adv7511 > > *adv7511, bool process_hpd) > > if (ret < 0) > > return ret; > > > > + /* If there is no IRQ to handle, exit indicating no IRQ data */ > > + if (!(irq0 & (ADV7511_INT0_HPD | ADV7511_INT0_EDID_READY)) && > > + !(irq1 & ADV7511_INT1_DDC_ERROR)) > > + return -ENODATA; > > + > > regmap_write(adv7511->regmap, ADV7511_REG_INT(0), irq0); > > regmap_write(adv7511->regmap, ADV7511_REG_INT(1), irq1); > > > > @@ -1318,7 +1323,8 @@ static int adv7511_probe(struct i2c_client *i2c) > > > > ret = devm_request_threaded_irq(dev, i2c->irq, NULL, > > adv7511_irq_handler, > > - IRQF_ONESHOT, dev_name(dev), > > + IRQF_ONESHOT | IRQF_SHARED, > > + dev_name(dev), > > adv7511); > > if (ret) > > goto err_unregister_audio; > > -- > Regards, > > Laurent Pinchart
Re: [PATCH v2 12/25] gpio: virtio: drop owner assignment
On Sun, Mar 31, 2024 at 10:45 AM Krzysztof Kozlowski wrote: > virtio core already sets the .owner, so driver does not need to. > > Acked-by: Bartosz Golaszewski > Acked-by: Viresh Kumar > Signed-off-by: Krzysztof Kozlowski Acked-by: Linus Walleij Yours, Linus Walleij
[PULL] drm-misc-fixes
Hi Dave, Sima, here's the drm-misc-fixes PR for this week. Best regards Thomas drm-misc-fixes-2024-04-04: Short summary of fixes pull: display: - fix typos in kerneldoc nouveau: - uvmm: fix remap address calculation - minor cleanups panfrost: - fix power-transition timeouts prime: - unbreak dma-buf export for virt-gpu The following changes since commit aba2a144c0bf1ecdcbc520525712fb661392e509: drm/qxl: remove unused variable from `qxl_process_single_command()` (2024-03-28 11:15:48 +0100) are available in the Git repository at: https://gitlab.freedesktop.org/drm/misc/kernel.git tags/drm-misc-fixes-2024-04-04 for you to fetch changes up to fddf09273807bf6e51537823aaae896e05f147f9: drm/display: fix typo (2024-04-01 22:35:16 +0300) Short summary of fixes pull: display: - fix typos in kerneldoc nouveau: - uvmm: fix remap address calculation - minor cleanups panfrost: - fix power-transition timeouts prime: - unbreak dma-buf export for virt-gpu Christian Hewitt (1): drm/panfrost: fix power transition timeout warnings Colin Ian King (1): drm/nouveau/gr/gf100: Remove second semicolon Dave Airlie (1): nouveau/uvmm: fix addr/range calcs for remap operations Oleksandr Natalenko (1): drm/display: fix typo Rob Clark (1): drm/prime: Unbreak virtgpu dma-buf export drivers/gpu/drm/display/drm_dp_dual_mode_helper.c | 4 ++-- drivers/gpu/drm/drm_prime.c | 7 ++- drivers/gpu/drm/nouveau/nouveau_uvmm.c| 6 +++--- drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c| 2 +- drivers/gpu/drm/panfrost/panfrost_gpu.c | 6 +++--- 5 files changed, 15 insertions(+), 10 deletions(-) -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Frankenstrasse 146, 90461 Nuernberg, Germany GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman HRB 36809 (AG Nuernberg)
[PATCH] drm/ttm/tests: Let ttm_bo_test consider different ww_mutex implementation.
PREEMPT_RT has a different locking implementation for ww_mutex. The
base mutex of struct ww_mutex is declared as struct WW_MUTEX_BASE. The
latter is defined as `mutex' for non-PREEMPT_RT builds and `rt_mutex'
for PREEMPT_RT builds.
Using mutex_lock() directly on the base mutex in
ttm_bo_reserve_deadlock() leads to compile error on PREEMPT_RT.
The locking-selftest has its own defines to deal with this and it is
probably best to defines the needed one within the test program since
their usefulness is limited outside of well known selftests.
Provide ww_mutex_base_lock() which points to the correct function for
PREEMPT_RT and non-PREEMPT_RT builds.
Fixes: 995279d280d1e ("drm/ttm/tests: Add tests for ttm_bo functions")
Signed-off-by: Sebastian Andrzej Siewior
---
For the record, testing led to
| WARNING: CPU: 5 PID: 2089 at include/drm/ttm/ttm_bo.h:247
ttm_bo_reserve_no_wait_ticket+0xe8/0x150 [ttm_bo_test]
but this occurred with and without RT on v6.9-rc2.
drivers/gpu/drm/ttm/tests/ttm_bo_test.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/tests/ttm_bo_test.c
b/drivers/gpu/drm/ttm/tests/ttm_bo_test.c
index 1f8a4f8adc929..9cc367a795341 100644
--- a/drivers/gpu/drm/ttm/tests/ttm_bo_test.c
+++ b/drivers/gpu/drm/ttm/tests/ttm_bo_test.c
@@ -18,6 +18,12 @@
#define BO_SIZESZ_8K
+#ifdef CONFIG_PREEMPT_RT
+#define ww_mutex_base_lock(b) rt_mutex_lock(b)
+#else
+#define ww_mutex_base_lock(b) mutex_lock(b)
+#endif
+
struct ttm_bo_test_case {
const char *description;
bool interruptible;
@@ -142,7 +148,7 @@ static void ttm_bo_reserve_deadlock(struct kunit *test)
bo2 = ttm_bo_kunit_init(test, test->priv, BO_SIZE);
ww_acquire_init(, _ww_class);
- mutex_lock(>base.resv->lock.base);
+ ww_mutex_base_lock(>base.resv->lock.base);
/* The deadlock will be caught by WW mutex, don't warn about it */
lock_release(>base.resv->lock.base.dep_map, 1);
--
2.43.0
Re: [PATCH 0/2] drm/amdgpu/display: Make multi-plane configurations more flexible
On Wed, 3 Apr 2024 17:32:46 -0400 Leo Li wrote: > On 2024-03-28 10:33, Pekka Paalanen wrote: > > On Fri, 15 Mar 2024 13:09:56 -0400 > > wrote: > > > >> From: Leo Li > >> > >> These patches aim to make the amdgpgu KMS driver play nicer with > >> compositors > >> when building multi-plane scanout configurations. They do so by: > >> > >> 1. Making cursor behavior more sensible. > >> 2. Allowing placement of DRM OVERLAY planes underneath the PRIMARY plane > >> for > >> 'underlay' configurations (perhaps more of a RFC, see below). > >> > >> Please see the commit messages for details. > >> > >> > >> For #2, the simplest way to accomplish this was to increase the value of > >> the > >> immutable zpos property for the PRIMARY plane. This allowed OVERLAY planes > >> with > >> a mutable zpos range of (0-254) to be positioned underneath the PRIMARY > >> for an > >> underlay scanout configuration. > >> > >> Technically speaking, DCN hardware does not have a concept of primary or > >> overlay > >> planes - there are simply 4 general purpose hardware pipes that can be > >> maped in > >> any configuration. So the immutable zpos restriction on the PRIMARY plane > >> is > >> kind of arbitrary; it can have a mutable range of (0-254) just like the > >> OVERLAYs. The distinction between PRIMARY and OVERLAY planes is also > >> somewhat > >> arbitrary. We can interpret PRIMARY as the first plane that should be > >> enabled on > >> a CRTC, but beyond that, it doesn't mean much for amdgpu. > >> > >> Therefore, I'm curious about how compositors devs understand KMS planes and > >> their zpos properties, and how we would like to use them. It isn't clear > >> to me > >> how compositors wish to interpret and use the DRM zpos property, or > >> differentiate between OVERLAY and PRIMARY planes, when it comes to setting > >> up > >> multi-plane scanout. > > > > You already quoted me on the Weston link, so I don't think I have > > anything to add. Sounds fine to me, and we don't have a standard plane > > arrangement algorithm that the kernel could optimize zpos ranges > > against, yet. > > > >> Ultimately, what I'd like to answer is "What can we do on the KMS driver > >> and DRM > >> plane API side, that can make building multi-plane scanout configurations > >> easier > >> for compositors?" I'm hoping we can converge on something, whether that be > >> updating the existing documentation to better define the usage, or update > >> the > >> API to provide support for something that is lacking. > > > > I think there probably should be a standardised plane arrangement > > algorithm in userspace, because the search space suffers from > > permutational explosion. Either there needs to be very few planes (max > > 4 or 5 at-all-possible per CRTC, including shareable ones) for an > > exhaustive search to be feasible, or all planes should be more or less > > equal in capabilities and userspace employs some simplified or > > heuristic search. > > > > If the search algorithm is fixed, then drivers could optimize zpos > > ranges to have the algorithm find a solution faster. > > > > My worry is that userspace already has heuristic search algorithms that > > may start failing if drivers later change their zpos ranges to be more > > optimal for another algorithm. > > > > OTOH, as long as exhaustive search is feasible, then it does not matter > > how DRM drivers set up the zpos ranges. > > > > In any case, the zpos ranges should try to allow all possible plane > > arrangements while minimizing the number of arrangements that won't > > work. The absolute values of zpos are pretty much irrelevant, so I > > think setting one plane to have an immutable zpos is a good idea, even > > if it's not necessary by the driver. That is one less moving part, and > > only the relative ordering between the planes matters. > > > > > > Thanks, > > pq > > Right, thanks for your thoughts! I agree that there should be a common plane > arrangement algorithm. I think libliftoff is the most obvious candidate here. > It > only handles overlay arrangements currently, but mixed-mode arrangements is > something I've been trying to look at. > > Taking the driver's reported zpos into account could narrow down the search > space for mixed arrangements. We could tell whether underlay, or overlay, or > both, is supported by looking at the allowed zpos ranges. > > I also wonder if it'll make underlay assignments easier. libliftoff has an > assumption that the PRIMARY plane has the lowest zpos (which now I realize, is > not always true). Therefore, the underlay buffer has to be placed on the > PRIMARY, with the render buffer on a higher OVERLAY. Swapping buffers between > planes when testing mixed-arrangements is kind of awkward, and simply setting > the OVERLAY's zpos to be lower or higher than the PRIMARY's sounds simpler. > > Currently only gamescope makes use of libliftoff, but I'm curious if patches > hooking it up to Weston would be
[PATCH 1/6] drm/panel: visionox-rm69299: don't unregister DSI device
The DSI device for the panel was registered by the DSI host, so it is an
error to unregister it from the panel driver. Drop the call to
mipi_dsi_device_unregister().
Fixes: c7f66d32dd43 ("drm/panel: add support for rm69299 visionox panel")
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/panel/panel-visionox-rm69299.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-visionox-rm69299.c
b/drivers/gpu/drm/panel/panel-visionox-rm69299.c
index 775144695283..b15ca56a09a7 100644
--- a/drivers/gpu/drm/panel/panel-visionox-rm69299.c
+++ b/drivers/gpu/drm/panel/panel-visionox-rm69299.c
@@ -253,8 +253,6 @@ static void visionox_rm69299_remove(struct mipi_dsi_device
*dsi)
struct visionox_rm69299 *ctx = mipi_dsi_get_drvdata(dsi);
mipi_dsi_detach(ctx->dsi);
- mipi_dsi_device_unregister(ctx->dsi);
-
drm_panel_remove(>panel);
}
--
2.39.2
[PATCH 6/6] drm/panel: visionox-rm69299: stop calling regulator_set_load manually
Use .init_load_uA part of the bulk regulator API instead of calling
register_set_load() manually.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/panel/panel-visionox-rm69299.c | 16 ++--
1 file changed, 2 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-visionox-rm69299.c
b/drivers/gpu/drm/panel/panel-visionox-rm69299.c
index b15ca56a09a7..272490b9565b 100644
--- a/drivers/gpu/drm/panel/panel-visionox-rm69299.c
+++ b/drivers/gpu/drm/panel/panel-visionox-rm69299.c
@@ -197,7 +197,9 @@ static int visionox_rm69299_probe(struct mipi_dsi_device
*dsi)
ctx->dsi = dsi;
ctx->supplies[0].supply = "vdda";
+ ctx->supplies[0].init_load_uA = 32000;
ctx->supplies[1].supply = "vdd3p3";
+ ctx->supplies[1].init_load_uA = 13200;
ret = devm_regulator_bulk_get(ctx->panel.dev, ARRAY_SIZE(ctx->supplies),
ctx->supplies);
@@ -227,22 +229,8 @@ static int visionox_rm69299_probe(struct mipi_dsi_device
*dsi)
goto err_dsi_attach;
}
- ret = regulator_set_load(ctx->supplies[0].consumer, 32000);
- if (ret) {
- dev_err(dev, "regulator set load failed for vdda supply ret =
%d\n", ret);
- goto err_set_load;
- }
-
- ret = regulator_set_load(ctx->supplies[1].consumer, 13200);
- if (ret) {
- dev_err(dev, "regulator set load failed for vdd3p3 supply ret =
%d\n", ret);
- goto err_set_load;
- }
-
return 0;
-err_set_load:
- mipi_dsi_detach(dsi);
err_dsi_attach:
drm_panel_remove(>panel);
return ret;
--
2.39.2
[PATCH 3/6] drm/panel: novatek-nt36672e: stop setting register load before disable
It is pointless to set register load before disabling the register. This
vote is going to be dropped as soon as the register is disabled. Drop
these register_set_load calls.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/panel/panel-novatek-nt36672e.c | 17 -
1 file changed, 17 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-novatek-nt36672e.c
b/drivers/gpu/drm/panel/panel-novatek-nt36672e.c
index c39fe0fc5d69..9a870b9b6765 100644
--- a/drivers/gpu/drm/panel/panel-novatek-nt36672e.c
+++ b/drivers/gpu/drm/panel/panel-novatek-nt36672e.c
@@ -25,12 +25,6 @@ static const unsigned long regulator_enable_loads[] = {
10,
};
-static const unsigned long regulator_disable_loads[] = {
- 80,
- 100,
- 100,
-};
-
struct panel_desc {
const struct drm_display_mode *display_mode;
u32 width_mm;
@@ -385,20 +379,9 @@ static int nt36672e_power_off(struct nt36672e_panel *ctx)
{
struct mipi_dsi_device *dsi = ctx->dsi;
int ret = 0;
- int i;
gpiod_set_value(ctx->reset_gpio, 0);
- for (i = 0; i < ARRAY_SIZE(ctx->supplies); i++) {
- ret = regulator_set_load(ctx->supplies[i].consumer,
- regulator_disable_loads[i]);
- if (ret) {
- dev_err(>dev, "regulator set load failed for
supply %s: %d\n",
- ctx->supplies[i].supply, ret);
- return ret;
- }
- }
-
ret = regulator_bulk_disable(ARRAY_SIZE(ctx->supplies), ctx->supplies);
if (ret)
dev_err(>dev, "regulator bulk disable failed: %d\n", ret);
--
2.39.2
[PATCH 4/6] drm/panel: novatek-nt36672e: stop calling regulator_set_load manually
Use .init_load_uA part of the bulk regulator API instead of calling
register_set_load() manually.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/panel/panel-novatek-nt36672e.c | 16
1 file changed, 4 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-novatek-nt36672e.c
b/drivers/gpu/drm/panel/panel-novatek-nt36672e.c
index 9a870b9b6765..20b7bfe4aa12 100644
--- a/drivers/gpu/drm/panel/panel-novatek-nt36672e.c
+++ b/drivers/gpu/drm/panel/panel-novatek-nt36672e.c
@@ -343,17 +343,7 @@ static int nt36672e_1080x2408_60hz_init(struct
mipi_dsi_device *dsi)
static int nt36672e_power_on(struct nt36672e_panel *ctx)
{
struct mipi_dsi_device *dsi = ctx->dsi;
- int ret, i;
-
- for (i = 0; i < ARRAY_SIZE(ctx->supplies); i++) {
- ret = regulator_set_load(ctx->supplies[i].consumer,
- regulator_enable_loads[i]);
- if (ret) {
- dev_err(>dev, "regulator set load failed for
supply %s: %d\n",
- ctx->supplies[i].supply, ret);
- return ret;
- }
- }
+ int ret;
ret = regulator_bulk_enable(ARRAY_SIZE(ctx->supplies), ctx->supplies);
if (ret < 0) {
@@ -550,8 +540,10 @@ static int nt36672e_panel_probe(struct mipi_dsi_device
*dsi)
return -ENODEV;
}
- for (i = 0; i < ARRAY_SIZE(ctx->supplies); i++)
+ for (i = 0; i < ARRAY_SIZE(ctx->supplies); i++) {
ctx->supplies[i].supply = regulator_names[i];
+ ctx->supplies[i].init_load_uA = regulator_enable_loads[i];
+ }
ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(ctx->supplies),
ctx->supplies);
--
2.39.2
[PATCH 5/6] drm/panel: novatek-nt36672a: stop calling regulator_set_load manually
Use .init_load_uA part of the bulk regulator API instead of calling
register_set_load() manually.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/panel/panel-novatek-nt36672a.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-novatek-nt36672a.c
b/drivers/gpu/drm/panel/panel-novatek-nt36672a.c
index 33fb3d715e54..3886372415c2 100644
--- a/drivers/gpu/drm/panel/panel-novatek-nt36672a.c
+++ b/drivers/gpu/drm/panel/panel-novatek-nt36672a.c
@@ -605,21 +605,16 @@ static int nt36672a_panel_add(struct nt36672a_panel
*pinfo)
struct device *dev = >link->dev;
int i, ret;
- for (i = 0; i < ARRAY_SIZE(pinfo->supplies); i++)
+ for (i = 0; i < ARRAY_SIZE(pinfo->supplies); i++) {
pinfo->supplies[i].supply = nt36672a_regulator_names[i];
+ pinfo->supplies[i].init_load_uA =
nt36672a_regulator_enable_loads[i];
+ }
ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(pinfo->supplies),
pinfo->supplies);
if (ret < 0)
return dev_err_probe(dev, ret, "failed to get regulators\n");
- for (i = 0; i < ARRAY_SIZE(pinfo->supplies); i++) {
- ret = regulator_set_load(pinfo->supplies[i].consumer,
-nt36672a_regulator_enable_loads[i]);
- if (ret)
- return dev_err_probe(dev, ret, "failed to set regulator
enable loads\n");
- }
-
pinfo->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
if (IS_ERR(pinfo->reset_gpio))
return dev_err_probe(dev, PTR_ERR(pinfo->reset_gpio),
--
2.39.2
[PATCH 2/6] drm/panel: novatek-nt36682e: don't unregister DSI device
The DSI device for the panel was registered by the DSI host, so it is an
error to unregister it from the panel driver. Drop the call to
mipi_dsi_device_unregister().
Fixes: ea4f9975625a ("drm/panel: Add support for Novatek NT36672E panel driver")
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/panel/panel-novatek-nt36672e.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-novatek-nt36672e.c
b/drivers/gpu/drm/panel/panel-novatek-nt36672e.c
index cb7406d74466..c39fe0fc5d69 100644
--- a/drivers/gpu/drm/panel/panel-novatek-nt36672e.c
+++ b/drivers/gpu/drm/panel/panel-novatek-nt36672e.c
@@ -614,8 +614,6 @@ static void nt36672e_panel_remove(struct mipi_dsi_device
*dsi)
struct nt36672e_panel *ctx = mipi_dsi_get_drvdata(dsi);
mipi_dsi_detach(ctx->dsi);
- mipi_dsi_device_unregister(ctx->dsi);
-
drm_panel_remove(>panel);
}
--
2.39.2
[PATCH 0/6] drm/panel: small fixes for visionox and novatek panel drivers
While taking a glance at the novatek-nt36672e driver I stumbled upon a call to unregister the DSI device for the panel, although it was not the panel driver that registered the device. Remove this call and a similar call from the visionox-rm69299 driver. While we are at it, also optimize regulator API calls in these two drivers and in the novatek-nt36672a driver. Signed-off-by: Dmitry Baryshkov --- Dmitry Baryshkov (6): drm/panel: visionox-rm69299: don't unregister DSI device drm/panel: novatek-nt36682e: don't unregister DSI device drm/panel: novatek-nt36672e: stop setting register load before disable drm/panel: novatek-nt36672e: stop calling regulator_set_load manually drm/panel: novatek-nt36672a: stop calling regulator_set_load manually drm/panel: visionox-rm69299: stop calling regulator_set_load manually drivers/gpu/drm/panel/panel-novatek-nt36672a.c | 11 +++- drivers/gpu/drm/panel/panel-novatek-nt36672e.c | 35 +++--- drivers/gpu/drm/panel/panel-visionox-rm69299.c | 18 ++--- 3 files changed, 9 insertions(+), 55 deletions(-) --- base-commit: a6bd6c997f5a0e2667d4d82fef8c970108f2 change-id: 20240404-drop-panel-unregister-744a9fd41cc6 Best regards, -- Dmitry Baryshkov
Re: [PATCH net-next v6 3/3] net: ethernet: ti: am65-cpsw: Add minimal XDP support
On Tue, 2024-04-02 at 12:33 +0200, Julien Panis wrote:
[...]
> +static int am65_cpsw_run_xdp(struct am65_cpsw_common *common, struct
> am65_cpsw_port *port,
> + struct xdp_buff *xdp, int desc_idx, int cpu, int
> *len)
> +{
> + struct am65_cpsw_rx_chn *rx_chn = >rx_chns;
> + struct net_device *ndev = port->ndev;
> + int ret = AM65_CPSW_XDP_CONSUMED;
> + struct am65_cpsw_tx_chn *tx_chn;
> + struct netdev_queue *netif_txq;
> + struct xdp_frame *xdpf;
> + struct bpf_prog *prog;
> + struct page *page;
> + u32 act;
> +
> + prog = READ_ONCE(port->xdp_prog);
> + if (!prog)
> + return AM65_CPSW_XDP_PASS;
> +
> + act = bpf_prog_run_xdp(prog, xdp);
> + /* XDP prog might have changed packet data and boundaries */
> + *len = xdp->data_end - xdp->data;
> +
> + switch (act) {
> + case XDP_PASS:
> + ret = AM65_CPSW_XDP_PASS;
> + goto out;
> + case XDP_TX:
> + tx_chn = >tx_chns[cpu % AM65_CPSW_MAX_TX_QUEUES];
> + netif_txq = netdev_get_tx_queue(ndev, tx_chn->id);
> +
> + xdpf = xdp_convert_buff_to_frame(xdp);
> + if (unlikely(!xdpf))
> + break;
> +
> + __netif_tx_lock(netif_txq, cpu);
> + ret = am65_cpsw_xdp_tx_frame(ndev, tx_chn, xdpf,
> + AM65_CPSW_TX_BUF_TYPE_XDP_TX);
> + __netif_tx_unlock(netif_txq);
> + if (ret)
> + break;
> +
> + ndev->stats.rx_bytes += *len;
> + ndev->stats.rx_packets++;
> + ret = AM65_CPSW_XDP_CONSUMED;
> + goto out;
> + case XDP_REDIRECT:
> + if (unlikely(xdp_do_redirect(ndev, xdp, prog)))
> + break;
> +
> + xdp_do_flush();
The above will kill XDP redirect performances. Even if this HW has the
same limitation of cpsw, the above will still deserve an explicit
comment.
Quickly skimming over the code it does not look so, so you could
possibly move xdp_do_flush() in am65_cpsw_nuss_rx_poll().
Cheers,
Paolo
Re: [PATCH v1 2/3] dt-bindings: arm: mediatek: mmsys: Add OF graph support for board path
On Thu, 04 Apr 2024 10:16:34 +0200, AngeloGioacchino Del Regno wrote:
> Document OF graph on MMSYS/VDOSYS: this supports up to three DDP paths
> per HW instance (so potentially up to six displays for multi-vdo SoCs).
>
> The MMSYS or VDOSYS is always the first component in the DDP pipeline,
> so it only supports an output port with multiple endpoints - where each
> endpoint defines the starting point for one of the (currently three)
> possible hardware paths.
>
> Signed-off-by: AngeloGioacchino Del Regno
>
> ---
> .../bindings/arm/mediatek/mediatek,mmsys.yaml | 23 +++
> 1 file changed, 23 insertions(+)
>
My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml:
properties:port:properties:required: ['endpoint@0'] is not of type 'object',
'boolean'
from schema $id: http://json-schema.org/draft-07/schema#
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml:
properties:port:properties: 'required' should not be valid under {'$ref':
'#/definitions/json-schema-prop-names'}
hint: A json-schema keyword was found instead of a DT property name.
from schema $id: http://devicetree.org/meta-schemas/keywords.yaml#
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml:
properties:port:properties:required: ['endpoint@0'] is not of type 'object',
'boolean'
from schema $id: http://devicetree.org/meta-schemas/keywords.yaml#
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml:
ignoring, error in schema: properties: port: properties: required
Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.example.dtb:
/example-0/syscon@1400: failed to match any schema with compatible:
['mediatek,mt8173-mmsys', 'syscon']
doc reference errors (make refcheckdocs):
See
https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240404081635.91412-3-angelogioacchino.delre...@collabora.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
Re: [PATCH v12 2/7] clk: meson: add vclk driver
On Wed 03 Apr 2024 at 09:46, Neil Armstrong wrote:
> The VCLK and VCLK_DIV clocks have supplementary bits.
>
> The VCLK gate has a "SOFT RESET" bit to toggle after the whole
> VCLK sub-tree rate has been set, this is implemented in
> the gate enable callback.
>
> The VCLK_DIV clocks as enable and reset bits used to disable
> and reset the divider, associated with CLK_SET_RATE_GATE it ensures
> the rate is set while the divider is disabled and in reset mode.
>
> The VCLK_DIV enable bit isn't implemented as a gate since it's part
> of the divider logic and vendor does this exact sequence to ensure
> the divider is correctly set.
The checkpatch warning is still there. Is it a choice or a mistake ?
Documentation says "GPL v2" exists for historic reason which seems to
hint "GPL" is preferred, and I suppose this is why checkpatch warns for
it.
>
> Signed-off-by: Neil Armstrong
> ---
> drivers/clk/meson/Kconfig | 4 ++
> drivers/clk/meson/Makefile | 1 +
> drivers/clk/meson/vclk.c | 141
> +
> drivers/clk/meson/vclk.h | 51
> 4 files changed, 197 insertions(+)
>
> diff --git a/drivers/clk/meson/Kconfig b/drivers/clk/meson/Kconfig
> index 29ffd14d267b..8a9823789fa3 100644
> --- a/drivers/clk/meson/Kconfig
> +++ b/drivers/clk/meson/Kconfig
> @@ -30,6 +30,10 @@ config COMMON_CLK_MESON_VID_PLL_DIV
> tristate
> select COMMON_CLK_MESON_REGMAP
>
> +config COMMON_CLK_MESON_VCLK
> + tristate
> + select COMMON_CLK_MESON_REGMAP
> +
> config COMMON_CLK_MESON_CLKC_UTILS
> tristate
>
> diff --git a/drivers/clk/meson/Makefile b/drivers/clk/meson/Makefile
> index 9ee4b954c896..9ba43fe7a07a 100644
> --- a/drivers/clk/meson/Makefile
> +++ b/drivers/clk/meson/Makefile
> @@ -12,6 +12,7 @@ obj-$(CONFIG_COMMON_CLK_MESON_PLL) += clk-pll.o
> obj-$(CONFIG_COMMON_CLK_MESON_REGMAP) += clk-regmap.o
> obj-$(CONFIG_COMMON_CLK_MESON_SCLK_DIV) += sclk-div.o
> obj-$(CONFIG_COMMON_CLK_MESON_VID_PLL_DIV) += vid-pll-div.o
> +obj-$(CONFIG_COMMON_CLK_MESON_VCLK) += vclk.o
>
> # Amlogic Clock controllers
>
> diff --git a/drivers/clk/meson/vclk.c b/drivers/clk/meson/vclk.c
> new file mode 100644
> index ..45dc216941ea
> --- /dev/null
> +++ b/drivers/clk/meson/vclk.c
> @@ -0,0 +1,141 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2024 Neil Armstrong
> + */
> +
> +#include
> +#include "vclk.h"
> +
> +/* The VCLK gate has a supplementary reset bit to pulse after ungating */
> +
> +static inline struct meson_vclk_gate_data *
> +clk_get_meson_vclk_gate_data(struct clk_regmap *clk)
> +{
> + return (struct meson_vclk_gate_data *)clk->data;
> +}
> +
> +static int meson_vclk_gate_enable(struct clk_hw *hw)
> +{
> + struct clk_regmap *clk = to_clk_regmap(hw);
> + struct meson_vclk_gate_data *vclk = clk_get_meson_vclk_gate_data(clk);
> +
> + meson_parm_write(clk->map, >enable, 1);
> +
> + /* Do a reset pulse */
> + meson_parm_write(clk->map, >reset, 1);
> + meson_parm_write(clk->map, >reset, 0);
> +
> + return 0;
> +}
> +
> +static void meson_vclk_gate_disable(struct clk_hw *hw)
> +{
> + struct clk_regmap *clk = to_clk_regmap(hw);
> + struct meson_vclk_gate_data *vclk = clk_get_meson_vclk_gate_data(clk);
> +
> + meson_parm_write(clk->map, >enable, 0);
> +}
> +
> +static int meson_vclk_gate_is_enabled(struct clk_hw *hw)
> +{
> + struct clk_regmap *clk = to_clk_regmap(hw);
> + struct meson_vclk_gate_data *vclk = clk_get_meson_vclk_gate_data(clk);
> +
> + return meson_parm_read(clk->map, >enable);
> +}
> +
> +const struct clk_ops meson_vclk_gate_ops = {
> + .enable = meson_vclk_gate_enable,
> + .disable = meson_vclk_gate_disable,
> + .is_enabled = meson_vclk_gate_is_enabled,
> +};
> +EXPORT_SYMBOL_GPL(meson_vclk_gate_ops);
> +
> +/* The VCLK Divider has supplementary reset & enable bits */
> +
> +static inline struct meson_vclk_div_data *
> +clk_get_meson_vclk_div_data(struct clk_regmap *clk)
> +{
> + return (struct meson_vclk_div_data *)clk->data;
> +}
> +
> +static unsigned long meson_vclk_div_recalc_rate(struct clk_hw *hw,
> + unsigned long prate)
> +{
> + struct clk_regmap *clk = to_clk_regmap(hw);
> + struct meson_vclk_div_data *vclk = clk_get_meson_vclk_div_data(clk);
> +
> + return divider_recalc_rate(hw, prate, meson_parm_read(clk->map,
> >div),
> +vclk->table, vclk->flags, vclk->div.width);
> +}
> +
> +static int meson_vclk_div_determine_rate(struct clk_hw *hw,
> + struct clk_rate_request *req)
> +{
> + struct clk_regmap *clk = to_clk_regmap(hw);
> + struct meson_vclk_div_data *vclk = clk_get_meson_vclk_div_data(clk);
> +
> + return divider_determine_rate(hw, req, vclk->table, vclk->div.width,
> + vclk->flags);
> +}
> +
> +static int meson_vclk_div_set_rate(struct
Re: [PATCH 5/5] drm/vmwgfx: Sort primary plane formats by order of preference
On Wed, 3 Apr 2024 07:44:54 -0400 Zack Rusin wrote: > On Wed, Apr 3, 2024 at 3:43 AM Pekka Paalanen > wrote: > > > > On Tue, 2 Apr 2024 19:28:13 -0400 > > Zack Rusin wrote: > > > > > The table of primary plane formats wasn't sorted at all, leading to > > > applications picking our least desirable formats by defaults. > > > > > > Sort the primary plane formats according to our order of preference. > > > > This is good. > > > > > Fixes IGT's kms_atomic plane-invalid-params which assumes that the > > > preferred format is a 32bpp format. > > > > That sounds strange, why would IGT depend on preferred format being > > 32bpp? > > > > That must be an oversight. IGT cannot dictate the format that hardware > > must prefer. XRGB is strongly suggested to be supported in general, > > but why also preferred? > > I think it's just a side-effect of the pixman's assert that's failing: > https://cgit.freedesktop.org/drm/igt-gpu-tools/tree/lib/igt_fb.c#n4190 > i.e. pixman assumes everything is 4 byte aligned. > I should have rephrased the message as "IGT assumes that the preferred > fb format is 4 byte aligned because our 16bpp formats are packed and > pixman can't convert them". Ah, yes. IIRC Pixman indeed assumes 4-byte alignment for stride and row start. It should work for 16bpp formats if the FB had even width + padding in pixels. I think this is just an indication that Pixman is ill-suited for IGT. IGT should be able to generate and analyse images in any format any kernel driver might support. I've noticed IGT also using Cairo, which limits the possible pixel formats so severely I'm actually puzzled how it can even be used there. Anyway, this is not at all about your patch, which looks good and well to me. Just the comment about adapting to IGT seemed odd. Maybe phrase that more like a happy accident rather than another justification for this patch? This patch: Acked-by: Pekka Paalanen Thanks, pq pgp2M8Nbaq_O9.pgp Description: OpenPGP digital signature
[PATCH] drm/atomic-helper: fix parameter order in drm_format_conv_state_copy() call
Old and new state parameters are swapped, so the old state was cleared
instead of the new duplicated state.
Fixes: 903674588a48 ("drm/atomic-helper: Add format-conversion state to
shadow-plane state")
Signed-off-by: Lucas Stach
Tested-by: Leonard Göhrs
---
drivers/gpu/drm/drm_gem_atomic_helper.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_atomic_helper.c
b/drivers/gpu/drm/drm_gem_atomic_helper.c
index e440f458b663..93337543aac3 100644
--- a/drivers/gpu/drm/drm_gem_atomic_helper.c
+++ b/drivers/gpu/drm/drm_gem_atomic_helper.c
@@ -224,8 +224,8 @@ __drm_gem_duplicate_shadow_plane_state(struct drm_plane
*plane,
__drm_atomic_helper_plane_duplicate_state(plane,
_shadow_plane_state->base);
- drm_format_conv_state_copy(_plane_state->fmtcnv_state,
- _shadow_plane_state->fmtcnv_state);
+ drm_format_conv_state_copy(_shadow_plane_state->fmtcnv_state,
+ _plane_state->fmtcnv_state);
}
EXPORT_SYMBOL(__drm_gem_duplicate_shadow_plane_state);
--
2.39.2
[PATCH v1 1/3] dt-bindings: display: mediatek: Add OF graph support for board path
The display IPs in MediaTek SoCs support being interconnected with
different instances of DDP IPs (for example, merge0 or merge1) and/or
with different DDP IPs (for example, rdma can be connected with either
color, dpi, dsi, merge, etc), forming a full Display Data Path that
ends with an actual display.
The final display pipeline is effectively board specific, as it does
depend on the display that is attached to it, and eventually on the
sensors supported by the board (for example, Adaptive Ambient Light
would need an Ambient Light Sensor, otherwise it's pointless!), other
than the output type.
Add support for OF graphs to most of the MediaTek DDP (display) bindings
to add flexibility to build custom hardware paths, hence enabling board
specific configuration of the display pipeline and allowing to finally
migrate away from using hardcoded paths.
Signed-off-by: AngeloGioacchino Del Regno
---
.../display/mediatek/mediatek,aal.yaml| 40 +++
.../display/mediatek/mediatek,ccorr.yaml | 21 ++
.../display/mediatek/mediatek,color.yaml | 22 ++
.../display/mediatek/mediatek,dither.yaml | 22 ++
.../display/mediatek/mediatek,dpi.yaml| 25 +++-
.../display/mediatek/mediatek,dsc.yaml| 24 +++
.../display/mediatek/mediatek,dsi.yaml| 27 -
.../display/mediatek/mediatek,ethdr.yaml | 22 ++
.../display/mediatek/mediatek,gamma.yaml | 19 +
.../display/mediatek/mediatek,merge.yaml | 23 +++
.../display/mediatek/mediatek,od.yaml | 22 ++
.../display/mediatek/mediatek,ovl-2l.yaml | 22 ++
.../display/mediatek/mediatek,ovl.yaml| 22 ++
.../display/mediatek/mediatek,postmask.yaml | 21 ++
.../display/mediatek/mediatek,rdma.yaml | 22 ++
.../display/mediatek/mediatek,ufoe.yaml | 21 ++
16 files changed, 372 insertions(+), 3 deletions(-)
diff --git
a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
index b4c28e96dd55..623cf7e37fe3 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
@@ -61,6 +61,27 @@ properties:
$ref: /schemas/types.yaml#/definitions/phandle-array
maxItems: 1
+ ports:
+$ref: /schemas/graph.yaml#/properties/ports
+description:
+ Input and output ports can have multiple endpoints, each of those
+ connects to either the primary, secondary, etc, display pipeline.
+
+properties:
+ port@0:
+$ref: /schemas/graph.yaml#/properties/port
+description: AAL input port
+
+ port@1:
+$ref: /schemas/graph.yaml#/properties/port
+description:
+ AAL output to the next component's input, for example could be one
+ of many gamma, overdrive or other blocks.
+
+required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
@@ -88,5 +109,24 @@ examples:
power-domains = < MT8173_POWER_DOMAIN_MM>;
clocks = < CLK_MM_DISP_AAL>;
mediatek,gce-client-reg = < SUBSYS_1401 0x5000 0x1000>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ aal0_in: endpoint {
+ remote-endpoint = <_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ aal0_out: endpoint {
+ remote-endpoint = <_in>;
+ };
+ };
+ };
};
};
diff --git
a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
index 8c2a737237f2..71ea277a5d8e 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
@@ -54,6 +54,27 @@ properties:
$ref: /schemas/types.yaml#/definitions/phandle-array
maxItems: 1
+ ports:
+$ref: /schemas/graph.yaml#/properties/ports
+description:
+ Input and output ports can have multiple endpoints, each of those
+ connects to either the primary, secondary, etc, display pipeline.
+
+properties:
+ port@0:
+$ref: /schemas/graph.yaml#/properties/port
+description: CCORR input port
+
+ port@1:
+$ref: /schemas/graph.yaml#/properties/port
+description:
+ CCORR output to the input of the next desired component in the
+ display pipeline, usually only one of the available AAL blocks.
+
+required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
diff --git
[PATCH v1 3/3] drm/mediatek: Implement OF graphs support for display paths
It is impossible to add each and every possible DDP path combination
for each and every possible combination of SoC and board: right now,
this driver hardcodes configuration for 10 SoCs and this is going to
grow larger and larger, and with new hacks like the introduction of
mtk_drm_route which is anyway not enough for all final routes as the
DSI cannot be connected to MERGE if it's not a dual-DSI, or enabling
DSC preventively doesn't work if the display doesn't support it, or
others.
Since practically all display IPs in MediaTek SoCs support being
interconnected with different instances of other, or the same, IPs
or with different IPs and in different combinations, the final DDP
pipeline is effectively a board specific configuration.
Implement OF graphs support to the mediatek-drm drivers, allowing to
stop hardcoding the paths, and preventing this driver to get a huge
amount of arrays for each board and SoC combination, also paving the
way to share the same mtk_mmsys_driver_data between multiple SoCs,
making it more straightforward to add support for new chips.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 16 +-
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 255 ++---
drivers/gpu/drm/mediatek/mtk_drm_drv.h | 2 +-
drivers/gpu/drm/mediatek/mtk_dsi.c | 10 +-
4 files changed, 250 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index beb7d9d08e97..c47648d244fe 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -705,6 +705,15 @@ static int mtk_dpi_bridge_attach(struct drm_bridge *bridge,
{
struct mtk_dpi *dpi = bridge_to_dpi(bridge);
+ dpi->next_bridge = devm_drm_of_get_bridge(dpi->dev, dpi->dev->of_node,
1, -1);
+ if (IS_ERR(dpi->next_bridge)) {
+ /* Old devicetree has only one endpoint */
+ dpi->next_bridge = devm_drm_of_get_bridge(dpi->dev,
dpi->dev->of_node, 0, 0);
+ if (IS_ERR(dpi->next_bridge))
+ return dev_err_probe(dpi->dev,
PTR_ERR(dpi->next_bridge),
+"Failed to get bridge\n");
+ }
+
return drm_bridge_attach(bridge->encoder, dpi->next_bridge,
>bridge, flags);
}
@@ -1055,13 +1064,6 @@ static int mtk_dpi_probe(struct platform_device *pdev)
if (dpi->irq < 0)
return dpi->irq;
- dpi->next_bridge = devm_drm_of_get_bridge(dev, dev->of_node, 0, 0);
- if (IS_ERR(dpi->next_bridge))
- return dev_err_probe(dev, PTR_ERR(dpi->next_bridge),
-"Failed to get bridge\n");
-
- dev_info(dev, "Found bridge node: %pOF\n", dpi->next_bridge->of_node);
-
platform_set_drvdata(pdev, dpi);
dpi->bridge.funcs = _dpi_bridge_funcs;
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index 2804bf0bc28d..7691aa7779c1 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -810,12 +810,200 @@ static const struct of_device_id mtk_ddp_comp_dt_ids[] =
{
{ }
};
+static int mtk_drm_of_get_ddp_comp_type(struct device_node *node, enum
mtk_ddp_comp_type *ctype)
+{
+ const struct of_device_id *of_id = of_match_node(mtk_ddp_comp_dt_ids,
node);
+
+ if (!of_id)
+ return -EINVAL;
+
+ *ctype = (enum mtk_ddp_comp_type)((uintptr_t)of_id->data);
+
+ return 0;
+}
+
+static int mtk_drm_of_get_ddp_ep_cid(struct device_node *node,
+int output_port, enum mtk_drm_crtc_path
crtc_path,
+struct device_node **next, unsigned int
*cid)
+{
+ struct device_node *ep_dev_node, *ep_out;
+ enum mtk_ddp_comp_type comp_type;
+ int ret;
+
+ ep_out = of_graph_get_endpoint_by_regs(node, output_port, crtc_path);
+ if (!ep_out)
+ return -ENOENT;
+
+ ep_dev_node = of_graph_get_remote_port_parent(ep_out);
+ if (!ep_dev_node)
+ return -EINVAL;
+
+ /*
+* Pass the next node pointer regardless of failures in the later code
+* so that if this function is called in a loop it will walk through all
+* of the subsequent endpoints anyway.
+*/
+ *next = ep_dev_node;
+
+ if (!of_device_is_available(ep_dev_node))
+ return -ENODEV;
+
+ ret = mtk_drm_of_get_ddp_comp_type(ep_dev_node, _type);
+ if (ret)
+ return ret;
+
+ ret = mtk_ddp_comp_get_id(ep_dev_node, comp_type);
+ if (ret < 0)
+ return ret;
+
+ /* All ok! Pass the Component ID to the caller. */
+ *cid = (unsigned int)ret;
+
+ return 0;
+}
+
+/**
+ * mtk_drm_of_ddp_path_build_one - Build a Display HW Pipeline for a CRTC Path
+ * @dev: The mediatek-drm
[PATCH v1 2/3] dt-bindings: arm: mediatek: mmsys: Add OF graph support for board path
Document OF graph on MMSYS/VDOSYS: this supports up to three DDP paths per HW instance (so potentially up to six displays for multi-vdo SoCs). The MMSYS or VDOSYS is always the first component in the DDP pipeline, so it only supports an output port with multiple endpoints - where each endpoint defines the starting point for one of the (currently three) possible hardware paths. Signed-off-by: AngeloGioacchino Del Regno --- .../bindings/arm/mediatek/mediatek,mmsys.yaml | 23 +++ 1 file changed, 23 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml index b3c6888c1457..90758bb5bcb1 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml @@ -93,6 +93,29 @@ properties: '#reset-cells': const: 1 + port: +$ref: /schemas/graph.yaml#/properties/port +description: + Output port node. This port connects the MMSYS/VDOSYS output to + the first component of one display pipeline, for example one of + the available OVL or RDMA blocks. + Some MediaTek SoCs support up to three display outputs per MMSYS. +properties: + endpoint@0: +$ref: /schemas/graph.yaml#/properties/endpoint +description: Output to the primary display pipeline + + endpoint@1: +$ref: /schemas/graph.yaml#/properties/endpoint +description: Output to the secondary display pipeline + + endpoint@2: +$ref: /schemas/graph.yaml#/properties/endpoint +description: Output to the tertiary display pipeline + + required: +- endpoint@0 + required: - compatible - reg -- 2.44.0
[PATCH v1 0/3] drm/mediatek: Add support for OF graphs
The display IPs in MediaTek SoCs are *VERY* flexible and those support being interconnected with different instances of DDP IPs (for example, merge0 or merge1) and/or with different DDP IPs (for example, rdma can be connected with either color, dpi, dsi, merge, etc), forming a full Display Data Path that ends with an actual display. This series was born because of an issue that I've found while enabling support for MT8195/MT8395 boards with DSI output as main display: the current mtk_drm_route variations would not work as currently, the driver hardcodes a display path for Chromebooks, which have a DisplayPort panel with DSC support, instead of a DSI panel without DSC support. There are other reasons for which I wrote this series, and I find that hardcoding those paths - when a HW path is clearly board-specific - is highly suboptimal. Also, let's not forget about keeping this driver from becoming a huge list of paths for each combination of SoC->board->disp and... this and that. For more information, please look at the commit description for each of the commits included in this series. Please don't mind about the missing OVL_ADAPTOR support for OF graphs in this series: that needs a bit more thinking and a bit more work, and will come in a second series that will go on top of this a bit later, as the OF graph support for *at least* the primary display is essential *right now* to enable support for the MT8195/8395 EVK, Kontron SoM, Radxa NIO-12L and all of the other non-Chromebook boards to co-exist with Chromebooks. Besides, this is also a valid option for MT8188 Chromebooks which might have different DSI-or-eDP displays depending on the model (as far as I can see from the mtk_drm_route attempt for this SoC that is already present in this driver). This series was tested on MT8195 Cherry Tomato and on MT8395 Radxa NIO-12L with both hardcoded paths, OF graph support and partially hardcoded paths (meaning main display through OF graph and external display hardcoded, because of OVL_ADAPTOR). AngeloGioacchino Del Regno (3): dt-bindings: display: mediatek: Add OF graph support for board path dt-bindings: arm: mediatek: mmsys: Add OF graph support for board path drm/mediatek: Implement OF graphs support for display paths .../bindings/arm/mediatek/mediatek,mmsys.yaml | 23 ++ .../display/mediatek/mediatek,aal.yaml| 40 +++ .../display/mediatek/mediatek,ccorr.yaml | 21 ++ .../display/mediatek/mediatek,color.yaml | 22 ++ .../display/mediatek/mediatek,dither.yaml | 22 ++ .../display/mediatek/mediatek,dpi.yaml| 25 +- .../display/mediatek/mediatek,dsc.yaml| 24 ++ .../display/mediatek/mediatek,dsi.yaml| 27 +- .../display/mediatek/mediatek,ethdr.yaml | 22 ++ .../display/mediatek/mediatek,gamma.yaml | 19 ++ .../display/mediatek/mediatek,merge.yaml | 23 ++ .../display/mediatek/mediatek,od.yaml | 22 ++ .../display/mediatek/mediatek,ovl-2l.yaml | 22 ++ .../display/mediatek/mediatek,ovl.yaml| 22 ++ .../display/mediatek/mediatek,postmask.yaml | 21 ++ .../display/mediatek/mediatek,rdma.yaml | 22 ++ .../display/mediatek/mediatek,ufoe.yaml | 21 ++ drivers/gpu/drm/mediatek/mtk_dpi.c| 16 +- drivers/gpu/drm/mediatek/mtk_drm_drv.c| 255 -- drivers/gpu/drm/mediatek/mtk_drm_drv.h| 2 +- drivers/gpu/drm/mediatek/mtk_dsi.c| 10 +- 21 files changed, 645 insertions(+), 36 deletions(-) -- 2.44.0
[PATCH v2 3/3] drm/mediatek: drm_ddp_comp: Add mtk_ddp_is_simple_comp() internal helper
Move the simple component check to a new mtk_ddp_is_simple_comp()
internal helper to reduce code duplication.
Signed-off-by: AngeloGioacchino Del Regno
Reviewed-by: CK Hu
---
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 57 +++--
1 file changed, 31 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index 477fc1950a0e..d760285761b9 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -576,6 +576,29 @@ unsigned int mtk_drm_find_possible_crtc_by_comp(struct
drm_device *drm,
return ret;
}
+static bool mtk_ddp_is_simple_comp(enum mtk_ddp_comp_type type)
+{
+ switch (type) {
+ case MTK_DISP_AAL:
+ case MTK_DISP_BLS:
+ case MTK_DISP_CCORR:
+ case MTK_DISP_COLOR:
+ case MTK_DISP_GAMMA:
+ case MTK_DISP_MERGE:
+ case MTK_DISP_OVL:
+ case MTK_DISP_OVL_2L:
+ case MTK_DISP_OVL_ADAPTOR:
+ case MTK_DISP_PWM:
+ case MTK_DISP_RDMA:
+ case MTK_DP_INTF:
+ case MTK_DPI:
+ case MTK_DSI:
+ return false;
+ default:
+ return true;
+ }
+}
+
int mtk_ddp_comp_init(struct device_node *node, struct mtk_ddp_comp *comp,
unsigned int comp_id)
{
@@ -606,19 +629,13 @@ int mtk_ddp_comp_init(struct device_node *node, struct
mtk_ddp_comp *comp,
}
comp->dev = _pdev->dev;
- if (type == MTK_DISP_AAL ||
- type == MTK_DISP_BLS ||
- type == MTK_DISP_CCORR ||
- type == MTK_DISP_COLOR ||
- type == MTK_DISP_GAMMA ||
- type == MTK_DISP_MERGE ||
- type == MTK_DISP_OVL ||
- type == MTK_DISP_OVL_2L ||
- type == MTK_DISP_PWM ||
- type == MTK_DISP_RDMA ||
- type == MTK_DPI ||
- type == MTK_DP_INTF ||
- type == MTK_DSI)
+ /*
+* Resources for simple components are retrieved here as those are
+* managed in here without the need of more complex drivers; for
+* the latter, their respective probe function will do the job, so
+* we must avoid getting their resources here.
+*/
+ if (!mtk_ddp_is_simple_comp(type))
return 0;
priv = devm_kzalloc(comp->dev, sizeof(*priv), GFP_KERNEL);
@@ -652,19 +669,7 @@ void mtk_ddp_comp_destroy(struct mtk_ddp_comp *comp)
return;
/* Complex components are destroyed with their own remove callback */
- if (mtk_ddp_matches[comp->id].type == MTK_DISP_AAL ||
- mtk_ddp_matches[comp->id].type == MTK_DISP_BLS ||
- mtk_ddp_matches[comp->id].type == MTK_DISP_CCORR ||
- mtk_ddp_matches[comp->id].type == MTK_DISP_COLOR ||
- mtk_ddp_matches[comp->id].type == MTK_DISP_GAMMA ||
- mtk_ddp_matches[comp->id].type == MTK_DISP_MERGE ||
- mtk_ddp_matches[comp->id].type == MTK_DISP_OVL ||
- mtk_ddp_matches[comp->id].type == MTK_DISP_OVL_2L ||
- mtk_ddp_matches[comp->id].type == MTK_DISP_PWM ||
- mtk_ddp_matches[comp->id].type == MTK_DISP_RDMA ||
- mtk_ddp_matches[comp->id].type == MTK_DPI ||
- mtk_ddp_matches[comp->id].type == MTK_DP_INTF ||
- mtk_ddp_matches[comp->id].type == MTK_DSI)
+ if (!mtk_ddp_is_simple_comp(mtk_ddp_matches[comp->id].type))
return;
priv = dev_get_drvdata(comp->dev);
--
2.44.0
