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
---
Changes in v2:
Add 64BIT
v1:
https://lore.kernel.org/amd-gfx/56e7ec54-9820-4e02-be97-2a9e1dedd...@amd.com/T/#t
drivers/gpu/drm/amd/amdkfd/Kconfig | 2
For normal hibernation, GPU do not need to be resumed in thaw since it is
not involved in writing the hibernation image. Skip resume in this case
can reduce the hibernation time.
On VM with 8 * 192GB VRAM dGPUs, 98% VRAM usage and 1.7TB system memory,
this can save 50 minutes.
Signed-off-by: Samu
dev_pm_ops.thaw() is called in following cases:
* normal case: after hibernation image has been created.
* error case 1: creation of a hibernation image has failed.
* error case 2: restoration from a hibernation image has failed.
For normal case, it is called mainly for resume storage devices for
When hibernate with data center dGPUs, huge number of VRAM data will be
moved to shmem during dev_pm_ops.prepare(). These shmem pages take a lot
of system memory so that there's no enough free memory for creating the
hibernation image. This will cause hibernation fail and abort.
After dev_pm_ops.p
When hibernate with data center dGPUs, huge number of VRAM BOs evicted
to GTT and takes too much system memory. This will cause hibernation
fail due to insufficient memory for creating the hibernation image.
Move GTT BOs to shmem in KMD, then shmem to swap disk in kernel
hibernation code to make r
This new api is used for hibernation to move GTT BOs to shmem after
VRAM eviction. shmem will be flushed to swap disk later to reduce
the system memory usage for hibernation.
Signed-off-by: Samuel Zhang
---
drivers/gpu/drm/ttm/ttm_device.c | 23 +++
include/drm/ttm/ttm_device
Modern data center dGPUs are usually equipped with very large VRAM. On
server with such dGPUs(192GB VRAM * 8) and 2TB system memory, hibernate
will fail due to no enough free memory.
The root cause is that during hibernation all VRAM memory get evicted to
GTT or shmem. In both case, it is in syste
On Tue, Jul 8, 2025 at 6:12 AM Felix Kuehling wrote:
>
> On 2025-07-05 04:05, 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
> > ---
> > drivers/gpu/drm/amd/amdkfd/Kconfig | 2
Dear Imre,
Thank you very much for your patch, and the detailed commit message.
Am 08.07.25 um 23:23 schrieb Imre Deak:
Commit a40c5d727b81 ("drm/dp: Change AUX DPCD probe address from
DPCD_REV to LANE0_1_STATUS") stopped using the DPCD_REV register for
DPCD probing, since this results in link
On Tue, Jul 08, 2025 at 04:10:55PM +0200, David Hildenbrand wrote:
> On 06.03.25 05:42, Balbir Singh wrote:
> > Make THP handling code in the mm subsystem for THP pages
> > aware of zone device pages. Although the code is
> > designed to be generic when it comes to handling splitting
> > of pages,
The fastrpc driver has support for 5 types of remoteprocs. There are
some products which support GDSP remoteprocs. GDSP is General Purpose
DSP where tasks can be offloaded. Add fastrpc nodes and task offload
support for GDSP. Also strict domain IDs for domain.
Patch [v5]:
https://lore.kernel.org/l
在 7/9/2025 1:47 PM, Ling Xu 写道:
> The fastrpc driver has support for 5 types of remoteprocs. There are
> some products which support GDSP remoteprocs. GDSP is General Purpose
> DSP where tasks can be offloaded. This patch extends the driver to
> support GDSP remoteprocs.
>
sorry, please ignore th
Currently the domain ids are added for each instance of domains, this is
totally not scalable approach. Clean this mess and create domain ids for
only domains not its instances.
Co-developed-by: Srinivas Kandagatla
Signed-off-by: Srinivas Kandagatla
Signed-off-by: Ling Xu
---
drivers/misc/fast
The fastrpc driver has support for 5 types of remoteprocs. There are
some products which support GDSP remoteprocs. GDSP is General Purpose
DSP where tasks can be offloaded. This patch extends the driver to
support GDSP remoteprocs.
Signed-off-by: Ling Xu
---
drivers/misc/fastrpc.c | 6 +-
1
Add GDSP0 and GDSP1 fastrpc compute-cb nodes for sa8775p SoC.
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Konrad Dybcio
Signed-off-by: Ling Xu
---
arch/arm64/boot/dts/qcom/sa8775p.dtsi | 57 +++
1 file changed, 57 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sa87
There are some products which support GDSP remoteprocs. GDSP is General
Purpose DSP where tasks can be offloaded. There are 2 GDSPs named gdsp0
and gdsp1. Add "gdsp0" and "gdsp1" as the new supported labels for GDSP
fastrpc domains.
Acked-by: Krzysztof Kozlowski
Signed-off-by: Ling Xu
---
Docum
On 7/4/25 12:07 PM, André Almeida wrote:
> Fix the following warning:
>
> Documentation/gpu/drm-uapi.rst:450: WARNING: Title underline too short.
>
> Task information
> --- [docutils]
>
> Fixes: cd37124b4093 ("drm/doc: Add a section about "Task information" for the
> wedge API")
On 7/4/25 12:07 PM, André Almeida wrote:
> Fix the following kernel doc warning:
>
> include/drm/drm_device.h:40: warning: Function parameter or struct member
> 'pid' not described in 'drm_wedge_task_info'
> include/drm/drm_device.h:40: warning: Function parameter or struct member
> 'comm' no
On 7/4/25 12:07 PM, André Almeida wrote:
> Remove the repetitive wording at the end of "Task information" section.
>
> Reviewed-by: Raag Jadav
> Signed-off-by: André Almeida
> ---
> Documentation/gpu/drm-uapi.rst | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Acked-by: Randy Du
On 6/12/2025 3:54 PM, Dmitry Baryshkov wrote:
> On Thu, Jun 12, 2025 at 03:02:52PM +0530, Ekansh Gupta wrote:
>>
>> On 6/12/2025 1:35 PM, Dmitry Baryshkov wrote:
>>> On Thu, Jun 12, 2025 at 10:50:10AM +0530, Ekansh Gupta wrote:
On 5/22/2025 5:43 PM, Dmitry Baryshkov wrote:
> On Thu, 22
On 7/8/25 7:45 PM, Bagas Sanjaya wrote:
> Stephen Rothwell reports multiple indentation warnings when merging
> drm-msm tree:
>
> Documentation/gpu/drm-mm:506: ./drivers/gpu/drm/drm_gpuvm.c:2445: ERROR:
> Unexpected indentation. [docutils]
> Documentation/gpu/drm-mm:506: ./drivers/gpu/drm/drm_
On 7/8/25 23:41, David Hildenbrand wrote:
> On 06.03.25 05:42, Balbir Singh wrote:
>> Add flags to mark zone device migration pages.
>>
>> MIGRATE_VMA_SELECT_COMPOUND will be used to select THP pages during
>> migrate_vma_setup() and MIGRATE_PFN_COMPOUND will make migrating
>> device pages as compo
On 7/8/25 23:37, David Hildenbrand wrote:
> On 06.03.25 05:42, Balbir Singh wrote:
>> Add routines to support allocation of large order zone device folios
>> and helper functions for zone device folios, to check if a folio is
>> device private and helpers for setting zone device data.
>>
>> When la
On 7/8/2025 8:40 PM, Deucher, Alexander wrote:
> [Public]
>
>
> I seem to recall -ENOTSUPP being frowned upon for IOCTLs.
>
>
Going by documentation -
https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html
EOPNOTSUPP:
Feature (like PRIME, modesetting, GEM) is not supported by the driver.
"Not
On Tue, Jul 08, 2025 at 01:20:32PM +0100, 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_
Stephen Rothwell reports multiple indentation warnings when merging
drm-msm tree:
Documentation/gpu/drm-mm:506: ./drivers/gpu/drm/drm_gpuvm.c:2445: ERROR:
Unexpected indentation. [docutils]
Documentation/gpu/drm-mm:506: ./drivers/gpu/drm/drm_gpuvm.c:2447: WARNING:
Block quote ends without a blan
On Fri, Jul 04, 2025 at 04:07:24PM -0300, André Almeida wrote:
> Remove the repetitive wording at the end of "Task information" section.
>
Looks good, thanks!
Reviewed-by: Bagas Sanjaya
--
An old man doll... just what I always wanted! - Clara
signature.asc
Description: PGP signature
On Fri, Jul 04, 2025 at 04:07:22PM -0300, André Almeida wrote:
> Task information
>
> +
>
LGTM, thanks!
Tested-by: Bagas Sanjaya
--
An old man doll... just what I always wanted! - Clara
signature.asc
Description: PGP signature
On 7/8/2025 6:36 PM, Danilo Krummrich wrote:
> On Tue, Jul 08, 2025 at 03:49:40PM +0900, Alexandre Courbot wrote:
>> This series adds some documentation that was relevant to the FWSEC-FRTS
>> [1] series, but wasn't sent alongside it as it was worked on in
>> parallel.
>
> Joel, thanks a lot for
nable_sw_signaling(sync_file->fence);
info.status = dma_fence_get_status(sync_file->fence);
goto no_fences;
} else {
---
base-commit: 58ba80c4740212c29a1cf9b48f588e60a7612209
change-id: 20250708-syncfile-enable-signaling-a993acff1860
On 7/9/25 09:16, Jamie Heilman wrote:
Rui Salvaterra wrote:
Hi,
The machine (Atom 330 CPU, ION chipset, GeForce 9400M graphics) works,
but graphics are dead. Dmesg shows the following (Linux 6.16-rc5):
[ 34.408331] BUG: kernel NULL pointer dereference, address:
[ 34.4083
Rui Salvaterra wrote:
> Hi,
>
>
> The machine (Atom 330 CPU, ION chipset, GeForce 9400M graphics) works,
> but graphics are dead. Dmesg shows the following (Linux 6.16-rc5):
>
> [ 34.408331] BUG: kernel NULL pointer dereference, address:
> [ 34.408351] #PF: supervisor instruc
On Tue, Jul 08, 2025 at 03:49:40PM +0900, Alexandre Courbot wrote:
> This series adds some documentation that was relevant to the FWSEC-FRTS
> [1] series, but wasn't sent alongside it as it was worked on in
> parallel.
Joel, thanks a lot for this series. It's great to have this documentation --
ve
-Original Message-
From: Intel-gfx On Behalf Of Imre Deak
Sent: Tuesday, July 8, 2025 2:24 PM
To: intel-...@lists.freedesktop.org; intel...@lists.freedesktop.org;
dri-devel@lists.freedesktop.org
Cc: Ville Syrjälä ; Jani Nikula
; Paul Menzel
Subject: [PATCH] drm/dp: Change AUX DPCD probe
On Sun, Jun 22, 2025 at 11:32 PM Boris Brezillon
wrote:
>
> On Wed, 18 Jun 2025 07:55:49 -0700
> Chia-I Wu wrote:
>
> > It is unclear why fence errors were set only for CS_INHERIT_FAULT.
> > Downstream driver also does not treat CS_INHERIT_FAULT specially.
> > Remove the check.
> >
> > Signed-off
Commit a40c5d727b81 ("drm/dp: Change AUX DPCD probe address from
DPCD_REV to LANE0_1_STATUS") stopped using the DPCD_REV register for
DPCD probing, since this results in link training failures at least when
using an Intel Barlow Ridge TBT hub at UHBR link rates (the
DP_INTRA_HOP_AUX_REPLY_INDICATIO
On Tue, 08 Jul 2025 18:06:46 +0800, LiangCheng Wang wrote:
> The binding is for the Mayqueen Pixpaper e-ink display panel,
> controlled via an SPI interface.
>
> Signed-off-by: LiangCheng Wang
> ---
> .../bindings/display/mayqueen,pixpaper.yaml| 63
> ++
> 1 file c
On Tue, 08 Jul 2025 18:06:44 +0800, LiangCheng Wang wrote:
> From: Wig Cheng
>
> Mayqueen is a Taiwan-based company primarily focused on the development
> of arm64 development boards and e-paper displays.
>
> Signed-off-by: Wig Cheng
> ---
> Documentation/devicetree/bindings/vendor-prefixes.
On Fri, Jul 04, 2025 at 09:03:45PM +0200, Werner Sembach wrote:
> RFC because I'm not sure if this is the right approach.
Could you please file a gitlab issue for us so we can get someone from our
display team to take a look and see if there's anything else that could be done
before we take the qu
* li...@treblig.org (li...@treblig.org) wrote:
> From: "Dr. David Alan Gilbert"
>
> Hi,
> A couple of small deadcodings for qxl. The first
> just cleans up a couple of trivial unusued wrappers.
> The second cleans out some debugfs code that's been unused
> for a few years.
>
> Dave
> Signed-o
Move to using the new API devm_drm_panel_alloc() to allocate the
panel. In the call to the new API, avoid using explicit type and use
__typeof() for more type safety.
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/panel/panel-startek-kd070fhfid015.c | 12 ++--
1 file changed, 6 inser
Move to using the new API devm_drm_panel_alloc() to allocate the
panel. In the call to the new API, avoid using explicit type and use
__typeof() for more type safety.
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c | 12 ++--
1 file changed, 6 insertion
Move to using the new API devm_drm_panel_alloc() to allocate the
panel. In the call to the new API, avoid using explicit type and use
__typeof() for more type safety.
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/panel/panel-visionox-g2647fb105.c | 10 +-
1 file changed, 5 insertion
Move to using the new API devm_drm_panel_alloc() to allocate the
panel. In the call to the new API, avoid using explicit type and use
__typeof() for more type safety.
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/panel/panel-samsung-s6e63m0.c | 14 +++---
1 file changed, 7 insertion
Move to using the new API devm_drm_panel_alloc() to allocate the
panel. In the call to the new API, avoid using explicit type and use
__typeof() for more type safety.
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/panel/panel-tdo-tl070wsh30.c | 13 ++---
1 file changed, 6 insertions(
Move to using the new API devm_drm_panel_alloc() to allocate the
panel. In the call to the new API, avoid using explicit type and use
__typeof() for more type safety.
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/panel/panel-truly-nt35597.c | 10 +-
1 file changed, 5 insertions(+),
Use the new API devm_drm_panel_alloc() for panel allocations.
A major chunk of driver conversion was sent in a 3 part series
which is already merged. The coccinelle patch that was used to
identify unsafe panel allocations didnt flag about 20 drivers.
Not using any semantic patch for the remaining
On Mon, Jul 07, 2025 at 01:38:23PM -0700, Juston Li wrote:
Add TRACE_GPU_MEM tracepoints for tracking global GPU memory usage.
These are required by VSR on Android 12+ for reporting GPU driver memory
allocations.
v5:
- Drop process_mem tracking
- Set the gpu_id field to dev->primary->index (Luc
On Mon, 07 Jul 2025 18:49:01 +0200, Heiko Stuebner wrote:
> The rk3576 controller is based on the same newer Synopsis IP as the one
> found in the rk3588.
>
> Its external setting bits in the GRF are different though, so it needs
> its own distinct compatible.
>
> Signed-off-by: Heiko Stuebner
On Mon, 07 Jul 2025 18:49:00 +0200, Heiko Stuebner wrote:
> RK3576 CSI and DSI support requires the GRF for its DC-PHY.
> The "general register files" provide additional setting-bits
> outside the regular ip-block reg-space.
>
> Signed-off-by: Heiko Stuebner
> ---
> Documentation/devicetree/bi
On Mon, 07 Jul 2025 18:48:58 +0200, Heiko Stuebner wrote:
> Document the compatible value for Bestar BSD1218-A101KL68 LCD panels
> that are based around the ili9881c controller.
>
> Signed-off-by: Heiko Stuebner
> ---
> .../devicetree/bindings/display/panel/ilitek,ili9881c.yaml | 1 +
>
On Mon, 07 Jul 2025 18:48:57 +0200, Heiko Stuebner wrote:
> Add the prefix for Bestar, named in full both on Panelook.com and their
> display datasheets as
> Shenzhen Bestar Electronic Technology Co., Ltd.
> which produces at least DSI displays and maybe more.
>
> Signed-off-by: Heiko Stuebner
: next-20250625
Bad: next-20250702 till next-20250708
Boot regression: next-20250702 kernel NULL pointer dereference
adv7511_cec_register_volatile
Reported-by: Linux Kernel Functional Testing
I am investigating this issue,
Planning to revert and re-build and test in a loop.
c871c199accb3 regmap
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
This patch adds an ioctl to reassign the gem handle of a bo.
It was formerly the first patch of my CRIU with dmabuf patchset.
Would it be possible to merge this on its own? Internal deadlines
would prefer this to be in the next kernel release if possible.
The CRIU patches that are the current use
On Tue, Jul 08, 2025 at 01:21:21PM +0100, Tvrtko Ursulin wrote:
> Extract out two copies of the identical code to function epilogue to make
> it smaller and more readable.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Christian König
> Cc: Danilo Krummrich
> Cc: Matthew Brost
Reviewed-by: Matthew B
Hi Thomas,
Thanks for the feedback.
On Tue, 8 Jul 2025 at 5:10, Thomas Zimmermann wrote:
> Could this use pcim_request_all_regions() [1] instead? Cleanup and error
> rollback would be automatic.
> ...
> Instead of manual cleanup, you're better off using pcim_enable_device()
> [2] in kyrofb_probe(
On Tue, Jul 08, 2025 at 04:31:31PM +0100, Tvrtko Ursulin wrote:
>
> On 08/07/2025 14:02, Christian König wrote:
> > On 08.07.25 14:54, Tvrtko Ursulin wrote:
> > >
> > > On 08/07/2025 13:37, Christian König wrote:
> > > > On 08.07.25 11:51, Tvrtko Ursulin wrote:
> > > > > There is no reason to que
just tried the fix. Don't see the warnings in dmesg anymore. thx
On Tue, Jul 8, 2025 at 2:31 AM Simona Vetter wrote:
>
> On Mon, Jul 07, 2025 at 05:21:00PM -0500, Steve French wrote:
> > I also see it manually building 6.16-rc4 from Saturday (not just
> > seeing it with Ubuntu's daily build and
On Tue, Jul 08, 2025 at 10:25:47AM -0300, Maíra Canal wrote:
> Xe can skip the reset if TDR has fired before the free job worker and can
> also re-arm the timeout timer in some scenarios. Instead of manipulating
> scheduler's internals, inform the scheduler that the job did not actually
> timeout a
On Thu, 15 May 2025 20:35:54 +0800, long.yunj...@zte.com.cn wrote:
> In the probe path, dev_err() can be replaced with dev_err_probe()
> which will check if error code is -EPROBE_DEFER and prints the
> error name. It also sets the defer probe reason which can be
> checked later through debugfs.
>
On Tue, 10 Jun 2025 23:27:48 +0200, Heiko Stuebner wrote:
> Each window of a vop2 is usable by a specific set of video ports, so while
> binding the vop2, we look through the list of available windows trying to
> find one designated as primary-plane and usable by that specific port.
>
> The code
On Thu, 29 May 2025 15:13:34 +0800, Chaoyi Chen wrote:
> Convert it to drm bridge driver, it will be convenient for us to
> migrate the connector part to the display driver later.
> Considering that some code depend on the connector, the following
> changes have been made:
> - Only process edid i
On Mon, 21 Apr 2025 18:21:54 +0800, Andy Yan wrote:
> The all video ports of rk3568/rk3588 share the same OVL_LAYER_SEL
> and OVL_PORT_SEL registers, and the configuration of these two registers
> can be set to take effect when the vsync signal arrives at a certain Video
> Port.
>
> If two threa
On Mon, 26 May 2025 09:58:34 +0800, Chaoyi Chen wrote:
> Convert it to drm bridge driver, it will be convenient for us to
> migrate the connector part to the display driver later.
>
>
Applied, thanks!
[1/1] drm/rockchip: lvds: Convert to drm bridge
commit: 40a382aae1d4a4ca07fe19b0d16b4f
On Mon, 12 May 2025 20:46:01 +0800, Andy Yan wrote:
> Convert it to drm bridge driver, it will be convenient for us to
> migrate the connector part to the display driver later.
>
> Patches that have already been merged in drm-misc-next are dropped.
>
> PATCH 1~8 are some cleanup and refactor.
>
On Fri, 04 Jul 2025 19:31:53 +0300, Dmitry Baryshkov wrote:
> Describe the SC8180X-specific compatible for the DSI controller persent
> on the SoC. While the current DT for SC8180X doesn't use this
> compatible, all other platforms were updated to have one. This change
> makes SC8180X follow the
On Fri, 04 Jul 2025 19:31:55 +0300, Dmitry Baryshkov wrote:
> Describe the Mobile Display SubSystem (MDSS) unit as present on the
> SC8180X platform.
>
> Reported-by: Konrad Dybcio
> Signed-off-by: Dmitry Baryshkov
> ---
> .../bindings/display/msm/qcom,sc8180x-mdss.yaml| 359
> ++
On Fri, 04 Jul 2025 19:31:54 +0300, Dmitry Baryshkov wrote:
> Describe the Display Processing Unit (DPU) as present on the SC8180X
> platform.
>
> Reported-by: Konrad Dybcio
> Signed-off-by: Dmitry Baryshkov
> ---
> .../bindings/display/msm/qcom,sc8180x-dpu.yaml | 103
> +
5.15-stable review patch. If anyone has any objections, please let me know.
--
From: Thomas Zimmermann
commit ff9cb6d2035c586ea7c8f1754d4409eec7a2d26d upstream.
Disconnecting a DisplayLink device results in the following kernel
error messages
[ 93.041748] [drm:udl_urb_compl
5.15-stable review patch. If anyone has any objections, please let me know.
--
From: Thomas Zimmermann
[ Upstream commit 03bcbbb3995ba5df43af9aba45334e35f2dfe27b ]
Signal vt subsystem to redraw console when switching to dummycon
with deferred takeover enabled. Makes the consol
5.15-stable review patch. If anyone has any objections, please let me know.
--
From: Jiri Slaby (SUSE)
[ Upstream commit 8d5cc8eed738e3202379722295c626cba0849785 ]
The non-zero (true) return value from consw::con_switch() means a redraw
is needed. So make this return type a bo
5.15-stable review patch. If anyone has any objections, please let me know.
--
From: Jiri Slaby (SUSE)
[ Upstream commit 559f01a0ee6d924c6fec3eaf6a5b078b15e71070 ]
In consw::con_clear():
* Height is always 1, so drop it.
* Offsets and width are always unsigned values, so re-ty
5.15-stable review patch. If anyone has any objections, please let me know.
--
From: Jiri Slaby (SUSE)
[ Upstream commit dae3e6b6180f1a2394b984c596d39ed2c57d25fe ]
The 'init' parameter of consw::con_init() is true for the first call of
the hook on a particular console. So make
5.15-stable review patch. If anyone has any objections, please let me know.
--
From: Jiri Slaby (SUSE)
[ Upstream commit 03b89a08484a88fb9e0604cab2b3eb0c2f265c74 ]
Switch vgacon_scrolldelta() and vgacon_restore_screen() positions, so
that the former is not needed to be forward
5.15-stable review patch. If anyone has any objections, please let me know.
--
From: Jiri Slaby (SUSE)
[ Upstream commit 6ceed69cde8fe4a78fe50d62d7a88a5c1eed4709 ]
Most of the forward declarations in vgacon are not needed. Drop them.
Signed-off-by: "Jiri Slaby (SUSE)"
Cc: He
https://bugzilla.kernel.org/show_bug.cgi?id=220326
Bug ID: 220326
Summary: Mismatch between the meanings of brightness and
actual_brightness
Product: Drivers
Version: 2.5
Hardware: AMD
OS: Linux
On Mon, Jul 07, 2025 at 01:38:22PM -0700, Juston Li wrote:
Move the source to a better place in Device Drivers -> Graphics support
now that its configurable.
v4:
- Move source location (Tvrtko)
v3:
- Patch introduced to replace per-driver config (Lucas)
Signed-off-by: Juston Li
Reviewed-by: L
On 7/8/2025 12:08 PM, Zhang, GuoQing (Sam) wrote:
On 2025/7/8 22:40, Mario Limonciello wrote:
On 7/8/2025 3:42 AM, Samuel Zhang wrote:
For normal hibernation, GPU do not need to be resumed in thaw since
it is
not involved in writing the hibernation image. Skip resume in this case
can reduce t
On 7/8/2025 12:07 PM, Zhang, GuoQing (Sam) wrote:
On 2025/7/8 22:36, Mario Limonciello wrote:
On 7/8/2025 3:42 AM, Samuel Zhang wrote:
dev_pm_ops.thaw() is called in following cases:
* normal case: after hibernation image has been created.
* error case 1: creation of a hibernation image has fa
On 2025/7/8 22:40, Mario Limonciello wrote:
On 7/8/2025 3:42 AM, Samuel Zhang wrote:
For normal hibernation, GPU do not need to be resumed in thaw since
it is
not involved in writing the hibernation image. Skip resume in this case
can reduce the hibernation time.
On VM with 8 * 192GB VRAM dG
On 2025/7/8 22:36, Mario Limonciello wrote:
On 7/8/2025 3:42 AM, Samuel Zhang wrote:
dev_pm_ops.thaw() is called in following cases:
* normal case: after hibernation image has been created.
* error case 1: creation of a hibernation image has failed.
* error case 2: restoration from a hibernati
The kyro framebuffer driver did not request its PCI memory regions,
which could lead to conflicts with other drivers. This change
addresses the task "Request memory regions in all fbdev drivers"
from the file Documentation/gpu/todo.rst.
pci_request_regions() is now called during probe. To ensure
Hi,
The machine (Atom 330 CPU, ION chipset, GeForce 9400M graphics) works,
but graphics are dead. Dmesg shows the following (Linux 6.16-rc5):
[ 34.408331] BUG: kernel NULL pointer dereference, address:
[ 34.408351] #PF: supervisor instruction fetch in kernel mode
[ 34.4083
This series adds drm_bridge_get/put() calls for DRM bridges returned by
drm_bridge_chain_get_first_bridge().
All patches are Reviewed-by Maxime except patch 3.
This is part of the work towards removal of bridges from a still existing
DRM pipeline without use-after-free. The grand plan was discuss
The bridge returned by drm_bridge_chain_get_first_bridge() is
refcounted. Put it when done.
Reviewed-by: Maxime Ripard
Signed-off-by: Luca Ceresoli
---
This patch was added in v7.
---
drivers/gpu/drm/drm_probe_helper.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/drm_pro
The bridge returned by drm_bridge_chain_get_first_bridge() is
refcounted. Put it when done.
Reviewed-by: Maxime Ripard
Signed-off-by: Luca Ceresoli
---
Changes in v9:
- Added R-by Maxime
Changes in v8:
- reworked after the changes in pre_enable/post_disable order:
f6ee26f58870 ("drm/atomic-h
The bridge returned by drm_bridge_chain_get_first_bridge() is
refcounted. Put it when done. Use a scope-based free action to catch all
the code paths.
Signed-off-by: Luca Ceresoli
---
Changes in v9:
- declare 'bridge' variable on first usage to avoid unnecessary cleanup for
!connector_state->c
drm_bridge_chain_get_first_bridge() returns a bridge pointer that the
caller could hold for a long time. Increment the refcount of the returned
bridge and document it must be put by the caller.
Reviewed-by: Maxime Ripard
Signed-off-by: Luca Ceresoli
---
This patch was added in v7.
---
include/
Many functions get a drm_bridge pointer, only use it in the function body
(or a smaller scope such as a loop body), and don't store it. In these
cases they always need to drm_bridge_put() it before returning (or exiting
the scope).
Some of those functions have complex code paths with multiple retu
On 08/07/2025 14:02, Christian König wrote:
On 08.07.25 14:54, Tvrtko Ursulin wrote:
On 08/07/2025 13:37, Christian König wrote:
On 08.07.25 11:51, Tvrtko Ursulin wrote:
There is no reason to queue just a single job if scheduler can take more
and re-queue the worker to queue more.
That's
devm_drm_bridge_alloc() is the new API to be used for allocating (and
partially initializing) a private driver struct embedding a struct
drm_bridge.
This driver was missed during the automated conversion in commit
9c399719cfb9 ("drm: convert many bridge drivers from devm_kzalloc() to
devm_drm_brid
: 20250708-drm-bridge-convert-to-alloc-api-leftovers-6c8e2734b5e9
Best regards,
--
Luca Ceresoli
devm_drm_bridge_alloc() is the new API to be used for allocating (and
partially initializing) a private driver struct embedding a struct
drm_bridge.
This driver was missed during the automated conversion in commit
9c399719cfb9 ("drm: convert many bridge drivers from devm_kzalloc() to
devm_drm_brid
On Tue, Jul 8, 2025 at 5:45 AM Simona Vetter wrote:
>
> On Sat, Jul 05, 2025 at 01:44:40PM -0700, Robin Clark wrote:
> > Hi Dave, Simona,
> >
> > Pull for v6.17 as described below. A bit larger this time, bringing
> > in VM_BIND support, x1-45 support, x1-85 speedbin support, and sm8750
> > kms s
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 @@ struct drm_color_lut {
> _
[Public]
I seem to recall -ENOTSUPP being frowned upon for IOCTLs.
Alex
From: McRae, Geoffrey
Sent: Tuesday, July 8, 2025 5:13 AM
To: Koenig, Christian ; Kuehling, Felix
Cc: Deucher, Alexander ;
amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v2 1/1] drm/am
Hi
Am 08.07.25 um 16:46 schrieb Giovanni Di Santi:
The kyro framebuffer driver did not request its PCI memory regions,
which could lead to conflicts with other drivers. This change
addresses the task "Request memory regions in all fbdev drivers"
from the file Documentation/gpu/todo.rst.
pci_re
On 08.07.25 16:46, Zi Yan wrote:
On 8 Jul 2025, at 10:38, David Hildenbrand wrote:
On 06.03.25 05:42, Balbir Singh wrote:
Support splitting pages during THP zone device migration as needed.
The common case that arises is that after setup, during migrate
the destination might not be able to all
On 8 Jul 2025, at 10:38, David Hildenbrand wrote:
> On 06.03.25 05:42, Balbir Singh wrote:
>> Support splitting pages during THP zone device migration as needed.
>> The common case that arises is that after setup, during migrate
>> the destination might not be able to allocate MIGRATE_PFN_COMPOUND
1 - 100 of 212 matches
Mail list logo
