summaryrefslogtreecommitdiff
path: root/drivers/pinctrl/pinctrl-scmi.c
AgeCommit message (Collapse)Author
2026-01-07pinctrl: imx: Add support for NXP i.MX952Peng Fan
The i.MX952 System Manager (SM) firmware supports the System Control Management Interface (SCMI) pinctrl protocol, similar to the i.MX95 SM. The base offset for the i.MX952 IOMUXC Daisy input register differs from that of the i.MX95. Update the pinctrl-imx-scmi driver to add support for i.MX952. Signed-off-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Linus Walleij <linusw@kernel.org>
2025-10-29pinctrl-scmi: remove unused struct membersDan Carpenter
The ->pins and ->nr_pins members are not used so delete them. Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2025-09-08pinctrl: generic: rename PIN_CONFIG_OUTPUT to LEVELLinus Walleij
This generic pin config property is confusingly named so let's rename it to make things clearer. There are already drivers in the tree that use PIN_CONFIG_OUTPUT to *read* the value of an output driven pin, which is a big semantic confusion for the head: are we then reading the setting of the output or the actual value/level that is put out on the pin? We already have PIN_CONFIG_OUTPUT_ENABLE that turns on driver buffers for output, so this can by logical conclusion only drive the voltage level if it should be any different. But if we read the pin, are we then reading the *setting* of the output value or the *actual* value we can see on the line? If the pin has not first been set into output mode with PIN_CONFIG_OUTPUT_ENABLE, but is instead in some input mode or tristate, what will reading this property actually return? Reading the current users reading this property it is clear that what we read is the logical level of the pin as 0 or 1 depending on if it is low or high. Rename it to PIN_CONFIG_LEVEL so it is crystal clear that we set or read the voltage level of the pin and nothing else. Acked-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2025-05-21pinctrl: freescale: Add support for imx943 pinctrlJacky Bai
The i.MX943 System Manager (SM) firmware supports the System Control Management Interface (SCMI) pinctrl protocol, similar to the i.MX95 SM. The base offset for the i.MX943 IOMUXC Daisy input register differs from that of the i.MX95. Update the pinctrl-imx-scmi driver to add support for i.MX943. Signed-off-by: Jacky Bai <ping.bai@nxp.com> Reviewed-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/20250516100423.1685732-1-ping.bai@nxp.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2024-06-17pinctrl: scmi: add blocklistPeng Fan
i.MX95 will have its own pinctrl scmi driver, so need block pinctrl-scmi driver for i.MX95, otherwise there will be two pinctrl devices for a single scmi protocol@19. Signed-off-by: Peng Fan <peng.fan@nxp.com> Acked-by: Sudeep Holla <sudeep.holla@arm.com> Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com> Link: https://lore.kernel.org/r/20240521-pinctrl-scmi-imx95-v1-2-9a1175d735fd@nxp.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2024-04-19pinctrl: Implementation of the generic scmi-pinctrl driverPeng Fan
scmi-pinctrl driver implements pinctrl driver interface and using SCMI protocol to redirect messages from pinctrl subsystem SDK to SCMI platform firmware, which does the changes in HW. Co-developed-by: Oleksii Moisieiev <oleksii_moisieiev@epam.com> Signed-off-by: Oleksii Moisieiev <oleksii_moisieiev@epam.com> Reviewed-by: Dhruva Gole <d-gole@ti.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Peng Fan <peng.fan@nxp.com> Link: https://lore.kernel.org/r/20240418-pinctrl-scmi-v11-4-499dca9864a7@nxp.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>