Huan Yang and Vivek,
I am trying to use udmabuf for my test, and I cannot vmap the udmabuf
buffers now. vmap_pfn_apply() will report a warning to complain that
the pfns are invalid.
I dump the pfn numbers as below:
[ 3365.399641] pg[0] pfn 1148695
[ 3365.399642] pg[1] pfn 1145057
[ 3365.399642]
Hi Simona and Laurent,
At 2025-03-07 21:25:02, "Simona Vetter" wrote:
>On Fri, Mar 07, 2025 at 03:30:41PM +0800, Andy Yan wrote:
>>
>> Hi All,
>> At 2025-03-07 09:08:48, "Andy Yan" wrote:
>> >Hi All,
>> >
>> >At 2025-03-06 23:41:24, "Simona Vetter" wrote:
>> >>On Thu, Mar 06, 2025 at 08:10:1
Hi Daniel,
On 10/03/25 13:55, Daniel Stone wrote:
Hi Vignesh,
On Fri, 28 Feb 2025 at 15:12, Vignesh Raman wrote:
The python-artifacts job has a timeout of 10 minutes, which causes
build failures as it was unable to clone the repository within the
specified limits. Set GIT_DEPTH to 50 to speed
> Sorry for the delay
>
> On Wed, 2025-02-26 at 17:05 +0800, Qianyi Liu wrote:
>> From: qianyi liu
>>
>> The last_scheduled fence leaked when an entity was being killed and
>> adding its callback failed.
>
> s/leaked/leaks
>
> s/was being/is being
>
> s/its callback/the cleanup callback
>
> s/fail
On Tue, Mar 11, 2025 at 01:12:14PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> On Fri, 7 Mar 2025 12:29:54 +1100 Stephen Rothwell
> wrote:
> >
> > Hi all,
> >
> > Today's linux-next merge of the drm-xe tree got a conflict in:
> >
> > mm/memory.c
> >
> > between commit:
> >
> > 089b22f60
From: "Dr. David Alan Gilbert"
The pcf50633 was used as part of the OpenMoko devices but
the support for its main chip was recently removed in:
commit 61b7f8920b17 ("ARM: s3c: remove all s3c24xx support")
See https://lore.kernel.org/all/Z8z236h4B5A6Ki3D@gallifrey/
Remove it.
I've split this up
The mediatek display driver fails to probe on mt8173 and mt8183 in
v6.14-rc4, with the following errors:
mt8173:
platform 1401b000.dsi: deferred probe pending: mtk-dsi: Failed to get hs clock
platform 14025000.hdmi: deferred probe pending: (reason unknown)
i2c 1-0008: deferred probe pending: (reas
cc_cx_gmu_clk' was expected
> from schema $id: http://devicetree.org/schemas/iommu/arm,smmu.yaml#
> arch/arm64/boot/dts/qcom/qcs8300-ride.dtb: iommu@3da: clock-names:5:
> 'gpu_cc_hub_cx_int_clk' was expected
> from schema $id: http://devicetree.org/schemas/iommu/arm,smmu.yaml#
>
>
>
>
>
These warnings are for the smmu dt change which I marked as a
dependency. Hopefully, the v6 revision from Pratyush will fix this.
https://lore.kernel.org/linux-arm-kernel/20250310-b4-branch-gfx-smmu-v6-1-15c60b8ab...@quicinc.com/T/
-Akhil.
On 10/03/2025 14:15, Maíra Canal wrote:
> Hi Krzysztof,
>
> On 3/10/25 09:55, Krzysztof Kozlowski wrote:
>> On 10/03/2025 12:57, Maíra Canal wrote:
> Signed-off-by: Maíra Canal
> ---
>.../devicetree/bindings/gpu/brcm,bcm-v3d.yaml | 60
> --
>
Hi,
All the patches within this series have been reviewed.
Are there any more concerns that should be taken care of?
On 26/02/25 21:22, Aradhya Bhatia wrote:
> Hello all,
>
> This series provides some crucial fixes and improvements for the Cadence's DSI
> TX (cdns-dsi) controller found commonly
On Mon, Mar 10, 2025 at 10:04:22PM -0700, Matthew Brost wrote:
> On Mon, Mar 10, 2025 at 09:22:50PM +0300, Dan Carpenter wrote:
> > On Mon, Mar 10, 2025 at 12:56:46PM -0400, Rodrigo Vivi wrote:
> > > On Mon, Mar 10, 2025 at 01:48:00PM +0300, Dan Carpenter wrote:
> > > > The error handling assumes t
From: "Dr. David Alan Gilbert"
The pcf50633 was used as part of the OpenMoko devices but
the support for its main chip was recently removed in:
commit 61b7f8920b17 ("ARM: s3c: remove all s3c24xx support")
See https://lore.kernel.org/all/Z8z236h4B5A6Ki3D@gallifrey/
Remove it.
Signed-off-by: Dr.
On Sat, Mar 08, 2025 at 11:33:43AM -0300, Maíra Canal wrote:
> V3D 7.1 exposes a new register block, called V3D_SMS. As BCM2712 has a
Where is the comaptible for this new block? Or was it already documented
but with missing register?
> V3D 7.1 core, add a new register item to the list. Similar to
From: Cavitt, Jonathan
Sent: Monday, March 10, 2025 10:18 AM
To: intel...@lists.freedesktop.org
Cc: Gupta, saurabhg ; Zuo, Alex ;
Cavitt, Jonathan ; joonas.lahti...@linux.intel.com
; Brost, Matthew ;
Zhang, Jianxun ; Lin, Shuicheng
; dri-devel@lists.freedesk
Hi all,
On Fri, 7 Mar 2025 12:58:03 +1100 Stephen Rothwell
wrote:
>
> After merging the drm-xe tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/gpu/drm/drm_gpusvm.c: In function 'drm_gpusvm_range_get_pages':
> drivers/gpu/drm/drm_gpusvm.c:1404:44: error: 'str
On 03/10/2025, Maxime Ripard wrote:
> On Fri, Mar 07, 2025 at 11:10:00AM +0800, Liu Ying wrote:
>> On 03/06/2025, Maxime Ripard wrote:
>>> On Thu, Mar 06, 2025 at 03:02:41PM +0800, Liu Ying wrote:
On 03/06/2025, Rob Herring wrote:
> On Wed, Mar 05, 2025 at 10:35:26AM +0100, Alexander Stein
On Mon, Mar 10, 2025 at 5:54 PM André Almeida wrote:
>
> Em 01/03/2025 03:04, Raag Jadav escreveu:
> > On Fri, Feb 28, 2025 at 06:49:43PM -0300, André Almeida wrote:
> >> Hi Raag,
> >>
> >> On 2/28/25 11:58, Raag Jadav wrote:
> >>> On Fri, Feb 28, 2025 at 09:13:53AM -0300, André Almeida wrote:
> >
Follow-on from the companion dt-bindings change ("dt-bindings: gpu: img:
More explicit compatible strings"), deprecating "img,img-axe" in favour of
the more explicit combination of "img,img-rogue" and "img,img-axe-1-16m".
Since all relevant details are interrogated from the device at runtime,
we c
Hi Andrew!
> Really, an acked-by would have been much easier all around, but
> whatever.
Hard to keep track of which of these kernel-wide series go through one
tree and which ones don't. I generally err on the side of picking up
things which may conflict with driver updates in my tree.
Judging
Hi Stephen,
On Fri, 7 Mar 2025 13:21:12 +1100 Stephen Rothwell
wrote:
>
> Hi all,
>
> After merging the drm-xe tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> In file included from include/linux/kernel.h:22,
> from include/linux/cpumask.h:11,
>
Hi all,
On Fri, 7 Mar 2025 12:29:54 +1100 Stephen Rothwell
wrote:
>
> Hi all,
>
> Today's linux-next merge of the drm-xe tree got a conflict in:
>
> mm/memory.c
>
> between commit:
>
> 089b22f60a0f ("mm: allow compound zone device pages")
>
> from the mm-unstable branch of the mm tree a
On Mon, 10 Mar 2025 21:19:03 -0400 "Martin K. Petersen"
wrote:
> On Tue, 25 Feb 2025 20:17:14 +, Easwar Hariharan wrote:
>
> > This is the second series (part 1*) that converts users of
> > msecs_to_jiffies() that
> > either use the multiply pattern of either of:
> > - msecs_to_jiffies(N*1
From: "Dr. David Alan Gilbert"
The pcf50633 was used as part of the OpenMoko devices but
the support for its main chip was recently removed in:
commit 61b7f8920b17 ("ARM: s3c: remove all s3c24xx support")
See https://lore.kernel.org/all/Z8z236h4B5A6Ki3D@gallifrey/
Remove it.
Signed-off-by: Dr.
As done in panthor, define and use these GPU_MMU_FEATURES_* macros,
which makes code easier to read and reuse.
Signed-off-by: Ariel D'Alessandro
Reviewed-by: Boris Brezillon
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_mmu.c | 6 --
drivers/gpu/drm/panfrost/panfrost_reg
From: "Dr. David Alan Gilbert"
Remove the remaining parts of the 50633, the core, headers and glue.
The pcf50633 was used as part of the OpenMoko devices but
the support for its main chip was recently removed in:
commit 61b7f8920b17 ("ARM: s3c: remove all s3c24xx support")
See https://lore.kern
From: "Dr. David Alan Gilbert"
The pcf50633 was used as part of the OpenMoko devices but
the support for its main chip was recently removed in:
commit 61b7f8920b17 ("ARM: s3c: remove all s3c24xx support")
See https://lore.kernel.org/all/Z8z236h4B5A6Ki3D@gallifrey/
Remove it.
Signed-off-by: Dr.
From: "Dr. David Alan Gilbert"
As part of the pcf50633 removal, take out it's irq code
(which includes one bit still called from the core, but it'll
go soon).
Signed-off-by: Dr. David Alan Gilbert
---
drivers/mfd/Makefile| 2 +-
drivers/mfd/pcf50633-core.c | 5 +-
drivers/mfd/pcf50
From: "Dr. David Alan Gilbert"
The pcf50633 was used as part of the OpenMoko devices but
the support for its main chip was recently removed in:
commit 61b7f8920b17 ("ARM: s3c: remove all s3c24xx support")
See https://lore.kernel.org/all/Z8z236h4B5A6Ki3D@gallifrey/
Remove it.
Signed-off-by: Dr.
* Dr. David Alan Gilbert (li...@treblig.org) wrote:
> * li...@treblig.org (li...@treblig.org) wrote:
> > From: "Dr. David Alan Gilbert"
> >
> > The pcf50633 was used as part of the OpenMoko devices but
> > the support for its main chip was recently removed in:
> > commit 61b7f8920b17 ("ARM: s3c:
From: "Dr. David Alan Gilbert"
The pcf50633 was used as part of the OpenMoko devices but
the support for its main chip was recently removed in:
commit 61b7f8920b17 ("ARM: s3c: remove all s3c24xx support")
See https://lore.kernel.org/all/Z8z236h4B5A6Ki3D@gallifrey/
Remove it.
Signed-off-by: Dr.
From: "Dr. David Alan Gilbert"
The pcf50633 was used as part of the OpenMoko devices but
the support for its main chip was recently removed in:
commit 61b7f8920b17 ("ARM: s3c: remove all s3c24xx support")
See https://lore.kernel.org/all/Z8z236h4B5A6Ki3D@gallifrey/
Remove it.
Signed-off-by: Dr.
From: "Dr. David Alan Gilbert"
The pcf50633 was used as part of the OpenMoko devices but
the support for its main chip was recently removed in:
commit 61b7f8920b17 ("ARM: s3c: remove all s3c24xx support")
See https://lore.kernel.org/all/Z8z236h4B5A6Ki3D@gallifrey/
Remove it.
Signed-off-by: Dr.
On Tue, 25 Feb 2025 20:17:14 +, Easwar Hariharan wrote:
> This is the second series (part 1*) that converts users of msecs_to_jiffies()
> that
> either use the multiply pattern of either of:
> - msecs_to_jiffies(N*1000) or
> - msecs_to_jiffies(N*MSEC_PER_SEC)
>
> where N is a constant or an
On 10/03/2025 12:57, Maíra Canal wrote:
>>
>>> Signed-off-by: Maíra Canal
>>> ---
>>> .../devicetree/bindings/gpu/brcm,bcm-v3d.yaml | 60
>>> --
>>> 1 file changed, 55 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/gpu/brcm,bcm-v3d
Applied. Thanks
On Tue, Mar 4, 2025 at 4:29 AM Christian König wrote:
>
> Am 25.02.25 um 02:02 schrieb André Almeida:
> > Instead of only triggering a wedged event for complete GPU resets,
> > trigger for ring resets. Regardless of the reset, it's useful for
> > userspace to know that it happen
https://bugzilla.kernel.org/show_bug.cgi?id=219507
Joe Breuer (linux-ker...@jmbreuer.net) changed:
What|Removed |Added
CC||linux-ker...@jmbr
DisplayPort requires per-segment link training when LTTPR are switched
to non-transparent mode, starting with LTTPR closest to the source.
Only when each segment is trained individually, source can link train
to sink.
Implement per-segment link traning when LTTPR(s) are detected, to
support extern
On Tue, 2025-03-04 at 22:53 +0900, Alexandre Courbot wrote:
> +/// Useful operations for `u64`.
> +pub trait U64Ext {
> + /// Build a `u64` by combining its `high` and `low` parts.
> + ///
> + /// ```
> + /// use kernel::num::U64Ext;
> + /// assert_eq!(u64::from_u32s(0x01234567, 0x89
Take into account LTTPR capabilities when selecting maximum allowed
link rate, number of data lines. Initialize LTTPR before
msm_dp_panel_read_sink_caps, as
a) Link params computation need to take into account LTTPR's caps
b) It appears DPTX shall (re)read DPRX caps after LTTPR detection
Return lt
Hi Boris,
On 2/27/25 11:55 AM, Boris Brezillon wrote:
On Wed, 26 Feb 2025 15:30:42 -0300
Ariel D'Alessandro wrote:
@@ -642,8 +713,15 @@ struct panfrost_mmu *panfrost_mmu_ctx_create(struct
panfrost_device *pfdev)
.iommu_dev = pfdev->dev,
};
- mmu->pgtbl_ops = a
The TI k3-j721s2 platform does not allow us to use uncached memory
(which is what the driver currently does) without disabling cache snooping
on the AXI ACE-Lite interface, which would be too much of a performance
hit.
Given the platform is dma-coherent, we can simply force all
device-accessible m
Recently added Initial LTTPR support in msm/dp has configured LTTPR(s)
to non-transparent mode to enable video output on X1E-based devices
that come with LTTPR on the motherboards. However, video would not work
if additional LTTPR(s) are present between sink and source, which is
the case for USB Ty
On Mon, 10 Mar 2025 at 17:08, Maxime Ripard wrote:
>
> On Fri, Mar 07, 2025 at 07:55:53AM +0200, 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
Now that Panfrost supports AARCH64_4K page table format, let's enable it
on Mediatek MT8188.
Signed-off-by: Ariel D'Alessandro
---
drivers/gpu/drm/panfrost/panfrost_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
b/drivers/gpu/drm/panfrost/panfr
This is currently a callback function which takes no parameters; there's
no reason for this so let's make it a straightforward value in pvr_fw_defs.
Signed-off-by: Matt Coster
---
Changes in v3:
- None
- Link to v2:
https://lore.kernel.org/r/20241118-sets-bxs-4-64-patch-v1-v2-11-3fd45d9fb...@img
Add initial declarations for the drm_xe_vm_get_faults ioctl.
Signed-off-by: Jonathan Cavitt
---
include/uapi/drm/xe_drm.h | 49 +++
1 file changed, 49 insertions(+)
diff --git a/include/uapi/drm/xe_drm.h b/include/uapi/drm/xe_drm.h
index 616916985e3f..90c2fcd
On Mon, Mar 10, 2025 at 10:09:51PM +1300, Ryan Walklin wrote:
> The Allwinner H616 and variants have a new display engine revision
> (DE33).
>
> Add a display engine bus binding for the DE33 and increase reg maxItems
> to 3 to accommodate additional register blocks.
>
> Signed-off-by: Ryan Walkli
Both these functions write to MMU_AS_CONTROL register in the same way.
Define a common _panfrost_mmu_as_control_write function with the shared
code.
Signed-off-by: Ariel D'Alessandro
---
drivers/gpu/drm/panfrost/panfrost_mmu.c | 33 -
1 file changed, 16 insertions(+), 17
On Fri, Mar 07, 2025 at 10:25:18AM +0100, Josef Luštický wrote:
> Ok, I'll implement the change and post it for a review.
> About the property naming, I tend to name it something like
> "inverted-reset-gpio-fixed" to denote that it is assumed the code
> using the "reset-gpios" property was fixed.
>
Add a very simple timeout test which submits a single job and verifies
that the timeout handling will run if the backend failed to complete the
job in time.
Signed-off-by: Tvrtko Ursulin
Cc: Christian König
Cc: Danilo Krummrich
Cc: Matthew Brost
Cc: Philipp Stanner
---
.../gpu/drm/scheduler/
Reviewed-by: Lyude Paul
And yes - feel free to push this change!
On Mon, 2025-03-10 at 19:24 +0200, Imre Deak wrote:
> On Mon, Mar 10, 2025 at 01:01:25PM +, Lin, Wayne wrote:
> > [Public]
> >
> > > -Original Message-
> > > From: Imre Deak
> > > Sent: Monday, March 10, 2025 7:00 PM
Em 01/03/2025 03:04, Raag Jadav escreveu:
On Fri, Feb 28, 2025 at 06:49:43PM -0300, André Almeida wrote:
Hi Raag,
On 2/28/25 11:58, Raag Jadav wrote:
On Fri, Feb 28, 2025 at 09:13:53AM -0300, André Almeida wrote:
To notify userspace about which app (if any) made the device get in a
wedge stat
-Original Message-
From: Wajdeczko, Michal
Sent: Monday, March 10, 2025 11:20 AM
To: Cavitt, Jonathan ; intel...@lists.freedesktop.org
Cc: Gupta, saurabhg ; Zuo, Alex ;
joonas.lahti...@linux.intel.com; Brost, Matthew ;
Zhang, Jianxun ; Lin, Shuicheng
; dri-devel@lists.freedesktop.org
S
Em 01/03/2025 02:53, Raag Jadav escreveu:
On Fri, Feb 28, 2025 at 06:54:12PM -0300, André Almeida wrote:
Hi Raag,
On 2/28/25 11:20, Raag Jadav wrote:
Cc: Lucas
On Fri, Feb 28, 2025 at 09:13:52AM -0300, André Almeida wrote:
When a device get wedged, it might be caused by a guilty application.
On 2025-02-25 06:18, Louis Chauvet wrote:
> Le 20/12/2024 à 05:33, Alex Hung a écrit :
>> From: Harry Wentland
>>
(snip)
>> + { 0xfbfb, 0xfbfb, 0xfbfb, 0 },
>> + { 0xfcfc, 0xfcfc, 0xfcfc, 0 },
>> + { 0xfdfd, 0xfdfd, 0xfdfd, 0 },
>> + { 0xfefe, 0xfefe, 0xfefe, 0 },
>> + { 0x
There has repeatedly been quite a bit of apprehension when any change to the DRM
scheduler is proposed, with two main reasons being code base is considered
fragile, not well understood and not very well documented, and secondly the lack
of systematic testing outside the vendor specific tests suites
On 12-02-25, 17:35, Jyothi Kumar Seerapu wrote:
> GSI hardware generates an interrupt for each transfer completion.
> For multiple messages within a single transfer, this results in
> N interrupts for N messages, leading to significant software
> interrupt latency.
>
> To mitigate this latency, ut
On Mon, Mar 10, 2025 at 12:01:36PM +0800, Yongbang Shi wrote:
> From: Baihan Li
>
> Add HPD interrupt enable functions in drm framework, and also add
> detect_ctx functions. Because of the debouncing when HPD pulled out,
> add 200 ms delay in detect_ctx(). Add link reset process to reset link
> s
On Mon, Mar 10, 2025 at 03:46:33PM +0100, Maxime Ripard wrote:
> On Sun, Mar 09, 2025 at 10:13:56AM +0200, Dmitry Baryshkov wrote:
> > From: Dmitry Baryshkov
> >
> > HDMI standard defines recommended N and CTS values for Audio Clock
> > Regeneration. Currently each driver implements those, freque
5.15-stable review patch. If anyone has any objections, please let me know.
--
From: Thomas Zimmermann
commit 53036937a101b5faeaf98e7438555fa854a1a844 upstream.
Including m68k's in vga.h on nommu platforms results
in conflicting defines with io_no.h for various I/O macros fro
On Mon, Mar 10, 2025 at 06:41:07PM +0800, Damon Ding wrote:
> The main modification is moving the DP AUX initialization from function
> analogix_dp_bind() to analogix_dp_probe(). In order to get the EDID of
> eDP panel during probing, it is also needed to advance PM operations to
> ensure that eDP
The timeout logic provided by drm_sched leads to races when we try
to suspend it while the drm_sched workqueue queues more jobs. Let's
overhaul the timeout handling in panthor to have our own delayed work
that's resumed/suspended when a group is resumed/suspended. When an
actual timeout occurs, we
On Thu, Mar 06, 2025 at 03:47:27PM +, David Turner wrote:
> Hi all,
>
> On Thu, 6 Mar 2025 at 13:39, Maxime Ripard wrote:
> > It looks fairly generic to me. Is there any reason you didn't put it in
> > the HDMI audio helpers?
>
> I originally wrote the downstream patch last year on 6.6, befo
On Fri, Mar 7, 2025 at 11:09 PM Dmitry Baryshkov
wrote:
>
> On Fri, Mar 07, 2025 at 09:40:56PM -0600, Rob Herring (Arm) wrote:
> >
> > On Sat, 08 Mar 2025 03:42:23 +0200, Dmitry Baryshkov wrote:
> > > From: Dmitry Baryshkov
> > >
> > > Describe the Mobile Display SubSystem (MDSS) device present o
Hi Krzysztof,
On 3/10/25 09:55, Krzysztof Kozlowski wrote:
On 10/03/2025 12:57, Maíra Canal wrote:
Signed-off-by: Maíra Canal
---
.../devicetree/bindings/gpu/brcm,bcm-v3d.yaml | 60
--
1 file changed, 55 insertions(+), 5 deletions(-)
diff --git a/Documentation
After a previous commit ("drm/imagination: Mask GPU IRQs in threaded
handler"), this register is now only used to enable firmware interrupts at
start-of-day. This is, however, unnecessary since they are enabled by
default.
In addition, the soon-to-be-added RISC-V firmware processors do not have
an
Use the new compatible string introduced earlier (in "dt-bindings: gpu:
img: More explicit compatible strings") and add a name to the single power
domain for this GPU (introduced in "dt-bindings: gpu: img: Power domain
details").
Signed-off-by: Matt Coster
---
Changes in v3:
- None
- Link to v2:
The first supported GPU only used a single power domain so this was
automatically handled by the device runtime.
In order to support multiple power domains, they must be enumerated from
devicetree and linked to both the GPU device and each other to ensure
correct power sequencing at start time.
F
Since we already added a generic compatible string for all IMG Rogue GPUs
("img,img-rogue"), all that's needed here is to link the appropriate
firmware for the BXS-4-64 GPU in the AM68.
Signed-off-by: Matt Coster
---
Changes in v3:
- Remove device overrides
- Remove specific compatible string
- L
From: Sarah Walker
Newer PowerVR GPUs (such as the BXS-4-64 MC1) use a RISC-V firmware
processor instead of the previous MIPS or META.
Signed-off-by: Sarah Walker
Signed-off-by: Matt Coster
---
Changes in v3:
- Don't enable debug module
- Link to v2:
https://lore.kernel.org/r/20241118-sets-bx
From: Alessio Belle
Update the register define header to a newer version that covers more
recent GPUs, including BXS-4-64.
Signed-off-by: Alessio Belle
Signed-off-by: Matt Coster
---
Changes in v3:
- Added
---
drivers/gpu/drm/imagination/pvr_rogue_cr_defs.h | 153 +---
1 f
Now that enable_reg isn't used, rename the previously shared event_mask to
status_mask since it's only used with status_reg.
Signed-off-by: Matt Coster
---
Changes in v3:
- None
- Link to v2:
https://lore.kernel.org/r/20241118-sets-bxs-4-64-patch-v1-v2-11-3fd45d9fb...@imgtec.com
Changes in v2:
-
This allows for more versatility in checking and clearing firmware
registers used for interrupt handling.
Signed-off-by: Matt Coster
---
Changes in v3:
- None
- Link to v2:
https://lore.kernel.org/r/20241118-sets-bxs-4-64-patch-v1-v2-14-3fd45d9fb...@imgtec.com
Changes in v2:
- None
- Link to v1:
The first compatible strings added for the AXE-1-16M are not sufficient to
accurately describe all the IMG Rogue GPUs. The current "img,img-axe"
string refers to the entire family of Series AXE GPUs, but this is
primarily a marketing term and does not denote a level of hardware
similarity any great
From: Alessio Belle
Pass IRQF_ONESHOT flag to request_threaded_irq(), so that interrupts will
be masked by the kernel until the end of the threaded IRQ handler. Since
the calls to pvr_fw_irq_enable() and pvr_fw_irq_disable() are now
redundant, remove them.
Interrupts to the host from the soon-to
[Public]
> -Original Message-
> From: Imre Deak
> Sent: Monday, March 10, 2025 7:00 PM
> To: Lin, Wayne
> Cc: intel-...@lists.freedesktop.org; intel...@lists.freedesktop.org; dri-
> de...@lists.freedesktop.org; Lyude Paul ;
> sta...@vger.kernel.org
> Subject: Re: [PATCH] drm/dp_mst: Fix
On Mon, 2025-03-10 at 13:25 +0100, Christian König wrote:
> Am 10.03.25 um 13:11 schrieb Philipp Stanner:
> > On Mon, 2025-03-10 at 08:44 +0100, Christian König wrote:
> > > This reverts commit 44d2f310f008613c1dbe5e234c2cf2be90cbbfab.
> > OK, your arguments with fence ordering are strong. Please u
On 10/03/2025 12:00, Philipp Stanner wrote:
On Mon, 2025-03-10 at 11:54 +, Tvrtko Ursulin wrote:
On 10/03/2025 11:11, Philipp Stanner wrote:
On Mon, 2025-03-10 at 09:55 +, Tvrtko Ursulin wrote:
On 07/03/2025 18:06, Philipp Stanner wrote:
On Fri, 2025-03-07 at 16:59 +, Tvrtko U
On 10/03/2025 12:11, Philipp Stanner wrote:
On Mon, 2025-03-10 at 08:44 +0100, Christian König wrote:
This reverts commit 44d2f310f008613c1dbe5e234c2cf2be90cbbfab.
OK, your arguments with fence ordering are strong. Please update the
commit message according to our discussion:
Could that ar
Am 10.03.25 um 13:11 schrieb Philipp Stanner:
> On Mon, 2025-03-10 at 08:44 +0100, Christian König wrote:
>> This reverts commit 44d2f310f008613c1dbe5e234c2cf2be90cbbfab.
> OK, your arguments with fence ordering are strong. Please update the
> commit message according to our discussion:
>
>> Sorry
On 3/10/2025 4:17 PM, Dan Carpenter wrote:
These lines are indented one tab too far. Delete the extra tabs.
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.
…
> Fix this by reordering the dereference after the sanity checks.
Can another wording approach (like the following) be more appropriate?
Thus move the assignment of the variable “dpu_enc” behind …
Would an other summary phrase become nicer?
Regards,
Markus
Consumers of the DMA contiguous API will have to know which region their
device allocates from in order for them to charge the memory allocation
in the right one.
Let's provide an accessor for that region.
Signed-off-by: Maxime Ripard
---
include/linux/dma-map-ops.h | 21 +
On Mon, Mar 10, 2025 at 08:59:51AM +, Lin, Wayne wrote:
>
> > -Original Message-
> > From: Imre Deak
> > Sent: Saturday, March 8, 2025 2:32 AM
> > To: intel-...@lists.freedesktop.org; intel...@lists.freedesktop.org; dri-
> > de...@lists.freedesktop.org
> > Cc: Lin, Wayne ; Lyude Paul
On Mon, 2025-03-10 at 08:44 +0100, Christian König wrote:
> This reverts commit 44d2f310f008613c1dbe5e234c2cf2be90cbbfab.
OK, your arguments with fence ordering are strong. Please update the
commit message according to our discussion:
>
> Sorry for the delayed response, I only stumbled over this
The dmem cgroup allows to track any DMA memory allocation made by the
userspace. Let's charge our allocations in videobuf2 to enable proper
memory tracking.
Signed-off-by: Maxime Ripard
---
drivers/media/common/videobuf2/videobuf2-dma-contig.c | 19 +++
1 file changed, 19 inserti
Now that we have a DMEM region per CMA region, we can track the
allocations of the CMA heap through DMEM.
Signed-off-by: Maxime Ripard
---
drivers/dma-buf/heaps/cma_heap.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/dma-buf/heaps/cma_heap.c b/d
In order to clean thing up when dma-heaps will allocate and register
buffers in the dev cgroup, let's uncharge a released buffer for any
(optional) cgroup controller.
Signed-off-by: Maxime Ripard
---
drivers/dma-buf/dma-buf.c | 7 +++
include/linux/dma-buf.h | 5 +
2 files changed, 12
Consumers of the DMA API will have to know which DMA region their device
allocate from in order for them to charge the memory allocation in the
right one.
Let's provide an accessor for that region.
Signed-off-by: Maxime Ripard
---
include/linux/dma-mapping.h | 11 +++
kernel/dma/mapping
Some DMA allocations are not going to be performed through dedicated
sub-allocators but using the default path. We need to create a default
region to track those as well.
Signed-off-by: Maxime Ripard
---
kernel/dma/mapping.c | 23 +++
1 file changed, 23 insertions(+)
diff --
Consumers of the coherent DMA API will have to know which coherent
region their device allocate from in order for them to charge the memory
allocation in the right one.
Let's provide an accessor for that region.
Signed-off-by: Maxime Ripard
---
include/linux/dma-map-ops.h | 11 +++
kern
Now that the dmem cgroup has been merged, we need to create memory
regions for each allocator devices might allocate DMA memory from.
Since CMA is one of these allocators, we need to create such a region.
CMA can deal with multiple regions though, so we'll need to create a
dmem region per CMA regi
Consumers of the CMA API will have to know which CMA region their device
allocate from in order for them to charge the memory allocation in the
right one.
Let's provide an accessor for that region.
Signed-off-by: Maxime Ripard
---
include/linux/cma.h | 9 +
mm/cma.c| 7 +
There can be several coherent memory region in the system, and all of
them might end up being used to allocate a DMA buffer.
Let's register a dmem region for each of them to make sure we can track
those allocations.
Signed-off-by: Maxime Ripard
---
kernel/dma/coherent.c | 12
1 fil
Hi,
Here's preliminary work to enable dmem tracking for heavy users of DMA
allocations on behalf of userspace: v4l2, DRM, and dma-buf heaps.
It's not really meant for inclusion at the moment, because I really
don't like it that much, and would like to discuss solutions on how to
make it nicer.
I
On Mon, 2025-03-10 at 11:54 +, Tvrtko Ursulin wrote:
>
> On 10/03/2025 11:11, Philipp Stanner wrote:
> > On Mon, 2025-03-10 at 09:55 +, Tvrtko Ursulin wrote:
> > >
> > > On 07/03/2025 18:06, Philipp Stanner wrote:
> > > > On Fri, 2025-03-07 at 16:59 +, Tvrtko Ursulin wrote:
> > > > >
The error handling assumes that vm_bind_ioctl_check_args() will
initialize "bind_ops" but there are a couple early returns where that's
not true. Initialize "bind_ops" to NULL from the start.
Fixes: b43e864af0d4 ("drm/xe/uapi: Add DRM_XE_VM_BIND_FLAG_CPU_ADDR_MIRROR")
Signed-off-by: Dan Carpenter
These lines are indented one tab more than they should be. Delete
the stray tabs.
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/amd/amdkfd/kfd_debug.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_debug.c
b/drivers/gpu/drm/am
This line has a seven space indent instead of a tab.
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.c
index 39669f8788
These lines are indented one tab too far. Delete the extra tabs.
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
in
1 - 100 of 148 matches
Mail list logo
