> > > > > > > > > > > > From: Dmitry Baryshkov
> > > > > > > > > > > >
> > > > > > > > > > > > Sent: Thursday, February 13, 2025 9:04 PM
> > > > > > > > > > > > To: Xin Ji
> > > > > > > > > > > > Cc: Andrzej Hajda ; Neil
> > > > > > > > > > > > Armstrong ; Robert Foss
> > > > > > > > > > > > ; La
From: Honglei Huang
Add probe code path for virtio gpu userptr.
Signed-off-by: Honglei Huang
---
drivers/gpu/drm/virtio/virtgpu_debugfs.c | 1 +
drivers/gpu/drm/virtio/virtgpu_drv.c | 1 +
drivers/gpu/drm/virtio/virtgpu_drv.h | 1 +
drivers/gpu/drm/virtio/virtgpu_kms.c | 8 ++--
"Alice Ryhl" writes:
> Signed-off-by: Alice Ryhl
What is going on with the cover letter of this one?
Best regards,
Andreas Hindborg
On Thu, Feb 27, 2025 at 09:50:50AM +0530, Vignesh Raman wrote:
> Merge request pipelines were only created when changes
> were made to drivers/gpu/drm/ci/, causing MRs that
> didn't touch this path to break. Fix MR pipeline rules
> to trigger jobs for all changes.
>
> Run jobs automatically for ma
On Thu, Feb 27, 2025 at 08:36:35PM -0800, Matthew Brost wrote:
> On Fri, Feb 28, 2025 at 01:34:42PM +1100, Alistair Popple wrote:
> > On Mon, Feb 24, 2025 at 08:43:11PM -0800, Matthew Brost wrote:
> > > Add documentation for agree upon GPU SVM design principles, current
> > > status, and future pla
From: Honglei Huang
Add interval tree to manage the userptrs to prevent repeat creation.
If the userptr exists, the ioctl will return the existing BO, and it's
offset with the create ioctl address.
Signed-off-by: Honglei Huang
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 16 ++-
drivers/gpu
From: Honglei Huang
Add implement for virtio gpu userptr. Current solution is pinning
all the user space memory. The UMD needs manage all the userptrs.
Signed-off-by: Honglei Huang
---
drivers/gpu/drm/virtio/Makefile | 3 +-
drivers/gpu/drm/virtio/virtgpu_drv.h | 33
drive
From: Honglei Huang
Add mmu notifier, there are some benefits:
- UMD do not need manage the userptrs, just alloc and free user space
memory, with the MMU notifier userpters can be managed by kernel.
- Can achieve a performance improvement of 20%~30%. With the MMU notifier
UMD like OpenCL can achi
From: Honglei Huang
This makes blob userptr resource available to guest userspace.
- Flag VIRTGPU_BLOB_FLAG_USE_USERPTR for guest userspace blob create,
enable this flag to indicate blob userptr resource create.
- Flag VIRTGPU_BLOB_FLAG_USERPTR_RDONLY used for read only userptr,
if not set then
From: Honglei Huang
Introduce the basic userptr feature to userspace.
Signed-off-by: Honglei Huang
---
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
b/drivers/gpu/drm/virtio/virtgpu
From: Honglei Huang
Hello,
This series add virtio gpu userptr support and add libhsakmt capset.
The userptr feature is used for let host access guest user space memory,
this feature is used for GPU compute use case, to enable ROCm/OpenCL native
context. It should be pointed out that we are not t
From: Honglei Huang
Add a new resource for blob resource, called userptr, used for let
host access guest user space memory, to acquire buffer based userptr
feature in virtio GPU.
- The capset VIRTIO_GPU_CAPSET_HSAKMT used for context init,
in this series patches only HSAKMT context can use the u
The pull request you sent on Fri, 28 Feb 2025 13:10:16 +1000:
> https://gitlab.freedesktop.org/drm/kernel.git tags/drm-fixes-2025-02-28
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/76544811c850a1f4c055aa182b513b7a843868ea
Thank you!
--
Deet-doot-dot, I am a bot.
h
Hi,
> Am 27.02.25 um 13:52 schrieb Andi Shyti:
> > Hi Nitin,
> >
> > On Wed, Feb 26, 2025 at 09:25:34PM +0530, Nitin Gote wrote:
> >> Give the scheduler a chance to breath by calling cond_resched() as
> >> some of the loops may take some time on old machines (like
> >> apl/bsw/pnv), and so catch
The MSM8937 platform doesn't have DSC blocks nor does have it DSC
registers in the PINGPONG block. Drop the DPU_PINGPONG_DSC feature bit
from the PINGPONG's feature mask, replacing PINGPONG_SDM845_MASK and
PINGPONG_SDM845_TE2_MASK with proper bitmasks.
Fixes: 7204df5e7e68 ("drm/msm/dpu: add suppor
During one of the chats Abhinav pointed out that in the 1.x generation
most of the DPU/MDP5 instances didn't have DSC support. Also SDM630
didn't provide DSC support. Disable DSC on those platforms.
Signed-off-by: Dmitry Baryshkov
---
Dmitry Baryshkov (4):
drm/msm/dpu: remove DSC feature bi
The MSM8937 platform doesn't have DSC blocks nor does have it DSC
registers in the PINGPONG block. Drop the DPU_PINGPONG_DSC feature bit
from the PINGPONG's feature mask and, as it is the only remaining bit,
drop the .features assignment completely.
Fixes: c079680bb0fa ("drm/msm/dpu: Add support f
On Wed, Feb 26, 2025 at 08:31:02PM +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 share a set of
> mixer configurations and enable m
On Wed, Feb 26, 2025 at 08:31:01PM +0800, Jun Nie wrote:
> Currently, only 2 pipes are used at most for a plane. A stage structure
> describes the configuration for a mixer pair. So only one stage is needed
> for current usage cases. The quad-pipe case will be added in future and 2
> stages are use
On Fri, Feb 28, 2025 at 01:34:42PM +1100, Alistair Popple wrote:
> On Mon, Feb 24, 2025 at 08:43:11PM -0800, Matthew Brost wrote:
> > Add documentation for agree upon GPU SVM design principles, current
> > status, and future plans.
>
> Thanks for writing this up. In general I didn't see anything t
If several interfaces are being handled through a single CTL, a main
('master') INTF needs to be programmed into a separate register. Write
corresponding value into that register.
Co-developed-by: Marijn Suijten
Signed-off-by: Marijn Suijten
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/
Since version 5.0 the DPU got an improved way of handling multi-output
configurations. It is now possible to program all pending changes
through a single CTL and flush everything at the same time.
Implement corresponding changes in the DPU driver.
Signed-off-by: Dmitry Baryshkov
---
Changes in v
Since DPU 5.0 CTL blocks do not require DPU_CTL_SPLIT_DISPLAY, as single
CTL is used for both interfaces. As both RM and encoder now handle
active CTLs, drop that feature bit.
Reviewed-by: Marijn Suijten
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_10_0_sm8650.h
Now as we have dropped the DPU_CTL_SPLIT_DISPLAY from DPU >= 5.0
configuration, drop the rm->has_legacy_ctl condition which short-cutted
the check for those platforms.
Suggested-by: Marijn Suijten
Signed-off-by: Dmitry Baryshkov
---
Note, it is imposible to reoder commits in any other sensible
In case of ACTIVE CTLs, a single CTL is being used for flushing all INTF
blocks. Don't skip programming the CTL on those targets.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers
In case of complex pipelines (e.g. the forthcoming quad-pipe) the DPU
might use more that one MERGE_3D block for a single output. Follow the
pattern and extend the CTL_MERGE_3D_ACTIVE active register instead of
simply writing new value there. Currently at most one MERGE_3D block is
being used, so
Unlike previous generation, since DPU 5.0 it is possible to use just one
CTL to handle all INTF and WB blocks for a single output. And one has to
use single CTL to support bonded DSI config. Allocate single CTL for
these DPU versions.
Reviewed-by: Marijn Suijten
Signed-off-by: Dmitry Baryshkov
-
On DPU >= 5.0 CTL blocks were reworked in order to support using a
single CTL for all outputs. In preparation of reworking the RM code to
return single CTL make sure that dpu_encoder can cope with that.
Reviewed-by: Marijn Suijten
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu
Active controls require setup of the master interface. Pass the selected
interface to CTL configuration.
Reviewed-by: Marijn Suijten
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 2 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 2 ++
2 fi
On Fri, Feb 21, 2025 at 12:37:40AM +0100, Marijn Suijten wrote:
> On 2025-02-20 12:26:24, Dmitry Baryshkov wrote:
> > Since DPU 5.0 CTL blocks do not require DPU_CTL_SPLIT_DISPLAY, as single
> > CTL is used for both interfaces. As both RM and encoder now handle
> > active CTLs, drop that feature bi
On Fri, 28 Feb 2025 at 09:07, John Hubbard wrote:
>
> On Thu Feb 27, 2025 at 1:42 PM PST, Dave Airlie wrote:
> > On Thu, 27 Feb 2025 at 11:34, John Hubbard wrote:
> >> On Wed Feb 26, 2025 at 5:02 PM PST, Greg KH wrote:
> >> > On Wed, Feb 26, 2025 at 07:47:30PM -0400, Jason Gunthorpe wrote:
> ...
Hi Dmitry,
On 27/02/25 11:21, Dmitry Baryshkov wrote:
On Thu, Feb 27, 2025 at 10:06:24AM +0530, Vignesh Raman wrote:
If we are not caching the git archive, do not
set CI_PRE_CLONE_SCRIPT. Setting it makes CI
try to download the cache first, and if it is
missing, it tries to clone the repo withi
Hi Jonathan,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-xe/drm-xe-next]
[also build test WARNING on next-20250227]
[cannot apply to linus/master v6.14-rc4]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting
On Thu, Feb 27, 2025 at 09:51:15AM -0700, Cavitt, Jonathan wrote:
> Some responses below. If I skip over anything, just assume that I'm taking
> the request
> into consideration and that it will be fixed for version 2 of this patch
> series.
>
> -Original Message-
> From: Brost, Matthew
On 2025/2/28 00:03, Lucas De Marchi wrote:
On Thu, Feb 27, 2025 at 03:32:06PM +0800, Su Hui wrote:
When build randconfig, there is an error:
ld: drivers/gpu/drm/xe/xe_vsec.o: in function `xe_vsec_init':
xe_vsec.c:(.text+0x182): undefined reference to `intel_vsec_register'
When CONFIG_DRM_XE=y a
Hi all,
Today's linux-next merge of the drm-xe tree got a conflict in:
drivers/gpu/drm/xe/display/xe_display.c
between commit:
1b242ceec536 ("drm/i915/audio: convert to struct intel_display")
from the drm tree and commit:
d41d048043c4 ("drm/xe/display: Drop xe_display_driver_remove()")
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 10 to speed up cloning and avoid
build failures due to timeouts when fetching the full repository.
Signed-off-by: Vignesh Raman
Hi Linus,
This week's fixes pull, amdgpu mostly, with some xe and a few misc
others, the fb defio fix is bit of a change, but it avoids some nasty
NULL pointer crashes due to defio assuming page backing in places it
didn't have pages.
Regards,
Dave.
drm-fixes-2025-02-28:
drm fixes for 6.14-rc5
Commit 434e5ca5b5d7 ("drm/panthor: Expose size of driver internal BO's over
fdinfo") locks the VMS xarray, to avoid UAF errors when the same VM is
being concurrently destroyed by another thread. However, that puts the
current thread in atomic context, which means taking the VMS' heap locks
will tri
The memory allocated by msm_fence_alloc() actually is the
container of msm_fence_alloc()'s return value. Thus, just
free its return value is not enough.
Add a helper 'msm_fence_free()' in msm_fence.h/msm_fence.c
to do the complete job.
Fixes: f94e6a51e17c ("drm/msm: Pre-allocate hw_fence")
Cc: sta
The MSM8937 platform doesn't have DSC blocks nor does have it DSC
registers in the PINGPONG block. Drop the DPU_PINGPONG_DSC feature bit
from the PINGPONG's feature mask and, as it is the only remaining bit,
drop the .features assignment completely.
Fixes: 62af6e1cb596 ("drm/msm/dpu: Add support f
The MSM8937 platform doesn't have DSC blocks nor does have it DSC
registers in the PINGPONG block. Drop the DPU_PINGPONG_DSC feature bit
from the PINGPONG's feature mask and, as it is the only remaining bit,
drop the .features assignment completely.
Fixes: 7a6109ce1c2c ("drm/msm/dpu: Add support f
On Mon, Feb 24, 2025 at 08:43:11PM -0800, Matthew Brost wrote:
> Add documentation for agree upon GPU SVM design principles, current
> status, and future plans.
Thanks for writing this up. In general I didn't see anything too controversial
but added a couple of comments below.
>
> v4:
> - Addre
On Fri, 28 Feb 2025 at 11:49, Timur Tabi wrote:
>
> On Fri, 2025-02-28 at 07:37 +1000, Dave Airlie wrote:
> > I've tried to retrofit checking 0x to drivers a lot, I'd
> > prefer not to. Drivers getting stuck in wait for clear bits for ever.
>
> That's what read_poll_timeout() is for. I'm
On February 27, 2025 1:57:41 PM PST, David Laight
wrote:
>On Thu, 27 Feb 2025 13:05:29 -0500
>Yury Norov wrote:
>
>> On Wed, Feb 26, 2025 at 10:29:11PM +, David Laight wrote:
>> > On Mon, 24 Feb 2025 14:27:03 -0500
>> > Yury Norov wrote:
>> >
>> > > +#define parity(val)
On Fri, 2025-02-28 at 07:37 +1000, Dave Airlie wrote:
> I've tried to retrofit checking 0x to drivers a lot, I'd
> prefer not to. Drivers getting stuck in wait for clear bits for ever.
That's what read_poll_timeout() is for. I'm surprised Nouveau doesn't use it.
> Applied to drm-misc-next, thanks!
Awesome. :)
Thank you, guys.
--
Gustavo
On 2/25/25 03:13, Louis Chauvet wrote:
Le 20/12/2024 à 05:33, Alex Hung a écrit :
From: Harry Wentland
Add a new drm_colorop with DRM_COLOROP_1D_CURVE with two subtypes:
DRM_COLOROP_1D_CURVE_SRGB_EOTF and DRM_COLOROP_1D_CURVE_SRGB_INV_EOTF.
Signed-off-by: Harry Wentland
Co-developed-by:
Hi Aditya,
kernel test robot noticed the following build warnings:
[auto build test WARNING on linus/master]
[also build test WARNING on v6.14-rc4 next-20250227]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--bas
On Fri, Feb 28, 2025 at 01:37:51AM +0530, Akhil P Oommen wrote:
> From: Jie Zhang
>
> Add support for Adreno 623 GPU found in QCS8300 chipsets.
>
> Signed-off-by: Jie Zhang
> Signed-off-by: Akhil P Oommen
> ---
> drivers/gpu/drm/msm/adreno/a6xx_catalog.c | 29
>
Commit 0590c94c3596 ("drm/panthor: Fix race condition when gathering fdinfo
group samples") introduced an xarray lock to deal with potential
use-after-free errors when accessing groups fdinfo figures. However, this
toggles the kernel's atomic context status, so the next nested mutex lock
will raise
Hi Aditya,
kernel test robot noticed the following build warnings:
[auto build test WARNING on linus/master]
[also build test WARNING on v6.14-rc4 next-20250227]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--bas
On Thu Feb 27, 2025 at 1:42 PM PST, Dave Airlie wrote:
> On Thu, 27 Feb 2025 at 11:34, John Hubbard wrote:
>> On Wed Feb 26, 2025 at 5:02 PM PST, Greg KH wrote:
>> > On Wed, Feb 26, 2025 at 07:47:30PM -0400, Jason Gunthorpe wrote:
...
> nova is just a drm driver, it's not a rewrite of the drm subs
On Thu, Feb 27, 2025 at 8:31 PM Greg Kroah-Hartman
wrote:
>
> On Thu, Feb 27, 2025 at 05:01:58PM +, Alice Ryhl wrote:
> > Signed-off-by: Alice Ryhl
>
> It's a bit odd to sign off on a 0/X email with no patch or description
> :)
What b4 does, I do. ;)
> Seriously, nice work! This resolves t
On Thu, Feb 27, 2025 at 10:29 PM Boqun Feng wrote:
>
> On Thu, Feb 27, 2025 at 05:02:02PM +, Alice Ryhl wrote:
> > This validates at compile time that the signatures match what is in the
> > header file. It highlights one annoyance with the compile-time check,
> > which is that it can only be
Migrate the pagefault struct from xe_gt_pagefault.c to the
xe_gt_pagefault.h header file, along with the associated enum values.
v2: Normalize names for common header (Matt Brost)
Signed-off-by: Jonathan Cavitt
---
drivers/gpu/drm/xe/xe_gt_pagefault.c | 43 ++--
drivers/
On Fri, 21 Feb 2025 at 02:00, Andre Przywara wrote:
>
> The Allwinner Power Reset Clock Management (RPCM) block contains a few
> bits that control some power domains. The most prominent one is the one
> for the Mali GPU. On the Allwinner H6 this domain is enabled at reset, so
> we didn't care abou
On Thu, Feb 27, 2025 at 03:23:21PM -0400, Jason Gunthorpe wrote:
> On Thu, Feb 27, 2025 at 06:32:15PM +0100, Danilo Krummrich wrote:
> > On Thu, Feb 27, 2025 at 08:55:09AM -0800, Boqun Feng wrote:
> > > On Thu, Feb 27, 2025 at 12:17:33PM -0400, Jason Gunthorpe wrote:
> > >
> > > > I still wonder w
On Thu, Feb 27, 2025 at 06:00:13PM -0400, Jason Gunthorpe wrote:
> On Thu, Feb 27, 2025 at 01:25:10PM -0800, Boqun Feng wrote:
> >
> > Most of the cases, it should be naturally achieved, because you already
> > bind the objects into your module or driver, otherwise they would be
> > already cancel
On Thu, Feb 27, 2025 at 10:34:20PM +0100, Marek Vasut wrote:
> On 2/27/25 10:27 PM, Frank Li wrote:
>
> [...]
>
> > > > > + gpu: gpu@4d90 {
> > > > > + compatible = "fsl,imx95-mali",
> > > > > "arm,mali-valhall-csf";
> > > > > + reg = <0 0x4d
On Thu, Feb 27, 2025 at 01:25:10PM -0800, Boqun Feng wrote:
> > The design pattern says that 'share it with the rest of the world' is
> > a bug. A driver following the pattern cannot do that, it must contain
> > the driver objects within the driver scope and free them. In C we
>
> I cannot speak f
On Thu, 27 Feb 2025 13:05:29 -0500
Yury Norov wrote:
> On Wed, Feb 26, 2025 at 10:29:11PM +, David Laight wrote:
> > On Mon, 24 Feb 2025 14:27:03 -0500
> > Yury Norov wrote:
> >
> > > +#define parity(val) \
> > > +({
On 27.02.2025 10:06 PM, Akhil P Oommen wrote:
> On 2/28/2025 1:59 AM, Konrad Dybcio wrote:
>> On 27.02.2025 9:07 PM, Akhil P Oommen wrote:
>>> From: Jie Zhang
>>>
>>> Add support for Adreno 623 GPU found in QCS8300 chipsets.
>>>
>>> Signed-off-by: Jie Zhang
>>> Signed-off-by: Akhil P Oommen
>>>
On 2/27/25 10:27 PM, Frank Li wrote:
[...]
+ gpu: gpu@4d90 {
+ compatible = "fsl,imx95-mali", "arm,mali-valhall-csf";
+ reg = <0 0x4d90 0 0x48>;
+ clocks = <&scmi_clk IMX95_CLK_GPU>;
+
On Thu, Feb 27, 2025 at 09:36:55PM +0100, Marek Vasut wrote:
> On 2/27/25 6:43 PM, Frank Li wrote:
> [...]
>
> > > diff --git a/arch/arm64/boot/dts/freescale/imx95.dtsi
> > > b/arch/arm64/boot/dts/freescale/imx95.dtsi
> > > index 3af13173de4bd..36bad211e5558 100644
> > > --- a/arch/arm64/boot/dts/
On Wed, 26 Feb 2025 at 00:11, Alexandre Courbot wrote:
>
> On Mon Feb 24, 2025 at 9:07 PM JST, Danilo Krummrich wrote:
> > CC: Gary
> >
> > On Mon, Feb 24, 2025 at 10:40:00AM +0900, Alexandre Courbot wrote:
> >> This inability to sleep while we are accessing registers seems very
> >> constraining
* li...@treblig.org (li...@treblig.org) wrote:
> From: "Dr. David Alan Gilbert"
>
> hgsmi_cursor_position() has been unused since 2018's
> commit 35f3288c453e ("staging: vboxvideo: Atomic phase 1: convert cursor to
> universal plane")
>
> Remove it.
>
> Signed-off-by: Dr. David Alan Gilbert
H
On Thu, Feb 27, 2025 at 05:02:02PM +, Alice Ryhl wrote:
> This validates at compile time that the signatures match what is in the
> header file. It highlights one annoyance with the compile-time check,
> which is that it can only be used with functions marked unsafe.
>
> If the function is not
On 2/28/2025 1:59 AM, Konrad Dybcio wrote:
> On 27.02.2025 9:07 PM, Akhil P Oommen wrote:
>> From: Jie Zhang
>>
>> Add support for Adreno 623 GPU found in QCS8300 chipsets.
>>
>> Signed-off-by: Jie Zhang
>> Signed-off-by: Akhil P Oommen
>> ---
>> drivers/gpu/drm/msm/adreno/a6xx_catalog.c | 29
From: Ville Syrjälä
Add the bit definitions needed for POST_LT_ADJ sequence.
v2: DP_POST_LT_ADJ_REQ_IN_PROGRESS is bit 1 not 5 (Jani)
Signed-off-by: Ville Syrjälä
---
include/drm/display/drm_dp.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/drm/display/drm_dp.h b/include/drm
On 2/27/25 7:38 PM, Rob Herring (Arm) wrote:
On Thu, 27 Feb 2025 17:58:07 +0100, Marek Vasut wrote:
The instance of the GPU populated in Freescale i.MX95 is the
Mali G310, document support for this variant.
Signed-off-by: Marek Vasut
---
Cc: Boris Brezillon
Cc: Conor Dooley
Cc: David Airlie
On 2/27/25 6:43 PM, Frank Li wrote:
[...]
diff --git a/arch/arm64/boot/dts/freescale/imx95.dtsi
b/arch/arm64/boot/dts/freescale/imx95.dtsi
index 3af13173de4bd..36bad211e5558 100644
--- a/arch/arm64/boot/dts/freescale/imx95.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx95.dtsi
@@ -249,6 +249,37 @@
On 2/27/25 9:17 PM, Marco Felsch wrote:
[...]
diff --git a/drivers/gpu/drm/panthor/panthor_drv.c
b/drivers/gpu/drm/panthor/panthor_drv.c
index 06fe46e320738..2504a456d45c4 100644
--- a/drivers/gpu/drm/panthor/panthor_drv.c
+++ b/drivers/gpu/drm/panthor/panthor_drv.c
@@ -1591,6 +1591,7 @@ stati
On 27.02.2025 9:07 PM, Akhil P Oommen wrote:
> From: Jie Zhang
>
> Add support for Adreno 623 GPU found in QCS8300 chipsets.
>
> Signed-off-by: Jie Zhang
> Signed-off-by: Akhil P Oommen
> ---
> drivers/gpu/drm/msm/adreno/a6xx_catalog.c | 29
> +
> drivers/gpu/dr
Hi Marek,
On 25-02-27, Marek Vasut wrote:
> The instance of the GPU populated in Freescale i.MX95 is the
> Mali G310, add support for this variant.
>
> Signed-off-by: Marek Vasut
> ---
> Cc: Boris Brezillon
> Cc: Conor Dooley
> Cc: David Airlie
> Cc: Fabio Estevam
> Cc: Krzysztof Kozlowski
From: Jie Zhang
Enable GPU for qcs8300-ride platform and provide path for zap
shader.
Signed-off-by: Jie Zhang
Signed-off-by: Akhil P Oommen
Reviewed-by: Dmitry Baryshkov
---
arch/arm64/boot/dts/qcom/qcs8300-ride.dts | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot
From: Jie Zhang
Document Adreno 623 GMU in the dt-binding specification.
Signed-off-by: Jie Zhang
Signed-off-by: Akhil P Oommen
Reviewed-by: Krzysztof Kozlowski
---
Documentation/devicetree/bindings/display/msm/gmu.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/device
From: Jie Zhang
Add gpu and gmu nodes for qcs8300 chipset.
Signed-off-by: Jie Zhang
Signed-off-by: Akhil P Oommen
---
arch/arm64/boot/dts/qcom/qcs8300.dtsi | 93 +++
1 file changed, 93 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/qcs8300.dtsi
b/arch/ar
From: Jie Zhang
Add support for Adreno 623 GPU found in QCS8300 chipsets.
Signed-off-by: Jie Zhang
Signed-off-by: Akhil P Oommen
---
drivers/gpu/drm/msm/adreno/a6xx_catalog.c | 29 +
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 8
drivers/gpu/drm/msm/a
This series adds support for A623 GPU found in QCS8300 chipsets. This
GPU IP is very similar to A621 GPU, except for the UBWC configuration
and the GMU firmware.
Both DT patches are for Bjorn and rest of the patches for Rob Clark to
pick up.
---
Changes in v2:
- Fix hwcg config (Konrad)
- Split g
From: Jie Zhang
Adreno 621 has a different memory map for GPUCC block. So update
a6xx_gpu_state code to dump the correct set of gpucc registers.
Signed-off-by: Jie Zhang
Signed-off-by: Akhil P Oommen
---
drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c | 9 +++--
drivers/gpu/drm/msm/adreno/a6
From: Jie Zhang
Some GPUs have different memory map for GPUCC block. So split out the
gpucc range from a6xx_gmu_cx_registers to a separate block to
accommodate those GPUs.
Signed-off-by: Jie Zhang
Signed-off-by: Akhil P Oommen
---
drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c | 8 +---
driv
Add the exec queue id to the exec queue struct. This is useful for
performing a reverse lookup into the xef->exec_queue xarray.
Signed-off-by: Jonathan Cavitt
---
drivers/gpu/drm/xe/xe_exec_queue.c | 1 +
drivers/gpu/drm/xe/xe_exec_queue_types.h | 2 ++
2 files changed, 3 insertions(+)
d
Add a new field to the xe_pagefault struct, address_type, that tracks
the type of fault the pagefault incurred.
Signed-off-by: Jonathan Cavitt
---
drivers/gpu/drm/xe/xe_gt_pagefault.c | 3 +++
drivers/gpu/drm/xe/xe_gt_pagefault.h | 1 +
2 files changed, 4 insertions(+)
diff --git a/drivers/gpu/
On Thu, Feb 27, 2025 at 05:01:58PM +, Alice Ryhl wrote:
> Signed-off-by: Alice Ryhl
It's a bit odd to sign off on a 0/X email with no patch or description
:)
Seriously, nice work! This resolves the issues I had, and it looks like
you found a needed fix already where things were not quite de
On Thu, Feb 27, 2025 at 06:32:15PM +0100, Danilo Krummrich wrote:
> On Thu, Feb 27, 2025 at 08:55:09AM -0800, Boqun Feng wrote:
> > On Thu, Feb 27, 2025 at 12:17:33PM -0400, Jason Gunthorpe wrote:
> >
> > > I still wonder why you couldn't also have these reliable reference
> > > counts rooted on t
Add support for userspace to get various properties from a specified VM.
The currently supported properties are:
- The number of engine resets the VM has observed
- The number of exec queue bans the VM has observed, up to the last 50
relevant ones, in total.
- The number of exec queue bans the V
Add additional information to the xe_vm so it can report the last 50
relevant exec queues that have been banned on it, as well as the
associated pagefault address and address type that caused the ban when
applicable. Since we cannot reasonably associate a pagefault to a
specific exec queue, whenev
Add a counter to xe_vm that tracks the number of times an engine reset
has been observed with respect to the VM since creation.
Signed-off-by: Jonathan Cavitt
---
drivers/gpu/drm/xe/xe_guc_submit.c | 2 ++
drivers/gpu/drm/xe/xe_vm_types.h | 3 +++
2 files changed, 5 insertions(+)
diff --git a
Add additional information to vm so it can report up to the last 50
relevant exec queues to have been banned on it, as well as the last
pagefault seen when said exec queues were banned. Since we cannot
reasonably associate a pagefault to a specific exec queue, we
currently report the last seen pag
Add initial declarations for the drm_xe_vm_get_property ioctl.
Signed-off-by: Jonathan Cavitt
---
include/uapi/drm/xe_drm.h | 67 +++
1 file changed, 67 insertions(+)
diff --git a/include/uapi/drm/xe_drm.h b/include/uapi/drm/xe_drm.h
index 76a462fae05f..78a52
The page fault handler should reject write/atomic access to read only
VMAs. Add code to handle this in handle_pagefault after the VMA lookup.
Fixes: 3d420e9fa848 ("drm/xe: Rework GPU page fault handling")
Signed-off-by: Jonathan Cavitt
Suggested-by: Matthew Brost
---
drivers/gpu/drm/xe/xe_gt_p
On Thu, Feb 27, 2025 at 08:39:21AM -0500, Tamir Duberstein wrote:
Hi Lucas, chiming in here since I also care about building on macOS.
On Mon, Feb 24, 2025 at 10:05 AM Lucas De Marchi
wrote:
Is this the approach taken for other similar issues you had? Note that
argv[0] and program_invocation_
On Thu, Feb 27, 2025 at 05:58:03PM +0100, Marek Vasut wrote:
> The instance of the GPU populated in Freescale i.MX95 does require
> release from reset by writing into a single GPUMIX block controller
> GPURESET register bit 0. Document support for one optional reset.
>
> Signed-off-by: Marek Vasut
On Thu, 27 Feb 2025 17:58:01 +0100, Marek Vasut wrote:
> The instance of the GPU populated in Freescale i.MX95 does require
> release from reset by writing into a single GPUMIX block controller
> GPURESET register bit 0. Document support for this reset register.
>
> Signed-off-by: Marek Vasut
>
On Thu, 27 Feb 2025 17:58:03 +0100, Marek Vasut wrote:
> The instance of the GPU populated in Freescale i.MX95 does require
> release from reset by writing into a single GPUMIX block controller
> GPURESET register bit 0. Document support for one optional reset.
>
> Signed-off-by: Marek Vasut
>
On Thu, 27 Feb 2025 17:58:07 +0100, Marek Vasut wrote:
> The instance of the GPU populated in Freescale i.MX95 is the
> Mali G310, document support for this variant.
>
> Signed-off-by: Marek Vasut
> ---
> Cc: Boris Brezillon
> Cc: Conor Dooley
> Cc: David Airlie
> Cc: Fabio Estevam
> Cc: Kr
On 2/12/25 10:01 AM, Gustavo A. R. Silva wrote:
-Wflex-array-member-not-at-end was introduced in GCC-14, and we are
getting ready to enable it, globally.
So, in order to avoid ending up with flexible-array members in the
middle of other structs, we use the `struct_group_tagged()` helper
to separ
On Wed, Feb 26, 2025 at 10:29:11PM +, David Laight wrote:
> On Mon, 24 Feb 2025 14:27:03 -0500
> Yury Norov wrote:
>
> > +#define parity(val)\
> > +({ \
> > + u64 __v = (val);
This moves the rust_fmt_argument function over to use the new #[export]
macro, which will verify at compile-time that the function signature
matches what is in the header file.
Signed-off-by: Alice Ryhl
---
I'm not sure which header file to put this in. Any advice?
---
include/linux/sprintf.h |
1 - 100 of 202 matches
Mail list logo
