Set BIT(10) when the function needs to be set, otherwise the setting is
ignored.

Fixes: 0cb160f1b629 ("scmi: pinctrl: add pinctrl driver for SCMI")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Signed-off-by: Peng Fan <peng.fan@nxp.com>

This driver adds the base support of pinctrl over SCMI.  The driver
does two main things.  First, it allows you to configure the initial
pin states.  Secondly, it's used a base to build a GPIO driver on
top of it.

To configure the states then add a pinmux config to the scmi_pinctrl
section:

        scmi_pinctrl: protocol@19 {
                reg = <0x19>;
                pinmux1: pinmux_test {
                        pinmux = <0 1 0xFFFFFFFF 18 1
                                  0 2 0xFFFFFFFF 18 1
                                  0 3 0xFFFFFFFF 18 1>;
                        function = "f_gpio1";
                        groups = "grp_1", "grp_3";
                };
        };

Under linux the pinctrl subsystem will parse the function and group
properties and use that to handle muxing.  However, under u-boot the
pin muxing is done using the "pinmux" property, which feeds raw SCMI
pinctrl PINCTRL_SETTINGS_CONFIGURE commands to the server.  The
numbers are: selector, identifier, function_id, config_type, and
config_value.  In the example above, it sets pins 1, 2, and 3 to 1.
The linux-kernel ignores this pinmux property.

Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>

As exposed by "make randconfig", how we have SCMI_FIRMWARE today is
incomplete, and in one case, used incorrectly. First, SCMI_FIRMWARE has
a build-time dependency on OF_CONTROL being enabled, so add that.
Second, RESET_SCMI depends on SCMI_FIRMWARE being enabled, it should not
select that symbol. In turn, a number of platforms need to now enable
SCMI_FIRMWARE explicitly and not rely on RESET_SCMI to enable it for
them.

Signed-off-by: Tom Rini <trini@konsulko.com>
Acked-by: Peng Fan <peng.fan@nxp.com>
Acked-by: Anshul Dalal <anshuld@ti.com>
Acked-by: Michal Simek <michal.simek@amd.com> # Versal Gen 2
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>

SCMI base protocol device does not have a device tree, it should use and
need to use the agent base channel.

For scmi_base.[x], there is no real device tree node for it. ofnode_null() is
assigned as the device tree node for scmi base protocol device:
commit 7eb4eb541c14 ("firmware: scmi: install base protocol to SCMI agent")

However with recent update in commit 0535e46d55d7
("scripts/dtc: Update to upstream version v1.7.2-35-g52f07dcca47c"),
SPL panic in fdt_check_node_offset_()->fdt_next_tag(), because offset is -1
and SPL_OF_LIBFDT_ASSUME_MASK is 0xFF.

So add a check in x_get_channel() to validate the protocol devices'
ofnode.

Reported-by: Ye Li <ye.li@nxp.com>
Closes: https://lore.kernel.org/u-boot/939a9696-27fa-45a1-b428-feffe21ac6d5@oss.nxp.com/
Signed-off-by: Peng Fan <peng.fan@nxp.com>

The sandbox scmi clock protocol use version 3.0, so need to use
scmi_clk_state_in_v2.

Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>

SCMI v3.2 introduces a new clock CONFIG_SET message format that can
optionally carry also OEM specific configuration values beside the usual
clock enable/disable requests. Add support to use such new format when
talking to a v3.2 compliant SCMI platform.

Support existing enable/disable operations across different clock protocol
versions: this patch still does not add protocol operations to support the
new OEM specific optional configuration capabilities.

No functional change for the SCMI drivers users of the related enable and
disable clock operations.

[Marek: Remodel after Linux e49e314a2cf7 ("firmware: arm_scmi: Add clock v3.2 CONFIG_SET support")
        Support both old < 2.1 and new >= 2.1 protocol versions.
	Update commit message based on Linux one]

Signed-off-by: Vinh Nguyen <vinh.nguyen.xz@renesas.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Alice Guo <alice.guo@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>

MMU region cache behavior configuration for SCMI/SMT mailboxes is
platform specific. Even on ARM systems, the mailbox memory may not
even be located in any cacheable MMU region and may instead reside
in some SRAM. Remove this non-generic cache behavior configuration
code from generic code path.

It is unlikely that any platform is affected by this change if it
did configure its MMU regions correctly on start up. Platforms
which might be affected are i.MX94/95 and STM32MP.

Fixes: 240720e9052f ("firmware: scmi: mailbox/smt agent device")
Fixes: 2a3f161c8b16 ("scmi: correctly configure MMU for SCMI buffer")
Fixes: b2ae10970d40 ("firmware: scmi: use PAGE_SIZE alignment for ARM64")
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Tested-by: Alice Guo <alice.guo@nxp.com>
Tested-by: Patrice Chotard <patrice.chotard@foss.st.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>

This protocol allows an agent to start, stop a CPU or set reset vector.
It is used to manage auxiliary CPUs in an LM (e.g. additional cores in an
AP cluster).

Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Alice Guo <alice.guo@nxp.com>

Add Logical Machine Management(LMM) protocol which is intended for boot,
shutdown, and reset of other logical machines (LM). It is usually used to
allow one LM to manager another used as an offload or accelerator engine.

Following Linux Kernel, created a separate folder for holding vendor
protocol drivers.

Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Alice Guo <alice.guo@nxp.com>

Preparing to add i.MX LMM and CPU protocol driver, support probe SCMI
vendor ID 0x80(i.MX SCMI LMM ID) and 0x82(i.MX SCMI CPU ID). And use
Kconfig option to support conditional compilation.

Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Alice Guo <alice.guo@nxp.com>