kernel/linux.git/drivers/pinctrl/qcom, branch v6.1.87

pinctrl: qcom: lpass-lpi: fix concurrent register updates

2023-11-02T08:35:22+00:00

[ Upstream commit c8befdc411e5fd1bf95a13e8744c8ca79b412bee ] The Qualcomm LPASS LPI pin controller driver uses one lock for guarding Read-Modify-Write code for slew rate registers. However the pin configuration and muxing registers have exactly the same RMW code but are not protected. Pin controller framework does not provide locking here, thus it is possible to trigger simultaneous change of pin configuration registers resulting in non-atomic changes. Protect from concurrent access by re-using the same lock used to cover the slew rate register. Using the same lock instead of adding second one will make more sense, once we add support for newer Qualcomm SoC, where slew rate is configured in the same register as pin configuration/muxing. Fixes: 6e261d1090d6 ("pinctrl: qcom: Add sm8250 lpass lpi pinctrl driver") Cc: stable@vger.kernel.org Reviewed-by: Linus Walleij Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20231013145705.219954-1-krzysztof.kozlowski@linaro.org Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin

pinctrl: qcom: lpass-lpi: set output value before enabling output

2023-05-11T14:03:02+00:00

commit 163bfb0cb1f6fbf961cf912cbde57399ea1ae0e8 upstream. As per Hardware Programming Guide, when configuring pin as output, set the pin value before setting output-enable (OE). Similar approach is in main SoC TLMM pin controller. Cc: Fixes: 6e261d1090d6 ("pinctrl: qcom: Add sm8250 lpass lpi pinctrl driver") Signed-off-by: Krzysztof Kozlowski Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20230309154949.658380-1-krzysztof.kozlowski@linaro.org Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman

pinctrl: qcom: pinctrl-msm8976: Correct function names for wcss pins

2023-03-10T08:33:10+00:00

[ Upstream commit a7cc0e2685082a0d79baec02df184dfa83cbfac3 ] Adjust names of function for wcss pins, also fix third gpio in bt group. Fixes: bcd11493f0ab ("pinctrl: qcom: Add a pinctrl driver for MSM8976 and 8956") Signed-off-by: Adam Skladowski Reviewed-by: Marijn Suijten Link: https://lore.kernel.org/r/20221231164250.74550-1-a39.skl@gmail.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin

pinctrl: qcom: sm8450-lpass-lpi: correct swr_rx_data group

2023-02-14T18:11:52+00:00

commit 5921b250f43870e7d8044ca14e402292ceb3e3a8 upstream. According to hardware programming guide, the swr_rx_data pin group has only two pins (GPIO5 and GPIO6). This is also visible in "struct sm8450_groups" in the driver - GPIO15 does not have swr_rx_data function. Fixes: ec1652fc4d56 ("pinctrl: qcom: Add sm8450 lpass lpi pinctrl driver") Cc: Signed-off-by: Krzysztof Kozlowski Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20230203165054.390762-1-krzysztof.kozlowski@linaro.org Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman

pinctrl: qcom: sc8280xp: Rectify UFS reset pins

2022-11-08T14:03:24+00:00

UFS reset pin offsets are wrongly configured for SC8280XP, correcting the same for both UFS instances here. Signed-off-by: Anjana Hari Signed-off-by: Bjorn Andersson Reviewed-by: Andrew Halaney Tested-by: Andrew Halaney # QDrive3 Link: https://lore.kernel.org/r/20221103181051.26912-1-quic_bjorande@quicinc.com Signed-off-by: Linus Walleij

pinctrl: qcom: Avoid glitching lines when we first mux to output

2022-10-17T10:28:26+00:00

Back in the description of commit e440e30e26dd ("arm64: dts: qcom: sc7180: Avoid glitching SPI CS at bootup on trogdor") we described a problem that we were seeing on trogdor devices. I'll re-summarize here but you can also re-read the original commit. On trogdor devices, the BIOS is setting up the SPI chip select as: - mux special function (SPI chip select) - output enable - output low (unused because we've muxed as special function) In the kernel, however, we've moved away from using the chip select line as special function. Since the kernel wants to fully control the chip select it's far more efficient to treat the line as a GPIO rather than sending packet-like commands to the GENI firmware every time we want the line to toggle. When we transition from how the BIOS had the pin configured to how the kernel has the pin configured we end up glitching the line. That's because we _first_ change the mux of the line and then later set its output. This glitch is bad and can confuse the device on the other end of the line. The old commit e440e30e26dd ("arm64: dts: qcom: sc7180: Avoid glitching SPI CS at bootup on trogdor") fixed the glitch, though the solution was far from elegant. It essentially did the thing that everyone always hates: encoding a sequential program in device tree, even if it's a simple one. It also, unfortunately, got broken by commit b991f8c3622c ("pinctrl: core: Handling pinmux and pinconf separately"). After that commit we did all the muxing _first_ even though the config (set the pin to output high) was listed first. :( I looked at ideas for how to solve this more properly. My first thought was to use the "init" pinctrl state. In theory the "init" pinctrl state is supposed to be exactly for achieving glitch-free transitions. My dream would have been for the "init" pinctrl to do nothing at all. That would let us delay the automatic pin muxing until the driver could set things up and call pinctrl_init_done(). In other words, my dream was: /* Request the GPIO; init it 1 (because DT says GPIO_ACTIVE_LOW) */ devm_gpiod_get_index(dev, "cs", GPIOD_OUT_LOW); /* Output should be right, so we can remux, yay! */ pinctrl_init_done(dev); Unfortunately, it didn't work out. The primary reason is that the MSM GPIO driver implements gpio_request_enable(). As documented in pinmux.h, that function automatically remuxes a line as a GPIO. ...and it does this remuxing _before_ specifying the output of the pin. You can see in gpiod_get_index() that we call gpiod_request() before gpiod_configure_flags(). gpiod_request() isn't passed any flags so it has no idea what the eventual output will be. We could have debates about whether or not the automatic remuxing to GPIO for the MSM pinctrl was a good idea or not, but at this point I think there is a plethora of code that's relying on it and I certainly wouldn't suggest changing it. Alternatively, we could try to come up with a way to pass the initial output state to gpio_request_enable() and plumb all that through. That seems like it would be doable, but we'd have to plumb it through several layers in the stack. This patch implements yet another alternative. Here, we specifically avoid glitching the first time a pin is muxed to GPIO function if the direction of the pin is output. The idea is that we can read the state of the pin before we set the mux and make sure that the re-mux won't change the state. NOTES: - We only do this the first time since later swaps between mux states might want to preserve the old output value. In other words, I wouldn't want to break a driver that did: gpiod_set_value(g, 1); pinctrl_select_state(pinctrl, special_state); pinctrl_select_default_state(); /* We should be driving 1 even if "special_state" made the pin 0 */ - It's safe to do this the first time since the driver _couldn't_ have explicitly set a state. In order to even be able to control the GPIO (at least using gpiod) we have to have requested it which would have counted as the first mux. - In theory, instead of keeping track of the first time a pin was set as a GPIO we could enable the glitch-free behavior only when msm_pinmux_request_gpio() is in the callchain. That works an enables my "dream" implementation above where we use an "init" state to solve this. However, it's nice not to have to do this. By handling just the first transition to GPIO we can simply let the normal "default" remuxing happen and we can be assured that there won't be a glitch. Before this change I could see the glitch reported on the EC console when booting. It would say this when booting the kernel: Unexpected state 1 in CSNRE ISR After this change there is no error reported. Note that I haven't reproduced the original problem described in e440e30e26dd ("arm64: dts: qcom: sc7180: Avoid glitching SPI CS at bootup on trogdor") but I could believe it might happen in certain timing conditions. Fixes: b991f8c3622c ("pinctrl: core: Handling pinmux and pinconf separately") Signed-off-by: Douglas Anderson Reviewed-by: Stephen Boyd Link: https://lore.kernel.org/r/20221014103217.1.I656bb2c976ed626e5d37294eb252c1cf3be769dc@changeid Signed-off-by: Linus Walleij

Merge tag 'pinctrl-v6.1-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl

2022-10-11T17:59:59+00:00

Pull pin control updates from Linus Walleij: "There is nothing exciting going on, no core changes, just a few drivers and cleanups. New drivers: - Cypress CY8C95x0 chip pin control support, along with an immediate cleanup - Mediatek MT8188 SoC pin control support - Qualcomm SM8450 and SC8280XP LPASS (low power audio subsystem) pin control support - Qualcomm PM7250, PM8450 - Rockchip RV1126 SoC pin control support Improvements: - Fix some missing pins in the Armada 37xx driver - Convert Broadcom and Nomadik drivers to use PINCTRL_PINGROUP() macro - Fix some GPIO irq_chips to be immutable - Massive Qualcomm device tree binding cleanup, with more to come" * tag 'pinctrl-v6.1-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl: (119 commits) MAINTAINERS: adjust STARFIVE JH7100 PINCTRL DRIVER after file movement pinctrl: starfive: Rename "pinctrl-starfive" to "pinctrl-starfive-jh7100" pinctrl: Create subdirectory for StarFive drivers dt-bindings: pinctrl: st,stm32: Document interrupt-controller property dt-bindings: pinctrl: st,stm32: Document gpio-hog pattern property dt-bindings: pinctrl: st,stm32: Document gpio-line-names pinctrl: st: stop abusing of_get_named_gpio() pinctrl: wpcm450: Correct the fwnode_irq_get() return value check pinctrl: bcm: Remove unused struct bcm6328_pingroup pinctrl: qcom: restrict drivers per ARM/ARM64 pinctrl: bcm: ns: Remove redundant dev_err call gpio: rockchip: request GPIO mux to pinctrl when setting direction pinctrl: rockchip: add pinmux_ops.gpio_set_direction callback pinctrl: cy8c95x0: Align function names in cy8c95x0_pmxops pinctrl: cy8c95x0: Drop atomicity on operations on push_pull pinctrl: cy8c95x0: Lock register accesses in cy8c95x0_set_mux() pinctrl: sunxi: sun50i-h5: Switch to use dev_err_probe() helper pinctrl: stm32: Switch to use dev_err_probe() helper dt-bindings: qcom-pmic-gpio: Add PM7250B and PM8450 bindings pinctrl: qcom: spmi-gpio: Add compatible for PM7250B ...

pinctrl: qcom: restrict drivers per ARM/ARM64

2022-10-04T07:33:37+00:00

There is no point to allow selecting pin-controller drivers for Qualcomm ARMv7 SoCs when building ARM64 kernel, and vice versa. This makes kernel configuration more difficult as many do not remember the Qualcomm SoCs. There won't be a single image for ARMv7 and ARMv8/9 SoCs, so no features/options are lost. Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20220925112103.148836-1-krzysztof.kozlowski@linaro.org Signed-off-by: Linus Walleij

pinctrl: qcom: spmi-gpio: Add compatible for PM7250B

2022-09-19T11:52:13+00:00

Add support for qcom,pm7250b-gpio variant. Signed-off-by: Jishnu Prakash Signed-off-by: David Collins Signed-off-by: Anjelique Melendez Acked-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20220912210624.4527-4-quic_amelende@quicinc.com Signed-off-by: Linus Walleij

pinctrl: qcom: spmi-gpio: Fix the GPIO strength mapping

2022-09-19T11:52:13+00:00

The SPMI based PMICs have the HIGH and LOW GPIO output strength mappings interchanged, fix them. Signed-off-by: Anjelique Melendez Link: https://lore.kernel.org/r/20220912210624.4527-3-quic_amelende@quicinc.com Signed-off-by: Linus Walleij