With v6.16-rc1 on my x86_64 pc with a G86 [Quadro NVS 290] I get a
kernel NULL pointer dereference when Xorg starts up and no further
video output. I bisected the problem to commit 862450a85b85
("drm/nouveau/gf100-: track chan progress with non-WFI semaphore
release") and reverting that commit on
> Subject: Re: [PATCH v6 01/11] mtd: core: always create master device
>
> - Ursprüngliche Mail -
> > Von: "Miquel Raynal"
> >> On 6/10/25 05:54, Richard Weinberger wrote:
> >>> - Ursprüngliche Mail -
> Von: "Alexander Usyskin"
> Richard, I've reproduced your setup (mod
Hi Jeff,
> Allow pr_ostream to also output directly to a seq_file without an
> intermediate buffer. The first caller of +ref_tracker_dir_seq_print()
> will come in a later patch, so mark that __maybe_unused for now. That
> designation will be removed once it is used.
>
> Reviewed-by: Andrew Lunn
Il 06/06/25 14:50, Louis-Alexis Eyraud ha scritto:
Reorder output format arrays in both MT8195 DPI and DP_INTF block
configuration by decreasing preference order instead of alphanumeric
one, as expected by the atomic_get_output_bus_fmts callback function
of drm_bridge controls, so the RGB ones ar
On Fri, 06 Jun 2025, Jani Nikula wrote:
> Hi all -
>
> This series expands panel follower to ACPI, and enables drm_panel on
> i915.
>
> Patch 1 makes panel follower matching independent of DT, making it also
> work with ACPI. Similar to DT, you can use a _DSD "panel" property to
> describe the dep
Hi Jeff,
> A later patch in the series will be adding debugfs files for each
> ref_tracker that get created in ref_tracker_dir_init(). The format will
> be "class@%px". The current "name" string can vary between
> ref_tracker_dir objects of the same type, so it's not suitable for this
> purpose.
>
Hi Marek,
On Sun, 8 Jun 2025 at 23:38, Marek Vasut
wrote:
> Not all panels use all 4 data lanes, so allow configuration based
> on the compatible string.
>
> Signed-off-by: Marek Vasut
Thanks for your patch!
> --- a/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
> +++ b/drivers/gpu/drm/panel/pa
struct drm_crtc_state {
/**
* @async_flip:
*
* This is set when DRM_MODE_PAGE_FLIP_ASYNC is set in the legacy
* PAGE_FLIP IOCTL. It's not wired up for the atomic IOCTL
itself yet.
*/
bool async_flip;
In the existing code the flag asyn
irq_domain_create_simple() takes fwnode as the first argument. It can be
extracted from the struct device using dev_fwnode() helper instead of
using of_node with of_fwnode_handle().
So use the dev_fwnode() helper.
Signed-off-by: Jiri Slaby (SUSE)
Cc: Rob Clark
Cc: Abhinav Kumar
Cc: Dmitry Bary
irq_domain_create_simple() takes fwnode as the first argument. It can be
extracted from the struct device using dev_fwnode() helper instead of
using of_node with of_fwnode_handle().
So use the dev_fwnode() helper.
Signed-off-by: Jiri Slaby (SUSE)
Cc: Philipp Zabel
Cc: David Airlie
Cc: Simona V
The following error has been reported sporadically by CI when a test
unbinds the i915 driver on a ring submission platform:
<4> [239.330153] [ cut here ]
<4> [239.330166] i915 :00:02.0: [drm] drm_WARN_ON(dev_priv->mm.shrink_count)
<4> [239.330196] WARNING: CPU: 1 PID: 1
Hi,
On 05.06.2025 19:15, Aradhya Bhatia wrote:
> From: Aradhya Bhatia
>
> Move the bridge pre_enable call before crtc enable, and the bridge
> post_disable call after the crtc disable.
>
> The sequence of enable after this patch will look like:
>
> bridge[n]_pre_enable
> ...
> b
On 11/06/2025 13:15, Akhil P Oommen wrote:
> In order to enable GPU support in Snapdragon X1P42100
> (8 CPU core version found on Asus Zenbook A14 and other
There is no A14 upstream board DTS in next. Your commit msg should
provide rationale for this, e.g. which upstream boards use this driver.
B
Add support for X1-45 GPU found in X1P41200 chipset (8 cpu core
version). X1-45 is a smaller version of X1-85 with lower core count and
smaller memories. From UMD perspective, this is similar to "FD735"
present in Mesa.
Tested Glmark & Vkmark on Debian Gnome desktop.
Signed-off-by: Akhil P Oommen
Hi Jeff,
> In a later patch, we'll be adding a 3rd mechanism for outputting
> ref_tracker info via seq_file. Instead of a conditional, have the caller
> set a pointer to an output function in struct ostream. As part of this,
> the log prefix must be explicitly passed in, as it's too late for the
>
On 11/06/2025 13:15, Akhil P Oommen wrote:
> + opp-28000 {
> + opp-hz = /bits/ 64 <28000>;
> + opp-level = ;
> + opp-peak-kBps = <2136719>;
> + qcom,opp-acd-level = <0xc82f5ffd>;
> +
On 2025/6/9 23:44, Dmitry Baryshkov wrote:
On Mon, Jun 09, 2025 at 08:21:48PM +0800, Yongxing Mou wrote:
From: Abhinav Kumar
Add connector abstraction for the DP MST. Each MST encoder
is connected through a DRM bridge to a MST connector and each
MST connector has a DP panel abstraction atta
On 6/10/25 10:52 AM, Mikko Perttunen wrote:
On 6/10/25 6:05 PM, Thierry Reding wrote:
On Fri, Jun 06, 2025 at 11:45:33AM +0100, Diogo Ivo wrote:
Hello,
This series adds support for the NVJPG hardware accelerator found in the
Tegra210 SoC.
The kernel driver is essentially a copy of the NVDE
On 2025/6/9 23:57, Dmitry Baryshkov wrote:
On Mon, Jun 09, 2025 at 08:21:47PM +0800, Yongxing Mou wrote:
From: Abhinav Kumar
Add a new file dp_mst_drm to manage the DP MST bridge operations
similar to the dp_drm file which manages the SST bridge operations.
Each MST encoder creates one brid
On 6/10/25 18:42, Tvrtko Ursulin wrote:
> Protect the access to driver and timeline name which otherwise could be
> freed as dma-fence exported is signalling fences.
>
> This prepares the code for incoming dma-fence API changes which will start
> asserting these accesses are done from a RCU locked
Hi Mikko, thanks for the quick review!
On 6/10/25 4:26 AM, Mikko Perttunen wrote:
On 6/6/25 7:45 PM, Diogo Ivo wrote:
Add support for booting and using NVJPG on Tegra210 to the Host1x
and TegraDRM drivers. This driver only supports the new TegraDRM uAPI.
Hello Diogo -- I'm happy to see this
On 6/10/25 5:57 AM, Mikko Perttunen wrote:
On 6/6/25 7:45 PM, Diogo Ivo wrote:
Add the NVJPG power-domain node in order to support the NVJPG
accelerator.
Signed-off-by: Diogo Ivo
---
arch/arm64/boot/dts/nvidia/tegra210.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/a
On 6/10/25 9:58 AM, Thierry Reding wrote:
On Fri, Jun 06, 2025 at 11:45:33AM +0100, Diogo Ivo wrote:
Hello,
This series adds support for the NVJPG hardware accelerator found in the
Tegra210 SoC.
The kernel driver is essentially a copy of the NVDEC driver as both
engines are Falcon-based.
F
On 2025/6/10 16:30, Dmitry Baryshkov wrote:
On Tue, Jun 10, 2025 at 12:47:00PM +0800, Yongxing Mou wrote:
On 2025/6/9 20:36, Dmitry Baryshkov wrote:
On Mon, Jun 09, 2025 at 08:21:19PM +0800, Yongxing Mou wrote:
Add support for Multi-stream transport for MSM chipsets that allow
a single in
On 6/10/25 6:01 AM, Mikko Perttunen wrote:
On 6/6/25 7:45 PM, Diogo Ivo wrote:
The Tegra X1 chip contains a NVJPG accelerator capable of
encoding/decoding JPEG files in hardware, so add its DT node.
Signed-off-by: Diogo Ivo
---
arch/arm64/boot/dts/nvidia/tegra210.dtsi | 8 +++-
1 fil
On 6/10/25 10:05 AM, Thierry Reding wrote:
On Fri, Jun 06, 2025 at 11:45:33AM +0100, Diogo Ivo wrote:
Hello,
This series adds support for the NVJPG hardware accelerator found in the
Tegra210 SoC.
The kernel driver is essentially a copy of the NVDEC driver as both
engines are Falcon-based.
Hi Diederik,
At 2025-06-11 18:56:31, "Diederik de Haas" wrote:
>Hi Andy,
>
>On Wed Jun 11, 2025 at 9:41 AM CEST, Andy Yan wrote:
>> At 2025-06-10 19:02:11, "Diederik de Haas" wrote:
>>>On Tue Jun 10, 2025 at 11:07 AM CEST, Andy Yan wrote:
At 2025-06-09 20:36:41, "Diederik de Haas" wrote:
Hello,
This series adds support for the NVJPG hardware accelerator found in the
Tegra210 SoC.
The kernel driver is essentially a copy of the NVDEC driver as both
engines are Falcon-based.
For the userspace part I have written a Mesa Gallium backend [1] that,
while still very much experimental, w
Add the NVJPG power-domain node in order to support the NVJPG
accelerator in Tegra210 platforms.
Reviewed-by: Mikko Perttunen
Signed-off-by: Diogo Ivo
---
v1->v2:
- Collect R-b from Mikko
- Explicitly mention Tegra210 in commit subject
---
arch/arm64/boot/dts/nvidia/tegra210.dtsi | 6 ++
1
The Tegra X1 chip contains a NVJPG accelerator capable of
encoding/decoding JPEG files in hardware. Complete its DT node
and enable it.
Reviewed-by: Mikko Perttunen
Signed-off-by: Diogo Ivo
---
v1->v2:
- Collect R-b from Mikko
- Explicitly mention Tegra210 in commit subject
- Be more precise in
On 6/10/25 18:42, Tvrtko Ursulin wrote:
> Dma-fence objects currently suffer from a potential use after free problem
> where fences exported to userspace and other drivers can outlive the
> exporting driver, or the associated data structures.
>
> The discussion on how to address this concluded tha
On 10/06/2025 at 09:15:25 -07, Guenter Roeck wrote:
> On 6/10/25 05:54, Richard Weinberger wrote:
>> - Ursprüngliche Mail -
>>> Von: "Alexander Usyskin"
>>> Richard, I've reproduced your setup (modulo that I must load mtdram
>>> manually)
>>> and patch provided in this thread helps to f
On 6/11/2025 4:50 PM, Krzysztof Kozlowski wrote:
> On 11/06/2025 13:15, Akhil P Oommen wrote:
>> Update regex to allow multi-worded OPP entry names.
>
> Why would we want multi-worded? This needs to be explained here.
I took the new regex from "opp-v2-base.yaml" file, so I thought it was
obvious
On 6/11/2025 4:52 PM, Krzysztof Kozlowski wrote:
> On 11/06/2025 13:15, Akhil P Oommen wrote:
>> +opp-28000 {
>> +opp-hz = /bits/ 64 <28000>;
>> +opp-level = ;
>> +opp-peak-kBps = <2136719>;
>> +qcom
Hi,
On Wed Jun 11, 2025 at 2:15 PM CEST, Andy Yan wrote:
> At 2025-06-11 18:56:31, "Diederik de Haas" wrote:
>>On Wed Jun 11, 2025 at 9:41 AM CEST, Andy Yan wrote:
>>> At 2025-06-10 19:02:11, "Diederik de Haas" wrote:
On Tue Jun 10, 2025 at 11:07 AM CEST, Andy Yan wrote:
> At 2025-06-09
Hi Thierry,
On 6/10/25 9:44 AM, Thierry Reding wrote:
On Tue, Jun 10, 2025 at 12:26:07PM +0900, Mikko Perttunen wrote:
On 6/6/25 7:45 PM, Diogo Ivo wrote:
Add support for booting and using NVJPG on Tegra210 to the Host1x
and TegraDRM drivers. This driver only supports the new TegraDRM uAPI.
On 6/11/2025 4:55 PM, Krzysztof Kozlowski wrote:
> On 11/06/2025 13:15, Akhil P Oommen wrote:
>> In order to enable GPU support in Snapdragon X1P42100
>> (8 CPU core version found on Asus Zenbook A14 and other
>
> There is no A14 upstream board DTS in next. Your commit msg should
> provide rationa
X1P42100 SoC has a new GPU called Adreno X1-45 which is a smaller
version of Adreno X1-85 GPU. Describe this new GPU and also add
the secure gpu firmware path that should used for X1P42100 CRD.
Signed-off-by: Akhil P Oommen
---
arch/arm64/boot/dts/qcom/x1e80100.dtsi| 7 ++
arch/arm64/boot/
On Wed, Jun 11, 2025 at 2:01 PM Michal Wilczynski
wrote:
>
>
>
> On 6/5/25 10:10, Bartosz Golaszewski wrote:
> > On Thu, Jun 5, 2025 at 9:47 AM Michal Wilczynski
> > wrote:
> >>
> >>
> >>
> >> On 6/4/25 14:07, Krzysztof Kozlowski wrote:
> >>> On 04/06/2025 13:53, Michal Wilczynski wrote:
> >>
On Tue, 10 Jun 2025 12:40:38 -0700, Nathan Chancellor wrote:
> This driver requires of_get_display_timing() from
> CONFIG_VIDEOMODE_HELPERS but does not select it. If no other driver
> selects it, there will be a failure from the linker if the driver is
> built in or modpost if it is a module.
>
>
Add support for booting and using NVJPG on Tegra210 to the Host1x
and TegraDRM drivers. This driver only supports the new TegraDRM uAPI.
Signed-off-by: Diogo Ivo
---
v1->v2:
- Removed explicit reset handling, leaving it to power-domain code
- Set clock rate to maximum upon getting clock
- Use mo
On 5/30/25 11:05, Louis Chauvet wrote:
The formats XRGB16161616 and ARGB16161616 were already supported.
Add the support for:
- ABGR16161616
- XBGR16161616
Signed-off-by: Louis Chauvet
Reviewed-by: Maíra Canal
Best Regards,
- Maíra
---
drivers/gpu/drm/vkms/vkms_formats.c | 6 ++
dr
On 5/30/25 11:06, Louis Chauvet wrote:
Add the support for:
- RGB888
- BGR888
Signed-off-by: Louis Chauvet
Reviewed-by: Maíra Canal
Best Regards,
- Maíra
---
drivers/gpu/drm/vkms/vkms_formats.c | 7 +++
drivers/gpu/drm/vkms/vkms_plane.c | 2 ++
2 files changed, 9 insertions(+)
Hi.
This patch series adds the DT bindings and tree entries for the GPU
present in Apple M-series SoCs. The driver itself is in Rust and
upstream is currently missing several prerequisite bindings, so will
be sent later.
Signed-off-by: Sasha Finkelstein
---
Sasha Finkelstein (2):
dt-bindin
On Wed, 11 Jun 2025 at 20:44, Sven Peter wrote:
> > + - description: Driver-opaque calibration blob
> > + - description: Calibration blob
>
> Like Alyssa mentioned, this description also raises more questions than
> it answers for me. Do we know what these two blobs contain or why they
>
On Wed, Jun 11, 2025 at 07:32:17PM +0200, Sasha Finkelstein via B4 Relay wrote:
> From: Sasha Finkelstein
>
> Add device tree entries for GPUs in M-series SoCs
>
> Signed-off-by: Sasha Finkelstein
> ---
> arch/arm64/boot/dts/apple/t6000.dtsi| 4
> arch/arm64/boot/dts/apple/t6001.
Hi Louis,
On 5/30/25 11:05, Louis Chauvet wrote:
The formats XRGB and ARGB were already supported.
Add the support for:
- XBGR
- RGBX
- BGRX
- ABGR
- RGBA
- BGRA
Signed-off-by: Louis Chauvet
---
[...]
+READ_LINE_ARGB(RGBX_read_line, px, 0xFF, px[3],
> + - description: Driver-opaque calibration blob
> + - description: Calibration blob
...
> + - const: hw-cal-a
> + - const: hw-cal-b
For me these descriptions raise more questions than what they're meant
to describe... Maybe "First hardware calibration blob" and "Second
hardwa
From: Sasha Finkelstein
Add bindings for the GPU present in Apple SoCs
Signed-off-by: Sasha Finkelstein
---
Documentation/devicetree/bindings/gpu/apple,agx.yaml | 95
+++
MAINTAINERS
The xe driver is the official driver for Intel Xe2 and later, while
maintaining experimental support for earlier GPUs. Reword the help
message accordingly.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/xe/Kconfig | 5 +++--
drivers/gpu/drm/xe/xe_drv.h | 2 +-
2 files changed, 4 insertions(
On 11.06.25 21:06, Sasha Finkelstein wrote:
On Wed, 11 Jun 2025 at 20:44, Sven Peter wrote:
+ - description: Driver-opaque calibration blob
+ - description: Calibration blob
Like Alyssa mentioned, this description also raises more questions than
it answers for me. Do we know what th
> > + - apple,agx-g13s
> > + - apple,agx-g13c
> > + - apple,agx-g13d
> > + - const: apple,agx-g13x
>
> I'm assuming the 'x' is a wildcard. The preferred thing to do make one
> of the 3 actual devices the fallback. Typically, the oldest one is
> used.
> On Tue, 2025-06-03 at 13:27 +0100, Tvrtko Ursulin wrote:
> > On 03/06/2025 10:31, Philipp Stanner wrote:
> > What I am not that ecstatic about is only getting the Suggested-by
> > credit in 1/6. Given it is basically my patch with some cosmetic
> > changes
> > like the kernel doc and the cancel
Hi,
On Tue, Jun 10, 2025 at 10:29 PM Jayesh Choudhary wrote:
>
> @@ -1195,9 +1203,17 @@ static enum drm_connector_status
> ti_sn_bridge_detect(struct drm_bridge *bridge)
> struct ti_sn65dsi86 *pdata = bridge_to_ti_sn65dsi86(bridge);
> int val = 0;
>
> - pm_runtime_get_sync(
On Tue, 2025-06-10 at 09:02 +0200, Maarten Lankhorst wrote:
> Instead of having ggtt->size point to the end of ggtt, have ggtt-
> >size
> be the actual size of the GGTT, and introduce ggtt->start to point to
> the beginning of GGTT.
>
> This will allow a massive cleanup of GGTT in case of SRIOV-VF
On Wed, Jun 11, 2025 at 09:12:35PM +0200, Sven Peter wrote:
> Hi,
>
> On 11.06.25 19:32, Sasha Finkelstein via B4 Relay wrote:
> > From: Sasha Finkelstein
> >
> > Add device tree entries for GPUs in M-series SoCs
> >
> > Signed-off-by: Sasha Finkelstein
> > ---
> > arch/arm64/boot/dts/apple/
On 5/30/25 11:05, Louis Chauvet wrote:
The callback functions for line conversion are almost identical for
some format. The generic READ_LINE macro generate all the required
boilerplate to process a line.
Two overrides of this macro have been added to avoid duplication of
the same arguments ever
Hi Nitin,
On Wed, Jun 11, 2025 at 03:45:30PM +, Gote, Nitin R wrote:
> [...]
> > Subject: [PATCH] drm/i915/ring_submission: Fix timeline left held on VMA
> > alloc
> > error
> >
>
> Generally, it's preferred to use "drm/i915/gt:" file path over
> "drm/i915/ring_submission:" file name in th
Hi Janusz,
On Wed, Jun 11, 2025 at 12:42:13PM +0200, Janusz Krzysztofik wrote:
> The following error has been reported sporadically by CI when a test
> unbinds the i915 driver on a ring submission platform:
>
> <4> [239.330153] [ cut here ]
> <4> [239.330166] i915 :00:
The Kconfig option `CONFIG_DRM_VKMS_KUNIT_TESTS` does not exist. However,
the VKMS format tests use such an option for compilation, meaning that
they are not compiled at all.
Use the Kconfig option `CONFIG_DRM_VKMS_KUNIT_TEST` to compile all VKMS
KUnit tests.
Fixes: 3e897853debd ("drm/vkms: Creat
Hi Louis,
On 5/30/25 11:05, Louis Chauvet wrote:
The format RGB565 was already supported. Add the support for:
- BGR565
Signed-off-by: Louis Chauvet
---
drivers/gpu/drm/vkms/vkms_formats.c | 23 +++
drivers/gpu/drm/vkms/vkms_plane.c | 1 +
2 files changed, 24 inserti
Hi,
On 11.06.25 19:32, Sasha Finkelstein via B4 Relay wrote:
From: Sasha Finkelstein
Add device tree entries for GPUs in M-series SoCs
Signed-off-by: Sasha Finkelstein
---
arch/arm64/boot/dts/apple/t6000.dtsi| 4
arch/arm64/boot/dts/apple/t6001.dtsi| 4
arch/a
Reviewed-by: Alyssa Rosenzweig
>
> This patch series adds the DT bindings and tree entries for the GPU
> present in Apple M-series SoCs. The driver itself is in Rust and
> upstream is currently missing several prerequisite bindings, so will
> be sent later.
It would be good to include links to the kernel + m1n1 branches that
s
Hi,
I think there's a "gpu: " missing in the subject.
On 11.06.25 19:32, Sasha Finkelstein via B4 Relay wrote:
From: Sasha Finkelstein
Add bindings for the GPU present in Apple SoCs
Signed-off-by: Sasha Finkelstein
---
Documentation/devicetree/bindings/gpu/apple,agx.yaml | 95
++
On Wed, Jun 11, 2025 at 12:32 PM Sasha Finkelstein via B4 Relay
wrote:
>
> From: Sasha Finkelstein
>
> Add bindings for the GPU present in Apple SoCs
>
> Signed-off-by: Sasha Finkelstein
> ---
> Documentation/devicetree/bindings/gpu/apple,agx.yaml | 95
> +++
Hi Louis,
On 5/30/25 11:06, Louis Chauvet wrote:
Some YUV format uses 16 bit values, so change the helper function for
conversion to support those new formats.
Add support for the YUV format P010
Hum, I don't think this patch added support for P010.
Signed-off-by: Louis Chauvet
---
driv
Hi Louis,
On 5/30/25 11:06, Louis Chauvet wrote:
The callback functions for line conversion are almost identical for
semi-planar formats. The generic READ_LINE_YUV_SEMIPLANAR macro
generate all the required boilerplate to process a line from a
semi-planar format.
Signed-off-by: Louis Chauvet
-
Hi Louis,
On 5/30/25 11:06, Louis Chauvet wrote:
Some YUV format uses 16 bit values, so change the helper function for
conversion to support those new formats.
Add support for the YUV format P010
Signed-off-by: Louis Chauvet
---
drivers/gpu/drm/vkms/tests/vkms_format_test.c | 103 ++
As with the RK3588 SoC, the HDMI PHY PLL on RK3576 can be used as a more
accurate pixel clock source for VOP2, which is actually mandatory to
ensure proper support for display modes handling.
Add the missing #clock-cells property to allow using the clock provider
functionality of HDMI PHY.
Fixes:
As with the RK3588 SoC, RK3576 also allows the use of HDMI PHY PLL as an
alternative and more accurate pixel clock source for VOP2.
Document the optional PLL clock property.
Moreover, given that this is part of a series intended to address some
recent display problems, provide the appropriate tag
hip-vop2.yaml | 56 +-
arch/arm64/boot/dts/rockchip/rk3576.dtsi | 7 ++-
2 files changed, 49 insertions(+), 14 deletions(-)
---
base-commit: 19272b37aa4f83ca52bdf9c16d5d81bdd1354494
change-id: 20250611-rk3576-hdmitx-fix-e030fbdb0d17
Since commit c871a311edf0 ("phy: rockchip: samsung-hdptx: Setup TMDS
char rate via phy_configure_opts_hdmi"), the workaround of passing the
rate from DW HDMI QP bridge driver via phy_set_bus_width() became
partially broken, as it cannot reliably handle mode switches anymore.
Attempting to fix this
Add TRACE_GPU_MEM tracepoints for tracking global and per-process GPU
memory usage.
These are required by VSR on Android 12+ for reporting GPU driver memory
allocations.
v3:
- Use now configurable CONFIG_TRACE_GPU_MEM instead of adding a
per-driver Kconfig (Lucas)
v2:
- Use u64 as preferred
Move the source to a better place in Device Drivers -> Graphics support
now that its configurable.
v4:
- Move source location (Tvrtko)
v3:
- Patch introduced to replace per-driver config (Lucas)
Signed-off-by: Juston Li
---
drivers/Kconfig | 2 --
drivers/gpu/trace/Kconfig | 11 ++
On 5/27/25 1:56 AM, Amirreza Zarrabi wrote:
For drivers that can transfer data to the TEE without using shared
memory from client, it is necessary to receive the user address
directly, bypassing any processing by the TEE subsystem. Introduce
TEE_IOCTL_PARAM_ATTR_TYPE_UBUF_INPUT/OUTPUT/INOUT to re
Use u8 to hold lane count in struct ili9881c_desc {} to avoid
alignment gap between default_address_mode and lanes members.
The ili9881c controller can only operate up to 4 DSI lanes, so
there is no chance this value can ever be larger than 4. No
functional change.
Suggested-by: Geert Uytterhoeven
Hi Andrew,
On 6/12/2025 8:40 AM, Andrew Davis wrote:
> On 5/27/25 1:56 AM, Amirreza Zarrabi wrote:
>> For drivers that can transfer data to the TEE without using shared
>> memory from client, it is necessary to receive the user address
>> directly, bypassing any processing by the TEE subsystem. In
Hi Cristian,
On Wednesday, 11 June 2025 17:47:49 EDT Cristian Ciocaltea wrote:
> Since commit c871a311edf0 ("phy: rockchip: samsung-hdptx: Setup TMDS
> char rate via phy_configure_opts_hdmi"), the workaround of passing the
> rate from DW HDMI QP bridge driver via phy_set_bus_width() became
> parti
On Tue, Jun 10, 2025 at 12:40:38PM -0700, Nathan Chancellor wrote:
> This driver requires of_get_display_timing() from
> CONFIG_VIDEOMODE_HELPERS but does not select it. If no other driver
> selects it, there will be a failure from the linker if the driver is
> built in or modpost if it is a module
From: Michael Kelley Sent: Thursday, June 5, 2025 10:39 AM
>
> From: Thomas Zimmermann Sent: Thursday, June 5, 2025
> 8:36 AM
> >
> > Hi
> >
> > Am 04.06.25 um 23:43 schrieb Michael Kelley:
> > [...]
> > > Nonetheless, there's an underlying issue. A main cause of the difference
> > > is the numbe
Hi Andy and Diederik
>
> The root case for the problem is now clear。
>
> Most of the registers in VOP need to write the cfd_done register(call
> vop2_cfg_done)
> after you have configured the registers. Then, they will take effect only
> when the VSYNC event occurs(It doesn't take effect
On 6/12/25 12:06 AM, Thierry Reding wrote:
On Wed, Jun 11, 2025 at 01:05:40PM +0100, Diogo Ivo wrote:
On 6/10/25 10:52 AM, Mikko Perttunen wrote:
On 6/10/25 6:05 PM, Thierry Reding wrote:
On Fri, Jun 06, 2025 at 11:45:33AM +0100, Diogo Ivo wrote:
Hello,
This series adds support for the NVJ
On Wed, 04 Jun 2025 12:48:49 +0530, Ayushi Makhija wrote:
> This series enables the support for DSI to DP bridge ports
> (labled as DSI0 and DSI1) of the Qualcomm's SA8775P Ride platform.
>
> SA8775P SoC has DSI controller v2.5.1 and DSI PHY v4.2.
> The Ride platform is having ANX7625 DSI to DP
Running the Cyberpunk 2077 benchmark we can observe that the lookup helper
is relatively hot, but the 97% of the calls are for a single object. (~3%
for two points, and never more than three points. While a more trivial
workload like vkmark under Plasma is even more skewed to single point
lookups.)
On 6/11/25 16:00, Tvrtko Ursulin wrote:
> Running the Cyberpunk 2077 benchmark we can observe that the lookup helper
> is relatively hot, but the 97% of the calls are for a single object. (~3%
> for two points, and never more than three points. While a more trivial
> workload like vkmark under Plas
We can avoid one of the two temporary allocations if we read the userspace
supplied timeline points as we go along.
The only new complication is to unwind unused fence chains on the error
path, but even that code was already present in the function.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Maí
Running the Cyberpunk 2077 benchmark we can observe that waiting on DRM
sycobjs is relatively hot, but the 96% of the calls are for a single
object. (~4% for two points, and never more than three points. While
a more trivial workload like vkmark under Plasma is even more skewed
to single point wait
Helper which fails to consolidate the code and instead just forks into two
copies of the code based on a boolean parameter is not very helpful or
readable. Lets just remove it and proof in the pudding is the net smaller
code.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Maíra Canal
---
v2:
* Assi
Drm_syncobj_array_find() helper is used from many userspace ioctl entry
points with the task of looking up userspace handles to internal objects.
We can easily avoid one temporary allocation by making it read the handles
as it is looking them up.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Maíra
A small set of drm_syncobj optimisations which should make things a tiny bit
more efficient on the CPU side of things.
Improvement seems to be around 1.5%* more FPS if observed with "vkgears
-present-mailbox" on a Steam Deck Plasma desktop, but I am reluctant to make a
definitive claim on the numb
On 6/11/25 16:00, Tvrtko Ursulin wrote:
> We can avoid one of the two temporary allocations if we read the userspace
> supplied timeline points as we go along.
The problem with that is that calling copy_from_user multiple times is really
inefficient.
So that improves performance with few entries
On Tue, 10 Jun 2025 10:59:20 -0400 Jeff Layton wrote:
> For those just joining in, this series adds a new top-level
> "ref_tracker" debugfs directory, and has each ref_tracker_dir register a
> file in there as part of its initialization. It also adds the ability to
> register a symlink with a more
On 11/06/2025 12:43, Christian König wrote:
On 6/10/25 18:42, Tvrtko Ursulin wrote:
Dma-fence objects currently suffer from a potential use after free problem
where fences exported to userspace and other drivers can outlive the
exporting driver, or the associated data structures.
The discussi
(Cc: dri-devel)
On Tue, Jun 10, 2025 at 03:05:34PM +0200, Christian König wrote:
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.h
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.h
> > index 5a8bc634..6108a6f9dba7 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.h
> > +++ b/drivers/g
On Fri, May 30, 2025 at 05:54:31PM +0800, Yongbang Shi wrote:
From: Baihan Li
In early OS versions， there is a bug in hibmc-drm driver previously,
Which OS? What does that mean? Why do we need to workaround userspace
issues in the kernel?
We use OpenEuler 22.03, there is a VGA cfg(video=V
On Tue, 10 Jun 2025, "Kahola, Mika" wrote:
>> -Original Message-
>> From: Intel-gfx On Behalf Of Imre
>> Deak
>> Sent: Monday, 9 June 2025 15.56
>> To: intel-...@lists.freedesktop.org; intel...@lists.freedesktop.org;
>> dri-devel@lists.freedesktop.org
>> Cc: Ville Syrjälä ; Jani Nikula
Hi Tvrtko,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-exynos/exynos-drm-next]
[also build test WARNING on linus/master v6.16-rc1 next-20250611]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we
Hello,
On 11/06/2025 at 10:52:36 GMT, "Usyskin, Alexander"
wrote:
>> Subject: Re: [PATCH v6 01/11] mtd: core: always create master device
>>
>> - Ursprüngliche Mail -
>> > Von: "Miquel Raynal"
>> >> On 6/10/25 05:54, Richard Weinberger wrote:
>> >>> - Ursprüngliche Mail -
>> >
On 6/11/25 16:25, Danilo Krummrich wrote:
> (Cc: dri-devel)
>
> On Tue, Jun 10, 2025 at 03:05:34PM +0200, Christian König wrote:
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.h
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.h
>>> index 5a8bc634..6108a6f9dba7 100644
>>> --- a/drivers/gpu
1 - 100 of 164 matches
Mail list logo
