Add the registers and clock for the Inline Crypto Engine (ICE) to the
device tree node for the UFS host controller on sm8450. This makes
ufs_qcom support inline encryption when CONFIG_SCSI_UFS_CRYPTO=y.
The address and size of the register range, and the minimum and maximum
frequency of the ICE core clock, all match the values used downstream.
I've validated this on an SM8450 HDK using the 'encrypt' group of
xfstests on ext4 with MOUNT_OPTIONS="-o inlinecrypt".
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20220826071244.185584-1-ebiggers@kernel.org
There's still a thermal zone using pm6150_adc in the pm6150.dtsi file,
pm6150_thermal. It's not super obvious because it indirectly uses the
adc through an iio channel in pm6150_temp. Let's keep this enabled on
lazor and coachz so that reading the temperature of the pm6150_thermal
zone continues to work. Otherwise we get -EINVAL when reading the zone,
and I suspect the PMIC temperature trip doesn't work properly so we
don't shutdown when the PMIC overheats.
Cc: Matthias Kaehlcke <mka@chromium.org>
Fixes: b8d1e3d334 ("arm64: dts: qcom: sc7180-trogdor: Delete ADC config for unused thermistors")
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20220827004901.511543-1-swboyd@chromium.org
Add LEDs found on the Xiaomi MSM8996 devices. The devices share
a status RGB LED mounted on the front, as well as a PWM-driven
IR LED for remote control (sometimes known as an IR blaster).
The Mi Note 2 has an additional pair of white LEDs used as backlights
for the touchkeys driven by the PM8994 LPG block.
Signed-off-by: Yassine Oudjana <y.oudjana@protonmail.com>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20220728180120.97968-1-y.oudjana@protonmail.com
The TCSR mutex bindings allow device to be described only with address
space (so it uses MMIO, not syscon regmap). This seems reasonable as
TCSR mutex is actually a dedicated IO address space and it also fixes DT
schema checks:
qcom/sm8150-mtp.dtb: hwlock: 'reg' is a required property
qcom/sm8150-mtp.dtb: hwlock: 'syscon' does not match any of the regexes: 'pinctrl-[0-9]+'
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20220819083209.50844-17-krzysztof.kozlowski@linaro.org
The TCSR mutex bindings allow device to be described only with address
space (so it uses MMIO, not syscon regmap). This seems reasonable as
TCSR mutex is actually a dedicated IO address space and it also fixes DT
schema checks:
qcom/sdm636-sony-xperia-ganges-mermaid.dtb: hwlock: 'reg' is a required property
qcom/sdm636-sony-xperia-ganges-mermaid.dtb: hwlock: 'syscon' does not match any of the regexes: 'pinctrl-[0-9]+'
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20220819083209.50844-15-krzysztof.kozlowski@linaro.org
The TCSR mutex bindings allow device to be described only with address
space (so it uses MMIO, not syscon regmap). This seems reasonable as
TCSR mutex is actually a dedicated IO address space and it also fixes DT
schema checks:
qcom/qcs404-evb-4000.dtb: hwlock: 'reg' is a required property
qcom/qcs404-evb-4000.dtb: hwlock: 'syscon' does not match any of the regexes: 'pinctrl-[0-9]+'
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20220819083209.50844-13-krzysztof.kozlowski@linaro.org
The TCSR mutex bindings allow device to be described only with address
space (so it uses MMIO, not syscon regmap). This seems reasonable as
TCSR mutex is actually a dedicated IO address space and it also fixes DT
schema checks:
qcom/sdm845-shift-axolotl.dtb: hwlock: 'reg' is a required property
qcom/sdm845-shift-axolotl.dtb: hwlock: 'syscon' does not match any of the regexes: 'pinctrl-[0-9]+'
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20220819083209.50844-12-krzysztof.kozlowski@linaro.org
The TCSR halt regs are next to TCSR mutex (in one address block called
TCSR_MUTEX), so before converting the TCSR mutex into device with
address space, we need to split the halt regs to its own syscon device.
This also describes more accurately the devices and their IO address
space, and allows to remove incorrect syscon compatible from TCSR mutex:
qcom/sc7280-herobrine-crd.dtb: hwlock@1f40000: compatible: ['qcom,tcsr-mutex', 'syscon'] is too long
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20220819083209.50844-10-krzysztof.kozlowski@linaro.org
The TCSR mutex bindings allow device to be described only with address
space (so it uses MMIO, not syscon regmap). This seems reasonable as
TCSR mutex is actually a dedicated IO address space and it also fixes DT
schema checks:
qcom/sc7180-trogdor-wormdingler-rev1-inx.dtb: hwlock: 'reg' is a required property
qcom/sc7180-trogdor-wormdingler-rev1-inx.dtb: hwlock: 'syscon' does not match any of the regexes: 'pinctrl-[0-9]+'
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20220819083209.50844-9-krzysztof.kozlowski@linaro.org
The TCSR mutex bindings allow device to be described only with address
space (so it uses MMIO, not syscon regmap). This seems reasonable as
TCSR mutex is actually a dedicated IO address space and it also fixes DT
schema checks:
qcom/msm8998-asus-novago-tp370ql.dtb: hwlock: 'reg' is a required property
qcom/msm8998-asus-novago-tp370ql.dtb: hwlock: 'syscon' does not match any of the regexes: 'pinctrl-[0-9]+'
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20220819083209.50844-6-krzysztof.kozlowski@linaro.org
The TCSR mutex bindings allow device to be described only with address
space (so it uses MMIO, not syscon regmap). This seems reasonable as
TCSR mutex is actually a dedicated IO address space and it also fixes DT
schema checks:
qcom/msm8996-xiaomi-natrium.dtb: hwlock: 'reg' is a required property
qcom/msm8996-xiaomi-natrium.dtb: hwlock: 'syscon' does not match any of the regexes: 'pinctrl-[0-9]+'
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20220819083209.50844-4-krzysztof.kozlowski@linaro.org
After adding all necessary support for MSM8916 SMP/cpuidle without PSCI
on ARM32, build the Samsung Galaxy E5/E7/Grand Max device trees from the
arm64 tree together with the ARM32 include to allow booting this device on
ARM32.
The approach to include device tree files from other architectures is
inspired from e.g. the Raspberry Pi (bcm2711-rpi-4-b.dts) where this is
used to build the device tree for both ARM32 and ARM64.
Signed-off-by: Lin, Meng-Bo <linmengbo0689@protonmail.com>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20220724095413.14135-1-linmengbo0689@protonmail.com
Samsung Galaxy E5, E7 and Grand Max are smartphones using the MSM8916 SoC
released in 2015.
e2015 and a2015 are similar, with some differences in accelerometer,
MUIC and Vibrator. The common parts are shared in
msm8916-samsung-a2015-common.dtsi to reduce duplication.
Add a common device tree for with initial support for:
- GPIO keys
- GPIO LEDs for Grand Max
- Regulator haptic
- Hall sensor (except Grand Max)
- SDHCI (internal and external storage)
- USB Device Mode
- UART (on USB connector via the SM5504 MUIC)
- WCNSS (WiFi/BT)
- Regulators
- S3FWRN5 NFC (except Grand Max)
The three devices (and all other variants of E5/E7/Grand Max released in
2015) are very similar, with some differences in display, touchscreen,
sensors and NFC. The common parts are shared in
msm8916-samsung-e2015-common.dtsi to reduce duplication.
Unfortunately, some E5/E7/Grand Max were released with outdated 32-bit
only firmware and never received any update from Samsung. Since the 32-bit
TrustZone firmware is signed there seems to be no way currently to
actually boot this device tree on arm64 Linux on those variants at the
moment.
However, it is possible to use this device tree by compiling an ARM32
kernel instead. The device tree can be easily built on ARM32 with
an #include and it works really well there. To avoid confusion for others
it is still better to add this device tree on arm64. Otherwise it's easy
to forget to update this one when making some changes that affect all
MSM8916 devices.
Maybe someone finds a way to boot ARM64 Linux on those device at some
point. In this case I expect that this device tree can be simply used
as-is.
Co-developed-by: Stephan Gerhold <stephan@gerhold.net>
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Signed-off-by: Lin, Meng-Bo <linmengbo0689@protonmail.com>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20220724095400.14081-1-linmengbo0689@protonmail.com
Add support for Sony Xperia 1 IV, a.k.a PDX223. This device is a part
of the SoMC SM8450 Nagara platform and currently it is the only
device based on that board, so no -common DTSI is created until (if?)
other Nagara devices appear.
This commit brings support for:
* SD Card
* USB (*including SuperSpeed*)
* ADSP/CDSP/SLPI (modem remains untested for now)
* Most regulators (some GPIO-enabled ones require PMIC GPIOs but
trying to access any SPMI device crashes the device..)
* Part of I2C-connected peripherals (notably no touch due to a
driver bug)
* PCIe0 (PCIe1 is unused)
Do note display via simplefb is not supported, as the display is blanked
upon exiting XBL.
To create a working boot image, you need to run:
cat arch/arm64/boot/Image.gz arch/arm64/boot/dts/qcom/sm8450-sony-xperia-\
nagara-pdx223.dtb > .Image.gz-dtb
mkbootimg \
--kernel .Image.gz-dtb \
--ramdisk some_initrd.img \
--pagesize 4096 \
--base 0x0 \
--kernel_offset 0x8000 \
--ramdisk_offset 0x1000000 \
--tags_offset 0x100 \
--cmdline "SOME_CMDLINE" \
--dtb_offset 0x1f00000 \
--header_version 1 \
--os_version 12 \
--os_patch_level 2022-06 \ # or newer
-o boot.img-sony-xperia-pdx223
Then, you need to flash it on the device and get rid of all the
vendor_boot/dtbo mess:
// You have to either pull vbmeta{"","_system"} from
// /dev/block/bootdevice/by-name/ or build one as a part of AOSP build process
fastboot --disable-verity --disable-verification flash vbmeta vbmeta.img
fastboot --disable-verity --disable-verification flash vbmeta_system \
vbmeta_system.img
fastboot flash boot boot.img-sony-xperia-pdx223
fastboot erase vendor_boot
fastboot erase recovery
fastboot flash dtbo emptydtbo.img
fastboot reboot
Where emptydtbo.img is a tiny file that consists of 2 bytes (all zeroes), doing
a "fastboot erase" won't cut it, the bootloader will go crazy and things will
fall apart when it tries to overlay random bytes from an empty partition onto a
perfectly good appended DTB.
Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20220714123406.1919836-5-konrad.dybcio@somainline.org
