On Wed, Nov 13, 2024 at 04:48:32PM +0100, Neil Armstrong wrote:
> Now all the DDR bandwidth voting via the GPU Management Unit (GMU)
> is in place, let's declare the Bus Control Modules (BCMs) and
s/let's //g
> it's parameters in the GPU info struct and add the GMU_BW_VOTE
> quirk to enable it.
On Wed, Nov 13, 2024 at 04:48:30PM +0100, Neil Armstrong wrote:
> 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
On Wed, Nov 13, 2024 at 04:48:29PM +0100, Neil Armstrong wrote:
> 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 b
On Wed, Nov 13, 2024 at 04:48:28PM +0100, Neil Armstrong wrote:
> 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 pa
Hi Dave and Simona,
A few more drm-xe fixes for this week.
thanks
Lucas De Marchi
drm-xe-fixes-2024-11-14:
Driver Changes:
- Fix unlock on exec ioctl error path (Matthew Brost)
- Fix hibernation on LNL due to ggtt getting lost
(Matthew Brost / Matthew Auld)
- Fix missing runtime PM in OA rele
This was previously attempted as xe specific reset uevent but dropped
in commit 77a0d4d1cea2 ("drm/xe/uapi: Remove reset uevent for now")
as part of refactoring.
Now that we have device wedged event provided by DRM core, make use
of it and support both driver rebind and bus-reset based recovery.
W
Add documentation for device wedged event in a new 'Device wedging'
chapter. The describes basic definitions and consumer expectations
along with an example.
v8: Improve documentation (Christian, Rodrigo)
v9: Add prerequisites section (Christian)
Signed-off-by: Raag Jadav
---
Documentation/gpu/
Now that we have device wedged event provided by DRM core, make use
of it and support both driver rebind and bus-reset based recovery.
With this in place, userspace will be notified of wedged device on
gt reset failure.
Signed-off-by: Raag Jadav
---
drivers/gpu/drm/i915/gt/intel_reset.c | 3 +++
Introduce device wedged event, which notifies userspace of 'wedged'
(hanged/unusable) state of the DRM device through a uevent. This is
useful especially in cases where the device is no longer operating as
expected and has become unrecoverable from driver context. Purpose of
this implementation is
This series introduces device wedged event in DRM subsystem and uses
it in xe and i915 drivers. Detailed description in commit message.
This was earlier attempted as xe specific uevent in v1 and v2.
https://patchwork.freedesktop.org/series/136909/
Similar work by André Almeida.
https://lore.kerne
Clang static checker(scan-build) warning：
drivers/gpu/drm/xe/xe_hw_engine_group.c: line 134, column 2
Argument to kfree() is a constant address (18446744073709551604), which
is not memory allocated by malloc().
kfree() can only handle NULL pointers instead of negitave error codes.
When hw_engine_g
On (24/11/14 17:53), Jani Nikula wrote:
> > Ville, we handle intel_ddi_init_dp_connector() failures but not
> > intel_ddi_init_hdmi_connector() failures. Do you recall if there's a
> > reason for that? Something like a dual-mode port where DP works but HDMI
> > gets rejected because of bogus VBT in
From: Zichen Xie
Like commit ac19c4c3d02e ("bcachefs: Use array_size() in call to
copy_from_user()"), it's a safer way to use helper array_size() in
copy_from_user() to avoid potential overflow issues.
Fixes: 7520a277d97b ("drm: Extract drm_framebuffer.[hc]")
Signed-off-by: Zichen Xie
---
driv
Hello Akhil,
On Thu, 14 Nov 2024 at 20:50, Akhil P Oommen wrote:
>
> On 11/1/2024 9:54 PM, Akhil P Oommen wrote:
> > On 10/25/2024 11:58 AM, Dmitry Baryshkov wrote:
> >> On Thu, Oct 24, 2024 at 12:56:58AM +0530, Akhil P Oommen wrote:
> >>> On 10/22/2024 11:19 AM, Krzysztof Kozlowski wrote:
>
Applied. Thanks!
Alex
On Wed, Nov 13, 2024 at 8:04 AM Christian König
wrote:
>
> 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
On Thu, Nov 14, 2024 at 10:21 AM Christian König
wrote:
>
> Am 14.11.24 um 16:11 schrieb Bhavin Sharma:
> > Since is_dsc_possible is already checked just above, there's no need to
> > check it again before filling out the DSC settings.
> >
> > Signed-off-by: Bhavin Sharma
> > ---
> > drivers/gp
Applied. Thanks!
On Thu, Nov 14, 2024 at 10:12 AM Bhavin Sharma
wrote:
>
> The check for tools_size being non-zero is redundant as tools_size is
> explicitly set to a non-zero value (0x19000). Removing the if condition
> simplifies the code without altering functionality.
>
> Signed-off-by: Bhav
Hi,
On Wed, Nov 13, 2024 at 1:00 AM Langyan Ye
wrote:
>
> 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
>
On Thu, Nov 14, 2024 at 10:44 AM Christian König
wrote:
>
> Just a straightforward conversion without any optimization.
>
> Only compile tested for now.
>
> v2: rebase
>
> Signed-off-by: Christian König
Acked-by: Alex Deucher
> ---
> drivers/gpu/drm/qxl/Kconfig | 1 +
> drivers/gpu/drm
On Thu, Nov 14, 2024 at 10:30 AM Christian König
wrote:
>
> Just a straightforward conversion without any optimization.
>
> Smoke tested on actual hardware.
>
> v2: rebase
>
> Signed-off-by: Christian König
Acked-by: Alex Deucher
> ---
> drivers/gpu/drm/radeon/Kconfig | 1 +
> driver
On Mon, Nov 04, 2024 at 10:13:51AM +0100, Alain Volmat wrote:
> Hi Raphael,
>
> On Tue, Oct 29, 2024 at 07:30:41PM +0100, Raphael Gallais-Pou wrote:
> > Add myself as a maintainer for STi driver changes.
> >
> > Signed-off-by: Raphael Gallais-Pou
> > ---
> > MAINTAINERS | 1 +
> > 1 file change
On 11/1/2024 9:54 PM, Akhil P Oommen wrote:
> On 10/25/2024 11:58 AM, Dmitry Baryshkov wrote:
>> On Thu, Oct 24, 2024 at 12:56:58AM +0530, Akhil P Oommen wrote:
>>> On 10/22/2024 11:19 AM, Krzysztof Kozlowski wrote:
On Mon, Oct 21, 2024 at 05:23:43PM +0530, Akhil P Oommen wrote:
> Add a ne
On Fri, 21 Jun 2024 22:17:55 +0200, Lucas Stach wrote:
> When the DP output is routed to a external connector there is no
> need for a fixed panel, as the panel may be detected via EDID on
> the AUX channel. Allow to continue probing if no panel reference
> is present.
>
>
Applied, thanks!
[1
On 14/11/2024 19:05, Fedor Pchelkin wrote:
On Thu, 14. Nov 17:47, Jocelyn Falempe wrote:
On 11/11/2024 17:33, Murad Masimov wrote:
If the value of the clock variable is higher than 80, the value of the
variable m, which is used as a divisor, will remain zero, because
(clock * testp) will be
On Thu, 14. Nov 17:47, Jocelyn Falempe wrote:
> On 11/11/2024 17:33, Murad Masimov wrote:
> > If the value of the clock variable is higher than 80, the value of the
> > variable m, which is used as a divisor, will remain zero, because
> > (clock * testp) will be higher than vcomax in every loop
On 11/14/2024 8:57 PM, Konrad Dybcio wrote:
> On 12.11.2024 10:15 PM, Akhil P Oommen wrote:
>> On 11/11/2024 8:38 PM, Rob Clark wrote:
>>> On Sun, Nov 10, 2024 at 9:31 AM Bjorn Andersson
>>> wrote:
Support for per-process page tables requires the SMMU aparture to be
setup such that
On Thu, Nov 14, 2024 at 04:30:19PM +0100, Christian König wrote:
XE switched over to drm_exec quite some time ago.
Signed-off-by: Christian König
Acked-by: Lucas De Marchi
I guess you will want to apply this through drm-misc so you can merge
the last commit. Otherwise let me know and I can
On 11/11/2024 17:33, Murad Masimov wrote:
If the value of the clock variable is higher than 80, the value of the
variable m, which is used as a divisor, will remain zero, because
(clock * testp) will be higher than vcomax in every loop iteration, which
leads to skipping every iteration and le
Hi,
On Thu, 26 Sep 2024 16:12:46 +0200, Francesco Dolcini wrote:
> Wait for the command transmission to be completed in the DSI transfer
> function polling for the dc_start bit to go back to idle state after the
> transmission is started.
>
> This is documented in the datasheet and failures to do
On 14/11/2024 13:48, Christian König wrote:
Am 14.11.24 um 12:14 schrieb Tvrtko Ursulin:
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
On Wed, 13 Nov 2024, Jani Nikula wrote:
> 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 optio
Just a straightforward conversion without any optimization.
Only compile tested for now.
v2: rebase
Signed-off-by: Christian König
---
drivers/gpu/drm/qxl/Kconfig | 1 +
drivers/gpu/drm/qxl/qxl_drv.h | 7 ++--
drivers/gpu/drm/qxl/qxl_release.c | 68 ---
Hi guys,
switching the remaining driver over to drm_exec, cleaning up XE and the
finally remove ttm_execbug_util since it isn't used any more.
When I originally posted the patch set for drm_exec vmwgfx was to
complicated to trivially switch over. This is now done with this patch
set.
Additional
Just a straightforward conversion without any optimization.
Smoke tested on actual hardware.
v2: rebase
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/Kconfig | 1 +
drivers/gpu/drm/radeon/radeon.h| 7 ++--
drivers/gpu/drm/radeon/radeon_cs.c | 45 +-
Basically just switching over to the new infrastructure like we did for
other drivers as well.
No intentional functional change, but only compile tested.
Signed-off-by: Christian König
---
drivers/gpu/drm/vmwgfx/vmwgfx_validation.c | 56 +-
drivers/gpu/drm/vmwgfx/vmwgfx_vali
Replaced by drm_exec and not used any more.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/Makefile | 4 +-
drivers/gpu/drm/ttm/ttm_execbuf_util.c | 161 -
include/drm/ttm/ttm_execbuf_util.h | 119 --
3 files changed, 2 insertions(+
Finish remove the ttm_eu depoendency.
No functional difference.
Signed-off-by: Christian König
---
drivers/gpu/drm/vmwgfx/vmwgfx_context.c | 16 ++---
drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c | 12 +-
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 1 -
drivers/gpu/d
XE switched over to drm_exec quite some time ago.
Signed-off-by: Christian König
---
drivers/gpu/drm/xe/xe_bo_types.h | 1 -
drivers/gpu/drm/xe/xe_gt_pagefault.c | 1 -
drivers/gpu/drm/xe/xe_vm.c | 1 -
drivers/gpu/drm/xe/xe_vm.h | 1 -
4 files changed, 4 deletions(-)
di
Start switching over vmwgfx to drm_exec as well. Replacing some
unnecessary complex calls with just just single BO dma_resv locking.
No intentional functional change, but only compile tested for now.
Signed-off-by: Christian König
---
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 49 --
On 12.11.2024 10:15 PM, Akhil P Oommen wrote:
> On 11/11/2024 8:38 PM, Rob Clark wrote:
>> On Sun, Nov 10, 2024 at 9:31 AM Bjorn Andersson
>> wrote:
>>>
>>> Support for per-process page tables requires the SMMU aparture to be
>>> setup such that the GPU can make updates with the SMMU. On some targ
On Thu, Nov 14, 2024 at 02:12:01PM +0100, Maxime Ripard wrote:
> On Tue, Oct 29, 2024 at 10:53:49PM +0800, Fei Shao wrote:
> > On Thu, Oct 24, 2024 at 8:36 PM Maxime Ripard wrote:
> > >
> > > On Wed, Oct 09, 2024 at 01:23:31PM +0800, Fei Shao wrote:
> > > > In the mtk_dsi driver, its DSI host atta
Am 14.11.24 um 16:11 schrieb Bhavin Sharma:
Since is_dsc_possible is already checked just above, there's no need to
check it again before filling out the DSC settings.
Signed-off-by: Bhavin Sharma
---
drivers/gpu/drm/amd/display/dc/dsc/dc_dsc.c | 13 +
1 file changed, 5 insertion
The check for tools_size being non-zero is redundant as tools_size is
explicitly set to a non-zero value (0x19000). Removing the if condition
simplifies the code without altering functionality.
Signed-off-by: Bhavin Sharma
---
.../amd/pm/powerplay/smumgr/vega12_smumgr.c | 24 +-
Since is_dsc_possible is already checked just above, there's no need to
check it again before filling out the DSC settings.
Signed-off-by: Bhavin Sharma
---
drivers/gpu/drm/amd/display/dc/dsc/dc_dsc.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/d
Change in V2:
in patch 1/2:
- Remove mode_422 condition check because that
is fixed in amd-staging-drm-next
Link for v1:
https://lore.kernel.org/dri-devel/2024120900.63869-1-bhavin.sha...@siliconsignals.io/T/#t
Bhavin Sharma (2):
drm/amd/display: remove redundant is_dsc_
Hi,
On Sat, Nov 09, 2024 at 02:35:05PM +0200, Dmitry Baryshkov wrote:
> Add drm_hdmi_connector_mode_valid(), generic helper for HDMI connectors.
> It can be either used directly or as a part of the .mode_valid callback.
>
> Signed-off-by: Dmitry Baryshkov
> ---
> drivers/gpu/drm/display/drm_hdm
On Thu, 14 Nov 2024 11:01:07 +0100
Pierre-Eric Pelloux-Prayer wrote:
> A fence uniquely identify a job, so this commits updates the places
> where a kernel pointer was used as an identifier by:
>
>"fence=(context:%llu, seqno:%lld)"
>
> Signed-off-by: Pierre-Eric Pelloux-Prayer
> ---
> ...
On 11/12/24 21:28, Suraj Sonawane wrote:
Fix an error detected by the Smatch tool:
drivers/video/fbdev/metronomefb.c:220 load_waveform() error:
buffer overflow 'wfm_hdr->stuff2a' 2 <= 4
drivers/video/fbdev/metronomefb.c:220 load_waveform() error:
buffer overflow 'wfm_hdr->stuff2a' 2 <= 4
The ac
On 10/27/24 00:01, li...@treblig.org wrote:
From: "Dr. David Alan Gilbert"
commit f76ee892a99e ("omapfb: copy omapdss & displays for omapfb")
took a copy of the omapdrm code into omapfb, however at that point
a couple of functions were already unused at that point.
Remove dispc_mgr_get_clock_d
Hi Dave, Simona,
Last fixes for 6.12.
The following changes since commit 2d5404caa8c7bb5c4e0435f94b28834ae5456623:
Linux 6.12-rc7 (2024-11-10 14:19:35 -0800)
are available in the Git repository at:
https://gitlab.freedesktop.org/agd5f/linux.git
tags/amd-drm-fixes-6.12-2024-11-14
for you
Hi Dave, Sima,
here's the drm-misc-fixes PR for this week.
Best regards
Thomas
drm-misc-fixes-2024-11-14:
Short summary of fixes pull:
bridge:
- tc358768: Fix DSI command tx
nouveau:
- Fix GSP AUX error handling
- dp: Handle retires for AUX CH transfers with GSP
- fw: Sync DMA after setup
pan
On 10/28/24 11:41, Dmitry Baryshkov wrote:
On Sat, Oct 26, 2024 at 11:56:34AM +0800, Zhen Lei wrote:
When information such as info->screen_base is not ready, calling
sh7760fb_free_mem() does not release memory correctly. Call
dma_free_coherent() instead.
Fixes: 4a25e41831ee ("video: sh7760fb: S
On 12.11.2024 7:22 PM, Colin Ian King wrote:
> The call chain on a5xx_gpu_init is such that pdev is not going to be
> null, so the null check on pdev can be removed. This also cleans up
> a static analysis warning where pdev is dereferenced before the null
> check which cannot actually occur.
>
>
Am 14.11.24 um 12:14 schrieb Tvrtko Ursulin:
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 b
On 13.11.2024 12:51 PM, Fange Zhang wrote:
> 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/dr
On Thu, 14 Nov 2024 at 15:32, Konrad Dybcio
wrote:
>
> On 13.11.2024 12:51 PM, Fange Zhang wrote:
> > 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
On Tue, Oct 29, 2024 at 10:53:49PM +0800, Fei Shao wrote:
> On Thu, Oct 24, 2024 at 8:36 PM Maxime Ripard wrote:
> >
> > On Wed, Oct 09, 2024 at 01:23:31PM +0800, Fei Shao wrote:
> > > In the mtk_dsi driver, its DSI host attach callback calls
> > > devm_drm_of_get_bridge() to get the next bridge.
On Tue, Nov 12, 2024 at 03:41:00PM +0800, Rex Nie wrote:
> In pll_get_integloop_gain(), digclk_divsel=1 or 2, base=63 or 196ULL,
> so the base may be 63, 126, 196, 392. The condition base <= 2046
> always true.
>
> Fixes: caedbf17c48d ("drm/msm: add msm8998 hdmi phy/pll support")
> Signed-off-by:
On 14/11/2024 10:01, Pierre-Eric Pelloux-Prayer wrote:
This will be used in a later commit to trace the drm client_id in
some of the gpu_scheduler trace events.
I wonder if it would be tidier to store the drm_client_id in the entity
via drm_sched_entity_init? It would still required tricklin
On 14/11/2024 10:01, Pierre-Eric Pelloux-Prayer wrote:
A fence uniquely identify a job, so this commits updates the places
where a kernel pointer was used as an identifier by:
"fence=(context:%llu, seqno:%lld)"
Any special reason for %lld? Planning to use like -1 for unknown or
somethin
On Wed, Nov 13, 2024 at 04:42:54PM +0100, Boris Brezillon wrote:
> 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
> ---
>
On Thu, Nov 14, 2024 at 12:27:55PM +0100, Boris Brezillon wrote:
> On Thu, 14 Nov 2024 11:13:29 +
> Liviu Dudau wrote:
>
> > On Wed, Nov 13, 2024 at 04:42:54PM +0100, Boris Brezillon wrote:
> > > The runtime PM resume operation is not guaranteed to succeed, but if it
> > > fails, the device s
Hi,
Am Donnerstag, dem 14.11.2024 um 11:01 +0100 schrieb Pierre-Eric
Pelloux-Prayer:
> This commit adds a document section in drm-uapi.rst about tracepoints,
> and mark the events gpu_scheduler_trace.h as stable uAPI.
>
> The goal is to explicitly state that tools can rely on the fields,
> format
On Thu, 14 Nov 2024 11:13:29 +
Liviu Dudau wrote:
> On Wed, Nov 13, 2024 at 04:42:54PM +0100, Boris Brezillon wrote:
> > 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
On Thu, 14 Nov 2024 10:51:01 +
Steven Price wrote:
> On 13/11/2024 15:42, Boris Brezillon wrote:
> > 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
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
On 14/11/2024 09:05, Christian König wrote:
Am 13.11.24 um 18:19 schrieb Tvrtko Ursulin:
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
On 13/11/2024 21:03, Jann Horn wrote:
> When bailing out due to group_priority_permit() failure, the queue_args
> need to be freed. Fix it by rearranging the function to use the
> goto-on-error pattern, such that the success case flows straight without
> indentation while error cases jump forward t
Hi Christophe,
On Wed, Nov 13, 2024 at 10:19:24PM +0100, Christophe JAILLET wrote:
> Le 12/11/2024 à 23:43, Laurent Pinchart a écrit :
> > 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 st
On Wed, Nov 13, 2024 at 05:02:57PM +0100, Boris Brezillon wrote:
> Drop the _RD_ in the flag names.
>
> Signed-off-by: Boris Brezillon
Acked-by: Liviu Dudau
Best regards,
Liviu
> ---
> drivers/gpu/drm/panthor/panthor_fw.c | 62 ++--
> 1 file changed, 31 insertions(+),
On Wed, Nov 13, 2024 at 10:03:39PM +0100, Jann Horn wrote:
> When bailing out due to group_priority_permit() failure, the queue_args
> need to be freed. Fix it by rearranging the function to use the
> goto-on-error pattern, such that the success case flows straight without
> indentation while error
On 13/11/2024 15:42, Boris Brezillon wrote:
> 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-res
On 13/11/2024 15:42, Boris Brezillon wrote:
> 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
On 13/11/2024 15:42, Boris Brezillon wrote:
> 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 leve
On 13/11/2024 15:42, Boris Brezillon wrote:
> 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
On 13/11/2024 16:02, Boris Brezillon wrote:
> Drop the _RD_ in the flag names.
>
> Signed-off-by: Boris Brezillon
Reviewed-by: Steven Price
> ---
> drivers/gpu/drm/panthor/panthor_fw.c | 62 ++--
> 1 file changed, 31 insertions(+), 31 deletions(-)
>
> diff --git a/dri
Hi Quetin,
At 2024-11-14 17:38:56, "Quentin Schulz" wrote:
>Hi Andy,
>
>On 11/14/24 1:50 AM, Andy Yan wrote:
>>
>> 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 w
Hi,
The initial goal of this series was to improve the drm and amdgpu
trace events to be able to expose more of the inner workings of
the scheduler and drivers to developers via tools.
Then, the series evolved to become focused only on gpu_scheduler.
The changes around vblank events will be part
This commit adds a document section in drm-uapi.rst about tracepoints,
and mark the events gpu_scheduler_trace.h as stable uAPI.
The goal is to explicitly state that tools can rely on the fields,
formats and semantics of these events.
Acked-by: Lucas Stach
Acked-by: Maíra Canal
Signed-off-by: P
For processes with multiple drm_file instances, the drm_client_id is
the only way to map jobs back to their unique owner.
It's even more useful if drm client_name is set, because now a tool
can map jobs to the client name instead of only having access to
the process name.
Signed-off-by: Pierre-Er
Trace the fence dependencies similarly to how we print fences:
... , dependencies:{(context:606, seqno:38006)}
This allows tools to analyze the dependencies between the jobs (previously
it was only possible for fences traced by drm_sched_job_wait_dep).
Since drm_sched_job and drm_run_job use th
A fence uniquely identify a job, so this commits updates the places
where a kernel pointer was used as an identifier by:
"fence=(context:%llu, seqno:%lld)"
Signed-off-by: Pierre-Eric Pelloux-Prayer
---
.../gpu/drm/scheduler/gpu_scheduler_trace.h | 39 +++
1 file changed, 22
Until the switch from kthread to workqueue, a userspace application could
determine the source device from the pid of the thread sending the event.
With workqueues this is not possible anymore, so the event needs to contain
the dev_name() to identify the device.
Signed-off-by: Pierre-Eric Pelloux
This will be used in a later commit to trace the drm client_id in
some of the gpu_scheduler trace events.
Signed-off-by: Pierre-Eric Pelloux-Prayer
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 3 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_j
client_id is a unique id used by fdinfo. Having it listed in 'clients'
output means a userspace application can correlate the fields, eg:
given a fdinfo id get the fdinfo name.
Signed-off-by: Pierre-Eric Pelloux-Prayer
---
drivers/gpu/drm/drm_debugfs.c | 10 ++
1 file changed, 6 insertio
Hello Neil,
On Wed, Oct 23, 2024 at 10:03:20AM +0200, Neil Armstrong wrote:
> On 26/09/2024 16:12, Francesco Dolcini wrote:
> > From: Francesco Dolcini
> >
> > Wait for the command transmission to be completed in the DSI transfer
> > function polling for the dc_start bit to go back to idle state
> - drm_mode_copy(&tc->mode, mode);
> + drm_mode_copy(&tc->mode, adj);
> }
>
> static const struct drm_edid *tc_edid_read(struct drm_bridge *bridge,
>
This unfortunately breaks my DSI->DP setup on TQMa8MPxL/MBa8MPxL.
When I revert it, DP works again
Hi,
On 14/11/2024 05:10, Viresh Kumar wrote:
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 req
Am 13.11.24 um 18:19 schrieb Tvrtko Ursulin:
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 b
On 14/11/2024 08:53, Christian König wrote:
Am 13.11.24 um 18:19 schrieb Tvrtko Ursulin:
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 cal
Hello dri maintainers/developers,
This is a 31-day syzbot report for the dri subsystem.
All related reports/information can be found at:
https://syzkaller.appspot.com/upstream/s/dri
During the period, 0 new issues were detected and 0 were fixed.
In total, 16 issues are still open and 31 have alre
Am 13.11.24 um 18:19 schrieb Tvrtko Ursulin:
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
On 2024/10/29 16:34, Chen Ridong wrote:
> From: Chen Ridong
>
> The 'vmw_user_object_buffer' function may return NULL with incorrect
> inputs. To avoid possible null pointer dereference, add a check whether
> the 'bo' is NULL in the vmw_framebuffer_surface_create_handle.
>
> Fixes: d6667f0ddf
On 11.11.24 23:53, Maarten Lankhorst wrote:
Den 2024-10-28 kl. 15:53, skrev Friedrich Vock:
On 23.10.24 09:52, Maarten Lankhorst wrote:
The initial version was based roughly on the rdma and misc cgroup
controllers, with a lot of the accounting code borrowed from rdma.
The current version is
Am 13.11.24 um 16:34 schrieb Matthew Brost:
Now the ordering works inherently in dma-resv and the scheduler. e.g. No
need to track the last completion fences explictly in preempt fences.
I really don't think that this is a good approach. Explicitly keeping the
last completion fence in the pre-em
On 13/11/2024 17:19, Tvrtko Ursulin wrote:
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 b
Reviewed-by: Tom Chung
On 11/5/2024 10:01 PM, Zicheng Qu wrote:
This commit addresses a null pointer dereference issue in
hwss_setup_dpp(). The issue could occur when pipe_ctx->plane_state is
null. The fix adds a check to ensure `pipe_ctx->plane_state` is not null
before accessing. This prevent
Reviewed-by: Tom Chung
On 11/5/2024 10:01 PM, Zicheng Qu wrote:
This commit addresses a null pointer dereference issue in
dcn20_program_pipe(). Previously, commit 8e4ed3cf1642 ("drm/amd/display:
Add null check for pipe_ctx->plane_state in dcn20_program_pipe")
partially fixed the null pointer de
On 2024/11/14 15:45, Vivekanandan, Balasubramani wrote:
On 14.11.2024 14:39, Su Hui wrote:
diff --git a/drivers/gpu/drm/xe/xe_hw_engine_group.c
b/drivers/gpu/drm/xe/xe_hw_engine_group.c
index 82750520a90a..ee2cb32817fa 100644
--- a/drivers/gpu/drm/xe/xe_hw_engine_group.c
+++ b/drivers/gpu/drm/
100 matches
Mail list logo
