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
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
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
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
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
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
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
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
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
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
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
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
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
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
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()")
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 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
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
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
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
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
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
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
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
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
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
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
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
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
"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 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_
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
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
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
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
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
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 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
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 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
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 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) \
> > > +({
This seems necessary on Freescale i.MX95 Mali G310 to reliably resume
from runtime PM suspend. Without this, if only the L2 is powered down
on RPM entry, the GPU gets stuck and does not indicate the firmware is
booted after RPM resume.
Signed-off-by: Marek Vasut
---
Cc: Boris Brezillon
Cc: Conor
The instance of the GPU populated in i.MX95 is the G310.
Add support for the GPUMIX reset via simple-reset driver,
add reset and multiple power domains support into panthor
GPU driver, add iMX95 GPU support into panthor driver and
describe the iMX95 GPU in imx95.dtsi DT.
Marek Vasut (9):
dt-bind
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. Implement support for one optional reset.
Signed-off-by: Marek Vasut
---
Cc: Boris Brezillon
Cc: Conor Dooley
Cc: David Airlie
Cc: Fab
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: Krzysztof Kozlowski
Cc: Liviu Dudau
Cc: Maarten Lankhorst
Cc: Maxime Ripard
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
Sent: Thursday, February 27, 2025 12:25 AM
To: Cavitt, Jonathan
Cc: intel...@
The instance of the GPU populated in i.MX95 is the G310,
describe this GPU in the DT. Include description of the
GPUMIX block controller, which can be operated as a simple
reset. Include dummy GPU voltage regulator and OPP tables.
Signed-off-by: Marek Vasut
---
Cc: Boris Brezillon
Cc: Conor Dool
The driver code power domain binding to driver instances only works
for single power domain, in case there are multiple power domains,
it is necessary to explicitly attach via dev_pm_domain_attach*().
As DT bindings list support for up to 5 power domains, add support
for attaching them all. This is
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
Cc: Liviu Dudau
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc:
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
---
Cc: Boris Brezillon
Cc: Conor Dooley
Cc: David Airlie
Cc: Fab
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
---
Cc: Boris Brezillon
Cc: Conor Dooley
Cc: David Airlie
Cc: Fabi
This macro behaves like #[no_mangle], but also performs an assertion
that the Rust function has the same signature as what is declared in the
C header.
If the signatures don't match, you will get errors that look like this:
error[E0308]: `if` and `else` have incompatible types
--> /rust/kernel/
: a64dcfb451e254085a7daee5fe51bf22959d52d3
change-id: 20250227-export-macro-9aa9f1016d8c
Best regards,
--
Alice Ryhl
Without this change, the rest of this series will emit the following
error message:
error[E0308]: `if` and `else` have incompatible types
--> /rust/kernel/print.rs:22:22
|
21 | #[export]
| - expected because of this
22 | unsafe extern "C" fn rust_fmt_argument(
|
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 unsafe, then this error is emitted:
error[E0308]: `if` and `else` ha
On Mon, 2025-02-24 at 20:42 -0800, Matthew Brost wrote:
> uAPI is designed with the use case that only mapping a BO to a
> malloc'd
> address will unbind a CPU-address mirror VMA. Therefore, allowing a
> CPU-address mirror VMA to unbind when the GPU has bindings in the
> range
> being unbound does
On 2/27/25 6:17 PM, Boris Brezillon wrote:
[...]
diff --git a/drivers/gpu/drm/panthor/panthor_gpu.c
b/drivers/gpu/drm/panthor/panthor_gpu.c
index 671049020afaa..0f07ef7d9aea7 100644
--- a/drivers/gpu/drm/panthor/panthor_gpu.c
+++ b/drivers/gpu/drm/panthor/panthor_gpu.c
@@ -470,11 +470,12 @@ in
> On 27 Feb 2025, at 10:24 PM, kernel test robot wrote:
>
> 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
On Thu, Feb 27, 2025 at 05:58:01PM +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, Feb 27, 2025 at 05:58:07PM +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
Reviewed-by: Frank Li
> ---
> Cc: Boris Brezillon
> Cc: Conor Dooley
> Cc: David Airlie
>
On Thu, 27 Feb 2025 17:58:06 +0100
Marek Vasut wrote:
> This seems necessary on Freescale i.MX95 Mali G310 to reliably resume
> from runtime PM suspend. Without this, if only the L2 is powered down
> on RPM entry, the GPU gets stuck and does not indicate the firmware is
> booted after RPM resume.
On Thu, Feb 27, 2025 at 05:58:02PM +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. Implement support for this reset register.
Reviewed-by: Frank Li
>
>
On Thu, Feb 27, 2025 at 07:38:58AM +0100, Jiri Slaby wrote:
> On 26. 02. 25, 19:33, Yury Norov wrote:
> > > Not in cases where macros are inevitable. I mean, do we need parityXX()
> > > for
> > > XX in (8, 16, 32, 64) at all? Isn't the parity() above enough for
> > > everybody?
> >
> > The exist
On Thu, Feb 27, 2025 at 05:58:08PM +0100, 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
Reviewed-by: Frank Li
> ---
> Cc: Boris Brezillon
> Cc: Conor Dooley
> Cc: David Airlie
> Cc:
On Thu, Feb 27, 2025 at 05:58:09PM +0100, Marek Vasut wrote:
> The instance of the GPU populated in i.MX95 is the G310,
> describe this GPU in the DT. Include description of the
> GPUMIX block controller, which can be operated as a simple
> reset. Include dummy GPU voltage regulator and OPP tables.
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. Implement support for this reset register.
Signed-off-by: Marek Vasut
---
Cc: Boris Brezillon
Cc: Conor Dooley
Cc: David Airlie
Cc: Fa
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
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
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/
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
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
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
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:
> ...
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, replacing PINGPONG_SDM845_MASK and
PINGPONG_SDM845_TE2_MASK with proper bitmasks.
Fixes: 7204df5e7e68 ("drm/msm/dpu: add suppor
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
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
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 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)
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 ++--
> > > > > > > > > > > > From: Dmitry Baryshkov
> > > > > > > > > > > >
> > > > > > > > > > > > Sent: Thursday, February 13, 2025 9:04 PM
> > > > > > > > > > > > To: Xin Ji
> > > > > > > > > > > > Cc: Andrzej Hajda ; Neil
> > > > > > > > > > > > Armstrong ; Robert Foss
> > > > > > > > > > > > ; La
* 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 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
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 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/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 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
>>>
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, 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 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 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
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
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
1 - 100 of 202 matches
Mail list logo
