X1P42100 SoC has a new GPU called Adreno X1-45 which is a smaller
version of Adreno X1-85 GPU. Describe this new GPU and also add
the secure gpu firmware path that should used for X1P42100 CRD.
Tested-by: Jens Glathe
Signed-off-by: Akhil P Oommen
---
arch/arm64/boot/dts/qcom/x1e80100.dtsi|
In order to enable GPU support in X1P42100-CRD and other similar
laptops with Snapdragon X1P42100 SoC, enable X1P42100 GPUCC driver
as a module.
Tested-by: Jens Glathe
Signed-off-by: Akhil P Oommen
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/c
In some cases, an OPP may have multiple varients to describe the
differences in the resources between SKUs. As an example, we may
want to vote different peak bandwidths in different SKUs for the
same frequency and the OPP node names can have an additional
integer suffix to denote this difference li
Add support for Adreno X1-45 GPU present Snapdragon X1P42100
series of compute chipsets. This GPU is a smaller version of
X1-85 GPU with lower core count and smaller internal memories.
Reviewed-by: Konrad Dybcio
Reviewed-by: Dmitry Baryshkov
Tested-by: Jens Glathe
Signed-off-by: Akhil P Oommen
Add support for X1-45 GPU found in X1P41200 chipset (8 cpu core
version). X1-45 is a smaller version of X1-85 with lower core count and
smaller memories. From UMD perspective, this is similar to "FD735"
present in Mesa.
Tested Glmark & Vkmark on Debian Gnome desktop.
I think Bjorn can pick the DT
Use u32 for level variable as one may need to pass value for
DP_EDP_PANEL_TARGET_LUMINANCE_VALUE.
--v2
-Typecase is not needed [Jani]
Signed-off-by: Suraj Kandpal
Reviewed-by: Arun R Murthy
---
drivers/gpu/drm/display/drm_dp_helper.c | 2 +-
include/drm/display/drm_dp_helper.h | 2 +-
2 fi
Use drm dp helper to enable backlight now that it has been modified
to set PANEL_LUMINANCE_CONTROL_ENABLE bit based on if capability
supports it and the driver wants it. Remove the dead code.
Signed-off-by: Suraj Kandpal
Reviewed-by: Arun R Murthy
---
.../gpu/drm/i915/display/intel_dp_aux_backl
Now that the drm helper sets the backlight using luminance
too we can use that. Remove the obselete function.
Signed-off-by: Suraj Kandpal
Reviewed-by: Arun R Murthy
---
.../drm/i915/display/intel_dp_aux_backlight.c | 34 ++-
1 file changed, 3 insertions(+), 31 deletions(-)
dif
Now that drm_edp_backlight init has been modified to take
into account the setup of lumininace based brightness manipulation
we can just use that.
--v2
-Fix commit message [Arun]
Signed-off-by: Suraj Kandpal
---
.../drm/i915/display/intel_dp_aux_backlight.c | 98 +--
1 file chan
Add flag to enable brightness control via luminance value
when enabling edp backlight.
Signed-off-by: Suraj Kandpal
Reviewed-by: Arun R Murthy
---
drivers/gpu/drm/display/drm_dp_helper.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/display/drm_dp_helper.c
b/drivers/gp
Change the argument type to u32 for the default level being sent
since it has to now account for luminance value which has to be
set for DP_EDP_PANEL_LUMINANCE_TARGET_VALUE.
--v2
-No need to typecast [Jani]
Signed-off-by: Suraj Kandpal
Reviewed-by: Arun R Murthy
---
drivers/gpu/drm/display/drm
Modify drm_edp_backlight_set_level to be able to set the value
for register in DP_EDP_PANEL_TARGET_LUMINANCE_VALUE. We multiply
the level with 1000 since we get the value in Nits and the
register accepts it in milliNits.
--v2
-Add comment regarding the unit [Arun]
Signed-off-by: Suraj Kandpal
Re
Change the current_level argument type to u32 from u16
since it can now carry the value which it gets from
DP_EDP_PANEL_TARGET_LUMINANCE_VALUE.
Signed-off-by: Suraj Kandpal
Reviewed-by: Arun R Murthy
---
drivers/gpu/drm/display/drm_dp_helper.c | 4 ++--
drivers/gpu/drm/i915/displa
Introduce luminance_set flag which indicates if we can manipulate
backlight using luminance value or not which is only possible
after eDP v1.5.
Signed-off-by: Suraj Kandpal
Reviewed-by: Arun R Murthy
---
drivers/gpu/drm/display/drm_dp_helper.c | 8 ++--
include/drm/display/drm_dp_helper.h
Modify drm_edp_probe_state to read current level from
DP_EDP_PANEL_TARGET_LUMINANCE_VALUE. We divide it by
1000 since the value in this register is in millinits.
--v2
-Add comment on the unit sent back [Arun]
Signed-off-by: Suraj Kandpal
Reviewed-by: Arun R Murthy
---
drivers/gpu/drm/display/d
Use u32 instead of u16 for max variable in drm_edp_backlight_info
since it can now hold max luminance range value which is u32.
We will set this max with max_luminance value when luminance_set is
true.
Signed-off-by: Suraj Kandpal
---
drivers/gpu/drm/display/drm_dp_helper.c | 10 +++---
incl
This series modifies drm dp edp helpers so that drivers can now use them
to manipulate brightness using luminance value via the
PANEL_TARGET_LUMINANCE_VALUE register. This feature was
introduced frin eDP 1.5.
Signed-off-by: Suraj Kandpal
Suraj Kandpal (13):
drm/dp: Introduce new member in drm_
Add new argument to drm_edp_backlight_init which gives the
max_luminance which will be needed to set the max values for
backlight.
--v2
-Use pass only max luminance instead of luminance_range_info struct
[Arun]
Signed-off-by: Suraj Kandpal
---
drivers/gpu/drm/display/drm_dp_helper.c
Add bool argument in drm_edp_backlight init to provide the drivers
option to choose if they want to use luminance values to
manipulate brightness.
Signed-off-by: Suraj Kandpal
Reviewed-by: Arun R Murthy
---
drivers/gpu/drm/display/drm_dp_helper.c | 7 ---
drivers/gpu/drm/i915/
The pull request you sent on Fri, 20 Jun 2025 13:25:32 +1000:
> https://gitlab.freedesktop.org/drm/kernel.git tags/drm-fixes-2025-06-20
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/5f2b6c5f6b692c696a232d12c43b8e41c0d393b9
Thank you!
--
Deet-doot-dot, I am a bot.
h
> -Original Message-
> From: Murthy, Arun R
> Sent: Friday, June 20, 2025 11:00 AM
> To: Kandpal, Suraj ;
> nouv...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; intel-
> x...@lists.freedesktop.org; intel-...@lists.freedesktop.org
> Cc: Nautiyal, Ankit K
> Subject: RE: [PATCH
> -Original Message-
> From: Kandpal, Suraj
> Sent: Friday, May 9, 2025 10:48 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
> Subject
> -Original Message-
> From: Kandpal, Suraj
> Sent: Monday, April 14, 2025 9:47 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
> -Original Message-
> From: Kandpal, Suraj
> Sent: Friday, May 9, 2025 10:48 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
> Subj
> -Original Message-
> From: Kandpal, Suraj
> Sent: Monday, April 14, 2025 9:47 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
> -Original Message-
> From: Kandpal, Suraj
> Sent: Monday, April 14, 2025 9:47 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
Am 19.06.25 um 18:07 schrieb Zenghui Yu:
Hi Thomas,
On 2025/6/19 00:25, Thomas Zimmermann wrote:
Hi
Am 18.06.25 um 18:03 schrieb Zenghui Yu:
Hi all,
Running the dmabuf-heap test [*] on mainline kernel triggers the
following splat:
[ cut here ]
DMA-API: platfo
> > > Add flag to enable brightness control via luminance value when
> > > enabling edp backlight.
> > >
> > > Signed-off-by: Suraj Kandpal
> > > ---
> > > drivers/gpu/drm/display/drm_dp_helper.c | 3 +++
> > > 1 file changed, 3 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/display/drm_d
> -Original Message-
> From: Murthy, Arun R
> Sent: Friday, June 20, 2025 10:17 AM
> To: Kandpal, Suraj ;
> nouv...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; intel-
> x...@lists.freedesktop.org; intel-...@lists.freedesktop.org
> Cc: Nautiyal, Ankit K
> Subject: RE: [PATCH
> -Original Message-
> From: Kandpal, Suraj
> Sent: Monday, April 14, 2025 9:47 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
> -Original Message-
> From: Kandpal, Suraj
> Sent: Monday, April 14, 2025 9:47 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
> -Original Message-
> From: Kandpal, Suraj
> Sent: Monday, April 14, 2025 9:47 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 Mon, Jun 02, 2025 at 10:37:27AM -0300, Jason Gunthorpe wrote:
> On Thu, May 29, 2025 at 01:34:43PM +0800, Xu Yilun wrote:
>
> > This series has 3 sections:
>
> I really think this is too big to try to progress, even in RFC
> form.
Sorry, I missed this message...
Yeah, I just try to give a ov
Hi Michal,
kernel test robot noticed the following build warnings:
[auto build test WARNING on 4774cfe3543abb8ee98089f535e28ebfd45b975a]
url:
https://github.com/intel-lab-lkp/linux/commits/Michal-Wilczynski/power-sequencing-Add-T-HEAD-TH1520-GPU-power-sequencer-driver/20250618-182429
base:
Hi Linus,
Bit of an uptick in fixes for rc3, msm and amdgpu leading the way,
with i915/xe/nouveau with a few each and then some scattered misc
bits, nothing looks too crazy,
Dave.
drm-fixes-2025-06-20:
drm fixes for 6.16-rc3
msm:
- Display:
- Fixed DP output on SDM845
- Fixed 10nm DSI PLL i
From: Mario Limonciello
The x86 specific check for whether a framebuffer belongs to a device
works for display devices as well as VGA devices. Callers to
video_is_primary_device() can benefit from checking non-VGA display
devices.
Move the x86 specific check into x86 specific code, and adjust V
From: Mario Limonciello
Knowing which device is the primary device can be useful for userspace
to make decisions on which device to start a display server.
Create a link to that device called 'primary_device'.
Signed-off-by: Mario Limonciello
---
drivers/video/fbdev/core/fbcon.c | 10
From: Mario Limonciello
The inline pci_is_display() helper does the same thing. Use it.
Reviewed-by: Daniel Dadap
Reviewed-by: Simona Vetter
Suggested-by: Bjorn Helgaas
Signed-off-by: Mario Limonciello
---
drivers/iommu/intel/iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
d
From: Mario Limonciello
The inline pci_is_display() helper does the same thing. Use it.
Reviewed-by: Daniel Dadap
Reviewed-by: Simona Vetter
Suggested-by: Bjorn Helgaas
Signed-off-by: Mario Limonciello
---
drivers/gpu/vga/vga_switcheroo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(
From: Mario Limonciello
The inline pci_is_display() helper does the same thing. Use it.
Reviewed-by: Daniel Dadap
Reviewed-by: Simona Vetter
Suggested-by: Bjorn Helgaas
Signed-off-by: Mario Limonciello
---
sound/hda/hdac_i915.c | 2 +-
sound/pci/hda/hda_intel.c | 4 ++--
2 files change
From: Mario Limonciello
This series started out as changes to VGA arbiter to try to handle a case
of a system with 2 GPUs that are not VGA devices [1]. This was discussed
but decided not to overload the VGA arbiter for non VGA devices.
Instead move the x86 specific detection of framebuffer reso
From: Mario Limonciello
The inline pci_is_display() helper does the same thing. Use it.
Acked-by: Alex Williamson
Reviewed-by: Daniel Dadap
Reviewed-by: Simona Vetter
Suggested-by: Bjorn Helgaas
Signed-off-by: Mario Limonciello
---
drivers/vfio/pci/vfio_pci_igd.c | 3 +--
1 file changed,
From: Mario Limonciello
Several places in the kernel do class shifting to match whether a
PCI device is display class. Introduce a helper for those places to
use.
Reviewed-by: Daniel Dadap
Reviewed-by: Simona Vetter
Signed-off-by: Mario Limonciello
---
include/linux/pci.h | 15 +
From: Chaoyi Chen
The bridge used in drm_connector_hdmi_audio_init() does not correctly
point to the required audio bridge, which lead to incorrect audio
configuration input.
Fixes: 231adeda9f67 ("drm/bridge-connector: hook DisplayPort audio support")
Signed-off-by: Chaoyi Chen
---
drivers/gpu
HI Piotr，
在 2025-06-19 19:54:12，"Piotr Zalewski" 写道：
>Hi Andy
>
>>
>> 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
On Wed, 18 Jun 2025 10:24:13 -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 Thu, 19 Jun 2025 17:20:25 +1000 Dave Airlie wrote:
>
> While discussing memcg intergration with gpu memory allocations,
> it was pointed out that there was no numa/system counters for
> GPU memory allocations.
>
> With more integrated memory GPU server systems turning up, and
> more requirem
On 2025-06-19 14:37, Francis, David wrote:
>
> [AMD Official Use Only - AMD Internal Distribution Only]
>
>
> > > + spin_lock(&filp->table_lock);
> > > + idr_for_each_entry(&filp->object_idr, gobj, id)
> > > + num_bos += 1;
> > > + spin_unlock(&filp->table_lock);
> > > +
> >
Put the panel reference back when driver is no
longer using it.
Patch added in v2.
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/tegra/dsi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/tegra/dsi.c b/drivers/gpu/drm/tegra/dsi.c
index
b5089b7722676cfaee5d28216af4ae70
The panel is looked for in exynos_dp_probe() which
calls analogix_dp_probe() after which the prepare(),
enable(), disable() and unprepare() helpers are called.
Put the reference after unprepare()
Patch added in v2.
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/bridge/analogix/analogix_dp_c
Put the panel reference returned by of_drm_find_panel()
back when driver is no longer using it.
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/mcde/mcde_dsi.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mcde/mcde_dsi.c b/drivers/gpu/drm/mcde/mcde_d
Put the panel reference back when driver is no
longer using it.
Patch added in v2
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb
Put the panel reference back to keep up
with refcounting.
Patch added in v2.
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/drm_of.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
index
d0183dea770308e77f05da364ffe087d53f3be36..2bd
Put the reference of the panel returned by
of_drm_find_panel().
Patch added in v2.
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/omapdrm/dss/output.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/output.c
b/drivers/gpu/drm/omapdrm/ds
Put the reference of the panel returned by
of_drm_find_panel() in the disable() function
after which panel won't be used.
Patch added in v2.
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/sti/sti_dvo.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/sti/sti_dvo.c b/dri
The panel returned by of_drm_find_panel() is for
calling devm_drm_panel_bridge_add and not
anywhere after that.
Put the panel reference accordingly.
Patch added in v2.
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/bridge/fsl-ldb.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/dri
The panel returned by of_drm_find_panel() is for
calling devm_drm_panel_bridge_add_typed and not
anywhere after that.
Put the panel reference accordingly.
Patch added in v2.
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/bridge/lvds-codec.c | 1 +
1 file changed, 1 insertion(+)
diff --git
The panel returned by of_drm_find_panel() is mainly
for the purpose of devm_drm_panel_bridge_add_typed().
Put the panel back accordingly.
This patch added in v2.
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/renesas/rz-du/rzg2l_du_encoder.c | 1 +
1 file changed, 1 insertion(+)
diff --git
The panel returned by of_drm_find_panel() is used to be
passed to devm_drm_panel_bridge_add_typed(). Put the
reference back accordingly.
This patch added in v2.
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/renesas/rcar-du/rcar_du_encoder.c | 2 ++
1 file changed, 2 insertions(+)
diff --g
Put the panel reference back when driver is no
longer using it.
Signed-off-by: Anusha Srivatsa
---
v2: move drm_panel_put() inside the if()
---
drivers/gpu/drm/exynos/exynos_drm_dpi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dpi.c
b/drivers/gpu/drm/e
Put the panel reference back when driver is no
longer using it.
Signed-off-by: Anusha Srivatsa
---
v2: none.
---
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
index
c3
Put the panel reference back when driver is no
longer using it. The panel that of_drm_find_panel()
returns is or the purpose of finding a out->bridge.
After which it is no longer used. Drop the refcount
accordingly.
Signed-off-by: Anusha Srivatsa
---
v2: Explain in commit message why the refcount
of_drm_find_panel() returns a panel pointer that the caller
holds. With refcounting in place, increment the refcount
of the panel that is returned. This reference has to be put()
by the caller.
Document the behaviour expected from all callers of this
API.
Signed-off-by: Anusha Srivatsa
---
drive
Take the panel reference and put it back as required.
drm_panel_add() and drm_panel_remove() add a panel to
the global registry and removes a panel respectively.
Use get() and put() helpers to keep up with refcounting.
Reviewed-by: Luca Ceresoli
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/dr
of_drm_find_panel() returns a pointer to a panel which the caller
holds to either do panel setup with the prepare(), enable() like
panel helpers or for APIs like devm_drm_panel_bridge_add(),
devm_drm_panel_bridge_add_typed() which expect a panel.
Either way, once the driver no longer needs the pane
On Thu, Jun 19, 2025 at 03:17:31PM +0200, Benno Lossin wrote:
> On Thu Jun 19, 2025 at 2:26 PM CEST, Daniel Almeida wrote:
> > Hi Benno,
> >
> >> On 19 Jun 2025, at 08:01, Benno Lossin wrote:
> >>
> >> On Thu Jun 19, 2025 at 12:55 PM CEST, Danilo Krummrich wrote:
> >>> On Thu, Jun 19, 2025 at 12:
[AMD Official Use Only - AMD Internal Distribution Only]
> > + spin_lock(&filp->table_lock);
> > + idr_for_each_entry(&filp->object_idr, gobj, id)
> > + num_bos += 1;
> > + spin_unlock(&filp->table_lock);
> > +
> > + if (args->num_bos < num_bos) {
> > + args
On Thu, Jun 19, 2025 at 01:57:09PM +0200, Boris Brezillon wrote:
> I'm digressing, but there's an aspect I found very annoying in the C
> version of the API: the fact that we have to take a BO ref, then lock,
> then release the vm_bo [1], because otherwise the vm_bo might be the
> last owner of a B
On 6/18/2025 1:02 AM, Dmitry Baryshkov wrote:
On Tue, 17 Jun 2025 at 17:11, Jyothi Kumar Seerapu
wrote:
On 5/30/2025 10:12 PM, Dmitry Baryshkov wrote:
On Fri, May 30, 2025 at 07:36:05PM +0530, Jyothi Kumar Seerapu wrote:
On 5/21/2025 6:15 PM, Dmitry Baryshkov wrote:
On Wed, May 21, 2
Hi Thomas,
On 2025/6/19 00:25, Thomas Zimmermann wrote:
> Hi
>
> Am 18.06.25 um 18:03 schrieb Zenghui Yu:
> > Hi all,
> >
> > Running the dmabuf-heap test [*] on mainline kernel triggers the
> > following splat:
> >
> > [ cut here ]
> > DMA-API: platform vgem: mapping sg
Hi Dave, Simona
Three fixes for -rc3. There are a couple more pending with
non-trivial merge conflicts that need to be properly
backported.
drm-xe-fixes-2025-06-19:
Driver Changes:
- A workaround update (Vinay)
- Fix memset on iomem (Lucas)
- Fix early wedge on GuC Load failure (Daniele)
The fol
Clean up references to `kernel::str::CStr`.
Signed-off-by: Tamir Duberstein
---
drivers/gpu/drm/drm_panic_qr.rs | 3 ++-
drivers/gpu/nova-core/firmware.rs | 2 +-
drivers/gpu/nova-core/nova_core.rs| 2 +-
drivers/net/phy/ax88796b_rust.rs | 1 +
drivers/net/phy/qt2025.rs
This picks up from Michal Rostecki's work[0]. Per Michal's guidance I
have omitted Co-authored tags, as the end result is quite different.
Link:
https://lore.kernel.org/rust-for-linux/20240819153656.28807-2-vadorov...@protonmail.com/t/#u
[0]
Closes: https://github.com/Rust-for-Linux/linux/issues
Introduce a `fmt!` macro which wraps all arguments in
`kernel::fmt::Adapter` and a `kernel::fmt::Display` trait. This enables
formatting of foreign types (like `core::ffi::CStr`) that do not
implement `core::fmt::Display` due to concerns around lossy conversions which
do not apply in the kernel.
R
`kernel::ffi::CStr` was introduced in commit d126d2380131 ("rust: str:
add `CStr` type") in November 2022 as an upstreaming of earlier work
that was done in May 2021[0]. That earlier work, having predated the
inclusion of `CStr` in `core`, largely duplicated the implementation of
`std::ffi::CStr`.
C-String literals were added in Rust 1.77. Replace instances of
`kernel::c_str!` with C-String literals where possible and rename
`kernel::c_str!` to `str_to_cstr!` to clarify its intended use.
Closes: https://github.com/Rust-for-Linux/linux/issues/1075
Signed-off-by: Tamir Duberstein
---
driver
Remove a handful of unncessary intermediate vectors and token streams;
mainly the top-level stream can be directly extended with the notable
exception of groups.
Remove an unnecessary `#[allow(dead_code)]` added in commit dbd5058ba60c
("rust: make pin-init its own crate").
Signed-off-by: Tamir Du
kzalloc() already zero-initializes the destination buffers, making
strscpy() sufficient for safely copying the names. The additional
NUL-padding performed by strscpy_pad() is unnecessary.
If the destination buffer has a fixed length, strscpy() automatically
determines its size using sizeof() when
Fix the following kernel doc warning:
include/drm/drm_device.h:40: warning: Function parameter or struct member 'pid'
not described in 'drm_wedge_task_info'
include/drm/drm_device.h:40: warning: Function parameter or struct member
'comm' not described in 'drm_wedge_task_info'
Fixes: 183bccafa17
Fix the following warning:
Documentation/gpu/drm-uapi.rst:450: WARNING: Title underline too short.
Task information
--- [docutils]
Fixes: cd37124b4093 ("drm/doc: Add a section about "Task information" for the
wedge API")
Reported-by: Stephen Rothwell
Signed-off-by: André Almeida
-
On Thu, 19 Jun 2025 at 14:31, Bartosz Golaszewski wrote:
>
> On Thu, Jun 19, 2025 at 12:25 PM Ulf Hansson wrote:
> >
> > On Wed, 18 Jun 2025 at 12:22, Michal Wilczynski
> > wrote:
> > >
> > > In order to support the complex power sequencing required by the TH1520
> > > GPU, the AON power domain
On Tue, Jun 17, 2025 at 10:28:40PM -0700, Vivek Kasireddy wrote:
> There are cases when we try to pin a folio but discover that it has
> not been faulted-in. So, we try to allocate it in memfd_alloc_folio()
> but there is a chance that we might encounter a fatal crash/failure
> (VM_BUG_ON(!h->resv_
Hi Boris,
> On 19 Jun 2025, at 08:57, Boris Brezillon
> wrote:
>
> Hi,
>
> On Fri, 13 Jun 2025 13:42:59 -0300
> Daniel Almeida wrote:
>
>> Danilo,
>>
>>
>>>
>>>
>> +// SAFETY: DRM GpuVmBo objects are always reference counted and the
>> get/put functions
>> +// satisfy the re
Add runtime PM since we might call populate_mm on a foreign device.
v3:
- Fix a kerneldoc failure (Matt Brost)
- Revert the bo type change from device to kernel (Matt Brost)
v4:
- Add an assert in xe_svm_alloc_vram (Matt Brost)
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Brost
---
dri
Add an operation to populate a part of a drm_mm with device
private memory. Clarify how migration using it is intended
to work.
v3:
- Kerneldoc fixes and updates (Matt Brost).
v4:
- More kerneldoc fixes. Rebase.
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Brost
---
drivers/gpu/drm/drm
From: Matthew Brost
The migration functionality and track-keeping of per-pagemap VRAM
mapped to the CPU mm is not per GPU_vm, but rather per pagemap.
This is also reflected by the functions not needing the drm_gpusvm
structures. So move to drm_pagemap.
With this, drm_gpusvm shouldn't really acce
This patchset modifies the migration part of drm_gpusvm to drm_pagemap and
adds a populate_mm() op to drm_pagemap.
The idea is that the device that receives a pagefault determines if it wants to
migrate content and to where. It then calls the populate_mm() method of relevant
drm_pagemap.
This fun
Hi,
On Mon, Jun 16, 2025 at 03:05:17PM +0800, Andy Yan wrote:
> From: Andy Yan
>
> Although the datasheet of the panel module describes that it has a
> reset pin, in the actual hardware design, we often use an RC circuit
> to control the reset, and rarely use GPIO to control the reset. This
> is
Some of the firmwares need to be patched at load-time with a signature.
Add a couple of types and traits that sub-modules can use to implement
this behavior, while ensuring that the correct kind of signature is
applied to the firmware.
Reviewed-by: Lyude Paul
Signed-off-by: Alexandre Courbot
---
From: Joel Fernandes
Using the support for navigating the VBIOS, add support to extract vBIOS
ucode data required for GSP to boot. The main data extracted from the
vBIOS is the FWSEC-FRTS firmware which runs on the GSP processor. This
firmware runs in high secure mode, and sets up the WPR2 (Write
On Thu Jun 19, 2025 at 3:26 PM CEST, Alexandre Courbot wrote:
> On Thu Jun 19, 2025 at 4:24 AM JST, Benno Lossin wrote:
>> On Mon Jun 16, 2025 at 8:41 AM CEST, Alexandre Courbot wrote:
>>> On Sun Jun 15, 2025 at 4:16 AM JST, Benno Lossin wrote:
On Thu Jun 12, 2025 at 4:01 PM CEST, Alexandre Co
Although there are various small changes between the init
sequences, the second half is common for all 3 currently
supported displays.
Note that this is only compile-tested.
Signed-off-by: Priit Laes
---
.../gpu/drm/panel/panel-newvision-nv3052c.c | 408 --
1 file changed, 74
On Thu Jun 19, 2025 at 4:24 AM JST, Benno Lossin wrote:
> On Mon Jun 16, 2025 at 8:41 AM CEST, Alexandre Courbot wrote:
>> On Sun Jun 15, 2025 at 4:16 AM JST, Benno Lossin wrote:
>>> On Thu Jun 12, 2025 at 4:01 PM CEST, Alexandre Courbot wrote:
+#[inline(always)]
+
FWSEC-FRTS is run with the desired address of the FRTS region as
parameter, which we need to compute depending on some hardware
parameters.
Do this in a `FbLayout` structure, that will be later extended to
describe more memory regions used to boot the GSP.
Reviewed-by: Lyude Paul
Signed-off-by:
With all the required pieces in place, load FWSEC-FRTS onto the GSP
falcon, run it, and check that it successfully carved out the WPR2
region out of framebuffer memory.
Reviewed-by: Lyude Paul
Signed-off-by: Alexandre Courbot
---
drivers/gpu/nova-core/falcon.rs | 3 --
drivers/gpu/nova
A few new dependencies are required to remove some of the TODO items:
- A way to safely convert from byte slices to types implementing
`FromBytes`,
- A way to obtain slices and write into a `CoherentAllocation`,
- Several improvements to the `register!()` macro,
- Alignment operations to powers
The FWSEC firmware needs to be extracted from the VBIOS and patched with
the desired command, as well as the right signature. Do this so we are
ready to load and run this firmware into the GSP falcon and create the
FRTS region.
[joelagn...@nvidia.com: give better names to FalconAppifHdrV1's fields
Booting the GSP on Ampere requires an intricate dance between the GSP
and SEC2 falcons, where the GSP starts by running the FWSEC firmware to
create the WPR2 region , and then SEC2 loads the actual RISC-V firmware
into the GSP.
Add the common Falcon code and HAL for Ampere GPUs, and instantiate th
From: Joel Fernandes
Add support for navigating the VBIOS images required for extracting
ucode data for GSP to boot. Later patches will build on this.
Debug log messages will show the BIOS images:
[102141.013287] NovaCore: Found BIOS image at offset 0x0, size: 0xfe00, type:
PciAt
[102141.08069
From: Joel Fernandes
The PMU table in the FWSEC image has to be located to locate the start
of the Falcon ucode in the same or another FWSEC image. Add support for
the same.
Signed-off-by: Joel Fernandes
Signed-off-by: Alexandre Courbot
---
drivers/gpu/nova-core/vbios.rs | 179 +++
1 - 100 of 180 matches
Mail list logo
