This commit provides the interfaces for the new UAPI motivated by the
Vulkan API. It allows user mode drivers (UMDs) to:
1) Initialize a GPU virtual address (VA) space via the new
DRM_IOCTL_NOUVEAU_VM_INIT ioctl. UMDs can provide a kernel reserved
VA area.
2) Bind and unbind GPU VA space ma
This commit adds a function to dump a DRM GPU VA space and a macro for
drivers to register the struct drm_info_list 'gpuvas' entry.
Most likely, most drivers might maintain one DRM GPU VA space per struct
drm_file, but there might also be drivers not having a fixed relation
between DRM GPU VA spac
Provide a getter function for the client's current vmm context. Since
we'll add a new (u)vmm context for UMD bindings in subsequent commits,
this will keep the code clean.
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_chan.c |
Initialize the GEM's DRM GPU VA manager interface in preparation for the
(u)vmm implementation, provided by subsequent commits, to make use of it.
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/nouve
The new (VM_BIND) UAPI exports DMA fences through DRM syncobjs. Hence,
in order to emit fences within DMA fence signalling critical sections
(e.g. as typically done in the DRM GPU schedulers run_job() callback) we
need to separate fence allocation and fence emitting.
Signed-off-by: Danilo Krummric
Move the usercopy helpers to a common driver header file to make it
usable for the new API added in subsequent commits.
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/nouveau/nouveau_drv.h | 26 ++
drivers/gpu/drm/nouveau/nouveau_gem.c | 26 --
The new VM_BIND UAPI implementation introduced in subsequent commits
will allow asynchronous jobs processing push buffers and emitting
fences.
If a fence context is killed, e.g. due to a channel fault, jobs which
are already queued for execution might still emit new fences. In such a
case a job wo
The new VM_BIND UAPI implementation introduced in subsequent commits
will allow asynchronous jobs processing push buffers and emitting fences.
If a job times out, we need a way to recover from this situation. For
now, simply kill the channel to unblock all hung up jobs and signal
userspace that th
This commit provides the implementation for the new uapi motivated by the
Vulkan API. It allows user mode drivers (UMDs) to:
1) Initialize a GPU virtual address (VA) space via the new
DRM_IOCTL_NOUVEAU_VM_INIT ioctl for UMDs to specify the portion of VA
space managed by the kernel and usersp
The new VM_BIND UAPI uses the DRM GPU VA manager to manage the VA space.
Hence, we a need a way to manipulate the MMUs page tables without going
through the internal range allocator implemented by nvkm/vmm.
This patch adds a raw interface for nvkm/vmm to pass the resposibility
for managing the add
Provide the driver indirection iterating over all DRM GPU VA spaces to
enable the common 'gpuvas' debugfs file for dumping DRM GPU VA spaces.
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/nouveau/nouveau_debugfs.c | 39 +++
1 file changed, 39 insertions(+)
diff --git a
On Tue, 2023-06-20 at 09:30 -0500, Balasubrawmanian, Vivaik wrote:
> On 6/1/2023 12:45 PM, Alan Previn wrote:
> > After recent discussions with Mesa folks, it was requested
> > that we optimize i915's GET_PARAM for the PXP_STATUS without
> > changing the UAPI spec.
> >
> > This patch adds this add
This patch series splits the fbdev core support in two different Kconfig
symbols: FB and FB_CORE. The motivation for this is to allow CONFIG_FB to
be disabled, while still having the the core fbdev support needed for the
CONFIG_DRM_FBDEV_EMULATION to be enabled. The motivation is automatically
disa
Now that the fbdev core has been split in FB_CORE and FB, make DRM fbdev
emulation layer to just depend on the former.
This allows to disable the CONFIG_FB option if is not needed, which will
avoid the need to explicitly disable each of the legacy fbdev drivers.
Signed-off-by: Javier Martinez Can
Currently the CONFIG_FB option has to be enabled even if no legacy fbdev
drivers are needed (e.g: only to have support for framebuffer consoles).
The DRM subsystem has a fbdev emulation layer, but depends on CONFIG_FB
and so it can only be enabled if that dependency is enabled as well.
That means
Hi Konrad,
kernel test robot noticed the following build errors:
[auto build test ERROR on 5c875096d59010cee4e00da1f9c7bdb07a025dc2]
url:
https://github.com/intel-lab-lkp/linux/commits/Konrad-Dybcio/dt-bindings-regulator-Describe-Qualcomm-REFGEN-regulator/20230630-043835
base: 5c875096d590
On 6/24/2023 7:44 PM, Abhinav Kumar wrote:
On 6/24/2023 8:03 AM, Dmitry Baryshkov wrote:
On 24/06/2023 17:17, Abhinav Kumar wrote:
On 6/24/2023 5:07 AM, Dmitry Baryshkov wrote:
On 24/06/2023 03:09, Abhinav Kumar wrote:
On 6/22/2023 5:13 PM, Dmitry Baryshkov wrote:
On 23/06/2023 02:4
On 29/06/2023 22:53, Konrad Dybcio wrote:
On 29.06.2023 14:24, Dmitry Baryshkov wrote:
On Thu, 29 Jun 2023 at 15:14, Marijn Suijten
wrote:
On 2023-06-29 13:56:25, Dmitry Baryshkov wrote:
On 27/06/2023 23:14, Marijn Suijten wrote:
Enable and configure the dispcc node on SM6125 for consumptio
On 30/06/2023 02:29, Abhinav Kumar wrote:
On 6/24/2023 7:44 PM, Abhinav Kumar wrote:
On 6/24/2023 8:03 AM, Dmitry Baryshkov wrote:
On 24/06/2023 17:17, Abhinav Kumar wrote:
On 6/24/2023 5:07 AM, Dmitry Baryshkov wrote:
On 24/06/2023 03:09, Abhinav Kumar wrote:
On 6/22/2023 5:13 PM, D
On 29/06/2023 22:29, Abhinav Kumar wrote:
With [1] dpu core revision was dropped in favor of using the
compatible string from the device tree to select the dpu catalog
being used in the device.
This approach works well however also necessitates adding catalog
entries for small register level det
On 29/06/2023 22:29, Abhinav Kumar wrote:
Instead of using a feature bit to decide whether to enable data
compress or not for DSC use-cases, use dpu core's major version instead.
This will avoid defining feature bits for every bit level details of
registers.
Also, rename the intf's enable_compre
On 29/06/2023 22:29, Abhinav Kumar wrote:
Now that all usages of DPU_INTF_DATA_COMPRESS have been replaced
with the dpu core's major revision lets drop DPU_INTF_DATA_COMPRESS
from the catalog completely.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 2 +-
On 29/06/2023 22:29, Abhinav Kumar wrote:
With [1] dpu core revision was dropped in favor of using the
compatible string from the device tree to select the dpu catalog
being used in the device.
This approach works well however also necessitates adding catalog
entries for small register level det
Add support for pixel_source property to drm_plane and related
documentation.
This enum property will allow user to specify a pixel source for the
plane. Possible pixel sources will be defined in the
drm_plane_pixel_source enum.
The current possible pixel sources are DRM_PLANE_PIXEL_SOURCE_FB and
Since solid fill planes allow for a NULL framebuffer in a valid commit,
add NULL framebuffer checks to atomic commit calls within DPU.
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 9 ++-
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 45 +++--
Currently framebuffer checks happen directly in
drm_atomic_plane_check(). Move these checks into their own helper
method.
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/drm_atomic.c | 130 ---
1 file changed, 74 insertions(+), 56 deletions(-)
diff --git
Loosen the requirements for atomic and legacy commit so that, in cases
where solid fill planes is enabled but no FB is set, the commit can
still go through.
This includes adding framebuffer NULL checks in other areas to account
for FB being NULL when solid fill is enabled.
Signed-off-by: Jessica
Some drivers support hardware that have optimizations for solid fill
planes. This series aims to expose these capabilities to userspace as
some compositors have a solid fill flag (ex. SOLID_COLOR in the Android
hardware composer HAL) that can be set by apps like the Android Gears
app.
In order to
Add solid_fill and pixel_source properties to DPU plane
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index c2aaaded07ed..5f09
Document and add support for solid_fill property to drm_plane. In
addition, add support for setting and getting the values for solid_fill.
To enable solid fill planes, userspace must assign a property blob to
the "solid_fill" plane property containing the following information:
struct drm_solid_f
Drop DPU_PLANE_COLOR_FILL_FLAG and check the DRM solid_fill property to
determine if the plane is solid fill. In addition drop the DPU plane
color_fill field as we can now use drm_plane_state.solid_fill instead,
and pass in drm_plane_state.alpha to _dpu_plane_color_fill_pipe() to
allow userspace to
Hi,
On Tue, Jun 27, 2023 at 2:17 PM Doug Anderson wrote:
>
> Hi,
>
> On Mon, Jun 26, 2023 at 10:01 PM Cong Yang
> wrote:
> >
> > Because the setting of hproch is too small, there will be warning in
I realized that hproch should be hporch. I fixed when applying.
> > kernel log[1]. After fine t
On 30/06/2023 03:25, Jessica Zhang wrote:
Add support for pixel_source property to drm_plane and related
documentation.
This enum property will allow user to specify a pixel source for the
plane. Possible pixel sources will be defined in the
drm_plane_pixel_source enum.
The current possible pix
On 30/06/2023 03:25, Jessica Zhang wrote:
Currently framebuffer checks happen directly in
drm_atomic_plane_check(). Move these checks into their own helper
method.
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/drm_atomic.c | 130 ---
1 file changed,
On 30/06/2023 03:25, Jessica Zhang wrote:
Loosen the requirements for atomic and legacy commit so that, in cases
where solid fill planes is enabled but no FB is set, the commit can
still go through.
This includes adding framebuffer NULL checks in other areas to account
for FB being NULL when sol
On 30/06/2023 03:25, Jessica Zhang wrote:
Add solid_fill and pixel_source properties to DPU plane
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 2 ++
1 file changed, 2 insertions(+)
This should be the last commit.
Otherwise:
Reviewed-by: Dmitry Baryshkov
On 30/06/2023 03:25, Jessica Zhang wrote:
Since solid fill planes allow for a NULL framebuffer in a valid commit,
add NULL framebuffer checks to atomic commit calls within DPU.
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 9 ++-
drivers/gpu/drm/msm/disp/d
On 30/06/2023 03:25, Jessica Zhang wrote:
Drop DPU_PLANE_COLOR_FILL_FLAG and check the DRM solid_fill property to
determine if the plane is solid fill. In addition drop the DPU plane
color_fill field as we can now use drm_plane_state.solid_fill instead,
and pass in drm_plane_state.alpha to _dpu_p
After recent discussions with Mesa folks, it was requested
that we optimize i915's GET_PARAM for the PXP_STATUS without
changing the UAPI spec.
Add these additional optimizations:
- If any PXP initializatoin flow failed, then ensure that
we catch it so that we can change the returned PXP_S
Hi,
On 2023/6/30 01:44, Limonciello, Mario wrote:
[Public]
-Original Message-
From: 15330273...@189.cn <15330273...@189.cn>
Sent: Thursday, June 29, 2023 12:00 PM
To: Bjorn Helgaas ; Sui Jingfeng
Cc: Bjorn Helgaas ; linux-fb...@vger.kernel.org;
Cornelia Huck ; Karol Herbst ;
nouv...@l
On 2023/6/29 14:37, Christian König wrote:
> This has already been fixed with:
>
> commit 2ce977df10c179138e2723b25c2d2c055a3e3cc6
> Author: Ma Jun
> Date: Wed May 31 13:30:51 2023 +0800
>
> drm/ttm: Remove redundant code in ttm_tt_init_fields
>
> Remove redundant assignment code for
The variable crtc->state->event is often protected by the lock
crtc->dev->event_lock when is accessed. However, it is accessed as a
condition of an if statement in exynos_drm_crtc_atomic_disable() without
holding the lock:
if (crtc->state->event && !crtc->state->active)
However, if crtc->stat
On 6/29/2023 5:20 PM, Dmitry Baryshkov wrote:
On 29/06/2023 22:29, Abhinav Kumar wrote:
Instead of using a feature bit to decide whether to enable data
compress or not for DSC use-cases, use dpu core's major version instead.
This will avoid defining feature bits for every bit level details of
On 6/29/2023 5:13 PM, Dmitry Baryshkov wrote:
On 29/06/2023 22:29, Abhinav Kumar wrote:
With [1] dpu core revision was dropped in favor of using the
compatible string from the device tree to select the dpu catalog
being used in the device.
This approach works well however also necessitates a
On 6/29/2023 5:24 PM, Dmitry Baryshkov wrote:
On 29/06/2023 22:29, Abhinav Kumar wrote:
With [1] dpu core revision was dropped in favor of using the
compatible string from the device tree to select the dpu catalog
being used in the device.
This approach works well however also necessitates a
On 30/06/2023 06:17, Abhinav Kumar wrote:
On 6/29/2023 5:24 PM, Dmitry Baryshkov wrote:
On 29/06/2023 22:29, Abhinav Kumar wrote:
With [1] dpu core revision was dropped in favor of using the
compatible string from the device tree to select the dpu catalog
being used in the device.
This appro
On 30/06/2023 06:07, Abhinav Kumar wrote:
On 6/29/2023 5:20 PM, Dmitry Baryshkov wrote:
On 29/06/2023 22:29, Abhinav Kumar wrote:
Instead of using a feature bit to decide whether to enable data
compress or not for DSC use-cases, use dpu core's major version instead.
This will avoid defining f
On 6/29/2023 8:22 PM, Dmitry Baryshkov wrote:
On 30/06/2023 06:07, Abhinav Kumar wrote:
On 6/29/2023 5:20 PM, Dmitry Baryshkov wrote:
On 29/06/2023 22:29, Abhinav Kumar wrote:
Instead of using a feature bit to decide whether to enable data
compress or not for DSC use-cases, use dpu core's
Hi,
On 2023/6/30 01:44, Limonciello, Mario wrote:
I think what you can do is pick up all the tags in your next version. Once the
whole series has tags we can discuss how it merges.
Yes, you are right.
I will prepare the next version.
But I think, I should only gather the reverent part toget
T.J. has been responsible for dmab-buf items on the Android team
for awhile now, so it would be great to have him on as a reviewer.
Cc: T.J. Mercier
Cc: Sumit Semwal
Cc: Benjamin Gaignard
Cc: Brian Starkey
Cc: John Stultz
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc:
Hi John,
On Fri, 30 Jun 2023 at 10:22, John Stultz wrote:
>
> T.J. has been responsible for dmab-buf items on the Android team
> for awhile now, so it would be great to have him on as a reviewer.
>
> Cc: T.J. Mercier
> Cc: Sumit Semwal
> Cc: Benjamin Gaignard
> Cc: Brian Starkey
> Cc: John St
101 - 151 of 151 matches
Mail list logo
