Add missing space in the comment in rzg2l_mipi_dsi_start_video().
Reported-by: Pavel Machek
Closes: https://lore.kernel.org/all/zpg7sthdn4lbl...@duo.ucw.cz/
Signed-off-by: Biju Das
Reviewed-by: Geert Uytterhoeven
Reviewed-by: Laurent Pinchart
---
This issue is noticed while backporting this dr
Changes the boe-bf060y8m-aj0 panel to use multi style functions for
improved error handling. Additionally the MIPI_DSI_MODE_LPM flag is set
after the off commands are run in boe_bf060y8m_aj0_off regardless of any
failures, and regulators are disabled if the boe_bf060y8m_aj0_on call in
boe_bf060y8m_
On Fri, Apr 11, 2025 at 11:50:54PM +0530, Gupta, Nipun wrote:
>
> AFAIU after looking into it, the keyring subsystem is not to perform the
> data operations, but for managing keys for these operations. Kindly correct
> me if I am wrong here.
Have a look at
security/keys/keyctl_pkey.c
Cheers,
--
On Mon, 31 Mar 2025 15:42:03 +0800, Yongbang Shi wrote:
> To support DP HPD, edid printing, and colorbar display features based on
> the Hisislcon DP devices.
>
Applied to drm-misc-next, thanks!
[1/9] drm/hisilicon/hibmc: Restructuring the header dp_reg.h
commit: f9698f802e50fbe696b3ac6f82
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.
Signed-off-by: Karunika Choo
---
drivers/gpu/drm/panthor/panthor_d
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,
--
~Randy
On Mon, Apr 7, 2025 at 9:29 AM Maxime Ripard wrote:
>
> Some reserved memory regions might have particular memory setup or
> attributes that make them good candidates for heaps.
>
> Let's provide a heap type that will create a new heap for each reserved
> memory region flagged as such.
>
> Signed-
From: Rodrigo Siqueira
Since DC is a shared code, this commit introduces a new file to work as
a mid-layer in DC for the edid manipulation.
Signed-off-by: Rodrigo Siqueira
Co-developed-by: Melissa Wen
Signed-off-by: Melissa Wen
---
.../gpu/drm/amd/display/amdgpu_dm/Makefile| 1 +
.../gp
Since [1], we can use drm_edid_product_id to get debug info from
drm_edid instead of directly parsing EDID.
Link:
https://lore.kernel.org/dri-devel/cover.1712655867.git.jani.nik...@intel.com/
[1]
Signed-off-by: Melissa Wen
---
.../amd/display/amdgpu_dm/amdgpu_dm_helpers.c| 16 +
On Fri, 11 Apr 2025 16:11:40 +0100
Karunika Choo wrote:
> 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.
>
>
Add Linux opaque object to dc_sink for storing edid data cross driver,
drm_edid. Also include the Linux call to free this object, the
drm_edid_free()
Signed-off-by: Melissa Wen
---
drivers/gpu/drm/amd/display/amdgpu_dm/dc_edid.c | 7 +++
drivers/gpu/drm/amd/display/amdgpu_dm/dc_edid.h | 1 +
Reduce direct handling of edid data by resorting to drm helpers that
deal with this info inside drm_edid infrastructure.
Signed-off-by: Melissa Wen
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 26 +++
.../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 24 +
..
AMD driver has a function used to compare if two edid are the same; this
is useful to some of the link detection algorithms implemented by
amdgpu. Since the amdgpu function can be helpful for other drivers, this
commit abstracts the AMD function to make it available at the DRM level
by wrapping exi
From: Rodrigo Siqueira
As part of the effort of stopping using raw edid, this commit move the
copy of the edid in DC to a dedicated function that will allow the usage
of drm_edid in the next steps.
Signed-off-by: Rodrigo Siqueira
Co-developer--by: Melissa Wen
Signed-off-by: Melissa Wen
---
d
There is an opaque obj in Linux/DRM to encapsulate edid data as
`drm_edid`. This obj isn't present in other platforms but we need to
pass it through DC when adding sink. To pass this data without
compromise the independence of DC code, make some DC functions accept
edid data as private options.
Si
We don't need to parse dc_edid to get the display name since it's
already set in drm_eld which in turn had it values updated when updating
connector with the opaque drm_edid.
Signed-off-by: Melissa Wen
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 10 ++
1 file changed, 6
Pass dc_sink to dm_helpers_parse_edid_caps(), since it already contains
edid info. It's a groundwork to get rid of raw edid stored as dc_edid.
Signed-off-by: Melissa Wen
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 5 +
.../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 17 +++--
Make sure the drm_edid container stored in aconnector is freed when
detroying the aconnector.
Fixes: 48edb2a4 ("drm/amd/display: switch amdgpu_dm_connector to use struct
drm_edid")
Signed-off-by: Melissa Wen
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 ++
1 file changed, 2 inserti
drm_edid_connector_update() updates display info, filling ELD with
speaker allocation data in the last step of update_dislay_info(). Our
goal is stopping using raw edid, so we can extract SADB from drm_eld
instead of access raw edid to get audio caps.
Signed-off-by: Melissa Wen
---
.../amd/displ
drm_edid_connector_update() updates display info, filling ELD with audio
info from Short-Audio Descriptors in the last step of
update_dislay_info(). Our goal is stopping using raw edid, so we can
extract SAD from drm_eld instead of access raw edid to get audio caps.
Signed-off-by: Melissa Wen
---
Hi,
Siqueira and I worked on a solution to reduce the usage of drm_edid_raw
in the AMD display driver, since the current guideline in the DRM
subsystem is to stop handling raw edid data in driver-specific
implementation and use opaque `drm_edid` object with common-code
helpers.
In short, this ser
Instead of using driver-specific code, use DRM helpers.
Signed-off-by: Melissa Wen
---
.../drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
b/drivers/gpu/d
From: Ville Syrjälä
Pass along the format info from .fb_create() to aliminate the
redundant drm_get_format_info() calls from the gem fb code.
v2: Fix kernel docs (Laurent)
Cc: Dave Airlie
Cc: Gerd Hoffmann
Cc: Sandy Huang
Cc: "Heiko Stübner"
Cc: Andy Yan
Cc: Oleksandr Andrushchenko
Cc: vi
From: Ville Syrjälä
Pass along the format information from the top to .fb_create()
so that we can avoid redundant (and somewhat expensive) lookups
in the drivers.
Done with cocci (with some manual fixups):
@@
identifier func =~ ".*create.*";
identifier dev, file, mode_cmd;
@@
struct drm_framebuf
From: Ville Syrjälä
Look up the format info already in drm_internal_framebuffer_create()
so that we can later pass it along to .fb_create(). Currently various
drivers are doing additional lookups in their .fb_create()
implementations, and these lookups are rather expensive now (given
how many dif
From: Ville Syrjälä
Decouple drm_get_format_info() from struct drm_mode_fb_cmd2 and just
pass the pixel format+modifier combo in by hand.
We may want to use drm_get_format_info() outside of the normal
addfb paths where we won't have a struct drm_mode_fb_cmd2, and
creating a temporary one just fo
Add the Tianma Micro-electronics P0700WXF1MBAA 7.0" LVDS LCD TFT panel.
Acked-by: Conor Dooley
Signed-off-by: Luca Ceresoli
---
Documentation/devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/panel
This short series adds power on/off timings to the Tianma TM070JDHG34-00
panel and adds support for the the Tianma P0700WXF1MBAA panel.
Signed-off-by: Luca Ceresoli
---
Changes in v3:
- add Fixes: and Cc:
- remove regulator delay
- add R-by tag by Dmitry
- Link to v2:
https://lore.kernel.org/r/2
From: Ville Syrjälä
Decouple .get_format_info() from struct drm_mode_fb_cmd2 and just
pass the pixel format+modifier combo in by hand.
We may want to use .get_format_info() outside of the normal
addfb paths where we won't have a struct drm_mode_fb_cmd2, and
creating a temporary one just for this
Add the Tianma P0700WXF1MBAA 7" 1280x800 LVDS RGB TFT LCD panel.
Reuse the timings of the TM070JDHG34-00 as they are identical, even though
they are described differently by the datasheet as noted in the
comment. Power up/down timing are slightly different, so add a new struct
panel_desc for that.
Add power on/off delays for the Tianma TM070JDHG34-00.
Fixes: bf6daaa281f7 ("drm/panel: simple: Add Tianma TM070JDHG34-00 panel
support")
Cc: sta...@vger.kernel.org
Signed-off-by: Luca Ceresoli
---
Changed in v3:
- add Fixes: and Cc:
- remove regulator delay
---
drivers/gpu/drm/panel/panel-si
On Fri, Apr 11, 2025 at 05:55:08PM +0200, Werner Sembach wrote:
> 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
Hi Bastien,
Le jeudi 10 avril 2025 à 16:53 +0200, Bastien Curutchet a écrit :
> Some UIO users need to access DMA addresses from userspace to be able to
> configure DMA done by the UIO device. Currently there is no way of doing
> this.
>
> Add a UIO_DMABUF_HEAP Kconfig option. When selected, a dm
Hi Bastien,
Le jeudi 10 avril 2025 à 16:53 +0200, Bastien Curutchet a écrit :
> There is no way to transmit the DMA address of a buffer to userspace.
> Some UIO users need this to handle DMA from userspace.
To me this API is against all safe practice we've been pushing forward
and has no place in
On Fri, Apr 11, 2025 at 12:55:57PM +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
Am 11.04.25 um 13:26 schrieb Sunil Khatri:
> 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.
Hi Sunil,
you need to send this out together with the patch which makes
On 11-04-2025 10:47, Herbert Xu wrote:
On Fri, Apr 11, 2025 at 10:21:03AM +0530, Gupta, Nipun wrote:
added crypto maintainers for comments.
IMO, as accel framework is designed to support any type of compute
accelerators, the PKI crypto accelerator in accel framework is not
completely out of
On 10-04-2025 12:59, Krzysztof Kozlowski wrote:
On Wed, Apr 09, 2025 at 11:00:31PM GMT, Nipun Gupta wrote:
+ interrupts:
+maxItems: 1
+
And the resets? I understand from previous email that there is a reset
controller.
It was not reset controller, those were register from clock cont
On Fri, Apr 11, 2025 at 02:50:19PM +0200, Christian König wrote:
> 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 hav
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
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
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ć
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
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
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
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.
Reviewed-by: Boris Brezillon
Suggested-by: Boris Brezillon
Signed-o
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()
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 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
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 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
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/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/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
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/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:
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 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.
>
---
base-commit: 2bdde620f7f2bff2ff1cb7dc166859eaa0c78a7c
change-id: 20250411-aux-select-kms-086618b92d6e
Best regards,
--
Dmitry Baryshkov
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
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
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
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 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
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
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
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
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
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
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
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, 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
> -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
> 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.
>
>
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
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-
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
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
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
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
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
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
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 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?
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
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
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 &
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
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: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
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.
>
[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
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/
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
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
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
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 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
1 - 100 of 142 matches
Mail list logo
