[PATCH 1/2] accel/habanalabs/gaudi2: use correct registers to dump QM CQ info

From: Tomer Tayar The QM CQ PTR_LO/PTR_HI/TSIZE registers are for pushing a CQ entry, and although they are updated by HW even when descriptors are fetched by PQ and CB addresses are fed into CQ, the correct registers to use when dumping the CQ info are the ones with the _STS suffix. Signed-off-

[PATCH 2/2] accel/habanalabs/gaudi2: add signed dev info uAPI

From: Moti Haimovski User will provide a nonce via the INFO ioctl, and will retrieve the signed device info generated using given nonce. Signed-off-by: Moti Haimovski Reviewed-by: Oded Gabbay Signed-off-by: Oded Gabbay --- drivers/accel/habanalabs/common/firmware_if.c | 8 drivers/acce

Re: [PATCH 3/3] drm/amd/display: Support DRM_AMD_DC_FP on RISC-V

On Wed, Nov 29, 2023 at 05:42:24PM -0700, Nathan Chancellor wrote: > On Thu, Nov 23, 2023 at 02:23:01PM +, Conor Dooley wrote: > > On Tue, Nov 21, 2023 at 07:05:15PM -0800, Samuel Holland wrote: > > > RISC-V uses kernel_fpu_begin()/kernel_fpu_end() like several other > > > architectures. Enabli

Re: [RFC PATCH 0/6] Supporting GMEM (generalized memory management) for external memory devices

Hi Oak, yeah, #4 is indeed a really good point and I think Felix will agree to that as well. HMM is basically still missing a way to advise device attributes for the CPU address space. Both migration strategy as well as device specific information (like cache preferences) fall into this cate

Re: [PATCH 1/2] dt-bindings: display: Add Sharp LS027B7DH01 Memory LCD

On 29/11/2023 15:29, Mehdi Djait wrote: > + pwms: > +maxItems: 1 > +description: External COM inversion signal > + > +required: > + - compatible > + - reg > + - spi-lsb-first > + - enable-gpios > + > +additionalProperties: false > + > +examples: > + - | > +#include > + > +spi

Re: [PATCH 2/2] drm/tests: managed: Add a simple test for drmm_managed_release

Hi, Thanks for creating a test for that, that's really appreciated :) On Wed, Nov 29, 2023 at 11:14:12PM +0100, Michał Winiarski wrote: > Add a simple test that checks whether the action is indeed called right > away and that it is not called on the final drm_dev_put(). > > Signed-off-by: Michał

Re: [RFC] drm: enable W=1 warnings by default across the subsystem

On Wed, 29 Nov 2023, Hamza Mahfooz wrote: > Cc: Nathan Chancellor > > On 11/29/23 13:12, Jani Nikula wrote: >> At least the i915 and amd drivers enable a bunch more compiler warnings >> than the kernel defaults. >> >> Extend the W=1 warnings to the entire drm subsystem by default. Use the >> cop

Re: [PATCH 1/2] drm/imagination: Fix error codes in pvr_device_clk_init()

Hi, Thank you for the patches. On Thu, 2023-11-30 at 10:26 +0300, Dan Carpenter wrote: > There is a cut and paste error so this code returns the wrong variable. > > Fixes: 1f88f017e649 ("drm/imagination: Get GPU resources") > Signed-off-by: Dan Carpenter Reviewed-by: Frank Binns > --- > dri

Re: [PATCH 2/2] drm/imagination: Fix IS_ERR() vs NULL bug in pvr_request_firmware()

On Thu, 2023-11-30 at 10:27 +0300, Dan Carpenter wrote: > The pvr_build_firmware_filename() function returns NULL on error. It > doesn't return error pointers. > > Fixes: f99f5f3ea7ef ("drm/imagination: Add GPU ID parsing and firmware > loading") > Signed-off-by: Dan Carpenter Reviewed-by: Fra

Re: [PATCH] drm/imagination: fix off by one in pvr_vm_mips_init() error handling

On Thu, 2023-11-30 at 10:27 +0300, Dan Carpenter wrote: > If the call to vmap() fails the "page_nr" is one element beyond the end > of the mips_data->pt_dma_addr[] and mips_data->pt_pages[] arrays. > > The way that this is traditionally written is that we clean up the > partial loop iteration befo

[PULL] drm-misc-next

Hi, Here's this week drm-misc-next PR Thanks! Maxime drm-misc-next-2023-11-30: drm-misc-next for 6.8: UAPI Changes: - Introduction of DRM_CAP_ATOMIC_ASYNC_PAGE_FLIP - Introduction of DRM_CLIENT_CAP_CURSOR_PLANE_HOTSPOT Cross-subsystem Changes: - fbdev: Convert a big chunks of drivers to hel

Re: [RFC] drm: enable W=1 warnings by default across the subsystem

Hi, On Thu, Nov 30, 2023 at 10:52:17AM +0200, Jani Nikula wrote: > On Wed, 29 Nov 2023, Hamza Mahfooz wrote: > > Cc: Nathan Chancellor > > > > On 11/29/23 13:12, Jani Nikula wrote: > >> At least the i915 and amd drivers enable a bunch more compiler warnings > >> than the kernel defaults. > >> >

Re: (subset) [PATCH 1/2] drm/imagination: Fix error codes in pvr_device_clk_init()

On Thu, 30 Nov 2023 10:26:29 +0300, Dan Carpenter wrote: > There is a cut and paste error so this code returns the wrong variable. > > Applied to drm/drm-misc (drm-misc-next). Thanks! Maxime

Re: (subset) [PATCH 2/2] drm/imagination: Fix IS_ERR() vs NULL bug in pvr_request_firmware()

On Thu, 30 Nov 2023 10:27:01 +0300, Dan Carpenter wrote: > The pvr_build_firmware_filename() function returns NULL on error. It > doesn't return error pointers. > > Applied to drm/drm-misc (drm-misc-next). Thanks! Maxime

Re: (subset) [PATCH] drm/imagination: fix off by one in pvr_vm_mips_init() error handling

On Thu, 30 Nov 2023 10:27:15 +0300, Dan Carpenter wrote: > If the call to vmap() fails the "page_nr" is one element beyond the end > of the mips_data->pt_dma_addr[] and mips_data->pt_pages[] arrays. > > The way that this is traditionally written is that we clean up the > partial loop iteration bef

Re: [PATCH 1/5] drm/imagination: Fixed warning due to implicit cast to bool

Hi Donald, It looks better, thanks :) On Wed, Nov 29, 2023 at 03:36:59PM +, Donald Robson wrote: > Reported-by: kernel test robot > Closes: > https://lore.kernel.org/oe-kbuild-all/202311241752.3ilyyfca-...@intel.com/ > Fixes: 1ff76f7a5b45 ("drm/imagination: Add GPU ID parsing and firmware

Re: [RFC] drm: enable W=1 warnings by default across the subsystem

Maxime Ripard writes: > Hi, > > On Thu, Nov 30, 2023 at 10:52:17AM +0200, Jani Nikula wrote: >> On Wed, 29 Nov 2023, Hamza Mahfooz wrote: >> > Cc: Nathan Chancellor >> > >> > On 11/29/23 13:12, Jani Nikula wrote: >> >> At least the i915 and amd drivers enable a bunch more compiler warnings >> >

Re: [RFC] drm: enable W=1 warnings by default across the subsystem

On Thu, 30 Nov 2023, Javier Martinez Canillas wrote: > Maxime Ripard writes: > >> Hi, >> >> On Thu, Nov 30, 2023 at 10:52:17AM +0200, Jani Nikula wrote: >>> On Wed, 29 Nov 2023, Hamza Mahfooz wrote: >>> > Cc: Nathan Chancellor >>> > >>> > On 11/29/23 13:12, Jani Nikula wrote: >>> >> At least th

Re: [RFC] drm: enable W=1 warnings by default across the subsystem

Jani Nikula writes: [...] > > Then I'd go for enabling in drm level and disabling individual warnings > in the driver Makefile level if they won't get fixed. > >> Maybe add a Kconfig symbol for it instead of making unconditional? >> >> Something like: >> >> +# Unconditionally enable W=1 warnings

Re: [RFC] drm: enable W=1 warnings by default across the subsystem

Am 29.11.23 um 19:12 schrieb Jani Nikula: At least the i915 and amd drivers enable a bunch more compiler warnings than the kernel defaults. Extend the W=1 warnings to the entire drm subsystem by default. Use the copy-pasted warnings from scripts/Makefile.extrawarn with s/KBUILD_CFLAGS/subdir-c

Re: [PATCH v2 0/2] drm/bridge: panel: Check device dependency before managing device link

Hi Linus, On Wed, Nov 29, 2023 at 03:38:35PM +0100, Linus Walleij wrote: > On Wed, Nov 29, 2023 at 1:32 PM Maxime Ripard wrote: > [Me] > > > It is a bigger evil to leave the tree broken than to enforce formal > > > process, > > > and it is pretty self-evident. If any of them get annoyed about it

Re: [RFC] drm: enable W=1 warnings by default across the subsystem

On Thu, Nov 30, 2023 at 11:46:00AM +0200, Jani Nikula wrote: > On Thu, 30 Nov 2023, Javier Martinez Canillas wrote: > > Maxime Ripard writes: > > > >> Hi, > >> > >> On Thu, Nov 30, 2023 at 10:52:17AM +0200, Jani Nikula wrote: > >>> On Wed, 29 Nov 2023, Hamza Mahfooz wrote: > >>> > Cc: Nathan Cha

Re: [RFC] drm: enable W=1 warnings by default across the subsystem

Maxime Ripard writes: > On Thu, Nov 30, 2023 at 11:46:00AM +0200, Jani Nikula wrote: [...] >> >> Then we'll have a ping pong of people not using W=1 or >> CONFIG_DRM_EXTRA_CHECKS introducing warnings, and people using them >> fixing the warnings... >> >> I really do think making it unconditio

RE: [RFC PATCH 0/6] Supporting GMEM (generalized memory management) for external memory devices

Glad to know that there is a common demand for a new syscall like hmadvise(). I expect it would also be useful for homogeneous NUMA cases. Credits to cudaMemAdvise() API which brought this idea to GMEM's design. To answer @Oak's questions about GMEM vs. HMM, Here is the major difference: GMEM

Re: [PATCH 10/10] ACPI: IORT: Allow COMPILE_TEST of IORT

On Wed, Nov 29, 2023 at 03:12:40PM -0400, Jason Gunthorpe wrote: > On Wed, Nov 29, 2023 at 01:55:04PM +0100, Lorenzo Pieralisi wrote: > > > I don't think it should be done this way. Is the goal compile testing > > IORT code ? > > Yes > > > If so, why are we forcing it through the SMMU (only bec

Re: [PATCH 0/2] Panfrost devfreq and GEM status fixes

On 25/11/2023 20:52, Adrián Larumbe wrote: > During recent development of the Mali CSF GPU Panthor driver, a user > noticed that GPU frequency values as reported by fdinfo were > incorrect. This was traced back to incorrect handling of frequency value > updates. The same problem was seen in Panfros

Re: [PATCH v5 00/32] drm/amd/display: add AMD driver-specific properties for color mgmt

On Tue, 28 Nov 2023 at 23:11, Harry Wentland wrote: > > On 2023-11-16 14:57, Melissa Wen wrote: > > Hello, > > > > This series extends the current KMS color management API with AMD > > driver-specific properties to enhance the color management support on > > AMD Steam Deck. The key additions to th

[PATCH v3 00/14] Add VOP2 support on rk3588

From: Andy Yan This patch sets aims at enable the VOP2 support on rk3588. Main feature of VOP2 on rk3588: Four video ports: VP0 Max 4096x2160 VP1 Max 4096x2160 VP2 Max 4096x2160 VP3 Max 2048x1080 4 4K Cluster windows with AFBC/line RGB and AFBC-only YUV support 4 4K Esmart windows with line RGB

Re: [PATCH 10/10] ACPI: IORT: Allow COMPILE_TEST of IORT

On Thu, Nov 30, 2023 at 12:12:26PM +0100, Lorenzo Pieralisi wrote: > On Wed, Nov 29, 2023 at 03:12:40PM -0400, Jason Gunthorpe wrote: > > On Wed, Nov 29, 2023 at 01:55:04PM +0100, Lorenzo Pieralisi wrote: > > > > > I don't think it should be done this way. Is the goal compile testing > > > IORT co

[PATCH v3 01/14] drm/rockchip: move output interface related definition to rockchip_drm_drv.h

From: Andy Yan The output interface related definition can shared between vop and vop2, move them to rockchip_drm_drv.h can avoid duplicated definition. Signed-off-by: Andy Yan Reviewed-by: Sascha Hauer --- (no changes since v1) drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 1 - drive

[PATCH v3 02/14] Revert "drm/rockchip: vop2: Use regcache_sync() to fix suspend/resume"

From: Andy Yan This reverts commit b63a553e8f5aa6574eeb535a551817a93c426d8c. regcache_sync will try to reload the configuration in regcache to hardware, but the registers of 4 Cluster windows and Esmart1/2/3 on the upcoming rk3588 can not be set successfully before internal PD power on. Also it

[PATCH v3 03/14] drm/rockchip: vop2: set half_block_en bit in all mode

From: Andy Yan At first we thought the half_block_en bit in AFBCD_CTRL register only work in afbc mode. But the fact is that it control the line buffer in all mode(afbc/tile/linear), so we need configure it in all case. As the cluster windows of rk3568 only supports afbc format so is therefore n

[PATCH v3 04/14] drm/rockchip: vop2: clear afbc en and transform bit for cluster window at linear mode

From: Andy Yan The enable bit and transform offset of cluster windows should be cleared when it work at linear mode, or we may have a iommu fault issue on rk3588 which cluster windows switch between afbc and linear mode. As the cluster windows of rk3568 only supports afbc format so is therefore

[PATCH v3 05/14] drm/rockchip: vop2: Add write mask for VP config done

From: Andy Yan The write mask bit is used to make sure when writing config done bit for one VP will not overwrite the other. Unfortunately, the write mask bit is missing on rk3566/8, that means when we write to these bits, it will not take any effect. We need this to make the vop work properly

[PATCH v3 06/14] drm/rockchip: vop2: Set YUV/RGB overlay mode

From: Andy Yan Set overlay mode register according to the output mode is yuv or rgb. Signed-off-by: Andy Yan --- Changes in v3: - put bool variable yuv_overlay next to other bool variable - define macro for RK3568_OVL_CTRL__YUV_MODE - just write RK3568_OVL_CTRL register once in function vop

[PATCH v3 07/14] drm/rockchip: vop2: rename grf to sys_grf

From: Andy Yan The vop2 need to reference more grf(system grf, vop grf, vo0/1 grf,etc) in the upcoming rk3588. So we rename the current system grf to sys_grf. Signed-off-by: Andy Yan Reviewed-by: Sascha Hauer --- (no changes since v1) drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 8 --

[PATCH v3 08/14] dt-bindings: soc: rockchip: add rk3588 vop/vo syscon

From: Andy Yan Add VOP and VO GRF syscon compatibles for RK3588 Signed-off-by: Andy Yan Acked-by: Rob Herring --- (no changes since v1) Documentation/devicetree/bindings/soc/rockchip/grf.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/soc/rockchi

[PATCH v3 09/14] dt-bindings: display: vop2: Add rk3588 support

From: Andy Yan The vop2 on rk3588 is similar to which on rk356x but with 4 video ports and need to reference more grf modules. Signed-off-by: Andy Yan --- Changes in v3: - constrain properties in allOf:if:then - some description updates Changes in v2: - fix errors when running 'make DT_CHECK

[PATCH v3 10/14] dt-bindings: rockchip, vop2: Add more endpoint definition

From: Andy Yan There are 2 HDMI, 2 DP, 2 eDP on rk3588, so add corresponding endpoint definition for it. Signed-off-by: Andy Yan Acked-by: Krzysztof Kozlowski --- Changes in v3: - change the subject as Krzysztof suggested, and add his ACK Changes in v2: - split form vop driver patch inclu

[PATCH v3 11/14] drm/rockchip: vop2: Add support for rk3588

From: Andy Yan VOP2 on rk3588: Four video ports: VP0 Max 4096x2160 VP1 Max 4096x2160 VP2 Max 4096x2160 VP3 Max 2048x1080 4 4K Cluster windows with AFBC/line RGB and AFBC-only YUV support 4 4K Esmart windows with line RGB/YUV support Signed-off-by: Andy Yan --- Changes in v3: - add braces fo

[PATCH v3 12/14] drm/rockchip: vop2: Add debugfs support

From: Andy Yan /sys/kernel/debug/dri/vop2/summary: dump vop display state /sys/kernel/debug/dri/vop2/regs: dump whole vop registers /sys/kernel/debug/dri/vop2/active_regs: only dump the registers of activated modules Signed-off-by: Andy Yan --- Changes in v3: - put regs dump info in vop2_dat

[PATCH v3 13/14] dt-bindings: iommu: rockchip: Add Rockchip RK3588

From: Andy Yan Add a Rockchip RK3588 compatible Signed-off-by: Andy Yan --- (no changes since v1) Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml b/Documentation/devic

[PATCH v3 14/14] arm64: dts: rockchip: Add vop on rk3588

From: Andy Yan Add vop dt node for rk3588. Signed-off-by: Andy Yan --- (no changes since v1) arch/arm64/boot/dts/rockchip/rk3588s.dtsi | 96 +++ 1 file changed, 96 insertions(+) diff --git a/arch/arm64/boot/dts/rockchip/rk3588s.dtsi b/arch/arm64/boot/dts/rockchip/rk3588

Re: [PATCH v2 08/12] dt-bindings: display: vop2: Add rk3588 support

Hi Krzysztof: On 11/23/23 03:07, Krzysztof Kozlowski wrote: On 22/11/2023 13:55, Andy Yan wrote: From: Andy Yan The vop2 on rk3588 is similar to which on rk356x but with 4 video ports and need to reference more grf modules. Signed-off-by: Andy Yan --- Changes in v2: - fix errors when run

Re: [PATCH 4/4] drm/mediatek: support the DSI0 output on the MT8195 VDOSYS0

With the latest dynamic selection of the output component, we can now support different outputs. Move current output component into the dynamic routes array and add the new DSI0 output. Signed-off-by: Michael Walle --- drivers/gpu/drm/mediatek/mtk_drm_drv.c | 8 +++- 1 file changed, 7 inser

Re: [RFC PATCH 0/6] Supporting GMEM (generalized memory management) for external memory devices

Am 30.11.23 um 08:22 schrieb zhuweixi: Add @Oak to the KFD discussion. I will reply separately elaborating your questions on GMEM's difference from HMM/MMU notifiers. Christian, thanks for pointing me to that AMDKFD discussion. I have read the discussion around the AMDKFD skeleton patch and fo

Re: [PATCH] drm/amdgpu: add shared fdinfo stats

Am 28.11.23 um 18:52 schrieb Rob Clark: On Tue, Nov 28, 2023 at 6:28 AM Alex Deucher wrote: On Tue, Nov 28, 2023 at 9:17 AM Christian König wrote: Am 17.11.23 um 20:56 schrieb Alex Deucher: Add shared stats. Useful for seeing shared memory. Signed-off-by: Alex Deucher --- drivers/gpu/d

Re: [Linaro-mm-sig] Re: [PATCH] dma-buf: Correct the documentation of name and exp_name symbols

Am 29.11.23 um 22:18 schrieb Alex Deucher: On Wed, Nov 22, 2023 at 1:58 PM Christian König wrote: Am 22.11.23 um 17:05 schrieb Ramesh Errabolu: Fix the documentation of struct dma_buf members name and exp_name as to how these members are to be used and accessed. Signed-off-by: Ramesh Errabolu

Re: [PATCH v6 06/10] drm: ci: mediatek: Set IGT_FORCE_DRIVER for mt8173

Hi Daniel, On 29/11/23 18:52, Daniel Stone wrote: Hi Vignesh, On Wed, 29 Nov 2023 at 12:19, Vignesh Raman wrote: Expected driver for mt8173 is "mediatek" and for mt8183 it is "panfrost". Set IGT_FORCE_DRIVER to 'mediatek' as the expected driver for mt8173. Actually, for mt8183 it's both. An

Re: [PATCH 10/10] ACPI: IORT: Allow COMPILE_TEST of IORT

On 29/11/2023 12:48 am, Jason Gunthorpe wrote: The arm-smmu driver can COMPILE_TEST on x86, so expand this to also enable the IORT code so it can be COMPILE_TEST'd too. Signed-off-by: Jason Gunthorpe --- drivers/acpi/Kconfig| 2 -- drivers/acpi/Makefile | 2 +- drivers/acpi/ar

[PATCH v3 00/10] Add displays support for bsh-smm-s2/pro boards

The series adds drivers for the displays used by bsh-smm-s2/pro boards. This required applying some patches to the samsung-dsim driver and the drm_bridge.c module. Changes in v3: - Add 'Reviewed-by' tag of Krzysztof Kozlowski. - Replace "synaptics,r63353" compatible with "syna,r63353", as requir

[PATCH v3 01/10] drm/bridge: Fix bridge disable logic

As explained by the comment of the fixed code, we need to find the next bridge that hasn't set the "pre_enable_prev_first" flag to true. The code, on the contrary, was doing the opposite. So, the order of disabling the bridges couldn't be altered as required by setting the "pre_enable_prev_first" f

[PATCH v3 08/10] drm/panel: Add Ilitek ILI9805 panel driver

From: Michael Trimarchi The GPM1790A0 panel is based on the Ilitek ILI9805 Controller. Add a driver for it. Signed-off-by: Michael Trimarchi Signed-off-by: Dario Binacchi --- (no changes since v1) MAINTAINERS | 6 + drivers/gpu/drm/panel/Kconfig

[PATCH v3 03/10] drm: bridge: samsung-dsim: enter display mode in the enable() callback

The synaptics-r63353 (panel-bridge) can only be configured in command mode. So, samsung-dsim (bridge) must not be in display mode during the prepare()/unprepare() of the panel-bridge. Setting the "pre_enable_prev_first" flag to true allows the prepare() of the panel-bridge to be called between the

[PATCH v3 05/10] dt-bindings: display: panel: Add synaptics r63353 panel controller

From: Michael Trimarchi Add documentation for "synaptics,r63353" panel. Signed-off-by: Michael Trimarchi Signed-off-by: Dario Binacchi Reviewed-by: Krzysztof Kozlowski --- Changes in v3: - Add 'Reviewed-by' tag of Krzysztof Kozlowski. - Replace "synaptics,r63353" compatible with "syna,r6335

[PATCH v3 02/10] drm/bridge: Fix a use case in the bridge disable logic

The patch fixes the code for finding the next bridge with the "pre_enable_prev_first" flag set to false. In case this condition is not verified, i. e. there is no subsequent bridge with the flag set to false, the whole bridge list is traversed, invalidating the "next" variable. The use of a new it

[PATCH v3 04/10] drm: bridge: samsung-dsim: complete the CLKLANE_STOP setting

The patch completes the setting of CLKLANE_STOP for the imx8mn and imx8mp platforms (i. e. not exynos). Co-developed-by: Michael Trimarchi Signed-off-by: Michael Trimarchi Signed-off-by: Dario Binacchi --- (no changes since v1) drivers/gpu/drm/bridge/samsung-dsim.c | 7 ++- 1 file change

[PATCH v3 06/10] drm/panel: Add Synaptics R63353 panel driver

From: Michael Trimarchi The LS068B3SX02 panel is based on the Synaptics R63353 Controller. Add a driver for it. Signed-off-by: Michael Trimarchi Signed-off-by: Dario Binacchi --- (no changes since v2) Changes in v2: - Adjust the timings of the panel reset MAINTAINERS

[PATCH v3 07/10] dt-bindings: display: panel: Add Ilitek ili9805 panel controller

From: Michael Trimarchi Add documentation for "ilitek,ili9805" panel. Signed-off-by: Michael Trimarchi Signed-off-by: Dario Binacchi --- Changes in v3: - Drop power-supply Changes in v2: - Add $ref to panel-common.yaml - Drop port, reset-gpios, and backlight - Set port and backlight ad requ

[PATCH v3 09/10] drm/panel: ilitek-ili9805: add support for Tianma TM041XDHG01 panel

From: Michael Trimarchi Tianma TM041XDHG01 utilizes the Ilitek ILI9805 controller. Add this panel's initialzation sequence and timing to ILI9805 driver. Signed-off-by: Michael Trimarchi Signed-off-by: Dario Binacchi --- (no changes since v1) drivers/gpu/drm/panel/panel-ilitek-ili9805.c | 5

Re: [PATCH v1] drm/msm/dpu: improve DSC allocation

Hi Kuogee, kernel test robot noticed the following build warnings: [auto build test WARNING on drm-misc/drm-misc-next] [also build test WARNING on drm/drm-next drm-exynos/exynos-drm-next drm-intel/for-linux-next drm-intel/for-linux-next-fixes drm-tip/drm-tip linus/master v6.7-rc3 next-20231130

Re: [RFC PATCH 0/6] Supporting GMEM (generalized memory management) for external memory devices

On 29.11.23 09:27, zhuweixi wrote: Glad to hear that more sharable code is desirable. IMHO, for a common MM subsystem, it is more beneficial for GMEM to extend core MM instead of building a separate one. More core-mm complexity, awesome, we all love that! ;) -- Cheers, David / dhildenb

[PULL] drm-intel-fixes

Hi Dave & Sima - i915 fixes for v6.7-rc4. drm-intel-fixes-2023-11-30: drm/i915 fixes for v6.7-rc4: - Mark internal GSC engine with reserved uabi class - Take VGA converters into account in eDP probe - Fix intel_pre_plane_updates() call to ensure workarounds get applied BR, Jani. The following

[drm-misc:for-linux-next-fixes 1/2] drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c:1389: warning: Function parameter or member 'priv' not described in 'r535_gsp_msg_run_cpu_sequencer'

tree: git://anongit.freedesktop.org/drm/drm-misc for-linux-next-fixes head: 64111a0e22a9d4e0de7a5d04e7d5c21d0af4b900 commit: 88a2b4d34a64bba914c4e245c6de3ca42bea93cf [1/2] nouveau/gsp: document some aspects of GSP-RM config: arm64-randconfig-001-20231130 (https://download.01.org/0day-ci

Re: [PATCH v1] drm/msm/dpu: improve DSC allocation

Hi Kuogee, kernel test robot noticed the following build errors: [auto build test ERROR on drm-misc/drm-misc-next] [also build test ERROR on drm/drm-next drm-exynos/exynos-drm-next drm-intel/for-linux-next drm-intel/for-linux-next-fixes drm-tip/drm-tip linus/master v6.7-rc3 next-20231130] [If

Re: [PATCH 10/10] ACPI: IORT: Allow COMPILE_TEST of IORT

On Thu, Nov 30, 2023 at 02:10:48PM +, Robin Murphy wrote: > > diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig > > index 7673bb82945b6c..309378e76a9bc9 100644 > > --- a/drivers/iommu/Kconfig > > +++ b/drivers/iommu/Kconfig > > @@ -318,6 +318,7 @@ config ARM_SMMU > > select IOMMU_A

Re: [PATCH v1] drm/msm/dpu: improve DSC allocation

Hi Kuogee, kernel test robot noticed the following build warnings: [auto build test WARNING on drm-misc/drm-misc-next] [also build test WARNING on drm/drm-next drm-exynos/exynos-drm-next drm-intel/for-linux-next drm-intel/for-linux-next-fixes drm-tip/drm-tip linus/master v6.7-rc3 next-20231130

[PATCH 1/9] drm/panel: himax-hx8394: Drop prepare/unprepare tracking

From: Chris Morgan Drop the panel specific prepare/unprepare logic. This is now tracked by the DRM stack [1]. [1] commit d2aacaf07395 ("drm/panel: Check for already prepared/enabled in drm_panel") Signed-off-by: Chris Morgan --- drivers/gpu/drm/panel/panel-himax-hx8394.c | 11 --- 1 f

[PATCH 0/9] rockchip: Add Powkiddy X55

From: Chris Morgan Add support for the Rockchip RK3566 based Powkiddy X55 handheld gaming console. Chris Morgan (9): drm/panel: himax-hx8394: Drop prepare/unprepare tracking drm/panel: himax-hx8394: Drop shutdown logic dt-bindings: display: Document Himax HX8394 panel rotation drm/panel:

[PATCH 2/9] drm/panel: himax-hx8394: Drop shutdown logic

From: Chris Morgan The driver shutdown is duplicate as it calls drm_unprepare and drm_disable which are called anyway when associated drivers are shutdown/removed. Signed-off-by: Chris Morgan --- drivers/gpu/drm/panel/panel-himax-hx8394.c | 17 - 1 file changed, 17 deletions(-)

[PATCH 3/9] dt-bindings: display: Document Himax HX8394 panel rotation

From: Chris Morgan Document panel rotation for Himax HX8394 display panel. Signed-off-by: Chris Morgan --- .../devicetree/bindings/display/panel/himax,hx8394.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/display/panel/himax,hx8394.yaml b/

[PATCH 5/9] dt-bindings: display: himax-hx8394: Add Powkiddy X55 panel

From: Chris Morgan Add compatible string for the Powkiddy X55 panel. Signed-off-by: Chris Morgan --- .../devicetree/bindings/display/panel/himax,hx8394.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/panel/himax,hx8394.yaml b/Documen

[PATCH 4/9] drm/panel: himax-hx8394: Add Panel Rotation Support

From: Chris Morgan Add support for setting the rotation property for the Himax HX8394 panel. Signed-off-by: Chris Morgan --- drivers/gpu/drm/panel/panel-himax-hx8394.c | 15 +++ 1 file changed, 15 insertions(+) diff --git a/drivers/gpu/drm/panel/panel-himax-hx8394.c b/drivers/gpu

[PATCH 6/9] drm/panel: himax-hx8394: Add Support for Powkiddy X55 panel

From: Chris Morgan Add support for the Powkiddy X55 panel as used on the Powkiddy X55 handheld gaming console. This panel uses a Himax HX8394 display controller and requires a vendor provided init sequence. The display resolution is 720x1280 and is 67mm by 121mm as measured with calipers. Signed

[PATCH 8/9] dt-bindings: arm: rockchip: Add Powkiddy X55

From: Chris Morgan The Powkiddy RK2023 is a handheld gaming device made by Powkiddy and powered by the Rockchip RK3566 SoC. This device is somewhat similar to the existing Powkiddy RK3566 devices, which have been grouped together with a previous commit[1]. [1] https://lore.kernel.org/linux-rock

[PATCH 9/9] arm64: dts: rockchip: Add Powkiddy X55

From: Chris Morgan Add support for the Powkiddy X55. The Powkiddy RK2023 is a handheld gaming device with a 720p 5.5 inch screen powered by the Rockchip RK3566 SoC. It includes a Realtek 8821cs WiFi/BT module, 2 ADC joysticks powered by 4 dedicated ADC channels, and several GPIO face buttons. The

[PATCH 7/9] clk: rockchip: Mark pclk_usb as critical on rk3568

From: Chris Morgan In the reference manual under "2.8.6 NIU Clock gating reliance" it is stated that pclk_usb_niu has a dependency on hclk_usb_niu. While the manual does not state that this is a bi-directional relationship it was noted that the sdmmc2 failed to operate for me in mmc mode if the

Re: [PATCH v2 1/2] drm: bridge: adv7511: fix reading edid segments

Hi Emil, On 27.10.23 14:22, Emil Abildgaard Svendsen wrote: > [Sie erhalten nicht häufig E-Mails von e...@bang-olufsen.dk. Weitere > Informationen, warum dies wichtig ist, finden Sie unter > https://aka.ms/LearnAboutSenderIdentification ] > > Currently reading EDID only works because usually on

Re: [PATCH] drm/amdgpu: add shared fdinfo stats

On Thu, Nov 30, 2023 at 5:13 AM Christian König wrote: > > Am 28.11.23 um 18:52 schrieb Rob Clark: > > On Tue, Nov 28, 2023 at 6:28 AM Alex Deucher wrote: > >> On Tue, Nov 28, 2023 at 9:17 AM Christian König > >> wrote: > >>> Am 17.11.23 um 20:56 schrieb Alex Deucher: > Add shared stats. U

[PATCH v2 1/5] drm/imagination: Fixed warning due to implicit cast to bool

This line appears to confuse the compiler and had been noticed previously in clang-tidy output. There isn't anything fundamentally wrong that I can see. I suspect that it just looks like a mistake - hence the first note. By making the second operand an actual bool result, const correctness can be

[PATCH v2 3/5] drm/imagination: pvr_device_process_active_queues now static

The function below is used only within this source file, but is not static. >> drivers/gpu/drm/imagination/pvr_device.c:129:6: warning: no previous >> prototype for function 'pvr_device_process_active_queues' >> [-Wmissing-prototypes] 129 | void pvr_device_process_active_queues(struct pvr_d

[PATCH v2 5/5] drm/imagination: Removed unused function to_pvr_vm_gpuva()

This function is now unused, hence it causes a compiler warning. drivers/gpu/drm/imagination/pvr_vm.c:112:22: warning: unused function 'to_pvr_vm_gpuva' [-Wunused-function] 112 | struct pvr_vm_gpuva *to_pvr_vm_gpuva(struct drm_gpuva *gpuva) | ^ Remove the fu

[PATCH v2 2/5] drm/imagination: Fixed missing header in pvr_fw_meta

A missing header causes the compiler to warn that the function below is not forward declared. >> drivers/gpu/drm/imagination/pvr_fw_meta.c:33:1: warning: no previous >> prototype for function 'pvr_meta_cr_read32' [-Wmissing-prototypes] 33 | pvr_meta_cr_read32(struct pvr_device *pvr_dev, u32

[PATCH v2 4/5] drm/imagination: pvr_gpuvm_free() now static

The function below is used only within this source file, but is not static. drivers/gpu/drm/imagination/pvr_vm.c:542:6: error: no previous prototype for 'pvr_gpuvm_free' [-Werror=missing-prototypes] 542 | void pvr_gpuvm_free(struct drm_gpuvm *gpuvm) Make it static. Reported-by: Arnd Bergmann

Re: [PATCH v2 1/2] drm: bridge: adv7511: fix reading edid segments

On 30.11.23 16:57, Frieder Schrempf wrote: > Hi Emil, > > On 27.10.23 14:22, Emil Abildgaard Svendsen wrote: >> [Sie erhalten nicht häufig E-Mails von e...@bang-olufsen.dk. Weitere >> Informationen, warum dies wichtig ist, finden Sie unter >> https://aka.ms/LearnAboutSenderIdentification ] >> >>

[PATCH] drm/i915/display: Check GGTT to determine phys_base

There was an assumption that for iGPU there should be a 1:1 mapping of GGTT to physical address pointing to actual framebuffer. This assumption is not valid anymore for MTL. Fix that by checking GGTT to determine the phys address. The following algorithm for phys_base should be valid for all platf

Re: [Intel-gfx] [PATCH] drm/i915/display: Fix phys_base to be relative not absolute

On Tue, Nov 28, 2023 at 12:12:08PM +0100, Andrzej Hajda wrote: > On 28.11.2023 04:47, Paz Zcharya wrote: > > > > On Mon, Nov 27, 2023 at 8:20 PM Paz Zcharya wrote: > > > > > > On 21.11.2023 13:06, Andrzej Hajda wrote: > > > > > > > The simplest approach would be then do the same as in case of D

[PATCH v4 01/17] drm/v3d: Remove unused function header

From: Melissa Wen v3d_mmu_get_offset header was added but the function was never defined. Just remove it. Signed-off-by: Melissa Wen Signed-off-by: Maíra Canal Reviewed-by: Iago Toral Quiroga --- drivers/gpu/drm/v3d/v3d_drv.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/d

[PATCH v4 00/17] drm/v3d: Introduce CPU jobs

This patchset implements the basic infrastructure for a new type of V3D job, a CPU job. A CPU job is a job that requires CPU intervention. It would be nice to perform this operations on the kernel space as we can attach multiple in/out syncobjs to it. Why we want a CPU job on the kernel? =

[PATCH v4 02/17] drm/v3d: Move wait BO ioctl to the v3d_bo file

From: Melissa Wen IOCTLs related to BO operations reside on the file v3d_bo.c. The wait BO ioctl is the only IOCTL regarding BOs that is placed in a different file. So, move it to the v3d_bo.c file. Signed-off-by: Melissa Wen Signed-off-by: Maíra Canal Reviewed-by: Iago Toral Quiroga --- dri

[PATCH v4 03/17] drm/v3d: Detach job submissions IOCTLs to a new specific file

From: Melissa Wen We will include a new job submission type, the CPU job submission. For readability and maintability, separate the job submission IOCTLs and related operations from v3d_gem.c. Minor fix in the CSD submission kernel doc: CSD (texture formatting) -> CSD (compute shader). Signed-o

[PATCH v4 04/17] drm/v3d: Simplify job refcount handling

From: Melissa Wen Instead of checking if the job is NULL every time we call the function, check it inside the function. Signed-off-by: Melissa Wen Signed-off-by: Maíra Canal Reviewed-by: Iago Toral Quiroga --- drivers/gpu/drm/v3d/v3d_submit.c | 9 + 1 file changed, 5 insertions(+), 4

[PATCH v4 05/17] drm/v3d: Don't allow two multisync extensions in the same job

Currently, two multisync extensions can be added to the same job and only the last multisync extension will be used. To avoid this vulnerability, don't allow two multisync extensions in the same job. Signed-off-by: Maíra Canal Reviewed-by: Iago Toral Quiroga --- drivers/gpu/drm/v3d/v3d_submit.c

[PATCH v4 09/17] drm/v3d: Create tracepoints to track the CPU job

Create tracepoints to track the three major events of a CPU job lifetime: 1. Submission of a `v3d_submit_cpu` IOCTL 2. Beginning of the execution of a CPU job 3. Ending of the execution of a CPU job Signed-off-by: Maíra Canal Reviewed-by: Iago Toral Quiroga --- drivers/g

[PATCH v4 06/17] drm/v3d: Decouple job allocation from job initiation

We want to allow the IOCTLs to allocate the job without initiating it. This will be useful for the CPU job submission IOCTL, as the CPU job has the need to use information from the user extensions. Currently, the user extensions are parsed before the job allocation, making it impossible to fill the

[PATCH v4 08/17] drm/v3d: Use v3d_get_extensions() to parse CPU job data

Currently, v3d_get_extensions() only parses multisync data and assigns it to the `struct v3d_submit_ext`. But, to implement the CPU job with user extensions, we want v3d_get_extensions() to be able to parse CPU job data and assign it to the `struct v3d_cpu_job`. Therefore, allow the function v3d_g

[PATCH v4 10/17] drm/v3d: Detach the CSD job BO setup

From: Melissa Wen Detach CSD job setup from CSD submission ioctl to reuse it in CPU submission ioctl for indirect CSD job. Signed-off-by: Melissa Wen Co-developed-by: Maíra Canal Signed-off-by: Maíra Canal Reviewed-by: Iago Toral Quiroga --- drivers/gpu/drm/v3d/v3d_submit.c | 68 +++

[PATCH v4 11/17] drm/v3d: Enable BO mapping

For the indirect CSD CPU job, we will need to access the internal contents of the BO with the dispatch parameters. Therefore, create methods to allow the mapping and unmapping of the BO. Signed-off-by: Maíra Canal Reviewed-by: Iago Toral Quiroga --- drivers/gpu/drm/v3d/v3d_bo.c | 18 ++

[PATCH v4 07/17] drm/v3d: Add a CPU job submission

From: Melissa Wen Create a new type of job, a CPU job. A CPU job is a type of job that performs operations that requires CPU intervention. The overall idea is to use user extensions to enable different types of CPU job, allowing the CPU job to perform different operations according to the type of

[PATCH v4 13/17] drm/v3d: Create a CPU job extension for the timestamp query job

A CPU job is a type of job that performs operations that requires CPU intervention. A timestamp query job is a job that calculates the query timestamp and updates the query availability by signaling a syncobj. As V3D doesn't provide any mechanism to obtain a timestamp from the GPU, it is a job that

  1   2   >