Re: [PATCH v1 5/9] firmware: keembay: Add support for Trusted Firmware Service call

[Mark Brown]

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