On Fri, Feb 07, 2025 at 05:59:04PM +0100, Louis Chauvet wrote:
> On 06/02/25 - 18:38, Greg Kroah-Hartman wrote:
> > The vkms driver does not need to create a platform device, as there is
> > no real platform resources associated it, it only did so because it was
> > simple to do that in order to g
On Tue, Feb 04, 2025 at 03:57:33PM +0100, Maxime Ripard wrote:
> It's pretty inconvenient to access the full atomic state from
> drm_bridges, so let's change the atomic_post_disable hook prototype to
> pass it directly.
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/bridge/analogix/ana
Change the visionox-r66451 panel to use multi style functions for
improved error handling.
Signed-off-by: Tejas Vipin
---
drivers/gpu/drm/panel/panel-visionox-r66451.c | 179 --
1 file changed, 76 insertions(+), 103 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-visionox
Hi Louis,
On Fri, 07 Feb 2025 18:35:22 +0100 Louis Chauvet
wrote:
>
> During the creation of drmm_ variants for writeback connector, one
> function was renamed, but not the kernel doc.
>
> To remove the warning, use the proper name in kernel doc.
>
> Fixes: 135d8fc7af44 ("drm: writeback: Creat
On Fri, Feb 07, 2025 at 11:26:50PM -0500, Steven Rostedt wrote:
>
> Note, even though PREEMPT_RT started in 2004 and wasn't fully merged until
> 2024, it slowly did creep in bit by bit. For example, here's a few things that
> came from the RT patch, and each was rewritten at least 3 times to becom
On Fri, Feb 07, 2025 at 06:16:38AM -0600, Dr. Greg wrote:
>
> Not sure what the fix is, from a project management perspective the
> technology industry has never faced a challenge like this. The fork
> model, which was the classic protection in open-source, doesn't work
> at this scale.
Maybe no
On 2/7/2025 4:27 PM, Dmitry Baryshkov wrote:
Setup the HDMI connector on the MSM HDMI outputs. Make use of
atomic_check hook and of the provided Infoframe infrastructure.
Acked-by: Maxime Ripard
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/Kconfig| 2 +
drivers/g
On Fri, Feb 07, 2025 at 04:42:46PM -0800, Abhinav Kumar wrote:
>
>
> On 2/7/2025 4:27 PM, Dmitry Baryshkov wrote:
> > The mode_set callback is deprecated, it doesn't get the
> > drm_bridge_state, just mode-related argumetns. Also Abhinav pointed out
> > that HDMI timings should be programmed afte
On Fri, Feb 07, 2025 at 07:05:14PM -0800, Abhinav Kumar wrote:
>
>
> On 2/7/2025 6:04 PM, Dmitry Baryshkov wrote:
> > On Fri, Feb 07, 2025 at 05:31:20PM -0800, Abhinav Kumar wrote:
> > >
> > >
> > > On 2/7/2025 4:27 PM, Dmitry Baryshkov wrote:
> > > > Extend the driver to send SPD and HDMI Vend
On Fri, Feb 07, 2025 at 10:23:25PM +0530, Pranav Tyagi wrote:
> Corrects the following grammatical issues in the VGA Arbiter documentation:
> - Fixes subject-verb agreement by changing "co-exists" to "co-exist"
> - Corrects pluralization by changing "server" to "servers"
> - Improves sentence struc
On 2/7/2025 6:04 PM, Dmitry Baryshkov wrote:
On Fri, Feb 07, 2025 at 05:31:20PM -0800, Abhinav Kumar wrote:
On 2/7/2025 4:27 PM, Dmitry Baryshkov wrote:
Extend the driver to send SPD and HDMI Vendor Specific InfoFrames.
While the HDMI block has special block to send HVS InfoFrame, use
GEN
On Fri, Feb 07, 2025 at 09:30:45PM -0500, Demi Marie Obenour wrote:
> On Fri, Feb 07, 2025 at 07:07:11PM +0800, Huang, Honglei1 wrote:
> > On 2025/2/7 2:21, Demi Marie Obenour wrote:
> > > On Thu, Feb 06, 2025 at 06:53:55PM +0800, Huang, Honglei1 wrote:
> > > > On 2025/1/31 8:33, Demi Marie Obenour
On Fri, Feb 07, 2025 at 07:07:11PM +0800, Huang, Honglei1 wrote:
> On 2025/2/7 2:21, Demi Marie Obenour wrote:
> > On Thu, Feb 06, 2025 at 06:53:55PM +0800, Huang, Honglei1 wrote:
> > > On 2025/1/31 8:33, Demi Marie Obenour wrote:
> > > > On Wed, Jan 29, 2025 at 03:54:59PM -0500, Demi Marie Obenour
On Fri, Feb 07, 2025 at 05:31:20PM -0800, Abhinav Kumar wrote:
>
>
> On 2/7/2025 4:27 PM, Dmitry Baryshkov wrote:
> > Extend the driver to send SPD and HDMI Vendor Specific InfoFrames.
> >
> > While the HDMI block has special block to send HVS InfoFrame, use
> > GENERIC0 block instead. VENSPEC_I
Hi,
On Tue, Feb 4, 2025 at 7:01 AM Maxime Ripard wrote:
>
> The TI sn65dsi86 driver follows the drm_encoder->crtc pointer that is
> deprecated and shouldn't be used by atomic drivers.
>
> This was due to the fact that we did't have any other alternative to
> retrieve the CRTC pointer. Fortunately
On 2/7/2025 4:27 PM, Dmitry Baryshkov wrote:
Extend the driver to send SPD and HDMI Vendor Specific InfoFrames.
While the HDMI block has special block to send HVS InfoFrame, use
GENERIC0 block instead. VENSPEC_INFO registers pack frame data in a way
that requires manual repacking in the drive
Hi,
On Tue, Feb 4, 2025 at 6:59 AM Maxime Ripard wrote:
>
> drm_atomic_bridge_chain_post_disable() disables all bridges affected by
> a new commit. It takes the drm_atomic_state being committed as a
> parameter.
>
> However, that parameter name is called (and documented) as old_state,
> which is
Hi,
On Tue, Feb 4, 2025 at 6:59 AM Maxime Ripard wrote:
>
> drm_atomic_bridge_chain_pre_enable() enables all bridges affected by
> a new commit. It takes the drm_atomic_state being committed as a
> parameter.
>
> However, that parameter name is called (and documented) as old_state,
> which is pre
On 2/7/2025 4:27 PM, Dmitry Baryshkov wrote:
The mode_set callback is deprecated, it doesn't get the
drm_bridge_state, just mode-related argumetns. Also Abhinav pointed out
that HDMI timings should be programmed after setting up HDMI PHY and
PLL. Rework the code to program HDMI timings at the
Use connector->display_info.is_hdmi instead of manually using
drm_detect_hdmi_monitor().
Acked-by: Maxime Ripard
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi/hdmi.c| 2 +-
drivers/gpu/drm/msm/hdmi/hdmi.h| 2 --
drivers/gpu/drm/msm/hd
Change MSM HDMI bridge to use atomic_* callbacks in preparation to
enablign the HDMI connector support.
Acked-by: Maxime Ripard
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 13 +
1 file changed, 9 insertions(+), 4 deletions
Setup the HDMI connector on the MSM HDMI outputs. Make use of
atomic_check hook and of the provided Infoframe infrastructure.
Acked-by: Maxime Ripard
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/Kconfig| 2 +
drivers/gpu/drm/msm/hdmi/hdmi.c| 45 ++---
drive
The GENERIC0_UPDATE field is a single bit. Redefine it as boolean to
simplify its usage in the driver.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/registers/display/hdmi.xml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/dr
In order to simplify the driver even further and to remove the
boilerplate code, rewrite the audio interface to use the DRM HDMI Audio
framework.
Audio InfoFames are controlled centrally via the DRM HDMI framework.
Correct InfoFrame data is programmed at the atomic_pre_enable() time (if
it was set
This patchset sits on top Maxime's HDMI connector patchset ([1]).
Currently this is an RFC exploring the interface between HDMI bridges
and HDMI connector code. This has been lightly verified on the Qualcomm
DB820c, which has native HDMI output. If this approach is considered to
be acceptable, I'l
Extend the driver to send SPD and HDMI Vendor Specific InfoFrames.
While the HDMI block has special block to send HVS InfoFrame, use
GENERIC0 block instead. VENSPEC_INFO registers pack frame data in a way
that requires manual repacking in the driver, while GENERIC0 doesn't
have such format require
The mode_set callback is deprecated, it doesn't get the
drm_bridge_state, just mode-related argumetns. Also Abhinav pointed out
that HDMI timings should be programmed after setting up HDMI PHY and
PLL. Rework the code to program HDMI timings at the end of
atomic_pre_enable().
Reviewed-by: Maxime R
On Fri, Feb 07, 2025 at 02:27:41PM -0800, Abhinav Kumar wrote:
>
>
> On 2/7/2025 2:03 PM, Dmitry Baryshkov wrote:
> > On Fri, Feb 07, 2025 at 01:34:35PM -0800, Abhinav Kumar wrote:
> > >
> > >
> > > On 2/3/2025 5:30 PM, Dmitry Baryshkov wrote:
> > > > On Mon, Feb 03, 2025 at 04:25:59PM -0800, A
From: Luan Arcanjo
All dce command_table_helper's shares a copy-pasted collection
of copy-pasted functions, which are: phy_id_to_atom,
clock_source_id_to_atom_phy_clk_src_id, and engine_bp_to_atom.
This patch removes the multiple copy-pasted by creating a
common command table and make the comman
From: Luan Arcanjo
All dce command_table_helper's shares a copy-pasted collection
of copy-pasted functions, which are: phy_id_to_atom,
clock_source_id_to_atom_phy_clk_src_id, and engine_bp_to_atom.
This patch removes the multiple copy-pasted by creating a
common command table and make the comman
On 2/7/2025 2:03 PM, Dmitry Baryshkov wrote:
On Fri, Feb 07, 2025 at 01:34:35PM -0800, Abhinav Kumar wrote:
On 2/3/2025 5:30 PM, Dmitry Baryshkov wrote:
On Mon, Feb 03, 2025 at 04:25:59PM -0800, Abhinav Kumar wrote:
On 1/24/2025 1:47 PM, Dmitry Baryshkov wrote:
Setup the HDMI connector
The pull request you sent on Sat, 8 Feb 2025 05:34:09 +1000:
> https://gitlab.freedesktop.org/drm/kernel.git tags/drm-fixes-2025-02-08
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/7ee983c850b40043ac4751836fbd9a2b4d0c5937
Thank you!
--
Deet-doot-dot, I am a bot.
ht
On Fri, Feb 07, 2025 at 12:11:55PM -0800, Abhinav Kumar wrote:
>
>
> On 2/6/2025 5:19 PM, Dmitry Baryshkov wrote:
> > On Thu, Feb 06, 2025 at 12:41:30PM -0800, Abhinav Kumar wrote:
> > >
> > >
> > > On 2/3/2025 4:59 PM, Dmitry Baryshkov wrote:
> > > > On Mon, Feb 03, 2025 at 11:34:00AM -0800, A
On Fri, Feb 07, 2025 at 01:34:35PM -0800, Abhinav Kumar wrote:
>
>
> On 2/3/2025 5:30 PM, Dmitry Baryshkov wrote:
> > On Mon, Feb 03, 2025 at 04:25:59PM -0800, Abhinav Kumar wrote:
> > >
> > >
> > > On 1/24/2025 1:47 PM, Dmitry Baryshkov wrote:
> > > > Setup the HDMI connector on the MSM HDMI o
On 2/3/2025 5:30 PM, Dmitry Baryshkov wrote:
On Mon, Feb 03, 2025 at 04:25:59PM -0800, Abhinav Kumar wrote:
On 1/24/2025 1:47 PM, Dmitry Baryshkov wrote:
Setup the HDMI connector on the MSM HDMI outputs. Make use of
atomic_check hook and of the provided Infoframe infrastructure.
By atom
On 2/6/2025 5:19 PM, Dmitry Baryshkov wrote:
On Thu, Feb 06, 2025 at 12:41:30PM -0800, Abhinav Kumar wrote:
On 2/3/2025 4:59 PM, Dmitry Baryshkov wrote:
On Mon, Feb 03, 2025 at 11:34:00AM -0800, Abhinav Kumar wrote:
On 1/24/2025 1:47 PM, Dmitry Baryshkov wrote:
The mode_set callback is
On Fri, Feb 07, 2025 at 11:44:01AM +0100, Luca Ceresoli wrote:
> On Fri, 7 Feb 2025 05:17:43 +0200
> Dmitry Baryshkov wrote:
>
> > On Thu, Feb 06, 2025 at 07:14:30PM +0100, Luca Ceresoli wrote:
> > > Add a devm/drmm action to these functions so the bridge reference is
> > > dropped automatically
On Fri, Feb 07, 2025 at 12:47:51PM +0100, Maxime Ripard wrote:
> Hi,
>
> On Thu, Feb 06, 2025 at 07:14:29PM +0100, Luca Ceresoli wrote:
> > DRM bridges are currently considered as a fixed element of a DRM card, and
> > thus their lifetime is assumed to extend for as long as the card
> > exists. Ne
On Fri, Feb 07, 2025 at 09:54:21AM +0100, Luca Ceresoli wrote:
> On Fri, 7 Feb 2025 04:52:20 +0200
> Dmitry Baryshkov wrote:
>
> > On Thu, Feb 06, 2025 at 07:14:24PM +0100, Luca Ceresoli wrote:
> > > devm_drm_of_get_bridge() and drmm_of_get_bridge() do not have anything to
> > > do with struct dr
On Fri, Feb 07, 2025 at 09:54:28AM +0100, Luca Ceresoli wrote:
> On Fri, 7 Feb 2025 04:49:21 +0200
> Dmitry Baryshkov wrote:
>
> > On Thu, Feb 06, 2025 at 07:14:23PM +0100, Luca Ceresoli wrote:
> > > Adding a panel does currently not add a panel_bridge wrapping it. Usually
> > > the panel_bridge
Hi Damon,
Am Donnerstag, dem 23.01.2025 um 18:07 +0800 schrieb Damon Ding:
> Move drm_of_find_panel_or_bridge() a little later and combine it with
> component_add() into a new function rockchip_dp_link_panel(). The function
> will serve as done_probing() callback of devm_of_dp_aux_populate_bus(),
Hi Linus,
Just regular drm fixes, amdgpu, xe and i915 mostly, but a few
scattered fixes. I think one of the i915 fixes fixes some build combos
that Guenter was seeing.
Thanks,
Dave.
drm-fixes-2025-02-08:
drm fixes for 6.14-rc2
amdgpu:
- Add new tiling flag for DCC write compress disable
- Add B
On 2025/02/08 3:33, Linus Torvalds wrote:
> On Fri, 7 Feb 2025 at 10:02, Hector Martin wrote:
>>
>> Meanwhile, for better or worse, much of Linux infra *is* centralized -
>> for example, the mailing lists themselves, and a lot of the Git hosting.
>
> The mailing lists are mostly on kernel.org,
- Added the new device ID
- Added new pll algorithm
Signed-off-by: Gwenael Georgeault
Co-authored-by: Mamadou Insa Diop
---
drivers/gpu/drm/mgag200/Makefile | 1 +
drivers/gpu/drm/mgag200/mgag200_drv.c | 4 +
drivers/gpu/drm/mgag200/mgag200_drv.h | 3 +
drivers/gpu/drm/m
* Hector Martin (mar...@marcan.st) wrote:
> On 2025/02/08 2:14, Konstantin Ryabitsev wrote:
> > On Fri, Feb 07, 2025 at 05:16:28AM +0900, Hector Martin wrote:
> >> And what I see, is very little effort to improve that status quo, or at
> >> least very little that yields any actual change that isn't
From: Saurabh Singh Sengar Sent: Friday, February 7,
2025 6:06 AM
>
> Thanks Michael, for the analysis.
>
> I have tried the kdump steps on Oracle 9.4, 6.13.0 kernel as well. Although I
> couldn't see
> the soft lockup issue I see some other VMBus failures. But I agree the bootup
> is
> extre
On Fri, 7 Feb 2025 at 10:02, Hector Martin wrote:
>
> Meanwhile, for better or worse, much of Linux infra *is* centralized -
> for example, the mailing lists themselves, and a lot of the Git hosting.
The mailing lists are mostly on kernel.org, but the git hosting most
certainly is not centralized
From: Michael Kelley Sent: Thursday, February 6, 2025
1:00 PM
>
> From: Michael Kelley
> >
> > From: Thomas Tai Sent: Thursday, January 30, 2025
> > 12:44 PM
> > >
> > > > -Original Message-
> > > > From: Michael Kelley Sent: Thursday, January 30,
> > > > 2025 3:20 PM
> > > >
> > >
Instead of calling from the Analogix DP encoder into the VOP crtc
handling, move the wait for PSR entry to vop_crtc_atomic_disable().
This untangles the Analogix DP code from the VOP, so it can safely
be used with VOP2.
Signed-off-by: Lucas Stach
---
Note: I don't have any Rockchip system with a
Instead of checking the same thing twice in a row, fold the second
condition into the first clause.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/d
On Sat, Feb 08, 2025 at 03:02:11AM +0900, Hector Martin wrote:
> The centralization concern is valid, but there are technical solutions
> to this, such as forge federation.
Unfortunately, forge federation is really only between Forgejo instances and
is still pretty nascent, afaict. The most promi
Hi Alexander,
On Thu, 06 Feb 2025 16:39:09 +0100
Alexander Stein wrote:
> Hi Herve,
>
> Am Donnerstag, 6. Februar 2025, 16:20:48 CET schrieb Herve Codina:
> > Hi Alexander,
> >
> > On Thu, 06 Feb 2025 15:38:42 +0100
> > Alexander Stein wrote:
> >
> > ...
> > > With interrupt configured I g
On 2025/02/08 2:14, Konstantin Ryabitsev wrote:
> On Fri, Feb 07, 2025 at 05:16:28AM +0900, Hector Martin wrote:
>> And what I see, is very little effort to improve that status quo, or at
>> least very little that yields any actual change that isn't just
>> band-aids (e.g. tooling like b4, which is
Hi,
On Thu, Feb 6, 2025 at 11:21 AM Doug Anderson wrote:
>
> Hi,
>
> On Thu, Feb 6, 2025 at 10:13 AM Conor Dooley wrote:
> >
> > On Thu, Feb 06, 2025 at 09:12:45AM -0800, Doug Anderson wrote:
> > > Hi,
> > >
> > > On Thu, Feb 6, 2025 at 5:13 AM Langyan Ye
> > > wrote:
> > > >
> > > > Add "csot"
Hi,
On Thu, Feb 6, 2025 at 5:13 AM Langyan Ye
wrote:
>
> The csot-pna957qt1-1 is a 10.95" TFT panel. The MIPI controller on this
> panel is the same as the other panels here, so add this panel to this
> driver.
>
> Signed-off-by: Langyan Ye
> ---
> drivers/gpu/drm/panel/panel-himax-hx83102.c |
Hi,
On Thu, Feb 6, 2025 at 10:14 AM Conor Dooley wrote:
>
> On Thu, Feb 06, 2025 at 09:12:59PM +0800, Langyan Ye wrote:
> > Add a new compatible for the panel CSOT PNA957QT1-1. This panel uses
> > HX83102 IC, so add the compatible to the hx83102 binding files.
> >
> > Signed-off-by: Langyan Ye
>
On Tue, 4 Feb 2025 17:28:24 -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 bindgen can't handle complex
> defines.
>
> Cc: Beata Michalska
> Signed-off-by: Rob Herring (Arm)
Queued to drm-misc-next.
On Fri, 7 Feb 2025 at 12:50, Neil Armstrong wrote:
>
> The mdp1-mem is not supported on the SM8650 SoCs, so only support a single
> mdp0-mem interconnect entry.
No, please add cpu-cfg interconnect instead.
>
> Signed-off-by: Neil Armstrong
> ---
> Documentation/devicetree/bindings/display/msm/
connector with
+ * __drm_writeback_connector_init - Initialize a writeback connector with
* a custom encoder
*
* @dev: DRM device
---
base-commit: 2eca617f12586abff62038db1c14cb3aa60a15aa
change-id: 20250207-b4-fix-warning-431e0a7067ae
Best regards,
--
Louis Chauvet
On Fri, Feb 07, 2025 at 05:16:28AM +0900, Hector Martin wrote:
> And what I see, is very little effort to improve that status quo, or at
> least very little that yields any actual change that isn't just
> band-aids (e.g. tooling like b4, which is nice and appreciated, but
> doesn't fix any underlyi
On 2/7/25 11:44, Laurent Pinchart wrote:
> Hi Sean,
>
> Thank you for the patch.
>
> On Fri, Feb 07, 2025 at 11:25:28AM -0500, Sean Anderson wrote:
>> Convert most mutex_(un)lock calls to use (scoped_)guard instead. This
>> generally reduces line count and prevents bugs like forgetting to unlock
On 28/01/2025 17:52, Jocelyn Falempe wrote:
The current encoding, is done by converting 13bits of input into 4
decimal digits, that are then encoded efficiently using the numeric
encoding of the QR code specification.
The Fido v2.2 specification [1] uses a similar approach for its
QR-initiated au
On Fri, 7 Feb 2025 at 05:25, Yongbang Shi wrote:
>
> > On 5 February 2025 10:18:00 EET, Yongbang Shi
> > wrote:
> >>> On Mon, Jan 27, 2025 at 11:20:23AM +0800, Yongbang Shi wrote:
> From: Baihan Li
>
> Create 3 files in drm debugfs:
> >>> This definitely needs to be split.
> >> H
On Fri, 7 Feb 2025 at 16:02, Neil Armstrong wrote:
>
> The mdp1-mem is not supported on the SM8550 SoCs, so only support a single
> mdp0-mem interconnect entry.
v2 went too fast. Please add cpu-cfg instead.
>
> Signed-off-by: Neil Armstrong
> ---
> .../devicetree/bindings/display/msm/qcom,sm85
On 06/02/25 - 18:38, Greg Kroah-Hartman wrote:
> The vkms driver does not need to create a platform device, as there is
> no real platform resources associated it, it only did so because it was
> simple to do that in order to get a device to use for resource
> management of drm resources. Change
On Mon, 20 Jan 2025 10:21:49 +0300
Dan Carpenter wrote:
> On Sun, Jan 19, 2025 at 10:58:29AM +0800, Su Hui wrote:
> > 'priorities_info' is uninitialized, and the uninitialized value is copied
> > to user object when calling PANTHOR_UOBJ_SET(). Using memset to initialize
> > 'priorities_info' to a
Hi Sean,
Thank you for the patch.
On Fri, Feb 07, 2025 at 11:25:28AM -0500, Sean Anderson wrote:
> Convert most mutex_(un)lock calls to use (scoped_)guard instead. This
> generally reduces line count and prevents bugs like forgetting to unlock
> the mutex. I've left traditional calls in a few pla
On Fri, 07 Feb 2025 11:32:18 -0500
Nicolas Dufresne wrote:
> Le vendredi 07 février 2025 à 16:02 +0100, Boris Brezillon a écrit :
> > Sorry for joining the party late, a couple of comments to back Akash
> > and Nicolas' concerns.
> >
> > On Wed, 05 Feb 2025 13:14:14 -0500
> > Nicolas Dufresne w
On Thu, 30 Jan 2025 17:28:08 +
Adrián Larumbe wrote:
> This patch series enables display of the size of driver-owned shmem BO's that
> aren't
> exposed to userspace through a DRM handle. Also fixes a use-after-free bug in
> the
> existing fdinfo implementation for Panthor.
>
> Discussion o
Hi Sean, Bart,
Thank you for the patch.
On Fri, Feb 07, 2025 at 11:25:27AM -0500, Sean Anderson wrote:
> From: Bart Van Assche
>
> Instead of attempting the same mutex twice, lock and unlock it.
>
> This bug has been detected by the Clang thread-safety analyzer.
>
> Cc: Sean Anderson
> Cc: T
Le vendredi 07 février 2025 à 16:02 +0100, Boris Brezillon a écrit :
> Sorry for joining the party late, a couple of comments to back Akash
> and Nicolas' concerns.
>
> On Wed, 05 Feb 2025 13:14:14 -0500
> Nicolas Dufresne wrote:
>
> > Le mercredi 05 février 2025 à 15:52 +0100, Maxime Ripard a é
Fix a mutex bug and convert most of the explicit mutex_(un)locks to
guards.
Changes in v2:
- Convert some conditional return statements to returns of ternary
expressions.
- Remove unnecessary whitespace change
Bart Van Assche (1):
drm: zynqmp_dp: Fix a deadlock in zynqmp_dp_ignore_hpd_set()
Convert most mutex_(un)lock calls to use (scoped_)guard instead. This
generally reduces line count and prevents bugs like forgetting to unlock
the mutex. I've left traditional calls in a few places where scoped
helpers would be more verbose. This mostly happens where
debugfs_file_put needs to be ca
From: Bart Van Assche
Instead of attempting the same mutex twice, lock and unlock it.
This bug has been detected by the Clang thread-safety analyzer.
Cc: Sean Anderson
Cc: Tomi Valkeinen
Fixes: 28edaacb821c ("drm: zynqmp_dp: Add debugfs interface for compliance
testing")
Signed-off-by: Bart
+
drivers/gpu/drm/panel/Makefile | 1 +
drivers/gpu/drm/panel/panel-raydium-rm67200.c | 503 +
4 files changed, 586 insertions(+)
---
base-commit: 2014c95afecee3e76ca4a56956a936e23283f05b
change-id: 20250207-raydium-rm67200-eb92932c28ec
Best regards
The Rockchip W552793DBA-V10 display/touchscreen board contains a
Wanchanglong W552793BAA panel, which in turn is using a Raydium
RM67200 MIPI-DSI controller. Add a DSI panel driver for it.
The W552793BAA panel init sequence has been taken from the RK3588
EVB1 vendor kernel devicetree.
Reviewed-by
The Rockchip W552793DBA-V10 display/touchscreen board contains a
Wanchanglong W552793BAA panel, which in turn is using a Raydium
RM67200 MIPI-DSI controller. Add a DT binding for the DSI panel.
Reviewed-by: Krzysztof Kozlowski
Signed-off-by: Sebastian Reichel
---
.../bindings/display/panel/rayd
On 2/6/25 18:17, Sasha Finkelstein wrote:
> On Wed, 29 Jan 2025 at 15:40, Dmitry Osipenko
> wrote:
>> Otherwise, the proper solution would be to pass info about host's page
>> size to guest using extended virtio protocol.
>
> It is not fully clear to me, as to what exactly is meant by that.
> IIU
Add a compatible for the MediaTek MT8370 SoC, with an
integrated ARM Mali G57 MC2 GPU (Valhall-JM, dual core),
with the same platform data as MT8186 (one regulator, two power
domains).
Despite their different GPU architecture (making them not being
compatible), the MT8186 platform data can still be
Add a new gpu node in mt8370.dtsi to enable support for the
ARM Mali G57 MC2 GPU (Valhall-JM) found on the MT8370 SoC, using the
Panfrost driver.
On a Mediatek Genio 510 EVK board, the panfrost driver probed with the
following message:
```
panfrost 1300.gpu: clock rate = 39000
panfrost 130
Add a compatible for the MediaTek MT8370 SoC, with an
integrated ARM Mali G57 MC2 GPU (Valhall-JM, dual core).
This new compatible is needed for this SoC support, as the other
existing compatibles for the same GPU architecture (MT8188, MT8192) do
not match the required power domain number.
The othe
This patchset adds the support of the ARM Mali G57 MC2 GPU (Valhall-JM,
dual core), integrated in the Mediatek MT8370 SoC, to the panfrost driver
and to the mt8370.dtsi include file.
I've tested this patchset on a Mediatek Genio 510 EVK board,
with a kernel based on linux-next (tag: next-202
Sorry for joining the party late, a couple of comments to back Akash
and Nicolas' concerns.
On Wed, 05 Feb 2025 13:14:14 -0500
Nicolas Dufresne wrote:
> 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:
> > >
On Wed, 2025-01-29 at 11:52 -0800, Matthew Brost wrote:
> Add documentation for agree upon GPU SVM design principles, current
> status, and future plans.
>
> v4:
> - Address Thomas's feedback
>
> Signed-off-by: Matthew Brost
> ---
> Documentation/gpu/rfc/gpusvm.rst | 84
> +
I saw that Noralf has to unfortunately step down from maintaining the
repaper and mi0283qt drivers. I would be more than happy to maintain
these two if need be. The repaper device is very similar to the
sharp-memory display I currently maintain and I've worked with mi0283qt
displays before.
best r
On 2025/02/07 22:49, Simona Vetter wrote:
> On Fri, Feb 07, 2025 at 07:20:03PM +0900, Hector Martin wrote:
>> On 2025/02/07 18:41, Hector Martin wrote:
>>> On 2025/02/06 3:52, Simona Vetter wrote:
On Tue, Feb 04, 2025 at 03:46:14AM +0900, Hector Martin wrote:
> Adding Linus
>
>
We can re-order some struct members and take u32 credits outside of the
pointer sandwich and also for the last_dependency member we can get away
with an unsigned int since for dependency we use xa_limit_32b.
Pahole report before:
/* size: 160, cachelines: 3, members: 14 */
/* sum m
Idea is to add helpers for peeking and popping jobs from entities with
the goal of decoupling the hidden assumption in the code that queue_node
is the first element in struct drm_sched_job.
That assumption usually comes in the form of:
while ((job = to_drm_sched_job(spsc_queue_pop(&entity->job_
On Wed, 2025-01-29 at 11:52 -0800, Matthew Brost wrote:
> Useful to experiment with notifier size and how it affects
> performance.
>
> v3:
> - Pull missing changes including in following patch (Thomas)
>
> Signed-off-by: Matthew Brost
Reviewed-by: Thomas Hellström
> ---
> drivers/gpu/drm/x
Helper is for scheduler internal use so lets hide it from DRM drivers
completely.
At the same time we change the method of checking whethere there is
anything in the queue from peeking to looking at the node count.
Signed-off-by: Tvrtko Ursulin
Cc: Christian König
Cc: Danilo Krummrich
Cc: Matt
Replace a copy of DRM scheduler's to_drm_sched_job with a copy of a newly
added __drm_sched_entity_queue_pop.
This allows breaking the hidden dependency that queue_node has to be the
first element in struct drm_sched_job.
A comment is also added with a reference to the mailing list discussion
exp
Do a bit of house keeping in gpu_scheduler.h by grouping the API by type
of object it operates on.
Signed-off-by: Tvrtko Ursulin
Cc: Christian König
Cc: Danilo Krummrich
Cc: Matthew Brost
Cc: Philipp Stanner
---
include/drm/gpu_scheduler.h | 60 -
1 file c
Now that we have a header file for internal scheduler interfaces we can
move some more prototypes into it. By doing that we eliminate the chance
of drivers trying to use something which was not intended to be used.
Signed-off-by: Tvrtko Ursulin
Cc: Christian König
Cc: Danilo Krummrich
Cc: Matth
Lets add some helpers for peeking and popping from the job queue which allows us
to re-order the fields in struct drm_sched_job and remove one hole.
As in the process we have added a header file for scheduler internal prototypes,
lets also use it more and cleanup the "exported" header a bit.
v2:
On Wed, 2025-01-29 at 11:52 -0800, Matthew Brost wrote:
> Used to show we can bounce memory multiple times which will happen
> once
> a real migration policy is implemented. Can be removed once migration
> policy is implemented.
>
> v3:
> - Pull some changes into the previous patch (Thomas)
> -
On Wed, 2025-01-29 at 11:52 -0800, Matthew Brost wrote:
> Add some useful SVM debug logging fro SVM range which prints the
> range's
> state.
>
> v2:
> - Upadte logging with latest structure layout
NIT: Update
> v3:
> - Better commit message (Thomas)
> - New range structure (Thomas)
> - s/CO
On Wed, 2025-01-29 at 11:52 -0800, Matthew Brost wrote:
> Wire xe_bo_move to GPU SVM migration via new helper xe_svm_bo_evict.
>
> v2:
> - Use xe_svm_bo_evict
> - Drop bo->range
> v3:
> - Kernel doc (Thomas)
> v4:
> - Add missing xe_bo.c code
>
> Signed-off-by: Matthew Brost
I think in the
On 13/01/2025 15:52, AngeloGioacchino Del Regno wrote:
Move the CEC device parsing logic to a new function called
mtk_hdmi_get_cec_dev(), and move the parsing action to the end
of mtk_hdmi_dt_parse_pdata(), allowing to remove gotos in this
function, reducing code size and improving readability
Add some basic tests for exercising entity priority handling.
Signed-off-by: Tvrtko Ursulin
Cc: Christian König
Cc: Danilo Krummrich
Cc: Matthew Brost
Cc: Philipp Stanner
---
.../scheduler/tests/drm_sched_tests_basic.c | 99 ++-
1 file changed, 98 insertions(+), 1 deletion(
Move some options out into a new debug specific kconfig file in order to
make things a bit cleaner.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/Kconfig | 98 ++-
drivers/gpu/drm/Kconfig.debug | 92
2 files changed, 97 i
1 - 100 of 206 matches
Mail list logo
