By importing scanout buffers from other devices, we should be able
to use the virtio-gpu driver in KMS only mode. Note that we attach
dynamically and register a move_notify() callback so that we can
let the VMM know of any location changes associated with the backing
store of the imported object by
When an imported dmabuf obj is used as part of an atomic commit, we
need to pin it as part of prepare and unpin it during cleanup of
the associated FB, to make sure that it does not move until the
commit is completed (and also while it is being used on the Host).
Cc: Gerd Hoffmann
Cc: Dmitry Osip
The imported object can be considered a guest blob resource;
therefore, we use create_blob cmd while creating it. These helpers
are used in the next patch which does the actual import.
Cc: Gerd Hoffmann
Cc: Dmitry Osipenko
Cc: Rob Clark
Cc: Gurchetan Singh
Cc: Chia-I Wu
Signed-off-by: Vivek K
This cmd is useful to let the VMM (i.e, Qemu) know that the backing
store associated with a resource is no longer valid, so that the VMM
can perform any cleanup or unmap operations.
The fence related changes and virtio_gpu_object_detach()/
virtio_gpu_detach_object_fenced() routines are extracted f
This helper would be used when first initializing the object as
part of import and also when updating the plane where we need to
ensure that the imported object's backing is valid.
Cc: Gerd Hoffmann
Cc: Dmitry Osipenko
Cc: Rob Clark
Cc: Gurchetan Singh
Cc: Chia-I Wu
Signed-off-by: Vivek Kasir
Having virtio-gpu import scanout buffers (via prime) from other
devices means that we'd be adding a head to headless GPUs assigned
to a Guest VM or additional heads to regular GPU devices that are
passthrough'd to the Guest. In these cases, the Guest compositor
can render into the scanout buffer us
Hi Dmitry,
> > Subject: Re: [PATCH v2 2/5] drm/virtio: Add a helper to map and note the
> > dma addrs and lengths
> >
> > On 10/29/24 09:18, Kasireddy, Vivek wrote:
> > BTW, is any DG2 GPU suitable for testing of this patchset? Will I be
> > able to test it using a regular consumer A750
On 15-11-2024 10:37, Raag Jadav wrote:
This was previously attempted as xe specific reset uevent but dropped
in commit 77a0d4d1cea2 ("drm/xe/uapi: Remove reset uevent for now")
as part of refactoring.
Now that we have device wedged event provided by DRM core, make use
of it and support both d
Following changes are getting added as part of this patch series:
- Move fastrpc driver to /misc/driver/ to enable maintainance of new
files to support additional features.
- Move macro and structure definitions to a new header file. These
date are consumed by features to be added in ne
On 15/11/24 10:37, Raag Jadav wrote:
> Now that we have device wedged event provided by DRM core, make use
> of it and support both driver rebind and bus-reset based recovery.
> With this in place, userspace will be notified of wedged device on
> gt reset failure.
>
> Signed-off-by: Raag Jadav
>
On 15/11/24 10:37, Raag Jadav wrote:
> This was previously attempted as xe specific reset uevent but dropped
> in commit 77a0d4d1cea2 ("drm/xe/uapi: Remove reset uevent for now")
> as part of refactoring.
>
> Now that we have device wedged event provided by DRM core, make use
> of it and support
Preempt fences are used by usermap queues to implement dynamic memory
(BO eviction, userptr invalidation), enable preempt fences on usermap
queues.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/xe/xe_exec_queue.c | 3 ++-
drivers/gpu/drm/xe/xe_pt.c | 3 +--
drivers/gpu/drm/xe/xe_vm.
Hi Maira,
>
> The patch overall LGTM, I just have one small nit.
>
Hopefully v4 will be the last iteration.
> On 17/11/24 18:41, Christian Gmeiner wrote:
> > From: Christian Gmeiner
> >
> > Add a new ioctl, DRM_IOCTL_V3D_PERFMON_SET_GLOBAL, to allow
> > configuration of a global performance mon
On 10/31/2024, Liu Ying wrote:
> Hi Maxime,
>
> On 10/30/2024, Maxime Ripard wrote:
>> On Mon, Oct 28, 2024 at 10:37:30AM +0800, Liu Ying wrote:
>>> Multiple display modes could be read from a display device's EDID.
>>> Use clk_round_rate() to validate the "ldb" clock rate for each mode
>>> in drm
On 11/18/2024, Maxime Ripard wrote:
> On Thu, Oct 31, 2024 at 10:35:27AM +0800, Liu Ying wrote:
>> Hi Maxime,
>>
>> On 10/22/2024, Maxime Ripard wrote:
>>> On Tue, Oct 22, 2024 at 02:13:57PM +0800, Liu Ying wrote:
On 10/13/2024, Marek Vasut wrote:
> On 10/11/24 8:18 AM, Liu Ying wrote:
>>>
> On Nov 19, 2024, at 02:18, Easwar Hariharan
> wrote:
>
> On 11/18/2024 3:06 AM, Petr Mladek wrote:
>> On Sat 2024-11-16 11:10:52, Christophe Leroy wrote:
>>>
>>>
>>> Le 15/11/2024 à 22:26, Easwar Hariharan a écrit :
[Vous ne recevez pas souvent de courriers de eahar...@linux.microsof
On 11/18/24 4:54 AM, Ying Liu wrote:
Hi Marek,
Hi,
media_disp1_pix clock is the pixel clock of the first i.MX8MP LCDIFv3
display controller, while media_disp2_pix clock is the pixel clock of
the second i.MX8MP LCDIFv3 display controller. The two display
controllers connect with Samsung MIPI
SST with 128b/132b channel coding needs this too. Extract to a separate
helper, independent of MST.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/display/drm_dp_helper.c | 56 +++
drivers/gpu/drm/display/drm_dp_mst_topology.c | 52 +
include/drm/display/drm
From: Tejas Upadhyay
In order to avoid having userspace to use MI_MEM_FENCE,
we are adding a mechanism for userspace to generate a
PCI memory barrier with low overhead (avoiding IOCTL call
as well as writing to VRAM will adds some overhead).
This is implemented by memory-mapping a page as uncach
Add a dma_fence_preempt base class with driver ops to implement
preemption, based on the existing Xe preemptive fence implementation.
Annotated to ensure correct driver usage.
Cc: Dave Airlie
Cc: Simona Vetter
Cc: Christian Koenig
Signed-off-by: Matthew Brost
---
drivers/dma-buf/Makefile
Teach xe_sync layer about drm_xe_semaphore which is used import / export
user fences.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/xe/xe_sync.c | 90 ++
drivers/gpu/drm/xe/xe_sync.h | 8 +++
drivers/gpu/drm/xe/xe_sync_types.h | 5 +-
3 files changed,
https://bugzilla.kernel.org/show_bug.cgi?id=219507
--- Comment #5 from Paul Osmialowski (newch...@king.net.pl) ---
I came across this page: https://bugs.mageia.org/show_bug.cgi?id=31695 and
tried the workaround presented on it, I've created /etc/X11/xorg.conf as such:
Section "Device"
Identif
Basically a version of the resume worker which also converts user syncs
to kerenl syncs (dma-fences) and vise versa. The expoxrted dma-fences in
the conversion guard against preemption which is required to avoid
breaking dma fence rules (no memory allocations in path of dma-fence,
resume requires m
Add exec queue post init extension processing which is needed for more
complex extensions in which data is returned to the user.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/xe/xe_exec_queue.c | 48 ++
1 file changed, 48 insertions(+)
diff --git a/drivers/gpu/drm
The assumption only a VM in preempt fence mode has preempt fences
attached is not true, preempt fences can be attached to a dma-resv VM if
user queues are open.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/xe/xe_pt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers
Simple interface to allow user space to share user syncs with kernel
syncs (dma-fences). The idea also is when user syncs are converted to
kernel syncs, preemption is guarded against until the kernel sync
signals. This is required to adhere to dma-fencing rules (no memory
allocates done in path of
Not supported at the moment, may need something in the no doorbells
available.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/xe/xe_exec.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/xe/xe_exec.c b/drivers/gpu/drm/xe/xe_exec.c
index 31cca938956f..898e4
The ring and indirect ring state need to mapped to user space for UMD
direction submission, add support for this.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/xe/xe_bo.c | 3 ---
drivers/gpu/drm/xe/xe_exec_queue.c | 2 +-
drivers/gpu/drm/xe/xe_execlist.c | 2 +-
drivers/gpu/drm/
Use the dma_fence_preempt base class in Xe instead of open-coding the
preemption implementation.
Cc: Dave Airlie
Cc: Simona Vetter
Cc: Christian Koenig
Signed-off-by: Matthew Brost
---
drivers/dma-buf/dma-fence-preempt.c | 5 +-
drivers/gpu/drm/xe/xe_guc_submit.c | 3 +
dri
Add xe_hw_fence_user_init which can create a struct xe_hw_fence from a
user input rather than internal LRC state. Used to import user fence and
export them as dma fences.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/xe/xe_hw_fence.c | 17 +
drivers/gpu/drm/xe/xe_hw_fence.h |
Stop abusing job list lock for message, use a dedicated lock. This lock
will soon be able to be taken in IRQ contexts, using irqsave for
simplicity. Can to tweaked in a follow up as needed.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/xe/xe_gpu_scheduler.c | 19 ---
dri
Normalize user fence attachment to a DMA fence. A user fence is a simple
seqno write to memory, implemented by attaching a DMA fence callback
that writes out the seqno. Intended use case is importing a dma-fence
into kernel and exporting a user fence.
Helpers added to allocate, attach, and free a
Imported user fences will not be tied to a specific queue or hardware
engine class. Therefore, a device IRQ handler is needed to signal the
associated exported DMA fences.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/xe/xe_device.c | 4
drivers/gpu/drm/xe/xe_device_types.h | 3 +++
We cannot let user fences exported as dma-fence run forever. Add a TDR
to protect against this. If the TDR fires the entire VM is killed as
dma-fences are not tied to an individual queue.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/xe/xe_vm.c | 164 +--
dri
Unsure why, but without this intermittent hangs occur on GuC context
switching.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/xe/xe_lrc.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/xe/xe_lrc.c b/drivers/gpu/drm/xe/xe_lrc.c
index e3c1773191bd..9633
Define UMD exec queue mapping uAPI. The submit ring, indirect LRC state
(ring head, tail, etc...), and doorbell are securly mapped to user
space. The ring is a VM PPGTT addres, while indirect LRC state and
doorbell mapping is provided via a fake offset like BOs.
Signed-off-by: Matthew Brost
---
Doorbells need to be mapped to user space for UMD direct submisssion,
add support for this.
FIXME: Wildly insecure as anyone can pick MMIO doorbell offset, will
need to randomize and tie unique offset to FD. Can be done in later revs
before upstreaming.
Signed-off-by: Matthew Brost
---
drivers/
The media GT supports this, required for UMD submission, so enable by
default.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/xe/xe_pci.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/xe/xe_pci.c b/drivers/gpu/drm/xe/xe_pci.c
index 9b81e7d00a86..a27450e63cf9 100644
--- a/
Use xe_exec_queue_is_usermap helper instead.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/xe/xe_exec_queue.c | 3 +--
drivers/gpu/drm/xe/xe_exec_queue.h | 5 +
drivers/gpu/drm/xe/xe_exec_queue_types.h | 2 --
drivers/gpu/drm/xe/xe_guc_submit.c | 4 ++--
drivers/gpu/drm/
Usermap exec queue's teardown (kill) differs from other exec queues as
no job is available, a doorbell is mapped, and the kill should be
immediate.
A follow up could unify LR queue cleanup with usermap but keeping this
a seperate flow for now.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/xe
Start laying the ground work for UMD submission. This will allow mmaping
the submission ring to user space.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/xe/xe_lrc.c | 38 +--
drivers/gpu/drm/xe/xe_lrc_types.h | 9 ++--
2 files changed, 38 insertions(+),
We don't want kernel pinned resources (ring, indirect state) in the VM's
bulk move as these are unevictable.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/xe/xe_bo.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/xe/xe_bo.c b/drivers/gpu/drm/xe/
Implement uAPI which maps submit rings, indirect LRC state, and
doorbells to user space. This is required for UMD direction submission.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/xe/xe_exec_queue.c | 125 ++-
drivers/gpu/drm/xe/xe_exec_queue_types.h | 13 +++
dri
Start laying the ground work for UMD submission. This will allow mmaping
the indirect ring state to user space.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/xe/xe_lrc.c | 79 ++-
drivers/gpu/drm/xe/xe_lrc_types.h | 7 ++-
2 files changed, 63 insertions(+),
Part of what xe_bo_restore_kernel does, is restore BO's GGTT mappings
which may have been lost during a power state change. Missing is
restoring the GGTT entries without BO mappings to a known state (e.g.,
scratch pages). Update xe_bo_restore_kernel to clear the entire GGTT
before restoring BO's GG
These will be mapped to user space for UMD submission. Add
infrastructure to GuC submission backend to manage these.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/xe/xe_exec_queue_types.h | 2 +
drivers/gpu/drm/xe/xe_guc_exec_queue_types.h | 7 ++
drivers/gpu/drm/xe/xe_guc_submit.c
Useful for debugging hangs with doorbells.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/xe/xe_guc_submit.c | 2 ++
drivers/gpu/drm/xe/xe_guc_submit_types.h | 2 ++
2 files changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/xe/xe_guc_submit.c
b/drivers/gpu/drm/xe/xe_guc_submit.c
in
This is an RFC, or possibly even a proof of concept, for UMD (User Mode
Driver) direct submission in Xe. It is similar to AMD's design [1] [2]
or ARM's design [3], utilizing a uAPI to convert user-space syncs
(memory writes) to kernel-space syncs (DMA fences). It is built around
the existing Xe pre
On 2024/11/13 20:07, Dmitry Baryshkov wrote:
On Wed, 13 Nov 2024 at 13:53, Fange Zhang wrote:
From: Li Liu
QCS615 platform uses the 14nm DSI PHY driver.
Signed-off-by: Li Liu
Signed-off-by: Fange Zhang
---
Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml | 1 +
1 file
From: Christian Gmeiner
If the active performance monitor (v3d->active_perfmon) is being
destroyed, stop it first. Currently, the active perfmon is not
stopped during destruction, leaving the v3d->active_perfmon pointer
stale. This can lead to undefined behavior and instability.
This patch ensur
On 11/17/2024 12:26 PM, Jeffrey Hugo wrote:
The documentation for vfree() says that passing in NULL is ok. Therefore
we can drop the null check as redundant.
Reported-by: kernel test robot
Closes:
https://lore.kernel.org/oe-kbuild-all/202410301732.abf5md4e-...@intel.com/
Signed-off-by: Jeffrey
Move fastrpc structures and MACRO definitions to a new header file.
These definitions are consumed by other upcoming features like
debugfs, PDR support etc.
Signed-off-by: Ekansh Gupta
---
drivers/misc/fastrpc/fastrpc_main.c | 136 +-
drivers/misc/fastrpc/fastrpc_shared.h |
Expose drm plane function to create formats/modifiers blob. This
function can be used to expose list of supported formats/modifiers for
sync/async flips.
Signed-off-by: Arun R Murthy
---
drivers/gpu/drm/drm_plane.c | 44 -
include/drm/drm_plane.h | 4
On Fri, 15 Nov 2024, Dmitry Baryshkov wrote:
> The mode_valid() callbacks of drm_encoder, drm_crtc and drm_bridge
> accept const struct drm_display_mode argument. Change the mode_valid
> callback of drm_connector to also accept const argument.
>
> Signed-off-by: Dmitry Baryshkov
Acked-by: Jani N
https://bugzilla.kernel.org/show_bug.cgi?id=219507
--- Comment #1 from Paul Osmialowski (newch...@king.net.pl) ---
I've just made an accidental discovery: this does not happen when I'm using
HDMI output only. And that's a huge degradation, as I'm so got used to work
with two-monitor setup like thi
Am 15.11.24 um 11:21 schrieb Tvrtko Ursulin:
From: Tvrtko Ursulin
Consolidated series as an simpler alternative to
https://lore.kernel.org/dri-devel/20241024124159.4519-3-christian.koe...@amd.com/.
Hopefully fixes https://gitlab.freedesktop.org/drm/amd/-/issues/3617.
First two patches are fix
Hi Dmitry,
> Subject: Re: [PATCH v2 2/5] drm/virtio: Add a helper to map and note the
> dma addrs and lengths
>
> On 10/29/24 09:18, Kasireddy, Vivek wrote:
> BTW, is any DG2 GPU suitable for testing of this patchset? Will I be
> able to test it using a regular consumer A750 card?
> >>>
This patchset introduces a new Linux Kernel Driver, amdxdna for AMD NPUs.
The driver is based on Linux accel subsystem.
NPU (Neural Processing Unit) is an AI inference accelerator integrated
into AMD client CPUs. NPU enables efficient execution of Machine Learning
applications like CNNs, LLMs, etc
Populate the list of formats/modifiers supported by async flip. Register
a async property and expose the same to user through blob.
Signed-off-by: Arun R Murthy
---
.../drm/i915/display/skl_universal_plane.c| 51 +++
1 file changed, 51 insertions(+)
diff --git a/drivers/gpu/
Le 15/11/2024 à 22:09, Dmitry Baryshkov a écrit :
The mode_valid() callbacks of drm_encoder, drm_crtc and drm_bridge
accept const struct drm_display_mode argument. Change the mode_valid
callback of drm_connector to also accept const argument.
Signed-off-by: Dmitry Baryshkov
---
Hi Dmitry,
Make hda_get_mode_idx() accept const struct drm_display_mode pointer
instead of just raw struct drm_display_mode. This is a preparation to
converting the mode_valid() callback of drm_connector to accept const
struct drm_display_mode argument.
Signed-off-by: Dmitry Baryshkov
---
Hi Dmitry,
On Mon, Nov 18, 2024 at 06:17:11PM +0100, Louis Chauvet wrote:
> On 18/11/24 - 18:10, José Expósito wrote:
> > > Introduce the usage of block_h/block_w to compute the offset and the
> > > pointer of a pixel. The previous implementation was specialized for
> > > planes with block_h == block_w == 1.
On 11/18/2024 10:29 AM, Lizhi Hou wrote:
This patchset introduces a new Linux Kernel Driver, amdxdna for AMD NPUs.
The driver is based on Linux accel subsystem.
Not seeing any additional issues. Build for bisect looks good. My plan
is to let this sit on list until Friday to allow for one fin
This add the support for:
- R1/R2/R4/R8
R1 format was tested with [1] and [2].
[1]:
https://lore.kernel.org/r/20240313-new_rotation-v2-0-6230fd5ca...@bootlin.com
[2]:
https://lore.kernel.org/igt-dev/20240306-b4-kms_tests-v1-0-8fe451efd...@bootlin.com/
Reviewed-by: Pekka Paalanen
Signed-off-by
As the pixel_read and pixel_write function should never modify the input
buffer, mark those pointers const.
Reviewed-by: Pekka Paalanen
Reviewed-by: Maíra Canal
Reviewed-by: José Expósito
Signed-off-by: Louis Chauvet
---
drivers/gpu/drm/vkms/vkms_drv.h | 4 ++--
drivers/gpu/drm/vkms/vkms
From: Arthur Grillo
Now that we have KUnit tests, add instructions on how to run them.
Signed-off-by: Arthur Grillo
Signed-off-by: Louis Chauvet
---
Documentation/gpu/vkms.rst | 11 +++
1 file changed, 11 insertions(+)
diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.
From: Arthur Grillo
Add support to the YUV formats bellow:
- NV12/NV16/NV24
- NV21/NV61/NV42
- YUV420/YUV422/YUV444
- YVU420/YVU422/YVU444
The conversion from yuv to rgb is done with fixed-point arithmetic, using
32.32 fixed-point numbers and the drm_fixed helpers.
To do the conversion, a spec
From: Arthur Grillo
VKMS has support for YUV formats now. Remove the task from the TODO
list.
Signed-off-by: Arthur Grillo
Signed-off-by: Louis Chauvet
---
Documentation/gpu/vkms.rst | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/Documentation/gpu/vkms.rst b/Documentati
This series depends on [1].
This patchset is extracted from [1]. The goal is to introduce the YUV
support, thanks to Arthur's work.
- PATCH 1: Add the support of YUV formats
- PATCH 2: Add some drm properties to expose more YUV features
- PATCH 3: Cleanup the todo
- PATCH 4..6: Add some kunit tes
From: Arthur Grillo
Create KUnit tests to test the conversion between YUV and RGB. Test each
conversion and range combination with some common colors.
The code used to compute the expected result can be found in comment.
[Louis Chauvet:
- fix minor formating issues (whitespace, double line)
- c
On 18/11/24 - 19:43, Louis Chauvet wrote:
> This series depends on [1].
>
> This patchset is extracted from [1]. The goal is to introduce the YUV
> support, thanks to Arthur's work.
>
> - PATCH 1: Add the support of YUV formats
> - PATCH 2: Add some drm properties to expose more YUV features
> -
On 11/16/2024 1:52 AM, Christophe Leroy wrote:
>
>
> Le 15/11/2024 à 22:26, Easwar Hariharan a écrit :
>> [Vous ne recevez pas souvent de courriers de
>> eahar...@linux.microsoft.com. Découvrez pourquoi ceci est important à
>> https://aka.ms/LearnAboutSenderIdentification ]
>>
>
> There should b
The functions drm_get_color_encoding_name and drm_get_color_range_name
are useful for clarifying test results. Therefore, export them so they
can be used in tests built as modules.
---
drivers/gpu/drm/drm_color_mgmt.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/drm_color_
From: Arthur Grillo
Now that the driver internally handles these quantization ranges and YUV
encoding matrices, expose the UAPI for setting them.
Signed-off-by: Arthur Grillo
[Louis Chauvet: retained only relevant parts, updated the commit message]
Acked-by: Pekka Paalanen
Signed-off-by: Louis
The pre_mul_alpha_blend is dedicated to blending, so to avoid mixing
different concepts (coordinate calculation and color management), extract
the x_limit and x_dst computation outside of this helper.
It also increases the maintainability by grouping the computation related
to coordinates in the sa
Introduce the usage of block_h/block_w to compute the offset and the
pointer of a pixel. The previous implementation was specialized for
planes with block_h == block_w == 1. To avoid confusion and allow easier
implementation of tiled formats. It also remove the usage of the
deprecated format field
Re-introduce a line-by-line composition algorithm for each pixel format.
This allows more performance by not requiring an indirection per pixel
read. This patch is focused on readability of the code.
Line-by-line composition was introduced by [1] but rewritten back to
pixel-by-pixel algorithm in [
From: Arthur Grillo
Remove intermidiary variables and access the variables directly from
drm_frame. These changes should be noop.
Signed-off-by: Arthur Grillo
Acked-by: Pekka Paalanen
Reviewed-by: Maíra Canal
Reviewed-by: José Expósito
Reviewed-by: Louis Chauvet
[Louis Chauvet: Applied revi
As all the rotation are now supported by VKMS, this simplification does
not make sense anymore, so remove it.
Acked-by: Maíra Canal
Reviewed-by: José Expósito
Signed-off-by: Louis Chauvet
---
drivers/gpu/drm/vkms/vkms_plane.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --
The pixel_read_direction enum is useful to describe the reading direction
in a plane. It avoids using the rotation property of DRM, which not
practical to know the direction of reading.
This patch also introduce two helpers, one to compute the
pixel_read_direction from the DRM rotation property, an
Few no-op changes to remove double spaces and fix wrong alignments.
Reviewed-by: Pekka Paalanen
Reviewed-by: Maíra Canal
Reviewed-by: José Expósito
Signed-off-by: Louis Chauvet
---
drivers/gpu/drm/vkms/vkms_composer.c | 10 +-
drivers/gpu/drm/vkms/vkms_crtc.c | 6 ++
drivers/
Introduce two typedefs: pixel_read_t and pixel_write_t. It allows the
compiler to check if the passed functions take the correct arguments.
Such typedefs will help ensuring consistency across the code base in
case of update of these prototypes.
Rename input/output variable in a consistent way betw
This patchset is the second version of [1]. It is almost a complete
rewrite to use a line-by-line algorithm for the composition.
It can be divided in multiple parts:
- PATCH 1 to 3: no functional change is intended, only some formatting and
documenting (PATCH 2 is taken from [2])
- PATCH 4 to 7:
On 11/18/2024 3:06 AM, Petr Mladek wrote:
> On Sat 2024-11-16 11:10:52, Christophe Leroy wrote:
>>
>>
>> Le 15/11/2024 à 22:26, Easwar Hariharan a écrit :
>>> [Vous ne recevez pas souvent de courriers de eahar...@linux.microsoft.com.
>>> Découvrez pourquoi ceci est important à
>>> https://aka.ms/
On 11/16/2024 1:40 AM, Christophe Leroy wrote:
>
>
> Le 15/11/2024 à 22:26, Easwar Hariharan a écrit :
>> [Vous ne recevez pas souvent de courriers de
>> eahar...@linux.microsoft.com. Découvrez pourquoi ceci est important à
>> https://aka.ms/LearnAboutSenderIdentification ]
>>
>> None of the high
On Mon, Nov 18, 2024 at 02:12:14PM +0200, Jani Nikula wrote:
> On Fri, 15 Nov 2024, Imre Deak wrote:
> > After a connector is added to the drm_mode_config::connector_list, it's
> > visible to any in-kernel users looking up connectors via the above list.
> > Make sure that the connector is properly
On 11/15/2024 10:05 PM, Christophe JAILLET wrote:
> Le 15/11/2024 à 22:26, Easwar Hariharan a écrit :
>> Suggested-by: Anna-Maria Behnsen
>> Signed-off-by: Easwar Hariharan
>> ---
>> scripts/coccinelle/misc/secs_to_jiffies.cocci | 21 +
>> 1 file changed, 21 insertions(+)
>
On 11/16/2024 2:23 AM, LEROY Christophe wrote:
>
>
> Le 15/11/2024 à 22:26, Easwar Hariharan a écrit :
>> [Vous ne recevez pas souvent de courriers de eahar...@linux.microsoft.com.
>> Découvrez pourquoi ceci est important à
>> https://aka.ms/LearnAboutSenderIdentification ]
>>
>> This is a seri
On Mon, Nov 18, 2024 at 03:21:52PM +, Karunika Choo wrote:
> Stop checking the FW halt_status as MCU_STATUS should be sufficient.
> This should make the check for successful FW halt and subsequently
> setting fast_reset to true more robust.
>
> We should also clear GLB_REQ.GLB_HALT bit only on
On Mon, Nov 18, 2024 at 02:09:29PM +0200, Jani Nikula wrote:
> On Fri, 15 Nov 2024, Imre Deak wrote:
> > Atm when the connector is added to the drm_mode_config::connector_list,
> > the connector may not be fully initialized yet. This is not a problem
> > for user space, which will see the connecto
The AI Engine consists of 2D array of tiles arranged as columns. Provides
the basic column allocation and release functions for the tile columns.
Co-developed-by: Min Ma
Signed-off-by: Min Ma
Reviewed-by: Jeffrey Hugo
Signed-off-by: Lizhi Hou
---
drivers/accel/amdxdna/Makefile | 1
On 18/11/24 - 18:24, José Expósito wrote:
> On Mon, Nov 18, 2024 at 06:17:11PM +0100, Louis Chauvet wrote:
> > On 18/11/24 - 18:10, José Expósito wrote:
> > > > Introduce the usage of block_h/block_w to compute the offset and the
> > > > pointer of a pixel. The previous implementation was specializ
When there is a hardware error, the NPU firmware notifies the host through
a mailbox message. The message includes details of the error, such as the
tile and column indexes where the error occurred.
The driver starts a thread to handle the NPU error message. The thread
stops the clients which are
The hardware mailboxes are used by the driver to submit requests to
firmware and receive the completion notices from hardware.
Initially, a management mailbox channel is up and running. The driver may
request firmware to create/destroy more channels dynamically through
management channel.
Add dri
The hardware can be shared among multiple user applications. The
hardware resources are allocated/freed based on the request from
user application via driver IOCTLs.
DRM_IOCTL_AMDXDNA_CREATE_HWCTX
Allocate tile columns and create a hardware context structure to track the
usage and status of the re
Implement PCI power management suspend and resume callbacks.
Co-developed-by: Narendra Gutta
Signed-off-by: Narendra Gutta
Co-developed-by: Xiaoming Ren
Signed-off-by: Xiaoming Ren
Co-developed-by: Min Ma
Signed-off-by: Min Ma
Reviewed-by: Jeffrey Hugo
Signed-off-by: Lizhi Hou
---
drivers
1 - 100 of 218 matches
Mail list logo
