On Fri, May 30, 2025 at 11:37:21AM +0200, David Hildenbrand wrote:
> On 29.05.25 08:32, Alistair Popple wrote:
> > Currently dax is the only user of pmd and pud mapped ZONE_DEVICE
> > pages. Therefore page walkers that want to exclude DAX pages can check
> > pmd_devmap or pud_devmap. However soon d
Replace comma between expressions with semicolons.
Using a ',' in place of a ';' can have unintended side effects.
Although that is not the case here, it is seems best to use ';'
unless ',' is intended.
Found by inspection.
No functional change intended.
Compile tested only.
Signed-off-by: Chen
On 12.06.2025 07:49, Tomi Valkeinen wrote:
> On 11/06/2025 13:45, Marek Szyprowski wrote:
>> 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 sequ
Hi,
On 11/06/2025 08:29, Jayesh Choudhary wrote:
> By default, HPD was disabled on SN65DSI86 bridge. When the driver was
> added (commit "a095f15c00e27"), the HPD_DISABLE bit was set in pre-enable
> call which was moved to other function calls subsequently.
> Later on, commit "c312b0df3b13" added
\o/
Reviewed-by: Maarten Lankhorst
On 2025-06-11 21:38, Lucas De Marchi wrote:
> 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/g
Hello Doug,
On 12/06/25 03:08, Doug Anderson wrote:
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);
> -Original Message-
> From: Kandpal, Suraj
> Sent: Monday, April 14, 2025 9:46 AM
> To: nouv...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; intel-
> x...@lists.freedesktop.org; intel-...@lists.freedesktop.org
> Cc: Nautiyal, Ankit K ; Murthy, Arun R
> ; Kandpal, Suraj
> Subje
Hi Heiko，
At 2025-06-11 05:27:48, "Heiko Stuebner" wrote:
>Each window of a vop2 is usable by a specific set of video ports, so while
>binding the vop2, we look through the list of available windows trying to
>find one designated as primary-plane and usable by that specific port.
>
>The code late
Hi,
On 11/06/2025 13:45, Marek Szyprowski wrote:
> 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 l
On Wed, Jun 11, 2025 at 03:51:24PM -0700, Juston Li wrote:
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
> -Original Message-
> From: Kandpal, Suraj
> Sent: Monday, April 14, 2025 9:46 AM
> To: nouv...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; intel-
> x...@lists.freedesktop.org; intel-...@lists.freedesktop.org
> Cc: Nautiyal, Ankit K ; Murthy, Arun R
> ; Kandpal, Suraj
> Subje
On Wed, Jun 11, 2025 at 03:51:23PM -0700, Juston Li wrote:
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
Reviewed-by:
On 5/22/2025 5:43 PM, Dmitry Baryshkov wrote:
> On Thu, 22 May 2025 at 08:01, Ekansh Gupta
> wrote:
>>
>>
>> On 5/19/2025 7:04 PM, Dmitry Baryshkov wrote:
>>> On Mon, May 19, 2025 at 04:28:34PM +0530, Ekansh Gupta wrote:
On 5/19/2025 4:22 PM, Dmitry Baryshkov wrote:
> On Tue, May 13, 2
> -Original Message-
> From: Kandpal, Suraj
> Sent: Monday, April 14, 2025 9:46 AM
> To: nouv...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; intel-
> x...@lists.freedesktop.org; intel-...@lists.freedesktop.org
> Cc: Nautiyal, Ankit K ; Murthy, Arun R
> ; Kandpal, Suraj
> Subje
On 5/22/2025 5:39 PM, Dmitry Baryshkov wrote:
> On Thu, 22 May 2025 at 07:54, Ekansh Gupta
> wrote:
>>
>>
>> On 5/19/2025 6:59 PM, Dmitry Baryshkov wrote:
>>> On Mon, May 19, 2025 at 04:36:13PM +0530, Ekansh Gupta wrote:
On 5/19/2025 3:46 PM, Dmitry Baryshkov wrote:
> On Tue, May 13, 2
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
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 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
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
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
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
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 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
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
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
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
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:
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
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-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 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
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 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:
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 ++
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
Hum, I don't think this patch added support for P010.
Signed-off-by: Louis Chauvet
---
driv
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],
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.
> > + - 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 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
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
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: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(+)
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 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,
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
++
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 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
>
> 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
Reviewed-by: Alyssa Rosenzweig
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
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
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
>
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
> + - 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 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/arm64/boot/dts/apple/t6002.dtsi| 4
arch/arm64/boot/dt
On Wed, 11 Jun 2025 at 19:42, Alyssa Rosenzweig wrote:
>
> It would be good to include links to the kernel + m1n1 branches that
> support this binding, since it's not what downstream ships.
Right, will add to cover message on v2.
Kernel: https://github.com/WhatAmISupposedToPutHere/linux/tree/star
Add support for the 2160x1080 LCD panel from DJN (98-03057-6598B-I)
bundled with a HX83112B driver IC, as found on the Fairphone 3
smartphone.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Luca Weiss
---
drivers/gpu/drm/panel/Kconfig| 10 +
drivers/gpu/drm/panel/Makefile
Add a driver for the HX83112B-based panel, and enable it on Fairphone 3
to enable display output, and enable GPU as well.
Signed-off-by: Luca Weiss
---
Changes in v4:
- Drop "port: true" from bindings (Krzysztof)
- Use devm_drm_panel_alloc (Dmitry)
- Pick up tags
- Link to v3:
https://lore.kerne
Hi Greet,
Thanks for your confirmation and suggestions.
I added this patch based on existing checks on var->pixclock in other
drivers, such as savagefb_check_var, nvidiafb_check_var, etc.
Are you suggesting that it is better to replace an invalid value
(var->pixclock == 0) with a default valid va
Add the description for the display panel found on this phone.
Unfortunately the LCDB module on PMI632 isn't yet supported upstream so
we need to use a dummy regulator-fixed in the meantime.
And with this done we can also enable the GPU and set the zap shader
firmware path.
Reviewed-by: Konrad Dy
Himax HX83112B is a display driver IC used to drive LCD DSI panels.
Describe it and the Fairphone 3 panel (98-03057-6598B-I) from DJN using
it.
Reviewed-by: Krzysztof Kozlowski
Signed-off-by: Luca Weiss
---
.../bindings/display/panel/himax,hx83112b.yaml | 73 ++
1 file c
Add the vendor prefix for DJN (http://en.djnlcd.com/).
Acked-by: Krzysztof Kozlowski
Signed-off-by: Luca Weiss
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml
b/Documentation
Hi Greet,
Thanks for your confirmation and suggestions.
I added this patch based on existing checks on var->pixclock in other drivers,
such as savagefb_check_var, nvidiafb_check_var, etc.
Are you suggesting that it is better to replace an invalid value (var->pixclock
== 0) with a default valid
Hi Janusz,
[...]
> 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 the commit title.
Otherwise, the patch looks good to me.
Reviewed-by: Nitin Gote
Hi
Am 11.06.25 um 14:47 schrieb Javier Martinez Canillas:
John Keeping writes:
Hello John,
The number of columns relates to the width, not the height. Use the
correct variable.
Signed-off-by: John Keeping
---
drivers/gpu/drm/solomon/ssd130x.c | 2 +-
1 file changed, 1 insertion(+), 1 d
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:
>>
>> The GPU node will depend on the AON node, which will be the sole
>>
On 6/10/2025 4:36 PM, Stephen Rothwell wrote:
Hi Jeff,
On Tue, 10 Jun 2025 11:59:12 -0600 Jeff Hugo wrote:
pci_printk() was removed with commit 1c8a0ed2043c ("PCI: Remove unused
pci_printk()")
so change to using dev_printk().
Fixes: c11a50b170e7 ("accel/qaic: Add Reliability, Accessibility,
On 11/06/2025 15:21, Christian König wrote:
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 mor
On Wed, Jun 11, 2025 at 04:57:50PM +0200, Christian König wrote:
> 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/a
On Wed, Jun 11, 2025 at 01:04:14PM +0100, Diogo Ivo wrote:
>
>
> 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.
> > >
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 NVJPG hardwa
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
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 -
>> >
When waiting on syncobjs the current code allocates a temporary array only
to fill it up with all zeros.
We can avoid that by relying on the allocated entry array already being
zero allocated.
For the timeline mode we can fetch the timeline point values as we
populate the entries array so also do
On Wed, Jun 11, 2025 at 08:08:49PM +0800, Yongxing Mou wrote:
>
>
> 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, Yongxi
On Wed, Jun 11, 2025 at 08:06:28PM +0800, Yongxing Mou wrote:
>
>
> 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 th
On Wed, Jun 11, 2025 at 07:39:24PM +0800, Yongxing Mou wrote:
>
>
> 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 t
(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 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
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 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
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 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
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
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
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
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
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
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 Mon, May 26, 2025 at 11:56:50PM -0700, Amirreza Zarrabi wrote:
> Increase TEE_MAX_ARG_SIZE to accommodate worst-case scenarios where
> additional buffer space is required to pass all arguments to TEE.
> This change is necessary for upcoming support for Qualcomm TEE, which
> requires a larger buf
On Fri, May 30, 2025 at 05:54:32PM +0800, Yongbang Shi wrote:
From: Baihan Li
When using command rmmod and insmod, there is no showing in second time
insmoding. Because DP controller won't send HPD signals, if connection
doesn't change or controller isn't reset. So add reset before unreset
i
Hi Deiderik and Piotr,
At 2025-06-11 20:26:38, "Diederik de Haas" wrote:
>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" wro
John Keeping writes:
Hello John,
> The number of columns relates to the width, not the height. Use the
> correct variable.
>
> Signed-off-by: John Keeping
> ---
> drivers/gpu/drm/solomon/ssd130x.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/solomon
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
1 - 100 of 164 matches
Mail list logo
