On Wed, 13 Nov 2024, Sergey Senozhatsky wrote:
> On (24/10/31 19:51), Sergey Senozhatsky wrote:
>> intel_ddi_init() may skip connector initialization, for instance,
>> both intel_ddi_init_dp_connector() and intel_ddi_init_hdmi_connector()
>> are optional. This leads to situation that ->attached_c
On Wed, 13 Nov 2024 at 13:53, Fange Zhang wrote:
>
> From: Li Liu
>
> QCS615 platform uses the 14nm DSI PHY driver.
>
> Signed-off-by: Li Liu
> Signed-off-by: Fange Zhang
> ---
> Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --
On Wed, 13 Nov 2024 at 13:53, Fange Zhang wrote:
>
> From: Li Liu
>
> Add definitions for the display hardware
> used on the Qualcomm QCS615 platform.
>
> Signed-off-by: Li Liu
> Signed-off-by: Fange Zhang
> ---
> .../gpu/drm/msm/disp/dpu1/catalog/dpu_5_3_qcs615.h | 263
>
On Wed, 13 Nov 2024 at 13:53, Fange Zhang wrote:
>
> From: Li Liu
>
> Add display MDSS and DSI configuration for QCS615.
> QCS615 has a DP port, and DP support will be added in a later patch.
>
> Signed-off-by: Li Liu
> Signed-off-by: Fange Zhang
> ---
> arch/arm64/boot/dts/qcom/qcs615-ride.dt
Am 13.11.24 um 13:51 schrieb Huacai Chen:
Since ttm_bo_move_null() is exactly the same as ttm_resource_free() +
ttm_bo_assign_mem(), we use ttm_bo_move_null() for the GTT --> SYSTEM
move case too. Then the code is more consistent as the SYSTEM --> GTT
move case.
Signed-off-by: Huacai Chen
Loo
On 13.11.24 05:57, Matthew Wilcox wrote:
On Tue, Nov 12, 2024 at 03:22:46PM +0100, David Hildenbrand wrote:
On 12.11.24 14:53, Jason Gunthorpe wrote:
On Tue, Nov 12, 2024 at 10:10:06AM +0100, David Hildenbrand wrote:
On 12.11.24 06:26, Matthew Wilcox wrote:
I don't want you to respin. I thin
Hi Dave, Simona,
Next pull request, hopefully we'll have a v6.12 release soon!
Cheers,
~Maarten
drm-misc-next-2024-11-13:
drm-misc-next for v6.13-rc1:
Core Changes:
- Replace use of of_graph_get_next_endpoint by get_endpoint_by_regs in
core and drivers.
Driver Changes:
- Use drm_connector_h
On Wed, 13 Nov 2024 at 13:52, Fange Zhang wrote:
>
> This series aims to enable display on the QCS615 platform
>
> 1.Add MDSS & DPU support for QCS615
> 2.Add DSI support for QCS615
Please don't send next iterations until the discussion on the previous
one has finished.
>
> Note:
> items still b
Am 13.11.24 um 13:10 schrieb Vamsi Krishna Brahmajosyula:
From: Philip Yang
[ Upstream commit c86ad39140bbcb9dc75a10046c2221f657e8083b ]
Pass pointer reference to amdgpu_bo_unref to clear the correct pointer,
otherwise amdgpu_bo_unref clear the local variable, the original pointer
not set to N
Hey Yunfei,
On 20.07.2024 15:15, Yunfei Dong wrote:
The patch series used to enable secure video playback (SVP) on MediaTek
hardware in the Linux kernel.
I will set this series as obsolete for now, please answer the open
questions on your patches and then send a new series.
Regards,
Sebastian
On Wed, 13 Nov 2024 at 13:53, Fange Zhang wrote:
>
> From: Li Liu
>
> For the QCS615 ride board, enable the SX150X to activate the ANX7625
> allowing the DSI to output to the mDP through the external bridge.
> The ANX7625 relies on the SX150X chip to perform reset and HPD.
>
> Signed-off-by: Li L
Since ttm_bo_move_null() is exactly the same as ttm_resource_free() +
ttm_bo_assign_mem(), we use ttm_bo_move_null() for the GTT --> SYSTEM
move case too. Then the code is more consistent as the SYSTEM --> GTT
move case.
Signed-off-by: Huacai Chen
---
drivers/gpu/drm/radeon/radeon_ttm.c | 3 +--
From: Li Liu
Add support for DSI 2.3.1 (block used on QCS615).
Add phy configuration for QCS615
Signed-off-by: Li Liu
Signed-off-by: Fange Zhang
---
drivers/gpu/drm/msm/dsi/dsi_cfg.c | 17 +
drivers/gpu/drm/msm/dsi/dsi_cfg.h | 1 +
drivers/gpu/drm/msm/dsi/ph
From: Li Liu
For the QCS615 ride board, enable the SX150X to activate the ANX7625
allowing the DSI to output to the mDP through the external bridge.
The ANX7625 relies on the SX150X chip to perform reset and HPD.
Signed-off-by: Li Liu
Signed-off-by: Fange Zhang
---
arch/arm64/configs/defconfi
From: Li Liu
Document general compatibility of the DSI controller on QCS615.
Signed-off-by: Li Liu
Signed-off-by: Fange Zhang
---
Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git
a/Documentation/devicetree/bindings/displ
This series aims to enable display on the QCS615 platform
1.Add MDSS & DPU support for QCS615
2.Add DSI support for QCS615
Note:
items still being confirmed
- missing reg_bus_bw
- missing refgen supply
This patch series depends on below patch series:
- rpmhcc
https://lore.kernel
From: Li Liu
Document the MDSS and DPU hardware found on the Qualcomm QCS615 platform.
Signed-off-by: Li Liu
Signed-off-by: Fange Zhang
---
.../bindings/display/msm/qcom,qcs615-dpu.yaml | 118 ++
.../bindings/display/msm/qcom,qcs615-mdss.yaml | 252 +
2 fi
erence errors (make refcheckdocs):
See
https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20241113-add-display-support-for-qcs615-platform-v2-3-2873eb6fb...@quicinc.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran &#
Hi,
On Wed, Nov 13, 2024 at 11:40:14AM +0530, Parthiban wrote:
> No, Mixers in upstream refers to RT-Mixers inside the DE. It's only the
> quirk for R40/D1 setting the DE ports using mixer numbering.
After an hour or two of spelunking the code base, I'm still not sure about this.
Confusables:
-
From: Jocelyn Falempe
Virtio gpu supports the drm_panic module, which displays a message to
the screen when a kernel panic occurs.
Signed-off-by: Ryosuke Yasuoka
Signed-off-by: Jocelyn Falempe
---
v4:
- As per Dmitry's comment, make virtio_panic_buffer private to
virtio_gpu_device.
v3:
http
On 11/12/24 5:27 PM, John Watts wrote:
> Hey everyone,
>
> I'm not sure exactly where to add this but I discussed some of this with
> Parthiban on #linux-sunxi a few days ago, so I want to write it down
> before I work on the next version of the patch.
>
> I had assumed for some reason in my mind
On (24/10/31 19:51), Sergey Senozhatsky wrote:
> intel_ddi_init() may skip connector initialization, for instance,
> both intel_ddi_init_dp_connector() and intel_ddi_init_hdmi_connector()
> are optional. This leads to situation that ->attached_connector may
> be NULL for some connectors. For inst
Applied to drm-misc-next
On 11/6/2024 11:55 AM, Jacek Lawrynowicz wrote:
> Restore PCI state after putting the NPU in D0.
> Restoring state before powering up the device caused a Qemu crash
> if NPU was running in passthrough mode and recovery was performed.
>
> Fixes: 3534eacbf101 ("accel/ivpu:
Hi Dave,
On Tue Nov 12, 2024 at 7:59 PM WET, Dave Airlie wrote:
> On Tue, 12 Nov 2024 at 22:34, Linux regression tracking (Thorsten
> Leemhuis) wrote:
> >
> > [CCing Danilo, who committed the culprit]
> >
> > On 04.11.24 13:11, Diogo Ivo wrote:
> > > On Tue Oct 15, 2024 at 7:13 PM WEST, Linux reg
On 13/11/2024 11:26, AngeloGioacchino Del Regno wrote:
> The MediaTek MT8188 SoC has a Mali-G57 MC3 GPU and, similarly to
> MT8192, it has yet another special GPU ID.
>
> Add the GPU ID to the list and treat it as a standard Mali-G57.
>
> Signed-off-by: AngeloGioacchino Del Regno
>
Looks reaso
Am 13.11.24 um 14:48 schrieb Tvrtko Ursulin:
From: Tvrtko Ursulin
As commit 746ae46c1113 ("drm/sched: Mark scheduler work queues with
WQ_MEM_RECLAIM")
points out, ever since
a6149f039369 ("drm/sched: Convert drm scheduler to use a work queue rather than
kthread"),
any workqueue flushing done
On Wed, Nov 13, 2024 at 10:02:12AM +0100, Christian König wrote:
> Am 13.11.24 um 03:30 schrieb Matthew Brost:
> > [SNIP]
> > > > > If you're using gpuvm, just call drm_gpuvm_resv_add_fence. I assume
> > > > > AMD has a
> > > > > similarly simple call.
> > > > Nope, we try to avoid locking all BOs
devfreq_{resume,suspend}_device() don't bother undoing the suspend_count
modifications if something fails, so either it assumes failures are
harmless, or it's super fragile/buggy. In either case it's not something
we can address at the driver level, so let's just assume failures are
harmless for no
The Adreno GMU Management Unit (GNU) can also scale the DDR Bandwidth
along the Frequency and Power Domain level, but by default we leave the
OPP core vote for the interconnect ddr path.
While scaling via the interconnect path was sufficient, newer GPUs
like the A750 requires specific vote paremet
The Adreno GMU Management Unit (GMU) can also scale DDR Bandwidth along
the Frequency and Power Domain level, but by default we leave the
OPP core scale the interconnect ddr path.
In order to get the vote values to be used by the GPU Management
Unit (GMU), we need to parse all the possible OPP Ban
/adreno_gpu.h | 1 +
drivers/opp/core.c| 25 +
include/linux/pm_opp.h| 7 ++
10 files changed, 314 insertions(+), 19 deletions(-)
---
base-commit: 86313a9cd152330c634b25d826a281c6a002eb77
change-id: 20241113-topic-sm8x50-gpu-bw-vote-f5e022fe7a47
Best
On Wed, 13 Nov 2024 16:42:54 +0100
Boris Brezillon wrote:
> @@ -74,7 +76,8 @@ void panthor_device_unplug(struct panthor_device *ptdev)
>*/
> mutex_unlock(&ptdev->unplug.lock);
>
> - drm_WARN_ON(&ptdev->base, pm_runtime_get_sync(ptdev->base.dev) < 0);
> + ret = pm_runtime_g
Now all the DDR bandwidth voting via the GPU Management Unit (GMU)
is in place, let's declare the Bus Control Modules (BCMs) and
it's parameters in the GPU info struct and add the GMU_BW_VOTE
quirk to enable it.
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/msm/adreno/a6xx_catalog.c | 26 +++
Each GPU OPP requires a specific peak DDR bandwidth, let's add
those to each OPP and also the related interconnect path.
Signed-off-by: Neil Armstrong
---
arch/arm64/boot/dts/qcom/sm8650.dtsi | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8650.dtsi
The Adreno GPU Management Unit (GMU) can also scale the ddr
bandwidth along the frequency and power domain level, but for
now we statically fill the bw_table with values from the
downstream driver.
Only the first entry is used, which is a disable vote, so we
currently rely on scaling via the linux
Add and implement the dev_pm_opp_get_bandwidth() to retrieve
the OPP's bandwidth in the same was as the dev_pm_opp_get_voltage()
helper.
Retrieving bandwidth is required in the case of the Adreno GPU
where the GPU Management Unit can handle the Bandwidth scaling.
The helper can get the peak or ev
Each GPU OPP requires a specific peak DDR bandwidth, let's add
those to each OPP and also the related interconnect path.
Signed-off-by: Neil Armstrong
---
arch/arm64/boot/dts/qcom/sm8550.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8550.dtsi
b
Thanks for the feedback.
On Mon, Oct 28, 2024 at 8:09 PM Ville Syrjälä
wrote:
>
> On Mon, Oct 28, 2024 at 03:45:07PM +0200, Jani Nikula wrote:
> > On Sun, 27 Oct 2024, Vamsi Krishna Brahmajosyula
> > wrote:
> > > @@ -6320,19 +6321,20 @@ static void drm_parse_hdmi_deep_color_info(struct
> > > d
From: Li Liu
Add display MDSS and DSI configuration for QCS615 SoC.
Signed-off-by: Li Liu
Signed-off-by: Fange Zhang
---
arch/arm64/boot/dts/qcom/qcs615.dtsi | 186 ++-
1 file changed, 185 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/qcs6
From: Li Liu
QCS615 platform uses the 14nm DSI PHY driver.
Signed-off-by: Li Liu
Signed-off-by: Fange Zhang
---
Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml
On 11/11/24 05:08, Bhavin Sharma wrote:
The mode_422 variable is initialized to zero, making mode_422 ? 2 : 1
always false.
Since is_dsc_possible is already checked just above, there's no need to
check it again before filling out the DSC settings.
Removing this redundant check simplifies the
From: Tvrtko Ursulin
One alternative to the fix Christian proposed in
https://lore.kernel.org/dri-devel/20241024124159.4519-3-christian.koe...@amd.com/
is to replace the rather complex open coded sorting loops with the kernel
standard sort followed by a context squashing pass.
Proposed advantage
From: Tvrtko Ursulin
Testing some workloads in two different scenarios, such as games running
under Gamescope on a Steam Deck, or vkcube under a Plasma desktop, shows
that in a significant portion of calls the dma_fence_unwrap_merge helper
is called with just a single unsignalled fence.
Therefor
Am 12.11.24 um 17:33 schrieb Thomas Hellström:
[SNIP]
This has been extensively discussed already, but was expected to
really
only be needed for low-on-memory scenarios. However it now seems
like
the need is much earlier due to the random userptr page joining
by
core
mm.
Just to clarify here:
On 13/11/2024 10:13, Dan Carpenter wrote:
On Wed, Nov 13, 2024 at 09:53:49AM +, Colin Ian King wrote:
There is a spelling mistake in a dev_err message. Fix it.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/amdgpu/mes_v11_0.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
On Mon, 2024-11-11 at 13:41 +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> The upper layer transfer functions expect EBUSY as a return
> for when retries should be done.
>
> Fix the AUX error translation, but also check for both errors
> in a few places.
>
> Fixes: eb284f4b3781 ("drm/nouveau
On Wed, 2024-11-13 at 09:37 +0100, Christian König wrote:
> Am 12.11.24 um 17:33 schrieb Thomas Hellström:
> > [SNIP]
> > > > > This has been extensively discussed already, but was expected
> > > > > to
> > > > > really
> > > > > only be needed for low-on-memory scenarios. However it now
> > > > >
On Tue, 2024-11-12 at 12:08 -0800, Matthew Brost wrote:
> On Tue, Nov 12, 2024 at 10:06:21AM +0100, Philipp Stanner wrote:
> > Hi Matt,
> >
> > On Sat, 2024-11-09 at 09:29 -0800, Matthew Brost wrote:
> > > Follow the semantics of DMA_RESV_USAGE_PREEMPT in the DRM
> > > scheduler
> > > by
> > > sto
On 12/11/2024 12:19, Christian König wrote:
The function silently assumed that signaling was already enabled for the
dma_fence_array. This meant that without enabling signaling first we would
never see forward progress.
Fix that by falling back to testing each individual fence when signaling
i
There is a spelling mistake in a dev_err message. Fix it.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/amdgpu/mes_v11_0.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/mes_v11_0.c
b/drivers/gpu/drm/amd/amdgpu/mes_v11_0.c
index 9c905b9e93
Signed-off-by: wang wei
---
>diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
>index 80fef38d9d64..365c73be0bb4 100644
>--- a/include/linux/mm_types.h
>+++ b/include/linux/mm_types.h
>@@ -310,6 +310,7 @@ typedef struct {
> * @_hugetlb_cgroup: Do not use directly, use accessor in h
On Wed, Nov 13, 2024 at 09:53:49AM +, Colin Ian King wrote:
> There is a spelling mistake in a dev_err message. Fix it.
>
> Signed-off-by: Colin Ian King
> ---
> drivers/gpu/drm/amd/amdgpu/mes_v11_0.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/a
Reset DSI receiver logic during power on. The need for this change was
discovered when investigating issue with ADV7535. The symptom of the
problem was that ADV7535 continuously outputs a black image. This
happened for about 10% of the times that ADV7535 was powered on. The
rest of the times the im
Am 13.11.24 um 03:30 schrieb Matthew Brost:
[SNIP]
If you're using gpuvm, just call drm_gpuvm_resv_add_fence. I assume AMD has a
similarly simple call.
Nope, we try to avoid locking all BOs in the VM as hard as we can.
Why? Calling in to perform fence conversion shouldn't be all that
frequent
AUDIO_UPDATE bit (Bit 5 of MAIN register 0x4A) needs to be set to 1
while updating Audio InfoFrame information and then set to 0 when done.
Otherwise partially updated Audio InfoFrames could be sent out. Two
cases where this rule were not followed are fixed:
- In adv7511_hdmi_hw_params() make sure
On 11/13/24 5:03 AM, John Watts wrote:
> Hi there,
>
> On Tue, Nov 12, 2024 at 10:43:44PM +0530, Parthiban wrote:
>> #define TCON_TOP_PORT_DE0_MSK GENMASK(1, 0)
>> #define TCON_TOP_PORT_DE1_MSK GENMASK(5, 4)
>>
>> references towards DE0 and DE1 is for DE itself,
The MediaTek MT8188 SoC has a Mali-G57 MC3 GPU and, similarly to
MT8192, it has yet another special GPU ID.
Add the GPU ID to the list and treat it as a standard Mali-G57.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/panfrost/panfrost_gpu.c | 4
1 file changed, 4 insertio
Am 13.11.24 um 11:44 schrieb Thomas Hellström:
On Wed, 2024-11-13 at 09:37 +0100, Christian König wrote:
Am 12.11.24 um 17:33 schrieb Thomas Hellström:
[SNIP]
This has been extensively discussed already, but was expected
to
really
only be needed for low-on-memory scenarios. However it now
seem
Hello,
On Wed, Nov 13, 2024 at 03:58:25PM +0100, Maarten Lankhorst wrote:
...
> Thanks for all feedback and discussion. I checked mostly on patchwork so I
> missed the discussion here. Fortunately it's only been about naming. :)
>
> I'm thinking of adding a 'high' knob as well, that will work sim
Make the interface more symmetric by providing and using a
ttm_resource_cursor_init().
v10:
- Fix a stray newline (Matthew Brost)
- Update kerneldoc (Matthew Brost)
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Brost
Reviewed-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c |
Following the design direction communicated here:
https://lore.kernel.org/linux-mm/b7491378-defd-4f1c-31e2-29e4c77e2...@amd.com/T/#ma918844aa8a6efe8768fdcda0c6590d5c93850c9
Export a LRU walker for driver shrinker use. The walker
initially supports only trylocking, since that's the
method used by
The XE_PL_TT watermark was set to 50% of system memory.
The idea behind that was unclear since the net effect is that
TT memory will be evicted to TTM_PL_SYSTEM memory if that
watermark is exceeded, requiring PPGTT rebinds and dma
remapping. But there is no similar watermark for TTM_PL_1SYSTEM
memo
Add a number of helpers for shrinking that access core TTM and
core MM functionality in a way that make them unsuitable for
driver open-coding.
v11:
- New patch (split off from previous) and additional helpers.
v13:
- Adapt to ttm_backup interface change.
- Take resource off LRU when backed up.
S
Hi Stefan
Sorry for missing this one.
On Fri, 8 Nov 2024 at 18:55, Stefan Wahren wrote:
>
> Am 26.10.24 um 15:11 schrieb Stefan Wahren:
> > Hi,
> > during the investigations of the recent VC4 HDMI Sink issue [1], I was
> > able to reproduce another issue with vc4 after s2idle resume.
> > Sometim
Provide a helper to shrink ttm_tt page-vectors on a per-page
basis. A ttm_backup backend could then in theory get away with
allocating a single temporary page for each struct ttm_tt.
This is accomplished by splitting larger pages before trying to
back them up.
In the future we could allow ttm_bac
Rather than relying on the TTM watermark accounting add a shrinker
for xe_bos in TT or system memory.
Leverage the newly added TTM per-page shrinking and shmem backup
support.
Although xe doesn't fully support WONTNEED (purgeable) bos yet,
introduce and add shrinker support for purgeable ttm_tts.
Provide a standalone shmem backup implementation.
Given the ttm_backup interface, this could
later on be extended to providing other backup
implementation than shmem, with one use-case being
GPU swapout to a user-provided fd.
v5:
- Fix a UAF. (kernel test robot, Dan Carptenter)
v6:
- Rename ttm_ba
Use fault-injection to test partial TTM swapout and interrupted swapin.
Return -EINTR for swapin to test the callers ability to handle and
restart the swapin, and on swapout perform a partial swapout to test that
the swapin and release_shrunken functionality.
v8:
- Use the core fault-injection sys
This series implements TTM shrinker / eviction helpers and an xe bo
shrinker. It builds on a previous series, *and obsoletes that one*.
https://lore.kernel.org/linux-mm/b7491378-defd-4f1c-31e2-29e4c77e2...@amd.com/T/
Where the comment about layering
https://lore.kernel.org/linux-mm/b7491378-defd-
From: Li Liu
Add display MDSS and DSI configuration for QCS615.
QCS615 has a DP port, and DP support will be added in a later patch.
Signed-off-by: Li Liu
Signed-off-by: Fange Zhang
---
arch/arm64/boot/dts/qcom/qcs615-ride.dts | 109 +++
1 file changed, 109 inserti
From: Philip Yang
[ Upstream commit c86ad39140bbcb9dc75a10046c2221f657e8083b ]
Pass pointer reference to amdgpu_bo_unref to clear the correct pointer,
otherwise amdgpu_bo_unref clear the local variable, the original pointer
not set to NULL, this could cause use-after-free bug.
Signed-off-by: Ph
From: Tvrtko Ursulin
As commit 746ae46c1113 ("drm/sched: Mark scheduler work queues with
WQ_MEM_RECLAIM")
points out, ever since
a6149f039369 ("drm/sched: Convert drm scheduler to use a work queue rather than
kthread"),
any workqueue flushing done from the job submission path must only
involve
From: Li Liu
Add definitions for the display hardware
used on the Qualcomm QCS615 platform.
Signed-off-by: Li Liu
Signed-off-by: Fange Zhang
---
.../gpu/drm/msm/disp/dpu1/catalog/dpu_5_3_qcs615.h | 263 +
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 1 +
drivers/
From: Li Liu
Add support for MDSS on QCS615.
Signed-off-by: Li Liu
Signed-off-by: Fange Zhang
---
drivers/gpu/drm/msm/msm_mdss.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_mdss.c b/drivers/gpu/drm/msm/msm_mdss.c
index
b7bd899ead44bf86998e7295bccb31a334
On Mon, Nov 11, 2024 at 11:20:17PM +0800, yangerkun wrote:
>
>
> 在 2024/11/11 22:39, Chuck Lever III 写道:
> >
> >
> > > On Nov 10, 2024, at 9:36 PM, Yu Kuai wrote:
> > > I'm in the cc list ,so I assume you saw my set, then I don't know why
> > > you're ignoring my concerns.
> > > 1) next_offset
Hey,
Den 2024-11-06 kl. 19:20, skrev Tejun Heo:
On Wed, Nov 06, 2024 at 11:31:49AM +0100, Maxime Ripard wrote:
...
How about dmem for this one, and dpu for the other one. For device
memory and device processing unit, respectively.
dmem sounds great to me, does everyone agree?
Sounds good to
On Wed, 13 Nov 2024 16:42:54 +0100
Boris Brezillon wrote:
> @@ -541,17 +547,4 @@ int panthor_device_suspend(struct device *dev)
> clk_disable_unprepare(ptdev->clks.core);
> atomic_set(&ptdev->pm.state, PANTHOR_DEVICE_PM_STATE_SUSPENDED);
> return 0;
> -
> -err_set_active:
> -
If we do a GPU soft-reset, that's no longer fast reset. This also means
the slow reset fallback doesn't work because the MCU state is only reset
after a GPU soft-reset.
Let's move the retry logic to panthor_device_resume() to issue a
soft-reset between the fast and slow attempts, and patch
panthor
The runtime PM resume operation is not guaranteed to succeed, but if it
fails, the device should be in a suspended state. Make sure we're robust
to resume failures in the unplug path.
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/panthor/panthor_device.c | 23 ---
driver
Hello,
Here's a collection of patches improving robustness to failures in
the device resume/suspend path. Those failures are pretty hard to
reproduce (happens once in a while on a deqp-vk run), so I used a
mechanism to fake them.
Faking a FW boot failure is kinda tricky though, which means the
la
On 13/11/2024 14:26, Christian König wrote:
Am 13.11.24 um 14:48 schrieb Tvrtko Ursulin:
From: Tvrtko Ursulin
As commit 746ae46c1113 ("drm/sched: Mark scheduler work queues with
WQ_MEM_RECLAIM")
points out, ever since
a6149f039369 ("drm/sched: Convert drm scheduler to use a work queue
rat
Drop the _RD_ in the flag names.
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/panthor/panthor_fw.c | 62 ++--
1 file changed, 31 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/panthor/panthor_fw.c
b/drivers/gpu/drm/panthor/panthor_fw.c
index 2060085cc
When the runtime PM resume callback returns an error, it puts the device
in a state where it can't be resumed anymore. Make sure we can recover
from such transient failures by calling pm_runtime_set_suspended()
explicitly after a pm_runtime_resume_and_get() failure.
Signed-off-by: Boris Brezillon
The Adreno GMU Management Unit (GMU) can also scale the DDR Bandwidth
along the Frequency and Power Domain level, until now we left the OPP
core scale the OPP bandwidth via the interconnect path.
In order to enable bandwidth voting via the GPU Management
Unit (GMU), when an opp is set by devfreq w
WARN() will return true if the condition is true, false otherwise.
If we store the return of drm_WARN_ON() in ret, we lose the actual
error code.
Fixes: 5fe909cae118 ("drm/panthor: Add the device logical block")
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/panthor/panthor_device.c | 4 ++--
kvfree(queue_args);
return ret;
}
---
base-commit: 9f8e716d46c68112484a23d1742d9ec725e082fc
change-id: 20241113-panthor-fix-gcq-bailout-2d9ac36590ed
--
Jann Horn
Le 12/11/2024 à 23:43, Laurent Pinchart a écrit :
Hi Christophe,
Thank you for the patch.
On Tue, Nov 12, 2024 at 10:12:25PM +0100, Christophe JAILLET wrote:
'struct i2c_device_id' is not modified in these drivers.
Constifying this structure moves some data to a read-only section, so
increase
Hi Thomas,
kernel test robot noticed the following build errors:
[auto build test ERROR on drm-xe/drm-xe-next]
[also build test ERROR on linus/master v6.12-rc7 next-20241113]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use
Hi Thomas,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-xe/drm-xe-next]
[also build test WARNING on linus/master v6.12-rc7 next-20241113]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to
Add support for the KDB KD116N2130B12, pleace the EDID here for
subsequent reference.
00 ff ff ff ff ff ff 00 2c 82 07 17 00 00 00 00
1c 21 01 04 95 1a 0e 78 0a 63 25 99 5b 5d 96 26
18 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01
01 01 01 01 01 01 87 1b 56 88 50 00 0e 30 28 20
55 00 00 90 10 00 00
On 11/12/24 8:57 PM, Matthew Wilcox wrote:
On Tue, Nov 12, 2024 at 03:22:46PM +0100, David Hildenbrand wrote:
On 12.11.24 14:53, Jason Gunthorpe wrote:
On Tue, Nov 12, 2024 at 10:10:06AM +0100, David Hildenbrand wrote:
On 12.11.24 06:26, Matthew Wilcox wrote:
...
I've certainly considered go
On 13-11-24, 16:48, Neil Armstrong wrote:
> Add and implement the dev_pm_opp_get_bandwidth() to retrieve
> the OPP's bandwidth in the same was as the dev_pm_opp_get_voltage()
way
> helper.
>
> Retrieving bandwidth is required in the case of the Adreno GPU
> wher
Hi,
At 2024-05-06 15:44:36, "Quentin Schulz" wrote:
>Hi Heiko,
>
>On 4/25/24 9:55 PM, Heiko Stuebner wrote:
>> From: Heiko Stuebner
>>
>> The clock is in Hz while the value checked against is in kHz, so
>> actual frequencies will never be able to be below to max value.
>> Fix this by specifyin
From: Dave Airlie
When this code moved to non-coherent allocator the sync was put too
early for some firmwares which called the setup function, move the
sync down after the setup function.
Reported-by: Diogo Ivo
Tested-by: Diogo Ivo
Fixes: 9b340aeb26d5 ("nouveau/firmware: use dma non-coherent
This patch series aims to add ITE IT6263 LVDS to HDMI converter on
i.MX8MP EVK.
Since IT6263 DT binding and driver were picked up from v5 and landed
in drm-misc, this patch series contains patches almost all i.MX8MP
SoC/platform specific.
Patch 1 is a preparation patch to allow display mode of an
Multiple display modes could be read from a display device's EDID.
Use clk_round_rate() to validate the "ldb" clock rate for each mode
in drm_bridge_funcs::mode_valid() to filter unsupported modes out.
Signed-off-by: Liu Ying
---
Note that this patch depends on a patch in shawnguo/imx/fixes:
http
The next bridge in bridge chain could be a panel bridge or a non-panel
bridge. Use devm_drm_of_get_bridge() to replace the combination
function calls of of_drm_find_panel() and devm_drm_panel_bridge_add()
to get either a panel bridge or a non-panel bridge, instead of getting
a panel bridge only.
This reverts commit ff06ea04e4cf3ba2f025024776e83bfbdfa05155.
media_disp1_pix clock is the pixel clock of the first i.MX8MP LCDIFv3
display controller, while media_disp2_pix clock is the pixel clock of
the second i.MX8MP LCDIFv3 display controller. The two display
controllers connect with Samsung
Same to "ldb" clock rate validation, call clk_round_rate() to validate
"pix"(pixel clock) rate too. This may filter modes out whose pixel
clock rates cannot be supported by the pixel clock tree. For example,
when the pixel clock is derived from the i.MX8MP video_pll1_out clock
and video_pll1_out
ITE IT6263 LVDS to HDMI converter is populated on NXP IMX-LVDS-HDMI
and IMX-DLVDS-HDMI adapter cards. The adapter cards can connect to
i.MX8MP EVK base board to support video output through HDMI connectors.
Build the ITE IT6263 driver as a module.
Signed-off-by: Liu Ying
Reviewed-by: Biju Das
-
1 - 100 of 107 matches
Mail list logo
