To SDX55 this introduces the description of the IPA, PCIe PHY and PCIe
endpoint controller, as well as enables these for the FN960 device.
The SDX65 5G platform is introduced, currently with definitions
necessary to boot to a shell.
The undocumented property "input-name" is dropped throughout the dts
files, dwc3 nodes throughout gains more specific compatibles and lastly
building of the Dragonboard 410c DTB on ARM32 is enabled, in addition to
its normal operation in 64-bit mode.
-----BEGIN PGP SIGNATURE-----
iQJPBAABCAA5FiEEBd4DzF816k8JZtUlCx85Pw2ZrcUFAmHBVYobHGJqb3JuLmFu
ZGVyc3NvbkBsaW5hcm8ub3JnAAoJEAsfOT8Nma3FruwQAIkncBLbeVIk2ioM7xEH
WRpd5yDczi2LVsXaDCjmCu9s4MMMaDYYUiQWSh1etovEdN+x8t4R8gzeNYDkZNX3
T0g3+x7bL0xjynQo4HEje8fzYZryCmWZfmYbqggawLWynUDXyYLSNFh+bxKEFpLw
uxOiNXzmTRZQhNUE60JV2BJCNuZls+pjthURbTAGWZ/LoBhgW6RjADOqGHVz1eF0
RIz8YPRaVN0lTrBxPAwwJDJ4AWo5nG5zNiy0/0fxnxabvr32N/2YBl2dCJ3hMgZB
/OIsMS21b2wYbOR59NgD/vauGXUeGnophcWnMmIEPA9D/ZiJiKYNteWLfEbUNKnC
sy/XXZbo0y+uHBIxFsmg8m4Dh5WBmkAgoINwEZ/0BFTVoCbQq6Oi8xnkkvPc61L1
r/ZUpFr13xzV3s1e2dSPAlgW3P7WfgTyXTN/5YkNi4dT47uD71EiHTDvcUEocFcg
gPyjm4SSRo/1HUqPOJMeFnVx5mv4cCo2OrnkQWKaCENgWg07wFq3lXJjOB666jMF
OEXRKPmH8tA3eVexy0tayO1bps/Go2MGjERtRxz/EUw8UDWO/0SerhplYD/vMmFU
NLOWbwIAUoJT5daiAsUYJQr1KBnJMlkFsim0Nd962rKZTX4F5cKkkJv8ucrwN+01
SZoQVfDBHlZtMuMsJn/Sxqk/
=SjjW
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmHB5qAACgkQmmx57+YA
GNkkxxAAw0GqWdbEiF2rNpTHsZgJnsDJpIfxFgONdzVA6C4pDi2YUlp5GgKitBzQ
zok21TebNPTNOEf7q8FqubpleDU+x913eJaYYQA8DRmx5fHeNkzYt6jMAE5c3V5Y
fpcRSLV0GLiT48tzhK/r3917/jZWnjcp7eKWDWByyavzkphgcVTbqYYBYZVltkzH
s/nyIu8zdSvCmOLMipRrH85GSVi372DU6bD/ejHdz0yXv/RsT2/2DZA6ZeJSF3FQ
qpZEnGxnizGrqcP6b3g6xVjVEYmwHC8js3B8scUyM/I9j+h/LAQD8yRXLivj5kwm
tM/mtCGaIfux3ca1B0cRe5DTZP3jPa7vKUmIxTVJsjfgKyco9vwJlPIyHdSBKqQQ
n7HtB2jBruCjb2IhtHjhCC0htPKFpEUs6k1SK3UB+I3usEfMhut/FC5RFU9Pz6ta
GtQ8k6ucdJySQDxgOF62EFqEjQmcDNOqTl07rgosXx4zrh4TYNlvW6v6/N3QblPp
8eRQGgK6HZMAypL1HgeEeYtYhK6eyRCfmNrQ+U2w1o/VRsRwwsLC6g4YENyEYm+1
yVQjPyEgo9KZah3tYtc8pxAGs3E6ulyHMhBZtHh1gWjSNyDTEBvYjcuKE1Javxmh
dRRgIoymJG1f7b5zACkimDuvB5A4DOJ6pUvpvpad6Cv724J7ixA=
=rvAi
-----END PGP SIGNATURE-----
Merge tag 'qcom-dts-for-5.17' of git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/dt
Qualcomm DeviceTree updates for v5.17
To SDX55 this introduces the description of the IPA, PCIe PHY and PCIe
endpoint controller, as well as enables these for the FN960 device.
The SDX65 5G platform is introduced, currently with definitions
necessary to boot to a shell.
The undocumented property "input-name" is dropped throughout the dts
files, dwc3 nodes throughout gains more specific compatibles and lastly
building of the Dragonboard 410c DTB on ARM32 is enabled, in addition to
its normal operation in 64-bit mode.
* tag 'qcom-dts-for-5.17' of git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux:
ARM: dts: qcom: Drop input-name property
ARM: dts: qcom: sdx65: Add pincontrol node
ARM: dts: qcom: Add SDX65 platform and MTP board support
dt-bindings: arm: qcom: Document SDX65 platform and boards
dt-bindings: clock: Add SDX65 GCC clock bindings
ARM: dts: qcom: Build apq8016-sbc/DragonBoard 410c DTB on ARM32
ARM: dts: qcom: sdx55-t55: Enable IPA
ARM: dts: qcom: sdx55-fn980: Enable IPA
ARM: dts: qcom: sdx55-fn980: Enable PCIe EP
ARM: dts: qcom: sdx55: Add support for PCIe EP
ARM: dts: qcom: sdx55-fn980: Enable PCIE0 PHY
ARM: dts: qcom: sdx55: Add support for PCIe PHY
ARM: dts: qcom: update USB nodes with new platform specific compatible
Link: https://lore.kernel.org/r/20211221042154.3621955-1-bjorn.andersson@linaro.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
There's no need for a fixed string like 'BUCK9' to be under
'patternProperties', so move it under 'properties' instead.
Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20211221120744.1118518-1-robh@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
In addition to CPS SMP setups, also try to initialise MT SMP setups with
multiple VPEs per CPU core. CMP SMP support is not provided as it is
considered deprecated.
Additionally, rework the code by dropping the err variable and make it
similar to how other platforms perform this initialisation.
Co-developed-by: INAGAKI Hiroshi <musashino.open@gmail.com>
Signed-off-by: INAGAKI Hiroshi <musashino.open@gmail.com>
Signed-off-by: Sander Vanheule <sander@svanheule.net>
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Verify that the current CPU actually supports multi-threading before
registering MT SMP ops, instead of unconditionally registering them if
the kernel is compiled with CONFIG_MIPS_MT_SMP.
Suggested-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Signed-off-by: Sander Vanheule <sander@svanheule.net>
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
A large number of the following errors is reported when compiling
with clang:
cvmx-bootinfo.h:326:3: error: adding 'int' to a string does not append to the string [-Werror,-Wstring-plus-int]
ENUM_BRD_TYPE_CASE(CVMX_BOARD_TYPE_NULL)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cvmx-bootinfo.h:321:20: note: expanded from macro 'ENUM_BRD_TYPE_CASE'
case x: return(#x + 16); /* Skip CVMX_BOARD_TYPE_ */
~~~^~~~
cvmx-bootinfo.h:326:3: note: use array indexing to silence this warning
cvmx-bootinfo.h:321:20: note: expanded from macro 'ENUM_BRD_TYPE_CASE'
case x: return(#x + 16); /* Skip CVMX_BOARD_TYPE_ */
^
Follow the prompts to use the address operator '&' to fix this error.
Signed-off-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
This introduces RPM power-domain support for the SM8450, SM6125 and
QCM2290 platforms. It them clean up the platform-based naming of the
resources definitions throughout the RPMh PD driver.
The last-level cache controller driver gains SM8350 support.
The RPM sleep stats driver gains support for several older systems that
had a slightly different memory layout for this information.
The socinfo gains SM8450, SM6350 and SM7227 definitions.
In addition to the DeviceTree binding updates related to these changes
new compatibles was added to describe the SM8450 and the Kryo 780 CPU.
Lastly a few typo and style fixes are introduced.
-----BEGIN PGP SIGNATURE-----
iQJPBAABCAA5FiEEBd4DzF816k8JZtUlCx85Pw2ZrcUFAmHBUg4bHGJqb3JuLmFu
ZGVyc3NvbkBsaW5hcm8ub3JnAAoJEAsfOT8Nma3FObUQAOCTBSbL/US0wCCUEHPq
MScjFtPDAV88bJi9uRzi5lalwPd/3yPZu+XLcCV/CjRj6nlGAbua2EcogvMsM1Lj
rgHZopKnnDOHEFII2ZZ3lyJN4EntvSGHtnm/i2Jd7n3nB52zBkuRpgn3mi32QWoL
QmGECClAPFBlQi9P33yHDZ/XC8ZK1y982G+Pb8SD6guxmtGxXCm4SaZ4qwVya53s
euBl+nT/snARPEwaqRoGIsvs+fH2BcoJbug19MLQ+3Q4K9ycxQkWalzcMsLM/EjT
H1JGjoaHbTpNhyMmKDqN2jS0CkvoLiYOIvhAbqw6l2HluRkn8QhcDOJJ9RHl2oB/
EqYkK457F7smA0Z9vViuaEZJWfyPNt0z2c7zcpf73Iuk8cBM+48MUQ1UOwyvQh3c
8AeyyAkgyYBWv58h5rLDS2fqD+tWx4hz6tqxyYojsxYjQkyWRDU6540tGSDeVAt+
SUQ9qFXWyG7R5Z3GBVHi7ztXnkl6vYZUF05fhZrkpw9YrGlmu3wK/3Rcg9ZIECOg
Q0UA/GQsqQtCqmzkRQsur/ljEbCrmtiB6JvG+7cnQIWPwcN/4Ho3wyfXvtzNvNki
dMIpd+7NKkTaj1HUaH5qEnyO4szUpMoFfOrtqzlucH5dGG6fppY3svVWzuxLcbDy
8+b+/aDuWa7HUXpBbPaK7H7U
=ovup
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmHBy8wACgkQmmx57+YA
GNmS3xAAhIPIdMWF76Gb7eQu0UWrbuACSl0Nkt5SRbRyjX0BHectf+ssXUzR6r2/
l8Uf2fkBYP5UWVUbWXlKPlmwmdQo/lAGYeHvi/lx3W4ORvIe6CRTeIS0q0DLPwSV
H7iH8lnoFozIITt+6N+LhN9VME/Zpo8E/t2Wt47mkSkV/2hP6Adrgh5f4pz4KMcl
hHQcAhi0/3DTEoGjczBDcTXMIt8nUPSwTnd1ktOaD0avRgKgiiLslvzjTxLMXRuw
aDInx8uIMBswbEE0ZtG1aFrYZ54Y3DAm65n4aZfOPo3OlLjiosOqT1pvKWkpF/u1
OYcQzVEdUnEwZKB9BYzkTFVtK3ptE/5nNFg4HkclZATrqvEfQ6I3EbM9tvtY6GV+
BUUjxOthWq0Rnazd3BkOJvsepSndB1dOfxAunBk6m/r44shWWjLKGRI3jd+0QgW2
UVd0hy5pC28OZelGgSAU0PVQyHYl/82pRu7UCpHVaOg9mvuwgURChr7ddGi9XWVG
cMChFAumH/hvnQrRavONPUqaTjP62hRkOqjA/bvc3jFuAgFWqvSrc+z1AvqKw4Uz
0ks+tjoHrQ839EZB0g/LDk7K8MDe8llvOk16gzqNxplQJe2WYaRZ9S0GD+3MC1Wz
sSIyMsFLhfZJ2Z7TNOqLTPPW3jfoU3ntNzHUY8gCpTSh8DVkbtQ=
=NlpZ
-----END PGP SIGNATURE-----
Merge tag 'qcom-drivers-for-5.17' of git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/drivers
Qualcomm driver updates for v5.17
This introduces RPM power-domain support for the SM8450, SM6125 and
QCM2290 platforms. It them clean up the platform-based naming of the
resources definitions throughout the RPMh PD driver.
The last-level cache controller driver gains SM8350 support.
The RPM sleep stats driver gains support for several older systems that
had a slightly different memory layout for this information.
The socinfo gains SM8450, SM6350 and SM7227 definitions.
In addition to the DeviceTree binding updates related to these changes
new compatibles was added to describe the SM8450 and the Kryo 780 CPU.
Lastly a few typo and style fixes are introduced.
* tag 'qcom-drivers-for-5.17' of git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux: (27 commits)
soc: qcom: rpmh-rsc: Fix typo in a comment
soc: qcom: socinfo: Add SM6350 and SM7225
dt-bindings: arm: msm: Don't mark LLCC interrupt as required
dt-bindings: firmware: scm: Add SM6350 compatible
dt-bindings: arm: msm: Add LLCC for SM6350
soc: qcom: rpmhpd: Sort power-domain definitions and lists
soc: qcom: rpmhpd: Remove mx/cx relationship on sc7280
soc: qcom: rpmhpd: Rename rpmhpd struct names
soc: qcom: rpmhpd: sm8450: Add the missing .peer for sm8450_cx_ao
soc: qcom: socinfo: add SM8450 ID
soc: qcom: rpmhpd: Add SM8450 power domains
dt-bindings: power: rpmpd: Add SM8450 to rpmpd binding
soc: qcom: smem: Update max processor count
dt-bindings: arm: qcom: Document SM8450 SoC and boards
dt-bindings: firmware: scm: Add SM8450 compatible
dt-bindings: arm: cpus: Add kryo780 compatible
soc: qcom: rpmpd: Add support for sm6125
dt-bindings: qcom-rpmpd: Add sm6125 power domains
soc: qcom: aoss: constify static struct thermal_cooling_device_ops
PM: AVS: qcom-cpr: Use div64_ul instead of do_div
...
Link: https://lore.kernel.org/r/20211221040452.3620633-1-bjorn.andersson@linaro.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Since the MMC/SD controller in Ingenic SoCs work in half-duplex, it is
possible to use one single DMA channel for both TX and RX operations,
instead of using separate channels.
As some older Ingenic SoCs offer only a handful of DMA channels,
supporting bi-directional channels allow more hardware to use the
channels that would otherwise be used for the MMC/SD operation.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20211220190840.108061-3-paul@crapouillou.net
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
When running the ARTPEC-8 DWMMC IP version, and a data error interrupt
comes during a data read transfer, there is no guarantee for the data
transfer over interrupt (DTO) to come within the specified data timeout.
This case is handled by the dto_timer handler which will complete the
request with the comment:
/*
* If DTO interrupt does NOT come in sending data state,
* we should notify the driver to terminate current transfer
* and report a data timeout to the core.
*/
But since the ARTPEC-8 DWMMC IP version, supports an extended TMOUT
register which allows longer timeouts than the non ARTPEC-8 version
does, waiting for the dto_timer to complete the request in error cases
may cause the request to take significantly longer time than necessary.
This is specifically true for the failing steps during tuning of a
device.
Fix this by completing the request when the error interrupt comes. Since
this fix is specific for the ARTPEC-8, a quirk is added.
Signed-off-by: Mårten Lindahl <marten.lindahl@axis.com>
Link: https://lore.kernel.org/r/20211220113026.21129-5-marten.lindahl@axis.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Current dw_mci driver supports a TMOUT register which consists of a 24
bit field (TMOUT[31:8]) for the DATA_TIMEOUT. The maximum value of this
field is 0xFFFFFF, which with a 200MHz clock will give a full DRTO of:
0xFFFFFF / 200000000 => ~84 ms
However, the ARTPEC-8 SoC DWMMC IP version has a TMOUT register with an
extended DATA_TIMEOUT field, which supports longer timers for the DRTO.
In this version the DATA_TIMEOUT field is split into two, which with the
same 200MHz clock as above will allow a maximum timeout of:
((TMOUT[10:8] -1) * 0xFFFFFF + TMOUT[31:11] * 8) / 200000000 => ~587 ms
Add driver callbacks for implementation specific data timeout, and
implement callback functions for the ARTPEC-8 SoC.
Signed-off-by: Mårten Lindahl <marten.lindahl@axis.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Link: https://lore.kernel.org/r/20211220113026.21129-4-marten.lindahl@axis.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The ARTPEC-8 SoC has a DWMMC controller that is compatible with the
Exynos 7 version v2.70a. The main differences from Exynos 7 is that it
does not support HS400 and has extended data read timeout.
This patch adds compatibility string "axis,artpec8-dw-mshc" for
ARTPEC-8, and DW_MCI_TYPE_ARTPEC8 is added to the dw_mci_exynos_type.
Signed-off-by: Mårten Lindahl <marten.lindahl@axis.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Link: https://lore.kernel.org/r/20211220113026.21129-3-marten.lindahl@axis.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The ARTPEC-8 SoC has a DWMMC controller that is compatible with the
Exynos 7 version v2.70a. The main differences from Exynos 7 is that it
does not support HS400 and has extended data read timeout.
Add compatibility string "axis,artpec8-dw-mshc" for ARTPEC-8.
Signed-off-by: Mårten Lindahl <marten.lindahl@axis.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Acked-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20211220113026.21129-2-marten.lindahl@axis.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The driver neglects to check the result of platform_get_irq()'s call and
blithely passes the negative error codes to devm_request_threaded_irq()
(which takes *unsigned* IRQ #), causing it to fail with -EINVAL, overriding
an original error code. Stop calling devm_request_threaded_irq() with the
invalid IRQ #s.
Fixes: ed80a13bb4 ("mmc: meson-mx-sdio: Add a driver for the Amlogic Meson8 and Meson8b SoC")
Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru>
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Link: https://lore.kernel.org/r/20211217202717.10041-3-s.shtylyov@omp.ru
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The driver neglects to check the result of platform_get_irq()'s call and
blithely passes the negative error codes to devm_request_threaded_irq()
(which takes *unsigned* IRQ #), causing it to fail with -EINVAL, overriding
an original error code. Stop calling devm_request_threaded_irq() with the
invalid IRQ #s.
Fixes: e4bf1b0970 ("mmc: host: meson-mx-sdhc: new driver for the Amlogic Meson SDHC host")
Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru>
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Link: https://lore.kernel.org/r/20211217202717.10041-2-s.shtylyov@omp.ru
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The "0x" prefix is redundant when # flag is used. It prints "0x0x".
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Mårten Lindahl <marten.lindahl@axis.com>
Link: https://lore.kernel.org/r/20211217150348.GD16611@kili
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
For some reason, <32-bit reads do not work on Apple ARM64 platforms with
these chips (even though they do on other PCIe devices). Issue them as
32-bit reads instead. This is done unconditionally, as it shouldn't hurt
even if not necessary.
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Hector Martin <marcan@marcan.st>
Link: https://lore.kernel.org/r/20211215161045.38843-3-marcan@marcan.st
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
This is required on some Apple ARM64 laptops using this controller.
As is typical on DT platforms, pull these quirks from the device tree
using the standard mmc bindings.
See Documentation/devicetree/bindings/mmc/mmc-controller.yaml
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Hector Martin <marcan@marcan.st>
Link: https://lore.kernel.org/r/20211215161045.38843-2-marcan@marcan.st
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Sparse spits out this following warning:
drivers/mmc/core/queue.c:311:21: warning: incorrect type in assignment (different base types)
drivers/mmc/core/queue.c:311:21: expected int ret
drivers/mmc/core/queue.c:311:21: got restricted blk_status_t [usertype]
drivers/mmc/core/queue.c:314:21: warning: incorrect type in assignment (different base types)
drivers/mmc/core/queue.c:314:21: expected int ret
drivers/mmc/core/queue.c:314:21: got restricted blk_status_t [usertype]
drivers/mmc/core/queue.c:336:16: warning: incorrect type in return expression (different base types)
drivers/mmc/core/queue.c:336:16: expected restricted blk_status_t
drivers/mmc/core/queue.c:336:16: got int [assigned] ret
ret is only used for blk_status_t types, so make it that type.
Signed-off-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Link: https://lore.kernel.org/r/20211215011336.194089-1-joel@jms.id.au
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Use feedback clock for HS200 mode, as for SDR104.
The HS200 mode can be enabled through DT by using mmc-hs200-1_8v.
It is possible to use it on STM32MP13, but not STM32MP15 platforms.
Signed-off-by: Ludovic Barre <ludovic.barre@foss.st.com>
Signed-off-by: Yann Gautier <yann.gautier@foss.st.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20211215141727.4901-5-yann.gautier@foss.st.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The variant->f_max is dependent on the IP, not on the SoC where it is
embedded. Set the max frequency of its source clock to 267MHz.
The frequency used will be limited by the IOs max frequency, set in the
SoC device tree.
Signed-off-by: Yann Gautier <yann.gautier@foss.st.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20211215141727.4901-3-yann.gautier@foss.st.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The change is only hardware, and does not need driver change:
Added hardware flow control during transmit packet with variable delay.
The new id is then added to the ids list structure.
Signed-off-by: Yann Gautier <yann.gautier@foss.st.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20211215141727.4901-2-yann.gautier@foss.st.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
During test campaign, and especially after several unbind/bind sequences,
it has been seen that the SD-card on SDMMC1 thread could freeze.
The freeze always appear on a CMD23 following a CMD19.
Checking SDMMC internal registers shows that the tuning command (CMD19)
has failed.
The freeze is then due to the delay block involved in the tuning sequence.
To correct this, clear the delay block register DLYB_CR register after
the tuning commands.
Signed-off-by: Christophe Kerello <christophe.kerello@foss.st.com>
Signed-off-by: Yann Gautier <yann.gautier@foss.st.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Fixes: 1103f807a3 ("mmc: mmci_sdmmc: Add execute tuning with delay block")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20211215141727.4901-4-yann.gautier@foss.st.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Although this compatible is not used in kernel, as we use the common
MMCI driver, it is used by bootloaders. The U-Boot driver was merged
before the kernel driver and uses this compatible.
To avoid issues when aligning device tree files between kernel and
boot loader, the ST dedicated compatible is added to bindings file.
Signed-off-by: Yann Gautier <yann.gautier@foss.st.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20211210091834.28958-1-yann.gautier@foss.st.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Some ARM64 Exynos SoCs have MCT timer block, e.g. Exynos850 and
Exynos5433. CLKSRC_EXYNOS_MCT option is not visible unless COMPILE_TEST
is enabled. Select CLKSRC_EXYNOS_MCT option for ARM64 ARCH_EXYNOS like
it's done in arch/arm/mach-exynos/Kconfig, to enable MCT timer support
for ARM64 Exynos SoCs.
Even though ARM architected timer is available on all ARM64 SoCs, and
used for managing timer hardware and clock source events, MCT timer
still can be used as a wakeup source, as stated in commitae460fd9164b
("clocksource/drivers/exynos_mct: Prioritise Arm arch timer on arm64").
It's also nice to be able to test available MCT IP-core.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
Link: https://lore.kernel.org/r/20211101193531.15078-3-semen.protsenko@linaro.org
Link: https://lore.kernel.org/r/20211220165004.17005-2-krzysztof.kozlowski@canonical.com'
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
The Fresco Logic FL1100 controller needs the TRUST_TX_LENGTH quirk like
other Fresco controllers, but should not have the BROKEN_MSI quirks set.
BROKEN_MSI quirk causes issues in detecting usb drives connected to docks
with this FL1100 controller.
The BROKEN_MSI flag was apparently accidentally set together with the
TRUST_TX_LENGTH quirk
Original patch went to stable so this should go there as well.
Fixes: ea0f69d821 ("xhci: Enable trust tx length quirk for Fresco FL11 USB controller")
Cc: stable@vger.kernel.org
cc: Nikolay Martynov <mar.kolya@gmail.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20211221112825.54690-2-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The variable rc is being initialized with a value that is never read, it
is being updated later on. The assignment is redundant and thus remove
it.
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Link: https://lore.kernel.org/r/20211126221848.1125321-1-colin.i.king@gmail.com
Add a new xfer parameter to mark_txdone transport operation which enables
the SCMI core to optionally pass back into the transport layer a reference
to the xfer descriptor that is being handled.
Link: https://lore.kernel.org/r/20211220195646.44498-9-cristian.marussi@arm.com
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Add a Kernel configuration option to enable SCMI SMC transport atomic
mode operation for selected SCMI transactions and leave it as default
disabled.
Substitute mutex usages with busy-waiting and declare smc transport as
.atomic_enabled if such Kernel configuration option is enabled.
Link: https://lore.kernel.org/r/20211220195646.44498-8-cristian.marussi@arm.com
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
An SCMI transport can be configured as .atomic_enabled in order to signal
to the SCMI core that all its TX path is executed in atomic context and
that, when requested, polling mode should be used while waiting for command
responses.
When a specific platform configuration had properly configured such a
transport as .atomic_enabled, the SCMI core will also take care not to
sleep in the corresponding RX path while waiting for a response if that
specific command transaction was requested as atomic using polling mode.
Asynchronous commands should not be used in an atomic context and so a
warning is emitted if polling was requested for an asynchronous command.
Add also a method to check, from the SCMI drivers, if the underlying SCMI
transport is currently configured to support atomic transactions: this will
be used by upper layers to determine if atomic requests can be supported at
all on this SCMI instance.
Link: https://lore.kernel.org/r/20211220195646.44498-7-cristian.marussi@arm.com
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Declare each OPTEE SCMI channel as not having a completion_irq so as to
enable polling mode and then enable also .sync_cmds_completed_on_ret flag
in the OPTEE transport descriptor so that real polling is itself
effectively bypassed on the rx path: once the optee command invocation has
successfully returned the core will directly fetch the response from the
shared memory area.
Remove OPTEE SCMI transport specific .poll_done callback support since
real polling is effectively bypassed when .sync_cmds_completed_on_ret is
set.
Add OPTEE SCMI transport specific .mark_txdone callback support in order to
properly handle channel locking along the tx path.
Link: https://lore.kernel.org/r/20211220195646.44498-6-cristian.marussi@arm.com
Cc: Etienne Carriere <etienne.carriere@linaro.org>
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Enable sync_cmds_completed_on_ret in the SMC transport descriptor and
remove SMC specific .poll_done callback support since polling is bypassed
when sync_cmds_completed_on_ret is set.
Link: https://lore.kernel.org/r/20211220195646.44498-5-cristian.marussi@arm.com
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Add a flag to let the transport signal to the core if its handling of sync
command implies that, after .send_message has returned successfully, the
requested command can be assumed to be fully and completely executed on
SCMI platform side so that any possible response value is already
immediately available to be retrieved by a .fetch_response: in other words
the polling phase can be skipped in such a case and the response values
accessed straight away.
Note that all of the above applies only when polling mode of operation was
selected by the core: if instead a completion IRQ was found to be available
the normal response processing path based on completions will still be
followed.
Link: https://lore.kernel.org/r/20211220195646.44498-4-cristian.marussi@arm.com
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
When a completion irq is available use it and delegate command completion
handling to the core SCMI completion mechanism.
If no completion irq is available revert to polling, using the core common
polling machinery.
Link: https://lore.kernel.org/r/20211220195646.44498-3-cristian.marussi@arm.com
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
SCMI communications along TX channels can optionally be provided of a
completion interrupt; when such interrupt is not available, command
transactions should rely on polling, where the SCMI core takes care to
repeatedly evaluate the transport-specific .poll_done() function, if
available, to determine if and when a request was fully completed or
timed out.
Such mechanism is already present and working on a single transfer base:
SCMI protocols can indeed enable hdr.poll_completion on specific commands
ahead of each transfer and cause that transaction to be handled with
polling.
Introduce a couple of flags to be able to enforce such polling behaviour
globally at will:
- scmi_desc.force_polling: to statically switch the whole transport to
polling mode.
- scmi_chan_info.no_completion_irq: to switch a single channel dynamically
to polling mode if, at runtime, is determined that no completion
interrupt was available for such channel.
Link: https://lore.kernel.org/r/20211220195646.44498-2-cristian.marussi@arm.com
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
The shared area is a DMA memory allocated in the host and
mapped so that the host and the CSME firmware can
exchange data. It is mapped through a dedicated PCI device
that is driven by the mei bus driver.
The bus driver is in charge of allocating and mapping this
memory. It also needs to configure the CSME firmware with
a specific set of commands, so that the CSME firmware will
know that this memory is meant to be used by its internal
WLAN module.
For this, the CSME firmware first needs to completely
initialize its WLAN module and only then get the mapping
request.
The problem is that the mei bus enumeration completes
before the WLAN is completely ready. This means that
the WLAN module's initialization is racing with iwlmei's
allocation and mapping flow.
Testing showed a problem in resume flows where iwlmei
was too fast and the DMA mapping failed.
Add a delay to avoid this. This is still racy, but our
measurements showed that we have a good margin and we
should now be safe.
Fixes: 2da4366f9e ("iwlwifi: mei: add the driver to allow cooperation with CSME")
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211220142940.8b6279e3d0be.I6fe128b0b86149a85535104822c8355b367887c8@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
