Anyone with access to contiguous physical memory should be able to
share memory with QTEE using shm_bridge.
Tested-by: Neil Armstrong
Signed-off-by: Amirreza Zarrabi
---
drivers/firmware/qcom/qcom_tzmem.c | 57 +---
include/linux/firmware/qcom/qcom_tzmem.h | 15
Enable userspace to allocate shared memory with QTEE. Since
QTEE handles shared memory as object, a wrapper is implemented
to represent tee_shm as an object. The shared memory identifier,
obtained through TEE_IOC_SHM_ALLOC, is transferred to the driver using
TEE_IOCTL_PARAM_ATTR_TYPE_OBJREF_INPUT/O
After booting, the kernel provides a static object known as the
primordial object. This object is utilized by QTEE for native
kernel services such as yield or privileged operations.
Acked-by: Sumit Garg
Tested-by: Neil Armstrong
Signed-off-by: Amirreza Zarrabi
---
drivers/tee/qcomtee/Makefile
Introduce qcomtee_object, which represents an object in both QTEE and
the kernel. QTEE clients can invoke an instance of qcomtee_object to
access QTEE services. If this invocation produces a new object in QTEE,
an instance of qcomtee_object will be returned.
Similarly, QTEE can request services fr
Add documentation for the Qualcomm TEE driver.
Signed-off-by: Amirreza Zarrabi
---
Documentation/tee/index.rst | 1 +
Documentation/tee/qtee.rst | 150
MAINTAINERS | 1 +
3 files changed, 152 insertions(+)
diff --git a/Documentat
For drivers that can transfer data to the TEE without using shared
memory from client, it is necessary to receive the user address
directly, bypassing any processing by the TEE subsystem. Introduce
TEE_IOCTL_PARAM_ATTR_TYPE_UBUF_INPUT/OUTPUT/INOUT to represent
userspace buffers.
Reviewed-by: Sumit
A TEE driver doesn't always need to provide a pool if it doesn't
support memory sharing ioctls and can allocate memory for TEE
messages in another way. Although this is mentioned in the
documentation for tee_device_alloc(), it is not handled correctly.
Reviewed-by: Sumit Garg
Signed-off-by: Amirr
Qualcomm TEE (QTEE) hosts Trusted Applications (TAs) and services in
the secure world, accessed via objects. A QTEE client can invoke these
objects to request services. Similarly, QTEE can request services from
the nonsecure world using objects exported to the secure world.
Add low-level primitive
This patch series introduces a Trusted Execution Environment (TEE)
driver for Qualcomm TEE (QTEE). QTEE enables Trusted Applications (TAs)
and services to run securely. It uses an object-based interface, where
each service is an object with sets of operations. Clients can invoke
these operations on
The TEE subsystem allows session-based access to trusted services,
requiring a session to be established to receive a service. This
is not suitable for an environment that represents services as objects.
An object supports various operations that a client can invoke,
potentially generating a result
The tee_context can be used to manage TEE user resources, including
those allocated by the driver for the TEE on behalf of the user.
The release() callback is invoked only when all resources, such as
tee_shm, are released and there are no references to the tee_context.
When a user closes the devic
shm_bridge create/delete functions always use the scm device.
There is no need to pass it as an argument.
Tested-by: Neil Armstrong
Signed-off-by: Amirreza Zarrabi
---
drivers/firmware/qcom/qcom_scm.c | 4 ++--
drivers/firmware/qcom/qcom_tzmem.c | 8
include/linux/firmware/qc
Increase TEE_MAX_ARG_SIZE to accommodate worst-case scenarios where
additional buffer space is required to pass all arguments to TEE.
This change is necessary for upcoming support for Qualcomm TEE, which
requires a larger buffer for argument marshaling.
Signed-off-by: Amirreza Zarrabi
---
includ
> Subject: Re: [PATCH v10 08/10] drm/xe/nvm: add on-die non-volatile
> memory device
>
> On Thu, May 15, 2025 at 04:33:43PM +0300, Alexander Usyskin wrote:
> > Enable access to internal non-volatile memory on DGFX
> > with GSC/CSC devices via a child device.
> > The nvm child device is exposed via
Hi Aradhya,
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/ti/ti,am625-oldi.yaml
> @@ -0,0 +1,80 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/ti/ti,am625-oldi.yaml#
> +$schema: http://devicetree
> Subject: Re: [PATCH v10 05/10] mtd: intel-dg: align 64bit read and write
>
> On Thu, May 15, 2025 at 04:33:40PM +0300, Alexander Usyskin wrote:
> > GSC NVM controller HW errors on quad access overlapping 1K border.
> > Align 64bit read and write to avoid readq/writeq over 1K border.
> >
> > Acke
Hi Aradhya,
On Mon May 26, 2025 at 4:17 PM CEST, Aradhya Bhatia wrote:
> Thank you for reviewing and testing the patches! =)
Thank you for your dedication to bring this feature upstream :)
> On 26/05/25 15:05, Michael Walle wrote:
> >
> >> +static int get_oldi_mode(struct device_node *oldi_tx,
> Subject: Re: [PATCH v10 06/10] drm/i915/nvm: add nvm device for discrete
> graphics
>
> On Thu, May 15, 2025 at 04:33:41PM +0300, Alexander Usyskin wrote:
> > Enable access to internal non-volatile memory on
> > DGFX devices via a child device.
> > The nvm child device is exposed via auxiliary b
> -Original Message-
> From: Jani Nikula
> Sent: Monday, May 19, 2025 6:22 PM
> To: Garg, Nemesa ; intel-...@lists.freedesktop.org;
> intel...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> Cc: Garg, Nemesa ; Nautiyal, Ankit K
>
> Subject: Re: [PATCH 05/10] drm/i915/display:
On 05/26/2025, Luca Ceresoli wrote:
> Hello Liu,
Hi Luca,
>
> On Thu, 22 May 2025 11:01:13 +0800
> Liu Ying wrote:
>
>> On 05/07/2025, Luca Ceresoli wrote:
>>
>> [...]
>>
After looking into this patch and patch 31(though I've already provided my
A-b)
more closely, I think the i
> -Original Message-
> From: Jani Nikula
> Sent: Monday, May 19, 2025 6:15 PM
> To: Garg, Nemesa ; intel-...@lists.freedesktop.org;
> intel...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> Cc: Garg, Nemesa ; Nautiyal, Ankit K
>
> Subject: Re: [PATCH 04/10] drm/i915/display:
Hi Leonardo,
Thank you for this patch, but unfortunately some unit test suites depend
on the names.
On 5/21/25 07:58, Leonardo Gomes wrote:
From: Leonardo da Silva Gomes
Adjust the dcn31_apg construct function name from
'apg31_construct' to 'dcn31_apg_construct'.
This helps the ftrace to de
Hi Michał,
kernel test robot noticed the following build errors:
[auto build test ERROR on pci/next]
[also build test ERROR on pci/for-linus drm-xe/drm-xe-next
drm-exynos/exynos-drm-next linus/master v6.15 next-20250526]
[cannot apply to drm/drm-next drm-intel/for-linux-next
drm-intel/for
Reviewed-by: Alex Hung
On 5/24/25 10:51, Christophe JAILLET wrote:
'struct timing_generator_funcs' are not modified in these drivers.
Constifying these structures moves some data to a read-only section, so
increases overall security, especially when the structure holds some
function pointers.
Reviewed-by: Alex Hung
On 5/25/25 20:37, Wentao Liang wrote:
The function mod_hdcp_hdcp1_enable_encryption() calls the function
get_first_active_display(), but does not check its return value.
The return value is a null pointer if the display list is empty.
This will lead to a null pointer dere
On 05/09/2025, Luca Ceresoli wrote:
> This is the new API for allocating DRM bridges.
>
> This driver embeds an array of channels in the main struct, and each
> channel embeds a drm_bridge. This prevents dynamic, refcount-based
> deallocation of the bridges.
>
> To make the new, dynamic bridge al
Hi Sumit,
On 5/14/2025 11:25 PM, Sumit Garg wrote:
> Hi Amir,
>
> Apologies for getting to this patch review a bit late, mostly due to
> it's enormous size.
>
Thank you so much for the review.
> On Mon, Apr 28, 2025 at 11:06:29PM -0700, Amirreza Zarrabi wrote:
>> Introduce qcomtee_object, whic
Hi Michał,
kernel test robot noticed the following build errors:
[auto build test ERROR on pci/next]
[also build test ERROR on pci/for-linus drm-xe/drm-xe-next
drm-exynos/exynos-drm-next linus/master v6.15 next-20250526]
[If your patch is applied to the wrong git tree, kindly drop us a note
On Tue, May 27, 2025 at 08:30:22AM +1000, Dave Airlie wrote:
> On Tue, 27 May 2025 at 08:08, Dave Chinner wrote:
> >
> > On Tue, May 27, 2025 at 06:32:30AM +1000, Dave Airlie wrote:
> > > Hey all,
> > >
> > > Hope someone here can help me work this out, I've been studying
> > > list_lru a bit this
On Tue May 27, 2025 at 12:30 AM CEST, Tamir Duberstein wrote:
> On Mon, May 26, 2025 at 11:05 AM Benno Lossin wrote:
>>
>> On Sat May 24, 2025 at 10:33 PM CEST, Tamir Duberstein wrote:
>> > Clean up references to `kernel::str::CStr`.
>> >
>> > Signed-off-by: Tamir Duberstein
>> > ---
>> > driver
On Tue May 27, 2025 at 12:29 AM CEST, Tamir Duberstein wrote:
> On Mon, May 26, 2025 at 11:04 AM Benno Lossin wrote:
>> On Sat May 24, 2025 at 10:33 PM CEST, Tamir Duberstein wrote:
>> > +macro_rules! c_str_avoid_literals {
>>
>> I don't like this name, how about `concat_to_c_str` or
>> `concat_wi
On Tue May 27, 2025 at 12:24 AM CEST, Tamir Duberstein wrote:
> On Mon, May 26, 2025 at 10:56 AM Benno Lossin wrote:
>>
>> On Sat May 24, 2025 at 10:33 PM CEST, Tamir Duberstein wrote:
>> > `std::ffi::CStr` was moved to `core::ffi::CStr` in Rust 1.64. Replace
>> > `kernel::str::CStr` with `core::f
On Tue May 27, 2025 at 12:17 AM CEST, Tamir Duberstein wrote:
> On Mon, May 26, 2025 at 10:48 AM Benno Lossin wrote:
>> On Sat May 24, 2025 at 10:33 PM CEST, Tamir Duberstein wrote:
>> > Introduce a `fmt!` macro which wraps all arguments in
>> > `kernel::fmt::Adapter` This enables formatting of fo
On Tue, 27 May 2025 at 08:08, Dave Chinner wrote:
>
> On Tue, May 27, 2025 at 06:32:30AM +1000, Dave Airlie wrote:
> > Hey all,
> >
> > Hope someone here can help me work this out, I've been studying
> > list_lru a bit this week for possible use in the GPU driver memory
> > pool code.
> >
> > I un
On Mon, May 26, 2025 at 11:05 AM Benno Lossin wrote:
>
> On Sat May 24, 2025 at 10:33 PM CEST, Tamir Duberstein wrote:
> > Clean up references to `kernel::str::CStr`.
> >
> > Signed-off-by: Tamir Duberstein
> > ---
> > drivers/gpu/drm/drm_panic_qr.rs | 3 ++-
> > drivers/gpu/nova-core/firmwar
On Mon, May 26, 2025 at 11:04 AM Benno Lossin wrote:
>
> On Sat May 24, 2025 at 10:33 PM CEST, Tamir Duberstein wrote:
> > +macro_rules! c_str_avoid_literals {
>
> I don't like this name, how about `concat_to_c_str` or
> `concat_with_nul`?
>
> This macro also is useful from macros that have a norm
On Mon, May 26, 2025 at 10:56 AM Benno Lossin wrote:
>
> On Sat May 24, 2025 at 10:33 PM CEST, Tamir Duberstein wrote:
> > `std::ffi::CStr` was moved to `core::ffi::CStr` in Rust 1.64. Replace
> > `kernel::str::CStr` with `core::ffi::CStr` now that we can.
>
> What's this supposed to mean?
It mea
On Mon, May 26, 2025 at 10:48 AM Benno Lossin wrote:
>
> On Sat May 24, 2025 at 10:33 PM CEST, Tamir Duberstein wrote:
> > Introduce a `fmt!` macro which wraps all arguments in
> > `kernel::fmt::Adapter` This enables formatting of foreign types (like
> > `core::ffi::CStr`) that do not implement `f
On Tue, May 27, 2025 at 06:32:30AM +1000, Dave Airlie wrote:
> Hey all,
>
> Hope someone here can help me work this out, I've been studying
> list_lru a bit this week for possible use in the GPU driver memory
> pool code.
>
> I understand that when a cgroup goes away, it's lru resources get
> rep
Hi Jayesh,
First of all, thanks for your patch. I applied it to our 6.6-based
downstream kernel supporting a board I have here, and noticed some
strange behaviour with eDP now.
On Thu, May 08, 2025 at 05:24:33PM +0530, Jayesh Choudhary wrote:
> + if (pdata->bridge.type == DRM_MODE_CONNECTOR_e
On Thu, Apr 03, 2025 at 01:20:58PM +0300, Ilpo Järvinen wrote:
> On Wed, 2 Apr 2025, Michał Winiarski wrote:
>
> > Drivers could leverage the fact that the VF BAR MMIO reservation is
> > created for total number of VFs supported by the device by resizing the
> > BAR to larger size when smaller num
Similar to regular resizable BAR, VF BAR can also be resized, e.g. by
the system firmware or the PCI subsystem itself.
The capability layout is the same as PCI_EXT_CAP_ID_REBAR.
Add the capability ID and restore it as a part of IOV state.
See PCIe r6.2, sec 7.8.7.
Signed-off-by: Michał Winiarsk
Hi,
Another revision after the feedback from Ilpo.
Missing includes and variable ordering were fixed.
v7 can be found here:
https://lore.kernel.org/linux-pci/20250402141122.2818478-1-michal.winiar...@intel.com/
For regular BAR, drivers can use pci_resize_resource to resize it to the
desired size
LMEM is partitioned between multiple VFs and we expect that the more
VFs we have, the less LMEM is assigned to each VF.
This means that we can achieve full LMEM BAR access without the need to
attempt full VF LMEM BAR resize via pci_resize_resource().
Always try to set the largest possible BAR size
Drivers could leverage the fact that the VF BAR MMIO reservation is
created for total number of VFs supported by the device by resizing the
BAR to larger size when smaller number of VFs is enabled.
Add a pci_iov_vf_bar_set_size() function to control the size and a
pci_iov_vf_bar_get_sizes() helper
When the resource representing VF MMIO BAR reservation is created, its
size is always large enough to accommodate the BAR of all SR-IOV Virtual
Functions that can potentially be created (total VFs). If for whatever
reason it's not possible to accommodate all VFs - the resource is not
assigned and n
There are multiple places where conversions between IOV resources and
corresponding VF BAR numbers are done.
Extract the logic to pci_resource_num_from_vf_bar() and
pci_resource_num_to_vf_bar() helpers.
Suggested-by: Ilpo Järvinen
Signed-off-by: Michał Winiarski
Acked-by: Christian König
Revie
Similar to regular resizable BAR, VF BAR can also be resized.
The capability layout is the same as PCI_EXT_CAP_ID_REBAR, which means
we can reuse most of the implementation, the only difference being
resource size calculation (which is multiplied by total VFs) and memory
decoding (which is control
Hi Damon,
kernel test robot noticed the following build errors:
[auto build test ERROR on drm-misc/drm-misc-next]
[also build test ERROR on next-20250526]
[cannot apply to linus/master v6.15]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we
Hi,
On Mon, May 26, 2025 at 07:30:35PM +0200, Maxime Ripard wrote:
On Mon, May 12, 2025 at 10:27:06PM +0200, Michael wrote:
with v6.9 and later there is no output on the BananaPI HDMI connector.
I have bisected the issue to the following commit:
358e76fd613a ("drm/sun4i: hdmi: Consolidate a
On Mon, May 26, 2025 at 12:15 PM Miguel Ojeda
wrote:
>
> On Sat, May 24, 2025 at 10:33 PM Tamir Duberstein wrote:
> >
> > This title is consistent with all other macros' documentation,
> > regardless of the number of examples contained in their "Examples"
> > sections.
> >
> > Signed-off-by: Tami
Hey all,
Hope someone here can help me work this out, I've been studying
list_lru a bit this week for possible use in the GPU driver memory
pool code.
I understand that when a cgroup goes away, it's lru resources get
reparented into the parent resource, however I'm wondering about
operation in th
On Mon, 26 May 2025 at 18:19, Christian König wrote:
>
> Hi Tejun,
>
> On 5/23/25 19:06, Tejun Heo wrote:
> > Hello, Christian.
> >
> > On Fri, May 23, 2025 at 09:58:58AM +0200, Christian König wrote:
> > ...
> >>> - There's a GPU workload which uses a sizable amount of system memory for
> >>> t
[AMD Official Use Only - AMD Internal Distribution Only]
Hi Mike,
It is indeed a bit harder, but we were able to repro the issue on the 6000
series. I'll need to get the DMCUB trace log to confirm, but it looks like an
SMU hang from within DMCUB. So we'd need more debugging to find out whats go
Hi,
On Mon, May 12, 2025 at 10:27:06PM +0200, Michael wrote:
> with v6.9 and later there is no output on the BananaPI HDMI connector.
>
> I have bisected the issue to the following commit:
>
> 358e76fd613a ("drm/sun4i: hdmi: Consolidate atomic_check and mode_valid")
>
> With this patch, sun4i
On Mon, May 12, 2025 at 10:27:07PM +0200, Michael wrote:
with v6.9 and later there is no output on the BananaPI HDMI connector.
I have bisected the issue to the following commit:
358e76fd613a ("drm/sun4i: hdmi: Consolidate atomic_check and mode_valid")
With this patch, sun4i_hdmi_connector_cl
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 following
Smatch static checker warning:
drivers/gpu/drm/xe/xe_vm.c:2922 prefetch_ranges()
Hi All,
On 26/05/25 16:28, Laurent Pinchart wrote:
On Mon, May 26, 2025 at 04:13:23PM +0200, Tommaso Merciai wrote:
On 26/05/25 16:02, Tommaso Merciai wrote:
On 26/05/25 15:18, Dmitry Baryshkov wrote:
On 26/05/2025 14:40, Maxime Ripard wrote:
On Mon, May 26, 2025 at 01:19:23PM +0200, Tommaso
On Sat, May 24, 2025 at 10:33 PM Tamir Duberstein wrote:
>
> This title is consistent with all other macros' documentation,
> regardless of the number of examples contained in their "Examples"
> sections.
>
> Signed-off-by: Tamir Duberstein
I was going to say that I could take this one independe
Hi Dmitry Baryshkov,
> -Original Message-
> From: Dmitry Baryshkov
> Sent: 23 May 2025 07:37
> Subject: Re: (subset) [PATCH v6 00/10] drm/display: generic HDMI CEC helpers
>
> Hi Biju
>
> On Fri, 23 May 2025 at 09:17, Biju Das wrote:
> >
> > Hi Dmitry Baryshkov,
> >
> > Thanks for the
On 5/7/25 11:28, Gerd Hoffmann wrote:
> Calling drm_dev_unplug() is the drm way to say the device
> is gone and can not be accessed any more.
>
> Cc: Michael S. Tsirkin
> Signed-off-by: Gerd Hoffmann
> Reviewed-by: Eric Auger
> Tested-by: Eric Auger
> ---
> drivers/gpu/drm/virtio/virtgpu_drv.
On Mon, May 26, 2025 at 1:36 AM Dmitry Baryshkov
wrote:
>
> On Sun, May 25, 2025 at 09:43:36PM +0200, Aleksandrs Vinarskis wrote:
> > On Sun, 25 May 2025 at 15:33, Dmitry Baryshkov
> > wrote:
> > >
> > > On Sat, May 24, 2025 at 07:58:13PM +0200, Aleksandrs Vinarskis wrote:
> > > > On Sat, 24 May
Hello Himal Prasad Ghimiray,
Commit 09ba0a8f06cd ("drm/xe/svm: Implement prefetch support for SVM
ranges") from May 13, 2025 (linux-next), leads to the following
Smatch static checker warning:
drivers/gpu/drm/xe/xe_vm.c:2922 prefetch_ranges()
warn: passing positive error code
's3
On Sat May 24, 2025 at 10:33 PM CEST, Tamir Duberstein wrote:
> Clean up references to `kernel::str::CStr`.
>
> Signed-off-by: Tamir Duberstein
> ---
> drivers/gpu/drm/drm_panic_qr.rs | 3 ++-
> drivers/gpu/nova-core/firmware.rs | 2 +-
> drivers/net/phy/ax88796b_rust.rs | 1 +
> drivers/ne
On Sat May 24, 2025 at 10:33 PM CEST, Tamir Duberstein wrote:
> -/// Creates a new [`CStr`] from a string literal.
> +/// Creates a static C string wrapper at compile time.
> ///
> -/// The string literal should not contain any `NUL` bytes.
> +/// Rust supports C string literals since Rust 1.77, a
Hi
Am 22.05.25 um 09:07 schrieb oushixiong1...@163.com:
From: Shixiong Ou
[WHY]
1. Drivers using DRM_GEM_SHADOW_PLANE_HELPER_FUNCS and
DRM_GEM_SHMEM_DRIVER_OPS (e.g., udl, ast) do not require
sg_table import.
They only need dma_buf_vmap() to access the shared buffer's
kernel vi
On Sat May 24, 2025 at 10:33 PM CEST, Tamir Duberstein wrote:
> `std::ffi::CStr` was moved to `core::ffi::CStr` in Rust 1.64. Replace
> `kernel::str::CStr` with `core::ffi::CStr` now that we can.
What's this supposed to mean?
> C-String literals were added in Rust 1.77. Opportunistically replace
On Sat May 24, 2025 at 10:33 PM CEST, Tamir Duberstein wrote:
> Introduce a `fmt!` macro which wraps all arguments in
> `kernel::fmt::Adapter` This enables formatting of foreign types (like
> `core::ffi::CStr`) that do not implement `fmt::Display` due to concerns
> around lossy conversions which do
On Sun, May 25, 2025 at 07:16:40AM +0200, Krzysztof Kozlowski wrote:
> Lists should have fixed constraints, because binding must be specific in
> respect to hardware. Add missing constraints to number of iommus in
> Mediatek media devices.
>
> Signed-off-by: Krzysztof Kozlowski
Acked-by: Conor
On Mon, May 26, 2025 at 04:13:23PM +0200, Tommaso Merciai wrote:
> On 26/05/25 16:02, Tommaso Merciai wrote:
> > On 26/05/25 15:18, Dmitry Baryshkov wrote:
> >> On 26/05/2025 14:40, Maxime Ripard wrote:
> >>> On Mon, May 26, 2025 at 01:19:23PM +0200, Tommaso Merciai wrote:
> On 26/05/25 12:49,
Pin and vmap are two distict operations. Do not mix them.
The helper drm_client_buffer_vmap() maps the pages for fbdev-dma
and fbdev-shmem. In both cases, the vmap operation ensures that
the pages are available until the vunmap happens. And as the pages
in DMA or SHMEM areas cannot be moved, there
Hi Michael,
Thank you for reviewing and testing the patches! =)
On 26/05/25 15:05, Michael Walle wrote:
> Hi Aradhya,
>
>> +static int get_oldi_mode(struct device_node *oldi_tx, int
>> *companion_instance)
>> +{
>> +struct device_node *companion;
>> +struct device_node *port0, *port1;
>
Hi Tejun,
On 5/23/25 19:06, Tejun Heo wrote:
> Hello, Christian.
>
> On Fri, May 23, 2025 at 09:58:58AM +0200, Christian König wrote:
> ...
>>> - There's a GPU workload which uses a sizable amount of system memory for
>>> the pool being discussed in this thread. This GPU workload is very
>>>
On 26/05/25 16:02, Tommaso Merciai wrote:
Hi All,
Thanks for your comments.
On 26/05/25 15:18, Dmitry Baryshkov wrote:
On 26/05/2025 14:40, Maxime Ripard wrote:
On Mon, May 26, 2025 at 01:19:23PM +0200, Tommaso Merciai wrote:
Hi Laurent,
Thanks for your comment.
On 26/05/25 12:49, Laurent
On 07-04-2025 16:00, Boris Brezillon wrote:
On Mon, 7 Apr 2025 15:47:03 +0530
Himal Prasad Ghimiray wrote:
- DRM_GPUVM_SM_MAP_NOT_MADVISE: Default sm_map operations for the input
range.
- DRM_GPUVM_SKIP_GEM_OBJ_VA_SPLIT_MADVISE: This flag is used by
drm_gpuvm_sm_map_ops_create to it
Hi All,
Thanks for your comments.
On 26/05/25 15:18, Dmitry Baryshkov wrote:
On 26/05/2025 14:40, Maxime Ripard wrote:
On Mon, May 26, 2025 at 01:19:23PM +0200, Tommaso Merciai wrote:
Hi Laurent,
Thanks for your comment.
On 26/05/25 12:49, Laurent Pinchart wrote:
On Mon, May 26, 2025 at 11:5
Am 22.05.25 um 09:07 schrieb oushixiong1...@163.com:
From: Shixiong Ou
Import dmabuf without mapping its sg_table to avoid issues likes:
udl 2-1.4:1.0: swiotlb buffer is full (sz: 2097152 bytes), total 65536
(slots), used 1 (slots)
Signed-off-by: Shixiong Ou
Reviewed-by: Thomas Zimm
Am 22.05.25 um 09:07 schrieb oushixiong1...@163.com:
From: Shixiong Ou
Import dmabuf without mapping its sg_table to avoid issues likes:
ast :07:00.0: swiotlb buffer is full (sz: 3145728 bytes), total 32768
(slots), used 0 (slots)
Signed-off-by: Shixiong Ou
Reviewed-by: Thomas Zi
Some unit tests intentionally trigger warning backtraces by passing bad
parameters to kernel API functions. Such unit tests typically check the
return value from such calls, not the existence of the warning backtrace.
Such intentionally generated warning backtraces are neither desirable
nor useful
The pin and unpin callbacks in struct drm_gem_object_funcs are
for PRIME exported dma-bufs. Remove the pin calls in the client
code, drop the unnecessary pin callbacks from gem-vram and inline
drm_gem_pin() into the only remaining caller. Do the equivalent
for drm_gem_unpin().
AFAICT the long-term
There are no external callers of the gem-vram pin helpers. Hence
unexport them.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_gem_vram_helper.c | 42 ++-
include/drm/drm_gem_vram_helper.h | 2 --
2 files changed, 2 insertions(
Inline drm_gem_pin() into its only caller drm_gem_map_attach()
and update the documentation in the callback's purpose. Do the
equivalent for drm_gem_unpin(). Also add stricter error checking
on the involved locking.
The pin operation in the GEM object functions is a helper for
PRIME-exported buffe
Gem-vram helpers do not support PRIME dma-buf sharing. So nothing
will ever call pin/unpin on its buffer objects. Do not set these
callbacks in struct drm_gem_object_funcs.
v2:
- fix typo in commit description
Signed-off-by: Thomas Zimmermann
Reviewed-by: Dmitry Osipenko
---
drivers/gpu/drm/dr
From: Guenter Roeck
The drm_test_rect_calc_hscale and drm_test_rect_calc_vscale unit tests
intentionally trigger warning backtraces by providing bad parameters to
the tested functions. What is tested is the return value, not the existence
of a warning backtrace. Suppress the backtraces to avoid c
KUnit support is not consistently present across distributions, some
include it in their stock kernels, while others do not.
While both KUNIT and KUNIT_SUPPRESS_BACKTRACE can be considered debug
features, the fact that some distros ship with KUnit enabled means it's
important to minimize the runtim
From: Guenter Roeck
Document API functions for suppressing warning backtraces.
Tested-by: Linux Kernel Functional Testing
Acked-by: Dan Carpenter
Reviewed-by: Kees Cook
Signed-off-by: Guenter Roeck
Reviewed-by: David Gow
Signed-off-by: Alessandro Carminati
---
Documentation/dev-tools/kuni
From: Guenter Roeck
Add unit tests to verify that warning backtrace suppression works.
If backtrace suppression does _not_ work, the unit tests will likely
trigger unsuppressed backtraces, which should actually help to get
the affected architectures / platforms fixed.
Tested-by: Linux Kernel Fu
Some unit tests intentionally trigger warning backtraces by passing bad
parameters to kernel API functions. Such unit tests typically check the
return value from such calls, not the existence of the warning backtrace.
Such intentionally generated warning backtraces are neither desirable
nor useful
On 26/05/2025 14:40, Maxime Ripard wrote:
On Mon, May 26, 2025 at 01:19:23PM +0200, Tommaso Merciai wrote:
Hi Laurent,
Thanks for your comment.
On 26/05/25 12:49, Laurent Pinchart wrote:
On Mon, May 26, 2025 at 11:58:37AM +0200, Tommaso Merciai wrote:
Hi Maxime,
Thanks for your comment.
On 2
https://bugzilla.kernel.org/show_bug.cgi?id=200531
Drei Eck (linux.felixbeck...@gmx.de) changed:
What|Removed |Added
CC||linux.felixbeck...@
A fence uniquely identify a job, so this commits updates the places
where a kernel pointer was used as an identifier by:
"fence=%llu:%llu"
Signed-off-by: Pierre-Eric Pelloux-Prayer
Reviewed-by: Tvrtko Ursulin
---
.../gpu/drm/scheduler/gpu_scheduler_trace.h | 44 ++-
1 file
This will be used in a later commit to trace the drm client_id in
some of the gpu_scheduler trace events.
This requires changing all the users of drm_sched_job_init to
add an extra parameter.
The newly added drm_client_id field in the drm_sched_fence is a bit
of a duplicate of the owner one. One
On 2024/12/8 13:42, Dmitry Baryshkov wrote:
On Thu, Dec 05, 2024 at 08:31:48PM -0800, Abhinav Kumar wrote:
Use the dp_panel's stream_id to adjust the offsets for stream 1
which will be used for MST in the dp_catalog. Also add additional
register defines for stream 1.
Signed-off-by: Abhinav K
All events now start with the same prefix (drm_sched_job_).
drm_sched_job_wait_dep was misleading because it wasn't waiting
at all. It's now replaced by trace_drm_sched_job_unschedulable,
which is only traced if the job cannot be scheduled.
For moot dependencies, nothing is traced.
Signed-off-by:
This commit adds a document section in drm-uapi.rst about tracepoints,
and mark the events gpu_scheduler_trace.h as stable uAPI.
The goal is to explicitly state that tools can rely on the fields,
formats and semantics of these events.
Acked-by: Lucas Stach
Acked-by: Maíra Canal
Reviewed-by: Chr
For processes with multiple drm_file instances, the drm_client_id is
the only way to map jobs back to their unique owner.
It's even more useful if drm client_name is set, because now a tool
can map jobs to the client name instead of only having access to
the process name.
Reviewed-by: Christian K
Log fences using the same format for coherency.
Signed-off-by: Pierre-Eric Pelloux-Prayer
Reviewed-by: Christian König
Reviewed-by: Arvind Yadav
---
drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 22 ++
1 file changed, 10 insertions(+), 12 deletions(-)
diff --git a/drivers/gp
Its only purpose was for trace events, but jobs can already be
uniquely identified using their fence.
The downside of using the fence is that it's only available
after 'drm_sched_job_arm' was called which is true for all trace
events that used job.id so they can safely switch to using it.
Suggest
We can't trace dependencies from drm_sched_job_add_dependency
because when it's called the job's fence is not available yet.
So instead each dependency is traced individually when
drm_sched_entity_push_job is used.
Tracing the dependencies allows tools to analyze the dependencies
between the jobs
1 - 100 of 175 matches
Mail list logo
