On Fri, Jun 14, 2024 at 01:55:46AM GMT, Konrad Dybcio wrote:
>
>
> On 6/13/24 17:15, Marc Gonzalez wrote:
> > From: Arnaud Vrac
> >
> > Port device nodes from vendor code.
> >
> > Signed-off-by: Arnaud Vrac
> > Reviewed-by: Dmitry Baryshkov
> > Signed-off-by: Marc Gonzalez
> > ---
>
> [...
On Thu, Jun 13, 2024 at 04:19:07PM GMT, Abhinav Kumar wrote:
>
>
> On 6/13/2024 3:36 PM, Dmitry Baryshkov wrote:
> > Move a call to dpu_format_populate_plane_sizes() to the atomic_check
> > step, so that any issues with the FB layout can be reported as early as
> > possible.
> >
> > Signed-off-b
On 6/11/24 5:17 PM, T.J. Mercier wrote:
On Tue, Jun 11, 2024 at 2:35 AM wrote:
From: Carsten Haitzler
In a few places (core drm + AMD kfd driver), the ioctl handling uses a
temporary 128 byte buffer on the stack to copy to/from user. ioctl data
can have structs with types of much larger s
On 24/03/2024 10:15, Thadeu Lima de Souza Cascardo wrote:
commit e531fdb5cd5e ("dma-buf/sw_sync: Avoid recursive lock during fence
signal") fixed a recursive locking when a signal callback released a fence.
It did it by taking an extra reference while traversing it on the list and
holding the t
On Thu, Jun 13, 2024 at 08:10:17PM +0800, Yafang Shao wrote:
> On Thu, Jun 13, 2024 at 4:37 PM Catalin Marinas
> wrote:
> > On Thu, Jun 13, 2024 at 10:30:40AM +0800, Yafang Shao wrote:
> > > Using __get_task_comm() to read the task comm ensures that the name is
> > > always NUL-terminated, regard
On Thu, 2024-06-13 at 16:57 -0500, Bjorn Helgaas wrote:
> On Thu, Jun 13, 2024 at 01:50:13PM +0200, Philipp Stanner wrote:
> > Changes in v9:
> > - Remove forgotten dead code ('enabled' bit in struct pci_dev) in
> > patch No.8 ("Move pinned status bit...")
> > - Rework patch No.3:
> >
From: Carsten Haitzler
In a few places (core drm + AMD kfd driver), the ioctl handling uses a
temporary 128 byte buffer on the stack to copy to/from user. ioctl data
can have structs with types of much larger sizes than a byte and a
system may require alignment of types in these. At the same time
Hi Jocelyn,
On Fri, Jun 14, 2024 at 11:55 AM Jocelyn Falempe wrote:
> On 13/06/2024 21:18, Geert Uytterhoeven wrote:
> > Re-use the existing support for boot-up logos to draw a monochrome
> > graphical logo in the DRM panic handler. When no suitable graphical
> > logo is available, the code fall
On 2024-06-13 10:38 pm, Sebastian Reichel wrote:
Hi,
On Thu, Jun 13, 2024 at 11:34:02AM GMT, Tomeu Vizoso wrote:
On Thu, Jun 13, 2024 at 11:24 AM Tomeu Vizoso wrote:
On Thu, Jun 13, 2024 at 2:05 AM Sebastian Reichel
wrote:
On Wed, Jun 12, 2024 at 03:52:55PM GMT, Tomeu Vizoso wrote:
IOMMUs
Add offset and size parameters to ttm_bo_vmap() to allow for partial
mappings of a buffer object. This brings the functionality on par with
ttm_bo_kmap().
Callers pass the byte offset and size within the buffer object and
receive a page-aligned mapping of the buffer object's memory for the
specifi
Add the public field alloc_flags to struct iosys_map. It allows for
the allocator of the mapping to store additional flags, such details
about the internal alloctor operations. This will be helpful with
DRM's TTM memory manager, which supports various types of memory in
it's vmap functions.
The ne
In ttm_bo_vmap(), set up single-page mappings with kmap() in certain
cases. The feature is already present in ttm_bo_kmap().
This functionality is require by DRM's xe driver, which claims that
using kmap() is an optimization over vmap(). [1] Reading the commit
at [2] indicates otherwise. It is not
Use the newer ttm_bo_vmap() instead of ttm_bo_kmap(). The new interface
uses struct iomap_map, which helps with pointer setup and memcpy() ops.
Removes a TODO item and quite a bit of workarounds from the code.
Signed-off-by: Thomas Zimmermann
---
.../compat-i915-headers/gem/i915_gem_object.h | 1
For each instances of struct iosys_map set up by ttm_bo_vmap(), store
the type of allocation in the instance. Use this information to unmap
the memory in ttm_bo_vunmap(). This change simplifies the unmap code
and puts the complicated logic entirely into the map code.
Signed-off-by: Thomas Zimmerma
[AMD Official Use Only - AMD Internal Distribution Only]
> -Original Message-
> From: Thomas Zimmermann
> Sent: Wednesday, June 12, 2024 9:26 AM
> To: Linux regressions mailing list
> Cc: Petkov, Borislav ;
> zack.ru...@broadcom.com; dmitry.osipe...@collabora.com; Kaplan, David
> ; Koeni
Move calls to unmap the buffer-object memory from the object-release
code in xe_gem_object_free() to the caller of the release.
Doing an unmap for a BO requires holding the reservation lock, which
is not allowed while releasing a GEM object. Without the reservation
lock, TTM can concurrently evict
Add ttm_bo_kmap()'s features to ttm_bo_vmap() and convert xe to
use the latter helper. ttm_bo_vmap() returns mappings in an instance
of struct iosys_map, which simplifies driver code in several places.
Patches 1 and 2 allow ttm_bo_vmap() to store the method of allocation
in the iosys_map instance.
On 6/14/2024 03:15, Thomas Zimmermann wrote:
Hi Mario
Am 13.06.24 um 07:17 schrieb Mario Limonciello:
If the lid on a laptop is closed when eDP connectors are populated
then it remains enabled when the initial framebuffer configuration
is built.
When creating the initial framebuffer configurat
Hi
Am 14.06.24 um 15:47 schrieb Mario Limonciello:
On 6/14/2024 03:15, Thomas Zimmermann wrote:
Hi Mario
Am 13.06.24 um 07:17 schrieb Mario Limonciello:
If the lid on a laptop is closed when eDP connectors are populated
then it remains enabled when the initial framebuffer configuration
is bui
On 6/14/2024 09:17, Thomas Zimmermann wrote:
Hi
Am 14.06.24 um 15:47 schrieb Mario Limonciello:
On 6/14/2024 03:15, Thomas Zimmermann wrote:
Hi Mario
Am 13.06.24 um 07:17 schrieb Mario Limonciello:
If the lid on a laptop is closed when eDP connectors are populated
then it remains enabled whe
Am 14.06.24 um 15:21 schrieb Thomas Zimmermann:
Add offset and size parameters to ttm_bo_vmap() to allow for partial
mappings of a buffer object. This brings the functionality on par with
ttm_bo_kmap().
Well the long term plan was to remove this functionality from
ttm_bo_kmap() and nuke that f
Am 14.06.24 um 15:21 schrieb Thomas Zimmermann:
For each instances of struct iosys_map set up by ttm_bo_vmap(), store
the type of allocation in the instance. Use this information to unmap
the memory in ttm_bo_vunmap(). This change simplifies the unmap code
and puts the complicated logic entirely
Currently, the init_code of the jd9365da driver is placed
in the enable() function and sent, but this seems to take
a long time. It takes 17ms to send each instruction (an init
code consists of about 200 instructions), so it takes
about 3.5s to send the init_code. So we moved the sending
of the int
This kingdisplay panel uses the jd9365da controller, so add it to
panel-jadard-jd9365da-h3.c driver, but because the init_code and timing
are different, some variables are added in struct jadard_panel_des to
control it.
In addition, since sending init_code in the enable() function takes a long
The kingdisplay-kd101ne3 is a 10.1" WXGA TFT-LCD panel with
jadard-jd9365da controller. Hence, we add a new compatible
with panel specific config.
Signed-off-by: Zhaoxiong Lv
---
Chage since V3:
- 1. Abandon the V2 patch and add kingdisplay kd101ne3-40ti binding to
-jadard,jd9365da-h3.yaml
This add the bindings for the 1280x800 TFT LCD Starry-er88577 DSI panel
to panel-simple-dsi.
Signed-off-by: Zhaoxiong Lv
---
Chage since V3:
- Separate the Starry bindings from kingdisplay, and add it to
panel-simple-dsi.yaml
v2:
https://lore.kernel.org/all/20240601084528.22502-4-lvzhaoxi..
The bias IC of this starry-er88577 panel is placed
on the panel side, so when the panel is powered on,
there is no need to control AVDD and AVEE in the driver,
only 3.3v and reset are needed.
Signed-off-by: Zhaoxiong Lv
---
Chage since V3:
- Separate Starry-er88577 from the panel-kingdisplay-
This driver does not have the function to adjust the orientation,
so this function is added.
Signed-off-by: Zhaoxiong Lv
---
drivers/gpu/drm/panel/panel-jadard-jd9365da-h3.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-jadard-jd
The K&d kd101ne3-40ti is a 10.1" WXGA TFT-LCD panel, use
jd9365da controller,which fits in nicely with the existing
panel-jadard-jd9365da-h3 driver.Hence,we add a new compatible
with panel specific config.
Although they have the same control IC, the two panels are different,
and the timing will be
The Starry is a 10.1" WXGA TFT LCD panel with er88577 controller
Because Starry-er88577 and kingdisplay-kd101ne3 are not the same IC,
separate Starry-er88577 from the panel-kingdisplay-kd101ne3 driver.
Changes in v3:
- PATCH 1/2: This add the bindings to panel-simple-dsi.
- PATCH 2/2: Add a separ
I guess sparse and potential CI errors won't minimally relate to
this patch.
Adding also Jonathan in Cc :-)
Thanks,
Andi
On Fri, Jun 14, 2024 at 12:28:37AM +0200, Andi Shyti wrote:
> Replace "dynmically" with "dynamically".
>
> Signed-off-by: Andi Shyti
> Cc: John Harrison
> ---
> drivers/gp
-Original Message-
From: Andi Shyti
Sent: Friday, June 14, 2024 8:22 AM
To: Andi Shyti
Cc: intel-gfx ; dri-devel
; Harrison, John C
; Cavitt, Jonathan
Subject: Re: [PATCH] drm/i915/gt/uc: Fix typo in comment
>
> I guess sparse and potential CI errors won't minimally relate to
> this
AMD hardware can do async flips with overlay planes, but currently there's no
easy way to enable that in DRM. To solve that, this patchset creates a new
drm_plane field, bool async_flip, that allows drivers to choose which plane can
or cannot do async flips. This is latter used on drm_atomic_set_pr
Allow userspace to use explicit synchronization with atomic async flips.
That means that the flip will wait for some hardware fence, and then
will flip as soon as possible (async) in regard of the vblank.
Signed-off-by: André Almeida
---
drivers/gpu/drm/drm_atomic_uapi.c | 4 +++-
1 file changed
This driver can perfom async flips on primary planes, so enable it.
Signed-off-by: André Almeida
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
b/drivers/gpu/drm/amd/display/
This driver can perfom async flips on primary planes, so enable it.
Signed-off-by: André Almeida
---
drivers/gpu/drm/nouveau/dispnv04/crtc.c | 4
drivers/gpu/drm/nouveau/dispnv50/wndw.c | 4
2 files changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
b/drive
This driver can perfom async flips on primary planes, so enable it.
Signed-off-by: André Almeida
---
drivers/gpu/drm/vc4/vc4_plane.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index 07caf2a47c6c..e3d41d
amdgpu can handle async flips on overlay planes, so mark it as true
during the plane initialization.
Signed-off-by: André Almeida
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.
This driver can perfom async flips on primary planes, so enable it.
Signed-off-by: André Almeida
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_p
Drivers have different capabilities on what plane types they can or
cannot perform async flips. Create a plane::async_flip field so each
driver can choose which planes they allow doing async flips.
Signed-off-by: André Almeida
---
drivers/gpu/drm/drm_atomic_uapi.c | 4 ++--
include/drm/drm_plane
This driver can perfom async flips on primary planes, so enable it.
Signed-off-by: André Almeida
---
drivers/gpu/drm/i915/display/i9xx_plane.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/i9xx_plane.c
b/drivers/gpu/drm/i915/display/i9xx_plane.c
index 0279c
On 2024-06-13 18:22, Nathan Chancellor wrote:
> Hi Palmer (and AMD folks),
>
> On Tue, Jun 04, 2024 at 09:04:23AM -0700, Palmer Dabbelt wrote:
>> On Mon, 03 Jun 2024 15:29:48 PDT (-0700), nat...@kernel.org wrote:
>>> On Thu, May 30, 2024 at 07:57:42AM -0700, Palmer Dabbelt wrote:
From: Pal
On 6/13/24 12:16, Alexey Makhalov wrote:
> +unsigned long vmware_tdx_hypercall(unsigned long cmd,
> +unsigned long in1, unsigned long in3,
> +unsigned long in4, unsigned long in5,
> +u32 *out1, u32 *out2
On 14/06/2024 10:53, Christian König wrote:
if (domain & abo->preferred_domains &
AMDGPU_GEM_DOMAIN_VRAM &&
- !(adev->flags & AMD_IS_APU))
- places[c].flags |= TTM_PL_FLAG_FALLBACK;
+ !(adev->flags & AMD_IS_APU)) {
+ /*
+ * Wh
"struct nouveau_job_ops" is not modified in these drivers.
Constifying this structure moves some data to a read-only section, so
increase overall security.
In order to do it, "struct nouveau_job" and "struct nouveau_job_args" also
need to be adjusted to this new const qualifier.
On a x86_64, wit
On Fri, Jun 14, 2024 at 10:09:46AM +0200, Philipp Stanner wrote:
> On Thu, 2024-06-13 at 16:06 -0500, Bjorn Helgaas wrote:
> > On Thu, Jun 13, 2024 at 01:50:23PM +0200, Philipp Stanner wrote:
> > > pci_intx() is one of the functions that have "hybrid mode" (i.e.,
> > > sometimes managed, sometimes
On Fri, Jun 14, 2024 at 09:03:22AM -0700, Dave Hansen wrote:
> On 6/13/24 12:16, Alexey Makhalov wrote:
> > +unsigned long vmware_tdx_hypercall(unsigned long cmd,
> > + unsigned long in1, unsigned long in3,
> > + unsigned long in4, unsigned
On Fri, Jun 14, 2024 at 01:38:41PM +0200, Philipp Stanner wrote:
> On Thu, 2024-06-13 at 16:57 -0500, Bjorn Helgaas wrote:
> > This is on pci/devres with some commit log rework and the following
> > diffs. I think the bar short/int thing is the only actual code
> > change. Happy to squash in any
On Fri, Jun 14, 2024 at 10:55:07PM GMT, Zhaoxiong Lv wrote:
> Currently, the init_code of the jd9365da driver is placed
> in the enable() function and sent, but this seems to take
> a long time. It takes 17ms to send each instruction (an init
> code consists of about 200 instructions), so it takes
On 6/12/2024 7:52 AM, Tomeu Vizoso wrote:
This initial version supports the NPU as shipped in the RK3588 SoC and
described in the first part of its TRM, in Chapter 36.
This NPU contains 3 independent cores that the driver can submit jobs
to.
This commit adds just hardware initialization and pow
On 6/14/24 09:14, Borislav Petkov wrote:
> On Fri, Jun 14, 2024 at 09:03:22AM -0700, Dave Hansen wrote:
...
>> You need to zero out all of 'args' somehow.
>
> You mean like this:
>
> struct tdx_module_args args = {};
>
> ?
Yes, or do all the assignments with the initializer. We seem to d
On 6/12/2024 7:53 AM, Tomeu Vizoso wrote:
This uses the SHMEM DRM helpers and we map right away to the CPU and NPU
sides, as all buffers are expected to be accessed from both.
Signed-off-by: Tomeu Vizoso
Reviewed-by: Jeffrey Hugo
On Fri, 14 Jun 2024 at 02:02, Pavel Machek wrote:
>
> If I can get at least basic metric on the gpu (%idle? which process
> use how much time?), it might be feasible. Is there tool similar for
> top?
Let's bring in the actual gpu people.. Dave/Jani/others - does any of
this sound familiar? Pavel
Add job that runs igt on top of vkms.
Acked-by: Maíra Canal
Acked-by: Helen Koike
Signed-off-by: Vignesh Raman
Acked-by: Jessica Zhang
Tested-by: Jessica Zhang
Acked-by: Maxime Ripard
Signed-off-by: Helen Koike
---
v2:
- do not mv modules to /lib/modules in the job definition, leave it to
On Fri, 14 Jun 2024 03:02:19 +0300, Dmitry Baryshkov wrote:
> There are two ways to describe an eDP panel in device tree. The
> recommended way is to add a device on the AUX bus, ideally using the
> edp-panel compatible. The legacy way is to define a top-level platform
> device for the panel.
>
>
On 6/12/2024 7:53 AM, Tomeu Vizoso wrote:
Using the DRM GPU scheduler infrastructure, with a scheduler for each
core.
Userspace can decide for a series of tasks to be executed sequentially
in the same core, so SRAM locality can be taken advantage of.
The job submission code was intially based o
On Fri, Jun 14, 2024 at 10:55:08PM GMT, Zhaoxiong Lv wrote:
> The kingdisplay-kd101ne3 is a 10.1" WXGA TFT-LCD panel with
> jadard-jd9365da controller. Hence, we add a new compatible
> with panel specific config.
>
> Signed-off-by: Zhaoxiong Lv
> ---
> Chage since V3:
>
> - 1. Abandon the V2 pat
On 6/12/2024 7:53 AM, Tomeu Vizoso wrote:
diff --git a/include/uapi/drm/rocket_accel.h b/include/uapi/drm/rocket_accel.h
index 888c9413e4cd..1539af0af4fe 100644
--- a/include/uapi/drm/rocket_accel.h
+++ b/include/uapi/drm/rocket_accel.h
@@ -12,9 +12,13 @@ extern "C" {
#endif
#define DRM_RO
On Fri, Jun 14, 2024 at 08:38:51AM +0200, Jan Beulich wrote:
> On 13.06.2024 20:43, Demi Marie Obenour wrote:
> > GPU acceleration requires that pageable host memory be able to be mapped
> > into a guest.
>
> I'm sure it was explained in the session, which sadly I couldn't attend.
> I've been aski
On 14/06/2024 13:18, Vignesh Raman wrote:
Add job that runs igt on top of vkms.
Acked-by: Maíra Canal
Acked-by: Helen Koike
Signed-off-by: Vignesh Raman
Acked-by: Jessica Zhang
Tested-by: Jessica Zhang
Acked-by: Maxime Ripard
Signed-off-by: Helen Koike
---
v2:
- do not mv modules to /
On 13/06/2024 14:55, Dmitry Baryshkov wrote:
On Thu, 13 Jun 2024 at 20:49, Abhinav Kumar wrote:
On 6/13/2024 9:33 AM, Dmitry Baryshkov wrote:
The commit b228501ff183 ("drm/msm: merge dpu format database to MDP
formats") made get_format take modifiers into account. This makes
kms_addfb_ba
On Fri, 14 Jun 2024 at 09:21, Linus Torvalds
wrote:
>
> Let's bring in the actual gpu people.. Dave/Jani/others - does any of
> this sound familiar? Pavel says things have gotten much slower in
> 6.10: "something was very wrong with the performance, likely to do
> with graphics"
Actually, maybe i
On Fri, Jun 14, 2024 at 10:55:09PM GMT, Zhaoxiong Lv wrote:
> The K&d kd101ne3-40ti is a 10.1" WXGA TFT-LCD panel, use
> jd9365da controller,which fits in nicely with the existing
> panel-jadard-jd9365da-h3 driver.Hence,we add a new compatible
> with panel specific config.
>
> Although they have t
Am 14.06.24 um 16:55 schrieb Zhaoxiong Lv:
Currently, the init_code of the jd9365da driver is placed
in the enable() function and sent, but this seems to take
a long time. It takes 17ms to send each instruction (an init
code consists of about 200 instructions), so it takes
about 3.5s to send the
On Fri, Jun 14, 2024 at 10:56:09PM GMT, Zhaoxiong Lv wrote:
> The bias IC of this starry-er88577 panel is placed
> on the panel side, so when the panel is powered on,
> there is no need to control AVDD and AVEE in the driver,
> only 3.3v and reset are needed.
>
> Signed-off-by: Zhaoxiong Lv
>
>
On Fri, Jun 14, 2024 at 12:35:29PM GMT, André Almeida wrote:
> Drivers have different capabilities on what plane types they can or
> cannot perform async flips. Create a plane::async_flip field so each
> driver can choose which planes they allow doing async flips.
>
> Signed-off-by: André Almeida
On Fri, Jun 14, 2024 at 12:35:27PM GMT, André Almeida wrote:
> AMD hardware can do async flips with overlay planes, but currently there's no
> easy way to enable that in DRM. To solve that, this patchset creates a new
> drm_plane field, bool async_flip, that allows drivers to choose which plane
>
Add a DRM core helper to dump the DSC state and take this into use in
the i915 driver to dump the state to dmesg after state computation and
HW readout as well as to the i915_display_info debugfs entry. The state
contains an x16 fixed point value, so also move the corresponding
bpp_x16 helpers from
Add a helper to dump the Display Stream Compression configuration, taken
into use in the i915 driver by a later patch.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/display/drm_dsc_helper.c | 91
include/drm/display/drm_dsc_helper.h | 3 +
2 files changed, 94 inserti
Add helpers to convert between x16 fixed point and integer/fraction
values. Also add the format/argument macros required to printk x16
fixed point variables.
These are needed by later patches dumping the Display Stream Compression
configuration in DRM core and in the i915 driver to replace the
cor
Replace to_bpp_frac() defined by the driver with the equivalent
drm_x16_to_frac() defined by DRM core.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_display_types.h | 7 +--
drivers/gpu/drm/i915/display/intel_dp.c| 4 ++--
drivers/gpu/drm/i915/display/intel_vdsc
Dump the DSC state to dmesg during HW readout and state computation as
well as the i915_display_info debugfs entry.
Signed-off-by: Imre Deak
---
.../drm/i915/display/intel_crtc_state_dump.c | 3 +++
.../drm/i915/display/intel_display_debugfs.c | 4
drivers/gpu/drm/i915/display/intel_vds
Replace to_bpp_int() defined by the driver with the equivalent
drm_x16_from_int() defined by DRM core.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/icl_dsi.c | 9 +
drivers/gpu/drm/i915/display/intel_display.c | 3 ++-
drivers/gpu/drm/i915/display/intel_dis
Replace to_bpp_int_roundup() defined by the driver with the equivalent
drm_x16_to_int_roundup() defined by DRM core.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 4 +++-
drivers/gpu/drm/i915/display/intel_display_types.h | 5 -
drivers/gpu/drm/i915/displa
Replace to_bpp_x16() defined by the driver with the drm_x16_from_int()
defined by DRM core.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_bios.c | 5 +++--
.../gpu/drm/i915/display/intel_display_types.h | 5 -
drivers/gpu/drm/i915/display/intel_dp.c | 17 ++
The Display Engine's DSC register values are deducted from the DSC
configuration stored in intel_crtc_state::dsc. The latter one is
dumped in a human-readable format, so dumping the register values is
redundant, remove it.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_vdsc.c |
Replace BPP_X16_FMT()/ARGS() defined by the driver with the equivalent
DRM_X16_FMT()/ARGS() defined by DRM core.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_audio.c | 5 +++--
drivers/gpu/drm/i915/display/intel_display.c | 4 ++--
.../gpu/drm/i915/display/intel_di
On Fri, Jun 14, 2024 at 11:52:03AM +0100, Tvrtko Ursulin wrote:
>
> On 24/03/2024 10:15, Thadeu Lima de Souza Cascardo wrote:
> > commit e531fdb5cd5e ("dma-buf/sw_sync: Avoid recursive lock during fence
> > signal") fixed a recursive locking when a signal callback released a fence.
> > It did it b
On 6/14/24 9:19 AM, Dave Hansen wrote:
On 6/14/24 09:14, Borislav Petkov wrote:
On Fri, Jun 14, 2024 at 09:03:22AM -0700, Dave Hansen wrote:
...
You need to zero out all of 'args' somehow.
You mean like this:
struct tdx_module_args args = {};
?
Yes, or do all the assignments w
On 5/30/2024 12:37, Jani Nikula wrote:
On Thu, 30 May 2024, John Harrison wrote:
Except that the whole reason this was started was because Michal
absolutely refuses to allow line counted output in a sysfs/debugfs
file because "it is unnecessary and breaks the decoding tools".
I'm only looking
On 5/30/2024 14:27, Michal Wajdeczko wrote:
On 30.05.2024 20:47, John Harrison wrote:
On 5/30/2024 00:49, Jani Nikula wrote:
On Wed, 29 May 2024, John Harrison wrote:
On 5/28/2024 06:06, Michal Wajdeczko wrote:
This drm printer wrapper can be used to increase the robustness of
the captured o
tree: git://anongit.freedesktop.org/drm-intel for-linux-next-gt
head: 05da7d9f717bcb03c457379fa8a61c1689dab86c
commit: 05da7d9f717bcb03c457379fa8a61c1689dab86c [3/3] drm/i915/gem: Downgrade
stolen lmem setup warning
config: x86_64-randconfig-122-20240614
(https://download.01.org/0day-ci
On Fri, Jun 14, 2024 at 12:35:32PM -0300, André Almeida wrote:
> This driver can perfom async flips on primary planes, so enable it.
>
Cc: Ville Syrjälä
Cc: Naveen Kumar
c: Vandita Kulkarni
> Signed-off-by: André Almeida
> ---
> drivers/gpu/drm/i915/display/i9xx_plane.c | 3 +++
> 1 file ch
On Fri, Jun 14, 2024 at 11:32:16AM -0700, Alexey Makhalov wrote:
>
>
> On 6/14/24 9:19 AM, Dave Hansen wrote:
> > On 6/14/24 09:14, Borislav Petkov wrote:
> > > On Fri, Jun 14, 2024 at 09:03:22AM -0700, Dave Hansen wrote:
> > ...
> > > > You need to zero out all of 'args' somehow.
> > >
> > > Yo
Hi Dmitry,
Em 14/06/2024 14:32, Dmitry Baryshkov escreveu:
On Fri, Jun 14, 2024 at 12:35:27PM GMT, André Almeida wrote:
AMD hardware can do async flips with overlay planes, but currently there's no
easy way to enable that in DRM. To solve that, this patchset creates a new
drm_plane field, bool
Em 14/06/2024 14:32, Dmitry Baryshkov escreveu:> On Fri, Jun 14, 2024 at
12:35:29PM GMT, André Almeida wrote:
>> Drivers have different capabilities on what plane types they can or
>> cannot perform async flips. Create a plane::async_flip field so each
>> driver can choose which planes they allow
On Fri, Jun 14, 2024 at 03:23:54PM +, Cavitt, Jonathan wrote:
> -Original Message-
> From: Andi Shyti
> Sent: Friday, June 14, 2024 8:22 AM
> To: Andi Shyti
> Cc: intel-gfx ; dri-devel
> ; Harrison, John C
> ; Cavitt, Jonathan
> Subject: Re: [PATCH] drm/i915/gt/uc: Fix typo in com
On Fri, Jun 14, 2024 at 09:55:57AM +0530, Mitul Golani wrote:
> Describe newly added parameter target_rr_divider in struct
> drm_dp_as_sdp.
>
> -v2:
> Remove extra line from commit message.(Lucas)
>
> Fixes: a20c6d954d75 ("drm/dp: Add refresh rate divider to struct representing
> AS SDP")
> Cc:
(!ARM64 ||
!CC_IS_CLANG)
+ select DRM_AMD_DC_FP if ARCH_HAS_KERNEL_FPU_SUPPORT && !(CC_IS_CLANG &&
(ARM64 || RISCV))
help
Choose this option if you want to use the new display engine
support for AMDGPU. This adds required support for Vega and
---
base-c
On 5/30/2024 14:09, Michal Wajdeczko wrote:
On 30.05.2024 20:47, John Harrison wrote:
On 5/30/2024 02:33, Michal Wajdeczko wrote:
On 30.05.2024 09:49, Jani Nikula wrote:
On Wed, 29 May 2024, John Harrison wrote:
On 5/28/2024 06:06, Michal Wajdeczko wrote:
This drm printer wrapper can be use
Hi!
> > Let's bring in the actual gpu people.. Dave/Jani/others - does any of
> > this sound familiar? Pavel says things have gotten much slower in
> > 6.10: "something was very wrong with the performance, likely to do
> > with graphics"
>
> Actually, maybe it's not graphics at all. Rafael just s
>
> -Original Message-
From: Vivi, Rodrigo
Sent: Friday, June 14, 2024 12:46 PM
To: Cavitt, Jonathan
Cc: Andi Shyti ; intel-gfx
; dri-devel ;
Harrison, John C
Subject: Re: [PATCH] drm/i915/gt/uc: Fix typo in comment
>
> On Fri, Jun 14, 2024 at 03:23:54PM +, Cavitt, Jonathan wr
Hi!
> > Let's bring in the actual gpu people.. Dave/Jani/others - does any of
> > this sound familiar? Pavel says things have gotten much slower in
> > 6.10: "something was very wrong with the performance, likely to do
> > with graphics"
>
> Actually, maybe it's not graphics at all. Rafael just s
tree: git://anongit.freedesktop.org/drm-intel for-linux-next-gt
head: 05da7d9f717bcb03c457379fa8a61c1689dab86c
commit: 05da7d9f717bcb03c457379fa8a61c1689dab86c [3/3] drm/i915/gem: Downgrade
stolen lmem setup warning
config: i386-buildonly-randconfig-002-20240615
(https://download.01.org/0day-
Hi,
Le vendredi 14 juin 2024 à 10:16 -0600, Jeffrey Hugo a écrit :
> > + version = rocket_read(core, REG_PC_VERSION) + (rocket_read(core,
> > REG_PC_VERSION_NUM) & 0x);
> > + dev_info(rdev->dev, "Rockchip NPU core %d version: %d\n", core->index,
> > version);
>
> A properly working driv
On Fri, Jun 14, 2024 at 6:57 PM Catalin Marinas wrote:
>
> On Thu, Jun 13, 2024 at 08:10:17PM +0800, Yafang Shao wrote:
> > On Thu, Jun 13, 2024 at 4:37 PM Catalin Marinas
> > wrote:
> > > On Thu, Jun 13, 2024 at 10:30:40AM +0800, Yafang Shao wrote:
> > > > Using __get_task_comm() to read the ta
On Fri, Jun 14, 2024 at 08:38:51AM +0200, Jan Beulich wrote:
> On 13.06.2024 20:43, Demi Marie Obenour wrote:
> > GPU acceleration requires that pageable host memory be able to be mapped
> > into a guest.
>
> I'm sure it was explained in the session, which sadly I couldn't attend.
> I've been aski
Document the DPU hardware found on the Qualcomm SM7150 platform.
Signed-off-by: Danila Tikhonov
Reviewed-by: Krzysztof Kozlowski
---
.../bindings/display/msm/qcom,sm7150-dpu.yaml | 143 ++
1 file changed, 143 insertions(+)
create mode 100644
Documentation/devicetree/bindings/d
This series adds MDSS and DPU support for SM7150.
Changes in v3:
- Swap DPU and MDSS patches (Krzysztof)
- Add an explanation of the abbreviation DPU in patch 1 (Krzysztof)
- Switch qseed3_1_4 on qseed3_2_4 in patch 2 (Dmitry)
- Drop LM_4 and LM_5 in patch 2 (Dmitry)
- Add Krzysztof's R-b tag to p
Add definitions for the display hardware used on the Qualcomm SM7150
platform.
Signed-off-by: Danila Tikhonov
---
.../msm/disp/dpu1/catalog/dpu_5_2_sm7150.h| 335 ++
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 1 +
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 1 +
1 - 100 of 193 matches
Mail list logo
