* Sean Christopherson wrote:
> Drop wbinvd_on_all_cpus()'s return value; both the "real" version and the
> stub always return '0', and none of the callers check the return.
>
> Signed-off-by: Sean Christopherson
> ---
> arch/x86/include/asm/smp.h | 5 ++---
> arch/x86/lib/cache-smp.c | 3 +
* Sean Christopherson wrote:
> From: Kevin Loughlin
>
> In line with WBINVD usage, add WBONINVD helper functions. Fall back to
> WBINVD (via alternative()) if WBNOINVD isn't supported, as WBINVD provides
> a superset of functionality, just more slowly.
>
> Note, alternative() ensures compat
Rewrite the ADV7511 driver to use implementation provided by the DRM
HDMI connector framework, including the Audio and CEC bits. Drop the
in-bridge connector support and use drm_bridge_connector if the host
requires the connector to be provided by the bridge.
Note: currently only AVI InfoFrames ar
On Fri, May 16, 2025 at 09:49:53AM -0300, Jason Gunthorpe wrote:
> On Fri, May 16, 2025 at 02:19:45PM +0800, Xu Yilun wrote:
> > > I don't know why you'd disable a viommu while the VM is running,
> > > doesn't make sense.
> >
> > Here it means remove the CC setup for viommu, shared setup is still
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
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/vc4/Kconfig| 1 +
drivers/gpu/drm/vc4/vc4_hdmi.c | 137
As a preparation to adding HDMI CEC helper code, add CEC-related fields
to the struct drm_connector. The callbacks abstract CEC infrastructure
in order to support CEC adapters and CEC notifiers in a universal way.
CEC data is a void pointer as it allows us to make CEC data
helper-specific. For exa
THe Kconfig symbol DRM_DISPLAY_DP_AUX_CEC is a boolean which simply
toggles whether DP_AUX_CEC support should be built into the
drm_display_helper (which can be eithera module or built-in into the
kernel). If DRM_DISPLAY_DP_AUX_CEC is selected, then CEC_CORE is
selected to be built-in into the kern
Currently it is next to impossible to implement CEC handling for the
setup using drm_bridges and drm_bridge_connector: bridges don't have a
hold of the connector at the proper time to be able to route CEC events.
At the same time it not very easy and obvious to get the CEC physical
address handlin
WHen adding HDMI fields I didn't notice the private: declaration for HPD
fields. Move private fields to the end of the struct drm_bride to have
clear distinction between private and public fields.
Reviewed-by: Maxime Ripard
Signed-off-by: Dmitry Baryshkov
Signed-off-by: Dmitry Baryshkov
---
in
Allow HDMI DRM bridges to create CEC notifier. Physical address is
handled automatically by drm_atomic_helper_connector_hdmi_hotplug()
being called from .detect() path.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Maxime Ripard
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/display/drm_br
Implement necessary glue code to let DRM bridge drivers to implement CEC
adapters support.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Maxime Ripard
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/display/Kconfig| 1 +
drivers/gpu/drm/display/drm_bridge_connector.c | 83 +
Add generic CEC helpers to be used by HDMI drivers. Both notifier and
and adapter are supported for registration. Once registered, the driver
can call common set of functions to update physical address, to
invalidate it or to unregister CEC data. Unlike drm_connector_cec_funcs
(which provides inter
Call HDMI CEC helpers in order to update physical address of the
adapter.
Reviewed-by: Maxime Ripard
Signed-off-by: Dmitry Baryshkov
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/display/drm_hdmi_state_helper.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/dr
By default HDMI codec registers all formats supported on the I2S bus.
Allow bridges (and connectors) to limit the list of the PCM formats
supported by the HDMI codec.
Reviewed-by: Maxime Ripard
Signed-off-by: Dmitry Baryshkov
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/display/drm_brid
Am Do., 27. März 2025 um 00:58 Uhr schrieb Alex Hung :
>
> It is to be used to enable HDR by allowing userpace to create and pass
> 3D LUTs to kernel and hardware.
>
> new drm_colorop_type: DRM_COLOROP_3D_LUT.
>
> Signed-off-by: Alex Hung
> ---
> v8:
> - Fix typo in subject (Simon Ser)
> - Updat
On 4/30/2025 6:00 AM, Krzysztof Kozlowski wrote:
Hi,
Dependency / Rabased on top of
==
https://lore.kernel.org/all/20241214-dpu-drop-features-v1-0-988f0662c...@linaro.org/
Hey Krzysztof,
JFYI, I think there was some discussion on IRC (specifically #linux-msm)
a
The pull request you sent on Sat, 17 May 2025 06:44:48 +1000:
> https://gitlab.freedesktop.org/drm/kernel.git tags/drm-fixes-2025-05-17
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/12b6c62c038e85354154aee4eb2cf7a2168b3ecc
Thank you!
--
Deet-doot-dot, I am a bot.
h
Hi Heiko,
On 2025/5/15 21:00, Heiko Stübner wrote:
Hi,
Am Dienstag, 13. Mai 2025, 03:19:04 Mitteleuropäische Sommerzeit schrieb Chaoyi
Chen:
From: Chaoyi Chen
+ ports:
+$ref: /schemas/graph.yaml#/properties/ports
+
+properties:
+ port@0:
+$ref: /schemas/graph.yaml#/prop
On Thu, May 15, 2025 at 04:33:37PM +0300, Alexander Usyskin wrote:
> In intel-dg, there is no access to the spi controller,
> the information is extracted from the descriptor region.
...
> +static int intel_dg_nvm_init(struct intel_dg_nvm *nvm, struct device *device)
> +{
> + int ret;
> +
On Thu, May 15, 2025 at 04:33:36PM +0300, Alexander Usyskin wrote:
> Add auxiliary driver for intel discrete graphics
> non-volatile memory device.
A few nits below but we're good to go.
Reviewed-by: Raag Jadav
...
> +static int intel_dg_mtd_probe(struct auxiliary_device *aux_dev,
> +
On Thu, May 15, 2025 at 05:48:09PM -0700, Jessica Zhang wrote:
>
>
> On 5/14/2025 5:17 PM, Dmitry Baryshkov wrote:
> > On Thu, 15 May 2025 at 02:52, Jessica Zhang
> > wrote:
> > >
> > > Since the max mixer width is not a strict hardware limit, use the actual
> >
> > Is it? What is the actual m
From: Zheyun Shen
Before sev_vm_destroy() is called, kvm_arch_guest_memory_reclaimed()
has been called for SEV and SEV-ES and kvm_arch_gmem_invalidate()
has been called for SEV-SNP. These functions have already handled
flushing the memory. Therefore, this wbinvd_on_all_cpus() can
simply be droppe
From: Zheyun Shen
Extract KVM's open-coded calls to do writeback caches on multiple CPUs to
common library helpers for both WBINVD and WBNOINVD (KVM will use both).
Put the onus on the caller to check for a non-empty mask to simplify the
SMP=n implementation, e.g. so that it doesn't need to check
Drop wbinvd_on_all_cpus()'s return value; both the "real" version and the
stub always return '0', and none of the callers check the return.
Signed-off-by: Sean Christopherson
---
arch/x86/include/asm/smp.h | 5 ++---
arch/x86/lib/cache-smp.c | 3 +--
2 files changed, 3 insertions(+), 5 deletio
From: Zheyun Shen
On AMD CPUs without ensuring cache consistency, each memory page
reclamation in an SEV guest triggers a call to do WBNOINVD/WBINVD on all
CPUs, thereby affecting the performance of other programs on the host.
Typically, an AMD server may have 128 cores or more, while the SEV gu
From: Kevin Loughlin
AMD CPUs currently execute WBINVD in the host when unregistering SEV
guest memory or when deactivating SEV guests. Such cache maintenance is
performed to prevent data corruption, wherein the encrypted (C=1)
version of a dirty cache line might otherwise only be written back
af
Remove the checks and associated pr_err() on wbinvd_on_all_cpus() failure,
as the helper has unconditionally returned 0/success since commit
caa759323c73 ("smp: Remove smp_call_function() and on_each_cpu() return
values").
Signed-off-by: Sean Christopherson
---
drivers/gpu/drm/drm_cache.c | 9 ++
From: Kevin Loughlin
In line with WBINVD usage, add WBONINVD helper functions. Fall back to
WBINVD (via alternative()) if WBNOINVD isn't supported, as WBINVD provides
a superset of functionality, just more slowly.
Note, alternative() ensures compatibility with early boot code as needed.
Signed
Use wbinvd_on_cpu() to target a single CPU instead of open-coding an
equivalent. In addition to deduplicating code, this will allow removing
KVM's wbinvd_ipi() once the other usage is gone.
No functional change intended.
Reviewed-by: Tom Lendacky
Signed-off-by: Sean Christopherson
---
arch/x8
This is the combination of Kevin's WBNOINVD series[1] with Zheyun's targeted
flushing series[2]. The combined goal is to use WBNOINVD instead of WBINVD
when doing cached maintenance to prevent data corruption due to C-bit aliasing,
and to reduce the number of cache invalidations by only performing
Hi Dave, Simona,
Pull for v6.16 as described below. There are a pair of x1e80100 dts
patches, ack'd by Bjorn, to preserve ordering (the driver part needs
to land before the dts part). These should not conflict with any
other dts patches in flight this cycle.
The following changes since commit 0
On Wed, May 14, 2025 at 5:22 AM Jani Nikula
wrote:
> On Tue, 13 May 2025, Maxime Ripard wrote:
> > Is it really surprising you get some pushback when you are using a
> > design that is the complete opposite to what every user of it for the
> > last decade has been doing?
>
> The opposite is also
Hi Dave, Simona,
Last few updates for 6.16.
The following changes since commit 1faeeb315fdbd005bbc1bc74214e39087971dda9:
Merge tag 'amd-drm-next-6.16-2025-05-09' of
https://gitlab.freedesktop.org/agd5f/linux into drm-next (2025-05-12 07:14:34
+1000)
are available in the Git repository at:
Hi Linus,
Weekly drm fixes, I'll be honest and say I think this is larger than
I'd prefer at this point, the main blow out point is that xe has two
larger fixes.
One is a fix for active context utilisation reporting, it's for a
reported regression and will end up in stable anyways, so I don't see
On Fri, May 16, 2025 at 2:48 AM Jani Nikula wrote:
> On Thu, 15 May 2025, Bill Wendling wrote:
> > On 1/23/25 7:09 AM, Jani Nikula wrote:
> >> The expectation is that the struct drm_device based logging helpers get
> >> passed an actual struct drm_device pointer rather than some random
> >> struc
On Wed, 2025-05-07 at 22:52 +0900, Alexandre Courbot wrote:
> +impl FwSecBiosImage {
> + fn setup_falcon_data(
> + &mut self,
> + pdev: &pci::Device,
> + pci_at_image: &PciAtBiosImage,
> + first_fwsec_image: &FwSecBiosImage,
> + ) -> Result<()> {
> + let mut
On Sat, 17 May 2025 at 06:04, Johannes Weiner wrote:
>
> On Fri, May 16, 2025 at 07:42:08PM +0200, Christian König wrote:
> > On 5/16/25 18:41, Johannes Weiner wrote:
> > >>> Listen, none of this is even remotely new. This isn't the first cache
> > >>> we're tracking, and it's not the first consum
On Fri, May 16, 2025 at 07:42:08PM +0200, Christian König wrote:
> On 5/16/25 18:41, Johannes Weiner wrote:
> >>> Listen, none of this is even remotely new. This isn't the first cache
> >>> we're tracking, and it's not the first consumer that can outlive the
> >>> controlling cgroup.
> >>
> >> Yes,
Hey Dave,
sorry for the noise, I just wanted to quickly ask if with Daniels R-b
below this patch is good to go into 6.16 once the window opens? Still
new to the process here, therefore want to double-check :)
Thanks and best regards,
Robert Mader
On 12.05.25 16:26, Daniel Stone wrote:
Hi R
Hello Alexander,
On Mon, 12 May 2025 12:13:54 +
"Sverdlin, Alexander" wrote:
> > I've tested the patch wit LP8864 LED as a provider for led_bl, removing the
> > underlying I2C bus. The patch avoids the crash for me (by removing led_bl
> > device as well),
> > thanks for fixing it!
> >
> >
On Fri, May 16, 2025 at 1:36 AM Christian König
wrote:
>
> On 5/16/25 09:40, wangtao wrote:
> >
> >
> >> -Original Message-
> >> From: Christian König
> >> Sent: Thursday, May 15, 2025 10:26 PM
> >> To: wangtao ; sumit.sem...@linaro.org;
> >> benjamin.gaign...@collabora.com; brian.star...
On 2025-04-02 10:12, Ваторопин Андрей wrote:
> From: Andrey Vatoropin
>
> Static analysis shows that pointer "svms" cannot be NULL because it points
> to the object "struct svm_range_list". Remove the extra NULL check. It is
> meaningless and harms the readability of the code.
>
> In the function
tation/devicetree/bindings/npu/rockchip,rknn-core.example.dtb:
npu-core@fdac (rockchip,rk3588-rknn-core): reg: [[0, 4255907840, 0,
36864]] is too short
from schema $id:
http://devicetree.org/schemas/npu/rockchip,rknn-core.yaml#
doc reference errors (make refcheckdocs):
See
h
Hi,
On Thu, May 15, 2025 at 2:11 PM Rob Clark wrote:
>
> From: Rob Clark
>
> Add an eDP panel for BOE NV133WUM-N61, which appears to be a 3rd panel
> option on the lenevo x13s laptop.
>
> edid:
> 00 ff ff ff ff ff ff 00 09 e5 64 09 00 00 00 00
> 16 1e 01 04 a5 1d 12 78 03 55 8e a7 51 4c 9c 26
>
On 5/16/25 18:41, Johannes Weiner wrote:
>>> Listen, none of this is even remotely new. This isn't the first cache
>>> we're tracking, and it's not the first consumer that can outlive the
>>> controlling cgroup.
>>
>> Yes, I knew about all of that and I find that extremely questionable
>> on existi
On Fri, 2025-05-16 at 15:30 +0100, Tvrtko Ursulin wrote:
>
> On 16/05/2025 14:38, Philipp Stanner wrote:
> > On Fri, 2025-05-16 at 13:10 +0100, Tvrtko Ursulin wrote:
> > >
> > > On 16/05/2025 12:53, Tvrtko Ursulin wrote:
> > > >
> > > > On 16/05/2025 08:28, Philipp Stanner wrote:
> > > > > On Th
Drive-by fix, it doesn't seem like anything actually uses this constant
anymore.
Signed-off-by: Lyude Paul
---
rust/kernel/drm/gem/mod.rs | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/rust/kernel/drm/gem/mod.rs b/rust/kernel/drm/gem/mod.rs
index 2b81298d29765..d0f8da54f
Look mom, no generic soup!
Anyway - this is just the last of the cleanup stuff I ended up while
working on cleaning up the gem shmem patch series. It simplifies the use
of generics and also adds a type alias for some very long types
currently in use. Also, drop one unused constant I noticed.
Appl
Now that my rust skills have been honed, I noticed that there's a lot of
generics in our gem bindings that don't actually need to be here. Currently
the hierarchy of traits in our gem bindings looks like this:
* Drivers implement:
* BaseDriverObject (has the callbacks)
* DriverObject (ha
Just to reduce the clutter with the File<…> types in gem.rs.
Signed-off-by: Lyude Paul
---
rust/kernel/drm/gem/mod.rs | 26 ++
1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a/rust/kernel/drm/gem/mod.rs b/rust/kernel/drm/gem/mod.rs
index c17b36948bae3..2b81
Now that we've cleaned up the generics for gem objects a bit, we're still
left with a bit of generic soup around referring to the Object
implementation for a given driver. Let's clean this up a bit by re-using
the DriverObject identifier we just freed up and turning it into a type
alias for referri
On Thu, May 15, 2025 at 9:23 PM Leonardo Gomes
wrote:
>
> Thanks for your reply Alex,
>
> I just realize with your comment that
> drivers/gpu/drm/amd/display/dc/gpio/hw_gpio.c import dal_hw_gpio_get_value
> and dal_hw_gpio_set_value.
> So to make those functions inside
> drivers/gpu/drm/amd/dis
Using the DRM GPU scheduler infrastructure, with a scheduler for each
core.
Userspace can decide for a series of tasks to be executed sequentially
in the same core, so SRAM locality can be taken advantage of.
The job submission code was initially based on Panfrost.
v2:
- Remove hardcoded number
From: Nicolas Frattaroli
The NPU of the RK3588 has an external supply. This supply also affects
the power domain of the NPU, not just the NPU device nodes themselves.
Since correctly modelled boards will want the power domain to be aware
of the regulator so that it doesn't always have to be on, a
From: Nicolas Frattaroli
The NPU on the ROCK5B uses the same regulator for both the sram-supply
and the npu's supply. Add this regulator, and enable all the NPU bits.
Also add the regulator as a domain-supply to the pd_npu power domain.
Signed-off-by: Nicolas Frattaroli
Signed-off-by: Tomeu Viz
Enable the nodes added in a previous commit to the rk3588s device tree.
v2:
- Split nodes (Sebastian Reichel)
- Sort nodes (Sebastian Reichel)
- Add board regulators (Sebastian Reichel)
Signed-off-by: Tomeu Vizoso
---
.../arm64/boot/dts/rockchip/rk3588-quartzpro64.dts | 30 +
The NPU cores have their own access to the memory bus, and this isn't
cache coherent with the CPUs.
Add IOCTLs so userspace can mark when the caches need to be flushed, and
also when a writer job needs to be waited for before the buffer can be
accessed from the CPU.
Initially based on the same IO
This uses the SHMEM DRM helpers and we map right away to the CPU and NPU
sides, as all buffers are expected to be accessed from both.
v2:
- Sync the IOMMUs for the other cores when mapping and unmapping.
v3:
- Make use of GPL-2.0-only for the copyright notice (Jeff Hugo)
Signed-off-by: Tomeu Viz
This initial version supports the NPU as shipped in the RK3588 SoC and
described in the first part of its TRM, in Chapter 36.
This NPU contains 3 independent cores that the driver can submit jobs
to.
This commit adds just hardware initialization and power management.
v2:
- Split cores and IOMMUs
See Chapter 36 "RKNN" from the RK3588 TRM (Part 1).
This is a derivative of NVIDIA's NVDLA, but with its own front-end
processor.
The IP is divided in three cores, programmed independently. The first
core though is special, requiring to be powered on before any of the
others can be used.
The IOM
This series adds a new driver for the NPU that Rockchip includes in its
newer SoCs, developed by them on the NVDLA base.
In its current form, it supports the specific NPU in the RK3588 SoC.
The userspace driver is part of Mesa and an initial draft can be found at:
https://gitlab.freedesktop.org/
Add the bindings for the Neural Processing Unit IP from Rockchip.
v2:
- Adapt to new node structure (one node per core, each with its own
IOMMU)
- Several misc. fixes from Sebastian Reichel
v3:
- Split register block in its constituent subblocks, and only require
the ones that the kernel woul
Add KUnit tests for the newly introduced devm_drm_bridge_alloc().
Signed-off-by: Luca Ceresoli
---
Changed in v8:
- rebase on new patch converting drm_bridge_test.c to
devm_drm_bridge_alloc()
- add check that bridge is removed (thanks to the .destroy callback)
- add a check with get/put
Use the new DRM bridge allocation API, which is the only supported now, for
the kunit tests.
This change is more massive than for the typical DRM bridge driver because
struct drm_bridge_init_priv currently embeds a struct drm_bridge, which is
not supported anymore. We new have to use devm_drm_brid
Some users of DRM bridges may need to execute specific code just before
deallocation.
As of now the only known user would be KUnit tests.
Suggested-by: Maxime Ripard
Signed-off-by: Luca Ceresoli
---
This patch is new in v8. The .destroy callback had appeared in v5 as well
[5], but as part of
This small series adds a few kunit tests for the new DRM bridge allocation
flow, based on the recently introduced devm_drm_bridge_alloc() [0].
It is part of the work towards removal of bridges from a still existing DRM
pipeline without use-after-free.
The steps in the grand plan [1] are:
1. ➜ a
On Fri, May 16, 2025 at 05:35:12PM +0200, Christian König wrote:
> On 5/16/25 16:53, Johannes Weiner wrote:
> > On Fri, May 16, 2025 at 08:53:07AM +0200, Christian König wrote:
> >> The cgroup who originally allocated it has no reference to the
> >> memory any more and also no way of giving it back
I need to actually re-spin this one more time - I realized this mistakenly
hardcodes the gem object type for all callbacks (e.g. we wouldn't get an shmem
gem object when we add shmem support in the future) so i'll have to add a type
alias for this
On Thu, 2025-05-15 at 17:42 -0400, Lyude Paul wrot
On Fri, May 16, 2025 at 2:01 AM Danilo Krummrich wrote:
>
> On Thu, May 15, 2025 at 02:57:46PM -0700, Rob Clark wrote:
> > On Thu, May 15, 2025 at 10:55 AM Danilo Krummrich wrote:
> > > Anyways, I don't agree with that. Even if you can tweak your driver to
> > > not run
> > > into trouble with t
On Fri, 16 May 2025 at 03:39, Jessica Zhang
wrote:
>
>
>
> On 5/14/2025 5:28 PM, Dmitry Baryshkov wrote:
> > On Wed, May 14, 2025 at 04:52:31PM -0700, Jessica Zhang wrote:
> >> Validate requested mode and topology based on the PINGPONG or DSC encoder
> >> max width. In addition, drop MAX_HDISPLAY_
xa_store() may fail so check its return value and if error occurred free
numa_info and return NULL.
Signed-off-by: Salah Triki
---
drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
b/driv
On Thu, May 15, 2025 at 01:02:07PM +1000, Dave Airlie wrote:
> > I have to admit I'm pretty clueless about the gpu driver internals and
> > can't really judge how feasible this is. But from a cgroup POV, if you
> > want proper memory isolation between groups, it seems to me that's the
> > direction
This patch extends the DEV_QUERY ioctl to return information about the
performance counter setup for userspace, and introduces the new
ioctl DRM_PANTHOR_PERF_CONTROL in order to allow for the sampling of
performance counters.
The new design is inspired by the perf aux ringbuffer, with the insert
a
AIC100 devices generates Reliability, Availability, Serviceability events
via MHI QAIC_STATUS channel. Support such events and print a structured
log with details of the events, and if the event describes an uncorrected
error, reset the device to put it back into service. As these events may
not al
This patch implements the PANTHOR_PERF_CONTROL ioctl series, and
a PANTHOR_GET_UOBJ wrapper to deal with the backwards and forwards
compatibility of the uAPI.
The minor version is bumped to indicate that the feature is now
supported.
Signed-off-by: Lukas Zapolskas
Reviewed-by: Adrián Larumbe
--
Added the panthor_perf system initialization and unplug code to allow
for the handling of userspace sessions to be added in follow-up
patches.
Signed-off-by: Lukas Zapolskas
---
drivers/gpu/drm/panthor/panthor_device.c | 2 +
drivers/gpu/drm/panthor/panthor_device.h | 5 +-
drivers/gpu/drm/pan
From: Adrián Larumbe
The sampler aggregates counter and set requests coming from userspace
and mediates interactions with the FW interface, to ensure that user
sessions cannot override the global configuration.
>From the top-level interface, the sampler supports two different types
of samples: c
The sampler must disable and re-enable counter sampling around suspends,
and must re-program the FW interface after a reset to avoid losing
data.
Signed-off-by: Lukas Zapolskas
---
drivers/gpu/drm/panthor/panthor_device.c | 7 +-
drivers/gpu/drm/panthor/panthor_perf.c | 102 +
This change adds the IOCTL to query data about the performance counter
setup. Some of this data was available via previous DEV_QUERY calls,
for instance for GPU info, but exposing it via PERF_INFO
minimizes the overhead of creating a single session to just the one
aggregate IOCTL.
Signed-off-by: L
To allow for combining the requests from multiple userspace clients, an
intermediary layer between the HW/FW interfaces and userspace is
created, containing the information for the counter requests and
tracking of insert and extract indices. Each session starts inactive and
must be explicitly activ
Hello,
This patch set implements initial support for performance counter
sampling in Panthor, as a follow-up for Adrián Larumbe's patch
set [1]. This version of the patch series fixes a number of issues,
including FW ring buffer wrapping and IRQ handling for the
performance counter IRQs. The size
On Fri, May 16 2025 at 03:38:04 PM +, Steven J Abner
wrote:
A boot param like 'amd_prefcore=disable' could work
But kinda a band aid. What if you just download a Mainline kernel (as I
did to verify not a build/configure issue). Writing bug report to OS
provider could take a while for the
On 16/05/2025 13:00, Danilo Krummrich wrote:
On Fri, May 16, 2025 at 12:35:52PM +0100, Tvrtko Ursulin wrote:
On 16/05/2025 11:54, Danilo Krummrich wrote:
On Fri, May 16, 2025 at 11:19:50AM +0100, Tvrtko Ursulin wrote:
On 16/05/2025 10:53, Danilo Krummrich wrote:
On Fri, May 16, 2025 at 10
Hi Maxime,
On Thu, 15 May 2025 10:11:33 +0200
Maxime Ripard wrote:
> On Tue, Apr 15, 2025 at 01:22:14PM +0200, Luca Ceresoli wrote:
> > > > +/*
> > > > + * Mimick the typical struct defined by a bridge driver, which embeds a
> > > > + * bridge plus other fields.
> > > > + */
> > > > +struct dumm
On Fri, May 16 2025 at 03:02:47 PM +, Michel Dänzer
wrote:
FWIW, with GNOME the "max bpc" property value can be set
Issue is pre-DE, gnome or Xorg. A boot param like
'amd_prefcore=disable' could work. Issue then becomes putting into
dmesg so can figure its needed. Blacked out console har
On 5/16/25 16:53, Johannes Weiner wrote:
> On Fri, May 16, 2025 at 08:53:07AM +0200, Christian König wrote:
>> On 5/15/25 18:08, Johannes Weiner wrote:
Stop for a second.
As far as I can see the shrinker for the TTM pool should *not* be
memcg aware. Background is that pages who
On 2025-05-15 19:59, Harry Wentland wrote:
> Hi Steven,
>
> thanks for the bisect.
>
> In order to avoid display artifacts (especially for HDR) we had to
> allow higher bit depth color output on the wire. The driver should
> fallback to a lower resolution as needed but looks like there's a
> bug
On Fri, May 16, 2025 at 08:53:07AM +0200, Christian König wrote:
> On 5/15/25 18:08, Johannes Weiner wrote:
> >> Stop for a second.
> >>
> >> As far as I can see the shrinker for the TTM pool should *not* be
> >> memcg aware. Background is that pages who enter the pool are
> >> considered freed by
On 16/05/2025 15:03, Christian König wrote:
On 5/16/25 15:41, Tvrtko Ursulin wrote:
But because TTM shrinker does not currently update shrinkerctl->nr_scanned,
shrinker core assumes TTM looked at full SHRINK_BATCH pages with every call, and
adds and decrements that value to the counters it u
On 5/15/2025 3:31 AM, Jacek Lawrynowicz wrote:
From: Karol Wachowski
Add new inference_timeout_ms parameter that allows specifying
maximum allowed duration in milliseconds that inference can take before
triggering a recovery.
Calculate maximum number of heartbeat retries based on ratio between
On 5/15/2025 3:41 AM, Jacek Lawrynowicz wrote:
From: Karol Wachowski
Refactor ivpu_cmdq_unregister() to ensure the doorbell is unregistered
before destroying the command queue. The NPU firmware requires doorbells
to be unregistered prior to command queue destruction.
If doorbell remains regist
On 16/05/2025 14:38, Philipp Stanner wrote:
On Fri, 2025-05-16 at 13:10 +0100, Tvrtko Ursulin wrote:
On 16/05/2025 12:53, Tvrtko Ursulin wrote:
On 16/05/2025 08:28, Philipp Stanner wrote:
On Thu, 2025-05-15 at 17:17 +0100, Tvrtko Ursulin wrote:
On 15/05/2025 16:00, Christian König wrote:
On 5/15/25 2:11 PM, zhang.en...@zte.com.cn wrote:
From: Zhang Enpei
As opposed to open-code, use ERR_CAST to clearly indicate that this is a
pointer to an error value and a type conversion is performed.
Applied to drm-misc-next, thanks!
On 4/24/25 3:02 PM, Philipp Stanner wrote:
Just some minor attempts at improving the readability of
nouveau_fence.c
Applied to drm-misc-next, thanks!
On 4/30/25 10:06 AM, Dan Carpenter wrote:
"&chan->cgrp->mutex" and "&cgrp->mutex" are the same thing. Use
"&cgrp->mutex" consistently. It looks nicer and it silences a
Smatch static checker warning.
Applied to drm-misc-next, thanks!
Hello Adrián,
Thank you for reaching out about the matter. Could you please clarify what you
would like
me to elaborate on? I have responded to most, if not all, of the comments you
raised in that
review, including providing more information about the approach (please see [1]
for more details
On 5/16/25 15:41, Tvrtko Ursulin wrote:
>>> But because TTM shrinker does not currently update shrinkerctl->nr_scanned,
>>> shrinker core assumes TTM looked at full SHRINK_BATCH pages with every
>>> call, and adds and decrements that value to the counters it uses to
>>> determine when to stop tr
On 5/13/25 15:49, Dmitry Baryshkov wrote:
The msm_mapping@shadow test fails on SM8350, which means that the write
might get through (hopefully not though). Disable the test completely
for now until we can fix the issue.
Link: https://gitlab.freedesktop.org/drm/msm/-/issues/77
Signed-off-by: D
On 16/05/2025 12:46, Christian König wrote:
On 5/16/25 13:21, Tvrtko Ursulin wrote:
On 16/05/2025 09:23, Christian König wrote:
On 5/15/25 22:57, Tvrtko Ursulin wrote:
Currently the TTM pool shrinker ensures it frees at least something every
time it is invoked, but it also lies to the core
On Fri, 2025-05-16 at 13:10 +0100, Tvrtko Ursulin wrote:
>
> On 16/05/2025 12:53, Tvrtko Ursulin wrote:
> >
> > On 16/05/2025 08:28, Philipp Stanner wrote:
> > > On Thu, 2025-05-15 at 17:17 +0100, Tvrtko Ursulin wrote:
> > > >
> > > > On 15/05/2025 16:00, Christian König wrote:
> > > > > Sometim
1 - 100 of 171 matches
Mail list logo
