From: Shixiong Ou
[WHY]
1. Drivers using DRM_GEM_SHADOW_PLANE_HELPER_FUNCS and
DRM_GEM_SHMEM_DRIVER_OPS (e.g., udl, ast) do not require
sg_table import.
They only need dma_buf_vmap() to access the shared buffer's
kernel virtual address.
2. On certain Aspeed-based boards, a dma_mask o
From: Shixiong Ou
Import dmabuf without mapping its sg_table to avoid issues likes:
udl 2-1.4:1.0: swiotlb buffer is full (sz: 2097152 bytes), total 65536
(slots), used 1 (slots)
Signed-off-by: Shixiong Ou
---
drivers/gpu/drm/udl/udl_drv.c | 19 +--
1 file changed, 1 insert
From: Shixiong Ou
Import dmabuf without mapping its sg_table to avoid issues likes:
ast :07:00.0: swiotlb buffer is full (sz: 3145728 bytes), total 32768
(slots), used 0 (slots)
Signed-off-by: Shixiong Ou
---
drivers/gpu/drm/ast/ast_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deleti
Adds a kernel-doc for externally linked dc_stream_remove_writeback() function.
Signed-off-by: James Flowers
---
drivers/gpu/drm/amd/display/dc/core/dc_stream.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_stream.c
b/drivers/gpu/drm/amd/displ
On Wed, 2025-04-30 at 20:50 -0700, Kuniyuki Iwashima wrote:
> From: Jeff Layton
> Date: Wed, 30 Apr 2025 20:42:40 -0700
> > On Wed, 2025-04-30 at 20:07 -0700, Kuniyuki Iwashima wrote:
> > > From: Jeff Layton
> > > Date: Wed, 30 Apr 2025 19:59:23 -0700
> > > > On Wed, 2025-04-30 at 14:29 -0700, Ku
On Wed, 2025-04-30 at 20:07 -0700, Kuniyuki Iwashima wrote:
> From: Jeff Layton
> Date: Wed, 30 Apr 2025 19:59:23 -0700
> > On Wed, 2025-04-30 at 14:29 -0700, Kuniyuki Iwashima wrote:
> > > From: Jeff Layton
> > > Date: Wed, 30 Apr 2025 08:06:54 -0700
> > > > After assigning the inode number to t
On Wed, 2025-04-30 at 14:29 -0700, Kuniyuki Iwashima wrote:
> From: Jeff Layton
> Date: Wed, 30 Apr 2025 08:06:54 -0700
> > After assigning the inode number to the namespace, use it to create a
> > unique name for each netns refcount tracker with the ns.inum value in
> > it, and register a symlink
On 4/29/2025 5:09 PM, Aleksandrs Vinarskis wrote:
DisplayPort requires per-segment link training when LTTPR are switched
to non-transparent mode, starting with LTTPR closest to the source.
Only when each segment is trained individually, source can link train
to sink.
Implement per-segment lin
On 4/29/2025 5:09 PM, Aleksandrs Vinarskis wrote:
Per-segment link training requires knowing the number of LTTPRs
(if any) present. Store the count during LTTPRs' initialization.
Fixes: 72d0af4accd9 ("drm/msm/dp: Add support for LTTPR handling")
Reviewed-by: Abel Vesa
Reviewed-by: Dmitry Ba
On 4/18/2025 12:50 AM, Dmitry Baryshkov wrote:
From: Dmitry Baryshkov
Qualcomm SAR2130P requires slightly different setup for the DSI PHY. It
is a 5nm PHY (like SM8450), so supplies are the same, but the rest of
the configuration is the same as SM8550 DSI PHY.
Signed-off-by: Dmitry Baryshko
On 4/29/2025 5:09 PM, Aleksandrs Vinarskis wrote:
Take into account LTTPR capabilities when selecting maximum allowed
link rate, number of data lines.
Fixes: 72d0af4accd9 ("drm/msm/dp: Add support for LTTPR handling")
Reviewed-by: Abel Vesa
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Alek
On 4/29/2025 5:09 PM, Aleksandrs Vinarskis wrote:
Initialize LTTPR before msm_dp_panel_read_sink_caps, as DPTX shall
(re)read DPRX caps after LTTPR detection, as required by DP 2.1,
Section 3.6.7.6.1.
Thanks for the patch.
Small correction: this is section 3.6.7.6.1 of DP 2.1a not DP 2.1
Hi Alex,
On 4/30/2025 8:09 PM, Alexandre Courbot wrote:
>>> I am just not seeing the benefits of not using dyn for
>>> this use case and only drawbacks. IMHO, we should try to not be doing the
>>> compiler's job.
>>>
>>> Maybe the only benefit is you don't need an Arc or Kbox wrapper?
>> That's no
On Thu May 1, 2025 at 3:16 AM JST, Danilo Krummrich wrote:
> On Wed, Apr 30, 2025 at 10:38:11AM -0400, Joel Fernandes wrote:
>> On 4/30/2025 9:25 AM, Alexandre Courbot wrote:
>> > On Tue Apr 22, 2025 at 11:44 PM JST, Danilo Krummrich wrote:
>>
>> >>> +/// Returns a boxed falcon HAL adequate for th
On Wed, Apr 30, 2025 at 08:21:59AM -0700, Ian Rogers wrote:
> On Thu, Apr 3, 2025 at 1:24 PM Ian Rogers wrote:
> >
> > DRM clients expose information through usage stats as documented in
> > Documentation/gpu/drm-usage-stats.rst (available online at
> > https://docs.kernel.org/gpu/drm-usage-stats.
Hi,
On Wed, Apr 30, 2025 at 10:52 AM Nick Bowler wrote:
>
> > > To clarify, there is no boot failure. There is just no video output
> > > after rebooting. I can then boot Linux again by any method that works
> > > without being able to see the screen, and then everything is fine once
> > > I do
Hi Neil,
On 4/29/2025 11:01 PM, neil.armstr...@linaro.org wrote:
> On 29/04/2025 08:06, Amirreza Zarrabi wrote:
>> This patch series introduces a Trusted Execution Environment (TEE)
>> driver for Qualcomm TEE (QTEE). QTEE enables Trusted Applications (TAs)
>> and services to run securely. It uses
On 4/30/2025 2:16 PM, Danilo Krummrich wrote:
[...]
>>> It is also the one that makes use of methods to abstract things (vs.
>>> fixed parameters), so it is a natural candidate for using virtual
>>> methods. I am not a fan of having ever-growing boilerplate match
>>> statements for each method that
On 4/29/2025 8:48 AM, Alexandre Courbot wrote:
> On Tue Apr 22, 2025 at 8:36 PM JST, Danilo Krummrich wrote:
>> On Sun, Apr 20, 2025 at 09:19:40PM +0900, Alexandre Courbot wrote:
>>> Upon reset, the GPU executes the GFW_BOOT firmware in order to
>>> initialize its base parameters such as clocks.
Pushed, thanks!
When a CL/CSD job times out, we check if the GPU has made any progress
since the last timeout. If so, instead of resetting the hardware, we skip
the reset and let the timer get rearmed. This gives long-running jobs a
chance to complete.
However, when `timedout_job()` is called, the job in question
On Tue, Apr 29, 2025 at 02:41:42PM +0200, Louis Chauvet wrote:
> Le 29/04/2025 à 11:27, Louis Chauvet a écrit :
> >
> > On Thu, 24 Apr 2025 20:59:07 +0200, Luca Ceresoli wrote:
> > > devm_drm_bridge_alloc() [0] is the new API to allocate and initialize a
> > > DRM
> > > bridge, and the only one s
On Mon, Apr 28, 2025 at 02:40:16PM +0300, Jani Nikula wrote:
> On Fri, 25 Apr 2025, Kees Cook wrote:
> > In preparation for making the kmalloc family of allocators type aware,
> > we need to make sure that the returned type from the allocation matches
> > the type of the variable being assigned. (
On Mon, Apr 28, 2025 at 01:09:46PM +0100, Tvrtko Ursulin wrote:
>
> On 26/04/2025 07:13, Kees Cook wrote:
> > In preparation for making the kmalloc family of allocators type aware,
> > we need to make sure that the returned type from the allocation matches
> > the type of the variable being assign
From: Lad Prabhakar
Simplify the high-speed clock frequency (HSFREQ) calculation by removing
the redundant multiplication and division by 8. The updated equation:
hsfreq = (mode->clock * bpp) / (dsi->lanes);
produces the same result while improving readability and clarity.
Additionally, up
From: Lad Prabhakar
The LCD controller (LCDC) on the RZ/V2H(P) SoC is composed of Frame
Compression Processor (FCPVD), Video Signal Processor (VSPD), and
Display Unit (DU).
There is one LCDC unit available on the RZ/V2H(P) SoC which is connected
to the DSI.
Signed-off-by: Lad Prabhakar
---
v3-
From: Lad Prabhakar
In preparation for adding support for the Renesas RZ/V2H(P) SoC, this patch
introduces a mechanism to pass SoC-specific information via OF data in the
DSI driver. This enables the driver to adapt dynamically to various
SoC-specific requirements without hardcoding configuration
From: Lad Prabhakar
Introduce the `RZ_MIPI_DSI_FEATURE_LPCLK` feature flag in
`rzg2l_mipi_dsi_hw_info` to indicate the need for LPCLK configuration.
On the RZ/V2H(P) SoC, the LPCLK clock rate influences the required
DPHY register configuration, whereas on the RZ/G2L SoC, this clock
is not presen
From: Lad Prabhakar
Pass the HSFREQ in milli-Hz to the `dphy_init()` callback to improve
precision, especially for the RZ/V2H(P) SoC, where PLL dividers require
high accuracy.
These changes prepare the driver for upcoming RZ/V2H(P) SoC support.
Co-developed-by: Fabrizio Castro
Signed-off-by: F
From: Lad Prabhakar
Introduce `dphy_conf_clks` and `dphy_mode_clk_check` callbacks in
`rzg2l_mipi_dsi_hw_info` to configure the VCLK and validate
supported display modes.
On the RZ/V2H(P) SoC, the DSI PLL dividers need to be as accurate as
possible. To ensure compatibility with both RZ/G2L and R
From: Lad Prabhakar
The DU block on the RZ/V2H(P) SoC is identical to the one found on the
RZ/G2L SoC. However, it only supports the DSI interface, whereas the
RZ/G2L supports both DSI and DPI interfaces.
Due to this difference, a SoC-specific compatible string
'renesas,r9a09g057-du' is added fo
From: Lad Prabhakar
Introduce the `RZ_MIPI_DSI_FEATURE_16BPP` flag in `rzg2l_mipi_dsi_hw_info`
to indicate support for 16BPP pixel formats. The RZ/V2H(P) SoC supports
16BPP, whereas this feature is missing on the RZ/G2L SoC.
Update the `mipi_dsi_host_attach()` function to check this flag before
From: Lad Prabhakar
Introduce the `dphy_late_init` callback in `rzg2l_mipi_dsi_hw_info` to
allow additional D-PHY register configurations after enabling data and
clock lanes. This is required for the RZ/V2H(P) SoC but not for the
RZ/G2L SoC.
Modify `rzg2l_mipi_dsi_startup()` to invoke `dphy_late
From: Lad Prabhakar
Add DSI support for Renesas RZ/V2H(P) SoC.
Co-developed-by: Fabrizio Castro
Signed-off-by: Fabrizio Castro
Signed-off-by: Lad Prabhakar
---
v3->v4
- In rzv2h_dphy_find_ulpsexit() made the array static const.
v2->v3:
- Simplifed V2H DSI timings array to save space
- Switc
From: Lad Prabhakar
Add support for PLLDSI and PLLDSI divider clocks.
Introduce the `renesas-rzv2h-dsi.h` header to centralize and share
PLLDSI-related data structures, limits, and algorithms between the RZ/V2H
CPG and DSI drivers.
The DSI PLL is functionally similar to the CPG's PLLDSI, but ha
From: Lad Prabhakar
The MIPI DSI interface on the RZ/V2H(P) SoC is nearly identical to that of
the RZ/G2L SoC. While the LINK registers are the same for both SoCs, the
D-PHY registers differ. Additionally, the number of resets for DSI on
RZ/V2H(P) is two compared to three on the RZ/G2L.
To accom
From: Lad Prabhakar
Update the RZ/G2L MIPI DSI driver to calculate HSFREQ using the actual
VCLK rate instead of the mode clock. The relationship between HSCLK and
VCLK is:
vclk * bpp <= hsclk * 8 * lanes
Retrieve the VCLK rate using `clk_get_rate(dsi->vclk)`, ensuring that
HSFREQ accurately
From: Lad Prabhakar
From: Lad Prabhakar
Hi All,
This patch series adds support for the Display Unit (DU) and MIPI DSI
interface on the Renesas RZ/V2H(P) SoC. The initial patches add PLLDSI
clocks and reset entries for the DSI and LCDC and the later patches add
support for the DU and DSI driver
From: Lad Prabhakar
The VCLK range for Renesas RZ/G2L SoC is 148.5 MHz to 5.803 MHz. Add a
minimum clock check in the mode_valid callback to ensure that the clock
value does not fall below the valid range.
Co-developed-by: Fabrizio Castro
Signed-off-by: Fabrizio Castro
Signed-off-by: Lad Prabh
From: Lad Prabhakar
Add clock and reset entries for the DSI and LCDC peripherals.
Co-developed-by: Fabrizio Castro
Signed-off-by: Fabrizio Castro
Signed-off-by: Lad Prabhakar
---
v3->v4:
- No changes
v2->v3:
- Reverted CSDIV0_DIVCTL2() to use DDIV_PACK()
- Renamed plleth_lpclk_div4 -> cdiv4_
On 4/13/2025 9:32 AM, Dmitry Baryshkov wrote:
If the Adreno device is used in a headless mode, there is no need to
build all KMS components. Build corresponding parts conditionally, only
selecting them if modeset support is actually required.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu
On 4/13/2025 9:32 AM, Dmitry Baryshkov wrote:
Extract two more KMS-related codepieces to msm_kms.c, removing last
pieces of KMS code from msm_drv.c.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/msm_drv.c | 9 +++--
drivers/gpu/drm/msm/msm_kms.c | 20
On 4/15/2025 1:59 AM, Dmitry Baryshkov wrote:
On 14/04/2025 18:58, Rob Clark wrote:
On Sun, Apr 13, 2025 at 9:33 AM Dmitry Baryshkov
wrote:
The global workqueue is only used for vblanks inside KMS code. Move
allocation / flushing / deallcation of it to msm_kms.c
Maybe we should also just
Document BOE TD4320 6.3" 2340x1080 panel
found in Xiaomi Redmi Note 7 smartphone.
Reviewed-by: Krzysztof Kozlowski
Signed-off-by: Barnabás Czémán
---
.../bindings/display/panel/boe,td4320.yaml | 65 ++
1 file changed, 65 insertions(+)
diff --git a/Documentation/devi
Add driver for BOE TD4320 DSI panel, used in Xiaomi Redmi Note 7
mobile phone.
Signed-off-by: Barnabás Czémán
---
drivers/gpu/drm/panel/Kconfig| 9 ++
drivers/gpu/drm/panel/Makefile | 1 +
drivers/gpu/drm/panel/panel-boe-td4320.c | 247 +++
3
Add driver for BOE TD4320 DSI panel, used in Xiaomi Redmi Note 7
smartphones.
Signed-off-by: Barnabás Czémán
---
Changes in v3:
- Convert to use devm_drm_panel_alloc
- Fix vsn, vsp supplies description.
- Link to v2:
https://lore.kernel.org/r/20250429-lavender-panel-v2-0-fb467ff81...@mainlining.
On Mon, Apr 28, 2025 at 10:18:34AM +0200, Louis Chauvet wrote:
>
>
> Le 26/04/2025 à 08:14, Kees Cook a écrit :
> > In preparation for making the kmalloc family of allocators type aware,
> > we need to make sure that the returned type from the allocation matches
> > the type of the variable being
-Original Message-
From: Hirschfeld, Dafna
Sent: Wednesday, April 30, 2025 12:07 AM
To: Cavitt, Jonathan
Cc: intel...@lists.freedesktop.org; Gupta, saurabhg ;
Zuo, Alex ; joonas.lahti...@linux.intel.com; Brost, Matthew
; Zhang, Jianxun ; Lin,
Shuicheng ; dri-devel@lists.freedesktop.or
On Wed, Apr 30, 2025 at 3:39 AM Konrad Dybcio
wrote:
>
> On 4/29/25 2:17 PM, Dmitry Baryshkov wrote:
> > On Mon, Apr 28, 2025 at 11:19:32PM +0200, Konrad Dybcio wrote:
> >> On 4/28/25 12:44 PM, Akhil P Oommen wrote:
> >>> On 4/14/2025 4:31 PM, Konrad Dybcio wrote:
> On 2/27/25 9:07 PM, Akhil
On Wed, Apr 30, 2025 at 10:38:11AM -0400, Joel Fernandes wrote:
> On 4/30/2025 9:25 AM, Alexandre Courbot wrote:
> > On Tue Apr 22, 2025 at 11:44 PM JST, Danilo Krummrich wrote:
>
> >>> +/// Returns a boxed falcon HAL adequate for the passed `chipset`.
> >>> +///
> >>> +/// We use this function an
To all X.Org Foundation Members:
The X.Org Foundation's annual election is now open and will remain open
until 23:59 UTC on 14 May 2025.
Four of the eight director seats are open during this election. The
four nominees receiving the highest vote totals serving as directors
for two year terms.
Th
Hi,
On Wed, Apr 30, 2025 at 10:05:44AM -0700, Doug Anderson wrote:
> On Wed, Apr 30, 2025 at 6:28 AM Nick Bowler wrote:
> > On Mon, Apr 28, 2025 at 01:40:25PM -0700, Doug Anderson wrote:
> > > On Sun, Apr 20, 2025 at 9:26 PM Nick Bowler wrote:
> > > > I recently noticed that on current kernels I
On 30/04/2025 19:37, Devarsh Thakkar wrote:
Hi Tomi
Thanks for the review.
@@ -2025,7 +2101,7 @@ int dispc_plane_check(struct dispc_device
*dispc, u32 hw_plane,
const struct drm_plane_state *state,
u32 hw_videoport)
{
- bool lite = dispc->feat->vid_l
Hi,
On Wed, Apr 30, 2025 at 6:28 AM Nick Bowler wrote:
>
> Hi Doug,
>
> On Mon, Apr 28, 2025 at 01:40:25PM -0700, Doug Anderson wrote:
> > On Sun, Apr 20, 2025 at 9:26■PM Nick Bowler wrote:
> > > I recently noticed that on current kernels I lose video output from
> > > my Blackbird's AST2500 BMC
On 30/04/2025 18:39, Konrad Dybcio wrote:
On 4/30/25 6:19 PM, neil.armstr...@linaro.org wrote:
On 30/04/2025 17:36, Konrad Dybcio wrote:
On 4/30/25 4:49 PM, neil.armstr...@linaro.org wrote:
On 30/04/2025 15:09, Konrad Dybcio wrote:
On 4/30/25 2:49 PM, neil.armstr...@linaro.org wrote:
On 30/0
Hello Doug,
On Wed, 30 Apr 2025 08:51:52 -0700
Doug Anderson wrote:
> Hi,
>
> On Wed, Apr 30, 2025 at 3:36 AM Luca Ceresoli
> wrote:
> >
> > Hello Doug,
> >
> > On Mon, 28 Apr 2025 13:59:50 -0700
> > Doug Anderson wrote:
> >
> > [...]
> >
> > > Reviewed-by: Douglas Anderson # parade-ps864
On 4/30/25 6:19 PM, neil.armstr...@linaro.org wrote:
> On 30/04/2025 17:36, Konrad Dybcio wrote:
>> On 4/30/25 4:49 PM, neil.armstr...@linaro.org wrote:
>>> On 30/04/2025 15:09, Konrad Dybcio wrote:
On 4/30/25 2:49 PM, neil.armstr...@linaro.org wrote:
> On 30/04/2025 14:35, Konrad Dybcio w
Hi Tomi
Thanks for the review.
>> @@ -2025,7 +2101,7 @@ int dispc_plane_check(struct dispc_device
>> *dispc, u32 hw_plane,
>> const struct drm_plane_state *state,
>> u32 hw_videoport)
>> {
>> - bool lite = dispc->feat->vid_lite[hw_plane];
>> + bool lite
On 4/30/25 6:20 PM, neil.armstr...@linaro.org wrote:
> On 30/04/2025 13:34, Konrad Dybcio wrote:
>> From: Konrad Dybcio
>>
>> On recent (SM8550+) Snapdragon platforms, the GPU speed bin data is
>> abstracted through SMEM, instead of being directly available in a fuse.
>>
>> Add support for SMEM-ba
On 30/04/2025 13:34, Konrad Dybcio wrote:
From: Konrad Dybcio
On recent (SM8550+) Snapdragon platforms, the GPU speed bin data is
abstracted through SMEM, instead of being directly available in a fuse.
Add support for SMEM-based speed binning, which includes getting
"feature code" and "product
On 30/04/2025 17:36, Konrad Dybcio wrote:
On 4/30/25 4:49 PM, neil.armstr...@linaro.org wrote:
On 30/04/2025 15:09, Konrad Dybcio wrote:
On 4/30/25 2:49 PM, neil.armstr...@linaro.org wrote:
On 30/04/2025 14:35, Konrad Dybcio wrote:
On 4/30/25 2:26 PM, neil.armstr...@linaro.org wrote:
Hi,
On
Hi,
On Wed, Apr 30, 2025 at 3:36 AM Luca Ceresoli wrote:
>
> Hello Doug,
>
> On Mon, 28 Apr 2025 13:59:50 -0700
> Doug Anderson wrote:
>
> [...]
>
> > Reviewed-by: Douglas Anderson # parade-ps8640
> > Tested-by: Douglas Anderson # parade-ps8640
>
> Thank you for your review!
>
> However I'll b
Em Fri, 25 Apr 2025 20:46:41 +0200
Nicolas Schier escreveu:
> On Thu, Apr 24, 2025 at 08:16:23AM +0800 Mauro Carvalho Chehab wrote:
> > As reported by Andy, kernel-doc.py is creating a __pycache__
> > directory at build time.
> >
> > Disable creation of __pycache__ for the libraries used by
> >
Hi Tomi
Thanks for the review. I had missed to respond back to below comment
before sending V5, so kindly find the response for the same as below.
On 27/03/25 16:48, Tomi Valkeinen wrote:
>> *dispc, u32 hw_plane,
>> const struct drm_plane_state *state,
>> u32 hw
On 4/30/25 4:49 PM, neil.armstr...@linaro.org wrote:
> On 30/04/2025 15:09, Konrad Dybcio wrote:
>> On 4/30/25 2:49 PM, neil.armstr...@linaro.org wrote:
>>> On 30/04/2025 14:35, Konrad Dybcio wrote:
On 4/30/25 2:26 PM, neil.armstr...@linaro.org wrote:
> Hi,
>
> On 30/04/2025 13:34,
Le 30/04/2025 à 12:39, Maxime Ripard a écrit :
On Wed, Apr 30, 2025 at 10:21:48AM +0200, Louis Chauvet wrote:
Le 29/04/2025 à 16:42, Dmitry Baryshkov a écrit :
On Tue, Apr 29, 2025 at 11:27:51AM +0200, Louis Chauvet wrote:
On Thu, 24 Apr 2025 20:59:07 +0200, Luca Ceresoli wrote:
devm_dr
Now that there is the ability to create a symlink for each tracker, do
so for the i915 entries.
Signed-off-by: Jeff Layton
---
drivers/gpu/drm/i915/intel_runtime_pm.c | 1 +
drivers/gpu/drm/i915/intel_wakeref.c| 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_r
On Thu, Apr 3, 2025 at 1:24 PM Ian Rogers wrote:
>
> DRM clients expose information through usage stats as documented in
> Documentation/gpu/drm-usage-stats.rst (available online at
> https://docs.kernel.org/gpu/drm-usage-stats.html). Add a tool like
> PMU, similar to the hwmon PMU, that exposes D
After assigning the inode number to the namespace, use it to create a
unique name for each netns refcount tracker with the ns.inum value in
it, and register a symlink to the debugfs file for it.
init_net is registered before the ref_tracker dir is created, so add a
late_initcall() to register its
This one is quite a bit of a change from the last set. I've gone back to
auto-registering the debugfs files for every ref_tracker_dir. With this,
the callers should pass in a static string as a classname instead of an
individual name string that gets copied. The debugfs file is given a
name "class@
Allow pr_ostream to also output directly to a seq_file without an
intermediate buffer. The first caller of +ref_tracker_dir_seq_print()
will come in a later patch, so mark that __maybe_unused for now. That
designation will be removed once it is used.
Reviewed-by: Andrew Lunn
Signed-off-by: Jeff L
Now that we have dentries and the ability to create meaningful symlinks
to them, don't keep a name string in each tracker. Switch the output
format to print "class@address", and drop the name field.
Also, add a kerneldoc header for ref_tracker_dir_init().
Signed-off-by: Jeff Layton
---
drivers/
In a later patch, we'll be adding a 3rd mechanism for outputting
ref_tracker info via seq_file. Instead of a conditional, have the caller
set a pointer to an output function in struct ostream. As part of this,
the log prefix must be explicitly passed in, as it's too late for the
pr_fmt macro.
Revi
Add a new "ref_tracker" directory in debugfs. Each individual refcount
tracker can register files under there to display info about
currently-held references.
Reviewed-by: Andrew Lunn
Signed-off-by: Jeff Layton
---
lib/ref_tracker.c | 16
1 file changed, 16 insertions(+)
diff
Currently, there is no convenient way to see the info that the
ref_tracking infrastructure collects. Attempt to create a file in
debugfs when called from ref_tracker_dir_init().
The file is given the name "class@%px", as having the unmodified address
is helpful for debugging. This should be safe s
Add the ability for a subsystem to add a user-friendly symlink that
points to a ref_tracker_dir's debugfs file.
Signed-off-by: Jeff Layton
---
include/linux/ref_tracker.h | 10 ++
lib/ref_tracker.c | 28
2 files changed, 38 insertions(+)
diff --git
A later patch in the series will be adding debugfs files for each
ref_tracker that get created in ref_tracker_dir_init(). The format will
be "class@%px". The current "name" string can vary between
ref_tracker_dir objects of the same type, so it's not suitable for this
purpose.
Add a new "class" st
As Thomas Weißschuh points out [1], it is now preferable to use %p
instead of hashed pointers with printk(), since raw pointers should no
longer be leaked into the kernel log. Change the ref_tracker
infrastructure to use %p instead of %pK in its formats.
[1]:
https://lore.kernel.org/netdev/202504
On 4/30/25 16:13, oushixiong wrote:
>
> 在 2025/4/30 19:03, Christian König 写道:
>> On 4/30/25 10:56,oushixiong1...@163.com wrote:
>>> From: Shixiong Ou
>>>
>>> [WHY]
>>> On some boards, the dma_mask of Aspeed devices is 0x_, this
>>> quite possibly causes the SWIOTLB to be triggered when im
On 30/04/2025 15:09, Konrad Dybcio wrote:
On 4/30/25 2:49 PM, neil.armstr...@linaro.org wrote:
On 30/04/2025 14:35, Konrad Dybcio wrote:
On 4/30/25 2:26 PM, neil.armstr...@linaro.org wrote:
Hi,
On 30/04/2025 13:34, Konrad Dybcio wrote:
From: Konrad Dybcio
Add speebin data for A740, as foun
[AMD Official Use Only - AMD Internal Distribution Only]
I am not very familiar with the process here but looking forward to some
response based.
"Any objections to merge this through amd-staging-drm-next?
The follow up amdgpu patches all depend on stuff in there which is not yet
merged to drm
Applied. Thanks!
On Wed, Apr 30, 2025 at 3:44 AM Antonio Fernando Silva e Cruz Filho
wrote:
>
> [WHY]
> Improve the output when using the ftrace debug feature,
> making it easier to identify which function is currently being executed.
>
> [HOW]
> Rename the program_timing function to a name that
On 4/30/2025 9:25 AM, Alexandre Courbot wrote:
> Hi Danilo,
>
> On Tue Apr 22, 2025 at 11:44 PM JST, Danilo Krummrich wrote:
>> This patch could probably split up a bit, to make it more pleasant to
>> review. :)
>
> Probably yes. I thought since it is mostly new files, splitting up
> wouldn't
Add detect_pipe_changes hook to dcn20_program_front_end_for_ctx and hook
the later to program_front_end_for_ctx in dcn401, then remove
dcn401_program_front_end_for_ctx duplicated code.
Signed-off-by: Melissa Wen
---
.../amd/display/dc/hwss/dcn20/dcn20_hwseq.c | 13 +-
.../amd/display/dc/hwss/
Enable hw_sequence_private funcs: enable plane for program_pipe and
post_unlock_reset_opp for post_unlock_program_front_end (even if this is
actually dcn20_post_unlock_reset_opp) to remove duplicated
post_unlock_program_front_end code on dcn401.
Signed-off-by: Melissa Wen
---
.../amd/display/dc/
Reduce code duplication by reusing dcn20_program_pipe since both
dcn401/dcn20_program_pipe now does the same thing and so its caller on
dcn401.
Signed-off-by: Melissa Wen
---
.../amd/display/dc/hwss/dcn401/dcn401_hwseq.c | 126 --
.../amd/display/dc/hwss/dcn401/dcn401_hwseq.h |
Hi,
I've been examining dcn401 code to figure out what is causing a wrong
cursor gamma on HDR issue reported in [1], and I found unnecessary code
duplications during this inspection. I don't have the HW, so I'd
appreciate if someone can validate this series (if it makes sense to you
ofc).
This se
The only actual difference between dcn20_program_pipe and
dcn401_program_pipe is the way they program global sync. Create a hook
to enable hw-family function calls, so that we can reuse
dcn20_program_pipe, avoid code duplication and prevent future partial
fixes for the same portion of code.
Signe
In this version, the global sync programming differs and needs an
specific function call slightly different from the commonly used
dcn20_program_tg. Hook up dcn401_program_tg only for dcn401.
Signed-off-by: Melissa Wen
---
.../gpu/drm/amd/display/dc/hwss/dcn401/dcn401_hwseq.c| 9 -
.
On Tue, 29 Apr 2025 19:18:01 -0700 Jeff Layton wrote:
> On Tue, 2025-04-29 at 16:27 -0700, Jakub Kicinski wrote:
> > On Mon, 28 Apr 2025 11:26:27 -0700 Jeff Layton wrote:
> > > Allow pr_ostream to also output directly to a seq_file without an
> > > intermediate buffer.
> > >
> > > Reviewed-by: A
On Wed, Apr 30, 2025 at 4:13 AM Dan Carpenter wrote:
>
> The "ticket" pointer points to in the middle of the &exec struct so it
> can't be NULL. Remove the check.
>
> Signed-off-by: Dan Carpenter
Applied. Thanks!
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c | 2 +-
> 1 file changed, 1 i
Applied. Thanks!
On Wed, Apr 30, 2025 at 4:08 AM Dan Carpenter wrote:
>
> This error path should call amdgpu_bo_unreserve() before returning.
>
> Fixes: d8675102ba32 ("drm/amdgpu: add vm root BO lock before accessing the
> vm")
> Signed-off-by: Dan Carpenter
> ---
> drivers/gpu/drm/amd/amdgpu
Similar to commit 6a057072ddd1 ("drm/amd/display: Fix null check for
pipe_ctx->plane_state in dcn20_program_pipe") that addresses a null
pointer dereference on dcn20_update_dchubp_dpp. This is the same
function hooked for update_dchubp_dpp in dcn401, with the same issue.
Fix possible null pointer d
在 2025/4/30 19:03, Christian König 写道:
On 4/30/25 10:56,oushixiong1...@163.com wrote:
From: Shixiong Ou
[WHY]
On some boards, the dma_mask of Aspeed devices is 0x_, this
quite possibly causes the SWIOTLB to be triggered when importing dmabuf.
However IO_TLB_SEGSIZE limits the maximum a
On 4/30/25 8:17 AM, Josef Lusticky wrote:
> The driver supports 3.5" Kingway HW-035P0Z002 display found
> on Braiins Mini Miner BMM 101 product.
>
> Signed-off-by: Josef Lusticky
> ---
I haven't really looked at the patch yet, but what about this display makes it
not compatible with "panel-mipi-
%p4cn was recently removed and replaced by %p4chR in vsprintf. So,
remove the check for %p4cn from checkpatch.pl.
Fixes: 37eed892cc5f ("vsprintf: Use %p4chR instead of %p4cn for reading data in
reversed host ordering")
Signed-off-by: Aditya Garg
---
v2: Add specific check for %p4chR as suggested
Hi Doug,
On Mon, Apr 28, 2025 at 01:40:25PM -0700, Doug Anderson wrote:
> On Sun, Apr 20, 2025 at 9:26■PM Nick Bowler wrote:
> > I recently noticed that on current kernels I lose video output from
> > my Blackbird's AST2500 BMC after a reboot
[...]
> > ce3d99c8349584bc0fbe1e21918a3ea1155343aa i
Hi Danilo,
On Tue Apr 22, 2025 at 11:44 PM JST, Danilo Krummrich wrote:
> This patch could probably split up a bit, to make it more pleasant to review.
> :)
Probably yes. I thought since it is mostly new files, splitting up
wouldn't change much. Let me see what I can do.
>
> On Sun, Apr 20, 202
The driver supports 3.5" Kingway HW-035P0Z002 display found
on Braiins Mini Miner BMM 101 product.
Signed-off-by: Josef Lusticky
---
drivers/gpu/drm/tiny/Kconfig | 14 ++
drivers/gpu/drm/tiny/Makefile | 1 +
drivers/gpu/drm/tiny/st7365p.c | 275 +
3 files ch
1 - 100 of 192 matches
Mail list logo
