On Thu, Jan 14, 2021 at 11:26:56PM +0800, Muhammad Husaini Zulkifli wrote:
> Export inline function to encapsulate AON_CFG1 for controling the I/O Rail
> supplied voltage levels which communicate with Trusted Firmware.
Adding Sudeep for the SMCCC bits, not deleting any context for his
benefit.
> Signed-off-by: Muhammad Husaini Zulkifli <muhammad.husaini.zulkifli@xxxxxxxxx>
> Acked-by: Andy Shevchenko <andriy.shevchenko@xxxxxxxxx>
> ---
> include/linux/firmware/intel/keembay.h | 82 ++++++++++++++++++++++++++
> 1 file changed, 82 insertions(+)
> create mode 100644 include/linux/firmware/intel/keembay.h
>
> diff --git a/include/linux/firmware/intel/keembay.h b/include/linux/firmware/intel/keembay.h
> new file mode 100644
> index 000000000000..f5a8dbfdb63b
> --- /dev/null
> +++ b/include/linux/firmware/intel/keembay.h
> @@ -0,0 +1,82 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Intel Keembay SOC Firmware API Layer
> + *
> + * Copyright (C) 2020, Intel Corporation
> + *
> + * Author: Muhammad Husaini Zulkifli <Muhammad.Husaini.Zulkifli@xxxxxxxxx>
> + */
> +
> +#ifndef __FIRMWARE_KEEMBAY_SMC_H__
> +#define __FIRMWARE_KEEMBAY_SMC_H__
> +
> +#include <linux/arm-smccc.h>
> +
> +/*
> + * This file defines an API function that can be called by a device driver in order to
> + * communicate with Trusted Firmware - A profile(TF-A) or Trusted Firmware - M profile (TF-M).
> + */
> +
> +#define KEEMBAY_SET_1V8_IO_RAIL 1
> +#define KEEMBAY_SET_3V3_IO_RAIL 0
> +
> +#define KEEMBAY_IOV_1_8V_uV 1800000
> +#define KEEMBAY_IOV_3_3V_uV 3300000
> +
> +#define KEEMBAY_SET_SD_VOLTAGE_ID 0xFF26
> +#define KEEMBAY_GET_SD_VOLTAGE_ID 0xFF2A
> +
> +#define ARM_SMCCC_SIP_KEEMBAY_SET_SD_VOLTAGE \
> + ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
> + ARM_SMCCC_SMC_32, \
> + ARM_SMCCC_OWNER_SIP, \
> + KEEMBAY_SET_SD_VOLTAGE_ID)
> +
> +#define ARM_SMCCC_SIP_KEEMBAY_GET_SD_VOLTAGE \
> + ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
> + ARM_SMCCC_SMC_32, \
> + ARM_SMCCC_OWNER_SIP, \
> + KEEMBAY_GET_SD_VOLTAGE_ID)
> +
> +#define KEEMBAY_REG_NUM_CONSUMERS 2
> +
> +struct keembay_reg_supply {
> + struct regulator *consumer;
> +};
> +
> +#if IS_ENABLED(CONFIG_HAVE_ARM_SMCCC_DISCOVERY)
> +/*
> + * Voltage applied on the IO Rail is controlled from the Always On Register using specific
> + * bits in AON_CGF1 register. This is a secure register. Keem Bay SOC cannot exposed this
> + * register address to the outside world.
> + */
> +static inline int keembay_set_io_rail_supplied_voltage(int volt)
> +{
> + struct arm_smccc_res res;
> +
> + arm_smccc_1_1_invoke(ARM_SMCCC_SIP_KEEMBAY_SET_SD_VOLTAGE, volt, &res);
There is a SCMI voltage domain protocol intended for just this use case
of controlling regulators managed by the firmware, why are you not using
that for these systems? See drivers/firmware/arm_scmi/voltage.c.
> +
> + return res.a0;
> +}
> +
> +static inline int keembay_get_io_rail_supplied_voltage(void)
> +{
> + struct arm_smccc_res res;
> +
> + arm_smccc_1_1_invoke(ARM_SMCCC_SIP_KEEMBAY_GET_SD_VOLTAGE, &res);
> +
> + return res.a1;
> +}
> +#else
> +static inline int keembay_set_io_rail_supplied_voltage(int volt)
> +{
> + return -ENODEV;
> +}
> +
> +static inline int keembay_get_io_rail_supplied_voltage(void)
> +{
> + return -ENODEV;
> +}
> +#endif
> +
> +#endif /* __FIRMWARE_KEEMBAY_SMC_H__ */
> --
> 2.17.1
>
Attachment:
signature.asc
Description: PGP signature
