| Age | Commit message (Collapse) | Author |
|---|
|
This starts refactoring how virtchnl messages are handled by adding a
transaction manager (idpf_vc_xn_manager).
There are two primary motivations here which are to enable handling of
multiple messages at once and to make it more robust in general. As it
is right now, the driver may only have one pending message at a time and
there's no guarantee that the response we receive was actually intended
for the message we sent prior.
This works by utilizing a "cookie" field of the message descriptor. It
is arbitrary what data we put in the cookie and the response is required
to have the same cookie the original message was sent with. Then using a
"transaction" abstraction that uses the completion API to pair responses
to the message it belongs to.
The cookie works such that the first half is the index to the
transaction in our array, and the second half is a "salt" that gets
incremented every message. This enables quick lookups into the array and
also ensuring we have the correct message. The salt is necessary because
after, for example, a message times out and we deem the response was
lost for some reason, we could theoretically reuse the same index but
using a different salt ensures that when we do actually get a response
it's not the old message that timed out previously finally coming in.
Since the number of transactions allocated is U8_MAX and the salt is 8
bits, we can never have a conflict because we can't roll over the salt
without using more transactions than we have available.
This starts by only converting the VIRTCHNL2_OP_VERSION message to use
this new transaction API. Follow up patches will convert all virtchnl
messages to use the API.
Tested-by: Alexander Lobakin <aleksander.lobakin@intel.com>
Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Reviewed-by: Igor Bagnucki <igor.bagnucki@intel.com>
Co-developed-by: Joshua Hay <joshua.a.hay@intel.com>
Signed-off-by: Joshua Hay <joshua.a.hay@intel.com>
Signed-off-by: Alan Brady <alan.brady@intel.com>
Tested-by: Krishneil Singh <krishneil.k.singh@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
|
|
idpf.h is quite heavy. We can reduce the burden a fair bit by
introducing an idpf_virtchnl.h file. This mostly just moves function
declarations but there are many of them. This also makes an attempt to
group those declarations in a way that makes some sense instead of
mishmashed.
Suggested-by: Alexander Lobakin <aleksander.lobakin@intel.com>
Signed-off-by: Alan Brady <alan.brady@intel.com>
Tested-by: Krishneil Singh <krishneil.k.singh@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
|
|
The early SME/SEV code parses the command line very early, in order to
decide whether or not memory encryption should be enabled, which needs
to occur even before the initial page tables are created.
This is problematic for a number of reasons:
- this early code runs from the 1:1 mapping provided by the decompressor
or firmware, which uses a different translation than the one assumed by
the linker, and so the code needs to be built in a special way;
- parsing external input while the entire kernel image is still mapped
writable is a bad idea in general, and really does not belong in
security minded code;
- the current code ignores the built-in command line entirely (although
this appears to be the case for the entire decompressor)
Given that the decompressor/EFI stub is an intrinsic part of the x86
bootable kernel image, move the command line parsing there and out of
the core kernel. This removes the need to build lib/cmdline.o in a
special way, or to use RIP-relative LEA instructions in inline asm
blocks.
This involves a new xloadflag in the setup header to indicate
that mem_encrypt=on appeared on the kernel command line.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Tested-by: Tom Lendacky <thomas.lendacky@amd.com>
Link: https://lore.kernel.org/r/20240227151907.387873-17-ardb+git@google.com
|
|
Parse the mem_encrypt= command line parameter from the EFI stub if
CONFIG_ARCH_HAS_MEM_ENCRYPT=y, so that it can be passed to the early
boot code by the arch code in the stub.
This avoids the need for the core kernel to do any string parsing very
early in the boot.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Tested-by: Tom Lendacky <thomas.lendacky@amd.com>
Link: https://lore.kernel.org/r/20240227151907.387873-16-ardb+git@google.com
|
|
The current measured frame rate is 59.95Hz, which does not meet the
requirements of touch-stylus and stylus cannot work normally. After
adjustment, the actual measurement is 60.001Hz. Now this panel looks
like it's only used by me on the MTK platform, so let's change this
set of parameters.
[ dianders: Added "(again") to subject and fixed the "Fixes" line ]
Fixes: cea7008190ad ("drm/panel: boe-tv101wum-nl6: Fine tune Himax83102-j02 panel HFP and HBP")
Signed-off-by: Cong Yang <yangcong5@huaqin.corp-partner.google.com>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240301061128.3145982-1-yangcong5@huaqin.corp-partner.google.com
|
|
Reset controller updates for v6.9
Enable support for the Sophgo SG2042 reset controller via reset-simple,
add a GPIO-based reset controller criver for shared GPIO resets, extract
an of_phandle_args_equal() helper function out of cpufreq, and use it in
reset-gpio.
Based on v6.8-rc5 because reset-gpio depends on commits in the
gpio-driver-h-stubs-for-v6.8-rc5 tag.
* tag 'reset-for-v6.9' of git://git.pengutronix.de/pza/linux:
reset: Instantiate reset GPIO controller for shared reset-gpios
reset: gpio: Add GPIO-based reset controller
cpufreq: do not open-code of_phandle_args_equal()
of: Add of_phandle_args_equal() helper
reset: simple: add support for Sophgo SG2042
dt-bindings: reset: sophgo: support SG2042
Link: https://lore.kernel.org/r/20240301111300.4038207-1-p.zabel@pengutronix.de
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into soc/late
Update TI clksel clocks to use reg
Updates for TI clksel clocks to use the standard reg property instead of
the non-standard ti,bit-shift legacy property.
There are still lots of TI composite clock related devicetree warnings for
missing bindings, and overlapping reg properties. We have grouped some of
the TI composite clocks under the clksel clock node, but did not consider
the reg property issue. Let's update the existing users before we continue
grouping more of the composite clocks.
* tag 'omap-for-v6.9/dt-warnings-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
ARM: dts: omap3: Update clksel clocks to use reg instead of ti,bit-shift
ARM: dts: am3: Update clksel clocks to use reg instead of ti,bit-shift
clk: ti: Improve clksel clock bit parsing for reg property
clk: ti: Handle possible address in the node name
Link: https://lore.kernel.org/r/pull-1709102378-94138@atomide.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
Of course we should use the key if there is no error ...
Signed-off-by: Hannes Reinecke <hare@suse.de>
Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com>
Signed-off-by: Keith Busch <kbusch@kernel.org>
|
|
Since commit d492cc2573a0 ("driver core: device.h: make struct
bus_type a const *"), the driver core can properly handle constant
struct bus_type, move the tee_bus_type variable to be a constant
structure as well, placing it into read-only memory which can not be
modified at runtime.
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ricardo B. Marliere <ricardo@marliere.net>
Reviewed-by: Sumit Garg <sumit.garg@linaro.org>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
Switch to the queue_limits_* helpers to stack the bdev limits, which also
includes updating the readahead settings.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Keith Busch <kbusch@kernel.org>
|
|
The multipath disk starts out with the stacking default limits.
The one interesting part here is that blk_set_stacking_limits
sets the max_zone_append_sectorts to UINT_MAX, which fails the
validation for non-zoned devices. With the old one call per
limit scheme this was fine because no one verified this weird
mismatch and it was fixed by blk_stack_limits a little later
before I/O could be issued.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Keith Busch <kbusch@kernel.org>
|
|
Changes the callchains that update queue_limits to build an on-stack
queue_limits and update it atomically. Note that for now only the
admin queue actually passes it to the queue allocation function.
Doing the same for the gendisks used for the namespaces will require
a little more work.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Keith Busch <kbusch@kernel.org>
|
|
Fold nvme_init_ms into nvme_configure_metadata after splitting up
a little helper to deal with the extended LBA formats.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Keith Busch <kbusch@kernel.org>
|
|
Move reading the Identify Namespace Data Structure, NVM Command Set out
of configure_metadata into the caller. This allows doing the identify
call outside the frozen I/O queues, and prepares for using data from
the Identify data structure for other purposes.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Keith Busch <kbusch@kernel.org>
|
|
Split the logic to query the Identify Namespace Data Structure, NVM
Command Set into a separate helper.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Max Gurtovoy <mgurtovoy@nvidia.com>
Signed-off-by: Keith Busch <kbusch@kernel.org>
|
|
nvme_update_ns_info_generic and nvme_update_ns_info_block share a
fair amount of logic related to not fully supported namespace
formats and updating the multipath information. Move this logic
into the common caller.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Keith Busch <kbusch@kernel.org>
|
|
nvme_set_queue_limits is used on the admin queue and all gendisks
including hidden ones that don't support block I/O. The write cache
setting on the other hand only makes sense for block I/O. Move the
blk_queue_write_cache call to nvme_update_ns_info_block instead.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Max Gurtovoy <mgurtovoy@nvidia.com>
Signed-off-by: Keith Busch <kbusch@kernel.org>
|
|
Move setting up the integrity profile and setting the disk capacity out
of nvme_update_disk_info to get nvme_update_disk_info into a shape where
it just sets queue_limits eventually.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Keith Busch <kbusch@kernel.org>
|
|
Currently nvme_update_ns_info_block calls nvme_update_disk_info both for
the namespace attached disk, and the multipath one (if it exists). This
is very different from how other stacking drivers work, and leads to
a lot of complexity.
Switch to setting the disk capacity and initializing the integrity
profile, and let blk_stack_limits which already is called just below
deal with updating the other limits.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Keith Busch <kbusch@kernel.org>
|
|
Move uneregistering the existing integrity profile into the helper
dealing with all the other integrity / metadata setup.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Max Gurtovoy <mgurtovoy@nvidia.com>
Signed-off-by: Keith Busch <kbusch@kernel.org>
|
|
Handle the no metadata support case in nvme_init_integrity as well to
simplify the calling convention and prepare for future changes in the
area.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Max Gurtovoy <mgurtovoy@nvidia.com>
Signed-off-by: Keith Busch <kbusch@kernel.org>
|
|
max_integrity_segments is just a hardware limit and doesn't need to be
in nvme_init_integrity with the PI setup.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Max Gurtovoy <mgurtovoy@nvidia.com>
Signed-off-by: Keith Busch <kbusch@kernel.org>
|
|
Handle setting the zone size / chunk_sectors and max_append_sectors
limits together with the other ZNS limits, and just open code the
call to blk_revalidate_zones in the current place.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
Signed-off-by: Keith Busch <kbusch@kernel.org>
|
|
Move the handling of the NVME_QUIRK_DEALLOCATE_ZEROES quirk out of
nvme_config_discard so that it is combined with the normal write_zeroes
limit handling.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Max Gurtovoy <mgurtovoy@nvidia.com>
Signed-off-by: Keith Busch <kbusch@kernel.org>
|
|
All transports set a max_hw_sectors value in the nvme_ctrl, so make
the code using it unconditional and clean it up using a little helper.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Max Gurtovoy <mgurtovoy@nvidia.com>
Reviewed-by: John Garry <john.g.garry@oracle.com>
Signed-off-by: Keith Busch <kbusch@kernel.org>
|
|
The SLAB_MEM_SPREAD flag used to be implemented in SLAB, which was
removed as of v6.8-rc1, so it became a dead flag since the commit
16a1d968358a ("mm/slab: remove mm/slab.c and slab_def.h"). And the
series[1] went on to mark it obsolete explicitly to avoid confusion
for users. Here we can just remove all its users, which has no any
functional change.
[1] https://lore.kernel.org/all/20240223-slab-cleanup-flags-v2-1-02f1753e8303@suse.cz/
Signed-off-by: Chengming Zhou <zhouchengming@bytedance.com>
Reviewed-by: Vishal Verma <vishal.l.verma@intel.com>
Link: https://lore.kernel.org/r/20240224134728.829289-1-chengming.zhou@linux.dev
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-mem-ctrl into soc/drivers
Memory controller drivers for v6.9, part two
1. Renesas RPC-IF: add bindings for R-Car V4M.
2. Tegra MC: correct and extend support for Tegra234 memory controller.
3. STM32: add support for Flexible Memory Controller on MP25 SoC.
4. NXP WEIM bindings: convert to DT schema.
* tag 'memory-controller-drv-6.9-2' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-mem-ctrl:
memory: stm32-fmc2-ebi: keep power domain on
memory: stm32-fmc2-ebi: add MP25 RIF support
memory: stm32-fmc2-ebi: add MP25 support
memory: stm32-fmc2-ebi: check regmap_read return value
dt-bindings: memory-controller: st,stm32: add MP25 support
dt-bindings: bus: imx-weim: convert to YAML
memory: tegra: Fix indentation
memory: tegra: Add BPMP and ICC info for DLA clients
memory: tegra: Correct DLA client names
dt-bindings: memory: renesas,rpc-if: Document R-Car V4M support
Link: https://lore.kernel.org/r/20240229124600.405016-1-krzysztof.kozlowski@linaro.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into soc/drivers
Driver change for ti-sysc
Just one change to constify struct device_type.
* tag 'omap-for-v6.9/ti-sysc-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
bus: ti-sysc: constify the struct device_type usage
Link: https://lore.kernel.org/r/pull-1709194472-263643@atomide.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux into soc/drivers
Samsung SoC driver changes for v6.9, part two
1. Extend Exynos PMU (Power Management Unit) driver being also the
syscon to main system controller registers block, to support Google
GS101. The Google GS101 has PMU registers protected and writing is
available only via SMC. The Exynos PMU will register its own custom
regmap for such case of mixed MMIO+SMC.
2. Rework Samsung watchdog driver to get the regmap to PMU block not
via syscon API, but from the Exynos PMU driver. This is necessary
for the watchdog driver to work on Google GS101.
* tag 'samsung-drivers-6.9-2' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux:
watchdog: s3c2410_wdt: use exynos_get_pmu_regmap_by_phandle() for PMU regs
soc: samsung: exynos-pmu: Add regmap support for SoCs that protect PMU regs
MAINTAINERS: samsung: gs101: match patches touching Google Tensor SoC
Link: https://lore.kernel.org/r/20240227080755.34170-1-krzysztof.kozlowski@linaro.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into soc/drivers
Qualcomm driver updates for v6.9
This introduces the Qualcomm Programmable Boot Sequencer (PBS) driver.
The Qualcomm SMEM no longer acquires the hwspinlock during the "get"
operation, to improve the system behavior during the recovery of a
remoteproc that crashed with the hwspinlock held.
The Qualcomm Always On Subsystem (AOSS) message protocol driver gains
tracepoints, printf annotation, and a debugfs interface is introduced
for tweaking system properties during development and debugging.
The Qualcomm socinfo driver gains data for SM8475, QCM8550 and
QCS8550 platforms, and the PM2250 is renamed to PM4125.
Support for controlling the voltage regulator in SPM/SAW2 is introduced.
The gfx.lvl power-domain is dropped for SA8540P, as this resource was
incorrectly inherited from SC8280XP.
Additionally some code cleanup improvements is introduced across APR,
LLCC, SMP2P and SPM.
* tag 'qcom-drivers-for-6.9' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux: (23 commits)
dt-bindings: soc: qcom: qcom,saw2: add msm8226 l2 compatible
soc: qcom: spm: add support for voltage regulator
soc: qcom: spm: remove driver-internal structures from the driver API
dt-bindings: soc: qcom: qcom,saw2: define optional regulator node
dt-bindings: soc: qcom: qcom,saw2: add missing compatible strings
dt-bindings: soc: qcom: merge qcom,saw2.txt into qcom,spm.yaml
soc: qcom: llcc: Check return value on Broadcast_OR reg read
soc: qcom: socinfo: Add Soc IDs for SM8475 family
dt-bindings: arm: qcom,ids: Add IDs for SM8475 family
soc: qcom: apr: make aprbus const
dt-bindings: soc: qcom: qcom,pmic-glink: document X1E80100 compatible
soc: qcom: add QCOM PBS driver
dt-bindings: soc: qcom: Add qcom,pbs bindings
pmdomain: qcom: rpmhpd: Drop SA8540P gfx.lvl
soc: qcom: socinfo: rename PM2250 to PM4125
soc: qcom: aoss: Add tracepoints in qmp_send()
soc: qcom: socinfo: add SoC Info support for QCM8550 and QCS8550 platform
dt-bindings: arm: qcom,ids: add SoC ID for QCM8550 and QCS8550
soc: qcom: aoss: Add debugfs interface for sending messages
soc: qcom: smem: remove hwspinlock from item get routine
...
Link: https://lore.kernel.org/r/20240225030612.480241-1-andersson@kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux into soc/drivers
- make sunxi_rsb_bus constant
* tag 'sunxi-drivers-for-6.9-1' of https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux:
bus: sunxi-rsb: make sunxi_rsb_bus const
Link: https://lore.kernel.org/r/20240223205734.GA9027@jernej-laptop
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into soc/drivers
firmware: tegra: Changes for v6.9-rc1
Contains a fix that makes sure we don't unnecessarily call kfree().
* tag 'tegra-for-6.9-firmware' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux:
firmware: tegra: bpmp: Return directly after a failed kzalloc() in get_filename()
Link: https://lore.kernel.org/r/20240223174849.1509465-2-thierry.reding@gmail.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into soc/drivers
soc/tegra: Changes for v6.9-rc1
This set of changes adds ACPI support for the APBMISC driver and cleans
up a few things like dependencies and unused code.
* tag 'tegra-for-6.9-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux:
soc/tegra: pmc: Add SD wake event for Tegra234
soc/tegra: pmc: Update scratch as an optional aperture
soc/tegra: pmc: Update address mapping sequence for PMC apertures
bus: tegra-aconnect: Update dependency to ARCH_TEGRA
soc/tegra: Fix build failure on Tegra241
soc/tegra: fuse: Fix crash in tegra_fuse_readl()
soc/tegra: fuse: Define tegra194_soc_attr_group for Tegra241
soc/tegra: fuse: Add support for Tegra241
soc/tegra: fuse: Add ACPI support for Tegra194 and Tegra234
soc/tegra: fuse: Add function to print SKU info
soc/tegra: fuse: Add function to add lookups
soc/tegra: fuse: Add tegra_acpi_init_apbmisc()
soc/tegra: fuse: Refactor resource mapping
soc/tegra: fuse: Use dev_err_probe for probe failures
mm/util: Introduce kmemdup_array()
soc/tegra: pmc: Remove some old and deprecated functions and constants
Link: https://lore.kernel.org/r/20240223174849.1509465-1-thierry.reding@gmail.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
The linear ranges aren't really matching what they should be. Indeed,
the range is inclusive of the min value, so it makes sense the previous
range does NOT include the max step value representing the min value of
the range in question.
Since 3.4V is represented by the decimal value 232, the previous range
max step value should be 231 and not 232.
No expected change in behavior since 3.4V was mapped with step 232 from
the first range but is now mapped with step 232 from the second range.
While at it, remove the incorrect comment from the second range.
Fixes: f991a220a447 ("regulator: rk808: add rk806 support")
Cc: Quentin Schulz <foss+kernel@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Link: https://msgid.link/r/20240223-rk806-regulator-ranges-v1-2-3904ab70d250@theobroma-systems.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The linear ranges aren't really matching what they should be. Indeed,
the range is inclusive of the min value, so it makes sense the previous
range does NOT include the max step value representing the min value of
the range in question.
Since 1.5V is represented by the decimal value 160, the previous range
max step value should be 159 and not 160. Similarly, 3.4V is represented
by the decimal value 236, so the previous range max value should be 235
and not 237.
The only change in behavior this makes is that this actually modeled
the ranges to map step with decimal value 237 with 3.65V instead of
3.4V (the max supported by the HW).
Fixes: f991a220a447 ("regulator: rk808: add rk806 support")
Cc: Quentin Schulz <foss+kernel@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Link: https://msgid.link/r/20240223-rk806-regulator-ranges-v1-1-3904ab70d250@theobroma-systems.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into soc/drivers
Arm SCMI updates for v6.9
Quite a few changes to extend support to SCMI v3.2 specification,
to enhance notification handling and other miscellaneous updates.
1. Enhancements to notification handling
Until now, trying to register a notifier for an unsuppported
notification returned an error genrating unneeded message exchanges
with the SCMI platform. This can be avoided by looking up in advance
the specific protocol and resources available.
With these changes SCMI driver user will fail to register a notifier
if the related command or resource is not supported (like before)
without the need of exchanging any message.
Perf notifications are also extended to provide the pre-calculated
frequencies corresponding to the level or index carried by the
2. More SCMI v3.2 related updates
One of the main addition includes a centralized support to the SCMI
core to handle v3.2 optional protocol version negotiation, so that
at protocol initialization time, if the platform advertised version
is newer than supported by the kernel and protocol version negotiation
is supported, the SCMI core will attempt to negotiate an older protocol
version.
It also includes the clock get permissions which indicates if any of
the clock operations are forbidden by the platform for the OSPM agent.
It can be used in the clock driver to avoid unnecessary message
exchanges between the kernel and the platform which will always end
up with the failure. It also includes other missing bits of clock
v3.2 protocol so that the supported protocol version can be bumped
to 0x30000 (v3.2).
3. Miscellaneous updates
This includes addition of warning if the domain frequency multiplier
is 0 or rounded off to indicate the actual frequencies are either
wrong ot rounded off, hardening of clock domain info lookups, addition
of multiple protocols registration support within a SCMI driver,
update to SCMI entry in MAINTAINERS to include HWMON driver and
constifying the scmi_bus_type structure.
This also includes couple for fixes to minor issues: double free in
SMC transport cleanup path and struct kernel-doc warnings in optee
transport.
* tag 'scmi-updates-6.9' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux: (29 commits)
MAINTAINERS: Update SCMI entry with HWMON driver
firmware: arm_scmi: Update the supported clock protocol version
firmware: arm_scmi: Add standard clock OEM definitions
firmware: arm_scmi: Add clock check for extended config support
firmware: arm_scmi: Add support for v3.2 NEGOTIATE_PROTOCOL_VERSION
firmware: arm_scmi: Fix struct kernel-doc warnings in optee transport
firmware: arm_scmi: Report frequencies in the perf notifications
firmware: arm_scmi: Use opps_by_lvl to store opps
firmware: arm_scmi: Implement is_notify_supported callback in powercap protocol
firmware: arm_scmi: Implement is_notify_supported callback in reset protocol
firmware: arm_scmi: Implement is_notify_supported callback in sensor protocol
firmware: arm_scmi: Implement is_notify_supported callback in clock protocol
firmware: arm_scmi: Implement is_notify_supported callback in system power protocol
firmware: arm_scmi: Implement is_notify_supported callback in power protocol
firmware: arm_scmi: Implement is_notify_supported callback in perf protocol
firmware: arm_scmi: Add a common helper to check if a message is supported
firmware: arm_scmi: Check for notification support
firmware: arm_scmi: Make scmi_bus_type const
firmware: arm_scmi: Fix double free in SMC transport cleanup path
firmware: arm_scmi: Implement clock get permissions
...
Link: https://lore.kernel.org/r/20240223033435.118028-1-sudeep.holla@arm.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into soc/drivers
Arm FF-A update for v6.9
Another single and simple update to just constify the ffa_bus_type
structure similar to other changes done treewide following the driver
core changes to accomodate the same.
* tag 'ffa-update-6.9' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux:
firmware: arm_ffa: Make ffa_bus_type const
Link: https://lore.kernel.org/r/20240223033250.117878-1-sudeep.holla@arm.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
Since 'grouped target' is used only in 'make' 4.3, it should
be avoided. Replace it with 'multi-target pattern rule' which
has the same behavior.
Fixes: 9616e74b796c ("drm/xe: Add support for OOB workarounds")
Signed-off-by: Dafna Hirschfeld <dhirschfeld@habana.ai>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240302153927.2602241-1-dhirschfeld@habana.ai
[ reword commit message ]
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
(cherry picked from commit 5224ed586ba7f9bba956655a1bfe5b75df7394d4)
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
|
|
If a page fault occurs on VM not in fault a ref can be leaked. Fix this.
Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs")
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240301041036.238471-1-matthew.brost@intel.com
(cherry picked from commit 27b5a3f237fe66dbf2288c2b50973aee8a427e41)
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
|
|
When sync binds were reworked and worker removed, async_ops became
obsolete. Remove it.
Fixes: f3e9b1f43458 ("drm/xe: Remove async worker and rework sync binds")
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Francois Dugast <francois.dugast@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240117110908.2362615-1-mika.kuoppala@linux.intel.com
(cherry picked from commit e5f276dc1e4c6475d322bc4672c33ab74b068f3b)
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
|
|
init_steering_dss need topology dss mask to be init ahead.
Fixed by moving xe_gt_topology_init ahead of xe_gt_mcr_init
Fixes: bf8ec3c3e82c ("drm/xe: Initialize GuC earlier during probe")
Cc: Michał Winiarski <michal.winiarski@intel.com>
Signed-off-by: Zhanjun Dong <zhanjun.dong@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240227164922.281346-2-zhanjun.dong@intel.com
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
(cherry picked from commit 4c47049d93b7a7fc2230cded84a6aec6bbd3d61e)
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
|
|
This function does not build on 32-bit targets when the compiler
fails to reduce DIV_ROUND_UP() into a shift:
ld.lld: error: undefined symbol: __aeabi_uldivmod
>>> referenced by xe_migrate.c
>>> drivers/gpu/drm/xe/xe_migrate.o:(pte_update_size) in archive vmlinux.a
There are two instances in this function. Change the first to
use an open-coded shift with the same behavior, and the second
one to a 32-bit calculation, which is sufficient here as the size
is never more than 2^32 pages (16TB).
Fixes: 237412e45390 ("drm/xe: Enable 32bits build")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240226124736.1272949-3-arnd@kernel.org
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
(cherry picked from commit 1408784b599927d2f361bac6dc5170d2ee275f17)
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
|
|
When the driver is built-in but the tests are in loadable modules,
the helpers don't actually get put into the driver:
ERROR: modpost: "xe_kunit_helper_alloc_xe_device" [drivers/gpu/drm/xe/tests/xe_test.ko] undefined!
Change the Makefile to ensure they are always part of the driver
even when the rest of the kunit tests are in loadable modules.
Fixes: 5095d13d758b ("drm/xe/kunit: Define helper functions to allocate fake xe device")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240226124736.1272949-1-arnd@kernel.org
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
(cherry picked from commit 0e6fec6da25167a568fbaeb8401d8172069124ad)
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
|
|
https://git.linaro.org/people/jens.wiklander/linux-tee into arm/fixes
Fix kernel panic in OP-TEE driver
* tag 'optee-fix-for-v6.8' of https://git.linaro.org/people/jens.wiklander/linux-tee:
tee: optee: Fix kernel panic caused by incorrect error handling
Link: https://lore.kernel.org/r/20240304132727.GA3501807@rayden
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
This patch adds support for StarFive's StarLink PMU (Performance
Monitor Unit). StarLink PMU integrates one or more CPU cores with
a shared L3 memory system. The PMU supports overflow interrupt,
up to 16 programmable 64bit event counters, and an independent
64bit cycle counter. StarLink PMU is accessed via MMIO.
Example Perf stat output:
[root@user]# perf stat -a -e /starfive_starlink_pmu/cycles/ \
-e /starfive_starlink_pmu/read_miss/ \
-e /starfive_starlink_pmu/read_hit/ \
-e /starfive_starlink_pmu/release_request/ \
-e /starfive_starlink_pmu/write_hit/ \
-e /starfive_starlink_pmu/write_miss/ \
-e /starfive_starlink_pmu/write_request/ \
-e /starfive_starlink_pmu/writeback/ \
-e /starfive_starlink_pmu/read_request/ \
-- openssl speed rsa2048
Doing 2048 bits private rsa's for 10s: 5 2048 bits private RSA's in
2.84s
Doing 2048 bits public rsa's for 10s: 169 2048 bits public RSA's in
2.42s
version: 3.0.11
built on: Tue Sep 19 13:02:31 2023 UTC
options: bn(64,64)
CPUINFO: N/A
sign verify sign/s verify/s
rsa 2048 bits 0.568000s 0.014320s 1.8 69.8
/////////
Performance counter stats for 'system wide':
649991998 starfive_starlink_pmu/cycles/
1009690 starfive_starlink_pmu/read_miss/
1079750 starfive_starlink_pmu/read_hit/
2089405 starfive_starlink_pmu/release_request/
129 starfive_starlink_pmu/write_hit/
70 starfive_starlink_pmu/write_miss/
194 starfive_starlink_pmu/write_request/
150080 starfive_starlink_pmu/writeback/
2089423 starfive_starlink_pmu/read_request/
27.062755678 seconds time elapsed
Signed-off-by: Ji Sheng Teoh <jisheng.teoh@starfivetech.com>
Link: https://lore.kernel.org/r/20240229072720.3987876-2-jisheng.teoh@starfivetech.com
Signed-off-by: Will Deacon <will@kernel.org>
|
|
The function xxx_find_related_event() scan all working events to find
related events. During this process, we also can find the idle counters.
If not found related events, return the first idle counter to simplify
the code.
Signed-off-by: Junhao He <hejunhao3@huawei.com>
Signed-off-by: Yicong Yang <yangyicong@hisilicon.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Link: https://lore.kernel.org/r/20240223103359.18669-8-yangyicong@huawei.com
Signed-off-by: Will Deacon <will@kernel.org>
|
|
If we use two events with the same filter and related event type
(see the following example), the driver check whether they are related
events and are in the same group, otherwise the function
hisi_pcie_pmu_find_related_event() return -EINVAL, then the 2nd event
cannot count but the 1st event is running, although the PCIe PMU has
other idle counters.
In this case, The perf event scheduler will make the two events to
multiplex a counter, if the user use the formula
(1st event_value / 2nd event_value) to calculate the bandwidth, he/she
won't get the correct value, because they are not counting at the
same period.
This patch tries to fix this by making the related events to use
different idle counters if they are not in the same event group.
And finally, I'm going to say. The related events are best used in the
same group [1]. There are two ways to know if they are related events.
a) By event name, such as the latency events "xxx_latency, xxx_cnt" or
bandwidth events "xxx_flux, xxx_time".
b) By event type, such as "event=0xXXXX, event=0x1XXXX".
Use group to count the related events:
[1] -e "{pmu_name/xxx_latency,port=1/,pmu_name/xxx_cnt,port=1/}"
example:
1st event: hisi_pcie0_core1/event=0x804,port=1
2nd event: hisi_pcie0_core1/event=0x10804,port=1
test cmd:
perf stat -e hisi_pcie0_core1/event=0x804,port=1/ \
-e hisi_pcie0_core1/event=0x10804,port=1/
before patch:
25,281 hisi_pcie0_core1/event=0x804,port=1/ (49.91%)
470,598 hisi_pcie0_core1/event=0x10804,port=1/ (50.09%)
after patch:
24,147 hisi_pcie0_core1/event=0x804,port=1/
474,558 hisi_pcie0_core1/event=0x10804,port=1/
Signed-off-by: Junhao He <hejunhao3@huawei.com>
Signed-off-by: Yicong Yang <yangyicong@hisilicon.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huwei.com>
Link: https://lore.kernel.org/r/20240223103359.18669-7-yangyicong@huawei.com
Signed-off-by: Will Deacon <will@kernel.org>
|
|
The PMU can monitor traffic of certain target Root Port or downstream
target Endpoint. User can specify the target filter by the "port" or
"bdf" option respectively. The PMU can only monitor the Root Port or
Endpoint on the same PCIe core so the value of "port" or "bdf" should
be valid and will be checked by the driver.
Currently at least and only one of "port" and "bdf" option must be set.
If "port" filter is not set or is set explicitly to zero (default),
driver will regard the user specifies a "bdf" option since "port" option
is a bitmask of the target Root Ports and zero is not a valid
value.
If user not explicitly set "port" or "bdf" filter, the driver uses "bdf"
default value (zero) to set target filter, but driver will skip the
check of bdf=0, although it's a valid value (meaning 0000:000:00.0).
Then the user just gets zero.
Therefore, we need to check if both "port" and "bdf" are invalid, then
return failure and report warning.
Testing:
before the patch:
0 hisi_pcie0_core1/rx_mrd_flux/
0 hisi_pcie0_core1/rx_mrd_flux,port=0/
24,124 hisi_pcie0_core1/rx_mrd_flux,port=1/
0 hisi_pcie0_core1/rx_mrd_flux,bdf=0/
0 hisi_pcie0_core1/rx_mrd_flux,port=0x800/
<not supported> hisi_pcie0_core1/rx_mrd_flux,bdf=1/
24,132 hisi_pcie0_core1/rx_mrd_flux,bdf=0x1700/
<not supported> hisi_pcie0_core1/rx_mrd_flux,port=0x0,bdf=0x0/
<not supported> hisi_pcie0_core1/rx_mrd_flux,port=0x0,bdf=0x1/
24,138 hisi_pcie0_core1/rx_mrd_flux,port=0x0,bdf=0x1700/
24,126 hisi_pcie0_core1/rx_mrd_flux,port=0x1,bdf=0x0/
after the patch:
<not supported> hisi_pcie0_core1/rx_mrd_flux/
<not supported> hisi_pcie0_core1/rx_mrd_flux,port=0/
24,153 hisi_pcie0_core1/rx_mrd_flux,port=1/
0 hisi_pcie0_core1/rx_mrd_flux,port=0x800/
<not supported> hisi_pcie0_core1/rx_mrd_flux,bdf=0/
<not supported> hisi_pcie0_core1/rx_mrd_flux,bdf=1/
24,117 hisi_pcie0_core1/rx_mrd_flux,bdf=0x1700/
<not supported> hisi_pcie0_core1/rx_mrd_flux,port=0x0,bdf=0x0/
<not supported> hisi_pcie0_core1/rx_mrd_flux,port=0x0,bdf=0x1/
24,120 hisi_pcie0_core1/rx_mrd_flux,port=0x0,bdf=0x1700/
24,123 hisi_pcie0_core1/rx_mrd_flux,port=0x1,bdf=0x0/
Signed-off-by: Junhao He <hejunhao3@huawei.com>
Signed-off-by: Yicong Yang <yangyicong@hisilicon.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Link: https://lore.kernel.org/r/20240223103359.18669-6-yangyicong@huawei.com
Signed-off-by: Will Deacon <will@kernel.org>
|
|
A typical PCIe transaction is consisted of various TLP packets in both
direction. For counting bandwidth only memory read events are exported
currently. Add memory write and completion counting events of both
direction to complete the bandwidth counting.
Signed-off-by: Yicong Yang <yangyicong@hisilicon.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Link: https://lore.kernel.org/r/20240223103359.18669-5-yangyicong@huawei.com
Signed-off-by: Will Deacon <will@kernel.org>
|
|
The metric counting shows incorrect results if the events in the
metric group using the same event but different filter options.
This is because we only judge the event code to decide whether
the event in the metric group should share the same hardware
counter, but ignore the settings of the filter.
For example, on a platform of 2 ports 0x1 and 0x2 but only port
0x1 has a downstream PCIe NVME device. The metric counting
shows both ports have the same counts because we misassign these
two events to one same hardware counter:
[root@localhost perf-iostat]# ./perf stat -e '{hisi_pcie0_core1/event=0x0104,port=0x2/,hisi_pcie0_core1/event=0x0104,port=0x1/}'
Performance counter stats for 'system wide':
7907484924 hisi_pcie0_core1/event=0x0104,port=0x2/
7907484924 hisi_pcie0_core1/event=0x0104,port=0x1/
10.153863691 seconds time elapsed
Fix this by using the whole config rather than the event only
to judge whether two events are the same and should share the
same hardware counter. With this patch, the metric counting in
the above case tends to be corrected:
[root@localhost perf-iostat]# ./perf stat -e '{hisi_pcie0_core1/event=0x0104,port=0x2/,hisi_pcie0_core1/event=0x0104,port=0x1/}'
Performance counter stats for 'system wide':
0 hisi_pcie0_core1/event=0x0104,port=0x2/
8123122077 hisi_pcie0_core1/event=0x0104,port=0x1/
10.152875631 seconds time elapsed
Fixes: 8404b0fbc7fb ("drivers/perf: hisi: Add driver for HiSilicon PCIe PMU")
Signed-off-by: Yicong Yang <yangyicong@hisilicon.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Link: https://lore.kernel.org/r/20240223103359.18669-4-yangyicong@huawei.com
Signed-off-by: Will Deacon <will@kernel.org>
|
