[PATCH 1/1] drm/bridge: analogix_dp: add a quirk for Bob panel

From: zain wang Some panels' DP_PSR_STATUS (DPCD 0x2008) may be unstable when we enable psr. If we get the unexpected psr state, We need try the debounce to ensure the panel was in PSR Signed-off-by: zain wang Signed-off-by: Chris Zhong Commit-Ready: Kristian H. Kristensen Tested-by: Kristian

Re: [PATCH v3 1/7] media: Add 2-10-10-10 RGB formats

[+CC: Maruo and Hans, who are listed in the SOB area of offending commit] Hi Tomi, I'm observing build failure of "make pdfdocs" against linux-next due to this change whose commitid is 8d0e3fc61abd. > Add XBGR2101010, ABGR2101010 and BGRA1010102 formats. > > Signed-off-by: Tomi Valkeinen > ---

[PATCH 1/1] drm/bridge: analogix_dp: add a quirk for Bob panel

From: zain wang Some panels' DP_PSR_STATUS (DPCD 0x2008) may be unstable when we enable psr. If we get the unexpected psr state, We need try the debounce to ensure the panel was in PSR Signed-off-by: zain wang Signed-off-by: Chris Zhong Commit-Ready: Kristian H. Kristensen Tested-by: Kristian

Re: [PATCH 1/3] drm/connector: Convert DRM_MODE_COLORIMETRY to enum

On Fri, 3 Feb 2023 02:07:42 + Joshua Ashton wrote: > From: Harry Wentland > > This allows us to use strongly typed arguments. > > Signed-off-by: Harry Wentland > Reviewed-by: Simon Ser > > Cc: Pekka Paalanen > Cc: Sebastian Wick > Cc: vitaly.pros...@amd.com > Cc: Uma Shankar > Cc: V

[PATCH] media: Fix building pdfdocs

Commit 8d0e3fc61abd ("media: Add 2-10-10-10 RGB formats") added documatation for a few new RGB formats. For some reason these break the pdfdocs build, even if the same style seems to work elsewhere in the file. Remove the trailing empty dash lines, which seems to fix the issue. Fixes: 8d0e3fc61ab

Re: [drm-misc:drm-misc-next] [drm/ttm] 1802537820: WARNING:at_drivers/gpu/drm/drm_gem_vram_helper.c:#drm_gem_vram_offset

Hey guys, I'm pretty sure this is a bug in bochs which happens to surface because of a recent TTM change, we have seen similar problems in the past with this driver. What happens is that userspace tries to bind a BO to a CRTC before the BO has even a backing store. Any idea how to fix this

Re: [PATCH 2/3] arm64: dts: qcom: sc8280xp: Add GPU related nodes

On 8.02.2023 04:40, Bjorn Andersson wrote: > From: Bjorn Andersson > > Add Adreno SMMU, GPU clock controller, GMU and GPU nodes for the > SC8280XP. > > Signed-off-by: Bjorn Andersson > Signed-off-by: Bjorn Andersson > --- > arch/arm64/boot/dts/qcom/sc8280xp.dtsi | 171 +

Re: linux-6.2-rc4+ hangs on poweroff/reboot: Bisected

Hi. I'm assuming that we are not going to see a fix for this regression before 6.2 is released. Consequently, I've implemented a (very simple) workaround. All that happens is that in the (sysv) init script that starts and stops SDDM, the nouveau module is removed once SDDM is stopped. With that

Re: [PATCH 2/3] drm/connector: Add enum documentation to drm_colorspace

On Fri, 3 Feb 2023 02:07:43 + Joshua Ashton wrote: > To match the other enums, and add more information about these values. > > Signed-off-by: Joshua Ashton > > Cc: Pekka Paalanen > Cc: Sebastian Wick > Cc: vitaly.pros...@amd.com > Cc: Uma Shankar > Cc: Ville Syrjälä > Cc: Joshua Asht

[PATCH 1/6] drm/gem: Remove BUG_ON in drm_gem_private_object_init

ttm_resource can allocate size in bytes to support less than page size. Signed-off-by: Somalapuram Amaranath --- drivers/gpu/drm/drm_gem.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c index 59a0bb5ebd85..ee8b5c2b6c60 100644 --- a/driv

[PATCH 2/6] drm/amdgpu: Remove TTM resource->start visible VRAM condition

Use amdgpu_bo_in_cpu_visible_vram() instead. Signed-off-by: Somalapuram Amaranath --- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c i

[PATCH 3/6] drm/ttm: Change the meaning of resource->start from pfn to bytes

Change resource->start from pfn to bytes to allow allocating objects smaller than a page. Change all DRM drivers using ttm_resource start and size pfn to bytes. Change amdgpu_res_first() cur->start, cur->size from pfn to bytes. Replacing ttm_resource resource->start field with cursor.start. Change

[PATCH 4/6] drm/ttm: Change the parameters of ttm_range_man_init() from pages to bytes

Change the parameters of ttm_range_man_init_nocheck() size from page size to byte size. Cleanup the PAGE_SHIFT operation on the depended caller functions. Signed-off-by: Somalapuram Amaranath --- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 4 ++-- drivers/gpu/drm/drm_gem_vram_helper.c | 2 +- dr

[PATCH 5/6] drm/ttm: Change the meaning of the fields in the drm_mm_nodes structure from pfn to bytes

Change the ttm_range_man_alloc() allocation from pages to size in bytes. Fix the dependent drm_mm_nodes start and size from pages to bytes. Signed-off-by: Somalapuram Amaranath --- drivers/gpu/drm/i915/i915_scatterlist.c | 6 +++--- drivers/gpu/drm/ttm/ttm_range_manager.c | 15 +++

[PATCH 6/6] drm/amdgpu: Cleanup the GDS, GWS and OA allocations

Change the size of GDS, GWS and OA from pages to bytes. The initialized gds_size, gws_size and oa_size in bytes, remove PAGE_SHIFT in amdgpu_ttm_init_on_chip(). : Signed-off-by: Somalapuram Amaranath --- drivers/gpu/drm/amd/amdgpu/amdgpu_job.c| 12 ++-- drivers/gpu/drm/amd/amdgpu/amdg

[PATCH v5 3/4] drm/rockchip: dw_hdmi: Add support for 4k@30 resolution

This adds the PLL/phy settings to support higher resolutions like 4k@30. The values were taken from the Rockchip downstream Kernel. Tested-by: Michael Riesch Link: https://lore.kernel.org/r/20220926080435.259617-3-s.ha...@pengutronix.de Tested-by: Nicolas Frattaroli Tested-by: Dan Johansen Link

[PATCH v5 2/4] drm/rockchip: dw_hdmi: relax mode_valid hook

The driver checks if the pixel clock of the given mode matches an entry in the mpll config table. At least for the Synopsys phy the frequencies in the mpll table are meant as a frequency range up to which the entry works, not as a frequency that must match the pixel clock. Return MODE_OK when the p

[PATCH v5 1/4] drm/rockchip: vop: limit maximium resolution to hardware capabilities

The different VOP variants support different maximum resolutions. Reject resolutions that are not supported by a specific variant. This hasn't been a problem in the upstream driver so far as 1920x1080 has been the maximum resolution supported by the HDMI driver and that resolution is supported by

[PATCH v5 4/4] drm/rockchip: dw_hdmi: discard modes with unachievable pixelclocks

The Rockchip PLL drivers are currently table based and support only the most common pixelclocks. Discard all modes we cannot achieve at all. Normally the desired pixelclocks have an exact match in the PLL driver, nevertheless allow for a 0.1% error just in case. Tested-by: Nicolas Frattaroli Test

[PATCH v5 0/4] drm/rockchip: dw_hdmi: Add 4k@30 support

Some more small changes to this series, see changelog. Sascha Changes since v4: - Use struct vop_reg to store resolutions - Only check for valid clock rates when clock != NULL Changes since v3 - Add patch to limit VOP resolutions to hardware capabilitie Changes since v2: - Use correct register

Re: [PATCH] media: Fix building pdfdocs

Hi Tomi, Thank you for the patch. On Wed, Feb 08, 2023 at 10:29:16AM +0200, Tomi Valkeinen wrote: > Commit 8d0e3fc61abd ("media: Add 2-10-10-10 RGB formats") added > documatation for a few new RGB formats. For some reason these break the s/documatation/documentation/ > pdfdocs build, even if th

Re: [PATCH 3/3] drm/connector: Deprecate split for BT.2020 in drm_colorspace enum

On Fri, 3 Feb 2023 16:02:51 +0200 Ville Syrjälä wrote: > On Fri, Feb 03, 2023 at 02:52:50PM +0100, Sebastian Wick wrote: > > On Fri, Feb 3, 2023 at 2:35 PM Ville Syrjälä > > wrote: > > > > > > On Fri, Feb 03, 2023 at 01:59:07PM +0100, Sebastian Wick wrote: > > > > On Fri, Feb 3, 2023 at 11:4

Re: [PATCH v2 4/8] arm64: dts: qcom: sm8350: reorder device nodes

On 6.02.2023 15:57, Dmitry Baryshkov wrote: > Start ordering DT nodes according to agreed order. Move apps SMMU, GIC, > timer, apps RSC, cpufreq ADSP and cDSP nodes to the end to the proper > position at the end of /soc/. > > Signed-off-by: Dmitry Baryshkov > --- Moving adjacent nodes is prett

Re: [PATCH 3/3] drm/connector: Deprecate split for BT.2020 in drm_colorspace enum

On Fri, 3 Feb 2023 18:00:44 +0200 Ville Syrjälä wrote: > On Fri, Feb 03, 2023 at 10:24:52AM -0500, Harry Wentland wrote: > > > > > > On 2/3/23 10:19, Ville Syrjälä wrote: > > > On Fri, Feb 03, 2023 at 09:39:42AM -0500, Harry Wentland wrote: > > >> > > >> > > >> On 2/3/23 07:59, Sebastian Wi

Re: [PATCH 3/3] drm/connector: Deprecate split for BT.2020 in drm_colorspace enum

On Fri, 3 Feb 2023 20:56:55 +0200 Ville Syrjälä wrote: > Anyways, sounds like what you're basically proposing is > getting rid of this property and starting from scratch. I would be happy with that (throwing "Colorspace" out and defining something new). Then we can start with enum values we care

Re: [PATCH 3/3] drm/connector: Deprecate split for BT.2020 in drm_colorspace enum

On Fri, 3 Feb 2023 02:07:44 + Joshua Ashton wrote: > Userspace has no way of controlling or knowing the pixel encoding > currently, so there is no way for it to ever get the right values here. > > When we do add pixel_encoding control from userspace,we can pick the > right value for the col

Re: [drm-misc:drm-misc-next] [drm/ttm] 1802537820: WARNING:at_drivers/gpu/drm/drm_gem_vram_helper.c:#drm_gem_vram_offset

On Wed, 8 Feb 2023 at 08:32, Christian König wrote: > > Hey guys, > > I'm pretty sure this is a bug in bochs which happens to surface because > of a recent TTM change, we have seen similar problems in the past with > this driver. > > What happens is that userspace tries to bind a BO to a CRTC befo

Re: [PATCH 3/3] drm/connector: Deprecate split for BT.2020 in drm_colorspace enum

On Fri, 3 Feb 2023 14:33:46 -0500 Harry Wentland wrote: > On 2/3/23 14:25, Ville Syrjälä wrote: > > On Fri, Feb 03, 2023 at 08:56:55PM +0200, Ville Syrjälä wrote: > >> On Fri, Feb 03, 2023 at 01:28:20PM -0500, Harry Wentland wrote: > >>> > >>> > >>> On 2/3/23 11:00, Ville Syrjälä wrote: > >

Re: [PATCH v2] fbdev: Fix invalid page access after closing deferred I/O devices

Hi, this bug could be a symptom of the problem reported at [1]. Best regards Thomas [1] https://lore.kernel.org/dri-devel/CAM0jSHOcvZoyv-y6bnvFaUybRQsDx_mfOydL1uaNM4T4PgcA=a...@mail.gmail.com/T/#mfbef4df9b49fc5fda9bcfa26db5ca13cdaef6d7e Am 29.01.23 um 09:28 schrieb Takashi Iwai: When a fbde

Re: [PATCH 3/3] drm/connector: Deprecate split for BT.2020 in drm_colorspace enum

On Mon, 6 Feb 2023 12:16:28 -0500 Harry Wentland wrote: > On 2/6/23 04:47, Ville Syrjälä wrote: > > On Sat, Feb 04, 2023 at 06:09:45AM +, Joshua Ashton wrote: > >> > >> > >> On 2/3/23 19:34, Ville Syrjälä wrote: > >>> On Fri, Feb 03, 2023 at 09:25:38PM +0200, Ville Syrjälä wrote: >

[PATCH 0/9] Panfrost: Improve and add MediaTek SoCs support

This series adds support for new MediaTek SoCs (MT8186/MT8192/MT8195) and improves MT8183 support: since the mtk-regulator-coupler driver was picked, it is now useless for Panfrost to look for, and manage, two regulators (GPU Vcore and GPU SRAM) on MediaTek; The aforementioned driver will take car

[PATCH 1/9] dt-bindings: gpu: mali-bifrost: Don't allow sram-supply by default

The sram-supply is MediaTek-specific, it is and will ever be used only for the mediatek,mt8183-mali compatible due to the addition of the mediatek-regulator-coupler driver: change the binding to add this supply when mediatek,mt8183-mali is present as a compatible instead of disabling it when not pr

[PATCH 2/9] dt-bindings: gpu: mali-bifrost: Allow up to 5 power domains for MT8192

MediaTek MT8192 (and similar) needs five power domains for the Mali GPU and no sram-supply: change the binding to allow so. Signed-off-by: AngeloGioacchino Del Regno --- .../bindings/gpu/arm,mali-bifrost.yaml| 34 +-- 1 file changed, 31 insertions(+), 3 deletions(-) dif

[PATCH 5/9] dt-bindings: gpu: mali-bifrost: Add a compatible for MediaTek MT8186

Get GPU support on MT8186 by adding its compatible. Signed-off-by: AngeloGioacchino Del Regno --- Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml | 5 + 1 file changed, 5 insertions(+) diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml b/Documentation/dev

[PATCH 6/9] drm/panfrost: Increase MAX_PM_DOMAINS to 5

From: Alyssa Rosenzweig Increase the MAX_PM_DOMAINS constant from 3 to 5, to support the extra power domains required by the Mali-G57 on the MT8192. Signed-off-by: Alyssa Rosenzweig Signed-off-by: AngeloGioacchino Del Regno --- drivers/gpu/drm/panfrost/panfrost_device.h | 2 +- 1 file change

[PATCH 4/9] dt-bindings: gpu: mali-bifrost: Add new MT8183 compatible

Since new platform data was required in Panfrost for getting GPU DVFS finally working on MediaTek SoCs, add a new "mediatek,mt8183b-mali" compatible. Signed-off-by: AngeloGioacchino Del Regno --- .../bindings/gpu/arm,mali-bifrost.yaml| 20 +++ 1 file changed, 20 insertio

[PATCH 7/9] drm/panfrost: Add the MT8192 GPU ID

From: Alyssa Rosenzweig MediaTek MT8192 has a Mali-G57 with a special GPU ID. Add its GPU ID, but treat it as otherwise identical to a standard Mali-G57. We do _not_ fix up the GPU ID here -- userspace needs to be aware of the special GPU ID, in case we find functional differences between MediaT

[PATCH 3/9] dt-bindings: gpu: mali-bifrost: Add compatible for MT8195 SoC

The MediaTek MT8195 SoC has a Mali G57 MC5 (Valhall-JM) and has the same number of power domains and requirements as MT8192 in terms of bindings. Signed-off-by: AngeloGioacchino Del Regno --- Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml | 5 + 1 file changed, 5 insertions(+)

[PATCH 8/9] drm/panfrost: Add mediatek,mt8192-mali compatible

From: Alyssa Rosenzweig Required for Mali-G57 on the Mediatek MT8192 and MT8195, which uses even more power domains than the MT8183 before it. Signed-off-by: Alyssa Rosenzweig [Angelo: Removed unneeded "sram" supply, added mt8195 to commit description] Co-developed-by: AngeloGioacchino Del Regn

[PATCH 9/9] drm/panfrost: Add new compatible for Mali on the MT8183 SoC

The "mediatek,mt8183-mali" compatible uses platform data that calls for getting (and managing) two regulators ("mali" and "sram") but devfreq does not support this usecase, resulting in DVFS not working. Since a lot of MediaTek SoCs need to set the voltages for the GPU SRAM regulator in a specific

Re: [PATCH] media: Fix building pdfdocs

Em Wed, 8 Feb 2023 11:11:34 +0200 Laurent Pinchart escreveu: > Hi Tomi, > > Thank you for the patch. > > On Wed, Feb 08, 2023 at 10:29:16AM +0200, Tomi Valkeinen wrote: > > Commit 8d0e3fc61abd ("media: Add 2-10-10-10 RGB formats") added > > documatation for a few new RGB formats. For some reaso

Re: [PATCH] drm: Rename headers to match DP2.1 spec

On Mon, Feb 06, 2023 at 02:37:08PM -0500, jdhillon wrote: > This patch changes the headers defined in drm_dp.h to match > the DP 2.1 spec. > > Signed-off-by: Jasdeep Dhillon > --- > drivers/gpu/drm/tegra/dp.c | 2 +- > include/drm/display/drm_dp.h | 13 +++-- > 2 files changed, 8 inse

Re: [PATCH 2/6] drm/amdgpu: Remove TTM resource->start visible VRAM condition

Am 08.02.23 um 10:01 schrieb Somalapuram Amaranath: Use amdgpu_bo_in_cpu_visible_vram() instead. Signed-off-by: Somalapuram Amaranath --- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdg

Re: [PATCH 1/2] drm: Introduce plane SIZE_HINTS property

On Wed, 8 Feb 2023 06:09:10 +0200 Ville Syrjala wrote: > From: Ville Syrjälä > > Add a new immutable plane property by which a plane can advertise > a handful of recommended plane sizes. This would be mostly exposed > by cursor planes as a slightly more capable replacement for > the DRM_CAP_CU

Re: remove arch/sh

Hi Randy! On Tue, 2023-02-07 at 17:31 -0800, Randy Dunlap wrote: > > On 2/7/23 01:06, John Paul Adrian Glaubitz wrote: > > Hello Christoph! > > > > On Fri, 2023-02-03 at 08:14 +0100, Christoph Hellwig wrote: > > > On Mon, Jan 16, 2023 at 09:52:10AM +0100, John Paul Adrian Glaubitz wrote: > > > >

Re: [PATCH 3/6] drm/ttm: Change the meaning of resource->start from pfn to bytes

That finally starts to look sane. I'm going to make a few more adjustments and then send this out. Christian. Am 08.02.23 um 10:01 schrieb Somalapuram Amaranath: Change resource->start from pfn to bytes to allow allocating objects smaller than a page. Change all DRM drivers using ttm_resource

Re: remove arch/sh

Emm, maybe this patch has its chance to be merged now. :) https://lore.kernel.org/linux-sh/caahv-h6siotvkzpks4aabejgzcqtwp3tiha0+0hgz1+mu3x...@mail.gmail.com/T/#u Huacai On Wed, Feb 8, 2023 at 8:14 PM John Paul Adrian Glaubitz wrote: > > Hi Randy! > > On Tue, 2023-02-07 at 17:31 -0800, Randy Du

Re: remove arch/sh

Hi Huacei! On Wed, 2023-02-08 at 20:24 +0800, Huacai Chen wrote: > Emm, maybe this patch has its chance to be merged now. :) > > https://lore.kernel.org/linux-sh/caahv-h6siotvkzpks4aabejgzcqtwp3tiha0+0hgz1+mu3x...@mail.gmail.com/T/#u Yes, that's the plan. We're collecting the various patches peo

Re: [drm-misc:drm-misc-next] [drm/ttm] 1802537820: WARNING:at_drivers/gpu/drm/drm_gem_vram_helper.c:#drm_gem_vram_offset

Am 08.02.23 um 10:38 schrieb Matthew Auld: On Wed, 8 Feb 2023 at 08:32, Christian König wrote: Hey guys, I'm pretty sure this is a bug in bochs which happens to surface because of a recent TTM change, we have seen similar problems in the past with this driver. What happens is that userspace t

Re: [Intel-gfx] [PATCH 4/4] drm/i915/selftest: Use forcewake to sanity check engine wa lists

On Tue, Feb 07, 2023 at 07:37:58PM -0300, Gustavo Sousa wrote: > On Wed, Feb 01, 2023 at 02:28:31PM -0800, Matt Roper wrote: > > Although register information in the bspec includes a field that is > > supposed to reflect a register's reset characteristics (i.e., whether a > > register maintains its

Re: [drm-misc:drm-misc-next] [drm/ttm] 1802537820: WARNING:at_drivers/gpu/drm/drm_gem_vram_helper.c:#drm_gem_vram_offset

On Wed, 8 Feb 2023 at 12:41, Christian König wrote: > > Am 08.02.23 um 10:38 schrieb Matthew Auld: > > On Wed, 8 Feb 2023 at 08:32, Christian König > > wrote: > >> Hey guys, > >> > >> I'm pretty sure this is a bug in bochs which happens to surface because > >> of a recent TTM change, we have see

Re: [PATCH 1/2] drm: Introduce plane SIZE_HINTS property

On Wed, Feb 08, 2023 at 02:13:12PM +0200, Pekka Paalanen wrote: > On Wed, 8 Feb 2023 06:09:10 +0200 > Ville Syrjala wrote: > > > From: Ville Syrjälä > > > > Add a new immutable plane property by which a plane can advertise > > a handful of recommended plane sizes. This would be mostly exposed

[PATCH v3 0/4] Reserve DSPPs based on user request

This series will enable color features on sc7280 target which has primary panel as eDP The series removes DSPP allocation based on encoder type and allows the DSPP reservation based on user request via CTM. The series will release/reserve the dpu resources when ever there is a topology change

[PATCH v3 3/4] drm/msm/dpu: avoid unnecessary check in DPU reservations

Return immediately on failure, this will make dpu reservations part look cleaner. Signed-off-by: Kalyan Thota Reviewed-by: Dmitry Baryshkov --- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 23 ++- 1 file changed, 10 insertions(+), 13 deletions(-) diff --git a/drivers/gpu/d

[PATCH v3 1/4] drm/msm/dpu: clear DSPP reservations in rm release

Clear DSPP reservations from the global state during rm release Fixes: e47616df008b ("drm/msm/dpu: add support for color processing blocks in dpu driver") Signed-off-by: Kalyan Thota Reviewed-by: Dmitry Baryshkov Reviewed-by: Marijn Suijten --- drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 2 ++ 1

[PATCH v3 2/4] drm/msm/dpu: add DSPPs into reservation upon a CTM request

Add DSPP blocks into the topology for reservation, if there is a CTM request for that composition. Signed-off-by: Kalyan Thota Reviewed-by: Dmitry Baryshkov --- Changes in v1: - Minor nits (Dmitry) Changes in v2: - Populate DSPPs into the reservation only if CTM is requested (Dmitry) --- drive

[PATCH v3 4/4] drm/msm/dpu: reserve the resources on topology change

Some features like CTM can be enabled dynamically. Release and reserve the DPU resources whenever a topology change occurs such that required hw blocks are allocated appropriately. Signed-off-by: Kalyan Thota --- Changes in v1: - Avoid mode_set call directly (Dmitry) Changes in v2: - Minor nits

Re: remove arch/sh

> Yes, that's the plan. We're collecting the various patches people have sent > in for arch/sh, review and test them and apply them. > > My test board is running the latest kernel now, so I can test new patches, > too. I am just witnessing this development, but I want to say thanks for your eff

[bug report] drm/i915/mtl: Add hardware-level lock for steering

Hello Matt Roper, The patch 3100240bf846: "drm/i915/mtl: Add hardware-level lock for steering" from Nov 28, 2022, leads to the following Smatch static checker warning: drivers/gpu/drm/i915/gt/intel_gt_mcr.c:379 intel_gt_mcr_lock() warn: sleeping in atomic context CALL TREE: intel_engine_reset()

Re: [PATCH v3 4/4] drm/msm/dpu: reserve the resources on topology change

On 08/02/2023 15:42, Kalyan Thota wrote: Some features like CTM can be enabled dynamically. Release and reserve the DPU resources whenever a topology change occurs such that required hw blocks are allocated appropriately. Signed-off-by: Kalyan Thota --- Changes in v1: - Avoid mode_set call dire

Re: [PATCH 3/3] drm/connector: Deprecate split for BT.2020 in drm_colorspace enum

On Wed, Feb 08, 2023 at 11:18:42AM +0200, Pekka Paalanen wrote: > On Fri, 3 Feb 2023 16:02:51 +0200 > Ville Syrjälä wrote: > > > On Fri, Feb 03, 2023 at 02:52:50PM +0100, Sebastian Wick wrote: > > > On Fri, Feb 3, 2023 at 2:35 PM Ville Syrjälä > > > wrote: > > > > > > > > On Fri, Feb 03, 2023

[PATCH 1/4] drm/gem-vram: handle NULL bo->resource in move callback

The ttm BO now initially has NULL bo->resource, and leaves the driver the handle that. However it looks like we forgot to handle that for ttm_bo_move_memcpy() users, like with vram-gem, since it just silently returns zero. This seems to then trigger warnings like: WARNING: CPU: 0 PID: 1 at drivers

[PATCH 2/4] drm/qxl: handle NULL bo->resource in move callback

The ttm bo now initially has NULL bo->resource, and leaves the driver the handle that. However it looks like we forgot to handle that for qxl. It looks like this will just null-ptr-deref in qxl_bo_move(), if bo->resource is NULL. Fix this by calling move_null() if the new resource is TTM_PL_SYSTEM

[PATCH 4/4] drm/radeon: handle NULL bo->resource in move callback

The ttm bo now initially has NULL bo->resource, and leaves the driver the handle that. However it looks like we forgot to handle that for radeon. It looks like this will just null-ptr-deref in radeon_bo_move(), if bo->resource is NULL. Fix this by calling move_null(). Fixes: 180253782038 ("drm/t

[PATCH 3/4] drm/vmwgfx: handle NULL bo->resource in move callback

The ttm bo now initially has NULL bo->resource, and leaves the driver the handle that. However it looks like we forgot to handle that for vmwgfx. It looks like this will just null-ptr-deref in vmw_move(), if bo->resource is NULL. Fix this by calling move_null() if the new resource is TTM_PL_SYSTE

Re: [PATCH 0/9] Panfrost: Improve and add MediaTek SoCs support

On 08/02/2023 10:37, AngeloGioacchino Del Regno wrote: > This series adds support for new MediaTek SoCs (MT8186/MT8192/MT8195) > and improves MT8183 support: since the mtk-regulator-coupler driver > was picked, it is now useless for Panfrost to look for, and manage, > two regulators (GPU Vcore and

[PATCH] habanalabs: change unused extern decl of hdev to forward decl of hl_device

Building with clang W=2 has several similar warnings drivers/accel/habanalabs/common/decoder.c:46:51: error: declaration shadows a variable in the global scope [-Werror,-Wshadow] static void dec_error_intr_work(struct hl_device *hdev, u32 base_addr, u32 core_id)

Re: [PATCH v2 8/8] arm64: dts: qcom: sm8350-hdk: enable GPU

On 6.02.2023 15:57, Dmitry Baryshkov wrote: > Enable the GPU on the SM8350-HDK device. The ZAP shader is required for > the GPU to function properly. > > Signed-off-by: Dmitry Baryshkov > --- Reviewed-by: Konrad Dybcio Konrad > arch/arm64/boot/dts/qcom/sm8350-hdk.dts | 8 > 1 file

Re: [PATCH 1/2] drm: Introduce plane SIZE_HINTS property

On 2/7/23 23:09, Ville Syrjala wrote: From: Ville Syrjälä Add a new immutable plane property by which a plane can advertise a handful of recommended plane sizes. This would be mostly exposed by cursor planes as a slightly more capable replacement for the DRM_CAP_CURSOR_WIDTH/HEIGHT caps, whi

Re: [PATCH v3 0/4] Reserve DSPPs based on user request

Hi, On Wed, Feb 8, 2023 at 5:42 AM Kalyan Thota wrote: > > This series will enable color features on sc7280 target which has > primary panel as eDP > > The series removes DSPP allocation based on encoder type and allows > the DSPP reservation based on user request via CTM. > > The series will rel

[PATCH] drm/vmwgfx: Stop accessing buffer objects which failed init

From: Zack Rusin ttm_bo_init_reserved on failure puts the buffer object back which causes it to be deleted, but kfree was still being called on the same buffer in vmw_bo_create leading to a double free. After the double free the vmw_gem_object_create_with_handle was setting the gem function obje

Re: [PATCH v3 1/6] drm/debugfs: Introduce wrapper for debugfs list

On Tue, Jan 31, 2023 at 04:58:21PM -0300, Maíra Canal wrote: > Introduce a struct wrapper for all the debugfs-related stuff: the list > of debugfs files and the mutex that protects it. This will make it > easier to initialize all the debugfs list in a DRM object and will > create a good abstraction

Re: DRM accel and debugfs/sysfs

On Tue, Feb 07, 2023 at 01:17:47PM -0300, Maíra Canal wrote: > On 2/7/23 12:43, Jeffrey Hugo wrote: > > On 2/7/2023 4:31 AM, Maíra Canal wrote: > > > Hi Stanislaw, > > > > > > On 2/1/23 12:20, Stanislaw Gruszka wrote: > > > > Hi > > > > > > > > I was about to send debugfs support for ivpu and not

Re: [PATCH v3 5/6] drm/debugfs: Make the show callback pass the pointer to the right object

On Tue, Jan 31, 2023 at 04:58:25PM -0300, Maíra Canal wrote: > Currently, the drivers need to access the struct drm_debugfs_entry to > get the proper device on the show callback. There is no need for such > thing, as you can wrap the show callback in order to provide to the > driver the proper para

Re: DRM accel and debugfs/sysfs

On Wed, Feb 8, 2023 at 8:07 PM Daniel Vetter wrote: > > On Tue, Feb 07, 2023 at 01:17:47PM -0300, Maíra Canal wrote: > > On 2/7/23 12:43, Jeffrey Hugo wrote: > > > On 2/7/2023 4:31 AM, Maíra Canal wrote: > > > > Hi Stanislaw, > > > > > > > > On 2/1/23 12:20, Stanislaw Gruszka wrote: > > > > > Hi >

Re: [PATCH v3 5/6] drm/debugfs: Make the show callback pass the pointer to the right object

On Wed, Feb 08, 2023 at 07:12:22PM +0100, Daniel Vetter wrote: > On Tue, Jan 31, 2023 at 04:58:25PM -0300, Maíra Canal wrote: > > Currently, the drivers need to access the struct drm_debugfs_entry to > > get the proper device on the show callback. There is no need for such > > thing, as you can wra

Re: [PATCH v3 1/6] drm/debugfs: Introduce wrapper for debugfs list

On Wed, Feb 08, 2023 at 07:06:19PM +0100, Daniel Vetter wrote: > On Tue, Jan 31, 2023 at 04:58:21PM -0300, Maíra Canal wrote: > > Introduce a struct wrapper for all the debugfs-related stuff: the list > > of debugfs files and the mutex that protects it. This will make it > > easier to initialize al

Re: DRM accel and debugfs/sysfs

On 2/8/23 15:13, Oded Gabbay wrote: On Wed, Feb 8, 2023 at 8:07 PM Daniel Vetter wrote: On Tue, Feb 07, 2023 at 01:17:47PM -0300, Maíra Canal wrote: On 2/7/23 12:43, Jeffrey Hugo wrote: On 2/7/2023 4:31 AM, Maíra Canal wrote: Hi Stanislaw, On 2/1/23 12:20, Stanislaw Gruszka wrote: Hi I w

[GIT PULL] etnaviv-next for 6.3

Hi Dave, hi Daniel, please pull the following etnaviv changes for the next merge window. This time we've added support for reporting of GPU load via the common fdinfo format, as already supported by multiple other drivers. Improved diagnostic messages for MMU faults. And finally added experimenta

Re: [PATCH v3 1/6] drm/debugfs: Introduce wrapper for debugfs list

On 2/8/23 15:06, Daniel Vetter wrote: On Tue, Jan 31, 2023 at 04:58:21PM -0300, Maíra Canal wrote: Introduce a struct wrapper for all the debugfs-related stuff: the list of debugfs files and the mutex that protects it. This will make it easier to initialize all the debugfs list in a DRM object a

Re: [PATCH v3 1/6] drm/debugfs: Introduce wrapper for debugfs list

On Wed, Feb 08, 2023 at 03:39:13PM -0300, Maíra Canal wrote: > On 2/8/23 15:06, Daniel Vetter wrote: > > On Tue, Jan 31, 2023 at 04:58:21PM -0300, Maíra Canal wrote: > > > Introduce a struct wrapper for all the debugfs-related stuff: the list > > > of debugfs files and the mutex that protects it. T

[PATCH] Revert "drm/i915/hwmon: Enable PL1 power limit"

This reverts commit 0349c41b05968befaffa5fbb7e73d0ee6004f610. 0349c41b0596 ("drm/i915/hwmon: Enable PL1 power limit") is incorrect and caused a major regression on ATSM. The change enabled the PL1 power limit but FW sets the default value of the PL1 limit to 0 which implies HW now works at minimum

Re: drm: panel-orientation-quirks: Add quirk for Lenovo IdeaPad Duet 3 10IGL5

I've resolved this by adding a matching quirk in drivers/firmware/efi/sysfb_efi.c - see below. Are you the right people to be notifying about this? --- diff --git a/kernel/6.2-rc6 original/sysfb_efi.c b/kernel/6.2-rc6 changes/sysfb_efi.c index 7882d4b..f06fdac 100755 --- a/kernel/6.2-rc6 original

Re: [PATCH v3 5/6] drm/debugfs: Make the show callback pass the pointer to the right object

On 2/8/23 15:17, Daniel Vetter wrote: On Wed, Feb 08, 2023 at 07:12:22PM +0100, Daniel Vetter wrote: On Tue, Jan 31, 2023 at 04:58:25PM -0300, Maíra Canal wrote: Currently, the drivers need to access the struct drm_debugfs_entry to get the proper device on the show callback. There is no need fo

[PATCH 0/5] drm/sched: Create wrapper to add a syncobj dependency to job

Some drivers perform the same operation to add a syncobj's fence to the sched as a dependency: first, call drm_syncobj_find_fence() to find the fence and then, call drm_sched_job_add_dependency(). Therefore, create a wrapper to encapsulate those steps in one single function. The first patch create

[PATCH 1/5] drm/sched: Create wrapper to add a syncobj dependency to job

In order to add a syncobj's fence as a dependency to a job, it is necessary to call drm_syncobj_find_fence() to find the fence and then add the dependency with drm_sched_job_add_dependency(). So, wrap these steps in one single function, drm_sched_job_add_syncobj_dependency(). Signed-off-by: Maíra

[PATCH 2/5] drm/lima: Use drm_sched_job_add_syncobj_dependency()

As lima_gem_add_deps() performs the same steps as drm_sched_job_add_syncobj_dependency(), replace the open-coded implementation in Lima in order to simply, using the DRM function. Signed-off-by: Maíra Canal --- drivers/gpu/drm/lima/lima_gem.c | 12 ++-- 1 file changed, 2 insertions(+), 1

[PATCH 3/5] drm/msm: Use drm_sched_job_add_syncobj_dependency()

As msm_parse_deps() performs the same steps as drm_sched_job_add_syncobj_dependency(), replace the open-coded implementation in msm in order to simply, using the DRM function. Signed-off-by: Maíra Canal --- drivers/gpu/drm/msm/msm_gem_submit.c | 8 ++-- 1 file changed, 2 insertions(+), 6 del

[PATCH 4/5] drm/panfrost: Use drm_sched_job_add_syncobj_dependency()

As panfrost_copy_in_sync() performs the same steps as drm_sched_job_add_syncobj_dependency(), replace the open-coded implementation in Panfrost in order to simply, using the DRM function. Signed-off-by: Maíra Canal --- drivers/gpu/drm/panfrost/panfrost_drv.c | 11 ++- 1 file changed, 2 i

[PATCH 5/5] drm/v3d: Use drm_sched_job_add_syncobj_dependency()

As v3d_job_add_deps() performs the same steps as drm_sched_job_add_syncobj_dependency(), replace the open-coded implementation in v3d in order to simply, using the DRM function. Signed-off-by: Maíra Canal --- drivers/gpu/drm/v3d/v3d_gem.c | 9 + 1 file changed, 1 insertion(+), 8 deletion

Re: [PATCH 1/5] drm/sched: Create wrapper to add a syncobj dependency to job

Am 08.02.23 um 20:48 schrieb Maíra Canal: In order to add a syncobj's fence as a dependency to a job, it is necessary to call drm_syncobj_find_fence() to find the fence and then add the dependency with drm_sched_job_add_dependency(). So, wrap these steps in one single function, drm_sched_job_add_

[PATCH] drm/amd/display: don't call dc_interrupt_set() for disabled crtcs

As made mention of in commit 4ea7fc09539b ("drm/amd/display: Do not program interrupt status on disabled crtc"), we shouldn't program disabled crtcs. So, filter out disabled crtcs in dm_set_vupdate_irq() and dm_set_vblank(). Fixes: 589d2739332d ("drm/amd/display: Use crtc enable/disable_vblank hoo

Re: [PATCH] Revert "drm/i915/hwmon: Enable PL1 power limit"

On Wed, Feb 08, 2023 at 11:03:12AM -0800, Ashutosh Dixit wrote: > This reverts commit 0349c41b05968befaffa5fbb7e73d0ee6004f610. > > 0349c41b0596 ("drm/i915/hwmon: Enable PL1 power limit") is incorrect and > caused a major regression on ATSM. The change enabled the PL1 power limit > but FW sets the

Re: [PATCH 4/5] drm/panfrost: Use drm_sched_job_add_syncobj_dependency()

R-b, thanks On Wed, Feb 08, 2023 at 04:48:16PM -0300, Ma??ra Canal wrote: > As panfrost_copy_in_sync() performs the same steps as > drm_sched_job_add_syncobj_dependency(), replace the open-coded > implementation in Panfrost in order to simply, using the DRM function. > > Signed-off-by: Ma??ra Can

Re: [PATCH] drm/amd/display: don't call dc_interrupt_set() for disabled crtcs

On 2/8/23 15:01, Hamza Mahfooz wrote: > As made mention of in commit 4ea7fc09539b ("drm/amd/display: Do not > program interrupt status on disabled crtc"), we shouldn't program > disabled crtcs. So, filter out disabled crtcs in dm_set_vupdate_irq() > and dm_set_vblank(). > > Fixes: 589d2739332d ("d

[PATCH v2 1/2] drm: Introduce plane SIZE_HINTS property

From: Ville Syrjälä Add a new immutable plane property by which a plane can advertise a handful of recommended plane sizes. This would be mostly exposed by cursor planes as a slightly more capable replacement for the DRM_CAP_CURSOR_WIDTH/HEIGHT caps, which can only declare a one size fits all lim

Re: [Intel-gfx] [PATCH 1/2] drm: Introduce plane SIZE_HINTS property

On Wed, Feb 08, 2023 at 03:03:49PM +0200, Ville Syrjälä wrote: > On Wed, Feb 08, 2023 at 02:13:12PM +0200, Pekka Paalanen wrote: > > On Wed, 8 Feb 2023 06:09:10 +0200 > > Ville Syrjala wrote: > > > > > From: Ville Syrjälä > > > > > > Add a new immutable plane property by which a plane can adve

[RFC PATCH] drm/msm/dpu: Move TE setup to prepare_for_kickoff()

Currently, DPU will enable TE during prepare_commit(). However, this will cause issues when trying to read/write to register in get_autorefresh_config(), because the core clock rates aren't set at that time. This used to work because phys_enc->hw_pp is only initialized in mode set [1], so the firs

[PATCH] drm/vmwgfx: Do not drop the reference to the handle too soon

From: Zack Rusin It is possible for userspace to predict the next buffer handle and to destroy the buffer while it's still used by the kernel. Delay dropping the internal reference on the buffers until kernel is done with them. Signed-off-by: Zack Rusin Fixes: 8afa13a0583f ("drm/vmwgfx: Impleme

Re: [PATCH v12 13/14] drm/msm/disp/dpu: add PSR support for eDP interface in dpu driver

On 07/02/2023 17:25, Dmitry Baryshkov wrote: On 07/02/2023 16:26, Vinod Polimera wrote: -Original Message- From: Dmitry Baryshkov Sent: Tuesday, January 31, 2023 6:29 PM To: Vinod Polimera (QUIC) ; dri- de...@lists.freedesktop.org; linux-arm-...@vger.kernel.org; freedr...@lists.freed

  1   2   >