Hi
Am 05.02.25 um 21:08 schrieb Anusha Srivatsa:
Update the Documentation to be more precise.
v2: Update for clarity
Cc: Thomas Zimmermann
Signed-off-by: Anusha Srivatsa
---
Documentation/gpu/todo.rst | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/Docume
On 05/02/2025 23:10, Sasha Finkelstein via B4 Relay wrote:
Hi.
This patch series adds support for a secondary display controller
present on Apple M1/M2 chips and used to drive the display of the
"touchbar" touch panel present on those.
Signed-off-by: Sasha Finkelstein
---
LGTM should patches
On 05/02/2025 23:10, Sasha Finkelstein via B4 Relay wrote:
From: Sasha Finkelstein
This is the display panel used for the touchbar on laptops that have it.
Co-developed-by: Nick Chan
Signed-off-by: Nick Chan
Signed-off-by: Sasha Finkelstein
---
drivers/gpu/drm/panel/Kconfig| 9 +
From: Shixiong Ou
convert to use devm_platform_ioremap_resource().
Signed-off-by: Shixiong Ou
---
drivers/gpu/drm/bridge/microchip-lvds.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/microchip-lvds.c
b/drivers/gpu/drm/bridge/microchip-lvds.c
ind
> -Original Message-
> From: Kandpal, Suraj
> Sent: Thursday, February 6, 2025 12:03 PM
> To: intel...@lists.freedesktop.org; intel-...@lists.freedesktop.org; dri-
> de...@lists.freedesktop.org
> Cc: Shankar, Uma ; Murthy, Arun R
> ; Kao, Ben ; Kandpal, Suraj
>
> Subject: [PATCH 1/8] d
> Check if we are capable of controlling brightness via luminance which is
> dependent on PANEL_LUMINANCE_CONTROL_CAPABLE bit being set on
> EDP_GENERAL_CAPABILITY_2 register.
>
> --v2
> -Prefer using luminance rather than nits [Jani] -Fix commit message
>
> --v3
> -Fix the bit name used in commi
From: Andy Yan
VOP2 on rk3576:
Three video ports:
VP0 Max 4096x2160
VP1 Max 2560x1600
VP2 Max 1920x1080
2 4K Cluster windows with AFBC/RFBC, line RGB and YUV
4 Esmart windows with line RGB/YUV support:
Esmart0/1: 4K
Esmart2/3: 2k, or worked together as a single 4K plane at shared
line buffer mod
> eDP is supposed to use VESA interface when using revision 1.5 and above, use
> Intel interface for backlight control otherwise. Add check to use correct
> interface.
>
> Signed-off-by: Suraj Kandpal
> Tested-by: Ben Kao
> ---
Reviewed-by: Arun R Murthy
Thanks and Regards,
Arun R Murthy
-
From: Andy Yan
Add vop found on rk3576, the main difference between rk3576 and the
previous vop is that each VP has its own interrupt line.
Signed-off-by: Andy Yan
---
Changes in v13:
- Use maxItems constraint for clocks in allOf block
Changes in v12:
- Split from patch 10/13
Changes in v11
On Wed, Feb 05, 2025 at 01:44:48PM +0100, Christian König wrote:
> Am 05.02.25 um 12:14 schrieb Tvrtko Ursulin:
> > Christian suggests scheduler should not use the term TDR because it only
> > can do basic timeout detection on it's own, not the full blown timeout-
> > detection-and-recovery (TDR) a
From: Andy Yan
In the upcoming VOP of rk3576, a window cannot attach to all Video
Ports, we introduce a possible_vp_mask for every window to indicate
which Video Ports this window can attach to.
Signed-off-by: Andy Yan
Tested-by: Michael Riesch # on RK3568
Tested-by: Detlev Casanova
---
(no
From: Andy Yan
PATCH 1~9 are preparations for rk3576 support
PATCH 10~13 are real support for rk376
I test it with a 1080P/4K HDMI output with modetest and weston
output.
If there are some one want to have a try, I have a tree based on
Linux 6.14-rc1 here[0]
[0]https://github.com/andyshrk/lin
> -Original Message-
> From: Murthy, Arun R
> Sent: Thursday, February 6, 2025 12:13 PM
> To: Kandpal, Suraj ; intel...@lists.freedesktop.org;
> intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> Cc: Shankar, Uma ; Kao, Ben
> Subject: RE: [PATCH 2/8] drm/dp: Increase eD
From: Andy Yan
In the upcoming VOP for rk3576, every VP has it's own LAYER_SEL
register, and the configuration value of each VP for the same
window maybe different, so extend the layer_sel_id to array,
let it can descption the layer select configuration value for
different VP.
Signed-off-by: And
From: Andy Yan
There is a version number hardcoded in the VOP VERSION_INFO
register, and the version number increments sequentially based
on the production order of the SOC.
So using this version number to distinguish different VOP features
will simplify the code.
Signed-off-by: Andy Yan
Teste
From: Andy Yan
This help avoid "exceeds 100 columns" warning from checkpatch
Signed-off-by: Andy Yan
---
(no changes since v1)
drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 8
drivers/gpu/drm/rockchip/rockchip_drm_vop2.h | 4 ++--
2 files changed, 6 insertions(+), 6 deletions(-)
d
From: Andy Yan
The clock polarity of RGB signal output is controlled by GRF, this
property is already being used in the current device tree, but
forgot to describe it as a required property in the binding file.
Signed-off-by: Andy Yan
---
Changes in v13:
- Fix typo
- Explain the function of t
From: Andy Yan
The VOP interface mux, overlay, background delay cycle configuration
of different SOC are much different. Add platform specific callback
ops to let the core driver look cleaner and more refined.
Signed-off-by: Andy Yan
Tested-by: Michael Riesch # on RK3568
Tested-by: Detlev Casa
From: Andy Yan
Now these two function share the same logic, the can
be merged as one.
Signed-off-by: Andy Yan
---
(no changes since v1)
drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 42 +---
1 file changed, 11 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/rock
From: Heiko Stuebner
Right now vop2_cluster_init() copies the base vop2_cluster_regs
and adapts the reg value with the current window's offset before
adding the fields to the regmap.
This conflicts with the notion of reg_fields being const, see
https://lore.kernel.org/all/20240706-regmap-const-s
From: Andy Yan
In the upcoming VOP of rk3576, a Window cannot attach to all Video Ports,
so make sure all VP find it's suitable primary plane, then register the
remain windows as overlay plane will make code easier.
Signed-off-by: Andy Yan
Tested-by: Michael Riesch # on RK3568
Tested-by: Detle
From: Andy Yan
The Cluster windows of upcoming VOP on rk3576 also support
linear YUV support, we need to set uv swap bit for it.
As the VOP2_WIN_UV_SWA register defined on rk3568/rk3588 is
0x, so this register will not be touched on these
two platforms.
Signed-off-by: Andy Yan
Tested-b
From: Andy Yan
As more SoCs variants are introduced, each SoC brings its own
unique set of constraints, describe this constraints SoC by
SoC will make things easier.
Signed-off-by: Andy Yan
---
Changes in v13:
- Add maxItems constraint for clocks
- Remove constraint for interrupts in allOf bl
>From eDP 1.5 we are supposed to use the VESA pathways to control
brightness. But still did not have the Nits brightness control coded
in. This series enables NITS based backlight control over AUX using
VESA pathways.
Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/3669
Signed-off-by
> Increase the eDP display control capability size to take into account the
> general
> capability register 703 and 704 that have recently been added.
>
> Signed-off-by: Suraj Kandpal
> ---
Reviewed-by: Arun R Murthy
Thanks and Regards,
Arun R Murthy
> include/drm/display
eDP is supposed to use VESA interface when using revision 1.5 and above,
use Intel interface for backlight control otherwise. Add check to
use correct interface.
Signed-off-by: Suraj Kandpal
Tested-by: Ben Kao
---
drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c | 8 +++-
1 file change
Create a function that fills in the value for
PANEL_TARGET_LUMINANCE_VALUE which helps in changing the luminance in
nits using VESA interface.
--v2
-Prefer using luminance over nits [Jani]
Signed-off-by: Suraj Kandpal
Tested-by: Ben Kao
Reviewed-by: Arun R Murthy
---
.../drm/i915/display/inte
On (25/02/03 10:39), Kirill A. Shutemov wrote:
> > Hi, I'm seeing following panic with SWAP after this commit:
> >
> > [ 29.672319] Oops: general protection fault, probably for
> > non-canonical address 0x88909a3be3: [#1] PREEMPT SMP NOPTI
> > [ 29.675503] CPU: 82 UID: 0 PID: 5145 Comm
Enable nits based luminance by writing the PANEL_LUMINANCE_CONTROL
bit and set the correct register to change brightness.
Signed-off-by: Suraj Kandpal
Tested-by: Ben Kao
Reviewed-by: Arun R Murthy
---
.../gpu/drm/i915/display/intel_dp_aux_backlight.c | 15 +++
1 file changed, 15 in
Check if we are capable of controlling brightness via luminance
which is dependent on PANEL_LUMINANCE_CONTROL_CAPABLE bit being set
on EDP_GENERAL_CAPABILITY_2 register.
--v2
-Prefer using luminance rather than nits [Jani]
-Fix commit message
--v3
-Fix the bit name used in commit message [Arun]
-
Modify vesa_get_brightness function to take into account
luminance_control_support and based on that read the appropriate
register and return the value.
--v2
-Changes since we now use luminance instead of nits
Signed-off-by: Suraj Kandpal
Tested-by: Ben Kao
Reviewed-by: Arun R Murthy
---
.../
Add the eDP revision bit value for 1.5.
Spec: eDPv1.5 Table 16-5
Signed-off-by: Suraj Kandpal
Reviewed-by: Arun R Murthy
Tested-by: Ben Kao
---
include/drm/display/drm_dp.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/drm/display/drm_dp.h b/include/drm/display/drm_dp.h
index 480
Modify backlight setup function for VESA interface to take into
account the nits based luminance.
--v2
-Prefer using luminance over nits [Jani]
Signed-off-by: Suraj Kandpal
Tested-by: Ben Kao
Reviewed-by: Arun R Murthy
---
.../drm/i915/display/intel_dp_aux_backlight.c | 99 +++
Increase the eDP display control capability size to take into
account the general capability register 703 and 704 that have
recently been added.
Signed-off-by: Suraj Kandpal
---
include/drm/display/drm_dp.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/display/d
> Enable nits based luminance by writing the PANEL_LUMINANCE_CONTROL bit
> and set the correct register to change brightness.
>
> Signed-off-by: Suraj Kandpal
> Tested-by: Ben Kao
> ---
Reviewed-by; Arun R Murthy
Thanks and Regards,
Arun R Murthy
---
> .../gpu/drm/i915/display
> > Create a function that fills in the value for
> > PANEL_TARGET_LUMINANCE_VALUE which helps in changing the luminance
> in nits using VESA interface.
> >
> > --v2
> > -Prefer using luminance over nits [Jani]
> >
> > Signed-off-by: Suraj Kandpal
> > Tested-by: Ben Kao
> > ---
> Reviewed-by: Aru
> Modify backlight setup function for VESA interface to take into account the
> nits
> based luminance.
>
> --v2
> -Prefer using luminance over nits [Jani]
>
> Signed-off-by: Suraj Kandpal
> Tested-by: Ben Kao
> ---
Reviewed-by: Arun R Murthy
Thanks and Regards,
Arun R Murthy
---
> -Original Message-
> From: Murthy, Arun R
> Sent: Wednesday, February 5, 2025 9:40 PM
> To: Kandpal, Suraj ; intel...@lists.freedesktop.org;
> intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> Cc: Shankar, Uma ; Nikula, Jani
> ; Kao, Ben
> Subject: RE: [PATCH 4/7] dr
> -Original Message-
> From: Murthy, Arun R
> Sent: Wednesday, February 5, 2025 8:14 PM
> To: Kandpal, Suraj ; intel...@lists.freedesktop.org;
> intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> Cc: Shankar, Uma ; Nikula, Jani
> ; Kao, Ben
> Subject: RE: [PATCH 3/7] dr
On Wed, Feb 05, 2025 at 11:10:51PM +0100, Sasha Finkelstein via B4 Relay wrote:
> From: Sasha Finkelstein
>
> This display controller is present on M-series chips and is used
> to drive the touchbar display.
>
> Co-developed-by: Janne Grunau
> Signed-off-by: Janne Grunau
> Signed-off-by: Sasha
On Wed, Feb 05, 2025 at 11:10:52PM +0100, Sasha Finkelstein via B4 Relay wrote:
> From: Sasha Finkelstein
>
> This is the display panel used for the touchbar on laptops that have it.
>
> Co-developed-by: Nick Chan
> Signed-off-by: Nick Chan
> Signed-off-by: Sasha Finkelstein
> ---
> drivers/
Picked from:
https://patchwork.kernel.org/project/linux-rockchip/list/?series=927102
The hdptxphy is a combo transmit-PHY for HDMI2.1 TMDS Link, FRL Link, DP
and eDP Link. Therefore, it is better to name it hdptxphy0 other than
hdptxphy_hdmi0, which will be referenced by both hdmi0 and edp0 nodes.
The hdptxphy is a combo transmit-PHY for HDMI2.1 TMDS Link, FRL Link, DP
and eDP Link. Therefore, it is better to name it hdptxphy0 other than
hdptxphy_hdmi0, which will be referenced by both hdmi0 and edp0 nodes.
Signed-off-by: Damon Ding
---
arch/arm64/boot/dts/rockchip/rk3588-base.dtsi
On Wed, 5 Feb 2025 at 16:28, Maxime Ripard wrote:
>
> On Tue, Jan 28, 2025 at 03:12:41PM +0200, Dmitry Baryshkov wrote:
> > On Tue, Jan 28, 2025 at 11:33:05AM +0100, Maxime Ripard wrote:
> > > On Sun, Jan 26, 2025 at 03:29:06PM +0200, Dmitry Baryshkov wrote:
> > > > As a preparation to adding HDMI
The hdptxphy is a combo transmit-PHY for HDMI2.1 TMDS Link, FRL Link, DP
and eDP Link. Therefore, it is better to name it hdptxphy0 other than
hdptxphy_hdmi0, which will be referenced by both hdmi0 and edp0 nodes.
Acked-by: Rob Herring (Arm)
Signed-off-by: Damon Ding
---
.../bindings/display/ro
On Wed, Feb 5, 2025 at 8:17 AM Erik Faye-Lund
wrote:
>
> On Wed, 2025-02-05 at 11:53 +0100, Erik Faye-Lund wrote:
> > On Tue, 2025-02-04 at 17:28 -0600, Rob Herring (Arm) wrote:
> > > Use an enum instead of #defines for panthor IOCTLs. This allows the
> > > header to be used with Rust code as bind
From: Sasha Finkelstein
Adds device tree entries for the touchbar screen
Co-developed-by: Janne Grunau
Signed-off-by: Janne Grunau
Reviewed-by: Nick Chan
Signed-off-by: Sasha Finkelstein
---
arch/arm64/boot/dts/apple/t8103-j293.dts | 31
arch/arm64/boot/dts/apple/t8103.dtsi
From: Sasha Finkelstein
This is the display panel used for the touchbar on laptops that have it.
Co-developed-by: Nick Chan
Signed-off-by: Nick Chan
Signed-off-by: Sasha Finkelstein
---
drivers/gpu/drm/panel/Kconfig| 9 +++
drivers/gpu/drm/panel/Makefile | 1 +
drivers/gpu/
From: Sasha Finkelstein
This display controller is present on M-series chips and is used
to drive the touchbar display.
Co-developed-by: Janne Grunau
Signed-off-by: Janne Grunau
Signed-off-by: Sasha Finkelstein
---
drivers/gpu/drm/Kconfig| 2 +
drivers/gpu/drm/Makefile | 1
From: Sasha Finkelstein
Add bindings for a secondary display controller present on certain
Apple laptops.
Reviewed-by: Krzysztof Kozlowski
Signed-off-by: Sasha Finkelstein
---
.../display/apple,h7-display-pipe-mipi.yaml| 83
.../bindings/display/apple,h7-display-p
Hi.
This patch series adds support for a secondary display controller
present on Apple M1/M2 chips and used to drive the display of the
"touchbar" touch panel present on those.
Signed-off-by: Sasha Finkelstein
---
Changes in v5:
- Moved to using the component framework.
- Other lifetime fixes
-
From: Sasha Finkelstein
Add the MAINTAINERS entries for the driver
Acked-by: Sven Peter
Signed-off-by: Sasha Finkelstein
---
MAINTAINERS | 5 +
1 file changed, 5 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index
a87ddad78e26f28ffd0f3433560d6db1518f9f95..4ce0d3bcf67910d909ba4126
Hi Dave, Simona,
Fixes for 6.14.
The following changes since commit 2014c95afecee3e76ca4a56956a936e23283f05b:
Linux 6.14-rc1 (2025-02-02 15:39:26 -0800)
are available in the Git repository at:
https://gitlab.freedesktop.org/agd5f/linux.git
tags/amd-drm-fixes-6.14-2025-02-05
for you to fe
Hi,
On Mon, Feb 3, 2025 at 9:59 AM Doug Anderson wrote:
>
> Hi,
>
> On Sat, Feb 1, 2025 at 10:55 AM Tejas Vipin wrote:
> >
> > Changes the sharp-ls060t1sx01 panel to use multi style functions for
>
> Not worth spinning for this, but s/Changes/Change/
>
> > improved error handling.
> >
> > Signed
Hi,
On Wed, Feb 5, 2025 at 1:54 AM Damon Ding wrote:
>
> The raw edid for LP079QX1-SP0V panel model is:
>
> 00 ff ff ff ff ff ff 00 16 83 00 00 00 00 00 00
> 04 17 01 00 a5 10 0c 78 06 ef 05 a3 54 4c 99 26
> 0f 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01
> 01 01 01 01 01 01 ea 4e 00 4c 60 00 14
On 2025-02-05 15:36, Mario Limonciello wrote:
> On 2/5/2025 14:33, Felix Kuehling wrote:
>>
>>
>> On 2025-02-05 14:31, Mario Limonciello wrote:
>>> On 2/4/2025 17:19, Felix Kuehling wrote:
On 2025-02-04 17:21, Mario Limonciello wrote:
> From: Mario Limonciello
>
> find_sys
On 2/5/2025 14:43, Felix Kuehling wrote:
On 2025-02-05 15:36, Mario Limonciello wrote:
On 2/5/2025 14:33, Felix Kuehling wrote:
On 2025-02-05 14:31, Mario Limonciello wrote:
On 2/4/2025 17:19, Felix Kuehling wrote:
On 2025-02-04 17:21, Mario Limonciello wrote:
From: Mario Limonciello
On Thu, 6 Feb 2025 at 04:52, Simona Vetter wrote:
>
> On Tue, Feb 04, 2025 at 03:46:14AM +0900, Hector Martin wrote:
> > Adding Linus
> >
> > My 2c: If Linus doesn't pipe up with an authoritative answer to this
> > thread, Miguel and the other Rust folks should just merge this series
> > once it i
On 2/5/2025 14:33, Felix Kuehling wrote:
On 2025-02-05 14:31, Mario Limonciello wrote:
On 2/4/2025 17:19, Felix Kuehling wrote:
On 2025-02-04 17:21, Mario Limonciello wrote:
From: Mario Limonciello
find_system_memory() pulls out two fields from an SMBIOS type 17
device and sets them on KF
On 2025-02-05 14:31, Mario Limonciello wrote:
> On 2/4/2025 17:19, Felix Kuehling wrote:
>>
>> On 2025-02-04 17:21, Mario Limonciello wrote:
>>> From: Mario Limonciello
>>>
>>> find_system_memory() pulls out two fields from an SMBIOS type 17
>>> device and sets them on KFD devices. This however
Replace platform_get_resource + devm_ioremap_resource
with just devm_platform_ioremap_resource()
Used Coccinelle to do this change. SmPl patch:
@rule_1@
identifier res;
expression ioremap_res;
identifier pdev;
@@
-struct resource *res;
...
-res = platform_get_resource(pdev,...);
-ioremap_res = dev
Hey,
Thanks for your feedback. I think in this case you are right, and it
will become unreadable.
I'll try to make sparse annotations work, and then see if we can enable
it in CI for all.
Cheers,
~Maarten
On 2025-02-04 18:40, David Lechner wrote:
On 2/4/25 7:22 AM, Maarten Lankhorst wrote
Update the Documentation to be more precise.
v2: Update for clarity
Cc: Thomas Zimmermann
Signed-off-by: Anusha Srivatsa
---
Documentation/gpu/todo.rst | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index
Replace platform_get_resource + devm_ioremap_resource
with just devm_platform_ioremap_resource()
Used Coccinelle to do this change. SmPl patch:
@rule_1@
identifier res;
expression ioremap_res;
identifier pdev;
@@
-struct resource *res;
...
-res = platform_get_resource(pdev,...);
-ioremap_res = dev
Replace platform_get_resource_byname + devm_ioremap_resource
with just devm_platform_ioremap_resource()
Used Coccinelle to do this change. SmPl patch:
//rule s/(devm_)platform_get_resource_byname +
//(devm_)ioremap/devm_platform_ioremap_resource.
@rule_3@
identifier res;
expression ioremap;
identi
Replace platform_get_resource + devm_ioremap_resource
with just devm_platform_ioremap_resource()
Used Coccinelle to do this change. SmPl patch:
@rule_1@
identifier res;
expression ioremap_res;
identifier pdev;
@@
-struct resource *res;
...
-res = platform_get_resource(pdev,...);
-ioremap_res = dev
Replace platform_get_resource + devm_ioremap
with just devm_platform_ioremap_resource()
Used Coccinelle to do this change. SmPl patch:
@rule_2@
identifier res;
expression ioremap;
identifier pdev;
@@
-struct resource *res;
...
-res = platform_get_resource(pdev,...);
<...
-if (!res) {
-...
-}
...>
Replace platform_get_resource/_byname + devm_ioremap
with just devm_platform_ioremap_resource()
Used Coccinelle to do this change. SmPl patch:
@rule@
identifier res;
expression ioremap;
identifier pdev;
constant mem;
expression name;
@@
-struct resource *res;
...
-res = platform_get_resource_byna
Replace platform_get_resource + devm_ioremap_resource
with just devm_platform_ioremap_resource()
Used Coccinelle to do this change. SmPl patch:
@rule_1@
identifier res;
expression ioremap_res;
identifier pdev;
@@
-struct resource *res;
...
-res = platform_get_resource(pdev,...);
-ioremap_res = dev
Replace platform_get_resource + devm_ioremap_resource
with just devm_platform_ioremap_resource()
Used Coccinelle to do this change. SmPl patch:
@rule_1@
identifier res;
expression ioremap_res;
identifier pdev;
@@
-struct resource *res;
...
-res = platform_get_resource(pdev,...);
-ioremap_res = dev
Replace platform_get_resource + devm_ioremap_resource
with just devm_platform_ioremap_resource()
Used Coccinelle to do this change. SmPl patch:
@rule_1@
identifier res;
expression ioremap_res;
identifier pdev;
@@
-struct resource *res;
...
-res = platform_get_resource(pdev,...);
-ioremap_res = dev
Replace platform_get_resource + devm_ioremap_resource
with just devm_platform_ioremap_resource()
Used Coccinelle to do this change. SmPl patch:
@rule_1@
identifier res;
expression ioremap_res;
identifier pdev;
@@
-struct resource *res;
...
-res = platform_get_resource(pdev,...);
-ioremap_res = dev
Replace platform_get_resource + devm_ioremap_resource
with just devm_platform_ioremap_resource()
Used Coccinelle to do this change. SmPl patch:
@rule_1@
identifier res;
expression ioremap_res;
identifier pdev;
@@
-struct resource *res;
...
-res = platform_get_resource(pdev,...);
-ioremap_res = dev
| 55 +++--
28 files changed, 46 insertions(+), 177 deletions(-)
---
base-commit: 92514ef226f511f2ca1fb1b8752966097518edc0
change-id: 20250205-mem-cocci-newapi-6db4b8116d6e
Best regards,
--
Anusha Srivatsa
On 05/02/2025 18.10, Danilo Krummrich wrote:
> On Wed, Feb 05, 2025 at 03:56:46PM +0200, Zhi Wang wrote:
>> On Tue, 4 Feb 2025 20:03:12 +0100
>> Danilo Krummrich wrote:
>>
>>> +
>>> +Generic register abstraction
>>> +
>>> +
>>> +Work out how register constants and stru
On 2/4/2025 17:19, Felix Kuehling wrote:
On 2025-02-04 17:21, Mario Limonciello wrote:
From: Mario Limonciello
find_system_memory() pulls out two fields from an SMBIOS type 17
device and sets them on KFD devices. This however is pulling from
the middle of the field in the SMBIOS device and le
On Tue, Feb 04, 2025 at 03:46:14AM +0900, Hector Martin wrote:
> Adding Linus
>
> My 2c: If Linus doesn't pipe up with an authoritative answer to this
> thread, Miguel and the other Rust folks should just merge this series
> once it is reviewed and ready, ignoring Christoph's overt attempt at
> sa
Le mercredi 05 février 2025 à 15:52 +0100, Maxime Ripard a écrit :
> On Mon, Feb 03, 2025 at 04:43:23PM +, Florent Tomasin wrote:
> > Hi Maxime, Nicolas
> >
> > On 30/01/2025 17:47, Nicolas Dufresne wrote:
> > > Le jeudi 30 janvier 2025 à 17:38 +0100, Maxime Ripard a écrit :
> > > > Hi Nicolas
Le mercredi 05 février 2025 à 15:53 +0100, Maxime Ripard a écrit :
> On Tue, Feb 04, 2025 at 01:22:58PM -0500, Nicolas Dufresne wrote:
> > Le lundi 03 février 2025 à 16:43 +, Florent Tomasin a écrit :
> > > Hi Maxime, Nicolas
> > >
> > > On 30/01/2025 17:47, Nicolas Dufresne wrote:
> > > > Le
On Fri, Jan 31, 2025 at 7:53 AM Thomas Zimmermann
wrote:
> Hi Maxime
>
>
> Am 29.01.25 um 15:31 schrieb Maxime Ripard:
> > Hi Thomas,
> >
> > On Wed, Jan 29, 2025 at 02:06:15PM +0100, Thomas Zimmermann wrote:
> >> Am 28.01.25 um 23:29 schrieb Anusha Srivatsa:
> >>> Remove the TODO now that this s
On Wed, Feb 05, 2025 at 04:56:32PM +0200, Zhi Wang wrote:
> On Wed, 5 Feb 2025 15:13:12 +0100
> Miguel Ojeda wrote:
>
> > On Wed, Feb 5, 2025 at 2:57 PM Zhi Wang wrote:
> > >
> > > It would be also helpful to make the process explicit. E.g. sharing your
> > > command lines used to checking the p
> Modify vesa_get_brightness function to take into account
> luminance_control_support and based on that read the appropriate register
> and return the value.
>
> --v2
> -Changes since we now use luminance instead of nits
>
> Signed-off-by: Suraj Kandpal
> Tested-by: Ben Kao
> ---
> .../drm/i9
> Create a function that fills in the value for PANEL_TARGET_LUMINANCE_VALUE
> which helps in changing the luminance in nits using VESA interface.
>
> --v2
> -Prefer using luminance over nits [Jani]
>
> Signed-off-by: Suraj Kandpal
> Tested-by: Ben Kao
> ---
Reviewed-by: Arun R Murthy
Thanks
On Wed, Feb 05, 2025 at 03:56:46PM +0200, Zhi Wang wrote:
> On Tue, 4 Feb 2025 20:03:12 +0100
> Danilo Krummrich wrote:
>
> > +
> > +Generic register abstraction
> > +
> > +
> > +Work out how register constants and structures can be automatically
> > generated
> > +t
On 05.02.2025 09:32, Christian König wrote:
Am 04.02.25 um 23:41 schrieb Tomasz Lis:
This RFC asks for introduction of an interface which allows to shift
a range managed by drm_mm instance without repeating the node list
creation.
What do you mean with "shift" here? As far as I can see from
On 05/02/25 - 09:55, Maxime Ripard wrote:
> On Mon, Jan 27, 2025 at 11:48:23AM +0100, Louis Chauvet wrote:
> > On 26/01/25 - 18:06, Maxime Ripard wrote:
> > > On Tue, Jan 21, 2025 at 11:48:06AM +0100, Louis Chauvet wrote:
> > > > +static struct yuv_u8_to_argb_u16_case yuv_u8_to_argb_u16_cases[] = {
Use aperture helpers to remove all generic graphics drivers before
loading mxsfb. Makes mxsfb compatible with simpledrm.
Co-developed-by: Michael Trimarchi
Signed-off-by: Michael Trimarchi
Signed-off-by: Dario Binacchi
Reviewed-by: Thomas Zimmermann
---
Changes in v3:
- Add 'Reviewed-by' of
On Mon, Feb 03, 2025 at 04:43:23PM +, Florent Tomasin wrote:
> Hi Maxime, Nicolas
>
> On 30/01/2025 17:47, Nicolas Dufresne wrote:
> > Le jeudi 30 janvier 2025 à 17:38 +0100, Maxime Ripard a écrit :
> >> Hi Nicolas,
> >>
> >> On Thu, Jan 30, 2025 at 10:59:56AM -0500, Nicolas Dufresne wrote:
>
On Wed, Feb 05, 2025 at 03:27:05PM +0100, Maxime Ripard wrote:
> On Tue, Jan 28, 2025 at 02:17:19PM +0200, Dmitry Baryshkov wrote:
> > On Tue, Jan 28, 2025 at 11:36:06AM +0100, Maxime Ripard wrote:
> > > On Sun, Jan 26, 2025 at 03:29:07PM +0200, Dmitry Baryshkov wrote:
> > > > Add generic CEC helpe
On Wed, 5 Feb 2025 15:13:12 +0100
Miguel Ojeda wrote:
> On Wed, Feb 5, 2025 at 2:57 PM Zhi Wang wrote:
> >
> > It would be also helpful to make the process explicit. E.g. sharing your
> > command lines used to checking the patches. So folks can align with the
> > expected outcome, e.g. command l
On Tue, Feb 04, 2025 at 01:22:58PM -0500, Nicolas Dufresne wrote:
> Le lundi 03 février 2025 à 16:43 +, Florent Tomasin a écrit :
> > Hi Maxime, Nicolas
> >
> > On 30/01/2025 17:47, Nicolas Dufresne wrote:
> > > Le jeudi 30 janvier 2025 à 17:38 +0100, Maxime Ripard a écrit :
> > > > Hi Nicolas
On Wed, Feb 05, 2025 at 02:42:03PM +0100, Krzysztof Kozlowski wrote:
> On 05/02/2025 12:23, Dmitry Baryshkov wrote:
> +
> +static void dsi_pll_disable_global_clk(struct dsi_pll_7nm *pll)
> +{
> +dsi_pll_cmn_clk_cfg1_update(pll, BIT(5), 0);
> }
>
> Check if we are capable of controlling brightness via luminance which is
> dependent on PANEL_LUMINANCE_OVERRIDE being set.
>
Is PANEL_LUMINANCE_OVERRIDE a macro? I don't see this definition!
> --v2
> -Prefer using luminance rather than nits [Jani] -Fix commit message
>
> Signed-off-by: Suraj
On Wed, Feb 05, 2025 at 02:41:03PM +0800, Hermes Wu via B4 Relay wrote:
> From: Hermes Wu
>
> Add DRM_BRIDGE_OP_HDMI to bridge.ops and implement necessary callback
> functions.
Wait Now I feel really sorry. I stumbled upon HDMI_related bits and
then I thought that it's a HDMI bridge without
On Wed, Jan 29, 2025 at 01:45:56AM +0200, Dmitry Baryshkov wrote:
> On Tue, Jan 28, 2025 at 05:11:16PM +0100, Maxime Ripard wrote:
> > On Sun, Jan 26, 2025 at 03:29:14PM +0200, Dmitry Baryshkov wrote:
> > > diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> > > index
> > > b55e80a5
On Tue, Jan 28, 2025 at 03:12:41PM +0200, Dmitry Baryshkov wrote:
> On Tue, Jan 28, 2025 at 11:33:05AM +0100, Maxime Ripard wrote:
> > On Sun, Jan 26, 2025 at 03:29:06PM +0200, Dmitry Baryshkov wrote:
> > > As a preparation to adding HDMI CEC helper code, add CEC-related fields
> > > to the struct
On Tue, Jan 28, 2025 at 02:17:19PM +0200, Dmitry Baryshkov wrote:
> On Tue, Jan 28, 2025 at 11:36:06AM +0100, Maxime Ripard wrote:
> > On Sun, Jan 26, 2025 at 03:29:07PM +0200, Dmitry Baryshkov wrote:
> > > Add generic CEC helpers to be used by HDMI drivers. Both notifier and
> > > and adapter are
On Wed, 5 Feb 2025 at 13:48, Vignesh Raman wrote:
> Update drm/ci maintainer entries:
>
> * Add myself as drm/ci maintainer.
> * Update Helen's email address.
Acked-by: Daniel Stone
On Wed, 05 Feb 2025 05:16:45 -0300 Vignesh Raman wrote ---
> Uprev mesa to adapt to the latest changes in mesa-ci,
> including new container jobs and stages. Update the
> lava-submit script to align with recent mes-ci changes
> for using LAVA rootfs overlays. Modify gitLab rules
Am 30.01.25 um 11:13 schrieb Thomas Hellström:
Provide a helper to shrink ttm_tt page-vectors on a per-page
basis. A ttm_backup backend could then in theory get away with
allocating a single temporary page for each struct ttm_tt.
This is accomplished by splitting larger pages before trying to
ba
1 - 100 of 143 matches
Mail list logo
