- 29 Aug, 2022 34 commits
-
-
Krzysztof Kozlowski authored
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
-
Krzysztof Kozlowski authored
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. Signed-off-by:
-
Krzysztof Kozlowski authored
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 authored
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. Signed-off-by:
-
Krzysztof Kozlowski authored
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 authored
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 authored
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. Signed-off-by:
-
Krzysztof Kozlowski authored
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 authored
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 authored
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. Signed-off-by:
-
Krzysztof Kozlowski authored
TCSR syscon node should come with dedicated compatible. Signed-off-by:
-
Krzysztof Kozlowski authored
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 authored
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. Signed-off-by:
-
Krzysztof Kozlowski authored
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 authored
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. Signed-off-by:
-
Krzysztof Kozlowski authored
Document existing (MSM8996, SC7280) and new compatibles for TCSR syscon registers (QCS404, SC7180, SDM630, SDM845, SM8150, MSM8998). Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Geert Uytterhoeven authored
"make dtbs_check" says: bias-disable: boolean property with value b'\x00\x00\x00\x00' Fix this by dropping the offending value. Fixes: be497abe ("arm64: dts: qcom: Add support for Xiaomi Mi Mix2s") Signed-off-by:Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by:
Caleb Connolly <caleb@connolly.tech> Signed-off-by:
-
Lin, Meng-Bo authored
reg_vdd_tsp: regulator-vdd-tsp is actually used as an analog regulator for touchscreen on all of a2015 and e2015 devices. Rename it into reg_vdd_tsp_a: regulator-vdd-tsp-a to reduce confusion. Signed-off-by:
Lin, Meng-Bo <linmengbo0689@protonmail.com> Signed-off-by:
-
Lin, Meng-Bo authored
On the Samsung Galaxy E5 and E7 the touch key is supplied by a single fixed regulator (enabled via GPIO 97) that supplies both MCU and LED. Add it to the device tree. Signed-off-by:
-
Lin, Meng-Bo authored
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 authored
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:
-
Lin, Meng-Bo authored
Document the new samsung,e5/e7/grandmax device tree bindings used in their device trees. Signed-off-by:
-
Yunlong Jia authored
The difference between sku6 and sku4 is that there is no esim The different SKUs are: LTE with physical SIM _and_ eSIM LTE with only a physical SIM WiFi only Both sku4 and sku6 are LTE SKUs. One has the eSIM stuffed and one doesn't. There is a single shared device tree for the two. Signed-off-by:
Yunlong Jia <yunlong.jia@ecs.corp-partner.google.com> Reviewed-by:
Douglas Anderson <dianders@chromium.org> Acked-by:
-
Yunlong Jia authored
SKU6 is LTE(w/o eSIM)+WIFI+Parade Signed-off-by:
-
Konrad Dybcio authored
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 authored
Add and configure the SDHCI host responsible for (mostly) SD Card and its corresponding pins' sleep states. Signed-off-by:
-
Konrad Dybcio authored
Fix up the camera region (cross-referenced different vendors' msm-5.10 drops, 9f500000 is the default location for SM8450) and reserve the second chunk occupied by xbl_sc. Signed-off-by:
-
Konrad Dybcio authored
Document the compatible for the PDX223 device. Signed-off-by:
-
Krzysztof Kozlowski authored
Add a MSM8998-specific SDCC compatible, because using only a generic qcom,sdhci-msm-v4 fallback is deprecated. Signed-off-by:
-
Krzysztof Kozlowski authored
The qcom,msm-id is an uint32 matrix, so a list of tuples. Signed-off-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by:
-
Dmitry Baryshkov authored
As we are converting this platform to use DT clock bindings, add clocks and clock-names properties to the MMCC device tree node. Reviewed-by:
Marijn Suijten <marijn.suijten@somainline.org> Signed-off-by:
-
Luca Weiss authored
Add all the different NoC providers that are found in SM6350 and populate different nodes that use the interconnect properties. Signed-off-by:
Luca Weiss <luca.weiss@fairphone.com> Signed-off-by:
-
Dmitry Baryshkov authored
Replace deprecated perst-gpio and wake-gpio properties with up-to-date perst-gpios and wake-gpios in the Qualcomm device trees. Acked-by:
-
Dmitry Baryshkov authored
Qualcomm PCIe devices are not really compatible with the snps,dw-pcie. Unlike the generic IP core, they have special requirements regarding enabling clocks, toggling resets, using the PHY, etc. This is not to mention that platform snps-dw-pcie driver expects to find two IRQs declared, while Qualcomm platforms use just one. Acked-by:
-
- 17 Aug, 2022 6 commits
-
-
Johan Hovold authored
Add support for the alternate (second-source) touchpad found on some X13s laptops. Note that alternate touchpad is kept disabled for now. The boot firmware should determine which device is actually populated and enable only the corresponding node. Signed-off-by:
Johan Hovold <johan+linaro@kernel.org> Reviewed-by:
Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20220805092317.4985-8-johan+linaro@kernel.org
-
Johan Hovold authored
The touchpad and keyboard can wake the system from suspend so declare them as wakeup sources. Signed-off-by:
-
Johan Hovold authored
The HID pin configurations belong in the HID nodes rather than i2c bus node. Signed-off-by:
-
Johan Hovold authored
The (optional) touchscreen interrupt line has an external pull-up so disable the internal one as is done for the keyboard and touchpad. Signed-off-by:
-
Johan Hovold authored
The touchpad and keyboard can wake the system from suspend so declare them as wakeup sources. Signed-off-by:
-
Johan Hovold authored
The HID pin configurations belong in the HID nodes rather than i2c bus node. Signed-off-by:
-
