| Age | Commit message (Collapse) | Author |
|---|
|
As specified in section 5.7.2 of the ACPI specification the feature
group string "3.0 _SCP Extensions" implies that the operating system
evaluates the _SCP control method with additional parameters.
However the ACPI thermal driver evaluates the _SCP control method
without those additional parameters, conflicting with the above
feature group string advertised to the firmware thru _OSI.
Stop advertising support for this feature string to avoid confusing
the ACPI firmware.
Fixes: e5f660ebef68 ("ACPI / osi: Collect _OSI handling into one single file")
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://patch.msgid.link/20250410165456.4173-2-W_Armin@gmx.de
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
"&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.
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Link: https://lore.kernel.org/r/aBHaCM66pXaP84ei@stanley.mountain
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
With all of the boundary conditions when streaming the commands B2B in our
validation (part of the reason we added the flush), the Flush effectively
serializes the transmission of each command enqueued within the command
dispatcher to one per V. Blank line which simplifies the behavior of the
High Speed Arbitration.
So, unless we absolutely have to burst these to the Sink, we should be
using the Pipeline Flush bit to serialize the commands.
Bspec: 19742, 50193
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14247
Cc: Suraj Kandpal <suraj.kandpal@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Gareth Yu <gareth.yu@intel.com>
Link: https://lore.kernel.org/r/20250509092539.763389-1-gareth.yu@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
In nouveau_fence_done(), a fence is checked for being signaled by
manually evaluating the base fence's bits. This can be done in a
canonical manner through dma_fence_is_signaled().
Replace the bit-check with dma_fence_is_signaled().
Signed-off-by: Philipp Stanner <phasta@kernel.org>
Link: https://lore.kernel.org/r/20250424130254.42046-6-phasta@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
nouveau_fence_done() contains an if branch that checks whether a
nouveau_fence has either of the two existing nouveau_fence backend ops,
which will always evaluate to true.
Remove the surplus check.
Signed-off-by: Philipp Stanner <phasta@kernel.org>
Reviewed-by: Christian König <christian.koenig@amd.com>
Link: https://lore.kernel.org/r/20250424130254.42046-5-phasta@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
nouveau_fence_signal() returns a de-facto boolean to indicate when
nvif_event_block() shall be called.
The code can be made more compact and readable by calling
nvif_event_block() in nouveau_fence_update() directly.
Make those calls in nouveau_fence.c more canonical.
Signed-off-by: Philipp Stanner <phasta@kernel.org>
Link: https://lore.kernel.org/r/20250424130254.42046-4-phasta@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
nouveau_fence.c iterates over lists in a non-canonical way. Since the
operations done are just basic for-each-loops and list-empty checks,
they should be written in the standard form.
Use standard list operations.
Signed-off-by: Philipp Stanner <phasta@kernel.org>
Link: https://lore.kernel.org/r/20250424130254.42046-3-phasta@kernel.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
The commit below reworked how iommu_put_pages_list() worked to not do
list_del() on every entry. This was done expecting all the callers to
already re-init the list so doing a per-item deletion is not
efficient.
It was missed that fq_ring_free_locked() re-uses its list after calling
iommu_put_pages_list() and so the leftover list reaches free'd struct
pages and will crash or WARN/BUG/etc.
Reinit the list to empty in fq_ring_free_locked() after calling
iommu_put_pages_list().
Audit to see if any other callers of iommu_put_pages_list() need the list
to be empty:
- iommu_dma_free_fq_single() and iommu_dma_free_fq_percpu() immediately
frees the memory
- iommu_v1_map_pages(), v1_free_pgtable(), domain_exit(),
riscv_iommu_map_pages() uses a stack variable which goes out of scope
- intel_iommu_tlb_sync() uses a gather in a iotlb_sync() callback, the
caller re-inits the gather
Fixes: 13f43d7cf3e0 ("iommu/pages: Formalize the freelist API")
Reported-by: Borah, Chaitanya Kumar <chaitanya.kumar.borah@intel.com>
Closes: https://lore.kernel.org/r/SJ1PR11MB61292CE72D7BE06B8810021CB997A@SJ1PR11MB6129.namprd11.prod.outlook.com
Tested-by: Borah, Chaitanya Kumar <chaitanya.kumar.borah@intel.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Link: https://lore.kernel.org/r/0-v1-7d4dfa6140f7+11f04-iommu_freelist_init_jgg@nvidia.com
Signed-off-by: Joerg Roedel <jroedel@suse.de>
|
|
Previously, the OSTM driver's platform probe path was only enabled for
selected SoCs (e.g., RZ/G2L and RZ/V2H) due to issues on RZ/Ax (ARM32)
SoCs, which encountered IRQ conflicts like:
/soc/timer@e803b000: used for clock events
genirq: Flags mismatch irq 16. 00215201 (timer@e803c000) vs. 00215201 (timer@e803c000)
Failed to request irq 16 for /soc/timer@e803c000
renesas_ostm e803c000.timer: probe with driver renesas_ostm failed with error -16
These issues have since been resolved by commit 37385c0772a4
("clocksource/drivers/renesas-ostm: Avoid reprobe after successful early
probe"), which prevents reprobe on successfully initialized early timers.
With this fix in place, there is no longer a need to restrict platform
probing based on SoC-specific configs. This change unconditionally enables
reprobe support for all SoCs, simplifying the logic and avoiding the need
to update the configuration for every new Renesas SoC with OSTM.
Additionally, the `ostm_of_table` is now marked with `__maybe_unused` to
fix a build warning when `CONFIG_OF` is disabled.
RZ/A1 and RZ/A2 remain unaffected with this change.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20250515182207.329176-3-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
|
|
Grabbing the work_mutex keeps probe_active_paths() from running at the
same time as multipath_message(). The only messages that could interfere
with probing the paths are "disable_group", "enable_group", and
"switch_group". These messages could force multipath to pick a new
pathgroup while probe_active_paths() was probing the current pathgroup.
If the multipath device has a hardware handler, and it switches active
pathgroups while there is outstanding IO to a path device, it's possible
that IO to the path will fail, even if the path would be usable if it
was in the active pathgroup. To avoid this, do not clear the current
pathgroup for the *_group messages while probe_active_paths() is
running. Instead set a flag, and probe_active_paths() will clear the
current pathgroup when it finishes probing the paths. For this to work
correctly, multipath needs to check current_pg before next_pg in
choose_pgpath(), but before this patch next_pg was only ever set when
current_pg was cleared, so this doesn't change the current behavior when
paths aren't being probed. Even with this change, it is still possible
to switch pathgroups while the probe is running, but only if all the
paths have failed, and the probe function will skip them as well in this
case.
If multiple DM_MPATH_PROBE_PATHS requests are received at once, there is
no point in repeatedly issuing test IOs. Instead, the later probes
should wait for the current probe to complete. If current pathgroup is
still the same as the one that was just checked, the other probes should
skip probing and just check the number of valid paths. Finally, probing
the paths should quit early if the multipath device is trying to
suspend, instead of continuing to issue test IOs, delaying the suspend.
While this patch will not change the behavior of existing multipath
users which don't use the DM_MPATH_PROBE_PATHS ioctl, when that ioctl
is used, the behavior of the "disable_group", "enable_group", and
"switch_group" messages can change subtly. When these messages return,
the next IO to the multipath device will no longer be guaranteed to
choose a new pathgroup. Instead, choosing a new pathgroup could be
delayed by an in-progress DM_MPATH_PROBE_PATHS ioctl. The userspace
multipath tools make no assumptions about what will happen to IOs after
sending these messages, so this change will not effect already released
versions of them, even if the DM_MPATH_PROBE_PATHS ioctl is run
alongside them.
Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
|
|
Check if all domains are awake specially for
LNCF regs
Fixes: 1182bc74b39b ("drm/xe: Fix MOCS debugfs LNCF readout")
Improvements-suggested-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
Reviewed-by: Badal Nilawar <badal.nilawar@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250506142300.1865783-1-tejas.upadhyay@intel.com
Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com>
|
|
Large part of the code uses the FIELD_PREP() macro already to construct
values to be written to hardware registers. Change the code to use also
the macro for more registers of which the corresponding bitmasks are
defined already.
This makes the code more readable. It also syncs the affected
codes with their counterparts in the 'qcom_nandc' driver, so it
makes it easier to spot the differences between the two
implementations.
No functional changes intended.
Signed-off-by: Gabor Juhos <j4g8y7@gmail.com>
Reviewed-by: Md Sadre Alam <quic_mdalam@quicinc.com>
Link: https://patch.msgid.link/20250515-qpic-snand-use-bitmasks-v1-2-11729aeae73b@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Change the code to use the already defined CW_PER_PAGE_MASK
bitmask along with the FIELD_PREP() macro instead of using
magic values.
This makes the code more readable. It also syncs the affected
codes with their counterparts in the 'qcom_nandc' driver, so it
makes it easier to spot the differences between the two
implementations.
No functional changes intended.
Signed-off-by: Gabor Juhos <j4g8y7@gmail.com>
Reviewed-by: Md Sadre Alam <quic_mdalam@quicinc.com>
Link: https://patch.msgid.link/20250515-qpic-snand-use-bitmasks-v1-1-11729aeae73b@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The LMEM provisioning is applicable only on platforms with LMTT.
v2:
- new commit description
- use xe_gt_assert in xe_gt_sriov_pf_config_set_lmem instead return
error,
- disable pf_lmem_info if LMTT is not available
v3: fix condition in xe_gt_assert
v4: rebase
Signed-off-by: Piotr Piórkowski <piotr.piorkowski@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Stuart Summers <stuart.summers@intel.com>
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Link: https://lore.kernel.org/r/20250513071321.700464-1-piotr.piorkowski@intel.com
|
|
Fix various spelling mistake in airoha_thermal_setup_monitor() and
define.
Reported-by: Alok Tiwari <alok.a.tiwari@oracle.com>
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Link: https://lore.kernel.org/r/20250514213919.2321490-1-ansuelsmth@gmail.com
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
|
|
IPQ5018 has tsens IP V1.0, 5 sensors of which 4 are in use and 1
interrupt. The IP does not have a RPM, hence use init routine for
tsens v1.0 without RPM which does not early enable.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Sricharan Ramabadhran <quic_srichara@quicinc.com>
Signed-off-by: George Moussalem <george.moussalem@outlook.com>
Link: https://lore.kernel.org/r/DS7PR19MB8883BD0E36C08DD1D03CE1CB9DCC2@DS7PR19MB8883.namprd19.prod.outlook.com
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
|
|
Adding generic support for SoCs with tsens v1.0 IP with no RPM.
Due to lack of RPM, tsens has to be reset and enabled in the driver
init. SoCs can have support for more sensors than those which will
actually be enabled. As such, init will only enable those explicitly
added to the hw_ids array.
Co-developed-by: Sricharan Ramabadhran <quic_srichara@quicinc.com>
Signed-off-by: Sricharan Ramabadhran <quic_srichara@quicinc.com>
Signed-off-by: George Moussalem <george.moussalem@outlook.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/DS7PR19MB8883C5D7974C7735E23923769DCC2@DS7PR19MB8883.namprd19.prod.outlook.com
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
|
|
TSENS v2.0+ leverage features not available to prior versions such as
updated interrupts init routine, masked interrupts, and watchdog.
Currently, the checks in place evaluate whether the IP version is greater
than v1 which invalidates when updates to v1 or v1 minor versions are
implemented. As such, update the conditional statements to strictly
evaluate whether the version is greater than or equal to v2 (inclusive).
Signed-off-by: George Moussalem <george.moussalem@outlook.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Amit Kucheria <amitk@kernel.org>
Link: https://lore.kernel.org/r/DS7PR19MB8883434CAA053648E22AA8AC9DCC2@DS7PR19MB8883.namprd19.prod.outlook.com
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
|
|
Add support for Airoha EN7581 thermal sensor. This provide support for
reading the CPU or SoC Package sensor and to setup trip points for hot
and critical condition. An interrupt is fired to react on this and
doesn't require passive poll to read the temperature.
The thermal regs provide a way to read the ADC value from an external
register placed in the Chip SCU regs. Monitor will read this value and
fire an interrupt if the trip condition configured is reached.
The Thermal Trip and Interrupt logic is conceptually similar to Mediatek
LVTS Thermal but differ in register mapping and actual function/bug
workaround. The implementation only share some register names but from
functionality observation it's very different and used only for the
basic function of periodically poll the temp and trip the interrupt.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Link: https://lore.kernel.org/r/20250511185003.3754495-2-ansuelsmth@gmail.com
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
|
|
When debugfs is disabled, the function has no reference any more:
drivers/thermal/mediatek/lvts_thermal.c:266:13: error: 'lvts_debugfs_exit' defined but not used [-Werror=unused-function]
266 | static void lvts_debugfs_exit(struct lvts_domain *lvts_td) { }
| ^~~~~~~~~~~~~~~~~
Fixes: ef280c17a840 ("thermal/drivers/mediatek/lvts: Fix debugfs unregister on failure")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20250505052502.1812867-1-arnd@kernel.org
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
|
|
When running the probe function for this driver, the function
lvts_debugfs_init() gets called in lvts_domain_init() which, in
turn, gets called in lvts_probe() before registering threaded
interrupt handlers.
Even though it's unlikely, the last call may fail and, if it does,
there's nothing removing the already created debugfs folder and
files.
In order to fix that, instead of calling the lvts debugfs cleanup
function upon failure, register a devm action that will take care
of calling that upon failure or driver removal.
Since devm was used, also delete the call to lvts_debugfs_exit()
in the lvts_remove() callback, as now that's done automatically.
Fixes: f5f633b18234 ("thermal/drivers/mediatek: Add the Low Voltage Thermal Sensor driver")
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
Link: https://lore.kernel.org/r/20250402083852.20624-1-angelogioacchino.delregno@collabora.com
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
|
|
The variable Uptat uses CamelCase, which violates the kernel's coding
style that mandates snake_case for variable names. This is a purely
cosmetic change with no functional impact.
Compilation tested with:
- checkpatch.pl --strict passed (no new warnings/errors).
Signed-off-by: Enrique Isidoro Vazquez Ramos <kike.correo99.f@gmail.com>
Link: https://lore.kernel.org/r/Z-MEZNMLUmj75uxN@debian.debian
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
|
|
The %pC and %pCn printk format specifiers produce the exact same string. In
preparation for removing %pCn, use %pC.
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Link: https://lore.kernel.org/r/20250311-vsprintf-pcn-v2-1-0af40fc7dee4@bootlin.com
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
|
|
Enabling the compile test should not cause automatic enabling of all
drivers, but only allow to choose to compile them.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Lukasz Luba <lukasz.luba@arm.com>
Link: https://lore.kernel.org/r/20250417074638.81329-1-krzysztof.kozlowski@linaro.org
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
|
|
Introduce a clocksource driver for the so-called high-precision timer (HPT)
in the EcoNet EN751221 and EN751627 MIPS SoCs.
It's a 32 bit upward-counting one-shot timer which relies on the crystal so it
is unaffected by CPU power mode. On MIPS 34K devices (single core) there is
one timer, and on 1004K devices (dual core) there are two.
Each timer has two sets of count/compare registers so that there is one for
each of the VPEs on the core. Because each core has 2 VPEs, register selection
takes the CPU number / 2 for the timer corrisponding to the core, then CPU
number % 2 for the register corrisponding to the VPE.
These timers use a percpu-devid IRQ to route interrupts to the VPE which set
the event.
Signed-off-by: Caleb James DeLisle <cjd@cjdns.fr>
Link: https://lore.kernel.org/r/20250507134500.390547-3-cjd@cjdns.fr
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
|
|
The intention to keep the unsed if(0) block is gone now. Remove
them for clean codes.
Signed-off-by: robelin <robelin@nvidia.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Link: https://lore.kernel.org/r/20250507044311.3751033-4-robelin@nvidia.com
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
|
|
This change removes watchdog self-pinging behavior.
The timer irq handler is triggered due to the 1st expiration,
the handler disables and enables watchdog but also implicitly
clears the expiration count so the count can only be 0 or 1.
Since this watchdog supports opened, configured, or pinged by
systemd, We remove this behavior or the watchdog may not bark
when systemd crashes since the 5th expiration never comes.
Signed-off-by: Pohsun Su <pohsuns@nvidia.com>
Signed-off-by: Robert Lin <robelin@nvidia.com>
Link: https://lore.kernel.org/r/20250507044311.3751033-3-robelin@nvidia.com
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
|
|
This change adds support for WDIOC_GETTIMELEFT so userspace
programs can get the number of seconds before system reset by
the watchdog timer via ioctl.
Signed-off-by: Pohsun Su <pohsuns@nvidia.com>
Signed-off-by: Robert Lin <robelin@nvidia.com>
Link: https://lore.kernel.org/r/20250507044311.3751033-2-robelin@nvidia.com
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
|
|
Build-testing this driver on arm without CONFIG_OF produces a warning:
drivers/clocksource/timer-atmel-tcb.c:368:34: error: 'atmel_tcb_of_match' defined but not used [-Werror=unused-const-variable=]
368 | static const struct of_device_id atmel_tcb_of_match[] = {
| ^~~~~~~~~~~~~~~~~~
Change the dependency to require CONFIG_OF for build testing to
avoid the warning. Testing remains possible on all architectures
as CONFIG_OF is user-selectable.
Cc: Nicolas Ferre <nicolas.ferre@microchip.com>
Cc: Claudiu Beznea <claudiu.beznea@tuxon.dev>
Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20250409155313.1096915-1-arnd@kernel.org
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
|
|
platforms
STM supports commonly required system and application software timing
functions. STM includes a 32-bit count-up timer and four 32-bit
compare channels with a separate interrupt source for each
channel. The timer is driven by the STM module clock divided by an
8-bit prescale value (1 to 256).
STM has the following features:
• One 32-bit count-up timer with an 8-bit prescaler
• Four 32-bit compare channels
• An independent interrupt source for each channel
• Ability to stop the timer in Debug mode
The s32g platform is declined into two versions, the s32g2 and the
s32g3. The former has a STM block with 8 timers and the latter has 12
timers.
The platform is designed to have one usable STM instance per core on
the system which is composed of 3 x Cortex-M3 + 4 Cortex-A53 for the
s32g2 and 3 x Cortex-M3 + 8 Cortex-A53 for the s32g3.
There is a special STM instance called STM_TS which is dedicated to
the timestamp. The 7th STM instance STM_07 is directly tied to the
STM_TS which means it is not usable as a clockevent.
The driver instantiate each STM described in the device tree as a
clocksource and a clockevent conforming to the reference manual even
if the Linux system does not use all of the clocksource. Each
clockevent will have a cpumask set for a specific CPU.
Given the counter is shared between the clocksource and the
clockevent, the STM module can not be disabled by one or another so
the refcounting mechanism is used to stop the counter when it reaches
zero and to start it when it is one. The suspend and resume relies on
the refcount to stop the module.
As the device tree will have multiple STM entries, the driver can be
probed in parallel with the async option but it is not enabled
yet. However, the driver code takes care of preventing a race by
putting a lock to protect the number of STM instances global variable
which means it is ready to support the option when enough testing will
be done with the underlying time framework.
Cc: Ghennadi Procopciuc <ghennadi.procopciuc@oss.nxp.com>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Cc: Thomas Fossati <thomas.fossati@linaro.org>
Suggested-by: Ghennadi Procopciuc <ghennadi.procopciuc@nxp.com>
Link: https://lore.kernel.org/r/20250417151623.121109-3-daniel.lezcano@linaro.org
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
|
|
Ping-Ke Shih says:
==================
rtw-next patches for v6.16
Some fixes and refinements across drivers, and regular development of
MLO and STA + P2P concurrency. Major changes are listed below.
rtw88:
* improve throughput for RTL8814AU
rtw89:
* support MLO
* improve user experience for STA + P2P concurrency
* dynamic antenna gain (DAG) with different power by antenna
* load SAR tables from ACPI
==================
Link: https://patch.msgid.link/17e74675-70cc-43d7-a797-afb937030d34@RTEXMBS04.realtek.com.tw/
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Instead of hardcoding the event handler indices (for runtime
event handler enable/disable) we can simply look for the handler
with the appropriate event type. This isolates us from the firmware
details a bit better.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250512103358.15724-8-ville.syrjala@linux.intel.com
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
|
|
Extract the helper to determine if the mmio reg+data are the
event handler register (DMC_EVT_CTL) for a specific event.
We'll have another use for this for runtime event handler
enable/disable.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250512103358.15724-7-ville.syrjala@linux.intel.com
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
|
|
Move is_dmc_evt_ctl_reg() to a slightly earlier position in the file
so that we can reuse it in the pkgc workaround code. Also move
is_dmc_evt_htp_reg() just to keep the two together.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250512103358.15724-6-ville.syrjala@linux.intel.com
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
|
|
We have two copies of the code to generate the "disable this event"
value for the DMC_EVT_CTL registers. Extract to a helper.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250512103358.15724-5-ville.syrjala@linux.intel.com
Reviewed-by: Luca Coelho <luciano.coeho@intel.com>
|
|
Define all the DMC event IDs to make life less misrable when
having to deal with these.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250512103358.15724-4-ville.syrjala@linux.intel.com
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
|
|
Hook up PIPEDMC interrupts. We'll need these for:
- flip queue signalling
- GTT/ATS faults on LNL+
- unclaimed register access errors (supposedly that is what
the error interrupt indicated according to Windows code).
On LNL+ we get a new level of interrupts registers PIPEDMC_INTERRUPT*.
On earlier platforms we only have the INT_VECTOR field in the
PIPEDMC_STATUS registers, whose values are defined by the firmware.
For now we'll enable the interrupts on LNL+ only. For earlier platforms
it's not clear that there is any use for these interrupts, and some
ADL machines have exhibited spurious DE_PIPE interrupts with the
PIPEDMC interrupts unmasked/enabled. We can revisit enabling these
for earlier platforms in the future.
For some unknown reason LNL pipe B triggers the error interrupt
during the first DC state transition (subsequent transitions are
maybe OK?). No clear idea what's going on here yet, so keep the
error interrupt disabled for now.
Similar to DSB interrupt registers, the unused bits in
PIPEDMC_INTERRUPT* seem to act like randomg r/w bits (instead
of being hardwired to 0 like one would expect), and so we'll try
to avoid setting them so that we don't mistake them for real
interrupts.
v2: Only enable/unmask for LNL+
Keep the flip queue interrupt masked off for now since
we don't have a use for it yet
v3: Also keep the error interrupt masked off for now due to
LNL pipe B triggering it
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250514174257.8708-1-ville.syrjala@linux.intel.com
|
|
On LNL+ PIPEDMC faults are reported via PIPEDMC interrupts
instead of the direct DE_PIPE_* reporting used on earlier
platforms. Drop the relevant bits from the fault mask.
The bits are tied to zero on LNL, so there is no danger of
spurious fault interrupts even with an incorrect mask.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250512103358.15724-2-ville.syrjala@linux.intel.com
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
|
|
As the first step towards making struct intel_display an opaque pointer
in i915 and xe drivers, convert the struct drm_i915_private and struct
xe_device display members into pointers.
Initially, add temporary struct intel_display __display members, and
point display at it to avoid dynamic allocation. In the future, we can
drop this, and switch to dynamic allocation.
The conversion is done simply with sed:
sed -i 's/&\([a-zA-Z0-9_>.-]*\)\(dev_priv\|i915\|xe\)->display\([^.]\)/\1\2->display\3/g' \
$(git ls-files -- drivers/gpu/drm/i915 drivers/gpu/drm/xe)
sed -i 's/\(dev_priv\|i915\|xe\)->display\./\1->display->/g' \
$(git ls-files -- drivers/gpu/drm/i915 drivers/gpu/drm/xe)
With a couple of manual tweaks on top.
v2: Initialize i915->display also in selftest mock_gem_device()
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://lore.kernel.org/r/20250507152254.2398934-1-jani.nikula@intel.com
|
|
Always use a local variable for display instead of referencing
i915->display inline. This makes it easier to convert i915->display into
a pointer.
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://lore.kernel.org/r/afcf305e8c4ea452cee37479530958f36a10c840.1746610601.git.jani.nikula@intel.com
|
|
Always use a local variable for display instead of referencing
xe->display inline. This makes it easier to convert xe->display into a
pointer.
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://lore.kernel.org/r/c99483ad86022d02f780bac73445baaf27a6edce.1746610601.git.jani.nikula@intel.com
|
|
Drop the dependency on display being a sub-struct of xe_device.
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://lore.kernel.org/r/3528f2cd5965e97248c161b8aa25a9df69606a39.1746610601.git.jani.nikula@intel.com
|
|
Backmerge to sync with v6.15-rc, xe, and specifically async flip changes
in drm-misc.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
According to "Function return values and names" in coding-style.rst, the
dmar_ats_supported() function should return a boolean instead of an
integer. Also, rename "ret" to "supported" to be more straightforward.
Signed-off-by: Wei Wang <wei.w.wang@intel.com>
Reviewed-by: Yi Liu <yi.l.liu@intel.com>
Link: https://lore.kernel.org/r/20250509140021.4029303-3-wei.w.wang@intel.com
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
|
|
The function dmar_find_matched_satc_unit() contains a duplicate call to
pci_physfn(). This call is unnecessary as pci_physfn() has already been
invoked by the caller. Removing the redundant call simplifies the code
and improves efficiency a bit.
Signed-off-by: Wei Wang <wei.w.wang@intel.com>
Link: https://lore.kernel.org/r/20250509140021.4029303-2-wei.w.wang@intel.com
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
|
|
The domain ID allocator is currently protected by a spin_lock. However,
ida_alloc_range can potentially block if it needs to allocate memory to
grow its internal structures.
Replace the spin_lock with a mutex which allows sleep on block. Thus,
the memory allocation flags can be updated from GFP_ATOMIC to GFP_KERNEL
to allow blocking memory allocations if necessary.
Introduce a new mutex, did_lock, specifically for protecting the domain
ida. The existing spinlock will remain for protecting other intel_iommu
fields.
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Link: https://lore.kernel.org/r/20250430021135.2370244-3-baolu.lu@linux.intel.com
Signed-off-by: Joerg Roedel <jroedel@suse.de>
|
|
Switch the intel iommu driver to use the ida mechanism for managing domain
IDs, replacing the previous fixed-size bitmap.
The previous approach allocated a bitmap large enough to cover the maximum
number of domain IDs supported by the hardware, regardless of the actual
number of domains in use. This led to unnecessary memory consumption,
especially on systems supporting a large number of iommu units but only
utilizing a small number of domain IDs.
The ida allocator dynamically manages the allocation and freeing of integer
IDs, only consuming memory for the IDs that are currently in use. This
significantly optimizes memory usage compared to the fixed-size bitmap.
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Link: https://lore.kernel.org/r/20250430021135.2370244-2-baolu.lu@linux.intel.com
Signed-off-by: Joerg Roedel <jroedel@suse.de>
|
|
VT-D HW can do WO permissions on the second-stage but not the first-stage
page table formats. The commit eea53c581688 ("iommu/vt-d: Remove WO
permissions on second-level paging entries") wanted to make this uniform
for VT-D by disabling the support for WO permissions in the second-stage.
This isn't consistent with how other drivers are working. Instead if the
underlying HW can support WO, it should. For instance AMD already supports
WO on its second stage (v1) format and not its first (v2).
If WO support needs to be discoverable it should be done through an
iommu_domain capability flag.
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Link: https://lore.kernel.org/r/0-v1-c26553717e90+65f-iommu_vtd_ss_wo_jgg@nvidia.com
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
|
|
A BIOS upgrade has changed the IVRS DTE UID for a device that no
longer matches the UID in the SSDT. In this case there is only
one ACPI device on the system with that _HID but the _UID mismatch.
IVRS:
```
Subtable Type : F0 [Device Entry: ACPI HID Named Device]
Device ID : 0060
Data Setting (decoded below) : 40
INITPass : 0
EIntPass : 0
NMIPass : 0
Reserved : 0
System MGMT : 0
LINT0 Pass : 1
LINT1 Pass : 0
ACPI HID : "MSFT0201"
ACPI CID : 0000000000000000
UID Format : 02
UID Length : 09
UID : "\_SB.MHSP"
```
SSDT:
```
Device (MHSP)
{
Name (_ADR, Zero) // _ADR: Address
Name (_HID, "MSFT0201") // _HID: Hardware ID
Name (_UID, One) // _UID: Unique ID
```
To handle this case; while enumerating ACPI devices in
get_acpihid_device_id() count the number of matching ACPI devices with
a matching _HID. If there is exactly one _HID match then accept it even
if the UID doesn't match. Other operating systems allow this, but the
current IVRS spec leaves some ambiguity whether to allow or disallow it.
This should be clarified in future revisions of the spec. Output
'Firmware Bug' for this case to encourage it to be solved in the BIOS.
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Reviewed-by: Vasant Hegde <vasant.hegde@amd.com>
Link: https://lore.kernel.org/r/20250512173129.1274275-1-superm1@kernel.org
Signed-off-by: Joerg Roedel <jroedel@suse.de>
|
|
Nothing in there is active if CONFIG_ARM_SMMU_V3 is not enabled, so the whole
directory can depend on that switch as well.
Fixes: e86d1aa8b60f ("iommu/arm-smmu: Move Arm SMMU drivers into their own subdirectory")
Signed-off-by: Rolf Eike Beer <eb@emlix.com>
Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
Link: https://lore.kernel.org/r/2434059.NG923GbCHz@devpool92.emlix.com
Signed-off-by: Joerg Roedel <jroedel@suse.de>
|
