On 10/7/2024 1:21 AM, Dmitry Baryshkov wrote:
On Fri, Oct 04, 2024 at 04:00:46PM GMT, Soutrik Mukhopadhyay wrote:
The Qualcomm SA8775P platform comes with 2 DisplayPort controllers
for each mdss, having different base offsets than the previous
SoCs. The support for all 4 DPTX have been added h
From: Bartosz Golaszewski
This driver is no longer used on any platform. It has been replaced by
tilcdc on the two DaVinci boards we still support and can be removed.
Signed-off-by: Bartosz Golaszewski
---
drivers/video/fbdev/Kconfig| 13 -
drivers/video/fbdev/Makefile |1 -
driver
Do not keep the obsolete EDID around after unplugging the display
from the connector.
Signed-off-by: Thomas Zimmermann
Fixes: d20c2f846428 ("drm/ast: sil164: Transparently handle BMC support")
Cc: Thomas Zimmermann
Cc: Jocelyn Falempe
Cc: Dave Airlie
Cc: dri-devel@lists.freedesktop.org
---
dr
Do not keep the obsolete EDID around after unplugging the display
from the connector.
Signed-off-by: Thomas Zimmermann
Fixes: 2a2391f857cd ("drm/ast: vga: Transparently handle BMC support")
Cc: Thomas Zimmermann
Cc: Jocelyn Falempe
Cc: Dave Airlie
Cc: dri-devel@lists.freedesktop.org
---
drive
After unplugging a display from the connector, the driver has to clear
the connector's EDID property. Recent code for BMC support forget to do
this for VGA- and SIL164-based transmitters. Fix it.
Thomas Zimmermann (2):
drm/ast: sil164: Clear EDID if no display is connected
drm/ast: vga: Clear
Am 15.10.24 um 04:44 schrieb kernel test robot:
Hello,
kernel test robot noticed
"WARNING:at_drivers/gpu/drm/ast/ast_dp.c:#ast_dp_set_enable[ast]" on:
commit: 4e29cc7c5c673299cfbaf4982fc8b6a72c9f706f ("drm/ast: astdp: Replace
ast_dp_set_on_off()")
https://git.kernel.org/cgit/linux/kernel/
This reverts commit 6c9e14ee9f519ee605a3694fbfa4711284781d22.
This reverts commit d5070c9b29440c270b534bbacd636b8fa558e82b.
This reverts commit 89c6ea2006e2d39b125848fb0195c08fa0b354be.
The VLINE interrupt doesn't work correctly on G200SE-A (at least). We
have also seen missing interrupts on G200E
On 10/14/2024, Dmitry Baryshkov wrote:
> On Mon, Oct 14, 2024 at 01:33:44PM +0800, Liu Ying wrote:
>> On 10/14/2024, Dmitry Baryshkov wrote:
>>> On Sat, Oct 12, 2024 at 05:14:13PM +0800, Liu Ying wrote:
On 10/12/2024, Dmitry Baryshkov wrote:
> On Sat, Oct 12, 2024 at 03:35:39PM +0800, Liu
linus/master v6.12-rc3 next-20241014]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab
On Mon, Oct 14, 2024 at 05:26:19PM -0700, Jeff Johnson wrote:
On 10/8/24 11:34, Lucas De Marchi wrote:
...
+module_init(dummy_init);
+module_exit(dummy_exit);
+
+MODULE_AUTHOR("Lucas De Marchi ");
+MODULE_LICENSE("GPL");
Since commit 1fffe7a34c89 ("script: modpost: emit a warning when the
desc
Hi Piotr,
At 2024-10-15 06:30:27, "Piotr Zalewski" wrote:
>Add support for gamma LUT in VOP2 driver. The implementation was inspired
>by one found in VOP1 driver. Blue and red channels in gamma LUT register
>write were swapped with respect to how gamma LUT values are written in
>VOP1. Gamma LUT
>-Original Message-
>From: Dmitry Baryshkov
>Sent: Monday, October 14, 2024 7:53 PM
>To: Hermes Wu (吳佳宏)
>Cc: Pin-yen Lin ; Kenneth Hung (洪家倫)
>; Pet Weng (翁玉芬) ; Andrzej Hajda
>; Neil Armstrong ; Robert
>Foss ; Laurent Pinchart ;
>Jonas Karlman ; Jernej Skrabec ;
>Maarten Lankhors
Hello,
kernel test robot noticed
"WARNING:at_drivers/gpu/drm/ast/ast_dp.c:#ast_dp_set_enable[ast]" on:
commit: 4e29cc7c5c673299cfbaf4982fc8b6a72c9f706f ("drm/ast: astdp: Replace
ast_dp_set_on_off()")
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master
[test failed on lin
On Fri, Oct 11, 2024 at 04:12:41PM -0700, Lizhi Hou wrote:
> Add interfaces for user application to submit command and wait for its
> completion.
>
> Co-developed-by: Min Ma
> Signed-off-by: Min Ma
> Signed-off-by: Lizhi Hou
> ---
> drivers/accel/amdxdna/aie2_ctx.c | 624 +
>From DT point of view, in general, drivers should be asking for a
specific port number because their function is fixed in the binding.
of_graph_get_next_endpoint() doesn't match to this concept.
Simply replace
- of_graph_get_next_endpoint(xxx, NULL);
+ of_graph_get_endpoint_by_r
Hi Boris,
I'm a bit confused, I thought the plan was to separate the FW_PAGE_SIZE
from the rest of Panthor's PAGE_SIZE.
On Mon, Oct 14, 2024 at 11:31:34AM +0200, Boris Brezillon wrote:
> The system and GPU MMU page size might differ, which becomes a
> problem for FW sections that need to be mappe
On 10/8/24 11:34, Lucas De Marchi wrote:
...
> +module_init(dummy_init);
> +module_exit(dummy_exit);
> +
> +MODULE_AUTHOR("Lucas De Marchi ");
> +MODULE_LICENSE("GPL");
Since commit 1fffe7a34c89 ("script: modpost: emit a warning when the
description is missing"), a module without a MODULE_DESCRIPT
Doesn't make any functional difference because generic dma_fence is the
first panfrost_fence structure member, but I guess it doesn't hurt either.
Signed-off-by: Adrián Larumbe
---
drivers/gpu/drm/panfrost/panfrost_job.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/p
Just a convenience macro to avoid reduplication.
Signed-off-by: Adrián Larumbe
---
drivers/gpu/drm/panfrost/panfrost_job.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c
b/drivers/gpu/drm/panfrost/panfrost_job.c
index 68
This is to make LLVM syntactic analysers happy.
Signed-off-by: Adrián Larumbe
---
drivers/gpu/drm/panfrost/panfrost_mmu.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.h
b/drivers/gpu/drm/panfrost/panfrost_mmu.h
index 0b2c0b59db3f..a19282a22aab 100
Rather than remasking interrupts after a device reset in the main reset
path, allow selecting whether to do this with an additional bool parameter.
Signed-off-by: Adrián Larumbe
---
drivers/gpu/drm/panfrost/panfrost_device.c | 6 +++---
drivers/gpu/drm/panfrost/panfrost_device.h | 2 +-
driver
Right now Panfrost's GPU page fault IRQ assumes the architectural page
mapping function always suceeds. That might not always be the case, so we
haravest its return status and unmap whatever we had mapped so far.
Signed-off-by: Adrián Larumbe
---
drivers/gpu/drm/panfrost/panfrost_mmu.c | 66
Avoid waiting for the DRM scheduler job timeout handler and let the DRM
scheduler core signal the error fence immediately instead when HW job
submission fails.
Signed-off-by: Adrián Larumbe
---
drivers/gpu/drm/panfrost/panfrost_job.c | 17 -
1 file changed, 12 insertions(+), 5 de
If we reach the beginning of the LRU AS list, then trigger an error.
Signed-off-by: Adrián Larumbe
---
drivers/gpu/drm/panfrost/panfrost_job.c | 4 +++-
drivers/gpu/drm/panfrost/panfrost_mmu.c | 8 +---
drivers/gpu/drm/panfrost/panfrost_mmu.h | 2 +-
drivers/gpu/drm/panfrost/panf
Just in case we're dealing with a yet not recognised device.
Signed-off-by: Adrián Larumbe
---
drivers/gpu/drm/panfrost/panfrost_gpu.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_gpu.c
b/drivers/gpu/drm/panfrost/panfrost
Drop the deprecated DRM driver allocation method in favour of
devm_drm_dev_alloc(). Overall just make it the same as in Panthor.
Also discard now superfluous generic and platform device pointers inside
the main panfrost device structure.
Some ancient checkpatch issues unearthed as a result of thes
On Wed, Sep 18, 2024 at 09:52:54AM -0600, Jeffrey Hugo wrote:
> The Sahara protocol has a crashdump functionality. In the hello
> exchange, the device can advertise it has a memory dump available for
> the host to collect. Instead of the device making requests of the host,
> the host requests data
Avoid hardcoding the LSPCON settle timeout because it takes a longer
time on certain chips made by certain vendors. Use the function that
already exists to determine the timeout.
Signed-off-by: Giedrius Statkevičius
---
drivers/gpu/drm/display/drm_dp_dual_mode_helper.c | 3 +--
drivers/gpu/drm/i
On Sat, Oct 05, 2024 at 09:04:11AM -0700, Kees Cook wrote:
>
>
>
> >On 03/10/24 12:36, Danilo Krummrich wrote:
> >> On 9/13/24 12:23 PM, Danilo Krummrich wrote:
>
> I am reminded that I should check all my MUAs to render the date as
> -MM-DD so my brain doesn't explode when I see people "t
Add support for gamma LUT in VOP2 driver. The implementation was inspired
by one found in VOP1 driver. Blue and red channels in gamma LUT register
write were swapped with respect to how gamma LUT values are written in
VOP1. Gamma LUT port selection was added before the write of new gamma LUT
table
[AMD Official Use Only - AMD Internal Distribution Only]
> -Original Message-
> From: Zhang, Jesse(Jie)
> Sent: Friday, October 11, 2024 9:45 PM
> To: Koenig, Christian ; dri-
> de...@lists.freedesktop.org; amd-...@lists.freedesktop.org
> Cc: Deucher, Alexander
> Subject: RE: [PATCH 1/2]
Am 14.10.24 um 12:54 schrieb Dave Stevenson:
On Mon, 14 Oct 2024 at 10:04, Maxime Ripard wrote:
Hi,
On Sun, Oct 13, 2024 at 09:57:58PM GMT, Stefan Wahren wrote:
Am 13.10.24 um 21:11 schrieb Dave Stevenson:
Hi Stefan.
On Sun, 13 Oct 2024, 18:19 Stefan Wahren, wrote:
Hi,
i rece
On 10/6/24 09:15, SurajSonawane2415 wrote:
Fix the indentation to ensure consistent code style and improve
readability, and to fix this warning:
drivers/video/fbdev/nvidia/nv_hw.c:1512 NVLoadStateExt() warn:
inconsistent indenting
Signed-off-by: SurajSonawane2415
---
drivers/video/fbdev/nvidi
On 10/13/24 13:48, Christophe JAILLET wrote:
'struct sbus_mmap_map' are not modified in these drivers.
Constifying this structure moves some data to a read-only section, so
increases overall security.
Update sbusfb_mmap_helper() accordingly.
On a x86_64, with allmodconfig, as an example:
Befor
On 10/10/2024 8:20 AM, Dmitry Baryshkov wrote:
On Wed, Oct 09, 2024 at 08:41:13PM GMT, Jessica Zhang wrote:
Don't set the merge_3d pending flush bits if the mode_3d is
BLEND_3D_NONE.
Always flushing merge_3d can cause timeout issues when there are
multiple commits with concurrent writeback e
On 10/14/2024 12:13 AM, Dmitry Baryshkov wrote:
On Sun, Oct 13, 2024 at 07:37:20PM -0700, Abhinav Kumar wrote:
Hi Dmitry
On 10/13/2024 5:20 PM, Dmitry Baryshkov wrote:
On Fri, Oct 11, 2024 at 10:25:13AM -0700, Jessica Zhang wrote:
Only enable the merge_3d block for the video phys encoder w
Hi Thomas,
On Wed, Oct 09, 2024 at 11:20:31AM +0200, Thomas Hellström wrote:
> When using mutex_acquire_nest() with a nest_lock, lockdep refcounts the
> number of acquired lockdep_maps of mutexes of the same class, and also
> keeps a pointer to the first acquired lockdep_map of a class. That point
On Mon, Oct 14, 2024 at 10:35:03AM GMT, Dmitry Baryshkov wrote:
> On Mon, Oct 07, 2024 at 11:03:09PM -0400, Alex Lanzano wrote:
> > This patch series add support for the monochrome Sharp Memory LCD
> > panels. This series is based off of the work done by Mehdi Djait.
> >
> > References:
> > https:
On Mon, Oct 14, 2024 at 09:25:19PM +0200, Peter Zijlstra wrote:
On Mon, Oct 14, 2024 at 01:20:34PM -0500, Lucas De Marchi wrote:
On Mon, Oct 14, 2024 at 07:32:46PM +0200, Peter Zijlstra wrote:
> I'm confused.. probably because I still don't have any clue about
> drivers and the above isn't re
On 10/6/2024 10:01 PM, Jonathan Marek wrote:
drm_mode_vrefresh() can introduce a large rounding error, avoid it.
Fixes: 7c9e4a554d4a ("drm/msm/dsi: Reduce pclk rate for compression")
Signed-off-by: Jonathan Marek
---
drivers/gpu/drm/msm/dsi/dsi_host.c | 2 +-
1 file changed, 1 insertion(+
On 9/21/2024 2:14 PM, Dmitry Baryshkov wrote:
The pll_cmp_to_fdata() was never used by the working code. Drop it to
prevent warnings with W=1 and clang.
Reported-by: Jani Nikula
Closes:
https://lore.kernel.org/dri-devel/3553b1db35665e6ff08592e35eb438a574d1ad65.1725962479.git.jani.nik...@int
On 10/6/2024 10:01 PM, Jonathan Marek wrote:
When (mode->clock * 1000) is larger than (1<<31), int to unsigned long
conversion will sign extend the int to 64 bits and the pclk_rate value
will be incorrect.
Fix this by making the result of the multiplication unsigned.
Note that above (1<<32)
On Mon, Oct 14, 2024 at 01:20:34PM -0500, Lucas De Marchi wrote:
> On Mon, Oct 14, 2024 at 07:32:46PM +0200, Peter Zijlstra wrote:
> > I'm confused.. probably because I still don't have any clue about
> > drivers and the above isn't really telling me much either.
> >
> > I don't see how you get r
On 14/10/2024 18:59, Miguel Ojeda wrote:
On Mon, Oct 14, 2024 at 10:54 AM Jocelyn Falempe wrote:
With the suggestions from Alice Ryhl to not introduce a return, and use
expect:
+1 to both.
`expect` (here and the other ones I suggested) require `rust-next`, so
if this goes through DRM, then
On 10/14/2024 9:36 AM, Douglas Anderson wrote:
The msm_disp_state_dump_regs():
- Doesn't allocate if the caller already allocated. ...but there's one
caller and it doesn't allocate so we don't need this check.
- Checks for allocation failure over and over even though it could
just do it
On 10/14/2024 9:36 AM, Douglas Anderson wrote:
If the allocation in msm_disp_state_dump_regs() failed then
`block->state` can be NULL. The msm_disp_state_print_regs() function
_does_ have code to try to handle it with:
if (*reg)
dump_addr = *reg;
...but since "dump_addr" is initializ
On 10/14/2024 9:36 AM, Douglas Anderson wrote:
With the "drm/msm: add a display mmu fault handler" series [1] we saw
issues in the field where memory allocation was failing when
allocating space for registers in msm_disp_state_dump_regs().
Specifically we were seeing an order 5 allocation fail
On Mon, Oct 14, 2024 at 07:32:46PM +0200, Peter Zijlstra wrote:
On Tue, Oct 08, 2024 at 01:34:59PM -0500, Lucas De Marchi wrote:
If a pmu is unregistered while there's an active event, perf will still
access the pmu via event->pmu, even after the event is destroyed. This
makes it difficult for d
Applied. Thanks!
Alex
On Mon, Oct 14, 2024 at 12:09 PM Ville Syrjala
wrote:
>
> From: Ville Syrjälä
>
> Include the encoder itself in its possible_clones bitmask.
> In the past nothing validated that drivers were populating
> possible_clones correctly, but that changed in commit
> 74d2aacbe840
Applied. Thanks!
Alex
On Thu, Oct 10, 2024 at 11:18 PM Lazar, Lijo wrote:
>
>
>
> On 10/11/2024 12:05 AM, Dan Carpenter wrote:
> > The >= ARRAY_SIZE() should be > ARRAY_SIZE() to prevent an out of
> > bounds read.
> >
> > Fixes: 012be6f22c01 ("drm/amdgpu: Add sysfs interfaces for NPS mode")
> >
On Fri, Sep 13, 2024 at 4:37 PM Rob Herring wrote:
>
> On Thu, Sep 12, 2024 at 9:44 AM Pin-yen Lin wrote:
> >
> > Add the port node to fix the binding schema check.
>
> The dsi node has the same issue.
This is still causing warnings in the tree. Please respin the patch.
>
> > Fixes: 009d855a26f
On Mon, Oct 14, 2024 at 3:51 AM AngeloGioacchino Del Regno
wrote:
>
> The display IPs in MediaTek SoCs support being interconnected with
> different instances of DDP IPs (for example, merge0 or merge1) and/or
> with different DDP IPs (for example, rdma can be connected with either
> color, dpi, ds
On Tue, Oct 08, 2024 at 01:34:59PM -0500, Lucas De Marchi wrote:
> If a pmu is unregistered while there's an active event, perf will still
> access the pmu via event->pmu, even after the event is destroyed. This
> makes it difficult for drivers like i915 that can be unbound from the
> HW.
>
>
Currently, virtio uses its own dumb_map_offset implementation,
virtio_gpu_mode_dumb_mmap. It works similarly to generic implementation,
drm_gem_dumb_map_offset, and using the generic implementation is
preferable (and making drivers to do so is a task stated on the DRM
subsystem's TODO list).
Thus,
> Attached is a full revert of the vblank support for you to test. If that
> undoes the bug, I'll post it for review to the list.
Thomas.
I applied that to v6.12-rc3. Builds cleanly.
System boots with no warnings.
MGAG device is present:
$ dmesg | grep mgag
[ 31.277259] mgag200 :08:00.0
Hi,
On Fri, Oct 11, 2024 at 7:20 AM Doug Anderson wrote:
>
> Hi,
>
> On Thu, Oct 10, 2024 at 7:08 PM Cong Yang
> wrote:
> >
> > The current panel brightness is only 360 nit. Adjust the power and gamma to
> > optimize the panel brightness. The brightness after adjustment is 390 nit.
> >
> > Fixes
On Mon, Oct 14, 2024 at 10:54 AM Jocelyn Falempe wrote:
>
> With the suggestions from Alice Ryhl to not introduce a return, and use
> expect:
+1 to both.
`expect` (here and the other ones I suggested) require `rust-next`, so
if this goes through DRM, then we can clean this up later. Otherwise,
i
The msm_disp_state_dump_regs():
- Doesn't allocate if the caller already allocated. ...but there's one
caller and it doesn't allocate so we don't need this check.
- Checks for allocation failure over and over even though it could
just do it once right after the allocation.
Clean this up.
Sig
With the "drm/msm: add a display mmu fault handler" series [1] we saw
issues in the field where memory allocation was failing when
allocating space for registers in msm_disp_state_dump_regs().
Specifically we were seeing an order 5 allocation fail. It's not
surprising that order 5 allocations will
If the allocation in msm_disp_state_dump_regs() failed then
`block->state` can be NULL. The msm_disp_state_print_regs() function
_does_ have code to try to handle it with:
if (*reg)
dump_addr = *reg;
...but since "dump_addr" is initialized to NULL the above is actually
a noop. The code then
On 10/14/2024 10:45, Alex Deucher wrote:
On Mon, Oct 14, 2024 at 11:25 AM Mario Limonciello wrote:
From: Mario Limonciello
The ASUS GA605W has a NVIDIA PCI VGA device and an AMD PCI display device.
```
65:00.0 VGA compatible controller: NVIDIA Corporation AD106M [GeForce RTX 4070
Max-Q / M
From: Ville Syrjälä
Include the encoder itself in its possible_clones bitmask.
In the past nothing validated that drivers were populating
possible_clones correctly, but that changed in commit
74d2aacbe840 ("drm: Validate encoder->possible_clones").
Looks like radeon never got the memo and is stil
On Mon, Oct 14, 2024 at 11:25 AM Mario Limonciello wrote:
>
> From: Mario Limonciello
>
> The ASUS GA605W has a NVIDIA PCI VGA device and an AMD PCI display device.
>
> ```
> 65:00.0 VGA compatible controller: NVIDIA Corporation AD106M [GeForce RTX
> 4070 Max-Q / Mobile] (rev a1)
> 66:00.0 Displ
https://bugzilla.kernel.org/show_bug.cgi?id=214071
Artem S. Tashkinov (a...@gmx.com) changed:
What|Removed |Added
Status|NEW |RESOLVED
Reso
From: Mario Limonciello
The ASUS GA605W has a NVIDIA PCI VGA device and an AMD PCI display device.
```
65:00.0 VGA compatible controller: NVIDIA Corporation AD106M [GeForce RTX 4070
Max-Q / Mobile] (rev a1)
66:00.0 Display controller: Advanced Micro Devices, Inc. [AMD/ATI] Strix
[Radeon 880M /
6.1-stable review patch. If anyone has any objections, please let me know.
--
From: Tvrtko Ursulin
commit 4286cc2c953983d44d248c9de1c81d3a9643345c upstream.
Without the locking amdgpu currently can race between
amdgpu_ctx_set_entity_priority() (via drm_sched_entity_modify_sche
6.1-stable review patch. If anyone has any objections, please let me know.
--
From: Thomas Zimmermann
commit 8b0d2f61545545ab5eef923ed6e59fc3be2385e0 upstream.
FB_DAMAGE_CLIPS is a plane property for damage handling. Its UAPI
should only use UAPI types. Hence replace struct dr
6.1-stable review patch. If anyone has any objections, please let me know.
--
From: Zack Rusin
commit aba07b9a0587f50e5d3346eaa19019cf3f86c0ea upstream.
The kms paths keep a persistent map active to read and compare the cursor
buffer. These maps can race with each other in sim
On Fri, Sep 27, 2024 at 11:04:48AM +0200, Christian König wrote:
> Am 25.09.24 um 16:53 schrieb Philipp Stanner:
> > On Tue, 2024-09-24 at 13:18 +0200, Simona Vetter wrote:
> > > On Mon, Sep 23, 2024 at 05:24:10PM +0200, Christian König wrote:
> > > > Am 20.09.24 um 15:26 schrieb Philipp Stanner:
>
I haven't been able to properly review the work on the driver for a while.
Hence, this commit removes me from the maintainers list.
Signed-off-by: Maíra Canal
---
MAINTAINERS | 1 -
1 file changed, 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 7d0b4335e263..23ac5fbf5e1c 100644
---
On Tue, Sep 24, 2024 at 01:18:25PM +0200, Simona Vetter wrote:
> On Mon, Sep 23, 2024 at 05:24:10PM +0200, Christian König wrote:
> > Am 20.09.24 um 15:26 schrieb Philipp Stanner:
> > > On Fri, 2024-09-20 at 12:33 +0200, Christian König wrote:
> > > > Am 20.09.24 um 10:57 schrieb Philipp Stanner:
>
On Thu, Oct 10, 2024 at 11:42:39AM -0400, Frank Li wrote:
> Convert device tree binding doc zii,rave-sp-backlight.txt to yaml format.
> Additional Changes:
> - Remove mfd parent node at example.
> - Ref to backlight's common.yaml
>
> Signed-off-by: Frank Li
Reviewed-by: Daniel Thompson
Daniel.
From: Brendan King
When remaining resources are being cleaned up on driver close,
outstanding VM mappings may result in resources being leaked, due
to an object reference loop, as shown below, with each object (or
set of objects) referencing the object below it:
PVR GEM Object
GPU schedu
From: Brendan King
This adds a linked list of VM contexts which is needed for the next patch
to be able to correctly track VM contexts for destruction on file close.
It is only safe for VM contexts to be removed from the list and destroyed
when not in interrupt context.
Signed-off-by: Brendan K
When remaining resources are being cleaned up on driver close,
outstanding VM mappings may result in resources being leaked, due
to an object reference loop, as shown below, with each object (or
set of objects) referencing the object below it:
PVR GEM Object
GPU scheduler "finished" fence
On Mon, 14 Oct 2024 14:34:25 +0100
Steven Price wrote:
> On 14/10/2024 10:31, Boris Brezillon wrote:
> > The system and GPU MMU page size might differ, which becomes a
> > problem for FW sections that need to be mapped at explicit address
> > since our PAGE_SIZE alignment might cover a VA range t
On Tue, Oct 01, 2024 at 02:42:59PM +0800, Hermes Wu wrote:
> From: Hermes Wu
>
> This is a v5 patch-set.
Please check the way you are sending your patches. For some reason my
email client lists patches 0-4 separately, patches 6-8 as a separate
thread and patches 5, 9, 10 as individual patches. P
On 10/14/2024 5:52 AM, Jinjie Ruan wrote:
> modprobe ttm_device_test and then rmmod ttm_device_test, the fllowing
nit: s/fllowing/following/
> memory leaks occurs:
On 14/10/2024 10:31, Boris Brezillon wrote:
> The system and GPU MMU page size might differ, which becomes a
> problem for FW sections that need to be mapped at explicit address
> since our PAGE_SIZE alignment might cover a VA range that's
> expected to be used for another section.
>
> Make sure w
On Wed, Oct 9, 2024 at 7:13 AM Erhard Furtner wrote:
>
> On Wed, 9 Oct 2024 09:28:44 +0300
> Ville Syrjälä wrote:
>
> > On Wed, Oct 09, 2024 at 12:03:21AM +0200, Erhard Furtner wrote:
> > > Greetings!
> > >
> > > On kernel v6.12-rc I get no X and dmesg (via netconsole) shows this at
> > > loadin
modprobe drm_hdmi_state_helper_test and then rmmod it, the following
memory leak occurs.
The `mode` allocated in drm_mode_duplicate() called by
drm_display_mode_from_cea_vic() is not freed, which cause the memory leak:
unreferenced object 0xff80ccd18100 (size 128):
comm "kun
modprobe drm_connector_test and then rmmod drm_connector_test,
the following memory leak occurs.
The `mode` allocated in drm_mode_duplicate() called by
drm_display_mode_from_cea_vic() is not freed, which cause the memory leak:
unreferenced object 0xff80cb0ee400 (size 128):
c
modprobe ttm_device_test and then rmmod ttm_device_test, the fllowing
memory leaks occurs:
The ttm->pages allocated in ttm_tt_init() is not freed after calling
ttm_tt_simple_create(), which cause the memory leak:
unreferenced object 0xff80caf27750 (size 8):
comm "kunit_try_c
As Maxime suggested, add a new helper
drm_kunit_helper_display_mode_from_cea_vic(), it can replace
the direct call of drm_display_mode_from_cea_vic(), and it will
help solving the `mode` memory leaks.
Suggested-by: Maxime Ripard
Signed-off-by: Jinjie Ruan
---
drivers/gpu/drm/tests/drm_kunit_hel
Fix some memory leaks in drm.
Changes in v2:
- Fix it with new introduced helper instead of drm_mode_destroy().
- Update the commit message.
- Add Reviewed-by.
Jinjie Ruan (4):
drm/tests: helpers: Add helper for drm_display_mode_from_cea_vic()
drm/connector: hdmi: Fix memory leak in
drm_d
On 04/10/2024 09:14, Jocelyn Falempe wrote:
On 04/10/2024 01:07, Miguel Ojeda wrote:
Under `CONFIG_DRM_PANIC_SCREEN_QR_CODE=y`, zlib is used:
ld.lld: error: undefined symbol: zlib_deflate_workspacesize
>>> referenced by drm_panic.c
>>> drivers/gpu/drm/drm_panic.o:(d
Hi
Am 11.10.24 um 18:44 schrieb Luck, Tony:
Posted too soon. Some time (kernel timestamps say a few minutes) after the
successful boot the console spewed another stack dump and the machine hung.
This warning is OK for the quick workaround.
Attached is a full revert of the vblank support for y
On 14/10/2024 12:32, Philipp Stanner wrote:
Hi,
On Mon, 2024-10-14 at 11:46 +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
In FIFO mode We can avoid dropping the lock only to immediately re-
acquire
by adding a new drm_sched_rq_update_fifo_locked() helper.
Please write detailed commit
On Tue, Oct 01, 2024 at 02:45:50PM +0800, Hermes Wu wrote:
> From: Hermes Wu
>
> DisplayPort AUX protocol supports I2C transport which is capable of reading
> EDID or supports MCCS.
>
> In drm_dp_helper, drm_dp_i2c_xfer() packs I2C requests into a sequence of AUX
> requests.
> it6505_aux_i2c_o
On Tue, Oct 01, 2024 at 02:43:44PM +0800, Hermes Wu wrote:
> From: Hermes Wu
>
> When running the HDCP CTS test with UNIGRAF DPR-100.
> KSV list must be read from DP_AUX_HDCP_KSV_FIFO in an AUX request, and can
> not separate with multiple read requests.
>
> The AUX operation command "CMD_AUX_G
On Tue, Oct 01, 2024 at 02:43:03PM +0800, Hermes Wu wrote:
> From: Hermes Wu
>
> A HDCP source device shall support max downstream to 127 devices.
> Change definition MAX_HDCP_DOWN_STREAM_COUNT to 127
>
> KSVs shall save for DRM blocked devices check.
> This results in struct it6505 growth by ~0
On Tue, Oct 01, 2024 at 02:43:02PM +0800, Hermes Wu wrote:
> From: Hermes Wu
>
> HDCP KSV list readback can choose to use AUX FIFO or general data register.
> For some DisplayPort devices, the KSV list must be read in 5 byte boundaries.
> The original AUX read command does not support these devic
On Tue, Oct 01, 2024 at 02:43:01PM +0800, Hermes Wu wrote:
> From: Hermes Wu
>
> The original AUX operation using data registers is limited to 4 bytes.
> The AUX operation command CMD_AUX_I2C_EDID_READ uses AUX FIFO and is capable
> of reading 16 bytes.
> This improves the speed of EDID read.
N
On Tue, Oct 01, 2024 at 02:43:00PM +0800, Hermes Wu wrote:
> From: Hermes Wu
>
> The hardware AUX FIFO is 16 bytes
> Change definition of AUX_FIFO_MAX_SIZE to 16
>
> Fixes: b5c84a9edcd4 ("drm/bridge: add it6505 driver")
> Signed-off-by: Hermes Wu
> ---
> drivers/gpu/drm/bridge/ite-it6505.c | 2
On Mon, 2024-10-14 at 11:46 +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> It does not seem there is a need to set the current entity in FIFO
> mode
> since ot only serves as being a "cursor" in round-robin mode. Even if
s/ot/it
> scheduling mode is changed at runtime the change in be
On Mon, Oct 14, 2024 at 11:25:00AM +, Biju Das wrote:
> Hi Dmitry,
>
> > -Original Message-
> > From: Dmitry Baryshkov
> > Sent: Monday, October 14, 2024 12:16 PM
> > Subject: Re: [PATCH v2 5/9] dt-bindings: display: bridge: Add ITE IT6263
> > LVDS to HDMI converter
> >
> > On Mon,
Hi,
On Mon, 2024-10-14 at 11:46 +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> In FIFO mode We can avoid dropping the lock only to immediately re-
> acquire
> by adding a new drm_sched_rq_update_fifo_locked() helper.
>
Please write detailed commit messages, as described here [1].
1
Hi Dmitry,
> -Original Message-
> From: Dmitry Baryshkov
> Sent: Monday, October 14, 2024 12:16 PM
> Subject: Re: [PATCH v2 5/9] dt-bindings: display: bridge: Add ITE IT6263 LVDS
> to HDMI converter
>
> On Mon, Oct 14, 2024 at 08:09:44AM +, Biju Das wrote:
> > Hi Dmitry,
> >
> > > -
On Mon, Oct 14, 2024 at 04:28:29PM +0800, Liu Ying wrote:
> On 10/14/2024, Dmitry Baryshkov wrote:
> > On Mon, Oct 14, 2024 at 03:18:15PM +0800, Liu Ying wrote:
> >> On 10/14/2024, Dmitry Baryshkov wrote:
> >>> On Sat, Oct 12, 2024 at 03:35:40PM +0800, Liu Ying wrote:
> Add basic HDMI video ou
On Mon, Oct 14, 2024 at 08:09:44AM +, Biju Das wrote:
> Hi Dmitry,
>
> > -Original Message-
> > From: Dmitry Baryshkov
> > Sent: Monday, October 14, 2024 9:04 AM
> > Subject: Re: [PATCH v2 5/9] dt-bindings: display: bridge: Add ITE IT6263
> > LVDS to HDMI converter
> >
> > On Mon, O
1 - 100 of 181 matches
Mail list logo
