Re: [PATCH v3 1/6] drm: move the buddy allocator from i915 into common drm

2021-11-17 Thread Christian König
I've looked a bit more into this and I think we should just follow Thomas Zimmermann's idea to make this a separate module. Otherwise we just have the code around all the time even if it is unused and implementing this should be trivial. See how DRM_GEM_CMA_HELPER or DRM_VRAM_HELPER are done

Re: [PATCH] drm/panel-edp: modify Kconfig to prevent build error

2021-11-17 Thread Arnd Bergmann
On Wed, Nov 17, 2021 at 7:27 AM Randy Dunlap wrote: > > When CONFIG_DRM_KMS_HELPER=m and CONFIG_DRM_PANEL_EDP=y, > there is a build error in gpu/drm/panel/panel-edp.o: > > arm-linux-gnueabi-ld: drivers/gpu/drm/panel/panel-edp.o: in function > `panel_edp_probe': > panel-edp.c:(.text+0xf38): undefi

Re: [PATCH] lontium-lt9611: check a different register bit for HDMI sensing

2021-11-17 Thread Anibal Limon
Dmitry, May be this is the reason of my HP monitor not working in RB5. Regards, Anibal El mar., 16 de noviembre de 2021 20:07, Peter Collingbourne escribió: > It has been observed that with certain monitors such as the HP Z27n, > the register 0x825e reads a value of 0x79 when the HDMI cable is

Re: [PATCH 0/6] drm/vc4: kms: Misc fixes for HVS commits

2021-11-17 Thread Jian-Hong Pan
Maxime Ripard 於 2021年11月15日 週一 下午7:31寫道: > > Hi, > > The conversion to DRM commit helpers (f3c420fe19f8, "drm/vc4: kms: Convert to > atomic helpers") introduced a number of issues in corner cases, most of them > showing themselves in the form of either a vblank timeout or use-after-free > error. >

Re: Build regressions/improvements in v5.16-rc1

2021-11-17 Thread Geert Uytterhoeven
Hi Nick, On Wed, Nov 17, 2021 at 3:20 AM Nick Terrell wrote: > > On Nov 16, 2021, at 6:05 PM, Randy Dunlap wrote: > > On 11/16/21 5:59 PM, Nick Terrell wrote: > >> I’ll send the PR to Linus tomorrow. I’ve been informed that it > >> isn't strictly necessary to send the patches to the mailing list

Re: [PATCH 0/6] drm/vc4: kms: Misc fixes for HVS commits

2021-11-17 Thread Maxime Ripard
Hi, On Wed, Nov 17, 2021 at 03:08:31PM +0800, Jian-Hong Pan wrote: > Maxime Ripard 於 2021年11月15日 週一 下午7:31寫道: > > > > Hi, > > > > The conversion to DRM commit helpers (f3c420fe19f8, "drm/vc4: kms: Convert > > to > > atomic helpers") introduced a number of issues in corner cases, most of them > >

Re: [PATCH 00/15] iio: buffer-dma: write() and new DMABUF based API

2021-11-17 Thread Christian König
Am 16.11.21 um 17:31 schrieb Laurent Pinchart: On Tue, Nov 16, 2021 at 05:02:25PM +0100, Daniel Vetter wrote: On Mon, Nov 15, 2021 at 02:57:37PM +, Paul Cercueil wrote: Le lun., nov. 15 2021 at 15:37:16 +0100, Daniel Vetter a écrit : On Mon, Nov 15, 2021 at 02:19:10PM +, Paul Cercueil

Re: [PATCH 0/6] drm/vc4: kms: Misc fixes for HVS commits

2021-11-17 Thread Maxime Ripard
On Wed, Nov 17, 2021 at 09:24:54AM +0100, Maxime Ripard wrote: > Hi, > > On Wed, Nov 17, 2021 at 03:08:31PM +0800, Jian-Hong Pan wrote: > > Maxime Ripard 於 2021年11月15日 週一 下午7:31寫道: > > > > > > Hi, > > > > > > The conversion to DRM commit helpers (f3c420fe19f8, "drm/vc4: kms: > > > Convert to > >

[PATCH v8 04/22] dt-bindings: reset: mt8195: add vdosys1 reset control bit

2021-11-17 Thread Nancy . Lin
Add vdosys1 reset control bit for MT8195 platform. Signed-off-by: Nancy.Lin Reviewed-by: Chun-Kuang Hu --- include/dt-bindings/reset/mt8195-resets.h | 12 1 file changed, 12 insertions(+) diff --git a/include/dt-bindings/reset/mt8195-resets.h b/include/dt-bindings/reset/mt8195-re

[PATCH v8 01/22] dt-bindings: mediatek: add vdosys1 RDMA definition for mt8195

2021-11-17 Thread Nancy . Lin
Add vdosys1 RDMA definition. Signed-off-by: Nancy.Lin --- .../arm/mediatek/mediatek,mdp-rdma.yaml | 77 +++ 1 file changed, 77 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,mdp-rdma.yaml diff --git a/Documentation/devicetree/bi

[PATCH v8 14/22] drm/mediatek: add display merge start/stop API for cmdq support

2021-11-17 Thread Nancy . Lin
Add merge start/stop API for cmdq support. The ovl_adaptor merges are configured with each drm plane update. Need to enable/disable merge with cmdq making sure all the settings taken effect in the same vblank. Signed-off-by: Nancy.Lin Reviewed-by: Chun-Kuang Hu --- drivers/gpu/drm/mediatek/mtk_

[PATCH v8 09/22] soc: mediatek: mmsys: modify reset controller for MT8195 vdosys1

2021-11-17 Thread Nancy . Lin
MT8195 vdosys1 has more than 32 reset bits and a different reset base than other chips. Modify mmsys for support 64 bit and different reset base. Signed-off-by: Nancy.Lin --- drivers/soc/mediatek/mt8195-mmsys.h | 1 + drivers/soc/mediatek/mtk-mmsys.c| 21 - drivers/soc/m

[PATCH v8 07/22] soc: mediatek: add mtk-mmsys config API for mt8195 vdosys1

2021-11-17 Thread Nancy . Lin
Add mmsys config API. The config API is used for config mmsys reg. Some mmsys regs need to be setting according to the HW engine binding to the mmsys simultaneously. Signed-off-by: Nancy.Lin --- drivers/soc/mediatek/mt8195-mmsys.h| 62 ++ drivers/soc/mediatek/mtk-mmsy

[PATCH v8 18/22] drm/mediatek: add mediatek-drm plane color encoding info

2021-11-17 Thread Nancy . Lin
Add plane color encoding information for color space conversion. It's a preparation for adding support for mt8195 ovl_adaptor mdp_rdma csc control. Signed-off-by: Nancy.Lin Reviewed-by: Chun-Kuang Hu --- drivers/gpu/drm/mediatek/mtk_drm_plane.c | 1 + drivers/gpu/drm/mediatek/mtk_drm_plane.h |

[PATCH v8 05/22] arm64: dts: mt8195: add display node for vdosys1

2021-11-17 Thread Nancy . Lin
Add display node for vdosys1. Signed-off-by: Nancy.Lin --- arch/arm64/boot/dts/mediatek/mt8195.dtsi | 222 +++ 1 file changed, 222 insertions(+) diff --git a/arch/arm64/boot/dts/mediatek/mt8195.dtsi b/arch/arm64/boot/dts/mediatek/mt8195.dtsi index e136761345db..a69a7b57e070

[PATCH v8 08/22] soc: mediatek: add cmdq support of mtk-mmsys config API for mt8195 vdosys1

2021-11-17 Thread Nancy . Lin
Add cmdq support for mtk-mmsys config API. The mmsys config register settings need to take effect with the other HW settings(like OVL_ADAPTOR...) at the same vblanking time. If we use CPU to write the mmsys reg, we can't guarantee all the settings can be written in the same vblanking time. Cmdq is

[PATCH v8 20/22] drm/mediatek: modify mediatek-drm for mt8195 multi mmsys support

2021-11-17 Thread Nancy . Lin
MT8195 have two mmsys. Modify drm for MT8195 multi-mmsys support. The two mmsys (vdosys0 and vdosys1) will bring up two drm drivers, only one drm driver register as the drm device. Each drm driver binds its own component. The last bind drm driver allocates and registers the drm device to drm core.

[PATCH v8 02/22] dt-bindings: mediatek: add vdosys1 MERGE property for mt8195

2021-11-17 Thread Nancy . Lin
MT8195 vdosys1 merge1 to merge4 have HW mute function. Add MERGE additional mute property description. Signed-off-by: Nancy.Lin Reviewed-by: Chun-Kuang Hu Acked-By: AngeloGioacchino Del Regno --- .../devicetree/bindings/display/mediatek/mediatek,merge.yaml | 4 1 file changed, 4 insertio

[PATCH v8 00/22] Add MediaTek SoC DRM (vdosys1) support for mt8195

2021-11-17 Thread Nancy . Lin
The hardware path of vdosys1 with DPTx output need to go through by several modules, such as, OVL_ADAPTOR and MERGE. Add DRM and these modules support by the patches below: Changes in v8: - separate merge async reset to new patch. - separate drm ovl_adaptor sub driver to new patch. - fix reviewe

[PATCH v8 13/22] drm/mediatek: add display merge advance config API for MT8195

2021-11-17 Thread Nancy . Lin
Add merge new advance config API. The original merge API is mtk_ddp_comp_funcs function prototype. The API interface parameters cannot be modified, so add a new config API for extension. This is the preparation for ovl_adaptor merge control. Signed-off-by: Nancy.Lin Reviewed-by: Chun-Kuang Hu --

[PATCH v8 17/22] drm/mediatek: add ETHDR support for MT8195

2021-11-17 Thread Nancy . Lin
ETHDR is a part of ovl_adaptor. ETHDR is designed for HDR video and graphics conversion in the external display path. It handles multiple HDR input types and performs tone mapping, color space/color format conversion, and then combine different layers, output the required HDR or SDR signal to the s

[PATCH v8 03/22] dt-bindings: mediatek: add ethdr definition for mt8195

2021-11-17 Thread Nancy . Lin
Add vdosys1 ETHDR definition. Signed-off-by: Nancy.Lin Reviewed-by: Chun-Kuang Hu --- .../display/mediatek/mediatek,ethdr.yaml | 147 ++ 1 file changed, 147 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml diff --git

[PATCH v8 21/22] drm/mediatek: add drm ovl_adaptor sub driver for MT8195

2021-11-17 Thread Nancy . Lin
Add drm ovl_adaptor sub driver. Bring up ovl_adaptor sub driver if the component exists in the path. Signed-off-by: Nancy.Lin --- drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 16 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 30 --- drivers/gpu/drm/mediatek/mtk_drm_ddp_comp

[PATCH v8 19/22] drm/mediatek: add ovl_adaptor support for MT8195

2021-11-17 Thread Nancy . Lin
Add ovl_adaptor driver for MT8195. Ovl_adaptor is an encapsulated module and designed for simplified DRM control flow. This module is composed of 8 RDMAs, 4 MERGEs and an ETHDR. Two RDMAs merge into one layer, so this module support 4 layers. Signed-off-by: Nancy.Lin Reviewed-by: Chun-Kuang Hu -

[PATCH v8 06/22] soc: mediatek: add mtk-mmsys support for mt8195 vdosys1

2021-11-17 Thread Nancy . Lin
Add mt8195 vdosys1 clock driver name and routing table to the driver data of mtk-mmsys. Signed-off-by: Nancy.Lin --- drivers/soc/mediatek/mt8195-mmsys.h| 136 + drivers/soc/mediatek/mtk-mmsys.c | 10 ++ include/linux/soc/mediatek/mtk-mmsys.h | 2 + 3 files ch

[PATCH v8 11/22] soc: mediatek: add mtk-mutex support for mt8195 vdosys1

2021-11-17 Thread Nancy . Lin
Add mtk-mutex support for mt8195 vdosys1. The vdosys1 path component contains ovl_adaptor, merge5, and dp_intf1. Ovl_adaptor is composed of several sub-elements. Signed-off-by: Nancy.Lin --- drivers/soc/mediatek/mtk-mutex.c | 54 1 file changed, 54 insertions(+)

[PATCH v8 22/22] drm/mediatek: add mediatek-drm of vdosys1 support for MT8195

2021-11-17 Thread Nancy . Lin
Add driver data of mt8195 vdosys1 to mediatek-drm. Signed-off-by: Nancy.Lin --- drivers/gpu/drm/mediatek/mtk_drm_drv.c | 18 ++ 1 file changed, 18 insertions(+) diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c index 96f505b2e571..a333

[PATCH v8 16/22] drm/mediatek: add display merge async reset control

2021-11-17 Thread Nancy . Lin
Add merge async reset control in mtk_merge_stop. Async hw doesn't do self reset on each sof signal(start of frame), so need to reset the async to clear the hw status for the next merge start. Signed-off-by: Nancy.Lin --- drivers/gpu/drm/mediatek/mtk_disp_merge.c | 4 1 file changed, 4 inser

[PATCH v8 10/22] soc: mediatek: change the mutex defines and the mutex_mod type

2021-11-17 Thread Nancy . Lin
This is a preparation for adding support for mt8195 vdosys1 mutex. The vdosys1 path component contains ovl_adaptor, merge5, and dp_intf1. Ovl_adaptor is composed of several sub-elements, so change it to support multi-bit control. Signed-off-by: Nancy.Lin --- drivers/soc/mediatek/mtk-mutex.c | 24

[PATCH v8 15/22] drm/mediatek: add display merge mute/unmute support for MT8195

2021-11-17 Thread Nancy . Lin
Add merge mute/unmute setting for MT8195. MT8195 Vdosys1 merge1~merge4 support HW mute function. Signed-off-by: Nancy.Lin Reviewed-by: Chun-Kuang Hu --- drivers/gpu/drm/mediatek/mtk_disp_merge.c | 23 ++- 1 file changed, 18 insertions(+), 5 deletions(-) diff --git a/drivers

[PATCH v8 12/22] drm/mediatek: add display MDP RDMA support for MT8195

2021-11-17 Thread Nancy . Lin
Add MDP_RDMA driver for MT8195. MDP_RDMA is the DMA engine of the ovl_adaptor component. Signed-off-by: Nancy.Lin Reviewed-by: Chun-Kuang Hu --- drivers/gpu/drm/mediatek/Makefile | 3 +- drivers/gpu/drm/mediatek/mtk_disp_drv.h | 7 + drivers/gpu/drm/mediatek/mtk_mdp_rdma.c | 316 +

[PATCH v2 1/6] drm/vc4: kms: Wait for the commit before increasing our clock rate

2021-11-17 Thread Maxime Ripard
Several DRM/KMS atomic commits can run in parallel if they affect different CRTC. These commits share the global HVS state, so we have some code to make sure we run commits in sequence. This synchronization code is one of the first thing that runs in vc4_atomic_commit_tail(). Another constraints w

[PATCH v2 0/6] drm/vc4: kms: Misc fixes for HVS commits

2021-11-17 Thread Maxime Ripard
Hi, The conversion to DRM commit helpers (f3c420fe19f8, "drm/vc4: kms: Convert to atomic helpers") introduced a number of issues in corner cases, most of them showing themselves in the form of either a vblank timeout or use-after-free error. These patches should fix most of them, some of them sti

[PATCH v2 4/6] drm/vc4: kms: Clear the HVS FIFO commit pointer once done

2021-11-17 Thread Maxime Ripard
Commit 9ec03d7f1ed3 ("drm/vc4: kms: Wait on previous FIFO users before a commit") introduced a wait on the previous commit done on a given HVS FIFO. However, we never cleared that pointer once done. Since drm_crtc_commit_put can free the drm_crtc_commit structure directly if we were the last user,

[PATCH v2 2/6] drm/vc4: kms: Fix return code check

2021-11-17 Thread Maxime Ripard
The HVS global state functions return an error pointer, but in most cases we check if it's NULL, possibly resulting in an invalid pointer dereference. Fixes: 9ec03d7f1ed3 ("drm/vc4: kms: Wait on previous FIFO users before a commit") Signed-off-by: Maxime Ripard --- drivers/gpu/drm/vc4/vc4_kms.c

[PATCH v2 3/6] drm/vc4: kms: Add missing drm_crtc_commit_put

2021-11-17 Thread Maxime Ripard
Commit 9ec03d7f1ed3 ("drm/vc4: kms: Wait on previous FIFO users before a commit") introduced a global state for the HVS, with each FIFO storing the current CRTC commit so that we can properly synchronize commits. However, the refcounting was off and we thus ended up leaking the drm_crtc_commit str

[PATCH v2 5/6] drm/vc4: kms: Don't duplicate pending commit

2021-11-17 Thread Maxime Ripard
Our HVS global state, when duplicated, will also copy the pointer to the drm_crtc_commit (and increase the reference count) for each FIFO if the pointer is not NULL. However, our atomic_setup function will overwrite that pointer without putting the reference back leading to a memory leak. Since t

[PATCH v2 6/6] drm/vc4: kms: Fix previous HVS commit wait

2021-11-17 Thread Maxime Ripard
Our current code is supposed to serialise the commits by waiting for all the drm_crtc_commits associated to the previous HVS state. However, assuming we have two CRTCs running and being configured and we configure each one alternatively, we end up in a situation where we're not waiting at all. In

Re: [PATCH 02/13] drm/connector: Add helper to check if a mode requires scrambling

2021-11-17 Thread Maxime Ripard
On Mon, Nov 08, 2021 at 07:55:00PM +0200, Ville Syrjälä wrote: > On Mon, Nov 08, 2021 at 04:58:34PM +0100, Maxime Ripard wrote: > > On Fri, Nov 05, 2021 at 08:14:04PM +0200, Ville Syrjälä wrote: > > > On Fri, Nov 05, 2021 at 07:02:30PM +0100, Daniel Vetter wrote: > > > > On Thu, Nov 04, 2021 at 05:

[PATCH] drm/msm/devfreq: Insert missing null check in msm_devfreq_idle

2021-11-17 Thread Marijn Suijten
msm_devfreq_init only initializes the idle_work hrtimer when it succeeds to create a devfreq instance (devfreq support is optional), yet msm_devfreq_idle is called unconditionally from retire_submit and queues work on it. We're seeing: [2.005265] adreno 1c0.gpu: [drm:msm_devfreq_init]

Re: Build regressions/improvements in v5.16-rc1

2021-11-17 Thread Helge Deller
On 11/17/21 03:19, Nick Terrell wrote: > > >> On Nov 16, 2021, at 6:05 PM, Randy Dunlap wrote: >> >> On 11/16/21 5:59 PM, Nick Terrell wrote: On Nov 15, 2021, at 8:44 AM, Helge Deller wrote: On 11/15/21 17:12, Geert Uytterhoeven wrote: > On Mon, Nov 15, 2021 at 4:54 PM Geert Uy

Re: [PATCH 1/6] drm/i915: move the pre_pin earlier

2021-11-17 Thread Thomas Hellström
On Fri, 2021-11-12 at 15:32 +, Matthew Auld wrote: > In intel_context_do_pin_ww, when calling into the pre_pin hook(which > is > passed the ww context) it could in theory return -EDEADLK(which is > very > likely with debug kernels), once we start adding more ww locking in > there, > like in the

[PATCH] video: omapfb: Use scnprintf() instead of snprintf()

2021-11-17 Thread Guo Zhengkui
Fix following warnings: ./drivers/video/fbdev/omap/omapfb_main.c:1382:8-16: WARNING: use scnprintf or sprintf ./drivers/video/fbdev/omap/omapfb_main.c:1306:8-16: WARNING: use scnprintf or sprintf Signed-off-by: Guo Zhengkui --- drivers/video/fbdev/omap/omapfb_main.c | 8 1 file changed,

[PATCH] video: omapfb: Use scnprintf() instead of snprintf()

2021-11-17 Thread Guo Zhengkui
Fix following warnings: ./drivers/video/fbdev/omap/omapfb_main.c:1382:8-16: WARNING: use scnprintf or sprintf ./drivers/video/fbdev/omap/omapfb_main.c:1306:8-16: WARNING: use scnprintf or sprintf Signed-off-by: Guo Zhengkui --- drivers/video/fbdev/omap/omapfb_main.c | 8 1 file changed,

Re: [PATCH 00/15] iio: buffer-dma: write() and new DMABUF based API

2021-11-17 Thread Paul Cercueil
Hi Daniel, Le mar., nov. 16 2021 at 17:02:25 +0100, Daniel Vetter a écrit : On Mon, Nov 15, 2021 at 02:57:37PM +, Paul Cercueil wrote: Hi Daniel, Le lun., nov. 15 2021 at 15:37:16 +0100, Daniel Vetter a écrit : > On Mon, Nov 15, 2021 at 02:19:10PM +, Paul Cercueil wrote: > >

[PATCH 0/2] More preparation for multi gt patches

2021-11-17 Thread Andi Shyti
Hi, the first of the two patches concludes the first stage of refactoring which makes the use of intel_gt on the different subsystem. It's taken from Matt's series and it has alread been reviewed. The patch has just been replaced before any multitile patches and I think it can be already pushed.

[PATCH 1/2] drm/i915: Store backpointer to GT in uncore

2021-11-17 Thread Andi Shyti
From: Michał Winiarski We now support a per-gt uncore, yet we're not able to infer which GT we're operating upon. Let's store a backpointer for now. Signed-off-by: Michał Winiarski Signed-off-by: Matt Roper Reviewed-by: Andi Shyti Signed-off-by: Andi Shyti --- drivers/gpu/drm/i915/i915_dri

[PATCH 2/2] drm/i915: Rename gt to gt0

2021-11-17 Thread Andi Shyti
In preparation to the upcoming multitile commits, embed the gt id in the GT 0 in the drm_i915_private structure. Signed-off-by: Andi Shyti Cc: Chris Wilson Cc: Joonas Lahtinen Cc: Lucas De Marchi Cc: Rodrigo Vivi Cc: Tvrtko Ursulin --- .../gpu/drm/i915/display/intel_atomic_plane.c | 4 +-

[bug report] drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP

2021-11-17 Thread Dan Carpenter
Hello Xin Ji, The patch 8bdfc5dae4e3: "drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP" from Sep 18, 2020, leads to the following Smatch static checker warning: drivers/gpu/drm/bridge/analogix/anx7625.c:1050 anx7625_init_gpio() warn: 'platform->pdata.gpio_p_on' could be an err

[PATCH 1/3] drm/fourcc: Add packed 10bit YUV 4:2:0 format

2021-11-17 Thread Maxime Ripard
From: Dave Stevenson Adds a format that is 3 10bit YUV 4:2:0 samples packed into a 32bit work (with 2 spare bits). Supported on Broadcom BCM2711 chips. Signed-off-by: Dave Stevenson Signed-off-by: Maxime Ripard --- drivers/gpu/drm/drm_fourcc.c | 3 +++ include/uapi/drm/drm_fourcc.h | 11 ++

[PATCH 0/3] drm/vc4: Support for 30 bits YUV formats

2021-11-17 Thread Maxime Ripard
Hi, Here are a few patches adding support for the P030 and the BT709 and BT2020 colorspaces. Let me know what you think, Maxime Dave Stevenson (3): drm/fourcc: Add packed 10bit YUV 4:2:0 format drm/vc4: plane: Add support for DRM_FORMAT_P030 drm/vc4: plane: Add support for YUV color encodi

[PATCH 3/3] drm/vc4: plane: Add support for YUV color encodings and ranges

2021-11-17 Thread Maxime Ripard
From: Dave Stevenson The BT601/BT709 color encoding and limited vs full range properties were not being exposed, defaulting always to BT601 limited range. Expose the parameters and set the registers appropriately. Signed-off-by: Dave Stevenson Signed-off-by: Maxime Ripard --- drivers/gpu/drm

[PATCH 2/3] drm/vc4: plane: Add support for DRM_FORMAT_P030

2021-11-17 Thread Maxime Ripard
From: Dave Stevenson The P030 format, used with the DRM_FORMAT_MOD_BROADCOM_SAND128 modifier, is a format output by the video decoder on the BCM2711. Add native support to the KMS planes for that format. Signed-off-by: Dave Stevenson Signed-off-by: Maxime Ripard --- drivers/gpu/drm/vc4/vc4_p

Re: [PATCH] drm/msm/devfreq: Insert missing null check in msm_devfreq_idle

2021-11-17 Thread AngeloGioacchino Del Regno
Il 17/11/21 12:11, Marijn Suijten ha scritto: msm_devfreq_init only initializes the idle_work hrtimer when it succeeds to create a devfreq instance (devfreq support is optional), yet msm_devfreq_idle is called unconditionally from retire_submit and queues work on it. We're seeing: [2.0

[PATCH v7 0/9] drm/omap: Add virtual-planes support

2021-11-17 Thread Neil Armstrong
This patchset is the follow-up the v4 patchset from Benoit Parrot at [1]. This patch series adds virtual-plane support to omapdrm driver to allow the use of display wider than 2048 pixels. In order to do so we introduce the concept of hw_overlay which can then be dynamically allocated to a plane.

[PATCH v7 2/9] drm/omap: Add ability to check if requested plane modes can be supported

2021-11-17 Thread Neil Armstrong
From: Benoit Parrot We currently assume that an overlay has the same maximum width and maximum height as the overlay manager. This assumption is incorrect. On some variants the overlay manager maximum width is twice the maximum width that the overlay can handle. We need to add the appropriate dat

[PATCH v7 3/9] drm/omap: Add ovl checking funcs to dispc_ops

2021-11-17 Thread Neil Armstrong
From: Benoit Parrot In order to be able to dynamically assign overlays to planes we need to be able to asses the overlay capabilities. Add a helper function to be able to retrieve the supported capabilities of an overlay. And export the function to check if a fourcc is supported on a given over

[PATCH v7 6/9] drm/omap: Add global state as a private atomic object

2021-11-17 Thread Neil Armstrong
From: Benoit Parrot Global shared resources (like hw overlays) for omapdrm are implemented as a part of atomic state using the drm_private_obj infrastructure available in the atomic core. omap_global_state is introduced as a drm atomic private object. The two funcs omap_get_global_state() and om

[PATCH v7 1/9] drm/omap: add sanity plane state check

2021-11-17 Thread Neil Armstrong
Call drm_atomic_helper_check_plane_state() from the plane atomic_check() callback in order to add plane state sanity checking. It will permit filtering out totally bad scaling factors, even if the real check are done later in the atomic commit. Calling drm_atomic_helper_check_plane_state() also s

[PATCH v7 4/9] drm/omap: introduce omap_hw_overlay

2021-11-17 Thread Neil Armstrong
From: Benoit Parrot Split out the hardware overlay specifics from omap_plane. To start, the hw overlays are statically assigned to planes. The goal is to eventually assign hw overlays dynamically to planes during plane->atomic_check() based on requested caps (scaling, YUV, etc). And then perform

[PATCH v7 5/9] drm/omap: omap_plane: subclass drm_plane_state

2021-11-17 Thread Neil Armstrong
From: Benoit Parrot In preparation to add omap plane state specific extensions we need to subclass drm_plane_state and add the relevant helpers. The addition of specific extension will be done separately. Signed-off-by: Benoit Parrot Signed-off-by: Neil Armstrong Reviewed-by: Tomi Valkeinen

[PATCH v7 7/9] drm/omap: dynamically assign hw overlays to planes

2021-11-17 Thread Neil Armstrong
From: Benoit Parrot (re)assign the hw overlays to planes based on required caps, and to handle situations where we could not modify an in-use plane. This means all planes advertise the superset of formats and properties. Userspace must (as always) use atomic TEST_ONLY step for atomic updates, as

[PATCH v7 9/9] drm/omap: Add a 'right overlay' to plane state

2021-11-17 Thread Neil Armstrong
From: Benoit Parrot If the drm_plane has a source width that's greater than the max width supported by a single hw overlay, then we assign a 'r_overlay' to it in omap_plane_atomic_check(). Both overlays should have the capabilities required to handle the source framebuffer. The only parameters t

[PATCH v7 8/9] drm/omap: add plane_atomic_print_state support

2021-11-17 Thread Neil Armstrong
From: Benoit Parrot Now that we added specific item to our subclassed drm_plane_state we can add omap_plane_atomic_print_state() helper to dump out our own driver specific plane state. Signed-off-by: Benoit Parrot Signed-off-by: Neil Armstrong --- drivers/gpu/drm/omapdrm/omap_plane.c | 14 +++

[PATCH v2 1/6] drm/i915: move the pre_pin earlier

2021-11-17 Thread Matthew Auld
In intel_context_do_pin_ww, when calling into the pre_pin hook(which is passed the ww context) it could in theory return -EDEADLK(which is very likely with debug kernels), once we start adding more ww locking in there, like in the next patch. If so then we need to be mindful of having to restart th

[PATCH v2 3/6] drm/i915: Create a full object for mock_ring, v2.

2021-11-17 Thread Matthew Auld
From: Maarten Lankhorst This allows us to finally get rid of all the assumptions that vma->obj is NULL. Changes since v1: - Ensure the mock_ring vma is pinned to prevent a fault. - Pin it high to avoid failure in evict_for_vma selftest. Signed-off-by: Maarten Lankhorst Reviewed-by: Matthew Aul

[PATCH v2 2/6] drm/i915: Create a dummy object for gen6 ppgtt

2021-11-17 Thread Matthew Auld
From: Maarten Lankhorst We currently have to special case vma->obj being NULL because of gen6 ppgtt and mock_engine. Fix gen6 ppgtt, so we may soon be able to remove a few checks. As the object only exists as a fake object pointing to ggtt, we have no backing storage, so no real object is created

[PATCH v2 4/6] drm/i915: vma is always backed by an object.

2021-11-17 Thread Matthew Auld
From: Maarten Lankhorst vma->obj and vma->resv are now never NULL, and some checks can be removed. Signed-off-by: Maarten Lankhorst Reviewed-by: Matthew Auld Signed-off-by: Matthew Auld --- drivers/gpu/drm/i915/gt/intel_context.c | 2 +- .../gpu/drm/i915/gt/intel_ring_submission.c |

[PATCH v2 5/6] drm/i915: Remove resv from i915_vma

2021-11-17 Thread Matthew Auld
From: Maarten Lankhorst It's just an alias to vma->obj->base.resv, no need to duplicate it. Signed-off-by: Maarten Lankhorst Reviewed-by: Niranjana Vishwanathapura Signed-off-by: Matthew Auld --- drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 4 ++-- drivers/gpu/drm/i915/i915_vma.c

[PATCH v2 6/6] drm/i915: Drain the ttm delayed workqueue too

2021-11-17 Thread Matthew Auld
From: Maarten Lankhorst Lets be thorough here. Users of the TTM backend would likely expect this behaviour. Signed-off-by: Maarten Lankhorst Reviewed-by: Matthew Auld Signed-off-by: Matthew Auld --- drivers/gpu/drm/i915/i915_drv.h | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/g

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Rename gt to gt0

2021-11-17 Thread Chris Wilson
Quoting Andi Shyti (2021-11-17 13:34:56) > diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c > b/drivers/gpu/drm/i915/display/intel_atomic_plane.c > index 089fb4658b216..0bbf8c0c42eac 100644 > --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c > +++ b/drivers/gpu/drm/i915/display

[PATCH] drm/format-helper: Fix dst computation in drm_fb_xrgb8888_to_rgb888_dstclip()

2021-11-17 Thread Hector Martin
The dst pointer was being advanced by the clip width, not the full line stride, resulting in corruption. The clip offset was also calculated incorrectly. Cc: sta...@vger.kernel.org Signed-off-by: Hector Martin --- drivers/gpu/drm/drm_format_helper.c | 4 ++-- 1 file changed, 2 insertions(+), 2 d

Re: [PATCH 11/12] drm/rockchip: Make VOP driver optional

2021-11-17 Thread Heiko Stübner
Am Mittwoch, 17. November 2021, 15:33:46 CET schrieb Sascha Hauer: > With upcoming VOP2 support VOP won't be the only choice anymore, so make > the VOP driver optional. > > Signed-off-by: Sascha Hauer > --- > arch/arm/configs/multi_v7_defconfig | 1 + > arch/arm64/configs/defconfig

[PATCH 0/5] drm/vc4: Use the firmware to stop the display pipeline

2021-11-17 Thread Maxime Ripard
Hi, The VC4 driver has had limited support to disable the HDMI controllers and pixelvalves at boot if the firmware has enabled them. However, this proved to be limited, and a bit unreliable so a new firmware command has been introduced some time ago to make it free all its resources and disable a

[PATCH 1/5] dt-bindings: display: vc4: Add optional phandle to firmware

2021-11-17 Thread Maxime Ripard
The firmware can free all the resources it was using to run the display engine that won't be needed once the kernel has taken over. Thus, we need a phandle to the firmware DT node to be able to send that message when relevant. Signed-off-by: Maxime Ripard --- .../devicetree/bindings/display/brc

[PATCH 2/5] firmware: raspberrypi: Add RPI_FIRMWARE_NOTIFY_DISPLAY_DONE

2021-11-17 Thread Maxime Ripard
The RPI_FIRMWARE_NOTIFY_DISPLAY_DONE firmware call allows to tell the firmware the kernel is in charge of the display now and the firmware can free whatever resources it was using. Signed-off-by: Maxime Ripard --- include/soc/bcm2835/raspberrypi-firmware.h | 1 + 1 file changed, 1 insertion(+)

[PATCH 4/5] drm/vc4: Notify the firmware when DRM is in charge

2021-11-17 Thread Maxime Ripard
Once the call to drm_fb_helper_remove_conflicting_framebuffers() has been made, simplefb has been unregistered and the KMS driver is entirely in charge of the display. Thus, we can notify the firmware it can free whatever resource it was using to maintain simplefb functional. Signed-off-by: Maxim

[PATCH 5/5] ARM: dts: rpi: Add the firmware node to vc4

2021-11-17 Thread Maxime Ripard
Add the firmware phandle to the vc4 node so that we can send it the message that we're done with the firmware display. Signed-off-by: Maxime Ripard --- arch/arm/boot/dts/bcm2835-rpi.dtsi | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm/boot/dts/bcm2835-rpi.dtsi b/arch/arm/boot/d

[PATCH 3/5] drm/vc4: Remove conflicting framebuffers before callind bind_all

2021-11-17 Thread Maxime Ripard
The bind hooks will modify their controller registers, so simplefb is going to be unusable anyway. Let's avoid any transient state where it could still be in the system but no longer functionnal. Signed-off-by: Maxime Ripard --- drivers/gpu/drm/vc4/vc4_drv.c | 8 1 file changed, 4 inser

Re: [PATCH v1 00/12] drm/rockchip: RK356x VOP2 support

2021-11-17 Thread Rob Herring
On Wed, Nov 17, 2021 at 8:34 AM Sascha Hauer wrote: > > This series adds initial graphics support for the Rockchip RK356[68] > SoCs. Graphics support is based around the VOP2 controller which > replaces the VOP controller found on earlier Rockchip SoCs. The driver > has been tested with HDMI supp

Re: [PATCH] drm/format-helper: Fix dst computation in drm_fb_xrgb8888_to_rgb888_dstclip()

2021-11-17 Thread Thomas Zimmermann
Hi Am 17.11.21 um 15:22 schrieb Hector Martin: The dst pointer was being advanced by the clip width, not the full line stride, resulting in corruption. The clip offset was also calculated incorrectly. Cc: sta...@vger.kernel.org Signed-off-by: Hector Martin Thanks for your patch, but you're p

[PATCH 0/3] drm/simpledrm: Apple M1 / DT platform support fixes

2021-11-17 Thread Hector Martin
Hi DRM folks, This short series makes simpledrm work on Apple M1 (including Pro/Max) platforms the way simplefb already does, by adding XRGB2101010 support and making it bind to framebuffers in /chosen the same way simplefb does. This avoids breaking the bootloader-provided framebuffer console wh

[PATCH 1/3] drm/simpledrm: Bind to OF framebuffers in /chosen

2021-11-17 Thread Hector Martin
This matches the simplefb behavior; these nodes are not matched by the standard OF machinery. This fixes a regression when simpledrm replaces simeplefb. Signed-off-by: Hector Martin --- drivers/gpu/drm/tiny/simpledrm.c | 17 + 1 file changed, 17 insertions(+) diff --git a/driver

[PATCH 2/3] drm/format-helper: Add drm_fb_xrgb8888_to_xrgb2101010_dstclip()

2021-11-17 Thread Hector Martin
Add XRGB emulation support for devices that can only do XRGB2101010. This is chiefly useful for simpledrm on Apple devices where the bootloader-provided framebuffer is 10-bit, which already works fine with simplefb. This is required to make simpledrm support this too. Signed-off-by: Hector Ma

[PATCH 3/3] drm/simpledrm: Enable XRGB2101010 format

2021-11-17 Thread Hector Martin
This is the format used by the bootloader framebuffer on Apple ARM64 platforms, and is already supported by simplefb. This avoids regressing on these platforms when simpledrm is enabled and replaces simplefb. Signed-off-by: Hector Martin --- drivers/gpu/drm/tiny/simpledrm.c | 2 +- 1 file change

Re: [PATCH 09/12] arm64: dts: rockchip: rk356x: Add HDMI nodes

2021-11-17 Thread Rob Herring
On Wed, Nov 17, 2021 at 8:34 AM Sascha Hauer wrote: > > Add support for the HDMI port found on RK3568. > > Signed-off-by: Sascha Hauer > --- > arch/arm64/boot/dts/rockchip/rk356x.dtsi | 65 > 1 file changed, 65 insertions(+) > > diff --git a/arch/arm64/boot/dts/rockchip/

Re: [PATCH 11/12] drm/rockchip: Make VOP driver optional

2021-11-17 Thread Heiko Stübner
Am Mittwoch, 17. November 2021, 15:50:54 CET schrieb Sascha Hauer: > On Wed, Nov 17, 2021 at 03:40:26PM +0100, Heiko Stübner wrote: > > Am Mittwoch, 17. November 2021, 15:33:46 CET schrieb Sascha Hauer: > > > With upcoming VOP2 support VOP won't be the only choice anymore, so make > > > the VOP dri

Re: [PATCH 10/12] arm64: dts: rockchip: rk3568-evb: Enable VOP2 and hdmi

2021-11-17 Thread Rob Herring
On Wed, Nov 17, 2021 at 8:34 AM Sascha Hauer wrote: > > This enabled the VOP2 display controller along with hdmi and the > required port routes which is enough to get a picture out of the > hdmi port of the board. > > Signed-off-by: Sascha Hauer > --- > .../boot/dts/rockchip/rk3568-evb1-v10.dts

Re: [PATCH 10/12] arm64: dts: rockchip: rk3568-evb: Enable VOP2 and hdmi

2021-11-17 Thread Michael Riesch
Hi Sascha, On 11/17/21 3:33 PM, Sascha Hauer wrote: This enabled the VOP2 display controller along with hdmi and the required port routes which is enough to get a picture out of the hdmi port of the board. Signed-off-by: Sascha Hauer --- .../boot/dts/rockchip/rk3568-evb1-v10.dts | 24 +++

RE: Backlight control broken on UM325 (OLED) on 5.15 (bisected)

2021-11-17 Thread Li, Roman
[Public] Hi Samuel, Can you please try: https://patchwork.freedesktop.org/patch/463485/ ? Thanks, Roman > -Original Message- > From: Samuel Čavoj > Sent: Tuesday, November 16, 2021 8:33 AM > To: Alex Deucher > Cc: Deucher, Alexander ; Li, Sun peng (Leo) > ; Li, Roman ; Maling list - D

Re: [PATCH] drm/format-helper: Fix dst computation in drm_fb_xrgb8888_to_rgb888_dstclip()

2021-11-17 Thread Hector Martin
On 17/11/2021 23.56, Thomas Zimmermann wrote: Hi Am 17.11.21 um 15:22 schrieb Hector Martin: The dst pointer was being advanced by the clip width, not the full line stride, resulting in corruption. The clip offset was also calculated incorrectly. Cc: sta...@vger.kernel.org Signed-off-by: Hecto

[PATCH] arm64: dts: rockchip: enable vop2 and hdmi tx on quartz64a

2021-11-17 Thread Michael Riesch
Enable the RK356x Video Output Processor (VOP) 2 on the Pine64 Quartz64 Model A. Signed-off-by: Michael Riesch --- .../boot/dts/rockchip/rk3566-quartz64-a.dts | 24 +++ 1 file changed, 24 insertions(+) diff --git a/arch/arm64/boot/dts/rockchip/rk3566-quartz64-a.dts b/arch/arm

Re: [PATCH 07/12] dt-bindings: display: rockchip: Add binding for VOP2

2021-11-17 Thread Rob Herring
On Wed, 17 Nov 2021 15:33:42 +0100, Sascha Hauer wrote: > The VOP2 is found on newer Rockchip SoCs like the rk3568 or the rk3566. > The binding differs slightly from the existing VOP binding, so add a new > binding file for it. > > Signed-off-by: Sascha Hauer > --- > .../display/rockchip/rockchi

Re: [PATCH 10/10] drm/i915: Add privacy-screen support (v3)

2021-11-17 Thread Hans de Goede
Hi Rajat, On 11/17/21 14:59, Rajat Jain wrote: > Hello Hans, > > I'm working on my platform's privacy-screen support based on your > patches, and had some (I know late) questions. Would be great if you > could please help answer. Please see inline. > > On Tue, Oct 5, 2021 at 1:25 PM Hans de Goed

[PATCH] gpu: drm: panel-edp: Fix edp_panel_entry documentation

2021-11-17 Thread Kieran Bingham
The edp_panel_entry members 'delay' and 'name' are documented, but without the correct syntax for kernel doc. This generates the following warnings: drivers/gpu/drm/panel/panel-edp.c:204: warning: Function parameter or member 'delay' not described in 'edp_panel_entry' drivers/gpu/drm/panel/panel

Re: [PATCH 03/10] drm/privacy-screen: Add X86 specific arch init code

2021-11-17 Thread Hans de Goede
Hi Rajat, On 11/17/21 15:13, Rajat Jain wrote: > Hello Hans, > > On Tue, Oct 5, 2021 at 1:23 PM Hans de Goede wrote: >> >> Add X86 specific arch init code, which fills the privacy-screen lookup >> table by checking for various vendor specific ACPI interfaces for >> controlling the privacy-screen

Re: Backlight control broken on UM325 (OLED) on 5.15 (bisected)

2021-11-17 Thread Samuel Čavoj
Hi Roman, On 17.11.2021 15:26, Li, Roman wrote: > [Public] > > Hi Samuel, > > Can you please try: https://patchwork.freedesktop.org/patch/463485/ ? Yup, that did the trick. Works as before. Thank you very much. Samuel > > Thanks, > Roman > > > -Original Message- > > From: Samuel Čav

[Bug 214921] amdgpu hangs HP Laptop on shutdown

2021-11-17 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=214921 spassw...@web.de changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug 214901] amdgpu freezes HP laptop at start up

2021-11-17 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=214901 spassw...@web.de changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug 214859] drm-amdgpu-init-iommu~fd-device-init.patch introduce bug

2021-11-17 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=214859 spassw...@web.de changed: What|Removed |Added CC||spassw...@web.de --- Comment #8 from s

  1   2   >