linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan.Cameron@huawei.com (Jonathan Cameron)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v6 04/20] firmware: arm_scmi: add common infrastructure and support for base protocol
Date: Mon, 5 Mar 2018 14:11:54 +0000	[thread overview]
Message-ID: <20180305151154.000051c2@huawei.com> (raw)
In-Reply-To: <1519403030-21189-5-git-send-email-sudeep.holla@arm.com>

On Fri, 23 Feb 2018 16:23:34 +0000
Sudeep Holla <sudeep.holla@arm.com> wrote:

> The base protocol describes the properties of the implementation and
> provide generic error management. The base protocol provides commands
> to describe protocol version, discover implementation specific
> attributes and vendor/sub-vendor identification, list of protocols
> implemented and the various agents are in the system including OSPM
> and the platform. It also supports registering for notifications of
> platform errors.
> 
> This protocol is mandatory. This patch adds support for the same along
> with some basic infrastructure to add support for other protocols.
> 
<snip>

Minor comments inline.

> diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
> index fa0e9cf31f4c..ba784b8ec170 100644
> --- a/drivers/firmware/arm_scmi/driver.c
> +++ b/drivers/firmware/arm_scmi/driver.c
> @@ -105,21 +105,27 @@ struct scmi_desc {
>   * @dev: Device pointer
>   * @desc: SoC description for this instance
>   * @handle: Instance of SCMI handle to send to clients
> + * @version: SCMI revision information containing protocol version,
> + *	implementation version and (sub-)vendor identification.
>   * @cl: Mailbox Client
>   * @tx_chan: Transmit mailbox channel
>   * @tx_payload: Transmit mailbox channel payload area
>   * @minfo: Message info
> + * @protocols_imp: list of protocols implemented, currently maximum of
> + *	MAX_PROTOCOLS_IMP elements allocated by the base protocol
If it is fixed size, is there a benefit in not just putting it in here
as a fixed size array and simplifying the allocation?

>   * @node: list head
>   * @users: Number of users of this instance
>   */
>  struct scmi_info {
>  	struct device *dev;
>  	const struct scmi_desc *desc;
> +	struct scmi_revision_info version;
>  	struct scmi_handle handle;
>  	struct mbox_client cl;
>  	struct mbox_chan *tx_chan;
>  	void __iomem *tx_payload;
>  	struct scmi_xfers_info minfo;
> +	u8 *protocols_imp;
>  	struct list_head node;
>  	int users;
>  };
> @@ -433,6 +439,45 @@ int scmi_one_xfer_init(const struct scmi_handle *handle, u8 msg_id, u8 prot_id,
>  }
>  
>  /**
> + * scmi_version_get() - command to get the revision of the SCMI entity
> + *
> + * @handle: Handle to SCMI entity information
> + *
> + * Updates the SCMI information in the internal data structure.
> + *
> + * Return: 0 if all went fine, else return appropriate error.
> + */
> +int scmi_version_get(const struct scmi_handle *handle, u8 protocol,
> +		     u32 *version)
> +{
> +	int ret;
> +	__le32 *rev_info;
> +	struct scmi_xfer *t;
> +
> +	ret = scmi_one_xfer_init(handle, PROTOCOL_VERSION, protocol, 0,
> +				 sizeof(*version), &t);
> +	if (ret)
> +		return ret;
> +
> +	ret = scmi_do_xfer(handle, t);
> +	if (!ret) {
> +		rev_info = t->rx.buf;
> +		*version = le32_to_cpu(*rev_info);
> +	}
> +
> +	scmi_one_xfer_put(handle, t);
blank line before all simple returns is common kernel coding style
and does help for readability (a little bit)

> +	return ret;
> +}
> +
> +void scmi_setup_protocol_implemented(const struct scmi_handle *handle,
> +				     u8 *prot_imp)
> +{
> +	struct scmi_info *info = handle_to_scmi_info(handle);
> +
> +	info->protocols_imp = prot_imp;
> +}
> +
> +/**
>   * scmi_handle_get() - Get the  SCMI handle for a device
>   *
>   * @dev: pointer to device for which we want SCMI handle
> @@ -660,11 +705,19 @@ static int scmi_probe(struct platform_device *pdev)
>  
>  	handle = &info->handle;
>  	handle->dev = info->dev;
> +	handle->version = &info->version;
>  
>  	ret = scmi_mbox_chan_setup(info);
>  	if (ret)
>  		return ret;
>  
> +	ret = scmi_base_protocol_init(handle);
> +	if (ret) {
> +		dev_err(dev, "unable to communicate with SCMI(%d)\n", ret);
> +		scmi_mbox_free_channel(info);
> +		return ret;
> +	}
> +
>  	mutex_lock(&scmi_list_mutex);
>  	list_add_tail(&info->node, &scmi_list);
>  	mutex_unlock(&scmi_list_mutex);
> diff --git a/include/linux/scmi_protocol.h b/include/linux/scmi_protocol.h
> index 854ed2479993..664da3d763f2 100644
> --- a/include/linux/scmi_protocol.h
> +++ b/include/linux/scmi_protocol.h
> @@ -17,11 +17,48 @@
>   */
>  #include <linux/types.h>
>  
> +#define SCMI_MAX_STR_SIZE	16
> +
> +/**
> + * struct scmi_revision_info - version information structure
This isn't really just the version stuff. It's more about discovery
of what is present.
Perhaps the naming could make that clear if you want to keep this
as one structure?

> + *
> + * @major_ver: Major ABI version. Change here implies risk of backward
> + *	compatibility break.
> + * @minor_ver: Minor ABI version. Change here implies new feature addition,
> + *	or compatible change in ABI.
> + * @num_protocols: Number of protocols that are implemented, excluding the
> + *	base protocol.
> + * @num_agents: Number of agents in the system.
> + * @impl_ver: A vendor-specific implementation version.
> + * @vendor_id: A vendor identifier(Null terminated ASCII string)
> + * @sub_vendor_id: A sub-vendor identifier(Null terminated ASCII string)
> + */
> +struct scmi_revision_info {
> +	u16 major_ver;
> +	u16 minor_ver;
> +	u8 num_protocols;
> +	u8 num_agents;
> +	u32 impl_ver;
> +	char vendor_id[SCMI_MAX_STR_SIZE];
> +	char sub_vendor_id[SCMI_MAX_STR_SIZE];
> +};
> +
>  /**
>   * struct scmi_handle - Handle returned to ARM SCMI clients for usage.
>   *
>   * @dev: pointer to the SCMI device
> + * @version: pointer to the structure containing SCMI version information
>   */
>  struct scmi_handle {
>  	struct device *dev;
> +	struct scmi_revision_info *version;
> +};
> +
> +enum scmi_std_protocol {
> +	SCMI_PROTOCOL_BASE = 0x10,
> +	SCMI_PROTOCOL_POWER = 0x11,
> +	SCMI_PROTOCOL_SYSTEM = 0x12,
> +	SCMI_PROTOCOL_PERF = 0x13,
> +	SCMI_PROTOCOL_CLOCK = 0x14,
> +	SCMI_PROTOCOL_SENSOR = 0x15,
>  };

  reply	other threads:[~2018-03-05 14:11 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-23 16:23 [PATCH v6 00/20] firmware: ARM System Control and Management Interface(SCMI) support Sudeep Holla
2018-02-23 16:23 ` [PATCH v6 01/20] dt-bindings: mailbox: add support for mailbox client shared memory Sudeep Holla
2018-02-23 16:23 ` [PATCH v6 02/20] dt-bindings: arm: add support for ARM System Control and Management Interface(SCMI) protocol Sudeep Holla
2018-02-23 16:23 ` [PATCH v6 03/20] firmware: arm_scmi: add basic driver infrastructure for SCMI Sudeep Holla
2018-02-26 15:57   ` Philippe Ombredanne
2018-02-26 17:10     ` Sudeep Holla
2018-03-05 13:52   ` Jonathan Cameron
2018-03-05 14:30     ` Sudeep Holla
2018-03-05 14:47       ` Jonathan Cameron
2018-02-23 16:23 ` [PATCH v6 04/20] firmware: arm_scmi: add common infrastructure and support for base protocol Sudeep Holla
2018-03-05 14:11   ` Jonathan Cameron [this message]
2018-02-23 16:23 ` [PATCH v6 05/20] firmware: arm_scmi: add scmi protocol bus to enumerate protocol devices Sudeep Holla
2018-03-05 14:23   ` Jonathan Cameron
2018-02-23 16:23 ` [PATCH v6 06/20] firmware: arm_scmi: add initial support for performance protocol Sudeep Holla
2018-03-05 14:29   ` Jonathan Cameron
2018-02-23 16:23 ` [PATCH v6 07/20] firmware: arm_scmi: add initial support for clock protocol Sudeep Holla
2018-02-23 16:23 ` [PATCH v6 08/20] firmware: arm_scmi: add initial support for power protocol Sudeep Holla
2018-02-23 16:23 ` [PATCH v6 09/20] firmware: arm_scmi: add initial support for sensor protocol Sudeep Holla
2018-02-23 16:23 ` [PATCH v6 10/20] firmware: arm_scmi: probe and initialise all the supported protocols Sudeep Holla
2018-02-23 16:23 ` [PATCH v6 11/20] firmware: arm_scmi: add support for polling based SCMI transfers Sudeep Holla
2018-02-23 16:23 ` [PATCH v6 12/20] firmware: arm_scmi: add option for polling based performance domain operations Sudeep Holla
2018-02-23 16:23 ` [PATCH v6 13/20] firmware: arm_scmi: refactor in preparation to support per-protocol channels Sudeep Holla
2018-03-05 14:35   ` Jonathan Cameron
2018-03-05 14:43     ` Sudeep Holla
2018-02-23 16:23 ` [PATCH v6 14/20] firmware: arm_scmi: add per-protocol channels support using idr objects Sudeep Holla
2018-02-23 16:23 ` [PATCH v6 15/20] firmware: arm_scmi: add device power domain support using genpd Sudeep Holla
2018-02-23 16:23 ` [PATCH v6 16/20] clk: add support for clocks provided by SCMI Sudeep Holla
2018-03-16 23:02   ` Stephen Boyd
2018-03-20 12:08     ` Sudeep Holla
2018-03-20 16:22       ` Stephen Boyd
2018-02-23 16:23 ` [PATCH v6 17/20] hwmon: (core) Add hwmon_max to hwmon_sensor_types enumeration Sudeep Holla
2018-02-23 16:23 ` [PATCH v6 18/20] hwmon: add support for sensors exported via ARM SCMI Sudeep Holla
2018-02-23 16:23 ` [PATCH v6 19/20] cpufreq: add support for CPU DVFS based on SCMI message protocol Sudeep Holla
2018-02-23 16:23 ` [PATCH v6 20/20] cpufreq: scmi: add support for fast frequency switching Sudeep Holla

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180305151154.000051c2@huawei.com \
    --to=jonathan.cameron@huawei.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).