| Message ID | 20240405-imx95-bbm-misc-v2-v2-3-9fc9186856c2@nxp.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | firmware: support i.MX95 SCMI BBM/MISC Extenstion | expand |
On Fri, Apr 05, 2024 at 08:39:25PM +0800, Peng Fan (OSS) wrote: > From: Peng Fan <peng.fan@nxp.com> > > The i.MX BBM protocol is for managing i.MX BBM module which provides > RTC and BUTTON feature. > Hi, > Signed-off-by: Peng Fan <peng.fan@nxp.com> > --- > drivers/firmware/arm_scmi/Kconfig | 10 + > drivers/firmware/arm_scmi/Makefile | 1 + > drivers/firmware/arm_scmi/imx-sm-bbm.c | 378 +++++++++++++++++++++++++++++++++ > include/linux/scmi_imx_protocol.h | 45 ++++ > 4 files changed, 434 insertions(+) > > diff --git a/drivers/firmware/arm_scmi/Kconfig b/drivers/firmware/arm_scmi/Kconfig > index aa5842be19b2..56d11c9d9f47 100644 > --- a/drivers/firmware/arm_scmi/Kconfig > +++ b/drivers/firmware/arm_scmi/Kconfig > @@ -181,3 +181,13 @@ config ARM_SCMI_POWER_CONTROL > early shutdown/reboot SCMI requests. > > endmenu > + > +config IMX_SCMI_BBM_EXT > + tristate "i.MX SCMI BBM EXTENSION" > + depends on ARM_SCMI_PROTOCOL || (COMPILE_TEST && OF) > + default y if ARCH_MXC > + help > + This enables i.MX System BBM control logic which supports RTC > + and BUTTON. > + > + This driver can also be built as a module. > diff --git a/drivers/firmware/arm_scmi/Makefile b/drivers/firmware/arm_scmi/Makefile > index a7bc4796519c..327687acf857 100644 > --- a/drivers/firmware/arm_scmi/Makefile > +++ b/drivers/firmware/arm_scmi/Makefile > @@ -11,6 +11,7 @@ scmi-transport-$(CONFIG_ARM_SCMI_HAVE_MSG) += msg.o > scmi-transport-$(CONFIG_ARM_SCMI_TRANSPORT_VIRTIO) += virtio.o > scmi-transport-$(CONFIG_ARM_SCMI_TRANSPORT_OPTEE) += optee.o > scmi-protocols-y = base.o clock.o perf.o power.o reset.o sensors.o system.o voltage.o powercap.o > +scmi-protocols-$(CONFIG_IMX_SCMI_BBM_EXT) += imx-sm-bbm.o > scmi-module-objs := $(scmi-driver-y) $(scmi-protocols-y) $(scmi-transport-y) > > obj-$(CONFIG_ARM_SCMI_PROTOCOL) += scmi-core.o > diff --git a/drivers/firmware/arm_scmi/imx-sm-bbm.c b/drivers/firmware/arm_scmi/imx-sm-bbm.c > new file mode 100644 > index 000000000000..92c0aedf65cc > --- /dev/null > +++ b/drivers/firmware/arm_scmi/imx-sm-bbm.c > @@ -0,0 +1,378 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * System Control and Management Interface (SCMI) NXP BBM Protocol > + * > + * Copyright 2024 NXP > + */ > + > +#define pr_fmt(fmt) "SCMI Notifications BBM - " fmt > + > +#include <linux/bits.h> > +#include <linux/io.h> > +#include <linux/module.h> > +#include <linux/of.h> > +#include <linux/platform_device.h> > +#include <linux/scmi_protocol.h> > +#include <linux/scmi_imx_protocol.h> > + > +#include "protocols.h" > +#include "notify.h" > + > +#define SCMI_PROTOCOL_SUPPORTED_VERSION 0x10000 > + I appreciate that you added versioning but I think a bit of documentation about what the protocol and its comamnds purpose is still lacking, as asked by Sudeep previously https://lore.kernel.org/linux-arm-kernel/ZeGtoJ7ztSe8Kg8R@bogus/#t > +enum scmi_imx_bbm_protocol_cmd { > + IMX_BBM_GPR_SET = 0x3, > + IMX_BBM_GPR_GET = 0x4, > + IMX_BBM_RTC_ATTRIBUTES = 0x5, > + IMX_BBM_RTC_TIME_SET = 0x6, > + IMX_BBM_RTC_TIME_GET = 0x7, > + IMX_BBM_RTC_ALARM_SET = 0x8, > + IMX_BBM_BUTTON_GET = 0x9, > + IMX_BBM_RTC_NOTIFY = 0xA, > + IMX_BBM_BUTTON_NOTIFY = 0xB, > +}; > + > +#define GET_RTCS_NR(x) le32_get_bits((x), GENMASK(23, 16)) > +#define GET_GPRS_NR(x) le32_get_bits((x), GENMASK(15, 0)) > + > +#define SCMI_IMX_BBM_NOTIFY_RTC_UPDATED BIT(2) > +#define SCMI_IMX_BBM_NOTIFY_RTC_ROLLOVER BIT(1) > +#define SCMI_IMX_BBM_NOTIFY_RTC_ALARM BIT(0) > + > +#define SCMI_IMX_BBM_RTC_ALARM_ENABLE_FLAG BIT(0) > + > +#define SCMI_IMX_BBM_NOTIFY_RTC_FLAG \ > + (SCMI_IMX_BBM_NOTIFY_RTC_UPDATED | SCMI_IMX_BBM_NOTIFY_RTC_ROLLOVER | \ > + SCMI_IMX_BBM_NOTIFY_RTC_ALARM) > + > +#define SCMI_IMX_BBM_EVENT_RTC_MASK GENMASK(31, 24) > + > +struct scmi_imx_bbm_info { > + u32 version; > + int nr_rtc; > + int nr_gpr; > +}; > + > +struct scmi_msg_imx_bbm_protocol_attributes { > + __le32 attributes; > +}; > + > +struct scmi_imx_bbm_set_time { > + __le32 id; > + __le32 flags; > + __le32 value_low; > + __le32 value_high; > +}; > + > +struct scmi_imx_bbm_get_time { > + __le32 id; > + __le32 flags; > +}; > + > +struct scmi_imx_bbm_alarm_time { > + __le32 id; > + __le32 flags; > + __le32 value_low; > + __le32 value_high; > +}; > + > +struct scmi_msg_imx_bbm_rtc_notify { > + __le32 rtc_id; > + __le32 flags; > +}; > + > +struct scmi_msg_imx_bbm_button_notify { > + __le32 flags; > +}; > + > +struct scmi_imx_bbm_notify_payld { > + __le32 flags; > +}; > + > +static int scmi_imx_bbm_attributes_get(const struct scmi_protocol_handle *ph, > + struct scmi_imx_bbm_info *pi) > +{ > + int ret; > + struct scmi_xfer *t; > + struct scmi_msg_imx_bbm_protocol_attributes *attr; > + > + ret = ph->xops->xfer_get_init(ph, PROTOCOL_ATTRIBUTES, 0, sizeof(*attr), &t); > + if (ret) > + return ret; > + > + attr = t->rx.buf; > + > + ret = ph->xops->do_xfer(ph, t); > + if (!ret) { > + pi->nr_rtc = GET_RTCS_NR(attr->attributes); > + pi->nr_gpr = GET_GPRS_NR(attr->attributes); > + } > + > + ph->xops->xfer_put(ph, t); > + > + return ret; > +} > + > +static int scmi_imx_bbm_notify(const struct scmi_protocol_handle *ph, > + u32 src_id, int message_id, bool enable) > +{ > + int ret; > + struct scmi_xfer *t; > + > + if (message_id == IMX_BBM_RTC_NOTIFY) { > + struct scmi_msg_imx_bbm_rtc_notify *rtc_notify; > + > + ret = ph->xops->xfer_get_init(ph, message_id, > + sizeof(*rtc_notify), 0, &t); > + if (ret) > + return ret; > + > + rtc_notify = t->tx.buf; > + rtc_notify->rtc_id = cpu_to_le32(0); > + rtc_notify->flags = > + cpu_to_le32(enable ? SCMI_IMX_BBM_NOTIFY_RTC_FLAG : 0); > + } else if (message_id == IMX_BBM_BUTTON_NOTIFY) { > + struct scmi_msg_imx_bbm_button_notify *button_notify; > + > + ret = ph->xops->xfer_get_init(ph, message_id, > + sizeof(*button_notify), 0, &t); > + if (ret) > + return ret; > + > + button_notify = t->tx.buf; > + button_notify->flags = cpu_to_le32(enable ? 1 : 0); > + } else { > + return -EINVAL; > + } > + > + ret = ph->xops->do_xfer(ph, t); > + > + ph->xops->xfer_put(ph, t); > + return ret; > +} > + > +static enum scmi_imx_bbm_protocol_cmd evt_2_cmd[] = { > + IMX_BBM_RTC_NOTIFY, > + IMX_BBM_BUTTON_NOTIFY > +}; > + > +static int scmi_imx_bbm_set_notify_enabled(const struct scmi_protocol_handle *ph, > + u8 evt_id, u32 src_id, bool enable) > +{ > + int ret, cmd_id; > + > + if (evt_id >= ARRAY_SIZE(evt_2_cmd)) > + return -EINVAL; > + > + cmd_id = evt_2_cmd[evt_id]; > + ret = scmi_imx_bbm_notify(ph, src_id, cmd_id, enable); > + if (ret) > + pr_debug("FAIL_ENABLED - evt[%X] dom[%d] - ret:%d\n", > + evt_id, src_id, ret); > + > + return ret; > +} > + > +static void *scmi_imx_bbm_fill_custom_report(const struct scmi_protocol_handle *ph, > + u8 evt_id, ktime_t timestamp, > + const void *payld, size_t payld_sz, > + void *report, u32 *src_id) > +{ > + const struct scmi_imx_bbm_notify_payld *p = payld; > + struct scmi_imx_bbm_notif_report *r = report; > + > + if (sizeof(*p) != payld_sz) > + return NULL; > + > + if (evt_id == SCMI_EVENT_IMX_BBM_RTC) { > + r->is_rtc = true; > + r->is_button = false; > + r->timestamp = timestamp; > + r->rtc_id = le32_get_bits(p->flags, SCMI_IMX_BBM_EVENT_RTC_MASK); > + r->rtc_evt = le32_get_bits(p->flags, SCMI_IMX_BBM_NOTIFY_RTC_FLAG); > + dev_dbg(ph->dev, "RTC: %d evt: %x\n", r->rtc_id, r->rtc_evt); > + *src_id = r->rtc_evt; > + } else if (evt_id == SCMI_EVENT_IMX_BBM_BUTTON) { > + r->is_rtc = false; > + r->is_button = true; > + r->timestamp = timestamp; > + dev_dbg(ph->dev, "BBM Button\n"); > + *src_id = 0; > + } else { > + WARN_ON_ONCE(1); > + return NULL; > + } > + > + return r; > +} > + > +static const struct scmi_event scmi_imx_bbm_events[] = { > + { > + .id = SCMI_EVENT_IMX_BBM_RTC, > + .max_payld_sz = sizeof(struct scmi_imx_bbm_notify_payld), > + .max_report_sz = sizeof(struct scmi_imx_bbm_notif_report), > + }, > + { > + .id = SCMI_EVENT_IMX_BBM_BUTTON, > + .max_payld_sz = sizeof(struct scmi_imx_bbm_notify_payld), > + .max_report_sz = sizeof(struct scmi_imx_bbm_notif_report), > + }, > +}; > + > +static const struct scmi_event_ops scmi_imx_bbm_event_ops = { > + .set_notify_enabled = scmi_imx_bbm_set_notify_enabled, > + .fill_custom_report = scmi_imx_bbm_fill_custom_report, > +}; > + > +static const struct scmi_protocol_events scmi_imx_bbm_protocol_events = { > + .queue_sz = SCMI_PROTO_QUEUE_SZ, > + .ops = &scmi_imx_bbm_event_ops, > + .evts = scmi_imx_bbm_events, > + .num_events = ARRAY_SIZE(scmi_imx_bbm_events), > + .num_sources = 1, > +}; > + > +static int scmi_imx_bbm_protocol_init(const struct scmi_protocol_handle *ph) > +{ > + u32 version; > + int ret; > + struct scmi_imx_bbm_info *binfo; > + > + ret = ph->xops->version_get(ph, &version); > + if (ret) > + return ret; > + > + dev_info(ph->dev, "NXP SM BBM Version %d.%d\n", > + PROTOCOL_REV_MAJOR(version), PROTOCOL_REV_MINOR(version)); > + > + binfo = devm_kzalloc(ph->dev, sizeof(*binfo), GFP_KERNEL); > + if (!binfo) > + return -ENOMEM; > + > + ret = scmi_imx_bbm_attributes_get(ph, binfo); > + if (ret) > + return ret; > + > + return ph->set_priv(ph, binfo, version); > +} > + > +static int scmi_imx_bbm_rtc_time_set(const struct scmi_protocol_handle *ph, > + u32 rtc_id, u64 sec) > +{ > + struct scmi_imx_bbm_info *pi = ph->get_priv(ph); > + struct scmi_imx_bbm_set_time *cfg; > + struct scmi_xfer *t; > + int ret; > + > + if (rtc_id >= pi->nr_rtc) > + return -EINVAL; > + > + ret = ph->xops->xfer_get_init(ph, IMX_BBM_RTC_TIME_SET, sizeof(*cfg), 0, &t); > + if (ret) > + return ret; > + > + cfg = t->tx.buf; > + cfg->id = cpu_to_le32(rtc_id); > + cfg->flags = 0; > + cfg->value_low = lower_32_bits(sec); > + cfg->value_high = upper_32_bits(sec); Sorry I may have not been clear on this, but when I mentioned lower/upper helpers I did not mean that they solved ALSO the endianity problem, so I suppose that after having chunked your 64bits value in 2, you still want to transmit it as 2 LE quantity....this is generally the expectation for SCMI payloads...in this case any available documentation about the expected command layout would have helped... > + > + ret = ph->xops->do_xfer(ph, t); > + > + ph->xops->xfer_put(ph, t); > + > + return ret; > +} > + > +static int scmi_imx_bbm_rtc_time_get(const struct scmi_protocol_handle *ph, > + u32 rtc_id, u64 *value) > +{ > + struct scmi_imx_bbm_info *pi = ph->get_priv(ph); > + struct scmi_imx_bbm_get_time *cfg; > + struct scmi_xfer *t; > + int ret; > + > + if (rtc_id >= pi->nr_rtc) > + return -EINVAL; > + > + ret = ph->xops->xfer_get_init(ph, IMX_BBM_RTC_TIME_GET, sizeof(*cfg), > + sizeof(u64), &t); > + if (ret) > + return ret; > + > + cfg = t->tx.buf; > + cfg->id = cpu_to_le32(rtc_id); > + cfg->flags = 0; > + > + ret = ph->xops->do_xfer(ph, t); > + if (!ret) > + *value = get_unaligned_le64(t->rx.buf); > + > + ph->xops->xfer_put(ph, t); > + > + return ret; > +} > + > +static int scmi_imx_bbm_rtc_alarm_set(const struct scmi_protocol_handle *ph, > + u32 rtc_id, u64 sec) > +{ > + struct scmi_imx_bbm_info *pi = ph->get_priv(ph); > + struct scmi_imx_bbm_alarm_time *cfg; > + struct scmi_xfer *t; > + int ret; > + > + if (rtc_id >= pi->nr_rtc) > + return -EINVAL; > + > + ret = ph->xops->xfer_get_init(ph, IMX_BBM_RTC_ALARM_SET, sizeof(*cfg), 0, &t); > + if (ret) > + return ret; > + > + cfg = t->tx.buf; > + cfg->id = cpu_to_le32(rtc_id); > + cfg->flags = SCMI_IMX_BBM_RTC_ALARM_ENABLE_FLAG; > + cfg->value_low = lower_32_bits(sec); > + cfg->value_high = upper_32_bits(sec); Same. Thanks, Cristian
> Subject: Re: [PATCH v2 3/6] firmware: arm_scmi: add initial support for i.MX > BBM protocol > > On Fri, Apr 05, 2024 at 08:39:25PM +0800, Peng Fan (OSS) wrote: > > From: Peng Fan <peng.fan@nxp.com> > > > > The i.MX BBM protocol is for managing i.MX BBM module which provides > > RTC and BUTTON feature. > > ..... > > +#include "notify.h" > > + > > +#define SCMI_PROTOCOL_SUPPORTED_VERSION 0x10000 > > + > > I appreciate that you added versioning but I think a bit of documentation > about what the protocol and its comamnds purpose is still lacking, as asked > by Sudeep previously Sorry for missing the previous comment. Will add some comments in the file. > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F% > 2Flore.kernel.org%2Flinux-arm- > kernel%2FZeGtoJ7ztSe8Kg8R%40bogus%2F%23t&data=05%7C02%7Cpeng.fa > n%40nxp.com%7C37b12c01b51f4329e9e308dc57f66153%7C686ea1d3bc2b > 4c6fa92cd99c5c301635%7C0%7C0%7C638481962901820964%7CUnknown > %7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha > WwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=d2XRugSYyiFuUnE5R2Oz6p > xmXBaPC9lZ%2Bb%2FcMBuXeKo%3D&reserved=0 > > > +enum scmi_imx_bbm_protocol_cmd { > > + IMX_BBM_GPR_SET = 0x3, .... > > + cfg->flags = 0; > > + cfg->value_low = lower_32_bits(sec); > > + cfg->value_high = upper_32_bits(sec); > > Sorry I may have not been clear on this, but when I mentioned lower/upper > helpers I did not mean that they solved ALSO the endianity problem, so I > suppose that after having chunked your 64bits value in 2, you still want to > transmit it as 2 LE quantity....this is generally the expectation for SCMI > payloads...in this case any available documentation about the expected > command layout would have helped... Got it , will fix in v3. > > > + > > + ret = ph->xops->do_xfer(ph, t); > > + > > + ph->xops->xfer_put(ph, t); > > + > > + return ret; > > +} > > + > > +static int scmi_imx_bbm_rtc_time_get(const struct scmi_protocol_handle > *ph, > > + u32 rtc_id, u64 *value) > > +{ > > + struct scmi_imx_bbm_info *pi = ph->get_priv(ph); > > + struct scmi_imx_bbm_get_time *cfg; > > + struct scmi_xfer *t; > > + int ret; > > + > > + if (rtc_id >= pi->nr_rtc) > > + return -EINVAL; > > + > > + ret = ph->xops->xfer_get_init(ph, IMX_BBM_RTC_TIME_GET, > sizeof(*cfg), > > + sizeof(u64), &t); > > + if (ret) > > + return ret; > > + > > + cfg = t->tx.buf; > > + cfg->id = cpu_to_le32(rtc_id); > > + cfg->flags = 0; > > + > > + ret = ph->xops->do_xfer(ph, t); > > + if (!ret) > > + *value = get_unaligned_le64(t->rx.buf); > > + > > + ph->xops->xfer_put(ph, t); > > + > > + return ret; > > +} > > + > > +static int scmi_imx_bbm_rtc_alarm_set(const struct scmi_protocol_handle > *ph, > > + u32 rtc_id, u64 sec) > > +{ > > + struct scmi_imx_bbm_info *pi = ph->get_priv(ph); > > + struct scmi_imx_bbm_alarm_time *cfg; > > + struct scmi_xfer *t; > > + int ret; > > + > > + if (rtc_id >= pi->nr_rtc) > > + return -EINVAL; > > + > > + ret = ph->xops->xfer_get_init(ph, IMX_BBM_RTC_ALARM_SET, > sizeof(*cfg), 0, &t); > > + if (ret) > > + return ret; > > + > > + cfg = t->tx.buf; > > + cfg->id = cpu_to_le32(rtc_id); > > + cfg->flags = SCMI_IMX_BBM_RTC_ALARM_ENABLE_FLAG; > > + cfg->value_low = lower_32_bits(sec); > > + cfg->value_high = upper_32_bits(sec); > > Same. Fix in V3. Thanks, Peng > > Thanks, > Cristian
On Mon, Apr 08, 2024 at 07:04:43PM +0100, Cristian Marussi wrote: > On Fri, Apr 05, 2024 at 08:39:25PM +0800, Peng Fan (OSS) wrote: > > From: Peng Fan <peng.fan@nxp.com> > > > > The i.MX BBM protocol is for managing i.MX BBM module which provides > > RTC and BUTTON feature. > > > > I appreciate that you added versioning but I think a bit of documentation > about what the protocol and its comamnds purpose is still lacking, as asked > by Sudeep previously > > https://lore.kernel.org/linux-arm-kernel/ZeGtoJ7ztSe8Kg8R@bogus/#t > I have decided to ignore all these vendor protocol patches until they have some documentation to understand what these protocol are for, what are the commands, their input/output parameter details, any conditions are the caller and callee,..etc very similar to SCMI spec. To start with can you please expand what is BBM or MISC protocol is ? Don't expect me to respond if the requested details are still missing in the future versions, I am going to ignore it silently. I have asked for these in atleast 2 different threads may be not just NXP patches but in one instance Qcom patches, but they apply equally here.
Hi Sudeep, > Subject: Re: [PATCH v2 3/6] firmware: arm_scmi: add initial support for i.MX > BBM protocol > > On Mon, Apr 08, 2024 at 07:04:43PM +0100, Cristian Marussi wrote: > > On Fri, Apr 05, 2024 at 08:39:25PM +0800, Peng Fan (OSS) wrote: > > > From: Peng Fan <peng.fan@nxp.com> > > > > > > The i.MX BBM protocol is for managing i.MX BBM module which provides > > > RTC and BUTTON feature. > > > > > > > I appreciate that you added versioning but I think a bit of > > documentation about what the protocol and its comamnds purpose is > > still lacking, as asked by Sudeep previously > > > > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore > > .kernel.org%2Flinux-arm- > kernel%2FZeGtoJ7ztSe8Kg8R%40bogus%2F%23t&data= > > > 05%7C02%7Cpeng.fan%40nxp.com%7Ce92ff78b9126447afe9708dc587358d > 4%7C686e > > > a1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638482499632395762%7C > Unknown%7C > > > TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiL > CJXVC > > > I6Mn0%3D%7C0%7C%7C%7C&sdata=7QP%2BkkjHA3Sa0CdcbbObGG4kgYYK > XAGA2r%2F%2F > > x0MogqU%3D&reserved=0 > > > > I have decided to ignore all these vendor protocol patches until they have > some documentation to understand what these protocol are for, what are the > commands, their input/output parameter details, any conditions are the > caller and callee,..etc very similar to SCMI spec. Where do you expect the documentation to be put? similar as scmi_protocol.h, put in scmi_imx_protcol.h? > > To start with can you please expand what is BBM or MISC protocol is ? ok. Sorry for missing your previous comment in v1. Let me write here briefly first. The Battery Backup (BB) Domain contains the Battery Backed Security Module (BBSM) and the Battery Backed Non-Secure Module (BBNSM). BBM protocol is to manage i.MX BBSM and BBNSM. This protocol supports #define COMMAND_PROTOCOL_VERSION 0x0U #define COMMAND_PROTOCOL_ATTRIBUTES 0x1U #define COMMAND_PROTOCOL_MESSAGE_ATTRIBUTES 0x2U #define COMMAND_BBM_GPR_SET 0x3U #define COMMAND_BBM_GPR_GET 0x4U #define COMMAND_BBM_RTC_ATTRIBUTES 0x5U #define COMMAND_BBM_RTC_TIME_SET 0x6U #define COMMAND_BBM_RTC_TIME_GET 0x7U #define COMMAND_BBM_RTC_ALARM_SET 0x8U #define COMMAND_BBM_BUTTON_GET 0x9U #define COMMAND_BBM_RTC_NOTIFY 0xAU #define COMMAND_BBM_BUTTON_NOTIFY 0xBU #define COMMAND_NEGOTIATE_PROTOCOL_VERSION 0x10U For now in this patchset for linux, we only use RTC, and BUTTON for system wakeup For MISC protocol, it is for various misc things, such as discover build info, get rom passed data, get reset reason, get i.mx cfg name, control set(for gpio expander under m33 control and etc). The command as below: 51 #define COMMAND_PROTOCOL_VERSION 0x0U 52 #define COMMAND_PROTOCOL_ATTRIBUTES 0x1U 53 #define COMMAND_PROTOCOL_MESSAGE_ATTRIBUTES 0x2U 54 #define COMMAND_MISC_CONTROL_SET 0x3U 55 #define COMMAND_MISC_CONTROL_GET 0x4U 56 #define COMMAND_MISC_CONTROL_ACTION 0x5U 57 #define COMMAND_MISC_DISCOVER_BUILD_INFO 0x6U 58 #define COMMAND_MISC_ROM_PASSOVER_GET 0x7U 59 #define COMMAND_MISC_CONTROL_NOTIFY 0x8U 60 #define COMMAND_MISC_REASON_ATTRIBUTES 0x9U 61 #define COMMAND_MISC_RESET_REASON 0xAU 62 #define COMMAND_MISC_SI_INFO 0xBU 63 #define COMMAND_MISC_CFG_INFO 0xCU 64 #define COMMAND_MISC_SYSLOG 0xDU 65 #define COMMAND_NEGOTIATE_PROTOCOL_VERSION 0x10U I will add the information in v3. But as of now I am not sure how to proceed with dt-binding, add in vendor stuff in arm,scmi.yaml or add imx,scmi.yaml Thanks, Peng. > Don't expect me to respond if the requested details are still missing in the > future versions, I am going to ignore it silently. > > I have asked for these in atleast 2 different threads may be not just NXP > patches but in one instance Qcom patches, but they apply equally here. > > -- > Regards, > Sudeep
On Tue, Apr 09, 2024 at 09:13:33AM +0000, Peng Fan wrote: > Hi Sudeep, > > > Subject: Re: [PATCH v2 3/6] firmware: arm_scmi: add initial support for i.MX > > BBM protocol > > > > On Mon, Apr 08, 2024 at 07:04:43PM +0100, Cristian Marussi wrote: > > > On Fri, Apr 05, 2024 at 08:39:25PM +0800, Peng Fan (OSS) wrote: > > > > From: Peng Fan <peng.fan@nxp.com> > > > > > > > > The i.MX BBM protocol is for managing i.MX BBM module which provides > > > > RTC and BUTTON feature. > > > > > > > > > > I appreciate that you added versioning but I think a bit of > > > documentation about what the protocol and its comamnds purpose is > > > still lacking, as asked by Sudeep previously > > > > > > > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore > > > .kernel.org%2Flinux-arm- > > kernel%2FZeGtoJ7ztSe8Kg8R%40bogus%2F%23t&data= > > > > > 05%7C02%7Cpeng.fan%40nxp.com%7Ce92ff78b9126447afe9708dc587358d > > 4%7C686e > > > > > a1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638482499632395762%7C > > Unknown%7C > > > > > TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiL > > CJXVC > > > > > I6Mn0%3D%7C0%7C%7C%7C&sdata=7QP%2BkkjHA3Sa0CdcbbObGG4kgYYK > > XAGA2r%2F%2F > > > x0MogqU%3D&reserved=0 > > > > > > > I have decided to ignore all these vendor protocol patches until they have > > some documentation to understand what these protocol are for, what are the > > commands, their input/output parameter details, any conditions are the > > caller and callee,..etc very similar to SCMI spec. > > Where do you expect the documentation to be put? > To begin with, we need all these vendor protocols in a directory say vendors/nxp under drivers/firmware/arm_scmi. It can be a simple text file under that. We can see later if we need any more formal version elsewhere but that shouldn't be a blocker for these changes. > similar as scmi_protocol.h, put in scmi_imx_protcol.h? > > > > To start with can you please expand what is BBM or MISC protocol is ? > > ok. Sorry for missing your previous comment in v1. Let me write here briefly > first. > Thanks > The Battery Backup (BB) Domain contains the Battery Backed Security > Module (BBSM) and the Battery Backed Non-Secure Module (BBNSM). > BBM protocol is to manage i.MX BBSM and BBNSM. This protocol supports > #define COMMAND_PROTOCOL_VERSION 0x0U > #define COMMAND_PROTOCOL_ATTRIBUTES 0x1U > #define COMMAND_PROTOCOL_MESSAGE_ATTRIBUTES 0x2U > #define COMMAND_BBM_GPR_SET 0x3U > #define COMMAND_BBM_GPR_GET 0x4U > #define COMMAND_BBM_RTC_ATTRIBUTES 0x5U > #define COMMAND_BBM_RTC_TIME_SET 0x6U > #define COMMAND_BBM_RTC_TIME_GET 0x7U > #define COMMAND_BBM_RTC_ALARM_SET 0x8U > #define COMMAND_BBM_BUTTON_GET 0x9U > #define COMMAND_BBM_RTC_NOTIFY 0xAU > #define COMMAND_BBM_BUTTON_NOTIFY 0xBU > #define COMMAND_NEGOTIATE_PROTOCOL_VERSION 0x10U > Hopefully description of each of these commands cover what GPR above means really. > For now in this patchset for linux, we only use RTC, and BUTTON > for system wakeup > > For MISC protocol, it is for various misc things, such as discover > build info, get rom passed data, get reset reason, get i.mx > cfg name, control set(for gpio expander under m33 control and > etc). The command as below: > #define COMMAND_PROTOCOL_VERSION 0x0U > #define COMMAND_PROTOCOL_ATTRIBUTES 0x1U > #define COMMAND_PROTOCOL_MESSAGE_ATTRIBUTES 0x2U > #define COMMAND_MISC_CONTROL_SET 0x3U > #define COMMAND_MISC_CONTROL_GET 0x4U > #define COMMAND_MISC_CONTROL_ACTION 0x5U > #define COMMAND_MISC_DISCOVER_BUILD_INFO 0x6U > #define COMMAND_MISC_ROM_PASSOVER_GET 0x7U > #define COMMAND_MISC_CONTROL_NOTIFY 0x8U > #define COMMAND_MISC_REASON_ATTRIBUTES 0x9U > #define COMMAND_MISC_RESET_REASON 0xAU > #define COMMAND_MISC_SI_INFO 0xBU > #define COMMAND_MISC_CFG_INFO 0xCU > #define COMMAND_MISC_SYSLOG 0xDU > #define COMMAND_NEGOTIATE_PROTOCOL_VERSION 0x10U > And same here. Just as an example what BUILD_INFO ? There will be 10s if not 100s of different image in the system. What does this BUILD_INFO provide ? And why is this important over version or release info ? These are simple pointers, expect more questions like this if the document is not self sufficient in explaining such details. -- Regards, Sudeep
> Subject: Re: [PATCH v2 3/6] firmware: arm_scmi: add initial support for i.MX > BBM protocol > > On Tue, Apr 09, 2024 at 09:13:33AM +0000, Peng Fan wrote: > > Hi Sudeep, > > > > > Subject: Re: [PATCH v2 3/6] firmware: arm_scmi: add initial support > > > for i.MX BBM protocol > > > > > > On Mon, Apr 08, 2024 at 07:04:43PM +0100, Cristian Marussi wrote: > > > > On Fri, Apr 05, 2024 at 08:39:25PM +0800, Peng Fan (OSS) wrote: > > > > > From: Peng Fan <peng.fan@nxp.com> > > > > > > > > > > The i.MX BBM protocol is for managing i.MX BBM module which > > > > > provides RTC and BUTTON feature. > > > > > > > > > > > > > I appreciate that you added versioning but I think a bit of > > > > documentation about what the protocol and its comamnds purpose is > > > > still lacking, as asked by Sudeep previously > > > > > > > > > > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > > > > > lore%2F&data=05%7C02%7Cpeng.fan%40nxp.com%7C6a989d0fb4c1454e94 > 3608 > > > > > dc5882c563%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6384 > 825658 > > > > > 71932293%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoi > V2luM > > > > > zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=OCvYPh3l94 > 0aQ > > > > 7mbAgrfEJMhYmix9%2FUUOA6kZyZJYWQ%3D&reserved=0 > > > > .kernel.org%2Flinux-arm- > > > kernel%2FZeGtoJ7ztSe8Kg8R%40bogus%2F%23t&data= > > > > > > > > 05%7C02%7Cpeng.fan%40nxp.com%7Ce92ff78b9126447afe9708dc587358d > > > 4%7C686e > > > > > > > > a1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638482499632395762%7C > > > Unknown%7C > > > > > > > > TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiL > > > CJXVC > > > > > > > > I6Mn0%3D%7C0%7C%7C%7C&sdata=7QP%2BkkjHA3Sa0CdcbbObGG4kgYYK > > > XAGA2r%2F%2F > > > > x0MogqU%3D&reserved=0 > > > > > > > > > > I have decided to ignore all these vendor protocol patches until > > > they have some documentation to understand what these protocol are > > > for, what are the commands, their input/output parameter details, > > > any conditions are the caller and callee,..etc very similar to SCMI spec. > > > > Where do you expect the documentation to be put? > > > > To begin with, we need all these vendor protocols in a directory say > vendors/nxp under drivers/firmware/arm_scmi. It can be a simple text file > under that. We can see later if we need any more formal version elsewhere > but that shouldn't be a blocker for these changes. > > > similar as scmi_protocol.h, put in scmi_imx_protcol.h? > > > > > > To start with can you please expand what is BBM or MISC protocol is ? > > > > ok. Sorry for missing your previous comment in v1. Let me write here > > briefly first. > > > > Thanks > > > The Battery Backup (BB) Domain contains the Battery Backed Security > > Module (BBSM) and the Battery Backed Non-Secure Module (BBNSM). > > BBM protocol is to manage i.MX BBSM and BBNSM. This protocol supports > > #define COMMAND_PROTOCOL_VERSION 0x0U > > #define COMMAND_PROTOCOL_ATTRIBUTES 0x1U > > #define COMMAND_PROTOCOL_MESSAGE_ATTRIBUTES 0x2U > > #define COMMAND_BBM_GPR_SET 0x3U > > #define COMMAND_BBM_GPR_GET 0x4U > > #define COMMAND_BBM_RTC_ATTRIBUTES 0x5U > > #define COMMAND_BBM_RTC_TIME_SET 0x6U > > #define COMMAND_BBM_RTC_TIME_GET 0x7U > > #define COMMAND_BBM_RTC_ALARM_SET 0x8U > > #define COMMAND_BBM_BUTTON_GET 0x9U > > #define COMMAND_BBM_RTC_NOTIFY 0xAU > > #define COMMAND_BBM_BUTTON_NOTIFY 0xBU > > #define COMMAND_NEGOTIATE_PROTOCOL_VERSION 0x10U > > > > Hopefully description of each of these commands cover what GPR above > means really. ok, will add more comment in the patch for the commands. For GPR, there are some general purpose registers in BBM module that could survive during power cycle, so users could set their own value and use. > > > For now in this patchset for linux, we only use RTC, and BUTTON for > > system wakeup > > > > For MISC protocol, it is for various misc things, such as discover > > build info, get rom passed data, get reset reason, get i.mx cfg name, > > control set(for gpio expander under m33 control and etc). The command > > as below: > > #define COMMAND_PROTOCOL_VERSION 0x0U > > #define COMMAND_PROTOCOL_ATTRIBUTES 0x1U > > #define COMMAND_PROTOCOL_MESSAGE_ATTRIBUTES 0x2U > > #define COMMAND_MISC_CONTROL_SET 0x3U > > #define COMMAND_MISC_CONTROL_GET 0x4U > > #define COMMAND_MISC_CONTROL_ACTION 0x5U > > #define COMMAND_MISC_DISCOVER_BUILD_INFO 0x6U > > #define COMMAND_MISC_ROM_PASSOVER_GET 0x7U > > #define COMMAND_MISC_CONTROL_NOTIFY 0x8U > > #define COMMAND_MISC_REASON_ATTRIBUTES 0x9U > > #define COMMAND_MISC_RESET_REASON 0xAU > > #define COMMAND_MISC_SI_INFO 0xBU > > #define COMMAND_MISC_CFG_INFO 0xCU > > #define COMMAND_MISC_SYSLOG 0xDU > > #define COMMAND_NEGOTIATE_PROTOCOL_VERSION 0x10U > > > > And same here. Just as an example what BUILD_INFO ? There will be 10s if > not 100s of different image in the system. What does this BUILD_INFO > provide ? > And why is this important over version or release info ? BUILD_INFO here is to expose the commit hash and patch numbers. This is firmware developer's decision to add this command, I could not say it is less or more important. > > These are simple pointers, expect more questions like this if the document is > not self sufficient in explaining such details. My plan is to add only the commands that this patch use, not add all the commands. So in v3, there will be doc only for the commands included, hope this is ok. Thanks, Peng. > > -- > Regards, > Sudeep
On Tue, Apr 09, 2024 at 11:19:31AM +0000, Peng Fan wrote: > > ok, will add more comment in the patch for the commands. > No I meant add document/description similar to SCMI spec for each of these commands. Not just one line comment. For std protocols, we can refer spec, for these vendor protocols, just one like comment will not suffice. Describe in more details and hence the request for separate TXT file for that. Hope that is clear now, I have mentioned it several times already. -- Regards, Sudeep
> Subject: Re: [PATCH v2 3/6] firmware: arm_scmi: add initial support for i.MX > BBM protocol > > On Tue, Apr 09, 2024 at 11:19:31AM +0000, Peng Fan wrote: > > > > ok, will add more comment in the patch for the commands. > > > > No I meant add document/description similar to SCMI spec for each of these > commands. Not just one line comment. For std protocols, we can refer spec, > for these vendor protocols, just one like comment will not suffice. Describe in > more details and hence the request for separate TXT file for that. > Hope that is clear now, I have mentioned it several times already. I see, will try to work with our firmware developers to write the details. Thanks, Peng. > > -- > Regards, > Sudeep
diff --git a/drivers/firmware/arm_scmi/Kconfig b/drivers/firmware/arm_scmi/Kconfig index aa5842be19b2..56d11c9d9f47 100644 --- a/drivers/firmware/arm_scmi/Kconfig +++ b/drivers/firmware/arm_scmi/Kconfig @@ -181,3 +181,13 @@ config ARM_SCMI_POWER_CONTROL early shutdown/reboot SCMI requests. endmenu + +config IMX_SCMI_BBM_EXT + tristate "i.MX SCMI BBM EXTENSION" + depends on ARM_SCMI_PROTOCOL || (COMPILE_TEST && OF) + default y if ARCH_MXC + help + This enables i.MX System BBM control logic which supports RTC + and BUTTON. + + This driver can also be built as a module. diff --git a/drivers/firmware/arm_scmi/Makefile b/drivers/firmware/arm_scmi/Makefile index a7bc4796519c..327687acf857 100644 --- a/drivers/firmware/arm_scmi/Makefile +++ b/drivers/firmware/arm_scmi/Makefile @@ -11,6 +11,7 @@ scmi-transport-$(CONFIG_ARM_SCMI_HAVE_MSG) += msg.o scmi-transport-$(CONFIG_ARM_SCMI_TRANSPORT_VIRTIO) += virtio.o scmi-transport-$(CONFIG_ARM_SCMI_TRANSPORT_OPTEE) += optee.o scmi-protocols-y = base.o clock.o perf.o power.o reset.o sensors.o system.o voltage.o powercap.o +scmi-protocols-$(CONFIG_IMX_SCMI_BBM_EXT) += imx-sm-bbm.o scmi-module-objs := $(scmi-driver-y) $(scmi-protocols-y) $(scmi-transport-y) obj-$(CONFIG_ARM_SCMI_PROTOCOL) += scmi-core.o diff --git a/drivers/firmware/arm_scmi/imx-sm-bbm.c b/drivers/firmware/arm_scmi/imx-sm-bbm.c new file mode 100644 index 000000000000..92c0aedf65cc --- /dev/null +++ b/drivers/firmware/arm_scmi/imx-sm-bbm.c @@ -0,0 +1,378 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * System Control and Management Interface (SCMI) NXP BBM Protocol + * + * Copyright 2024 NXP + */ + +#define pr_fmt(fmt) "SCMI Notifications BBM - " fmt + +#include <linux/bits.h> +#include <linux/io.h> +#include <linux/module.h> +#include <linux/of.h> +#include <linux/platform_device.h> +#include <linux/scmi_protocol.h> +#include <linux/scmi_imx_protocol.h> + +#include "protocols.h" +#include "notify.h" + +#define SCMI_PROTOCOL_SUPPORTED_VERSION 0x10000 + +enum scmi_imx_bbm_protocol_cmd { + IMX_BBM_GPR_SET = 0x3, + IMX_BBM_GPR_GET = 0x4, + IMX_BBM_RTC_ATTRIBUTES = 0x5, + IMX_BBM_RTC_TIME_SET = 0x6, + IMX_BBM_RTC_TIME_GET = 0x7, + IMX_BBM_RTC_ALARM_SET = 0x8, + IMX_BBM_BUTTON_GET = 0x9, + IMX_BBM_RTC_NOTIFY = 0xA, + IMX_BBM_BUTTON_NOTIFY = 0xB, +}; + +#define GET_RTCS_NR(x) le32_get_bits((x), GENMASK(23, 16)) +#define GET_GPRS_NR(x) le32_get_bits((x), GENMASK(15, 0)) + +#define SCMI_IMX_BBM_NOTIFY_RTC_UPDATED BIT(2) +#define SCMI_IMX_BBM_NOTIFY_RTC_ROLLOVER BIT(1) +#define SCMI_IMX_BBM_NOTIFY_RTC_ALARM BIT(0) + +#define SCMI_IMX_BBM_RTC_ALARM_ENABLE_FLAG BIT(0) + +#define SCMI_IMX_BBM_NOTIFY_RTC_FLAG \ + (SCMI_IMX_BBM_NOTIFY_RTC_UPDATED | SCMI_IMX_BBM_NOTIFY_RTC_ROLLOVER | \ + SCMI_IMX_BBM_NOTIFY_RTC_ALARM) + +#define SCMI_IMX_BBM_EVENT_RTC_MASK GENMASK(31, 24) + +struct scmi_imx_bbm_info { + u32 version; + int nr_rtc; + int nr_gpr; +}; + +struct scmi_msg_imx_bbm_protocol_attributes { + __le32 attributes; +}; + +struct scmi_imx_bbm_set_time { + __le32 id; + __le32 flags; + __le32 value_low; + __le32 value_high; +}; + +struct scmi_imx_bbm_get_time { + __le32 id; + __le32 flags; +}; + +struct scmi_imx_bbm_alarm_time { + __le32 id; + __le32 flags; + __le32 value_low; + __le32 value_high; +}; + +struct scmi_msg_imx_bbm_rtc_notify { + __le32 rtc_id; + __le32 flags; +}; + +struct scmi_msg_imx_bbm_button_notify { + __le32 flags; +}; + +struct scmi_imx_bbm_notify_payld { + __le32 flags; +}; + +static int scmi_imx_bbm_attributes_get(const struct scmi_protocol_handle *ph, + struct scmi_imx_bbm_info *pi) +{ + int ret; + struct scmi_xfer *t; + struct scmi_msg_imx_bbm_protocol_attributes *attr; + + ret = ph->xops->xfer_get_init(ph, PROTOCOL_ATTRIBUTES, 0, sizeof(*attr), &t); + if (ret) + return ret; + + attr = t->rx.buf; + + ret = ph->xops->do_xfer(ph, t); + if (!ret) { + pi->nr_rtc = GET_RTCS_NR(attr->attributes); + pi->nr_gpr = GET_GPRS_NR(attr->attributes); + } + + ph->xops->xfer_put(ph, t); + + return ret; +} + +static int scmi_imx_bbm_notify(const struct scmi_protocol_handle *ph, + u32 src_id, int message_id, bool enable) +{ + int ret; + struct scmi_xfer *t; + + if (message_id == IMX_BBM_RTC_NOTIFY) { + struct scmi_msg_imx_bbm_rtc_notify *rtc_notify; + + ret = ph->xops->xfer_get_init(ph, message_id, + sizeof(*rtc_notify), 0, &t); + if (ret) + return ret; + + rtc_notify = t->tx.buf; + rtc_notify->rtc_id = cpu_to_le32(0); + rtc_notify->flags = + cpu_to_le32(enable ? SCMI_IMX_BBM_NOTIFY_RTC_FLAG : 0); + } else if (message_id == IMX_BBM_BUTTON_NOTIFY) { + struct scmi_msg_imx_bbm_button_notify *button_notify; + + ret = ph->xops->xfer_get_init(ph, message_id, + sizeof(*button_notify), 0, &t); + if (ret) + return ret; + + button_notify = t->tx.buf; + button_notify->flags = cpu_to_le32(enable ? 1 : 0); + } else { + return -EINVAL; + } + + ret = ph->xops->do_xfer(ph, t); + + ph->xops->xfer_put(ph, t); + return ret; +} + +static enum scmi_imx_bbm_protocol_cmd evt_2_cmd[] = { + IMX_BBM_RTC_NOTIFY, + IMX_BBM_BUTTON_NOTIFY +}; + +static int scmi_imx_bbm_set_notify_enabled(const struct scmi_protocol_handle *ph, + u8 evt_id, u32 src_id, bool enable) +{ + int ret, cmd_id; + + if (evt_id >= ARRAY_SIZE(evt_2_cmd)) + return -EINVAL; + + cmd_id = evt_2_cmd[evt_id]; + ret = scmi_imx_bbm_notify(ph, src_id, cmd_id, enable); + if (ret) + pr_debug("FAIL_ENABLED - evt[%X] dom[%d] - ret:%d\n", + evt_id, src_id, ret); + + return ret; +} + +static void *scmi_imx_bbm_fill_custom_report(const struct scmi_protocol_handle *ph, + u8 evt_id, ktime_t timestamp, + const void *payld, size_t payld_sz, + void *report, u32 *src_id) +{ + const struct scmi_imx_bbm_notify_payld *p = payld; + struct scmi_imx_bbm_notif_report *r = report; + + if (sizeof(*p) != payld_sz) + return NULL; + + if (evt_id == SCMI_EVENT_IMX_BBM_RTC) { + r->is_rtc = true; + r->is_button = false; + r->timestamp = timestamp; + r->rtc_id = le32_get_bits(p->flags, SCMI_IMX_BBM_EVENT_RTC_MASK); + r->rtc_evt = le32_get_bits(p->flags, SCMI_IMX_BBM_NOTIFY_RTC_FLAG); + dev_dbg(ph->dev, "RTC: %d evt: %x\n", r->rtc_id, r->rtc_evt); + *src_id = r->rtc_evt; + } else if (evt_id == SCMI_EVENT_IMX_BBM_BUTTON) { + r->is_rtc = false; + r->is_button = true; + r->timestamp = timestamp; + dev_dbg(ph->dev, "BBM Button\n"); + *src_id = 0; + } else { + WARN_ON_ONCE(1); + return NULL; + } + + return r; +} + +static const struct scmi_event scmi_imx_bbm_events[] = { + { + .id = SCMI_EVENT_IMX_BBM_RTC, + .max_payld_sz = sizeof(struct scmi_imx_bbm_notify_payld), + .max_report_sz = sizeof(struct scmi_imx_bbm_notif_report), + }, + { + .id = SCMI_EVENT_IMX_BBM_BUTTON, + .max_payld_sz = sizeof(struct scmi_imx_bbm_notify_payld), + .max_report_sz = sizeof(struct scmi_imx_bbm_notif_report), + }, +}; + +static const struct scmi_event_ops scmi_imx_bbm_event_ops = { + .set_notify_enabled = scmi_imx_bbm_set_notify_enabled, + .fill_custom_report = scmi_imx_bbm_fill_custom_report, +}; + +static const struct scmi_protocol_events scmi_imx_bbm_protocol_events = { + .queue_sz = SCMI_PROTO_QUEUE_SZ, + .ops = &scmi_imx_bbm_event_ops, + .evts = scmi_imx_bbm_events, + .num_events = ARRAY_SIZE(scmi_imx_bbm_events), + .num_sources = 1, +}; + +static int scmi_imx_bbm_protocol_init(const struct scmi_protocol_handle *ph) +{ + u32 version; + int ret; + struct scmi_imx_bbm_info *binfo; + + ret = ph->xops->version_get(ph, &version); + if (ret) + return ret; + + dev_info(ph->dev, "NXP SM BBM Version %d.%d\n", + PROTOCOL_REV_MAJOR(version), PROTOCOL_REV_MINOR(version)); + + binfo = devm_kzalloc(ph->dev, sizeof(*binfo), GFP_KERNEL); + if (!binfo) + return -ENOMEM; + + ret = scmi_imx_bbm_attributes_get(ph, binfo); + if (ret) + return ret; + + return ph->set_priv(ph, binfo, version); +} + +static int scmi_imx_bbm_rtc_time_set(const struct scmi_protocol_handle *ph, + u32 rtc_id, u64 sec) +{ + struct scmi_imx_bbm_info *pi = ph->get_priv(ph); + struct scmi_imx_bbm_set_time *cfg; + struct scmi_xfer *t; + int ret; + + if (rtc_id >= pi->nr_rtc) + return -EINVAL; + + ret = ph->xops->xfer_get_init(ph, IMX_BBM_RTC_TIME_SET, sizeof(*cfg), 0, &t); + if (ret) + return ret; + + cfg = t->tx.buf; + cfg->id = cpu_to_le32(rtc_id); + cfg->flags = 0; + cfg->value_low = lower_32_bits(sec); + cfg->value_high = upper_32_bits(sec); + + ret = ph->xops->do_xfer(ph, t); + + ph->xops->xfer_put(ph, t); + + return ret; +} + +static int scmi_imx_bbm_rtc_time_get(const struct scmi_protocol_handle *ph, + u32 rtc_id, u64 *value) +{ + struct scmi_imx_bbm_info *pi = ph->get_priv(ph); + struct scmi_imx_bbm_get_time *cfg; + struct scmi_xfer *t; + int ret; + + if (rtc_id >= pi->nr_rtc) + return -EINVAL; + + ret = ph->xops->xfer_get_init(ph, IMX_BBM_RTC_TIME_GET, sizeof(*cfg), + sizeof(u64), &t); + if (ret) + return ret; + + cfg = t->tx.buf; + cfg->id = cpu_to_le32(rtc_id); + cfg->flags = 0; + + ret = ph->xops->do_xfer(ph, t); + if (!ret) + *value = get_unaligned_le64(t->rx.buf); + + ph->xops->xfer_put(ph, t); + + return ret; +} + +static int scmi_imx_bbm_rtc_alarm_set(const struct scmi_protocol_handle *ph, + u32 rtc_id, u64 sec) +{ + struct scmi_imx_bbm_info *pi = ph->get_priv(ph); + struct scmi_imx_bbm_alarm_time *cfg; + struct scmi_xfer *t; + int ret; + + if (rtc_id >= pi->nr_rtc) + return -EINVAL; + + ret = ph->xops->xfer_get_init(ph, IMX_BBM_RTC_ALARM_SET, sizeof(*cfg), 0, &t); + if (ret) + return ret; + + cfg = t->tx.buf; + cfg->id = cpu_to_le32(rtc_id); + cfg->flags = SCMI_IMX_BBM_RTC_ALARM_ENABLE_FLAG; + cfg->value_low = lower_32_bits(sec); + cfg->value_high = upper_32_bits(sec); + + ret = ph->xops->do_xfer(ph, t); + + ph->xops->xfer_put(ph, t); + + return ret; +} + +static int scmi_imx_bbm_button_get(const struct scmi_protocol_handle *ph, u32 *state) +{ + struct scmi_xfer *t; + int ret; + + ret = ph->xops->xfer_get_init(ph, IMX_BBM_BUTTON_GET, 0, sizeof(u32), &t); + if (ret) + return ret; + + ret = ph->xops->do_xfer(ph, t); + if (!ret) + *state = get_unaligned_le32(t->rx.buf); + + ph->xops->xfer_put(ph, t); + + return ret; +} + +static const struct scmi_imx_bbm_proto_ops scmi_imx_bbm_proto_ops = { + .rtc_time_get = scmi_imx_bbm_rtc_time_get, + .rtc_time_set = scmi_imx_bbm_rtc_time_set, + .rtc_alarm_set = scmi_imx_bbm_rtc_alarm_set, + .button_get = scmi_imx_bbm_button_get, +}; + +static const struct scmi_protocol scmi_imx_bbm = { + .id = SCMI_PROTOCOL_IMX_BBM, + .owner = THIS_MODULE, + .instance_init = &scmi_imx_bbm_protocol_init, + .ops = &scmi_imx_bbm_proto_ops, + .events = &scmi_imx_bbm_protocol_events, + .supported_version = SCMI_PROTOCOL_SUPPORTED_VERSION, +}; + +module_scmi_protocol(scmi_imx_bbm); diff --git a/include/linux/scmi_imx_protocol.h b/include/linux/scmi_imx_protocol.h new file mode 100644 index 000000000000..90ce011a4429 --- /dev/null +++ b/include/linux/scmi_imx_protocol.h @@ -0,0 +1,45 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * SCMI Message Protocol driver NXP extension header + * + * Copyright 2024 NXP. + */ + +#ifndef _LINUX_SCMI_NXP_PROTOCOL_H +#define _LINUX_SCMI_NXP_PROTOCOL_H + +#include <linux/bitfield.h> +#include <linux/device.h> +#include <linux/notifier.h> +#include <linux/types.h> + +enum scmi_nxp_protocol { + SCMI_PROTOCOL_IMX_BBM = 0x81, +}; + +struct scmi_imx_bbm_proto_ops { + int (*rtc_time_set)(const struct scmi_protocol_handle *ph, u32 id, + uint64_t sec); + int (*rtc_time_get)(const struct scmi_protocol_handle *ph, u32 id, + u64 *val); + int (*rtc_alarm_set)(const struct scmi_protocol_handle *ph, u32 id, + u64 sec); + int (*button_get)(const struct scmi_protocol_handle *ph, u32 *state); +}; + +enum scmi_nxp_notification_events { + SCMI_EVENT_IMX_BBM_RTC = 0x0, + SCMI_EVENT_IMX_BBM_BUTTON = 0x1, + SCMI_EVENT_IMX_MISC_CONTROL_DISABLED = 0x0, + SCMI_EVENT_IMX_MISC_CONTROL_FALLING_EDGE = 0x1, + SCMI_EVENT_IMX_MISC_CONTROL_RISING_EDGE = 0x2, +}; + +struct scmi_imx_bbm_notif_report { + bool is_rtc; + bool is_button; + ktime_t timestamp; + unsigned int rtc_id; + unsigned int rtc_evt; +}; +#endif