On Sat, Jul 12, 2025 at 06:02:31AM +0100, Al Viro wrote:
> [dma_buf_fd() fixes; no preferences regarding the tree it goes through -
> up to dri folks]
A MAINTAINERS change for the habanalabs driver landed in Linus' tree
a few hours ago. I'm adding the new maintainers Yaron, Koby and
Konstantin to
[dma_buf_fd() fixes; no preferences regarding the tree it goes through -
up to dri folks]
As soon as we'd inserted a file reference into descriptor table, another
thread could close it. That's fine for the case when all we are doing is
returning that descriptor to userland (it's a race, but it's
Add the connected and link_ready states to the debug logs for [un]plug
and HPD IRQ handling.
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/dp/dp_display.c | 38 -
1 file changed, 25 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_
Currently, the DP link training is being done during HPD. Move
link training to atomic_enable() in accordance with the atomic_enable()
documentation.
In addition, don't disable the link until atomic_post_disable() (as part
of the dp_ctrl_off[_link_stream]() helpers).
Since the link training is mo
Drop the now unused hpd_state field from msm_dp and adjust debug logs
accordingly
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/dp/dp_display.c | 36 +---
1 file changed, 13 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b
Call drm_bridge_hpd_notify() instead of drm_helper_hpd_irq_event(). This
way, we can directly call hpd_notify() via the bridge connector.
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/dp/dp_display.c | 17 +
drivers/gpu/drm/msm/dp/dp_display.h | 1 +
drivers/gpu/drm/msm/d
Drop the now-unused ST_DISCONNECT_PENDING state. This will completely
remove the hpd state enum.
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/dp/dp_display.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm
Drop the now-unused ST_CONNECTED state
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/dp/dp_display.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index dac5078a849d..c7ad61e96b37 100644
--- a/drivers/gpu/
From: Abhinav Kumar
Since all consumers of ST_DISPLAY_OFF have now been removed,
drop ST_DISPLAY_OFF from the list of hpd_states as technically
this was never a 'hpd' state anyway.
Signed-off-by: Abhinav Kumar
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/dp/dp_display.c | 3 ---
1 fil
Drop the now unused ST_DISCONNECTED state
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/dp/dp_display.c | 17 -
1 file changed, 17 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index 5efc8d4ecf54..dac5078a849d 100644
From: Abhinav Kumar
msm_dp_hpd_unplug_handle() checks if the display was already disabled and
if so does not transition to ST_DISCONNECT_PENDING state and goes directly
to ST_DISCONNECTED. The same result can be achieved with the !power_on
check.
Replace ST_DISPLAY_OFF with !power_on to achieve
Drop the now-unused ST_MAINLINK_READY hpd_state.
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/dp/dp_display.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index 17093b78900c..5efc8d4ecf54 100644
--- a/dr
Simplify the unplug event handling by dropping the link teardown (as it
is already handled as part of the atomic post_disable()).
With the link teardown removed, we can also drop hpd_state-specific
handling to minimize redundant code
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/dp/dp_ct
From: Abhinav Kumar
ST_DISPLAY_OFF check in msm_dp_bridge_atomic_enable() is used to check
that if the display was disabled while still hotplugged, phy needs
to be re-initialized.
This can be replaced with a different check as it just means the DP cable
is connected but without display being pow
Since the hpd_state is unused, change the "wrong hpd_state" debug log in
atomic post_disable() to log if the DP cable is disconnected.
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/dp/dp_display.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/ms
Since there is already a return early for when the DP link is ready and
because link_ready is only set after the DP is connected and link
training has completed, the DP will already be disconnect for plug-in
handling to happen.
Thus, there is no need delay the plug-in handling until ST_DISCONNECTE
From: Abhinav Kumar
In commit 8ede2ecc3e5ee ("drm/msm/dp: Add DP compliance tests on Snapdragon
Chipsets"), checks were introduced to avoid handling any plug or irq hpd
events in ST_DISPLAY_OFF state.
Even if we do get hpd events, after the bridge was disabled,
it should get handled. Moreover, i
The ST_MAINLINK_READY state and msm_dp::link_ready both indicate when
link training has been successfully completed and the link is ready to be
used.
Thus, replace ST_MAINLINK_READY checks with a check for
msm_dp::link_ready.
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/dp/dp_display.c
Replace ST_DISCONNECTED checks with checks for if !msm_dp::connected as
they both represent the DP cable being disconnected
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/dp/dp_display.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_d
Add a boolean to track whether the DP cable is physically plugged in.
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/dp/dp_display.c | 11 ++-
drivers/gpu/drm/msm/dp/dp_display.h | 1 +
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_displa
Replace the ST_MAINLINK_READY check here with a check for if the cable
is not connected.
Since atomic_check() fails if the link isn't ready, we technically don't
need a check against ST_MAINLINK_READY. The hpd_state should also never
really hit ST_DISPLAY_OFF since atomic_enable() shouldn't be cal
Currently, all HPD interrupt handling must go through the HPD state
machine.
This has caused many issues where the DRM framework assumes that DP is
in one state while the state machine is stuck in another state.
As discussed here [1], this series:
- Removes the state machine
- Moves link trainin
The pull request you sent on Sat, 12 Jul 2025 00:11:25 +0200:
> https://gitlab.freedesktop.org/drm/kernel.git tags/drm-fixes-2025-07-12
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/3c2fe27971c3c9cc27de6e369385f6428db6c0b5
Thank you!
--
Deet-doot-dot, I am a bot.
h
On Fri, Jul 11, 2025 at 03:19:00PM -0700, Linus Torvalds wrote:
> On Fri, 11 Jul 2025 at 14:46, Linus Torvalds
> wrote:
> >
> > I've only tested the previous commit being good twice now, but I'll go
> > back to the head of tree and try a revert to verify that this is
> > really it. Because maybe i
Hi iuncuim,
kernel test robot noticed the following build errors:
[auto build test ERROR on sunxi/sunxi/for-next]
[also build test ERROR on robh/for-next linus/master v6.16-rc5 next-20250711]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we
Xu Yilun wrote:
> On Sat, Jun 21, 2025 at 11:07:24AM +1000, Alexey Kardashevskiy wrote:
> >
> >
> > On 11/6/25 11:55, Alexey Kardashevskiy wrote:
> > > Hi,
> > >
> > > Is there a QEMU tree using this somewhere?
> >
> > Ping? Thanks,
>
> Sorry for late. I've finally got a public tree.
>
> http
On Fri, 11 Jul 2025 at 14:46, Linus Torvalds
wrote:
>
> I've only tested the previous commit being good twice now, but I'll go
> back to the head of tree and try a revert to verify that this is
> really it. Because maybe it's the now Nth time I found something that
> hides the problem, not the rea
Hi Linus,
The much-anticipated handle_count regression fix from -rc5, but as
discussed, not the pile of reverts - we'll go with what we have for at
least this rc to not rush into yet another issue. The
gem_handle_create_tail fix is another one that's a bit more tricky, but
not something legit user
On Fri, Jul 11, 2025 at 10:53:42AM -0400, David Francis wrote:
> The drm_gem ioctls were documented in internal file drm_gem.c
> instead of uapi header drm.h. Move them there and change to
> appropriate kerneldoc formatting.
>
> Signed-off-by: David Francis
Thanks a lot for taking care of this!
On Fri, Jul 11, 2025 at 01:34:19PM +0100, Chris Clayton wrote:
> Hi
>
> I've built and installed 6.16 cloned from Linus' tree and am consistently
> getting a warning during system startup.
> The warning is not produced by rc4 but is by rc5, so I've bisected between
> those two points abd the out
On Fri, Jul 11, 2025 at 11:37:30AM -0700, Linus Torvalds wrote:
> On Fri, 11 Jul 2025 at 10:35, Linus Torvalds
> wrote:
> >
> > I'm hoping the login time timeout / hang ends up being due to a known
> > netlink regression, and it just happened to look like a drm issue
> > because it exposes itself
On Fri, 11 Jul 2025 at 13:35, Linus Torvalds
wrote:
>
> Indeed. It turns out that the problem actually started somewhere
> between rc4 and rc5, and all my previous bisections never even came
> close, because kernels usually work well enough that I never realized
> that it went back that far.
It l
On 2025-07-09 02:51, Han Gao wrote:
KFD has been confirmed that can run on LoongArch systems.
It's necessary to support CONFIG_HSA_AMD on LoongArch.
Signed-off-by: Han Gao
Thank you. I'm applying this patch to amd-staging-drm-next.
Reviewed-by: Felix Kuehling
---
Changes in v2:
Add
On 7/11/25 2:10 AM, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20250710:
>
on x86_64, when
# CONFIG_SUSPEND is not set
# CONFIG_HIBERNATION is not set
# CONFIG_PM is not set
ERROR: modpost: "pm_hibernate_is_recovering"
[drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
caused by co
On Wed, Jul 9, 2025 at 3:28 PM Christophe JAILLET
wrote:
>
> If kasprintf() fails, some mutex still need to be released to avoid locking
> issue, as already done in all other error handling path.
>
> Fixes: c03ea34cbf88 ("drm/amdgpu: add support of debugfs for mqd information")
> Signed-off-by: Ch
Hi Dave, Simona,
A few more bits for 6.17.
The following changes since commit 17d081ef84a6f3c2a1867cc753d7c8459a34d829:
Merge tag 'drm-misc-next-2025-07-03' of
https://gitlab.freedesktop.org/drm/misc/kernel into drm-next (2025-07-04
11:54:31 +1000)
are available in the Git repository at:
Marcus Folkesson writes:
Hello Marcus,
> Hello Javier,
>
>
> On Thu, Jul 10, 2025 at 12:24:32PM +0200, Javier Martinez Canillas wrote:
>> This patch-series adds support for the Sitronix ST7567 Controller, which is
>> is a
>> monochrome Dot Matrix LCD Controller that has SPI, I2C and parallel
>
On Fri, 11 Jul 2025 at 13:07, Linus Torvalds
wrote:
>
> Oh well. I think I'll just have to go back to bisecting this thing.
> I've tried to do that several times, and it has failed due to being
> too flaky, but I think I've learnt the signs to look out for better
> too.
Indeed. It turns out that
Hello Javier,
On Thu, Jul 10, 2025 at 12:24:32PM +0200, Javier Martinez Canillas wrote:
> This patch-series adds support for the Sitronix ST7567 Controller, which is
> is a
> monochrome Dot Matrix LCD Controller that has SPI, I2C and parallel
> interfaces.
>
> The st7571-i2c driver only has su
On Fri, 11 Jul 2025 at 12:53, Jakub Kicinski wrote:
>
> Let me keep digging but other than the netlink stuff the rest doesn't
> stand out..
Oh well. I think I'll just have to go back to bisecting this thing.
I've tried to do that several times, and it has failed due to being
too flaky, but I thin
On Fri, 11 Jul 2025 12:42:54 -0700 Linus Torvalds wrote:
> Were there any other socket changes perhaps?
>
> I just looked, and gsd-screensaver-proxy seems to use a regular Unix
> domain stream socket. Maybe not related to netlink, did unix domain
> sockets end up with some similar changes?
Humpf.
On Fri, 11 Jul 2025 at 12:30, Linus Torvalds
wrote:
>
> So that "Oh, it worked this time" has been tainted by past experience.
> Will do several more boots now in the hope that it's gone for good.
Yeah, no.
There's still something wrong. The second boot looked fine, but then
starting chrome had
On Fri, 11 Jul 2025 12:30:28 -0700 Linus Torvalds wrote:
> > I spent several hours yesterday chasing all the wrong things (because
> > I thought it was in drm), and often thought "Oh, that fixed it". Only
> > to then realize that nope, the problem still happens.
> >
> > I will test the reverts. Sev
On Fri, 11 Jul 2025 at 12:18, Linus Torvalds
wrote:
>
> I spent several hours yesterday chasing all the wrong things (because
> I thought it was in drm), and often thought "Oh, that fixed it". Only
> to then realize that nope, the problem still happens.
>
> I will test the reverts. Several times.
Marcus Folkesson writes:
Hello Marcus,
> Hello Javier,
>
> On Thu, Jul 10, 2025 at 01:00:41PM +0200, Javier Martinez Canillas wrote:
>> >
>> > devm_gpiod_get_optional() returns -ENOENT when the GPIO is not found,
>> > and that is no error we want to propagage upwards.
>> >
>> > Maybe something l
On 03.07.2025 15:28, Caterina Shablia wrote:
> From: Boris Brezillon
>
> We are going to add flags/properties that will impact the VA merging
> ability. Instead of sprinkling tests all over the place in
> __drm_gpuvm_sm_map(), let's add a helper aggregating all these checks
> can call it for every
On 7/11/25 9:08 PM, Maíra Canal wrote:
Hi Tvrtko,
On 11/07/25 12:09, Tvrtko Ursulin wrote:
Currently the job free work item will lock sched->job_list_lock first time
to see if there are any jobs, free a single job, and then lock again to
decide whether to re-queue itself if there are more finis
On Fri, 11 Jul 2025 at 11:54, Linus Torvalds
wrote:
>
> Will do more testing.
Bah. What I thought was a "reliable hang" isn't actually that at all.
It ends up still being very random indeed.
That said, I do think it's related to this netlink issue, because the
symptoms end up being random delays
Hi Caterina,
On 03.07.2025 15:28, Caterina Shablia wrote:
> From: Boris Brezillon
>
> Move the lock/flush_mem operations around the gpuvm_sm_map() calls so
> we can implement true atomic page updates, where any access in the
> locked range done by the GPU has to wait for the page table updates
>
Hi Tvrtko,
On 11/07/25 12:09, Tvrtko Ursulin wrote:
Currently the job free work item will lock sched->job_list_lock first time
to see if there are any jobs, free a single job, and then lock again to
decide whether to re-queue itself if there are more finished jobs.
Since drm_sched_get_finished_
On Fri, 11 Jul 2025 at 11:46, Jakub Kicinski wrote:
>
> Hm. I'm definitely okay with reverting. So if you revert these three:
>
> a3c4a125ec72 ("netlink: Fix rmem check in netlink_broadcast_deliver().")
> a3c4a125ec72 ("netlink: Fix rmem check in netlink_broadcast_deliver().")
> ae8f160e7eb2 ("net
On Fri, 11 Jul 2025 11:33:10 -0700 Linus Torvalds wrote:
> Because this "emergency PR" does seem to have turned my "annoying
> problem with timeouts at initial login" into "now it doesn't boot at
> all".
Hm. I'm definitely okay with reverting. So if you revert these three:
a3c4a125ec72 ("netlink:
On Fri, 11 Jul 2025 11:57:29 +0800
iuncuim wrote:
> From: Mikhail Kalashnikov
>
> All devices based on the A523/A527/H728/T527 processors contain a G57 MC1 GPU.
>
> Enable the DT nodes for this GPU and specify a regulator that supplies power
> to the SoC's VDD_GPU pins. The other parameters ar
On Fri, 11 Jul 2025 at 10:35, Linus Torvalds
wrote:
>
> I'm hoping the login time timeout / hang ends up being due to a known
> netlink regression, and it just happened to look like a drm issue
> because it exposes itself as a hang at the first graphical login
>
> A netlink regression *might* fit
On 7/10/2025 3:38 PM, Krzysztof Kozlowski wrote:
> On 10/07/2025 21:03, Williams, Gregory wrote:
>> On 7/3/2025 12:48 AM, Krzysztof Kozlowski wrote:
>>> On 02/07/2025 17:56, Gregory Williams wrote:
In the device tree, there will be device node for the AI engine device,
and device nodes fo
On Fri, 11 Jul 2025 11:57:28 +0800
iuncuim wrote:
Hi,
> From: Mikhail Kalashnikov
>
> The Allwinner A523 SoC features the Mali-G57 MC1 GPU, which belongs
> to the Mali Valhall (v9) family. There is a power domain specifically
> for this GPU that needs to be enabled to utilize it.
>
> To enabl
[ Added in some drm people too, just to give a heads-up that it isn't
all their fault ]
On Fri, 11 Jul 2025 at 08:10, Jakub Kicinski wrote:
>
> The Netlink fixes (on top of the tree) restore
> operation of iw (WiFi CLI) which uses sillily small recv buffer,
> and is the reason for this "emergenc
Hello!
The CfP for XDC 2025 ends tonight at 23:59 CEST! You still have a few
hours left to submit your proposal, don't wait!
https://xdc2025.x.org
As usual, the conference is free of charge and open to the general
public. If you plan on attending, please make sure to register as early
as p
On Fri Jul 11, 2025 at 9:24 AM CEST, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> nouveau_drm_ioctl() only checks the _IOC_NR() bits in the DRM_NOUVEAU_NVIF
> command, but ignores the type and direction bits, so any command with
> '7' in the low eight bits gets passed into nouveau_abi16_ioctl()
On Fri, Jul 11, 2025, at 19:41, Danilo Krummrich wrote:
> On Fri Jul 11, 2025 at 9:24 AM CEST, Arnd Bergmann wrote:
>> diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
>> b/drivers/gpu/drm/nouveau/nouveau_drm.c
>> index 1527b801f013..506eeb44f0d4 100644
>> --- a/drivers/gpu/drm/nouveau/nouveau_d
On Thu, Jul 10, 2025 at 7:43 PM Brian Masney wrote:
> The round_rate() clk ops is deprecated, so migrate this driver from
> round_rate() to determine_rate() using the Coccinelle semantic patch
> on the cover letter of this series.
>
> Signed-off-by: Brian Masney
Reviewed-by: Linus Walleij
You
On Thu, Jul 10, 2025 at 7:43 PM Brian Masney wrote:
> The round_rate() clk ops is deprecated, so migrate this driver from
> round_rate() to determine_rate() using the Coccinelle semantic patch
> on the cover letter of this series.
>
> Signed-off-by: Brian Masney
Reviewed-by: Linus Walleij
You
On Fri Jul 11, 2025 at 9:24 AM CEST, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> nouveau_drm_ioctl() only checks the _IOC_NR() bits in the DRM_NOUVEAU_NVIF
> command, but ignores the type and direction bits, so any command with
> '7' in the low eight bits gets passed into nouveau_abi16_ioctl()
On 6/6/25 1:28 AM, Tomeu Vizoso wrote:
This uses the SHMEM DRM helpers and we map right away to the CPU and NPU
sides, as all buffers are expected to be accessed from both.
v2:
- Sync the IOMMUs for the other cores when mapping and unmapping.
v3:
- Make use of GPL-2.0-only for the copyright not
On 7/9/2025 7:08 AM, Rob Clark wrote:
When commit 98290b0a7d60 ("drm/msm: make it possible to disable
KMS-related code.") was rebased on top of commit 3bebfd53af0f ("drm/msm:
Defer VMA unmap for fb unpins"), the additional use of msm_kms was
overlooked, resulting in a build break when KMS is d
On 6/6/25 1:28 AM, Tomeu Vizoso wrote:
This initial version supports the NPU as shipped in the RK3588 SoC and
described in the first part of its TRM, in Chapter 36.
This NPU contains 3 independent cores that the driver can submit jobs
to.
This commit adds just hardware initialization and power
On Fri, 11 Jul 2025 at 08:48, Linus Torvalds
wrote:
>
> Background for others: current -git ends up having odd hangs when
> Xwayland starts for me (not at boot, but when I log in). It seems to
> be very timing-dependent, so presumably I'm just unlucky with my
> hardware.
Update for this thread as
On Fri, Jul 11, 2025 at 05:20:49PM +0200, Christian König wrote:
> On 11.07.25 15:37, Philipp Stanner wrote:
> > On Fri, 2025-07-11 at 15:22 +0200, Christian König wrote:
> >>
> >>
> >> On 08.07.25 15:25, Maíra Canal wrote:
> >>> When the DRM scheduler times out, it's possible that the GPU isn't hu
On Fri, Jul 11, 2025 at 04:45:53PM +0100, Adrián Larumbe wrote:
> Commit ec62d37d2c0d("drm/panthor: Fix the fast-reset logic") did away
> with the only reference to panthor_vm_flush_all(), so let's get rid
> of the orphaned definition.
>
> Signed-off-by: Adrián Larumbe
Reviewed-by: Liviu Dudau
On Fri, Jul 11, 2025 at 6:40 PM Robin Murphy wrote:
>
> On 11/07/2025 5:00 pm, Tomeu Vizoso wrote:
> > On Tue, Jun 24, 2025 at 3:50 PM Robin Murphy wrote:
> >>
> >> On 2025-06-06 7:28 am, Tomeu Vizoso wrote:
> >> [...]
> >>> diff --git a/drivers/accel/rocket/rocket_device.h
> >>> b/drivers/accel
Hi
Am 11.07.25 um 17:48 schrieb Linus Torvalds:
On Fri, 11 Jul 2025 at 02:40, Thomas Zimmermann wrote:
Reverting the whole thing is the only sensible action here.
I'm assuming this is against some current drm tree, not mine, because
it doesn't apply here.
Yes, it's against drm-misc-fixes, w
On 11/07/2025 5:00 pm, Tomeu Vizoso wrote:
On Tue, Jun 24, 2025 at 3:50 PM Robin Murphy wrote:
On 2025-06-06 7:28 am, Tomeu Vizoso wrote:
[...]
diff --git a/drivers/accel/rocket/rocket_device.h
b/drivers/accel/rocket/rocket_device.h
index
10acfe8534f00a7985d40a93f4b2f7f69d43caee..50e46f0516
On 7/8/25 11:10, Simon Ser wrote:
On Tuesday, June 17th, 2025 at 06:26, Alex Hung wrote:
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 651bdf48b766..21bd96f437e0 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -872,6 +872,16 @@ st
On 7/9/25 14:49, Borah, Chaitanya Kumar wrote:
Hi Alex,
-Original Message-
From: Alex Hung
Sent: Tuesday, June 17, 2025 9:47 AM
To: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org
Cc: wayland-de...@lists.freedesktop.org; harry.wentl...@amd.com;
alex.h...@amd.com; leo.
Hi
Am 11.07.25 um 16:46 schrieb Ville Syrjälä:
On Fri, Jul 11, 2025 at 11:08:03AM +0200, Simona Vetter wrote:
On Thu, Jul 10, 2025 at 04:43:02PM -0700, Jeff Johnson wrote:
I'm trying to debug a hibernation issue with the ath12k driver, but to
establish a baseline I started with Linus' current
On Tue, Jun 24, 2025 at 3:27 PM Robin Murphy wrote:
>
> On 2025-06-06 7:28 am, Tomeu Vizoso wrote:
> > Add the bindings for the Neural Processing Unit IP from Rockchip.
> >
> > v2:
> > - Adapt to new node structure (one node per core, each with its own
> >IOMMU)
> > - Several misc. fixes from
On Tue, Jun 24, 2025 at 3:50 PM Robin Murphy wrote:
>
> On 2025-06-06 7:28 am, Tomeu Vizoso wrote:
> [...]
> > diff --git a/drivers/accel/rocket/rocket_device.h
> > b/drivers/accel/rocket/rocket_device.h
> > index
> > 10acfe8534f00a7985d40a93f4b2f7f69d43caee..50e46f0516bd1615b5f826c5002a6c0ecbf9
Thanks Melissa. I will send this series to promotion test and post the
result by the end of next week.
On 6/18/25 11:19, Melissa Wen wrote:
Hi,
Siqueira and I have been working on a solution to reduce the usage of
drm_edid_raw in the AMD display driver, since the current guideline in
the DRM s
On Fri, 11 Jul 2025 at 02:40, Thomas Zimmermann wrote:
>
> Reverting the whole thing is the only sensible action here.
I'm assuming this is against some current drm tree, not mine, because
it doesn't apply here.
I'll try the smaller set of reverts that Simona suggested for my
testing, and will g
Commit ec62d37d2c0d("drm/panthor: Fix the fast-reset logic") did away
with the only reference to panthor_vm_flush_all(), so let's get rid
of the orphaned definition.
Signed-off-by: Adrián Larumbe
---
drivers/gpu/drm/panthor/panthor_mmu.c | 11 ---
drivers/gpu/drm/panthor/panthor_mmu.h |
On 11.07.25 15:37, Philipp Stanner wrote:
> On Fri, 2025-07-11 at 15:22 +0200, Christian König wrote:
>>
>>
>> On 08.07.25 15:25, Maíra Canal wrote:
>>> When the DRM scheduler times out, it's possible that the GPU isn't hung;
>>> instead, a job just took unusually long (longer than the timeout) but
The GL extension KHR_robustness uses the number of global and per-context
GPU resets to learn about graphics resets that affect a GL context. This
commit introduces a new V3D parameter to retrieve the number of GPU resets
triggered by jobs submitted through a file descriptor.
To retrieve this info
The GL extension KHR_robustness uses the number of global and per-context
GPU resets to learn about graphics resets that affect a GL context. This
commit introduces a new V3D parameter to retrieve the global number of
GPU resets that have happened since the driver was probed.
To retrieve this info
The GL extension KHR_robustness requires a mechanism for a GL application
to learn about graphics resets that affect a GL context. With the goal
to provide support for such extension in Mesa, this series implements
global and per-context GPU reset counters that user-space can retrieve
using the DRM
On 11/07/2025 14:04, Philipp Stanner wrote:
Late to the party; had overlooked that the discussion with Matt is
resolved. Some comments below
On Tue, 2025-07-08 at 13:20 +0100, Tvrtko Ursulin wrote:
Currently the job free work item will lock sched->job_list_lock first time
to see if there are
Currently the job free work item will lock sched->job_list_lock first time
to see if there are any jobs, free a single job, and then lock again to
decide whether to re-queue itself if there are more finished jobs.
Since drm_sched_get_finished_job() already looks at the second job in the
queue we c
The drm_gem ioctls were documented in internal file drm_gem.c
instead of uapi header drm.h. Move them there and change to
appropriate kerneldoc formatting.
Signed-off-by: David Francis
---
drivers/gpu/drm/drm_gem.c | 30 -
include/uapi/drm/drm.h| 40 ++
This patch adds a new ioctl GEM_CHANGE_HANDLE which is needed by
amdgpu CRIU for dmabuf.
The ioctl allows a user to move a gem object to a new handle.
In this version, I have added kerneldoc comments for the new ioctl
in drm.h and have moved over the other drm_gem.c ioctl docs
to drm.h.
Accompan
CRIU restore of drm buffer objects requires the ability to create
or import a buffer object with a specific gem handle.
Add new drm ioctl DRM_IOCTL_GEM_CHANGE_HANDLE, which takes
the gem handle of an object and moves that object to a
specified new gem handle.
This ioctl needs to call drm_prime_re
On Fri, Jul 11, 2025 at 11:08:03AM +0200, Simona Vetter wrote:
> On Thu, Jul 10, 2025 at 04:43:02PM -0700, Jeff Johnson wrote:
> > I'm trying to debug a hibernation issue with the ath12k driver, but to
> > establish a baseline I started with Linus' current tree. I have the
> > following
> > enable
Hi Christian,
On 11/07/25 10:22, Christian König wrote:
On 08.07.25 15:25, Maíra Canal wrote:
When the DRM scheduler times out, it's possible that the GPU isn't hung;
instead, a job just took unusually long (longer than the timeout) but is
still running, and there is, thus, no reason to reset
On Fri Jul 11, 2025 at 10:04 AM CEST, Alice Ryhl wrote:
> The prefix as_* should not be used for a constructor. Constructors
> usually use the prefix from_* instead.
>
> Some prior art in the stdlib: Box::from_raw, CString::from_raw,
> Rc::from_raw, Arc::from_raw, Waker::from_raw, File::from_raw_fd
Hi
this patch regresses buffer sharing between udl and amdgpu. The latter
uses TTM. When udl imports a dma_buf from amdgpu, vmap returns a kernel
address, but pagefaults on the buffer cannot be handled. A full error
message is attached. It fails right at [1], where udl read the first
pixel fr
On Thu, Jul 10, 2025 at 03:15:28PM +0300, Andy Shevchenko wrote:
> The list_for_each_rcu() relies on the rcu_dereference() API which is not
> provided by the list.h. At the same time list.h is a low-level basic header
> that must not have dependencies like RCU, besides the fact of the potential
> c
On 07/07/2025 18:04, Caterina Shablia wrote:
> From: Boris Brezillon
>
> This allows us to optimize mapping of a relatively small
> portion of a BO over and over in a large VA range, which
> is useful to support Vulkan sparse bindings in an efficient
> way.
>
> Signed-off-by: Boris Brezillon
>
Em 10/07/2025 18:59, Raag Jadav escreveu:
On Thu, Jul 10, 2025 at 06:27:45PM -0300, André Almeida wrote:
Em 04/07/2025 16:07, André Almeida escreveu:
Fix the following warning:
Documentation/gpu/drm-uapi.rst:450: WARNING: Title underline too short.
Task information
--- [docutils]
On Fri, 2025-07-11 at 15:22 +0200, Christian König wrote:
>
>
> On 08.07.25 15:25, Maíra Canal wrote:
> > When the DRM scheduler times out, it's possible that the GPU isn't hung;
> > instead, a job just took unusually long (longer than the timeout) but is
> > still running, and there is, thus, no
Hello Sergey,
> > + /* Report required division ratio setting for the MIPI clock
> > +dividers
>
> /* should be on a line of its own (unless you do a networking patch)...
OK.
> > +* pllclk/2 = vclk * DSI divider
>
>Why no spaces around / while there are spaces around *?
I missed t
From: Mikhail Kalashnikov
The Allwinner A523 SoC features the Mali-G57 MC1 GPU, which belongs
to the Mali Valhall (v9) family. There is a power domain specifically
for this GPU that needs to be enabled to utilize it.
To enable in a specific device, we need to enable the gpu node and specify
the
From: Mikhail Kalashnikov
Add a compatible for the Allwinner A523 SoC, with an integrated
ARM Mali G57 MC1 (Valhall-JM) GPU.
Signed-off-by: Mikhail Kalashnikov
---
Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devi
1 - 100 of 181 matches
Mail list logo
