- 07 Apr, 2023 40 commits
-
-
Krzysztof Kozlowski authored
Pin configuration property "input-enable" was used with the intention to disable the output, but this is done by default by Linux drivers. Since patch ("dt-bindings: pinctrl: qcom: tlmm should use output-disable, not input-enable") the property is not accepted anymore. Signed-off-by:Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230407175807.124394-5-krzysztof.kozlowski@linaro.org
-
Krzysztof Kozlowski authored
Pin configuration property "input-enable" was used with the intention to disable the output, but this is done by default by Linux drivers. Since patch ("dt-bindings: pinctrl: qcom: tlmm should use output-disable, not input-enable") the property is not accepted anymore. Signed-off-by: -
Krzysztof Kozlowski authored
Pin configuration property "input-enable" was used with the intention to disable the output, but this is done by default by Linux drivers. Since patch ("dt-bindings: pinctrl: qcom: tlmm should use output-disable, not input-enable") the property is not accepted anymore. Signed-off-by: -
Krzysztof Kozlowski authored
Pin configuration property "input-enable" was used with the intention to disable the output, but this is done by default by Linux drivers. Since patch ("dt-bindings: pinctrl: qcom: tlmm should use output-disable, not input-enable") the property is not accepted anymore. Signed-off-by: -
Krzysztof Kozlowski authored
Pin configuration property "input-enable" was used with the intention to disable the output, but this is done by default by Linux drivers. Since patch ("dt-bindings: pinctrl: qcom: tlmm should use output-disable, not input-enable") the property is not accepted anymore. Signed-off-by: -
Lux Aliaga authored
Add support for the Xiaomi Mi A3 (xiaomi-laurel-sprout). Here's a summary on what's defined. - dmesg output to bootloader preconfigured display - USB - UFS - SD card - SMD RPM regulators - Volume Up, Down and Power buttons - Thermistors Signed-off-by:
Lux Aliaga <they@mint.lgbt> Reviewed-by:
Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by:
Marijn Suijten <marijn.suijten@somainline.org> Signed-off-by:
-
Lux Aliaga authored
Adds a UFS host controller node and its corresponding PHY to the sm6125 platform. Signed-off-by:
-
Jianhua Lu authored
Add support for the Xiaomi Mi Pad 5 Pro CSOT variant. The CSOT variant uses China Star Optoelectronics Technology (CSOT) panel based on NT36523 display controller. Signed-off-by:
Jianhua Lu <lujianhua000@gmail.com> Reviewed-by:
-
Jianhua Lu authored
Add nodes for BOE NT36523 panel found in xiaomi-elish. This panel is a dual dsi mode panel and the dsi phy type is cphy. Signed-off-by:
-
Jianhua Lu authored
There are two panel variants of xiaomi-elish, BOE and CSOT panels. In order to support both panels, so split elish dts into common dtsi and elish-boe dts. Signed-off-by:
-
Krzysztof Kozlowski authored
SC8150 mailbox is compatible with SDM845. Signed-off-by:
-
Krzysztof Kozlowski authored
SC7180 mailbox is compatible with SDM845. Signed-off-by:
-
Krzysztof Kozlowski authored
QCS404 mailbox is compatible with MSM8916. Signed-off-by:
-
Krzysztof Kozlowski authored
SM6125 mailbox is compatible with MSM8994. Signed-off-by:
-
Krzysztof Kozlowski authored
SM6115 mailbox is compatible with MSM8994. Signed-off-by:
-
Krzysztof Kozlowski authored
SDM630 mailbox is compatible with MSM8994. Signed-off-by:
-
Krzysztof Kozlowski authored
MSM8998 mailbox is compatible with MSM8994. Signed-off-by:
-
Krzysztof Kozlowski authored
MSM8976 mailbox is compatible with MSM8994. Signed-off-by:
-
Krzysztof Kozlowski authored
IPQ8074 mailbox is compatible with IPQ6018. Signed-off-by:
-
Konrad Dybcio authored
Add an initial device tree for the QTI RB1 development board, based on the QRB2210 (QCM2290 derivative) SoC. This device tree targets the SoM revision 4, a.k.a. the Mass Production SKU. To get a successful boot, run: cat arch/arm64/boot/Image.gz arch/arm64/boot/dts/qcom/qrb2210-rb1.dtb >\ .Image.gz-dtb mkbootimg \ --kernel .Image.gz-dtb \ --ramdisk some_initrd \ --output rb1-boot.img \ --pagesize 4096 \ --base 0x8000 \ --cmdline 'some cmdline' fastboot boot rb1-boot.img There's no dtbo or other craziness to worry about. For the best dev experience, you can erase boot and use fastboot boot everytime, so that the bootloader doesn't mess with you. If you have a SoM revision 3 or older (there should be a sticker on it with text like -r00, where r is the revision), you will need to apply this additional diff: aliases { - serial0 = &uart0; + serial0 = &uart4; /* UART connected to the Micro-USB port via a FTDI chip */ - &uart0 { + &uart4 { That should however only concern preproduction boards. Signed-off-by: -
Konrad Dybcio authored
Introduce an initial device tree for the PM2250 (sometimes known as PM4125) PMIC. Signed-off-by:
-
Konrad Dybcio authored
Add an initial device tree for the QCM2290 low-end SoC, featuring 4 "customized" Cortex-A53 cores and up to 4 GiB of LPDDR(3/4X). This revision brings support for: - TSENS & thermal zones - SDHCI1/2 - I2C, SPI, UART - MPSS - ADSP - Wi-Fi Signed-off-by:
-
Konrad Dybcio authored
Drop the qcom,snoc-host-cap-skip-quirk that was never introduced to solve schema warnings. Reviewed-by:
-
Dylan Van Assche authored
Enable the SLPI DSP on the SHIFTPHONES SHIFT6mq phone with a Qualcomm SDM845 SoC. Signed-off-by:
Dylan Van Assche <me@dylanvanassche.be> Reviewed-by:
-
Dylan Van Assche authored
Enable the SLPI DSP on the Oneplus 6 phone with a Qualcomm SDM845 SoC. Signed-off-by:
-
Dylan Van Assche authored
Qualcomm SDM845 SoC features a SLPI DSP which uses FastRPC through an allocated memory region to load files from the host filesystem such as sensor configuration files. Add a FastRPC node at /dev/fastrpc-sdsp and a DMA region, similar to downstream, to allow userspace to communicate with the SLPI via the FastRPC interface for initializing the sensors on the SLPI. Signed-off-by:
-
Dylan Van Assche authored
SSC_Q6 and ADSP_Q6 are used in the FastRPC driver for accessing the secure world. Signed-off-by:
-
Dylan Van Assche authored
Add the SLPI remoteproc to the SDM845 Qualcomm SoC which is responsible for exposing the sensors connected to the SoC. The SLPI communicates over GLink edge 'dsps' and is similar to other DSPs e.g. ADSP or CDSP. This patch allows the SLPI to boot and expose itself over QRTR as service 400. Signed-off-by:
-
Bartosz Golaszewski authored
Add PMIC regulators for sa8775p-ride. Signed-off-by:
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by:
-
Konrad Dybcio authored
Drop the unnecessary mux{} level to make dtbs check happy. Signed-off-by: -
Konrad Dybcio authored
Fix the node name to make dtbs_check happy: qcom/apq8016-sbc.dtb: pmic@0: 'extcon@1300' does not match any of the regexes: '(.*)?(wled|leds)@[0-9a-f]+$', '^adc-tm@[0-9a-f]+$', '^adc@[0-9a-f]+$', '^audio-codec@[0-9a-f]+$', '^charger@[0-9a-f]+$', '^mpps@[0-9a-f]+$', '^nvram@[0-9a-f]+$', '^rtc@[0-9a-f]+$', '^temp-alarm@[0-9a-f]+$', '^usb-detect@[0-9a-f]+$', '^usb-vbus-regulator@[0-9a-f]+$', '^vibrator@[0-9a-f]+$', 'gpio@[0-9a-f]+$', 'pinctrl-[0-9]+', 'pon@[0-9a-f]+$' Signed-off-by:
-
Konrad Dybcio authored
Fix the following schema warning: gic-its@17a40000: False schema does not allow {'compatible': ['arm,gic-v3-its'], 'msi-controller': True, '#msi-cells': [[1]], 'reg': [[0, 396623872, 0, 131072]], 'status': ['disabled']} And reorder the properties to be more in order with all other nodes. Signed-off-by: -
Douglas Anderson authored
Cheza's SPI flash hookups (qspi) are exactly the same as trogdor's. Apply the same solution that's described in the patch ("arm64: dts: qcom: sc7180: Fix trogdor qspi pin config") Signed-off-by:Douglas Anderson <dianders@chromium.org> Acked-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Douglas Anderson authored
Similar to sc7180 (see the patch ("arm64: dts: qcom: sc7180: Fix trogdor qspi pin config")), we should adjust the qspi pin config for sc7280. I won't re-describe all the research/arguments in the sc7180 patch here, but there are a few differences for sc7280 worth noting: 1. On herobrine the SPI flash (qspi) is wired up differently on the board. Rather than Cr50 and the AP being wired directly together, there's actually a mux that will _either_ connect the AP to the flash or Cr50 to the flash. This means that the internal pulls on Cr50 don't affect us and we should enable our own pulldowns. 2. On herobrine, EEs added an external pulldown on the MISO line. The argument in the schematic said that we added it (but not one on MOSI and CLK) because Cr50 already enabled pulldowns on MOSI and CLK. ...though, as per #1, those Cr50 pulldowns would only affect the line when the mux was swung to Cr50. The ironic result of #1 and #2 is that the external pulldowns on CLK/MISO/MOSI on herobrine are _exactly opposite_ of the ones on trogdor. 3. While I still don't have the actual exact schematics for all variants of IDP/CRD that were produced, I have some reference schematics that give me a belief of how the qspi is hooked up there. From this, I'm fairly certain that all of the older variants of IDP/CRD either have a pulldown on the CLK/MOSI/MISO lines (maybe through a direct connect to Cr50) or have no pull (in other words, they don't have a pullup). I'll go ahead and enable internal pulldowns on all the lines since that won't hurt to double-pull if there's an external pulldown and it's nice to have a pulldown if there's nothing external. Note that this only affects _older_ CRDs. Newer revs are considered "herobrine" (see the hoglin/zoglin device trees). 4. I didn't find the same strange "auto-switch-to-keeper" at suspend when probing on sc7280. Whatever pulls (or lack thereof) I left at suspend time seemed to persist into suspend. Signed-off-by: -
Douglas Anderson authored
In commit 7ec3e673 ("arm64: dts: qcom: sc7180-trogdor: add initial trogdor and lazor dt") we specified the pull settings on the boot SPI (the qspi) data lines as pullups to "park" the lines. This seemed like the right thing to do, but I never really probed the lines to confirm. Since that time, I've done A LOT of research, experiements and poking of the lines with a voltmeter. A first batch of discoveries: - There is an external pullup on CS (clearly shown on schematics) - There are weak external pulldowns on CLK/MOSI (believed to be Cr50's internal pulldowns) - There is no pull on MISO. - When qspi isn't actively transferring it still drives CS, CLK, and MOSI. CS and MOSI are driven high and CLK is driven low. It does not drive MISO and (if no internal pulls are enabled) the line floats. The above means that it's good to have some sort of pull on MISO, at the very least. The pullup that we had before was actually fine (and my voltmeter confirms that it actually affected the state of the pin) but a pulldown would work equally well (and would match MOSI and CLK better). The above also means that we could save a tiny bit of power (not measurable by my setup) by setting up a sleep state for these pins. If nothing else this prevents us from driving high against Cr50's internal pulldown on MOSI. However, Qualcomm has also asserted in the past that it burns a little extra power to drive a pin, especially since these are configured with a slightly higher drive strength Let's fix all this. Since the external pulls are different for the two data lines, we'll split them into separate configs. Then we'll change the MISO pin to a pulldown and add a sleep state. On a slightly tangental (but not totally unrelated note), I also discovered some interesting things with these pins in suspend. First, I found that if we don't switch the pins to GPIO that the qspi peripheral continues to drive them in suspend. That'll be solved by what we're already doing above. Second, I found that something in the system suspend path (after Linux stops running) reconfigures these pins so that they don't have their normal pulls enabled but instead change to "keepers" (bias-bus-hold in DT speak). If a pin was floating before we entered suspend then it would stop floating. I found that I could manually pull a pin to a different level and then probe it and it would stay there. This is exactly keeper behavior. With the solution we have the switch to "keeper" doesn't matter too much but it's good to document. While talking about "keepers", it can also be noted that I found that the "keepers" on these pins were at least enough to win a fight against Cr50's internal pulls. That means it's best to make sure that the state of the pins are already correct before the mysterious transition to a keeper. Otherwise we'll burn (a small amount of) power in S3 via this fight. Luckily with the current solution we don't hit this case. NOTE: I've left "sc7180-idp" behavior totally alone in this patch. I didn't add a sleep state and I didn't change any pulls--I just adapted it to the fact that the data lines have separate configs. Qualcomm doesn't provide me with schematics for IDP and thus I don't actually know how the pulls are configured. Since this is just a development platform and worked well enough, it seems safer to leave it alone. Dependencies: - This patch has a hard dependency on ("pinctrl: qcom: Support OUTPUT_ENABLE; deprecate INPUT_ENABLE"). Something in the boot code seemed to have been confused and thought it needed to set the "OUTPUT ENABLE" bit for these pins even though it was using them as SPI. Thus if we don't honor the "output-disable" property we could end up driving the SPI pins while in sleep mode. - In general, it's probably best not to backport this to a kernel that doesn't have commit d21f4b7f ("pinctrl: qcom: Avoid glitching lines when we first mux to output"). That landed a while ago, but it's still good to be explicit in case someone was backporting. If we don't have that then there might be a glitch when we first switch over to GPIO before we disable the output. - This patch _doesn't_ really have any dependency on the qspi driver patch that supports setting the pinctrl sleep state--they can go in either order. If we define the sleep state and the driver never selects it that's fine. If the driver tries to select a sleep state that we don't define that's fine. Signed-off-by:
-
Douglas Anderson authored
As talked about in the patch ("dt-bindings: pinctrl: qcom: tlmm should use output-disable, not input-enable"), using "input-enable" in pinctrl states for Qualcomm TLMM pinctrl devices was either superfluous or there to disable a pin's output. Looking at cheza * ec_ap_int_l, h1_ap_int_odl: Superfluous. The pins will be configured as inputs automatically by the Linux GPIO subsystem (presumably the reference for other OSes using these device trees). * bios_flash_wp_l: Superfluous. This pin is exposed to userspace through the kernel's GPIO API and will be configured automatically. That means that in none of the cases for cheza did we need to change "input-enable" to "output-disable" and we can just remove these superfluous properties. Signed-off-by: -
Douglas Anderson authored
As talked about in the patch ("dt-bindings: pinctrl: qcom: tlmm should use output-disable, not input-enable"), using "input-enable" in pinctrl states for Qualcomm TLMM pinctrl devices was either superfluous or there to disable a pin's output. Looking at the sc7280-idp-ec-h1.dtsi file: * ap_ec_int_l, h1_ap_int_odl: Superfluous. The pins will be configured as inputs automatically by the Linux GPIO subsystem (presumably the reference for other OSes using these device trees). That means that in none of the cases for sc7280-idp-ec-h1.dtsi did we need to change "input-enable" to "output-disable" and we can just remove these superfluous properties. Signed-off-by: -
Douglas Anderson authored
As talked about in the patch ("dt-bindings: pinctrl: qcom: tlmm should use output-disable, not input-enable"), using "input-enable" in pinctrl states for Qualcomm TLMM pinctrl devices was either superfluous or there to disable a pin's output. Looking at trogdor: * ap_ec_int_l, fp_to_ap_irq_l, h1_ap_int_odl, p_sensor_int_l: Superfluous. The pins will be configured as inputs automatically by the Linux GPIO subsystem (presumably the reference for other OSes using these device trees). * bios_flash_wp_l: Superfluous. This pin is exposed to userspace through the kernel's GPIO API and will be configured automatically. That means that in none of the cases for trogdor did we need to change "input-enable" to "output-disable" and we can just remove these superfluous properties. Signed-off-by: -
Douglas Anderson authored
The l13a rail on trogdor devices has always been intended to be always-on on both S0 and S3. Different trogdor variants use l13a in slightly different ways, but the overall theme is that it's a 1.8V rail that the board uses for things that it wants powered in on S0 and S3. On many boards this includes the boot SPI (AKA qspi). For all intents and purposes this patch is actually a no-op since something else in the system seems to already be keeping the rail on all the time (confirmed via multimeter). That "something else" was postulated to be the modem but the rail is on / stays on even without the modem/wifi coming up so it's likely the boot config. In any case, making the fact that this is always-on explicit seems like a good idea. Signed-off-by:
-
Douglas Anderson authored
There are 4 qspi data pins: data0, data1, data2, and data3. Currently we have a shared pin state for data0 and data1 (2 lane config) and a pin state for data2 and data3 (you'd enable both this and the 2 lane state for 4 lanes). The second state is obviously misnamed. Fix it. Fixes: e1ce8539 ("arm64: dts: qcom: sdm845: Add qspi (quad SPI) node") Signed-off-by:
-
