Hi Mario,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on drm-intel/for-linux-next-fixes drm-tip/drm-tip
linus/master v6.8-rc4 next-20240216]
[If your patch is applied to the wrong git tree, kindly drop us
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: d37e1e4c52bc60578969f391fb81f947c3e83118 Add linux-next specific
files for 20240216
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202402161359.furktcoz-...@intel.com
https
Hi Mario,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on drm-intel/for-linux-next-fixes drm-tip/drm-tip
linus/master v6.8-rc4 next-20240216]
[If your patch is applied to the wrong git tree, kindly drop us
On 2/16/24 12:24, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> The newly added drm_test_buddy_alloc_contiguous() test fails to link on
> 32-bit targets because of inadvertent 64-bit calculations:
>
> ERROR: modpost: "__aeabi_uldivmod" [drivers/gpu/drm/tests/drm_buddy_test.ko]
> undefined!
On Fri, 16 Feb 2024 11:10:47 +0100, Luca Weiss wrote:
> Introduce the bindings and panel driver for the LCD panel with the model
> number 9A-3R063-1102B from DJN which is using the HX83112A driver IC. It
> is used on the Fairphone 4 smartphone.
>
> Then we can add the panel to the device dts
Adjust the encoder timing engine setup programming in the case of video
mode for YUV420 over DP to accommodate CDM.
Changes in v3:
- Move drm_display_mode's hskew division to another patch
- Minor cleanup
Changes in v2:
- Move timing engine programming to this patch
Reserve CDM blocks for DP if the mode format is YUV420. Currently this
reservation only works for writeback and DP if the format is YUV420. But
this can be easily extented to other YUV formats for DP.
Changes in v2:
- Minor code simplification
Signed-off-by: Paloma Arellano
Reviewed-by:
All the components of YUV420 over DP are added. Therefore, let's mark the
connector property as true for DP connector when the DP type is not eDP
and when there is a CDM block available.
Changes in v3:
- Move setting the connector's ycbcr_420_allowed parameter so
that it is not
Parity calculation is necessary for VSC SDP implementation. Therefore
create new files dp_utils.c and dp_utils.h and move the parity
calculating functions here. This ensures that they are usable by SDP
programming in both dp_catalog.c and dp_audio.c
Changes in v3:
- Change ordering of the
Add support to pack and send the VSC SDP packet for DP. This therefore
allows the transmision of format information to the sinks which is
needed for YUV420 support over DP.
Changes in v4:
- Remove struct msm_dp_sdp_with_parity
- Use dp_utils_pack_sdp_header() to pack the SDP
CDM block supports formats other than H1V2 for DP. Since we are now
adding support for CDM over DP, relax the checks to allow all other
formats for DP other than H1V2.
Changes in v2:
- Add fixes tag
- Move patch to top of series
Fixes: 0afac0ba6024 ("drm/msm/dpu: add dpu_hw_cdm
Change all relevant DP controller related programming for YUV420 cases.
Namely, change the pixel clock math to consider YUV420 and modify the
MVID programming to consider YUV420.
Changes in v2:
- Move configuration control programming to a different commit
- Slight code
From: Kuogee Hsieh
Introduce a peripheral flushing mechanism to decouple peripheral
metadata flushing from timing engine related flush.
Changes in v2:
- Fixed some misalignment issues
Signed-off-by: Kuogee Hsieh
Signed-off-by: Paloma Arellano
Reviewed-by: Dmitry Baryshkov
---
Adjust the encoder format programming in the case of video mode for DP
to accommodate CDM related changes.
Changes in v4:
- Remove hw_cdm check in dpu_encoder_needs_periph_flush()
- Remove hw_cdm check when getting the fmt_fourcc in
dpu_encoder_phys_vid_enable()
Changes
DP controller can be setup to operate in either SDP update flush mode or
peripheral flush mode based on the DP controller hardware version.
Starting in DP v1.2, the hardware documents require the use of
peripheral flush mode for SDP packets such as PPS OR VSC SDP packets.
In-line with this
Widebus enablement is decided by the interfaces based on their specific
checks and that already happens with DSI/DP specific helpers. Let's
invoke these helpers from dpu_encoder_is_widebus_enabled() to make it
cleaner overall.
Signed-off-by: Paloma Arellano
Reviewed-by: Dmitry Baryshkov
---
Change relevant DP controller related programming for YUV420 cases.
Program the configuration control register to indicate YUV420.
Changes in v2:
- Create a new patch only for configuration control programming
Signed-off-by: Paloma Arellano
Reviewed-by: Dmitry Baryshkov
---
Move dpu_encoder_helper_phys_setup_cdm to dpu_encoder in preparation for
implementing YUV420 over DP, which requires CDM compatibility.
Changes in v2:
- Slightly change the wording of the commit text to make clear
that YUV over DP requires CDM
Signed-off-by: Paloma Arellano
Wide bus is not supported when the mode is YUV420 in DP. In preparation
for changing the DPU programming to reflect this, the value and
assignment location of wide_bus_en for the DP submodules must be
changed. Move it from boot time in dp_init_sub_modules() to run time in
dp_display_mode_set.
Generalize dpu_encoder_helper_phys_setup_cdm to be compatible with DP.
Changes in v2:
- Minor formatting changes
- Move the modification of the dimensions for CDM setup to a new
patch
Signed-off-by: Paloma Arellano
Reviewed-by: Dmitry Baryshkov
---
Rename wide_bus_en to wide_bus_supported in dp_display_private to
correctly establish that the parameter is referencing if wide bus is
supported instead of enabled.
Signed-off-by: Paloma Arellano
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dp/dp_display.c | 42
In the DP driver, check if VSC SDP is supported and propagate this value
to dp_panel. In dp_display's dp_mode, the out_fmt_is_yuv_420 parameter
must also utilize this value since YUV420 is only allowed when VSC SDP
is supported.
Changes in v2:
- Move DP programming when VSC SDP is
Modify the output width and height parameters of hw_cdm to utilize the
physical encoder's data instead of obtaining the information from the
framebuffer. CDM is to be set up to utilize the actual output data since
at CDM setup, there is no difference between the two sources.
Changes in v2:
Setting up the timing engine when the physical encoder has a split role
neglects dividing the drm_display_mode's hskew parameter. Let's fix this
since this must also be done in preparation for implementing YUV420 over
DP.
Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
Signed-off-by:
The Chroma Down Sampling (CDM) block is a hardware component in the DPU
pipeline that includes a CSC block capable of converting RGB input from
the DPU to YUV data.
This block can be used with either HDMI, DP, or writeback interfaces.
This series adds support for the CDM block to be used with DP
On Thu, 15 Feb 2024 10:05:12 +0100, Heiko Stuebner wrote:
> Similar in setup to the ltk500hd1829, group it with this driver.
>
> Heiko Stuebner (3):
> drm/panel: ltk500hd1829: make room for more similar panels
> dt-bindings: display: ltk500hd1829: add variant compatible for
> ltk101b4029w
On Thu, 15 Feb 2024 10:04:41 +0100, Heiko Stuebner wrote:
> From: Heiko Stuebner
>
> admatec GmbH is a german supplier for industrial displays.
>
>
Applied, thanks!
Adding the link to the manufacturer Conor suggested.
[1/2] dt-bindings: vendor-prefixes: add prefix for admatec GmbH
Hi Maxime, Dave,
On Thu, Feb 15, 2024 at 5:45 PM Geert Uytterhoeven wrote:
> On Thu, Feb 15, 2024 at 5:09 PM Maxime Ripard wrote:
> On Thu, Feb 15, 2024 at 01:41:24PM +0100, Geert Uytterhoeven wrote:
> > > On Thu, 15 Feb 2024, Maxime Ripard wrote:
> > > > Matthew Auld (1):
> > > >
On 2024-02-13 01:48, Uma Shankar wrote:
> This series intends to add support for Plane Color Management for
> Intel platforms. This is based on the design which has been agreed
> upon by the community. Series implementing the design for generic
> DRM core has been sent out by Harry Wentland and
On 2/16/2024 12:31 PM, Douglas Anderson wrote:
The panel on sc7180-trogdor-wormdingler and
sc7180-trogdor-quackingstick hasn't been coming up since commit
9e15123eca79 ("drm/msm/dsi: Stop unconditionally powering up DSI hosts
at modeset"). Let's add "prepare_prev_first" as has been done for
On 2024-02-16 10:33, Mario Limonciello wrote:
> This vendor specific property has never been used by userspace
> software and conflicts with the panel_power_savings sysfs file.
> That is a compositor and user could fight over the same data.
>
> Fixes: f97e4303da16 ("drm/amd/display: add
Hi Mario,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on drm-intel/for-linux-next-fixes drm-tip/drm-tip
linus/master v6.8-rc4 next-20240216]
[If your patch is applied to the wrong git tree, kindly drop us
This reverts commit b1ae40a5db6191c42e2e45d726407096f030ee08.
The ExpressWire library introduced in commit 25ae5f5f4168 ("leds:
Introduce ExpressWire library") does not depend on NEW_LEDS, but without
this revert it would never get compiled if NEW_LEDS is not enabled.
Revert this commit to allow
LEDS_EXPRESSWIRE does not depend on NEW_LEDS in practice but still does
in Kconfig. Fix up its Kconfig entry to reflect this and fix a Kconfig
warning.
Signed-off-by: Duje Mihanović
---
Changes in v2:
- Fix checkpatch errors
- Pull Daniel's Reviewed-by
- Link to v1:
The ExpressWire library does not depend on NEW_LEDS and selecting it
from a subsystem other than LEDs may cause Kconfig warnings:
WARNING: unmet direct dependencies detected for LEDS_EXPRESSWIRE
Depends on [n]: NEW_LEDS [=n] && GPIOLIB [=y]
Selected by [y]:
- BACKLIGHT_KTD2801 [=y] &&
The commit ea489a3d983b ("drm/ci: add sc7180-trogdor-kingoftown")
dropped the msm-sc7180-skips.txt file, which disabled suspend-to-RAM
tests. However testing shows that STR tests still can fail. Restore the
skiplist, applying it to both limozeen and kingoftown machines.
Fixes: ea489a3d983b
The panel on sc7180-trogdor-wormdingler and
sc7180-trogdor-quackingstick hasn't been coming up since commit
9e15123eca79 ("drm/msm/dsi: Stop unconditionally powering up DSI hosts
at modeset"). Let's add "prepare_prev_first" as has been done for many
other DSI panels.
Fixes: 9e15123eca79
From: Arnd Bergmann
The newly added drm_test_buddy_alloc_contiguous() test fails to link on
32-bit targets because of inadvertent 64-bit calculations:
ERROR: modpost: "__aeabi_uldivmod" [drivers/gpu/drm/tests/drm_buddy_test.ko]
undefined!
ERROR: modpost: "__aeabi_ldivmod"
From: Ondrej Jirman
Identical configurations of planes can lead to different (and wrong)
layer -> pipe routing at HW level, depending on the order of atomic
plane changes.
For example:
- Layer 1 is configured to zpos 0 and thus uses pipe 0. No other layer
is enabled. This is a typical
From: Ondrej Jirman
This series refactors blender setup from individual planes to a common
place where it can be performed at once and is easier to reason about.
In the process this fixes a few bugs that allowed blender pipes to be
disabled while corresponding DRM planes were requested to be
From: Ondrej Jirman
These structs are identical, use a single struct to represent private
data for the DRM plane. This is a preparation for configuring layer
routing from the CRTC (mixer) instead of current approach of setting
up routing from individual layer's atomic_update callback.
From: Ondrej Jirman
These will be needed later on when we move layer configuration to
crtc update.
Signed-off-by: Ondrej Jirman
---
drivers/gpu/drm/sun4i/sun4i_backend.c | 4 +++-
drivers/gpu/drm/sun4i/sun4i_crtc.c| 2 +-
drivers/gpu/drm/sun4i/sun8i_mixer.c | 5 -
All the handling for the properties was present, but they
were never attached to the connector to allow userspace
to change them.
Add them to the connector.
Signed-off-by: Dave Stevenson
---
drivers/gpu/drm/vc4/vc4_vec.c | 2 ++
1 file changed, 2 insertions(+)
diff --git
The VEC supports not producing colour bursts for monochrome output.
It also has an option for disabling the chroma input to remove
chroma from the signal.
Now that there is a DRM_MODE_TV_MODE_MONOCHROME defined, plumb
this in.
Signed-off-by: Dave Stevenson
---
drivers/gpu/drm/vc4/vc4_vec.c |
From: Nick Hollinghurst
Add this as a value for enum_drm_connector_tv_mode, represented
by the string "Mono", to generate video with no colour encoding
or bursts. Define it to have no pedestal (since only NTSC-M calls
for a pedestal).
Change default mode creation to acommodate the new tv_mode
Hi All
A couple of patches to vc4, including adding a new "TV mode" enum for monochrome
output (yes we have some users who wish for monochrome).
Adding mono has raised a query here as to whether the the TV_MODE is meant to
describe the timing, or just the colour encoding.
The description for
From: John Harrison
The above w/a is required for every platform that the i915 driver
supports. It is fixed on the latest platforms but they are only
supported by Xe instead of i915. So just remove the platform check
completely and keep the code simple.
Signed-off-by: John Harrison
---
On Fri, Feb 16, 2024 at 10:42 AM Christian König
wrote:
>
> Am 16.02.24 um 16:12 schrieb Mario Limonciello:
> > On 2/16/2024 09:05, Harry Wentland wrote:
> >>
> >>
> >> On 2024-02-16 09:47, Christian König wrote:
> >>> Am 16.02.24 um 15:42 schrieb Mario Limonciello:
> On 2/16/2024 08:38,
labs.org/project/devicetree-bindings/patch/20240216-x1e80100-display-v3-2-28b1c33ac...@linaro.org
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make s
On 2/13/24 19:09, Dan Carpenter wrote:
If gf100_bar_new_() fails then "bar" is not initialized.
Fixes: 5bf0257136a2 ("drm/nouveau/mmu/r535: initial support")
Signed-off-by: Dan Carpenter
Applied to drm-misc-fixes, thanks!
---
It looks like this was intended to handle a failure from the
On 2/13/24 10:57, Arnd Bergmann wrote:
From: Arnd Bergmann
clang-16 warns about casting between incompatible function types:
drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c:161:10: error: cast from
'void (*)(const struct firmware *)' to 'void (*)(void *)' converts to
incompatible function
On Fri, Feb 16, 2024 at 05:51:59PM +0100, Christian König wrote:
> Am 16.02.24 um 17:32 schrieb Daniel Vetter:
> > On Tue, Feb 13, 2024 at 04:50:26PM +0100, Pierre-Eric Pelloux-Prayer wrote:
> > > This new event can be used to trace where a given dma_fence is added
> > > as a dependency of some
On 16/02/2024 16:57, Daniel Vetter wrote:
On Wed, Feb 14, 2024 at 01:52:05PM +, Steven Price wrote:
Hi Adrián,
On 14/02/2024 12:14, Adrián Larumbe wrote:
A driver user expressed interest in being able to access engine usage stats
through fdinfo when debugfs is not built into their
On 2023-12-19 23:03, Sam Ravnborg via B4 Relay wrote:
> From: Sam Ravnborg
>
> With only LEON supported there is no need to run-time patch
> the instructions to match ASI.
>
> Move a few functions back to C with inline asm, now that
> run-time patching is not needed.
>
> Deleted a few
On Fri, Feb 16, 2024 at 06:04:43PM +0100, Daniel Vetter wrote:
> On Thu, Feb 15, 2024 at 06:11:16PM +0800, Hsiao Chien Sung wrote:
> > Register CRC related function pointers to support
> > CRC retrieval.
> >
> > Signed-off-by: Hsiao Chien Sung
> > ---
> > drivers/gpu/drm/mediatek/mtk_drm_crtc.c
Hi Mario,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on drm-intel/for-linux-next-fixes drm-tip/drm-tip
linus/master v6.8-rc4 next-20240216]
[If your patch is applied to the wrong git tree, kindly drop us
The pull request you sent on Fri, 16 Feb 2024 17:20:39 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2024-02-16
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/ca6a62f9fe23713ea2b58a256a1ab27b9cc5a05a
Thank you!
--
Deet-doot-dot, I am a bot.
On Tue, Feb 13, 2024 at 12:15:11PM +0100, Jiri Slaby (SUSE) wrote:
> agp_bridge_data::type is unused (and I cannot find when was used last).
>
> Therefore, remove it.
>
> Found by https://github.com/jirislaby/clang-struct.
>
> Signed-off-by: Jiri Slaby (SUSE)
> Cc: David Airlie
> Cc:
On Thu, Feb 15, 2024 at 06:11:16PM +0800, Hsiao Chien Sung wrote:
> Register CRC related function pointers to support
> CRC retrieval.
>
> Signed-off-by: Hsiao Chien Sung
> ---
> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 239
> drivers/gpu/drm/mediatek/mtk_drm_crtc.h
This patchset adds support for display for X1E80100.
The support for embedded DisplayPort on this platform will not
be enabled using the connetor type from driver match data,
but through some 'is-edp' property via DT. This subsequent work
will be part of a separate patchset.
Signed-off-by: Abel
Add definitions for the display hardware used on the Qualcomm X1E80100
platform.
Co-developed-by: Abhinav Kumar
Signed-off-by: Abhinav Kumar
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Abel Vesa
---
.../drm/msm/disp/dpu1/catalog/dpu_9_2_x1e80100.h | 449 +
Add support for MDSS on X1E80100.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Abel Vesa
---
drivers/gpu/drm/msm/msm_mdss.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_mdss.c b/drivers/gpu/drm/msm/msm_mdss.c
index 35423d10aafa..6eda501e2a1a 100644
Document the DPU for Qualcomm X1E80100 platform in the SM8650 schema, as
they are similar.
Signed-off-by: Abel Vesa
---
Documentation/devicetree/bindings/display/msm/qcom,sm8650-dpu.yaml | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
Document the MDSS hardware found on the Qualcomm X1E80100 platform.
Reviewed-by: Krzysztof Kozlowski
Signed-off-by: Abel Vesa
---
.../bindings/display/msm/qcom,x1e80100-mdss.yaml | 253 +
1 file changed, 253 insertions(+)
diff --git
Applied. Thanks.
Alex
On Fri, Feb 16, 2024 at 5:38 AM Ilpo Järvinen
wrote:
>
> On Thu, 15 Feb 2024, Deucher, Alexander wrote:
>
> > [Public]
> >
> > > -Original Message-
> > > From: Ilpo Järvinen
> > > Sent: Thursday, February 15, 2024 8:32 AM
> > > To: Deucher, Alexander ; amd-
> > >
On Wed, Feb 14, 2024 at 01:52:05PM +, Steven Price wrote:
> Hi Adrián,
>
> On 14/02/2024 12:14, Adrián Larumbe wrote:
> > A driver user expressed interest in being able to access engine usage stats
> > through fdinfo when debugfs is not built into their kernel. In the current
> >
[AMD Official Use Only - General]
Hi Rohit,
Thanks for the patch.
> -Original Message-
> From: dri-devel On Behalf Of
> Rohit Visavalia
> Sent: Friday, February 16, 2024 1:41 PM
> To: gre...@linuxfoundation.org; laurent.pinch...@ideasonboard.com;
> maarten.lankho...@linux.intel.com;
Am 16.02.24 um 17:32 schrieb Daniel Vetter:
On Tue, Feb 13, 2024 at 04:50:26PM +0100, Pierre-Eric Pelloux-Prayer wrote:
This new event can be used to trace where a given dma_fence is added
as a dependency of some other work.
How?
What I'd expected here is that you add a dependency chain from
On Mon, Feb 12, 2024 at 01:27:57PM +0200, Jani Nikula wrote:
> On Sat, 10 Feb 2024, Mario Limonciello wrote:
> > On 2/9/2024 12:57, Daniel Vetter wrote:
> >> On Fri, Feb 09, 2024 at 09:34:13AM -0600, Mario Limonciello wrote:
> >>> On 2/9/2024 05:07, Daniel Vetter wrote:
> On Thu, Feb 08,
On Fri, 16 Feb 2024 17:37:23 +0100
Daniel Vetter wrote:
> > > @@ -1503,6 +1504,24 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
> > > drm_mode_object_put(obj);
> > > }
> > >
> > > + if (trace_drm_mode_atomic_commit_enabled()) {
> > > + struct drm_crtc_state
Applied. Thanks!
On Mon, Feb 12, 2024 at 8:08 PM Armin Wolf wrote:
>
> After destroying dmub_srv, the memory associated with it is
> not freed, causing a memory leak:
>
> unreferenced object 0x896302b45800 (size 1024):
> comm "(udev-worker)", pid 222, jiffies 4294894636
> hex dump
On Tue, Feb 13, 2024 at 06:39:20PM +0100, Danilo Krummrich wrote:
> On 2/9/24 19:52, Daniel Vetter wrote:
> > On Fri, Feb 09, 2024 at 06:41:32PM +0100, Danilo Krummrich wrote:
> > > On 2/6/24 15:03, Daniel Vetter wrote:
> > > > On Mon, Feb 05, 2024 at 11:00:04PM +0100, Danilo Krummrich wrote:
> >
On 2/14/2024 1:13 AM, Jacek Lawrynowicz wrote:
VPU was renamed to NPU but due to large overhead of renaming
all the sources only user visible messages are being updated.
Signed-off-by: Jacek Lawrynowicz
Reviewed-by: Jeffrey Hugo
On Tue, Feb 13, 2024 at 11:20:17AM -0500, Steven Rostedt wrote:
> On Tue, 13 Feb 2024 16:50:31 +0100
> Pierre-Eric Pelloux-Prayer wrote:
>
> > @@ -1503,6 +1504,24 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
> > drm_mode_object_put(obj);
> > }
> >
> > + if
On 2/14/2024 1:13 AM, Jacek Lawrynowicz wrote:
From: "Wachowski, Karol"
Rename BO allocate/create functions, so the code is more consistent.
There are now two matching buffer creation functions:
- ivpu_bo_create_ioctl() - create a BO from user space
- ivpu_bo_create() - create a BO from
On 2/14/2024 1:13 AM, Jacek Lawrynowicz wrote:
ivpu_reset_engine_fn and ivpu_reset_engine_fops were separated during
merge so move them back together to keep the file consistent.
Signed-off-by: Jacek Lawrynowicz
Reviewed-by: Jeffrey Hugo
On 2/14/2024 1:13 AM, Jacek Lawrynowicz wrote:
From: "Wachowski, Karol"
Reserve/allocate and free doorbells for command queues when needed
using xarray. This allows to avoid reserving a doorbell for
a contexts that never issues a job.
Signed-off-by: Wachowski, Karol
Missing your SOB.
On 2/14/2024 1:13 AM, Jacek Lawrynowicz wrote:
From: Krystian Pradzynski
Add support for FW boot API param system_time_us.
According to the API description this field should
be set to system time in microseconds starting from 1970.
Signed-off-by: Krystian Pradzynski
Missing your SOB.
On Tue, Feb 13, 2024 at 04:50:26PM +0100, Pierre-Eric Pelloux-Prayer wrote:
> This new event can be used to trace where a given dma_fence is added
> as a dependency of some other work.
How?
What I'd expected here is that you add a dependency chain from one fence
to another, but this only has one
On 2/16/2024 10:13, Harry Wentland wrote:
On 2024-02-16 11:11, Harry Wentland wrote:
On 2024-02-16 10:42, Pekka Paalanen wrote:
On Fri, 16 Feb 2024 09:33:47 -0500
Harry Wentland wrote:
On 2024-02-16 03:19, Pekka Paalanen wrote:
On Fri, 2 Feb 2024 10:28:35 -0500
Hamza Mahfooz wrote:
On 2/14/2024 1:13 AM, Jacek Lawrynowicz wrote:
Update Boot API to 3.22.0 and JSM API to 3.15.6
Signed-off-by: Jacek Lawrynowicz
Reviewed-by: Jeffrey Hugo
On 2/14/2024 1:12 AM, Jacek Lawrynowicz wrote:
We are now using NPU IP generation based FW names instead of platform
code names, so mtl_vpu.bin can be removed.
Signed-off-by: Jacek Lawrynowicz
Reviewed-by: Jeffrey Hugo
On 2/14/2024 1:12 AM, Jacek Lawrynowicz wrote:
Remove legacy postfix from TILE_SKU_BOTH macro.
This was missed when renaming MTL to VPU37XX.
Signed-off-by: Jacek Lawrynowicz
Reviewed-by: Jeffrey Hugo
On Tue, Feb 13, 2024 at 04:50:25PM +0100, Pierre-Eric Pelloux-Prayer wrote:
> This series adds new events to make it easier for tools
> like gpuvis or umr to graph the GPUs, kernel and applications
> activity.
>
> UMR patches using these events can be found here:
>
On Fri, Feb 16, 2024 at 04:09:55PM +0100, Pierre-Eric Pelloux-Prayer wrote:
> With this and the dma_fence_used_as_dependency event, a tool can draw the
> relationship between the compositing draw, the atomic commit, and vblank.
>
> An example on a 2 monitors system look like this:
>
>
On 2024-02-16 11:11, Harry Wentland wrote:
>
>
> On 2024-02-16 10:42, Pekka Paalanen wrote:
>> On Fri, 16 Feb 2024 09:33:47 -0500
>> Harry Wentland wrote:
>>
>>> On 2024-02-16 03:19, Pekka Paalanen wrote:
On Fri, 2 Feb 2024 10:28:35 -0500
Hamza Mahfooz wrote:
> We want
On 2024-02-16 10:42, Pekka Paalanen wrote:
> On Fri, 16 Feb 2024 09:33:47 -0500
> Harry Wentland wrote:
>
>> On 2024-02-16 03:19, Pekka Paalanen wrote:
>>> On Fri, 2 Feb 2024 10:28:35 -0500
>>> Hamza Mahfooz wrote:
>>>
We want programs besides the compositor to be able to enable or
On Fri, 16 Feb 2024 16:09:55 +0100
Pierre-Eric Pelloux-Prayer wrote:
>
> Signed-off-by: Pierre-Eric Pelloux-Prayer
> ---
> drivers/gpu/drm/drm_atomic_uapi.c | 21 +
> drivers/gpu/drm/drm_trace.h | 23 +++
> 2 files changed, 44 insertions(+)
>
>
Am 16.02.24 um 16:09 schrieb Pierre-Eric Pelloux-Prayer:
This makes it possible to understand the dependencies between jobs.
Possible usage of this trace:
* stuttering issues like Mesa !9189
* incorrect synchronization: I don't have a link for this one, but having
these events was very useful
This vendor specific property has never been used by userspace
software and conflicts with the panel_power_savings sysfs file.
That is a compositor and user could fight over the same data.
Fixes: f97e4303da16 ("drm/amd/display: add panel_power_savings sysfs entry to
eDP connectors")
On 2/16/2024 09:41, Christian König wrote:
Am 16.02.24 um 16:12 schrieb Mario Limonciello:
On 2/16/2024 09:05, Harry Wentland wrote:
On 2024-02-16 09:47, Christian König wrote:
Am 16.02.24 um 15:42 schrieb Mario Limonciello:
On 2/16/2024 08:38, Christian König wrote:
Am 16.02.24 um 15:07
On Fri, 16 Feb 2024 09:33:47 -0500
Harry Wentland wrote:
> On 2024-02-16 03:19, Pekka Paalanen wrote:
> > On Fri, 2 Feb 2024 10:28:35 -0500
> > Hamza Mahfooz wrote:
> >
> >> We want programs besides the compositor to be able to enable or disable
> >> panel power saving features.
> >
> >
Am 16.02.24 um 16:12 schrieb Mario Limonciello:
On 2/16/2024 09:05, Harry Wentland wrote:
On 2024-02-16 09:47, Christian König wrote:
Am 16.02.24 um 15:42 schrieb Mario Limonciello:
On 2/16/2024 08:38, Christian König wrote:
Am 16.02.24 um 15:07 schrieb Mario Limonciello:
By exporting ABM
Hi,
On Fri, Feb 16, 2024 at 12:21 AM Javier Martinez Canillas
wrote:
>
> > The kernel tree we landed on was the v5.15 tree, which is currently
> > serving all Qualcomm sc7180-based Chromebooks, all Mediatek 8173
> > Chromebooks and all Mediatek 8186 Chromebooks. There are also a pile
> > of x86
Am 16.02.24 um 16:09 schrieb Pierre-Eric Pelloux-Prayer:
To inform tools about the relationship between the fences.
Signed-off-by: Pierre-Eric Pelloux-Prayer
Reviewed-by: Christian König
---
drivers/dma-buf/dma-fence-chain.c | 4
1 file changed, 4 insertions(+)
diff --git
Am 16.02.24 um 16:09 schrieb Pierre-Eric Pelloux-Prayer:
This new event can be used to trace where a given dma_fence is added
as a dependency of some other work.
I plan to use it in amdgpu.
Signed-off-by: Pierre-Eric Pelloux-Prayer
---
drivers/dma-buf/dma-fence.c | 1 +
Am 16.02.24 um 16:09 schrieb Pierre-Eric Pelloux-Prayer:
This series adds new events to make it easier for tools
like gpuvis or umr to graph the GPUs, kernel and applications
activity.
UMR patches using these events can be found here:
With the move to work queues for the drm scheduler it becomes
impossible for a tool to match the events to the GPU.
Before this move, the event source was fixed (eg: gfx_0.0.0-598),
so even if the system had multiple GPUs with identical queue names
it was possible to map the events using the PID.
drm_sched_job_add_dependency adds dependencies so use the new
trace event.
Signed-off-by: Pierre-Eric Pelloux-Prayer
---
drivers/gpu/drm/scheduler/sched_main.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
On 2/16/2024 09:05, Harry Wentland wrote:
On 2024-02-16 09:47, Christian König wrote:
Am 16.02.24 um 15:42 schrieb Mario Limonciello:
On 2/16/2024 08:38, Christian König wrote:
Am 16.02.24 um 15:07 schrieb Mario Limonciello:
By exporting ABM to sysfs it's possible that DRM master and
1 - 100 of 211 matches
Mail list logo
