| Age | Commit message (Collapse) | Author |
|---|
|
Fixed spelling of "descriptor".
Signed-off-by: Ghanshyam Agrawal <ghanshyam1898@gmail.com>
Link: https://lore.kernel.org/r/20231215070707.560350-1-ghanshyam1898@gmail.com
[bjorn: Rewrote commit message]
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Drop stray semicolons after function definitions to avoid having this be
reproduced elsewhere.
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
Link: https://lore.kernel.org/r/20231208125827.10363-1-johan+linaro@kernel.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Enabling UCSI on sc8280xp and the Lenovo ThinkPad X13s in particular
results in a number of errors and timeouts during boot:
[ 9.012421] ucsi_glink.pmic_glink_ucsi pmic_glink.ucsi.0: GET_CONNECTOR_STATUS failed (-95)
[ 14.047379] ucsi_glink.pmic_glink_ucsi pmic_glink.ucsi.0: timeout waiting for UCSI sync write response
[ 14.050708] ucsi_glink.pmic_glink_ucsi pmic_glink.ucsi.0: GET_CONNECTOR_STATUS failed (-110)
[ 20.192382] ucsi_glink.pmic_glink_ucsi pmic_glink.ucsi.0: timeout waiting for UCSI sync write response
[ 20.192542] ucsi_glink.pmic_glink_ucsi pmic_glink.ucsi.0: GET_CONNECTOR_STATUS failed (-110)
Disable UCSI on sc8280xp until this has been resolved.
Fixes: 4db09e7b967b ("soc: qcom: pmic_glink: enable UCSI by default)
Link: https://lore.kernel.org/r/ZXL5jvDHr-MuxMoz@hovoldconsulting.com
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20231208125730.10323-1-johan+linaro@kernel.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Commit c14e64b46944 ("soc: qcom: llcc: Support chipsets that can
write to llcc") add the support for chipset where capacity based
allocation and retention through power collapse can be programmed
based on content of SCT table mentioned in the llcc driver where
the target like sdm845 where the entire programming related to it
is controlled in firmware. However, the commit introduces a bug
where capacity/retention register get overwritten each time it
gets programmed for each slice and that results in misconfiguration
of the register based on SCT table and that is not expected
behaviour instead it should be read modify write to retain the
configuration of other slices.
This issue is totally caught from code review and programming test
and not through any power/perf numbers so, it is not known what
impact this could make if we don't have this change however,
this feature are for these targets and they should have been
programmed accordingly as per their configuration mentioned in
SCT table like others bits information.
This change brings one difference where it keeps capacity/retention
bits of the slices that are not mentioned in SCT table in unknown
state where as earlier it was initialized to zero.
Fixes: c14e64b46944 ("soc: qcom: llcc: Support chipsets that can write to llcc")
Signed-off-by: Atul Dhudase <quic_adhudase@quicinc.com>
Signed-off-by: Mukesh Ojha <quic_mojha@quicinc.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/1701876771-10695-1-git-send-email-quic_mojha@quicinc.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Sparse reports the following:
% ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make C=2 W=1 drivers/soc/qcom/pmic_pdcharger_ulog.o
...
CC drivers/soc/qcom/pmic_pdcharger_ulog.o
CHECK drivers/soc/qcom/pmic_pdcharger_ulog.c
drivers/soc/qcom/pmic_pdcharger_ulog.c:57:34: warning: incorrect type in initializer (different base types)
drivers/soc/qcom/pmic_pdcharger_ulog.c:57:34: expected restricted __le32 [usertype] owner
drivers/soc/qcom/pmic_pdcharger_ulog.c:57:34: got int
drivers/soc/qcom/pmic_pdcharger_ulog.c:58:33: warning: incorrect type in initializer (different base types)
drivers/soc/qcom/pmic_pdcharger_ulog.c:58:33: expected restricted __le32 [usertype] type
drivers/soc/qcom/pmic_pdcharger_ulog.c:58:33: got int
drivers/soc/qcom/pmic_pdcharger_ulog.c:59:35: warning: incorrect type in initializer (different base types)
drivers/soc/qcom/pmic_pdcharger_ulog.c:59:35: expected restricted __le32 [usertype] opcode
drivers/soc/qcom/pmic_pdcharger_ulog.c:59:35: got int
Let's deal with endianness conversion in the rare case this ever runs
on a big-endian machine (and to quiet down sparse for this file).
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202312060355.M0eJtq4X-lkp@intel.com/
Fixes: 086fdb48bc65 ("soc: qcom: add ADSP PDCharger ULOG driver")
Signed-off-by: Andrew Halaney <ahalaney@redhat.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20231205-pmicpdcharger-ulog-fixups-v1-3-71c95162cb84@redhat.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
As specified in samples/trace_events/trace-events-sample.h:
* Notice that TRACE_SYSTEM should be defined outside of #if
* protection, just like TRACE_INCLUDE_FILE.
Fixes: 086fdb48bc65 ("soc: qcom: add ADSP PDCharger ULOG driver")
Signed-off-by: Andrew Halaney <ahalaney@redhat.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20231205-pmicpdcharger-ulog-fixups-v1-2-71c95162cb84@redhat.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
As specified in samples/trace_events/Makefile:
If you include a trace header outside of include/trace/events
then the file that does the #define CREATE_TRACE_POINTS must
have that tracer file in its main search path. This is because
define_trace.h will include it, and must be able to find it from
the include/trace directory.
Without this the following compilation error is seen:
CC drivers/soc/qcom/pmic_pdcharger_ulog.o
In file included from drivers/soc/qcom/pmic_pdcharger_ulog.h:36,
from drivers/soc/qcom/pmic_pdcharger_ulog.c:15:
./include/trace/define_trace.h:95:42: fatal error: ./pmic_pdcharger_ulog.h: No such file or directory
95 | #include TRACE_INCLUDE(TRACE_INCLUDE_FILE)
| ^
compilation terminated.
Fixes: 086fdb48bc65 ("soc: qcom: add ADSP PDCharger ULOG driver")
Signed-off-by: Andrew Halaney <ahalaney@redhat.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20231205-pmicpdcharger-ulog-fixups-v1-1-71c95162cb84@redhat.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Add support to get image details from SMEM for DSPs like
DSPS (Sensors DSP), CDSP (Compute DSP), GPDSP (General purpose DSP)
while also supporting this for more than one DSP of certain types.
Signed-off-by: Naman Jain <quic_namajain@quicinc.com>
Link: https://lore.kernel.org/r/20231205101018.6079-1-quic_namajain@quicinc.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Fix all warnings thrown due to missing description for some of the
members in llcc_slice_config.
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202312050519.mup4Q8mD-lkp@intel.com/
Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
Link: https://lore.kernel.org/r/20231205-llcc-fix-slice-config-warnings-v1-1-d6331d601dd3@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
After recent reports ([1], [2]) of older platforms (particularly 8150 and
7180) breaking after DDR sleep stats introduction, revert the following:
Commit 73380e2573c3 ("soc: qcom: stats: fix 64-bit division")
Commit e84e61bdb97c ("soc: qcom: stats: Add DDR sleep stats")
The feature itself is rather useful for debugging DRAM power management,
however it looks like the shared RPMh stats data structures differ on
previous SoCs.
Revert its addition for now to un-break booting on these earlier SoCs,
while I try to come up with a better way to enable it conditionally.
[1] https://lore.kernel.org/linux-arm-msm/20231209215601.3543895-2-dmitry.baryshkov@linaro.org/
[2] https://lore.kernel.org/linux-arm-msm/CAD=FV=XX4wLg1NNVL15RK4D4tLvuSzZyUv=k_tS4bSb3=7QJzQ@mail.gmail.com/
Reported-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reported-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Tested-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20231214-topic-undo_ddr_stats-v1-1-1fe32c258e56@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Randy reported yet another build issue with randconfigs on rv32:
WARNING: unmet direct dependencies detected for DMA_GLOBAL_POOL
Depends on [n]: !ARCH_HAS_DMA_SET_UNCACHED [=n] && !DMA_DIRECT_REMAP [=y]
Selected by [y]:
- ARCH_R9A07G043 [=y] && SOC_RENESAS [=y] && RISCV [=y] && NONPORTABLE [=y] && RISCV_ALTERNATIVE [=y] && !RISCV_ISA_ZICBOM [=n] && RISCV_SBI [=y]
This happens when DMA_DIRECT_REMAP is selected by the T-Head CMO erratum
option and DMA_GLOBAL_POOL is selected by the Andes CMO erratum. Block
selecting the RZ/Five config option, and by extension DMA_GLOBAL_POOL,
if DMA_DIRECT_REMAP has already been enabled.
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Closes: https://lore.kernel.org/all/24942b4d-d16a-463f-b39a-f9dfcb89d742@infradead.org/
Tested-by: Randy Dunlap <rdunlap@infradead.org> # build-tested
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20231211-primate-arbitrate-fbcd307a0b00@spud
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
|
|
As of commit 3f84aa5ec052dba9 ("base: soc: populate machine name in
soc_device_register if empty") in v6.4, soc_device_register() fills in
soc_device_attribute.family when it is still empty. Hence the identical
code in renesas_soc_init() doing the same can be removed.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/4c5e4d0d1819028466748ed684254fec41aae816.1701696627.git.geert+renesas@glider.be
|
|
payload[0] of response buffer of zynqmp_pm_get_callback_data()
contains valid payload or error code in case of error.
Added error message to inform user about the error code received in
payload[0].
Signed-off-by: Naman Trivedi Manojbhai <naman.trivedimanojbhai@amd.com>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/85749bde3e71148533d31ea2092f4514ec347768.1701962639.git.michal.simek@amd.com
|
|
Add JTAG ID info for the J722S SoC family to enable SoC detection.
More details about this SoC can be found in the TRM:
https://www.ti.com/lit/zip/sprujb3
Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com>
Reviewed-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20231211132600.25289-1-vaishnav.a@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
|
|
Introduce qmc_chan_{get,set}_ts_info() function to allow timeslots
modification at runtime.
The modification is provided using qmc_chan_set_ts_info() and will be
applied on next qmc_chan_start().
qmc_chan_set_ts_info() must be called with the channel rx and/or tx
stopped.
Signed-off-by: Herve Codina <herve.codina@bootlin.com>
Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Link: https://lore.kernel.org/r/20231205152116.122512-18-herve.codina@bootlin.com
|
|
Timeslots setting is done at channel start() and stop().
There is no more need to do that during setup_chan().
Simply remove timeslot setting from setup_chan().
Signed-off-by: Herve Codina <herve.codina@bootlin.com>
Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Link: https://lore.kernel.org/r/20231205152116.122512-17-herve.codina@bootlin.com
|
|
In order to support runtime timeslot route changes, enable the
channel timeslot entries at channel start() and disable them at
channel stop().
Signed-off-by: Herve Codina <herve.codina@bootlin.com>
Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Link: https://lore.kernel.org/r/20231205152116.122512-16-herve.codina@bootlin.com
|
|
In order to support runtime timeslot route changes, some operations will
be different according the routing table used (common Rx and Tx table or
one table for Rx and one for Tx).
The is_tsa_64rxtx flag is introduced to avoid extra computation to
determine the table format each time we need it.
It is set once at initialization.
Signed-off-by: Herve Codina <herve.codina@bootlin.com>
Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Link: https://lore.kernel.org/r/20231205152116.122512-15-herve.codina@bootlin.com
|
|
The Tx and Rx entries for a given channel are set in one function.
In order to modify Rx entries and Tx entries independently of one other,
split this function in one for the Rx part and one for the Tx part.
Signed-off-by: Herve Codina <herve.codina@bootlin.com>
Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Link: https://lore.kernel.org/r/20231205152116.122512-14-herve.codina@bootlin.com
|
|
In order to allow runtime timeslot route changes, disabling channel TSA
entries needs to be supported.
Add support for this new feature.
Signed-off-by: Herve Codina <herve.codina@bootlin.com>
Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Link: https://lore.kernel.org/r/20231205152116.122512-13-herve.codina@bootlin.com
|
|
The timeslots checked in qmc_check_chans() are the timeslots used.
With the introduction of the available timeslots, the used timeslots
are a subset of the available timeslots. The timeslots checked during
the qmc_check_chans() call should be the available ones.
Simply update and check the available timeslots instead of the used
timeslots in qmc_check_chans().
Signed-off-by: Herve Codina <herve.codina@bootlin.com>
Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Link: https://lore.kernel.org/r/20231205152116.122512-12-herve.codina@bootlin.com
|
|
The newly introduced qmc_chan_setup_tsa* functions check that the
channel entries are not already used.
These checks are also performed by qmc_check_chans() and are no more
needed.
Remove them from qmc_check_chans().
Signed-off-by: Herve Codina <herve.codina@bootlin.com>
Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Link: https://lore.kernel.org/r/20231205152116.122512-11-herve.codina@bootlin.com
|
|
Introduce the qmc_chan_setup_tsa* functions to setup entries related
to the given channel.
Use them during QMC channels setup.
Signed-off-by: Herve Codina <herve.codina@bootlin.com>
Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Link: https://lore.kernel.org/r/20231205152116.122512-10-herve.codina@bootlin.com
|
|
qmc_setup_tsa* are called once at initialisation.
They initialize the QMC TSA table.
In order to introduce setup function later on for dynamic timeslots
management, rename the function to avoid later confusion.
Signed-off-by: Herve Codina <herve.codina@bootlin.com>
Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Link: https://lore.kernel.org/r/20231205152116.122512-9-herve.codina@bootlin.com
|
|
Available timeslots masks define timeslots available for the related
channel. These timeslots are defined by the QMC binding.
Timeslots used are initialized to available timeslots but can be a
subset of available timeslots.
This prepares the dynamic timeslots management (ie. changing timeslots
at runtime).
Signed-off-by: Herve Codina <herve.codina@bootlin.com>
Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Link: https://lore.kernel.org/r/20231205152116.122512-8-herve.codina@bootlin.com
|
|
QMC child devices support is needed to avoid orphan DT nodes that use a
simple DT phandle to reference a QMC channel.
Allow to instantiate child devices and also extend the API to get the
qmc_chan using a child device.
Signed-off-by: Herve Codina <herve.codina@bootlin.com>
Link: https://lore.kernel.org/r/20231205152116.122512-7-herve.codina@bootlin.com
|
|
The inline function specifier is present on some functions but it is
better to let the compiler decide inlining or not these functions.
Remove inline specifiers.
Fixes: 3178d58e0b97 ("soc: fsl: cpm1: Add support for QMC")
Signed-off-by: Herve Codina <herve.codina@bootlin.com>
Suggested-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Link: https://lore.kernel.org/r/20231205152116.122512-6-herve.codina@bootlin.com
|
|
In HDLC mode, some status flags related to the data read transfer can be
set by the hardware and need to be known by a QMC consumer for further
analysis.
Extend the API in order to provide these transfer status flags at the
read complete() call.
In TRANSPARENT mode, these flags have no meaning. Keep only one read
complete() API and update the consumers working in transparent mode.
In this case, the newly introduced flags parameter is simply unused.
Signed-off-by: Herve Codina <herve.codina@bootlin.com>
Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Link: https://lore.kernel.org/r/20231205152116.122512-5-herve.codina@bootlin.com
|
|
The qmc_chan_reset_rx() set the is_rx_stopped flag. This leads to an
inconsistent state in the following sequence.
qmc_chan_stop()
qmc_chan_reset()
Indeed, after the qmc_chan_reset() call, the channel must still be
stopped. Only a qmc_chan_start() call can move the channel from stopped
state to started state.
Fix the issue removing the is_rx_stopped flag setting from
qmc_chan_reset()
Fixes: 3178d58e0b97 ("soc: fsl: cpm1: Add support for QMC")
Cc: stable@vger.kernel.org
Signed-off-by: Herve Codina <herve.codina@bootlin.com>
Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Link: https://lore.kernel.org/r/20231205152116.122512-4-herve.codina@bootlin.com
|
|
Running sparse (make C=1) on qmc.c raises a lot of warning such as:
...
warning: incorrect type in assignment (different address spaces)
expected struct cpm_buf_desc [usertype] *[noderef] __iomem bd
got struct cpm_buf_desc [noderef] [usertype] __iomem *txbd_free
...
Indeed, some variable were declared 'type *__iomem var' instead of
'type __iomem *var'.
Use the correct declaration to remove these warnings.
Fixes: 3178d58e0b97 ("soc: fsl: cpm1: Add support for QMC")
Cc: stable@vger.kernel.org
Signed-off-by: Herve Codina <herve.codina@bootlin.com>
Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Link: https://lore.kernel.org/r/20231205152116.122512-3-herve.codina@bootlin.com
|
|
Running sparse (make C=1) on tsa.c raises a lot of warning such as:
--- 8< ---
warning: incorrect type in assignment (different address spaces)
expected void *[noderef] si_regs
got void [noderef] __iomem *
--- 8< ---
Indeed, some variable were declared 'type *__iomem var' instead of
'type __iomem *var'.
Use the correct declaration to remove these warnings.
Fixes: 1d4ba0b81c1c ("soc: fsl: cpm1: Add support for TSA")
Cc: stable@vger.kernel.org
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202312051959.9YdRIYbg-lkp@intel.com/
Signed-off-by: Herve Codina <herve.codina@bootlin.com>
Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Link: https://lore.kernel.org/r/20231205152116.122512-2-herve.codina@bootlin.com
|
|
Some members of struct svs_bank are not changed during runtime, so those
are not variables but constants: move all of those to a new structure
called svs_bank_pdata and refactor the code to make use of that and
reorder members by size where possible.
This effectively moves at least 50 bytes to the text segment.
While at it, also uniform the thermal zone names across the banks.
Link: https://lore.kernel.org/r/20231121125044.78642-19-angelogioacchino.delregno@collabora.com
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
|
|
The `freq` variable is of type unsigned long and, even though it does
currently work with u32 because no frequency is higher than U32_MAX,
it is not guaranteed that in the future we will see one.
Initialize the freq variable with ULONG_MAX instead of U32_MAX.
Link: https://lore.kernel.org/r/20231121125044.78642-18-angelogioacchino.delregno@collabora.com
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
|
|
The svs_init01() and svs_init02() functions are already checking if the
INIT01 and INIT02 modes are available - but that's done in for loops and
for each SVS bank.
Give those a shortcut to get out early if no SVS bank features the
desired init mode: this is especially done to avoid some locking in
the svs_init01(), but also to avoid multiple for loops to check the
same, when no bank supports a specific mode.
Link: https://lore.kernel.org/r/20231121125044.78642-17-angelogioacchino.delregno@collabora.com
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
|
|
Cleanup the svs_probe() function: use dev_err_probe() where possible,
change some efuse read failure gotos and then remove now impossible
IS_ERR_OR_NULL() checks (as they will never return true) for nvmem
(efuse read) failures.
Also remove some unnecessary blank lines.
Link: https://lore.kernel.org/r/20231121125044.78642-16-angelogioacchino.delregno@collabora.com
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
|
|
Compress each entry to one line, as they fit in 84 columns, which
is acceptable.
While at it, also change the capital 'S' to 's' in 'sentinel'.
Link: https://lore.kernel.org/r/20231121125044.78642-15-angelogioacchino.delregno@collabora.com
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
|
|
Callers of svs_get_efuse_data() are already printing an error in case
anything goes wrong, and the error print for nvmem_cell_read() failure
is redundant: remove it.
Link: https://lore.kernel.org/r/20231121125044.78642-14-angelogioacchino.delregno@collabora.com
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
|
|
Include the additions of svs_mt8186_platform_probe() in the common
svs_mt8192_platform_probe() function, remove the former, and use the
latter as .probe() callback for MT8186.
Link: https://lore.kernel.org/r/20231121125044.78642-13-angelogioacchino.delregno@collabora.com
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
|
|
Drop the "pbank" pointer from struct svs_bank: this was used to simply
pass a pointer to the SVS bank that the flow was working on.
That for instance needs more locking, and it's avoidable by adding one
more parameter to functions working on specific banks, either a bank
index number, or passing the svs_bank pointer directly from the caller.
Even if the locking can now be reduced, for now, it was still left in
place for the sake of making sure to not introduce any stability and/or
reliability regression.
Link: https://lore.kernel.org/r/20231121125044.78642-12-angelogioacchino.delregno@collabora.com
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
|
|
Remove almost all of the per-SoC .efuse_parsing() callbacks and replace
them with one common callback svs_common_parse_efuse(): to do that, also
change the function signature of the callback to add the newly required
pointer to struct svs_platform_data, containing the SVS-global fuse map.
This is done for MT8186, MT8188, MT8192, MT8195.
As for MT8183, the efuse parse function was simplified by using the new
fuse maps.
Link: https://lore.kernel.org/r/20231121125044.78642-11-angelogioacchino.delregno@collabora.com
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
|
|
The t-calibration-data (SVS-Thermal calibration data) shall exist for
all SoCs or SVS won't work anyway: move it to the common svs_probe()
function and remove it from all of the per-SoC efuse_parsing() probe
callbacks.
Link: https://lore.kernel.org/r/20231121125044.78642-10-angelogioacchino.delregno@collabora.com
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
|
|
In preparation for commonizing the efuse parsing function, add the
SVS-Thermal coefficients for all SoCs for which said function can be
commonized (MT8186, MT8188, MT8192, MT8195) and assign those to their
platform data structure.
That will be used to calculate the MTS parameter with the equation
MTS = (ts_coeff * 2) / 1000
This commit brings no functional changes.
Link: https://lore.kernel.org/r/20231121125044.78642-9-angelogioacchino.delregno@collabora.com
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
|
|
In preparation for adding a common efuse parsing function which will
greatly reduce code duplication, add a SoC-specific mapping that will
be used to retrieve the right SVS calibration values from the fuses.
The maps are two: one is a Global Map used for reading parameters that
are SVS-global, and one is a Bank Map for reading calibrations for
each SVS Bank.
While at it, also populate the map in the platform data for each SoC.
Being this a preparation commit, there are no functional changes.
Link: https://lore.kernel.org/r/20231121125044.78642-8-angelogioacchino.delregno@collabora.com
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
|
|
This driver tries to create a device link to the thermal sensor device:
change all instances of "lvts" and "thermal" to "thermal-sensor", as
that's what the devicetree node name must be.
Note for MT8183: As specified in a previous commit, this SoC never got
SVS probing, so this is not a breaking change and it does not require
fallback for older device trees.
Link: https://lore.kernel.org/r/20231121125044.78642-7-angelogioacchino.delregno@collabora.com
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
|
|
Many 32-bit members of this struct can be size reduced to either 16-bit
or even 8-bit, for a total saving of ~61 bytes per bank. Keeping in mind
that one SoC declares at least two banks, this brings a minimum of ~122
bytes saving (depending on compiler optimization).
Link: https://lore.kernel.org/r/20231121125044.78642-6-angelogioacchino.delregno@collabora.com
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
|
|
In svs_bank_resource_setup() there is a "big" switch assigning different
names depending on sw_id and type and this will surely grow: for example
MT8186 has got a two-line type (high/low) SVS bank for CPU_BIG, and this
would require more switch nesting.
Simplify all of this by changing that to a devm_kasprintf() call that
will concatenate the SW_ID string (e.g. SVSB_CPU_LITTLE) with the Type
string (e.g. _LOW), resulting in the expected full bank name (e.g.
SVSB_CPU_LITTLE_LOW).
This being a dynamic allocation can be slower, but this happens only
once in the life of this driver and it's not a performance path, so it's
totally acceptable.
Link: https://lore.kernel.org/r/20231121125044.78642-5-angelogioacchino.delregno@collabora.com
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
|
|
The sw_id and type specifiers currently are defined as BIT(x) for
unknown reasons: nothing in this code makes any AND/OR check for
those, and that would never happen anyway because both sw_id and
type are exclusive, as in:
- There will never be a bank that is for both CPU and GPU, or
for CPU and CCI together;
- A bank cannot be contemporarily of one-line and two-line type,
as much as it cannot contemporarily have both HIGH and LOW roles
Change those definitions to enumerations and also add some kerneldoc
to better describe what they are for and what they indicate.
While at it, also change the names adding _SWID or _TYPE to increase
human readability.
Link: https://lore.kernel.org/r/20231121125044.78642-4-angelogioacchino.delregno@collabora.com
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
|
|
The svs_regs_v2 array of registers was offsetted by 0xc00 because the
SVS node was supposed to have the same iostart as the thermal sensors.
That's wrong for two reasons:
1. Two different devices cannot have the same iostart in devicetree,
as those would technically be the same device otherwise; and
2. SVS and Thermal Sensor (be it LVTS or AUXADC thermal) are not the
same IP, and those two do obviously have a different iospace.
Even though there already are users of this register array, the only
one that declares a devicetree node for SVS is MT8183 - but it never
actually worked because the "tzts1" thermal zone missed thermal trips,
hence this driver's probe always failed on that SoC.
Knowing this - it is safe to say that keeping compatibility with older
device trees is pointless, hence simply subtract the 0xc00 offset from
the register offset array.
Link: https://lore.kernel.org/r/20231121125044.78642-3-angelogioacchino.delregno@collabora.com
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
|
|
Add MT8188 reset bit map for VDOSYS0 and VDOSYS1.
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Hsiao Chien Sung <shawn.sung@mediatek.com>
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
|
|
- Reset ID must starts from 0 and be consecutive, but
the reset bits in our hardware design is not continuous,
some bits are left unused, we need a map to solve the problem
- Use old style 1-to-1 mapping if .rst_tb is not defined
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Hsiao Chien Sung <shawn.sung@mediatek.com>
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
|
