linux/drivers/pinctrl/qcom, branch v6.2

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

2023-02-06T11:14:23Z

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

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

2022-12-13T21:03:06Z

Pull pin control updates from Linus Walleij: "The two large chunks is the header clean-up from Andy and the Qualcomm DT bindings clean-up from Krzysztof. Each which could give rise to conflicts, but I haven't seen any. The YAML conversions happening around the device tree is the biggest item in the series and is the result of Rob Herrings ambition to autovalidate these trees against strict schemas and it is paying off in lots of bugs found and ever prettier device trees. Sooner or later the transition will be complete, Krzysztof is fixing up all of the Qualcomm stuff, which is pretty voluminous. Core changes: - minor but nice and important documentation clean-ups New drivers: - subdriver for the Qualcomm SDM670 SoC - subdriver for the Intel Moorefield SoC - trivial support for the NXP Freescale i.MXRT1170 SoC Other changes and improvements - major clean-up of the Qualcomm pin control device tree bindings by Krzysztof - major header clean-up by Andy - some immutable irqchip clean-up for the Actions Semiconductor and Nuvoton drivers - GPIO helpers for The Cypress cy8c95x0 driver - bias handling in the Mediatek MT7986 driver - remove the unused pins-are-numbered concept that never flew" * tag 'pinctrl-v6.2-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl: (231 commits) pinctrl: thunderbay: fix possible memory leak in thunderbay_build_functions() dt-bindings: pinctrl: st,stm32: Deprecate pins-are-numbered dt-bindings: pinctrl: mediatek,mt65xx: Deprecate pins-are-numbered pinctrl: stm32: Remove check for pins-are-numbered pinctrl: mediatek: common: Remove check for pins-are-numbered pinctrl: qcom: remove duplicate included header files pinctrl: sunxi: d1: Add CAN bus pinmuxes pinctrl: loongson2: Fix some const correctness pinctrl: pinconf-generic: add missing of_node_put() pinctrl: intel: Enumerate PWM device when community has a capability pwm: lpss: Rename pwm_lpss_probe() --> devm_pwm_lpss_probe() pwm: lpss: Allow other drivers to enable PWM LPSS pwm: lpss: Include headers we are the direct user of pwm: lpss: Rename MAX_PWMS --> LPSS_MAX_PWMS pwm: Add a stub for devm_pwmchip_add() pinctrl: k210: call of_node_put() pinctrl: starfive: Use existing variable gpio dt-bindings: pinctrl: semtech,sx150xq: fix match patterns for 16 GPIOs matching pinconf-generic: fix style issues in pin_config_param doc pinctrl: pinctrl-loongson2: fix Kconfig dependency ...

pinctrl: qcom: remove duplicate included header files

2022-11-28T20:25:27Z

linux/seq_file.h is included more than once. Signed-off-by: ye xingchen Link: https://lore.kernel.org/r/202211221631577017318@zte.com.cn Signed-off-by: Linus Walleij

Merge tag 'intel-pinctrl-v6.2-1' of git://git.kernel.org/pub/scm/linux/kernel/git/pinctrl/intel into devel

2022-11-18T08:20:20Z

intel-pinctrl for v6.2-1 * Add Intel Moorefield pin control driver * Deduplicate COMMUNITY() macro in the Intel pin control drivers * Switch Freescale GPIO driver to use fwnode instead of of_node * Miscellaneous clenups here and there The following is an automated git shortlog grouped by driver: alderlake: - Deduplicate COMMUNITY macro code cannonlake: - Deduplicate COMMUNITY macro code device property: - Introduce fwnode_device_is_compatible() helper icelake: - Deduplicate COMMUNITY macro code intel: - Add Intel Moorefield pin controller support - Use temporary variable for struct device - Use str_enable_disable() helper merrifield: - Use temporary variable for struct device qcom: - lpass-lpi: Add missed bitfield.h soc: - fsl: qe: Switch to use fwnode instead of of_node sunrisepoint: - Deduplicate COMMUNITY macro code tigerlake: - Deduplicate COMMUNITY macro code

pinctrl: qcom: sc8280xp: Rectify UFS reset pins

2022-11-08T14:03:24Z

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: lpass-lpi: Add missed bitfield.h

2022-11-01T15:03:18Z

Previously the cleanup change dropped the bitfield.h from the pinctrl-lpass-lpi.h, since it's not used there, but forgot to re-instantiate it in the C-file, where users are located. Fix this by adding missed bitfield.h to the C-file. Fixes: aa9430f8a6de ("pinctrl: qcom: Add missing header(s)") Reported-by: kernel test robot Reported-by: Nathan Chancellor Signed-off-by: Andy Shevchenko

Merge tag 'intel-pinctrl-v6.1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/pinctrl/intel into devel

2022-10-26T07:58:29Z

intel-pinctrl for v6.1-2 * Add missing and remove unused headers in the pin control and GPIO drivers * Revise the pin control and GPIO headers

pinctrl: qcom: Add missing header(s)

2022-10-24T14:06:46Z

Do not imply that some of the generic headers may be always included. Instead, include explicitly what we are direct user of. While at it, sort headers alphabetically. Signed-off-by: Andy Shevchenko

pinctrl: qcom: sdm670: change sdm670_reserved_gpios to static

2022-10-24T08:17:28Z

sdm670_reserved_gpios is only used in pinctrl-sdm670.c now, change it to static. Fixes: 61164d220f52 ("pinctrl: qcom: add sdm670 pinctrl") Signed-off-by: Yang Yingliang Link: https://lore.kernel.org/r/20221020075650.1031228-1-yangyingliang@huawei.com Acked-by: Richard Acayan [Fix up subject] Signed-off-by: Linus Walleij

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

2022-10-17T10:28:26Z

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