On 08/04/25 17:40, Kees Cook wrote:
On Mon, Apr 07, 2025 at 05:35:47PM -0600, Gustavo A. R. Silva wrote:
[..]
- struct {
- struct nvif_chan_v0 chan;
- char name[TASK_COMM_LEN+16];
- } args;
+ DEFINE_RAW_FLEX(struct nvif_chan_v0, args, name, TASK
Hi,
a really nice cleanup. With the various comments fixed, you can add
Reviewed-by: Thomas Zimmermann
to the series.
Best regards
Thomas
Am 10.04.25 um 18:31 schrieb Ville Syrjala:
From: Ville Syrjälä
I noticed a bunch of redundant (and rather expensive) drm_format_info
lookups in some t
Hi Thomas,
Am 10.04.25 um 21:43 schrieb Thomas Petazzoni:
> Hello Christian,
>
> Thanks for your feedback!
>
> On Thu, 10 Apr 2025 18:29:12 +0200
> Christian König wrote:
>
>>> Many UIO users performing DMA from their UIO device need to access the
>>> DMA addresses of the allocated buffers. There
Hi,
thanks for the updated patch.
Am 10.04.25 um 19:43 schrieb Nathan Chancellor:
Clang warns (or errors with CONFIG_WERROR=y):
drivers/gpu/drm/sysfb/efidrm.c:353:11: error: variable 'screen_base' is used
uninitialized whenever 'if' condition is false
[-Werror,-Wsometimes-uninitialized]
Am 10.04.25 um 20:41 schrieb Boris Brezillon:
> On Thu, 10 Apr 2025 14:01:03 -0400
> Alyssa Rosenzweig wrote:
>
> In Panfrost and Lima, we don't have this concept of "incremental
> rendering", so when we fail the allocation, we just fail the GPU job
> with an unhandled GPU fault.
>
Hi Christian,
On Thu, 10 Apr 2025 20:52:27 +0200
Christian König wrote:
> Am 10.04.25 um 19:20 schrieb Boris Brezillon:
> > [SNIP]
> Faulting is only legal when you have something like HMM, SVM or
> whatever you call it. And then you can just use a plain shmem
> object to provid
Hi Christian,
On 4/11/25 9:30 AM, Christian König wrote:
Hi Thomas,
Am 10.04.25 um 21:43 schrieb Thomas Petazzoni:
Hello Christian,
Thanks for your feedback!
On Thu, 10 Apr 2025 18:29:12 +0200
Christian König wrote:
Many UIO users performing DMA from their UIO device need to access the
DMA
On 12/3/2024 5:27 PM, Dmitry Baryshkov wrote:
> On Tue, 3 Dec 2024 at 07:22, Ekansh Gupta wrote:
>>
>>
>> On 12/2/2024 6:18 PM, Dmitry Baryshkov wrote:
>>> On Mon, Dec 02, 2024 at 03:27:43PM +0530, Ekansh Gupta wrote:
On 11/22/2024 12:23 AM, Dmitry Baryshkov wrote:
> On Thu, Nov 21, 20
Marcus Folkesson writes:
Hello Marcus,
[...]
>> static const struct of_device_id st7571_of_match[] = {
>> /* monochrome displays */
>> {
>> .compatible = "sinocrystal,sc128128012-v01",
>> .data = monochrome_formats,
>> },
>> ...
>> /* grayscale d
Hi Helen,
On 10/04/25 20:10, Helen Koike wrote:
On 10/04/2025 05:07, Vignesh Raman wrote:
Hi Helen,
On 09/04/25 23:53, Helen Koike wrote:
Hi Vignesh,
Thank you for your patch.
On 09/04/2025 03:15, Vignesh Raman wrote:
Add jobs to validate devicetrees and run KUnit tests.
Pipeline link,
On Fri, 11 Apr 2025 10:04:07 +0200
Christian König wrote:
> Am 10.04.25 um 20:41 schrieb Boris Brezillon:
> > On Thu, 10 Apr 2025 14:01:03 -0400
> > Alyssa Rosenzweig wrote:
> >
> > In Panfrost and Lima, we don't have this concept of "incremental
> > rendering", so when we fail the all
Hi Dmitry,
On 11/04/25 01:02, Dmitry Baryshkov wrote:
On Wed, Apr 09, 2025 at 11:45:38AM +0530, Vignesh Raman wrote:
Add jobs to run dt_binding_check and dtbs_check. If warnings are seen,
exit with a non-zero error code while configuring them as warning in
the GitLab CI pipeline.
Signed-off-by
On 10/04/2025 09:24, AngeloGioacchino Del Regno wrote:
Add a driver for the Himax HX8279-D MIPI-DSI DriverIC with support
for the Startek KX070FHFID078 7.0" 1200x1920 IPS panel, found on
various MediaTek Genio Evaluation Kit boards and for the Aoly
SL101PM1794FOG-v15 10.1" 1200x1920 LCD panel fou
On 01/04/2025 07:11, Dmitry Baryshkov wrote:
Now there are no users of the return value of the drm_panel_prepare(),
drm_panel_unprepare(), drm_panel_enable() and drm_panel_disable() calls.
Usually these calls are performed from the atomic callbacks, where it is
impossible to return an error. Stop
On Thu, 2025-04-10 at 17:36 +0200, Philipp Stanner wrote:
> On Thu, 2025-04-10 at 15:16 +0200, Christian König wrote:
> > Am 10.04.25 um 15:09 schrieb Philipp Stanner:
> > > On Thu, 2025-04-10 at 14:58 +0200, Christian König wrote:
> > > > Am 10.04.25 um 11:24 schrieb Philipp Stanner:
> > > > > Nou
Enable NO_EOT and SYNC flags for DSI to use VIDEO_SYNC_PULSE_MODE
with EOT disabled.
Signed-off-by: Jayesh Choudhary
---
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
b/drivers/gpu/drm/bridge/ti-
Applied with updated commit message to drm-misc-fixes
On 4/1/2025 5:57 PM, Maciej Falkowski wrote:
> Use flush_work() instead of cancel_work_sync() for driver
> workqueues to guarantee that remaining pending work
> will be handled.
>
> Fixes: bc3e5f48b7ee ("accel/ivpu: Use workqueue for IRQ handl
On 4/9/25 5:49 PM, Konrad Dybcio wrote:
> On 4/9/25 5:44 PM, Dmitry Baryshkov wrote:
>> On 09/04/2025 17:47, Konrad Dybcio wrote:
>>> SMEM allows the OS to retrieve information about the DDR memory.
>>> Among that information, is a semi-magic value called 'HBB', or Highest
>>> Bank address Bit, whi
On Fri, 11 Apr 2025 at 12:49, Konrad Dybcio
wrote:
>
> On 4/9/25 5:49 PM, Konrad Dybcio wrote:
> > On 4/9/25 5:44 PM, Dmitry Baryshkov wrote:
> >> On 09/04/2025 17:47, Konrad Dybcio wrote:
> >>> SMEM allows the OS to retrieve information about the DDR memory.
> >>> Among that information, is a sem
On Fri, 11 Apr 2025 at 11:32, Vignesh Raman wrote:
>
> Hi Dmitry,
>
> On 11/04/25 01:02, Dmitry Baryshkov wrote:
> > On Wed, Apr 09, 2025 at 11:45:38AM +0530, Vignesh Raman wrote:
> >> Add jobs to run dt_binding_check and dtbs_check. If warnings are seen,
> >> exit with a non-zero error code while
Reviewed-by: Jacek Lawrynowicz
On 4/1/2025 5:59 PM, Maciej Falkowski wrote:
> From: Andrzej Kacprowski
>
> Add sysfs files that show maximum and current
> frequency of the NPU's data processing unit.
> New sysfs entries:
> - npu_max_frequency_mhz
> - npu_current_frequency_mhz
>
> Signed-off-by
On 4/11/25 11:57 AM, Dmitry Baryshkov wrote:
> On Fri, 11 Apr 2025 at 12:49, Konrad Dybcio
> wrote:
>>
>> On 4/9/25 5:49 PM, Konrad Dybcio wrote:
>>> On 4/9/25 5:44 PM, Dmitry Baryshkov wrote:
On 09/04/2025 17:47, Konrad Dybcio wrote:
> SMEM allows the OS to retrieve information about the
Applied with updated commit message to drm-misc-fixes
On 4/1/2025 5:58 PM, Maciej Falkowski wrote:
> From: Karol Wachowski
>
> This commit bumps FW Boot API to 3.28.3.
>
> Use new preemption buffer size fields from FW header added to
> firmware boot API for preemption buffers allocations,
> if
Applied to drm-misc-fixes
On 4/1/2025 5:59 PM, Maciej Falkowski wrote:
> This patchset introduces the capability to measure the NPU frequency
> and makes it accessible to a userspace via sysfs. The initial patch in the
> series
> addresses the inconsistency in retrieving the clock frequency from
Applied to drm-misc-fixes
On 4/1/2025 5:59 PM, Maciej Falkowski wrote:
> From: Karol Wachowski
>
> Add tracking of command queue ID in JOB debug message to improve
> debugging capabilities.
>
> Signed-off-by: Karol Wachowski
> Signed-off-by: Maciej Falkowski
> ---
> drivers/accel/ivpu/ivpu_j
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
On Wed, Apr 02, 2025 at 04:35:05PM +0200, Gergo Koteles wrote:
> Hi Dmitry,
>
> But the code would start to become quite untraceable.
> duplicate mode in amdgpu_dm_connector_mode_valid()
> call drm_mode_set_crtcinfo() in amdgpu_dm_connector_mo
kzalloc() already zero-initializes the destination buffers, making
strscpy() sufficient for safely copying the names. The additional
NUL-padding performed by strscpy_pad() is unnecessary.
If the destination buffer has a fixed length, strscpy() automatically
determines its size using sizeof() when
On Fri, 11 Apr 2025, Suraj Kandpal wrote:
> Use u32 for level variable as one may need to pass value for
> DP_EDP_PANEL_TARGET_LUMINANCE_VALUE.
>
> Signed-off-by: Suraj Kandpal
> ---
> drivers/gpu/drm/display/drm_dp_helper.c | 6 +++---
> include/drm/display/drm_dp_helper.h | 2 +-
> 2 files
On Fri, Apr 11, 2025 at 12:03:03PM +0200, Konrad Dybcio wrote:
> On 4/11/25 11:57 AM, Dmitry Baryshkov wrote:
> > On Fri, 11 Apr 2025 at 12:49, Konrad Dybcio
> > wrote:
> >>
> >> On 4/9/25 5:49 PM, Konrad Dybcio wrote:
> >>> On 4/9/25 5:44 PM, Dmitry Baryshkov wrote:
> On 09/04/2025 17:47, Ko
On 4/11/25 12:50 PM, Dmitry Baryshkov wrote:
> On Fri, Apr 11, 2025 at 12:03:03PM +0200, Konrad Dybcio wrote:
>> On 4/11/25 11:57 AM, Dmitry Baryshkov wrote:
>>> On Fri, 11 Apr 2025 at 12:49, Konrad Dybcio
>>> wrote:
On 4/9/25 5:49 PM, Konrad Dybcio wrote:
> On 4/9/25 5:44 PM, Dmitry
Am 11.04.25 um 10:38 schrieb Boris Brezillon:
> On Fri, 11 Apr 2025 10:04:07 +0200
> Christian König wrote:
>
>> Am 10.04.25 um 20:41 schrieb Boris Brezillon:
>>> On Thu, 10 Apr 2025 14:01:03 -0400
>>> Alyssa Rosenzweig wrote:
>>>
>>> In Panfrost and Lima, we don't have this concept of "inc
Hello Tomi,
On 02/04/25 19:00, Tomi Valkeinen wrote:
While trying to get the cdns-dsi to work on Toradex's AM69 Aquila
platform, I hit multiple issues in the driver. Basicaly nothing worked
for with the board.
This series fixes those issues. While I itch to make much larger changes
to the cdns-
Am 11.04.25 um 11:29 schrieb Philipp Stanner:
> [SNIP]
> It could be, however, that at the same moment nouveau_fence_signal() is
> removing that entry, holding the appropriate lock.
>
> So we have a race. Again.
Ah, yes of course. If signaled is called with or without the lock is actually
undeter
Add helper function which get the process information for
the drm_file and updates the user provided character buffer
with the information of process name and pid as a string.
Signed-off-by: Sunil Khatri
---
drivers/gpu/drm/drm_file.c | 30 ++
include/drm/drm_file.h
On 10/04/2025 16:46, Aradhya Bhatia wrote:
Use the "adjusted_mode" for the dsi configuration check, as that is the
more appropriate display_mode for validation, and later bridge enable.
Also, fix the mode_valid_check parameter from false to true, as the dsi
configuration check is taking place du
On Wed, Apr 02, 2025 at 03:36:32PM +0100, Christopher Obbard wrote:
> Add edp_hpd_active pinctrl to the X1E80100 device tree.
Please squash this one with the patch adding the user.
> Signed-off-by: Christopher Obbard
> ---
> arch/arm64/boot/dts/qcom/x1e80100.dtsi | 5 +
> 1 file changed, 5
From: Andy Yan
It is not recommended for drivers to include UAPI header
directly.
Signed-off-by: Andy Yan
Reviewed-by: Heiko Stuebner
---
Changes in v2:
- Collect R-b from Heiko.
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
On Thu, Apr 10, 2025 at 08:41:55PM +0200, Boris Brezillon wrote:
> On Thu, 10 Apr 2025 14:01:03 -0400
> Alyssa Rosenzweig wrote:
>
> > > > > In Panfrost and Lima, we don't have this concept of "incremental
> > > > > rendering", so when we fail the allocation, we just fail the GPU job
> > > > > wi
On Fri, 11 Apr 2025 12:55:57 +0200
Christian König wrote:
> Am 11.04.25 um 10:38 schrieb Boris Brezillon:
> > On Fri, 11 Apr 2025 10:04:07 +0200
> > Christian König wrote:
> >
> >> Am 10.04.25 um 20:41 schrieb Boris Brezillon:
> >>> On Thu, 10 Apr 2025 14:01:03 -0400
> >>> Alyssa Rosenzweig
On Fri, 11 Apr 2025, Sunil Khatri wrote:
> Add helper function which get the process information for
> the drm_file and updates the user provided character buffer
> with the information of process name and pid as a string.
Where's the user for this function?
BR,
Jani.
>
> Signed-off-by: Sunil K
Hi Martin,
Thank you for the patch.
I encountered this issue some time ago as well and had a possible fix in my
tree (see
below).
My apologies for not upstreaming it earlier.
While my fix is not as symmetric as yours—I like symmetry—it is somewhat
simpler. It
did make the assumption that only
Fix typos found in drivers/accel/habanalabs/common/command_submission.c.
Signed-off-by: Jiangyong Wang
---
drivers/accel/habanalabs/common/command_submission.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/accel/habanalabs/common/command_submission.c
b/drivers/acce
Hello Tomi,
On 02/04/25 19:00, Tomi Valkeinen wrote:
The timings calculation gets it wrong for DSI event mode, resulting in
too large hbp value. Fix the issue by taking into account the
pulse/event mode difference.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Jayesh Choudhary
---
drivers/
[AMD Official Use Only - AMD Internal Distribution Only]
Sure, I will send the patch for the user too.
Regards
Sunil Khatri
-Original Message-
From: Koenig, Christian
Sent: Friday, April 11, 2025 5:40 PM
To: Khatri, Sunil ; dri-devel@lists.freedesktop.org;
amd-...@lists.freedesktop.org
On Fri, 2025-04-11 at 13:05 +0200, Christian König wrote:
> Am 11.04.25 um 11:29 schrieb Philipp Stanner:
>
> > [SNIP]
> >
> > It could be, however, that at the same moment
> > nouveau_fence_signal() is
> > removing that entry, holding the appropriate lock.
> >
> > So we have a race. Again.
>
Am 11.04.25 um 14:02 schrieb Boris Brezillon:
>>> I guess this leaves older GPUs that don't support incremental
>>> rendering in a bad place though.
>> Well what's the handling there currently? Just crash when you're OOM?
> It's "alloc(GFP_KERNEL) and crash if it fails or times out", yes.
Oh, pl
Hi Martin,
On Thu, 10 Apr 2025 at 03:30, Martin Blumenstingl
wrote:
>
> meson_drv_bind_master() does not free resources in the order they are
> allocated. This can lead to crashes such as:
> Unable to handle kernel NULL pointer dereference at virtual address
> 00c8
> [...]
>
Am 11.04.25 um 14:01 schrieb Simona Vetter:
> On Thu, Apr 10, 2025 at 08:41:55PM +0200, Boris Brezillon wrote:
>> On Thu, 10 Apr 2025 14:01:03 -0400
>> Alyssa Rosenzweig wrote:
>>
>> In Panfrost and Lima, we don't have this concept of "incremental
>> rendering", so when we fail the allocat
From: Arnd Bergmann
clang points out that there is a code path that leads to undefined behavior:
drivers/gpu/drm/sysfb/efidrm.c:353:11: error: variable 'screen_base' is used
uninitialized whenever 'if' condition is false
[-Werror,-Wsometimes-uninitialized]
353 | else if (mem_flags &
From: Arnd Bergmann
ttm now directly calls into shmem code, which fails to build when
that is disabled at compile time.
ld.lld-21: error: undefined symbol: shmem_writeout
>>> referenced by ttm_backup.c
>>> drivers/gpu/drm/ttm/ttm_backup.o:(ttm_backup_backup_page) in
>>> archive vm
On 10.04.2025 08:36, Boris Brezillon wrote:
On Wed, 9 Apr 2025 22:22:22 +0100
Adrián Larumbe wrote:
> > Add a device DebugFS file that displays a complete list of all the DRM
> > GEM objects that are exposed to UM through a DRM handle.
> >
> > Since leaking object identifiers that might belong t
On Fri, 11 Apr 2025 14:45:49 +0200
Christian König wrote:
> Am 11.04.25 um 14:02 schrieb Boris Brezillon:
> >>> I guess this leaves older GPUs that don't support incremental
> >>> rendering in a bad place though.
> >> Well what's the handling there currently? Just crash when you're
> >> OOM?
Add helper function which get the process information for
the drm_file and updates the user provided character buffer
with the information of process name and pid as a string.
Signed-off-by: Sunil Khatri
---
drivers/gpu/drm/drm_file.c | 30 ++
include/drm/drm_file.h
Am 11.04.25 um 14:44 schrieb Philipp Stanner:
> On Fri, 2025-04-11 at 13:05 +0200, Christian König wrote:
>> Am 11.04.25 um 11:29 schrieb Philipp Stanner:
>>
>>> [SNIP]
>>>
>>> It could be, however, that at the same moment
>>> nouveau_fence_signal() is
>>> removing that entry, holding the appr
Arnd Bergmann writes:
Hello Arnd,
> From: Arnd Bergmann
>
> clang points out that there is a code path that leads to undefined behavior:
>
> drivers/gpu/drm/sysfb/efidrm.c:353:11: error: variable 'screen_base' is used
> uninitialized whenever 'if' condition is false
> [-Werror,-Wsometimes-uni
add process and pid information in the userqueue error
logging to make it more useful in resolving the error
by logs.
Sample log:
[ 42.444297] [drm:amdgpu_userqueue_wait_for_signal [amdgpu]] *ERROR* Timed
out waiting for fence f=1c74d978 for comm:Xwayland pid:3427
[ 42.444669] [drm:am
drm_file will be used in usermode queues code to
enable better process information in logging and hence
add drm_file part of the userq_mgr struct.
update the drm_file pointer in userq_mgr for each
amdgpu_driver_open_kms.
Signed-off-by: Sunil Khatri
---
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
Am 08.04.25 um 13:01 schrieb Dan Carpenter:
> Call dma_fence_put(fence) before returning an error if
> dma_fence_to_sync_pt() fails. Use an unwind ladder at the
> end of the function to do the cleanup.
>
> Fixes: 70e67aaec2f4 ("dma-buf/sw_sync: Add fence deadline support")
> Signed-off-by: Dan Car
Am 11.04.25 um 00:06 schrieb Rob Clark:
> On Thu, Apr 10, 2025 at 9:33 AM Dan Carpenter
> wrote:
>> We need to cleanup if the chain = dma_fence_chain_alloc() allocation
>> fails. Now that we have multiple error returns in this function, switch
>> to using an unwind ladder for cleanup.
>>
>> Fixe
Hi Dave and Sima,
Here goes our first pull request towards 6.16.
It is worth to highlight the huge amount of patches around VRR refactor.
Also more chunks of clean-up towards a separated display.
And finally some changes in the debugfs entries.
Thanks,
Rodrigo.
drm-intel-next-2025-04-11:
Cross-
Hi Arnd
Am 11.04.25 um 15:11 schrieb Javier Martinez Canillas:
Arnd Bergmann writes:
Hello Arnd,
From: Arnd Bergmann
Thanks for the fix.
clang points out that there is a code path that leads to undefined behavior:
drivers/gpu/drm/sysfb/efidrm.c:353:11: error: variable 'screen_base' is
> 2. Device Lost
> --
>
> At this point we're left with no other choice than to kill the context.
> And userspace should be able to cope with VK_DEVICE_LOST (hopefully zink
> does), but it will probably not cope well with an entire strom of these
> just to get the first frame out.
>
>
> -Original Message-
> From: Kandpal, Suraj
> Sent: Tuesday, April 8, 2025 10:32 AM
> To: dri-devel@lists.freedesktop.org; intel...@lists.freedesktop.org; intel-
> g...@lists.freedesktop.org
> Cc: Nautiyal, Ankit K ; Murthy, Arun R
> ; Kandpal, Suraj
> Subject: [PATCH 0/2] Register bit
On Fri, 2025-04-11 at 15:06 +0200, Christian König wrote:
> Am 11.04.25 um 14:44 schrieb Philipp Stanner:
> > On Fri, 2025-04-11 at 13:05 +0200, Christian König wrote:
> > > Am 11.04.25 um 11:29 schrieb Philipp Stanner:
> > >
> > > > [SNIP]
> > > >
> > > > It could be, however, that at the sam
On Fri, Apr 11, 2025 at 9:05 AM Sunil Khatri wrote:
>
> add process and pid information in the userqueue error
> logging to make it more useful in resolving the error
> by logs.
>
> Sample log:
> [ 42.444297] [drm:amdgpu_userqueue_wait_for_signal [amdgpu]] *ERROR* Timed
> out waiting for fence
On Fri, 11 Apr 2025 15:13:26 +0200
Christian König wrote:
> >
> >> Background is that you don't get a crash, nor error message, nor
> >> anything indicating what is happening.
> > The job times out at some point, but we might get stuck in the fault
> > handler waiting for memory, which is pre
Hi Ville,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-exynos/exynos-drm-next]
[also build test WARNING on linus/master v6.15-rc1 next-20250411]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we
This patch series is aimed at providing UM with detailed memory profiling
information in debug builds. It is achieved through a device-wide list of
DRM GEM objects, and also implementing the ability to label BO's from UM
through a new IOCTL.
The new debugfs file shows a list of driver DRM GEM obje
Allow UM to label a BO for which it possesses a DRM handle.
Signed-off-by: Adrián Larumbe
Reviewed-by: Liviu Dudau
Reviewed-by: Boris Brezillon
---
drivers/gpu/drm/panthor/panthor_drv.c | 42 ++-
drivers/gpu/drm/panthor/panthor_gem.h | 2 ++
include/uapi/drm/panthor_dr
Add a new character string Panthor BO field, and a function that allows
setting it from within the driver.
Driver takes care of freeing the string when it's replaced or no longer
needed at object destruction time, but allocating it is the responsibility
of callers.
Signed-off-by: Adrián Larumbe
Add a device DebugFS file that displays a complete list of all the DRM
GEM objects that are exposed to UM through a DRM handle.
Since leaking object identifiers that might belong to a different NS is
inadmissible, this functionality is only made available in debug builds
with DEBUGFS support enabl
Hi Bastien,
Am 11.04.25 um 10:14 schrieb Bastien Curutchet:
> Hi Christian,
>
> On 4/11/25 9:30 AM, Christian König wrote:
>> Hi Thomas,
>>
>> Am 10.04.25 um 21:43 schrieb Thomas Petazzoni:
>>> Hello Christian,
>>>
>>> Thanks for your feedback!
>>>
>>> On Thu, 10 Apr 2025 18:29:12 +0200
>>> Christ
Am 11.04.25 um 15:00 schrieb Boris Brezillon:
> On Fri, 11 Apr 2025 14:45:49 +0200
> Christian König wrote:
>
>> Am 11.04.25 um 14:02 schrieb Boris Brezillon:
> I guess this leaves older GPUs that don't support incremental
> rendering in a bad place though.
Well what's the handlin
Hi all,
This patch series adds support for 64-bit and poll register accessors in
the Panthor DRM driver and performs a cleanup of the 64-bit register
definitions.
The first patch introduces new accessor functions to simplify and
standardize 64-bit and polling register operations. The second patch
With the introduction of 64-bit register accessors, the separate *_HI
definitions are no longer necessary. This change removes them and
renames the corresponding *_LO entries for cleaner and more consistent
register definitions.
Suggested-by: Boris Brezillon
Signed-off-by: Karunika Choo
---
dri
On 10/04/2025 17:46, Boris Brezillon wrote:
> On Thu, 10 Apr 2025 17:35:46 +0100
> Karunika Choo wrote:
>
>> This patch adds 64-bit register accessors to simplify register access in
>> Panthor. It also adds 32-bit and 64-bit variants for read_poll_timeout.
>>
>> This patch also updates Panthor to
---
base-commit: 2bdde620f7f2bff2ff1cb7dc166859eaa0c78a7c
change-id: 20250411-aux-select-kms-086618b92d6e
Best regards,
--
Dmitry Baryshkov
On Fri, 11 Apr 2025 16:11:39 +0100
Karunika Choo wrote:
> This patch adds 64-bit register accessors to simplify register access in
> Panthor. It also adds 32-bit and 64-bit variants for read_poll_timeout.
>
> This patch also updates Panthor to use the new 64-bit accessors and poll
> functions.
>
On Fri, 11 Apr 2025 16:17:56 +0100
Karunika Choo wrote:
> On 10/04/2025 17:46, Boris Brezillon wrote:
> > On Thu, 10 Apr 2025 17:35:46 +0100
> > Karunika Choo wrote:
> >
> >> This patch adds 64-bit register accessors to simplify register access in
> >> Panthor. It also adds 32-bit and 64-bit
On 4/8/2025 5:52 AM, Thomas Zimmermann wrote:
Instead of testing import_attach for imported GEM buffers, invoke
drm_gem_is_imported() to do the test. The helper tests the dma_buf
itself while import_attach is just an artifact of the import. Prepares
to make import_attach optional.
Signed-off-by:
On 4/8/2025 5:52 AM, Thomas Zimmermann wrote:
Instead of testing import_attach for imported GEM buffers, invoke
drm_gem_is_imported() to do the test. The helper tests the dma_buf
itself while import_attach is just an artifact of the import. Prepares
to make import_attach optional.
Signed-off-by:
Hi Ashley,
On 10/04/2025 13:57, Ashley Smith wrote:
> The timeout logic provided by drm_sched leads to races when we try
> to suspend it while the drm_sched workqueue queues more jobs. Let's
> overhaul the timeout handling in panthor to have our own delayed work
> that's resumed/suspended when a g
On 4/9/2025 3:00 PM, Lizhi Hou wrote:
When multiple ERT_START_NPU commands are combined in one buffer, the
buffer size calculation is incorrect. Also, the condition to make sure
the buffer size is not beyond 4K is also fixed.
Fixes: aac243092b70 ("accel/amdxdna: Add command execution")
Signed-of
On 4/11/2025 7:54 PM, Alex Deucher wrote:
On Fri, Apr 11, 2025 at 9:05 AM Sunil Khatri wrote:
add process and pid information in the userqueue error
logging to make it more useful in resolving the error
by logs.
Sample log:
[ 42.444297] [drm:amdgpu_userqueue_wait_for_signal [amdgpu]] *ERRO
On 4/8/2025 8:55 AM, Falkowski, Maciej wrote:
On 4/4/2025 5:13 PM, Jeff Hugo wrote:
On 4/1/2025 9:59 AM, Maciej Falkowski wrote:
From: Andrzej Kacprowski
Add sysfs files that show maximum and current
frequency of the NPU's data processing unit.
New sysfs entries:
- npu_max_frequency_mhz
Do
On 4/9/2025 11:30 AM, Nipun Gupta wrote:
No cover letter?
Add binding documentation for AMD PKI accelerator supported for AMD
versal-net SoC.
AMD PKI accelerator is a device on AMD versa-net SoC to execute public key
asymmetric crypto operations like ECDSA, ECDH, RSA etc. with high performance
Kernel BO's aren't exposed to UM, so labelling them is the responsibility
of the driver itself. This kind of tagging will prove useful in further
commits when want to expose these objects through DebugFS.
Expand panthor_kernel_bo_create() interface to take a NULL-terminated
string. No bounds check
On Wed, Apr 09, 2025 at 07:09:28PM -0700, H. Peter Anvin wrote:
> On 4/9/25 11:33, Yury Norov wrote:
> > > >
> > > I don't have a strong preference for the name, but if I had to guess
> > > the return value from the function prototype, I would intuitively
> > > expect an int to return "0 for even
On 4/9/2025 11:30 AM, Nipun Gupta wrote:
The AMD PKI accelerator driver provides a accel interface to interact
"an accel"
with the device for offloading and accelerating asymmetric crypto
operations.
Signed-off-by: Nipun Gupta
---
Changes RFC->v2:
- moved from misc to accel
- added archite
On Thu, Apr 10, 2025 at 07:08:58AM +0200, Arend Van Spriel wrote:
> On April 10, 2025 12:06:52 AM Johannes Berg wrote:
>
> > On Wed, 2025-04-09 at 20:43 +0200, Arend van Spriel wrote:
> > >
> > > This is orthogonal to the change to parity_odd() though. More specific
> > > to the new parity_odd()
With the introduction of 64-bit register accessors, the separate *_HI
definitions are no longer necessary. This change removes them and
renames the corresponding *_LO entries for cleaner and more consistent
register definitions.
Reviewed-by: Boris Brezillon
Suggested-by: Boris Brezillon
Signed-o
Hi all,
This patch series adds support for 64-bit and poll register accessors in
the Panthor DRM driver and performs a cleanup of the 64-bit register
definitions.
The first patch introduces new accessor functions to simplify and
standardize 64-bit and polling register operations. The second patch
On April 11, 2025 6:37:35 PM Kuan-Wei Chiu wrote:
On Thu, Apr 10, 2025 at 07:08:58AM +0200, Arend Van Spriel wrote:
On April 10, 2025 12:06:52 AM Johannes Berg wrote:
On Wed, 2025-04-09 at 20:43 +0200, Arend van Spriel wrote:
This is orthogonal to the change to parity_odd() though. More s
This is a quirk we currently manually apply via our installer via the boot
parameter, but we don't have this exact device + panel configuration in our
archive anymore so I could only test the qurik moking in other ids. This is
the same situation we have here:
https://lore.kernel.org/all/20250409163
The display backlight on TUXEDO DX1708 and InsanityBook 15 v1 with panels
AUO 12701 and AUO 12701 must be forced to INTEL_DP_AUX_BACKLIGHT_ON to be
able to control the brightness.
This could already be archived via a module parameter, but this patch adds
a quirk to apply this by default on the men
select LEDS_EXPRESSWIRE
help
Say Y to enable the backlight driver for the Kinetic KTD2801 1-wire
---
base-commit: 01c6df60d5d4ae00cd5c1648818744838bba7763
change-id: 20250411-ktd-fix-7a5e5d8657b8
Best regards,
--
Duje Mihanović
This patch adds 64-bit register accessors to simplify register access in
Panthor. It also adds 32-bit and 64-bit variants for read_poll_timeout.
This patch also updates Panthor to use the new 64-bit accessors and poll
functions.
Reviewed-by: Boris Brezillon
Signed-off-by: Karunika Choo
---
dri
On Fri, Apr 11, 2025 at 09:52:30AM -0400, Alyssa Rosenzweig wrote:
> > 2. Device Lost
> > --
> >
> > At this point we're left with no other choice than to kill the context.
> > And userspace should be able to cope with VK_DEVICE_LOST (hopefully zink
> > does), but it will probably not
1 - 100 of 142 matches
Mail list logo
