- 21 Apr, 2024 27 commits
-
-
Manivannan Sadhasivam authored
On Qcom SoCs, the PCIe host bridge is connected to a single PCIe bridge for each controller instance. Hence, add a node to represent the bridge. Signed-off-by:
Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Reviewed-by:
Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20240321-pcie-qcom-bridge-dts-v2-13-1eb790c53e43@linaro.orgSigned-off-by:
Bjorn Andersson <andersson@kernel.org>
-
Manivannan Sadhasivam authored
On Qcom SoCs, the PCIe host bridge is connected to a single PCIe bridge for each controller instance. Hence, add a node to represent the bridge. Signed-off-by:
-
Manivannan Sadhasivam authored
On Qcom SoCs, the PCIe host bridge is connected to a single PCIe bridge for each controller instance. Hence, add a node to represent the bridge. Signed-off-by:
-
Manivannan Sadhasivam authored
On Qcom SoCs, the PCIe host bridge is connected to a single PCIe bridge for each controller instance. Hence, add a node to represent the bridge. Signed-off-by:
-
Manivannan Sadhasivam authored
On Qcom SoCs, the PCIe host bridge is connected to a single PCIe bridge for each controller instance. Hence, add a node to represent the bridge. While at it, let's remove the bridge properties from board dts as they are now redundant. Signed-off-by:
-
Manivannan Sadhasivam authored
On Qcom SoCs, the PCIe host bridge is connected to a single PCIe bridge for each controller instance. Hence, add a node to represent the bridge. Signed-off-by:
-
Manivannan Sadhasivam authored
On Qcom SoCs, the PCIe host bridge is connected to a single PCIe bridge for each controller instance. Hence, add a node to represent the bridge. Reviewed-by:
Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by:
-
Manivannan Sadhasivam authored
On Qcom SoCs, the PCIe host bridge is connected to a single PCIe bridge for each controller instance. Hence, add a node to represent the bridge. Reviewed-by:
-
Manivannan Sadhasivam authored
On Qcom SoCs, the PCIe host bridge is connected to a single PCIe bridge for each controller instance. Hence, add a node to represent the bridge. Reviewed-by:
-
Manivannan Sadhasivam authored
On Qcom SoCs, the PCIe host bridge is connected to a single PCIe bridge for each controller instance. Hence, add a node to represent the bridge. Signed-off-by:
-
Manivannan Sadhasivam authored
On Qcom SoCs, the PCIe host bridge is connected to a single PCIe bridge for each controller instance. Hence, add a node to represent the bridge. Signed-off-by:
-
Manivannan Sadhasivam authored
On Qcom SoCs, the PCIe host bridge is connected to a single PCIe bridge for each controller instance. Hence, add a node to represent the bridge. Signed-off-by:
-
Manivannan Sadhasivam authored
On Qcom SoCs, the PCIe host bridge is connected to a single PCIe bridge for each controller instance. Hence, add a node to represent the bridge. Signed-off-by:
-
Caleb Connolly authored
This regulator is responsible not just for the PCIe 3.3v rail, but also for 5v VBUS on the left USB port. There is currently no way to correctly model this dependency on the USB controller, as a result when the PCIe driver is not available (for example when in the initramfs) USB is non-functional. Until support is added for modelling this property (likely by referencing it as a supply under a usb-connector node), let's just make it always on. We don't target any power constrained usecases and this regulator is required for USB to function correctly. Fixes: 3f72e2d3 ("arm64: dts: qcom: Add Dragonboard 845c") Suggested-by:
Bjorn Andersson <quic_bjorande@quicinc.com> Signed-off-by:
Caleb Connolly <caleb.connolly@linaro.org> Reviewed-by:
-
Udipto Goswami authored
Update SNPS Phy tuning parameters for sm8450 QRD platform to fix electrical compliance failures. Signed-off-by:
Udipto Goswami <quic_ugoswami@quicinc.com> Reviewed-by:
-
Konrad Dybcio authored
Replace the bogus capacity-dmips-mhz values and add the measured dynamic-power-coefficient values. The power numbers were measured by matters much more precise than the laggy and cache-y pmic_glink battery data, though the reported values were only accurate to 10mA. But that shouldn't be an issue, especially for the fat and power-hungry X1Cs and given that *each SoC unit* has somewhat different frequency-voltage maps. X1C cluster: 940 kHz, 596 mV, 434 mW, 663 Cx 1056 kHz, 612 mV, 463 mW, 565 Cx 1171 kHz, 628 mV, 502 mW, 574 Cx 1286 kHz, 644 mV, 534 mW, 540 Cx 1401 kHz, 660 mV, 580 mW, 550 Cx 1516 kHz, 688 mV, 630 mW, 529 Cx 1632 kHz, 712 mV, 690 mW, 533 Cx 1747 kHz, 728 mV, 722 mW, 503 Cx 1862 kHz, 752 mV, 787 mW, 504 Cx 1977 kHz, 776 mV, 855 mW, 503 Cx 2073 kHz, 792 mV, 913 mW, 504 Cx 2169 kHz, 812 mV, 989 mW, 514 Cx 2284 kHz, 856 mV, 1250 mW, 611 Cx 2400 kHz, 900 mV, 1441 mW, 626 Cx 2496 kHz, 932 mV, 1600 mW, 636 Cx 2592 kHz, 964 mV, 1790 mW, 653 Cx 2688 kHz, 1000 mV, 2020 mW, 673 Cx 2803 kHz, 1040 mV, 2292 mW, 687 Cx 2899 kHz, 1076 mV, 2572 mW, 706 Cx 2995 kHz, 1108 mV, 2850 mW, 721 Cx A78C cluster: 403 kHz, 576 mV, 180 mW, 584 Cx 499 kHz, 576 mV, 200 mW, 605 Cx 595 kHz, 576 mV, 220 mW, 612 Cx 691 kHz, 576 mV, 230 mW, 541 Cx 806 kHz, 600 mV, 250 mW, 471 Cx 902 kHz, 620 mV, 270 mW, 444 Cx 1017 kHz, 640 mV, 290 mW, 409 Cx 1113 kHz, 652 mV, 310 mW, 401 Cx 1209 kHz, 668 mV, 320 mW, 363 Cx 1324 kHz, 700 mV, 490 mW, 600 Cx 1440 kHz, 724 mV, 523 mW, 554 Cx 1555 kHz, 800 mV, 660 mW, 558 Cx 1670 kHz, 800 mV, 780 mW, 639 Cx 1785 kHz, 804 mV, 910 mW, 711 Cx 1881 kHz, 824 mV, 941 mW, 663 Cx 1996 kHz, 856 mV, 980 mW, 601 Cx 2112 kHz, 880 mV, 1020 mW, 559 Cx 2227 kHz, 908 mV, 1090 mW, 535 Cx 2342 kHz, 932 mV, 1230 mW, 552 Cx 2438 kHz, 956 mV, 1351 mW, 559 Cx Signed-off-by:
-
Ling Xu authored
Add three missing cDSP fastrpc compute-cb nodes for the SM8650 SoC. Signed-off-by:
Ling Xu <quic_lxu5@quicinc.com> Link: https://lore.kernel.org/r/20240319032816.27070-1-quic_lxu5@quicinc.comSigned-off-by:
-
Neil Armstrong authored
Add path of the GPU firmware for the SM8650-QRD board Reviewed-by:
Jun Nie <jun.nie@linaro.org> Link: https://lore.kernel.org/r/20240318-topic-sm8650-gpu-v4-2-206eb0d31694@linaro.orgSigned-off-by:
-
Neil Armstrong authored
Add GPU nodes for the SM8650 platform. Signed-off-by:
-
Danila Tikhonov authored
Add device node defining LPG/PWM block on PM6150L PMIC chip. Signed-off-by:
Danila Tikhonov <danila@jiaxyga.com> Reviewed-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20240306172710.59780-3-danila@jiaxyga.comSigned-off-by:
-
Raymond Hackley authored
Add subnode usb_con: extcon for SM5502 / SM5504 MUIC, which will be used for RT5033 charger. Signed-off-by:
Raymond Hackley <raymondhackley@protonmail.com> Link: https://lore.kernel.org/r/20240215122605.3817-1-raymondhackley@protonmail.comSigned-off-by:
-
Jianhua Lu authored
arm64: dts: qcom: sm8250-xiaomi-elish: set pm8150b_vbus regulator-min-microamp and regulator-max-microamp Fix the dtb check warnings: sm8250-xiaomi-elish-boe.dtb: usb-vbus-regulator@1100: 'regulator-min-microamp' is a required property sm8250-xiaomi-elish-boe.dtb: usb-vbus-regulator@1100: 'regulator-max-microamp' is a required property Fixes: 69652787 ("arm64: dts: qcom: sm8250-xiaomi-elish: Add pm8150b type-c node and enable usb otg") Signed-off-by:
Jianhua Lu <lujianhua000@gmail.com> Reviewed-by:
-
Neil Armstrong authored
The MDP/DPU device is not disabled by default, so there is not point in enabling it in the board DTS file. Signed-off-by:
-
Krzysztof Kozlowski authored
Soc node has ranges, thus it must have an unit address. This fixes W=1 dtc warning: sdx75.dtsi:399.11-736.4: Warning (unit_address_vs_reg): /soc: node has a reg or ranges property, but no unit name Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by:
-
Luca Weiss authored
Add the node for the DisplayPort controller found on the SM6350 SoC. Reviewed-by:
Luca Weiss <luca.weiss@fairphone.com> Reviewed-by:
-
Komal Bajaj authored
Enable the ADSP, CDSP and WPSS that are found on qcs6490-rb3gen2. Signed-off-by:
Komal Bajaj <quic_kbajaj@quicinc.com> Reviewed-by:
-
Komal Bajaj authored
Enable the ADSP, CDSP, MPSS and WPSS that are found on the SoC. Signed-off-by:
-
- 20 Apr, 2024 11 commits
-
-
Dmitry Baryshkov authored
Define the USB-C orientation GPIOs so that the USB-C ports orientation is known without having to resort to the altmode notifications. Signed-off-by:
-
Dmitry Baryshkov authored
Define the USB-C orientation GPIOs so that the USB-C ports orientation is known without having to resort to the altmode notifications. Signed-off-by:
-
Dmitry Baryshkov authored
Define the USB-C orientation GPIO so that the USB-C port orientation is known without having to resort to the altmode notifications. Signed-off-by:
-
Dmitry Baryshkov authored
Define the USB-C orientation GPIO so that the USB-C port orientation is known without having to resort to the altmode notifications. Signed-off-by:
-
Dmitry Baryshkov authored
The orientation GPIOs are not limited to sm8450/sm8550/x1e8000 platforms. Allow corresponding property to be used on all Qualcom platforms. Fixes: 65682407 ("dt-bindings: soc: qcom: qcom,pmic-glink: add a gpio used to determine the Type-C port plug orientation") Signed-off-by:
Krzysztof Kozlowski <krzk@kernel.org> Reviewed-by:
-
Luca Weiss authored
Define the USB-C orientation GPIOs so that the USB-C ports orientation is known without having to resort to the altmode notifications. On PCB level this is the signal from PM7250B (pin CC_OUT) which is called USB_PHY_PS. Signed-off-by:
-
Umang Chheda authored
Without explicitly specifying names for the regulators they are named based on the DeviceTree node name. This results in multiple regulators with the same name, making it impossible to reason debug prints and regulator_summary. Signed-off-by:
Umang Chheda <quic_uchheda@quicinc.com> Link: https://lore.kernel.org/r/20240412123237.2633000-1-quic_uchheda@quicinc.comSigned-off-by:
-
Volodymyr Babchuk authored
Voltage regulator L13C is used by SD card IO interface. In order to support UHS modes, IO interface voltage needs to be set to 1.8V. This patch extends minimum voltage range of L13C regulator to allow this. Signed-off-by:
Volodymyr Babchuk <volodymyr_babchuk@epam.com> Fixes: 0deb2624 ("arm64: dts: qcom: sa8155p-adp: Add support for uSD card") Suggested-by:
Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20240412190310.1647893-2-volodymyr_babchuk@epam.comSigned-off-by:
-
Abel Vesa authored
The data-lanes are a property of the out remote endpoint, so move them from mdss_dp3 to the mdss_dp3_out. Also add the link-frequencies to mdss_dp3_out and make sure to include all frequencies. Fixes: f9a9c114 ("arm64: dts: qcom: x1e80100-qcp: Enable more support") Reviewed-by:
Abel Vesa <abel.vesa@linaro.org> Reviewed-by:
-
Abel Vesa authored
The data-lanes are a property of the out remote endpoint, so move them from mdss_dp3 to the mdss_dp3_out. Also add the link-frequencies to mdss_dp3_out and make sure to include all frequencies. Fixes: d7e03cce ("arm64: dts: qcom: x1e80100-crd: Enable more support") Reviewed-by:
-
Abel Vesa authored
The link-frequencies belong in mdss_dp3_out. Drop them from mdss_dp3_in. Fixes: 1940c25e ("arm64: dts: qcom: x1e80100: Add display nodes") Reviewed-by:
-
- 16 Apr, 2024 2 commits
-
-
Konrad Dybcio authored
Add support for Sony Xperia 1 V, a.k.a PDX234. This device is a part of the SoMC SM8550 Yodo platform. This commit brings support for: * Remoteprocs (sans modem for now) * Flash LED (the notification LED is gone :((((() * SD Card * USB (*including SuperSpeed*) + PMIC_GLINK (it's funky, requires a replug with an cable flip sometimes..) * Most regulators * 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/sm8550-sony-xperia-\ yodo-pdx234.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 2 \ -o boot.img-sony-xperia-pdx234 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-pdx234 fastboot erase vendor_boot fastboot erase recovery fastboot flash dtbo emptydtbo.img fastboot erase init_boot // ? I don't remember if it's necessary, sorry fastboot continue 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
In a fairly new development, Qualcomm somehow made the DWC3 block cache-coherent. Annotate that. Fixes: 7f7e5c1b ("arm64: dts: qcom: sm8550: Add USB PHYs and controller nodes") Signed-off-by:
-
