On Tue, Jun 3, 2025 at 8:24 PM Michal Wilczynski
wrote:
> >
> > Agreed. And as far as implementation goes, you can have the same
> > driver be a PM domain AND pwrseq provider. It just has to bind to the
> > device node that represents an actual component, not a made-up
> > "convenience" node.
>
>
On 03/06/2025 21:43, Michal Wilczynski wrote:
>>> +* and resets. Otherwise, we fall back to managing them ourselves.
>>> +*/
>>> + pvr_dev->pwrseq = devm_pwrseq_get(dev, "gpu-power");
>>> + if (IS_ERR(pvr_dev->pwrseq)) {
>>> + int pwrseq_err = PTR_ERR(pvr_dev->pwrseq);
>>> +
>
On 08-05-2025 05:14, Daniele Ceraolo Spurio wrote:
On 4/29/2025 9:09 AM, Badal Nilawar wrote:
Load late binding firmware
Signed-off-by: Badal Nilawar
---
drivers/gpu/drm/xe/xe_device.c | 2 +
drivers/gpu/drm/xe/xe_late_bind_fw.c | 91 +++-
drivers/gpu/drm
On Wed Jun 4, 2025 at 6:14 AM JST, Lyude Paul wrote:
> On Wed, 2025-05-21 at 15:45 +0900, Alexandre Courbot wrote:
>> FWSEC-FRTS is run with the desired address of the FRTS region as
>> parameter, which we need to compute depending on some hardware
>> parameters.
>>
>> Do this in a `FbLayout` stru
On Mon Jun 2, 2025 at 9:26 PM JST, Danilo Krummrich wrote:
> On Wed, May 21, 2025 at 03:45:10PM +0900, Alexandre Courbot wrote:
>> FWSEC-FRTS is the first firmware we need to run on the GSP falcon in
>> order to initiate the GSP boot process. Introduce the structure that
>> describes it.
>>
>> Sig
On Tue, Jun 3, 2025 at 9:26 PM Peter Zijlstra wrote:
>
> On Mon, Jun 02, 2025 at 01:13:29PM +0200, Maxime Ripard wrote:
>
> > > I can't operate kunit
> >
> > Why not?
>
> Too complicated. People have even wrecked tools/testing/selftests/ to
> the point that it is now nearly impossible to run the s
On Mon, Jun 02, 2025 at 06:54:27AM +0200, Christoph Hellwig wrote:
> On Thu, May 29, 2025 at 04:32:02PM +1000, Alistair Popple wrote:
> > The PFN_MAP flag is no longer used for anything, so remove it. The
> > PFN_SG_CHAIN and PFN_SG_LAST flags never appear to have been used so
> > also remove them.
On Thu, May 29, 2025 at 12:46:20PM +0100, Jonathan Cameron wrote:
> On Thu, 29 May 2025 16:32:02 +1000
> Alistair Popple wrote:
>
> > The PFN_MAP flag is no longer used for anything, so remove it. The
> > PFN_SG_CHAIN and PFN_SG_LAST flags never appear to have been used so
> > also remove them.
>
e/xe_guc_pc.c | 4 ++--
drivers/gpu/drm/xe/xe_migrate.c | 4 ++--
drivers/gpu/drm/xe/xe_query.c| 2 +-
include/uapi/drm/xe_drm.h| 7 +--
12 files changed, 44 insertions(+), 37 deletions(-)
---
base-commit: 546b1c9e93c2bb8cf5ed24e0be1c86bb089b3253
change-id: 20250603-upstream-xe-non-4k-v2-4acf253c9bfd
Best regards,
--
Mingcong Bai
From: Mingcong Bai
Per the "Firmware" chapter in "drm/xe Intel GFX Driver", as well as
"Volume 8: Command Stream Programming" in "Intel® Arc™ A-Series Graphics
and Intel Data Center GPU Flex Series Open-Source Programmer's Reference
Manual For the discrete GPUs code named "Alchemist" and "Arctic
From: Mingcong Bai
It appears that the xe_res_cursor also assumes 4KiB alignment.
Current implementation uses `PAGE_SIZE' as an assumed alignment reference,
but 4KiB kernel page sizes is by no means a guarantee. On 16KiB-paged
kernels, this causes driver failures during boot up:
[ 23.242757]
From: Mingcong Bai
Similar to the preceding patch for GuC (and with the same references),
Intel GPUs expects command buffers to align to 4KiB boundaries.
Current code uses `PAGE_SIZE' as an assumed alignment reference but 4KiB
kernel page sizes is by no means a guarantee. On 16KiB-paged kernels,
From: Mingcong Bai
As this component hooks into userspace API, it should be assumed that it
will play well with non-4KiB/64KiB pages.
Use `PAGE_SIZE' as the final reference for page alignment instead.
Cc: sta...@vger.kernel.org
Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel
From: Mingcong Bai
The bo/ttm interfaces with kernel memory mapping from dedicated GPU
memory. It is not correct to assume that SZ_4K would suffice for page
alignment as there are a few hardware platforms that commonly uses non-
4KiB pages - for instance, 16KiB is the most commonly used kernel pa
On Tue, 03 Jun 2025 07:27:11 -0400 Jeff Layton wrote:
> For those just joining in, this series adds a new top-level
> "ref_tracker" debugfs directory, and has each ref_tracker_dir register a
> file in there as part of its initialization. It also adds the ability to
> register a symlink with a more
On Mon, May 26, 2025 at 10:15:17PM +0530, Ghimiray, Himal Prasad wrote:
>
>
> On 26-05-2025 20:36, Dan Carpenter wrote:
> > Hello Himal Prasad Ghimiray,
> >
> > Commit 09ba0a8f06cd ("drm/xe/svm: Implement prefetch support for SVM
> > ranges") from May 13, 2025 (linux-next), leads to the followin
On Tue, 3 Jun 2025 19:29:49 -0700 Jakub Kicinski wrote:
> > I think the i915 driver is doing something it shouldn't with these
> > objects. They seem to be initialized more than once, which could lead
> > to leaked ref_tracker objects. It would be good for one of the i915
> > maintainers to comme
On Wed Jun 4, 2025 at 6:45 AM JST, Lyude Paul wrote:
> On Wed, 2025-05-21 at 15:45 +0900, Alexandre Courbot wrote:
>> With all the required pieces in place, load FWSEC-FRTS onto the GSP
>> falcon, run it, and check that it successfully carved out the WPR2
>> region out of framebuffer memory.
>>
>>
On Fri May 30, 2025 at 6:30 AM JST, Timur Tabi wrote:
> On Wed, 2025-05-21 at 15:45 +0900, Alexandre Courbot wrote:
>
> I noticed something interesting in this change to Gpu::new().
>
>> + // Check that the WPR2 region does not already exists - if it does,
>> the GPU needs to be
>> +
On Wed Jun 4, 2025 at 6:32 AM JST, Lyude Paul wrote:
>> +unsafe fn transmute<'a, 'b, T: Sized + FromBytes>(
>> +fw: &'a DmaObject,
>> +offset: usize,
>> +) -> Result<&'b T> {
>> +if offset + core::mem::size_of::() > fw.size() {
>> +return Err(EINVAL);
>> +}
>> +if (fw.s
On 6/3/2025 12:39 PM, Chris Morgan wrote:
From: Chris Morgan
Add support for the Huiling hl055fhav028c panel as used on the
Gameforce Ace handheld gaming console. This panel uses a Himax HX8399C
display controller and requires a sparsely documented vendor provided
init sequence. The display
On Wed Jun 4, 2025 at 8:02 AM JST, Benno Lossin wrote:
> On Mon Jun 2, 2025 at 3:09 PM CEST, Alexandre Courbot wrote:
>> On Thu May 29, 2025 at 4:27 PM JST, Benno Lossin wrote:
>>> On Thu May 29, 2025 at 3:18 AM CEST, Alexandre Courbot wrote:
On Thu May 29, 2025 at 5:17 AM JST, Benno Lossin wr
On Wed Jun 4, 2025 at 7:53 AM JST, Benno Lossin wrote:
> On Mon Jun 2, 2025 at 11:39 AM CEST, Danilo Krummrich wrote:
>> On Thu, May 29, 2025 at 09:27:33AM +0200, Benno Lossin wrote:
>>> That's also fair, but we lose the constness of `next_multiple_of`, so
>>> you can't use `align_up` in a const fu
On Mon Jun 2, 2025 at 3:09 PM CEST, Alexandre Courbot wrote:
> On Thu May 29, 2025 at 4:27 PM JST, Benno Lossin wrote:
>> On Thu May 29, 2025 at 3:18 AM CEST, Alexandre Courbot wrote:
>>> On Thu May 29, 2025 at 5:17 AM JST, Benno Lossin wrote:
On Wed May 21, 2025 at 8:44 AM CEST, Alexandre Cou
v3:
- Patch introduced to replace per-driver config (Lucas)
Signed-off-by: Juston Li
---
drivers/gpu/trace/Kconfig | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/trace/Kconfig b/drivers/gpu/trace/Kconfig
index c24e9edd022e6..cd3d19c4a201c 100644
---
On Mon Jun 2, 2025 at 11:39 AM CEST, Danilo Krummrich wrote:
> On Thu, May 29, 2025 at 09:27:33AM +0200, Benno Lossin wrote:
>> That's also fair, but we lose the constness of `next_multiple_of`, so
>> you can't use `align_up` in a const function. That might confuse people
>> and then they write the
Add TRACE_GPU_MEM tracepoints for tracking global and per-process GPU
memory usage.
These are required by VSR on Android 12+ for reporting GPU driver memory
allocations.
v3:
- Use now configurable CONFIG_TRACE_GPU_MEM instead of adding a
per-driver Kconfig (Lucas)
v2:
- Use u64 as preferred
From: Dave Airlie
When you read this debugfs file it's isn't guaranteed the count
will happen before the scan, but I think the intent is that it does.
printf argument evaluation order is undefined.
Cc: Christian Koenig
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/ttm/ttm_pool.c | 4 +++-
1
On Tue, 3 Jun 2025 at 18:50, Christian König wrote:
>
> On 6/3/25 09:52, David Airlie wrote:
> > On Tue, Jun 3, 2025 at 5:47 PM Christian König
> > wrote:
> >>
> >> On 6/2/25 22:40, Dave Airlie wrote:
> >>> From: Dave Airlie
> >>>
> >>> Currently you can't see per-device numa aware pools proper
On Wed, 2025-05-21 at 15:45 +0900, Alexandre Courbot wrote:
> With all the required pieces in place, load FWSEC-FRTS onto the GSP
> falcon, run it, and check that it successfully carved out the WPR2
> region out of framebuffer memory.
>
> Signed-off-by: Alexandre Courbot
> ---
> drivers/gpu/nova
On Wed, 2025-05-21 at 15:45 +0900, Alexandre Courbot wrote:
> The FWSEC firmware needs to be extracted from the VBIOS and patched with
> the desired command, as well as the right signature. Do this so we are
> ready to load and run this firmware into the GSP falcon and create the
> FRTS region.
>
Reviewed-by: Lyude Paul
On Wed, 2025-05-21 at 15:45 +0900, Alexandre Courbot wrote:
> Some of the firmwares need to be patched at load-time with a signature.
> Add a couple of types and traits that sub-modules can use to implement
> this behavior, while ensuring that the correct kind of signature
On Tue, 2025-05-27 at 16:38 -0400, Joel Fernandes wrote:
> Hello,
> I split this particular patch into 3 patches:
>
> gpu: nova-core: vbios: Add support for FWSEC ucode extraction
> gpu: nova-core: vbios: Add support to look up PMU table in FWSEC
> gpu: nova-core: vbios: Add base support for VBIOS
On Wed, 2025-05-21 at 15:45 +0900, Alexandre Courbot wrote:
> FWSEC-FRTS is run with the desired address of the FRTS region as
> parameter, which we need to compute depending on some hardware
> parameters.
>
> Do this in a `FbLayout` structure, that will be later extended to
> describe more memory
Some comments down below (in addition to the ones that Danilo left). Mostly
nits since Danilo got to most of the good feedback :P
On Wed, 2025-05-21 at 15:45 +0900, Alexandre Courbot wrote:
> From: Joel Fernandes
>
> Add support for navigating and setting up vBIOS ucode data required for
> GSP t
From: Chris Morgan
Enable the DSI controller, DSI DCPHY, and Huiling hl055fhav028c
1080x1920 panel for the Gameforce Ace.
Signed-off-by: Chris Morgan
---
.../dts/rockchip/rk3588s-gameforce-ace.dts| 66 +++
1 file changed, 66 insertions(+)
diff --git a/arch/arm64/boot/dts/r
From: Chris Morgan
Add support for the Huiling hl055fhav028c panel as used on the
Gameforce Ace handheld gaming console. This panel uses a Himax HX8399C
display controller and requires a sparsely documented vendor provided
init sequence. The display resolution is 1080x1920 and is 70mm by 127mm
as
On 2025-06-03 06:51, Pekka Paalanen wrote:
> On Tue, 3 Jun 2025 08:30:23 +
> "Shankar, Uma" wrote:
>
>>> -Original Message-
>>> From: Pekka Paalanen
>>> Sent: Friday, May 30, 2025 7:28 PM
>>> To: Shankar, Uma
>>> Cc: Simon Ser ; Harry Wentland
>>> ; Alex Hung ; dri-
>>> de...@lis
On Tue, May 20, 2025 at 12:27:00PM +0200, Tomeu Vizoso wrote:
> Using the DRM GPU scheduler infrastructure, with a scheduler for each
> core.
>
> Userspace can decide for a series of tasks to be executed sequentially
> in the same core, so SRAM locality can be taken advantage of.
>
> The job subm
On 6/3/25 16:49, Bartosz Golaszewski wrote:
> On Tue, Jun 3, 2025 at 3:35 PM Bartosz Golaszewski wrote:
The compatible string could be updated like so:
"thead,th1520-aon-pwrseq"
>>>
>>> Should not be separate node, you already have one for AON.
>>>
>>
>> Agreed. And as far as imp
On Tue, Jun 3, 2025 at 2:11 AM Geert Uytterhoeven
wrote:
> Hi Anusha,
>
> On Fri, 30 May 2025 at 20:28, Anusha Srivatsa wrote:
> > Move to using the new API devm_drm_panel_alloc() to allocate the
> > panel.
> >
> > Reviewed-by: Neil Armstrong
> > Signed-off-by: Anusha Srivatsa
>
> Thanks for y
On 6/3/25 15:28, Krzysztof Kozlowski wrote:
> On Fri, May 30, 2025 at 12:23:50AM GMT, Michal Wilczynski wrote:
>> Update the Imagination PVR DRM driver to leverage the pwrseq framework
>> for managing the power sequence of the GPU on the T-HEAD TH1520 SoC.
>>
>> In pvr_device_init(), the driver
From: Chris Morgan
Add support for the DSI panel as found on the Gameforce Ace handheld
gaming console based on the RK3588s.
Chris Morgan (4):
dt-bindings: vendor-prefixes: Add prefix for Huiling
dt-bindings: display: himax-hx8394: Add Huiling hl055fhav028c
drm/panel: himax-hx8394: Add Sup
From: Chris Morgan
Add compatible string for the Huiling hl055fhav028c. This panel is
based on the Himax HX8399C display controller which is extremely
similar to the existing HX8394. Add a new constant for
himax,hx8399c for this new display controller as well.
Signed-off-by: Chris Morgan
---
.
From: Chris Morgan
Shenzhen Huiling Information Technology Co. Ltd. specializes in the
research and manufacturing of display and touch screens for industrial
usage. https://en.szhuiling.com/
Signed-off-by: Chris Morgan
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
1 file c
On 6/3/25 15:22, Krzysztof Kozlowski wrote:
> On Fri, May 30, 2025 at 12:23:53AM GMT, Michal Wilczynski wrote:
>> Add the device tree node for the T-HEAD TH1520 GPU power sequencer
>> (gpu_pwrseq) to the th1520.dtsi file.
>>
>> This node instantiates the thead,th1520-gpu-pwrseq driver, which
>
On 03/06/2025 20:26, Michal Wilczynski wrote:
>
>
> On 6/3/25 15:20, Krzysztof Kozlowski wrote:
>> On Fri, May 30, 2025 at 12:23:52AM GMT, Michal Wilczynski wrote:
>>> TH1520_RESET_ID_GPU_CLKGEN and TH1520_RESET_ID_GPU are required for GPU
>>> power sequencing to work. To make these symbols avai
Move the define outside the ifdef for CONFIG_DEBUG_FS to fix the build.
This currently breaks drm kunit tests:
$ ./tools/testing/kunit/kunit.py run --kunitconfig
drivers/gpu/drm/ttm/tests/.kunitconfig
ERROR:root:../drivers/gpu/drm/ttm/ttm_pool.c: In function
‘ttm_pool_mgr_init’:
On 6/3/25 14:25, Ulf Hansson wrote:
> On Fri, 30 May 2025 at 00:24, Michal Wilczynski
> wrote:
>>
>> This patch series introduces support for the Imagination IMG BXM-4-64
>> GPU found on the T-HEAD TH1520 SoC. A key aspect of this support is
>> managing the GPU's complex power-up and power-down
On 6/3/25 15:35, Bartosz Golaszewski wrote:
> On Tue, Jun 3, 2025 at 3:19 PM Krzysztof Kozlowski wrote:
>>
>> On Mon, Jun 02, 2025 at 10:29:13PM GMT, Michal Wilczynski wrote:
> +description: |
> + This binding describes the power sequencer for the T-HEAD TH1520 GPU.
> + This seque
On Tue, Jun 03, 2025 at 03:47:20PM +0100, Tvrtko Ursulin wrote:
diff --git a/drivers/gpu/drm/ttm/ttm_pool.c b/drivers/gpu/drm/ttm/ttm_pool.c
index c060c90b89c0..e671812789ea 100644
--- a/drivers/gpu/drm/ttm/ttm_pool.c
+++ b/drivers/gpu/drm/ttm/ttm_pool.c
@@ -1265,10 +1265,16 @@ int ttm_pool_debug
On 6/3/25 15:20, Krzysztof Kozlowski wrote:
> On Fri, May 30, 2025 at 12:23:52AM GMT, Michal Wilczynski wrote:
>> TH1520_RESET_ID_GPU_CLKGEN and TH1520_RESET_ID_GPU are required for GPU
>> power sequencing to work. To make these symbols available, add the
>> necessary include for the T-HEAD TH1
On Tue, 3 Jun 2025 10:54:49 -0700
Linus Torvalds wrote:
> On Tue, 3 Jun 2025 at 10:26, Steven Rostedt wrote:
> >
> > config DRM_TTM
> > tristate
> > - depends on DRM && MMU
> > + depends on DRM && MMU && SHMEM
>
> Yeah, except I think you should just make it be
>
>
val0/val1 are not initialised and are passed to xe_pcode_read():
xe_hwmon_pcode_write_power_limit()
? xe_pcode_read()
? pcode_mailbox_rw()
? __pcode_mailbox_rw()
If __pcode_mailbox_rw fails, val0/val1 could be left
uninitialised lead
On Tue, 3 Jun 2025 at 10:26, Steven Rostedt wrote:
>
> config DRM_TTM
> tristate
> - depends on DRM && MMU
> + depends on DRM && MMU && SHMEM
Yeah, except I think you should just make it be
depends on DRM && SHMEM
because SHMEM already depends on MMU.
That said,
From: Thomas Zimmermann Sent: Monday, June 2, 2025 11:25
PM
>
> Hi
>
> Am 03.06.25 um 03:49 schrieb Michael Kelley:
> [...]
> >> Will the VMA have VM_PFNMAP or VM_MIXEDMAP set? PFN_SPECIAL is a
> >> horrible hack.
> >>
> >> In another thread, you mention that you use PFN_SPECIAL to bypass the
>
From: David Hildenbrand Sent: Tuesday, June 3, 2025 12:55 AM
>
> On 03.06.25 03:49, Michael Kelley wrote:
> > From: David Hildenbrand Sent: Monday, June 2, 2025 2:48
> > AM
> >>
> >> On 23.05.25 18:15, mhkelle...@gmail.com wrote:
> >>> From: Michael Kelley
> >>>
> >>> Current defio code works
[ Adding DRM folks ]
On Tue, 3 Jun 2025 17:26:23 +0100
Matthew Wilcox wrote:
> On Tue, Jun 03, 2025 at 10:29:59AM -0400, Steven Rostedt wrote:
> > On Tue, 3 Jun 2025 01:02:36 -0700 (PDT)
> > Hugh Dickins wrote:
> >
> > > Agreed that ramfs does not use swap, so calling swap_writepage() woul
On 03/06/2025 17:27, Christian König wrote:
On 6/3/25 17:00, Tvrtko Ursulin wrote:
On 03/06/2025 14:13, Maxime Ripard wrote:
Hi,
On Mon, Jun 02, 2025 at 04:42:27PM +0200, Christian König wrote:
On 6/2/25 15:05, Tvrtko Ursulin wrote:
On 15/05/2025 14:15, Christian König wrote:
Hey drm-mis
On 6/3/25 18:18, Thomas Zimmermann wrote:
Hi
Am 03.06.25 um 18:08 schrieb Helge Deller:
On 6/2/25 09:51, Thomas Zimmermann wrote:
Protect global edid_info behind CONFIG_FIRMWARE_EDID and remove
the config tests for CONFIG_X86. Makes edid_info available iff
its option has been enabled.
Signed-
On 6/2/25 09:51, Thomas Zimmermann wrote:
DRM drivers such as efidrm and vesadrm can export firmware EDID
data to userspace. Make the related option CONFIG_FIRMWARE_EDID
available without CONFIG_FB. Make it depend on X86, which is
currently the only architecture providing EDID information.
Signe
On 6/3/25 17:00, Tvrtko Ursulin wrote:
>
> On 03/06/2025 14:13, Maxime Ripard wrote:
>> Hi,
>>
>> On Mon, Jun 02, 2025 at 04:42:27PM +0200, Christian König wrote:
>>> On 6/2/25 15:05, Tvrtko Ursulin wrote:
On 15/05/2025 14:15, Christian König wrote:
> Hey drm-misc maintainers,
>
>>
Hi
Am 03.06.25 um 18:08 schrieb Helge Deller:
On 6/2/25 09:51, Thomas Zimmermann wrote:
Protect global edid_info behind CONFIG_FIRMWARE_EDID and remove
the config tests for CONFIG_X86. Makes edid_info available iff
its option has been enabled.
Signed-off-by: Thomas Zimmermann
---
arch/x86/k
BT.601 weights RGB components by certain factors to convert the
color to grayscale. Normalize the constants to 256 instead of 10.
Allows for slightly more precise rounding. The division by 256 can
be compiled as an 8-bit shift, which might be faster on some hardware.
Signed-off-by: Thomas Zimmerma
On 6/3/25 15:13, Maxime Ripard wrote:
> Hi,
>
> On Mon, Jun 02, 2025 at 04:42:27PM +0200, Christian König wrote:
>> On 6/2/25 15:05, Tvrtko Ursulin wrote:
>>> On 15/05/2025 14:15, Christian König wrote:
Hey drm-misc maintainers,
can you guys please backmerge drm-next into drm-misc-n
On 6/2/25 09:51, Thomas Zimmermann wrote:
Protect global edid_info behind CONFIG_FIRMWARE_EDID and remove
the config tests for CONFIG_X86. Makes edid_info available iff
its option has been enabled.
Signed-off-by: Thomas Zimmermann
---
arch/x86/kernel/setup.c | 4
drivers/gpu/drm
On 6/3/25 16:28, Christoph Hellwig wrote:
> On Tue, Jun 03, 2025 at 04:18:22PM +0200, Christian König wrote:
>>> Does it matter compared to the I/O in this case?
>>
>> It unfortunately does, see the numbers on patch 3 and 4.
>
> That's kinda weird. Why does the page table lookup tage so much
> ti
Use the helper screen_info_video_type() to get the framebuffer
type from struct screen_info. Handle supported values in sorted
switch statement.
Reading orig_video_isVGA is unreliable. On most systems it is a
VIDEO_TYPE_ constant. On some systems with VGA it is simply set
to 1 to signal the presen
Reading DPCD registers has side-effects and some of these can cause a
problem for instance during link training. Based on this it's better to
avoid the probing quirk done before each DPCD register read, limiting
this to the monitor which requires it. Add an EDID quirk for this. Leave
the quirk enab
On 03/06/2025 14:13, Maxime Ripard wrote:
Hi,
On Mon, Jun 02, 2025 at 04:42:27PM +0200, Christian König wrote:
On 6/2/25 15:05, Tvrtko Ursulin wrote:
On 15/05/2025 14:15, Christian König wrote:
Hey drm-misc maintainers,
can you guys please backmerge drm-next into drm-misc-next?
I want to
On Tue, Jun 3, 2025 at 3:35 PM Bartosz Golaszewski wrote:
> > >
> > > The compatible string could be updated like so:
> > > "thead,th1520-aon-pwrseq"
> >
> > Should not be separate node, you already have one for AON.
> >
>
> Agreed. And as far as implementation goes, you can have the same
> driver
On 03/06/2025 13:57, Christian König wrote:
On 6/3/25 13:27, Tvrtko Ursulin wrote:
The default core shrink target of 128 pages (SHRINK_BATCH) is quite low
relative to how cheap TTM pool shrinking is, and how the free pages are
distributed in page order pools.
We can make the target a bit more
On 6/2/2025 8:43 AM, Simona Vetter wrote:
On Wed, May 28, 2025 at 09:15:22AM -0600, Jeff Hugo wrote:
On 5/28/2025 3:13 AM, Simona Vetter wrote:
Handles are per-file, not global, so this makes no sense. Plus it's
set only after calling drm_gem_handle_create(), and drivers are not
allowed to furt
Dmitry Baryshkov 于2025年6月3日周二 18:21写道：
>
> On Tue, Jun 03, 2025 at 03:10:09PM +0800, Jun Nie wrote:
> > Currently, SSPPs are assigned to a maximum of two pipes. However,
> > quad-pipe usage scenarios require four pipes and involve configuring
> > two stages. In quad-pipe case, the first two pipes
On 6/2/2025 9:33 AM, Danilo Krummrich wrote:
[...]
>> +impl PcirStruct {
>> +fn new(pdev: &pci::Device, data: &[u8]) -> Result {
>> +if data.len() < core::mem::size_of::() {
>> +dev_err!(pdev.as_ref(), "Not enough data for PcirStruct\n");
>> +return Err(EINVAL
On 6/3/25 15:19, Christoph Hellwig wrote:
> On Tue, Jun 03, 2025 at 03:14:20PM +0200, Christian König wrote:
>> On 6/3/25 15:00, Christoph Hellwig wrote:
>>> This is a really weird interface. No one has yet to explain why dmabuf
>>> is so special that we can't support direct I/O to it when we can
On Thu, May 29, 2025 at 10:40:12AM +0800, Xilin Wu wrote:
> On 2025/4/24 01:52:45, Dmitry Baryshkov wrote:
> > From: Dmitry Baryshkov
> >
> > The MSM DisplayPort driver implements several HDMI codec functions
> > in the driver, e.g. it manually manages HDMI codec device registration,
> > returnin
On 6/3/25 14:48, Tvrtko Ursulin wrote:
>
> On 03/06/2025 13:40, Christian König wrote:
>> On 6/3/25 13:30, Tvrtko Ursulin wrote:
>>>
>>> On 02/06/2025 19:00, Christian König wrote:
On 6/2/25 17:25, Tvrtko Ursulin wrote:
>
> On 02/06/2025 15:42, Christian König wrote:
>> On 6/2/25
On 08-05-2025 04:41, Daniele Ceraolo Spurio wrote:
On 4/29/2025 9:09 AM, Badal Nilawar wrote:
Search for late binding firmware binaries and populate the meta data of
firmware structures.
Signed-off-by: Badal Nilawar
---
drivers/gpu/drm/xe/xe_device.c | 2 +
drivers/gpu/drm/xe/xe
On 08-05-2025 03:08, Daniele Ceraolo Spurio wrote:
On 4/29/2025 9:09 AM, Badal Nilawar wrote:
Introducing late_bind_fw to enable firmware loading for the devices,
such as the fan controller and voltage regulator, during the driver
probe.
Typically, firmware for these devices are part of IFW
On Thu, May 29, 2025 at 04:32:13PM +1000, Alistair Popple wrote:
> It's no longer used so remove it.
>
> Signed-off-by: Alistair Popple
> ---
> mm/memremap.c | 27 ---
> 1 file changed, 27 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
On Thu, May 29, 2025 at 04:32:12PM +1000, Alistair Popple wrote:
> All PFN_* pfn_t flags have been removed. Therefore there is no longer
> a need for the pfn_t type and all uses can be replaced with normal
> pfns.
>
> Signed-off-by: Alistair Popple
> Reviewed-by: Christoph Hellwig
Yay!
Reviewe
On Thu, May 29, 2025 at 04:32:11PM +1000, Alistair Popple wrote:
> Now that DAX and all other reference counts to ZONE_DEVICE pages are
> managed normally there is no need for the special devmap PTE/PMD/PUD
> page table bits. So drop all references to these, freeing up a
> software defined page tab
On 6/3/25 3:47 PM, Joel Fernandes wrote:
On 6/3/2025 4:12 AM, Alexandre Courbot wrote:
Would it then make sense to make `FwSecBiosImage` public, add an `fn
fwsec_image(&self) -> &FwSecBiosImage` method and have the caller call
its methods directly (maybe renamed to `header`, `ucode` and `sigs`)?
On Thu, May 29, 2025 at 04:32:10PM +1000, Alistair Popple wrote:
> PFN_DEV no longer exists. This means no devmap PMDs or PUDs will be
> created, so checking for them is redundant. Instead mappings of pages that
> would have previously returned true for pXd_devmap() will return true for
> pXd_trans
On Thu, May 29, 2025 at 04:32:09PM +1000, Alistair Popple wrote:
> The only users of pmd_devmap were device dax and fs dax. The check for
> pmd_devmap() in check_pmd_state() is therefore redundant as callers
> explicitly check for is_zone_device_page(), so this check can be dropped.
>
> Signed-off
On Thu, May 29, 2025 at 04:32:08PM +1000, Alistair Popple wrote:
> DAX was the only thing that created pmd_devmap and pud_devmap entries
> however it no longer does as DAX pages are now refcounted normally and
> pXd_trans_huge() returns true for those. Therefore checking both pXd_devmap
> and pXd_t
On 6/3/2025 4:12 AM, Alexandre Courbot wrote:
> On Tue Jun 3, 2025 at 12:15 AM JST, Joel Fernandes wrote:
>> On Mon, Jun 02, 2025 at 03:33:56PM +0200, Danilo Krummrich wrote:
>>> On Wed, May 21, 2025 at 03:45:11PM +0900, Alexandre Courbot wrote:
+impl Vbios {
>>>
>>>
>>>
+pub(crat
On Thu, May 29, 2025 at 04:32:07PM +1000, Alistair Popple wrote:
> GUP uses pXX_devmap() calls to see if it needs to a get a reference on
> the associated pgmap data structure to ensure the pages won't go
> away. However it's a driver responsibility to ensure that if pages are
> mapped (ie. discove
On Thu, May 29, 2025 at 04:32:06PM +1000, Alistair Popple wrote:
> PFN_DEV was used by callers of dax_direct_access() to figure out if the
> returned PFN is associated with a page using pfn_t_has_page() or
> not. However all DAX PFNs now require an assoicated ZONE_DEVICE page so can
> assume a page
On Thu, May 29, 2025 at 04:32:05PM +1000, Alistair Popple wrote:
> DAX no longer requires device PTEs as it always has a ZONE_DEVICE page
> associated with the PTE that can be reference counted normally. Other users
> of pte_devmap are drivers that set PFN_DEV when calling vmf_insert_mixed()
> whic
On Thu, May 29, 2025 at 04:32:04PM +1000, Alistair Popple wrote:
> Previously dax pages were skipped by the pagewalk code as pud_special() or
> vm_normal_page{_pmd}() would be false for DAX pages. Now that dax pages are
> refcounted normally that is no longer the case, so add explicit checks to
> s
On Tue, Jun 3, 2025 at 3:19 PM Krzysztof Kozlowski wrote:
>
> On Mon, Jun 02, 2025 at 10:29:13PM GMT, Michal Wilczynski wrote:
> > >> +description: |
> > >> + This binding describes the power sequencer for the T-HEAD TH1520 GPU.
> > >> + This sequencer handles the specific power-up and power-dow
On Thu, May 29, 2025 at 04:32:03PM +1000, Alistair Popple wrote:
> Currently dax is the only user of pmd and pud mapped ZONE_DEVICE
> pages. Therefore page walkers that want to exclude DAX pages can check
> pmd_devmap or pud_devmap. However soon dax will no longer set PFN_DEV,
> meaning dax pages a
On Thu, May 29, 2025 at 04:32:02PM +1000, Alistair Popple wrote:
> The PFN_MAP flag is no longer used for anything, so remove it. The
> PFN_SG_CHAIN and PFN_SG_LAST flags never appear to have been used so
> also remove them.
>
> Signed-off-by: Alistair Popple
> Reviewed-by: Christoph Hellwig
> -
On Fri, May 30, 2025 at 12:23:50AM GMT, Michal Wilczynski wrote:
> Update the Imagination PVR DRM driver to leverage the pwrseq framework
> for managing the power sequence of the GPU on the T-HEAD TH1520 SoC.
>
> In pvr_device_init(), the driver now attempts to get a handle to the
> "gpu-power" se
On Tue, 2025-06-03 at 13:27 +0100, Tvrtko Ursulin wrote:
>
> On 03/06/2025 10:31, Philipp Stanner wrote:
> > An alternative version to [1], based on Tvrtko's suggestion from
> > [2].
> >
> > I tested this for Nouveau. Works.
> >
> > I'm having, however, bigger problems properly porting the unit
On 03/06/2025 10:31, Philipp Stanner wrote:
Since its inception, the GPU scheduler can leak memory if the driver
calls drm_sched_fini() while there are still jobs in flight.
The simplest way to solve this in a backwards compatible manner is by
adding a new callback, drm_sched_backend_ops.cance
On Fri, May 30, 2025 at 12:23:53AM GMT, Michal Wilczynski wrote:
> Add the device tree node for the T-HEAD TH1520 GPU power sequencer
> (gpu_pwrseq) to the th1520.dtsi file.
>
> This node instantiates the thead,th1520-gpu-pwrseq driver, which
Explain the hardware, not what drivers do.
> is respo
1 - 100 of 205 matches
Mail list logo
