On 8/15/25 20:45, Shengyu Qu wrote:
Hi,
Thanks for reply. I guess we need to point this out in documentation or
code comment? As I can see different definition somewhere like this[1].
Best regards,
Shengyu
[1] https://color.org/chardata/rgb/BT2020.xalter
It's the same one. You can find
Hi,
Thanks for reply. I guess we need to point this out in documentation or
code comment? As I can see different definition somewhere like this[1].
Best regards,
Shengyu
[1] https://color.org/chardata/rgb/BT2020.xalter
在 2025/8/16 3:26, Alex Hung 写道:
On 8/15/25 11:54, Qu Shengyu wrote:
H
Hi Alex,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-exynos/exynos-drm-next]
[also build test WARNING on linus/master v6.17-rc1 next-20250815]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest
Hi,
kernel test robot noticed the following build errors:
[auto build test ERROR on drm-exynos/exynos-drm-next]
[also build test ERROR on linus/master v6.17-rc1 next-20250815]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use
Hi Damon,
kernel test robot noticed the following build errors:
[auto build test ERROR on drm-exynos/exynos-drm-next]
[also build test ERROR on rockchip/for-next linus/master v6.17-rc1
next-20250815]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting
Ma Ke 於 2025年8月12日 週二 下午3:19寫道：
>
> Using device_find_child() and of_find_device_by_node() to locate
> devices could cause an imbalance in the device's reference count.
> device_find_child() and of_find_device_by_node() both call
> get_device() to increment the reference count of the found device
The pull request you sent on Sat, 16 Aug 2025 07:24:32 +1000:
> https://gitlab.freedesktop.org/drm/kernel.git tags/drm-fixes-2025-08-16
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/dfd4b508c8c6106083698a0dd5e35aecc7c48725
Thank you!
--
Deet-doot-dot, I am a bot.
h
On Thu, Aug 14, 2025 at 05:13:54PM +0100, liviu.du...@arm.com wrote:
> Hi,
>
> On Wed, Aug 13, 2025 at 10:04:22AM +, Kandpal, Suraj wrote:
> > > > > };
> > > >
> > > > I still don't like that. This really doesn't belong here. If anything,
> > > > the drm_connector for writeback belongs to drm_
On Thu, Aug 14, 2025 at 07:52:13PM +0200, Konrad Dybcio wrote:
> On 8/14/25 6:38 PM, Akhil P Oommen wrote:
> > On 8/14/2025 7:56 PM, Neil Armstrong wrote:
> >> Hi,
> >>
> >> On 14/08/2025 13:22, Konrad Dybcio wrote:
> >>> On 8/14/25 1:21 PM, Konrad Dybcio wrote:
> On 7/31/25 12:19 PM, Konrad D
On Fri, Aug 15, 2025 at 09:04:34AM -0400, Rodrigo Vivi wrote:
> On Wed, Aug 13, 2025 at 10:50:25AM -0300, Luiz Otavio Mello wrote:
> > Move legacy BKL struct_mutex from drm_device to drm_i915_private, which
> > is the last remaining user.
> >
> > Signed-off-by: Luiz Otavio Mello
> > Reviewed-by:
On Thu, Aug 14, 2025 at 10:08:26PM +0530, Akhil P Oommen wrote:
> On 8/14/2025 7:56 PM, Neil Armstrong wrote:
> > Hi,
> >
> > On 14/08/2025 13:22, Konrad Dybcio wrote:
> >> On 8/14/25 1:21 PM, Konrad Dybcio wrote:
> >>> On 7/31/25 12:19 PM, Konrad Dybcio wrote:
> On 7/25/25 10:35 AM, Neil Arm
On Thu, Aug 14, 2025 at 04:16:09PM +0200, Neil Armstrong wrote:
> From: Christopher Obbard
>
> According to the eDP specification (VESA Embedded DisplayPort Standard
> v1.4b, Section 3.3.10.2), if the value of DP_EDP_PWMGEN_BIT_COUNT is
> less than DP_EDP_PWMGEN_BIT_COUNT_CAP_MIN, the sink is req
On Wed, Jul 30, 2025 at 12:19:56PM +0530, Aravind Iddamsetty wrote:
> Whenever a correctable or an uncorrectable error happens an event is sent
> to the corresponding listeners of these groups.
>
> v2: Rebase
> v3: protect with CONFIG_NET define.
>
> Reviewed-by: Michael J. Ruhl #v2
> Signed-off
On Wed, Jul 30, 2025 at 12:19:55PM +0530, Aravind Iddamsetty wrote:
> Netlink subsystem supports event notifications to userspace. we define
> two multicast groups for correctable and uncorrectable errors to which
> userspace can subscribe and be notified when any of those errors happen.
> The grou
On Wed, Jul 30, 2025 at 12:19:54PM +0530, Aravind Iddamsetty wrote:
> We expose the various error counters supported on a hardware via genl
> subsytem through the registered commands to userspace. The
> DRM_RAS_CMD_QUERY lists the error names with config id,
> DRM_RAD_CMD_READ_ONE returns the count
On Wed, Jul 30, 2025 at 12:19:53PM +0530, Aravind Iddamsetty wrote:
> Register netlink capability with the DRM and register the driver
> callbacks to DRM RAS netlink commands.
>
> v2:
> Move the netlink registration parts to DRM susbsytem (Tomer Tayar)
>
> v3: compile only if CONFIG_NET is enable
On Wed, Jul 30, 2025 at 12:19:52PM +0530, Aravind Iddamsetty wrote:
> Define the netlink registration interface and commands, attributes that
> can be commonly used across by drm drivers. This patch intends to use
> the generic netlink family to expose various stats of device. At present
> it defin
Hi Linus,
Relatively quiet week, usual amdgpu/i915/xe fixes along with a set of
fixes for fbdev format info, which fix some regressions seen in with
rc1.
Thanks,
Dave.
drm-fixes-2025-08-16:
drm fixes for 6.17-rc2
bridge:
- fix OF-node leak
- fix documentation
fbdev-emulation:
- pass correct fo
Hi Alex,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-exynos/exynos-drm-next]
[also build test WARNING on linus/master v6.17-rc1 next-20250815]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest
On Wed, Aug 13, 2025 at 04:21:03PM -0400, Rodrigo Vivi wrote:
> On Wed, Jul 30, 2025 at 12:19:51PM +0530, Aravind Iddamsetty wrote:
> > Revisiting this patch series to address pending feedback and help move
> > the discussion towards a conclusion. This revision includes updates
> > based on previou
On 7/24/25 6:54 PM, Miguel Ojeda wrote:
In 32-bit arm, the build fails with:
error[E0308]: mismatched types
--> drivers/gpu/drm/nova/file.rs:42:28
|
42 | getparam.set_value(value);
| - ^ expected `u64`, found `u32`
|
On 8/13/25 2:54 PM, Qianfeng Rong wrote:
Replace kfree() with kvfree() for memory allocated by kvmalloc().
Compile-tested only.
Cc: sta...@vger.kernel.org
Fixes: 8a8b1ec5261f ("drm/nouveau/gsp: split rpc handling out on its own")
Signed-off-by: Qianfeng Rong
Reviewed-by: Timur Tabi
Acked-by:
On 8/15/25 12:16 PM, Lizhi Hou wrote:
> Walking hardware contexts created by a process is duplicated in multiple
> spots. Add a function, amdxdna_hwctx_walk(), and replace all spots.
>
> hwctx_srcu and dev_lock are good enough to protect hardware context list.
> Remove hwctx_lock.
>
> Signed-off-
Hi Alex,
kernel test robot noticed the following build errors:
[auto build test ERROR on drm-exynos/exynos-drm-next]
[also build test ERROR on linus/master v6.17-rc1 next-20250815]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to
Hi,
Gentle ping on this patch.
Best Regards,
- Maíra
On 7/20/25 18:42, Maíra Canal wrote:
The global fault counter is no longer used since commit 12578c075f89
("drm/msm/gpu: Skip retired submits in recover worker"). However, it's
still needed, as we need to handle cases where a GPU fault occur
The per-fd reset counter tracks GPU resets caused by jobs submitted
through a specific file descriptor. However, there's a race condition
where the file descriptor can be closed while jobs are still running,
leading to potential access to freed memory when updating the reset
counter.
Ensure that t
CPU jobs and CACHE CLEAN jobs execute synchronously once the DRM
scheduler starts running them. Therefore, there is no fence to wait on,
neither are those jobs able to timeout.
Hence, remove the `timedout_job` hook from the CPU and CACHE CLEAN
scheduler ops.
Signed-off-by: Maíra Canal
Reviewed-b
When the file descriptor is closed while a job is still running,
there's a race condition between the job completion callback and the
file descriptor cleanup. This can lead to accessing freed memory when
updating per-fd GPU stats, such as the following example:
[56120.512903] Unable to handle kern
Each V3D queue works independently and all the dependencies between the
jobs are handled through the DRM scheduler. Therefore, there is no need
to use one single lock for all queues. Using it, creates unnecessary
contention between different queues that can operate independently.
Replace the globa
Instead of storing the queue's active job in four different variables,
store the active job inside the queue's state. This way, it's possible
to access all active jobs using an index based in `enum v3d_queue`.
Signed-off-by: Maíra Canal
Reviewed-by: Iago Toral Quiroga
---
drivers/gpu/drm/v3d/v3
Instead of storing a pointer to the DRM file data, store a pointer
directly to the private V3D file struct.
Signed-off-by: Maíra Canal
Reviewed-by: Iago Toral Quiroga
---
drivers/gpu/drm/v3d/v3d_drv.h| 4 ++--
drivers/gpu/drm/v3d/v3d_sched.c | 10 +-
drivers/gpu/drm/v3d/v3d_submit
This patch series was initially motivated by a race condition (exposed
in PATCH 4/6) where we lacked synchronization for `job->file` access.
This led to use-after-free issues when a file descriptor was closed
while a job was still running.
However, beyond fixing this specific race, the series intr
On 8/15/25 4:41 AM, Christian König wrote:
On 14.08.25 18:10, Andrew Davis wrote:
Hello all,
This series makes it so the udmabuf will sync the backing buffer
with the set of attached devices as required for DMA-BUFs when
doing {begin,end}_cpu_access.
Yeah the reason why we didn't do that is t
On 8/15/25 11:54, Qu Shengyu wrote:
Hello,
What actually is this OETF? Is it power 1/2.4? Or reversed BT.1886?
https://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.2020-2-201510-I!!PDF-E.pdf
(Table 4?)
Best regards,
Shengyu
On 8/10/25 5:07 PM, Javier Garcia wrote:
Add formating directive line in function `drm_gpuvm_sm_map_exec_lock()`
comment to clear warning messages shown bellow that appears generating
documentation `make htmldocs`.
Warning: ./drivers/gpu/drm/drm_gpuvm.c:2444: Unexpected indentation.
Warnin
Hi Alex,
kernel test robot noticed the following build errors:
[auto build test ERROR on drm-exynos/exynos-drm-next]
[also build test ERROR on linus/master v6.17-rc1 next-20250815]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to
Hi,
On Thu, Jul 31, 2025 at 10:52:49AM +0800, Andy Yan wrote:
>
> Hello Sebastian，
>
> 在 2025-07-30 20:15:44，"Andy Yan" 写道：
> >
> >
> >Hello Sebastian，
> >
> >At 2025-07-30 01:09:41, "Sebastian Reichel"
> > wrote:
> >>Hi,
> >>
> >>On Mon, Jul 28, 2025 at 04:28:34PM +0800, Andy Yan wrote:
> >>>
Hello,
What actually is this OETF? Is it power 1/2.4? Or reversed BT.1886?
Best regards,
Shengyu
发件人: amd-gfx 代表 Alex Hung
发送时间: Friday, August 15, 2025 11:50:20 AM
收件人: dri-devel@lists.freedesktop.org ;
amd-...@lists.freedesktop.org
抄送: wayland-de...@lists.
Hi,
On Mon, Jul 28, 2025 at 04:28:27PM +0800, Andy Yan wrote:
> From: Andy Yan
>
> The DW DP TX Controller is compliant with the DisplayPort Specification
> Version 1.4 with the following features:
>
> * DisplayPort 1.4a
> * Main Link: 1/2/4 lanes
> * Main Link Support 1.62Gbps, 2.7Gbps, 5.4Gbp
Walking hardware contexts created by a process is duplicated in multiple
spots. Add a function, amdxdna_hwctx_walk(), and replace all spots.
hwctx_srcu and dev_lock are good enough to protect hardware context list.
Remove hwctx_lock.
Signed-off-by: Lizhi Hou
---
drivers/accel/amdxdna/aie2_ctx.c
On 7/30/2025 12:49 AM, Aravind Iddamsetty wrote:
+static void drm_genl_family_init(struct drm_device *dev)
+{
+ dev->drm_genl_family = drmm_kzalloc(dev, sizeof(struct genl_family),
+ GFP_KERNEL);
+
+ /* Use drm primary node name eg: card0 to n
在 2025-08-15星期五的 17:53 +0800，Icenowy Zheng写道：
> 在 2025-08-15星期五的 11:09 +0200，Krzysztof Kozlowski写道：
> > On 15/08/2025 00:04, Rob Herring wrote:
> > > > +
> > > > +maintainers:
> > > > + - Icenowy Zheng
> > > > +
> > > > +properties:
> > > > + $nodename:
> > > > + pattern: "^display@[0-9a-f]+$
On 2025-06-23 09:38, Christopher Snowhill wrote:
> On Mon Jun 23, 2025 at 4:06 AM PDT, Christopher Snowhill wrote:
>> On Mon Jun 23, 2025 at 3:46 AM PDT, Christopher Snowhill wrote:
>>> On Fri Jun 20, 2025 at 3:10 AM PDT, Christopher Snowhill wrote:
Here's another alternative change, which
On 08:52-20250815, Andrew Davis wrote:
> > This also allows for some future compatibility to be checked only
> > against a restricted set of vid/pid.
^^ See below
> > static const struct of_device_id it66121_dt_match[] = {
> > - { .compatible = "ite
From: Dmitry Baryshkov
The DPU driver provides support for 4:2:0 planar YCbCr plane formats.
Extend it to also support 4:2:2 planar formats.
Signed-off-by: Dmitry Baryshkov
Signed-off-by: Dmitry Baryshkov
---
Changes in v2:
- Dropped 4:4:4 formats, they require higher clocks.
- Link to v1:
ht
On Sat, Jul 05, 2025 at 01:05:13PM +0300, Dmitry Baryshkov wrote:
> Switch VC4 driver to using CEC helpers code, simplifying hotplug and
> registration / cleanup. The existing vc4_hdmi_cec_release() is kept for
> now.
>
> Signed-off-by: Dmitry Baryshkov
> Reviewed-by: Maxime Ripard
> Signed-off-
On Mi, 2025-08-13 at 18:14 +0200, Wolfram Sang wrote:
> When using MMIO with regmap, fast_io is implied. No need to set it
> again.
>
> Signed-off-by: Wolfram Sang
> ---
> No dependencies, can be applied directly to the subsystem tree. Buildbot is
> happy, too.
>
> drivers/gpu/drm/bridge/synops
On Wed, 13 Aug 2025 18:14:46 +0200, Wolfram Sang wrote:
> While working on a driver using regmap with MMIO, I wondered if I need
> to set 'fast_io' in the config. Turned out I don't need to, so I added
> documentation for it with commit ffc72771ff6e ("regmap: Annotate that
> MMIO implies fast IO"
From: Wang Jiang
In commit 3c021931023a ("drm/amdgpu: replace drm_detect_hdmi_monitor() with
drm_display_info.is_hdmi")',
the method for determining connector types has been modified.
After the modification, when disconnecting the monitor, the information from
the previous connection cannot be
On Fri, Aug 15, 2025 at 6:36 AM Marie Zhussupova wrote:
>
> KUnit parameterized tests currently support two primary methods f
> or getting parameters:
> 1. Defining custom logic within a generate_params() function.
> 2. Using the KUNIT_ARRAY_PARAM() and KUNIT_ARRAY_PARAM_DESC()
> macros with
On 15/08/2025 15:10, Steven Price wrote:
> On 15/08/2025 15:01, Karunika Choo wrote:
>> On 15/08/2025 14:42, Steven Price wrote:
>>> The only callers to mmu_hw_do_operation_locked() pass an 'op' of either
>>> AS_COMAND_FLUSH_MEM or AS_COMMAND_FLUSH_PT. This means the code paths
>>> after that are d
From: Abhinav Kumar
On a vast majority of Qualcomm chipsets DisplayPort controller can
support several MST streams (up to 4x). To support MST these chipsets
use up to 4 stream pixel clocks for the DisplayPort controller. Expand
corresponding clock bindings for these platforms and fix example
sche
From: Jessica Zhang
Update Qualcomm DT files in order to declare extra stream pixel clocks
used on these platforms to support DisplayPort MST.
Signed-off-by: Jessica Zhang
Signed-off-by: Dmitry Baryshkov
---
arch/arm64/boot/dts/qcom/lemans.dtsi | 34
arch/arm64/boot/dts/qco
From: Abhinav Kumar
DP controller schema documents assigned-clocks and
assigned-clock-parents. However these assignments should not be a part
of the ABI: there are no actual requirements on the order of the
assignments, MST cases require different number of clocks to be
assigned, etc.
Instead of
From: Abhinav Kumar
Add X1E80100 to the dp-controller bindings, it has DisplayPort
controller similar to other platforms, but it uses its own compatible
string.
Signed-off-by: Abhinav Kumar
Signed-off-by: Jessica Zhang
Acked-by: Rob Herring (Arm)
Signed-off-by: Dmitry Baryshkov
---
Document
From: Abhinav Kumar
Fix c&p error and correct example to use 32-bit addressing (as the rest
of the example DT does) instead of 64-bit (as the platform does). It
got unnoticed before since DP controller node wasn't validated against
DT schema because of the missing compatible.
Fixes: 81de267367d
On Qualcomm SA8775P the DP controller might be driving either a
DisplayPort or a eDP sink (depending on the PHY that is tied to the
controller). Reflect that in the schema.
Acked-by: Rob Herring (Arm)
Signed-off-by: Dmitry Baryshkov
---
.../bindings/display/msm/dp-controller.yaml| 25 ++
On some MSM chipsets, the display port controller is capable of supporting
up to 4 streams.
To drive these additional streams, the pixel clocks for the corresponding
stream needs to be enabled.
Fixup the documentation of some of the bindings to clarify exactly which
stream they correspond to, the
On 04/07/2025 10:18, Steven Price wrote:
> On 04/07/2025 08:54, Sakari Ailus wrote:
>> pm_runtime_put_autosuspend(), pm_runtime_put_sync_autosuspend(),
>> pm_runtime_autosuspend() and pm_request_autosuspend() now include a call
>> to pm_runtime_mark_last_busy(). Remove the now-reduntant explicit ca
On 15/08/2025 15:01, Karunika Choo wrote:
> On 15/08/2025 14:42, Steven Price wrote:
>> The only callers to mmu_hw_do_operation_locked() pass an 'op' of either
>> AS_COMAND_FLUSH_MEM or AS_COMMAND_FLUSH_PT. This means the code paths
>> after that are dead. Removing those paths means the
>> mmu_hw_d
On 15/08/2025 14:42, Steven Price wrote:
> The only callers to mmu_hw_do_operation_locked() pass an 'op' of either
> AS_COMAND_FLUSH_MEM or AS_COMMAND_FLUSH_PT. This means the code paths
> after that are dead. Removing those paths means the
> mmu_hw_do_flush_on_gpu_ctrl() function might has well be
On 8/14/25 10:41 PM, Nishanth Menon wrote:
The IT66122 is a pin compatible replacement for the IT66122. Based on
empirical testing, the new device looks to be compatible with IT66121.
However due to a lack of public data sheet at this time beyond overall
feature list[1] (which seems to add additi
On 8/14/25 10:41 PM, Nishanth Menon wrote:
The driver knows exactly which version of the chip is present since
the vid/pid is used to enforce a compatibility. Given that some
devices like IT66121 has potentially been replaced with IT66122 mid
production for many platforms, it makes no sense to us
On 8/14/25 10:41 PM, Nishanth Menon wrote:
Drop the ftrace like dev_dbg() that checkpatch --strict complains about:
WARNING: Unnecessary ftrace-like logging - prefer using ftrace
+ dev_dbg(dev, "%s\n", __func__);
WARNING: Unnecessary ftrace-like logging - prefer using ftrace
+ dev_d
Hi
Am 15.08.25 um 15:28 schrieb Christian König:
On 15.08.25 14:46, Thomas Zimmermann wrote:
Hi Christian
Am 14.08.25 um 15:16 schrieb Christian König:
[...]
Another point to keep in mind is that other drivers besides amdgpu might also
be affected. Most drivers appear to be using drm_gem_p
The only callers to mmu_hw_do_operation_locked() pass an 'op' of either
AS_COMAND_FLUSH_MEM or AS_COMMAND_FLUSH_PT. This means the code paths
after that are dead. Removing those paths means the
mmu_hw_do_flush_on_gpu_ctrl() function might has well be inlined.
Simplify everything by having a switch
Replace redundant return value judgment with PTR_ERR_OR_ZERO() to
enhance code readability.
Signed-off-by: Liao Yuanhong
---
drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c | 5 +
drivers/gpu/drm/sun4i/sun4i_tcon_dclk.c | 5 +
drivers/gpu/drm/sun4i/sun8i_hdmi_phy_clk.c | 5 +
3 file
Replace redundant return value judgment with PTR_ERR_OR_ZERO() to
enhance code readability.
Signed-off-by: Liao Yuanhong
---
drivers/gpu/drm/nouveau/nouveau_platform.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_platform.c
b/drivers/gp
On 15.08.25 14:46, Thomas Zimmermann wrote:
> Hi Christian
>
> Am 14.08.25 um 15:16 schrieb Christian König:
> [...]
>>
>>
>>> Another point to keep in mind is that other drivers besides amdgpu might
>>> also be affected. Most drivers appear to be using drm_gem_prime_export(),
>>> which ends up
Am 15.08.25 um 15:03 schrieb Rodrigo Vivi:
On Wed, Aug 13, 2025 at 10:50:33AM -0300, Luiz Otavio Mello wrote:
This patch completes the removal of struct_mutex from the driver.
Remove the related TODO item, as the transition away from struct_mutex
is now complete.
Also clean up references to
@Wentland, Harry
, @Leo (Sunpeng) Li Can you guys take a look? This patch fixes a regression.
Thanks,
Alex
On Mon, Jun 23, 2025 at 11:33 AM Alex Deucher wrote:
>
> + Harry, Leo
>
> On Mon, Jun 23, 2025 at 9:38 AM Christopher Snowhill wrote:
> >
> > On Mon Jun 23, 2025 at 4:06 AM PDT, Christop
On Wed, Aug 13, 2025 at 10:50:25AM -0300, Luiz Otavio Mello wrote:
> Move legacy BKL struct_mutex from drm_device to drm_i915_private, which
> is the last remaining user.
>
> Signed-off-by: Luiz Otavio Mello
> Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/drm_drv.c | 2 --
On Wed, Aug 13, 2025 at 10:50:33AM -0300, Luiz Otavio Mello wrote:
> This patch completes the removal of struct_mutex from the driver.
>
> Remove the related TODO item, as the transition away from struct_mutex
> is now complete.
>
> Also clean up references to struct_mutex in i915.rst to avoid ou
Hi Christian
Am 14.08.25 um 15:16 schrieb Christian König:
[...]
Another point to keep in mind is that other drivers besides amdgpu might also
be affected. Most drivers appear to be using drm_gem_prime_export(), which ends
up with drm_gem_dmabuf_vmap(). So a fix there would benefit them.
Y
On 8/15/25 10:04, Matthew Brost wrote:
> On Fri, Aug 15, 2025 at 08:51:21AM +1000, Balbir Singh wrote:
>> On 8/13/25 10:07, Mika Penttilä wrote:
>>>
>>> On 8/13/25 02:36, Balbir Singh wrote:
>>>
On 8/12/25 15:35, Mika Penttilä wrote:
> Hi,
>
> On 8/12/25 05:40, Balbir Singh wrote:
On 15.08.25 13:15, Daniel Stone wrote:
> Hi Rob,
>
> On Thu, 14 Aug 2025 at 17:17, Rob Herring wrote:
>> On Thu, Aug 14, 2025 at 11:51:44AM +0100, Daniel Stone wrote:
>>> This is the main security issue, since it would allow writes a
>>> cmdstream BO which has been created but is not _the_ cmdstr
On 15/08/2025 12:17, Daniel Stone wrote:
> Hi Steven,
>
> On Fri, 15 Aug 2025 at 11:25, Steven Price wrote:
>> The only callers to mmu_hw_do_operation_locked() pass an 'op' of either
>> AS_COMAND_FLUSH_MEM or AS_COMMAND_FLUSH_PT. So remove the code paths
>> that test for other operations and add
Hi Rob,
On Thu, 14 Aug 2025 at 17:17, Rob Herring wrote:
> On Thu, Aug 14, 2025 at 11:51:44AM +0100, Daniel Stone wrote:
> > This is the main security issue, since it would allow writes a
> > cmdstream BO which has been created but is not _the_ cmdstream BO for
> > this job. Fixing that is pretty
Hi Steven,
On Fri, 15 Aug 2025 at 11:25, Steven Price wrote:
> The only callers to mmu_hw_do_operation_locked() pass an 'op' of either
> AS_COMAND_FLUSH_MEM or AS_COMMAND_FLUSH_PT. So remove the code paths
> that test for other operations and add a drm_WARN_ON() to catch the
> posibility of other
On Thu Aug 14, 2025 at 12:59 AM JST, Tamir Duberstein wrote:
> C-String literals were added in Rust 1.77. Replace instances of
> `kernel::c_str!` with C-String literals where possible.
>
> Acked-by: Greg Kroah-Hartman
> Reviewed-by: Alice Ryhl
> Reviewed-by: Benno Lossin
> Acked-by: Danilo Krumm
On Fri, 15 Aug 2025 at 18:36, Marie Zhussupova wrote:
>
> Add (*param_init) and (*param_exit) function pointers to
> `struct kunit_case`. Users will be able to set them via the new
> KUNIT_CASE_PARAM_WITH_INIT() macro.
>
> param_init/exit will be invoked by kunit_run_tests() once before and once
>
This patch updates the KUnit docs to show how to use the new
parameterized test context to share resources between parameter runs.
It documents and show examples of different ways the test user can
pass parameter arrays to a parameterized test. Finally, it specifies the
parameterized testing termin
Introduce example_params_test_with_init_dynamic_arr(). This new
KUnit test demonstrates directly assigning a dynamic parameter
array, using the kunit_register_params_array() macro, to a
parameterized test context.
It highlights the use of param_init() and param_exit() for
initialization and exit o
Add example_params_test_with_init() to illustrate how to manage
shared resources across a parameterized KUnit test. This example
showcases the use of the new param_init() function and its registration
to a test using the KUNIT_CASE_PARAM_WITH_INIT() macro.
Additionally, the test demonstrates how t
KUnit parameterized tests currently support two primary methods f
or getting parameters:
1. Defining custom logic within a generate_params() function.
2. Using the KUNIT_ARRAY_PARAM() and KUNIT_ARRAY_PARAM_DESC()
macros with a pre-defined static array and passing
the created *_gen_params(
To enable more complex parameterized testing scenarios, the
generate_params() function needs additional context beyond just
the previously generated parameter. This patch modifies the
generate_params() function signature to include an extra
`struct kunit *test` argument, giving test users access to
Add (*param_init) and (*param_exit) function pointers to
`struct kunit_case`. Users will be able to set them via the new
KUNIT_CASE_PARAM_WITH_INIT() macro.
param_init/exit will be invoked by kunit_run_tests() once before and once
after the parameterized test, respectively. They will receive the
`
Currently, KUnit parameterized tests lack a mechanism to share
resources across parameter runs because the same `struct kunit`
instance is cleaned up and reused for each run.
This patch introduces parameterized test context, enabling test
users to share resources between parameter runs. It also al
Hello!
KUnit offers a parameterized testing framework, where tests can be
run multiple times with different inputs. However, the current
implementation uses the same `struct kunit` for each parameter run.
After each run, the test context gets cleaned up, which creates
the following limitations:
a
The only callers to mmu_hw_do_operation_locked() pass an 'op' of either
AS_COMAND_FLUSH_MEM or AS_COMMAND_FLUSH_PT. So remove the code paths
that test for other operations and add a drm_WARN_ON() to catch the
posibility of others appearing the future.
Suggested-by: Daniel Stone
Signed-off-by: Ste
On 14/08/2025 23:58, Liviu Dudau wrote:
> On Fri, Aug 08, 2025 at 11:50:27AM +0100, Daniel Stone wrote:
>> Hi Karunika,
>>
>>
>> On Thu, 7 Aug 2025 at 17:27, Karunika Choo wrote:
>>> @@ -585,6 +615,9 @@ static int mmu_hw_do_operation_locked(struct
>>> panthor_device *ptdev, int as_nr,
>>>
Replace the original code with a switch statement to enhance
readability and unify code style.
No functional change.
Signed-off-by: Xichao Zhao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/am
在 2025-08-15星期五的 11:09 +0200，Krzysztof Kozlowski写道：
> On 15/08/2025 00:04, Rob Herring wrote:
> > > +
> > > +maintainers:
> > > + - Icenowy Zheng
> > > +
> > > +properties:
> > > + $nodename:
> > > + pattern: "^display@[0-9a-f]+$"
> > > +
> > > + compatible:
> > > + const: verisilicon,dc
On 07/08/2025 17:26, Karunika Choo wrote:
> In certain scenarios, it is possible for multiple cache flushes to be
> requested before the previous one completes. This patch introduces the
> cache_flush_lock mutex to serialize these operations and ensure that
> any requested cache flushes are complet
On 14.08.25 18:10, Andrew Davis wrote:
> Hello all,
>
> This series makes it so the udmabuf will sync the backing buffer
> with the set of attached devices as required for DMA-BUFs when
> doing {begin,end}_cpu_access.
Yeah the reason why we didn't do that is that this doesn't even work 100%
reli
On 14/08/2025 18:40, Icenowy Zheng wrote:
> +
> +examples:
> + - |
> +#include
> +#include
> +#include
> +
> +soc {
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + hdmi@ffef54 {
> +compatible = "thead,th1520-dw-hdmi";
> +reg = <0xff 0
On 15/08/2025 00:04, Rob Herring wrote:
>> +
>> +maintainers:
>> + - Icenowy Zheng
>> +
>> +properties:
>> + $nodename:
>> +pattern: "^display@[0-9a-f]+$"
>> +
>> + compatible:
>> +const: verisilicon,dc
>
> If the clocks or resets varies by platform, then you need an SoC
> specific co
1 - 100 of 117 matches
Mail list logo
