On 19/08/2025 10:26, Mike Looijmans wrote:
> On 19-08-2025 09:51, Krzysztof Kozlowski wrote:
>> On 19/08/2025 09:46, Mike Looijmans wrote:
> +
> +properties:
> + compatible:
> +enum:
> + - ti,tmds181
> + - ti,sn65dp159
The driver contains:
+ { .comp
вт, 19 серп. 2025 р. о 23:30 Rob Herring пише:
>
> On Tue, Aug 19, 2025 at 03:16:29PM +0300, Svyatoslav Ryhel wrote:
> > Document CSI hw block found in Tegra20 and Tegra30 SoC.
> >
> > Signed-off-by: Svyatoslav Ryhel
> > ---
> > .../display/tegra/nvidia,tegra210-csi.yaml| 78 +++-
вт, 19 серп. 2025 р. о 23:27 Rob Herring пише:
>
> On Tue, Aug 19, 2025 at 03:16:16PM +0300, Svyatoslav Ryhel wrote:
> > Parallel VI interface found in Tegra30 is exactly the same as Tegra20 has.
>
> That's not what the compatible schema says. 'exactly the same' implies a
> fallback to whatever it
On 8/19/25 06:54, Dmitry Baryshkov wrote:
On Mon, Aug 18, 2025 at 09:17:44PM +0530, Harikrishna Shenoy wrote:
Add RPi DSI panel[0] as a valid compatible for simple-panel.
[0]: https://www.raspberrypi.com/products/raspberry-pi-touch-display/
Signed-off-by: Harikrishna Shenoy
---
.../device
On 8/19/25 21:50, Rob Herring wrote:
On Tue, Aug 19, 2025 at 12:58:59PM +0200, Maud Spierings wrote:
The Maxim MAX25014 is a 4-channel automotive grade backlight driver IC
with intgrated boost controller.
Signed-off-by: Maud Spierings
---
.../bindings/leds/backlight/maxim,max25014.yaml|
On 08/19/2025, Dmitry Baryshkov wrote:
[...]
> @@ -930,23 +947,29 @@ static int write_device_infoframe(struct drm_connector
> *connector,
> union hdmi_infoframe *frame)
> {
> const struct drm_connector_hdmi_funcs *funcs = connector->hdmi.funcs;
> + enum
On Tue, 19 Aug, 2025 11:06:40 +0200 "Maxime Ripard" wrote:
> Hi Rahul,
>
> On Mon, Aug 18, 2025 at 05:04:15AM +, Rahul Rameshbabu wrote:
>> I am working on a drm_connector scoped backlight API in Rust. I have been
>> looking through Hans de Goede's previous efforts on this topic to help
>> gui
On 08/19/2025, Dmitry Baryshkov wrote:
> Now as all bridges are updated to list supported HDMI InfoFrames, drop
> the default value from drm_bridge_connector_init(). All HDMI bridges now
> have to declare all supported InfoFrames.
>
> Signed-off-by: Dmitry Baryshkov
> ---
> drivers/gpu/drm/displ
On 08/19/2025, Dmitry Baryshkov wrote:
> Declare which infoframes are supported via the .hdmi_write_infoframe()
> interface.
>
> Signed-off-by: Dmitry Baryshkov
> ---
> drivers/gpu/drm/rockchip/rk3066_hdmi.c | 1 +
> 1 file changed, 1 insertion(+)
Reviewed-by: Liu Ying
On 08/19/2025, Dmitry Baryshkov wrote:
> Declare which infoframes are supported via the .hdmi_write_infoframe()
> interface.
>
> Signed-off-by: Dmitry Baryshkov
> ---
> drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 4
> 1 file changed, 4 insertions(+)
Reviewed-by: Liu Ying
On 08/19/2025, Dmitry Baryshkov wrote:
> Declare which infoframes are supported via the .hdmi_write_infoframe()
> interface.
>
> Signed-off-by: Dmitry Baryshkov
> ---
> drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridg
On 08/19/2025, Dmitry Baryshkov wrote:
> Declare which infoframes are supported via the .hdmi_write_infoframe()
> interface.
>
> Signed-off-by: Dmitry Baryshkov
> ---
> drivers/gpu/drm/bridge/lontium-lt9611.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/lo
On 08/19/2025, Dmitry Baryshkov wrote:
> Currently DRM framework expects that the HDMI connector driver supports
> all infoframe types: it generates the data as required and calls into
> the driver to program all of them, letting the driver to soft-fail if
> the infoframe is unsupported. This has a
On 08/19/2025, Dmitry Baryshkov wrote:
> Declare which infoframes are supported via the .hdmi_write_infoframe()
> interface. Audio infoframe is handled separately.
>
> Signed-off-by: Dmitry Baryshkov
> ---
> drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 1 +
> 1 file changed, 1 insertion(+)
Re
On 08/19/2025, Dmitry Baryshkov wrote:
> On 19/08/2025 12:49, Liu Ying wrote:
>> Hi Dmitry,
>>
>> On 08/16/2025, Dmitry Baryshkov wrote:
>>> Declare which infoframes are supported via the .hdmi_write_infoframe()
>>> interface.
>>>
>>> Signed-off-by: Dmitry Baryshkov
>>> ---
>>> drivers/gpu/drm/b
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/nova/file.rs
between commit:
db2e7bcee11c ("drm: nova-drm: fix 32-bit arm build")
from the drm-misc-fixes tree and commit:
94febfb5bcfb ("rust: drm: Drop the use of Opaque for ioctl arguments")
from the
From: Dang Huynh
Add initial support for MSM8937 SoC.
Signed-off-by: Dang Huynh
Co-developed-by: Barnabás Czémán
Signed-off-by: Barnabás Czémán
---
arch/arm64/boot/dts/qcom/msm8937.dtsi | 2134 +
1 file changed, 2134 insertions(+)
diff --git a/arch/arm64/boot
Add initial support for Xiaomi Redmi 3S (land).
Reviewed-by: Konrad Dybcio
Signed-off-by: Barnabás Czémán
---
arch/arm64/boot/dts/qcom/Makefile| 1 +
arch/arm64/boot/dts/qcom/msm8937-xiaomi-land.dts | 381 +++
2 files changed, 382 insertions(+)
diff --git
Descirbe A505 clocks it is using same clocks like A506.
Signed-off-by: Barnabás Czémán
---
Documentation/devicetree/bindings/display/msm/gpu.yaml | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/display/msm/gpu.yaml
b/Documentation/devicet
This patch series add initial support for MSM8937 SoC
and Xiaomi Redmi 3S (land).
The series is extending the MSM8917 gcc and pinctrl drivers
because they are sibling SoCs.
MSM8937 have 4 more A53 cores and have one more dsi port then
MSM8917.
It implements little-big architecture and uses Adreno
From: Daniil Titov
Modify existing MSM8917 driver to support MSM8937 SoC. Override frequencies
which are different in this chip. Register all the clocks to the framework
for the clients to be able to request for them. Add new variant of GDSC for
new chip.
Signed-off-by: Daniil Titov
Reviewed-by
Add device tree bindings for the global clock controller on Qualcomm
MSM8937 platform.
Reviewed-by: Krzysztof Kozlowski
Signed-off-by: Barnabás Czémán
---
.../devicetree/bindings/clock/qcom,gcc-msm8953.yaml | 11 ---
include/dt-bindings/clock/qcom,gcc-msm8917.h | 19 +
Document Xiaomi Redmi 3S (land).
Add qcom,msm8937 for msm-id, board-id allow-list.
Acked-by: Krzysztof Kozlowski
Signed-off-by: Barnabás Czémán
---
Documentation/devicetree/bindings/arm/qcom.yaml | 6 ++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/qco
If we fail a handle-lookup part way thru, we need to drop the already
obtained obj references.
Fixes: 2e6a8a1fe2b2 ("drm/msm: Add VM_BIND ioctl")
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem_vma.c | 25 +++--
1 file changed, 19 insertions(+), 6 deletions(-)
diff
Hi Mike,
kernel test robot noticed the following build errors:
[auto build test ERROR on 53e760d8949895390e256e723e7ee46618310361]
url:
https://github.com/intel-lab-lkp/linux/commits/Mike-Looijmans/dt-bindings-drm-bridge-ti-tmds181-Add-TI-TMDS181-and-SN65DP159-bindings/20250819-133458
base
Fixes for a few issues found in vkd3d-proton testing.
Rob Clark (3):
drm/msm: Fix obj leak in VM_BIND error path
drm/msm: Fix missing VM_BIND offset/range validation
drm/msm: Fix 32b size truncation
drivers/gpu/drm/msm/msm_gem.c | 17 -
drivers/gpu/drm/msm/msm_gem.h
We need to reject the MAP op if offset+range is larger than the BO size.
Reported-by: Connor Abbott
Fixes: 2e6a8a1fe2b2 ("drm/msm: Add VM_BIND ioctl")
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem_vma.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm
Somehow we never noticed this when arm64 became a thing, many years ago.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 17 -
drivers/gpu/drm/msm/msm_gem.h | 6 +++---
2 files changed, 11 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/
On Tue, Aug 19, 2025 at 08:26:43PM +0530, Kaustabh Chakraborty wrote:
> Synaptics' Touch and Display Driver Integration (TDDI) technology [1]
> employs a single chip for both touchscreen and display capabilities.
> Such designs reportedly help reducing costs and power consumption.
>
> Although the
In an effort to make the existing compatibles more usable, we are
removing the max_pclk_khz form dispc_features structure and doing the
supported pixel clock checks using "max_successful_rate[]" and
"max_attempted_rate[]".
Changes are fully backwards compatible.
After integration of OLDI support[
On Fri Aug 15, 2025 at 5:50 AM CEST, Alex Hung wrote:
> We've previously introduced DRM_COLOROP_1D_CURVE for
> pre-defined 1D curves. But we also have HW that supports
> custom curves and userspace needs the ability to pass
> custom curves, aka LUTs.
>
> This patch introduces a new colorop type, ca
On Fri Aug 15, 2025 at 5:49 AM CEST, Alex Hung wrote:
> From: Harry Wentland
>
> We want to be able to bypass each colorop at all times.
> Introduce a new BYPASS boolean property for this.
>
> Reviewed-by: Simon Ser
> Reviewed-by: Louis Chauvet
> Signed-off-by: Alex Hung
> Signed-off-by: Harry
On Fri Aug 15, 2025 at 5:49 AM CEST, Alex Hung wrote:
> From: Harry Wentland
>
> Add a new drm_colorop with DRM_COLOROP_1D_CURVE with two subtypes:
> DRM_COLOROP_1D_CURVE_SRGB_EOTF and DRM_COLOROP_1D_CURVE_SRGB_INV_EOTF.
>
> Reviewed-by: Simon Ser
> Reviewed-by: Louis Chauvet
> Signed-off-by: Ha
From: Jayesh Choudhary
Since OLDI consumes DSS VP clock directly as serial clock, certain
checks cannot be performed in tidss driver which should be checked
in OLDI driver. Add check for mode clock and set max_successful_rate
and max_attempted_rate field for tidss in case the VP is OLDI.
Fixes:
From: Jayesh Choudhary
TIDSS hardware by itself does not have variable max_pclk for each VP.
The maximum pixel clock is determined by the limiting factor between
the functional clock and the PLL (parent to the VP/pixel clock).
The limitation that has been modeled till now comes from the clock
(P
From: Jayesh Choudhary
TIDSS should know which VP has OLDI output to avoid calling clock
functions for that VP as those are controlled by OLDI driver. Add a
property "is_ext_vp_clk" to "tidss_device" structure for that. Mark it
'true' in tidss_oldi_init() and 'false' in tidss_oldi_deinit().
Fixe
On 15.08.2025 04:59, Damon Ding wrote:
> On 2025/8/15 5:16, Marek Szyprowski wrote:
>> On 14.08.2025 16:33, Marek Szyprowski wrote:
>>> On 14.08.2025 12:47, Damon Ding wrote:
PATCH 1 is a small format optimization for struct analogid_dp_device.
PATCH 2 is to perform mode setting in &drm_b
Use drmm_plain_encoder_alloc() to allocate simple encoder and
drmm_writeback_connector_init() in order to initialize writeback
connector instance.
Reviewed-by: Suraj Kandpal
Reviewed-by: Louis Chauvet
Signed-off-by: Dmitry Baryshkov
---
.../gpu/drm/renesas/rcar-du/rcar_du_writeback.c| 23 +
Drivers using drm_writeback_connector_init() / _with_encoder() don't
perform cleanup in a manner similar to drmm_writeback_connector_init()
(see drm_writeback_connector_cleanup()). Migrate all existing drivers
to use drmm_writeback_connector_init(), drop
drm_writeback_connector_init() and drm_write
Use drmm_plain_encoder_alloc() to allocate simple encoder and
drmm_writeback_connector_init() in order to initialize writeback
connector instance.
Reviewed-by: Suraj Kandpal
Reviewed-by: Louis Chauvet
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/arm/malidp_mw.c | 25 ++--
Rename drm_writeback_connector_init_with_encoder() to
drm_writeback_connector_init() and adapt its interface to follow
drmm_writeback_connector_init().
Reviewed-by: Suraj Kandpal
Reviewed-by: Louis Chauvet
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/drm_writeback.c | 14 +++---
Use drmm_plain_encoder_alloc() to allocate simple encoder and
drmm_writeback_connector_init() in order to initialize writeback
connector instance.
Reviewed-by: Louis Chauvet
Reviewed-by: Suraj Kandpal
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/vc4/vc4_txp.c | 9 -
1 file chang
Now as all drivers have been converted to
drmm_writeback_connector_init(), drop drm_writeback_connector_init() and
drm_writeback_connector::encoder field, they are unused now.
Reviewed-by: Suraj Kandpal
Reviewed-by: Louis Chauvet
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/drm_writebac
Use drmm_plain_encoder_alloc() to allocate simple encoder and
drmm_writeback_connector_init() in order to initialize writeback
connector instance.
Reviewed-by: Louis Chauvet
Reviewed-by: Suraj Kandpal
Reviewed-by: Jessica Zhang
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1
Use drmm_plain_encoder_alloc() to allocate simple encoder and
drmm_writeback_connector_init() in order to initialize writeback
connector instance.
Reviewed-by: Suraj Kandpal
Reviewed-by: Louis Chauvet
Signed-off-by: Dmitry Baryshkov
---
.../drm/arm/display/komeda/komeda_wb_connector.c | 30 +
Use drmm_plain_encoder_alloc() to allocate simple encoder and
drmm_writeback_connector_init() in order to initialize writeback
connector instance.
Reviewed-by: Louis Chauvet
Reviewed-by: Suraj Kandpal
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c| 2
On Tue, Aug 19, 2025 at 03:16:29PM +0300, Svyatoslav Ryhel wrote:
> Document CSI hw block found in Tegra20 and Tegra30 SoC.
>
> Signed-off-by: Svyatoslav Ryhel
> ---
> .../display/tegra/nvidia,tegra210-csi.yaml| 78 +++
> 1 file changed, 63 insertions(+), 15 deletions(-)
>
>
On Tue, Aug 19, 2025 at 03:16:16PM +0300, Svyatoslav Ryhel wrote:
> Parallel VI interface found in Tegra30 is exactly the same as Tegra20 has.
That's not what the compatible schema says. 'exactly the same' implies a
fallback to whatever it is exactly the same as.
>
> Signed-off-by: Svyatoslav R
On 8/19/2025 2:11 PM, Athul Raj Kollareth wrote:
> Replace the DRM_* logging macros used in gem helper files with the appropriate
> ones specified in /include/drm/drm_print.h.
>
> Signed-off-by: Athul Raj Kollareth
> ---
> Changes in v3:
> - Revert all changes to drm_gem_objects_lookup()
>
On Tue, Aug 19, 2025 at 12:58:59PM +0200, Maud Spierings wrote:
> The Maxim MAX25014 is a 4-channel automotive grade backlight driver IC
> with intgrated boost controller.
>
> Signed-off-by: Maud Spierings
> ---
> .../bindings/leds/backlight/maxim,max25014.yaml| 79
> ++
On Tue, Aug 19, 2025 at 09:31:05AM +0800, Jun Nie wrote:
> Currently, SSPPs are assigned to a maximum of two pipes. However,
> quad-pipe usage scenarios require four pipes and involve configuring
> two stages. In quad-pipe case, the first two pipes share a set of
> mixer configurations and enable m
Now as all bridges are updated to list supported HDMI InfoFrames, drop
the default value from drm_bridge_connector_init(). All HDMI bridges now
have to declare all supported InfoFrames.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/display/drm_bridge_connector.c | 7 +--
1 file changed
Declare which infoframes are supported via the .hdmi_write_infoframe()
interface.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/rockchip/rk3066_hdmi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/rockchip/rk3066_hdmi.c
b/drivers/gpu/drm/rockchip/rk3066_hdmi.c
index
Declare which infoframes are supported via the .hdmi_write_infoframe()
interface. Audio infoframe is handled separately.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv
It's not uncommon for the particular device to support only a subset of
HDMI InfoFrames. It's not a big problem for the kernel, since we adopted
a model of ignoring the unsupported Infoframes, but it's a bigger
problem for the userspace: we end up having files in debugfs which do
mot match what is
Declare which infoframes are supported via the .hdmi_write_infoframe()
interface.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/bridge/lontium-lt9611.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/bridge/lontium-lt9611.c
b/drivers/gpu/drm/bridge/lontium-lt9611.c
Declare which infoframes are supported via the .hdmi_write_infoframe()
interface.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
b/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
in
Declare which infoframes are supported via the .hdmi_write_infoframe()
interface.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c
b/drivers/gpu/drm/bridge/synopsy
Declare which infoframes are supported via the .hdmi_write_infoframe()
interface.
Reviewed-by: Liu Ying
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/bridge/ite-it6263.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/bridge/ite-it6263.c
b/drivers/gpu/drm/bridge/ite-i
Currently DRM framework expects that the HDMI connector driver supports
all infoframe types: it generates the data as required and calls into
the driver to program all of them, letting the driver to soft-fail if
the infoframe is unsupported. This has a major drawback on userspace
API: the framework
amdgpu_dm_connector_ddc_get_modes() reinitializes a connector's probed
modes list without cleaning it up. First time it is called during the
driver's initialization phase, then via drm_mode_getconnector() ioctl.
The leaks observed with Kmemleak are as following:
unreferenced object 0x88812f91b
This functionality may be helpful in drivers so export it for reusability.
Found by Linux Verification Center (linuxtesting.org).
Signed-off-by: Fedor Pchelkin
---
drivers/gpu/drm/drm_connector.c | 8 +---
drivers/gpu/drm/drm_modes.c | 15 +++
include/drm/drm_modes.h
The first patch is a prerequisite exporting a convenient helper at
include/drm/modes.h used in the second one fixing a leak in amdgpu
driver.
v1: https://lore.kernel.org/all/20250817094346.15740-1-pchel...@ispras.ru/
Fedor Pchelkin (2):
drm/modes: export drm_mode_remove() helper
drm/amd/displ
From: Andi Shyti
Coverity warns that 'cap' may be used uninitialised. If pcode
is disabled there is no need to go through the hassle of a
pcode read or taking a PM reference.
Check skip_pcode early in the function and return if it is set.
No change for platforms where pcode is enabled.
Signed-
On Monday, July 7, 2025 6:58 PM Mikko Perttunen wrote:
> From: Mikko Perttunen
>
> Optimize performance of syncpoint interrupt handling by reading
> the status register in 64-bit chunks when possible, and skipping
> processing when the read value is zero.
>
> Signed-off-by: Mikko Perttunen
> --
On 19/08/2025 3:44 am, kernel test robot wrote:
Hello,
kernel test robot noticed "BUG:unable_to_handle_page_fault_for_address" on:
commit: 1ba20479196e5af3ebbedf9321de6b26f2a0cdd3 ("[PATCH 19/19] perf:
Garbage-collect event_init checks")
url:
https://github.com/intel-lab-lkp/linux/commits/R
On Tue, Aug 19, 2025 at 10:26:15AM +0200, Mike Looijmans wrote:
> On 19-08-2025 09:51, Krzysztof Kozlowski wrote:
> > On 19/08/2025 09:46, Mike Looijmans wrote:
> > > > > +
> > > > > +properties:
> > > > > + compatible:
> > > > > +enum:
> > > > > + - ti,tmds181
> > > > > + - ti,sn65d
On Mon, 18. Aug 21:17, Limonciello, Mario wrote:
> On 8/17/25 4:43 AM, Fedor Pchelkin wrote:
> > For what the patch does there exists a drm_mode_remove() helper but it's
> > static at drivers/gpu/drm/drm_connector.c and requires to be exported
> > first. This probably looks like a subject for an in
Hi, Maarten,
On Tue, 2025-08-19 at 13:49 +0200, Maarten Lankhorst wrote:
> Add an option to pin memory through the science of cgroup accounting.
> A bo will be pinned for its entire lifetime, and this allows buffers
> that are pinned for dma-buf export without requiring the pinning to
> be
> done
> The header file is already included on line 8. Remove the
> redundant include.
You would like to omit a duplicate #include directive, don't you?
Will a corresponding refinement become helpful for the summary phrase
and change description?
Regards,
Markus
Am 09.04.25 um 18:27 schrieb Werner Sembach:
The display backlight on TUXEDO Polaris AMD Gen2 and Gen3 with panels
BOE 2420 and BOE 2423 must be forced to pwn controlled to be able to
control the brightness.
This could already be archived via a module parameter, but this patch adds
a quirk to
Hi Maxime,
On Tue, 19 Aug 2025 15:47:06 +0200
Maxime Ripard wrote:
> > +/**
> > + * drm_for_each_bridge_in_chain_scoped - iterate over all bridges attached
> > + * to an encoder
> > + * @encoder: the encoder to iterate bridges on
> > + * @bridge: a bridge po
Boolean flag access from interrupt context might have synchronous issue on
multiple processor platform, flage modified by one core might be read as an
old value by another core. This issue on interrupt enable flag might causes
interrupt missing or leakage.
Fixed by change the data type as automic t
The drm_gpusvm_for_each_notifier, drm_gpusvm_for_each_notifier_safe and
drm_gpusvm_for_each_range_safe macros are useful for locating notifiers
and ranges within a user-specified range. By making these macros public,
we enable broader access and utility for developers who need to leverage
them in t
From: Boris Brezillon
drm_gpuva_init() only has one internal user, and given we are about to
add new optional fields, it only add maintenance burden for no real
benefit, so let's kill the thing now.
Cc: Danilo Krummrich
Cc: Rob Clark
Signed-off-by: Boris Brezillon
Acked-by: Danilo Krummrich
This ops is used to iterate over GPUVA's in the user-provided range
and split the existing sparse VMA's if the start or end of the input
range lies within it. The operations can create up to 2 REMAPS and 2 MAPs.
The primary use case is for drivers to assign attributes to GPU VAs in
the specified r
From: Boris Brezillon
We are about to pass more arguments to drm_gpuvm_sm_map[_ops_create](),
so, before we do that, let's pass arguments through a struct instead
of changing each call site every time a new optional argument is added.
Cc: Danilo Krummrich
Cc: Brendan King
Cc: Matt Coster
Cc:
This series contains a set of patches that modify files outside the Xe
driver to enable support for MADVISE [1] in the Xe subsystem. These
patches are being submitted for merging via drm-misc.
Once these patches are backmerged into drm-xe-next, the remaining
patches from the MADVISE [1] series wil
Hello,
syzbot found the following issue on:
HEAD commit:2674d1eadaa2 Add linux-next specific files for 20250812
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=10c12af058
kernel config: https://syzkaller.appspot.com/x/.config?x=712e4169f26d539a
dashbo
On Tue, Aug 19, 2025 at 04:27:08PM +0100, Matthew Auld wrote:
> This should be enough to get scripts/kernel-doc passing for
> drm_gpusvm.[ch], so we can then add them to our CI build infra.
>
> v2:
> - Also drop misplaced range_evict()
>
> Link: https://gitlab.freedesktop.org/drm/xe/ci/-/merge_r
On Tue, Aug 19, 2025 at 01:33:40PM +0200, Thomas Hellström wrote:
> On Tue, 2025-08-19 at 19:55 +1000, Alistair Popple wrote:
> > On Mon, Aug 18, 2025 at 01:46:55PM -0300, Jason Gunthorpe wrote:
> > > On Mon, Aug 18, 2025 at 09:44:01AM -0700, Matthew Brost wrote:
> > > > On Mon, Aug 18, 2025 at 01:
This should be enough to get scripts/kernel-doc passing for
drm_gpusvm.[ch], so we can then add them to our CI build infra.
v2:
- Also drop misplaced range_evict()
Link: https://gitlab.freedesktop.org/drm/xe/ci/-/merge_requests/86
Signed-off-by: Matthew Auld
Cc: Matthew Brost
---
drivers/gpu/
Applied. Thanks!
On Tue, Aug 19, 2025 at 10:33 AM Liao Yuanhong wrote:
>
> The header file "dc_stream.h" is already included on line 1507. Remove the
> redundant include.
>
> This is because the header file was initially included towards the latter
> part of the code. Subsequent commits had to i
Synaptics TDDI (Touch/Display Integration) panels utilize a single chip
for display and touch controllers. Implement a simple device driver for
such panels, along with its built-in LED backlight controller, and add
support for TD4101 and TD4300 panels in the driver.
Signed-off-by: Kaustabh Chakrab
Document the Synaptics TDDI (Touch/Display Integration) panel hardware.
Along with the MIPI-DSI panel, these devices also have an in-built LED
backlight device and a touchscreen, all packed together in a single chip.
Also, add compatibles for supported panels - TD4101 and TD4300. Both
have the '-p
Synaptics' Touch and Display Driver Integration (TDDI) technology [1]
employs a single chip for both touchscreen and display capabilities.
Such designs reportedly help reducing costs and power consumption.
Although the touchscreens, which are powered by Synaptics'
Register-Mapped Interface 4 (RMI4
On Tue, Aug 19, 2025 at 03:48:08PM +0200, Geert Uytterhoeven wrote:
> On Mon, 28 Jul 2025 at 22:14, Prabhakar wrote:
> > From: Lad Prabhakar
> >
> > This patch series adds DU/DSI clocks and provides support for the
> > MIPI DSI interface on the RZ/V2H(P) SoC. It was originally part of
> > series [
On 8/19/25 8:08 AM, Nishanth Menon wrote:
The driver knows exactly which version of the chip is present since
the vid/pid is used to enforce a compatibility. Given that some
devices like IT66121 has potentially been replaced with IT66122 mid
production for many platforms, it makes no sense to use
On Mon, 18 Aug 2025 16:54:23 +0530 Meghana Malladi wrote:
> @@ -1332,6 +1350,13 @@ static int prueth_xsk_wakeup(struct net_device *ndev,
> u32 qid, u32 flags)
> }
> }
>
> + if (flags & XDP_WAKEUP_RX) {
> + if (!napi_if_scheduled_mark_missed(&emac->napi_rx)) {
On 19/08/2025 15:26, Liao Yuanhong wrote:
The header file is already included on line 8. Remove the
redundant include.
Fixes: 5a99350794fec ("drm/sched: Add scheduler unit testing infrastructure and some
basic tests")
Signed-off-by: Liao Yuanhong
---
drivers/gpu/drm/scheduler/tests/sched_
The header file is already included on line 8. Remove the
redundant include.
Fixes: 5a99350794fec ("drm/sched: Add scheduler unit testing infrastructure and
some basic tests")
Signed-off-by: Liao Yuanhong
---
drivers/gpu/drm/scheduler/tests/sched_tests.h | 1 -
1 file changed, 1 deletion(-)
d
On 19-08-2025 15:22, Maxime Ripard wrote:
On Tue, Aug 19, 2025 at 07:31:15AM +0200, Mike Looijmans wrote:
The tmds181 and sn65dp159 are "retimers" and hence can be considered
HDMI-to-HDMI bridges. Typical usage is to convert the output of an
FPGA into a valid HDMI signal, and it will typically b
The header file "dc_stream.h" is already included on line 1507. Remove the
redundant include.
This is because the header file was initially included towards the latter
part of the code. Subsequent commits had to include the header file again
earlier in the code. In my opinion, this doesn't count a
This should be enough to get scripts/kernel-doc passing for
drm_gpusvm.[ch], so we can then add them to our CI build infra.
Link: https://gitlab.freedesktop.org/drm/xe/ci/-/merge_requests/86
Signed-off-by: Matthew Auld
Cc: Matthew Brost
---
drivers/gpu/drm/drm_gpusvm.c | 4 ++--
1 file changed,
On Tue, 19 Aug 2025 11:15:54 +0200, Raphael Gallais-Pou wrote:
> The new STMicroelectronics SoC features a display controller similar to
> the one used in previous SoCs. Because there is additional registers,
> it is incompatible with existing IPs.
>
> Add the new name to the list of compatible
On Tue, Aug 19, 2025 at 03:17:46PM +0200, Raphael Gallais-Pou wrote:
>
>
> On 8/19/25 13:01, Rob Herring (Arm) wrote:
> > On Tue, 19 Aug 2025 11:15:54 +0200, Raphael Gallais-Pou wrote:
> >> The new STMicroelectronics SoC features a display controller similar to
> >> the one used in previous SoCs.
On Fri, 1 Aug 2025 19:05:31 +0200, Luca Ceresoli wrote:
> The bridge returned by drm_bridge_get_next_bridge() is refcounted. Put it
> when done. We need to ensure it is not put before either next_bridge or
> next_bridge_state is in use, thus for simplicity use a cleanup action.
>
> Signed-off-by:
On Fri, 1 Aug 2025 19:05:30 +0200, Luca Ceresoli wrote:
> The bridge returned by drm_bridge_get_next_bridge() is refcounted. Put it
> when done. We need to ensure it is not put before either next_bridge or
> next_bridge_state is in use, thus for simplicity use a cleanup action.
>
> Signed-off-by:
On Fri, 1 Aug 2025 19:05:26 +0200, Luca Ceresoli wrote:
> Use drm_bridge_chain_get_last_bridge() instead of open coding a loop with
> two invocations of drm_bridge_get_next_bridge() per iteration.
>
> Besides being cleaner and more efficient, this change is necessary in
> preparation for drm_bridg
1 - 100 of 229 matches
Mail list logo
